\section{Status Code Definitions}
\label{sec:status}

The response codes are consistent with, and extend, HTTP/1.1 response
codes.  Not all HTTP/1.1 response codes are appropriate, and only
those that are appropriate are given here.  Other HTTP/1.1 response
codes {\SHOULDNOT} be used.  Response codes not defined by HTTP/1.1 have
codes x80 upwards to avoid clashes with future HTTP response codes.
Also, SIP defines a new class, 6xx.  The default behavior for unknown
response codes is given for each category of codes.

\subsection{Informational 1xx}

Informational responses indicate that the server or proxy contacted is
performing some further action and does not yet have a definitive
response.  The client {\SHOULD} wait for a further response from the
server, and the server {\SHOULD} send such a response without further
prompting.  A server {\SHOULD} send a 1xx response if it expects to take
more than 200\,ms to obtain a final response.  A server {\MAY} issue zero
or more 1xx responses, with no restriction on their ordering or
uniqueness.  Note that 1xx responses are not transmitted reliably, that
is, they do not cause the client to send an {\ACK}.  Servers are free to
retransmit informational responses and clients can inquire about the
current state of call processing by re-sending the request.

Informational (1xx) responses other than 100 (Trying) {\MAY} contain
message bodies, including session descriptions.  If a 1xx response
contains a session description, a UAC {\SHOULD} cease generating local
ringback tone.  Session descriptions in 1xx responses are interpreted in
the same manner as those in 2xx responses.  In particular, the session
description {\MUST} be formatted in such a way that it would be valid in
a 2xx response.  Thus, the UAS can only include a session description in
its provisional response if the UAC has included one in an earlier
{\INVITE}.  (SIP extensions may specify additional circumstances where
session descriptions may be included.) If a later provisional response
or 2xx contains a different session description, this new description is
treated as if it were the original response to the session description
in the {\INVITE}.

The UAS can remove the media stream by setting the port number to zero
in a subsequent session description contained in a provisional response
and thus restore normal ringback behavior.  The UAS cannot add media
streams beyond those offered by the UAC in the {\INVITE}.  A provisional
response without a session description has no effect on any early media
that have already been set up.

The media streams are assumed to be bidirectional unless marked as
send-only or receive-only.  For SDP, this is described in
Section~\ref{sec:sdp}.  Client behavior when receiving several different
session descriptions from different branches is undefined.

\subsubsection{100 Trying}
\label{sec:100}

Some unspecified action is being taken on behalf of this call (e.g., a
database is being consulted), but the user has not yet been located.

\subsubsection{180 Ringing}
\label{sec:180}

The called user agent has located a possible location where the user has
registered recently and is trying to alert the user.

\subsubsection{181 Call Is Being Forwarded}
\label{sec:181}

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

\subsubsection{182 Queued}
\label{sec:182}

The called party is temporarily unavailable, but the callee 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,
e.g., ``5 calls queued; expected waiting time is 15 minutes''.  The
server {\MAY} issue several 182 responses to update the caller about the
status of the queued call.

\subsubsection{183 Session Progress}
\label{sec:183}

The 183 (Session Progress) response is used to convey information about
the progress of the call which is not otherwise classified.  The
\header{Reason-Phrase} {\MAY} be used to convey more details about the
call progress. 

\subsection{Successful 2xx}
\label{sec:2xx}

The request was successful and {\MUST} terminate a search.

\subsubsection{200 OK}
\label{sec:200}

The request has succeeded. The information returned with the response
depends on the method used in the request, for example:

\begin{description}
\item[{\BYE}:] The call has been terminated. The message body is empty.

\item[{\CANCEL}:] The search has been cancelled. The message body is empty.

\item[{\INVITE}:] The callee has agreed to participate; the message body
indicates the callee's capabilities.

\item[{\OPTIONS}:] The callee has agreed to share its capabilities,
included in the message body.

\item[{\REGISTER}:] The registration has succeeded. The client treats
the message body according to its \header{Content-Type}.

\end{description}

\subsection{Redirection 3xx}
\label{sec:3xx}

3xx responses give information about the user's new location, or about
alternative services that might be able to satisfy the call.  They
{\SHOULD} terminate an existing search, and {\MAY} cause the initiator
to begin a new search if appropriate.

To avoid forwarding loops, a user agent client or proxy {\MUST} check
whether the address returned by a redirect server equals an address
tried earlier.

\subsubsection{300 Multiple Choices}

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

The response {\SHOULD} include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can
choose the one most appropriate, if allowed by the \header{Accept}
request header.  The entity format is specified by the media type given
in the \header{Content-Type} header field.  The choices {\SHOULD} also
be listed as \header{Contact} fields (Section~\ref{sec:Contact}). 
Unlike HTTP, the SIP response {\MAY} contain several \header{Contact}
fields or a list of addresses in a \header{Contact} field.  User agents
{\MAY} use the \header{Contact} header field value for automatic redirection
or {\MAY} ask the user to confirm a choice.  However, this specification
does not define any standard for such automatic selection.

\motivation{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.}

\subsubsection{301 Moved Permanently}
\label{sec:301}

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

\subsubsection{302 Moved Temporarily}
\label{sec:302}

The requesting client {\SHOULD} retry the request at the new address(es)
given by the \header{Contact} header field (Section~\ref{sec:Contact}). 
The \header{Request-URI} of the new request uses the value of the
\header{Contact} header in the response.  The new request can take two
different forms.  In the first approach, the \header{To}, \header{From},
\header{Call-ID}, and \header{CSeq} header fields in the new request are
the same as in the original request, with a new \header{branch}
identifier in the \header{Via} header field.  Proxies {\MUST} follow
this behavior and UACs {\MAY}.  UAs {\MAY} also use the \header{Contact}
information for the \header{To} header field, as well as a new
\header{Call-ID} value.

\motivation{Reusing the \header{CSeq} value allows proxies to avoid
forwarding the request to the same destination twice, as a proxy will
consider it a retransmission.}

The duration of the redirection can be indicated through an
\header{Expires} (Section~\ref{sec:Expires}) header.  If there is no
explicit expiration time, the address is only valid for this call and
{\MUSTNOT} be cached for future calls.

\subsubsection{305 Use Proxy}
\label{sec:305}

The requested resource {\MUST} be accessed through the proxy given by
the \header{Contact} field.  The \header{Contact} field gives the URI of
the proxy.  The recipient is expected to repeat this single request via
the proxy.  305 responses {\MUST} only be generated by user agent servers.

\subsubsection{380 Alternative Service}
\label{sec:380}

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 may be the subject of
future standardization.

\subsection{Request Failure 4xx}

4xx responses are definite failure responses from a particular server. 
The client {\SHOULDNOT} retry the same request without modification (e.g.,
adding appropriate authorization).  However, the same request to a
different server might be successful. 

\subsubsection{400 Bad Request}

The request could not be understood due to malformed syntax. 
The \header{Reason-Phrase} {\SHOULD} identify the syntax problem in more
detail, e.g., ``Missing Call-ID header''.

\subsubsection{401 Unauthorized}

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

\subsubsection{402 Payment Required}

Reserved for future use.

\subsubsection{403 Forbidden}

The server understood the request, but is refusing to fulfill it. 
Authorization will not help, and the request {\SHOULDNOT} be repeated.

\subsubsection{404 Not Found}

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

\subsubsection{405 Method Not Allowed}

The method specified in the \header{Request-Line} is not allowed for the
address identified by the \header{Request-URI}.  The response {\MUST}
include an \header{Allow} header field containing a list of valid
methods for the indicated address.

\subsubsection{406 Not Acceptable}

The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request. 

\subsubsection{407 Proxy Authentication Required}

This code is similar to 401 (Unauthorized), but indicates that the
client {\MUST} first authenticate itself with the proxy.  The proxy {\MUST}
return a \header{Proxy-Authenticate} header field (section
\ref{sec:Proxy-Authenticate}) containing a challenge applicable to the
proxy for the requested resource.  The client {\MAY} repeat the request
with a suitable Proxy-Authorization header field (section
\ref{sec:Proxy-Authorization}).  SIP access authentication is explained
in section \ref{sec:authentication} and \ref{sec:httpauth}.

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

\subsubsection{408 Request Timeout}

The server could not produce a response within a suitable amount of
time, for example, since it could not determine the location of the user
in time.  The amount of time may have been indicated in the
\header{Expires} request-header field or may be set by the server.  The
client {\MAY} repeat the request without modifications at any later
time.

\subsubsection{409 Conflict}

The request could not be completed due to a conflict with the current
state of the resource. This response is returned if the \header{action}
parameter in a {\REGISTER} request conflicts with existing
registrations.

\subsubsection{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.

\subsubsection{413 Request Entity Too Large}

The server is refusing to process a request because the request entity
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
\header{Retry-After} header field to indicate that it is temporary and
after what time the client {\MAY} try again.

\subsubsection{414 Request-URI Too Long}

The server is refusing to service the request because the
\header{Request-URI} is longer than the server is willing to interpret.

\subsubsection{415 Unsupported Media Type}

The server is refusing to service the request because the message body
of the request is in a format not supported by the server for the
requested method.  The server {\SHOULD} return a list of acceptable
formats using the \header{Accept}, \header{Accept-Encoding} and
\header{Accept-Language} header fields. The
client {\SHOULD} retry the request, this time omitting any bodies not
supported by the server.

\subsubsection{420 Bad Extension}

The server did not understand the protocol extension specified in a
\header{Proxy-Require} (Section~\ref{sec:Proxy-Require}) or
\header{Require} (Section~\ref{sec:Require}) header field. 
The server {\SHOULD} include a list of the unsupported extensions in
an \header{Unsupported} header in the response. The client {\SHOULD}
retry the request, this time without using those extensions listed in
the \header{Unsupported} header in the response.

\subsubsection{480 Temporarily Unavailable}

The callee's end system was contacted successfully but the callee is
currently unavailable (e.g., not logged in, logged in in such a manner
as to preclude communication with the callee or activated the ``do not
disturb'' feature).  The response {\MAY} indicate a better time to call
in the \header{Retry-After} header.  The user could also be available
elsewhere (unbeknownst to this host), thus, this response does not
terminate any searches.  The reason phrase {\SHOULD} indicate a more
precise cause as to why the callee is unavailable.  This value {\SHOULD}
be setable by the user agent.  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 server that recognizes the
user identified by the \header{Request-URI}, but does not currently have
a valid forwarding location for that user.

\subsubsection{481 Call Leg/Transaction Does Not Exist}

This status is returned under three conditions:  The UAS received a
{\BYE} request that does not match any existing call leg, the server
received a {\CANCEL} request that does not match any existing
transaction or the UAS received an {\INVITE} with a \header{To} tag
that does not match the local tag value.  (A server simply discards an
{\ACK} referring to an unknown transaction.) A UAC receiving a 481 to
a request sent for an existing call leg {\MUST} consider that call leg
terminated.

\subsubsection{482 Loop Detected}

The server received a request with a \header{Via}
(Section~\ref{sec:Via}) path containing itself.

\subsubsection{483 Too Many Hops}

The server received a request that contains a \header{Max-Forwards}
(Section~\ref{sec:Max-Forwards}) header with the value zero.

\subsubsection{484 Address Incomplete}

The server received a request with a \header{To} (Section~\ref{sec:To})
address or \header{Request-URI} that was incomplete.  Additional
information {\SHOULD} be provided.

\motivation{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 status response.}

\subsubsection{485 Ambiguous}

The callee address provided in the request was ambiguous.  The response
{\MAY} contain a listing of possible unambiguous addresses in
\header{Contact} headers.

Revealing alternatives can infringe on privacy concerns 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 if the request address was ambiguous.

Example response to a request with the URL {\tt lee@example.com}:
\begin{verbatim}
485 Ambiguous SIP/2.0
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sip:lee.foote@example.com>
\end{verbatim}

\motivation{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 response.}

\subsubsection{486 Busy Here}
\label{sec:486}

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
\header{Retry-After} header.  The user could also be available
elsewhere, such as through a voice mail service, thus, this response
does not terminate any searches.  Status 600 (Busy Everywhere) {\SHOULD}
be used if the client knows that no other end system will be able to
accept this call.

\subsubsection{487 Request Terminated}
\label{sec:487}

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

\subsubsection{488 Not Acceptable Here}
\label{sec:488}

The response has the same meaning as 606 (Not Acceptable), but only
applies to the specific entity addressed by the \header{Request-URI} and
the request may succeed elsewhere.

\subsection{Server Failure 5xx}

5xx responses are failure responses given when a server itself has
erred.  They are not definitive failures, and {\MUSTNOT} terminate a
search if other possible locations remain untried.

\subsubsection{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 \header{Retry-After} header.

\subsubsection{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.)

\subsubsection{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.

\subsubsection{503 Service Unavailable}

The server is currently unable to handle the request due to a
temporary overloading (i.e., congestion) or maintenance of the server.
The implication is that this is a temporary condition which will be
alleviated after some delay.  If known, the length of the delay {\MAY}
be indicated in a \header{Retry-After} header.  If no
\header{Retry-After} is given, the client {\MUST} handle the response
as it would for a 500 response.

A client (proxy or UAC) receiving a 503 {\SHOULD} attempt to forward
the request to an alternate server. It {\SHOULDNOT} forward any other requests
to that server for the duration specified in the \header{Retry-After}
header, if present. A proxy which receives a 503 {\SHOULDNOT} forward
it upstream unless it can determine that any subsequent requests it
might proxy will also generate a 503. In other words, forwarding a 503
means that the proxy knows it cannot service any requests, not just
the one for the \header{Request-URI} in the request which generated
the 503.

Note:  The existence of the 503 status code does not imply that a server
has to use it when becoming overloaded.  Some servers {\MAY} wish to
simply refuse the connection.

\subsubsection{504 Server Time-out}

The server did not receive a timely response from the server (e.g., a
location server) it accessed in attempting to process the request. Note
that 408 (Request Timeout) should be used if there was no response
within the period specified in the \header{Expires} header field from
the upstream server.

\subsubsection{505 Version Not Supported}

The server does not support, or refuses to support, the SIP protocol
version that was used in the request message.  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.  The
response {\MAY} contain an entity describing why that version is not
supported and what other protocols are supported by that server.  The
format for such an entity is not defined here and may be the subject of
future standardization.

\subsubsection{513 Message Too Large}

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

\subsection{Global Failures 6xx}

6xx responses indicate that a server has definitive information about a
particular user, not just the particular instance indicated in the
\header{Request-URI}.  All further searches for this user are doomed to
failure and pending searches {\SHOULD} be terminated.

\subsubsection{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 \header{Retry-After}
header.  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 end
point (such as a voice mail system) will answer the request.  Otherwise,
486 (Busy Here) should be returned.

\subsubsection{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 \header{Retry-After} header.

\subsubsection{604 Does Not Exist Anywhere}

The server has authoritative information that the user indicated in the
\header{Request-URI} does not exist anywhere.  Searching
for the user elsewhere will not yield any results.

\subsubsection{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
\header{Warning} header field describing why the session described
cannot be supported.  Reasons are listed in Section~\ref{sec:Warning}. 
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.
