<font size=2 face="sans-serif">Thanks Ryan and Anthony - very useful!</font>

<br>

<br><font size=2 face="sans-serif">I did have two special case SIP trunks

that would not come back to life after putting that option on their SIP

profile. One was between two CM clusters. And the other was an "Aggregation"

trunk pointing to IP address 1.1.1.1 (which is not pingable so that makes

sense.)</font>

<br>

<br><font size=2 face="sans-serif">I'll be looking further at those ...</font>

<br>

<br><font size=2 face="sans-serif">Thanks again,</font>

<br><font size=2 face="sans-serif"><br>

Joe</font>

<br>

<br>

<br><font size=1 color=#5f5f5f face="sans-serif">From:      

 </font><font size=1 face="sans-serif">Ryan Huff <ryanhuff@outlook.com></font>

<br><font size=1 color=#5f5f5f face="sans-serif">To:      

 </font><font size=1 face="sans-serif">Joe Loiacono/USA/CSC@CSC,

"cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net></font>

<br><font size=1 color=#5f5f5f face="sans-serif">Date:      

 </font><font size=1 face="sans-serif">09/08/2016 11:11 PM</font>

<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    

   </font><font size=1 face="sans-serif">Re: [cisco-voip]

SIP Trunk Profile w/ Options Ping</font>

<br>

<hr noshade>

<br>

<br>

<br><font size=3 face="Calibri">Hi Joe,</font>

<br>

<br><font size=3 face="Calibri">The SIP Options Request (</font><a href=https://www.ietf.org/rfc/rfc3261.txt><font size=3 color=blue face="Calibri"><u>page

66-67 of RFC 3261</u></font></a><font size=3 face="Calibri"> or </font><a href=https://tools.ietf.org/html/rfc2543><font size=3 color=blue face="Calibri"><u>page

29-30 of its predecessor RFC 2543</u></font></a><font size=3 face="Calibri">)

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. </font>

<br>

<br><font size=3 face="Calibri">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.</font>

<br>

<font size=3 face="Calibri">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. </font>

<br>

<br><font size=3 face="Calibri">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.</font>

<br>

<br><font size=3 face="Calibri">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. </font>

<br>

<br><font size=3 face="Calibri">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).</font>

<br>

<br><font size=3 face="Calibri">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 href=http://translatorx.org/><font size=3 color=blue face="Calibri">TranslatorX</a><font size=3 face="Calibri">.

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>".</font>

<br>

<br><font size=3 face="Calibri">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.</font>

<br>

<br><font size=3 face="Calibri">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.</font>

<br>

<br><font size=3 face="Calibri">-Ryan</font>

<br>

<p>

<hr>

<br><font size=2 face="Calibri"><b>From:</b> cisco-voip <cisco-voip-bounces@puck.nether.net>

on behalf of Joe Loiacono <jloiacon@csc.com><b><br>

Sent:</b> Thursday, September 8, 2016 9:24 PM<b><br>

To:</b> cisco-voip@puck.nether.net<b><br>

Cc:</b> cisco-voip<b><br>

Subject:</b> [cisco-voip] SIP Trunk Profile w/ Options Ping</font><font size=3 face="Calibri">

</font>

<br><font size=3 face="Calibri"> </font>

<br><font size=2 face="sans-serif">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><font size=3 face="Calibri">

<br>

</font><font size=2 face="sans-serif"><br>

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><font size=3 face="Calibri">

<br>

</font><font size=2 face="sans-serif"><br>

Was wondering what people have found as a 'best practice' along these lines

...</font><font size=3 face="Calibri"> <br>

</font><font size=2 face="sans-serif"><br>

Thanks,</font><font size=3 face="Calibri"> </font><font size=2 face="sans-serif"><br>

<br>

Joe Loiacono<br>

<br>

Global Infrastructure Services | m: +1-410.300-3804 | jloiacon@csc.com

| </font><a href=www.csc.com><font size=2 color=blue face="sans-serif"><u>www.csc.com</u></font></a><font size=2 face="sans-serif"><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>

<br>