\section{Method Definitions}
\label{sec:methods}

The {\tt method} token indicates the method to be performed on the
resource identified by the {\tt Request-URI}.  The method is
case-sensitive.  New methods may be defined in the future.  Method names
may not start with a \$ character (decimal 24) and must be a {\tt
token}. Methods are summarized in Table~\ref{tab:methods}.

\begin{table}[htpb]
\begin{center}
\begin{tabular}{llll}
method & direction & object & requirement\\
\hline
DESCRIBE       & \CS      & P,S & recommended\\
ANNOUNCE       & \CS, \SC & P,S & optional\\
GET\_PARAMETER & \CS, \SC & P,S & optional\\
OPTIONS        & \CS      & P,S & required\\
PAUSE          & \CS      & P,S & recommended\\
PLAY           & \CS      & P,S & required\\
RECORD         & \CS      & P,S & optional\\
REDIRECT       & \SC      & P,S & optional\\
SETUP          & \CS      & S   & required\\
SET\_PARAMETER & \CS, \SC & P,S & optional\\
TEARDOWN       & \CS      & P,S & required\\
\end{tabular}
\end{center}
\caption{Overview of RTSP methods, their direction, and what objects (P:
presentation, S: stream) they operate on}
\label{tab:methods}
\end{table}

Notes on Table~\ref{tab:methods}:  {\sf PAUSE} is recommended, but not
required in that a fully functional server can be built that does not
support this method, for example, for live feeds.  If a server does not
support a particular method, it MUST return "501 Not Implemented" and a
client SHOULD not try this method again for this server.

\subsection{\sf{OPTIONS}}
\label{sec:OPTIONS}

The behavior is equivalent to that described in [H9.2]. An {\sf OPTIONS}
request may be issued at any time, e.g., if the client is about to try a
non-standard request. It does not influence server state.

Example :
\begin{verbatim}
  C->S:  OPTIONS * RTSP/1.0 1
         Require: implicit-play
         Proxy-Require: gzipped-messages

  S->C:  RTSP/1.0 200 2 OK
         Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
\end{verbatim}

Note that these are necessarily fictional features (one would hope
that we would not purposefully overlook a truly useful feature just so
that we could have a strong example in this section).

\subsection{{\sf DESCRIBE}}
\label{sec:DESCRIBE}

The {\sf DESCRIBE} method retrieves the description of a presentation or
media object identified by the request URL from a server.  It may use
the {\sf Accept} header to specify the description formats that the
client understands.  The server responds with a {\em description} of the
requested resource.

Example:

\begin{verbatim}
  C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 312
        Accept: application/sdp, application/rtsl, application/mheg

  S->C: RTSP/1.0 200 312 OK
        Date: 23 Jan 1997 15:35:06 GMT
        Content-Type: application/sdp
        Content-Length: 376

        v=0 
        o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 
        s=SDP Seminar 
        i=A Seminar on the session description protocol 
        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 
        e=mjh@isi.edu (Mark Handley) 
        c=IN IP4 224.2.17.12/127 
        t=2873397496 2873404696 
        a=recvonly 
        m=audio 3456 RTP/AVP 0 
        m=video 2232 RTP/AVP 31 
        m=whiteboard 32416 UDP WB 
        a=orient:portrait 
\end{verbatim}

\subsection{{\sf ANNOUNCE}}
\label{sec:ANNOUNCE}

The {\sf ANNOUNCE} method serves two purposes:

When sent from client to server, {\sf ANNOUNCE} posts the description of
a presentation or media object identified by the request URL to a
server.  When sent from server to client, {\sf ANNOUNCE} updates the
session description in real-time.

If a new media stream is added to a presentation (e.g., during a live
presentation), the whole presentation description should be sent again,
rather than just the additional components, so that components can be
deleted. 

Example:

\begin{verbatim}
  C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0 312
        Date: 23 Jan 1997 15:35:06 GMT
        Session: 4711
        Content-Type: application/sdp
        Content-Length: 332

        v=0 
        o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 
        s=SDP Seminar 
        i=A Seminar on the session description protocol 
        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 
        e=mjh@isi.edu (Mark Handley) 
        c=IN IP4 224.2.17.12/127 
        t=2873397496 2873404696 
        a=recvonly 
        m=audio 3456 RTP/AVP 0 
        m=video 2232 RTP/AVP 31 

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

\subsection{{\sf SETUP}}
\label{sec:SETUP}

The {\sf SETUP} request for a URI specifies the transport mechanism to be
used for the streamed media.  A client can issue a {\sf SETUP} request for
a stream that is already playing to change transport parameters, which a
server MAY allow(If it does not allow it, it must respond with error 
``45x Method not valid in this state'' ).
For the benefit of any intervening firewalls, a client
must indicate the transport parameters even if it has no influence over
these parameters, for example, where the server advertises a fixed
multicast address.

\motivation{Segregating content desciption into a DESCRIBE message and
transport information in SETUP avoids having firewall to parse numerous
different presentation description formats for information which is
irrelevant to transport.}

The {\sf Transport} header specifies the transport parameters acceptable
to the client for data transmission; the response will contain the
transport parameters selected by the server.

\begin{verbatim}
  C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 302
        Transport: RTP/AVP;port=4588

  S->C: RTSP/1.0 200 302 OK
        Date: 23 Jan 1997 15:35:06 GMT
        Session: 4711
        Transport: RTP/AVP;port=4588
\end{verbatim}

\subsection{{\sf PLAY}}
\label{sec:PLAY}

The {\sf PLAY} method tells the server to start sending data via the
mechanism specified in {\sf SETUP}.  A client MUST NOT issue a {\sf
PLAY} request until any outstanding {\sf SETUP} requests have been
acknowledged as successful.  

The {\sf PLAY} request positions the normal play time to the beginning
of the range specified and delivers stream data until the end of the
range is reached.  {\sf PLAY} requests may be pipelined (queued); a
server MUST queue {\sf PLAY} requests to be executed in order.  That
is, a {\sf PLAY} request arriving while a previous PLAY request is still
active is delayed until the first has been completed.  \motivation{This
allows precise editing.} For example, regardless of how closely spaced
the two PLAY commands in the example below arrive, the server will play
first second 10 through 15 and then, immediately following, seconds 20
to 25 and finally seconds 30 through the end.

\begin{verbatim}
  C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 835
        Session: 4711
        Range: npt=10-15

  C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 836
        Session: 4711
        Range: npt=20-25

  C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 837
        Session: 4711
        Range: npt=30-
\end{verbatim}

See the description of the {\sf PAUSE} request for further examples.

A {\sf PLAY} request without a {\sf Range} header is legal.  It starts
playing a stream from the beginning unless the stream has been paused. 
If a stream has been paused via {\sf PAUSE}, stream delivery resumes at
the pause point.  If a stream is playing, such a {\sf PLAY} request
causes no further action and can be used by the client to test server
liveness.

The {\sf Range} header may also contain a {\sf time} parameter.  This
parameter specifies a time in UTC at which the playback should start. 
If the message is received after the specified time, playback is started
immediately.  The {\sf time} parameter may be used to aid in
synchronisation of streams obtained from different sources.

For a on-demand stream, the server replies back with the actual range
that will be played back.  This may differ from the requested range if
alignment of the requested range to valid frame boundaries is required
for the media source.  If no range is specified in the request, the
current position is returned in the reply.  The unit of the range in the
reply is the same as that in the request.

After playing the desired range, the presentation is automatically
paused, as if a {\sf PAUSE} request had been issued.

The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip.  The playback is to start
at 15:36 on 23 Jan 1997.

\begin{verbatim}
  C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833
        Range: smpte=0:10:20-;time=19970123T153600Z

  S->C: RTSP/1.0 200 833 OK
        Date: 23 Jan 1997 15:35:06 GMT
        Range: smpte=0:10:22-;time=19970123T153600Z
\end{verbatim}

For playing back a recording of a live presentation, it may be desirable
to use {\sf clock} units:

\begin{verbatim}
  C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835
        Range: clock=19961108T142300Z-19961108T143520Z
	
  S->C: RTSP/1.0 200 833 OK
        Date: 23 Jan 1997 15:35:06 GMT
	  
\end{verbatim}

A media server only supporting playback MUST support the {\sf npt}
format and MAY support the {\sf clock} and {\sf smpte} formats.

\subsection{{\sf PAUSE}}
\label{sec:PAUSE}

The {\sf PAUSE} request causes the stream delivery to be interrupted
(halted) temporarily.  If the request URL names a stream, only playback
and recording of that stream is halted.  For example, for audio, this is
equivalent to muting.  If the request URL names a presentation or group
of streams, delivery of all currently active streams within the
presentation or group is halted.  After resuming playback or recording,
synchronization of the tracks MUST be maintained.  Any server resources
are kept. 

The {\sf PAUSE} request may contain a {\sf Range} header specifying when
the stream or presentation is to be halted.  The header must contain
exactly one value rather than a time range.  The normal play time for
the stream is set to that value.  The pause request becomes effective
the first time the server is encountering the time point specified.  If
this header is missing, stream delivery is interrupted immediately on
receipt of the message. 

For example, if the server has play requests for ranges 10 to 15 and 20
to 29 pending and then receives a pause request for NPT 21, it would
start playing the second range and stop at NPT 21.  If the pause request
is for NPT 12 and the server is playing at NPT 13 serving the first play
request, it stops immediately.  If the pause request is for NPT 16, it
stops after completing the first play request and discards the second
play request.

As another example, if a server has received requests to play ranges 10
to 15 and then 13 to 20, that is, overlapping ranges, the PAUSE request
for NPT=14 would take effect while playing the first range, with the
second PLAY request effectively being ignored, assuming the PAUSE
request arrives before the server has started playing the second,
overlapping range.  Regardless of when the PAUSE request arrives, it
sets the NPT to 14.

If the server has already sent data beyond the time specified in the
{\sf Range} header, a {\sf PLAY} would still resume at that point in
time, as it is assumed that the client has discarded data after that point.
This ensures continuous pause/play cycling without gaps.

Example:

\begin{verbatim}
  C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 834
        Session: 1234

  S->C: RTSP/1.0 200 834 OK
        Date: 23 Jan 1997 15:35:06 GMT
\end{verbatim}

\subsection{{\sf TEARDOWN}}
\label{sec:TEARDOWN}

Stop the stream delivery for the given URI, freeing the resources
associated with it.  If the URI is the presentation URI for this presentation,
any RTSP session identifier associated with the session is no longer
valid.  Unless all transport parameters are defined by the session
description, a {\sf SETUP} request has to be issued before the session
can be played again.

Example:

\begin{verbatim}
  C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 892
        Session: 1234

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

\subsection{{\sf GET\_PARAMETER}}
\label{sec:GET_PARAMETER}

The requests retrieves the value of a parameter of a presentation or
stream specified in the URI.  Multiple parameters can be requested in
the message body using the content type {\tt text/rtsp-parameters}. 
Note that parameters include server and client statistics.  IANA
registers parameter names for statistics and other purposes.  {\sf
GET\_PARAMETER} with no entity body may be used to test client or server
liveness (``ping'').

Example:

\begin{verbatim}
  S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 431
        Content-Type: text/rtsp-parameters
        Session: 1234
        Content-Length: 15

        packets_received
        jitter

  C->S: RTSP/1.0 200 431 OK
        Content-Length: 46
        Content-Type: text/rtsp-parameters
	
        packets_received: 10
        jitter: 0.3838
\end{verbatim}

\subsection{{\sf SET\_PARAMETER}}
\label{sec:SET_PARAMETER}

This method requests to set the value of a parameter for a presentation
or stream specified by the URI.

A request SHOULD only contain a single parameter to allow the client to
determine why a particular request failed.  A server MUST allow a
parameter to be set repeatedly to the same value, but it MAY disallow
changing parameter values. If a request fails for any reason, all
parameters should be left in the state prior to the request.

Note: transport parameters for the media stream MUST only be set with
the {\sf SETUP} command. \motivation{Restricting setting transport
parameters to {\sf SETUP} is for the benefit of firewalls.} 

\motivation{The parameters are split in a fine-grained fashion so that
there can be more meaningful error indications.  However, it may make
sense to allow the setting of several parameters if an atomic setting is
desirable.  Imagine device control where the client does not want the
camera to pan unless it can also tilt to the right angle at the same
time.}

A {\sf SET\_PARAMETER} request without parameters can be used as a way
to detect client or server liveness.

Example:

\begin{verbatim}
  C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 421
        Content-type: text/rtsp-parameters

        barparam: barstuff

  S->C: RTSP/1.0 450 421 Invalid Parameter
        Content-Length: 8

        barparam
\end{verbatim}

\subsection{{\sf REDIRECT}}
\label{sec:REDIRECT}

A redirect request informs the client that it must connect to another
server location.  It contains the mandatory header {\sf Location}, which
indicates that the client should issue requests for that URL.  It may
contain the parameter {\sf Range}, which indicates when the redirection
takes effect.\begin{changebar} If the client wants to continue to send
or receive media for this URI, the client MUST issue a {\sf TEARDOWN}
request for the current session and a {\sf SETUP} for the new session at
the designated host.  \end{changebar}

This example request redirects traffic for this URI to the new server at
the given play time:

\begin{verbatim}
  S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 732
        Location: rtsp://bigserver.com:8001
        Range: clock=19960213T143205Z-
\end{verbatim}

\subsection{{\sf RECORD}}
\label{sec:RECORD}

This method initiates recording a range of media data according to the
presentation description.  The timestamp reflects start and end time
(UTC).  If no time range is given, use the start or end time provided in
the presentation description.  If the session has already started,
commence recording immediately.  

The server decides whether to store the recorded data under the
request-URI or another URI.  If the server does not use the request-URI,
the response SHOULD be 201 (Created) and contain an entity which
describes the status of the request and refers to the new resource, and
a {\sf Location} header.

A media server supporting recording of live presentations MUST support
the clock range format; the smpte format does not make sense.

In this example, the media server was previously invited to the
conference indicated.
\begin{verbatim}
  C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 954
        Session: 1234
        Conference: 128.16.64.19/32492374
\end{verbatim}

\subsection{Embedded (Interleaved) Binary Data}
\label{sec:binary}

Certain firewall designs and other circumstances may force a server to
interleave RTSP methods and stream data.  This interleaving should
generally be avoided unless necessary since it complicates client and
server operation and imposes additional overhead. Interleaved binary
data SHOULD only be used if RTSP is carried over TCP.

Stream data such as RTP packets is encapsulated by an ASCII dollar sign
(24 decimal), followed by a one-byte channel identifier, followed by the
length of the encapsulated binary data as a binary, two-byte integer in
network byte order.  The stream data follows immediately afterwards,
without a CRLF, but including the upper-layer protocol headers.  Each \$
block contains exactly one upper-layer protocol data unit, e.g., one RTP
packet.

The channel identifier is defined in the {\sf Transport} header
\ref{sec:Transport}. 

\begin{verbatim}
  C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 2
        Transport: RTP/AVP/TCP;channel=0

  S->C: RTSP/1.0 200 2 OK
        Date: 05 Jun 1997 18:57:18 GMT
        Transport: RTP/AVP/TCP;channel=0
        Session: 12345

  C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 3
        Session: 12345

  S->C: RTSP/1.0 200 3 OK
        Session: 12345
        Date: 05 Jun 1997 18:59:15 GMT
       
  S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
  S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}
\end{verbatim}





