[cisco-voip] SIP Trunk Profile w/ Options Ping

[Ryan Huff]

Hi Joe,


The SIP Options Request (page 66-67 of RFC 3261<https://www.ietf.org/rfc/rfc3261.txt> or page 29-30 of its predecessor RFC 2543<https://tools.ietf.org/html/rfc2543>) 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.


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.


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.


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.


I usually 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.


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 X times at an interval of Y. The default value of (X,Y) is (6,500Ms).


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 not 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 TranslatorX<http://translatorx.org/>. 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, "show call history stats cps table".


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.


WOW ... an incredibly 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.


-Ryan


________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Joe Loiacono <jloiacon at csc.com>
Sent: Thursday, September 8, 2016 9:24 PM
To: cisco-voip at puck.nether.net
Cc: cisco-voip
Subject: [cisco-voip] SIP Trunk Profile w/ Options Ping

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

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'.)

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

Thanks,

Joe Loiacono

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

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160909/ea1be60b/attachment.html>