draft-ietf-mmusic-rfc2326bis-10.txt   draft-ietf-mmusic-rfc2326bis-11.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-10.txt Columbia U. draft-ietf-mmusic-rfc2326bis-11.txt Columbia U.
July 18, 2005 Anup Rao October 24, 2005 A. Rao
Expires: January 18, 2006 Cisco Expires: April, 2006 Cisco
Robert Lanphier R. Lanphier
Real Networks Real Networks
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Aravind Narasimhan A. Narasimhan
Overture Computing Overture
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This memorandum defines RTSP version 1.1 which is a revision of the This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in RFC 2326. Proposed Standard RTSP version 1.0 which is defined in RFC 2326.
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.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 ...................................... 19
2.1 On-demand Playback of Stored Content ................ 20
2.2 Unicast distribution of Live Content ................ 21
2.3 On-demand Playback using Multicast .................. 21
2.4 Inviting a RTSP server into a conference ............ 22
2.5 Live Content using Multicast ........................ 23
3 Protocol Parameters ................................. 23
3.1 RTSP Version ........................................ 23
3.2 RTSP URI ............................................ 23
3.3 Session Identifiers ................................. 25
3.4 SMPTE Relative Timestamps ........................... 25
3.5 Normal Play Time .................................... 26
3.6 Absolute Time ....................................... 27
3.7 Feature-tags ........................................ 27
3.8 Entity Tags ......................................... 27
4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 28
4.2 Message Headers ..................................... 28
4.3 Message Body ........................................ 28
4.4 Message Length ...................................... 29
5 General Header Fields ............................... 29
6 Request ............................................. 30
6.1 Request Line ........................................ 30
6.2 Request Header Fields ............................... 31
7 Response ............................................ 32
7.1 Status-Line ......................................... 32
7.1.1 Status Code and Reason Phrase ....................... 33
7.1.2 Response Header Fields .............................. 34
8 Entity .............................................. 34
8.1 Entity Header Fields ................................ 34
8.2 Entity Body ......................................... 34
9 Connections ......................................... 35
9.1 Reliability and Acknowledgements .................... 35
9.2 Using Connections ................................... 38
9.3 Closing Connections ................................. 39
9.4 Timing Out Connections and RTSP Messages ............ 40
9.5 Use of IPv6 ......................................... 40
10 Capability Handling ................................. 41
11 Method Definitions .................................. 42
11.1 OPTIONS ............................................. 43
11.2 DESCRIBE ............................................ 44
11.3 SETUP ............................................... 46
11.3.1 Changing Transport Parameters ....................... 48
11.4 PLAY ................................................ 49
11.5 PAUSE ............................................... 53
11.6 TEARDOWN ............................................ 57
11.7 GET_PARAMETER ....................................... 58
11.8 SET_PARAMETER ....................................... 59
11.9 REDIRECT ............................................ 60
12 Embedded (Interleaved) Binary Data .................. 62
13 Status Code Definitions ............................. 64
13.1 Success 1xx ......................................... 64
13.1.1 100 Continue ........................................ 64
13.2 Success 2xx ......................................... 64
13.3 Redirection 3xx ..................................... 64
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 ....................................... 65
13.3.5 304 Not Modified .................................... 65
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 .............................. 66
13.4.3 451 Parameter Not Understood ........................ 66
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 ................................... 67
13.4.10 458 Parameter Is Read-Only .......................... 67
13.4.11 459 Aggregate Operation Not Allowed ................. 67
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 ............. 68
13.5 Server Error 5xx .................................... 68
13.5.1 551 Option not supported ............................ 68
14 Header Field Definitions ............................ 69
14.1 Accept .............................................. 71
14.2 Accept-Credentials .................................. 71
14.3 Accept-Encoding ..................................... 75
14.4 Accept-Language ..................................... 75
14.5 Accept-Ranges ....................................... 75
14.6 Allow ............................................... 76
14.7 Authorization ....................................... 76
14.8 Bandwidth ........................................... 76
14.9 Blocksize ........................................... 76
14.10 Cache-Control ....................................... 77
14.11 Connection .......................................... 79
14.12 Connection-Credentials .............................. 79
14.13 Content-Base ........................................ 80
14.14 Content-Encoding .................................... 80
14.15 Content-Language .................................... 80
14.16 Content-Length ...................................... 80
14.17 Content-Location .................................... 80
14.18 Content-Type ........................................ 80
14.19 CSeq ................................................ 81
14.20 Date ................................................ 81
14.21 ETag ................................................ 81
14.22 Expires ............................................. 82
14.23 From ................................................ 83
14.24 Host ................................................ 83
14.25 If-Match ............................................ 83
14.26 If-Modified-Since ................................... 83
14.27 If-None-Match ....................................... 83
14.28 Last-Modified ....................................... 84
14.29 Location ............................................ 84
14.30 Proxy-Authenticate .................................. 84
14.31 Proxy-Require ....................................... 84
14.32 Proxy-Supported ..................................... 84
14.33 Public .............................................. 85
14.34 Range ............................................... 86
14.35 Referer ............................................. 88
14.36 Retry-After ......................................... 88
14.37 Require ............................................. 88
14.38 RTP-Info ............................................ 89
14.39 Scale ............................................... 91
14.40 Speed ............................................... 91
14.41 Server .............................................. 92
14.42 Session ............................................. 92
14.43 Supported ........................................... 94
14.44 Timestamp ........................................... 94
14.45 Transport ........................................... 95
14.46 Unsupported ......................................... 99
14.47 User-Agent .......................................... 100
14.48 Vary ................................................ 100
14.49 Via ................................................. 100
14.50 WWW-Authenticate .................................... 100
15 Proxies ............................................. 100
16 Caching ............................................. 101
17 Examples ............................................ 102
17.1 Media on Demand (Unicast) ........................... 102
17.2 Streaming of a Container file ....................... 105
17.3 Single Stream Container Files ....................... 108
17.4 Live Media Presentation Using Multicast ............. 110
17.5 Capability Negotiation .............................. 111
18 Security Framework .................................. 112
18.1 RTSP and HTTP Authentication ........................ 112
18.2 RTSP over TLS ....................................... 112
18.3 Security and Proxies ................................ 113
18.3.1 Accept-Credentials .................................. 114
18.3.2 User approved TLS procedure ......................... 115
19 Syntax .............................................. 117
19.1 Base Syntax ......................................... 117
19.2 RTSP Protocol Definition ............................ 119
19.2.1 Generic Protocol elements ........................... 119
19.2.2 Message Syntax ...................................... 120
19.2.3 Header Syntax ....................................... 124
19.3 SDP extension Syntax ................................ 129
20 Security Considerations ............................. 130
20.1 Remote denial of Service Attack ..................... 132
21 IANA Considerations ................................. 132
21.1 Feature-tags ........................................ 133
21.1.1 Description ......................................... 133
21.1.2 Registering New Feature-tags with IANA .............. 133
21.1.3 Registered entries .................................. 133
21.2 RTSP Methods ........................................ 134
21.2.1 Description ......................................... 134
21.2.2 Registering New Methods with IANA ................... 134
21.2.3 Registered Entries .................................. 134
21.3 RTSP Status Codes ................................... 134
21.3.1 Description ......................................... 134
21.3.2 Registering New Status Codes with IANA .............. 135
21.3.3 Registered Entries .................................. 135
21.4 RTSP Headers ........................................ 135
21.4.1 Description ......................................... 135
21.4.2 Registering New Headers with IANA ................... 135
21.4.3 Registered entries .................................. 136
21.5 Transport Header registries ......................... 136
21.5.1 Transport Protocols ................................. 136
21.5.2 Profile ............................................. 137
21.5.3 Lower Transport ..................................... 137
21.5.4 Transport modes ..................................... 138
21.5.5 Transport Parameters ................................ 138
21.6 Cache Directive Extensions .......................... 139
21.7 Accept-Credentials policies ......................... 139
21.8 URI Schemes ......................................... 140
21.9 SDP attributes ...................................... 140
A RTSP Protocol State Machine ......................... 141
A.1 States .............................................. 141
A.2 State variables ..................................... 142
A.3 Abbreviations ....................................... 142
A.4 State Tables ........................................ 142
B Media Transport Alternatives ........................ 145
B.1 RTP ................................................. 146
B.1.1 AVP ................................................. 146
B.1.2 AVP/UDP ............................................. 146
B.1.3 AVP/TCP ............................................. 147
B.1.4 AVPF ................................................ 148
B.1.5 SAVP ................................................ 148
B.1.6 Handling NPT Jumps in the RTP Media Layer ........... 148
B.1.7 Handling RTP Timestamps after PAUSE ................. 151
B.1.8 RTSP / RTP Integration .............................. 153
B.1.9 Scaling with RTP .................................... 153
B.1.10 Maintaining NPT synchronization with RTP
timestamps .......................................... 153
B.1.11 Continuous Audio .................................... 153
B.1.12 Multiple Sources in an RTP Session .................. 153
B.1.13 Usage of SSRCs and the RTCP BYE Message During an
RTSP Session ........................................ 154
B.2 Future Additions .................................... 154
C Use of SDP for RTSP Session Descriptions ............ 155
C.1 Definitions ......................................... 155
C.1.1 Control URI ......................................... 155
C.1.2 Media Streams ....................................... 156
C.1.3 Payload Type(s) ..................................... 157
C.1.4 Format-Specific Parameters .......................... 157
C.1.5 Range of Presentation ............................... 157
C.1.6 Time of Availability ................................ 158
C.1.7 Connection Information .............................. 158
C.1.8 Entity Tag .......................................... 158
C.2 Aggregate Control Not Available ..................... 159
C.3 Aggregate Control Available ......................... 160
C.4 RTSP external SDP delivery .......................... 161
D Minimal RTSP implementation ......................... 161
D.1 Minimal Core Implementation ......................... 161
D.2 The Basic Playback Feature Support .................. 162
D.2.1 Client .............................................. 162
D.2.2 Server .............................................. 163
D.2.3 Proxy ............................................... 163
D.3 Secure Transport .................................... 163
D.4 Old Implementation Text ............................. 163
D.5 Client .............................................. 164
D.5.1 Basic Playback ...................................... 164
D.5.2 Authentication-enabled .............................. 165
D.6 Server .............................................. 165
D.6.1 Basic Playback ...................................... 166
D.6.2 Authentication-enabled .............................. 166
E Requirements for Unreliable Transport of RTSP
messages ............................................ 167
F Backwards Compatibility Considerations .............. 168
F.1 Play Request in Play mode ........................... 168
F.2 Using Persistent Connections ........................ 168
G Open Issues ......................................... 169
H Changes ............................................. 169
H.1 Changes needing to be updated ....................... 175
I Author Addresses .................................... 175
J Contributors ........................................ 176
K Acknowledgements .................................... 176
L Normative References ................................ 177
M Informative References .............................. 179
1 Introduction 1 Introduction
1.1 RTSP Specification Update 1.1 RTSP Specification Update
This memorandum specifies RTSP 1.1 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 [24]. 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 full 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 A few open issues still remain to be resolved, and are listed in
appendix G. These are intended to be close quickly. appendix G. These are intended to be close quickly.
A list of bugs against RFC 2326 is available at A list of bugs against RFC 2326 is available at
"http://rtspspec.sourceforge.net". These bugs should be taken into "http://rtspspec.sourceforge.net". These bugs should be taken into
account when reading this memorandum. Input on the unresolved bugs 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 and other issues can be sent via e-mail to the MMUSIC WG's mailing
list mmusic@ietf.org and the authors. list mmusic@ietf.org and the authors.
RTSP 1.1 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. The Working group has discussed a number of different
proposals to extensions and is currently working on: proposals to extensions and is currently working on:
o NAT and FW traversal mechanisms for RTSP are described in a o NAT and FW traversal mechanisms for RTSP are described in a
document called "How to make Real-Time Streaming Protocol document called "How to make Real-Time Streaming Protocol
(RTSP) traverse Network Address Translators (NAT) and interact (RTSP) traverse Network Address Translators (NAT) and interact
skipping to change at page 11, line 38 skipping to change at page 3, line 135
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]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail prose and the Augmented Backus-Naur form (ABNF) described in detail
in RFC 2234 [4]. in RFC 4234 [4].
Indented and smaller-type paragraphs are used to provide informative Indented and smaller-type paragraphs are used to provide informative
background and motivation. This is intended to give readers who were background and motivation. This is intended to give readers who were
not involved with the formulation of the specification an not involved with the formulation of the specification an
understanding of why things are the way they are in RTSP. understanding of why things are the way they are in RTSP.
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].
skipping to change at page 14, line 48 skipping to change at page 3, line 291
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 zero or more media
streams associated with it. An RTSP server uses the session streams associated with it. An RTSP server uses the session
to aggregate control over multiple media streams. 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 [10]. In RTSP URI: Universal Resource Identifier, see RFC 3986 [6]. 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 15, line 22 skipping to change at page 3, line 313
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 [6]) or within the protocol transport level (TLS, RFC 2246 [7]) 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 [7]) are (RFC 2616 [3]) and digest authentication (RFC 2617 [8]) are
directly applicable. directly applicable.
Transport-independent: RTSP does not preclude the use of an Transport-independent: RTSP does not preclude the use of an
unreliable datagram protocol (UDP) (RFC 768 [8]) as it unreliable datagram protocol (UDP) (RFC 768 [9]) 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 [9]) and usage of the reliable stream protocol TCP (RFC 793 [10])
secured reliable stream protocol TLS over TCP [6] is what and secured reliable stream protocol TLS over TCP [7] is
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
performed at the transport level. 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
skipping to change at page 23, line 48 skipping to change at page 3, line 724
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 [24] 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 1.1 of RTSP. RTSP. This specification defines version 2.0 of RTSP.
3.2 RTSP URI 3.2 RTSP URI
The "rtsp", "rtsps" schemes are used to refer to network resources The "rtsp", "rtsps" schemes are used to refer to network resources
via the RTSP protocol. This section defines the scheme-specific via the RTSP protocol. This section defines the scheme-specific
syntax and semantics for RTSP URIs. The RTSP URI is case sensitive. 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 An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP
messages over unreliable transport (UDP) and is currently deprecated messages over unreliable transport (UDP) and is currently deprecated
and reserved, and MUST NOT be used . See Appendix E for further and reserved, and MUST NOT be used . See Appendix E for further
information. information.
Informative RTSP URI syntax: Informative RTSP URI syntax:
rtsp[u|s]://host[:port]/abspath[?query]#fragment rtsp[u|s]://host[:port]/abspath[?query]#fragment
See section 19.2.1 for the formal definition of the RTSP URI syntax. See section 19.2.1 for the formal definition of the RTSP URI syntax.
The fragment identifier is used as defined in section 4.1 of [10], The fragment identifier is used as defined in section 4.1 of [6],
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 [6]). identifies a reliable transport using secure transport (TLS [7]).
If the no port number is provided in the URI, port number 554 SHALL If the no port number is provided in the URI, port number 554 SHALL
be used. The semantics are that the identified resource can be be used. The semantics are that the identified resource can be
controlled by RTSP at the server listening for TCP (scheme "rtsp") controlled by RTSP at the server listening for TCP (scheme "rtsp")
connections on that port of host, and the Request-URI for the connections on that port of host, and the Request-URI for the
resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322 resource is rtsp_URI. For the scheme rtsps the TCP and UDP 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 The use of IP addresses in URIs SHOULD be avoided whenever possible
(see RFC 1924 [11]). This specification updates the RTSP URI scheme (see RFC 1924 [11]). This specification updates the RTSP URI scheme
to allow for literal IPv6 addresses using the host specification in to allow for literal IPv6 addresses using the host specification in
RFC 2732 [12]. RFC 2732 [12].
Note: Using qualified domain names in any URI is one Note: Using qualified domain names in any URI is one
requirement for making it possible for RTSP 1.0 (RFC 2326) requirement for making it possible for RTSP 1.0 (RFC 2326)
implementations of RTSP to use IPv6. 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 [H3.2] of
URIs (RFC 3986 [10]). URIs may refer to a stream or an aggregate of URIs (RFC 3986 [6]). 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
skipping to change at page 31, line 25 skipping to change at page 3, line 1060
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 in the Request-URI to indicate that the
request does not apply to a particular resource, but to the server or request does not apply to a particular resource, but to the server or
proxy itself, and is only allowed when the request method does not proxy itself, and is only allowed when the request method does not
necessarily apply to a resource. necessarily apply to a resource.
For example: For example:
OPTIONS * RTSP/1.1 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/1.1 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. These headers may
also be used in the response to a request, as response headers, to also be used in the response to a request, as response headers, to
modify the specifics of a response (Section 7.1.2). modify the specifics of a response (Section 7.1.2).
Detailed headers definition are provided in Section 14. Detailed headers definition are provided in Section 14.
skipping to change at page 33, line 34 skipping to change at page 3, line 1155
o 3rr: Redirection - Further action needs to be taken in order o 3rr: Redirection - Further action needs to be taken in order
to complete the request to complete the request
o 4xx: Client Error - The request contains bad syntax or cannot o 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled be fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently o 5xx: Server Error - The server failed to fulfill an apparently
valid request valid request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/1.1, and an example set of corresponding Reason-Phrases, are RTSP/2.0, and an example set of corresponding Reason-Phrases, are
presented in table 4. The reason phrases listed here are only presented in table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 [3] affecting the protocol. Note that RTSP adopts most HTTP/1.1 [3]
status codes and adds RTSP-specific status codes starting at x50 to status codes and adds RTSP-specific status codes starting at x50 to
avoid conflicts with newly defined HTTP status codes. avoid conflicts with newly defined HTTP status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
skipping to change at page 35, line 22 skipping to change at page 3, line 1236
o persistent - transport connections used for several o persistent - transport connections used for several
request/response transactions; request/response transactions;
o transient - transport connections used for a single o transient - transport connections used for a single
request/response transaction. request/response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient enough detail to as UDP. However, it was not specified in sufficient enough detail to
allow for interoperable implementations. In an attempt to reduce allow for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 1.1 does not 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 attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect is that RTSP connectionless transport protocols. A side-effect is that RTSP
requests SHALL NOT be sent to multicast groups since no connection requests SHALL NOT be sent to multicast groups since no connection
can be established with a specific receiver in multicast can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 14.19), which Certain RTSP headers, such as the CSeq header (Section 14.19), which
may appear to be relevant to only connectionless transport scenarios may appear to be relevant to only connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq it is quite useful in proxy specification. In the case of CSeq it is quite useful in proxy
skipping to change at page 40, line 50 skipping to change at page 3, line 1500
A requestor SHOULD wait longer than 10 seconds for a response if it A requestor SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requestor is capable of determining the RTT of the responder. The requestor is capable of determining the RTT of the
request/response cycle using the Timestamp header (section 14.44) in request/response cycle using the Timestamp header (section 14.44) in
any RTSP request. any RTSP request.
9.5 Use of IPv6 9.5 Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
1.1 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 1.1 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
10 Capability Handling 10 Capability Handling
This section describes the capability handling mechanism available in This section describes the capability handling mechanism available in
RTSP which allows RTSP to be extended. Extensions to this version of RTSP which allows RTSP to be extended. Extensions to this version of
the protocol are basically done in two ways. First, new headers can the protocol are basically done in two ways. First, new headers can
be added. Secondly, new methods can be added. The capability handling be added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
skipping to change at page 44, line 29 skipping to change at page 3, line 1671
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive However, it is not the preferred means of session keep-alive
signalling, see section 14.42. An OPTIONS request intended for signalling, see section 14.42. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS * RTSP/1.1 C->S: OPTIONS * RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: Require:
Proxy-Require: gzipped-messages Proxy-Require: gzipped-messages
Supported: play.basic Supported: play.basic
S->C: RTSP/1.1 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 necessarily fictional features (one would hope that we would not
purposefully overlook a truly useful feature just so that we could purposefully overlook a truly useful feature just so that we could
have a strong example in this section). have a strong example in this section).
skipping to change at page 45, line 15 skipping to change at page 3, line 1701
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:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.1 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/rtsl, application/mheg Accept: application/sdp, application/rtsl, application/mheg
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 367 Content-Length: 367
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
skipping to change at page 47, line 20 skipping to change at page 3, line 1798
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 In a SETUP response the server SHOULD include the Accept-Ranges
header (see section 14.5 to indicate which time formats that are header (see section 14.5 to indicate which time formats that are
acceptable to use for this media resource. acceptable to use for this media resource.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.1 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/1.1 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
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589";
src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; src_addr="192.0.2.241:6256"/"192.0.2.241:6257";
ssrc=2A3F93ED ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
skipping to change at page 50, line 21 skipping to change at page 3, line 1940
reached. To allow for precise composition multiple ranges MAY be reached. To allow for precise composition multiple ranges MAY be
specified in one PLAY Request. The range values are valid if all specified in one PLAY Request. The range values are valid if all
given ranges are part of any media within the aggregate. If a given given ranges are part of any media within the aggregate. If a given
range value points outside of the media, the response SHALL be the range value points outside of the media, the response SHALL be the
457 (Invalid Range) error code. 457 (Invalid Range) error code.
The below example will first play seconds 10 through 15, then, The below example will first play seconds 10 through 15, then,
immediately following, seconds 20 to 25, and finally seconds 30 immediately following, seconds 20 to 25, and finally seconds 30
through the end. through the end.
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.1 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=20-25, npt=30- Range: npt=10-15, npt=20-25, npt=30-
See the description of the PAUSE request for further examples. See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It SHALL start A PLAY request without a Range header is legal. It SHALL start
playing a stream from the beginning (npt=0-) unless the stream has playing a stream from the beginning (npt=0-) unless the stream has
been paused or is currently playing. If a stream has been paused via been paused or is currently playing. If a stream has been paused via
PAUSE, stream delivery resumes at the pause point. If a stream is PAUSE, stream delivery resumes at the pause point. If a stream is
skipping to change at page 51, line 22 skipping to change at page 3, line 1986
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.
Example: Single audio stream (MIDI) Example: Single audio stream (MIDI)
C->S: PLAY rtsp://example.com/audio RTSP/1.1 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=7.05- Range: npt=7.05-
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
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=3.52- Range: npt=3.52-
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration: 4.15 seconds Duration: 4.15 seconds
skipping to change at page 52, line 40 skipping to change at page 3, line 2048
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
headers has been broken into several lines to fit the page. headers has been broken into several lines to fit the page.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.1 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 833 CSeq: 833
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: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
RTP-Info:url="rtsp://example.com/twister.en" RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be For playing back a recording of a live presentation, it may be
desirable to use clock units: desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.1 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
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: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
RTP-Info:url="rtsp://example.com/meeting.en" RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019 ssrc=0D12F123:seq=53745;rtptime=484589019
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
skipping to change at page 54, line 11 skipping to change at page 3, line 2111
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only an aggregated session SHALL be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/1.1 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
Range: npt=45.76- Range: npt=45.76-
The PAUSE request MAY contain a Range header specifying when the The PAUSE request MAY contain a Range header specifying when the
stream or presentation is to be halted. This point is referred to as 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 "pause point". The time parameter in the Range MUST NOT be used.
The Range header MUST contain a single value, expressed as the The Range header MUST contain a single value, expressed as the
beginning value an open range. For example, the following clip will beginning value an open range. For example, the following clip will
be played from 10 seconds through 21 seconds of the clip's normal be played from 10 seconds through 21 seconds of the clip's normal
play time, under the assumption that the PAUSE request reaches the play time, under the assumption that the PAUSE request reaches the
server within 11 seconds of the PLAY request. Note that some lines server within 11 seconds of the PLAY request. Note that some lines
has been broken in an non-correct way to fit the page: has been broken in an non-correct way to fit the page:
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.1 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-30
S->C: RTSP/1.1 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-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=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=21- Range: npt=21-
S->C: RTSP/1.1 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=21-
Session: 12345678 Session: 12345678
The pause request becomes effective the first time the server is The pause request becomes effective the first time the server is
encountering the time point specified in any of the multiple ranges. encountering the time point specified in any of the multiple ranges.
If the Range header specifies a time outside any range from the PLAY 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 request, the error 457 (Invalid Range) SHALL be returned. If a media
skipping to change at page 56, line 13 skipping to change at page 3, line 2203
As another example, if a server has received requests to play ranges As another example, if a server has received requests to play ranges
10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE
request for NPT=14 would take effect while the server plays the first request for NPT=14 would take effect while the server plays the first
range, with the second range effectively being ignored, assuming the range, with the second range effectively being ignored, assuming the
PAUSE request arrives before the server has started playing the PAUSE request arrives before the server has started playing the
second, overlapping range. Regardless of when the PAUSE request second, overlapping range. Regardless of when the PAUSE request
arrives, it sets the pause point to 14. The below example messages is 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 for the above case when the PAUSE request arrives before the first
occurrence of NPT=14. occurrence of NPT=14.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.1 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-15, npt=13-20
S->C: RTSP/1.1 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-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=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=14- Range: npt=14-
S->C: RTSP/1.1 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=14-15, npt=13-20
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, even if the
PAUSE request is asking for some other 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/1.1 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/1.1 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/1.1 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: 86- Range: 86-
S->C: RTSP/1.1 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
skipping to change at page 58, line 7 skipping to change at page 3, line 2288
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 that
will exist after the processing of the TEARDOWN request SHALL in the will exist after the processing of the TEARDOWN request SHALL in the
response to that TEARDOWN request contain a Session header. Thus the response to that TEARDOWN request contain a Session header. Thus the
presence of the Session indicates to the receiver of the response if presence of the Session indicates to the receiver of the response if
the session is still existing or has been removed. the session is still existing or has been removed.
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.1 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
11.7 GET_PARAMETER 11.7 GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter or The GET_PARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URI. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
skipping to change at page 58, line 34 skipping to change at page 3, line 2315
request is successful, i.e. a 200 OK response is received, then the request is successful, i.e. a 200 OK response is received, then the
keep-alive timer has been updated. Any non-required header present in keep-alive timer has been updated. Any non-required header present in
such a request may or may not been processed. To allow a client to such a request may or may not been processed. To allow a client to
determine if any such header has been processed, it is necessary to determine if any such header has been processed, it is necessary to
use a feature tag and the Require header. Due to this reason it is use a feature tag and the Require header. Due to this reason it is
RECOMMENDED that any parameters to be retrieved are sent in the body, RECOMMENDED that any parameters to be retrieved are sent in the body,
rather than using any header. rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.1 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
packets_received packets_received
jitter jitter
C->S: RTSP/1.1 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Content-Length: 38 Content-Length: 38
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
The "text/parameters" section is only an example type for a The "text/parameters" section is only an example type for a
body carrying parameters. body carrying parameters.
11.8 SET_PARAMETER 11.8 SET_PARAMETER
skipping to change at page 59, line 48 skipping to change at page 3, line 2375
The parameters are split in a fine-grained fashion so that The parameters are split in a fine-grained fashion so that
there can be more meaningful error indications. However, it there can be more meaningful error indications. However, it
may make sense to allow the setting of several parameters may make sense to allow the setting of several parameters
if an atomic setting is desirable. Imagine device control if an atomic setting is desirable. Imagine device control
where the client does not want the camera to pan unless it where the client does not want the camera to pan unless it
can also tilt to the right angle at the same time. can also tilt to the right angle at the same time.
Example: Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.1 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421 CSeq: 421
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/1.1 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
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameter. 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 after further experimentation. content will be defined by the one desiring to use this
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
required to connect to another server location to access the resource required to connect to another server location to access the resource
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
skipping to change at page 62, line 31 skipping to change at page 3, line 2498
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.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.1 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
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
skipping to change at page 63, line 37 skipping to change at page 3, line 2549
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 needed for synchronization when two or more streams
are interleaved in such a fashion. Also, this provides a are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP convenient way to tunnel RTP/RTCP packets through the TCP
control connection when required by the network control connection when required by the network
configuration and transfer them onto UDP when possible. configuration and transfer them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/1.1 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/1.1 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
C->S: PLAY rtsp://example.com/bar.file RTSP/1.1 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url="rtsp://example.com/bar.file" RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
skipping to change at page 65, line 47 skipping to change at page 3, line 2643
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
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.1 (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.26) 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:
skipping to change at page 71, line 42 skipping to change at page 3, line 2924
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 any trusted intermediary how to handle further secured connections to
proxies or servers. See section 18 for the usage of this header. It proxies or servers. See section 18 for the usage of this header. It
SHALL only be included in client to server requests. SHALL only be included in client to server requests.
In a request the header SHALL contain the method (User, Proxy, or In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy. If the method is "User" the header 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,
and the SHA-1 [14] hash computed over that entity's DER encoded
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 - - o - - - Accept-Ranges r r - - o - - -
Accept-Ranges 456 r - - - o o - Accept-Ranges 456 r - - - o o -
Allow r am - 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 - - -
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 o o o o o o
Content-Encoding R r - - - - - - Content-Encoding R r - - - - - -
skipping to change at page 73, line 44 skipping to change at page 3, line 3008
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
credential SHALL consist of one URI identifying the proxy or server,
and the SHA-1 [14] hash computed over that entity's DER encoded
certificate [15] in Base64 [35]. certificate [15] in Base64 [35].
Example:
Accept-Credentials:User,
"rtsps://proxy2.example.com/";exaIl9VMbQMOFGClx5rXnPJKVNI=,
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 -
skipping to change at page 75, line 34 skipping to change at page 3, line 3090
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=,
"rtsps://server.example.com/";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.
skipping to change at page 76, line 25 skipping to change at page 3, line 3131
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 methods allowed for the resource is different than the minimal
implementation set.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER Allow: SETUP, PLAY, SET_PARAMETER
14.7 Authorization 14.7 Authorization
See [H14.8] See [H14.8]
14.8 Bandwidth 14.8 Bandwidth
skipping to change at page 82, line 35 skipping to change at page 3, line 3423
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by HTTP-date in The format is an absolute date and time as defined by HTTP-date in
[H3.3]; it MUST be in RFC1123-date format: [H3.3]; it MUST be in RFC1123-date format:
An example of its use is An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.1 clients and caches MUST treat other invalid date formats, RTSP/2.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
RTSP/1.1 servers SHOULD NOT send Expires dates more than one year in RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
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].
skipping to change at page 85, line 18 skipping to change at page 3, line 3545
applicable to proxies, as described in Section 3.7. The list are the applicable to proxies, as described in Section 3.7. The list are the
intersection of all feature-tags understood by the proxies. To intersection of all feature-tags understood by the proxies. To
achieve an intersection, the proxy adding the Proxy-Supported header achieve an intersection, the proxy adding the Proxy-Supported header
includes all proxy feature-tags it understands. Any proxy receiving a includes all proxy feature-tags it understands. Any proxy receiving a
request with the header, checks the list and removes any feature tag request with the header, checks the list and removes any feature tag
it do not support. A Proxy-Supported header present in the response it do not support. A Proxy-Supported header present in the response
SHALL NOT be touched by the proxies. SHALL NOT be touched by the proxies.
Example: Example:
C->P1: OPTIONS rtsp://example.com/ RTSP/1.1 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
P1->P2: OPTIONS rtsp://example.com/ RTSP/1.1 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 1.1 prox1.example.com Via: 2.0 prox1.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/1.1 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Via: 1.1 prox1.example.com, 1.1 prox2.example.com Via: 2.0 prox1.example.com, 2.0 prox2.example.com
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
Supported: foo, bar, baz Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 1.1 prox1.example.com, 1.1 prox2.example.com Via: 2.0 prox1.example.com, 2.0 prox2.example.com
14.33 Public 14.33 Public
The Public response header field lists the set of methods supported The Public response header field lists the set of methods supported
by the response sender. This header applies to the general by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or may sender's capabilities to the recipient. The methods listed may or may
not be applicable to the Request-URI; the Allow header field (section not be applicable to the Request-URI; the Allow header field (section
14.7) MAY be used to indicate methods allowed for a particular URI. 14.7) MAY be used to indicate methods allowed for a particular URI.
skipping to change at page 88, line 39 skipping to change at page 3, line 3701
by both sides, and only slow down if features are not by both sides, and only slow down if features are not
understood (as in the example below). For a well-matched understood (as in the example below). For a well-matched
client-server pair, the interaction proceeds quickly, client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation saving a round-trip often required by negotiation
mechanisms. In addition, it also removes state ambiguity mechanisms. In addition, it also removes state ambiguity
when the client requires features that the server does not when the client requires features that the server does not
understand. understand.
Example: Example:
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.1 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Require: funky-feature Require: funky-feature
Funky-Parameter: funkystuff Funky-Parameter: funkystuff
S->C: RTSP/1.1 551 Option not supported S->C: RTSP/2.0 551 Option not supported
CSeq: 302 CSeq: 302
Unsupported: funky-feature Unsupported: funky-feature
In this example, "funky-feature" is the feature-tag which indicates In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required. to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
skipping to change at page 94, line 43 skipping to change at page 3, line 3982
extensions supported by the message sending entity. The Supported extensions supported by the message sending entity. The Supported
header MAY be included in any request. When present in a request, header MAY be included in any request. When present in a request,
the receiver MUST respond with its corresponding Supported header. the receiver MUST respond with its corresponding Supported header.
Note, also in 4xx and 5xx responses is the supported header included. Note, also in 4xx and 5xx responses is the supported header included.
The Supported header field contains a list of feature-tags, described The Supported header field contains a list of feature-tags, described
in Section 3.7, that are understood by the client or server. in Section 3.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/1.1 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
14.44 Timestamp 14.44 Timestamp
The Timestamp general-header field describes when the agent sent the The Timestamp general-header field describes when the agent sent the
request. The value of the timestamp is of significance only to the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this, exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp is used by elapsed since it has received the request. The timestamp is used by
the agent to compute the round-trip time to the responding agent so the agent to compute the round-trip time to the responding agent so
that it can adjust the timeout value for retransmissions. It also that it can adjust the timeout value for retransmissions. It also
resolves retransmission ambiguities for unreliable transport of RTSP. resolves retransmission ambiguities for unreliable transport of RTSP.
skipping to change at page 99, line 28 skipping to change at page 3, line 4203
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.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.1 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY" "192.0.2.5:3457";mode="PLAY"
S->C: RTSP/1.1 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
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256" "192.0.2.5:3457";src_addr="192.0.2.224:6256"
/"192.0.2.224:6257";mode="PLAY" /"192.0.2.224:6257";mode="PLAY"
14.46 Unsupported 14.46 Unsupported
The Unsupported response-header field lists the features not The Unsupported response-header field lists the features not
skipping to change at page 100, line 32 skipping to change at page 3, line 4253
See [H14.47]. See [H14.47].
15 Proxies 15 Proxies
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.
o This type of proxy is used to reduce the workload on servers Caching Proxy: This type of proxy is used to reduce the workload
and connections. By caching a presentation, both description on servers and connections. By caching a presentation, both
and media streams the proxy can serve a client content without description and media streams the proxy can serve a client
requesting it from the server once it has been cached and content without requesting it from the server once it has
hasn't become stale. See the caching section 16. been cached and hasn't become stale. See the caching
section 16.
o This type of proxy is used to ensure that a RTSP client get Access Proxy: This type of proxy is used to ensure that a RTSP
access to servers on an external network. Thus this proxy is client get access to servers on an external network. Thus
placed on the border between two domains, e.g. a private this proxy is placed on the border between two domains,
address space and the public internet. The proxy performs the e.g. a private address space and the public internet. The
necessary translation, usually addresses, and often also media proxy performs the necessary translation, usually
stream translation or redirection. addresses, and often also media stream translation or
redirection.
o This type of proxy is used to help facilitate security Security Proxy: This type of proxy is used to help facilitate
functions around RTSP. For example when having a firewalled security functions around RTSP. For example when having a
network, the security proxy request that the necessary firewalled network, the security proxy request that the
pinholes in the firewall is opened when a client in the necessary pinholes in the firewall is opened when a client
protected network want to access media streams on the external in the protected network want to access media streams on
side. It can also provide network owners with a logging and the external side. It can also provide network owners with
audit point for RTSP sessions, e.g. for corporations that a logging and audit point for RTSP sessions, e.g. for
tracks or limits their employees access to certain type of corporations that tracks or limits their employees access
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 1.1 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.
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 1.1 [25]. The reason for these traversal procedures defined for RTSP 2.0 [25]. 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 103, line 19 skipping to change at page 3, line 4386
o=- 2890844526 2890842807 IN IP4 192.16.24.202 o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session s=RTSP Session
e=adm@example.com e=adm@example.com
a=range:npt=0-1:49:34 a=range:npt=0-1:49:34
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.1 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1 CSeq: 1
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
A->C: RTSP/1.1 200 OK A->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001" src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public Cache-Control: public
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.1
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059", Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
V->C: RTSP/1.1 200 OK V->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 23456789 Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059"; Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003" src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Cache-Control: public Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.1
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: 23456789
Range: smpte=0:10:00- Range: smpte=0:10:00-
V->C: RTSP/1.1 200 OK V->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Session: 23456789 Session: 23456789
Range: smpte=0:10:00-1:49:23 Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://video.example.com/twister/video" RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811 ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.1 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
Range: smpte=0:10:00- Range: smpte=0:10:00-
A->C: RTSP/1.1 200 OK A->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Session: 12345678 Session: 12345678
Range: smpte=0:10:00-1:49:23 Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://audio.example.com/twister/audio.en" RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181 ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.1
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
A->C: RTSP/1.1 200 OK A->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.1 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: 23456789
V->C: RTSP/1.1 200 OK V->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT Date: 23 Jan 1997 15:36:52 GMT
Even though the audio and video track are on two different servers, Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to may start at slightly different times, and may drift with respect to
each other, the client can synchronize the two using standard RTP each other, the client can synchronize the two using standard RTP
methods, in particular the time scale contained in the RTCP sender methods, in particular the time scale contained in the RTCP sender
reports. Initial synchronization is achieved through the RTP-Info and reports. Initial synchronization is achieved through the RTP-Info and
Range headers information in the PLAY response. Range headers information in the PLAY response.
skipping to change at page 106, line 5 skipping to change at page 3, line 4509
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.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/1.1 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93 o=- 2890844256 2890842807 IN IP4 172.16.2.93
skipping to change at page 106, line 31 skipping to change at page 3, line 4535
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/1.1 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001" src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/1.1 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678 Session: 12345678
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13 ssrc=A813FC13
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT Accept-Range: NPT
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.1 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30- Range: npt=0-10, npt=30-
Session: 12345678 Session: 12345678
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-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=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"; url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/1.1
CSeq: 5 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
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
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.1 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6 CSeq: 6
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=34.57-623.10 Range: npt=34.57-623.10
Session: 12345678 Session: 12345678
M->C: RTSP/1.1 200 OK
M->C: RTSP/2.0 200 OK
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.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 SHOULD 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/1.1 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/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Content-base: rtsp://foo.com/test.wav/ Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp Content-type: application/sdp
Content-length: 148 Content-length: 148
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT Expires: 23 Jan 1997 17:00:00 GMT
v=0 v=0
o=- 872653257 872653257 IN IP4 172.16.2.187 o=- 872653257 872653257 IN IP4 172.16.2.187
s=mu-law wave file s=mu-law wave file
i=audio test i=audio test
t=0 0 t=0 0
a=control: * a=control: *
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:streamid=0 a=control:streamid=0
C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.1 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY" dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971"; Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971";
src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712 mode="PLAY";ssrc=EAB98712
CSeq: 2 CSeq: 2
Session: 2034820394 Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/1.1 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: 2034820394
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT Date: 23 Jan 1997 15:35:08 GMT
Session: 2034820394 Session: 2034820394
Range: npt=0-600 Range: npt=0-600
RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" RTP-Info: url="rtsp://foo.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123 ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command, and then the switch back Note the different URI in the SETUP command, and then the switch back
to the aggregate URI in the PLAY command. This makes complete sense to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but is less when there are multiple streams with aggregate control, but is less
than intuitive in the special case where the number of streams is than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI one. However the server has declared that the aggregated control URI
in the SDP and therefore this is legal. in the SDP and therefore this is legal.
In this case, it is also required that servers accept implementations In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual that use the non-aggregated interpretation and use the individual
media URI, like this: media URI, like this:
skipping to change at page 109, line 44 skipping to change at page 3, line 4687
to the aggregate URI in the PLAY command. This makes complete sense to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but is less when there are multiple streams with aggregate control, but is less
than intuitive in the special case where the number of streams is than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI one. However the server has declared that the aggregated control URI
in the SDP and therefore this is legal. in the SDP and therefore this is legal.
In this case, it is also required that servers accept implementations In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual that use the non-aggregated interpretation and use the individual
media URI, like this: media URI, like this:
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.1 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
17.4 Live Media Presentation Using Multicast 17.4 Live Media Presentation Using Multicast
The media server M chooses the multicast address and port. Here, it The media server M chooses the multicast address and port. Here, it
is assumed that the web server only contains a pointer to the full is assumed that the web server only contains a pointer to the full
description, while the media server M maintains the full description. description, while the media server M maintains the full description.
C->W: GET /sessions.html HTTP/1.1 C->W: GET /sessions.html HTTP/2.0
Host: www.example.com Host: www.example.com
W->C: HTTP/1.1 200 OK W->C: HTTP/2.0 200 OK
Content-Type: text/html Content-Type: text/html
<html> <html>
... ...
<href "Stremed Live Music performance" <href "Stremed Live Music performance"
src="rtsp://live.example.com/concert/audio"> src="rtsp://live.example.com/concert/audio">
... ...
</html> </html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.1 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 182 Content-Length: 182
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Supported: play.basic Supported: play.basic
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202 o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session s=RTSP Session
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16 c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio a=control: rtsp://live.example.com/concert/audio
a=range:npt=0- a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.1 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast Transport: RTP/AVP;multicast
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/" Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/"
224.2.0.1:3457";ttl=16 224.2.0.1:3457";ttl=16
Session: 0456804596 Session: 0456804596
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.1 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3 CSeq: 3
Session: 0456804596 Session: 0456804596
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
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
skipping to change at page 111, line 36 skipping to change at page 3, line 4770
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 that the client is supporting this updated
specification, and also supports the playback time scaling feature of specification, and also supports the playback time scaling feature of
RTSP. The server's response contains the following feature related RTSP. The server's response contains the following feature related
information to the client; it supports the updated specification information to the client; it supports the updated specification
(play.basic), the extended functionality of time scaling of content (play.basic), the extended functionality of time scaling of content
(play.scale), and one "example.com" proprietary feature (play.scale), and one "example.com" proprietary feature
(example.com.flight). The client also learns the methods supported (example.com.flight). The client also learns the methods 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/1.1 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/1.1 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, example.com.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/1.1 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
Require: play.scale Require: play.scale
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001" src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
18 Security Framework 18 Security Framework
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 [7] and also in [H15]. the same usage guidelines as specified in [8] and also in [H15].
Servers SHOULD implement both basic and digest [7] authentication. Servers SHOULD implement both basic and digest [8] 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 [6] usage RTSP SHALL follow the same guidelines with regards to TLS [7] usage
as specified for HTTP, see [17]. 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
skipping to change at page 116, line 26 skipping to change at page 3, line 4990
The client MUST upon receiving a 470 or 407 response with The client MUST upon receiving a 470 or 407 response with
Connection-Credentials header take the decision on whether to accept Connection-Credentials header take the decision on whether to accept
the certificate or not (if it cannot do so, the user SHOULD be the certificate or not (if it cannot do so, the user SHOULD be
consulted). If the certificate is accepted, the client has to again consulted). If the certificate is accepted, the client has to again
send the RTSP request. In that request the client has to include the send the RTSP request. In that request the client has to include the
Accept-Credentials header including the hash over the DER encoded Accept-Credentials header including the hash over the DER encoded
certificate for all trusted proxies in the chain. certificate for all trusted proxies in the chain.
Example: Example:
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/1.1 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"
P->C: RTSP/1.1 470 Connection Authorization Required P->C: RTSP/2.0 470 Connection Authorization Required
CSeq: 2 CSeq: 2
Connection-Credentials: "rtsps://test.example.org"; Connection-Credentials: "rtsps://test.example.org";
MIIDNTCCAp... MIIDNTCCAp...
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/1.1 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= ...
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.
19 Syntax 19 Syntax
The RTSP syntax is described in an augmented Backus-Naur Form (BNF) The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF)
as defined in RFC 2234 [4]. It uses the basic definitions present in as defined in RFC 4234 [4]. It uses the basic definitions present in
RFC 2234. RFC 4234.
Please note that ABNF strings, e.g. "Accept", are case insensitive as
specified in section 2.3 of RFC 4234.
19.1 Base Syntax 19.1 Base Syntax
RTSP header field values can be folded onto multiple lines if the RTSP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 [8]. The SWS construct is used when linear white space is 2616 [8]. The SWS construct is used when linear white space is
skipping to change at page 119, line 14 skipping to change at page 3, line 5116
/ %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 URI-reference = RTSP-URI / relative-ref
relative-ref = < As defined in RFC 3986 [10]> relative-ref = < As defined in RFC 3986 [6]>
RTSP-URI = rtsp-uri-def / rtsps-uri-def / rtspu-uri-def RTSP-URI = rtsp-uri-def / rtsps-uri-def / rtspu-uri-def
rtsp-uri-def = "rtsp:" rtsp-uri-rest rtsp-uri-def = "rtsp:" rtsp-uri-rest
rtsps-uri-def = "rtsps:" rtsp-uri-rest rtsps-uri-def = "rtsps:" rtsp-uri-rest
rtspu-uri-def = "rtspu:" rtsp-uri-rest rtspu-uri-def = "rtspu:" rtsp-uri-rest
rtsp-uri-rest = "//" host [":" port] [abs-path-def] [frag-def] rtsp-uri-rest = "//" host [":" port] [abs-path-def] [frag-def]
abs-path-def = abs-path ["?" query] abs-path-def = abs-path ["?" query]
frag-def = "#" fragment frag-def = "#" fragment
host = <As defined by RFC 3986 [10]> host = <As defined by RFC 3986 [6]>
abs-path = <As defined by RFC 3986 [10]> abs-path = <As defined by RFC 3986 [6]>
port = *DIGIT ; Is expected to be 1*5DIGIT port = *DIGIT ; Is expected to be 1*5DIGIT
query = <As defined by RFC 3986 [10]> query = <As defined by RFC 3986 [6]>
fragment = <As defined by RFC 3986 [10]> fragment = <As defined by RFC 3986 [6]>
absolute-URI = <As defined by RFC 3986 [10]> absolute-URI = <As defined by RFC 3986 [6]>
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
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 )
skipping to change at page 120, line 26 skipping to change at page 3, line 5170
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/1.1 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 ] ; Section 4.3
Response = Status-Line ; Section 7.1 Response = Status-Line ; Section 7.1
*( general-header ; Section 5 *( general-header ; Section 5
/ response-header ; Section 7.1.2 / response-header ; Section 7.1.2
/ entity-header ) ; Section 8.1 / entity-header ) ; Section 8.1
skipping to change at page 124, line 10 skipping to change at page 3, line 5323
/ 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.28
/ 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" HCOLON Accept = Accept-name 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
skipping to change at page 129, line 10 skipping to change at page 3, line 5551
/ SEMI "mode" EQUAL mode-spec / SEMI "mode" EQUAL mode-spec
/ SEMI "dest_addr" EQUAL addr-list / SEMI "dest_addr" EQUAL addr-list
/ SEMI "src_addr" EQUAL addr-list / SEMI "src_addr" EQUAL addr-list
/ SEMI trn-param-ext / SEMI trn-param-ext
trn-param-ext = par-name EQUAL trn-par-value trn-param-ext = par-name EQUAL trn-par-value
par-name = token par-name = token
trn-par-value = *(rtsp-unreserved / DQUOTE *TEXT DQUOTE) trn-par-value = *(rtsp-unreserved / DQUOTE *TEXT DQUOTE)
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX ssrc = 8HEX
channel = 1*3DIGIT channel = 1*3DIGIT
mode-spec = mode / ( 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
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
skipping to change at page 131, line 38 skipping to change at page 3, line 5670
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
[7] authentication. In environments requiring tighter [8] 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 [6]) SHOULD be used. mechanism TLS (RFC 2246 [7]) 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
skipping to change at page 132, line 40 skipping to change at page 3, line 5720
credentials passed along to the server. However, in certain cases, credentials passed along to the server. However, in certain cases,
such as when recipient address is a multicast group, or when the such as when recipient address is a multicast group, or when the
recipient is unable to communicate with the server in an out-of-band recipient is unable to communicate with the server in an out-of-band
manner, this may not be possible. In these cases server may chose manner, this may not be possible. In these cases server may chose
another method such as a server-resident authorization list to ensure another method such as a server-resident authorization list to ensure
that the request originator has the proper credentials to request that the request originator has the proper credentials to request
stream delivery to the recipient. stream delivery to the recipient.
21 IANA Considerations 21 IANA Considerations
This section set up a number of registers for RTSP 1.1 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 [19], namely "First Come,
First Served", "Specification Required", and "Standards Action". First Served", "Specification Required", and "Standards Action".
skipping to change at page 138, line 17 skipping to change at page 3, line 5987
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" [8] for UDP: Indicates the use of the "User datagram protocol" [9] for
media transport. media transport.
TCP: Indicates the use Transmission control protocol [9] for TCP: Indicates the use Transmission control protocol [10] 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 143, line 26 skipping to change at page 3, line 6229
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. For NRM>1 the presentation URI MUST be other than any of the URI. For NRM>1 the presentation URI MUST be other than any of the
medias that are part of the session. This applies to all states. 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
or the state variables. However some methods do change other session
related parameters, for example SET_PARAMETER which will set the
parameter(s) specified in its body. Also all of these methods that
allows Session header will also update the keep-alive timer for the
session.
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
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
related parameters, for example SET_PARAMETER which will set the
parameter(s) specified in its body. Also all of these methods that
allows Session header will also update the keep-alive timer for the
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
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 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.
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
_____________________________________________________________________ _____________________________________________________________________
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,NRM>1 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
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
_____________________________________________________________________
______________________________________________________________________
PAUSE PrsURI,No range Ready Set RP to present point PAUSE PrsURI,No range Ready Set RP to present point
PAUSE PrsURI,Range>now Play Set RP & PP to given p. PAUSE PrsURI,Range>now Play Set RP & PP to given p.
PAUSE PrsURI,Range<now Ready Set RP to Range Hdr. 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
skipping to change at page 146, line 33 skipping to change at page 3, line 6370
(interleaved) binary data as defined in section 12. The usage of (interleaved) binary data as defined in section 12. The usage of
this method is indicated by include the "interleaved" parameter. this method is indicated by include the "interleaved" parameter.
When using embedded binary data the "src_addr" and "dest_addr" SHALL When using embedded binary data the "src_addr" and "dest_addr" SHALL
NOT be used. This addressing and multiplexing is used as defined with NOT be used. This addressing and multiplexing is used as defined with
use of channel numbers and the interleaved parameter. use of channel numbers and the interleaved parameter.
B.1.2 AVP/UDP B.1.2 AVP/UDP
This part describes sending of RTP [16] over lower transport layer This part describes sending of RTP [16] over lower transport layer
UDP [8] according to the profile "RTP Profile for Audio and Video UDP [9] according to the profile "RTP Profile for Audio and Video
Conferences with Minimal Control" defined in RFC 3551 [2]. This Conferences with Minimal Control" defined in RFC 3551 [2]. This
profiles requires one or two uni- or bi-directional UDP flows per profiles requires one or two uni- or bi-directional UDP flows per
media stream. The first UDP flow is for RTP and the second is for media stream. The first UDP flow is for RTP and the second is for
RTCP. Embedding of RTP data with the RTSP messages, in accordance RTCP. Embedding of RTP data with the RTSP messages, in accordance
with section 12, SHOULD NOT be performed when RTSP messages are with section 12, SHOULD NOT be performed when RTSP messages are
transported over unreliable transport protocols, like UDP [8]. transported over unreliable transport protocols, like UDP [9].
The RTP/UDP and RTCP/UDP flows can be established using the Transport The RTP/UDP and RTCP/UDP flows can be established using the Transport
header's "src_addr", and "dest_addr" parameters. header's "src_addr", and "dest_addr" parameters.
In RTSP PLAY mode, the transmission of RTP packets from client to In RTSP PLAY mode, the transmission of RTP packets from client to
server is unspecified. The behavior in regards to such RTP packets server is unspecified. The behavior in regards to such RTP packets
MAY be defined in future. MAY be defined in future.
The "src_addr" and "dest_addr" parameters are used in the following The "src_addr" and "dest_addr" parameters are used in the following
way for media playback, i.e. Mode=PLAY: way for media playback, i.e. Mode=PLAY:
skipping to change at page 149, line 9 skipping to change at page 3, line 6488
processes. If the RTP timestamp shows the same gap as the processes. If the RTP timestamp shows the same gap as the
NPT, the media agent will assume that there is a pause in NPT, the media agent will assume that there is a pause in
the presentation. If the jump in NPT is large enough, the the presentation. If the jump in NPT is large enough, the
RTP timestamp may roll over and the media agent may believe RTP timestamp may roll over and the media agent may believe
later packets to be duplicates of packets just played out. later packets to be duplicates of packets just played out.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of interval of 100 ms and an initial sequence number and timestamp of
zero. zero.
C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://xyz/fizzle/audiotrack" RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . . . . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
Immediately after the end of the play range, the client follows up Immediately after the end of the play range, the client follows up
with a request to PLAY from a new NPT. with a request to PLAY from a new NPT.
C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Session: abcdefg Session: abcdefg
Range: npt=18-20; Range: npt=18-20;
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Session: abcdefg Session: abcdefg
Range: npt=18-20 Range: npt=18-20
RTP-Info: url="rtsp://xyz/fizzle/audiotrack" RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100 ssrc=0D12F123:seq=50;rtptime=40100
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
skipping to change at page 150, line 24 skipping to change at page 3, line 6543
consists of RTP packets with sequence number 50 through 69, with consists of RTP packets with sequence number 50 through 69, with
timestamps 40,100 through 55,200. While there is a gap in the NPT, timestamps 40,100 through 55,200. While there is a gap in the NPT,
there is no gap in the sequence number space of the RTP data stream. there is no gap in the sequence number space of the RTP data stream.
The RTP timestamp gap is present in the above example due to the time The RTP timestamp gap is present in the above example due to the time
it takes to perform the second play request, in this case 12.5 ms it takes to perform the second play request, in this case 12.5 ms
(100/8000). To avoid this gap in playback due to the time it takes to (100/8000). To avoid this gap in playback due to the time it takes to
perform RTSP requests, a PLAY request with multiple ranges needs to perform RTSP requests, a PLAY request with multiple ranges needs to
be specified. That would result in the following example: be specified. That would result in the following example:
C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15;npt=18-20 Range: npt=10-15;npt=18-20
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://xyz/fizzle/audiotrack" RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
skipping to change at page 151, line 32 skipping to change at page 3, line 6593
needs to increase continuously with real time. While this is not needs to increase continuously with real time. While this is not
optimal for stored media, it is required for RTP and RTCP to function optimal for stored media, it is required for RTP and RTCP to function
as intended. Using a continuous RTP timestamp space allows the same as intended. Using a continuous RTP timestamp space allows the same
timestamp model for both stored and live media and allows better timestamp model for both stored and live media and allows better
opportunity to integrate both types of media under a single control. opportunity to integrate both types of media under a single control.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of interval of 100 ms and an initial sequence number and timestamp of
zero. zero.
C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15; Range: npt=10-15;
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://xyz/fizzle/audiotrack" RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
The client then sends a PAUSE request: The client then sends a PAUSE request:
C->S: PAUSE rtsp://xyz/fizzle RTSP/1.1 C->S: PAUSE rtsp://xyz/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Session: abdcdefg Session: abdcdefg
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Session: abcdefg Session: abcdefg
Range: npt=10.4-15 Range: npt=10.4-15
20 seconds elapse and then the client sends a PLAY request. In 20 seconds elapse and then the client sends a PLAY request. In
addition the server requires 15 ms to process the request: addition the server requires 15 ms to process the request:
C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0
CSeq: 6 CSeq: 6
Session: abcdefg Session: abcdefg
S->C: RTSP/1.1 200 OK S->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Session: abcdefg Session: abcdefg
Range: npt=10.4-15 Range: npt=10.4-15
RTP-Info: url="rtsp://xyz/fizzle/audiotrack" RTP-Info: url="rtsp://xyz/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400 ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
skipping to change at page 153, line 10 skipping to change at page 3, line 6653
First, NPT 10 through 10.3 is played, then a PAUSE is received by the First, NPT 10 through 10.3 is played, then a PAUSE is received by the
server. After 20 seconds a PLAY is received by the server which take server. After 20 seconds a PLAY is received by the server which take
15ms to process. The duration of time for which the session was 15ms to process. The duration of time for which the session was
paused is reflected in the RTP timestamp of the RTP packets sent paused is reflected in the RTP timestamp of the RTP packets sent
after this PLAY request. after this PLAY request.
A client can use the RTSP range header and RTP-Info header to map NPT A client can use the RTSP range header and RTP-Info header to map NPT
time of a presentation with the RTP timestamp. time of a presentation with the RTP timestamp.
Note: In RFC 2326 [24], this matter was not clearly defined and was Note: In RFC 2326 [24], this matter was not clearly defined and was
misunderstood commonly. However for RTSP 1.1 it is expected that this misunderstood commonly. However for RTSP 2.0 it is expected that this
will be handled correctly and not exception handling will be will be handled correctly and not exception handling will be
required. required.
B.1.8 RTSP / RTP Integration B.1.8 RTSP / RTP Integration
For certain datatypes, tight integration between the RTSP layer and For certain datatypes, tight integration between the RTSP layer and
the RTP layer will be necessary. This by no means precludes the above the RTP layer will be necessary. This by no means precludes the above
restrictions. Combined RTSP/RTP media clients should use the RTP-Info restrictions. Combined RTSP/RTP media clients should use the RTP-Info
field to determine whether incoming RTP packets were sent before or field to determine whether incoming RTP packets were sent before or
after a seek or before or after a PAUSE. after a seek or before or after a PAUSE.
skipping to change at page 155, line 49 skipping to change at page 3, line 6786
only contains a single media stream, in which case the attribute MAY only contains a single media stream, in which case the attribute MAY
only be present on the session level. only be present on the session level.
ABNF for the attribute is defined in section 19.3. ABNF for the attribute is defined in section 19.3.
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 [10]. following the rules and conventions set out in RFC 3986 [6].
Implementations SHALL look for a base URI in the following order: Implementations SHALL look for a base URI in the following order:
1. the RTSP Content-Base field; 1. the RTSP Content-Base field;
2. the RTSP Content-Location field; 2. the RTSP Content-Location field;
3. the RTSP Request-URI. 3. the RTSP Request-URI.
If this attribute contains only an asterisk (*), then the URI SHALL If this attribute contains only an asterisk (*), then the URI SHALL
be treated as if it were an empty embedded URI, and thus inherit the be treated as if it were an empty embedded URI, and thus inherit the
entire base URI. entire base URI.
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example lets assume that a container file has the consideration. For example lets assume that a container file has the
URI: "rtsp://example.com/container.mp4". Lets further assume this URI URI: "rtsp://example.com/container.mp4". Lets further assume this URI
is the base URI, and that there is a absolute media level URI: is the base URI, and that there is a absolute media level URI:
"rtsp://example.com/container.mp4/trackID=2". A relative media level "rtsp://example.com/container.mp4/trackID=2". A relative media level
URI that resolves in accordance with RFC 3986 [10] to the above given URI that resolves in accordance with RFC 3986 [6] to the above given
media URI is: "container.mp4/trackID=2". It is usually not desirable media URI is: "container.mp4/trackID=2". It is usually not desirable
to need to include in or modify the SDP stored within the container to need to include in or modify the SDP stored within the container
file with the server local name of the container file. To avoid this, file with the server local name of the container file. To avoid this,
one can modify the base URI used to include a trailing slash, e.g. one can modify the base URI used to include a trailing slash, e.g.
"rtsp://example.com/container.mp4/". In this case the relative URI "rtsp://example.com/container.mp4/". In this case the relative URI
for the media will only need to be: "trackID=2". However this will for the media will only need to be: "trackID=2". However this will
also mean that using "*" in the SDP will result in control URI also mean that using "*" in the SDP will result in control URI
including the trailing slash, i.e. including the trailing slash, i.e.
"rtsp://example.com/container.mp4/". "rtsp://example.com/container.mp4/".
C.1.2 Media Streams C.1.2 Media Streams
The "m=" field is used to enumerate the streams. It is expected that The "m=" field is used to enumerate the streams. It is expected that
all the specified streams will be rendered with appropriate all the specified streams will be rendered with appropriate
synchronization. If the session is over multicast, the port number synchronization. If the session is over multicast, the port number
indicated SHOULD be used for reception. The client MAY try to indicated SHOULD be used for reception. The client MAY try to
override the destination port, through the Transport header. The override the destination port, through the Transport header. The
servers MAY allow this, the response will indicate if allowed or not. servers MAY allow this, the response will indicate if allowed or not.
skipping to change at page 160, line 22 skipping to change at page 3, line 6990
In this scenario, the server has multiple streams that can be In this scenario, the server has multiple streams that can be
controlled as a whole. In this case, there are both a media-level controlled as a whole. In this case, there are both a media-level
"a=control:" attributes, which are used to specify the stream URIs, "a=control:" attributes, which are used to specify the stream URIs,
and a session-level "a=control:" attribute which is used as the and a session-level "a=control:" attribute which is used as the
Request-URI for aggregate control. If the media-level URI is Request-URI for aggregate control. If the media-level URI is
relative, it is resolved to absolute URIs according to Section C.1.1 relative, it is resolved to absolute URIs according to Section C.1.1
above. above.
Example: Example:
C->M: DESCRIBE rtsp://example.com/movie RTSP/1.1 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1 CSeq: 1
M->C: RTSP/1.1 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/ Content-Base: rtsp://example.com/movie/
Content-Length: 228 Content-Length: 228
v=0 v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32 o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I contain s=I contain
i=<more info> i=<more info>
skipping to change at page 163, line 4 skipping to change at page 3, line 7113
- Content-Encoding and at least the Identity method. - Content-Encoding and at least the Identity method.
- Content-Location - Content-Location
- Location - Location
- Range - Range
- RTP-Info - RTP-Info
o Handling of all Status code categories and in addition the o Handling of all Status code categories and in addition the
following specific status codes: following specific status codes:
o Media delivery using RTP/AVP over UDP. o Media delivery using RTP/AVP over UDP.
A play.basic client is RECOMMENDED to support the following: A play.basic client is RECOMMENDED to support the following:
o RTSP basic and digest authentication: The 401 response, the o RTSP basic and digest authentication: The 401 response, the
WWW-Authenticate and Authorization headers, and both Basic and WWW-Authenticate and Authorization headers, and both Basic and
Digest authentication methods as defined by [7]. Digest authentication methods as defined by [8].
o Expires header o Expires header
o From header o From header
o Secure Transport as specified by section D.3. o Secure Transport as specified by section D.3.
D.2.2 Server D.2.2 Server
To be written! To be written!
skipping to change at page 168, line 27 skipping to change at page 3, line 7375
CSeq See section 14.19 CSeq See section 14.19
Timestamp See section 14.44 Timestamp See section 14.44
F Backwards Compatibility Considerations F Backwards Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 [24]. with clients or servers being implemented according to RFC 2326 [24].
A server implementing RTSP/1.1 MUST include a RTSP-Version of A server implementing RTSP/2.0 MUST include a RTSP-Version of
RTSP/1.1 in all responses to requests containing RTSP-Version RTSP/2.0 in all responses to requests containing RTSP-Version
RTSP/1.1. If a server receives a RTSP/1.0 request, it MAY respond RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond
with a RTSP/1.0 response if it chooses to support RFC 2326. If the with a RTSP/1.0 response if it chooses to support RFC 2326. If the
server chooses not to support RFC 2326, it SHOULD respond with a 505 server chooses not to support RFC 2326, it SHOULD respond with a 505
(RTSP Version not supported) status code. A server MUST NOT respond (RTSP Version not supported) status code. A server MUST NOT respond
to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/1.1 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0
response. response.
Clients implementing RTSP/1.1 SHOULD use an OPTIONS request with a Clients implementing RTSP/2.0 SHOULD use an OPTIONS request with a
RTSP-Version of 1.1 to determine whether a server supports RTSP/1.1. RTSP-Version of 2.0 to determine whether a server supports RTSP/2.0.
If the server responds with either a RTSP-Version of 1.0 or a status If the server responds with either a RTSP-Version of 1.0 or a status
code of 505 (RTSP Version not supported), the client MAY use RTSP/1.0 code of 505 (RTSP Version not supported), the client MAY use RTSP/1.0
requests if it chooses to support RFC 2326. A client SHOULD NOT send requests if it chooses to support RFC 2326.
RTSP/1.1 requests to a server which has previously responded to a
RTSP/1.1 request with a RTSP-Version of 1.0.
F.1 Play Request in Play mode F.1 Play Request in Play mode
The behavior in the server when a Play is received in Play mode has The behavior in the server when a Play is received in Play mode has
changed (Section 11.4). In RFC 2326, the new PLAY request would be changed (Section 11.4). In RFC 2326, the new PLAY request would be
queued until the current Play completed. Any new PLAY request now queued until the current Play completed. Any new PLAY request now
take effect immediately replacing the previous request. take effect immediately replacing the previous request.
F.2 Using Persistent Connections F.2 Using Persistent Connections
Some server implementations of RFC 2326 maintain a one-to-one Some server implementations of RFC 2326 maintain a one-to-one
relationship between a connection and an RTSP session. Such relationship between a connection and an RTSP session. Such
implementations require clients to use a persistent connection to implementations require clients to use a persistent connection to
communicate with the server and when a client closes its connection, communicate with the server and when a client closes its connection,
the server may remove the RTSP session. This is worth noting if a the server may remove the RTSP session. This is worth noting if a
RTSP 1.1 client connects to a 1.0 server. RTSP 2.0 client connects to a 1.0 server.
G Open Issues G Open Issues
This section contains a list of open issues that still needs to be This section contains a list of open issues that still needs to be
resolved. However also any open issues in the bug tracker at resolved. However also any open issues in the bug tracker at
http://rtspspec.sourceforge.net should also be considered. http://rtspspec.sourceforge.net should also be considered.
1. Should the Allow header be possible to use optional in 1. The minimal implementation chapter is still under
request or responses of DESCRIBE and SETUP besides the now
specified 405 error code and OPTIONS?
2. The minimal implementation chapter is still under
refinement. All shall, must and shoulds needs to be refinement. All shall, must and shoulds needs to be
included in the minimal and relevant feature tags. included in the minimal and relevant feature tags.
Feature-tags for these needs to be defined. Further Feature-tags for these needs to be defined. Further
feature-tags needs to be discussed. feature-tags needs to be discussed.
3. The RTSP state machine is kind of not as useful as one
could desire. Should something be done about this? See
http://www1.ietf.org/mail-
archive/web/mmusic/current/msg03542.html
H Changes H Changes
Compared to RTSP 1.0 (RFC 2326), the below changes has been made when Compared to RTSP 1.0 (RFC 2326), the below changes has been made when
defining RTSP 1.1. Note that this list does not reflect minor changes defining RTSP 2.0. Note that this list does not reflect minor changes
in wording or correction of typographical errors. in wording or correction of typographical errors.
o The Transport header has been changed in the following way: o The Transport header has been changed in the following way:
- The ABNF has been changed to define that extensions are - The ABNF has been changed to define that extensions are
possible, and that unknown extension parameters are to be possible, and that unknown extension parameters are to be
ignored. ignored.
- To prevent backwards compatibility issues, any extension or - To prevent backwards compatibility issues, any extension or
new parameter requires the usage of a feature tag combined new parameter requires the usage of a feature tag combined
skipping to change at page 173, line 32 skipping to change at page 3, line 7610
has been removed from HTTP due to lack of use. Public is has been removed from HTTP due to lack of use. Public is
used quite frequently in RTSP. used quite frequently in RTSP.
- Clarified rules for populating the Public header so that it - Clarified rules for populating the Public header so that it
is an intersection of the capabilities of all the RTSP is an intersection of the capabilities of all the RTSP
agents in a chain. agents in a chain.
o The Protocol Syntax has been changed in the following way: o The Protocol Syntax has been changed in the following way:
- All BNF definitions are updated according to the rules - All BNF definitions are updated according to the rules
defined in RFC 2234 [4] and has been gathered in a separate defined in RFC 4234 [4] and has been gathered in a separate
section 19. section 19.
- The BNF for the User-Agent and Server headers has been - The BNF for the User-Agent and Server headers has been
corrected so now only the description is in the HTTP corrected so now only the description is in the HTTP
specification. specification.
- The definition in the introduction of the RTSP session has - The definition in the introduction of the RTSP session has
been changed. been changed.
- The protocol has been made fully IPv6 capable. Certain of - The protocol has been made fully IPv6 capable. Certain of
skipping to change at page 177, line 23 skipping to change at page 3, line 7792
Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas
Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal
Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov,
Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith,
Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen
Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi,
Jae-Hwan Kim and Mela Martti. Jae-Hwan Kim and Mela Martti.
L Normative References L Normative References
[1] M. Handley and V. Jacobson, "SDP: session description protocol," [1] M. Handley and V. Jacobson, "SDP: Session Description Protocol."
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327 (Proposed Standard), Apr. 1998. Updated by RFC 3266.
[2] H. Schulzrinne and S. Casner, "RTP profile for audio and video [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
conferences with minimal control," RFC 3551, Internet Engineering Conferences with Minimal Control." RFC 3551 (Standard), July 2003.
Task Force, July 2003.
[3] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. [3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
J. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999. RFC 2616 (Draft Standard), June 1999. Updated by RFC 2817.
[4] "Augmented BNF for syntax specifications: ABNF," RFC 2234, [4] D. Crocker and P. Overell, "Augmented BNF for Syntax
Internet Engineering Task Force, Nov. 1997. Specifications: ABNF." RFC 4234 (Draft Standard), Oct. 2005.
[5] S. Bradner, "Key words for use in RFCs to indicate requirement [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. Levels." RFC 2119 (Best Current Practice), Mar. 1997.
[6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, [6] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource
Internet Engineering Task Force, Jan. 1999. Identifier (URI): Generic Syntax." RFC 3986 (Standard), Jan. 2005.
[7] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. J. [7] T. Dierks and C. Allen, "The TLS Protocol Version 1.0." RFC 2246
Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and (Proposed Standard), Jan. 1999. Updated by RFC 3546.
digest access authentication," RFC 2617, Internet Engineering Task
Force, June 1999.
[8] J. B. Postel, "User datagram protocol," RFC 768, Internet [8] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,
Engineering Task Force, Aug. 1980. A. Luotonen, and L. Stewart, "HTTP Authentication: Basic and Digest
Access Authentication." RFC 2617 (Draft Standard), June 1999.
[9] J. B. Postel, "Transmission control protocol," RFC 793, Internet [9] J. Postel, "User Datagram Protocol." RFC 768 (Standard), Aug.
Engineering Task Force, Sept. 1981. 1980.
[10] R. F. T. Berners-Lee and L. Masinter, "Uniform resource [10] J. Postel, "Transmission Control Protocol." RFC 793 (Standard),
identifier (uri): Generic syntax," RFC 3986, Internet Engineering Sept. 1981. Updated by RFC 3168.
Task Force, Jan. 2005.
[11] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, [11] R. Elz, "A Compact Representation of IPv6 Addresses." RFC 1924
Internet Engineering Task Force, Apr. 1996. (Informational), Apr. 1996.
[12] R. Hinden, B. E. Carpenter, and L. Masinter, "Format for literal [12] R. Hinden, B. Carpenter, and L. Masinter, "Format for Literal
IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force, IPv6 Addresses in URL's." RFC 2732 (Proposed Standard), Dec. 1999.
Dec. 1999. Obsoleted by RFC 3986.
[13] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC [13] F. Yergeau, "UTF-8, a transformation format of ISO 10646." RFC
2279, Internet Engineering Task Force, Jan. 1998. 2279 (Draft Standard), Jan. 1998. Obsoleted by RFC 3629.
[14] NIST, "Fips pub 180-1:secure hash standard," tech. rep., [14] NIST, "Fips pub 180-1:secure hash standard," tech. rep.,
National Institute of Standards and Technology, Apr. 1995. National Institute of Standards and Technology, Apr. 1995.
[15] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 [15] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509
public key infrastructure certificate and certificate revocation list Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) profile," RFC 3280, Internet Engineering Task Force, Apr. 2002. (CRL) Profile." RFC 3280 (Proposed Standard), Apr. 2002.
[16] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: [16] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
a transport protocol for real-time applications," RFC 3550, Internet A Transport Protocol for Real-Time Applications." RFC 3550
Engineering Task Force, July 2003. (Standard), July 2003.
[17] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering [17] E. Rescorla, "HTTP Over TLS." RFC 2818 (Informational), May
Task Force, May 2000. 2000.
[18] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-
Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068 (Proposed
Internet Engineering Task Force, Jan. 1997. Standard), Jan. 1997. Obsoleted by RFC 2616.
[19] T. Narten and H. Alvestrand, "Guidelines for writing an IANA [19] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
considerations section in RFCs," RFC 2434, Internet Engineering Task Considerations Section in RFCs." RFC 2434 (Best Current Practice),
Force, Oct. 1998. Oct. 1998. Updated by RFC 3692.
[20] e. a. J. Ott, "Extended rtp profile for rtcp-based feedback [20] e. a. J. Ott, "Extended rtp profile for rtcp-based feedback
(rtp/avpf)," internet draft, Internet Engineering Task Force, Aug. (rtp/avpf)," internet draft, Internet Engineering Task Force, Aug.
2004. Work in progress. 2004. Work in progress.
[21] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, [21] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman,
"The secure real-time transport protocol (SRTP)," RFC 3711, Internet "The Secure Real-time Transport Protocol (SRTP)." RFC 3711 (Proposed
Engineering Task Force, Mar. 2004. Standard), Mar. 2004.
[22] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in [22] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in
session description protocol (SDP)," RFC 3266, Internet Engineering Session Description Protocol (SDP)." RFC 3266 (Proposed Standard),
Task Force, June 2002. June 2002.
[23] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6) [23] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
addressing architecture," RFC 3513, Internet Engineering Task Force, Addressing Architecture." RFC 3513 (Proposed Standard), Apr. 2003.
Apr. 2003.
M Informative References M Informative References
[24] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming [24] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. Protocol (RTSP)." RFC 2326 (Proposed Standard), Apr. 1998.
1998.
[25] T. Z. M. Westerlund, "How to make real-time streaming protocol [25] T. Z. M. Westerlund, "How to make real-time streaming protocol
(rtsp) traverse network address translators (nat) and interact with (rtsp) traverse network address translators (nat) and interact with
firewalls.," internet draft, Internet Engineering Task Force, Feb. firewalls.," internet draft, Internet Engineering Task Force, Feb.
2004. Work in progress. 2004. Work in progress.
[26] F. Yergeau, G. Nicol, G. C. Adams, and M. Duerst, [26] F. Yergeau, G. Nicol, G. Adams, and M. Duerst,
"Internationalization of the hypertext markup language," RFC 2070, "Internationalization of the Hypertext Markup Language." RFC 2070
Internet Engineering Task Force, Jan. 1997. (Historic), Jan. 1997. Obsoleted by RFC 2854.
[27] H. Schulzrinne, "A comprehensive multimedia control architecture [27] H. Schulzrinne, "A comprehensive multimedia control architecture
for the Internet," in Proc. International Workshop on Network and for the Internet," in Proc. International Workshop on Network and
Operating System Support for Digital Audio and Video (NOSSDAV), (St. Operating System Support for Digital Audio and Video (NOSSDAV), (St.
Louis, Missouri), May 1997. Louis, Missouri), May 1997.
[28] International Telecommunication Union, "Visual telephone systems [28] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-guaranteed and equipment for local area networks which provide a non-guaranteed
quality of service," Recommendation H.323, Telecommunication quality of service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996. Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[29] P. McMahon, "GSS-API authentication method for SOCKS version 5," [29] P. McMahon, "GSS-API Authentication Method for SOCKS Version 5."
RFC 1961, Internet Engineering Task Force, June 1996. RFC 1961 (Proposed Standard), June 1996.
[30] J. Miller, P. Resnick, and D. Singer, "Rating services and [30] J. Miller, P. Resnick, and D. Singer, "Rating services and
rating systems (and their machine readable descriptions)," rating systems (and their machine readable descriptions),"
Recommendation REC-PICS-services-961031, W3C (World Wide Web Recommendation REC-PICS-services-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996. Consortium), Boston, Massachusetts, Oct. 1996.
[31] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label [31] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label
distribution label syntax and communication protocols," distribution label syntax and communication protocols,"
Recommendation REC-PICS-labels-961031, W3C (World Wide Web Recommendation REC-PICS-labels-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996. Consortium), Boston, Massachusetts, Oct. 1996.
[32] D. L. Mills, "Network time protocol (version 3) specification, [32] D. Mills, "Network Time Protocol (Version 3) Specification,
implementation," RFC 1305, Internet Engineering Task Force, Mar. Implementation and Analysis." RFC 1305 (Draft Standard), Mar. 1992.
1992.
[33] ISO/IEC, "Information technology -- generic coding of moving [33] ISO/IEC, "Information technology -- generic coding of moving
pictures and associated audio informaiton -- part 6: extension for pictures and associated audio informaiton -- part 6: extension for
digital storage media and control," Draft International Standard ISO digital storage media and control," Draft International Standard ISO
13818-6, International Organization for Standardization ISO/IEC 13818-6, International Organization for Standardization ISO/IEC
JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995.
[34] ISO/IEC, "Data elements and interchange formats -- information [34] ISO/IEC, "Data elements and interchange formats -- information
interchange -- representation of dates and times," Published standard interchange -- representation of dates and times," Published standard
ISO 8601, International Organization for Standardization ISO/IEC, ISO 8601, International Organization for Standardization ISO/IEC,
Geneva, Switzerland, Dec. 2000. Geneva, Switzerland, Dec. 2000.
[35] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data [35] S. Josefsson, "The Base16, Base32, and Base64 Data Encodings."
encodings," RFC 3548, Internet Engineering Task Force, July 2003. RFC 3548 (Informational), July 2003.
[36] Third Generation Partnership Project (3GPP), "Transparent end- [36] Third Generation Partnership Project (3GPP), "Transparent end-
to-end packet-switched streaming service (pss); protocols and to-end packet-switched streaming service (pss); protocols and
codecs," Technical Specification 26.234, Third Generation Partnership codecs," Technical Specification 26.234, Third Generation Partnership
Project (3GPP), Dec. 2002. Project (3GPP), Dec. 2002.
[37] D. Yon, "Connection-oriented media transport in sdp," internet [37] D. Yon, "Connection-oriented media transport in sdp," internet
draft, Internet Engineering Task Force, Mar. 2003. Work in progress. draft, Internet Engineering Task Force, Mar. 2003. Work in progress.
[38] J. Lazzaro, "Framing rtp and rtcp packets over connection- [38] J. Lazzaro, "Framing rtp and rtcp packets over connection-
oriented transport," internet draft, Internet Engineering Task Force, oriented transport," internet draft, Internet Engineering Task Force,
Oct. 2003. Work in progress. Oct. 2003. Work in progress.
[39] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, [39] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne,
"Grouping of media lines in the session description protocol (SDP)," "Grouping of Media Lines in the Session Description Protocol (SDP)."
RFC 3388, Internet Engineering Task Force, Dec. 2002. RFC 3388 (Proposed Standard), Dec. 2002.
[40] "Requirements for Internet hosts - application and support," RFC [40] R. Braden, "Requirements for Internet Hosts - Application and
1123, Internet Engineering Task Force, Oct. 1989. Support." RFC 1123 (Standard), Oct. 1989. Updated by RFCs 1349,
2181.
[41] R. Braden, "T/TCP -- TCP extensions for transactions functional [41] R. Braden, "T/TCP -- TCP Extensions for Transactions Functional
specification," RFC 1644, Internet Engineering Task Force, July 1994. Specification." RFC 1644 (Experimental), July 1994.
[42] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. [42] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
Reading, Massachusetts: Addison-Wesley, 1994. Reading, Massachusetts: Addison-Wesley, 1994.
IPR Notice IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
skipping to change at line 8298 skipping to change at page 3, line 7988
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Introduction ........................................ 9
1.1 RTSP Specification Update ........................... 9
1.2 Purpose ............................................. 9
1.3 Notational Conventions .............................. 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 ...................................... 19
2.1 On-demand Playback of Stored Content ................ 20
2.2 Unicast distribution of Live Content ................ 21
2.3 On-demand Playback using Multicast .................. 21
2.4 Inviting a RTSP server into a conference ............ 22
2.5 Live Content using Multicast ........................ 23
3 Protocol Parameters ................................. 23
3.1 RTSP Version ........................................ 23
3.2 RTSP URI ............................................ 23
3.3 Session Identifiers ................................. 25
3.4 SMPTE Relative Timestamps ........................... 25
3.5 Normal Play Time .................................... 26
3.6 Absolute Time ....................................... 27
3.7 Feature-tags ........................................ 27
3.8 Entity Tags ......................................... 27
4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 28
4.2 Message Headers ..................................... 28
4.3 Message Body ........................................ 28
4.4 Message Length ...................................... 29
5 General Header Fields ............................... 29
6 Request ............................................. 30
6.1 Request Line ........................................ 30
6.2 Request Header Fields ............................... 31
7 Response ............................................ 32
7.1 Status-Line ......................................... 32
7.1.1 Status Code and Reason Phrase ....................... 33
7.1.2 Response Header Fields .............................. 34
8 Entity .............................................. 34
8.1 Entity Header Fields ................................ 34
8.2 Entity Body ......................................... 34
9 Connections ......................................... 35
9.1 Reliability and Acknowledgements .................... 35
9.2 Using Connections ................................... 38
9.3 Closing Connections ................................. 39
9.4 Timing Out Connections and RTSP Messages ............ 40
9.5 Use of IPv6 ......................................... 40
10 Capability Handling ................................. 41
11 Method Definitions .................................. 42
11.1 OPTIONS ............................................. 43
11.2 DESCRIBE ............................................ 44
11.3 SETUP ............................................... 46
11.3.1 Changing Transport Parameters ....................... 48
11.4 PLAY ................................................ 49
11.5 PAUSE ............................................... 53
11.6 TEARDOWN ............................................ 57
11.7 GET_PARAMETER ....................................... 58
11.8 SET_PARAMETER ....................................... 59
11.9 REDIRECT ............................................ 60
12 Embedded (Interleaved) Binary Data .................. 62
13 Status Code Definitions ............................. 64
13.1 Success 1xx ......................................... 64
13.1.1 100 Continue ........................................ 64
13.2 Success 2xx ......................................... 64
13.3 Redirection 3xx ..................................... 64
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 ....................................... 65
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 .............................. 66
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 ................................... 67
13.4.10 458 Parameter Is Read-Only .......................... 67
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 ............. 68
13.5 Server Error 5xx .................................... 68
13.5.1 551 Option not supported ............................ 68
14 Header Field Definitions ............................ 69
14.1 Accept .............................................. 71
14.2 Accept-Credentials .................................. 71
14.3 Accept-Encoding ..................................... 75
14.4 Accept-Language ..................................... 75
14.5 Accept-Ranges ....................................... 75
14.6 Allow ............................................... 76
14.7 Authorization ....................................... 76
14.8 Bandwidth ........................................... 76
14.9 Blocksize ........................................... 77
14.10 Cache-Control ....................................... 77
14.11 Connection .......................................... 79
14.12 Connection-Credentials .............................. 80
14.13 Content-Base ........................................ 80
14.14 Content-Encoding .................................... 80
14.15 Content-Language .................................... 80
14.16 Content-Length ...................................... 80
14.17 Content-Location .................................... 81
14.18 Content-Type ........................................ 81
14.19 CSeq ................................................ 81
14.20 Date ................................................ 81
14.21 ETag ................................................ 81
14.22 Expires ............................................. 82
14.23 From ................................................ 83
14.24 Host ................................................ 83
14.25 If-Match ............................................ 83
14.26 If-Modified-Since ................................... 83
14.27 If-None-Match ....................................... 84
14.28 Last-Modified ....................................... 84
14.29 Location ............................................ 84
14.30 Proxy-Authenticate .................................. 84
14.31 Proxy-Require ....................................... 84
14.32 Proxy-Supported ..................................... 85
14.33 Public .............................................. 85
14.34 Range ............................................... 86
14.35 Referer ............................................. 88
14.36 Retry-After ......................................... 88
14.37 Require ............................................. 88
14.38 RTP-Info ............................................ 89
14.39 Scale ............................................... 91
14.40 Speed ............................................... 92
14.41 Server .............................................. 92
14.42 Session ............................................. 93
14.43 Supported ........................................... 94
14.44 Timestamp ........................................... 95
14.45 Transport ........................................... 95
14.46 Unsupported ......................................... 100
14.47 User-Agent .......................................... 100
14.48 Vary ................................................ 100
14.49 Via ................................................. 100
14.50 WWW-Authenticate .................................... 100
15 Proxies ............................................. 100
16 Caching ............................................. 101
17 Examples ............................................ 102
17.1 Media on Demand (Unicast) ........................... 102
17.2 Streaming of a Container file ....................... 105
17.3 Single Stream Container Files ....................... 108
17.4 Live Media Presentation Using Multicast ............. 110
17.5 Capability Negotiation .............................. 111
18 Security Framework .................................. 112
18.1 RTSP and HTTP Authentication ........................ 113
18.2 RTSP over TLS ....................................... 113
18.3 Security and Proxies ................................ 113
18.3.1 Accept-Credentials .................................. 115
18.3.2 User approved TLS procedure ......................... 116
19 Syntax .............................................. 117
19.1 Base Syntax ......................................... 117
19.2 RTSP Protocol Definition ............................ 119
19.2.1 Generic Protocol elements ........................... 119
19.2.2 Message Syntax ...................................... 120
19.2.3 Header Syntax ....................................... 124
19.3 SDP extension Syntax ................................ 130
20 Security Considerations ............................. 130
20.1 Remote denial of Service Attack ..................... 132
21 IANA Considerations ................................. 133
21.1 Feature-tags ........................................ 133
21.1.1 Description ......................................... 133
21.1.2 Registering New Feature-tags with IANA .............. 134
21.1.3 Registered entries .................................. 134
21.2 RTSP Methods ........................................ 134
21.2.1 Description ......................................... 134
21.2.2 Registering New Methods with IANA ................... 134
21.2.3 Registered Entries .................................. 135
21.3 RTSP Status Codes ................................... 135
21.3.1 Description ......................................... 135
21.3.2 Registering New Status Codes with IANA .............. 135
21.3.3 Registered Entries .................................. 135
21.4 RTSP Headers ........................................ 135
21.4.1 Description ......................................... 135
21.4.2 Registering New Headers with IANA ................... 136
21.4.3 Registered entries .................................. 136
21.5 Transport Header registries ......................... 137
21.5.1 Transport Protocols ................................. 137
21.5.2 Profile ............................................. 137
21.5.3 Lower Transport ..................................... 138
21.5.4 Transport modes ..................................... 138
21.5.5 Transport Parameters ................................ 139
21.6 Cache Directive Extensions .......................... 139
21.7 Accept-Credentials policies ......................... 140
21.8 URI Schemes ......................................... 140
21.9 SDP attributes ...................................... 140
A RTSP Protocol State Machine ......................... 141
A.1 States .............................................. 142
A.2 State variables ..................................... 142
A.3 Abbreviations ....................................... 142
A.4 State Tables ........................................ 143
B Media Transport Alternatives ........................ 146
B.1 RTP ................................................. 146
B.1.1 AVP ................................................. 146
B.1.2 AVP/UDP ............................................. 146
B.1.3 AVP/TCP ............................................. 148
B.1.4 AVPF ................................................ 148
B.1.5 SAVP ................................................ 148
B.1.6 Handling NPT Jumps in the RTP Media Layer ........... 148
B.1.7 Handling RTP Timestamps after PAUSE ................. 151
B.1.8 RTSP / RTP Integration .............................. 153
B.1.9 Scaling with RTP .................................... 153
B.1.10 Maintaining NPT synchronization with RTP
timestamps ..................................................... 154
B.1.11 Continuous Audio .................................... 154
B.1.12 Multiple Sources in an RTP Session .................. 154
B.1.13 Usage of SSRCs and the RTCP BYE Message During an
RTSP Session ................................................... 154
B.2 Future Additions .................................... 155
C Use of SDP for RTSP Session Descriptions ............ 155
C.1 Definitions ......................................... 155
C.1.1 Control URI ......................................... 155
C.1.2 Media Streams ....................................... 157
C.1.3 Payload Type(s) ..................................... 157
C.1.4 Format-Specific Parameters .......................... 157
C.1.5 Range of Presentation ............................... 158
C.1.6 Time of Availability ................................ 158
C.1.7 Connection Information .............................. 159
C.1.8 Entity Tag .......................................... 159
C.2 Aggregate Control Not Available ..................... 159
C.3 Aggregate Control Available ......................... 160
C.4 RTSP external SDP delivery .......................... 161
D Minimal RTSP implementation ......................... 162
D.1 Minimal Core Implementation ......................... 162
D.2 The Basic Playback Feature Support .................. 162
D.2.1 Client .............................................. 163
D.2.2 Server .............................................. 163
D.2.3 Proxy ............................................... 163
D.3 Secure Transport .................................... 164
D.4 Old Implementation Text ............................. 164
D.5 Client .............................................. 164
D.5.1 Basic Playback ...................................... 165
D.5.2 Authentication-enabled .............................. 165
D.6 Server .............................................. 165
D.6.1 Basic Playback ...................................... 166
D.6.2 Authentication-enabled .............................. 167
E Requirements for Unreliable Transport of RTSP
messages ....................................................... 167
F Backwards Compatibility Considerations .............. 168
F.1 Play Request in Play mode ........................... 169
F.2 Using Persistent Connections ........................ 169
G Open Issues ......................................... 169
H Changes ............................................. 169
H.1 Changes needing to be updated ..................... 175
I Author Addresses .................................... 175
J Contributors ........................................ 176
K Acknowledgements .................................... 177
L Normative References ................................ 177
M Informative References .............................. 179
 End of changes. 222 change blocks. 
581 lines changed or deleted 319 lines changed or added

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