Session Initiation Protocol (SIP) - Overview -4 (messages-2)

SIP response

The SIP response types defined in RFC 3261 fall in one of the following categories:

Main article: List of SIP response codes

Provisional (1xx): Request received and being processed.
Success (2xx): The action was successfully received, understood, and accepted.
Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request.
Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server.
Server Error (5xx): The server failed to fulfill an apparently valid request.
Global Failure (6xx): The request cannot be fulfilled at any server.

SIP messages are of two types: requests and responses.

The opening line of a request contains a method that defines the request, and a Request-URI that defines where the request is to be sent.
Similarly the opening line of a response contains a response code.

nformational(1xx)

Informational responses are used to indicate call progress. Normally the responses are end to end (except 100 Trying). The main objective of informational responses is to stop retransmission of INVITE requests.

Informational responses include the following responses:

100 Trying

This special case response is only a hop-by-hop request.
It is never forwarded and may not contain a message body.
It is used to avoid the retransmission of INVITE requests.

180 Ringing

This response is used to indicate that an INVITE has been received by the user agent and alerting is taking place.

181 Call is Being Forwarded

This response is used to indicate that the call has been forwarded to another endpoint.
It is sent when the information may be of use to the caller.
It gives the status of the caller, as a forwarding operation may result in the call taking longer to be answered.

182 Call Queued

This response is used to indicate that the INVITE has been received and will be processed in a queue.

183 Session Progress

It indicates that information about the progress of a session may be present in a message body or media stream.
Unlike a 100 Trying response, a 183 is an end-to-end response and establishes a dialog.
A typical use of this response is to allow a UAC to hear a ringtone, busy tone, or recorded announcement in calls through a gateway into the PSTN.

Success(2xx)

This class of responses is meant for indicating that a request has been accepted. It includes the following responses:

200 OK

200 OK is used to accept a session invitation.
It indicates a successful completion or receipt of a request.

202 Accepted

202 Accepted indicates that the UAS has received and understood the request, but that the request may not have been authorized or processed by the server.
It is commonly used in responses to SUBSCRIBE, REFER methods.

Redirection(3xx)

Generally these class responses are sent by redirect servers in response to INVITE. They are also known as redirect class responses. It includes the following responses:

300 Multiple Choices

It contains multiple Contact header fields to indicate that the location service has returned multiple possible locations for the SIP URI in the Request-URI.

301 Moved Permanently

This redirection response contains a Contact header field with the new permanent URI of the called party.
The address can be saved and used in future INVITE requests.

302 Moved Temporarily

This redirection response contains a URI that is currently valid but is not permanent.
That is, the location is valid for the duration of the time specified.

305 Use Proxy

This response contains a URI that points to a proxy server having authoritative information about the calling party.
This response could be sent by a UAS issuing a proxy for incoming call screening.

380 Alternative Service

This response returns a URI that indicates the type of service the called party would like.
For example, a call could be redirected to a voicemail server.

Client Error(4xx)

Client error responses indicate that the request cannot be fulfilled as some errors are identified from the UAC side. The response codes are generally sent by UAS. Upon receiving an error message, the client should resend the request by modifying it based on the response. Discussed below are some of the important client error responses.

400 Bad Request

It indicates that the request was not understood by the server.
Request might be missing required header fields such as To, From, Call-ID, or CSeq.

401 Unauthorized

- It indicates that the request requires the user to perform authentication.
- 401 Unauthorized is normally sent by a registrar server for REGISTER request.
- The response contains WWW-Authenticate header field which requests for correct credentials from the calling user agent.

A subsequent REGISTER will trigger from the User Agent with correct credentials.

403 Forbidden

403 Forbidden is sent when the server has understood the request, found the request to be correctly formulated, but will not service the request.
This response is not used when authorization is required.

404 Not Found

404 Not Found indicates that the user identified by the SIP URI in the Request-URI cannot be located by the server or that the user is not currently signed on with the user agent.

405 Method Not Allowed

It indicates that the server or user agent has received and understood a request but is not willing to fulfil the request.
Example: A REGISTER request might be sent to a user agent.
An Allow field must be present to inform the UAC as to what methods are acceptable.

406 Not Acceptable

This response indicates that the request cannot be processed due to a requirement in the request message.
The Accept header field in the request did not contain any options supported by the UAS.

407 Proxy Authentication Required

This request sent by a proxy indicates that the UAC must first authenticate itself with the proxy before the request can be processed.
The response should contain information about the type of credentials required by the proxy in a Proxy-Authenticate header field.
The request can be resubmitted with the proper credentials in a Proxy-Authorization header field.

408 Request Timeout

This response is sent when an Expires header field is present in an INVITE request and the specified time period has passed.
It could be sent by a forking proxy or a user agent.
The request can be retried at any time by the UAC.

422 Session Timer Interval Too Small

The response is used to reject a request containing a Session-Expires header field.
The minimum allowed interval is indicated in the required Min-SE header field.
The calling party may retry the request without the Session-Expires header field or with a value less than or equal to the specified minimum.

423 Interval Too Brief

The response is returned by a registrar that is rejecting a registration request because the requested expiration time on one or more Contacts is too brief.
The response must contain a Min-Expires header field listing the minimum expiration interval that the registrar will accept.

480 Temporarily Unavailable

This response indicates that the request has reached the correct destination, but the called party is not available for some reason.
The response should contain a Retry-After header indicating when the request may be able to be fulfilled.

481 Dialog/Transaction Does Not Exist

This response indicates that a response referencing an existing call or transaction has been received for which the server has no records or state information.

483 Too Many Hops

This response indicates that the request has been forwarded the maximum number of times as set by the Max-Forwards header in the request.
This is indicated by the receipt of a Max-Forward: 0 header in a request.

486 Busy Here

This indicates the user agent is busy and cannot accept the call.

487 Request Terminated

This response can be sent by a UA that has received a CANCEL request for a pending INVITE request.
A 200 OK is sent to acknowledge the CANCEL, and a 487 is sent to cancel the INVITE transaction.

Server Failure (5xx)

This class response is used to indicate that the request cannot be processed because of an error with the server. The server failed to fulfil an apparently valid request. The response may contain a Retry-After header field. The request can be tried at other locations because there are no errors indicated in the request. Some of the important server failure responses are discussed below.

500 Server Internal Error

500 indicates that the server has experienced some kind of error that is preventing it from processing the request.
It is one kind of server failure that indicates the client to retry the request again at this server after several seconds.

501 Not Implemented

It indicates that the server is unable to process the request because it is not supported.
This response can be used to decline a request containing an unknown method.

502 Bad Gateway

This response is sent by a proxy that is acting as a gateway to another network.
It indicates some problem in the other network is preventing the request from being processed.

503 Service Unavailable

This response indicates that the requested service is temporarily unavailable at that time.
The request can be retried after a few seconds, or after the expiration of the Retry-After header field.

504 Gateway Timeout

This response comes when the request failed due to a timeout occurred in the other network to which the gateway connects.
It is a server error class response because the call is failing due to a failure of the server in accessing resources outside the SIP network.

505 Version Not Supported

The server denies a request when it comes with a different SIP version number. The denial is indicated in this message.
Currently SIP version 2.0 is the only version implemented.

513 Message Too Large

This response is used by a UAS to indicate that the request size was too large for it to process.

580 Preconditions Failure

This response is used to reject an SDP offer in which required preconditions cannot be met.

Global Error (6xx)

This response class indicates that the server knows that the request will fail wherever it is tried. As a result, the request should not be sent to other locations.

Only a server having definitive knowledge of the user identified by the Request-URI in every possible instance should send a global error class response. Otherwise, a client error class response should be sent.

A Retry-After header field can be used to indicate when the request might be successful. Some of the important responses are discussed below:

600 Busy Everywhere

This response indicates that the call to the specified Request-URI could be answered in other locations.

603 Decline

This response could indicate the called party is busy, or simply does not want to accept the call.

604 Does Not Exist Anywhere

This response is similar to the 404 Not Found response but indicates that the user in the Request-URI cannot be found anywhere.
This response should only be sent by a server having access to all the information about the user.

606 Not Acceptable

This response indicates that some aspect of the desired session is not acceptable to the UAS, and as a result, the session cannot be established.
The response may contain a Warning header field with a numerical code describing exactly what was not acceptable.
The request can be retried with different media session information.