\section{Response}
\label{sec:response}

After receiving and interpreting a request message, the recipient
responds with a SIP response message.  The response message format is
shown below:

\begin{syntax}
Response
& = & Status-Line          & ; {\rm Section~\ref{sec:Status-Line}}\\
&   & *( general-header    & \\
&   & $|$ response-header  & \\
&   & $|$ entity-header )  & \\
&   & CRLF                 & \\
&   & [ message-body ]     & ; {\rm Section~\ref{sec:message-body}}\\
\end{syntax}

SIP's structure of responses is similar to [H6], but is defined
explicitly here.

\subsection{Status-Line}
\label{sec:Status-Line}

The first line of a \header{Response} message is the \header{Status-Line},
consisting of the protocol version (Section~\ref{sec:SIP-Version})
followed by a numeric \header{Status-Code} and its associated textual
phrase, with each element separated by SP characters.  No \header{CR} or
\header{LF} is allowed except in the final \header{CRLF} sequence.

\begin{syntax}
Status-Line & = & SIP-version SP Status-Code SP Reason-Phrase CRLF
\end{syntax}

\subsubsection{Status Codes and Reason Phrases}

The \header{Status-Code} is a 3-digit integer result code that indicates
the outcome of the attempt to understand and satisfy the request.  The
\header{Reason-Phrase} is intended to give a short textual description
of the \header{Status-Code}.  The \header{Status-Code} is intended for
use by automata, whereas the \header{Reason-Phrase} is intended for the
human user.  The client is not required to examine or display the
\header{Reason-Phrase}.

\begin{syntax}
Status-Code 
& = & Informational  & {\rm ;Fig.~\ref{fig:Informational}}\\
&$|$& Success        & {\rm ;Fig.~\ref{fig:Informational}}\\
&$|$& Redirection    & {\rm ;Fig.~\ref{fig:Redirection}}\\
&$|$& Client-Error   & {\rm ;Fig.~\ref{fig:Client-Error}}\\
&$|$& Server-Error   & {\rm ;Fig.~\ref{fig:Server-Error}}\\
&$|$& Global-Failure & {\rm ;Fig.~\ref{fig:Global-Failure}}\\
&$|$& extension-code
\\
extension-code 
& = & 3DIGIT\\
\\
Reason-Phrase
& = & *$<$TEXT-UTF8, {\rm excluding} CR, LF$>$
\end{syntax}

We provide an overview of the \header{Status-Code} below, and provide
full definitions in Section \ref{sec:status}.  The first digit of the
\header{Status-Code} defines the class of response.  The last two digits
do not have any categorization role.  SIP/2.0 allows 6 values for the
first digit:

\begin{description}
\item[1xx:] Informational -- request received, continuing to process the
request;

\item[2xx:] Success -- the action was successfully received, understood,
and accepted;

\item[3xx:] Redirection -- further action needs to be taken in order to
complete the request;

\item[4xx:] Client Error -- the request contains bad syntax or cannot be
fulfilled at this server;

\item[5xx:] Server Error -- the server failed to fulfill an apparently
valid request;

\item[6xx:] Global Failure -- the request cannot be fulfilled at any
server.
\end{description}

Figures~\ref{fig:Informational} through \ref{fig:Global-Failure} present
the individual values of the numeric response codes, and an example set
of corresponding reason phrases for SIP/2.0.  These reason phrases are
only recommended; they may be replaced by local equivalents without
affecting the protocol.  Note that SIP adopts many HTTP/1.1 response
codes.  SIP/2.0 adds response codes in the range starting at x80 to
avoid conflicts with newly defined HTTP response codes, and adds a new
class, 6xx, of response codes.

SIP response codes are extensible.  SIP applications are not required to
understand the meaning of all registered response codes, though such
understanding is obviously desirable.  However, applications {\MUST}
understand the class of any response code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 response code of that class. 
However, proxies {\SHOULD} distinguish 100 from other 1xx responses. 
(The former {\SHOULDNOT} be forwarded, while the latter {\MUST} be. 
See Section~\ref{sec:proxy}.)
For example, if a client receives an
unrecognized response code of 431, it can safely assume that there was
something wrong with its request and treat the response as if it had
received a 400 (Bad Request) response code.  In such cases, user agents
{\SHOULD} present to the user the message body returned with the
response, since that message body is likely to include human-readable
information which will explain the unusual status.

\begin{figure}
\begin{makeimage}
\end{makeimage}
\begin{syntax}
Informational
& = & "100" & ; {\rm Trying}\\
&$|$& "180" & ; {\rm Ringing}\\
&$|$& "181" & ; {\rm Call Is Being Forwarded}\\
&$|$& "182" & ; {\rm Queued}\\
&$|$& "183" & ; {\rm Session Progress}\\
Success
& = & "200" & ; {\rm OK}\\
\end{syntax}
\caption{Informational and success status codes}
\label{fig:Informational}
\end{figure}

\begin{figure}
\begin{makeimage}
\end{makeimage}
\begin{syntax}
Redirection
& = & "300" & ; {\rm Multiple Choices}\\
&$|$& "301" & ; {\rm Moved Permanently}\\
&$|$& "302" & ; {\rm Moved Temporarily}\\
&$|$& "305" & ; {\rm Use Proxy}\\
&$|$& "380" & ; {\rm Alternative Service}\\
\end{syntax}
\caption{Redirection status codes}
\label{fig:Redirection}
\end{figure}

\begin{figure}
\begin{makeimage}
\end{makeimage}
\begin{syntax}
Client-Error
& = & "400" & ; {\rm Bad Request}\\
&$|$& "401" & ; {\rm Unauthorized}\\
&$|$& "402" & ; {\rm Payment Required}\\
&$|$& "403" & ; {\rm Forbidden}\\
&$|$& "404" & ; {\rm Not Found}\\
&$|$& "405" & ; {\rm Method Not Allowed}\\
&$|$& "406" & ; {\rm Not Acceptable}\\
&$|$& "407" & ; {\rm Proxy Authentication Required}\\
&$|$& "408" & ; {\rm Request Timeout}\\
&$|$& "409" & ; {\rm Conflict}\\
&$|$& "410" & ; {\rm Gone}\\
&$|$& "411" & ; {\rm Length Required}\\
&$|$& "413" & ; {\rm Request Entity Too Large}\\
&$|$& "414" & ; {\rm Request-URI Too Large}\\
&$|$& "415" & ; {\rm Unsupported Media Type}\\
&$|$& "420" & ; {\rm Bad Extension}\\
&$|$& "480" & ; {\rm Temporarily not available}\\
&$|$& "481" & ; {\rm Call Leg/Transaction Does Not Exist}\\
&$|$& "482" & ; {\rm Loop Detected}\\
&$|$& "483" & ; {\rm Too Many Hops}\\
&$|$& "484" & ; {\rm Address Incomplete}\\
&$|$& "485" & ; {\rm Ambiguous}\\
&$|$& "486" & ; {\rm Busy Here}\\
&$|$& "487" & ; {\rm Request Terminated}\\
&$|$& "488" & ; {\rm Not Acceptable Here}
\end{syntax}
\caption{Client error status codes}
\label{fig:Client-Error}
\end{figure}

\begin{figure}
\begin{makeimage}
\end{makeimage}
\begin{syntax}
Server-Error
& = & "500" & ; {\rm Internal Server Error}\\
&$|$& "501" & ; {\rm Not Implemented}\\
&$|$& "502" & ; {\rm Bad Gateway}\\
&$|$& "503" & ; {\rm Service Unavailable}\\
&$|$& "504" & ; {\rm Server Time-out}\\
&$|$& "505" & ; {\rm SIP Version not supported}\\
\end{syntax}
\caption{Server error status codes}
\label{fig:Server-Error}
\end{figure}

\begin{figure}
\begin{makeimage}
\end{makeimage}
\begin{syntax}
Global-Failure
& = & "600" & ; {\rm Busy Everywhere}\\
&$|$& "603" & ; {\rm Decline}\\
&$|$& "604" & ; {\rm Does not exist anywhere}\\
&$|$& "606" & ; {\rm Not Acceptable}\\
\end{syntax}
\caption{Global failure status codes}
\label{fig:Global-Failure}
\end{figure}

