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

Fri Sep 9 15:44:46 EDT 2016

Hi Brian,

There is the SIP Debug Output Filtering Support<http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_SIP_Debug_Output_Filtering_Support> (also another great resource on the topic<https://supportforums.cisco.com/document/12570051/sip-debugging-commands-overview>) that you can read up on for IOS / IOS-XE. Essentially, it allows you to define a set of matching criteria that is matched in the output of the debug command that you choose; filtering out only that which matches your criteria. In full disclosure, I have never attempted to use this method to filter out the OPTIONS messages of a SIP conversation, so it may or may not be of any help. I can tell you that it can be frustrating to get the matching criteria to capture everything you want.

More to the point; I would, in almost all cases, recommend TranslatorX<http://translatorx.org/> ... it just makes it too easy (I became a fan once Paul offered native Linux support). In the case of ccsip messages (one of the more common SIP debug outputs) ... TranslatorX<http://translatorx.org/> makes filtering out the OPTIONS messages super simple; lower right corner of the GUI has a little checkbox to Exclude SIP OPTIONS messages ... POOF, gone. It makes accessing filtering options much easier too, IMO, than dealing with call filters in the CLI.

In many of my cases, what brought me to something like a debug ccsip messages output was a "it WAS working and now it is not" scenario. In those cases I have found speed is everything, especially to the client. For me, being able to clear CUBE's log buffer, make some test calls to reproduce and then copy out the debug sample and paste into TranslatorX is about as fast as it gets.

Hope this helps,

Ryan

________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Brian V <bvanbens at gmail.com>
Sent: Friday, September 9, 2016 2:42 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] SIP Trunk Profile w/ Options Ping

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><mailto:cisco-voip-bounces at puck.nether.net> on behalf of Joe Loiacono <jloiacon at csc.com><mailto:jloiacon at csc.com>
Sent: Thursday, September 8, 2016 9:24 PM
To: cisco-voip at puck.nether.net<mailto: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<mailto: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<mailto: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/6ee16500/attachment.html>