CUCM 6.1(2) with OCS integration call forwarding failures
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
Re: CUCM 6.1(2) with OCS integration call forwarding failures
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...