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

Erick Bergquist erickbee at gmail.com
Fri Jan 3 17:13:33 EST 2014 

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> 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]
> > Sent: Friday, January 03, 2014 4:35 PM
> > To: Pawlowski, Adam; 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] 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
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/2045dc76/attachment.html>

More information about the cisco-voip mailing list