draft-ietf-mmusic-rfc2326bis-12.txt   draft-ietf-mmusic-rfc2326bis-13.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-12.txt Columbia U. draft-ietf-mmusic-rfc2326bis-13.txt Columbia U.
March 6, 2006 A. Rao June 26, 2006 A. Rao
Expires: September, 2006 Cisco Expires: December, 2006 Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
A. Narasimhan A. Narasimhan
Overture Overture
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
skipping to change at page 4, line 24 skipping to change at page 4, line 24
11.2 DESCRIBE ............................................ 45 11.2 DESCRIBE ............................................ 45
11.3 SETUP ............................................... 47 11.3 SETUP ............................................... 47
11.3.1 Changing Transport Parameters ....................... 49 11.3.1 Changing Transport Parameters ....................... 49
11.4 PLAY ................................................ 50 11.4 PLAY ................................................ 50
11.5 PAUSE ............................................... 55 11.5 PAUSE ............................................... 55
11.6 TEARDOWN ............................................ 57 11.6 TEARDOWN ............................................ 57
11.7 GET_PARAMETER ....................................... 58 11.7 GET_PARAMETER ....................................... 58
11.8 SET_PARAMETER ....................................... 59 11.8 SET_PARAMETER ....................................... 59
11.9 REDIRECT ............................................ 60 11.9 REDIRECT ............................................ 60
12 Embedded (Interleaved) Binary Data .................. 63 12 Embedded (Interleaved) Binary Data .................. 63
13 Status Code Definitions ............................. 64 13 Status Code Definitions ............................. 65
13.1 Success 1xx ......................................... 64 13.1 Success 1xx ......................................... 65
13.1.1 100 Continue ........................................ 65 13.1.1 100 Continue ........................................ 65
13.2 Success 2xx ......................................... 65 13.2 Success 2xx ......................................... 65
13.3 Redirection 3xx ..................................... 65 13.3 Redirection 3xx ..................................... 65
13.3.1 300 Multiple Choices ................................ 65 13.3.1 300 Multiple Choices ................................ 66
13.3.2 301 Moved Permanently ............................... 65 13.3.2 301 Moved Permanently ............................... 66
13.3.3 302 Found ........................................... 65 13.3.3 302 Found ........................................... 66
13.3.4 303 See Other ....................................... 66 13.3.4 303 See Other ....................................... 66
13.3.5 304 Not Modified .................................... 66 13.3.5 304 Not Modified .................................... 66
13.3.6 305 Use Proxy ....................................... 66 13.3.6 305 Use Proxy ....................................... 67
13.4 Client Error 4xx .................................... 66 13.4 Client Error 4xx .................................... 67
13.4.1 400 Bad Request ..................................... 66 13.4.1 400 Bad Request ..................................... 67
13.4.2 405 Method Not Allowed .............................. 67 13.4.2 405 Method Not Allowed .............................. 67
13.4.3 451 Parameter Not Understood ........................ 67 13.4.3 451 Parameter Not Understood ........................ 67
13.4.4 452 reserved ........................................ 67 13.4.4 452 reserved ........................................ 67
13.4.5 453 Not Enough Bandwidth ............................ 67 13.4.5 453 Not Enough Bandwidth ............................ 67
13.4.6 454 Session Not Found ............................... 67 13.4.6 454 Session Not Found ............................... 68
13.4.7 455 Method Not Valid in This State .................. 67 13.4.7 455 Method Not Valid in This State .................. 68
13.4.8 456 Header Field Not Valid for Resource ............. 67 13.4.8 456 Header Field Not Valid for Resource ............. 68
13.4.9 457 Invalid Range ................................... 68 13.4.9 457 Invalid Range ................................... 68
13.4.10 458 Parameter Is Read-Only .......................... 68 13.4.10 458 Parameter Is Read-Only .......................... 68
13.4.11 459 Aggregate Operation Not Allowed ................. 68 13.4.11 459 Aggregate Operation Not Allowed ................. 68
13.4.12 460 Only Aggregate Operation Allowed ................ 68 13.4.12 460 Only Aggregate Operation Allowed ................ 68
13.4.13 461 Unsupported Transport ........................... 68 13.4.13 461 Unsupported Transport ........................... 68
13.4.14 462 Destination Unreachable ......................... 68 13.4.14 462 Destination Unreachable ......................... 69
13.4.15 463 Destination Prohibited .......................... 68 13.4.15 463 Destination Prohibited .......................... 69
13.4.16 470 Connection Authorization Required ............... 68 13.4.16 470 Connection Authorization Required ............... 69
13.4.17 471 Connection Credentials not accepted ............. 69 13.4.17 471 Connection Credentials not accepted ............. 69
13.5 Server Error 5xx .................................... 69 13.5 Server Error 5xx .................................... 69
13.5.1 551 Option not supported ............................ 69 13.5.1 551 Option not supported ............................ 69
14 Header Field Definitions ............................ 69 14 Header Field Definitions ............................ 69
14.1 Accept .............................................. 71 14.1 Accept .............................................. 73
14.2 Accept-Credentials .................................. 71 14.2 Accept-Credentials .................................. 75
14.3 Accept-Encoding ..................................... 76 14.3 Accept-Encoding ..................................... 76
14.4 Accept-Language ..................................... 76 14.4 Accept-Language ..................................... 76
14.5 Accept-Ranges ....................................... 76 14.5 Accept-Ranges ....................................... 76
14.6 Allow ............................................... 76 14.6 Allow ............................................... 77
14.7 Authorization ....................................... 77 14.7 Authorization ....................................... 77
14.8 Bandwidth ........................................... 77 14.8 Bandwidth ........................................... 77
14.9 Blocksize ........................................... 77 14.9 Blocksize ........................................... 77
14.10 Cache-Control ....................................... 77 14.10 Cache-Control ....................................... 78
14.11 Connection .......................................... 80 14.11 Connection .......................................... 80
14.12 Connection-Credentials .............................. 80 14.12 Connection-Credentials .............................. 80
14.13 Content-Base ........................................ 80 14.13 Content-Base ........................................ 81
14.14 Content-Encoding .................................... 81 14.14 Content-Encoding .................................... 81
14.15 Content-Language .................................... 81 14.15 Content-Language .................................... 81
14.16 Content-Length ...................................... 81 14.16 Content-Length ...................................... 81
14.17 Content-Location .................................... 81 14.17 Content-Location .................................... 81
14.18 Content-Type ........................................ 81 14.18 Content-Type ........................................ 81
14.19 CSeq ................................................ 81 14.19 CSeq ................................................ 81
14.20 Date ................................................ 82 14.20 Date ................................................ 82
14.21 ETag ................................................ 82 14.21 ETag ................................................ 82
14.22 Expires ............................................. 82 14.22 Expires ............................................. 83
14.23 From ................................................ 83 14.23 From ................................................ 84
14.24 If-Match ............................................ 83 14.24 If-Match ............................................ 84
14.25 If-Modified-Since ................................... 84 14.25 If-Modified-Since ................................... 84
14.26 If-None-Match ....................................... 84 14.26 If-None-Match ....................................... 84
14.27 Last-Modified ....................................... 84 14.27 Last-Modified ....................................... 85
14.28 Location ............................................ 84 14.28 Location ............................................ 85
14.29 Proxy-Authenticate .................................. 85 14.29 Proxy-Authenticate .................................. 85
14.30 Proxy-Authorization ................................. 85 14.30 Proxy-Authorization ................................. 85
14.31 Proxy-Require ....................................... 85 14.31 Proxy-Require ....................................... 85
14.32 Proxy-Supported ..................................... 85 14.32 Proxy-Supported ..................................... 85
14.33 Public .............................................. 86 14.33 Public .............................................. 86
14.34 Range ............................................... 87 14.34 Range ............................................... 87
14.35 Referer ............................................. 88 14.35 Referer ............................................. 89
14.36 Retry-After ......................................... 89 14.36 Retry-After ......................................... 89
14.37 Require ............................................. 89 14.37 Require ............................................. 89
14.38 RTP-Info ............................................ 90 14.38 RTP-Info ............................................ 90
14.39 Scale ............................................... 92 14.39 Scale ............................................... 92
14.40 Speed ............................................... 92 14.40 Speed ............................................... 93
14.41 Server .............................................. 93 14.41 Server .............................................. 93
14.42 Session ............................................. 93 14.42 Session ............................................. 93
14.43 Supported ........................................... 95 14.43 Supported ........................................... 95
14.44 Timestamp ........................................... 95 14.44 Timestamp ........................................... 96
14.45 Transport ........................................... 96 14.45 Transport ........................................... 96
14.46 Unsupported ......................................... 100 14.46 Unsupported ......................................... 102
14.47 User-Agent .......................................... 101 14.47 User-Agent .......................................... 102
14.48 Vary ................................................ 101 14.48 Vary ................................................ 102
14.49 Via ................................................. 101 14.49 Via ................................................. 102
14.50 WWW-Authenticate .................................... 101 14.50 WWW-Authenticate .................................... 103
15 Proxies ............................................. 101 15 Proxies ............................................. 103
16 Caching ............................................. 102 16 Caching ............................................. 104
17 Examples ............................................ 103 17 Examples ............................................ 105
17.1 Media on Demand (Unicast) ........................... 103 17.1 Media on Demand (Unicast) ........................... 105
17.2 Media on Demand (Unicast) ........................... 106 17.2 Media on Demand (Unicast) ........................... 108
17.3 Single Stream Container Files ....................... 109 17.3 Single Stream Container Files ....................... 111
17.4 Live Media Presentation Using Multicast ............. 111 17.4 Live Media Presentation Using Multicast ............. 112
17.5 Capability Negotiation .............................. 112 17.5 Capability Negotiation .............................. 114
18 Security Framework .................................. 113 18 Security Framework .................................. 115
18.1 RTSP and HTTP Authentication ........................ 113 18.1 RTSP and HTTP Authentication ........................ 115
18.2 RTSP over TLS ....................................... 113 18.2 RTSP over TLS ....................................... 115
18.3 Security and Proxies ................................ 114 18.3 Security and Proxies ................................ 116
18.3.1 Accept-Credentials .................................. 115 18.3.1 Accept-Credentials .................................. 117
18.3.2 User approved TLS procedure ......................... 116 18.3.2 User approved TLS procedure ......................... 118
19 Syntax .............................................. 118 19 Syntax .............................................. 120
19.1 Base Syntax ......................................... 118 19.1 Base Syntax ......................................... 120
19.2 RTSP Protocol Definition ............................ 120 19.2 RTSP Protocol Definition ............................ 122
19.2.1 Generic Protocol elements ........................... 120 19.2.1 Generic Protocol elements ........................... 122
19.2.2 Message Syntax ...................................... 122 19.2.2 Message Syntax ...................................... 124
19.2.3 Header Syntax ....................................... 126 19.2.3 Header Syntax ....................................... 128
19.3 SDP extension Syntax ................................ 132 19.3 SDP extension Syntax ................................ 134
20 Security Considerations ............................. 132 20 Security Considerations ............................. 134
20.1 Remote denial of Service Attack ..................... 134 20.1 Remote denial of Service Attack ..................... 136
21 IANA Considerations ................................. 135 21 IANA Considerations ................................. 137
21.1 Feature-tags ........................................ 136 21.1 Feature-tags ........................................ 138
21.1.1 Description ......................................... 136 21.1.1 Description ......................................... 138
21.1.2 Registering New Feature-tags with IANA .............. 136 21.1.2 Registering New Feature-tags with IANA .............. 138
21.1.3 Registered entries .................................. 136 21.1.3 Registered entries .................................. 138
21.2 RTSP Methods ........................................ 137 21.2 RTSP Methods ........................................ 139
21.2.1 Description ......................................... 137 21.2.1 Description ......................................... 139
21.2.2 Registering New Methods with IANA ................... 137 21.2.2 Registering New Methods with IANA ................... 139
21.2.3 Registered Entries .................................. 137 21.2.3 Registered Entries .................................. 139
21.3 RTSP Status Codes ................................... 137 21.3 RTSP Status Codes ................................... 139
21.3.1 Description ......................................... 137 21.3.1 Description ......................................... 139
21.3.2 Registering New Status Codes with IANA .............. 137 21.3.2 Registering New Status Codes with IANA .............. 139
21.3.3 Registered Entries .................................. 138 21.3.3 Registered Entries .................................. 140
21.4 RTSP Headers ........................................ 138 21.4 RTSP Headers ........................................ 140
21.4.1 Description ......................................... 138 21.4.1 Description ......................................... 140
21.4.2 Registering New Headers with IANA ................... 138 21.4.2 Registering New Headers with IANA ................... 140
21.4.3 Registered entries .................................. 138 21.4.3 Registered entries .................................. 140
21.5 Transport Header registries ......................... 139 21.5 Transport Header registries ......................... 141
21.5.1 Transport Protocols ................................. 139 21.5.1 Transport Protocol Specification .................... 141
21.5.2 Profile ............................................. 140 21.5.2 Transport modes ..................................... 143
21.5.3 Lower Transport ..................................... 140 21.5.3 Transport Parameters ................................ 143
21.5.4 Transport modes ..................................... 141 21.6 Cache Directive Extensions .......................... 143
21.5.5 Transport Parameters ................................ 141 21.7 Accept-Credentials .................................. 144
21.6 Cache Directive Extensions .......................... 142 21.7.1 Accept-Credentials policies ......................... 144
21.7 Accept-Credentials .................................. 142 21.7.2 Accept-Credentials hash algorithms .................. 145
21.7.1 Accept-Credentials policies ......................... 142 21.8 Range header formats ................................ 145
21.7.2 Accept-Credentials hash algorithms .................. 143 21.9 URI Schemes ......................................... 145
21.8 Range header formats ................................ 143 21.9.1 The rtsp URI Scheme ................................. 145
21.9 URI Schemes ......................................... 144 21.9.2 The rtsps URI Scheme ................................ 146
21.9.1 The rtsp URI Scheme ................................. 144 21.9.3 The rtspu URI Scheme ................................ 147
21.9.2 The rtsps URI Scheme ................................ 145 21.10 SDP attributes ...................................... 148
21.9.3 The rtspu URI Scheme ................................ 146 A RTSP Protocol State Machine ......................... 149
21.10 SDP attributes ...................................... 146 A.1 States .............................................. 149
A RTSP Protocol State Machine ......................... 147 A.2 State variables ..................................... 150
A.1 States .............................................. 148 A.3 Abbreviations ....................................... 150
A.2 State variables ..................................... 148 A.4 State Tables ........................................ 150
A.3 Abbreviations ....................................... 148 B Media Transport Alternatives ........................ 153
A.4 State Tables ........................................ 148 B.1 RTP ................................................. 154
B Media Transport Alternatives ........................ 152 B.1.1 AVP ................................................. 154
B.1 RTP ................................................. 152 B.1.2 AVP/UDP ............................................. 154
B.1.1 AVP ................................................. 152 B.1.3 AVPF/UDP ............................................ 155
B.1.2 AVP/UDP ............................................. 152 B.1.4 SAVP/UDP ............................................ 156
B.1.3 AVPF/UDP ............................................ 153 B.1.5 SAVPF/UDP ........................................... 156
B.1.4 SAVP/UDP ............................................ 154 B.2 RTP over TCP ........................................ 156
B.1.5 SAVPF/UDP ........................................... 154 B.2.1 Interleaved RTP over TCP ............................ 156
B.2 RTP over TCP ........................................ 154 B.2.2 RTP over independent TCP ............................ 156
B.2.1 Interleaved RTP over TCP ............................ 154 B.2.3 Handling NPT Jumps in the RTP Media Layer ........... 159
B.2.2 RTP over independent TCP connections ................ 155 B.2.4 Handling RTP Timestamps after PAUSE ................. 162
B.2.3 Handling NPT Jumps in the RTP Media Layer ........... 155 B.2.5 RTSP / RTP Integration .............................. 164
B.2.4 Handling RTP Timestamps after PAUSE ................. 157 B.2.6 Scaling with RTP .................................... 164
B.2.5 RTSP / RTP Integration .............................. 159
B.2.6 Scaling with RTP .................................... 160
B.2.7 Maintaining NPT synchronization with RTP B.2.7 Maintaining NPT synchronization with RTP
timestamps ..................................................... 160 timestamps ..................................................... 165
B.2.8 Continuous Audio .................................... 160 B.2.8 Continuous Audio .................................... 165
B.2.9 Multiple Sources in an RTP Session .................. 160 B.2.9 Multiple Sources in an RTP Session .................. 165
B.2.10 Usage of SSRCs and the RTCP BYE Message During an B.2.10 Usage of SSRCs and the RTCP BYE Message During an
RTSP Session ................................................... 160 RTSP Session ................................................... 165
B.3 Future Additions .................................... 161 B.3 Future Additions .................................... 166
C Use of SDP for RTSP Session Descriptions ............ 161 C Use of SDP for RTSP Session Descriptions ............ 166
C.1 Definitions ......................................... 162 C.1 Definitions ......................................... 166
C.1.1 Control URI ......................................... 162 C.1.1 Control URI ......................................... 166
C.1.2 Media Streams ....................................... 163 C.1.2 Media Streams ....................................... 168
C.1.3 Payload Type(s) ..................................... 163 C.1.3 Payload Type(s) ..................................... 168
C.1.4 Format-Specific Parameters .......................... 164 C.1.4 Format-Specific Parameters .......................... 168
C.1.5 Range of Presentation ............................... 164 C.1.5 Range of Presentation ............................... 169
C.1.6 Time of Availability ................................ 165 C.1.6 Time of Availability ................................ 169
C.1.7 Connection Information .............................. 165 C.1.7 Connection Information .............................. 170
C.1.8 Entity Tag .......................................... 165 C.1.8 Entity Tag .......................................... 170
C.2 Aggregate Control Not Available ..................... 166 C.2 Aggregate Control Not Available ..................... 171
C.3 Aggregate Control Available ......................... 166 C.3 Aggregate Control Available ......................... 171
C.4 RTSP external SDP delivery .......................... 167 C.4 RTSP external SDP delivery .......................... 172
D Minimal RTSP implementation ......................... 168 D Minimal RTSP implementation ......................... 173
D.1 Minimal Core Implementation ......................... 168 D.1 Minimal Core Implementation ......................... 173
D.2 Recommended Core Implementation ..................... 169 D.2 Recommended Core Implementation ..................... 173
D.3 The Basic Playback Feature Support .................. 169 D.3 The Basic Playback Feature Support .................. 174
D.3.1 Client .............................................. 169 D.3.1 Client .............................................. 174
D.3.2 Server .............................................. 170 D.3.2 Server .............................................. 174
D.3.3 Proxy ............................................... 170 D.3.3 Proxy ............................................... 175
D.4 Secure Transport .................................... 170 D.4 Secure Transport .................................... 175
E Requirements for Unreliable Transport of RTSP E Requirements for Unreliable Transport of RTSP
messages ....................................................... 171 messages ....................................................... 175
F Backwards Compatibility Considerations .............. 172 F Backwards Compatibility Considerations .............. 177
F.1 Play Request in Play mode ........................... 172 F.1 Play Request in Play mode ........................... 177
F.2 Using Persistent Connections ........................ 172 F.2 Using Persistent Connections ........................ 177
G Open Issues ......................................... 173 G Open Issues ......................................... 177
H Changes ............................................. 174 H Changes ............................................. 178
H.1 Changes needing to be updated ..................... 179 H.1 Changes needing to be updated ..................... 184
I Author Addresses .................................... 180 I Author Addresses .................................... 184
J Contributors ........................................ 180 J Contributors ........................................ 185
K Acknowledgements .................................... 181 K Acknowledgements .................................... 186
L Normative References ................................ 181 L Normative References ................................ 186
M Informative References .............................. 183 M Informative References .............................. 188
1 Introduction 1 Introduction
1.1 RTSP Specification Update 1.1 RTSP Specification Update
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a
proposed standard defined in RFC 2326 [27]. The goal of this version proposed standard defined in RFC 2326 [28]. 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 backwards since its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was decided the most compatibility was impossible. Thus a new version was decided the most
appropriate solution to get a more functional protocol. There are no appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix H catalogs the changes of this plans to revise RTSP 1.0. Appendix H catalogs the changes of this
version in relation to RTSP 1.0. version in relation to RTSP 1.0.
RTSP 2.0 is reduced in functionality in regards to RTSP 1.0 and aims RTSP 2.0 is reduced in functionality in regards to RTSP 1.0 and aims
at specifying the RTSP core, functionality and rules for extensions, at specifying the RTSP core, functionality and rules for extensions,
and basic interaction with the media delivery protocol RTP. and basic interaction with the media delivery protocol RTP.
skipping to change at page 9, line 49 skipping to change at page 9, line 49
This memorandum describes the use of RTSP over a reliable connection This memorandum describes the use of RTSP over a reliable connection
based transport level protocol such as TCP. RTSP may be implemented based transport level protocol such as TCP. RTSP may be implemented
over an unreliable connectionless transport protocol such as UDP. over an unreliable connectionless transport protocol such as UDP.
While nothing in RTSP precludes this, additional definition of this While nothing in RTSP precludes this, additional definition of this
problem area needs to be handled as an extension to the core problem area needs to be handled as an extension to the core
specification. specification.
The mechanisms of RTSP's operation over UDP were left out The mechanisms of RTSP's operation over UDP were left out
of this spec. because they were poorly defined in RFC 2326 of this spec. because they were poorly defined in RFC 2326
[27] and the tradeoff in size and complexity of this [28] and the tradeoff in size and complexity of this
memorandum for a small gain in a limited problem space was memorandum for a small gain in a limited problem space was
not deemed justifiable. not deemed justifiable.
The set of streams to be controlled in an RTSP session is defined by The set of streams to be controlled in an RTSP session is defined by
a presentation description. This memorandum does not define a format a presentation description. This memorandum does not define a format
for the presentation description. However appendix C defines how SDP for the presentation description. However appendix C defines how SDP
[1] is used for this purpose. The streams controlled by RTSP may use [1] is used for this purpose. The streams controlled by RTSP may use
RTP [2] for their data transport, but the operation of RTSP does not RTP [2] for their data transport, but the operation of RTSP does not
depend on the transport mechanism used to carry continuous media. depend on the transport mechanism used to carry continuous media.
RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3] RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3]
skipping to change at page 10, line 33 skipping to change at page 10, line 33
o Both an RTSP server and client can issue requests. o Both an RTSP server and client can issue requests.
o Data is usually carried out-of-band by a different protocol. o Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see Session descriptions returned in a DESCRIBE response (see
Section 11.2) and interleaving of RTP with RTSP over TCP are Section 11.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 12). exceptions to this rule (see Section 12).
o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts 8859-1, consistent with HTML internationalization efforts
[28]. [29].
o The Request-URI always contains the absolute URI. Because of o The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 [3] backward compatibility with a historical blunder, HTTP/1.1 [3]
carries only the absolute path in the request and puts the carries only the absolute path in the request and puts the
host name in a separate header field. host name in a separate header field.
This makes "virtual hosting" easier, where a single This makes "virtual hosting" easier, where a single
host with one IP address hosts several document trees. host with one IP address hosts several document trees.
The protocol supports the following operations: The protocol supports the following operations:
skipping to change at page 16, line 7 skipping to change at page 16, line 7
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 in those different media servers. Media synchronization is in those
cases performed at the transport level. cases performed at the transport level.
Separation of stream control and conference initiation: Stream Separation of stream control and conference initiation: Stream
control is divorced from inviting a media server to a control is divorced from inviting a media server to a
conference. In particular, SIP [29] or H.323 [30] may be conference. In particular, SIP [30] or H.323 [31] may be
used to invite a server to a conference. However the exact used to invite a server to a conference. However the exact
procedures are unspecified. procedures are unspecified.
Suitable for professional applications: RTSP supports frame- Suitable for professional applications: RTSP supports frame-
level accuracy through SMPTE time stamps to allow remote level accuracy through SMPTE time stamps to allow remote
digital editing. digital editing.
Presentation description neutral: The protocol does not impose a Presentation description neutral: The protocol does not impose a
particular presentation description or metafile format and particular presentation description or metafile format and
can convey the type of format to be used. However, the can convey the type of format to be used. However, the
presentation description is required to contain at least presentation description is required to contain at least
one RTSP URI. one RTSP URI.
Proxy and firewall friendly: The protocol should be readily Proxy and firewall friendly: The protocol should be readily
handled by both application and transport-layer (SOCKS handled by both application and transport-layer (SOCKS
[31]) firewalls. A firewall may need to understand the [32]) firewalls. A firewall may need to understand the
SETUP method to open a "hole" for the media stream. SETUP method to open a "hole" for the media stream.
HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so
that the existing infrastructure can be reused. This that the existing infrastructure can be reused. This
infrastructure includes PICS (Platform for Internet Content infrastructure includes PICS (Platform for Internet Content
Selection [32,33]) for associating labels with content. Selection [33,34]) for associating labels with content.
However, RTSP does not just add methods to HTTP since the However, RTSP does not just add methods to HTTP since the
controlling continuous media requires server state in most controlling continuous media requires server state in most
cases. cases.
Appropriate server control: If a client can start a stream, it Appropriate server control: If a client can start a stream, it
needs to be able to stop a stream. Servers should not start needs to be able to stop a stream. Servers should not start
streaming to clients in such a way that clients cannot stop streaming to clients in such a way that clients cannot stop
the stream. the stream.
Transport negotiation: The client can negotiate the transport Transport negotiation: The client can negotiate the transport
skipping to change at page 23, line 48 skipping to change at page 23, line 48
information that is desirable to be done on a per receiver basis, and information that is desirable to be done on a per receiver basis, and
the receivers are not know prior to the session start, the state the receivers are not know prior to the session start, the state
establishment that RTSP provides can be beneficial. In this case a establishment that RTSP provides can be beneficial. In this case a
client would establish a RTSP session to the multicast group. The client would establish a RTSP session to the multicast group. The
RTSP server will not transmit any media, instead it will simply point RTSP server will not transmit any media, instead it will simply point
to the multicast group. However the client and server will be able to to the multicast group. However the client and server will be able to
keep the session alive for as long as the receiver participates in keep the session alive for as long as the receiver participates in
the session. Thus enabling, for example server to client pushes of the session. Thus enabling, for example server to client pushes of
updates. This use cases will most likely not be able to actually updates. This use cases will most likely not be able to actually
implement without some extensions in relation to the server to client implement without some extensions in relation to the server to client
push mechanism. Here a method like ANNOUNCE (see RFC 2326 [27] might push mechanism. Here a method like ANNOUNCE (see RFC 2326 [28] might
be suitable, however it will require a RTSP extension to revive the be suitable, however it will require a RTSP extension to revive the
method. method.
3 Protocol Parameters 3 Protocol Parameters
3.1 RTSP Version 3.1 RTSP Version
HTTP Specification Section [H3.1] applies, with HTTP replaced by HTTP Specification Section [H3.1] applies, with HTTP replaced by
RTSP. This specification defines version 2.0 of RTSP. RTSP. This specification defines version 2.0 of RTSP.
skipping to change at page 26, line 42 skipping to change at page 26, line 42
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
3.5 Normal Play Time 3.5 Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [34]. The timestamp consists of with the Network Time Protocol (NTP) [35]. The timestamp consists of
a decimal fraction. The part left of the decimal may be expressed in a decimal fraction. The part left of the decimal may be expressed in
either seconds or hours, minutes, and seconds. The part right of the either seconds or hours, minutes, and seconds. The part right of the
decimal point measures fractions of a second. decimal point measures fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. The special constant now is defined as the values are not defined. The special constant now is defined as the
current instant of a live type event. It MAY only be used for live current instant of a live type event. It MAY only be used for live
type events, and SHALL NOT be used for on-demand content. type events, and SHALL NOT be used for on-demand content.
NPT is defined as in DSM-CC [35]: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC [36]: "Intuitively, NPT is the clock the
viewer associates with a program. It is often digitally displayed on viewer associates with a program. It is often digitally displayed on
a VCR. NPT advances normally when in normal play mode (scale = 1), a VCR. NPT advances normally when in normal play mode (scale = 1),
advances at a faster rate when in fast scan forward (high positive advances at a faster rate when in fast scan forward (high positive
scale ratio), decrements when in scan reverse (high negative scale scale ratio), decrements when in scan reverse (high negative scale
ratio) and is fixed in pause mode. NPT is (logically) equivalent to ratio) and is fixed in pause mode. NPT is (logically) equivalent to
SMPTE time codes." SMPTE time codes."
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax conforms to ISO 8601 [36]. The npt-sec notation The syntax conforms to ISO 8601 [37]. The npt-sec notation
is optimized for automatic generation, the ntp-hhmmss is optimized for automatic generation, the ntp-hhmmss
notation for consumption by human readers. The "now" notation for consumption by human readers. The "now"
constant allows clients to request to receive the live feed constant allows clients to request to receive the live feed
rather than the stored or time-delayed version. This is rather than the stored or time-delayed version. This is
needed since neither absolute time nor zero time are needed since neither absolute time nor zero time are
appropriate for this case. appropriate for this case.
3.6 Absolute Time 3.6 Absolute Time
Absolute time is expressed as ISO 8601 [36] timestamps, using UTC Absolute time is expressed as ISO 8601 [37] timestamps, using UTC
(GMT). Fractions of a second may be indicated. (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
3.7 Feature-tags 3.7 Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
skipping to change at page 50, line 27 skipping to change at page 50, line 27
If the transport parameters change while in PLAY state results in a If the transport parameters change while in PLAY state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However the server is RECOMMENDED to synchronization information. However the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
11.4 PLAY 11.4 PLAY
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. A client MUST NOT issue a PLAY request mechanism specified in SETUP. PLAY requests are valid when the
until any outstanding SETUP requests have been acknowledged as session is in READY or PLAY states. A PLAY request MUST include a
successful. PLAY requests are valid when the session is in READY or Session header to indicate which session the request applies to.
PLAY states. A PLAY request MUST include a Session header to indicate
which session the request applies to. For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This can procedure can reduce the
delay from start of session establishment until media play-out has
started with one round trip time. However an client needs to be aware
that using this procedure will result in the playout of the server
state established at the time of processing the PLAY, i.e. after the
processing of all the requests prior to the PLAY request in the
pipeline. This may not be the intended one due to failure of any of
the prior requests. However a client easily determine this based on
the responses from those requests. In case of failure the client can
halt the media playout using PAUSE and try to establish the intended
state again before issuing another PLAY request.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server SHALL responde with error 460 (Only Aggregate control URI. A server SHALL responde with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
media. The media in an aggregate SHALL be played in sync. If a client media. The media in an aggregate SHALL be played in sync. If a client
want individual control of the media it needs to use separate RTSP want individual control of the media it needs to use separate RTSP
sessions for each media. sessions for each media.
The PLAY request SHALL position the normal play time to the beginning The PLAY request SHALL position the normal play time to the beginning
of the range specified by the Range header and delivers stream data of the range specified by the Range header and delivers stream data
skipping to change at page 54, line 14 skipping to change at page 54, line 28
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the from the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given. value, a 457 (Invalid Range) response SHALL be given.
The possibility to replace a current PLAY request with a new one The possibility to replace a current PLAY request with a new one
replaces two RTSP 1.0 functions: replaces two RTSP 1.0 functions:
o The queued play functionality described in RFC 2326 [27] is o The queued play functionality described in RFC 2326 [28] is
removed and multiple ranges can be used to achieve a similar removed and multiple ranges can be used to achieve a similar
functionality. functionality.
o The use of PLAY for keep-alive signaling, i.e. PLAY request o The use of PLAY for keep-alive signaling, i.e. PLAY request
without a range header in PLAY state, has also been without a range header in PLAY state, has also been
deprecated. Instead a client can use, SET_PARAMETER deprecated. Instead a client can use, SET_PARAMETER
(recommended) or OPTIONS (allowed) for keep alive. (recommended) or OPTIONS (allowed) for keep alive.
An example of using PLAY request to change the behavior, if a server An example of using PLAY request to change the behavior, if a server
has received requests to play ranges 10 to 15 and then 13 to 20 (that has received requests to play ranges 10 to 15 and then 13 to 20 (that
skipping to change at page 67, line 26 skipping to change at page 67, line 45
13.4.3 451 Parameter Not Understood 13.4.3 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a entity body containing the offending sender SHOULD return a entity body containing the offending
parameter(s). parameter(s).
13.4.4 452 reserved 13.4.4 452 reserved
This error code was removed from RFC 2326 [27] and is obsolete. This error code was removed from RFC 2326 [28] and is obsolete.
13.4.5 453 Not Enough Bandwidth 13.4.5 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
13.4.6 454 Session Not Found 13.4.6 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
skipping to change at page 69, line 22 skipping to change at page 69, line 41
13.5 Server Error 5xx 13.5 Server Error 5xx
13.5.1 551 Option not supported 13.5.1 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header SHALL be returned stating the not supported. The Unsupported header SHALL be returned stating the
feature for which there is no support. feature for which there is no support.
14 Header Field Definitions 14 Header Field Definitions
The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for header fields are
present in section 19.2.3. Throughout this section, we use [HX.Y] to
refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[3]. Examples of each header field are given.
Information about header fields in relation to methods and proxy
processing is summarized in Tables 9, 10, 11, and 12.
The "where" column describes the request and response types in which
method direction object acronym Body method direction object acronym Body
_________________________________________________ _________________________________________________
DESCRIBE C -> S P,S DES r DESCRIBE C -> S P,S DES r
GET_PARAMETER C -> S, S -> C P,S GPR R,r GET_PARAMETER C -> S, S -> C P,S GPR R,r
OPTIONS C -> S P,S OPT OPTIONS C -> S P,S OPT
S -> C S -> C
PAUSE C -> S P,S PSE PAUSE C -> S P,S PSE
PLAY C -> S P,S PLY PLAY C -> S P,S PLY
REDIRECT S -> C P,S RDR REDIRECT S -> C P,S RDR
SETUP C -> S S STP SETUP C -> S S STP
SET_PARAMETER C -> S, S -> C P,S SPR R,r SET_PARAMETER C -> S, S -> C P,S SPR R,r
TEARDOWN C -> S P,S TRD TEARDOWN C -> S P,S TRD
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for header fields are
present in section 19.2.3. Throughout this section, we use [HX.Y] to
refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[3]. Examples of each header field are given.
Information about header fields in relation to methods and proxy
processing is summarized in Tables 9, 10, 11, and 12.
The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response 2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used; codes with which the header field can be used;
c: header field is copied from the request to the response. c: header field is copied from the request to the response.
skipping to change at page 71, line 31 skipping to change at page 72, line 5
ignore the header field in the response. ignore the header field in the response.
An RTSP agent SHALL ignore extension headers that are not understood. An RTSP agent SHALL ignore extension headers that are not understood.
The From and Location header fields contain an URI. If the URI The From and Location header fields contain an URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double contains a comma, or semicolon, the URI MUST be enclosed in double
quotas ("). Any URI parameters are contained within these quotas. If quotas ("). Any URI parameters are contained within these quotas. If
the URI is not enclosed in double quotas, any semicolon- delimited the URI is not enclosed in double quotas, any semicolon- delimited
parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
14.1 Accept
The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the
response.
See [H14.1] for syntax.
Example of use:
Accept: application/rtsl q=1.0, application/sdp
14.2 Accept-Credentials
The Accept-Credentials header is a request header used to indicate to
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD Header Where Proxy DES OPT SETUP PLAY PAUSE TRD
_________________________________________________________________ _________________________________________________________________
Accept R o - - - - - Accept R o - - - - -
Accept-Credentials R r o o o o o o Accept-Credentials R r o o o o o o
Accept-Encoding R r o - - - - - Accept-Encoding R r o - - - - -
Accept-Language R r o - - - - - Accept-Language R r o - - - - -
Accept-Ranges R r - - m - - - Accept-Ranges R r - - m - - -
Accept-Ranges r r - - o - - - Accept-Ranges r r - - o - - -
Accept-Ranges 456 r - - - o - - Accept-Ranges 456 r - - - o - -
Allow r am c c c - - - Allow r am c c c - - -
skipping to change at page 73, line 45 skipping to change at page 73, line 45
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.
any trusted intermediary how to handle further secured connections to 14.1 Accept
proxies or servers. See Section 18 for the usage of this header. It
SHALL NOT be included in server to client requests. The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the
response.
In a request the header SHALL contain the method (User, Proxy, or
Header Where Proxy GPR SPR RDR Header Where Proxy GPR SPR RDR
__________________________________________________ __________________________________________________
Accept-Credentials R r o o o Accept-Credentials R r o o o
Allow 405 amr m m m Allow 405 amr m m m
Authorization R o o o Authorization R o o o
Bandwidth R - o - Bandwidth R - o -
Blocksize R - o - Blocksize R - o -
Connection o o o Connection o o o
Connection-Credentials 470,407 ar o o o Connection-Credentials 470,407 ar o o o
Content-Base R o o - Content-Base R o o -
skipping to change at page 75, line 34 skipping to change at page 75, line 34
Via R amr o o o Via R amr o o o
Via c dr m m m Via c dr m m m
WWW-Authenticate 401 m m m WWW-Authenticate 401 m m m
____________________________________________ ____________________________________________
Header Where Proxy GPR SPR RDR Header Where Proxy GPR SPR RDR
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, and REDIRECT. GET_PARAMETER, SET_PARAMETER, and REDIRECT.
See [H14.1] for syntax.
Example of use:
Accept: application/rtsl q=1.0, application/sdp
14.2 Accept-Credentials
The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 18 for the usage of this header. It
SHALL NOT be included in server to client requests.
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 contains zero or more of credentials that the client accept. Each
credential SHALL consist of one URI identifying the proxy or server, credential SHALL consist of one URI identifying the proxy or server,
the hash algorithm identifier, and the hash over that entity's DER the hash algorithm identifier, and the hash over that entity's DER
encoded certificate [16] in Base64. All RTSP clients and proxies encoded certificate [16] in Base64. All RTSP clients and proxies
SHALL implement the SHA-1 [17] algorithm for computation of the hash SHALL implement the SHA-1 [17] algorithm for computation of the hash
of the DER encoded certificate. The SHA-1 algorithm is identified by of the DER encoded certificate. The SHA-1 algorithm is identified by
the token "sha-1". the token "sha-1".
skipping to change at page 80, line 32 skipping to change at page 80, line 50
14.12 Connection-Credentials 14.12 Connection-Credentials
The Connection-Credentials response header is used to carry the The Connection-Credentials response header is used to carry the
credentials of any next hop that need to be approved by the credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses. requestor. It SHALL only be used in server to client responses.
The Connection-Credentials header in an RTSP response SHALL, if The Connection-Credentials header in an RTSP response SHALL, if
included, contain the credentials information of the next hop that an included, contain the credentials information of the next hop that an
intermediary needs to securely connect to. The credential MUST intermediary needs to securely connect to. The credential MUST
include the URI of the next proxy or server and the DER encoded include the URI of the next proxy or server and the DER encoded
X.509v3 [16] certificate in base64 [37]. X.509v3 [16] certificate in base64 [38].
Example: Example:
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
14.13 Content-Base 14.13 Content-Base
The Content-Base entity-header field may be used to specify the base The Content-Base entity-header field may be used to specify the base
URI for resolving relative URIs within the entity. URI for resolving relative URIs within the entity.
skipping to change at page 97, line 5 skipping to change at page 97, line 18
required to be understood. If a parameter is required to be required to be understood. If a parameter is required to be
understood, then a feature tag MUST be defined for the functionality understood, then a feature tag MUST be defined for the functionality
and used in the Require and/or Proxy-Require headers. and used in the Require and/or Proxy-Require headers.
The Transport header field is restricted to describing a The Transport header field is restricted to describing a
single media stream. (RTSP can also control multiple single media stream. (RTSP can also control multiple
streams as a single entity.) Making it part of RTSP rather streams as a single entity.) Making it part of RTSP rather
than relying on a multitude of session description formats than relying on a multitude of session description formats
greatly simplifies designs of firewalls. greatly simplifies designs of firewalls.
The syntax for the transport specifier is The general syntax for the transport specifier is a list of slash
separated tokens:
transport/profile/lower-transport. Value1/Value2/Value3...
Which for RTP transports take the form:
RTP/profile/lower-transport.
The default value for the "lower-transport" parameters is specific to The default value for the "lower-transport" parameters is specific to
the profile. For RTP/AVP, the default is UDP. the profile. For RTP/AVP, the default is UDP.
There are two different methods for how to specify where the media There are two different methods for how to specify where the media
should be delivered: should be delivered:
o The presence of this parameter and its values indicates the o The presence of this parameter and its values indicates the
destination address or addresses (host address and port pairs destination address or addresses (host address and port pairs
for IP flows) necessary for the media transport. for IP flows) necessary for the media transport.
skipping to change at page 100, line 17 skipping to change at page 100, line 35
The ssrc parameter SHALL NOT be specified in requests. The The ssrc parameter SHALL NOT be specified in requests. The
functionality of specifying the ssrc parameter in a SETUP functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550 [18]. If the parameter is specification of RTP in RFC 3550 [18]. If the parameter is
included in the Transport header of a SETUP request, the included in the Transport header of a SETUP request, the
server MAY ignore it, and choose appropriate SSRCs for the server MAY ignore it, and choose appropriate SSRCs for the
stream. The server MAY set the ssrc parameter in the stream. The server MAY set the ssrc parameter in the
Transport header of the response. Transport header of the response.
The parameters defined below MAY only be used if the media transport
protocol if the lower-level transport is connection-oriented (such as
TCP). However, these parameters MUST NOT be used when interleaving
data over the RTSP control connection.
setup: Clients use the setup parameter on the Transport line in
a SETUP request, to indicate the roles it wishes to play in
a TCP connection. This parameter is adapted from [26]. We
discuss the use of this parameter in RTP/AVP/TCP non-
interleaved transport in Appendix B.2.2; the discussion
below is limited to syntactic issues.
Clients may specify the following values for the setup
parameter:
"active": The client will initiate an outgoing connection.
"passive": The client will accept an incoming connection.
"actpass": The client is willing to accept an incoming
connection or to initiate an outgoing connection.
If a client does not specify a setup value, the "active"
value is assumed.
In response to a client SETUP request where the setup
parameter is set to "active", a server's 2xx reply MUST
assign the setup parameter to "passive" on the Transport
header line.
In response to a client SETUP request where the setup
parameter is set to "passive", a server's 2xx reply MUST
assign the setup parameter to "active" on the Transport
header line.
In response to a client SETUP request where the setup
parameter is set to "actpass", a server's 2xx reply MUST
assign the setup parameter to "active" or "passive" on the
Transport header line.
Note that the "holdconn" value for setup is not defined for
RTSP use, and MUST NOT appear on a Transport line.
connection: Clients use the setup parameter on the Transport
line in a SETUP request, to indicate the SETUP request
prefers the reuse of an existing connection between client
and server (in which case the client sets the "connection"
parameter to "existing"), or that the client requires the
creation of a new connection between client and server (in
which cast the client sets the "connection" parameter to
"new"). Typically, clients use the "new" value for the
first SETUP request for a URL, and "existing" for
subsequent SETUP requests for a URL.
If a client SETUP request assigns the "new" value to
"connection", the server response MUST also assign the
"new" value to "connection" on the Transport line.
If a client SETUP request assigns the "existing" value to
"connection", the server response MUST assign a value of
"existing" or "new" to "connection" on the Transport line,
at its discretion.
The default value of "connection" is "existing", for all
SETUP requests (initial and subsequent).
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/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
skipping to change at page 102, line 17 skipping to change at page 103, line 51
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificates for with TLS as RTSP 2.0 allows the client to approve certificates for
connection establishment from a proxy, see Section 18.3.2. However connection establishment from a proxy, see Section 18.3.2. However
that trust model may not be suitable for all type of deployment, and that trust model may not be suitable for all type of deployment, and
instead secured sessions do by-pass of the proxies. instead secured sessions do by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the NAT or small office equipment. In these cases it is better to use the NAT
traversal procedures defined for RTSP 2.0 [38]. The reason for these traversal procedures defined for RTSP 2.0 [39]. 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 123, line 4 skipping to change at page 124, line 33
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
19.2.2 Message Syntax 19.2.2 Message Syntax
RTSP-message = Request / Response ; RTSP/2.0 messages RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line ; Section 6.1 Request = Request-Line ; Section 6.1
*( general-header ; Section 5 *( general-header ; Section 5
/ request-header ; Section 6.2 / request-header ; Section 6.2
/ entity-header ) ; Section 8.1 / entity-header ) ; Section 8.1
CRLF CRLF
[ message-body ] ; [ message-body ] ; Section 4.3
Section 4.3 Response = Status-Line ; Section Response = Status-Line ; Section 7.1
7.1 *( general-header ; Section *( general-header ; Section 5
5 / response-header ; Section / response-header ; Section 7.2
7.2 / entity-header ) ; Section / entity-header ) ; Section 8.1
8.1 CRLF
CRLF [ [ message-body ] ; Section 4.3
message-body ] ; Section 4.3
Request-Line = Method SP Request-URI SP RTSP-Version CRLF Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" ; Section 11.2 Method = "DESCRIBE" ; Section 11.2
/ "GET_PARAMETER" ; Section 11.7 / "GET_PARAMETER" ; Section 11.7
/ "OPTIONS" ; Section 11.1 / "OPTIONS" ; Section 11.1
/ "PAUSE" ; Section 11.5 / "PAUSE" ; Section 11.5
/ "PLAY" ; Section 11.4 / "PLAY" ; Section 11.4
/ "REDIRECT" ; Section 11.9 / "REDIRECT" ; Section 11.9
/ "SETUP" ; Section 11.3 / "SETUP" ; Section 11.3
/ "SET_PARAMETER" ; Section 11.8 / "SET_PARAMETER" ; Section 11.8
/ "TEARDOWN" ; Section 11.6 / "TEARDOWN" ; Section 11.6
/ extension-method / extension-method
skipping to change at page 131, line 23 skipping to change at page 133, line 9
/ SEMI "interleaved" EQUAL channel [ "-" channel ] / SEMI "interleaved" EQUAL channel [ "-" channel ]
/ SEMI "append" / SEMI "append"
/ SEMI "ttl" EQUAL ttl / SEMI "ttl" EQUAL ttl
/ SEMI "layers" EQUAL 1*DIGIT / SEMI "layers" EQUAL 1*DIGIT
/ SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) / SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)
/ SEMI "client_ssrc" EQUAL ssrc / SEMI "client_ssrc" EQUAL ssrc
/ 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
/ SEMI "setup" EQUAL contrans-setup
/ SEMI "connection" EQUAL contrans-con
contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing"
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 = ( 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
skipping to change at page 133, line 43 skipping to change at page 135, line 31
Location Headers and Spoofing: If a single server supports Location Headers and Spoofing: If a single server supports
multiple organizations that do not trust each another, then multiple organizations that do not trust each another, then
it needs to check the values of Location and Content- it needs to check the values of Location and Content-
Location header fields in responses that are generated Location header fields in responses that are generated
under control of said organizations to make sure that they under control of said organizations to make sure that they
do not attempt to invalidate resources over which they have do not attempt to invalidate resources over which they have
no authority. ([H15.4]) no authority. ([H15.4])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [3], as of this writing) and also of the previous RFC2068 (RFC 2616 [3], as of this writing) and also of the previous RFC2068
[39], future HTTP specifications may provide additional guidance on [40], future HTTP specifications may provide additional guidance on
security issues. security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service opportunity for a remote-controlled denial-of-service
attack. See Section 20.1. attack. See Section 20.1.
Session hijacking: Since there is no or little relation between Session hijacking: Since there is no or little relation between
a transport layer connection and an RTSP session, it is a transport layer connection and an RTSP session, it is
skipping to change at page 135, line 21 skipping to change at page 137, line 9
are acceptable in an increased generality are; verification of the are acceptable in an increased generality are; verification of the
client's identity, either against a database of known users using client's identity, either against a database of known users using
RTSP authentication mechanisms (preferably digest authentication or RTSP authentication mechanisms (preferably digest authentication or
stronger); a list of addresses that accept to be media destinations, stronger); a list of addresses that accept to be media destinations,
especially considering user identity; and media path based especially considering user identity; and media path based
verification. verification.
The server SHOULD NOT allow the destination field to be set unless a The server SHOULD NOT allow the destination field to be set unless a
mechanism exists in the system to authorize the request originator to mechanism exists in the system to authorize the request originator to
direct streams to the recipient. It is preferred that this direct streams to the recipient. It is preferred that this
authorization be performed by the recipient itself and the authorization be performed by the media recipient (destination)
credentials passed along to the server. However, in certain cases, itself and the credentials passed along to the server. However, in
such as when recipient address is a multicast group, or when the certain cases, such as when recipient address is a multicast group,
recipient is unable to communicate with the server in an out-of-band or when the recipient is unable to communicate with the server in an
manner, this may not be possible. In these cases server may chose out-of-band manner, this may not be possible. In these cases server
another method such as a server-resident authorization list to ensure may chose another method such as a server-resident authorization list
that the request originator has the proper credentials to request to ensure that the request originator has the proper credentials to
stream delivery to the recipient. request stream delivery to the recipient.
One solution that performs the necessary verification of acceptance
of media suitable for unicast based delivery is the ICE based NAT
traversal method described in [39]. By using random passwords and
username the probability of unintended indication as a valid media
destination is very low. If the server include in its STUN requests a
cookie (consisting of random material) that is the destination echo
back the solution is also safe against having a off-path attacker
being able to spoof the STUN checks. Leaving this solution vulnerable
only to on-path attackers that can see the STUN requests go to the
target of attack.
For delivery to multicast addresses there is need for another
solution which is not specified here.
21 IANA Considerations 21 IANA Considerations
This section set up a number of registers for RTSP 2.0 that should be This section set up a number of registers for RTSP 2.0 that should be
maintained by IANA. For each registry there is a description on what maintained by IANA. For each registry there is a description on what
it is required to contain, what specification is needed when adding a it is required to contain, what specification is needed when adding a
entry with IANA, and finally the entries that this document needs to entry with IANA, and finally the entries that this document needs to
register. See also the section 1.6 "Extending RTSP". There is also an register. See also the section 1.6 "Extending RTSP". There is also an
IANA registration of two SDP attributes. IANA registration of two SDP attributes.
skipping to change at page 139, line 5 skipping to change at page 141, line 8
o A description of the purpose of the header. o A description of the purpose of the header.
21.4.3 Registered entries 21.4.3 Registered entries
All headers specified in section 14 in RFCXXXX are to be registered. All headers specified in section 14 in RFCXXXX are to be registered.
Furthermore the following RTSP headers defined in other Furthermore the following RTSP headers defined in other
specifications are registered: specifications are registered:
o x-wap-profile defined in [40]. o x-wap-profile defined in [41].
o x-wap-profile-diff defined in [40]. o x-wap-profile-diff defined in [41].
o x-wap-profile-warning defined in [40]. o x-wap-profile-warning defined in [41].
o x-predecbufsize defined in [40]. o x-predecbufsize defined in [41].
o x-initpredecbufperiod defined in [40]. o x-initpredecbufperiod defined in [41].
o x-initpostdecbufperiod defined in [40]. o x-initpostdecbufperiod defined in [41].
o 3gpp-videopostdecbufsize defined in [40]. o 3gpp-videopostdecbufsize defined in [41].
o 3GPP-Link-Char defined in [40]. o 3GPP-Link-Char defined in [41].
o 3GPP-Adaptation defined in [40]. o 3GPP-Adaptation defined in [41].
o 3GPP-QoE-Metrics defined in [40]. o 3GPP-QoE-Metrics defined in [41].
o 3GPP-QoE-Feedback defined in [40]. o 3GPP-QoE-Feedback defined in [41].
The use of "X-" is NOT RECOMMENDED but the above headers in the The use of "X-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
21.5 Transport Header registries 21.5 Transport Header registries
The transport header contains a number of parameters which have The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these possibilities for future extensions. Therefore registries for these
needs to be defined. needs to be defined.
21.5.1 Transport Protocols 21.5.1 Transport Protocol Specification
A registry for the parameter transport-protocol SHALL be defined with A registry for the parameter transport-protocol specification SHALL
the following rules: be defined with the following rules:
o Registering require an public available standards o Registering require an public available standards
specification. specification.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF token o A value definition that are following the ABNF syntax
definition. definition.
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
used in RTSP. used in RTSP.
This specification registers 1 value: This specification registers the following values:
o Use of the RTP [18] protocol for media transport. The usage is o Use of the RTP [18] protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control" [2] over UDP. The usage is
explained in RFC XXXX, appendix B.1. explained in RFC XXXX, appendix B.1.
21.5.2 Profile o the same as RTP/AVP.
A registry for the parameter profile SHALL be defined with the
following rules:
o Registering requires public available standards specification.
o A contact person or organization with address and email.
o A value definition that are following the BNF token
definition.
o A definition of which Transport protocol(s) that this profile
is valid for.
o A describing text that explains how the registered value are
used in RTSP.
This specification registers 3 value:
o The "RTP profile for audio and video conferences with minimal
control" [2] MUST only be used when the transport
specification's transport-protocol is "RTP".
o The "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)"
[21] MUST only be used when the transport specification's
transport-protocol is "RTP"
o The "The Secure Real-time Transport Protocol (SRTP)" [22] MUST
only be used when the transport specification's transport-
protocol is "RTP".
o The "Extended Secure RTP Profile for RTCP-based Feedback o Use of the RTP [18] protocol for media transport in
(RTP/SAVPF)" [6] MUST only be used when the transport combination with the "Extended RTP Profile for RTCP-based
specification's transport-protocol is "RTP". Feedback (RTP/AVPF)" [21] over UDP. The usage is explained in
RFC XXXX, appendix B.1.
21.5.3 Lower Transport o the same as RTP/AVPF.
A registry for the parameter lower-transport SHALL be defined with o Use of the RTP [18] protocol for media transport in
the following rules: combination with the "The Secure Real-time Transport Protocol
(SRTP)" [22] over UDP. The usage is explained in RFC XXXX,
appendix B.1.
o Registering requires public available standards specification. o the same as RTP/SAVP.
o A contact person or organization with address and email. o Use of the RTP [18] protocol for media transport in
combination with the " [6] over UDP. The usage is explained in
RFC XXXX, appendix B.1.
o A value definition that are following the BNF token o the same as RTP/SAVPF.
definition.
o A text describing how the registered value are used in RTSP. o Use of the RTP [18] protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control" [2] over TCP. The usage is
explained in RFC XXXX, appendix B.2.2.
This specification registers 2 values: o Use of the RTP [18] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)" [21] over TCP. The usage is explained in
RFC XXXX, appendix B.2.2.
UDP: Indicates the use of the "User datagram protocol" [13] for o Use of the RTP [18] protocol for media transport in
media transport. combination with the "The Secure Real-time Transport Protocol
(SRTP)" [22] over TCP. The usage is explained in RFC XXXX,
appendix B.2.2.
TCP: Indicates the use Transmission control protocol [14] for o Use of the RTP [18] protocol for media transport in
media transport. combination with the " [6] over TCP. The usage is explained in
RFC XXXX, appendix B.2.2.
21.5.4 Transport modes 21.5.2 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.
o A value definition that are following the ABNF token o A value definition that are following the ABNF token
definition. definition.
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
used in RTSP. used in RTSP.
This specification registers 1 values: This specification registers 1 values:
PLAY: See RFC XXXX. PLAY: See RFC XXXX.
21.5.5 Transport Parameters 21.5.3 Transport Parameters
A registry for parameters that may be included in the Transport A registry for parameters that may be included in the Transport
header SHALL be defined with the following rules: header SHALL be defined with the following rules:
o Registering required a Open Standards document o Registering required a Open Standards document
o A value definition that are following the ABNF token o A value definition that are following the ABNF token
definition. definition.
o A describing text that explains how the registered value are o A describing text that explains how the registered value are
skipping to change at page 149, line 40 skipping to change at page 151, line 30
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 URI In the case that NRM=1 the presentation URI is equal to the media URI
or a specified presentation URI. For NRM>1 the presentation URI MUST or a specified presentation URI. For NRM>1 the presentation URI MUST
be other than any of the medias that are part of the session. This be other than any of the medias that are part of the session. This
applies to all states. 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.
The initial state of the state machine, see Table 14 can only be left
by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also
Event Prerequisite Response Event Prerequisite Response
______________________________________________________________ ______________________________________________________________
DESCRIBE Needs REDIRECT 3rr, Redirect DESCRIBE Needs REDIRECT 3rr, Redirect
DESCRIBE 200, Session description DESCRIBE 200, Session description
OPTIONS Session ID 200, Reset session timeout timer OPTIONS Session ID 200, Reset session timeout timer
OPTIONS 200 OPTIONS 200
SET_PARAMETER Valid parameter 200, change value of parameter SET_PARAMETER Valid parameter 200, change value of parameter
GET_PARAMETER Valid parameter 200, return value of parameter GET_PARAMETER Valid parameter 200, return value of parameter
Table 13: None state-machine changing events Table 13: None state-machine changing events
Action Requisite New State Response 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.
Action Requisite New State Response
_____________________________________________________________ _____________________________________________________________
SETUP Ready NRM=1, RP=0.0 SETUP Ready NRM=1, RP=0.0
SETUP Needs Redirect Init 3rr Redirect SETUP Needs Redirect Init 3rr Redirect
S -> C:REDIRECT No Session hdr Init Terminate all SES S -> C:REDIRECT No Session hdr Init Terminate all SES
Table 14: State: Init Table 14: State: Init
The initial state of the state machine, see Table 14 can only be left
by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another shows that a correct SETUP can in some cases be redirected to another
URI and/or server by a 3rr response. URI and/or server by a 3rr response.
Action Requisite New State Response Action Requisite New State Response
_____________________________________________________________________ _____________________________________________________________________
SETUP New URI Ready NRM+=1 SETUP New URI Ready NRM+=1
SETUP Setten up URI Ready Change transport param SETUP Setten up URI Ready Change transport param
TEARDOWN Prs URI, Init No session hdr, NRM=0 TEARDOWN Prs URI, Init No session hdr, NRM=0
TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0
TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1 TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1
PLAY Prs URI, No range Play Play from RP PLAY Prs URI, No range Play Play from RP
PLAY Prs URI, Range Play According to range PLAY Prs URI, Range Play According to range
PAUSE Prs URI Ready Return PP PAUSE Prs URI Ready Return PP
S -> C:REDIRECT Range hdr Ready Set RedP S -> C:REDIRECT Range hdr Ready Set RedP
skipping to change at page 151, line 16 skipping to change at page 153, line 7
number of media stream within the session. If the Request-URI is 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 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 used in the TEARDOWN request and more than one media exist in the
session, the session will remain and a session header MUST be session, the session will remain and a session header MUST be
returned in the response. If only a single media stream remains in returned in the response. If only a single media stream remains in
the session when performing a TEARDOWN with a media URI the session the session when performing a TEARDOWN with a media URI the session
is removed. The number of media streams remaining after tearing down is removed. The number of media streams remaining after tearing down
a media stream determines the new state. a media stream determines the new state.
Action Requisite New State Response Action Requisite New State Response
____________________________________________________________________ ______________________________________________________________________
PAUSE PrsURI Ready Set RP to present point PAUSE PrsURI Ready Set RP to present point
PP reached Ready RP = PP PP reached Ready RP = PP
End of media All media Play Set RP = End of media End of media All media Play Set RP = End of media
End of range Play Set RP = End of range End of range Play Set RP = End of range
PLAY Prs URI, No range Play Play from present point PLAY Prs URI, No range Play Play from present point
PLAY Prs URI, Range Play According to range PLAY Prs URI, Range Play According to range
SETUP New URI Play 455 SETUP New URI Play 455
SETUP Setuped URI Play 455 SETUP Setuped URI Play 455
SETUP Setuped URI, IFI Play Change transport param. SETUP Setuped URI, IFI Play Change transport param.
TEARDOWN Prs URI Init No session hdr TEARDOWN Prs URI Init No session hdr
skipping to change at page 155, line 5 skipping to change at page 156, line 46
The use of embedded (interleaved) binary data transported on the RTSP The use of embedded (interleaved) binary data transported on the RTSP
connection is possible as specified in Section 12. When using this connection is possible as specified in Section 12. When using this
declared combination of interleaved binary data the RTSP messages declared combination of interleaved binary data the RTSP messages
MUST be transported over TCP. TLS may or may not be used. MUST be transported over TCP. TLS may or may not be used.
One should however consider that this will result that all media One should however consider that this will result that all media
streams go through any proxy. Using independent TCP connections can streams go through any proxy. Using independent TCP connections can
avoid that issue. avoid that issue.
B.2.2 RTP over independent TCP connections B.2.2 RTP over independent TCP
This procedure uses an process similar to RFC 4145 [41] to establish In this Appendix, we describe the sending of RTP [18] over lower
one independent TCP connection per media stream in the RTSP session. transport layer TCP [14] according to the profile "RTP Profile for
Audio and Video Conferences with Minimal Control" defined in RFC 3551
[2]. This Appendix adapts the guidelines for using RTP over TCP
within SIP sessions [26] to work with RTSP.
Specification for the procedure to establish the TCP connection needs A client codes the support of RTP over independent TCP by specifying
to be written. an RTP/AVP/TCP transport option on the Transport line of a SETUP
request that does not used the interleaved parameter. This
specification MUST include the "unicast" parameter.
B.2.3 Handling NPT Jumps in the RTP Media Layer If the client wishes to use RTP with RTCP, two ports (or two
address/port pairs) are specified by the dest_addr parameter. If the
client wishes to use RTP without RTCP, one port (or one address/port
pair) is specified by the dest_addr parameter. Ordering rules of
dest_addr ports follow the rules for RTP/AVP/UDP.
If the client wishes to play the active role in initiating the TCP
connection, it MAY set the "setup" parameter on the Transport line to
be "active", or it MAY omit the setup parameter, as active is the
default. If the client signals the active role, the ports for all
dest_addr values MUST be set to 9 (the discard port).
If the client wishes to play the passive role in TCP connection
initiation, it MUST set the "setup" parameter on the Transport line
to be "passive". If the client is able to assume the active or the
passive role, it MUST set the "setup" parameter on the Transport line
to be "actpass". In either case, the dest_addr port value for RTP
MUST be set to the TCP port number on which the client is expecting
to receive the RTP stream connection, and the dest_addr port value
for RTCP MUST be set to the TCP port number on which the client is
expecting to receive the RTCP stream connection.
If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a
server decides to accept the request, the 2xx reply MUST contain a
Transport line that specifies RTP/AVP/TCP (without using the
interleaved parameter, and with using the unicast parameter). The
dest_addr parameter value MUST be echoed from the parameter value in
the client request.
In addition, the server reply MUST set the setup parameter on the
Transport line, to indicate the role the server will play in the
connection setup. Permissible values are "active" (if a client set
"setup" to "passive" or "actpass") and "passive" (if a client set
"setup" to "active" or "actpass").
If a server sets "setup" to "passive", the "src_addr" in the reply
MUST indicate the ports the server is willing to receive an RTP
connection and (if the client requested an RTCP connection by
specifying two dest_addr ports or address/port pairs) and RTCP
connection. If a server sets "setup" to "passive", the ports
specified in "src_addr" MUST be set to 9. The server MAY use the
"ssrc" parameter, following the guidance in 14.45. Port ordering for
src_addr follows the rules for RTP/AVP/UDP.
After sending (receiving) the first 2xx reply for a SETUP method for
a non-interleaved RTP/AVP/TCP URL, the active party SHOULD take steps
to initiate the TCP connection as soon as possible, rather than wait
for a PLAY request for the URI (or its container file URI) to arrive
(be sent).
Once the PLAY request occurs for a non-interleaved RTP/AVP/TCP URI
(or its container file), media begins to flow from server to client
over the RTP TCP connection, and RTCP packets flow bidirectionally
over the RTCP TCP connection. As in the RTP/UDP case, client-server
traffic on the UDP port is unspecified by this memo. The packets that
travel on these connections are framed using the protocol defined in
[26], not by the framing defined for interleaving RTP over the RTSP
control connection defined in Section 12.
A successful PAUSE request for a non-interleaved RTP/AVP/TCP URL
pauses the flow of packets over the connections, without closing the
connections. A successful TEARDOWN request signals that the TCP
connections for RTP and RTCP are to be closed as soon as possible.
Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be
ambiguous in the following way: does the client wish to open up new
TCP RTP and RTCP connections for the URI, or does the client wish to
continue using the existing TCP RTP and RTCP connections? The client
SHOULD use the "connection" parameter (defined in 14.45) on the
Transport line to make its intention clear in the regard (by setting
"connection" to "new" if new connections are needed, and by setting
"connection" to "existing" if the existing connections are to be
used). After a 2xx reply for a SETUP request for a new connection,
parties should close the pre-existing connections, after waiting a
suitable period for any stray RTP or RTCP packets to arrive.
Below, we rewrite part of the example media on demand example shown
in 17.1 to use RTP/AVP/TCP non-interleaved:
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"
setup=active;connection=new
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
setup=active;connection=new;ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
B.2.3 Handling NPT Jumps in the RTP Media Layer
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer[18]. Such control allows jumps to be created in NPT media layer[18]. Such control allows jumps to be created in NPT
timeline of the RTSP session. For example, jumps in NPT can be caused timeline of the RTSP session. For example, jumps in NPT can be caused
by multiple ranges in the range specifier of a PLAY request or by multiple ranges in the range specifier of a PLAY request or
through a "seek" opertaion on an RTSP session which involves a PLAY, through a "seek" opertaion on an RTSP session which involves a PLAY,
PAUSE, PLAY scenario where a new NPT is set for the session. The PAUSE, PLAY scenario where a new NPT is set for the session. The
media layer rendering the RTP stream should not be affected by jumps media layer rendering the RTP stream should not be affected by jumps
in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be
continuous and monotonic across jumps of NPT. continuous and monotonic across jumps of NPT.
skipping to change at page 159, line 36 skipping to change at page 164, line 29
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 [27], this matter was not clearly defined and was Note: In RFC 2326 [28], this matter was not clearly defined and was
misunderstood commonly. However for RTSP 2.0 it is expected that this misunderstood commonly. However for RTSP 2.0 it is expected that this
will be handled correctly and no exception handling will be required. will be handled correctly and no exception handling will be required.
B.2.5 RTSP / RTP Integration B.2.5 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 165, line 36 skipping to change at page 170, line 26
C.1.7 Connection Information C.1.7 Connection Information
In SDP, the "c=" field contains the destination address for the media In SDP, the "c=" field contains the destination address for the media
stream. For on-demand unicast streams and some multicast streams, the stream. For on-demand unicast streams and some multicast streams, the
destination address MAY be specified by the client via the SETUP destination address MAY be specified by the client via the SETUP
request, thus overriding any specified address. To identify streams request, thus overriding any specified address. To identify streams
without a fixed destination address, where the client is required to without a fixed destination address, where the client is required to
specify a destination address, the "c=" field SHOULD be set to a null specify a destination address, the "c=" field SHOULD be set to a null
value. For addresses of type "IP4", this value SHALL be "0.0.0.0", value. For addresses of type "IP4", this value SHALL be "0.0.0.0",
and for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the and for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the
unspecified address according to RFC 3513 [26]. unspecified address according to RFC 3513 [27].
C.1.8 Entity Tag C.1.8 Entity Tag
The optional "a=etag" attribute identifies a version of the session The optional "a=etag" attribute identifies a version of the session
description. It is opaque to the client. SETUP requests may include description. It is opaque to the client. SETUP requests may include
this identifier in the If-Match field (see section 14.24) to only this identifier in the If-Match field (see section 14.24) to only
allow session establishment if this attribute value still corresponds allow session establishment if this attribute value still corresponds
to that of the current description. The attribute value is opaque to that of the current description. The attribute value is opaque
and may contain any character allowed within SDP attribute values. and may contain any character allowed within SDP attribute values.
skipping to change at page 171, line 10 skipping to change at page 175, line 48
D.4 Secure Transport D.4 Secure Transport
Any Client, Proxy or Server supporting secure transport of RTSP Any Client, Proxy or Server supporting secure transport of RTSP
messages and usage of the "rtsps" URI scheme SHALL implement; The messages and usage of the "rtsps" URI scheme SHALL implement; The
Accept-Credentials and Connection-Credentials headers; TLS over TCP. Accept-Credentials and Connection-Credentials headers; TLS over TCP.
E Requirements for Unreliable Transport of RTSP messages E Requirements for Unreliable Transport of RTSP messages
This section provides any one intending to define how to transport of This section provides any one intending to define how to transport of
RTSP messages over a unreliable transport protocol with some RTSP messages over a unreliable transport protocol with some
information learned by the attempt in RFC 2326 [27]. RFC 2326 define information learned by the attempt in RFC 2326 [28]. RFC 2326 define
both an URI scheme and some basic functionality for transport of RTSP both an URI scheme and some basic functionality for transport of RTSP
messages over UDP, however it was not sufficient for reliable usage messages over UDP, however it was not sufficient for reliable usage
and successful interoperability. and successful interoperability.
The RTSP scheme defined for unreliable transport of RTSP messages was The RTSP scheme defined for unreliable transport of RTSP messages was
"rtspu". It has been reserved by this specification as at least one "rtspu". It has been reserved by this specification as at least one
commercial implementation exist, thus avoiding any collisions in the commercial implementation exist, thus avoiding any collisions in the
name space. name space.
The following considerations should exist for operation of RTSP over The following considerations should exist for operation of RTSP over
skipping to change at page 172, line 14 skipping to change at page 177, line 4
messages comes from the same entity becomes extremely messages comes from the same entity becomes extremely
important, as session hijacking may be substantially easier important, as session hijacking may be substantially easier
for RTSP message transport using an unreliable protocol like for RTSP message transport using an unreliable protocol like
UDP than for TCP. UDP than for TCP.
There exist two RTSP headers thats primarily are intended for being There exist two RTSP headers thats primarily are intended for being
used by the unreliable handling of RTSP messages and which will be used by the unreliable handling of RTSP messages and which will be
maintained: maintained:
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 [27]. with clients or servers being implemented according to RFC 2326 [28].
Note that there exist no requirement to implement RTSP 1.0, in fact Note that there exist no requirement to implement RTSP 1.0, in fact
we recommend against it as it is difficult to do in an interoperable we recommend against it as it is difficult to do in an interoperable
way. way.
A server implementing RTSP/2.0 MUST include a RTSP-Version of A server implementing RTSP/2.0 MUST include a RTSP-Version of
RTSP/2.0 in all responses to requests containing RTSP-Version RTSP/2.0 in all responses to requests containing RTSP-Version
RTSP/2.0. 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
skipping to change at page 173, line 14 skipping to change at page 177, line 51
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 2.0 client also supporting 1.0 connects to a 1.0 server. RTSP 2.0 client also supporting 1.0 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. Procedures for establishing the TCP connections for 1. Should the SMPTE range format be updated to support the 50
RTP/AVP/TCP without interleaving in Section B.2.2 needs to
be written.
2. Should the SMPTE range format be updated to support the 50
and 60 frames per second modes? and 60 frames per second modes?
3. Should we define a recommended format for error message 2. Should we define a recommended format for error message
bodies? bodies?
4. Today there is no recommended or required format for 300 3. Today there is no recommended or required format for 300
response entities containing URI lists. Should one be response entities containing URI lists. Should one be
defined? defined?
5. Should the dest_addr parameter in the Transport header in 4. Should the dest_addr parameter in the Transport header in
responses include the destination used by the server? responses include the destination used by the server?
6. Should a IPv6 multicast scope parameter for the Transport 5. Should a IPv6 multicast scope parameter for the Transport
header be defined? This would be similar to TTL. header be defined? This would be similar to TTL.
7. Should we remove the Accept header with application/rtsl in 6. Should we remove the Accept header with application/rtsl in
Section 14.1 due to that it is not a registered media type? Section 14.1 due to that it is not a registered media type?
8. The Expires header (Section 14.22 contains the below 7. The Expires header (Section 14.22 contains the below
paragraph: paragraph:
Expires header field with a date value of some time in the Expires header field with a date value of some time in the
future on a media stream that otherwise would by default be future on a media stream that otherwise would by default be
non- cacheable indicates that the media stream is non- cacheable indicates that the media stream is
cacheable, unless indicated otherwise by a Cache-Control cacheable, unless indicated otherwise by a Cache-Control
header field (Section 14.10). header field (Section 14.10).
Is there any purpose for this in RTSP, or could we remove Is there any purpose for this in RTSP, or could we remove
this statement and instead rely on the Cache-Control this statement and instead rely on the Cache-Control
header? header?
9. Should proxies strip out the credentials for themselves 8. Should proxies strip out the credentials for themselves
when forwarding messages with Accept-Credentials? when forwarding messages with Accept-Credentials?
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 2.0. 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:
skipping to change at page 177, line 38 skipping to change at page 182, line 23
available headers. available headers.
- It has been is clarified that any message with a message - It has been is clarified that any message with a message
body is required to have a Content-Length header. This was body is required to have a Content-Length header. This was
the case in RFC 2326 but could be misinterpreted. the case in RFC 2326 but could be misinterpreted.
- To resolve functionality around ETag. The ETag and If-None- - To resolve functionality around ETag. The ETag and If-None-
Match header has been added from HTTP with necessary Match header has been added from HTTP with necessary
clarification in regards to RTSP operation. clarification in regards to RTSP operation.
- Imported the Public header from HTTP RFC 2068 [39] since it - Imported the Public header from HTTP RFC 2068 [40] since it
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
skipping to change at page 179, line 21 skipping to change at page 184, line 5
use of the Public and Allow headers. use of the Public and Allow headers.
- The RECORD and ANNOUNCE methods are removed as they are - The RECORD and ANNOUNCE methods are removed as they are
lacking implementation and not considered necessary in the lacking implementation and not considered necessary in the
core specification. Any work on these methods should be done core specification. Any work on these methods should be done
as a extension document to RTSP. as a extension document to RTSP.
- Added text clarifying the usage of SET_PARAMETER for keep- - Added text clarifying the usage of SET_PARAMETER for keep-
alive and usage without any body. alive and usage without any body.
- PLAY method is now allowed to be pipelined with the
pipelining of one or more SETUP requests following the
initial that generates the session for aggregated control.
o Wrote a new section about how to setup different media o Wrote a new section about how to setup different media
transport alternatives and their profiles, and lower layer transport alternatives and their profiles, and lower layer
protocols. This resulted that the appendix on RTP interaction protocols. This resulted that the appendix on RTP interaction
was moved there instead in the part describing RTP. The was moved there instead in the part describing RTP. The
section also includes guidelines what to think of when writing section also includes guidelines what to think of when writing
usage guidelines for new protocols and profiles. usage guidelines for new protocols and profiles.
o Setup and usage of independent TCP connections for transport
of RTP has been specified.
o Added a new section describing the available mechanisms to o Added a new section describing the available mechanisms to
determine if functionality is supported, called "Capability determine if functionality is supported, called "Capability
Handling". Renamed option-tags to feature-tags. Handling". Renamed option-tags to feature-tags.
o Added a contributors section with people who has contribute o Added a contributors section with people who has contribute
actual text to the specification. actual text to the specification.
o Added a section Use Cases that describes the major use cases o Added a section Use Cases that describes the major use cases
for RTSP. for RTSP.
skipping to change at page 180, line 22 skipping to change at page 185, line 12
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
Cisco Cisco
USA USA
electronic mail: anrao@cisco.com electronic mail: anrao@cisco.com
Robert Lanphier Robert Lanphier
RealNetworks Seattle, WA, USA
P.O. Box 91123 electronic mail: robla@robla.com
Seattle, WA 98111-9223
USA
electronic mail: robla@real.com
Magnus Westerlund Magnus Westerlund
Ericsson AB, EAB/TVA/A Ericsson AB, EAB/TVA/A
Torshamsgatan 23 Torshamsgatan 23
SE-164 80 STOCKHOLM SE-164 80 STOCKHOLM
SWEDEN SWEDEN
electronic mail: magnus.westerlund@ericsson.com electronic mail: magnus.westerlund@ericsson.com
Aravind Narasimhan Aravind Narasimhan
Overture Computing Corp., Overture Computing Corp.,
skipping to change at page 181, line 11 skipping to change at page 185, line 45
o Thomas Zheng contributed text on the usage of the Range in o Thomas Zheng contributed text on the usage of the Range in
PLAY responses. PLAY responses.
o Sean Sheedy contributed text on the timeout behavior of RTSP o Sean Sheedy contributed text on the timeout behavior of RTSP
messages and connections, and the 463 status code. messages and connections, and the 463 status code.
o Fredrik Lindholm contributed text about the RTSP security o Fredrik Lindholm contributed text about the RTSP security
framework. framework.
o John Lazzaro contributed the text for RTP over Independent
TCP.
The following people have provided detailed comments on updated The following people have provided detailed comments on updated
versions of this specification: versions of this specification:
o Stephan Wenger o Stephan Wenger
K Acknowledgements K Acknowledgements
This draft is based on the functionality of the original RTSP draft This draft is based on the functionality of the original RTSP draft
submitted in October 1996. It also borrows format and descriptions submitted in October 1996. It also borrows format and descriptions
from HTTP/1.1. from HTTP/1.1.
skipping to change at page 183, line 37 skipping to change at page 188, line 26
Engineering Task Force, Feb. 2006. Engineering Task Force, Feb. 2006.
[24] J. A. et al., "Key management extensions for session [24] J. A. et al., "Key management extensions for session
description," internet draft, Internet Engineering Task Force, June description," internet draft, Internet Engineering Task Force, June
2005. Work in progress. 2005. Work in progress.
[25] D. E. 3rd, "The protocol versus document points of view in [25] D. E. 3rd, "The protocol versus document points of view in
computer protocols," RFC 3930, Internet Engineering Task Force, Oct. computer protocols," RFC 3930, Internet Engineering Task Force, Oct.
2004. 2004.
[26] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6) [26] D. Yon and G. Camarillo, "Tcp-based media transport in the
session description protocol (sdp)," RFC 4145, Internet Engineering
Task Force, Sept. 2005.
[27] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6)
addressing architecture," RFC 3513, Internet Engineering Task Force, addressing architecture," RFC 3513, Internet Engineering Task Force,
Apr. 2003. Apr. 2003.
M Informative References M Informative References
[27] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming [28] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming
protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr.
1998. 1998.
[28] F. Yergeau, G. Nicol, G. C. Adams, and M. Duerst, [29] F. Yergeau, G. Nicol, G. C. 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. Internet Engineering Task Force, Jan. 1997.
[29] H. Schulzrinne, "A comprehensive multimedia control architecture [30] 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.
[30] International Telecommunication Union, "Visual telephone systems [31] 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.
[31] P. McMahon, "GSS-API authentication method for SOCKS version 5," [32] P. McMahon, "GSS-API authentication method for SOCKS version 5,"
RFC 1961, Internet Engineering Task Force, June 1996. RFC 1961, Internet Engineering Task Force, June 1996.
[32] J. Miller, P. Resnick, and D. Singer, "Rating services and [33] 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.
[33] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label [34] 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.
[34] D. L. Mills, "Network time protocol (version 3) specification, [35] D. L. Mills, "Network time protocol (version 3) specification,
implementation," RFC 1305, Internet Engineering Task Force, Mar. implementation," RFC 1305, Internet Engineering Task Force, Mar.
1992. 1992.
[35] ISO/IEC, "Information technology -- generic coding of moving [36] 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.
[36] ISO/IEC, "Data elements and interchange formats -- information [37] 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.
[37] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data [38] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data
encodings," RFC 3548, Internet Engineering Task Force, July 2003. encodings," RFC 3548, Internet Engineering Task Force, July 2003.
[38] M. Westerlund and T. Zeng, "How to make real-time streaming [39] M. Westerlund and T. Zeng, "How to make real-time streaming
protocol (rtsp) traverse network address translators (nat) and protocol (rtsp) traverse network address translators (nat) and
interact with firewalls.," internet draft, Internet Engineering Task interact with firewalls.," internet draft, Internet Engineering Task
Force, Feb. 2004. Work in progress. Force, Oct. 2005. Work in progress.
[39] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. [40] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T.
Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068,
Internet Engineering Task Force, Jan. 1997. Internet Engineering Task Force, Jan. 1997.
[40] Third Generation Partnership Project (3GPP), "Transparent end- [41] 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.
[41] D. Yon and G. Camarillo, "Tcp-based media transport in the
session description protocol (sdp)," RFC 4145, Internet Engineering
Task Force, Sept. 2005.
[42] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, [42] 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, Internet Engineering Task Force, Dec. 2002.
[43] R. Braden, "Requirements for Internet hosts - application and [43] R. Braden, "Requirements for Internet hosts - application and
support," RFC 1123, Internet Engineering Task Force, Oct. 1989. support," RFC 1123, Internet Engineering Task Force, Oct. 1989.
[44] R. Braden, "T/TCP -- TCP extensions for transactions functional [44] R. Braden, "T/TCP -- TCP extensions for transactions functional
specification," RFC 1644, Internet Engineering Task Force, July 1994. specification," RFC 1644, Internet Engineering Task Force, July 1994.
 End of changes. 123 change blocks. 
346 lines changed or deleted 567 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/