draft-ietf-mmusic-rfc2326bis-03.txt   draft-ietf-mmusic-rfc2326bis-04.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft H. Schulzrinne Internet Draft H. Schulzrinne
Columbia U. Columbia U.
A. Rao A. Rao
Cisco Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
M. Westerlund M. Westerlund
Ericsson Ericsson
A. Narasimhan
Sun
draft-ietf-mmusic-rfc2326bis-03.txt draft-ietf-mmusic-rfc2326bis-04.txt
March 3, 2003 June 30, 2003
Expires: September, 2003 Expires: December, 2003
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 46 skipping to change at page 1, line 48
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This memorandum is a revision of RFC 2326, which is currently a Pro- This memorandum is a revision of RFC 2326, which is currently a Pro-
posed Standard. posed Standard.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time proper- protocol for control over the delivery of data with real-time
ties. RTSP provides an extensible framework to enable controlled, on- properties. RTSP provides an extensible framework to enable con-
demand delivery of real-time data, such as audio and video. Sources trolled, on-demand delivery of real-time data, such as audio and
of data can include both live data feeds and stored clips. This pro- video. Sources of data can include both live data feeds and stored
tocol is intended to control multiple data delivery sessions, provide clips. This protocol is intended to control multiple data delivery
a means for choosing delivery channels such as UDP, multicast UDP and sessions, provide a means for choosing delivery channels such as UDP,
TCP, and provide a means for choosing delivery mechanisms based upon multicast UDP and TCP, and provide a means for choosing delivery
RTP (RFC 1889). mechanisms based upon RTP (RFC 1889).
1 Introduction 1 Introduction
1.1 The Update of the RTSP Specification 1.1 The Update of the RTSP Specification
This is the draft to an update of the RTSP which currently is a pro- This is the draft to an update of RTSP which is currently a proposed
posed standard defined in [21]. During the years since RTSP was pub- standard defined in RFC 2326 [21]. Many flaws have been found in
lished many flaws has been found. This draft tries to address these. RTSP since it was published. While this draft tries to address the
The work is not yet completed to get all known issues resolved. flaws, not all known issues have been resolved.
The goal is to progress RTSP to draft standard. If that is possible
without first publishing it as a proposed standard is not yet deter-
mined, as it depends on the changes necessary to make the protocol
work.
See the list of changes in chapter F to see what has been addressed.
The currently open issues are listed in chapter E.
There is currently a list of reported bugs available at "http://rtsp- The goal of the current work on RTSP is to progress it to draft stan-
spec.sourceforge.net". This list should be taken into account when dard status. Whether this is possible without first publishing RTSP
reading this specification. A lot of these bugs are addressed but not as a proposed standard depends on the changes necessary to make the
yet all. Please comment on unresolved ones to give your view. protocol work. The list of changes in chapter F indicates the issues
that have already been addressed. The currently open issues are
listed in chapter E.
Another way of giving input on this work is to send e-mail to the There is also a list of reported bugs available at "http://rtsp-
MMUSIC WG's mailing list mmusic@ietf.org and the authors. spec.sourceforge.net". These bugs should be taken into account when
reading this specification. While a lot of these bugs are addressed,
not all are yet accounted for in this specification. Input on the
unresolved bugs and other issues can be sent via e-mail to the MMUSIC
WG's mailing list mmusic@ietf.org and the authors.
Take special notice of the following: Take special notice of the following:
+ The example section 15 has not yet been revised as the changes + The example section 15 has not yet been revised since the
to protocol has not been completed. changes to protocol have not been completed.
+ The BNF chapter 16 has neither been compiled completely. + The BNF chapter 16 has not been compiled completely.
All of the contents of RFC 2326 is not longer part of this draft. In | + Not all of the contents of RFC 2326 are part of this draft. In
an attempt to prevent the draft from becoming to thick for its own | an attempt to prevent the draft from exploding in size, the spec-
good, the specification has been reduced and split. The content of | ification has been reduced and split. The content of this draft
this draft is the core specification of the protocol. It contains | is the core specification of the protocol. It contains the gen-
the basic idea behind RTSP, the basic and general functionality nec- | eral idea behind RTSP and the basic functionality necessary to
essary to establish on-demand a play-back session, and the protocol | establish an on-demand play-back session. It also contains the
extension mechanisms. This allow us too keep this draft as short as | mechanisms for extending the protocol. Any other functionality
possible, it is however still a rather thick document. | will be published as extension documents. Two proposals exist at
this time:
Any other functionality will be published as extension documents. So | + NAT and FW traversal mechanisms for RTSP are described in a docu-
far there exist two proposals: | ment called "How to make Real-Time Streaming Protocol (RTSP) tra-
verse Network Address Translators (NAT) and interact with Fire-
walls." [33].
+ NAT and FW traversal mechanisms for RTSP are described in a docu- | + The MUTE extension [34] contains a proposal on adding functional-
ment called "How to make Real-Time Streaming Protocol (RTSP) tra- | ity to mute and unmute media streams in an aggregated media ses-
verse Network Address Translators (NAT) and interact with Fire- | sion without affecting the time-line of the playback.
walls." [33]. |
+ The MUTE extension [34] contains a proposal on how to add the |
possibility to MUTE and UNMUTE media streams in a aggregated |
media session without affecting the time-line of the playback. |
Unfortunately the draft has expired in IETF's repository. |
There has been discussion about the following extensions to RTSP, | There have also been discussions about the following extensions to
they have however so far not become concrete proposals: | RTSP:
+ Transport security for RTSP messages (rtsps). | + Transport security for RTSP messages (rtsps).
+ Unreliable transport of RTSP messages (rtspu). | + Unreliable transport of RTSP messages (rtspu).
+ The Record functionality. | + The Record functionality.
+ A text body type with suitable syntax for basic parameters to be | + A text body type with suitable syntax for basic parameters to be
used in SET_PARAMETER, and GET_PARAMETER. Including IANA registry | used in SET_PARAMETER, and GET_PARAMETER. Including IANA registry
within the defined name space. | within the defined name space.
+ An RTSP MIB. | + A RTSP MIB.
However, so far, they have not become concrete proposals.
1.2 Purpose 1.2 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls The Real-Time Streaming Protocol (RTSP) establishes and controls sin-
either a single or several time-synchronized streams of continuous gle or several time-synchronized streams of continuous media such as
media such as audio and video. It does not typically deliver the con- audio and video. Put simply, RTSP acts as a "network remote control"
tinuous streams itself, although interleaving of the continuous media for multimedia servers.
stream with the control stream is possible (see Section 11.11). In
other words, RTSP acts as a "network remote control" for multimedia
servers.
The set of streams to be controlled is defined by a presentation There is no notion of a RTSP connection in the protocol. Instead, a
description. This memorandum does not define a format for a presenta- RTSP server maintains a session labelled by an identifier to associ-
tion description. ate groups of media streams and their states. A RTSP session is nor-
mally not tied to a transport-level connection such as a TCP connec-
tion. During a session, a client may open and close many reliable
transport connections to the server to issue RTSP requests for that
session.
There is no necessity for a notion of an RTSP connection; instead, a This memorandum describes the use of RTSP over a reliable connection
server maintains a session labeled by an identifier. An RTSP session based transport level protocol such as TCP. RTSP may be implemented
is in normally not tied to a transport-level connection such as a TCP over an unreliable connectionless transport protocol such as UDP.
connection. During an RTSP session, an RTSP client may open and close While nothing in RTSP precludes this, additional definition of this
many reliable transport connections to the server to issue RTSP problem area must be handled as an extension to the core specifica-
requests. Alternatively, it may use a connectionless transport proto- tion.
col such as UDP.
The streams controlled by RTSP may use RTP [1], but the operation of The mechanisms of RTSP's operation over UDP were left out of
RTSP does not depend on the transport mechanism used to carry contin- this spec. because they were poorly defined in RFC 2336 [21]
uous media. and the tradeoff in size and complexity of this spec. for a
small gain in a targeted problem space was not deemed justifi-
able.
The protocol is intentionally similar in syntax and operation to The set of streams to be controlled is defined by a presentation
HTTP/1.1 [26] so that extension mechanisms to HTTP can in most cases description. This memorandum does not define a format for the
also be added to RTSP. However, RTSP differs in a number of important presentation description. The streams controlled by RTSP may use RTP
[1] for their data transport, but the operation of RTSP does not
depend on the transport mechanism used to carry continuous media. The
protocol is intentionally similar in syntax and operation to HTTP/1.1
[26] so that extension mechanisms to HTTP can in most cases also be
added to RTSP. However, RTSP differs in a number of important
aspects from HTTP: aspects from HTTP:
+ RTSP introduces a number of new methods and has a different pro- + RTSP introduces a number of new methods and has a different pro-
tocol identifier. tocol identifier.
+ An RTSP server needs to maintain state by default in almost all + RTSP has the notion of a session built into the protocol.
+ A RTSP server needs to maintain state by default in almost all
cases, as opposed to the stateless nature of HTTP. cases, as opposed to the stateless nature of HTTP.
+ Both an RTSP server and client can issue requests. + Both a RTSP server and client can issue requests.
+ Data is usually carried out-of-band by a different protocol. + Data is usually carried out-of-band by a different protocol.
Session descriptions is one possible exception. Session descriptions returned in a DESCRIBE response (see Section
11.2) and interleaving of RTP with RTSP over TCP are exceptions
to this rule (see Section 11.11).
+ RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, + RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,
consistent with current HTML internationalization efforts [3]. consistent with current HTML internationalization efforts [3].
+ The Request-URI always contains the absolute URI. Because of + The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 [26] backward compatibility with a historical blunder, HTTP/1.1 [26]
carries only the absolute path in the request and puts the host carries only the absolute path in the request and puts the host
name in a separate header field. name in a separate header field.
This makes "virtual hosting" easier, where a single host This makes "virtual hosting" easier, where a single host
skipping to change at page 1, line 210 skipping to change at page 1, line 221
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. document are to be interpreted as described in RFC 2119 [4].
1.4 Terminology 1.4 Terminology
Some of the terminology has been adopted from HTTP/1.1 [26]. Terms Some of the terminology has been adopted from HTTP/1.1 [26]. Terms
not listed here are defined as in HTTP/1.1. not listed here are defined as in HTTP/1.1.
Aggregate control: The control of the multiple streams using a sin- Aggregate control: The concept of controlling multiple streams
gle timeline by the server. For audio/video feeds, this means using a single timeline, generally maintained by the server. A
that the client may issue a single play or pause message to client, for example, uses aggregate control when it issues a
control both the audio and video feeds. single play or pause message to simultaneously control both
the audio and video in a movie.
Aggregate control URI: The URI that represents the whole aggregate. Aggregate control URI: The URI used in a RTSP request to refer to
Normally specified in the session description. and control an aggregated session. It normally, but not
always, corresponds to the presentation URI specified in the
session description. See Section 11.3 for more information.
Conference: a multiparty, multimedia presentation, where "multi" Conference: a multiparty, multimedia presentation, where "multi"
implies greater than or equal to one. implies greater than or equal to one.
Client: The client requests media service from the media server. Client: The client requests media service from the media server.
Connection: A transport layer virtual circuit established between Connection: A transport layer virtual circuit established between
two programs for the purpose of communication. two programs for the purpose of communication.
Container file: A file which may contain multiple media streams Container file: A file which may contain multiple media streams
skipping to change at page 1, line 240 skipping to change at page 1, line 254
Continuous media: Data where there is a timing relationship between Continuous media: Data where there is a timing relationship between
source and sink; that is, the sink must reproduce the timing source and sink; that is, the sink must reproduce the timing
relationship that existed at the source. The most common exam- relationship that existed at the source. The most common exam-
ples of continuous media are audio and motion video. Continu- ples of continuous media are audio and motion video. Continu-
ous media can be real-time (interactive), where there is a ous media can be real-time (interactive), where there is a
"tight" timing relationship between source and sink, or "tight" timing relationship between source and sink, or
streaming (playback), where the relationship is less strict. streaming (playback), where the relationship is less strict.
Entity: The information transferred as the payload of a request or Entity: The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of response. An entity consists of meta-information in the form
entity-header fields and content in the form of an entity- of entity-header fields and content in the form of an entity-
body, as described in Section 8. body, as described in Section 8.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality,
i.e. a feature. i.e. a feature.
Media initialization: Datatype/codec specific initialization. This Media initialization: Datatype/codec specific initialization. This
includes such things as clockrates, color tables, etc. Any includes such things as clockrates, color tables, etc. Any
transport-independent information which is required by a transport-independent information which is required by a
client for playback of a media stream occurs in the media ini- client for playback of a media stream occurs in the media ini-
tialization phase of stream setup. tialization phase of stream setup.
skipping to change at page 1, line 296 skipping to change at page 1, line 310
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a presenta- information about one or more media streams within a presenta-
tion, such as the set of encodings, network addresses and tion, such as the set of encodings, network addresses and
information about the content. Other IETF protocols such as information about the content. Other IETF protocols such as
SDP (RFC 2327 [24]) use the term "session" for a live presen- SDP (RFC 2327 [24]) use the term "session" for a live presen-
tation. The presentation description may take several differ- tation. The presentation description may take several differ-
ent formats, including but not limited to the session descrip- ent formats, including but not limited to the session descrip-
tion format SDP. tion format SDP.
Response: An RTSP response. If an HTTP response is meant, that is Response: A RTSP response. If an HTTP response is meant, that is
indicated explicitly. indicated explicitly.
Request: An RTSP request. If an HTTP request is meant, that is Request: A RTSP request. If an HTTP request is meant, that is indi-
indicated explicitly. cated explicitly.
RTSP session: A state established on a RTSP server by a client with | RTSP session: A stateful abstraction upon which the main control
an SETUP request. The RTSP session exist until it either time- | methods of RTSP operate. A RTSP session is a server entity; it
outs or is explicitly removed by a TEARDOWN request. The ses- | is created, maintained and destroyed by the server. It is
sion contains state about which media resources that can be | established by a RTSP server upon the completion of a success-
played and their transport. ful SETUP request (when 200 OK response is sent) and is
labelled by a session identifier at that time. The session
exists until timed out by the server or explicitly removed by
a TEARDOWN request. A RTSP session is also a stateful entity;
a RTSP server maintains an explicit session state machine (see
Appendix A) where most state transitions are triggered by
client requests. The existence of a session implies the exis-
tence of state about the session's media streams and their
respective transport mechanisms. A given session can have zero
or more media streams associated with it. A RTSP server uses
the session to aggregate control over multiple media streams.
Transport initialization: The negotiation of transport information Transport initialization: The negotiation of transport information
(e.g., port numbers, transport protocols) between the client (e.g., port numbers, transport protocols) between the client
and the server. and the server.
1.5 Protocol Properties 1.5 Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to RTSP. Extendable: New methods and parameters can be easily added to RTSP.
Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers.
Secure: RTSP re-uses web security mechanisms, either at the trans- Secure: RTSP re-uses web security mechanisms, either at the trans-
port level (TLS, RFC 2246 [27]) or within the protocol itself. port level (TLS, RFC 2246 [27]) or within the protocol itself.
All HTTP authentication mechanisms such as basic (RFC 2616 All HTTP authentication mechanisms such as basic (RFC 2616
[26]) and digest authentication (RFC 2069 [6]) are directly [26]) and digest authentication (RFC 2069 [6]) are directly
applicable. applicable.
Transport-independent: RTSP may use either an unreliable datagram Transport-independent: RTSP does not preclude the use of an unreli-
protocol (UDP) (RFC 768 [7]), a reliable datagram protocol able datagram protocol (UDP) (RFC 768 [7]), a reliable data-
(RDP, RFC 1151, not widely used [8]) or a reliable stream pro- gram protocol (RDP, RFC 1151, not widely used [8]) or a reli-
tocol such as TCP (RFC 793 [9]) as it implements application- able stream protocol such as TCP (RFC 793 [9]) as it imple-
level reliability. ments application-level reliability. The use of a connection-
less datagram protocol such as UDP or RDP requires additional
definition that may be provided as extensions to the core RTSP
specification.
Multi-server capable: Each media stream within a presentation can Multi-server capable: Each media stream within a presentation can
reside on a different server. The client automatically estab- reside on a different server. The client automatically estab-
lishes several concurrent control sessions with the different lishes several concurrent control sessions with the different
media servers. Media synchronization is performed at the media servers. Media synchronization is performed at the
transport level. transport level.
Control of recording devices: The protocol can control both record-
ing and playback devices, as well as devices that can alter-
nate between the two modes ("VCR").
Separation of stream control and conference initiation: Stream con- Separation of stream control and conference initiation: Stream con-
trol is divorced from inviting a media server to a conference. trol is divorced from inviting a media server to a conference.
In particular, SIP [10] or H.323 [28] may be used to invite a In particular, SIP [10] or H.323 [28] may be used to invite a
server to a conference. server to a conference.
Suitable for professional applications: RTSP supports frame-level Suitable for professional applications: RTSP supports frame-level
accuracy through SMPTE time stamps to allow remote digital accuracy through SMPTE time stamps to allow remote digital
editing. editing.
Presentation description neutral: The protocol does not impose a Presentation description neutral: The protocol does not impose a
skipping to change at page 1, line 439 skipping to change at page 1, line 462
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
change. change.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is avail- support for a certain feature and to ensure that a feature is avail-
able when performing a request. For detailed explanation of this see able when performing a request. For detailed explanation of this see
chapter 10. chapter 10.
1.7 Overall Operation 1.7 Overall Operation
Each presentation and media stream may be identified by an RTSP URL. Each presentation and media stream may be identified by a RTSP URL.
The overall presentation and the properties of the media the presen- The overall presentation and the properties of the media the presen-
tation is made up of are defined by a presentation description file, tation is made up of are defined by a presentation description file,
the format of which is outside the scope of this specification. The the format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored HTTP or other means such as email and may not necessarily be stored
on the media server. on the media server.
For the purposes of this specification, a presentation description is For the purposes of this specification, a presentation description is
assumed to describe one or more presentations, each of which main- assumed to describe one or more presentations, each of which main-
tains a common time axis. For simplicity of exposition and without tains a common time axis. For simplicity of exposition and without
loss of generality, it is assumed that the presentation description loss of generality, it is assumed that the presentation description
contains exactly one such presentation. A presentation may contain contains exactly one such presentation. A presentation may contain
several media streams. several media streams.
The presentation description file contains a description of the media The presentation description file contains a description of the media
streams making up the presentation, including their encodings, lan- streams making up the presentation, including their encodings, lan-
guage, and other parameters that enable the client to choose the most guage, and other parameters that enable the client to choose the most
appropriate combination of media. In this presentation description, appropriate combination of media. In this presentation description,
each media stream that is individually controllable by RTSP is iden- each media stream that is individually controllable by RTSP is
tified by an RTSP URL, which points to the media server handling that identified by a RTSP URL, which points to the media server handling
particular media stream and names the stream stored on that server. that particular media stream and names the stream stored on that
Several media streams can be located on different servers; for exam- server. Several media streams can be located on different servers;
ple, audio and video streams can be split across servers for load for example, audio and video streams can be split across servers for
sharing. The description also enumerates which transport methods the load sharing. The description also enumerates which transport methods
server is capable of. the server is capable of.
Besides the media parameters, the network destination address and Besides the media parameters, the network destination address and
port need to be determined. Several modes of operation can be distin- port need to be determined. Several modes of operation can be distin-
guished: guished:
Unicast: The media is transmitted to the source of the RTSP Unicast: The media is transmitted to the source of the RTSP
request, with the port number chosen by the client. Alterna- request, with the port number chosen by the client. Alterna-
tively, the media is transmitted on the same reliable stream tively, the media is transmitted on the same reliable stream
as RTSP. as RTSP.
skipping to change at page 1, line 499 skipping to change at page 1, line 522
occur on a TCP connection while the data flows via UDP. Thus, data occur on a TCP connection while the data flows via UDP. Thus, data
delivery continues even if no RTSP requests are received by the media delivery continues even if no RTSP requests are received by the media
server. Also, during its lifetime, a single media stream may be con- server. Also, during its lifetime, a single media stream may be con-
trolled by RTSP requests issued sequentially on different TCP connec- trolled by RTSP requests issued sequentially on different TCP connec-
tions. Therefore, the server needs to maintain "session state" to be tions. Therefore, the server needs to maintain "session state" to be
able to correlate RTSP requests with a stream. The state transitions able to correlate RTSP requests with a stream. The state transitions
are described in Appendix A. are described in Appendix A.
Many methods in RTSP do not contribute to state. However, the follow- | Many methods in RTSP do not contribute to state. However, the follow- |
ing play a central role in defining the allocation and usage of | ing play a central role in defining the allocation and usage of |
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT and | stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING |
TEARDOWN. and TEARDOWN.
SETUP: Causes the server to allocate resources for a stream and SETUP: Causes the server to allocate resources for a stream and
create an RTSP session. create a RTSP session.
PLAY: Starts data transmission on a stream allocated via SETUP. | PLAY: Starts data transmission on a stream allocated via SETUP. |
PAUSE: Temporarily halts a stream without freeing server resources. PAUSE: Temporarily halts a stream without freeing server resources.
REDIRECT: Indicates that the session should be moved to new server
/ location
PING: Prevents the identified session from being timed out.
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header RTSP methods that contribute to state use the Session header field
field (Section 13.37) to identify the RTSP session whose state (Section 13.37) to identify the RTSP session whose state is being
is being manipulated. The server generates session identifiers manipulated. The server generates session identifiers in response to
in response to SETUP requests (Section 11.3). SETUP requests (Section 11.3).
1.9 Relationship with Other Protocols 1.9 Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may inter- RTSP has some overlap in functionality with HTTP. It also may inter-
act with HTTP in that the initial contact with streaming content is act with HTTP in that the initial contact with streaming content is
often to be made through a web page. The current protocol specifica- often to be made through a web page. The current protocol specifica-
tion aims to allow different hand-off points between a web server and tion aims to allow different hand-off points between a web server and
the media server implementing RTSP. For example, the presentation the media server implementing RTSP. For example, the presentation
description can be retrieved using HTTP or RTSP, which reduces description can be retrieved using HTTP or RTSP, which reduces
roundtrips in web-browser-based scenarios, yet also allows for roundtrips in web-browser-based scenarios, yet also allows for stan-
standalone RTSP servers and clients which do not rely on HTTP at all. dalone RTSP servers and clients which do not rely on HTTP at all.
However, RTSP differs fundamentally from HTTP in that most data However, RTSP differs fundamentally from HTTP in that most data
delivery takes place out-of-band in a different protocol. HTTP is an delivery takes place out-of-band in a different protocol. HTTP is an
asymmetric protocol where the client issues requests and the server asymmetric protocol where the client issues requests and the server
responds. In RTSP, both the media client and media server can issue responds. In RTSP, both the media client and media server can issue
requests. RTSP requests are also not stateless; they may set parame- requests. RTSP requests are also stateful; they may set parameters
ters and continue to control a media stream long after the request and continue to control a media stream long after the request has
has been acknowledged. been acknowledged.
Re-using HTTP functionality has advantages in at least two Re-using HTTP functionality has advantages in at least two
areas, namely security and proxies. The requirements are very areas, namely security and proxies. The requirements are very
similar, so having the ability to adopt HTTP work on caches, similar, so having the ability to adopt HTTP work on caches,
proxies and authentication is valuable. proxies and authentication is valuable.
While most real-time media will use RTP as a transport protocol, RTSP
is not tied to RTP.
RTSP assumes the existence of a presentation description format that RTSP assumes the existence of a presentation description format that
can express both static and temporal properties of a presentation can express both static and temporal properties of a presentation
containing several media streams. containing several media streams. Session Description Protocol (SDP)
[24] is generally the format of choice; however, RTSP is not bound to
it. For data delivery, most real-time media will use RTP as a trans-
port protocol. While RTSP works well with RTP, it is not tied to RTP.
2 Notational Conventions 2 Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1, Since many of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [26]). to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [26]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur form (BNF) similar to that used in prose and an augmented Backus-Naur form (BNF) similar to that used in
skipping to change at page 1, line 571 skipping to change at page 1, line 598
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. This is intended to give readers who were background and motivation. This is intended to give readers who were
not involved with the formulation of the specification an understand- not involved with the formulation of the specification an understand-
ing of why things are the way that they are in RTSP. ing of why things are the way that they are in RTSP.
b b
3 Protocol Parameters 3 Protocol Parameters
3.1 RTSP Version 3.1 RTSP Version
HTTP Specification Section [H3.1] applies, with HTTP replaced by HTTP Specification Section [H3.1] applies, with HTTP replaced by
RTSP. This specification defines version 1.0 of RTSP. RTSP. This specification defines version 1.0 of RTSP.
3.2 RTSP URL 3.2 RTSP URL
The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network
resources via the RTSP protocol. This section defines the scheme-spe- resources via the RTSP protocol. This section defines the scheme-spe-
cific syntax and semantics for RTSP URLs. cific syntax and semantics for RTSP URLs. The RTSP URL is case sensi-
tive. |
rtsp_URL = ( "rtsp:" / "rtspu:" / "rtsps:" ) rtsp_URL = ( "rtsp:" / "rtspu:" / "rtsps:" ) ||
"//" host [ ":" port ] [ abs_path ] [ "#" fragment ] "//" host [ ":" port ] [ abs_path [ "?" query ]] ||
host = As defined by RFC 2732 [30] host = As defined by RFC 2732 [30] ||
abs_path = As defined by RFC 2396 [22] abs_path = As defined by RFC 2396 [22] ||
port = *DIGIT port = *DIGIT ||
query = As defined by RFC 2396 [22] ||
Note that fragment and query identifiers do not have a well- Note that fragment and query identifiers do not have a well-
defined meaning at this time, with the interpretation left to defined meaning at this time, with the interpretation left to
the RTSP server. the RTSP server.
The scheme rtsp requires that commands are issued via a reliable pro- | The scheme rtsp requires that commands are issued via a reliable pro- |
tocol (within the Internet, TCP), while the scheme rtspu identifies | tocol (within the Internet, TCP), while the scheme rtspu identifies |
an unreliable protocol (within the Internet, UDP). The scheme rtsps | an unreliable protocol (within the Internet, UDP). The scheme rtsps |
identifies a reliable transport using TLS [27]. The rtspu and rtsps | identifies a reliable transport using secure transport, perhaps TLS |
is not defined in this specification and if for future extensions of | [27]. The rtspu and rtsps is not defined in this specification and if |
the protocol. for future extensions of the protocol.
If the port is empty or not given, port 554 is assumed. The seman- If the port is empty or not given, port 554 SHALL be assumed. The
tics are that the identified resource can be controlled by RTSP at semantics are that the identified resource can be controlled by RTSP
the server listening for TCP (scheme "rtsp") connections or UDP at the server listening for TCP (scheme "rtsp") connections or UDP
(scheme "rtspu") packets on that port of host, and the Request-URI (scheme "rtspu") packets on that port of host, and the Request-URI
for the resource is rtsp_URL. for the resource is rtsp_URL.
The use of IP addresses in URLs SHOULD be avoided whenever possible The use of IP addresses in URLs SHOULD be avoided whenever possible
(see RFC 1924 [16]). Note: Using qualified domain names in any URL is (see RFC 1924 [16]). Note: Using qualified domain names in any URL is
one requirement for making it possible for RFC 2326 implementations one requirement for making it possible for RFC 2326 implementations
of RTSP to use IPv6. This specification is updated to allow for lit- of RTSP to use IPv6. This specification is updated to allow for lit-
eral IPv6 addresses in RTSP URLs using the host specification in RFC eral IPv6 addresses in RTSP URLs using the host specification in RFC
2732 [30]. 2732 [30].
skipping to change at page 1, line 913 skipping to change at page 1, line 943
HTTP/1.1 requires servers to understand the absolute URL, but HTTP/1.1 requires servers to understand the absolute URL, but
clients are supposed to use the Host request header. This is clients are supposed to use the Host request header. This is
purely needed for backward-compatibility with HTTP/1.0 purely needed for backward-compatibility with HTTP/1.0
servers, a consideration that does not apply to RTSP. servers, a consideration that does not apply to RTSP.
The asterisk "*" in the Request-URI means that the request does not The asterisk "*" in the Request-URI means that the request does not
apply to a particular resource, but to the server or proxy itself, apply to a particular resource, but to the server or proxy itself,
and is only allowed when the method used does not necessarily apply and is only allowed when the method used does not necessarily apply
to a resource. to a resource.
One example would be: One example would be as follows:
OPTIONS * RTSP/1.0 OPTIONS * RTSP/1.0
Which will determine the capabilities of the server or the proxy that An OPTIONS in this form will determine the capabilities of the server
first receives the request. If one needs to address the server explic- or the proxy that first receives the request. If one needs to address
itly one needs to put in a absolute URL with the servers address. the server explicitly, then one should use an absolute URL with the
server's address.
OPTIONS rtsp://example.com RTSP/1.0 OPTIONS rtsp://example.com RTSP/1.0
7 Response 7 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. [H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some Also, RTSP defines additional status codes and does not define some
HTTP codes. The valid response codes and the methods they can be used HTTP codes. The valid response codes and the methods they can be used
with are defined in Table 1. with are defined in Table 1.
skipping to change at page 1, line 1050 skipping to change at page 1, line 1080
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an unrecog- x00 status code of that class, with the exception that an unrecog-
nized response MUST NOT be cached. For example, if an unrecognized nized response MUST NOT be cached. For example, if an unrecognized
status code of 431 is received by the client, it can safely assume status code of 431 is received by the client, it can safely assume
that there was something wrong with its request and treat the that there was something wrong with its request and treat the
response as if it had received a 400 status code. In such cases, user response as if it had received a 400 status code. In such cases, user
agents SHOULD present to the user the entity returned with the agents SHOULD present to the user the entity returned with the
response, since that entity is likely to include human-readable response, since that entity is likely to include human-readable
information which will explain the unusual status. information which will explain the unusual status.
7.1.2 Response Header Fields Code Reason Method
The response-header fields allow the request recipient to pass addi-
tional information about the response which cannot be placed in the
Status-Line. These header fields give information about the server
and about further access to the resource identified by the Request-
URI.
response-header = Accept-Ranges ; Section
13.4
/ Location ; Section 13.25
/ Proxy-Authenticate ; Section 13.26
/ Public ; Section 13.28
/ Range ; Section 13.29
/ Retry-After ; Section 13.31
/ RTP-Info ; Section 13.33
/ Scale ; Section 13.34
/ Session ; Section 13.37
/ Server ; Section 13.36
/ Speed ; Section 13.35
/ Transport ; Section 13.40
/ Unsupported ; Section 13.41
/ Vary ; Section 13.43
/ WWW-Authenticate ; Section 13.45
Response-header field names can be extended reliably only in combina-
tion with a change in the protocol version. However, new or experi-
mental header fields MAY be given the semantics of response-header
fields if all parties in the communication recognize them to be
response-header fields. Unrecognized header fields are treated as
entity-header fields.
8 Entity
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
Code reason
-------------------------------------------------------- --------------------------------------------------------
100 Continue all 100 Continue all
-------------------------------------------------------- --------------------------------------------------------
200 OK all 200 OK all
201 Created RECORD 201 Created RECORD
250 Low on Storage Space RECORD 250 Low on Storage Space RECORD
-------------------------------------------------------- --------------------------------------------------------
300 Multiple Choices all 300 Multiple Choices all
301 Moved Permanently all 301 Moved Permanently all
302 Found all 302 Found all
303 See Other all 303 See Other all
305 Use Proxy all 305 Use Proxy all
350 Going Away all 350 Going Away all
351 Load Balancing all 351 Load Balancing all
-------------------------------------------------------- --------------------------------------------------------
Code Reason Method
--------------------------------------------------------
400 Bad Request all 400 Bad Request all
401 Unauthorized all 401 Unauthorized all
402 Payment Required all 402 Payment Required all
403 Forbidden all 403 Forbidden all
404 Not Found all 404 Not Found all
405 Method Not Allowed all 405 Method Not Allowed all
406 Not Acceptable all 406 Not Acceptable all
407 Proxy Authentication Required all 407 Proxy Authentication Required all
408 Request Timeout all 408 Request Timeout all
410 Gone all 410 Gone all
skipping to change at page 1, line 1141 skipping to change at page 1, line 1136
500 Internal Server Error all 500 Internal Server Error all
501 Not Implemented all 501 Not Implemented all
502 Bad Gateway all 502 Bad Gateway all
503 Service Unavailable all 503 Service Unavailable all
504 Gateway Timeout all 504 Gateway Timeout all
505 RTSP Version Not Supported all 505 RTSP Version Not Supported all
551 Option not support all 551 Option not support all
Table 1: Status codes and their usage with RTSP methods Table 1: Status codes and their usage with RTSP methods
7.1.2 Response Header Fields
The response-header fields allow the request recipient to pass addi-
tional information about the response which cannot be placed in the
Status-Line. These header fields give information about the server
and about further access to the resource identified by the Request-
URI.
response-header = Accept-Ranges ; Section 13.4
/ Location ; Section 13.25
/ Proxy-Authenticate ; Section 13.26
/ Public ; Section 13.28
/ Range ; Section 13.29
/ Retry-After ; Section 13.31
/ RTP-Info ; Section 13.33
/ Scale ; Section 13.34
/ Session ; Section 13.37
/ Server ; Section 13.36
/ Speed ; Section 13.35
/ Transport ; Section 13.40
/ Unsupported ; Section 13.41
/ Vary ; Section 13.43
/ WWW-Authenticate ; Section 13.45
Response-header field names can be extended reliably only in combina-
tion with a change in the protocol version. However, new or experi-
mental header fields MAY be given the semantics of response-header
fields if all parties in the communication recognize them to be
response-header fields. Unrecognized header fields are treated as
entity-header fields.
8 Entity
Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity. or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields 8.1 Entity Header Fields
Entity-header fields define optional meta-information about the Entity-header fields define optional meta-information about the
entity-body or, if no body is present, about the resource identified entity-body or, if no body is present, about the resource identified
by the request. by the request.
skipping to change at page 1, line 1247 skipping to change at page 1, line 1278
ment, the request MUST carry the original sequence number (i.e., the ment, the request MUST carry the original sequence number (i.e., the
sequence number is not incremented). sequence number is not incremented).
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 support UDP. The default port for the RTSP server is 554 for both UDP
and TCP. and TCP.
A number of RTSP packets destined for the same control end point may A number of RTSP packets destined for the same control end point may
be packed into a single lower-layer PDU or encapsulated into a TCP be packed into a single lower-layer PDU or encapsulated into a TCP
stream. RTSP data MAY be interleaved with RTP and RTCP packets. stream. RTSP data MAY be interleaved with RTP and RTCP packets.
Unlike HTTP, an RTSP message MUST contain a Content-Length header Unlike HTTP, an RTSP message MUST contain a Content-Length header
field whenever that message contains a payload. Otherwise, an RTSP field whenever that message contains a payload. Otherwise, an RTSP
packet is terminated with an empty line immediately following the packet is terminated with an empty line immediately following the
last message header. last message header.
9.3 The usage of connections 9.3 The usage of connections
TCP can be used for both persistent connections and for one message | TCP can be used for both persistent connections and for one message
exchange per connection, as presented above. This section gives fur- | exchange per connection, as presented above. This section gives fur-
ther rules and recommendations on how to handle these connections so | ther rules and recommendations on how to handle these connections so
maximum interoperability and flexibility can be achieved. | maximum interoperability and flexibility can be achieved.
A server SHALL handle both persistent connections and one | A server SHALL handle both persistent connections and one
request/response transaction per connection. A persistent connection | request/response transaction per connection. A persistent connection
MAY be used for all transactions between the server and client, | MAY be used for all transactions between the server and client,
including messages to multiple RTSP sessions. However the persistent | including messages to multiple RTSP sessions. However the persistent
connection MAY also be closed after a few message exchanges, e.g. the | connection MAY also be closed after a few message exchanges, e.g. the
initial setup and play command in a session. Later when the client | initial setup and play command in a session. Later when the client
wishes to send a new request, e.g. pause, to the session a new con- | wishes to send a new request, e.g. pause, to the session a new con-
nection is opened. This connection may either be for a single message | nection is opened. This connection may either be for a single message
exchange or can be kept open for several messages, i.e. persistent. | exchange or can be kept open for several messages, i.e. persistent.
A major motivation for allowing non-persistent connections are that | A major motivation for allowing non-persistent connections are that
they ensure fault tolerance. A server and client supporting non-per- | they ensure fault tolerance. A server and client supporting non-per-
sistent connection can survive a loss of a TCP connection, e.g. due | sistent connection can survive a loss of a TCP connection, e.g. due
to a NAT timeout. When the it is discovered that the TCP connection | to a NAT timeout. When the it is discovered that the TCP connection
has been lost one sets up a new one. | has been lost one sets up a new one.
The client MAY close the connection at any time when no outstanding | The client MAY close the connection at any time when no outstanding |
request/response transactions exist. The server SHOULD NOT close the | request/response transactions exist. The server SHOULD NOT close the |
connection unless at least one RTSP session timeout period has passed | connection unless at least one RTSP session timeout period has passed |
without data traffic. A server MUST NOT initiate a close of a connec- | without data traffic. A server MUST NOT initiate a close of a connec- |
tion directly after responding to a TEARDOWN request for the whole | tion directly after responding to a TEARDOWN request for the whole |
session. | session. A server MUST NOT close the connection as a result of |
responding to a request with an error code. Doing this would prevent |
or result in extra overhead for the client when testing advanced or |
special types of requests.
The client SHOULD NOT have more than one connection to the server at | The client SHOULD NOT have more than one connection to the server at
any given point. If a client or proxy handles multiple RTSP sessions | any given point. If a client or proxy handles multiple RTSP sessions
on the same server, it is RECOMMENDED to use only a single connec- | on the same server, it is RECOMMENDED to use only a single connec-
tion. | tion.
Older services which was implemented according to RFC 2326 sometimes | Older services which was implemented according to RFC 2326 sometimes
requires the client to use persistent connection. The client closing | requires the client to use persistent connection. The client closing
the connection may result in that the server removes the session. To | the connection may result in that the server removes the session. To
achieve interoperability with old servers any client is strongly REC- | achieve interoperability with old servers any client is strongly REC-
OMMENDED to use persistent connections. | OMMENDED to use persistent connections.
A Client is also strongly RECOMMENDED to use persistent connections | A Client is also strongly RECOMMENDED to use persistent connections
as it allows the server to send request to the client. In cases | as it allows the server to send request to the client. In cases
where no connection exist between the server and the client, this may | where no connection exist between the server and the client, this may
cause the server to be forced to drop the RTSP session without noti- | cause the server to be forced to drop the RTSP session without noti-
fying the client why,due to the lack of signalling channel. An exam- | fying the client why,due to the lack of signalling channel. An exam-
ple of such a case is when the server desires to send a REDIRECT | ple of such a case is when the server desires to send a REDIRECT
request for a RTSP session to the client. | request for a RTSP session to the client.
If a service requires the use of persistent connection an feature-tag | If a service requires the use of persistent connection an feature-tag
is specified for usage in the Require and Proxy-Require headers. | is specified for usage in the Require and Proxy-Require headers.
con.persistent || con.persistent
A server implemented according to this specification MUST respond | A server implemented according to this specification MUST respond
that it supports the "play.basic" feature-tag above. A client MAY | that it supports the "play.basic" feature-tag above. A client MAY
send a request including the Supported header in a request to deter- | send a request including the Supported header in a request to deter-
mine support of non-persistent connections. A server supporting non- | mine support of non-persistent connections. A server supporting non-
persistent connections will return the "play.basic" feature-tag in | persistent connections will return the "play.basic" feature-tag in
its response. If the client receives the feature-tag in the response, | its response. If the client receives the feature-tag in the response,
it can be certain that the server handles non-persistent connections. it can be certain that the server handles non-persistent connections.
9.4 Use of IPv6 9.4 Use of IPv6
This specification has been updated so that it supports IPv6. How- This specification has been updated so that it supports IPv6. How-
ever this support was not present in RFC 2326 therefore some interop- ever this support was not present in RFC 2326 therefore some interop-
erability issues exist. A RFC 2326 implementation can support IPv6 as erability issues exist. A RFC 2326 implementation can support IPv6 as
long as no explicit IPv6 addresses are used within RTSP messages. long as no explicit IPv6 addresses are used within RTSP messages.
This require that any RTSP URL pointing at a IPv6 host must use fully This require that any RTSP URL pointing at a IPv6 host must use fully
qualified domain name and not a IPv6 address. Further the Transport qualified domain name and not a IPv6 address. Further the Transport
skipping to change at page 1, line 1386 skipping to change at page 1, line 1421
Require: The Require header can be included in any request where Require: The Require header can be included in any request where
the end point, i.e. the client or server, is required to the end point, i.e. the client or server, is required to
understand the feature to correctly perform the request. This understand the feature to correctly perform the request. This
can for example be a SETUP request where the server must can for example be a SETUP request where the server must
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require must negatively receiving a request containing a Require must negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not understood are 551 (Option Not Supported). Also the fea- not understood are 551 (Option Not Supported). Also the
tures that are not understood are given in the Unsupported features that are not understood are given in the Unsupported
header in the response. header in the response.
Proxy-Require: This method has the same purpose and workings as Proxy-Require: This method has the same purpose and workings as
Require except that it only applies to proxies and not the end Require except that it only applies to proxies and not the end
point. Features that needs to be supported by both proxies and point. Features that needs to be supported by both proxies and
end-point needs to be included in both the Require and Proxy- end-point needs to be included in both the Require and Proxy-
Require header. Require header.
Unsupported: This header is used in 551 error response to tell Unsupported: This header is used in 551 error response to tell
which feature(s) that was not supported. Such a response is which feature(s) that was not supported. Such a response is
skipping to change at page 1, line 1411 skipping to change at page 1, line 1446
uations as it knows which features that was not supported. uations as it knows which features that was not supported.
11 Method Definitions 11 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 case-sensitive. New methods may be identified by the Request-URI case-sensitive. New methods 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 as defined by the ABNF. Methods are (decimal 24) and must be a token as defined by the ABNF. Methods are
summarized in Table 2. summarized in Table 2.
Notes on Table 2: PAUSE is recommended, but not required in that a
fully functional server can be built that does not support this
method, for example, for live feeds. If a server does not support a
method direction object Server req. Client req. method direction object Server req. Client req.
---------------------------------------------------------------- ----------------------------------------------------------------
DESCRIBE C->S P,S recommended recommended DESCRIBE C->S P,S recommended recommended
GET_PARAMETER C->S, S->C P,S optional optional GET_PARAMETER C->S, S->C P,S optional optional
OPTIONS C->S, S->C P,S R=Req, Sd=Opt Sd=Req, R=Opt OPTIONS C->S, S->C P,S R=Req, Sd=Opt Sd=Req, R=Opt
PAUSE C->S P,S recommended recommended PAUSE C->S P,S recommended recommended
PING C->S, S->C P,S recommended optional PING C->S, S->C P,S recommended optional
PLAY C->S P,S required required PLAY C->S P,S required required
REDIRECT S->C P,S optional optional REDIRECT S->C P,S optional optional
SETUP C->S S required required SETUP C->S S required required
SET_PARAMETER C->S, S->C P,S optional optional SET_PARAMETER C->S, S->C P,S optional optional
TEARDOWN C->S P,S required required TEARDOWN C->S P,S required required
Table 2: Overview of RTSP methods, their direction, and what objects Table 2: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Responde to, (P: presentation, S: stream) they operate on. Legend: R=Responde to,
Sd=Send, Opt: Optional, Req: Required, Rec: Recommended Sd=Send, Opt: Optional, Req: Required, Rec: Recommended
Notes on Table 2: PAUSE is recommended, but not required in that a
fully functional server can be built that does not support this
method, for example, for live feeds. If a server does not support a
particular method, it MUST return 501 (Not Implemented) and a client particular method, it MUST return 501 (Not Implemented) and a client
SHOULD not try this method again for this server. SHOULD not try this method again for this server.
11.1 OPTIONS 11.1 OPTIONS
The behavior is equivalent to that described in [H9.2]. An OPTIONS The behavior is equivalent to that described in [H9.2]. An OPTIONS
request may be issued at any time, e.g., if the client is about to request may be issued at any time, e.g., if the client is about to
try a nonstandard request. It does not influence the session state. try a nonstandard request. It does not influence the session state.
The Public header MUST be included in responses to indicate which The Public header MUST be included in responses to indicate which
methods that are supported by the server. To specify which methods methods that are supported by the server. To specify which methods
skipping to change at page 1, line 1551 skipping to change at page 1, line 1587
11.3 SETUP 11.3 SETUP
The SETUP request for a URI specifies the transport mechanism to be The SETUP request for a URI specifies the transport mechanism to be
used for the streamed media. A client can issue a SETUP request for a used for the streamed media. A client can issue a SETUP request for a
stream that is already set up or playing in the session to change stream that is already set up or playing in the session to change
transport parameters, which a server MAY allow. If it does not allow transport parameters, which a server MAY allow. If it does not allow
this, it MUST respond with error 455 (Method Not Valid In This this, it MUST respond with error 455 (Method Not Valid In This
State). State).
A server MAY allow a client to do SETUP while in playing state to add A server MAY allow a client to do SETUP while in playing state to add
additional media streams. If not supported the server shall responde additional media streams. If not supported, the server SHALL respond
with error 455 (Method Not Allowed In This State). If supported the with error 455 (Method Not Allowed In This State). If supported, the
added media shall then start to play in sync with the already playing added media SHALL then start to play in sync with the already playing
media. To be able to sync the media with the already playing streams media. To be able to sync the media with the already playing streams
the SETUP response MUST include a RTP-Info header with the timestamp the SETUP response MUST include a RTP-Info header with the timestamp
value, and a Range header with the corresponding normal play time. To value, and a Range header with the corresponding normal play time. To
indicate support for this optional feature the feature-tag: indicate support for this optional feature the feature-tag:
"setup.playing" is defined. "setup.playing" is defined.
For 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 multi-
cast address.
Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need
this information) are spared the more arduous task of parsing
the DESCRIBE response, which has been reserved for media ini-
tialization.
The Transport header specifies the transport parameters acceptable to The Transport header specifies the transport parameters acceptable to
the client for data transmission; the response will contain the the client for data transmission; the response will contain the
transport parameters selected by the server. transport parameters selected by the server.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589 Transport: RTP/AVP;unicast;client_port=4588-4589
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast; Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257 client_port=4588-4589;server_port=6256-6257
The server generates session identifiers in response to SETUP For the benefit of any intervening firewalls, a client must indicate
requests. If a SETUP request to a server includes a session identi- the transport parameters even if it has no influence over these
parameters, for example, where the server advertises a fixed multi-
cast address.
Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need
this information) are spared the more arduous task of parsing
the DESCRIBE response, which has been reserved for media ini-
tialization.
The server generates a session identifier in response to a SETUP
request. If a SETUP request to a server includes a session identi-
fier, the server MUST bundle this setup request into the existing fier, the server MUST bundle this setup request into the existing
session (aggregated session) or return error 459 (Aggregate Operation session (aggregated session) or return error 459 (Aggregate Operation
Not Allowed) (see Section 12.4.11). Not Allowed) (see Section 12.4.11). An Aggregate control URI MUST be
used to control an aggregated session. This URI MUST be different
from the stream control URIs of the individual media streams included
in the aggregate. The Aggregate control URI SHOULD be specified by
the session description since there is no general rule for deriving
it from the various stream control URIs in the session. If an Aggre-
gate control URI is not specified in the session description, a
client MUST create an URI for aggregate control of the session. This
URI MUST contain the servers host address and MUST contain the port,
if applicable. Once an URI is used to refer to an aggregation for a
given session, that URI MUST be used to refer to that aggregation for
the duration of the session. If the contents of the aggregation
change, then a different aggregate control URI SHOULD be used.
To control an aggregated session an aggregated control URI MUST be While the session ID has enough information for aggregate con-
used. The aggregated control URI MUST be different from any of the trol of a session, the Aggregate control URI is still impor-
media control URIs included in the aggregate. The aggregated URI tant for some methods such as SET_PARAMETER where the control
SHOULD be specified by session description, as no general rule exist URI enables the resource in question to be easily identified.
to derive it from the included media's. The Aggregate control URI is also useful for proxies, enabling
them to route the request to the appropriate server, and for
logging, where it is useful to note the actual resource that a
request was operating on. Finally, presence of the Aggregate
control URI allows for backwards compatibility with RFC 2326
[21].
A session will exist until it is torn down by a TEARDOWN request or A session will exist until it is either removed by a TEARDOWN request
times out. The server MAY remove a session that have had no liveness or is timed-out by the server. The server MAY remove a session that
signs from the client in the specified timeout time. The default has not demonstrated liveness signs from the client within a certain
timeout time is 60 seconds, the server MAY set this to another value, timeout period. The default timeout value is 60 seconds; the server
by in the SETUP response include a timeout value in the session MAY set this to a different value and indicate so in the timeout
header. For further discussion see chapter 13.37. Signs of client field of the Session header in the SETUP response. For further dis-
liveness are: cussion see chapter 13.37. Signs of liveness for a RTSP session are:
+ RTCP sender or receiver reports from the client in any of the RTP + Any RTSP request from a client which includes a Session header
sessions part of the RTSP session. with that session's ID.
+ Any RTSP request which includes a Session header with the ses- + If RTP is used as a transport for the underlying media streams,
sion's ID. an RTCP sender or receiver report from the client for any of the
media streams in that RTSP session.
If a SETUP request on a session fails for any reason, the session |
state, as well as transport and other parameters for associated |
streams SHALL remain unchanged from their values as if the SETUP |
request had never been received by the server.
11.4 PLAY 11.4 PLAY
The PLAY method tells the server to start sending data via the mecha- The PLAY method tells the server to start sending data via the mecha-
nism specified in SETUP. A client MUST NOT issue a PLAY request until nism specified in SETUP. A client MUST NOT issue a PLAY request until
any outstanding SETUP requests have been acknowledged as successful. any outstanding SETUP requests have been acknowledged as successful.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URL. A server SHALL responde with error 460 (Only Aggregate control URL. A server SHALL responde with error 460 (Only Aggregate
Operation Allowed) if the client PLAY request URI is for one of the Operation Allowed) if the client PLAY request URI is for one of the
skipping to change at page 1, line 1650 skipping to change at page 1, line 1708
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=20-25, npt=30- Range: npt=10-15, npt=20-25, npt=30-
See the description of the PAUSE request for further examples. See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It starts playing a 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 from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the stream has been paused via PAUSE, stream delivery resumes at the
pause point. pause point.
The Range header may also contain a time parameter. This parameter The Range header MUST NOT contain a time parameter. The usage of time |
specifies a time in UTC at which the playback should start. If the has been deprecated.
message is received after the specified time, playback is started
immediately. The time parameter may be used to aid in synchronization
of streams obtained from different sources. Note: The usage of time
has two problems. First, at the time requested the RTSP state machine
may not accept the request. The client will not get any notification
of the failure. Secondly, the server has difficulties to produce the
synchronization information for the RTP-Info header ahead of the
actually play-out. Due to these reasons it is RECOMMENDED that a
client not issues more than one timed request and no request without
timing , until it is performed. The server SHALL in responses to
timed PLAY request give in the RTP-Info header, the sequence number
of the next RTP packet that will be send for that media, the RTP
timestamp value corresponding to the activation time of the request.
Unless the session is in paused state and not plays a single media
packet the RTP sequence number will be in error. The RTP timestamp
should be correct unless another timestamp rate has been used in
between the issuing of the request and activation.
Server MUST include a "Range" header in any PLAY response. The | Server MUST include a "Range" header in any PLAY response. The |
response MUST use the same format as the request's range header con- | response MUST use the same format as the request's range header con- |
tained. If no Range header was in the request, the NPT time format | tained. If no Range header was in the request, the NPT time format |
SHOULD be used unless the client showed support for other formats. | SHOULD be used unless the client showed support for other formats. |
For a session with live media streams the Range header MUST also be | For a session with live media streams the Range header MUST also be |
given, containing a valid time indication. It is RECOMMENDED that | given, containing a valid time indication. It is RECOMMENDED that |
either "npt=now-" or a absolute time value (clock) for the corre- | either "npt=now-" or a absolute time value (clock) for the corre- |
sponding time is given, i.e. "clock=20030213T143205Z-". The UTC | sponding time is given, i.e. "clock=20030213T143205Z-". The UTC |
clock format SHOULD only be used if client has shown support for it. clock format SHOULD only be used if client has shown support for it.
skipping to change at page 1, line 1752 skipping to change at page 1, line 1793
value, a 457 (Invalid Range) response SHALL be given. value, a 457 (Invalid Range) response SHALL be given.
The queued play functionality described in RFC 2326 [21] is removed The queued play functionality described in RFC 2326 [21] is removed
and multiple ranges can be used to achieve a similar performance. If and multiple ranges can be used to achieve a similar performance. If
a server receives a PLAY request while in the PLAY state, the server a server receives a PLAY request while in the PLAY state, the server
SHALL responde using the error code 455 (Method Not Valid In This SHALL responde using the error code 455 (Method Not Valid In This
State). This will signal the client that queued play are not sup- State). This will signal the client that queued play are not sup-
ported. ported.
The use of PLAY for keep-alive signaling, i.e. PLAY request without a The use of PLAY for keep-alive signaling, i.e. PLAY request without a
range header, has also been decapitated. Instead a client can use, range header, has also been depreciated. Instead a client can use,
PING, SET_PARAMETER or OPTIONS for keep alive. A server receiving a PING, SET_PARAMETER or OPTIONS for keep alive. A server receiving a
PLAY keep alive SHALL respond with the 455 error code. PLAY keep alive SHALL respond with the 455 error code.
When playing live media, indicated by the Accept-Ranges header the | When playing live media, indicated by the Accept-Ranges header the |
session are in a live state. This live state will put some restric- | session are in a live state. This live state will put some restric- |
tions on the action available for a client. A PLAY request without a | tions on the action available for a client. A PLAY request without a |
Range header will start media deliver at the current point in the | Range header will start media deliver at the current point in the |
live presentation, i.e. now. Any seeking in the media will be impos- | live presentation, i.e. now. Any seeking in the media will be impos- |
sible. The only allowed usage of the Range header is npt=now-, and | sible. The only allowed usage of the Range header is npt=now-, and |
certain clock units. The usage of npt=now- is unnecessary as it has | certain clock units. The usage of npt=now- is unnecessary as it has |
skipping to change at page 1, line 1794 skipping to change at page 1, line 1835
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76 Range: npt=45.76
The PAUSE request may contain a Range header specifying when the The PAUSE request may contain a Range header specifying when the
stream or presentation is to be halted. We refer to this point as the stream or presentation is to be halted. We refer to this point as the
"pause point". The header MUST contain a single value, expressed as "pause point". The time parameter in the Range MUST NOT be used. |
the beginning value an open range. For example, the following clip The header MUST contain a single value, expressed as the beginning
will be played from 10 seconds through 21 seconds of the clip's nor- value an open range. For example, the following clip will be played
mal play time, under the assumption that the PAUSE request reaches from 10 seconds through 21 seconds of the clip's normal play time,
the server within 11 seconds of the PLAY request. Note that some under the assumption that the PAUSE request reaches the server within
lines has been broken in an non-correct way to fit the page: 11 seconds of the PLAY request. Note that some lines has been broken
in an non-correct way to fit the page:
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
skipping to change at page 1, line 1867 skipping to change at page 1, line 1908
As another example, if a server has received requests to play ranges 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 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
request for NPT=14 would take effect while the server plays the first request for NPT=14 would take effect while the server plays the first
range, with the second range effectively being ignored, assuming the range, with the second range effectively being ignored, assuming the
PAUSE request arrives before the server has started playing the sec- PAUSE request arrives before the server has started playing the sec-
ond, overlapping range. Regardless of when the PAUSE request arrives, ond, overlapping range. Regardless of when the PAUSE request arrives,
it sets the pause point to 14. it sets the pause point to 14.
If the server has already sent data beyond the time specified in the If the server has already sent data beyond the time specified in the
the PAUSE request Range header, a PLAY without range would still the PAUSE request Range header, a PLAY without range would still
resume at that point in time, specified by the pause's range header, resume at that point in time, specified by the PAUSE request's Range
as it is assumed that the client has discarded data after that point. header, as it is assumed that the client has discarded data after
This ensures continuous pause/play cycling without gaps. that point. This ensures continuous pause/play cycling without gaps.
If a client issues a PAUSE request and the server acknowledges and
enters the ready state, the proper server response, if the player
issues another PAUSE, is 200 OK. The 200 OK response MUST include the
Range header with the current pause point, even if the PAUSE request
is asking for some other pause point. See examples below:
Examples:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Session: 12345678
Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 835
Session: 12345678
Range: 86-
S->C: RTSP/1.0 200 OK
CSeq: 835
Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-
11.6 TEARDOWN 11.6 TEARDOWN
The TEARDOWN request stops the stream delivery for the given URI, The TEARDOWN request stops the stream delivery for the given URI,
freeing the resources associated with it. If the URI is the aggre- freeing the resources associated with it. If the URI is the aggre-
gated control URI for this presentation, any RTSP session identifier gated control URI for this presentation, any RTSP session identifier
associated with the session is no longer valid. The use of "*" as URI associated with the session is no longer valid. The use of "*" as URI
in TEARDOWN will also result in that the session is removed indepen- in TEARDOWN will also result in that the session is removed indepen-
dent of the number of medias that was part of it. If the URI in the dent of the number of medias that was part of it. If the URI in the
request was for a media within an aggregated session that media is request was for a media within an aggregated session that media is
skipping to change at page 1, line 2043 skipping to change at page 1, line 2113
case of absolute URLs in the location header the media redirected to case of absolute URLs in the location header the media redirected to
can be either identical, slightly different or totally different. can be either identical, slightly different or totally different.
This is the reason why a new DESCRIBE request SHOULD be issued. This is the reason why a new DESCRIBE request SHOULD be issued.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732 CSeq: 732
Location: rtsp://bigserver.com:8001 Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z- Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
11.10 PING 11.10 PING
This method is a bi-directional mechanism for server or client live- This method is a bi-directional mechanism for server or client live-
ness checking. It has no side effects. The issuer of the request MUST ness checking. It has no side effects. The issuer of the request MUST
include a session header with the session ID of the session that is include a session header with the session ID of the session that is
being checked for liveness. being checked for liveness.
Prior to using this method, an OPTIONS method is RECOMMENDED to be Prior to using this method, an OPTIONS method is RECOMMENDED to be
skipping to change at page 1, line 2086 skipping to change at page 1, line 2155
to interleave RTSP messages and media stream data. This interleaving to interleave RTSP messages and media stream data. This interleaving
should generally be avoided unless necessary since it complicates should generally be avoided unless necessary since it complicates
client and server operation and imposes additional overhead. Also client and server operation and imposes additional overhead. Also
head of line blocking may cause problems. Interleaved binary data head of line blocking may cause problems. Interleaved binary data
SHOULD only be used if RTSP is carried over TCP. SHOULD only be used if RTSP is carried over TCP.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (24 decimal), followed by a one-byte channel identifier, fol- sign (24 decimal), followed by a one-byte channel identifier, fol-
lowed by the length of the encapsulated binary data as a binary, two- lowed by the length of the encapsulated binary data as a binary, two-
byte integer in network byte order. The stream data follows immedi- byte integer in network byte order. The stream data follows immedi-
ately afterwards, without a CRLF, but including the upper-layer ately afterwards, without a CRLF, but including the upper-layer pro-
protocol headers. Each $ block contains exactly one upper-layer pro- tocol headers. Each $ block contains exactly one upper-layer protocol
tocol data unit, e.g., one RTP packet. data unit, e.g., one RTP packet.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 24 | Channel ID | Length in bytes | | "$" = 24 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
skipping to change at page 1, line 2137 skipping to change at page 1, line 2206
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
S->C: RTSP/1.0 200 OK S->C: RTSP/1.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file; RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234 seq=232433;rtptime=972948234
S->C: $000{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $000{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $001{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
12 Status Code Definitions 12 Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 1 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 requests. All listing of which status codes may be returned by which requests. All
error messages, 4xx and 5xx MAY return a body containing further error messages, 4xx and 5xx MAY return a body containing further
information about the error. information about the error.
12.1 Success 1xx 12.1 Success 1xx
skipping to change at page 1, line 2173 skipping to change at page 1, line 2242
processes on the server may be consuming storage space simultane- processes on the server may be consuming storage space simultane-
ously, a client should take this only as an estimate. ously, a client should take this only as an estimate.
12.3 Redirection 3xx 12.3 Redirection 3xx
The notation "3rr" indicates response codes from 300 to 399 inclusive The notation "3rr" indicates response codes from 300 to 399 inclusive
which are meant for redirection. The response code 304 is excluded which are meant for redirection. The response code 304 is excluded
from this set, as it is not used for redirection. from this set, as it is not used for redirection.
See [H10.3] for definition of status code 300 to 305. However com- See [H10.3] for definition of status code 300 to 305. However com-
ments are given for some to how they apply to RTSP. Further a couple ments are given for some to how they apply to RTSP.
of new status codes are defined.
Within RTSP, redirection may be used for load balancing or redirect- Within RTSP, redirection may be used for load balancing or redirect-
ing stream requests to a server topologically closer to the client. ing stream requests to a server topologically closer to the client.
Mechanisms to determine topological proximity are beyond the scope of Mechanisms to determine topological proximity are beyond the scope of
this specification. this specification.
12.3.1 300 Multiple Choices 12.3.1 300 Multiple Choices
12.3.2 301 Moved Permanently 12.3.2 301 Moved Permanently
The request resource are moved permanently and resides now at the URI The request resource are moved permanently and resides now at the URI
given by the location header. The user client SHOULD redirect auto- given by the location header. The user client SHOULD redirect auto-
matically to the given URI. matically to the given URI. This response MUST NOT contain a message-
body.
12.3.3 302 Found 12.3.3 302 Found
The requested resource reside temporarily at the URI given by the The requested resource reside temporarily at the URI given by the
Location header. The Location header MUST be included. Is intended to Location header. The Location header MUST be included in the
be used for many types of temporary redirects, e.g. load balancing. response. Is intended to be used for many types of temporary redi-
It is RECOMMENDED that one set the reason phrase to something more rects, e.g. load balancing. It is RECOMMENDED that one set the reason
meaningful than "Found" in these cases. phrase to something more meaningful than "Found" in these cases. The
user client SHOULD redirect automatically to the given URI. This
response MUST NOT contain a message-body.
12.3.4 303 See Other 12.3.4 303 See Other
This status code SHALL NOT be used in RTSP. However as it was allowed This status code SHALL NOT be used in RTSP. However as it was allowed
to use in RFC 2326 it is possible that such response will be to use in RFC 2326 it is possible that such response may be received.
received.
12.3.5 304 Not Modified 12.3.5 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
12.23) and the requested resource has not been modified, the server 12.23) and the requested resource has not been modified, the server
SHOULD send a 304 response. This response MUST NOT contain a message- SHOULD send a 304 response. This response MUST NOT contain a message-
body. body.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 1, line 2329 skipping to change at page 1, line 2401
12.5 Server Error 5xx 12.5 Server Error 5xx
12.5.1 551 Option not supported 12.5.1 551 Option not supported
An feature-tag given in the Require or the Proxy-Require fields was An feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header SHOULD be returned stating the not supported. The Unsupported header SHOULD be returned stating the
feature for which there is no support. feature for which there is no support.
13 Header Field Definitions 13 Header Field Definitions
The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on syn-
tax, meaning, and usage. Throughout this section, we use [HX.Y] to
refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[26]. Examples of each header field are given.
Information about header fields in relation to methods and proxy pro-
cessing is summarized in Table 4 and Table 5.
The "where" column describes the request and response types in which
the header field can be used. Values in this column are:
method direction object acronym Body method direction object acronym Body
----------------------------------------------- -----------------------------------------------
DESCRIBE C->S P,S DES r DESCRIBE C->S P,S DES r
GET_PARAMETER C->S, S->C P,S GPR R,r GET_PARAMETER C->S, S->C P,S GPR R,r
OPTIONS C->S P,S OPT OPTIONS C->S P,S OPT
S->C S->C
PAUSE C->S P,S PSE PAUSE C->S P,S PSE
PING C->S, S->C P,S PNG PING C->S, S->C P,S PNG
PLAY C->S P,S PLY PLAY C->S P,S PLY
REDIRECT S->C P,S RDR REDIRECT S->C P,S RDR
SETUP C->S S STP SETUP C->S S STP
SET_PARAMETER C->S, S->C P,S SPR R,r SET_PARAMETER C->S, S->C P,S SPR R,r
TEARDOWN C->S P,S TRD TEARDOWN C->S P,S TRD
Table 3: Overview of RTSP methods, their direction, and what objects Table 3: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on syn-
tax, meaning, and usage. Throughout this section, we use [HX.Y] to
refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[26]. Examples of each header field are given.
Information about header fields in relation to methods and proxy pro-
cessing is summarized in Table 4 and Table 5.
The "where" column describes the request and response types in which
the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response codes 2xx, 4xx, etc.: A numerical value or range indicates response codes
with which the header field can be used; with which the header field can be used;
c: header field is copied from the request to the response. c: header field is copied from the request to the response.
An empty entry in the "where" column indicates that the header field An empty entry in the "where" column indicates that the header field
skipping to change at page 1, line 2433 skipping to change at page 1, line 2505
ble quotas ("). Any URI parameters are contained within these quotas. ble quotas ("). Any URI parameters are contained within these quotas.
If the URI is not enclosed in double quotas, any semicolon- delimited If the URI is not enclosed in double quotas, any semicolon- delimited
parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
13.1 Accept 13.1 Accept
The Accept request-header field can be used to specify certain pre- The Accept request-header field can be used to specify certain pre-
sentation description content types which are acceptable for the sentation description content types which are acceptable for the
response. response.
The "level" parameter for presentation descriptions is prop-
erly defined as part of the MIME type registration, not here.
See [H14.1] for syntax.
Example of use:
Accept: application/rtsl q=1.0, application/sdp;level=2
13.2 Accept-Encoding
See [H14.3]
13.3 Accept-Language
See [H14.4]. Note that the language specified applies to the presen-
tation description and any reason phrases, not the media content.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
-------------------------------------------------------------- --------------------------------------------------------------
Accept R o - - - - - Accept R o - - - - -
Accept-Encoding R r o - - - - - Accept-Encoding R r o - - - - -
Accept-Language R r o - - - - - Accept-Language R r o - - - - -
Accept-Ranges r r - - o - - - Accept-Ranges r r - - o - - -
Accept-Ranges 456 r - - - o o - Accept-Ranges 456 r - - - o o -
Allow r - o - - - - Allow r - o - - - -
Allow 405 - - - m m - Allow 405 - - - m m -
Authorization R o o o o o o Authorization R o o o o o o
skipping to change at page 1, line 2493 skipping to change at page 1, line 2547
Host o o o o o o Host o o o o o o
If-Match R r - - o - - - If-Match R r - - o - - -
If-Modified-Since R r o - o - - - If-Modified-Since R r o - o - - -
Last-Modified r r o - - - - - Last-Modified r r o - - - - -
Location 3rr o o o o o o Location 3rr o o o o o o
Proxy-Authenticate 407 amr m m m m m m Proxy-Authenticate 407 amr m m m m m m
Proxy-Require R ar o o o o o o Proxy-Require R ar o o o o o o
Public r admr - m* - - - - Public r admr - m* - - - -
Public 501 admr m* m* m* m* m* m* Public 501 admr m* m* m* m* m* m*
Range R - - - o o - Range R - - - o o -
Range r - - c m* - - Range r - - c m* m* -
Referer R o o o o o o Referer R o o o o o o
Require R o o o o o o Require R o o o o o o
Retry-After 3rr,503 o o o - - - Retry-After 3rr,503 o o o - - -
RTP-Info r - - o m - - RTP-Info r - - o m - -
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
----------------------------------------------------------
Scale - - - o - - Scale - - - o - -
Session R - o o m m m Session R - o o m m m
Session r - c m m m o Session r - c m m m o
Server R - o - - - - Server R - o - - - -
Server r o o o o o o Server r o o o o o o
Speed - - - o - - Speed - - - o - -
Supported R o o o o o o Supported R o o o o o o
Supported r c c c c c c Supported r c c c c c c
Timestamp R o o o o o o Timestamp R o o o o o o
Timestamp c m m m m m m Timestamp c m m m m m m
Transport - - m - - - Transport - - m - - -
Unsupported r c c c c c c Unsupported r c c c c c c
User-Agent R m* m* m* m* m* m* User-Agent R m* m* m* m* m* m*
Vary r c c c c c c Vary r c c c c c c
Via R amr o o o o o o Via R amr o o o o o o
Via c dr m m m m m m Via c dr m m m m m m
WWW-Authenticate 401 m m m m m m WWW-Authenticate 401 m m m m m m
-------------------------------------------------------------- ----------------------------------------------------------
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
Table 4: Overview of RTSP header fields related to methods DESCRIBE, Table 4: Overview of RTSP header fields related to methods DESCRIBE,
OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
13.4 Accept-Ranges The "level" parameter for presentation descriptions is prop-
erly defined as part of the MIME type registration, not here.
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests and possible formats for a resource: |
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges || See [H14.1] for syntax.
acceptable-ranges = 1#range-unit / "none" ||
range-unit = NPT / SMPTE / UTC / LIVE / extension-format ||
extension-format = token ||
This header has the same syntax as [H14.5]. However new range-units Example of use:
are defined and byte-ranges SHALL NOT be used. Inclusion of any of
the three time formats indicates acceptance by the server for PLAY
and PAUSE requests with this format. Inclusion of the "LIVE" tag
indicates that the resource has LIVE properties. The headers value is
valid for the resource specified by the URI in the request, this
response corresponds to.
Accept: application/rtsl q=1.0, application/sdp;level=2
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR PNG
----------------------------------------------------- -----------------------------------------------------
Allow 405 - - - - Allow 405 - - - -
Authorization R o o o o Authorization R o o o o
Bandwidth R - o - - Bandwidth R - o - -
Blocksize R - o - - Blocksize R - o - -
Connection o o o - Connection o o o -
Content-Base R o o - - Content-Base R o o - -
Content-Base r o o - - Content-Base r o o - -
Content-Base 4xx o o o - Content-Base 4xx o o o -
skipping to change at page 1, line 2601 skipping to change at page 1, line 2647
Vary r c c - - Vary r c c - -
Via R amr o o o o Via R amr o o o o
Via c dr m m m m Via c dr m m m m
WWW-Authenticate 401 m m m m WWW-Authenticate 401 m m m m
----------------------------------------------------- -----------------------------------------------------
Header Where Proxy GPR SPR RDR PNG Header Where Proxy GPR SPR RDR PNG
Table 5: Overview of RTSP header fields related to methods GET_PARAM- Table 5: Overview of RTSP header fields related to methods GET_PARAM-
ETER, SET_PARAMETER,REDIRECT, and PING. ETER, SET_PARAMETER,REDIRECT, and PING.
13.2 Accept-Encoding
See [H14.3]
13.3 Accept-Language
See [H14.4]. Note that the language specified applies to the presen-
tation description and any reason phrases, not the media content.
13.4 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests and possible formats for a resource: |
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges ||
acceptable-ranges = 1#range-unit / "none" ||
range-unit = NPT / SMPTE / UTC / LIVE / extension-format ||
extension-format = token ||
This header has the same syntax as [H14.5]. However new range-units
are defined and byte-ranges SHALL NOT be used. Inclusion of any of
the three time formats indicates acceptance by the server for PLAY
and PAUSE requests with this format. Inclusion of the "LIVE" tag
indicates that the resource has LIVE properties. The headers value is
valid for the resource specified by the URI in the request, this
response corresponds to.
A server is RECOMMENDED to use this header in SETUP responses to A server is RECOMMENDED to use this header in SETUP responses to
indicate to the client which range time formats the media supports. indicate to the client which range time formats the media supports.
The header SHOULD also be included in "456" responses which is a The header SHOULD also be included in "456" responses which is a
result of use of unsupported range formats. result of use of unsupported range formats.
13.5 Allow 13.5 Allow
The Allow entity-header field lists the methods supported by the The Allow entity-header field lists the methods supported by the
resource identified by the request-URI. The purpose of this field is resource identified by the request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
skipping to change at page 1, line 2996 skipping to change at page 1, line 3069
the client (i.e., the nearest neighbor in a chain of connections). the client (i.e., the nearest neighbor in a chain of connections).
If the response passes through a proxy, the proxy MUST either remove If the response passes through a proxy, the proxy MUST either remove
the Public header field or replace it with one applicable to its own the Public header field or replace it with one applicable to its own
capabilities. capabilities.
13.29 Range 13.29 Range
The Range request and response header field specifies a range of The Range request and response header field specifies a range of
time. The range can be specified in a number of units. This specifi- time. The range can be specified in a number of units. This specifi-
cation defines the smpte (Section 3.4), npt (Section 3.5), and clock cation defines the smpte (Section 3.4), npt (Section 3.5), and clock
(Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are (Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are |
not meaningful and MUST NOT be used. The header may also contain a normally not meaningful. The header MAY contain a time parameter in |
time parameter in UTC, specifying the time at which the operation is UTC, specifying the time at which the operation is to be made |
to be made effective. Servers supporting the Range header MUST under- effective. This functionality SHALL only be used with the REDIRECT |
stand the NPT range format and SHOULD understand the SMPTE range for- method. Servers supporting the Range header MUST understand the NPT
mat. The Range response header indicates what range of time is actu- range format and SHOULD understand the SMPTE range format. The Range
ally being played. If the Range header is given in a time format that response header indicates what range of time is actually being
is not understood, the recipient should return 501 (Not Implemented). played. If the Range header is given in a time format that is not
understood, the recipient should return 501 (Not Implemented).
Ranges are half-open intervals, including the lower point, but Ranges are half-open intervals, including the first point, but
excluding the upper point. In other words, a range of a-b starts excluding the second point. In other words, a range of A-B starts
exactly at time a, but stops just before b. Only the start time of a exactly at time A, but stops just before B. Only the start time of a
media unit such as a video or audio frame is relevant. As an example, media unit such as a video or audio frame is relevant. As an example,
assume that video frames are generated every 40 ms. A range of assume that video frames are generated every 40 ms. A range of
10.0-10.1 would include a video frame starting at 10.0 or later time 10.0-10.1 would include a video frame starting at 10.0 or later time
and would include a video frame starting at 10.08, even though it and would include a video frame starting at 10.08, even though it
lasted beyond the interval. A range of 10.0-10.08, on the other hand, lasted beyond the interval. A range of 10.0-10.08, on the other hand,
would exclude the frame at 10.08. would exclude the frame at 10.08.
Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ] Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range / utc-range / smpte-range ranges-specifier = npt-range / utc-range / smpte-range
skipping to change at page 1, line 3030 skipping to change at page 1, line 3104
Range: clock=19960213T143205Z-;time=19970123T143720Z Range: clock=19960213T143205Z-;time=19970123T143720Z
The notation is similar to that used for the HTTP/1.1 [26] The notation is similar to that used for the HTTP/1.1 [26]
byte-range header. It allows clients to select an excerpt from byte-range header. It allows clients to select an excerpt from
the media object, and to play from a given point to the end as the media object, and to play from a given point to the end as
well as from the current location to a given point. The start well as from the current location to a given point. The start
of playback can be scheduled for any time in the future, of playback can be scheduled for any time in the future,
although a server may refuse to keep server resources for although a server may refuse to keep server resources for
extended idle periods. extended idle periods.
By default, range intervals increase, where the second point is
larger than the first point.
Example:
Range: npt=10-15
However, range intervals can also decrease if the Scale header (see
section 13.34) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired.
Example:
Scale: -1
Range: npt=15-10
Decreasing ranges are still half open intervals as described above.
Thus, For range A-B, A is closed and B is open. In the above example,
15 is closed and 10 is open. An exception to this rule is the case
when B=0 in a decreasing range. In this case, the range is closed on
both ends, as otherwise there would be no way to reach 0 on a reverse
playback.
Example:
Scale: -1
Range: npt=15-0
In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale
header is not valid.
13.30 Referer 13.30 Referer
See [H14.36]. The URL refers to that of the presentation description, See [H14.36]. The URL refers to that of the presentation description,
typically retrieved via HTTP. typically retrieved via HTTP.
13.31 Retry-After 13.31 Retry-After
See [H14.37]. See [H14.37].
13.32 Require 13.32 Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however the use of the other end-point supports certain features, however the use of the
Supported (Section 13.38) is much more effective in this purpose. Supported (Section 13.38) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response SHALL use the error code 551 (Option Not Sup- supported. The response SHALL use the error code 551 (Option Not Sup-
ported). This header does not apply to proxies, for the same func- ported). This header does not apply to proxies, for the same
tionality in respect to proxies see, header Proxy-Require (Section functionality in respect to proxies see, header Proxy-Require (Sec-
13.27). tion 13.27).
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as sides, and only slow down if features are not understood (as
in the example below). For a well-matched client-server pair, in the example below). For a well-matched client-server pair,
the interaction proceeds quickly, saving a round-trip often the interaction proceeds quickly, saving a round-trip often
required by negotiation mechanisms. In addition, it also required by negotiation mechanisms. In addition, it also
removes state ambiguity when the client requires features that removes state ambiguity when the client requires features that
the server does not understand. the server does not understand.
skipping to change at page 1, line 3099 skipping to change at page 1, line 3206
are not understood in this field. If a particular extension requires are not understood in this field. If a particular extension requires
that intermediate devices support it, the extension should be tagged that intermediate devices support it, the extension should be tagged
in the Proxy-Require field instead (see Section 13.27). in the Proxy-Require field instead (see Section 13.27).
13.33 RTP-Info 13.33 RTP-Info
The RTP-Info response-header field is used to set RTP-specific param- The RTP-Info response-header field is used to set RTP-specific param-
eters in the PLAY response. For streams using RTP as transport proto- eters in the PLAY response. For streams using RTP as transport proto-
col the RTP-Info header SHALL be part of a 200 response to PLAY. col the RTP-Info header SHALL be part of a 200 response to PLAY.
The RTP-Info response-header field is used to set RTP-specific param-
eters in the PLAY response. These parameters correspond to the syn-
chronization source identified by the ssrc parameter of the Transport
response header in the SETUP reponse. For streams using RTP as trans-
port protocol the RTP-Info header SHALL be part of a 200 response to
PLAY.
url: Indicates the stream URL which for which the following RTP url: Indicates the stream URL which for which the following RTP
parameters correspond, this URL MUST be the same used in the parameters correspond, this URL MUST be the same used in the
SETUP request for this media stream. Any relative URL SHALL SETUP request for this media stream. Any relative URL SHALL
use the request URL as base URL. use the request URL as base URL.
seq: Indicates the sequence number of the first packet of the seq: Indicates the sequence number of the first packet of the
stream. This allows clients to gracefully deal with packets stream. This allows clients to gracefully deal with packets
when seeking. The client uses this value to differentiate when seeking. The client uses this value to differentiate
packets that originated before the seek from packets that packets that originated before the seek from packets that
originated after the seek. originated after the seek.
rtptime: Indicates the RTP timestamp corresponding to the time rtptime: Indicates the RTP timestamp corresponding to the time
value in the Range response header. (Note: For aggregate con- value in the Range response header. (Note: For aggregate con-
trol, a particular stream may not actually generate a packet trol, a particular stream may not actually generate a packet
for the Range time value returned or implied. Thus, there is for the Range time value returned or implied. Thus, there is
no guarantee that the packet with the sequence number no guarantee that the packet with the sequence number indi-
indicated by seq actually has the timestamp indicated by rtp- cated by seq actually has the timestamp indicated by rtptime.)
time.) The client uses this value to calculate the mapping of The client uses this value to calculate the mapping of RTP
RTP time to NPT. time to NPT.
A mapping from RTP timestamps to NTP timestamps (wall A mapping from RTP timestamps to NTP timestamps (wall
clock) is available via RTCP. However, this information clock) is available via RTCP. However, this information
is not sufficient to generate a mapping from RTP times- is not sufficient to generate a mapping from RTP times-
tamps to NPT. Furthermore, in order to ensure that this tamps to NPT. Furthermore, in order to ensure that this
information is available at the necessary time (immedi- information is available at the necessary time (immedi-
ately at startup or after a seek), and that it is deliv- ately at startup or after a seek), and that it is deliv-
ered reliably, this mapping is placed in the RTSP control ered reliably, this mapping is placed in the RTSP control
channel. channel.
In order to compensate for drift for long, uninterrupted pre- In order to compensate for drift for long, uninterrupted pre-
sentations, RTSP clients should additionally map NPT to NTP, sentations, RTSP clients should additionally map NPT to NTP,
using initial RTCP sender reports to do the mapping, and later using initial RTCP sender reports to do the mapping, and later
reports to check drift against the mapping. reports to check drift against the mapping.
Additionally, the RTP-Info header parameter fields only apply to a
single SSRC within a stream (the SSRC reported in the transport
response header; see section 13.40). If there are multiple synchro-
nization sources present within a RTP session, RTCP must be used to
map RTP and NTP timestamps for those sources, for both synchroniza-
tion and drift-checking.
Syntax: Syntax:
RTP-Info = "RTP-Info" ":" 1#rtsp-info-spec RTP-Info = "RTP-Info" ":" 1#rtsp-info-spec
rtsp-info-spec = stream-url 1*parameter rtsp-info-spec = stream-url 1*parameter
stream-url = quoted-url / unquoted-url stream-url = quoted-url / unquoted-url
unquoted-url = "url" "=" safe-url unquoted-url = "url" "=" safe-url
/ ";" "mode" = <"> 1#Method <">
quoted-url = "url" "=" <"> needquote-url <"> quoted-url = "url" "=" <"> needquote-url <">
safe-url = url safe-url = url
needquote-url = url //That contains ; or , needquote-url = url //That contains ; or ,
url = ( absoluteURI / relativeURI ) url = ( absoluteURI / relativeURI )
parameter = ";" "seq" "=" 1*DIGIT parameter = ";" "seq" "=" 1*DIGIT
/ ";" "rtptime" "=" 1*DIGIT / ";" "rtptime" "=" 1*DIGIT
Additional constraint: safe-url MUST NOT contain the semicolon (";") Additional constraint: safe-url MUST NOT contain the semicolon (";")
or comma (",") characters. The quoted-url form SHOULD only be used or comma (",") characters. The quoted-url form SHOULD only be used
when a URL does not meet the safe-url constraint, in order to ensure when a URL does not meet the safe-url constraint, in order to ensure
skipping to change at page 1, line 3189 skipping to change at page 1, line 3309
restrict the range of scale values that it supports. The response restrict the range of scale values that it supports. The response
MUST contain the actual scale value chosen by the server. MUST contain the actual scale value chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY SHALL indicate this with the use of the "play.scale" feature- PLAY SHALL indicate this with the use of the "play.scale" feature-
tags. tags.
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
When indicating a negative scale for a reverse playback, the Range
header must indicate a decreasing range as described in section
13.29.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5 Scale: -3.5
Range: npt=15-10
13.35 Speed 13.35 Speed
The Speed request-header field requests the server to deliver data to The Speed request-header field requests the server to deliver data to
the client at a particular speed, contingent on the server's ability the client at a particular speed, contingent on the server's ability
and desire to serve the media stream at the given speed. Implementa- and desire to serve the media stream at the given speed. Implementa-
tion by the server is OPTIONAL. The default is the bit rate of the tion by the server is OPTIONAL. The default is the bit rate of the
stream. stream.
The parameter value is expressed as a decimal ratio, e.g., a value of The parameter value is expressed as a decimal ratio, e.g., a value of
skipping to change at page 1, line 3426 skipping to change at page 1, line 3552
preferred that this authorization be performed by the recipi- preferred that this authorization be performed by the recipi-
ent itself and the credentials passed along to the server. ent itself and the credentials passed along to the server.
However, in certain cases, such as when recipient address is a However, in certain cases, such as when recipient address is a
multicast group, or when the recipient is unable to communi- multicast group, or when the recipient is unable to communi-
cate with the server in an out-of-band manner, this may not be cate with the server in an out-of-band manner, this may not be
possible. In these cases server may chose another method such possible. In these cases server may chose another method such
as a server-resident authorization list to ensure that the as a server-resident authorization list to ensure that the
request originator has the proper credentials to request request originator has the proper credentials to request
stream delivery to the recipient. stream delivery to the recipient.
IPv6 addresses are RECOMMENDED to be given as fully qualified This parameter SHALL NOT be used when src_addr and dst_addr is |
domain to make it backwards compatible with RFC 2326 used in a transport declaration. IPv6 addresses are RECOM- |
implementations. MENDED to be given as fully qualified domain to make it back- |
wards compatible with RFC 2326 implementations. |
source: If the source address for the stream is different than can source: If the source address for the stream is different than can |
be derived from the RTSP endpoint address (the server in play- be derived from the RTSP endpoint address (the server in play- |
back), the source address SHOULD be specified. To maintain back), the source address SHOULD be specified. To maintain |
backwards compatibility with RFC 2326, any IPv6 host's address backwards compatibility with RFC 2326, any IPv6 host's address |
must be given as a fully qualified domain name. must be given as a fully qualified domain name. This |
parameter SHALL NOT be used when src_addr and dst_addr is used |
in a transport declaration.
This information may also be available through SDP. How- This information may also be available through SDP. How-
ever, since this is more a feature of transport than ever, since this is more a feature of transport than
media initialization, the authoritative source for this media initialization, the authoritative source for this
information should be in the SETUP response. information should be in the SETUP response.
layers: The number of multicast layers to be used for this media layers: The number of multicast layers to be used for this media
stream. The layers are sent to consecutive addresses starting stream. The layers are sent to consecutive addresses starting
at the destination address. at the destination address.
dest_addresses: A general destination address parameter that can | dest_addr: A general destination address parameter that can contain |
contain one or more address and port pair. For each combina- | one or more address and port pair. For each combination of |
tion of Protocol/Profile/Lower Transport the interpretation of | Protocol/Profile/Lower Transport the interpretation of the |
the address or addresses needs to be defined. The client or | address or addresses needs to be defined. The client or server |
server SHALL NOT use this parameter unless both client and | SHALL NOT use this parameter unless both client and server has |
server has shown support. This parameter MUST be supported by | shown support. This parameter MUST be supported by client and |
client and servers that implements this specification. Support | servers that implements this specification. Support is indi- |
is indicated by the use of the feature-tag "play.basic". This | cated by the use of the feature-tag "play.basic". This parame- |
parameter SHALL NOT be used in the same transport specifica- | ter SHALL NOT be used in the same transport specification as |
tion as any of the parameters "destination", "source", "port", | any of the parameters "destination", "source", "port", |
"client_port", and "server_port". | "client_port", and "server_port". |
The same security consideration that are given for the "Desti- | The same security consideration that are given for the "Desti- |
nation" parameter does also applies to this parameter. This | nation" parameter does also applies to this parameter. This |
parameter can be used for redirecting traffic to recipient not | parameter can be used for redirecting traffic to recipient not |
desiring the media traffic. | desiring the media traffic. |
src_addresses: A General source address parameter that can contain | src_addr: A General source address parameter that can contain one |
one or more address and port pair. For each combination of | or more address and port pair. For each combination of Proto- |
Protocol/Profile/Lower Transport the interpretation of the | col/Profile/Lower Transport the interpretation of the address |
address or addresses needs to be defined. The client or server | or addresses needs to be defined. The client or server SHALL |
SHALL NOT use this parameter unless both client and server has | NOT use this parameter unless both client and server has shown |
shown support. This parameter MUST be supported by client and | support. This parameter MUST be supported by client and |
servers that implements this specification. Support is indi- | servers that implements this specification. Support is indi- |
cated by the use the feature-tag "play.basic". This parameter | cated by the use the feature-tag "play.basic". This parameter |
SHALL NOT be used in the same transport specification as any | SHALL NOT be used in the same transport specification as any |
of the parameters "destination", "source", "port", | of the parameters "destination", "source", "port", |
"client_port", and "server_port". | "client_port", and "server_port". |
The address or addresses indicated in the src_addresses param- |
eter SHOULD be used both for sending and receiving of the | The address or addresses indicated in the src_addr parameter |
media streams data packet. The main reasons are two: First by | SHOULD be used both for sending and receiving of the media |
sending from the indicated ports the source address will be | streams data packet. The main reasons are two: First by send- |
known by the receiver of the packet. Secondly, in the presence | ing from the indicated ports the source address will be known |
of NATs some traversal mechanism requires either knowledge | by the receiver of the packet. Secondly, in the presence of |
from which address and port a packet flow is coming, or having | NATs some traversal mechanism requires either knowledge from |
the possibility to send data to the sender port. which address and port a packet flow is coming, or having the |
possibility to send data to the sender port.
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not pro- this session. Valid values are PLAY and RECORD. If not pro-
vided, the default is PLAY. The RECORD value was defined in vided, the default is PLAY. The RECORD value was defined in
RFC 2326 and is deprecated in this specification. RFC 2326 and is deprecated in this specification.
append: The append parameter was used together with RECORD and is append: The append parameter was used together with RECORD and is
now deprecated. now deprecated.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
skipping to change at page 1, line 3522 skipping to change at page 1, line 3652
ttl: multicast time-to-live. ttl: multicast time-to-live.
RTP-specific: RTP-specific:
These parameters are MAY only be used if the media transport protocol These parameters are MAY only be used if the media transport protocol
is RTP. is RTP.
port: This parameter provides the RTP/RTCP port pair for a multi- port: This parameter provides the RTP/RTCP port pair for a multi-
cast session. It is should be specified as a range, e.g., cast session. It is should be specified as a range, e.g.,
port=3456-3457 port=3456-3457
client_port: This parameter provides the unicast RTP/RTCP port pair |
on the client where media data and control information is to |
be sent. It is specified as a range, e.g., port=3456-3457 is |
used in a transport declaration. |
client_port: This parameter provides the unicast RTP/RTCP port pair server_port: This parameter provides the unicast RTP/RTCP port pair |
on the client where media data and control information is to on the server where media data and control information is to |
be sent. It is specified as a range, e.g., port=3456-3457 be sent. It is specified as a range, e.g., port=3456-3457 is |
used in a transport declaration.
server_port: This parameter provides the unicast RTP/RTCP port pair
on the server where media data and control information is to
be sent. It is specified as a range, e.g., port=3456-3457
ssrc: The ssrc parameter indicates the RTP SSRC [23] value that ssrc: The ssrc parameter, if included in a SETUP response, indi-
should be (request) or will be (response) used by the media cates the RTP SSRC [23] value that will be used by the media
server. This parameter is only valid for unicast transmission. server for RTP packets within the stream. It is expressed as
It identifies the synchronization source to be associated with an eight digit hexadecimal value. If the server does not act
the media stream, and is expressed as an eight digit hexideci- as a synchronization source for stream data (for instance,
mal value. In cases that a sender will use multiple SSRCs it server is a translator, reflector, etc.) the value will be the
SHOULD NOT use this parameter. "packet sender's SSRC" that would have been used in the RTCP
Receiver Reports generated by the server, regardless of
whether the server actually generates RTCP RRs. If there are
multiple sources within the stream, the ssrc parameter only
indicates the value for a single synchronization source. Other
sources must be deduced from the actual RTP/RTCP stream.
client_ssrc: The client_ssrc parameter indicates the RTP SSRC [23] The functionality of specifying the ssrc parameter in a SETUP
value that will be used by the client. This parameter is only request is deprecated as it is incompatible with the specifi-
valid for unicast transmission. It identifies the synchroniza- cation of RTP in RFC 1889. If the parameter is included in the
tion source to be associated with the media stream, and is transport header of a SETUP request, the server MAY ignore the
expressed as an eight digit hexidecimal value. In cases that a it, and choose an appropriate SSRC for the stream. It MAY set
client will use multiple SSRCs it SHOULD NOT use this parame- the ssrc parameter in the transport header of the response.
ter.
Transport = "Transport" ":" 1#transport-spec || Transport = "Transport" ":" 1#transport-spec ||
transport-spec = transport-id *parameter || transport-spec = transport-id *parameter ||
transport-id = transport-protocol "/" profile ["/" lower-transport]|| transport-id = transport-protocol "/" profile ["/" lower-transport]||
; no LWS is allowed inside transport-id || ; no LWS is allowed inside transport-id ||
transport-protocol = "RTP" / token || transport-protocol = "RTP" / token ||
profile = "AVP" / token || profile = "AVP" / token ||
lower-transport = "TCP" / "UDP" / token || lower-transport = "TCP" / "UDP" / token ||
parameter = ";" ( "unicast" / "multicast" ) || parameter = ";" ( "unicast" / "multicast" ) ||
/ ";" "source" "=" host || / ";" "source" "=" host ||
/ ";" "destination" [ "=" host ] || / ";" "destination" [ "=" host ] ||
/ ";" "interleaved" "=" channel [ "-" channel ]|| / ";" "interleaved" "=" channel [ "-" channel ]||
/ ";" "append" || / ";" "append" ||
/ ";" "ttl" "=" ttl || / ";" "ttl" "=" ttl ||
/ ";" "layers" "=" 1*DIGIT || / ";" "layers" "=" 1*DIGIT ||
/ ";" "port" "=" port-spec || / ";" "port" "=" port-spec ||
/ ";" "client_port" "=" port-spec || / ";" "client_port" "=" port-spec ||
/ ";" "server_port" "=" port-spec || / ";" "server_port" "=" port-spec ||
/ ";" "ssrc" "=" ssrc || / ";" "ssrc" "=" ssrc ||
/ ";" "client_ssrc" "=" ssrc ||
/ ";" "mode" "=" mode-spec || / ";" "mode" "=" mode-spec ||
/ ";" "dest_addresses" "=" addr-list || / ";" "dest_addr" "=" addr-list ||
/ ";" "src_addresses" "=" addr-list || / ";" "src_addr" "=" addr-list ||
/ ";" trn-parameter-extension || / ";" trn-parameter-extension ||
port-spec = port [ "-" port ] || port-spec = port [ "-" port ] ||
trn-parameter-extension = par-name "=" trn-par-value || trn-parameter-extension = par-name "=" trn-par-value ||
par-name = token || par-name = token ||
trn-par-value = *unreserved || trn-par-value = *unreserved ||
ttl = 1*3(DIGIT) || ttl = 1*3(DIGIT) ||
ssrc = 8*8(HEX) || ssrc = 8*8(HEX) ||
channel = 1*3(DIGIT) || channel = 1*3(DIGIT) ||
mode-spec = <"> 1#mode <"> / mode || mode-spec = <"> 1#mode <"> / mode ||
mode = "PLAY" / "RECORD" / token || mode = "PLAY" / "RECORD" / token ||
skipping to change at page 1, line 3652 skipping to change at page 1, line 3786
cantly in that respect. Responses are not cacheable, with the excep- | cantly in that respect. Responses are not cacheable, with the excep- |
tion of the presentation description returned by DESCRIBE. (Since the | tion of the presentation description returned by DESCRIBE. (Since the |
responses for anything but DESCRIBE and GET_PARAMETER do not return | responses for anything but DESCRIBE and GET_PARAMETER do not return |
any data, caching is not really an issue for these requests.) How- | any data, caching is not really an issue for these requests.) How- |
ever, it is desirable for the continuous media data, typically deliv- | ever, it is desirable for the continuous media data, typically deliv- |
ered out-of-band with respect to RTSP, to be cached, as well as the | ered out-of-band with respect to RTSP, to be cached, as well as the |
session description. session description.
On receiving a SETUP or PLAY request, a proxy ascertains whether it On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by issu- description. It can determine whether the copy is up-to-date by
ing a SETUP or DESCRIBE request, respectively, and comparing the issuing a SETUP or DESCRIBE request, respectively, and comparing the
Last-Modified header with that of the cached copy. If the copy is not Last-Modified header with that of the cached copy. If the copy is not
up-to-date, it modifies the SETUP transport parameters as appropriate up-to-date, it modifies the SETUP transport parameters as appropriate
and forwards the request to the origin server. Subsequent control and forwards the request to the origin server. Subsequent control
commands such as PLAY or PAUSE then pass the proxy unmodified. The commands such as PLAY or PAUSE then pass the proxy unmodified. The
proxy delivers the continuous media data to the client, while possi- proxy delivers the continuous media data to the client, while possi-
bly making a local copy for later reuse. The exact behavior allowed bly making a local copy for later reuse. The exact behavior allowed
to the cache is given by the cache-response directives described in to the cache is given by the cache-response directives described in
Section 13.9. A cache MUST answer any DESCRIBE requests if it is cur- Section 13.9. A cache MUST answer any DESCRIBE requests if it is cur-
rently serving the stream to the requestor, as it is possible that rently serving the stream to the requestor, as it is possible that
low-level details of the stream description may have changed on the low-level details of the stream description may have changed on the
skipping to change at page 1, line 4394 skipping to change at page 1, line 4526
and entry points and MAY arbitrarily disconnect and ignore and entry points and MAY arbitrarily disconnect and ignore
further requests clients which are deemed to be in violation further requests clients which are deemed to be in violation
of local security policy. of local security policy.
18 IANA Considerations 18 IANA Considerations
This section set up a number of registers for RTSP that should be This section set up a number of registers for RTSP that should be
maintained by IANA. For each registry there is a description on what maintained by IANA. For each registry there is a description on what
it shall contain, what specification is needed when adding a entry it shall contain, what specification is needed when adding a entry
with IANA, and finally the entries that this document needs to regis- with IANA, and finally the entries that this document needs to regis-
ter. See also the section 1.6 "Extending RTSP". ter. See also the section 1.6 "Extending RTSP". There is also a IANA
registration of two SDP attributes.
The sections describing how to register an item uses some of the The sections describing how to register an item uses some of the
requirements level described in RFC 2434 [29], namely " First Come, requirements level described in RFC 2434 [29], namely " First Come,
First Served", "Specification Required", and "Standards Action". First Served", "Specification Required", and "Standards Action".
A registration request to IANA MUST contain the following informa- A registration request to IANA MUST contain the following informa-
tion: tion:
+ A name of the item to register according to the rules specified + A name of the item to register according to the rules specified
by the intended registry. by the intended registry.
+ Indication of who has change control over the feature (for exam- + Indication of who has change control over the feature (for exam-
ple, IETF, ISO, ITU-T, other international standardization bod- ple, IETF, ISO, ITU-T, other international standardization
ies, a consortium or a particular company or group of companies); bodies, a consortium or a particular company or group of compa-
nies);
+ A reference to a further description, if available, for example + A reference to a further description, if available, for example
(in order of preference) an RFC, a published standard, a pub- (in order of preference) an RFC, a published standard, a pub-
lished paper, a patent filing, a technical report, documented lished paper, a patent filing, a technical report, documented
source code or a computer manual; source code or a computer manual;
+ For proprietary features, contact information (postal and email + For proprietary features, contact information (postal and email
address); address);
18.1 Feature-tags 18.1 Feature-tags
skipping to change at page 1, line 4667 skipping to change at page 1, line 4799
+ Registering requires a IETF standard tracks document. + Registering requires a IETF standard tracks document.
+ A registration shall name a contact person. + A registration shall name a contact person.
+ Name of the directive and a definition of the value, if any. + Name of the directive and a definition of the value, if any.
+ A describing text that explains how the cache directive is used + A describing text that explains how the cache directive is used
for RTSP controlled media streams. for RTSP controlled media streams.
18.7 SDP attributes
This specification defines two SDP [24] attributes that it is request
that IANA register.
SDP Attribute ("att-field"):
Attribute name: range
Long form: Media Range Attribute
Type of name: att-field
Type of attribute: Media and session level
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: See ABNF definition.
Attribute name: control
Long form: RTSP control URL
Type of name: att-field
Type of attribute: Media and session level
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: Absolute or Relative URLs.
A RTSP Protocol State Machine A RTSP Protocol State Machine
The RTSP session state machine describe the behavior of the protocol The RTSP session state machine describe the behavior of the protocol
from RTSP session initialization through RTSP session termination. from RTSP session initialization through RTSP session termination.
State machine is defined on a per session basis which is uniquely State machine is defined on a per session basis which is uniquely
identified by the RTSP session identifier. The session may contain identified by the RTSP session identifier. The session may contain
zero or more media streams depending on state. If a single media zero or more media streams depending on state. If a single media
stream is part of the session it is in non-aggregated control. If two stream is part of the session it is in non-aggregated control. If two
or more is part of the session it is in aggregated control. or more is part of the session it is in aggregated control.
skipping to change at page 1, line 4798 skipping to change at page 1, line 4955
Table 7: State: Init Table 7: State: Init
The initial state of the state machine, see Table 7 can only be left The initial state of the state machine, see Table 7 can only be left
by processing a correct SETUP request. As seen in the table the two by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another shows that a correct SETUP can in some cases be redirected to another
URL and/or server by a 3rr response. URL and/or server by a 3rr response.
Action Requisite New State Response Action Requisite New State Response
---------------------------------------------------------- --------------------------------------------------------------
SETUP Ready NRM=1,RP=0.0 SETUP Ready NRM=1,RP=0.0
SETUP Needs Redirect Init 3rr SETUP Needs Redirect Init 3rr
TEARDOWN URL=* Init No session hdr. TEARDOWN URL=* Init No session hdr.
Timeout Init Timeout Init
S->C:REDIRECT Range hdr Ready-nm Set RedP S->C:REDIRECT Range hdr Ready-nm Set RedP
S->C:REDIRECT no range hdr Init S->C:REDIRECT no range hdr Ready-nm TEARDOWN of session
RedP reached Init RedP reached Ready-nm TEARDOWN of session
Table 8: State: Ready-nm Table 8: State: Ready-nm
The optional Ready-nm state has no media streams and therefore can't | The optional Ready-nm state has no media streams and therefore can't |
play. This state exist so that all session related parameters and | play. This state exist so that all session related parameters and |
resources can be kept while changing media stream(s). As seen in | resources can be kept while changing media stream(s). As seen in |
Table 8 the operations are limited to setting up a new media or tear- | Table 8 the operations are limited to setting up a new media or tear- |
ing down the session. The established session can also be redirected | ing down the session. The established session can also be redirected |
with the REDIRECT method. with the REDIRECT method.
In the Ready state, see Table 9, some of the actions are depending on
the number of media streams (NRM) in the session, i.e. aggregated or
non-aggregated control. A setup request in the ready state can either
add one more media stream to the session or if the media stream (same
URL) already is part of the session change the transport parameters.
TEARDOWN is depending on both the request URI and the number of media
stream within the session. If the request URI is either * or the pre-
sentations URI the whole session is torn down. If a media URL is used
in the TEARDOWN request and more than one media exist in the session,
the session will remain and a session header MUST be returned in the
Action Requisite New State Response Action Requisite New State Response
--------------------------------------------------------------------- ---------------------------------------------------------------------
SETUP New URL Ready NRM+=1 SETUP New URL Ready NRM+=1
SETUP Setten up URL Ready Change transport param. SETUP Setten up URL Ready Change transport param.
TEARDOWN URL=* Init No session hdr TEARDOWN URL=* Init No session hdr
TEARDOWN Prs URL,NRM>1 Init No session hdr TEARDOWN Prs URL,NRM>1 Init No session hdr
TEARDOWN md URL,NRM=1IFI Ready-nm Session hdr, NRM=0 TEARDOWN md URL,NRM=1IFI Ready-nm Session hdr, NRM=0
TEARDOWN md URL,NRM=1 Init No Session hdr, NRM=0 TEARDOWN md URL,NRM=1 Init No Session hdr, NRM=0
TEARDOWN md URL,NRM>1 Ready Session hdr, NRM-=1 TEARDOWN md URL,NRM>1 Ready Session hdr, NRM-=1
PLAY Prs URL, No range Play Play from RP PLAY Prs URL, No range Play Play from RP
PLAY Prs URL, Range Play according to range PLAY Prs URL, Range Play according to range
S->C:REDIRECT Range hdr Ready Set RedP S->C:REDIRECT Range hdr Ready Set RedP
S->C:REDIRECT no range hdr Init S->C:REDIRECT no range hdr Ready TEARDOWN of session
Timeout Init Timeout Init
RedP reached Init RedP reached Ready TEARDOWN of session
Table 9: State: Ready Table 9: State: Ready
In the Ready state, see Table 9, some of the actions are depending on
the number of media streams (NRM) in the session, i.e. aggregated or
non-aggregated control. A setup request in the ready state can either
add one more media stream to the session or if the media stream (same
URL) already is part of the session change the transport parameters.
TEARDOWN is depending on both the request URI and the number of media
stream within the session. If the request URI is either * or the pre-
sentations URI the whole session is torn down. If a media URL is used
in the TEARDOWN request and more than one media exist in the session,
the session will remain and a session header MUST be returned in the
response. If only a single media stream remains in the session when response. If only a single media stream remains in the session when
performing a TEARDOWN with a media URL , it is optional to keep the performing a TEARDOWN with a media URL , it is optional to keep the
session. If the session still exist after the request a Session MUST session. If the session still exist after the request a Session MUST
be returned in the response. The number of media streams remaining be returned in the response. The number of media streams remaining
after tearing down a media stream determines the new state. after tearing down a media stream determines the new state.
The Play state table, see Table 10, is the largest. The table con-
tains an number of request that has presentation URL as a prerequi-
site on the request URL, this is due to the exclusion of non-aggre-
gated stream control in sessions with more than one media stream.
To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request must be sent to
change the state to Ready. It may appear that there exist two auto-
matic transitions in "RedP reached" and "PP reached", however they
are requested and acknowledge before they take place. The time at
which the transition will happen is known by looking at the range
header. If the client sends request close in time to these transi-
tions it must be prepared for getting error message as the state may
or may not have changed.
SETUP and TEARDOWN requests with media URLs in aggregated sessions
may not be handled by the server as it is optional functionality. Use
the service discovery mechanism with OPTIONS to find out in before-
hand if the server implements it. If the functionality is not
Action Requisite New State Response Action Requisite New State Response
------------------------------------------------------------------------ ------------------------------------------------------------------------
PAUSE PrsURL,No range Ready Set RP to present point PAUSE PrsURL,No range Ready Set RP to present point
PAUSE PrsURL,Range>now Play Set RP & PP to given point PAUSE PrsURL,Range>now Play Set RP & PP to given point
PAUSE PrsURL,Range<=now Ready Set RP to Range Hdr. PAUSE PrsURL,Range<=now Ready Set RP to Range Hdr.
PP reached Ready RP = PP PP reached Ready RP = PP
End of media All media Play No action, RP = Invalid End of media All media Play No action, RP = Invalid
End of media >=1 Media plays Play No action End of media >=1 Media plays Play No action
End of range Play Set RP = End of range End of range Play Set RP = End of range
SETUP New URL,IFI Play NRM+=1, 200, *A SETUP New URL,IFI Play NRM+=1, 200, *A
SETUP New URL Play 455 SETUP New URL Play 455
SETUP Setuped URL Play 455 SETUP Setuped URL Play 455
SETUP Setuped URL, IFI Play Change transport param. SETUP Setuped URL, IFI Play Change transport param.
TEARDOWN URL=* Init No session hdr TEARDOWN URL=* Init No session hdr
TEARDOWN Prs URL,NRM>1 Init No session hdr TEARDOWN Prs URL,NRM>1 Init No session hdr
TEARDOWN md URL,NRM=1,IFI Ready-nm Session hdr TEARDOWN md URL,NRM=1,IFI Ready-nm Session hdr
TEARDOWN md URL,NRM>1,IFI Play Session hdr TEARDOWN md URL,NRM>1,IFI Play Session hdr
TEARDOWN md URL Play 455 TEARDOWN md URL Play 455
S->C:REDIRECT Range hdr Play Set RedP S->C:REDIRECT Range hdr Play Set RedP
S->C:REDIRECT no range hdr Init Stop Media Playout S->C:REDIRECT no range hdr Play TEARDOWN of session
RedP reached Init Stop Media playout RedP reached Play TEARDOWN of session
Timeout Init Stop Media playout Timeout Init Stop Media playout
Table 10: State: Play, *A: RTP-Info and Range header Table 10: State: Play, *A: RTP-Info and Range header
implemented but still tried by the client a "501 Not Implemented" The Play state table, see Table 10, is the largest. The table con-
response SHALL be received. tains an number of request that has presentation URL as a prerequi-
site on the request URL, this is due to the exclusion of non-aggre-
gated stream control in sessions with more than one media stream.
To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request must be sent to
change the state to Ready. It may appear that there exist two auto-
matic transitions in "RedP reached" and "PP reached", however they
are requested and acknowledge before they take place. The time at
which the transition will happen is known by looking at the range
header. If the client sends request close in time to these transi-
tions it must be prepared for getting error message as the state may
or may not have changed.
SETUP and TEARDOWN requests with media URLs in aggregated sessions
may not be handled by the server as it is optional functionality. Use
the service discovery mechanism with OPTIONS to find out in before-
hand if the server implements it. If the functionality is not imple-
mented but still tried by the client a "501 Not Implemented" response
SHALL be received.
B Media Transport Alternatives B Media Transport Alternatives
This chapter defines how certain combinations of protocols, profiles | This chapter defines how certain combinations of protocols, profiles |
and lower transports are used. This includes the usage of the Trans- | and lower transports are used. This includes the usage of the Trans- |
port header's general source and destination parameters | port header's general source and destination parameters |
"src_addresses" and "dst_addresses". | "src_addresses" and "dst_addresses". |
B.1 RTP | B.1 RTP |
skipping to change at page 1, line 5131 skipping to change at page 1, line 5286
used for individual media, it indicates the URL to be used for con- used for individual media, it indicates the URL to be used for con-
trolling that particular media stream. If found at the session level, trolling that particular media stream. If found at the session level,
the attribute indicates the URL for aggregate control. the attribute indicates the URL for aggregate control.
control-attribute = "a=" "control" ":" url control-attribute = "a=" "control" ":" url
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute may contain either relative and absolute URLs, follow- This attribute MAY contain either relative and absolute URLs, follow- |
ing the rules and conventions set out in RFC 2396 [22]. Implementa- ing the rules and conventions set out in RFC 2396 [22]. Implementa- |
tions should look for a base URL in the following order: tions SHALL look for a base URL in the following order: |
1. the RTSP Content-Base field; 1. the RTSP Content-Base field; |
2. the RTSP Content-Location field; 2. the RTSP Content-Location field; |
3. the RTSP request URL. 3. the RTSP request URL. |
If this attribute contains only an asterisk (*), then the URL is If this attribute contains only an asterisk (*), then the URL is
treated as if it were an empty embedded URL, and thus inherits the treated as if it were an empty embedded URL, and thus inherits the
entire base URL. entire base URL.
For SDP retrieved from a container file, there are certain things to For SDP retrieved from a container file, there are certain things to
consider. Lets say that the container file has the following URL: consider. Lets say that the container file has the following URL:
"rtsp://example.com/container.mp4". A media level relative URL needs "rtsp://example.com/container.mp4". A media level relative URL needs
to contain the file name container.mp4 in the beginning to be to contain the file name container.mp4 in the beginning to be
resolved correctly relative to the before given URL. An alternative resolved correctly relative to the before given URL. An alternative
skipping to change at page 1, line 5161 skipping to change at page 1, line 5316
that the base URL for the SDP document becomes: "rtsp://exam- that the base URL for the SDP document becomes: "rtsp://exam-
ple.com/container.mp4/", i.e. an extra trailing slash. When using ple.com/container.mp4/", i.e. an extra trailing slash. When using
the URL resolution rules in RFC 2396 that will resolve correctly. the URL resolution rules in RFC 2396 that will resolve correctly.
However as a warning if the session level control URL is a * that However as a warning if the session level control URL is a * that
control URL will be equal to "rtsp://example.com/container.mp4/" and control URL will be equal to "rtsp://example.com/container.mp4/" and
include the slash. include the slash.
C.1.2 Media Streams C.1.2 Media Streams
The "m=" field is used to enumerate the streams. It is expected that The "m=" field is used to enumerate the streams. It is expected that
all the specified streams will be rendered with appropriate synchro- all the specified streams will be rendered with appropriate
nization. If the session is unicast, the port number serves as a rec- synchronization. If the session is unicast, the port number serves as
ommendation from the server to the client; the client still has to a recommendation from the server to the client; the client still has
include it in its SETUP request and may ignore this recommendation. to include it in its SETUP request and may ignore this recommenda-
If the server has no preference, it SHOULD set the port number value tion. If the server has no preference, it SHOULD set the port number
to zero. value to zero.
Example: Example:
m=audio 0 RTP/AVP 31 m=audio 0 RTP/AVP 31
C.1.3 Payload Type(s) C.1.3 Payload Type(s)
The payload type(s) are specified in the "m=" field. In case the pay- The payload type(s) are specified in the "m=" field. In case the pay-
load type is a static payload type from RFC 1890 [1], no other infor- load type is a static payload type from RFC 1890 [1], no other infor-
mation is required. In case it is a dynamic payload type, the media mation is required. In case it is a dynamic payload type, the media
skipping to change at page 1, line 5196 skipping to change at page 1, line 5351
priate profile name be used in lieu of "RTP/AVP" in the "m=" field. priate profile name be used in lieu of "RTP/AVP" in the "m=" field.
C.1.4 Format-Specific Parameters C.1.4 Format-Specific Parameters
Format-specific parameters are conveyed using the "fmtp" media Format-specific parameters are conveyed using the "fmtp" media
attribute. The syntax of the "fmtp" attribute is specific to the attribute. The syntax of the "fmtp" attribute is specific to the
encoding(s) that the attribute refers to. Note that the packetization encoding(s) that the attribute refers to. Note that the packetization
interval is conveyed using the "ptime" attribute. interval is conveyed using the "ptime" attribute.
C.1.5 Range of Presentation C.1.5 Range of Presentation
The "a=range" attribute defines the total time range of the stored
session. (The length of live sessions can be deduced from the "t" and The "a=range" attribute defines the total time range of the stored |
"r" parameters.) Unless the presentation contains media streams of session. (The length of live sessions can be deduced from the "t" and |
different durations, the length attribute is a session-level "r" parameters.) The attribute is a session and media level |
attribute. In case of different length the range attribute MUST be attribute. For presentations that contains media streams of the same |
given at media level for all media. The unit is specified first, fol- durations, the range attribute SHOULD only be used at session-level. |
lowed by the value range. The units and their values are as defined In case of different length the range attribute MUST be given at |
in Section 3.4, 3.5 and 3.6. ' media level for all media. The unit is specified first, followed by |
the value range. The units and their values are as defined in Section |
3.4, 3.5 and 3.6. The range attribute SHOULD NOT be present for live |
media streams. |
This attribute is defined in ABNF [14] as: |
a-range-def = "a" "=" "range" ":" ranges-specifier CRLF ||
Examples: Examples:
a=range:npt=0-34.4368 a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203 a=range:clock=19971113T2115-19971113T2203
C.1.6 Time of Availability C.1.6 Time of Availability
The "t=" field MUST contain suitable values for the start and stop The "t=" field MUST contain suitable values for the start and stop
times for both aggregate and non-aggregate stream control. With times for both aggregate and non-aggregate stream control. With
skipping to change at page 1, line 5376 skipping to change at page 1, line 5536
To support on-demand playback of media streams, the client MUST addi- To support on-demand playback of media streams, the client MUST addi-
tionally be able to do the following: tionally be able to do the following:
+ generate the PAUSE request; + generate the PAUSE request;
+ implement the REDIRECT method, and the Location header. + implement the REDIRECT method, and the Location header.
D.1.2 Authentication-enabled D.1.2 Authentication-enabled
In order to access media presentations from RTSP servers that require In order to access media presentations from RTSP servers that require
authentication, the client MUST additionally be able to do the authentication, the client MUST additionally be able to do the fol-
following: lowing:
+ recognize the 401 (Unauthorized) status code; + recognize the 401 (Unauthorized) status code;
+ parse and include the WWW-Authenticate header; + parse and include the WWW-Authenticate header;
+ implement Basic Authentication and Digest Authentication. + implement Basic Authentication and Digest Authentication.
D.2 Server D.2 Server
A minimal server implementation MUST be able to do the following: | A minimal server implementation MUST be able to do the following: |
+ Implement the following methods: SETUP, TEARDOWN, OPTIONS and | + Implement the following methods: SETUP, TEARDOWN, OPTIONS and |
PLAY. | PLAY. |
skipping to change at page 1, line 5726 skipping to change at page 1, line 5885
USA USA
electronic mail: robla@real.com electronic mail: robla@real.com
Magnus Westerlund Magnus Westerlund
Ericsson AB, ERA/TVA/A Ericsson AB, ERA/TVA/A
Torshamsgatan 23 Torshamsgatan 23
SE-164 80 STOCKHOLM SE-164 80 STOCKHOLM
SWEDEN SWEDEN
electronic mail: magnus.westerlund@ericsson.com electronic mail: magnus.westerlund@ericsson.com
Aravind Narasimhan
Sun Microsystems, Inc.
101 Park Avenue, 3rd & 4th Floor
New York, NY
USA
electronic mail: aravind.narasimhan@sun.com
H Contributors H Contributors
The following people has made written contribution included in the | The following people has made written contribution included in the |
specification: | specification: |
+ Tom Marshall has contributed with text about the usage of 3rr | + Tom Marshall has contributed with text about the usage of 3rr |
status codes. | status codes. |
+ Thomas Zheng has contributed with text regarding the usage of the | + Thomas Zheng has contributed with text regarding the usage of the |
Range in PLAY responses. | Range in PLAY responses. |
skipping to change at page 1, line 5757 skipping to change at page 1, line 5923
participating in the MMUSIC-WG. In addition to those already men- participating in the MMUSIC-WG. In addition to those already men-
tioned, the following individuals have contributed to this specifica- tioned, the following individuals have contributed to this specifica-
tion: tion:
Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari,
Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V.
Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets,
Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas
Marshall, Rob McCool, Aravind Narasimhan, David Oran, Joerg Ott, Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal
Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov,
Perkins, Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith,
Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Alexander Sokolsky, Dale Stammen, John Francis Stracke, and David
Stracke, and David Walker. Walker.
[1] H. Schulzrinne, "RTP profile for audio and video conferences with [1] H. Schulzrinne, "RTP profile for audio and video conferences with
minimal control," RFC 1890, Internet Engineering Task Force, Jan. minimal control," RFC 1890, Internet Engineering Task Force, Jan.
1996. 1996.
[2] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee, [2] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee,
"Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Engi- "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Engi-
neering Task Force, Jan. 1997. neering Task Force, Jan. 1997.
[3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Internationaliza- [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Internationaliza-
skipping to change at page 1, line 5964 skipping to change at page 1, line 6130
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 3
1.1 The Update of the RTSP Specification . . . . . . . . . . 3 1.1 The Update of the RTSP Specification . . . . . . . . . . 3
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Protocol Properties . . . . . . . . . . . . . . . . . . . 8 1.5 Protocol Properties . . . . . . . . . . . . . . . . . . . 8
1.6 Extending RTSP . . . . . . . . . . . . . . . . . . . . . 10 1.6 Extending RTSP . . . . . . . . . . . . . . . . . . . . . 10
1.7 Overall Operation . . . . . . . . . . . . . . . . . . . . 11 1.7 Overall Operation . . . . . . . . . . . . . . . . . . . . 11
1.8 RTSP States . . . . . . . . . . . . . . . . . . . . . . . 12 1.8 RTSP States . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 Relationship with Other Protocols . . . . . . . . . . . . 12 1.9 Relationship with Other Protocols . . . . . . . . . . . . 13
2 Notational Conventions . . . . . . . . . . . . . . . . . 13 2 Notational Conventions . . . . . . . . . . . . . . . . . 14
3 Protocol Parameters . . . . . . . . . . . . . . . . . . . 13 3 Protocol Parameters . . . . . . . . . . . . . . . . . . . 14
3.1 RTSP Version . . . . . . . . . . . . . . . . . . . . . . 13 3.1 RTSP Version . . . . . . . . . . . . . . . . . . . . . . 14
3.2 RTSP URL . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 RTSP URL . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Session Identifiers . . . . . . . . . . . . . . . . . . . 15 3.3 Session Identifiers . . . . . . . . . . . . . . . . . . . 16
3.4 SMPTE Relative Timestamps . . . . . . . . . . . . . . . . 15 3.4 SMPTE Relative Timestamps . . . . . . . . . . . . . . . . 16
3.5 Normal Play Time . . . . . . . . . . . . . . . . . . . . 16 3.5 Normal Play Time . . . . . . . . . . . . . . . . . . . . 17
3.6 Absolute Time . . . . . . . . . . . . . . . . . . . . . . 17 3.6 Absolute Time . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Feature-tags . . . . . . . . . . . . . . . . . . . . . . 18 3.7 Feature-tags . . . . . . . . . . . . . . . . . . . . . . 18
4 RTSP Message . . . . . . . . . . . . . . . . . . . . . . 18 4 RTSP Message . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 19 4.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Message Headers . . . . . . . . . . . . . . . . . . . . . 19 4.2 Message Headers . . . . . . . . . . . . . . . . . . . . . 19
4.3 Message Body . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Message Body . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Message Length . . . . . . . . . . . . . . . . . . . . . 19 4.4 Message Length . . . . . . . . . . . . . . . . . . . . . 19
5 General Header Fields . . . . . . . . . . . . . . . . . . 20 5 General Header Fields . . . . . . . . . . . . . . . . . . 20
6 Request . . . . . . . . . . . . . . . . . . . . . . . . . 20 6 Request . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Request Line . . . . . . . . . . . . . . . . . . . . . . 20 6.1 Request Line . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Request Header Fields . . . . . . . . . . . . . . . . . . 21 6.2 Request Header Fields . . . . . . . . . . . . . . . . . . 21
7 Response . . . . . . . . . . . . . . . . . . . . . . . . 22 7 Response . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1 Status-Line . . . . . . . . . . . . . . . . . . . . . . . 22 7.1 Status-Line . . . . . . . . . . . . . . . . . . . . . . . 23
7.1.1 Status Code and Reason Phrase . . . . . . . . . . . . . . 22 7.1.1 Status Code and Reason Phrase . . . . . . . . . . . . . . 23
7.1.2 Response Header Fields . . . . . . . . . . . . . . . . . 25 7.1.2 Response Header Fields . . . . . . . . . . . . . . . . . 25
8 Entity . . . . . . . . . . . . . . . . . . . . . . . . . 25 8 Entity . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1 Entity Header Fields . . . . . . . . . . . . . . . . . . 27 8.1 Entity Header Fields . . . . . . . . . . . . . . . . . . 27
8.2 Entity Body . . . . . . . . . . . . . . . . . . . . . . . 27 8.2 Entity Body . . . . . . . . . . . . . . . . . . . . . . . 28
9 Connections . . . . . . . . . . . . . . . . . . . . . . . 27 9 Connections . . . . . . . . . . . . . . . . . . . . . . . 28
9.1 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 28 9.1 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 28
9.2 Reliability and Acknowledgements . . . . . . . . . . . . 28 9.2 Reliability and Acknowledgements . . . . . . . . . . . . 29
9.3 The usage of connections . . . . . . . . . . . . . . . . 29 9.3 The usage of connections . . . . . . . . . . . . . . . . 30
9.4 Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . . 30 9.4 Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . . 31
10 Capability Handling . . . . . . . . . . . . . . . . . . . 31 10 Capability Handling . . . . . . . . . . . . . . . . . . . 31
11 Method Definitions . . . . . . . . . . . . . . . . . . . 32 11 Method Definitions . . . . . . . . . . . . . . . . . . . 33
11.1 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.2 DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 34 11.2 DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 34
11.3 SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3 SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.4 PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.4 PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.5 PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 40 11.5 PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.6 TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 43 11.6 TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 44
11.7 GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 43 11.7 GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 45
11.8 SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 44 11.8 SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 46
11.9 REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 45 11.9 REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 47
11.10 PING . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.10 PING . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.11 Embedded (Interleaved) Binary Data . . . . . . . . . . . 47 11.11 Embedded (Interleaved) Binary Data . . . . . . . . . . . 49
12 Status Code Definitions . . . . . . . . . . . . . . . . . 49 12 Status Code Definitions . . . . . . . . . . . . . . . . . 50
12.1 Success 1xx . . . . . . . . . . . . . . . . . . . . . . . 49 12.1 Success 1xx . . . . . . . . . . . . . . . . . . . . . . . 50
12.1.1 100 Continue . . . . . . . . . . . . . . . . . . . . . . 49 12.1.1 100 Continue . . . . . . . . . . . . . . . . . . . . . . 50
12.2 Success 2xx . . . . . . . . . . . . . . . . . . . . . . . 49 12.2 Success 2xx . . . . . . . . . . . . . . . . . . . . . . . 51
12.2.1 250 Low on Storage Space . . . . . . . . . . . . . . . . 49 12.2.1 250 Low on Storage Space . . . . . . . . . . . . . . . . 51
12.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 49 12.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 51
12.3.1 TBW . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 12.3.1 TBW . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . 50 12.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . 51
12.3.3 302 Found . . . . . . . . . . . . . . . . . . . . . . . . 50 12.3.3 302 Found . . . . . . . . . . . . . . . . . . . . . . . . 51
12.3.4 303 See Other . . . . . . . . . . . . . . . . . . . . . . 50 12.3.4 303 See Other . . . . . . . . . . . . . . . . . . . . . . 51
12.3.5 304 Not Modified . . . . . . . . . . . . . . . . . . . . 50 12.3.5 304 Not Modified . . . . . . . . . . . . . . . . . . . . 52
12.3.6 305 Use Proxy . . . . . . . . . . . . . . . . . . . . . . 51 12.3.6 305 Use Proxy . . . . . . . . . . . . . . . . . . . . . . 52
12.4 Client Error 4xx . . . . . . . . . . . . . . . . . . . . 51 12.4 Client Error 4xx . . . . . . . . . . . . . . . . . . . . 52
12.4.1 400 Bad Request . . . . . . . . . . . . . . . . . . . . . 51 12.4.1 400 Bad Request . . . . . . . . . . . . . . . . . . . . . 52
12.4.2 405 Method Not Allowed . . . . . . . . . . . . . . . . . 51 12.4.2 405 Method Not Allowed . . . . . . . . . . . . . . . . . 52
12.4.3 451 Parameter Not Understood . . . . . . . . . . . . . . 51 12.4.3 451 Parameter Not Understood . . . . . . . . . . . . . . 53
12.4.4 452 reserved . . . . . . . . . . . . . . . . . . . . . . 51 12.4.4 452 reserved . . . . . . . . . . . . . . . . . . . . . . 53
12.4.5 453 Not Enough Bandwidth . . . . . . . . . . . . . . . . 51 12.4.5 453 Not Enough Bandwidth . . . . . . . . . . . . . . . . 53
12.4.6 454 Session Not Found . . . . . . . . . . . . . . . . . . 51 12.4.6 454 Session Not Found . . . . . . . . . . . . . . . . . . 53
12.4.7 455 Method Not Valid in This State . . . . . . . . . . . 52 12.4.7 455 Method Not Valid in This State . . . . . . . . . . . 53
12.4.8 456 Header Field Not Valid for Resource . . . . . . . . . 52 12.4.8 456 Header Field Not Valid for Resource . . . . . . . . . 53
12.4.9 457 Invalid Range . . . . . . . . . . . . . . . . . . . . 52 12.4.9 457 Invalid Range . . . . . . . . . . . . . . . . . . . . 53
12.4.10 458 Parameter Is Read-Only . . . . . . . . . . . . . . . 52 12.4.10 458 Parameter Is Read-Only . . . . . . . . . . . . . . . 53
12.4.11 459 Aggregate Operation Not Allowed . . . . . . . . . . . 52 12.4.11 459 Aggregate Operation Not Allowed . . . . . . . . . . . 54
12.4.12 460 Only Aggregate Operation Allowed . . . . . . . . . . 52 12.4.12 460 Only Aggregate Operation Allowed . . . . . . . . . . 54
12.4.13 461 Unsupported Transport . . . . . . . . . . . . . . . . 52 12.4.13 461 Unsupported Transport . . . . . . . . . . . . . . . . 54
12.4.14 462 Destination Unreachable . . . . . . . . . . . . . . . 52 12.4.14 462 Destination Unreachable . . . . . . . . . . . . . . . 54
12.5 Server Error 5xx . . . . . . . . . . . . . . . . . . . . 53 12.5 Server Error 5xx . . . . . . . . . . . . . . . . . . . . 54
12.5.1 551 Option not supported . . . . . . . . . . . . . . . . 53 12.5.1 551 Option not supported . . . . . . . . . . . . . . . . 54
13 Header Field Definitions . . . . . . . . . . . . . . . . 53 13 Header Field Definitions . . . . . . . . . . . . . . . . 54
13.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . 55 13.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.2 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 55 13.2 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 60
13.3 Accept-Language . . . . . . . . . . . . . . . . . . . . . 55 13.3 Accept-Language . . . . . . . . . . . . . . . . . . . . . 60
13.4 Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 57 13.4 Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 60
13.5 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 59 13.5 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.6 Authorization . . . . . . . . . . . . . . . . . . . . . . 59 13.6 Authorization . . . . . . . . . . . . . . . . . . . . . . 61
13.7 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 59 13.7 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 61
13.8 Blocksize . . . . . . . . . . . . . . . . . . . . . . . . 60 13.8 Blocksize . . . . . . . . . . . . . . . . . . . . . . . . 61
13.9 Cache-Control . . . . . . . . . . . . . . . . . . . . . . 60 13.9 Cache-Control . . . . . . . . . . . . . . . . . . . . . . 62
13.10 Connection . . . . . . . . . . . . . . . . . . . . . . . 63 13.10 Connection . . . . . . . . . . . . . . . . . . . . . . . 65
13.11 Content-Base . . . . . . . . . . . . . . . . . . . . . . 63 13.11 Content-Base . . . . . . . . . . . . . . . . . . . . . . 65
13.12 Content-Encoding . . . . . . . . . . . . . . . . . . . . 63 13.12 Content-Encoding . . . . . . . . . . . . . . . . . . . . 65
13.13 Content-Language . . . . . . . . . . . . . . . . . . . . 63 13.13 Content-Language . . . . . . . . . . . . . . . . . . . . 65
13.14 Content-Length . . . . . . . . . . . . . . . . . . . . . 64 13.14 Content-Length . . . . . . . . . . . . . . . . . . . . . 65
13.15 Content-Location . . . . . . . . . . . . . . . . . . . . 64 13.15 Content-Location . . . . . . . . . . . . . . . . . . . . 65
13.16 Content-Type . . . . . . . . . . . . . . . . . . . . . . 64 13.16 Content-Type . . . . . . . . . . . . . . . . . . . . . . 65
13.17 CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 64 13.17 CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.18 Date . . . . . . . . . . . . . . . . . . . . . . . . . . 64 13.18 Date . . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.19 Expires . . . . . . . . . . . . . . . . . . . . . . . . . 65 13.19 Expires . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.20 From . . . . . . . . . . . . . . . . . . . . . . . . . . 66 13.20 From . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.21 Host . . . . . . . . . . . . . . . . . . . . . . . . . . 66 13.21 Host . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.22 If-Match . . . . . . . . . . . . . . . . . . . . . . . . 66 13.22 If-Match . . . . . . . . . . . . . . . . . . . . . . . . 67
13.23 If-Modified-Since . . . . . . . . . . . . . . . . . . . . 66 13.23 If-Modified-Since . . . . . . . . . . . . . . . . . . . . 68
13.24 Last-Modified . . . . . . . . . . . . . . . . . . . . . . 66 13.24 Last-Modified . . . . . . . . . . . . . . . . . . . . . . 68
13.25 Location . . . . . . . . . . . . . . . . . . . . . . . . 67 13.25 Location . . . . . . . . . . . . . . . . . . . . . . . . 68
13.26 Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 67 13.26 Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 68
13.27 Proxy-Require . . . . . . . . . . . . . . . . . . . . . . 67 13.27 Proxy-Require . . . . . . . . . . . . . . . . . . . . . . 68
13.28 Public . . . . . . . . . . . . . . . . . . . . . . . . . 67 13.28 Public . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.29 Range . . . . . . . . . . . . . . . . . . . . . . . . . . 68 13.29 Range . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.30 Referer . . . . . . . . . . . . . . . . . . . . . . . . . 69 13.30 Referer . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.31 Retry-After . . . . . . . . . . . . . . . . . . . . . . . 69 13.31 Retry-After . . . . . . . . . . . . . . . . . . . . . . . 71
13.32 Require . . . . . . . . . . . . . . . . . . . . . . . . . 69 13.32 Require . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.33 RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 70 13.33 RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 73
13.34 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.34 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.35 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.35 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 75
13.36 Server . . . . . . . . . . . . . . . . . . . . . . . . . 73 13.36 Server . . . . . . . . . . . . . . . . . . . . . . . . . 76
13.37 Session . . . . . . . . . . . . . . . . . . . . . . . . . 73 13.37 Session . . . . . . . . . . . . . . . . . . . . . . . . . 76
13.38 Supported . . . . . . . . . . . . . . . . . . . . . . . . 75 13.38 Supported . . . . . . . . . . . . . . . . . . . . . . . . 78
13.39 Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 75 13.39 Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 78
13.40 Transport . . . . . . . . . . . . . . . . . . . . . . . . 76 13.40 Transport . . . . . . . . . . . . . . . . . . . . . . . . 79
13.41 Unsupported . . . . . . . . . . . . . . . . . . . . . . . 81 13.41 Unsupported . . . . . . . . . . . . . . . . . . . . . . . 84
13.42 User-Agent . . . . . . . . . . . . . . . . . . . . . . . 82 13.42 User-Agent . . . . . . . . . . . . . . . . . . . . . . . 85
13.43 Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 82 13.43 Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.44 Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 13.44 Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.45 WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 82 13.45 WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 85
14 Caching . . . . . . . . . . . . . . . . . . . . . . . . . 82 14 Caching . . . . . . . . . . . . . . . . . . . . . . . . . 85
15 Examples . . . . . . . . . . . . . . . . . . . . . . . . 83 15 Examples . . . . . . . . . . . . . . . . . . . . . . . . 86
15.1 Media on Demand (Unicast) . . . . . . . . . . . . . . . . 83 15.1 Media on Demand (Unicast) . . . . . . . . . . . . . . . . 86
15.2 Streaming of a Container file . . . . . . . . . . . . . . 85 15.2 Streaming of a Container file . . . . . . . . . . . . . . 88
15.3 Single Stream Container Files . . . . . . . . . . . . . . 88 15.3 Single Stream Container Files . . . . . . . . . . . . . . 91
15.4 Live Media Presentation Using Multicast . . . . . . . . . 90 15.4 Live Media Presentation Using Multicast . . . . . . . . . 93
16 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 91 16 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 94
16.1 Base Syntax . . . . . . . . . . . . . . . . . . . . . . . 91 16.1 Base Syntax . . . . . . . . . . . . . . . . . . . . . . . 94
16.2 RTSP Protocol Definition . . . . . . . . . . . . . . . . 92 16.2 RTSP Protocol Definition . . . . . . . . . . . . . . . . 95
16.2.1 Message Syntax . . . . . . . . . . . . . . . . . . . . . 92 16.2.1 Message Syntax . . . . . . . . . . . . . . . . . . . . . 95
16.2.2 Header Syntax . . . . . . . . . . . . . . . . . . . . . . 96 16.2.2 Header Syntax . . . . . . . . . . . . . . . . . . . . . . 99
17 Security Considerations . . . . . . . . . . . . . . . . . 97 17 Security Considerations . . . . . . . . . . . . . . . . . 100
18 IANA Considerations . . . . . . . . . . . . . . . . . . . 99 18 IANA Considerations . . . . . . . . . . . . . . . . . . . 102
18.1 Feature-tags . . . . . . . . . . . . . . . . . . . . . . 100 18.1 Feature-tags . . . . . . . . . . . . . . . . . . . . . . 103
18.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . 100 18.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . 103
18.1.2 Registering New Feature-tags with IANA . . . . . . . . . 100 18.1.2 Registering New Feature-tags with IANA . . . . . . . . . 103
18.1.3 Registered entries . . . . . . . . . . . . . . . . . . . 100 18.1.3 Registered entries . . . . . . . . . . . . . . . . . . . 103
18.2 RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 101 18.2 RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 104
18.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 101 18.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 104
18.2.2 Registering New Methods with IANA . . . . . . . . . . . . 101 18.2.2 Registering New Methods with IANA . . . . . . . . . . . . 104
18.2.3 Registered Entries . . . . . . . . . . . . . . . . . . . 101 18.2.3 Registered Entries . . . . . . . . . . . . . . . . . . . 104
18.3 RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 101 18.3 RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 104
18.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 101 18.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 104
18.3.2 Registering New Status Codes with IANA . . . . . . . . . 101 18.3.2 Registering New Status Codes with IANA . . . . . . . . . 104
18.3.3 Registered Entries . . . . . . . . . . . . . . . . . . . 102 18.3.3 Registered Entries . . . . . . . . . . . . . . . . . . . 105
18.4 RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 102 18.4 RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 105
18.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 102 18.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 105
18.4.2 Registering New Headers with IANA . . . . . . . . . . . . 102 18.4.2 Registering New Headers with IANA . . . . . . . . . . . . 105
18.4.3 Registered entries . . . . . . . . . . . . . . . . . . . 102 18.4.3 Registered entries . . . . . . . . . . . . . . . . . . . 105
18.5 Transport Header registries . . . . . . . . . . . . . . . 103 18.5 Transport Header registries . . . . . . . . . . . . . . . 106
18.5.1 Transport Protocols . . . . . . . . . . . . . . . . . . . 103 18.5.1 Transport Protocols . . . . . . . . . . . . . . . . . . . 106
18.5.2 Profile . . . . . . . . . . . . . . . . . . . . . . . . . 103 18.5.2 Profile . . . . . . . . . . . . . . . . . . . . . . . . . 106
18.5.3 Lower Transport . . . . . . . . . . . . . . . . . . . . . 104 18.5.3 Lower Transport . . . . . . . . . . . . . . . . . . . . . 107
18.5.4 Transport modes . . . . . . . . . . . . . . . . . . . . . 104 18.5.4 Transport modes . . . . . . . . . . . . . . . . . . . . . 107
18.6 Cache Directive Extensions . . . . . . . . . . . . . . . 105 18.6 Cache Directive Extensions . . . . . . . . . . . . . . . 108
A RTSP Protocol State Machine . . . . . . . . . . . . . . . 105 18.7 SDP attributes . . . . . . . . . . . . . . . . . . . . . 108
A.1 States . . . . . . . . . . . . . . . . . . . . . . . . . 105 A RTSP Protocol State Machine . . . . . . . . . . . . . . . 109
A.2 State variables . . . . . . . . . . . . . . . . . . . . . 106 A.1 States . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 106 A.2 State variables . . . . . . . . . . . . . . . . . . . . . 109
A.4 State Tables . . . . . . . . . . . . . . . . . . . . . . 106 A.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 110
B Media Transport Alternatives . . . . . . . . . . . . . . 110 A.4 State Tables . . . . . . . . . . . . . . . . . . . . . . 110
B.1 RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 B Media Transport Alternatives . . . . . . . . . . . . . . 114
B.1.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 B.1 RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.1.2 AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . 112 B.1.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B.1.3 AVP/TCP . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.1.2 AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . 115
B.2 Future Additions . . . . . . . . . . . . . . . . . . . . 114 B.1.3 AVP/TCP . . . . . . . . . . . . . . . . . . . . . . . . . 117
C Use of SDP for RTSP Session Descriptions . . . . . . . . 114 B.2 Future Additions . . . . . . . . . . . . . . . . . . . . 118
C.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 115 C Use of SDP for RTSP Session Descriptions . . . . . . . . 118
C.1.1 Control URL . . . . . . . . . . . . . . . . . . . . . . . 115 C.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 118
C.1.2 Media Streams . . . . . . . . . . . . . . . . . . . . . . 116 C.1.1 Control URL . . . . . . . . . . . . . . . . . . . . . . . 118
C.1.3 Payload Type(s) . . . . . . . . . . . . . . . . . . . . . 116 C.1.2 Media Streams . . . . . . . . . . . . . . . . . . . . . . 119
C.1.4 Format-Specific Parameters . . . . . . . . . . . . . . . 116 C.1.3 Payload Type(s) . . . . . . . . . . . . . . . . . . . . . 120
C.1.5 Range of Presentation . . . . . . . . . . . . . . . . . . 116 C.1.4 Format-Specific Parameters . . . . . . . . . . . . . . . 120
C.1.6 Time of Availability . . . . . . . . . . . . . . . . . . 117 C.1.5 Range of Presentation . . . . . . . . . . . . . . . . . . 120
C.1.7 Connection Information . . . . . . . . . . . . . . . . . 117 C.1.6 Time of Availability . . . . . . . . . . . . . . . . . . 121
C.1.8 Entity Tag . . . . . . . . . . . . . . . . . . . . . . . 117 C.1.7 Connection Information . . . . . . . . . . . . . . . . . 121
C.2 Aggregate Control Not Available . . . . . . . . . . . . . 118 C.1.8 Entity Tag . . . . . . . . . . . . . . . . . . . . . . . 121
C.3 Aggregate Control Available . . . . . . . . . . . . . . . 118 C.2 Aggregate Control Not Available . . . . . . . . . . . . . 122
D Minimal RTSP implementation . . . . . . . . . . . . . . . 119 C.3 Aggregate Control Available . . . . . . . . . . . . . . . 122
D.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . 119 D Minimal RTSP implementation . . . . . . . . . . . . . . . 123
D.1.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 120 D.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . 123
D.1.2 Authentication-enabled . . . . . . . . . . . . . . . . . 120 D.1.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 124
D.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . 121 D.1.2 Authentication-enabled . . . . . . . . . . . . . . . . . 124
D.2.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 121 D.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . 125
D.2.2 Authentication-enabled . . . . . . . . . . . . . . . . . 122 D.2.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 125
E Open Issues . . . . . . . . . . . . . . . . . . . . . . . 122 D.2.2 Authentication-enabled . . . . . . . . . . . . . . . . . 126
F Changes . . . . . . . . . . . . . . . . . . . . . . . . . 123 E Open Issues . . . . . . . . . . . . . . . . . . . . . . . 126
G Author Addresses . . . . . . . . . . . . . . . . . . . . 127 F Changes . . . . . . . . . . . . . . . . . . . . . . . . . 127
H Contributors . . . . . . . . . . . . . . . . . . . . . . 128 G Author Addresses . . . . . . . . . . . . . . . . . . . . 131
I Acknowledgements . . . . . . . . . . . . . . . . . . . . 128 H Contributors . . . . . . . . . . . . . . . . . . . . . . 132
I Acknowledgements . . . . . . . . . . . . . . . . . . . . 132
 End of changes. 

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