[cisco-voip] h323 Call Preserve and features

[Wes Sisk (wsisk)]

UCM has to know the h225 call control session is lost to properly invoke call preservation. The network has to fail in a way that allows this or UCM has to detect TCP session failure via keep alive timeout. That would be via h225 TCP keepalives. Verify they are enabled:

Service Parameter:

Accept Unknown TCP Connection:	This parameter specifies the valid value as True or False. If the parameter is set to True, the system accepts incoming TCP connection even when corresponding H323 gateway or trunk profile is not found at the time of TCP connection establishment; otherwise, the system rejects TCP connection.
 	This is a required field.
 	Default:  False
Allow TCP KeepAlives For H323: 	This parameter determines whether Cisco CallManager sends KeepAlive messages to the H.323 device. When IP connectivity between the originating voice gateway (which is registered to Cisco CallManager as an H.323 endpoint) and Cisco CallManager is lost, Cisco CallManager does not send a disconnect message to the terminating voice gateway after TCP KeepAlive timeout. This results in calls being disconnected on the originating side only and a blocked connection between Cisco CallManager and the terminating gateway. When this parameter is set to True, the terminating H.323 endpoint can clear a blocked connection on a TCP timeout. Valid values specify True (enable TCP KeepAlives for H.323) or False (disable KeepAlives). NOTE: Changing this parameter value affects outbound calls immediately; you must restart the Cisco CallManager service for the parameter change to take effect for inbound calls.
 	This is a required field.
 	Default:  True

-Wes


On Jan 3, 2014, at 8:45 AM, "Pawlowski, Adam" <ajp26 at buffalo.edu> wrote:

I've been working with our PRI IOS gateways a bit, trying to improve on MGCP's resilience in  regard to service when the CUCM is down or transitioning. We service a non-PSAP police department on our campus, and they've asked the world of us in regard to never losing a call. I don't think this is  possible, but, we've demonstrated to them how MGCP works, and they're not satisfied. Presently, we have MGCP with 3 cucm nodes and the shut-backhaul-interfaces command enabled. Calls will overflow to our other trunk group at another loc if the Ds are down here. The telco has not been reasonable about establishing any other extended services (network call redirect, DTO) to make that situation better, so while MGCP is failing over due to WAN/CUCM outage, calls are not terminated and die off.

I have set a test gateway up with H323, which works (save for 5ESS Fac IE CNAM which is fine), and have set up call preservation. Media stays up when I null route one CUCM or another, to simulate a CUCM reload or failure. However, there's no reflection of a loss of call control from the station (SCCP 7965). If you attempt to invoke call hold or such, media ends, the call does not get held, and the call dies in place on the set (both ends - the remote call off the gateway hangs in limbo too). At one point I hit transfer on the set and heard the hold tone when it opened a new call. Am I missing something in configuration that the control of the call is never re-established, or does not seem to do so properly? Is this how this feature is intended to operate? 

Adam P
SUNYAB

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip