Packetizer

SIP OPTIONS "Ping" (Q122)


The information in this article applies to: SIP, POCS-1

Devices in a SIP network like proxies, SBCs, and other devices need an efficient means of forwarding calls to a next-hop device. Unfortunately, there is no means of knowing whether a neighboring device is alive or dead, or whether the neighboring device is willing or able to accept calls.

Some have asserted that the REGISTER method is the right way to do that, and it is in some cases. Unfortunately, it is not the right solution in all cases. A small business with a single PBX connected to a SIP-based service provider over a SIP trunk might REGISTER with the service provider. It is a little "odd", though, since a REGISTER message is supposed to be sent from the user agent that represents a user (i.e., the user's phone). So, to send a REGISTER message is not quite right. Nonetheless, it is a workable solution. What if that business is a bigger enterprise with two or three interfaces to different service providers, perhaps interconnecting through SBCs? Suddenly, the REGISTER approach does not work very well at all. Who is registering? And what does the REGISTER message even mean?

A de facto standard that has emerged in the industry to address this problem is the use of the OPTIONS message between two devices. What is important when routing calls is whether the next-hop device is capable and able to accept calls. So, a PBX can send an OPTIONS message periodically to SBCs. Likewise, SBCs can send OPTIONS messages to peer SBC devices. If the response is a 200 from the peer, that indicates that the signaling path is good.

If a peer device is unable to accept calls, it returns a 503 to indicate that service is unavailable. This may be the result code returned because the responding device cannot process requests (e.g., it has been placed into maintenance mode or is overloaded) or perhaps because that is the response it is receiving from its upstream neighbor. By passing the upstream status downstream, it is possible to determine that, not only is the next hop not useable, but there is a failure further into the network that renders a given path inaccessible. Likewise, reporting the downstream status upstream would allow a service provider, for example, to know whether a route into an enterprise is accessible.

This mechanism is known in the industry as an OPTIONS "ping" and is widely supported by equipment manufacturers. It is a very lightweight mechanism that provides a lot of utility and helps to significantly reduce call setup delays due to failure of intermediate network elements or network connections.

A complete formal specification for use of the SIP OPTIONS Ping is documented in POCS-1.