<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
I believe what he was doing was breaking the routing between the gateway and CUCM, not the phone and CUCM.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
<div>-Ryan </div>
<br>
<div>
<div>On Jan 3, 2014, at 5:26 PM, Brian Meade (brmeade) <<a href="mailto:brmeade@cisco.com">brmeade@cisco.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Brian<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Erick Bergquist [<a href="mailto:erickbee@gmail.com">mailto:erickbee@gmail.com</a>]
<br>
<b>Sent:</b> Friday, January 03, 2014 5:14 PM<br>
<b>To:</b> Pawlowski, Adam<br>
<b>Cc:</b> Brian Meade (brmeade); <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> Re: [cisco-voip] FW: h323 Call Preserve and features<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I believe the phone should also say "<span style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#333333">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? </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Jan 3, 2014 at 3:57 PM, Pawlowski, Adam <<a href="mailto:ajp26@buffalo.edu" target="_blank">ajp26@buffalo.edu</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Brian, Wes,<br>
<br>
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.<br>
<br>
Thanks again all<br>
<br>
Adam P<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
> -----Original Message-----<br>
> From: Brian Meade (brmeade) [mailto:<a href="mailto:brmeade@cisco.com">brmeade@cisco.com</a>]<br>
> Sent: Friday, January 03, 2014 4:35 PM<br>
> To: Pawlowski, Adam; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: RE: [cisco-voip] FW: h323 Call Preserve and features<br>
><br>
> Adam,<br>
><br>
> You're correct in that we're really only going to keep the media up and keep<br>
> the call connected in a call preservation scenario. Any extended features<br>
> such as hold/resume/transfer will have very strange behavior with the<br>
> signaling channel being down. In a call preservation scenario, both sides have<br>
> to disconnect the call due to the signaling being down as well.<br>
><br>
> Another thing to check with H.323 call preservation is what you have the<br>
> "Allow Peer to Preserve H.323 Calls" CallManager service parameter set to as<br>
> this is "False" by default.<br>
><br>
> Brian<br>
><br>
> -----Original Message-----<br>
> From: cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of<br>
> Pawlowski, Adam<br>
> Sent: Friday, January 03, 2014 4:16 PM<br>
> To: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: [cisco-voip] FW: h323 Call Preserve and features<br>
><br>
><br>
> I have now set "Accept Unknown TCP Connection" to true, and "Allow TCP<br>
> KeepAlives for H323" was left on true. I tried it on false, and it seems to have<br>
> the same behavior - media is preserved between endpoints for some period<br>
> of time (I did not wait excessively to see if it changes). Initially, soft functions<br>
> (hold, transfer) do not work. After some period of time I can press "hold" to<br>
> envoke hold, and I hear the hold tone, but resume does not work, and the<br>
> call clears from the phone. From the remote station, I continue to hear the<br>
> hold tone until the call drops off fast busy.<br>
><br>
> I have "call preserve" configured for the h323 voice class. I'm not really sure<br>
> there are other options - I believe the goal for this sort of thing is to allow<br>
> media to survive until connectivity to the same UCM is re-established, it is<br>
> not capable of allowing call control to migrate to another node in the cluster.<br>
> I'm not sure if that's correct or not, as to what it does.<br>
><br>
> Adam P<br>
> SUNYAB<br>
><br>
><br>
> > > -----Original Message-----<br>
> > > From: Wes Sisk (wsisk) [mailto:<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>]<br>
> > > Sent: Friday, January 03, 2014 2:14 PM<br>
> > > To: Pawlowski, Adam<br>
> > > Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> > > Subject: Re: [cisco-voip] h323 Call Preserve and features<br>
> > ><br>
> > > UCM has to know the h225 call control session is lost to properly<br>
> > > invoke<br>
> > call<br>
> > > preservation. The network has to fail in a way that allows this or<br>
> > > UCM has<br>
> > to<br>
> > > detect TCP session failure via keep alive timeout. That would be via<br>
> > > h225<br>
> > TCP<br>
> > > keepalives. Verify they are enabled:<br>
> > ><br>
> > > Service Parameter:<br>
> > ><br>
> > > Accept Unknown TCP Connection: This parameter specifies the valid<br>
> > > value as True or False. If the parameter is set to True, the system<br>
> > accepts<br>
> > > incoming TCP connection even when corresponding H323 gateway or<br>
> > > trunk profile is not found at the time of TCP connection<br>
> > > establishment;<br>
> > otherwise,<br>
> > > the system rejects TCP connection.<br>
> > > This is a required field.<br>
> > > Default: False<br>
> > > Allow TCP KeepAlives For H323: This parameter determines whether<br>
> > > Cisco CallManager sends KeepAlive messages to the H.323 device. When<br>
> > > IP connectivity between the originating voice gateway (which is<br>
> > > registered to Cisco CallManager as an H.323 endpoint) and Cisco<br>
> > > CallManager is lost,<br>
> > Cisco<br>
> > > CallManager does not send a disconnect message to the terminating<br>
> > > voice gateway after TCP KeepAlive timeout. This results in calls<br>
> > > being<br>
> > disconnected<br>
> > > on the originating side only and a blocked connection between Cisco<br>
> > > CallManager and the terminating gateway. When this parameter is set<br>
> > > to True, the terminating H.323 endpoint can clear a blocked<br>
> > > connection on a<br>
> > TCP<br>
> > > timeout. Valid values specify True (enable TCP KeepAlives for H.323)<br>
> > > or<br>
> > False<br>
> > > (disable KeepAlives). NOTE: Changing this parameter value affects<br>
> > > outbound calls immediately; you must restart the Cisco CallManager<br>
> > > service for the parameter change to take effect for inbound calls.<br>
> > > This is a required field.<br>
> > > Default: True<br>
> > ><br>
> > > -Wes<br>
> > ><br>
> > ><br>
> > > On Jan 3, 2014, at 8:45 AM, "Pawlowski, Adam" <<a href="mailto:ajp26@buffalo.edu">ajp26@buffalo.edu</a>><br>
> > wrote:<br>
> > ><br>
> > > I've been working with our PRI IOS gateways a bit, trying to improve<br>
> > > on MGCP's resilience in regard to service when the CUCM is down or<br>
> > > transitioning. We service a non-PSAP police department on our<br>
> > > campus, and they've asked the world of us in regard to never losing<br>
> > > a call. I don't<br>
> > think this<br>
> > > is possible, but, we've demonstrated to them how MGCP works, and<br>
> > > they're not satisfied. Presently, we have MGCP with 3 cucm nodes and<br>
> > > the shut- backhaul-interfaces command enabled. Calls will overflow<br>
> > > to our other<br>
> > trunk<br>
> > > group at another loc if the Ds are down here. The telco has not been<br>
> > > reasonable about establishing any other extended services (network<br>
> > > call redirect, DTO) to make that situation better, so while MGCP is<br>
> > > failing<br>
> > over<br>
> > > due to WAN/CUCM outage, calls are not terminated and die off.<br>
> > ><br>
> > > I have set a test gateway up with H323, which works (save for 5ESS<br>
> > > Fac IE CNAM which is fine), and have set up call preservation. Media<br>
> > > stays up<br>
> > when<br>
> > > I null route one CUCM or another, to simulate a CUCM reload or failure.<br>
> > > However, there's no reflection of a loss of call control from the<br>
> > > station<br>
> > (SCCP<br>
> > > 7965). If you attempt to invoke call hold or such, media ends, the<br>
> > > call<br>
> > does<br>
> > > not get held, and the call dies in place on the set (both ends - the<br>
> > remote call<br>
> > > off the gateway hangs in limbo too). At one point I hit transfer on<br>
> > > the<br>
> > set and<br>
> > > heard the hold tone when it opened a new call. Am I missing<br>
> > > something in configuration that the control of the call is never<br>
> > > re-established, or<br>
> > does not<br>
> > > seem to do so properly? Is this how this feature is intended to operate?<br>
> > ><br>
> > > Adam P<br>
> > > SUNYAB<br>
> > ><br>
> > > _______________________________________________<br>
> > > cisco-voip mailing list<br>
> > > <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> > > <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">
https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
> > ><br>
> ><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
https://puck.nether.net/mailman/listinfo/cisco-voip<br>
</div>
</div>
<br>
</div>
</body>
</html>