[VoiceOps] SIP OPTIONS PING

[Ryan Delgrosso]

I use this extensively from a lot of network elements.

Check frequency as a keep-alive, anywhere from 30 to 60 seconds is 
generally good BUT i strongly urge it be made configurable and not 
hard-coded, since if used for client trunk polling this can become 
overwhelming at scale if they are all on the same timer. If used in this 
fashion, I also recommend putting a random 1-1000ms delay in to prevent 
10,000 sip messages from hitting your border element all at once every 
30 sec.

As far as details go, I also recommend the following:

1: Make the from, to and request URI user part configurable. Metaswitch 
has these statically coded to be "metaswitch" which can cause 2 issues, 
the first is that if you are pinging out of your network you are 
revealing information about your infrastructure which is bad (but not so 
serious here), and the 2nd is if you are pinging a strict proxy like 
opensips, it will try to route the ping instead of responding to it 
locally (i am aware you can config opensips to fix this but its a silly 
workaround)

2: Allow the setting of hop-count to prevent unnecessary forwarding

3: If used for device heartbeats a failed ping should take a device 
down. A successful ping OR a successful call should bring a device up. 
Waiting for a successful ping to bring a device up can dramatically slow 
network convergence periods in the event of an interruption.

4: Existing media sessions should not be interrupted by a failed options 
ping, instead you should be using session timers or some other orphaned 
call detection to do cleanup there. Failed options pings should stop new 
dialogues from being established, but existing dialogues should survive 
or fail per-dialogue based on RFC 4028 or some other dialogue-centric 
method.

This is all based on nothing more than my own meandering experience and 
the readings from my sack of voodoo chicken bones.

-Ryan

On 06/25/2012 07:32 AM, Frank Bulk wrote:
> Does anyone have some real-world experience with SIP OPTIONS PING?  Our
> softswitch vendor is looking to implement support and seeking some input on
> check frequency, response timeouts, how quickly to check recheck on a down,
> and how long to wait after it's up before restoring the SIP trunk group.
> And should there be a ramp-up period through some kind of rate-limiting?
>
> If you have a product that does it well, what parameters does it use?
>
> How do you think the software should handle existing calls that may or may
> not have active media flows?  Should it tear down calls immediately, use
> some kind of active media detection, or wait x minutes before tearing down
> calls?
>
> Any input here or offline would be appreciated.
>
> Kind regards,
>
> Frank
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops