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

The following examples refer to stream description formats that are not
standards, such as RTSL.  The following examples are not to be used 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 timeline of the movie.

In this example, the client is only interested in the last part of the
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=control:rtsp://audio.example.com/twister/audio.en
      m=video 0 RTP/AVP 31
      a=control:rtsp://video.example.com/twister/video

C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
      CSeq: 1
      Transport: RTP/AVP/UDP;unicast;client_port=3056-3057

A->C: RTSP/1.0 200 OK
      CSeq: 1
      Session: 12345678
      Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                 server_port=5000-5001

C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
      CSeq: 1
      Transport: RTP/AVP/UDP;unicast;client_port=3058-3059

V->C: RTSP/1.0 200 OK
      CSeq: 1
      Session: 23456789
      Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                 server_port=5002-5003

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

V->C: RTSP/1.0 200 OK
      CSeq: 2
      Session: 23456789
      Range: smpte=0:10:00-0:20:00
      RTP-Info: url=rtsp://video.example.com/twister/video;
	seq=12312232;rtptime=78712811

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

A->C: RTSP/1.0 200 OK
      CSeq: 2
      Session: 12345678
      Range: smpte=0:10:00-0:20:00
      RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
	seq=876655;rtptime=1032181

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

A->C: RTSP/1.0 200 OK
      CSeq: 3

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
      CSeq: 3
      Session: 23456789
      
V->C: RTSP/1.0 200 OK
      CSeq: 3
\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 an
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 transported as independent 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 the 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 an RTSP URL to the
container file.

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

M->C: RTSP/1.0 200 OK
      CSeq: 1
      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
      a=control:rtsp://foo/twister   
      t=0 0
      m=audio 0 RTP/AVP 0	
      a=control:rtsp://foo/twister/audio
      m=video 0 RTP/AVP 26
      a=control:rtsp://foo/twister/video

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

M->C: RTSP/1.0 200 OK
      CSeq: 2
      Transport: RTP/AVP;unicast;client_port=8000-8001;
                 server_port=9000-9001
      Session: 12345678

C->M: SETUP rtsp://foo/twister/video RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8002-8003
      Session: 12345678

M->C: RTSP/1.0 200 OK
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=8002-8003;
                 server_port=9004-9005
      Session: 12345678

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

M->C: RTSP/1.0 200 OK
      CSeq: 4
      Session: 12345678
      RTP-Info: url=rtsp://foo/twister/video;
	seq=9810092;rtptime=3450012

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

M->C: RTSP/1.0 460 Only aggregate operation allowed
      CSeq: 5

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

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

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

M->C: RTSP/1.0 459 Aggregate operation not allowed
      CSeq: 7

\end{verbatim}

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

\subsection{Single Stream Container Files}

Some RTSP servers may treat all files as though they are ``container
files'', yet other servers may not support such a concept.  Because of
this, clients SHOULD use the rules set forth in the session description for
request URLs, rather than assuming that a consistent URL may always be used
throughout.  Here's an example of how a multi-stream server might expect a
single-stream file to be served:

\begin{verbatim}
    C->S  DESCRIBE rtsp://foo.com/test.wav RTSP/1.0
          Accept: application/x-rtsp-mh, application/sdp
          CSeq: 1
          
    S->C  RTSP/1.0 200 OK
          CSeq: 1
          Content-base: rtsp://foo.com/test.wav/
          Content-type: application/sdp
          Content-length: 48
          
          v=0
          o=- 872653257 872653257 IN IP4 172.16.2.187
          s=mu-law wave file
          i=audio test
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:streamid=0
          
    C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          Transport: RTP/AVP/UDP;unicast;
                     client_port=6970-6971;mode="PLAY"
          CSeq: 2
          
    S->C  RTSP/1.0 200 OK
          Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
                     server_port=6970-6971;mode="PLAY"
          CSeq: 2
          Session: 2034820394

    C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
          CSeq: 3
          Session: 2034820394

    S->C  RTSP/1.0 200 OK
          CSeq: 3
          Session: 2034820394
          RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
            seq=981888;rtptime=3781123
\end{verbatim}

Note the different URL in the \header{SETUP} command, and then the switch
back to the aggregate URL in the \header{PLAY} command.  This makes
complete sense when there are multiple streams with aggregate control,
but is less than intuitive in the special case where the number of
streams is one.

In this special case, it is recommended that servers be forgiving of
implementations that send:

\begin{verbatim}
    C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          CSeq: 3
\end{verbatim}

In the worst case, servers should send back:

\begin{verbatim}
    S->C  RTSP/1.0 460 Only aggregate operation allowed
          CSeq: 3
\end{verbatim}

One would also hope that server implementations are also forgiving of
the following:

\begin{verbatim}
    C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode="PLAY"
          CSeq: 2
\end{verbatim}

Since there is only a single stream in this file, it's not ambiguous
what this means.

\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/x-rtsl

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

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

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

      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
      a=control:rtsp://live.example.com/concert/audio

C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
      CSeq: 2
      Transport: RTP/AVP;multicast

M->C: RTSP/1.0 200 OK
      CSeq: 2
      Transport: RTP/AVP;multicast;destination=224.2.0.1;
                 port=3456-3457;ttl=16
      Session: 0456804596

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

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

\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.  
$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
      CSeq: 1
      Accept: application/sdp

M->C: RTSP/1.0 200 1 OK
      Content-type: application/sdp
      Content-Length: 44

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

C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
      CSeq: 2
      Transport: RTP/AVP;multicast;destination=225.219.201.15;
                 port=7000-7001;ttl=127
      Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

M->C: RTSP/1.0 200 OK
      CSeq: 2
      Transport: RTP/AVP;multicast;destination=225.219.201.15;
                 port=7000-7001;ttl=127
      Session: 91389234234
      Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
      CSeq: 3
      Session: 91389234234

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

\subsection{Recording}

The conference participant client $C$ asks the media server $M$ to
record the audio and video portions of a meeting.  The client uses the
\header{ANNOUNCE} method to provide meta-information about the recorded
session to the server.

\begin{verbatim}

C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
      CSeq: 90
      Content-Type: application/sdp
      Content-Length: 121

      v=0
      o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
      s=IETF Meeting, Munich - 1
      i=The thirty-ninth 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 OK
      CSeq: 90

C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
      CSeq: 91
      Transport: RTP/AVP;multicast;destination=224.0.1.11;
                 port=21010-21011;mode=record;ttl=127

M->C: RTSP/1.0 200 OK
      CSeq: 91
      Session: 50887676
      Transport: RTP/AVP;multicast;destination=224.0.1.11;
                 port=21010-21011;mode=record;ttl=127

C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
      CSeq: 92
      Session: 50887676
      Transport: RTP/AVP;multicast;destination=224.0.1.12;
                 port=61010-61011;mode=record;ttl=127

M->C: RTSP/1.0 200 OK
      CSeq: 92
      Transport: RTP/AVP;multicast;destination=224.0.1.12;
                 port=61010-61011;mode=record;ttl=127

C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
      CSeq: 93
      Session: 50887676
      Range: clock=19961110T1925-19961110T2015

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