Real Time Streaming Protocol
Total Page：16
File Type：pdf, Size：1020Kb
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
Init Ready Playing
Pause Teardown
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]
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