<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Is there a way to exclude the OPTIONS pings when debugging SIP in
IOS ?</p>
<p>For instance when using a <i>debug ccsip messages</i>, it would
be awesome if the OPTIONS messages could be excluded from the
debug output.<br>
</p>
<br>
<div class="moz-cite-prefix">On 9/8/2016 10:11 PM, Ryan Huff wrote:<br>
</div>
<blockquote
cite="mid:BLUPR18MB0482AF29A0AA4A3C3FD6BB4EC5FA0@BLUPR18MB0482.namprd18.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi Joe,</p>
<p><br>
</p>
<p>The SIP Options Request (<a moz-do-not-send="true"
href="https://www.ietf.org/rfc/rfc3261.txt">page 66-67 of
RFC 3261</a> or
<a moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc2543">page 29-30 of its
predecessor RFC 2543</a>) is a fantastic mechanism that is
often (and sadly) under used being reduced in many cases, to
something the tune of a, "can you hear me now" test. You would
think a mechanism with the capabilities of letting the other
side know exactly what can be supported, before a call is ever
made would lead to a fantastic and very resilient user
experience -and you'd be correct.
<br>
</p>
<p><br>
</p>
<p>In many cases a "ping" implementation is forged from the
Options Request stack simply because, if the request is
successful, will generate a response from the far end. For
many applications that use the Options Request stack in this
manner, the mere presence of a response from the far end is
considered 'proof' that the connection between peers is up.</p>
<p><br>
</p>
<p>Lets consider for a moment, what is "up"? Well, as long as I
have IP connectivity between two peers an the far-end is able
to listen and respond to SIP requests (responds with something
other than a 503 message), an 'OPTIONS Ping' would typically
be successful, but does that mean calls will be successful?
No, it does not. Although a typical "OPTIONS Ping" may
succeed, the two peers may not be configured to negotiate the
same codecs and if the requesting application is just looking
for the presence of a response, none would be the wiser until
someone tried to make a call through that link. <br>
</p>
<p><br>
</p>
<p>In the Communications Manager world, the OPTIONS Ping is
often used on SIP trunks to induce quicker failover within the
route group/list as Communications Manager will mark a trunk
as down if the last OPTIONS Ping was not successful and
Communications Manager will not send an INVITE to a peer
through a trunk marked "down"; thus avoiding the need to fool
with the "Stop Routing on ..." CCM Service Parameters (the
OPTIONS Ping yields little benefit if the route group only has
one egress method or the route list has one route group with
one egress method). By default Communications Manager will
wait 120 seconds before attempting an OPTIONS Ping against a
trunk previously marked as down.</p>
<p><br>
</p>
<p>I <i>usually</i> enable OPTIONS Ping on all carrier and
technology trunks as it gives Communications Manager a way to
track link state more efficiently. I say usually because there
are times when the OPTIONS Ping can generate more hassle than
it is worth (generally with carriers). I encountered a
scenario once where a carrier wasn't anticipating the
frequency of the OPTIONS request from the CPE (default of 60
seconds) and they were downing their end as a protective
measure .... sounds more like, "um, yeah we didn't have our
gear configured right" ... but OK Mr. Carrier, whatever you
say.
<br>
</p>
<p><br>
</p>
<p>I have also had a carrier ask me to increase the request
delay on successful pings (by default Communications Manager
will issue an OPTIONS Ping to the far-end of a SIP trunk every
60 seconds, if the last OPTIONS Ping was successful). Once the
first OPTIONS Request is not returned (SIP 408 ( timeout) ) or
SIP 503 is returned, Communications manager will then send an
OPTIONS Ping to the far-end
<i>X</i> times at an interval of <i>Y</i>. The default value
of (X,Y) is (6,500Ms).</p>
<p><br>
</p>
<p>By default, the Standard SIP Profile that is created in
Communications Manager when the cluster database is created
does not have the OPTION Ping capability turned on. Where I
have seen users elect
<i>not</i> to use the OPTIONS Ping capability is in cases of
diagnostic troubleshooting because OPTIONS Requests and
Responses will add to the ccsip message debugger output
-although this is easily controllable with a parser / log
reader like
<a moz-do-not-send="true" href="http://translatorx.org/">TranslatorX</a>.
Also, while I've never seen it be the reason a user has
decided not to use OPTIONS Ping, the OPTIONS Request is
tracked on the CPS table. You can bench test with, "<i>show
call history stats cps table</i>".</p>
<p><br>
</p>
<p>So yes, I would say OPTIONS Ping is "best practice, with a
nod to the carrier"; check with the carrier on carrier trunks
(especially if the carrier is a CLEC) just to make sure they
don't have any unusual requirements around the OPTIONS Request
stack.<br>
</p>
<p><br>
</p>
<p>WOW ... an <i>incredibly</i> long-winded response (might be
a P.R for me) to a question that could have likely been
answered in much shorter prose; hopefully it has been of some
assistance.</p>
<p><br>
</p>
<p>-Ryan<br>
</p>
<p><br>
</p>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
cisco-voip <a class="moz-txt-link-rfc2396E" href="mailto:cisco-voip-bounces@puck.nether.net"><cisco-voip-bounces@puck.nether.net></a> on
behalf of Joe Loiacono <a class="moz-txt-link-rfc2396E" href="mailto:jloiacon@csc.com"><jloiacon@csc.com></a><br>
<b>Sent:</b> Thursday, September 8, 2016 9:24 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Cc:</b> cisco-voip<br>
<b>Subject:</b> [cisco-voip] SIP Trunk Profile w/ Options
Ping</font>
<div> </div>
</div>
<div><font face="sans-serif" size="2">I have found the use of
the SIP profile w/ Options Ping useful as a barometer for
detecting network problems through alerts generated when
the SIP trunk goes down..</font>
<br>
<br>
<font face="sans-serif" size="2">However, when configuring a
group of them for a customer, I noticed that some of them
had previously been configured with the Ping option
explicitly disabled (as opposed to the more normal
'Standard SIP profile'.)</font>
<br>
<br>
<font face="sans-serif" size="2">Was wondering what people
have found as a 'best practice' along these lines ...</font>
<br>
<br>
<font face="sans-serif" size="2">Thanks,</font> <br>
<font face="sans-serif" size="2"><br>
Joe Loiacono<br>
<br>
Global Infrastructure Services | m: +1-410.300-3804 |
<a class="moz-txt-link-abbreviated" href="mailto:jloiacon@csc.com">jloiacon@csc.com</a> | </font><a moz-do-not-send="true"
href="www.csc.com"><font face="sans-serif" size="2">www.csc.com</font></a><font
face="sans-serif" size="2"><br>
<br>
This is a PRIVATE message. If you are not the intended
recipient, please delete without copying and kindly advise
us by e-mail of the mistake in delivery.
<br>
NOTE: Regardless of content, this e-mail shall not operate
to bind CSC to any order or other contract unless pursuant
to explicit written agreement or government initiative
expressly permitting the use of e-mail for such purpose.</font></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<br>
</body>
</html>