<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Carlos,<br>
<br>
Dropping 1 packet is not going to cause phone unregistration. You will
have to drop several packets. The phone will retransmit 5 times and
await response.<br>
<br>
However, since you have 7940/60 there you will be subject to another
limitation, namely CSCsb39178. Basically the 7940/60 flushes (purges)
tcp buffers for every out of order TCP segment. This means the phone
purges valid data that is already received if any part is received out
of order. All data that was purged must be retransmitted.<br>
<br>
So the issue could be reordering, or it could be packet drop. Anyone
at the UK site have a 3rd gen phone? How does it perform?<br>
<br>
/Wes<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:CarlosOrtiz@bayviewfinancial.com">CarlosOrtiz@bayviewfinancial.com</a> wrote:
<blockquote
cite="mid:OFD870957F.680ABE42-ON852573E6.006C59C6-852573E6.006CFF58@bftg.com"
type="cite"><br>
<font face="sans-serif" size="2">Wes,</font>
<br>
<br>
<font face="sans-serif" size="2">Thanks for the extra info - makes
sense.
The phones I have in the UK are 7960's and my phone is a 7961.
This actually occured between myself and someone in the UK` earlier
today. Here are the rough stats of me pinging this phone for about
15 minutes.</font>
<br>
<br>
<font face="Courier New" size="2">Ping statistics for 10.X.X.X:</font>
<br>
<font face="Courier New" size="2"> <b>Packets: Sent = 1434,
Received = 1429, Lost = 5</b> (0% loss),</font>
<br>
<font face="Courier New" size="2">Approximate round trip times in
milli-seconds:</font>
<br>
<font face="Courier New" size="2"> Minimum = 133ms, Maximum
= <b>780ms</b>, <b>Average = 166ms</b></font>
<br>
<br>
<br>
<font face="sans-serif" size="2">If I were to get a packet drop on
one
of these SCCP acks, would that basically kill the connection since the
other device would not continue the conversation? Hence leading me to
the
"CM Down, Features disabled" message?</font>
<br>
<br>
<font face="sans-serif" size="2">My only recourse at this point is to
tell them we need a more reliable connection, correct? </font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<table width="100%">
<tbody>
<tr valign="top">
<td width="40%"><font face="sans-serif" size="1"><b>Wes Sisk
<a class="moz-txt-link-rfc2396E" href="mailto:wsisk@cisco.com"><wsisk@cisco.com></a></b>
</font>
<p><font face="sans-serif" size="1">02/05/2008 02:15 PM</font>
</p>
</td>
<td width="59%">
<table width="100%">
<tbody>
<tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">To</font></div>
</td>
<td><font face="sans-serif" size="1"><a class="moz-txt-link-abbreviated" href="mailto:CarlosOrtiz@bayviewfinancial.com">CarlosOrtiz@bayviewfinancial.com</a></font>
</td>
</tr>
<tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">cc</font></div>
</td>
<td><font face="sans-serif" size="1">Robert Kulagowski
<a class="moz-txt-link-rfc2396E" href="mailto:rkulagow@gmail.com"><rkulagow@gmail.com></a>,
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a></font>
</td>
</tr>
<tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">Subject</font></div>
</td>
<td><font face="sans-serif" size="1">Re: [cisco-voip]
Phone Keepalives</font></td>
</tr>
</tbody>
</table>
<br>
<table>
<tbody>
<tr valign="top">
<td>
<br>
</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
<font size="3">Carlos,<br>
<br>
'Registration' and timing appears to be topic-de-jure, this is the 4th
conversation about it already today. <br>
<br>
There are at least 2 factors at play when it comes to registration.
Let
me expand on those:<br>
1. TCP session errors - SCCP/Skinny works over TCP/IP. When TCP
transmits
a segment that segment must be acknowledged by the peer. In the case
of an SCCP keepalive exchange:<br>
phone cm<br>
-> sccp ka <br>
<- tcp ack<br>
< sccp ka ack<br>
-> tcp ack<br>
<br>
Normal TCP retransmit rules apply. Normal TCP session management
also apply. TCP FIN/RST can abort the session. ICMP messages such
as host unreachable, net unreachable, port unreachable, may also apply.
Otherwise the phone/CM will retransmit until TCP MaxRetransmits.
On the 7940/60 TCP will retransmit up to 5 times for a maximum of
15 seconds (this was the last value i have documented, it may have
changed).
On the 3rd gen phones 7941,61,70,71,42,62, etc the maximum retransmit
time is much shorter. I've seen reports as short as 4 retransmits each
after 300 ms (less than 2 seconds total). I do not have hard numbers
handy on those.<br>
<br>
If you have an outage of 15 seconds at the exact instant when phone
needs
to send SCCP keepalive then the phone is going to unregister and report
"CM down features disabled". The TCP/IP network must be
stable and working.<br>
<br>
2. keepalive errors - This is complete implemented at the SCCP level,
so
above TCP. CM allows missing 2x keepalives from the phone, most SCCP
endpoints support missing 1 SCCP KeepAliveAck from CM. These are
not universally supported as seen in CSCef31887.<br>
<br>
The vast majority of time we see:<br>
Phone believes it failed because of TCP timeout, TCP reset, or TCP fin.
This is normal since the phone is responsible for initiating SCCP
KA. It has to send data over the network and has to receive a response.<br>
CM believes the phone failed because of "device initiated reset"
or "keepalive timeout". "device initiated reset"
is a misnomer, see CSCsa66536. CM is sitting waiting to receive SCCP
KA from the phone. When the phone does not send then CM aborts the
session. Note CM institutes timeout at the SCCP level (~90 seconds)
while the phone institutes timeout at the TCP level (~15 seconds).<br>
<br>
/Wes<br>
</font><font color="blue" size="3"><u><br>
</u></font><a moz-do-not-send="true"
href="mailto:CarlosOrtiz@bayviewfinancial.com"><font color="blue"
size="3"><u>CarlosOrtiz@bayviewfinancial.com</u></font></a><font
size="3">
wrote: </font>
<br>
<font face="sans-serif" size="2"><br>
Not the case here as this Subscriber has many other phones registered
is
the US with no problems. As Wes said,I suspect a network issue, but
I was hoping to change the keepalive timer for those phones to decrease
the chance that a single missed keepalive would cause the message to
appear
and invoke a failover. This way when a someone hangs up the phone
a failover would not be invoked automatically. That's my understanding
of the process anyway......</font><font size="3"> <br>
</font><font face="sans-serif" size="2"><br>
Carlos</font><font size="3"> <br>
<br>
</font>
<table width="100%">
<tbody>
<tr valign="top">
<td width="54%"><font face="sans-serif" size="1"><b>Robert
Kulagowski </b></font><a moz-do-not-send="true"
href="mailto:rkulagow@gmail.com"><font color="blue" face="sans-serif"
size="1"><b><u><rkulagow@gmail.com></u></b></font></a><font
face="sans-serif" size="1">
<br>
Sent by: </font><a moz-do-not-send="true"
href="mailto:cisco-voip-bounces@puck.nether.net"><font color="blue"
face="sans-serif" size="1"><u>cisco-voip-bounces@puck.nether.net</u></font></a><font
size="3">
</font>
<p><font face="sans-serif" size="1">02/05/2008 11:50 AM</font><font
size="3">
</font></p>
</td>
<td width="45%"><br>
<table width="100%">
<tbody>
<tr valign="top">
<td width="19%">
<div align="right"><font face="sans-serif" size="1">To</font></div>
</td>
<td width="80%"><a moz-do-not-send="true"
href="mailto:cisco-voip@puck.nether.net"><font color="blue"
face="sans-serif" size="1"><u>cisco-voip@puck.nether.net</u></font></a><font
size="3">
</font></td>
</tr>
<tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">cc</font></div>
</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">Subject</font></div>
</td>
<td><font face="sans-serif" size="1">Re: [cisco-voip]
Phone Keepalives</font></td>
</tr>
</tbody>
</table>
<br>
<br>
<table width="100%">
<tbody>
<tr valign="top">
<td width="50%">
<br>
</td>
<td width="50%"><br>
</td>
</tr>
</tbody>
</table>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<font size="3"><br>
<br>
</font><font size="2"><tt><br>
Wes Sisk wrote:<br>
> sccp keepalive interval is a cluster wide parameter.<br>
> <br>
> Sounds like you definitely have spotty network connectivity. Have
to <br>
> stabilize that.<br>
<br>
But couldn't it also be a runaway process that's hogging CPU? I just
<br>
ran into a situation where a javaw process was spiking to 100% often <br>
enough that phones connected to that subscriber were showing "CM Down".<br>
_______________________________________________<br>
cisco-voip mailing list</tt></font><font color="blue" size="2"><tt><u><br>
</u></tt></font><a moz-do-not-send="true"
href="mailto:cisco-voip@puck.nether.net"><font color="blue" size="2"><tt><u>cisco-voip@puck.nether.net</u></tt></font></a><font
color="blue" size="2"><tt><u><br>
</u></tt></font><a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/cisco-voip"><font
color="blue" size="2"><tt><u>https://puck.nether.net/mailman/listinfo/cisco-voip</u></tt></font></a><font
size="3"><br>
</font>
<br>
<font size="3"><tt><br>
</tt></font>
<hr><font size="3"><tt><br>
_______________________________________________<br>
cisco-voip mailing list<br>
</tt></font><a moz-do-not-send="true"
href="mailto:cisco-voip@puck.nether.net"><font color="blue" size="3"><tt><u>cisco-voip@puck.nether.net</u></tt></font></a><font
size="3"><tt><br>
</tt></font><a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/cisco-voip"><font
color="blue" size="3"><tt><u>https://puck.nether.net/mailman/listinfo/cisco-voip</u></tt></font></a><font
size="3"><tt><br>
</tt></font>
<br>
</blockquote>
</body>
</html>