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

Pawlowski, Adam ajp26 at buffalo.edu
Fri Jan 3 16:16:06 EST 2014


 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
> >
> 
> 




More information about the cisco-voip mailing list