CUCM 6.1(2) with OCS integration call forwarding failures

glenn.martindell · ‎11-20-2009

Hello,

I have a CUCM 6.1(2) cluster with two CUBE (h323 to SIP) routers. CUCM handles all PSTN routing for OCS. Everything works fine except if an OCS endpoint forwards calls back to the PSTN. If the call is forwarded to a land line phone, the call completes correctly. If the call is forwarded to a mobile phone, the call times out and fails. We can see the ISDN timer expirey message in the Q931 message on the originating PSTN leg of the call. It looks like neither of these calls sends a call progress message but since the land line call sets up quicker, the timer does not expire before the call connects. Anyone know how I can force either CUCM, CUBE or OCS to send a call progress message on a forwarded call?

Call flow is as follows:

MGCP PRI --> CUCM --> CUBE1 --> OCS --> CUBE2 --> CUCM --> MGCP PRI

Any help is greatly appreciated.

Thanks,

Glenn

glenn.martindell · ‎11-23-2009

In case anyone is interested, this looks like an interoperability issue with CUBE and OCS. Cisco has documented

an internal bug and the fix is set to be released in 15.1.1(T) in April 2010.

A summary of the bug notes for "CSCsv04606 - Handling 183 without sdp from Microsoft OCS" are as follows:

Description of the issue
++++++++++++++++++++++++
OCS cannot send a 180 since the called party may be available at multiple locations/AoRs, some of which may require NAT and FW traversal. This procedure may take time. Thus OCS chooses not to send 180 or 183 w/SDP because they will cause PSTN GW to start alerting the caller even before OCS knows whether the called-party is available. Moreover, OCS has not yet determined whether the called party is capable of providing ringback. Hence they send a 183 just to keep the PSTN timer happy and expect the GW to just relay the Progress to PSTN. Microsoft understands that the caller will hear silence (no ringback will be played to caller) till the IOS GW sees a 180 or a 183 w/SDP from OCS. This delay could exceed 5 seconds in complex deployments.

Description of the fix
++++++++++++++++++++++++
Now when 183 without any application body is received, we pass it on the CCAPI with PI=0 value. This message is passed on to other leg to just relay PROGRESS towards the ISDN end and Progress equivalent message towards the SCCP Phone and 183 without sdp towards the OGW or SIP Phone in case of CUBE and CUCME.

Thanks,

Glenn