idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 8308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 8281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 8288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 8294. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 36) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1616 has weird spacing: '...equired all...' == Line 1617 has weird spacing: '...ccepted all...' == Line 1909 has weird spacing: '...mmended rec...' == Line 1919 has weird spacing: '...nd what objec...' == Line 3116 has weird spacing: '...nd what objec...' == (30 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The response to valid request meeting the requisites is normally a 2xx (SUCCESS) unless other noted in the response column. The exceptions needs to be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occur the appropriate response code MUST be sent. If the response code is a 4xx the session state is unchanged. A response code of 3rr will result in that the session is ended and its state is changed to Init. A response code of 304 results in no state change. However there exist restrictions to when a 3xx response may be used. A 5xx response SHALL not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error SHALL result the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client knows that the session has ended. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '24' on line 8193 looks like a reference -- Missing reference section? '25' on line 8197 looks like a reference -- Missing reference section? '1' on line 8108 looks like a reference -- Missing reference section? '2' on line 8111 looks like a reference -- Missing reference section? '3' on line 8115 looks like a reference -- Missing reference section? '26' on line 8202 looks like a reference -- Missing reference section? '4' on line 8119 looks like a reference -- Missing reference section? '5' on line 8122 looks like a reference -- Missing reference section? '10' on line 8139 looks like a reference -- Missing reference section? '6' on line 8125 looks like a reference -- Missing reference section? '7' on line 8128 looks like a reference -- Missing reference section? '8' on line 8133 looks like a reference -- Missing reference section? '9' on line 8136 looks like a reference -- Missing reference section? '27' on line 8206 looks like a reference -- Missing reference section? '28' on line 8211 looks like a reference -- Missing reference section? '29' on line 8216 looks like a reference -- Missing reference section? '30' on line 8219 looks like a reference -- Missing reference section? '31' on line 8224 looks like a reference -- Missing reference section? '16' on line 8160 looks like a reference -- Missing reference section? '11' on line 8143 looks like a reference -- Missing reference section? '12' on line 8146 looks like a reference -- Missing reference section? '32' on line 8229 looks like a reference -- Missing reference section? '33' on line 8233 looks like a reference -- Missing reference section? '34' on line 8239 looks like a reference -- Missing reference section? '13' on line 8150 looks like a reference -- Missing reference section? 'H6' on line 1415 looks like a reference -- Missing reference section? 'H10' on line 2885 looks like a reference -- Missing reference section? 'TBW' on line 2930 looks like a reference -- Missing reference section? '14' on line 8153 looks like a reference -- Missing reference section? '15' on line 8156 looks like a reference -- Missing reference section? '35' on line 8244 looks like a reference -- Missing reference section? 'H15' on line 5904 looks like a reference -- Missing reference section? '17' on line 8164 looks like a reference -- Missing reference section? '18' on line 8167 looks like a reference -- Missing reference section? '19' on line 8171 looks like a reference -- Missing reference section? '36' on line 8247 looks like a reference -- Missing reference section? '20' on line 8175 looks like a reference -- Missing reference section? '21' on line 8179 looks like a reference -- Missing reference section? '37' on line 8252 looks like a reference -- Missing reference section? '38' on line 8255 looks like a reference -- Missing reference section? '39' on line 8259 looks like a reference -- Missing reference section? '22' on line 8183 looks like a reference -- Missing reference section? '23' on line 8187 looks like a reference -- Missing reference section? '40' on line 8263 looks like a reference -- Missing reference section? '41' on line 8266 looks like a reference -- Missing reference section? '42' on line 8269 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 16 warnings (==), 54 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft H. Schulzrinne 4 draft-ietf-mmusic-rfc2326bis-10.txt Columbia U. 5 July 18, 2005 Anup Rao 6 Expires: January 18, 2006 Cisco 7 Robert Lanphier 8 Real Networks 9 Magnus Westerlund 10 Ericsson 11 Aravind Narasimhan 12 Overture Computing 14 Real Time Streaming Protocol (RTSP) 16 STATUS OF THIS MEMO 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This memorandum defines RTSP version 1.1 which is a revision of the 42 Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 44 The Real Time Streaming Protocol, or RTSP, is an application-level 45 protocol for control over the delivery of data with real-time 46 properties. RTSP provides an extensible framework to enable 47 controlled, on-demand delivery of real-time data, such as audio and 48 video. Sources of data can include both live data feeds and stored 49 clips. This protocol is intended to control multiple data delivery 50 sessions, provide a means for choosing delivery channels such as UDP, 51 multicast UDP and TCP, and provide a means for choosing delivery 52 mechanisms based upon RTP (RFC 3550). 54 Table of Contents 56 1 Introduction ........................................ 9 57 1.1 RTSP Specification Update ........................... 9 58 1.2 Purpose ............................................. 9 59 1.3 Notational Conventions .............................. 11 60 1.4 Terminology ......................................... 12 61 1.5 Protocol Properties ................................. 15 62 1.6 Extending RTSP ...................................... 16 63 1.7 Overall Operation ................................... 17 64 1.8 RTSP States ......................................... 18 65 1.9 Relationship with Other Protocols ................... 19 66 2 RTSP Use Cases ...................................... 19 67 2.1 On-demand Playback of Stored Content ................ 20 68 2.2 Unicast distribution of Live Content ................ 21 69 2.3 On-demand Playback using Multicast .................. 21 70 2.4 Inviting a RTSP server into a conference ............ 22 71 2.5 Live Content using Multicast ........................ 23 72 3 Protocol Parameters ................................. 23 73 3.1 RTSP Version ........................................ 23 74 3.2 RTSP URI ............................................ 23 75 3.3 Session Identifiers ................................. 25 76 3.4 SMPTE Relative Timestamps ........................... 25 77 3.5 Normal Play Time .................................... 26 78 3.6 Absolute Time ....................................... 27 79 3.7 Feature-tags ........................................ 27 80 3.8 Entity Tags ......................................... 27 81 4 RTSP Message ........................................ 28 82 4.1 Message Types ....................................... 28 83 4.2 Message Headers ..................................... 28 84 4.3 Message Body ........................................ 28 85 4.4 Message Length ...................................... 29 86 5 General Header Fields ............................... 29 87 6 Request ............................................. 30 88 6.1 Request Line ........................................ 30 89 6.2 Request Header Fields ............................... 31 90 7 Response ............................................ 32 91 7.1 Status-Line ......................................... 32 92 7.1.1 Status Code and Reason Phrase ....................... 33 93 7.1.2 Response Header Fields .............................. 34 94 8 Entity .............................................. 34 95 8.1 Entity Header Fields ................................ 34 96 8.2 Entity Body ......................................... 34 97 9 Connections ......................................... 35 98 9.1 Reliability and Acknowledgements .................... 35 99 9.2 Using Connections ................................... 38 100 9.3 Closing Connections ................................. 39 101 9.4 Timing Out Connections and RTSP Messages ............ 40 102 9.5 Use of IPv6 ......................................... 40 103 10 Capability Handling ................................. 41 104 11 Method Definitions .................................. 42 105 11.1 OPTIONS ............................................. 43 106 11.2 DESCRIBE ............................................ 44 107 11.3 SETUP ............................................... 46 108 11.3.1 Changing Transport Parameters ....................... 48 109 11.4 PLAY ................................................ 49 110 11.5 PAUSE ............................................... 53 111 11.6 TEARDOWN ............................................ 57 112 11.7 GET_PARAMETER ....................................... 58 113 11.8 SET_PARAMETER ....................................... 59 114 11.9 REDIRECT ............................................ 60 115 12 Embedded (Interleaved) Binary Data .................. 62 116 13 Status Code Definitions ............................. 64 117 13.1 Success 1xx ......................................... 64 118 13.1.1 100 Continue ........................................ 64 119 13.2 Success 2xx ......................................... 64 120 13.3 Redirection 3xx ..................................... 64 121 13.3.1 300 Multiple Choices ................................ 65 122 13.3.2 301 Moved Permanently ............................... 65 123 13.3.3 302 Found ........................................... 65 124 13.3.4 303 See Other ....................................... 65 125 13.3.5 304 Not Modified .................................... 65 126 13.3.6 305 Use Proxy ....................................... 66 127 13.4 Client Error 4xx .................................... 66 128 13.4.1 400 Bad Request ..................................... 66 129 13.4.2 405 Method Not Allowed .............................. 66 130 13.4.3 451 Parameter Not Understood ........................ 66 131 13.4.4 452 reserved ........................................ 67 132 13.4.5 453 Not Enough Bandwidth ............................ 67 133 13.4.6 454 Session Not Found ............................... 67 134 13.4.7 455 Method Not Valid in This State .................. 67 135 13.4.8 456 Header Field Not Valid for Resource ............. 67 136 13.4.9 457 Invalid Range ................................... 67 137 13.4.10 458 Parameter Is Read-Only .......................... 67 138 13.4.11 459 Aggregate Operation Not Allowed ................. 67 139 13.4.12 460 Only Aggregate Operation Allowed ................ 68 140 13.4.13 461 Unsupported Transport ........................... 68 141 13.4.14 462 Destination Unreachable ......................... 68 142 13.4.15 463 Destination Prohibited .......................... 68 143 13.4.16 470 Connection Authorization Required ............... 68 144 13.4.17 471 Connection Credentials not accepted ............. 68 145 13.5 Server Error 5xx .................................... 68 146 13.5.1 551 Option not supported ............................ 68 147 14 Header Field Definitions ............................ 69 148 14.1 Accept .............................................. 71 149 14.2 Accept-Credentials .................................. 71 150 14.3 Accept-Encoding ..................................... 75 151 14.4 Accept-Language ..................................... 75 152 14.5 Accept-Ranges ....................................... 75 153 14.6 Allow ............................................... 76 154 14.7 Authorization ....................................... 76 155 14.8 Bandwidth ........................................... 76 156 14.9 Blocksize ........................................... 76 157 14.10 Cache-Control ....................................... 77 158 14.11 Connection .......................................... 79 159 14.12 Connection-Credentials .............................. 79 160 14.13 Content-Base ........................................ 80 161 14.14 Content-Encoding .................................... 80 162 14.15 Content-Language .................................... 80 163 14.16 Content-Length ...................................... 80 164 14.17 Content-Location .................................... 80 165 14.18 Content-Type ........................................ 80 166 14.19 CSeq ................................................ 81 167 14.20 Date ................................................ 81 168 14.21 ETag ................................................ 81 169 14.22 Expires ............................................. 82 170 14.23 From ................................................ 83 171 14.24 Host ................................................ 83 172 14.25 If-Match ............................................ 83 173 14.26 If-Modified-Since ................................... 83 174 14.27 If-None-Match ....................................... 83 175 14.28 Last-Modified ....................................... 84 176 14.29 Location ............................................ 84 177 14.30 Proxy-Authenticate .................................. 84 178 14.31 Proxy-Require ....................................... 84 179 14.32 Proxy-Supported ..................................... 84 180 14.33 Public .............................................. 85 181 14.34 Range ............................................... 86 182 14.35 Referer ............................................. 88 183 14.36 Retry-After ......................................... 88 184 14.37 Require ............................................. 88 185 14.38 RTP-Info ............................................ 89 186 14.39 Scale ............................................... 91 187 14.40 Speed ............................................... 91 188 14.41 Server .............................................. 92 189 14.42 Session ............................................. 92 190 14.43 Supported ........................................... 94 191 14.44 Timestamp ........................................... 94 192 14.45 Transport ........................................... 95 193 14.46 Unsupported ......................................... 99 194 14.47 User-Agent .......................................... 100 195 14.48 Vary ................................................ 100 196 14.49 Via ................................................. 100 197 14.50 WWW-Authenticate .................................... 100 198 15 Proxies ............................................. 100 199 16 Caching ............................................. 101 200 17 Examples ............................................ 102 201 17.1 Media on Demand (Unicast) ........................... 102 202 17.2 Streaming of a Container file ....................... 105 203 17.3 Single Stream Container Files ....................... 108 204 17.4 Live Media Presentation Using Multicast ............. 110 205 17.5 Capability Negotiation .............................. 111 206 18 Security Framework .................................. 112 207 18.1 RTSP and HTTP Authentication ........................ 112 208 18.2 RTSP over TLS ....................................... 112 209 18.3 Security and Proxies ................................ 113 210 18.3.1 Accept-Credentials .................................. 114 211 18.3.2 User approved TLS procedure ......................... 115 212 19 Syntax .............................................. 117 213 19.1 Base Syntax ......................................... 117 214 19.2 RTSP Protocol Definition ............................ 119 215 19.2.1 Generic Protocol elements ........................... 119 216 19.2.2 Message Syntax ...................................... 120 217 19.2.3 Header Syntax ....................................... 124 218 19.3 SDP extension Syntax ................................ 129 219 20 Security Considerations ............................. 130 220 20.1 Remote denial of Service Attack ..................... 132 221 21 IANA Considerations ................................. 132 222 21.1 Feature-tags ........................................ 133 223 21.1.1 Description ......................................... 133 224 21.1.2 Registering New Feature-tags with IANA .............. 133 225 21.1.3 Registered entries .................................. 133 226 21.2 RTSP Methods ........................................ 134 227 21.2.1 Description ......................................... 134 228 21.2.2 Registering New Methods with IANA ................... 134 229 21.2.3 Registered Entries .................................. 134 230 21.3 RTSP Status Codes ................................... 134 231 21.3.1 Description ......................................... 134 232 21.3.2 Registering New Status Codes with IANA .............. 135 233 21.3.3 Registered Entries .................................. 135 234 21.4 RTSP Headers ........................................ 135 235 21.4.1 Description ......................................... 135 236 21.4.2 Registering New Headers with IANA ................... 135 237 21.4.3 Registered entries .................................. 136 238 21.5 Transport Header registries ......................... 136 239 21.5.1 Transport Protocols ................................. 136 240 21.5.2 Profile ............................................. 137 241 21.5.3 Lower Transport ..................................... 137 242 21.5.4 Transport modes ..................................... 138 243 21.5.5 Transport Parameters ................................ 138 244 21.6 Cache Directive Extensions .......................... 139 245 21.7 Accept-Credentials policies ......................... 139 246 21.8 URI Schemes ......................................... 140 247 21.9 SDP attributes ...................................... 140 248 A RTSP Protocol State Machine ......................... 141 249 A.1 States .............................................. 141 250 A.2 State variables ..................................... 142 251 A.3 Abbreviations ....................................... 142 252 A.4 State Tables ........................................ 142 253 B Media Transport Alternatives ........................ 145 254 B.1 RTP ................................................. 146 255 B.1.1 AVP ................................................. 146 256 B.1.2 AVP/UDP ............................................. 146 257 B.1.3 AVP/TCP ............................................. 147 258 B.1.4 AVPF ................................................ 148 259 B.1.5 SAVP ................................................ 148 260 B.1.6 Handling NPT Jumps in the RTP Media Layer ........... 148 261 B.1.7 Handling RTP Timestamps after PAUSE ................. 151 262 B.1.8 RTSP / RTP Integration .............................. 153 263 B.1.9 Scaling with RTP .................................... 153 264 B.1.10 Maintaining NPT synchronization with RTP 265 timestamps .......................................... 153 266 B.1.11 Continuous Audio .................................... 153 267 B.1.12 Multiple Sources in an RTP Session .................. 153 268 B.1.13 Usage of SSRCs and the RTCP BYE Message During an 269 RTSP Session ........................................ 154 270 B.2 Future Additions .................................... 154 271 C Use of SDP for RTSP Session Descriptions ............ 155 272 C.1 Definitions ......................................... 155 273 C.1.1 Control URI ......................................... 155 274 C.1.2 Media Streams ....................................... 156 275 C.1.3 Payload Type(s) ..................................... 157 276 C.1.4 Format-Specific Parameters .......................... 157 277 C.1.5 Range of Presentation ............................... 157 278 C.1.6 Time of Availability ................................ 158 279 C.1.7 Connection Information .............................. 158 280 C.1.8 Entity Tag .......................................... 158 281 C.2 Aggregate Control Not Available ..................... 159 282 C.3 Aggregate Control Available ......................... 160 283 C.4 RTSP external SDP delivery .......................... 161 284 D Minimal RTSP implementation ......................... 161 285 D.1 Minimal Core Implementation ......................... 161 286 D.2 The Basic Playback Feature Support .................. 162 287 D.2.1 Client .............................................. 162 288 D.2.2 Server .............................................. 163 289 D.2.3 Proxy ............................................... 163 290 D.3 Secure Transport .................................... 163 291 D.4 Old Implementation Text ............................. 163 292 D.5 Client .............................................. 164 293 D.5.1 Basic Playback ...................................... 164 294 D.5.2 Authentication-enabled .............................. 165 295 D.6 Server .............................................. 165 296 D.6.1 Basic Playback ...................................... 166 297 D.6.2 Authentication-enabled .............................. 166 298 E Requirements for Unreliable Transport of RTSP 299 messages ............................................ 167 300 F Backwards Compatibility Considerations .............. 168 301 F.1 Play Request in Play mode ........................... 168 302 F.2 Using Persistent Connections ........................ 168 303 G Open Issues ......................................... 169 304 H Changes ............................................. 169 305 H.1 Changes needing to be updated ....................... 175 306 I Author Addresses .................................... 175 307 J Contributors ........................................ 176 308 K Acknowledgements .................................... 176 309 L Normative References ................................ 177 310 M Informative References .............................. 179 312 1 Introduction 314 1.1 RTSP Specification Update 316 This memorandum specifies RTSP 1.1 which is an update of RTSP 1.0, a 317 proposed standard defined in RFC 2326 [24]. The goal of this version 318 is to correct the many flaws that have been identified in RTSP 1.0 319 since its publication. The corrections are such that full backwards 320 compatibility was impossible. Thus a new version was decided the most 321 appropriate solution to get a more functional protocol. There are no 322 plans to revise RTSP 1.0. Appendix H catalogs the changes of this 323 version in relation to RTSP 1.0. 325 A few open issues still remain to be resolved, and are listed in 326 appendix G. These are intended to be close quickly. 328 A list of bugs against RFC 2326 is available at 329 "http://rtspspec.sourceforge.net". These bugs should be taken into 330 account when reading this memorandum. Input on the unresolved bugs 331 and other issues can be sent via e-mail to the MMUSIC WG's mailing 332 list mmusic@ietf.org and the authors. 334 RTSP 1.1 is reduced in functionality in regards to RTSP 1.0 and aims 335 at specifying the RTSP core, functionality and rules for extensions, 336 and basic interaction with the media delivery protocol RTP. 338 Any other functionality would be need to be published as extension 339 documents. The Working group has discussed a number of different 340 proposals to extensions and is currently working on: 342 o NAT and FW traversal mechanisms for RTSP are described in a 343 document called "How to make Real-Time Streaming Protocol 344 (RTSP) traverse Network Address Translators (NAT) and interact 345 with Firewalls." [25]. 347 1.2 Purpose 349 The Real-Time Streaming Protocol (RTSP) establishes and controls one 350 or several time-synchronized streams of continuous media such as 351 audio and video. Put simply, RTSP acts as a "network remote control" 352 for multimedia servers. 354 There is no notion of an RTSP connection in the protocol. Instead, an 355 RTSP server maintains a session labeled by an identifier to associate 356 groups of media streams and their states. An RTSP session is not tied 357 to a transport-level connection such as a TCP connection. During a 358 session, a client may open and close many reliable transport 359 connections to the server to issue RTSP requests for that session. 361 This memorandum describes the use of RTSP over a reliable connection 362 based transport level protocol such as TCP. RTSP may be implemented 363 over an unreliable connectionless transport protocol such as UDP. 364 While nothing in RTSP precludes this, additional definition of this 365 problem area needs to be handled as an extension to the core 366 specification. 368 The mechanisms of RTSP's operation over UDP were left out 369 of this spec. because they were poorly defined in RFC 2326 370 [24] and the tradeoff in size and complexity of this 371 memorandum for a small gain in a limited problem space was 372 not deemed justifiable. 374 The set of streams to be controlled in an RTSP session is defined by 375 a presentation description. This memorandum does not define a format 376 for the presentation description. However appendix C defines how SDP 377 [1] is used for this purpose. The streams controlled by RTSP may use 378 RTP [2] for their data transport, but the operation of RTSP does not 379 depend on the transport mechanism used to carry continuous media. 380 RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3] 381 so that extension mechanisms to HTTP can in most cases also be added 382 to RTSP. However, RTSP differs in a number of important aspects from 383 HTTP: 385 o RTSP introduces a number of new methods and has a different 386 protocol identifier. 388 o RTSP has the notion of a session built into the protocol. 390 o An RTSP server needs to maintain state by default in almost 391 all cases, as opposed to the stateless nature of HTTP. 393 o Both an RTSP server and client can issue requests. 395 o Data is usually carried out-of-band by a different protocol. 396 Session descriptions returned in a DESCRIBE response (see 397 Section 11.2) and interleaving of RTP with RTSP over TCP are 398 exceptions to this rule (see Section 12). 400 o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 401 8859-1, consistent with HTML internationalization efforts 402 [26]. 404 o The Request-URI always contains the absolute URI. Because of 405 backward compatibility with a historical blunder, HTTP/1.1 [3] 406 carries only the absolute path in the request and puts the 407 host name in a separate header field. 409 This makes "virtual hosting" easier, where a single 410 host with one IP address hosts several document trees. 412 The protocol supports the following operations: 414 Retrieval of media from media server: The client can either 415 request a presentation description via RTSP DESCRIBE, HTTP 416 or some other method. If the presentation is being 417 multicast, the presentation description contains the 418 multicast addresses and ports to be used for the continuous 419 media. If the presentation is to be sent only to the client 420 via unicast, the client provides the destination of 421 necessity. 423 Invitation of a media server to a conference: A media server can 424 be "invited" to join an existing conference to play back 425 media into the presentation. This mode is useful for 426 example distributed teaching applications. Several parties 427 in the conference may take turns "pushing the remote 428 control buttons". 430 RTSP requests may be handled by proxies, tunnels and caches as in 431 HTTP/1.1 [3]. 433 1.3 Notational Conventions 435 Since many of the definitions and syntax are identical to HTTP/1.1, 436 this specification only points to the section where they are defined 437 rather than copying it. For brevity, [HX.Y] is to be taken to refer 438 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [3]). 440 All the mechanisms specified in this document are described in both 441 prose and the Augmented Backus-Naur form (ABNF) described in detail 442 in RFC 2234 [4]. 444 Indented and smaller-type paragraphs are used to provide informative 445 background and motivation. This is intended to give readers who were 446 not involved with the formulation of the specification an 447 understanding of why things are the way they are in RTSP. 449 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 450 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 451 document are to be interpreted as described in RFC 2119 [5]. 453 The word, "unspecified" is used to indicate functionality or features 454 that are not defined in this specification. Such functionality cannot 455 be used in a standardized manner without further definition in an 456 extension specification to RTSP. 458 1.4 Terminology 460 Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not 461 listed here are defined as in HTTP/1.1. 463 Aggregate control: The concept of controlling multiple streams 464 using a single timeline, generally maintained by the 465 server. A client, for example, uses aggregate control when 466 it issues a single play or pause message to simultaneously 467 control both the audio and video in a movie. 469 Aggregate control URI: The URI used in an RTSP request to refer 470 to and control an aggregated session. It normally, but not 471 always, corresponds to the presentation URI specified in 472 the session description. See Section 11.3 for more 473 information. 475 Conference: a multiparty, multimedia presentation, where "multi" 476 implies greater than or equal to one. 478 Client: The client requests media service from the media server. 480 Connection: A transport layer virtual circuit established 481 between two programs for the purpose of communication. 483 Container file: A file which may contain multiple media streams 484 which often constitutes a presentation when played 485 together. The concept of a container file is not embedded 486 in the protocol. However, RTSP servers may offer aggregate 487 control on the media streams within these files. 489 Continuous media: Data where there is a timing relationship 490 between source and sink; that is, the sink needs to 491 reproduce the timing relationship that existed at the 492 source. The most common examples of continuous media are 493 audio and motion video. Continuous media can be real-time 494 (interactive or conversational), where there is a "tight" 495 timing relationship between source and sink, or streaming 496 (playback), where the relationship is less strict. 498 Entity: The information transferred as the payload of a request 499 or response. An entity consists of meta-information in the 500 form of entity-header fields and content in the form of an 501 entity-body, as described in Section 8. 503 Feature-tag: A tag representing a certain set of functionality, 504 i.e. a feature. 506 Live: Normally used to describe a presentation or session with 507 media coming from an ongoing event. This generally results 508 in that the session has a unbound or only loosely defined 509 duration, and that no seek operations are possible. 511 Media initialization: Datatype/codec specific initialization. 512 This includes such things as clock rates, color tables, 513 etc. Any transport-independent information which is 514 required by a client for playback of a media stream occurs 515 in the media initialization phase of stream setup. 517 Media parameter: Parameter specific to a media type that may be 518 changed before or during stream playback. 520 Media server: The server providing playback services for one or 521 more media streams. Different media streams within a 522 presentation may originate from different media servers. A 523 media server may reside on the same host or on a different 524 host from which the presentation is invoked. 526 Media server indirection: Redirection of a media client to a 527 different media server. 529 (Media) stream: A single media instance, e.g., an audio stream 530 or a video stream as well as a single whiteboard or shared 531 application group. When using RTP, a stream consists of all 532 RTP and RTCP packets created by a source within an RTP 533 session. 535 Message: The basic unit of RTSP communication, consisting of a 536 structured sequence of octets matching the syntax defined 537 in Section 19 and transmitted over a connection or a 538 connectionless transport. 540 Non-Aggregated Control: Control of a single media stream. Only 541 possible in RTSP sessions with a single media. 543 Participant: Member of a conference. A participant may be a 544 machine, e.g., a playback server. 546 Presentation: A set of one or more streams presented to the 547 client as a complete media feed and described by a 548 presentation description as defined below. Presentations 549 with more than one media stream is often handled in RTSP 550 under aggregate control. 552 Presentation description: A presentation description contains 553 information about one or more media streams within a 554 presentation, such as the set of encodings, network 555 addresses and information about the content. Other IETF 556 protocols such as SDP (RFC 2327 [1]) use the term "session" 557 for a presentation. The presentation description may take 558 several different formats, including but not limited to the 559 session description protocol format, SDP. 561 Response: An RTSP response. If an HTTP response is meant, that 562 is indicated explicitly. 564 Request: An RTSP request. If an HTTP request is meant, that is 565 indicated explicitly. 567 Request-URI: The URI used in a request to indicate the resource 568 on which the request is to be performed. 570 RTSP agent: Refers to either an RTSP client, an RTSP server, or 571 an RTSP Proxy. In this specification, there are many 572 capabilities that are common to these three entities such 573 as the capability to send requests or receive responses. 574 This term will be used when describing functionality that 575 is applicable to all three of these entities. 577 RTSP session: A stateful abstraction upon which the main control 578 methods of RTSP operate. An RTSP session is a server 579 entity; it is created, maintained and destroyed by the 580 server. It is established by an RTSP server upon the 581 completion of a successful SETUP request (when 200 OK 582 response is sent) and is labelled by a session identifier 583 at that time. The session exists until timed out by the 584 server or explicitly removed by a TEARDOWN request. An RTSP 585 session is a stateful entity; an RTSP server maintains an 586 explicit session state machine (see Appendix A) where most 587 state transitions are triggered by client requests. The 588 existence of a session implies the existence of state about 589 the session's media streams and their respective transport 590 mechanisms. A given session can have zero or more media 591 streams associated with it. An RTSP server uses the session 592 to aggregate control over multiple media streams. 594 Transport initialization: The negotiation of transport 595 information (e.g., port numbers, transport protocols) 596 between the client and the server. 598 URI: Universal Resource Identifier, see RFC 3986 [10]. In RTSP 599 the used URIs are as general rule in fact URL's as they 600 gives an location for the resource. As URLs are a subset of 601 URIs, they will be referred to as URIs to cover also the 602 cases when an RTSP URI would not be an URL. 604 URL: Universal Resource Locator, is an URI which identifies the 605 resource through its primary access mechanism, rather than 606 identifying the resource by name or by some other 607 attribute(s) of that resource. 609 1.5 Protocol Properties 611 RTSP has the following properties: 613 Extendable: New methods and parameters can be easily added to 614 RTSP. 616 Easy to parse: RTSP can be parsed by standard HTTP or MIME 617 parsers. 619 Secure: RTSP re-uses web security mechanisms, either at the 620 transport level (TLS, RFC 2246 [6]) or within the protocol 621 itself. All HTTP authentication mechanisms such as basic 622 (RFC 2616 [3]) and digest authentication (RFC 2617 [7]) are 623 directly applicable. 625 Transport-independent: RTSP does not preclude the use of an 626 unreliable datagram protocol (UDP) (RFC 768 [8]) as it 627 would be possible to implement application-level 628 reliability. The use of a connectionless datagram protocol 629 such as UDP requires additional definition that may be 630 provided as extensions to the core RTSP specification. The 631 usage of the reliable stream protocol TCP (RFC 793 [9]) and 632 secured reliable stream protocol TLS over TCP [6] is what 633 is currently defined as transport protocol of RTSP 634 messages. 636 Multi-server capable: Each media stream within a presentation 637 can reside on a different server. The client automatically 638 establishes several concurrent control sessions with the 639 different media servers. Media synchronization is 640 performed at the transport level. 642 Separation of stream control and conference initiation: Stream 643 control is divorced from inviting a media server to a 644 conference. In particular, SIP [27] or H.323 [28] may be 645 used to invite a server to a conference. 647 Suitable for professional applications: RTSP supports frame- 648 level accuracy through SMPTE time stamps to allow remote 649 digital editing. 651 Presentation description neutral: The protocol does not impose a 652 particular presentation description or metafile format and 653 can convey the type of format to be used. However, the 654 presentation description is required to contain at least 655 one RTSP URI. 657 Proxy and firewall friendly: The protocol should be readily 658 handled by both application and transport-layer (SOCKS 659 [29]) firewalls. A firewall may need to understand the 660 SETUP method to open a "hole" for the media stream. 662 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so 663 that the existing infrastructure can be reused. This 664 infrastructure includes PICS (Platform for Internet Content 665 Selection [30,31]) for associating labels with content. 666 However, RTSP does not just add methods to HTTP since the 667 controlling continuous media requires server state in most 668 cases. 670 Appropriate server control: If a client can start a stream, it 671 needs to be able to stop a stream. Servers should not start 672 streaming to clients in such a way that clients cannot stop 673 the stream. 675 Transport negotiation: The client can negotiate the transport 676 method prior to actually needing to process a continuous 677 media stream. 679 1.6 Extending RTSP 681 Since not all media servers have the same functionality, media 682 servers by necessity will support different sets of requests. For 683 example: 685 o A server may not be capable of seeking (absolute positioning) 686 if it is to support live events only. 688 o Some servers may not support setting stream parameters and 689 thus not support GET_PARAMETER and SET_PARAMETER. 691 o Some server may support an RTSP extension. 693 A server SHOULD implement all header fields described in Section 14. 695 It is up to the creators of presentation descriptions not to ask the 696 impossible of a server. This situation is similar in HTTP/1.1 [3], 697 where the methods described in [H19.5] are not likely to be supported 698 across all servers. 700 RTSP can be extended in three ways, listed here in order of the 701 magnitude of changes supported: 703 o Existing methods can be extended with new parameters, e.g. 704 headers, as long as these parameters can be safely ignored by 705 the recipient. If the client needs negative acknowledgement 706 when a method extension is not supported, a tag corresponding 707 to the extension may be added in the Require: field (see 708 Section 14.37). 710 o New methods can be added. If the recipient of the message does 711 not understand the request, it responds with error code 501 712 (Not Implemented) and the sender should not attempt to use 713 this method again. A client may also use the OPTIONS method to 714 inquire about methods supported by the server. The server MUST 715 list the methods it supports using the Public response header. 717 o A new version of the protocol can be defined, allowing almost 718 all aspects (except the position of the protocol version 719 number) to change. 721 The basic capability discovery mechanism can be used to both discover 722 support for a certain feature and to ensure that a feature is 723 available when performing a request. For detailed explanation of this 724 see section 10. 726 1.7 Overall Operation 728 Each presentation and media stream is identified by an RTSP URI. The 729 overall presentation and the properties of the media the presentation 730 is made up of are defined by a presentation description file, the 731 format of which is outside the scope of this specification. The 732 presentation description file may be obtained by the client using 733 HTTP or other means such as email and may not necessarily be stored 734 on the media server. 736 For the purposes of this specification, a presentation description is 737 assumed to describe one or more presentations, each of which 738 maintains a common time axis. For simplicity of exposition and 739 without loss of generality, it is assumed that the presentation 740 description contains exactly one such presentation. A presentation 741 may contain several media streams. 743 The presentation description file contains a description of the media 744 streams making up the presentation, including their encodings, 745 language, and other parameters that enable the client to choose the 746 most appropriate combination of media. In this presentation 747 description, each media stream that is individually controllable by 748 RTSP is identified by an RTSP URI, which points to the media server 749 handling that particular media stream and names the stream stored on 750 that server. Several media streams can be located on different 751 servers; for example, audio and video streams can be split across 752 servers for load sharing. The description also enumerates which 753 transport methods the server is capable of. 755 Besides the media parameters, the network destination address and 756 port need to be determined. Several modes of operation can be 757 distinguished: 759 Unicast: The media is transmitted to the source of the RTSP 760 request, with the port number chosen by the client. 761 Alternatively, the media is transmitted on the same 762 reliable stream as RTSP. 764 Multicast, server chooses address: The media server picks the 765 multicast address and port. This is the typical case for a 766 live or near-media-on-demand transmission. 768 Multicast, client chooses address: If the server is to 769 participate in an existing multicast conference, the 770 multicast address, port and encryption key are given by the 771 conference description, established by means outside the 772 scope of this specification, for example by a SIP created 773 conference. 775 1.8 RTSP States 777 RTSP controls a stream which may be sent via a separate protocol, 778 independent of the control channel. For example, RTSP control may be 779 transported on a TCP connection while the media data is conveyed via 780 UDP. Thus, data delivery continues even if no RTSP requests are 781 received by the media server. Also, during its lifetime, a single 782 media stream may be controlled by RTSP requests issued sequentially 783 on different TCP connections. Therefore, the server needs to maintain 784 "session state" to be able to correlate RTSP requests with a stream. 785 The state transitions are described in Appendix A. 787 Many methods in RTSP do not contribute to state. However, the 788 following play a central role in defining the allocation and usage of 789 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and 790 TEARDOWN. 792 SETUP: Causes the server to allocate resources for a stream and 793 create an RTSP session. 795 PLAY: Starts data transmission on a stream allocated via SETUP. 797 PAUSE: Temporarily halts a stream without freeing server 798 resources. 800 REDIRECT: Indicates that the session should be moved to new 801 server / location 803 TEARDOWN: Frees resources associated with the stream. The RTSP 804 session ceases to exist on the server. 806 RTSP methods that contribute to state use the Session header field 807 (Section 14.42) to identify the RTSP session whose state is being 808 manipulated. The server generates session identifiers in response to 809 SETUP requests (Section 11.3). 811 1.9 Relationship with Other Protocols 813 RTSP has some overlap in functionality with HTTP. It also may 814 interact with HTTP in that the initial contact with streaming content 815 is often to be made through a web page. The current protocol 816 specification aims to allow different hand-off points between a web 817 server and the media server implementing RTSP. For example, the 818 presentation description can be retrieved using HTTP or RTSP, which 819 reduces round trips in web-browser-based scenarios, yet also allows 820 for stand alone RTSP servers and clients which do not rely on HTTP at 821 all. However, RTSP differs fundamentally from HTTP in that most data 822 delivery takes place out-of-band in a different protocol. HTTP is an 823 asymmetric protocol where the client issues requests and the server 824 responds. In RTSP, both the media client and media server can issue 825 requests. RTSP requests are also stateful; they may set parameters 826 and continue to control a media stream long after the request has 827 been acknowledged. 829 Re-using HTTP functionality has advantages in at least two 830 areas, namely security and proxies. The requirements are 831 very similar, so having the ability to adopt HTTP work on 832 caches, proxies and authentication is valuable. 834 RTSP assumes the existence of a presentation description format that 835 can express both static and temporal properties of a presentation 836 containing several media streams. Session Description Protocol (SDP) 837 [1] is generally the format of choice; however, RTSP is not bound to 838 it. For data delivery, most real-time media will use RTP as a 839 transport protocol. While RTSP works well with RTP, it is not tied to 840 RTP. 842 2 RTSP Use Cases 843 This section describes the most important and considered use cases 844 for RTSP. They are listed in descending order of importance in 845 regards to ensuring that all necessary functionality is present. This 846 specification does only fully support usage of the two first. Also in 847 these first two cases, there are special cases or exceptions that are 848 not supported without extensions, e.g. the redirection of media to 849 another address than the controlling entity. 851 2.1 On-demand Playback of Stored Content 853 An RTSP capable server stores content suitable for being streamed to 854 a client. A client desiring playback of any of the stored content 855 then uses RTSP to set up and configure the media transport required 856 for the desired content. Then RTSP is used to initiate, halt and 857 manipulate the actual transmission (playout) of the content. There 858 are also requirement on being able to use RTSP to carry necessary 859 description and synchronization information for the content. The 860 above high level description can be broken down into a number of 861 functionalities that RTSP needs to be capable of. 863 Presentation Description: The possibility to carry 864 initialization information about the presentation 865 (content), for example, which media codec(s) that are 866 needed for the content. Other information that are 867 important; how many media stream that the presentation 868 contains; what transport protocols used for the media 869 streams; and identifiers for these media streams. This 870 information is required before setup of the content is 871 possible. The information is also needed by the client to 872 determine if it is capable at all to support the content. 873 This information is not required to be sent using RTSP, 874 instead other external protocols can be utilized to 875 transport presentation descriptions. Two good examples are 876 the use of HTTP [3] or email to fetch or receive 877 presentation descriptions like SDP [1]. .XP Setup: 878 Performing setup of some or all of the media streams in a 879 presentation. The setup itself consist of determining which 880 protocols for media transport to use; the necessary 881 parameters for the protocol, like addresses and ports. .XP 882 Control of Transmission: After the necessary media streams 883 has been established the client can request the server to 884 start transmitting the content. There is need to allow the 885 client to at arbitrary times start or stop the transmission 886 of the content. There are also exist need to be able to 887 start the transmission at an any point in the timeline of 888 the presentation. .XP Synchronization: For media transport 889 protocols like RTP [16] it might be beneficial to carry 890 synchronization information within RTSP. Either due to the 891 lack of inter media synchronization within the protocol 892 itself, or the potential delay before the synchronization 893 is established (which is the case for RTP when using RTCP). 894 .XP Termination There is also need to be able to terminate 895 the established contexts. 896 For this use cases there is a number of assumption about how it 897 works. These are listed below: 899 On-Demand content: The content available is stored at the server 900 and can be accessed at any time during a time period when 901 it is intended to be available. .XP Independent sessions: A 902 server is capable of serving a number of clients 903 simultaneously, including from the same piece of content at 904 different points in that presentations time-line. .XP 905 Unicast Transport: Content for each individual client is 906 transmitted to them using unicast traffic. 907 It is also possible to redirect the media traffic to another 908 destination than where the entity controlling traffic uses. 909 However allowing this without appropriate mechanisms for 910 checking that the destination approves of this is allows for 911 distributed denial of service attacks (DDoS). 913 2.2 Unicast distribution of Live Content 915 This use cases is not that different from the above on-demand content 916 case (see section 2.1. The difference is really the restriction the 917 content itself establish. Live content is continuously distributed as 918 it becomes available from a source, i.e. the main difference to on- 919 demand is that one starts distributing content before the end of it 920 has become available to the server. In many cases the consumer of 921 live content is only interested in consuming what is actually happens 922 "now", i.e. very similar to broadcast TV. However in this case it is 923 assumed that there exist no broadcast or multicast channel to the 924 users, and instead the server functions as a distribution node, 925 sending the same content to multiple receivers, using unicast traffic 926 between server and client. This unicast traffic and the transport 927 parameters are individually negotiated for each receiving client. 928 Another aspect of live content is that it has often very limited time 929 of availability, as it is only is available for the duration of the 930 event the content covers. A example of such a live content could for 931 example be a music concert, which lasts 2 hour and starts at a 932 predetermined time. Thus there is need to announce when and for how 933 long the live content is available. 935 2.3 On-demand Playback using Multicast 937 It is possible to use RTSP to request that media is delivered to a 938 multicast group. The entity setting up the session (the controller) 939 will then control when and what media that is delivered to the group. 940 Also this use case has some potential for denial of service attacks, 941 in this case flooding any multicast group. Therefore there is need 942 for a mechanism indicating that the group actually accepts the 943 traffic from the RTSP server. An open issue in this use case is how 944 one ensures that all receivers listening to the multicast or 945 broadcast receives the session presentation configuring the 946 receivers. 948 2.4 Inviting a RTSP server into a conference 950 If one has an established conference or group session, it is possible 951 to have a RTSP server distribute media to the whole group. The 952 transmission to the group is simplest controlled by a single 953 participant or leader of the conference. Shared control might be 954 possible, but would require further investigation and possibly 955 extensions. There are some protocol mechanisms missing for this 956 scenario. For reasonable complexity in the media transmission stage, 957 this use case assumes that there exist either multicast or a 958 conference focus that redistribute media to all participants. In some 959 more detail, this use case is intended to be able to handle the 960 following scenario: A conference leader or participant (from here 961 called the controller) has some pre-stored content on a RTSP server 962 that he likes to share with the group. The controller sets up an RTSP 963 session at the streaming server for the content the controller likes 964 to share. The session description for the content is retrieved by the 965 controller. The media destination for the media content is sent to 966 the shared multicast group or conference focus. When desired by the 967 controller, he/she can start and stop the transmission of the media 968 to the conference group. There are several issues with this use case 969 that is not solved by this core specification for RTSP: 971 o Denial of service threat, to avoid a RTSP server from being a 972 unknowing participant of a denial of service attack the server 973 needs to be able to verify the destinations acceptance for the 974 media. Such a mechanism does not yet exist that can be used to 975 verify the approval to received media, instead only policies 976 can be used, which can be made to work in controlled 977 environments. .IP o 2 The problem of distributing the 978 presentation description to all participants in the group. To 979 enable a media receiver to decode the content correctly the 980 media configuration information will need to be distributed 981 reliable to all participants. This will most likely require 982 support from an external protocol. .IP o 2 Passing the 983 control. If it is desired to be able to pass the control of 984 the RTSP session between the participants some support will be 985 required by an external protocol for the necessary exchange of 986 state information and possibly floor control of who is 987 controlling the RTSP session. 989 So if there interest in this use case further work on the necessary 990 extensions has to be performed. 992 2.5 Live Content using Multicast 994 This use case does in its simplest form do not require any use of 995 RTSP at all. This is what multicast conferences being announced with 996 SAP and SDP are intended to handle. However in use cases where more 997 advance features like access control to the multicast session is 998 desired, RTSP could be used for session establishment. A client 999 desiring to join a live multicasted media session with cryptographic 1000 (encryption) access control could use RTSP in the following way. The 1001 source of the session, announces the session and gives all interested 1002 to join, a RTSP URI. The client connects to the server and requests 1003 the presentation description allowing for configuration the 1004 reception. In this step it is possible to use secured transport for 1005 the client, and also desired levels of authentication, for example 1006 for charging purposes or simply access control. An RTSP link also 1007 allows for load balancing between multiple servers. However if this 1008 was the only thing that occurred it could probably be solved as 1009 simply using HTTP. However for session where the sender likes to keep 1010 track of each individual receiver during the session, and possibly 1011 use this side channel for pushing out key-updates or other side 1012 information that is desirable to be done on a per receiver basis, and 1013 the receivers are not know prior to the session start, the state 1014 establishment that RTSP provides can be beneficial. In this case a 1015 client would establish a RTSP session to the multicast group. The 1016 RTSP server will not transmit any media, instead it will simply point 1017 to the multicast group. However the client and server will be able to 1018 keep the session alive for as long as the receiver participates in 1019 the session. Thus enabling, for example server to client pushes of 1020 updates. This use cases will most likely not be able to actually 1021 implement without some extensions in relation to the server to client 1022 push mechanism. Here a method like ANNOUNCE (see RFC 2326 [24] might 1023 be suitable, however it will require a RTSP extension to revive the 1024 method. 1026 3 Protocol Parameters 1028 3.1 RTSP Version 1030 HTTP Specification Section [H3.1] applies, with HTTP replaced by 1031 RTSP. This specification defines version 1.1 of RTSP. 1033 3.2 RTSP URI 1034 The "rtsp", "rtsps" schemes are used to refer to network resources 1035 via the RTSP protocol. This section defines the scheme-specific 1036 syntax and semantics for RTSP URIs. The RTSP URI is case sensitive. 1037 An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP 1038 messages over unreliable transport (UDP) and is currently deprecated 1039 and reserved, and MUST NOT be used . See Appendix E for further 1040 information. 1042 Informative RTSP URI syntax: 1044 rtsp[u|s]://host[:port]/abspath[?query]#fragment 1046 See section 19.2.1 for the formal definition of the RTSP URI syntax. 1048 The fragment identifier is used as defined in section 4.1 of [10], 1049 i.e. the fragment is to be stripped from the URI by the requestor and 1050 not included in the request. The user agent also needs to interpret 1051 the value of the fragment based on the media type the request relates 1052 to, i.e. the media type indicated in Content-Type header in the 1053 response to DESCRIBE. 1055 The syntax of any URI query string is unspecified and responder 1056 (usually the server) specific. As it is from the requestor an opaque 1057 string, it needs to be handled as such. 1059 The URI scheme rtsp requires that commands are issued via a reliable 1060 protocol (within the Internet, TCP), while the scheme rtsps 1061 identifies a reliable transport using secure transport (TLS [6]). 1063 If the no port number is provided in the URI, port number 554 SHALL 1064 be used. The semantics are that the identified resource can be 1065 controlled by RTSP at the server listening for TCP (scheme "rtsp") 1066 connections on that port of host, and the Request-URI for the 1067 resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322 1068 is registered and SHALL be assumed. 1070 The use of IP addresses in URIs SHOULD be avoided whenever possible 1071 (see RFC 1924 [11]). This specification updates the RTSP URI scheme 1072 to allow for literal IPv6 addresses using the host specification in 1073 RFC 2732 [12]. 1075 Note: Using qualified domain names in any URI is one 1076 requirement for making it possible for RTSP 1.0 (RFC 2326) 1077 implementations of RTSP to use IPv6. 1079 A presentation or a stream is identified by a textual media 1080 identifier, using the character set and escape conventions [H3.2] of 1081 URIs (RFC 3986 [10]). URIs may refer to a stream or an aggregate of 1082 streams, i.e., a presentation. Accordingly, requests described in 1083 Section 11 can apply to either the whole presentation or an 1084 individual stream within the presentation. Note that some request 1085 methods can only be applied to streams, not presentations and vice 1086 versa. 1088 For example, the RTSP URI: 1090 rtsp://media.example.com:554/twister/audiotrack 1092 may identify the audio stream within the presentation "twister", 1093 which can be controlled via RTSP requests issued over a TCP 1094 connection to port 554 of host media.example.com 1096 Also, the RTSP URI: 1098 rtsp://media.example.com:554/twister 1100 identifies the presentation "twister", which may be composed of audio 1101 and video streams. 1103 This does not imply a standard way to reference streams in 1104 URIs. The presentation description defines the hierarchical 1105 relationships in the presentation and the URIs for the 1106 individual streams. A presentation description may name a 1107 stream "a.mov" and the whole presentation "b.mov". 1109 The path components of the RTSP URI are opaque to the client and do 1110 not imply any particular file system structure for the server. 1112 This decoupling also allows presentation descriptions to be 1113 used with non-RTSP media control protocols simply by 1114 replacing the scheme in the URI. 1116 3.3 Session Identifiers 1118 Session identifiers are strings of any arbitrary length. A session 1119 identifier MUST be chosen randomly and MUST be at least eight 1120 characters long to make guessing it more difficult. (See Section 20.) 1122 3.4 SMPTE Relative Timestamps 1123 A SMPTE relative timestamp expresses time relative to the start of 1124 the clip. Relative timestamps are expressed as SMPTE time codes for 1125 frame-level access accuracy. The time code has the format 1126 hours:minutes:seconds:frames.subframes, 1127 with the origin at the start of the clip. The default smpte format is 1128 "SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 1129 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 1130 use of alternative use of "smpte time". For the "frames" field in the 1131 time value can assume the values 0 through 29. The difference between 1132 30 and 29.97 frames per second is handled by dropping the first two 1133 frame indices (values 00 and 01) of every minute, except every tenth 1134 minute. If the frame value is zero, it may be omitted. Subframes are 1135 measured in one-hundredth of a frame. 1137 Examples: 1139 smpte=10:12:33:20- 1140 smpte=10:07:33- 1141 smpte=10:07:00-10:07:33:05.01 1142 smpte-25=10:07:00-10:07:33:05.01 1144 3.5 Normal Play Time 1146 Normal play time (NPT) indicates the stream absolute position 1147 relative to the beginning of the presentation, not to be confused 1148 with the Network Time Protocol (NTP) [32]. The timestamp consists of 1149 a decimal fraction. The part left of the decimal may be expressed in 1150 either seconds or hours, minutes, and seconds. The part right of the 1151 decimal point measures fractions of a second. 1153 The beginning of a presentation corresponds to 0.0 seconds. Negative 1154 values are not defined. The special constant now is defined as the 1155 current instant of a live type event. It MAY only be used for live 1156 type events, and SHALL NOT be used for on-demand content. 1158 NPT is defined as in DSM-CC [33]: "Intuitively, NPT is the clock the 1159 viewer associates with a program. It is often digitally displayed on 1160 a VCR. NPT advances normally when in normal play mode (scale = 1), 1161 advances at a faster rate when in fast scan forward (high positive 1162 scale ratio), decrements when in scan reverse (high negative scale 1163 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 1164 SMPTE time codes." 1166 Examples: 1168 npt=123.45-125 1169 npt=12:05:35.3- 1170 npt=now- 1172 The syntax conforms to ISO 8601 [34]. The npt-sec notation 1173 is optimized for automatic generation, the ntp-hhmmss 1174 notation for consumption by human readers. The "now" 1175 constant allows clients to request to receive the live feed 1176 rather than the stored or time-delayed version. This is 1177 needed since neither absolute time nor zero time are 1178 appropriate for this case. 1180 3.6 Absolute Time 1182 Absolute time is expressed as ISO 8601 [34] timestamps, using UTC 1183 (GMT). Fractions of a second may be indicated. 1185 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 1186 UTC: 1188 19961108T143720.25Z 1190 3.7 Feature-tags 1192 Feature-tags are unique identifiers used to designate features in 1193 RTSP. These tags are used in Require (Section 14.37), Proxy-Require 1194 (Section 14.31), Proxy-Supported (Section 14.32), Unsupported 1195 (Section 14.46), and Supported (Section 14.43) header fields. 1197 Feature tag needs to indicate which combination of clients, servers, 1198 or proxies they applies too. 1200 The creator of a new RTSP feature-tag should either prefix the 1201 feature-tag with a reverse domain name (e.g., 1202 "com.example.mynewfeature" is an apt name for a feature whose 1203 inventor can be reached at "example.com"), or register the new 1204 feature-tag with the Internet Assigned Numbers Authority (IANA), see 1205 IANA Section 21. 1207 The usage of feature tags are further described in section 10 that 1208 deals with capability handling. 1210 3.8 Entity Tags 1211 Entity tags are opaque strings that are used to compare two entities 1212 from the same resource, for example in caches or to optimize setup 1213 after a redirect. Further explanation is present in [H3.11]. For 1214 explanation on how to compare Entity tags see [H13.3]. Entity tags 1215 can be carried in the ETag header (see section 14.21) or in SDP (see 1216 section C.1.8). 1218 Entity tags are used in RTSP to make some methods conditional. The 1219 methods are made conditional through the inclusion of headers, see 1220 14.25 and 14.27. 1222 4 RTSP Message 1224 RTSP is a text-based protocol and uses the ISO 10646 character set in 1225 UTF-8 encoding (RFC 2279 [13]). Lines SHALL be terminated by CRLF. 1227 Text-based protocols make it easier to add optional 1228 parameters in a self-describing manner. Since the number of 1229 parameters and the frequency of commands is low, processing 1230 efficiency is not a concern. Text-based protocols, if done 1231 carefully, also allow easy implementation of research 1232 prototypes in scripting languages such as Tcl, Visual Basic 1233 and Perl. 1235 The 10646 character set avoids tricky character set switching, but is 1236 invisible to the application as long as US-ASCII is being used. This 1237 is also the encoding used for RTCP. ISO 8859-1 translates directly 1238 into Unicode with a high-order octet of zero. ISO 8859-1 characters 1239 with the most-significant bit set are represented as 1100001x 1240 10xxxxxx. (See RFC 2279 [13]) 1242 Requests contain methods, the object the method is operating upon and 1243 parameters to further describe the method. Methods are idempotent, 1244 unless otherwise noted. Methods are also designed to require little 1245 or no state maintenance at the media server. 1247 4.1 Message Types 1249 See [H4.1]. 1251 4.2 Message Headers 1253 See [H4.2]. 1255 4.3 Message Body 1257 See [H4.3] 1259 4.4 Message Length 1261 When a message body is included with a message, the length of that 1262 body is determined by one of the following (in order of precedence): 1264 1. Any response message which MUST NOT include a message body 1265 (such as the 1xx, 204, and 304 responses) is always 1266 terminated by the first empty line after the header fields, 1267 regardless of the entity-header fields present in the 1268 message. (Note: An empty line consists of only CRLF.) 1270 2. If a Content-Length header field (section 14.16) is 1271 present, its value in bytes represents the length of the 1272 message-body. If this header field is not present, a value 1273 of zero is assumed. 1275 Unlike an HTTP message, an RTSP message MUST contain a Content-Length 1276 header field whenever it contains a message body. Note that RTSP does 1277 not (at present) support the HTTP/1.1 "chunked" transfer coding(see 1278 [H3.6.1]). 1280 Given the moderate length of presentation descriptions 1281 returned, the server should always be able to determine its 1282 length, even if it is generated dynamically, making the 1283 chunked transfer encoding unnecessary. 1285 5 General Header Fields 1287 See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, 1288 and Warning headers are not defined. RTSP further defines the CSeq, 1289 and Timestamp. The general headers are listed in table 1: 1291 Header Name Comment 1292 _________________________________ 1293 Cache-Control See section 14.10 1294 Connection See section 14.11 1295 CSeq See section 14.19 1296 Date See section 14.20 1297 Supported See section 14.43 1298 Timestamp See section 14.44 1299 Via See section 14.49 1301 Table 1: The General headers used in RTSP. 1303 6 Request 1305 A request messages uses the format outlined below, regardless of the 1306 direction of a request, client to server or server to client: 1308 o Request line, containing the method to be applied to the 1309 resource, the identifier of the resource, and the protocol 1310 version in use; 1312 o zero or more Header lines, that can be of the following types: 1313 general (Section 5), request (Section 6.2), or entity (Section 1314 8.1); 1316 o One empty line (CR/LF) to indicate the end of the header 1317 section; 1319 o Optionally a message body (entity), consisting of one or more 1320 lines. the length of the message body in number of bytes is 1321 indicated by the Content-Length entity header. 1323 6.1 Request Line 1325 The request line provides the key information about the request: 1326 What method, on what resources and using which RTSP version. The 1327 methods that are defined by this specification are listed in Table 2. 1329 Method Defined In Section 1330 _________________________________ 1331 DESCRIBE Section 11.2 1332 GET_PARAMETER Section 11.7 1333 OPTIONS Section 11.1 1334 PAUSE Section 11.5 1335 PLAY Section 11.4 1336 REDIRECT Section 11.9 1337 SETUP Section 11.3 1338 SET_PARAMETER Section 11.8 1339 TEARDOWN Section 11.6 1341 Table 2: The RTSP Methods 1343 The syntax of the RTSP request line is the following: 1345 SP SP CRLF 1346 Note: This syntax cannot be freely changed in future versions of 1347 RTSP. This line needs to remain parsable by older RTSP 1348 implementations since it indicates the RTSP version of the message. 1350 In contrast to HTTP/1.1 [3], RTSP requests identify the resource 1351 through an absolute RTSP URI (scheme, host, and port)(see section 1352 3.2) rather than just the absolute path. 1354 HTTP/1.1 requires servers to understand the absolute URI, 1355 but clients are supposed to use the Host request header. 1356 This is purely needed for backward-compatibility with 1357 HTTP/1.0 servers, a consideration that does not apply to 1358 RTSP. 1360 An asterisk "*" can be used in the Request-URI to indicate that the 1361 request does not apply to a particular resource, but to the server or 1362 proxy itself, and is only allowed when the request method does not 1363 necessarily apply to a resource. 1365 For example: 1367 OPTIONS * RTSP/1.1 1369 An OPTIONS in this form will determine the capabilities of the server 1370 or the proxy that first receives the request. If the capability of 1371 the specific server needs to be determined, without regard to the 1372 capability of an intervening proxy, the server should be addressed 1373 explicitly with an absolute URI that contains the server's address. 1375 For example: 1377 OPTIONS rtsp://example.com RTSP/1.1 1379 6.2 Request Header Fields 1381 The RTSP headers in Table 3 can be included in a request, as request 1382 headers, to modify the specifics of the request. These headers may 1383 also be used in the response to a request, as response headers, to 1384 modify the specifics of a response (Section 7.1.2). 1386 Detailed headers definition are provided in Section 14. 1388 Header Defined in Section 1389 _____________________________________ 1390 Accept Section 14.1 1391 Accept-Encoding Section 14.3 1392 Accept-Language Section 14.4 1393 Authorization Section 14.7 1394 Bandwidth Section 14.8 1395 Blocksize Section 14.9 1396 From Section 14.23 1397 If-Match Section 14.25 1398 If-Modified-Since Section 14.26 1399 If-None-Match Section 14.27 1400 Proxy-Require Section 14.31 1401 Range Section 14.34 1402 Referer Section 14.35 1403 Require Section 14.37 1404 Scale Section 14.39 1405 Session Section 14.42 1406 Speed Section 14.40 1407 Supported Section 14.43 1408 Transport Section 14.45 1409 User-Agent Section 14.47 1411 Table 3: The RTSP request headers 1413 7 Response 1415 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1416 Also, RTSP defines additional status codes and does not define some 1417 HTTP codes. The valid response codes and the methods they can be used 1418 with are defined in Table 4. 1420 After receiving and interpreting a request message, the recipient 1421 responds with an RTSP response message. 1423 7.1 Status-Line 1425 The first line of a Response message is the Status-Line, consisting 1426 of the protocol version followed by a numeric status code, and the 1427 textual phrase associated with the status code, with each element 1428 separated by SP characters. No CR or LF is allowed except in the 1429 final CRLF sequence. 1431 SP SP CRLF 1433 7.1.1 Status Code and Reason Phrase 1435 The Status-Code element is a 3-digit integer result code of the 1436 attempt to understand and satisfy the request. These codes are fully 1437 defined in Section 13. The Reason-Phrase is intended to give a short 1438 textual description of the Status-Code. The Status-Code is intended 1439 for use by automata and the Reason-Phrase is intended for the human 1440 user. The client is not required to examine or display the Reason- 1441 Phrase. 1443 The first digit of the Status-Code defines the class of response. The 1444 last two digits do not have any categorization role. There are 5 1445 values for the first digit: 1447 o 1xx: Informational - Request received, continuing process 1449 o 2xx: Success - The action was successfully received, 1450 understood, and accepted 1452 o 3rr: Redirection - Further action needs to be taken in order 1453 to complete the request 1455 o 4xx: Client Error - The request contains bad syntax or cannot 1456 be fulfilled 1458 o 5xx: Server Error - The server failed to fulfill an apparently 1459 valid request 1461 The individual values of the numeric status codes defined for 1462 RTSP/1.1, and an example set of corresponding Reason-Phrases, are 1463 presented in table 4. The reason phrases listed here are only 1464 recommended; they may be replaced by local equivalents without 1465 affecting the protocol. Note that RTSP adopts most HTTP/1.1 [3] 1466 status codes and adds RTSP-specific status codes starting at x50 to 1467 avoid conflicts with newly defined HTTP status codes. 1469 RTSP status codes are extensible. RTSP applications are not required 1470 to understand the meaning of all registered status codes, though such 1471 understanding is obviously desirable. However, applications MUST 1472 understand the class of any status code, as indicated by the first 1473 digit, and treat any unrecognized response as being equivalent to the 1474 x00 status code of that class, with the exception that an 1475 unrecognized response MUST NOT be cached. For example, if an 1476 unrecognized status code of 431 is received by the client, it can 1477 safely assume that there was something wrong with its request and 1478 treat the response as if it had received a 400 status code. In such 1479 cases, user agents SHOULD present to the user the entity returned 1480 with the response, since that entity is likely to include human- 1481 readable information which will explain the unusual status. 1483 7.1.2 Response Header Fields 1485 The response-header fields allow the request recipient to pass 1486 additional information about the response which cannot be placed in 1487 the Status-Line. These header fields give information about the 1488 server and about further access to the resource identified by the 1489 Request-URI. All headers currently being classified as response 1490 headers are listed in table 5. 1492 Response-header field names can be extended reliably only in 1493 combination with a change in the protocol version. However, new or 1494 experimental header fields MAY be given the semantics of response- 1495 header fields if all parties in the communication recognize them to 1496 be response-header fields. Unrecognized header fields are treated as 1497 entity-header fields. 1499 8 Entity 1501 Request and Response messages MAY transfer an entity if not otherwise 1502 restricted by the request method or response status code. An entity 1503 consists of entity-header fields and an entity-body, although some 1504 responses will only include the entity-headers. 1506 The SET_PARAMETER, and GET_PARAMETER request and response, and 1507 DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY 1508 also have an entity. 1510 In this section, both sender and recipient refer to either the client 1511 or the server, depending on who sends and who receives the entity. 1513 8.1 Entity Header Fields 1515 Entity-header fields define optional meta-information about the 1516 entity-body or, if no body is present, about the resource identified 1517 by the request. The entity header fields are listed in table 8.1. 1519 The extension-header mechanism allows additional entity-header fields 1520 to be defined without changing the protocol, but these fields cannot 1521 be assumed to be recognizable by the recipient. Unrecognized header 1522 fields SHOULD be ignored by the recipient and forwarded by proxies. 1524 8.2 Entity Body 1525 See [H7.2] with the addition that an RTSP message with an entity body 1526 MUST include the Content-Type and Content-Length headers. 1528 9 Connections 1530 RTSP requests can be transmitted over two different connection 1531 scenarios listed below: 1533 o persistent - transport connections used for several 1534 request/response transactions; 1536 o transient - transport connections used for a single 1537 request/response transaction. 1539 RFC 2326 attempted to specify an optional mechanism for transmitting 1540 RTSP messages in connectionless mode over a transport protocol such 1541 as UDP. However, it was not specified in sufficient enough detail to 1542 allow for interoperable implementations. In an attempt to reduce 1543 complexity and scope, and due to lack of interest, RTSP 1.1 does not 1544 attempt to define a mechanism for supporting RTSP over UDP or other 1545 connectionless transport protocols. A side-effect is that RTSP 1546 requests SHALL NOT be sent to multicast groups since no connection 1547 can be established with a specific receiver in multicast 1548 environments. 1550 Certain RTSP headers, such as the CSeq header (Section 14.19), which 1551 may appear to be relevant to only connectionless transport scenarios 1552 are still retained and must be implemented according to the 1553 specification. In the case of CSeq it is quite useful in proxy 1554 situations for keeping track of the different request when 1555 aggregating several client requests to a single TCP connection. 1557 9.1 Reliability and Acknowledgements 1559 Since RTSP is transmitted primarily over connection oriented, 1560 reliable transport protocols, all RTSP requests MUST be acknowledged 1561 by the receiver. RTSP requests that are not immediately acknowledged 1562 MUST NOT be retransmitted at the application level. Instead, the 1563 application must rely on the underlying transport to provide 1564 reliability. 1566 If both the underlying reliable transport such as TCP and 1567 the RTSP application retransmit requests, each packet loss 1568 or message loss may result in two retransmissions. The 1569 receiver typically cannot take advantage of the 1570 application-layer retransmission since the transport stack 1571 will not deliver the application-layer retransmission 1572 Code Reason Method 1573 __________________________________________________________ 1574 100 Continue all 1576 __________________________________________________________ 1577 200 OK all 1578 201 Reserved n/a 1579 250 Reserved n/a 1580 __________________________________________________________ 1581 300 Multiple Choices all 1582 301 Moved Permanently all 1583 302 Found all 1584 303 See Other all 1585 305 Use Proxy all 1587 __________________________________________________________ 1588 400 Bad Request all 1589 401 Unauthorized all 1590 402 Payment Required all 1591 403 Forbidden all 1592 404 Not Found all 1593 405 Method Not Allowed all 1594 406 Not Acceptable all 1595 407 Proxy Authentication Required all 1596 408 Request Timeout all 1597 410 Gone all 1598 411 Length Required all 1599 412 Precondition Failed DESCRIBE, SETUP 1600 413 Request Entity Too Large all 1601 414 Request-URI Too Long all 1602 415 Unsupported Media Type all 1603 451 Parameter Not Understood SET_PARAMETER 1604 452 reserved n/a 1605 453 Not Enough Bandwidth SETUP 1606 454 Session Not Found all 1607 455 Method Not Valid In This State all 1608 456 Header Field Not Valid all 1609 457 Invalid Range PLAY, PAUSE 1610 458 Parameter Is Read-Only SET_PARAMETER 1611 459 Aggregate Operation Not Allowed all 1612 460 Only Aggregate Operation Allowed all 1613 461 Unsupported Transport all 1614 462 Destination Unreachable all 1615 463 Destination Prohibited SETUP 1616 470 Connection Authorization Required all 1617 471 Connection Credentials not accepted all 1618 __________________________________________________________ 1619 500 Internal Server Error all 1620 501 Not Implemented all 1621 502 Bad Gateway all 1622 503 Service Unavailable all 1623 504 Gateway Timeout all 1625 Table 4: Status codes and their usage with RTSP methods 1627 Header Defined in Section 1628 __________________________________________ 1629 Accept-Ranges Section 14.5 1630 Connection-Credentials Section 14.12 1631 ETag Section 14.21 1632 Location Section 14.29 1633 Proxy-Authenticate Section 14.30 1634 Public Section 14.33 1635 Range Section 14.34 1636 Retry-After Section 14.36 1637 RTP-Info Section 14.38 1638 Scale Section 14.39 1639 Session Section 14.42 1640 Server Section 14.41 1641 Speed Section 14.40 1642 Transport Section 14.45 1643 Unsupported Section 14.46 1644 Vary Section 14.48 1645 WWW-Authenticate Section 14.50 1647 Table 5: The RTSP response headers 1649 Header Defined in Section 1651 ____________________________________ 1652 Allow Section 14.6 1653 Content-Base Section 14.13 1654 Content-Encoding Section 14.14 1655 Content-Language Section 14.15 1656 Content-Length Section 14.16 1657 Content-Location Section 14.17 1658 Content-Type Section 14.18 1659 Expires Section 14.22 1660 Last-Modified Section 14.28 1662 Table 6: The RTSP entity headers 1664 before the first attempt has reached the receiver. If the 1665 packet loss is caused by congestion, multiple 1666 retransmissions at different layers will exacerbate the 1667 congestion. 1669 Lack of acknowledgement of an RTSP request should be handled within 1670 the constraints of the connection timeout considerations described 1671 below (Section 9.4). 1673 9.2 Using Connections 1675 A TCP transport can be used for both persistent connections (for 1676 several message exchanges) and transient connections (for a single 1677 message exchange). Implementations of this specification MUST support 1678 RTSP over TCP. The scheme of the RTSP URI (Section 3.2) indicates the 1679 default port that the server will listen on. 1681 A server MUST handle both persistent and transient connections. 1683 Transient connections facilitate mechanisms for fault 1684 tolerance. They also allow for application layer mobility. 1685 A server and client pair that support transient connections 1686 can survive the loss of a TCP connection, e.g. due to a NAT 1687 timeout. When the client has discovered that the TCP 1688 connection has been lost, it can set up a new one when 1689 there is need to communicate again. 1691 A persistent connection MAY be used for all transactions between the 1692 server and client, including messages to multiple RTSP sessions. 1693 However a persistent connection MAY also be closed after a few 1694 message exchanges. For example, a client may use a persistent 1695 connection for the initial SETUP and PLAY message exchanges in a 1696 session and then close the connection. Later, when the client wishes 1697 to send a new request, such as a PAUSE for the session, a new 1698 connection would be opened. This connection may either be transient 1699 or persistent. 1701 A client SHOULD NOT have more than one connection to the server at 1702 any given point. If a client or proxy handles multiple RTSP sessions 1703 on the same server, it SHOULD use only one connection for managing 1704 those sessions. 1706 This saves connection resources on the server. It also 1707 reduces complexity by and enabling the server to maintain 1708 less state about its sessions and connections. 1710 Unlike HTTP, RTSP allows a server to send requests to a client. 1711 However, this can be supported only if a client establishes a 1712 persistent connection with the server. In cases where a persistent 1713 connection does not exist between a server and its client, due to the 1714 lack of a signalling channel, the server may be forced to drop an 1715 RTSP session without notifying the client. An example of such a case 1716 is when the server desires to send a REDIRECT request for an RTSP 1717 session to the client but is not able to do so because it cannot 1718 reach the client. 1720 Without a persistent connection between the client and the 1721 server, the media server has no reliable way of reaching 1722 the client. Also, this is the only way that requests from a 1723 server to its client are likely to traverse firewalls. 1725 In light of the above, it is RECOMMENDED that clients use persistent 1726 connections whenever possible. A client that supports persistent 1727 connections MAY "pipeline" its requests (i.e., send multiple requests 1728 without waiting for each response). A server MUST send its responses 1729 to those requests in the order that the requests were received. 1731 9.3 Closing Connections 1733 The client MAY close a connection at any point when no outstanding 1734 request/response transactions exist for any RTSP session being 1735 managed through the connection. The server, however, SHOULD NOT close 1736 a connection until all RTSP sessions being managed through the 1737 connection have been timed out (Section 14.42). A server SHOULD NOT 1738 close a connection immediately after responding to a session-level 1739 TEARDOWN request for the last RTSP session being controlled through 1740 the connection. Instead, it should wait for a reasonable amount of 1741 time for the client to: receive the TEARDOWN response, take 1742 appropriate action, and initiate the connection closing. The server 1743 SHOULD wait at least 10 seconds after sending the TEARDOWN response 1744 before closing the connection. 1746 This is to ensure that the client has time to issue a SETUP 1747 for a new session on the existing connection after having 1748 torn the last one down. 10 seconds should give the client 1749 ample opportunity get its message to the server. 1751 A server SHOULD NOT close the connection directly as a result of 1752 responding to a request with an error code. 1754 Certain error responses such as "460 Only Aggregate 1755 Operation Allowed" (Section 13.4.12) are used for 1756 negotiating capabilities of a server with respect to 1757 content or other factors. In such cases, it is inefficient 1758 for the server to close a connection on an error response. 1759 Also, such behavior would prevent implementation of 1760 advanced/special types of requests or result in extra 1761 overhead for the client when testing for new features. On 1762 the flip side, keeping connections open after sending an 1763 error response poses a Denial of Service security risk 1764 (Section 20). 1766 If a server initiates a connection close while the client is 1767 attempting to send a new request, the client will have to close its 1768 current connection, establish a new connection and send its request 1769 over the new connection. 1771 An RTSP message should not be terminated through a connection close. 1772 Such a message will be considered to be incomplete by the receiver 1773 and discarded. An RTSP message is properly terminated as defined in 1774 Section 4. 1776 9.4 Timing Out Connections and RTSP Messages 1778 Receivers of a request (responder) SHOULD respond to requests in a 1779 timely manner even when a reliable transport such as TCP is used. 1780 Similarly, the sender of a request (requestor) SHOULD wait for a 1781 sufficient time for a response before concluding that the responder 1782 will not be acting upon its request. 1784 A responder SHOULD respond to all requests within 5 seconds. If the 1785 responder recognizes that processing of a request will take longer 1786 than 5 seconds, it SHOULD send a 100 response as soon as possible. It 1787 SHOULD continue sending a 100 response every 5 seconds thereafter 1788 until it is ready to send the final response to the requestor. After 1789 sending a 100 response, the receiver MUST send a final response 1790 indicating the success or failure of the request. 1792 A requestor SHOULD wait at least 10 seconds for a response before 1793 concluding that the responder will not be responding to its request. 1794 After receiving a 100 response, the requestor SHOULD continue waiting 1795 for further responses. If more than 10 seconds elapses without 1796 receiving any response, the requestor MAY assume that the responder 1797 is unresponsive and abort the connection. 1799 A requestor SHOULD wait longer than 10 seconds for a response if it 1800 is experiencing significant transport delays on its connection to the 1801 responder. The requestor is capable of determining the RTT of the 1802 request/response cycle using the Timestamp header (section 14.44) in 1803 any RTSP request. 1805 9.5 Use of IPv6 1807 Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP 1808 1.1 has been updated for explicit IPv6 support. Implementations of 1809 RTSP 1.1 MUST understand literal IPv6 addresses in URIs and headers. 1811 10 Capability Handling 1813 This section describes the capability handling mechanism available in 1814 RTSP which allows RTSP to be extended. Extensions to this version of 1815 the protocol are basically done in two ways. First, new headers can 1816 be added. Secondly, new methods can be added. The capability handling 1817 mechanism is designed to handle both cases. 1819 When a method is added, the involved parties can use the OPTIONS 1820 method to discover wether it is supported. This is done by issuing a 1821 OPTIONS request to the other party. Depending on the URI it will 1822 either apply in regards to a certain media resource, the whole server 1823 in general, or simply the next hop. The OPTIONS response will contain 1824 a Public header which declares all methods supported for the 1825 indicated resource. 1827 It is not necessary to use OPTIONS to discover support of a method, 1828 the client could simply try the method. If the receiver of the 1829 request does not support the method it will respond with an error 1830 code indicating the the method is either not implemented (501) or 1831 does not apply for the resource (405). The choice between the two 1832 discovery methods depends on the requirements of the service. 1834 Feature-Tags are defined to handle functionality additions that are 1835 not new methods. Each feature-tag represents a certain block of 1836 functionality. The amount of functionality that a feature-tag 1837 represents can vary significantly. A feature-tag can for example 1838 represent the functionality a single RTSP header provides. Another 1839 feature-tag can represent much more functionality, such as the 1840 "play.basic" feature tag which represents the minimal playback 1841 implementation. 1843 Feature-tags are used to determine wether the client, server or proxy 1844 supports the functionality that is necessary to achieve the desired 1845 service. To determine support of a feature-tag, several different 1846 headers can be used, each explained below: 1848 Supported: The supported header is used to determine the 1849 complete set of functionality that both client and server 1850 have. The intended usage is to determine before one needs 1851 to use a functionality that it is supported. It can be used 1852 in any method, however OPTIONS is the most suitable one as 1853 it at the same time determines all methods that are 1854 implemented. When sending a request the requestor declares 1855 all its capabilities by including all supported feature- 1856 tags. This results in that the receiver learns the 1857 requestors feature support. The receiver then includes its 1858 set of features in the response. 1860 Proxy-Supported: The Proxy-Supported header is used similar to 1861 the Supported header, but instead of giving the supported 1862 functionality of the client or server it provides both the 1863 requestor and the responder a view of what functionality 1864 the proxy chain between the two supports. Proxies are 1865 required to add this header whenever the Supported header 1866 is present, but proxies may independently of the requestor 1867 add it. 1869 Require: The Require header can be included in any request where 1870 the end-point, i.e. the client or server, is required to 1871 understand the feature to correctly perform the request. 1872 This can, for example, be a SETUP request where the server 1873 is required to understand a certain parameter to be able to 1874 set up the media delivery correctly. Ignoring this 1875 parameter would not have the desired effect and is not 1876 acceptable. Therefore the end-point receiving a request 1877 containing a Require MUST negatively acknowledge any 1878 feature that it does not understand and not perform the 1879 request. The response in cases where features are not 1880 supported are 551 (Option Not Supported). Also the 1881 features that are not supported are given in the 1882 Unsupported header in the response. 1884 Proxy-Require: This method has the same purpose and workings as 1885 Require except that it only applies to proxies and not the 1886 end-point. Features that needs to be supported by both 1887 proxies and end-point needs to be included in both the 1888 Require and Proxy-Require header. 1890 Unsupported: This header is used in a 551 error response, to 1891 indicate which feature(s) that was not supported. Such a 1892 response is only the result of the usage of the Require 1893 and/or Proxy-Require header where one or more feature where 1894 not supported. This information allows the requestor to 1895 make the best of situations as it knows which features are 1896 not supported. 1898 11 Method Definitions 1900 The method indicates what is to be performed on the resource 1901 identified by the Request-URI. The method name is case-sensitive. 1902 New methods may be defined in the future. Method names SHALL NOT 1903 start with a $ character (decimal 24) and MUST be a token as defined 1904 by the ABNF [4] in the syntax chapter 19. The methods are summarized 1905 in Table 7. 1907 method direction object Server req. Client req. 1908 ___________________________________________________________________ 1909 DESCRIBE C -> S P,S recommended recommended 1910 GET_PARAMETER C -> S, S -> C P,S optional optional 1911 OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt 1912 PAUSE C -> S P,S required required 1913 PLAY C -> S P,S required required 1914 REDIRECT S -> C P,S optional required 1915 SETUP C -> S S required required 1916 SET_PARAMETER C -> S, S -> C P,S required optional 1917 TEARDOWN C -> S P,S required required 1919 Table 7: Overview of RTSP methods, their direction, and what objects 1920 (P: presentation, S: stream) they operate on. Legend: R=Respond, 1921 Sd=Send, Opt: Optional, Req: Required, Rec: Recommended 1923 Note on Table 7: GET_PARAMETER is recommended, but not 1924 required. For example, a fully functional server can be 1925 built to deliver media without any parameters. 1926 SET_PARAMETER is required however due to its usage for 1927 keep-alive. PAUSE is now required due to that it is the 1928 only way of getting out of the state machines play state 1929 without terminating the whole session. 1931 If an RTSP agent does not support a particular method, it MUST return 1932 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 1933 NOT try this method again for the given agent / resource combination. 1935 11.1 OPTIONS 1937 The semantics of the RTSP OPTIONS method is equivalent to that of the 1938 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 1939 bi-directional, in that a client can request it to a server and vice 1940 versa. A client MUST implement the capability to send an OPTIONS 1941 request and a server or a proxy MUST implement the capability to 1942 respond to an OPTIONS request. The client, server or proxy MAY also 1943 implement the converse of their required capability. 1945 An OPTIONS request may be issued at any time. Such a request does not 1946 modify the session state. However, it may prolong the session 1947 lifespan (see below). The URI in an OPTIONS request determines the 1948 scope of the request and the corresponding response. If the Request- 1949 URI refers to a specific media resource on a given host, the scope is 1950 limited to the set of methods supported for that media resource by 1951 the indicated RTSP agent. A Request-URI with only the host address 1952 limits the scope to the specified RTSP agent's general capabilities 1953 without regard to any specific media. If the Request-URI is an 1954 asterisk ("*"), the scope is limited to the general capabilities of 1955 the next hop (i.e. the RTSP agent in direct communication with the 1956 request sender). 1958 Regardless of scope of the request, the Public header MUST always be 1959 included in the OPTIONS response listing the methods that are 1960 supported by the responding RTSP agent. In addition, if the scope of 1961 the request is limited to a media resource, the Allow header MUST be 1962 included in the response to enumerate the set of methods that are 1963 allowed for that resource unless the set of methods completely 1964 matches the set in the Public header. If the given resource is not 1965 available, the RTSP agent SHOULD return an appropriate response code 1966 such as 3rr or 4xx. The Supported header MAY be included in the 1967 request to query the set of features that are supported by the 1968 responding RTSP agent. 1970 The OPTIONS method can be used to keep an RTSP session alive. 1971 However, it is not the preferred means of session keep-alive 1972 signalling, see section 14.42. An OPTIONS request intended for 1973 keeping alive an RTSP session MUST include the Session header with 1974 the associated session ID. Such a request SHOULD also use the media 1975 or the aggregated control URI as the Request-URI. 1977 Example: 1979 C->S: OPTIONS * RTSP/1.1 1980 CSeq: 1 1981 User-Agent: PhonyClient/1.2 1982 Require: 1983 Proxy-Require: gzipped-messages 1984 Supported: play.basic 1986 S->C: RTSP/1.1 200 OK 1987 CSeq: 1 1988 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1989 Supported: play.basic, implicit-play, gzipped-messages 1990 Server: PhonyServer/1.1 1992 Note that some of the feature-tags in Require and Proxy-Require are 1993 necessarily fictional features (one would hope that we would not 1994 purposefully overlook a truly useful feature just so that we could 1995 have a strong example in this section). 1997 11.2 DESCRIBE 1998 The DESCRIBE method is used to retrieve the description of a 1999 presentation or media object from a server. The Request-URI of the 2000 DESCRIBE request identifies the media resource of interest. The 2001 client MAY include the Accept header in the request to list the 2002 description formats that it understands. The server SHALL respond 2003 with a description of the requested resource and return the 2004 description in the entity of the response. The DESCRIBE reply- 2005 response pair constitutes the media initialization phase of RTSP. 2007 Example: 2009 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.1 2010 CSeq: 312 2011 User-Agent: PhonyClient 1.2 2012 Accept: application/sdp, application/rtsl, application/mheg 2014 S->C: RTSP/1.1 200 OK 2015 CSeq: 312 2016 Date: 23 Jan 1997 15:35:06 GMT 2017 Server: PhonyServer 1.1 2018 Content-Type: application/sdp 2019 Content-Length: 367 2021 v=0 2022 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 2023 s=SDP Seminar 2024 i=A Seminar on the session description protocol 2025 u=http://www.example.com/lectures/sdp.ps 2026 e=seminar@example.com (Seminar Management) 2027 c=IN IP4 224.2.17.12/127 2028 t=2873397496 2873404696 2029 a=recvonly 2030 m=audio 3456 RTP/AVP 0 2031 m=video 2232 RTP/AVP 31 2032 m=application 32416 UDP WB 2033 a=orient:portrait 2035 The DESCRIBE response SHOULD contain all media initialization 2036 information for the resource(s) that it describes. Servers SHOULD NOT 2037 use the DESCRIBE response as a means of media indirection by having 2038 the description point at another server, instead usage of 3rr 2039 responses are recommended. 2041 By forcing a DESCRIBE response to contain all media 2042 initialization for the set of streams that it describes, 2043 and discouraging the use of DESCRIBE for media indirection, 2044 any looping problems can be avoided that might have 2045 resulted from other approaches. 2047 Media initialization is a requirement for any RTSP-based system, but 2048 the RTSP specification does not dictate that this is required to be 2049 done via the DESCRIBE method. There are three ways that an RTSP 2050 client may receive initialization information: 2052 o via an RTSP DESCRIBE request 2054 o via some other protocol (HTTP, email attachment, etc.) 2056 o via some form of a user interface 2058 If a client obtains a valid description from an alternate source, the 2059 client MAY use this description for initialization purposes without 2060 issuing a DESCRIBE request for the same media. 2062 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2063 and highly recommended that minimal clients support the ability to 2064 act as "helper applications" that accept a media initialization file 2065 from a user interface, and/or other means that are appropriate to the 2066 operating environment of the clients. 2068 11.3 SETUP 2070 The SETUP request for an URI specifies the transport mechanism to be 2071 used for the streamed media. The SETUP method may be used in three 2072 different cases; Create an RTSP session, add a media to a session, 2073 and change the transport parameters of already set up media stream. 2074 When in PLAY state, using SETUP to create or add media to a session 2075 when in PLAY state is unspecified. Otherwise SETUP can be used in all 2076 three states; INIT, and READY, for both purposes and in PLAY to 2077 change the transport parameters. 2079 The Transport header, see section 14.45, specifies the transport 2080 parameters acceptable to the client for data transmission; the 2081 response will contain the transport parameters selected by the 2082 server. This allows the client to enumerate in priority order the 2083 transport mechanisms and parameters acceptable to it, while the 2084 server can select the most appropriate. It is expected that the 2085 session description format used will enable the client to select a 2086 limited number possible configurations that are offered to the server 2087 to choose from. All transport parameters SHOULD be included in the 2088 Transport header, the use of other headers for this purpose is 2089 discouraged due to middle boxes such as firewalls, or NATs. 2091 For the benefit of any intervening firewalls, a client SHOULD 2092 indicate the transport parameters even if it has no influence over 2093 these parameters, for example, where the server advertises a fixed 2094 multicast address. 2096 Since SETUP includes all transport initialization 2097 information, firewalls and other intermediate network 2098 devices (which need this information) are spared the more 2099 arduous task of parsing the DESCRIBE response, which has 2100 been reserved for media initialization. 2102 In a SETUP response the server SHOULD include the Accept-Ranges 2103 header (see section 14.5 to indicate which time formats that are 2104 acceptable to use for this media resource. 2106 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.1 2107 CSeq: 302 2108 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 2109 RTP/AVP/TCP;unicast;interleaved=0-1 2111 S->C: RTSP/1.1 200 OK 2112 CSeq: 302 2113 Date: 23 Jan 1997 15:35:06 GMT 2114 Server: PhonyServer 1.1 2115 Session: 47112344;timeout=60 2116 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; 2117 src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; 2118 ssrc=2A3F93ED 2119 Accept-Ranges: NPT 2121 In the above example the client wants to create an RTSP session 2122 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 2123 The transport parameters acceptable to the client is either 2124 RTP/AVP/UDP (UDP per default) to be received on client port 4588 and 2125 4589 or RTP/AVP interleaved on the RTSP control channel. The server 2126 selects the RTP/AVP/UDP transport and adds the ports it will send and 2127 received RTP and RTCP from, and the RTP SSRC that will be used by the 2128 server. 2130 The server MUST generate a session identifier in response to a 2131 successful SETUP request, unless a SETUP request to a server includes 2132 a session identifier, in which case the server MUST bundle this setup 2133 request into the existing session (aggregated session) or return 2134 error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). 2136 An Aggregate control URI MUST be used to control an aggregated 2137 session. This URI MUST be different from the stream control URIs of 2138 the individual media streams included in the aggregate. The Aggregate 2139 control URI is to be specified by the session description if the 2140 server supports aggregated control and aggregated control is desired 2141 for the session. However even if aggregated control is offered the 2142 client MAY chose to not set up the session in aggregated control. If 2143 an Aggregate control URI is not specified in the session description, 2144 it is normally an indication that non-aggregated control should be 2145 used. The SETUP of media streams in an aggregate which has not been 2146 given an aggregated control URI is unspecified. 2148 While the session ID sometimes has enough information for 2149 aggregate control of a session, the Aggregate control URI 2150 is still important for some methods such as SET_PARAMETER 2151 where the control URI enables the resource in question to 2152 be easily identified. The Aggregate control URI is also 2153 useful for proxies, enabling them to route the request to 2154 the appropriate server, and for logging, where it is useful 2155 to note the actual resource that a request was operating 2156 on. 2158 A session will exist until it is either removed by a TEARDOWN request 2159 or is timed-out by the server. The server MAY remove a session that 2160 has not demonstrated liveness signs from the client(s) within a 2161 certain timeout period. The default timeout value is 60 seconds; the 2162 server MAY set this to a different value and indicate so in the 2163 timeout field of the Session header in the SETUP response. For 2164 further discussion see section 14.42. Signs of liveness for an RTSP 2165 session are: 2167 o Any RTSP request from a client(s) which includes a Session 2168 header with that session's ID. 2170 o If RTP is used as a transport for the underlying media 2171 streams, an RTCP sender or receiver report from the client(s) 2172 for any of the media streams in that RTSP session. RTCP Sender 2173 Reports may for example be received in sessions where the 2174 server is invited into a conference session and is as valid 2175 for keep-alive. 2177 If a SETUP request on a session fails for any reason, the session 2178 state, as well as transport and other parameters for associated 2179 streams SHALL remain unchanged from their values as if the SETUP 2180 request had never been received by the server. 2182 11.3.1 Changing Transport Parameters 2183 A client MAY issue a SETUP request for a stream that is already set 2184 up or playing in the session to change transport parameters, which a 2185 server MAY allow. If it does not allow changing of parameters, it 2186 MUST respond with error 455 (Method Not Valid In This State). Reasons 2187 to support changing transport parameters, is to allow for application 2188 layer mobility and flexibility to utilize the best available 2189 transport as it becomes available. If a client receives a 455 when 2190 trying to change transport parameters while the server is in play 2191 state, it MAY try to put the server in ready state using PAUSE. 2192 Before trying issuing the SETUP request again. If also that fails the 2193 changing of transport parameters will require that the client 2194 performs a TEARDOWN of the affected media and then setting it up 2195 again. In aggregated session avoiding tearing down all the media at 2196 the same time will avoid the creation of a new session. 2198 All transport parameters MAY be changed. However the primary usage 2199 expected is to either change transport protocol completely, like 2200 switching from Interleaved TCP mode to RTP or vise versa or change 2201 delivery address. 2203 In a SETUP response for a request to change the transport parameters 2204 while in Play state, the server SHOULD include the Range to indicate 2205 from what point the new transport parameters are used. Further, if 2206 RTP is used for delivery, the server SHOULD also include the RTP-Info 2207 header to indicate from what timestamp and RTP sequence number the 2208 change has taken place. If both RTP-Info and Range is included in the 2209 response the "rtp_time" parameter and range MUST be for the 2210 corresponding time, i.e. be used in the same way as for PLAY to 2211 ensure the correct synchronization information is available. 2213 If the transport parameters change while in PLAY state results in a 2214 change of synchronization related information, for example changing 2215 RTP SSRC, the server MUST provide in the SETUP response the necessary 2216 synchronization information. However the server is RECOMMENDED to 2217 avoid changing the synchronization information if possible. 2219 11.4 PLAY 2221 The PLAY method tells the server to start sending data via the 2222 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 2223 until any outstanding SETUP requests have been acknowledged as 2224 successful. PLAY requests are valid when the session is in READY or 2225 PLAY states. A PLAY request MUST include a Session header to indicate 2226 which session the request applies to. 2228 In an aggregated session the PLAY request MUST contain an aggregated 2229 control URI. A server SHALL responde with error 460 (Only Aggregate 2230 Operation Allowed) if the client PLAY Request-URI is for one of the 2231 media. The media in an aggregate SHALL be played in sync. If a client 2232 want individual control of the media it needs to use separate RTSP 2233 sessions for each media. 2235 The PLAY request SHALL position the normal play time to the beginning 2236 of the range specified by the Range header and delivers stream data 2237 until the end of the range if given, else to the end of the media is 2238 reached. To allow for precise composition multiple ranges MAY be 2239 specified in one PLAY Request. The range values are valid if all 2240 given ranges are part of any media within the aggregate. If a given 2241 range value points outside of the media, the response SHALL be the 2242 457 (Invalid Range) error code. 2244 The below example will first play seconds 10 through 15, then, 2245 immediately following, seconds 20 to 25, and finally seconds 30 2246 through the end. 2248 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.1 2249 CSeq: 835 2250 Session: 12345678 2251 Range: npt=10-15, npt=20-25, npt=30- 2253 See the description of the PAUSE request for further examples. 2255 A PLAY request without a Range header is legal. It SHALL start 2256 playing a stream from the beginning (npt=0-) unless the stream has 2257 been paused or is currently playing. If a stream has been paused via 2258 PAUSE, stream delivery resumes at the pause point. If a stream is 2259 currently playing, the new PLAY begins at the current stream 2260 position. The stream SHALL play until the end of the media. 2262 The Range header MUST NOT contain a time parameter. The usage of time 2263 in PLAY method has been deprecated. If a request with time parameter 2264 is received the server SHOULD respond with a 457 (Invalid Range) to 2265 indicate that the time parameter is not supported. 2267 Server MUST include a "Range" header in any PLAY response. The 2268 response MUST use the same format as the request's range header 2269 contained. If no Range header was in the request, the NPT time format 2270 SHOULD be used unless the client showed support for an other format 2271 more appropriate. Also for a session with live media streams the 2272 Range header MUST indicate a valid time. It is RECOMMENDED that 2273 normal play time is used, either the "now" indicator, for example 2274 "npt=now-", or the time since session start as an open interval, e.g. 2275 "npt=96.23-". An absolute time value (clock) for the corresponding 2276 time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock 2277 format SHOULD only be used if client has shown support for it. 2279 A media server only supporting playback MUST support the npt format 2280 and MAY support the clock and smpte formats. 2282 For an on-demand stream, the server MUST reply with the actual range 2283 that will be played back, i.e. for which duration any media (having 2284 content at this time) is delivered. This may differ from the 2285 requested range if alignment of the requested range to valid frame 2286 boundaries is required for the media source. Note that some media 2287 streams in an aggregate may need to be delivered from even earlier 2288 points. Also, some media format have a very long duration per 2289 individual data unit, therefore it might be necessary for the client 2290 to parse the data unit, and select where to start. 2292 Example: Single audio stream (MIDI) 2294 C->S: PLAY rtsp://example.com/audio RTSP/1.1 2295 CSeq: 836 2296 Session: 12345678 2297 Range: npt=7.05- 2299 S->C: RTSP/1.1 200 OK 2300 CSeq: 836 2301 Date: 23 Jan 1997 15:35:06 GMT 2302 Server: PhonyServer 1.0 2303 Range: npt=3.52- 2304 RTP-Info:url="rtsp://example.com/audio" 2305 ssrc=0D12F123:seq=14783;rtptime=2345962545 2307 S->C: RTP Packet TS=2345962545 => NPT=3.52 2308 Duration: 4.15 seconds 2310 In this example the client receives the first media packet that 2311 stretches all the way up and past the requested playtime. Thus, it is 2312 the client's decision if to render to the user the time between 3.52 2313 and 7.05, or to skip it. In most cases it is probably most suitable 2314 to not render that time period. 2316 For live media sources it might be impossible to specify from which 2317 point in time all media streams carrying active content can actually 2318 be delivered. Therefore a server MAY specify a start time (or now-) 2319 in the range header, for which not all media will be available from. 2321 If no range is specified in the request, the start position SHALL 2322 still be returned in the reply. If the medias that are part of an 2323 aggregate has different lengths, the PLAY request SHALL be performed 2324 as long as the given range is valid for any media, for example the 2325 longest media. Media will be sent whenever it is available for the 2326 given play-out point. 2328 A PLAY response MAY include a header(s) carrying synchronization 2329 information. As the information necessary is dependent on the media 2330 transport format, further rules specifying the header and its usage 2331 is needed. For RTP the RTP-Info header is specified, see section 2332 14.38. 2334 After playing the desired range, the presentation does NOT transition 2335 to the READY state, media delivery simply stops. A PAUSE request MUST 2336 be issued before the stream enters the READY state. A PLAY request 2337 while the stream is still in the PLAYING state is legal, and can be 2338 issued without an intervening PAUSE request. Such a request SHALL 2339 replace the current PLAY action with the new one requested, i.e. 2340 being handle the same as the request was received in ready state. In 2341 the case the first time range in Range header has a open start time 2342 (-endtime), the server SHALL continue to play from where it currently 2343 was. 2345 A client desiring to play the media from the beginning MUST send a 2346 PLAY request with a Range header pointing at the beginning, e.g. 2347 npt=0-. If a PLAY request is received without a Range header when 2348 media delivery has stopped at the end, the server SHOULD respond with 2349 a 457 "Invalid Range" error response. In that response the current 2350 pause point in a Range header SHALL be included. 2352 The following example plays the whole presentation starting at SMPTE 2353 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2354 headers has been broken into several lines to fit the page. 2356 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.1 2357 CSeq: 833 2358 Session: 12345678 2359 Range: smpte=0:10:20- 2361 S->C: RTSP/1.1 200 OK 2362 CSeq: 833 2363 Date: 23 Jan 1997 15:35:06 GMT 2364 Server: PhonyServer 1.0 2365 Range: smpte=0:10:22-0:15:45 2366 RTP-Info:url="rtsp://example.com/twister.en" 2367 ssrc=0D12F123:seq=14783;rtptime=2345962545 2369 For playing back a recording of a live presentation, it may be 2370 desirable to use clock units: 2372 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.1 2373 CSeq: 835 2374 Session: 12345678 2375 Range: clock=19961108T142300Z-19961108T143520Z 2377 S->C: RTSP/1.1 200 OK 2378 CSeq: 835 2379 Date: 23 Jan 1997 15:35:06 GMT 2380 Server:PhonyServer 1.0 2381 Range: clock=19961108T142300Z-19961108T143520Z 2382 RTP-Info:url="rtsp://example.com/meeting.en" 2383 ssrc=0D12F123:seq=53745;rtptime=484589019 2385 All range specifiers in this specification allow for ranges with 2386 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2387 request, the server treats this as a request to start/resume playback 2388 from the current pause point, ending at the end time specified in the 2389 Range header. If the pause point is located later than the given end 2390 value, a 457 (Invalid Range) response SHALL be given. 2392 The possibility to replace a current PLAY request with a new one 2393 replaces two RTSP 1.0 functions: 2395 o The queued play functionality described in RFC 2326 [24] is 2396 removed and multiple ranges can be used to achieve a similar 2397 functionality. 2399 o The use of PLAY for keep-alive signaling, i.e. PLAY request 2400 without a range header in PLAY state, has also been 2401 deprecated. Instead a client can use, SET_PARAMETER 2402 (recommended) or OPTIONS (allowed) for keep alive. 2404 11.5 PAUSE 2406 The PAUSE request causes the stream delivery to be interrupted 2407 (halted) temporarily. A PAUSE request MUST be done with the 2408 aggregated control URI for aggregated sessions, resulting in all 2409 media being halted, or the media URI for non-aggregated sessions. 2410 Any attempt to do muting of a single media with an PAUSE request in 2411 an aggregated session SHALL be responded with error 460 (Only 2412 Aggregate Operation Allowed). After resuming playback, 2413 synchronization of the tracks MUST be maintained. Any server 2414 resources are kept, though servers MAY close the session and free 2415 resources after being paused for the duration specified with the 2416 timeout parameter of the Session header in the SETUP message. 2418 Example: 2420 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 2421 CSeq: 834 2422 Session: 12345678 2424 S->C: RTSP/1.1 200 OK 2425 CSeq: 834 2426 Date: 23 Jan 1997 15:35:06 GMT 2427 Range: npt=45.76- 2429 The PAUSE request MAY contain a Range header specifying when the 2430 stream or presentation is to be halted. This point is referred to as 2431 the "pause point". The time parameter in the Range MUST NOT be used. 2432 The Range header MUST contain a single value, expressed as the 2433 beginning value an open range. For example, the following clip will 2434 be played from 10 seconds through 21 seconds of the clip's normal 2435 play time, under the assumption that the PAUSE request reaches the 2436 server within 11 seconds of the PLAY request. Note that some lines 2437 has been broken in an non-correct way to fit the page: 2439 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.1 2440 CSeq: 834 2441 Session: 12345678 2442 Range: npt=10-30 2444 S->C: RTSP/1.1 200 OK 2445 CSeq: 834 2446 Date: 23 Jan 1997 15:35:06 GMT 2447 Server: PhonyServer 1.0 2448 Range: npt=10-30 2449 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2450 ssrc=0D12F123:seq=5712;rtptime=934207921, 2451 url="rtsp://example.com/fizzle/videotrack" 2452 ssrc=4FAD8726:seq=57654;rtptime=2792482193 2453 Session: 12345678 2455 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 2456 CSeq: 835 2457 Session: 12345678 2458 Range: npt=21- 2460 S->C: RTSP/1.1 200 OK 2461 CSeq: 835 2462 Date: 23 Jan 1997 15:35:09 GMT 2463 Server: PhonyServer 1.0 2464 Range: npt=21- 2465 Session: 12345678 2467 The pause request becomes effective the first time the server is 2468 encountering the time point specified in any of the multiple ranges. 2469 If the Range header specifies a time outside any range from the PLAY 2470 request, the error 457 (Invalid Range) SHALL be returned. If a media 2471 unit (such as an audio or video frame) starts presentation at exactly 2472 the pause point, it is not played. If the Range header is missing, 2473 stream delivery is interrupted immediately on receipt of the message 2474 and the pause point is set to the current normal play time. However, 2475 the pause point in the media stream MUST be maintained. A subsequent 2476 PLAY request without Range header SHALL resume from the pause point 2477 and play until media end. 2479 If the server has already sent data beyond the time specified in the 2480 PAUSE request's Range header, a PLAY without range SHALL resume at 2481 the point in time specified by the PAUSE request's Range header, as 2482 it is assumed that the client has discarded data after that point. 2483 This ensures continuous pause/play cycling without gaps. 2485 The pause point after any PAUSE request SHALL be returned to the 2486 client by adding a Range header with what remains unplayed of the 2487 PLAY request's ranges, i.e. including all the remaining ranges part 2488 of multiple range specification. If one desires to resume playing a 2489 ranged request, one simply includes the Range header from the PAUSE 2490 response. 2492 For example, if the server have a play request for ranges 10 to 15 2493 and 20 to 29 pending and then receives a pause request for NPT 21, it 2494 would start playing the second range and stop at NPT 21. If the pause 2495 request is for NPT 12 and the server is playing at NPT 13 serving the 2496 first play request, the server stops immediately. If the pause 2497 request is for NPT 16, the server returns a 457 error message. To 2498 prevent that the second range is played and the server stops after 2499 completing the first range, a PAUSE request for NPT 20 needs to be 2500 issued. 2502 As another example, if a server has received requests to play ranges 2503 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 2504 request for NPT=14 would take effect while the server plays the first 2505 range, with the second range effectively being ignored, assuming the 2506 PAUSE request arrives before the server has started playing the 2507 second, overlapping range. Regardless of when the PAUSE request 2508 arrives, it sets the pause point to 14. The below example messages is 2509 for the above case when the PAUSE request arrives before the first 2510 occurrence of NPT=14. 2512 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.1 2513 CSeq: 834 2514 Session: 12345678 2515 Range: npt=10-15, npt=13-20 2517 S->C: RTSP/1.1 200 OK 2518 CSeq: 834 2519 Date: 23 Jan 1997 15:35:06 GMT 2520 Server: PhonyServer 1.0 2521 Range: npt=10-15, npt=13-20 2522 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2523 ssrc=0D12F123:seq=5712;rtptime=934207921, 2524 url="rtsp://example.com/fizzle/videotrack" 2525 ssrc=789DAF12:seq=57654;rtptime=2792482193 2526 Session: 12345678 2528 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 2529 CSeq: 835 2530 Session: 12345678 2531 Range: npt=14- 2533 S->C: RTSP/1.1 200 OK 2534 CSeq: 835 2535 Date: 23 Jan 1997 15:35:09 GMT 2536 Server: PhonyServer 1.0 2537 Range: npt=14-15, npt=13-20 2538 Session: 12345678 2540 If a client issues a PAUSE request and the server acknowledges and 2541 enters the READY state, the proper server response, if the player 2542 issues another PAUSE, is still 200 OK. The 200 OK response MUST 2543 include the Range header with the current pause point, even if the 2544 PAUSE request is asking for some other pause point. See examples 2545 below: 2547 Examples: 2549 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 2550 CSeq: 834 2551 Session: 12345678 2553 S->C: RTSP/1.1 200 OK 2554 CSeq: 834 2555 Session: 12345678 2556 Date: 23 Jan 1997 15:35:06 GMT 2557 Range: npt=45.76-98.36 2559 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.1 2560 CSeq: 835 2561 Session: 12345678 2562 Range: 86- 2564 S->C: RTSP/1.1 200 OK 2565 CSeq: 835 2566 Session: 12345678 2567 Date: 23 Jan 1997 15:35:07 GMT 2568 Range: npt=45.76-98.36 2570 11.6 TEARDOWN 2572 The TEARDOWN client to server request stops the stream delivery for 2573 the given URI, freeing the resources associated with it. A TEARDOWN 2574 request MAY be performed on either an aggregated or a media control 2575 URI. However some restrictions apply depending on the current state. 2576 The TEARDOWN request SHALL contain a Session header indicating what 2577 session the request applies to. 2579 A TEARDOWN using the aggregated control URI or the media URI in a 2580 session under non-aggregated control MAY be done in any state (Ready, 2581 and Play). A successful request SHALL result in that media delivery 2582 is immediately halted and the session state is destroyed. This SHALL 2583 be indicated through the lack of a Session header in the response. 2585 A TEARDOWN using a media URI in an aggregated session MAY only be 2586 done in Ready state. Such a request only removes the indicated media 2587 stream and associated resources from the session. This may result in 2588 that a session returns to non-aggregated control, due to that it only 2589 contains a single media after the requests completion. A session that 2590 will exist after the processing of the TEARDOWN request SHALL in the 2591 response to that TEARDOWN request contain a Session header. Thus the 2592 presence of the Session indicates to the receiver of the response if 2593 the session is still existing or has been removed. 2595 Example: 2597 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.1 2598 CSeq: 892 2599 Session: 12345678 2601 S->C: RTSP/1.1 200 OK 2602 CSeq: 892 2603 Server: PhonyServer 1.0 2605 11.7 GET_PARAMETER 2607 The GET_PARAMETER request retrieves the value of a parameter or 2608 parameters for a presentation or stream specified in the URI. If the 2609 Session header is present in a request, the value of a parameter MUST 2610 be retrieved in the specified session context. The content of the 2611 reply and response is left to the implementation. 2613 The method MAY also be used without a body (entity). If the this 2614 request is successful, i.e. a 200 OK response is received, then the 2615 keep-alive timer has been updated. Any non-required header present in 2616 such a request may or may not been processed. To allow a client to 2617 determine if any such header has been processed, it is necessary to 2618 use a feature tag and the Require header. Due to this reason it is 2619 RECOMMENDED that any parameters to be retrieved are sent in the body, 2620 rather than using any header. 2622 Example: 2624 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.1 2625 CSeq: 431 2626 Content-Type: text/parameters 2627 Session: 12345678 2628 Content-Length: 26 2630 packets_received 2631 jitter 2633 C->S: RTSP/1.1 200 OK 2634 CSeq: 431 2635 Content-Length: 38 2636 Content-Type: text/parameters 2638 packets_received: 10 2639 jitter: 0.3838 2641 The "text/parameters" section is only an example type for a 2642 body carrying parameters. 2644 11.8 SET_PARAMETER 2646 This method requests to set the value of a parameter or a set of 2647 parameters for a presentation or stream specified by the URI. The 2648 method MAY also be used without a body (entity). It is the 2649 RECOMMENDED method to use in request sent for the sole purpose of 2650 updating the keep-alive timer. If this request is successful, i.e. a 2651 200 OK response is received, then the keep-alive timer has been 2652 updated. Any non-required header present in such a request may or may 2653 not been processed. To allow a client to determine if any such header 2654 has been processed, it is necessary to use a feature tag and the 2655 Require header. Due to this reason it is RECOMMENDED that any 2656 parameters are sent in the body, rather than using any header. 2658 A request is RECOMMENDED to only contain a single parameter to allow 2659 the client to determine why a particular request failed. If the 2660 request contains several parameters, the server MUST only act on the 2661 request if all of the parameters can be set successfully. A server 2662 MUST allow a parameter to be set repeatedly to the same value, but it 2663 MAY disallow changing parameter values. If the receiver of the 2664 request does not understand or cannot locate a parameter, error 451 2665 (Parameter Not Understood) SHALL be used. In the case a parameter is 2666 not allowed to change, the error code is 458 (Parameter Is Read- 2667 Only). The response body SHOULD contain only the parameters that have 2668 errors. Otherwise no body SHALL be returned. 2670 Note: transport parameters for the media stream MUST only be set with 2671 the SETUP command. 2673 Restricting setting transport parameters to SETUP is for 2674 the benefit of firewalls. 2676 The parameters are split in a fine-grained fashion so that 2677 there can be more meaningful error indications. However, it 2678 may make sense to allow the setting of several parameters 2679 if an atomic setting is desirable. Imagine device control 2680 where the client does not want the camera to pan unless it 2681 can also tilt to the right angle at the same time. 2683 Example: 2685 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.1 2686 CSeq: 421 2687 Content-length: 20 2688 Content-type: text/parameters 2690 barparam: barstuff 2692 S->C: RTSP/1.1 451 Parameter Not Understood 2693 CSeq: 421 2694 Content-length: 10 2695 Content-type: text/parameters 2697 barparam 2699 The "text/parameters" section is only an example type for 2700 parameter. This method is intentionally loosely defined 2701 with the intention that the reply content and response 2702 content will be defined after further experimentation. 2704 11.9 REDIRECT 2706 The REDIRECT method is issued by a server to inform a client that it 2707 required to connect to another server location to access the resource 2708 indicated by the Request-URI. The presence of the Session header in a 2709 REDIRECT request indicates the scope of the request, and determines 2710 the specific semantics of the request. 2712 A REDIRECT request with a Session header has end-to-end (i.e. server 2713 to client) scope and applies only to the given session. Any 2714 intervening proxies SHOULD NOT disconnect the control channel while 2715 there are other remaining end-to-end sessions. The OPTIONAL Location 2716 header, if included in such a request, SHALL contain a complete 2717 absolute URI pointing to the resource to which the client SHOULD 2718 reconnect. Specifically, the Location SHALL NOT contain just the 2719 host and port. A client may receive a REDIRECT request with a Session 2720 header, if and only if, an end-to-end session has been established. 2722 A client may receive a REDIRECT request without a Session header at 2723 any time when it has communication or a connection established with a 2724 server. The scope of such a request is limited to the next-hop (i.e. 2725 the RTSP agent in direct communication with the server) and applies, 2726 as well, to the control connection between the next-hop RTSP agent 2727 and the server. A REDIRECT request without a Session header 2728 indicates that all sessions and pending requests being managed via 2729 the control connection MUST be redirected. The OPTIONAL Location 2730 header, if included in such a request, SHOULD contain an absolute URI 2731 with only the host address and the OPTIONAL port number of the server 2732 to which the RTSP agent SHOULD reconnect. Any intervening proxies 2733 SHOULD do all of the following in the order listed: 2735 1. respond to the REDIRECT request 2737 2. disconnect the control channel from the requesting server 2739 3. connect to the server at the given host address 2741 4. pass the REDIRECT request to each applicable client 2742 (typically those clients with an active session or an 2743 unanswered request) 2745 Note: The proxy is responsible for accepting REDIRECT responses from 2746 its clients; these responses MUST NOT be passed on to either the 2747 original server or the redirected server. 2749 The lack of a Location header in any REDIRECT request is indicative 2750 of the server no longer being able to fulfill the current request and 2751 having no alternatives for the client to continue with its normal 2752 operation. It is akin to a server initiated TEARDOWN that applies 2753 both to sessions as well as the general connection associated with 2754 that client. 2756 When the Range header is not included in a REDIRECT request, the 2757 client SHOULD perform the redirection immediately and return a 2758 response to the server. The server can consider the session as 2759 terminated and can free any associated state after it receives the 2760 successful (2xx) response. The server MAY close the signalling 2761 connection upon receiving the response and the client SHOULD close 2762 the signalling connection after sending the 2xx response. The 2763 exception to this is when the client has several sessions on the 2764 server being managed by the given signalling connection. In this 2765 case, the client SHOULD close the connection when it has received and 2766 responded to REDIRECT requests for all the sessions managed by the 2767 signalling connection. 2769 If the OPTIONAL Range header is included in a REDIRECT request, it 2770 indicates when the redirection takes effect. The range value MUST be 2771 an open ended single value, e.g. npt=59-, indicating the play out 2772 time when redirection SHALL occur. Alternatively, a range with a 2773 time= parameter indicates the wall clock time by when the redirection 2774 MUST take place. When the time= parameter is present in the range, 2775 any range value MUST be ignored even though it MUST be syntactically 2776 correct. When the indicated redirect point is reached, a client MUST 2777 issue a TEARDOWN request and SHOULD close the signalling connection 2778 after receiving a 2xx response. The normal connection considerations 2779 apply for the server. 2781 The differentiation of REDIRECT requests with and without 2782 range headers is to allow for clear and explicit state 2783 handling. As the state in the server needs to be kept until 2784 the point of redirection, the handling becomes more clear 2785 if the client is required to TEARDOWN the session at the 2786 redirect point. 2788 After a REDIRECT request has been processed, a client that wants to 2789 continue to send or receive media for the resource identified by the 2790 Request-URI will have to establish a new session with the designated 2791 host. If the URI given in the Location header is a valid resource 2792 URI, a client SHOULD issue a DESCRIBE request for the URI. 2794 Note: The media resource indicated by the Location header 2795 can be identical, slightly different or totally different. 2796 This is the reason why a new DESCRIBE request SHOULD be 2797 issued. 2799 If the Location header contains only a host address, the client MAY 2800 assume that the media on the new server is identical to the media on 2801 the old server, i.e. all media configuration information from the old 2802 session is still valid except for the host address. 2804 This example request redirects traffic for this session to the new 2805 server at the given absolute time: 2807 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.1 2808 CSeq: 732 2809 Location: rtsp://s2.example.com:8001 2810 Range: npt=0- ;time=19960213T143205Z 2811 Session: uZ3ci0K+Ld-M 2813 12 Embedded (Interleaved) Binary Data 2815 In order to fulfill certain requirements on the network side, e.g. 2816 in conjunction with network address translators that block RTP 2817 traffic over UDP, it may be necessary to interleave RTSP messages and 2818 media stream data. This interleaving should generally be avoided 2819 unless necessary since it complicates client and server operation and 2820 imposes additional overhead. Also head of line blocking may cause 2821 problems. Interleaved binary data SHOULD only be used if RTSP is 2822 carried over TCP. 2824 Stream data such as RTP packets is encapsulated by an ASCII dollar 2825 sign (24 decimal), followed by a one-byte channel identifier, 2826 followed by the length of the encapsulated binary data as a binary, 2827 two-byte integer in network byte order. The stream data follows 2828 immediately afterwards, without a CRLF, but including the upper-layer 2829 protocol headers. Each $ block SHALL contain exactly one upper-layer 2830 protocol data unit, e.g., one RTP packet. 2832 0 1 2 3 2833 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 | "$" = 24 | Channel ID | Length in bytes | 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 : Length number of bytes of binary data : 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 The channel identifier is defined in the Transport header with the 2841 interleaved parameter(Section 14.45). 2843 When the transport choice is RTP, RTCP messages are also interleaved 2844 by the server over the TCP connection. The usage of RTCP messages is 2845 indicated by including a range containing a second channel in the 2846 interleaved parameter of the Transport header, see section 14.45. If 2847 RTCP is used, packets SHALL be sent on the first available channel 2848 higher than the RTP channel. The channels are bi-directional and 2849 therefore RTCP traffic are sent on the second channel in both 2850 directions. 2852 RTCP is needed for synchronization when two or more streams 2853 are interleaved in such a fashion. Also, this provides a 2854 convenient way to tunnel RTP/RTCP packets through the TCP 2855 control connection when required by the network 2856 configuration and transfer them onto UDP when possible. 2858 C->S: SETUP rtsp://example.com/bar.file RTSP/1.1 2859 CSeq: 2 2860 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 2862 S->C: RTSP/1.1 200 OK 2863 CSeq: 2 2864 Date: 05 Jun 1997 18:57:18 GMT 2865 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 2866 Session: 12345678 2868 C->S: PLAY rtsp://example.com/bar.file RTSP/1.1 2869 CSeq: 3 2870 Session: 12345678 2872 S->C: RTSP/1.1 200 OK 2873 CSeq: 3 2874 Session: 12345678 2875 Date: 05 Jun 1997 18:59:15 GMT 2876 RTP-Info: url="rtsp://example.com/bar.file" 2877 ssrc=0D12F123:seq=232433;rtptime=972948234 2879 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2880 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2881 S->C: $006{2 byte length}{"length" bytes RTCP packet} 2883 13 Status Code Definitions 2885 Where applicable, HTTP status [H10] codes are reused. Status codes 2886 that have the same meaning are not repeated here. See Table 4 for a 2887 listing of which status codes may be returned by which requests. All 2888 error messages, 4xx and 5xx MAY return a body containing further 2889 information about the error. 2891 13.1 Success 1xx 2893 13.1.1 100 Continue 2895 See, [H10.1.1]. 2897 13.2 Success 2xx 2899 13.3 Redirection 3xx 2901 The notation "3rr" indicates response codes from 300 to 399 inclusive 2902 which are meant for redirection. The response code 304 is excluded 2903 from this set, as it is not used for redirection. 2905 See [H10.3] for definition of status code 300 to 305. However 2906 comments are given for some to how they apply to RTSP. 2908 Within RTSP, redirection may be used for load balancing or 2909 redirecting stream requests to a server topologically closer to the 2910 client. Mechanisms to determine topological proximity are beyond the 2911 scope of this specification. 2913 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 2914 that they are used if necessary before a session is established, i.e. 2915 in response to DESCRIBE or SETUP. However in cases where a server is 2916 not able to send a REDIRECT request to the client, the server MAY 2917 need to resort to using 3rr responses to inform a client with a 2918 established session about the need for redirecting the session. If an 2919 3rr response is received for an request in relation to a established 2920 session, the client SHOULD send a TEARDOWN request for the session, 2921 and MAY reestablish the session using the resource indicated by the 2922 Location. 2924 If the the Location header is used in a response it SHALL contain an 2925 absolute URI pointing out the media resource the client is redirected 2926 to, the URI SHALL NOT only contain the host name. 2928 13.3.1 300 Multiple Choices 2930 See [H10.3.1] [TBW] 2932 13.3.2 301 Moved Permanently 2934 The request resource are moved permanently and resides now at the URI 2935 given by the location header. The user client SHOULD redirect 2936 automatically to the given URI. This response MUST NOT contain a 2937 message-body. The Location header MUST be included in the response. 2939 13.3.3 302 Found 2941 The requested resource reside temporarily at the URI given by the 2942 Location header. The Location header MUST be included in the 2943 response. Is intended to be used for many types of temporary 2944 redirects, e.g. load balancing. It is RECOMMENDED that one set the 2945 reason phrase to something more meaningful than "Found" in these 2946 cases. The user client SHOULD redirect automatically to the given 2947 URI. This response MUST NOT contain a message-body. 2949 13.3.4 303 See Other 2951 This status code SHALL NOT be used in RTSP. However as it was allowed 2952 to use in RTSP 1.1 (RFC 2326). 2954 13.3.5 304 Not Modified 2956 If the client has performed a conditional DESCRIBE or SETUP (see 2957 14.26) and the requested resource has not been modified, the server 2958 SHOULD send a 304 response. This response MUST NOT contain a 2959 message-body. 2961 The response MUST include the following header fields: 2963 o Date 2965 o ETag and/or Content-Location, if the header would have been 2966 sent in a 200 response to the same request. 2968 o Expires, Cache-Control, and/or Vary, if the field-value might 2969 differ from that sent in any previous response for the same 2970 variant. 2972 This response is independent for the DESCRIBE and SETUP requests. 2973 That is, a 304 response to DESCRIBE does NOT imply that the resource 2974 content is unchanged (only the session description) and a 304 2975 response to SETUP does NOT imply that the resource description is 2976 unchanged. The ETag and If-Match headers may be used to link the 2977 DESCRIBE and SETUP in this manner. 2979 13.3.6 305 Use Proxy 2981 See [H10.3.6]. 2983 13.4 Client Error 4xx 2985 13.4.1 400 Bad Request 2987 The request could not be understood by the server due to malformed 2988 syntax. The client SHOULD NOT repeat the request without 2989 modifications [H10.4.1]. If the request does not have a CSeq header, 2990 the server MUST NOT include a CSeq in the response. 2992 13.4.2 405 Method Not Allowed 2994 The method specified in the request is not allowed for the resource 2995 identified by the Request-URI. The response MUST include an Allow 2996 header containing a list of valid methods for the requested resource. 2997 This status code is also to be used if a request attempts to use a 2998 method not indicated during SETUP, e.g., if a RECORD request is 2999 issued even though the mode parameter in the Transport header only 3000 specified PLAY. 3002 13.4.3 451 Parameter Not Understood 3004 The recipient of the request does not support one or more parameters 3005 contained in the request. When returning this error message the 3006 sender SHOULD return a entity body containing the offending 3007 parameter(s). 3009 13.4.4 452 reserved 3011 This error code was removed from RFC 2326 [24] and is obsolete. 3013 13.4.5 453 Not Enough Bandwidth 3015 The request was refused because there was insufficient bandwidth. 3016 This may, for example, be the result of a resource reservation 3017 failure. 3019 13.4.6 454 Session Not Found 3021 The RTSP session identifier in the Session header is missing, 3022 invalid, or has timed out. 3024 13.4.7 455 Method Not Valid in This State 3026 The client or server cannot process this request in its current 3027 state. The response SHOULD contain an Allow header to make error 3028 recovery easier. 3030 13.4.8 456 Header Field Not Valid for Resource 3032 The server could not act on a required request header. For example, 3033 if PLAY contains the Range header field but the stream does not allow 3034 seeking. This error message may also be used for specifying when the 3035 time format in Range is impossible for the resource. In that case the 3036 Accept-Ranges header SHOULD be returned to inform the client of which 3037 format(s) that are allowed. 3039 13.4.9 457 Invalid Range 3041 The Range value given is out of bounds, e.g., beyond the end of the 3042 presentation. 3044 13.4.10 458 Parameter Is Read-Only 3046 The parameter to be set by SET_PARAMETER can be read but not 3047 modified. When returning this error message the sender SHOULD return 3048 a entity body containing the offending parameter(s). 3050 13.4.11 459 Aggregate Operation Not Allowed 3052 The requested method may not be applied on the URI in question since 3053 it is an aggregate (presentation) URI. The method may be applied on a 3054 media URI. 3056 13.4.12 460 Only Aggregate Operation Allowed 3058 The requested method may not be applied on the URI in question since 3059 it is not an aggregate control (presentation) URI. The method may be 3060 applied on the aggregate control URI. 3062 13.4.13 461 Unsupported Transport 3064 The Transport field did not contain a supported transport 3065 specification. 3067 13.4.14 462 Destination Unreachable 3069 The data transmission channel could not be established because the 3070 client address could not be reached. This error will most likely be 3071 the result of a client attempt to place an invalid dest_addr 3072 parameter in the Transport field. 3074 13.4.15 463 Destination Prohibited 3076 The data transmission channel was not established because the server 3077 prohibited access to the client address. This error is most likely 3078 the result of a client attempt to redirect media traffic to another 3079 destination with a dest_addr parameter in the Transport header. 3081 13.4.16 470 Connection Authorization Required 3083 The secured connection attempt need user or client authorization 3084 before proceeding. The next hops certificate is included in this 3085 response in the Accept-Credentials header. 3087 13.4.17 471 Connection Credentials not accepted 3089 When performing a secure connection over multiple connections, a 3090 intermediary has refused to connect to the next hop and carry out the 3091 request due to unacceptable credentials for the used policy. 3093 13.5 Server Error 5xx 3095 13.5.1 551 Option not supported 3097 A feature-tag given in the Require or the Proxy-Require fields was 3098 not supported. The Unsupported header SHOULD be returned stating the 3099 feature for which there is no support. 3101 14 Header Field Definitions 3103 method direction object acronym Body 3104 _________________________________________________ 3105 DESCRIBE C -> S P,S DES r 3106 GET_PARAMETER C -> S, S -> C P,S GPR R,r 3107 OPTIONS C -> S P,S OPT 3108 S -> C 3109 PAUSE C -> S P,S PSE 3110 PLAY C -> S P,S PLY 3111 REDIRECT S -> C P,S RDR 3112 SETUP C -> S S STP 3113 SET_PARAMETER C -> S, S -> C P,S SPR R,r 3114 TEARDOWN C -> S P,S TRD 3116 Table 8: Overview of RTSP methods, their direction, and what objects 3117 (P: presentation, S: stream) they operate on. Body notes if a method 3118 is allowed to carry body and in which direction, R = Request, 3119 r=response. Note: It is allowed for all error messages 4xx and 5xx to 3120 have a body 3122 The general syntax for header fields is covered in Section 4.2 This 3123 section lists the full set of header fields along with notes on 3124 meaning, and usage. The syntax definition for header fields are 3125 present in section 19.2.3. Throughout this section, we use [HX.Y] to 3126 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 3127 [3]. Examples of each header field are given. 3129 Information about header fields in relation to methods and proxy 3130 processing is summarized in Tables 9, 10, 11, and 12. 3132 The "where" column describes the request and response types in which 3133 the header field can be used. Values in this column are: 3135 R: header field may only appear in requests; 3137 r: header field may only appear in responses; 3139 2xx, 4xx, etc.: A numerical value or range indicates response 3140 codes with which the header field can be used; 3142 c: header field is copied from the request to the response. 3144 An empty entry in the "where" column indicates that the header field 3145 may be present in all requests and responses. 3147 The "proxy" column describes the operations a proxy may perform on a 3148 header field. An empty proxy column indicates that the proxy SHALL 3149 NOT do any changes to that header, all allowed operations are 3150 explicitly stated: 3152 a: A proxy can add or concatenate the header field if not 3153 present. 3155 m: A proxy can modify an existing header field value. 3157 d: A proxy can delete a header field value. 3159 r: A proxy needs to be able to read the header field, and thus 3160 this header field cannot be encrypted. 3162 The rest of the columns relate to the presence of a header field in a 3163 method. The method names when abbreviated, are according to table 8: 3165 c: Conditional; requirements on the header field depend on the 3166 context of the message. 3168 m: The header field is mandatory. 3170 m*: The header field SHOULD be sent, but clients/servers need to 3171 be prepared to receive messages without that header field. 3173 o: The header field is optional. 3175 *: The header field is SHALL be present if the message body is 3176 not empty. See sections 14.16, 14.18 and 4.3 for details. 3178 -: The header field is not applicable. 3180 "Optional" means that a Client/Server MAY include the header field in 3181 a request or response. The Client/Server behavior when receiving such 3182 headers varies, for some it may ignore the header field, in other 3183 case it is request to process the header. This is regulated by the 3184 method and header descriptions. Example of such headers that require 3185 processing are the Require and Proxy-Require header fields discussed 3186 in 14.37 and 14.31. A "mandatory" header field MUST be present in a 3187 request, and MUST be understood by the Client/Server receiving the 3188 request. A mandatory response header field MUST be present in the 3189 response, and the header field MUST be understood by the 3190 Client/Server processing the response. "Not applicable" means that 3191 the header field MUST NOT be present in a request. If one is placed 3192 in a request by mistake, it MUST be ignored by the Client/Server 3193 receiving the request. Similarly, a header field labeled "not 3194 applicable" for a response means that the Client/Server MUST NOT 3195 place the header field in the response, and the Client/Server MUST 3196 ignore the header field in the response. 3198 A Client/Server SHOULD ignore extension header parameters that are 3199 not understood. 3201 The From and Location header fields contain an URI. If the URI 3202 contains a comma, or semicolon, the URI MUST be enclosed in double 3203 quotas ("). Any URI parameters are contained within these quotas. If 3204 the URI is not enclosed in double quotas, any semicolon- delimited 3205 parameters are header-parameters, not URI parameters. 3207 14.1 Accept 3209 The Accept request-header field can be used to specify certain 3210 presentation description content types which are acceptable for the 3211 response. 3213 The "level" parameter for presentation descriptions is 3214 properly defined as part of the MIME type registration, not 3215 here. 3217 See [H14.1] for syntax. 3219 Example of use: 3221 Accept: application/rtsl q=1.0, application/sdp 3223 14.2 Accept-Credentials 3225 The Accept-Credentials header is a request header used to indicate to 3226 any trusted intermediary how to handle further secured connections to 3227 proxies or servers. See section 18 for the usage of this header. It 3228 SHALL only be included in client to server requests. 3230 In a request the header SHALL contain the method (User, Proxy, or 3231 Any) for approving credentials selected by the requestor. The method 3232 SHALL NOT be changed by any proxy. If the method is "User" the header 3233 contains zero or more of credentials that the client accept. Each 3234 credential SHALL consist of one URI identifying the proxy or server, 3235 and the SHA-1 [14] hash computed over that entity's DER encoded 3236 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3237 _________________________________________________________________ 3238 Accept R o - - - - - 3239 Accept-Credentials R r o o o o o o 3240 Accept-Encoding R r o - - - - - 3241 Accept-Language R r o - - - - - 3242 Accept-Ranges r r - - o - - - 3243 Accept-Ranges 456 r - - - o o - 3244 Allow r am - c - - - - 3245 Allow 405 am m m m m m m 3246 Authorization R o o o o o o 3247 Bandwidth R o o o o - - 3248 Blocksize R o - o o - - 3249 Cache-Control r - - o - - - 3250 Connection o o o o o o 3251 Connection-Credentials 470,407 ar o o o o o o 3252 Content-Base r o - - - - - 3253 Content-Base 4xx o o o o o o 3254 Content-Encoding R r - - - - - - 3255 Content-Encoding r r o - - - - - 3256 Content-Encoding 4xx r o o o o o o 3257 Content-Language R r - - - - - - 3258 Content-Language r r o - - - - - 3259 Content-Language 4xx r o o o o o o 3260 Content-Length r r * - - - - - 3261 Content-Length 4xx r * * * * * * 3262 Content-Location r o - - - - - 3263 Content-Location 4xx o o o o o o 3264 Content-Type r * - - - - - 3265 Content-Type 4xx * * * * * * 3266 CSeq Rc rm m m m m m m 3267 Date am o o o o o o 3268 ETag r r o - o - - - 3269 Expires r r o - - - - - 3270 From R r o o o o o o 3271 Host - - - - - - 3272 If-Match R r - - o - - - 3273 If-Modified-Since R r o - o - - - 3274 If-None-Match R r o - - - - - 3275 Last-Modified r r o - - - - - 3276 Location 3rr o o o o o o 3278 Table 9: Overview of RTSP header fields (A-L) related to methods 3279 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3281 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3282 _____________________________________________________________ 3283 Proxy-Authenticate 407 amr m m m m m m 3284 Proxy-Require R ar o o o o o o 3285 Proxy-Require r r c c c c c c 3286 Proxy-Supported R amr oc oc oc oc oc oc 3287 Proxy-Supported r c c c c c c 3288 Public r admr - m* - - - - 3289 Public 501 admr m* m* m* m* m* m* 3290 Range R - - - o o - 3291 Range r - - c m* m* - 3292 Referer R o o o o o o 3293 Require R o o o o o o 3294 Retry-After 3rr,503 o o o - - - 3295 RTP-Info r - - o c - - 3296 Scale - - - o - - 3297 Session R r - o o m m m 3298 Session r r - c m m m o 3299 Server R r - o - - - - 3300 Server r r o o o o o o 3301 Speed - - - o - - 3302 Supported R amr o o o o o o 3303 Supported r amr c c c c c c 3304 Timestamp R admr o o o o o o 3305 Timestamp c admr m m m m m m 3306 Transport amr - - m - - - 3307 Unsupported r c c c c c c 3308 User-Agent R m* m* m* m* m* m* 3309 Vary r c c c c c c 3310 Via R amr o o o o o o 3311 Via c dr m m m m m m 3312 WWW-Authenticate 401 m m m m m m 3314 _____________________________________________________________ 3315 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3317 Table 10: Overview of RTSP header fields (P-W) related to methods 3318 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3320 certificate [15] in Base64 [35]. 3322 Example: 3323 Accept-Credentials:User, 3324 "rtsps://proxy2.example.com/";exaIl9VMbQMOFGClx5rXnPJKVNI=, 3326 Header Where Proxy GPR SPR RDR 3327 __________________________________________________ 3328 Accept-Credentials R r o o o 3329 Allow 405 amr m m m 3330 Authorization R o o o 3331 Bandwidth R - o - 3332 Blocksize R - o - 3333 Connection o o o 3334 Connection-Credentials 470,407 ar o o o 3335 Content-Base R o o - 3336 Content-Base r o o - 3337 Content-Base 4xx o o o 3338 Content-Encoding R r o o - 3339 Content-Encoding r r o o - 3340 Content-Encoding 4xx r o o o 3341 Content-Language R r o o - 3342 Content-Language r r o o - 3343 Content-Language 4xx r o o o 3344 Content-Length R r * * - 3345 Content-Length r r * * - 3346 Content-Length 4xx r * * * 3347 Content-Location R o o - 3348 Content-Location r o o - 3349 Content-Location 4xx o o o 3350 Content-Type R * * - 3351 Content-Type r * * - 3352 Content-Type 4xx * * * 3353 CSeq Rc mr m m m 3354 Date am o o o 3355 From R r o o o 3356 Host - - - 3357 Last-Modified R r - - - 3358 Last-Modified r r o - - 3359 Location 3rr o o o 3360 Location R - - m 3361 Proxy-Authenticate 407 amr m m m 3362 Proxy-Require R ar o o o 3363 Proxy-Require r r c c c 3364 Proxy-Supported R amr oc oc oc 3365 Proxy-Supported r c c c 3366 Public 501 admr m* m* m* 3368 __________________________________________________ 3369 Header Where Proxy GPR SPR RDR 3371 Table 11: Overview of RTSP header fields (A-P) related to methods 3372 GET_PARAMETER, SET_PARAMETER, and REDIRECT. 3374 Header Where Proxy GPR SPR RDR 3375 ____________________________________________ 3376 Range R - - o 3377 Referer R o o o 3378 Require R r o o o 3379 Retry-After 3rr,503 o o - 3380 Scale - - - 3381 Session R r o o o 3382 Session r r c c o 3383 Server R r o o o 3384 Server r r o o - 3385 Supported R adrm o o o 3386 Supported r adrm c c c 3387 Timestamp R adrm o o o 3388 Timestamp c adrm m m m 3389 Unsupported r arm c c c 3390 User-Agent R r m* m* - 3391 User-Agent r r - - m* 3392 Vary r c c - 3393 Via R amr o o o 3394 Via c dr m m m 3395 WWW-Authenticate 401 m m m 3397 ____________________________________________ 3398 Header Where Proxy GPR SPR RDR 3400 Table 12: Overview of RTSP header fields (R-W) related to methods 3401 GET_PARAMETER, SET_PARAMETER, and REDIRECT. 3403 14.3 Accept-Encoding 3405 See [H14.3] 3407 14.4 Accept-Language 3409 See [H14.4]. Note that the language specified applies to the 3410 presentation description and any reason phrases, not the media 3411 content. 3413 14.5 Accept-Ranges 3415 The Accept-Ranges response-header field allows the server to indicate 3416 its acceptance of range requests and possible formats for a resource: 3418 Accept-Ranges: NPT, SMPTE 3419 This header has the same syntax as [H14.5] and the syntax is defined 3420 in 19.2.3. However, new range-units are defined. Inclusion of any of 3421 the time formats indicates acceptance by the server for PLAY and 3422 PAUSE requests with this format. The headers value is valid for the 3423 resource specified by the URI in the request, this response 3424 corresponds to. A server SHOULD use this header in SETUP responses to 3425 indicate to the client which range time formats the media supports. 3426 The header SHOULD also be included in "456" responses which is a 3427 result of use of unsupported range formats. 3429 14.6 Allow 3431 The Allow entity-header field lists the methods supported by the 3432 resource identified by the Request-URI. The purpose of this field is 3433 to strictly inform the recipient of valid methods associated with the 3434 resource. An Allow header field MUST be present in a 405 (Method Not 3435 Allowed) response. See [H14.7] for syntax definition. The Allow 3436 header MUST also be present in all OPTIONS responses where the 3437 content of the header will not include exactly the same methods as 3438 listed in the Public header. 3440 Example of use: 3442 Allow: SETUP, PLAY, SET_PARAMETER 3444 14.7 Authorization 3446 See [H14.8] 3448 14.8 Bandwidth 3450 The Bandwidth request-header field describes the estimated bandwidth 3451 available to the client, expressed as a positive integer and measured 3452 in bits per second. The bandwidth available to the client may change 3453 during an RTSP session, e.g., due to mobility. 3455 Example: 3457 Bandwidth: 4000 3459 14.9 Blocksize 3461 The Blocksize request-header field is sent from the client to the 3462 media server asking the server for a particular media packet size. 3464 This packet size does not include lower-layer headers such as IP, 3465 UDP, or RTP. The server is free to use a blocksize which is lower 3466 than the one requested. The server MAY truncate this packet size to 3467 the closest multiple of the minimum, media-specific block size, or 3468 override it with the media-specific size if necessary. The block size 3469 MUST be a positive decimal number, measured in octets. The server 3470 only returns an error (4xx) if the value is syntactically invalid. 3472 14.10 Cache-Control 3474 The Cache-Control general-header field is used to specify directives 3475 that MUST be obeyed by all caching mechanisms along the 3476 request/response chain. 3478 Cache directives MUST be passed through by a proxy or gateway 3479 application, regardless of their significance to that application, 3480 since the directives may be applicable to all recipients along the 3481 request/response chain. It is not possible to specify a cache- 3482 directive for a specific cache. 3484 Cache-Control should only be specified in a SETUP request and its 3485 response. Note: Cache-Control does not govern the caching of 3486 responses as for HTTP, instead it applies to the media stream 3487 identified by the SETUP request. The caching of RTSP requests are 3488 generally not cacheable, for further information see section 16. 3489 Below is the description of the cache directives that can be included 3490 in the Cache-Control header. 3492 no-cache: Indicates that the media stream MUST NOT be cached 3493 anywhere. This allows an origin server to prevent caching 3494 even by caches that have been configured to return stale 3495 responses to client requests. 3497 public: Indicates that the media stream is cacheable by any 3498 cache. 3500 private: Indicates that the media stream is intended for a 3501 single user and MUST NOT be cached by a shared cache. A 3502 private (non-shared) cache may cache the media stream. 3504 no-transform: An intermediate cache (proxy) may find it useful 3505 to convert the media type of a certain stream. A proxy 3506 might, for example, convert between video formats to save 3507 cache space or to reduce the amount of traffic on a slow 3508 link. Serious operational problems may occur, however, 3509 when these transformations have been applied to streams 3510 intended for certain kinds of applications. For example, 3511 applications for medical imaging, scientific data analysis 3512 and those using end-to-end authentication all depend on 3513 receiving a stream that is bit-for-bit identical to the 3514 original media stream. Therefore, if a response includes 3515 the no-transform directive, an intermediate cache or proxy 3516 MUST NOT change the encoding of the stream. Unlike HTTP, 3517 RTSP does not provide for partial transformation at this 3518 point, e.g., allowing translation into a different 3519 language. 3521 only-if-cached: In some cases, such as times of extremely poor 3522 network connectivity, a client may want a cache to return 3523 only those media streams that it currently has stored, and 3524 not to receive these from the origin server. To do this, 3525 the client may include the only-if-cached directive in a 3526 request. If it receives this directive, a cache SHOULD 3527 either respond using a cached media stream that is 3528 consistent with the other constraints of the request, or 3529 respond with a 504 (Gateway Timeout) status. However, if a 3530 group of caches is being operated as a unified system with 3531 good internal connectivity, such a request MAY be forwarded 3532 within that group of caches. 3534 max-stale: Indicates that the client is willing to accept a 3535 media stream that has exceeded its expiration time. If 3536 max-stale is assigned a value, then the client is willing 3537 to accept a response that has exceeded its expiration time 3538 by no more than the specified number of seconds. If no 3539 value is assigned to max-stale, then the client is willing 3540 to accept a stale response of any age. 3542 min-fresh: Indicates that the client is willing to accept a 3543 media stream whose freshness lifetime is no less than its 3544 current age plus the specified time in seconds. That is, 3545 the client wants a response that will still be fresh for at 3546 least the specified number of seconds. 3548 must-revalidate: When the must-revalidate directive is present 3549 in a SETUP response received by a cache, that cache MUST 3550 NOT use the entry after it becomes stale to respond to a 3551 subsequent request without first revalidating it with the 3552 origin server. That is, the cache is required to do an 3553 end-to-end revalidation every time, if, based solely on the 3554 origin server's Expires, the cached response is stale.) 3556 proxy-revalidate: The proxy-revalidate directive has the same 3557 meaning as the must-revalidate directive, except that it 3558 does not apply to non-shared user agent caches. It can be 3559 used on a response to an authenticated request to permit 3560 the user's cache to store and later return the response 3561 without needing to revalidate it (since it has already been 3562 authenticated once by that user), while still requiring 3563 proxies that service many users to revalidate each time (in 3564 order to make sure that each user has been authenticated). 3565 Note that such authenticated responses also need the public 3566 cache control directive in order to allow them to be cached 3567 at all. 3569 max-age: When an intermediate cache is forced, by means of a 3570 max-age=0 directive, to revalidate its own cache entry, and 3571 the client has supplied its own validator in the request, 3572 the supplied validator might differ from the validator 3573 currently stored with the cache entry. In this case, the 3574 cache MAY use either validator in making its own request 3575 without affecting semantic transparency. 3577 However, the choice of validator might affect performance. 3578 The best approach is for the intermediate cache to use its 3579 own validator when making its request. If the server 3580 replies with 304 (Not Modified), then the cache can return 3581 its now validated copy to the client with a 200 (OK) 3582 response. If the server replies with a new entity and cache 3583 validator, however, the intermediate cache can compare the 3584 returned validator with the one provided in the client's 3585 request, using the strong comparison function. If the 3586 client's validator is equal to the origin server's, then 3587 the intermediate cache simply returns 304 (Not Modified). 3588 Otherwise, it returns the new entity with a 200 (OK) 3589 response. 3591 14.11 Connection 3593 See [H14.10]. The use of the connection option "close" in RTSP 3594 messages SHOULD be limited to error messages when the server is 3595 unable to recover and therefore see it necessary to close the 3596 connection. The reason is that the client has the choice of 3597 continuing using a connection indefinitely, as long as it sends valid 3598 messages. 3600 14.12 Connection-Credentials 3602 The Connection-Credentials response header is used to carry the 3603 credentials of any next hop that need to be approved by the 3604 requestor. It SHALL only be used in server to client responses. 3606 The Connection-Credentials header in an RTSP response SHALL, if 3607 included, contain the credentials information of the next hop that an 3608 intermediary needs to securely connect to. The credential MUST 3609 include the URI of the next proxy or server and the DER encoded 3610 X.509v3 [15] certificate in base64 [35]. 3612 Example: 3614 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 3616 14.13 Content-Base 3618 The Content-Base entity-header field may be used to specify the base 3619 URI for resolving relative URIs within the entity. 3621 Content-Base: rtsp://media.example.com/movie/twister 3623 If no Content-Base field is present, the base URI of an entity is 3624 defined either by its Content-Location (if that Content-Location URI 3625 is an absolute URI) or the URI used to initiate the request, in that 3626 order of precedence. Note, however, that the base URI of the contents 3627 within the entity-body may be redefined within that entity-body. 3629 14.14 Content-Encoding 3631 See [H14.11] 3633 14.15 Content-Language 3635 See [H14.12] 3637 14.16 Content-Length 3639 The Content-Length general-header field contains the length of the 3640 body (entity) of the message (i.e. after the double CRLF following 3641 the last header). Unlike HTTP, it MUST be included in all messages 3642 that carry body beyond the header portion of the message. If it is 3643 missing, a default value of zero is assumed. It is interpreted 3644 according to [H14.13]. 3646 14.17 Content-Location 3648 See [H14.14] 3650 14.18 Content-Type 3651 See [H14.17]. Note that the content types suitable for RTSP are 3652 likely to be restricted in practice to presentation descriptions and 3653 parameter-value types. 3655 14.19 CSeq 3657 The CSeq general-header field specifies the sequence number for an 3658 RTSP request-response pair. This field MUST be present in all 3659 requests and responses. For every RTSP request containing the given 3660 sequence number, the corresponding response will have the same 3661 number. Any retransmitted request MUST contain the same sequence 3662 number as the original (i.e. the sequence number is not incremented 3663 for retransmissions of the same request). For each new RTSP request 3664 the CSeq value SHALL be incremented by one. The initial sequence 3665 number MAY be any number, however it is RECOMMENDED to start at 0. 3666 Each sequence number series is unique between each requester and 3667 responder, i.e. the client has one series for its request to a 3668 server and the server has another when sending request to the client. 3669 Each requester and responder is identified with its network address. 3671 Example: 3673 CSeq: 239 3675 14.20 Date 3677 See [H14.18]. An RTSP message containing a body MUST include a Date 3678 header if the sending host has a clock. Servers SHOULD include a Date 3679 header in all other RTSP messages. 3681 14.21 ETag 3683 The ETag response header MAY be included in DESCRIBE or SETUP 3684 responses. The entity tag returned in a DESCRIBE response is for the 3685 included entity, while for SETUP it refers to the media resource just 3686 set up. This differentiation allows for cache validation of both 3687 session description and the media resource associated with the 3688 description. If the ETag is provided both inside the entity, e.g. 3689 within the "a=etag" attribute in SDP, and in the response message, 3690 then both tags SHALL be identical. It is RECOMMENDED that the ETag is 3691 primarily given in the RTSP response message, to ensure that caches 3692 can use the ETag without requiring content inspection. 3694 SETUP and DESCRIBE requests can be made conditional upon the ETag 3695 using the headers If-Match (Section 14.25) and If-None-Match (Section 3696 14.27). 3698 14.22 Expires 3700 The Expires entity-header field gives a date and time after which the 3701 description or media-stream should be considered stale. The 3702 interpretation depends on the method: 3704 DESCRIBE response: The Expires header indicates a date and time 3705 after which the presentation description (body) SHOULD be 3706 considered stale. 3708 SETUP response: The Expires header indicate a date and time 3709 after which the media stream SHOULD be considered stale. 3711 A stale cache entry may not normally be returned by a cache (either a 3712 proxy cache or an user agent cache) unless it is first validated with 3713 the origin server (or with an intermediate cache that has a fresh 3714 copy of the entity). See section 16 for further discussion of the 3715 expiration model. 3717 The presence of an Expires field does not imply that the original 3718 resource will change or cease to exist at, before, or after that 3719 time. 3721 The format is an absolute date and time as defined by HTTP-date in 3722 [H3.3]; it MUST be in RFC1123-date format: 3724 An example of its use is 3726 Expires: Thu, 01 Dec 1994 16:00:00 GMT 3728 RTSP/1.1 clients and caches MUST treat other invalid date formats, 3729 especially including the value "0", as having occurred in the past 3730 (i.e., already expired). 3732 To mark a response as "already expired," an origin server should use 3733 an Expires date that is equal to the Date header value. To mark a 3734 response as "never expires," an origin server SHOULD use an Expires 3735 date approximately one year from the time the response is sent. 3736 RTSP/1.1 servers SHOULD NOT send Expires dates more than one year in 3737 the future. 3739 The presence of an Expires header field with a date value of some 3740 time in the future on a media stream that otherwise would by default 3741 be non-cacheable indicates that the media stream is cacheable, unless 3742 indicated otherwise by a Cache-Control header field (Section 14.10). 3744 14.23 From 3746 See [H14.22]. 3748 14.24 Host 3750 The Host HTTP request header field [H14.23] is not needed for RTSP, 3751 and SHALL NOT be sent. It SHALL be silently ignored if received. 3753 14.25 If-Match 3755 See [H14.24]. 3757 The If-Match request-header field is especially useful for ensuring 3758 the integrity of the presentation description, in both the case where 3759 it is fetched via means external to RTSP (such as HTTP), or in the 3760 case where the server implementation is guaranteeing the integrity of 3761 the description between the time of the DESCRIBE message and the 3762 SETUP message. By including the ETag given in or with the session 3763 description in a SETUP request, the client ensures that resources set 3764 up are matching the description. A SETUP request for which the ETag 3765 validation check fails, SHALL responde using 412 (Precondition 3766 Failed). 3768 This validation check is also very useful if a session has been 3769 redirected from one server to another. 3771 14.26 If-Modified-Since 3773 The If-Modified-Since request-header field is used with the DESCRIBE 3774 and SETUP methods to make them conditional. If the requested variant 3775 has not been modified since the time specified in this field, a 3776 description will not be returned from the server (DESCRIBE) or a 3777 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 3778 response SHALL be returned without any message-body. 3780 An example of the field is: 3782 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 3784 14.27 If-None-Match 3786 See [H14.26]. 3788 This request header can be used with entity tags to make DESCRIBE 3789 requests conditional. A new session description is retrieved only if 3790 another entity than the already available would be included. If the 3791 entity available for delivery is matching the one the client already 3792 has, then a 304 (Not Modified) response is given. 3794 14.28 Last-Modified 3796 The Last-Modified entity-header field indicates the date and time at 3797 which the origin server believes the presentation description or 3798 media stream was last modified. See [H14.29]. For the methods 3799 DESCRIBE, the header field indicates the last modification date and 3800 time of the description, for SETUP that of the media stream. 3802 14.29 Location 3804 See [H14.30]. 3806 14.30 Proxy-Authenticate 3808 See [H14.33]. 3810 14.31 Proxy-Require 3812 The Proxy-Require request-header field is used to indicate proxy- 3813 sensitive features that MUST be supported by the proxy. Any Proxy- 3814 Require header features that are not supported by the proxy MUST be 3815 negatively acknowledged by the proxy to the client using the 3816 Unsupported header. The proxy SHALL use the 551 (Option Not 3817 Supported) status code in the response. Any feature tag included in 3818 the Proxy-Require does not apply to the end-point (server or client). 3819 To ensure that a feature is supported by both proxies and servers the 3820 tag needs to be included in also a Require header. 3822 See Section 14.37 for more details on the mechanics of this message 3823 and a usage example. 3825 Example of use: 3827 Proxy-Require: play.basic 3829 14.32 Proxy-Supported 3831 The Proxy-Supported header field enumerates all the extensions 3832 supported by the proxy using feature tags. The header carries the 3833 intersection of extensions supported by the forwarding proxies. The 3834 Proxy-Supported header MAY be included in any request by a proxy. It 3835 SHALL be added by any proxy if the Supported header is present in a 3836 request. When present in a request, the receiver MUST in the response 3837 copy the received Proxy-Supported header. 3839 The Proxy-Supported header field contains a list of feature-tags 3840 applicable to proxies, as described in Section 3.7. The list are the 3841 intersection of all feature-tags understood by the proxies. To 3842 achieve an intersection, the proxy adding the Proxy-Supported header 3843 includes all proxy feature-tags it understands. Any proxy receiving a 3844 request with the header, checks the list and removes any feature tag 3845 it do not support. A Proxy-Supported header present in the response 3846 SHALL NOT be touched by the proxies. 3848 Example: 3850 C->P1: OPTIONS rtsp://example.com/ RTSP/1.1 3851 Supported: foo, bar, blech 3853 P1->P2: OPTIONS rtsp://example.com/ RTSP/1.1 3854 Supported: foo, bar, blech 3855 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 3856 Via: 1.1 prox1.example.com 3858 P2->S: OPTIONS rtsp://example.com/ RTSP/1.1 3859 Supported: foo, bar, blech 3860 Proxy-Supported: proxy-foo, proxy-blech 3861 Via: 1.1 prox1.example.com, 1.1 prox2.example.com 3863 S->C: RTSP/1.1 200 OK 3864 Supported: foo, bar, baz 3865 Proxy-Supported: proxy-foo, proxy-blech 3866 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3867 Via: 1.1 prox1.example.com, 1.1 prox2.example.com 3869 14.33 Public 3871 The Public response header field lists the set of methods supported 3872 by the response sender. This header applies to the general 3873 capabilities of the sender and its only purpose is to indicate the 3874 sender's capabilities to the recipient. The methods listed may or may 3875 not be applicable to the Request-URI; the Allow header field (section 3876 14.7) MAY be used to indicate methods allowed for a particular URI. 3878 Example of use: 3880 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3882 In the event that there are proxies between the sender and the 3883 recipient of a response, each intervening proxy MUST modify the 3884 Public header field to remove any methods that are not supported via 3885 that proxy. The resulting Public header field will contain an 3886 intersection of the sender's methods and the methods allowed through 3887 by the intervening proxies. 3889 In general proxies should allow all methods to 3890 transparently pass through from the sending RTSP agent to 3891 the receiving RTSP agent, but there may be cases where this 3892 is not desirable for a given proxy. Modification of the 3893 Public response header field by the intervening proxies 3894 ensures that the request sender gets an accurate response 3895 indicating the methods that can be used on the target agent 3896 via the proxy chain. 3898 14.34 Range 3900 The Range header specifies a time range in PLAY (Section 11.4), PAUSE 3901 (Section 11.5), SETUP (Section 11.3), and REDIRECT (Section 11.9) 3902 requests and/or responses. 3904 The range can be specified in a number of units. This specification 3905 defines smpte (Section 3.4), npt (Section 3.5), and clock (Section 3906 3.6) range units. While byte ranges [H14.35.1] and other extended 3907 units MAY be used, their behavior is unspecified since they are not 3908 normally meaningful in RTSP. Servers supporting the Range header MUST 3909 understand the NPT range format and SHOULD understand the SMPTE range 3910 format. If the Range header is sent in a time format that is not 3911 understood, the recipient SHOULD return 456 (Header Field Not Valid 3912 for Resource) and include an Accept-Ranges header indicating the 3913 supported time formats for the given resource. 3915 The Range header MAY contain a time parameter in UTC, specifying the 3916 time at which the operation is to be made effective. This 3917 functionality SHALL be used only with the REDIRECT method. 3919 Ranges are half-open intervals, including the first point, but 3920 excluding the second point. In other words, a range of A-B starts 3921 exactly at time A, but stops just before B. Only the start time of a 3922 media unit such as a video or audio frame is relevant. For example, 3923 assume that video frames are generated every 40 ms. A range of 3924 10.0-10.1 would include a video frame starting at 10.0 or later time 3925 and would include a video frame starting at 10.08, even though it 3926 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 3927 would exclude the frame at 10.08. 3929 Example: 3931 Range: clock=19960213T143205Z-;time=19970123T143720Z 3933 The notation is similar to that used for the HTTP/1.1 [3] 3934 byte-range header. It allows clients to select an excerpt 3935 from the media object, and to play from a given point to 3936 the end as well as from the current location to a given 3937 point. 3939 By default, range intervals increase, where the second point is 3940 larger than the first point. 3942 Example: 3944 Range: npt=10-15 3946 However, range intervals can also decrease if the Scale header (see 3947 section 14.39) indicates a negative scale value. For example, this 3948 would be the case when a playback in reverse is desired. 3950 Example: 3952 Scale: -1 3953 Range: npt=15-10 3955 Decreasing ranges are still half open intervals as described above. 3956 Thus, for range A-B, A is closed and B is open. In the above example, 3957 15 is closed and 10 is open. An exception to this rule is the case 3958 when B=0 in a decreasing range. In this case, the range is closed on 3959 both ends, as otherwise there would be no way to reach 0 on a reverse 3960 playback. 3962 Example: 3964 Scale: -1 3965 Range: npt=15-0 3967 In this range both 15 and 0 are closed. 3969 A decreasing range interval without a corresponding negative Scale 3970 header is not valid. 3972 14.35 Referer 3974 See [H14.36]. The URI refers to that of the presentation description, 3975 typically retrieved via HTTP. 3977 14.36 Retry-After 3979 See [H14.37]. 3981 14.37 Require 3983 The Require request-header field is used by clients or servers to 3984 ensure that the other end-point supports features that are required 3985 in respect to this request. It can also be used to query if the other 3986 end-point supports certain features, however the use of the Supported 3987 (Section 14.43) is much more effective in this purpose. The server 3988 MUST respond to this header by using the Unsupported header to 3989 negatively acknowledge those feature-tags which are NOT supported. 3990 The response SHALL use the error code 551 (Option Not Supported). 3991 This header does not apply to proxies, for the same functionality in 3992 respect to proxies see, header Proxy-Require (Section 14.31). 3994 This is to make sure that the client-server interaction 3995 will proceed without delay when all features are understood 3996 by both sides, and only slow down if features are not 3997 understood (as in the example below). For a well-matched 3998 client-server pair, the interaction proceeds quickly, 3999 saving a round-trip often required by negotiation 4000 mechanisms. In addition, it also removes state ambiguity 4001 when the client requires features that the server does not 4002 understand. 4004 Example: 4006 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.1 4007 CSeq: 302 4008 Require: funky-feature 4009 Funky-Parameter: funkystuff 4011 S->C: RTSP/1.1 551 Option not supported 4012 CSeq: 302 4013 Unsupported: funky-feature 4015 In this example, "funky-feature" is the feature-tag which indicates 4016 to the client that the fictional Funky-Parameter field is required. 4017 The relationship between "funky-feature" and Funky-Parameter is not 4018 communicated via the RTSP exchange, since that relationship is an 4019 immutable property of "funky-feature" and thus should not be 4020 transmitted with every exchange. 4022 Proxies and other intermediary devices SHALL ignore this header. If a 4023 particular extension requires that intermediate devices support it, 4024 the extension should be tagged in the Proxy-Require field instead 4025 (see Section 14.31). 4027 14.38 RTP-Info 4029 The RTP-Info response-header field is used to set RTP-specific 4030 parameters in the PLAY response. For streams using RTP as transport 4031 protocol the RTP-Info header SHOULD be part of a 200 response to 4032 PLAY. 4034 The exclusion of the RTP-Info in a PLAY response for RTP 4035 transported media will result in that a client needs to 4036 synchronize the media streams using RTCP. This may have 4037 negative impact as the RTCP can be lost, and does not need 4038 to be particulary timely in their arrival. Also 4039 functionality as informing the client from which packet a 4040 seek has occurred is affected. 4042 The RTP-Info MAY also be included in SETUP responses to provide 4043 synchronization information when changing transport parameters, see 4044 11.3. 4046 The header can carry the following parameters: 4048 url: Indicates the stream URI which for which the following RTP 4049 parameters correspond, this URI MUST be the same used in 4050 the SETUP request for this media stream. Any relative URI 4051 SHALL use the Request-URI as base URI. This parameter SHALL 4052 be present. 4054 ssrc: The Synchronization source (SSRC) that the RTP timestamp 4055 and sequence number provide applies to. This parameter 4056 SHALL be present. 4058 seq: Indicates the sequence number of the first packet of the 4059 stream that is direct result of the request. This allows 4060 clients to gracefully deal with packets when seeking. The 4061 client uses this value to differentiate packets that 4062 originated before the seek from packets that originated 4063 after the seek. Note that a client may not receive the 4064 packet with the expressed sequence number, and instead 4065 packets with a higher sequence number, due to packet loss 4066 or reordering. This parameter is RECOMMENDED to be present. 4068 rtptime: SHALL indicate the RTP timestamp value corresponding to 4069 the start time value in the Range response header, or if 4070 not explicitly given the implied start point. The client 4071 uses this value to calculate the mapping of RTP time to NPT 4072 or other media timescale. This parameter SHOULD be present 4073 to ensure inter-media synchronization is achieved. There 4074 exist no requirement that any received RTP packet will have 4075 the same RTP timestamp value as the one in the parameter 4076 used to establish synchronization. 4078 A mapping from RTP timestamps to NTP timestamps (wall 4079 clock) is available via RTCP. However, this information is 4080 not sufficient to generate a mapping from RTP timestamps to 4081 media clock time (NPT, etc.). Furthermore, in order to 4082 ensure that this information is available at the necessary 4083 time (immediately at startup or after a seek), and that it 4084 is delivered reliably, this mapping is placed in the RTSP 4085 control channel. 4087 In order to compensate for drift for long, uninterrupted 4088 presentations, RTSP clients should additionally map NPT to NTP, using 4089 initial RTCP sender reports to do the mapping, and later reports to 4090 check drift against the mapping. 4092 Example: 4094 Range:npt=3.25-15 4095 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 4096 rtptime=12345678,url="rtsp://example.com/foo/video" 4097 ssrc=9A9DE123:seq=30211;rtptime=29567112 4099 Lets assume that audio uses a 16kHz RTP timestamp clock and Video 4100 a 90kHz RTP timestamp clock. Then the media synchronization is 4101 depicted in the following way. 4103 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 4104 Audio PA A 4105 Video V PV 4107 X: NPT time value = 3.25, from Range header. 4108 A: RTP timestamp value for Audio from RTP-Info header (12345678). 4109 V: RTP timestamp value for Video from RTP-Info header (29567112). 4111 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 4112 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 4113 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 4114 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 4116 14.39 Scale 4118 A scale value of 1 indicates normal play at the normal forward 4119 viewing rate. If not 1, the value corresponds to the rate with 4120 respect to normal viewing rate. For example, a ratio of 2 indicates 4121 twice the normal viewing rate ("fast forward") and a ratio of 0.5 4122 indicates half the normal viewing rate. In other words, a ratio of 2 4123 has normal play time increase at twice the wallclock rate. For every 4124 second of elapsed (wallclock) time, 2 seconds of content will be 4125 delivered. A negative value indicates reverse direction. For certain 4126 media transports this may require certain considerations to work 4127 consistent, see section B.1 for description on how RTP handles this. 4129 Unless requested otherwise by the Speed parameter, the data rate 4130 SHOULD not be changed. Implementation of scale changes depends on the 4131 server and media type. For video, a server may, for example, deliver 4132 only key frames or selected key frames. For audio, it may time-scale 4133 the audio while preserving pitch or, less desirably, deliver 4134 fragments of audio. 4136 The server should try to approximate the viewing rate, but may 4137 restrict the range of scale values that it supports. The response 4138 MUST contain the actual scale value chosen by the server. 4140 If the server does not implement the possibility to scale, it will 4141 not return a Scale header. A server supporting Scale operations for 4142 PLAY SHALL indicate this with the use of the "play.scale" feature- 4143 tags. 4145 When indicating a negative scale for a reverse playback, the Range 4146 header MUST indicate a decreasing range as described in section 4147 14.34. 4149 Example of playing in reverse at 3.5 times normal rate: 4151 Scale: -3.5 4152 Range: npt=15-10 4154 14.40 Speed 4155 The Speed request-header field requests the server to deliver data to 4156 the client at a particular speed, contingent on the server's ability 4157 and desire to serve the media stream at the given speed. 4158 Implementation by the server is OPTIONAL. The default is the bit rate 4159 of the stream. 4161 The parameter value is expressed as a decimal ratio, e.g., a value of 4162 2.0 indicates that data is to be delivered twice as fast as normal. A 4163 speed of zero is invalid. All speeds may not be possible to support. 4164 Therefore the actual used speed MUST be included in the response. The 4165 lack of a response header is indication of lack of support from the 4166 server of this functionality. Support of the speed functionality are 4167 indicated by the "play.speed" featuretag. 4169 Example: 4171 Speed: 2.5 4173 Use of this field changes the bandwidth used for data delivery. It is 4174 meant for use in specific circumstances where preview of the 4175 presentation at a higher or lower rate is necessary. Implementors 4176 should keep in mind that bandwidth for the session may be negotiated 4177 beforehand (by means other than RTSP), and therefore re-negotiation 4178 may be necessary. When data is delivered over UDP, it is highly 4179 recommended that means such as RTCP be used to track packet loss 4180 rates. If the data transport is performed over public best-effort 4181 networks the sender MUST perform congestion control of the stream(s). 4182 This can result in that the communicated speed is impossible to 4183 maintain. 4185 14.41 Server 4187 See [H14.38], however the header syntax is corrected in section 4188 19.2.3. 4190 14.42 Session 4192 The Session request-header and response-header field identifies an 4193 RTSP session. An RTSP session is created by the server as a result of 4194 a successful SETUP request and in the response the session identifier 4195 is given to the client. The RTSP session exist until destroyed by a 4196 TEARDOWN or timed out by the server. 4198 The session identifier is chosen by the server (see Section 3.3) and 4199 MUST be returned in the SETUP response. Once a client receives a 4200 session identifier, it SHALL be included in any request related to 4201 that session. This means that the Session header MUST be included in 4202 a request using the following methods: PLAY, PAUSE, and TEARDOWN, and 4203 MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and 4204 REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response 4205 the session header SHALL be included in methods, SETUP, PLAY, and 4206 PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if 4207 included in the request of the following methods it SHALL also be 4208 included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER, 4209 and SHALL NOT be included in DESCRIBE. 4211 The timeout parameter MAY be included in a SETUP response, and SHALL 4212 NOT be included in requests. The server uses it to indicate to the 4213 client how long the server is prepared to wait between RTSP commands 4214 or other signs of life before closing the session due to lack of 4215 activity (see below and Section A). The timeout is measured in 4216 seconds, with a default of 60 seconds (1 minute). The length of the 4217 session timeout SHALL NOT be changed in a established session. 4219 The mechanisms for showing liveness of the client is, any RTSP 4220 request with a Session header, if RTP & RTCP is used an RTCP message, 4221 or through any other used media protocol capable of indicating 4222 liveness of the RTSP client. It is RECOMMENDED that a client does not 4223 wait to the last second of the timeout before trying to send a 4224 liveness message. The RTSP message may be lost or when using reliable 4225 protocols, such as TCP, the message may take some time to arrive 4226 safely at the receiver. To show liveness between RTSP request issued 4227 to accomplish other things, the following mechanisms can be used, in 4228 descending order of preference: 4230 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 4231 RTCP is used to report transport statistics, it SHALL also 4232 work as keep alive. The server can determine the client by 4233 used network address and port together with the fact that 4234 the client is reporting on the servers SSRC(s). A downside 4235 of using RTCP is that it only gives statistical guarantees 4236 to reach the server. However that probability is so low 4237 that it can be ignored in most cases. For example, a 4238 session with 60 seconds timeout and enough bitrate assigned 4239 to RTCP messages to send a message from client to server on 4240 average every 5 seconds. That client have for a network 4241 with 5 % packet loss, the probability to fail showing 4242 liveness sign in that session within the timeout interval 4243 of 2.4*E-16. In sessions with shorter timeout times, or 4244 much higher packet loss, or small RTCP bandwidths SHOULD 4245 also use any of the mechanisms below. 4247 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 4248 SHOULD be included. This method is the RECOMMENDED RTSP 4249 method to use in request only intended to perform keep- 4250 alive. 4252 OPTIONS: This method does also work. However it causes the 4253 server to perform unnecessary processing and result in 4254 bigger responses than necessary for the task. The reason 4255 for this is that the server needs to determine what 4256 capabilities that are associated with the media resource to 4257 correctly populate the Public and Allow headers. 4259 Note that a session identifier identifies an RTSP session across 4260 transport sessions or connections. RTSP requests for a given session 4261 can use different URIs (Presentation and media URIs). Note, that 4262 there are restrictions depending on the session which URIs that are 4263 acceptable for a given method. However, multiple "user" sessions for 4264 the same URI from the same client will require use of different 4265 session identifiers. 4267 The session identifier is needed to distinguish several 4268 delivery requests for the same URI coming from the same 4269 client. 4271 The response 454 (Session Not Found) SHALL be returned if the session 4272 identifier is invalid. 4274 14.43 Supported 4276 The Supported header field enumerates all the extensions supported by 4277 the client or server using feature tags. The header carries the 4278 extensions supported by the message sending entity. The Supported 4279 header MAY be included in any request. When present in a request, 4280 the receiver MUST respond with its corresponding Supported header. 4281 Note, also in 4xx and 5xx responses is the supported header included. 4283 The Supported header field contains a list of feature-tags, described 4284 in Section 3.7, that are understood by the client or server. 4286 Example: 4288 C->S: OPTIONS rtsp://example.com/ RTSP/1.1 4289 Supported: foo, bar, blech 4291 S->C: RTSP/1.1 200 OK 4292 Supported: bar, blech, baz 4294 14.44 Timestamp 4295 The Timestamp general-header field describes when the agent sent the 4296 request. The value of the timestamp is of significance only to the 4297 agent and may use any timescale. The responding agent MUST echo the 4298 exact same value and MAY, if it has accurate information about this, 4299 add a floating point number indicating the number of seconds that has 4300 elapsed since it has received the request. The timestamp is used by 4301 the agent to compute the round-trip time to the responding agent so 4302 that it can adjust the timeout value for retransmissions. It also 4303 resolves retransmission ambiguities for unreliable transport of RTSP. 4305 14.45 Transport 4307 The Transport request and response header field indicates which 4308 transport protocol is to be used and configures its parameters such 4309 as destination address, compression, multicast time-to-live and 4310 destination port for a single stream. It sets those values not 4311 already determined by a presentation description. 4313 Transports are comma separated, listed in order of preference. 4314 Parameters may be added to each transport, separated by a semicolon. 4315 The server SHOULD return a Transport response-header field in the 4316 response to indicate the values actually chosen. The Transport header 4317 field MAY also be used to change certain transport parameters. A 4318 server MAY refuse to change parameters of an existing stream. 4320 A Transport request header field MAY contain a list of transport 4321 options acceptable to the client, in the form of multiple 4322 transportspec entries. In that case, the server MUST return the 4323 single (transport-spec) which was actually chosen. The number of 4324 transportspec entries is expected to be limited as the client will 4325 get guidance on what configurations that are possible from the 4326 presentation description. 4328 A transport-spec transport option may only contain one of any given 4329 parameter within it. Parameters MAY be given in any order. 4330 Additionally, it may only contain the unicast or the multicast 4331 transport type parameter. Unknown parameters SHALL be ignored. The 4332 requester need to ensure that the responder understands the 4333 parameters through the use of feature tags and the Require header. 4335 Any parameters part of future extensions requires clarification if 4336 they are safe to ignore in accordance to this specification, or is 4337 required to be understood. If a parameter is required to be 4338 understood, then a feature tag MUST be defined for the functionality 4339 and used in the Require and/or Proxy-Require headers. 4341 The Transport header field is restricted to describing a 4342 single media stream. (RTSP can also control multiple 4343 streams as a single entity.) Making it part of RTSP rather 4344 than relying on a multitude of session description formats 4345 greatly simplifies designs of firewalls. 4347 The syntax for the transport specifier is 4349 transport/profile/lower-transport. 4351 The default value for the "lower-transport" parameters is specific to 4352 the profile. For RTP/AVP, the default is UDP. 4354 There are two different methods for how to specify where the media 4355 should be delivered: 4357 o The presence of this parameter and its values indicates the 4358 destination address or addresses (host address and port pairs 4359 for IP flows) necessary for the media transport. 4361 o The lack of the dest_addr parameter indicates that the server 4362 SHALL send media to same address for which the RTSP messages 4363 originates. Does not work for transports requiring explicitly 4364 given destination ports. 4366 The choice of method for indicating where the media is to be 4367 delivered depends on the use case. In many case the only allowed 4368 method will be to use no explicit address indication and have the 4369 server deliver media to the source of the RTSP messages. 4371 An RTSP proxy will need to take care. If the media is not desired to 4372 be routed through the proxy, the proxy will need to introduce the 4373 destination indication. 4375 Below are the configuration parameters associated with transport: 4377 General parameters: 4379 unicast / multicast: This parameter is a mutually exclusive 4380 indication of whether unicast or multicast delivery will be 4381 attempted. One of the two values MUST be specified. Clients 4382 that are capable of handling both unicast and multicast 4383 transmission needs to indicate such capability by including 4384 two full transport-specs with separate parameters for each. 4386 layers: The number of multicast layers to be used for this media 4387 stream. The layers are sent to consecutive addresses 4388 starting at the dest_addr address. 4390 dest_addr: A general destination address parameter that can 4391 contain one or more address specifications. Each 4392 combination of Protocol/Profile/Lower Transport needs to 4393 have the format and interpretation of its address 4394 specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, 4395 the address specification is a tuple containing a host 4396 address and port. 4398 The client originating the RTSP request MAY specify the 4399 destination address of the stream recipient with the host 4400 address part of the tuple. When the destination address is 4401 specified, the recipient may be a different party than the 4402 originator of the request. To avoid becoming the unwitting 4403 perpetrator of a remote-controlled denial-of-service 4404 attack, a server MUST perform security checks (see Section 4405 20.1) and SHOULD log such attempts before allowing the 4406 client to direct a media stream to a recipient address not 4407 chosen by the server. Implementations cannot rely on TCP as 4408 reliable means of client identification. If the server does 4409 not allow the host address part of the tuple to be set, it 4410 SHALL return 463 (Destination Prohibited). 4412 The host address part of the tuple MAY be empty, for 4413 example ":58044", in cases when only destination port is 4414 desired to be specified. 4416 src_addr: A general source address parameter that can contain 4417 one or more address specifications. Each combination of 4418 Protocol/Profile/Lower Transport needs to have the format 4419 and interpretation of its address specification defined. 4420 For RTP/AVP/UDP and RTP/AVP/TCP, the address specification 4421 is a tuple containing a host address and port. 4423 This parameter MUST be specified by the server if it 4424 transmits media packets from another address than the one 4425 RTSP messages are sent to. This will allow the client to 4426 verify source address and give it a destination address for 4427 its RTCP feedback packets if RTP is used. The address or 4428 addresses indicated in the src_addr parameter SHOULD be 4429 used both for sending and receiving of the media streams 4430 data packets. The main reasons are threefold: First, 4431 indicating the port and source address(s) lets the receiver 4432 know where from the packets is expected to originate. 4433 Secondly, traversal of NATs are greatly simplified when 4434 traffic is flowing symmetrically over a NAT binding. 4435 Thirdly, certain NAT traversal mechanisms, needs to know to 4436 which address and port to send so called "binding packets" 4437 from the receiver to the sender, thus creating a address 4438 binding in the NAT that the sender to receiver packet flow 4439 can use. 4441 This information may also be available through SDP. 4442 However, since this is more a feature of transport 4443 than media initialization, the authoritative source 4444 for this information should be in the SETUP response. 4446 mode: The mode parameter indicates the methods to be supported 4447 for this session. Valid values are PLAY and RECORD. If not 4448 provided, the default is PLAY. The RECORD value was 4449 defined in RFC 2326 and is deprecated in this 4450 specification. 4452 append: The append parameter was used together with RECORD and 4453 is now deprecated. 4455 interleaved: The interleaved parameter implies mixing the media 4456 stream with the control stream in whatever protocol is 4457 being used by the control stream, using the mechanism 4458 defined in Section 12. The argument provides the channel 4459 number to be used in the $ statement and MUST be present. 4460 This parameter MAY be specified as a range, e.g., 4461 interleaved=4-5 in cases where the transport choice for the 4462 media stream requires it, e.g. for RTP with RTCP. The 4463 channel number given in the request are only a guidance 4464 from the client to the server on what channel number(s) to 4465 use. The server MAY set any valid channel number in the 4466 response. The declared channel(s) are bi-directional, so 4467 both end-parties MAY send data on the given channel. One 4468 example of such usage is the second channel used for RTCP, 4469 where both server and client sends RTCP packets on the same 4470 channel. 4472 This allows RTP/RTCP to be handled similarly to the 4473 way that it is done with UDP, i.e., one channel for 4474 RTP and the other for RTCP. 4476 Multicast-specific: 4478 ttl: multicast time-to-live. 4480 RTP-specific: 4482 These parameters are MAY only be used if the media transport protocol 4483 is RTP. 4485 ssrc: The ssrc parameter, if included in a SETUP response, 4486 indicates the RTP SSRC [16] value(s) that will be used by 4487 the media server for RTP packets within the stream. It is 4488 expressed as an eight digit hexadecimal value. 4490 The ssrc parameter SHALL NOT be specified in requests. The 4491 functionality of specifying the ssrc parameter in a SETUP 4492 request is deprecated as it is incompatible with the 4493 specification of RTP in RFC 3550 [16]. If the parameter is 4494 included in the Transport header of a SETUP request, the 4495 server MAY ignore it, and choose an appropriate SSRC for 4496 the stream. The server MAY set the ssrc parameter in the 4497 Transport header of the response. 4499 The combination of transport protocol, profile and lower transport 4500 needs to be defined. A number of combinations are defined in the 4501 appendix B. 4503 Below is a usage example, showing a client advertising the capability 4504 to handle multicast or unicast, preferring multicast. Since this is 4505 a unicast-only stream, the server responds with the proper transport 4506 parameters for unicast. 4508 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.1 4509 CSeq: 302 4510 Transport: RTP/AVP;multicast;mode="PLAY", 4511 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 4512 "192.0.2.5:3457";mode="PLAY" 4514 S->C: RTSP/1.1 200 OK 4515 CSeq: 302 4516 Date: 23 Jan 1997 15:35:06 GMT 4517 Session: 47112344 4518 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 4519 "192.0.2.5:3457";src_addr="192.0.2.224:6256" 4520 /"192.0.2.224:6257";mode="PLAY" 4522 14.46 Unsupported 4524 The Unsupported response-header field lists the features not 4525 supported by the server. In the case where the feature was specified 4526 via the Proxy-Require field (Section 14.31), if there is a proxy on 4527 the path between the client and the server, the proxy MUST send a 4528 response message with a status code of 551 (Option Not Supported). 4529 The request SHALL NOT be forwarded. 4531 See Section 14.37 for a usage example. 4533 14.47 User-Agent 4535 See [H14.43] for explanation, however the syntax is clarified due to 4536 an error in RFC 2616. A Client SHOULD include this header in all RTSP 4537 messages it sends. 4539 14.48 Vary 4541 See [H14.44] 4543 14.49 Via 4545 See [H14.45]. 4547 14.50 WWW-Authenticate 4549 See [H14.47]. 4551 15 Proxies 4553 RTSP Proxies are RTSP agents that sit in between a client and a 4554 server. A proxy can take on both the role as a client and as server 4555 depending on what it tries to accomplish. Proxies are also introduced 4556 for several different reasons. 4558 o This type of proxy is used to reduce the workload on servers 4559 and connections. By caching a presentation, both description 4560 and media streams the proxy can serve a client content without 4561 requesting it from the server once it has been cached and 4562 hasn't become stale. See the caching section 16. 4564 o This type of proxy is used to ensure that a RTSP client get 4565 access to servers on an external network. Thus this proxy is 4566 placed on the border between two domains, e.g. a private 4567 address space and the public internet. The proxy performs the 4568 necessary translation, usually addresses, and often also media 4569 stream translation or redirection. 4571 o This type of proxy is used to help facilitate security 4572 functions around RTSP. For example when having a firewalled 4573 network, the security proxy request that the necessary 4574 pinholes in the firewall is opened when a client in the 4575 protected network want to access media streams on the external 4576 side. It can also provide network owners with a logging and 4577 audit point for RTSP sessions, e.g. for corporations that 4578 tracks or limits their employees access to certain type of 4579 content. 4581 All type of proxies can be used also when using secured communication 4582 with TLS as RTSP 1.1 allows the client to approve certificates for 4583 connection establishment from a proxy, see section 18.3.2. 4585 Access proxies SHOULD NOT be used in equipment like NATs and 4586 firewalls that aren't expected to be regularly maintained, like home 4587 or small office equipment. In these cases it is better to use the NAT 4588 traversal procedures defined for RTSP 1.1 [25]. The reason for these 4589 recommendations is that any extensions of RTSP resulting in new media 4590 transport protocols or profiles, new parameters etc may fail in a 4591 proxy that isn't maintained. Thus resulting in blocking further 4592 development of RTSP and its usage. 4594 The existence of proxies must always be considered when developing 4595 new RTSP extensions. There must be definition of how proxies may 4596 handle the extension, if it is required to understand it, thus 4597 requiring a feature tag to be used in the Proxy-Require header. 4599 16 Caching 4601 In HTTP, response-request pairs are cached. RTSP differs 4602 significantly in that respect. Responses are not cacheable, with the 4603 exception of the presentation description returned by DESCRIBE. 4604 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4605 not return any data, caching is not really an issue for these 4606 requests.) However, it is desirable for the continuous media data, 4607 typically delivered out-of-band with respect to RTSP, to be cached, 4608 as well as the session description. 4610 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4611 has an up-to-date copy of the continuous media content and its 4612 description. It can determine whether the copy is up-to-date by 4613 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4614 Last-Modified header with that of the cached copy. If the copy is not 4615 up-to-date, it modifies the SETUP transport parameters as appropriate 4616 and forwards the request to the origin server. Subsequent control 4617 commands such as PLAY or PAUSE then pass the proxy unmodified. The 4618 proxy delivers the continuous media data to the client, while 4619 possibly making a local copy for later reuse. The exact behavior 4620 allowed to the cache is given by the cache-response directives 4621 described in Section 14.10. A cache MUST answer any DESCRIBE requests 4622 if it is currently serving the stream to the requestor, as it is 4623 possible that low-level details of the stream description may have 4624 changed on the origin-server. 4626 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 4627 through" variety. Rather than retrieving the whole resource from the 4628 origin server, the cache simply copies the streaming data as it 4629 passes by on its way to the client. Thus, it does not introduce 4630 additional latency. 4632 To the client, an RTSP proxy cache appears like a regular media 4633 server, to the media origin server like a client. Just as an HTTP 4634 cache has to store the content type, content language, and so on for 4635 the objects it caches, a media cache has to store the presentation 4636 description. Typically, a cache eliminates all transport-references 4637 (that is, multicast information) from the presentation description, 4638 since these are independent of the data delivery from the cache to 4639 the client. Information on the encodings remains the same. If the 4640 cache is able to translate the cached media data, it would create a 4641 new presentation description with all the encoding possibilities it 4642 can offer. 4644 17 Examples 4646 This section contains several different examples trying to illustrate 4647 possible ways of using RTSP. The examples can also help with the 4648 understanding of how functions of RTSP work. However remember that 4649 this is examples and the normative and syntax description in the 4650 other sections takes precedence. Please also note that many of the 4651 example MAY contain syntax illegal line breaks to accommodate the 4652 formatting restriction that the RFC series impose. 4654 17.1 Media on Demand (Unicast) 4656 Client C requests a movie distributed from two different media 4657 servers A (audio.example.com ) and V (video.example.com ). The media 4658 description is stored on a web server W. The media description 4659 contains descriptions of the presentation and all its streams, 4660 including the codecs that are available, dynamic RTP payload types, 4661 the protocol stack, and content information such as language or 4662 copyright restrictions. It may also give an indication about the 4663 timeline of the movie. 4665 In this example, the client is only interested in the last part of 4666 the movie. 4668 C->W: GET /twister.sdp HTTP/1.1 4669 Host: www.example.com 4670 Accept: application/sdp 4672 W->C: HTTP/1.0 200 OK 4673 Date: 23 Jan 1997 15:35:06 GMT 4674 Content-Type: application/sdp 4675 Content-Length: 264 4676 Expires: 23 Jan 1998 15:35:06 GMT 4678 v=0 4679 o=- 2890844526 2890842807 IN IP4 192.16.24.202 4680 s=RTSP Session 4681 e=adm@example.com 4682 a=range:npt=0-1:49:34 4683 t=0 0 4684 m=audio 0 RTP/AVP 0 4685 a=control:rtsp://audio.example.com/twister/audio.en 4686 m=video 0 RTP/AVP 31 4687 a=control:rtsp://video.example.com/twister/video 4689 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.1 4690 CSeq: 1 4691 User-Agent: PhonyClient/1.2 4692 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 4693 RTP/AVP/TCP;unicast;interleaved=0-1 4695 A->C: RTSP/1.1 200 OK 4696 CSeq: 1 4697 Session: 12345678 4698 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 4699 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 4700 Date: 23 Jan 1997 15:35:12 GMT 4701 Server: PhonyServer/1.0 4702 Expires: 24 Jan 1997 15:35:12 GMT 4703 Cache-Control: public 4704 Accept-Ranges: NPT, SMPTE 4706 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.1 4707 CSeq: 1 4708 User-Agent: PhonyClient/1.2 4709 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059", 4710 RTP/AVP/TCP;unicast;interleaved=0-1 4712 V->C: RTSP/1.1 200 OK 4713 CSeq: 1 4714 Session: 23456789 4715 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059"; 4716 src_addr="192.0.2.5:5002"/"192.0.2.5:5003" 4717 Date: 23 Jan 1997 15:35:12 GMT 4718 Server: PhonyServer/1.0 4719 Cache-Control: public 4720 Expires: 24 Jan 1997 15:35:12 GMT 4721 Accept-Ranges: NPT, SMPTE 4723 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.1 4724 CSeq: 2 4725 User-Agent: PhonyClient/1.2 4726 Session: 23456789 4727 Range: smpte=0:10:00- 4729 V->C: RTSP/1.1 200 OK 4730 CSeq: 2 4731 Session: 23456789 4732 Range: smpte=0:10:00-1:49:23 4733 RTP-Info: url="rtsp://video.example.com/twister/video" 4734 ssrc=A17E189D:seq=12312232;rtptime=78712811 4735 Server: PhonyServer/2.0 4736 Date: 23 Jan 1997 15:35:13 GMT 4738 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.1 4739 CSeq: 2 4740 User-Agent: PhonyClient/1.2 4741 Session: 12345678 4742 Range: smpte=0:10:00- 4744 A->C: RTSP/1.1 200 OK 4745 CSeq: 2 4746 Session: 12345678 4747 Range: smpte=0:10:00-1:49:23 4748 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 4749 ssrc=3D124F01:seq=876655;rtptime=1032181 4750 Server: PhonyServer/1.0 4751 Date: 23 Jan 1997 15:35:13 GMT 4753 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.1 4754 CSeq: 3 4755 User-Agent: PhonyClient/1.2 4756 Session: 12345678 4758 A->C: RTSP/1.1 200 OK 4759 CSeq: 3 4760 Server: PhonyServer/1.0 4761 Date: 23 Jan 1997 15:36:52 GMT 4763 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.1 4764 CSeq: 3 4765 User-Agent: PhonyClient/1.2 4766 Session: 23456789 4768 V->C: RTSP/1.1 200 OK 4769 CSeq: 3 4770 Server: PhonyServer/2.0 4771 Date: 23 Jan 1997 15:36:52 GMT 4773 Even though the audio and video track are on two different servers, 4774 may start at slightly different times, and may drift with respect to 4775 each other, the client can synchronize the two using standard RTP 4776 methods, in particular the time scale contained in the RTCP sender 4777 reports. Initial synchronization is achieved through the RTP-Info and 4778 Range headers information in the PLAY response. 4780 17.2 Streaming of a Container file 4782 For purposes of this example, a container file is a storage entity in 4783 which multiple continuous media types pertaining to the same end-user 4784 presentation are present. In effect, the container file represents an 4785 RTSP presentation, with each of its components being RTSP streams. 4786 Container files are a widely used means to store such presentations. 4787 While the components are transported as independent streams, it is 4788 desirable to maintain a common context for those streams at the 4789 server end. 4791 This enables the server to keep a single storage handle 4792 open easily. It also allows treating all the streams 4793 equally in case of any prioritization of streams by the 4794 server. 4796 It is also possible that the presentation author may wish to prevent 4797 selective retrieval of the streams by the client in order to preserve 4798 the artistic effect of the combined media presentation. Similarly, in 4799 such a tightly bound presentation, it is desirable to be able to 4800 control all the streams via a single control message using an 4801 aggregate URI. 4803 The following is an example of using a single RTSP session to control 4804 multiple streams. It also illustrates the use of aggregate URIs. In a 4805 container file it is also desirable to not write any URI parts which 4806 is not kept, when the container is distributed, like the host and 4807 most of the path element. Therefore this example also uses the "*" 4808 and relative URI in the delivered SDP. 4810 Client C requests a presentation from media server M. The movie is 4811 stored in a container file. The client has obtained an RTSP URI to 4812 the container file. 4814 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/1.1 4815 CSeq: 1 4816 User-Agent: PhonyClient/1.2 4818 M->C: RTSP/1.1 200 OK 4819 CSeq: 1 4820 Server: PhonyServer/1.0 4821 Date: 23 Jan 1997 15:35:06 GMT 4822 Content-Type: application/sdp 4823 Content-Length: 257 4824 Content-Base: rtsp://example.com/twister.3gp/ 4825 Expires: 24 Jan 1997 15:35:06 GMT 4827 v=0 4828 o=- 2890844256 2890842807 IN IP4 172.16.2.93 4829 s=RTSP Session 4830 i=An Example of RTSP Session Usage 4831 e=adm@example.com 4832 a=control: * 4833 a=range: npt=0-0:10:34.10 4834 t=0 0 4835 m=audio 0 RTP/AVP 0 4836 a=control: trackID=1 4837 m=video 0 RTP/AVP 26 4838 a=control: trackID=4 4840 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/1.1 4841 CSeq: 2 4842 User-Agent: PhonyClient/1.2 4843 Require: play.basic 4844 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 4846 M->C: RTSP/1.1 200 OK 4847 CSeq: 2 4848 Server: PhonyServer/1.0 4849 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; 4850 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 4851 ssrc=93CB001E 4852 Session: 12345678 4853 Expires: 24 Jan 1997 15:35:12 GMT 4854 Date: 23 Jan 1997 15:35:12 GMT 4855 Accept-Ranges: NPT 4857 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/1.1 4858 CSeq: 3 4859 User-Agent: PhonyClient/1.2 4860 Require: play.basic 4861 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 4862 Session: 12345678 4864 M->C: RTSP/1.1 200 OK 4865 CSeq: 3 4866 Server: PhonyServer/1.0 4867 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; 4868 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 4869 ssrc=A813FC13 4870 Session: 12345678 4871 Expires: 24 Jan 1997 15:35:13 GMT 4872 Date: 23 Jan 1997 15:35:13 GMT 4873 Accept-Range: NPT 4875 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.1 4876 CSeq: 4 4877 User-Agent: PhonyClient/1.2 4878 Range: npt=0-10, npt=30- 4879 Session: 12345678 4881 M->C: RTSP/1.1 200 OK 4882 CSeq: 4 4883 Server: PhonyServer/1.0 4884 Date: 23 Jan 1997 15:35:14 GMT 4885 Session: 12345678 4886 Range: npt=0-10, npt=30-623.10 4887 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 4888 ssrc=0D12F123:seq=12345;rtptime=3450012, 4889 url="rtsp://example.com/twister.3gp/trackID=1"; 4890 ssrc=4F312DD8:seq=54321;rtptime=2876889 4892 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/1.1 4893 CSeq: 5 4894 User-Agent: PhonyClient/1.2 4895 Session: 12345678 4897 M->C: RTSP/1.1 200 OK 4898 CSeq: 5 4899 Server: PhonyServer/1.0 4900 Date: 23 Jan 1997 15:36:01 GMT 4901 Session: 12345678 4902 Range: npt=34.57-623.10 4904 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.1 4905 CSeq: 6 4906 User-Agent: PhonyClient/1.2 4907 Range: npt=34.57-623.10 4908 Session: 12345678 4910 M->C: RTSP/1.1 200 OK 4911 CSeq: 6 4912 Server: PhonyServer/1.0 4913 Date: 23 Jan 1997 15:36:01 GMT 4914 Session: 12345678 4915 Range: npt=34.57-623.10 4916 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 4917 ssrc=0D12F123:seq=12555;rtptime=6330012, 4918 url="rtsp://example.com/twister.3gp/trackID=1" 4919 ssrc=4F312DD8:seq=55021;rtptime=3132889 4921 17.3 Single Stream Container Files 4923 Some RTSP servers may treat all files as though they are "container 4924 files", yet other servers may not support such a concept. Because of 4925 this, clients SHOULD use the rules set forth in the session 4926 description for Request-URIs, rather than assuming that a consistent 4927 URI may always be used throughout. Below are an example of how a 4928 multi-stream server might expect a single-stream file to be served: 4930 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/1.1 4931 Accept: application/x-rtsp-mh, application/sdp 4932 CSeq: 1 4933 User-Agent: PhonyClient/1.2 4935 S->C: RTSP/1.1 200 OK 4936 CSeq: 1 4937 Content-base: rtsp://foo.com/test.wav/ 4938 Content-type: application/sdp 4939 Content-length: 148 4940 Server: PhonyServer/1.0 4941 Date: 23 Jan 1997 15:35:06 GMT 4942 Expires: 23 Jan 1997 17:00:00 GMT 4944 v=0 4945 o=- 872653257 872653257 IN IP4 172.16.2.187 4946 s=mu-law wave file 4947 i=audio test 4948 t=0 0 4949 a=control: * 4950 m=audio 0 RTP/AVP 0 4951 a=control:streamid=0 4953 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.1 4954 Transport: RTP/AVP/UDP;unicast; 4955 dest_addr=":6970"/":6971";mode="PLAY" 4956 CSeq: 2 4957 User-Agent: PhonyClient/1.2 4959 S->C: RTSP/1.1 200 OK 4960 Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971"; 4961 src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; 4962 mode="PLAY";ssrc=EAB98712 4963 CSeq: 2 4964 Session: 2034820394 4965 Expires: 23 Jan 1997 16:00:00 GMT 4966 Server: PhonyServer/1.0 4967 Date: 23 Jan 1997 15:35:07 GMT 4969 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/1.1 4970 CSeq: 3 4971 User-Agent: PhonyClient/1.2 4972 Session: 2034820394 4974 S->C: RTSP/1.1 200 OK 4975 CSeq: 3 4976 Server: PhonyServer/1.0 4977 Date: 23 Jan 1997 15:35:08 GMT 4978 Session: 2034820394 4979 Range: npt=0-600 4980 RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" 4981 ssrc=0D12F123:seq=981888;rtptime=3781123 4983 Note the different URI in the SETUP command, and then the switch back 4984 to the aggregate URI in the PLAY command. This makes complete sense 4985 when there are multiple streams with aggregate control, but is less 4986 than intuitive in the special case where the number of streams is 4987 one. However the server has declared that the aggregated control URI 4988 in the SDP and therefore this is legal. 4990 In this case, it is also required that servers accept implementations 4991 that use the non-aggregated interpretation and use the individual 4992 media URI, like this: 4994 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.1 4995 CSeq: 3 4996 User-Agent: PhonyClient/1.2 4998 17.4 Live Media Presentation Using Multicast 5000 The media server M chooses the multicast address and port. Here, it 5001 is assumed that the web server only contains a pointer to the full 5002 description, while the media server M maintains the full description. 5004 C->W: GET /sessions.html HTTP/1.1 5005 Host: www.example.com 5007 W->C: HTTP/1.1 200 OK 5008 Content-Type: text/html 5010 5011 ... 5012 5014 ... 5015 5017 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.1 5018 CSeq: 1 5019 Supported: play.basic, play.scale 5021 M->C: RTSP/1.1 200 OK 5022 CSeq: 1 5023 Content-Type: application/sdp 5024 Content-Length: 182 5025 Server: PhonyServer/1.0 5026 Date: 23 Jan 1997 15:35:06 GMT 5027 Supported: play.basic 5029 v=0 5030 o=- 2890844526 2890842807 IN IP4 192.16.24.202 5031 s=RTSP Session 5032 m=audio 3456 RTP/AVP 0 5033 c=IN IP4 224.2.0.1/16 5034 a=control: rtsp://live.example.com/concert/audio 5035 a=range:npt=0- 5037 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.1 5038 CSeq: 2 5039 Transport: RTP/AVP;multicast 5041 M->C: RTSP/1.1 200 OK 5042 CSeq: 2 5043 Server: PhonyServer/1.0 5044 Date: 23 Jan 1997 15:35:06 GMT 5045 Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/" 5046 224.2.0.1:3457";ttl=16 5047 Session: 0456804596 5048 Accept-Ranges: NPT, UTC 5050 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.1 5051 CSeq: 3 5052 Session: 0456804596 5054 M->C: RTSP/1.1 200 OK 5055 CSeq: 3 5056 Server: PhonyServer/1.0 5057 Date: 23 Jan 1997 15:35:07 GMT 5058 Session: 0456804596 5059 Range:npt=1256- 5060 RTP-Info: url="rtsp://live.example.com/concert/audio" 5061 ssrc=0D12F123:seq=1473; rtptime=80000 5063 17.5 Capability Negotiation 5065 This examples illustrate how the client and server determines their 5066 capability to support a special feature, in this case "play.scale". 5067 The server, through the clients request and the included Supported 5068 header, learns that the client is supporting this updated 5069 specification, and also supports the playback time scaling feature of 5070 RTSP. The server's response contains the following feature related 5071 information to the client; it supports the updated specification 5072 (play.basic), the extended functionality of time scaling of content 5073 (play.scale), and one "example.com" proprietary feature 5074 (example.com.flight). The client also learns the methods supported 5075 (Public header) by the server for the indicated resource. 5077 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/1.1 5078 CSeq: 1 5079 Supported: play.basic, play.scale 5080 User-Agent: PhonyClient/1.2 5082 S->C: RTSP/1.1 200 OK 5083 CSeq: 1 5084 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 5085 Server: PhonyServer/2.0 5086 Supported: play.basic, play.scale, example.com.flight 5088 When the client sends its SETUP request it tells the server that it 5089 is requires support of the play.scale feature for this session by 5090 including the Require header. 5092 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/1.1 5093 CSeq: 3 5094 User-Agent: PhonyClient/1.2 5095 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 5096 RTP/AVP/TCP;unicast;interleaved=0-1 5097 Require: play.scale 5099 S->C: RTSP/1.1 200 OK 5100 CSeq: 3 5101 Session: 12345678 5102 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 5103 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 5104 Server: PhonyServer/2.0 5105 Accept-Ranges: NPT, SMPTE 5107 18 Security Framework 5109 The RTSP security framework consists of two high level components: 5110 the pure authentication mechanisms based on HTTP authentication, and 5111 the transport protection based on TLS, which is independent of RTSP. 5112 Because of the similarity in syntax and usage between RTSP servers 5113 and HTTP servers, the security for HTTP is re-used to a large extent. 5115 18.1 RTSP and HTTP Authentication 5117 RTSP and HTTP share common authentication schemes, and thus follow 5118 the same usage guidelines as specified in [7] and also in [H15]. 5119 Servers SHOULD implement both basic and digest [7] authentication. 5121 It should be stressed that using the HTTP authentication alone does 5122 not provide full control message security. Therefore, in environments 5123 requiring tighter security for the control messages, TLS SHOULD be 5124 used, see Section 18.2. 5126 18.2 RTSP over TLS 5128 RTSP SHALL follow the same guidelines with regards to TLS [6] usage 5129 as specified for HTTP, see [17]. RTSP over TLS is separated from 5130 unsecured RTSP both on URI level and port level. Instead of using the 5131 "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier 5132 MUST be used to signal RTSP over TLS. If no port is given in a URI 5133 with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP. 5135 When a client tries to setup an insecure channel to the server (using 5136 the "rtsp" URI), and the policy for the resource requires a secure 5137 channel, the server SHALL redirect the client to the secure service 5138 by sending a 301 redirect response code together with the correct 5139 Location URI (using the "rtsps" scheme). 5141 It should be noted that TLS allows for mutual authentication (when 5142 using both server and client certificates). Still, one of the more 5143 common way TLS is used is to only provide server side authentication 5144 (often to avoid client certificates). TLS is then used in addition to 5145 HTTP authentication, providing transport security and server 5146 authentication, while HTTP Authentication is used to authenticate the 5147 client. 5149 RTSP includes the possibility to keep a TCP session up between the 5150 client and server, throughout the RTSP session lifetime. It may be 5151 convenient to keep the TCP session, not only to save the extra setup 5152 time for TCP, but also the extra setup time for TLS (even if TLS uses 5153 the resume function, there will be almost two extra roundtrips). 5154 Still, when TLS is used, such behavior introduces extra active state 5155 in the server, not only for TCP and RTSP, but also for TLS. This may 5156 increase the vulnerability to DoS attacks. 5158 In addition to these recommendations, Section 18.3 gives further 5159 recommendations of TLS usage with proxies. 5161 18.3 Security and Proxies 5163 The nature of a proxy is often to act as a "man-in-the-middle", while 5164 security is often about preventing the existence of a "man-in-the- 5165 middle". This section provides the clients with the possibility to 5166 use proxies even when applying secure transports (TLS). The client 5167 needs to select between using the below specified procedure or using 5168 a TLS connection directly (by-passing any proxies) to the server. The 5169 choice may be dependent on policies. 5171 There are basically two categories of inspecting proxies, the 5172 transparent proxies (which the client is not aware of) and the non- 5173 transparent proxies (which the client is aware of). An infrastructure 5174 based on proxies requires that the trust model is such that both 5175 client and servers can trust the proxies to handle the RTSP messages 5176 correctly. To be able to trust a proxy, the client and server also 5177 needs to be aware of the proxy. Hence, transparent proxies cannot 5178 generally be seen as trusted and will not work well with security 5179 (unless they work only at transport layer). In the rest of this 5180 section any reference to proxy will be to a non-transparent proxy, 5181 which requires to inspect/manipulate the RTSP messages. 5183 The HTTP Authentication is built on the assumption of proxies and can 5184 provide user-proxy authentication and proxy-proxy/server 5185 authentication in addition to the client-server authentication. 5187 When TLS is applied and a proxy is used, the client will use the 5188 proxy's destination URI address when sending messages. This implies 5189 that for TLS, the client will authenticate the proxy server and not 5190 the end server. Note that, when the client checks the server 5191 certificate in TLS, it MUST check the proxy's identity (URI or 5192 possibly other known identity) against the proxy's identity as 5193 presented in the proxy's Certificate message. 5195 The problem is that for proxy accepted by the client, it needs to be 5196 provided information on which grounds it should accept the next-hop 5197 certificate. Both the proxy and the user may have rules for this, and 5198 the user have the possibility to select the desired behavior. To 5199 handle this case, the Accept-Credentials header (See Section 14.2) is 5200 used, where the client can force the proxy/proxies to relay back the 5201 certificates used by any intermediate proxies as well as the server. 5202 Given the assumption that the proxies are viewed as trusted, it gives 5203 the user a possibility to enforce policies to each trusted proxy of 5204 whether it should accept the next entity in the chain. 5206 A proxy MUST use TLS for the next hop if the RTSP request includes a 5207 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 5208 client and proxy, or between proxy and proxy), even if the resource 5209 and the end server does not require to use it. 5211 18.3.1 Accept-Credentials 5213 The Accept-Credentials header can be used by the client to distribute 5214 simple authorization policies to intermediate proxies. The client 5215 includes the Accept-Credentials header to dictate how the proxy 5216 treats the server/next proxy certificate. There are currently three 5217 methods defined: 5219 Any, which means that the proxy (or proxies) SHALL accept 5220 whatever certificate presented. This is of course not a 5221 recommended option to use, but may be useful in certain 5222 circumstances (such as testing). 5224 Proxy, which means that the proxy (or proxies) MUST use its own 5225 policies to validate the certificate and decide whether to 5226 accept it or not. This is convenient in cases where the 5227 user has a strong trust relation with the proxy. Reason why 5228 a strong trust relation may exist are; personal/company 5229 proxy, proxy has a out-of-band policy configuration 5230 mechanism. 5232 User, which means that the proxy (or proxies) MUST send 5233 credential information about the next hop to the client for 5234 authorization. The client can then decide whether the proxy 5235 should accept the certificate or not. See section 18.3.2 5236 for further details. 5238 If the Accept-Credentials header is not included in the RTSP request 5239 from the client, the default method used SHALL be "Proxy". If 5240 something else than the "Proxy" method is used, the Accept- 5241 Credentials header SHALL always be included in the RTSP request from 5242 the client. This is because it cannot be assumed that the proxy 5243 always keeps the TLS state or the users previously preference between 5244 different RTSP messages (in particular if the time interval between 5245 the messages is long). 5247 The "Any" and "Proxy" methods does not require the proxy to provide 5248 any specific response, but only apply the policy as defined for 5249 respectively method. If the policy do not accept the credentials of 5250 the next hop, the entity SHALL respond with a message using status 5251 code 471 (Connection Credentials not accepted). 5253 An RTSP request in the direction server to client MUST NOT include 5254 the Accept-Credential header. As for the non-secured communication, 5255 the possibility for these request depends on the presence of a client 5256 established connection. However if the server to client request is 5257 in relation to a session established over a TLS secured channel, if 5258 MUST be sent in a TLS secured connection. That secured connection 5259 MUST also be the one used by the last client to server request. If no 5260 such transport connection exist at the time when the server desire to 5261 send the request, it silently fails. 5263 Further policies MAY be defined and registered, but should be done so 5264 with caution. 5266 18.3.2 User approved TLS procedure 5268 For the "User" method each proxy MUST perform the the following 5269 procedure for each RTSP request: 5271 o Setup the TLS session to the next hop if not already present 5272 (i.e. run the TLS handshake, but do not send the RTSP 5273 request). 5275 o Extract the peer certificate for the TLS session. 5277 o Check if a matching identity and hash of the peer certificate 5278 is present in the Accept-Credentials header. If present, send 5279 the message to the next hop, and conclude these procedures. If 5280 not, go to the next step. 5282 o The proxy responds to the RTSP request with a 470 or 407 5283 response code. The 407 response code MAY be used when the 5284 proxy requires both user and connection authorization from 5285 user or client. In this message the proxy SHALL include a 5286 Connection-Credentials header, see section 14.12 with the next 5287 hop's identity and certificate. 5289 The client MUST upon receiving a 470 or 407 response with 5290 Connection-Credentials header take the decision on whether to accept 5291 the certificate or not (if it cannot do so, the user SHOULD be 5292 consulted). If the certificate is accepted, the client has to again 5293 send the RTSP request. In that request the client has to include the 5294 Accept-Credentials header including the hash over the DER encoded 5295 certificate for all trusted proxies in the chain. 5297 Example: 5298 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/1.1 5299 CSeq: 2 5300 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5301 "192.0.2.5:4589" 5303 P->C: RTSP/1.1 470 Connection Authorization Required 5304 CSeq: 2 5305 Connection-Credentials: "rtsps://test.example.org"; 5306 MIIDNTCCAp... 5308 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/1.1 5309 CSeq: 2 5310 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5311 "192.0.2.5:4589" 5312 Accept-Credentials: User "rtsps://test.example.org" ; 5313 dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ... 5315 One implication of this process is that the connection for secured 5316 RTSP messages may take significantly more round-trip times for the 5317 first message. An complete extra message exchange between the proxy 5318 connecting to the next hop and the client results because of the 5319 process for approval for each hop. However after the first message 5320 exchange the remaining message should not be delayed, if each message 5321 contains the chain of proxies that the requestor accepts. The 5322 procedure of including the credentials in each request rather than 5323 building state in each proxy, avoids the need for revocation 5324 procedures. 5326 19 Syntax 5328 The RTSP syntax is described in an augmented Backus-Naur Form (BNF) 5329 as defined in RFC 2234 [4]. It uses the basic definitions present in 5330 RFC 2234. 5332 19.1 Base Syntax 5334 RTSP header field values can be folded onto multiple lines if the 5335 continuation line begins with a space or horizontal tab. All linear 5336 white space, including folding, has the same semantics as SP. A 5337 recipient MAY replace any linear white space with a single SP before 5338 interpreting the field value or forwarding the message downstream. 5339 This is intended to behave exactly as HTTP/1.1 as described in RFC 5340 2616 [8]. The SWS construct is used when linear white space is 5341 optional, generally between tokens and separators. 5343 To separate the header name from the rest of value, a colon is used, 5344 which, by the above rule, allows whitespace before, but no line 5345 break, and whitespace after, including a linebreak. The HCOLON 5346 defines this construct. 5348 OCTET = %x00-FF ; any 8-bit sequence of data 5349 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 5350 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 5351 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 5352 ALPHA = UPALPHA / LOALPHA 5353 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 5354 CTL = %x00-1F / %x7F ; any US-ASCII control character 5355 ; (octets 0 - 31) and DEL (127) 5356 CR = %x0D ; US-ASCII CR, carriage return (13 5357 LF = %x0A ; US-ASCII LF, linefeed (10) 5358 SP = %x20 ; US-ASCII SP, space (32) 5359 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 5360 DQUOTE = %x22 ; US-ASCII double-quote mark (34) 5361 BACKSLASH = %x5C ; US-ASCII backslash (92) 5362 CRLF = CR LF 5364 LWS = [CRLF] 1*( SP / HT ) 5365 SWS = [LWS] ; sep whitespace 5366 HCOLON = *( SP / HTAB ) ":" SWS 5367 TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs 5368 tspecials = "(" / ")" / "<" / ">" / "@" 5369 / "," / ";" / ":" / BACKSLASH / DQUOTE 5370 / "/" / "[" / "]" / "?" / "=" 5371 / "{" / "}" / SP / HT 5372 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 5373 / %x41-5A / %x5E-7A / %x7C / %x7E) 5374 ; 1* 5375 quoted-string = ( DQUOTE *qdtext DQUOTE ) 5376 qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> 5377 quoted-pair = BACKSLASH CHAR 5378 ctext = %x20-27 / %x2A-7D 5379 / %x80-FF ; any OCTET except CTLs, "(" and ")" 5380 generic-param = token [ EQUAL gen-value ] 5381 gen-value = token / host / quoted-string 5383 safe = "$" / "-" / "_" / "." / "+" 5384 extra = "!" / "*" / "'" / "(" / ")" / "," 5385 rtsp-extra = "!" / "*" / "'" / "(" / ")" 5386 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 5387 / "a" / "b" / "c" / "d" / "e" / "f" 5388 LHEX = DIGIT / %x61-66 ;lowercase a-f 5389 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 5390 unreserved = ALPHA / DIGIT / safe / extra 5391 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 5392 base64 = *base64-unit [base64-pad] 5393 base64-unit = 4base64-char 5394 base64-pad = (2base64-char "==") / (3base64-char "=") 5395 base64-char = ALPHA / DIGIT / "+" / "/" 5397 SLASH = SWS "/" SWS ; slash 5398 EQUAL = SWS "=" SWS ; equal 5399 LPAREN = SWS "(" SWS ; left parenthesis 5400 RPAREN = SWS ")" SWS ; right parenthesis 5401 COMMA = SWS "," SWS ; comma 5402 SEMI = SWS ";" SWS ; semicolon 5403 COLON = SWS ":" SWS ; colon 5404 LDQUOT = SWS DQUOTE ; open double quotation mark 5405 RDQUOT = DQUOTE SWS ; close double quotation mark 5406 RAQUOT = ">" SWS ; right angle quote 5407 LAQUOT = SWS "<" ; left angle quote 5408 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 5409 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 5410 / %xE0-EF 2UTF8-CONT 5411 / %xF0-F7 3UTF8-CONT 5412 / %xF8-FB 4UTF8-CONT 5413 / %xFC-FD 5UTF8-CONT 5414 UTF8-CONT = %x80-BF 5416 19.2 RTSP Protocol Definition 5418 19.2.1 Generic Protocol elements 5420 URI-reference = RTSP-URI / relative-ref 5421 relative-ref = < As defined in RFC 3986 [10]> 5422 RTSP-URI = rtsp-uri-def / rtsps-uri-def / rtspu-uri-def 5423 rtsp-uri-def = "rtsp:" rtsp-uri-rest 5424 rtsps-uri-def = "rtsps:" rtsp-uri-rest 5425 rtspu-uri-def = "rtspu:" rtsp-uri-rest 5426 rtsp-uri-rest = "//" host [":" port] [abs-path-def] [frag-def] 5427 abs-path-def = abs-path ["?" query] 5428 frag-def = "#" fragment 5429 host = 5430 abs-path = 5431 port = *DIGIT ; Is expected to be 1*5DIGIT 5432 query = 5433 fragment = 5434 absolute-URI = 5435 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 5436 IPv6address = hexpart [ ":" IPv4address ] 5437 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 5438 hexseq = hex4 *( ":" hex4) 5439 hex4 = 1*4HEXDIG 5441 smpte-range = smpte-type "=" smpte-range-spec 5442 ;Section 3.4 5443 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 5444 / ( "-" smpte-time ) 5445 smpte-type = "smpte" / "smpte-30-drop" 5446 / "smpte-25" / smpte-type-extension 5447 ; other timecodes may be added 5448 smpte-type-extension = token 5449 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 5450 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 5452 npt-range = "npt=" npt-range-spec ; Section 3.5 5453 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 5454 npt-time = "now" / npt-sec / npt-hhmmss 5455 npt-sec = 1*DIGIT [ "." *DIGIT ] 5456 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 5457 npt-hh = 1*DIGIT ; any positive number 5458 npt-mm = 1*2DIGIT ; 0-59 5459 npt-ss = 1*2DIGIT ; 0-59 5461 utc-range = "clock=" utc-range-spec ; Section 3.6 5462 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 5463 utc-time = utc-date "T" utc-clock "Z" 5464 utc-date = 8DIGIT ; < YYYYMMDD > 5465 utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > 5466 fraction = 1*DIGIT 5468 feature-tag = token 5469 session-id = 8*( ALPHA / DIGIT / safe ) 5470 extension-header = header-name HCOLON header-value 5471 header-name = token 5472 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 5474 19.2.2 Message Syntax 5476 RTSP-message = Request / Response ; RTSP/1.1 messages 5477 Request = Request-Line ; Section 6.1 5478 *( general-header ; Section 5 5479 / request-header ; Section 6.2 5480 / entity-header ) ; Section 8.1 5481 CRLF 5482 [ message-body ] ; Section 4.3 5483 Response = Status-Line ; Section 7.1 5484 *( general-header ; Section 5 5485 / response-header ; Section 7.1.2 5486 / entity-header ) ; Section 8.1 5487 CRLF 5488 [ message-body ] ; Section 4.3 5490 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 5491 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 5492 Method = "DESCRIBE" ; Section 11.2 5493 / "GET_PARAMETER" ; Section 11.7 5494 / "OPTIONS" ; Section 11.1 5495 / "PAUSE" ; Section 11.5 5496 / "PLAY" ; Section 11.4 5497 / "REDIRECT" ; Section 11.9 5498 / "SETUP" ; Section 11.3 5499 / "SET_PARAMETER" ; Section 11.8 5500 / "TEARDOWN" ; Section 11.6 5501 / extension-method 5502 extension-method = token 5504 Request-URI = "*" / RTSP-URI 5505 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 5506 message-body = 1*OCTET 5508 Status-Code = "100" ; Continue 5509 / "200" ; OK 5510 / "201" ; Created 5511 / "250" ; Low on Storage Space 5512 / "300" ; Multiple Choices 5513 / "301" ; Moved Permanently 5514 / "302" ; Moved Temporarily 5515 / "303" ; See Other 5516 / "304" ; Not Modified 5517 / "305" ; Use Proxy 5518 / "400" ; Bad Request 5519 / "401" ; Unauthorized 5520 / "402" ; Payment Required 5521 / "403" ; Forbidden 5522 / "404" ; Not Found 5523 / "405" ; Method Not Allowed 5524 / "406" ; Not Acceptable 5525 / "407" ; Proxy Authentication Required 5526 / "408" ; Request Time-out 5527 / "410" ; Gone 5528 / "411" ; Length Required 5529 / "412" ; Precondition Failed 5530 / "413" ; Request Entity Too Large 5531 / "414" ; Request-URI Too Large 5532 / "415" ; Unsupported Media Type 5533 / "451" ; Parameter Not Understood 5534 / "452" ; reserved 5535 / "453" ; Not Enough Bandwidth 5536 / "454" ; Session Not Found 5537 / "455" ; Method Not Valid in This State 5538 / "456" ; Header Field Not Valid for Resource 5539 / "457" ; Invalid Range 5540 / "458" ; Parameter Is Read-Only 5541 / "459" ; Aggregate operation not allowed 5542 / "460" ; Only aggregate operation allowed 5543 / "461" ; Unsupported transport 5544 / "462" ; Destination unreachable 5545 / "463" ; Destination Prohibited 5546 / "470" ; Connection Authorization Required 5547 / "471" ; Connection Credentials not accepted 5548 / "500" ; Internal Server Error 5549 / "501" ; Not Implemented 5550 / "502" ; Bad Gateway 5551 / "503" ; Service Unavailable 5552 / "504" ; Gateway Time-out 5553 / "505" ; RTSP Version not supported 5554 / "551" ; Option not supported 5555 / extension-code 5556 extension-code = 3DIGIT 5557 Reason-Phrase = *TEXT 5559 general-header = Cache-Control ; Section 14.10 5560 / Connection ; Section 14.11 5561 / CSeq ; Section 14.19 5562 / Date ; Section 14.20 5563 / Proxy-Supported ; Section 14.32 5564 / Supported ; Section 14.43 5565 / Timestamp ; Section 14.44 5566 / Via ; Section 14.49 5567 / extension-header 5569 request-header = Accept ; Section 14.1 and [H14.1] 5570 / Accept-Credentials ; Section 14.2 5571 / Accept-Encoding ; Section 14.3 and [H14.3] 5572 / Accept-Language ; Section 14.4 and [H14.4] 5573 / Authorization ; Section 14.7 and [H14.8] 5574 / Bandwidth ; Section 14.8 5575 / Blocksize ; Section 14.9 5576 / From ; Section 14.23 5577 / If-Match ; Section 14.25 5578 / If-Modified-Since ; Section 14.26 and [H14.25] 5579 / If-None-Match ; Section 14.27 5580 / Proxy-Require ; Section 14.31 5581 / Range ; Section 14.34 5582 / Referer ; Section 14.35 5583 / Require ; Section 14.37 5584 / Scale ; Section 14.39 5585 / Session ; Section 14.42 5586 / Speed ; Section 14.40 5587 / Supported ; Section 14.43 5588 / Transport ; Section 14.45 5589 / User-Agent ; Section 14.47 5590 / extension-header 5592 response-header = Accept-Credentials ; Section 14.2 5593 / Accept-Ranges ; Section 14.5 5594 / Connection-Creds ; Section 14.12 5595 / ETag ; Section 14.21 5596 / Location ; Section 14.29 5597 / Proxy-Authenticate ; Section 14.30 5598 / Public ; Section 14.33 5599 / Range ; Section 14.34 5600 / Retry-After ; Section 14.36 5601 / RTP-Info ; Section 14.38 5602 / Scale ; Section 14.39 5603 / Session ; Section 14.42 5604 / Server ; Section 14.41 5605 / Speed ; Section 14.40 5606 / Transport ; Section 14.45 5607 / Unsupported ; Section 14.46 5608 / Vary ; Section 14.48 5609 / WWW-Authenticate ; Section 14.50 5610 / extension-header 5612 entity-header = Allow ; Section 14.6 5613 / Content-Base ; Section 14.13 5614 / Content-Encoding ; Section 14.14 5615 / Content-Language ; Section 14.15 5616 / Content-Length ; Section 14.16 5617 / Content-Location ; Section 14.17 5618 / Content-Type ; Section 14.18 5619 / Expires ; Section 14.22 and [H14.21] 5620 / Last-Modified ; Section 14.28 5621 / extension-header 5623 19.2.3 Header Syntax 5625 All header syntaxes not defined in this section are defined in 5626 section 14 of the HTTP 1.1 specification [3]. 5628 Accept = "Accept" HCOLON 5629 [ accept-range *(COMMA accept-range) ] 5630 accept-range = media-range *(SEMI accept-param) 5631 media-range = ( "*/*" 5632 / ( m-type SLASH "*" ) 5633 / ( m-type SLASH m-subtype ) 5634 ) *( SEMI m-parameter ) 5635 accept-param = ("q" EQUAL qvalue) / generic-param 5636 qvalue = ( "0" [ "." *3DIGIT ] ) 5637 / ( "1" [ "." *3("0") ] ) 5638 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF 5639 cred-decision = ("User" COMMA [cred-info]) 5640 / "Proxy" 5641 / "Any" 5642 / token ; For future extensions 5643 cred-info = cred-info-data *(COMMA cred-info-data) 5644 cred-info-data = DQUOTE RTSP-URI DQUOTE SEMI base64 5645 Accept-Encoding = "Accept-Encoding" HCOLON 5646 [ encoding *(COMMA encoding) ] 5647 encoding = codings *(SEMI accept-param) 5648 codings = content-coding / "*" 5649 content-coding = token 5650 Accept-Language = "Accept-Language" HCOLON 5651 [ language *(COMMA language) ] 5652 language = language-range *(SEMI accept-param) 5653 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) 5654 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF 5655 acceptable-ranges = (range-unit *(COMMA range-unit)) 5656 / "none" 5657 range-unit = "NPT" / "SMPTE" / "UTC" / extension-format 5658 extension-format = token 5659 Allow = "Allow" HCOLON [Method *(COMMA Method)] 5660 Authorization = "Authorization" HCOLON credentials 5661 credentials = ("Digest" LWS digest-response) 5662 / other-response 5663 digest-response = dig-resp *(COMMA dig-resp) 5664 dig-resp = username / realm / nonce / digest-uri 5665 / dresponse / algorithm / cnonce 5666 / opaque / message-qop 5667 / nonce-count / auth-param 5668 username = "username" EQUAL username-value 5669 username-value = quoted-string 5670 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 5671 digest-uri-value = Request-URI 5672 ; by HTTP/1.1 5673 message-qop = "qop" EQUAL qop-value 5674 cnonce = "cnonce" EQUAL cnonce-value 5675 cnonce-value = nonce-value 5676 nonce-count = "nc" EQUAL nc-value 5677 nc-value = 8LHEX 5678 dresponse = "response" EQUAL request-digest 5679 request-digest = LDQUOT 32LHEX RDQUOT 5680 auth-param = auth-param-name EQUAL 5681 ( token / quoted-string ) 5682 auth-param-name = token 5683 other-response = auth-scheme LWS auth-param 5684 *(COMMA auth-param) 5685 auth-scheme = token 5686 Bandwidth = "Bandwidth" HCOLON 1*DIGIT CRLF 5687 Blocksize = "Blocksize" HCOLON 1*DIGIT CRLF 5689 Cache-Control = "Cache-Control" HCOLON cache-directive CRLF 5690 *(COMMA cache-directive) 5691 cache-directive = cache-rqst-directive 5692 / cache-rspns-directive 5693 cache-rqst-directive = "no-cache" 5694 / "max-stale" [EQUAL delta-seconds] 5695 / "min-fresh" EQUAL delta-seconds 5696 / "only-if-cached" 5697 / cache-extension 5698 cache-rspns-directive = "public" 5699 / "private" 5700 / "no-cache" 5701 / "no-transform" 5702 / "must-revalidate" 5703 / "proxy-revalidate" 5704 / "max-age" EQUAL delta-seconds 5705 / cache-extension 5706 cache-extension = token [EQUAL (token / quoted-string)] 5707 delta-seconds = 1*DIGIT 5709 Connection-Creds = "Connection-Credentials" HCOLON cred-info CRLF 5710 Connection = "Connection" HCOLON (connection-token) 5711 *(COMMA connection-token) CRLF 5712 connection-token = token 5713 Content-Base = "Content-Base" HCOLON URI-reference CRLF 5714 Content-Encoding = "Content-Encoding" HCOLON 5715 content-coding *(COMMA content-coding) 5716 Content-Language = "Content-Language" HCOLON 5717 language-tag *(COMMA language-tag) 5718 language-tag = primary-tag *( "-" subtag ) 5719 primary-tag = 1*8ALPHA 5720 subtag = 1*8ALPHA 5721 Content-Length = "Content-Length" HCOLON 1*DIGIT 5722 Content-Location = "Content-Location" HCOLON URI-reference 5723 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type 5724 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 5725 m-type = discrete-type / composite-type 5726 discrete-type = "text" / "image" / "audio" / "video" 5727 / "application" / extension-token 5728 composite-type = "message" / "multipart" / extension-token 5729 extension-token = ietf-token / x-token 5730 ietf-token = token 5731 x-token = "x-" token 5732 m-subtype = extension-token / iana-token 5733 iana-token = token 5734 m-parameter = m-attribute EQUAL m-value 5735 m-attribute = token 5736 m-value = token / quoted-string 5737 CSeq = "Cseq" HCOLON 1*DIGIT CRLF 5738 Date = "Date" HCOLON RTSP-date 5739 RTSP-date = rfc1123-date ; HTTP-date 5740 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 5741 date1 = 2DIGIT SP month SP 4DIGIT 5742 ; day month year (e.g., 02 Jun 1982) 5743 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 5744 ; 00:00:00 - 23:59:59 5745 wkday = "Mon" / "Tue" / "Wed" 5746 / "Thu" / "Fri" / "Sat" / "Sun" 5747 month = "Jan" / "Feb" / "Mar" / "Apr" 5748 / "May" / "Jun" / "Jul" / "Aug" 5749 / "Sep" / "Oct" / "Nov" / "Dec" 5750 ETag = "ETag" HCOLON entity-tag 5751 Expires = "Expires" HCOLON delta-seconds 5752 From = "From" HCOLON from-spec 5753 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 5754 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 5755 addr-spec = RTSP-URI / absolute-URI 5756 display-name = *(token LWS)/ quoted-string 5757 from-param = tag-param / generic-param 5758 tag-param = "tag" EQUAL token 5759 If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) 5760 entity-tag-list = entity-tag *(COMMA entity-tag) 5761 entity-tag = [ weak ] opaque-tag 5762 weak = "W/" 5763 opaque-tag = quoted-string 5764 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 5765 If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) 5766 Last-Modified = "Last-Modified" HCOLON RTSP-date 5767 Location = "Location" HCOLON RTSP-URI 5768 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge 5769 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 5770 / other-challenge 5771 other-challenge = auth-scheme LWS auth-param 5772 *(COMMA auth-param) 5773 digest-cln = realm / domain / nonce 5774 / opaque / stale / algorithm 5775 / qop-options / auth-param 5776 realm = "realm" EQUAL realm-value 5777 realm-value = quoted-string 5778 domain = "domain" EQUAL LDQUOT URI 5779 *( 1*SP URI ) RDQUOT 5780 URI = RTSP-URI / abs-path 5781 nonce = "nonce" EQUAL nonce-value 5782 nonce-value = quoted-string 5783 opaque = "opaque" EQUAL quoted-string 5784 stale = "stale" EQUAL ( "true" / "false" ) 5785 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 5786 qop-options = "qop" EQUAL LDQUOT qop-value 5787 *("," qop-value) RDQUOT 5788 qop-value = "auth" / "auth-int" / token 5789 Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF 5790 *(COMMA feature-tag) 5791 Proxy-Supported = "Proxy-Supported" HCOLON feature-tag 5792 *(COMMA feature-tag) CRLF 5793 Public = "Public" HCOLON Method *(COMMA Method) CRLF 5794 Range = "Range" HCOLON ranges-list [exec-time] CRLF 5795 ranges-list = ranges-spec *(COMMA ranges-spec) 5796 exec-time = SEMI "time" EQUAL utc-time 5797 ranges-spec = npt-range / utc-range / smpte-range 5798 Referer = "Referer" HCOLON URI-reference 5799 Require = "Require" HCOLON feature-tag-list CRLF 5800 feature-tag-list = feature-tag *(COMMA feature-tag) 5802 RTP-Info = "RTP-Info" HCOLON rtsp-info-spec 5803 *(COMMA rtsp-info-spec) CRLF 5804 rtsp-info-spec = stream-url 1*ssrc-parameter 5805 stream-url = "url" EQUAL DQUOTE URI-reference DQUOTE 5806 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 5807 ri-parameter *(SEMI ri-parameter) 5809 ri-parameter = "seq" EQUAL 1*DIGIT 5810 / "rtptime" EQUAL 1*DIGIT 5811 Retry-After = "Retry-After" HCOLON delta-seconds 5812 [ comment ] *( SEMI retry-param ) 5813 retry-param = ("duration" EQUAL delta-seconds) 5814 / generic-param 5816 Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF 5817 Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] CRLF 5818 Server = "Server" HCOLON ( product / comment ) 5819 *(LWS (product / comment)) CRLF 5820 product = token [SLASH product-version] 5821 product-version = token 5822 comment = LPAREN *( ctext / quoted-pair) RPAREN 5823 Session = "Session" HCOLON session-id 5824 [ SEMI "timeout" EQUAL delta-seconds ] CRLF 5825 Supported = "Supported" HCOLON [feature-tag-list] CRLF 5827 Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] 5828 timestamp-value = *DIGIT [ "." *DIGIT ] 5829 delay = *DIGIT [ "." *DIGIT ] 5830 Transport = "Transport" HCOLON transport-spec 5831 *(COMMA transport-spec) CRLF 5832 transport-spec = transport-id *tr-parameter 5833 transport-id = trans-id-rtp / other-trans 5834 trans-id-rtp = "RTP/" profile ["/" lower-transport] 5835 ; no LWS is allowed inside transport-id 5836 other-trans = token *("/" token) 5838 profile = "AVP" / "SAVP" / "AVPF" / token 5839 lower-transport = "TCP" / "UDP" / token 5840 tr-parameter = SEMI ( "unicast" / "multicast" ) 5841 / SEMI "interleaved" EQUAL channel [ "-" channel ] 5842 / SEMI "append" 5843 / SEMI "ttl" EQUAL ttl 5844 / SEMI "layers" EQUAL 1*DIGIT 5845 / SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) 5846 / SEMI "client_ssrc" EQUAL ssrc 5847 / SEMI "mode" EQUAL mode-spec 5848 / SEMI "dest_addr" EQUAL addr-list 5849 / SEMI "src_addr" EQUAL addr-list 5850 / SEMI trn-param-ext 5852 trn-param-ext = par-name EQUAL trn-par-value 5853 par-name = token 5854 trn-par-value = *(rtsp-unreserved / DQUOTE *TEXT DQUOTE) 5855 ttl = 1*3DIGIT ; 0 to 255 5856 ssrc = 8HEX 5857 channel = 1*3DIGIT 5858 mode-spec = mode / ( DQUOTE mode *(COMMA mode) DQUOTE ) 5859 mode = "PLAY" / "RECORD" / token 5860 addr-list = quoted-addr *(SLASH quoted-addr) 5861 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 5862 host-port = host [":" port] 5863 / ":" port 5864 extension-addr = 1*qdtext 5866 Unsupported = "Unsupported" HCOLON feature-tag-list CRLF 5867 User-Agent = "User-Agent" HCOLON ( product / comment ) 5868 0*(LWS (product / comment)) CRLF 5869 Vary = "Vary" HCOLON ( "*" / field-name-list) 5870 field-name-list = field-name *(COMMA field-name) 5871 field-name = token 5872 Via = "Via" HCOLON via-parm *(COMMA via-parm) 5873 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 5874 via-params = via-ttl / via-maddr 5875 / via-received / via-branch 5876 / via-extension 5877 via-ttl = "ttl" EQUAL ttl 5878 via-maddr = "maddr" EQUAL host 5879 via-received = "received" EQUAL (IPv4address / IPv6address) 5880 via-branch = "branch" EQUAL token 5881 via-extension = generic-param 5882 sent-protocol = protocol-name SLASH protocol-version 5883 SLASH transport-prot 5884 protocol-name = "RTSP" / token 5885 protocol-version = token 5886 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 5887 other-transport = token 5888 sent-by = host [ COLON port ] 5889 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge 5891 19.3 SDP extension Syntax 5893 This section defines in ABNF the SDP extensions defined for RTSP. 5894 See section C for the definition of the extensions in text. 5896 control-attribute = "a=control:" *SP RTSP-URI 5897 a-range-def = "a=range:" ranges-spec CRLF 5898 a-etag-def = "a=etag:" etag-string CRLF 5899 etag-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 5901 20 Security Considerations 5903 Because of the similarity in syntax and usage between RTSP servers 5904 and HTTP servers, the security considerations outlined in [H15] 5905 apply. Specifically, please note the following: 5907 Abuse of Server Log Information: RTSP and HTTP servers will 5908 presumably have similar logging mechanisms, and thus should 5909 be equally guarded in protecting the contents of those 5910 logs, thus protecting the privacy of the users of the 5911 servers. See [H15.1.1] for HTTP server recommendations 5912 regarding server logs. 5914 Transfer of Sensitive Information: There is no reason to believe 5915 that information transferred via RTSP may be any less 5916 sensitive than that normally transmitted via HTTP. 5917 Therefore, all of the precautions regarding the protection 5918 of data privacy and user privacy apply to implementors of 5919 RTSP clients, servers, and proxies. See [H15.1.2] for 5920 further details. 5922 Attacks Based On File and Path Names: Though RTSP URIs are 5923 opaque handles that do not necessarily have file system 5924 semantics, it is anticipated that many implementations will 5925 translate portions of the Request-URIs directly to file 5926 system calls. In such cases, file systems SHOULD follow the 5927 precautions outlined in [H15.5], such as checking for ".." 5928 in path components. 5930 Personal Information: RTSP clients are often privy to the same 5931 information that HTTP clients are (user name, location, 5932 etc.) and thus should be equally sensitive. See [H15.1] 5933 for further recommendations. 5935 Privacy Issues Connected to Accept Headers: Since may of the 5936 same "Accept" headers exist in RTSP as in HTTP, the same 5937 caveats outlined in [H15.1.4] with regards to their use 5938 should be followed. 5940 DNS Spoofing: Presumably, given the longer connection times 5941 typically associated to RTSP sessions relative to HTTP 5942 sessions, RTSP client DNS optimizations should be less 5943 prevalent. Nonetheless, the recommendations provided in 5944 [H15.3] are still relevant to any implementation which 5945 attempts to rely on a DNS-to-IP mapping to hold beyond a 5946 single use of the mapping. 5948 Location Headers and Spoofing: If a single server supports 5949 multiple organizations that do not trust each another, then 5950 it needs to check the values of Location and Content- 5951 Location header fields in responses that are generated 5952 under control of said organizations to make sure that they 5953 do not attempt to invalidate resources over which they have 5954 no authority. ([H15.4]) 5956 In addition to the recommendations in the current HTTP specification 5957 (RFC 2616 [3], as of this writing) and also of the previous RFC2068 5958 [18], future HTTP specifications may provide additional guidance on 5959 security issues. 5961 The following are added considerations for RTSP implementations. 5963 Concentrated denial-of-service attack: The protocol offers the 5964 opportunity for a remote-controlled denial-of-service 5965 attack. See Section . 5967 Session hijacking: Since there is no or little relation between 5968 a transport layer connection and an RTSP session, it is 5969 possible for a malicious client to issue requests with 5970 random session identifiers which would affect unsuspecting 5971 clients. The server SHOULD use a large, random and non- 5972 sequential session identifier to minimize the possibility 5973 of this kind of attack. For real session security, client 5974 authentication needs to be performed. 5976 Authentication: Servers SHOULD implement both basic and digest 5977 [7] authentication. In environments requiring tighter 5978 security for the control messages, the transport layer 5979 mechanism TLS (RFC 2246 [6]) SHOULD be used. 5981 Stream issues: RTSP only provides for stream control. Stream 5982 delivery issues are not covered in this section, nor in the 5983 rest of this draft. RTSP implementations will most likely 5984 rely on other protocols such as RTP, IP multicast, RSVP and 5985 IGMP, and should address security considerations brought up 5986 in those and other applicable specifications. 5988 Persistently suspicious behavior: RTSP servers SHOULD return 5989 error code 403 (Forbidden) upon receiving a single instance 5990 of behavior which is deemed a security risk. RTSP servers 5991 SHOULD also be aware of attempts to probe the server for 5992 weaknesses and entry points and MAY arbitrarily disconnect 5993 and ignore further requests clients which are deemed to be 5994 in violation of local security policy. 5996 20.1 Remote denial of Service Attack 5998 The attacker may initiate traffic flows to one or more IP addresses 5999 by specifying them as the destination in SETUP requests. While the 6000 attacker's IP address may be known in this case, this is not always 6001 useful in prevention of more attacks or ascertaining the attackers 6002 identity. Thus, an RTSP server MUST only allow client-specified 6003 destinations for RTSP-initiated traffic flows if the server has 6004 ensured that the specified destination address accepts receiving 6005 media through different security mechanisms. Security mechanism that 6006 are acceptable in an increased generality are; verification of the 6007 client's identity, either against a database of known users using 6008 RTSP authentication mechanisms (preferably digest authentication or 6009 stronger); a list of addresses that accept to be media destinations, 6010 especially considering user identity; and media path based 6011 verification. 6013 The server SHOULD NOT allow the destination field to be set unless a 6014 mechanism exists in the system to authorize the request originator to 6015 direct streams to the recipient. It is preferred that this 6016 authorization be performed by the recipient itself and the 6017 credentials passed along to the server. However, in certain cases, 6018 such as when recipient address is a multicast group, or when the 6019 recipient is unable to communicate with the server in an out-of-band 6020 manner, this may not be possible. In these cases server may chose 6021 another method such as a server-resident authorization list to ensure 6022 that the request originator has the proper credentials to request 6023 stream delivery to the recipient. 6025 21 IANA Considerations 6027 This section set up a number of registers for RTSP 1.1 that should be 6028 maintained by IANA. For each registry there is a description on what 6029 it is required to contain, what specification is needed when adding a 6030 entry with IANA, and finally the entries that this document needs to 6031 register. See also the section 1.6 "Extending RTSP". There is also an 6032 IANA registration of two SDP attributes. 6034 The sections describing how to register an item uses some of the 6035 requirements level described in RFC 2434 [19], namely "First Come, 6036 First Served", "Specification Required", and "Standards Action". 6038 A registration request to IANA MUST contain the following 6039 information: 6041 o A name of the item to register according to the rules 6042 specified by the intended registry. 6044 o Indication of who has change control over the feature (for 6045 example, IETF, ISO, ITU-T, other international standardization 6046 bodies, a consortium, a particular company or group of 6047 companies, or an individual); 6049 o A reference to a further description, if available, for 6050 example (in order of preference) an RFC, a published standard, 6051 a published paper, a patent filing, a technical report, 6052 documented source code or a computer manual; 6054 o For proprietary features, contact information (postal and 6055 email address); 6057 21.1 Feature-tags 6059 21.1.1 Description 6061 When a client and server try to determine what part and functionality 6062 of the RTSP specification and any future extensions that its counter 6063 part implements there is need for a namespace. This registry 6064 contains named entries representing certain functionality. 6066 The usage of feature-tags is explained in section 10 and 11.1. 6068 21.1.2 Registering New Feature-tags with IANA 6070 The registering of feature-tags is done on a first come, first served 6071 basis. 6073 The name of the feature MUST follow these rules: The name may be of 6074 any length, but SHOULD be no more than twenty characters long. The 6075 name MUST NOT contain any spaces, or control characters. The 6076 registration SHALL indicate if the feature tag applies to clients, 6077 servers, or proxies only or any combinations of these. Any 6078 proprietary feature SHALL have as the first part of the name a vendor 6079 tag, which identifies the organization. 6081 21.1.3 Registered entries 6083 The following feature-tags are in this specification defined and 6084 hereby registered. The change control belongs to the Authors and the 6085 IETF MMUSIC WG. 6087 play.basic: The minimal implementation for playback operations 6088 according to section D. Applies for both clients, servers 6089 and proxies. 6091 play.scale: Support of scale operations for media playback. 6092 Applies only for servers. 6094 play.speed: Support of the speed functionality for playback. 6095 Applies only for servers 6097 21.2 RTSP Methods 6099 21.2.1 Description 6101 What a method is, is described in section 11. Extending the protocol 6102 with new methods allow for totally new functionality. 6104 21.2.2 Registering New Methods with IANA 6106 A new method MUST be registered through an IETF standard track 6107 document. The reason is that new methods may radically change the 6108 protocols behavior and purpose. 6110 A specification for a new RTSP method MUST consist of the following 6111 items: 6113 o A method name which follows the ABNF rules for methods. 6115 o A clear specification on what action and response a request 6116 with the method will result in. Which directions the method is 6117 used, C -> S or S -> C or both. How the use of headers, if 6118 any, modifies the behavior and effect of the method. 6120 o A list or table specifying which of the registered headers 6121 that are allowed to use with the method in request or/and 6122 response. 6124 o Describe how the method relates to network proxies. 6126 21.2.3 Registered Entries 6128 This specification, RFCXXXX, registers 9 methods: DESCRIBE, 6129 GET_PARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SET_PARAMETER, 6130 and TEARDOWN. 6132 21.3 RTSP Status Codes 6134 21.3.1 Description 6135 A status code is the three digit numbers used to convey information 6136 in RTSP response messages, see 7. The number space is limited and 6137 care should be taken not to fill the space. 6139 21.3.2 Registering New Status Codes with IANA 6141 A new status code can only be registered by an IETF standards track 6142 document. A specification for a new status code MUST specify the 6143 following: 6145 o The requested number. 6147 o A description what the status code means and the expected 6148 behavior of the sender and receiver of the code. 6150 21.3.3 Registered Entries 6152 RFCXXX, registers the numbered status code defined in the ABNF entry 6153 "Status-Code" except "extension-code" in section 19.2.2. 6155 21.4 RTSP Headers 6157 21.4.1 Description 6159 By specifying new headers a method(s) can be enhanced in many 6160 different ways. An unknown header will be ignored by the receiving 6161 entity. If the new header is vital for a certain functionality, a 6162 feature-tag for the functionality can be created and demanded to be 6163 used by the counter-part with the inclusion of a Require header 6164 carrying the feature-tag. 6166 21.4.2 Registering New Headers with IANA 6168 A public available specification is required to register a header. 6169 The specification SHOULD be a standards document, preferable an IETF 6170 RFC. 6172 The specification MUST contain the following information: 6174 o The name of the header. 6176 o An ABNF specification of the header syntax. 6178 o A list or table specifying when the header may be used, 6179 encompassing all methods, their request or response, the 6180 direction (C -> S or S -> C). 6182 o How the header is to be handled by proxies. 6184 o A description of the purpose of the header. 6186 21.4.3 Registered entries 6188 All headers specified in section 14 in RFCXXXX are to be registered. 6190 Furthermore the following RTSP headers defined in other 6191 specifications are registered: 6193 o x-wap-profile defined in [36]. 6195 o x-wap-profile-diff defined in [36]. 6197 o x-wap-profile-warning defined in [36]. 6199 o x-predecbufsize defined in [36]. 6201 o x-initpredecbufperiod defined in [36]. 6203 o x-initpostdecbufperiod defined in [36]. 6205 o 3gpp-videopostdecbufsize defined in [36]. 6207 o 3GPP-Link-Char defined in [36]. 6209 o 3GPP-Adaptation defined in [36]. 6211 o 3GPP-QoE-Metrics defined in [36]. 6213 o 3GPP-QoE-Feedback defined in [36]. 6215 The use of "X-" is NOT RECOMMENDED but the above headers in the 6216 register list was defined prior to the clarification. 6218 21.5 Transport Header registries 6220 The transport header contains a number of parameters which have 6221 possibilities for future extensions. Therefore registries for these 6222 needs to be defined. 6224 21.5.1 Transport Protocols 6226 A registry for the parameter transport-protocol SHALL be defined with 6227 the following rules: 6229 o Registering require an public available standards 6230 specification. 6232 o A contact person or organization with address and email. 6234 o A value definition that are following the ABNF token 6235 definition. 6237 o A describing text that explains how the registered value are 6238 used in RTSP. 6240 This specification registers 1 value: 6242 o Use of the RTP [16] protocol for media transport. The usage 6243 is explained in RFC XXXX, appendix B.1. 6245 21.5.2 Profile 6247 A registry for the parameter profile SHALL be defined with the 6248 following rules: 6250 o Registering requires public available standards specification. 6252 o A contact person or organization with address and email. 6254 o A value definition that are following the BNF token 6255 definition. 6257 o A definition of which Transport protocol(s) that this profile 6258 is valid for. 6260 o A describing text that explains how the registered value are 6261 used in RTSP. 6263 This specification registers 3 value: 6265 o The "RTP profile for audio and video conferences with minimal 6266 control" [2] MUST only be used when the transport 6267 specification's transport-protocol is "RTP". 6269 o The "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" 6270 [20] MUST only be used when the transport specification's 6271 transport-protocol is "RTP" 6273 o The "The Secure Real-time Transport Protocol (SRTP)" [21] MUST 6274 only be used when the transport specification's transport- 6275 protocol is "RTP". 6277 21.5.3 Lower Transport 6279 A registry for the parameter lower-transport SHALL be defined with 6280 the following rules: 6282 o Registering requires public available standards specification. 6284 o A contact person or organization with address and email. 6286 o A value definition that are following the BNF token 6287 definition. 6289 o A text describing how the registered value are used in RTSP. 6291 This specification registers 2 values: 6293 UDP: Indicates the use of the "User datagram protocol" [8] for 6294 media transport. 6296 TCP: Indicates the use Transmission control protocol [9] for 6297 media transport. 6299 21.5.4 Transport modes 6301 A registry for the transport parameter mode SHALL be defined with the 6302 following rules: 6304 o Registering requires an IETF standard tracks document. 6306 o A contact person or organization with address and email. 6308 o A value definition that are following the ABNF token 6309 definition. 6311 o A describing text that explains how the registered value are 6312 used in RTSP. 6314 This specification registers 1 values: 6316 PLAY: See RFC XXXX. 6318 21.5.5 Transport Parameters 6320 A registry for parameters that may be included in the Transport 6321 header SHALL be defined with the following rules: 6323 o Registering required a Open Standards document 6325 o A value definition that are following the ABNF token 6326 definition. 6328 o A describing text that explains how the registered value are 6329 used in RTSP. 6331 This specification registers all the transport parameters defined in 6332 Section 14.45. 6334 21.6 Cache Directive Extensions 6336 There exist a number of cache directives which can be sent in the 6337 Cache-Control header. A registry for this cache directives SHALL be 6338 defined with the following rules: 6340 o Registering requires an IETF standard tracks document. 6342 o A registration is required to contain a contact person. 6344 o Name of the directive and a definition of the value, if any. 6346 o Specification if it is an request or response directive. 6348 o A describing text that explains how the cache directive is 6349 used for RTSP controlled media streams. 6351 This specification registers the following values: 6353 no-cache: 6355 public: 6357 private: 6359 no-transform: 6361 only-if-cached: 6363 max-stale: 6365 min-fresh: 6367 must-revalidate: 6369 proxy-revalidate: 6371 max-age: 6373 21.7 Accept-Credentials policies 6375 In section 18.3.1 three policies for how to handle certificates. 6377 Further policies may be defined and SHALL be registered with IANA 6378 using the following rules: 6380 o Registering requires an IETF standard tracks document. 6382 o A registration is required name a contact person. 6384 o Name of the policy. 6386 o A describing text that explains how the policy works for 6387 handling the certificates. 6389 This specification registers the following values: 6391 Any 6393 Proxy 6395 User 6397 21.8 URI Schemes 6399 This specification defines two URI schemes ("rtsp" and "rtsps") and 6400 reserves a third one ("rtspu"). 6402 This will need to be done in accordance with RFC 2717. 6404 21.9 SDP attributes 6406 This specification defines two SDP [1] attributes that it is 6407 requested that IANA register. 6409 SDP Attribute ("att-field"): 6411 Attribute name: range 6412 Long form: Media Range Attribute 6413 Type of name: att-field 6414 Type of attribute: Media and session level 6415 Subject to charset: No 6416 Purpose: RFC XXXX 6417 Reference: RFC XXXX 6418 Values: See ABNF definition. 6420 Attribute name: control 6421 Long form: RTSP control URI 6422 Type of name: att-field 6423 Type of attribute: Media and session level 6424 Subject to charset: No 6425 Purpose: RFC XXXX 6426 Reference: RFC XXXX 6427 Values: Absolute or Relative URIs. 6429 Attribute name: etag 6430 Long form: Entity Tag 6431 Type of name: att-field 6432 Type of attribute: Media and session level 6433 Subject to charset: No 6434 Purpose: RFC XXXX 6435 Reference: RFC XXXX 6436 Values: See ABNF definition 6438 A RTSP Protocol State Machine 6440 The RTSP session state machine describes the behavior of the protocol 6441 from RTSP session initialization through RTSP session termination. 6443 The State machine is defined on a per session basis which is uniquely 6444 identified by the RTSP session identifier. The session may contain 6445 one or more media streams depending on state. If a single media 6446 stream is part of the session it is in non-aggregated control. If two 6447 or more is part of the session it is in aggregated control. 6449 The below state machine is a normative description of the protocols 6450 behavior. However, in case of ambiguity with the earlier parts of 6451 this specification, the description in the earlier parts SHALL take 6452 precedence. 6454 A.1 States 6456 The state machine contains three states, described below. For each 6457 state there exist a table which shows which requests and events that 6458 is allowed and if they will result in a state change. 6460 Init: Initial state no session exist. 6462 Ready: Session is ready to start playing. 6464 Play: Session is playing, i.e. sending media stream data in the 6465 direction S -> C. 6467 A.2 State variables 6469 This representation of the state machine needs more than its state to 6470 work. A small number of variables are also needed and is explained 6471 below. 6473 NRM: The number of media streams part of this session. 6475 RP: Resume point, the point in the presentation time line at 6476 which a request to continue will resume from. A time format 6477 for the variable is not mandated. 6479 A.3 Abbreviations 6481 To make the state tables more compact a number of abbreviations are 6482 used, which are explained below. 6484 IFI: IF Implemented. 6486 md: Media 6488 PP: Pause Point, the point in the presentation time line at 6489 which the presentation was paused. 6491 Prs: Presentation, the complete multimedia presentation. 6493 RedP: Redirect Point, the point in the presentation time line at 6494 which a REDIRECT was specified to occur. 6496 SES: Session. 6498 A.4 State Tables 6500 This section contains a table for each state. The table contains all 6501 the requests and events that this state is allowed to act on. The 6502 events which is method names are, unless noted, requests with the 6503 given method in the direction client to server (C -> S). In some 6504 cases there exist one or more requisite. The response column tells 6505 what type of response actions should be performed. Possible actions 6506 that is requested for an event includes: response codes, e.g. 200, 6507 headers that MUST be included in the response, setting of state 6508 variables, or setting of other session related parameters. The new 6509 state column tells which state the state machine changes to. 6511 The response to valid request meeting the requisites is normally a 6512 2xx (SUCCESS) unless other noted in the response column. The 6513 exceptions needs to be given a response according to the response 6514 column. If the request does not meet the requisite, is erroneous or 6515 some other type of error occur the appropriate response code MUST be 6516 sent. If the response code is a 4xx the session state is unchanged. A 6517 response code of 3rr will result in that the session is ended and its 6518 state is changed to Init. A response code of 304 results in no state 6519 change. However there exist restrictions to when a 3xx response may 6520 be used. A 5xx response SHALL not result in any change of the session 6521 state, except if the error is not possible to recover from. A 6522 unrecoverable error SHALL result the ending of the session. As it in 6523 the general case can't be determined if it was a unrecoverable error 6524 or not the client will be required to test. In the case that the next 6525 request after a 5xx is responded with 454 (Session Not Found) the 6526 client knows that the session has ended. 6528 The server will timeout the session after the period of time 6529 specified in the SETUP response, if no activity from the client is 6530 detected. Therefore there exist a timeout event for all states 6531 except Init. 6533 In the case that NRM=1 the presentation URI is equal to the media 6534 URI. For NRM>1 the presentation URI MUST be other than any of the 6535 medias that are part of the session. This applies to all states. 6537 Event Prerequisite Response 6538 ______________________________________________________________ 6539 DESCRIBE Needs REDIRECT 3rr, Redirect 6540 DESCRIBE 200, Session description 6541 OPTIONS Session ID 200, Reset session timeout timer 6542 OPTIONS 200 6543 SET_PARAMETER Valid parameter 200, change value of parameter 6544 GET_PARAMETER Valid parameter 200, return value of parameter 6546 Table 13: None state-machine changing events 6548 The methods in Table 13 do not have any effect on the state machine 6549 or the state variables. However some methods do change other session 6550 related parameters, for example SET_PARAMETER which will set the 6551 parameter(s) specified in its body. Also all of these methods that 6552 allows Session header will also update the keep-alive timer for the 6553 session. 6555 The initial state of the state machine, see Table 14 can only be left 6556 by processing a correct SETUP request. As seen in the table the two 6557 Action Requisite New State Response 6558 _____________________________________________________________ 6559 SETUP Ready NRM=1, RP=0.0 6560 SETUP Needs Redirect Init 3rr Redirect 6561 S -> C:REDIRECT No Session hdr Init Terminate all SES 6563 Table 14: State: Init 6565 state variables are also set by a correct request. This table also 6566 shows that a correct SETUP can in some cases be redirected to another 6567 URI and/or server by a 3rr response. 6569 Action Requisite New State Response 6571 _____________________________________________________________________ 6572 SETUP New URI Ready NRM+=1 6573 SETUP Setten up URI Ready Change transport param 6574 TEARDOWN Prs URI,NRM>1 Init No session hdr, NRM=0 6575 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 6576 TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1 6577 PLAY Prs URI, No range Play Play from RP 6578 PLAY Prs URI, Range Play According to range 6579 PAUSE Prs URI Ready Return PP 6580 S -> C:REDIRECT Range hdr Ready Set RedP 6581 S -> C:REDIRECT no range hdr Init Session is removed 6582 Timeout Init 6583 RedP reached Init TEARDOWN of session 6585 Table 15: State: Ready 6587 In the Ready state, see Table 15, some of the actions are depending 6588 on the number of media streams (NRM) in the session, i.e. aggregated 6589 or non-aggregated control. A setup request in the ready state can 6590 either add one more media stream to the session or if the media 6591 stream (same URI) already is part of the session change the transport 6592 parameters. TEARDOWN is depending on both the Request-URI and the 6593 number of media stream within the session. If the Request-URI is the 6594 presentations URI the whole session is torn down. If a media URI is 6595 used in the TEARDOWN request and more than one media exist in the 6596 session, the session will remain and a session header MUST be 6597 returned in the response. If only a single media stream remains in 6598 the session when performing a TEARDOWN with a media URI the session 6599 is removed. The number of media streams remaining after tearing down 6600 a media stream determines the new state. 6602 Action Requisite New State Response 6603 _____________________________________________________________________ 6604 PAUSE PrsURI,No range Ready Set RP to present point 6605 PAUSE PrsURI,Range>now Play Set RP & PP to given p. 6606 PAUSE PrsURI,Range1 Init No session hdr 6616 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 6617 TEARDOWN md URI Play 455 6618 S -> C:REDIRECT Range hdr Play Set RedP 6619 S -> C:REDIRECT no range hdr Init Session is removed 6620 RedP reached Init TEARDOWN of session 6621 Timeout Init Stop Media playout 6623 Table 16: State: Play 6625 The Play state table, see Table 16, is the largest. The table 6626 contains an number of requests that has presentation URI as a 6627 prerequisite on the Request-URI, this is due to the exclusion of 6628 non-aggregated stream control in sessions with more than one media 6629 stream. 6631 To avoid inconsistencies between the client and server, automatic 6632 state transitions are avoided. This can be seen at for example "End 6633 of media" event when all media has finished playing, the session 6634 still remain in Play state. An explicit PAUSE request MUST be sent to 6635 change the state to Ready. It may appear that there exist two 6636 automatic transitions in "RedP reached" and "PP reached", however 6637 they are requested and acknowledge before they take place. The time 6638 at which the transition will happen is known by looking at the range 6639 header. If the client sends request close in time to these 6640 transitions it needs to be prepared for getting error message as the 6641 state may or may not have changed. 6643 B Media Transport Alternatives 6645 This section defines how certain combinations of protocols, profiles 6646 and lower transports are used. This includes the usage of the 6647 Transport header's source and destination address parameters 6648 "src_addr" and "dest_addr". 6650 B.1 RTP 6652 This section defines the interaction of RTSP with respect to the RTP 6653 protocol [16]. It also defines any necessary media transport 6654 signalling with regards to RTP. 6656 The available RTP profiles and lower layer transports are described 6657 below along with rules on signalling the available combinations. 6659 B.1.1 AVP 6661 The usage of the "RTP Profile for Audio and Video Conferences with 6662 Minimal Control" [2] when using RTP for media transport over 6663 different lower layer transport protocols is defined below in regards 6664 to RTSP. 6666 One such case is defined within this document, the use of embedded 6667 (interleaved) binary data as defined in section 12. The usage of 6668 this method is indicated by include the "interleaved" parameter. 6670 When using embedded binary data the "src_addr" and "dest_addr" SHALL 6671 NOT be used. This addressing and multiplexing is used as defined with 6672 use of channel numbers and the interleaved parameter. 6674 B.1.2 AVP/UDP 6676 This part describes sending of RTP [16] over lower transport layer 6677 UDP [8] according to the profile "RTP Profile for Audio and Video 6678 Conferences with Minimal Control" defined in RFC 3551 [2]. This 6679 profiles requires one or two uni- or bi-directional UDP flows per 6680 media stream. The first UDP flow is for RTP and the second is for 6681 RTCP. Embedding of RTP data with the RTSP messages, in accordance 6682 with section 12, SHOULD NOT be performed when RTSP messages are 6683 transported over unreliable transport protocols, like UDP [8]. 6685 The RTP/UDP and RTCP/UDP flows can be established using the Transport 6686 header's "src_addr", and "dest_addr" parameters. 6688 In RTSP PLAY mode, the transmission of RTP packets from client to 6689 server is unspecified. The behavior in regards to such RTP packets 6690 MAY be defined in future. 6692 The "src_addr" and "dest_addr" parameters are used in the following 6693 way for media playback, i.e. Mode=PLAY: 6695 o The "src_addr" and "dest_addr" parameters MUST contain either 6696 1 or 2 address specifications. 6698 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 6699 contain either: 6701 - both an address and a port number, or 6703 - a port number without an address 6705 o The first address and port pair given in either of the 6706 parameters applies to the RTP stream. The second address and 6707 port pair if present applies to the RTCP stream. 6709 o The RTP/UDP packets from the server to the client SHALL be 6710 sent to the address and port given by first address and port 6711 pair of the "dest_addr" parameter. 6713 o The RTCP/UDP packets from the server to the client SHALL be 6714 sent to the address and port given by the second address and 6715 port pair of the "dest_addr" parameter. If no second pair is 6716 given RTCP SHALL NOT be sent. 6718 o The RTCP/UDP packets from the client to the server SHALL be 6719 sent to the address and port given by the second address and 6720 port pair of the "src_addr" parameter. If no second pair is 6721 given RTCP SHALL NOT be sent. 6723 o The RTP/UDP packets from the client to the server SHALL be 6724 sent to the address and port given by the first address and 6725 port pair of the "src_addr" parameter. 6727 o RTP and RTCP Packets SHOULD be sent from the corresponding 6728 receiver port, i.e. RTCP packets from server should be sent 6729 from the "src_addr" parameters second address port pair. 6731 B.1.3 AVP/TCP 6733 Note that this combination is not yet defined using sperate TCP 6734 connections. However the use of embedded (interleaved) binary data 6735 transported on the RTSP connection is possible as specified in 6736 section 12. When using this declared combination of interleaved 6737 binary data the RTSP messages MUST be transported over TCP. 6739 A possible future for this profile would be to define the 6740 use of a combination of the two drafts "Connection-Oriented 6741 Media Transport in SDP" [37] and "Framing RTP and RTCP 6742 Packets over Connection-Oriented Transport" [38]. However 6743 as this work is not finished, this functionality is 6744 unspecified. 6746 B.1.4 AVPF 6748 The RTP profile "Extended RTP Profile for RTCP-based Feedback 6749 (RTP/AVPF)" [20] MAY be used as RTP profiles in session using RTP. 6750 All that is defined for AVP SHALL also apply for AVPF. 6752 The usage of AVPF is indicated by the media initialization protocol 6753 used. In the case of SDP it is indicated by media lines (m=) 6754 containing the profile RTP/AVPF. That SDP MAY also contain further 6755 AVPF related SDP attributes configuring the AVPF session regarding 6756 reporting interval and feedback messages that shall be used that 6757 SHALL be followed. 6759 B.1.5 SAVP 6761 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" [21] 6762 is an RTP profile (SAVP) that MAY be used in RTSP sessions using RTP. 6763 All that is defined for AVP SHALL also apply for AVPF. 6765 The usage of SRTP requires that a security association is 6766 established. The protocol used are outside of the scope of RTSP, 6767 however a method must exist to enable the usage of the RTP profile 6768 SAVP. 6770 B.1.6 Handling NPT Jumps in the RTP Media Layer 6772 RTSP allows media clients to control selected, non-contiguous 6773 sections of media presentations, rendering those streams with an RTP 6774 media layer[16]. Such control allows jumps to be created in NPT 6775 timeline of the RTSP session. For example, jumps in NPT can be caused 6776 by multiple ranges in the range specifier of a PLAY request or 6777 through a "seek" opertaion on an RTSP session which involves a PLAY, 6778 PAUSE, PLAY scenario where a new NPT is set for the session. The 6779 media layer rendering the RTP stream should not be affected by jumps 6780 in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be 6781 continuous and monotonic across jumps of NPT. 6783 We cannot assume that the RTSP client can communicate with 6784 the RTP media agent, as the two may be independent 6785 processes. If the RTP timestamp shows the same gap as the 6786 NPT, the media agent will assume that there is a pause in 6787 the presentation. If the jump in NPT is large enough, the 6788 RTP timestamp may roll over and the media agent may believe 6789 later packets to be duplicates of packets just played out. 6791 As an example, assume a clock frequency of 8000 Hz, a packetization 6792 interval of 100 ms and an initial sequence number and timestamp of 6793 zero. 6795 C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 6796 CSeq: 4 6797 Session: abcdefg 6798 Range: npt=10-15 6800 S->C: RTSP/1.1 200 OK 6801 CSeq: 4 6802 Session: abcdefg 6803 Range: npt=10-15 6804 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6805 ssrc=0D12F123:seq=0;rtptime=0 6807 The ensuing RTP data stream is depicted below: 6809 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6810 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6811 . . . 6812 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 6814 Immediately after the end of the play range, the client follows up 6815 with a request to PLAY from a new NPT. 6817 C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 6818 CSeq: 5 6819 Session: abcdefg 6820 Range: npt=18-20; 6822 S->C: RTSP/1.1 200 OK 6823 CSeq: 5 6824 Session: abcdefg 6825 Range: npt=18-20 6826 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6827 ssrc=0D12F123:seq=50;rtptime=40100 6829 The ensuing RTP data stream is depicted below: 6831 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 6832 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 6833 . . . 6834 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 6836 In this example, first, NPT 10 through 15 is played, then the client 6837 request the server to skip ahead and play NPT 18 through 20. The 6838 first segment is presented as RTP packets with sequence numbers 0 6839 through 49 and timestamp 0 through 39,200. The second segment 6840 consists of RTP packets with sequence number 50 through 69, with 6841 timestamps 40,100 through 55,200. While there is a gap in the NPT, 6842 there is no gap in the sequence number space of the RTP data stream. 6844 The RTP timestamp gap is present in the above example due to the time 6845 it takes to perform the second play request, in this case 12.5 ms 6846 (100/8000). To avoid this gap in playback due to the time it takes to 6847 perform RTSP requests, a PLAY request with multiple ranges needs to 6848 be specified. That would result in the following example: 6850 C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 6851 CSeq: 4 6852 Session: abcdefg 6853 Range: npt=10-15;npt=18-20 6855 S->C: RTSP/1.1 200 OK 6856 CSeq: 4 6857 Session: abcdefg 6858 Range: npt=10-15 6859 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6860 ssrc=0D12F123:seq=0;rtptime=0 6862 The ensuing RTP data stream is depicted below: 6864 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6865 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6866 . . . 6867 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 6868 S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 6869 S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 6870 . . . 6871 S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 6873 B.1.7 Handling RTP Timestamps after PAUSE 6875 During a PAUSE / PLAY interaction in an RTSP session, the duration of 6876 time for which the RTP transmission was halted MUST be reflected in 6877 the RTP timestamp of each RTP stream. The duration can be calculated 6878 for each RTP stream as the time elapsed from when the last RTP packet 6879 was sent before the PAUSE request was received and when the first RTP 6880 packet was sent after the subsequent PLAY request was received. The 6881 duration includes all latency incurred and processing time required 6882 to complete the request. 6884 The RTP RFC [16] states that: The RTP timestamp for each 6885 unit[packet] would be related to the wallclock time at 6886 which the unit becomes current on the virtual presentation 6887 timeline. 6889 In order to satisfy the requirements of [16], the RTP timestamp space 6890 needs to increase continuously with real time. While this is not 6891 optimal for stored media, it is required for RTP and RTCP to function 6892 as intended. Using a continuous RTP timestamp space allows the same 6893 timestamp model for both stored and live media and allows better 6894 opportunity to integrate both types of media under a single control. 6896 As an example, assume a clock frequency of 8000 Hz, a packetization 6897 interval of 100 ms and an initial sequence number and timestamp of 6898 zero. 6900 C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 6901 CSeq: 4 6902 Session: abcdefg 6903 Range: npt=10-15; 6905 S->C: RTSP/1.1 200 OK 6906 CSeq: 4 6907 Session: abcdefg 6908 Range: npt=10-15 6909 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6910 ssrc=0D12F123:seq=0;rtptime=0 6912 The ensuing RTP data stream is depicted below: 6914 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6915 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6916 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 6917 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 6919 The client then sends a PAUSE request: 6921 C->S: PAUSE rtsp://xyz/fizzle RTSP/1.1 6922 CSeq: 5 6923 Session: abdcdefg 6925 S->C: RTSP/1.1 200 OK 6926 CSeq: 5 6927 Session: abcdefg 6928 Range: npt=10.4-15 6930 20 seconds elapse and then the client sends a PLAY request. In 6931 addition the server requires 15 ms to process the request: 6933 C->S: PLAY rtsp://xyz/fizzle RTSP/1.1 6934 CSeq: 6 6935 Session: abcdefg 6937 S->C: RTSP/1.1 200 OK 6938 CSeq: 6 6939 Session: abcdefg 6940 Range: npt=10.4-15 6941 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6942 ssrc=0D12F123:seq=4;rtptime=164400 6944 The ensuing RTP data stream is depicted below: 6946 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 6947 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 6948 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 6950 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 6951 server. After 20 seconds a PLAY is received by the server which take 6952 15ms to process. The duration of time for which the session was 6953 paused is reflected in the RTP timestamp of the RTP packets sent 6954 after this PLAY request. 6956 A client can use the RTSP range header and RTP-Info header to map NPT 6957 time of a presentation with the RTP timestamp. 6959 Note: In RFC 2326 [24], this matter was not clearly defined and was 6960 misunderstood commonly. However for RTSP 1.1 it is expected that this 6961 will be handled correctly and not exception handling will be 6962 required. 6964 B.1.8 RTSP / RTP Integration 6966 For certain datatypes, tight integration between the RTSP layer and 6967 the RTP layer will be necessary. This by no means precludes the above 6968 restrictions. Combined RTSP/RTP media clients should use the RTP-Info 6969 field to determine whether incoming RTP packets were sent before or 6970 after a seek or before or after a PAUSE. 6972 B.1.9 Scaling with RTP 6974 For scaling (see Section 14.39), RTP timestamps should correspond to 6975 the playback timing. For example, when playing video recorded at 30 6976 frames/second at a scale of two and speed (Section 14.40) of one, the 6977 server would drop every second frame to maintain and deliver video 6978 packets with the normal timestamp spacing of 3,000 per frame, but NPT 6979 would increase by 1/15 second for each video frame. 6981 Note: The above scaling puts requirements on the media 6982 codec or a media stream to support it. For example motion 6983 JPEG or other non-predictive video coding can easier handle 6984 the above example. 6986 B.1.10 Maintaining NPT synchronization with RTP timestamps 6988 The client can maintain a correct display of NPT by noting the RTP 6989 timestamp value of the first packet arriving after repositioning. 6990 The sequence parameter of the RTP-Info (Section 14.38) header 6991 provides the first sequence number of the next segment. 6993 B.1.11 Continuous Audio 6995 For continuous audio, the server SHOULD set the RTP marker bit at the 6996 beginning of serving a new PLAY request or at jumps in timeline. This 6997 allows the client to perform playout delay adaptation. 6999 B.1.12 Multiple Sources in an RTP Session 7000 Note that more than one SSRC MAY be sent in the media stream. If it 7001 happens all sources are expected to be rendered simultaneously. 7003 B.1.13 Usage of SSRCs and the RTCP BYE Message During an RTSP Session 7005 The RTCP BYE message indicates the end of use of a given SSRC. If all 7006 sources leave an RTP session, it can, in most cases, be assumed to 7007 have ended. Therefore, a client or server SHALL NOT send a RTCP BYE 7008 message until it has finished using a SSRC. A server SHOULD keep 7009 using a SSRC until the RTP session is terminated. Prolonging the use 7010 of a SSRC allows the established synchronization context associated 7011 with that SSRC to be used to synchronize subsequent PLAY requests 7012 even if the PLAY response is late. 7014 An SSRC collision with the SSRC that transmits media does also have 7015 consequences, as it will force the media sender to change its SSRC in 7016 accordance with the RTP specification [16]. This will result in a 7017 loss of synchronization context, and require any receiver to wait for 7018 RTCP sender reports for all media requiring synchronization before 7019 being able to play out synchronized. Due to these reasons a client 7020 joining a session should take care to not select the same SSRC as the 7021 server. Any SSRC signalled in the Transport header SHOULD be avoided. 7022 A client detecting a collision prior to sending any RTP or RTCP 7023 messages can also select a new SSRC. 7025 B.2 Future Additions 7027 It is the intention that any future protocol or profile regarding 7028 both for media delivery and lower transport should be easy to add to 7029 RTSP. This section provides the necessary steps that needs to be 7030 meet. 7032 The following things needs to be considered when adding a new 7033 protocol of profile for use with RTSP: 7035 o The protocol or profile needs to define a name tag 7036 representing it. This tag is required to be a ABNF "token" to 7037 be possible to use in the Transport header specification. 7039 o The useful combinations of protocol/profile/lower-layer needs 7040 to be defined and for each combination declare the necessary 7041 parameters to use in the Transport header. 7043 o For new media protocols the interaction with RTSP needs to be 7044 addressed. One important factor will be the media 7045 synchronization. 7047 See the IANA section (21) for information how to register new 7048 attributes. 7050 C Use of SDP for RTSP Session Descriptions 7052 The Session Description Protocol (SDP, RFC 2327 [1]) may be used to 7053 describe streams or presentations in RTSP. This description is 7054 typically returned in reply to a DESCRIBE request on an URI from a 7055 server to a client, or received via HTTP from a server to a client. 7057 This appendix describes how an SDP file determines the operation of 7058 an RTSP session. SDP as is provides no mechanism by which a client 7059 can distinguish, without human guidance, between several media 7060 streams to be rendered simultaneously and a set of alternatives 7061 (e.g., two audio streams spoken in different languages). However the 7062 SDP extension "Grouping of Media Lines in the Session Description 7063 Protocol (SDP)" [39] may provide such functionality depending on 7064 need. Also future grouping semantics may in the future be developed. 7066 C.1 Definitions 7068 The terms "session-level", "media-level" and other key/attribute 7069 names and values used in this appendix are to be used as defined in 7070 SDP (RFC 2327 [1]): 7072 C.1.1 Control URI 7074 The "a=control:" attribute is used to convey the control URI. This 7075 attribute is used both for the session and media descriptions. If 7076 used for individual media, it indicates the URI to be used for 7077 controlling that particular media stream. If found at the session 7078 level, the attribute indicates the URI for aggregate control 7079 (presentation URI). The session level URI SHALL be different from any 7080 media level URI. The presence of a session level control attribute 7081 SHALL be interpreted as support for aggregated control. The control 7082 attribute SHALL be present on media level unless the presentation 7083 only contains a single media stream, in which case the attribute MAY 7084 only be present on the session level. 7086 ABNF for the attribute is defined in section 19.3. 7088 Example: 7090 a=control:rtsp://example.com/foo 7092 This attribute MAY contain either relative or absolute URIs, 7093 following the rules and conventions set out in RFC 3986 [10]. 7095 Implementations SHALL look for a base URI in the following order: 7097 1. the RTSP Content-Base field; 7099 2. the RTSP Content-Location field; 7101 3. the RTSP Request-URI. 7103 If this attribute contains only an asterisk (*), then the URI SHALL 7104 be treated as if it were an empty embedded URI, and thus inherit the 7105 entire base URI. 7107 The URI handling for SDPs from container files need special 7108 consideration. For example lets assume that a container file has the 7109 URI: "rtsp://example.com/container.mp4". Lets further assume this URI 7110 is the base URI, and that there is a absolute media level URI: 7111 "rtsp://example.com/container.mp4/trackID=2". A relative media level 7112 URI that resolves in accordance with RFC 3986 [10] to the above given 7113 media URI is: "container.mp4/trackID=2". It is usually not desirable 7114 to need to include in or modify the SDP stored within the container 7115 file with the server local name of the container file. To avoid this, 7116 one can modify the base URI used to include a trailing slash, e.g. 7117 "rtsp://example.com/container.mp4/". In this case the relative URI 7118 for the media will only need to be: "trackID=2". However this will 7119 also mean that using "*" in the SDP will result in control URI 7120 including the trailing slash, i.e. 7121 "rtsp://example.com/container.mp4/". 7123 C.1.2 Media Streams 7125 The "m=" field is used to enumerate the streams. It is expected that 7126 all the specified streams will be rendered with appropriate 7127 synchronization. If the session is over multicast, the port number 7128 indicated SHOULD be used for reception. The client MAY try to 7129 override the destination port, through the Transport header. The 7130 servers MAY allow this, the response will indicate if allowed or not. 7131 If the session is unicast, the port number is the ones RECOMMENDED by 7132 the server to the client, about which receiver ports to use; the 7133 client MUST still include its receiver ports in its SETUP request. 7134 The client MAY ignore this recommendation. If the server has no 7135 preference, it SHOULD set the port number value to zero. 7137 The "m=" lines contain information about what transport protocol, 7138 profile, and possibly lower-layer is to be used for the media stream. 7139 The combination of transport, profile and lower layer, like 7140 RTP/AVP/UDP needs to be defined for how to be used with RTSP. The 7141 currently defined combinations are defined in section B, further 7142 combinations MAY be specified. 7144 Usage of grouping of media lines [39] to determine which media lines 7145 should or should not be included in a RTSP session is unspecified. 7147 Example: 7149 m=audio 0 RTP/AVP 31 7151 C.1.3 Payload Type(s) 7153 The payload type(s) are specified in the "m=" field. In case the 7154 payload type is a static payload type from RFC 3551 [2], no other 7155 information may be required. In case it is a dynamic payload type, 7156 the media attribute "rtpmap" is used to specify what the media is. 7157 The "encoding name" within the "rtpmap" attribute may be one of those 7158 specified in RFC 3551 (Sections 5 and 6), or an MIME type registered 7159 with IANA, or an experimental encoding as specified in SDP (RFC 2327 7160 [1]). Codec-specific parameters are not specified in this field, but 7161 rather in the "fmtp" attribute described below. 7163 C.1.4 Format-Specific Parameters 7165 Format-specific parameters are conveyed using the "fmtp" media 7166 attribute. The syntax of the "fmtp" attribute is specific to the 7167 encoding(s) that the attribute refers to. Note that some of the 7168 format specific parameters may be specified outside of the fmtp 7169 parameters, like for example the "ptime" attribute for most audio 7170 encodings. 7172 C.1.5 Range of Presentation 7174 The "a=range" attribute defines the total time range of the stored 7175 session or an individual media. Non-seekable live sessions can be 7176 indicated, while the length of live sessions can be deduced from the 7177 "t" and "r" SDP parameters. 7179 The attribute is both a session and a media level attribute. For 7180 presentations that contains media streams of the same durations, the 7181 range attribute SHOULD only be used at session-level. In case of 7182 different length the range attribute MUST be given at media level for 7183 all media, and SHOULD NOT be given at session level. If the attribute 7184 is present at both media level and session level the media level 7185 values SHALL be used. 7187 The unit is specified first, followed by the value range. The units 7188 and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY 7189 be extended with further formats. Any open ended range (start-), i.e. 7191 without stop range, is of unspecified duration and SHALL be 7192 considered as non-seekable content unless this property is 7193 overridden. Multiple instances carrying different clock formats MAY 7194 be included at either session or media level. 7196 ABNF for the attribute is defined in section 19.3. 7198 Examples: 7200 a=range:npt=0-34.4368 7201 a=range:clock=19971113T2115-19971113T2203 7202 Non seekable stream of unknown duration: 7203 a=range:npt=0- 7205 C.1.6 Time of Availability 7207 The "t=" field MUST contain suitable values for the start and stop 7208 times for both aggregate and non-aggregate stream control. The 7209 server SHOULD indicate a stop time value for which it guarantees the 7210 description to be valid, and a start time that is equal to or before 7211 the time at which the DESCRIBE request was received. It MAY also 7212 indicate start and stop times of 0, meaning that the session is 7213 always available. 7215 For sessions that are of live type, i.e. specific start time, unknown 7216 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 7217 to indicate the start time of the event. The stop time SHOULD be 7218 given so that the live event will with high probability have ended at 7219 that time, while still not be unnecessary long into the future. 7221 C.1.7 Connection Information 7223 In SDP, the "c=" field contains the destination address for the media 7224 stream. For a media destination address that is a IPv6 one, the SDP 7225 extension defined in [22] needs to be used. For on-demand unicast 7226 streams and some multicast streams, the destination address MAY be 7227 specified by the client via the SETUP request, thus overriding any 7228 specified address. To identify streams without a fixed destination 7229 address, where the client is required to specify a destination 7230 address, the "c=" field SHOULD be set to a null value. For addresses 7231 of type "IP4", this value SHALL be "0.0.0.0", and for type "IP6", 7232 this value SHALL be "0:0:0:0:0:0:0:0", i.e. the unspecified address 7233 according to RFC 3513 [23]. 7235 C.1.8 Entity Tag 7236 The optional "a=etag" attribute identifies a version of the session 7237 description. It is opaque to the client. SETUP requests may include 7238 this identifier in the If-Match field (see section 14.25) to only 7239 allow session establishment if this attribute value still corresponds 7240 to that of the current description. The attribute value is opaque 7241 and may contain any character allowed within SDP attribute values. 7243 ABNF for the attribute is defined in section 19.3. 7245 Example: 7247 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 7249 One could argue that the "o=" field provides identical 7250 functionality. However, it does so in a manner that would 7251 put constraints on servers that need to support multiple 7252 session description types other than SDP for the same piece 7253 of media content. 7255 C.2 Aggregate Control Not Available 7257 If a presentation does not support aggregate control no session level 7258 "a=control:" attribute is specified. For a SDP with multiple media 7259 sections specified, each section will have its own control URI 7260 specified via the "a=control:" attribute. 7262 Example: 7264 v=0 7265 o=- 2890844256 2890842807 IN IP4 204.34.34.32 7266 s=I came from a web page 7267 e=adm@example.com 7268 c=IN IP4 0.0.0.0 7269 t=0 0 7270 m=video 8002 RTP/AVP 31 7271 a=control:rtsp://audio.com/movie.aud 7272 m=audio 8004 RTP/AVP 3 7273 a=control:rtsp://video.com/movie.vid 7275 Note that the position of the control URI in the description implies 7276 that the client establishes separate RTSP control sessions to the 7277 servers audio.com and video.com 7278 It is recommended that an SDP file contains the complete media 7279 initialization information even if it is delivered to the media 7280 client through non-RTSP means. This is necessary as there is no 7281 mechanism to indicate that the client should request more detailed 7282 media stream information via DESCRIBE. 7284 C.3 Aggregate Control Available 7286 In this scenario, the server has multiple streams that can be 7287 controlled as a whole. In this case, there are both a media-level 7288 "a=control:" attributes, which are used to specify the stream URIs, 7289 and a session-level "a=control:" attribute which is used as the 7290 Request-URI for aggregate control. If the media-level URI is 7291 relative, it is resolved to absolute URIs according to Section C.1.1 7292 above. 7294 Example: 7296 C->M: DESCRIBE rtsp://example.com/movie RTSP/1.1 7297 CSeq: 1 7299 M->C: RTSP/1.1 200 OK 7300 CSeq: 1 7301 Date: 23 Jan 1997 15:35:06 GMT 7302 Content-Type: application/sdp 7303 Content-Base: rtsp://example.com/movie/ 7304 Content-Length: 228 7306 v=0 7307 o=- 2890844256 2890842807 IN IP4 204.34.34.32 7308 s=I contain 7309 i= 7310 e=adm@example.com 7311 c=IN IP4 0.0.0.0 7312 t=0 0 7313 a=control:* 7314 m=video 8002 RTP/AVP 31 7315 a=control:trackID=1 7316 m=audio 8004 RTP/AVP 3 7317 a=control:trackID=2 7319 In this example, the client is required to establish a single RTSP 7320 session to the server, and uses the URIs 7321 rtsp://example.com/movie/trackID=1 and 7322 rtsp://example.com/movie/trackID=2 to set up the video and audio 7323 streams, respectively. The URI rtsp://example.com/movie/ , which is 7324 resolved from the "*", controls the whole presentation (movie). 7326 A client is not required to issues SETUP requests for all streams 7327 within an aggregate object. Servers should allow the client to ask 7328 for only a subset of the streams. 7330 C.4 RTSP external SDP delivery 7332 There are some considerations that needs to be made when the session 7333 description is delivered to client outside of RTSP, for example in 7334 HTTP or email. 7336 First of all the SDP needs to contain absolute URIs, relative will in 7337 most cases not work as the delivery will not correctly forward the 7338 base URI. And as SDP might be temporarily stored on file system 7339 before being loaded into an RTSP capable client, thus if possible to 7340 transport the base URI it still would need to be merged into the 7341 file. 7343 The writing of the SDP session availability information, i.e. "t=" 7344 and "r=", needs to be carefully considered. When the SDP is fetched 7345 by the DESCRIBE method it is with very high probability that the it 7346 is valid. However the same are much less certain for SDPs distributed 7347 using other methods. Therefore the publisher of the SDP should take 7348 care to follow the recommendations about availability in the SDP 7349 specification [1]. 7351 D Minimal RTSP implementation 7353 Note: This section is still under development! 7355 This section defines the minimal implementation requirements for any 7356 client and server. In addition the requirements for supporting the 7357 "play.basic" feature tag is defined here. 7359 D.1 Minimal Core Implementation 7361 The minimal core implementation is what is required to negotiate the 7362 usage of any other features. A minimal core implementation is not 7363 supporting any other feature set will be useless as the minimal 7364 implementation doesn't deliver any service. All feature sets SHALL 7365 include the minimal core. 7367 A minimal core implementation SHALL support the following 7368 functionalities: 7370 o Establishing a connection between RTSP agent using TCP. 7372 o Implement the reception and response to the OPTIONS method. 7374 o Implement the handling of all headers mandatory or conditional 7375 in regards to the usage of the OPTIONS method. See tables 9 7376 and 10. This include at least the capability to ignore 7377 unknown headers. 7379 o Implement the headers related to capability negotiation and 7380 exchange: 7382 - Require 7384 - Supported 7386 - Proxy-Require 7388 - Proxy-Supported 7390 - Unsupported 7392 D.2 The Basic Playback Feature Support 7394 This section defines what is required to be supported for clients, 7395 proxies and servers to be supporting the "play.basic" feature tag. 7397 D.2.1 Client 7399 A play.basic supporting client SHALL implement the following: 7401 o The RTSP methods as required by Table 7. 7403 o All the RTSP headers that are required required or conditional 7404 in requests or responses to method required to be supported 7405 according to Tables 9, 10, 11, and 12 and in addition the 7406 following headers: 7408 - Content-Base 7410 - Content-Encoding and at least the Identity method. 7412 - Content-Location 7414 - Location 7416 - Range 7418 - RTP-Info 7420 o Handling of all Status code categories and in addition the 7421 following specific status codes: 7423 o Media delivery using RTP/AVP over UDP. 7425 A play.basic client is RECOMMENDED to support the following: 7427 o RTSP basic and digest authentication: The 401 response, the 7428 WWW-Authenticate and Authorization headers, and both Basic and 7429 Digest authentication methods as defined by [7]. 7431 o Expires header 7433 o From header 7435 o Secure Transport as specified by section D.3. 7437 D.2.2 Server 7439 To be written! 7441 D.2.3 Proxy 7443 A play.basic supporting proxy SHALL implement the following: 7445 o Correct handling of the RTSP methods as required by Table 7. 7447 o The handling of all RTSP headers that are required to be 7448 handled by the server and clients supporting "play.basic" and 7449 in addition the following headers: 7451 - Cache-Control 7453 - Expires 7455 - Via 7457 D.3 Secure Transport 7459 Any Client, Proxy or Server supporting secure transport of RTSP 7460 messages and usage of the "rtsps" URI scheme SHALL implement; The 7461 Accept-Credentials and Connection-Credentials headers; TLS over TCP. 7463 D.4 Old Implementation Text 7465 The OLD Text follows from here on and is kept in this revision for 7466 comparison reasons: 7468 D.5 Client 7470 A client implementation MUST be able to do the following : 7472 o Generate the following requests: SETUP, TEARDOWN, PLAY. 7474 o Include the following headers in requests: CSeq, Connection, 7475 Session, Transport. 7477 o Parse and understand the following headers in responses: 7478 CSeq, Connection, Session, Transport, Content-Language, 7479 Content-Encoding, Content-Length, Content-Type. 7481 o Understand the class of each error code received and notify 7482 the end-user, if one is present, of error codes in classes 4xx 7483 and 5xx. The notification requirement may be relaxed if the 7484 end-user explicitly does not want it for one or all status 7485 codes. 7487 o Expect and respond to asynchronous requests from the server, 7488 such as REDIRECT. This does not necessarily mean that it 7489 should implement the REDIRECT method, merely that it MUST 7490 respond positively or negatively to any request received from 7491 the server. 7493 Though not required, the following are RECOMMENDED. 7495 o Implement RTP/AVP/UDP as a valid transport. 7497 o Inclusion of the User-Agent header. 7499 o Understand SDP session descriptions as defined in Appendix C 7501 o Accept media initialization formats (such as SDP) from 7502 standard input, command line, or other means appropriate to 7503 the operating environment to act as a "helper application" for 7504 other applications (such as web browsers). 7506 There may be RTSP applications different from those 7507 initially envisioned by the contributors to the RTSP 7508 specification for which the requirements above do not make 7509 sense. Therefore, the recommendations above serve only as 7510 guidelines instead of strict requirements. 7512 D.5.1 Basic Playback 7514 To support on-demand playback of media streams, the client MUST 7515 additionally be able to do the following: 7517 o generate the PAUSE request; 7519 o implement the REDIRECT method, and the Location header. 7521 D.5.2 Authentication-enabled 7523 In order to access media presentations from RTSP servers that require 7524 authentication, the client MUST additionally be able to do the 7525 following: 7527 o recognize the 401 (Unauthorized) status code; 7529 o parse and include the WWW-Authenticate header; 7531 o implement Basic Authentication and Digest Authentication. 7533 D.6 Server 7535 A minimal server implementation MUST be able to do the following: 7537 o Implement the following methods: SETUP, TEARDOWN, OPTIONS, 7538 SET_PARAMETER and PLAY. 7540 o Include the following headers in responses: Connection, 7541 Content-Length, Content-Type, Content-Language, Content- 7542 Encoding, Timestamp, Transport, Proxy-Supported, Public, and 7543 Via, and Unsupported. RTP-compliant implementations MUST also 7544 implement the RTP-Info field. 7546 o Parse and respond appropriately to the following headers in 7547 requests: Connection, Proxy-Require, Session, Transport, and 7548 Require. 7550 o Implement Date header if supporting DESCRIBE 7552 Though not required, the following are highly recommended at the time 7553 of publication for practical interoperability with initial 7554 implementations and/or to be a "good citizen". 7556 o Implement RTP/AVP/UDP as a valid transport. 7558 o Inclusion of the Server, Cache-Control, and Expires headers. 7560 o Implement the DESCRIBE method. 7562 o Generate SDP session descriptions as defined in Appendix C 7563 There may be RTSP applications different from those 7564 initially envisioned by the contributors to the RTSP 7565 specification for which the requirements above do not make 7566 sense. Therefore, the recommendations above serve only as 7567 guidelines instead of strict requirements. 7569 D.6.1 Basic Playback 7571 To support on-demand playback of media streams, the server MUST 7572 additionally be able to do the following: 7574 o Recognize the Range header, and return an error if seeking is 7575 not supported. 7577 o Implement the PAUSE method. 7579 In addition, in order to support commonly-accepted user interface 7580 features, the following are highly recommended for on-demand media 7581 servers: 7583 o Include and parse the Range header, with NPT units. 7584 Implementation of SMPTE units is recommended. 7586 o Include the length of the media presentation in the media 7587 initialization information. 7589 o Include mappings from data-specific timestamps to NPT. When 7590 RTP is used, the rtptime portion of the RTP-Info field may be 7591 used to map RTP timestamps to NPT. 7593 Client implementations may use the presence of length 7594 information to determine if the clip is seekable, and 7595 visably disable seeking features for clips for which the 7596 length information is unavailable. A common use of the 7597 presentation length is to implement a "slider bar" which 7598 serves as both a progress indicator and a timeline 7599 positioning tool. 7601 Mappings from RTP timestamps to NPT are necessary to ensure correct 7602 positioning of the slider bar. 7604 D.6.2 Authentication-enabled 7606 In order to correctly handle client authentication, the server MUST 7607 additionally be able to do the following: 7609 o Generate the 401 (Unauthorized) status code when 7610 authentication is required for the resource. 7612 o Parse and include the WWW-Authenticate header 7614 o Implement Basic Authentication and Digest Authentication 7616 E Requirements for Unreliable Transport of RTSP messages 7618 This section provides any one intending to define how to transport of 7619 RTSP messages over a unreliable transport protocol with some 7620 information learned by the attempt in RFC 2326 [24]. RFC 2326 define 7621 both an URI scheme and some basic functionality for transport of RTSP 7622 messages over UDP, however it was not sufficient for reliable usage 7623 and successful interoperability. 7625 The RTSP scheme defined for unreliable transport of RTSP messages was 7626 "rtspu". It has been reserved by this specification as at least one 7627 commercial implementation exist, thus avoiding any collisions in the 7628 name space. 7630 The following considerations should exist for operation of RTSP over 7631 an unreliable transport protocol: 7633 o Request shall be acknowledged by the receiver. If there is no 7634 acknowledgement, the sender may resend the same message after 7635 a timeout of one round-trip time (RTT). Any retransmissions 7636 due to lack of acknowledgement must carry the same sequence 7637 number as the original request. 7639 o The round-trip time can be estimated as in TCP (RFC 1123) 7640 [40], with an initial round-trip value of 500 ms. An 7641 implementation may cache the last RTT measurement as the 7642 initial value for future connections. 7644 o If RTSP is used over a small-RTT LAN, standard procedures for 7645 optimizing initial TCP round trip estimates, such as those 7646 used in T/TCP (RFC 1644) [41], can be beneficial. 7648 o The Timestamp header (Section 14.44) is used to avoid the 7649 retransmission ambiguity problem [42] and obviates the need 7650 for Karn's algorithm. 7652 o The registered default port for RTSP over UDP for the server 7653 is 554. 7655 o RTSP messages can be carried over any lower-layer transport 7656 protocol that is 8-bit clean. 7658 o RTSP messages are vulnerable to bit errors and should not be 7659 subjected to them. 7661 o Source authentication, or at least validation that RTSP 7662 messages comes from the same entity becomes extremely 7663 important, as session hijacking may be substantially easier 7664 for RTSP message transport using an unreliable protocol like 7665 UDP than for TCP. 7667 There exist two RTSP headers thats primarily are intended for being 7668 used by the unreliable handling of RTSP messages and which will be 7669 maintained: 7671 CSeq See section 14.19 7673 Timestamp See section 14.44 7675 F Backwards Compatibility Considerations 7677 This section contains notes on issues about backwards compatibility 7678 with clients or servers being implemented according to RFC 2326 [24]. 7680 A server implementing RTSP/1.1 MUST include a RTSP-Version of 7681 RTSP/1.1 in all responses to requests containing RTSP-Version 7682 RTSP/1.1. If a server receives a RTSP/1.0 request, it MAY respond 7683 with a RTSP/1.0 response if it chooses to support RFC 2326. If the 7684 server chooses not to support RFC 2326, it SHOULD respond with a 505 7685 (RTSP Version not supported) status code. A server MUST NOT respond 7686 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/1.1 7687 response. 7689 Clients implementing RTSP/1.1 SHOULD use an OPTIONS request with a 7690 RTSP-Version of 1.1 to determine whether a server supports RTSP/1.1. 7691 If the server responds with either a RTSP-Version of 1.0 or a status 7692 code of 505 (RTSP Version not supported), the client MAY use RTSP/1.0 7693 requests if it chooses to support RFC 2326. A client SHOULD NOT send 7694 RTSP/1.1 requests to a server which has previously responded to a 7695 RTSP/1.1 request with a RTSP-Version of 1.0. 7697 F.1 Play Request in Play mode 7699 The behavior in the server when a Play is received in Play mode has 7700 changed (Section 11.4). In RFC 2326, the new PLAY request would be 7701 queued until the current Play completed. Any new PLAY request now 7702 take effect immediately replacing the previous request. 7704 F.2 Using Persistent Connections 7705 Some server implementations of RFC 2326 maintain a one-to-one 7706 relationship between a connection and an RTSP session. Such 7707 implementations require clients to use a persistent connection to 7708 communicate with the server and when a client closes its connection, 7709 the server may remove the RTSP session. This is worth noting if a 7710 RTSP 1.1 client connects to a 1.0 server. 7712 G Open Issues 7714 This section contains a list of open issues that still needs to be 7715 resolved. However also any open issues in the bug tracker at 7716 http://rtspspec.sourceforge.net should also be considered. 7718 1. Should the Allow header be possible to use optional in 7719 request or responses of DESCRIBE and SETUP besides the now 7720 specified 405 error code and OPTIONS? 7722 2. The minimal implementation chapter is still under 7723 refinement. All shall, must and shoulds needs to be 7724 included in the minimal and relevant feature tags. 7725 Feature-tags for these needs to be defined. Further 7726 feature-tags needs to be discussed. 7728 3. The RTSP state machine is kind of not as useful as one 7729 could desire. Should something be done about this? See 7730 http://www1.ietf.org/mail- 7731 archive/web/mmusic/current/msg03542.html 7733 H Changes 7735 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 7736 defining RTSP 1.1. Note that this list does not reflect minor changes 7737 in wording or correction of typographical errors. 7739 o The Transport header has been changed in the following way: 7741 - The ABNF has been changed to define that extensions are 7742 possible, and that unknown extension parameters are to be 7743 ignored. 7745 - To prevent backwards compatibility issues, any extension or 7746 new parameter requires the usage of a feature tag combined 7747 with the Require header. 7749 - Syntax unclarities with the Mode parameter has been 7750 resolved. 7752 - Syntax error with ";" for multicast and unicast has been 7753 resolved. 7755 - Two new addressing parameters has been defined, src_addr and 7756 dest_addr. These replaces the parameters "port", 7757 "client_port", "server_port", "destination", "source". 7759 - Support for IPv6 explicit addresses in all address fields 7760 has been included. 7762 - To handle URI definitions that contain ";" or "," a quoted 7763 URI format has been introduced and is required. 7765 - Defined IANA registries for the transport headers 7766 parameters, transport-protocol, profile, lower-transport, 7767 and mode. 7769 - The transport headers interleaved parameter's text was made 7770 more strict and use formal requirements levels. However no 7771 change on how it is used was made. 7773 - It has been clarified that the client can't request of the 7774 server to use a certain RTP SSRC, using a request with the 7775 transport parameter SSRC. 7777 - Syntax definition for SSRC has been clarified to require 8*8 7778 HEX. It has also been extend to allow multiple values for 7779 clients supporting this version. 7781 - Clarified the text on the transport headers "dest_addr" 7782 parameters regarding what security precautions the server is 7783 required to perform. 7785 - The embedded (interleaved) binary data and its transport 7786 parameter was clarified to being symmetric and that it is 7787 the server that sets the channel numbers. 7789 o The Range formats has been changed in the following way: 7791 - The NPT format has been given a initial NPT identifier that 7792 must now be used. 7794 - All formats now support initial open ended formats of type 7795 "npt=-10". 7797 o RTSP message handling has been changed in the following way: 7799 - RTSP messages now uses URIs rather then URLs. 7801 - It has been clarified that a 4xx message due to missing CSeq 7802 header shall be returned without a CSeq header. 7804 - Rules for how to handle timing out RTSP messages has been 7805 added. 7807 o The HTTP references has been updated to RFC 2616 and RFC 2617. 7808 This has resulted in that the Public, and the Content-Base 7809 header needed to be defined in the RTSP specification. Known 7810 effects on RTSP due to HTTP clarifications: 7812 - Content-Encoding header can include encoding of type 7813 "identity". 7815 o The state machine section has completely been rewritten. It 7816 includes now more details and are also more clear about the 7817 model used. 7819 o A IANA section has been included with contains a number of 7820 registries and their rules. This will allow us to use IANA to 7821 keep track of all RTSP extensions. 7823 o Than transport of RTSP messages has seen the following 7824 changes: 7826 - The use of UDP for RTSP message transport has been 7827 deprecated due to missing interest and to broken 7828 specification. 7830 - The rules for how TCP connections is to be handled has been 7831 clarified. Now it is made clear that servers should not 7832 close the TCP connection unless they have been unused for 7833 significant time. 7835 - Strong recommendations why server and clients should use 7836 persistent connections has also been added. 7838 - There is now a requirement on the servers to handle non- 7839 persistent connections as this provides fault tolerance. 7841 - Added wording on the usage of Connection:Close for RTSP. 7843 - specified usage of TLS for RTSP messages, including a scheme 7844 to approve a proxies TLS connection to the next hop. 7846 o The following header related changes have been made: 7848 - Accept-Ranges response header is added. This header 7849 clarifies which range formats that can be used for a 7850 resource. 7852 - Clarified that Range header allows multiple ranges to allow 7853 for creating editing list. 7855 - Fixed the missing definitions for the Cache-Control header. 7856 Also added to the syntax definition the missing delta- 7857 seconds for max-stale and min-fresh parameters. 7859 - Put requirement on CSeq header that the value is increased 7860 by one for each new RTSP request. A Recommendation to start 7861 at 1 has also been added. 7863 - Added requirement that the Date header must be used for all 7864 messages with entity. Also the Server should always include 7865 it. 7867 - Removed possibility of using Range header with Scale header 7868 to indicate when it is to be activated, since it can't work 7869 as defined. Also added rule that lack of Scale header in 7870 response indicates lack of support for the header. Feature- 7871 tags for scaled playback has been defined. 7873 - The Speed header must now be responded to indicate support 7874 and the actual speed going to be used. A feature-tag is 7875 defined. Notes on congestion control was also added. 7877 - The Supported header was borrowed from SIP to help with the 7878 feature negotiation in RTSP. 7880 - Clarified that the Timestamp header can be used to resolve 7881 retransmission ambiguities. 7883 - The Session header text has been expanded with a explanation 7884 on keep alive and which methods to use. SET_PARAMETER is now 7885 recommended to use if only keep-alive within RTSP is 7886 desired. 7888 - It has been clarified how the Range header formats is used 7889 to indicate pause points. 7891 - Clarified that RTP-Info URIs that are relative, uses the 7892 Request-URI as base URI. Also clarified that used URI must 7893 be that one that was used in the SETUP request. They are now 7894 also required to be quoted. The header also expresses the 7895 SSRC for the provided RTP timestamp and sequence number 7896 values. 7898 - Added text that requires the Range to always be present in 7899 PLAY responses. Clarified what should be sent in case of 7900 live streams. 7902 - The headers table has been updated using a structured 7903 borrowed from SIP. This table carries much more information 7904 and should provide a good overview of the available headers. 7906 - It has been is clarified that any message with a message 7907 body is required to have a Content-Length header. This was 7908 the case in RFC 2326 but could be misinterpreted. 7910 - To resolve functionality around ETag. The ETag and If-None- 7911 Match header has been added from HTTP with necessary 7912 clarification in regards to RTSP operation. 7914 - Imported the Public header from HTTP RFC 2068 [18] since it 7915 has been removed from HTTP due to lack of use. Public is 7916 used quite frequently in RTSP. 7918 - Clarified rules for populating the Public header so that it 7919 is an intersection of the capabilities of all the RTSP 7920 agents in a chain. 7922 o The Protocol Syntax has been changed in the following way: 7924 - All BNF definitions are updated according to the rules 7925 defined in RFC 2234 [4] and has been gathered in a separate 7926 section 19. 7928 - The BNF for the User-Agent and Server headers has been 7929 corrected so now only the description is in the HTTP 7930 specification. 7932 - The definition in the introduction of the RTSP session has 7933 been changed. 7935 - The protocol has been made fully IPv6 capable. Certain of 7936 the functionality, like using explicit IPv6 addresses in 7937 fields requires that the protocol support this updated 7938 specification. 7940 - Added a fragment part to the RTSP URI. This seem to be 7941 indicated by the note below the definition however it was 7942 not part of the BNF. 7944 - The CHAR rule has been changed to exclude NULL. 7946 o The Status codes has been changed in the following way: 7948 - The use of status code 303 "See Other" has been deprecated 7949 as it does not make sense to use in RTSP. 7951 - When sending response 451 and 458 the response body should 7952 contain the offending parameters. 7954 - Clarification on when a 3rr redirect status code can be 7955 received has been added. This includes receiving 3rr as a 7956 result of request within a established session. This 7957 provides clarification to a previous unspecified behavior. 7959 - Removed the 250 (Low On Storage Space) status code as it 7960 only is relevant to recording which is deprecated. 7962 o The following functionality has been deprecated from the 7963 protocol: 7965 - The use of Queued Play. 7967 - The use of PLAY method for keep-alive in play state. 7969 - The RECORD and ANNOUNCE methods and all related 7970 functionality. Some of the syntax has been removed. 7972 - The possibility to use timed execution of methods with the 7973 time parameter in the Range header. 7975 - The description on how rtspu works is not part of the core 7976 specification and will require external description. Only 7977 that it exist is defined here and some requirements for the 7978 the transport is provided. 7980 o The following changes has been made in relation to methods: 7982 - The OPTIONS method has been clarified with regards to the 7983 use of the Public and Allow headers. 7985 - The RECORD and ANNOUNCE methods are removed as they are 7986 lacking implementation and not considered necessary in the 7987 core specification. Any work on these methods should be done 7988 as a extension document to RTSP. 7990 - Added text clarifying the usage of SET_PARAMETER for keep- 7991 alive and usage without any body. 7993 o Wrote a new section about how to setup different media 7994 transport alternatives and their profiles, and lower layer 7995 protocols. This resulted that the appendix on RTP interaction 7996 was moved there instead in the part describing RTP. The 7997 section also includes guidelines what to think of when writing 7998 usage guidelines for new protocols and profiles. 8000 o Added a new section describing the available mechanisms to 8001 determine if functionality is supported, called "Capability 8002 Handling". Renamed option-tags to feature-tags. 8004 o Added a contributors section with people who has contribute 8005 actual text to the specification. 8007 o Added a section Use Cases that describes the major use cases 8008 for RTSP. 8010 o Clarified the usage of a=range and how to indicate live 8011 content that are not seekable with this header. 8013 o Text specifying the special behavior of PLAY for live content. 8015 H.1 Changes needing to be updated 8017 o The minimal implementation specification has been changed: 8019 - Required Timestamp, Via, and Unsupported headers for a minimal 8020 server implementation. 8022 - Recommended that Cache-Control, Expires and Date headers be 8023 supported by server implementations. 8025 I Author Addresses 8027 Henning Schulzrinne 8028 Dept. of Computer Science 8029 Columbia University 8030 1214 Amsterdam Avenue 8031 New York, NY 10027 8032 USA 8033 electronic mail: schulzrinne@cs.columbia.edu 8035 Anup Rao 8036 Cisco 8037 USA 8038 electronic mail: anrao@cisco.com 8040 Robert Lanphier 8041 RealNetworks 8042 P.O. Box 91123 8043 Seattle, WA 98111-9223 8044 USA 8045 electronic mail: robla@real.com 8047 Magnus Westerlund 8048 Ericsson AB, EAB/TVA/A 8049 Torshamsgatan 23 8050 SE-164 80 STOCKHOLM 8051 SWEDEN 8052 electronic mail: magnus.westerlund@ericsson.com 8054 Aravind Narasimhan 8055 Overture Computing Corp., 8056 East Windsor, NJ 08520 8057 USA 8058 electronic mail: aravind.narasimhan@gmail.com 8060 J Contributors 8062 The following people have made written contributions that were 8063 included in the specification: 8065 o Tom Marshall contributed text on the usage of 3rr status 8066 codes. 8068 o Thomas Zheng contributed text on the usage of the Range in 8069 PLAY responses. 8071 o Sean Sheedy contributed text on the timeout behavior of RTSP 8072 messages and connections, and the 463 status code. 8074 o Fredrik Lindholm contributed text about the RTSP security 8075 framework. 8077 The following people have provided detailed comments on updated 8078 versions of this specification: 8080 o Stephan Wenger 8082 K Acknowledgements 8084 This draft is based on the functionality of the original RTSP draft 8085 submitted in October 1996. It also borrows format and descriptions 8086 from HTTP/1.1. 8088 This document has benefited greatly from the comments of all those 8089 participating in the MMUSIC-WG. In addition to those already 8090 mentioned, the following individuals have contributed to this 8091 specification: 8093 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 8094 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 8095 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 8096 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 8097 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 8098 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 8099 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 8100 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 8101 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 8102 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 8103 Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, 8104 Jae-Hwan Kim and Mela Martti. 8106 L Normative References 8108 [1] M. Handley and V. Jacobson, "SDP: session description protocol," 8109 RFC 2327, Internet Engineering Task Force, Apr. 1998. 8111 [2] H. Schulzrinne and S. Casner, "RTP profile for audio and video 8112 conferences with minimal control," RFC 3551, Internet Engineering 8113 Task Force, July 2003. 8115 [3] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 8116 J. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- 8117 HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999. 8119 [4] "Augmented BNF for syntax specifications: ABNF," RFC 2234, 8120 Internet Engineering Task Force, Nov. 1997. 8122 [5] S. Bradner, "Key words for use in RFCs to indicate requirement 8123 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 8125 [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, 8126 Internet Engineering Task Force, Jan. 1999. 8128 [7] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. J. 8129 Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and 8130 digest access authentication," RFC 2617, Internet Engineering Task 8131 Force, June 1999. 8133 [8] J. B. Postel, "User datagram protocol," RFC 768, Internet 8134 Engineering Task Force, Aug. 1980. 8136 [9] J. B. Postel, "Transmission control protocol," RFC 793, Internet 8137 Engineering Task Force, Sept. 1981. 8139 [10] R. F. T. Berners-Lee and L. Masinter, "Uniform resource 8140 identifier (uri): Generic syntax," RFC 3986, Internet Engineering 8141 Task Force, Jan. 2005. 8143 [11] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, 8144 Internet Engineering Task Force, Apr. 1996. 8146 [12] R. Hinden, B. E. Carpenter, and L. Masinter, "Format for literal 8147 IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force, 8148 Dec. 1999. 8150 [13] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 8151 2279, Internet Engineering Task Force, Jan. 1998. 8153 [14] NIST, "Fips pub 180-1:secure hash standard," tech. rep., 8154 National Institute of Standards and Technology, Apr. 1995. 8156 [15] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 8157 public key infrastructure certificate and certificate revocation list 8158 (CRL) profile," RFC 3280, Internet Engineering Task Force, Apr. 2002. 8160 [16] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 8161 a transport protocol for real-time applications," RFC 3550, Internet 8162 Engineering Task Force, July 2003. 8164 [17] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering 8165 Task Force, May 2000. 8167 [18] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. 8168 Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, 8169 Internet Engineering Task Force, Jan. 1997. 8171 [19] T. Narten and H. Alvestrand, "Guidelines for writing an IANA 8172 considerations section in RFCs," RFC 2434, Internet Engineering Task 8173 Force, Oct. 1998. 8175 [20] e. a. J. Ott, "Extended rtp profile for rtcp-based feedback 8176 (rtp/avpf)," internet draft, Internet Engineering Task Force, Aug. 8177 2004. Work in progress. 8179 [21] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, 8180 "The secure real-time transport protocol (SRTP)," RFC 3711, Internet 8181 Engineering Task Force, Mar. 2004. 8183 [22] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in 8184 session description protocol (SDP)," RFC 3266, Internet Engineering 8185 Task Force, June 2002. 8187 [23] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6) 8188 addressing architecture," RFC 3513, Internet Engineering Task Force, 8189 Apr. 2003. 8191 M Informative References 8193 [24] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 8194 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 8195 1998. 8197 [25] T. Z. M. Westerlund, "How to make real-time streaming protocol 8198 (rtsp) traverse network address translators (nat) and interact with 8199 firewalls.," internet draft, Internet Engineering Task Force, Feb. 8200 2004. Work in progress. 8202 [26] F. Yergeau, G. Nicol, G. C. Adams, and M. Duerst, 8203 "Internationalization of the hypertext markup language," RFC 2070, 8204 Internet Engineering Task Force, Jan. 1997. 8206 [27] H. Schulzrinne, "A comprehensive multimedia control architecture 8207 for the Internet," in Proc. International Workshop on Network and 8208 Operating System Support for Digital Audio and Video (NOSSDAV), (St. 8209 Louis, Missouri), May 1997. 8211 [28] International Telecommunication Union, "Visual telephone systems 8212 and equipment for local area networks which provide a non-guaranteed 8213 quality of service," Recommendation H.323, Telecommunication 8214 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 8216 [29] P. McMahon, "GSS-API authentication method for SOCKS version 5," 8217 RFC 1961, Internet Engineering Task Force, June 1996. 8219 [30] J. Miller, P. Resnick, and D. Singer, "Rating services and 8220 rating systems (and their machine readable descriptions)," 8221 Recommendation REC-PICS-services-961031, W3C (World Wide Web 8222 Consortium), Boston, Massachusetts, Oct. 1996. 8224 [31] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 8225 distribution label syntax and communication protocols," 8226 Recommendation REC-PICS-labels-961031, W3C (World Wide Web 8227 Consortium), Boston, Massachusetts, Oct. 1996. 8229 [32] D. L. Mills, "Network time protocol (version 3) specification, 8230 implementation," RFC 1305, Internet Engineering Task Force, Mar. 8231 1992. 8233 [33] ISO/IEC, "Information technology -- generic coding of moving 8234 pictures and associated audio informaiton -- part 6: extension for 8235 digital storage media and control," Draft International Standard ISO 8236 13818-6, International Organization for Standardization ISO/IEC 8237 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 8239 [34] ISO/IEC, "Data elements and interchange formats -- information 8240 interchange -- representation of dates and times," Published standard 8241 ISO 8601, International Organization for Standardization ISO/IEC, 8242 Geneva, Switzerland, Dec. 2000. 8244 [35] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data 8245 encodings," RFC 3548, Internet Engineering Task Force, July 2003. 8247 [36] Third Generation Partnership Project (3GPP), "Transparent end- 8248 to-end packet-switched streaming service (pss); protocols and 8249 codecs," Technical Specification 26.234, Third Generation Partnership 8250 Project (3GPP), Dec. 2002. 8252 [37] D. Yon, "Connection-oriented media transport in sdp," internet 8253 draft, Internet Engineering Task Force, Mar. 2003. Work in progress. 8255 [38] J. Lazzaro, "Framing rtp and rtcp packets over connection- 8256 oriented transport," internet draft, Internet Engineering Task Force, 8257 Oct. 2003. Work in progress. 8259 [39] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, 8260 "Grouping of media lines in the session description protocol (SDP)," 8261 RFC 3388, Internet Engineering Task Force, Dec. 2002. 8263 [40] "Requirements for Internet hosts - application and support," RFC 8264 1123, Internet Engineering Task Force, Oct. 1989. 8266 [41] R. Braden, "T/TCP -- TCP extensions for transactions functional 8267 specification," RFC 1644, Internet Engineering Task Force, July 1994. 8269 [42] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 8270 Reading, Massachusetts: Addison-Wesley, 1994. 8272 IPR Notice 8274 The IETF takes no position regarding the validity or scope of any 8275 Intellectual Property Rights or other rights that might be claimed to 8276 pertain to the implementation or use of the technology described in 8277 this document or the extent to which any license under such rights 8278 might or might not be available; nor does it represent that it has 8279 made any independent effort to identify any such rights. Information 8280 on the procedures with respect to rights in RFC documents can be 8281 found in BCP 78 and BCP 79. 8283 Copies of IPR disclosures made to the IETF Secretariat and any 8284 assurances of licenses to be made available, or the result of an 8285 attempt made to obtain a general license or permission for the use of 8286 such proprietary rights by implementers or users of this 8287 specification can be obtained from the IETF on-line IPR repository at 8288 http://www.ietf.org/ipr. 8290 The IETF invites any interested party to bring to its attention any 8291 copyrights, patents or patent applications, or other proprietary 8292 rights that may cover technology that may be required to implement 8293 this standard. Please address the information to the IETF at ietf- 8294 ipr@ietf.org. 8296 Full Copyright Statement 8298 Copyright (C) The Internet Society (2005). This document is subject 8299 to the rights, licenses and restrictions contained in BCP 78, and 8300 except as set forth therein, the authors retain all their rights. 8302 This document and the information contained herein are provided on an 8303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 8304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 8305 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 8306 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 8307 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 8308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.