Multimedia Networking

7.2.3 Real-Time Streaming Protocol (RTSP)

Home
Introduction
7.1 Multimedia Networking Applications
7.1.1 Examples of Multimedia Applications
7.1.2 Hurdles for Multimedia in Today's Internet
7.1.3 How Should the Internet Evolve to Support Multimedia Better?
7.1.4 Audio and Video Compression
7.2 Streamimg Stored Audio and Video
7.2.1 Accessing Audio and Video Through a Web Server
7.2.2 Sending Multimedia from a Streaming Server to a Helper Application
7.2.3 Real-Time Streaming Protocol (RTSP)
7.3 Making the Best of the Best-Effort Service: An Internet Phone Example
7.3.1 The Limitations of a Best-Effort Service
7.3.2 Removing Jitter at the Receiver for Audio
7.3.3 Recovering from Packet Loss
7.4 Protocols for Real-Time Interactive Applications
7.4.1 RTP
7.4.2 RTP Control Protocol (RTCP)
7.4.3 SIP
7.4.4 H.323
7.5 Distributing Multimedia: Content Distribution Networks
7.6 Beyond Best Effort
7.6.1 Scenario 1: A 1 Mbps Audio Application and an FTP
7.6.2 Scenario 2: A 1 Mbps Audio Application and a High-Priority FTP Transfer
7.6.3 Scenario 3: A Misbehaving Audio Application and an FTP Transfer
7.6.4 Scenario 4: Two 1 Mbps Audio Applications over an Overload 1.5 Mbps Link
7.7 Scheduling and Policing Mechanisms
7.7.1 Scheduling Mechanisms
7.7.2 Policing: The Leaky Bucket
7.8 Intergrated Services and Differentiated Services
7.8.1 Intserv
7.8.2 Diffserv
7.9 RSVP
7.9.1 The Essence of RSVP
7.9.2 A Few Simple Examples
Real-Time Streaming Protocol (RTSP)

RTSP allows a media player to control the tranmission of a media stream.  Control actions include pause/resume, repositioning of playback, fast-forward, and rewind.  RTSP is an out-of-band protocol.  The RSTP messages are sent out-of-band, whereas the media stream, whose packet structure is not defined by RTSP, is considered "in-band."  RTSP message use a different port number, 544, from the media stream. 
 
The file transfer protocol (FTP) also uses the out-of-band notion.  FTP uses tow client/server pairs of sockets, each pair that transports control information; the other client/server socket pair supports a TCP connection that actually transports the file.  The RTSP channel is in many ways similar to FTP's control channel.
 
The Web browser first rrequests a presentation description file from a Web server.  The presentation description file can have references to serveral continuous-media files as well as directives fro synchronization of the continuous-media files.  Each reference to a continuous-media fiel begins withthe URL method, rtsp://.

kurose_320719_c07f05.gif

The Web server encapsulates the presentation description file in an HTTP response message and sends the message to the browser.  When the browser receives the HTTP response message, the browser invokes a media player based on the content-type field of the message.  The presentation description file includes references to media streams, using the URL method rtsp://.
 
It is interesting to note the similarities between HTTP and RTSP.  All request and response message are in ASCII text, the client employs standardized methods, and the server responds with standardized reply codes.  One important defferece, however, is that the RTSP server keeps track of the state of the client fro each ongoing RTSP session.
 
The client initiates the session with the SETUP request, providing the URL of the file to be streamed and the RTSP version.  The setup message includes the client port number to which the media should be sent over UDP using the RTP packetization protocol.
 
RTSP has facilities that allo clients to stream toward the server.