idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 31) 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 1673 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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 2 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 682: '... A server SHOULD implement all heade...' RFC 2119 keyword, line 705: '... SHOULD list the methods it s...' RFC 2119 keyword, line 882: '... given, port 554 SHALL be assumed. The...' RFC 2119 keyword, line 887: '...22 is registered and SHALL be assumed....' RFC 2119 keyword, line 889: '...ddresses in URLs SHOULD be avoided whe...' (422 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1360 has weird spacing: '...s State all...' == Line 1364 has weird spacing: '...Allowed all...' == Line 1365 has weird spacing: '...Allowed all...' == Line 1707 has weird spacing: '...mmended rec...' == Line 1710 has weird spacing: '...mmended rec...' == (17 more instances...) == 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 'MUST not' in this paragraph: The name of the feature MUST follow these rules: The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST not contain any spaces, or control characters. The registration SHALL indicate if the feature tag applies to servers only, proxies only or both server and proxies. Any proprietary feature SHALL have as the first part of the name a vendor tag, which identifies the organization. == 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 shall 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 shall assume that the session has been 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. 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? '1' on line 6912 looks like a reference -- Missing reference section? '20' on line 6982 looks like a reference -- Missing reference section? '21' on line 6987 looks like a reference -- Missing reference section? '22' on line 6990 looks like a reference -- Missing reference section? '23' on line 6993 looks like a reference -- Missing reference section? '2' on line 6917 looks like a reference -- Missing reference section? '3' on line 6920 looks like a reference -- Missing reference section? '4' on line 6924 looks like a reference -- Missing reference section? '24' on line 6996 looks like a reference -- Missing reference section? '5' on line 6927 looks like a reference -- Missing reference section? '6' on line 6931 looks like a reference -- Missing reference section? '25' on line 7000 looks like a reference -- Missing reference section? '12' on line 6951 looks like a reference -- Missing reference section? '26' on line 7006 looks like a reference -- Missing reference section? '7' on line 6934 looks like a reference -- Missing reference section? '8' on line 6938 looks like a reference -- Missing reference section? '27' on line 7009 looks like a reference -- Missing reference section? '9' on line 6941 looks like a reference -- Missing reference section? '28' on line 7014 looks like a reference -- Missing reference section? '29' on line 7019 looks like a reference -- Missing reference section? '30' on line 7024 looks like a reference -- Missing reference section? '31' on line 7027 looks like a reference -- Missing reference section? '32' on line 7032 looks like a reference -- Missing reference section? '10' on line 6944 looks like a reference -- Missing reference section? '11' on line 6947 looks like a reference -- Missing reference section? '13' on line 6955 looks like a reference -- Missing reference section? 'H6' on line 1186 looks like a reference -- Missing reference section? '14' on line 6958 looks like a reference -- Missing reference section? '33' on line 7037 looks like a reference -- Missing reference section? '34' on line 7040 looks like a reference -- Missing reference section? 'H10' on line 2616 looks like a reference -- Missing reference section? '15' on line 6962 looks like a reference -- Missing reference section? 'H15' on line 5051 looks like a reference -- Missing reference section? '16' on line 6965 looks like a reference -- Missing reference section? '17' on line 6969 looks like a reference -- Missing reference section? '35' on line 7043 looks like a reference -- Missing reference section? '36' on line 7048 looks like a reference -- Missing reference section? '37' on line 7051 looks like a reference -- Missing reference section? '38' on line 7055 looks like a reference -- Missing reference section? '18' on line 6973 looks like a reference -- Missing reference section? '19' on line 6977 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 43 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/Columbia U. 4 draft-ietf-mmusic-rfc2326bis-06.txt A. Rao/Cisco 5 February 16, 2004 R. Lanphier/RealNetworks 6 Expires: August, 2004 M. Westerlund/Ericsson 7 A. Narasimhan/Sun 9 Real Time Streaming Protocol (RTSP) 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memorandum is a revision of RFC 2326, which is currently a 35 Proposed Standard. 37 The Real Time Streaming Protocol, or RTSP, is an application-level 38 protocol for control over the delivery of data with real-time 39 properties. RTSP provides an extensible framework to enable 40 controlled, on-demand delivery of real-time data, such as audio and 41 video. Sources of data can include both live data feeds and stored 42 clips. This protocol is intended to control multiple data delivery 43 sessions, provide a means for choosing delivery channels such as UDP, 44 multicast UDP and TCP, and provide a means for choosing delivery 45 mechanisms based upon RTP (RFC 3550). 47 Table of Contents 49 1 Introduction ........................................ 8 50 1.1 The Update of the RTSP Specification ................ 8 51 1.2 Purpose ............................................. 9 52 1.3 Notational Conventions .............................. 11 53 1.4 Terminology ......................................... 11 54 1.5 Protocol Properties ................................. 14 55 1.6 Extending RTSP ...................................... 16 56 1.7 Overall Operation ................................... 17 57 1.8 RTSP States ......................................... 18 58 1.9 Relationship with Other Protocols ................... 19 59 2 RTSP Use Cases ...................................... 19 60 2.1 On-demand Playback of Stored Content ................ 20 61 2.2 Unicast distribution of Live Content ................ 20 62 2.3 Inviting RTSP on-demand servers into a multicast 63 group ............................................... 20 64 2.4 On-demand Playback using Multicast .................. 20 65 3 Protocol Parameters ................................. 20 66 3.1 RTSP Version ........................................ 20 67 3.2 RTSP URL ............................................ 20 68 3.3 Session Identifiers ................................. 22 69 3.4 SMPTE Relative Timestamps ........................... 22 70 3.5 Normal Play Time .................................... 22 71 3.6 Absolute Time ....................................... 23 72 3.7 Feature-tags ........................................ 23 73 4 RTSP Message ........................................ 24 74 4.1 Message Types ....................................... 24 75 4.2 Message Headers ..................................... 24 76 4.3 Message Body ........................................ 25 77 4.4 Message Length ...................................... 25 78 5 General Header Fields ............................... 25 79 6 Request ............................................. 25 80 6.1 Request Line ........................................ 26 81 6.2 Request Header Fields ............................... 27 82 7 Response ............................................ 27 83 7.1 Status-Line ......................................... 28 84 7.1.1 Status Code and Reason Phrase ....................... 28 85 7.1.2 Response Header Fields .............................. 29 86 8 Entity .............................................. 30 87 8.1 Entity Header Fields ................................ 32 88 8.2 Entity Body ......................................... 32 89 9 Connections ......................................... 32 90 9.1 Pipelining .......................................... 33 91 9.2 Reliability and Acknowledgements .................... 33 92 9.3 Unreliable Transport ................................ 34 93 9.4 The usage of connections ............................ 34 94 9.5 Timing Out RTSP messages ............................ 36 95 9.6 Use of IPv6 ......................................... 36 96 10 Capability Handling ................................. 37 97 11 Method Definitions .................................. 38 98 11.1 OPTIONS ............................................. 39 99 11.2 DESCRIBE ............................................ 40 100 11.3 SETUP ............................................... 42 101 11.4 PLAY ................................................ 44 102 11.5 PAUSE ............................................... 48 103 11.6 TEARDOWN ............................................ 51 104 11.7 GET_PARAMETER ....................................... 52 105 11.8 SET_PARAMETER ....................................... 53 106 11.9 REDIRECT ............................................ 55 107 11.10 PING ................................................ 56 108 12 Embedded (Interleaved) Binary Data .................. 57 109 13 Status Code Definitions ............................. 59 110 13.1 Success 1xx ......................................... 59 111 13.1.1 100 Continue ........................................ 59 112 13.2 Success 2xx ......................................... 59 113 13.3 Redirection 3xx ..................................... 59 114 13.3.1 TBW ................................................. 60 115 13.3.2 301 Moved Permanently ............................... 60 116 13.3.3 302 Found ........................................... 60 117 13.3.4 303 See Other ....................................... 60 118 13.3.5 304 Not Modified .................................... 60 119 13.3.6 305 Use Proxy ....................................... 61 120 13.4 Client Error 4xx .................................... 61 121 13.4.1 400 Bad Request ..................................... 61 122 13.4.2 405 Method Not Allowed .............................. 61 123 13.4.3 451 Parameter Not Understood ........................ 61 124 13.4.4 452 reserved ........................................ 61 125 13.4.5 453 Not Enough Bandwidth ............................ 61 126 13.4.6 454 Session Not Found ............................... 62 127 13.4.7 455 Method Not Valid in This State .................. 62 128 13.4.8 456 Header Field Not Valid for Resource ............. 62 129 13.4.9 457 Invalid Range ................................... 62 130 13.4.10 458 Parameter Is Read-Only .......................... 62 131 13.4.11 459 Aggregate Operation Not Allowed ................. 62 132 13.4.12 460 Only Aggregate Operation Allowed ................ 62 133 13.4.13 461 Unsupported Transport ........................... 62 134 13.4.14 462 Destination Unreachable ......................... 63 135 13.5 Server Error 5xx .................................... 63 136 13.5.1 551 Option not supported ............................ 63 137 14 Header Field Definitions ............................ 63 138 14.1 Accept .............................................. 65 139 14.2 Accept-Encoding ..................................... 65 140 14.3 Accept-Language ..................................... 66 141 14.4 Accept-Ranges ....................................... 66 142 14.5 Allow ............................................... 66 143 14.6 Authorization ....................................... 66 144 14.7 Bandwidth ........................................... 66 145 14.8 Blocksize ........................................... 68 146 14.9 Cache-Control ....................................... 70 147 14.10 Connection .......................................... 72 148 14.11 Content-Base ........................................ 73 149 14.12 Content-Encoding .................................... 73 150 14.13 Content-Language .................................... 73 151 14.14 Content-Length ...................................... 73 152 14.15 Content-Location .................................... 73 153 14.16 Content-Type ........................................ 73 154 14.17 CSeq ................................................ 73 155 14.18 Date ................................................ 74 156 14.19 Expires ............................................. 74 157 14.20 From ................................................ 75 158 14.21 Host ................................................ 75 159 14.22 If-Match ............................................ 75 160 14.23 If-Modified-Since ................................... 75 161 14.24 Last-Modified ....................................... 76 162 14.25 Location ............................................ 76 163 14.26 Proxy-Authenticate .................................. 76 164 14.27 Proxy-Require ....................................... 76 165 14.28 Public .............................................. 77 166 14.29 Range ............................................... 77 167 14.30 Referer ............................................. 79 168 14.31 Retry-After ......................................... 79 169 14.32 Require ............................................. 79 170 14.33 RTP-Info ............................................ 80 171 14.34 Scale ............................................... 82 172 14.35 Speed ............................................... 82 173 14.36 Server .............................................. 83 174 14.37 Session ............................................. 83 175 14.38 Supported ........................................... 85 176 14.39 Timestamp ........................................... 86 177 14.40 Transport ........................................... 86 178 14.41 Unsupported ......................................... 92 179 14.42 User-Agent .......................................... 92 180 14.43 Vary ................................................ 93 181 14.44 Via ................................................. 93 182 14.45 WWW-Authenticate .................................... 93 183 15 Caching ............................................. 93 184 16 Examples ............................................ 94 185 16.1 Media on Demand (Unicast) ........................... 94 186 16.2 Streaming of a Container file ....................... 97 187 16.3 Single Stream Container Files ....................... 100 188 16.4 Live Media Presentation Using Multicast ............. 101 189 16.5 Capability Negotiation .............................. 103 190 17 Syntax .............................................. 104 191 17.1 Base Syntax ......................................... 104 192 17.2 RTSP Protocol Definition ............................ 105 193 17.2.1 Generic Protocol elements ........................... 105 194 17.2.2 Message Syntax ...................................... 106 195 17.2.3 Header Syntax ....................................... 110 196 18 Security Considerations ............................. 112 197 19 IANA Considerations ................................. 115 198 19.1 Feature-tags ........................................ 115 199 19.1.1 Description ......................................... 115 200 19.1.2 Registering New Feature-tags with IANA .............. 116 201 19.1.3 Registered entries .................................. 116 202 19.2 RTSP Methods ........................................ 116 203 19.2.1 Description ......................................... 116 204 19.2.2 Registering New Methods with IANA ................... 116 205 19.2.3 Registered Entries .................................. 117 206 19.3 RTSP Status Codes ................................... 117 207 19.3.1 Description ......................................... 117 208 19.3.2 Registering New Status Codes with IANA .............. 117 209 19.3.3 Registered Entries .................................. 117 210 19.4 RTSP Headers ........................................ 117 211 19.4.1 Description ......................................... 117 212 19.4.2 Registering New Headers with IANA ................... 118 213 19.4.3 Registered entries .................................. 118 214 19.5 Transport Header registries ......................... 118 215 19.5.1 Transport Protocols ................................. 119 216 19.5.2 Profile ............................................. 119 217 19.5.3 Lower Transport ..................................... 119 218 19.5.4 Transport modes ..................................... 120 219 19.6 Cache Directive Extensions .......................... 120 220 19.7 SDP attributes ...................................... 121 221 A RTSP Protocol State Machine ......................... 122 222 A.1 States .............................................. 122 223 A.2 State variables ..................................... 122 224 A.3 Abbreviations ....................................... 122 225 A.4 State Tables ........................................ 123 226 B Media Transport Alternatives ........................ 125 227 B.1 RTP ................................................. 126 228 B.1.1 AVP ................................................. 126 229 B.1.2 AVP/UDP ............................................. 127 230 B.1.3 AVP/TCP ............................................. 128 231 B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 129 232 B.1.5 Handling RTP Timestamps after PAUSE ................. 131 233 B.1.6 RTSP / RTP Integration .............................. 133 234 B.1.7 Scaling with RTP .................................... 133 235 B.1.8 Maintaining NPT synchronization with RTP 236 timesatmps .......................................... 133 237 B.1.9 Continuous Audio .................................... 134 238 B.1.10 Multiple Sources in an RTP Session .................. 134 239 B.1.11 Usage of SSRCs and the RTCP BYE Message During a 240 RTSP Session ........................................ 134 241 B.2 Future Additions .................................... 134 242 C Use of SDP for RTSP Session Descriptions ............ 135 243 C.1 Definitions ......................................... 135 244 C.1.1 Control URL ......................................... 135 245 C.1.2 Media Streams ....................................... 136 246 C.1.3 Payload Type(s) ..................................... 137 247 C.1.4 Format-Specific Parameters .......................... 137 248 C.1.5 Range of Presentation ............................... 137 249 C.1.6 Time of Availability ................................ 138 250 C.1.7 Connection Information .............................. 138 251 C.1.8 Entity Tag .......................................... 139 252 C.2 Aggregate Control Not Available ..................... 139 253 C.3 Aggregate Control Available ......................... 140 254 C.4 RTSP external SDP delivery .......................... 141 255 D Minimal RTSP implementation ......................... 141 256 D.1 Client .............................................. 141 257 D.1.1 Basic Playback ...................................... 142 258 D.1.2 Authentication-enabled .............................. 142 259 D.2 Server .............................................. 143 260 D.2.1 Basic Playback ...................................... 143 261 D.2.2 Authentication-enabled .............................. 144 262 E Open Issues ......................................... 144 263 F Changes ............................................. 145 264 G Author Addresses .................................... 151 265 H Contributors ........................................ 152 266 I Acknowledgements .................................... 152 267 J Normative References ................................ 152 268 K Informative References .............................. 154 270 1 Introduction 272 1.1 The Update of the RTSP Specification 274 This is the draft to an update of RTSP which is currently a proposed | 275 standard defined in RFC 2326 [1]. Many flaws have been found in RTSP | 276 since it was published. While this draft tries to address the flaws, | 277 not all known issues have been resolved. However in this version only | 278 a few remains, please see Open Issues in section E. 280 The goal of the current work on RTSP is to progress it to draft 281 standard status. Whether this is possible without first republishing 282 RTSP as a proposed standard depends on the changes necessary to make 283 the protocol work. The list of changes in appendix F indicates the 284 issues that have already been addressed. The currently open issues 285 are listed in appendix E. 287 There is also a list of reported bugs available at 288 "http://rtspspec.sourceforge.net". These bugs should be taken into 289 account when reading this specification. While a lot of these bugs 290 are addressed, not all are yet accounted for in this specification. 291 Input on the unresolved bugs and other issues can be sent via e-mail 292 to the MMUSIC WG's mailing list mmusic@ietf.org and the authors. 294 Not all of the contents of RFC 2326 are part of this draft. In an | 295 attempt to prevent the draft from exploding in size, the | 296 specification has been reduced and split. The content of this draft | 297 is the core specification of the protocol. It contains the general | 298 idea behind RTSP and the basic functionality necessary to establish | 299 an on-demand play-back session. It also contains the mechanisms for | 300 extending the protocol. Any other functionality will be published as | 301 extension documents. The Working group currently is working on: | 303 o NAT and FW traversal mechanisms for RTSP are described in a | 304 document called "How to make Real-Time Streaming Protocol | 305 (RTSP) traverse Network Address Translators (NAT) and interact | 306 with Firewalls." [20]. | 308 There have also been discussion or proposals about the following | 309 extensions to RTSP: | 311 o Mute and Unmute Extension [21]. | 313 o RTSP Stream Switching [22]. | 315 o Live Streaming Relays [23]. | 317 o Transport security for RTSP messages (rtsps). | 318 o Unreliable transport of RTSP messages (rtspu). | 320 o The Record functionality. | 322 o A text body type with suitable syntax for basic parameters to | 323 be used in SET_PARAMETER, and GET_PARAMETER. Including IANA | 324 registry within the defined name space. | 326 o A RTSP MIB. | 328 1.2 Purpose 330 The Real-Time Streaming Protocol (RTSP) establishes and controls 331 single or several time-synchronized streams of continuous media such 332 as audio and video. Put simply, RTSP acts as a "network remote 333 control" for multimedia servers. 335 There is no notion of a RTSP connection in the protocol. Instead, a 336 RTSP server maintains a session labelled by an identifier to 337 associate groups of media streams and their states. A RTSP session is 338 not tied to a transport-level connection such as a TCP connection. 339 During a session, a client may open and close many reliable transport 340 connections to the server to issue RTSP requests for that session. 342 This memorandum describes the use of RTSP over a reliable connection 343 based transport level protocol such as TCP. RTSP may be implemented 344 over an unreliable connectionless transport protocol such as UDP. 345 While nothing in RTSP precludes this, additional definition of this 346 problem area must be handled as an extension to the core 347 specification. 349 The mechanisms of RTSP's operation over UDP were left out 350 of this spec. because they were poorly defined in RFC 2326 351 [1] and the tradeoff in size and complexity of this spec. 352 for a small gain in a targeted problem space was not deemed 353 justifiable. 355 The set of streams to be controlled is defined by a presentation | 356 description. This memorandum does not define a format for the | 357 presentation description. However appendix C defines how SDP [2] is | 358 used for this purpose. The streams controlled by RTSP may use RTP [3] | 359 for their data transport, but the operation of RTSP does not depend | 360 on the transport mechanism used to carry continuous media. The | 361 protocol is intentionally similar in syntax and operation to HTTP/1.1 | 362 [4] so that extension mechanisms to HTTP can in most cases also be | 363 added to RTSP. However, RTSP differs in a number of important aspects | 364 from HTTP: 366 o RTSP introduces a number of new methods and has a different 367 protocol identifier. 369 o RTSP has the notion of a session built into the protocol. 371 o A RTSP server needs to maintain state by default in almost all 372 cases, as opposed to the stateless nature of HTTP. 374 o Both a RTSP server and client can issue requests. 376 o Data is usually carried out-of-band by a different protocol. 377 Session descriptions returned in a DESCRIBE response (see 378 Section 11.2) and interleaving of RTP with RTSP over TCP are 379 exceptions to this rule (see Section 12). | 381 o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO | 382 8859-1, consistent with HTML internationalization efforts | 383 [24]. 385 o The Request-URL always contains the absolute URL. Because of 386 backward compatibility with a historical blunder, HTTP/1.1 [4] 387 carries only the absolute path in the request and puts the 388 host name in a separate header field. 390 This makes "virtual hosting" easier, where a single 391 host with one IP address hosts several document trees. 393 The protocol supports the following operations: 395 Retrieval of media from media server: The client can either | 396 request a presentation description via RTSP DESCRIBE, HTTP | 397 or some other method. If the presentation is being | 398 multicast, the presentation description contains the | 399 multicast addresses and ports to be used for the continuous | 400 media. If the presentation is to be sent only to the client | 401 via unicast, the client provides the destination for | 402 security reasons. 404 Invitation of a media server to a conference: A media server can 405 be "invited" to join an existing conference to play back 406 media into the presentation. This mode is useful for 407 distributed teaching applications. Several parties in the 408 conference may take turns "pushing the remote control 409 buttons". 411 RTSP requests may be handled by proxies, tunnels and caches as in 412 HTTP/1.1 [4]. 414 1.3 Notational Conventions | 416 Since many of the definitions and syntax are identical to HTTP/1.1, | 417 this specification only points to the section where they are defined | 418 rather than copying it. For brevity, [HX.Y] is to be taken to refer | 419 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [4]). | 421 All the mechanisms specified in this document are described in both | 422 prose and the augmented Backus-Naur form (BNF) described in detail in | 423 RFC 2234 [5]. | 425 In this specification, we use indented and smaller-type paragraphs to | 426 provide background and motivation. This is intended to give readers | 427 who were not involved with the formulation of the specification an | 428 understanding of why things are the way that they are in RTSP. | 430 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | 431 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | 432 document are to be interpreted as described in RFC 2119 [6]. | 434 This specification uses the word "Unspecified" to indicate | 435 functionality or features that are not defined in this specification, | 436 and therefore can't be used. Any such functionality or feature can in | 437 the future be evaluated and if technical sound be defined in | 438 specification extending RTSP. 440 1.4 Terminology 442 Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not 443 listed here are defined as in HTTP/1.1. 445 Aggregate control: The concept of controlling multiple streams 446 using a single timeline, generally maintained by the 447 server. A client, for example, uses aggregate control when 448 it issues a single play or pause message to simultaneously 449 control both the audio and video in a movie. 451 Aggregate control URL: The URL used in a RTSP request to refer | 452 to and control an aggregated session. It normally, but not | 453 always, corresponds to the presentation URL specified in | 454 the session description. See Section 11.3 for more | 455 information. 457 Conference: a multiparty, multimedia presentation, where "multi" 458 implies greater than or equal to one. 460 Client: The client requests media service from the media server. 462 Connection: A transport layer virtual circuit established 463 between two programs for the purpose of communication. 465 Container file: A file which may contain multiple media streams 466 which often comprise a presentation when played together. 467 RTSP servers may offer aggregate control on these files, 468 though the concept of a container file is not embedded in 469 the protocol. 471 Continuous media: Data where there is a timing relationship 472 between source and sink; that is, the sink must reproduce 473 the timing relationship that existed at the source. The 474 most common examples of continuous media are audio and 475 motion video. Continuous media can be real-time 476 (interactive), where there is a "tight" timing relationship 477 between source and sink, or streaming (playback), where the 478 relationship is less strict. 480 Entity: The information transferred as the payload of a request 481 or response. An entity consists of meta-information in the 482 form of entity-header fields and content in the form of an 483 entity-body, as described in Section 8. 485 Feature-tag: A tag representing a certain set of functionality, 486 i.e. a feature. 488 Live: Normally used to describe a presentation or session with | 489 media coming from ongoing event. This generally results in | 490 that the session has a unbound or only loosely defined | 491 duration, and that no seek operations are possible. 493 Media initialization: Datatype/codec specific initialization. 494 This includes such things as clockrates, color tables, etc. 495 Any transport-independent information which is required by 496 a client for playback of a media stream occurs in the media 497 initialization phase of stream setup. 499 Media parameter: Parameter specific to a media type that may be 500 changed before or during stream playback. 502 Media server: The server providing playback services for one or 503 more media streams. Different media streams within a 504 presentation may originate from different media servers. A 505 media server may reside on the same or a different host as 506 the web server the presentation is invoked from. 508 Media server indirection: Redirection of a media client to a 509 different media server. 511 (Media) stream: A single media instance, e.g., an audio stream 512 or a video stream as well as a single whiteboard or shared 513 application group. When using RTP, a stream consists of all 514 RTP and RTCP packets created by a source within an RTP 515 session. This is equivalent to the definition of a DSM-CC 516 stream([25]). 518 Message: The basic unit of RTSP communication, consisting of a 519 structured sequence of octets matching the syntax defined 520 in Section 17 and transmitted via a connection or a 521 connectionless protocol. 523 Non-Aggregated Control: Control of a single media stream. Only 524 possible in RTSP sessions with a single media. 526 Participant: Member of a conference. A participant may be a 527 machine, e.g., a playback server. 529 Presentation: A set of one or more streams presented to the 530 client as a complete media feed, using a presentation 531 description as defined below. In most cases in the RTSP 532 context, this implies aggregate control of those streams, 533 but does not have to. 535 Presentation description: A presentation description contains 536 information about one or more media streams within a 537 presentation, such as the set of encodings, network 538 addresses and information about the content. Other IETF 539 protocols such as SDP (RFC 2327 [2]) use the term "session" 540 for a presentation. The presentation description may take 541 several different formats, including but not limited to the 542 session description format SDP. 544 Response: A RTSP response. If an HTTP response is meant, that is 545 indicated explicitly. 547 Request: A RTSP request. If an HTTP request is meant, that is 548 indicated explicitly. 550 Request URL: The URL used in a request to indicate the resource | 551 which the request shall be performed on. 553 RTSP session: A stateful abstraction upon which the main control 554 methods of RTSP operate. A RTSP session is a server entity; 555 it is created, maintained and destroyed by the server. It 556 is established by a RTSP server upon the completion of a 557 successful SETUP request (when 200 OK response is sent) and 558 is labelled by a session identifier at that time. The 559 session exists until timed out by the server or explicitly 560 removed by a TEARDOWN request. A RTSP session is also a 561 stateful entity; a RTSP server maintains an explicit 562 session state machine (see Appendix A) where most state 563 transitions are triggered by client requests. The existence 564 of a session implies the existence of state about the 565 session's media streams and their respective transport 566 mechanisms. A given session can have zero or more media 567 streams associated with it. A RTSP server uses the session 568 to aggregate control over multiple media streams. 570 Transport initialization: The negotiation of transport 571 information (e.g., port numbers, transport protocols) 572 between the client and the server. 574 URI: Universal Resource Identifier, see RFC 2396 [12]. In RTSP | 575 the used URIs are as general rule in fact URL's as they | 576 gives an location for the resource. Therefore although RTSP | 577 URLs are a subset of URIs, they will be refered as URLs. | 579 URL: Universal Resource Locator, is an URI which identifies the | 580 resource through its primary access mechanism, rather than | 581 identifying the resource by name or by some other | 582 attribute(s) of that resource. 584 1.5 Protocol Properties 586 RTSP has the following properties: 588 Extendable: New methods and parameters can be easily added to 589 RTSP. 591 Easy to parse: RTSP can be parsed by standard HTTP or MIME 592 parsers. 594 Secure: RTSP re-uses web security mechanisms, either at the 595 transport level (TLS, RFC 2246 [26]) or within the protocol 596 itself. All HTTP authentication mechanisms such as basic 597 (RFC 2616 [4]) and digest authentication (RFC 2617 [7]) are 598 directly applicable. 600 Transport-independent: RTSP does not preclude the use of an | 601 unreliable datagram protocol (UDP) (RFC 768 [8]), a | 602 reliable datagram protocol (RDP, RFC 1151, not widely used | 603 [27]) as it would be possible to implement application- | 604 level reliability. The use of a connectionless datagram | 605 protocol such as UDP or RDP requires additional definition | 606 that may be provided as extensions to the core RTSP | 607 specification. The usage of the reliable stream protocol | 608 TCP (RFC 793 [9]) is what is currently defined as transport | 609 protocol of RTSP messages. 611 Multi-server capable: Each media stream within a presentation 612 can reside on a different server. The client automatically 613 establishes several concurrent control sessions with the 614 different media servers. Media synchronization is 615 performed at the transport level. 617 Separation of stream control and conference initiation: Stream 618 control is divorced from inviting a media server to a 619 conference. In particular, SIP [28] or H.323 [29] may be 620 used to invite a server to a conference. 622 Suitable for professional applications: RTSP supports frame- 623 level accuracy through SMPTE time stamps to allow remote 624 digital editing. 626 Presentation description neutral: The protocol does not impose a 627 particular presentation description or metafile format and 628 can convey the type of format to be used. However, the 629 presentation description must contain at least one RTSP 630 URL. 632 Proxy and firewall friendly: The protocol should be readily | 633 handled by both application and transport-layer (SOCKS | 634 [30]) firewalls. A firewall may need to understand the | 635 SETUP method to open a "hole" for the media stream. 637 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so 638 that the existing infrastructure can be reused. This 639 infrastructure includes PICS (Platform for Internet Content 640 Selection [31,32]) for associating labels with content. 641 However, RTSP does not just add methods to HTTP since the 642 controlling continuous media requires server state in most 643 cases. 645 Appropriate server control: If a client can start a stream, it 646 must be able to stop a stream. Servers should not start 647 streaming to clients in such a way that clients cannot stop 648 the stream. 650 Transport negotiation: The client can negotiate the transport 651 method prior to actually needing to process a continuous 652 media stream. 654 Capability negotiation: If basic features are disabled, there 655 must be some clean mechanism for the client to determine 656 which methods are not going to be implemented. This allows 657 clients to present the appropriate user interface. For 658 example, if seeking is not allowed, the user interface must 659 be able to disallow moving a sliding position indicator. 661 An earlier requirement in RTSP was multi-client capability. 662 However, it was determined that a better approach was to 663 make sure that the protocol is easily extensible to the 664 multi-client scenario. Stream identifiers can be used by 665 several control streams, so that "passing the remote" would 666 be possible. The protocol would not address how several 667 clients negotiate access; this is left to either a "social 668 protocol" or some other floor control mechanism. 670 1.6 Extending RTSP 672 Since not all media servers have the same functionality, media 673 servers by necessity will support different sets of requests. For 674 example: 676 o A server may not be capable of seeking (absolute positioning) 677 if it is to support live events only. 679 o Some servers may not support setting stream parameters and 680 thus not support GET_PARAMETER and SET_PARAMETER. 682 A server SHOULD implement all header fields described in Section 14. 684 It is up to the creators of presentation descriptions not to ask the 685 impossible of a server. This situation is similar in HTTP/1.1 [4], 686 where the methods described in [H19.5] are not likely to be supported 687 across all servers. 689 RTSP can be extended in three ways, listed here in order of the 690 magnitude of changes supported: 692 o Existing methods can be extended with new parameters, e.g. | 693 headers, as long as these parameters can be safely ignored by | 694 the recipient. (This is equivalent to adding new parameters to | 695 an HTML tag.) If the client needs negative acknowledgement | 696 when a method extension is not supported, a tag corresponding | 697 to the extension may be added in the Require: field (see | 698 Section 14.32). 700 o New methods can be added. If the recipient of the message does 701 not understand the request, it responds with error code 501 702 (Not Implemented) and the sender should not attempt to use 703 this method again. A client may also use the OPTIONS method 704 to inquire about methods supported by the server. The server 705 SHOULD list the methods it supports using the Public response 706 header. 708 o A new version of the protocol can be defined, allowing almost 709 all aspects (except the position of the protocol version 710 number) to change. 712 The basic capability discovery mechanism can be used to both discover 713 support for a certain feature and to ensure that a feature is 714 available when performing a request. For detailed explanation of this 715 see chapter 10. 717 1.7 Overall Operation 719 Each presentation and media stream is identified by an RTSP URL. The 720 overall presentation and the properties of the media the presentation 721 is made up of are defined by a presentation description file, the 722 format of which is outside the scope of this specification. The 723 presentation description file may be obtained by the client using 724 HTTP or other means such as email and may not necessarily be stored 725 on the media server. 727 For the purposes of this specification, a presentation description is 728 assumed to describe one or more presentations, each of which 729 maintains a common time axis. For simplicity of exposition and 730 without loss of generality, it is assumed that the presentation 731 description contains exactly one such presentation. A presentation 732 may contain several media streams. 734 The presentation description file contains a description of the media 735 streams making up the presentation, including their encodings, 736 language, and other parameters that enable the client to choose the 737 most appropriate combination of media. In this presentation 738 description, each media stream that is individually controllable by 739 RTSP is identified by a RTSP URL, which points to the media server 740 handling that particular media stream and names the stream stored on 741 that server. Several media streams can be located on different 742 servers; for example, audio and video streams can be split across 743 servers for load sharing. The description also enumerates which 744 transport methods the server is capable of. 746 Besides the media parameters, the network destination address and 747 port need to be determined. Several modes of operation can be 748 distinguished: 750 Unicast: The media is transmitted to the source of the RTSP 751 request, with the port number chosen by the client. 752 Alternatively, the media is transmitted on the same 753 reliable stream as RTSP. 755 Multicast, server chooses address: The media server picks the 756 multicast address and port. This is the typical case for a 757 live or near-media-on-demand transmission. 759 Multicast, client chooses address: If the server is to 760 participate in an existing multicast conference, the 761 multicast address, port and encryption key are given by the 762 conference description, established by means outside the 763 scope of this specification. 765 1.8 RTSP States 767 RTSP controls a stream which may be sent via a separate protocol, 768 independent of the control channel. For example, RTSP control may 769 occur on a TCP connection while the data flows via UDP. Thus, data 770 delivery continues even if no RTSP requests are received by the media 771 server. Also, during its lifetime, a single media stream may be 772 controlled by RTSP requests issued sequentially on different TCP 773 connections. Therefore, the server needs to maintain "session state" 774 to be able to correlate RTSP requests with a stream. The state 775 transitions are described in Appendix A. 777 Many methods in RTSP do not contribute to state. However, the 778 following play a central role in defining the allocation and usage of 779 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING 780 and TEARDOWN. 782 SETUP: Causes the server to allocate resources for a stream and 783 create a RTSP session. 785 PLAY: Starts data transmission on a stream allocated via SETUP. 787 PAUSE: Temporarily halts a stream without freeing server 788 resources. 790 REDIRECT: Indicates that the session should be moved to new 791 server / location 793 PING: Prevents the identified session from being timed out. 795 TEARDOWN: Frees resources associated with the stream. The RTSP 796 session ceases to exist on the server. 798 RTSP methods that contribute to state use the Session header field 799 (Section 14.37) to identify the RTSP session whose state is being 800 manipulated. The server generates session identifiers in response to 801 SETUP requests (Section 11.3). 803 1.9 Relationship with Other Protocols 805 RTSP has some overlap in functionality with HTTP. It also may 806 interact with HTTP in that the initial contact with streaming content 807 is often to be made through a web page. The current protocol 808 specification aims to allow different hand-off points between a web 809 server and the media server implementing RTSP. For example, the 810 presentation description can be retrieved using HTTP or RTSP, which 811 reduces roundtrips in web-browser-based scenarios, yet also allows 812 for standalone RTSP servers and clients which do not rely on HTTP at 813 all. However, RTSP differs fundamentally from HTTP in that most data 814 delivery takes place out-of-band in a different protocol. HTTP is an 815 asymmetric protocol where the client issues requests and the server 816 responds. In RTSP, both the media client and media server can issue 817 requests. RTSP requests are also stateful; they may set parameters 818 and continue to control a media stream long after the request has 819 been acknowledged. 821 Re-using HTTP functionality has advantages in at least two 822 areas, namely security and proxies. The requirements are 823 very similar, so having the ability to adopt HTTP work on 824 caches, proxies and authentication is valuable. 826 RTSP assumes the existence of a presentation description format that 827 can express both static and temporal properties of a presentation 828 containing several media streams. Session Description Protocol (SDP) 829 [2] is generally the format of choice; however, RTSP is not bound to 830 it. For data delivery, most real-time media will use RTP as a 831 transport protocol. While RTSP works well with RTP, it is not tied to 832 RTP. 834 2 RTSP Use Cases 835 This section describes some of the use cases RTSP can be used for. | 836 They are listed in descending order of importance in regards to | 837 ensuring that all necessary functionality is present. | 839 TODO: Fill this headings with descriptions of the use cases. | 841 2.1 On-demand Playback of Stored Content | 843 2.2 Unicast distribution of Live Content | 845 2.3 Inviting RTSP on-demand servers into a multicast group | 847 2.4 On-demand Playback using Multicast | 849 3 Protocol Parameters 851 3.1 RTSP Version 853 HTTP Specification Section [H3.1] applies, with HTTP replaced by 854 RTSP. This specification defines version 1.0 of RTSP. 856 3.2 RTSP URL 858 The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network 859 resources via the RTSP protocol. This section defines the scheme- 860 specific syntax and semantics for RTSP URLs. The RTSP URL is case 861 sensitive. 863 Informative RTSP URL syntax: 865 rtsp[u|s]://host[:port]/abspath[?query]#fragment 867 See section 17.2.1 for the formal definition of the RTSP URL syntax. 869 Note that fragment and query identifiers do not have a 870 well-defined meaning at this time, i.e. their usage is 871 unspecified, with the interpretation left to the RTSP 872 server. 874 The URL scheme rtsp requires that commands are issued via a reliable 875 protocol (within the Internet, TCP), while the scheme rtspu is 876 intended to identify RTSP over an unreliable protocol (within the 877 Internet, UDP). The scheme rtsps is intended to identify a reliable 878 transport using secure transport, perhaps TLS [26]. The rtspu and 879 rtsps is not defined in this specification, and are for future 880 extensions of the protocol to define how to use. 882 If the port is empty or not given, port 554 SHALL be assumed. The | 883 semantics are that the identified resource can be controlled by RTSP | 884 at the server listening for TCP (scheme "rtsp") connections or UDP | 885 (scheme "rtspu") packets on that port of host, and the Request-URL | 886 for the resource is rtsp_URL. For the scheme rtsps the TCP and UDP | 887 port 322 is registered and SHALL be assumed. 889 The use of IP addresses in URLs SHOULD be avoided whenever possible 890 (see RFC 1924 [10]). Note: Using qualified domain names in any URL is 891 one requirement for making it possible for RFC 2326 implementations 892 of RTSP to use IPv6. This specification is updated to allow for 893 literal IPv6 addresses in RTSP URLs using the host specification in 894 RFC 2732 [11]. 896 A presentation or a stream is identified by a textual media 897 identifier, using the character set and escape conventions [H3.2] of 898 URLs (RFC 2396 [12]). URLs may refer to a stream or an aggregate of 899 streams, i.e., a presentation. Accordingly, requests described in 900 Section 11 can apply to either the whole presentation or an 901 individual stream within the presentation. Note that some request 902 methods can only be applied to streams, not presentations and vice 903 versa. 905 For example, the RTSP URL: 907 rtsp://media.example.com:554/twister/audiotrack 909 identifies the audio stream within the presentation "twister", which 910 can be controlled via RTSP requests issued over a TCP connection to 911 port 554 of host media.example.com 913 Also, the RTSP URL: 915 rtsp://media.example.com:554/twister 917 identifies the presentation "twister", which may be composed of audio 918 and video streams. 920 This does not imply a standard way to reference streams in 921 URLs. The presentation description defines the hierarchical 922 relationships in the presentation and the URLs for the 923 individual streams. A presentation description may name a 924 stream "a.mov" and the whole presentation "b.mov". 926 The path components of the RTSP URL are opaque to the client and do 927 not imply any particular file system structure for the server. 929 This decoupling also allows presentation descriptions to be 930 used with non-RTSP media control protocols simply by 931 replacing the scheme in the URL. 933 3.3 Session Identifiers 935 Session identifiers are strings of any arbitrary length. A session 936 identifier MUST be chosen randomly and MUST be at least eight 937 characters long to make guessing it more difficult. (See Section 18.) 939 3.4 SMPTE Relative Timestamps 941 A SMPTE relative timestamp expresses time relative to the start of 942 the clip. Relative timestamps are expressed as SMPTE time codes for 943 frame-level access accuracy. The time code has the format 944 hours:minutes:seconds:frames.subframes, 945 with the origin at the start of the clip. The default smpte format 946 is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 947 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 948 use of alternative use of "smpte time". For the "frames" field in the 949 time value can assume the values 0 through 29. The difference between 950 30 and 29.97 frames per second is handled by dropping the first two 951 frame indices (values 00 and 01) of every minute, except every tenth 952 minute. If the frame value is zero, it may be omitted. Subframes are 953 measured in one-hundredth of a frame. 955 Examples: 957 smpte=10:12:33:20- 958 smpte=10:07:33- 959 smpte=10:07:00-10:07:33:05.01 960 smpte-25=10:07:00-10:07:33:05.01 962 3.5 Normal Play Time 964 Normal play time (NPT) indicates the stream absolute position 965 relative to the beginning of the presentation, not to be confused 966 with the Network Time Protocol (NTP). The timestamp consists of a 967 decimal fraction. The part left of the decimal may be expressed in 968 either seconds or hours, minutes, and seconds. The part right of the 969 decimal point measures fractions of a second. 971 The beginning of a presentation corresponds to 0.0 seconds. Negative 972 values are not defined. The special constant now is defined as the 973 current instant of a live type event. It MAY only be used for live 974 type events, and SHALL NOT be used for on-demand content. 976 NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the 977 viewer associates with a program. It is often digitally displayed on 978 a VCR. NPT advances normally when in normal play mode (scale = 1), 979 advances at a faster rate when in fast scan forward (high positive 980 scale ratio), decrements when in scan reverse (high negative scale 981 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 982 SMPTE time codes." [25] 984 Examples: 986 npt=123.45-125 987 npt=12:05:35.3- 988 npt=now- 990 The syntax conforms to ISO 8601. The npt-sec notation is 991 optimized for automatic generation, the ntp-hhmmss notation 992 for consumption by human readers. The "now" constant allows 993 clients to request to receive the live feed rather than the 994 stored or time-delayed version. This is needed since 995 neither absolute time nor zero time are appropriate for 996 this case. 998 3.6 Absolute Time 1000 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 1001 Fractions of a second may be indicated. 1003 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 1004 UTC: 1006 19961108T143720.25Z 1008 3.7 Feature-tags 1010 Feature-tags are unique identifiers used to designate features in 1011 RTSP. These tags are used in Require (Section 14.32), Proxy-Require 1012 (Section 14.27), Unsupported (Section 14.41), and Supported (Section 1013 14.38) header fields. 1015 Feature tag needs to indicate if they apply to servers only, proxies 1016 only, or both server and proxies. 1018 The creator of a new RTSP feature-tag should either prefix the | 1019 feature-tag with a reverse domain name (e.g., | 1020 "com.example.mynewfeature" is an apt name for a feature whose | 1021 inventor can be reached at "example.com"), or register the new | 1022 feature-tag with the Internet Assigned Numbers Authority (IANA), see | 1023 IANA Section 19. 1025 4 RTSP Message 1027 RTSP is a text-based protocol and uses the ISO 10646 character set in 1028 UTF-8 encoding (RFC 2279 [13]). Lines are terminated by CRLF, but 1029 receivers should be prepared to also interpret CR and LF by 1030 themselves as line terminators. 1032 Text-based protocols make it easier to add optional 1033 parameters in a self-describing manner. Since the number of 1034 parameters and the frequency of commands is low, processing 1035 efficiency is not a concern. Text-based protocols, if done 1036 carefully, also allow easy implementation of research 1037 prototypes in scripting languages such as Tcl, Visual Basic 1038 and Perl. 1040 The 10646 character set avoids tricky character set switching, but is 1041 invisible to the application as long as US-ASCII is being used. This 1042 is also the encoding used for RTCP. ISO 8859-1 translates directly 1043 into Unicode with a high-order octet of zero. ISO 8859-1 characters 1044 with the most-significant bit set are represented as 1100001x 1045 10xxxxxx. (See RFC 2279 [13]) 1047 RTSP messages can be carried over any lower-layer transport protocol 1048 that is 8-bit clean. RTSP messages are vulnerable to bit errors and 1049 SHOULD NOT be subjected to them. 1051 Requests contain methods, the object the method is operating upon and 1052 parameters to further describe the method. Methods are idempotent, 1053 unless otherwise noted. Methods are also designed to require little 1054 or no state maintenance at the media server. 1056 4.1 Message Types 1058 See [H4.1]. 1060 4.2 Message Headers 1061 See [H4.2]. 1063 4.3 Message Body 1065 See [H4.3] 1067 4.4 Message Length 1069 When a message body is included with a message, the length of that 1070 body is determined by one of the following (in order of precedence): 1072 1. Any response message which MUST NOT include a message body 1073 (such as the 1xx, 204, and 304 responses) is always 1074 terminated by the first empty line after the header fields, 1075 regardless of the entity-header fields present in the 1076 message. (Note: An empty line consists of only CRLF.) 1078 2. If a Content-Length header field (section 14.14) is 1079 present, its value in bytes represents the length of the 1080 message-body. If this header field is not present, a value 1081 of zero is assumed. 1083 Note that RTSP does not (at present) support the HTTP/1.1 "chunked" 1084 transfer coding(see [H3.6.1]) and requires the presence of the 1085 Content-Length header field. 1087 Given the moderate length of presentation descriptions 1088 returned, the server should always be able to determine its 1089 length, even if it is generated dynamically, making the 1090 chunked transfer encoding unnecessary. 1092 5 General Header Fields 1094 See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, 1095 and Warning headers are not defined. RTSP further defines the CSeq, 1096 and Timestamp. The general headers are listed in table 1: 1098 6 Request 1100 A request message from a client to a server or vice versa includes, | 1101 within the first line (Request Line) of that message, the method to | 1102 be applied to the resource, the identifier of the resource, and the | 1103 protocol version in use. Then follows zero or more headers that can | 1104 be of general (Section 5), request (Section 6.2), or entity (Section | 1105 8.1) type. Then an empty line, i.e. a line with only the two | 1106 characters Carriage Return (CR) and Line Feed (LF), indicates the end | 1107 Header Name Comment 1108 _________________________________ 1109 Cache-Control See section 14.9 1110 Connection See section 14.10 1111 CSeq See section 14.17 1112 Date See section 14.18 1113 Supported See section 14.38 1114 Timestamp See section 14.39 1115 Via See section 14.44 1117 Table 1: The General headers used in RTSP. 1119 of the header part. Optionally a message body (entity) follows to the | 1120 end of the message. The length of the message body is indicated | 1121 through the entity headers. | 1123 6.1 Request Line | 1125 The request line, provides the most important things about the | 1126 request: What method, on what resources and using which RTSP version. | 1127 The methods that is defined by this specification can be seen in | 1128 Table 6.1. The resource is identified through an absolute RTSP URL | 1129 (see section 3.2. 1131 SP SP CRLF 1133 Please note: The request line's syntax can't be changed in future 1134 versions of RTSP, as this line indicates the version of the messages 1135 and need to be parsable also by older versions. 1137 Note that in contrast to HTTP/1.1 [4], RTSP requests always contain 1138 the absolute URL (that is, including the scheme, host and port) 1139 rather than just the absolute path. 1141 HTTP/1.1 requires servers to understand the absolute URL, 1142 but clients are supposed to use the Host request header. 1143 This is purely needed for backward-compatibility with 1144 HTTP/1.0 servers, a consideration that does not apply to 1145 RTSP. 1147 The asterisk "*" in the Request-URL means that the request does not 1148 apply to a particular resource, but to the server or proxy itself, 1149 and is only allowed when the method used does not necessarily apply 1150 Method Defined In Section 1151 _________________________________ 1152 DESCRIBE Section 11.2 1153 GET_PARAMETER Section 11.7 1154 OPTIONS Section 11.1 1155 PAUSE Section 11.5 1156 PLAY Section 11.4 1157 PING Section 11.10 1158 REDIRECT Section 11.9 1159 SETUP Section 11.3 1160 SET_PARAMETER Section 11.8 1161 TEARDOWN Section 11.6 1163 Table 2: The RTSP Methods 1165 to a resource. 1167 One example would be as follows: 1169 OPTIONS * RTSP/1.0 1171 An OPTIONS in this form will determine the capabilities of the server 1172 or the proxy that first receives the request. If one needs to address 1173 the server explicitly, then one should use an absolute URL with the 1174 server's address. 1176 OPTIONS rtsp://example.com RTSP/1.0 1178 6.2 Request Header Fields 1180 The RTSP headers in Table 6.2 can be included in a request with the 1181 purpose to give further define how the request should be fulfilled. A 1182 request header MAY also be response header, see section 7.1.2. 1184 7 Response 1186 [H6] applies except that HTTP-Version is replaced by RTSP-Version. | 1187 Also, RTSP defines additional status codes and does not define some | 1188 Header Defined in Section 1189 _____________________________________ 1190 Accept Section 14.1 1191 Accept-Encoding Section 14.2 1192 Accept-Language Section 14.3 1193 Authorization Section 14.6 1194 Bandwidth Section 14.7 1195 Blocksize Section 14.8 1196 From Section 14.20 1197 If-Match Section 14.22 1198 If-Modified-Since Section 14.23 1199 Proxy-Require Section 14.27 1200 Range Section 14.29 1201 Referer Section 14.30 1202 Require Section 14.32 1203 Scale Section 14.34 1204 Session Section 14.37 1205 Speed Section 14.35 1206 Supported Section 14.38 1207 Transport Section 14.40 1208 User-Agent Section 14.42 1210 Table 3: The RTSP request headers 1212 HTTP codes. The valid response codes and the methods they can be used | 1213 with are defined in Table 4. | 1215 After receiving and interpreting a request message, the recipient | 1216 responds with an RTSP response message. | 1218 7.1 Status-Line | 1220 The first line of a Response message is the Status-Line, consisting | 1221 of the protocol version followed by a numeric status code, and the | 1222 textual phrase associated with the status code, with each element | 1223 separated by SP characters. No CR or LF is allowed except in the | 1224 final CRLF sequence. | 1226 SP SP CRLF | 1228 7.1.1 Status Code and Reason Phrase | 1230 The Status-Code element is a 3-digit integer result code of the | 1231 attempt to understand and satisfy the request. These codes are fully | 1232 defined in Section 13. The Reason-Phrase is intended to give a short | 1233 textual description of the Status-Code. The Status-Code is intended | 1234 for use by automata and the Reason-Phrase is intended for the human | 1235 user. The client is not required to examine or display the Reason- | 1236 Phrase. | 1238 The first digit of the Status-Code defines the class of response. The | 1239 last two digits do not have any categorization role. There are 5 | 1240 values for the first digit: | 1242 o 1xx: Informational - Request received, continuing process | 1244 o 2xx: Success - The action was successfully received, | 1245 understood, and accepted | 1247 o 3rr: Redirection - Further action must be taken in order to | 1248 complete the request | 1250 o 4xx: Client Error - The request contains bad syntax or cannot | 1251 be fulfilled | 1253 o 5xx: Server Error - The server failed to fulfill an apparently | 1254 valid request | 1256 The individual values of the numeric status codes defined for | 1257 RTSP/1.0, and an example set of corresponding Reason-Phrase's, are | 1258 presented in table 4. The reason phrases listed here are only | 1259 recommended they may be replaced by local equivalents without | 1260 affecting the protocol. Note that RTSP adopts most HTTP/1.1 [4] | 1261 status codes and adds RTSP-specific status codes starting at x50 to | 1262 avoid conflicts with newly defined HTTP status codes. | 1264 RTSP status codes are extensible. RTSP applications are not required | 1265 to understand the meaning of all registered status codes, though such | 1266 understanding is obviously desirable. However, applications MUST | 1267 understand the class of any status code, as indicated by the first | 1268 digit, and treat any unrecognized response as being equivalent to the | 1269 x00 status code of that class, with the exception that an | 1270 unrecognized response MUST NOT be cached. For example, if an | 1271 unrecognized status code of 431 is received by the client, it can | 1272 safely assume that there was something wrong with its request and | 1273 treat the response as if it had received a 400 status code. In such | 1274 cases, user agents SHOULD present to the user the entity returned | 1275 with the response, since that entity is likely to include human- | 1276 readable information which will explain the unusual status. | 1278 7.1.2 Response Header Fields | 1279 The response-header fields allow the request recipient to pass | 1280 additional information about the response which cannot be placed in | 1281 the Status-Line. These header fields give information about the | 1282 server and about further access to the resource identified by the | 1283 Request-URL. All headers currently being classified as response | 1284 headers are listed in table 7.1.2. 1286 Header Defined in Section 1287 ______________________________________ 1288 Accept-Ranges Section 14.4 1289 Location Section 14.25 1290 Proxy-Authenticate Section 14.26 1291 Public Section 14.28 1292 Range Section 14.29 1293 Retry-After Section 14.31 1294 RTP-Info Section 14.33 1295 Scale Section 14.34 1296 Session Section 14.37 1297 Server Section 14.36 1298 Speed Section 14.35 1299 Transport Section 14.40 1300 Unsupported Section 14.41 1301 Vary Section 14.43 1302 WWW-Authenticate Section 14.45 1304 Table 5: The RTSP response headers 1306 Response-header field names can be extended reliably only in 1307 combination with a change in the protocol version. However, new or 1308 experimental header fields MAY be given the semantics of response- 1309 header fields if all parties in the communication recognize them to 1310 be response-header fields. Unrecognized header fields are treated as 1311 entity-header fields. 1313 8 Entity 1315 Request and Response messages MAY transfer an entity if not otherwise | 1316 restricted by the request method or response status code. An entity | 1317 consists of entity-header fields and an entity-body, although some | 1318 responses will only include the entity-headers. | 1320 The SET_PARAMETER, and GET_PARAMETER request and response, and | 1321 DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY | 1322 also have an entity. | 1323 Code Reason Method 1324 _______________________________________________________ 1325 100 Continue all 1327 _______________________________________________________ 1328 200 OK all 1329 201 Created RECORD 1330 250 Low on Storage Space RECORD 1331 _______________________________________________________ 1332 300 Multiple Choices all 1333 301 Moved Permanently all 1334 302 Found all 1335 303 See Other all 1336 305 Use Proxy all 1337 350 Going Away all 1338 351 Load Balancing all 1340 _______________________________________________________ 1341 400 Bad Request all 1342 401 Unauthorized all 1343 402 Payment Required all 1344 403 Forbidden all 1345 404 Not Found all 1346 405 Method Not Allowed all 1347 406 Not Acceptable all 1348 407 Proxy Authentication Required all 1349 408 Request Timeout all 1350 410 Gone all 1351 411 Length Required all 1352 412 Precondition Failed DESCRIBE, SETUP 1353 413 Request Entity Too Large all 1354 414 Request-URL Too Long all 1355 415 Unsupported Media Type all 1356 451 Parameter Not Understood SET_PARAMETER 1357 452 reserved n/a 1358 453 Not Enough Bandwidth SETUP 1359 454 Session Not Found all 1360 455 Method Not Valid In This State all 1361 456 Header Field Not Valid all 1362 457 Invalid Range PLAY, PAUSE 1363 458 Parameter Is Read-Only SET_PARAMETER 1364 459 Aggregate Operation Not Allowed all 1365 460 Only Aggregate Operation Allowed all 1366 461 Unsupported Transport all 1367 462 Destination Unreachable all 1368 _______________________________________________________ 1369 500 Internal Server Error all 1370 501 Not Implemented all 1371 502 Bad Gateway all 1372 503 Service Unavailable all 1373 504 Gateway Timeout all 1374 505 RTSP Version Not Supported all 1376 Table 4: Status codes and their usage with RTSP methods 1378 In this section, both sender and recipient refer to either the client | 1379 or the server, depending on who sends and who receives the entity. | 1381 8.1 Entity Header Fields | 1383 Entity-header fields define optional meta-information about the | 1384 entity-body or, if no body is present, about the resource identified | 1385 by the request. The entity header fields are listed in table 8.1. | 1387 Header Defined in Section 1388 ____________________________________ 1389 Allow Section 14.5 1390 Content-Base Section 14.11 1391 Content-Encoding Section 14.12 1392 Content-Language Section 14.13 1393 Content-Length Section 14.14 1394 Content-Location Section 14.15 1395 Content-Type Section 14.16 1396 Expires Section 14.19 1397 Last-Modified Section 14.24 1399 Table 6: The RTSP entity headers 1401 The extension-header mechanism allows additional entity-header fields | 1402 to be defined without changing the protocol, but these fields cannot | 1403 be assumed to be recognizable by the recipient. Unrecognized header | 1404 fields SHOULD be ignored by the recipient and forwarded by proxies. | 1406 8.2 Entity Body | 1408 See [H7.2] with the addition that a RTSP message with an entity body | 1409 MUST include the Content-Type and Content-Length headers. | 1411 9 Connections 1413 RTSP requests can be transmitted in several different ways: 1415 o persistent transport connections used for several request- 1416 response transactions; 1418 o one connection per request/response transaction; 1419 o connectionless mode. 1421 The type of transport is defined by the RTSP URL (Section 3.2). For | 1422 the scheme "rtsp", a connection is assumed, while the scheme "rtspu" | 1423 calls for RTSP requests to be sent without setting up a connection. 1425 Unlike HTTP, RTSP allows the media server to send requests to the 1426 media client. However, this is only supported for persistent 1427 connections, as the media server otherwise has no reliable way of 1428 reaching the client. Also, this is the only way that requests from 1429 media server to client are likely to traverse firewalls. 1431 9.1 Pipelining 1433 A client that supports persistent connections or connectionless mode 1434 MAY "pipeline" its requests (i.e., send multiple requests without 1435 waiting for each response). A server MUST send its responses to those 1436 requests in the same order that the requests were received. 1438 9.2 Reliability and Acknowledgements 1440 The transmission of RTSP over UDP was optionally to implement and 1441 specified in RFC 2326. However that definition was not satisfactory 1442 for interoperable implementations. Due to lack of interest, this 1443 specification does not specify how RTSP over UDP shall be 1444 implemented. However to maintain backwards compatibility in the 1445 message format certain RTSP headers must be maintained. These 1446 mechanism are described below. The next section Unreliable Transport 1447 (section 9.3) provides documentation of certain features that are 1448 necessary for transport protocols like UDP. 1450 Any RTSP request according to this specification SHALL NOT be sent to 1451 a multicast address. Any RTSP request SHALL be acknowledged. If a 1452 reliable transport protocol is used to carry RTSP, requests MUST NOT 1453 be retransmitted; the RTSP application MUST instead rely on the 1454 underlying transport to provide reliability. 1456 If both the underlying reliable transport such as TCP and 1457 the RTSP application retransmit requests, it is possible 1458 that each packet loss results in two retransmissions. The 1459 receiver cannot typically take advantage of the 1460 application-layer retransmission since the transport stack 1461 will not deliver the application-layer retransmission 1462 before the first attempt has reached the receiver. If the 1463 packet loss is caused by congestion, multiple 1464 retransmissions at different layers will exacerbate the 1465 congestion. 1467 Each request carries a sequence number in the CSeq header (Section 1468 14.17), which MUST be incremented by one for each distinct request 1469 transmitted to the destination end-point. The initial sequence 1470 number MAY be chosen arbitrary, but is RECOMMENDED to begin with 0. 1471 If a request is repeated because of lack of acknowledgement, the 1472 request MUST carry the original sequence number (i.e., the sequence 1473 number is not incremented). 1475 9.3 Unreliable Transport 1477 This section provides some information to future specification of 1478 RTSP over unreliable transport. 1480 Requests shall be acknowledged by the receiver. If there is no | 1481 acknowledgement, the sender may resend the same message after a | 1482 timeout of one round-trip time (RTT). The round-trip time is | 1483 estimated as in TCP (RFC 1123) [14], with an initial round-trip value | 1484 of 500 ms. An implementation MAY cache the last RTT measurement as | 1485 the initial value for future connections. 1487 If RTSP is used over a small-RTT LAN, standard procedures for 1488 optimizing initial TCP round trip estimates, such as those used in 1489 T/TCP (RFC 1644) [33], can be beneficial. 1491 The Timestamp header (Section 14.39) is used to avoid the 1492 retransmission ambiguity problem [34] and obviates the need for 1493 Karn's algorithm. 1495 If a request is repeated because of lack of acknowledgement, the 1496 request must carry the original sequence number (i.e., the sequence 1497 number is not incremented). 1499 A number of RTSP messages destined for the same control end point may | 1500 be packed into a single lower-layer PDU. 1502 The default port for the RTSP server is 554 for UDP. 1504 9.4 The usage of connections 1506 Systems implementing RTSP MUST support carrying RTSP over TCP. The | 1507 default port for the RTSP server is 554 for TCP. A number of RTSP | 1508 packets destined for the same control end point may be encapsulated | 1509 into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP | 1510 packets, see section 12. Unlike HTTP, an RTSP message MUST contain a | 1511 Content-Length header field whenever that message contains a payload | 1512 (entity). Otherwise, an RTSP packet is terminated with an empty line | 1513 immediately following the last message header. 1515 TCP can be used for both persistent connections and for one message 1516 exchange per connection, as presented above. This section gives 1517 further rules and recommendations on how to handle these connections 1518 so maximum interoperability and flexibility can be achieved. 1520 A server SHALL handle both persistent connections and one 1521 request/response transaction per connection. A persistent connection 1522 MAY be used for all transactions between the server and client, 1523 including messages to multiple RTSP sessions. However the persistent 1524 connection MAY also be closed after a few message exchanges, e.g. the 1525 initial setup and play command in a session. Later when the client 1526 wishes to send a new request, e.g. pause, to the session a new 1527 connection is opened. This connection may either be for a single 1528 message exchange or can be kept open for several messages, i.e. 1529 persistent. 1531 A major motivation for allowing non-persistent connections are that 1532 they ensure fault tolerance. A second one is to allow for application 1533 layer mobility. A server and client supporting non-persistent 1534 connection can survive a loss of a TCP connection, e.g. due to a NAT 1535 timeout. When the client has discovered that the TCP connection has 1536 been lost, it can set up a new one when there is need to communicate. 1538 The client MAY close the connection at any time when no outstanding | 1539 request/response transactions exist. The server SHOULD NOT close the | 1540 connection unless at least one RTSP session timeout period has passed | 1541 without data traffic. A server SHOULD NOT initiate a close of a | 1542 connection directly after responding to a TEARDOWN request for the | 1543 whole session. A server SHOULD NOT close the connection as a result | 1544 of responding to a request with an error code. Doing this would | 1545 prevent or result in extra overhead for the client when testing | 1546 advanced or special types of requests. 1548 The client SHOULD NOT have more than one connection to the server at 1549 any given point. If a client or proxy handles multiple RTSP sessions 1550 on the same server, it is RECOMMENDED to use only a single 1551 connection. 1553 Older services which was implemented according to RFC 2326 sometimes 1554 requires the client to use persistent connection. The client closing 1555 the connection may result in that the server removes the session. To 1556 achieve interoperability with old servers any client is strongly 1557 RECOMMENDED to use persistent connections. 1559 A Client is also strongly RECOMMENDED to use persistent connections 1560 as it allows the server to send request to the client. In cases 1561 where no connection exist between the server and the client, this may 1562 cause the server to be forced to drop the RTSP session without 1563 notifying the client why, due to the lack of signalling channel. An 1564 example of such a case is when the server desires to send a REDIRECT 1565 request for a RTSP session to the client. 1567 A server implemented according to this specification MUST respond 1568 that it supports the "play.basic" feature-tag above. A client MAY 1569 send a request including the Supported header in a request to 1570 determine support of non-persistent connections. A server supporting 1571 non-persistent connections will return the "play.basic" feature-tag 1572 in its response. If the client receives the feature-tag in the 1573 response, it can be certain that the server handles non-persistent 1574 connections. 1576 9.5 Timing Out RTSP messages | 1578 Receivers of a request (responder) SHOULD respond to requests in a | 1579 timely manner even when a reliable transport such as TCP is used. | 1580 Similarly, the sender of a request (requestor) SHOULD wait for a | 1581 sufficient time for a response before concluding that the responder | 1582 will not be acting upon its request. | 1584 A responder SHOULD respond to all requests within 5 seconds. If the | 1585 responder recognizes that processing of a request will take longer | 1586 than 5 seconds, it SHOULD send a 100 response as soon as possible. It | 1587 SHOULD continue sending a 100 response every 5 seconds thereafter | 1588 until it is ready to send the final response to the requestor. After | 1589 sending a 100 response, the receiver MUST send a final response | 1590 indicating the success or failure of the request. | 1592 A requestor SHOULD wait at least 10 seconds for a response before | 1593 concluding that the responder will not be responding to its request. | 1594 After receiving a 100 response, the requestor SHOULD continue waiting | 1595 for further responses. If more than 10 seconds elapses without | 1596 receiving any response, the requestor MAY assume the responder is | 1597 unresponsive and abort the connection. | 1599 A requestor SHOULD wait longer than 10 seconds for a response if it | 1600 is experiencing significant transport delays on its connection to the | 1601 responder. The requestor is capable of determining the RTT using the | 1602 Timestamp header (section 14.39) in any RTSP request. 1604 9.6 Use of IPv6 1606 This specification has been updated so that it supports IPv6. 1607 However this support was not present in RFC 2326 therefore some 1608 interoperability issues exist. A RFC 2326 implementation can support 1609 IPv6 as long as no explicit IPv6 addresses are used within RTSP 1610 messages. This require that any RTSP URL pointing at a IPv6 host must 1611 use fully qualified domain name and not a IPv6 address. Further the 1612 Transport header must not use the parameters source and destination. 1614 Implementations according to this specification MUST understand IPv6 1615 addresses in URLs, and headers. By this requirement the feature-tag 1616 "play.basic" can be used to determine that a server or client is 1617 capable of handling IPv6 within RTSP. 1619 10 Capability Handling 1621 This chapter describes the capability handling mechanism available in 1622 RTSP which allows RTSP to be extended. Extensions to this version of 1623 the protocol are basically done in two ways. First, new headers can 1624 be added. Secondly, new methods can be added. The capability handling 1625 mechanism is designed to handle these two cases. 1627 When a method is added the involved parties can use the OPTIONS 1628 method to discover if it is supported. This is done by issuing a 1629 OPTIONS request to the other party. Depending on the URL it will 1630 either apply in regards to a certain media resource, the whole server 1631 in general, or simply the next hop. The OPTIONS response will contain 1632 a Public header which declares all methods supported for the 1633 indicated resource. 1635 It is not necessary to use OPTIONS to discover support of a method, 1636 the client could simply try the method. If the receiver of the 1637 request does not support the method it will respond with an error 1638 code indicating the the method is either not implemented (501) or 1639 does not apply for the resource (405). The choice between the two 1640 discovery methods depends on the requirements of the service. 1642 To handle functionality additions that are not new methods feature- 1643 tags are defined. Each feature-tag represents a certain block of 1644 functionality. The amount of functionality that a feature-tag 1645 represents can vary significantly. A simple feature-tag can simple 1646 represent the functionality a single header gives. Another feature- 1647 tag is "play.basic" which represents the minimal playback 1648 implementation according to the updated specification. 1650 The feature-tags are then used to determine if the client, server or 1651 proxy supports the functionality that is necessary to achieve the 1652 desired service. To determine support of a feature-tag several 1653 different headers can be used, each explained below: 1655 Supported: The supported header is used to determine the 1656 complete set of functionality that both client and server 1657 has. The intended usage is to determine before one needs to 1658 use a functionality that it is supported. It can be used in 1659 any method however OPTIONS is the most suitable as one at 1660 the same time determines all methods that are implemented. 1661 When sending a request the requestor declares all its 1662 capabilities by including all supported feature-tags. This 1663 results in that the receiver learns the requestors feature 1664 support. The receiver then includes its set of features in 1665 the response. 1667 Require: The Require header can be included in any request where 1668 the end point, i.e. the client or server, is required to 1669 understand the feature to correctly perform the request. 1670 This can for example be a SETUP request where the server 1671 must understand a certain parameter to be able to set up 1672 the media delivery correctly. Ignoring this parameter would 1673 not have the desired effect and is not acceptable. 1674 Therefore the end-point receiving a request containing a 1675 Require must negatively acknowledge any feature that it 1676 does not understand and not perform the request. The 1677 response in cases where features are not understood are 551 1678 (Option Not Supported). Also the features that are not 1679 understood are given in the Unsupported header in the 1680 response. 1682 Proxy-Require: This method has the same purpose and workings as 1683 Require except that it only applies to proxies and not the 1684 end point. Features that needs to be supported by both 1685 proxies and end-point needs to be included in both the 1686 Require and Proxy-Require header. 1688 Unsupported: This header is used in 551 error response to tell 1689 which feature(s) that was not supported. Such a response is 1690 only the result of the usage of the Require and/or Proxy- 1691 Require header where one or more feature where not 1692 supported. This information allows the requestor to make 1693 the best of situations as it knows which features that was 1694 not supported. 1696 11 Method Definitions 1698 The method indicates what is to be performed on the resource | 1699 identified by the Request-URL. The method name is case-sensitive. | 1700 New methods may be defined in the future. Method names may not start | 1701 with a $ character (decimal 24) and must be a token as defined by the | 1702 ABNF. Methods are summarized in Table 7. 1704 Notes on Table 7: PAUSE is recommended, but not required in that a | 1705 method direction object Server req. Client req. 1706 ___________________________________________________________________ 1707 DESCRIBE C -> S P,S recommended recommended 1708 GET_PARAMETER C -> S, S -> C P,S optional optional 1709 OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt 1710 PAUSE C -> S P,S recommended recommended 1711 PING C -> S, S -> C P,S recommended optional 1712 PLAY C -> S P,S required required 1713 REDIRECT S -> C P,S optional optional 1714 SETUP C -> S S required required 1715 SET_PARAMETER C -> S, S -> C P,S optional optional 1716 TEARDOWN C -> S P,S required required 1718 Table 7: Overview of RTSP methods, their direction, and what objects 1719 (P: presentation, S: stream) they operate on. Legend: R=Responde to, 1720 Sd=Send, Opt: Optional, Req: Required, Rec: Recommended 1722 fully functional server can be built that does not support this | 1723 method, for example, for live feeds. If a server does not support a | 1724 particular method, it MUST return 501 (Not Implemented) and a client | 1725 SHOULD NOT try this method again for this server and resource. 1727 11.1 OPTIONS 1729 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1730 request may be issued at any time, e.g., if the client is about to 1731 try a nonstandard request. It does not influence the session state. 1732 The Public header MUST be included in responses to indicate which 1733 methods that are supported by the server. To specify which methods 1734 that are possible to use for the specified resource, the Allow MAY be 1735 used. By including in the OPTIONS request a Supported header, the 1736 requester can determine which features the other part supports. 1738 The request URL determines which scope the OPTIONS request has. By 1739 giving the URL of a certain media the capabilities regarding this 1740 media will be responded. By using the "*" URL the request regards the 1741 next hop only, while having a URL with only the host address regards 1742 the server without any media relevance. 1744 The OPTIONS method can be used for RTSP session keep alive | 1745 signalling, however this method is not the most recommended one, see | 1746 section 14.37 for a preference list. A keep alive OPTIONS request | 1747 SHOULD use the media or aggregated control URL. For options to | 1748 function as session state keep-alive, it is REQUIRED that the session | 1749 ID is included in the Session header. 1751 Example: 1753 C->S: OPTIONS * RTSP/1.0 1754 CSeq: 1 1755 User-Agent: PhonyClient/1.2 1756 Require: 1757 Proxy-Require: gzipped-messages 1758 Supported: play-basic 1760 S->C: RTSP/1.0 200 OK 1761 CSeq: 1 1762 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1763 Supported: play-basic, implicit-play, gzipped-messages 1764 Server: PhonyServer/1.0 1766 Note that some of the feature-tags in Require and Proxy-Require are 1767 necessarily fictional features (one would hope that we would not 1768 purposefully overlook a truly useful feature just so that we could 1769 have a strong example in this section). 1771 11.2 DESCRIBE 1773 The DESCRIBE method retrieves the description of a presentation or | 1774 media object identified by the request URL from a server. The request | 1775 MAY use the Accept header to specify the description formats that the | 1776 client understands. The server responds with a description of the | 1777 requested resource. The DESCRIBE reply-response pair constitutes the | 1778 media initialization phase of RTSP. 1780 Example: 1782 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 1783 CSeq: 312 1784 User-Agent: PhonyClient 1.2 1785 Accept: application/sdp, application/rtsl, application/mheg 1787 S->C: RTSP/1.0 200 OK 1788 CSeq: 312 1789 Date: 23 Jan 1997 15:35:06 GMT 1790 Server: PhonyServer 1.0 1791 Content-Type: application/sdp 1792 Content-Length: 376 1794 v=0 1795 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1796 s=SDP Seminar 1797 i=A Seminar on the session description protocol 1798 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1799 e=mjh@isi.edu (Mark Handley) 1800 c=IN IP4 224.2.17.12/127 1801 t=2873397496 2873404696 1802 a=recvonly 1803 m=audio 3456 RTP/AVP 0 1804 m=video 2232 RTP/AVP 31 1805 m=application 32416 UDP WB 1806 a=orient:portrait 1808 The DESCRIBE response MUST contain all media initialization 1809 information for the resource(s) that it describes. If a media client 1810 obtains a presentation description from a source other than DESCRIBE 1811 and that description contains a complete set of media initialization 1812 parameters, the client SHOULD use those parameters and not then 1813 request a description for the same media via RTSP. 1815 Additionally, servers SHOULD NOT use the DESCRIBE response as a means 1816 of media indirection. 1818 By forcing a DESCRIBE response to contain all media 1819 initialization for the set of streams that it describes, 1820 and discouraging use of DESCRIBE for media indirection, we 1821 avoid looping problems that might result from other 1822 approaches. 1824 Media initialization is a requirement for any RTSP-based system, but 1825 the RTSP specification does not dictate that this must be done via 1826 the DESCRIBE method. There are three ways that an RTSP client may 1827 receive initialization information: 1829 o via RTSP's DESCRIBE method; 1831 o via some other protocol (HTTP, email attachment, etc.); 1833 o via the command line or standard input (thus working as a 1834 browser helper application launched with an SDP file or other 1835 media initialization format). 1837 It is RECOMMENDED that minimal servers support the DESCRIBE method, 1838 and highly recommended that minimal clients support the ability to 1839 act as a "helper application" that accepts a media initialization 1840 file from standard input, command line, and/or other means that are 1841 appropriate to the operating environment of the client. 1843 11.3 SETUP 1845 The SETUP request for a URL specifies the transport mechanism to be 1846 used for the streamed media. The SETUP method may be used in two 1847 different cases; Create a RTSP session or add a media to a session, 1848 and change the transport parameters of already set up media stream. 1849 Using SETUP to create or add media to a session when in PLAY state is 1850 unspecified. Otherwise SETUP can be used in all three states; INIT, 1851 and READY, for both purposes and in PLAY to change the transport 1852 parameters. 1854 The Transport header, see section 14.40, specifies the transport | 1855 parameters acceptable to the client for data transmission; the | 1856 response will contain the transport parameters selected by the | 1857 server. This allows the client to enumerate in priority order the | 1858 transport mechanisms and parameters acceptable to it, while the | 1859 server can select the most appropriate. It is expected that the | 1860 session description format used will enable the client to select a | 1861 limited number possible configurations that are offered to the server | 1862 to choose from. All transport parameters SHOULD be included in the | 1863 Transport header, the use of other headers for this purpose is | 1864 discouraged due to middle boxes. 1866 For the benefit of any intervening firewalls, a client SHOULD 1867 indicate the transport parameters even if it has no influence over 1868 these parameters, for example, where the server advertises a fixed 1869 multicast address. 1871 Since SETUP includes all transport initialization 1872 information, firewalls and other intermediate network 1873 devices (which need this information) are spared the more 1874 arduous task of parsing the DESCRIBE response, which has 1875 been reserved for media initialization. 1877 In a SETUP response the server SHOULD include the Accept-Ranges 1878 header (see section 14.4 to indicate which time formats that are 1879 acceptable to use for this media resource. 1881 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 1882 CSeq: 302 1883 Transport: RTP/AVP;unicast;client_port=4588-4589, 1884 RTP/AVP/TCP;unicast;interleave=0-1 1886 S->C: RTSP/1.0 200 OK 1887 CSeq: 302 1888 Date: 23 Jan 1997 15:35:06 GMT 1889 Server: PhonyServer 1.0 1890 Session: 47112344 1891 Transport: RTP/AVP;unicast;client_port=4588-4589; 1892 server_port=6256-6257;ssrc=2A3F93ED 1893 Accept-Ranges: NPT 1895 In the above example the client want to create a RTSP session 1896 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 1897 The transport parameters acceptable to the client is either 1898 RTP/AVP/UDP (UDP per default) to be received on client port 4588 and 1899 4589 or RTP/AVP interleaved on the RTSP control channel. The server 1900 selects the RTP/AVP/UDP transport and adds the ports it will send and 1901 received RTP and RTCP from, and the RTP SSRC that will be used by the 1902 server. 1904 The server MUST generate a session identifier in response to a 1905 successful SETUP request, unless a SETUP request to a server includes 1906 a session identifier, in which case the server MUST bundle this setup 1907 request into the existing session (aggregated session) or return 1908 error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). 1909 An Aggregate control URL MUST be used to control an aggregated 1910 session. This URL MUST be different from the stream control URLs of 1911 the individual media streams included in the aggregate. The Aggregate 1912 control URL is to be specified by the session description if the 1913 server supports aggregated control and aggregated control is desired 1914 for the session. However even if aggregated control is offered the 1915 client MAY chose to not set up the session in aggregated control. If 1916 an Aggregate control URL is not specified in the session description, 1917 it is normally an indication that non-aggregated control should be | 1918 used. The SETUP of media streams in an aggregate which has not been | 1919 given an aggregated control URL is unspecified. 1921 While the session ID sometimes has enough information for 1922 aggregate control of a session, the Aggregate control URL 1923 is still important for some methods such as SET_PARAMETER 1924 where the control URL enables the resource in question to 1925 be easily identified. The Aggregate control URL is also 1926 useful for proxies, enabling them to route the request to 1927 the appropriate server, and for logging, where it is useful 1928 to note the actual resource that a request was operating 1929 on. Finally, presence of the Aggregate control URL allows 1930 for backwards compatibility with RFC 2326 [1]. 1932 A session will exist until it is either removed by a TEARDOWN request 1933 or is timed-out by the server. The server MAY remove a session that 1934 has not demonstrated liveness signs from the client within a certain 1935 timeout period. The default timeout value is 60 seconds; the server 1936 MAY set this to a different value and indicate so in the timeout 1937 field of the Session header in the SETUP response. For further 1938 discussion see chapter 14.37. Signs of liveness for a RTSP session 1939 are: 1941 o Any RTSP request from a client which includes a Session header 1942 with that session's ID. 1944 o If RTP is used as a transport for the underlying media 1945 streams, an RTCP sender or receiver report from the client for 1946 any of the media streams in that RTSP session. 1948 If a SETUP request on a session fails for any reason, the session 1949 state, as well as transport and other parameters for associated 1950 streams SHALL remain unchanged from their values as if the SETUP 1951 request had never been received by the server. 1953 A client MAY issue a SETUP request for a stream that is already set 1954 up or playing in the session to change transport parameters, which a 1955 server MAY allow. If it does not allow this, it MUST respond with 1956 error 455 (Method Not Valid In This State). Reasons to support 1957 changing transport parameters, is to allow for application layer 1958 mobility and flexibility to utilize the best available transport as 1959 it becomes available. 1961 In a SETUP response for a request to change the transport parameters 1962 while in Play state, the server SHOULD include the Range to indicate 1963 from what point the new transport parameters are used. Further if RTP 1964 is used for delivery the server SHOULD also include the RTP-Info 1965 header to indicate from what timestamp and RTP sequence number the 1966 change has taken place. If both RTP-Info and Range is included in the 1967 response the "rtp_time" parameter and range MUST be for the 1968 corresponding time, i.e. be used in the same way as for PLAY to 1969 ensure the correct synchronization information is present. 1971 If the transport parameter change while in PLAY state results in a 1972 change of synchronization related information, for example changing 1973 RTP SSRC, the server MUST provide in the SETUP response the necessary 1974 synchronization information. However the server is RECOMMENDED to 1975 avoid changing the synchronization information if possible. 1977 11.4 PLAY 1979 The PLAY method tells the server to start sending data via the 1980 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 1981 until any outstanding SETUP requests have been acknowledged as 1982 successful. PLAY requests are valid when the session is in READY 1983 state; the use of PLAY requests when the session is in PLAY state is 1984 deprecated. A PLAY request MUST include a Session header to indicate 1985 which session the request applies to. 1987 In an aggregated session the PLAY request MUST contain an aggregated 1988 control URL. A server SHALL responde with error 460 (Only Aggregate 1989 Operation Allowed) if the client PLAY request URL is for one of the 1990 media. The media in an aggregate SHALL be played in sync. If a client 1991 want individual control of the media it must use separate RTSP 1992 sessions for each media. 1994 The PLAY request SHALL position the normal play time to the beginning 1995 of the range specified by the Range header and delivers stream data 1996 until the end of the range if given, else to the end of the media is 1997 reached. To allow for precise composition multiple ranges MAY be 1998 specified in one PLAY Request. The range values are valid if all 1999 given ranges are part of any media within the aggregate. If a given 2000 range value points outside of the media, the response SHALL be the 2001 457 (Invalid Range) error code. 2003 The below example will first play seconds 10 through 15, then, 2004 immediately following, seconds 20 to 25, and finally seconds 30 2005 through the end. 2007 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 2008 CSeq: 835 2009 Session: 12345678 2010 Range: npt=10-15, npt=20-25, npt=30- 2012 See the description of the PAUSE request for further examples. 2014 A PLAY request without a Range header is legal. It SHALL start 2015 playing a stream from the beginning (npt=0-) unless the stream has 2016 been paused. If a stream has been paused via PAUSE, stream delivery 2017 resumes at the pause point. The stream SHALL play until the end of 2018 the media. 2020 The Range header MUST NOT contain a time parameter. The usage of time | 2021 in PLAY method has been deprecated. If a request with time parameter | 2022 is received the server SHOULD respond with a 457 (Invalid Range) to | 2023 indicate that the time parameter is not supported. | 2024 Server MUST include a "Range" header in any PLAY response. The | 2025 response MUST use the same format as the request's range header | 2026 contained. If no Range header was in the request, the NPT time format | 2027 SHOULD be used unless the client showed support for an other format | 2028 more appropriate. Also for a session with live media streams the | 2029 Range header MUST indicate a valid time. It is RECOMMENDED that | 2030 normal play time is used, either the "now" indicator, for example | 2031 "npt=now-", or the time since session start as an open interval, e.g. | 2032 "npt=96.23-". An absolute time value (clock) for the corresponding | 2033 time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock | 2034 format SHOULD only be used if client has shown support for it. 2036 A media server only supporting playback MUST support the npt format 2037 and MAY support the clock and smpte formats. 2039 For a on-demand stream, the server MUST reply with the actual range 2040 that will be played back. This may differ from the requested range if 2041 alignment of the requested range to valid frame boundaries is 2042 required for the media source. If no range is specified in the 2043 request, the start position SHALL still be returned in the reply. If 2044 the medias that are part of an aggregate has different lengths, the 2045 PLAY request SHALL be performed as long as the given range is valid 2046 for any media, for example the longest media. Media will be sent 2047 whenever it is available for the given play-out point. 2049 After playing the desired range, the presentation is NOT | 2050 automatically paused, media delivery simply stops. A PAUSE request | 2051 MUST be issued before another PLAY request can be issued. Note: This | 2052 is one change resulting in a non-operability with RFC 2326 | 2053 implementations. A client not issuing a PAUSE request before a new | 2054 PLAY will be stuck in PLAY state. To mitigate this backwards | 2055 compatibility issue the following behavior is recommended. If a | 2056 server receives a PLAY request when in play state and all media has | 2057 finished the requested playout, the server MAY interpret this as a | 2058 PLAY request received in ready state. However the server SHALL NOT do | 2059 this if the client has shown any support for this specification, for | 2060 example by sending a Supported header with the play.basic feature | 2061 tag. 2063 A client desiring to play the media from the beginning MUST send a 2064 PLAY request with a Range header pointing at the beginning, e.g. 2065 npt=0-. If a PLAY request is received without a Range header when 2066 media delivery has stopped at the end, the server SHOULD respond with 2067 a 457 "Invalid Range" error response. In that response the current 2068 pause point in a Range header SHALL be included. 2070 The following example plays the whole presentation starting at SMPTE 2071 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2072 headers has been broken into several lines to fit the page. 2074 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 | 2075 CSeq: 833 | 2076 Session: 12345678 | 2077 Range: smpte=0:10:20- | 2079 S->C: RTSP/1.0 200 OK | 2080 CSeq: 833 | 2081 Date: 23 Jan 1997 15:35:06 GMT | 2082 Server: PhonyServer 1.0 | 2083 Range: smpte=0:10:22-0:15:45 | 2084 RTP-Info:url=rtsp://example.com/twister.en; | 2085 seq=14783;rtptime=2345962545 | 2087 For playing back a recording of a live presentation, it may be 2088 desirable to use clock units: 2090 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 2091 CSeq: 835 2092 Session: 12345678 2093 Range: clock=19961108T142300Z-19961108T143520Z 2095 S->C: RTSP/1.0 200 OK 2096 CSeq: 835 2097 Date: 23 Jan 1997 15:35:06 GMT 2098 Server:PhonyServer 1.0 2099 Range: clock=19961108T142300Z-19961108T143520Z 2100 RTP-Info:url=rtsp://example.com/meeting.en; 2101 seq=53745;rtptime=484589019 2103 All range specifiers in this specification allow for ranges with 2104 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2105 request, the server treats this as a request to start/resume playback 2106 from the current pause point, ending at the end time specified in the 2107 Range header. If the pause point is located later than the given end 2108 value, a 457 (Invalid Range) response SHALL be given. 2110 The queued play functionality described in RFC 2326 [1] is removed | 2111 and multiple ranges can be used to achieve a similar functionality. | 2112 If a server receives a PLAY request while in the PLAY state, the | 2113 server SHALL responde using the error code 455 (Method Not Valid In | 2114 This State). This will signal the client that queued play are not | 2115 supported. 2117 The use of PLAY for keep-alive signaling, i.e. PLAY request without a 2118 range header in PLAY state, has also been depreciated. Instead a 2119 client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A 2120 server receiving a PLAY keep alive SHALL respond with the 455 error 2121 code. 2123 11.5 PAUSE 2125 The PAUSE request causes the stream delivery to be interrupted 2126 (halted) temporarily. A PAUSE request MUST be done with the 2127 aggregated control URL for aggregated sessions, resulting in all 2128 media being halted, or the media URL for non-aggregated sessions. 2129 Any attempt to do muting of a single media with an PAUSE request in 2130 an aggregated session SHALL be responded with error 460 (Only 2131 Aggregate Operation Allowed). After resuming playback, 2132 synchronization of the tracks MUST be maintained. Any server 2133 resources are kept, though servers MAY close the session and free 2134 resources after being paused for the duration specified with the 2135 timeout parameter of the Session header in the SETUP message. 2137 Example: 2139 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2140 CSeq: 834 2141 Session: 12345678 2143 S->C: RTSP/1.0 200 OK 2144 CSeq: 834 2145 Date: 23 Jan 1997 15:35:06 GMT 2146 Range: npt=45.76- 2148 The PAUSE request MAY contain a Range header specifying when the 2149 stream or presentation is to be halted. We refer to this point as the 2150 "pause point". The time parameter in the Range MUST NOT be used. The 2151 Range header MUST contain a single value, expressed as the beginning 2152 value an open range. For example, the following clip will be played 2153 from 10 seconds through 21 seconds of the clip's normal play time, 2154 under the assumption that the PAUSE request reaches the server within 2155 11 seconds of the PLAY request. Note that some lines has been broken 2156 in an non-correct way to fit the page: 2158 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 2159 CSeq: 834 2160 Session: 12345678 2161 Range: npt=10-30 2163 S->C: RTSP/1.0 200 OK 2164 CSeq: 834 2165 Date: 23 Jan 1997 15:35:06 GMT 2166 Server: PhonyServer 1.0 2167 Range: npt=10-30 2168 RTP-Info:url=rtsp://example.com/fizzle/audiotrack; 2169 seq=5712;rtptime=934207921, 2170 url=rtsp://example.com/fizzle/videotrack; 2171 seq=57654;rtptime=2792482193 2172 Session: 12345678 2174 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2175 CSeq: 835 2176 Session: 12345678 2177 Range: npt=21- 2179 S->C: RTSP/1.0 200 OK 2180 CSeq: 835 2181 Date: 23 Jan 1997 15:35:09 GMT 2182 Server: PhonyServer 1.0 2183 Range: npt=21- 2184 Session: 12345678 2186 The pause request becomes effective the first time the server is 2187 encountering the time point specified in any of the multiple ranges. 2188 If the Range header specifies a time outside any range from the PLAY 2189 request, the error 457 (Invalid Range) SHALL be returned. If a media 2190 unit (such as an audio or video frame) starts presentation at exactly 2191 the pause point, it is not played. If the Range header is missing, 2192 stream delivery is interrupted immediately on receipt of the message 2193 and the pause point is set to the current normal play time. However, 2194 the pause point in the media stream MUST be maintained. A subsequent 2195 PLAY request without Range header SHALL resume from the pause point 2196 and play until media end. 2198 If the server has already sent data beyond the time specified in the 2199 PAUSE request's Range header, a PLAY without range SHALL resume at 2200 the point in time specified by the PAUSE request's Range header, as 2201 it is assumed that the client has discarded data after that point. 2202 This ensures continuous pause/play cycling without gaps. 2204 The pause point after any PAUSE request SHALL be returned to the 2205 client by adding a Range header with what remains unplayed of the 2206 PLAY request's ranges, i.e. including all the remaining ranges part 2207 of multiple range specification. If one desires to resume playing a 2208 ranged request, one simply includes the Range header from the PAUSE 2209 response. Note that this server behavior was not mandated previously 2210 and servers implementing according to RFC 2326 will probably not 2211 return the range header. 2213 For example, if the server have a play request for ranges 10 to 15 2214 and 20 to 29 pending and then receives a pause request for NPT 21, it 2215 would start playing the second range and stop at NPT 21. If the pause 2216 request is for NPT 12 and the server is playing at NPT 13 serving the 2217 first play request, the server stops immediately. If the pause 2218 request is for NPT 16, the server returns a 457 error message. To 2219 prevent that the second range is played and the server stops after 2220 completing the first range, a PAUSE request for 20 must be issued. 2222 As another example, if a server has received requests to play ranges 2223 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 2224 request for NPT=14 would take effect while the server plays the first 2225 range, with the second range effectively being ignored, assuming the 2226 PAUSE request arrives before the server has started playing the 2227 second, overlapping range. Regardless of when the PAUSE request 2228 arrives, it sets the pause point to 14. The below example messages is 2229 for the above case when the PAUSE request arrives before the first 2230 occurrence of NPT=14. 2232 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 2233 CSeq: 834 2234 Session: 12345678 2235 Range: npt=10-15, npt=13-20 2237 S->C: RTSP/1.0 200 OK 2238 CSeq: 834 2239 Date: 23 Jan 1997 15:35:06 GMT 2240 Server: PhonyServer 1.0 2241 Range: npt=10-15, npt=13-20 2242 RTP-Info:url=rtsp://example.com/fizzle/audiotrack; 2243 seq=5712;rtptime=934207921, 2244 url=rtsp://example.com/fizzle/videotrack; 2245 seq=57654;rtptime=2792482193 2246 Session: 12345678 2248 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2249 CSeq: 835 2250 Session: 12345678 2251 Range: npt=14- 2253 S->C: RTSP/1.0 200 OK 2254 CSeq: 835 2255 Date: 23 Jan 1997 15:35:09 GMT 2256 Server: PhonyServer 1.0 2257 Range: npt=14-15, npt=13-20 2258 Session: 12345678 2260 If a client issues a PAUSE request and the server acknowledges and 2261 enters the READY state, the proper server response, if the player 2262 issues another PAUSE, is still 200 OK. The 200 OK response MUST 2263 include the Range header with the current pause point, even if the 2264 PAUSE request is asking for some other pause point. See examples 2265 below: 2267 Examples: | 2269 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 | 2270 CSeq: 834 | 2271 Session: 12345678 | 2273 S->C: RTSP/1.0 200 OK | 2274 CSeq: 834 | 2275 Session: 12345678 | 2276 Date: 23 Jan 1997 15:35:06 GMT | 2277 Range: npt=45.76-98.36 | 2279 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 | 2280 CSeq: 835 | 2281 Session: 12345678 | 2282 Range: 86- | 2284 S->C: RTSP/1.0 200 OK | 2285 CSeq: 835 | 2286 Session: 12345678 | 2287 Date: 23 Jan 1997 15:35:07 GMT | 2288 Range: npt=45.76-98.36 | 2290 11.6 TEARDOWN 2292 The TEARDOWN client to server request stops the stream delivery for 2293 the given URL, freeing the resources associated with it. TEARDOWN 2294 MAY be done using either an aggregated or a media control URL. 2296 However some restrictions apply depending on the current state. The 2297 TEARDOWN request SHALL contain a Session header indicating what 2298 session the request applies to. 2300 A TEARDOWN using the aggregated control URL or the media URL in a 2301 session under non-aggregated control MAY be done in any state (Ready, 2302 and Play). A successful request SHALL result in that media delivery 2303 is immediately halted and the session state is destroyed. This SHALL 2304 be indicated through the lack of a Session header in the response. 2306 A TEARDOWN using a media URL in an aggregated session MAY only be | 2307 done in Ready state. Such a request only removes the indicated media | 2308 stream and associated resources from the session. This may result in | 2309 that a session returns to non-aggregated control, due to that it only | 2310 contains a single media. In the response to TEARDOWN request | 2311 resulting in that the session still exist SHALL contain a Session | 2312 header to indicate this. 2314 Note, the indication with the session header if sessions state remain 2315 may not be done correctly by a RFC 2326 client, but will be for any 2316 server signalling the "play.basic" tag. 2318 Example: 2320 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 2321 CSeq: 892 2322 Session: 12345678 2324 S->C: RTSP/1.0 200 OK 2325 CSeq: 892 2326 Server: PhonyServer 1.0 2328 11.7 GET_PARAMETER 2330 The GET_PARAMETER request retrieves the value of a parameter or | 2331 parameters for a presentation or stream specified in the URL. If the | 2332 Session header is present in a request, the value of a parameter MUST | 2333 be retrieved in the specified session context. The content of the | 2334 reply and response is left to the implementation. | 2336 The method MAY also be used without a body (entity). If the this | 2337 request is successful, i.e. a 200 OK response is received, then the | 2338 keep-alive time has been updated. Any non-required header present in | 2339 such a request, may or may not been processed. The allow a client to | 2340 determine if any such header has been processed, it is necessary to | 2341 use a feature tag and the Require header. Due to this reason it is | 2342 RECOMMENDED that any parameters to be retrieved are sent in the body, | 2343 rather than using any header. 2345 Example: 2347 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 2348 CSeq: 431 2349 Content-Type: text/parameters 2350 Session: 12345678 2351 Content-Length: 15 2353 packets_received 2354 jitter 2356 C->S: RTSP/1.0 200 OK 2357 CSeq: 431 2358 Content-Length: 46 2359 Content-Type: text/parameters 2361 packets_received: 10 2362 jitter: 0.3838 2364 The "text/parameters" section is only an example type for 2365 parameter. This method is intentionally loosely defined 2366 with the intention that the reply content and response 2367 content will be defined after further experimentation. 2369 11.8 SET_PARAMETER 2371 This method requests to set the value of a parameter or a set of | 2372 parameters for a presentation or stream specified by the URL. The | 2373 method MAY also be used without a body (entity). If the this request | 2374 is successful, i.e. a 200 OK response is received, then the keep- | 2375 alive time has been updated. Any non-required header present in such | 2376 a request, may or may not been processed. The allow a client to | 2377 determine if any such header has been processed, it is necessary to | 2378 use a feature tag and the Require header. Due to this reason it is | 2379 RECOMMENDED that any parameters are sent in the body, rather than | 2380 using any header. 2382 A request is RECOMMENDED to only contain a single parameter to allow 2383 the client to determine why a particular request failed. If the 2384 request contains several parameters, the server MUST only act on the 2385 request if all of the parameters can be set successfully. A server 2386 MUST allow a parameter to be set repeatedly to the same value, but it 2387 MAY disallow changing parameter values. If the receiver of the 2388 request does not understand or can locate a parameter error 451 2389 (Parameter Not Understood) SHALL be used. In the case a parameter is 2390 not allowed to change the error code 458 (Parameter Is Read-Only). 2391 The response body SHOULD contain only the parameters that has errors. 2392 Otherwise no body SHALL be returned. 2394 Note: transport parameters for the media stream MUST only be set with 2395 the SETUP command. 2397 Restricting setting transport parameters to SETUP is for 2398 the benefit of firewalls. 2400 The parameters are split in a fine-grained fashion so that 2401 there can be more meaningful error indications. However, it 2402 may make sense to allow the setting of several parameters 2403 if an atomic setting is desirable. Imagine device control 2404 where the client does not want the camera to pan unless it 2405 can also tilt to the right angle at the same time. 2407 Example: 2409 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 2410 CSeq: 421 2411 Content-length: 20 2412 Content-type: text/parameters 2414 barparam: barstuff 2416 S->C: RTSP/1.0 451 Parameter Not Understood 2417 CSeq: 421 2418 Content-length: 10 2419 Content-type: text/parameters 2421 barparam 2423 The "text/parameters" section is only an example type for 2424 parameter. This method is intentionally loosely defined 2425 with the intention that the reply content and response 2426 content will be defined after further experimentation. 2428 11.9 REDIRECT 2430 A redirect request informs the client that it MUST connect to another 2431 server location. The REDIRECT request MAY contain the header 2432 Location, which indicates that the client should issue requests for 2433 that URL. The lack of a Location header in the response SHALL be 2434 interpreted as that the server can't any longer fulfill the current 2435 request, but has no alternative at the present where the client can 2436 continue. 2438 If a REDIRECT request contains a Session header, it is end-to-end and 2439 applies only to the given session. If there are proxies in the 2440 request chain, they SHOULD NOT disconnect the control channel unless 2441 there are no remaining sessions. If the Location header is included 2442 it SHALL contain a full absolute URL pointing out the resource to 2443 reconnect too, i.e. the Location SHALL NOT contain only host and 2444 port. 2446 If a REDIRECT request does not contain a Session header, it is next- 2447 hop and applies also to the control connection. If the Location 2448 header is included it SHOULD only contain an absolute URL containing 2449 the host address and OPTIONAL the port number. If there are proxies 2450 in the request chain, they SHOULD do all of the following: (1) 2451 respond to the REDIRECT request, (2) disconnect the control channel 2452 from the requestor, (3) reconnect to the given host address, and (4) 2453 pass the request to each applicable client (typically those clients 2454 with an active session or unanswered request from the requestor). 2455 Note that the proxy is responsible for accepting the REDIRECT 2456 response from its clients and these responses MUST NOT be passed on 2457 to either the requesting or the destination server. 2459 A REDIRECT request with a Session header MAY only be received by a | 2460 client when it has the established session. A REDIRECT request | 2461 without a Session MAY be received at any time communication is | 2462 established with the server. 2464 The redirect request MAY contain the header Range, which indicates 2465 when the redirection takes effect. If the Range contains a "time=" 2466 value that is the wall clock time that the redirection MUST at the 2467 latest take place. When the "time=" parameter is present the range 2468 value MUST be ignored. However the range entered MUST be syntactical 2469 correct and SHALL point at the beginning of any on-demand content. If 2470 no time parameter is part of the Range header then redirection SHALL 2471 take place when the media playout from the server reaches the given 2472 time. The range value MUST be a single value in the open ended form, 2473 e.g. npt=59-. 2475 A server upon receiving a successful (2xx) response for a REDIRECT 2476 request without any Range header SHALL consider the session as 2477 removed and can free any session state. For this type of requests 2478 the rest of this paragraph applies. The server MAY close the 2479 signalling connection upon receiving the response for REDIRECT 2480 requests without a Session header. The client SHOULD close the 2481 signaling connection after having given the 2xx response to a 2482 REDIRECT response, unless it has several sessions on the server. If 2483 the client has multiple session on the server it SHOULD close the 2484 connection when it has received and responded to REDIRECT requests 2485 for all sessions. 2487 A client receiving a REDIRECT request with a Range header SHALL issue 2488 a TEARDOWN request when the in indicated redirect point is reached. 2489 The client SHOULD for REDIRECT requests with Range header close the 2490 signalling connection after a 2xx response on its TEARDOWN request. 2491 The normal connection considerations apply for the server. This 2492 differentiation from REDIRECT requests without range headers is to 2493 allow clear an explicit state handling. As the state in the server 2494 needs to be kept until the point of redirection, the handling becomes 2495 more clear if the client is required to tear down the session at that 2496 point. 2498 If the client wants to continue to send or receive media for this 2499 resource, the client will have to establish a new session with the 2500 designated host. A client SHOULD issue a new DESCRIBE request with 2501 the URL given in the Location header, unless the URL only contains a 2502 host address. In the cases the Location only contains a host address 2503 the client MAY assume that the media on the server it is redirected 2504 to is identical. Identical media means that all media configuration 2505 information from the old session still is valid except for the host 2506 address. In the case of absolute URLs in the location header the 2507 media redirected to can be either identical, slightly different or 2508 totally different. This is the reason why a new DESCRIBE request 2509 SHOULD be issued. 2511 This example request redirects traffic for this session to the new 2512 server at the given absolute time: 2514 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 2515 CSeq: 732 2516 Location: rtsp://s2.example.com:8001 2517 Range: npt=0- ;time=19960213T143205Z 2518 Session: uZ3ci0K+Ld-M 2520 11.10 PING 2521 This method is a bi-directional mechanism for server or client 2522 liveness checking. It has no side effects. The issuer of the request 2523 MUST include a session header with the session ID of the session that 2524 is being checked for liveness. 2526 Prior to using this method, an OPTIONS method is RECOMMENDED to be 2527 issued in the direction which the PING method would be used. This 2528 method MUST NOT be used if support is not indicated by the Public 2529 header. Note: That an 501 (Not Implemented) response means that the 2530 keep-alive timer has not been updated. 2532 When a proxy is in use, PING with a * indicates a single-hop liveness 2533 check, whereas PING with a URL including an host address indicates an 2534 end-to-end liveness check. 2536 Example: 2538 C->S: PING * RTSP/1.0 2539 CSeq: 123 2540 Session:12345678 2542 S->C: RTSP/1.0 200 OK 2543 CSeq: 123 2544 Session:12345678 2546 12 Embedded (Interleaved) Binary Data 2548 Certain firewall designs and other circumstances may force a server 2549 to interleave RTSP messages and media stream data. This interleaving 2550 should generally be avoided unless necessary since it complicates 2551 client and server operation and imposes additional overhead. Also 2552 head of line blocking may cause problems. Interleaved binary data 2553 SHOULD only be used if RTSP is carried over TCP. 2555 Stream data such as RTP packets is encapsulated by an ASCII dollar 2556 sign (24 decimal), followed by a one-byte channel identifier, 2557 followed by the length of the encapsulated binary data as a binary, 2558 two-byte integer in network byte order. The stream data follows 2559 immediately afterwards, without a CRLF, but including the upper-layer 2560 protocol headers. Each $ block SHALL contain exactly one upper-layer 2561 protocol data unit, e.g., one RTP packet. 2563 0 1 2 3 2564 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 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | "$" = 24 | Channel ID | Length in bytes | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 : Length number of bytes of binary data : 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 The channel identifier is defined in the Transport header with the 2572 interleaved parameter(Section 14.40). 2574 When the transport choice is RTP, RTCP messages are also interleaved 2575 by the server over the TCP connection. The usage of RTCP messages is 2576 indicated by including a range containing a second channel in the 2577 interleaved parameter of the Transport header, see section 14.40. If 2578 RTCP is used, packets SHALL be sent on the first available channel 2579 higher than the RTP channel. The channels are bi-directional and 2580 therefore RTCP traffic are sent on the second channel in both 2581 directions. 2583 RTCP is needed for synchronization when two or more streams 2584 are interleaved in such a fashion. Also, this provides a 2585 convenient way to tunnel RTP/RTCP packets through the TCP 2586 control connection when required by the network 2587 configuration and transfer them onto UDP when possible. 2589 C->S: SETUP rtsp://example.com/bar.file RTSP/1.0 | 2590 CSeq: 2 | 2591 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 | 2593 S->C: RTSP/1.0 200 OK | 2594 CSeq: 2 | 2595 Date: 05 Jun 1997 18:57:18 GMT | 2596 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 | 2597 Session: 12345678 | 2599 C->S: PLAY rtsp://example.com/bar.file RTSP/1.0 | 2600 CSeq: 3 | 2601 Session: 12345678 | 2603 S->C: RTSP/1.0 200 OK | 2604 CSeq: 3 | 2605 Session: 12345678 | 2606 Date: 05 Jun 1997 18:59:15 GMT | 2607 RTP-Info: url=rtsp://example.com/bar.file; | 2608 seq=232433;rtptime=972948234 | 2610 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} | 2611 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} | 2612 S->C: $006{2 byte length}{"length" bytes RTCP packet} | 2614 13 Status Code Definitions 2616 Where applicable, HTTP status [H10] codes are reused. Status codes 2617 that have the same meaning are not repeated here. See Table 4 for a 2618 listing of which status codes may be returned by which requests. All 2619 error messages, 4xx and 5xx MAY return a body containing further 2620 information about the error. 2622 13.1 Success 1xx 2624 13.1.1 100 Continue 2626 See, [H10.1.1]. 2628 13.2 Success 2xx 2630 13.3 Redirection 3xx 2632 The notation "3rr" indicates response codes from 300 to 399 inclusive 2633 which are meant for redirection. The response code 304 is excluded 2634 from this set, as it is not used for redirection. 2636 See [H10.3] for definition of status code 300 to 305. However 2637 comments are given for some to how they apply to RTSP. 2639 Within RTSP, redirection may be used for load balancing or 2640 redirecting stream requests to a server topologically closer to the 2641 client. Mechanisms to determine topological proximity are beyond the 2642 scope of this specification. 2644 A 3rr code MAY be used to respond to any request. It is RECOMMENDED | 2645 that they are used if necessary before a session is established, i.e. | 2646 in response to DESCRIBE or SETUP. However in cases where a server is | 2647 not able to send a REDIRECT request to the client, the server MAY | 2648 need to resort to using 3rr responses to inform a client with a | 2649 established session about the need for redirecting the session. If an | 2650 3rr response is received for an request in relation to a established | 2651 session, the client SHOULD send a TEARDOWN request for the session, | 2652 and MAY reestablish the session using the resource indicated by the | 2653 Location. 2655 If the the Location header is used in a response it SHALL contain an 2656 absolute URL pointing out the media resource the client is redirected 2657 to, the URL SHALL NOT only contain the host name. 2659 13.3.1 300 Multiple Choices 2661 13.3.2 301 Moved Permanently 2663 The request resource are moved permanently and resides now at the URL 2664 given by the location header. The user client SHOULD redirect 2665 automatically to the given URL. This response MUST NOT contain a 2666 message-body. 2668 13.3.3 302 Found 2670 The requested resource reside temporarily at the URL given by the 2671 Location header. The Location header MUST be included in the 2672 response. Is intended to be used for many types of temporary 2673 redirects, e.g. load balancing. It is RECOMMENDED that one set the 2674 reason phrase to something more meaningful than "Found" in these 2675 cases. The user client SHOULD redirect automatically to the given 2676 URL. This response MUST NOT contain a message-body. 2678 13.3.4 303 See Other 2680 This status code SHALL NOT be used in RTSP. However as it was allowed | 2681 to use in RFC 2326 it is possible that such response may be received, | 2682 in which case the behavior is undefined. 2684 13.3.5 304 Not Modified 2686 If the client has performed a conditional DESCRIBE or SETUP (see 2687 12.23) and the requested resource has not been modified, the server 2688 SHOULD send a 304 response. This response MUST NOT contain a 2689 message-body. 2691 The response MUST include the following header fields: 2693 o Date 2695 o ETag and/or Content-Location, if the header would have been 2696 sent in a 200 response to the same request. 2698 o Expires, Cache-Control, and/or Vary, if the field-value might 2699 differ from that sent in any previous response for the same 2700 variant. 2702 This response is independent for the DESCRIBE and SETUP requests. 2703 That is, a 304 response to DESCRIBE does NOT imply that the resource 2704 content is unchanged and a 304 response to SETUP does NOT imply that 2705 the resource description is unchanged. The ETag and If-Match headers 2706 may be used to link the DESCRIBE and SETUP in this manner. 2708 13.3.6 305 Use Proxy 2710 See [H10.3.6]. 2712 13.4 Client Error 4xx 2714 13.4.1 400 Bad Request 2716 The request could not be understood by the server due to malformed 2717 syntax. The client SHOULD NOT repeat the request without 2718 modifications [H10.4.1]. If the request does not have a CSeq header, 2719 the server MUST NOT include a CSeq in the response. 2721 13.4.2 405 Method Not Allowed 2723 The method specified in the request is not allowed for the resource 2724 identified by the request URL. The response MUST include an Allow 2725 header containing a list of valid methods for the requested resource. 2726 This status code is also to be used if a request attempts to use a 2727 method not indicated during SETUP, e.g., if a RECORD request is 2728 issued even though the mode parameter in the Transport header only 2729 specified PLAY. 2731 13.4.3 451 Parameter Not Understood 2733 The recipient of the request does not support one or more parameters 2734 contained in the request.When returning this error message the sender 2735 SHOULD return a entity body containing the offending parameter(s). 2737 13.4.4 452 reserved 2739 This error code was removed from RFC 2326 [1] and is obsolete. 2741 13.4.5 453 Not Enough Bandwidth 2743 The request was refused because there was insufficient bandwidth. 2744 This may, for example, be the result of a resource reservation 2745 failure. 2747 13.4.6 454 Session Not Found 2749 The RTSP session identifier in the Session header is missing, 2750 invalid, or has timed out. 2752 13.4.7 455 Method Not Valid in This State 2754 The client or server cannot process this request in its current 2755 state. The response SHOULD contain an Allow header to make error 2756 recovery easier. 2758 13.4.8 456 Header Field Not Valid for Resource 2760 The server could not act on a required request header. For example, 2761 if PLAY contains the Range header field but the stream does not allow 2762 seeking. This error message may also be used for specifying when the 2763 time format in Range is impossible for the resource. In that case the 2764 Accept-Ranges header SHOULD be returned to inform the client of which 2765 format(s) that are allowed. 2767 13.4.9 457 Invalid Range 2769 The Range value given is out of bounds, e.g., beyond the end of the 2770 presentation. 2772 13.4.10 458 Parameter Is Read-Only 2774 The parameter to be set by SET_PARAMETER can be read but not 2775 modified. When returning this error message the sender SHOULD return 2776 a entity body containing the offending parameter(s). 2778 13.4.11 459 Aggregate Operation Not Allowed 2780 The requested method may not be applied on the URL in question since 2781 it is an aggregate (presentation) URL. The method may be applied on a 2782 media URL. 2784 13.4.12 460 Only Aggregate Operation Allowed 2786 The requested method may not be applied on the URL in question since 2787 it is not an aggregate control (presentation) URL. The method may be 2788 applied on the aggregate control URL. 2790 13.4.13 461 Unsupported Transport 2792 The Transport field did not contain a supported transport 2793 specification. 2795 13.4.14 462 Destination Unreachable 2797 The data transmission channel could not be established because the 2798 client address could not be reached. This error will most likely be 2799 the result of a client attempt to place an invalid Destination 2800 parameter in the Transport field. 2802 13.5 Server Error 5xx 2804 13.5.1 551 Option not supported 2806 An feature-tag given in the Require or the Proxy-Require fields was 2807 not supported. The Unsupported header SHOULD be returned stating the 2808 feature for which there is no support. 2810 14 Header Field Definitions 2812 method direction object acronym Body 2813 _________________________________________________ 2814 DESCRIBE C -> S P,S DES r 2815 GET_PARAMETER C -> S, S -> C P,S GPR R,r 2816 OPTIONS C -> S P,S OPT 2817 S -> C 2818 PAUSE C -> S P,S PSE 2819 PING C -> S, S -> C P,S PNG 2820 PLAY C -> S P,S PLY 2821 REDIRECT S -> C P,S RDR 2822 SETUP C -> S S STP 2823 SET_PARAMETER C -> S, S -> C P,S SPR R,r 2824 TEARDOWN C -> S P,S TRD 2826 Table 8: Overview of RTSP methods, their direction, and what objects 2827 (P: presentation, S: stream) they operate on. Body notes if a method 2828 is allowed to carry body and in which direction, R = Request, 2829 r=response. Note: It is allowed for all error messages 4xx and 5xx to 2830 have a body 2832 The general syntax for header fields is covered in Section 4.2 This 2833 section lists the full set of header fields along with notes on 2834 meaning, and usage. The syntax definition for headers are present in 2835 section 17.2.3. Throughout this section, we use [HX.Y] to refer to 2836 Section X.Y of the current HTTP/1.1 specification RFC 2616 [4]. 2837 Examples of each header field are given. 2839 Information about header fields in relation to methods and proxy 2840 processing is summarized in Table 9 and Table 10. 2842 The "where" column describes the request and response types in which 2843 the header field can be used. Values in this column are: 2845 R: header field may only appear in requests; 2847 r: header field may only appear in responses; 2849 2xx, 4xx, etc.: A numerical value or range indicates response 2850 codes with which the header field can be used; 2852 c: header field is copied from the request to the response. 2854 An empty entry in the "where" column indicates that the header field 2855 may be present in all requests and responses. 2857 The "proxy" column describes the operations a proxy may perform on a 2858 header field: 2860 a: A proxy can add or concatenate the header field if not 2861 present. 2863 m: A proxy can modify an existing header field value. 2865 d: A proxy can delete a header field value. 2867 r: A proxy must be able to read the header field, and thus this 2868 header field cannot be encrypted. 2870 The rest of the columns relate to the presence of a header field in a 2871 method. The method names when abbreviated, are according to table 8: 2873 c: Conditional; requirements on the header field depend on the 2874 context of the message. 2876 m: The header field is mandatory. 2878 m*: The header field SHOULD be sent, but clients/servers need to 2879 be prepared to receive messages without that header field. 2881 o: The header field is optional. 2883 *: The header field is required if the message body is not 2884 empty. See sections 14.14, 14.16 and 4.3 for details. 2886 -: The header field is not applicable. 2887 "Optional" means that a Client/Server MAY include the header | 2888 field in a request or response. The Client/Server behavior when | 2889 receiving such headers varies, for some it may ignore the header | 2890 field, in other case it is request to process the header. This | 2891 is regulated by the method and header descriptions. Example of | 2892 such headers that require processing are the Require and Proxy- | 2893 Require header fields discussed in 14.32 and 14.27. A | 2894 "mandatory" header field MUST be present in a request, and MUST | 2895 be understood by the Client/Server receiving the request. A | 2896 mandatory response header field MUST be present in the response, | 2897 and the header field MUST be understood by the Client/Server | 2898 processing the response. "Not applicable" means that the header | 2899 field MUST NOT be present in a request. If one is placed in a | 2900 request by mistake, it MUST be ignored by the Client/Server | 2901 receiving the request. Similarly, a header field labeled "not | 2902 applicable" for a response means that the Client/Server MUST NOT | 2903 place the header field in the response, and the Client/Server | 2904 MUST ignore the header field in the response. 2906 A Client/Server SHOULD ignore extension header parameters that are 2907 not understood. 2909 The From, Location, and RTP-Info header fields contain a URL. If the 2910 URL contains a comma, or semicolon, the URL MUST be enclosed in 2911 double quotas ("). Any URL parameters are contained within these 2912 quotas. If the URL is not enclosed in double quotas, any semicolon- 2913 delimited parameters are header-parameters, not URL parameters. 2915 14.1 Accept 2917 The Accept request-header field can be used to specify certain 2918 presentation description content types which are acceptable for the 2919 response. 2921 The "level" parameter for presentation descriptions is 2922 properly defined as part of the MIME type registration, not 2923 here. 2925 See [H14.1] for syntax. 2927 Example of use: | 2929 Accept: application/rtsl q=1.0, application/sdp | 2931 14.2 Accept-Encoding 2932 See [H14.3] 2934 14.3 Accept-Language 2936 See [H14.4]. Note that the language specified applies to the 2937 presentation description and any reason phrases, not the media 2938 content. 2940 14.4 Accept-Ranges 2942 The Accept-Ranges response-header field allows the server to indicate 2943 its acceptance of range requests and possible formats for a resource: 2945 Accept-Ranges: NPT, SMPTE 2947 This header has the same syntax as [H14.5] and the syntax is defined 2948 in 17.2.3. However new range-units are defined. Inclusion of any of 2949 the time formats indicates acceptance by the server for PLAY and 2950 PAUSE requests with this format. The headers value is valid for the 2951 resource specified by the URL in the request, this response 2952 corresponds to. A server SHOULD use this header in SETUP responses to 2953 indicate to the client which range time formats the media supports. 2954 The header SHOULD also be included in "456" responses which is a 2955 result of use of unsupported range formats. 2957 14.5 Allow 2959 The Allow entity-header field lists the methods supported by the 2960 resource identified by the request-URL. The purpose of this field is 2961 to strictly inform the recipient of valid methods associated with the 2962 resource. An Allow header field MUST be present in a 405 (Method Not 2963 Allowed) response. See [H14.7] for syntax definition. 2965 Example of use: 2967 Allow: SETUP, PLAY, SET_PARAMETER 2969 14.6 Authorization 2971 See [H14.8] 2973 14.7 Bandwidth 2974 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 2975 _____________________________________________________________ 2976 Accept R o - - - - - 2977 Accept-Encoding R r o - - - - - 2978 Accept-Language R r o - - - - - 2979 Accept-Ranges r r - - o - - - 2980 Accept-Ranges 456 r - - - o o - 2981 Allow r - o - - - - 2982 Allow 405 m m m m m m 2983 Authorization R o o o o o o 2984 Bandwidth R o o o o - - 2985 Blocksize R o - o o - - 2986 Cache-Control r - - o - - - 2987 Connection o o o o o o 2988 Content-Base r o - - - - - 2989 Content-Base 4xx o o o o o o 2990 Content-Encoding R r - - - - - - 2991 Content-Encoding r r o - - - - - 2992 Content-Encoding 4xx r o o o o o o 2993 Content-Language R r - - - - - - 2994 Content-Language r r o - - - - - 2995 Content-Language 4xx r o o o o o o 2996 Content-Length r r * - - - - - 2997 Content-Length 4xx r * * * * * * 2998 Content-Location r o - - - - - 2999 Content-Location 4xx o o o o o o 3000 Content-Type r * - - - - - 3001 Content-Type 4xx * * * * * * 3002 CSeq Rc m m m m m m 3003 Date am o o o o o o 3004 Expires r r o - - - - - 3005 From R r o o o o o o 3006 Host - - - - - - 3007 If-Match R r - - o - - - 3008 If-Modified-Since R r o - o - - - 3009 Last-Modified r r o - - - - - 3010 Location 3rr o o o o o o 3011 Proxy-Authenticate 407 amr m m m m m m 3012 Proxy-Require R ar o o o o o o 3013 Public r admr - m* - - - - 3014 Public 501 admr m* m* m* m* m* m* 3015 Range R - - - o o - 3016 Range r - - c m* m* - 3017 Referer R o o o o o o 3018 Require R o o o o o o 3019 Retry-After 3rr,503 o o o - - - 3020 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3021 _________________________________________________________ 3022 Scale - - - o - - 3023 Session R - o o m m m 3024 Session r - c m m m o 3025 Server R - o - - - - 3026 Server r o o o o o o 3027 Speed - - - o - - 3028 Supported R o o o o o o 3029 Supported r c c c c c c 3030 Timestamp R o o o o o o 3031 Timestamp c m m m m m m 3032 Transport - - m - - - 3033 Unsupported r c c c c c c 3034 User-Agent R m* m* m* m* m* m* 3035 Vary r c c c c c c 3036 Via R amr o o o o o o 3037 Via c dr m m m m m m 3038 WWW-Authenticate 401 m m m m m m 3040 _________________________________________________________ 3041 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3043 Table 9: Overview of RTSP header fields related to methods DESCRIBE, 3044 OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3046 The Bandwidth request-header field describes the estimated bandwidth 3047 available to the client, expressed as a positive integer and measured 3048 in bits per second. The bandwidth available to the client may change 3049 during an RTSP session, e.g., due to modem retraining. 3051 Example: 3053 Bandwidth: 4000 3055 14.8 Blocksize 3057 The Blocksize request-header field is sent from the client to the 3058 media server asking the server for a particular media packet size. 3059 This packet size does not include lower-layer headers such as IP, 3060 UDP, or RTP. The server is free to use a blocksize which is lower 3061 than the one requested. The server MAY truncate this packet size to 3062 the closest multiple of the minimum, media-specific block size, or 3063 override it with the media-specific size if necessary. The block size 3064 MUST be a positive decimal number, measured in octets. The server 3065 Header Where Proxy GPR SPR RDR PNG 3066 __________________________________________________ 3067 Allow 405 m m m m 3068 Authorization R o o o o 3069 Bandwidth R - o - - 3070 Blocksize R - o - - 3071 Connection o o o - 3072 Content-Base R o o - - 3073 Content-Base r o o - - 3074 Content-Base 4xx o o o - 3075 Content-Encoding R r o o - - 3076 Content-Encoding r r o o - - 3077 Content-Encoding 4xx r o o o - 3078 Content-Language R r o o - - 3079 Content-Language r r o o - - 3080 Content-Language 4xx r o o o - 3081 Content-Length R r * * - - 3082 Content-Length r r * * - - 3083 Content-Length 4xx r * * * - 3084 Content-Location R o o - - 3085 Content-Location r o o - - 3086 Content-Location 4xx o o o - 3087 Content-Type R * * - - 3088 Content-Type r * * - - 3089 Content-Type 4xx * * * - 3090 CSeq Rc m m m m 3091 Date am o o o o 3092 From R r o o o o 3093 Host - - - - 3094 Last-Modified R r - - - - 3095 Last-Modified r r o - - - 3096 Location 3rr o o o o 3097 Location R - - m - 3098 Proxy-Authenticate 407 amr m m m m 3099 Proxy-Require R ar o o o o 3100 Public 501 admr m* m* m* m* 3101 Range R - - o - 3102 Referer R o o o - 3103 Require R o o o o 3104 Retry-After 3rr,503 o o - - 3105 Scale - - - - 3106 Session R o o o m 3107 Session r c c o m 3108 Server R o o o o 3109 Server r o o - o 3110 Supported R o o o o 3111 Timestamp c m m m m 3112 Unsupported r c c c c 3113 User-Agent R m* m* - m* 3114 User-Agent r - - m* - 3115 Vary r c c - - 3116 Via R amr o o o o 3117 Via c dr m m m m 3118 WWW-Authenticate 401 m m m m 3119 __________________________________________________ 3120 Header Where Proxy GPR SPR RDR PNG 3122 Table 10: Overview of RTSP header fields related to methods 3123 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. 3125 only returns an error (4xx) if the value is syntactically invalid. 3127 14.9 Cache-Control 3129 The Cache-Control general-header field is used to specify directives 3130 that MUST be obeyed by all caching mechanisms along the 3131 request/response chain. 3133 Cache directives must be passed through by a proxy or gateway 3134 application, regardless of their significance to that application, 3135 since the directives may be applicable to all recipients along the 3136 request/response chain. It is not possible to specify a cache- 3137 directive for a specific cache. 3139 Cache-Control should only be specified in a SETUP request and its | 3140 response. Note: Cache-Control does not govern the caching of | 3141 responses as for HTTP, instead it applies to the media stream | 3142 identified by the SETUP request. The caching of RTSP requests are | 3143 generally not cacheable, for further information see 15. Below is the | 3144 description of the cache directives that can be included in the | 3145 Cache-Control header. 3147 no-cache: Indicates that the media stream MUST NOT be cached 3148 anywhere. This allows an origin server to prevent caching 3149 even by caches that have been configured to return stale 3150 responses to client requests. 3152 public: Indicates that the media stream is cacheable by any 3153 cache. 3155 private: Indicates that the media stream is intended for a 3156 single user and MUST NOT be cached by a shared cache. A 3157 private (non-shared) cache may cache the media stream. 3159 no-transform: An intermediate cache (proxy) may find it useful 3160 to convert the media type of a certain stream. A proxy 3161 might, for example, convert between video formats to save 3162 cache space or to reduce the amount of traffic on a slow 3163 link. Serious operational problems may occur, however, 3164 when these transformations have been applied to streams 3165 intended for certain kinds of applications. For example, 3166 applications for medical imaging, scientific data analysis 3167 and those using end-to-end authentication all depend on 3168 receiving a stream that is bit-for-bit identical to the 3169 original media stream. Therefore, if a response includes 3170 the no-transform directive, an intermediate cache or proxy 3171 MUST NOT change the encoding of the stream. Unlike HTTP, 3172 RTSP does not provide for partial transformation at this 3173 point, e.g., allowing translation into a different 3174 language. 3176 only-if-cached: In some cases, such as times of extremely poor 3177 network connectivity, a client may want a cache to return 3178 only those media streams that it currently has stored, and 3179 not to receive these from the origin server. To do this, 3180 the client may include the only-if-cached directive in a 3181 request. If it receives this directive, a cache SHOULD 3182 either respond using a cached media stream that is 3183 consistent with the other constraints of the request, or 3184 respond with a 504 (Gateway Timeout) status. However, if a 3185 group of caches is being operated as a unified system with 3186 good internal connectivity, such a request MAY be forwarded 3187 within that group of caches. 3189 max-stale: Indicates that the client is willing to accept a 3190 media stream that has exceeded its expiration time. If 3191 max-stale is assigned a value, then the client is willing 3192 to accept a response that has exceeded its expiration time 3193 by no more than the specified number of seconds. If no 3194 value is assigned to max-stale, then the client is willing 3195 to accept a stale response of any age. 3197 min-fresh: Indicates that the client is willing to accept a 3198 media stream whose freshness lifetime is no less than its 3199 current age plus the specified time in seconds. That is, 3200 the client wants a response that will still be fresh for at 3201 least the specified number of seconds. 3203 must-revalidate: When the must-revalidate directive is present 3204 in a SETUP response received by a cache, that cache MUST 3205 NOT use the entry after it becomes stale to respond to a 3206 subsequent request without first revalidating it with the 3207 origin server. That is, the cache must do an end-to-end 3208 revalidation every time, if, based solely on the origin 3209 server's Expires, the cached response is stale.) 3211 proxy-revalidate: The proxy-revalidate directive has the same 3212 meaning as the must-revalidate directive, except that it 3213 does not apply to non-shared user agent caches. It can be 3214 used on a response to an authenticated request to permit 3215 the user's cache to store and later return the response 3216 without needing to revalidate it (since it has already been 3217 authenticated once by that user), while still requiring 3218 proxies that service many users to revalidate each time (in 3219 order to make sure that each user has been authenticated). 3220 Note that such authenticated responses also need the public 3221 cache control directive in order to allow them to be cached 3222 at all. 3224 max-age: When an intermediate cache is forced, by means of a 3225 max-age=0 directive, to revalidate its own cache entry, and 3226 the client has supplied its own validator in the request, 3227 the supplied validator might differ from the validator 3228 currently stored with the cache entry. In this case, the 3229 cache MAY use either validator in making its own request 3230 without affecting semantic transparency. 3232 However, the choice of validator might affect performance. 3233 The best approach is for the intermediate cache to use its 3234 own validator when making its request. If the server 3235 replies with 304 (Not Modified), then the cache can return 3236 its now validated copy to the client with a 200 (OK) 3237 response. If the server replies with a new entity and cache 3238 validator, however, the intermediate cache can compare the 3239 returned validator with the one provided in the client's 3240 request, using the strong comparison function. If the 3241 client's validator is equal to the origin server's, then 3242 the intermediate cache simply returns 304 (Not Modified). 3243 Otherwise, it returns the new entity with a 200 (OK) 3244 response. 3246 14.10 Connection 3248 See [H14.10]. The use of the connection option "close" in RTSP 3249 messages SHOULD be limited to error messages when the server is 3250 unable to recover and therefore see it necessary to close the 3251 connection. The reason is that the client shall have the choice of 3252 continue using a connection indefinitely as long as it sends valid 3253 messages. 3255 14.11 Content-Base 3257 The Content-Base entity-header field may be used to specify the base 3258 URL for resolving relative URLs within the entity. 3260 Content-Base: rtsp://media.example.com/movie/twister 3262 If no Content-Base field is present, the base URL of an entity is 3263 defined either by its Content-Location (if that Content-Location URL 3264 is an absolute URL) or the URL used to initiate the request, in that 3265 order of precedence. Note, however, that the base URL of the contents 3266 within the entity-body may be redefined within that entity-body. 3268 14.12 Content-Encoding 3270 See [H14.11] 3272 14.13 Content-Language 3274 See [H14.12] 3276 14.14 Content-Length 3278 The Content-Length general-header field contains the length of the 3279 content of the method (i.e. after the double CRLF following the last 3280 header). Unlike HTTP, it MUST be included in all messages that carry 3281 content beyond the header portion of the message. If it is missing, a 3282 default value of zero is assumed. It is interpreted according to 3283 [H14.13]. 3285 14.15 Content-Location 3287 See [H14.14] 3289 14.16 Content-Type 3291 See [H14.17]. Note that the content types suitable for RTSP are 3292 likely to be restricted in practice to presentation descriptions and 3293 parameter-value types. 3295 14.17 CSeq 3297 The CSeq general-header field specifies the sequence number for an | 3298 RTSP request-response pair. This field MUST be present in all | 3299 requests and responses. For every RTSP request containing the given | 3300 sequence number, the corresponding response will have the same | 3301 number. Any retransmitted request must contain the same sequence | 3302 number as the original (i.e. the sequence number is not incremented | 3303 for retransmissions of the same request). For each new RTSP request | 3304 the CSeq value SHALL be incremented by one. The initial sequence | 3305 number MAY be any number, however it is RECOMMENDED to start at 1. | 3306 Each sequence number series is unique between each requester and | 3307 responder, i.e. the client has one series for its request to a server | 3308 and the server has another when sending request to the client. Each | 3309 requester and responder is identified with its network address. 3311 Example: 3313 CSeq: 239 3315 14.18 Date 3317 See [H14.18]. An RTSP message containing a body MUST include a Date 3318 header if the sending host has a clock. Servers SHOULD include a Date 3319 header in all other RTSP messages. 3321 14.19 Expires 3323 The Expires entity-header field gives a date and time after which the 3324 description or media-stream should be considered stale. The 3325 interpretation depends on the method: 3327 DESCRIBE response: The Expires header indicates a date and time 3328 after which the description SHOULD be considered stale. 3330 SETUP response: The Expires header indicate a date and time 3331 after which the media stream SHOULD be considered stale. 3333 A stale cache entry may not normally be returned by a cache (either a 3334 proxy cache or an user agent cache) unless it is first validated with 3335 the origin server (or with an intermediate cache that has a fresh 3336 copy of the entity). See section 15 for further discussion of the 3337 expiration model. 3339 The presence of an Expires field does not imply that the original 3340 resource will change or cease to exist at, before, or after that 3341 time. 3343 The format is an absolute date and time as defined by HTTP-date in 3344 [H3.3]; it MUST be in RFC1123-date format: 3346 An example of its use is 3348 Expires: Thu, 01 Dec 1994 16:00:00 GMT 3350 RTSP/1.0 clients and caches MUST treat other invalid date formats, 3351 especially including the value "0", as having occurred in the past 3352 (i.e., already expired). 3354 To mark a response as "already expired," an origin server should use 3355 an Expires date that is equal to the Date header value. To mark a 3356 response as "never expires," an origin server SHOULD use an Expires 3357 date approximately one year from the time the response is sent. 3358 RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in 3359 the future. 3361 The presence of an Expires header field with a date value of some 3362 time in the future on a media stream that otherwise would by default 3363 be non-cacheable indicates that the media stream is cacheable, unless 3364 indicated otherwise by a Cache-Control header field (Section 14.9). 3366 14.20 From 3368 See [H14.22]. 3370 14.21 Host 3372 The Host HTTP request header field [H14.23] is not needed for RTSP, 3373 and SHALL NOT be sent. It SHALL be silently ignored if received. 3375 14.22 If-Match 3377 See [H14.24]. 3379 The If-Match request-header field is especially useful for ensuring 3380 the integrity of the presentation description, in both the case where 3381 it is fetched via means external to RTSP (such as HTTP), or in the 3382 case where the server implementation is guaranteeing the integrity of 3383 the description between the time of the DESCRIBE message and the 3384 SETUP message. 3386 The identifier is an opaque identifier, and thus is not specific to 3387 any particular session description language. 3389 14.23 If-Modified-Since 3391 The If-Modified-Since request-header field is used with the DESCRIBE 3392 and SETUP methods to make them conditional. If the requested variant 3393 has not been modified since the time specified in this field, a 3394 description will not be returned from the server (DESCRIBE) or a 3395 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 3396 response SHALL be returned without any message-body. 3398 An example of the field is: 3400 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 3402 14.24 Last-Modified 3404 The Last-Modified entity-header field indicates the date and time at 3405 which the origin server believes the presentation description or 3406 media stream was last modified. See [H14.29]. For the methods 3407 DESCRIBE, the header field indicates the last modification date and 3408 time of the description, for SETUP that of the media stream. 3410 14.25 Location 3412 See [H14.30]. 3414 14.26 Proxy-Authenticate 3416 See [H14.33]. 3418 14.27 Proxy-Require 3420 The Proxy-Require request-header field is used to indicate proxy- 3421 sensitive features that MUST be supported by the proxy. Any Proxy- 3422 Require header features that are not supported by the proxy MUST be 3423 negatively acknowledged by the proxy to the client using the 3424 Unsupported header. The proxy SHALL use the 551 (Option Not 3425 Supported) status code in the response. Any feature tag included in 3426 the Proxy-Require does not apply to the server. To ensure that a 3427 feature is supported by both proxies and servers the tag must be 3428 included in also a Require header. 3430 See Section 14.32 for more details on the mechanics of this message 3431 and a usage example. 3433 Example of use: 3435 Proxy-Require: play.basic 3437 14.28 Public 3439 The Public response-header field lists the set of methods supported 3440 by the server. The purpose of this field is strictly to inform the 3441 recipient of the capabilities of the server regarding unusual 3442 methods. The methods listed may or may not be applicable to the 3443 Request-URL; the Allow header field (section 14.7) MAY be used to 3444 indicate methods allowed for a particular URL. 3446 Example of use: 3448 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3450 This header field applies only to the server directly connected to 3451 the client (i.e., the nearest neighbor in a chain of connections). 3452 If the response passes through a proxy, the proxy MUST either remove 3453 the Public header field or replace it with one applicable to its own 3454 capabilities. 3456 14.29 Range 3458 The Range request and response header field specifies a range of | 3459 time. The header is used in PLAY request to indicate the range of | 3460 time the client desires the server to play back. The Range header in | 3461 a PLAY indicates what range of time that is actually being played. In | 3462 a SETUP response the header MAY be used, to ensure correct | 3463 synchronization information after changes of transport parameters. | 3465 The range can be specified in a number of units. This specification | 3466 defines the smpte (Section 3.4), npt (Section 3.5), and clock | 3467 (Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are | 3468 normally not meaningful, and the behavior is unspecified, but they | 3469 and other extended units MAY be used. Servers supporting the Range | 3470 header MUST understand the NPT range format and SHOULD understand the | 3471 SMPTE range format. If the Range header is given in a time format | 3472 that is not understood, the recipient should return 456 (Header Field | 3473 Not Valid for Resource) and include a Accept-Ranges header indicating | 3474 which time format that is supported for this resource. 3476 The header MAY contain a time parameter in UTC, specifying the time 3477 at which the operation is to be made effective. This functionality 3478 SHALL only be used with the REDIRECT method. 3480 Ranges are half-open intervals, including the first point, but 3481 excluding the second point. In other words, a range of A-B starts 3482 exactly at time A, but stops just before B. Only the start time of a 3483 media unit such as a video or audio frame is relevant. As an example, 3484 assume that video frames are generated every 40 ms. A range of 3485 10.0-10.1 would include a video frame starting at 10.0 or later time 3486 and would include a video frame starting at 10.08, even though it 3487 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 3488 would exclude the frame at 10.08. 3490 Example: 3492 Range: clock=19960213T143205Z-;time=19970123T143720Z 3494 The notation is similar to that used for the HTTP/1.1 [4] 3495 byte-range header. It allows clients to select an excerpt 3496 from the media object, and to play from a given point to 3497 the end as well as from the current location to a given 3498 point. The start of playback can be scheduled for any time 3499 in the future, although a server may refuse to keep server 3500 resources for extended idle periods. 3502 By default, range intervals increase, where the second point is 3503 larger than the first point. 3505 Example: 3507 Range: npt=10-15 3509 However, range intervals can also decrease if the Scale header (see 3510 section 14.34) indicates a negative scale value. For example, this 3511 would be the case when a playback in reverse is desired. 3513 Example: 3515 Scale: -1 3516 Range: npt=15-10 3518 Decreasing ranges are still half open intervals as described above. 3519 Thus, For range A-B, A is closed and B is open. In the above example, 3520 15 is closed and 10 is open. An exception to this rule is the case 3521 when B=0 in a decreasing range. In this case, the range is closed on 3522 both ends, as otherwise there would be no way to reach 0 on a reverse 3523 playback. 3525 Example: 3527 Scale: -1 3528 Range: npt=15-0 3530 In this range both 15 and 0 are closed. 3532 A decreasing range interval without a corresponding negative Scale 3533 header is not valid. 3535 14.30 Referer 3537 See [H14.36]. The URL refers to that of the presentation description, 3538 typically retrieved via HTTP. 3540 14.31 Retry-After 3542 See [H14.37]. 3544 14.32 Require 3546 The Require request-header field is used by clients or servers to 3547 ensure that the other end-point supports features that are required 3548 in respect to this request. It can also be used to query if the other 3549 end-point supports certain features, however the use of the Supported 3550 (Section 14.38) is much more effective in this purpose. The server 3551 MUST respond to this header by using the Unsupported header to 3552 negatively acknowledge those feature-tags which are NOT supported. 3553 The response SHALL use the error code 551 (Option Not Supported). 3554 This header does not apply to proxies, for the same functionality in 3555 respect to proxies see, header Proxy-Require (Section 14.27). 3557 This is to make sure that the client-server interaction 3558 will proceed without delay when all features are understood 3559 by both sides, and only slow down if features are not 3560 understood (as in the example below). For a well-matched 3561 client-server pair, the interaction proceeds quickly, 3562 saving a round-trip often required by negotiation 3563 mechanisms. In addition, it also removes state ambiguity 3564 when the client requires features that the server does not 3565 understand. 3567 Example: 3569 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 3570 CSeq: 302 3571 Require: funky-feature 3572 Funky-Parameter: funkystuff 3574 S->C: RTSP/1.0 551 Option not supported 3575 CSeq: 302 3576 Unsupported: funky-feature 3578 In this example, "funky-feature" is the feature-tag which indicates 3579 to the client that the fictional Funky-Parameter field is required. 3580 The relationship between "funky-feature" and Funky-Parameter is not 3581 communicated via the RTSP exchange, since that relationship is an 3582 immutable property of "funky-feature" and thus should not be 3583 transmitted with every exchange. 3585 Proxies and other intermediary devices SHOULD ignore features that 3586 are not understood in this field. If a particular extension requires 3587 that intermediate devices support it, the extension should be tagged 3588 in the Proxy-Require field instead (see Section 14.27). 3590 14.33 RTP-Info 3592 The RTP-Info response-header field is used to set RTP-specific | 3593 parameters in the PLAY response. These parameters correspond to the | 3594 synchronization source identified by the ssrc parameter of the | 3595 Transport response header in the SETUP reponse. For streams using RTP | 3596 as transport protocol the RTP-Info header SHOULD be part of a 200 | 3597 response to PLAY. | 3599 The exclusion of the RTP-Info in a PLAY response for RTP | 3600 transported media will result in that a client needs to | 3601 synchronize the media streams using RTCP. This may have | 3602 negative impact as the RTCP can be lost, and does not need | 3603 to be particulary timely in their arrival. Also | 3604 functionality as informing the client from which packet a | 3605 seek has occurred is affected. | 3607 The RTP-Info MAY also be included in SETUP responses to provide | 3608 synchronization information when changing transport parameters, see | 3609 11.3. | 3611 The header can carry the following parameters: 3613 url: Indicates the stream URL which for which the following RTP 3614 parameters correspond, this URL MUST be the same used in 3615 the SETUP request for this media stream. Any relative URL 3616 SHALL use the request URL as base URL. 3618 seq: Indicates the sequence number of the first packet of the 3619 stream. This allows clients to gracefully deal with packets 3620 when seeking. The client uses this value to differentiate 3621 packets that originated before the seek from packets that 3622 originated after the seek. 3624 rtptime: Indicates the RTP timestamp corresponding to the time 3625 value in the Range response header. (Note: For aggregate 3626 control, a particular stream may not actually generate a 3627 packet for the Range time value returned or implied. Thus, 3628 there is no guarantee that the packet with the sequence 3629 number indicated by seq actually has the timestamp 3630 indicated by rtptime.) The client uses this value to 3631 calculate the mapping of RTP time to NPT. 3633 A mapping from RTP timestamps to NTP timestamps (wall 3634 clock) is available via RTCP. However, this 3635 information is not sufficient to generate a mapping 3636 from RTP timestamps to NPT. Furthermore, in order to 3637 ensure that this information is available at the 3638 necessary time (immediately at startup or after a 3639 seek), and that it is delivered reliably, this mapping 3640 is placed in the RTSP control channel. 3642 In order to compensate for drift for long, uninterrupted 3643 presentations, RTSP clients should additionally map NPT to 3644 NTP, using initial RTCP sender reports to do the mapping, 3645 and later reports to check drift against the mapping. 3647 Additionally, the RTP-Info header parameter fields only apply to a | 3648 single SSRC within a stream (the SSRC reported in the transport | 3649 response header; see section 14.40). If there are multiple | 3650 synchronization sources (SSRCs) present within a RTP session | 3651 transmitting media, RTCP must be used to map RTP and NTP timestamps | 3652 for those sources, for both synchronization and drift-checking. Due | 3653 to backwards compatibility reasons these shortcomings can't be fixed | 3654 without defining a new header, which is for future work if needed. 3656 Additional constraint: The syntax element "safe-url" (see section 3657 17.2.3) MUST NOT contain the semicolon (";") or comma (",") 3658 characters. The quoted-url form SHOULD only be used when a URL does 3659 not meet the safe-url constraint, in order to ensure compatibility 3660 with implementations conformant to RFC 2326 [1]. 3662 Example: | 3664 RTP-Info: url=rtsp://example.com/bar.avi/streamid=0;seq=45102, | 3665 url=rtsp://example.com/bar.avi/streamid=1;seq=30211 | 3667 14.34 Scale 3669 A scale value of 1 indicates normal play at the normal forward | 3670 viewing rate. If not 1, the value corresponds to the rate with | 3671 respect to normal viewing rate. For example, a ratio of 2 indicates | 3672 twice the normal viewing rate ("fast forward") and a ratio of 0.5 | 3673 indicates half the normal viewing rate. In other words, a ratio of 2 | 3674 has normal play time increase at twice the wallclock rate. For every | 3675 second of elapsed (wallclock) time, 2 seconds of content will be | 3676 delivered. A negative value indicates reverse direction. For certain | 3677 media transports this may require certain considerations to work | 3678 consistent, see section B.1 for description on how RTP handles this. 3680 Unless requested otherwise by the Speed parameter, the data rate 3681 SHOULD not be changed. Implementation of scale changes depends on the 3682 server and media type. For video, a server may, for example, deliver 3683 only key frames or selected key frames. For audio, it may time-scale 3684 the audio while preserving pitch or, less desirably, deliver 3685 fragments of audio. 3687 The server should try to approximate the viewing rate, but may 3688 restrict the range of scale values that it supports. The response 3689 MUST contain the actual scale value chosen by the server. 3691 If the server does not implement the possibility to scale, it will 3692 not return a Scale header. A server supporting Scale operations for 3693 PLAY SHALL indicate this with the use of the "play.scale" feature- 3694 tags. 3696 When indicating a negative scale for a reverse playback, the Range 3697 header must indicate a decreasing range as described in section 3698 14.29. 3700 Example of playing in reverse at 3.5 times normal rate: 3702 Scale: -3.5 3703 Range: npt=15-10 3705 14.35 Speed 3706 The Speed request-header field requests the server to deliver data to 3707 the client at a particular speed, contingent on the server's ability 3708 and desire to serve the media stream at the given speed. 3709 Implementation by the server is OPTIONAL. The default is the bit rate 3710 of the stream. 3712 The parameter value is expressed as a decimal ratio, e.g., a value of 3713 2.0 indicates that data is to be delivered twice as fast as normal. A 3714 speed of zero is invalid. All speeds may not be possible to support. 3715 Therefore the actual used speed MUST be included in the response. The 3716 lack of a response header is indication of lack of support from the 3717 server of this functionality. Support of the speed functionality are 3718 indicated by the "play.speed" featuretag. 3720 Example: 3722 Speed: 2.5 3724 Use of this field changes the bandwidth used for data delivery. It is 3725 meant for use in specific circumstances where preview of the 3726 presentation at a higher or lower rate is necessary. Implementors 3727 should keep in mind that bandwidth for the session may be negotiated 3728 beforehand (by means other than RTSP), and therefore re-negotiation 3729 may be necessary. When data is delivered over UDP, it is highly 3730 recommended that means such as RTCP be used to track packet loss 3731 rates. If the data transport is performed over public best-effort 3732 networks the sender SHOULD perform congestion control of the 3733 stream(s). This can result in that the communicated speed is 3734 impossible to maintain. 3736 14.36 Server 3738 See [H14.38], however the header syntax is corrected in section 3739 17.2.3. 3741 14.37 Session 3743 The Session request-header and response-header field identifies an 3744 RTSP session. An RTSP session is created by the server as a result of 3745 a successful SETUP request and in the response the session identifier 3746 is given to the client. The RTSP session exist until destroyed by a 3747 TEARDOWN or timed out by the server. 3749 The session identifier is chosen by the server (see Section 3.3) and 3750 MUST be returned in the SETUP response. Once a client receives a 3751 session identifier, it SHALL be included in any request related to 3752 that session. This means that the Session header MUST be included in 3753 a request using the following methods: PLAY, PAUSE, PING, and 3754 TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, 3755 GET_PARAMETER, and REDIRECT, and SHALL NOT be included in DESCRIBE. 3756 In a RTSP response the session header SHALL be included in methods, 3757 SETUP, PING, PLAY, and PAUSE, and MAY be included in methods, 3758 TEARDOWN, and REDIRECT, and if included in the request of the 3759 following methods it SHALL also be included in the response, OPTIONS, 3760 GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in 3761 DESCRIBE. 3763 Note that RFC 2326 servers and client may in some cases not include 3764 or return a Session header when expected according to the above text. 3765 Any client or server is RECOMMENDED to be forgiving of this error if 3766 possible (which it is in many cases). 3768 The timeout parameter MAY be included in a SETUP response, and SHALL | 3769 NOT be included in requests. The server uses it to indicate to the | 3770 client how long the server is prepared to wait between RTSP commands | 3771 or other signs of life before closing the session due to lack of | 3772 activity (see below and Section A). The timeout is measured in | 3773 seconds, with a default of 60 seconds (1 minute). The length of the | 3774 session timeout SHALL NOT be changed in a established session. 3776 The mechanisms for showing liveness of the client is, any RTSP 3777 request with a Session header, if RTP & RTCP is used an RTCP message, 3778 or through any other used media protocol capable of indicating 3779 liveness of the RTSP client. It is RECOMMENDED that a client does not 3780 wait to the last second of the timeout before trying to send a 3781 liveness message. The RTSP message may be lost or when using reliable 3782 protocols, such as TCP, the message may take some time to arrive 3783 safely at the receiver. To show liveness between RTSP request issued 3784 to accomplish other things, the following mechanisms can be used, in 3785 descending order of preference: 3787 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 3788 RTCP is used to report transport statistics, it SHALL also 3789 work as keep alive. The server can determine the client by 3790 used network address and port together with the fact that 3791 the client is reporting on the servers SSRC(s). A downside 3792 of using RTCP is that it only gives statistical guarantees 3793 to reach the server. However that probability is so low 3794 that it can be ignored in most cases. For example, a 3795 session with 60 seconds timeout and enough bitrate assigned 3796 to RTCP messages to send a message from client to server on 3797 average every 5 seconds. That client have for a network 3798 with 5 % packet loss, the probability to fail showing 3799 liveness sign in that session within the timeout interval 3800 of 2.4*E-16. In sessions with shorter timeout times, or 3801 much higher packet loss, or small RTCP bandwidths SHOULD 3802 also use any of the mechanisms below. 3804 PING: The use of the PING method is the best of the RTSP based 3805 methods. It has no other effects than updating the timeout 3806 timer. In that way it will be a minimal message, that also 3807 does not cause any extra processing for the server. The 3808 downside is that it may not be implemented. A client SHOULD 3809 use a OPTIONS request to verify support of the PING at the 3810 server. It is also possible to detect support by sending a 3811 PING to the server. If a 200 (OK) message is received the 3812 server supports it. In case a 501 (Not Implemented) is 3813 received it does not support PING and there is no meaning 3814 in continue trying. Also the reception of a error message 3815 will also mean that the liveness timer has not been 3816 updated. 3818 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 3819 SHOULD be included. This method is basically as good as 3820 PING, however the implementation support of the method is 3821 today limited. The same considerations as for PING apply 3822 regarding checking of support in server and proxies. 3824 OPTIONS: This method does also work. However it causes the 3825 server to perform unnecessary processing and result in 3826 bigger responses than necessary for the task. The reason 3827 for this is that the Public is always included creating 3828 overhead. 3830 Note that a session identifier identifies an RTSP session across 3831 transport sessions or connections. RTSP requests for a given session 3832 can use different URLs (Presentation and media URLs). Note, that 3833 there are restrictions depending on the session which URLs that are 3834 acceptable for a given method. However, multiple "user" sessions for 3835 the same URL from the same client will require use of different 3836 session identifiers. 3838 The session identifier is needed to distinguish several 3839 delivery requests for the same URL coming from the same 3840 client. 3842 The response 454 (Session Not Found) SHALL be returned if the session 3843 identifier is invalid. 3845 14.38 Supported 3847 The Supported header field enumerates all the extensions supported by 3848 the client or server. When offered in a request, the receiver MUST 3849 respond with its corresponding Supported header. 3851 The Supported header field contains a list of feature-tags, described 3852 in Section 3.7, that are understood by the client or server. 3854 Example: 3856 C->S: OPTIONS rtsp://example.com/ RTSP/1.0 3857 Supported: foo, bar, blech 3859 S->C: RTSP/1.0 200 OK 3860 Supported: bar, blech, baz 3862 14.39 Timestamp 3864 The Timestamp general-header field describes when the client sent the 3865 request to the server. The value of the timestamp is of significance 3866 only to the client and may use any timescale. The server MUST echo 3867 the exact same value and MAY, if it has accurate information about 3868 this, add a floating point number indicating the number of seconds 3869 that has elapsed since it has received the request. The timestamp is 3870 used by the client to compute the round-trip time to the server so 3871 that it can adjust the timeout value for retransmissions. It also 3872 resolves retransmission ambiguities for unreliable transport of RTSP. 3874 14.40 Transport 3876 The Transport request and response header field indicates which 3877 transport protocol is to be used and configures its parameters such 3878 as destination address, compression, multicast time-to-live and 3879 destination port for a single stream. It sets those values not 3880 already determined by a presentation description. 3882 Transports are comma separated, listed in order of preference. | 3883 Parameters may be added to each transport, separated by a semicolon. | 3884 The server SHOULD return a Transport response-header field in the | 3885 response to indicate the values actually chosen. The Transport header | 3886 field MAY also be used to change certain transport parameters. A | 3887 server MAY refuse to change parameters of an existing stream. | 3889 A Transport request header field MAY contain a list of transport | 3890 options acceptable to the client, in the form of multiple | 3891 transportspec entries. In that case, the server MUST return the | 3892 single option (transport-spec) which was actually chosen. The number | 3893 of transportspec entries is expected to be limited as the client will | 3894 get guidance on what configurations that are possible from the | 3895 presentation description. 3897 A transport-spec transport option may only contain one of any given | 3898 parameter within it. Parameters may be given in any order. | 3899 Additionally, it may only contain the unicast or multicast transport | 3900 parameter. Unknown transport parameters SHALL be ignored. The | 3901 requester need to ensure that the responder understands the | 3902 parameters through the use of feature tags and the Require header. | 3904 The usage of any parameter that was not defined in RFC 2326 or in an | 3905 extended way requires that request or response contains a Require | 3906 header with the "play.basic" feature tag. 3908 The Transport header field is restricted to describing a 3909 single media stream. (RTSP can also control multiple 3910 streams as a single entity.) Making it part of RTSP rather 3911 than relying on a multitude of session description formats 3912 greatly simplifies designs of firewalls. 3914 The syntax for the transport specifier is 3916 transport/profile/lower-transport. 3918 The default value for the "lower-transport" parameters is specific to 3919 the profile. For RTP/AVP, the default is UDP. 3921 There is three different methods for how to specify where the media | 3922 should be delivered: | 3924 o The presence of this parameter and its values indicates | 3925 address and port pairs for one or more IP flow necessary for | 3926 the media transport. This is an improved version of the | 3927 Destination parameter. | 3929 o The presence of this parameter and its value indicates what IP | 3930 address the media shall be delivered to. This method is kept | 3931 for backwards compatibility reasons, dest_addr is a better | 3932 choice. | 3934 o The lack of of both of the above parameters indicates that the | 3935 server SHALL send media to same address for which the RTSP | 3936 messages originates. | 3938 The choice of method for indicating where the media shall be | 3939 delivered depends on the use case. In many case the only allowed | 3940 method will be to use no explicit indication and have the server | 3941 deliver media to the source of the RTSP messages. | 3943 An RTSP proxy will also need to take care. If the media is not | 3944 desired to be routed through the proxy, the proxy will need to | 3945 introduce the destination indication. 3947 Below are the configuration parameters associated with transport: 3949 General parameters: 3951 unicast / multicast: This parameter is a mutually exclusive 3952 indication of whether unicast or multicast delivery will be 3953 attempted. One of the two values MUST be specified. Clients 3954 that are capable of handling both unicast and multicast 3955 transmission MUST indicate such capability by including two 3956 full transport-specs with separate parameters for each. 3958 destination: The address of the stream recipient to which a 3959 stream will be sent. The client originating the RTSP 3960 request may specify the destination address of the stream 3961 recipient with the destination parameter. When the 3962 destination field is specified, the recipient may be a 3963 different party than the originator of the request. To 3964 avoid becoming the unwitting perpetrator of a remote- 3965 controlled denial-of-service attack, a server SHOULD 3966 authenticate the client originating the request and SHOULD 3967 log such attempts before allowing the client to direct a 3968 media stream to a recipient address not chosen by the 3969 server. While, this is particularly important if RTSP 3970 commands are issued via UDP, implementations cannot rely on 3971 TCP as reliable means of client identification by itself 3972 either. 3974 The server SHOULD NOT allow the destination field to be set 3975 unless a mechanism exists in the system to authorize the 3976 request originator to direct streams to the recipient. It 3977 is preferred that this authorization be performed by the 3978 recipient itself and the credentials passed along to the 3979 server. However, in certain cases, such as when recipient 3980 address is a multicast group, or when the recipient is 3981 unable to communicate with the server in an out-of-band 3982 manner, this may not be possible. In these cases server may 3983 chose another method such as a server-resident 3984 authorization list to ensure that the request originator 3985 has the proper credentials to request stream delivery to 3986 the recipient. 3988 This parameter SHALL NOT be used when src_addr and 3989 dest_addr is used in a transport declaration. For IPv6 3990 addresses it is RECOMMENDED that they be given as fully 3991 qualified domain to make it backwards compatible with RFC 3992 2326 implementations. 3994 source: If the source address for the stream is different than 3995 can be derived from the RTSP endpoint address (the server 3996 in playback), the source address SHOULD be specified. To 3997 maintain backwards compatibility with RFC 2326, any IPv6 3998 host's address must be given as a fully qualified domain 3999 name. This parameter SHALL NOT be used when src_addr and 4000 dest_addr is used in a transport declaration. 4002 This information may also be available through SDP. 4003 However, since this is more a feature of transport 4004 than media initialization, the authoritative source 4005 for this information should be in the SETUP response. 4007 layers: The number of multicast layers to be used for this media 4008 stream. The layers are sent to consecutive addresses 4009 starting at the destination address. 4011 dest_addr: A general destination address parameter that can | 4012 contain one or more address and port pair. For each | 4013 combination of Protocol/Profile/Lower Transport the | 4014 interpretation of the address or addresses needs to be | 4015 defined. The host address part of the tuple MAY be empty, | 4016 for example ":8000", in cases when only destination port is | 4017 desired to be specified. 4019 The client or server SHALL NOT use this parameter unless 4020 both client and server has shown support. This parameter 4021 MUST be supported by client and servers that implements 4022 this specification. Support is indicated by the use of the 4023 feature-tag "play.basic". This parameter SHALL NOT be used 4024 in the same transport specification as any of the 4025 parameters "destination", "source", "port", "client_port", 4026 and "server_port". 4028 The same security consideration that are given for the 4029 "Destination" parameter does also applies to this 4030 parameter. This parameter can be used for redirecting 4031 traffic to recipient not desiring the media traffic. 4033 src_addr: A General source address parameter that can contain 4034 one or more address and port pair. For each combination of 4035 Protocol/Profile/Lower Transport the interpretation of the 4036 address or addresses needs to be defined. The client or 4037 server SHALL NOT use this parameter unless both client and 4038 server has shown support. This parameter MUST be supported 4039 by client and servers that implements this specification. 4040 Support is indicated by the use the feature-tag 4041 "play.basic". This parameter SHALL NOT be used in the same 4042 transport specification as any of the parameters 4043 "destination", "source", "port", "client_port", and 4044 "server_port". 4046 This parameter MUST be specified by the server if it | 4047 transmits media packets from another address than the one | 4048 RTSP messages are sent to. This will allow the client to | 4049 verify source address and give it a destination address for | 4050 its RTCP feedback packets if RTP is used. The address or | 4051 addresses indicated in the src_addr parameter SHOULD be | 4052 used both for sending and receiving of the media streams | 4053 data packets. The main reasons are three: First by sending | 4054 from the indicated ports the source address will be known | 4055 by the receiver of the packet. Secondly, in the presence of | 4056 NATs some traversal mechanism requires either knowledge | 4057 from which address and port a packet flow is coming, or | 4058 having the possibility to send data to the sender port. 4060 mode: The mode parameter indicates the methods to be supported 4061 for this session. Valid values are PLAY and RECORD. If not 4062 provided, the default is PLAY. The RECORD value was 4063 defined in RFC 2326 and is deprecated in this 4064 specification. 4066 append: The append parameter was used together with RECORD and 4067 is now deprecated. 4069 interleaved: The interleaved parameter implies mixing the media 4070 stream with the control stream in whatever protocol is 4071 being used by the control stream, using the mechanism 4072 defined in Section 12. The argument provides the channel 4073 number to be used in the $ statement and MUST be present. 4074 This parameter MAY be specified as a range, e.g., 4075 interleaved=4-5 in cases where the transport choice for the 4076 media stream requires it, e.g. for RTP with RTCP. The 4077 channel number given in the request are only a guidance 4078 from the client to the server on what channel number(s) to 4079 use. The server MAY set any valid channel number in the 4080 response. The declared channel(s) are bi-directional, so 4081 both end-parties MAY send data on the given channel. One 4082 example of such usage is the second channel used for RTCP, 4083 where both server and client sends RTCP packets on the same 4084 channel. 4086 This allows RTP/RTCP to be handled similarly to the 4087 way that it is done with UDP, i.e., one channel for 4088 RTP and the other for RTCP. 4090 Multicast-specific: 4092 ttl: multicast time-to-live. 4094 RTP-specific: 4096 These parameters are MAY only be used if the media transport protocol 4097 is RTP. 4099 port: This parameter provides the RTP/RTCP port pair for a 4100 multicast session. It is should be specified as a range, 4101 e.g., port=3456-3457 4103 client_port: This parameter provides the unicast RTP/RTCP port 4104 pair on the client where media data and control information 4105 is to be sent. It is specified as a range, e.g., 4106 port=3456-3457. This parameter SHALL NOT be used when 4107 src_addr and dest_addr is used in a transport declaration. 4109 server_port: This parameter provides the unicast RTP/RTCP port 4110 pair on the server where media data and control information 4111 is to be sent. It is specified as a range, e.g., 4112 port=3456-3457. This parameter SHALL NOT be used when 4113 src_addr and dest_addr is used in a transport declaration. 4115 ssrc: The ssrc parameter, if included in a SETUP response, 4116 indicates the RTP SSRC [15] value that will be used by the 4117 media server for RTP packets within the stream. It is 4118 expressed as an eight digit hexadecimal value. If the 4119 server does not act as a synchronization source for stream 4120 data (for instance, server is a translator, reflector, 4121 etc.) the value will be the "packet sender's SSRC" that 4122 would have been used in the RTCP Receiver Reports generated 4123 by the server, regardless of whether the server actually 4124 generates RTCP RRs. If there are multiple sources within 4125 the stream, the ssrc parameter only indicates the value for 4126 a single synchronization source. Other sources must be 4127 deduced from the actual RTP/RTCP stream. 4129 The functionality of specifying the ssrc parameter in a 4130 SETUP request is deprecated as it is incompatible with the 4131 specification of RTP in RFC 3550 [15]. If the parameter is 4132 included in the transport header of a SETUP request, the 4133 server MAY ignore it, and choose an appropriate SSRC for 4134 the stream. The server MAY set the ssrc parameter in the 4135 transport header of the response. 4137 The combination of transport protocol, profile and lower transport 4138 needs to be defined. A number of combinations are defined in the 4139 appendix B. 4141 Below is a usage example, showing a client advertising the capability 4142 to handle multicast or unicast, preferring multicast. Since this is 4143 a unicast-only stream, the server responds with the proper transport 4144 parameters for unicast. 4146 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 4147 CSeq: 302 4148 Transport: RTP/AVP;multicast;mode="PLAY", 4149 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" 4151 S->C: RTSP/1.0 200 OK 4152 CSeq: 302 4153 Date: 23 Jan 1997 15:35:06 GMT 4154 Session: 47112344 4155 Transport: RTP/AVP;unicast;client_port=3456-3457; 4156 server_port=6256-6257;mode="PLAY" 4158 14.41 Unsupported 4160 The Unsupported response-header field lists the features not 4161 supported by the server. In the case where the feature was specified 4162 via the Proxy-Require field (Section 14.27), if there is a proxy on 4163 the path between the client and the server, the proxy MUST send a 4164 response message with a status code of 551 (Option Not Supported). 4165 The request SHALL NOT be forwarded. 4167 See Section 14.32 for a usage example. 4169 14.42 User-Agent 4171 See [H14.43] for explanation, however the syntax is clarified due to 4172 an error in RFC 2616. A Client SHOULD include this header in all RTSP 4173 messages it sends. 4175 14.43 Vary 4177 See [H14.44] 4179 14.44 Via 4181 See [H14.45]. 4183 14.45 WWW-Authenticate 4185 See [H14.47]. 4187 15 Caching 4189 In HTTP, response-request pairs are cached. RTSP differs 4190 significantly in that respect. Responses are not cacheable, with the 4191 exception of the presentation description returned by DESCRIBE. 4192 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4193 not return any data, caching is not really an issue for these 4194 requests.) However, it is desirable for the continuous media data, 4195 typically delivered out-of-band with respect to RTSP, to be cached, 4196 as well as the session description. 4198 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4199 has an up-to-date copy of the continuous media content and its 4200 description. It can determine whether the copy is up-to-date by 4201 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4202 Last-Modified header with that of the cached copy. If the copy is not 4203 up-to-date, it modifies the SETUP transport parameters as appropriate 4204 and forwards the request to the origin server. Subsequent control 4205 commands such as PLAY or PAUSE then pass the proxy unmodified. The 4206 proxy delivers the continuous media data to the client, while 4207 possibly making a local copy for later reuse. The exact behavior 4208 allowed to the cache is given by the cache-response directives 4209 described in Section 14.9. A cache MUST answer any DESCRIBE requests 4210 if it is currently serving the stream to the requestor, as it is 4211 possible that low-level details of the stream description may have 4212 changed on the origin-server. 4214 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 4215 through" variety. Rather than retrieving the whole resource from the 4216 origin server, the cache simply copies the streaming data as it 4217 passes by on its way to the client. Thus, it does not introduce 4218 additional latency. 4220 To the client, an RTSP proxy cache appears like a regular media 4221 server, to the media origin server like a client. Just as an HTTP 4222 cache has to store the content type, content language, and so on for 4223 the objects it caches, a media cache has to store the presentation 4224 description. Typically, a cache eliminates all transport-references 4225 (that is, multicast information) from the presentation description, 4226 since these are independent of the data delivery from the cache to 4227 the client. Information on the encodings remains the same. If the 4228 cache is able to translate the cached media data, it would create a 4229 new presentation description with all the encoding possibilities it 4230 can offer. 4232 16 Examples 4234 This section contains several different examples trying to illustrate | 4235 possible ways of using RTSP. The examples can also help with the | 4236 understanding of how functions of RTSP work. However remember that | 4237 this is examples and the normative and syntax description in the | 4238 other chapters takes precedence. Please also note that many of the | 4239 example MAY contain syntax illegal line breaks to accommodate the | 4240 formatting restriction that the RFC series impose. | 4242 16.1 Media on Demand (Unicast) | 4244 Client C requests a movie distributed from two different media | 4245 servers A (audio.example.com ) and V (video.example.com ). The media | 4246 description is stored on a web server W. The media description | 4247 contains descriptions of the presentation and all its streams, | 4248 including the codecs that are available, dynamic RTP payload types, | 4249 the protocol stack, and content information such as language or | 4250 copyright restrictions. It may also give an indication about the | 4251 timeline of the movie. | 4253 In this example, the client is only interested in the last part of | 4254 the movie. | 4256 C->W: GET /twister.sdp HTTP/1.1 | 4257 Host: www.example.com | 4258 Accept: application/sdp | 4260 W->C: HTTP/1.0 200 OK | 4261 Date: 23 Jan 1997 15:35:06 GMT | 4262 Content-Type: application/sdp | 4263 Content-Length: 255 | 4264 Expires: 23 Jan 1998 15:35:06 GMT | 4266 v=0 | 4267 o=- 2890844526 2890842807 IN IP4 192.16.24.202 | 4268 s=RTSP Session | 4269 e=adm@example.com | 4270 a=range:npt=0-1:49:34 | 4271 t=0 0 | 4272 m=audio 0 RTP/AVP 0 | 4273 a=control:rtsp://audio.example.com/twister/audio.en | 4274 m=video 0 RTP/AVP 31 | 4275 a=control:rtsp://video.example.com/twister/video | 4277 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 | 4278 CSeq: 1 | 4279 User-Agent: PhonyClient/1.2 | 4280 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, | 4281 RTP/AVP/TCP;unicast;interleave=0-1 | 4283 A->C: RTSP/1.0 200 OK | 4284 CSeq: 1 | 4285 Session: 12345678 | 4286 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; | 4287 server_port=5000-5001 | 4288 Date: 23 Jan 1997 15:35:12 GMT | 4289 Server: PhonyServer/1.0 | 4290 Expires: 24 Jan 1997 15:35:12 GMT | 4291 Cache-Control: public | 4292 Accept-Ranges: NPT, SMPTE | 4294 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 | 4295 CSeq: 1 | 4296 User-Agent: PhonyClient/1.2 | 4297 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059, | 4298 RTP/AVP/TCP;unicast;interleave=0-1 | 4300 V->C: RTSP/1.0 200 OK | 4301 CSeq: 1 | 4302 Session: 23456789 | 4303 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; | 4304 server_port=5002-5003 | 4305 Date: 23 Jan 1997 15:35:12 GMT | 4306 Server: PhonyServer/1.0 | 4307 Cache-Control: public | 4308 Expires: 24 Jan 1997 15:35:12 GMT | 4309 Accept-Ranges: NPT, SMPTE | 4311 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 | 4312 CSeq: 2 | 4313 User-Agent: PhonyClient/1.2 | 4314 Session: 23456789 | 4315 Range: smpte=0:10:00- | 4317 V->C: RTSP/1.0 200 OK | 4318 CSeq: 2 | 4319 Session: 23456789 | 4320 Range: smpte=0:10:00-1:49:23 | 4321 RTP-Info: url=rtsp://video.example.com/twister/video; | 4322 seq=12312232;rtptime=78712811 | 4323 Server: PhonyServer/2.0 | 4324 Date: 23 Jan 1997 15:35:13 GMT | 4326 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 | 4327 CSeq: 2 | 4328 User-Agent: PhonyClient/1.2 | 4329 Session: 12345678 | 4330 Range: smpte=0:10:00- | 4332 A->C: RTSP/1.0 200 OK | 4333 CSeq: 2 | 4334 Session: 12345678 | 4335 Range: smpte=0:10:00-1:49:23 | 4336 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; | 4337 seq=876655;rtptime=1032181 | 4338 Server: PhonyServer/1.0 | 4339 Date: 23 Jan 1997 15:35:13 GMT | 4341 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 | 4342 CSeq: 3 | 4343 User-Agent: PhonyClient/1.2 | 4344 Session: 12345678 | 4346 A->C: RTSP/1.0 200 OK | 4347 CSeq: 3 | 4348 Server: PhonyServer/1.0 | 4349 Date: 23 Jan 1997 15:36:52 GMT | 4351 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 | 4352 CSeq: 3 | 4353 User-Agent: PhonyClient/1.2 | 4354 Session: 23456789 | 4356 V->C: RTSP/1.0 200 OK | 4357 CSeq: 3 | 4358 Server: PhonyServer/2.0 | 4359 Date: 23 Jan 1997 15:36:52 GMT | 4361 Even though the audio and video track are on two different servers, | 4362 and may start at slightly different times and may drift with respect | 4363 to each other, the client can synchronize the two using standard RTP | 4364 methods, in particular the time scale contained in the RTCP sender | 4365 reports. Initial synchronization is achieved through the RTP-Info and | 4366 Range headers information in the PLAY response. | 4368 16.2 Streaming of a Container file | 4370 For purposes of this example, a container file is a storage entity in | 4371 which multiple continuous media types pertaining to the same end-user | 4372 presentation are present. In effect, the container file represents an | 4373 RTSP presentation, with each of its components being RTSP streams. | 4374 Container files are a widely used means to store such presentations. | 4375 While the components are transported as independent streams, it is | 4376 desirable to maintain a common context for those streams at the | 4377 server end. | 4379 This enables the server to keep a single storage handle | 4380 open easily. It also allows treating all the streams | 4381 equally in case of any prioritization of streams by the | 4382 server. | 4384 It is also possible that the presentation author may wish to prevent | 4385 selective retrieval of the streams by the client in order to preserve | 4386 the artistic effect of the combined media presentation. Similarly, in | 4387 such a tightly bound presentation, it is desirable to be able to | 4388 control all the streams via a single control message using an | 4389 aggregate URL. | 4391 The following is an example of using a single RTSP session to control | 4392 multiple streams. It also illustrates the use of aggregate URLs. In a | 4393 container file it is also desirable to not write any URL parts which | 4394 is not kept, when the container is distributed, like the host and | 4395 most of the path element. Therefore this example also uses the "*" | 4396 and relative URL in the delivered SDP. | 4398 Client C requests a presentation from media server M. The movie is | 4399 stored in a container file. The client has obtained an RTSP URL to | 4400 the container file. | 4402 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/1.0 | 4403 CSeq: 1 | 4404 User-Agent: PhonyClient/1.2 | 4406 M->C: RTSP/1.0 200 OK | 4407 CSeq: 1 | 4408 Server: PhonyServer/1.0 | 4409 Date: 23 Jan 1997 15:35:06 GMT | 4410 Content-Type: application/sdp | 4411 Content-Length: 257 | 4412 Content-Base: rtsp://example.com/twister.3gp/ | 4413 Expires: 24 Jan 1997 15:35:06 GMT | 4415 v=0 | 4416 o=- 2890844256 2890842807 IN IP4 172.16.2.93 | 4417 s=RTSP Session | 4418 i=An Example of RTSP Session Usage | 4419 e=adm@example.com | 4420 a=control: * | 4421 a=range: npt=0-0:10:34.10 | 4422 t=0 0 | 4423 m=audio 0 RTP/AVP 0 | 4424 a=control: trackID=1 | 4425 m=video 0 RTP/AVP 26 | 4426 a=control: trackID=4 | 4428 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/1.0 | 4429 CSeq: 2 | 4430 User-Agent: PhonyClient/1.2 | 4431 Require: play.basic | 4432 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" | 4434 M->C: RTSP/1.0 200 OK | 4435 CSeq: 2 | 4436 Server: PhonyServer/1.0 | 4437 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; | 4438 src_addr="172.16.2.93:9000"/"172.16.2.93:9001" | 4439 ssrc=93CB001E | 4440 Session: 12345678 | 4441 Expires: 24 Jan 1997 15:35:12 GMT | 4442 Date: 23 Jan 1997 15:35:12 GMT | 4443 Accept-Ranges: NPT | 4445 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/1.0 | 4446 CSeq: 3 | 4447 User-Agent: PhonyClient/1.2 | 4448 Require: play.basic | 4449 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" | 4450 Session: 12345678 | 4452 M->C: RTSP/1.0 200 OK | 4453 CSeq: 3 | 4454 Server: PhonyServer/1.0 | 4455 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; | 4456 src_addr="172.16.2.93:9002"/"172.16.2.93:9003"; | 4457 ssrc=A813FC13 | 4458 Session: 12345678 | 4459 Expires: 24 Jan 1997 15:35:13 GMT | 4460 Date: 23 Jan 1997 15:35:13 GMT | 4461 Accept-Range: NPT | 4463 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 | 4464 CSeq: 4 | 4465 User-Agent: PhonyClient/1.2 | 4466 Range: npt=0-10, npt=30- | 4467 Session: 12345678 | 4469 M->C: RTSP/1.0 200 OK | 4470 CSeq: 4 | 4471 Server: PhonyServer/1.0 | 4472 Date: 23 Jan 1997 15:35:14 GMT | 4473 Session: 12345678 | 4474 Range: npt=0-10, npt=30-623.10 | 4475 RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4; | 4476 seq=12345;rtptime=3450012, | 4477 url=rtsp://example.com/twister.3gp/trackID=1; | 4478 seq=54321;rtptime=2876889 | 4480 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/1.0 | 4481 CSeq: 5 | 4482 User-Agent: PhonyClient/1.2 | 4483 Session: 12345678 | 4485 M->C: RTSP/1.0 200 OK | 4486 CSeq: 5 | 4487 Server: PhonyServer/1.0 | 4488 Date: 23 Jan 1997 15:36:01 GMT | 4489 Session: 12345678 | 4490 Range: npt=34.57-623.10 | 4492 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 | 4493 CSeq: 6 | 4494 User-Agent: PhonyClient/1.2 | 4495 Range: npt=34.57-623.10 | 4496 Session: 12345678 | 4498 M->C: RTSP/1.0 200 OK | 4499 CSeq: 6 | 4500 Server: PhonyServer/1.0 | 4501 Date: 23 Jan 1997 15:36:01 GMT | 4502 Session: 12345678 | 4503 Range: npt=34.57-623.10 | 4504 RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4; | 4505 seq=12555;rtptime=6330012, | 4506 url=rtsp://example.com/twister.3gp/trackID=1; | 4507 seq=55021;rtptime=3132889 | 4509 16.3 Single Stream Container Files | 4511 Some RTSP servers may treat all files as though they are "container | 4512 files", yet other servers may not support such a concept. Because of | 4513 this, clients SHOULD use the rules set forth in the session | 4514 description for request URLs, rather than assuming that a consistent | 4515 URL may always be used throughout. Here's an example of how a multi- | 4516 stream server might expect a single-stream file to be served: | 4518 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 | 4519 Accept: application/x-rtsp-mh, application/sdp | 4520 CSeq: 1 | 4521 User-Agent: PhonyClient/1.2 | 4523 S->C: RTSP/1.0 200 OK | 4524 CSeq: 1 | 4525 Content-base: rtsp://foo.com/test.wav/ | 4526 Content-type: application/sdp | 4527 Content-length: 48 | 4528 Server: PhonyServer/1.0 | 4529 Date: 23 Jan 1997 15:35:06 GMT | 4530 Expires: 23 Jan 1997 17:00:00 GMT | 4532 v=0 | 4533 o=- 872653257 872653257 IN IP4 172.16.2.187 | 4534 s=mu-law wave file | 4535 i=audio test | 4536 t=0 0 | 4537 a=control: * | 4538 m=audio 0 RTP/AVP 0 | 4539 a=control:streamid=0 | 4541 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 | 4542 Transport: RTP/AVP/UDP;unicast; | 4543 client_port=6970-6971;mode="PLAY" | 4544 CSeq: 2 | 4545 User-Agent: PhonyClient/1.2 | 4547 S->C: RTSP/1.0 200 OK | 4548 Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; | 4549 server_port=6970-6971;mode="PLAY";ssrc=EAB98712 | 4550 CSeq: 2 | 4551 Session: 2034820394 | 4552 Expires: 23 Jan 1997 16:00:00 GMT | 4553 Server: PhonyServer/1.0 | 4554 Date: 23 Jan 1997 15:35:07 GMT | 4556 C->S: PLAY rtsp://foo.com/test.wav RTSP/1.0 | 4557 CSeq: 3 | 4558 User-Agent: PhonyClient/1.2 | 4559 Session: 2034820394 | 4561 S->C: RTSP/1.0 200 OK | 4562 CSeq: 3 | 4563 Server: PhonyServer/1.0 | 4564 Date: 23 Jan 1997 15:35:08 GMT | 4565 Session: 2034820394 | 4566 Range: npt=0-600 | 4567 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; | 4568 seq=981888;rtptime=3781123 | 4570 Note the different URL in the SETUP command, and then the switch back | 4571 to the aggregate URL in the PLAY command. This makes complete sense | 4572 when there are multiple streams with aggregate control, but is less | 4573 than intuitive in the special case where the number of streams is | 4574 one. However the server has declared that the aggregated control URL | 4575 in the SDP and therefore this is fine. | 4577 If however the server had not declared an aggregated control URL it | 4578 would be another question, in which the client should consider it | 4579 lucky if it works. | 4581 In this case, it is also required that servers accept implementations | 4582 that uses the non-aggregated interpretation and uses the individual | 4583 media URL, like this: | 4585 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.0 | 4586 CSeq: 3 | 4587 User-Agent: PhonyClient/1.2 | 4589 16.4 Live Media Presentation Using Multicast | 4590 The media server M chooses the multicast address and port. Here, we | 4591 assume that the web server only contains a pointer to the full | 4592 description, while the media server M maintains the full description. | 4594 Editors note: Is this example really valid? In what situations does | 4595 it make sense to do a setup to a multicast distribution channel, and | 4596 also issue PLAY requests? | 4598 C->W: GET /sessions.html HTTP/1.1 | 4599 Host: www.example.com | 4601 W->C: HTTP/1.1 200 OK | 4602 Content-Type: text/html | 4604 | 4605 ... | 4606 | 4608 ... | 4609 | 4611 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 | 4612 CSeq: 1 | 4613 Supported: play.basic, play.scale | 4615 M->C: RTSP/1.0 200 OK | 4616 CSeq: 1 | 4617 Content-Type: application/sdp | 4618 Content-Length: 181 | 4619 Server: PhonyServer/1.0 | 4620 Date: 23 Jan 1997 15:35:06 GMT | 4621 Supported: play.basic | 4623 v=0 | 4624 o=- 2890844526 2890842807 IN IP4 192.16.24.202 | 4625 s=RTSP Session | 4626 m=audio 3456 RTP/AVP 0 | 4627 c=IN IP4 224.2.0.1/16 | 4628 a=control: rtsp://live.example.com/concert/audio | 4629 a=range:npt=0- | 4631 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 | 4632 CSeq: 2 | 4633 Transport: RTP/AVP;multicast | 4635 M->C: RTSP/1.0 200 OK | 4636 CSeq: 2 | 4637 Server: PhonyServer/1.0 | 4638 Date: 23 Jan 1997 15:35:06 GMT | 4639 Transport: RTP/AVP;multicast;destination=224.2.0.1; | 4640 port=3456-3457;ttl=16 | 4641 Session: 0456804596 | 4642 Accept-Ranges: NPT, UTC | 4644 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 | 4645 CSeq: 3 | 4646 Session: 0456804596 | 4648 M->C: RTSP/1.0 200 OK | 4649 CSeq: 3 | 4650 Server: PhonyServer/1.0 | 4651 Date: 23 Jan 1997 15:35:07 GMT | 4652 Session: 0456804596 | 4653 Range:npt=1256- | 4654 RTP-Info: url=rtsp://live.example.com/concert/audio; | 4655 seq=1473; rtptime=80000 | 4657 16.5 Capability Negotiation | 4659 This examples illustrate how the client and server determines there | 4660 capability to support a special feature, in this case "play.scale". | 4661 The server through the clients request, and included Supported header | 4662 learns that the client is supporting this updated specification, and | 4663 also support the playback time scaling feature of RTSP. The server's | 4664 response declares that it is also an updated specification minimal | 4665 implementation and supports the extra features, of client requested | 4666 time scaling and faster than normal transmission rates, plus one | 4667 "example.com" proprietary feature "flight". The client also learns | 4668 what methods that are possible to use in regards to the indicated | 4669 resource. | 4671 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/1.0 | 4672 CSeq: 1 | 4673 Supported: play.basic, play.scale | 4674 User-Agent: PhonyClient/1.2 | 4676 S->C: RTSP/1.0 200 OK | 4677 CSeq: 1 | 4678 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN | 4679 Server: PhonyServer/2.0 | 4680 Supported: play.basic, play.scale, play.speed, example.com.flight| 4682 When the client sends its SETUP request it tells the server that it | 4683 is must support the play.scale feature for this session by including | 4684 the Require header. | 4686 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/1.0 | 4687 CSeq: 3 | 4688 User-Agent: PhonyClient/1.2 | 4689 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, | 4690 RTP/AVP/TCP;unicast;interleave=0-1 | 4691 Require: play.scale | 4693 S->C: RTSP/1.0 200 OK | 4694 CSeq: 3 | 4695 Session: 12345678 | 4696 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; | 4697 server_port=5000-5001 | 4698 Server: PhonyServer/2.0 | 4699 Accept-Ranges: NPT, SMPTE | 4701 17 Syntax 4703 The RTSP syntax is described in an augmented Backus-Naur Form (BNF) | 4704 as defined in RFC 2234 [5]. | 4706 17.1 Base Syntax | 4708 OCTET = %x00-FF | 4709 CHAR = %x01-7F | 4710 UPALPHA = %x41-5A | 4711 LOALPHA = %x61-7A | 4712 ALPHA = UPALPHA / LOALPHA | 4713 DIGIT = %x30-39 | 4714 CTL = %x00-1F / %x7F | 4716 CR = %x0D | 4717 LF = %x0A | 4718 SP = %x20 | 4719 HT = %x09 | 4720 DQUOTE = %x22 | 4721 BACKSLASH = %x5C | 4722 CRLF = CR LF | 4723 LWS = [CRLF] 1*( SP / HT ) | 4724 TEXT = %x20-7D / %x80-FF | 4725 tspecials = "(" / ")" / "<" / ">" / "@" | 4726 / "," / ";" / ":" / BACKSLASH / DQUOTE | 4727 / "/" / "[" / "]" / "?" / "=" | 4728 / "{" / "}" / SP / HT | 4729 token = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 | 4730 / %x41-5A / %x5E-7A / %x7C / %x7E | 4731 1* | 4732 quoted-string = ( DQUOTE *(qdtext) DQUOTE ) | 4733 qdtext = %x20-21 / %x23-7D / %x80-FF > | 4734 quoted-pair = BACKSLASH CHAR | 4736 safe = "$" / "-" / "_" / "." / "+" | 4737 extra = "!" / "*" / "'" / "(" / ")" / "," | 4738 hex = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / | 4739 "a" / "b" / "c" / "d" / "e" / "f" | 4740 escape = "%" hex hex | 4741 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" | 4742 unreserved = alpha / digit / safe / extra | 4743 xchar = unreserved / reserved / escape | 4745 17.2 RTSP Protocol Definition | 4747 17.2.1 Generic Protocol elements | 4749 absoluteURL = as defined in RFC 2396 [12] and RFC2732 [11] | 4750 relativeURL = as defined in RFC 2396 [12] and RFC2732 [11] | 4751 rtsp_URL = rtsp-scheme "//" host [":" port] | 4752 [abs_path ["?" query]] ["#" fragment] | 4753 rtsp-scheme = ( "rtsp:" / "rtspu:" / "rtsps:" ) | 4754 host = As defined by RFC 2732 [11] | 4755 abs_path = As defined by RFC 2396 [12] | 4756 port = *DIGIT | 4757 query = As defined by RFC 2396 [12] | 4758 fragment = As defined by RFC 2396 [12] | 4760 smpte-range = smpte-type "=" smpte-range-spec | 4761 ;Section 3.4 | 4762 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) | 4763 / ( "-" smpte-time ) | 4764 smpte-type = "smpte" / "smpte-30-drop" | 4765 / "smpte-25" / smpte-type-extension | 4766 ; other timecodes may be added | 4767 smpte-type-extension = token | 4768 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT | 4769 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] | 4771 npt-range = ["npt" "="] npt-range-spec ; Section 3.5 | 4772 ; implementations SHOULD use npt= prefix, | 4773 ;but SHOULD be prepared to interoperate with | 4774 ; RFC 2326 implementations which don't use it. | 4775 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) | 4776 npt-time = "now" / npt-sec / npt-hhmmss | 4777 npt-sec = 1*DIGIT [ "." *DIGIT ] | 4778 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] | 4779 npt-hh = 1*DIGIT ; any positive number | 4780 npt-mm = 1*2DIGIT ; 0-59 | 4781 npt-ss = 1*2DIGIT ; 0-59 | 4783 utc-range = "clock" "=" utc-range-spec ; Section 3.6 | 4784 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) | 4785 utc-time = utc-date "T" utc-clock "Z" | 4786 utc-date = 8DIGIT ; < YYYYMMDD > | 4787 utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > | 4788 fraction = 1*DIGIT | 4790 feature-tag = token | 4791 session-id = 8*( ALPHA / DIGIT / safe ) | 4792 message-header = field-name ":" [ field-value ] CRLF | 4793 field-name = token | 4794 field-value = *( field-content / LWS ) | 4795 field-content = | 4799 17.2.2 Message Syntax | 4801 RTSP-message = Request / Response ; RTSP/1.0 messages | 4802 Request = Request-Line ; Section 6.1 | 4803 *( general-header ; Section 5 | 4805 / request-header ; Section 6.2 | 4806 / entity-header ) ; Section 8.1 | 4807 CRLF | 4808 [message-body ] ; Section 4.3 | 4809 Response = Status-Line ; Section 7.1 | 4810 *(general-header ; Section 5 | 4811 / response-header ; Section 7.1.2 | 4812 / entity-header ) ; Section 8.1 | 4813 CRLF | 4814 [ message-body ] ; Section 4.3 | 4816 Request-Line = Method SP Request-URI SP RTSP-Version CRLF | 4817 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF | 4819 Method = "DESCRIBE" ; Section 11.2 | 4820 / "GET_PARAMETER" ; Section 11.7 | 4821 / "OPTIONS" ; Section 11.1 | 4822 / "PAUSE" ; Section 11.5 | 4823 / "PLAY" ; Section 11.4 | 4824 / "PING" ; Section 11.10 | 4825 / "REDIRECT" ; Section 11.9 | 4826 / "SETUP" ; Section 11.3 | 4827 / "SET_PARAMETER" ; Section 11.8 | 4828 / "TEARDOWN" ; Section 11.6 | 4829 / extension-method | 4830 extension-method = token | 4832 Request-URI = "*" / absolute_URL | 4833 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT | 4835 Status-Code = "100" ; Continue | 4836 / "200" ; OK | 4837 / "201" ; Created | 4838 / "250" ; Low on Storage Space | 4839 / "300" ; Multiple Choices | 4840 / "301" ; Moved Permanently | 4841 / "302" ; Moved Temporarily | 4842 / "303" ; See Other | 4843 / "304" ; Not Modified | 4844 / "305" ; Use Proxy | 4845 / "400" ; Bad Request | 4846 / "401" ; Unauthorized | 4847 / "402" ; Payment Required | 4848 / "403" ; Forbidden | 4849 / "404" ; Not Found | 4850 / "405" ; Method Not Allowed | 4851 / "406" ; Not Acceptable | 4852 / "407" ; Proxy Authentication Required | 4853 / "408" ; Request Time-out | 4854 / "410" ; Gone | 4855 / "411" ; Length Required | 4856 / "412" ; Precondition Failed | 4857 / "413" ; Request Entity Too Large | 4858 / "414" ; Request-URI Too Large | 4859 / "415" ; Unsupported Media Type | 4860 / "451" ; Parameter Not Understood | 4861 / "452" ; reserved | 4862 / "453" ; Not Enough Bandwidth | 4863 / "454" ; Session Not Found | 4864 / "455" ; Method Not Valid in This State | 4865 / "456" ; Header Field Not Valid for Resource | 4866 / "457" ; Invalid Range | 4867 / "458" ; Parameter Is Read-Only | 4868 / "459" ; Aggregate operation not allowed | 4869 / "460" ; Only aggregate operation allowed | 4870 / "461" ; Unsupported transport | 4871 / "462" ; Destination unreachable | 4872 / "500" ; Internal Server Error | 4873 / "501" ; Not Implemented | 4874 / "502" ; Bad Gateway | 4875 / "503" ; Service Unavailable | 4876 / "504" ; Gateway Time-out | 4877 / "505" ; RTSP Version not supported | 4878 / "551" ; Option not supported | 4879 / extension-code | 4881 extension-code = 3DIGIT | 4882 Reason-Phrase = * | 4884 general-header = Cache-Control ; Section 14.9 | 4885 / Connection ; Section 14.10 | 4886 / CSeq ; Section 14.17 | 4887 / Date ; Section 14.18 | 4888 / Supported ; Section 14.38 | 4889 / Timestamp ; Section 14.39 | 4890 / Via ; Section 14.44 | 4891 / extension-header | 4893 request-header = Accept ; Section 14.1 and [H14.1] | 4894 / Accept-Encoding ; Section 14.2 and [H14.3] | 4895 / Accept-Language ; Section 14.3 and [H14.4] | 4896 / Authorization ; Section 14.6 and [H14.8] | 4897 / Bandwidth ; Section 14.7 | 4898 / Blocksize ; Section 14.8 | 4899 / From ; Section 14.20 | 4900 / If-Match ; Section 14.22 | 4901 / If-Modified-Since ; Section 14.23 and [H14.25] | 4902 / Proxy-Require ; Section 14.27 | 4903 / Range ; Section 14.29 | 4904 / Referer ; Section 14.30 | 4905 / Require ; Section 14.32 | 4906 / Scale ; Section 14.34 | 4907 / Session ; Section 14.37 | 4908 / Speed ; Section 14.35 | 4909 / Supported ; Section 14.38 | 4910 / Transport ; Section 14.40 | 4911 / User-Agent ; Section 14.42 | 4912 / extension-header | 4914 response-header = Accept-Ranges ; Section 14.4 | 4915 / Location ; Section 14.25 | 4916 / Proxy-Authenticate ; Section 14.26 | 4917 / Public ; Section 14.28 | 4918 / Range ; Section 14.29 | 4919 / Retry-After ; Section 14.31 | 4920 / RTP-Info ; Section 14.33 | 4921 / Scale ; Section 14.34 | 4922 / Session ; Section 14.37 | 4923 / Server ; Section 14.36 | 4924 / Speed ; Section 14.35 | 4925 / Transport ; Section 14.40 | 4926 / Unsupported ; Section 14.41 | 4927 / Vary ; Section 14.43 | 4928 / WWW-Authenticate ; Section 14.45 | 4929 / extension-header | 4931 entity-header = Allow ; Section 14.5 | 4932 / Content-Base ; Section 14.11 | 4933 / Content-Encoding ; Section 14.12 | 4934 / Content-Language ; Section 14.13 | 4935 / Content-Length ; Section 14.14 | 4936 / Content-Location ; Section 14.15 | 4937 / Content-Type ; Section 14.16 | 4938 / Expires ; Section 14.19 and [H14.21] | 4939 / Last-Modified ; Section 14.24 | 4940 / extension-header | 4941 extension-header = message-header | 4943 17.2.3 Header Syntax | 4945 All header syntaxes not defined in this section are defined in | 4946 chapter 14 of the HTTP 1.1 specification [4]. | 4948 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | 4949 acceptable-ranges = (range-unit *("," LWS range-unit)) | 4950 / "none" | 4951 range-unit = NPT / SMPTE / UTC / extension-format | 4952 extension-format = token | 4953 Bandwidth = "Bandwidth" ":" 1*DIGIT | 4954 Blocksize = "Blocksize" ":" 1*DIGIT | 4956 Cache-Control = "Cache-Control" ":" cache-directive | 4957 *("," LWS cache-directive) | 4958 cache-directive = cache-request-directive | 4959 / cache-response-directive | 4960 cache-request-directive = "no-cache" | 4961 / "max-stale" ["=" delta-seconds] | 4962 / "min-fresh" "=" delta-seconds | 4963 / "only-if-cached" | 4964 / cache-extension | 4965 cache-response-directive = "public" | 4966 / "private" | 4967 / "no-cache" | 4968 / "no-transform" | 4969 / "must-revalidate" | 4970 / "proxy-revalidate" | 4971 / "max-age" "=" delta-seconds | 4972 / cache-extension | 4973 cache-extension = token ["=" (token / quoted-string)] | 4974 delta-seconds = 1*DIGIT | 4975 Content-Base = "Content-Base" ":" absoluteURL | 4976 CSeq = "Cseq" ":" 1*DIGIT | 4977 Proxy-Require = "Proxy-Require" ":" feature-tag | 4978 *("," LWS feature-tag) | 4979 Public = "Public" ":" method *("," LWS method) | 4980 Range = "Range" ":" ranges-spec *("," LWS ranges-spec) | 4981 [ ";" "time" "=" utc-time ] | 4982 ranges-spec = npt-range / utc-range / smpte-range | 4983 Require = "Require" ":" feature-tag *("," LWS feature-tag) | 4985 RTP-Info = "RTP-Info" ":" rtsp-info-spec | 4986 *("," LWS rtsp-info-spec) | 4987 rtsp-info-spec = stream-url 1*parameter | 4988 stream-url = quoted-url / unquoted-url | 4989 unquoted-url = "url" "=" safe-url | 4990 quoted-url = "url" "=" DQUOTE needquote-url DQUOTE | 4991 safe-url = url | 4992 needquote-url = url //That contains ; or , | 4993 url = ( absoluteURL / relativeURL ) | 4994 parameter = ";" "seq" "=" 1*DIGIT | 4995 / ";" "rtptime" "=" 1*DIGIT | 4997 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] | 4998 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] | 4999 Server = "Server" ":" ( product / comment ) | 5000 *(SP (product / comment)) | 5001 Session = "Session" ":" session-id | 5002 [ ";" "timeout" "=" delta-seconds ] | 5003 Supported = "Supported" ":" [feature-tag *("," LWS feature-tag)] | 5005 Timestamp = "Timestamp" ":" *(DIGIT) ["." *(DIGIT)] [delay] | 5006 delay = *(DIGIT) [ "." *(DIGIT) ] | 5007 Transport = "Transport" ":" transport-spec | 5008 *("," LWS transport-spec) | 5009 transport-spec = transport-id *parameter | 5010 transport-id = transport-prot "/" profile ["/" lower-transport] | 5011 ; no LWS is allowed inside transport-id | 5013 transport-prot = "RTP" / token | 5014 profile = "AVP" / token | 5015 lower-transport = "TCP" / "UDP" / token | 5016 parameter = ";" ( "unicast" / "multicast" ) | 5017 / ";" "source" "=" host | 5018 / ";" "destination" [ "=" host ] | 5019 / ";" "interleaved" "=" channel [ "-" channel ] | 5020 / ";" "append" | 5021 / ";" "ttl" "=" ttl | 5022 / ";" "layers" "=" 1*DIGIT | 5023 / ";" "port" "=" port-spec | 5024 / ";" "client_port" "=" port-spec | 5025 / ";" "server_port" "=" port-spec | 5026 / ";" "ssrc" "=" ssrc | 5027 / ";" "client_ssrc" "=" ssrc | 5028 / ";" "mode" "=" mode-spec | 5029 / ";" "dest_addr" "=" addr-list | 5030 / ";" "src_addr" "=" addr-list | 5031 / ";" trn-param-ext | 5032 port-spec = port [ "-" port ] | 5033 trn-param-ext = par-name "=" trn-par-value | 5034 par-name = token | 5035 trn-par-value = *(unreserved / DQUOTE *TEXT DQUOTE) | 5036 ttl = 1*3(DIGIT) | 5037 ssrc = 8*8(HEX) | 5038 channel = 1*3(DIGIT) | 5039 mode-spec = ( DQUOTE mode *("," *SP mode) DQUOTE ) / mode | 5040 mode = "PLAY" / "RECORD" / token | 5041 addr-list = quoted-host-port *("/" quoted-host-port) | 5042 quoted-host-port = DQUOTE host [":" port] DQUOTE | 5044 Unsupported = "Unsupported" ":" feature-tag *("," feature-tag) | 5045 User-Agent = "User-Agent" ":" ( product / comment ) | 5046 0*(SP (product / comment) | 5048 18 Security Considerations 5050 Because of the similarity in syntax and usage between RTSP servers 5051 and HTTP servers, the security considerations outlined in [H15] 5052 apply. Specifically, please note the following: 5054 Authentication Mechanisms: RTSP and HTTP share common 5055 authentication schemes, and thus should follow the same 5056 prescriptions with regards to authentication . See chapter 5057 15.1 of [16] for client authentication issues, and chapter 5058 15.2 of [16] for issues regarding support for multiple 5059 authentication mechanisms. Also see [H15.6]. 5061 Abuse of Server Log Information: RTSP and HTTP servers will 5062 presumably have similar logging mechanisms, and thus should 5063 be equally guarded in protecting the contents of those 5064 logs, thus protecting the privacy of the users of the 5065 servers. See [H15.1.1] for HTTP server recommendations 5066 regarding server logs. 5068 Transfer of Sensitive Information: There is no reason to believe 5069 that information transferred via RTSP may be any less 5070 sensitive than that normally transmitted via HTTP. 5071 Therefore, all of the precautions regarding the protection 5072 of data privacy and user privacy apply to implementors of 5073 RTSP clients, servers, and proxies. See [H15.1.2] for 5074 further details. 5076 Attacks Based On File and Path Names: Though RTSP URLs are 5077 opaque handles that do not necessarily have file system 5078 semantics, it is anticipated that many implementations will 5079 translate portions of the request URLs directly to file 5080 system calls. In such cases, file systems SHOULD follow the 5081 precautions outlined in [H15.5], such as checking for ".." 5082 in path components. 5084 Personal Information: RTSP clients are often privy to the same 5085 information that HTTP clients are (user name, location, 5086 etc.) and thus should be equally. See [H15.1] for further 5087 recommendations. 5089 Privacy Issues Connected to Accept Headers: Since may of the 5090 same "Accept" headers exist in RTSP as in HTTP, the same 5091 caveats outlined in [H15.1.4] with regards to their use 5092 should be followed. 5094 DNS Spoofing: Presumably, given the longer connection times 5095 typically associated to RTSP sessions relative to HTTP 5096 sessions, RTSP client DNS optimizations should be less 5097 prevalent. Nonetheless, the recommendations provided in 5098 [H15.3] are still relevant to any implementation which 5099 attempts to rely on a DNS-to-IP mapping to hold beyond a 5100 single use of the mapping. 5102 Location Headers and Spoofing: If a single server supports 5103 multiple organizations that do not trust one another, then 5104 it must check the values of Location and Content-Location 5105 header fields in responses that are generated under control 5106 of said organizations to make sure that they do not attempt 5107 to invalidate resources over which they have no authority. 5108 ([H15.4]) 5110 In addition to the recommendations in the current HTTP specification 5111 (RFC 2616 [4], as of this writing) and also of the previous RFC2068 5112 [16], future HTTP specifications may provide additional guidance on 5113 security issues. 5115 The following are added considerations for RTSP implementations. 5117 Concentrated denial-of-service attack: The protocol offers the 5118 opportunity for a remote-controlled denial-of-service 5119 attack. 5121 The attacker may initiate traffic flows to one or more IP 5122 addresses by specifying them as the destination in SETUP 5123 requests. While the attacker's IP address may be known in 5124 this case, this is not always useful in prevention of more 5125 attacks or ascertaining the attackers identity. Thus, an 5126 RTSP server SHOULD only allow client-specified destinations 5127 for RTSP-initiated traffic flows if the server has verified 5128 the client's identity, either against a database of known 5129 users using RTSP authentication mechanisms (preferably 5130 digest authentication or stronger), or other secure means. 5132 Session hijacking: Since there is no or little relation between 5133 a transport layer connection and an RTSP session, it is 5134 possible for a malicious client to issue requests with 5135 random session identifiers which would affect unsuspecting 5136 clients. The server SHOULD use a large, random and non- 5137 sequential session identifier to minimize the possibility 5138 of this kind of attack. 5140 Authentication: Servers SHOULD implement both basic and digest 5141 [7] authentication. In environments requiring tighter 5142 security for the control messages, transport layer 5143 mechanisms such as TLS (RFC 2246 [26]) SHOULD be used. 5145 Stream issues: RTSP only provides for stream control. Stream 5146 delivery issues are not covered in this section, nor in the 5147 rest of this draft. RTSP implementations will most likely 5148 rely on other protocols such as RTP, IP multicast, RSVP and 5149 IGMP, and should address security considerations brought up 5150 in those and other applicable specifications. 5152 Persistently suspicious behavior: RTSP servers SHOULD return 5153 error code 403 (Forbidden) upon receiving a single instance 5154 of behavior which is deemed a security risk. RTSP servers 5155 SHOULD also be aware of attempts to probe the server for 5156 weaknesses and entry points and MAY arbitrarily disconnect 5157 and ignore further requests clients which are deemed to be 5158 in violation of local security policy. 5160 19 IANA Considerations 5162 This section set up a number of registers for RTSP that should be 5163 maintained by IANA. For each registry there is a description on what 5164 it shall contain, what specification is needed when adding a entry 5165 with IANA, and finally the entries that this document needs to 5166 register. See also the section 1.6 "Extending RTSP". There is also an 5167 IANA registration of two SDP attributes. 5169 The sections describing how to register an item uses some of the 5170 requirements level described in RFC 2434 [17], namely " First Come, 5171 First Served", "Specification Required", and "Standards Action". 5173 A registration request to IANA MUST contain the following 5174 information: 5176 o A name of the item to register according to the rules 5177 specified by the intended registry. 5179 o Indication of who has change control over the feature (for 5180 example, IETF, ISO, ITU-T, other international standardization 5181 bodies, a consortium, a particular company or group of 5182 companies, or an individual); 5184 o A reference to a further description, if available, for 5185 example (in order of preference) an RFC, a published standard, 5186 a published paper, a patent filing, a technical report, 5187 documented source code or a computer manual; 5189 o For proprietary features, contact information (postal and 5190 email address); 5192 19.1 Feature-tags 5194 19.1.1 Description 5196 When a client and server try to determine what part and functionality 5197 of the RTSP specification and any future extensions that its counter 5198 part implements there is need for a namespace. This registry 5199 contains named entries representing certain functionality. 5201 The usage of feature-tags is explained in section 10 and 11.1. 5203 19.1.2 Registering New Feature-tags with IANA 5205 The registering of feature-tags is done on a first come, first served 5206 basis. 5208 The name of the feature MUST follow these rules: The name may be of 5209 any length, but SHOULD be no more than twenty characters long. The 5210 name MUST not contain any spaces, or control characters. The 5211 registration SHALL indicate if the feature tag applies to servers 5212 only, proxies only or both server and proxies. Any proprietary 5213 feature SHALL have as the first part of the name a vendor tag, which 5214 identifies the organization. 5216 19.1.3 Registered entries 5218 The following feature-tags are in this specification defined and 5219 hereby registered. The change control belongs to the Authors and the 5220 IETF MMUSIC WG. 5222 play.basic: The minimal implementation for playback operations 5223 according to section D. Applies for both servers and 5224 proxies. 5226 play.scale: Support of scale operations for media playback. 5227 Applies only for servers. 5229 play.speed: Support of the speed functionality for playback. 5230 Applies only for servers 5232 19.2 RTSP Methods 5234 19.2.1 Description 5236 What a method is, is described in section 11. Extending the protocol 5237 with new methods allow for totally new functionality. 5239 19.2.2 Registering New Methods with IANA 5241 A new method MUST be registered through an IETF standard track 5242 document. The reason is that new methods may radically change the 5243 protocols behavior and purpose. 5245 A specification for a new RTSP method MUST consist of the following 5246 items: 5248 o A method name which follows the BNF rules for methods. 5250 o A clear specification on what action and response a request 5251 with the method will result in. Which directions the method is 5252 used, C -> S or S -> C or both. How the use of headers, if 5253 any, modifies the behavior and effect of the method. 5255 o A list or table specifying which of the registered headers 5256 that are allowed to use with the method in request or/and 5257 response. 5259 o Describe how the method relates to network proxies. 5261 19.2.3 Registered Entries 5263 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 5264 GET_PARAMETER, OPTIONS, PAUSE, PING, PLAY, REDIRECT, SETUP, 5265 SET_PARAMETER, and TEARDOWN. 5267 19.3 RTSP Status Codes 5269 19.3.1 Description 5271 A status code is the three digit numbers used to convey information 5272 in RTSP response messages, see 7. The number space is limited and 5273 care should be taken not to fill the space. 5275 19.3.2 Registering New Status Codes with IANA 5277 A new status code can only be registered by an IETF standards track 5278 document. A specification for a new status code MUST specify the 5279 following: 5281 o The requested number. 5283 o A description what the status code means and the expected 5284 behavior of the sender and receiver of the code. 5286 19.3.3 Registered Entries 5288 RFCXXX, registers the numbered status code defined in the BNF entry 5289 "Status-Code" except "extension-code" in section 17.2.2. 5291 19.4 RTSP Headers 5293 19.4.1 Description 5295 By specifying new headers a method(s) can be enhanced in many 5296 different ways. An unknown header will be ignored by the receiving 5297 entity. If the new header is vital for a certain functionality, a 5298 feature-tag for the functionality can be created and demanded to be 5299 used by the counter-part with the inclusion of a Require header 5300 carrying the feature-tag. 5302 19.4.2 Registering New Headers with IANA 5304 A public available specification is required to register a header. 5305 The specification SHOULD be a standards document, preferable an IETF 5306 RFC. 5308 The specification MUST contain the following information: 5310 o The name of the header. 5312 o A BNF specification of the header syntax. 5314 o A list or table specifying when the header may be used, 5315 encompassing all methods, their request or response, the 5316 direction (C -> S or S -> C). 5318 o How the header shall be handled by proxies. 5320 o A description of the purpose of the header. 5322 19.4.3 Registered entries 5324 All headers specified in section 14 in RFCXXXX are to be registered. 5326 Furthermore the following RTSP headers defined in other 5327 specifications are registered: 5329 o x-wap-profile defined in [35]. 5331 o x-wap-profile-diff defined in [35]. 5333 o x-wap-profile-warning defined in [35]. 5335 o x-predecbufsize defined in [35]. 5337 o x-initpredecbufperiod defined in [35]. 5339 o x-initpostdecbufperiod defined in [35]. 5341 Note: The use of "X-" is NOT RECOMMENDED but the above headers 5342 in the register list was defined prior to the clarification. 5344 19.5 Transport Header registries 5346 The transport header contains a number of parameters which have 5347 possibilities for future extensions. Therefore registries for these 5348 must be defined. 5350 19.5.1 Transport Protocols 5352 A registry for the parameter transport-protocol shall be defined with 5353 the following rules: 5355 o Registering requires public available standards specification. 5357 o A contact person or organization with address and email. 5359 o A value definition that are following the BNF token 5360 definition. 5362 o A describing text that explains how the registered value are 5363 used in RTSP. 5365 This specification registers 1 value: 5367 o Use of the RTP [15] protocol for media transport. The usage 5368 is explained in RFC XXXX, appendix B.1. 5370 19.5.2 Profile 5372 A registry for the parameter profile shall be defined with the 5373 following rules: 5375 o Registering requires public available standards specification. 5377 o A contact person or organization with address and email. 5379 o A value definition that are following the BNF token 5380 definition. 5382 o A definition of which Transport protocol(s) that this profile 5383 is valid for. 5385 o A describing text that explains how the registered value are 5386 used in RTSP. 5388 This specification registers 1 value: 5390 o The "RTP profile for audio and video conferences with minimal 5391 control" [3] MUST only be used when the transport 5392 specification's transport-protocol is "RTP". 5394 19.5.3 Lower Transport 5395 A registry for the parameter lower-transport shall be defined with 5396 the following rules: 5398 o Registering requires public available standards specification. 5400 o A contact person or organization with address and email. 5402 o A value definition that are following the BNF token 5403 definition. 5405 o A text describing how the registered value are used in RTSP. 5407 This specification registers 2 values: | 5409 o Indicates the use of the "User datagram protocol" [8] for 5410 media transport. 5412 o Indicates the use Transmission control protocol [9] for media 5413 transport. 5415 19.5.4 Transport modes 5417 A registry for the transport parameter mode shall be defined with the 5418 following rules: 5420 o Registering requires a IETF standard tracks document. 5422 o A contact person or organization with address and email. 5424 o A value definition that are following the BNF token 5425 definition. 5427 o A describing text that explains how the registered value are 5428 used in RTSP. 5430 This specification registers 2 values: | 5432 o See RFC XXXX. 5434 o See RFC XXXX. 5436 19.6 Cache Directive Extensions 5438 There exist a number of cache directives which can be sent in the 5439 Cache-Control header. A registry for this cache directives shall be 5440 defined with the following rules: 5442 o Registering requires a IETF standard tracks document. 5444 o A registration shall name a contact person. 5446 o Name of the directive and a definition of the value, if any. 5448 o Specification if it is an request or response directive. 5450 o A describing text that explains how the cache directive is 5451 used for RTSP controlled media streams. 5453 This specification registers the following values: | 5455 19.7 SDP attributes 5457 This specification defines two SDP [2] attributes that it is 5458 requested that IANA register. 5460 SDP Attribute ("att-field"): | 5462 Attribute name: range | 5463 Long form: Media Range Attribute | 5464 Type of name: att-field | 5465 Type of attribute: Media and session level | 5466 Subject to charset: No | 5467 Purpose: RFC XXXX | 5468 Reference: RFC XXXX | 5469 Values: See ABNF definition. | 5471 Attribute name: control | 5472 Long form: RTSP control URL | 5473 Type of name: att-field | 5474 Type of attribute: Media and session level | 5475 Subject to charset: No | 5476 Purpose: RFC XXXX | 5477 Reference: RFC XXXX | 5478 Values: Absolute or Relative URLs. | 5480 Attribute name: etag | 5481 Long form: Entity Tag | 5482 Type of name: att-field | 5483 Type of attribute: Media and session level | 5484 Subject to charset: No | 5485 Purpose: RFC XXXX | 5486 Reference: RFC XXXX | 5487 Values: See ABNF definition | 5489 A RTSP Protocol State Machine 5491 The RTSP session state machine describe the behavior of the protocol 5492 from RTSP session initialization through RTSP session termination. 5494 State machine is defined on a per session basis which is uniquely 5495 identified by the RTSP session identifier. The session may contain 5496 one or more media streams depending on state. If a single media 5497 stream is part of the session it is in non-aggregated control. If two 5498 or more is part of the session it is in aggregated control. 5500 This state machine is one possible representation that helps explain 5501 how the protocol works and when different requests are allowed. We 5502 find it a reasonable representation but does not mandate it, and 5503 other representations can be created. 5505 A.1 States 5507 The state machine contains three states, described below. For each 5508 state there exist a table which shows which requests and events that 5509 is allowed and if they will result in a state change. 5511 Init: Initial state no session exist. 5513 Ready: Session is ready to start playing. 5515 Play: Session is playing, i.e. sending media stream data in the 5516 direction S -> C. 5518 A.2 State variables 5520 This representation of the state machine needs more than its state to 5521 work. A small number of variables are also needed and is explained 5522 below. 5524 NRM: The number of media streams part of this session. 5526 RP: Resume point, the point in the presentation time line at 5527 which a request to continue will resume from. A time format 5528 for the variable is not mandated. 5530 A.3 Abbreviations 5532 To make the state tables more compact a number of abbreviations are 5533 used, which are explained below. 5535 IFI: IF Implemented. 5537 md: Media 5539 PP: Pause Point, the point in the presentation time line at 5540 which the presentation was paused. 5542 Prs: Presentation, the complete multimedia presentation. 5544 RedP: Redirect Point, the point in the presentation time line at 5545 which a REDIRECT was specified to occur. 5547 SES: Session. 5549 A.4 State Tables 5551 This section contains a table for each state. The table contains all 5552 the requests and events that this state is allowed to act on. The 5553 events which is method names are, unless noted, requests with the 5554 given method in the direction client to server (C -> S). In some 5555 cases there exist one or more requisite. The response column tells 5556 what type of response actions should be performed. Possible actions 5557 that is requested for an event includes: response codes, e.g. 200, 5558 headers that MUST be included in the response, setting of state 5559 variables, or setting of other session related parameters. The new 5560 state column tells which state the state machine shall change to. 5562 The response to valid request meeting the requisites is normally a | 5563 2xx (SUCCESS) unless other noted in the response column. The | 5564 exceptions shall be given a response according to the response | 5565 column. If the request does not meet the requisite, is erroneous or | 5566 some other type of error occur the appropriate response code MUST be | 5567 sent. If the response code is a 4xx the session state is unchanged. A | 5568 response code of 3rr will result in that the session is ended and its | 5569 state is changed to Init. A response code of 304 results in no state | 5570 change. However there exist restrictions to when a 3xx response may | 5571 be used. A 5xx response SHALL not result in any change of the session | 5572 state, except if the error is not possible to recover from. A | 5573 unrecoverable error SHALL result the ending of the session. As it in | 5574 the general case can't be determined if it was a unrecoverable error | 5575 or not the client will be required to test. In the case that the next | 5576 request after a 5xx is responded with 454 (Session Not Found) the | 5577 client shall assume that the session has been ended. 5579 The server will timeout the session after the period of time 5580 specified in the SETUP response, if no activity from the client is 5581 detected. Therefore there exist a timeout event for all states 5582 except Init. 5584 In the case that NRM=1 the presentation URL is equal to the media 5585 URL. For NRM>1 the presentation URL MUST be other than any of the 5586 medias that are part of the session. This applies to all states. 5588 Event Prerequisite Response 5589 ______________________________________________________________ 5590 DESCRIBE Needs REDIRECT 3rr Redirect 5591 DESCRIBE 200, Session description 5592 OPTIONS Session ID 200, Reset session timeout timer 5593 OPTIONS 200 5594 SET_PARAMETER Valid parameter 200, change value of parameter 5595 GET_PARAMETER Valid parameter 200, return value of parameter 5597 Table 11: None state-machine changing events 5599 The methods in Table 11 do not have any effect on the state machine 5600 or the state variables. However some methods do change other session 5601 related parameters, for example SET_PARAMETER which will set the 5602 parameter(s) specified in its body. 5604 Action Requisite New State Response 5606 _____________________________________________________________ 5607 SETUP Ready NRM=1, RP=0.0 5608 SETUP Needs Redirect Init 3rr Redirect 5609 S -> C:REDIRECT No Session hdr Init Terminate all SES 5611 Table 12: State: Init 5613 The initial state of the state machine, see Table 12 can only be left 5614 by processing a correct SETUP request. As seen in the table the two 5615 state variables are also set by a correct request. This table also 5616 shows that a correct SETUP can in some cases be redirected to another 5617 URL and/or server by a 3rr response. 5619 In the Ready state, see Table 13, some of the actions are depending 5620 on the number of media streams (NRM) in the session, i.e. aggregated 5621 or non-aggregated control. A setup request in the ready state can 5622 either add one more media stream to the session or if the media 5623 stream (same URL) already is part of the session change the transport 5624 parameters. TEARDOWN is depending on both the request URL and the 5625 Action Requisite New State Response 5626 ______________________________________________________________________ 5627 SETUP New URL Ready NRM+=1 5628 SETUP Setten up URL Ready Change transport param. 5629 TEARDOWN Prs URL,NRM>1 Init No session hdr 5630 TEARDOWN md URL,NRM=1 Init No Session hdr, NRM=0 5631 TEARDOWN md URL,NRM>1 Ready Session hdr, NRM-=1 5632 PLAY Prs URL, No range Play Play from RP 5633 PLAY Prs URL, Range Play according to range 5634 PAUSE Prs URL Ready Return PP 5635 S -> C:REDIRECT Range hdr Ready Set RedP 5636 S -> C:REDIRECT no range hdr Init Session is removed 5637 Timeout Init 5638 RedP reached Ready TEARDOWN of session 5640 Table 13: State: Ready 5642 number of media stream within the session. If the request URL is the 5643 presentations URL the whole session is torn down. If a media URL is 5644 used in the TEARDOWN request and more than one media exist in the 5645 session, the session will remain and a session header MUST be 5646 returned in the response. If only a single media stream remains in 5647 the session when performing a TEARDOWN with a media URL the session 5648 is removed. The number of media streams remaining after tearing down 5649 a media stream determines the new state. 5651 The Play state table, see Table 14, is the largest. The table 5652 contains an number of request that has presentation URL as a 5653 prerequisite on the request URL, this is due to the exclusion of 5654 non-aggregated stream control in sessions with more than one media 5655 stream. 5657 To avoid inconsistencies between the client and server, automatic 5658 state transitions are avoided. This can be seen at for example "End 5659 of media" event when all media has finished playing, the session 5660 still remain in Play state. An explicit PAUSE request must be sent to 5661 change the state to Ready. It may appear that there exist two 5662 automatic transitions in "RedP reached" and "PP reached", however 5663 they are requested and acknowledge before they take place. The time 5664 at which the transition will happen is known by looking at the range 5665 header. If the client sends request close in time to these 5666 transitions it must be prepared for getting error message as the 5667 state may or may not have changed. 5669 B Media Transport Alternatives 5670 Action Requisite New State Response 5671 ________________________________________________________________________ 5672 PAUSE PrsURL,No range Ready Set RP to present point 5673 PAUSE PrsURL,Range>now Play Set RP & PP to given point 5674 PAUSE PrsURL,Range1 Media plays Play No action 5678 End of range Play Set RP = End of range 5679 SETUP New URL Play 455 5680 SETUP Setuped URL Play 455 5681 SETUP Setuped URL, IFI Play Change transport param. 5682 TEARDOWN Prs URL,NRM>1 Init No session hdr 5683 TEARDOWN md URL,NRM=1 Init No Session hdr, NRM=0 5684 TEARDOWN md URL Play 455 5685 S -> C:REDIRECT Range hdr Play Set RedP 5686 S -> C:REDIRECT no range hdr Init Session is removed 5687 RedP reached Play TEARDOWN of session 5688 Timeout Init Stop Media playout 5690 Table 14: State: Play 5692 This chapter defines how certain combinations of protocols, profiles 5693 and lower transports are used. This includes the usage of the 5694 Transport header's general source and destination parameters 5695 "src_addr" and "dest_addr". 5697 B.1 RTP 5699 This section defines the interaction of RTSP with respect to the RTP 5700 protocol [15]. It also defines any necessary media transport 5701 signalling with regards to RTP. 5703 The available RTP profiles and lower layer transports are described 5704 below along with rules on signalling the available combinations. 5706 B.1.1 AVP 5708 The usage of the "RTP Profile for Audio and Video Conferences with 5709 Minimal Control" [3] when using RTP for media transport over 5710 different lower layer transport protocols are defined below in 5711 regards to RTSP. 5713 On such case is defined within this document, the use of embedded 5714 (interleaved) binary data as defined in section 12. The usage of 5715 this method is indicated by include the "interleaved" parameter. 5717 When using embedded binary data the "src_addr" and "dest_addresses" 5718 SHALL NOT be used. This addressing and multiplexing is used as 5719 defined with use of channel numbers and the interleaved parameter. 5721 B.1.2 AVP/UDP 5723 This part descibes sending of RTP [15] over lower transport layer UDP 5724 [8] according to the profile "RTP Profile for Audio and Video 5725 Conferences with Minimal Control" defined in RFC 3551 [3]. This 5726 profiles requires that one or two uni- or bi-directional UDP flows 5727 per media stream. The first UDP flow is for RTP and the second is 5728 for RTCP. Embedded (interleaved) data when RTSP messages is 5729 transported over UDP SHOULD NOT be performed. 5731 The RTP/UDP and RTCP/UDP flows can be established in two ways using 5732 the Transport header's parameters. The way provided in RFC 2326 was 5733 to use the necessary parameters from the set of "source", 5734 "destination", "client_port", and "server_port". This has the 5735 advantage of being compatible with all RTP capable RTSP servers and 5736 clients. However this method does not provide a possibility to 5737 specify non-continues port ranges for RTP and RTCP. The other way is 5738 to use the parameters "src_addr", and "dest_addr". This method 5739 provides total flexibility in specifying address and port number for 5740 each transport flow. However the disadvantage is that it is not 5741 supported by non-updated clients, i.e. clients not supporting the 5742 "play.basic" feature-tag. 5744 When using the "source", "destination", "client_port", and 5745 "server_port" the packets are be addressed in the following way for 5746 media playback: 5748 o RTP/UDP packet from the server to the client SHALL be sent to 5749 the address specified in the "destination" parameter and first 5750 even port number given in client_port range. If there is only 5751 a single port number given that MUST be given. 5753 o The server SHOULD send its RTP/UDP packets from the address 5754 specified in "source" parameter and from the first even port 5755 number specified in "server_port" parameter. 5757 o If there is specified a range in "client_port" parameter that 5758 contains at least two port numbers, the RTCP/UDP packets from 5759 server to client SHALL be sent to address specified in the 5760 "destination" parameter and first odd port number part of the 5761 range specified in the client_port parameter. 5763 o The Server SHOULD send its RTCP/UDP packets from the address | 5764 specified in "source" parameter and from the first odd port | 5765 number greater than the RTP port number specified in | 5766 "server_port" parameter. | 5768 o RTCP/UDP packets from the client to the server SHALL be sent | 5769 to the address specified in the "source" parameter and first | 5770 odd port number greater than the RTP port number given in | 5771 client_port range. | 5773 o The client SHOULD send its RTCP/UDP packets from the address | 5774 specified in "destination" parameter and from the first odd | 5775 port number specified in "server_port" parameter. | 5777 The usage of "src_addr" and "dest_addr" parameters to specify the 5778 address and port numbers are done in the following way for media 5779 playback, i.e. Mode=PLAY: 5781 o The "src_addr" and "dest_addr" parameters MUST contain either 5782 1 or 2 address and port pairs. 5784 o Each address and port pair MUST contain both and address and a 5785 port number. 5787 o The first address and port pair given in either of the 5788 parameters applies to the RTP stream. The second address and 5789 port pair if present applies to the RTCP stream. 5791 o The RTP/UDP packets from the server to the client SHALL be 5792 sent to the address and port given by first address and port 5793 pair of the "dest_addr" parameter. 5795 o The RTCP/UDP packets from the server to the client SHALL be 5796 sent to the address and port given by the second address and 5797 port pair of the "dest_addr" parameter. If no second pair is 5798 given RTCP SHALL NOT be sent. 5800 o The RTCP/UDP packets from the client to the server SHALL be 5801 sent to the address and port given by the second address and 5802 port pair of the "dest_addr" parameter. If no second pair is 5803 given RTCP SHALL NOT be sent. 5805 o RTP and RTCP Packets SHOULD be sent from the corresponding 5806 receiver port, i.e. RTCP packets from server should be sent 5807 from the "src_addr" parameters second address port pair. 5809 B.1.3 AVP/TCP 5810 Note that this combination is not yet defined using sperate TCP 5811 connections. However the use of embedded (interleaved) binary data 5812 transported on the RTSP connection is possible as specified in 5813 section 12. When using this declared combination of interleaved 5814 binary data the RTSP messages MUST be transported over TCP. 5816 A possible future for this profile would be to define the use of a 5817 combination of the two drafts "Connection-Oriented Media Transport in 5818 SDP" [36] and "Framing RTP and RTCP Packets over Connection-Oriented 5819 Transport" [37]. However as this work is not finished, this 5820 functionality is unspecified. 5822 B.1.4 Handling NPT Jumps in the RTP Media Layer | 5824 RTSP allows media clients to control selected, non-contiguous | 5825 sections of media presentations, rendering those streams with an RTP | 5826 media layer[15]. Such control allows jumps to be created in NPT | 5827 timeline of the RTSP session. For example, jumps in NPT can be caused | 5828 by multiple ranges in the range specifier of a PLAY request or | 5829 through a "seek" opertaion on an RTSP session which involves a PLAY, | 5830 PAUSE, PLAY scenario where a new NPT is set for the session. The | 5831 media layer rendering the RTP stream should not be affected by jumps | 5832 in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be | 5833 continuous and monotonic across jumps of NPT. | 5835 We cannot assume that the RTSP client can communicate with | 5836 the RTP media agent, as the two may be independent | 5837 processes. If the RTP timestamp shows the same gap as the | 5838 NPT, the media agent will assume that there is a pause in | 5839 the presentation. If the jump in NPT is large enough, the | 5840 RTP timestamp may roll over and the media agent may believe | 5841 later packets to be duplicates of packets just played out. | 5843 As an example, assume a clock frequency of 8000 Hz, a packetization | 5844 interval of 100 ms and an initial sequence number and timestamp of | 5845 zero. | 5847 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 | 5848 CSeq: 4 | 5849 Session: abcdefg | 5850 Range: npt=10-15; | 5852 S->C: RTSP/1.0 200 OK | 5853 CSeq: 4 | 5854 Session: abcdefg | 5855 Range: npt=10-15 | 5856 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0; | 5857 rtptime=0 | 5859 The ensuing RTP data stream is depicted below: | 5861 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s | 5862 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s | 5863 . . . | 5864 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s | 5866 Immediately after the end of the play range, the client follows up | 5867 with a request to PLAY from a new NPT. | 5869 C->S: PAUSE rtsp://xyz/fizzle RTSP/1.0 | 5870 CSeq: 5 | 5871 Session: abcdefg | 5873 S->C: RTSP/1.0 200 OK | 5874 CSeq: 5 | 5875 Session: abcdefg | 5876 Range: npt=15-15 | 5878 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 | 5879 CSeq: 6 | 5880 Session: abcdefg | 5881 Range: npt=18-20; | 5883 S->C: RTSP/1.0 200 OK | 5884 CSeq: 6 | 5885 Session: abcdefg | 5886 Range: npt=18-20 | 5887 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=50; | 5888 rtptime=40000 | 5889 | 5891 The ensuing RTP data stream is depicted below: | 5893 S->C: RTP packet - seq = 50, rtptime = 40000, NPT time = 18s | 5894 S->C: RTP packet - seq = 51, rtptime = 40800, NPT time = 18.1s | 5895 . . . | 5897 S->C: RTP packet - seq = 69, rtptime = 55200, NPT time = 19.9s | 5899 First we play NPT 10 through 15, then skip ahead and play NPT 18 | 5900 through 20. The first segment is presented as RTP packets with | 5901 sequence numbers 0 through 49 and timestamp 0 through 39,200. The | 5902 second segment consists of RTP packets with sequence number 50 | 5903 through 69, with timestamps 40,000 through 55,200. While there is a | 5904 gap in the NPT, there is no gap in the sequence number or timestamp | 5905 space of the RTP data stream. | 5907 B.1.5 Handling RTP Timestamps after PAUSE | 5909 During a PAUSE / PLAY interaction in a RTSP session, the duration of | 5910 time for which the RTP transmission was halted MUST be reflected in | 5911 the RTP timestamp of each RTP stream. The duration can be calculated | 5912 for each RTP stream as the time elapsed from when the last RTP packet | 5913 was sent before the PAUSE request was received and when the first RTP | 5914 packet was sent after thesubsequent PLAY request was received. The | 5915 duration includes all latency incurred and processing time required | 5916 to complete the request. | 5918 The RTP RFC [15] states that: The RTP timestamp for each | 5919 unit[packet] would be related to the wallclock time at | 5920 which the unit becomes current on the virtual presentation | 5921 timeline. | 5923 In order to satisfy the requirements of [15], the RTP timestamp space | 5924 must increase continously with real time. While this is not optimal | 5925 for stored media, it is required for RTP and RTCP to function as | 5926 intended. Using a continous RTP timestamp space allows the same | 5927 timestamp model for both stored and live media and allows better | 5928 opportunity to integrate both types of media under a single control. | 5930 As an example, assume a clock frequency of 8000 Hz, a packetization | 5931 interval of 100 ms and an initial sequence number and timestamp of | 5932 zero. | 5934 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 | 5935 CSeq: 4 | 5936 Session: abcdefg | 5937 Range: npt=10-15; | 5939 S->C: RTSP/1.0 200 OK | 5940 CSeq: 4 | 5941 Session: abcdefg | 5942 Range: npt=10-15 | 5943 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0; | 5944 rtptime=0 | 5946 The ensuing RTP data stream is depicted below: | 5948 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s | 5949 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s | 5950 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s | 5951 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s | 5953 The client then sends a PAUSE request: | 5955 C->S: PAUSE rtsp://xyz/fizzle RTSP/1.0 | 5956 CSeq: 5 | 5957 Session: abdcdefg | 5959 S->C: RTSP/1.0 200 OK | 5960 CSeq: 5 | 5961 Session: abcdefg | 5962 Range: npt=10.4-15 | 5964 20 seconds elapse and then the client sends a PLAY request. In | 5965 addtion the server requires 15 ms to process the request: | 5967 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 | 5968 CSeq: 6 | 5969 Session: abcdefg | 5971 S->C: RTSP/1.0 200 OK | 5972 CSeq: 6 | 5973 Session: abcdefg | 5974 Range: npt=10.4-15 | 5975 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=4; | 5976 rtptime=164400 | 5978 The ensuing RTP data stream is depicted below: | 5980 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s | 5981 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s | 5982 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s | 5984 First, we play NPT 10 through 10.3, when a PAUSE is received by the | 5985 server. After 20 seconds a PLAY is recieved by the server which take | 5986 15ms to process. The duration of time for which the session was | 5987 paused is reflected in the RTP timestamp of the RTP packets sent | 5988 after this PLAY request. | 5990 A client can use the RTSP range header and RTP-Info header to map NPT | 5991 time of a presentation with the RTP timestamp. | 5993 Note: In RFC 2326 [1], this matter was not clearly defined and was | 5994 misunderstood commonly. Therefore, clients SHOULD expect servers to | 5995 break the continuity of the RTP timestamp space in various arbitrary | 5996 manners after a PAUSE request. In these cases, it is RECOMMENDED that | 5997 clients accept the RTP stream after the pause with appropriate | 5998 mappings provided by the RTP-Info and Range headers. | 6000 B.1.6 RTSP / RTP Integration | 6002 For certain datatypes, tight integration between the RTSP layer and | 6003 the RTP layer will be necessary. This by no means precludes the above | 6004 restrictions. Combined RTSP/RTP media clients should use the RTP-Info | 6005 field to determine whether incoming RTP packets were sent before or | 6006 after a seek or before or after a PAUSE. | 6008 B.1.7 Scaling with RTP | 6010 For scaling (see Section 14.34), RTP timestamps should correspond to | 6011 the playback timing. For example, when playing video recorded at 30 | 6012 frames/second at a scale of two and speed (Section 14.35) of one, the | 6013 server would drop every second frame to maintain and deliver video | 6014 packets with the normal timestamp spacing of 3,000 per frame, but NPT | 6015 would increase by 1/15 second for each video frame. | 6017 B.1.8 Maintaining NPT synchronization with RTP timesatmps | 6019 The client can maintain a correct display of NPT by noting the RTP | 6020 timestamp value of the first packet arriving after repositioning. | 6021 The sequence parameter of the RTP-Info (Section 14.33) header | 6022 provides the first sequence number of the next segment. | 6024 B.1.9 Continuous Audio | 6026 For continuous audio, the server SHOULD set the RTP marker bit at the | 6027 beginning of serving a new PLAY request. This allows the client to | 6028 perform playout delay adaptation. | 6030 B.1.10 Multiple Sources in an RTP Session | 6032 Note that more than one SSRC MAY be sent in the media stream. | 6033 However, without further extensions RTSP can't synchronize more than | 6034 the single one indicated in the Transport header. In these cases RTCP | 6035 needs to be used for synchronization. | 6037 B.1.11 Usage of SSRCs and the RTCP BYE Message During a RTSP Session | 6039 The RTCP BYE message indicates the end of a RTP session as well as | 6040 the end of use of a given SSRC. Therefore, a client or server SHALL | 6041 NOT send a RTCP BYE message until it has finished using a SSRC. A | 6042 server SHOULD keep using a SSRC until the RTP session is terminated. | 6043 Prologing the use of a SSRC allows the established synchronization | 6044 context associated with that SSRC to be used to sychronize subsequent | 6045 PLAY requests even if the PLAY response is late. Additionally, | 6046 changing the server side SSRC will prevent the server from | 6047 synchronizing the new SSRC within RTSP as it is connected to the one | 6048 declared in the ssrc parameter in the Transport header. | 6050 B.2 Future Additions 6052 It is the intention that any future protocol or profile regarding 6053 both for media delivery and lower transport should be easy to add to 6054 RTSP. This chapter provides the necessary steps that needs to be 6055 meet. 6057 The following things needs to be considered when adding a new 6058 protocol of profile for use with RTSP: 6060 o The protocol or profile needs to define a name tag 6061 representing it. This tag is required to be a ABNF "token" to 6062 be possible to use in the Transport header specification. 6064 o The useful combinations of protocol/profile/lower-layer needs 6065 to be defined and for each combination declare the necessary 6066 parameters to use in the Transport header. 6068 o For new media protocols the interaction with RTSP needs to be 6069 addressed. One important factor will be the media 6070 synchronization. 6072 See the IANA section ( 19) on how to register the necessary 6073 attributes. 6075 C Use of SDP for RTSP Session Descriptions 6077 The Session Description Protocol (SDP, RFC 2327 [2]) may be used to 6078 describe streams or presentations in RTSP. This description is 6079 typically returned in reply to a DESCRIBE request on a URL from a 6080 server to a client, or received via HTTP from a server to a client. 6082 This appendix describes how an SDP file determines the operation of 6083 an RTSP session. SDP as is provides no mechanism by which a client 6084 can distinguish, without human guidance, between several media 6085 streams to be rendered simultaneously and a set of alternatives 6086 (e.g., two audio streams spoken in different languages). However the 6087 SDP extension "Grouping of Media Lines in the Session Description 6088 Protocol (SDP)" [38] may provide such functionality depending on 6089 need. Also future grouping semantics may in the future be developed. 6091 C.1 Definitions 6093 The terms "session-level", "media-level" and other key/attribute 6094 names and values used in this appendix are to be used as defined in 6095 SDP (RFC 2327 [2]): 6097 C.1.1 Control URL 6099 The "a=control:" attribute is used to convey the control URL. This 6100 attribute is used both for the session and media descriptions. If 6101 used for individual media, it indicates the URL to be used for 6102 controlling that particular media stream. If found at the session 6103 level, the attribute indicates the URL for aggregate control 6104 (presentation URL). The session level URL SHALL be different from any 6105 media level URL. The presence of a session level control attribute 6106 SHALL be interpreted as support for aggregated control. The control 6107 attribute SHALL be present on media level unless the presentation 6108 only contains a single media stream, in which case the attribute MAY 6109 only be present on the session level. 6111 control-attribute = "a=" "control" ":" url 6113 Example: 6115 a=control:rtsp://example.com/foo 6117 This attribute MAY contain either relative and absolute URLs, 6118 following the rules and conventions set out in RFC 2396 [12]. 6119 Implementations SHALL look for a base URL in the following order: 6121 1. the RTSP Content-Base field; 6123 2. the RTSP Content-Location field; 6125 3. the RTSP request URL. 6127 If this attribute contains only an asterisk (*), then the URL SHALL 6128 be treated as if it were an empty embedded URL, and thus inherit the 6129 entire base URL. 6131 For SDP retrieved from a container file, there are certain things to 6132 consider. Lets say that the container file has the following URL: 6133 "rtsp://example.com/container.mp4". A media level relative URL needs 6134 to contain the file name container.mp4 in the beginning to be 6135 resolved correctly relative to the before given URL. An alternative 6136 if one does not desire to enter the container files name is to ensure 6137 that the base URL for the SDP document becomes: 6138 "rtsp://example.com/container.mp4/", i.e. an extra trailing slash. 6139 When using the URL resolution rules in RFC 2396 that will resolve 6140 correctly. However, please note that if the session level control URL 6141 is a *, that control URL will be equal to 6142 "rtsp://example.com/container.mp4/" and include the slash. 6144 C.1.2 Media Streams 6146 The "m=" field is used to enumerate the streams. It is expected that 6147 all the specified streams will be rendered with appropriate 6148 synchronization. If the session is a multicast, the port number 6149 indicated SHOULD be used for reception. The client MAY try to 6150 override the destination port, through the Transport header. The 6151 servers MAY allow this, the response will indicate if allowed or not. 6152 If the session is unicast, the port number is the ones RECOMMENDED by 6153 the server to the client, about which receiver ports to use; the 6154 client MUST still include its receiver ports in its SETUP request. 6155 The client MAY ignore this recommendation. If the server has no 6156 preference, it SHOULD set the port number value to zero. 6158 The "m=" lines contain information about what transport protocol, 6159 profile, and possibly lower-layer shall be used for the media stream. 6160 The combination of transport, profile and lower layer, like 6161 RTP/AVP/UDP needs to be defined for how to be used with RTSP. The 6162 currently defined combinations are defined in section B, further 6163 combinations MAY be specified. 6165 TODO: Write something about the usage of Grouping of media line, RFC 6166 3388 [38]. 6168 Example: 6170 m=audio 0 RTP/AVP 31 6172 C.1.3 Payload Type(s) 6174 The payload type(s) are specified in the "m=" field. In case the | 6175 payload type is a static payload type from RFC 3551 [3], no other | 6176 information is required. In case it is a dynamic payload type, the | 6177 media attribute "rtpmap" is used to specify what the media is. The | 6178 "encoding name" within the "rtpmap" attribute may be one of those | 6179 specified in RFC 3551 (Sections 5 and 6), or an MIME type registered | 6180 with IANA, or an experimental encoding as specified in SDP (RFC 2327 | 6181 [2]). Codec-specific parameters are not specified in this field, but | 6182 rather in the "fmtp" attribute described below. 6184 C.1.4 Format-Specific Parameters 6186 Format-specific parameters are conveyed using the "fmtp" media 6187 attribute. The syntax of the "fmtp" attribute is specific to the 6188 encoding(s) that the attribute refers to. Note that some of the 6189 format specific parameters may be specified outside of the fmtp 6190 parameters, like for example the "ptime" attribute for most audio 6191 encodings. 6193 C.1.5 Range of Presentation 6195 The "a=range" attribute defines the total time range of the stored 6196 session or an individual media. Non-seekable live sessions can be 6197 indicated, while the length of live sessions can be deduced from the 6198 "t" and "r" SDP parameters. 6200 The attribute is both a session and a media level attribute. For 6201 presentations that contains media streams of the same durations, the 6202 range attribute SHOULD only be used at session-level. In case of 6203 different length the range attribute MUST be given at media level for 6204 all media, and SHOULD NOT be given at session level. If the attribute 6205 is present at both media level and session level the media level 6206 values SHALL be used. 6208 The unit is specified first, followed by the value range. The units | 6209 and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY | 6210 be extended with further formats. Any open ended range (start-), i.e. | 6211 without stop range, is of unspecified duration and SHALL be | 6212 considered as non-seekable content unless this property is | 6213 overridden. 6215 This attribute is defined in ABNF [5] as: 6217 a-range-def = "a" "=" "range" ":" ranges-specifier CRLF 6219 Examples: 6221 a=range:npt=0-34.4368 6222 a=range:clock=19971113T2115-19971113T2203 6223 Non seekable stream of unknown duration: 6224 a=range:npt=0- 6226 C.1.6 Time of Availability 6228 The "t=" field MUST contain suitable values for the start and stop 6229 times for both aggregate and non-aggregate stream control. The 6230 server SHOULD indicate a stop time value for which it guarantees the 6231 description to be valid, and a start time that is equal to or before 6232 the time at which the DESCRIBE request was received. It MAY also 6233 indicate start and stop times of 0, meaning that the session is 6234 always available. 6236 For sessions that are of live type, i.e. specific start time, unknown | 6237 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used | 6238 to indicate the start time of the event. The stop time SHOULD be | 6239 given so that the live event will with high probability have ended at | 6240 that time, while still not be unnecessary long into the future. 6242 C.1.7 Connection Information 6244 In SDP, the "c=" field contains the destination address for the media 6245 stream. For a media destination address that is a IPv6 one, the SDP 6246 extension defined in [18] needs to be used. For on-demand unicast 6247 streams and some multicast streams, the destination address MAY be 6248 specified by the client via the SETUP request, thus overriding any 6249 specified address. To identify streams without a fixed destination 6250 address, where the client must specify a destination address, the 6251 "c=" field SHOULD be set to a null value. For addresses of type 6252 "IP4", this value SHALL be "0.0.0.0", and for type "IP6", this value 6253 SHALL be "0:0:0:0:0:0:0:0", i.e. the unspecified address according to 6254 RFC 3513 [19]. 6256 C.1.8 Entity Tag 6258 The optional "a=etag" attribute identifies a version of the session 6259 description. It is opaque to the client. SETUP requests may include 6260 this identifier in the If-Match field (see section 14.22) to only 6261 allow session establishment if this attribute value still corresponds 6262 to that of the current description. The attribute value is opaque 6263 and may contain any character allowed within SDP attribute values. 6265 a-etag-def = "a" "=" "etag" ":" etag-string CRLF 6266 etag-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 6268 Example: 6270 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 6272 One could argue that the "o=" field provides identical 6273 functionality. However, it does so in a manner that would 6274 put constraints on servers that need to support multiple 6275 session description types other than SDP for the same piece 6276 of media content. 6278 C.2 Aggregate Control Not Available 6280 If a presentation does not support aggregate control no session level 6281 "a=control:" attribute is specified. For a SDP with multiple media 6282 sections specified, each section will have its own control URL 6283 specified via the "a=control:" attribute. 6285 Example: 6287 v=0 6288 o=- 2890844256 2890842807 IN IP4 204.34.34.32 6289 s=I came from a web page 6290 e=adm@example.com 6291 c=IN IP4 0.0.0.0 6292 t=0 0 6293 m=video 8002 RTP/AVP 31 6294 a=control:rtsp://audio.com/movie.aud 6295 m=audio 8004 RTP/AVP 3 6296 a=control:rtsp://video.com/movie.vid 6297 Note that the position of the control URL in the description implies 6298 that the client establishes separate RTSP control sessions to the 6299 servers audio.com and video.com 6301 It is recommended that an SDP file contains the complete media 6302 initialization information even if it is delivered to the media 6303 client through non-RTSP means. This is necessary as there is no 6304 mechanism to indicate that the client should request more detailed 6305 media stream information via DESCRIBE. 6307 C.3 Aggregate Control Available 6309 In this scenario, the server has multiple streams that can be 6310 controlled as a whole. In this case, there are both a media-level 6311 "a=control:" attributes, which are used to specify the stream URLs, 6312 and a session-level "a=control:" attribute which is used as the 6313 request URL for aggregate control. If the media-level URL is 6314 relative, it is resolved to absolute URLs according to Section C.1.1 6315 above. 6317 Example: 6319 C->M: DESCRIBE rtsp://example.com/movie RTSP/1.0 6320 CSeq: 1 6322 M->C: RTSP/1.0 200 OK 6323 CSeq: 1 6324 Date: 23 Jan 1997 15:35:06 GMT 6325 Content-Type: application/sdp 6326 Content-Base: rtsp://example.com/movie/ 6327 Content-Length: 164 6329 v=0 6330 o=- 2890844256 2890842807 IN IP4 204.34.34.32 6331 s=I contain 6332 i= 6333 e=adm@example.com 6334 c=IN IP4 0.0.0.0 6335 t=0 0 6336 a=control:* 6337 m=video 8002 RTP/AVP 31 6338 a=control:trackID=1 6339 m=audio 8004 RTP/AVP 3 6340 a=control:trackID=2 6342 In this example, the client is required to establish a single RTSP 6343 session to the server, and uses the URLs 6344 rtsp://example.com/movie/trackID=1 and 6345 rtsp://example.com/movie/trackID=2 to set up the video and audio 6346 streams, respectively. The URL rtsp://example.com/movie/ , which is 6347 resolved from the "*", controls the whole presentation (movie). 6349 A client is not required to issues SETUP requests for all streams 6350 within an aggregate object. Servers should allow the client to ask 6351 for only a subset of the streams. 6353 C.4 RTSP external SDP delivery 6355 There are some considerations that needs to be made when the session 6356 description is delivered to client outside of RTSP, for example in 6357 HTTP or email. 6359 First of all the SDP needs to contain absolute URLs, relative will in 6360 most cases not work as the delivery will not correctly forward the 6361 base URL. And as SDP might be temporarily stored on file system 6362 before being loaded into a RTSP capable client, thus if possible to 6363 transport the base URL it still would need to be merged into the 6364 file. 6366 The writing of the SDP session availability information, i.e. "t=" 6367 and "r=", needs to be carefully considered. When the SDP is fetched 6368 by the DESCRIBE method it is with very high probability that the it 6369 is valid. However the same are much less certain for SDPs distributed 6370 using other methods. Therefore the publisher of the SDP should take 6371 care to follow the recommendations about availability in the SDP 6372 specification [2]. 6374 D Minimal RTSP implementation 6376 D.1 Client 6378 A client implementation MUST be able to do the following : 6380 o Generate the following requests: SETUP, TEARDOWN, PLAY. 6382 o Include the following headers in requests: CSeq, Connection, 6383 Session, Transport. 6385 o Parse and understand the following headers in responses: 6386 CSeq, Connection, Session, Transport, Content-Language, 6387 Content-Encoding, Content-Length, Content-Type. 6389 o Understand the class of each error code received and notify 6390 the end-user, if one is present, of error codes in classes 4xx 6391 and 5xx. The notification requirement may be relaxed if the 6392 end-user explicitly does not want it for one or all status 6393 codes. 6395 o Expect and respond to asynchronous requests from the server, 6396 such as REDIRECT. This does not necessarily mean that it 6397 should implement the REDIRECT method, merely that it MUST 6398 respond positively or negatively to any request received from 6399 the server. 6401 Though not required, the following are RECOMMENDED. 6403 o Implement RTP/AVP/UDP as a valid transport. 6405 o Inclusion of the User-Agent header. 6407 o Understand SDP session descriptions as defined in Appendix C 6409 o Accept media initialization formats (such as SDP) from 6410 standard input, command line, or other means appropriate to 6411 the operating environment to act as a "helper application" for 6412 other applications (such as web browsers). 6414 There may be RTSP applications different from those 6415 initially envisioned by the contributors to the RTSP 6416 specification for which the requirements above do not make 6417 sense. Therefore, the recommendations above serve only as 6418 guidelines instead of strict requirements. 6420 D.1.1 Basic Playback 6422 To support on-demand playback of media streams, the client MUST 6423 additionally be able to do the following: 6425 o generate the PAUSE request; 6427 o implement the REDIRECT method, and the Location header. 6429 D.1.2 Authentication-enabled 6431 In order to access media presentations from RTSP servers that require 6432 authentication, the client MUST additionally be able to do the 6433 following: 6435 o recognize the 401 (Unauthorized) status code; 6436 o parse and include the WWW-Authenticate header; 6438 o implement Basic Authentication and Digest Authentication. 6440 D.2 Server 6442 A minimal server implementation MUST be able to do the following: 6444 o Implement the following methods: SETUP, TEARDOWN, OPTIONS and 6445 PLAY. 6447 o Include the following headers in responses: Connection, 6448 Content-Length, Content-Type, Content-Language, Content- 6449 Encoding, Timestamp, Transport, Public, and Via, and 6450 Unsupported. RTP-compliant implementations MUST also 6451 implement the RTP-Info field. 6453 o Parse and respond appropriately to the following headers in 6454 requests: Connection, Proxy-Require, Session, Transport, and 6455 Require. 6457 Though not required, the following are highly recommended at the time 6458 of publication for practical interoperability with initial 6459 implementations and/or to be a "good citizen". 6461 o Implement RTP/AVP/UDP as a valid transport. | 6463 o Inclusion of the Server, Cache-Control Date, and Expires | 6464 headers. | 6466 o Implement the DESCRIBE method. | 6468 o Generate SDP session descriptions as defined in Appendix C | 6470 There may be RTSP applications different from those 6471 initially envisioned by the contributors to the RTSP 6472 specification for which the requirements above do not make 6473 sense. Therefore, the recommendations above serve only as 6474 guidelines instead of strict requirements. 6476 D.2.1 Basic Playback 6478 To support on-demand playback of media streams, the server MUST 6479 additionally be able to do the following: 6481 o Recognize the Range header, and return an error if seeking is 6482 not supported. 6484 o Implement the PAUSE method. 6486 In addition, in order to support commonly-accepted user interface 6487 features, the following are highly recommended for on-demand media 6488 servers: 6490 o Include and parse the Range header, with NPT units. 6491 Implementation of SMPTE units is recommended. 6493 o Include the length of the media presentation in the media 6494 initialization information. 6496 o Include mappings from data-specific timestamps to NPT. When 6497 RTP is used, the rtptime portion of the RTP-Info field may be 6498 used to map RTP timestamps to NPT. 6500 Client implementations may use the presence of length 6501 information to determine if the clip is seekable, and 6502 visably disable seeking features for clips for which the 6503 length information is unavailable. A common use of the 6504 presentation length is to implement a "slider bar" which 6505 serves as both a progress indicator and a timeline 6506 positioning tool. 6508 Mappings from RTP timestamps to NPT are necessary to ensure correct 6509 positioning of the slider bar. 6511 D.2.2 Authentication-enabled 6513 In order to correctly handle client authentication, the server MUST 6514 additionally be able to do the following: 6516 o Generate the 401 (Unauthorized) status code when 6517 authentication is required for the resource. 6519 o Parse and include the WWW-Authenticate header 6521 o Implement Basic Authentication and Digest Authentication 6523 E Open Issues 6525 1. The proxy indications in the two header tables in chapter | 6526 14 needs review. | 6528 2. Should the Allow header be possible to use optional in | 6529 request or responses besides the now specified 405 error | 6530 code? | 6532 3. What text should be written on use of authorization in this | 6533 spec? | 6535 4. How does entity tags relate to the If-Match header? The | 6536 usage in SDP must also be clarified related to syntax, etc. | 6538 5. The minimal implementation must be looked over to see if it | 6539 complies with the specification. All must and should shall | 6540 be included in the minimal. Feature-tags for these needs to | 6541 be defined. Further feature-tags needs to be discussed. | 6543 6. The list specifying which status codes are allowed on which | 6544 request methods seem to be in error and need review. | 6546 7. The capability negotiation statement in section 1.5 does | 6547 not declare something that RTSP really supports fully. | 6549 8. Should we define a 463 status code that informs the client | 6550 that the tried media stream destination was not allowed? | 6552 9. There is need for clearer rule in regards to Transport | 6553 parameters changes in mid session. | 6555 10. Can fragment be included in a request URL? Or should it as | 6556 for HTTP only be handled on the User-Agent side? | 6558 11. Write the use case descriptions. | 6560 F Changes 6562 Compared to RFC 2326, the following issues has been addressed: | 6564 o The Transport header has been changed in the following way: | 6566 - The ABNF has been changed to define that extensions are | 6567 possible, and that unknown extension parameters shall be | 6568 ignored. | 6570 - To prevent backwards compatibility issues, any extension or | 6571 new parameter requires the usage of a feature tag combined | 6572 with the Require header. | 6574 - Syntax unclarities with the Mode parameter has been | 6575 resolved. | 6577 - Syntax error with ";" for multicast and unicast has been | 6578 resolved. | 6580 - Two new addressing parameters has been defined, src_addr and | 6581 dest_addr. These allow one to specify more than one complete | 6582 address and port tuple if needed. | 6584 - Support for IPv6 explicit addresses in all address fields | 6585 has been included. | 6587 - To handle URI definitions that contain ";" or "," a quoted | 6588 URL format has been introduced. | 6590 - Defined IANA registries for the transport headers | 6591 parameters, transport-protocol, profile, lower-transport, | 6592 and mode. | 6594 - The transport headers interleave parameter's text was made | 6595 more strict and use formal requirements levels. However no | 6596 change on how it is used was made. | 6598 - It has been clarified that the client can't request of the | 6599 server to use a certain RTP SSRC, using a request with the | 6600 transport parameter SSRC. | 6602 - Syntax defintion for SSRC has been clarified to require 8*8 | 6603 HEX. | 6605 - Updated the text on the transport headers "destination" and | 6606 "dest_addr" parameters regarding what security precautions | 6607 the server shall perform. | 6609 - The embedded (interleaved) binary data and its transport | 6610 parameter was clarified to being symmetric and that it is | 6611 the server that sets the channel numbers. | 6613 o The Range formats has been changed in the following way: | 6615 - The NPT format has been given a initial NPT identifier that | 6616 should be used, if missing NPT is assumed. | 6618 - All formats now support initial open ended formats of type | 6619 "npt=-10". | 6621 o RTSP message handling has been changed in the following way: | 6623 - It has been clarified that a 4xx message due to missing CSeq | 6624 header shall be returned without a CSeq header. | 6626 - Rules for how to handle timing out RTSP messages has been | 6627 added. | 6629 o The HTTP references has been updated to RFC 2616 and RFC 2617. | 6630 This has required that public, and content-base header are now | 6631 defined in the RTSP specification. Known effects on RTSP due | 6632 to HTTP clarifications: | 6634 - Content-Encoding header can include encoding of type | 6635 "identity". | 6637 o The state machine chapter has completely been rewritten. It | 6638 includes now more details and are also more clear about the | 6639 model used. | 6641 o A IANA section has been included with contains a number of | 6642 registries and their rules. This will allow us to use IANA to | 6643 keep track of all RTSP extensions. | 6645 o Than transport of RTSP messages has seen the following | 6646 changes: | 6648 - The use of UDP has been deprecated due to missing interest | 6649 and to broken specification. | 6651 - The rules for how TCP connections shall be handled has been | 6652 clarified. Now it is made clear that servers should not | 6653 close the TCP connection unless they have been unused for | 6654 significant time. | 6656 - Strong recommendations why server and clients should use | 6657 persistent connections has also been added. | 6659 - There is now a requirement to handle non-persistent | 6660 connections as this provides great fault tolerance. | 6662 - Added wording on the usage of Connection:Close for RTSP. | 6664 o The following header related changes has been made: | 6666 - Accept-Ranges response header is added. This header | 6667 clarifies which range formats that can be used for a | 6668 resource. | 6670 - Clarified that Range header allows multiple ranges to allow | 6671 for creating editing list. | 6673 - Fixed the missing definitions for the Cache-Control header. | 6674 Also added to the syntax definition the missing delta- | 6675 seconds for max-stale and min-fresh parameters. | 6677 - Put requirement on CSeq header that the value is increased | 6678 by one for each new RTSP request. A Recommendation to start | 6679 at 1 has also been added. | 6681 - Added requirement that the Date header must be used for all | 6682 messages with entity. Also the Server should always include | 6683 it. | 6685 - Removed possibility to use Range header combined with Scale | 6686 header to indicate when it shall be activated, due to that | 6687 it can't work as defined. Also added rule that lack of scale | 6688 header in response indicate lack of support. Feature-tags | 6689 for scaled playback defined. | 6691 - The Speed header must now be responded to indicate support | 6692 and the actual speed going to be used. A feature-tag is | 6693 defined. Notes on congestion control was also added. | 6695 - The Supported header was borrowed from SIP to help with the | 6696 feature negotiation in RTSP. | 6698 - Clarified that the Timestamp header can be used to resolve | 6699 retransmission ambiguities. | 6701 - The Session header text has been expanded with a explanation | 6702 on keep alive and which methods to use. | 6704 - It has been clarified how the Range header formats shall be | 6705 used to indicate pause points. | 6707 - Clarified that RTP-Info URLs that are relative, uses the | 6708 request URL as base URL. Also clarified that the URL that | 6709 must be used is the SETUP. | 6711 - Added text that requires the Range to always be present in | 6712 PLAY responses. Clarified what should be sent in case of | 6713 live streams. | 6715 - The quoted URL format may also be used with the RTP-Info | 6716 header. Backwards compatibility issues exist with such | 6717 usage, thus it can only be used for implementations | 6718 following this specification. | 6720 - The Headers table has been updated using a structured | 6721 borrowed from SIP. This table carries much more information | 6722 and should provide a good overview of the available headers. | 6724 - It has been is clarified that any message with a message | 6725 body is required to have a Content-Length header. This was | 6726 the case in RFC 2326 but could be misinterpreted. | 6728 o The minimal implementation specification has been changed: | 6730 - Added Headers Timestamp, Via, Unsupported as required for a | 6731 minimal server implementation. | 6733 - Added headers Cache-Control, Expires and Date as recommended | 6734 headers to support by server implementations. | 6736 o The Protocol Syntax has been changed in the following way: | 6738 - All BNF definitions are updated according to the rules | 6739 defined in RFC 2234 [5] and has been gathered in a separate | 6740 chapter 17. | 6742 - The BNF for the User-Agent and Server headers has been | 6743 corrected so now only the description is in the HTTP | 6744 specification. | 6746 - The definition in the introduction of the RTSP session has | 6747 been changed. | 6749 - The protocol has been made fully IPv6 capable. Certain of | 6750 the functionality, like using explicit IPv6 addresses in | 6751 fields requires that the protocol support this updated | 6752 specification. | 6754 - Added a fragment part to the RTSP URL. This seem to be | 6755 indicated by the note below the definition however it was | 6756 not part of the BNF. | 6758 o The Status codes has been changed in the following way: | 6760 - The use of status code 303 "See Other" has been decapitated | 6761 as it does not make sense to use in RTSP. | 6763 - Added status code 350, 351 and updated usage of the other | 6764 redirect status codes, see chapter 13.3. | 6766 - When sending response 451 and 458 the response body should | 6767 contain the offending parameters. | 6769 - Clarification on when a 3rr redirect status code can be | 6770 received has been added. This includes receiving 3rr as a | 6771 result of request within a established session. This | 6772 provides clarification to a previous unspecified behavior. | 6774 - Removed the 250 (Low On Storage Space) status code as it | 6775 only is relevant to recording which is deprecated. | 6777 o The following functionality has been deprecated from the | 6778 protocol: | 6780 - The use of Queued Play. | 6782 - The use of PLAY method for keep-alive in play state. | 6784 - The RECORD and ANNOUNCE methods and all related | 6785 functionality. Some of the syntax has been removed. | 6787 - The possibility to use timed execution of methods with the | 6788 time parameter in the Range header. | 6790 - The description on how rtspu and rtsps works is not part of | 6791 the core specification and will require external | 6792 description. Only that they exist is defined here. | 6794 o Text specifying the special behavior of PLAY for live content. | 6796 o The following changes has been made in relation to methods: | 6798 - The OPTIONS method has been clarified on how to use the | 6799 Public and Allow headers. | 6801 - The RECORD and ANNOUNCE methods are removed as they are | 6802 lacking implementation and not considered necessary in the | 6803 core specification. Any work on these methods should be done | 6804 as a extension document to RTSP. | 6806 - Added text clarifying the usage of SET_PARAMETER for keep- | 6807 alive and usage without any body. | 6809 - Added a backwards compatibility resolution for how to handle | 6810 the new state machine without automatic state transition, | 6811 for example for returning to ready when finished playing. | 6813 o Wrote a new chapter about how to setup different media | 6814 transport alternatives and their profiles, and lower layer | 6815 protocols. This resulted that the appendix on RTP interaction | 6816 was moved there instead in the part describing RTP. The | 6817 chapter also includes guidelines what to think of when writing | 6818 usage guidelines for new protocols and profiles. | 6820 o Added a new chapter describing the available mechanisms to | 6821 determine if functionality is supported, called "Capability | 6822 Handling". Renamed option-tags to feature-tags. | 6824 o Added a contributors chapter with people who has contribute | 6825 actual text to the specification. | 6827 o Added a chapter Use Cases that describes the major use cases | 6828 for RTSP. | 6830 o Clarified the usage of "a=range" and how to indicate live | 6831 content that are not seekable with this header. | 6833 Note that this list does not reflect minor changes in wording or | 6834 correction of typographical errors. | 6836 A word-by-word diff from RFC 2326 can be found at http://rtsp.org/ 6838 G Author Addresses 6840 Henning Schulzrinne 6841 Dept. of Computer Science 6842 Columbia University 6843 1214 Amsterdam Avenue 6844 New York, NY 10027 6845 USA 6846 electronic mail: schulzrinne@cs.columbia.edu 6848 Anup Rao 6849 Cisco 6850 USA 6851 electronic mail: anrao@cisco.com 6853 Robert Lanphier 6854 RealNetworks 6855 P.O. Box 91123 6856 Seattle, WA 98111-9223 6857 USA 6858 electronic mail: robla@real.com 6860 Magnus Westerlund 6861 Ericsson AB, EAB/TVA/A 6862 Torshamsgatan 23 6863 SE-164 80 STOCKHOLM 6864 SWEDEN 6865 electronic mail: magnus.westerlund@ericsson.com 6866 Aravind Narasimhan 6867 Sun Microsystems, Inc. 6868 101 Park Avenue, 3rd & 4th Floor 6869 New York, NY 6870 USA 6871 electronic mail: aravind.narasimhan@sun.com 6873 H Contributors 6875 The following people has made written contribution included in the 6876 specification: 6878 o Tom Marshall has contributed with text about the usage of 3rr 6879 status codes. 6881 o Thomas Zheng has contributed with text regarding the usage of 6882 the Range in PLAY responses. 6884 o Sean Sheedy has contributed with text regarding timing out 6885 RTSP messages. 6887 I Acknowledgements 6889 This draft is based on the functionality of the original RTSP draft 6890 submitted in October 1996. It also borrows format and descriptions 6891 from HTTP/1.1. 6893 This document has benefited greatly from the comments of all those 6894 participating in the MMUSIC-WG. In addition to those already 6895 mentioned, the following individuals have contributed to this 6896 specification: 6898 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 6899 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 6900 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 6901 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 6902 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 6903 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 6904 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 6905 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 6906 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 6907 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 6908 Chesire, David Walker, and Geetha Srikantan. 6910 J Normative References 6912 [1] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 6913 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 6915 1998. 6917 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 6918 RFC 2327, Internet Engineering Task Force, Apr. 1998. 6920 [3] S. C. H. Schulzrinne, "RTP profile for audio and video 6921 conferences with minimal control," RFC 3551, Internet Engineering 6922 Task Force, July 2003. 6924 [4] e. a. R. Fielding, "Hypertext transfer protocol -- http/1.1," RFC 6925 2616, Internet Engineering Task Force, June 1999. 6927 [5] D. Crocker and P. Overell, "Augmented BNF for syntax 6928 specifications: ABNF," RFC 2234, Internet Engineering Task Force, 6929 Nov. 1997. 6931 [6] S. Bradner, "Key words for use in RFCs to indicate requirement 6932 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 6934 [7] J. F. et. al., "Http authentication: Basic and digest access 6935 authentication," RFC 2617, Internet Engineering Task Force, June 6936 1999. 6938 [8] J. Postel, "User datagram protocol," RFC STD 6, 768, Internet 6939 Engineering Task Force, Aug. 1980. 6941 [9] J. Postel, "Transmission control protocol," RFC STD 7, 793, 6942 Internet Engineering Task Force, Sept. 1981. 6944 [10] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, 6945 Internet Engineering Task Force, Apr. 1996. 6947 [11] L. M. R. Hinden, B. Carpenter, "Format for literal ipv6 6948 addresses in url's," RFC 2732, Internet Engineering Task Force, Dec. 6949 1999. 6951 [12] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 6952 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 6953 Task Force, Aug. 1998. 6955 [13] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 6956 2279, Internet Engineering Task Force, Jan. 1998. 6958 [14] B. Braden, "Requirements for internet hosts - application and 6959 support," RFC STD 3, 1123, Internet Engineering Task Force, Oct. 6960 1989. 6962 [15] e. a. H. Schulzrinne, "RTP: a transport protocol for real-time 6963 applications," RFC 3550, Internet Engineering Task Force, July 2003. 6965 [16] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners- 6966 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 6967 Engineering Task Force, Jan. 1997. 6969 [17] H. Alvestrand and T. Narten, "Guidelines for writing an IANA 6970 considerations section in RFCs," RFC 2434, Internet Engineering Task 6971 Force, Oct. 1998. 6973 [18] A. B. R. S. Olson, G. Camarill, "Support for ipv6 in session 6974 description protocol (sdp)," RFC 3266, Internet Engineering Task 6975 Force, June 2002. 6977 [19] S. D. R. Hinden, "Internet protocol version 6 (ipv6) addressing 6978 architecture," RFC 3513, Internet Engineering Task Force, Apr. 2003. 6980 K Informative References 6982 [20] T. Z. M. Westerlund, "How to make real-time streaming protocol 6983 (rtsp) traverse network address translators (nat) and interact with 6984 firewalls.," internet draft, Internet Engineering Task Force, Feb. 6985 2004. Work in progress. 6987 [21] A. Narasimhan, "Mute and unmute extension to rtsp," internet 6988 draft, Internet Engineering Task Force, Feb. 2002. Work in progress. 6990 [22] P. Gentric, "Rtsp stream switching," internet draft, Internet 6991 Engineering Task Force, Jan. 2004. Work in progress. 6993 [23] A. L. G. Srikantan, J. Murata, "Streaming relays," internet 6994 draft, Internet Engineering Task Force, Dec. 2003. Work in progress. 6996 [24] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 6997 "Internationalization of the hypertext markup language," RFC 2070, 6998 Internet Engineering Task Force, Jan. 1997. 7000 [25] ISO/IEC, "Information technology -- generic coding of moving 7001 pictures and associated audio informaiton -- part 6: extension for 7002 digital storage media and control," Draft International Standard ISO 7003 13818-6, International Organization for Standardization ISO/IEC 7004 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 7006 [26] C. A. T. Dierks, "The tls protocol, version 1.0," RFC 2246, 7007 Internet Engineering Task Force, Jan. 1999. 7009 [27] B. Hinden and C. Partridge, "Version 2 of the reliable data 7010 protocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr. 7012 1990. 7014 [28] H. Schulzrinne, "A comprehensive multimedia control architecture 7015 for the Internet," in Proc. International Workshop on Network and 7016 Operating System Support for Digital Audio and Video (NOSSDAV), (St. 7017 Louis, Missouri), May 1997. 7019 [29] International Telecommunication Union, "Visual telephone systems 7020 and equipment for local area networks which provide a non-guaranteed 7021 quality of service," Recommendation H.323, Telecommunication 7022 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 7024 [30] P. McMahon, "GSS-API authentication method for SOCKS version 5," 7025 RFC 1961, Internet Engineering Task Force, June 1996. 7027 [31] J. Miller, P. Resnick, and D. Singer, "Rating services and 7028 rating systems (and their machine readable descriptions)," 7029 Recommendation REC-PICS-services-961031, W3C (World Wide Web 7030 Consortium), Boston, Massachusetts, Oct. 1996. 7032 [32] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 7033 distribution label syntax and communication protocols," 7034 Recommendation REC-PICS-labels-961031, W3C (World Wide Web 7035 Consortium), Boston, Massachusetts, Oct. 1996. 7037 [33] B. Braden, "T/TCP -- TCP extensions for transactions functional 7038 specification," RFC 1644, Internet Engineering Task Force, July 1994. 7040 [34] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 7041 Reading, Massachusetts: Addison-Wesley, 1994. 7043 [35] Third Generation Partnership Project (3GPP), "Transparent end- 7044 to-end packet-switched streaming service (pss); protocols and 7045 codecs," Technical Specification 26.234, Third Generation Partnership 7046 Project (3GPP), Dec. 2002. 7048 [36] D. Yon, "Connection-oriented media transport in sdp," internet 7049 draft, Internet Engineering Task Force, Mar. 2003. Work in progress. 7051 [37] J. Lazzaro, "Framing rtp and rtcp packets over connection- 7052 oriented transport," internet draft, Internet Engineering Task Force, 7053 Oct. 2003. Work in progress. 7055 [38] e. a. G. Camarillo, "Grouping of media lines in the session 7056 description protocol (sdp)," RFC 3388, Internet Engineering Task 7057 Force, Dec. 2002. 7059 IPR Notice 7061 The IETF takes no position regarding the validity or scope of any 7062 intellectual property or other rights that might be claimed to 7063 pertain to the implementation or use of the technology described in 7064 this document or the extent to which any license under such rights 7065 might or might not be available; neither does it represent that it 7066 has made any effort to identify any such rights. Information on the 7067 IETF's procedures with respect to rights in standards-track and 7068 standards-related documentation can be found in BCP-11. Copies of 7069 claims of rights made available for publication and any assurances of 7070 licenses to be made available, or the result of an attempt made to 7071 obtain a general license or permission for the use of such 7072 proprietary rights by implementors or users of this specification can 7073 be obtained from the IETF Secretariat. 7075 The IETF invites any interested party to bring to its attention any 7076 copyrights, patents or patent applications, or other proprietary 7077 rights which may cover technology that may be required to practice 7078 this standard. Please address the information to the IETF Executive 7079 Director. 7081 Full Copyright Statement 7083 Copyright (C) The Internet Society (2004). All Rights Reserved. 7085 This document and translations of it may be copied and furnished to 7086 others, and derivative works that comment on or otherwise explain it 7087 or assist in its implmentation may be prepared, copied, published and 7088 distributed, in whole or in part, without restriction of any kind, 7089 provided that the above copyright notice and this paragraph are 7090 included on all such copies and derivative works. However, this 7091 document itself may not be modified in any way, such as by removing 7092 the copyright notice or references to the Internet Society or other 7093 Internet organizations, except as needed for the purpose of 7094 developing Internet standards in which case the procedures for 7095 copyrights defined in the Internet Standards process must be 7096 followed, or as required to translate it into languages other than 7097 English. 7099 The limited permissions granted above are perpetual and will not be 7100 revoked by the Internet Society or its successors or assigns. 7102 This document and the information contained herein is provided on an 7103 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 7104 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 7105 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 7106 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 7107 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.