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

Fri Jan 3 17:26:33 EST 2014

If he's not seeing this, it may be due to him null routing the node the H.323 signaling is using but not the node the phone is registered to.  Off the top of my head, I don't think the phone will be alerted in a scenario like that.  In order to make sure the users get the CM Down message, I'd make sure to use the same primary node for incoming/outgoing H.323 signaling as the IP Phones are using.

Brian

From: Erick Bergquist [mailto:erickbee at gmail.com]
Sent: Friday, January 03, 2014 5:14 PM
To: Pawlowski, Adam
Cc: Brian Meade (brmeade); cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] FW: h323 Call Preserve and features

I believe the phone should also say "CM down Features disabled" when the phone is up on a call still but loses connectivity to call manager if things are working correct. Are you seeing that on the phone display at all?

On Fri, Jan 3, 2014 at 3:57 PM, Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:
Brian, Wes,

      Thanks ! With that in mind it does seem to work. If it's a connectivity thing, and the UCM becomes reachable within a reasonable time frame, call control capabilities eventually resume, but it's not immediate and you would not know anyways from the end station. With that in mind, I was able to successfully set up preferenced dial peers and a couple of translation rules, so that calls to a targeted number will re-route back out to the PSTN to an alternate destination if the UCMs are not available, but the calls in progress stay alive. The rest of the calls get network failure and I get re-order or such from their local switch, so their clear off the PRI. While not as convenient to set up and operate, if the only goal is to shorten failure times, and provide for q931 through UCM loss, this does beat out MGCP. I have not evaluated other caveats of MGCP or de-centralizing our dial-plan control, but at least I know how this works now.

Thanks again all

Adam P

> -----Original Message-----
> From: Brian Meade (brmeade) [mailto:brmeade at cisco.com<mailto:brmeade at cisco.com>]
> Sent: Friday, January 03, 2014 4:35 PM
> To: Pawlowski, Adam; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: RE: [cisco-voip] FW: h323 Call Preserve and features
>
> 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<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<mailto: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<mailto:wsisk at cisco.com>]
> > > Sent: Friday, January 03, 2014 2:14 PM
> > > To: Pawlowski, Adam
> > > Cc: cisco-voip at puck.nether.net<mailto: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<mailto: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<mailto:cisco-voip at puck.nether.net>
> > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > >
> >
> >
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140103/f8ab22d2/attachment.html>