Skip to main content

14 Examples

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

14.1 Media on Demand (Unicast)​

Client C requests a movie from media servers A ( audio.example.com) and V (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.

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

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.

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

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.

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

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 SETUP and one control message is required per stream to set up transport parameters.

This keeps the syntax of the Transport header simple and allows easy parsing of transport information by firewalls.

14.3 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:

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

Note the different URL in the SETUP command, and then the switch back to the aggregate URL in the 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:

C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 CSeq: 3

In the worst case, servers should send back:

S->C RTSP/1.0 460 Only aggregate operation allowed CSeq: 3

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

C->S SETUP rtsp://foo.com/test.wav RTSP/1.0 Transport: rtp/avp/udp;client_port=6970-6971;mode=play CSeq: 2

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

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

C->W: GET /concert.sdp HTTP/1.1 Host: www.example.com

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

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

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

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

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: [email protected]%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: [email protected]%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

14.6 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 ANNOUNCE method to provide meta-information about the recorded session to the server.

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 [email protected] 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

Last updated on