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

Fri Sep 9 14:42:53 EDT 2016

Is there a way to exclude the OPTIONS pings when debugging SIP in IOS ?

For instance when using a /debug ccsip messages/, it would be awesome if 
the OPTIONS messages could be excluded from the debug output.

On 9/8/2016 10:11 PM, Ryan Huff wrote:
>
> 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.
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160909/dec10453/attachment.html>