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?
Tao, Zen, and Tomorrow 
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,
Matthias
Matthias, OPTIONS will have its own call-id. There is no association with an INVITE. An OPTIONS is its own transaction.
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 ?
Thanks
Matthias
I too agree with Matthias ..I have real world traces with SIP OPTIONS having the same Call ID as the INVITE..
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.
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.
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 ?
Luis
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.”
https://tools.ietf.org/html/rfc3261#section-12.2.1.1
Thanks,
Luis
You got there before I could! 🙂
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?
Here is an interesting discussion on that. http://www.ietf.org/mail-archive/web/sip/current/msg11168.html
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) ?
Thanks,
Miguel
Any answer for my question?
I want to know about SIP notify message. When and why this message occurs?
Look here. https://andrewjprokop.wordpress.com/2013/06/21/sip-subscribe-notify-and-publish/
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,
Use OPTIONS. It’s a widely used approach to do just what you are asking.
Hi how did you solve the issue we need to solve it with opensips and do not know how.
kr
kth
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!
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.
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.
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.
This is a pretty comprehensive article on that. http://www.voip-info.org/wiki/view/NAT+and+VOIP
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?
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.
Regards,
Ronka
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.
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?
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
Grazie!
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.
KR
KTH
Thanks for sharing great knowledge..
A small doubt, Assume that device A and B are sending options to each other and device B is not repsonding for the options it is recienved from A. Even though A is not gettting a 200 OK from B, Will A can utilize the incoming options method to confirm that side B is active.
I suppose it could do that, but that would be at the application level. I would wonder why the other side wasn’t responding. Would I want to keep communicating with a flaky device?
Thanks for your quick response.
In our scenario, we have an SBC. where SBC is configured to not to repsond for side A options if Side B is not up. It will help the device on side to idnetify the status of complete path. But it is not working the way as it intented as SBC keep sending his options towards side A.
What i thought was option ping is one sided request and a device will assume the other end is down if it is not getting a repsonse for it option request irrespective of what ever else is happening around.
Options are great for failover scenarios (knowing when you need to) in redundant architectures
Can OPTIONS message be sent without IMS Registrations?
If yes, what should be response from the IMS Core.
Hello Andrew,
After call gets connected, i can see OPTIONS message from UAC to UAS every after 60 sec, and in response UAC is getting 200OK SDP, but here i want see a message or parameter which trigger UAC to send this OPTIONS message every after 60 sec, is their any parameter is sent/enable by the UAS , that forces UAC to send this OPTIONS message ?
None that I know of in the SIP protocol. This is something occurring at the application level.
Thanks Andrew , I asked this, as this was not regular for us, this i found in one of our onnet calls.
I have a query. Can option message will have multiple Accept header?
I tried to find it in the RFCs but no luck. Could you please help me?
As far as I know the answer is “no.”
Hello Andrew. I am facing an issue where incoming calls to my sip phone doesn’t reach sip phone as the mac aging time in the switch (somewhere in the network setup) is expired before the call. Eventually my sip phone doesn’t get the sip invite packet. I was looking for a keep alive method in SIP. Can I use SIP Options packet for the same or Is there any other packet for keep alive? Please suggest a sample capture link, if possible.
Options is the way to go. https://andrewjprokop.wordpress.com/2014/04/24/understanding-the-sip-options-request/
Being new in this type of communication and in a country where this technology is in the ambryonnary stage, I found your explanations are very practical. Many thanks
Hello Andrew. I am facing an issue where I am getting ‘503 Service Unavailable’ in response to OPTION. But still NE sending INVITE on same link even it is not available (due to 503, Link status—unavailable). This seems to be a wrong behaviour or we have to manually control this.
Hi,
what’s the reason for ‘Options’ query are coming from different IPs, instead of what we are configured.
Thank you.
Do you know what services are running on those IP addresses? Are they yours or outside your network?
How often should a device send the OPTIONS message ?…I usually saw that 60 seconds, but there is a minimum ? a maximum ?..a recommended period of time ?
I don’t know of a recommended time. It’s up to the application and its needs.
Hello Andrew,
When the server is undergoing maintenance it will reply 503 Service Unavailable to a SIP INVITE request.
Should we expect the same answer to a SIP OPTIONS request?
Thank you.
Probably. It depends on the server, but that’s what I would expect.
Hi first time I connected a device made call to that device, it was ringing and I cancelled the call . On second time I removed the device, again made call this time I am getting the a ICMP host unreachable packets along with SIP header and IP header with source and destination addresses are same suppose 192.168.1.1. what is this issue?