Movies on Demand

 

To show how RTSP is used, we shall demonstrate the implementation of a Media on Demand Service, borrowed from the standard itself. The client wants to receive audio and video streams from two different media servers A and V respectively. The actual description of the movie is held on a web server W, which contains sufficient information to allow the client to set up the appropriate receiving applications. We assume that the reader is familiar with the Session Description Protocol from Chapter .

     C->W: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

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

           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

The client first requests the description of the protocol. Notice that the request has a sequence number CSeq associated. The response returns with the numeric status code of 200, indicating ``OK''. It returns the sequence number, along with entity headers describing the body of the message. The description of the presentation is held within the message body using the session description protocol. The session consists of two streams, an audio and a video stream.

     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

The client then requests the SETUP of the audio and the video streams, using the Transport header field to indicate the preferred parameters for the RTP streams. The responses confirm these are ok, adding the necessary ports to receive from the server. Importantly, the SETUP responses return session identifiers to be used in associated commands with the appropriate streams in all subsequent messages.

     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

The client then requests that each of the streams are played, specifying the range using SMTPE timestamps. The start times of each of the streams is actually specified as 10 minutes into the stream. The servers respond OK, returning the end of the time range that will be played.

     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

Finally the client requests that the session be ended, tearing down the state associated with the media streams.