[cisco-voip] FW: h323 Call Preserve and features

[Brian Meade (brmeade)]

Adam,

You're correct in that we're really only going to keep the media up and keep the call connected in a call preservation scenario.  Any extended features such as hold/resume/transfer will have very strange behavior with the signaling channel being down.  In a call preservation scenario, both sides have to disconnect the call due to the signaling being down as well.

Another thing to check with H.323 call preservation is what you have the "Allow Peer to Preserve H.323 Calls" CallManager service parameter set to as this is "False" by default.

Brian

-----Original Message-----
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Pawlowski, Adam
Sent: Friday, January 03, 2014 4:16 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] FW: h323 Call Preserve and features


 I have now set "Accept Unknown TCP Connection" to true, and "Allow TCP  KeepAlives for H323" was left on true. I tried it on false, and it seems to have  the same behavior - media is preserved between endpoints for some period  of time (I did not wait excessively to see if it changes). Initially, soft functions  (hold, transfer) do not work. After some period of time I can press "hold" to  envoke hold, and I hear the hold tone, but resume does not work, and the  call clears from the phone. From the remote station, I continue to hear the  hold tone until the call drops off fast busy.
 
 I have "call preserve" configured for the h323 voice class. I'm not really sure  there are other options - I believe the goal for this sort of thing is to allow  media to survive until connectivity to the same UCM is re-established, it is  not capable of allowing call control to migrate to another node in the cluster.
 I'm not sure if that's correct or not, as to what it does.
 
 Adam P
 SUNYAB
 
 
> > -----Original Message-----
> > From: Wes Sisk (wsisk) [mailto:wsisk at cisco.com]
> > Sent: Friday, January 03, 2014 2:14 PM
> > To: Pawlowski, Adam
> > Cc: cisco-voip at puck.nether.net
> > Subject: Re: [cisco-voip] h323 Call Preserve and features
> >
> > 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
> >
> 
> 


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