draft-ietf-mmusic-rtsp-01.txt   draft-ietf-mmusic-rtsp-02.txt 
INTERNET-DRAFT Henning Schulzrinne, Columbia University Internet Engineering Task Force MMUSIC WG
Anup Rao, Netscape Communications Internet Draft H. Schulzrinne, A. Rao, R. Lanphier
Rob Lanphier, Progressive Networks ietf-mmusic-rtsp-02.txt Columbia U./Netscape/Progressive Networks
SUBMITTED: 24th February 1997 Expires: 24th August 1997 March 27, 1997
Expires: September 26, 1997
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-01.txt
STATUS OF THIS MEMO STATUS OF THIS MEMO
This is an Internet-Draft. Internet-Drafts are working documents of the This document is an Internet-Draft. Internet-Drafts are working
Internet Engineering Task Force (IETF), its areas, and its working groups. documents of the Internet Engineering Task Force (IETF), its areas,
Note that other groups may also distribute working documents as and its working groups. Note that other groups may also distribute
Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of working documents as Internet-Drafts.
six months and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), mannari.oz.au
(Pacific Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US West
Coast).
Prior to the expiration of this draft, the list of open issues may be found Internet-Drafts are draft documents valid for a maximum of six months
at the following URL: and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''.
http://www.prognet.com/prognet/rt/openissues.html To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract: Distribution of this document is unlimited.
The Real Time Streaming Protocol, or RTSP, is an application-level protocol ABSTRACT
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).
H. Schulzrinne, A. Rao, R. Lanphier Page 1 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).
Contents 1 Introduction
* 1 Introduction 1.1 Purpose
o 1.1 Purpose
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.8 GET_PARAMETER
o 9.9 SET_PARAMETER
o 9.10 REDIRECT
o 9.11 SESSION
o 9.12 RECORD
o 9.13 Embedded Binary Data
H. Schulzrinne, A. Rao, R. Lanphier Page 2 The Real-Time Streaming Protocol (RTSP) establishes and controls
* 10 Status Codes Definitions either a single or several time-synchronized streams of continuous
o 10.1 Client Error 4xx media such as audio and video. It does not typically deliver the
+ 10.1.1 451 Parameter Not Understood continuous streams itself, although interleaving of the continuous
+ 10.1.2 452 Conference Not Found media stream with the control stream is possible (see Section 9.11).
+ 10.1.3 453 Not Enough Bandwidth In other words, RTSP acts as a "network remote control" for
+ 10.1.4 45x Session Not Found multimedia servers.
+ 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
H. Schulzrinne, A. Rao, R. Lanphier Page 3 The set of streams to be controlled is defined by a presentation
* 14 Syntax description. This memorandum does not define a format for a
o 14.1 Base Syntax presentation description.
o 14.2 Internet Media Type Syntax
o 14.3 Universal Resource Identifier Syntax
o 14.4 RTSP-specific syntax
* 15 Experimental
o 15.1 Header Field Definitions
+ 15.1.1 Address
* 16 Security Considerations
* A State Machines
o A.1 Client State Machine
+ A.1.1 Client States
+ A.1.2 Notes
+ 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 Introduction There is no notion of an RTSP connection; instead, a server maintains
a session labeled by an identifier. An RTSP session is in no way tied
to a transport-level connection such as a TCP connection. During an
RTSP session, an RTSP client may open and close many reliable
transport connections to the server to issue RTSP requests.
Alternatively, it may use a connectionless transport protocol such as
UDP.
1.1 Purpose The streams controlled by RTSP may use RTP [1], but the operation of
RTSP does not depend on the transport mechanism used to carry
continuous media.
RTSP establishes and controls either single or several (time-synchronized) The protocol is intentionally similar in syntax and operation to
streams of continuous media. It does not typically deliver the continuous HTTP/1.1, so that extension mechanisms to HTTP can in most cases also
streams itself, although interleaving of the continuous media stream with be added to RTSP. However, RTSP differs in a number of important
the control stream is possible (Section 9.13). aspects from HTTP:
There is no notion of an RTSP connection, but rather a session maintained o RTSP introduces a number of new methods and has a different
by an identifier. An RTSP session is in no way tied to a transport-level protocol identifier.
session. During an RTSP session, an RTSP client may open and close many
reliable transport connections to the server to issue RTSP requests.
Alternatively, it may use a connectionless transport protocol such as UDP.
The protocol is intentionally similar in syntax and operation to HTTP/1.1, o An RTSP server needs to maintain state by default in almost
so that extension mechanisms to HTTP can in most cases also be added to all cases, as opposed to the stateless nature of HTTP. (RTSP
RTSP. However, RTSP differs in a number of important aspects from HTTP: servers and clients MAY use the HTTP state maintenance
mechanism [2].)
H. Schulzrinne, A. Rao, R. Lanphier Page 4 o Both an RTSP server and client can issue requests.
* RTSP introduces a number of new methods and has a different protocol
identifier.
* An RTSP server needs to maintain state by default in almost all cases,
as opposed to the stateless nature of HTTP. (RTSP servers and clients
MAY use the HTTP state maintenance mechanism [1].)
* 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].
HS: Probably the right thing to do, but may lead to o Data is carried out-of-band, by a different protocol. (There
confusion with GET. is an exception to this.)
* The Request-URI always contains the absolute URI. Because of backward o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
compatibility with a historical blunder, HTTP/1.1 carries only the 8859-1, consistent with current HTML internationalization
absolute path in the request efforts [3].
o The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1
carries only the absolute path in the request
This makes virtual hosting easier. However, this is This makes virtual hosting easier. However, this is
incompatible with HTTP/1.1, which may be a bad idea. Makes incompatible with HTTP/1.1, which may be a bad idea.
definition of GET confusing, if it is included in RTSP.
The protocol supports the following operations: The protocol supports the following operations:
Retrieval of media from media server: Retrieval of media from media server: The client can request a
The client can request a session description via HTTP or some other presentation description via HTTP or some other method. If the
method. If the session is being multicast, the session description presentation is being multicast, the presentation description
contains the multicast addresses and ports to be used for the 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 continuous media. If the presentation is to be sent only to the
unicast, the client provides the destination for security reasons. client via unicast, the client provides the destination for
security reasons.
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''.
Addition of media to an existing session: Invitation of a media server to a conference: A media server can be
Particularly for live events, it is useful if the server can tell the "invited" to join an existing conference, either to play back
client about additional media becoming available. media into the presentation or to record all or a subset of the
media in a presentation. This mode is useful for distributed
teaching applications. Several parties in the conference may
take turns "pushing the remote control buttons".
H. Schulzrinne, A. Rao, R. Lanphier Page 5 Addition of media to an existing presentation: Particularly for live
presentations, it is useful if the server can tell the client
about additional media becoming available.
RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1. RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1.
1.2 Requirements 1.2 Requirements
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
``OPTIONAL'' in this document are to be interpreted as described in RFC document are to be interpreted as described in RFC xxxx [4].
xxxx [3].
1.3 Terminology 1.3 Terminology
Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not Some of the terminology has been adopted from HTTP/1.1 [5]. Terms
listed here are defined as in HTTP/1.1. not listed here are defined as in HTTP/1.1.
Conference:
a multiparty, multimedia session, where ``multi'' implies greater than
or equal to one.
Client: Conference: a multiparty, multimedia presentation, where "multi"
The client requests continuous media data from the media server. implies greater than or equal to one.
Connection: Client: The client requests continuous media data from the media
A transport layer virtual circuit established between two programs for server.
the purpose of communication.
Continuous media: Connection: A transport layer virtual circuit established between two
Data where there is a timing relationship between source and sink, programs for the purpose of communication.
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.
Entity: Continuous media: Data where there is a timing relationship between
An entity is a participant in a conference. This participant may be source and sink, that is, the sink must reproduce the timing
non-human, e.g., a media record or playback server. 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.
Media server: Participant: Participants are members of conferences. A participant
The network entity providing playback or recording services for one or may be a machine, e.g., a media record or playback server.
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.
H. Schulzrinne, A. Rao, R. Lanphier Page 6 Media server: The network entity providing playback or recording
services for one or more media streams. Different media streams
within a presentation may originate from different media
servers. A media server may reside on the same or a different
host as the web server the presentation is invoked from.
Media session: Media parameter: Parameter specific to a media type that may be
A collection of media streams to be treated as an aggregate, with a changed while the stream is being played or prior to it.
single time axis. Typically, a client will synchronize in time all
media streams within a media session. An example of a media session is
a movie consisting of a video and audio track.
(Media) stream: (Media) stream: A single media instance, e.g., an audio stream or a
A single media instance, e.g., an audio stream or a video stream as video stream as well as a single whiteboard or shared
well as a single whiteboard or shared application group. When using application group. When using RTP, a stream consists of all RTP
RTP, a stream consists of all RTP and RTCP packets created by a source and RTCP packets created by a source within an RTP session. This
within an RTP session. is equivalent to the definition of a DSM-CC stream.
[TBD: terminology is confusing since there's an RTP session, which is Message: The basic unit of RTSP communication, consisting of a
used by a single RTSP stream.] structured sequence of octets matching the syntax defined in
Section 14 and transmitted via a connection or a connectionless
protocol.
Message: Presentation: A set of one or more streams which the server allows
The basic unit of RTSP communication, consisting of a structured the client to manipulate together. A presentation has a single
sequence of octets matching the syntax defined in Section 14 and time axis for all streams belonging to it. Presentations are
transmitted via a connection or a connectionless protocol. defined by presentation descriptions (see below). A presentation
description contains RTSP URIs that define which streams can be
controlled individually and an RTSP URI to control the whole
presentation. A movie or live concert consisting of one or more
audio and video streams is be an example of a presentation.
Response: Presentation description: A presentation description contains
An RTSP response. If an HTTP response is meant, that is indicated information about one or more media streams within a
explicitly. presentation, such as the set of encodings, network addresses
and information about the content. Other IETF protocols such as
SDP [6] use the term "session" for a live presentation. The
presentation description may take several different formats,
including but not limited to the session description format SDP.
Request: Response: An RTSP response. If an HTTP response is meant, that is
An RTSP request. If an HTTP request is meant, that is indicated indicated explicitly.
explicitly.
Session description: Request: An RTSP request. If an HTTP request is meant, that is
A session description contains information about one or more media indicated explicitly.
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.
Media parameter: RTSP session: A complete RTSP "transaction", e.g., the viewing of a
Parameter specific to a media type that may be changed while the movie. A session typically consist of a client setting up a
stream is being played or prior to it. transport mechanism for the continuous media stream ( SETUP),
starting the stream with PLAY or RECORD and closing the stream
with TEARDOWN.
1.4 Protocol Properties 1.4 Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: Extendable: New methods and parameters can be easily added to RTSP.
New methods and parameters can be easily added to RTSP.
H. Schulzrinne, A. Rao, R. Lanphier Page 7 Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers.
Easy to parse: Secure: RTSP re-uses web security mechanisms, either at the transport
RTSP can be parsed by standard HTTP or MIME parsers. level (TLS [7]) or within the protocol itself. All HTTP
authentication mechanisms such as basic [5] and digest
authentication [8] are directly applicable.
Secure: Transport-independent: RTSP may use either an unreliable datagram
RTSP re-uses web security mechanisms, either at the transport level protocol (UDP) [9], a reliable datagram protocol (RDP, not
(TLS [5]) or within the protocol itself. All HTTP authentication widely used [10]) or a reliable stream protocol such as TCP [11]
mechanisms such as basic [4, Section 11.1,] and digest authentication as it implements application-level reliability.
[6] are directly applicable.
Transport-independent: Multi-server capable: Each media stream within a presentation can
RTSP may use either an unreliable datagram protocol (UDP) [7], a reside on a different server. The client automatically
reliable datagram protocol (RDP, not widely used [8]) or a reliable establishes several concurrent control sessions with the
stream protocol such as TCP [9] as it implements application-level different media servers. Media synchronization is performed at
reliability. the transport level.
Multi-server capable: Control of recording devices: The protocol can control both recording
Each media stream within a session can reside on a different server. and playback devices, as well as devices that can alternate
The client automatically establishes several concurrent control between the two modes ("VCR").
sessions with the different media servers. Media synchronization is
performed at the transport level.
Control of recording devices: Separation of stream control and conference initiation: Stream
The protocol can control both recording and playback devices, as well control is divorced from inviting a media server to a
as devices that can alternate between the two modes (``VCR''). 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 [12] or H.323
may be used to invite a server to a conference.
Separation of stream control and conference initiation: Suitable for professional applications: RTSP supports frame-level
Stream control is divorced from inviting a media server to a accuracy through SMPTE time stamps to allow remote digital
conference. The only requirement is that the conference initiation editing.
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.
Suitable for professional applications: Presentation description neutral: The protocol does not impose a
RTSP supports frame-level accuracy through SMPTE time stamps to allow particular presentation description or metafile format and can
remote digital editing. convey the type of format to be used. However, the presentation
description must contain at least one RTSP URI.
Session description neutral: Proxy and firewall friendly: The protocol should be readily handled
The protocol does not impose a particular session description or by both application and transport-layer (SOCKS [13]) firewalls.
metafile format and can convey the type of format to be used. However, A firewall may need to understand the SETUP method to open a
the session description must contain an RTSP URI. "hole" for the UDP media stream.
Proxy and firewall friendly: HTTP-friendly: Where sensible, RTSP re-uses HTTP concepts, so that
The protocol should be readily handled by both application and the existing infrastructure can be re-used. This infrastructure
transport-layer (SOCKS [11]) firewalls. A firewall may need to includes JEPI (the Joint Electronic Payment Initiative) for
understand the SETUP method to open a ``hole'' for the UDP media electronic payments and PICS (Platform for Internet Content
stream. Selection) for associating labels with content. However, RTSP
does not just add methods to HTTP, since the controlling
continuous media requires server state in most cases.
H. Schulzrinne, A. Rao, R. Lanphier Page 8 Appropriate server control: If a client can start a stream, it must
be able to stop a stream. Servers should not start streaming to
clients in such a way that clients cannot stop the stream.
HTTP-friendly: Transport negotiation: The client can negotiate the transport method
Where sensible, RTSP re-uses HTTP concepts, so that the existing prior to actually needing to process a continuous media stream.
infrastructure can be re-used. This infrastructure includes JEPI (the
Joint Electronic Payment Initiative) for electronic payments and PICS
(Platform for Internet Content Selection) for associating labels with
content. However, RTSP does not just add methods to HTTP, since the
controlling continuous media requires server state in most cases.
Appropriate server control: Capability negotiation: If basic features are disabled, there must be
If a client can start a stream, it must be able to stop a stream. some clean mechanism for the client to determine which methods
Servers should not start streaming to clients in such a way that are not going to be implemented. This allows clients to present
clients cannot stop the stream. the appropriate user interface. For example, if seeking is not
allowed, the user interface must be able to disallow moving a
sliding position indicator.
Transport negotiation: An earlier requirement in RTSP' was multi-client
The client can negotiate the transport method prior to actually capability. However, it was determined that a better
needing to process a continuous media stream. approach was to make sure that the protocol is easily
extensible to the multi-client scenario. Stream identifiers
can be used by several control streams, so that "passing
the remote" would be possible. The protocol would not
address how several clients negotiate access; this is left
to either a "social protocol" or some other floor control
mechanism.
Capability negotiation: 1.5 Extending RTSP
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.
An earlier requirement in RTSP' was multi-client capability. Since not all media servers have the same functionality, media
However, it was determined that a better approach was to make servers by necessity will support different sets of requests. For
sure that the protocol is easily extensible to the multi-client example:
scenario. Stream identifiers can be used by several control
streams, so that ``passing the remote'' would be possible. The
protocol would not address how several clients negotiate access;
this is left to either a ``social protocol'' or some other floor
control mechanism.
1.5 Extending RTSP o A server may only be capable of playback, not recording and
thus has no need to support the RECORD request.
RTSP can be extended in three ways, listed in order of the magnitude of o A server may not be capable of seeking (absolute positioning),
changes supported: say, if it is to support live events only.
H. Schulzrinne, A. Rao, R. Lanphier Page 9 o Some servers may not support setting stream parameters and
* Existing methods can be extended with new parameters, as long as these thus not support GET_PARAMETER and SET_PARAMETER.
parameters can be safely ignored by the recipient. (This is equivalent
to adding new parameters to an HTML tag.) A server SHOULD implement all header fields described in Section 11.
* New methods can be added. If the recipient of the message does not
understand the request, it responds with error code 501 (Not It is up to the creators of presentation descriptions not to ask the
implemented) and the sender can then attempt an earlier, less impossible of a server. This situation is similar in HTTP/1.1, where
functional version. the methods described in [H19.6] are not likely to be supported
* A new version of the protocol can be defined, allowing almost all across all servers.
aspects (except the position of the protocol version number) to
change. RTSP can be extended in three ways, listed in order of the magnitude
of changes supported:
o Existing methods can be extended with new parameters, as long
as these parameters can be safely ignored by the recipient.
(This is equivalent to adding new parameters to an HTML tag.)
o New methods can be added. If the recipient of the message does
not understand the request, it responds with error code 501
(Not implemented) and the sender can then attempt an earlier,
less functional version.
o A new version of the protocol can be defined, allowing almost
all aspects (except the position of the protocol version
number) to change.
1.6 Overall Operation 1.6 Overall Operation
Each media stream and session may be identified by an RTSP URL. The overall Each presentation and media stream may be identified by an RTSP URL.
session and the properties of the media the session is made up of are The overall presentation and the properties of the media the
defined by a session description file, the format of which is outside the presentation is made up of are defined by a presentation description
scope of this specification. The session description file is retrieved file, the format of which is outside the scope of this specification.
using HTTP, either from the web server or the media server, typically using The presentation description file may be obtained by the client using
an URL with scheme HTTP. HTTP or other means such as email and may not necessarily be stored
on the media server.
The session description file contains a description of the media streams For the purposes of this specification, a presentation description is
making up the media session, including their encodings, language, and other assumed to describe one or more presentations, each of which
parameters that enable the client to choose the most appropriate maintains a common time axis. For simplicity of exposition and
combination of media. In this session description, each media stream is without loss of generality, it is assumed that the presentation
identified by an RTSP URL, which points to the media server handling that description contains exactly one such presentation. A presentation
particular media stream and names the stream stored on that server. Several may contain several media streams.
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.
Besides the media parameters, the network destination address and port need The presentation description file contains a description of the media
to be determined. Several modes of operation can be distinguished: streams making up the presentation, including their encodings,
language, and other parameters that enable the client to choose the
most appropriate combination of media. In this presentation
description, each media stream that is individually controllable by
RTSP 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 streams can be split across
servers for load sharing. The description also enumerates which
transport methods the server is capable of.
Unicast: Besides the media parameters, the network destination address and
The media is transmitted to the source of the RTSP request, with the port need to be determined. Several modes of operation can be
port number picked by the client. Alternatively, the media is distinguished:
transmitted on the same reliable stream as RTSP.
Multicast, server chooses address: Unicast: The media is transmitted to the source of the RTSP request,
The media server picks the multicast address and port. This is the with the port number chosen by the client. Alternatively, the
typical case for a live or near-media-on-demand transmission. media is transmitted on the same reliable stream as RTSP.
Multicast, client chooses address: Multicast, server chooses address: The media server picks the
If the server is to participate in an existing multicast conference, multicast address and port. This is the typical case for a live
the multicast address, port and encryption key are given by the or near-media-on-demand transmission.
conference description, established by means outside the scope of this
specification. Multicast, client chooses address: 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 specification.
1.7 RTSP States 1.7 RTSP States
RTSP controls a stream which may be sent via a separate protocol, RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may occur on independent of the control channel. For example, RTSP control may
a TCP connection while the data flows via UDP. Thus, data delivery occur on a TCP connection while the data flows via UDP. Thus, data
continues even if no RTSP requests are received by the media server. Also, delivery continues even if no RTSP requests are received by the media
during its lifetime, a single media stream may be controlled by RTSP server. Also, during its lifetime, a single media stream may be
requests issued sequentially on different TCP connections. Therefore, the controlled by RTSP requests issued sequentially on different TCP
server needs to maintain ``session state'' to be able to correlate RTSP connections. Therefore, the server needs to maintain "session state"
requests with a stream. to be able to correlate RTSP requests with a stream. The state
transitions are described in Section A.
HS: This does not imply that the protocol has to be stateful in
the way described here. If state were to be defined by identifier
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.
Many methods in RTSP do not contribute to state. However, there are four Many methods in RTSP do not contribute to state. However, the
that play a central role in defining the allocation and usage of stream following play a central role in defining the allocation and usage of
resources on the server: SETUP, PLAY, PAUSE, and CLOSE. The roles they play stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and
are defined as follows. TEARDOWN.
Step session allocation method session control method SETUP: Causes the server to allocate resources for a stream and start
1 SETUP an RTSP session.
2 PLAY
3 PAUSE
4 CLOSE
SETUP Causes the server to allocate resources for a stream. PLAY and RECORD: Starts data transmission on a stream allocated via
PLAY Starts data transmission on a stream allocated via SETUP. SETUP.
PAUSE Temporarily halts a stream, without freeing server resources.
CLOSE Frees resources associated with the stream. The session ceases to PAUSE: Temporarily halts a stream, without freeing server resources.
exist on the server.
A client must issue a SETUP request unless all necessary transport TEARDOWN: Frees resources associated with the stream. The RTSP
information is already available. session ceases to exist on the server.
1.8 Relationship with Other Protocols 1.8 Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may interact with RTSP has some overlap in functionality with HTTP. It also may
HTTP in that the initial contact with streaming content is often to be made interact with HTTP in that the initial contact with streaming content
through a web page. The current protocol specification aims to allow is often to be made through a web page. The current protocol
different hand-off points between a web server and the media server specification aims to allow different hand-off points between a web
implementing RTSP. For example, the session description can be retrieved server and the media server implementing RTSP. For example, the
using HTTP or RTSP. Having the session description be returned by the web presentation description can be retrieved using HTTP or RTSP. Having
server makes it possible to have the web server take care of authentication the presentation description be returned by the web server makes it
and billing, by handing out a session description whose media identifier possible to have the web server take care of authentication and
includes an encrypted version of the requestor's IP address and a billing, by handing out a presentation description whose media
timestamp, with a shared secret between web and media server. identifier includes an encrypted version of the requestor's IP
address and a timestamp, with a shared secret between web and media
server.
However, RTSP differs fundamentally from HTTP in that data delivery takes However, RTSP differs fundamentally from HTTP in that data delivery
place out-of-band, in a different protocol. HTTP is an asymmetric protocol, takes place out-of-band, in a different protocol. HTTP is an
where the client issues requests and the server responds. In RTSP, both the asymmetric protocol, where the client issues requests and the server
media client and media server can issue requests. RTSP requests are also responds. In RTSP, both the media client and media server can issue
not stateless, in that they may set parameters and continue to control a requests. RTSP requests are also not stateless, in that they may set
media stream long after the request has been acknowledged. parameters and continue to control a media stream long after the
request has been acknowledged.
Re-using HTTP functionality has advantages in at least two areas, Re-using HTTP functionality has advantages in at least two
namely security and proxies. The requirements are very similar, areas, namely security and proxies. The requirements are
so having the ability to adopt HTTP work on caches, proxies and very similar, so having the ability to adopt HTTP work on
authentication is valuable. caches, proxies and authentication is valuable.
While most real-time media will use RTP as a transport protocol, RTSP is While most real-time media will use RTP as a transport protocol, RTSP
not tied to RTP. is not tied to RTP.
RTSP assumes the existence of a session description format that can express RTSP assumes the existence of a presentation description format that
both static and temporal properties of a media session containing several can express both static and temporal properties of a presentation
media streams. containing several media streams.
2 Notational Conventions 2 Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1, this Since many of the definitions and syntax are identical to HTTP/1.1,
specification only points to the section where they are defined rather than this specification only points to the section where they are defined
copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of rather than copying it. For brevity, [HX.Y] is to be taken to refer
the current HTTP/1.1 specification (RFC 2068). to Section X.Y of the current HTTP/1.1 specification (RFC 2068).
All the mechanisms specified in this document are described in both prose All the mechanisms specified in this document are described in both
and an augmented Backus-Naur form (BNF) similar to that used in RFC 2068 prose and an augmented Backus-Naur form (BNF) similar to that used in
[H2.1]. It is described in detail in [12]. RFC 2068 [H2.1]. It is described in detail in [14].
In this draft, we use indented and smaller-type paragraphs to provide In this draft, we use indented and smaller-type paragraphs to provide
background and motivation. Some of these paragraphs are marked with HS, AR background and motivation. Some of these paragraphs are marked with
and RL, designating opinions and comments by the individual authors which HS, AR and RL, designating opinions and comments by the individual
may not be shared by the co-authors and require resolution. authors which may not be shared by the co-authors and require
resolution.
3 Protocol Parameters 3 Protocol Parameters
3.1 RTSP Version 3.1 RTSP Version
[H3.1] applies, with HTTP replaced by RTSP. applies, with HTTP replaced by RTSP.
3.2 RTSP URL 3.2 RTSP URL
The ``rtsp'' and ``rtspu'' schemes are used to refer to network resources The "rtsp" and "rtspu" schemes are used to refer to network resources
via the RTSP protocol. This section defines the scheme-specific syntax and via the RTSP protocol. This section defines the scheme-specific
semantics for RTSP URLs. syntax and semantics for RTSP URLs.
rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path] rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path]
host = <A legal Internet host domain name of IP address host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1 (in dotted decimal form), as defined by Section 2.1
of RFC 1123> of RFC 1123>
port = *DIGIT port = *DIGIT
abs_path is defined in [H3.2.1]. abs_path is defined in [H3.2.1].
Note that fragment and query identifiers do not have a Note that fragment and query identifiers do not have a
well-defined meaning at this time, with the interpretation left well-defined meaning at this time, with the interpretation
to the RTSP server. left to the RTSP server.
The scheme rtsp requires that commands are issued via a reliable protocol The scheme rtsp requires that commands are issued via a reliable
(within the Internet, TCP), while the scheme rtspu identifies an unreliable protocol (within the Internet, TCP), while the scheme rtspu
protocol (within the Internet, UDP). identifies an unreliable protocol (within the Internet, UDP).
If the port is empty or not given, port 554 is assumed. The semantics are If the port is empty or not given, port 554 is assumed. The semantics
that the identified resource can be controlled be RTSP at the server are that the identified resource can be controlled be RTSP at the
listening for TCP (scheme ``rtsp'') connections or UDP (scheme ``rtspu'') server listening for TCP (scheme "rtsp") connections or UDP (scheme
packets on that port of host, and the Request-URI for the resource is "rtspu") packets on that port of host , and the Request-URI for the
rtsp_URL. resource is rtsp_URL
The use of IP addresses in URLs SHOULD be avoided whenever possible (see The use of IP addresses in URLs SHOULD be avoided whenever possible
RFC 1924 [13]). (see RFC 1924 [15]).
A media presentation is identified by an textual media identifier, using A presentation or a stream is identified by an textual media
the character set and escape conventions [H3.2] of URLs []. Requests identifier, using the character set and escape conventions [H3.2] of
described in Section 9 can refer to either the whole presentation or an URLs [16]. Requests described in Section 9 can refer to either the
individual track within the presentation. Note that some methods can only whole presentation or an individual stream within the presentation.
be applied to tracks, not presentations. A specific instance of a session, Note that some methods can only be applied to streams, not
e.g., one of several concurrent transmissions of the same content, is presentations and vice versa. A specific instance of a presentation
indicated by the Session header field (Section 11.24) where needed. or stream, e.g., one of several concurrent transmissions of the same
content, an RTSP session , is indicated by the Session header field
(Section 11.26) where needed.
For example, the RTSP URL For example, the RTSP URL
rtsp://media.content.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
identifies the audio track within the presentation ``twister'', which can identifies the audio stream within the presentation "twister", which
be controlled via RTSP requests issued over a TCP connection to port 554 of can be controlled via RTSP requests issued over a TCP connection to
host media.content.com. port 554 of host media.example.com
This does not imply a standard way to reference tracks in URLs. This does not imply a standard way to reference streams in
The session description defines the hierarchical relationships in URLs. The presentation description defines the hierarchical
the presentation and the URLs for the individual tracks. A relationships in the presentation and the URLs for the
session description may name a track 'a.mov' and the whole individual streams. A presentation description may name a
presentation 'b.mov'. stream 'a.mov' and the whole presentation 'b.mov'.
The path components of the RTSP URL are opaque to the client and do not The path components of the RTSP URL are opaque to the client and do
imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows session descriptions to be used with This decoupling also allows presentation descriptions to be
non-RTSP media control protocols, simply by replacing the scheme used with non-RTSP media control protocols, simply by
in the URL. replacing the scheme in the URL.
3.3 Conference Identifiers 3.3 Conference Identifiers
Conference identifiers are opaque to RTSP and are encoded using standard Conference identifiers are opaque to RTSP and are encoded using
URI encoding methods (i.e., LWS is escaped with %). They can contain any standard URI encoding methods (i.e., LWS is escaped with %). They can
octet value. The conference identifier MUST be globally unique. For H.323, contain any octet value. The conference identifier MUST be globally
the conferenceID value is to be used. unique. For H.323, the conferenceID value is to be used.
conference-id = 1*OCTET ; LWS must be URL-escaped conference-id = 1*OCTET ; LWS must be URL-escaped
Conference identifiers are used to allow to allow RTSP sessions Conference identifiers are used to allow to allow RTSP
to obtain parameters from multimedia conferences the media server sessions to obtain parameters from multimedia conferences
is participating in. These conferences are created by protocols the media server is participating in. These conferences are
outside the scope of this specification, e.g., H.323 [15] or SIP created by protocols outside the scope of this
[10]. Instead of the RTSP client explicitly providing transport specification, e.g., H.323 [17] or SIP [12]. Instead of the
information, for example, it asks the media server to use the RTSP client explicitly providing transport information, for
values in the conference description instead. If the conference 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 participant inviting the media server would only supply a
conference identifier which is unique for that inviting party, conference identifier which is unique for that inviting
the media server could add an internal identifier for that party, party, the media server could add an internal identifier
e.g., its Internet address. However, this would prevent that the for that party, e.g., its Internet address. However, this
conference participant and the initiator of the RTSP commands are would prevent that the conference participant and the
two different entities. initiator of the RTSP commands are two different entities.
3.4 Relative Timestamps 3.4 SMPTE Relative Timestamps
A relative time-stamp expresses time relative to the start of the clip. A SMPTE relative time-stamp expresses time relative to the start of
Relative timestamps are expressed as SMPTE time codes for frame-level the clip. Relative timestamps are expressed as SMPTE time codes for
access accuracy. The time code has the format hours:minutes:seconds.frames, frame-level access accuracy. The time code has the format
with the origin at the start of the clip. For NTSC, the frame rate is 29.97 hours:minutes:seconds.frames
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 with the origin at the start of the clip. For NTSC, the frame rate is
be omitted. 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.
smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ] smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ]
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ] smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ]
Examples: Examples:
10:12:33.40 smpte=10:12:33.40-
10:7:33 smpte=10:7:33-
10:7:0 smpte=10:7:0-10:7:33
3.5 Absolute Time 3.5 Normal Play Time
Absolute time is expressed as ISO 8601 timestamps. It is always expressed Normal play time (NPT) indicates the stream absolute position
as UTC (GMT). relative to the beginning of the presentation, measured in seconds
and microseconds. The beginning of a presentation corresponds to 0
seconds and 0 microseconds. Negative values are not defined. The
microsecond field is always less than 1,000,000. NPT is defined as in
DSM-CC: "Intuitively, NPT is the clock the viewer associates with a
program. It is often digitally displayed on a VCR. NPT advances
normally when in normal play mode (scale = 1), advances at a faster
rate when in fast scan forward (high positive scale ratio),
decrements when in scan reverse (high negative scale ratio) and is
fixed in pause mode. NPT is [logically] equivalent to SMPTE time
codes." [18]
npt-range = "npt" "=" npt-time "-" [ npt-time ]
npt-time = 1*DIGIT [ ":" *DIGIT ]
Examples:
npt=123:45-125
3.6 Absolute Time
Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT).
Fractions of a second may be indicated.
utc-range = "clock" "=" utc-time "-" [ utc-time ] utc-range = "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z" utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT ; < YYYYMMDD > utc-date = 8DIGIT ; < YYYYMMDD >
utc-time = 6DIGIT ; < HHMMSS > utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >
Example for November 8, 1996 at 14h37 and 20 seconds UTC: Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC:
19961108T143720Z 19961108T143720.25Z
4 RTSP Message Example
RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 4 RTSP Message
encoding (RFC 2044). Lines are terminated by CRLF, but receivers should be RTSP is a text-based protocol and uses the ISO 10646 character set in
prepared to also interpret CR and LF by themselves as line terminators. UTF-8 encoding (RFC 2044). Lines are terminated by CRLF, but
receivers should be prepared to also interpret CR and LF by
themselves as line terminators.
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional
a self-describing manner. Since the number of parameters and the parameters in a self-describing manner. Since the number of
frequency of commands is low, processing efficiency is not a parameters and the frequency of commands is low, processing
concern. Text-based protocols, if done carefully, also allow easy efficiency is not a concern. Text-based protocols, if done
implementation of research prototypes in scripting languages such carefully, also allow easy implementation of research
as Tcl, Visual Basic and Perl. prototypes in scripting languages such as Tcl, Visual Basic
and Perl.
The 10646 character set avoids tricky character set switching, The 10646 character set avoids tricky character set switching, but is
but is invisible to the application as long as US-ASCII is being invisible to the application as long as US-ASCII is being used. This
used. This is also the encoding used for RTCP. ISO 8859-1 is also the encoding used for RTCP. ISO 8859-1 translates directly
translates directly into Unicode, with a high-order octet of into Unicode, with a high-order octet of zero. ISO 8859-1 characters
zero. ISO 8859-1 characters with the most-significant bit set are with the most-significant bit set are represented as 1100001x
represented as 1100001x 10xxxxxx. 10xxxxxx.
RTSP messages can be carried over any lower-layer transport protocol that RTSP messages can be carried over any lower-layer transport protocol
is 8-bit clean. that is 8-bit clean.
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent, unless parameters to further describe the method. Methods are idempotent,
otherwise noted. Methods are also designed to require little or no state unless otherwise noted. Methods are also designed to require little
maintenance at the media server. or no state maintenance at the media server.
4.1 Message Types 4.1 Message Types
See [H4.1] See [H4.1]
4.2 Message Headers 4.2 Message Headers
See [H4.2] See [H4.2]
4.3 Message Body 4.3 Message Body
See [H4.3] See [H4.3]
4.4 Message Length 4.4 Message Length
When a message-body is included with a message, the length of that body is When a message-body is included with a message, the length of that
determined by one of the following (in order of precedence): body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message-body (such as 1. Any response message which MUST NOT include a message-body
the 1xx, 204, and 304 responses) is always terminated by the first (such as the 1xx, 204, and 304 responses) is always
empty line after the header fields, regardless of the entity-header terminated by the first empty line after the header fields,
fields present in the message. regardless of the entity-header fields present in the
2. If a Content-Length header field (section 11.10) is present, its value message. (Note: An empty line consists of only CRLF.)
in bytes represents the length of the message-body. If this header
field is not present, a value of zero is assumed.
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 2. If a Content-Length header field (section 11.12) is
coding and requires the presence of the Content-Length header field. present, its value in bytes represents the length of the
message-body. If this header field is not present, a value
of zero is assumed.
Given the moderate length of session descriptions returned, the 3. By the server closing the connection. (Closing the
server should always be able to determine its length, even if it connection cannot be used to indicate the end of a request
is generated dynamically, making the chunked transfer encoding body, since that would leave no possibility for the server
unnecessary. Even though Content-Length must be present if there to send back a response.)
is any entity body, the rules ensure reasonable behavior even if
the length is not given explicitly. Note that RTSP does not (at present) support the HTTP/1.1 "chunked"
transfer coding and requires the presence of the Content-Length
header field.
Given the moderate length of presentation 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 5 Request
A request message from a client to a server or vice versa includes, within A request message from a client to a server or vice versa includes,
the first line of that message, the method to be applied to the resource, within the first line of that message, the method to be applied to
the identifier of the resource, and the protocol version in use. the resource, the identifier of the resource, and the protocol
version in use.
Request = Request-line CRLF Request = Request-line CRLF
*request-header *request-header
CRLF CRLF
[ message-body ] [ message-body ]
Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF
Method = "GET" ; Section Method = "DESCRIBE" ; Section
| "SETUP" ; Section | "GET_PARAMETER" ; Section
| "PLAY" ; Section | "OPTIONS" ; Section
| "PAUSE" ; Section | "PAUSE" ; Section
| "CLOSE" ; Section | "PLAY" ; Section
| "RECORD" ; Section | "RECORD" ; Section
| "REDIRECT" ; Section | "REDIRECT" ; Section
| "HELLO" ; Section | "SETUP" ; Section
| "SESSION" ; Section
| "BYE" ; Section
| "SET_PARAMETER" ; Section | "SET_PARAMETER" ; Section
| "GET_PARAMETER" ; Section | "TEARDOWN" ; Section
| extension-method | extension-method
extendion-method = token extension-method = token
Request-URI = absolute_URI Request-URI = "*" | absolute_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
seq-no = 1*DIGIT seq-no = 1*DIGIT
Note that in contrast to HTTP/1.1, RTSP requests always contain the 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 absolute URL (that is, including the scheme, host and port) rather
just the absolute path. than just the absolute path.
The asterisk "*" in the Request-URI means that the request does not
apply to a particular resource, but to the server itself, and is only
allowed when the method used does not necessarily apply to a
resource. One example would be
OPTIONS * RTSP/1.0
6 Response 6 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. Also, [H6] applies except that HTTP-Version is replaced by RTSP-Version
RTSP defines additional status codes and does not define some HTTP codes. define some HTTP codes. The valid response codes and the methods they
The valid response codes and the methods they can be used with are defined can be used with are defined in the table 1.
in the table 1 and 2.
After receiving and interpreting a request message, the recipient responds After receiving and interpreting a request message, the recipient
with an RTSP response message. responds with an RTSP response message.
Response = Status-Line ; Section Response = Status-Line ; Section
*( general-header ; Section *( general-header ; Section
| response-header ; Section | response-header ; Section
| entity-header ) ; Section | entity-header ) ; Section
CRLF CRLF
[ message-body ] ; Section [ message-body ] ; Section
6.1 Status-Line 6.1 Status-Line
The first line of a Response message is the Status-Line, consisting of the The first line of a Response message is the Status-Line , consisting
protocol version followed by a numeric status code, the sequence number of of the protocol version followed by a numeric status code, the
the corresponding request and the textual phrase associated with the status sequence number of the corresponding request and the textual phrase
code, with each element separated by SP characters. No CR or LF is allowed associated with the status code, with each element separated by SP
except in the final CRLF sequence. Note that the addition of a 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 Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF
6.1.1 Status Code and Reason Phrase 6.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the attempt to The Status-Code element is a 3-digit integer result code of the
understand and satisfy the request. These codes are fully defined in attempt to understand and satisfy the request. These codes are fully
section10. The Reason-Phrase is intended to give a short textual defined in section10. The Reason-Phrase is intended to give a short
description of the Status-Code. The Status-Code is intended for use by textual description of the Status-Code. The Status-Code is intended
automata and the Reason-Phrase is intended for the human user. The client for use by automata and the Reason-Phrase is intended for the human
is not required to examine or display the Reason-Phrase. 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 The first digit of the Status-Code defines the class of response. The
two digits do not have any categorization role. There are 5 values for the last two digits do not have any categorization role. There are 5
first digit: values for the first digit:
* 1xx: Informational - Request received, continuing process o 1xx: Informational - Request received, continuing process
* 2xx: Success - The action was successfully received, understood, and
accepted
* 3xx: Redirection - Further action must be taken in order to complete
the request
* 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
* 5xx: Server Error - The server failed to fulfill an apparently valid
request
The individual values of the numeric status codes defined for RTSP/1.0, and o 2xx: Success - The action was successfully received,
an example set of corresponding Reason-Phrase's, are presented below. The understood, and accepted
reason phrases listed here are only recommended - they may be replaced by
local equivalents without affecting the protocol. Note that RTSP adopts o 3xx: Redirection - Further action must be taken in order to
most HTTP/1.1 status codes and adds RTSP-specific status codes in the complete the request
starting at 450 to avoid conflicts with newly defined HTTP status codes.
o 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently
valid request
The individual values of the numeric status codes defined for
RTSP/1.0, and an example set of corresponding Reason-Phrase 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 Status-Code = "100" ; Continue
| "200" ; OK | "200" ; OK
| "201" ; Created | "201" ; Created
| "202" ; Accepted
| "203" ; Non-Authoritative Information
| "204" ; No Content
| "205" ; Reset Content
| "206" ; Partial Content
| "300" ; Multiple Choices | "300" ; Multiple Choices
| "301" ; Moved Permanently | "301" ; Moved Permanently
| "302" ; Moved Temporarily | "302" ; Moved Temporarily
| "303" ; See Other | "303" ; See Other
| "304" ; Not Modified | "304" ; Not Modified
| "305" ; Use Proxy | "305" ; Use Proxy
| "400" ; Bad Request | "400" ; Bad Request
| "401" ; Unauthorized | "401" ; Unauthorized
| "402" ; Payment Required | "402" ; Payment Required
| "403" ; Forbidden | "403" ; Forbidden
skipping to change at line 858 skipping to change at page 18, line 31
| "406" ; Not Acceptable | "406" ; Not Acceptable
| "407" ; Proxy Authentication Required | "407" ; Proxy Authentication Required
| "408" ; Request Time-out | "408" ; Request Time-out
| "409" ; Conflict | "409" ; Conflict
| "410" ; Gone | "410" ; Gone
| "411" ; Length Required | "411" ; Length Required
| "412" ; Precondition Failed | "412" ; Precondition Failed
| "413" ; Request Entity Too Large | "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large | "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type | "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood} | "451" ; Parameter Not Understood
| "452" ; Conference Not Found} | "452" ; Conference Not Found
| "453" ; Not Enough Bandwidth} | "453" ; Not Enough Bandwidth
| "45x" ; Session Not Found} | "45x" ; Session Not Found
| "45x" ; Method Not Valid in This State} | "45x" ; Method Not Valid in This State
| "45x" ; Header Field Not Valid for Resource} | "45x" ; Header Field Not Valid for Resource
| "45x" ; Invalid Range} | "45x" ; Invalid Range
| "45x" ; Parameter Is Read-Only} | "45x" ; Parameter Is Read-Only
| "500" ; Internal Server Error | "500" ; Internal Server Error
| "501" ; Not Implemented | "501" ; Not Implemented
| "502" ; Bad Gateway | "502" ; Bad Gateway
| "503" ; Service Unavailable | "503" ; Service Unavailable
| "504" ; Gateway Time-out | "504" ; Gateway Time-out
| "505" ; HTTP Version not supported | "505" ; HTTP Version not supported
| extension-code | extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *<TEXT, excluding CR, LF>
RTSP status codes are extensible. RTSP applications are not required
RTSP status codes are extensible. RTSP applications are not required to to understand the meaning of all registered status codes, though such
understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST
understanding is obviously desirable. However, applications MUST understand understand the class of any status code, as indicated by the first
the class of any status code, as indicated by the first digit, and treat digit, and treat any unrecognized response as being equivalent to the
any unrecognized response as being equivalent to the x00 status code of x00 status code of that class, with the exception that an
that class, with the exception that an unrecognized response MUST NOT be unrecognized response MUST NOT be cached. For example, if an
cached. For example, if an unrecognized status code of 431 is received by unrecognized status code of 431 is received by the client, it can
the client, it can safely assume that there was something wrong with its safely assume that there was something wrong with its request and
request and treat the response as if it had received a 400 status code. In treat the response as if it had received a 400 status code. In such
such cases, user agents SHOULD present to the user the entity returned with cases, user agents SHOULD present to the user the entity returned
the response, since that entity is likely to include human-readable with the response, since that entity is likely to include human-
information which will explain the unusual status. readable information which will explain the unusual status.
Code reason HELLO GET SETUP PLAY RECORD PAUSE
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
Code reason CLOSE REDIRECT GET_PARAMETER SET_PARAMETER
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
Required
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
Large
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
Identifier
45x Illegal Session x x
Identifier
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
Supported
Table 2: Status codes and their usage with RTSP methods
6.1.2 Response Header Fields 6.1.2 Response Header Fields
The response-header fields allow the request recipient to pass additional The response-header fields allow the request recipient to pass
information about the response which cannot be placed in the Status-Line. additional information about the response which cannot be placed in
These header fields give information about the server and about further the Status-Line server and about further access to the resource
access to the resource identified by the Request-URI. identified by the Request-URI
response-header = Location ; Section response-header = Location ; Section
| Proxy-Authenticate ; Section | Proxy-Authenticate ; Section
| Public ; Section | Public ; Section
| Retry-After ; Section | Retry-After ; Section
| Server ; Section | Server ; Section
| Vary ; Section | Vary ; Section
| WWW-Authenticate ; Section | WWW-Authenticate ; Section
Response-header field names can be extended reliably only in combination Response-header field names can be extended reliably only in
with a change in the protocol version. However, new or experimental header combination with a change in the protocol version. However, new or
fields MAY be given the semantics of response-header fields if all parties experimental header fields MAY be given the semantics of response-
in the communication recognize them to be response-header fields. header fields if all parties in the communication recognize them to
Unrecognized header fields are treated as entity-header fields. be response-header fields. Unrecognized header fields are treated as
entity-header fields.
7 Entity 7 Entity
Request and Response messages MAY transfer an entity if not otherwise Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
In this section, both sender and recipient refer to either the client or In this section, both sender and recipient refer to either the client
the server, depending on who sends and who receives the entity. Code reason
_______________________________________________________________
100 Continue all
_______________________________________________________________
200 OK all
201 Created RECORD
_______________________________________________________________
300 Multiple Choices all
301 Moved Permanently all
302 Moved Temporarily all
303 See Other all
305 Use Proxy all
_______________________________________________________________
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
409 Conflict
410 Gone all
411 Length Required SETUP
412 Precondition Failed
413 Request Entity Too Large SETUP
414 Request-URI Too Long all
415 Unsupported Media Type SETUP
45x Only Valid for Stream SETUP
45x Invalid parameter SETUP
45x Not Enough Bandwidth SETUP
45x Illegal Conference Identifier SETUP
45x Illegal Session Identifier PLAY, RECORD, TEARDOWN
45x Parameter Is Read-Only SET_PARAMETER
45x Header Field Not Valid all
_______________________________________________________________
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
Table 1: Status codes and their usage with RTSP methods
or the server, depending on who sends and who receives the entity.
7.1 Entity Header Fields 7.1 Entity Header Fields
Entity-header fields define optional metainformation about the entity-body Entity-header fields define optional metainformation about the
or, if no body is present, about the resource identified by the request. entity-body or, if no body is present, about the resource identified
by the request.
entity-header = Allow ; Section 14.7 entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.12 | Content-Encoding ; Section 14.12
| Content-Language ; Section 14.13 | Content-Language ; Section 14.13
| Content-Length ; Section 14.14 | Content-Length ; Section 14.14
| Content-Type ; Section 14.18 | Content-Type ; Section 14.18
| Expires ; Section 14.21 | Expires ; Section 14.21
| Last-Modified ; Section 14.29 | Last-Modified ; Section 14.29
| extension-header | extension-header
extension-header = message-header extension-header = message-header
The extension-header mechanism allows additional entity-header fields to be The extension-header mechanism allows additional entity-header fields
defined without changing the protocol, but these fields cannot be assumed to be defined without changing the protocol, but these fields cannot
to be recognizable by the recipient. Unrecognized header fields SHOULD be be assumed to be recognizable by the recipient. Unrecognized header
ignored by the recipient and forwarded by proxies. fields SHOULD be ignored by the recipient and forwarded by proxies.
7.2 Entity Body 7.2 Entity Body
See [H7.2] See [H7.2]
8 Connections 8 Connections
RTSP requests can be transmitted in several different ways: RTSP requests can be transmitted in several different ways:
* persistent transport connections used for several request-response o persistent transport connections used for several request-
transactions; response transactions;
* one connection per request/response transaction;
* connectionless mode.
The type of transport connection is defined by the RTSP URI (Section 3.2). o one connection per request/response transaction;
For the scheme ``rtsp'', a persistent connection is assumed, while the
scheme ``rtspu'' calls for RTSP requests to be send without setting up a
connection.
Unlike HTTP, RTSP allows the media server to send requests to the media o connectionless mode.
client. However, this is only supported for persistent connections, as the
media server otherwise has no reliable way of reaching the client. Also, The type of transport connection is defined by the RTSP URI (Section
this is the only way that requests from media server to client are likely 3.2). For the scheme "rtsp", a persistent connection is assumed,
to traverse firewalls. while the scheme "rtspu" calls for RTSP requests to be send without
setting up a connection.
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 8.1 Pipelining
A client that supports persistent connections or connectionless mode MAY A client that supports persistent connections or connectionless mode
``pipeline'' its requests (i.e., send multiple requests without waiting for MAY "pipeline" its requests (i.e., send multiple requests without
each response). A server MUST send its responses to those requests in the waiting for each response). A server MUST send its responses to those
same order that the requests were received. requests in the same order that the requests were received.
8.2 Reliability and Acknowledgements 8.2 Reliability and Acknowledgements
Requests are acknowledged by the receiver unless they are sent to a Requests are acknowledged by the receiver unless they are sent to a
multicast group. If there is no acknowledgement, the sender may resend the multicast group. If there is no acknowledgement, the sender may
same message after a timeout of one round-trip time (RTT). The round-trip resend the same message after a timeout of one round-trip time (RTT).
time is estimated as in TCP (RFC TBD), with an initial round-trip value of The round-trip time is estimated as in TCP (RFC TBD), with an initial
500 ms. An implementation MAY cache the last RTT measurement as the initial round-trip value of 500 ms. An implementation MAY cache the last RTT
value for future connections. If a reliable transport protocol is used to measurement as the initial value for future connections. If a
carry RTSP, the timeout value MAY be set to an arbitrarily large value. 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 This can greatly increase responsiveness for proxies
each request transmitted. If a request is repeated because of lack of operating in local-area networks with small RTTs. The
acknowledgement, the sequence number is incremented. 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.
This avoids ambiguities when computing round-trip time estimates. 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.
[TBD: An initial sequence number negotiation needs to be added for UDP; This avoids ambiguities when computing round-trip time
otherwise, a new stream connection may see a request be acknowledged by a estimates. [TBD: An initial sequence number negotiation
delayed response from an earlier ``connection''. This handshake can be needs to be added for UDP; otherwise, a new stream
avoided with a sequence number containing a timestamp of sufficiently high connection may see a request be acknowledged by a delayed
resolution.] response from an earlier "connection". This handshake can
be avoided with a sequence number containing a timestamp of
sufficiently high resolution.]
The reliability mechanism described here does not protect against The reliability mechanism described here does not protect against
reordering. This may cause problems in some instances. For example, a CLOSE reordering. This may cause problems in some instances. For example, a
followed by a PLAY has quite a different effect than the reverse. TEARDOWN followed by a PLAY has quite a different effect than the
Similarly, if a PLAY request arrives before all parameters are set due to reverse. Similarly, if a PLAY request arrives before all parameters
reordering, the media server would have to issue an error indication. Since are set due to reordering, the media server would have to issue an
sequence numbers for retransmissions are incremented (to allow easy RTT error indication. Since sequence numbers for retransmissions are
estimation), the receiver cannot just ignore out-of-order packets. [TBD: incremented (to allow easy RTT estimation), the receiver cannot just
This problem could be fixed by including both a sequence number that stays ignore out-of-order packets. [TBD: This problem could be fixed by
the same for retransmissions and a timestamp for RTT estimation.] 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 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 support UDP. The default port for the RTSP server is 554 for both UDP
TCP. and TCP.
A number of RTSP packets destined for the same control end point may be A number of RTSP packets destined for the same control end point may
packed into a single lower-layer PDU or encapsulated into a TCP stream. be packed into a single lower-layer PDU or encapsulated into a TCP
RTSP data MAY be interleaved with RTP and RTCP packets. Unlike HTTP, an stream. RTSP data MAY be interleaved with RTP and RTCP packets.
RTSP method header MUST contain a Content-Length whenever that method Unlike HTTP, an RTSP method header MUST contain a Content-Length
contains a payload. Otherwise, an RTSP packet is terminated with an empty whenever that method contains a payload. Otherwise, an RTSP packet is
line immediately following the method header. terminated with an empty line immediately following the method
header.
9 Method Definitions 9 Method Definitions
The method token indicates the method to be performed on the resource The method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. New methods identified by the Request-URI case-sensitive. New methods may be
may be defined in the future. Method names may not start with a $ character defined in the future. Method names may not start with a $ character
(decimal 24) and must be a token. (decimal 24) and must be a token
method direction requirement method direction object requirement
GET C->S recommended ________________________________________________________
SETUP C->S recommended DESCRIBE C -> S, S -> C P,S recommended
PLAY C->S required GET_PARAMETER C -> S, S -> C P,S optional
PAUSE C->S recommended OPTIONS C -> S P,S required
CLOSE C->S required PAUSE C -> S P,S recommended
REDIRECT S->C optional PLAY C -> S P,S required
SESSION S->C optional RECORD C -> S P,S optional
RECORD C->S optional REDIRECT S -> C P,S optional
BYE C->S required? SETUP C -> S S required
SET_PARAMETER C->S, S->C optional SET_PARAMETER C -> S, S -> C P,S optional
GET_PARAMETER C->S, S->C optional TEARDOWN C -> S P,S required
Table 3: Overview of RTSP methods Table 2: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on
HS: PAUSE is recommend, but not required in that a fully Notes on Table 2: PAUSE is recommend, but not required in that a
functional server can be built that does not support this method, fully functional server can be built that does not support this
for example, for live feeds. Similarly, SETUP is not needed for a method, for example, for live feeds. If a server does not support a
server that only handles multicast events with transport particular method, it MUST return "501 Not Implemented" and a client
parameters set outside of RTSP. GET and BYE are controversial. SHOULD not try this method again for this server.
9.1 HELLO 9.1 OPTIONS
RTSP sessions MAY be initiated by a HELLO message. The request URI is "*" The behavior is equivalent to that described in [H9.2]. An OPTIONS
to indicate that the request pertains to the session itself. The primary request may be issued at any time, e.g., if the client is about to
use of the HELLO message is to verify the identity of the sender to the try a non-standard request. It does not influence server state.
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 In addition, if the optional Require header is present, option tags
the header indicate features needed by the requestor that are not required within the header indicate features needed by the requestor that are
at the version level of the protocol. not required at the version level of the protocol.
Example 1: Example 1:
C->S: HELLO * RTSP/1.0 1 C->S: OPTIONS * RTSP/1.0 1
Require: implicit-play, record-feature Require: implicit-play, record-feature
Transport-Require: switch-to-udp-control, gzipped-messages Transport-Require: switch-to-udp-control, gzipped-messages
Note that these are fictional features (though we may want to make them Note that these are fictional features (though we may want to make
real one day). them real one day).
Example 2 (using RFC2069-style authentication only as an example): Example 2 (using RFC2069-style authentication only as an example):
S->C: HELLO * RTSP/1.0 1 S->C: OPTIONS * RTSP/1.0 1
Authenticate: Digest realm="testrealm@host.com", Authenticate: Digest realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
Response:
Possible errors: 401, Parameter Not Understood
Examples:
S->C: RTSP/1.0 200 1 OK S->C: RTSP/1.0 200 1 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Nack-Transport-Require: switch-to-udp-control Nack-Transport-Require: switch-to-udp-control
Note that these are fictional features (though we may want to make them Note that these are fictional features (though we may want to make
real one day). them real one day).
Example 2 (using RFC2069-style authentication only as an example): Example 2 (using RFC2069-style authentication only as an example):
C->S: RTSP/1.0 401 1 Unauthorized C->S: RTSP/1.0 401 1 Unauthorized
Authorization: Digest username="Mufasa", Authorization: Digest username="Mufasa",
realm="testrealm@host.com", realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html", uri="/dir/index.html",
response="e966c932a9242554e42c8ee200cec7f6", response="e966c932a9242554e42c8ee200cec7f6",
opaque="5ccc069c403ebaf9f0171e9517f40e41" opaque="5ccc069c403ebaf9f0171e9517f40e41"
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 9.2 DESCRIBE
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. The DESCRIBE method retrieves the description of a presentation or
media object identified by the request URL from a server. It may use
the Accept header to specify the description formats that the client
understands. The server responds with a description of the requested
resource. Alternatively, the server may "push" a new description to
the client, for example, if a new stream has become available. If a
new media stream is added to a presentation (e.g., during a live
presentation), the whole presentation description should be sent
again, rather than just the additional components, so that components
can be deleted.
Example: Example:
C->S: GET rtsp://server.example.com/fizzle/foo RTSP/1.0 312 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 312
Accept: application/sdp, application/sdf, application/mheg Accept: application/sdp, application/rtsl, application/mheg
Bandwidth: 4000
S->C: RTSP/1.0 200 312 OK S->C: RTSP/1.0 200 312 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 376 Content-Length: 376
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
skipping to change at line 1271 skipping to change at page 26, line 4
a=recvonly a=recvonly
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB m=whiteboard 32416 UDP WB
a=orient:portrait a=orient:portrait
or or
S->C: RTSP/1.0 200 312 OK S->C: RTSP/1.0 200 312 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/x-rtsp-mh Content-Type: application/rtsl
Content-Length: 2782 Content-Length: 2782
<2782 octets of data containing stream descriptions and <2782 octets of data containing stream description>
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 Server to client example:
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 S->C: DESCRIBE /twister RTSP/1.0 902
should be limited, and therefore, it may be appropriate to come Session: 1234
up with another name for this message. Content-Type: application/rtsl
HS believes that this only works if GET is required. Otherwise, new RTSL presentation description
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.
9.3 SETUP 9.3 SETUP
The SETUP request for a URI specifies the transport mechanism to be used The SETUP request for a URI specifies the transport mechanism to be
for the streamed media. Note that SETUP makes sense only for an individual used for the streamed media. A client can issue a SETUP request for
media stream, rather than an aggregate. A client can issue a SETUP request a stream that is already playing to change transport parameters. For
for a stream that is already playing to change transport parameters. the benefit of any intervening firewalls, a client must indicate the
transport parameters even if it has no influence over these
parameters, for example, where the server advertises a fixed
multicast address.
If the optional Require header is present, option tags within the header This avoids having firewall to parse numerous different
indicate features needed by the requestor that are not required at the presentation description formats, for information which is
version level of the protocol. The Transport-Require header is used to irrelevant.
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 If the optional Require header is present, option tags within the
since PEP is standards-track, has more functionality and somebody header indicate features needed by the requestor that are not
already did the work. 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.
The Transport header specifies the transports acceptable to the client for HS: In my opinion, the Require header should be replaced by
data transmission; the response will contain the transport selected by the PEP since PEP is standards-track, has more functionality
server. and somebody already did the work.
The Transport header specifies the transport parameters acceptable
to the client for data transmission; the response will contain the
transport parameters selected by the server.
C->S: SETUP foo/bar/baz.rm RTSP/1.0 302 C->S: SETUP foo/bar/baz.rm RTSP/1.0 302
Transport: rtp/udp;port=458 Transport: rtp/udp;port=458
S->C: RTSP/1.0 200 302 OK S->C: RTSP/1.0 200 302 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Transport: cush/udp;port=458 Transport: cush/udp;port=458
9.4 PLAY 9.4 PLAY
The PLAY method tells the server to start sending data via the mechanism The PLAY method tells the server to start sending data via the
specified in SETUP. A client MUST NOT issue a PLAY request until any mechanism specified in SETUP. A client MUST NOT issue a PLAY request
outstanding SETUP request have been acknowledged as successful. until any outstanding SETUP requests have been acknowledged as
successful.
A PLAY request without a Range header is legal. It starts playing a stream The PLAY request positions the normal play time to the beginning of
from the beginning unless the stream has been paused. If a stream has been the range specified and delivers stream data until the end of the
paused via PAUSE, stream delivery resumes at the pause point. If a stream range is reached. PLAY requests may be pipelined (queued); a server
is playing, such a PLAY request causes no further action and can be used by MUST queue PLAY requests to be executed in order. That is, a PLAY
the client to test server liveness. request arriving while a previous PLAY request is still active is
delayed until the first has been completed.
The following example plays the whole session starting at SMPTE time code This allows precise editing. For example, regardless of
0:10:20 until the end of the clip. how closely spaced the two PLAY commands in the example
below arrive, the server will play first second 10 through
15 and then, immediately following, seconds 20 to 25 and
finally seconds 30 through the end.
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 835
Range: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 836
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 837
Range: npt=30-
See the description of the PAUSE request for further examples.
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 Range header may also contain a time parameter. This parameter
specifies a time in UTC at which the playback should start. If the
message is received after the specified time, playback is started
immediately. The time parameter may be used to aid in
synchronisation of streams obtained from different sources.
For a on-demand stream, the server replies back with the actual range
that will be played back. This may differ from the requested range if
alignment of the requested range to valid frame boundaries is
required for the media source. If no range is specified in the
request, the current position is returned in the reply. The unit of
the range in the reply is the same as that in the request.
After playing the desired range, the presentation is automatically
paused, as if a PAUSE request had been issued.
The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. The playback is to start
at 15:36 on 23 Jan 1997.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833
Range: smpte=0:10:20- Range: smpte=0:10:20-;time=19970123T153600Z
For playing back a recording of a live event, it may be desirable to use S->C: RTSP/1.0 200 833 OK
clock units: Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
For playing back a recording of a live presentation, it may be
desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 833 OK S->C: RTSP/1.0 200 833 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
A media server only supporting playback MUST support the smpte format and A media server only supporting playback MUST support the smpte format
MAY support the clock format. and MAY support the clock format.
RL says: We had considered optionally overloading PLAY with SETUP 9.5 PAUSE
information. This would have potentially allowed a case where one The PAUSE request causes the stream delivery to be interrupted
could implement a minimal RTSP server that only handles the PLAY (halted) temporarily. If the request URL names a stream, only
command. However, we decided that supporting that minimal of a playback and recording of that stream is halted. For example, for
server was problematic for a couple of reasons: audio, this is equivalent to muting. If the request URL names a
presentation or group of streams, delivery of all currently active
streams within the presentation or group is halted. After resuming
playback or recording, synchronization of the tracks MUST be
maintained. Any server resources are kept.
* We must be able to negotiate the transport (i.e. have server The PAUSE request may contain a Range header specifying when the
acknowledgment) prior to actually needing to deal with the stream or presentation is to be halted. The header must contain
data. We don't want to have a server start spewing packets exactly one value rather than a time range. The normal play time for
at us before we are ready to deal with them. The server the stream is set to that value. The pause request becomes effective
acknowledgment with setup information MUST arrive before the the first time the server is encountering the time point specified.
first packet. If this header is missing, stream delivery is interrupted immediately
* We need make sure that we aren't dealing with an allocation on receipt of the message.
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 For example, if the server has play requests for ranges 10 to 15 and
if the session description contains all necessary information, 20 to 29 pending and then receives a pause request for NPT 21, it
without options. The client knows whether it needs to configure would start playing the second range and stop at NPT 21. If the pause
transport parameters or not. For multicast delivery, for example, request is for NPT 12 and the server is playing at NPT 13 serving the
it likely would not have to set additional parameters. I doubt first play request, it stops immediately. If the pause request is for
that allowing one additional parameter is going to greatly NPT 16, it stops after completing the first play request and discards
complicate or slow down a server. the second play request.
9.5 PAUSE As another example, if a server has received requests to play ranges
10 to 15 and then 13 to 20, that is, overlapping ranges, the PAUSE
request for NPT=14 would take effect while playing the first range,
with the second PLAY request effectively being ignored, assuming the
PAUSE request arrives before the server has started playing the
second, overlapping range. Regardless of when the PAUSE request
arrives, it sets the NPT to 14.
The PAUSE request causes the stream delivery to be interrupted (halted) If the server has already sent data beyond the time specified in the
temporarily. If the request URL names a track, only playback and recording Range header, a PLAY would still resume at that point in time, as it
of that track is halted. If the request URL names a presentation, delivery is assumed that the client has discarded data after that point. This
of all currently active tracks is halted. After resuming playback or ensures continuous pause/play cycling without gaps.
recording, synchronization of the tracks MUST be maintained. Any server
resources are kept.
Example: Example:
C->S: PAUSE /fizzle/foo RTSP/1.0 834 C->S: PAUSE /fizzle/foo RTSP/1.0 834
S->C: RTSP/1.0 200 834 OK S->C: RTSP/1.0 200 834 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
9.6 CLOSE 9.6 TEARDOWN
Stop the stream delivery for the given URI, freeing the resources 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 associated with it. If the URI is the root node for this
session identifier associated with the session is no longer valid. Unless presentation, any RTSP session identifier associated with the session
all transport parameters are defined by the session description, a SETUP is no longer valid. Unless all transport parameters are defined by
request has to be issued before the session can be played again. the session description, a SETUP request has to be issued before the
session can be played again.
Example: Example:
C->S: CLOSE /fizzle/foo RTSP/1.0 892 C->S: TEARDOWN /fizzle/foo RTSP/1.0 892
S->C: RTSP/1.0 200 892 OK S->C: RTSP/1.0 200 892 OK
9.7 BYE 9.7 GET_PARAMETER
Terminate the session.
Example:
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.
9.8 GET_PARAMETER
The requests retrieves the value value of a parameter of a session The requests retrieves the value of a parameter of a presentation or
component specified in the URI. Multiple parameters can be requested in the stream specified in the URI. Multiple parameters can be requested in
message body using the content type text/rtsp-parameters. Note that the message body using the content type text/rtsp-parameters Note
parameters include server and client statistics. [HS: registry of parameter that parameters include server and client statistics. IANA registers
names for statistics and other purposes, possibly using the HTTP feature parameter names for statistics and other purposes. GET_PARAMETER with
registration mechanism.] A GET_PARAMETER with no entity body may be used to no entity body may be used to test client or server liveness
test client or server liveness (``ping''). ("ping").
Example: Example:
S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431 S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431
Content-Type: text/rtsp-parameters Content-Type: text/rtsp-parameters
Session: 1234 Session: 1234
Content-Length: 15 Content-Length: 15
packets_received packets_received
jitter jitter
C->S: RTSP/1.0 200 431 OK C->S: RTSP/1.0 200 431 OK
Content-Length: 46 Content-Length: 46
Content-Type: text/rtsp-parameters Content-Type: text/rtsp-parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
9.9 SET_PARAMETER 9.8 SET_PARAMETER
This method requests to set the value of a parameter for a session This method requests to set the value of a parameter for a
component specified by the URI. presentation or stream specified by the URI.
A request SHOULD only contain a single parameter to allow the client to A request SHOULD only contain a single parameter to allow the client
determine why a particular request failed. A server MUST allow a parameter to determine why a particular request failed. A server MUST allow a
to be set repeatedly to the same value, but it MAY disallow changing parameter to be set repeatedly to the same value, but it MAY disallow
parameter values. changing parameter values.
Note: transport parameters for the media stream MUST only be set with the Note: transport parameters for the media stream MUST only be set with
SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for the Restricting setting transport parameters to SETUP is for
benefit of firewalls. the benefit of firewalls.
The parameters are split in a fine-grained fashion so that there The parameters are split in a fine-grained fashion so that
can be more meaningful error indications. However, it may make there can be more meaningful error indications. However, it
sense to allow the setting of several parameters if an atomic may make sense to allow the setting of several parameters
setting is desirable. Imagine device control where the client if an atomic setting is desirable. Imagine device control
does not want the camera to pan unless it can also tilt to the where the client does not want the camera to pan unless it
right angle at the same time. 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 A SET_PARAMETER request without parameters can be used as a way to
client or server liveness. detect client or server liveness.
Example: Example:
C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421 C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421
Content-type: text/rtsp-parameters Content-type: text/rtsp-parameters
fooparam: foostuff fooparam: foostuff
barparam: barstuff barparam: barstuff
S->C: RTSP/1.0 450 421 Invalid Parameter S->C: RTSP/1.0 450 421 Invalid Parameter
Content-Length: 6 Content-Length: 6
barparam barparam
9.10 REDIRECT 9.9 REDIRECT
A redirect request informs the client that it must connect to another A redirect request informs the client that it must connect to another
server location. It contains the mandatory header Location, which indicates server location. It contains the mandatory header Location, which
that the client should issue a GET for that URL. It may contain the indicates that the client should issue a DESCRIBE for that URL. It
parameter Range, which indicates when the redirection takes effect. 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 This example request redirects traffic for this URI to the new server
the given play time: at the given play time:
S->C: REDIRECT /fizzle/foo RTSP/1.0 732 S->C: REDIRECT /fizzle/foo RTSP/1.0 732
Location: rtsp://bigserver.com:8001 Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z- Range: clock=19960213T143205Z-
9.11 SESSION 9.10 RECORD
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.
Example:
S->C: SESSION /twister RTSP/1.0 902
Session: 1234
Content-Type: application/sdp
Session Description
9.12 RECORD This method initiates recording a range of media data according to
the presentation description. The timestamp reflects start and end
time (UTC). If no time range is given, use the start or end time
provided in the presentation description. If the session has already
started, commence recording immediately. The Conference header is
mandatory.
This method initiates recording a range of media data according to the The server decides whether to store the recorded data under the
session description. The timestamp reflects start and end time (UTC). If no request-URI or another URI. If the server does not use the request-
time range is given, use the start or end time provided in the session URI, the response SHOULD be 201 (Created) and contain an entity which
description. If the session has already started, commence recording describes the status of the request and refers to the new resource,
immediately. The Conference header is mandatory. and a Location header.
A media server supporting recording of live events MUST support the clock A media server supporting recording of live presentations MUST
range format; the smpte format does not make sense. support the clock range format; the smpte format does not make sense.
In this example, the media server was previously invited to the conference In this example, the media server was previously invited to the
indicated. conference indicated.
C->S: RECORD /meeting/audio.en RTSP/1.0 954 C->S: RECORD /meeting/audio.en RTSP/1.0 954
Session: 1234 Session: 1234
Conference: 128.16.64.19/32492374 Conference: 128.16.64.19/32492374
9.13 Embedded Binary Data 9.11 Embedded Binary Data
Binary packets such as RTP data are encapsulated by an ASCII dollar sign Binary packets such as RTP data are encapsulated by an ASCII dollar
(24 decimal), followed by a one-byte session identifier, followed by the sign (24 decimal), followed by a one-byte session identifier,
length of the encapsulated binary data as a binary, two-byte integer in followed by the length of the encapsulated binary data as a binary,
network byte order. The binary data follows immediately afterwards, without two-byte integer in network byte order. The binary data follows
a CRLF. immediately afterwards, without a CRLF.
Status Codes Definitions 10 Status Code Definitions
Where applicable, HTTP status [H10] codes are re-used. Status codes that Where applicable, HTTP status [H10] codes are re-used. Status codes
have the same meaning are not repeated here. See Tables 1 and 2 for a that have the same meaning are not repeated here. See Table 1 for a
listing of which status codes may be returned by which request. listing of which status codes may be returned by which request.
10.1 Client Error 4xx 10.1 Redirection 3xx
10.1.1 451 Parameter Not Understood See [H10.3].
Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the
scope of this specification.
10.2 Client Error 4xx
10.2.1 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. contained in the request.
10.1.2 452 Conference Not Found 10.2.2 452 Conference Not Found
The conference indicated by a Conference header field is unknown to the The conference indicated by a Conference header field is unknown to
media server. the media server.
10.1.3 453 Not Enough Bandwidth 10.2.3 453 Not Enough Bandwidth
The request was refused since there was insufficient bandwidth. This may, The request was refused since there was insufficient bandwidth. This
for example, be the result of a resource reservation failure. may, for example, be the result of a resource reservation failure.
10.1.4 45x Session Not Found 10.2.4 45x Session Not Found
10.1.5 45x Method Not Valid in This State The RTSP session identifier is invalid or has timed out.
10.1.6 45x Header Field Not Valid for Resource 10.2.5 45x Method Not Valid in This State
The server could not act on a required request header. For example, if PLAY The client or server cannot process this request in its current
contains the Range header field, but the stream does not allow seeking. state.
10.1.7 45x Invalid Range 10.2.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.2.7 45x Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the The Range value given is out of bounds, e.g., beyond the end of the
presentation. presentation.
10.1.8 45x Parameter Is Read-Only 10.2.8 45x Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can only be read, but not The parameter to be set by SET_PARAMETER can only be read, but not
modified. modified.
11 Header Field Definitions 11 Header Field Definitions
HTTP/1.1 or other, non-standard header fields not listed here currently HTTP/1.1 or other, non-standard header fields not listed here
have no well-defined meaning and SHOULD be ignored by the recipient. 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).
type HELLO GET SETUP PLAY RECORD PAUSE
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 Tables 3 summarizes the header fields used by RTSP. Type "R"
PAUSE designates request headers, type "r" response headers. Fields marked
CLOSE REDIRECT GET_PARAMETER SET_PARAMETER with "req." in the column labeled "support" MUST be implemented by
Accept the recipient for a particular method, while fields marked "opt." are
Accept-Encoding optional. Note that not all fields marked 'r' will be send in every
Accept-Language request of this type; merely, that client (for response headers) and
Authorization o o o o server (for request headers) MUST implement them. The last column
Bandwidth lists the method for which this header field is meaningful; the
Blocksize designation "entity" refers to all methods that return a message
Conference body. Within this specification, DESCRIBE and GET_PARAMETER fall
Connection x x x x into this class.
Content-Encoding x x x x
Content-Length x x x x
Content-Type x x x x
Date o o o o
If-Modified-Since
Last-Modified
Public o o o o
Range
Referer o o o o
Retry-After o o o o
Session x x x x
Server o o o o
Speed
Transport
User-Agent o o o o
Via o o o o
WWW-Authenticate o o o o
Table 5: Overview of RTSP header fields for PAUSE, CLOSE, GET_PARAMETER and If the field content does not apply to the particular resource, the
SET_PARAMETER server MUST return status 45x (Header Field Not Valid for Resource).
11.1 Accept 11.1 Accept
The Accept request-header field can be used to specify certain session The Accept request-header field can be used to specify certain
description content types which are acceptable for the response. presentation description content types which are acceptable for the
response.
The ``level'' parameter for session descriptions is properly The "level" parameter for presentation descriptions is
defined as part of the MIME type registration, not here. properly defined as part of the MIME type registration, not
here.
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: Example of use:
Accept: application/sdf, application/sdp;level=2 Accept: application/rtsl, application/sdp;level=2
Header type support methods
_________________________________________________________________
Accept R opt. entity
Accept-Encoding R opt. entity
Accept-Language R opt. all
Authorization R opt. all
Bandwidth R opt. SETUP
Blocksize R opt. all but OPTIONS, TEARDOWN
Cache-Control Rr opt. SETUP
Conference R opt. SETUP
Connection Rr req. all
Content-Encoding R req. SET_PARAMETER
Content-Encoding r req. DESCRIBE
Content-Length R req. SET_PARAMETER
Content-Length r req. entity
Content-Type R req. SET_PARAMETER
Content-Type r req. entity
Date Rr opt. all
Expires r opt. DESCRIBE
If-Modified-Since R opt. DESCRIBE, SETUP
Last-Modified r opt. entity
Public r opt. all
Range R opt. PLAY, PAUSE, RECORD
Range r opt. PLAY, PAUSE, RECORD
Referer R opt. all
Require R req. all
Retry-After r opt. all
Scale Rr opt. PLAY, RECORD
Session Rr req. all but SETUP, OPTIONS
Server r opt. all
Speed Rr opt. PLAY
Transport Rr req. SETUP
Transport-Require R xeq. all
User-Agent R opt. all
Via Rr opt. all
WWW-Authenticate r opt. all
Table 3: Overview of RTSP header fields
11.2 Accept-Encoding 11.2 Accept-Encoding
See [H14.3] See [H14.3]
11.3 Accept-Language 11.3 Accept-Language
See [H14.4]. Note that the language specified applies to the session See [H14.4]. Note that the language specified applies to the
description, not the media content. presentation description and any reason phrases, not the media
content.
11.4 Allow 11.4 Allow
The Allow response header field lists the methods supported by the resource The Allow response header field lists the methods supported by the
identified by the request-URI. The purpose of this field is to strictly resource identified by the request-URI. The purpose of this field is
inform the recipient of valid methods associated with the resource. An to strictly inform the recipient of valid methods associated with the
Allow header field must be present in a 405 (Method not allowed) response. resource. An Allow header field must be present in a 405 (Method not
allowed) response.
Example of use: Example of use:
Allow: SETUP, PLAY, RECORD, SET_PARAMETER Allow: SETUP, PLAY, RECORD, SET_PARAMETER
11.5 Authorization 11.5 Authorization
See [H14.8] See [H14.8]
11.6 Bandwidth 11.6 Bandwidth
The Bandwidth request header field describes the estimated bandwidth The Bandwidth request header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured in available to the client, expressed as a positive integer and measured
bits per second. in bits per second.
Bandwidth = "Bandwidth" ":" 1*DIGIT Bandwidth = "Bandwidth" ":" 1*DIGIT
Example: Example:
Bandwidth: 4000 Bandwidth: 4000
11.7 Blocksize 11.7 Blocksize
This request header field is sent from the client to the media server This request header field is sent from the client to the media server
asking the server for a particular media packet size. This packet size does asking the server for a particular media packet size. This packet
not include lower-layer headers such as IP, UDP, or RTP. The server is free size does not include lower-layer headers such as IP, UDP, or RTP.
to use a blocksize which is lower than the one requested. The server MAY The server is free to use a blocksize which is lower than the one
truncate this packet size to the closest multiple of the minimum requested. The server MAY truncate this packet size to the closest
media-specific block size or overrides it with the media specific size if multiple of the minimum media-specific block size or overrides it
necessary. The block size is a strictly positive decimal number and with the media specific size if necessary. The block size is a
measured in octets. The server only returns an error (416) if the value is strictly positive decimal number and measured in octets. The server
syntactically invalid. only returns an error (416) if the value is syntactically invalid.
11.8 Conference 11.8 Cache-Control
The Cache-Control general header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response chain.
Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache-
directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of
responses as for HTTP, but rather of the stream identified by the
SETUP request. Responses to RTSP requests are not cacheable.
[HS: Should there be an exception for DESCRIBE?]
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
"no-cache"
| "max-stale"
| "min-fresh"
| "only-if-cached"
| cache-extension
cache-response-directive =
"public"
| "private"
| "no-cache"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching even
by caches that have been configured to return stale responses to
client requests.
public: Indicates that the media stream is cachable by any cache.
private: Indicates that the media stream is intended for a single
user and MUST NOT be cached by a shared cache. A private (non-
shared) cache may cache the media stream.
no-transform: An intermediate cache (proxy) may find it useful to
convert the media type of certain stream. A proxy might, for
example, convert between video formats to save cache space or to
reduce the amount of traffic on a slow link. Serious operational
problems may occur, however, when these transformations have
been applied to streams intended for certain kinds of
applications. For example, applications for medical imaging,
scientific data analysis and those using end-to-end
authentication, all depend on receiving a stream that is bit for
bit identical to the original entity-body. Therefore, if a
response includes the no-transform directive, an intermediate
cache or proxy MUST NOT change the encoding of the stream.
Unlike HTTP, RTSP does not provide for partial transformation at
this point, e.g., allowing translation into a different
language.
only-if-cached: In some cases, such as times of extremely poor
network connectivity, a client may want a cache to return only
those media streams that it currently has stored, and not to
receive these from the origin server. To do this, the client may
include the only-if-cached directive in a request. If it
receives this directive, a cache SHOULD either respond using a
cached media stream that is consistent with the other
constraints of the request, or respond with a 504 (Gateway
Timeout) status. However, if a group of caches is being operated
as a unified system with good internal connectivity, such a
request MAY be forwarded within that group of caches.
max-stale: Indicates that the client is willing to accept a media
stream that has exceeded its expiration time. If max-stale is
assigned a value, then the client is willing to accept a
response that has exceeded its expiration time by no more than
the specified number of seconds. If no value is assigned to
max-stale, then the client is willing to accept a stale response
of any age.
min-fresh: Indicates that the client is willing to accept a media
stream whose freshness lifetime is no less than its current age
plus the specified time in seconds. That is, the client wants a
response that will still be fresh for at least the specified
number of seconds.
must-revalidate: When the must-revalidate directive is present in a
SETUP response received by a cache, that cache MUST NOT use the
entry after it becomes stale to respond to a subsequent request
without first revalidating it with the origin server. (I.e., the
cache must do an end-to-end revalidation every time, if, based
solely on the origin server's Expires, the cached response is
stale.)
11.9 Conference
This request header field establishes a logical connection between a This request header field establishes a logical connection between a
conference, established using non-RTSP means, and an RTSP stream. conference, established using non-RTSP means, and an RTSP stream. The
conference-id must not be changed for the same RTSP session.
Conference = "Conference" ":" conference-id Conference = "Conference" ":" conference-id
Example: Example:
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu
11.9 Content-Encoding 11.10 Connection
See [H14.10].
11.11 Content-Encoding
See [H14.12] See [H14.12]
11.10 Content-Length 11.12 Content-Length
This field contains the length of the content of the method (i.e. after the This field contains the length of the content of the method (i.e.
double CRLF following the last header). Unlike HTTP, it MUST be included in after the double CRLF following the last header). Unlike HTTP, it
all messages that carry content beyond the header portion of the message. MUST be included in all messages that carry content beyond the header
It is interpreted according to [H14.14]. portion of the message. It is interpreted according to [H14.14].
11.11 Content-Type 11.13 Content-Type
See [H14.18]. Note that the content types suitable for RTSP are likely to See [H14.18]. Note that the content types suitable for RTSP are
be restricted in practice to session descriptions and parameter-value likely to be restricted in practice to presentation descriptions and
types. parameter-value types.
11.12 Date 11.14 Date
See [H14.19]. See [H14.19].
11.13 If-Modified-Since 11.15 Expires
See [H14.24]. If the request URL refers to a presentation rather than a The Expires entity-header field gives the date/time after which the
track, the server is to return the presentation if any of the track has media-stream should be considered stale. A stale cache entry may not
been modified since the time stated in the header field. normally be returned by a cache (either a proxy cache or an user
agent cache) unless it is first validated with the origin server (or
with an intermediate cache that has a fresh copy of the entity). See
section 13.2 for further discussion of the expiration model.
11.14 Last-modified The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.
The Last-Modified entity-header field indicates the date and time at which The format is an absolute date and time as defined by HTTP-date in
the origin server believes the variant was last modified. See [H14.29]. If [H3.3]; it MUST be in RFC1123-date format:
the request URI refers to an aggregate, the field indicates the last
modification time across all leave nodes of that aggregate.
11.15 Location Expires = "Expires" ":" HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value.
To mark a response as "never expires," an origin server should use an
Expires date approximately one year from the time the response is
sent. RTSP/1.0 servers should not send Expires dates more than one
year in the future.
The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cachable, unless
indicated otherwise by a Cache-Control header field (Section 11.8.
11.16 If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional: if the requested variant
has not been modified since the time specified in this field, a
description will not be returned from the server ( DESCRIBE) or a
stream will not be setup ( SETUP); instead, a 304 (not modified)
response will be returned without any message-body.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
11.17 Last-modified
The Last-Modified entity-header field indicates the date and time at
which 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 modification time across all leave nodes of that
aggregate.
11.18 Location
See [H14.30]. See [H14.30].
11.16 Range 11.19 Nack-Transport-Require
Negative acknowledgement of features not supported by the server. If
there 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).
HS: Same caveat as for Require applies.
11.20 Range
This request header field specifies a range of time. The range can be This request header field specifies a range of time. The range can be
specified in a number of units. This specification defines the smpte (see specified in a number of units. This specification defines the smpte
Section 3.4) and clock (see Section 3.5) range units. Within RTSP, byte (see Section 3.4) and clock (see Section 3.6) range units. Within
ranges [H14.36.1] are not meaningful and MUST NOT be used. RTSP, byte ranges [H14.36.1] are not meaningful and MUST NOT be used.
The header may also contain a time parameter in UTC, specifying the
time at which the operation is to be made effective.
Range = "Range" ":" 1#ranges-specifier Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = utc-range | smpte-range ranges-specifier = npt-range | utc-range | smpte-range
Example: Example:
Range: clock=19960213T143205Z- Range: clock=19960213T143205Z-;Time=19970123T143720Z
11.17 Require The notation is similar to that used for the HTTP/1.1
header. It allows to select a clip from the media object,
to play from a given point to the end and from the current
location to a given point.
The Require header is used by clients to query the server about features 11.21 Require
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.
HS: Naming of features - yet another name space. I believe this The Require header is used by clients to query the server about
header field to be redundant. PEP should be used instead. 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.
HS: Naming of features -- yet another name space. I believe
this header field to be redundant. PEP should be used
instead.
For example For example
C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302
Require: funky-feature Require: funky-feature
Funky-Parameter: funkystuff Funky-Parameter: funkystuff
S->C: RTSP/1.0 200 506 Option not supported S->C: RTSP/1.0 200 506 Option not supported
Unsupported: funky-feature Unsupported: funky-feature
skipping to change at line 1838 skipping to change at page 43, line 4
C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302
Require: funky-feature Require: funky-feature
Funky-Parameter: funkystuff Funky-Parameter: funkystuff
S->C: RTSP/1.0 200 506 Option not supported S->C: RTSP/1.0 200 506 Option not supported
Unsupported: funky-feature Unsupported: funky-feature
C->S: SETUP /foo/bar/baz.rm RTSP/1.0 303 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 303
S->C: RTSP/1.0 200 303 OK S->C: RTSP/1.0 200 303 OK
This is to make sure that the client-server interaction will proceed 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 optimally when all options are understood by both sides, and only
if options aren't understood (as in the case above). For a well-matched slow down if options aren't understood (as in the case above). For a
client-server pair, the interaction proceeds quickly, saving a round-trip well-matched client-server pair, the interaction proceeds quickly,
often required by negotiation mechanisms. In addition, it also removes saving a round-trip often required by negotiation mechanisms. In
state ambiguity when the client requires features that the server doesn't addition, it also removes state ambiguity when the client requires
understand. features that the server doesn't understand.
11.18 Unsupported 11.22 Retry-After
See Section 11.17 for a usage example. See [H14.38].
HS: same caveat as for Require applies. 11.23 Scale
11.19 Nack-Transport-Require A scale value of 1 indicates normal play or record at the normal
forward viewing rate. If not 1, the value corresponds to the rate
with respect to normal viewing rate. For example, a ratio of 2
indicates twice the normal viewing rate ("fast forward") and a ratio
of 0.5 indicates half the normal viewing rate. In other words, a
ratio of 2 has normal play time increase at twice the wallclock rate.
For every second of elapsed (wallclock) time, 2 seconds of content
will be delivered. A negative value indicates reverse direction.
Negative acknowledgement of features not supported by the server. If there Unless requested otherwise by the Speed parameter, the data rate
is a proxy on the path between the client and the server, the proxy MUST SHOULD not be changed. Implementation of scale changes depends on the
insert a message reply with an error message 506 (Feature not supported). server and media type. For video, a server may, for example, deliver
only key frames or selected key frames. For audio, it may time-scale
the audio while preserving pitch or, less desirably, deliver
fragments of audio.
HS: Same caveat as for Require applies. The server should try to approximate the viewing rate, but may
restrict the range of scale values that it supports. The response
MUST contain the actual scale value chosen by the server.
11.20 Transport-Require If the request contains a Range parameter, the new scale value will
take effect at that time.
The Transport-Require header is used to indicate proxy-sensitive features Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
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.
See Section 11.17 for more details on the mechanics of this message and a Example of playing in reverse at 3.5 times normal rate:
usage example.
HS: Same caveat as for Require applies. Scale: -3.5
11.21 Retry-After 11.24 Speed
See [H14.38]. 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.
11.22 Speed The parameter value is expressed as a decimal ratio, e.g., a value of
2.0 indicates that data is to be delivered twice as fast as normal. A
speed of zero is invalid. A negative value indicates that the stream
is to be played back in reverse direction.
This request header fields parameter requests the server to deliver data to HS: With 'Scale', the negative value is redundant and
the client at a particular speed, contingent on the server's ability and should probably be removed since it only leads to possible
desire to serve the media stream at the given speed. Implementation by the conflicts when Scale is positive and Speed negative.
server is OPTIONAL. The default is the bit rate of the stream.
The parameter value is expressed as a decimal ratio, e.g., a value of 2.0 If the request contains a Range parameter, the new speed value will
indicates that data is to be delivered twice as fast as normal. A speed of take effect at that time.
zero is invalid. A negative value indicates that the stream is to be played
back in reverse direction.
speed = "Speed" ":" ["-"]1*DIGIT [ "." *DIGIT ] Speed = "Speed" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
Example: Example:
Speed: 2.5 Speed: 2.5
11.23 Server 11.25 Server
See [H14.39] See [H14.39]
11.24 Session 11.26 Session
This request and response header field identifies a session, started by the This request and response header field identifies an RTSP session,
media server in a SETUP or PLAY response and concluded by CLOSE on the started by the media server in a SETUP response and concluded by
session URL (presentation). The session identifier is chosen by the media TEARDOWN on the presentation URL. The session identifier is chosen by
server and has the same syntax as a conference identifier. Once a client the media server and has the same syntax as a conference identifier.
receives a Session identifier, it MUST return it for any request related to Once a client receives a Session identifier, it MUST return it for
that session. any request related to that session.
HS: This may be redundant with the standards-track HTTP state HS: This may be redundant with the standards-track HTTP
maintenance mechanism [1]. The equivalent way of doing this would state maintenance mechanism [2]. The equivalent way of
be for the server to send Set-Cookie: Session="123"; Version=1; doing this would be for the server to send Set-Cookie:
Path = "/twister" and for the client to return later Cookie: Session="123"; Version=1; Path = "/twister" and for the
Session = "123"; $Version=1; $Path = "/twister". In the response client to return later Cookie: Session = "123"; $Version=1;
to the CLOSE message, the server would simply send Set-Cookie: $Path = "/twister" response to the TEARDOWN message, the
Session="123"; Version=1; Max-Age=0 to get rid of the cookie on server would simply send Set-Cookie: Session="123";
the client side. Cookies also have a time-out, so that a server Version=1; Max-Age=0 to get rid of the cookie on the client
may limit the lifetime of a session at will. Unlike a web side. Cookies also have a time-out, so that a server may
browser, a client would not store these states on disk. limit the lifetime of a session at will. Unlike a web
browser, a client would not store these states on disk. To
avoid privacy issues, we should prohibit the Host
parameter.
11.25 Transport 11.27 Transport
This request header indicates which transport protocol is to be used and This request header indicates which transport protocol is to be used
configures its parameters such as multicast, compression, multicast and configures its parameters such as multicast, compression,
time-to-live and destination port for a single stream. It sets those values multicast time-to-live and destination port for a single stream. It
not already determined by a session description. In some cases, the session sets those values not already determined by a presentation
description contains all necessary information. In those cases, a Transport description. In some cases, the presentation description contains all
header field (and the SETUP request containing it) are not needed. necessary information. In those cases, a Transport header field
(and the SETUP request containing it) are not needed.
'Interleaved' implies mixing the media stream with the control stream, in in whatever protocol is being used by the control stream. Currently,
whatever protocol is being used by the control stream. Currently, the the next-layer protocols RTP is defined. Parameters may be added to
next-layer protocols RTP is defined. Parameters may be added to each each protocol, separated by a semicolon. For RTP, the boolean
protocol, separated by a semicolon. For RTP, the boolean parameter parameter compressed is defined, indicating compressed RTP according
compressed is defined, indicating compressed RTP according to RFC XXXX. For to RFC XXXX. For multicast UDP, the integer parameter ttl defines
multicast UDP, the integer parameter ttl defines the time-to-live value to the time-to-live value to be used. The client may specify the
be used. For UDP and TCP, the parameter port defines the port data is to be multicast address with the multicast parameter. A server SHOULD
sent to. authenticate the client before allowing the client to direct a media
stream to a multicast address not chosen by the server to avoid
becoming the unwitting perpetrator of a denial-of-service attack. For
UDP and TCP, the parameter port defines the port data is to be sent
to.
The SSRC parameter indicates the RTP SSRC value that should be (request)i The SSRC parameter indicates the RTP SSRC value that should be
or will be (response) used by the media server. This parameter is only (request) or will be (response) used by the media server. This
valid for unicast transmission. It identifies the synchronization source to parameter is only valid for unicast transmission. It identifies the
be associated with the media stream. synchronization source to be associated with the media stream.
The Transport header MAY also be used to change certain transport The Transport header MAY also be used to change certain transport
parameters. A server MAY refuse to change parameters of an existing stream. parameters. A server MAY refuse to change parameters of an existing
stream.
The server MAY return a Transport response header in the response to The server MAY return a Transport response header in the response to
indicate the values actually chosen. indicate the values actually chosen.
A Transport request header field may contain a list of transport options A Transport request header field may contain a list of transport
acceptable to the client. In that case, the server MUST return a single options acceptable to the client. In that case, the server MUST
option which was actually chosen. The Transport header field makes sense return a single option which was actually chosen. The Transport
only for an individual media stream, not a session. header field makes sense only for an individual media stream, not a
presentation.
Transport = "Transport" ":" Transport = "Transport" ":"
1#transport-protocol/upper-layer *parameter 1#transport-protocol/upper-layer *parameter
transport-protocol = "UDP" | "TCP" transport-protocol = "UDP" | "TCP"
upper-layer = "RTP" upper-layer = "RTP"
parameters = ";" "multicast" | parameters = ";" "multicast" [ "=" mca ]
";" "compressed" | | ";" "compressed"
";" "interleaved" | | ";" "interleaved"
";" "ttl" "=" ttl | | ";" "ttl" "=" ttl
";" "port" "=" port | | ";" "port" "=" port
";" "ssrc" "=" ssrc | ";" "ssrc" "=" ssrc
ttl = 1*3(DIGIT) ttl = 1*3(DIGIT)
port = 1*5(DIGIT) port = 1*5(DIGIT)
ssrc = 8*8(HEX) ssrc = 8*8(HEX)
mca = host
Example: Example:
Transport: udp/rtp;compressed;ttl=127;port=3456 Transport: udp/rtp;compressed;ttl=127;port=3456
11.26 User-Agent 11.28 Transport-Require
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.
See Section 11.21 for more details on the mechanics of this message
and a usage example.
HS: Same caveat as for Require applies.
11.29 Unsupported
See Section 11.21 for a usage example.
HS: same caveat as for Require applies.
11.30 User-Agent
See [H14.42] See [H14.42]
11.27 Via 11.31 Via
See [H14.44]. See [H14.44].
11.28 WWW-Authenticate 11.32 WWW-Authenticate
See [H14.46]. See [H14.46].
12 Caching 12 Caching
In HTTP, response-request pairs are cached. RTSP differs significantly in In HTTP, response-request pairs are cached. RTSP differs
that respect. Typically, responses are not cachable (except maybe for the significantly in that respect. Responses are not cachable, with the
GET response), rather it is desirable for the media data (that is typically exception of the stream description returned by DESCRIBE. (Since the
delivered outside of RTSP) to be cached. Since the responses for anything responses for anything but DESCRIBE and GET_PARAMETER do not return
but GET and GET_PARAMETER do not return any data, caching is not an issue any data, caching is not really an issue for these requests.)
for these requests. However, it is desirable for the continuous media data, typically
delivered out-of-band with respect to RTSP, to be cached.
HS: A proxy cache for RTSP would look not much different from an HTTP On receiving a SETUP or PLAY request, the proxy would ascertain as
cache. To the client, the proxy cache would appear like a regular media to whether it has an up-to-date copy of the continuous media content.
server, to the media server like a client. Just like an HTTP cache has to If not, it would modify the SETUP transport parameters as
store the content type, content language, etc. for the objects it caches, a appropriate and forward the request to the origin server. Subsequent
media cache has to store the session description. Typically, a cache would control commands such as PLAY or PAUSE would pass the proxy
eliminate all transport-references (that is, multicast information) from unmodified. The proxy would then pass the continuous media data to
the session description, since these are independent of the data delivery the client, while possibly making a local copy for later re-use. The
from the cache to the client. Information on the encodings remains the exact behavior allowed to the cache is given by the cache-response
same. If the cache is able to translate the cached media data, it would directives described in Section 11.8. A cache MUST answer any
create a new session description with all the encoding possibilities it can DESCRIBE requests if it is currently serving the stream to the
offer. requestor, as it is possible that low-level details of the stream
description may have changed on the origin-server.
Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
through" variety. Rather than retrieving the whole resource from the
origin server, the cache simply copies the streaming data as it
passes by on its way to the client, thus, it does not introduce
additional latency.
To the client, an RTSP proxy cache would appear like a regular media
server, to the media origin 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 presentation
description. Typically, a cache would eliminate all transport-
references (that is, multicast information) from the presentation
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 presentation description with all the encoding
possibilities it can offer.
13 Examples 13 Examples
To emphasize that RTSP is independent of the session description format, The following examples reference stream description formats that are
the following examples use a fictional session description language which not finalized, such as RTSL and SDP. Please do not use these examples
is chosen to be sufficiently self-explanatory. as a reference for those formats.
13.1 Media on Demand (Unicast) 13.1 Media on Demand (Unicast)
Client C requests a movie from media servers A ( audio.content.com) and V Client C requests a movie from media servers A ( audio.example.com )
(video.content.com). The media description is stored on a web server W. and V ( video.example.com ). The media description is stored on a web
This, however, is transparent to the client. The client is only interested server W. The media description contains descriptions of the
in the last part of the movie. The server requires authentication for this presentation and all its streams, including the codecs that are
movie. The audio track can be dynamically switched between between two sets available, dynamic RTP payload types, the protocol stack and content
of encodings. The URL with scheme rtpsu indicates the media servers want to information such as language or copyright restrictions. It may also
use UDP for exchanging RTSP messages. give an indication about the time line of the movie.
C->W: GET /twister HTTP/1.1 In our example, the client is only interested in the last part of the
Host: www.content.com movie. The server requires authentication for this movie. The audio
Accept: application/sdf; application/sdp 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.
C->W: DESCRIBE /twister HTTP/1.1
Host: www.example.com
Accept: application/rtsl; application/sdp
W->C: 200 OK W->C: 200 OK
Content-Type: application/sdf Content-Type: application/rtsl
(session
(all
(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)
)
)
)
C->A: SETUP rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 1 <session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src="rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtspu://video.example.com/twister/video">
</group>
</session>
C->A: SETUP rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 1
Transport: rtp/udp;compression;port=3056 Transport: rtp/udp;compression;port=3056
A->C: RTSP/1.0 200 1 OK A->C: RTSP/1.0 200 1 OK
Session: 1234 Session: 1234
C->V: SETUP rtsp://video.content.com/twister/video RTSP/1.0 1 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 1
Transport: rtp/udp;compression;port=3058 Transport: rtp/udp;compression;port=3058
V->C: RTSP/1.0 200 1 OK V->C: RTSP/1.0 200 1 OK
Session: 1235 Session: 1235
C->V: PLAY rtsp://video.content.com/twister/video RTSP/1.0 2 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 2
Session: 1235 Session: 1235
Range: smpte 0:10:00- Range: smpte=0:10:00-
V->C: RTSP/1.0 200 2 OK V->C: RTSP/1.0 200 2 OK
C->A: PLAY rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 2 C->A: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 2
Session: 1234 Session: 1234
Range: smpte 0:10:00- Range: smpte=0:10:00-
A->C: 200 2 OK A->C: 200 2 OK
C->A: CLOSE rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 3 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 3
Session: 1234 Session: 1234
A->C: 200 3 OK A->C: 200 3 OK
C->V: CLOSE rtsp://video.content.com/twister/video RTSP/1.0 3 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 3
Session: 1235 Session: 1235
V->C: 200 3 OK V->C: 200 3 OK
Even though the audio and video track are on two different servers, may Even though the audio and video track are on two different servers,
start at slightly different times and may drift with respect to each other, may start at slightly different times and may drift with respect to
the client can synchronize the two using standard RTP methods, in each other, the client can synchronize the two using standard RTP
particular the time scale contained in the RTCP sender reports. methods, in particular the time scale contained in the RTCP sender
reports.
13.2 Live Media Event Using Multicast 13.2 Live Media Presentation Using Multicast
The media server M chooses the multicast address and port. Here, we assume The media server M chooses the multicast address and port. Here, we
that the web server only contains a pointer to the full description, while assume that the web server only contains a pointer to the full
the media server M maintains the full description. During the session, a description, while the media server M maintains the full description.
new subtitling stream is added. During the RTSP session, a new subtitling stream is added.
C->W: GET /concert HTTP/1.1 C->W: GET /concert HTTP/1.1
Host: www.content.com Host: www.example.com
W->C: HTTP/1.1 200 OK W->C: HTTP/1.1 200 OK
Content-Type: application/sdf Content-Type: application/rtsl
(session <session>
(id rtsp://live.content.com/concert) <track id=17 src="rtsp://live.example.com/concert/audio">
) </session>
C->M: GET rtsp://live.content.com/concert RTSP/1.0 1 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 1
M->C: RTSP/1.0 200 1 OK M->C: RTSP/1.0 200 1 OK
Content-Type: application/sdf Content-Type: application/rtsl
(session (all <track id=17 type=audio address=224.2.0.1 port=3456 ttl=16>
(media (t audio) (id music) (a IP4 224.2.0.1) (p 3456))
))
C->M: PLAY rtsp://live.content.com/concert/music RTSP/1.0 2 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 2
Transport: multicast=224.2.0.1; port=3456; ttl=16
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3
Range: smpte 1:12:0 Range: smpte 1:12:0
M->C: RTSP/1.0 405 2 No positioning possible M->C: RTSP/1.0 405 3 No positioning possible
M->C: SESSION concert RTSP/1.0 M->C: DESCRIBE concert RTSP/1.0
Content-Type: application/sdf Content-Type: application/rtsl
(session (all <session>
(media (t audio) (id music)) <track id=17
(media (t text) (id lyrics)) media=audio/g.728 src="rtsp://live.example.com/concert/audio">
)) <track id=18
media=text/html src="rtsp://live.example.com/concert/lyrics">
</session>
C->M: PLAY rtsp://live.content.com/concert/lyrics RTSP/1.0 C->M: PLAY rtsp://live.example.com/concert/lyrics RTSP/1.0
Since the session description already contains the necessary address The attempt to position the stream fails since this is a live
information, the client does not set the transport address. The attempt to presentation.
position the stream fails since this is a live event.
13.3 Playing media into an existing session 13.3 Playing media into an existing session
A conference participant C wants to have the media server M play back
A conference participant C wants to have the media server M play back a a demo tape into an existing conference. When retrieving the
demo tape into an existing conference. When retrieving the session presentation description, C indicates to the media server that the
description, C indicates to the media server that the network addresses and network addresses and encryption keys are already given by the
encryption keys are already given by the conference, so they should not be conference, so they should not be chosen by the server. The example
chosen by the server. The example omits the simple ACK responses. omits the simple ACK responses.
C->M: GET /demo HTTP/1.1 C->M: GET /demo HTTP/1.1
Host: www.content.com Host: www.example.com
Accept: application/sdf, application/sdp Accept: application/rtsl, application/sdp
M->C: HTTP/1.1 200 1 OK M->C: HTTP/1.1 200 1 OK
Content-type: application/sdf Content-type: application/rtsl
(session <session>
(id 548) <track type=audio/g.723.1
(media (t audio) (id sound) src="rtsp://server.example.com/demo/548/sound">
) </session>
C->M: SETUP rtsp://server.content.com/demo/548/sound RTSP/1.0 2 C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 2
Conference: 218kadjk Conference: 218kadjk
13.4 Recording 13.4 Recording
Conference participant C asks the media server M to record a session. If The conference participant C asks the media server M to record a
the session description contains any alternatives, the server records them meeting. If the presentation description contains any alternatives,
all. the server records them all.
C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 89 C->M: DESCRIBE rtsp://server.example.com/meeting RTSP/1.0 89
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
s=Mbone Audio s=Mbone Audio
i=Discussion of Mbone Engineering Issues i=Discussion of Mbone Engineering Issues
M->C: 415 89 Unsupported Media Type M->C: 415 89 Unsupported Media Type
Accept: application/sdf Accept: application/rtsl
C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 90 C->M: DESCRIBE rtsp://server.example.com/meeting RTSP/1.0 90
Content-Type: application/sdf Content-Type: application/rtsl
M->C: 200 90 OK M->C: 200 90 OK
C->M: RECORD rtsp://server.content.com/meeting RTSP/1.0 91 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 91
Range: clock 19961110T1925-19961110T2015 Range: clock 19961110T1925-19961110T2015
14 Syntax 14 Syntax
The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used The RTSP syntax is described in an augmented Backus-Naur form (BNF)
in RFC 2068 (HTTP/1.1). as used in RFC 2068 (HTTP/1.1).
14.1 Base Syntax 14.1 Base Syntax
OCTET = <any 8-bit sequence of data> OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)> CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z"> LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9"> DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)> (octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)> CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)> LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)> SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)> HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)> <"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP | HT ) LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs> TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@" tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <"> | "," | ";" | ":" | "
| "/" | "[" | "]" | "?" | "=" | "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT | "{" | "}" | SP | HT
token = 1*<any CHAR except CTLs or tspecials> token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> ) quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">> qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR quoted-pair = "
message-header = field-name ":" [ field-value ] CRLF message-header = field-name ":" [ field-value ] CRLF
field-name = token field-name = token
field-value = *( field-content | LWS ) field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and consisting field-content = <the OCTETs making up the field-value and consisting
of either *TEXT or combinations of token, tspecials, of either *TEXT or combinations of token, tspecials,
and quoted-string> and quoted-string>
14.2 Internet Media Type Syntax 15 Security Considerations
The protocol offers the opportunity for a remote-control denial-of-
media-type = type "/" subtype *( ";" parameter ) service attack. The attacker, using a forged source IP address, can
type = token ask for a stream to be played back to that forged IP address.
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
14.3 Universal Resource Identifier Syntax
uri = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net-path | abs-path | rel-path
net-path = "//" net-loc [ abs-path ]
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>
14.4 RTSP-specific syntax
setup-response = response-line
date-type-header
*( nack-require-header
| nack-require-transport-header )
CRLF
redirect-response = response-line
date-type-header
session-response = response-line
date-type-header
play-response = response-line
date-type-header
pause-response = response-line
date-type-header
message-body = *OCTET
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
auth-scheme = token Since there is no relation between a transport layer connection and
ip-address = <IP address in dotted-decimal form per RFC 1123> an RTSP session, it is possible for a malicious client to issue
port-number = 1*DIGIT requests with random session identifiers which would affect
blocksize-value = 1*DIGIT unsuspecting clients. This does not require spoofing of network
credentials = auth-scheme ":" #parameter packet addresses. The server SHOULD use a large random session
rfc1123-date = wkday "," SP date SP time SP "GMT" identifier to make this attack more difficult.
date = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 12 Dec 1998)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun"
| "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
15 Experimental Both problems can be be prevented by appropriate authentication.
This section gathers parts of the protocol which are less well understood In addition, the security considerations outlined in [H15] apply.
and require extensive further discussion.
15.1 Header Field Definitions A RTSP Protocol State Machines
The following additional HTTP headers may be useful for RTSP: The RTSP client and server state machines describe the behavior of
the protocol from RTSP session initialization through RTSP session
termination.
* Accept-Language [TBD: should we allow for the trivial case of a server that only
* Cache-Control implements the PLAY message, with no control.]
* From
* Max-Forwards
* Proxy-Authenticate
* Proxy-Authorization
* Public
* Referer
15.1.1 Address State is defined on a per object basis. An object is uniquely
identified by the stream URL and the RTSP session identifier. (A
server may choose to generate dynamic presentation descriptions where
the URL is unique for a particular RTSP session and thus may not need
an explicit RTSP session identifier in the request header.) Any
request/reply using URLs denoting an RTSP session comprised of
multiple streams will have an effect on the individual states of all
the substreams. For example, if the stream /movie contains two
substreams /movie/audio and /movie/video, then the following command:
Designates address to send multimedia data to. PLAY /movie RTSP/1.0 559
Session: 12345
It appears that in almost all cases, the destination address is will have an effect on the states of movie/audio and movie/video.
the same one where the RTSP command originates from. If TCP is
used for control, this also eliminates the possibilities of
pointing a data stream at an unsuspecting third party.
16 Security Considerations This example does not imply a standard way to represent
substreams in URLs or a relation to the filesystem. See
Section 3.2.
The protocol offers the opportunity for a remote-control denial-of-service The requests OPTIONS, DESCRIBE, GET_PARAMETER, SET_PARAMETER do
attack. The attacker, using a forged source IP address, can ask for a not have any effect on client or server state and are therefore not
stream to be played back to that forged IP address. listed in the state tables.
Since there is no relation between a transport layer connection and an RTSP Client and servers MUST disregard messages with a sequence number
session, it is possible for a malicious client to issue requests with less than the last one. If no message has been received, the first
random session identifiers which would affect unsuspecting clients. This received message's sequence number will be the starting point.
does not require spoofing of network packet addresses. The server SHOULD
use a large random session identifier to make this attack more difficult.
Both problems can be be prevented by appropriate authentication. A.1 Client State Machine
In addition, the security considerations outlined in [H15] apply. The client can assume the following states:
A State Machines Init: SETUP has been sent, waiting for reply.
The RTSP client and server state machines describe the behavior of the Ready: SETUP reply received OR after playing, PAUSE reply received.
protocol from session initialization through session termination.
[TBD: should we allow for the trivial case of a server that only implements Playing: PLAY reply received
the PLAY message, with no control.]
State is defined on a per object basis. An object is uniquely identified by Recording: RECORD reply received
the stream URL AND the session identifier. (A server may choose to generate
dynamic session descriptions where the URL is unique for a particular
session and thus may not need an explicit session identifier in the request
header.) Any request/reply using URLs denoting a session comprised of
multiple streams will have an effect on the individual states of all the
substreams. For example:
Assuming the stream /coolmovie contains two substreams /coolmovie/audio and The client changes state on receipt of replies to requests. If no
/coolmovie/video, then the following command: explicit SETUP is required for the object (for example, it is
available via a multicast group), state begins at READY. In this
case, there are only two states, READY and PLAYING.
PLAY /coolmovie RTSP/1.0 559 The "next state" column indicates the state assumed after receiving a
Session: 12345 success response (2xx). If a request yields a status code greater or
equal to 300, the client state becomes Init, with the exception of
status codes 401 (Unauthorized) and 402 (Payment Required), where the
state remains unchanged and the request should be re-issued with the
appropriate authentication or payment information. Messages not
listed for each state MUST NOT be issued by the client in that state,
with the exception of messages not affecting state, as listed above.
Receiving a REDIRECT from the server is equivalent to receiving a 3xx
redirect status from the server.
will have an effect on the states of coolmovie/audio and coolmovie/video. HS: Depends on allowing PLAY without SETUP. After 4xx or
5xx error, do we go back to Init?
This example does not imply a standard way to represent state message next state
substreams in URLs or a relation to the filesystem. See Section _______________________________________________________
3.2. Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
RECORD Recording
TEARDOWN Init
Playing PAUSE Ready
TEARDOWN Init
PLAY Playing
RECORD Recording
SETUP Playing (changed transport)
Recording PAUSE Init
TEARDOWN Init
PLAY Playing
RECORD Recording
SETUP Recording (changed transport)
A.1 Client State Machine A.2 Server State Machine
A.1.1 Client States The server can assume the following states:
These are defined as follows: Init: The initial state, no valid SETUP received.
NULL: Ready: Last SETUP received was successful, reply sent or after
No state playing, last PAUSE received was successful, reply sent.
INIT:
GET or SETUP has been sent, waiting for reply.
READY:
SETUP reply received OR after playing, PAUSE reply received.
PLAYING:
PLAY reply received
A.1.2 Notes Playing: Last PLAY received was successful, reply sent. Data is
being sent.
In general, the client transitions state on receipt of specific replies. Recording: The server is recording media data.
After a period of inactivity, state transitions back to NULL. "Inactivity"
is defined as one of the following:
* For state PLAYING, no data being received and/or lack of wellness The server changes state on receiving requests. If the server is in
information from the server. state Playing or Recording and in unicast mode, it MAY revert to Init
* The client stays in any other state continuously for more than a and tear down the RTSP session if it has not received "wellness"
specific interval. The choice of this interval is left to the information, such as RTCP reports, from the client for a defined
implementation. interval, with a default of one minute. If the server is in state
Ready, it MAY revert to Init if it does not receive an RTSP request
for an interval of more than one minute.
If no explicit SETUP is required for the object (for example, it is The REDIRECT message, when sent, is effective immediately. If a
available via a multicast group) , state begins at READY. In this case, similar change of location occurs at a certain time in the future,
there are only two states, i.e READY and PLAYING. this is assumed to be indicated by the presentation description.
A client MUST disregard messages with a sequence number less than the last SETUP is valid in states Init and Ready only. An error message should
one . If no message has been received, the first received message's be returned in other cases. If no explicit SETUP is required for the
sequence number will be the starting point. object, state starts at READY, there are only two states READY and
PLAYING.
A.1.3 State Table state message next state
___________________________________
Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
SETUP Ready
TEARDOWN Ready
Playing PLAY Playing
PAUSE Ready
TEARDOWN Ready
RECORD Recording
SETUP Playing
Recording RECORD Recording
PAUSE Ready
TEARDOWN Ready
PLAY Playing
SETUP Recording
In the NEXT STATE column, + indicates that the message was successful, B Open Issues
-indicates that it was unsuccessful.
STATE MESSAGES NEXT STATE(+) NEXT STATE(-) o Define text/rtsp-parameter MIME type.
INIT GET REPLY INIT NULL o HS believes that RTSP should only control individual media
SETUP REPLY READY INIT objects rather than aggregates. This avoids disconnects between
REDIRECT NULL NULL presentation descriptions and streams and avoids having to deal
BYE NULL NULL separately with single-host and multi-host case. Cost: several
OTHER INIT INIT PLAY/PAUSE/RECORD in one packet, one for each stream.
READY PLAY REPLY PLAYING READY o Allow changing of transport for a stream that's playing? May
SETUP REPLY READY INIT not be a great idea since the same can be accomplished by tear
BYE NULL NULL down and re-setup.
OTHER READY READY
PLAYING PAUSE REPLY READY PLAYING o Allow fragment (#) identifiers for controlling substreams in
PLAY REPLY PLAYING CLOSED Quicktime, AVI and ASF files?
BYE NULL NULL
CLOSE REPLY NULL PLAYING
OTHER PLAYING PLAYING
This assumes that a PLAY during state PLAYING is an implicit PAUSE, PLAY. o How does the server get back to the client unless a persistent
connection is used? Probably cannot, in general.
HS: BYE should be replaced by CLOSE. o Cache and proxy behavior?
A.2 Server State Machine o Session: or Set-Cookie: ?
A.2.1 Server States o When do relative RTSP URLs make sense?
INIT: o Nack-require, etc. are dubious. This is getting awfully close
The initial state, no valid SETUP receieved. to the HTTP extension mechanisms [19] in complexity, but is
READY: different.
Last SETUP received was successful, reply sent or after playing, last
PAUSE received was successful, reply sent.
PLAYING: o Use HTTP absolute path + Host field or do the right thing and
Last PLAY received was successful, reply sent. Data actually being carry full URL, including host in request?
sent.
In general, server state transitions occur on receiving requests. On C Changes
receiving a BYE, state transitions back to INIT. After inactivity for a
period, state also transitions back to INIT. "Inactivity" is defined as:
* For states other than PLAYING, no messages for that object for a Since the February 1997 version, the following changes were made:
specific interval. The choice of interval is left to the
implementation.
* 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)
The REDIRECT message, when sent, is effective immediately. If a similar o Various editorial changes and clarifications.
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.
A server MUST disregard messages with a sequence number less than the last o Removed references to SDF and replaced by RTSL.
one. If no message has been received, the first received message's sequence
number will be the starting point.
SETUP is valid in states INIT and READY only. An error message should be o Added Scale general header.
returned in other cases. If no explicit SETUP is required for the object,
state starts at READY, ie. there are only two states READY and PLAYING.
A.2.2 State Table o Clarify behavior of PLAY.
In the NEXT STATE column, + indicates that the message was successful, o Rename GET to DESCRIBE.
-indicates that it was unsuccessful.
STATE MESSAGES NEXT STATE(+) NEXT STATE(-) o Removed SESSION since it is just DESCRIBE in the other
direction.
INIT GET INIT INIT o Rename CLOSE to TEARDOWN, in symmetry with SETUP.
SETUP READY INIT
BYE INIT INIT
OTHER - INIT
READY PLAY PLAYING READY o Terminology adjusted to "presentation" and "stream".
SETUP READY INIT
CLOSE INIT -
BYE INIT -
OTHER - READY
PLAYING PLAY PLAYING READY o Redundant syntax BNF in appendix removed since it just
PAUSE READY PLAYING duplicates HTTP spec.
CLOSE INIT PLAYING
BYE INIT -
OTHER - PLAYING
B Open Issues o Beginnings of cache control.
* Define text/rtsp-parameter MIME type. Changes are marked by changebars in the margins of the PostScript
* Lots of inconsistencies need to be fixed: naming of methods in state version.
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
re-setup.
* 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 D Author Addresses
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
skipping to change at line 2535 skipping to change at page 57, line 52
USA USA
electronic mail: anup@netscape.com electronic mail: anup@netscape.com
Robert Lanphier Robert Lanphier
Progressive Networks Progressive Networks
1111 Third Avenue Suite 2900 1111 Third Avenue Suite 2900
Seattle, WA 98101 Seattle, WA 98101
USA USA
electronic mail: robla@prognet.com electronic mail: robla@prognet.com
D Acknowledgements E Acknowledgements
This draft is based on the functionality of the RTSP draft. It also
This draft is based on the functionality of the RTSP draft. It also borrows borrows format and descriptions from HTTP/1.1.
format and descriptions from HTTP/1.1.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already mentioned, the participating in the MMUSIC-WG. In addition to those already
following individuals have contributed to this specification: mentioned, the following individuals have contributed to this
specification:
Rahul Agarwal Eduardo F. Llach Rahul Agarwal Eduardo F. Llach
Bruce Butterfield Rob McCool Bruce Butterfield Rob McCool
Martin Dunsmuir Sujal Patel Martin Dunsmuir Sujal Patel
Eric Fleischman
Mark Handley Igor Plotnikov Mark Handley Igor Plotnikov
Peter Haight Pinaki Shah Peter Haight Pinaki Shah
Brad Hefta-Gaub Jeff Smith Brad Hefta-Gaub Jeff Smith
John K. Ho Alexander Sokolsky John K. Ho Alexander Sokolsky
Ruth Lang Dale Stammen Ruth Lang Dale Stammen
Stephanie Leif John Francis Stracke Stephanie Leif John Francis Stracke
References F Bibliography
1 D. Kristol and L. Montulli, ``HTTP state management mechanism,'' RFC [1] H. Schulzrinne, "RTP profile for audio and video conferences with
2109, Internet Engineering Task Force, Feb. 1997. minimal control," RFC 1890, Internet Engineering Task Force, Jan.
1996.
2 F. Yergeau, G. Nicol, G. Adams, and M. Duerst, ``Internationalization [2] D. Kristol and L. Montulli, "HTTP state management mechanism,"
of the hypertext markup language,'' RFC 2070, Internet Engineering RFC 2109, Internet Engineering Task Force, Feb. 1997.
Task Force, Jan. 1997.
3 S. Bradner, ``Key words for use in RFCs to indicate requirement [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst,
levels,'' Internet Draft, Internet Engineering Task Force, Jan. 1997. "Internationalization of the hypertext markup language," RFC 2070,
Internet Engineering Task Force, Jan. 1997.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Internet Draft, Internet Engineering Task Force, Jan. 1997.
Work in progress. Work in progress.
4 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, [5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee,
``Hypertext transfer protocol - HTTP/1.1,'' RFC 2068, Internet "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet
Engineering Task Force, Jan. 1997. Engineering Task Force, Jan. 1997.
5 A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' Internet [6] M. Handley, "SDP: Session description protocol," Internet Draft,
Draft, Internet Engineering Task Force, Dec. 1996. Work in progress. Internet Engineering Task Force, Nov. 1996. Work in progress.
6 J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and E. L. [7] A. Freier, P. Karlton, and P. Kocher, "The TLS protocol,"
Stewart, ``An extension to HTTP: digest access authentication,'' RFC Internet Draft, Internet Engineering Task Force, Dec. 1996. Work in
2069, Internet Engineering Task Force, Jan. 1997. progress.
7 J. Postel, ``User datagram protocol,'' STD 6, RFC 768, Internet [8] 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.
[9] J. Postel, "User datagram protocol," STD 6, RFC 768, Internet
Engineering Task Force, Aug. 1980. Engineering Task Force, Aug. 1980.
8 R. Hinden and C. Partridge, ``Version 2 of the reliable data protocol [10] R. Hinden and C. Partridge, "Version 2 of the reliable data
(RDP),'' RFC 1151, Internet Engineering Task Force, Apr. 1990. protocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr.
1990.
9 J. Postel, ``Transmission control protocol,'' STD 7, RFC 793, [11] J. Postel, "Transmission control protocol," STD 7, RFC 793,
Internet Engineering Task Force, Sept. 1981. Internet Engineering Task Force, Sept. 1981.
10 M. Handley, H. Schulzrinne, and E. Schooler, ``SIP: Session [12] M. Handley, H. Schulzrinne, and E. Schooler, "SIP: Session
initiation protocol,'' Internet Draft, Internet Engineering Task initiation protocol," Internet Draft, Internet Engineering Task
Force, Dec. 1996. Work in progress. Force, Dec. 1996. Work in progress.
11 P. McMahon, ``GSS-API authentication method for SOCKS version 5,'' [13] P. McMahon, "GSS-API authentication method for SOCKS version 5,"
RFC 1961, Internet Engineering Task Force, June 1996. RFC 1961, Internet Engineering Task Force, June 1996.
12 D. Crocker, ``Augmented BNF for syntax specifications: ABNF,'' [14] D. Crocker, "Augmented BNF for syntax specifications: ABNF,"
Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in
progress. progress.
13 R. Elz, ``A compact representation of IPv6 addresses,'' RFC 1924, [15] R. Elz, "A compact representation of IPv6 addresses," RFC 1924,
Internet Engineering Task Force, Apr. 1996. Internet Engineering Task Force, Apr. 1996.
14 T. Berners-Lee, ``Universal resource identifiers in WWW: a unifying [16] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource
syntax for the expression of names and addresses of objects on the locators (URL)," RFC 1738, Internet Engineering Task Force, Dec.
network as used in the world-wide web,'' RFC 1630, Internet 1994.
Engineering Task Force, June 1994.
15 International Telecommunication Union, ``Visual telephone systems and [17] International Telecommunication Union, "Visual telephone systems
equipment for local area networks which provide a non-guaranteed and equipment for local area networks which provide a non-guaranteed
quality of service,'' Recommendation H.323, Telecommunication quality of service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996. Standardization Sector of ITU, Geneva, Switzerland, May 1996.
16 D. Connolly, ``PEP: an extension mechanism for http,'' Internet [18] ISO/IEC, "Information technology -- generic coding of moving
pictures and associated audio informaiton -- part 6: extension for
digital storage media and control," Draft International Standard ISO
13818-6, International Organization for Standardization ISO/IEC
JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995.
[19] D. Connolly, "PEP: an extension mechanism for http," Internet
Draft, Internet Engineering Task Force, Jan. 1997. Work in progress. Draft, Internet Engineering Task Force, Jan. 1997. Work in progress.
Table of Contents
1 Introduction ........................................ 1
1.1 Purpose ............................................. 1
1.2 Requirements ........................................ 3
1.3 Terminology ......................................... 3
1.4 Protocol Properties ................................. 5
1.5 Extending RTSP ...................................... 6
1.6 Overall Operation ................................... 7
1.7 RTSP States ......................................... 8
1.8 Relationship with Other Protocols ................... 9
2 Notational Conventions .............................. 10
3 Protocol Parameters ................................. 10
3.1 H3.1 ................................................ 10
3.2 RTSP URL ............................................ 10
3.3 Conference Identifiers .............................. 11
3.4 SMPTE Relative Timestamps ........................... 12
3.5 Normal Play Time .................................... 13
3.6 Absolute Time ....................................... 13
4 RTSP Message ........................................ 13
4.1 Message Types ....................................... 14
4.2 Message Headers ..................................... 14
4.3 Message Body ........................................ 14
4.4 Message Length ...................................... 14
5 Request ............................................. 15
6 Response ............................................ 16
6.1 Status-Line ......................................... 17
6.1.1 Status Code and Reason Phrase ....................... 17
6.1.2 Response Header Fields .............................. 19
7 Entity .............................................. 19
7.1 Entity Header Fields ................................ 21
7.2 Entity Body ......................................... 21
8 Connections ......................................... 21
8.1 Pipelining .......................................... 22
8.2 Reliability and Acknowledgements .................... 22
9 Method Definitions .................................. 23
9.1 OPTIONS ............................................. 24
9.2 DESCRIBE ........................................... 25
9.3 SETUP .............................................. 26
9.4 PLAY ............................................... 27
9.5 PAUSE .............................................. 28
9.6 TEARDOWN ........................................... 30
9.7 GET_PARAMETER ...................................... 30
9.8 SET_PARAMETER ...................................... 31
9.9 REDIRECT ........................................... 31
9.10 RECORD ............................................. 32
9.11 Embedded Binary Data ................................ 32
10 Status Code Definitions ............................. 33
10.1 Redirection 3xx ..................................... 33
10.2 Client Error 4xx .................................... 33
10.2.1 451 Parameter Not Understood ........................ 33
10.2.2 452 Conference Not Found ............................ 33
10.2.3 453 Not Enough Bandwidth ............................ 33
10.2.4 45x Session Not Found ............................... 33
10.2.5 45x Method Not Valid in This State .................. 33
10.2.6 45x Header Field Not Valid for Resource ............. 33
10.2.7 45x Invalid Range ................................... 33
10.2.8 45x Parameter Is Read-Only .......................... 34
11 Header Field Definitions ............................ 34
11.1 Accept .............................................. 34
11.2 Accept-Encoding ..................................... 35
11.3 Accept-Language ..................................... 35
11.4 Allow ............................................... 36
11.5 Authorization ....................................... 36
11.6 Bandwidth ........................................... 36
11.7 Blocksize ........................................... 36
11.8 Cache-Control ....................................... 37
11.9 Conference .......................................... 39
11.10 Connection .......................................... 39
11.11 Content-Encoding .................................... 39
11.12 Content-Length ...................................... 39
11.13 Content-Type ........................................ 39
11.14 Date ................................................ 40
11.15 Expires ............................................. 40
11.16 If-Modified-Since ................................... 41
11.17 Last-modified ....................................... 41
11.18 Location ............................................ 41
11.19 Nack-Transport-Require .............................. 41
11.20 Range ............................................... 41
11.21 Require ............................................. 42
11.22 Retry-After ......................................... 43
11.23 Scale ............................................... 43
11.24 Speed ............................................... 44
11.25 Server .............................................. 44
11.26 Session ............................................. 44
11.27 Transport ........................................... 45
11.28 Transport-Require ................................... 46
11.29 Unsupported ......................................... 46
11.30 User-Agent .......................................... 47
11.31 Via ................................................. 47
11.32 WWW-Authenticate .................................... 47
12 Caching ............................................. 47
13 Examples ............................................ 48
13.1 Media on Demand (Unicast) ........................... 48
13.2 Live Media Presentation Using Multicast ............. 49
13.3 Playing media into an existing session .............. 50
13.4 Recording ........................................... 51
14 Syntax .............................................. 52
14.1 Base Syntax ......................................... 52
15 Security Considerations ............................. 52
A RTSP Protocol State Machines ........................ 53
A.1 Client State Machine ................................ 54
A.2 Server State Machine ................................ 55
B Open Issues ......................................... 56
C Changes ............................................. 56
D Author Addresses .................................... 57
E Acknowledgements .................................... 57
F Bibliography ........................................ 58
 End of changes. 

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