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

[Joe Loiacono]

Thanks Ryan and Anthony - very useful!

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

I'll be looking further at those ...

Thanks again,

Joe


From:   Ryan Huff <ryanhuff at outlook.com>
To:     Joe Loiacono/USA/CSC at CSC, "cisco-voip at puck.nether.net" 
<cisco-voip at puck.nether.net>
Date:   09/08/2016 11:11 PM
Subject:        Re: [cisco-voip] SIP Trunk Profile w/ Options Ping



Hi Joe,

The SIP Options Request (page 66-67 of RFC 3261 or page 29-30 of its 
predecessor RFC 2543) 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. 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/12f902ef/attachment.html>