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

[H6] applies except that \header{HTTP-Version} is replaced by
\header{RTSP-Version}.  Also, RTSP defines additional status codes and
does not define some HTTP codes.  The valid response codes and the
methods they can be used with are defined in Table~\ref{tab:status}.

After receiving and interpreting a request message, the recipient
responds with an RTSP response message.

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

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

The first line of a Response message is the \header{Status-Line},
consisting of the protocol version followed by a numeric status code,
and the textual phrase associated with the status code, with each
element separated by \header{SP} characters.  No \header{CR} or
\header{LF} is allowed except in the final CRLF sequence.

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

\subsubsection{Status Code and Reason Phrase}

The Status-Code element is a 3-digit integer result code of the attempt
to understand and satisfy the request.  These codes are fully defined in
Section \ref{sec:status}.  The \header{Reason-Phrase} is intended to
give a short textual description of the Status-Code.  The
\header{Status-Code} is intended for use by automata and the
Reason-Phrase is intended for the human user.  The client is not
required to examine or display the \header{Reason-Phrase}.

The first digit of the \header{Status-Code} defines the class of
response.  The last two digits do not have any categorization role. 
There are 5 values for the first digit:

\begin{itemize}
\item 1xx: Informational - Request received, continuing process

\item 2xx: Success - The action was successfully received, understood,
and accepted

\item 3xx: Redirection - Further action must be taken in order to
complete the request

\item 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled

\item 5xx: Server Error - The server failed to fulfill an apparently
valid request
\end{itemize}

The individual values of the numeric status codes defined for RTSP/1.0,
and an example set of corresponding \header{Reason-Phrase}'s, are
presented below.  The reason phrases listed here are only recommended --
they may be replaced by local equivalents without affecting the
protocol.  Note that RTSP adopts most HTTP/1.1 \cite{rfc2068} status
codes and adds RTSP-specific status codes starting at x50 to avoid
conflicts with newly defined HTTP status codes.

\begin{quotation}
\begin{sf}
\begin{tabular}{lcll}
Status-Code & =   & "100"   & ; {\rm Continue}\\
            & $|$ & "200"   & ; {\rm OK}\\
            & $|$ & "201"   & ; {\rm Created}\\
            & $|$ & "250"   & ; {\rm Low on Storage Space}\\
            & $|$ & "300"   & ; {\rm Multiple Choices}\\
            & $|$ & "301"   & ; {\rm Moved Permanently}\\
            & $|$ & "302"   & ; {\rm Moved Temporarily}\\
            & $|$ & "303"   & ; {\rm See Other}\\
            & $|$ & "304"   & ; {\rm Not Modified}\\
            & $|$ & "305"   & ; {\rm Use Proxy}\\
            & $|$ & "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 Time-out}\\
            & $|$ & "410"   & ; {\rm Gone}\\
            & $|$ & "411"   & ; {\rm Length Required}\\
            & $|$ & "412"   & ; {\rm Precondition Failed}\\
            & $|$ & "413"   & ; {\rm Request Entity Too Large}\\
            & $|$ & "414"   & ; {\rm Request-URI Too Large}\\
            & $|$ & "415"   & ; {\rm Unsupported Media Type}\\
            & $|$ & "451"   & ; {\rm Parameter Not Understood}\\
            & $|$ & "452"   & ; {\rm Conference Not Found}\\
            & $|$ & "453"   & ; {\rm Not Enough Bandwidth}\\
            & $|$ & "454"   & ; {\rm Session Not Found}\\
            & $|$ & "455"   & ; {\rm Method Not Valid in This State}\\
            & $|$ & "456"   & ; {\rm Header Field Not Valid for Resource}\\
            & $|$ & "457"   & ; {\rm Invalid Range}\\
            & $|$ & "458"   & ; {\rm Parameter Is Read-Only}\\
            & $|$ & "459"   & ; {\rm Aggregate operation not allowed}\\
            & $|$ & "460"   & ; {\rm Only aggregate operation allowed}\\
            & $|$ & "461"   & ; {\rm Unsupported transport}\\
            & $|$ & "462"   & ; {\rm Destination unreachable}\\
            & $|$ & "500"   & ; {\rm Internal Server Error}\\
            & $|$ & "501"   & ; {\rm Not Implemented}\\
            & $|$ & "502"   & ; {\rm Bad Gateway}\\
            & $|$ & "503"   & ; {\rm Service Unavailable}\\
            & $|$ & "504"   & ; {\rm Gateway Time-out}\\
            & $|$ & "505"   & ; {\rm RTSP Version not supported}\\
            & $|$ & "551"   & ; {\rm Option not supported}\\
            & $|$ & extension-code
\end{tabular}
\end{sf}
\end{quotation}
\begin{quotation}
\begin{sf}
\begin{tabular}{lcll}
extension-code & = & 3DIGIT\\
\\
Reason-Phrase  & = & *$<$TEXT, {\rm excluding} CR, LF$>$\\
\end{tabular}
\end{sf}
\end{quotation}

RTSP status codes are extensible.  RTSP applications are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable.  However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an unrecognized
response MUST NOT be cached.  For example, if an unrecognized status
code of 431 is received by the client, it can safely assume that there
was something wrong with its request and treat the response as if it had
received a 400 status code.  In such cases, user agents SHOULD present
to the user the entity returned with the response, since that entity is
likely to include human-readable information which will explain the
unusual status.
\begin{table}[htpb]
\begin{center}
\begin{small}
\begin{tabular}{lll}
Code & reason\\
\hline
100  & Continue                      & all\\
\hline				             
200  & OK                            & all\\
201  & Created                       & RECORD\\ 
250  & Low on Storage Space          & RECORD\\
\hline				             
300  & Multiple Choices              & all\\
301  & Moved Permanently             & all\\
302  & Moved Temporarily             & all\\
303  & See Other                     & all\\
305  & Use Proxy                     & all\\
\hline				             
400  & Bad Request                   & all\\
401  & Unauthorized                  & all\\
402  & Payment Required              & all\\
403  & Forbidden                     & all\\
404  & Not Found                     & all\\
405  & Method Not Allowed            & all\\
406  & Not Acceptable                & all\\
407  & Proxy Authentication Required & all\\
408  & Request Timeout               & all\\
410  & Gone                          & all\\
411  & Length Required               & all\\
412  & Precondition Failed           & DESCRIBE, SETUP\\
413  & Request Entity Too Large      & all\\
414  & Request-URI Too Long          & all\\
415  & Unsupported Media Type        & all\\
451  & Parameter Not Understood      & SETUP\\ 
452  & Illegal Conference Identifier & SETUP\\
453  & Not Enough Bandwidth          & SETUP\\
454  & Session Not Found             & all\\ 
455  & Method Not Valid In This State       & all\\
456  & Header Field Not Valid        & all\\
457  & Invalid Range                 & PLAY\\
458  & Parameter Is Read-Only        & SET\_PARAMETER\\
459  & Aggregate Operation Not Allowed & all \\
460  & Only Aggregate Operation Allowed & all \\
461  & Unsupported Transport          & all \\
462  & Destination Unreachable       & all \\
\hline				             
500  & Internal Server Error         & all\\
501  & Not Implemented               & all\\
502  & Bad Gateway                   & all\\
503  & Service Unavailable           & all\\
504  & Gateway Timeout               & all\\
505  & RTSP Version Not Supported    & all\\
551  & Option not support            & all\\
\end{tabular}
\end{small}
\end{center}
\caption{Status codes and their usage with RTSP methods}
\label{tab:status}
\end{table}

\subsubsection{Response Header Fields}
\label{sec:response-header}

The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in the
\header{Status-Line}.  These header fields give information about the
server and about further access to the resource identified by the
\header{Request-URI}.

\begin{syntaxwcomment}
response-header
& =   & Location            & {\rm ; Section \ref{sec:Location}}\\
& $|$ & Proxy-Authenticate  & {\rm ; Section \ref{sec:Proxy-Authenticate}}\\
& $|$ & Public              & {\rm ; Section \ref{sec:Public}}\\
& $|$ & Range               & {\rm ; Section \ref{sec:Range}}\\
& $|$ & Retry-After         & {\rm ; Section \ref{sec:Retry-After}}\\
& $|$ & RTP-Info            & {\rm ; Section \ref{sec:RTP-Info}}\\
& $|$ & Scale               & {\rm ; Section \ref{sec:Scale}}\\
& $|$ & Session             & {\rm ; Section \ref{sec:Session}}\\
& $|$ & Server              & {\rm ; Section \ref{sec:Server}}\\
& $|$ & Speed               & {\rm ; Section \ref{sec:Speed}}\\
& $|$ & Transport           & {\rm ; Section \ref{sec:Transport}}\\
& $|$ & Unsupported         & {\rm ; Section \ref{sec:Unsupported}}\\
& $|$ & Vary                & {\rm ; Section \ref{sec:Vary}}\\
& $|$ & WWW-Authenticate    & {\rm ; Section \ref{sec:WWW-Authenticate}}\\
\end{syntaxwcomment}

Response-header field names can be extended reliably only in combination
with a change in the protocol version.  However, new or experimental
header fields MAY be given the semantics of response-header fields if
all parties in the communication recognize them to be response-header
fields.  Unrecognized header fields are treated as entity-header fields.
