draft-ietf-mmusic-rfc2326bis-11.txt   draft-ietf-mmusic-rfc2326bis-12.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft H. Schulzrinne Internet Draft H. Schulzrinne
draft-ietf-mmusic-rfc2326bis-11.txt Columbia U. draft-ietf-mmusic-rfc2326bis-12.txt Columbia U.
October 24, 2005 A. Rao March 6, 2006 A. Rao
Expires: April, 2006 Cisco Expires: September, 2006 Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
A. Narasimhan A. Narasimhan
Overture Overture
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
skipping to change at page 3, line 5 skipping to change at page 3, line 5
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 protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents
1 Introduction ........................................ 9
1.1 RTSP Specification Update ........................... 9
1.2 Purpose ............................................. 9
1.3 Notational Conventions .............................. 11
1.3.1 RFC Editor Consideration ............................ 11
1.4 Terminology ......................................... 12
1.5 Protocol Properties ................................. 15
1.6 Extending RTSP ...................................... 16
1.7 Overall Operation ................................... 17
1.8 RTSP States ......................................... 18
1.9 Relationship with Other Protocols ................... 19
2 RTSP Use Cases ...................................... 20
2.1 On-demand Playback of Stored Content ................ 20
2.2 Unicast distribution of Live Content ................ 21
2.3 On-demand Playback using Multicast .................. 22
2.4 Inviting an RTSP server into a conference ........... 22
2.5 Live Content using Multicast ........................ 23
3 Protocol Parameters ................................. 24
3.1 RTSP Version ........................................ 24
3.2 RTSP IRI and URI .................................... 24
3.3 Session Identifiers ................................. 26
3.4 SMPTE Relative Timestamps ........................... 26
3.5 Normal Play Time .................................... 26
3.6 Absolute Time ....................................... 27
3.7 Feature-tags ........................................ 27
3.8 Entity Tags ......................................... 28
4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 29
4.2 Message Headers ..................................... 29
4.3 Message Body ........................................ 29
4.4 Message Length ...................................... 29
5 General Header Fields ............................... 29
6 Request ............................................. 30
6.1 Request Line ........................................ 30
6.2 Request Header Fields ............................... 32
7 Response ............................................ 33
7.1 Status-Line ......................................... 33
7.1.1 Status Code and Reason Phrase ....................... 33
7.2 Response Header Fields .............................. 34
8 Entity .............................................. 34
8.1 Entity Header Fields ................................ 35
8.2 Entity Body ......................................... 35
9 Connections ......................................... 35
9.1 Reliability and Acknowledgements .................... 38
9.2 Using Connections ................................... 38
9.3 Closing Connections ................................. 39
9.4 Timing Out Connections and RTSP Messages ............ 40
9.5 Use of IPv6 ......................................... 41
10 Capability Handling ................................. 41
11 Method Definitions .................................. 43
11.1 OPTIONS ............................................. 44
11.2 DESCRIBE ............................................ 45
11.3 SETUP ............................................... 47
11.3.1 Changing Transport Parameters ....................... 49
11.4 PLAY ................................................ 50
11.5 PAUSE ............................................... 55
11.6 TEARDOWN ............................................ 57
11.7 GET_PARAMETER ....................................... 58
11.8 SET_PARAMETER ....................................... 59
11.9 REDIRECT ............................................ 60
12 Embedded (Interleaved) Binary Data .................. 63
13 Status Code Definitions ............................. 64
13.1 Success 1xx ......................................... 64
13.1.1 100 Continue ........................................ 65
13.2 Success 2xx ......................................... 65
13.3 Redirection 3xx ..................................... 65
13.3.1 300 Multiple Choices ................................ 65
13.3.2 301 Moved Permanently ............................... 65
13.3.3 302 Found ........................................... 65
13.3.4 303 See Other ....................................... 66
13.3.5 304 Not Modified .................................... 66
13.3.6 305 Use Proxy ....................................... 66
13.4 Client Error 4xx .................................... 66
13.4.1 400 Bad Request ..................................... 66
13.4.2 405 Method Not Allowed .............................. 67
13.4.3 451 Parameter Not Understood ........................ 67
13.4.4 452 reserved ........................................ 67
13.4.5 453 Not Enough Bandwidth ............................ 67
13.4.6 454 Session Not Found ............................... 67
13.4.7 455 Method Not Valid in This State .................. 67
13.4.8 456 Header Field Not Valid for Resource ............. 67
13.4.9 457 Invalid Range ................................... 68
13.4.10 458 Parameter Is Read-Only .......................... 68
13.4.11 459 Aggregate Operation Not Allowed ................. 68
13.4.12 460 Only Aggregate Operation Allowed ................ 68
13.4.13 461 Unsupported Transport ........................... 68
13.4.14 462 Destination Unreachable ......................... 68
13.4.15 463 Destination Prohibited .......................... 68
13.4.16 470 Connection Authorization Required ............... 68
13.4.17 471 Connection Credentials not accepted ............. 69
13.5 Server Error 5xx .................................... 69
13.5.1 551 Option not supported ............................ 69
14 Header Field Definitions ............................ 69
14.1 Accept .............................................. 71
14.2 Accept-Credentials .................................. 71
14.3 Accept-Encoding ..................................... 76
14.4 Accept-Language ..................................... 76
14.5 Accept-Ranges ....................................... 76
14.6 Allow ............................................... 76
14.7 Authorization ....................................... 77
14.8 Bandwidth ........................................... 77
14.9 Blocksize ........................................... 77
14.10 Cache-Control ....................................... 77
14.11 Connection .......................................... 80
14.12 Connection-Credentials .............................. 80
14.13 Content-Base ........................................ 80
14.14 Content-Encoding .................................... 81
14.15 Content-Language .................................... 81
14.16 Content-Length ...................................... 81
14.17 Content-Location .................................... 81
14.18 Content-Type ........................................ 81
14.19 CSeq ................................................ 81
14.20 Date ................................................ 82
14.21 ETag ................................................ 82
14.22 Expires ............................................. 82
14.23 From ................................................ 83
14.24 If-Match ............................................ 83
14.25 If-Modified-Since ................................... 84
14.26 If-None-Match ....................................... 84
14.27 Last-Modified ....................................... 84
14.28 Location ............................................ 84
14.29 Proxy-Authenticate .................................. 85
14.30 Proxy-Authorization ................................. 85
14.31 Proxy-Require ....................................... 85
14.32 Proxy-Supported ..................................... 85
14.33 Public .............................................. 86
14.34 Range ............................................... 87
14.35 Referer ............................................. 88
14.36 Retry-After ......................................... 89
14.37 Require ............................................. 89
14.38 RTP-Info ............................................ 90
14.39 Scale ............................................... 92
14.40 Speed ............................................... 92
14.41 Server .............................................. 93
14.42 Session ............................................. 93
14.43 Supported ........................................... 95
14.44 Timestamp ........................................... 95
14.45 Transport ........................................... 96
14.46 Unsupported ......................................... 100
14.47 User-Agent .......................................... 101
14.48 Vary ................................................ 101
14.49 Via ................................................. 101
14.50 WWW-Authenticate .................................... 101
15 Proxies ............................................. 101
16 Caching ............................................. 102
17 Examples ............................................ 103
17.1 Media on Demand (Unicast) ........................... 103
17.2 Media on Demand (Unicast) ........................... 106
17.3 Single Stream Container Files ....................... 109
17.4 Live Media Presentation Using Multicast ............. 111
17.5 Capability Negotiation .............................. 112
18 Security Framework .................................. 113
18.1 RTSP and HTTP Authentication ........................ 113
18.2 RTSP over TLS ....................................... 113
18.3 Security and Proxies ................................ 114
18.3.1 Accept-Credentials .................................. 115
18.3.2 User approved TLS procedure ......................... 116
19 Syntax .............................................. 118
19.1 Base Syntax ......................................... 118
19.2 RTSP Protocol Definition ............................ 120
19.2.1 Generic Protocol elements ........................... 120
19.2.2 Message Syntax ...................................... 122
19.2.3 Header Syntax ....................................... 126
19.3 SDP extension Syntax ................................ 132
20 Security Considerations ............................. 132
20.1 Remote denial of Service Attack ..................... 134
21 IANA Considerations ................................. 135
21.1 Feature-tags ........................................ 136
21.1.1 Description ......................................... 136
21.1.2 Registering New Feature-tags with IANA .............. 136
21.1.3 Registered entries .................................. 136
21.2 RTSP Methods ........................................ 137
21.2.1 Description ......................................... 137
21.2.2 Registering New Methods with IANA ................... 137
21.2.3 Registered Entries .................................. 137
21.3 RTSP Status Codes ................................... 137
21.3.1 Description ......................................... 137
21.3.2 Registering New Status Codes with IANA .............. 137
21.3.3 Registered Entries .................................. 138
21.4 RTSP Headers ........................................ 138
21.4.1 Description ......................................... 138
21.4.2 Registering New Headers with IANA ................... 138
21.4.3 Registered entries .................................. 138
21.5 Transport Header registries ......................... 139
21.5.1 Transport Protocols ................................. 139
21.5.2 Profile ............................................. 140
21.5.3 Lower Transport ..................................... 140
21.5.4 Transport modes ..................................... 141
21.5.5 Transport Parameters ................................ 141
21.6 Cache Directive Extensions .......................... 142
21.7 Accept-Credentials .................................. 142
21.7.1 Accept-Credentials policies ......................... 142
21.7.2 Accept-Credentials hash algorithms .................. 143
21.8 Range header formats ................................ 143
21.9 URI Schemes ......................................... 144
21.9.1 The rtsp URI Scheme ................................. 144
21.9.2 The rtsps URI Scheme ................................ 145
21.9.3 The rtspu URI Scheme ................................ 146
21.10 SDP attributes ...................................... 146
A RTSP Protocol State Machine ......................... 147
A.1 States .............................................. 148
A.2 State variables ..................................... 148
A.3 Abbreviations ....................................... 148
A.4 State Tables ........................................ 148
B Media Transport Alternatives ........................ 152
B.1 RTP ................................................. 152
B.1.1 AVP ................................................. 152
B.1.2 AVP/UDP ............................................. 152
B.1.3 AVPF/UDP ............................................ 153
B.1.4 SAVP/UDP ............................................ 154
B.1.5 SAVPF/UDP ........................................... 154
B.2 RTP over TCP ........................................ 154
B.2.1 Interleaved RTP over TCP ............................ 154
B.2.2 RTP over independent TCP connections ................ 155
B.2.3 Handling NPT Jumps in the RTP Media Layer ........... 155
B.2.4 Handling RTP Timestamps after PAUSE ................. 157
B.2.5 RTSP / RTP Integration .............................. 159
B.2.6 Scaling with RTP .................................... 160
B.2.7 Maintaining NPT synchronization with RTP
timestamps ..................................................... 160
B.2.8 Continuous Audio .................................... 160
B.2.9 Multiple Sources in an RTP Session .................. 160
B.2.10 Usage of SSRCs and the RTCP BYE Message During an
RTSP Session ................................................... 160
B.3 Future Additions .................................... 161
C Use of SDP for RTSP Session Descriptions ............ 161
C.1 Definitions ......................................... 162
C.1.1 Control URI ......................................... 162
C.1.2 Media Streams ....................................... 163
C.1.3 Payload Type(s) ..................................... 163
C.1.4 Format-Specific Parameters .......................... 164
C.1.5 Range of Presentation ............................... 164
C.1.6 Time of Availability ................................ 165
C.1.7 Connection Information .............................. 165
C.1.8 Entity Tag .......................................... 165
C.2 Aggregate Control Not Available ..................... 166
C.3 Aggregate Control Available ......................... 166
C.4 RTSP external SDP delivery .......................... 167
D Minimal RTSP implementation ......................... 168
D.1 Minimal Core Implementation ......................... 168
D.2 Recommended Core Implementation ..................... 169
D.3 The Basic Playback Feature Support .................. 169
D.3.1 Client .............................................. 169
D.3.2 Server .............................................. 170
D.3.3 Proxy ............................................... 170
D.4 Secure Transport .................................... 170
E Requirements for Unreliable Transport of RTSP
messages ....................................................... 171
F Backwards Compatibility Considerations .............. 172
F.1 Play Request in Play mode ........................... 172
F.2 Using Persistent Connections ........................ 172
G Open Issues ......................................... 173
H Changes ............................................. 174
H.1 Changes needing to be updated ..................... 179
I Author Addresses .................................... 180
J Contributors ........................................ 180
K Acknowledgements .................................... 181
L Normative References ................................ 181
M Informative References .............................. 183
1 Introduction 1 Introduction
1.1 RTSP Specification Update 1.1 RTSP Specification Update
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a
proposed standard defined in RFC 2326 [24]. The goal of this version proposed standard defined in RFC 2326 [27]. The goal of this version
is to correct the many flaws that have been identified in RTSP 1.0 is to correct the many flaws that have been identified in RTSP 1.0
since its publication. The corrections are such that full backwards since its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was decided the most compatibility was impossible. Thus a new version was decided the most
appropriate solution to get a more functional protocol. There are no appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix H catalogs the changes of this plans to revise RTSP 1.0. Appendix H catalogs the changes of this
version in relation to RTSP 1.0. version in relation to RTSP 1.0.
A few open issues still remain to be resolved, and are listed in
appendix G. These are intended to be close quickly.
A list of bugs against RFC 2326 is available at
"http://rtspspec.sourceforge.net". These bugs should be taken into
account when reading this memorandum. 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.
RTSP 2.0 is reduced in functionality in regards to RTSP 1.0 and aims RTSP 2.0 is reduced in functionality in regards to RTSP 1.0 and aims
at specifying the RTSP core, functionality and rules for extensions, at specifying the RTSP core, functionality and rules for extensions,
and basic interaction with the media delivery protocol RTP. and basic interaction with the media delivery protocol RTP.
Any other functionality would be need to be published as extension Any other functionality would be need to be published as extension
documents. The Working group has discussed a number of different documents. And this specification provides rules for such extensions
proposals to extensions and is currently working on: and defines registries to avoid naming collisions.
o NAT and FW traversal mechanisms for RTSP are described in a
document called "How to make Real-Time Streaming Protocol
(RTSP) traverse Network Address Translators (NAT) and interact
with Firewalls." [25].
1.2 Purpose 1.2 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls one The Real-Time Streaming Protocol (RTSP) establishes and controls one
or several time-synchronized streams of continuous media such as or several time-synchronized streams of continuous media such as
audio and video. Put simply, RTSP acts as a "network remote control" audio and video. Put simply, RTSP acts as a "network remote control"
for multimedia servers. for multimedia servers.
There is no notion of an RTSP connection in the protocol. Instead, an There is no notion of an RTSP connection in the protocol. Instead, an
RTSP server maintains a session labeled by an identifier to associate RTSP server maintains a session labeled by an identifier to associate
skipping to change at page 3, line 63 skipping to change at page 9, line 49
This memorandum describes the use of RTSP over a reliable connection This memorandum describes the use of RTSP over a reliable connection
based transport level protocol such as TCP. RTSP may be implemented based transport level protocol such as TCP. RTSP may be implemented
over an unreliable connectionless transport protocol such as UDP. over an unreliable connectionless transport protocol such as UDP.
While nothing in RTSP precludes this, additional definition of this While nothing in RTSP precludes this, additional definition of this
problem area needs to be handled as an extension to the core problem area needs to be handled as an extension to the core
specification. specification.
The mechanisms of RTSP's operation over UDP were left out The mechanisms of RTSP's operation over UDP were left out
of this spec. because they were poorly defined in RFC 2326 of this spec. because they were poorly defined in RFC 2326
[24] and the tradeoff in size and complexity of this [27] and the tradeoff in size and complexity of this
memorandum for a small gain in a limited problem space was memorandum for a small gain in a limited problem space was
not deemed justifiable. not deemed justifiable.
The set of streams to be controlled in an RTSP session is defined by The set of streams to be controlled in an RTSP session is defined by
a presentation description. This memorandum does not define a format a presentation description. This memorandum does not define a format
for the presentation description. However appendix C defines how SDP for the presentation description. However appendix C defines how SDP
[1] is used for this purpose. The streams controlled by RTSP may use [1] is used for this purpose. The streams controlled by RTSP may use
RTP [2] for their data transport, but the operation of RTSP does not RTP [2] for their data transport, but the operation of RTSP does not
depend on the transport mechanism used to carry continuous media. depend on the transport mechanism used to carry continuous media.
RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3] RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3]
skipping to change at page 3, line 95 skipping to change at page 10, line 33
o Both an RTSP server and client can issue requests. o Both an RTSP server and client can issue requests.
o Data is usually carried out-of-band by a different protocol. o Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see Session descriptions returned in a DESCRIBE response (see
Section 11.2) and interleaving of RTP with RTSP over TCP are Section 11.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 12). exceptions to this rule (see Section 12).
o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts 8859-1, consistent with HTML internationalization efforts
[26]. [28].
o The Request-URI always contains the absolute URI. Because of o The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 [3] backward compatibility with a historical blunder, HTTP/1.1 [3]
carries only the absolute path in the request and puts the carries only the absolute path in the request and puts the
host name in a separate header field. host name in a separate header field.
This makes "virtual hosting" easier, where a single This makes "virtual hosting" easier, where a single
host with one IP address hosts several document trees. host with one IP address hosts several document trees.
The protocol supports the following operations: The protocol supports the following operations:
skipping to change at page 3, line 121 skipping to change at page 11, line 11
multicast addresses and ports to be used for the continuous multicast addresses and ports to be used for the continuous
media. If the presentation is to be sent only to the client media. If the presentation is to be sent only to the client
via unicast, the client provides the destination of via unicast, the client provides the destination of
necessity. necessity.
Invitation of a media server to a conference: A media server can Invitation of a media server to a conference: A media server can
be "invited" to join an existing conference to play back be "invited" to join an existing conference to play back
media into the presentation. This mode is useful for media into the presentation. This mode is useful for
example distributed teaching applications. Several parties example distributed teaching applications. Several parties
in the conference may take turns "pushing the remote in the conference may take turns "pushing the remote
control buttons". control buttons". Note: This functionality will require
RTSP external application level functionality.
RTSP requests may be handled by proxies, tunnels and caches as in RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 [3]. HTTP/1.1 [3].
1.3 Notational Conventions 1.3 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 [3]). to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [3]).
skipping to change at page 3, line 151 skipping to change at page 11, line 42
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 [5]. document are to be interpreted as described in RFC 2119 [5].
The word, "unspecified" is used to indicate functionality or features The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality cannot that are not defined in this specification. Such functionality cannot
be used in a standardized manner without further definition in an be used in a standardized manner without further definition in an
extension specification to RTSP. extension specification to RTSP.
1.3.1 RFC Editor Consideration
Please replace RFC XXXX with the RFC number this specification
recieves.
Please replace RFC YYYY with the RFC number that SAVPF [6] receives.
Please replace RFC ZZZZ with the RFC number that SDP-new [7] receives
when published.
Please replace RFC WWWW with the RFC number that RTP framing over TCP
[8] receives when published.
1.4 Terminology 1.4 Terminology
Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not
listed here are defined as in HTTP/1.1. listed here are defined as in HTTP/1.1.
Aggregate control: The concept of controlling multiple streams Aggregate control: The concept of controlling multiple streams
using a single timeline, generally maintained by the using a single timeline, generally maintained by the
server. A client, for example, uses aggregate control when server. A client, for example, uses aggregate control when
it issues a single play or pause message to simultaneously it issues a single play or pause message to simultaneously
control both the audio and video in a movie. control both the audio and video in a movie.
skipping to change at page 3, line 199 skipping to change at page 13, line 8
(playback), where the relationship is less strict. (playback), where the relationship is less strict.
Entity: The information transferred as the payload of a request Entity: The information transferred as the payload of a request
or response. An entity consists of meta-information in the or response. An entity consists of meta-information in the
form of entity-header fields and content in the form of an form of entity-header fields and content in the form of an
entity-body, as described in Section 8. entity-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.
IRI: Internationalized Resource Identifier, is the same as an
URI, with the exception that it allows characters from the
whole Universal Character Set (Unicode/ISO 10646), rather
than the US-ASCII only. See RFC 3987 [9] for more
information.
Live: Normally used to describe a presentation or session with Live: Normally used to describe a presentation or session with
media coming from an ongoing event. This generally results media coming from an ongoing event. This generally results
in that the session has a unbound or only loosely defined in that the session has a unbound or only loosely defined
duration, and that no seek operations are possible. duration, and that no seek operations are possible.
Media initialization: Datatype/codec specific initialization. Media initialization: Datatype/codec specific initialization.
This includes such things as clock rates, color tables, This includes such things as clock rates, color tables,
etc. Any transport-independent information which is etc. Any transport-independent information which is
required by a client for playback of a media stream occurs required by a client for playback of a media stream occurs
in the media initialization phase of stream setup. in the media initialization phase of stream setup.
skipping to change at page 3, line 249 skipping to change at page 14, line 15
Presentation: A set of one or more streams presented to the Presentation: A set of one or more streams presented to the
client as a complete media feed and described by a client as a complete media feed and described by a
presentation description as defined below. Presentations presentation description as defined below. Presentations
with more than one media stream is often handled in RTSP with more than one media stream is often handled in RTSP
under aggregate control. under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a information about one or more media streams within a
presentation, such as the set of encodings, network presentation, such as the set of encodings, network
addresses and information about the content. Other IETF addresses and information about the content. Other IETF
protocols such as SDP (RFC 2327 [1]) use the term "session" protocols such as SDP (RFC ZZZZ [1]) use the term "session"
for a presentation. The presentation description may take for a presentation. The presentation description may take
several different formats, including but not limited to the several different formats, including but not limited to the
session description protocol format, SDP. session description protocol format, SDP.
Response: An RTSP response. If an HTTP response is meant, that Response: An RTSP response. If an HTTP response is meant, that
is indicated explicitly. is indicated explicitly.
Request: An RTSP request. If an HTTP request is meant, that is Request: An RTSP request. If an HTTP request is meant, that is
indicated explicitly. indicated explicitly.
skipping to change at page 3, line 283 skipping to change at page 14, line 49
server. It is established by an RTSP server upon the server. It is established by an RTSP server upon the
completion of a successful SETUP request (when 200 OK completion of a successful SETUP request (when 200 OK
response is sent) and is labelled by a session identifier response is sent) and is labelled by a session identifier
at that time. The session exists until timed out by the at that time. The session exists until timed out by the
server or explicitly removed by a TEARDOWN request. An RTSP server or explicitly removed by a TEARDOWN request. An RTSP
session is a stateful entity; an RTSP server maintains an session is a stateful entity; an RTSP server maintains an
explicit session state machine (see Appendix A) where most explicit session state machine (see Appendix A) where most
state transitions are triggered by client requests. The state transitions are triggered by client requests. The
existence of a session implies the existence of state about existence of a session implies the existence of state about
the session's media streams and their respective transport the session's media streams and their respective transport
mechanisms. A given session can have zero or more media mechanisms. A given session can have one or more media
streams associated with it. An RTSP server uses the session streams associated with it. An RTSP server uses the
to aggregate control over multiple media streams. session to aggregate control over multiple media streams.
Transport initialization: The negotiation of transport Transport initialization: The negotiation of transport
information (e.g., port numbers, transport protocols) information (e.g., port numbers, transport protocols)
between the client and the server. between the client and the server.
URI: Universal Resource Identifier, see RFC 3986 [6]. In RTSP URI: Universal Resource Identifier, see RFC 3986 [10]. In RTSP
the used URIs are as general rule in fact URL's as they the used URIs are as general rule in fact URL's as they
gives an location for the resource. As URLs are a subset of gives an location for the resource. As URLs are a subset of
URIs, they will be referred to as URIs to cover also the URIs, they will be referred to as URIs to cover also the
cases when an RTSP URI would not be an URL. cases when an RTSP URI would not be an URL.
URL: Universal Resource Locator, is an URI which identifies the URL: Universal Resource Locator, is an URI which identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism, rather than
identifying the resource by name or by some other identifying the resource by name or by some other
attribute(s) of that resource. attribute(s) of that resource.
skipping to change at page 3, line 313 skipping to change at page 15, line 31
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to Extendable: New methods and parameters can be easily added to
RTSP. RTSP.
Easy to parse: RTSP can be parsed by standard HTTP or MIME Easy to parse: RTSP can be parsed by standard HTTP or MIME
parsers. parsers.
Secure: RTSP re-uses web security mechanisms, either at the Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, RFC 2246 [7]) or within the protocol transport level (TLS, RFC 2246 [11]) or within the protocol
itself. All HTTP authentication mechanisms such as basic itself. All HTTP authentication mechanisms such as basic
(RFC 2616 [3]) and digest authentication (RFC 2617 [8]) are (RFC 2616 [3]) and digest authentication (RFC 2617 [12])
directly applicable. are directly applicable.
Transport-independent: RTSP does not preclude the use of an Transport-independent: RTSP does not preclude the use of
unreliable datagram protocol (UDP) (RFC 768 [9]) as it unreliable datagram protocol (UDP) (RFC 768 [13]) as it
would be possible to implement application-level would be possible to implement application-level
reliability. The use of a connectionless datagram protocol reliability. The use of a connectionless datagram protocol
such as UDP requires additional definition that may be such as UDP requires additional definition that may be
provided as extensions to the core RTSP specification. The provided as extensions to the core RTSP specification. The
usage of the reliable stream protocol TCP (RFC 793 [10]) usage of the reliable stream protocol TCP (RFC 793 [14])
and secured reliable stream protocol TLS over TCP [7] is and secured reliable stream protocol TLS over TCP [11] is
what is currently defined as transport protocol of RTSP what is currently defined as transport protocol of RTSP
messages. messages.
Multi-server capable: Each media stream within a presentation Multi-server capable: Each media stream within a presentation
can reside on a different server. The client automatically can reside on a different server. The client automatically
establishes several concurrent control sessions with the establishes several concurrent control sessions with the
different media servers. Media synchronization is different media servers. Media synchronization is in those
performed at the transport level. cases performed at the transport level.
Separation of stream control and conference initiation: Stream Separation of stream control and conference initiation: Stream
control is divorced from inviting a media server to a control is divorced from inviting a media server to a
conference. In particular, SIP [27] or H.323 [28] may be conference. In particular, SIP [29] or H.323 [30] may be
used to invite a server to a conference. used to invite a server to a conference. However the exact
procedures are unspecified.
Suitable for professional applications: RTSP supports frame- Suitable for professional applications: RTSP supports frame-
level accuracy through SMPTE time stamps to allow remote level accuracy through SMPTE time stamps to allow remote
digital editing. digital editing.
Presentation description neutral: The protocol does not impose a Presentation description neutral: The protocol does not impose a
particular presentation description or metafile format and particular presentation description or metafile format and
can convey the type of format to be used. However, the can convey the type of format to be used. However, the
presentation description is required to contain at least presentation description is required to contain at least
one RTSP URI. one RTSP URI.
Proxy and firewall friendly: The protocol should be readily Proxy and firewall friendly: The protocol should be readily
handled by both application and transport-layer (SOCKS handled by both application and transport-layer (SOCKS
[29]) firewalls. A firewall may need to understand the [31]) firewalls. A firewall may need to understand the
SETUP method to open a "hole" for the media stream. SETUP method to open a "hole" for the media stream.
HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so
that the existing infrastructure can be reused. This that the existing infrastructure can be reused. This
infrastructure includes PICS (Platform for Internet Content infrastructure includes PICS (Platform for Internet Content
Selection [30,31]) for associating labels with content. Selection [32,33]) for associating labels with content.
However, RTSP does not just add methods to HTTP since the However, RTSP does not just add methods to HTTP since the
controlling continuous media requires server state in most controlling continuous media requires server state in most
cases. cases.
Appropriate server control: If a client can start a stream, it Appropriate server control: If a client can start a stream, it
needs to be able to stop a stream. Servers should not start needs to be able to stop a stream. Servers should not start
streaming to clients in such a way that clients cannot stop streaming to clients in such a way that clients cannot stop
the stream. the stream.
Transport negotiation: The client can negotiate the transport Transport negotiation: The client can negotiate the transport
skipping to change at page 3, line 386 skipping to change at page 17, line 8
example: example:
o A server may not be capable of seeking (absolute positioning) o A server may not be capable of seeking (absolute positioning)
if it is to support live events only. if it is to support live events only.
o Some servers may not support setting stream parameters and o Some servers may not support setting stream parameters and
thus not support GET_PARAMETER and SET_PARAMETER. thus not support GET_PARAMETER and SET_PARAMETER.
o Some server may support an RTSP extension. o Some server may support an RTSP extension.
A server SHOULD implement all header fields described in Section 14.
It is up to the creators of presentation descriptions not to ask the It is up to the creators of presentation descriptions not to ask the
impossible of a server. This situation is similar in HTTP/1.1 [3], impossible of a server. This situation is similar in HTTP/1.1 [3],
where the methods described in [H19.5] are not likely to be supported where the methods described in [H19.5] are not likely to be supported
across all servers. across all servers.
RTSP can be extended in three ways, listed here in order of the RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported: magnitude of changes supported:
o Existing methods can be extended with new parameters, e.g. o Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by headers, as long as these parameters can be safely ignored by
the recipient. If the client needs negative acknowledgement the recipient. If the client needs negative acknowledgement
when a method extension is not supported, a tag corresponding when a method extension is not supported, a tag corresponding
to the extension may be added in the Require: field (see to the extension may be added in the field of the Require or
Section 14.37). Proxy-Require headers (see Section 14.37).
o New methods can be added. If the recipient of the message does o New methods can be added. If the recipient of the message does
not understand the request, it responds with error code 501 not understand the request, it responds with error code 501
(Not Implemented) and the sender should not attempt to use (Not Implemented) and the sender can avoid using this method
this method again. A client may also use the OPTIONS method to again. A client may also use the OPTIONS method to inquire
inquire about methods supported by the server. The server MUST about methods supported by the server. The server list the
list the methods it supports using the Public response header. methods it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost o A new version of the protocol can be defined, allowing almost
all aspects (except the position of the protocol version all aspects (except the position of the protocol version
number) to change. number) to 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 support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of this available when performing a request. For detailed explanation of this
see section 10. see section 10.
skipping to change at page 3, line 453 skipping to change at page 18, line 25
that server. Several media streams can be located on different that server. Several media streams can be located on different
servers; for example, audio and video streams can be split across servers; for example, audio and video streams can be split across
servers for load sharing. The description also enumerates which servers for load sharing. The description also enumerates which
transport methods the server is capable of. transport methods 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 port need to be determined. Several modes of operation can be
distinguished: distinguished:
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. request or the requested destination, with the port number
Alternatively, the media is transmitted on the same chosen by the client. Alternatively, the media is
reliable stream as RTSP. transmitted on the same reliable stream as RTSP.
Multicast, server chooses address: The media server picks the Multicast, server chooses address: The media server picks the
multicast address and port. This is the typical case for a multicast address and port. This is the typical case for a
live or near-media-on-demand transmission. live or near-media-on-demand transmission.
Multicast, client chooses address: If the server is to Multicast, client chooses address: If the server is to
participate in an existing multicast conference, the participate in an existing multicast conference, the
multicast address, port and encryption key are given by the multicast address, port and encryption key are given by the
conference description, established by means outside the conference description, established by means outside the
scope of this specification, for example by a SIP created scope of this specification, for example by a SIP created
skipping to change at page 3, line 582 skipping to change at page 21, line 12
presentation. The setup itself consist of determining which presentation. The setup itself consist of determining which
protocols for media transport to use; the necessary protocols for media transport to use; the necessary
parameters for the protocol, like addresses and ports. .XP parameters for the protocol, like addresses and ports. .XP
Control of Transmission: After the necessary media streams Control of Transmission: After the necessary media streams
has been established the client can request the server to has been established the client can request the server to
start transmitting the content. There is need to allow the start transmitting the content. There is need to allow the
client to at arbitrary times start or stop the transmission client to at arbitrary times start or stop the transmission
of the content. There are also exist need to be able to of the content. There are also exist need to be able to
start the transmission at an any point in the timeline of start the transmission at an any point in the timeline of
the presentation. .XP Synchronization: For media transport the presentation. .XP Synchronization: For media transport
protocols like RTP [16] it might be beneficial to carry protocols like RTP [18] it might be beneficial to carry
synchronization information within RTSP. Either due to the synchronization information within RTSP. Either due to the
lack of inter media synchronization within the protocol lack of inter media synchronization within the protocol
itself, or the potential delay before the synchronization itself, or the potential delay before the synchronization
is established (which is the case for RTP when using RTCP). is established (which is the case for RTP when using RTCP).
.XP Termination There is also need to be able to terminate .XP Termination There is also need to be able to terminate
the established contexts. the established contexts.
For this use cases there is a number of assumption about how it For this use cases there is a number of assumption about how it
works. These are listed below: works. These are listed below:
On-Demand content: The content available is stored at the server On-Demand content: The content available is stored at the server
and can be accessed at any time during a time period when and can be accessed at any time during a time period when
it is intended to be available. .XP Independent sessions: A it is intended to be available. .XP Independent sessions: A
server is capable of serving a number of clients server is capable of serving a number of clients
simultaneously, including from the same piece of content at simultaneously, including from the same piece of content at
different points in that presentations time-line. .XP different points in that presentations time-line. .XP
Unicast Transport: Content for each individual client is Unicast Transport: Content for each individual client is
transmitted to them using unicast traffic. transmitted to them using unicast traffic.
It is also possible to redirect the media traffic to another It is also possible to redirect the media traffic to another
destination than where the entity controlling traffic uses. destination than where the entity controlling traffic uses.
However allowing this without appropriate mechanisms for However allowing this without appropriate mechanisms for
checking that the destination approves of this is allows for checking that the destination approves of this allows for
distributed denial of service attacks (DDoS). distributed denial of service attacks (DDoS).
2.2 Unicast distribution of Live Content 2.2 Unicast distribution of Live Content
This use cases is not that different from the above on-demand content This use cases is not that different from the above on-demand content
case (see section 2.1. The difference is really the restriction the case (see section 2.1. The difference is really the restriction the
content itself establish. Live content is continuously distributed as content itself establish. Live content is continuously distributed as
it becomes available from a source, i.e. the main difference to on- it becomes available from a source, i.e. the main difference to on-
demand is that one starts distributing content before the end of it demand is that one starts distributing content before the end of it
has become available to the server. In many cases the consumer of has become available to the server. In many cases the consumer of
skipping to change at page 3, line 641 skipping to change at page 22, line 23
multicast group. The entity setting up the session (the controller) multicast group. The entity setting up the session (the controller)
will then control when and what media that is delivered to the group. will then control when and what media that is delivered to the group.
Also this use case has some potential for denial of service attacks, Also this use case has some potential for denial of service attacks,
in this case flooding any multicast group. Therefore there is need in this case flooding any multicast group. Therefore there is need
for a mechanism indicating that the group actually accepts the for a mechanism indicating that the group actually accepts the
traffic from the RTSP server. An open issue in this use case is how traffic from the RTSP server. An open issue in this use case is how
one ensures that all receivers listening to the multicast or one ensures that all receivers listening to the multicast or
broadcast receives the session presentation configuring the broadcast receives the session presentation configuring the
receivers. receivers.
2.4 Inviting a RTSP server into a conference 2.4 Inviting an RTSP server into a conference
If one has an established conference or group session, it is possible If one has an established conference or group session, it is possible
to have a RTSP server distribute media to the whole group. The to have a RTSP server distribute media to the whole group. The
transmission to the group is simplest controlled by a single transmission to the group is simplest controlled by a single
participant or leader of the conference. Shared control might be participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly possible, but would require further investigation and possibly
extensions. There are some protocol mechanisms missing for this extensions. For reasonable complexity in the media transmission
scenario. For reasonable complexity in the media transmission stage, stage, this use case assumes that there exist either multicast or a
this use case assumes that there exist either multicast or a
conference focus that redistribute media to all participants. In some conference focus that redistribute media to all participants. In some
more detail, this use case is intended to be able to handle the more detail, this use case is intended to be able to handle the
following scenario: A conference leader or participant (from here following scenario: A conference leader or participant (from here
called the controller) has some pre-stored content on a RTSP server called the controller) has some pre-stored content on a RTSP server
that he likes to share with the group. The controller sets up an RTSP that he likes to share with the group. The controller sets up an RTSP
session at the streaming server for the content the controller likes session at the streaming server for the content the controller likes
to share. The session description for the content is retrieved by the to share. The session description for the content is retrieved by the
controller. The media destination for the media content is sent to controller. The destination for the media content is set to the
the shared multicast group or conference focus. When desired by the shared multicast group or conference focus. When desired by the
controller, he/she can start and stop the transmission of the media controller, he/she can start and stop the transmission of the media
to the conference group. There are several issues with this use case to the conference group. There are several issues with this use case
that is not solved by this core specification for RTSP: that is not solved by this core specification for RTSP:
o Denial of service threat, to avoid a RTSP server from being a o Denial of service threat, to avoid a RTSP server from being a
unknowing participant of a denial of service attack the server unknowing participant of a denial of service attack the server
needs to be able to verify the destinations acceptance for the needs to be able to verify the destinations acceptance for the
media. Such a mechanism does not yet exist that can be used to media. Such a mechanism does not yet exist that can be used to
verify the approval to received media, instead only policies verify the approval to received media, instead only policies
can be used, which can be made to work in controlled can be used, which can be made to work in controlled
skipping to change at page 3, line 715 skipping to change at page 23, line 48
information that is desirable to be done on a per receiver basis, and information that is desirable to be done on a per receiver basis, and
the receivers are not know prior to the session start, the state the receivers are not know prior to the session start, the state
establishment that RTSP provides can be beneficial. In this case a establishment that RTSP provides can be beneficial. In this case a
client would establish a RTSP session to the multicast group. The client would establish a RTSP session to the multicast group. The
RTSP server will not transmit any media, instead it will simply point RTSP server will not transmit any media, instead it will simply point
to the multicast group. However the client and server will be able to to the multicast group. However the client and server will be able to
keep the session alive for as long as the receiver participates in keep the session alive for as long as the receiver participates in
the session. Thus enabling, for example server to client pushes of the session. Thus enabling, for example server to client pushes of
updates. This use cases will most likely not be able to actually updates. This use cases will most likely not be able to actually
implement without some extensions in relation to the server to client implement without some extensions in relation to the server to client
push mechanism. Here a method like ANNOUNCE (see RFC 2326 [24] might push mechanism. Here a method like ANNOUNCE (see RFC 2326 [27] might
be suitable, however it will require a RTSP extension to revive the be suitable, however it will require a RTSP extension to revive the
method. method.
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 2.0 of RTSP. RTSP. This specification defines version 2.0 of RTSP.
3.2 RTSP URI 3.2 RTSP IRI and URI
The "rtsp", "rtsps" schemes are used to refer to network resources
via the RTSP protocol. This section defines the scheme-specific
syntax and semantics for RTSP URIs. The RTSP URI is case sensitive.
An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP
messages over unreliable transport (UDP) and is currently deprecated
and reserved, and MUST NOT be used . See Appendix E for further
information.
Informative RTSP URI syntax: RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and
"rtspu". The usage of the last in RTSP 2.0, "rtspu", is unspecified,
and is done to register and reserve the URI scheme that is defined by
RTSP 1.0. The "rtspu" scheme indicate transport of the RTSP messages
over unreliable transport (UDP). The syntax of "rtsp" and "rtsps"
URIs has been changed compared with RTSP 1.0.
rtsp[u|s]://host[:port]/abspath[?query]#fragment This specification also defines the format of the RTSP IRI [9] that
can used as RTSP resource identifiers and locators, in web pages,
user interfaces, on paper, etc. However the RTSP request message
format does only allow usage of the absolute URI format. The RTSP IRI
format SHALL use the rules and transformation for IRIs defined in RFC
3987 [9]. That way RTSP 2.0 URIs for request can be produced from an
RTSP IRI.
See section 19.2.1 for the formal definition of the RTSP URI syntax. The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in RFC 3986 [10] and RFC 3987 [9];
The fragment identifier is used as defined in section 4.1 of [6], o An absolute URI requires the authority part, i.e. a host
identity must be provided.
o parameters in the path element are prefixed with the reserved
separator ";".
The RTSP URI and IRI is case sensitive, with the exception of those
parts that RFC 3986 [10] and RFC 3987 [9] defines as case-
insensitive. For example the scheme and host part.
The fragment identifier is used as defined in section 4.1 of [10],
i.e. the fragment is to be stripped from the URI by the requestor and i.e. the fragment is to be stripped from the URI by the requestor and
not included in the request. The user agent also needs to interpret not included in the request. The user agent also needs to interpret
the value of the fragment based on the media type the request relates the value of the fragment based on the media type the request relates
to, i.e. the media type indicated in Content-Type header in the to, i.e. the media type indicated in Content-Type header in the
response to DESCRIBE. response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. As it is from the requestor an opaque (usually the server) specific. As it is from the requestor an opaque
string, it needs to be handled as such. string, it needs to be handled as such.
The URI scheme rtsp requires that commands are issued via a reliable The URI scheme rtsp requires that commands are issued via a reliable
protocol (within the Internet, TCP), while the scheme rtsps protocol (within the Internet, TCP), while the scheme rtsps
identifies a reliable transport using secure transport (TLS [7]). identifies a reliable transport using secure transport (TLS [11]),
see Section 18.
If the no port number is provided in the URI, port number 554 SHALL If the no port number is provided in the authority part of the URI,
be used. The semantics are that the identified resource can be port number 554 SHALL be used. The semantics are that the identified
controlled by RTSP at the server listening for TCP (scheme "rtsp") resource can be controlled by RTSP at the server listening for TCP
connections on that port of host, and the Request-URI for the (scheme "rtsp") connections on that port of host, and the Request-URI
resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322 for the resource is rtsp_URI. For the scheme rtsps the TCP port 322
is registered and SHALL be assumed. is registered and SHALL be assumed.
The use of IP addresses in URIs SHOULD be avoided whenever possible
(see RFC 1924 [11]). This specification updates the RTSP URI scheme
to allow for literal IPv6 addresses using the host specification in
RFC 2732 [12].
Note: Using qualified domain names in any URI is one
requirement for making it possible for RTSP 1.0 (RFC 2326)
implementations of RTSP to use IPv6.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions [H3.2] of identifier, using the character set and escape conventions of URIs
URIs (RFC 3986 [6]). URIs may refer to a stream or an aggregate of (RFC 3986 [10]). URIs may refer to a stream or an aggregate of
streams, i.e., a presentation. Accordingly, requests described in streams, i.e., a presentation. Accordingly, requests described in
Section 11 can apply to either the whole presentation or an Section 11 can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations and vice methods can only be applied to streams, not presentations and vice
versa. versa.
For example, the RTSP URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com connection to port 554 of host media.example.com
Also, the RTSP URI: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams. and video streams, but can also be something else like a random media
redirector.
This does not imply a standard way to reference streams in This does not imply a standard way to reference streams in
URIs. The presentation description defines the hierarchical URIs. The presentation description defines the hierarchical
relationships in the presentation and the URIs for the relationships in the presentation and the URIs for the
individual streams. A presentation description may name a individual streams. A presentation description may name a
stream "a.mov" and the whole presentation "b.mov". stream "a.mov" and the whole presentation "b.mov".
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
skipping to change at page 3, line 841 skipping to change at page 26, line 42
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
3.5 Normal Play Time 3.5 Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [32]. The timestamp consists of with the Network Time Protocol (NTP) [34]. The timestamp consists of
a decimal fraction. The part left of the decimal may be expressed in a decimal fraction. The part left of the decimal may be expressed in
either seconds or hours, minutes, and seconds. The part right of the either seconds or hours, minutes, and seconds. The part right of the
decimal point measures fractions of a second. decimal point measures fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. The special constant now is defined as the values are not defined. The special constant now is defined as the
current instant of a live type event. It MAY only be used for live current instant of a live type event. It MAY only be used for live
type events, and SHALL NOT be used for on-demand content. type events, and SHALL NOT be used for on-demand content.
NPT is defined as in DSM-CC [33]: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC [35]: "Intuitively, NPT is the clock the
viewer associates with a program. It is often digitally displayed on viewer associates with a program. It is often digitally displayed on
a VCR. NPT advances normally when in normal play mode (scale = 1), a VCR. NPT advances normally when in normal play mode (scale = 1),
advances at a faster rate when in fast scan forward (high positive advances at a faster rate when in fast scan forward (high positive
scale ratio), decrements when in scan reverse (high negative scale scale ratio), decrements when in scan reverse (high negative scale
ratio) and is fixed in pause mode. NPT is (logically) equivalent to ratio) and is fixed in pause mode. NPT is (logically) equivalent to
SMPTE time codes." SMPTE time codes."
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601 [34]. The npt-sec notation The syntax conforms to ISO 8601 [36]. The npt-sec notation
is optimized for automatic generation, the ntp-hhmmss is optimized for automatic generation, the ntp-hhmmss
notation for consumption by human readers. The "now" notation for consumption by human readers. The "now"
constant allows clients to request to receive the live feed constant allows clients to request to receive the live feed
rather than the stored or time-delayed version. This is rather than the stored or time-delayed version. This is
needed since neither absolute time nor zero time are needed since neither absolute time nor zero time are
appropriate for this case. appropriate for this case.
3.6 Absolute Time 3.6 Absolute Time
Absolute time is expressed as ISO 8601 [34] timestamps, using UTC Absolute time is expressed as ISO 8601 [36] timestamps, using UTC
(GMT). Fractions of a second may be indicated. (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
3.7 Feature-tags 3.7 Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
skipping to change at page 3, line 904 skipping to change at page 28, line 14
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA), see feature-tag with the Internet Assigned Numbers Authority (IANA), see
IANA Section 21. IANA Section 21.
The usage of feature tags are further described in section 10 that The usage of feature tags are further described in section 10 that
deals with capability handling. deals with capability handling.
3.8 Entity Tags 3.8 Entity Tags
Entity tags are opaque strings that are used to compare two entities Entity tags are opaque strings that are used to compare two entities
from the same resource, for example in caches or to optimize setup from the same resource, for example in caches or to optimize setup
after a redirect. Further explanation is present in [H3.11]. For after a redirect. Further explanation is present in [H3.11]. For
explanation on how to compare Entity tags see [H13.3]. Entity tags explanation on how to compare Entity tags see [H13.3]. Entity tags
can be carried in the ETag header (see section 14.21) or in SDP (see can be carried in the ETag header (see section 14.21) or in SDP (see
section C.1.8). section C.1.8).
Entity tags are used in RTSP to make some methods conditional. The Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see methods are made conditional through the inclusion of headers, see
14.25 and 14.27. 14.24 and 14.26. Note that for RTSP entity tags applies to the
complete presentation, i.e. both session description, and the
individual media streams. Thus entity tags can be used to verify at
setup time after a redirect that the same session description applies
to the media at the new location using the If-Match header.
4 RTSP Message 4 RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [13]). Lines SHALL be terminated by CRLF. UTF-8 encoding (RFC 3629 [15]). Lines SHALL be terminated by CRLF.
Text-based protocols make it easier to add optional Text-based protocols make it easier to add optional
parameters in a self-describing manner. Since the number of parameters in a self-describing manner. Since the number of
parameters and the frequency of commands is low, processing parameters and the frequency of commands is low, processing
efficiency is not a concern. Text-based protocols, if done efficiency is not a concern. Text-based protocols, if done
carefully, also allow easy implementation of research carefully, also allow easy implementation of research
prototypes in scripting languages such as Tcl, Visual Basic prototypes in scripting languages such as Tcl, Visual Basic
and Perl. and Perl.
The 10646 character set avoids tricky character set switching, but is The 10646 character set avoids tricky character set switching, but is
invisible to the application as long as US-ASCII is being used. This invisible to the application as long as US-ASCII is being used. This
is also the encoding used for RTCP. ISO 8859-1 translates directly is also the encoding used for RTCP. ISO 8859-1 translates directly
into Unicode with a high-order octet of zero. ISO 8859-1 characters into Unicode with a high-order octet of zero. ISO 8859-1 characters
with the most-significant bit set are represented as 1100001x with the most-significant bit set are represented as 1100001x
10xxxxxx. (See RFC 2279 [13]) 10xxxxxx. (See RFC 3629 [15])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent, parameters to further describe the method. Methods are idempotent,
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
4.1 Message Types 4.1 Message Types
See [H4.1]. See [H4.1].
skipping to change at page 3, line 1022 skipping to change at page 30, line 43
o Optionally a message body (entity), consisting of one or more o Optionally a message body (entity), consisting of one or more
lines. the length of the message body in number of bytes is lines. the length of the message body in number of bytes is
indicated by the Content-Length entity header. indicated by the Content-Length entity header.
6.1 Request Line 6.1 Request Line
The request line provides the key information about the request: The request line provides the key information about the request:
What method, on what resources and using which RTSP version. The What method, on what resources and using which RTSP version. The
methods that are defined by this specification are listed in Table 2. methods that are defined by this specification are listed in Table 2.
The syntax of the RTSP request line is the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Method Defined In Section Method Defined In Section
_________________________________ _________________________________
DESCRIBE Section 11.2 DESCRIBE Section 11.2
GET_PARAMETER Section 11.7 GET_PARAMETER Section 11.7
OPTIONS Section 11.1 OPTIONS Section 11.1
PAUSE Section 11.5 PAUSE Section 11.5
PLAY Section 11.4 PLAY Section 11.4
REDIRECT Section 11.9 REDIRECT Section 11.9
SETUP Section 11.3 SETUP Section 11.3
SET_PARAMETER Section 11.8 SET_PARAMETER Section 11.8
TEARDOWN Section 11.6 TEARDOWN Section 11.6
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [3], RTSP requests identify the resource In contrast to HTTP/1.1 [3], RTSP requests identify the resource
through an absolute RTSP URI (scheme, host, and port)(see section through an absolute RTSP URI (scheme, host, and port)(see section
3.2) rather than just the absolute path. 3.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, HTTP/1.1 requires servers to understand the absolute URI,
but clients are supposed to use the Host request header. but clients are supposed to use the Host request header.
This is purely needed for backward-compatibility with This is purely needed for backward-compatibility with
HTTP/1.0 servers, a consideration that does not apply to HTTP/1.0 servers, a consideration that does not apply to
RTSP. RTSP.
An asterisk "*" can be used in the Request-URI to indicate that the An asterisk "*" can be used instead of an absolute URI in the
request does not apply to a particular resource, but to the server or Request-URI part to indicate that the request does not apply to a
proxy itself, and is only allowed when the request method does not particular resource, but to the server or proxy itself, and is only
necessarily apply to a resource. allowed when the request method does not necessarily apply to a
resource.
For example: For example:
OPTIONS * RTSP/2.0 OPTIONS * RTSP/2.0
An OPTIONS in this form will determine the capabilities of the server An OPTIONS in this form will determine the capabilities of the server
or the proxy that first receives the request. If the capability of or the proxy that first receives the request. If the capability of
the specific server needs to be determined, without regard to the the specific server needs to be determined, without regard to the
capability of an intervening proxy, the server should be addressed capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address. explicitly with an absolute URI that contains the server's address.
For example: For example:
OPTIONS rtsp://example.com RTSP/2.0 OPTIONS rtsp://example.com RTSP/2.0
6.2 Request Header Fields 6.2 Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table 3 can be included in a request, as request
headers, to modify the specifics of the request. These headers may headers, to modify the specifics of the request. Some of these
also be used in the response to a request, as response headers, to headers may also be used in the response to a request, as response
modify the specifics of a response (Section 7.1.2). headers, to modify the specifics of a response (Section 7.2).
Detailed headers definition are provided in Section 14.
Header Defined in Section Header Defined in Section
_____________________________________ _____________________________________
Accept Section 14.1 Accept Section 14.1
Accept-Encoding Section 14.3 Accept-Encoding Section 14.3
Accept-Language Section 14.4 Accept-Language Section 14.4
Authorization Section 14.7 Authorization Section 14.7
Bandwidth Section 14.8 Bandwidth Section 14.8
Blocksize Section 14.9 Blocksize Section 14.9
From Section 14.23 From Section 14.23
If-Match Section 14.25 If-Match Section 14.24
If-Modified-Since Section 14.26 If-Modified-Since Section 14.25
If-None-Match Section 14.27 If-None-Match Section 14.26
Proxy-Require Section 14.31 Proxy-Require Section 14.31
Range Section 14.34 Range Section 14.34
Referer Section 14.35 Referer Section 14.35
Require Section 14.37 Require Section 14.37
Scale Section 14.39 Scale Section 14.39
Session Section 14.42 Session Section 14.42
Speed Section 14.40 Speed Section 14.40
Supported Section 14.43 Supported Section 14.43
Transport Section 14.45 Transport Section 14.45
User-Agent Section 14.47 User-Agent Section 14.47
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 14.
New request headers may be defined. If it is required of the receiver
of the request to understand the request header, the request must
include a feature tag in Require or Proxy-Require header representing
the functionality to ensure the correct processing of the header.
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 of the HTTP codes. The valid response codes and the methods they can
with are defined in Table 4. be used with are listed in Table 4.
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. responds with an RTSP response message.
7.1 Status-Line 7.1 Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code, and the of the protocol version followed by a numeric status code, and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
skipping to change at page 3, line 1176 skipping to change at page 34, line 28
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 x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
7.1.2 Response Header Fields 7.2 Response Header Fields
The response-header fields allow the request recipient to pass The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the the Status-Line. These header fields give information about the
server and about further access to the resource identified by the server and about further access to the resource identified by the
Request-URI. All headers currently being classified as response Request-URI. All headers currently being classified as response
headers are listed in table 5. headers are listed in table 5.
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However the usage
experimental header fields MAY be given the semantics of response- of feature tags in the request allows the responding party to learn
header fields if all parties in the communication recognize them to the capability of the receiver of the response. New or experimental
be response-header fields. Unrecognized header fields are treated as header fields MAY be given the semantics of response-header fields if
entity-header fields. all parties in the communication recognize them to be response-header
fields. Unrecognized header fields are treated as entity-header
fields.
8 Entity 8 Entity
Request and Response messages MAY transfer an entity if not otherwise Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
The SET_PARAMETER, and GET_PARAMETER request and response, and The SET_PARAMETER, and GET_PARAMETER request and response, and
DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY
also have an entity. also have an entity.
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 meta-information about the entity-body
entity-body or, if no body is present, about the resource identified or, if no body is present, about the resource identified by the
by the request. The entity header fields are listed in table 8.1. request. The entity header fields are listed in table 8.1.
Header Defined in Section
____________________________________
Allow Section 14.6
Content-Base Section 14.13
Content-Encoding Section 14.14
Content-Language Section 14.15
Content-Length Section 14.16
Content-Location Section 14.17
Content-Type Section 14.18
Expires Section 14.22
Last-Modified Section 14.27
Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies. fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body 8.2 Entity Body
See [H7.2] with the addition that an RTSP message with an entity body See [H7.2] with the addition that an RTSP message with an entity body
MUST include the Content-Type and Content-Length headers. MUST include the Content-Type and Content-Length headers.
9 Connections 9 Connections
RTSP requests can be transmitted over two different connection RTSP requests can be transmitted over two different connection
scenarios listed below: scenarios listed below:
o persistent - transport connections used for several
request/response transactions;
o transient - transport connections used for a single
request/response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient enough detail to
allow for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect is that RTSP
requests SHALL NOT be sent to multicast groups since no connection
can be established with a specific receiver in multicast
environments.
Certain RTSP headers, such as the CSeq header (Section 14.19), which
may appear to be relevant to only connectionless transport scenarios
are still retained and must be implemented according to the
specification. In the case of CSeq it is quite useful in proxy
situations for keeping track of the different request when
aggregating several client requests to a single TCP connection.
9.1 Reliability and Acknowledgements
Since RTSP is transmitted primarily over connection oriented,
reliable transport protocols, all RTSP requests MUST be acknowledged
by the receiver. RTSP requests that are not immediately acknowledged
MUST NOT be retransmitted at the application level. Instead, the
application must rely on the underlying transport to provide
reliability.
If both the underlying reliable transport such as TCP and
the RTSP application retransmit requests, each packet loss
or message loss may result in two retransmissions. The
receiver typically cannot take advantage of the
application-layer retransmission since the transport stack
will not deliver the application-layer retransmission
Code Reason Method Code Reason Method
__________________________________________________________ __________________________________________________________
100 Continue all 100 Continue all
__________________________________________________________ __________________________________________________________
200 OK all 200 OK all
201 Reserved n/a 201 Reserved n/a
250 Reserved n/a 250 Reserved n/a
__________________________________________________________ __________________________________________________________
300 Multiple Choices all 300 Multiple Choices all
skipping to change at page 3, line 1324 skipping to change at page 37, line 11
502 Bad Gateway all 502 Bad Gateway all
503 Service Unavailable all 503 Service Unavailable all
504 Gateway Timeout all 504 Gateway Timeout all
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
Header Defined in Section Header Defined in Section
__________________________________________ __________________________________________
Accept-Ranges Section 14.5 Accept-Ranges Section 14.5
Connection-Credentials Section 14.12 Connection-Credentials Section 14.12
ETag Section 14.21 ETag Section 14.21
Location Section 14.29 Location Section 14.28
Proxy-Authenticate Section 14.30 Proxy-Authenticate Section 14.29
Public Section 14.33 Public Section 14.33
Range Section 14.34 Range Section 14.34
Retry-After Section 14.36 Retry-After Section 14.36
RTP-Info Section 14.38 RTP-Info Section 14.38
Scale Section 14.39 Scale Section 14.39
Session Section 14.42 Session Section 14.42
Server Section 14.41 Server Section 14.41
Speed Section 14.40 Speed Section 14.40
Transport Section 14.45 Transport Section 14.45
Unsupported Section 14.46 Unsupported Section 14.46
Vary Section 14.48 Vary Section 14.48
WWW-Authenticate Section 14.50 WWW-Authenticate Section 14.50
Table 5: The RTSP response headers Table 5: The RTSP response headers
Header Defined in Section o persistent - transport connections used for several
request/response transactions;
____________________________________ o transient - transport connections used for a single
Allow Section 14.6 request/response transaction.
Content-Base Section 14.13
Content-Encoding Section 14.14
Content-Language Section 14.15
Content-Length Section 14.16
Content-Location Section 14.17
Content-Type Section 14.18
Expires Section 14.22
Last-Modified Section 14.28
Table 6: The RTSP entity headers RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient enough detail to
allow for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect is that RTSP
requests SHALL NOT be sent to multicast groups since no connection
can be established with a specific receiver in multicast
environments.
Certain RTSP headers, such as the CSeq header (Section 14.19), which
may appear to be relevant to only connectionless transport scenarios
are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful in proxy
situations for keeping track of the different request when
aggregating several client requests on a single TCP connection.
9.1 Reliability and Acknowledgements
When RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication
of reception acknowledgement of the message from the underlying
transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport such as TCP and
the RTSP application retransmit requests, each packet loss
or message loss may result in two retransmissions. The
receiver typically cannot take advantage of the
application-layer retransmission since the transport stack
will not deliver the application-layer retransmission
before the first attempt has reached the receiver. If the before the first attempt has reached the receiver. If the
packet loss is caused by congestion, multiple packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the retransmissions at different layers will exacerbate the
congestion. congestion.
Lack of acknowledgement of an RTSP request should be handled within Lack of acknowledgement of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 9.4). below (Section 9.4).
9.2 Using Connections 9.2 Using Connections
skipping to change at page 3, line 1384 skipping to change at page 38, line 48
Transient connections facilitate mechanisms for fault Transient connections facilitate mechanisms for fault
tolerance. They also allow for application layer mobility. tolerance. They also allow for application layer mobility.
A server and client pair that support transient connections A server and client pair that support transient connections
can survive the loss of a TCP connection, e.g. due to a NAT can survive the loss of a TCP connection, e.g. due to a NAT
timeout. When the client has discovered that the TCP timeout. When the client has discovered that the TCP
connection has been lost, it can set up a new one when connection has been lost, it can set up a new one when
there is need to communicate again. there is need to communicate again.
A persistent connection MAY be used for all transactions between the A persistent connection MAY be used for all transactions between the
server and client, including messages to multiple RTSP sessions. server and client, including messages for multiple RTSP sessions.
However a persistent connection MAY also be closed after a few However a persistent connection MAY also be closed after a few
message exchanges. For example, a client may use a persistent message exchanges. For example, a client may use a persistent
connection for the initial SETUP and PLAY message exchanges in a connection for the initial SETUP and PLAY message exchanges in a
session and then close the connection. Later, when the client wishes session and then close the connection. Later, when the client wishes
to send a new request, such as a PAUSE for the session, a new to send a new request, such as a PAUSE for the session, a new
connection would be opened. This connection may either be transient connection would be opened. This connection may either be transient
or persistent. or persistent.
A client SHOULD NOT have more than one connection to the server at An RTSP agent SHOULD NOT have more than one connection to the server
any given point. If a client or proxy handles multiple RTSP sessions at any given point. If a client or proxy handles multiple RTSP
on the same server, it SHOULD use only one connection for managing sessions on the same server, it SHOULD use only one connection for
those sessions. managing those sessions.
This saves connection resources on the server. It also This saves connection resources on the server. It also
reduces complexity by and enabling the server to maintain reduces complexity by and enabling the server to maintain
less state about its sessions and connections. less state about its sessions and connections.
Unlike HTTP, RTSP allows a server to send requests to a client. Unlike HTTP, RTSP allows a server to send requests to a client.
However, this can be supported only if a client establishes a However, this can be supported only if a client establishes a
persistent connection with the server. In cases where a persistent persistent connection with the server. In cases where a persistent
connection does not exist between a server and its client, due to the connection does not exist between a server and its client, due to the
lack of a signalling channel, the server may be forced to drop an lack of a signalling channel, the server may be forced to drop an
skipping to change at page 3, line 1613 skipping to change at page 43, line 42
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 required required PAUSE C -> S P,S required required
PLAY C -> S P,S required required PLAY C -> S P,S required required
REDIRECT S -> C P,S optional required REDIRECT S -> C P,S optional required
SETUP C -> S S required required SETUP C -> S S required required
SET_PARAMETER C -> S, S -> C P,S required optional SET_PARAMETER C -> S, S -> C P,S required optional
TEARDOWN C -> S P,S required required TEARDOWN C -> S P,S required required
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Respond, (P: presentation, S: stream) they operate on. Legend: R=Respond,
Sd=Send, Opt: Optional, Req: Required, Rec: Recommended Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GET_PARAMETER is recommended, but not Note on Table 7: GET_PARAMETER is recommended, but not
required. For example, a fully functional server can be required. For example, a fully functional server can be
built to deliver media without any parameters. built to deliver media without any parameters.
SET_PARAMETER is required however due to its usage for SET_PARAMETER is required however due to its usage for
keep-alive. PAUSE is now required due to that it is the keep-alive. PAUSE is now required due to that it is the
only way of getting out of the state machines play state only way of getting out of the state machines play state
without terminating the whole session. without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
skipping to change at page 3, line 1685 skipping to change at page 45, line 21
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play.basic Supported: play.basic
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Supported: play.basic, implicit-play, gzipped-messages Supported: play.basic, implicit-play, gzipped-messages
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Require and Proxy-Require are
necessarily fictional features (one would hope that we would not fictional features.
purposefully overlook a truly useful feature just so that we could
have a strong example in this section).
11.2 DESCRIBE 11.2 DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond description formats that it understands. The server SHALL respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
Example: Example:
skipping to change at page 3, line 1779 skipping to change at page 47, line 24
change the transport parameters. change the transport parameters.
The Transport header, see section 14.45, specifies the transport The Transport header, see section 14.45, specifies the transport
parameters acceptable to the client for data transmission; the parameters acceptable to the client for data transmission; the
response will contain the transport parameters selected by the response will contain the transport parameters selected by the
server. This allows the client to enumerate in priority order the server. This allows the client to enumerate in priority order the
transport mechanisms and parameters acceptable to it, while the transport mechanisms and parameters acceptable to it, while the
server can select the most appropriate. It is expected that the server can select the most appropriate. It is expected that the
session description format used will enable the client to select a session description format used will enable the client to select a
limited number possible configurations that are offered to the server limited number possible configurations that are offered to the server
to choose from. All transport parameters SHOULD be included in the to choose from. All transport related parameters shall be included in
Transport header, the use of other headers for this purpose is the Transport header, the use of other headers for this purpose is
discouraged due to middle boxes such as firewalls, or NATs. discouraged due to middle boxes such as firewalls, or NATs.
For the benefit of any intervening firewalls, a client SHOULD For the benefit of any intervening firewalls, a client SHALL indicate
indicate the transport parameters even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address. multicast address as destination.
Since SETUP includes all transport initialization Since SETUP includes all transport initialization
information, firewalls and other intermediate network information, firewalls and other intermediate network
devices (which need this information) are spared the more devices (which need this information) are spared the more
arduous task of parsing the DESCRIBE response, which has arduous task of parsing the DESCRIBE response, which has
been reserved for media initialization. been reserved for media initialization.
In a SETUP response the server SHOULD include the Accept-Ranges The client SHALL include the Accept-Ranges header in the request
header (see section 14.5 to indicate which time formats that are indicating all supported unit formats in the Range header. This
acceptable to use for this media resource. allows the server to know which format it may use in future session
related responses, such as PLAY response without any range in the
request. If the client does not support a time format necessary for
the presentation the server SHALL respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource.
In a SETUP response the server SHALL include the Accept-Ranges header
(see section 14.5 to indicate which time formats that are acceptable
to use for this media resource.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/2.0 200 OK S->C: RTSP/2.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.1 Server: PhonyServer 1.1
skipping to change at page 3, line 1826 skipping to change at page 48, line 33
RTP/AVP/UDP (UDP per default) to be received on client port 4588 and RTP/AVP/UDP (UDP per default) to be received on client port 4588 and
4589 or RTP/AVP interleaved on the RTSP control channel. The server 4589 or RTP/AVP interleaved on the RTSP control channel. The server
selects the RTP/AVP/UDP transport and adds the ports it will send and selects the RTP/AVP/UDP transport and adds the ports it will send and
received RTP and RTCP from, and the RTP SSRC that will be used by the received RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier, in which case the server MUST bundle this setup a session identifier, in which case the server MUST bundle this setup
request into the existing session (aggregated session) or return request into the existing session (aggregated session) or return
error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). An
Aggregate control URI MUST be used to control an aggregated session.
An Aggregate control URI MUST be used to control an aggregated This URI MUST be different from the stream control URIs of the
session. This URI MUST be different from the stream control URIs of individual media streams included in the aggregate. The Aggregate
the individual media streams included in the aggregate. The Aggregate
control URI is to be specified by the session description if the control URI is to be specified by the session description if the
server supports aggregated control and aggregated control is desired server supports aggregated control and aggregated control is desired
for the session. However even if aggregated control is offered the for the session. However even if aggregated control is offered the
client MAY chose to not set up the session in aggregated control. If client MAY chose to not set up the session in aggregated control. If
an Aggregate control URI is not specified in the session description, an Aggregate control URI is not specified in the session description,
it is normally an indication that non-aggregated control should be it is normally an indication that non-aggregated control should be
used. The SETUP of media streams in an aggregate which has not been used. The SETUP of media streams in an aggregate which has not been
given an aggregated control URI is unspecified. given an aggregated control URI is unspecified.
While the session ID sometimes has enough information for While the session ID sometimes has enough information for
skipping to change at page 3, line 1875 skipping to change at page 49, line 35
Reports may for example be received in sessions where the Reports may for example be received in sessions where the
server is invited into a conference session and is as valid server is invited into a conference session and is as valid
for keep-alive. for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP streams SHALL remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
11.3.1 Changing Transport Parameters 11.3.1 Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). Reasons MUST respond with error 455 (Method Not Valid In This State). Reasons
to support changing transport parameters, is to allow for application to support changing transport parameters, is to allow for application
layer mobility and flexibility to utilize the best available layer mobility and flexibility to utilize the best available
transport as it becomes available. If a client receives a 455 when transport as it becomes available. If a client receives a 455 when
trying to change transport parameters while the server is in play trying to change transport parameters while the server is in play
state, it MAY try to put the server in ready state using PAUSE. state, it MAY try to put the server in ready state using PAUSE,
Before trying issuing the SETUP request again. If also that fails the before issuing the SETUP request again. If also that fails the
changing of transport parameters will require that the client changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then setting it up performs a TEARDOWN of the affected media and then setting it up
again. In aggregated session avoiding tearing down all the media at again. In aggregated session avoiding tearing down all the media at
the same time will avoid the creation of a new session. the same time will avoid the creation of a new session.
All transport parameters MAY be changed. However the primary usage All transport parameters MAY be changed. However the primary usage
expected is to either change transport protocol completely, like expected is to either change transport protocol completely, like
switching from Interleaved TCP mode to RTP or vise versa or change switching from Interleaved TCP mode to UDP or vise versa or change
delivery address. delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server SHOULD include the Range to indicate while in Play state, the server SHALL include the Range to indicate
from what point the new transport parameters are used. Further, if from what point the new transport parameters are used. Further, if
RTP is used for delivery, the server SHOULD also include the RTP-Info RTP is used for delivery, the server SHALL also include the RTP-Info
header to indicate from what timestamp and RTP sequence number the header to indicate from what timestamp and RTP sequence number the
change has taken place. If both RTP-Info and Range is included in the change has taken place. If both RTP-Info and Range is included in the
response the "rtp_time" parameter and range MUST be for the response the "rtp_time" parameter and range MUST be for the
corresponding time, i.e. be used in the same way as for PLAY to corresponding time, i.e. be used in the same way as for PLAY to
ensure the correct synchronization information is available. ensure the correct synchronization information is available.
If the transport parameters change while in PLAY state results in a If the transport parameters change while in PLAY state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However the server is RECOMMENDED to synchronization information. However the server is RECOMMENDED to
skipping to change at page 3, line 1971 skipping to change at page 51, line 36
contained. If no Range header was in the request, the NPT time format contained. If no Range header was in the request, the NPT time format
SHOULD be used unless the client showed support for an other format SHOULD be used unless the client showed support for an other format
more appropriate. Also for a session with live media streams the more appropriate. Also for a session with live media streams the
Range header MUST indicate a valid time. It is RECOMMENDED that Range header MUST indicate a valid time. It is RECOMMENDED that
normal play time is used, either the "now" indicator, for example normal play time is used, either the "now" indicator, for example
"npt=now-", or the time since session start as an open interval, e.g. "npt=now-", or the time since session start as an open interval, e.g.
"npt=96.23-". An absolute time value (clock) for the corresponding "npt=96.23-". An absolute time value (clock) for the corresponding
time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock
format SHOULD only be used if client has shown support for it. format SHOULD only be used if client has shown support for it.
A media server only supporting playback MUST support the npt format
and MAY support the clock and smpte formats.
For an on-demand stream, the server MUST reply with the actual range For an on-demand stream, the server MUST reply with the actual range
that will be played back, i.e. for which duration any media (having that will be played back, i.e. for which duration any media (having
content at this time) is delivered. This may differ from the content at this time) is delivered. This may differ from the
requested range if alignment of the requested range to valid frame requested range if alignment of the requested range to valid frame
boundaries is required for the media source. Note that some media boundaries is required for the media source. Note that some media
streams in an aggregate may need to be delivered from even earlier streams in an aggregate may need to be delivered from even earlier
points. Also, some media format have a very long duration per points. Also, some media format have a very long duration per
individual data unit, therefore it might be necessary for the client individual data unit, therefore it might be necessary for the client
to parse the data unit, and select where to start. to parse the data unit, and select where to start.
skipping to change at page 3, line 2035 skipping to change at page 53, line 5
After playing the desired range, the presentation does NOT transition After playing the desired range, the presentation does NOT transition
to the READY state, media delivery simply stops. A PAUSE request MUST to the READY state, media delivery simply stops. A PAUSE request MUST
be issued before the stream enters the READY state. A PLAY request be issued before the stream enters the READY state. A PLAY request
while the stream is still in the PLAYING state is legal, and can be while the stream is still in the PLAYING state is legal, and can be
issued without an intervening PAUSE request. Such a request SHALL issued without an intervening PAUSE request. Such a request SHALL
replace the current PLAY action with the new one requested, i.e. replace the current PLAY action with the new one requested, i.e.
being handle the same as the request was received in ready state. In being handle the same as the request was received in ready state. In
the case the first time range in Range header has a open start time the case the first time range in Range header has a open start time
(-endtime), the server SHALL continue to play from where it currently (-endtime), the server SHALL continue to play from where it currently
was. was until the specified end point. This is useful to change ongoing
playback to play another sequence, or end at another point than in
the previous request.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header when npt=0-. If a PLAY request is received without a Range header when
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response the current a 457 "Invalid Range" error response. In that response the current
pause point in a Range header SHALL be included. pause point in a Range header SHALL be included.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
skipping to change at page 3, line 2086 skipping to change at page 54, line 14
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the from the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given. value, a 457 (Invalid Range) response SHALL be given.
The possibility to replace a current PLAY request with a new one The possibility to replace a current PLAY request with a new one
replaces two RTSP 1.0 functions: replaces two RTSP 1.0 functions:
o The queued play functionality described in RFC 2326 [24] is o The queued play functionality described in RFC 2326 [27] is
removed and multiple ranges can be used to achieve a similar removed and multiple ranges can be used to achieve a similar
functionality. functionality.
o The use of PLAY for keep-alive signaling, i.e. PLAY request o The use of PLAY for keep-alive signaling, i.e. PLAY request
without a range header in PLAY state, has also been without a range header in PLAY state, has also been
deprecated. Instead a client can use, SET_PARAMETER deprecated. Instead a client can use, SET_PARAMETER
(recommended) or OPTIONS (allowed) for keep alive. (recommended) or OPTIONS (allowed) for keep alive.
11.5 PAUSE An example of using PLAY request to change the behavior, if a server
has received requests to play ranges 10 to 15 and then 13 to 20 (that
The PAUSE request causes the stream delivery to be interrupted is, overlapping ranges), a PLAY request 4 seconds after the first
(halted) temporarily. A PAUSE request MUST be done with the would take effect while the server plays the first range. Thus
aggregated control URI for aggregated sessions, resulting in all changing the behavior to continue to play to 25 seconds, i.e. the
media being halted, or the media URI for non-aggregated sessions. played range equal play with range: npt=10-25. If the second PLAY
Any attempt to do muting of a single media with an PAUSE request in request would arrive after the second range in the first range was
an aggregated session SHALL be responded with error 460 (Only playing, then the equivalent request would be play with
Aggregate Operation Allowed). After resuming playback, range:npt=10-15,npt=13-25.
synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message.
Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: 12345678
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-
The PAUSE request MAY contain a Range header specifying when the
stream or presentation is to be halted. This point is referred to as
the "pause point". The time parameter in the Range MUST NOT be used.
The Range header MUST contain a single value, expressed as the
beginning value an open range. For example, the following clip will
be played from 10 seconds through 21 seconds of the clip's normal
play time, under the assumption that the PAUSE request reaches the
server within 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/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-15, npt=13-20
S->C: RTSP/2.0 200 OK S->C: RTSP/2.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
Range: npt=10-30 Range: npt=10-15, npt=13-20
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=21- Range: npt=-25
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=21- Range: npt=14-15, npt=13-25
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
Session: 12345678 Session: 12345678
The pause request becomes effective the first time the server is 11.5 PAUSE
encountering the time point specified in any of the multiple ranges.
If the Range header specifies a time outside any range from the PLAY
request, the error 457 (Invalid Range) SHALL be returned. If a media
unit (such as an audio or video frame) starts presentation at exactly
the pause point, it is not played. If the Range header is missing,
stream delivery is interrupted immediately on receipt of the message
and the pause point is set to the current normal play time. However,
the pause point in the media stream MUST be maintained. A subsequent
PLAY request without Range header SHALL resume from the pause point
and play until media end.
If the server has already sent data beyond the time specified in the The PAUSE request causes the stream delivery to immediately be
PAUSE request's Range header, a PLAY without range SHALL resume at interrupted (halted). A PAUSE request MUST be done with the
the point in time specified by the PAUSE request's Range header, as aggregated control URI for aggregated sessions, resulting in all
it is assumed that the client has discarded data after that point. media being halted, or the media URI for non-aggregated sessions.
This ensures continuous pause/play cycling without gaps. Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message.
Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: 12345678
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-
The PAUSE request causes stream delivery to be interrupted
immediately on receipt of the message and the pause point is set to
the current point in the presentation. That pause point in the media
stream needs to be maintained. A subsequent PLAY request without
Range header SHALL resume from the pause point and play until media
end.
The pause point after any PAUSE request SHALL be returned to the The pause point after any PAUSE request SHALL be returned to the
client by adding a Range header with what remains unplayed of the client by adding a Range header with what remains unplayed of the
PLAY request's ranges, i.e. including all the remaining ranges part PLAY request's ranges, i.e. including all the remaining ranges part
of multiple range specification. If one desires to resume playing a of multiple range specification. If one desires to resume playing a
ranged request, one simply includes the Range header from the PAUSE ranged request, one simply includes the Range header from the PAUSE
response. response.
For example, if the server have a play request for ranges 10 to 15
and 20 to 29 pending and then receives a pause request for NPT 21, it
would start playing the second range and stop at NPT 21. If the pause
request is for NPT 12 and the server is playing at NPT 13 serving the
first play request, the server stops immediately. If the pause
request is for NPT 16, the server returns a 457 error message. To
prevent that the second range is played and the server stops after
completing the first range, a PAUSE request for NPT 20 needs to be
issued.
As another example, if a server has received requests to play ranges
10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
request for NPT=14 would take effect while the server plays the first
range, with the second range effectively being ignored, assuming the
PAUSE request arrives before the server has started playing the
second, overlapping range. Regardless of when the PAUSE request
arrives, it sets the pause point to 14. The below example messages is
for the above case when the PAUSE request arrives before the first
occurrence of NPT=14.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=13-20 Range: npt=10-30
S->C: RTSP/2.0 200 OK S->C: RTSP/2.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
Range: npt=10-15, npt=13-20 Range: npt=10-30
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
after 11 seconds, i.e. at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=14-
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=14-15, npt=13-20 Range: npt=21-30
Session: 12345678 Session: 12345678
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the READY state, the proper server response, if the player enters the READY state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point, even if the include the Range header with the current pause point. See examples
PAUSE request is asking for some other pause point. See examples
below: below:
Examples: Examples:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: 86-
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
11.6 TEARDOWN 11.6 TEARDOWN
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control request MAY be performed on either an aggregated or a media control
URI. However some restrictions apply depending on the current state. URI. However some restrictions apply depending on the current state.
The TEARDOWN request SHALL contain a Session header indicating what The TEARDOWN request SHALL contain a Session header indicating what
session the request applies to. session the request applies to.
A TEARDOWN using the aggregated control URI or the media URI in a A TEARDOWN using the aggregated control URI or the media URI in a
session under non-aggregated control MAY be done in any state (Ready, session under non-aggregated control (single media session) MAY be
and Play). A successful request SHALL result in that media delivery done in any state (Ready, and Play). A successful request SHALL
is immediately halted and the session state is destroyed. This SHALL result in that media delivery is immediately halted and the session
be indicated through the lack of a Session header in the response. state is destroyed. This SHALL be indicated through the lack of a
Session header in the response.
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only that a session returns to non-aggregated control, due to that it only
contains a single media after the requests completion. A session that contains a single media after the requests completion. A session
will exist after the processing of the TEARDOWN request SHALL in the that will exist after the processing of the TEARDOWN request SHALL in
response to that TEARDOWN request contain a Session header. Thus the the response to that TEARDOWN request contain a Session header. Thus
presence of the Session indicates to the receiver of the response if the presence of the Session header indicates to the receiver of the
the session is still existing or has been removed. response if the session is still existing or has been removed.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
skipping to change at page 3, line 2387 skipping to change at page 60, line 14
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam barparam: barstuff
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameters. This method is intentionally loosely defined parameters. This method is intentionally loosely defined
with the intention that the reply content and response with the intention that the reply content and response
content will be defined by the one desiring to use this content will be defined by the one desiring to use this
mechanism. mechanism.
11.9 REDIRECT 11.9 REDIRECT
The REDIRECT method is issued by a server to inform a client that it The REDIRECT method is issued by a server to inform a client that it
skipping to change at page 3, line 2409 skipping to change at page 60, line 36
indicated by the Request-URI. The presence of the Session header in a indicated by the Request-URI. The presence of the Session header in a
REDIRECT request indicates the scope of the request, and determines REDIRECT request indicates the scope of the request, and determines
the specific semantics of the request. the specific semantics of the request.
A REDIRECT request with a Session header has end-to-end (i.e. server A REDIRECT request with a Session header has end-to-end (i.e. server
to client) scope and applies only to the given session. Any to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while intervening proxies SHOULD NOT disconnect the control channel while
there are other remaining end-to-end sessions. The OPTIONAL Location there are other remaining end-to-end sessions. The OPTIONAL Location
header, if included in such a request, SHALL contain a complete header, if included in such a request, SHALL contain a complete
absolute URI pointing to the resource to which the client SHOULD absolute URI pointing to the resource to which the client SHOULD
reconnect. Specifically, the Location SHALL NOT contain just the reconnect. Specifically, the Location SHALL NOT contain just the host
host and port. A client may receive a REDIRECT request with a Session and port. A client may receive a REDIRECT request with a Session
header, if and only if, an end-to-end session has been established. header, if and only if, an end-to-end session has been established.
A client may receive a REDIRECT request without a Session header at A client may receive a REDIRECT request without a Session header at
any time when it has communication or a connection established with a any time when it has communication or a connection established with a
server. The scope of such a request is limited to the next-hop (i.e. server. The scope of such a request is limited to the next-hop (i.e.
the RTSP agent in direct communication with the server) and applies, the RTSP agent in direct communication with the server) and applies,
as well, to the control connection between the next-hop RTSP agent as well, to the control connection between the next-hop RTSP agent
and the server. A REDIRECT request without a Session header and the server. A REDIRECT request without a Session header
indicates that all sessions and pending requests being managed via indicates that all sessions and pending requests being managed via
the control connection MUST be redirected. The OPTIONAL Location the control connection MUST be redirected. The OPTIONAL Location
skipping to change at page 3, line 2467 skipping to change at page 61, line 49
responded to REDIRECT requests for all the sessions managed by the responded to REDIRECT requests for all the sessions managed by the
signalling connection. signalling connection.
If the OPTIONAL Range header is included in a REDIRECT request, it If the OPTIONAL Range header is included in a REDIRECT request, it
indicates when the redirection takes effect. The range value MUST be indicates when the redirection takes effect. The range value MUST be
an open ended single value, e.g. npt=59-, indicating the play out an open ended single value, e.g. npt=59-, indicating the play out
time when redirection SHALL occur. Alternatively, a range with a time when redirection SHALL occur. Alternatively, a range with a
time= parameter indicates the wall clock time by when the redirection time= parameter indicates the wall clock time by when the redirection
MUST take place. When the time= parameter is present in the range, MUST take place. When the time= parameter is present in the range,
any range value MUST be ignored even though it MUST be syntactically any range value MUST be ignored even though it MUST be syntactically
correct. When the indicated redirect point is reached, a client MUST correct. To allow a client to determine that redirect time without
issue a TEARDOWN request and SHOULD close the signalling connection being time synchronized with the server, the server SHALL include a
after receiving a 2xx response. The normal connection considerations Date header in the request. When the indicated redirect point is
apply for the server. reached, a client MUST issue a TEARDOWN request and SHOULD close the
signalling connection after receiving a 2xx response. The normal
connection considerations apply for the server.
The differentiation of REDIRECT requests with and without The differentiation of REDIRECT requests with and without
range headers is to allow for clear and explicit state range headers is to allow for clear and explicit state
handling. As the state in the server needs to be kept until handling. As the state in the server needs to be kept until
the point of redirection, the handling becomes more clear the point of redirection, the handling becomes more clear
if the client is required to TEARDOWN the session at the if the client is required to TEARDOWN the session at the
redirect point. redirect point.
If the REDIRECT request times out following the rules in Section 9.4
the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against
misbehaving clients that refuses to respond to a REDIRECT request.
That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header Note: The media resource indicated by the Location header
can be identical, slightly different or totally different. can be identical, slightly different or totally different.
This is the reason why a new DESCRIBE request SHOULD be This is the reason why a new DESCRIBE request SHOULD be
issued. issued.
If the Location header contains only a host address, the client MAY If the Location header contains only a host address, the client MAY
assume that the media on the new server is identical to the media on assume that the media on the new server is identical to the media on
the old server, i.e. all media configuration information from the old the old server, i.e. all media configuration information from the old
session is still valid except for the host address. session is still valid except for the host address. However the usage
of conditional SETUP using ETag identifiers are RECOMMENDED to verify
the assumption.
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/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Range: npt=0- ;time=19960213T143205Z Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK
CSeq: 732
12 Embedded (Interleaved) Binary Data 12 Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. In order to fulfill certain requirements on the network side, e.g.
in conjunction with network address translators that block RTP in conjunction with network address translators that block RTP
traffic over UDP, it may be necessary to interleave RTSP messages and traffic over UDP, it may be necessary to interleave RTSP messages and
media stream data. This interleaving should generally be avoided media stream data. This interleaving should generally be avoided
unless necessary since it complicates client and server operation and unless necessary since it complicates client and server operation and
imposes additional overhead. Also head of line blocking may cause imposes additional overhead. Also head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP. carried over TCP.
skipping to change at page 3, line 2543 skipping to change at page 64, line 6
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including a range containing a second channel in the indicated by including a range containing a second channel in the
interleaved parameter of the Transport header, see section 14.45. If interleaved parameter of the Transport header, see section 14.45. If
RTCP is used, packets SHALL be sent on the first available channel RTCP is used, packets SHALL be sent on the first available channel
higher than the RTP channel. The channels are bi-directional and higher than the RTP channel. The channels are bi-directional and
therefore RTCP traffic are sent on the second channel in both therefore RTCP traffic are sent on the second channel in both
directions. directions.
RTCP is needed for synchronization when two or more streams RTCP is sometime needed for synchronization when two or
are interleaved in such a fashion. Also, this provides a more streams are interleaved in such a fashion. Also, this
convenient way to tunnel RTP/RTCP packets through the TCP provides a convenient way to tunnel RTP/RTCP packets
control connection when required by the network through the TCP control connection when required by the
configuration and transfer them onto UDP when possible. network configuration and transfer them onto UDP when
possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
skipping to change at page 3, line 2621 skipping to change at page 65, line 42
session, the client SHOULD send a TEARDOWN request for the session, session, the client SHOULD send a TEARDOWN request for the session,
and MAY reestablish the session using the resource indicated by the and MAY reestablish the session using the resource indicated by the
Location. Location.
If the the Location header is used in a response it SHALL contain an If the the Location header is used in a response it SHALL contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI SHALL NOT only contain the host name. to, the URI SHALL NOT only contain the host name.
13.3.1 300 Multiple Choices 13.3.1 300 Multiple Choices
See [H10.3.1] [TBW] See [H10.3.1].
13.3.2 301 Moved Permanently 13.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 given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
13.3.3 302 Found 13.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 in the Location header. The Location header MUST be included in the
response. Is intended to be used for many types of temporary response. Is intended to be used for many types of temporary
redirects, e.g. load balancing. It is RECOMMENDED that one set the redirects, e.g. load balancing. It is RECOMMENDED that one set the
reason phrase to something more meaningful than "Found" in these reason phrase to something more meaningful than "Found" in these
cases. The user client SHOULD redirect automatically to the given cases. The user client SHOULD redirect automatically to the given
URI. This response MUST NOT contain a message-body. URI. This response MUST NOT contain a message-body.
13.3.4 303 See Other 13.3.4 303 See Other
skipping to change at page 3, line 2648 skipping to change at page 66, line 20
URI. This response MUST NOT contain a message-body. URI. This response MUST NOT contain a message-body.
13.3.4 303 See Other 13.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 RTSP 1.0 (RFC 2326). to use in RTSP 1.0 (RFC 2326).
13.3.5 304 Not Modified 13.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
14.26) and the requested resource has not been modified, the server 14.25) and the requested resource has not been modified, the server
SHOULD send a 304 response. This response MUST NOT contain a SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
o Date o Date
o ETag and/or Content-Location, if the header would have been o ETag and/or Content-Location, if the header(s) would have been
sent in a 200 response to the same request. sent in a 200 response to the same request.
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant. variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is response to SETUP does NOT imply that the resource description is
skipping to change at page 3, line 2702 skipping to change at page 67, line 26
13.4.3 451 Parameter Not Understood 13.4.3 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a entity body containing the offending sender SHOULD return a entity body containing the offending
parameter(s). parameter(s).
13.4.4 452 reserved 13.4.4 452 reserved
This error code was removed from RFC 2326 [24] and is obsolete. This error code was removed from RFC 2326 [27] and is obsolete.
13.4.5 453 Not Enough Bandwidth 13.4.5 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
13.4.6 454 Session Not Found 13.4.6 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
invalid, or has timed out. invalid, or has timed out.
13.4.7 455 Method Not Valid in This State 13.4.7 455 Method Not Valid in This State
The client or server cannot process this request in its current The client or server cannot process this request in its current
state. The response SHOULD contain an Allow header to make error state. The response SHALL contain an Allow header to make error
recovery easier. recovery possible.
13.4.8 456 Header Field Not Valid for Resource 13.4.8 456 Header Field Not Valid for Resource
The server could not act on a required request header. For example, The server could not act on a required request header. For example,
if PLAY contains the Range header field but the stream does not allow if PLAY contains the Range header field but the stream does not allow
seeking. This error message may also be used for specifying when the seeking. This error message may also be used for specifying when the
time format in Range is impossible for the resource. In that case the time format in Range is impossible for the resource. In that case the
Accept-Ranges header SHOULD be returned to inform the client of which Accept-Ranges header SHALL be returned to inform the client of which
format(s) that are allowed. format(s) that are allowed.
13.4.9 457 Invalid Range 13.4.9 457 Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the The Range value given is out of bounds, e.g., beyond the end of the
presentation. presentation.
13.4.10 458 Parameter Is Read-Only 13.4.10 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not The parameter to be set by SET_PARAMETER can be read but not
skipping to change at page 3, line 2789 skipping to change at page 69, line 17
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
13.5 Server Error 5xx 13.5 Server Error 5xx
13.5.1 551 Option not supported 13.5.1 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A 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 SHALL be returned stating the
feature for which there is no support. feature for which there is no support.
14 Header Field Definitions 14 Header Field Definitions
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
skipping to change at page 3, line 2836 skipping to change at page 70, line 18
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 2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used; codes 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
may be present in all requests and responses. may be present in both requests and responses.
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field. An empty proxy column indicates that the proxy SHALL header field. An empty proxy column indicates that the proxy SHALL
NOT do any changes to that header, all allowed operations are NOT do any changes to that header, all allowed operations are
explicitly stated: explicitly stated:
a: A proxy can add or concatenate the header field if not a: A proxy can add or concatenate the header field if not
present. present.
m: A proxy can modify an existing header field value. m: A proxy can modify an existing header field value.
skipping to change at page 3, line 2889 skipping to change at page 71, line 23
request. A mandatory response header field MUST be present in the request. A mandatory response header field MUST be present in the
response, and the header field MUST be understood by the response, and the header field MUST be understood by the
Client/Server processing the response. "Not applicable" means that Client/Server processing the response. "Not applicable" means that
the header field MUST NOT be present in a request. If one is placed the header field MUST NOT be present in a request. If one is placed
in a request by mistake, it MUST be ignored by the Client/Server in a request by mistake, it MUST be ignored by the Client/Server
receiving the request. Similarly, a header field labeled "not receiving the request. Similarly, a header field labeled "not
applicable" for a response means that the Client/Server MUST NOT applicable" for a response means that the Client/Server MUST NOT
place the header field in the response, and the Client/Server MUST place the header field in the response, and the Client/Server MUST
ignore the header field in the response. ignore the header field in the response.
A Client/Server SHOULD ignore extension header parameters that are An RTSP agent SHALL ignore extension headers that are not understood.
not understood.
The From and Location header fields contain an URI. If the URI The From and Location header fields contain an URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double contains a comma, or semicolon, the URI MUST be enclosed in double
quotas ("). Any URI parameters are contained within these quotas. If quotas ("). Any URI parameters are contained within these quotas. If
the URI is not enclosed in double quotas, any semicolon- delimited 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.
14.1 Accept 14.1 Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
The "level" parameter for presentation descriptions is
properly defined as part of the MIME type registration, not
here.
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: Example of use:
Accept: application/rtsl q=1.0, application/sdp Accept: application/rtsl q=1.0, application/sdp
14.2 Accept-Credentials 14.2 Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to
proxies or servers. See section 18 for the usage of this header. It
SHALL only be included in client to server requests.
In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy. If the method is "User" the header
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-Credentials R r o o o o o o Accept-Credentials R r o o o o o 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 - - m - - -
Accept-Ranges r r - - o - - - Accept-Ranges r r - - o - - -
Accept-Ranges 456 r - - - o o - Accept-Ranges 456 r - - - o - -
Allow r am c c c - - - Allow r am c c c - - -
Allow 405 am m m m m m m Allow 405 am m m m m m m
Authorization R o o o o o o Authorization R o o o o o o
Bandwidth R o o o o - - Bandwidth R o o o o - -
Blocksize R o - o o - - Blocksize R o - o o - -
Cache-Control r - - o - - - Cache-Control r o - o - - -
Connection o o o o o o Connection o o o o o o
Connection-Credentials 470,407 ar o o o o o o Connection-Credentials 470,407 ar o o o o o o
Content-Base r o - - - - - Content-Base r o - - - - -
Content-Base 4xx o o o o o o Content-Base 4xx,5xx o o o o o o
Content-Encoding R r - - - - - - Content-Encoding R r - - - - - -
Content-Encoding r r o - - - - - Content-Encoding r r o - - - - -
Content-Encoding 4xx r o o o o o o Content-Encoding 4xx,5xx r o o o o o o
Content-Language R r - - - - - - Content-Language R r - - - - - -
Content-Language r r o - - - - - Content-Language r r o - - - - -
Content-Language 4xx r o o o o o o Content-Language 4xx,5xx r o o o o o o
Content-Length r r * - - - - - Content-Length r r * - - - - -
Content-Length 4xx r * * * * * * Content-Length 4xx,5xx r * * * * * *
Content-Location r o - - - - - Content-Location r o - - - - -
Content-Location 4xx o o o o o o Content-Location 4xx,5xx o o o o o o
Content-Type r * - - - - - Content-Type r * - - - - -
Content-Type 4xx * * * * * * Content-Type 4xx,5xx * * * * * *
CSeq Rc rm m m m m m m CSeq Rc rm m m m m m m
Date am o o o o o o Date am o o o o o o
ETag r r o - o - - - ETag r r o - o - - -
Expires r r o - - - - - Expires r r o - - - - -
From R r o o o o o o From R r o o o o o o
Host - - - - - -
If-Match R r - - o - - - If-Match R r - - o - - -
If-Modified-Since R r o - o - - - If-Modified-Since R r o - o - - -
If-None-Match R r o - - - - - If-None-Match R r 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
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
_____________________________________________________________ ______________________________________________________________
Proxy-Authenticate 407 amr m m m m m m Proxy-Authenticate 407 amr m m m m m m
Proxy-Authorization R rd o o o o o o
Proxy-Require R ar o o o o o o Proxy-Require R ar o o o o o o
Proxy-Require r r c c c c c c Proxy-Require r r c c c c c c
Proxy-Supported R amr oc oc oc oc oc oc Proxy-Supported R amr c c c c c c
Proxy-Supported r c c c c c c Proxy-Supported r c c c c c c
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 - -
Range r - - c m* 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 c - - RTP-Info r - - o c - -
Scale - - - o - - Scale - - - o - -
Session R r - o o m m m Session R r - o o m m m
Session r r - c m m m o Session r r - c m m m o
Server R r - o - - - - Server R r - o - - - -
Server r r o o o o o o Server r r o o o o o o
Speed - - - o - - Speed - - - o - -
skipping to change at page 3, line 3002 skipping to change at page 73, line 39
Timestamp R admr o o o o o o Timestamp R admr o o o o o o
Timestamp c admr m m m m m m Timestamp c admr m m m m m m
Transport amr - - m - - - Transport amr - - 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 10: Overview of RTSP header fields (P-W) related to methods Table 10: Overview of RTSP header fields (P-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
contains zero or more of credentials that the client accept. Each any trusted intermediary how to handle further secured connections to
credential SHALL consist of one URI identifying the proxy or server, proxies or servers. See Section 18 for the usage of this header. It
and the SHA-1 [14] hash computed over that entity's DER encoded SHALL NOT be included in server to client requests.
certificate [15] in Base64 [35].
In a request the header SHALL contain the method (User, Proxy, or
Header Where Proxy GPR SPR RDR Header Where Proxy GPR SPR RDR
__________________________________________________ __________________________________________________
Accept-Credentials R r o o o Accept-Credentials R r o o o
Allow 405 amr m m m Allow 405 amr m m m
Authorization R o o o Authorization R o o o
Bandwidth R - o - Bandwidth R - o -
Blocksize R - o - Blocksize R - o -
Connection o o o Connection o o o
Connection-Credentials 470,407 ar o o o Connection-Credentials 470,407 ar 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,5xx o o o
Content-Encoding R r o o - Content-Encoding R r o o -
Content-Encoding r r o o - Content-Encoding r r o o -
Content-Encoding 4xx r o o o Content-Encoding 4xx,5xx r o o o
Content-Language R r o o - Content-Language R r o o -
Content-Language r r o o - Content-Language r r o o -
Content-Language 4xx r o o o Content-Language 4xx,5xx r o o o
Content-Length R r * * - Content-Length R r * * -
Content-Length r r * * - Content-Length r r * * -
Content-Length 4xx r * * * Content-Length 4xx,5xx r * * *
Content-Location R o o - Content-Location R o o -
Content-Location r o o - Content-Location r o o -
Content-Location 4xx o o o Content-Location 4xx,5xx o o o
Content-Type R * * - Content-Type R * * -
Content-Type r * * - Content-Type r * * -
Content-Type 4xx * * * Content-Type 4xx * * *
CSeq Rc mr m m m CSeq R,c mr m m m
Date am o o o Date R a o o m
Date r am o o o
From R r o o o From R r o o o
Host - - -
Last-Modified R r - - - Last-Modified R r - - -
Last-Modified r r o - - Last-Modified r r o - -
Location 3rr o o o Location 3rr o o o
Location R - - m Location R - - m
Proxy-Authenticate 407 amr m m m Proxy-Authenticate 407 amr m m m
Proxy-Authorization R rd o o o
Proxy-Require R ar o o o Proxy-Require R ar o o o
Proxy-Require r r c c c Proxy-Require r r c c c
Proxy-Supported R amr oc oc oc Proxy-Supported R amr c c c
Proxy-Supported r c c c Proxy-Supported r c c c
Public 501 admr m* m* m* Public 501 admr m m m
__________________________________________________ __________________________________________________
Header Where Proxy GPR SPR RDR Header Where Proxy GPR SPR RDR
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, and REDIRECT. GET_PARAMETER, SET_PARAMETER, and REDIRECT.
Header Where Proxy GPR SPR RDR Header Where Proxy GPR SPR RDR
____________________________________________ ____________________________________________
Range R - - o Range R - - o
skipping to change at page 3, line 3090 skipping to change at page 75, line 34
Via R amr o o o Via R amr o o o
Via c dr m m m Via c dr m m m
WWW-Authenticate 401 m m m WWW-Authenticate 401 m m m
____________________________________________ ____________________________________________
Header Where Proxy GPR SPR RDR Header Where Proxy GPR SPR RDR
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, and REDIRECT. GET_PARAMETER, SET_PARAMETER, and REDIRECT.
"rtsps://proxy2.example.com/";exaIl9VMbQMOFGClx5rXnPJKVNI=, Any) for approving credentials selected by the requestor. The method
"rtsps://server.example.com/";lurbjj5khhB0NhIuOXtt4bBRH1M= SHALL NOT be changed by any proxy. If the method is "User" the header
contains zero or more of credentials that the client accept. Each
credential SHALL consist of one URI identifying the proxy or server,
the hash algorithm identifier, and the hash over that entity's DER
encoded certificate [16] in Base64. All RTSP clients and proxies
SHALL implement the SHA-1 [17] algorithm for computation of the hash
of the DER encoded certificate. The SHA-1 algorithm is identified by
the token "sha-1".
The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited.
Example:
Accept-Credentials:User,
"rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M=
14.3 Accept-Encoding 14.3 Accept-Encoding
See [H14.3] See [H14.3]
14.4 Accept-Language 14.4 Accept-Language
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
14.5 Accept-Ranges 14.5 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate The Accept-Ranges request and response-header field allows indication
its acceptance of range requests and possible formats for a resource: of the format supported in the Range header. The client SHALL include
the header in SETUP requests to indicate which formats it support to
receive in PLAY and PAUSE responses, and REDIRECT requests. The
server SHALL include the header in SETUP and 456 error responses to
indicate the formats supported for the resource indicated by the
request URI.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined This header has the same syntax as [H14.5] and the syntax is defined
in 19.2.3. However, new range-units are defined. Inclusion of any of in 19.2.3. However, new range-units are defined.
the time formats indicates acceptance by the server for PLAY and
PAUSE requests with this format. The headers value is valid for the
resource specified by the URI in the request, this response
corresponds to. A server SHOULD use this header in SETUP responses to
indicate to the client which range time formats the media supports.
The header SHOULD also be included in "456" responses which is a
result of use of unsupported range formats.
14.6 Allow 14.6 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
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. The Allow Allowed) response. See [H14.7] for syntax definition. The Allow
header MUST also be present in all OPTIONS responses where the header MUST also be present in all OPTIONS responses where the
content of the header will not include exactly the same methods as content of the header will not include exactly the same methods as
listed in the Public header. listed in the Public header.
The Allow SHALL also be included in SETUP and DESCRIBE responses, if The Allow SHALL also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the minimal the methods allowed for the resource is different than the minimal
implementation set. implementation set.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
14.7 Authorization 14.7 Authorization
See [H14.8] See [H14.8]
14.8 Bandwidth 14.8 Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to mobility. during an RTSP session, e.g., due to mobility, congestion, etc.
Example: Example:
Bandwidth: 4000 Bandwidth: 62360
14.9 Blocksize 14.9 Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block size override it with the media-specific size if necessary. The block size
skipping to change at page 3, line 3181 skipping to change at page 78, line 6
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of response. Note: Cache-Control does not govern the caching of
responses as for HTTP, instead it applies to the media stream responses as for HTTP, instead it applies to the media stream
identified by the SETUP request. The caching of RTSP requests are identified by the SETUP request. The RTSP requests are generally not
generally not cacheable, for further information see section 16. cacheable, for further information see section 16. Below is the
Below is the description of the cache directives that can be included description of the cache directives that can be included in the
in the Cache-Control header. Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching anywhere. This allows an origin server to prevent caching
even by caches that have been configured to return stale even by caches that have been configured to return stale
responses to client requests. responses to client requests.
public: Indicates that the media stream is cacheable by any public: Indicates that the media stream is cacheable by any
cache. cache.
private: Indicates that the media stream is intended for a private: Indicates that the media stream is intended for a
skipping to change at page 3, line 3304 skipping to change at page 80, line 32
14.12 Connection-Credentials 14.12 Connection-Credentials
The Connection-Credentials response header is used to carry the The Connection-Credentials response header is used to carry the
credentials of any next hop that need to be approved by the credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses. requestor. It SHALL only be used in server to client responses.
The Connection-Credentials header in an RTSP response SHALL, if The Connection-Credentials header in an RTSP response SHALL, if
included, contain the credentials information of the next hop that an included, contain the credentials information of the next hop that an
intermediary needs to securely connect to. The credential MUST intermediary needs to securely connect to. The credential MUST
include the URI of the next proxy or server and the DER encoded include the URI of the next proxy or server and the DER encoded
X.509v3 [15] certificate in base64 [35]. X.509v3 [16] certificate in base64 [37].
Example: Example:
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
14.13 Content-Base 14.13 Content-Base
The Content-Base entity-header field may be used to specify the base The Content-Base entity-header field may be used to specify the base
URI for resolving relative URIs within the entity. URI for resolving relative URIs within the entity.
skipping to change at page 3, line 3366 skipping to change at page 81, line 50
number. Any retransmitted request MUST contain the same sequence number. Any retransmitted request MUST contain the same sequence
number as the original (i.e. the sequence number is not incremented number as the original (i.e. the sequence number is not incremented
for retransmissions of the same request). For each new RTSP request for retransmissions of the same request). For each new RTSP request
the CSeq value SHALL be incremented by one. The initial sequence the CSeq value SHALL be incremented by one. The initial sequence
number MAY be any number, however it is RECOMMENDED to start at 0. number MAY be any number, however it is RECOMMENDED to start at 0.
Each sequence number series is unique between each requester and Each sequence number series is unique between each requester and
responder, i.e. the client has one series for its request to a responder, i.e. the client has one series for its request to a
server and the server has another when sending request to the client. server and the server has another when sending request to the client.
Each requester and responder is identified with its network address. Each requester and responder is identified with its network address.
Proxies that aggregate several sessions on the same transport will
regularly need to renumber the CSeq header field in requests and
responses to fulfill the rules for the header.
Example: Example:
CSeq: 239 CSeq: 239
14.20 Date 14.20 Date
See [H14.18]. An RTSP message containing a body MUST include a Date See [H14.18]. An RTSP message containing a body MUST include a Date
header if the sending host has a clock. Servers SHOULD include a Date header if the sending host has a clock. Servers SHOULD include a Date
header in all other RTSP messages. header in all other RTSP messages.
14.21 ETag 14.21 ETag
The ETag response header MAY be included in DESCRIBE or SETUP The ETag response header MAY be included in DESCRIBE or SETUP
responses. The entity tag returned in a DESCRIBE response is for the responses. The entity tags (Section 3.8) returned in a DESCRIBE
included entity, while for SETUP it refers to the media resource just response, and the one in SETUP refers to the presentation, i.e. both
set up. This differentiation allows for cache validation of both the returned session description and the media stream. This allows
session description and the media resource associated with the for verification that one has the right session description to a
description. If the ETag is provided both inside the entity, e.g. media resource at the time of the SETUP request. However it has the
within the "a=etag" attribute in SDP, and in the response message, disadvantage that a change in any of the parts results in
then both tags SHALL be identical. It is RECOMMENDED that the ETag is invalidation of all the parts.
primarily given in the RTSP response message, to ensure that caches
can use the ETag without requiring content inspection. If the ETag is provided both inside the entity, e.g. within the
"a=etag" attribute in SDP, and in the response message, then both
tags SHALL be identical. It is RECOMMENDED that the ETag is primarily
given in the RTSP response message, to ensure that caches can use the
ETag without requiring content inspection. However for session
descriptions that are distributed outside of RTSP, for example using
HTTP, etc. it will be necessary to include the entity tag in the
session description as specified in Section C.1.8.
SETUP and DESCRIBE requests can be made conditional upon the ETag SETUP and DESCRIBE requests can be made conditional upon the ETag
using the headers If-Match (Section 14.25) and If-None-Match (Section using the headers If-Match (Section 14.24) and If-None-Match (Section
14.27). 14.26).
14.22 Expires 14.22 Expires
The Expires entity-header field gives a date and time after which the The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the presentation description (body) SHOULD be after which the presentation description (body) SHOULD be
considered stale. considered stale.
skipping to change at page 3, line 3443 skipping to change at page 83, line 45
The presence of an Expires header field with a date value of some The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (Section 14.10). indicated otherwise by a Cache-Control header field (Section 14.10).
14.23 From 14.23 From
See [H14.22]. See [H14.22].
14.24 Host 14.24 If-Match
The Host HTTP request header field [H14.23] is not needed for RTSP,
and SHALL NOT be sent. It SHALL be silently ignored if received.
14.25 If-Match
See [H14.24]. See [H14.24].
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, in both the case where the integrity of the presentation description, in both the case where
it is fetched via means external to RTSP (such as HTTP), or in the it is fetched via means external to RTSP (such as HTTP), or in the
case where the server implementation is guaranteeing the integrity of case where the server implementation is guaranteeing the integrity of
the description between the time of the DESCRIBE message and the the description between the time of the DESCRIBE message and the
SETUP message. By including the ETag given in or with the session SETUP message. By including the ETag given in or with the session
description in a SETUP request, the client ensures that resources set description in a SETUP request, the client ensures that resources set
up are matching the description. A SETUP request for which the ETag up are matching the description. A SETUP request for which the ETag
validation check fails, SHALL responde using 412 (Precondition validation check fails, SHALL responde using 412 (Precondition
Failed). Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
14.26 If-Modified-Since 14.25 If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response SHALL be returned without any message-body. response SHALL be returned without any message-body.
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
14.27 If-None-Match 14.26 If-None-Match
See [H14.26]. See [H14.26].
This request header can be used with entity tags to make DESCRIBE This request header can be used with one or several entity tags to
requests conditional. A new session description is retrieved only if make DESCRIBE requests conditional. A new session description is
another entity than the already available would be included. If the retrieved only if another entity than the ones already available
entity available for delivery is matching the one the client already would be included. If the entity available for delivery is matching
has, then a 304 (Not Modified) response is given. the one the client already has, then a 304 (Not Modified) response is
given.
14.28 Last-Modified 14.27 Last-Modified
The Last-Modified entity-header field indicates the date and time at The Last-Modified entity-header field indicates the date and time at
which the origin server believes the presentation description or which the origin server believes the presentation description or
media stream was last modified. See [H14.29]. For the methods media stream was last modified. See [H14.29]. For the methods
DESCRIBE, the header field indicates the last modification date and DESCRIBE, the header field indicates the last modification date and
time of the description, for SETUP that of the media stream. time of the description, for SETUP that of the media stream.
14.29 Location 14.28 Location
See [H14.30]. See [H14.30].
14.30 Proxy-Authenticate 14.29 Proxy-Authenticate
See [H14.33]. See [H14.33].
14.30 Proxy-Authorization
See [H14.34].
14.31 Proxy-Require 14.31 Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy SHALL use the 551 (Option Not Unsupported header. The proxy SHALL use the 551 (Option Not
Supported) status code in the response. Any feature tag included in Supported) status code in the response. Any feature tag included in
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
skipping to change at page 3, line 3655 skipping to change at page 88, line 29
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-10 Range: npt=15-10
Decreasing ranges are still half open intervals as described above. 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, 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 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 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 both ends, as otherwise there would be no way to reach 0 on a reverse
playback. playback for formats that have such a notion, like NPT and SMPTE.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-0 Range: npt=15-0
In this range both 15 and 0 are closed. In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale A decreasing range interval without a corresponding negative Scale
header is not valid. header is not valid.
skipping to change at page 3, line 3874 skipping to change at page 93, line 24
Speed: 2.5 Speed: 2.5
Use of this field changes the bandwidth used for data delivery. It is Use of this field changes the bandwidth used for data delivery. It is
meant for use in specific circumstances where preview of the meant for use in specific circumstances where preview of the
presentation at a higher or lower rate is necessary. Implementors presentation at a higher or lower rate is necessary. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. When data is delivered over UDP, it is highly may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over public best-effort rates. If the data transport is performed over non-dedicated best-
networks the sender MUST perform congestion control of the stream(s). effort networks the sender is required to perform congestion control
This can result in that the communicated speed is impossible to of the stream(s). This can result in that the communicated speed is
maintain. impossible to maintain.
14.41 Server 14.41 Server
See [H14.38], however the header syntax is corrected in section See [H14.38], however the header syntax is corrected in section
19.2.3. 19.2.3.
14.42 Session 14.42 Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result of RTSP session. An RTSP session is created by the server as a result of
skipping to change at page 3, line 3947 skipping to change at page 94, line 50
of 2.4*E-16. In sessions with shorter timeout times, or of 2.4*E-16. In sessions with shorter timeout times, or
much higher packet loss, or small RTCP bandwidths SHOULD much higher packet loss, or small RTCP bandwidths SHOULD
also use any of the mechanisms below. also use any of the mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
SHOULD be included. This method is the RECOMMENDED RTSP SHOULD be included. This method is the RECOMMENDED RTSP
method to use in request only intended to perform keep- method to use in request only intended to perform keep-
alive. alive.
OPTIONS: This method does also work. However it causes the OPTIONS: This method does also work. However it causes the
server to perform unnecessary processing and result in server to perform more unnecessary processing and result in
bigger responses than necessary for the task. The reason bigger responses than necessary for the task. The reason
for this is that the server needs to determine what for this is that the server needs to determine what
capabilities that are associated with the media resource to capabilities that are associated with the media resource to
correctly populate the Public and Allow headers. correctly populate the Public and Allow headers.
Note that a session identifier identifies an RTSP session across Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session transport sessions or connections. RTSP requests for a given session
can use different URIs (Presentation and media URIs). Note, that can use different URIs (Presentation and media URIs). Note, that
there are restrictions depending on the session which URIs that are there are restrictions depending on the session which URIs that are
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
skipping to change at page 3, line 4083 skipping to change at page 97, line 46
unicast / multicast: This parameter is a mutually exclusive unicast / multicast: This parameter is a mutually exclusive
indication of whether unicast or multicast delivery will be indication of whether unicast or multicast delivery will be
attempted. One of the two values MUST be specified. Clients attempted. One of the two values MUST be specified. Clients
that are capable of handling both unicast and multicast that are capable of handling both unicast and multicast
transmission needs to indicate such capability by including transmission needs to indicate such capability by including
two full transport-specs with separate parameters for each. two full transport-specs with separate parameters for each.
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 stream. The layers are sent to consecutive addresses
starting at the dest_addr address. starting at the dest_addr address. If the parameter is not
included, it defaults to a single layer.
dest_addr: A general destination address parameter that can dest_addr: A general destination address parameter that can
contain one or more address specifications. Each contain one or more address specifications. Each
combination of Protocol/Profile/Lower Transport needs to combination of Protocol/Profile/Lower Transport needs to
have the format and interpretation of its address have the format and interpretation of its address
specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, specification defined. For RTP/AVP/UDP and RTP/AVP/TCP,
the address specification is a tuple containing a host the address specification is a tuple containing a host
address and port. address and port.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
skipping to change at page 3, line 4143 skipping to change at page 99, line 12
binding in the NAT that the sender to receiver packet flow binding in the NAT that the sender to receiver packet flow
can use. can use.
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport However, since this is more a feature of transport
than media initialization, the authoritative source than media initialization, the authoritative source
for this information should be in the SETUP response. for this information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported mode: The mode parameter indicates the methods to be supported
for this session. Valid values are PLAY and RECORD. If not for this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY. The RECORD value was provided, the default is PLAY. The RECORD value was defined
defined in RFC 2326 and is deprecated in this in RFC 2326 and is in this specification unspecified but
specification. reserved.
append: The append parameter was used together with RECORD and
is now deprecated.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is stream with the control stream in whatever protocol is
being used by the control stream, using the mechanism being used by the control stream, using the mechanism
defined in Section 12. The argument provides the channel defined in Section 12. The argument provides the channel
number to be used in the $ statement and MUST be present. number to be used in the $ statement and MUST be present.
This parameter MAY be specified as a range, e.g., This parameter MAY be specified as a range, e.g.,
interleaved=4-5 in cases where the transport choice for the interleaved=4-5 in cases where the transport choice for the
media stream requires it, e.g. for RTP with RTCP. The media stream requires it, e.g. for RTP with RTCP. The
channel number given in the request are only a guidance channel number given in the request are only a guidance
skipping to change at page 3, line 4173 skipping to change at page 99, line 39
example of such usage is the second channel used for RTCP, example of such usage is the second channel used for RTCP,
where both server and client sends RTCP packets on the same where both server and client sends RTCP packets on the same
channel. channel.
This allows RTP/RTCP to be handled similarly to the This allows RTP/RTCP to be handled similarly to the
way that it is done with UDP, i.e., one channel for way that it is done with UDP, i.e., one channel for
RTP and the other for RTCP. RTP and the other for RTCP.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live. ttl: multicast time-to-live. When included in requests the value
indicate the TTL value that the client desires to use. In
response the value actually being used is returned. A
server will need to consider what values that are
reasonable and also the authority of the user to set this
value.
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.
ssrc: The ssrc parameter, if included in a SETUP response, ssrc: The ssrc parameter, if included in a SETUP response,
indicates the RTP SSRC [16] value(s) that will be used by indicates the RTP SSRC [18] value(s) that will be used by
the media server for RTP packets within the stream. It is the media server for RTP packets within the stream. It is
expressed as an eight digit hexadecimal value. expressed as an eight digit hexadecimal value.
The ssrc parameter SHALL NOT be specified in requests. The The ssrc parameter SHALL NOT be specified in requests. The
functionality of specifying the ssrc parameter in a SETUP functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550 [16]. If the parameter is specification of RTP in RFC 3550 [18]. If the parameter is
included in the Transport header of a SETUP request, the included in the Transport header of a SETUP request, the
server MAY ignore it, and choose an appropriate SSRC for server MAY ignore it, and choose appropriate SSRCs for the
the stream. The server MAY set the ssrc parameter in the stream. The server MAY set the ssrc parameter in the
Transport header of the response. Transport header of the response.
The combination of transport protocol, profile and lower transport The combination of transport protocol, profile and lower transport
needs to be defined. A number of combinations are defined in the needs to be defined. A number of combinations are defined in the
appendix B. appendix B.
Below is a usage example, showing a client advertising the capability Below is a usage example, showing a client advertising the capability
to handle multicast or unicast, preferring multicast. Since this is to handle multicast or unicast, preferring multicast. Since this is
a unicast-only stream, the server responds with the proper transport a unicast-only stream, the server responds with the proper transport
parameters for unicast. parameters for unicast.
skipping to change at page 3, line 4258 skipping to change at page 101, line 37
RTSP Proxies are RTSP agents that sit in between a client and a RTSP Proxies are RTSP agents that sit in between a client and a
server. A proxy can take on both the role as a client and as server server. A proxy can take on both the role as a client and as server
depending on what it tries to accomplish. Proxies are also introduced depending on what it tries to accomplish. Proxies are also introduced
for several different reasons. for several different reasons.
Caching Proxy: This type of proxy is used to reduce the workload Caching Proxy: This type of proxy is used to reduce the workload
on servers and connections. By caching a presentation, both on servers and connections. By caching a presentation, both
description and media streams the proxy can serve a client description and media streams the proxy can serve a client
content without requesting it from the server once it has content without requesting it from the server once it has
been cached and hasn't become stale. See the caching been cached and hasn't become stale. See the caching
section 16. Section 16.
Access Proxy: This type of proxy is used to ensure that a RTSP Access Proxy: This type of proxy is used to ensure that a RTSP
client get access to servers on an external network. Thus client get access to servers on an external network. Thus
this proxy is placed on the border between two domains, this proxy is placed on the border between two domains,
e.g. a private address space and the public internet. The e.g. a private address space and the public internet. The
proxy performs the necessary translation, usually proxy performs the necessary translation, usually
addresses, and often also media stream translation or addresses, and often also media stream translation or
redirection. redirection.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
skipping to change at page 3, line 4280 skipping to change at page 102, line 10
firewalled network, the security proxy request that the firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client necessary pinholes in the firewall is opened when a client
in the protected network want to access media streams on in the protected network want to access media streams on
the external side. It can also provide network owners with the external side. It can also provide network owners with
a logging and audit point for RTSP sessions, e.g. for a logging and audit point for RTSP sessions, e.g. for
corporations that tracks or limits their employees access corporations that tracks or limits their employees access
to certain type of content. to certain type of content.
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificates for with TLS as RTSP 2.0 allows the client to approve certificates for
connection establishment from a proxy, see section 18.3.2. connection establishment from a proxy, see Section 18.3.2. However
that trust model may not be suitable for all type of deployment, and
instead secured sessions do by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the NAT or small office equipment. In these cases it is better to use the NAT
traversal procedures defined for RTSP 2.0 [25]. The reason for these traversal procedures defined for RTSP 2.0 [38]. The reason for these
recommendations is that any extensions of RTSP resulting in new media recommendations is that any extensions of RTSP resulting in new media
transport protocols or profiles, new parameters etc may fail in a transport protocols or profiles, new parameters etc may fail in a
proxy that isn't maintained. Thus resulting in blocking further proxy that isn't maintained. Thus resulting in blocking further
development of RTSP and its usage. development of RTSP and its usage.
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. There must be definition of how proxies may new RTSP extensions. There must be definition of how proxies may
handle the extension, if it is required to understand it, thus handle the extension, if it is required to understand it, thus
requiring a feature tag to be used in the Proxy-Require header. requiring a feature tag to be used in the Proxy-Require header.
skipping to change at page 3, line 4334 skipping to change at page 103, line 18
through" variety. Rather than retrieving the whole resource from the through" variety. Rather than retrieving the whole resource from the
origin server, the cache simply copies the streaming data as it origin server, the cache simply copies the streaming data as it
passes by on its way to the client. Thus, it does not introduce passes by on its way to the client. Thus, it does not introduce
additional latency. additional latency.
To the client, an RTSP proxy cache appears like a regular media To the client, an RTSP proxy cache appears like a regular media
server, to the media origin server like a client. Just as an HTTP server, to the media origin server like a client. Just as an HTTP
cache has to store the content type, content language, and so on for cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, multicast information) from the presentation description, (that is, e.g. multicast information) from the presentation
since these are independent of the data delivery from the cache to description, since these are independent of the data delivery from
the client. Information on the encodings remains the same. If the the cache to the client. Information on the encodings remains the
cache is able to translate the cached media data, it would create a same. If the cache is able to translate the cached media data, it
new presentation description with all the encoding possibilities it would create a new presentation description with all the encoding
can offer. possibilities it can offer.
17 Examples 17 Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that understanding of how functions of RTSP work. However remember that
this is examples and the normative and syntax description in the this is examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the other sections takes precedence. Please also note that many of the
example MAY contain syntax illegal line breaks to accommodate the example contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose. formatting restriction that the RFC series impose.
17.1 Media on Demand (Unicast) 17.1 Media on Demand (Unicast)
Client C requests a movie distributed from two different media The is an example of media on demand streaming of a media stored in a
servers A (audio.example.com ) and V (video.example.com ). The media container file. For purposes of this example, a container file is a
description is stored on a web server W. The media description storage entity in which multiple continuous media types pertaining to
contains descriptions of the presentation and all its streams, the same end-user presentation are present. In effect, the container
including the codecs that are available, dynamic RTP payload types, file represents an RTSP presentation, with each of its components
the protocol stack, and content information such as language or being RTSP controlled media streams. Container files are a widely
copyright restrictions. It may also give an indication about the used means to store such presentations. While the components are
timeline of the movie. transported as independent streams, it is desirable to maintain a
common context for those streams at the server end.
In this example, the client is only interested in the last part of
the movie.
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
e=adm@example.com
a=range:npt=0-1:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public
Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 12345678
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 23456789
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT
Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to
each other, the client can synchronize the two using standard RTP
methods, in particular the time scale contained in the RTCP sender
reports. Initial synchronization is achieved through the RTP-Info and
Range headers information in the PLAY response.
17.2 Streaming of a Container file
For purposes of this example, a container file is a storage entity in
which multiple continuous media types pertaining to the same end-user
presentation are present. In effect, the container file represents an
RTSP presentation, with each of its components being RTSP streams.
Container files are a widely used means to store such presentations.
While the components are transported as independent streams, it is
desirable to maintain a common context for those streams at the
server end.
This enables the server to keep a single storage handle This enables the server to keep a single storage handle
open easily. It also allows treating all the streams open easily. It also allows treating all the streams
equally in case of any prioritization of streams by the equally in case of any prioritization of streams by the
server. server.
It is also possible that the presentation author may wish to prevent It is also possible that the presentation author may wish to prevent
selective retrieval of the streams by the client in order to preserve selective retrieval of the streams by the client in order to preserve
the artistic effect of the combined media presentation. Similarly, in the artistic effect of the combined media presentation. Similarly,
such a tightly bound presentation, it is desirable to be able to in such a tightly bound presentation, it is desirable to be able to
control all the streams via a single control message using an control all the streams via a single control message using an
aggregate URI. aggregate URI.
The following is an example of using a single RTSP session to control The following is an example of using a single RTSP session to control
multiple streams. It also illustrates the use of aggregate URIs. In a multiple streams. It also illustrates the use of aggregate URIs. In a
container file it is also desirable to not write any URI parts which container file it is also desirable to not write any URI parts which
is not kept, when the container is distributed, like the host and is not kept, when the container is distributed, like the host and
most of the path element. Therefore this example also uses the "*" most of the path element. Therefore this example also uses the "*"
and relative URI in the delivered SDP. and relative URI in the delivered SDP.
skipping to change at page 3, line 4615 skipping to change at page 106, line 33
CSeq: 6 CSeq: 6
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678 Session: 12345678
Range: npt=34.57-623.10 Range: npt=34.57-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012, ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889 ssrc=4F312DD8:seq=55021;rtptime=3132889
17.2 Media on Demand (Unicast)
An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two
different media servers A (audio.example.com ) and V
(video.example.com ). The media description is stored on a web server
W. The media description contains descriptions of the presentation
and all its streams, including the codecs that are available, dynamic
RTP payload types, the protocol stack, and content information such
as language or copyright restrictions. It may also give an indication
about the timeline of the movie.
In this example, the client is only interested in the last part of
the movie.
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
e=adm@example.com
a=range:npt=0-1:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public
Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 12345678
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 23456789
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT
Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to
each other, the client can perform initial synchronize of the two
media using RTP-Info and Range received in the PLAY responses. If the
two servers are time synchronized the RTCP packets can also be used
to maintain synchronization.
17.3 Single Stream Container Files 17.3 Single Stream Container Files
Some RTSP servers may treat all files as though they are "container Some RTSP servers may treat all files as though they are "container
files", yet other servers may not support such a concept. Because of files", yet other servers may not support such a concept. Because of
this, clients SHOULD use the rules set forth in the session this, clients needs to use the rules set forth in the session
description for Request-URIs, rather than assuming that a consistent description for Request-URIs, rather than assuming that a consistent
URI may always be used throughout. Below are an example of how a URI may always be used throughout. Below are an example of how a
multi-stream server might expect a single-stream file to be served: multi-stream server might expect a single-stream file to be served:
C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp Accept: application/x-rtsp-mh, application/sdp
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
skipping to change at page 3, line 4761 skipping to change at page 112, line 33
Session: 0456804596 Session: 0456804596
Range:npt=1256- Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio" RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000 ssrc=0D12F123:seq=1473; rtptime=80000
17.5 Capability Negotiation 17.5 Capability Negotiation
This examples illustrate how the client and server determines their This examples illustrate how the client and server determines their
capability to support a special feature, in this case "play.scale". capability to support a special feature, in this case "play.scale".
The server, through the clients request and the included Supported The server, through the clients request and the included Supported
header, learns that the client is supporting this updated header, learns the client supports RTSP 2.0, and also supports the
specification, and also supports the playback time scaling feature of playback time scaling feature of RTSP. The server's response contains
RTSP. The server's response contains the following feature related the following feature related information to the client; it supports
information to the client; it supports the updated specification the basic playback (play.basic), the extended functionality of time
(play.basic), the extended functionality of time scaling of content scaling of content (play.scale), and one "example.com" proprietary
(play.scale), and one "example.com" proprietary feature feature (com.example.flight). The client also learns the methods
(example.com.flight). The client also learns the methods supported supported (Public header) by the server for the indicated resource.
(Public header) by the server for the indicated resource.
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Supported: play.basic, play.scale, example.com.flight Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request it tells the server that it When the client sends its SETUP request it tells the server that it
is requires support of the play.scale feature for this session by is requires support of the play.scale feature for this session by
including the Require header. including the Require header.
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
skipping to change at page 3, line 4811 skipping to change at page 113, line 37
The RTSP security framework consists of two high level components: The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the transport protection based on TLS, which is independent of RTSP. the transport protection based on TLS, which is independent of RTSP.
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security for HTTP is re-used to a large extent. and HTTP servers, the security for HTTP is re-used to a large extent.
18.1 RTSP and HTTP Authentication 18.1 RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in [8] and also in [H15]. the same usage guidelines as specified in [12] and also in [H15].
Servers SHOULD implement both basic and digest [8] authentication. Servers SHOULD implement both basic and digest [12] authentication.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in environments not provide full control message security. Therefore, in environments
requiring tighter security for the control messages, TLS SHOULD be requiring tighter security for the control messages, TLS SHOULD be
used, see Section 18.2. used, see Section 18.2.
18.2 RTSP over TLS 18.2 RTSP over TLS
RTSP SHALL follow the same guidelines with regards to TLS [11] usage
RTSP SHALL follow the same guidelines with regards to TLS [7] usage as specified for HTTP, see [19]. RTSP over TLS is separated from
as specified for HTTP, see [17]. RTSP over TLS is separated from
unsecured RTSP both on URI level and port level. Instead of using the unsecured RTSP both on URI level and port level. Instead of using the
"rtsp" scheme identifier in the URI, the "rtsps" scheme identifier "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier
MUST be used to signal RTSP over TLS. If no port is given in a URI MUST be used to signal RTSP over TLS. If no port is given in a URI
with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP. with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP.
When a client tries to setup an insecure channel to the server (using When a client tries to setup an insecure channel to the server (using
the "rtsp" URI), and the policy for the resource requires a secure the "rtsp" URI), and the policy for the resource requires a secure
channel, the server SHALL redirect the client to the secure service channel, the server SHALL redirect the client to the secure service
by sending a 301 redirect response code together with the correct by sending a 301 redirect response code together with the correct
Location URI (using the "rtsps" scheme). Location URI (using the "rtsps" scheme). A user or client MAY upgrade
a non secured URI to a secured by changing the scheme from "rtsp" to
"rtsps". A server implementing support for "rtsps" SHALL allow this.
It should be noted that TLS allows for mutual authentication (when It should be noted that TLS allows for mutual authentication (when
using both server and client certificates). Still, one of the more using both server and client certificates). Still, one of the more
common way TLS is used is to only provide server side authentication common way TLS is used is to only provide server side authentication
(often to avoid client certificates). TLS is then used in addition to (often to avoid client certificates). TLS is then used in addition to
HTTP authentication, providing transport security and server HTTP authentication, providing transport security and server
authentication, while HTTP Authentication is used to authenticate the authentication, while HTTP Authentication is used to authenticate the
client. client.
RTSP includes the possibility to keep a TCP session up between the RTSP includes the possibility to keep a TCP session up between the
skipping to change at page 3, line 4933 skipping to change at page 116, line 23
User, which means that the proxy (or proxies) MUST send User, which means that the proxy (or proxies) MUST send
credential information about the next hop to the client for credential information about the next hop to the client for
authorization. The client can then decide whether the proxy authorization. The client can then decide whether the proxy
should accept the certificate or not. See section 18.3.2 should accept the certificate or not. See section 18.3.2
for further details. for further details.
If the Accept-Credentials header is not included in the RTSP request If the Accept-Credentials header is not included in the RTSP request
from the client, the default method used SHALL be "Proxy". If from the client, the default method used SHALL be "Proxy". If
something else than the "Proxy" method is used, the Accept- something else than the "Proxy" method is used, the Accept-
Credentials header SHALL always be included in the RTSP request from Credentials header SHALL be included in all of the RTSP request from
the client. This is because it cannot be assumed that the proxy the client. This is because it cannot be assumed that the proxy
always keeps the TLS state or the users previously preference between always keeps the TLS state or the users previously preference between
different RTSP messages (in particular if the time interval between different RTSP messages (in particular if the time interval between
the messages is long). the messages is long).
The "Any" and "Proxy" methods does not require the proxy to provide The "Any" and "Proxy" methods does not require the proxy to provide
any specific response, but only apply the policy as defined for any specific response, but only apply the policy as defined for
respectively method. If the policy do not accept the credentials of respectively method. If the policy do not accept the credentials of
the next hop, the entity SHALL respond with a message using status the next hop, the entity SHALL respond with a message using status
code 471 (Connection Credentials not accepted). code 471 (Connection Credentials not accepted).
skipping to change at page 3, line 5007 skipping to change at page 117, line 49
Connection-Credentials: "rtsps://test.example.org"; Connection-Credentials: "rtsps://test.example.org";
MIIDNTCCAp... MIIDNTCCAp...
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589" "192.0.2.5:4589"
Accept-Credentials: User "rtsps://test.example.org" ; Accept-Credentials: User "rtsps://test.example.org" ;
dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ... dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ...
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org" ;
dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ...
One implication of this process is that the connection for secured One implication of this process is that the connection for secured
RTSP messages may take significantly more round-trip times for the RTSP messages may take significantly more round-trip times for the
first message. An complete extra message exchange between the proxy first message. An complete extra message exchange between the proxy
connecting to the next hop and the client results because of the connecting to the next hop and the client results because of the
process for approval for each hop. However after the first message process for approval for each hop. However after the first message
exchange the remaining message should not be delayed, if each message exchange the remaining message should not be delayed, if each message
contains the chain of proxies that the requestor accepts. The contains the chain of proxies that the requestor accepts. The
procedure of including the credentials in each request rather than procedure of including the credentials in each request rather than
building state in each proxy, avoids the need for revocation building state in each proxy, avoids the need for revocation
procedures. procedures.
skipping to change at page 3, line 5061 skipping to change at page 119, line 18
CR = %x0D ; US-ASCII CR, carriage return (13 CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10) LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32) SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9) HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQUOTE = %x22 ; US-ASCII double-quote mark (34) DQUOTE = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92) BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace SWS = [LWS] ; sep whitespace
HCOLON = *( SP / HTAB ) ":" SWS HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE / "," / ";" / ":" / BACKSLASH / DQUOTE
/ "/" / "[" / "]" / "?" / "=" / "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT / "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E) / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials> ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE ) quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <">
skipping to change at page 3, line 5115 skipping to change at page 120, line 27
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
19.2 RTSP Protocol Definition 19.2 RTSP Protocol Definition
19.2.1 Generic Protocol elements 19.2.1 Generic Protocol elements
URI-reference = RTSP-URI / relative-ref RTSP-IRI = schemes ":" IRI-rest
relative-ref = < As defined in RFC 3986 [6]> IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
RTSP-URI = rtsp-uri-def / rtsps-uri-def / rtspu-uri-def ihier-part = "//" iauthority ipath-abempty
rtsp-uri-def = "rtsp:" rtsp-uri-rest RTSP-IRI-ref = RTSP-IRI / irelative-ref
rtsps-uri-def = "rtsps:" rtsp-uri-rest irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
rtspu-uri-def = "rtspu:" rtsp-uri-rest irelative-part = "//" iauthority ipath-abempty
rtsp-uri-rest = "//" host [":" port] [abs-path-def] [frag-def] / ipath-absolute
abs-path-def = abs-path ["?" query] / ipath-noscheme
frag-def = "#" fragment / ipath-empty
host = <As defined by RFC 3986 [6]> iauthority = < As defined in RFC 3987 [9]>
abs-path = <As defined by RFC 3986 [6]> ipath = ipath-abempty ; begins with "/" or is empty
port = *DIGIT ; Is expected to be 1*5DIGIT / ipath-absolute ; begins with "/" but not "//"
query = <As defined by RFC 3986 [6]> / ipath-noscheme ; begins with a non-colon segment
fragment = <As defined by RFC 3986 [6]> / ipath-rootless ; begins with a segment
absolute-URI = <As defined by RFC 3986 [6]> / ipath-empty ; zero characters
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT ipath-abempty = *( "/" isegment )
IPv6address = hexpart [ ":" IPv4address ] ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] ipath-noscheme = isegment-nz-nc *( "/" isegment )
hexseq = hex4 *( ":" hex4) ipath-rootless = isegment-nz *( "/" isegment )
hex4 = 1*4HEXDIG ipath-empty = 0<ipchar>
isegment = *ipchar [";" *ipchar]
isegment-nz = 1*ipchar [";" *ipchar]
/ ";" *ipchar
isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc])
/ ";" *ipchar-nc
; non-zero-length segment without any colon ":"
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
iquery = < As defined in RFC 3987 [9]>
ifragment = < As defined in RFC 3987 [9]>
iunreserved = < As defined in RFC 3987 [9]>
pct-encoded = < As defined in RFC 3987 [9]>
RTSP-URI = schemes ":" URI-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative
schemes = "rtsp" / "rtsps" / scheme
scheme = < As defined in RFC 3986 [10]>
URI-rest = hier-part [ "?" query ]
hier-part = "//" authority path-abempty
RTSP-Relative = relative-part [ "?" query ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
authority = < As defined in RFC 3986 [10]>
query = < As defined in RFC 3986 [10]>
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar [";" *pchar]
segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar)
segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc)
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / "="
smpte-range = smpte-type "=" smpte-range-spec smpte-range = smpte-type "=" smpte-range-spec
;Section 3.4 ;Section 3.4
smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) smpte-range-spec = ( smpte-time "-" [ smpte-time ] )
/ ( "-" smpte-time ) / ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop" smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension / "smpte-25" / smpte-type-extension
; other timecodes may be added ; other timecodes may be added
smpte-type-extension = token smpte-type-extension = token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
skipping to change at page 3, line 5170 skipping to change at page 122, line 36
utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction >
fraction = 1*DIGIT fraction = 1*DIGIT
feature-tag = token feature-tag = token
session-id = 8*( ALPHA / DIGIT / safe ) session-id = 8*( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value extension-header = header-name HCOLON header-value
header-name = token header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
19.2.2 Message Syntax 19.2.2 Message Syntax
RTSP-message = Request / Response ; RTSP/2.0 messages RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line ; Section 6.1 Request = Request-Line ; Section 6.1
*( general-header ; Section 5 *( general-header ; Section 5
/ request-header ; Section 6.2 / request-header ; Section 6.2
/ entity-header ) ; Section 8.1 / entity-header ) ; Section 8.1
CRLF CRLF
[ message-body ] ; Section 4.3 [ message-body ] ;
Response = Status-Line ; Section 7.1 Section 4.3 Response = Status-Line ; Section
*( general-header ; Section 5 7.1 *( general-header ; Section
/ response-header ; Section 7.1.2 5 / response-header ; Section
/ entity-header ) ; Section 8.1 7.2 / entity-header ) ; Section
CRLF 8.1
[ message-body ] ; Section 4.3 CRLF [
message-body ] ; Section 4.3
Request-Line = Method SP Request-URI SP RTSP-Version CRLF Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" ; Section 11.2 Method = "DESCRIBE" ; Section 11.2
/ "GET_PARAMETER" ; Section 11.7 / "GET_PARAMETER" ; Section 11.7
/ "OPTIONS" ; Section 11.1 / "OPTIONS" ; Section 11.1
/ "PAUSE" ; Section 11.5 / "PAUSE" ; Section 11.5
/ "PLAY" ; Section 11.4 / "PLAY" ; Section 11.4
/ "REDIRECT" ; Section 11.9 / "REDIRECT" ; Section 11.9
skipping to change at page 3, line 5272 skipping to change at page 125, line 15
/ extension-header / extension-header
request-header = Accept ; Section 14.1 and [H14.1] request-header = Accept ; Section 14.1 and [H14.1]
/ Accept-Credentials ; Section 14.2 / Accept-Credentials ; Section 14.2
/ Accept-Encoding ; Section 14.3 and [H14.3] / Accept-Encoding ; Section 14.3 and [H14.3]
/ Accept-Language ; Section 14.4 and [H14.4] / Accept-Language ; Section 14.4 and [H14.4]
/ Authorization ; Section 14.7 and [H14.8] / Authorization ; Section 14.7 and [H14.8]
/ Bandwidth ; Section 14.8 / Bandwidth ; Section 14.8
/ Blocksize ; Section 14.9 / Blocksize ; Section 14.9
/ From ; Section 14.23 / From ; Section 14.23
/ If-Match ; Section 14.25 / If-Match ; Section 14.24
/ If-Modified-Since ; Section 14.26 and [H14.25] / If-Modified-Since ; Section 14.25 and [H14.25]
/ If-None-Match ; Section 14.27 / If-None-Match ; Section 14.26
/ Proxy-Require ; Section 14.31 / Proxy-Require ; Section 14.31
/ Range ; Section 14.34 / Range ; Section 14.34
/ Referer ; Section 14.35 / Referer ; Section 14.35
/ Require ; Section 14.37 / Require ; Section 14.37
/ Scale ; Section 14.39 / Scale ; Section 14.39
/ Session ; Section 14.42 / Session ; Section 14.42
/ Speed ; Section 14.40 / Speed ; Section 14.40
/ Supported ; Section 14.43 / Supported ; Section 14.43
/ Transport ; Section 14.45 / Transport ; Section 14.45
/ User-Agent ; Section 14.47 / User-Agent ; Section 14.47
/ extension-header / extension-header
response-header = Accept-Credentials ; Section 14.2 response-header = Accept-Credentials ; Section 14.2
/ Accept-Ranges ; Section 14.5 / Accept-Ranges ; Section 14.5
/ Connection-Creds ; Section 14.12 / Connection-Creds ; Section 14.12
/ ETag ; Section 14.21 / ETag ; Section 14.21
/ Location ; Section 14.29 / Location ; Section 14.28
/ Proxy-Authenticate ; Section 14.30 / Proxy-Authenticate ; Section 14.29
/ Public ; Section 14.33 / Public ; Section 14.33
/ Range ; Section 14.34 / Range ; Section 14.34
/ Retry-After ; Section 14.36 / Retry-After ; Section 14.36
/ RTP-Info ; Section 14.38 / RTP-Info ; Section 14.38
/ Scale ; Section 14.39 / Scale ; Section 14.39
/ Session ; Section 14.42 / Session ; Section 14.42
/ Server ; Section 14.41 / Server ; Section 14.41
/ Speed ; Section 14.40 / Speed ; Section 14.40
/ Transport ; Section 14.45 / Transport ; Section 14.45
/ Unsupported ; Section 14.46 / Unsupported ; Section 14.46
skipping to change at page 3, line 5315 skipping to change at page 126, line 14
/ extension-header / extension-header
entity-header = Allow ; Section 14.6 entity-header = Allow ; Section 14.6
/ Content-Base ; Section 14.13 / Content-Base ; Section 14.13
/ Content-Encoding ; Section 14.14 / Content-Encoding ; Section 14.14
/ Content-Language ; Section 14.15 / Content-Language ; Section 14.15
/ Content-Length ; Section 14.16 / Content-Length ; Section 14.16
/ Content-Location ; Section 14.17 / Content-Location ; Section 14.17
/ Content-Type ; Section 14.18 / Content-Type ; Section 14.18
/ Expires ; Section 14.22 and [H14.21] / Expires ; Section 14.22 and [H14.21]
/ Last-Modified ; Section 14.28 / Last-Modified ; Section 14.27
/ extension-header / extension-header
19.2.3 Header Syntax 19.2.3 Header Syntax
All header syntaxes not defined in this section are defined in All header syntaxes not defined in this section are defined in
section 14 of the HTTP 1.1 specification [3]. section 14 of the HTTP 1.1 specification [3].
Accept = Accept-name HCOLON Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ] [ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param) accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*" media-range = ( "*/*"
/ ( m-type SLASH "*" ) / ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype ) / ( m-type SLASH m-subtype )
) *( SEMI m-parameter ) ) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." *3DIGIT ] ) qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] ) / ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF
cred-decision = ("User" COMMA [cred-info]) cred-decision = ("User" COMMA [cred-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ token ; For future extensions / token ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data) cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-URI DQUOTE SEMI base64 cred-info-data = DQUOTE RTSP-URI DQUOTE SEMI hash-alg SEMI base64
hash-alg = "sha-1" / extension-alg
extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ] [ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param) encoding = codings *(SEMI accept-param)
codings = content-coding / "*" codings = content-coding / "*"
content-coding = token content-coding = token
Accept-Language = "Accept-Language" HCOLON Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ] [ language *(COMMA language) ]
language = language-range *(SEMI accept-param) language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF
skipping to change at page 3, line 5408 skipping to change at page 128, line 19
/ "proxy-revalidate" / "proxy-revalidate"
/ "max-age" EQUAL delta-seconds / "max-age" EQUAL delta-seconds
/ cache-extension / cache-extension
cache-extension = token [EQUAL (token / quoted-string)] cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Connection-Creds = "Connection-Credentials" HCOLON cred-info CRLF Connection-Creds = "Connection-Credentials" HCOLON cred-info CRLF
Connection = "Connection" HCOLON (connection-token) Connection = "Connection" HCOLON (connection-token)
*(COMMA connection-token) CRLF *(COMMA connection-token) CRLF
connection-token = token connection-token = token
Content-Base = "Content-Base" HCOLON URI-reference CRLF Content-Base = "Content-Base" HCOLON RTSP-URI-Ref CRLF
Content-Encoding = "Content-Encoding" HCOLON Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding) content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag) language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag ) language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA primary-tag = 1*8ALPHA
subtag = 1*8ALPHA subtag = 1*8ALPHA
Content-Length = "Content-Length" HCOLON 1*DIGIT Content-Length = "Content-Length" HCOLON 1*DIGIT
Content-Location = "Content-Location" HCOLON URI-reference Content-Location = "Content-Location" HCOLON RTSP-URI-Ref
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter) media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video" discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token / "application" / extension-token
composite-type = "message" / "multipart" / extension-token composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token extension-token = ietf-token / x-token
ietf-token = token ietf-token = token
x-token = "x-" token x-token = "x-" token
m-subtype = extension-token / iana-token m-subtype = extension-token / iana-token
skipping to change at page 3, line 5451 skipping to change at page 129, line 16
/ "Thu" / "Fri" / "Sat" / "Sun" / "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr" month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug" / "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec" / "Sep" / "Oct" / "Nov" / "Dec"
ETag = "ETag" HCOLON entity-tag ETag = "ETag" HCOLON entity-tag
Expires = "Expires" HCOLON delta-seconds Expires = "Expires" HCOLON delta-seconds
From = "From" HCOLON from-spec From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-URI / absolute-URI addr-spec = RTSP-URI / absolute-URI
absolute-URI = < As defined in RFC 3986 [10]>
display-name = *(token LWS)/ quoted-string display-name = *(token LWS)/ quoted-string
from-param = tag-param / generic-param from-param = tag-param / generic-param
tag-param = "tag" EQUAL token tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) If-Match = "If-Match" HCOLON ( "*" / entity-tag-list)
entity-tag-list = entity-tag *(COMMA entity-tag) entity-tag-list = entity-tag *(COMMA entity-tag)
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = "W/" weak = "W/"
opaque-tag = quoted-string opaque-tag = quoted-string
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list)
skipping to change at page 3, line 5475 skipping to change at page 129, line 41
/ other-challenge / other-challenge
other-challenge = auth-scheme LWS auth-param other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param) *(COMMA auth-param)
digest-cln = realm / domain / nonce digest-cln = realm / domain / nonce
/ opaque / stale / algorithm / opaque / stale / algorithm
/ qop-options / auth-param / qop-options / auth-param
realm = "realm" EQUAL realm-value realm = "realm" EQUAL realm-value
realm-value = quoted-string realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI domain = "domain" EQUAL LDQUOT URI
*( 1*SP URI ) RDQUOT *( 1*SP URI ) RDQUOT
URI = RTSP-URI / abs-path URI = RTSP-URI / RTSP-URI-Ref
nonce = "nonce" EQUAL nonce-value nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" ) stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token)
qop-options = "qop" EQUAL LDQUOT qop-value qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT *("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token qop-value = "auth" / "auth-int" / token
Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF
*(COMMA feature-tag) *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON feature-tag Proxy-Supported = "Proxy-Supported" HCOLON feature-tag
*(COMMA feature-tag) CRLF *(COMMA feature-tag) CRLF
Public = "Public" HCOLON Method *(COMMA Method) CRLF Public = "Public" HCOLON Method *(COMMA Method) CRLF
Range = "Range" HCOLON ranges-list [exec-time] CRLF Range = "Range" HCOLON ranges-list [exec-time] CRLF
ranges-list = ranges-spec *(COMMA ranges-spec) ranges-list = ranges-spec *(COMMA ranges-spec)
exec-time = SEMI "time" EQUAL utc-time exec-time = SEMI "time" EQUAL utc-time
ranges-spec = npt-range / utc-range / smpte-range ranges-spec = npt-range / utc-range / smpte-range / range-ext
Referer = "Referer" HCOLON URI-reference range-ext = extension-format "=" range-value
range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referer = "Referer" HCOLON RTSP-URI-Ref
Require = "Require" HCOLON feature-tag-list CRLF Require = "Require" HCOLON feature-tag-list CRLF
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
RTP-Info = "RTP-Info" HCOLON rtsp-info-spec RTP-Info = "RTP-Info" HCOLON rtsp-info-spec
*(COMMA rtsp-info-spec) CRLF *(COMMA rtsp-info-spec) CRLF
rtsp-info-spec = stream-url 1*ssrc-parameter rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE URI-reference DQUOTE stream-url = "url" EQUAL DQUOTE RTSP-URI-Ref DQUOTE
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter) ri-parameter *(SEMI ri-parameter)
ri-parameter = "seq" EQUAL 1*DIGIT ri-parameter = "seq" EQUAL 1*DIGIT
/ "rtptime" EQUAL 1*DIGIT / "rtptime" EQUAL 1*DIGIT
Retry-After = "Retry-After" HCOLON delta-seconds Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param ) [ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds) retry-param = ("duration" EQUAL delta-seconds)
/ generic-param / generic-param
Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF
skipping to change at page 3, line 5558 skipping to change at page 131, line 36
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX ssrc = 8HEX
channel = 1*3DIGIT channel = 1*3DIGIT
mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / "RECORD" / token mode = "PLAY" / "RECORD" / token
addr-list = quoted-addr *(SLASH quoted-addr) addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE
host-port = host [":" port] host-port = host [":" port]
/ ":" port / ":" port
extension-addr = 1*qdtext extension-addr = 1*qdtext
host = < As defined in RFC 3986 [10]>
port = < As defined in RFC 3986 [10]>
Unsupported = "Unsupported" HCOLON feature-tag-list CRLF Unsupported = "Unsupported" HCOLON feature-tag-list CRLF
User-Agent = "User-Agent" HCOLON ( product / comment ) User-Agent = "User-Agent" HCOLON ( product / comment )
0*(LWS (product / comment)) CRLF 0*(LWS (product / comment)) CRLF
Vary = "Vary" HCOLON ( "*" / field-name-list) Vary = "Vary" HCOLON ( "*" / field-name-list)
field-name-list = field-name *(COMMA field-name) field-name-list = field-name *(COMMA field-name)
field-name = token field-name = token
Via = "Via" HCOLON via-parm *(COMMA via-parm) Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr via-params = via-ttl / via-maddr
/ via-received / via-branch / via-received / via-branch
/ via-extension / via-extension
via-ttl = "ttl" EQUAL ttl via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address) via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986 [10]>
IPv6address = < As defined in RFC 3986 [10]>
via-branch = "branch" EQUAL token via-branch = "branch" EQUAL token
via-extension = generic-param via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot SLASH transport-prot
protocol-name = "RTSP" / token protocol-name = "RTSP" / token
protocol-version = token protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token other-transport = token
sent-by = host [ COLON port ] sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
19.3 SDP extension Syntax 19.3 SDP extension Syntax
This section defines in ABNF the SDP extensions defined for RTSP. This section defines in ABNF the SDP extensions defined for RTSP.
See section C for the definition of the extensions in text. See section C for the definition of the extensions in text.
control-attribute = "a=control:" *SP RTSP-URI control-attribute = "a=control:" *SP RTSP-URI
a-range-def = "a=range:" ranges-spec CRLF a-range-def = "a=range:" ranges-spec CRLF
a-etag-def = "a=etag:" etag-string CRLF a-etag-def = "a=etag:" entity-tag CRLF
etag-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
20 Security Considerations 20 Security Considerations
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] and HTTP servers, the security considerations outlined in [H15]
apply. Specifically, please note the following: apply. Specifically, please note the following:
Abuse of Server Log Information: RTSP and HTTP servers will Abuse of Server Log Information: RTSP and HTTP servers will
presumably have similar logging mechanisms, and thus should presumably have similar logging mechanisms, and thus should
be equally guarded in protecting the contents of those be equally guarded in protecting the contents of those
skipping to change at page 3, line 5651 skipping to change at page 133, line 43
Location Headers and Spoofing: If a single server supports Location Headers and Spoofing: If a single server supports
multiple organizations that do not trust each another, then multiple organizations that do not trust each another, then
it needs to check the values of Location and Content- it needs to check the values of Location and Content-
Location header fields in responses that are generated Location header fields in responses that are generated
under control of said organizations to make sure that they under control of said organizations to make sure that they
do not attempt to invalidate resources over which they have do not attempt to invalidate resources over which they have
no authority. ([H15.4]) no authority. ([H15.4])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [3], as of this writing) and also of the previous RFC2068 (RFC 2616 [3], as of this writing) and also of the previous RFC2068
[18], future HTTP specifications may provide additional guidance on [39], future HTTP specifications may provide additional guidance on
security issues. security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service opportunity for a remote-controlled denial-of-service
attack. See Section . attack. See Section 20.1.
Session hijacking: Since there is no or little relation between Session hijacking: Since there is no or little relation between
a transport layer connection and an RTSP session, it is a transport layer connection and an RTSP session, it is
possible for a malicious client to issue requests with possible for a malicious client to issue requests with
random session identifiers which would affect unsuspecting random session identifiers which would affect unsuspecting
clients. The server SHOULD use a large, random and non- clients. The server SHOULD use a large, random and non-
sequential session identifier to minimize the possibility sequential session identifier to minimize the possibility
of this kind of attack. For real session security, client of this kind of attack. For real session security, client
authentication needs to be performed. authentication needs to be performed.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[8] authentication. In environments requiring tighter [12] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS (RFC 2246 [7]) SHOULD be used. mechanism TLS (RFC 2246 [11]) SHOULD be used.
Stream issues: RTSP only provides for stream control. Stream Stream issues: RTSP only provides for stream control. Stream
delivery issues are not covered in this section, nor in the delivery issues are not covered in this section, nor in the
rest of this draft. RTSP implementations will most likely rest of this draft. RTSP implementations will most likely
rely on other protocols such as RTP, IP multicast, RSVP and rely on other protocols such as RTP, IP multicast, RSVP and
IGMP, and should address security considerations brought up IGMP, and should address security considerations brought up
in those and other applicable specifications. in those and other applicable specifications.
Persistently suspicious behavior: RTSP servers SHOULD return Persistently suspicious behavior: RTSP servers SHOULD return
error code 403 (Forbidden) upon receiving a single instance error code 403 (Forbidden) upon receiving a single instance
of behavior which is deemed a security risk. RTSP servers of behavior which is deemed a security risk. RTSP servers
SHOULD also be aware of attempts to probe the server for SHOULD also be aware of attempts to probe the server for
weaknesses and entry points and MAY arbitrarily disconnect weaknesses and entry points and MAY arbitrarily disconnect
and ignore further requests clients which are deemed to be and ignore further requests clients which are deemed to be
in violation of local security policy. in violation of local security policy.
Scope of Multicast: If RTSP is used to control the transmission
of media onto a multicast network it is need to consider
the scope that delivery has. RTSP supports the TTL
Transport header parameter to indicate this scope. However
such scope control is risk as it may be set to large and
distribute media beyond the intended scope.
TLS through proxies: If one uses the possibility to connect TLS
in multiple legs (Section 18.3 one really needs to be aware
of the trust model. That procedure requires full faith and
trust in all proxies that one allows to connect through.
They are man in the middle and has access to all that goes
on over the TLS connection. Thus it is important to
consider if that trust model is acceptable in the actual
application.
20.1 Remote denial of Service Attack 20.1 Remote denial of Service Attack
The attacker may initiate traffic flows to one or more IP addresses The attacker may initiate traffic flows to one or more IP addresses
by specifying them as the destination in SETUP requests. While the by specifying them as the destination in SETUP requests. While the
attacker's IP address may be known in this case, this is not always attacker's IP address may be known in this case, this is not always
useful in prevention of more attacks or ascertaining the attackers useful in prevention of more attacks or ascertaining the attackers
identity. Thus, an RTSP server MUST only allow client-specified identity. Thus, an RTSP server MUST only allow client-specified
destinations for RTSP-initiated traffic flows if the server has destinations for RTSP-initiated traffic flows if the server has
ensured that the specified destination address accepts receiving ensured that the specified destination address accepts receiving
media through different security mechanisms. Security mechanism that media through different security mechanisms. Security mechanism that
skipping to change at page 3, line 5728 skipping to change at page 135, line 40
21 IANA Considerations 21 IANA Considerations
This section set up a number of registers for RTSP 2.0 that should be This section set up a number of registers for RTSP 2.0 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 is required to contain, what specification is needed when adding a it is required to contain, what specification is needed when adding a
entry with IANA, and finally the entries that this document needs to entry with IANA, and finally the entries that this document needs to
register. See also the section 1.6 "Extending RTSP". There is also an register. See also the section 1.6 "Extending RTSP". There is also an
IANA registration of two SDP attributes. 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 [19], namely "First Come, requirements level described in RFC 2434 [20], 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 A registration request to IANA MUST contain the following
information: information:
o A name of the item to register according to the rules o A name of the item to register according to the rules
specified by the intended registry. specified by the intended registry.
o Indication of who has change control over the feature (for o Indication of who has change control over the feature (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
skipping to change at page 3, line 5777 skipping to change at page 136, line 41
any length, but SHOULD be no more than twenty characters long. The any length, but SHOULD be no more than twenty characters long. The
name MUST NOT contain any spaces, or control characters. The name MUST NOT contain any spaces, or control characters. The
registration SHALL indicate if the feature tag applies to clients, registration SHALL indicate if the feature tag applies to clients,
servers, or proxies only or any combinations of these. Any servers, or proxies only or any combinations of these. Any
proprietary feature SHALL have as the first part of the name a vendor proprietary feature SHALL have as the first part of the name a vendor
tag, which identifies the organization. tag, which identifies the organization.
21.1.3 Registered entries 21.1.3 Registered entries
The following feature-tags are in this specification defined and The following feature-tags are in this specification defined and
hereby registered. The change control belongs to the Authors and the hereby registered. The change control belongs to the IETF.
IETF MMUSIC WG.
play.basic: The minimal implementation for playback operations play.basic: The minimal implementation for playback operations
according to section D. Applies for both clients, servers according to section D. Applies for both clients, servers
and proxies. and proxies.
play.scale: Support of scale operations for media playback. play.scale: Support of scale operations for media playback.
Applies only for servers. Applies only for servers.
play.speed: Support of the speed functionality for playback. play.speed: Support of the speed functionality for playback.
Applies only for servers Applies only for servers
skipping to change at page 3, line 5887 skipping to change at page 139, line 5
o A description of the purpose of the header. o A description of the purpose of the header.
21.4.3 Registered entries 21.4.3 Registered entries
All headers specified in section 14 in RFCXXXX are to be registered. All headers specified in section 14 in RFCXXXX are to be registered.
Furthermore the following RTSP headers defined in other Furthermore the following RTSP headers defined in other
specifications are registered: specifications are registered:
o x-wap-profile defined in [36]. o x-wap-profile defined in [40].
o x-wap-profile-diff defined in [36]. o x-wap-profile-diff defined in [40].
o x-wap-profile-warning defined in [36]. o x-wap-profile-warning defined in [40].
o x-predecbufsize defined in [36]. o x-predecbufsize defined in [40].
o x-initpredecbufperiod defined in [36]. o x-initpredecbufperiod defined in [40].
o x-initpostdecbufperiod defined in [36]. o x-initpostdecbufperiod defined in [40].
o 3gpp-videopostdecbufsize defined in [36]. o 3gpp-videopostdecbufsize defined in [40].
o 3GPP-Link-Char defined in [36]. o 3GPP-Link-Char defined in [40].
o 3GPP-Adaptation defined in [36]. o 3GPP-Adaptation defined in [40].
o 3GPP-QoE-Metrics defined in [36]. o 3GPP-QoE-Metrics defined in [40].
o 3GPP-QoE-Feedback defined in [36]. o 3GPP-QoE-Feedback defined in [40].
The use of "X-" is NOT RECOMMENDED but the above headers in the The use of "X-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
21.5 Transport Header registries 21.5 Transport Header registries
The transport header contains a number of parameters which have The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these possibilities for future extensions. Therefore registries for these
needs to be defined. needs to be defined.
skipping to change at page 3, line 5936 skipping to change at page 140, line 5
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF token o A value definition that are following the ABNF token
definition. definition.
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
used in RTSP. used in RTSP.
This specification registers 1 value: This specification registers 1 value:
o Use of the RTP [16] protocol for media transport. The usage o Use of the RTP [18] protocol for media transport. The usage is
is explained in RFC XXXX, appendix B.1. explained in RFC XXXX, appendix B.1.
21.5.2 Profile 21.5.2 Profile
A registry for the parameter profile SHALL be defined with the A registry for the parameter profile SHALL be defined with the
following rules: following rules:
o Registering requires public available standards specification. o Registering requires public available standards specification.
o A contact person or organization with address and email. o A contact person or organization with address and email.
skipping to change at page 3, line 5964 skipping to change at page 140, line 33
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
used in RTSP. used in RTSP.
This specification registers 3 value: This specification registers 3 value:
o The "RTP profile for audio and video conferences with minimal o The "RTP profile for audio and video conferences with minimal
control" [2] MUST only be used when the transport control" [2] MUST only be used when the transport
specification's transport-protocol is "RTP". specification's transport-protocol is "RTP".
o The "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" o The "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)"
[20] MUST only be used when the transport specification's [21] MUST only be used when the transport specification's
transport-protocol is "RTP" transport-protocol is "RTP"
o The "The Secure Real-time Transport Protocol (SRTP)" [21] MUST o The "The Secure Real-time Transport Protocol (SRTP)" [22] MUST
only be used when the transport specification's transport- only be used when the transport specification's transport-
protocol is "RTP". protocol is "RTP".
o The "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [6] MUST only be used when the transport
specification's transport-protocol is "RTP".
21.5.3 Lower Transport 21.5.3 Lower Transport
A registry for the parameter lower-transport SHALL be defined with A registry for the parameter lower-transport SHALL be defined with
the following rules: the following rules:
o Registering requires public available standards specification. o Registering requires public available standards specification.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the BNF token o A value definition that are following the BNF token
definition. definition.
o A text describing how the registered value are used in RTSP. o A text describing how the registered value are used in RTSP.
This specification registers 2 values: This specification registers 2 values:
UDP: Indicates the use of the "User datagram protocol" [9] for UDP: Indicates the use of the "User datagram protocol" [13] for
media transport. media transport.
TCP: Indicates the use Transmission control protocol [10] for TCP: Indicates the use Transmission control protocol [14] for
media transport. media transport.
21.5.4 Transport modes 21.5.4 Transport modes
A registry for the transport parameter mode SHALL be defined with the A registry for the transport parameter mode SHALL be defined with the
following rules: following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF standard tracks document.
o A contact person or organization with address and email. o A contact person or organization with address and email.
skipping to change at page 3, line 6067 skipping to change at page 142, line 44
max-stale: max-stale:
min-fresh: min-fresh:
must-revalidate: must-revalidate:
proxy-revalidate: proxy-revalidate:
max-age: max-age:
21.7 Accept-Credentials policies 21.7 Accept-Credentials
The security framework's TLS connection mechanism has two
registerable entities.
21.7.1 Accept-Credentials policies
In section 18.3.1 three policies for how to handle certificates. In section 18.3.1 three policies for how to handle certificates.
Further policies may be defined and SHALL be registered with IANA Further policies may be defined and SHALL be registered with IANA
using the following rules: using the following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF standard tracks document.
o A registration is required name a contact person. o A registration is required name a contact person.
o Name of the policy. o Name of the policy.
skipping to change at page 3, line 6090 skipping to change at page 143, line 23
handling the certificates. handling the certificates.
This specification registers the following values: This specification registers the following values:
Any Any
Proxy Proxy
User User
21.8 URI Schemes 21.7.2 Accept-Credentials hash algorithms
The Accept-Credentials header (See Section 14.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely
rare and could also be an interoperability problem. Therefore the
bare for registering new algorithms is placed intentional high.
Any registration of a new hash algorithm SHALL meet the following
requirement:
o Registration requires an IETF standard track document.
o A definition of the algorithm and its identifier meeting the
"token" ABNF requirement.
21.8 Range header formats
The Range header allows for different range formats. New ones may be
registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the
following requirements:
o A publicly available standards document
o A ABNF definition of the range format that fulfills the
"range-ext" definition.
o A Contact person for the registration
o Rules for how one handles the range when using a negative
Scale.
21.9 URI Schemes
This specification defines two URI schemes ("rtsp" and "rtsps") and This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). reserves a third one ("rtspu"). Registrations are following RFC 4395
[23].
This will need to be done in accordance with RFC 2717. 21.9.1 The rtsp URI Scheme
URI scheme name: rtsp
Status: Permanent
URI scheme syntax: See Section 19.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate
resources accessible through the usage of the Real-time
Streaming Protocol (RTSP). RTSP allows different operations
on the resource identified by the URI, but the primary
purpose is the streaming delivery of the resource to a
client. However the operations that are currently defined
are: Describing the resource for the purpose of configuring
the receiving entity (DESCRIBE), configuring the delivery
method and its addressing (SETUP), controlling the delivery
(PLAY and PAUSE), reading or setting of resource related
parameters (SET_PARAMETER and GET_PARAMETER, and
termination of the session context created (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and
needs to be encoded as RTSP URIs when used within the RTSP
protocol. That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0
(RFC 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The change in URI syntax
performed between RTSP 1.0 and 2.0 can create
interoperability issues.
Security considerations: All the security threats identified in
Section 7 of RFC 3986 applies also to this scheme. They
needs to be reviewed and considered in any implementation
utilizing this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF MMUSIC WG
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX,
21.9.2 The rtsps URI Scheme
URI scheme name: rtsps
Status: Permanent
URI scheme syntax: See Section 19.2.1 of RFC XXXX.
URI scheme semantics: The rtsps scheme is used to indicate
resources accessible through the usage of the Real-time
Streaming Protocol (RTSP) over TLS. RTSP allows different
operations on the resource identified by the URI, but the
primary purpose is the streaming delivery of the resource
to a client. However the operations that are currently
defined are: Describing the resource for the purpose of
configuring the receiving entity (DESCRIBE), configuring
the delivery method and its addressing (SETUP), controlling
the delivery (PLAY and PAUSE), reading or setting of
resource related parameters (SET_PARAMETER and
GET_PARAMETER, and termination of the session context
created (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and
needs to be encoded as RTSP URIs when used within the RTSP
protocol. That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0
(RFC 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The change in URI syntax
performed between RTSP 1.0 and 2.0 can create
interoperability issues.
Security considerations: All the security threats identified in
Section 7 of RFC 3986 applies also to this scheme. They
needs to be reviewed and considered in any implementation
utilizing this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF MMUSIC WG
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
21.9.3 The rtspu URI Scheme
URI scheme name: rtspu
Status: Permanent
URI scheme syntax: See Section 3.2 of RFC 2326.
URI scheme semantics: The rtspu scheme is used to indicate
resources accessible through the usage of the Real-time
Streaming Protocol (RTSP) over unrelaible datagram
transport. RTSP allows different operations on the resource
identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However the
operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving
entity (DESCRIBE), configuring the delivery method and its
addressing (SETUP), controlling the delivery (PLAY and
PAUSE), reading or setting of resource related parameters
(SET_PARAMETER and GET_PARAMETER, and termination of the
session context created (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and
needs to be encoded as RTSP URIs when used within the RTSP
protocol. That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0
(RFC 2326)
Interoperability considerations: The definition of the transport
mechanism of RTSP over UDP has interoperability issues.
That makes the usage of this scheme problematic.
Security considerations: All the security threats identified in
Section 7 of RFC 3986 applies also to this scheme. They
needs to be reviewed and considered in any implementation
utilizing this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF MMUSIC WG
References: RFC 2326, RFC 3986, RFC 3987
21.10 SDP attributes
21.9 SDP attributes
This specification defines two SDP [1] attributes that it is This specification defines two SDP [1] attributes that it is
requested that IANA register. requested that IANA register.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: range Attribute name: range
Long form: Media Range Attribute Long form: Media Range Attribute
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
Subject to charset: No Subject to charset: No
skipping to change at page 3, line 6211 skipping to change at page 149, line 21
state column tells which state the state machine changes to. state column tells which state the state machine changes to.
The response to valid request meeting the requisites is normally a The response to valid request meeting the requisites is normally a
2xx (SUCCESS) unless other noted in the response column. The 2xx (SUCCESS) unless other noted in the response column. The
exceptions needs to be given a response according to the response exceptions needs to be given a response according to the response
column. If the request does not meet the requisite, is erroneous or column. If the request does not meet the requisite, is erroneous or
some other type of error occur the appropriate response code MUST be some other type of error occur the appropriate response code MUST be
sent. If the response code is a 4xx the session state is unchanged. A sent. If the response code is a 4xx the session state is unchanged. A
response code of 3rr will result in that the session is ended and its response code of 3rr will result in that the session is ended and its
state is changed to Init. A response code of 304 results in no state state is changed to Init. A response code of 304 results in no state
change. However there exist restrictions to when a 3xx response may change. However there exist restrictions to when a 3rr response may
be used. A 5xx response SHALL not result in any change of the session be used. A 5xx response SHALL not result in any change of the session
state, except if the error is not possible to recover from. A state, except if the error is not possible to recover from. A
unrecoverable error SHALL result the ending of the session. As it in unrecoverable error SHALL result the ending of the session. As it in
the general case can't be determined if it was a unrecoverable error the general case can't be determined if it was a unrecoverable error
or not the client will be required to test. In the case that the next or not the client will be required to test. In the case that the next
request after a 5xx is responded with 454 (Session Not Found) the request after a 5xx is responded with 454 (Session Not Found) the
client knows that the session has ended. client knows that the session has ended.
The server will timeout the session after the period of time The server will timeout the session after the period of time
specified in the SETUP response, if no activity from the client is specified in the SETUP response, if no activity from the client is
detected. Therefore there exist a timeout event for all states detected. Therefore there exist a timeout event for all states
except Init. except Init.
In the case that NRM=1 the presentation URI is equal to the media In the case that NRM=1 the presentation URI is equal to the media URI
URI. For NRM>1 the presentation URI MUST be other than any of the or a specified presentation URI. For NRM>1 the presentation URI MUST
medias that are part of the session. This applies to all states. be other than any of the medias that are part of the session. This
applies to all states.
The methods in Table 13 do not have any effect on the state machine The methods in Table 13 do not have any effect on the state machine
or the state variables. However some methods do change other session or the state variables. However some methods do change other session
related parameters, for example SET_PARAMETER which will set the related parameters, for example SET_PARAMETER which will set the
parameter(s) specified in its body. Also all of these methods that parameter(s) specified in its body. Also all of these methods that
allows Session header will also update the keep-alive timer for the allows Session header will also update the keep-alive timer for the
session. session.
The initial state of the state machine, see Table 14 can only be left
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
Event Prerequisite Response Event Prerequisite Response
______________________________________________________________ ______________________________________________________________
DESCRIBE Needs REDIRECT 3rr, Redirect DESCRIBE Needs REDIRECT 3rr, Redirect
DESCRIBE 200, Session description DESCRIBE 200, Session description
OPTIONS Session ID 200, Reset session timeout timer OPTIONS Session ID 200, Reset session timeout timer
OPTIONS 200 OPTIONS 200
SET_PARAMETER Valid parameter 200, change value of parameter SET_PARAMETER Valid parameter 200, change value of parameter
GET_PARAMETER Valid parameter 200, return value of parameter GET_PARAMETER Valid parameter 200, return value of parameter
Table 13: None state-machine changing events Table 13: None state-machine changing events
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 Redirect SETUP Needs Redirect Init 3rr Redirect
S -> C:REDIRECT No Session hdr Init Terminate all SES S -> C:REDIRECT No Session hdr Init Terminate all SES
Table 14: State: Init Table 14: State: Init
The initial state of the state machine, see Table 14 can only be left
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
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
URI and/or server by a 3rr response. URI and/or server by a 3rr response.
In the Ready state, see Table 15, 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 URI) 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 the
presentations URI the whole session is torn down. If a media URI 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 performing a TEARDOWN with a media URI the session
is removed. The number of media streams remaining after tearing down
a media stream determines the new state.
Action Requisite New State Response Action Requisite New State Response
_____________________________________________________________________ _____________________________________________________________________
SETUP New URI Ready NRM+=1 SETUP New URI Ready NRM+=1
SETUP Setten up URI Ready Change transport param SETUP Setten up URI Ready Change transport param
TEARDOWN Prs URI,NRM>1 Init No session hdr, NRM=0 TEARDOWN Prs URI, Init No session hdr, NRM=0
TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0
TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1 TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1
PLAY Prs URI, No range Play Play from RP PLAY Prs URI, No range Play Play from RP
PLAY Prs URI, Range Play According to range PLAY Prs URI, Range Play According to range
PAUSE Prs URI Ready Return PP PAUSE Prs URI Ready Return PP
S -> C:REDIRECT Range hdr Ready Set RedP S -> C:REDIRECT Range hdr Ready Set RedP
S -> C:REDIRECT no range hdr Init Session is removed S -> C:REDIRECT no range hdr Init Session is removed
Timeout Init Timeout Init
RedP reached Init TEARDOWN of session RedP reached Init TEARDOWN of session
Table 15: State: Ready Table 15: State: Ready
Action Requisite New State Response In the Ready state, see Table 15, 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 URI) 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 the
presentations URI the whole session is torn down. If a media URI 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 performing a TEARDOWN with a media URI the session
is removed. The number of media streams remaining after tearing down
a media stream determines the new state.
______________________________________________________________________ Action Requisite New State Response
PAUSE PrsURI,No range Ready Set RP to present point ____________________________________________________________________
PAUSE PrsURI,Range>now Play Set RP & PP to given p. PAUSE PrsURI Ready Set RP to present point
PAUSE PrsURI,Range<now Ready Set RP to Range Hdr.
PP reached Ready RP = PP PP reached Ready RP = PP
End of media All media Play Set RP = End of media End of media All media Play Set RP = End of media
End of range Play Set RP = End of range End of range Play Set RP = End of range
PLAY Prs URI, No range Play Play from present point PLAY Prs URI, No range Play Play from present point
PLAY Prs URI, Range Play According to range PLAY Prs URI, Range Play According to range
SETUP New URI Play 455 SETUP New URI Play 455
SETUP Setuped URI Play 455 SETUP Setuped URI Play 455
SETUP Setuped URI, IFI Play Change transport param. SETUP Setuped URI, IFI Play Change transport param.
TEARDOWN Prs URI,NRM>1 Init No session hdr TEARDOWN Prs URI Init No session hdr
TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0
TEARDOWN md URI Play 455 TEARDOWN md URI 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 Session is removed S -> C:REDIRECT no range hdr Init Session is removed
RedP reached Init TEARDOWN of session RedP reached Init TEARDOWN of session
Timeout Init Stop Media playout Timeout Init Stop Media playout
Table 16: State: Play Table 16: State: Play
The Play state table, see Table 16, is the largest. The table The Play state table, see Table 16, is the largest. The table
contains an number of requests that has presentation URI as a contains an number of requests that has presentation URI as a
prerequisite on the Request-URI, this is due to the exclusion of prerequisite on the Request-URI, this is due to the exclusion of
non-aggregated stream control in sessions with more than one media non-aggregated stream control in sessions with more than one media
stream. stream.
To avoid inconsistencies between the client and server, automatic To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request MUST be sent to 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 change the state to Ready. It may appear that there exist an
automatic transitions in "RedP reached" and "PP reached", however automatic transitions in "RedP reached" and "PP reached", however
they are requested and acknowledge before they take place. The time they are requested and acknowledge before they take place. The time
at which the transition will happen is known by looking at the range at which the transition will happen is known by looking at the range
header. If the client sends request close in time to these header. If the client sends request close in time to these
transitions it needs to be prepared for getting error message as the transitions it needs to be prepared for getting error message as the
state may or may not have changed. state may or may not have changed.
B Media Transport Alternatives B Media Transport Alternatives
This section defines how certain combinations of protocols, profiles This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
Transport header's source and destination address parameters Transport header's source and destination address parameters
"src_addr" and "dest_addr". "src_addr" and "dest_addr".
B.1 RTP B.1 RTP
This section defines the interaction of RTSP with respect to the RTP This section defines the interaction of RTSP with respect to the RTP
protocol [16]. It also defines any necessary media transport protocol [18]. It also defines any necessary media transport
signalling with regards to RTP. signalling with regards to RTP.
The av