Call Survivabilty in CUCM 7.1.3

[russell.sage]

I have am currently testing a new cluster being depolyed. I have IP trunks running H.323 from a subscriber to a carriers softswitch. I have a SCCP phone registered to another subscriber. I establish a call across the softswitch to an external address.

I then simulate a failure of the Phone subscriber by shutting down the network interface on the switch.

Why does call manager tear down the call. The H.323 trunk is still up and working. Once the RTP stream is established shouldn't call manager display CM DOWN on the phone and all features stop working but I see no reason as to why the RTP and hence the call should survive. Or am I mixing up H.323 and MGCP behaviour

[William Bell]

Call preservation is inherent with MGCP and SCCP. With H.323, you have to do

a few things. On the CUCM you have to configure the "Allow Peer to Preserve

H.323 Calls" parameter. This is a Call Manager service parameter (show

Advanced).

On a Cisco voice gateway, you can also use the H.323 "call preserve" config

options:

http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_h323_configuration_guide/old_archives_h323/4gwconf.html#wp1149764

For call preservation to work with H.323, all agents involved in the call setup and call maintenance need to be able to preserve the call.  In the CUCM case, this is accomplished by telling the CUCM to "not" send a release complete when a call failure is detected. There is a danger here. You must have a reliable way to detect when a call should be terminated when there is not call signaling channel.  The H.323 config guide above goes into this some.

HTH.

Regards,
Bill

Message was edited by: William Bell  (I hit send too soon!!!)

[russell.sage]

William

Thank you very much for the advice. I activated the Advanced Service Parameters you suggested and interestingly the CUCM doesn't send the H.225 Release Complete Message but it does send a H.225 RAS Disengage Request to the peer who promptly sends a H.225 Release Complete Message back to the Call Manager which effectively clears the call.

Cisco TAC are scratching their heads but this smells like a bug to me as I cannot see why the call manager would send a H.225 RAS when it this parameter is set.

Any experience of this.