SIP is basically a call and response protocol. You send a message. You get a response. In some situations, you may even get several responses for a single message.
Case in point is an INVITE transaction. A single INVITE request typically receives three responses and it’s not impossible for it to receive more. However, with most other SIP requests, a single response is received for every message sent.
A SIP response is more than simply an acknowledgement to a request. It can, and often does, carry a lot of useful information from the user agent server (UAS) back to the user agent client (UAC). For instance, a 200 Ok typically carries session description protocol (SDP) and therefore a list of codecs that the UAS supports. A 302 Moved Temporarily provides next-hop routing information. A 401 Unauthorized is used to pass the data needed to encrypt a UAC’s credentials.
Response messages fall into one of six types and those types are subsequently divided into two categories. The categories are either Provisional or Final. The types are identified by a three-digit number where the first digit indicates the class of the response.
There is also human readable text associated with every response code. This Reason Phrase is never processed by a SIP stack. It’s simply there for you to read. SIP stacks deal only with the three-digit number.
Several Provisional responses can be sent by the UAS up to the point of session establishment. Provisional responses begin with a 1.
Final responses begin with a 2, 3, 4, 5, or 6. A single Final response indicates that the session has been established (success) or the session never will be established (redirection or error).
For example, 182 Queued is a Provisional response. I know that because the leading digit is 1. The UAC might receive several 182 Queued responses as the call goes through various levels of queuing.
415 Unsupported Media Type is a Final response. I know that because the leading digit is 4. Only one Final response will be sent to the UAC for a single session. Upon receipt of the 415 Unsupported Media Type, session establishment will stop and the UAC will respond with an ACK.
The following table graphically shows what I just explained.
Let’s take a deeper look at each type starting with the 1xx responses.
1xx Response Codes
The 1xx responses are the Informational responses. As I stated earlier, they are sent while a session is being established and you can receive more than one of them.
181 Call is Being Forwarded
183 Session in Progress
199 Early Dialog Terminated
A 100 Trying is sent to indicate that the request is being processed. It will subsequently stop the SIP retransmission timer.
For a deep dive into 180 Ringing and 183 Session in Progress, please see my article, SIP Media Management: Early Media vs. Late Media.
2xx Response Codes
The 2xx responses are the Success responses. They are used to indicate that a SIP request was successfully processed. Of these, the 200 Ok is the most common. The 202 Accepted is used in REFER processing. I have never witnessed a 204 No Notification outside of SIP documentation.
204 No Notification
3xx Response Codes
The 3xx responses are the Redirection responses. They are used to inform the UAC of a different route to get to the UAS. Of these, 301 Moved Permanently and 302 Moved Temporarily are the workhorses.
I like these responses so much that I blogged about them in Move it on Over – SIP Redirection.
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternate Service
4xx Response Codes
The 4xx responses are the Client Error responses. They are used to indicate that something went wrong while processing the message. They can come from the UAS or a network SIP element in the path to the UAS.
There are far more 4xx responses than I care to document in this article, so I will just list a few of the most common.
One response should look very familiar to you. 404 Page Not Found is what you see if you attempt to browse to a webpage that doesn’t exist. The fact that the same response code is used for both web browsing and SIP should not be surprising. SIP is based on the language of the web – HTTP.
400 Bad Request
404 Not Found
407 Proxy Authentication Required
408 Request Timeout
415 Unsupported Media Type
5xx Response Codes
The 5xx responses are the Server Error responses. They are generated by the likes of proxy servers, location servers, and redirect servers.
500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-Out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure
Avaya has a unique use for the 503 Service Unavailable response. A Session Manager sends OPTIONS messages to its configured SIP entities to determine whether they are alive or not. A Communication Manager will reply with a 200 Ok if it’s active and processing calls and a 503 Service Unavailable is returned if it’s alive, but no gateways have registered to it. This allows Session Manager to mark a Communication manager as operational, but not up.
6xx Response Codes
The 6xx responses are the Global Error responses. They indicate that a server has definitive information about a particular user and not just the particular instance indicated by the Request-URI.
600 Busy Everywhere
604 Does Not Exist Anywhere
606 Not Acceptable
That’s All Folks
I hope this all made sense to you. SIP responses aren’t that difficult to understand, yet they can be used to create some very sophisticated services. Of course, that is the beauty of SIP – power in simplicity.
Thanks for the articles – they are well written.
“SIP is based on the language of the web – HTML.” – I think you might mean HTTP? The response codes are similar to HTTP response codes.
Ha! Thanks for catching my typo. Fixed now!
Hi there, I’m new to SIP so please bear with me. I’m a little confused here. So we know that 2xx is a final response and 1xx is provisional. In the case of 180, 183 and 200 response, all can carry SDPs.
Based on RFC 3261:
“The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.”
In my case, there are 2 responses being sent back for the initial invite:
183 with SDP
200 OK with SDP
Now the question is – which SDP will be considered as the final response?
By the way, the SDP on 183 and SDP on 200 OK are having different originator (o). First SDP has my media gateway IP as the originator and 2nd SDP has my CM IP.
The 183 and 200 will almost always have different SDP. One is typically an intermediary (183) and the the other is the actual endpoint (or endpoint proxy like an SBC). The SDP that will be used by the conversation will be in the 200 OK. The 183 media will be ring back, dial tone, re-order, etc.
Got it! Thanks Andrew! Appreciate it!
As per your comment above regarding the 503 message, Do you think is not possible to re-route to alternate destination an INVITE after receive the 503 message? I am trying to do that right now. I have configured two possible destinations in the dial pattern, the policies have diferent rank however the call is not being re-routed to the second policy.
There is nothing inherent in a 503 that would reroute an INVITE, but the UA could be programmed to send a new INVITE to a new destination. However, that is outside of SIP and in the realm of programming.
I can totally understand the flow of SIP messages in basic examples provided, but in my case, Media server sends INVITE to Avaya gateway and it replies with 180,200 SDP OK which is totally fine.! After a sec Avaya gateway sends INVITE message to my media server and even the media server replies with 200 SDP OK.
Now my question is why does the Avaya gateway sends an INVITE message? What is the use of UA sending INVITE msg to Server??
Any thoughts on this would be appreciated!!
Thanks in advance,
You may want to take a look at the “deep dive” article I wrote about Avaya SIP. Scroll down this page to find the article. Good luck. https://www.avaya.com/blogs/archives/author/andrew_prokop
I have observed multiple times, that 183 followed by final response like 500 server internal error etc. Because of that my switch don’t rehunt the call. It is normal to get 183 followed by error codes like 5xx or 4xx?
I wouldn’t call that normal. Does your system not support 183 and early media?
what should a client should expect if server sends 603 decline message ?
I would make sure you are dialing the right number. Check for funny characters.
first of all i’d like to tell you that i’m a fan of your blog. I’ve been using your blog for my personal reference to be honest.
I have a question, what is an acceptable time to respond an Invite with a 100 trying? is it has to be in miliseconds or several seconds is stil acceptable? i’ve been trying to read the RFC myself but i haven’t found it yet.
many many thanks in advance
Read this: https://andrewjprokop.wordpress.com/2013/07/02/understanding-sip-timers-part-i/
I am observing an issue, 503 response after 180/183. my supplier is giving me this response. i want to add two suppliers for a congested region call. would you please tell me in which case call can re-hunt?
I have had heard in the case of 503 after 180 calls can re-hunt to the second supplier whereas in the case of 183(SDP) it did not. can you please answer it.
Off hand, I don’t know why you can’t “re-hunt” to your alternate provider. Who is telling you that you can’t do that?