\section{RTSP Message}
\label{sec:message}

RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 \cite{rfc2279}).  Lines are terminated by CRLF,
but receivers should be prepared to also interpret CR and LF by
themselves as line terminators.

\motivation{Text-based protocols make it easier to add optional
parameters in a self-describing manner.  Since the number of parameters
and the frequency of commands is low, processing efficiency is not a
concern.  Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such as
Tcl, Visual Basic and Perl.

The 10646 character set avoids tricky character set switching, but is
invisible to the application as long as US-ASCII is being used.  This is
also the encoding used for RTCP.  ISO 8859-1 translates directly into
Unicode with a high-order octet of zero.  ISO 8859-1 characters with
the most-significant bit set are represented as 1100001x 10xxxxxx.
(See RFC 2279 \cite{rfc2279})}

RTSP messages can be carried over any lower-layer transport protocol
that is 8-bit clean.  

Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent,
unless otherwise noted. Methods are also designed to require little or
no state maintenance at the media server.

\subsection{Message Types}

See [H4.1]

\subsection{Message Headers}

See [H4.2]

\subsection{Message Body}
\label{sec:message-body}

See [H4.3]

\subsection{Message Length}

When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence):

\begin{enumerate}
\item Any response message which MUST NOT include a message body (such
as the 1xx, 204, and 304 responses) is always terminated by the first
empty line after the header fields, regardless of the entity-header
fields present in the message. (Note: An empty line consists of only
CRLF.)

\item If a \header{Content-Length} header field
(section~\ref{sec:Content-Length}) is present, its value in bytes
represents the length of the message-body. If this header field is not
present, a value of zero is assumed.

\end{enumerate}

Note that RTSP does not (at present) support the HTTP/1.1 ``chunked''
transfer coding(see [H3.6]) and requires the presence of the
\header{Content-Length} header field.

\motivation{Given the moderate length of presentation descriptions
returned, the server should always be able to determine its length, even
if it is generated dynamically, making the chunked transfer encoding
unnecessary.}

\section{General Header Fields}
\label{sec:general-header}

See [H4.5], except that \header{Pragma}, \header{Transfer-Encoding} and
\header{Upgrade} headers are not defined:

\begin{syntaxwcomment}
general-header
& =   & Cache-Control & {\rm ; Section \ref{sec:Cache-Control}}\\
& $|$ & Connection    & {\rm ; Section \ref{sec:Connection}}\\
& $|$ & CSeq          & {\rm ; Section \ref{sec:CSeq}}\\
& $|$ & Date          & {\rm ; Section \ref{sec:Date}}\\
& $|$ & Via           & {\rm ; Section \ref{sec:Via}}\\
\end{syntaxwcomment}
