\section{Examples}
\label{sec:examples}

The following examples reference stream description formats that are not
finalized, such as RTSL and SDP.  Please do not use these examples as a
reference for those formats.

\subsection{Media on Demand (Unicast)}

Client $C$ requests a movie from media servers $A$ ({\tt
audio.example.com}) and $V$ ({\tt video.example.com}).  The media
description is stored on a web server $W$.  The media description
contains descriptions of the presentation and all its streams, including the
codecs that are available, dynamic RTP payload types, the protocol stack
and content information such as language or copyright restrictions.  It
may also give an indication about the time line of the movie.

In our example, the client is only interested in the last part of the
movie.  The server requires authentication for this movie.

\begin{verbatim}
C->W: GET /twister.sdp HTTP/1.1
      Host: www.example.com
      Accept: application/sdp

W->C: HTTP/1.0 200  OK
      Content-Type: application/sdp

      v=0
      o=- 2890844526 2890842807 IN IP4 192.16.24.202
      s=RTSP Session
      m=audio 0 RTP/AVP 0
      a=murl:rtsp://audio.example.com/twister/audio.en
      m=video 0 RTP/AVP 31
      a=murl:rtsp://audio.example.com/twister/video

C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 1
      Transport: rtp/udp;port=3056

A->C: RTSP/1.0 200 1 OK
      Session: 1234

C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 1
      Transport: rtp/udp;port=3058

V->C: RTSP/1.0 200 1 OK
      Session: 1235

C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 2
      Session: 1235
      Range: smpte=0:10:00-

V->C: RTSP/1.0 200 2 OK

C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 2
      Session: 1234
      Range: smpte=0:10:00-

A->C: RTSP/1.0 200 2 OK

C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 3
      Session: 1234

A->C: RTSP/1.0 200 3 OK

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 3
      Session: 1235
      
V->C: RTSP/1.0 200 3 OK
\end{verbatim}

Even though the audio and video track are on two different servers, and
may start at slightly different times and may drift with respect to each
other, the client can synchronize the two using standard RTP methods, in
particular the time scale contained in the RTCP sender reports. 

\subsection{Streaming of a Container file}

For purposes of this example, a container file is a storage entity in
which multiple continuous media types pertaining to the same end-user
presentation are present.  In effect, the container file represents a
RTSP presentation, with each of its components being RTSP streams. 
Container files are a widely used means to store such presentations. 
While the components are essentially transported as independant streams,
it is desirable to maintain a common context for those streams at the
server end.

\motivation {This enables the server to keep a single storage handle
open easily.  It also allows treating all the streams equally in case of
any prioritization of streams by the server.}

It is also possible that the presentation author may wish to prevent
selective retrieval of the streams by client in order to preserve the
artistic effect of the combined media presentation.  Similarly, in such
a tightly bound presentation, it is desirable to be able to control all
the streams via a single control message using an aggregate URL.

The following is an example of using a single RTSP session to control
multiple streams.  It also illustrates the use of aggregate URLs.

Client $C$ requests a presentation from media server $M$.  The movie is
stored in a container file.  The client has obtained a RTSP URL to the
container file.

\begin{verbatim}
C->M: DESCRIBE rtsp://foo/twister  RTSP/1.0 1

M->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp
      Content-Length: 164

      v=0
      o=- 2890844256 2890842807 IN IP4 172.16.2.93
      s=RTSP Session
      i=An Example of RTSP Session Usage
      c=IN URL rtsp://foo/twister   # aggregate URL 
      t=0 0
      m=audio 0 RTP/AVP 0	
      c=IN URL rtsp://foo/twister/audio
      m=video 0 RTP/AVP 26
      c=IN URL rtsp://foo/twister/video

C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 2
      Transport: RTP/AVP;port=8000

M->C: RTSP/1.0 200 2 OK
      Session: 1234

C->M: SETUP rtsp://foo/twister/video RTSP/1.0 3
      Transport: RTP/AVP;port=8002
      Session: 1234

M->C: RTSP/1.0 200 3 OK
      Session: 1234

C->M: PLAY  rtsp://foo/twister  RTSP/1.0 4
      Range: npt=0-
      Session: 1234

M->C: RTSP/1.0 200 4 OK
      Session: 1234

C->M: PAUSE rtsp://foo/twister/video RTSP/1.0 5
      Session: 1234

M->C: RTSP/1.0 4xx 5 Only aggregate operation allowed

C->M: PAUSE rtsp://foo/twister RTSP/1.0 6
      Session: 1234

M->C: RTSP/1.0 200 6 OK
      Session: 1234

C->M: SETUP rtsp://foo/twister RTSP/1.0 7
      Transport: RTP/AVP;port=10000

M->C: RTSP/1.0 4xx 7 Aggregate operation not allowed

\end{verbatim}

In the first instance of failure, the client tries to pause one
stream (in this case video) of the presentation which is disallowed for
that presentation by the server.  In the second instance, the aggregate
URL may not be used for SETUP and one control message is required per
stream to setup transport parameters.  \motivation {This keeps the
syntax of the Transport header simple, and allows easy parsing of
transport information by firewalls.}

\subsection{Live Media Presentation Using Multicast}

The media server $M$ chooses the multicast address and port.  Here, we
assume that the web server only contains a pointer to the full
description, while the media server $M$ maintains the full description. 

\begin{verbatim}
C->W: GET /concert.sdp HTTP/1.1
      Host: www.example.com

W->C: HTTP/1.1 200 OK
      Content-Type: application/rtsl

      <session>
        <track src="rtsp://live.example.com/concert/audio">
      </session>

C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 1

M->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdp

      v=0
      o=- 2890844526 2890842807 IN IP4 192.16.24.202
      s=RTSP Session
      m=audio 3456 RTP/AVP 0
      c=IN IP4 224.2.0.1/16

C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 2
      Transport: multicast=224.2.0.1; port=3456; ttl=16

C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3

M->C: RTSP/1.0 200 3 OK
\end{verbatim}

The attempt to position the stream fails since this is a live
presentation.

\subsection{Playing media into an existing session}

A conference participant $C$ wants to have the media server $M$ play
back a demo tape into an existing conference.  When retrieving the
presentation description, $C$ indicates to the media server that the
network addresses and encryption keys are already given by the
conference, so they should not be chosen by the server.  The example
omits the simple ACK responses.

\begin{verbatim}
C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0 1
      Accept: application/sdp

M->C: RTSP/1.0 200 1 OK
      Content-type: application/rtsl

      v=0
      o=- 2890844526 2890842807 IN IP4 192.16.24.202
      s=RTSP Session
      m=audio 0 RTP/AVP 0

C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 2
      Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
\end{verbatim}

\subsection{Recording}

\begin{changebar}
The conference participant client $C$ asks the media server $M$ to
record the audio portion of a meeting.  The client uses the {\sf
ANNOUNCE} method to provide meta-information about the recorded session
to the server.

\begin{verbatim}
C->S: SETUP rtsp://server.example.com/meeting/audio RTSP/1.0 91
      Transport: RTP/AVP;mode=record;destination=224.0.1.11;port=21010

S->C: RTSP/1.0 200 91 OK
      Session: 508876

C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 92
      Content-Type: application/sdp

      v=0
      o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
      s=IETF Meeting, Munich - 1
      i=The thirty-nineth IETF meeting will be held in Munich, Germany
      u=http://www.ietf.org/meetings/Munich.html
      e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
      p=IETF Channel 1 +49-172-2312 451
      c=IN IP4 224.0.1.11/127
      t=3080271600 3080703600
      a=tool:sdr v2.4a6
      a=type:test
      m=audio 21010 RTP/AVP 5
      c=IN IP4 224.0.1.11/127
      a=ptime:40
      m=video 61010 RTP/AVP 31
      c=IN IP4 224.0.1.12/127

M->C: RTSP/1.0 200 92 OK

C->M: RECORD rtsp://server.example.com/meeting/audio RTSP/1.0 93
      Session: 508876
      Range: clock 19961110T1925-19961110T2015
\end{verbatim}
\end{changebar}
