draft-ietf-mmusic-rtsp-00.txt   draft-ietf-mmusic-rtsp-01.txt 
INTERNET-DRAFT Anup Rao, Netscape Communications INTERNET-DRAFT Henning Schulzrinne, Columbia University
Anup Rao, Netscape Communications
Rob Lanphier, Progressive Networks Rob Lanphier, Progressive Networks
SUBMITTED: 24th February 1997 Expires: 24th August 1997
SUBMITTED: 26th November 1996 Expires: 26th May 1997
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-rtsp-00.txt> draft-ietf-mmusic-rtsp-01.txt
This is an Internet-Draft. Internet-Drafts are working documents of This is an Internet-Draft. Internet-Drafts are working documents of the
the Internet Engineering Task Force (IETF), its areas, and its Internet Engineering Task Force (IETF), its areas, and its working groups.
working groups. Note that other groups may also distribute working Note that other groups may also distribute working documents as
documents as Internet-Drafts. Internet-Drafts are draft documents Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of
valid for a maximum of six months and may be updated, replaced, or six months and may be updated, replaced, or obsoleted by other documents at
obsoleted by other documents at any time. It is inappropriate to use any time. It is inappropriate to use Internet-Drafts as reference material
Internet-Drafts as reference material or to cite them other than as or to cite them other than as "work in progress."
"work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts Shadow "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), mannari.oz.au
mannari.oz.au (Pacific Rim), ds.internic.net (Us East Coast), or (Pacific Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US West
ftp.isi.edu (US West Coast). Coast).
Prior to the expiration of this draft, the list of open issues may be Prior to the expiration of this draft, the list of open issues may be found
found at the following URL: at the following URL:
http://www.prognet.com/prognet/ra/openissues.html http://www.prognet.com/prognet/rt/openissues.html
This contains a list of issues that have been discussed on the MMUSIC Abstract:
mailing list (confctrl). Many of the points brought up have a rather
holistic effect on the whole document (such as discussions of
converting the protocol to a text-based protocol, or breaking this
draft up into several drafts), while other have rather localized
effect (Appendix C changes). The points that are localized will be
be pointed out in various parts of this draft.
ABSTRACT The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP
provides an extensible framework to enable controlled, on-demand delivery
of real-time data, such as audio and video. Sources of data can include
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based
upon RTP (RFC 1889).
The Real Time Streaming Protocol, or RTSP, is an application-level H. Schulzrinne, A. Rao, R. Lanphier Page 1
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real- time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC
1889). RTSP uses the Session Control Protocol (SCP) (see appendix) to
allow the use of a single TCP connection between the client and
server for controlling delivery of one or more streams of data.
Rao, Lanphier Page 1 Contents
[Note: see "Use Of UDP For Delivery Of Control Messages" in the "Open * 1 Introduction
Issues" document for discussion of alternative control delivery o 1.1 Purpose
(http://www.prognet.com/prognet/rt/openissues.html)] o 1.2 Requirements
o 1.3 Terminology
o 1.4 Protocol Properties
o 1.5 Extending RTSP
o 1.6 Overall Operation
o 1.7 RTSP States
o 1.8 Relationship with Other Protocols
* 2 Notational Conventions
* 3 Protocol Parameters
o 3.1 RTSP Version
o 3.2 RTSP URL
o 3.3 Conference Identifiers
o 3.4 Relative Timestamps
o 3.5 Absolute Time
* 4 RTSP Message
o 4.1 Message Types
o 4.2 Message Headers
o 4.3 Message Body
o 4.4 Message Length
* 5 Request
* 6 Response
o 6.1 Status-Line
+ 6.1.1 Status Code and Reason Phrase
+ 6.1.2 Response Header Fields
* 7 Entity
o 7.1 Entity Header Fields
o 7.2 Entity Body
* 8 Connections
o 8.1 Pipelining
o 8.2 Reliability and Acknowledgements
* 9 Method Definitions
o 9.1 HELLO
o 9.2 GET
o 9.3 SETUP
o 9.4 PLAY
o 9.5 PAUSE
o 9.6 CLOSE
o 9.7 BYE
o 9.11 SESSION
o 9.12 RECORD
o 9.13 Embedded Binary Data
TABLE OF CONTENTS H. Schulzrinne, A. Rao, R. Lanphier Page 2
* 10 Status Codes Definitions
o 10.1 Client Error 4xx
+ 10.1.1 451 Parameter Not Understood
+ 10.1.2 452 Conference Not Found
+ 10.1.3 453 Not Enough Bandwidth
+ 10.1.4 45x Session Not Found
+ 10.1.5 45x Method Not Valid in This State
+ 10.1.6 45x Header Field Not Valid for Resource
+ 10.1.7 45x Invalid Range
+ 10.1.8 45x Parameter Is Read-Only
* 11 Header Field Definitions
o 11.1 Accept
o 11.2 Accept-Encoding
o 11.3 Accept-Language
o 11.4 Allow
o 11.5 Authorization
o 11.6 Bandwidth
o 11.7 Blocksize
o 11.8 Conference
o 11.9 Content-Encoding
o 11.10 Content-Length
o 11.11 Content-Type
o 11.12 Date
o 11.13 If-Modified-Since
o 11.14 Last-modified
o 11.15 Location
o 11.16 Range
o 11.17 Require
o 11.18 Unsupported
o 11.19 Nack-Transport-Require
o 11.20 Transport-Require
o 11.21 Retry-After
o 11.22 Speed
o 11.23 Server
o 11.24 Session
o 11.25 Transport
o 11.26 User-Agent
o 11.27 Via
o 11.28 WWW-Authenticate
* 12 Caching
* 13 Examples
o 13.1 Media on Demand (Unicast)
o 13.2 Live Media Event Using Multicast
o 13.3 Playing media into an existing session
o 13.4 Recording
1.0 INTRODUCTION H. Schulzrinne, A. Rao, R. Lanphier Page 3
3.0 PROTOCOL DESCRIPTION o 14.1 Base Syntax
3.1 Connection Messages o 14.2 Internet Media Type Syntax
3.2 Object Messages o 14.3 Universal Resource Identifier Syntax
3.3 Custom Messages/Events o 14.4 RTSP-specific syntax
3.4 Media specific options and Extension mechanism * 15 Experimental
4.0 EXAMPLES/APPLICATION NOTE o 15.1 Header Field Definitions
5.0 REFERENCES + 15.1.1 Address
6.0 APPENDIXES * 16 Security Considerations
6.1 Appendix A - Data Packets * A State Machines
6.2 Appendix B - Session Control Protocol (SCP) o A.1 Client State Machine
6.3 Appendix C - RTSP Audio Format + A.1.1 Client States
6.4 Appendix D - RTSP Audio Annotations + A.1.2 Notes
6.5 Appendix E - Authors + A.1.3 State Table
o A.2 Server State Machine
+ A.2.1 Server States
+ A.2.2 State Table
* B Open Issues
* C Author Addresses
* D Acknowledgements
* References
1.0 INTRODUCTION 1 Introduction
This document describes the Real Time Streaming Protocol, or RTSP. 1.1 Purpose
The RTSP provides mechanisms to: RTSP establishes and controls either single or several (time-synchronized)
-Request delivery of real-time data streams of continuous media. It does not typically deliver the continuous
-Request a specific transport type and destination for streams itself, although interleaving of the continuous media stream with
the delivery of the data the control stream is possible (Section 9.13).
-Request information about the data in a format-
specific fashion
-Start, stop, and pause the delivery of the data
-Provide random access to various portions of the data
(where applicable)
RTSP uses TCP for delivery of control messages, and allows for a There is no notion of an RTSP connection, but rather a session maintained
variety of delivery options for the data including both multicast and by an identifier. An RTSP session is in no way tied to a transport-level
unicast UDP based on RTP(RFC 1889), and TCP where applicable. RTSP session. During an RTSP session, an RTSP client may open and close many
uses the Session Control Protocol (see appendix) to allow the use of reliable transport connections to the server to issue RTSP requests.
a single TCP connection between the client and server for controlling Alternatively, it may use a connectionless transport protocol such as UDP.
delivery of one or more streams of data. The RTSP specifically uses
one SCP session to deliver control messages and in addition, a new
SCP session might be opened for each real-time object delivered.
Rao, Lanphier Page 2 The protocol is intentionally similar in syntax and operation to HTTP/1.1,
so that extension mechanisms to HTTP can in most cases also be added to
RTSP. However, RTSP differs in a number of important aspects from HTTP:
While the protocol is designed for the streaming of real- time data H. Schulzrinne, A. Rao, R. Lanphier Page 4
regardless of its format, it also provides mechanisms to inquire * RTSP introduces a number of new methods and has a different protocol
about format specific information (compression type, data rate, identifier.
compression-type specific headers and frame boundaries). * An RTSP server needs to maintain state by default in almost all cases,
Considerations for each peer arising from these features are as opposed to the stateless nature of HTTP. (RTSP servers and clients
discussed later in the document. Three typical categories of data MAY use the HTTP state maintenance mechanism [1].)
whose delivery could be controlled with RTSP include: * 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 [2].
1. Real-time stored clips HS: Probably the right thing to do, but may lead to
This category comprises all real-time recordings (primarily confusion with GET.
audio/video). Examples include web sites with audio narration,
stored audio recordings, and video recordings. A typical end-user
application would be an audio/video store site providing excerpts
from its collection on-demand.
2. Real-time live feeds * The Request-URI always contains the absolute URI. Because of backward
This category comprises real-time data which is fed in live at the compatibility with a historical blunder, HTTP/1.1 carries only the
server site rather than being pre-recorded. Examples of this usage absolute path in the request
include a press conference, a live internet radio station, or a
televised shuttle launch.
3. Non real-time stored data This makes virtual hosting easier. However, this is
This category comprises non-real-time data of any MIME type, similar incompatible with HTTP/1.1, which may be a bad idea. Makes
to data served by HTTP servers. This data is provided over a new SCP definition of GET confusing, if it is included in RTSP.
session. While HTTP servers would serve this kind of data in most
cases, it might be advanta- geous to serve non-real-time data with
RTSP. This is typically true of non-real-time data pertaining to
real- time data being served; for example, a text track playing along
with audio/video. This category is meant to provide the capability of
serving non-real-time data through RTSP, and it is strongly
recommended that it be used only when advantageous over existing
[Note: Other scenarios that don't fall into the above categories may The protocol supports the following operations:
be discussed in the "Open Issues" document
2.0 DOCUMENT CONVENTIONS Retrieval of media from media server:
The client can request a session description via HTTP or some other
method. If the session is being multicast, the session description
contains the multicast addresses and ports to be used for the
continuous media. If the session is to be sent only to the client via
unicast, the client provides the destination for security reasons.
The following conventions are used throughout this document: Invitation of a media server to a conference:
A media server can be ``invited'' to join an existing conference,
either to play back media into the session or to record all or a
subset of the media in a session. This mode is useful for distributed
teaching applications. Several parties in the conference may take
turns ``pushing the remote control buttons''.
Byte Order and Alignment Addition of media to an existing session:
All integer fields are carried in network byte order, where the most Particularly for live events, it is useful if the server can tell the
significant byte is sent first. Integers are aligned on their natural client about additional media becoming available.
length: 16 bit integers on even byte boundary, 32 bit integers on 4
byte boundary and so on.
Rao, Lanphier Page 3 H. Schulzrinne, A. Rao, R. Lanphier Page 5
Definitions RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1.
Stream 1.2 Requirements
A stream is data of a distinct type that is sent from server to
client at a rate defined by the server, even if more bandwidth is
available. For a typical video broadcast, for example, one stream
could consist of the video signal, one stream could consist of the
audio data, and one stream could contain the closed caption
information. In most cases, each stream is served at the rate that it
should be rendered by the client.
Global Control Session The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
The SCP session with a well-known session ID, used for exchange of NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and
connection messages described later in this document. ``OPTIONAL'' in this document are to be interpreted as described in RFC
xxxx [3].
Stream Control Session 1.3 Terminology
An SCP session established for each stream, used for
exchange of object messages described later in this
URL Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not
A Uniform Resource Locator or URL is a unique identifier listed here are defined as in HTTP/1.1.
that describes a resource on the Internet. The syntax for
URLs is defined by RFC 1738.
a multiparty, multimedia session, where ``multi'' implies greater than
or equal to one.
Two classes of messages exist in RTSP; those sent on the Client:
Global control session, termed connection messages and The client requests continuous media data from the media server.
those sent on the Stream control session, termed object
messages. Some messages might fall in both categories.
3.1 Connection messages Connection:
A transport layer virtual circuit established between two programs for
the purpose of communication.
Connection messages are used to negotiate protocol version and Continuous media:
possibly client identity. This is common to all streams Data where there is a timing relationship between source and sink,
requested on the connection. that is, the sink must reproduce the timing relationshop that existed
at the source. The most common examples of continuous media are audio
and motion video. Continuous media can be realtime (interactive),
where there is a ``tight'' timing relationship between source and
sink, or streaming (playback), where the relationship is less strict.
Rao, Lanphier Page 4 Entity:
An entity is a participant in a conference. This participant may be
non-human, e.g., a media record or playback server.
HELLO Media server:
The network entity providing playback or recording services for one or
more media streams. Different media streams within a session may
originate from different media servers. A media server may reside on
the same or a different host as the web server the media session is
invoked from.
Upon connection, the client sends a HELLO message to the server H. Schulzrinne, A. Rao, R. Lanphier Page 6
informing it of its version and desire to establish a RTSP
session. The server replies with a HELLO message. The server
need not wait for the clients HELLO message before sending its
own. The message includes protocol version, and optional
character string denoting the user- agent(to be specified). The
communication continues in the lower of the exchanged
versions. If the two sides cannot speak this common version, the
connection is closed.
0 1 2 3 Media session:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 A collection of media streams to be treated as an aggregate, with a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ single time axis. Typically, a client will synchronize in time all
| HELLO | media streams within a media session. An example of a media session is
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a movie consisting of a video and audio track.
| Major | Minor | Sub Protocol | Reserved |
| |
/ User Agent (Optional) /
| |
Major Version (Media) stream:
Specifies the major RTSP version. A single media instance, e.g., an audio stream or a video stream as
well as a single whiteboard or shared application group. When using
RTP, a stream consists of all RTP and RTCP packets created by a source
within an RTP session.
Minor Version [TBD: terminology is confusing since there's an RTP session, which is
Specifies the minor RTSP version within the major version. used by a single RTSP stream.]
Sub Protocol Message:
Specifies the sub-protocol spoken by the sender. For normal The basic unit of RTSP communication, consisting of a structured
client-server communication, this should be 0. sequence of octets matching the syntax defined in Section 14 and
transmitted via a connection or a connectionless protocol.
Reserved Response:
For future use. An RTSP response. If an HTTP response is meant, that is indicated
User Agent Request:
Is an optional null-terminated character string sent by the An RTSP request. If an HTTP request is meant, that is indicated
client to provide information like the client name, machine type, explicitly.
OS etc.
Rao, Lanphier Page 5 Session description:
A session description contains information about one or more media
within a session, such as the set of encodings, network addresses and
information about the content. The session description may take
several different formats, including SDP and SDF.
ID Media parameter:
Parameter specific to a media type that may be changed while the
stream is being played or prior to it.
This message is sent by either a server or a client. The 1.4 Protocol Properties
recipient of this message is asked to prove its identity. A
number of different schemes are possible, the simplest of which
uses a password. More complicated schemes can cause a one time
challenge and response mechanism. Multiple challenge response
steps are possible and implemenation dependent.
A separate ID message allows a server to service a number of RTSP has the following properties:
different classes of users. The ID message can be sent at any
time during the session or may be sent once per URL, depending on
how a service is configured.
0 1 2 3 Extendable:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 New methods and parameters can be easily added to RTSP.
| tag(ID) |
| key type | (reserved) |
| |
/ authentication key /
| |
Key type H. Schulzrinne, A. Rao, R. Lanphier Page 7
Specifies the authentication key type. Authentication of
different strengths might be required in different
situations. This field allows a choice of authentication. It is
up to the client and server to negotiate what level of
authentication is used. Note that different services might be
available at different authentication levels.
Authentication key Easy to parse:
Specifies the key that authenticates the sender. The standard key RTSP can be parsed by standard HTTP or MIME parsers.
types and proper responses will be specified in an extension to
this document.
ID_RESP Secure:
This message is sent in response to an ID message. The entity RTSP re-uses web security mechanisms, either at the transport level
issuing the ID message closes the TCP connection if the response (TLS [5]) or within the protocol itself. All HTTP authentication
is not valid. mechanisms such as basic [4, Section 11.1,] and digest authentication
[6] are directly applicable.
Rao, Lanphier Page 6 Transport-independent:
0 1 2 3 RTSP may use either an unreliable datagram protocol (UDP) [7], a
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 reliable datagram protocol (RDP, not widely used [8]) or a reliable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ stream protocol such as TCP [9] as it implements application-level
| tag(ID_RESP) | reliability.
| key type | response code |
| |
/ response data /
| |
Key type Multi-server capable:
Specifies the authentication key type. Authentication of Each media stream within a session can reside on a different server.
different strength may be required in different situations. This The client automatically establishes several concurrent control
field allows a choice of authentication. It is up to the client sessions with the different media servers. Media synchronization is
and server to negotiate what level of authentication is used. performed at the transport level.
Note that different services might be available at different
authentication levels.
Response code Control of recording devices:
Specifies one of the two possible responses to an ID message: The protocol can control both recording and playback devices, as well
OK as devices that can alternate between the two modes (``VCR'').
Authentication type recognized, response follows.
UNKNOWN Separation of stream control and conference initiation:
Unknown type, ordered list of authentication types follows Stream control is divorced from inviting a media server to a
(can be a null list). conference. The only requirement is that the conference initiation
protocol either provides or can be used to create a unique conference
identifier. In particular, SIP [10] or H.323 may be used to invite a
server to a conference.
Response data Suitable for professional applications:
Specifies the response, depending on the response code. If OK, RTSP supports frame-level accuracy through SMPTE time stamps to allow
then this is the key that authenticates the sender, and the remote digital editing.
format is dictated by the authentication type. If UNKNOWN, then
this is a list of 16-bit response types that are acceptable to
the recipient.
The standard key types and proper responses will be specified in Session description neutral:
an extension to this document. The protocol does not impose a particular session description or
metafile format and can convey the type of format to be used. However,
the session description must contain an RTSP URI.
REDIRECT Proxy and firewall friendly:
The protocol should be readily handled by both application and
transport-layer (SOCKS [11]) firewalls. A firewall may need to
understand the SETUP method to open a ``hole'' for the UDP media
A redirect message informs the client that it must connect to H. Schulzrinne, A. Rao, R. Lanphier Page 8
another server location. When received on the Global control
session, it should be made effective as specified by offset. The
message can also be sent on a Stream control session, in which
case it it relative to the stream.
Rao, Lanphier Page 7 HTTP-friendly:
0 1 2 3 Where sensible, RTSP re-uses HTTP concepts, so that the existing
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 infrastructure can be re-used. This infrastructure includes JEPI (the
+-------------------------------+-------------------------------+ Joint Electronic Payment Initiative) for electronic payments and PICS
| tag (REDIRECT) | (Platform for Internet Content Selection) for associating labels with
+-------------------------------+-------------------------------+ content. However, RTSP does not just add methods to HTTP, since the
| Offset | controlling continuous media requires server state in most cases.
| |
/ URL /
| |
Offset Appropriate server control:
On the Stream control session, specifies the position (in If a client can start a stream, it must be able to stop a stream.
milliseconds) in the media stream at which time the Servers should not start streaming to clients in such a way that
redirection is effective. If received on the global control clients cannot stop the stream.
session, it means that the server is not available after
this time.
URL Transport negotiation:
Is a null-terminated string that identifies the new location for The client can negotiate the transport method prior to actually
the object. This URL is similar to the one specified in the needing to process a continuous media stream.
original FETCH request, described later in this document.
OPTIONS Capability negotiation:
If basic features are disabled, there must be some clean mechanism for
the client to determine which methods are not going to be implemented.
This allows clients to present the appropriate user interface. For
example, if seeking is not allowed, the user interface must be able to
disallow moving a sliding position indicator.
This message is used to negotiate additional functionality. This An earlier requirement in RTSP' was multi-client capability.
can be sent by the client or the server. This is provided as an However, it was determined that a better approach was to make
extension mechanism to extend the protocol without changing the sure that the protocol is easily extensible to the multi-client
version number. Set 0 refers to the global set of options, a scenario. Stream identifiers can be used by several control
universally-agreed upon set. Implementors can use this to streams, so that ``passing the remote'' would be possible. The
negotiate replacements for messages in the current specification; protocol would not address how several clients negotiate access;
however, all implementations must be able to support the core this is left to either a ``social protocol'' or some other floor
messages defined here, and be prepared not to use an option control mechanism.
should the other implementation not be prepared to support the
given option. The maximum size of an option set is 64.
This is defined in the spirit of the TELNET protocol (RFC 854), 1.5 Extending RTSP
which provides a further explanation of how different
implementations may interoperate using this mechanism.
Rao, Lanphier Page 8 RTSP can be extended in three ways, listed in order of the magnitude of
0 1 2 3 changes supported:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (OPTIONS) |
| option set |
| highest option number |
/ /
Option set H. Schulzrinne, A. Rao, R. Lanphier Page 9
Implementors can specify an option set to use for adding custom * Existing methods can be extended with new parameters, as long as these
extensions. In addition, as the protocol matures, certain parameters can be safely ignored by the recipient. (This is equivalent
options may be accepted as universal to all clients,which will be to adding new parameters to an HTML tag.)
placed in the reserved range of option sets. The following ranges * New methods can be added. If the recipient of the message does not
of options are reserved: understand the request, it responds with error code 501 (Not
implemented) and the sender can then attempt an earlier, less
functional version.
* A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
Option set Purpose 1.6 Overall Operation
0 This is a universally accepted set Each media stream and session may be identified by an RTSP URL. The overall
of options session and the properties of the media the session is made up of are
defined by a session description file, the format of which is outside the
scope of this specification. The session description file is retrieved
using HTTP, either from the web server or the media server, typically using
an URL with scheme HTTP.
0x1-0xFFFF Reserved for later allocation The session description file contains a description of the media streams
making up the media session, including their encodings, language, and other
parameters that enable the client to choose the most appropriate
combination of media. In this session description, each media stream is
identified by an RTSP URL, which points to the media server handling that
particular media stream and names the stream stored on that server. Several
media streams can be located on different servers; for example, audio and
video tracks can be split across servers for load sharing. The description
also enumerates which transport methods the server is capable of. If
desired, the session description can also contain only an RTSP URL, with
the complete session description retrieved via RTSP.
0x10000-0xFFFFFFFF Custom extensions (i.e. vendor or Besides the media parameters, the network destination address and port need
organization specific) to be determined. Several modes of operation can be distinguished:
Highest option number Unicast:
Specifies the highest option number that is set or unset. It is The media is transmitted to the source of the RTSP request, with the
used to calculate the length of the bit vectors that follow. This port number picked by the client. Alternatively, the media is
list is zero indexed. transmitted on the same reliable stream as RTSP.
Rao, Lanphier Page 9 Multicast, server chooses address:
The media server picks the multicast address and port. This is the
typical case for a live or near-media-on-demand transmission.
s.d.s.w Multicast, client chooses address:
s.d.s.w If the server is to participate in an existing multicast conference,
^ ^ ^ ^ the multicast address, port and encryption key are given by the
| | | | conference description, established by means outside the scope of this
select do/don't ----------+ | | | specification.
do/don't -------------------+ | |
select will/won't ------------+ |
will/won't ---------------------+
select do/don't 1.7 RTSP States
If set, activates the do/don't flag
do/don't RTSP controls a stream which may be sent via a separate protocol,
If set to 1, means DO and if set to 0, means DON'T. independent of the control channel. For example, RTSP control may occur on
a TCP connection while the data flows via UDP. Thus, data delivery
continues even if no RTSP requests are received by the media server. Also,
during its lifetime, a single media stream may be controlled by RTSP
requests issued sequentially on different TCP connections. Therefore, the
server needs to maintain ``session state'' to be able to correlate RTSP
requests with a stream.
DO indicates the request that the other party perform, or HS: This does not imply that the protocol has to be stateful in
confirmation that you are expecting the other party to perform, the way described here. If state were to be defined by identifier
the indicated option. only, the first PLAY or RECORD request would initiate stream
flow, with no need for SETUP. It has been argued that a separate
setup simplifies the life of firewall writers.
DON'T indicates the demand that the other party stops performing, Many methods in RTSP do not contribute to state. However, there are four
or confirmation that you are no longer expecting the other party that play a central role in defining the allocation and usage of stream
to perform, the indicated option. resources on the server: SETUP, PLAY, PAUSE, and CLOSE. The roles they play
are defined as follows.
select will/won't Step session allocation method session control method
If set, activates the will/won't flag 1 SETUP
will/won't SETUP Causes the server to allocate resources for a stream.
1 means WILL, 0 means WON'T. PLAY Starts data transmission on a stream allocated via SETUP.
PAUSE Temporarily halts a stream, without freeing server resources.
WILL indicates the desire to begin performing, or confirmation CLOSE Frees resources associated with the stream. The session ceases to
that the indicated options are being used. exist on the server.
WON'T indicates the refusal to perform, or continue performing, A client must issue a SETUP request unless all necessary transport
the indicated option. information is already available.
At a minimum, the response to a OPTION is to reply with the 1.8 Relationship with Other Protocols
desire to perform NONE of the requested options.
The Working Group or IETF needs to define and regulate the RTSP has some overlap in functionality with HTTP. It also may interact with
registration process for OPTIONS sets. Currently, no sets are HTTP in that the initial contact with streaming content is often to be made
defined. through a web page. The current protocol specification aims to allow
different hand-off points between a web server and the media server
implementing RTSP. For example, the session description can be retrieved
using HTTP or RTSP. Having the session description be returned by the web
server makes it possible to have the web server take care of authentication
and billing, by handing out a session description whose media identifier
includes an encrypted version of the requestor's IP address and a
timestamp, with a shared secret between web and media server.
GOODBYE However, RTSP differs fundamentally from HTTP in that data delivery takes
Sent only by the client to politely close the RTSP session. place out-of-band, in a different protocol. HTTP is an asymmetric protocol,
where the client issues requests and the server responds. In RTSP, both the
media client and media server can issue requests. RTSP requests are also
not stateless, in that they may set parameters and continue to control a
media stream long after the request has been acknowledged.
The client sends this message to the server to indicate that it Re-using HTTP functionality has advantages in at least two areas,
is done with its requests and wants to terminate the session. namely security and proxies. The requirements are very similar,
so having the ability to adopt HTTP work on caches, proxies and
authentication is valuable.
0 1 2 3 While most real-time media will use RTP as a transport protocol, RTSP is
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 not tied to RTP.
| tag (GOODBYE) |
3.2 OBJECT MESSAGES RTSP assumes the existence of a session description format that can express
both static and temporal properties of a media session containing several
media streams.
These messages are sent on the stream control session (one of 2 Notational Conventions
which exists for each stream). They a used to request objects,
set transport mechanism, and control data delivery.
FETCH Since many of the definitions and syntax are identical to HTTP/1.1, this
This is the first message sent on a new stream control session. specification only points to the section where they are defined rather than
It requests an object of a given name. If the object exists, and copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of
the client is permitted to access it, the server accepts the the current HTTP/1.1 specification (RFC 2068).
request and sends a STREAM_HEADER message to the client. If the
object is non-existent or access is not allowed, the appro-
priate error message is sent to the client.
The client uses this message to request an object (for example, All the mechanisms specified in this document are described in both prose
an audio clip) from the server. The object is specified as an URL. and an augmented Backus-Naur form (BNF) similar to that used in RFC 2068
[H2.1]. It is described in detail in [12].
0 1 2 3 In this draft, we use indented and smaller-type paragraphs to provide
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 background and motivation. Some of these paragraphs are marked with HS, AR
+-------------------------------+-------------------------------+ and RL, designating opinions and comments by the individual authors which
| tag (FETCH) | may not be shared by the co-authors and require resolution.
| Bandwidth (Bits per second) |
| Max Number of Hops | Request Flags |F|M|N|
| |
/ URL (null-terminated) /
| |
Bandwidth 3 Protocol Parameters
Specifies the client's estimate of the bandwidth (in bits per
sec) it has available for a particular stream. The exact bit rate
of the stream is provided by the STREAM_HEADER message from the
server. If the server refuses the request based on insufficient
bandwidth, then the server sends the appropriate error message.
Max Number of Hops 3.1 RTSP Version
Specifies the maximum number of hops. A hop is a connection
between Client, Server or Proxy. For example, the are three hops
for passing through two proxies and connecting to a server. If
set to 0xFFFF, then the number of hops is unlimited.
Request Flags [H3.1] applies, with HTTP replaced by RTSP.
F - Fresh bit, used to override Proxy Cache
M - Multicast capable
N - No Rate (rate unlimited file transfer, used only for TCP.
This could be used for transfering non-real time data, such as
URL - Universal Resource Locator 3.2 RTSP URL
Specifies a null-terminated string which identifies the The ``rtsp'' and ``rtspu'' schemes are used to refer to network resources
location for the object (i.e. RTSP://host-name:port/filename) via the RTSP protocol. This section defines the scheme-specific syntax and
semantics for RTSP URLs.
STREAM_HEADER rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path]
host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1
of RFC 1123>
port = *DIGIT
This message is sent in response to a successful FETCH message. abs_path is defined in [H3.2.1].
It provides the basic information about the stream such as rate,
generic type, and last modification time.
0 1 2 3 Note that fragment and query identifiers do not have a
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 well-defined meaning at this time, with the interpretation left
+-------------------------------+-------------------------------+ to the RTSP server.
| Generic Type (family) |
| Bit Rate (Bits per second) |
| Last Modification Time |
| Reserved |
| Length (milliseconds) |
| Max Packet size (bytes) |
| Flags x|L|C|H|A|U|M|
Generic type (family) The scheme rtsp requires that commands are issued via a reliable protocol
Specifies the type of family, such as RTSP_Audio, etc. Currently, (within the Internet, TCP), while the scheme rtspu identifies an unreliable
RTSP_Audio is defined in the appendix. protocol (within the Internet, UDP).
Bandwidth If the port is empty or not given, port 554 is assumed. The semantics are
Specifies the rate or bandwidth of the stream in bits per second. that the identified resource can be controlled be RTSP at the server
It is set to 0 if non-realtime. listening for TCP (scheme ``rtsp'') connections or UDP (scheme ``rtspu'')
packets on that port of host, and the Request-URI for the resource is
Last Modification Time The use of IP addresses in URLs SHOULD be avoided whenever possible (see
Specifies the last time the object was modified. The specified RFC 1924 [13]).
time is seconds since Jan 01 1970(UTC).
Reserved A media presentation is identified by an textual media identifier, using
Reserved for future use. the character set and escape conventions [H3.2] of URLs []. Requests
described in Section 9 can refer to either the whole presentation or an
individual track within the presentation. Note that some methods can only
be applied to tracks, not presentations. A specific instance of a session,
e.g., one of several concurrent transmissions of the same content, is
indicated by the Session header field (Section 11.24) where needed.
Length For example, the RTSP URL
Specifies the stream length in miliseconds. It is 0 if the object
is live or if it is non-realtime.
Max Packet Size rtsp://media.content.com:554/twister/audiotrack
Specifies the maximum packet size in bytes that the server
supports for the stream.
Flags identifies the audio track within the presentation ``twister'', which can
x: Unicast available be controlled via RTSP requests issued over a TCP connection to port 554 of
L: Live : if set, the stream is live and there is no host media.content.com.
concept of position.
C: Copy : if set, means that the client can save it.
H: Cached : if set, the object is cached on a proxy.
A: if set, stream can be cached by the client
U: UDP Okay : if set, the stream can be sent via a
unreliable channel.
M: Stream is available via Multicast, and a
SET_TRANSPORT message follows providing this
[Note: There has been discussion of providing this This does not imply a standard way to reference tracks in URLs.
information in a session description that is loaded via The session description defines the hierarchical relationships in
HTTP or some other mechanism prior to the RTSP connection the presentation and the URLs for the individual tracks. A
being established. See "Metafiles/Session Descriptions" in session description may name a track 'a.mov' and the whole
http://www.prognet.com/prognet/rt/openissues.html] presentation 'b.mov'.
SET_TRANSPORT The path components of the RTSP URL are opaque to the client and do not
imply any particular file system structure for the server.
This message is sent to set the delivery mechanism for a stream. This decoupling also allows session descriptions to be used with
The client uses this message to request the transport used for non-RTSP media control protocols, simply by replacing the scheme
the data transfer. in the URL.
The server can use this message to inform the client about multicast 3.3 Conference Identifiers
availability (this is the only instance the server sends this
0 1 2 3 Conference identifiers are opaque to RTSP and are encoded using standard
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 URI encoding methods (i.e., LWS is escaped with %). They can contain any
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ octet value. The conference identifier MUST be globally unique. For H.323,
| tag (SET_TRANSPORT) | the conferenceID value is to be used.
|C| | ChannelID |
| synchronization source (SSRC) identifier |
/ Transport specific fields /
C flag : This flag specifies the type of header/framing. conference-id = 1*OCTET ; LWS must be URL-escaped
C = 0 : Standard RTP header Conference identifiers are used to allow to allow RTSP sessions
C = 1 : Compressed/Extensible RTP header to obtain parameters from multimedia conferences the media server
is participating in. These conferences are created by protocols
outside the scope of this specification, e.g., H.323 [15] or SIP
[10]. Instead of the RTSP client explicitly providing transport
information, for example, it asks the media server to use the
values in the conference description instead. If the conference
participant inviting the media server would only supply a
conference identifier which is unique for that inviting party,
the media server could add an internal identifier for that party,
e.g., its Internet address. However, this would prevent that the
conference participant and the initiator of the RTSP commands are
two different entities.
SSRC: 32 bits 3.4 Relative Timestamps
Identifies the synchronization source to be associated with the A relative time-stamp expresses time relative to the start of the clip.
data. This can be used for de-multiplexing by the client of data Relative timestamps are expressed as SMPTE time codes for frame-level
received on the same port. access accuracy. The time code has the format hours:minutes:seconds.frames,
with the origin at the start of the clip. For NTSC, the frame rate is 29.97
frames per second. This is handled by dropping the first frame index of
every minute, except every tenth minute. If the frame value is zero, it may
be omitted.
Channel ID smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ]
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ]
Transport channel Fixed RTP header Compressed RTP header Channel ID Examples:
Unicast UDP Yes Yes 0 10:12:33.40
Multicast UDP Yes Yes 1 3.5 Absolute Time
SCP Yes Yes 2 Absolute time is expressed as ISO 8601 timestamps. It is always expressed
as UTC (GMT).
SCP - compressed Yes Yes 3 utc-range = "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT ; < YYYYMMDD >
utc-time = 6DIGIT ; < HHMMSS >
Note : The client may not send a channel ID of 1. This is Example for November 8, 1996 at 14h37 and 20 seconds UTC:
sent by the server only.
Transport Spcific Fields 19961108T143720Z
Channel ID 0: 4 RTSP Message
0 1 2 3 RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 encoding (RFC 2044). Lines are terminated by CRLF, but receivers should be
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= prepared to also interpret CR and LF by themselves as line terminators.
| port |
Port Text-based protocols make it easier to add optional parameters in
Specifies the port number on which the stream should be sent. a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such
as Tcl, Visual Basic and Perl.
Channel ID 2,3 : The 10646 character set avoids tricky character set switching,
but is invisible to the application as long as US-ASCII is being
used. This is also the encoding used for RTCP. ISO 8859-1
translates directly into Unicode, with a high-order octet of
zero. ISO 8859-1 characters with the most-significant bit set are
represented as 1100001x 10xxxxxx.
0 1 2 3 RTSP messages can be carried over any lower-layer transport protocol that
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 is 8-bit clean.
| session ID | (reserved) |
Session ID Requests contain methods, the object the method is operating upon and
Specifies the SCP session ID that should be associated with this parameters to further describe the method. Methods are idempotent, unless
stream. otherwise noted. Methods are also designed to require little or no state
maintenance at the media server.
Channel ID 1 4.1 Message Types
0 1 2 3 See [H4.1]
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| port |
| address |
Port 4.2 Message Headers
Specifies the port number on which the stream is sent.
Address See [H4.2]
Specifies the multicast group address where the data is
[Note: There is some debate over the best way to address 4.3 Message Body
RTP header compression in the "Compressed RTP section" of
the "RTSP Open Issues" document.
(see http://www.prognet.com/prognet/rt/openissues.html)]
[Note: There has also been debate about what level of RTP See [H4.3]
support to provide. It has been suggested that a server
should be able to stream directly into an RTP based
conference which may contain clients that are not
necessarily RTSP-aware, so long as the requesting
conference client provides control connection proxying.
See the "RTSP Open Issues" document section titled "Joining
Into Existing Conferences"
SET_SPEED 4.4 Message Length
This advisory message sets the speed at which the server delivers When a message-body is included with a message, the length of that body is
data to the client, contingent on the server's ability and desire determined by one of the following (in order of precedence):
to serve the file at the given speed. Implementation by the
server is optional. The default is the bit rate of the stream.
0 1 2 3 1. Any response message which MUST NOT include a message-body (such as
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 the 1xx, 204, and 304 responses) is always terminated by the first
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ empty line after the header fields, regardless of the entity-header
| tag(SET_SPEED ) | fields present in the message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. If a Content-Length header field (section 11.10) is present, its value
| (reserved) |F| in bytes represents the length of the message-body. If this header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ field is not present, a value of zero is assumed.
| speed | 3. By the server closing the connection. (Closing the connection cannot
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ be used to indicate the end of a request body, since that would leave
no possibility for the server to send back a response.)
Note that RTSP does not (at present) support the ``chunked'' transfer
coding and requires the presence of the Content-Length header field.
Given the moderate length of session descriptions returned, the
server should always be able to determine its length, even if it
is generated dynamically, making the chunked transfer encoding
unnecessary. Even though Content-Length must be present if there
is any entity body, the rules ensure reasonable behavior even if
the length is not given explicitly.
5 Request
A request message from a client to a server or vice versa includes, within
the first line of that message, the method to be applied to the resource,
the identifier of the resource, and the protocol version in use.
Request = Request-line CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF
Method = "GET" ; Section
| "SETUP" ; Section
| "PLAY" ; Section
| "PAUSE" ; Section
| "CLOSE" ; Section
| "RECORD" ; Section
| "REDIRECT" ; Section
| "HELLO" ; Section
| "SESSION" ; Section
| "BYE" ; Section
| "SET_PARAMETER" ; Section
| "GET_PARAMETER" ; Section
| extension-method
extendion-method = token
Request-URI = absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
seq-no = 1*DIGIT
Note that in contrast to HTTP/1.1, RTSP requests always contain the
absolute URL (that is, including the scheme, host and port) rather than
just the absolute path.
6 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. Also,
RTSP defines additional status codes and does not define some HTTP codes.
The valid response codes and the methods they can be used with are defined
in the table 1 and 2.
After receiving and interpreting a request message, the recipient responds
with an RTSP response message.
Response = Status-Line ; Section
*( general-header ; Section
| response-header ; Section
| entity-header ) ; Section
[ message-body ] ; Section
6.1 Status-Line
The first line of a Response message is the Status-Line, consisting of the
protocol version followed by a numeric status code, the sequence number of
the corresponding request and the textual phrase associated with the status
code, with each element separated by SP characters. No CR or LF is allowed
except in the final CRLF sequence. Note that the addition of a
Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF
6.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the attempt to
understand and satisfy the request. These codes are fully defined in
section10. The Reason-Phrase is intended to give a short textual
description of the Status-Code. The Status-Code is intended for use by
automata and the Reason-Phrase is intended for the human user. The client
is not required to examine or display the Reason-Phrase.
The first digit of the Status-Code defines the class of response. The last
two digits do not have any categorization role. There are 5 values for the
first digit:
* 1xx: Informational - Request received, continuing process
* 2xx: Success - The action was successfully received, understood, and
* 3xx: Redirection - Further action must be taken in order to complete
the request
* 4xx: Client Error - The request contains bad syntax or cannot be
* 5xx: Server Error - The server failed to fulfill an apparently valid
The individual values of the numeric status codes defined for RTSP/1.0, and
an example set of corresponding Reason-Phrase's, are presented below. The
reason phrases listed here are only recommended - they may be replaced by
local equivalents without affecting the protocol. Note that RTSP adopts
most HTTP/1.1 status codes and adds RTSP-specific status codes in the
starting at 450 to avoid conflicts with newly defined HTTP status codes.
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "203" ; Non-Authoritative Information
| "204" ; No Content
| "205" ; Reset Content
| "206" ; Partial Content
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood}
| "452" ; Conference Not Found}
| "453" ; Not Enough Bandwidth}
| "45x" ; Session Not Found}
| "45x" ; Method Not Valid in This State}
| "45x" ; Header Field Not Valid for Resource}
| "45x" ; Invalid Range}
| "45x" ; Parameter Is Read-Only}
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
RTSP status codes are extensible. RTSP applications are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understand
the class of any status code, as indicated by the first digit, and treat
any unrecognized response as being equivalent to the x00 status code of
that class, with the exception that an unrecognized response MUST NOT be
cached. For example, if an unrecognized status code of 431 is received by
the client, it can safely assume that there was something wrong with its
request and treat the response as if it had received a 400 status code. In
such cases, user agents SHOULD present to the user the entity returned with
the response, since that entity is likely to include human-readable
information which will explain the unusual status.
100 Continue x x x x x x
200 OK x x x x x x
300 Multiple Choices x x x x x
301 Moved Permanently x x x x x
302 Moved Temporarily x x x x x
303 See Other x x x x x
304 Not Modified x x x x x
305 Use Proxy x x x x x
400 Bad Request x x x x x x
401 Unauthorized x x x x x x
402 Payment Required x x x x x x
403 Forbidden x x x x x
404 Not Found x x x x x
405 Method Not Allowed x x x x x x
406 Not Acceptable x x x x x
407 Proxy Authentication Required x x x x x x
408 Request Timeout x x x x x x
409 Conflict
410 Gone x x x x x x
411 Length Required x x x
412 Precondition Failed x x
413 Request Entity Too Large x x
414 Request-URI Too Long x x x x x x
415 Unsupported Media Type x x
45x Only Valid for Stream x x x
45x Invalid parameter
45x Not Enough Bandwidth x
45x Illegal Conference Identifier
45x Illegal Session Identifier x x x x
45x Parameter Is Read-Only
45x Header Field Not Valid
500 Internal Server Error x x x x x x
501 Not Implemented x x x x x x
502 Bad Gateway x x x x x x
503 Service Unavailable x x x x x x
504 Gateway Timeout x x x x x x
505 RTSP Version Not Supported x x x x x x
Table 1: Status codes and their usage with RTSP methods
100 Continue x x x x
200 OK x x x x
300 Multiple Choices x x x
301 Moved Permanently x x x x
302 Moved Temporarily x x x x
303 See Other x x x x
304 Not Modified x x x x
305 Use Proxy x x x x
400 Bad Request x x x x
401 Unauthorized x x x
402 Payment Required x x x
403 Forbidden x x x x
404 Not Found x x x x
405 Method Not Allowed x x x x
406 Not Acceptable x x x x
407 Proxy Authentication x x x x
408 Request Timeout x x x x
409 Conflict x x
410 Gone x x
411 Length Required x x
412 Precondition Failed x x
413 Request Entity Too x x x x
414 Request-URI Too Long x x x x
415 Unsupported Media Type
45x Only Valid for Stream
45x Invalid parameter
45x Not Enough Bandwidth
45x Illegal Conference
45x Illegal Session x x
45x Parameter Is Read-Only x
45x Header Field Not Valid
500 Internal Server Error x x x x
501 Not Implemented x x x x
502 Bad Gateway x x x x
503 Service Unavailable x x x x
504 Gateway Timeout x x x x
505 RTSP Version Not x x x x
Table 2: Status codes and their usage with RTSP methods
6.1.2 Response Header Fields
The response-header fields allow the request recipient to pass additional
information about the response which cannot be placed in the Status-Line.
These header fields give information about the server and about further
access to the resource identified by the Request-URI.
response-header = Location ; Section
| Proxy-Authenticate ; Section
| Public ; Section
| Retry-After ; Section
| Server ; Section
| Vary ; Section
| WWW-Authenticate ; Section
Response-header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental header
fields MAY be given the semantics of response-header fields if all parties
in the communication recognize them to be response-header fields.
Unrecognized header fields are treated as entity-header fields.
7 Entity
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.
In this section, both sender and recipient refer to either the client or
the server, depending on who sends and who receives the entity.
7.1 Entity Header Fields
Entity-header fields define optional metainformation about the entity-body
or, if no body is present, about the resource identified by the request.
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.12
| Content-Language ; Section 14.13
| Content-Length ; Section 14.14
| Content-Type ; Section 14.18
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields to be
defined without changing the protocol, but these fields cannot be assumed
to be recognizable by the recipient. Unrecognized header fields SHOULD be
ignored by the recipient and forwarded by proxies.
7.2 Entity Body
See [H7.2]
8 Connections
RTSP requests can be transmitted in several different ways:
* persistent transport connections used for several request-response
* one connection per request/response transaction;
* connectionless mode.
The type of transport connection is defined by the RTSP URI (Section 3.2).
For the scheme ``rtsp'', a persistent connection is assumed, while the
scheme ``rtspu'' calls for RTSP requests to be send without setting up a
Unlike HTTP, RTSP allows the media server to send requests to the media
client. However, this is only supported for persistent connections, as the
media server otherwise has no reliable way of reaching the client. Also,
this is the only way that requests from media server to client are likely
to traverse firewalls.
8.1 Pipelining
A client that supports persistent connections or connectionless mode MAY
``pipeline'' its requests (i.e., send multiple requests without waiting for
each response). A server MUST send its responses to those requests in the
same order that the requests were received.
8.2 Reliability and Acknowledgements
Requests are acknowledged by the receiver unless they are sent to a
multicast group. If there is no acknowledgement, the sender may resend the
same message after a timeout of one round-trip time (RTT). The round-trip
time is estimated as in TCP (RFC TBD), with an initial round-trip value of
500 ms. An implementation MAY cache the last RTT measurement as the initial
value for future connections. If a reliable transport protocol is used to
carry RTSP, the timeout value MAY be set to an arbitrarily large value.
This can greatly increase responsiveness for proxies operating in
local-area networks with small RTTs. The mechanism is defined
such that the client implementation does not have be aware of
whether a reliable or unreliable transport protocol is being
used. It is probably a bad idea to have two reliability
mechanisms on top of each other, although the RTSP RTT estimate
is likely to be larger than the TCP estimate.
Each request carries a sequence number, which is incremented by one for
each request transmitted. If a request is repeated because of lack of
acknowledgement, the sequence number is incremented.
This avoids ambiguities when computing round-trip time estimates.
[TBD: An initial sequence number negotiation needs to be added for UDP;
otherwise, a new stream connection may see a request be acknowledged by a
delayed response from an earlier ``connection''. This handshake can be
avoided with a sequence number containing a timestamp of sufficiently high
The reliability mechanism described here does not protect against
reordering. This may cause problems in some instances. For example, a CLOSE
followed by a PLAY has quite a different effect than the reverse.
Similarly, if a PLAY request arrives before all parameters are set due to
reordering, the media server would have to issue an error indication. Since
sequence numbers for retransmissions are incremented (to allow easy RTT
estimation), the receiver cannot just ignore out-of-order packets. [TBD:
This problem could be fixed by including both a sequence number that stays
the same for retransmissions and a timestamp for RTT estimation.]
Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
support UDP. The default port for the RTSP server is 554 for both UDP and
A number of RTSP packets destined for the same control end point may be
packed into a single lower-layer PDU or encapsulated into a TCP stream.
RTSP data MAY be interleaved with RTP and RTCP packets. Unlike HTTP, an
RTSP method header MUST contain a Content-Length whenever that method
contains a payload. Otherwise, an RTSP packet is terminated with an empty
line immediately following the method header.
9 Method Definitions
The method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. New methods
may be defined in the future. Method names may not start with a $ character
(decimal 24) and must be a token.
method direction requirement
GET C->S recommended
SETUP C->S recommended
PLAY C->S required
PAUSE C->S recommended
CLOSE C->S required
REDIRECT S->C optional
SESSION S->C optional
RECORD C->S optional
BYE C->S required?
SET_PARAMETER C->S, S->C optional
GET_PARAMETER C->S, S->C optional
Table 3: Overview of RTSP methods
HS: PAUSE is recommend, but not required in that a fully
functional server can be built that does not support this method,
for example, for live feeds. Similarly, SETUP is not needed for a
server that only handles multicast events with transport
parameters set outside of RTSP. GET and BYE are controversial.
RTSP sessions MAY be initiated by a HELLO message. The request URI is "*"
to indicate that the request pertains to the session itself. The primary
use of the HELLO message is to verify the identity of the sender to the
receiver; both sides must authorize one another to enable full access to
server resources. Unauthorized clients may be disconnected or restricted to
a subset of server resources.
In addition, if the optional Require header is present, option tags within
the header indicate features needed by the requestor that are not required
at the version level of the protocol.
Example 1:
C->S: HELLO * RTSP/1.0 1
Require: implicit-play, record-feature
Transport-Require: switch-to-udp-control, gzipped-messages
Note that these are fictional features (though we may want to make them
real one day).
Example 2 (using RFC2069-style authentication only as an example):
S->C: HELLO * RTSP/1.0 1
Authenticate: Digest realm="testrealm@host.com",
Possible errors: 401, Parameter Not Understood
S->C: RTSP/1.0 200 1 OK
Date: 23 Jan 1997 15:35:06 GMT
Nack-Transport-Require: switch-to-udp-control
Note that these are fictional features (though we may want to make them
real one day).
Example 2 (using RFC2069-style authentication only as an example):
C->S: RTSP/1.0 401 1 Unauthorized
Authorization: Digest username="Mufasa",
HS: I consider HELLO superfluous, not fully specified and just
complicating client and server. It is also not clear how this is
supposed to work when a client connects to the server, since it
can't know ahead of time whether the server will issus a HELLO
request. So it may connect, issue a SETUP, be refused and then
somehow guess that it's supposed to wait for HELLO.
Authentication of the client can be readily achieved by standard
HTTP-like methods. On either retrieving the session description
or the first SETUP, the server would refuse with 401, supply the
authentication methods (and nonces) it is willing to accept and
wait for the request to be re-issued with proper authentication.
As with standard web browser, a client can cache the
authentication message for efficiency.
Similarly, the client can ask the server to authenticate itself
with the first request.
Feature announcement can be done using standard HTTP mechanism,
with a well-defined registration mechanism for feature names.
RL: HELLO offers the opportunity to negotiate server features
prior to actually needing them. A client may wish to poll a
server for its features without actually causing any action to
occur, and HELLO offers that opportunity.
9.2 GET
The GET method retrieves a session description from a server. It may use
the Accept header to specify the session description formats that the
client understands.
If the media server has previously been invited to a conference by the
client, the GET request SHOULD contain the Conference header field. If the
GET request contains a conference identifier, the media server MAY locate
the conference description and use the multicast addresses and port numbers
supplied in that description. The media server SHOULD only offer media
types corresponding to the media types currently active within the
conference. If the media server has no local reference to this conference,
it returns status code 452.
The conference invitation should also contain an indication whether the
media server is expected to receive or generate media, or both. (A VCR-like
device would support both directions.) If the invitation does not contain
an indication of the operations to be performed, the media server should
accept and then reject inappropriate operations.
The server responds with a description of the requested resource.
C->S: GET rtsp://server.example.com/fizzle/foo RTSP/1.0 312
Accept: application/sdp, application/sdf, application/mheg
Bandwidth: 4000
S->C: RTSP/1.0 200 312 OK
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
o=mhandley 2890844526 2890842807 IN IP4
s=SDP Seminar
i=A Seminar on the session description protocol
e=mjh@isi.edu (Mark Handley)
c=IN IP4
t=2873397496 2873404696
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
S->C: RTSP/1.0 200 312 OK
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/x-rtsp-mh
Content-Length: 2782
<2782 octets of data containing stream descriptions and
headers for the requested presentation>
The authors disagree amongst themselves as to whether having an
GET method within RTSP is appropriate. The alternative would be
that the stream header would be done as an HTTP GET, and then
RTSP would be used for SETUP, PLAY, etc. RL believes there are a
number of reasons why a GET method is appropriate within RTSP:
* An RTSP GET is a request for header information, while an
HTTP GET is a request for the entire file. For instance, an
RTSP GET on a Quicktime file with the name foo.mov would
mean "please send me the header and packetization
information for foo.mov", whereas an HTTP GET for that file
would mean "please send me foo.mov".
* Assuming the client only has an URL to a resource, it is
highly desireable to get to the point where the client is
actually receiving data all over one connection. Though this
would be possible if one assumed that one can multiplex RTSP
and HTTP on the same connection, there is a question of how
much of a web server would have to be supported in order to
fulfill this simpler requirement.
* Since the RTSP GET contains information such as codec,
packetization, total size, and whether the clip is live or
stored, it is important to insure integrity between the
session description and the media it represents. This
information may be cached by HTTP proxies, but it would be
needed by caching RTSP proxies.
RL and AR feel that the scope and applicability of this message
should be limited, and therefore, it may be appropriate to come
up with another name for this message.
HS believes that this only works if GET is required. Otherwise,
the client has no way of knowing whether to first send a GET or
SETUP. The easy alternative is to have any further descriptive
information that is necessary encoded in the session description.
Thus, the naming does not matter; the resource description can
either have a separate name or the same name if the server can
distinguish variants based on the requested type, as modern web
servers can. (A single URL can return different objects depending
on the content of the Accept fields.) It appears likely that the
RTSP GET will over time acquire all the functionality of the HTTP
GET and thus lead to unnecessary duplication. If the description
is lengthy, the ability to use HTTP caches is likely to
compensate for any additional latency due to having to open two
streams. Also, note that relying on HTTP get does not mean that
this has to be a separate server.
The SETUP request for a URI specifies the transport mechanism to be used
for the streamed media. Note that SETUP makes sense only for an individual
media stream, rather than an aggregate. A client can issue a SETUP request
for a stream that is already playing to change transport parameters.
If the optional Require header is present, option tags within the header
indicate features needed by the requestor that are not required at the
version level of the protocol. The Transport-Require header is used to
indicate proxy-sensitive features that MUST be stripped by the proxy to the
server if not supported. Furthermore, any Transport-Require header features
that are not supported by the proxy MUST be negatively acknowledged by the
proxy to the client if not supported.
HS: In my opinion, the Require header should be replaced by PEP
since PEP is standards-track, has more functionality and somebody
already did the work.
The Transport header specifies the transports acceptable to the client for
data transmission; the response will contain the transport selected by the
C->S: SETUP foo/bar/baz.rm RTSP/1.0 302
Transport: rtp/udp;port=458
S->C: RTSP/1.0 200 302 OK
Date: 23 Jan 1997 15:35:06 GMT
Transport: cush/udp;port=458
9.4 PLAY
The PLAY method tells the server to start sending data via the mechanism
specified in SETUP. A client MUST NOT issue a PLAY request until any
outstanding SETUP request have been acknowledged as successful.
A PLAY request without a Range header is legal. It starts playing a stream
from the beginning unless the stream has been paused. If a stream has been
paused via PAUSE, stream delivery resumes at the pause point. If a stream
is playing, such a PLAY request causes no further action and can be used by
the client to test server liveness.
The following example plays the whole session starting at SMPTE time code
0:10:20 until the end of the clip.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833
Range: smpte=0:10:20-
For playing back a recording of a live event, it may be desirable to use
clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835
Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 833 OK
Date: 23 Jan 1997 15:35:06 GMT
A media server only supporting playback MUST support the smpte format and
MAY support the clock format.
RL says: We had considered optionally overloading PLAY with SETUP
information. This would have potentially allowed a case where one
could implement a minimal RTSP server that only handles the PLAY
command. However, we decided that supporting that minimal of a
server was problematic for a couple of reasons:
* We must be able to negotiate the transport (i.e. have server
acknowledgment) prior to actually needing to deal with the
data. We don't want to have a server start spewing packets
at us before we are ready to deal with them. The server
acknowledgment with setup information MUST arrive before the
first packet.
* We need make sure that we aren't dealing with an allocation
method every time we are dealing with PLAY. We anticipate
the potential of dealing with PLAY frequently when a client
chooses to issue several seeks, and so simplifying this
message is imperative.
HS says: PLAY without SETUP is useful and possible, in particular
if the session description contains all necessary information,
without options. The client knows whether it needs to configure
transport parameters or not. For multicast delivery, for example,
it likely would not have to set additional parameters. I doubt
that allowing one additional parameter is going to greatly
complicate or slow down a server.
The PAUSE request causes the stream delivery to be interrupted (halted)
temporarily. If the request URL names a track, only playback and recording
of that track is halted. If the request URL names a presentation, delivery
of all currently active tracks is halted. After resuming playback or
recording, synchronization of the tracks MUST be maintained. Any server
resources are kept.
C->S: PAUSE /fizzle/foo RTSP/1.0 834
S->C: RTSP/1.0 200 834 OK
Date: 23 Jan 1997 15:35:06 GMT
Stop the stream delivery for the given URI, freeing the resources
associated with it. If the URI is the root node for this session, any
session identifier associated with the session is no longer valid. Unless
all transport parameters are defined by the session description, a SETUP
request has to be issued before the session can be played again.
C->S: CLOSE /fizzle/foo RTSP/1.0 892
S->C: RTSP/1.0 200 892 OK
9.7 BYE
Terminate the session.
C->S: BYE /movie RTSP/1.0 894
S->C: RTSP/1.0 200 894 OK
Date: 23 Jan 1997 15:35:06 GMT
HS: I believe BYE to be unnecessary since CLOSE already frees
resources and session descriptor.
The requests retrieves the value value of a parameter of a session
component specified in the URI. Multiple parameters can be requested in the
message body using the content type text/rtsp-parameters. Note that
parameters include server and client statistics. [HS: registry of parameter
names for statistics and other purposes, possibly using the HTTP feature
registration mechanism.] A GET_PARAMETER with no entity body may be used to
test client or server liveness (``ping'').
S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431
Content-Type: text/rtsp-parameters
Session: 1234
Content-Length: 15
C->S: RTSP/1.0 200 431 OK
Content-Length: 46
Content-Type: text/rtsp-parameters
packets_received: 10
jitter: 0.3838
This method requests to set the value of a parameter for a session
component specified by the URI.
A request SHOULD only contain a single parameter to allow the client to
determine why a particular request failed. A server MUST allow a parameter
to be set repeatedly to the same value, but it MAY disallow changing
parameter values.
Note: transport parameters for the media stream MUST only be set with the
SETUP command.
Restricting setting transport parameters to SETUP is for the
benefit of firewalls.
The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client
does not want the camera to pan unless it can also tilt to the
right angle at the same time.
A SET_PARAMETER request without parameters can be used as a way to detect
client or server liveness.
C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421
Content-type: text/rtsp-parameters
fooparam: foostuff
barparam: barstuff
S->C: RTSP/1.0 450 421 Invalid Parameter
Content-Length: 6
A redirect request informs the client that it must connect to another
server location. It contains the mandatory header Location, which indicates
that the client should issue a GET for that URL. It may contain the
parameter Range, which indicates when the redirection takes effect.
Mandatory header: Location [XXX: add this to table if accepted]
Example: This request redirects traffic for this URI to the new server at
the given play time:
S->C: REDIRECT /fizzle/foo RTSP/1.0 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
This request is used by a media server to send new media information to the
client. If a new media type is added to a session (e.g., during a live
event), the whole session description should be sent again, rather than
just the additional components.
This allows the deletion of session components.
S->C: SESSION /twister RTSP/1.0 902
Session: 1234
Content-Type: application/sdp
Session Description
This method initiates recording a range of media data according to the
session description. The timestamp reflects start and end time (UTC). If no
time range is given, use the start or end time provided in the session
description. If the session has already started, commence recording
immediately. The Conference header is mandatory.
A media server supporting recording of live events MUST support the clock
range format; the smpte format does not make sense.
In this example, the media server was previously invited to the conference
C->S: RECORD /meeting/audio.en RTSP/1.0 954
Session: 1234
9.13 Embedded Binary Data
Binary packets such as RTP data are encapsulated by an ASCII dollar sign
(24 decimal), followed by a one-byte session identifier, followed by the
length of the encapsulated binary data as a binary, two-byte integer in
network byte order. The binary data follows immediately afterwards, without
Status Codes Definitions
Where applicable, HTTP status [H10] codes are re-used. Status codes that
have the same meaning are not repeated here. See Tables 1 and 2 for a
listing of which status codes may be returned by which request.
10.1 Client Error 4xx
10.1.1 451 Parameter Not Understood
The recipient of the request does not support one or more parameters
contained in the request.
10.1.2 452 Conference Not Found
The conference indicated by a Conference header field is unknown to the
media server.
10.1.3 453 Not Enough Bandwidth
The request was refused since there was insufficient bandwidth. This may,
for example, be the result of a resource reservation failure.
10.1.4 45x Session Not Found
10.1.5 45x Method Not Valid in This State
10.1.6 45x Header Field Not Valid for Resource
The server could not act on a required request header. For example, if PLAY
contains the Range header field, but the stream does not allow seeking.
10.1.7 45x Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the
10.1.8 45x Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can only be read, but not
11 Header Field Definitions
HTTP/1.1 or other, non-standard header fields not listed here currently
have no well-defined meaning and SHOULD be ignored by the recipient.
Tables 4 and 5 summarize the header fields used by RTSP. Type ``R''
designates requests, type ``r'' responses. Fields marked with ``x'' MUST be
implemented by the recipient. If the field content does not apply to the
particular resource, the server MUST return status 45x (Header Field Not
Valid for Resource).
Accept R x
Accept-Encoding R x
Accept-Language R x o o
Authorization R o o o o o o
Bandwidth R o
Blocksize R o
Conference R o o ? ? ?
Connection Rr x x x x x
Content-Encoding Rr x
Content-Length Rr x
Content-Type Rr x
Date Rr o o o o o o
If-Modified-Since R o
Last-Modified r o
Public r o o o o o o
Range R x x
Referer R o o o o o o
Require R x o x o o o
Retry-After r o o o o o o
Session Rr x x x x
Server r o o o o o o
Speed Rr o o
Transport Rr x
Transport-Require R x o x o o o
User-Agent R o o o o o o
Via Rr o o o o o o
WWW-Authenticate r o o o o o o
Table 4: Overview of RTSP header fields for GET, SETUP, PLAY, RECORD and
Authorization o o o o
Connection x x x x
Content-Encoding x x x x
Content-Length x x x x
Content-Type x x x x
Date o o o o
Public o o o o
Referer o o o o
Retry-After o o o o
Session x x x x
Server o o o o
Speed Speed
Send speed as a ratio. The speed is relative to the normal Transport
speed for the stream, as expressed as a ratio of speed User-Agent o o o o
divided by 65536 (i.e. 2^16). For example, speed is 65536 Via o o o o
for real-time delivery, 32768 (2^15) for half-speed WWW-Authenticate o o o o
delivery, and 131072 (2^17) for double-speed delivery. A
speed of zero is invalid.
F Table 5: Overview of RTSP header fields for PAUSE, CLOSE, GET_PARAMETER and
If F is set, sends the data as fast as possible. This feature SET_PARAMETER
only works on a TCP data connection.
PLAY_RANGE 11.1 Accept
This message tells the server to start sending data via the The Accept request-header field can be used to specify certain session
previously set transport mechanism. The two fields, From and To, description content types which are acceptable for the response.
specify the range in milliseconds. If the the "To" field is zero,
it signifies the end of the stream. If the "To" field is non-
zero, it should be greater than the value specified in
the "From" field.
0 1 2 3 The ``level'' parameter for session descriptions is properly
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 defined as part of the MIME type registration, not here.
| tag (PLAY_RANGE) |
| From (in ms) |
| To (in ms) |
STREAM_SYNC See [H14.1] for syntax.
This message is sent by the server to the client in response to Example of use:
the PLAY_RANGE message. It informs the client of the first
expected sequence number, and in case of some delivery types, the
first expected timestamp.
0 1 2 3 Accept: application/sdf, application/sdp;level=2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (STREAM_SYNC) |
| Sequence Number | Reserved |
| Start Time |
Sequence Number 11.2 Accept-Encoding
Specifies where the new data starts. This number should be far
enough away from the last sequence number sent so that old
packets can be detected and rejected.
Start Time See [H14.3]
Specifies the offset (in milliseconds) relative to the origin of
the first packet that will be sent.
SET_BLOCK_SIZE 11.3 Accept-Language
This is an advisory message sent from the client to the server See [H14.4]. Note that the language specified applies to the session
setting the transport packet size. The server truncates it to the description, not the media content.
closest multiple of the minimum media-specific block size or
overrides it with the media specific size if necessary.
0 1 2 3 11.4 Allow
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Block Size |
Block Size The Allow response header field lists the methods supported by the resource
Specifies the size of the block in bytes. identified by the request-URI. The purpose of this field is to strictly
inform the recipient of valid methods associated with the resource. An
Allow header field must be present in a 405 (Method not allowed) response.
STOP Example of use:
This messages tells the server to stop sending. This is used for
`pause' operation, and the server is to keep track of the stream
position in order to `resume' play when a resume command is given.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (STOP) |
RESUME 11.5 Authorization
This message tells the server to resume sending from the position
it was stopped at with the STOP message. If no STOP message was
sent prior to RESUME, the messages is ignored.
0 1 2 3 See [H14.8]
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (RESUME) |
SEND_REPORT 11.6 Bandwidth
This message is sent by the server to the client requesting The Bandwidth request header field describes the estimated bandwidth
statistics on data reception. At a minimum, the client is available to the client, expressed as a positive integer and measured in
required to reply to the message of type 1 (PING) indicating that bits per second.
it is receiving data.
0 1 2 3 Bandwidth = "Bandwidth" ":" 1*DIGIT
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (SEND_REPORT) |
| Report Type |
Report Type: Example:
1 - PING,
2 - Text Message
3 - Reception Report
REPORT Bandwidth: 4000
Sent by the client to the server in response to the SEND_REPORT
message. or otherwise.
0 1 2 3 11.7 Blocksize
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (REPORT) |
| Report Type |
| Report Specific Fields |
Report Type: This request header field is sent from the client to the media server
1 - PING asking the server for a particular media packet size. This packet size does
2 - Text Message, not include lower-layer headers such as IP, UDP, or RTP. The server is free
3 - Reception Report to use a blocksize which is lower than the one requested. The server MAY
truncate this packet size to the closest multiple of the minimum
media-specific block size or overrides it with the media specific size if
necessary. The block size is a strictly positive decimal number and
measured in octets. The server only returns an error (416) if the value is
syntactically invalid.
PING Report (1) Report Specific Fields (NONE, just respond with 11.8 Conference
Report type 1)
Text Message (2) Report Specific Fields
0 1 2 3 This request header field establishes a logical connection between a
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 conference, established using non-RTSP means, and an RTSP stream.
| Text String (Null Terminated) |
Text String (Null terminated).
Reception Report (3) - Report specific fields
0 1 2 3 Conference = "Conference" ":" conference-id
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Packets Received | Packets Lost |
| Lagging | Buffer occupancy |
Packets Received Example:
Specifies the number of packets received since last report
Packets Lost Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
Specifies the number of packets lost since the last report.
Lagging 11.9 Content-Encoding
Specifies that the buffer level is below (1), or above the
desired level (0).
Buffer occupancy See [H14.12]
Specifies the number of milliseconds below or above the desired 11.10 Content-Length
ERROR This field contains the length of the content of the method (i.e. after the
double CRLF following the last header). Unlike HTTP, it MUST be included in
all messages that carry content beyond the header portion of the message.
It is interpreted according to [H14.14].
This message is sent by the server to the client in case of an 11.11 Content-Type
abnormal condition. It includes a numeric error code which is
defined later in this document and an optional null-terminated
error string.
Error is sent by the server to report an error to the client. See [H14.18]. Note that the content types suitable for RTSP are likely to
be restricted in practice to session descriptions and parameter-value
0 1 2 3 11.12 Date
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (ERROR) |
|F| error code |
| |
/ Error String (null-terminated) /
| |
F:(one bit) Fatal Error Flag See [H14.19].
Is used to tell the client it must terminate the session.
error codes: 11.13 If-Modified-Since
200 - Success
400 - FETCH failure; no such object exists
401 - FETCH failure; fetch refused
402 - SEND_RANGE out of bounds
403 - Incompatible protocol version
404 - SET_TRANSPORT failure; bad port specified
405 - Feed gone - live feed closed
406 - Can't do that on non-live feed
407 - Request not supported
408 - Request refused due to bandwidth mismatch
(e.g. Insufficient Client Bandwidth)
500 - Unspecified server-side problem
501 - Server running low on resources and cannot
satisfy request
UDP_RESEND See [H14.24]. If the request URL refers to a presentation rather than a
track, the server is to return the presentation if any of the track has
been modified since the time stated in the header field.
This messages is sent by the client to request retransmission 11.14 Last-modified
packets of specific sequence numbers. The service of the request
at the server end is optional.
0 1 2 3 The Last-Modified entity-header field indicates the date and time at which
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 the origin server believes the variant was last modified. See [H14.29]. If
+-------------------------------+-------------------------------+ the request URI refers to an aggregate, the field indicates the last
| tag (UDP_RESEND) | modification time across all leave nodes of that aggregate.
| Sequence Number | Number of Packets |
Sequence Number: 11.15 Location
Specifies the first packet that needs to be resent.
Number of Packets: See [H14.30].
Specifies the number of packets that need to be resent, beginning
with the above sequence number.
These messages are intended to provide a general notification This request header field specifies a range of time. The range can be
system from the server to the client or from the client to the specified in a number of units. This specification defines the smpte (see
server. The message could be sent on the control or object Section 3.4) and clock (see Section 3.5) range units. Within RTSP, byte
session. An example of using the custom message is when the ranges [H14.36.1] are not meaningful and MUST NOT be used.
server announces the availability of a new stream, or drives the
client's web browser to a particular location.
The message includes payload type and payload. Currently, defined Range = "Range" ":" 1#ranges-specifier
payload types are NewURL(1) and GotoURL(2). Implementation of
this custom messaging system is optional for both client and
server, and vendor specific payload types could be added as
EVENT_NOTIFY ranges-specifier = utc-range | smpte-range
0 1 2 3 Example:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Payload Type |
| |
/ Payload /
| |
Payload Type Range: clock=19960213T143205Z-
Specifies one of the currently defined payload types. For
example, NewURL(1) and GotoURL(2).
Payload 11.17 Require
For the previous two payload types, specifies the URL.
3.4 MEDIA SPECIFIC OPTIONS AND EXTENSION MECHANISM The Require header is used by clients to query the server about features
that it may or may not support. The server MUST respond to this header by
negatively acknowledging those features which are NOT supported in the
Unsupported header.
RTSP provides an extensible way for the client to query and set HS: Naming of features - yet another name space. I believe this
media-specific parameters and to set media-specific parameters header field to be redundant. PEP should be used instead.
for the stream. This is done via the GET_PARAM and PARAM_REPLY
messages. The GET_PARAM message includes a request ID, family
identifier and a parameter identifier. The PARAM_REPLY mes-
sage includes the corresponding request ID, and a variable length
reply data payload.
GET_PARAM For example
0 1 2 3 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Require: funky-feature
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Funky-Parameter: funkystuff
| tag (GET_PARAM) |
REQUEST_ID S->C: RTSP/1.0 200 506 Option not supported
Is a 32 bit number used to reference this request, must be non- Unsupported: funky-feature
FAMILY_ID C->S: SETUP /foo/bar/baz.rm RTSP/1.0 303
Currently, RTSP_Audio (Family 1) is defined in Appendix C.
PARAMETER_ID S->C: RTSP/1.0 200 303 OK
Specified the parameter ID within the family. These are defined
for the in Appendix C.
PARAM_REPLY This is to make sure that the client-server interaction will proceed
optimally when all options are understood by both sides, and only slow down
if options aren't understood (as in the case above). For a well-matched
client-server pair, the interaction proceeds quickly, saving a round-trip
often required by negotiation mechanisms. In addition, it also removes
state ambiguity when the client requires features that the server doesn't
0 1 2 3 11.18 Unsupported
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag(PARAM_REPLY) |
/ DATA /
| |
For a list of currently defined family and parameter identifiers, See Section 11.17 for a usage example.
see Appendix C. An example of use of these messages is available
in the next section. Data types are String(0), Integer(1), and
Opaque data(2).
This message can be sent by the server to the client, even if the HS: same caveat as for Require applies.
client has not sent a request. The client must be prepared to
handle this. In this case, the REQUEST_ID is 0x0.
REQUEST_ID 11.19 Nack-Transport-Require
Is a 32 bit number used to reference this request, must be non-
FAMILY_ID Negative acknowledgement of features not supported by the server. If there
Currently, RTSP_Audio (Family 1) is defined in Appendix C. is a proxy on the path between the client and the server, the proxy MUST
insert a message reply with an error message 506 (Feature not supported).
PARAMETER_ID HS: Same caveat as for Require applies.
Specified the parameter ID within the family. These are defined 11.20 Transport-Require
for the in Appendix C.
PARAM_REFUSE The Transport-Require header is used to indicate proxy-sensitive features
If the server does not support the requested parameter or family, that MUST be stripped by the proxy to the server if not supported.
it sends a ParamRefuse, whose format is as below: Furthermore, any Transport-Require header features that are not supported
by the proxy MUST be negatively acknowledged by the proxy to the client if
not supported.
0 1 2 3 See Section 11.17 for more details on the mechanics of this message and a
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 usage example.
REQUEST_ID HS: Same caveat as for Require applies.
Is a 32 bit number used to reference this request, must be non-
FAMILY_ID 11.21 Retry-After
Currently, RTSP_Audio (FAMILY_ID1) is defined in Appendix C.
PARAMETER_ID See [H14.38].
Specified the parameter ID within the family. Currently, the
RTSP_Audio is defined in Appendix C.
ERROR_CODE: As defined earlier. 11.22 Speed
SET_PARAM This request header fields parameter requests the server to deliver data to
the client at a particular speed, contingent on the server's ability and
desire to serve the media stream at the given speed. Implementation by the
server is OPTIONAL. The default is the bit rate of the stream.
Using the same principle as GET_PARAM, a media-specific option The parameter value is expressed as a decimal ratio, e.g., a value of 2.0
for the stream can be set using the SET_PARAM message. Examples indicates that data is to be delivered twice as fast as normal. A speed of
of an option include encryption, custom encoding or quality zero is invalid. A negative value indicates that the stream is to be played
levels. The server replies with a SET_PARAM_REPLY or back in reverse direction.
0 1 2 3 speed = "Speed" ":" ["-"]1*DIGIT [ "." *DIGIT ]
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| tag (SET_PARAM) |
| |
/ DATA /
| |
Is a 32 bit number used to reference this request, must be non-
FAMILY_ID Speed: 2.5
Currently, RTSP_Audio (Family 1) is defined in Appendix C.
PARAMETER_ID 11.23 Server
Specified the parameter ID within the family. These are defined
for the in Appendix C.
DATA See [H14.39]
Specifies the payload specific to the family and parameters.
Example of use of GetParam to request and play an audio file: This request and response header field identifies a session, started by the
media server in a SETUP or PLAY response and concluded by CLOSE on the
session URL (presentation). The session identifier is chosen by the media
server and has the same syntax as a conference identifier. Once a client
receives a Session identifier, it MUST return it for any request related to
that session.
CLIENT SERVER HS: This may be redundant with the standards-track HTTP state
maintenance mechanism [1]. The equivalent way of doing this would
be for the server to send Set-Cookie: Session="123"; Version=1;
Path = "/twister" and for the client to return later Cookie:
Session = "123"; $Version=1; $Path = "/twister". In the response
to the CLOSE message, the server would simply send Set-Cookie:
Session="123"; Version=1; Max-Age=0 to get rid of the cookie on
the client side. Cookies also have a time-out, so that a server
may limit the lifetime of a session at will. Unlike a web
browser, a client would not store these states on disk.
CONTROL_SCP: HELLO---------------------------> 11.25 Transport
<---------------------------CONTROL_SCP:HELLO This request header indicates which transport protocol is to be used and
configures its parameters such as multicast, compression, multicast
time-to-live and destination port for a single stream. It sets those values
not already determined by a session description. In some cases, the session
description contains all necessary information. In those cases, a Transport
header field (and the SETUP request containing it) are not needed.
<--------------------------- CONTROL_SCP:ID 'Interleaved' implies mixing the media stream with the control stream, in
whatever protocol is being used by the control stream. Currently, the
next-layer protocols RTP is defined. Parameters may be added to each
protocol, separated by a semicolon. For RTP, the boolean parameter
compressed is defined, indicating compressed RTP according to RFC XXXX. For
multicast UDP, the integer parameter ttl defines the time-to-live value to
be used. For UDP and TCP, the parameter port defines the port data is to be
sent to.
(OPTIONAL) CONTROL_SCP:ID_RESP---------------------> The SSRC parameter indicates the RTP SSRC value that should be (request)i
or will be (response) used by the media server. This parameter is only
valid for unicast transmission. It identifies the synchronization source to
be associated with the media stream.
STREAM_SCP_0: FETCH-----------------------------> The Transport header MAY also be used to change certain transport
parameters. A server MAY refuse to change parameters of an existing stream.
STREAM_SCP_0: GETPARAM--------------------------> The server MAY return a Transport response header in the response to
indicate the values actually chosen.
STREAM_SCP_0: GETPARAM--------------------------> A Transport request header field may contain a list of transport options
acceptable to the client. In that case, the server MUST return a single
option which was actually chosen. The Transport header field makes sense
only for an individual media stream, not a session.
<------------------------- STREAM_SCP_0:STREAM_HEADER Transport = "Transport" ":"
1#transport-protocol/upper-layer *parameter
transport-protocol = "UDP" | "TCP"
upper-layer = "RTP"
parameters = ";" "multicast" |
";" "compressed" |
";" "interleaved" |
";" "ttl" "=" ttl |
";" "port" "=" port |
";" "ssrc" "=" ssrc
ttl = 1*3(DIGIT)
port = 1*5(DIGIT)
ssrc = 8*8(HEX)
<------------------------- STREAM_SCP_0:PARAM_REPLY Example:
<------------------------- STREAM_SCP_0:PARAM_REPLY Transport: udp/rtp;compressed;ttl=127;port=3456
STREAM_SCP_0: SETPARAM(eg.encryption) ----------------> 11.26 User-Agent
<-------------------------- STREAM_SCP_0:PARAM_REPLY See [H14.42]
STREAM_SCP_0: SET_TRANSPORT(RTP)----------------> 11.27 Via
STREAM_SCP_0: PLAY_RANGE(a,b)-------------------> See [H14.44].
<--------------------------- STREAM_SCP_0:STREAM_SYNC 11.28 WWW-Authenticate
<--------------------------- Data on UDP channel See [H14.46].
Example of use of custom message: 12 Caching
CLIENT SERVER In HTTP, response-request pairs are cached. RTSP differs significantly in
that respect. Typically, responses are not cachable (except maybe for the
GET response), rather it is desirable for the media data (that is typically
delivered outside of RTSP) to be cached. Since the responses for anything
but GET and GET_PARAMETER do not return any data, caching is not an issue
for these requests.
CONTROL_SCP: HELLO----------------------------> HS: A proxy cache for RTSP would look not much different from an HTTP
cache. To the client, the proxy cache would appear like a regular media
server, to the media server like a client. Just like an HTTP cache has to
store the content type, content language, etc. for the objects it caches, a
media cache has to store the session description. Typically, a cache would
eliminate all transport-references (that is, multicast information) from
the session description, since these are independent of the data delivery
from the cache to the client. Information on the encodings remains the
same. If the cache is able to translate the cached media data, it would
create a new session description with all the encoding possibilities it can
<----------------------------CONTROL_SCP:HELLO 13 Examples
STREAM_SCP_0: FETCH -------------------> To emphasize that RTSP is independent of the session description format,
the following examples use a fictional session description language which
is chosen to be sufficiently self-explanatory.
<-------------------------- STREAM_SCP_0:STREAM_HEADER 13.1 Media on Demand (Unicast)
STREAM_OBJECT_SCP_0: SET_TRANSPORT(RTP)--------> Client C requests a movie from media servers A ( audio.content.com) and V
(video.content.com). The media description is stored on a web server W.
This, however, is transparent to the client. The client is only interested
in the last part of the movie. The server requires authentication for this
movie. The audio track can be dynamically switched between between two sets
of encodings. The URL with scheme rtpsu indicates the media servers want to
use UDP for exchanging RTSP messages.
STREAM_OBJECT_SCP_0: PLAY_RANGE(a,b)-----------------> C->W: GET /twister HTTP/1.1
Host: www.content.com
Accept: application/sdf; application/sdp
<--------------------------- STREAM_SCP_0:STREAMSYNC W->C: 200 OK
Content-Type: application/sdf
(media (t audio) (oneof
((e PCMU/8000/1 89 DVI4/8000/1 90) (id lofi))
((e DVI4/16000/2 90 DVI4/16000/2 91) (id hifi))
(language en)
(id rtspu://audio.content.com/twister/audio.en)
(media (t video) (e JPEG)
(id rtspu://video.content.com/twister/video)
<--------------------------- Data on UDP channel C->A: SETUP rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 1
Transport: rtp/udp;compression;port=3056
<--------------------------- CONTROL_SCP: EVENT_NOTIFY(NewURL) A->C: RTSP/1.0 200 1 OK
Session: 1234
STREAM_OBJECT_SCP_1: FETCH---------------------> C->V: SETUP rtsp://video.content.com/twister/video RTSP/1.0 1
Transport: rtp/udp;compression;port=3058
<------------------------- STREAM_SCP_1:STREAM_HEADER V->C: RTSP/1.0 200 1 OK
Session: 1235
STREAM_SCP_1: SET_TRANSPORT(RTP)----------------> C->V: PLAY rtsp://video.content.com/twister/video RTSP/1.0 2
Session: 1235
Range: smpte 0:10:00-
STREAM_SCP_1: SEEK(a,b)-------------------------> V->C: RTSP/1.0 200 2 OK
<--------------------------------- STREAM_SCP_1:STREAM_SYNC C->A: PLAY rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 2
Session: 1234
Range: smpte 0:10:00-
<------------------------------- Data on UDP channel A->C: 200 2 OK
5.0 REFERENCES: C->A: CLOSE rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 3
Session: 1234
[1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: A->C: 200 3 OK
A Transport Protocol for real-time applications." RFC 1889
[2] Simon Spero, Session Control Protocol(SCP). C->V: CLOSE rtsp://video.content.com/twister/video RTSP/1.0 3
Session: 1235
[3] J. Postel, J. Reynolds, "Telnet Protocol Spefication.", RFC 854 V->C: 200 3 OK
6.0 APPENDIXES Even though the audio and video track are on two different servers, 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.
6.1 APPENDIX A - Data packets 13.2 Live Media Event Using Multicast
[Note: see "Compartmentalize the Protocol" in the "RTSP The media server M chooses the multicast address and port. Here, we assume
Open Issues" document for discussion of the possible split that the web server only contains a pointer to the full description, while
of this appendix into a separate document the media server M maintains the full description. During the session, a
(http://www.prognet.com/prognet/rt/openissues.html)] new subtitling stream is added.
The following are the types of data packet formats. C->W: GET /concert HTTP/1.1
Host: www.content.com
RTP: The format of the UDP packet is a standard RTP packet, as W->C: HTTP/1.1 200 OK
per RFC 1889. This is a description of how the RTP packet is used Content-Type: application/sdf
by RTSP. Complete generalized descriptions of these fields can be
found in RFC 1889.
0 1 2 3 (session
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 (id rtsp://live.content.com/concert)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ )
|V=2|P|X| CC |M| PT | sequence number |
| timestamp |
| synchronization source (SSRC) identifier |
| contributing source (CSRC) identifiers |
| .... |
The first twelve octets are present in every RTP packet, while C->M: GET rtsp://live.content.com/concert RTSP/1.0 1
the list of CSRC identifiers usually will not be present (though
may be used when broadcasting an RTP conferencing session, for
instance). The fields have the following meaning:
Version (V): 2 bits M->C: RTSP/1.0 200 1 OK
This field identifies the version of RTP. The version used by Content-Type: application/sdf
this specification is two (2).
Padding (P): 1 bit (session (all
If the padding bit is set, the packet contains one or more (media (t audio) (id music) (a IP4 (p 3456))
additional padding octets at the end which are not part of the ))
payload. The last octet of the padding contains a count of how
many padding octets should be ignored.
Extension (X): 1 bit C->M: PLAY rtsp://live.content.com/concert/music RTSP/1.0 2
Not used. Set to zero for RTP compatibility. CSRC count (CC): 4 Range: smpte 1:12:0
bits. The CSRC count contains the number of CSRC identifiers that
follow the fixed header.
Marker (M): 1 bit M->C: RTSP/1.0 405 2 No positioning possible
In RTSP, this designates the block boundary. This is a point at
which a client can start decoding the stream.
Payload type (PT): 7 bits M->C: SESSION concert RTSP/1.0
Each stream uses a payload type allocated dynamically between 96 Content-Type: application/sdf
and 127, to remain consistent with the dynamic mappings in the
audio-video profile (RFC 1890).
Sequence number: 16 bits (session (all
The sequence number increments by one for each RTP data packet (media (t audio) (id music))
sent, and may be used by the receiver to detect packet loss and (media (t text) (id lyrics))
to restore packet sequence. The initial value of the sequence ))
number is random (unpredictable) to make known plaintext attacks
on encryption more difficult, even if the source itself does
not encrypt, because the packets may flow through a translator
that does.
Timestamp: 32 bits C->M: PLAY rtsp://live.content.com/concert/lyrics RTSP/1.0
The timestamp is a tick mark which reflects the sampling instant
of the first octet in the RTP data packet. The clock frequency is
dependent on the format of data carried as payload.
SSRC: 32 bits Since the session description already contains the necessary address
The SSRC field identifies the synchronization source associated information, the client does not set the transport address. The attempt to
with the data. This identifier is chosen with the intent that no position the stream fails since this is a live event.
two synchronization sources within the same RTSP session will
have the same SSRC.
CSRC list: 0 to 15 items, 32 bits each 13.3 Playing media into an existing session
The CSRC list identifies the contributing sources for the payload
contained in this packet. The number of identifiers is given by
the CC field. If there are more than 15 contributing sources,
only 15 may be identified.
Compressed RTP A conference participant C wants to have the media server M play back a
[Note: There has been some questions as to the demo tape into an existing conference. When retrieving the session
appropriateness of this name, since it is really an description, C indicates to the media server that the network addresses and
application-level compression that relies on RTSP to carry encryption keys are already given by the conference, so they should not be
some of the "compressed" information out of band. We will chosen by the server. The example omits the simple ACK responses.
probably change this name to reflect its distance from RTP.]
0 1 2 3 C->M: GET /demo HTTP/1.1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Host: www.content.com
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Accept: application/sdf, application/sdp
|v|M|t|s| SSRC | sequence number |timestamp (opt)...
... |
version (v): 1 bit M->C: HTTP/1.1 200 1 OK
If this is 1, the rest of this packet is standard RTP, and we can Content-type: application/sdf
treat it as such. If it is 0, the rest of the packet is defined
as follows.
marker (M): 1 bit (session
In RTSP, this designates the block boundary. This is a point at (id 548)
which a client can start decoding the stream. (media (t audio) (id sound)
timestamp lower bits compression bit (t): 1 bit C->M: SETUP rtsp://server.content.com/demo/548/sound RTSP/1.0 2
This number specifies the existence of the least-significant two Conference: 218kadjk
bytes of the timestamps. If this bit is not set, the value of
these bytes are calculated based some media-specific method
(probably using the sequence number). If this bit is set, the
value of these bytes are given in this packet.
The upper bits are determined based on the probable value given 13.4 Recording
the sequence number. This compression scheme does not work for
packets that are spaced out at intervals greater than roughly 64
sequence number inclusion bit(s) Conference participant C asks the media server M to record a session. If
This bit is for compatibility with reliable, sequenced delivery the session description contains any alternatives, the server records them
mechanisms, such as SCP. This should always be set to 1. all.
SSRC: 4 bits or 36 bits C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 89
The SSRC field identifies the synchronization source associated Content-Type: application/sdp
with the data. This identifier is chosen with the intent that no
two synchronization sources within the same RTSP session will
have the same SSRC.
This is 4 bits unless set to 15 (1111), in which case it expands v=0
to 36 bits, and the lower 32 bits are the actual SSRC. s=Mbone Audio
i=Discussion of Mbone Engineering Issues
sequence number: 16 bits M->C: 415 89 Unsupported Media Type
The sequence number increments by one for each RTP data packet Accept: application/sdf
sent, and may be used by the receiver to detect packet loss and
to restore packet sequence. The initial value of the sequence
number is random (unpredictable) to make known-plaintext attacks
on encryption more difficult, even if the source itself does
not encrypt, because the packets may flow through a translator
that does.
6.2 APPENDIX B - Session Control Protocol (SCP) C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 90
Content-Type: application/sdf
[Note: see "Compartmentalize the Protocol" in the "RTSP M->C: 200 90 OK
Open Issues" document for discussion of the possible split
of this appendix into a separate document
[Note: other methods of multiplexing are currently being C->M: RECORD rtsp://server.content.com/meeting RTSP/1.0 91
discussed. Simon Spero has a new draft of SCP at Range: clock 19961110T1925-19961110T2015
http://sunsite.unc.edu/ses/scp.html. SMUX, from Jim
Gettys and the W3C at http://www.w3.org is another candidate.]
This document was originally written by Simon Spero for the HTTP- 14 Syntax
NG project. It has been slightly editied and clarified.
Several heavily used Internet applications such as FTP, GOPHER, The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used
and HTTP use a protocol model in which every transaction in RFC 2068 (HTTP/1.1).
requires a separate TCP connection. Since clients normally issue
multiple requests to the same server, this model is quite
inefficient, as it incurs all the connection start up costs for
every single request.
SCP is a simple protocol which lets a server and client have 14.1 Base Syntax
multiple conversations over a single TCP connection.
Definitions OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
A session is a virtual stream of data carried within the single message-header = field-name ":" [ field-value ] CRLF
TCP connection. It is independent of any other session within the field-name = token
same connection. field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and consisting
of either *TEXT or combinations of token, tspecials,
and quoted-string>
A session identifier is a unique number which is used to specify 14.2 Internet Media Type Syntax
which session a particular block of data is associated with.
Session flag names are borrowed from TCP. The name SYN means media-type = type "/" subtype *( ";" parameter )
"open" in SCP. The name FIN means "finish" or "close" in SCP. The type = token
name RST means "reset" in SCP. PUSH indicates the end of a subtype = token
segment. parameter = attribute "=" value
attribute = token
value = token | quoted-string
Services 14.3 Universal Resource Identifier Syntax
SCP's main service is dialogue control. This service allows uri = ( absoluteURI | relativeURI ) [ "#" fragment ]
either end of the connection to establish multiple virtual absoluteURI = scheme ":" *( uchar | reserved )
sessions over a single transport connection. SCP also allows a relativeURI = net-path | abs-path | rel-path
sender to indicate message boundaries, and allows a receiver to net-path = "//" net-loc [ abs-path ]
reject an incoming session. abs-path = "/" rel-path
rel-path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT, reserverd, extra,
safe, and unsafe>
Design goals 14.4 RTSP-specific syntax
SCP allows data to be sent with the session establishment; the setup-response = response-line
recepient does not confirm successful connection establishment, date-type-header
but may reject unsuccessful attempts. This simplifies the design *( nack-require-header
of the protocol, and removes the latency required for a con- | nack-require-transport-header )
firmed operation. CRLF
Low overhead redirect-response = response-line
SCP has a fixed overhead of 8 bytes per segment. This overhead is session-response = response-line
only incurred once per segment, instead of once per packet. date-type-header
Simple design play-response = response-line
The session protocol should be simple enough to implement for a pause-response = response-line
single application. date-type-header
Protocol Description message-body = *OCTET
Header Format: accept-header = "Accept" ":" 1#media-type
allow-header = "Allow" ":" 1#method
blocksize-header = "Blocksize" ":" 1*DIGIT
content-length-header = "Content-Length" ":" 1*DIGIT
content-type-header = "Content-Type" ":" media-type
date-type-header = "Date" ":" rfc1123-date
location-header = "Location" ":" request-uri
require-header = "Require" ":" #parameters
transport-require-header = "Transport-Require" ":" #parameters
nack-require-header = "Nack-Require" ":" #parameters
nack-transport-require-header = "Nack-Transport-Require" ":" #parameters
0 1 2 3 auth-scheme = token
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ip-address = <IP address in dotted-decimal form per RFC 1123>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ port-number = 1*DIGIT
|0|0|0|0| flags | session ID | blocksize-value = 1*DIGIT
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ credentials = auth-scheme ":" #parameter
| session length | rfc1123-date = wkday "," SP date SP time SP "GMT"
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ date = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 12 Dec 1998)
| | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59
/ data / wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
| | month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun"
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
flags: 15 Experimental
0x1 : SYN
0x2 : FIN
0x4 : RST
0x8 : PUSH
Protocol Operation This section gathers parts of the protocol which are less well understood
and require extensive further discussion.
Session ID allocation 15.1 Header Field Definitions
Each session is allocated a session identifier. Session
Identifiers below 1024 are reserved. Session IDs allocated by
clients are even; those allocated byservers, odd.
Session establishment The following additional HTTP headers may be useful for RTSP:
A new session is established by setting the SYN bit in the first
message sent on that channel.
Graceful release * Accept-Language
* Cache-Control
* From
* Max-Forwards
* Proxy-Authenticate
* Proxy-Authorization
* Public
* Referer
A session is ended by sending a message with the FIN bit set. 15.1.1 Address
Each end of a connection may be closed independently.
Disgraceful release Designates address to send multimedia data to.
A session may be terminated by sending a message with the RST bit
set. All pending data for that session should be discarded
Message boundaries It appears that in almost all cases, the destination address is
A message boundary is marked by sending a message with the PUSH the same one where the RTSP command originates from. If TCP is
bit set. The boundary is set at the final octet in this message, used for control, this also eliminates the possibilities of
including that octet. pointing a data stream at an unsuspecting third party.
Compressed Header SCP 16 Security Considerations
+-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+ The protocol offers the opportunity for a remote-control denial-of-service
|1|P| IDL | LNL | session ID | segment length | data | attack. The attacker, using a forged source IP address, can ask for a
+-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+ stream to be played back to that forged IP address.
P: 1 bit Since there is no relation between a transport layer connection and an RTSP
Push bit. This denotes a message boundry, which is set at the session, it is possible for a malicious client to issue requests with
final octet in this message. random session identifiers which would affect unsuspecting clients. This
does not require spoofing of network packet addresses. The server SHOULD
use a large random session identifier to make this attack more difficult.
IDL: 3 bit Both problems can be be prevented by appropriate authentication.
Length of the session ID field (as described below).
LNL: 3 bits In addition, the security considerations outlined in [H15] apply.
Length of the session length field (as described below).
session ID: Variable number of bits, depending on IDL field A State Machines
Identifier for this session. The session ID value is relative to
1024, which is the minimum non-reserved value.
segment length: Variable number of bits, depending on LNL field. The RTSP client and server state machines describe the behavior of the
Length of the payload in bytes. protocol from session initialization through session termination.
IDL and LNL values: 3 bits [TBD: should we allow for the trivial case of a server that only implements
the PLAY message, with no control.]
value Length of Session ID or Segment Length field State is defined on a per object basis. An object is uniquely identified by
0x0 use previous value the stream URL AND the session identifier. (A server may choose to generate
0x1 4 bits dynamic session descriptions where the URL is unique for a particular
0x2 8 bits session and thus may not need an explicit session identifier in the request
0x3 12 bits header.) Any request/reply using URLs denoting a session comprised of
0x4 16 bits multiple streams will have an effect on the individual states of all the
0x5 24 bits substreams. For example:
0x6 32 bits
0x7 64 bits
IDL and LNL values should be chosen so that byte alignment of the Assuming the stream /coolmovie contains two substreams /coolmovie/audio and
packet is guaranteed. /coolmovie/video, then the following command:
6.3 APPENDIX C - RTSP -Audio (Family ID =1 ) PLAY /coolmovie RTSP/1.0 559
Format descriptor (Parameter=1) Session: 12345
[Note: see "Compartmentalize the Protocol" in the "RTSP
Open Issues" document for discussion of the possible split
of this appendix into a separate document
[Note: see "Change Appendix C (families of stream types)" will have an effect on the states of coolmovie/audio and coolmovie/video.
in the "RTSP Open Issues" document for discussion of a
series of proposed changes to this Appendix, such as
changing CODEC IDs to UUIDs, modifying the audio family,
and adding a video family
0 1 2 3 This example does not imply a standard way to represent
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 substreams in URLs or a relation to the filesystem. See Section
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.
| NumChannels | Bits/Sample |
| Samples Per Second |
| Average Frame Size | Maximum Frame Size |
| Samples Per Frame |
|P| Frames Per Packet | Extra Bytes |
| Number Of Frames |
| CODEC-specific Data |
: : :
: : :
The above structure describes a generic compressed audio stream A.1 Client State Machine
for the RTSP Audio Family.
CODEC ID: The CODEC ID uniquely identifies the codec which was A.1.1 Client States
used to generate this audio data. CODEC ID's in the range 0x00
through 0xffff are reserved for ACM (Audio Compression Manager
native to Microsoft Windows Operating systems) compatible/
interoperable codecs.
NumChannels: Use 1 for mono, 2 for stereo These are defined as follows:
Bits/Sample: Number of bits per sample as specified by the codec. NULL:
Codecs which do not need or do not have a well defined value for No state
this parameter may set this to zero. INIT:
GET or SETUP has been sent, waiting for reply.
SETUP reply received OR after playing, PAUSE reply received.
PLAY reply received
Samples Per Second: Playback rate for each channel in A.1.2 Notes
samples per second (hertz).
Average Frame Size: Frame is the smallest unit of encoded audio In general, the client transitions state on receipt of specific replies.
data that can be streamed from the server. Average Frame Size After a period of inactivity, state transitions back to NULL. "Inactivity"
represents the typical size (in bytes) of a frame. This family is defined as one of the following:
does not support non byte-aligned frames.
Maximum Frame Size: Size in bytes of the largest frame. For * For state PLAYING, no data being received and/or lack of wellness
constant bit rate codecs, this value is the same as the Average information from the server.
Frame Size. * The client stays in any other state continuously for more than a
specific interval. The choice of this interval is left to the
Samples Per Frame: Number of samples of audio data encoded in If no explicit SETUP is required for the object (for example, it is
each frame. This family does not support variable duration frames. available via a multicast group) , state begins at READY. In this case,
there are only two states, i.e READY and PLAYING.
P: If P is not set, then the audio data is planar and the client A client MUST disregard messages with a sequence number less than the last
has the option to request data packets of size which are one . If no message has been received, the first received message's
multiples of the average frame size. If P is set, the stream is sequence number will be the starting point.
packetized (usually for variable bit rate data and live feeds),
then the size of the data packet is defined by frame size and
frames per packet (described below).
Frames Per Packet: For packetized formats, this represents the A.1.3 State Table
number of frames in every data packet. For planar formats, this
is a hint to the client regarding the server preference.
Extra Bytes: This specifies the number of bytes of codec specific In the NEXT STATE column, + indicates that the message was successful,
data that follow the fixed header. -indicates that it was unsuccessful.
Number of Frames: Total number of frames in the audio stream. For STATE MESSAGES NEXT STATE(+) NEXT STATE(-)
non-seekable streams (e.g. live feeds), this should be set to
6.4 APPENDIX D - RTSP - Audio (Family ID =1 ) : Annotations INIT GET REPLY INIT NULL
[Note: see "Compartmentalize the Protocol" in the "RTSP READY PLAY REPLY PLAYING READY
Open Issues" document for discussion of the possible split SETUP REPLY READY INIT
of this appendix into a separate document BYE NULL NULL
(http://www.prognet.com/prognet/rt/openissues.html)] OTHER READY READY
This payload data enables the server to communicate additional PLAYING PAUSE REPLY READY PLAYING
information about the stream to the client. Examples of such PLAY REPLY PLAYING CLOSED
information include the authorof the clip, the clip name, BYE NULL NULL
copyright information, creation date etc. The payload data is CLOSE REPLY NULL PLAYING
organized as a list of information chunks. Each such chunk has an OTHER PLAYING PLAYING
identifier, length of the chunk and the actual data itself.
0 1 2 3 This assumes that a PLAY during state PLAYING is an implicit PAUSE, PLAY.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Number of chunks |
| Chunk Identifier (Chunk 0) |
| Number of Bytes (Chunk 0) |
| Chunk Data (Chunk 0) |
: : :
: : :
| Chunk Identifier (Chunk n-1) |
| Number of Bytes (Chunk n-1) |
| Chunk Data (Chunk n-1) |
: : :
: : :
Chunk Identifier HS: BYE should be replaced by CLOSE.
This is a four character code identifying the chunk. For example,
`I''C''O''P' is used for copyright information which is
stored as a null terminated string. `I''N''A''M' is used for the
name of the audio clip. `I''U''R''L' serves to pass the URL for
the CODEC installer. The client should use this URL if it
encounters a clip compressed with an unknown CODEC.
Any chunk with an unrecognized four character code should be A.2 Server State Machine
ignored by the client.
Number of Bytes A.2.1 Server States
Represents the length of the chunk data. The chunk data should be INIT:
16 bit aligned. The initial state, no valid SETUP receieved.
Last SETUP received was successful, reply sent or after playing, last
PAUSE received was successful, reply sent.
Last PLAY received was successful, reply sent. Data actually being
Contacts: In general, server state transitions occur on receiving requests. On
receiving a BYE, state transitions back to INIT. After inactivity for a
period, state also transitions back to INIT. "Inactivity" is defined as:
At Netscape: Anup Rao <anup@netscape.com> * For states other than PLAYING, no messages for that object for a
At Progressive Networks: Rob Lanphier <robla@prognet.com> specific interval. The choice of interval is left to the
* In state PLAYING, lack of wellness information from the client.(This
information could be either RTCP or be requested by the server by
other means)
[Note: this list will need to be updated for the final The REDIRECT message, when sent, is effective immediately. If a similar
release of the document] change of location occurs at a certain time in the future, this is assumed
to be indicated by the session description. For purposes of this table, a
REDIRECT is considered an unsuccessful GET.
The following authors contributed to this document: A server MUST disregard messages with a sequence number less than the last
one. If no message has been received, the first received message's sequence
number will be the starting point.
Martin Dunsmuir <martind@prognet.com> SETUP is valid in states INIT and READY only. An error message should be
General Manager Server Products, returned in other cases. If no explicit SETUP is required for the object,
Progressive Networks state starts at READY, ie. there are only two states READY and PLAYING.
1111 Third Avenue, Suite 2900
Tel. 206 674 2700 (main #)
John K. Ho <johnkho@netscape.com> A.2.2 State Table
Project Manager
Netscape Communications Corp.
685 E. Middlefield Rd.
Mountain View, CA, 94043
Tel. 415 254 1900 (main #)
Rob Lanphier <robla@prognet.com> In the NEXT STATE column, + indicates that the message was successful,
Program Manager -indicates that it was unsuccessful.
Progressive Networks
Eduardo F. Llach <eduardo@netscape.com> STATE MESSAGES NEXT STATE(+) NEXT STATE(-)
Manager, Media Server Team,
Netscape Communications Corp.
Rob McCool <robm@netscape.com> INIT GET INIT INIT
Technical Team Leader, Media Server SETUP READY INIT
Netscape Communications Corp. BYE INIT INIT
Igor Plotnikov <igor@netscape.com> READY PLAY PLAYING READY
Technical Team Leader, Media Server SETUP READY INIT
Netscape Communications Corp. CLOSE INIT -
Member, Technical Staff PAUSE READY PLAYING
Netscape Communications Corp. CLOSE INIT PLAYING
Pinaki Shah B Open Issues
Member, Technical Staff
Netscape Communications Corp.
Alexander Sokolsky * Define text/rtsp-parameter MIME type.
Member, Technical Staff * Lots of inconsistencies need to be fixed: naming of methods in state
definition, syntax.
* Allow changing of transport for a stream that's playing? May not be a
great idea since the same can be accomplished by tear down and
* How does the server get back to the client unless a persistent
connection is used? Probably cannot, in general.
* Cache and proxy behavior?
* Session: or Set-Cookie: ?
* Behavior of all methods in state diagram.
* Error message for method
* When do relative RTSP URLs make sense?
* Nack-require, etc. are dubious. This is getting awfully close to the
HTTP extension mechanisms [16] in complexity, but is different.
* Suggestion (HS): shelve REDIRECT method for now, until necessity
becomes clear.
* Use HTTP absolute path + Host field or do the right thing and carry
full URL, including host in request?
C Author Addresses
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
electronic mail: schulzrinne@cs.columbia.edu
Anup Rao
Netscape Communications Corp. Netscape Communications Corp.
electronic mail: anup@netscape.com
Dale Stammen Robert Lanphier
Lead Saxophone
Progressive Networks Progressive Networks
1111 Third Avenue Suite 2900
Seattle, WA 98101
electronic mail: robla@prognet.com
John Francis Stracke D Acknowledgements
Senior LiveMedia Architect
Netscape Communications Corp. This draft is based on the functionality of the RTSP draft. It also borrows
format and descriptions from HTTP/1.1.
This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already mentioned, the
following individuals have contributed to this specification:
Rahul Agarwal Eduardo F. Llach
Bruce Butterfield Rob McCool
Martin Dunsmuir Sujal Patel
Mark Handley Igor Plotnikov
Peter Haight Pinaki Shah
Brad Hefta-Gaub Jeff Smith
John K. Ho Alexander Sokolsky
Ruth Lang Dale Stammen
Stephanie Leif John Francis Stracke
1 D. Kristol and L. Montulli, ``HTTP state management mechanism,'' RFC
2109, Internet Engineering Task Force, Feb. 1997.
2 F. Yergeau, G. Nicol, G. Adams, and M. Duerst, ``Internationalization
of the hypertext markup language,'' RFC 2070, Internet Engineering
Task Force, Jan. 1997.
3 S. Bradner, ``Key words for use in RFCs to indicate requirement
levels,'' Internet Draft, Internet Engineering Task Force, Jan. 1997.
Work in progress.
4 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee,
``Hypertext transfer protocol - HTTP/1.1,'' RFC 2068, Internet
Engineering Task Force, Jan. 1997.
5 A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' Internet
Draft, Internet Engineering Task Force, Dec. 1996. Work in progress.
6 J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and E. L.
Stewart, ``An extension to HTTP: digest access authentication,'' RFC
2069, Internet Engineering Task Force, Jan. 1997.
7 J. Postel, ``User datagram protocol,'' STD 6, RFC 768, Internet
Engineering Task Force, Aug. 1980.
8 R. Hinden and C. Partridge, ``Version 2 of the reliable data protocol
(RDP),'' RFC 1151, Internet Engineering Task Force, Apr. 1990.
9 J. Postel, ``Transmission control protocol,'' STD 7, RFC 793,
Internet Engineering Task Force, Sept. 1981.
10 M. Handley, H. Schulzrinne, and E. Schooler, ``SIP: Session
initiation protocol,'' Internet Draft, Internet Engineering Task
Force, Dec. 1996. Work in progress.
11 P. McMahon, ``GSS-API authentication method for SOCKS version 5,''
RFC 1961, Internet Engineering Task Force, June 1996.
12 D. Crocker, ``Augmented BNF for syntax specifications: ABNF,''
Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in
13 R. Elz, ``A compact representation of IPv6 addresses,'' RFC 1924,
Internet Engineering Task Force, Apr. 1996.
14 T. Berners-Lee, ``Universal resource identifiers in WWW: a unifying
syntax for the expression of names and addresses of objects on the
network as used in the world-wide web,'' RFC 1630, Internet
Engineering Task Force, June 1994.
15 International Telecommunication Union, ``Visual telephone systems and
equipment for local area networks which provide a non-guaranteed
quality of service,'' Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996.
16 D. Connolly, ``PEP: an extension mechanism for http,'' Internet
Draft, Internet Engineering Task Force, Jan. 1997. Work in progress.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/