07-31-2012 05:43 AM - edited 03-17-2019 11:32 PM
Hi, we’ve reached the limit of SIP URIs on our 8510 and I noticed the below in the admin guide, has anyone achieved this prefix based routing method and does it retain the presence of the MCU conferences?
Solved! Go to Solution.
07-31-2012 05:37 PM
Hi Darren,
Instead of registering all conferences (SIP) to VCS, prefix based routing needs rule/s to be created on VCS.
For eg:- 11(.*)@abc.com ----target this to MCU.
In this case, presence will not be retained as conferences will not register and PUBLISH their presence status to VCS.
Hope this helps.
Regards,
Sagar
07-31-2012 05:37 PM
Hi Darren,
Instead of registering all conferences (SIP) to VCS, prefix based routing needs rule/s to be created on VCS.
For eg:- 11(.*)@abc.com ----target this to MCU.
In this case, presence will not be retained as conferences will not register and PUBLISH their presence status to VCS.
Hope this helps.
Regards,
Sagar
07-31-2012 06:47 PM
Hello Sagar!
To be honest, the VCS is from cisco, the MCU is from cisco and this is a non so uncommon deployment
to have more then 50 conferences and possibly prefix routing and the wish to have presence.
For me this would be something which the VCS and its PUA and the MCU could handle way more clever.
Also some handy things like setting the conference to busy or if full to unavailable and if the client
supports showing the state even the amount of current and availalble ports, ...
Please remember to rate helpful responses and identify
08-01-2012 06:50 AM
Thanks guys, have to agree with Martin but I guess it's a limitation of the hardware? Does the limit apply across the board on the Codian boxes, what about the TelePresence server?
08-01-2012 08:57 AM
For me this is a software limitation.
Btw, in earlier versions the MCU/VCS supported more (at least h323 registered conferences).
We use authentication and these many registrations crashed the VCS. Maybe thats one of
the reasons why it is now limited.
I always thought of adding an extra sip domain for the MCU, and use either the API of the VCS
or the MCU to get the concurrent calls out and then map these to an extra presence handler.
But hope dies last that this will be fixed in general and it was not critical for us.
Also the handling of the meeting room number could be optimized. I lack for example
the capability to add the prefix (not as a prefix registration, that does not exist with sip),
but as a numeric prefix upfront the sip registration.
like you have the prefix 80 and the conference number 50 you would dial 8050 you will always
and up in a h323 call and the mcu registers the number 50, it would be much better if it could
register on sip 8050.
Also the handling in TMS is not ideal. The other way a workaround could be is to use only the service prefix
and give the conferences the number 80xx for example. But at some point in the TMS/MCU upgrades
that does not behave properly anymore as TMS only tries to add conferences like xx and not 80xx.
Maybe someone from Cisco reads this and cam make a change :-)
Please remember to rate helpful responses and identify
08-01-2012 05:50 PM
Btw, in earlier versions the MCU/VCS supported more (at least h323 registered conferences).
We use authentication and these many registrations crashed the VCS. Maybe thats one of
the reasons why it is now limited.
>>-MCU still have 100 H323 and 50 SIP registration. This limit was set in earlier version as well.
always thought of adding an extra sip domain for the MCU, and use either the API of the VCS
or the MCU to get the concurrent calls out and then map these to an extra presence handler.
But hope dies last that this will be fixed in general and it was not critical for us.
>> Presence works on base of SUBSRCIBE- NOTIFY. When an UA(user agent) registers to REGISTRAR (VCS in this case), after that it sends SUBSCRIBE to subscribe for event 'presence'. Whenever the Status of the UA changes, it send PUBLISH to VCS, and VCS will send NOTIFY all the other UA's whose has subscribe to Presence event.
So without Registration,MCU will act as Gateway. Presence will not work for this scenario.
like you have the prefix 80 and the conference number 50 you would dial 8050 you will always
and up in a h323 call and the mcu registers the number 50, it would be much better if it could
register on sip 8050.
>> Lets say that you created a conference with Numeric ID 50 and MCU service prefix is 80. Now you have registered as both H323 and SIP. In this case you dont need 80. You can directly dial with H323 id 50 or SIP URI 50@domain.com
Now lets says that you have conference created but not registered, in that case for H323 you can dial 80(prefix) followed by conference ID. But in case of SIP what you can do is create a rule as follow
80(.*)@domain.com ---> \1@domain.com
Increase the priority of this rule and target it towards the MCU. Now if SIP endpoints dails 8050@domain.com, it will strip and send 50@domain.com and it will be end to end SIP call.
H323 and SIP boths works in different way, so we cannot expect same out of both.
Hope this helps
-Sagar
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide