Real-Time Streaming Protocol (RTSP)

November 22nd, 1998

Juha Huuhtanen
Department of Computer Science and Engineering
Helsinki University of Technology
jthiki.fi

Abstract

The traffic in the internet is becoming more and more involved with multimedia applications. To cope with such bandwith-demanding data, specific protocols have been created. The most difficult area is realtime (or realtimish) streams that enable us to make such things as videophonecalls and remote groupworks in much more efficient way. Real Time Streaming Protocol (RTSP), offers robust protocol that can stream multimedia over multicast and unicast in "one to many"-applications. Although the full advantage of RTSP can be harnessed only after most of the Internet is upgraded IPv6, there are already some implementations available.

1. Introduction
2. Realtime protocols in Internet, history
3. Real Time Streaming protocol (RTSP)
3.1. RTSP overview
3.2. Differences between RTSP and HTTP
3.3. The properties of RTSP
3.4. RTSP supported operations
4. Conclusion
5. Glossary
References
More Information

1. Introduction

This document explains the concept of realtime streaming protocol. For proper definition, it must be presented in the right context. We dive first into the history and backgrounds of realtime protocols in general. Secondly we discuss the present situation of the protocols, before we scrutinize the realtime streaming protocol itself. Lastly we take a peek into the future to see what lies ahead.

2. Real-time protocols in Internet, history

The Internet has been used primarily for the reliable data transmission with minimal or no delay constraints. The TCP/IP protocols were designed for this type of traffic and work very well in this context. However, multimedia traffic, which constitutes of a significant portion of potential multicast traffic, possesses different characteristics and hence requires the use of different protocols to provide the necessary services.

For example, if a receiver has to wait for a TCP retransmission, there can be a noticeable and unacceptable delay in playout of the real-time data, whether audio, video, or something else. In addition, the "slow start" TCP congestion-control mechanism can interfere with the audio and video "natural" playout rate. Since there is no fixed path for datagrams to flow across the Internet, there is no mechanism to make sure that the bandwidth needed for multimedia is available between the sender and receiver(s), so quality of service cannot be guaranteed. Additionally, TCP doesn't provide timing information, a critical requirement for multimedia support. [8,9]

Multimedia applications usually do not need the complexity of TCP and, instead, use a simpler transport framework. Most playback algorithms can tolerate missing data way better than long delays caused by retransmission. They don't require guaranteed in-sequence delivery either. Certain protocols have been developed to enhance the Internet and improve support of applications like audio, video and interactive multimedia conferencing. The main protocols are the Real-time Transport protocol (RTP), Real-time Control Protocol (RTCP), Resource Reservation Protocol (RSVP) and Real-Time Streaming Protocol (RTSP) protocols.

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. [8,9]

3. Real Time Streaming protocol (RTSP)

Real Time Streaming Protocol, RTSP, is an application-level protocol. Its goal is to offer robust protocol that can stream multimedia over multicast and unicast in "one to many"-applications. It also supports interoperation between clients and servers from different vendors. It's currently a proposed standard, [7]. The group behind the standard is Multiparty Multimedia Session Control (mmusic) Charter, which works under IETF. Products using RTSP are available today (eg. RealNetworks RealMedia SDK).

3.1. RTSP overview

RTSP takes advantage of streaming which breaks data into many packets sized according to the bandwith 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 idea in RTSP is that it acts as a "network remote control" for multimedia servers.

The Real Time Streaming Protocol is more of a framework than a protocol. It's meant to control multiple datadelivery 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 change from unicast to IP multicasting with RTP. Real Time Streaming Protocol can also be used with RSVP to set up and manage reserved-bandwith streaming sessions. [5,7, 9]

3.2. 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: [7]

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.3. The properties of RTSP

The Real Time Streaming Protocol boasts of very many properties. It is clear that IPv6 has been considered in these: [7]

Extendable (new methods and parametres 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)
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.4. RTSP supported operations

The following operations are supported by RTSP protocol:

Retrieval of media from media server
Invitation of a media server to a conference (media server can be "invited" to join an existing conference, either to play back media into the presentation or to record media in a presentation)
Addition of media to an existing presentation

RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1. [7]

4. Conclusion

Real Time Streaming protocol and the realtime protocols in general offer many, needed improvements to the Internet of the day. Although they are still Proposed standards, they are already in use. The full power of these protocols can be harnessed when IPv6 becomes the basis of Internet architecture. The multicast and quality of service features found in IPv6 are already adopted by some companies to meet the demands of high bandwith media streams. For the common Internet user there is still some years of wait before the IPv6 with its improvements becomes the baseprotocol in the Internet. However, RTSP can already used also by the enduser by using RealNetworks RealPlayers and/or RealMedia SDK. They implement the RTSP protocol as it is in the proposed standard.

5. Glossary

Broadcast, One-to-all transmission where the source sends one copy of the message to all nodes, whether they wish to receive it or not. See Unicast, Multicast

IP Multicast, A one-to-many transmission, in contrast to Unicast, Broadcast.

MBONE, The MBONE (Multicast Backbone) is a virtual network layered on top of the physical Internet to support routing of IP Multicast packets.

QOS, Quality of Service

Real-Time Streaming Protocol (RTSP), RTSP is an application-level protocol for control over the delivery of data with real-time properties to enable controlled, on-demand delivery of real-time data, such as audio and video.

Real-Time Transport Protocol (RTP), RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.

ReSerVation Protocol (RSVP), RSVP, the ReSerVation Protocol, enhances the current Internet architecture with support requests for a specific quality of service (QoS) from the network for particular data streams or flows.

TCP, Transfer Control Protocol. Connection-oriented transfer protocol of TCP/IP Protocol Suite.

UDP, User Datagram Protocol. Connectionless transfer protocol of TCP/IP Protocol Suite

Unicast,Point-to-point transmission requiring the source to send an individual copy of a message to each requester.

URI, Uniform Resource Identifier, the generic term for all types of names and addresses that refer to objects on the World Wide Web. A URL is one kind of URI.

References

[1] Braden R., Ed., Zhang L., Berson S., Herzog S., Jamin S.
RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Status: PROPOSED STANDARD , September 1997 [referenced 22.11.1998]
< ftp://ftp.isi.edu/in-notes/rfc2205.txt>

[2] IETF Multiparty Multimedia Session Control (MMUSIC) Working Group,
31.7.1998 [referenced 22.11.1998]
< http://www.ietf.org/html.charters/mmusic-charter.html>

[3] IETF - The Internet Engineering Task Force
20.10.1998 [referenced 22.11.1998]
<http://www.ietf.org/>

[4] RealNetworks, RealMedia SDK
22.11.1998 [referenced 22.11.1998]
< http://www.real.com/devzone/tools/rmsdk/index.html>

[5] Schulzrinne, H, RTSP: Real-Time Streaming Protocol
[referenced 22.11.1998]
< http://www.cs.columbia.edu/~hgs/rtsp/>

[6] Schulzrinne H.,Casner S., Frederick R. & Jacobson V.
RFC 1889, RTP: A Transport Protocol for Real-Time Applications.
Status: PROPOSED STANDARD, January 1996 [referenced 22.11.1998]
< ftp://ftp.isi.edu/in-notes/rfc1889.txt>

[7] Schulzrinne H.,Rao A., Lanphier R.
RFC 2326, Real Time Streaming Protocol (RTSP).
Status: PROPOSED STANDARD, April 1998 [referenced 22.11.1998]
< ftp://ftp.isi.edu/in-notes/rfc2326.txt>

[8] Stallings, W, "High Speed Networks, TCP/IP and ATM design principles"
Prentice-Hall Inc., 1998. [Referenced 22.11.1998]

[9] Stardust Forums Inc., IP Multicast Initiative (IPMI)
31.7.1998 [referenced 22.11.1998]
<http://www.ipmulticast.com>

More Information

Web Sites

BiteComm, RealNetworks - company backgrounder
http://www.bitecomm.co.uk/Prognet_pages/corp_backgrounder.html">

Chunlei Liu, "Multimedia Over IP: RSVP, RTP, RTCP, RTSP"
http://www.netlab.ohio-state.edu/~jain/cis788-97/ip_multimedia/index.htm

Kho H. S. J., Technology Review Paper On Streaming Video
http://www.fit.qut.edu.au/Student/ITB235/papers/Compress/n1991761/assign1b.htm

Kumar V., MBone-related Mailing List Archives
http://www.mbone.com/lists/ (Mailing Lists; mmusic: confctrl, avt: rem-conf)

National Computer Board - Singapore, Singapore ONE - Technology Guide; Streaming Audio and Video: Progressive Networks
http://www.s-one.gov.sg/developers/pnet.html

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

RealNetworks, Real Time Streaming Protocol (RTSP)
http://www.real.com/devzone/library/fireprot/rtsp/index.html

RSVP information
http://www.isi.edu/div7/rsvp/rsvp-home.html

RTP information
http://www.cs.columbia.edu/~hgs/rtp/

RTSP Resource Center
http://huntleyl.prognet.com/prognet/rt/index.html

Schulzrinne H., "RTSP - Real Time Streaming Protocol"
http://www.cs.columbia.edu/~hgs/rtsp/