[cisco-voip] h323 Call Preserve and features

Mon Jan 6 13:18:23 EST 2014

Inline, ws.

On Jan 6, 2014, at 11:23 AM, "Pawlowski, Adam" <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:

Yes, that’s exactly right, I just null routed the CUCM from the gateway itself, I didn’t take the UCM down. I’d say bringing the UCM down is the more likely failure scenario (reboot/patch/crash) than any such thing with the uplink from the voice router, as that’s sufficiently diverse.

There seems to be a purposeful option to tell the UCM not to tear down the call when the TCP control session dies off, that it could do something with that information, though I’m not sure what.

ws: by enabling preservation and h225/h245 TCP keep alive UCM should identify the h323 call control session is lost and update the phone status to "CM Down, Features Disabled". I believe that text is customizable so perhaps someone has changed it in your environment. That update would also disable supplementary services such as hold and transfer.  Note that that will only happen after TCP keep alive timeout (after TCP max retransmits exceeded, and TCP ack timeout expired). While those retries are in progress UCM is unaware the call control session is lost so the phone stays in "normal" state with normal functionality. Attempting hold/transfer will invoke h323 signaling which will also go through TCP timeout and eventually fail. That is the nature of the transient state with two "intelligent" endpoints.

Assuming that another UCM node cannot assume control of the call (I don’t know enough of h323 to know if that’s possible) there’s probably not much to do.

ws: Correct, another UCM cannot assume control of that call. With MGCP the gateway can report the DS0 status to the failover UCM so the secondary UCM can assume management of the call on that DS0.

It would be nice if I were in a perfect world scenario, and I could configure the dial-peers to route the calls to the UCM that holds the DN that belongs to the phone that’s (normally) registered to it, so the phone would see the UCM down message and the softkeys would clear. That’s not reasonable, though. At least in this case, for planned maintenance I can shut down the dial-peer ahead of time to allow for normal clearing and a higher preference peer to be used, and then reload the UCM when it’s not going to cause this issue.

I’ll go play with SIP and see what that does for us, if anything different.

Thanks again for all the replies.

Adam P
SUNYAB

From: Ryan Ratliff (rratliff) [mailto:rratliff at cisco.com<http://cisco.com>]
Sent: Saturday, January 04, 2014 4:30 PM
To: Brian Meade (brmeade)
Cc: Erick Bergquist; Pawlowski, Adam; cisco-voip voyp list
Subject: Re: [cisco-voip] h323 Call Preserve and features

I believe what he was doing was breaking the routing between the gateway and CUCM, not the phone and CUCM.

As has been noted already I'd agree that the goal for any preserved call is for media to stay up.  Ideally if the ccm service can detect the signaling connection to the peer is down it can notify the endpoint(s) that the call has been preserved (so they can disable features).  In this case the call is going great until the endpoint tries to do something that will use the signaling channel (ie hold).  This is going to cause CUCM to try an send an empty TCS to the gateway, which of course will fail.  Absent special handling for the preserved call this media exchange will fail, triggering the hold to fail, and thus the call.  If TCP keepalives are enabled for both H.225 and H.245 then there's at least a chance ccm and the gateway can preserve the call, otherwise there won't be any packets sent on either TCP session and thus no way for either side to even know the connection is down until it's too late.

The only protocol I'm aware of now that will actually tell the phone when a call is preserved because the remote gateway is unregistered is MGCP, though for the life of me I can't remember the exact error message that shows on the phone.  Whether this same message will show up for a preserved SIP or H.323 call is a very good question, and a good enhancement if it's not.

-Ryan

On Jan 3, 2014, at 5:26 PM, Brian Meade (brmeade) <brmeade at cisco.com<mailto:brmeade at cisco.com>> wrote:

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

_______________________________________________
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/20140106/a3b99c8c/attachment.html>