Understanding the SIP OPTIONS Request

Several years ago I bought my sons a set of walkie-talkies.

Some of you may remember that for a while they were huge with the teens and tweens. They were on every Christmas and birthday list. Of course, this was before cell phones effectively put an end to the fad.

Personally, I thought they were pretty cool and imagined all the fun I would have had with them back in my younger days. However, I soon learned that with my kids, wanting something and knowing what to do with it are two completely different things.

Instead of all the spy games I had envisioned for them, the vast majority of their conversations consisted of the following:

“Can you hear me?”

“Yes, I can. Can you hear me?”

“I can. Can you hear me now?”

Pretty sad, isn’t it? So much potential in their hands and they wasted it by running around executing quality of service tests.

Which brings me to what I want to write about today – the SIP OPTIONS request.

Related article: Rummaging Through the SIP Closet

OPTIONS allows a user agent (UA) to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without “ringing” the other party.

I imagine that when OPTIONS was first defined, the designers of SIP imagined all the great things people would do with it. After all, knowing what the other side is capable of is very powerful. OPTIONS could be used to set button states for the far-end client. For instance, you could gray out the transfer button if the far-end didn’t support REFER. You could also tailor the codecs you advertised if you already knew what the other side supported.

Knowing something about the far-end before you ever attempted a call could lead to a much better user experience.

For example, this OPTIONS message might be used to ask the far-end to respond back with the SDP it would typically send as part of an INVITE-200 Ok sequence.

OPTIONS sip:carol@chicago.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877

Max-Forwards: 70

To: <sip:carol@chicago.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: <sip:alice@pc33.atlanta.com>

Accept: application/sdp

Content-Length: 0

Note that the Accept header contains the value, application/sdp. This instructs the far-end to return SDP in the 200 Ok.

However, like my kids with their underused walkie-talkies, most implementations use OPTIONS as a SIP ping mechanism. “Are you there?” “Yes, I am.”

For example, when you configure SIP entities in an Avaya Aura Session Manager, there is a section called SIP Link Monitoring. You are presented with a variety of configuration options that allow you to choose how you want to ensure that a configured entity is up and active. This will ultimately result in how frequently OPTIONS messages are sent. If the entity responds with a 200 Ok, it is marked as active. If no 200 Ok is received, it is marked as down.

I have seen the exact same sort of configuration for Acme Packet SBCs. After a quick web search I find similar statements for Cisco, Sonus, AudioCodes, and Microsoft. Clearly, OPTIONS is universally used by everyone for pinging.

Don’t get me wrong.  Pinging is a good thing and I am glad that you can do it with SIP.  I would just like to see OPTIONS used for a little more than “Can you hear me.”  That’s not too much to ask, is it?  Well, is it?

Can’t you hear me?

Can you hear me, now?

* * *

This article originally appeared on SIP Adventures and is reprinted with permission.

Views All Time
Views All Time
Views Today
Views Today