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

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

Tables~\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'' response headers, type ``e'' 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 'r' will be send in every
request of this type; merely, that client (for response headers) and
server (for request headers) MUST implement them.  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, {\sf DESCRIBE} and {\sf GET\_PARAMETER} fall into
this class.

If the field content does not apply to the particular resource, the
server MUST return status 456 (Header Field Not Valid for Resource). 

\begin{table}[htbp]
\begin{center}
\begin{small}
\begin{tabular}{lccl}
Header                 & type & support & methods\\ 
\hline
Accept                 & R  & opt. & entity\\
Accept-Encoding        & R  & opt. & entity\\
Accept-Language        & R  & opt. & all\\
Authorization          & R  & opt. & all\\
Bandwidth              & R  & opt. & all\\
Blocksize              & R  & opt. & all but OPTIONS, TEARDOWN\\
Cache-Control          & g  & opt. & SETUP\\
Conference             & R  & opt. & SETUP\\
Connection             & g  & req. & all\\
Content-Base           & e  & opt. & entity\\
Content-Encoding       & e  & req. & SET\_PARAMETER\\
Content-Encoding       & e  & req. & DESCRIBE, ANNOUNCE\\
Content-Language       & e  & req. & DESCRIBE, ANNOUNCE\\
Content-Length         & e  & req. & SET\_PARAMETER, ANNOUNCE\\
Content-Length         & e  & req. & entity\\
Content-Location       & e  & opt. & entity\\
Content-Type           & e  & req. & SET\_PARAMETER, ANNOUNCE\\
Content-Type           & r  & req. & entity\\
CSeq                   & g  & req. & all\\
Date                   & g  & opt. & all\\
Expires                & e  & opt. & DESCRIBE, ANNOUNCE\\
From                   & R  & opt. & all\\
If-Modified-Since      & R  & opt. & DESCRIBE, SETUP\\
Last-Modified          & e  & opt. & entity\\
Proxy-Authenticate     &    &      & \\
Proxy-Require          & R  & req. & all\\
Public                 & r  & opt. & all\\
Range                  & R  & opt. & PLAY, PAUSE, RECORD\\
Range                  & r  & opt. & PLAY, PAUSE, RECORD\\
Referer                & R  & opt. & all\\
Require                & R  & req. & all\\
Retry-After            & r  & opt. & all\\
RTP-Info               & r  & req. & PLAY\\
Scale                  & Rr & opt. & PLAY, RECORD\\
Session                & Rr & req. & all but SETUP, OPTIONS\\
Server                 & r  & opt. & all\\
Speed                  & Rr & opt. & PLAY\\
Transport              & Rr & req. & SETUP\\
Unsupported	           & r  & req. & all\\
User-Agent             & R  & opt. & all\\
Via                    & g  & opt. & all\\
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 {\sf 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.

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

The {\sf Allow} response 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 {\sf 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 {\sf 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}

This 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 is a strictly positive
decimal number and measured in octets.  The server only returns an error
(416) if the value is syntactically invalid.

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

The 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.

Cache-Control should only be specified in a {\sf 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 {\sf
SETUP} request. Responses to RTSP requests are not cacheable, except for
responses to {\sf 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[{\sf no-cache}:] Indicates that the media stream MUST NOT 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[{\sf public}:] Indicates that the media stream is cachable by any
cache.

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

\item[{\sf no-transform}:] An intermediate cache (proxy) may find it
useful to convert the media type of 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 MUST
NOT 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[{\sf 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[{\sf 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[{\sf 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[{\sf must-revalidate}:] When the must-revalidate directive is
present in a {\sf SETUP} response received by a cache, that cache MUST
NOT use the entry after it becomes stale to respond to a subsequent
request without first revalidating it with the origin server.  (I.e.,
the cache must do an end-to-end revalidation every time, if, based
solely on the origin server's {\sf Expires}, the cached response is
stale.)

\end{description}

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

This request header field establishes a logical connection between a
conference, established using non-RTSP means, and an RTSP stream.  The
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 (452 Conference Not Found) is returned if the
{\sf conference-id} is not valid.

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

See [H14.10].

TBD: Connection: timeout=<secs>

\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}

This 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.  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}

This field is a mandatory field that specifies the sequence number for
an RTSP request-response pair.  For every RTSP request containing the
given sequence number, there will be a corresponding response having
the same number.

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

See [H14.19].

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

The {\sf 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[{\sf DESCRIBE} response:] The {\sf 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 {\sf 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 {\sf HTTP-date} in
[H3.3]; it MUST be in 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 in the past (i.e., ``already
expired'').

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

The presence of an {\sf 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 cachable, unless
indicated otherwise by a {\sf Cache-Control} header field (Section
\ref{sec:Cache-Control}).

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

See [H14.22].

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

This 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].

This 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 integrety 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 {\sf If-Modified-Since} request-header field is used with the
{\sf DESCRIBE} and {\sf 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 ({\sf DESCRIBE}) or a stream will not be
setup ({\sf 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 {\sf Last-Modified} entity-header field indicates the date and time
at which the origin server believes the entity (presentation description
or media stream) was last modified.  See [H14.29].  For the methods {\sf
DESCRIBE} or {\sf ANNOUNCE}, the header field indicates the last
modification date and time of the description, for {\sf 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 Proxy-Require header is used to indicate proxy-sensitive features
that MUST be stripped by the proxy to the server if not supported.
Furthermore, any Proxy-Require header features that are not supported
by the proxy MUST be negatively acknowledged by the proxy to the client if
not supported.

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

\motivation{We explored using the W3C's PEP proposal \cite{pep} for this
functionality.  However, we determined that such a device was too complex
for our needs.

This field roughly corresponds to the C-PEP field in the PEP draft.
}

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

See [H14.35].

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

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

\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
header.  It allows to select a clip from the media object, to play from
a given point to the end and from the current location to a given point. 
The start of playback can be scheduled for at 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 {\sf Require} header is used by clients to query the server about
features that it may or may not support.  The server MUST respond to
this header by negatively acknowledging those features which are NOT
supported in the {\sf Unsupported} header.

For 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 200 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}

This is to make sure that the client-server interaction will proceed
optimally when all options are understood by both sides, and only slow down
if options aren't 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 doesn't
understand.

\motivation{We explored using the W3C's PEP proposal \cite{pep} for this
functionality.  However, we determined that such a device was too complex
for our needs.

This field roughly corresponds to the PEP field in the PEP draft.
}

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 {\sf
Proxy-Require} field instead (see Section~\ref{sec:session-id}).

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

This field is used to set RTP-specific parameters in the PLAY
response.

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

\item[{\sf 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[{\sf rtptime}:] Indicates the RTP timestamp of the first packet of
the stream.  The client uses this value to calculate the mapping of RTP
time to NPT.

\motivation{This information is also available in RTCP timestamps.
However, 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, it is placed in the RTSP control channel as well.}

\end{description}

Syntax:
\begin{syntax}
RTP-Info        &=& "RTP-Info" ":" 1\#stream-url ";" *parameter\\
stream-url      &=& "url" "=" url\\
parameter       &=& ";" "seq" "=" sequence-number\\
sequence-number &=& 1*(DIGIT)\\
\end{syntax}

Example:
\begin{verbatim}
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=43754027,
          url=rtsp://foo.com/bar.avi/streamid=1;seq=34834738
\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 {\sf 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 {\sf 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}

This request header fields parameter 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 {\sf 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}

This request and response header field identifies an RTSP session,
started by the media server in a {\sf SETUP} response and concluded by
{\sf TEARDOWN} on the presentation URL.  The session identifier is
chosen by the media server (see Section~\ref{sec:session-id}).  Once a
client receives a {\sf Session} identifier, it MUST return it for any
request related to that session.  A server does not have to set up a
session identifier if it has other means of identifying a session, such
as dynamically generated URLs.

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

The {\sf 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 a 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
comprising 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 timestamp general header 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}

This request header 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 tranpsort, separated by a semicolon.

The {\sf Transport} header 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 {\sf Transport} response header in the response
to indicate the values actually chosen.

A {\sf Transport} request header field may contain a list of transport
options acceptable to the client.  In that case, the server MUST return
a single option which was actually chosen. 

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 {\sf RTP/AVP}, the default is {\sf UDP}.

Below are the configuration parameters associated with transport:

General parameters:
\begin{description}

\item[{\sf unicast} $|$ {\sf multicast}] : mutually exclusive indication of
whether unicast or multicast delivery will be attempted.  Default value is
multicast.  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.

\item[{\sf destination}:] The address to which a stream will be sent. 
The client may specify the multicast address with the {\sf destination}
parameter.  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 to avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack.  This is
particularly important if RTSP commands are issued via UDP, but TCP
cannot be relied upon as reliable means of client identification by
itself.  A server SHOULD not allow a client to direct media streams to
an address that differs from the address commands are coming from.

\item[{\sf source}:] Unicast only.  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 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[{\sf layers}:] The number of multicast layers to be used for this
media stream. The layers are sent to consecutive addresses starting at
the {\sf destination} address.

\item[{\sf mode}:] The {\sf mode} parameter indicates the methods to be
supported for this session.  Valid values are {\sf PLAY} and {\sf
RECORD}.  If not provided, the default is {\sf PLAY}.  For {\sf RECORD},
the {\sf append} flag indicates that the media data should be appended
to the existing resource rather than overwriting it.  If appending is
requested and the server does not support this, it MUST refuse the
request rather than overwrite the resouce identified by the URI.  The
{\sf append} parameter is ignored if the {\sf mode} parameter does not
contain {\sf RECORD}.

\item[{\sf interleaved}:] The {\sf 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 the channel number
to be used in the \$ statement.

\end{description}

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

RTP Specific:
\begin{description}

\item[{\sf compressed}:] Boolean parameter indicating compressed RTP
according to RFC XXXX. 

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

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

\item[{\sf ssrc}:] The {\sf 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.

\end{description}

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

Example:  
\begin{verbatim}
  Transport: RTP/AVP;multicast;compressed;ttl=127;mode="PLAY",
             RTP/AVP;unicast;compressed;client_port=3456-3457;mode="PLAY"
\end{verbatim}

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

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

Negative acknowledgement of features not supported by the server.  In the
case where the feature was specified via the 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 message reply with an error
message 506 (Feature not supported).

\motivation{We explored using the W3C's PEP proposal \cite{pep} for this
functionality.  However, we determined that such a device was too complex
for our needs.  

This field roughly corresponds to the PEP-Info and C-PEP-Info in the PEP
draft.
}

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

\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].
