08-07-2013 05:15 PM - edited 03-18-2019 01:35 AM
Hi folks,
I have just one question: When integrating Conductor to VCS using B2BUA deployment, can I make H.323 endpoints registered to VCS to dial to Conductor meetings? I am assuming that the dial plan is properly configured to route the calls and interworking is enable and properly working on VCS to allow H323 to SIP dialling.
Currently, this setup is not working for me. After making several troubleshooting attempts and debugs, I came to conclusion that there is some bug or limitation in Conductor, that's why this setup is not working. But I need to confirm if this integration is supposed to work or not, before opening a TAC case. I didn't find any specific information in the documentation.
I have the following devices. All they are running latest software version:
Conductor
VCS
TP Server
TC Endpoints
The problem does not occur when dialling from SIP endpoints to Conductor. Also, if I dial from Conductor to the H323 endpoints, it works normally using interworking in VCS. The problem only happens from H323 endpoints to Conductor.
I would appreciate any help. Thanks in advance!
Regards
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
Solved! Go to Solution.
08-08-2013 12:43 PM
Hey Paulo,
You did a good job of going through the logs. As you pointed out the issue is with the SIP options. The conductor receives a SIP Options from the VCS but never sends back a reply. This causes the call to hang and then eventually timeout.
There is a defect for this, once the ID has been generated I'll let you know what it is.
The workaround is to switch the zone profile to custom with "Automatically respond to SIP searches" on. Let us know if the workaround works out for you.
Thanks, Adam
08-07-2013 11:40 PM
Yes, H.323 endpoints should be able to dial into a B2BUA Conductor. I assume you have a configuration issue on your VCS.
Sent from Cisco Technical Support iPhone App
08-08-2013 02:54 AM
Hi Kjetil,
Thanks for answering.
Well, collecting logs in VCS and Conductor, I found a possible problem with Conductor. This is what happens:
--------------------------------------------------------------------
2013-08-07T18:06:44-03:00 Conductor b2bua[17139]: UTCTime="2013-08-07 21:06:44,179" Module="network.sip" Level="INFO": Src-ip="10.54.9.14" Src-port="28516" Detail="Receive Request Method=OPTIONS, Request-URI=sip:77984999@doamin.com... ... ... ... ... ...
2013-08-07T18:06:44-03:00 Conductor b2bua[17139]: UTCTime="2013-08-07 21:06:44,179" Module="developer.applicationmanager.search" Level="INFO" CodeLocation="ppcmains/ivy/search/SearchFsmState_Idle.cpp(96)" Method="SearchFsmState_Idle::performSearch" Thread="0x7fe21a92a700": AppId="44" LegId="BSide" CurState="SearchFsmState_Idle" Detail="Initiating search" searchContext="mTarget : sip:77984999@domain.com
mRouteSet:
2013-08-07T18:06:44-03:00 Conductor b2bua[17139]: UTCTime="2013-08-07 21:06:44,179" Module="developer.modulefactory.threadeddispatcher" Level="ERROR" CodeLocation="ppcmains/ivy/threadeddispatcher/ThreadedDispatcher.cpp(94)" Method="ThreadedDispatcher::run" Thread="0x7fe21a92a700": Detail="Caught std::exception" what="DefaultRouteHeaderStrategy::manipulateOutgoingRouteSet: Policy routing configured, but no outgoing route found."
2013-08-07T18:06:44-03:00 Conductor conferencefactory.controller
--------------------------------------------------------------------------------------------------
One detail. I am not using Call Policy in Conductor and I made sure it is not enable on all templates. The error seems to be related to some internal module or object, I don't know exactly.
Also, I tried to use different Conductors into two different customer enviroments and I got exactly the same error.
Any thoughts? How can it be a problem related to VCS if the call is being routed properly?
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
08-08-2013 10:45 AM
Hi Folks,
I have opened a TAC case. Adam from Cisco has taken ownership of my case. We are working to find a solution. Once we get a solution for the problem, I will provide a feedback here, it may be helpfull to assist another people with similar problem.
Regards
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
08-08-2013 12:43 PM
Hey Paulo,
You did a good job of going through the logs. As you pointed out the issue is with the SIP options. The conductor receives a SIP Options from the VCS but never sends back a reply. This causes the call to hang and then eventually timeout.
There is a defect for this, once the ID has been generated I'll let you know what it is.
The workaround is to switch the zone profile to custom with "Automatically respond to SIP searches" on. Let us know if the workaround works out for you.
Thanks, Adam
08-08-2013 01:04 PM
Hi Adam,
That worked!
I tried to use custom profile before, but I only changed the option “Interworking SIP Search strategy” and set it to INFO. I thought that Conductor was not able to understand SIP OPTIONS correctly, but it did not work even using INFO message instead OPTIONS message. But now it is working!
Thank you very much for your fast assistance! I really appreciate it.
Please, keep us informed about the bug informations and updates.
Regards
Paulo Souza
Please rate replies and mark question as "answered" if applicable.
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