\section{Header Field Definitions}
\label{sec:headers}

HTTP/1.1 \cite{rfc2068} or other, non-standard header fields not listed
here currently have no well-defined meaning and {\SHOULD} be ignored by
the recipient.

Table~\ref{tab:headers} summarizes the header fields used by RTSP.  Type
``g'' designates general request headers to be found in both requests
and responses, type ``R'' designates request headers, type ``r''
designates response headers, and type ``e'' designates entity header
fields.  Fields marked with ``req.'' in the column labeled ``support''
{\MUST} be implemented by the recipient for a particular method, while
fields marked ``opt.'' are optional.  Note that not all fields marked
``req.'' will be sent in every request of this type.  The ``req.'' means
only that client (for response headers) and server (for request headers)
MUST implement the fields.  The last column lists the method for which
this header field is meaningful; the designation ``entity'' refers to
all methods that return a message body.  Within this specification,
{\DESCRIBE} and {\GETPARAMETER} fall into this class.

\begin{table}[htbp]
\begin{center}
\begin{small}
\begin{tabular}{lccl}
Header                 & type & support & methods\\ 
\hline
\header{Accept}                 & R  & opt. & entity\\
\header{Accept-Encoding}        & R  & opt. & entity\\
\header{Accept-Language}        & R  & opt. & all\\
\header{Accept-Ranges}          & R  & opt. & all\\
\header{Allow}                  & e  & opt. & all\\
\header{Authorization}          & R  & opt. & all\\
\header{Bandwidth}              & R  & opt. & all\\
\header{Blocksize}              & R  & opt. & all but \OPTIONS, \TEARDOWN\\
\header{Cache-Control}          & g  & opt. & \SETUP\\
\header{Conference}             & R  & opt. & \SETUP\\
\header{Connection}             & g  & req. & all\\
\header{Content-Base}           & e  & opt. & entity\\
\header{Content-Encoding}       & e  & req. & \SETPARAMETER\\
\header{Content-Encoding}       & e  & req. & \DESCRIBE, \ANNOUNCE\\
\header{Content-Language}       & e  & req. & \DESCRIBE, \ANNOUNCE\\
\header{Content-Length}         & e  & req. & \SETPARAMETER, \ANNOUNCE\\
\header{Content-Length}         & e  & req. & entity\\
\header{Content-Location}       & e  & opt. & entity\\
\header{Content-Type}           & e  & req. & \SETPARAMETER, \ANNOUNCE\\
\header{CSeq}                   & g  & req. & all\\
\header{Date}                   & g  & opt. & all\\
\header{Expires}                & e  & opt. & \DESCRIBE, \ANNOUNCE\\
\header{From}                   & R  & opt. & all\\
\header{If-Match}               & R  & opt. & \SETUP\\
\header{If-Modified-Since}      & R  & opt. & \DESCRIBE, \SETUP\\
\header{Last-Modified}          & e  & opt. & entity\\
\header{Location}               & r  & opt. & 201, 30x\\
\header{Proxy-Authenticate}     & r  & req. & 407\\
\header{Proxy-Require}          & R  & req. & all\\
\header{Public}                 & r  & opt. & all\\
\header{Range}                  & R  & opt. & \PLAY, \PAUSE, \RECORD\\
\header{Range}                  & r  & opt. & \PLAY, \PAUSE, \RECORD\\
\header{Referer}                & R  & opt. & all\\
\header{Require}                & R  & req. & all\\
\header{Retry-After}            & r  & opt. & all\\
\header{RTP-Info}               & r  & req. & \PLAY\\
\header{Scale}                  & g  & opt. & \PLAY, \RECORD\\
\header{Session}                & g  & req. & all but \OPTIONS\\
\header{Server}                 & r  & opt. & all\\
\header{Speed}                  & g  & opt. & \PLAY\\
\header{Transport}              & g  & req. & \SETUP\\
\header{Unsupported}            & r  & req. & all\\
\header{User-Agent}             & R  & opt. & all\\
\header{Vary}                   & r  & opt. & all\\
\header{Via}                    & g  & opt. & all\\
\header{WWW-Authenticate}       & r  & opt. & all\\
\end{tabular}
\end{small}
\end{center}
\caption{Overview of RTSP header fields}
\label{tab:headers}
\end{table}

\subsection{Accept}
\label{sec:Accept}

The \header{Accept} request-header field can be used to specify certain
presentation description content types which are acceptable for the
response.  \motivation{The ``level'' parameter for presentation
descriptions is properly defined as part of the MIME type registration,
not here.}

See [H14.1] for syntax.

Example of use:
\begin{verbatim}
  Accept: application/rtsl, application/sdp;level=2
\end{verbatim} 

\subsection{Accept-Encoding}
\label{sec:Accept-Encoding}

See [H14.3]

\subsection{Accept-Language}
\label{sec:Accept-Language}

See [H14.4].  Note that the language specified applies to the
presentation description and any reason phrases, not the media content.

\begin{changebar}
\subsection{Accept-Ranges}
\label{sec:Accept-Ranges}

\end{changebar}

\subsection{Allow}
\label{sec:Allow}

The \header{Allow} entity-header field lists the methods supported by
the resource identified by the request-URI.  The purpose of this field
is to strictly inform the recipient of valid methods associated with the
resource.  An \header{Allow} header field must be present in a 405
(Method Not Allowed) response.

Example of use:
\begin{verbatim}
  Allow: SETUP, PLAY, RECORD, SET_PARAMETER
\end{verbatim}

\subsection{Authorization}
\label{sec:Authorization}

See [H14.8]

\subsection{Bandwidth}
\label{sec:Bandwidth}

The \header{Bandwidth} request-header field describes the estimated
bandwidth available to the client, expressed as a positive integer and
measured in bits per second.  The bandwidth available to the client may
change during an RTSP session, e.g., due to modem retraining.

\begin{syntax}
Bandwidth &=& "Bandwidth" ":" 1*DIGIT
\end{syntax}

Example:
\begin{verbatim}
  Bandwidth: 4000
\end{verbatim}

\subsection{Blocksize}
\label{sec:Blocksize}

The \header{Blocksize} request-header field is sent from the client to
the media server asking the server for a particular media packet size. 
This packet size does not include lower-layer headers such as IP, UDP,
or RTP.  The server is free to use a blocksize which is lower than the
one requested.  The server {\MAY} truncate this packet size to the closest
multiple of the minimum, media-specific block size, or override it with
the media-specific size if necessary.  The block size {\MUST} be a positive
decimal number, measured in octets.  The server only returns an error
(416) if the value is syntactically invalid.

\begin{syntax}
Blocksize &=& "Blocksize" ":" 1*DIGIT
\end{syntax}

\subsection{Cache-Control}
\label{sec:Cache-Control}

The \header{Cache-Control} general-header field is used to specify
directives that {\MUST} be obeyed by all caching mechanisms along the
request/response chain.

Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application, since
the directives may be applicable to all recipients along the
request/response chain.  It is not possible to specify a cache-directive
for a specific cache.

\header{Cache-Control} should only be specified in a {\SETUP} request
and its response.  Note:  Cache-Control does {\em not} govern the
caching of responses as for HTTP, but rather of the stream identified by
the {\SETUP} request.  Responses to RTSP requests are not cacheable,
except for responses to {\DESCRIBE}.

\begin{syntax}
Cache-Control   & = & "Cache-Control" ":" 1\#cache-directive\\
cache-directive & = & cache-request-directive\\
                &$|$& cache-response-directive
\\
cache-request-directive  & = & "no-cache"\\
                         &$|$& "max-stale"\\
                         &$|$& "min-fresh"\\
                         &$|$& "only-if-cached"\\
                         &$|$& cache-extension
\\
cache-response-directive & = & "public"\\
                         &$|$& "private"\\
                         &$|$& "no-cache"\\
                         &$|$& "no-transform"\\
                         &$|$& "must-revalidate"\\
                         &$|$& "proxy-revalidate"\\
                         &$|$& "max-age" "=" delta-seconds\\
                         &$|$& cache-extension\\
\\
cache-extension          & = & token [ "=" ( token $|$ quoted-string ) ]
\end{syntax}

\begin{description}
\item[\header{no-cache}:] Indicates that the media stream {\MUSTNOT} be
cached anywhere.  This allows an origin server to prevent caching even
by caches that have been configured to return stale responses to client
requests.

\item[\header{public}:] Indicates that the media stream is cacheable by any
cache.

\item[\header{private}:] Indicates that the media stream is intended for
a single user and {\MUSTNOT} be cached by a shared cache.  A private
(non-shared) cache may cache the media stream.

\item[\header{no-transform}:] An intermediate cache (proxy) may find it
useful to convert the media type of a certain stream.  A proxy might,
for example, convert between video formats to save cache space or to
reduce the amount of traffic on a slow link.  Serious operational
problems may occur, however, when these transformations have been
applied to streams intended for certain kinds of applications.  For
example, applications for medical imaging, scientific data analysis and
those using end-to-end authentication all depend on receiving a stream
that is bit-for-bit identical to the original entity-body.  Therefore,
if a response includes the no-transform directive, an intermediate cache
or proxy {\MUSTNOT} change the encoding of the stream.  Unlike HTTP, RTSP
does not provide for partial transformation at this point, e.g.,
allowing translation into a different language.

\item[\header{only-if-cached}:] In some cases, such as times of
extremely poor network connectivity, a client may want a cache to return
only those media streams that it currently has stored, and not to
receive these from the origin server.  To do this, the client may
include the only-if-cached directive in a request.  If it receives this
directive, a cache {\SHOULD} either respond using a cached media stream
that is consistent with the other constraints of the request, or respond
with a 504 (Gateway Timeout) status.  However, if a group of caches is
being operated as a unified system with good internal connectivity, such
a request {\MAY} be forwarded within that group of caches.

\item[\header{max-stale}:] Indicates that the client is willing to
accept a media stream that has exceeded its expiration time.  If
max-stale is assigned a value, then the client is willing to accept a
response that has exceeded its expiration time by no more than the
specified number of seconds.  If no value is assigned to max-stale, then
the client is willing to accept a stale response of any age.

\item[\header{min-fresh}:] Indicates that the client is willing to
accept a media stream whose freshness lifetime is no less than its
current age plus the specified time in seconds.  That is, the client
wants a response that will still be fresh for at least the specified
number of seconds.

\item[\header{must-revalidate}:] When the \header{must-revalidate}
directive is present in a {\SETUP} response received by a cache, that
cache {\MUSTNOT} use the entry after it becomes stale to respond to a
subsequent request without first revalidating it with the origin server. 
That is, the cache must do an end-to-end revalidation every time, if,
based solely on the origin server's \header{Expires}, the cached
response is stale.)

\end{description}

\subsection{Conference}
\label{sec:Conference}

The \header{Conference} request-header field establishes a logical
connection between a pre-established conference and an RTSP stream.  The
\header{conference-id} must not be changed for the same RTSP session.

\begin{syntax}
Conference &=& "Conference" ":" conference-id
\end{syntax}

Example:
\begin{verbatim}
  Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
\end{verbatim}

A response code of 452 (Conference Not Found) is returned if the
\header{conference-id} is not valid.

\subsection{Connection}
\label{sec:Connection}

See [H14.10]

\subsection{Content-Base}
\label{sec:Content-Base}

See [H14.11]

\subsection{Content-Encoding}
\label{sec:Content-Encoding}

See [H14.12]

\subsection{Content-Language}
\label{sec:Content-Language}

See [H14.13]

\subsection{Content-Length}
\label{sec:Content-Length}

The \header{Content-Length} general-header field contains the length of
the content of the method (i.e.  after the double CRLF following the
last header).  Unlike HTTP, it {\MUST} be included in all messages that
carry content beyond the header portion of the message.  If it is
missing, a default value of zero is assumed.  It is interpreted
according to [H14.14].

\subsection{Content-Location}
\label{sec:Content-Location}

See [H14.15]

\subsection{Content-Type}
\label{sec:Content-Type}

See [H14.18].  Note that the content types suitable for RTSP are likely
to be restricted in practice to presentation descriptions and
parameter-value types.

\subsection{CSeq}
\label{sec:CSeq}

The \header{CSeq} general-header field specifies the sequence number for
an RTSP request-response pair.  This field {\MUST} be present in all
requests and responses.  For every RTSP request containing the given
sequence number, the corresponding response will have the same
number.  Any retransmitted request must contain the same sequence number
as the original (i.e.  the sequence number is {\em not} incremented for
retransmissions of the same request).

\begin{syntax}
CSeq &=& "Cseq" ":" 1*DIGIT
\end{syntax}

\subsection{Date}
\label{sec:Date}

See [H14.19].

\subsection{Expires}
\label{sec:Expires}

The \header{Expires} entity-header field gives a date and time after
which the description or media-stream should be considered stale.  The
interpretation depends on the method:

\begin{description}
\item[{\DESCRIBE} response:] The \header{Expires} header indicates a
date and time after which the description should be considered stale.

\end{description}

A stale cache entry may not normally be returned by a cache (either a
proxy cache or an user agent cache) unless it is first validated with
the origin server (or with an intermediate cache that has a fresh copy
of the entity).  See section \ref{sec:caching} for further discussion of
the expiration model.

The presence of an \header{Expires} field does not imply that the original
resource will change or cease to exist at, before, or after that time.

The format is an absolute date and time as defined by \header{HTTP-date}
in [H3.3]; it {\MUST} be in \header{RFC1123-date} format:

\begin{syntax}
Expires &=& "Expires" ":" HTTP-date
\end{syntax}

An example of its use is

\begin{verbatim}
  Expires: Thu, 01 Dec 1994 16:00:00 GMT
\end{verbatim}

RTSP/1.0 clients and caches {\MUST} treat other invalid date formats,
especially including the value ``0'', as having occurred in the past
(i.e., already expired).

To mark a response as ``already expired,'' an origin server should use
an \header{Expires} date that is equal to the \header{Date} header
value.  To mark a response as ``never expires,'' an origin server should
use an \header{Expires} date approximately one year from the time the
response is sent.  RTSP/1.0 servers should not send \header{Expires}
dates more than one year in the future.

The presence of an \header{Expires} header field with a date value of some
time in the future on a media stream that otherwise would by default be
non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a \header{Cache-Control} header field (Section
\ref{sec:Cache-Control}).

\subsection{From}
\label{sec:From}

See [H14.22].

\subsection{Host}
\label{sec:Host}

The \header{Host} HTTP request header field is not needed for RTSP.  It
should be silently ignored if sent.

\subsection{If-Match}
\label{sec:If-Match}

See [H14.25].

The \header{If-Match} request-header field is especially useful for
ensuring the integrity of the presentation description, in both the case
where it is fetched via means external to RTSP (such as HTTP), or in the
case where the server implementation is guaranteeing the integrity of
the description between the time of the {\DESCRIBE} message and the
{\SETUP} message.

The identifier is an opaque identifier, and thus is not specific to any
particular session description language.

\subsection{If-Modified-Since}
\label{sec:If-Modified-Since}

The \header{If-Modified-Since} request-header field is used with the
{\DESCRIBE} and {\SETUP} methods to make them conditional.  If the
requested variant has not been modified since the time specified in this
field, a description will not be returned from the server ({\DESCRIBE})
or a stream will not be set up ({\SETUP}).  Instead, a 304 (Not
Modified) response will be returned without any message-body.

\begin{syntax}
If-Modified-Since &=& "If-Modified-Since" ":" HTTP-date
\end{syntax}

An example of the field is:

\begin{verbatim}
  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
\end{verbatim}

\subsection{Last-Modified}
\label{sec:Last-Modified}

The \header{Last-Modified} entity-header field indicates the date and
time at which the origin server believes the presentation description or
media stream was last modified.  See [H14.29].  For the methods
{\DESCRIBE} or {\ANNOUNCE}, the header field indicates the last
modification date and time of the description, for {\SETUP} that of the
media stream.

\subsection{Location}
\label{sec:Location}

See [H14.30].

\subsection{Proxy-Authenticate}
\label{sec:Proxy-Authenticate}

See [H14.33].

\subsection{Proxy-Require}
\label{sec:Proxy-Require}

The \header{Proxy-Require} request-header field is used to indicate
proxy-sensitive features that {\MUST} be supported by the proxy.  Any
\header{Proxy-Require} header features that are not supported by the
proxy {\MUST} be negatively acknowledged by the proxy to the client if
not supported.  Servers should treat this field identically to the
\header{Require} field.

See Section~\ref{sec:Require} for more details on the mechanics of this
message and a usage example.

\subsection{Public}
\label{sec:Public}

See [H14.35].

\subsection{\header{Range}}
\label{sec:Range}

The \header{Range} request and response header field specifies a range
of time.  The range can be specified in a number of units.  This
specification defines the \header{smpte} (Section~\ref{sec:smpte}),
\header{npt} (Section~\ref{sec:npt}), and \header{clock}
(Section~\ref{sec:clock}) range units.  Within RTSP, byte ranges
[H14.36.1] are not meaningful and {\MUSTNOT} be used.  The header may
also contain a \header{time} parameter in UTC, specifying the time at
which the operation is to be made effective.  Servers supporting the
\header{Range} header {\MUST} understand the NPT range format and
{\SHOULD} understand the SMPTE range format.  The \header{Range}
response header indicates what range of time is actually being played or
recorded.  If the \header{Range} header is given in a time format that
is not understood, the recipient should return 501 (Not Implemented).

Ranges are half-open intervals, including the lower point, but excluding
the upper point.  In other words, a range of $a-b$ starts exactly at
time $a$, but stops just before $b$. Only the start time of a media unit
such as a video or audio frame is relevant. As an example, assume that
video frames are generated every 40 ms. A range of $10.0-10.1$ would
include a video frame starting at 10.0 or later time and would include a
video frame starting at 10.08, even though it lasted beyond the
interval. A range of $10.0-10.08$, on the other hand, would exclude the
frame at 10.08.

\begin{syntax}
Range            &=& "Range" ":" 1\#ranges-specifier [ ";" "time" "=" utc-time ]\\
ranges-specifier &=& npt-range $|$ utc-range $|$ smpte-range
\end{syntax}

Example:
\begin{verbatim}
  Range: clock=19960213T143205Z-;time=19970123T143720Z
\end{verbatim}

\motivation{The notation is similar to that used for the HTTP/1.1
\cite{rfc2068} \header{byte-range} header.  It allows clients to select an
excerpt from the media object, and to play from a given point to the end
as well as from the current location to a given point.  The start of
playback can be scheduled for any time in the future, although a server
may refuse to keep server resources for extended idle periods.}

\subsection{Referer}
\label{sec:Referer}

See [H14.37].  The URL refers to that of the presentation description,
typically retrieved via HTTP.

\subsection{Retry-After}
\label{sec:Retry-After}

See [H14.38].

\subsection{Require}
\label{sec:Require}

The \header{Require} request-header field is used by clients to query
the server about options that it may or may not support.  The server
MUST respond to this header by using the \header{Unsupported} header to
negatively acknowledge those options which are NOT supported.

\motivation{This is to make sure that the client-server interaction will
proceed without delay when all options are understood by both sides, and
only slow down if options are not understood (as in the case above). 
For a well-matched client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation mechanisms.  In
addition, it also removes state ambiguity when the client requires
features that the server does not understand.}

\begin{syntax}
Require &=& "Require" ":" 1\#option-tag\\
\end{syntax}

Example:
\begin{verbatim}
C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
        CSeq: 302
        Require: funky-feature
        Funky-Parameter: funkystuff

S->C:   RTSP/1.0 551 Option not supported
        CSeq: 302
        Unsupported: funky-feature

C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
        CSeq: 303

S->C:   RTSP/1.0 200 OK
        CSeq: 303
\end{verbatim}

In this example, ``funky-feature'' is the feature tag which indicates to
the client that the fictional \header{Funky-Parameter} field is required. 
The relationship between ``funky-feature'' and \header{Funky-Parameter} is
not communicated via the RTSP exchange, since that relationship is an
immutable property of ``funky-feature'' and thus should not be
transmitted with every exchange.

Proxies and other intermediary devices {\SHOULD} ignore features that are
not understood in this field.  If a particular extension requires that
intermediate devices support it, the extension should be tagged in the
\header{Proxy-Require} field instead (see
Section~\ref{sec:Proxy-Require}).

\subsection{RTP-Info}
\label{sec:RTP-Info}

The \header{RTP-Info} response-header field is used to set RTP-specific
parameters in the {\PLAY} response.

\begin{description}
\item[\header{url}:] Indicates the stream URL which for which the following
RTP parameters correspond.

\item[\header{seq}:] Indicates the sequence number of the first packet of
the stream.  This allows clients to gracefully deal with packets when
seeking.  The client uses this value to differentiate packets that
originated before the seek from packets that originated after the seek. 

\item[\header{rtptime}:] Indicates the RTP timestamp corresponding to
the time value in the \header{Range} response header.  (Note:  For
aggregate control, a particular stream may not actually generate a
packet for the \header{Range} time value returned or implied.  Thus,
there is no guarantee that the packet with the sequence number indicated
by \header{seq} actually has the timestamp indicated by
\header{rtptime}.) The client uses this value to calculate the mapping
of RTP time to NPT.

\motivation{A mapping from RTP timestamps to NTP timestamps (wall clock) is
available via RTCP.  However, this information is not sufficient to
generate a mapping from RTP timestamps to NPT.  Furthermore, in order to
ensure that this information is available at the necessary time
(immediately at startup or after a seek), and that it is delivered
reliably, this mapping is placed in the RTSP control channel.

In order to compensate for drift for long, uninterrupted presentations,
RTSP clients should additionally map NPT to NTP, using initial RTCP sender
reports to do the mapping, and later reports to check drift against the
mapping.
}

\end{description}

Syntax:
\begin{syntax}
RTP-Info        &=& "RTP-Info" ":" 1\#rtsp-info-spec \\
rtsp-info-spec  &=& stream-url 1*parameter \\
stream-url      &=& quoted-url $|$ unquoted-url \\
unquoted-url    &=& "url" "=" safe-url\\
                   &$|$& ";" "mode" = $<$"$>$ 1\#Method $<$"$>$\\
quoted-url      &=& "url" "=" $<$"$>$ needquote-url $<$"$>$ \\
safe-url        &=& url \\ 
needquote-url   &=& url \\
url             &=& ( absoluteURI $|$ relativeURI ) \\
parameter       &=&   ";" "seq" "=" 1*DIGIT\\
                &$|$& ";" "rtptime" "=" 1*DIGIT\\
\end{syntax}

Additional constraint: safe-url MUST NOT contain the semicolon (";") or comma (",") characters.  The quoted-url form SHOULD only be used when a URL does not meet the safe-url constraint, in order to ensure compatibility with implementations conformant to RFC 2326 \cite{rfc2326}. 

absoluteURI and relativeURI are defined in RFC 2396 \cite{rfc2396}.

Example:
\begin{verbatim}
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
          url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
\end{verbatim}

\subsection{Scale}
\label{sec:Scale}

A scale value of 1 indicates normal play or record at the normal forward
viewing rate. If not 1, the value corresponds to the rate
with respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate (``fast forward'') and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 has
normal play time increase at twice the wallclock rate. For every second
of elapsed (wallclock) time, 2 seconds of content will be delivered.
A negative value indicates reverse direction.

Unless requested otherwise by the \header{Speed} parameter, the data
rate {\SHOULD} not be changed.  Implementation of scale changes depends
on the server and media type.  For video, a server may, for example,
deliver only key frames or selected key frames.  For audio, it may
time-scale the audio while preserving pitch or, less desirably, deliver
fragments of audio.

The server should try to approximate the viewing rate, but may restrict
the range of scale values that it supports.  The response {\MUST} contain
the actual scale value chosen by the server.

If the request contains a \header{Range} parameter, the new scale value
will take effect at that time.

\begin{syntax}
Scale &=& "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
\end{syntax}

Example of playing in reverse at 3.5 times normal rate:

\begin{verbatim}
  Scale: -3.5
\end{verbatim}

\subsection{Speed}
\label{sec:Speed}

The \header{Speed} request-header field requests the server to deliver
data to the client at a particular speed, contingent on the server's
ability and desire to serve the media stream at the given speed. 
Implementation by the server is {\OPTIONAL}.  The default is the bit
rate of the stream.

The parameter value is expressed as a decimal ratio, e.g., a value of
2.0 indicates that data is to be delivered twice as fast as normal.  A
speed of zero is invalid.  If the request contains a \header{Range}
parameter, the new speed value will take effect at that time.

\begin{syntax}
  Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
\end{syntax}

Example:
\begin{verbatim}
  Speed: 2.5
\end{verbatim}

Use of this field changes the bandwidth used for data delivery.  It is
meant for use in specific circumstances where preview of the
presentation at a higher or lower rate is necessary.  Implementors
should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation may
be necessary.  When data is delivered over UDP, it is highly recommended
that means such as RTCP be used to track packet loss rates.

\subsection{Server}
\label{sec:Server}

See [H14.39]

\subsection{Session}
\label{sec:Session}

The \header{Session} request-header and response-header field identifies
an RTSP session started by the media server in a {\SETUP} response and
concluded by \header{TEARDOWN} on the presentation URL.  The session
identifier is chosen by the media server (see
Section~\ref{sec:session-id}) and {\MUST} be returned in the {\SETUP}
response.  Once a client receives a \header{Session} identifier, it
{\MUST} return it for any request related to that session. 

\begin{syntax}
  Session &=& "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
\end{syntax}

The \header{timeout} parameter is only allowed in a response header. 
The server uses it to indicate to the client how long the server is
prepared to wait between RTSP commands before closing the session due to
lack of activity (see Section~\ref{sec:machine}).  The timeout is
measured in seconds, with a default of 60 seconds (1 minute).

Note that a session identifier identifies an RTSP session across
transport sessions or connections.  Control messages for more than one
RTSP URL may be sent within a single RTSP session.  Hence, it is
possible that clients use the same session for controlling many streams
constituting a presentation, as long as all the streams come from the
same server.  (See example in Section~\ref{sec:examples}).  However,
multiple ``user'' sessions for the same URL from the same client MUST
use different session identifiers.  \motivation{The session identifier
is needed to distinguish several delivery requests for the same URL
coming from the same client.}

The response 454 (Session Not Found) is returned if the session
identifier is invalid.

\subsection{Timestamp}
\label{sec:Timestamp}

The \header{Timestamp} general-header field describes when the client
sent the request to the server.  The value of the timestamp is of
significance only to the client and may use any timescale.  The server
MUST echo the exact same value and {\MAY}, if it has accurate information
about this, add a floating point number indicating the number of seconds
that has elapsed since it has received the request.  The timestamp is
used by the client to compute the round-trip time to the server so that
it can adjust the timeout value for retransmissions.

\begin{syntax}
Timestamp &=& "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]\\
delay     &=& *(DIGIT) [ "." *(DIGIT) ]\\
\end{syntax}

\subsection{Transport}
\label{sec:Transport}

The \header{Transport} request-header field indicates which transport
protocol is to be used and configures its parameters such as destination
address, compression, multicast time-to-live and destination port for a
single stream.  It sets those values not already determined by a
presentation description.

Transports are comma separated, listed in order of preference. 
Parameters may be added to each transport, separated by a semicolon.

The \header{Transport} header field {\MAY} also be used to change certain
transport parameters.  A server {\MAY} refuse to change parameters of an
existing stream.

The server {\MAY} return a \header{Transport} response-header field in the
response to indicate the values actually chosen.

A \header{Transport} request header field may contain a list of transport
options acceptable to the client, in the form of multiple
\header{transport-spec} entries.  In that case, the server {\MUST} return
a single option (\header{transport-spec}) which was actually chosen.

\begin{changebar}
A \header{transport-spec} transport option may only contain one of any
given parameter within it.  Parameters may be given in any order.
Additionally, it may only contain the \header{unicast} or
\header{multicast} transport parameter.
\end{changebar}

\motivation{The \header{Transport} header field is restricted to
describing a single RTP stream.  (RTSP can also control multiple streams
as a single entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies designs of
firewalls.}

The syntax for the transport specifier is
\begin{syntax}
{\it transport}/{\it profile}/{\it lower-transport}.
\end{syntax}

The default value for the ``lower-transport'' parameters is specific to
the profile.  For \header{RTP/AVP}, the default is \header{UDP}.

Below are the configuration parameters associated with transport:

General parameters:
\begin{description}

\item[\header{unicast} $|$ \header{multicast}:] This parameter is a
mutually exclusive indication of whether unicast or multicast delivery
will be attempted.  One of the two values {\MUST} be specified.  Clients
that are capable of handling both unicast and multicast transmission
{\MUST} indicate such capability by including two full transport-specs
with separate parameters for each.

\begin{changebar}
\item[\header{destination}:] The address to which a stream will be sent. 
The client may specify the destination address with the
\header{destination} parameter.  To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a server
{\SHOULD} authenticate the client and {\SHOULD} log such attempts before
allowing the client to direct a media stream to an address not chosen by
the server.  This is particularly important if RTSP commands are issued
via UDP, but implementations cannot rely on TCP as reliable means of
client identification by itself.
\end{changebar}

\item[\header{source}:] If the source address for the stream is
different than can be derived from the RTSP endpoint address (the server
in playback or the client in recording), the source address {\MAY} be
specified. 

\motivation{This information may also be available through SDP. 
However, since this is more a feature of transport than media
initialization, the authoritative source for this information should be
in the {\SETUP} response.}

\item[\header{layers}:] The number of multicast layers to be used for this
media stream. The layers are sent to consecutive addresses starting at
the \header{destination} address.

\item[\header{mode}:] The \header{mode} parameter indicates the methods
to be supported for this session.  Valid values are {\PLAY} and
{\RECORD}.  If not provided, the default is {\PLAY}. 

\item[\header{append}:] If the \header{mode} parameter includes
{\RECORD}, the \header{append} parameter indicates that the media
data should append to the existing resource rather than overwrite it. 
If appending is requested and the server does not support this, it MUST
refuse the request rather than overwrite the resource identified by the
URI.  The \header{append} parameter is ignored if the \header{mode}
parameter does not contain {\RECORD}.

\item[\header{interleaved}:] The \header{interleaved} parameter implies
mixing the media stream with the control stream in whatever protocol is
being used by the control stream, using the mechanism defined in
Section~\ref{sec:binary}.  The argument provides the channel number to
be used in the \$ statement.  This parameter may be specified as a
range, e.g., {\tt interleaved=4-5} in cases where the transport choice
for the media stream requires it.

\motivation{This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and the other for
RTCP.}

\end{description}

Multicast-specific:
\begin{description}
\item[\header{ttl:}] multicast time-to-live.
\end{description}

RTP-specific:
\begin{description}

\item[\header{port}:] This parameter provides the RTP/RTCP port pair for
a multicast session.  It is specified as a range, e.g., {\tt
port=3456-3457}.

\item[\header{client\_port}:] This parameter provides the unicast
RTP/RTCP port pair on the client where media data and control
information is to be sent.  It is specified as a range, e.g., {\tt
port=3456-3457}.

\item[\header{server\_port}:] This parameter provides the unicast
RTP/RTCP port pair on the server where media data and control
information is to be sent.  It is specified as a range, e.g., {\tt
port=3456-3457}. 

\item[\header{ssrc}:] The \header{ssrc} parameter indicates the RTP SSRC
\cite[Sec.~3]{rfc1889} value that should be (request) or will be
(response) used by the media server.  This parameter is only valid for
unicast transmission.  It identifies the synchronization source to be
associated with the media stream, and is expressed as an eight digit 
hexidecimal value.

\end{description}

\begin{syntax}
Transport &=& "Transport" ":" 1\#transport-spec\\
transport-spec     & = & transport-id *parameter\\
transport-id       & = & transport-protocol "/" profile ["/" lower-transport]\\
                   & &   {\rm ; no LWS is allowed inside transport-id }\\
transport-protocol & = & "RTP" $|$ token\\
profile            & = & "AVP" $|$ token\\
lower-transport    & = & "TCP" $|$ "UDP" $|$ token\\
parameter          & = & ";" ( "unicast" $|$ "multicast" )\\
                   &$|$& ";" "source" [ "=" address ]\\
                   &$|$& ";" "destination" [ "=" address ]\\
                   &$|$& ";" "interleaved" "=" channel [ "-" channel ]\\
                   &$|$& ";" "append"\\
                   &$|$& ";" "ttl" "=" ttl\\
                   &$|$& ";" "layers" "=" 1*DIGIT\\
                   &$|$& ";" "port" "=" port [ "-" port ]\\
                   &$|$& ";" "client\_port" "=" port [ "-" port ]\\
                   &$|$& ";" "server\_port" "=" port [ "-" port ]\\
                   &$|$& ";" "source" "=" address\\
                   &$|$& ";" "ssrc" "=" ssrc\\
                   &$|$& ";" "mode" "=" mode-spec\\
ttl                & = & 1*3(DIGIT)\\
port               & = & 1*5(DIGIT)\\
ssrc               & = & 8*8(HEX)\\
channel            & = & 1*3(DIGIT)\\
address            & = & host\\
mode-spec          & = & $<$"$>$ 1\#mode $<$"$>$ $|$ mode\\
mode               & = & "PLAY" $|$ "RECORD" $|$ token\\
\end{syntax}

Below is a usage example, showing a client advertising the capability to
handle multicast or unicast, preferring multicast.  Since this is a
unicast-only stream, the server responds with the proper transport
parameters for unicast.

\begin{verbatim}
  C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
        CSeq: 302
        Transport: RTP/AVP;multicast;mode="PLAY",
            RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

  S->C: RTSP/1.0 200 OK
        CSeq: 302
        Date: 23 Jan 1997 15:35:06 GMT
        Session: 47112344
        Transport: RTP/AVP;unicast;client_port=3456-3457;
            server_port=6256-6257;mode="PLAY"
\end{verbatim}


\subsection{Unsupported}
\label{sec:Unsupported}

The \header{Unsupported} response-header field lists the features not
supported by the server.  In the case where the feature was specified
via the \header{Proxy-Require} field (Section~\ref{sec:Require}), if
there is a proxy on the path between the client and the server, the
proxy {\MUST} insert a response message with a status code of 551
(Option Not Supported).

See Section~\ref{sec:Require} for a usage example. 

\begin{syntax}
Unsupported &=& "Unsupported" ":" 1\#option-tag\\
\end{syntax}

\subsection{User-Agent}
\label{sec:User-Agent}

See [H14.42]

\subsection{Vary}
\label{sec:Vary}

See [H14.43]

\subsection{Via}
\label{sec:Via}

See [H14.44].

\subsection{WWW-Authenticate}
\label{sec:WWW-Authenticate}

See [H14.46].
