<
 draft-ietf-mmusic-rfc2326bis-13.txt   draft-ietf-mmusic-rfc2326bis-14.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-13.txt Columbia U. draft-ietf-mmusic-rfc2326bis-14.txt Columbia U.
June 26, 2006 A. Rao Dec 22, 2006 A. Rao
Expires: December, 2006 Cisco Expires: June, 2007 Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
A. Narasimhan A. Narasimhan
Overture Overture
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
skipping to change at page 3, line 12 skipping to change at page 3, line 12
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1 Introduction ........................................ 9 1 Introduction ........................................ 9
1.1 RTSP Specification Update ........................... 9 1.1 RTSP Specification Update ........................... 9
1.2 Purpose ............................................. 9 1.2 Purpose ............................................. 9
1.3 Notational Conventions .............................. 11 1.3 Notational Conventions .............................. 11
1.3.1 RFC Editor Consideration ............................ 11 1.3.1 RFC Editor Consideration ............................ 11
1.4 Terminology ......................................... 12 1.4 Terminology ......................................... 11
1.5 Protocol Properties ................................. 15 1.5 Protocol Properties ................................. 15
1.6 Extending RTSP ...................................... 16 1.6 Extending RTSP ...................................... 16
1.7 Overall Operation ................................... 17 1.7 Overall Operation ................................... 17
1.8 RTSP States ......................................... 18 1.8 RTSP States ......................................... 18
1.9 Relationship with Other Protocols ................... 19 1.9 Relationship with Other Protocols ................... 19
2 RTSP Use Cases ...................................... 20 2 RTSP Use Cases ...................................... 20
2.1 On-demand Playback of Stored Content ................ 20 2.1 On-demand Playback of Stored Content ................ 20
2.2 Unicast distribution of Live Content ................ 21 2.2 Unicast distribution of Live Content ................ 21
2.3 On-demand Playback using Multicast .................. 22 2.3 On-demand Playback using Multicast .................. 22
2.4 Inviting an RTSP server into a conference ........... 22 2.4 Inviting an RTSP server into a conference ........... 22
2.5 Live Content using Multicast ........................ 23 2.5 Live Content using Multicast ........................ 23
3 Protocol Parameters ................................. 24 3 Protocol Parameters ................................. 24
3.1 RTSP Version ........................................ 24 3.1 RTSP Version ........................................ 24
3.2 RTSP IRI and URI .................................... 24 3.2 RTSP IRI and URI .................................... 24
3.3 Session Identifiers ................................. 26 3.3 Session Identifiers ................................. 26
3.4 SMPTE Relative Timestamps ........................... 26 3.4 SMPTE Relative Timestamps ........................... 26
3.5 Normal Play Time .................................... 26 3.5 Normal Play Time .................................... 27
3.6 Absolute Time ....................................... 27 3.6 Absolute Time ....................................... 27
3.7 Feature-tags ........................................ 27 3.7 Feature-tags ........................................ 28
3.8 Entity Tags ......................................... 28 3.8 Entity Tags ......................................... 28
4 RTSP Message ........................................ 28 4 RTSP Message ........................................ 28
4.1 Message Types ....................................... 29 4.1 Message Types ....................................... 29
4.2 Message Headers ..................................... 29 4.2 Message Headers ..................................... 29
4.3 Message Body ........................................ 29 4.3 Message Body ........................................ 29
4.4 Message Length ...................................... 29 4.4 Message Length ...................................... 29
5 General Header Fields ............................... 29 5 General Header Fields ............................... 30
6 Request ............................................. 30 6 Request ............................................. 30
6.1 Request Line ........................................ 30 6.1 Request Line ........................................ 31
6.2 Request Header Fields ............................... 32 6.2 Request Header Fields ............................... 32
7 Response ............................................ 33 7 Response ............................................ 32
7.1 Status-Line ......................................... 33 7.1 Status-Line ......................................... 33
7.1.1 Status Code and Reason Phrase ....................... 33 7.1.1 Status Code and Reason Phrase ....................... 33
7.2 Response Header Fields .............................. 34 7.2 Response Header Fields .............................. 34
8 Entity .............................................. 34 8 Entity .............................................. 35
8.1 Entity Header Fields ................................ 35 8.1 Entity Header Fields ................................ 37
8.2 Entity Body ......................................... 35 8.2 Entity Body ......................................... 37
9 Connections ......................................... 35 9 Connections ......................................... 37
9.1 Reliability and Acknowledgements .................... 38 9.1 Reliability and Acknowledgements .................... 38
9.2 Using Connections ................................... 38 9.2 Using Connections ................................... 39
9.3 Closing Connections ................................. 39 9.3 Closing Connections ................................. 40
9.4 Timing Out Connections and RTSP Messages ............ 40 9.4 Timing Out Connections and RTSP Messages ............ 41
9.5 Use of IPv6 ......................................... 41 9.5 Use of IPv6 ......................................... 41
10 Capability Handling ................................. 41 10 Capability Handling ................................. 41
11 Method Definitions .................................. 43 11 Method Definitions .................................. 43
11.1 OPTIONS ............................................. 44 11.1 OPTIONS ............................................. 44
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 ....................... 50
11.4 PLAY ................................................ 50 11.4 PLAY ................................................ 50
11.5 PAUSE ............................................... 55 11.5 PAUSE ............................................... 56
11.6 TEARDOWN ............................................ 57 11.6 TEARDOWN ............................................ 58
11.7 GET_PARAMETER ....................................... 58 11.7 GET_PARAMETER ....................................... 59
11.8 SET_PARAMETER ....................................... 59 11.8 SET_PARAMETER ....................................... 59
11.9 REDIRECT ............................................ 60 11.9 REDIRECT ............................................ 61
12 Embedded (Interleaved) Binary Data .................. 63 12 Embedded (Interleaved) Binary Data .................. 63
13 Status Code Definitions ............................. 65 13 Status Code Definitions ............................. 65
13.1 Success 1xx ......................................... 65 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 ................................ 66 13.3.1 300 Multiple Choices ................................ 66
13.3.2 301 Moved Permanently ............................... 66 13.3.2 301 Moved Permanently ............................... 66
13.3.3 302 Found ........................................... 66 13.3.3 302 Found ........................................... 66
13.3.4 303 See Other ....................................... 66 13.3.4 303 See Other ....................................... 67
13.3.5 304 Not Modified .................................... 66 13.3.5 304 Not Modified .................................... 67
13.3.6 305 Use Proxy ....................................... 67 13.3.6 305 Use Proxy ....................................... 67
13.4 Client Error 4xx .................................... 67 13.4 Client Error 4xx .................................... 67
13.4.1 400 Bad Request ..................................... 67 13.4.1 400 Bad Request ..................................... 68
13.4.2 405 Method Not Allowed .............................. 67 13.4.2 405 Method Not Allowed .............................. 68
13.4.3 451 Parameter Not Understood ........................ 67 13.4.3 451 Parameter Not Understood ........................ 68
13.4.4 452 reserved ........................................ 67 13.4.4 452 reserved ........................................ 68
13.4.5 453 Not Enough Bandwidth ............................ 67 13.4.5 453 Not Enough Bandwidth ............................ 68
13.4.6 454 Session Not Found ............................... 68 13.4.6 454 Session Not Found ............................... 68
13.4.7 455 Method Not Valid in This State .................. 68 13.4.7 455 Method Not Valid in This State .................. 68
13.4.8 456 Header Field Not Valid for Resource ............. 68 13.4.8 456 Header Field Not Valid for Resource ............. 68
13.4.9 457 Invalid Range ................................... 68 13.4.9 457 Invalid Range ................................... 69
13.4.10 458 Parameter Is Read-Only .......................... 68 13.4.10 458 Parameter Is Read-Only .......................... 69
13.4.11 459 Aggregate Operation Not Allowed ................. 68 13.4.11 459 Aggregate Operation Not Allowed ................. 69
13.4.12 460 Only Aggregate Operation Allowed ................ 68 13.4.12 460 Only Aggregate Operation Allowed ................ 69
13.4.13 461 Unsupported Transport ........................... 68 13.4.13 461 Unsupported Transport ........................... 69
13.4.14 462 Destination Unreachable ......................... 69 13.4.14 462 Destination Unreachable ......................... 69
13.4.15 463 Destination Prohibited .......................... 69 13.4.15 463 Destination Prohibited .......................... 69
13.4.16 470 Connection Authorization Required ............... 69 13.4.16 464 Data Transport Not Ready Yet .................... 70
13.4.17 471 Connection Credentials not accepted ............. 69 13.4.17 470 Connection Authorization Required ............... 70
13.5 Server Error 5xx .................................... 69 13.4.18 471 Connection Credentials not accepted ............. 70
13.5.1 551 Option not supported ............................ 69 13.5 Server Error 5xx .................................... 70
14 Header Field Definitions ............................ 69 13.5.1 551 Option not supported ............................ 70
14.1 Accept .............................................. 73 14 Header Field Definitions ............................ 70
14.1 Accept .............................................. 74
14.2 Accept-Credentials .................................. 75 14.2 Accept-Credentials .................................. 75
14.3 Accept-Encoding ..................................... 76 14.3 Accept-Encoding ..................................... 75
14.4 Accept-Language ..................................... 76 14.4 Accept-Language ..................................... 77
14.5 Accept-Ranges ....................................... 76 14.5 Accept-Ranges ....................................... 77
14.6 Allow ............................................... 77 14.6 Allow ............................................... 78
14.7 Authorization ....................................... 77 14.7 Authorization ....................................... 78
14.8 Bandwidth ........................................... 77 14.8 Bandwidth ........................................... 78
14.9 Blocksize ........................................... 77 14.9 Blocksize ........................................... 78
14.10 Cache-Control ....................................... 78 14.10 Cache-Control ....................................... 79
14.11 Connection .......................................... 80 14.11 Connection .......................................... 81
14.12 Connection-Credentials .............................. 80 14.12 Connection-Credentials .............................. 81
14.13 Content-Base ........................................ 81 14.13 Content-Base ........................................ 82
14.14 Content-Encoding .................................... 81 14.14 Content-Encoding .................................... 82
14.15 Content-Language .................................... 81 14.15 Content-Language .................................... 82
14.16 Content-Length ...................................... 81 14.16 Content-Length ...................................... 82
14.17 Content-Location .................................... 81 14.17 Content-Location .................................... 82
14.18 Content-Type ........................................ 81 14.18 Content-Type ........................................ 82
14.19 CSeq ................................................ 81 14.19 CSeq ................................................ 83
14.20 Date ................................................ 82 14.20 Date ................................................ 83
14.21 ETag ................................................ 82 14.21 ETag ................................................ 83
14.22 Expires ............................................. 83 14.22 Expires ............................................. 84
14.23 From ................................................ 84 14.23 From ................................................ 85
14.24 If-Match ............................................ 84 14.24 If-Match ............................................ 85
14.25 If-Modified-Since ................................... 84 14.25 If-Modified-Since ................................... 85
14.26 If-None-Match ....................................... 84 14.26 If-None-Match ....................................... 86
14.27 Last-Modified ....................................... 85 14.27 Last-Modified ....................................... 86
14.28 Location ............................................ 85 14.28 Location ............................................ 86
14.29 Proxy-Authenticate .................................. 85 14.29 Proxy-Authenticate .................................. 86
14.30 Proxy-Authorization ................................. 85 14.30 Proxy-Authorization ................................. 86
14.31 Proxy-Require ....................................... 85 14.31 Proxy-Require ....................................... 86
14.32 Proxy-Supported ..................................... 85 14.32 Proxy-Supported ..................................... 87
14.33 Public .............................................. 86 14.33 Public .............................................. 87
14.34 Range ............................................... 87 14.34 Range ............................................... 88
14.35 Referer ............................................. 89 14.35 Referer ............................................. 90
14.36 Retry-After ......................................... 89 14.36 Retry-After ......................................... 90
14.37 Require ............................................. 89 14.37 Require ............................................. 90
14.38 RTP-Info ............................................ 90 14.38 RTP-Info ............................................ 91
14.39 Scale ............................................... 92 14.39 Scale ............................................... 93
14.40 Speed ............................................... 93 14.40 Speed ............................................... 94
14.41 Server .............................................. 93 14.41 Server .............................................. 95
14.42 Session ............................................. 93 14.42 Session ............................................. 95
14.43 Supported ........................................... 95 14.43 Supported ........................................... 96
14.44 Timestamp ........................................... 96 14.44 Timestamp ........................................... 97
14.45 Transport ........................................... 96 14.45 Transport ........................................... 97
14.46 Unsupported ......................................... 102 14.46 Unsupported ......................................... 103
14.47 User-Agent .......................................... 102 14.47 User-Agent .......................................... 104
14.48 Vary ................................................ 102 14.48 Vary ................................................ 104
14.49 Via ................................................. 102 14.49 Via ................................................. 104
14.50 WWW-Authenticate .................................... 103 14.50 WWW-Authenticate .................................... 104
15 Proxies ............................................. 103 15 Proxies ............................................. 104
16 Caching ............................................. 104 16 Caching ............................................. 105
17 Examples ............................................ 105 17 Examples ............................................ 106
17.1 Media on Demand (Unicast) ........................... 105 17.1 Media on Demand (Unicast) ........................... 106
17.2 Media on Demand (Unicast) ........................... 108 17.2 Media on Demand (Unicast) ........................... 109
17.3 Single Stream Container Files ....................... 111 17.3 Single Stream Container Files ....................... 112
17.4 Live Media Presentation Using Multicast ............. 112 17.4 Live Media Presentation Using Multicast ............. 114
17.5 Capability Negotiation .............................. 114 17.5 Capability Negotiation .............................. 115
18 Security Framework .................................. 115 18 Security Framework .................................. 116
18.1 RTSP and HTTP Authentication ........................ 115 18.1 RTSP and HTTP Authentication ........................ 116
18.2 RTSP over TLS ....................................... 115 18.2 RTSP over TLS ....................................... 116
18.3 Security and Proxies ................................ 116 18.3 Security and Proxies ................................ 117
18.3.1 Accept-Credentials .................................. 117 18.3.1 Accept-Credentials .................................. 118
18.3.2 User approved TLS procedure ......................... 118 18.3.2 User approved TLS procedure ......................... 119
19 Syntax .............................................. 120 19 Syntax .............................................. 121
19.1 Base Syntax ......................................... 120 19.1 Base Syntax ......................................... 121
19.2 RTSP Protocol Definition ............................ 122 19.2 RTSP Protocol Definition ............................ 123
19.2.1 Generic Protocol elements ........................... 122 19.2.1 Generic Protocol elements ........................... 123
19.2.2 Message Syntax ...................................... 124 19.2.2 Message Syntax ...................................... 125
19.2.3 Header Syntax ....................................... 128 19.2.3 Header Syntax ....................................... 129
19.3 SDP extension Syntax ................................ 134 19.3 SDP extension Syntax ................................ 135
20 Security Considerations ............................. 134 20 Security Considerations ............................. 135
20.1 Remote denial of Service Attack ..................... 136 20.1 Remote denial of Service Attack ..................... 137
21 IANA Considerations ................................. 137 21 IANA Considerations ................................. 138
21.1 Feature-tags ........................................ 138 21.1 Feature-tags ........................................ 139
21.1.1 Description ......................................... 138 21.1.1 Description ......................................... 139
21.1.2 Registering New Feature-tags with IANA .............. 138 21.1.2 Registering New Feature-tags with IANA .............. 139
21.1.3 Registered entries .................................. 138 21.1.3 Registered entries .................................. 139
21.2 RTSP Methods ........................................ 139 21.2 RTSP Methods ........................................ 140
21.2.1 Description ......................................... 139 21.2.1 Description ......................................... 140
21.2.2 Registering New Methods with IANA ................... 139 21.2.2 Registering New Methods with IANA ................... 140
21.2.3 Registered Entries .................................. 139 21.2.3 Registered Entries .................................. 140
21.3 RTSP Status Codes ................................... 139 21.3 RTSP Status Codes ................................... 141
21.3.1 Description ......................................... 139 21.3.1 Description ......................................... 141
21.3.2 Registering New Status Codes with IANA .............. 139 21.3.2 Registering New Status Codes with IANA .............. 141
21.3.3 Registered Entries .................................. 140 21.3.3 Registered Entries .................................. 141
21.4 RTSP Headers ........................................ 140 21.4 RTSP Headers ........................................ 141
21.4.1 Description ......................................... 140 21.4.1 Description ......................................... 141
21.4.2 Registering New Headers with IANA ................... 140 21.4.2 Registering New Headers with IANA ................... 141
21.4.3 Registered entries .................................. 140 21.4.3 Registered entries .................................. 142
21.5 Transport Header registries ......................... 141 21.5 Transport Header registries ......................... 142
21.5.1 Transport Protocol Specification .................... 141 21.5.1 Transport Protocol Specification .................... 142
21.5.2 Transport modes ..................................... 143 21.5.2 Transport modes ..................................... 144
21.5.3 Transport Parameters ................................ 143 21.5.3 Transport Parameters ................................ 144
21.6 Cache Directive Extensions .......................... 143 21.6 Cache Directive Extensions .......................... 145
21.7 Accept-Credentials .................................. 144 21.7 Accept-Credentials .................................. 145
21.7.1 Accept-Credentials policies ......................... 144 21.7.1 Accept-Credentials policies ......................... 145
21.7.2 Accept-Credentials hash algorithms .................. 145 21.7.2 Accept-Credentials hash algorithms .................. 146
21.8 Range header formats ................................ 145 21.8 Range header formats ................................ 146
21.9 URI Schemes ......................................... 145 21.9 URI Schemes ......................................... 147
21.9.1 The rtsp URI Scheme ................................. 145 21.9.1 The rtsp URI Scheme ................................. 147
21.9.2 The rtsps URI Scheme ................................ 146 21.9.2 The rtsps URI Scheme ................................ 148
21.9.3 The rtspu URI Scheme ................................ 147 21.9.3 The rtspu URI Scheme ................................ 149
21.10 SDP attributes ...................................... 148 21.10 SDP attributes ...................................... 149
A RTSP Protocol State Machine ......................... 149 A RTSP Protocol State Machine ......................... 150
A.1 States .............................................. 149 A.1 States .............................................. 151
A.2 State variables ..................................... 150 A.2 State variables ..................................... 151
A.3 Abbreviations ....................................... 150 A.3 Abbreviations ....................................... 151
A.4 State Tables ........................................ 150 A.4 State Tables ........................................ 151
B Media Transport Alternatives ........................ 153 B Media Transport Alternatives ........................ 155
B.1 RTP ................................................. 154 B.1 RTP ................................................. 155
B.1.1 AVP ................................................. 154 B.1.1 AVP ................................................. 155
B.1.2 AVP/UDP ............................................. 154 B.1.2 AVP/UDP ............................................. 155
B.1.3 AVPF/UDP ............................................ 155 B.1.3 AVPF/UDP ............................................ 156
B.1.4 SAVP/UDP ............................................ 156 B.1.4 SAVP/UDP ............................................ 157
B.1.5 SAVPF/UDP ........................................... 156 B.1.5 SAVPF/UDP ........................................... 157
B.2 RTP over TCP ........................................ 156 B.2 RTP over TCP ........................................ 157
B.2.1 Interleaved RTP over TCP ............................ 156 B.2.1 Interleaved RTP over TCP ............................ 157
B.2.2 RTP over independent TCP ............................ 156 B.2.2 RTP over independent TCP ............................ 158
B.2.3 Handling NPT Jumps in the RTP Media Layer ........... 159 B.2.3 Handling NPT Jumps in the RTP Media Layer ........... 161
B.2.4 Handling RTP Timestamps after PAUSE ................. 162 B.2.4 Handling RTP Timestamps after PAUSE ................. 163
B.2.5 RTSP / RTP Integration .............................. 164 B.2.5 RTSP / RTP Integration .............................. 166
B.2.6 Scaling with RTP .................................... 164 B.2.6 Scaling with RTP .................................... 166
B.2.7 Maintaining NPT synchronization with RTP B.2.7 Maintaining NPT synchronization with RTP
timestamps ..................................................... 165 timestamps ..................................................... 166
B.2.8 Continuous Audio .................................... 165 B.2.8 Continuous Audio .................................... 166
B.2.9 Multiple Sources in an RTP Session .................. 165 B.2.9 Multiple Sources in an RTP Session .................. 166
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 ................................................... 165 RTSP Session ................................................... 166
B.3 Future Additions .................................... 166 B.3 Future Additions .................................... 167
C Use of SDP for RTSP Session Descriptions ............ 166 C Use of SDP for RTSP Session Descriptions ............ 167
C.1 Definitions ......................................... 166 C.1 Definitions ......................................... 168
C.1.1 Control URI ......................................... 166 C.1.1 Control URI ......................................... 168
C.1.2 Media Streams ....................................... 168 C.1.2 Media Streams ....................................... 169
C.1.3 Payload Type(s) ..................................... 168 C.1.3 Payload Type(s) ..................................... 170
C.1.4 Format-Specific Parameters .......................... 168 C.1.4 Format-Specific Parameters .......................... 170
C.1.5 Range of Presentation ............................... 169 C.1.5 Directionality of media stream ...................... 170
C.1.6 Time of Availability ................................ 169 C.1.6 Range of Presentation ............................... 171
C.1.7 Connection Information .............................. 170 C.1.7 Time of Availability ................................ 172
C.1.8 Entity Tag .......................................... 170 C.1.8 Connection Information .............................. 172
C.2 Aggregate Control Not Available ..................... 171 C.1.9 Entity Tag .......................................... 172
C.3 Aggregate Control Available ......................... 171 C.2 Aggregate Control Not Available ..................... 173
C.4 RTSP external SDP delivery .......................... 172 C.3 Aggregate Control Available ......................... 174
D Minimal RTSP implementation ......................... 173 C.4 RTSP external SDP delivery .......................... 175
D.1 Minimal Core Implementation ......................... 173 D Minimal RTSP implementation ......................... 175
D.2 Recommended Core Implementation ..................... 173 D.1 Minimal Core Implementation ......................... 175
D.3 The Basic Playback Feature Support .................. 174 D.2 Recommended Core Implementation ..................... 176
D.3.1 Client .............................................. 174 D.3 The Basic Playback Feature Support .................. 176
D.3.2 Server .............................................. 174 D.3.1 Client .............................................. 176
D.3.3 Proxy ............................................... 175 D.3.2 Server .............................................. 177
D.4 Secure Transport .................................... 175 D.3.3 Proxy ............................................... 177
D.4 Secure Transport .................................... 178
E Requirements for Unreliable Transport of RTSP E Requirements for Unreliable Transport of RTSP
messages ....................................................... 175 messages ....................................................... 178
F Backwards Compatibility Considerations .............. 177 F Backwards Compatibility Considerations .............. 179
F.1 Play Request in Play mode ........................... 177 F.1 Play Request in Play mode ........................... 179
F.2 Using Persistent Connections ........................ 177 F.2 Using Persistent Connections ........................ 180
G Open Issues ......................................... 177 G Open Issues ......................................... 180
H Changes ............................................. 178 H Changes ............................................. 181
H.1 Changes needing to be updated ..................... 184 H.1 Changes needing to be updated ..................... 187
I Author Addresses .................................... 184 I Author Addresses .................................... 188
J Contributors ........................................ 185 J Contributors ........................................ 188
K Acknowledgements .................................... 186 K Acknowledgements .................................... 189
L Normative References ................................ 186 L Normative References ................................ 189
M Informative References .............................. 188 M Informative References .............................. 191
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 [28]. The goal of this version proposed standard defined in RFC 2326 [25]. 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 deemed 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 has reduced functionality compared to RTSP 1.0 and aims at
at specifying the RTSP core, functionality and rules for extensions, specifying the RTSP core, functionality and rules for extensions, and
and basic interaction with the media delivery protocol RTP. basic interaction with the media delivery protocol RTP.
Any other functionality would be need to be published as extension Any other functionality would be need to be published as extension
documents. And this specification provides rules for such extensions documents. This specification provides rules for such extensions and
and defines registries to avoid naming collisions. defines registries to avoid naming collisions.
1.2 Purpose 1.2 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls one The Real-Time Streaming Protocol (RTSP) establishes and controls one
or several time-synchronized streams of continuous media such as or several time-synchronized streams of continuous media such as
audio and video. Put simply, RTSP acts as a "network remote control" audio and video. Put simply, RTSP acts as a "network remote control"
for multimedia servers. for multimedia servers.
There is no notion of an RTSP connection in the protocol. Instead, an There is no notion of an RTSP connection in the protocol. Instead, an
RTSP server maintains a session labeled by an identifier to associate RTSP server maintains a session labeled by an identifier to associate
groups of media streams and their states. An RTSP session is not tied groups of media streams and their states. An RTSP session is not tied
to a transport-level connection such as a TCP connection. During a to a transport-level connection such as a TCP connection. During a
session, a client may open and close many reliable transport session, a client may open and close multiple reliable transport
connections to the server to issue RTSP requests for that session. connections to the server to issue RTSP requests for that session.
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
[28] and the tradeoff in size and complexity of this [25] 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 describes how
[1] is used for this purpose. The streams controlled by RTSP may use SDP [1] is used for this purpose. The streams controlled by RTSP may
RTP [2] for their data transport, but the operation of RTSP does not use RTP [2] for their data transport, but the operation of RTSP does
depend on the transport mechanism used to carry continuous media. not 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]
so that extension mechanisms to HTTP can in most cases also be added so that extension mechanisms to HTTP can in most cases also be
to RTSP. However, RTSP differs in a number of important aspects from applied to RTSP. However, RTSP differs in a number of important
HTTP: aspects from HTTP:
o RTSP introduces a number of new methods and has a different o RTSP introduces a number of new methods and has a different
protocol identifier. protocol identifier.
o RTSP has the notion of a session built into the protocol. o RTSP has the notion of a session built into the protocol.
o An RTSP server needs to maintain state by default in almost o An RTSP server needs to maintain state in almost all cases, as
all cases, as opposed to the stateless nature of HTTP. opposed to the stateless nature of HTTP.
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
[29]. [26].
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:
Retrieval of media from media server: The client can either Retrieval of media from media server: The client can either
request a presentation description via RTSP DESCRIBE, HTTP request a presentation description via RTSP DESCRIBE, HTTP
or some other method. If the presentation is being or some other method. If the presentation is being
multicast, the presentation description contains the multicast, the presentation description contains the
multicast addresses and ports to be used for the continuous multicast addresses and ports to be used for the continuous
media. If the presentation is to be sent only to the client media. If the presentation is to be sent only to the client
via unicast, the client provides the destination of via unicast, the client provides the destination.
necessity.
Invitation of a media server to a conference: A media server can Invitation of a media server to a conference: A media server can
be "invited" to join an existing conference to play back be "invited" to join an existing conference to play back
media into the presentation. This mode is useful for media into the presentation. This mode is useful, for
example distributed teaching applications. Several parties example, in distributed teaching applications. Several
in the conference may take turns "pushing the remote parties in the conference may take turns "pushing the
control buttons". Note: This functionality will require remote control buttons". Note: This functionality will
RTSP external application level functionality. require RTSP external application level functionality.
RTSP requests may be handled by proxies, tunnels and caches as in RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 [3]. HTTP/1.1 [3].
1.3 Notational Conventions 1.3 Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1, Since many of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [3]). to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [3]).
skipping to change at page 11, line 49 skipping to change at page 11, line 48
be used in a standardized manner without further definition in an be used in a standardized manner without further definition in an
extension specification to RTSP. extension specification to RTSP.
1.3.1 RFC Editor Consideration 1.3.1 RFC Editor Consideration
Please replace RFC XXXX with the RFC number this specification Please replace RFC XXXX with the RFC number this specification
recieves. recieves.
Please replace RFC YYYY with the RFC number that SAVPF [6] receives. Please replace RFC YYYY with the RFC number that SAVPF [6] receives.
Please replace RFC ZZZZ with the RFC number that SDP-new [7] receives
when published.
Please replace RFC WWWW with the RFC number that RTP framing over TCP
[8] receives when published.
1.4 Terminology 1.4 Terminology
Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not
listed here are defined as in HTTP/1.1. listed here are defined as in HTTP/1.1.
Aggregate control: The concept of controlling multiple streams Aggregate control: The concept of controlling multiple streams
using a single timeline, generally maintained by the using a single timeline, generally maintained by the
server. A client, for example, uses aggregate control when server. A client, for example, uses aggregate control when
it issues a single play or pause message to simultaneously it issues a single play or pause message to simultaneously
control both the audio and video in a movie. control both the audio and video in a movie. A session
which is under aggregate control is referred to as an
aggregated session.
Aggregate control URI: The URI used in an RTSP request to refer Aggregate control URI: The URI used in an RTSP request to refer
to and control an aggregated session. It normally, but not to and control an aggregated session. It normally, but not
always, corresponds to the presentation URI specified in always, corresponds to the presentation URI specified in
the session description. See Section 11.3 for more the session description. See Section 11.3 for more
information. information.
Conference: a multiparty, multimedia presentation, where "multi" Conference: a multiparty, multimedia presentation, where "multi"
implies greater than or equal to one. implies greater than or equal to one.
skipping to change at page 13, line 11 skipping to change at page 13, line 4
or response. An entity consists of meta-information in the or response. An entity consists of meta-information in the
form of entity-header fields and content in the form of an form of entity-header fields and content in the form of an
entity-body, as described in Section 8. entity-body, as described in Section 8.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality,
i.e. a feature. i.e. a feature.
IRI: Internationalized Resource Identifier, is the same as an IRI: Internationalized Resource Identifier, is the same as an
URI, with the exception that it allows characters from the URI, with the exception that it allows characters from the
whole Universal Character Set (Unicode/ISO 10646), rather whole Universal Character Set (Unicode/ISO 10646), rather
than the US-ASCII only. See RFC 3987 [9] for more than the US-ASCII only. See RFC 3987 [7] for more
information. information.
Live: Normally used to describe a presentation or session with Live: Normally used to describe a presentation or session with
media coming from an ongoing event. This generally results media coming from an ongoing event. This generally results
in that the session has a unbound or only loosely defined in the session having an unbound or only loosely defined
duration, and that no seek operations are possible. duration, and sometimes no seek operations are possible.
Media initialization: Datatype/codec specific initialization. Media initialization: Datatype/codec specific initialization.
This includes such things as clock rates, color tables, This includes such things as clock rates, color tables,
etc. Any transport-independent information which is etc. Any transport-independent information which is
required by a client for playback of a media stream occurs required by a client for playback of a media stream occurs
in the media initialization phase of stream setup. in the media initialization phase of stream setup.
Media parameter: Parameter specific to a media type that may be Media parameter: Parameter specific to a media type that may be
changed before or during stream playback. changed before or during stream playback.
skipping to change at page 13, line 48 skipping to change at page 13, line 41
or a video stream as well as a single whiteboard or shared or a video stream as well as a single whiteboard or shared
application group. When using RTP, a stream consists of all application group. When using RTP, a stream consists of all
RTP and RTCP packets created by a source within an RTP RTP and RTCP packets created by a source within an RTP
session. session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined structured sequence of octets matching the syntax defined
in Section 19 and transmitted over a connection or a in Section 19 and transmitted over a connection or a
connectionless transport. connectionless transport.
Non-Aggregated Control: Control of a single media stream. Only Non-Aggregated Control: Control of a single media stream. This
possible in RTSP sessions with a single media. is only possible in RTSP sessions with a single media.
Participant: Member of a conference. A participant may be a Participant: Member of a conference. A participant may be a
machine, e.g., a playback server. machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the Presentation: A set of one or more streams presented to the
client as a complete media feed and described by a client as a complete media feed and described by a
presentation description as defined below. Presentations presentation description as defined below. Presentations
with more than one media stream is often handled in RTSP with more than one media stream are often handled in RTSP
under aggregate control. under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a information about one or more media streams within a
presentation, such as the set of encodings, network presentation, such as the set of encodings, network
addresses and information about the content. Other IETF addresses and information about the content. Other IETF
protocols such as SDP (RFC ZZZZ [1]) use the term "session" protocols such as SDP (RFC 4566 [1]) use the term "session"
for a presentation. The presentation description may take for a presentation. The presentation description may take
several different formats, including but not limited to the several different formats, including but not limited to the
session description protocol format, SDP. session description protocol format, SDP.
Response: An RTSP response. If an HTTP response is meant, that Response: An RTSP response. If an HTTP response is meant, that
is indicated explicitly. is indicated explicitly.
Request: An RTSP request. If an HTTP request is meant, that is Request: An RTSP request. If an HTTP request is meant, that is
indicated explicitly. indicated explicitly.
skipping to change at page 14, line 40 skipping to change at page 14, line 34
an RTSP Proxy. In this specification, there are many an RTSP Proxy. In this specification, there are many
capabilities that are common to these three entities such capabilities that are common to these three entities such
as the capability to send requests or receive responses. as the capability to send requests or receive responses.
This term will be used when describing functionality that This term will be used when describing functionality that
is applicable to all three of these entities. is applicable to all three of these entities.
RTSP session: A stateful abstraction upon which the main control RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a server methods of RTSP operate. An RTSP session is a server
entity; it is created, maintained and destroyed by the entity; it is created, maintained and destroyed by the
server. It is established by an RTSP server upon the server. It is established by an RTSP server upon the
completion of a successful SETUP request (when 200 OK completion of a successful SETUP request (when a 200 OK
response is sent) and is labelled by a session identifier response is sent) and is labelled with a session identifier
at that time. The session exists until timed out by the at that time. The session exists until timed out by the
server or explicitly removed by a TEARDOWN request. An RTSP server or explicitly removed by a TEARDOWN request. An RTSP
session is a stateful entity; an RTSP server maintains an session is a stateful entity; an RTSP server maintains an
explicit session state machine (see Appendix A) where most explicit session state machine (see Appendix A) where most
state transitions are triggered by client requests. The state transitions are triggered by client requests. The
existence of a session implies the existence of state about existence of a session implies the existence of state about
the session's media streams and their respective transport the session's media streams and their respective transport
mechanisms. A given session can have one or more media mechanisms. A given session can have one or more media
streams associated with it. An RTSP server uses the streams associated with it. An RTSP server uses the
session to aggregate control over multiple media streams. session to aggregate control over multiple media streams.
Transport initialization: The negotiation of transport Transport initialization: The negotiation of transport
information (e.g., port numbers, transport protocols) information (e.g., port numbers, transport protocols)
between the client and the server. between the client and the server.
URI: Universal Resource Identifier, see RFC 3986 [10]. In RTSP URI: Universal Resource Identifier, see RFC 3986 [8]. The URIs
the used URIs are as general rule in fact URL's as they used in RTSP are generally URLs as they give a location for
gives an location for the resource. As URLs are a subset of the resource. As URLs are a subset of URIs, they will be
URIs, they will be referred to as URIs to cover also the referred to as URIs to cover also the cases when an RTSP
cases when an RTSP URI would not be an URL. URI would not be an URL.
URL: Universal Resource Locator, is an URI which identifies the URL: Universal Resource Locator, is an URI which identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism, rather than
identifying the resource by name or by some other identifying the resource by name or by some other
attribute(s) of that resource. attribute(s) of that resource.
1.5 Protocol Properties 1.5 Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to Extendable: New methods and parameters can be easily added to
RTSP. RTSP.
Easy to parse: RTSP can be parsed by standard HTTP or MIME Easy to parse: RTSP can be parsed by standard HTTP or MIME
parsers. parsers.
Secure: RTSP re-uses web security mechanisms, either at the Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, RFC 2246 [11]) or within the protocol transport level (TLS, RFC 4346 [9]) or within the protocol
itself. All HTTP authentication mechanisms such as basic itself. All HTTP authentication mechanisms such as basic
(RFC 2616 [3]) and digest authentication (RFC 2617 [12]) (RFC 2616 [3]) and digest authentication (RFC 2617 [10])
are directly applicable. are directly applicable.
Transport-independent: RTSP does not preclude the use of Transport-independent: RTSP does not preclude the use of
unreliable datagram protocol (UDP) (RFC 768 [13]) as it unreliable datagram protocol (UDP) (RFC 768 [11]) as it
would be possible to implement application-level would be possible to implement application-level
reliability. The use of a connectionless datagram protocol reliability. The use of a connectionless datagram protocol
such as UDP requires additional definition that may be such as UDP requires additional definition that may be
provided as extensions to the core RTSP specification. The provided as extensions to the core RTSP specification. The
usage of the reliable stream protocol TCP (RFC 793 [14]) reliable stream protocol TCP (RFC 793 [12]) and the secured
and secured reliable stream protocol TLS over TCP [11] is reliable stream protocol TLS over TCP [9] are the currently
what is currently defined as transport protocol of RTSP defined transport protocols for RTSP messages.
messages.
Media-delivery protocol independent: The operation of RTSP does
not depend on the transport mechanism used to carry
continuous media. While most real-time media will use RTP
as a transport protocol, RTSP does not preclude the use of
other protocols such as MPEG-2 [27]. The use of other
protocols requires additional definition that may be
provided as extensions to the core RTSP specification.
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 in those
cases performed at the transport level. cases is 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 [30] or H.323 [31] may be conference. In particular, SIP [28] or H.323 [29] 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
[32]) firewalls. A firewall may need to understand the [30]) 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 [33,34]) for associating labels with content. Selection [31,32]) 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
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
method prior to actually needing to process a continuous method prior to actually needing to process a continuous
skipping to change at page 17, line 24 skipping to change at page 17, line 24
magnitude of changes supported: magnitude of changes supported:
o Existing methods can be extended with new parameters, e.g. o Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by headers, as long as these parameters can be safely ignored by
the recipient. If the client needs negative acknowledgement the recipient. If the client needs negative acknowledgement
when a method extension is not supported, a tag corresponding when a method extension is not supported, a tag corresponding
to the extension may be added in the field of the Require or to the extension may be added in the field of the Require or
Proxy-Require headers (see Section 14.37). Proxy-Require headers (see Section 14.37).
o New methods can be added. If the recipient of the message does o New methods can be added. If the recipient of the message does
not understand the request, it responds with error code 501 not understand the request, it MUST respond with error code
(Not Implemented) and the sender can avoid using this method 501 (Not Implemented) so that the sender can avoid using this
again. A client may also use the OPTIONS method to inquire method again. A client may also use the OPTIONS method to
about methods supported by the server. The server list the inquire about methods supported by the server. The server MUST
methods it supports using the Public response header. list the methods it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost o A new version of the protocol can be defined, allowing almost
all aspects (except the position of the protocol version all aspects (except the position of the protocol version
number) to change. number) to change. A new version of the protocol MUST be
registered through an IETF standard track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of this available when performing a request. For detailed explanation of this
see section 10. see section 10.
1.7 Overall Operation 1.7 Overall Operation
Each presentation and media stream is identified by an RTSP URI. The Each presentation and media stream is identified by an RTSP URI. The
overall presentation and the properties of the media the presentation overall presentation and the properties of the media the presentation
is made up of are defined by a presentation description file, the is composed of are defined by a presentation description file, the
format of which is outside the scope of this specification. The format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored HTTP or other means such as email and may not necessarily be stored
on the media server. on the media server.
For the purposes of this specification, a presentation description is For the purposes of this specification, a presentation description is
assumed to describe one or more presentations, each of which assumed to describe one or more presentations, each of which
maintains a common time axis. For simplicity of exposition and maintains a common time axis. For simplicity of exposition and
without loss of generality, it is assumed that the presentation without loss of generality, it is assumed that the presentation
description contains exactly one such presentation. A presentation description contains exactly one such presentation. A presentation
skipping to change at page 18, line 46 skipping to change at page 18, line 47
conference description, established by means outside the conference description, established by means outside the
scope of this specification, for example by a SIP created scope of this specification, for example by a SIP created
conference. conference.
1.8 RTSP States 1.8 RTSP States
RTSP controls a stream which may be sent via a separate protocol, RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may be independent of the control channel. For example, RTSP control may be
transported on a TCP connection while the media data is conveyed via transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime, a single received by the media server. Also, during its lifetime a single
media stream may be controlled by RTSP requests issued sequentially media stream may be controlled by RTSP requests issued sequentially
on different TCP connections. Therefore, the server needs to maintain on different TCP connections. Therefore, the server needs to maintain
"session state" to be able to correlate RTSP requests with a stream. "session state" to be able to correlate RTSP requests with a stream.
The state transitions are described in Appendix A. The state transitions are described in Appendix A.
Many methods in RTSP do not contribute to state. However, the Many methods in RTSP do not contribute to state. However, the
following play a central role in defining the allocation and usage of following play a central role in defining the allocation and usage of
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and
TEARDOWN. TEARDOWN.
SETUP: Causes the server to allocate resources for a stream and SETUP: Causes the server to allocate resources for a stream and
create an RTSP session. create an RTSP session.
PLAY: Starts data transmission on a stream allocated via SETUP. PLAY: Starts data transmission on a stream allocated via SETUP.
PAUSE: Temporarily halts a stream without freeing server PAUSE: Temporarily halts a stream without freeing server
resources. resources.
REDIRECT: Indicates that the session should be moved to new REDIRECT: Indicates that the session should be moved to a new
server / location server or location
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field RTSP methods that contribute to state use the Session header field
(Section 14.42) to identify the RTSP session whose state is being (Section 14.42) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to manipulated. The server generates session identifiers in response to
SETUP requests (Section 11.3). SETUP requests (Section 11.3).
1.9 Relationship with Other Protocols 1.9 Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content interact with HTTP in that the initial contact with streaming content
is often to be made through a web page. The current protocol will often be made through a web page. The current protocol
specification aims to allow different hand-off points between a web specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the server and the media server implementing RTSP. For example, the
presentation description can be retrieved using HTTP or RTSP, which presentation description can be retrieved using HTTP or RTSP, which
reduces round trips in web-browser-based scenarios, yet also allows reduces round trips in web-browser-based scenarios, yet also allows
for stand alone RTSP servers and clients which do not rely on HTTP at for stand alone RTSP servers and clients which do not rely on HTTP at
all. However, RTSP differs fundamentally from HTTP in that most data all. However, RTSP differs fundamentally from HTTP in that most data
delivery takes place out-of-band in a different protocol. HTTP is an delivery takes place out-of-band in a different protocol. HTTP is an
asymmetric protocol where the client issues requests and the server asymmetric protocol where the client issues requests and the server
responds. In RTSP, both the media client and media server can issue responds. In RTSP, both the media client and media server can issue
requests. RTSP requests are also stateful; they may set parameters requests. RTSP requests are also stateful; they may set parameters
skipping to change at page 20, line 17 skipping to change at page 20, line 17
containing several media streams. Session Description Protocol (SDP) containing several media streams. Session Description Protocol (SDP)
[1] is generally the format of choice; however, RTSP is not bound to [1] is generally the format of choice; however, RTSP is not bound to
it. For data delivery, most real-time media will use RTP as a it. For data delivery, most real-time media will use RTP as a
transport protocol. While RTSP works well with RTP, it is not tied to transport protocol. While RTSP works well with RTP, it is not tied to
RTP. RTP.
2 RTSP Use Cases 2 RTSP Use Cases
This section describes the most important and considered use cases This section describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in for RTSP. They are listed in descending order of importance in
regards to ensuring that all necessary functionality is present. This regards to ensuring that all necessary functionality is present.
specification does only fully support usage of the two first. Also in This specification only fully supports usage of the two first. Also
these first two cases, there are special cases or exceptions that are in these first two cases, there are special cases or exceptions that
not supported without extensions, e.g. the redirection of media to are not supported without extensions, e.g. the redirection of media
another address than the controlling entity. to another address than the controlling entity.
2.1 On-demand Playback of Stored Content 2.1 On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content a client. A client desiring playback of any of the stored content
then uses RTSP to set up and configure the media transport required uses RTSP to set up the media transport required to deliver the
for the desired content. Then RTSP is used to initiate, halt and desired content. RTSP is then used to initiate, halt and manipulate
manipulate the actual transmission (playout) of the content. There the actual transmission (playout) of the content. RTSP is also
are also requirement on being able to use RTSP to carry necessary required to provide necessary description and synchronization
description and synchronization information for the content. The information for the content.
above high level description can be broken down into a number of
functionalities that RTSP needs to be capable of.
Presentation Description: The possibility to carry The above high level description can be broken down into a number of
initialization information about the presentation functions that RTSP needs to be capable of.
(content), for example, which media codec(s) that are
needed for the content. Other information that are Presentation Description: Provide initialization information
important; how many media stream that the presentation about the presentation (content); for example, which media
contains; what transport protocols used for the media codecs are needed for the content. Other information that
streams; and identifiers for these media streams. This is important includes the number of media stream the
information is required before setup of the content is presentation contains, the transport protocols used for the
possible. The information is also needed by the client to media streams, and identifiers for these media streams.
determine if it is capable at all to support the content. This information is required before setup of the content is
This information is not required to be sent using RTSP, possible and to determine if the client is even capable of
instead other external protocols can be utilized to using the content.
transport presentation descriptions. Two good examples are
the use of HTTP [3] or email to fetch or receive This information need not be sent using RTSP; other
presentation descriptions like SDP [1]. .XP Setup: external protocols can be used to transmit the transport
Performing setup of some or all of the media streams in a presentation descriptions. Two good examples are the use of
presentation. The setup itself consist of determining which HTTP [3] or email to fetch or receive presentation
protocols for media transport to use; the necessary descriptions like SDP [1].
parameters for the protocol, like addresses and ports. .XP
Control of Transmission: After the necessary media streams Setup: Set up some or all of the media streams in a
has been established the client can request the server to presentation. The setup itself consist of selecting the
start transmitting the content. There is need to allow the protocol for media transport and the necessary parameters
client to at arbitrary times start or stop the transmission for the protocol, like addresses and ports.
of the content. There are also exist need to be able to
start the transmission at an any point in the timeline of Control of Transmission: After the necessary media streams have
the presentation. .XP Synchronization: For media transport been established the client can request the server to start
protocols like RTP [18] it might be beneficial to carry transmitting the content. The client must be allowed to
synchronization information within RTSP. Either due to the start or stop the transmission of the content at arbitrary
lack of inter media synchronization within the protocol times. The client must also be able to start the
itself, or the potential delay before the synchronization transmission at any point in the timeline of the
is established (which is the case for RTP when using RTCP). presentation.
.XP Termination There is also need to be able to terminate
the established contexts. Synchronization: For media transport protocols like RTP [16] it
For this use cases there is a number of assumption about how it might be beneficial to carry synchronization information
works. These are listed below: within RTSP. This may be due to either the lack of inter-
media synchronization within the protocol itself, or the
potential delay before the synchronization is established
(which is the case for RTP when using RTCP).
Termination Terminate the established contexts.
For this use case there are a number of assumptions about how it
works. These are:
On-Demand content: The content is stored at the server and can
be accessed at any time during a time period when it is
intended to be available.
Independent sessions: A server is capable of serving a number of
clients simultaneously, including from the same piece of
content at different points in that presentations time-
line.
On-Demand content: The content available is stored at the server
and can be accessed at any time during a time period when
it is intended to be available. .XP Independent sessions: A
server is capable of serving a number of clients
simultaneously, including from the same piece of content at
different points in that presentations time-line. .XP
Unicast Transport: Content for each individual client is Unicast Transport: Content for each individual client is
transmitted to them using unicast traffic. transmitted to them using unicast traffic.
It is also possible to redirect the media traffic to another
destination than where the entity controlling traffic uses. It is also possible to redirect the media traffic to a different
However allowing this without appropriate mechanisms for destination than that of the entity controlling the traffic. However,
checking that the destination approves of this allows for allowing this without appropriate mechanisms for checking that the
distributed denial of service attacks (DDoS). destination approves of this allows for distributed denial of service
attacks (DDoS).
2.2 Unicast distribution of Live Content 2.2 Unicast distribution of Live Content
This use cases is not that different from the above on-demand content This use cases is similar to the above on-demand content case (see
case (see section 2.1. The difference is really the restriction the section 2.1; the difference is the nature of the content itself.
content itself establish. Live content is continuously distributed as Live content is continuously distributed as it becomes available from
it becomes available from a source, i.e. the main difference to on- a source; i.e., the main difference from on-demand is that one starts
demand is that one starts distributing content before the end of it distributing content before the end of it has become available to the
has become available to the server. In many cases the consumer of server.
live content is only interested in consuming what is actually happens
"now", i.e. very similar to broadcast TV. However in this case it is In many cases the consumer of live content is only interested in
assumed that there exist no broadcast or multicast channel to the consuming what is actually happens "now"; i.e., very similar to
users, and instead the server functions as a distribution node, broadcast TV. However in this case it is assumed that there exist no
sending the same content to multiple receivers, using unicast traffic broadcast or multicast channel to the users, and instead the server
between server and client. This unicast traffic and the transport functions as a distribution node, sending the same content to
parameters are individually negotiated for each receiving client. multiple receivers, using unicast traffic between server and client.
Another aspect of live content is that it has often very limited time This unicast traffic and the transport parameters are individually
of availability, as it is only is available for the duration of the negotiated for each receiving client.
event the content covers. A example of such a live content could for
example be a music concert, which lasts 2 hour and starts at a Another aspect of live content is that it often has a very limited
predetermined time. Thus there is need to announce when and for how time of availability, as it is only is available for the duration of
long the live content is available. the event the content covers. An example of such a live content could
be a music concert which lasts 2 hour and starts at a predetermined
time. Thus there is need to announce when and for how long the live
content is available.
2.3 On-demand Playback using Multicast 2.3 On-demand Playback using Multicast
It is possible to use RTSP to request that media is delivered to a It is possible to use RTSP to request that media be delivered to a
multicast group. The entity setting up the session (the controller) multicast group. The entity setting up the session (the controller)
will then control when and what media that is delivered to the group. will then control when and what media is delivered to the group. This
Also this use case has some potential for denial of service attacks, use case has some potential for denial of service attacks by flooding
in this case flooding any multicast group. Therefore there is need a multicast group. Therefore, a mechanism is needed to indicate that
for a mechanism indicating that the group actually accepts the the group actually accepts the traffic from the RTSP server.
traffic from the RTSP server. An open issue in this use case is how
one ensures that all receivers listening to the multicast or An open issue in this use case is how one ensures that all receivers
broadcast receives the session presentation configuring the listening to the multicast or broadcast receives the session
receivers. presentation configuring the receivers.
2.4 Inviting an RTSP server into a conference 2.4 Inviting an RTSP server into a conference
If one has an established conference or group session, it is possible If one has an established conference or group session, it is possible
to have a RTSP server distribute media to the whole group. The to have an RTSP server distribute media to the whole group.
transmission to the group is simplest controlled by a single Transmission to the group is simplest when controlled by a single
participant or leader of the conference. Shared control might be participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly possible, but would require further investigation and possibly
extensions. For reasonable complexity in the media transmission extensions.
stage, this use case assumes that there exist either multicast or a
conference focus that redistribute media to all participants. In some
more detail, this use case is intended to be able to handle the
following scenario: A conference leader or participant (from here
called the controller) has some pre-stored content on a RTSP server
that he likes to share with the group. The controller sets up an RTSP
session at the streaming server for the content the controller likes
to share. The session description for the content is retrieved by the
controller. The destination for the media content is set to the
shared multicast group or conference focus. When desired by the
controller, he/she can start and stop the transmission of the media
to the conference group. There are several issues with this use case
that is not solved by this core specification for RTSP:
o Denial of service threat, to avoid a RTSP server from being a This use case assumes that there exists either multicast or a
unknowing participant of a denial of service attack the server conference focus that redistribute media to all participants.
needs to be able to verify the destinations acceptance for the
media. Such a mechanism does not yet exist that can be used to
verify the approval to received media, instead only policies
can be used, which can be made to work in controlled
environments. .IP o 2 The problem of distributing the
presentation description to all participants in the group. To
enable a media receiver to decode the content correctly the
media configuration information will need to be distributed
reliable to all participants. This will most likely require
support from an external protocol. .IP o 2 Passing the
control. If it is desired to be able to pass the control of
the RTSP session between the participants some support will be
required by an external protocol for the necessary exchange of
state information and possibly floor control of who is
controlling the RTSP session.
So if there interest in this use case further work on the necessary This use case is intended to be able to handle the following
extensions has to be performed. scenario: A conference leader or participant (hereafter called the
controller) has some pre-stored content on an RTSP server that he
wants to share with the group. The controller sets up an RTSP session
at the streaming server for this content and retrieves the session
description for the content. The destination for the media content
is set to the shared multicast group or conference focus. When
desired by the controller, he/she can start and stop the transmission
of the media to the conference group.
There are several issues with this use case that are not solved by
this core specification for RTSP:
o To avoid an RTSP server from being an unknowing participant in
a denial of service attack the server needs to be able to
verify the destination's acceptance of the media. Such a
mechanism to verify the approval of received media does not
yet exist; instead, only policies can be used, which can be
made to work in controlled environments.
o To enable a media receiver to correctly decode the content the
media configuration information needs to be distributed
reliably to all participants. This will most likely require
support from an external protocol.
o If it is desired to pass control of the RTSP session between
the participants, some support will be required by an external
protocol to exchange state information and possibly floor
control of who is controlling the RTSP session.
If there interest in this use case, further work is required on the
necessary extensions.
2.5 Live Content using Multicast 2.5 Live Content using Multicast
This use case does in its simplest form do not require any use of This use case in its simplest form does not require any use of RTSP
RTSP at all. This is what multicast conferences being announced with at all; this is what multicast conferences being announced with SAP
SAP and SDP are intended to handle. However in use cases where more and SDP are intended to handle. However in use cases where more
advance features like access control to the multicast session is advanced features like access control to the multicast session are
desired, RTSP could be used for session establishment. A client desired, RTSP could be used for session establishment.
desiring to join a live multicasted media session with cryptographic
(encryption) access control could use RTSP in the following way. The A client desiring to join a live multicasted media session with
source of the session, announces the session and gives all interested cryptographic (encryption) access control could use RTSP in the
to join, a RTSP URI. The client connects to the server and requests following way. The source of the session announces the session and
the presentation description allowing for configuration the gives all interested an RTSP URI. The client connects to the server
reception. In this step it is possible to use secured transport for and requests the presentation description, allowing configuration for
the client, and also desired levels of authentication, for example reception of the media. In this step it is possible for the client to
for charging purposes or simply access control. An RTSP link also use secured transport and any desired level of authentication; for
allows for load balancing between multiple servers. However if this example, for billing or access control. An RTSP link also allows for
was the only thing that occurred it could probably be solved as load balancing between multiple servers.
simply using HTTP. However for session where the sender likes to keep
track of each individual receiver during the session, and possibly If these were the only goals, they could be achieved by simply using
use this side channel for pushing out key-updates or other side HTTP. However, for cases where the sender likes to keep track of
information that is desirable to be done on a per receiver basis, and each individual receiver of a session, and possibly use the session
the receivers are not know prior to the session start, the state as a side channel for distributing key-updates or other information
establishment that RTSP provides can be beneficial. In this case a on a per-receiver basis, and the full set of receivers is not know
client would establish a RTSP session to the multicast group. The prior to the session start, the state establishment that RTSP
RTSP server will not transmit any media, instead it will simply point provides can be beneficial. In this case a client would establish an
to the multicast group. However the client and server will be able to RTSP session to the multicast group. The RTSP server will not
keep the session alive for as long as the receiver participates in transmit any media, but instead will point to the multicast group.
the session. Thus enabling, for example server to client pushes of The client and server will be able to keep the session alive for as
updates. This use cases will most likely not be able to actually long as the receiver participates in the session thus enabling, for
implement without some extensions in relation to the server to client example, the server to push updates to the client.
push mechanism. Here a method like ANNOUNCE (see RFC 2326 [28] might
be suitable, however it will require a RTSP extension to revive the This use case will most likely not be able to be implemented without
method. some extensions to the server-to-client push mechanism. Here a method
like ANNOUNCE (see RFC 2326 [25] might be suitable; however, it will
require a RTSP extension to revive the method.
3 Protocol Parameters 3 Protocol Parameters
3.1 RTSP Version 3.1 RTSP Version
HTTP Specification Section [H3.1] applies, with HTTP replaced by HTTP specification section [H3.1] applies, with "HTTP" replaced by
RTSP. This specification defines version 2.0 of RTSP. "RTSP". This specification defines version 2.0 of RTSP.
3.2 RTSP IRI and URI 3.2 RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and
"rtspu". The usage of the last in RTSP 2.0, "rtspu", is unspecified, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is done to register and reserve the URI scheme that is defined by and is defined here to register and reserve the URI scheme that is
RTSP 1.0. The "rtspu" scheme indicate transport of the RTSP messages defined in RTSP 1.0. The "rtspu" scheme indicates transport of the
over unreliable transport (UDP). The syntax of "rtsp" and "rtsps" RTSP messages over unreliable transport (UDP). The syntax of "rtsp"
URIs has been changed compared with RTSP 1.0. and "rtsps" URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [9] that This specification also defines the format of the RTSP IRI [7] that
can used as RTSP resource identifiers and locators, in web pages, can be used as RTSP resource identifiers and locators, in web pages,
user interfaces, on paper, etc. However the RTSP request message user interfaces, on paper, etc. However, the RTSP request message
format does only allow usage of the absolute URI format. The RTSP IRI format only allows usage of the absolute URI format. The RTSP IRI
format SHALL use the rules and transformation for IRIs defined in RFC format SHALL use the rules and transformation for IRIs defined in RFC
3987 [9]. That way RTSP 2.0 URIs for request can be produced from an 3987 [7]. This way RTSP 2.0 URIs for request can be produced from an
RTSP IRI. RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in RFC 3986 [10] and RFC 3987 [9]; generic syntax defined in RFC 3986 [8] and RFC 3987 [7]:
o An absolute URI requires the authority part, i.e. a host o An absolute URI requires the authority part; i.e., a host
identity must be provided. identity must be provided.
o parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
The RTSP URI and IRI is case sensitive, with the exception of those The RTSP URI and IRI is case sensitive, with the exception of those
parts that RFC 3986 [10] and RFC 3987 [9] defines as case- parts that RFC 3986 [8] and RFC 3987 [7] defines as case-insensitive;
insensitive. For example the scheme and host part. for example, the scheme and host part.
The fragment identifier is used as defined in section 4.1 of [10], The fragment identifier is used as defined in sections 3.5 and 4.3 of
i.e. the fragment is to be stripped from the URI by the requestor and [8], i.e. the fragment is to be stripped from the URI by the
not included in the request. The user agent also needs to interpret requestor and not included in the request. The user agent also needs
the value of the fragment based on the media type the request relates to interpret the value of the fragment based on the media type the
to, i.e. the media type indicated in Content-Type header in the request relates to; i.e., the media type indicated in Content-Type
response to DESCRIBE. header in the response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. As it is from the requestor an opaque (usually the server) specific. The query is, from the requestor's
string, it needs to be handled as such. perspective, an opaque string and needs to be handled as such.
The URI scheme rtsp requires that commands are issued via a reliable The URI scheme "rtsp" requires that commands are issued via a
protocol (within the Internet, TCP), while the scheme rtsps reliable protocol (within the Internet, TCP), while the scheme
identifies a reliable transport using secure transport (TLS [11]), "rtsps" identifies a reliable transport using secure transport (TLS
see Section 18. [9], see Section 18).
If the no port number is provided in the authority part of the URI, For the scheme "rtsp", if no port number is provided in the authority
port number 554 SHALL be used. The semantics are that the identified part of the URI port number 554 SHALL be used. For the scheme
resource can be controlled by RTSP at the server listening for TCP "rtsps", the TCP port 322 is registered and SHALL be assumed.
(scheme "rtsp") connections on that port of host, and the Request-URI
for the resource is rtsp_URI. For the scheme rtsps the TCP port 322
is registered and SHALL be assumed.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs identifier, using the character set and escape conventions of URIs
(RFC 3986 [10]). URIs may refer to a stream or an aggregate of (RFC 3986 [8]). URIs may refer to a stream or an aggregate of
streams, i.e., a presentation. Accordingly, requests described in streams; i.e., a presentation. Accordingly, requests described in
Section 11 can apply to either the whole presentation or an Section 11 can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations and vice methods can only be applied to streams, not presentations, and vice
versa. versa.
For example, the RTSP URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com connection to port 554 of host media.example.com
skipping to change at page 25, line 37 skipping to change at page 26, line 4
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com connection to port 554 of host media.example.com
Also, the RTSP URI: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams, but can also be something else like a random media and video streams, but could also be something else like a random
redirector. media redirector.
This does not imply a standard way to reference streams in This does not imply a standard way to reference streams in
URIs. The presentation description defines the hierarchical URIs. The presentation description defines the hierarchical
relationships in the presentation and the URIs for the relationships in the presentation and the URIs for the
individual streams. A presentation description may name a individual streams. A presentation description may name a
stream "a.mov" and the whole presentation "b.mov". stream "a.mov" and the whole presentation "b.mov".
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
skipping to change at page 26, line 24 skipping to change at page 26, line 36
3.4 SMPTE Relative Timestamps 3.4 SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default smpte format is with the origin at the start of the clip. The default smpte format is
"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. "SMPTE 30 drop" format, with frame rate is 29.97 frames per second.
Other SMPTE codes MAY be supported (such as "SMPTE 25") through the Other SMPTE codes MAY be supported (such as "SMPTE 25") through the
use of alternative use of "smpte time". For the "frames" field in the use of alternative use of "smpte-type". For SMPTE 30, the "frames"
time value can assume the values 0 through 29. The difference between field in the time value can assume the values 0 through 29. The
30 and 29.97 frames per second is handled by dropping the first two difference between 30 and 29.97 frames per second is handled by
frame indices (values 00 and 01) of every minute, except every tenth dropping the first two frame indices (values 00 and 01) of every
minute. If the frame value is zero, it may be omitted. Subframes are minute, except every tenth minute. If the frame and the subframe
measured in one-hundredth of a frame. values are zero, they may be omitted. Subframes are measured in one-
hundredth of a frame.
Examples: Examples:
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) [35]. The timestamp consists of with the Network Time Protocol (NTP) [33]. 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 event. It MAY only be used for live events,
type events, and SHALL NOT be used for on-demand content. and SHALL NOT be used for on-demand (i.e., non-live) content.
NPT is defined as in DSM-CC [36]: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC [34]: "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 [37]. The npt-sec notation The syntax conforms to ISO 8601 [35]. The npt-sec notation
is optimized for automatic generation, the ntp-hhmmss is optimized for automatic generation, the npt-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 [37] timestamps, using UTC Absolute time is expressed as ISO 8601 [35] 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
RTSP. These tags are used in Require (Section 14.37), Proxy-Require RTSP. These tags are used in Require (Section 14.37), Proxy-Require
(Section 14.31), Proxy-Supported (Section 14.32), Unsupported (Section 14.31), Proxy-Supported (Section 14.32), Unsupported
(Section 14.46), and Supported (Section 14.43) header fields. (Section 14.46), and Supported (Section 14.43) header fields.
Feature tag needs to indicate which combination of clients, servers, A feature-tag definition MUST indicate which combination of clients,
or proxies they applies too. servers or proxies they applies too.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA), see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 21. IANA Section 21).
The usage of feature tags are further described in section 10 that The usage of feature-tags is further described in section 10 that
deals with capability handling. deals with capability handling.
3.8 Entity Tags 3.8 Entity Tags
Entity tags are opaque strings that are used to compare two entities Entity tags are opaque strings that are used to compare two entities
from the same resource, for example in caches or to optimize setup from the same resource, for example in caches or to optimize setup
after a redirect. Further explanation is present in [H3.11]. For after a redirect. Further explanation is present in [H3.11]. For an
explanation on how to compare Entity tags see [H13.3]. Entity tags explanation of how to compare entity tags see [H13.3]. Entity tags
can be carried in the ETag header (see section 14.21) or in SDP (see can be carried in the ETag header (see section 14.21) or in SDP (see
section C.1.8). section C.1.9).
Entity tags are used in RTSP to make some methods conditional. The Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see methods are made conditional through the inclusion of headers, see
14.24 and 14.26. Note that for RTSP entity tags applies to the 14.24 and 14.26. Note that RTSP entity tags apply to the complete
complete presentation, i.e. both session description, and the presentation; i.e., both the session description and the individual
individual media streams. Thus entity tags can be used to verify at media streams. Thus entity tags can be used to verify at setup time
setup time after a redirect that the same session description applies after a redirect that the same session description applies to the
to the media at the new location using the If-Match header. media at the new location using the If-Match header.
4 RTSP Message 4 RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 3629 [15]). Lines SHALL be terminated by CRLF. UTF-8 encoding (RFC 3629 [13]). Lines SHALL be terminated by CRLF.
Text-based protocols make it easier to add optional Text-based protocols make it easier to add optional
parameters in a self-describing manner. Since the number of parameters in a self-describing manner. Since the number of
parameters and the frequency of commands is low, processing parameters and the frequency of commands is low, processing
efficiency is not a concern. Text-based protocols, if done efficiency is not a concern. Text-based protocols, if done
carefully, also allow easy implementation of research carefully, also allow easy implementation of research
prototypes in scripting languages such as Tcl, Visual Basic prototypes in scripting languages such as Tcl, Visual Basic
and Perl. and Perl.
The 10646 character set avoids tricky character set switching, but is The ISO 10646 character set avoids tricky character set switching,
invisible to the application as long as US-ASCII is being used. This but is invisible to the application as long as US-ASCII is being
is also the encoding used for RTCP. ISO 8859-1 translates directly used. This is also the encoding used for RTCP. ISO 8859-1 translates
into Unicode with a high-order octet of zero. ISO 8859-1 characters directly into Unicode with a high-order octet of zero. ISO 8859-1
with the most-significant bit set are represented as 1100001x characters with the most-significant bit set are represented as
10xxxxxx. (See RFC 3629 [15]) 1100001x 10xxxxxx. (See RFC 3629 [13])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent, parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
4.1 Message Types 4.1 Message Types
See [H4.1]. See [H4.1].
4.2 Message Headers 4.2 Message Headers
See [H4.2]. See [H4.2].
4.3 Message Body 4.3 Message Body
See [H4.3] See [H4.3]
Unlike HTTP, the presence of a message-body in either a request or a
response MUST be signaled by the inclusion of a Content-Length header
field (see section 14.16).
4.4 Message Length 4.4 Message Length
When a message body is included with a message, the length of that When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence): body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body 1. Any response message which MUST NOT include a message body
(such as the 1xx, 204, and 304 responses) is always (such as the 1xx, 204, and 304 responses) is always
terminated by the first empty line after the header fields, terminated by the first empty line after the header fields,
regardless of the entity-header fields present in the regardless of the entity-header fields present in the
message. (Note: An empty line consists of only CRLF.) message. (Note: An empty line is a line with nothing
preceding the CRLF.)
2. If a Content-Length header field (section 14.16) is 2. If a Content-Length header field (section 14.16) is
present, its value in bytes represents the length of the present, its value in bytes represents the length of the
message-body. If this header field is not present, a value message-body. If this header field is not present, a value
of zero is assumed. of zero is assumed.
Unlike an HTTP message, an RTSP message MUST contain a Content-Length Unlike an HTTP message, an RTSP message MUST contain a Content-Length
header field whenever it contains a message body. Note that RTSP does header field whenever it contains a message body. Note that RTSP does
not (at present) support the HTTP/1.1 "chunked" transfer coding(see not support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).
[H3.6.1]).
Given the moderate length of presentation descriptions Given the moderate length of presentation descriptions
returned, the server should always be able to determine its returned, the server should always be able to determine its
length, even if it is generated dynamically, making the length, even if it is generated dynamically, making the
chunked transfer encoding unnecessary. chunked transfer encoding unnecessary.
5 General Header Fields 5 General Header Fields
See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
and Warning headers are not defined. RTSP further defines the CSeq, Upgrade, and Warning headers are not defined. RTSP further defines
and Timestamp. The general headers are listed in table 1: the CSeq, Proxy-Supported and Timestamp headers. The general headers
are listed in table 1:
Header Name Comment Header Name Defined in Section
_________________________________ ___________________________________
Cache-Control See section 14.10 Cache-Control Section 14.10
Connection See section 14.11 Connection Section 14.11
CSeq See section 14.19 CSeq Section 14.19
Date See section 14.20 Date Section 14.20
Supported See section 14.43 Proxy-Supported Section 14.32
Timestamp See section 14.44 Supported Section 14.43
Via See section 14.49 Timestamp Section 14.44
Via Section 14.49
Table 1: The General headers used in RTSP. Table 1: The General headers used in RTSP.
6 Request 6 Request
A request messages uses the format outlined below, regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the o Request line, containing the method to be applied to the
resource, the identifier of the resource, and the protocol resource, the identifier of the resource, and the protocol
version in use; version in use;
o zero or more Header lines, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general (Section 5), request (Section 6.2), or entity (Section general (Section 5), request (Section 6.2), or entity (section
8.1); 8.1);
o One empty line (CR/LF) to indicate the end of the header o One empty line (CRLF) to indicate the end of the header
section; section;
o Optionally a message body (entity), consisting of one or more o Optionally a message body (entity), consisting of one or more
lines. the length of the message body in number of bytes is lines. The length of the message body in bytes is indicated by
indicated by the Content-Length entity header. the Content-Length entity header.
6.1 Request Line 6.1 Request Line
The request line provides the key information about the request: The request line provides the key information about the request:
What method, on what resources and using which RTSP version. The what method, on what resources and using which RTSP version. The
methods that are defined by this specification are listed in Table 2. methods that are defined by this specification are listed in Table 2.
The syntax of the RTSP request line is the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Method Defined In Section Method Defined In Section
_________________________________ _________________________________
DESCRIBE Section 11.2 DESCRIBE Section 11.2
GET_PARAMETER Section 11.7 GET_PARAMETER Section 11.7
OPTIONS Section 11.1 OPTIONS Section 11.1
PAUSE Section 11.5 PAUSE Section 11.5
PLAY Section 11.4 PLAY Section 11.4
REDIRECT Section 11.9 REDIRECT Section 11.9
SETUP Section 11.3 SETUP Section 11.3
SET_PARAMETER Section 11.8 SET_PARAMETER Section 11.8
TEARDOWN Section 11.6 TEARDOWN Section 11.6
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [3], RTSP requests identify the resource In contrast to HTTP/1.1 [3], RTSP requests identify the resource
through an absolute RTSP URI (scheme, host, and port)(see section through an absolute RTSP URI (scheme, host, and port)(see section
3.2) rather than just the absolute path. 3.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, HTTP/1.1 requires servers to understand the absolute URI,
but clients are supposed to use the Host request header. but clients are supposed to use the Host request header.
skipping to change at page 32, line 16 skipping to change at page 32, line 32
OPTIONS rtsp://example.com RTSP/2.0 OPTIONS rtsp://example.com RTSP/2.0
6.2 Request Header Fields 6.2 Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table 3 can be included in a request, as request
headers, to modify the specifics of the request. Some of these headers, to modify the specifics of the request. Some of these
headers may also be used in the response to a request, as response headers may also be used in the response to a request, as response
headers, to modify the specifics of a response (Section 7.2). headers, to modify the specifics of a response (Section 7.2).
Detailed headers definition are provided in Section 14.
New request headers may be defined. If the receiver of the request is
required to understand the request header, the request MUST include a
corresponding feature tag in a Require or Proxy-Require header to
ensure the correct processing of the header.
7 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some
of the HTTP codes. The valid response codes and the methods they can
be used with are listed in Table 4.
After receiving and interpreting a request message, the recipient
Header Defined in Section Header Defined in Section
_____________________________________ ______________________________________
Accept Section 14.1 Accept Section 14.1
Accept-Credentials Section 14.2
Accept-Encoding Section 14.3 Accept-Encoding Section 14.3
Accept-Language Section 14.4 Accept-Language Section 14.4
Authorization Section 14.7 Authorization Section 14.7
Bandwidth Section 14.8 Bandwidth Section 14.8
Blocksize Section 14.9 Blocksize Section 14.9
From Section 14.23 From Section 14.23
If-Match Section 14.24 If-Match Section 14.24
If-Modified-Since Section 14.25 If-Modified-Since Section 14.25
If-None-Match Section 14.26 If-None-Match Section 14.26
Proxy-Require Section 14.31 Proxy-Require Section 14.31
skipping to change at page 32, line 41 skipping to change at page 33, line 30
Require Section 14.37 Require Section 14.37
Scale Section 14.39 Scale Section 14.39
Session Section 14.42 Session Section 14.42
Speed Section 14.40 Speed Section 14.40
Supported Section 14.43 Supported Section 14.43
Transport Section 14.45 Transport Section 14.45
User-Agent Section 14.47 User-Agent Section 14.47
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 14.
New request headers may be defined. If it is required of the receiver
of the request to understand the request header, the request must
include a feature tag in Require or Proxy-Require header representing
the functionality to ensure the correct processing of the header.
7 Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some
of the HTTP codes. The valid response codes and the methods they can
be used with are listed in Table 4.
After receiving and interpreting a request message, the recipient
responds with an RTSP response message. responds with an RTSP response message.
7.1 Status-Line 7.1 Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code, and the of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
final CRLF sequence. final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF
7.1.1 Status Code and Reason Phrase 7.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
skipping to change at page 34, line 34 skipping to change at page 35, line 6
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
7.2 Response Header Fields 7.2 Response Header Fields
The response-header fields allow the request recipient to pass The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the the Status-Line. These header fields give information about the
server and about further access to the resource identified by the server and about further access to the resource identified by the
Request-URI. All headers currently being classified as response Request-URI. All headers currently classified as response headers are
headers are listed in table 5. listed in table 5.
Header Defined in Section
__________________________________________
Accept-Credentials Section 14.2
Accept-Ranges Section 14.5
Connection-Credentials Section 14.12
ETag Section 14.21
Location Section 14.28
Proxy-Authenticate Section 14.29
Public Section 14.33
Range Section 14.34
Retry-After Section 14.36
RTP-Info Section 14.38
Scale Section 14.39
Session Section 14.42
Server Section 14.41
Speed Section 14.40
Transport Section 14.45
Unsupported Section 14.46
Vary Section 14.48
WWW-Authenticate Section 14.50
Table 5: The RTSP response headers
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However the usage combination with a change in the protocol version. However the usage
of feature tags in the request allows the responding party to learn of feature-tags in the request allows the responding party to learn
the capability of the receiver of the response. New or experimental the capability of the receiver of the response. New or experimental
header fields MAY be given the semantics of response-header fields if header fields MAY be given the semantics of response-header fields if
all parties in the communication recognize them to be response-header all parties in the communication recognize them to be response-header
fields. Unrecognized header fields are treated as entity-header fields. Unrecognized header fields in responses are treated as
fields. entity-header fields.
8 Entity 8 Entity
Request and Response messages MAY transfer an entity if not otherwise Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
The SET_PARAMETER, and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY
also have an entity.
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields
Entity-header fields define meta-information about the entity-body
or, if no body is present, about the resource identified by the
request. The entity header fields are listed in table 8.1.
Header Defined in Section
____________________________________
Allow Section 14.6
Content-Base Section 14.13
Content-Encoding Section 14.14
Content-Language Section 14.15
Content-Length Section 14.16
Content-Location Section 14.17
Content-Type Section 14.18
Expires Section 14.22
Last-Modified Section 14.27
Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body
See [H7.2] with the addition that an RTSP message with an entity body
MUST include the Content-Type and Content-Length headers.
9 Connections
RTSP requests can be transmitted over two different connection
scenarios listed below:
Code Reason Method Code Reason Method
__________________________________________________________ __________________________________________________________
100 Continue all 100 Continue all
__________________________________________________________ __________________________________________________________
200 OK all 200 OK all
201 Reserved n/a
250 Reserved n/a
__________________________________________________________ __________________________________________________________
300 Multiple Choices all 300 Multiple Choices all
301 Moved Permanently all 301 Moved Permanently all
302 Found all 302 Found all
303 See Other all 303 See Other all
305 Use Proxy all 305 Use Proxy all
__________________________________________________________ __________________________________________________________
400 Bad Request all 400 Bad Request all
401 Unauthorized all 401 Unauthorized all
skipping to change at page 36, line 49 skipping to change at page 36, line 46
454 Session Not Found all 454 Session Not Found all
455 Method Not Valid In This State all 455 Method Not Valid In This State all
456 Header Field Not Valid all 456 Header Field Not Valid all
457 Invalid Range PLAY, PAUSE 457 Invalid Range PLAY, PAUSE
458 Parameter Is Read-Only SET_PARAMETER 458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all 459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all 460 Only Aggregate Operation Allowed all
461 Unsupported Transport all 461 Unsupported Transport all
462 Destination Unreachable all 462 Destination Unreachable all
463 Destination Prohibited SETUP 463 Destination Prohibited SETUP
464 Data Transport Not Ready Yet PLAY
470 Connection Authorization Required all 470 Connection Authorization Required all
471 Connection Credentials not accepted all 471 Connection Credentials not accepted all
__________________________________________________________ __________________________________________________________
500 Internal Server Error all 500 Internal Server Error all
501 Not Implemented all 501 Not Implemented all
502 Bad Gateway all 502 Bad Gateway all
503 Service Unavailable all 503 Service Unavailable all
504 Gateway Timeout all 504 Gateway Timeout all
505 RTSP Version Not Supported all
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
also have an entity.
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields
Entity-header fields define meta-information about the entity-body
or, if no body is present, about the resource identified by the
request. The entity header fields are listed in table 8.1.
Header Defined in Section Header Defined in Section
__________________________________________ ____________________________________
Accept-Ranges Section 14.5 Allow Section 14.6
Connection-Credentials Section 14.12 Content-Base Section 14.13
ETag Section 14.21 Content-Encoding Section 14.14
Location Section 14.28 Content-Language Section 14.15
Proxy-Authenticate Section 14.29 Content-Length Section 14.16
Public Section 14.33 Content-Location Section 14.17
Range Section 14.34 Content-Type Section 14.18
Retry-After Section 14.36 Expires Section 14.22
RTP-Info Section 14.38 Last-Modified Section 14.27
Scale Section 14.39
Session Section 14.42
Server Section 14.41
Speed Section 14.40
Transport Section 14.45
Unsupported Section 14.46
Vary Section 14.48
WWW-Authenticate Section 14.50
Table 5: The RTSP response headers Table 6: The RTSP entity headers
o persistent - transport connections used for several The extension-header mechanism allows additional entity-header fields
request/response transactions; to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies.
o transient - transport connections used for a single 8.2 Entity Body
See [H7.2] with the addition that an RTSP message with an entity body
MUST include the Content-Type and Content-Length headers.
9 Connections
RTSP requests can be transmitted using the two different connection
scenarios listed below:
o persistent - a transport connection is used for several
request/response transactions;
o transient - a transport connection is used for a single
request/response transaction. request/response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient enough detail to as UDP. However, it was not specified in sufficient detail to allow
allow for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce complexity
complexity and scope, and due to lack of interest, RTSP 2.0 does not and scope, and due to lack of interest, RTSP 2.0 does not attempt to
attempt to define a mechanism for supporting RTSP over UDP or other define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect is that RTSP connectionless transport protocols. A side-effect of this is that
requests SHALL NOT be sent to multicast groups since no connection RTSP requests SHALL NOT be sent to multicast groups since no
can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 14.19), which Certain RTSP headers, such as the CSeq header (Section 14.19), which
may appear to be relevant to only connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful in proxy specification. In the case of CSeq, it is quite useful for matching
situations for keeping track of the different request when responses to requests if the requests are pipelined (see section
aggregating several client requests on a single TCP connection. 9.2). It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP
connection.
9.1 Reliability and Acknowledgements 9.1 Reliability and Acknowledgements
When RTSP messages are transmitted using reliable transport When RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication provide reliability. The RTSP implementation may use any indication
of reception acknowledgement of the message from the underlying of reception acknowledgement of the message from the underlying
transport protocols to optimize the RTSP behavior. transport protocols to optimize the RTSP behavior.
skipping to change at page 38, line 42 skipping to change at page 39, line 18
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST support message exchange). Implementations of this specification MUST support
RTSP over TCP. The scheme of the RTSP URI (Section 3.2) indicates the RTSP over TCP. The scheme of the RTSP URI (Section 3.2) indicates the
default port that the server will listen on. default port that the server will listen on.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault Transient connections facilitate mechanisms for fault
tolerance. They also allow for application layer mobility. tolerance. They also allow for application layer mobility.
A server and client pair that support transient connections A server and client pair that support transient connections
can survive the loss of a TCP connection, e.g. due to a NAT can survive the loss of a TCP connection; e.g., due to a
timeout. When the client has discovered that the TCP NAT timeout. When the client has discovered that the TCP
connection has been lost, it can set up a new one when connection has been lost, it can set up a new one when
there is need to communicate again. there is need to communicate again.
A persistent connection MAY be used for all transactions between the A persistent connection MAY be used for all transactions between the
server and client, including messages for multiple RTSP sessions. server and client, including messages for multiple RTSP sessions.
However a persistent connection MAY also be closed after a few However a persistent connection MAY also be closed after a few
message exchanges. For example, a client may use a persistent message exchanges. For example, a client may use a persistent
connection for the initial SETUP and PLAY message exchanges in a connection for the initial SETUP and PLAY message exchanges in a
session and then close the connection. Later, when the client wishes session and then close the connection. Later, when the client wishes
to send a new request, such as a PAUSE for the session, a new to send a new request, such as a PAUSE for the session, a new
skipping to change at page 39, line 23 skipping to change at page 39, line 46
managing those sessions. managing those sessions.
This saves connection resources on the server. It also This saves connection resources on the server. It also
reduces complexity by and enabling the server to maintain reduces complexity by and enabling the server to maintain
less state about its sessions and connections. less state about its sessions and connections.
Unlike HTTP, RTSP allows a server to send requests to a client. Unlike HTTP, RTSP allows a server to send requests to a client.
However, this can be supported only if a client establishes a However, this can be supported only if a client establishes a
persistent connection with the server. In cases where a persistent persistent connection with the server. In cases where a persistent
connection does not exist between a server and its client, due to the connection does not exist between a server and its client, due to the
lack of a signalling channel, the server may be forced to drop an lack of a signalling channel the server may be forced to drop an RTSP
RTSP session without notifying the client. An example of such a case session without notifying the client. An example of such a case is
is when the server desires to send a REDIRECT request for an RTSP when the server desires to send a REDIRECT request for an RTSP
session to the client but is not able to do so because it cannot session to the client but is not able to do so because it cannot
reach the client. reach the client.
Without a persistent connection between the client and the Without a persistent connection between the client and the
server, the media server has no reliable way of reaching server, the media server has no reliable way of reaching
the client. Also, this is the only way that requests from a the client. Also, this is the only way that requests from a
server to its client are likely to traverse firewalls. server to its client are likely to traverse firewalls.
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
skipping to change at page 40, line 4 skipping to change at page 40, line 26
9.3 Closing Connections 9.3 Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT close managed through the connection. The server, however, SHOULD NOT close
a connection until all RTSP sessions being managed through the a connection until all RTSP sessions being managed through the
connection have been timed out (Section 14.42). A server SHOULD NOT connection have been timed out (Section 14.42). A server SHOULD NOT
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, it should wait for a reasonable amount of
time for the client to: receive the TEARDOWN response, take time for the client to receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection. before closing the connection.
This is to ensure that the client has time to issue a SETUP This is to ensure that the client has time to issue a SETUP
for a new session on the existing connection after having for a new session on the existing connection after having
torn the last one down. 10 seconds should give the client torn the last one down. 10 seconds should give the client
ample opportunity get its message to the server. ample opportunity get its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
skipping to change at page 40, line 34 skipping to change at page 41, line 10
overhead for the client when testing for new features. On overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an the flip side, keeping connections open after sending an
error response poses a Denial of Service security risk error response poses a Denial of Service security risk
(Section 20). (Section 20).
If a server initiates a connection close while the client is If a server initiates a connection close while the client is
attempting to send a new request, the client will have to close its attempting to send a new request, the client will have to close its
current connection, establish a new connection and send its request current connection, establish a new connection and send its request
over the new connection. over the new connection.
An RTSP message should not be terminated through a connection close. An RTSP message should not be terminated by closing the connection.
Such a message will be considered to be incomplete by the receiver Such a message MAY be considered to be incomplete by the receiver and
and discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 4. Section 4.
9.4 Timing Out Connections and RTSP Messages 9.4 Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a Similarly, the sender of a request (requestor) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 response as soon as possible. It than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
SHOULD continue sending a 100 response every 5 seconds thereafter possible. It SHOULD continue sending a 100 response every 5 seconds
until it is ready to send the final response to the requestor. After thereafter until it is ready to send the final response to the
sending a 100 response, the receiver MUST send a final response requestor. After sending a 100 response, the receiver MUST send a
indicating the success or failure of the request. final response indicating the success or failure of the request.
A requestor SHOULD wait at least 10 seconds for a response before A requestor SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requestor SHOULD continue waiting After receiving a 100 response, the requestor SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume that the responder receiving any response, the requestor MAY assume that the responder
is unresponsive and abort the connection. is unresponsive and abort the connection.
A requestor SHOULD wait longer than 10 seconds for a response if it A requestor SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
skipping to change at page 41, line 40 skipping to change at page 42, line 13
This section describes the capability handling mechanism available in This section describes the capability handling mechanism available in
RTSP which allows RTSP to be extended. Extensions to this version of RTSP which allows RTSP to be extended. Extensions to this version of
the protocol are basically done in two ways. First, new headers can the protocol are basically done in two ways. First, new headers can
be added. Secondly, new methods can be added. The capability handling be added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover wether it is supported. This is done by issuing a method to discover wether it is supported. This is done by issuing a
OPTIONS request to the other party. Depending on the URI it will OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response will contain in general, or simply the next hop. The OPTIONS response MUST contain
a Public header which declares all methods supported for the a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
the client could simply try the method. If the receiver of the the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the the method is either not implemented (501) or code indicating the the method is either not implemented (501) or
does not apply for the resource (405). The choice between the two does not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
Feature-Tags are defined to handle functionality additions that are Feature-Tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A feature-tag can for example represents can vary significantly. A feature-tag can for example
represent the functionality a single RTSP header provides. Another represent the functionality a single RTSP header provides. Another
feature-tag can represent much more functionality, such as the feature-tag can represent much more functionality, such as the
"play.basic" feature tag which represents the minimal playback "play.basic" feature-tag which represents the minimal playback
implementation. implementation.
Feature-tags are used to determine wether the client, server or proxy Feature-tags are used to determine wether the client, server or proxy
supports the functionality that is necessary to achieve the desired supports the functionality that is necessary to achieve the desired
service. To determine support of a feature-tag, several different service. To determine support of a feature-tag, several different
headers can be used, each explained below: headers can be used, each explained below:
Supported: The supported header is used to determine the Supported: The supported header is used to determine the
complete set of functionality that both client and server complete set of functionality that both client and server
have. The intended usage is to determine before one needs have. The intended usage is to determine before one needs
skipping to change at page 43, line 28 skipping to change at page 43, line 49
11 Method Definitions 11 Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names SHALL NOT New methods may be defined in the future. Method names SHALL NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 24) and MUST be a token as defined
by the ABNF [4] in the syntax chapter 19. The methods are summarized by the ABNF [4] in the syntax chapter 19. The methods are summarized
in Table 7. in Table 7.
Note on Table 7: GET_PARAMETER is recommended, but not
method direction object Server req. Client req. method direction object Server req. Client req.
___________________________________________________________________ ___________________________________________________________________
DESCRIBE C -> S P,S recommended recommended DESCRIBE C -> S P,S recommended recommended
GET_PARAMETER C -> S, S -> C P,S optional optional GET_PARAMETER C -> S, S -> C P,S optional optional
OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt
PAUSE C -> S P,S required required PAUSE C -> S P,S required required
PLAY C -> S P,S required required PLAY C -> S P,S required required
REDIRECT S -> C P,S optional required REDIRECT S -> C P,S optional required
SETUP C -> S S required required SETUP C -> S S required required
SET_PARAMETER C -> S, S -> C P,S required optional SET_PARAMETER C -> S, S -> C P,S required optional
TEARDOWN C -> S P,S required required TEARDOWN C -> S P,S required required
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Respond, (P: presentation, S: stream) they operate on. Legend: R=Respond,
Sd=Send, Opt: Optional, Req: Required Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GET_PARAMETER is recommended, but not
required. For example, a fully functional server can be required. For example, a fully functional server can be
built to deliver media without any parameters. built to deliver media without any parameters.
SET_PARAMETER is required however due to its usage for SET_PARAMETER is required however due to its usage for
keep-alive. PAUSE is now required due to that it is the keep-alive. PAUSE is now required due to that it is the
only way of getting out of the state machines play state only way of getting out of the state machines play state
without terminating the whole session. without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
skipping to change at page 45, line 39 skipping to change at page 46, line 15
description formats that it understands. The server SHALL respond description formats that it understands. The server SHALL respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/rtsl, application/mheg Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 367 Content-Length: 367
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
m=application 32416 UDP WB m=application 32416 UDP WB
skipping to change at page 54, line 28 skipping to change at page 55, line 6
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 [28] is o The queued play functionality described in RFC 2326 [25] 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 58, line 43 skipping to change at page 59, line 18
parameters for a presentation or stream specified in the URI. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
The method MAY also be used without a body (entity). If the this The method MAY also be used without a body (entity). If the this
request is successful, i.e. a 200 OK response is received, then the request is successful, i.e. a 200 OK response is received, then the
keep-alive timer has been updated. Any non-required header present in keep-alive timer has been updated. Any non-required header present in
such a request may or may not been processed. To allow a client to such a request may or may not been processed. To allow a client to
determine if any such header has been processed, it is necessary to determine if any such header has been processed, it is necessary to
use a feature tag and the Require header. Due to this reason it is use a feature-tag and the Require header. Due to this reason it is
RECOMMENDED that any parameters to be retrieved are sent in the body, RECOMMENDED that any parameters to be retrieved are sent in the body,
rather than using any header. rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
skipping to change at page 66, line 23 skipping to change at page 66, line 44
13.3.2 301 Moved Permanently 13.3.2 301 Moved Permanently
The request resource are moved permanently and resides now at the URI The request resource are moved permanently and resides now at the URI
given by the location header. The user client SHOULD redirect given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
13.3.3 302 Found 13.3.3 302 Found
The requested resource reside temporarily at the URI given by the The requested resource resides temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. Is intended to be used for many types of temporary response. This response is intended to be used for many types of
redirects, e.g. load balancing. It is RECOMMENDED that one set the temporary redirects; e.g., load balancing. It is RECOMMENDED that the
reason phrase to something more meaningful than "Found" in these server set the reason phrase to something more meaningful than
cases. The user client SHOULD redirect automatically to the given "Found" in these cases. The user client SHOULD redirect automatically
URI. This response MUST NOT contain a message-body. to the given URI. This response MUST NOT contain a message-body.
This example shows a client being redirected to a different server:
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
C->S: RTSP/2.0 302 Try Other Server
CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo
13.3.4 303 See Other 13.3.4 303 See Other
This status code SHALL NOT be used in RTSP. However as it was allowed This status code SHALL NOT be used in RTSP. However as it was allowed
to use in RTSP 1.0 (RFC 2326). to use in RTSP 1.0 (RFC 2326).
13.3.5 304 Not Modified 13.3.5 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
14.25) and the requested resource has not been modified, the server 14.25) and the requested resource has not been modified, the server
skipping to change at page 67, line 45 skipping to change at page 68, line 31
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 [28] and is obsolete. This error code was removed from RFC 2326 [25] 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 19 skipping to change at page 70, line 5
the result of a client attempt to place an invalid dest_addr the result of a client attempt to place an invalid dest_addr
parameter in the Transport field. parameter in the Transport field.
13.4.15 463 Destination Prohibited 13.4.15 463 Destination Prohibited
The data transmission channel was not established because the server The data transmission channel was not established because the server
prohibited access to the client address. This error is most likely prohibited access to the client address. This error is most likely
the result of a client attempt to redirect media traffic to another the result of a client attempt to redirect media traffic to another
destination with a dest_addr parameter in the Transport header. destination with a dest_addr parameter in the Transport header.
13.4.16 470 Connection Authorization Required 13.4.16 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet
ready for carrying data. However the responding entity still expects
that the data transmission channel will be established at this point
in time. Note however that this may result in a permanent failure
like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successful established (In
violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment.
13.4.17 470 Connection Authorization Required
The secured connection attempt need user or client authorization The secured connection attempt need user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
13.4.17 471 Connection Credentials not accepted 13.4.18 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
13.5 Server Error 5xx 13.5 Server Error 5xx
13.5.1 551 Option not supported 13.5.1 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
skipping to change at page 69, line 51 skipping to change at page 71, line 5
The general syntax for header fields is covered in Section 4.2 This 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 section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for header fields are meaning, and usage. The syntax definition for header fields are
present in section 19.2.3. Throughout this section, we use [HX.Y] to 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 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[3]. Examples of each header field are given. [3]. Examples of each header field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Tables 9, 10, 11, and 12. 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 "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 73, line 46 skipping to change at page 75, line 4
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.
14.1 Accept 14.1 Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
See [H14.1] for syntax.
Example of use:
Accept: application/example 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
SHALL NOT be changed by any proxy. If the method is "User" the header
contains zero or more of credentials that the client accept. The
header may contain zero credentials in the first RTSP request to a
RTSP server when using the "User" method. This as the client has not
yet received any credentials to accept. Each credential SHALL consist
of one URI identifying the proxy or server, the hash algorithm
identifier, and the hash over that entity's DER encoded certificate
[14] in Base64. All RTSP clients and proxies SHALL implement the
SHA-1 [15] algorithm for computation of the hash of the DER encoded
certificate. The SHA-1 algorithm is identified by the token "sha-1".
The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited.
Example:
Accept-Credentials:User,
"rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M=
14.3 Accept-Encoding
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 77, 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
SHALL NOT be changed by any proxy. If the method is "User" the header
contains zero or more of credentials that the client accept. Each
credential SHALL consist of one URI identifying the proxy or server,
the hash algorithm identifier, and the hash over that entity's DER
encoded certificate [16] in Base64. All RTSP clients and proxies
SHALL implement the SHA-1 [17] algorithm for computation of the hash
of the DER encoded certificate. The SHA-1 algorithm is identified by
the token "sha-1".
The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited.
Example:
Accept-Credentials:User,
"rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M=
14.3 Accept-Encoding
See [H14.3] See [H14.3]
14.4 Accept-Language 14.4 Accept-Language
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
14.5 Accept-Ranges 14.5 Accept-Ranges
skipping to change at page 80, line 50 skipping to change at page 82, line 7
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 [38]. X.509v3 [14] certificate in base64 [36].
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 83, line 4 skipping to change at page 84, line 10
disadvantage that a change in any of the parts results in disadvantage that a change in any of the parts results in
invalidation of all the parts. invalidation of all the parts.
If the ETag is provided both inside the entity, e.g. within the If the ETag is provided both inside the entity, e.g. within the
"a=etag" attribute in SDP, and in the response message, then both "a=etag" attribute in SDP, and in the response message, then both
tags SHALL be identical. It is RECOMMENDED that the ETag is primarily tags SHALL be identical. It is RECOMMENDED that the ETag is primarily
given in the RTSP response message, to ensure that caches can use the given in the RTSP response message, to ensure that caches can use the
ETag without requiring content inspection. However for session ETag without requiring content inspection. However for session
descriptions that are distributed outside of RTSP, for example using descriptions that are distributed outside of RTSP, for example using
HTTP, etc. it will be necessary to include the entity tag in the HTTP, etc. it will be necessary to include the entity tag in the
session description as specified in Section C.1.8. session description as specified in Section C.1.9.
SETUP and DESCRIBE requests can be made conditional upon the ETag SETUP and DESCRIBE requests can be made conditional upon the ETag
using the headers If-Match (Section 14.24) and If-None-Match (Section using the headers If-Match (Section 14.24) and If-None-Match (Section
14.26). 14.26).
14.22 Expires 14.22 Expires
The Expires entity-header field gives a date and time after which the The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
skipping to change at page 85, line 36 skipping to change at page 86, line 43
See [H14.34]. See [H14.34].
14.31 Proxy-Require 14.31 Proxy-Require
The Proxy-Require request-header field is used to indicate proxy- The Proxy-Require request-header field is used to indicate proxy-
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy SHALL use the 551 (Option Not Unsupported header. The proxy SHALL use the 551 (Option Not
Supported) status code in the response. Any feature tag included in Supported) status code in the response. Any feature-tag included in
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 14.37 for more details on the mechanics of this message See Section 14.37 for more details on the mechanics of this message
and a usage example. and a usage example.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
skipping to change at page 86, line 4 skipping to change at page 87, line 8
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 14.37 for more details on the mechanics of this message See Section 14.37 for more details on the mechanics of this message
and a usage example. and a usage example.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
14.32 Proxy-Supported 14.32 Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
SHALL be added by any proxy if the Supported header is present in a SHALL be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the response request. When present in a request, the receiver MUST in the response
copy the received Proxy-Supported header. copy the received Proxy-Supported header.
The Proxy-Supported header field contains a list of feature-tags The Proxy-Supported header field contains a list of feature-tags
applicable to proxies, as described in Section 3.7. The list are the applicable to proxies, as described in Section 3.7. The list are the
intersection of all feature-tags understood by the proxies. To intersection of all feature-tags understood by the proxies. To
achieve an intersection, the proxy adding the Proxy-Supported header achieve an intersection, the proxy adding the Proxy-Supported header
includes all proxy feature-tags it understands. Any proxy receiving a includes all proxy feature-tags it understands. Any proxy receiving a
request with the header, checks the list and removes any feature tag request with the header, checks the list and removes any feature-tag
it do not support. A Proxy-Supported header present in the response it do not support. A Proxy-Supported header present in the response
SHALL NOT be touched by the proxies. SHALL NOT be touched by the proxies.
Example: Example:
C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
skipping to change at page 87, line 30 skipping to change at page 88, line 35
is not desirable for a given proxy. Modification of the is not desirable for a given proxy. Modification of the
Public response header field by the intervening proxies Public response header field by the intervening proxies
ensures that the request sender gets an accurate response ensures that the request sender gets an accurate response
indicating the methods that can be used on the target agent indicating the methods that can be used on the target agent
via the proxy chain. via the proxy chain.
14.34 Range 14.34 Range
The Range header specifies a time range in PLAY (Section 11.4), PAUSE The Range header specifies a time range in PLAY (Section 11.4), PAUSE
(Section 11.5), SETUP (Section 11.3), and REDIRECT (Section 11.9) (Section 11.5), SETUP (Section 11.3), and REDIRECT (Section 11.9)
requests and/or responses. requests and responses.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines smpte (Section 3.4), npt (Section 3.5), and clock (Section defines smpte (Section 3.4), npt (Section 3.5), and clock (Section
3.6) range units. While byte ranges [H14.35.1] and other extended 3.6) range units. While byte ranges [H14.35.1] and other extended
units MAY be used, their behavior is unspecified since they are not units MAY be used, their behavior is unspecified since they are not
normally meaningful in RTSP. Servers supporting the Range header MUST normally meaningful in RTSP. Servers supporting the Range header MUST
understand the NPT range format and SHOULD understand the SMPTE range understand the NPT range format and SHOULD understand the SMPTE range
format. If the Range header is sent in a time format that is not format. If the Range header is sent in a time format that is not
understood, the recipient SHOULD return 456 (Header Field Not Valid understood, the recipient SHOULD return 456 (Header Field Not Valid
for Resource) and include an Accept-Ranges header indicating the for Resource) and include an Accept-Ranges header indicating the
skipping to change at page 97, line 7 skipping to change at page 98, line 14
presentation description. presentation description.
A transport-spec transport option may only contain one of any given A transport-spec transport option may only contain one of any given
parameter within it. Parameters MAY be given in any order. parameter within it. Parameters MAY be given in any order.
Additionally, it may only contain the unicast or the multicast Additionally, it may only contain the unicast or the multicast
transport type parameter. Unknown parameters SHALL be ignored. The transport type parameter. Unknown parameters SHALL be ignored. The
requester need to ensure that the responder understands the requester need to ensure that the responder understands the
parameters through the use of feature tags and the Require header. parameters through the use of feature tags and the Require header.
Any parameters part of future extensions requires clarification if Any parameters part of future extensions requires clarification if
they are safe to ignore in accordance to this specification, or is they are safe to ignore in accordance to this specification, or are
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 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 general syntax for the transport specifier is a list of slash The general syntax for the transport specifier is a list of slash
separated tokens: separated tokens:
Value1/Value2/Value3... Value1/Value2/Value3...
skipping to change at page 98, line 25 skipping to change at page 99, line 32
stream. The layers are sent to consecutive addresses stream. The layers are sent to consecutive addresses
starting at the dest_addr address. If the parameter is not starting at the dest_addr address. If the parameter is not
included, it defaults to a single layer. included, it defaults to a single layer.
dest_addr: A general destination address parameter that can dest_addr: A general destination address parameter that can
contain one or more address specifications. Each contain one or more address specifications. Each
combination of Protocol/Profile/Lower Transport needs to combination of Protocol/Profile/Lower Transport needs to
have the format and interpretation of its address have the format and interpretation of its address
specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, specification defined. For RTP/AVP/UDP and RTP/AVP/TCP,
the address specification is a tuple containing a host the address specification is a tuple containing a host
address and port. address and port. Note, only a single destination entity
per transport spec is intended. The usage of multiple
destination to distribute a single media to multiple
entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
specified, the recipient may be a different party than the specified, the recipient may be a different party than the
originator of the request. To avoid becoming the unwitting originator of the request. To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service perpetrator of a remote-controlled denial-of-service
attack, a server MUST perform security checks (see Section attack, a server MUST perform security checks (see Section
20.1) and SHOULD log such attempts before allowing the 20.1) and SHOULD log such attempts before allowing the
client to direct a media stream to a recipient address not client to direct a media stream to a recipient address not
skipping to change at page 100, line 22 skipping to change at page 101, line 32
server will need to consider what values that are server will need to consider what values that are
reasonable and also the authority of the user to set this reasonable and also the authority of the user to set this
value. value.
RTP-specific: RTP-specific:
These parameters are MAY only be used if the media transport protocol These parameters are MAY only be used if the media transport protocol
is RTP. is RTP.
ssrc: The ssrc parameter, if included in a SETUP response, ssrc: The ssrc parameter, if included in a SETUP response,
indicates the RTP SSRC [18] value(s) that will be used by indicates the RTP SSRC [16] value(s) that will be used by
the media server for RTP packets within the stream. It is the media server for RTP packets within the stream. It is
expressed as an eight digit hexadecimal value. expressed as an eight digit hexadecimal value.
The ssrc parameter SHALL NOT be specified in requests. The The ssrc parameter SHALL NOT be specified in requests. The
functionality of specifying the ssrc parameter in a SETUP functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550 [18]. If the parameter is specification of RTP in RFC 3550 [16]. 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 The parameters defined below MAY only be used if the media transport
protocol if the lower-level transport is connection-oriented (such as protocol if the lower-level transport is connection-oriented (such as
TCP). However, these parameters MUST NOT be used when interleaving TCP). However, these parameters MUST NOT be used when interleaving
data over the RTSP control connection. data over the RTSP control connection.
setup: Clients use the setup parameter on the Transport line in setup: Clients use the setup parameter on the Transport line in
a SETUP request, to indicate the roles it wishes to play in a SETUP request, to indicate the roles it wishes to play in
a TCP connection. This parameter is adapted from [26]. We a TCP connection. This parameter is adapted from [37]. We
discuss the use of this parameter in RTP/AVP/TCP non- discuss the use of this parameter in RTP/AVP/TCP non-
interleaved transport in Appendix B.2.2; the discussion interleaved transport in Appendix B.2.2; the discussion
below is limited to syntactic issues. below is limited to syntactic issues.
Clients may specify the following values for the setup Clients may specify the following values for the setup
parameter: parameter:
"active": The client will initiate an outgoing connection. "active": The client will initiate an outgoing connection.
"passive": The client will accept an incoming connection. "passive": The client will accept an incoming connection.
skipping to change at page 103, line 51 skipping to change at page 105, line 15
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 [39]. The reason for these traversal procedures defined for RTSP 2.0 [38]. The reason for these
recommendations is that any extensions of RTSP resulting in new media recommendations is that any extensions of RTSP resulting in new media
transport protocols or profiles, new parameters etc may fail in a transport protocols or profiles, new parameters etc may fail in a
proxy that isn't maintained. Thus resulting in blocking further proxy that isn't maintained. Thus resulting in blocking further
development of RTSP and its usage. development of RTSP and its usage.
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. There must be definition of how proxies may new RTSP extensions. There must be definition of how proxies may
handle the extension, if it is required to understand it, thus handle the extension, if it is required to understand it, thus
requiring a feature tag to be used in the Proxy-Require header. requiring a feature-tag to be used in the Proxy-Require header.
16 Caching 16 Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data, requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached, typically delivered out-of-band with respect to RTSP, to be cached,
skipping to change at page 106, line 23 skipping to change at page 107, line 34
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
skipping to change at page 108, line 46 skipping to change at page 110, line 13
Host: www.example.com Host: www.example.com
Accept: application/sdp Accept: application/sdp
W->C: HTTP/1.0 200 OK W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 264 Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT Expires: 23 Jan 1998 15:35:06 GMT
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202 o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
e=adm@example.com e=adm@example.com
a=range:npt=0-1:49:34 a=range:npt=0-1:49:34
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
skipping to change at page 111, line 35 skipping to change at page 112, line 44
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Content-base: rtsp://foo.com/test.wav/ Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp Content-type: application/sdp
Content-length: 148 Content-length: 148
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT Expires: 23 Jan 1997 17:00:00 GMT
v=0 v=0
o=- 872653257 872653257 IN IP4 172.16.2.187 o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file s=mu-law wave file
i=audio test i=audio test
t=0 0 t=0 0
a=control: * a=control: *
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:streamid=0 a=control:streamid=0
C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY" dest_addr=":6970"/":6971";mode="PLAY"
skipping to change at page 113, line 31 skipping to change at page 114, line 41
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 182 Content-Length: 182
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Supported: play.basic Supported: play.basic
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202 o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16 c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio a=control: rtsp://live.example.com/concert/audio
a=range:npt=0- a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast Transport: RTP/AVP;multicast
skipping to change at page 115, line 27 skipping to change at page 116, line 37
The RTSP security framework consists of two high level components: The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the transport protection based on TLS, which is independent of RTSP. the transport protection based on TLS, which is independent of RTSP.
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security for HTTP is re-used to a large extent. and HTTP servers, the security for HTTP is re-used to a large extent.
18.1 RTSP and HTTP Authentication 18.1 RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in [12] and also in [H15]. the same usage guidelines as specified in [10] and also in [H15].
Servers SHOULD implement both basic and digest [12] authentication. Servers SHOULD implement both basic and digest [10] authentication.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in environments not provide full control message security. Therefore, in environments
requiring tighter security for the control messages, TLS SHOULD be requiring tighter security for the control messages, TLS SHOULD be
used, see Section 18.2. used, see Section 18.2.
18.2 RTSP over TLS 18.2 RTSP over TLS
RTSP SHALL follow the same guidelines with regards to TLS [9] usage
RTSP SHALL follow the same guidelines with regards to TLS [11] usage as specified for HTTP, see [17]. RTSP over TLS is separated from
as specified for HTTP, see [19]. RTSP over TLS is separated from
unsecured RTSP both on URI level and port level. Instead of using the unsecured RTSP both on URI level and port level. Instead of using the
"rtsp" scheme identifier in the URI, the "rtsps" scheme identifier "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier
MUST be used to signal RTSP over TLS. If no port is given in a URI MUST be used to signal RTSP over TLS. If no port is given in a URI
with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP. with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP.
When a client tries to setup an insecure channel to the server (using When a client tries to setup an insecure channel to the server (using
the "rtsp" URI), and the policy for the resource requires a secure the "rtsp" URI), and the policy for the resource requires a secure
channel, the server SHALL redirect the client to the secure service channel, the server SHALL redirect the client to the secure service
by sending a 301 redirect response code together with the correct by sending a 301 redirect response code together with the correct
Location URI (using the "rtsps" scheme). A user or client MAY upgrade Location URI (using the "rtsps" scheme). A user or client MAY upgrade
skipping to change at page 116, line 32 skipping to change at page 117, line 45
In addition to these recommendations, Section 18.3 gives further In addition to these recommendations, Section 18.3 gives further
recommendations of TLS usage with proxies. recommendations of TLS usage with proxies.
18.3 Security and Proxies 18.3 Security and Proxies
The nature of a proxy is often to act as a "man-in-the-middle", while The nature of a proxy is often to act as a "man-in-the-middle", while
security is often about preventing the existence of a "man-in-the- security is often about preventing the existence of a "man-in-the-
middle". This section provides the clients with the possibility to middle". This section provides the clients with the possibility to
use proxies even when applying secure transports (TLS). The client use proxies even when applying secure transports (TLS). The client
needs to select between using the below specified procedure or using needs to select between using the procedure specified below or using
a TLS connection directly (by-passing any proxies) to the server. The a TLS connection directly (by-passing any proxies) to the server. The
choice may be dependent on policies. choice may be dependent on policies.
There are basically two categories of inspecting proxies, the There are basically two categories of proxies, the transparent
transparent proxies (which the client is not aware of) and the non- proxies (of which the client is not aware) and the non-transparent
transparent proxies (which the client is aware of). An infrastructure proxies (of which the client is aware). An infrastructure based on
based on proxies requires that the trust model is such that both proxies requires that the trust model is such that both client and
client and servers can trust the proxies to handle the RTSP messages servers can trust the proxies to handle the RTSP messages correctly.
correctly. To be able to trust a proxy, the client and server also To be able to trust a proxy, the client and server also needs to be
needs to be aware of the proxy. Hence, transparent proxies cannot aware of the proxy. Hence, transparent proxies cannot generally be
generally be seen as trusted and will not work well with security seen as trusted and will not work well with security (unless they
(unless they work only at transport layer). In the rest of this work only at transport layer). In the rest of this section any
section any reference to proxy will be to a non-transparent proxy, reference to proxy will be to a non-transparent proxy, which inspects
which requires to inspect/manipulate the RTSP messages. or manipulate the RTSP messages.
The HTTP Authentication is built on the assumption of proxies and can HTTP Authentication is built on the assumption of proxies and can
provide user-proxy authentication and proxy-proxy/server provide user-proxy authentication and proxy-proxy/server
authentication in addition to the client-server authentication. authentication in addition to the client-server authentication.
When TLS is applied and a proxy is used, the client will use the When TLS is applied and a proxy is used, the client will connect to
proxy's destination URI address when sending messages. This implies the proxy's address when connecting to any RTSP server. This implies
that for TLS, the client will authenticate the proxy server and not that for TLS, the client will authenticate the proxy server and not
the end server. Note that, when the client checks the server the end server. Note that, when the client checks the server
certificate in TLS, it MUST check the proxy's identity (URI or certificate in TLS, it MUST check the proxy's identity (URI or
possibly other known identity) against the proxy's identity as possibly other known identity) against the proxy's identity as
presented in the proxy's Certificate message. presented in the proxy's Certificate message.
The problem is that for proxy accepted by the client, it needs to be The problem is that for a proxy accepted by the client, the proxy
provided information on which grounds it should accept the next-hop needs to be provided information on which grounds it should accept
certificate. Both the proxy and the user may have rules for this, and the next-hop certificate. Both the proxy and the user may have rules
the user have the possibility to select the desired behavior. To for this, and the user have the possibility to select the desired
handle this case, the Accept-Credentials header (See Section 14.2) is behavior. To handle this case, the Accept-Credentials header (See
used, where the client can force the proxy/proxies to relay back the Section 14.2) is used, where the client can force the proxy/proxies
certificates used by any intermediate proxies as well as the server. to relay back the certificates used by any intermediate proxies as
Given the assumption that the proxies are viewed as trusted, it gives well as the server. Given the assumption that the proxies are viewed
the user a possibility to enforce policies to each trusted proxy of as trusted, it gives the user a possibility to enforce policies to
whether it should accept the next entity in the chain. each trusted proxy of whether it should accept the next entity in the
chain.
A proxy MUST use TLS for the next hop if the RTSP request includes a A proxy MUST use TLS for the next hop if the RTSP request includes a
"rtsps" URI. TLS MAY be applied on intermediate links (e.g. between "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between
client and proxy, or between proxy and proxy), even if the resource client and proxy, or between proxy and proxy), even if the resource
and the end server does not require to use it. and the end server does not require to use it.
18.3.1 Accept-Credentials 18.3.1 Accept-Credentials
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
skipping to change at page 118, line 8 skipping to change at page 119, line 22
proxy, proxy has a out-of-band policy configuration proxy, proxy has a out-of-band policy configuration
mechanism. mechanism.
User, which means that the proxy (or proxies) MUST send User, which means that the proxy (or proxies) MUST send
credential information about the next hop to the client for credential information about the next hop to the client for
authorization. The client can then decide whether the proxy authorization. The client can then decide whether the proxy
should accept the certificate or not. See section 18.3.2 should accept the certificate or not. See section 18.3.2
for further details. for further details.
If the Accept-Credentials header is not included in the RTSP request If the Accept-Credentials header is not included in the RTSP request
from the client, the default method used SHALL be "Proxy". If from the client, then the "Proxy" method SHALL be used as default. If
something else than the "Proxy" method is used, the Accept- an other method than the "Proxy" is to be used, then the Accept-
Credentials header SHALL be included in all of the RTSP request from Credentials header SHALL be included in all of the RTSP request from
the client. This is because it cannot be assumed that the proxy the client. This is because it cannot be assumed that the proxy
always keeps the TLS state or the users previously preference between always keeps the TLS state or the users previously preference between
different RTSP messages (in particular if the time interval between different RTSP messages (in particular if the time interval between
the messages is long). the messages is long).
The "Any" and "Proxy" methods does not require the proxy to provide With the "Any" and "Proxy" methods the proxy will apply the policy as
any specific response, but only apply the policy as defined for defined for respectively method. If the policy do not accept the
respectively method. If the policy do not accept the credentials of credentials of the next hop, the entity SHALL respond with a message
the next hop, the entity SHALL respond with a message using status using status code 471 (Connection Credentials not accepted).
code 471 (Connection Credentials not accepted).
An RTSP request in the direction server to client MUST NOT include An RTSP request in the direction server to client MUST NOT include
the Accept-Credential header. As for the non-secured communication, the Accept-Credential header. As for the non-secured communication,
the possibility for these request depends on the presence of a client the possibility for these request depends on the presence of a client
established connection. However if the server to client request is established connection. However if the server to client request is
in relation to a session established over a TLS secured channel, if in relation to a session established over a TLS secured channel, if
MUST be sent in a TLS secured connection. That secured connection MUST be sent in a TLS secured connection. That secured connection
MUST also be the one used by the last client to server request. If no MUST also be the one used by the last client to server request. If no
such transport connection exist at the time when the server desire to such transport connection exist at the time when the server desire to
send the request, it silently fails. send the request, it silently fails.
skipping to change at page 120, line 27 skipping to change at page 121, line 37
specified in section 2.3 of RFC 4234. specified in section 2.3 of RFC 4234.
19.1 Base Syntax 19.1 Base Syntax
RTSP header field values can be folded onto multiple lines if the RTSP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 [8]. The SWS construct is used when linear white space is 2616 [3]. The SWS construct is used when linear white space is
optional, generally between tokens and separators. optional, generally between tokens and separators.
To separate the header name from the rest of value, a colon is used, To separate the header name from the rest of value, a colon is used,
which, by the above rule, allows whitespace before, but no line which, by the above rule, allows whitespace before, but no line
break, and whitespace after, including a linebreak. The HCOLON break, and whitespace after, including a linebreak. The HCOLON
defines this construct. defines this construct.
OCTET = %x00-FF ; any 8-bit sequence of data OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9" DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127) ; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13 CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10) LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32) SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9) HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQUOTE = %x22 ; US-ASCII double-quote mark (34) DQ = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92) BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace SWS = [LWS] ; sep whitespace
HCOLON = *( SP / HT ) ":" SWS HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE / "," / ";" / ":" / BACKSLASH / DQ
/ "/" / "[" / "]" / "?" / "=" / "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT / "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E) / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials> ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE ) quoted-string = ( DQ *qdtext DQ )
qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <">
quoted-pair = BACKSLASH CHAR quoted-pair = BACKSLASH CHAR
ctext = %x20-27 / %x2A-7D ctext = %x20-27 / %x2A-7D
/ %x80-FF ; any OCTET except CTLs, "(" and ")" / %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ] generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string gen-value = token / host / quoted-string
safe = "$" / "-" / "_" / "." / "+" safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / "," extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")" rtsp-extra = "!" / "*" / "'" / "(" / ")"
skipping to change at page 121, line 36 skipping to change at page 123, line 4
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f" / "a" / "b" / "c" / "d" / "e" / "f"
LHEX = DIGIT / %x61-66 ;lowercase a-f LHEX = DIGIT / %x61-66 ;lowercase a-f
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra
base64 = *base64-unit [base64-pad] base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=") base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/" base64-char = ALPHA / DIGIT / "+" / "/"
SLASH = SWS "/" SWS ; slash SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis RPAREN = SWS ")" SWS ; right parenthesis
COMMA = SWS "," SWS ; comma COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQUOTE ; open double quotation mark LDQUOT = SWS DQ ; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark RDQUOT = DQ SWS ; close double quotation mark
RAQUOT = ">" SWS ; right angle quote RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<" ; left angle quote LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
skipping to change at page 122, line 25 skipping to change at page 123, line 36
RTSP-IRI = schemes ":" IRI-rest RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute / ipath-absolute
/ ipath-noscheme / ipath-noscheme
/ ipath-empty / ipath-empty
iauthority = < As defined in RFC 3987 [9]> iauthority = < As defined in RFC 3987 [7]>
ipath = ipath-abempty ; begins with "/" or is empty ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//" / ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment / ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment / ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters / ipath-empty ; zero characters
ipath-abempty = *( "/" isegment ) ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ] ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment ) ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment ) ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar> ipath-empty = 0<ipchar>
isegment = *ipchar [";" *ipchar] isegment = *ipchar [";" *ipchar]
isegment-nz = 1*ipchar [";" *ipchar] isegment-nz = 1*ipchar [";" *ipchar]
/ ";" *ipchar / ";" *ipchar
isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc])
/ ";" *ipchar-nc / ";" *ipchar-nc
; non-zero-length segment without any colon ":" ; non-zero-length segment without any colon ":"
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@" ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
iquery = < As defined in RFC 3987 [9]> iquery = < As defined in RFC 3987 [7]>
ifragment = < As defined in RFC 3987 [9]> ifragment = < As defined in RFC 3987 [7]>
iunreserved = < As defined in RFC 3987 [9]> iunreserved = < As defined in RFC 3987 [7]>
pct-encoded = < As defined in RFC 3987 [9]> pct-encoded = < As defined in RFC 3987 [7]>
RTSP-URI = schemes ":" URI-rest RTSP-URI = schemes ":" URI-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative RTSP-URI-Ref = RTSP-URI / RTSP-Relative
schemes = "rtsp" / "rtsps" / scheme schemes = "rtsp" / "rtsps" / scheme
scheme = < As defined in RFC 3986 [10]> scheme = < As defined in RFC 3986 [8]>
URI-rest = hier-part [ "?" query ] URI-rest = hier-part [ "?" query ]
hier-part = "//" authority path-abempty hier-part = "//" authority path-abempty
RTSP-Relative = relative-part [ "?" query ] RTSP-Relative = relative-part [ "?" query ]
relative-part = "//" authority path-abempty relative-part = "//" authority path-abempty
/ path-absolute / path-absolute
/ path-noscheme / path-noscheme
/ path-empty / path-empty
authority = < As defined in RFC 3986 [10]> authority = < As defined in RFC 3986 [8]>
query = < As defined in RFC 3986 [10]> query = < As defined in RFC 3986 [8]>
path = path-abempty ; begins with "/" or is empty path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//" / path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment / path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment / path-rootless ; begins with a segment
/ path-empty ; zero characters / path-empty ; zero characters
path-abempty = *( "/" segment ) path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ] path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment ) path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment ) path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar> path-empty = 0<pchar>
skipping to change at page 124, line 33 skipping to change at page 126, line 4
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
19.2.2 Message Syntax 19.2.2 Message Syntax
RTSP-message = Request / Response ; RTSP/2.0 messages RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line ; Section 6.1 Request = Request-Line ; Section 6.1
*( general-header ; Section 5 *( general-header ; Section 5
/ request-header ; Section 6.2 / request-header ; Section 6.2
/ entity-header ) ; Section 8.1 / entity-header ) ; Section 8.1
CRLF CRLF
[ message-body ] ; Section 4.3 [ message-body ] ;
Response = Status-Line ; Section 7.1 Section 4.3 Response = Status-Line ; Section
*( general-header ; Section 5 7.1 *( general-header ; Section
/ response-header ; Section 7.2 5 / response-header ; Section
/ entity-header ) ; Section 8.1 7.2 / entity-header ) ; Section
CRLF 8.1
[ message-body ] ; Section 4.3 CRLF [
message-body ] ; Section 4.3
Request-Line = Method SP Request-URI SP RTSP-Version CRLF Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" ; Section 11.2 Method = "DESCRIBE" ; Section 11.2
/ "GET_PARAMETER" ; Section 11.7 / "GET_PARAMETER" ; Section 11.7
/ "OPTIONS" ; Section 11.1 / "OPTIONS" ; Section 11.1
/ "PAUSE" ; Section 11.5 / "PAUSE" ; Section 11.5
/ "PLAY" ; Section 11.4 / "PLAY" ; Section 11.4
/ "REDIRECT" ; Section 11.9 / "REDIRECT" ; Section 11.9
/ "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 125, line 22 skipping to change at page 126, line 34
/ "TEARDOWN" ; Section 11.6 / "TEARDOWN" ; Section 11.6
/ extension-method / extension-method
extension-method = token extension-method = token
Request-URI = "*" / RTSP-URI Request-URI = "*" / RTSP-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
message-body = 1*OCTET message-body = 1*OCTET
Status-Code = "100" ; Continue Status-Code = "100" ; Continue
/ "200" ; OK / "200" ; OK
/ "201" ; Created
/ "250" ; Low on Storage Space
/ "300" ; Multiple Choices / "300" ; Multiple Choices
/ "301" ; Moved Permanently / "301" ; Moved Permanently
/ "302" ; Moved Temporarily / "302" ; Found
/ "303" ; See Other / "303" ; See Other
/ "304" ; Not Modified / "304" ; Not Modified
/ "305" ; Use Proxy / "305" ; Use Proxy
/ "400" ; Bad Request / "400" ; Bad Request
/ "401" ; Unauthorized / "401" ; Unauthorized
/ "402" ; Payment Required / "402" ; Payment Required
/ "403" ; Forbidden / "403" ; Forbidden
/ "404" ; Not Found / "404" ; Not Found
/ "405" ; Method Not Allowed / "405" ; Method Not Allowed
/ "406" ; Not Acceptable / "406" ; Not Acceptable
skipping to change at page 126, line 11 skipping to change at page 127, line 25
/ "451" ; Parameter Not Understood / "451" ; Parameter Not Understood
/ "452" ; reserved / "452" ; reserved
/ "453" ; Not Enough Bandwidth / "453" ; Not Enough Bandwidth
/ "454" ; Session Not Found / "454" ; Session Not Found
/ "455" ; Method Not Valid in This State / "455" ; Method Not Valid in This State
/ "456" ; Header Field Not Valid for Resource / "456" ; Header Field Not Valid for Resource
/ "457" ; Invalid Range / "457" ; Invalid Range
/ "458" ; Parameter Is Read-Only / "458" ; Parameter Is Read-Only
/ "459" ; Aggregate operation not allowed / "459" ; Aggregate operation not allowed
/ "460" ; Only aggregate operation allowed / "460" ; Only aggregate operation allowed
/ "461" ; Unsupported transport / "461" ; Unsupported Transport
/ "462" ; Destination unreachable / "462" ; Destination Unreachable
/ "463" ; Destination Prohibited / "463" ; Destination Prohibited
/ "464" ; Data Transport Not Ready Yet
/ "470" ; Connection Authorization Required / "470" ; Connection Authorization Required
/ "471" ; Connection Credentials not accepted / "471" ; Connection Credentials not accepted
/ "500" ; Internal Server Error / "500" ; Internal Server Error
/ "501" ; Not Implemented / "501" ; Not Implemented
/ "502" ; Bad Gateway / "502" ; Bad Gateway
/ "503" ; Service Unavailable / "503" ; Service Unavailable
/ "504" ; Gateway Time-out / "504" ; Gateway Time-out
/ "505" ; RTSP Version not supported / "505" ; RTSP Version not supported
/ "551" ; Option not supported / "551" ; Option not supported
/ extension-code / extension-code
skipping to change at page 127, line 18 skipping to change at page 128, line 31
/ Scale ; Section 14.39 / Scale ; Section 14.39
/ Session ; Section 14.42 / Session ; Section 14.42
/ Speed ; Section 14.40 / Speed ; Section 14.40
/ Supported ; Section 14.43 / Supported ; Section 14.43
/ Transport ; Section 14.45 / Transport ; Section 14.45
/ User-Agent ; Section 14.47 / User-Agent ; Section 14.47
/ extension-header / extension-header
response-header = Accept-Credentials ; Section 14.2 response-header = Accept-Credentials ; Section 14.2
/ Accept-Ranges ; Section 14.5 / Accept-Ranges ; Section 14.5
/ Connection-Creds ; Section 14.12 / Connection-Credentials ; Section 14.12
/ ETag ; Section 14.21 / ETag ; Section 14.21
/ Location ; Section 14.28 / Location ; Section 14.28
/ Proxy-Authenticate ; Section 14.29 / Proxy-Authenticate ; Section 14.29
/ Public ; Section 14.33 / Public ; Section 14.33
/ Range ; Section 14.34 / Range ; Section 14.34
/ Retry-After ; Section 14.36 / Retry-After ; Section 14.36
/ RTP-Info ; Section 14.38 / RTP-Info ; Section 14.38
/ Scale ; Section 14.39 / Scale ; Section 14.39
/ Session ; Section 14.42 / Session ; Section 14.42
/ Server ; Section 14.41 / Server ; Section 14.41
skipping to change at page 128, line 26 skipping to change at page 129, line 36
) *( SEMI m-parameter ) ) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." *3DIGIT ] ) qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] ) / ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF
cred-decision = ("User" COMMA [cred-info]) cred-decision = ("User" COMMA [cred-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ token ; For future extensions / token ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data) cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-URI DQUOTE SEMI hash-alg SEMI base64 cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64
hash-alg = "sha-1" / extension-alg hash-alg = "sha-1" / extension-alg
extension-alg = token extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ] [ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param) encoding = codings *(SEMI accept-param)
codings = content-coding / "*" codings = content-coding / "*"
content-coding = token content-coding = token
Accept-Language = "Accept-Language" HCOLON Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ] [ language *(COMMA language) ]
language = language-range *(SEMI accept-param) language = language-range *(SEMI accept-param)
skipping to change at page 130, line 48 skipping to change at page 132, line 12
/ "Thu" / "Fri" / "Sat" / "Sun" / "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr" month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug" / "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec" / "Sep" / "Oct" / "Nov" / "Dec"
ETag = "ETag" HCOLON entity-tag ETag = "ETag" HCOLON entity-tag
Expires = "Expires" HCOLON delta-seconds Expires = "Expires" HCOLON delta-seconds
From = "From" HCOLON from-spec From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-URI / absolute-URI addr-spec = RTSP-URI / absolute-URI
absolute-URI = < As defined in RFC 3986 [10]> absolute-URI = < As defined in RFC 3986 [8]>
display-name = *(token LWS)/ quoted-string display-name = *(token LWS)/ quoted-string
from-param = tag-param / generic-param from-param = tag-param / generic-param
tag-param = "tag" EQUAL token tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) If-Match = "If-Match" HCOLON ( "*" / entity-tag-list)
entity-tag-list = entity-tag *(COMMA entity-tag) entity-tag-list = entity-tag *(COMMA entity-tag)
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = "W/" weak = "W/"
opaque-tag = quoted-string opaque-tag = quoted-string
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list)
skipping to change at page 131, line 42 skipping to change at page 133, line 6
*("," qop-value) RDQUOT *("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token qop-value = "auth" / "auth-int" / token
Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF
*(COMMA feature-tag) *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON feature-tag Proxy-Supported = "Proxy-Supported" HCOLON feature-tag
*(COMMA feature-tag) CRLF *(COMMA feature-tag) CRLF
Public = "Public" HCOLON Method *(COMMA Method) CRLF Public = "Public" HCOLON Method *(COMMA Method) CRLF
Range = "Range" HCOLON ranges-list [exec-time] CRLF Range = "Range" HCOLON ranges-list [exec-time] CRLF
ranges-list = ranges-spec *(COMMA ranges-spec) ranges-list = ranges-spec *(COMMA ranges-spec)
exec-time = SEMI "time" EQUAL utc-time exec-time = SEMI "time" EQUAL utc-time
ranges-spec = npt-range / utc-range / smpte-range / range-ext ranges-spec = npt-range / utc-range / smpte-range
/ range-ext
range-ext = extension-format "=" range-value range-ext = extension-format "=" range-value
range-value = 1*(rtsp-unreserved / quoted-string / ":" ) range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referer = "Referer" HCOLON RTSP-URI-Ref Referer = "Referer" HCOLON RTSP-URI-Ref
Require = "Require" HCOLON feature-tag-list CRLF Require = "Require" HCOLON feature-tag-list CRLF
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
RTP-Info = "RTP-Info" HCOLON rtsp-info-spec RTP-Info = "RTP-Info" HCOLON rtsp-info-spec
*(COMMA rtsp-info-spec) CRLF *(COMMA rtsp-info-spec) CRLF
rtsp-info-spec = stream-url 1*ssrc-parameter rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE RTSP-URI-Ref DQUOTE stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter) ri-parameter *(SEMI ri-parameter)
ri-parameter = "seq" EQUAL 1*DIGIT ri-parameter = "seq" EQUAL 1*DIGIT
/ "rtptime" EQUAL 1*DIGIT / "rtptime" EQUAL 1*DIGIT
Retry-After = "Retry-After" HCOLON delta-seconds Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param ) [ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds) retry-param = ("duration" EQUAL delta-seconds)
/ generic-param / generic-param
Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF
skipping to change at page 133, line 15 skipping to change at page 134, line 26
/ 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 "setup" EQUAL contrans-setup
/ SEMI "connection" EQUAL contrans-con / SEMI "connection" EQUAL contrans-con
contrans-setup = "active" / "passive" / "actpass" contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing" 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 / DQ *TEXT DQ)
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 = ( DQ mode *(COMMA mode) DQ )
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 = DQ (host-port / extension-addr) DQ
host-port = host [":" port] host-port = host [":" port]
/ ":" port / ":" port
extension-addr = 1*qdtext extension-addr = 1*qdtext
host = < As defined in RFC 3986 [10]> host = < As defined in RFC 3986 [8]>
port = < As defined in RFC 3986 [10]> port = < As defined in RFC 3986 [8]>
Unsupported = "Unsupported" HCOLON feature-tag-list CRLF Unsupported = "Unsupported" HCOLON feature-tag-list CRLF
User-Agent = "User-Agent" HCOLON ( product / comment ) User-Agent = "User-Agent" HCOLON ( product / comment )
0*(LWS (product / comment)) CRLF 0*(LWS (product / comment)) CRLF
Vary = "Vary" HCOLON ( "*" / field-name-list) Vary = "Vary" HCOLON ( "*" / field-name-list)
field-name-list = field-name *(COMMA field-name) field-name-list = field-name *(COMMA field-name)
field-name = token field-name = token
Via = "Via" HCOLON via-parm *(COMMA via-parm) Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr via-params = via-ttl / via-maddr
/ via-received / via-branch / via-received / via-branch
/ via-extension / via-extension
via-ttl = "ttl" EQUAL ttl via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address) via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986 [10]> IPv4address = < As defined in RFC 3986 [8]>
IPv6address = < As defined in RFC 3986 [10]> IPv6address = < As defined in RFC 3986 [8]>
via-branch = "branch" EQUAL token via-branch = "branch" EQUAL token
via-extension = generic-param via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot SLASH transport-prot
protocol-name = "RTSP" / token protocol-name = "RTSP" / token
protocol-version = token protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token other-transport = token
sent-by = host [ COLON port ] sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
skipping to change at page 135, line 31 skipping to change at page 136, line 44
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
[40], future HTTP specifications may provide additional guidance on [39], future HTTP specifications may provide additional guidance on
security issues. security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service opportunity for a remote-controlled denial-of-service
attack. See Section 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
possible for a malicious client to issue requests with possible for a malicious client to issue requests with
random session identifiers which would affect unsuspecting random session identifiers which would affect unsuspecting
clients. The server SHOULD use a large, random and non- clients. The server SHOULD use a large, random and non-
sequential session identifier to minimize the possibility sequential session identifier to minimize the possibility
of this kind of attack. For real session security, client of this kind of attack. For real session security, client
authentication needs to be performed. authentication needs to be performed.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[12] authentication. In environments requiring tighter [10] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS (RFC 2246 [11]) SHOULD be used. mechanism TLS (RFC 4346 [9]) SHOULD be used.
Stream issues: RTSP only provides for stream control. Stream Stream issues: RTSP only provides for stream control. Stream
delivery issues are not covered in this section, nor in the delivery issues are not covered in this section, nor in the
rest of this draft. RTSP implementations will most likely rest of this draft. RTSP implementations will most likely
rely on other protocols such as RTP, IP multicast, RSVP and rely on other protocols such as RTP, IP multicast, RSVP and
IGMP, and should address security considerations brought up IGMP, and should address security considerations brought up
in those and other applicable specifications. in those and other applicable specifications.
Persistently suspicious behavior: RTSP servers SHOULD return Persistently suspicious behavior: RTSP servers SHOULD return
error code 403 (Forbidden) upon receiving a single instance error code 403 (Forbidden) upon receiving a single instance
skipping to change at page 137, line 20 skipping to change at page 138, line 32
itself and the credentials passed along to the server. However, in itself and the credentials passed along to the server. However, in
certain cases, such as when recipient address is a multicast group, certain cases, such as when recipient address is a multicast group,
or when the recipient is unable to communicate with the server in an or when the recipient is unable to communicate with the server in an
out-of-band manner, this may not be possible. In these cases server out-of-band manner, this may not be possible. In these cases server
may chose another method such as a server-resident authorization list may chose another method such as a server-resident authorization list
to ensure that the request originator has the proper credentials to to ensure that the request originator has the proper credentials to
request stream delivery to the recipient. request stream delivery to the recipient.
One solution that performs the necessary verification of acceptance One solution that performs the necessary verification of acceptance
of media suitable for unicast based delivery is the ICE based NAT of media suitable for unicast based delivery is the ICE based NAT
traversal method described in [39]. By using random passwords and traversal method described in [38]. By using random passwords and
username the probability of unintended indication as a valid media username the probability of unintended indication as a valid media
destination is very low. If the server include in its STUN requests a destination is very low. If the server include in its STUN requests a
cookie (consisting of random material) that is the destination echo cookie (consisting of random material) that is the destination echo
back the solution is also safe against having a off-path attacker back the solution is also safe against having a off-path attacker
being able to spoof the STUN checks. Leaving this solution vulnerable 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 only to on-path attackers that can see the STUN requests go to the
target of attack. target of attack.
For delivery to multicast addresses there is need for another For delivery to multicast addresses there is need for another
solution which is not specified here. 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 sets up a number of registries for RTSP 2.0 that should
maintained by IANA. For each registry there is a description on what be maintained by IANA. For each registry there is a description on
it is required to contain, what specification is needed when adding a what it is required to contain, what specification is needed when
entry with IANA, and finally the entries that this document needs to adding a entry with IANA, and finally the entries that this document
register. See also the section 1.6 "Extending RTSP". There is also an needs to register. See also the section 1.6 "Extending RTSP". There
IANA registration of two SDP attributes. is also an IANA registration of two SDP attributes.
The sections describing how to register an item uses some of the The sections describing how to register an item uses some of the
requirements level described in RFC 2434 [20], namely "First Come, requirements level described in RFC 2434 [18], namely "First Come,
First Served", "Specification Required", and "Standards Action". First Served", "Specification Required", and "Standards Action".
A registration request to IANA MUST contain the following A registration request to IANA MUST contain the following
information: information:
o A name of the item to register according to the rules o A name of the item to register according to the rules
specified by the intended registry. specified by the intended registry.
o Indication of who has change control over the feature (for o Indication of who has change control over the feature (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
skipping to change at page 138, line 35 skipping to change at page 139, line 47
The usage of feature-tags is explained in section 10 and 11.1. The usage of feature-tags is explained in section 10 and 11.1.
21.1.2 Registering New Feature-tags with IANA 21.1.2 Registering New Feature-tags with IANA
The registering of feature-tags is done on a first come, first served The registering of feature-tags is done on a first come, first served
basis. basis.
The name of the feature MUST follow these rules: The name may be of The name of the feature MUST follow these rules: The name may be of
any length, but SHOULD be no more than twenty characters long. The any length, but SHOULD be no more than twenty characters long. The
name MUST NOT contain any spaces, or control characters. The name MUST NOT contain any spaces, or control characters. The
registration SHALL indicate if the feature tag applies to clients, registration SHALL indicate if the feature-tag applies to clients,
servers, or proxies only or any combinations of these. Any servers, or proxies only or any combinations of these. Any
proprietary feature SHALL have as the first part of the name a vendor proprietary feature SHALL have as the first part of the name a vendor
tag, which identifies the organization. tag, which identifies the organization.
21.1.3 Registered entries 21.1.3 Registered entries
The following feature-tags are in this specification defined and The following feature-tags are in this specification defined and
hereby registered. The change control belongs to the IETF. hereby registered. The change control belongs to the IETF.
play.basic: The minimal implementation for playback operations play.basic: The minimal implementation for playback operations
according to section D. Applies for both clients, servers according to section D. Applies for both clients, servers
and proxies. and proxies.
play.scale: Support of scale operations for media playback. play.scale: Support of scale operations for media playback.
Applies only for servers. Applies only for servers.
skipping to change at page 141, line 8 skipping to change at page 142, line 18
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 [41]. o x-wap-profile defined in [40].
o x-wap-profile-diff defined in [41]. o x-wap-profile-diff defined in [40].
o x-wap-profile-warning defined in [41]. o x-wap-profile-warning defined in [40].
o x-predecbufsize defined in [41]. o x-predecbufsize defined in [40].
o x-initpredecbufperiod defined in [41]. o x-initpredecbufperiod defined in [40].
o x-initpostdecbufperiod defined in [41]. o x-initpostdecbufperiod defined in [40].
o 3gpp-videopostdecbufsize defined in [41]. o 3gpp-videopostdecbufsize defined in [40].
o 3GPP-Link-Char defined in [41]. o 3GPP-Link-Char defined in [40].
o 3GPP-Adaptation defined in [41]. o 3GPP-Adaptation defined in [40].
o 3GPP-QoE-Metrics defined in [41]. o 3GPP-QoE-Metrics defined in [40].
o 3GPP-QoE-Feedback defined in [41]. o 3GPP-QoE-Feedback defined in [40].
The use of "X-" is NOT RECOMMENDED but the above headers in the The use of "X-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
21.5 Transport Header registries 21.5 Transport Header registries
The transport header contains a number of parameters which have The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these possibilities for future extensions. Therefore registries for these
needs to be defined. needs to be defined.
skipping to change at page 142, line 8 skipping to change at page 143, line 19
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 syntax 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 the following values: This specification registers the following values:
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
conferences with minimal control" [2] over UDP. The usage is conferences with minimal control" [2] over UDP. The usage is
explained in RFC XXXX, appendix B.1. explained in RFC XXXX, appendix B.1.
o the same as RTP/AVP. o the same as RTP/AVP.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)" [21] over UDP. The usage is explained in Feedback (RTP/AVPF)" [19] over UDP. The usage is explained in
RFC XXXX, appendix B.1. RFC XXXX, appendix B.1.
o the same as RTP/AVPF. o the same as RTP/AVPF.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the "The Secure Real-time Transport Protocol combination with the "The Secure Real-time Transport Protocol
(SRTP)" [22] over UDP. The usage is explained in RFC XXXX, (SRTP)" [20] over UDP. The usage is explained in RFC XXXX,
appendix B.1. appendix B.1.
o the same as RTP/SAVP. o the same as RTP/SAVP.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the " [6] over UDP. The usage is explained in combination with the " [6] over UDP. The usage is explained in
RFC XXXX, appendix B.1. RFC XXXX, appendix B.1.
o the same as RTP/SAVPF. o the same as RTP/SAVPF.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
conferences with minimal control" [2] over TCP. The usage is conferences with minimal control" [2] over TCP. The usage is
explained in RFC XXXX, appendix B.2.2. explained in RFC XXXX, appendix B.2.2.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)" [21] over TCP. The usage is explained in Feedback (RTP/AVPF)" [19] over TCP. The usage is explained in
RFC XXXX, appendix B.2.2. RFC XXXX, appendix B.2.2.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the "The Secure Real-time Transport Protocol combination with the "The Secure Real-time Transport Protocol
(SRTP)" [22] over TCP. The usage is explained in RFC XXXX, (SRTP)" [20] over TCP. The usage is explained in RFC XXXX,
appendix B.2.2. appendix B.2.2.
o Use of the RTP [18] protocol for media transport in o Use of the RTP [16] protocol for media transport in
combination with the " [6] over TCP. The usage is explained in combination with the " [6] over TCP. The usage is explained in
RFC XXXX, appendix B.2.2. RFC XXXX, appendix B.2.2.
21.5.2 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.
skipping to change at page 145, line 40 skipping to change at page 147, line 4
registered, but moderation should be applied as it makes registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the interoperability more difficult. A registration SHALL fulfill the
following requirements: following requirements:
o A publicly available standards document o A publicly available standards document
o A ABNF definition of the range format that fulfills the o A ABNF definition of the range format that fulfills the
"range-ext" definition. "range-ext" definition.
o A Contact person for the registration o A Contact person for the registration
o Rules for how one handles the range when using a negative o Rules for how one handles the range when using a negative
Scale. Scale.
21.9 URI Schemes 21.9 URI Schemes
This specification defines two URI schemes ("rtsp" and "rtsps") and This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). Registrations are following RFC 4395 reserves a third one ("rtspu"). Registrations are following RFC 4395
[23]. [41].
21.9.1 The rtsp URI Scheme 21.9.1 The rtsp URI Scheme
URI scheme name: rtsp URI scheme name: rtsp
Status: Permanent Status: Permanent
URI scheme syntax: See Section 19.2.1 of RFC XXXX. URI scheme syntax: See Section 19.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate URI scheme semantics: The rtsp scheme is used to indicate
resources accessible through the usage of the Real-time resources accessible through the usage of the Real-time
Streaming Protocol (RTSP). RTSP allows different operations Streaming Protocol (RTSP). RTSP allows different operations
on the resource identified by the URI, but the primary on the resource identified by the URI, but the primary
purpose is the streaming delivery of the resource to a purpose is the streaming delivery of the resource to a
client. However the operations that are currently defined client. However the operations that are currently defined
skipping to change at page 151, line 30 skipping to change at page 152, line 40
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
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 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 153, line 7 skipping to change at page 154, line 16
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 154, line 9 skipping to change at page 155, line 18
B Media Transport Alternatives B Media Transport Alternatives
This section defines how certain combinations of protocols, profiles This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
Transport header's source and destination address parameters Transport header's source and destination address parameters
"src_addr" and "dest_addr". "src_addr" and "dest_addr".
B.1 RTP B.1 RTP
This section defines the interaction of RTSP with respect to the RTP This section defines the interaction of RTSP with respect to the RTP
protocol [18]. It also defines any necessary media transport protocol [16]. It also defines any necessary media transport
signalling with regards to RTP. signalling with regards to RTP.
The available RTP profiles and lower layer transports are described The available RTP profiles and lower layer transports are described
below along with rules on signalling the available combinations. below along with rules on signalling the available combinations.
B.1.1 AVP B.1.1 AVP
The usage of the "RTP Profile for Audio and Video Conferences with The usage of the "RTP Profile for Audio and Video Conferences with
Minimal Control" [2] when using RTP for media transport over Minimal Control" [2] when using RTP for media transport over
different lower layer transport protocols is defined below in regards different lower layer transport protocols is defined below in regards
skipping to change at page 154, line 32 skipping to change at page 155, line 41
One such case is defined within this document, the use of embedded One such case is defined within this document, the use of embedded
(interleaved) binary data as defined in section 12. The usage of (interleaved) binary data as defined in section 12. The usage of
this method is indicated by include the "interleaved" parameter. this method is indicated by include the "interleaved" parameter.
When using embedded binary data the "src_addr" and "dest_addr" SHALL When using embedded binary data the "src_addr" and "dest_addr" SHALL
NOT be used. This addressing and multiplexing is used as defined with NOT be used. This addressing and multiplexing is used as defined with
use of channel numbers and the interleaved parameter. use of channel numbers and the interleaved parameter.
B.1.2 AVP/UDP B.1.2 AVP/UDP
This part describes sending of RTP [18] over lower transport layer This part describes sending of RTP [16] over lower transport layer
UDP [13] according to the profile "RTP Profile for Audio and Video UDP [11] according to the profile "RTP Profile for Audio and Video
Conferences with Minimal Control" defined in RFC 3551 [2]. This Conferences with Minimal Control" defined in RFC 3551 [2]. This
profiles requires one or two uni- or bi-directional UDP flows per profiles requires one or two uni- or bi-directional UDP flows per
media stream. The first UDP flow is for RTP and the second is for media stream. The first UDP flow is for RTP and the second is for
RTCP. Embedding of RTP data with the RTSP messages, in accordance RTCP. Embedding of RTP data with the RTSP messages, in accordance
with section 12, SHOULD NOT be performed when RTSP messages are with section 12, SHOULD NOT be performed when RTSP messages are
transported over unreliable transport protocols, like UDP [13]. transported over unreliable transport protocols, like UDP [11].
The RTP/UDP and RTCP/UDP flows can be established using the Transport The RTP/UDP and RTCP/UDP flows can be established using the Transport
header's "src_addr", and "dest_addr" parameters. header's "src_addr", and "dest_addr" parameters.
In RTSP PLAY mode, the transmission of RTP packets from client to In RTSP PLAY mode, the transmission of RTP packets from client to
server is unspecified. The behavior in regards to such RTP packets server is unspecified. The behavior in regards to such RTP packets
MAY be defined in future. MAY be defined in future.
The "src_addr" and "dest_addr" parameters are used in the following The "src_addr" and "dest_addr" parameters are used in the following
way for media playback, i.e. Mode=PLAY: way for media playback, i.e. Mode=PLAY:
skipping to change at page 155, line 42 skipping to change at page 156, line 51
sent to the address and port given by the first address and sent to the address and port given by the first address and
port pair of the "src_addr" parameter. port pair of the "src_addr" parameter.
o RTP and RTCP Packets SHOULD be sent from the corresponding o RTP and RTCP Packets SHOULD be sent from the corresponding
receiver port, i.e. RTCP packets from server should be sent receiver port, i.e. RTCP packets from server should be sent
from the "src_addr" parameters second address port pair. from the "src_addr" parameters second address port pair.
B.1.3 AVPF/UDP B.1.3 AVPF/UDP
The RTP profile "Extended RTP Profile for RTCP-based Feedback The RTP profile "Extended RTP Profile for RTCP-based Feedback
(RTP/AVPF)" [21] MAY be used as RTP profiles in session using RTP. (RTP/AVPF)" [19] MAY be used as RTP profiles in session using RTP.
All that is defined for AVP SHALL also apply for AVPF. All that is defined for AVP SHALL also apply for AVPF.
The usage of AVPF is indicated by the media initialization protocol The usage of AVPF is indicated by the media initialization protocol
used. In the case of SDP it is indicated by media lines (m=) used. In the case of SDP it is indicated by media lines (m=)
containing the profile RTP/AVPF. That SDP MAY also contain further containing the profile RTP/AVPF. That SDP MAY also contain further
AVPF related SDP attributes configuring the AVPF session regarding AVPF related SDP attributes configuring the AVPF session regarding
reporting interval and feedback messages that shall be used that reporting interval and feedback messages that shall be used that
SHALL be followed. SHALL be followed.
B.1.4 SAVP/UDP B.1.4 SAVP/UDP
The RTP profile "The Secure Real-time Transport Protocol (SRTP)" The RTP profile "The Secure Real-time Transport Protocol (SRTP)"
[22] is an RTP profile (SAVP) that MAY be used in RTSP sessions using [20] is an RTP profile (SAVP) that MAY be used in RTSP sessions using
RTP. All that is defined for AVP SHALL also apply for SAVP. RTP. All that is defined for AVP SHALL also apply for SAVP.
The usage of SRTP requires that a security association is The usage of SRTP requires that a security association is
established. The RECOMMENDED mechanism for establishing that security established. The RECOMMENDED mechanism for establishing that security
association is to use MIKEY with RTSP as defined in RFC YYYY [24]. association is to use MIKEY with RTSP as defined in RFC 4567 [21].
B.1.5 SAVPF/UDP B.1.5 SAVPF/UDP
The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [6] is an RTP profile (SAVPF) that MAY be used in RTSP (RTP/SAVPF)" [6] is an RTP profile (SAVPF) that MAY be used in RTSP
sessions using RTP. All that is defined for AVP SHALL also apply for sessions using RTP. All that is defined for AVP SHALL also apply for
SAVPF. SAVPF.
The usage of SRTP requires that a security association is The usage of SRTP requires that a security association is
established. The RECOMMENDED mechanism for establishing that security established. The RECOMMENDED mechanism for establishing that security
association is to use MIKEY [25] with RTSP as defined in RFC YYYY association is to use MIKEY [22] with RTSP as defined in RFC 4567
[24]. [21].
B.2 RTP over TCP B.2 RTP over TCP
Transport of RTP over TCP can be done in two ways, over independent Transport of RTP over TCP can be done in two ways, over independent
TCP connections using RFC WWWW [8] or interleaved in the RTSP control TCP connections using RFC 4571 [23] or interleaved in the RTSP
connection. In both cases the protocol SHALL be "rtp" and the lower control connection. In both cases the protocol SHALL be "rtp" and the
layer SHALL be TCP. The profile may be any of the above specified lower layer SHALL be TCP. The profile may be any of the above
ones; AVP, AVPF, SAVP or SAVPF. specified ones; AVP, AVPF, SAVP or SAVPF.
B.2.1 Interleaved RTP over TCP B.2.1 Interleaved RTP over TCP
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 B.2.2 RTP over independent TCP
In this Appendix, we describe the sending of RTP [18] over lower In this Appendix, we describe the sending of RTP [16] over lower
transport layer TCP [14] according to the profile "RTP Profile for transport layer TCP [12] according to "Framing Real-time Transport
Audio and Video Conferences with Minimal Control" defined in RFC 3551 Protocol (RTP) and RTP Control Protocol (RTCP) Packets over
[2]. This Appendix adapts the guidelines for using RTP over TCP Connection-Oriented Transport" [23]. This Appendix adapts the
within SIP sessions [26] to work with RTSP. guidelines for using RTP over TCP within SIP/SDP [37] to work with
RTSP.
A client codes the support of RTP over independent TCP by specifying A client codes the support of RTP over independent TCP by specifying
an RTP/AVP/TCP transport option on the Transport line of a SETUP an RTP/AVP/TCP transport option without an interleaved parameter in
request that does not used the interleaved parameter. This the Transport line of a SETUP request. This transport option MUST
specification MUST include the "unicast" parameter. include the "unicast" parameter.
If the client wishes to use RTP with RTCP, two ports (or two 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 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 client wishes to use RTP without RTCP, one port (or one address/port
pair) is specified by the dest_addr parameter. Ordering rules of pair) is specified by the dest_addr parameter. Ordering rules of
dest_addr ports follow the rules for RTP/AVP/UDP. dest_addr ports follow the rules for RTP/AVP/UDP.
If the client wishes to play the active role in initiating the TCP 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 connection, it MAY set the "setup" parameter (See section 14.45) on
be "active", or it MAY omit the setup parameter, as active is the the Transport line to be "active", or it MAY omit the setup
default. If the client signals the active role, the ports for all parameter, as active is the default. If the client signals the active
dest_addr values MUST be set to 9 (the discard port). 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 If the client wishes to play the passive role in TCP connection
initiation, it MUST set the "setup" parameter on the Transport line 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 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 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 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 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 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 for RTCP MUST be set to the TCP port number on which the client is
expecting to receive the RTCP stream connection. expecting to receive the RTCP stream connection.
If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a 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 server decides to accept this requested option, the 2xx reply MUST
Transport line that specifies RTP/AVP/TCP (without using the contain a Transport option that specifies RTP/AVP/TCP (without using
interleaved parameter, and with using the unicast parameter). The the interleaved parameter, and with using the unicast parameter). The
dest_addr parameter value MUST be echoed from the parameter value in dest_addr parameter value MUST be echoed from the parameter value in
the client request. the client request unless the destination address (only port) was not
provided in which can the server MAY include the source address of
the RTSP TCP connection with the port number unchanged.
In addition, the server reply MUST set the setup parameter on the In addition, the server reply MUST set the setup parameter on the
Transport line, to indicate the role the server will play in the Transport line, to indicate the role the server will play in the
connection setup. Permissible values are "active" (if a client set connection setup. Permissible values are "active" (if a client set
"setup" to "passive" or "actpass") and "passive" (if a client set "setup" to "passive" or "actpass") and "passive" (if a client set
"setup" to "active" or "actpass"). "setup" to "active" or "actpass").
If a server sets "setup" to "passive", the "src_addr" in the reply 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 MUST indicate the ports the server is willing to receive an RTP
connection and (if the client requested an RTCP connection by connection and (if the client requested an RTCP connection by
specifying two dest_addr ports or address/port pairs) and RTCP specifying two dest_addr ports or address/port pairs) and RTCP
connection. If a server sets "setup" to "passive", the ports connection. If a server sets "setup" to "active", the ports specified
specified in "src_addr" MUST be set to 9. The server MAY use the in "src_addr" MUST be set to 9. The server MAY use the "ssrc"
"ssrc" parameter, following the guidance in 14.45. Port ordering for parameter, following the guidance in 14.45. Port ordering for
src_addr follows the rules for RTP/AVP/UDP. src_addr follows the rules for RTP/AVP/UDP.
After sending (receiving) the first 2xx reply for a SETUP method for For cases when servers have a public IP-address it is RECOMMENDED
a non-interleaved RTP/AVP/TCP URL, the active party SHOULD take steps that the server take the passive role and the client the active role.
to initiate the TCP connection as soon as possible, rather than wait This help in cases when the client is behind a NAT.
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 After sending (receiving) a 2xx reply for a SETUP method for a non-
(or its container file), media begins to flow from server to client interleaved RTP/AVP/TCP media stream, the active party SHOULD
over the RTP TCP connection, and RTCP packets flow bidirectionally initiate the TCP connection as soon as possible. The client SHALL NOT
over the RTCP TCP connection. As in the RTP/UDP case, client-server send a PLAY request prior to the establishment of all the TCP
traffic on the UDP port is unspecified by this memo. The packets that connections negotiated using SETUP for the session. In case the
travel on these connections are framed using the protocol defined in server receives a PLAY request in a session that has not yet
[26], not by the framing defined for interleaving RTP over the RTSP established all the TCP connections, it SHALL respond using the 464
control connection defined in Section 12. "Data Transport Not Ready Yet" (Section 13.4.16) error code.
A successful PAUSE request for a non-interleaved RTP/AVP/TCP URL Once the PLAY request for a media resource transported over non-
pauses the flow of packets over the connections, without closing the interleaved RTP/AVP/TCP occurs, media begins to flow from server to
connections. A successful TEARDOWN request signals that the TCP client over the RTP TCP connection, and RTCP packets flow
connections for RTP and RTCP are to be closed as soon as possible. bidirectionally over the RTCP TCP connection. As in the RTP/UDP case,
client to server traffic on the TCP port is unspecified by this memo.
The packets that travel on these connections SHALL be framed using
the protocol defined in [23], not by the framing defined for
interleaving RTP over the RTSP control connection defined in Section
12.
A successful PAUSE request for a media being transported over
RTP/AVP/TCP 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 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 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 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 continue using the existing TCP RTP and RTCP connections? The client
SHOULD use the "connection" parameter (defined in 14.45) on the SHOULD use the "connection" parameter (defined in 14.45) on the
Transport line to make its intention clear in the regard (by setting 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 "new" if new connections are needed, and by setting
"connection" to "existing" if the existing connections are to be "connection" to "existing" if the existing connections are to be
used). After a 2xx reply for a SETUP request for a new connection, used). After a 2xx reply for a SETUP request for a new connection,
skipping to change at page 159, line 4 skipping to change at page 160, line 25
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
skipping to change at page 159, line 27 skipping to change at page 160, line 49
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9" Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"
setup=active;connection=new setup=active;connection=new
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
src_addr="192.0.2.5:9000"/"192.0.2.5:9001" src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
setup=active;connection=new;ssrc=93CB001E setup=passive;connection=new;ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->M: TCP Connection Establishment
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30- Range: npt=0-10, npt=30-
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
skipping to change at page 160, line 4 skipping to change at page 161, line 26
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"; RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
B.2.3 Handling NPT Jumps in the RTP Media Layer 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[16]. 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.
We cannot assume that the RTSP client can communicate with We cannot assume that the RTSP client can communicate with
the RTP media agent, as the two may be independent the RTP media agent, as the two may be independent
skipping to change at page 162, line 32 skipping to change at page 164, line 12
During a PAUSE / PLAY interaction in an RTSP session, the duration of During a PAUSE / PLAY interaction in an RTSP session, the duration of
time for which the RTP transmission was halted MUST be reflected in time for which the RTP transmission was halted MUST be reflected in
the RTP timestamp of each RTP stream. The duration can be calculated the RTP timestamp of each RTP stream. The duration can be calculated
for each RTP stream as the time elapsed from when the last RTP packet for each RTP stream as the time elapsed from when the last RTP packet
was sent before the PAUSE request was received and when the first RTP was sent before the PAUSE request was received and when the first RTP
packet was sent after the subsequent PLAY request was received. The packet was sent after the subsequent PLAY request was received. The
duration includes all latency incurred and processing time required duration includes all latency incurred and processing time required
to complete the request. to complete the request.
The RTP RFC [18] states that: The RTP timestamp for each The RTP RFC [16] states that: The RTP timestamp for each
unit[packet] would be related to the wallclock time at unit[packet] would be related to the wallclock time at
which the unit becomes current on the virtual presentation which the unit becomes current on the virtual presentation
timeline. timeline.
In order to satisfy the requirements of [18], the RTP timestamp space In order to satisfy the requirements of [16], the RTP timestamp space
needs to increase continuously with real time. While this is not needs to increase continuously with real time. While this is not
optimal for stored media, it is required for RTP and RTCP to function optimal for stored media, it is required for RTP and RTCP to function
as intended. Using a continuous RTP timestamp space allows the same as intended. Using a continuous RTP timestamp space allows the same
timestamp model for both stored and live media and allows better timestamp model for both stored and live media and allows better
opportunity to integrate both types of media under a single control. opportunity to integrate both types of media under a single control.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of interval of 100 ms and an initial sequence number and timestamp of
zero. zero.
skipping to change at page 164, line 29 skipping to change at page 166, line 5
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 [28], this matter was not clearly defined and was Note: In RFC 2326 [25], 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 42 skipping to change at page 167, line 14
sources leave an RTP session, it can, in most cases, be assumed to sources leave an RTP session, it can, in most cases, be assumed to
have ended. Therefore, a client or server SHALL NOT send a RTCP BYE have ended. Therefore, a client or server SHALL NOT send a RTCP BYE
message until it has finished using a SSRC. A server SHOULD keep message until it has finished using a SSRC. A server SHOULD keep
using a SSRC until the RTP session is terminated. Prolonging the use using a SSRC until the RTP session is terminated. Prolonging the use
of a SSRC allows the established synchronization context associated of a SSRC allows the established synchronization context associated
with that SSRC to be used to synchronize subsequent PLAY requests with that SSRC to be used to synchronize subsequent PLAY requests
even if the PLAY response is late. even if the PLAY response is late.
An SSRC collision with the SSRC that transmits media does also have An SSRC collision with the SSRC that transmits media does also have
consequences, as it will force the media sender to change its SSRC in consequences, as it will force the media sender to change its SSRC in
accordance with the RTP specification [18]. This will result in a accordance with the RTP specification [16]. This will result in a
loss of synchronization context, and require any receiver to wait for loss of synchronization context, and require any receiver to wait for
RTCP sender reports for all media requiring synchronization before RTCP sender reports for all media requiring synchronization before
being able to play out synchronized. Due to these reasons a client being able to play out synchronized. Due to these reasons a client
joining a session should take care to not select the same SSRC as the joining a session should take care to not select the same SSRC as the
server. Any SSRC signalled in the Transport header SHOULD be avoided. server. Any SSRC signalled in the Transport header SHOULD be avoided.
A client detecting a collision prior to sending any RTP or RTCP A client detecting a collision prior to sending any RTP or RTCP
messages can also select a new SSRC. messages can also select a new SSRC.
B.3 Future Additions B.3 Future Additions
skipping to change at page 166, line 32 skipping to change at page 167, line 50
o For new media protocols the interaction with RTSP needs to be o For new media protocols the interaction with RTSP needs to be
addressed. One important factor will be the media addressed. One important factor will be the media
synchronization. synchronization.
See the IANA section (21) for information how to register new See the IANA section (21) for information how to register new
attributes. attributes.
C Use of SDP for RTSP Session Descriptions C Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, RFC ZZZZ [1]) may be used to The Session Description Protocol (SDP, RFC 4566 [1]) may be used to
describe streams or presentations in RTSP. This description is describe streams or presentations in RTSP. This description is
typically returned in reply to a DESCRIBE request on an URI from a typically returned in reply to a DESCRIBE request on an URI from a
server to a client, or received via HTTP from a server to a client. server to a client, or received via HTTP from a server to a client.
This appendix describes how an SDP file determines the operation of This appendix describes how an SDP file determines the operation of
an RTSP session. SDP as is provides no mechanism by which a client an RTSP session. SDP as is provides no mechanism by which a client
can distinguish, without human guidance, between several media can distinguish, without human guidance, between several media
streams to be rendered simultaneously and a set of alternatives streams to be rendered simultaneously and a set of alternatives
(e.g., two audio streams spoken in different languages). However the (e.g., two audio streams spoken in different languages). However the
SDP extension "Grouping of Media Lines in the Session Description SDP extension "Grouping of Media Lines in the Session Description
Protocol (SDP)" [42] may provide such functionality depending on Protocol (SDP)" [42] may provide such functionality depending on
need. Also future grouping semantics may in the future be developed. need. Also future grouping semantics may in the future be developed.
C.1 Definitions C.1 Definitions
The terms "session-level", "media-level" and other key/attribute The terms "session-level", "media-level" and other key/attribute
names and values used in this appendix are to be used as defined in names and values used in this appendix are to be used as defined in
SDP (RFC ZZZZ [1]): SDP (RFC 4566 [1]):
C.1.1 Control URI C.1.1 Control URI
The "a=control:" attribute is used to convey the control URI. This The "a=control:" attribute is used to convey the control URI. This
attribute is used both for the session and media descriptions. If attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URI to be used for used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control level, the attribute indicates the URI for aggregate control
(presentation URI). The session level URI SHALL be different from any (presentation URI). The session level URI SHALL be different from any
media level URI. The presence of a session level control attribute media level URI. The presence of a session level control attribute
SHALL be interpreted as support for aggregated control. The control SHALL be interpreted as support for aggregated control. The control
attribute SHALL be present on media level unless the presentation attribute SHALL be present on media level unless the presentation
only contains a single media stream, in which case the attribute MAY only contains a single media stream, in which case the attribute MAY
skipping to change at page 167, line 23 skipping to change at page 168, line 43
only contains a single media stream, in which case the attribute MAY only contains a single media stream, in which case the attribute MAY
only be present on the session level. only be present on the session level.
ABNF for the attribute is defined in section 19.3. ABNF for the attribute is defined in section 19.3.
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 [10]. following the rules and conventions set out in RFC 3986 [8].
Implementations SHALL look for a base URI in the following order: Implementations SHALL look for a base URI in the following order:
1. the RTSP Content-Base field; 1. the RTSP Content-Base field;
2. the RTSP Content-Location field; 2. the RTSP Content-Location field;
3. the RTSP Request-URI. 3. the RTSP Request-URI.
If this attribute contains only an asterisk (*), then the URI SHALL If this attribute contains only an asterisk (*), then the URI SHALL
be treated as if it were an empty embedded URI, and thus inherit the be treated as if it were an empty embedded URI, and thus inherit the
entire base URI. entire base URI.
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example lets assume that a container file has the consideration. For example lets assume that a container file has the
URI: "rtsp://example.com/container.mp4". Lets further assume this URI URI: "rtsp://example.com/container.mp4". Lets further assume this URI
is the base URI, and that there is a absolute media level URI: is the base URI, and that there is a absolute media level URI:
skipping to change at page 167, line 41 skipping to change at page 169, line 15
If this attribute contains only an asterisk (*), then the URI SHALL If this attribute contains only an asterisk (*), then the URI SHALL
be treated as if it were an empty embedded URI, and thus inherit the be treated as if it were an empty embedded URI, and thus inherit the
entire base URI. entire base URI.
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example lets assume that a container file has the consideration. For example lets assume that a container file has the
URI: "rtsp://example.com/container.mp4". Lets further assume this URI URI: "rtsp://example.com/container.mp4". Lets further assume this URI
is the base URI, and that there is a absolute media level URI: is the base URI, and that there is a absolute media level URI:
"rtsp://example.com/container.mp4/trackID=2". A relative media level "rtsp://example.com/container.mp4/trackID=2". A relative media level
URI that resolves in accordance with RFC 3986 [10] to the above given URI that resolves in accordance with RFC 3986 [8] to the above given
media URI is: "container.mp4/trackID=2". It is usually not desirable media URI is: "container.mp4/trackID=2". It is usually not desirable
to need to include in or modify the SDP stored within the container to need to include in or modify the SDP stored within the container
file with the server local name of the container file. To avoid this, file with the server local name of the container file. To avoid this,
one can modify the base URI used to include a trailing slash, e.g. one can modify the base URI used to include a trailing slash, e.g.
"rtsp://example.com/container.mp4/". In this case the relative URI "rtsp://example.com/container.mp4/". In this case the relative URI
for the media will only need to be: "trackID=2". However this will for the media will only need to be: "trackID=2". However this will
also mean that using "*" in the SDP will result in control URI also mean that using "*" in the SDP will result in control URI
including the trailing slash, i.e. including the trailing slash, i.e.
"rtsp://example.com/container.mp4/". "rtsp://example.com/container.mp4/".
Note: The usage of TrackID in the above is not an
standardized form, but one example out of several similar
strings such as TrackID, Track_ID, StreamID that is used by
different server vendors to indicate a particular piece of
media inside a container file.
C.1.2 Media Streams C.1.2 Media Streams
The "m=" field is used to enumerate the streams. It is expected that The "m=" field is used to enumerate the streams. It is expected that
all the specified streams will be rendered with appropriate all the specified streams will be rendered with appropriate
synchronization. If the session is over multicast, the port number synchronization. If the session is over multicast, the port number
indicated SHOULD be used for reception. The client MAY try to indicated SHOULD be used for reception. The client MAY try to
override the destination port, through the Transport header. The override the destination port, through the Transport header. The
servers MAY allow this, the response will indicate if allowed or not. servers MAY allow this, the response will indicate if allowed or not.
If the session is unicast, the port number is the ones RECOMMENDED by If the session is unicast, the port number is the ones RECOMMENDED by
the server to the client, about which receiver ports to use; the the server to the client, about which receiver ports to use; the
skipping to change at page 168, line 43 skipping to change at page 170, line 21
m=audio 0 RTP/AVP 31 m=audio 0 RTP/AVP 31
C.1.3 Payload Type(s) C.1.3 Payload Type(s)
The payload type(s) are specified in the "m=" line. In case the The payload type(s) are specified in the "m=" line. In case the
payload type is a static payload type from RFC 3551 [2], no other payload type is a static payload type from RFC 3551 [2], no other
information may be required. In case it is a dynamic payload type, information may be required. In case it is a dynamic payload type,
the media attribute "rtpmap" is used to specify what the media is. the media attribute "rtpmap" is used to specify what the media is.
The "encoding name" within the "rtpmap" attribute may be one of those The "encoding name" within the "rtpmap" attribute may be one of those
specified in RFC 3551 (Sections 5 and 6), or an MIME type registered specified in RFC 3551 (Sections 5 and 6), or an MIME type registered
with IANA, or an experimental encoding as specified in SDP (RFC ZZZZ with IANA, or an experimental encoding as specified in SDP (RFC 4566
[1]). Codec-specific parameters are not specified in this field, but [1]). Codec-specific parameters are not specified in this field, but
rather in the "fmtp" attribute described below. rather in the "fmtp" attribute described below.
C.1.4 Format-Specific Parameters C.1.4 Format-Specific Parameters
Format-specific parameters are conveyed using the "fmtp" media Format-specific parameters are conveyed using the "fmtp" media
attribute. The syntax of the "fmtp" attribute is specific to the attribute. The syntax of the "fmtp" attribute is specific to the
encoding(s) that the attribute refers to. Note that some of the encoding(s) that the attribute refers to. Note that some of the
format specific parameters may be specified outside of the fmtp format specific parameters may be specified outside of the fmtp
parameters, like for example the "ptime" attribute for most audio parameters, like for example the "ptime" attribute for most audio
encodings. encodings.
C.1.5 Range of Presentation C.1.5 Directionality of media stream
The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
provides instructions on which direction the media streams flow
within a session. When using RTSP the SDP can be delivered to a
client using either RTSP DESCRIBE or a number of RTSP external
methods, like HTTP, FTP, and email. Based on this the SDP applies to
how the RTSP client will see the complete session. Thus for media
streams delivered from the RTSP server to the client would be given
the "a=recvonly" attribute. A a=sendonly in a SDP provided to the
client would indicate that a media stream would be sent from the
client to the server. "a=sendrecv" would indicate media transmission
occurs in both directions between client and server.
The direction attributes are not commonly used in SDPs for RTSP, but
may occur. To reflect this reality the following rules are defined.
"a=recvonly" in a SDP provided to the RTSP client SHALL indicate that
media delivery will only occur in the direction from the server to
the client. Thus an RTSP client shall initiate any RTSP session in
the "PLAY" mode. In SDP provided to the RTSP client that lacks any of
the directionality attributes (a=recvonly, a=sendonly, a=sendrecv)
SHALL behave as if the "a=recvonly" attribute was received. Note that
this overrules the normal default rule defined in SDP [1]. The usage
of "a=sendonly" or "a=sendrecv" is not defined, nor is the
interpretation of SDP by other entities than the RTSP client.
C.1.6 Range of Presentation
The "a=range" attribute defines the total time range of the stored The "a=range" attribute defines the total time range of the stored
session or an individual media. Non-seekable live sessions can be session or an individual media. Non-seekable live sessions can be
indicated, while the length of live sessions can be deduced from the indicated, while the length of live sessions can be deduced from the
"t" and "r" SDP parameters. "t" and "r" SDP parameters.
The attribute is both a session and a media level attribute. For The attribute is both a session and a media level attribute. For
presentations that contains media streams of the same durations, the presentations that contains media streams of the same durations, the
range attribute SHOULD only be used at session-level. In case of range attribute SHOULD only be used at session-level. In case of
different length the range attribute MUST be given at media level for different length the range attribute MUST be given at media level for
all media, and SHOULD NOT be given at session level. If the attribute all media, and SHOULD NOT be given at session level. If the attribute
is present at both media level and session level the media level is present at both media level and session level the media level
values SHALL be used. values SHALL be used.
Note: Usually one will specify the same length for all media, even if Note: Usually one will specify the same length for all media, even if
there isn't media available for the full duration on all media. there isn't media available for the full duration on all media.
However that requires that the server accepts PLAY requests within However that requires that the server accepts PLAY requests within
that range. that range.
Servers SHALL take care to provide RTSP Range (see Section 14.34)
values that are consistent with what is presented in the SDP for the
content. There are no reason for non dynamic content, like media
clips provided on demand to have inconsistent values. Inconsistent
values between the SDP and the actual values for the content handled
by the server is likely to generate some failure, like 457 "Invalid
Range", in case the client uses PLAY requests with a Range header. In
case the content is dynamic in length and it is infeasible to provide
a correct value in the SDP the server is recommended to describe this
as non-seekable content (see below). The server MAY override that
property in the response to a PLAY request using the correct values
in the Range header.
The unit is specified first, followed by the value range. The units The unit is specified first, followed by the value range. The units
and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY
be extended with further formats. Any open ended range (start-), i.e. be extended with further formats. Any open ended range (start-), i.e.
without stop range, is of unspecified duration and SHALL be without stop range, is of unspecified duration and SHALL be
considered as non-seekable content unless this property is considered as non-seekable content unless this property is
overridden. Multiple instances carrying different clock formats MAY overridden. Multiple instances carrying different clock formats MAY
be included at either session or media level. be included at either session or media level.
ABNF for the attribute is defined in section 19.3. ABNF for the attribute is defined in section 19.3.
Examples: Examples:
a=range:npt=0-34.4368 a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203 a=range:clock=19971113T2115-19971113T2203
Non seekable stream of unknown duration: Non seekable stream of unknown duration:
a=range:npt=0- a=range:npt=0-
C.1.6 Time of Availability C.1.7 Time of Availability
The "t=" field MUST contain suitable values for the start and stop The "t=" field MUST contain suitable values for the start and stop
times for both aggregate and non-aggregate stream control. The times for both aggregate and non-aggregate stream control. The
server SHOULD indicate a stop time value for which it guarantees the server SHOULD indicate a stop time value for which it guarantees the
description to be valid, and a start time that is equal to or before description to be valid, and a start time that is equal to or before
the time at which the DESCRIBE request was received. It MAY also the time at which the DESCRIBE request was received. It MAY also
indicate start and stop times of 0, meaning that the session is indicate start and stop times of 0, meaning that the session is
always available. always available.
For sessions that are of live type, i.e. specific start time, unknown For sessions that are of live type, i.e. specific start time, unknown
stop time, likely unseekable, the "t=" and "r=" field SHOULD be used stop time, likely unseekable, the "t=" and "r=" field SHOULD be used
to indicate the start time of the event. The stop time SHOULD be to indicate the start time of the event. The stop time SHOULD be
given so that the live event will have ended at that time, while given so that the live event will have ended at that time, while
still not be unnecessary long into the future. still not be unnecessary long into the future.
C.1.7 Connection Information C.1.8 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 [27]. unspecified address according to RFC 3513 [24].
C.1.8 Entity Tag C.1.9 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.
ABNF for the attribute is defined in section 19.3. ABNF for the attribute is defined in section 19.3.
skipping to change at page 171, line 15 skipping to change at page 173, line 29
C.2 Aggregate Control Not Available C.2 Aggregate Control Not Available
If a presentation does not support aggregate control no session level If a presentation does not support aggregate control no session level
"a=control:" attribute is specified. For a SDP with multiple media "a=control:" attribute is specified. For a SDP with multiple media
sections specified, each section will have its own control URI sections specified, each section will have its own control URI
specified via the "a=control:" attribute. specified via the "a=control:" attribute.
Example: Example:
v=0 v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32 o=- 2890844256 2890842807 IN IP4 192.0.2.56
s=I came from a web page s=I came from a web page
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
t=0 0 t=0 0
m=video 8002 RTP/AVP 31 m=video 8002 RTP/AVP 31
a=control:rtsp://audio.com/movie.aud a=control:rtsp://audio.com/movie.aud
m=audio 8004 RTP/AVP 3 m=audio 8004 RTP/AVP 3
a=control:rtsp://video.com/movie.vid a=control:rtsp://video.com/movie.vid
Note that the position of the control URI in the description implies Note that the position of the control URI in the description implies
skipping to change at page 172, line 4 skipping to change at page 174, line 20
"a=control:" attributes, which are used to specify the stream URIs, "a=control:" attributes, which are used to specify the stream URIs,
and a session-level "a=control:" attribute which is used as the and a session-level "a=control:" attribute which is used as the
Request-URI for aggregate control. If the media-level URI is Request-URI for aggregate control. If the media-level URI is
relative, it is resolved to absolute URIs according to Section C.1.1 relative, it is resolved to absolute URIs according to Section C.1.1
above. above.
Example: Example:
C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1 CSeq: 1
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/ Content-Base: rtsp://example.com/movie/
Content-Length: 228 Content-Length: 228
v=0 v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32 o=- 2890844256 2890842807 IN IP4 192.0.2.211
s=I contain s=I contain
i=<more info> i=<more info>
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
t=0 0 t=0 0
a=control:* a=control:*
m=video 8002 RTP/AVP 31 m=video 8002 RTP/AVP 31
a=control:trackID=1 a=control:trackID=1
m=audio 8004 RTP/AVP 3 m=audio 8004 RTP/AVP 3
a=control:trackID=2 a=control:trackID=2
skipping to change at page 174, line 7 skipping to change at page 176, line 24
- Proxy-Supported - Proxy-Supported
- Unsupported - Unsupported
D.2 Recommended Core Implementation D.2 Recommended Core Implementation
A RTSP Agent is also RECOMMENDED to support the following: A RTSP Agent is also RECOMMENDED to support the following:
o RTSP basic and digest authentication: The 401 response, the o RTSP basic and digest authentication: The 401 response, the
WWW-Authenticate and Authorization headers, and both Basic and WWW-Authenticate and Authorization headers, and both Basic and
Digest authentication methods as defined by [12]. Digest authentication methods as defined by [10].
o Secure RTSP message transport as specified by section D.4. o Secure RTSP message transport as specified by section D.4.
D.3 The Basic Playback Feature Support D.3 The Basic Playback Feature Support
This section defines what is required to be supported for clients, This section defines what is required to be supported for clients,
proxies and servers to be supporting the "play.basic" feature tag. proxies and servers to be supporting the "play.basic" feature-tag.
D.3.1 Client D.3.1 Client
A play.basic supporting client SHALL implement the following: A play.basic supporting client SHALL implement the following:
o The RTSP methods as required by Table 7. o The RTSP methods as required by Table 7.
o All the RTSP headers that are required required or conditional o All the RTSP headers that are required required or conditional
in requests or responses to method required to be supported in requests or responses to method required to be supported
according to Tables 9, 10, 11, and 12 and in addition the according to Tables 9, 10, 11, and 12 and in addition the
skipping to change at page 175, line 48 skipping to change at page 178, line 16
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 [28]. RFC 2326 define information learned by the attempt in RFC 2326 [25]. 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 177, line 4 skipping to change at page 179, line 20
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 [28]. with clients or servers being implemented according to RFC 2326 [25].
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
to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0
response. response.
Clients implementing RTSP/2.0 MAY use an OPTIONS request with a Clients implementing RTSP/2.0 MAY use an OPTIONS request with a
RTSP-Version of 2.0 to determine whether a server supports RTSP/2.0. RTSP-Version of 2.0 to determine whether a server supports RTSP/2.0.
If the server responds with either a RTSP-Version of 1.0 or a status If the server responds with either a RTSP-Version of 1.0 or a status
code of 505 (RTSP Version not supported), the client will have to use code of 505 (RTSP Version not supported), the client will have to use
RTSP/1.0 requests if it chooses to support RFC 2326. RTSP/1.0 requests if it chooses to support RFC 2326.
F.1 Play Request in Play mode In RFC 2326, receivers were advised to be prepared to also interpret
CR and LF by themselves as line terminators in addition to CRLF. If a
server or client wishes to support RFC 2326, it should treat a CR or
LF by itself as a CRLF.
F.1 Play Request in Play mode
The behavior in the server when a Play is received in Play mode has The behavior in the server when a Play is received in Play mode has
changed (Section 11.4). In RFC 2326, the new PLAY request would be changed (Section 11.4). In RFC 2326, the new PLAY request would be
queued until the current Play completed. Any new PLAY request now queued until the current Play completed. Any new PLAY request now
take effect immediately replacing the previous request. take effect immediately replacing the previous request.