CMPE 208 – Fall 2006
RTSP
(Real Time Streaming Protocol)
Team: RIGIL
Shahina Ahmed
Kishwer Jabeen
Shilpa Mayanna
Sowmya Ramarao
Submitted to
Prof. Richard Sinn
October 11, 2006
TABLE OF CONTENTS
1. INTRODUCTION............................................................................................................... 3
2. RTSP ORIGIN & HISTORY ............................................................................................ 3
3. RTSP OVERVIEW ............................................................................................................. 3
3.1 DIFFERENCES BETWEEN RTSP AND HTTP................................................................... 4
3.2 THE PROPERTIES OF RTSP ............................................................................................ 4
3.3 WHAT RTSP DOES NOT DO ............................................................................................ 5
3.4 FEATURES OF RTSP ....................................................................................................... 5
3.5 RTSP INTEROPERABILITY ............................................................................................. 5
4. RTSP METHODS ............................................................................................................... 6
4.1 RTSP STATES ................................................................................................................. 7
5. RTSP OPERATION ........................................................................................................... 8
6. SECURITY CONSIDERATIONS .................................................................................. 10
7. CONCLUSION ................................................................................................................. 10
2
1. Introduction
The document covers RTSP (Real Time Streaming protocol). The document states its
evolution, overview, the message format, and working. Finally we end with some of the
security considerations for RTSP.
2. RTSP Origin & History
The Real Time Streaming Protocol (RTSP), was developed by the IETF and published in
1998 as RFC 2326, is a protocol for use in streaming media systems which allows a client to
remotely control a streaming media server, issuing VCR-like commands such as "play" and
"pause", and allowing time-based access to files on a server.
These real-time oriented protocols are designed to be used in both multicast and unicast
network services. Since many real-time applications can save network and server resources
by using IP multicast, the special requirements and characteristics of IP multicast have been
taken into account in these protocols, such as multicast routing, scalability and adaptation to
large numbers of receivers and heterogeneous receivers.
Some RTSP servers use RTP as the transport protocol for the actual audio/video data. Many
RTSP servers use Real Networks' proprietary RDT as the transport protocol.
3. RTSP Overview
The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several
time-synchronized streams of continuous media such as audio and video. It does not typically
deliver the continuous streams itself, although interleaving of the continuous media stream
with the control stream is possible. In other words, RTSP acts as a "network remote control"
for multimedia servers.
RTSP takes advantage of streaming which breaks data into many packets sized according to
the bandwidth available between client and server. When enough packets have been received
by the client, the user's software can be playing one packet, decompressing another and
downloading the third. The user is able to start listening almost immediately without having
to get the entire media file. Both live data feeds and stored clips can be the sources of data.
The Real Time Streaming Protocol is more of a framework than a protocol. It's meant to
control multiple data delivery sessions, provide a way to choose delivery channels such as
UDP, TCP and IP-multicast. The delivery mechanisms are based solely on RTP. RTSP has
been designed to be on top of RTP to both control and deliver realtime content. Thus RTSP
implementations will be able to take advantage of RTP improvements, such as RTP header
compression. Although RTSP can be used with unicast, its use might help to smoothen the
3
change from unicast to IP multicasting with RTP. Real Time Streaming Protocol can also be
used with RSVP to set up and manage reserved-bandwidth streaming sessions.
3.1 Differences between RTSP and HTTP
The RTSP is intentionally similar in syntax and operation to HTTP/1.1. However, it differs in
a number of important aspects from HTTP:






RTSP introduces a number of new methods and has a different protocol identifier.
An RTSP server needs to maintain state by default in almost all cases, as opposed to
the stateless nature of HTTP.
Both an RTSP server and client can issue requests.
Data is carried out-of-band by a different protocol. (There is an exception to this.)
RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, consistent with
current HTML internationalization efforts.
The Request-URI always contains the absolute URI.
This makes "virtual hosting" easier, where a single host with one IP address hosts several
document trees.
RTSP URL is in form rtsp://media.example.com:554/twister/audiotrack, where




rtsp:// is the identifier for TCP rtsp scheme (rtspu:// is used for UDP scheme)
554 is the assumed port for Real-Time Streaming Protocol
twister is the name of the presentation
audiotrack is the name of certain stream in the presentation (this is optional)
3.2 The properties of RTSP
The Real Time Streaming Protocol boasts of many properties. It is clear that IPv6 has been
considered in these:








Extendable (new methods and parameters are easy to add)
Easy to parse (standard HTML or MIME parser can be used)
Secure (HTTP authentication methods, transport and network layer security
mechanisms applicable)
Transport-independent (protocols such as UDP, RDP and TCP applicable)
Multi-server capable (there can be media streams from different servers in one
presentation)
Control of recording devices (both playback and recording control possible)
Separation of stream control and conference initiation (The only requirement is that
the conference initiation protocol either provides or can be used to create a unique
conference identifier)
Suitable for professional applications (frame-level accuracy through SMPTE time
stamps is supported to allow remote digital editing)
4






Presentation description neutral (no particular format imposed, the presentation
description must contain at least one RTSP URI, however)
Proxy and firewall friendly (protocol should be readily handled by both application
and transport-layer firewalls)
HTTP-friendly (RTSP reuses HTTP concepts, where sensible)
Appropriate server control (i.e. servers should not start streaming to clients in such a
way that clients cannot stop the stream)
Transport negotiation (transport method can be negotiated just before streaming)
Capability negotiation(client must have a way to find out if some of the basic features
are disabled in the server)
3.3 What RTSP does not do



Does not define how audio/video is encapsulated for streaming over network.
Does not restrict how streamed media is transported; it can be transported over UDP
or TCP.
Does not specify how the media player buffers audio/video.
3.4 Features of RTSP
The operations supported by RTSP are
 Retrieval and control of media from media server: Clients can request to the media
server a description of the session that is going to begin. The request can be issued via
HTTP, for example. Clients can control the media by requesting the server to deliver
only specified ranges of the stream.
 Invitation of a media server to a conference: Any of the participants to an on-line
conference can invite a media server to join it, for retrieving media files available at
that server, or also for recording purposes.
 Addition of media to an existing presentation: The server can inform clients that
additional media are available for the current session. This is especially useful for
streaming of live contents.
RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1.
3.5 RTSP Interoperability
Interoperability is very important in RTSP. Interoperability on streaming media systems
involves many components such as Players, Servers, and Encoders/Tools. These must share
common mechanisms. Encoders must be able to store content in files that servers can read.
Servers must be able to stream content using protocols that players can understand. Encoders
and tools must also store datatypes in the files in formats that will eventually be understood
by players. It all locks together in the following way:
5
4. RTSP Methods
DESCRIBE
A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data that can
be handled. The reply includes the presentation description, typically in SDP format.
ANNOUNCE
A ANNOUNCE method allows one end to push the other end various types of information.
6
SETUP
A SETUP request specifies how a single media stream must be transported. This must be
done before a PLAY request is sent.
PLAY
A PLAY request causes to play one or all media streams. Play requests can be stacked by
sending multiple PLAY requests.
PAUSE
A PAUSE request temporarily halts one or all media streams, so it can later be resumed with
a PLAY request.
RECORD
The RECORD request can be used to send a stream to the server for storage.
TEARDOWN
A TEARDOWN request is used to terminate the session. It stops all media streams and frees
all session related data on the server.
GET PARAMETER / SET PARAMETER
A GET/ SET PPARAMETER allow the parameters to be exchanged.
REDIRECT
A REDIRECT method causes client to go to another server for part of the presentation.
4.1 RTSP States
Setup
Play
Ready
Init
Teardown
Playing
Pause
7
The RTSP methods that provide a proxy with all of the port information necessary to open
up, map and close ports are SETUP and TEARDOWN. The server needs to maintain session
state to be able to correlate RTSP requests with a stream. Most of the methods in RTSP do
not contribute to state. The methods that play a central role in allocating and using stream
resources on the server are SETUP, PLAY, RECORD, PAUSE, and TEARDOWN.
5. RTSP Operation
Exchange of Commands
8
Message Exchange Format
9
6. Security Considerations
Denial of service:
Sometimes there can be RTSP request streams sent to the server leading to flooding. These
can have no originationg sourse or client If such request exceed a certain number then
legitimate requests can be denied leading to a denial of service attack.
Session hijacking:
RTSP unlike HTTP is a stateful server and uses session ID’s to keep track of sessions.
Session Hijacking is a possible threat to RTSP servrs as sessions can be sniffed and existing
sessions ID’s can be used to steal the session.
Authentication:
After a HTTP GET request sent from the Web Browser and a GET RSP got from the Web
server, there is absolutely no authentication taking place between the media player and media
server. Authentication is at the transport level which again makes RTSP vulnerable to false
clients using media server to get media.
7. Conclusion
Real Time Streaming protocol has brought a lot of changes to the way media
(video/audio/presentation) are streamed and the different ways in which they can be
controlled. Most of the standards proposed are already in use. Bringing a change from IPv4
to Ipv6 can affect the functioning of these protocols in a great way offering higher bandwidth
and better streaming for these real-time protocols.
References:
[1] IETF - The Internet Engineering Task Force
20.10.1998 [referenced 22.11.1998]
<http://www.ietf.org/>
[2] RealNetworks, RealMedia SDK
22.11.1998 [referenced 22.11.1998]
< http://www.real.com/devzone/tools/rmsdk/index.html>
[3] Schulzrinne, H, RTSP: Real-Time Streaming Protocol
[Referenced 22.11.1998]
< http://www.cs.columbia.edu/~hgs/rtsp/>
Websites:
[1] Perkins C.,Kouvelas I., Notes on the 38th IETF - Real-Time Streaming Protocol (RTSP)
http://www.cs.ucl.ac.uk/staff/c.perkins/reports/ietf_38/node3.html
[2] RealNetworks, Real Time Streaming Protocol (RTSP)
http://www.real.com/devzone/library/fireprot/rtsp/index.html
[3] Chunlei Liu, "Multimedia Over IP: RSVP, RTP, RTCP, RTSP"
http://www.netlab.ohio-state.edu/~jain/cis788-97/ip_multimedia/index.htm
10