On 06/25/12?09:32?-0500, 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.
We poll once every 60 seconds from our Metaswitch when communicating with unauthenticated (or authenticated by IP address) SIP trunk peers. I don't recall if that was a suggestion that we received, or if that was a value we picked. I do not know without digging into our switch documentation what occurs if one options response is not received, but most likely there would need to be two (or more) options statements missed before the sip binding goes into alarm and gets taken down. I suspect that the sip binding comes back up on the next response. In my observations, the contents of the SIP options response has no bearing. In fact, an error response (such as "not supported") is sufficient to keep the sip binding up, if I recall correctly. -- Dan White