SIP Response Codes Explained

Why don’t we start with some trivia?
Did you know that SIP response codes are based on HTTP/1.1 response codes?

Actually, SIP response codes are the extent of the original HTTP ones and even define a new class with more response codes. I’ll let you know which one when we get to it.

That said, not all of the HTTP codes are relevant and mapped to SIP response codes, so if you know some HTTP, don’t expect to find them all in this list.

I actually like to divide SIP response codes into two groups, final SIP responses, and non-final SIP responses. We go deeper into the subject in the SIP TS course, but I’ll go over the basics here.

---

1xx – Provisional SIP Response Codes

SIP Provisional responses, AKA informational responses,
indicate that the UA Server contacted has to perform some further action so it could come up with a final response.
As you can understand, 1xx provisional SIP responses are non-final.

One more thing to note here is that 1xx SIP responses are not transmitted reliably, thus, unlike for other response types, an ACK won’t be sent by the client.

100 Trying

This response indicates that the request has been received by the
UA server and that some unspecified action is being taken on
behalf of this call. (For example, a database is being consulted).

This response, like all other provisional responses, stops
retransmissions of an INVITE by a UAC.
The 100 (Trying) response is different from other provisional responses,
in that, it is never forwarded upstream by a stateful proxy.

180 Ringing

The UA receiving the INVITE (an IP Phone for example) is trying to alert the user of an incoming call.
The UA Client sending the INVITE will usually use the 180 Ringing to play a local ringback.

181 Call Is Being Forwarded

A server MAY use this status code to indicate that the call is being
forwarded to a different set of destinations.

182 Queued

The called party is temporarily unavailable, but the server has
decided to queue the call rather than reject it. When the callee
becomes available, it will return the appropriate final status
response.
The reason phrase MAY give further details about the status of the call,
for example, “5 calls queued; expected waiting time is 15 minutes”.
The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call.

183 Session Progress

The 183 (Session Progress) response is used to convey information
about the progress of the call.

In practice, if 180 Ringing is used to invoke local ringback on the calling party, the 183 Session Progress is a sign for the UA to try and receive a media stream (can be ringback or an announcement for example) from the remote party.

2xx Successful SIP Response Codes

The request was successful.

SIP Successful responses indicate that the SIP request was understood and accepted.
2xx responses are final and conclude a SIP transaction, and often, in a phone call, meaning that the receiving party has answered and is ready to send media.

And although this is the ultimate response, it doesn’t always mean that everything is working properly…

200 OK

The request has succeeded.
The information returned with the response depends on the SIP Request method.

So for a SIP INVITE, a 200 OK response might include, for example, SDP with media information.

3xx Redirection SIP Response Codes

The 3xx series responses mean that the request can’t be completed by this UA and Another UA has to be contacted to fulfill this request.

In simple words, this is a redirection response.
A redirection response will give information on the user’s new location or an alternative service that the caller has to use to complete the call.
For example, redirect you to a different port,
or provide information about the user’s new location or alternative services.

300 Multiple Choices

The address in the request resolved to several choices, each with its
own specific location and the user (or UA) can select a preferred
communication endpoint and redirect its request to that location.

The response MAY include a message body containing a list of resource
characteristics and location(s) from which the user or UA can choose
the one most appropriate, if allowed by the Accept request header
field. However, no MIME types have been defined for this message
body.

The choices SHOULD also be listed as Contact fields.
Unlike HTTP, the SIP response MAY contain several Contact fields or a
list of addresses in a Contact field. UAs MAY use the Contact header
field value for automatic redirection or MAY ask the user to confirm
a choice.

This status response is appropriate if the callee can be reached
at several different locations and the server cannot or prefers
not to proxy the request.

301 Moved Permanently

The user can no longer be found at the address in the Request-URI,
and the requesting client SHOULD retry at the new address given by
the Contact header field.
The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.

302 Moved Temporarily

The requesting client SHOULD retry the request at the new address(es)
given by the Contact header field.
The Request-URI of the new request uses the value of the Contact header field in the response.

The duration of the validity of the Contact URI can be indicated
through an Expires header field or an expires parameter in the Contact header field.
Both proxies and UAs MAY cache this URI for the duration of the expiration time.
If there is no explicit expiration time, the address is only valid once for
recursing, and MUST NOT be cached for future transactions.

If the URI cached from the Contact header field fails, the Request-URI from the redirected request MAY be tried again a single time.

The temporary URI may have become out-of-date sooner than the
expiration time and a new temporary URI may be available.

305 Use Proxy

The requested resource MUST be accessed through the proxy given by
the Contact field.
The Contact field gives the URI of the proxy.
The recipient is expected to repeat this single request via the proxy.
305 (Use Proxy) responses MUST only be generated by UASs.

380 Alternative Service

The call was not successful, but alternative services are possible.

The alternative services are described in the message body of the
response. Formats for such bodies are not defined here and maybe
the subject of future standardization.

4xx Request Failure SIP Response Codes

The 4xx series of responses are client errors.
They officially mean that The request may contain some bad syntax or parameter and can’t be processed by this server.
We will get this kind of responses if the destination is busy for example,
in which case we will get ‘486 busy here’ response.
If the number is bad or doesn’t exist we will get 404 not found.
If your request doesn’t include the proper credentials you may get 401 unauthorized and so on.

SIP 4xx responses are definite failure responses from a particular server.
The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization).

400 Bad Request

The request could not be understood due to malformed syntax.
The Reason-Phrase SHOULD identify the syntax problem in more detail,
for example, “Missing Call-ID header field”.

401 Unauthorized

The request requires user authentication. This response is issued by
UASs and registrars, while 407 (Proxy Authentication Required) is
used by proxy servers.

This is a client error that we will see with certain ITSPs and CUBE or SBC, and this is normal as this is the cue for an SBC to send an authenticated request.

402 Payment Required

Reserved for future use.

403 Forbidden

The server understood the request but is refusing to fulfill it.
Authorization will not help, and the request SHOULD NOT be repeated.

This can happen when you’re trying to get services from a server that doesn’t recognize you.

404 Not Found

The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request.

In other words, when you are trying to call a number that doesn’t exist or match in the call routing table of the server. CoS can also trigger the 404 Not Found response.

405 Method Not Allowed

The method specified in the Request-Line is understood, but not
allowed for the address identified by the Request-URI.

The response MUST include an Allow header field containing a list of
valid methods for the indicated address.

406 Not Acceptable

The resource identified by the request is only capable of generating
response entities that have content characteristics not acceptable
according to the Accept header field sent in the request.

407 Proxy Authentication Required

This code is similar to 401 (Unauthorized) but indicates that the client MUST first authenticate itself with the proxy.

This status code can be used for applications where access to the
communication channel (for example, a telephony gateway) rather than
the callee requires authentication.

408 Request Timeout

The server could not produce a response within a suitable amount of time.
For example, if it could not determine the location of the user in time.
The client MAY repeat the request without modifications at any later time.

410 Gone

The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be
considered permanent. If the server does not know or has no
facility to determine, whether or not the condition is permanent, the
status code 404 (Not Found) SHOULD be used instead.

413 Request Entity Too Large

The server is refusing to process a request because the request
entity-body is larger than the server is willing or able to process.
The server MAY close the connection to prevent the client from
continuing the request.

If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what
time the client MAY try again.

414 Request-URI Too Long

The server is refusing to service the request because of the Request-URI
is longer than the server is willing to interpret.

415 Unsupported Media Type

The server is refusing to service the request because of the message
body of the request is in a format not supported by the server for
the requested method. The server MUST return a list of acceptable
formats using the Accept, Accept-Encoding, or Accept-Language header
field, depending on the specific problem with the content.

416 Unsupported URI Scheme

The server cannot process the request because of the scheme of the URI
in the Request-URI is unknown to the server.

420 Bad Extension

The server did not understand the protocol extension specified in a
Proxy-Require or Require header field.
The server MUST include a list of the unsupported extensions
in an Unsupported header field in the response.

421 Extension Required

The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request.
Responses with this status code MUST contain a Require header field
listing the required extensions.

A UAS SHOULD NOT use this response unless it truly cannot provide any
useful service to the client. Instead, if a desirable extension is
not listed in the Supported header field, servers SHOULD process the
request using baseline SIP capabilities and any extensions supported
by the client.

423 Interval Too Brief

The server is rejecting the request because of the expiration time of
the resource refreshed by the request is too short. This response
can be used by a registrar to reject a registration whose Contact header field expiration time was too small.

480 Temporarily Unavailable

The callee’s end system was contacted successfully but the callee is
currently unavailable (for example, is not logged in, logged in but
in a state that precludes communication with the callee, or has
activated the “do not disturb” feature).
The response MAY indicate a better time to call in the Retry-After header field.
The user could also be available elsewhere (unbeknownst to this server).
The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA.
Status 486 (Busy Here) MAY be used to more precisely indicate a particular
reason for the call failure.

This status is also returned by a redirect or proxy server that
recognizes the user identified by the Request-URI but does not
currently have a valid forwarding location for that user.

481 Call/Transaction Does Not Exist

This status indicates that the UAS received a request that does not
match any existing dialog or transaction.

482 Loop Detected

The server has detected a loop.

483 Too Many Hops

The server received a request that contains a Max-Forwards header field with the value zero.

484 Address Incomplete

The server received a request with a Request-URI that was incomplete.
Additional information SHOULD be provided in the reason phrase.

This status code allows overlapped dialing. With overlapped
dialing, the client does not know the length of the dialing
string. It sends strings of increasing lengths, prompting the
user for more input until it no longer receives a 484 (Address
Incomplete) status response.

485 Ambiguous

The Request-URI was ambiguous. The response MAY contain a listing of
possible unambiguous addresses in Contact header fields. Revealing
alternatives can infringe on the privacy of the user or the organization.
It MUST be possible to configure a server to respond with status 404
(Not Found) or to suppress the listing of possible choices for
ambiguous Request-URIs.

Example response to a request with the Request-URI
sip:lee@example.com:

SIP/2.0 485 Ambiguous
Contact: Carol Lee sip:carol.lee@example.com
Contact: Ping Lee sip:p.lee@example.com
Contact: Lee M. Foote sips:lee.foote@example.com

Some email and voice mail systems provide this functionality. A
status code separate from 3xx is used since the semantics are
different: for 300, it is assumed that the same person or service
will be reached by the choices provided. While an automated
choice or sequential search makes sense for a 3xx response, user
intervention is required for a 485 (Ambiguous) response.

486 Busy Here

The callee’s end system was contacted successfully, but the callee is
currently not willing or able to take additional calls at this end
system. The response MAY indicate a better time to call in the
Retry-After header field. The user could also be available
elsewhere, such as through a voice mail service. Status 600 (Busy
Everywhere) SHOULD be used if the client knows that no other end
system will be able to accept this call.

487 Request Terminated

The request was terminated by a BYE or CANCEL request.
This response is never returned for a CANCEL request itself.

488 Not Acceptable Here

The response has the same meaning as 606 (Not Acceptable), but only
applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.
A message body containing a description of media capabilities MAY be
present in the response, which is formatted according to the Accept
header field in the INVITE (or application/sdp if not present), the
same as a message body in a 200 (OK) response to an OPTIONS request.

491 Request Pending

The request was received by a UAS that had a pending request within
the same dialog.

493 Undecipherable

The request was received by a UAS that contained an encrypted MIME
body for which the recipient does not possess or will not provide an
appropriate decryption key. This response MAY have a single body
containing an appropriate public key that should be used to encrypt
MIME bodies sent to this UA.

5xx Server Failure SIP Response Codes

SIP 5xx response codes are server errors. These imply that the Server has failed to process (what probably looks like a) valid request.
So this type of response should alert us that we have an issue with the SIP server we are trying to get service from.

500 Server Internal Error

The server encountered an unexpected condition that prevented it from
fulfilling the request. The client MAY display the specific error
condition and MAY retry the request after several seconds.
If the condition is temporary, the server MAY indicate when the
client may retry the request using the Retry-After header field.

501 Not Implemented

The server does not support the functionality required to fulfill the
request. This is the appropriate response when a UAS does not
recognize the request method and is not capable of supporting it for
any user. (Proxies forward all requests regardless of method.)

Note that a 405 (Method Not Allowed) is sent when the server
recognizes the request method, but that method is not allowed or
supported.

502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid
response from the downstream server it accessed in attempting to
fulfill the request.

503 Service Unavailable

The server is temporarily unable to process the request due to a
temporary overloading or maintenance of the server. The server MAY
indicate when the client should retry the request in a Retry-After
header field. If no Retry-After is given, the client MUST act as if
it had received a 500 (Server Internal Error) response.

A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
attempt to forward the request to an alternate server.
It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field if present.

Servers MAY refuse the connection or drop the request instead of
responding with 503 (Service Unavailable).

504 Server Time-out

The server did not receive a timely response from an external server
it accessed in attempting to process the request. 408 (Request
Timeout) should be used instead if there was no response within the
period specified in the Expires header field from the upstream
server.

505 Version Not Supported

The server does not support or refuses to support, the SIP protocol
version that was used in the request. The server is indicating that
it is unable or unwilling to complete the request using the same
major version as the client, other than with this error message.

513 Message Too Large

The server was unable to process the request since the message length
exceeded its capabilities.

Global Failures 6xx

6xx SIP response codes are not taken from HTTP and are unique to SIP.

6xx responses indicate that a server has definitive information about
a particular user, not just the particular instance indicated in the
Request-URI.

600 Busy Everywhere

The callee’s end system was contacted successfully but the callee is
busy and does not wish to take the call at this time. The response
MAY indicate a better time to call in the Retry-After header field.
If the callee does not wish to reveal the reason for declining the
call, the callee uses status code 603 (Decline) instead. This status
response is returned only if the client knows that no other endpoint
(such as a voice mail system) will answer the request. Otherwise,
486 (Busy Here) should be returned.

603 Decline

The callee’s machine was successfully contacted but the user
explicitly does not wish to or cannot participate. The response MAY
indicate a better time to call in the Retry-After header field. This
status response is returned only if the client knows that no other
endpoint will answer the request.

604 Does Not Exist Anywhere

The server has authoritative information that the user indicated in
the Request-URI does not exist anywhere.

606 Not Acceptable

The user’s agent was contacted successfully but some aspects of the
session description such as the requested media, bandwidth, or
addressing style were not acceptable.

A 606 (Not Acceptable) response means that the user wishes to
communicate, but cannot adequately support the session described.
The 606 (Not Acceptable) response MAY contain a list of reasons in a
Warning header field describing why the session described cannot be
supported.

A message body containing a description of media capabilities MAY be
present in the response, which is formatted according to the Accept
header field in the INVITE (or application/sdp if not present), the
same as a message body in a 200 (OK) response to an OPTIONS request.

It is hoped that negotiation will not frequently be needed, and when
a new user is being invited to join an already existing conference,
negotiation may not be possible. It is up to the invitation
initiator to decide whether or not to act on a 606 (Not Acceptable)
response.
This status response is returned only if the client knows that no
other endpoints will answer the request.

To gather this list I relied mostly on the RFC in addition to my own experience and comments.
This is the link to the official SIP RFC, that goes along with huge respect for the work these guys do.

---