02-21-2014 10:27 AM - edited 03-18-2019 02:38 AM
Dear community,
I am experiencing an interesting issue with TP Conductor based OBTP scheduled conferences and the behavior of TC software based endpoints natively registered to CUCM.
Software versions:
- TelePresence Conductor XC2.2.1
- CUCM 9.1.2
- TMS 14.3.2
- TC 7.0.2
Scheduled conferences are configured as OBTP and the Conductor is the preffered MCU in routing.
Behind the Conductor is a TelePresence Server 7010 appliance.
The Conductor Alias Pattern is 805%, priority 100, is immersive is not checked, the generated regular expression is (805[^@]*).*
Numeric ID Base for the alias is 10, Numeric ID Step is 1, Numeric ID Quantity is 9.
When scheduling conferences with TMS, TMS is generating numbers in this sequence:
80510, 80511, 80512, etc.
In CUCM, the Conductor IP alias for rendezvous is a destination of a SIP trunk, and there is a
route pattern 8051X
pointing to it.
The conference alias in Conductor is
(805[^@]*).*
With OBTP and CTS software based endpoints everything works well, these 8051X numbers are pushed to the MIDlets of the IP Phone or Touch 12" and the endpoints connect to the telepresence server scheduled conference.
With the TC software based endpoints, when selecting Join now on the conference reminder pop up screen with the remote control, the endpoint is dialing both:
80510@<CUCM-IP-Address> and
where example.com is the CUCM cluster domain.
The TC endpoint then somehow automatically connects with two sessions to the telepresence server which is extremely awkward.
When pushing the red disconnect button on the remote control, I have an option to disconnect all calls, or disconnect the first or second call to the same dialed alias 80510@<CUCM-IP-Address>. If I disconnect one of the calls everything is OK.
But then, how come the TC based endpoint initates two calls in parallel to the Conductor and then Telepresence Server ?
Has anybody experienced a similar issue ?
If I manually dial 80510 everything is fine, the endpoint dials
80510@<CUCM-IP-Address> and it connects successfully.
02-21-2014 05:07 PM
I think theres an open issue with this. Sounds like a bug we encountered with another customer. Someone may beat me to it but this was seen on touch panel and the OSD. Will have a look for it over the weekend. If not it will be on Monday for sure.
VR
Patrick.
Sent from Cisco Technical Support Android App
02-21-2014 11:11 PM
Hello Patrick,
Thank you very much for the input.
I also have the
log ctx SIPStack debug 9
from the endpoint when initiating the call. I can provide it to you privately.
Did not have enough time to get the traces from CUCM but will also check them.
If we are really hitting a bug, I will have to quickly do a workaround removing the Conductor from scheduling and trying directly with the TelePresence Server.
Mihail
02-22-2014 09:06 AM
Sure you can PM me the log if you have it. Its not a conductor issue, but an endpoint problem fixed in a later release.
VR
Patrick
Sent from Cisco Technical Support Android App
08-27-2014 02:18 PM
08-27-2014 10:51 PM
Hi,
This was a bug in that particular TC software version.
It is solved now.
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