Conductor - Unable to dial-in from H323 endpoints

[Paulo Souza]

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.       

[Kjetil Ree]

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

[Paulo Souza]

Hi Kjetil,

Thanks for answering.

Well, collecting logs in VCS and Conductor, I found a possible problem with Conductor. This is what happens:

• VCS receives the initial RAS from H323 endpoints
• The call request reaches the correct search rules towards Conductor, the destination URI is corrrect (just like when calling from SIP)
• VCS then sends SIP OPTIONS message to Conductor with the correct destination URI (it matches conference alias)
• VCS receives timeout from Conductor. No answer is received from Conductor and the call fails
• In Conductor, I do see this SIP OPTIONS message coming in, but the call is not routed to the conference alias, instead, I see an strange internal error in Conductor. This is the error:

--------------------------------------------------------------------

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.

[Paulo Souza]

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.

[Adam Wamsley · Accepted solution]

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

[Paulo Souza]

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.