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.

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?


  1. Matthias · · Reply

    Is the SIP OPTIONS message an initiating message ( I mean, is it the first message with a new CallID) or must it be sent during an INVite dialog ?

    Best Regards,

    1. Matthias, OPTIONS will have its own call-id. There is no association with an INVITE. An OPTIONS is its own transaction.

      1. Matthias · ·

        I’m asking this, because I saw real life traces with OPTIONS “request” during the INVite signalling sequence with the same CALL-ID and now I’m asking myself if it is a protocol violation or not ?

  2. I too agree with Matthias ..I have real world traces with SIP OPTIONS having the same Call ID as the INVITE..

    1. I would love to see that trace. They are separate messages and there is no reason why they should be associated. I can send OPTIONS all day long without ever having to send an INVITE.

      1. Andrea Marinelli · ·

        Hi Andrew, yes you can, In that case, you are using the OPTIONS for link monitoring. But you can also use the OPTIONS for “call state” monitoring.

        Let’s suppose there is an active call (INVITE/200 OK/ACK) and you want to monitor the state of that call. You could use re-INVITE messages, of course. But you could also use in-dialog OPTIONS messages (i.e. OPTIONS with the same to-tag, from-tag, call-id, etc… of the original call).

        If the call is alive, the end-point must reply “200 OK”.
        Instead, if the call is dead, the end-point will reply “481 Call leg/transaction doesn’t exist”.

        In that way you are able to monitor the state of your calls.

      2. Hello,
        Regarding the question about OPTIONS messages having call-id of a real active call, using the call’s tags, I know it is possible, I have seen and used those scenarios. I have a question, though, maybe somebody knows.
        In that case, monitoring an active call, may a third entity (not any of those parties involved in the call) send an OPTIONS to any the parties involved ? I work at a company where we usually try this kind of “interesting scenarios”:
        I personally think it should be possible. For instance, I have used a third party to end calls using passive monitoring of signaling via port mirroring at the switch. As SIP entities look at SIP headers, it doesn’t really matter what the real IP address of the sender is. In that case, I have sent BYE requests from an external, third IP, to both parties with a VIA header pointing to that IP, and call ends perfectly, and 200 BYE are actually received by this third entity.

        But, I am not sure it works that way with OPTIONS.

        Anybody knows ?


      3. I answer to myself. Unfortunately what I proposed is not possible, because of the CSeq. The CSeq must increase by one for every new request in a given direction, and even if the third party knows which CSeq comes next, for instance, last used was “n”, it could use “n + 1”, but when the original party tries to send a new request it will also use “n + 1”, because it does now know a third entity send a message in between. And that is not allowed.

        Here is the responsible for this :

        “Requests within a dialog MUST contain strictly monotonically
        increasing and contiguous CSeq sequence numbers (increasing-by-one)
        in each direction (excepting ACK and CANCEL of course, whose numbers
        equal the requests being acknowledged or cancelled). Therefore, if
        the local sequence number is not empty, the value of the local
        sequence number MUST be incremented by one, and this value MUST be
        placed into the CSeq header field.”




      4. You got there before I could! 🙂

  3. Pradeep Nandam · · Reply

    Thanks for such a useful article.

    I have a doubt though.

    “Note that the Accept header contains the value, application/sdp. This instructs the far-end to return SDP in the 200 Ok.” => It is not really necessary for the far-end device to send SDP body in 200 OK response, right? As per my understanding, “Accept” just means the Agent that initiates SIP OPTIONS can handle SDP body. Am i missing something? Is there any such mentioning in RFC?

  4. I have one question regarding OPTIONS. In the Technical Specification ETSI TS 102 027-2 V4.1.1, there is one mandatory test (SIP_QC_TE_ V _004) stating that “Ensure that the IUT on receipt of an OPTIONS request with a TAG set on the To header, sends a Success (200 OK) including the same URI and the same TAG for the To header”. Is it correct? Isn’t possible to send 481 instead, like in the case of INVITE (SIP_CC_TE_CE_V_016) ?


    1. Any answer for my question?

  5. I want to know about SIP notify message. When and why this message occurs?

  6. Wally Rally · · Reply

    Indicated: 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 am interested in using this to query a UA, to see if it is still alive. Alive, in the sense that it is reachable from the network. For example, a UA on a smartphone, and the network has become very weak. Before attempting to INVITE or other, I would like to query to see if it is reachable. Therefore, I would like to know how to query the UA from the UA I am using.

    Thanks in advance,

    1. Use OPTIONS. It’s a widely used approach to do just what you are asking.

    2. Hi how did you solve the issue we need to solve it with opensips and do not know how.

  7. Wally Rally · · Reply

    Thanks for the confirmation! This will help immensely in 2 scenarios:
    1. The user swipes the app from running without the app having a chance to gracefully shutdown letting the server know it is no longer running.
    2. The network goes out from underneath the app without the ability to gracefully communicate to the server.
    3. The user places their smartphone into airplane mode, and the same issue of no graceful showdown process is communicated to the server.

    All of these leave user thinking a user is still registered, but they aren’t, and presence is not even updated.

    Thanks fro you article!

  8. Devraj · · Reply

    Hi, i am getting option and 200 in one case:
    phone 1 calls lync and lycn forwards it to PSTN.while forwarding phone 1 doe not hear ring back tone and call is connected.
    question:why Phone 1 is not able to hear ringback.

    1. There is no way I can figure that out over emails. It sounds like a NAT or codec mismatch. I suggest you do some traces to see if you can figure where it’s breaking.

  9. David Bukhan · · Reply

    It is a newbie question of course. In a peer-to-peer communication in a NAT’d environment when a UA receives an INVITE it needs to respond with an SDP containing IP addresses for incoming media. So it needs to make a decision on whether to put its private or public IP and it seems to depend on whether the INVITE came from inside or outside of the NATing firewall. Could OPTIONS be used to determine it? Before responding to the INVITE the UA would send an OPTIONS with a private IP in the Via header and wait for a response. If no response it will try OPTIONS with the public IP. Once it determines which IP to use it will respond with OK to the INVITE with the proper IP in the SDP.
    I have a feeling there are other methods for determining which IP to use in the SDP that I am not aware of. Your comments are greatly appreciated.

    1. This is a pretty comprehensive article on that. http://www.voip-info.org/wiki/view/NAT+and+VOIP

      1. David Bukhan · ·

        It is a very good article indeed. But while it describes how to deal with NAT and how to discover a public address it does not answer how to determine if a public or private address has to be used to begin with. In other words how would the UA know if the INVITE came from a LAN or outside-LAN device?

  10. Ronak · · Reply

    Hello Andrew,

    I have Panasonic NS1000 PBX, it does not respond to SIP OPTIONS, thus not allowing ITSP to run failover, based on your experience, what other terms are used by IP PBX to for this service?

    This is a basic feature and I believe it should be supported by Panasonic.


    1. About the only thing I can think of off the top of my head is the carrier sends the Panasonic a call and that call times out. There isn’t much else it could do if it can’t send Options messages.

  11. So I’m a bit confused..We’ve been talking about the OPTIONS header in regards to doing other things..but where is it documented what the options actually are? Where in the packet does the other side actually answer with what it can do? Is it in the “Supported” field? These options are provided in an INVITE as well as the OPTIONS requests correct?

  12. Sir I’m really in-love with your articles
    Thank you very much or as we call it in Deutsch “vielen dank”

    Wish you all the best

  13. Hi There
    interesting article, we have inheritat a opensips platform and we need to ping UA on demand same issue like Wally Rally but we do not know how, can someone point us in the right direction please.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: