idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 8022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 7995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 8002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 8008. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 36) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1605 has weird spacing: '...equired all...' == Line 1606 has weird spacing: '...ccepted all...' == Line 1902 has weird spacing: '...mmended rec...' == Line 1905 has weird spacing: '...mmended rec...' == Line 1906 has weird spacing: '...mmended opt...' == (23 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found '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 needs to be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occur the appropriate response code MUST be sent. If the response code is a 4xx the session state is unchanged. A response code of 3rr will result in that the session is ended and its state is changed to Init. A response code of 304 results in no state change. However there exist restrictions to when a 3xx response may be used. A 5xx response SHALL not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error SHALL result the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client knows that the session has ended. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 7821 looks like a reference -- Missing reference section? '23' on line 7902 looks like a reference -- Missing reference section? '24' on line 7907 looks like a reference -- Missing reference section? '25' on line 7910 looks like a reference -- Missing reference section? '26' on line 7913 looks like a reference -- Missing reference section? '2' on line 7825 looks like a reference -- Missing reference section? '3' on line 7828 looks like a reference -- Missing reference section? '4' on line 7832 looks like a reference -- Missing reference section? '27' on line 7916 looks like a reference -- Missing reference section? '5' on line 7836 looks like a reference -- Missing reference section? '6' on line 7839 looks like a reference -- Missing reference section? '13' on line 7863 looks like a reference -- Missing reference section? '7' on line 7842 looks like a reference -- Missing reference section? '8' on line 7845 looks like a reference -- Missing reference section? '9' on line 7850 looks like a reference -- Missing reference section? '10' on line 7853 looks like a reference -- Missing reference section? '28' on line 7920 looks like a reference -- Missing reference section? '29' on line 7925 looks like a reference -- Missing reference section? '30' on line 7930 looks like a reference -- Missing reference section? '31' on line 7933 looks like a reference -- Missing reference section? '32' on line 7938 looks like a reference -- Missing reference section? '17' on line 7877 looks like a reference -- Missing reference section? '11' on line 7856 looks like a reference -- Missing reference section? '12' on line 7859 looks like a reference -- Missing reference section? '33' on line 7943 looks like a reference -- Missing reference section? '34' on line 7947 looks like a reference -- Missing reference section? '35' on line 7953 looks like a reference -- Missing reference section? '14' on line 7867 looks like a reference -- Missing reference section? 'H6' on line 1421 looks like a reference -- Missing reference section? 'H10' on line 2880 looks like a reference -- Missing reference section? 'TBW' on line 2924 looks like a reference -- Missing reference section? '15' on line 7870 looks like a reference -- Missing reference section? '16' on line 7873 looks like a reference -- Missing reference section? '36' on line 7958 looks like a reference -- Missing reference section? 'H15' on line 5737 looks like a reference -- Missing reference section? '18' on line 7881 looks like a reference -- Missing reference section? '19' on line 7884 looks like a reference -- Missing reference section? '20' on line 7888 looks like a reference -- Missing reference section? '37' on line 7961 looks like a reference -- Missing reference section? '38' on line 7966 looks like a reference -- Missing reference section? '39' on line 7969 looks like a reference -- Missing reference section? '40' on line 7973 looks like a reference -- Missing reference section? '21' on line 7892 looks like a reference -- Missing reference section? '22' on line 7896 looks like a reference -- Missing reference section? '41' on line 7977 looks like a reference -- Missing reference section? '42' on line 7980 looks like a reference -- Missing reference section? '43' on line 7983 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 17 warnings (==), 53 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft H. Schulzrinne 4 draft-ietf-mmusic-rfc2326bis-08.txt Columbia U. 5 October 25, 2004 A. Rao 6 Expires: April, 2005 Cisco 7 R. Lanphier 8 RealNetworks 9 M. Westerlund 10 Ericsson 11 A. Narasimhan 12 Princeton 14 Real Time Streaming Protocol (RTSP) 16 STATUS OF THIS MEMO 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes? 21 aware will be disclosed, in accordance with( Section 6 of) RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This memorandum is a revision of RFC 2326, which is currently a 42 Proposed Standard. 44 The Real Time Streaming Protocol, or RTSP, is an application-level 45 protocol for control over the delivery of data with real-time 46 properties. RTSP provides an extensible framework to enable 47 controlled, on-demand delivery of real-time data, such as audio and 48 video. Sources of data can include both live data feeds and stored 49 clips. This protocol is intended to control multiple data delivery 50 sessions, provide a means for choosing delivery channels such as UDP, 51 multicast UDP and TCP, and provide a means for choosing delivery 52 mechanisms based upon RTP (RFC 3550). 54 Table of Contents 56 1 Introduction ........................................ 9 57 1.1 RTSP Specification Update ........................... 9 58 1.2 Purpose ............................................. 10 59 1.3 Notational Conventions .............................. 11 60 1.4 Terminology ......................................... 12 61 1.5 Protocol Properties ................................. 15 62 1.6 Extending RTSP ...................................... 17 63 1.7 Overall Operation ................................... 18 64 1.8 RTSP States ......................................... 19 65 1.9 Relationship with Other Protocols ................... 19 66 2 RTSP Use Cases ...................................... 20 67 2.1 On-demand Playback of Stored Content ................ 20 68 2.2 Unicast distribution of Live Content ................ 22 69 2.3 On-demand Playback using Multicast .................. 22 70 2.4 Inviting a RTSP server into a conference ............ 22 71 2.5 Live Content using Multicast ........................ 23 72 3 Protocol Parameters ................................. 24 73 3.1 RTSP Version ........................................ 24 74 3.2 RTSP URI ............................................ 24 75 3.3 Session Identifiers ................................. 26 76 3.4 SMPTE Relative Timestamps ........................... 26 77 3.5 Normal Play Time .................................... 27 78 3.6 Absolute Time ....................................... 27 79 3.7 Feature-tags ........................................ 28 80 3.8 Entity Tags ......................................... 28 81 4 RTSP Message ........................................ 28 82 4.1 Message Types ....................................... 29 83 4.2 Message Headers ..................................... 29 84 4.3 Message Body ........................................ 29 85 4.4 Message Length ...................................... 29 86 5 General Header Fields ............................... 30 87 6 Request ............................................. 30 88 6.1 Request Line ........................................ 30 89 6.2 Request Header Fields ............................... 32 90 7 Response ............................................ 32 91 7.1 Status-Line ......................................... 33 92 7.1.1 Status Code and Reason Phrase ....................... 33 93 7.1.2 Response Header Fields .............................. 34 94 8 Entity .............................................. 34 95 8.1 Entity Header Fields ................................ 35 96 8.2 Entity Body ......................................... 35 97 9 Connections ......................................... 35 98 9.1 Pipelining .......................................... 37 99 9.2 Reliability and Acknowledgements .................... 37 100 9.3 The usage of connections ............................ 38 101 9.4 Timing Out RTSP messages ............................ 39 102 9.5 Use of IPv6 ......................................... 40 103 10 Capability Handling ................................. 40 104 11 Method Definitions .................................. 42 105 11.1 OPTIONS ............................................. 43 106 11.2 DESCRIBE ............................................ 44 107 11.3 SETUP ............................................... 46 108 11.4 PLAY ................................................ 49 109 11.5 PAUSE ............................................... 53 110 11.6 TEARDOWN ............................................ 57 111 11.7 GET_PARAMETER ....................................... 57 112 11.8 SET_PARAMETER ....................................... 58 113 11.9 REDIRECT ............................................ 60 114 11.10 PING ................................................ 62 115 12 Embedded (Interleaved) Binary Data .................. 63 116 13 Status Code Definitions ............................. 64 117 13.1 Success 1xx ......................................... 64 118 13.1.1 100 Continue ........................................ 64 119 13.2 Success 2xx ......................................... 64 120 13.3 Redirection 3xx ..................................... 65 121 13.3.1 300 Multiple Choices ................................ 65 122 13.3.2 301 Moved Permanently ............................... 65 123 13.3.3 302 Found ........................................... 65 124 13.3.4 303 See Other ....................................... 66 125 13.3.5 304 Not Modified .................................... 66 126 13.3.6 305 Use Proxy ....................................... 66 127 13.4 Client Error 4xx .................................... 66 128 13.4.1 400 Bad Request ..................................... 66 129 13.4.2 405 Method Not Allowed .............................. 66 130 13.4.3 451 Parameter Not Understood ........................ 67 131 13.4.4 452 reserved ........................................ 67 132 13.4.5 453 Not Enough Bandwidth ............................ 67 133 13.4.6 454 Session Not Found ............................... 67 134 13.4.7 455 Method Not Valid in This State .................. 67 135 13.4.8 456 Header Field Not Valid for Resource ............. 67 136 13.4.9 457 Invalid Range ................................... 67 137 13.4.10 458 Parameter Is Read-Only .......................... 68 138 13.4.11 459 Aggregate Operation Not Allowed ................. 68 139 13.4.12 460 Only Aggregate Operation Allowed ................ 68 140 13.4.13 461 Unsupported Transport ........................... 68 141 13.4.14 462 Destination Unreachable ......................... 68 142 13.4.15 470 Connection Authorization Required ............... 68 143 13.4.16 471 Connection Credentials not accepted ............. 68 144 13.5 Server Error 5xx .................................... 68 145 13.5.1 551 Option not supported ............................ 68 146 14 Header Field Definitions ............................ 69 147 14.1 Accept .............................................. 71 148 14.2 Accept-Credentials .................................. 71 149 14.3 Accept-Encoding ..................................... 75 150 14.4 Accept-Language ..................................... 75 151 14.5 Accept-Ranges ....................................... 75 152 14.6 Allow ............................................... 76 153 14.7 Authorization ....................................... 76 154 14.8 Bandwidth ........................................... 76 155 14.9 Blocksize ........................................... 77 156 14.10 Cache-Control ....................................... 77 157 14.11 Connection .......................................... 79 158 14.12 Connection-Credentials .............................. 79 159 14.13 Content-Base ........................................ 80 160 14.14 Content-Encoding .................................... 80 161 14.15 Content-Language .................................... 80 162 14.16 Content-Length ...................................... 80 163 14.17 Content-Location .................................... 80 164 14.18 Content-Type ........................................ 81 165 14.19 CSeq ................................................ 81 166 14.20 Date ................................................ 81 167 14.21 ETag ................................................ 81 168 14.22 Expires ............................................. 82 169 14.23 From ................................................ 83 170 14.24 Host ................................................ 83 171 14.25 If-Match ............................................ 83 172 14.26 If-Modified-Since ................................... 83 173 14.27 If-None-Match ....................................... 83 174 14.28 Last-Modified ....................................... 84 175 14.29 Location ............................................ 84 176 14.30 Proxy-Authenticate .................................. 84 177 14.31 Proxy-Require ....................................... 84 178 14.32 Proxy-Supported ..................................... 84 179 14.33 Public .............................................. 85 180 14.34 Range ............................................... 86 181 14.35 Referer ............................................. 88 182 14.36 Retry-After ......................................... 88 183 14.37 Require ............................................. 88 184 14.38 RTP-Info ............................................ 89 185 14.39 Scale ............................................... 91 186 14.40 Speed ............................................... 92 187 14.41 Server .............................................. 92 188 14.42 Session ............................................. 92 189 14.43 Supported ........................................... 95 190 14.44 Timestamp ........................................... 95 191 14.45 Transport ........................................... 95 192 14.46 Unsupported ......................................... 102 193 14.47 User-Agent .......................................... 102 194 14.48 Vary ................................................ 102 195 14.49 Via ................................................. 102 196 14.50 WWW-Authenticate .................................... 102 197 15 Caching ............................................. 102 198 16 Examples ............................................ 103 199 16.1 Media on Demand (Unicast) ........................... 103 200 16.2 Streaming of a Container file ....................... 106 201 16.3 Single Stream Container Files ....................... 109 202 16.4 Live Media Presentation Using Multicast ............. 111 203 16.5 Capability Negotiation .............................. 112 204 17 Security Framework .................................. 113 205 17.1 RTSP and HTTP Authentication ........................ 114 206 17.2 RTSP over TLS ....................................... 114 207 17.3 Security and Proxies ................................ 115 208 17.3.1 Accept-Credentials .................................. 116 209 17.3.2 User approved TLS procedure ......................... 117 210 18 Syntax .............................................. 118 211 18.1 Base Syntax ......................................... 118 212 18.2 RTSP Protocol Definition ............................ 119 213 18.2.1 Generic Protocol elements ........................... 119 214 18.2.2 Message Syntax ...................................... 120 215 18.2.3 Header Syntax ....................................... 124 216 19 Security Considerations ............................. 127 217 20 IANA Considerations ................................. 129 218 20.1 Feature-tags ........................................ 130 219 20.1.1 Description ......................................... 130 220 20.1.2 Registering New Feature-tags with IANA .............. 130 221 20.1.3 Registered entries .................................. 130 222 20.2 RTSP Methods ........................................ 130 223 20.2.1 Description ......................................... 130 224 20.2.2 Registering New Methods with IANA ................... 131 225 20.2.3 Registered Entries .................................. 131 226 20.3 RTSP Status Codes ................................... 131 227 20.3.1 Description ......................................... 131 228 20.3.2 Registering New Status Codes with IANA .............. 131 229 20.3.3 Registered Entries .................................. 132 230 20.4 RTSP Headers ........................................ 132 231 20.4.1 Description ......................................... 132 232 20.4.2 Registering New Headers with IANA ................... 132 233 20.4.3 Registered entries .................................. 132 234 20.5 Transport Header registries ......................... 133 235 20.5.1 Transport Protocols ................................. 133 236 20.5.2 Profile ............................................. 133 237 20.5.3 Lower Transport ..................................... 134 238 20.5.4 Transport modes ..................................... 134 239 20.6 Cache Directive Extensions .......................... 135 240 20.7 Accept-Credentials policies ......................... 135 241 20.8 URI Schemes ......................................... 136 242 20.9 SDP attributes ...................................... 136 243 A RTSP Protocol State Machine ......................... 137 244 A.1 States .............................................. 137 245 A.2 State variables ..................................... 138 246 A.3 Abbreviations ....................................... 138 247 A.4 State Tables ........................................ 138 248 B Media Transport Alternatives ........................ 141 249 B.1 RTP ................................................. 142 250 B.1.1 AVP ................................................. 142 251 B.1.2 AVP/UDP ............................................. 142 252 B.1.3 AVP/TCP ............................................. 144 253 B.1.4 Handling NPT Jumps in the RTP Media Layer ........... 144 254 B.1.5 Handling RTP Timestamps after PAUSE ................. 147 255 B.1.6 RTSP / RTP Integration .............................. 149 256 B.1.7 Scaling with RTP .................................... 149 257 B.1.8 Maintaining NPT synchronization with RTP 258 timestamps ..................................................... 150 259 B.1.9 Continuous Audio .................................... 150 260 B.1.10 Multiple Sources in an RTP Session .................. 150 261 B.1.11 Usage of SSRCs and the RTCP BYE Message During an 262 RTSP Session ................................................... 150 263 B.2 Future Additions .................................... 151 264 C Use of SDP for RTSP Session Descriptions ............ 151 265 C.1 Definitions ......................................... 151 266 C.1.1 Control URI ......................................... 152 267 C.1.2 Media Streams ....................................... 153 268 C.1.3 Payload Type(s) ..................................... 153 269 C.1.4 Format-Specific Parameters .......................... 154 270 C.1.5 Range of Presentation ............................... 154 271 C.1.6 Time of Availability ................................ 154 272 C.1.7 Connection Information .............................. 155 273 C.1.8 Entity Tag .......................................... 155 274 C.2 Aggregate Control Not Available ..................... 156 275 C.3 Aggregate Control Available ......................... 156 276 C.4 RTSP external SDP delivery .......................... 157 277 D Minimal RTSP implementation ......................... 158 278 D.1 Client .............................................. 158 279 D.1.1 Basic Playback ...................................... 159 280 D.1.2 Authentication-enabled .............................. 159 281 D.2 Server .............................................. 159 282 D.2.1 Basic Playback ...................................... 160 283 D.2.2 Authentication-enabled .............................. 161 284 E Requirements for Unreliable Transport of RTSP 285 messages ....................................................... 161 286 F Backwards Compatibility Considerations .............. 162 287 F.1 Requirement on Pause before Play in Play mode ....... 162 288 F.2 Usage of persistent connections ..................... 163 289 G Open Issues ......................................... 163 290 H Changes ............................................. 164 291 H.1 Issues Addressed .................................... 164 292 H.2 Changes made to the protocol and specification ...... 165 293 I Author Addresses .................................... 170 294 J Contributors ........................................ 171 295 K Acknowledgements .................................... 171 296 L Normative References ................................ 172 297 M Informative References .............................. 173 299 1 Introduction 301 1.1 RTSP Specification Update 303 This document is a draft to an update of RTSP, a proposed standard 304 defined in RFC 2326 [1]. The goal the update is to progress RTSP to 305 draft standard status. Many flaws have been identified in RTSP since 306 its publication. While this draft tries to address these flaws, not 307 all known issues have been resolved. Appendix H catalogs the issues 308 that have already been addressed. Known open issues are listed in 309 appendix G. 311 The possibility of progressing RTSP to draft standard without 312 republishing RTSP as a proposed standard depends on the changes 313 necessary to make the protocol work. 315 A list of bugs against the specification is available at 316 "http://rtspspec.sourceforge.net". These bugs should be taken into 317 account when reading this specification. Input on the unresolved bugs 318 and other issues can be sent via e-mail to the MMUSIC WG's mailing 319 list mmusic@ietf.org and the authors. 321 Not all of the contents of RFC 2326 are part of this draft. In an 322 attempt to prevent bloat, the specification has been reduced and 323 split. The content of this draft is the core specification of the 324 protocol. It contains the general idea behind RTSP and the basic 325 functionality necessary to establish an on-demand play-back session. 326 It also contains the mechanisms for extending the protocol. Any other 327 functionality will be published as extension documents. The Working 328 group is currently working on: 330 o NAT and FW traversal mechanisms for RTSP are described in a 331 document called "How to make Real-Time Streaming Protocol 332 (RTSP) traverse Network Address Translators (NAT) and interact 333 with Firewalls." [23]. 335 There have also been discussion or proposals about the following 336 extensions to RTSP: 338 o Mute and Unmute Extension [24]. 340 o RTSP Stream Switching [25]. 342 o Live Streaming Relays [26]. 344 o Unreliable transport of RTSP messages (rtspu). 346 o The Record functionality. 348 o A text body type with suitable syntax for basic parameters to 349 be used in SET_PARAMETER, and GET_PARAMETER. Including IANA 350 registry within the defined name space. 352 o An RTSP MIB. 354 1.2 Purpose 356 The Real-Time Streaming Protocol (RTSP) establishes and controls 357 single or several time-synchronized streams of continuous media such 358 as audio and video. Put simply, RTSP acts as a "network remote 359 control" for multimedia servers. 361 There is no notion of an RTSP connection in the protocol. Instead, an 362 RTSP server maintains a session labelled by an identifier to 363 associate groups of media streams and their states. An RTSP session 364 is not tied to a transport-level connection such as a TCP connection. 365 During a session, a client may open and close many reliable transport 366 connections to the server to issue RTSP requests for that session. 368 This memorandum describes the use of RTSP over a reliable connection 369 based transport level protocol such as TCP. RTSP may be implemented 370 over an unreliable connectionless transport protocol such as UDP. 371 While nothing in RTSP precludes this, additional definition of this 372 problem area needs to be handled as an extension to the core 373 specification. 375 The mechanisms of RTSP's operation over UDP were left out 376 of this spec. because they were poorly defined in RFC 2326 377 [1] and the tradeoff in size and complexity of this spec. 378 for a small gain in a targeted problem space was not deemed 379 justifiable. 381 The set of streams to be controlled in an RTSP session is defined by 382 a presentation description. This memorandum does not define a format 383 for the presentation description. However appendix C defines how SDP 384 [2] is used for this purpose. The streams controlled by RTSP may use 385 RTP [3] for their data transport, but the operation of RTSP does not 386 depend on the transport mechanism used to carry continuous media. 387 RTSP is intentionally similar in syntax and operation to HTTP/1.1 [4] 388 so that extension mechanisms to HTTP can in most cases also be added 389 to RTSP. However, RTSP differs in a number of important aspects from 390 HTTP: 392 o RTSP introduces a number of new methods and has a different 393 protocol identifier. 395 o RTSP has the notion of a session built into the protocol. 397 o An RTSP server needs to maintain state by default in almost 398 all cases, as opposed to the stateless nature of HTTP. 400 o Both an RTSP server and client can issue requests. 402 o Data is usually carried out-of-band by a different protocol. 403 Session descriptions returned in a DESCRIBE response (see 404 Section 11.2) and interleaving of RTP with RTSP over TCP are 405 exceptions to this rule (see Section 12). 407 o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 408 8859-1, consistent with HTML internationalization efforts 409 [27]. 411 o The Request-URI always contains the absolute URI. Because of 412 backward compatibility with a historical blunder, HTTP/1.1 [4] 413 carries only the absolute path in the request and puts the 414 host name in a separate header field. 416 This makes "virtual hosting" easier, where a single 417 host with one IP address hosts several document trees. 419 The protocol supports the following operations: 421 Retrieval of media from media server: The client can either 422 request a presentation description via RTSP DESCRIBE, HTTP 423 or some other method. If the presentation is being 424 multicast, the presentation description contains the 425 multicast addresses and ports to be used for the continuous 426 media. If the presentation is to be sent only to the client 427 via unicast, the client provides the destination for 428 security reasons. 430 Invitation of a media server to a conference: A media server can 431 be "invited" to join an existing conference to play back 432 media into the presentation. This mode is useful for 433 example distributed teaching applications. Several parties 434 in the conference may take turns "pushing the remote 435 control buttons". 437 RTSP requests may be handled by proxies, tunnels and caches as in 438 HTTP/1.1 [4]. 440 1.3 Notational Conventions 441 Since many of the definitions and syntax are identical to HTTP/1.1, 442 this specification only points to the section where they are defined 443 rather than copying it. For brevity, [HX.Y] is to be taken to refer 444 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [4]). 446 All the mechanisms specified in this document are described in both 447 prose and the augmented Backus-Naur form (BNF) described in detail in 448 RFC 2234 [5]. 450 Indented and smaller-type paragraphs are used to provide informative 451 background and motivation. This is intended to give readers who were 452 not involved with the formulation of the specification an 453 understanding of why things are the way they are in RTSP. 455 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 456 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 457 document are to be interpreted as described in RFC 2119 [6]. 459 The word, "unspecified" is used to indicate functionality or features 460 that are not defined in this specification. Such functionality cannot 461 be used in a standardized manner without further definition and 462 review in an extension specification to RTSP. 464 1.4 Terminology 466 Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not 467 listed here are defined as in HTTP/1.1. 469 Aggregate control: The concept of controlling multiple streams 470 using a single timeline, generally maintained by the 471 server. A client, for example, uses aggregate control when 472 it issues a single play or pause message to simultaneously 473 control both the audio and video in a movie. 475 Aggregate control URI: The URI used in an RTSP request to refer 476 to and control an aggregated session. It normally, but not 477 always, corresponds to the presentation URI specified in 478 the session description. See Section 11.3 for more 479 information. 481 Conference: a multiparty, multimedia presentation, where "multi" 482 implies greater than or equal to one. 484 Client: The client requests media service from the media server. 486 Connection: A transport layer virtual circuit established 487 between two programs for the purpose of communication. 489 Container file: A file which may contain multiple media streams 490 which often constitutes a presentation when played 491 together. The concept of a container file is not embedded 492 in the protocol. However, RTSP servers may offer aggregate 493 control on the media streams within these files. 495 Continuous media: Data where there is a timing relationship 496 between source and sink; that is, the sink needs to 497 reproduce the timing relationship that existed at the 498 source. The most common examples of continuous media are 499 audio and motion video. Continuous media can be real-time 500 (interactive or conversational), where there is a "tight" 501 timing relationship between source and sink, or streaming 502 (playback), where the relationship is less strict. 504 Entity: The information transferred as the payload of a request 505 or response. An entity consists of meta-information in the 506 form of entity-header fields and content in the form of an 507 entity-body, as described in Section 8. 509 Feature-tag: A tag representing a certain set of functionality, 510 i.e. a feature. 512 Live: Normally used to describe a presentation or session with 513 media coming from ongoing event. This generally results in 514 that the session has a unbound or only loosely defined 515 duration, and that no seek operations are possible. 517 Media initialization: Datatype/codec specific initialization. 518 This includes such things as clock rates, color tables, 519 etc. Any transport-independent information which is 520 required by a client for playback of a media stream occurs 521 in the media initialization phase of stream setup. 523 Media parameter: Parameter specific to a media type that may be 524 changed before or during stream playback. 526 Media server: The server providing playback services for one or 527 more media streams. Different media streams within a 528 presentation may originate from different media servers. A 529 media server may reside on the same host or on a different 530 host from which the presentation is invoked. 532 Media server indirection: Redirection of a media client to a 533 different media server. 535 (Media) stream: A single media instance, e.g., an audio stream 536 or a video stream as well as a single whiteboard or shared 537 application group. When using RTP, a stream consists of all 538 RTP and RTCP packets created by a source within an RTP 539 session. 541 Message: The basic unit of RTSP communication, consisting of a 542 structured sequence of octets matching the syntax defined 543 in Section 18 and transmitted over a connection or a 544 connectionless transport. 546 Non-Aggregated Control: Control of a single media stream. Only 547 possible in RTSP sessions with a single media. 549 Participant: Member of a conference. A participant may be a 550 machine, e.g., a playback server. 552 Presentation: A set of one or more streams presented to the 553 client as a complete media feed and described by a 554 presentation description as defined below. Presentations 555 with more than one media stream is often handled in RTSP 556 under aggregate control. 558 Presentation description: A presentation description contains 559 information about one or more media streams within a 560 presentation, such as the set of encodings, network 561 addresses and information about the content. Other IETF 562 protocols such as SDP (RFC 2327 [2]) use the term "session" 563 for a presentation. The presentation description may take 564 several different formats, including but not limited to the 565 session description protocol format, SDP. 567 Response: An RTSP response. If an HTTP response is meant, that 568 is indicated explicitly. 570 Request: An RTSP request. If an HTTP request is meant, that is 571 indicated explicitly. 573 Request-URI: The URI used in a request to indicate the resource 574 on which the request is to be performed. 576 RTSP agent: Refers to either an RTSP client, an RTSP server, or 577 an RTSP Proxy. In this specification, there are many 578 capabilities that are common to these three entities such 579 as the capability to send requests or receive responses. 580 This term will be used when describing functionality that 581 is applicable to all three of these entities. 583 RTSP session: A stateful abstraction upon which the main control 584 methods of RTSP operate. An RTSP session is a server 585 entity; it is created, maintained and destroyed by the 586 server. It is established by an RTSP server upon the 587 completion of a successful SETUP request (when 200 OK 588 response is sent) and is labelled by a session identifier 589 at that time. The session exists until timed out by the 590 server or explicitly removed by a TEARDOWN request. An RTSP 591 session is a stateful entity; an RTSP server maintains an 592 explicit session state machine (see Appendix A) where most 593 state transitions are triggered by client requests. The 594 existence of a session implies the existence of state about 595 the session's media streams and their respective transport 596 mechanisms. A given session can have zero or more media 597 streams associated with it. An RTSP server uses the session 598 to aggregate control over multiple media streams. 600 Transport initialization: The negotiation of transport 601 information (e.g., port numbers, transport protocols) 602 between the client and the server. 604 URI: Universal Resource Identifier, see RFC 2396 [13]. In RTSP 605 the used URIs are as general rule in fact URI's as they 606 gives an location for the resource. Therefore although RTSP 607 URIs are a subset of URIs, they will be refered as URIs. 609 URI: Universal Resource Locator, is an URI which identifies the 610 resource through its primary access mechanism, rather than 611 identifying the resource by name or by some other 612 attribute(s) of that resource. 614 1.5 Protocol Properties 616 RTSP has the following properties: 618 Extendable: New methods and parameters can be easily added to 619 RTSP. 621 Easy to parse: RTSP can be parsed by standard HTTP or MIME 622 parsers. 624 Secure: RTSP re-uses web security mechanisms, either at the 625 transport level (TLS, RFC 2246 [7]) or within the protocol 626 itself. All HTTP authentication mechanisms such as basic 627 (RFC 2616 [4]) and digest authentication (RFC 2617 [8]) are 628 directly applicable. 630 Transport-independent: RTSP does not preclude the use of an 631 unreliable datagram protocol (UDP) (RFC 768 [9]) as it 632 would be possible to implement application-level 633 reliability. The use of a connectionless datagram protocol 634 such as UDP requires additional definition that may be 635 provided as extensions to the core RTSP specification. The 636 usage of the reliable stream protocol TCP (RFC 793 [10]) 637 and secured reliable stream protocol TLS over TCP [7] is 638 what is currently defined as transport protocol of RTSP 639 messages. 641 Multi-server capable: Each media stream within a presentation 642 can reside on a different server. The client automatically 643 establishes several concurrent control sessions with the 644 different media servers. Media synchronization is 645 performed at the transport level. 647 Separation of stream control and conference initiation: Stream 648 control is divorced from inviting a media server to a 649 conference. In particular, SIP [28] or H.323 [29] may be 650 used to invite a server to a conference. 652 Suitable for professional applications: RTSP supports frame- 653 level accuracy through SMPTE time stamps to allow remote 654 digital editing. 656 Presentation description neutral: The protocol does not impose a 657 particular presentation description or metafile format and 658 can convey the type of format to be used. However, the 659 presentation description is required to contain at least 660 one RTSP URI. 662 Proxy and firewall friendly: The protocol should be readily 663 handled by both application and transport-layer (SOCKS 664 [30]) firewalls. A firewall may need to understand the 665 SETUP method to open a "hole" for the media stream. 667 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so 668 that the existing infrastructure can be reused. This 669 infrastructure includes PICS (Platform for Internet Content 670 Selection [31,32]) for associating labels with content. 671 However, RTSP does not just add methods to HTTP since the 672 controlling continuous media requires server state in most 673 cases. 675 Appropriate server control: If a client can start a stream, it 676 needs to be able to stop a stream. Servers should not start 677 streaming to clients in such a way that clients cannot stop 678 the stream. 680 Transport negotiation: The client can negotiate the transport 681 method prior to actually needing to process a continuous 682 media stream. 684 1.6 Extending RTSP 686 Since not all media servers have the same functionality, media 687 servers by necessity will support different sets of requests. For 688 example: 690 o A server may not be capable of seeking (absolute positioning) 691 if it is to support live events only. 693 o Some servers may not support setting stream parameters and 694 thus not support GET_PARAMETER and SET_PARAMETER. 696 o Some server may support an RTSP extension, for example the 697 currently proposed "end of stream" indication. 699 A server SHOULD implement all header fields described in Section 14. 701 It is up to the creators of presentation descriptions not to ask the 702 impossible of a server. This situation is similar in HTTP/1.1 [4], 703 where the methods described in [H19.5] are not likely to be supported 704 across all servers. 706 RTSP can be extended in three ways, listed here in order of the 707 magnitude of changes supported: 709 o Existing methods can be extended with new parameters, e.g. 710 headers, as long as these parameters can be safely ignored by 711 the recipient. If the client needs negative acknowledgement 712 when a method extension is not supported, a tag corresponding 713 to the extension may be added in the Require: field (see 714 Section 14.37). 716 o New methods can be added. If the recipient of the message does 717 not understand the request, it responds with error code 501 718 (Not Implemented) and the sender should not attempt to use 719 this method again. A client may also use the OPTIONS method to 720 inquire about methods supported by the server. The server MUST 721 list the methods it supports using the Public response header. 723 o A new version of the protocol can be defined, allowing almost 724 all aspects (except the position of the protocol version 725 number) to change. 727 The basic capability discovery mechanism can be used to both discover 728 support for a certain feature and to ensure that a feature is 729 available when performing a request. For detailed explanation of this 730 see section 10. 732 1.7 Overall Operation 734 Each presentation and media stream is identified by an RTSP URI. The 735 overall presentation and the properties of the media the presentation 736 is made up of are defined by a presentation description file, the 737 format of which is outside the scope of this specification. The 738 presentation description file may be obtained by the client using 739 HTTP or other means such as email and may not necessarily be stored 740 on the media server. 742 For the purposes of this specification, a presentation description is 743 assumed to describe one or more presentations, each of which 744 maintains a common time axis. For simplicity of exposition and 745 without loss of generality, it is assumed that the presentation 746 description contains exactly one such presentation. A presentation 747 may contain several media streams. 749 The presentation description file contains a description of the media 750 streams making up the presentation, including their encodings, 751 language, and other parameters that enable the client to choose the 752 most appropriate combination of media. In this presentation 753 description, each media stream that is individually controllable by 754 RTSP is identified by an RTSP URI, which points to the media server 755 handling that particular media stream and names the stream stored on 756 that server. Several media streams can be located on different 757 servers; for example, audio and video streams can be split across 758 servers for load sharing. The description also enumerates which 759 transport methods the server is capable of. 761 Besides the media parameters, the network destination address and 762 port need to be determined. Several modes of operation can be 763 distinguished: 765 Unicast: The media is transmitted to the source of the RTSP 766 request, with the port number chosen by the client. 767 Alternatively, the media is transmitted on the same 768 reliable stream as RTSP. 770 Multicast, server chooses address: The media server picks the 771 multicast address and port. This is the typical case for a 772 live or near-media-on-demand transmission. 774 Multicast, client chooses address: If the server is to 775 participate in an existing multicast conference, the 776 multicast address, port and encryption key are given by the 777 conference description, established by means outside the 778 scope of this specification, for example by a SIP created 779 conference. 781 1.8 RTSP States 783 RTSP controls a stream which may be sent via a separate protocol, 784 independent of the control channel. For example, RTSP control may be 785 transported on a TCP connection while the media data is conveyed via 786 UDP. Thus, data delivery continues even if no RTSP requests are 787 received by the media server. Also, during its lifetime, a single 788 media stream may be controlled by RTSP requests issued sequentially 789 on different TCP connections. Therefore, the server needs to maintain 790 "session state" to be able to correlate RTSP requests with a stream. 791 The state transitions are described in Appendix A. 793 Many methods in RTSP do not contribute to state. However, the 794 following play a central role in defining the allocation and usage of 795 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING 796 and TEARDOWN. 798 SETUP: Causes the server to allocate resources for a stream and 799 create an RTSP session. 801 PLAY: Starts data transmission on a stream allocated via SETUP. 803 PAUSE: Temporarily halts a stream without freeing server 804 resources. 806 REDIRECT: Indicates that the session should be moved to new 807 server / location 809 PING: Prevents the identified session from being timed out. 811 TEARDOWN: Frees resources associated with the stream. The RTSP 812 session ceases to exist on the server. 814 RTSP methods that contribute to state use the Session header field 815 (Section 14.42) to identify the RTSP session whose state is being 816 manipulated. The server generates session identifiers in response to 817 SETUP requests (Section 11.3). 819 1.9 Relationship with Other Protocols 821 RTSP has some overlap in functionality with HTTP. It also may 822 interact with HTTP in that the initial contact with streaming content 823 is often to be made through a web page. The current protocol 824 specification aims to allow different hand-off points between a web 825 server and the media server implementing RTSP. For example, the 826 presentation description can be retrieved using HTTP or RTSP, which 827 reduces round trips in web-browser-based scenarios, yet also allows 828 for stand alone RTSP servers and clients which do not rely on HTTP at 829 all. However, RTSP differs fundamentally from HTTP in that most data 830 delivery takes place out-of-band in a different protocol. HTTP is an 831 asymmetric protocol where the client issues requests and the server 832 responds. In RTSP, both the media client and media server can issue 833 requests. RTSP requests are also stateful; they may set parameters 834 and continue to control a media stream long after the request has 835 been acknowledged. 837 Re-using HTTP functionality has advantages in at least two 838 areas, namely security and proxies. The requirements are 839 very similar, so having the ability to adopt HTTP work on 840 caches, proxies and authentication is valuable. 842 RTSP assumes the existence of a presentation description format that 843 can express both static and temporal properties of a presentation 844 containing several media streams. Session Description Protocol (SDP) 845 [2] is generally the format of choice; however, RTSP is not bound to 846 it. For data delivery, most real-time media will use RTP as a 847 transport protocol. While RTSP works well with RTP, it is not tied to 848 RTP. 850 2 RTSP Use Cases 852 This section describes some of the use cases for RTSP. They are 853 listed in descending order of importance in regards to ensuring that 854 all necessary functionality is present. This specification does only 855 fully support usage of the two first. Also in these first two cases 856 are there special cases that will not be supported without 857 extensions, e.g. the redirection of media to another address than the 858 controlling entity. 860 2.1 On-demand Playback of Stored Content 862 An RTSP capable server stores content suitable for being streamed to 863 a client. A client desiring playback of any of the stored content 864 uses RTSP to set up the media transport required for the desired 865 content. Then RTSP is used to initiate, halt and manipulate the 866 transmission of the content. There are also requirement on being able 867 to use RTSP to carry necessary description and synchronization 868 information for the content. The above high level description can be 869 broken down into a number of functionalities that RTSP needs to be 870 capable of. 872 Presentation Description: The possibility to carry 873 initialization information about the presentation 874 (content), for example, which media codec(s) that are 875 needed for the content. Other information that are 876 important; how many media stream that the presentation 877 contains; what transport protocols to use for the media 878 streams; and identifiers for these media streams. This 879 information is required before setup of the content is 880 possible. The information is also needed by the client to 881 determine if it is capable at all to support the content. 882 This information is not required to be sent using RTSP, 883 instead other external protocols can be utilized to 884 transport presentation descriptions. Two good examples are 885 the use of HTTP [4] or email to fetch or receive 886 presentation descriptions like SDP [2]. .XP Setup: 887 Performing setup of some or all of the media streams in a 888 presentation. The setup itself consist of determining which 889 protocols for media transport to use; the necessary 890 parameters for the protocol, like addresses and ports. .XP 891 Control of Transmission: After the necessary media streams 892 has been established the client can request the server to 893 start transmitting the content. There is need to allow the 894 client to arbitrary times start or stop the transmission of 895 the content. There are also exist need to be able to start 896 the transmission at an any point in the timeline of the 897 presentation. .XP Synchronization: For media transport 898 protocols like RTP [17] it might be beneficial to carry 899 synchronization information within RTSP. Either due to the 900 lack of inter media synchronization within the protocol 901 itself, or the potential delay before the synchronization 902 is established (which is the case for RTP when using RTCP). 903 .XP Termination There is also need to be able to terminate 904 the established contexts. 905 For this use cases there is a number of assumption about how it 906 works. These are listed below: 908 On-Demand content: The content available is stored at the server 909 and can be accessed at any time during a time period when 910 it is intended to be available. .XP Independent sessions: A 911 server is capable of serving a number of clients 912 simultaneously, including from the same piece of content at 913 different points in that presentations time-line. .XP 914 Unicast Transport: Content for each individual client is 915 transmitted to them using unicast traffic. 916 It is also possible to redirect the media traffic to another 917 destination than where the entity controlling traffic uses. 918 However allowing this without appropriate mechanisms for 919 checking that the destination approves of this is a denial of 920 service threat. 922 2.2 Unicast distribution of Live Content 924 This use cases is not that different from the above on-demand content 925 case (see section 2.1. The difference is really the restriction the 926 content itself establish. Live content is continuously distributed as 927 it becomes available from a source, i.e. the main difference to on- 928 demand is that one starts distributing content before the end of it 929 has become available to the server. In many cases the consumer of 930 live content is only interested in consuming what is actually happens 931 "now", i.e. very similar to broadcast TV. However in this case it is 932 assumed that there exist no broadcast or multicast channel to the 933 users, and instead the server functions as a distribution node, 934 sending the same content to multiple receivers, using unicast traffic 935 between server and client. This unicast traffic and the transport 936 parameters are individually negotiated for each receiving client. 937 Another aspect of live content is that it has often very limited time 938 of availability, as it is only is available for the duration of the 939 event the content covers. A example of such a live content could for 940 example be a music concert, which lasts 2 hour and starts at a 941 predetermined time. Thus there is need to announce when and for how 942 long the live content is available. 944 2.3 On-demand Playback using Multicast 946 It is possible to use RTSP to request that media is delivered to a 947 multicast group. The entity setting up the session (the controller) 948 will then control when and what media that is delivered to the group. 949 Also this use case has some potential for denial of service attacks, 950 in this case flooding any multicast group. Therefore there is need 951 for a mechanism indicating that the group actually accepts the 952 traffic from the RTSP server. An open issue in this use case is how 953 one ensures that all receivers listening to the multicast or 954 broadcast receives the session presentation configuring the 955 receivers. 957 2.4 Inviting a RTSP server into a conference 959 If one has an established conference or group session, it is possible 960 to have a RTSP server distribute media to the whole group. The 961 transmission to the group is simplest controlled by a single 962 participant or leader of the conference. Shared control might be 963 possible, but would require further investigation and possibly 964 extensions. There are some protocol mechanisms missing for this 965 scenario. For reasonable complexity in the media transmission stage, 966 this use case assumes that there exist either multicast or a 967 conference focus that redistribute media to all participants. In some 968 more detail, this use case is intended to be able to handle the 969 following scenario: A conference leader or participant (from here 970 called the controller) has some pre-stored content on a RTSP server 971 that he likes to share with the group. The controller sets up a RTSP 972 session at the streaming server for the content the controller likes 973 to share. The session description for the content is retrieved to the 974 controller. The media destination for the media content is set to the 975 shared multicast group or conference focus. When desired by the 976 controller, he/she can start and stop the transmission of the media 977 to the conference group. There are several issues with this use case 978 that is not solved by this core specification for RTSP: 980 o Denial of service threat, to avoid a RTSP server from being a 981 unknowing participant of a denial of service attack the server 982 needs to be able to verify the destinations acceptance for the 983 media. Such a mechanism does not yet exist that can be used to 984 verify the approval to received media, instead only policies 985 can be used, which can be made to work in controlled 986 environments. .IP o 2 The problem of distributing the 987 presentation description to all participants in the group. To 988 enable a media receiver to decode the content correctly the 989 media configuration information will need to be distributed 990 reliable to all participants. This will most likely require 991 support from an external protocol. .IP o 2 Passing the 992 control. If it is desired to be able to pass the control of 993 the RTSP session between the participants some support will be 994 required by an external protocol for the necessary exchange of 995 state information and possibly floor control of who is 996 controlling the RTSP session. 998 So if there interest in this use case further work on the necessary 999 extensions has to be performed. 1001 2.5 Live Content using Multicast 1003 This use case does in its simplest form do not require any use of 1004 RTSP at all. This is what multicast conferences being announce with 1005 SAP and SDP are intended to handle. However in use cases where more 1006 advance features like access control to the multicast session is 1007 desired, RTSP could be used for session establishment. A client 1008 desiring to join a live multicasted media session with cryptographic 1009 (encryption) access control could use RTSP in the following way. The 1010 source of the session, announces the session and gives all interested 1011 to join, a RTSP URI. The client connects to the server and requests 1012 the presentation description allowing for configuration the 1013 reception. In this step it is possible to use secured transport for 1014 the client, and also desired levels of authentication, for example 1015 for charging purposes or simply access control. An RTSP link also 1016 allows for load balancing between multiple servers. However if this 1017 the only thing that occurs it can probably be solved as simple using 1018 HTTP. However for session where the sender likes to keep track of 1019 each individual receiver during the session, and possibly use this 1020 side channel for pushing out key-updates or other side information 1021 that is desirable to be done on a per receiver basis, and the 1022 receivers are not know prior to the session start, the state 1023 establishment that RTSP provides can be beneficial. In this case a 1024 client would establish a RTSP session to the multicast group. The 1025 RTSP server will not transmit any media, instead it will simply point 1026 to the multicast group. However the client and server will be able to 1027 keep the session alive for as long as the receiver participates in 1028 the session. Thus enabling for example server to client pushes of 1029 updates. This use cases will most likely not be able to actually 1030 implement some extensions in relation to the server to client push 1031 mechanism. Here a method like ANNOUNCE might be suitable, however it 1032 will require a RTSP extension to revive the method. 1034 3 Protocol Parameters 1036 3.1 RTSP Version 1038 HTTP Specification Section [H3.1] applies, with HTTP replaced by 1039 RTSP. This specification defines version 1.0 of RTSP. 1041 3.2 RTSP URI 1043 The "rtsp", "rtsps" schemes are used to refer to network resources 1044 via the RTSP protocol. This section defines the scheme-specific 1045 syntax and semantics for RTSP URIs. The RTSP URI is case sensitive. 1046 An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP 1047 messages over unreliable transport (UDP) and is currently deprecated 1048 and reserved, and MUST NOT be used . See Appendix E for further 1049 information. 1051 Informative RTSP URI syntax: 1053 rtsp[u|s]://host[:port]/abspath[?query]#fragment 1055 See section 18.2.1 for the formal definition of the RTSP URI syntax. 1057 The fragment identifier is used as defined in section 4.1 of [13], 1058 i.e. the fragment is to be stripped from the URI by the requestor and 1059 not included in the request. The user agent also needs to interpret 1060 the value of the fragment based on the media type the request relates 1061 to, i.e. the media type indicated in Content-Type header in the 1062 response to DESCRIBE. 1064 The syntax of any URI query string is unspecified and responder 1065 (usually the server) specific. As it is from the requestor an opaque 1066 string, it needs to be handled as such. 1068 The URI scheme rtsp requires that commands are issued via a reliable 1069 protocol (within the Internet, TCP), while the scheme rtsps 1070 identifies a reliable transport using secure transport (TLS [7]). 1072 If the no port number is provided in the URI, port number 554 SHALL 1073 be used. The semantics are that the identified resource can be 1074 controlled by RTSP at the server listening for TCP (scheme "rtsp") 1075 connections on that port of host, and the Request-URI for the 1076 resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322 1077 is registered and SHALL be assumed. 1079 The use of IP addresses in URIs SHOULD be avoided whenever possible 1080 (see RFC 1924 [11]). Note: Using qualified domain names in any URI is 1081 one requirement for making it possible for RFC 2326 implementations 1082 of RTSP to use IPv6. This specification is updated to allow for 1083 literal IPv6 addresses in RTSP URIs using the host specification in 1084 RFC 2732 [12]. 1086 A presentation or a stream is identified by a textual media 1087 identifier, using the character set and escape conventions [H3.2] of 1088 URIs (RFC 2396 [13]). URIs may refer to a stream or an aggregate of 1089 streams, i.e., a presentation. Accordingly, requests described in 1090 Section 11 can apply to either the whole presentation or an 1091 individual stream within the presentation. Note that some request 1092 methods can only be applied to streams, not presentations and vice 1093 versa. 1095 For example, the RTSP URI: 1097 rtsp://media.example.com:554/twister/audiotrack 1099 identifies the audio stream within the presentation "twister", which 1100 can be controlled via RTSP requests issued over a TCP connection to 1101 port 554 of host media.example.com 1103 Also, the RTSP URI: 1105 rtsp://media.example.com:554/twister 1107 identifies the presentation "twister", which may be composed of audio 1108 and video streams. 1110 This does not imply a standard way to reference streams in 1111 URIs. The presentation description defines the hierarchical 1112 relationships in the presentation and the URIs for the 1113 individual streams. A presentation description may name a 1114 stream "a.mov" and the whole presentation "b.mov". 1116 The path components of the RTSP URI are opaque to the client and do 1117 not imply any particular file system structure for the server. 1119 This decoupling also allows presentation descriptions to be 1120 used with non-RTSP media control protocols simply by 1121 replacing the scheme in the URI. 1123 3.3 Session Identifiers 1125 Session identifiers are strings of any arbitrary length. A session 1126 identifier MUST be chosen randomly and MUST be at least eight 1127 characters long to make guessing it more difficult. (See Section 19.) 1129 3.4 SMPTE Relative Timestamps 1131 A SMPTE relative timestamp expresses time relative to the start of 1132 the clip. Relative timestamps are expressed as SMPTE time codes for 1133 frame-level access accuracy. The time code has the format 1134 hours:minutes:seconds:frames.subframes, 1135 with the origin at the start of the clip. The default smpte format 1136 is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 1137 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 1138 use of alternative use of "smpte time". For the "frames" field in the 1139 time value can assume the values 0 through 29. The difference between 1140 30 and 29.97 frames per second is handled by dropping the first two 1141 frame indices (values 00 and 01) of every minute, except every tenth 1142 minute. If the frame value is zero, it may be omitted. Subframes are 1143 measured in one-hundredth of a frame. 1145 Examples: 1147 smpte=10:12:33:20- 1148 smpte=10:07:33- 1149 smpte=10:07:00-10:07:33:05.01 1150 smpte-25=10:07:00-10:07:33:05.01 1152 3.5 Normal Play Time 1154 Normal play time (NPT) indicates the stream absolute position 1155 relative to the beginning of the presentation, not to be confused 1156 with the Network Time Protocol (NTP) [33]. The timestamp consists of 1157 a decimal fraction. The part left of the decimal may be expressed in 1158 either seconds or hours, minutes, and seconds. The part right of the 1159 decimal point measures fractions of a second. 1161 The beginning of a presentation corresponds to 0.0 seconds. Negative 1162 values are not defined. The special constant now is defined as the 1163 current instant of a live type event. It MAY only be used for live 1164 type events, and SHALL NOT be used for on-demand content. 1166 NPT is defined as in DSM-CC [34]: "Intuitively, NPT is the clock the 1167 viewer associates with a program. It is often digitally displayed on 1168 a VCR. NPT advances normally when in normal play mode (scale = 1), 1169 advances at a faster rate when in fast scan forward (high positive 1170 scale ratio), decrements when in scan reverse (high negative scale 1171 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 1172 SMPTE time codes." 1174 Examples: 1176 npt=123.45-125 1177 npt=12:05:35.3- 1178 npt=now- 1180 The syntax conforms to ISO 8601 [35]. The npt-sec notation 1181 is optimized for automatic generation, the ntp-hhmmss 1182 notation for consumption by human readers. The "now" 1183 constant allows clients to request to receive the live feed 1184 rather than the stored or time-delayed version. This is 1185 needed since neither absolute time nor zero time are 1186 appropriate for this case. 1188 3.6 Absolute Time 1190 Absolute time is expressed as ISO 8601 [35] timestamps, using UTC 1191 (GMT). Fractions of a second may be indicated. 1193 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 1194 UTC: 1196 19961108T143720.25Z 1198 3.7 Feature-tags 1200 Feature-tags are unique identifiers used to designate features in 1201 RTSP. These tags are used in Require (Section 14.37), Proxy-Require 1202 (Section 14.31), Proxy-Supported (Section 14.32), Unsupported 1203 (Section 14.46), and Supported (Section 14.43) header fields. 1205 Feature tag needs to indicate if they apply to servers only, proxies 1206 only, or both server and proxies. 1208 The creator of a new RTSP feature-tag should either prefix the 1209 feature-tag with a reverse domain name (e.g., 1210 "com.example.mynewfeature" is an apt name for a feature whose 1211 inventor can be reached at "example.com"), or register the new 1212 feature-tag with the Internet Assigned Numbers Authority (IANA), see 1213 IANA Section 20. 1215 The usage of feature tags are further described in section 10 that 1216 deals with capability handling. 1218 3.8 Entity Tags 1220 Entity tags are opaque strings that are used to compare two entities 1221 from the same resource, for example in caches or to optimize setup 1222 after a redirect. Further explanation is present in [H3.11]. For 1223 explanation on how to compare Entity tags see [H13.3]. Entity tags 1224 can be carried in the ETag header (see section 14.21) or in SDP (see 1225 section C.1.8). 1227 Entity tags are used in RTSP to make some methods conditional. The 1228 methods are made conditional through the inclusion of headers, see 1229 14.25 and 14.27. 1231 4 RTSP Message 1233 RTSP is a text-based protocol and uses the ISO 10646 character set in 1234 UTF-8 encoding (RFC 2279 [14]). Lines are terminated by CRLF, but 1235 receivers should be prepared to also interpret CR and LF by 1236 themselves as line terminators. 1238 Text-based protocols make it easier to add optional 1239 parameters in a self-describing manner. Since the number of 1240 parameters and the frequency of commands is low, processing 1241 efficiency is not a concern. Text-based protocols, if done 1242 carefully, also allow easy implementation of research 1243 prototypes in scripting languages such as Tcl, Visual Basic 1244 and Perl. 1246 The 10646 character set avoids tricky character set switching, but is 1247 invisible to the application as long as US-ASCII is being used. This 1248 is also the encoding used for RTCP. ISO 8859-1 translates directly 1249 into Unicode with a high-order octet of zero. ISO 8859-1 characters 1250 with the most-significant bit set are represented as 1100001x 1251 10xxxxxx. (See RFC 2279 [14]) 1253 Requests contain methods, the object the method is operating upon and 1254 parameters to further describe the method. Methods are idempotent, 1255 unless otherwise noted. Methods are also designed to require little 1256 or no state maintenance at the media server. 1258 4.1 Message Types 1260 See [H4.1]. 1262 4.2 Message Headers 1264 See [H4.2]. 1266 4.3 Message Body 1268 See [H4.3] 1270 4.4 Message Length 1272 When a message body is included with a message, the length of that 1273 body is determined by one of the following (in order of precedence): 1275 1. Any response message which MUST NOT include a message body 1276 (such as the 1xx, 204, and 304 responses) is always 1277 terminated by the first empty line after the header fields, 1278 regardless of the entity-header fields present in the 1279 message. (Note: An empty line consists of only CRLF.) 1281 2. If a Content-Length header field (section 14.16) is 1282 present, its value in bytes represents the length of the 1283 message-body. If this header field is not present, a value 1284 of zero is assumed. 1286 Note that RTSP does not (at present) support the HTTP/1.1 "chunked" 1287 transfer coding(see [H3.6.1]) and requires the presence of the 1288 Content-Length header field. 1290 Given the moderate length of presentation descriptions 1291 returned, the server should always be able to determine its 1292 length, even if it is generated dynamically, making the 1293 chunked transfer encoding unnecessary. 1295 5 General Header Fields 1297 See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, 1298 and Warning headers are not defined. RTSP further defines the CSeq, 1299 and Timestamp. The general headers are listed in table 1: 1301 Header Name Comment 1302 _________________________________ 1303 Cache-Control See section 14.10 1304 Connection See section 14.11 1305 CSeq See section 14.19 1306 Date See section 14.20 1307 Supported See section 14.43 1308 Timestamp See section 14.44 1309 Via See section 14.49 1311 Table 1: The General headers used in RTSP. 1313 6 Request 1315 A request messages uses the format outlined below, regardless of the 1316 direction of a request, client to server or server to client: 1318 o Request line, containing the method to be applied to the 1319 resource, the identifier of the resource, and the protocol 1320 version in use; 1322 o zero or more Header lines, that can be of the following types: 1323 general (Section 5), request (Section 6.2), or entity (Section 1324 8.1); 1326 o One empty line (CR/LF) to indicate the end of the header 1327 section; 1329 o Optionally a message body (entity), consisting of one or more 1330 lines. the length of the message body in number of bytes is 1331 indicated by the Content-Length entity header. 1333 6.1 Request Line 1335 The request line provides the key information about the request: 1336 What method, on what resources and using which RTSP version. The 1337 methods that is defined by this specification can be seen in Table 1338 6.1. The resource is identified through an absolute RTSP URI (see 1339 section 3.2. 1341 SP SP CRLF 1343 Please note: The request line's syntax can't be freely changed in 1344 future versions of RTSP, as this line indicates the version of the 1345 messages and need to be parsable also by older versions. 1347 Note that in contrast to HTTP/1.1 [4], RTSP requests always contain 1348 the absolute URI (that is, including the scheme, host and port) 1349 rather than just the absolute path. 1351 HTTP/1.1 requires servers to understand the absolute URI, 1352 but clients are supposed to use the Host request header. 1353 This is purely needed for backward-compatibility with 1354 HTTP/1.0 servers, a consideration that does not apply to 1355 RTSP. 1357 Method Defined In Section 1358 _________________________________ 1359 DESCRIBE Section 11.2 1360 GET_PARAMETER Section 11.7 1361 OPTIONS Section 11.1 1362 PAUSE Section 11.5 1363 PLAY Section 11.4 1364 PING Section 11.10 1365 REDIRECT Section 11.9 1366 SETUP Section 11.3 1367 SET_PARAMETER Section 11.8 1368 TEARDOWN Section 11.6 1370 Table 2: The RTSP Methods 1372 The asterisk "*" in the Request-URI means that the request does not 1373 apply to a particular resource, but to the server or proxy itself, 1374 and is only allowed when the method used does not necessarily apply 1375 to a resource. 1377 One example would be as follows: 1379 OPTIONS * RTSP/1.0 1381 An OPTIONS in this form will determine the capabilities of the server 1382 or the proxy that first receives the request. If one needs to address 1383 the server explicitly, then one should use an absolute URI with the 1384 server's address. 1386 OPTIONS rtsp://example.com RTSP/1.0 1388 6.2 Request Header Fields 1390 The RTSP headers in Table 3 can be included in a request with the 1391 purpose to give further define how the request should be fulfilled. A 1392 request header MAY also be response header, see section 7.1.2. 1394 Header Defined in Section 1395 _____________________________________ 1396 Accept Section 14.1 1397 Accept-Encoding Section 14.3 1398 Accept-Language Section 14.4 1399 Authorization Section 14.7 1400 Bandwidth Section 14.8 1401 Blocksize Section 14.9 1402 From Section 14.23 1403 If-Match Section 14.25 1404 If-Modified-Since Section 14.26 1405 If-None-Match Section 14.27 1406 Proxy-Require Section 14.31 1407 Range Section 14.34 1408 Referer Section 14.35 1409 Require Section 14.37 1410 Scale Section 14.39 1411 Session Section 14.42 1412 Speed Section 14.40 1413 Supported Section 14.43 1414 Transport Section 14.45 1415 User-Agent Section 14.47 1417 Table 3: The RTSP request headers 1419 7 Response 1421 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1422 Also, RTSP defines additional status codes and does not define some 1423 HTTP codes. The valid response codes and the methods they can be used 1424 with are defined in Table 4. 1426 After receiving and interpreting a request message, the recipient 1427 responds with an RTSP response message. 1429 7.1 Status-Line 1431 The first line of a Response message is the Status-Line, consisting 1432 of the protocol version followed by a numeric status code, and the 1433 textual phrase associated with the status code, with each element 1434 separated by SP characters. No CR or LF is allowed except in the 1435 final CRLF sequence. 1437 SP SP CRLF 1439 7.1.1 Status Code and Reason Phrase 1441 The Status-Code element is a 3-digit integer result code of the 1442 attempt to understand and satisfy the request. These codes are fully 1443 defined in Section 13. The Reason-Phrase is intended to give a short 1444 textual description of the Status-Code. The Status-Code is intended 1445 for use by automata and the Reason-Phrase is intended for the human 1446 user. The client is not required to examine or display the Reason- 1447 Phrase. 1449 The first digit of the Status-Code defines the class of response. The 1450 last two digits do not have any categorization role. There are 5 1451 values for the first digit: 1453 o 1xx: Informational - Request received, continuing process 1455 o 2xx: Success - The action was successfully received, 1456 understood, and accepted 1458 o 3rr: Redirection - Further action needs to be taken in order 1459 to complete the request 1461 o 4xx: Client Error - The request contains bad syntax or cannot 1462 be fulfilled 1464 o 5xx: Server Error - The server failed to fulfill an apparently 1465 valid request 1467 The individual values of the numeric status codes defined for 1468 RTSP/1.0, and an example set of corresponding Reason-Phrases, are 1469 presented in table 4. The reason phrases listed here are only 1470 recommended; they may be replaced by local equivalents without 1471 affecting the protocol. Note that RTSP adopts most HTTP/1.1 [4] 1472 status codes and adds RTSP-specific status codes starting at x50 to 1473 avoid conflicts with newly defined HTTP status codes. 1475 RTSP status codes are extensible. RTSP applications are not required 1476 to understand the meaning of all registered status codes, though such 1477 understanding is obviously desirable. However, applications MUST 1478 understand the class of any status code, as indicated by the first 1479 digit, and treat any unrecognized response as being equivalent to the 1480 x00 status code of that class, with the exception that an 1481 unrecognized response MUST NOT be cached. For example, if an 1482 unrecognized status code of 431 is received by the client, it can 1483 safely assume that there was something wrong with its request and 1484 treat the response as if it had received a 400 status code. In such 1485 cases, user agents SHOULD present to the user the entity returned 1486 with the response, since that entity is likely to include human- 1487 readable information which will explain the unusual status. 1489 7.1.2 Response Header Fields 1491 The response-header fields allow the request recipient to pass 1492 additional information about the response which cannot be placed in 1493 the Status-Line. These header fields give information about the 1494 server and about further access to the resource identified by the 1495 Request-URI. All headers currently being classified as response 1496 headers are listed in table 5. 1498 Response-header field names can be extended reliably only in 1499 combination with a change in the protocol version. However, new or 1500 experimental header fields MAY be given the semantics of response- 1501 header fields if all parties in the communication recognize them to 1502 be response-header fields. Unrecognized header fields are treated as 1503 entity-header fields. 1505 8 Entity 1507 Request and Response messages MAY transfer an entity if not otherwise 1508 restricted by the request method or response status code. An entity 1509 consists of entity-header fields and an entity-body, although some 1510 responses will only include the entity-headers. 1512 The SET_PARAMETER, and GET_PARAMETER request and response, and 1513 DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY 1514 also have an entity. 1516 In this section, both sender and recipient refer to either the client 1517 or the server, depending on who sends and who receives the entity. 1519 8.1 Entity Header Fields 1521 Entity-header fields define optional meta-information about the 1522 entity-body or, if no body is present, about the resource identified 1523 by the request. The entity header fields are listed in table 8.1. 1525 Header Defined in Section 1526 ____________________________________ 1527 Allow Section 14.6 1528 Content-Base Section 14.13 1529 Content-Encoding Section 14.14 1530 Content-Language Section 14.15 1531 Content-Length Section 14.16 1532 Content-Location Section 14.17 1533 Content-Type Section 14.18 1534 Expires Section 14.22 1535 Last-Modified Section 14.28 1537 Table 6: The RTSP entity headers 1539 The extension-header mechanism allows additional entity-header fields 1540 to be defined without changing the protocol, but these fields cannot 1541 be assumed to be recognizable by the recipient. Unrecognized header 1542 fields SHOULD be ignored by the recipient and forwarded by proxies. 1544 8.2 Entity Body 1546 See [H7.2] with the addition that an RTSP message with an entity body 1547 MUST include the Content-Type and Content-Length headers. 1549 9 Connections 1551 RTSP requests can be transmitted in several different ways: 1553 o persistent transport connections used for several request- 1554 response transactions; 1556 o one connection per request/response transaction; 1558 o connectionless mode. 1560 The type of transport is defined by the RTSP URI (Section 3.2). For 1561 the scheme "rtsp", a connection is assumed, while the scheme "rtsps" 1562 Code Reason Method 1563 __________________________________________________________ 1564 100 Continue all 1566 __________________________________________________________ 1567 200 OK all 1568 201 Created RECORD 1569 250 Low on Storage Space RECORD 1570 __________________________________________________________ 1571 300 Multiple Choices all 1572 301 Moved Permanently all 1573 302 Found all 1574 303 See Other all 1575 305 Use Proxy all 1577 __________________________________________________________ 1578 400 Bad Request all 1579 401 Unauthorized all 1580 402 Payment Required all 1581 403 Forbidden all 1582 404 Not Found all 1583 405 Method Not Allowed all 1584 406 Not Acceptable all 1585 407 Proxy Authentication Required all 1586 408 Request Timeout all 1587 410 Gone all 1588 411 Length Required all 1589 412 Precondition Failed DESCRIBE, SETUP 1590 413 Request Entity Too Large all 1591 414 Request-URI Too Long all 1592 415 Unsupported Media Type all 1593 451 Parameter Not Understood SET_PARAMETER 1594 452 reserved n/a 1595 453 Not Enough Bandwidth SETUP 1596 454 Session Not Found all 1597 455 Method Not Valid In This State all 1598 456 Header Field Not Valid all 1599 457 Invalid Range PLAY, PAUSE 1600 458 Parameter Is Read-Only SET_PARAMETER 1601 459 Aggregate Operation Not Allowed all 1602 460 Only Aggregate Operation Allowed all 1603 461 Unsupported Transport all 1604 462 Destination Unreachable all 1605 470 Connection Authorization Required all 1606 471 Connection Credentials not accepted all 1607 __________________________________________________________ 1608 500 Internal Server Error all 1609 501 Not Implemented all 1610 502 Bad Gateway all 1611 503 Service Unavailable all 1612 504 Gateway Timeout all 1613 505 RTSP Version Not Supported all 1615 Table 4: Status codes and their usage with RTSP methods 1617 Header Defined in Section 1618 __________________________________________ 1619 Accept-Ranges Section 14.5 1620 Connection-Credentials Section 14.12 1621 ETag Section 14.21 1622 Location Section 14.29 1623 Proxy-Authenticate Section 14.30 1624 Public Section 14.33 1625 Range Section 14.34 1626 Retry-After Section 14.36 1627 RTP-Info Section 14.38 1628 Scale Section 14.39 1629 Session Section 14.42 1630 Server Section 14.41 1631 Speed Section 14.40 1632 Transport Section 14.45 1633 Unsupported Section 14.46 1634 Vary Section 14.48 1635 WWW-Authenticate Section 14.50 1637 Table 5: The RTSP response headers 1639 calls for RTSP requests to be sent using a secure protocol. 1641 Unlike HTTP, RTSP allows the media server to send requests to the 1642 media client. However, this is only supported for persistent 1643 connections, as the media server otherwise has no reliable way of 1644 reaching the client. Also, this is the only way that requests from 1645 media server to client are likely to traverse firewalls. 1647 9.1 Pipelining 1649 A client that supports persistent connections or connectionless mode 1650 MAY "pipeline" its requests (i.e., send multiple requests without 1651 waiting for each response). A server MUST send its responses to those 1652 requests in the same order that the requests were received. 1654 9.2 Reliability and Acknowledgements 1656 The transmission of RTSP over UDP was optionally to implement and 1657 specified in RFC 2326. However that definition was not sufficient for 1658 interoperable implementations. Due to lack of interest, this 1659 specification does not specify how RTSP over UDP is implemented. 1660 However to maintain backwards compatibility in the message format 1661 certain RTSP headers are maintained. 1663 Any RTSP request according to this specification SHALL NOT be sent to 1664 a multicast address. Any RTSP request SHALL be acknowledged. If a 1665 reliable transport protocol is used to carry RTSP, requests MUST NOT 1666 be retransmitted; the RTSP application MUST instead rely on the 1667 underlying transport to provide reliability. 1669 If both the underlying reliable transport such as TCP and 1670 the RTSP application retransmit requests, it is possible 1671 that each packet loss results in two retransmissions. The 1672 receiver cannot typically take advantage of the 1673 application-layer retransmission since the transport stack 1674 will not deliver the application-layer retransmission 1675 before the first attempt has reached the receiver. If the 1676 packet loss is caused by congestion, multiple 1677 retransmissions at different layers will exacerbate the 1678 congestion. 1680 Each request carries a sequence number in the CSeq header (Section 1681 14.19), which MUST be incremented by one for each distinct request 1682 transmitted to the destination end-point. The initial sequence 1683 number MAY be chosen arbitrary, but is RECOMMENDED to begin with 0. 1684 If a request is repeated because of lack of acknowledgement, the 1685 request MUST carry the original sequence number (i.e., the sequence 1686 number is not incremented). 1688 9.3 The usage of connections 1690 Systems implementing RTSP MUST support carrying RTSP over TCP. The 1691 default port for the RTSP server is 554 for TCP. A number of RTSP 1692 packets destined for the same control end-point may be encapsulated 1693 into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP 1694 packets, see section 12. Unlike HTTP, an RTSP message MUST contain a 1695 Content-Length header field whenever that message contains a payload 1696 (entity). Otherwise, an RTSP packet is terminated with an empty line 1697 immediately following the last message header. 1699 TCP can be used for both persistent connections and for one message 1700 exchange per connection, as presented above. This section gives 1701 further rules and recommendations on how to handle these connections 1702 so maximum interoperability and flexibility can be achieved. 1704 A server SHALL handle both persistent connections and one 1705 request/response transaction per connection. A persistent connection 1706 MAY be used for all transactions between the server and client, 1707 including messages to multiple RTSP sessions. However the persistent 1708 connection MAY also be closed after a few message exchanges, e.g. the 1709 initial setup and play command in a session. Later when the client 1710 wishes to send a new request, e.g. pause, to the session a new 1711 connection is opened. This connection may either be for a single 1712 message exchange or can be kept open for several messages, i.e. 1713 persistent. 1715 A major motivation for allowing non-persistent connections are that 1716 they ensure fault tolerance. A second one is to allow for application 1717 layer mobility. A server and client supporting non-persistent 1718 connection can survive a loss of a TCP connection, e.g. due to a NAT 1719 timeout. When the client has discovered that the TCP connection has 1720 been lost, it can set up a new one when there is need to communicate. 1722 The client MAY close the connection at any time when no outstanding 1723 request/response transactions exist. The server SHOULD NOT close the 1724 connection unless at least one RTSP session timeout period has passed 1725 without data traffic. A server SHOULD NOT initiate a close of a 1726 connection directly after responding to a TEARDOWN request for the 1727 whole session. A server SHOULD NOT close the connection as a result 1728 of responding to a request with an error code. Doing this would 1729 prevent or result in extra overhead for the client when testing 1730 advanced or special types of requests. 1732 The client SHOULD NOT have more than one connection to the server at 1733 any given point. If a client or proxy handles multiple RTSP sessions 1734 on the same server, it is RECOMMENDED to use only a single 1735 connection. 1737 A Client is strongly RECOMMENDED to use persistent connections as it 1738 allows the server to send request to the client. In cases where no 1739 connection exist between the server and the client, this may cause 1740 the server to be forced to drop the RTSP session without notifying 1741 the client why, due to the lack of signalling channel. An example of 1742 such a case is when the server desires to send a REDIRECT request for 1743 an RTSP session to the client. 1745 A server implemented according to this specification MUST respond 1746 that it supports the "play.basic" feature-tag above. A client MAY 1747 send a request including the Supported header in a request to 1748 determine support of non-persistent connections. A server supporting 1749 non-persistent connections will return the "play.basic" feature-tag 1750 in its response. If the client receives the feature-tag in the 1751 response, it can be certain that the server handles non-persistent 1752 connections. 1754 9.4 Timing Out RTSP messages 1756 Receivers of a request (responder) SHOULD respond to requests in a 1757 timely manner even when a reliable transport such as TCP is used. 1759 Similarly, the sender of a request (requestor) SHOULD wait for a 1760 sufficient time for a response before concluding that the responder 1761 will not be acting upon its request. 1763 A responder SHOULD respond to all requests within 5 seconds. If the 1764 responder recognizes that processing of a request will take longer 1765 than 5 seconds, it SHOULD send a 100 response as soon as possible. It 1766 SHOULD continue sending a 100 response every 5 seconds thereafter 1767 until it is ready to send the final response to the requestor. After 1768 sending a 100 response, the receiver MUST send a final response 1769 indicating the success or failure of the request. 1771 A requestor SHOULD wait at least 10 seconds for a response before 1772 concluding that the responder will not be responding to its request. 1773 After receiving a 100 response, the requestor SHOULD continue waiting 1774 for further responses. If more than 10 seconds elapses without 1775 receiving any response, the requestor MAY assume the responder is 1776 unresponsive and abort the connection. 1778 A requestor SHOULD wait longer than 10 seconds for a response if it 1779 is experiencing significant transport delays on its connection to the 1780 responder. The requestor is capable of determining the RTT using the 1781 Timestamp header (section 14.44) in any RTSP request. 1783 9.5 Use of IPv6 1785 This specification has been updated so that it supports IPv6. 1786 However this support was not present in RFC 2326 therefore some 1787 interoperability issues exist. A RFC 2326 implementation can support 1788 IPv6 as long as no explicit IPv6 addresses are used within RTSP 1789 messages. This require that any RTSP URI pointing at a IPv6 host 1790 needs to use fully qualified domain name and not an IPv6 address. 1791 Further the Transport header can not use the parameters source and 1792 destination. 1794 Implementations according to this specification MUST understand IPv6 1795 addresses in URIs, and headers. By this requirement the feature-tag 1796 "play.basic" can be used to determine that a server or client is 1797 capable of handling IPv6 within RTSP. 1799 10 Capability Handling 1801 This section describes the capability handling mechanism available in 1802 RTSP which allows RTSP to be extended. Extensions to this version of 1803 the protocol are basically done in two ways. First, new headers can 1804 be added. Secondly, new methods can be added. The capability handling 1805 mechanism is designed to handle both cases. 1807 When a method is added, the involved parties can use the OPTIONS 1808 method to discover wether it is supported. This is done by issuing a 1809 OPTIONS request to the other party. Depending on the URI it will 1810 either apply in regards to a certain media resource, the whole server 1811 in general, or simply the next hop. The OPTIONS response will contain 1812 a Public header which declares all methods supported for the 1813 indicated resource. 1815 It is not necessary to use OPTIONS to discover support of a method, 1816 the client could simply try the method. If the receiver of the 1817 request does not support the method it will respond with an error 1818 code indicating the the method is either not implemented (501) or 1819 does not apply for the resource (405). The choice between the two 1820 discovery methods depends on the requirements of the service. 1822 Feature-Tags are defined to handle functionality additions that are 1823 not new methods. Each feature-tag represents a certain block of 1824 functionality. The amount of functionality that a feature-tag 1825 represents can vary significantly. A feature-tag can for example 1826 represent the functionality a single RTSP header provides. Another 1827 feature-tag can represent much more functionality, such as the 1828 "play.basic" feature tag which represents the minimal playback 1829 implementation according to the updated specification. 1831 Feature-tags are used to determine wether the client, server or proxy 1832 supports the functionality that is necessary to achieve the desired 1833 service. To determine support of a feature-tag, several different 1834 headers can be used, each explained below: 1836 Supported: The supported header is used to determine the 1837 complete set of functionality that both client and server 1838 have. The intended usage is to determine before one needs 1839 to use a functionality that it is supported. It can be used 1840 in any method, however OPTIONS is the most suitable one as 1841 it at the same time determines all methods that are 1842 implemented. When sending a request the requestor declares 1843 all its capabilities by including all supported feature- 1844 tags. This results in that the receiver learns the 1845 requestors feature support. The receiver then includes its 1846 set of features in the response. 1848 Proxy-Supported: The Proxy-Supported header is used similar to 1849 the Supported header, but instead of giving the supported 1850 functionality of the client or server it provides both the 1851 requestor and the responder a view of what functionality 1852 the proxy chain between the two supports. Proxies are 1853 required to add this header whenever the Supported header 1854 is present, but proxies may independently of the requestor 1855 add it. 1857 Require: The Require header can be included in any request where 1858 the end-point, i.e. the client or server, is required to 1859 understand the feature to correctly perform the request. 1860 This can, for example, be a SETUP request where the server 1861 is required to understand a certain parameter to be able to 1862 set up the media delivery correctly. Ignoring this 1863 parameter would not have the desired effect and is not 1864 acceptable. Therefore the end-point receiving a request 1865 containing a Require MUST negatively acknowledge any 1866 feature that it does not understand and not perform the 1867 request. The response in cases where features are not 1868 supported are 551 (Option Not Supported). Also the 1869 features that are not supported are given in the 1870 Unsupported header in the response. 1872 Proxy-Require: This method has the same purpose and workings as 1873 Require except that it only applies to proxies and not the 1874 end-point. Features that needs to be supported by both 1875 proxies and end-point needs to be included in both the 1876 Require and Proxy-Require header. 1878 Unsupported: This header is used in a 551 error response, to 1879 indicate which feature(s) that was not supported. Such a 1880 response is only the result of the usage of the Require 1881 and/or Proxy-Require header where one or more feature where 1882 not supported. This information allows the requestor to 1883 make the best of situations as it knows which features are 1884 not supported. 1886 11 Method Definitions 1888 The method indicates what is to be performed on the resource 1889 identified by the Request-URI. The method name is case-sensitive. 1890 New methods may be defined in the future. Method names SHALL NOT 1891 start with a $ character (decimal 24) and MUST be a token as defined 1892 by the ABNF [5]. Methods are summarized in Table 7. 1894 Note on Table 7: PAUSE is recommended, but not required. 1895 For example, a fully functional server can be built to 1896 deliver live feeds, which do not support this method. 1898 If an RTSP agent does not support a particular method, it MUST return 1899 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 1900 method direction object Server req. Client req. 1901 ___________________________________________________________________ 1902 DESCRIBE C -> S P,S recommended recommended 1903 GET_PARAMETER C -> S, S -> C P,S optional optional 1904 OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt 1905 PAUSE C -> S P,S recommended recommended 1906 PING C -> S, S -> C P,S recommended optional 1907 PLAY C -> S P,S required required 1908 REDIRECT S -> C P,S optional optional 1909 SETUP C -> S S required required 1910 SET_PARAMETER C -> S, S -> C P,S optional optional 1911 TEARDOWN C -> S P,S required required 1913 Table 7: Overview of RTSP methods, their direction, and what objects 1914 (P: presentation, S: stream) they operate on. Legend: R=Respond, 1915 Sd=Send, Opt: Optional, Req: Required, Rec: Recommended 1917 NOT try this method again for the given agent / resource combination. 1919 11.1 OPTIONS 1921 The semantics of the RTSP OPTIONS method is equivalent to that of the 1922 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 1923 bi-directional, in that a client can request it to a server and vice 1924 versa. A client MUST implement the capability to send an OPTIONS 1925 request and a server or a proxy MUST implement the capability to 1926 respond to an OPTIONS request. The client, server or proxy MAY also 1927 implement the converse of their required capability. 1929 An OPTIONS request may be issued at any time. Such a request does not 1930 modify the session state. However, it may prolong the session 1931 lifespan (see below). The URI in an OPTIONS request determines the 1932 scope of the request and the corresponding response. If the Request- 1933 URI refers to a specific media resource on a given host, the scope is 1934 limited to the set of methods supported for that media resource by 1935 the indicated RTSP agent. A Request-URI with only the host address 1936 limits the scope to the specified RTSP agent's general capabilities 1937 without regard to any specific media. If the Request-URI is an 1938 asterisk ("*"), the scope is limited to the general capabilities of 1939 the next hop (i.e. the RTSP agent in direct communication with the 1940 request sender). 1942 Regardless of scope of the request, the Public header MUST always be 1943 included in the OPTIONS response listing the methods that are 1944 supported by the responding RTSP agent. In addition, if the scope of 1945 the request is limited to a media resource, the Allow header MAY be 1946 included in the response to enumerate the set of methods that are 1947 allowed for that resource. If the given resource is not available, 1948 the RTSP agent SHOULD return an appropriate response code such as 3rr 1949 or 4xx. The Supported header can be included in the request to query 1950 the set of features that are supported by the responding RTSP agent. 1952 The OPTIONS method can be used to keep an RTSP session alive. 1953 However, it is not the preferred means of session keep-alive 1954 signalling, see section 14.42. An OPTIONS request intended for 1955 keeping alive an RTSP session MUST include the Session header with 1956 the associated session ID. Such a request SHOULD also use the media 1957 or the aggregated control URI as the Request-URI. 1959 Example: 1961 C->S: OPTIONS * RTSP/1.0 1962 CSeq: 1 1963 User-Agent: PhonyClient/1.2 1964 Require: 1965 Proxy-Require: gzipped-messages 1966 Supported: play.basic 1968 S->C: RTSP/1.0 200 OK 1969 CSeq: 1 1970 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1971 Supported: play.basic, implicit-play, gzipped-messages 1972 Server: PhonyServer/1.0 1974 Note that some of the feature-tags in Require and Proxy-Require are 1975 necessarily fictional features (one would hope that we would not 1976 purposefully overlook a truly useful feature just so that we could 1977 have a strong example in this section). 1979 11.2 DESCRIBE 1981 The DESCRIBE method is used to retrieve the description of a 1982 presentation or media object from a server. The Request-URI of the 1983 DESCRIBE request identifies the media resource of interest. The 1984 client MAY include the Accept header in the request to list the 1985 description formats that it understands. The server SHALL respond 1986 with a description of the requested resource and return the 1987 description in the entity of the response. The DESCRIBE reply- 1988 response pair constitutes the media initialization phase of RTSP. 1990 Example: 1992 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 1993 CSeq: 312 1994 User-Agent: PhonyClient 1.2 1995 Accept: application/sdp, application/rtsl, application/mheg 1997 S->C: RTSP/1.0 200 OK 1998 CSeq: 312 1999 Date: 23 Jan 1997 15:35:06 GMT 2000 Server: PhonyServer 1.0 2001 Content-Type: application/sdp 2002 Content-Length: 376 2004 v=0 2005 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 2006 s=SDP Seminar 2007 i=A Seminar on the session description protocol 2008 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 2009 e=mjh@isi.edu (Mark Handley) 2010 c=IN IP4 224.2.17.12/127 2011 t=2873397496 2873404696 2012 a=recvonly 2013 m=audio 3456 RTP/AVP 0 2014 m=video 2232 RTP/AVP 31 2015 m=application 32416 UDP WB 2016 a=orient:portrait 2018 The DESCRIBE response MUST contain all media initialization 2019 information for the resource(s) that it describes. Servers SHOULD NOT 2020 use the DESCRIBE response as a means of media indirection. 2022 By forcing a DESCRIBE response to contain all media 2023 initialization for the set of streams that it describes, 2024 and discouraging the use of DESCRIBE for media indirection, 2025 any looping problems can be avoided that might have 2026 resulted from other approaches. 2028 Media initialization is a requirement for any RTSP-based system, but 2029 the RTSP specification does not dictate that this is required to be 2030 done via the DESCRIBE method. There are three ways that an RTSP 2031 client may receive initialization information: 2033 o via an RTSP DESCRIBE method 2035 o via some other protocol (HTTP, email attachment, etc.) 2036 o via some form of a user interface 2038 If a client obtains a valid description from an alternate source, the 2039 client MAY use this description for initialization purposes without 2040 issuing a DESCRIBE request for the same media. 2042 It is RECOMMENDED that minimal servers support the DESCRIBE method, 2043 and highly recommended that minimal clients support the ability to 2044 act as "helper applications" that accept a media initialization file 2045 from a user interface, and/or other means that are appropriate to the 2046 operating environment of the clients. 2048 11.3 SETUP 2050 The SETUP request for an URI specifies the transport mechanism to be 2051 used for the streamed media. The SETUP method may be used in three 2052 different cases; Create an RTSP session, add a media to a session, 2053 and change the transport parameters of already set up media stream. 2054 When in PLAY state, using SETUP to create or add media to a session 2055 when in PLAY state is unspecified. Otherwise SETUP can be used in all 2056 three states; INIT, and READY, for both purposes and in PLAY to 2057 change the transport parameters. 2059 The Transport header, see section 14.45, specifies the transport 2060 parameters acceptable to the client for data transmission; the 2061 response will contain the transport parameters selected by the 2062 server. This allows the client to enumerate in priority order the 2063 transport mechanisms and parameters acceptable to it, while the 2064 server can select the most appropriate. It is expected that the 2065 session description format used will enable the client to select a 2066 limited number possible configurations that are offered to the server 2067 to choose from. All transport parameters SHOULD be included in the 2068 Transport header, the use of other headers for this purpose is 2069 discouraged due to middle boxes such as firewalls, or NATs. 2071 For the benefit of any intervening firewalls, a client SHOULD 2072 indicate the transport parameters even if it has no influence over 2073 these parameters, for example, where the server advertises a fixed 2074 multicast address. 2076 Since SETUP includes all transport initialization 2077 information, firewalls and other intermediate network 2078 devices (which need this information) are spared the more 2079 arduous task of parsing the DESCRIBE response, which has 2080 been reserved for media initialization. 2082 In a SETUP response the server SHOULD include the Accept-Ranges 2083 header (see section 14.5 to indicate which time formats that are 2084 acceptable to use for this media resource. 2086 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 2087 CSeq: 302 2088 Transport: RTP/AVP;unicast;client_port=4588-4589, 2089 RTP/AVP/TCP;unicast;interleaved=0-1 2091 S->C: RTSP/1.0 200 OK 2092 CSeq: 302 2093 Date: 23 Jan 1997 15:35:06 GMT 2094 Server: PhonyServer 1.0 2095 Session: 47112344;timeout=60 2096 Transport: RTP/AVP;unicast;client_port=4588-4589; 2097 server_port=6256-6257;ssrc=2A3F93ED 2098 Accept-Ranges: NPT 2100 In the above example the client wants to create an RTSP session 2101 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 2102 The transport parameters acceptable to the client is either 2103 RTP/AVP/UDP (UDP per default) to be received on client port 4588 and 2104 4589 or RTP/AVP interleaved on the RTSP control channel. The server 2105 selects the RTP/AVP/UDP transport and adds the ports it will send and 2106 received RTP and RTCP from, and the RTP SSRC that will be used by the 2107 server. 2109 The server MUST generate a session identifier in response to a 2110 successful SETUP request, unless a SETUP request to a server includes 2111 a session identifier, in which case the server MUST bundle this setup 2112 request into the existing session (aggregated session) or return 2113 error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). 2114 An Aggregate control URI MUST be used to control an aggregated 2115 session. This URI MUST be different from the stream control URIs of 2116 the individual media streams included in the aggregate. The Aggregate 2117 control URI is to be specified by the session description if the 2118 server supports aggregated control and aggregated control is desired 2119 for the session. However even if aggregated control is offered the 2120 client MAY chose to not set up the session in aggregated control. If 2121 an Aggregate control URI is not specified in the session description, 2122 it is normally an indication that non-aggregated control should be 2123 used. The SETUP of media streams in an aggregate which has not been 2124 given an aggregated control URI is unspecified. 2126 While the session ID sometimes has enough information for 2127 aggregate control of a session, the Aggregate control URI 2128 is still important for some methods such as SET_PARAMETER 2129 where the control URI enables the resource in question to 2130 be easily identified. The Aggregate control URI is also 2131 useful for proxies, enabling them to route the request to 2132 the appropriate server, and for logging, where it is useful 2133 to note the actual resource that a request was operating 2134 on. Finally, presence of the Aggregate control URI allows 2135 for backwards compatibility with RFC 2326 [1]. 2137 A session will exist until it is either removed by a TEARDOWN request 2138 or is timed-out by the server. The server MAY remove a session that 2139 has not demonstrated liveness signs from the client(s) within a 2140 certain timeout period. The default timeout value is 60 seconds; the 2141 server MAY set this to a different value and indicate so in the 2142 timeout field of the Session header in the SETUP response. For 2143 further discussion see section 14.42. Signs of liveness for an RTSP 2144 session are: 2146 o Any RTSP request from a client(s) which includes a Session 2147 header with that session's ID. 2149 o If RTP is used as a transport for the underlying media 2150 streams, an RTCP sender or receiver report from the client(s) 2151 for any of the media streams in that RTSP session. RTCP Sender 2152 Reports may for example be received in sessions where the 2153 server is invited into a conference session and is as valid 2154 for keep-alive. 2156 If a SETUP request on a session fails for any reason, the session 2157 state, as well as transport and other parameters for associated 2158 streams SHALL remain unchanged from their values as if the SETUP 2159 request had never been received by the server. 2161 A client MAY issue a SETUP request for a stream that is already set 2162 up or playing in the session to change transport parameters, which a 2163 server MAY allow. If it does not allow this, it MUST respond with 2164 error 455 (Method Not Valid In This State). Reasons to support 2165 changing transport parameters, is to allow for application layer 2166 mobility and flexibility to utilize the best available transport as 2167 it becomes available. 2169 In a SETUP response for a request to change the transport parameters 2170 while in Play state, the server SHOULD include the Range to indicate 2171 from what point the new transport parameters are used. Further, if 2172 RTP is used for delivery, the server SHOULD also include the RTP-Info 2173 header to indicate from what timestamp and RTP sequence number the 2174 change has taken place. If both RTP-Info and Range is included in the 2175 response the "rtp_time" parameter and range MUST be for the 2176 corresponding time, i.e. be used in the same way as for PLAY to 2177 ensure the correct synchronization information is available. 2179 If the transport parameters change while in PLAY state results in a 2180 change of synchronization related information, for example changing 2181 RTP SSRC, the server MUST provide in the SETUP response the necessary 2182 synchronization information. However the server is RECOMMENDED to 2183 avoid changing the synchronization information if possible. 2185 11.4 PLAY 2187 The PLAY method tells the server to start sending data via the 2188 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 2189 until any outstanding SETUP requests have been acknowledged as 2190 successful. PLAY requests are valid when the session is in READY 2191 state; the use of PLAY requests when the session is in PLAY state is 2192 deprecated. A PLAY request MUST include a Session header to indicate 2193 which session the request applies to. 2195 In an aggregated session the PLAY request MUST contain an aggregated 2196 control URI. A server SHALL responde with error 460 (Only Aggregate 2197 Operation Allowed) if the client PLAY Request-URI is for one of the 2198 media. The media in an aggregate SHALL be played in sync. If a client 2199 want individual control of the media it needs to use separate RTSP 2200 sessions for each media. 2202 The PLAY request SHALL position the normal play time to the beginning 2203 of the range specified by the Range header and delivers stream data 2204 until the end of the range if given, else to the end of the media is 2205 reached. To allow for precise composition multiple ranges MAY be 2206 specified in one PLAY Request. The range values are valid if all 2207 given ranges are part of any media within the aggregate. If a given 2208 range value points outside of the media, the response SHALL be the 2209 457 (Invalid Range) error code. 2211 The below example will first play seconds 10 through 15, then, 2212 immediately following, seconds 20 to 25, and finally seconds 30 2213 through the end. 2215 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 2216 CSeq: 835 2217 Session: 12345678 2218 Range: npt=10-15, npt=20-25, npt=30- 2220 See the description of the PAUSE request for further examples. 2222 A PLAY request without a Range header is legal. It SHALL start 2223 playing a stream from the beginning (npt=0-) unless the stream has 2224 been paused. If a stream has been paused via PAUSE, stream delivery 2225 resumes at the pause point. The stream SHALL play until the end of 2226 the media. 2228 The Range header MUST NOT contain a time parameter. The usage of time 2229 in PLAY method has been deprecated. If a request with time parameter 2230 is received the server SHOULD respond with a 457 (Invalid Range) to 2231 indicate that the time parameter is not supported. 2233 Server MUST include a "Range" header in any PLAY response. The 2234 response MUST use the same format as the request's range header 2235 contained. If no Range header was in the request, the NPT time format 2236 SHOULD be used unless the client showed support for an other format 2237 more appropriate. Also for a session with live media streams the 2238 Range header MUST indicate a valid time. It is RECOMMENDED that 2239 normal play time is used, either the "now" indicator, for example 2240 "npt=now-", or the time since session start as an open interval, e.g. 2241 "npt=96.23-". An absolute time value (clock) for the corresponding 2242 time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock 2243 format SHOULD only be used if client has shown support for it. 2245 A media server only supporting playback MUST support the npt format 2246 and MAY support the clock and smpte formats. 2248 For an on-demand stream, the server MUST reply with the actual range 2249 that will be played back, i.e. for which duration any media (having 2250 content at this time) is delivered. This may differ from the 2251 requested range if alignment of the requested range to valid frame 2252 boundaries is required for the media source. Note that some media 2253 streams in an aggregate may need to be delivered from even earlier 2254 points. Also, some media format have a very long duration per 2255 individual data unit, therefore it might be necessary for the client 2256 to parse the data unit, and select where to start. 2258 Example: Single audio stream (MIDI) 2260 C->S: PLAY rtsp://example.com/audio RTSP/1.0 2261 CSeq: 836 2262 Session: 12345678 2263 Range: npt=7.05- 2265 S->C: RTSP/1.0 200 OK 2266 CSeq: 836 2267 Date: 23 Jan 1997 15:35:06 GMT 2268 Server: PhonyServer 1.0 2269 Range: npt=3.52- 2270 RTP-Info:url=rtsp://example.com/audio; 2271 seq=14783;rtptime=2345962545 2273 S->C: RTP Packet TS=2345962545 => NPT=3.52 2274 Duration: 4.15 seconds 2276 In this example the client receives the first media packet that 2277 stretches all the way up and past the requested playtime. Thus, it is 2278 the client's decision if to render to the user the time between 3.52 2279 and 7.05, or to skip it. In most cases it is probably most suitable 2280 to not render that time period. 2282 For live media sources it might be impossible to specify from which 2283 point in time all media streams carrying active content can actually 2284 be delivered. Therefore a server MAY specify a start time (or now-) 2285 in the range header, for which not all media will be available from. 2287 If no range is specified in the request, the start position SHALL 2288 still be returned in the reply. If the medias that are part of an 2289 aggregate has different lengths, the PLAY request SHALL be performed 2290 as long as the given range is valid for any media, for example the 2291 longest media. Media will be sent whenever it is available for the 2292 given play-out point. 2294 A PLAY response MAY include a header(s) carrying synchronization 2295 information. As the information necessary is dependent on the media 2296 transport format, further rules specifying the header and its usage 2297 is needed. For RTP the RTP-Info header is specified, see section 2298 14.38. 2300 After playing the desired range, the presentation is NOT 2301 automatically paused, media delivery simply stops. A PAUSE request 2302 MUST be issued before another PLAY request can be issued. 2304 Note: The above is a change resulting in a non-operability 2305 with RFC 2326 implementations. See Appendix F.1 2307 A client desiring to play the media from the beginning MUST send a 2308 PLAY request with a Range header pointing at the beginning, e.g. 2309 npt=0-. If a PLAY request is received without a Range header when 2310 media delivery has stopped at the end, the server SHOULD respond with 2311 a 457 "Invalid Range" error response. In that response the current 2312 pause point in a Range header SHALL be included. 2314 The following example plays the whole presentation starting at SMPTE 2315 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2316 headers has been broken into several lines to fit the page. 2318 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 2319 CSeq: 833 2320 Session: 12345678 2321 Range: smpte=0:10:20- 2323 S->C: RTSP/1.0 200 OK 2324 CSeq: 833 2325 Date: 23 Jan 1997 15:35:06 GMT 2326 Server: PhonyServer 1.0 2327 Range: smpte=0:10:22-0:15:45 2328 RTP-Info:url=rtsp://example.com/twister.en; 2329 seq=14783;rtptime=2345962545 2331 For playing back a recording of a live presentation, it may be 2332 desirable to use clock units: 2334 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 2335 CSeq: 835 2336 Session: 12345678 2337 Range: clock=19961108T142300Z-19961108T143520Z 2339 S->C: RTSP/1.0 200 OK 2340 CSeq: 835 2341 Date: 23 Jan 1997 15:35:06 GMT 2342 Server:PhonyServer 1.0 2343 Range: clock=19961108T142300Z-19961108T143520Z 2344 RTP-Info:url=rtsp://example.com/meeting.en; 2345 seq=53745;rtptime=484589019 2347 All range specifiers in this specification allow for ranges with 2348 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2349 request, the server treats this as a request to start/resume playback 2350 from the current pause point, ending at the end time specified in the 2351 Range header. If the pause point is located later than the given end 2352 value, a 457 (Invalid Range) response SHALL be given. 2354 The queued play functionality described in RFC 2326 [1] is removed 2355 and multiple ranges can be used to achieve a similar functionality. 2356 If a server receives a PLAY request while in the PLAY state, the 2357 server SHALL respond using the error code 455 (Method Not Valid In 2358 This State). This will signal the client that queued play are not 2359 supported. 2361 The use of PLAY for keep-alive signaling, i.e. PLAY request without a 2362 range header in PLAY state, has also been deprecated. Instead a 2363 client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A 2364 server receiving a PLAY keep alive SHALL respond with the 455 error 2365 code. 2367 11.5 PAUSE 2369 The PAUSE request causes the stream delivery to be interrupted 2370 (halted) temporarily. A PAUSE request MUST be done with the 2371 aggregated control URI for aggregated sessions, resulting in all 2372 media being halted, or the media URI for non-aggregated sessions. 2373 Any attempt to do muting of a single media with an PAUSE request in 2374 an aggregated session SHALL be responded with error 460 (Only 2375 Aggregate Operation Allowed). After resuming playback, 2376 synchronization of the tracks MUST be maintained. Any server 2377 resources are kept, though servers MAY close the session and free 2378 resources after being paused for the duration specified with the 2379 timeout parameter of the Session header in the SETUP message. 2381 Example: 2383 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2384 CSeq: 834 2385 Session: 12345678 2387 S->C: RTSP/1.0 200 OK 2388 CSeq: 834 2389 Date: 23 Jan 1997 15:35:06 GMT 2390 Range: npt=45.76- 2392 The PAUSE request MAY contain a Range header specifying when the 2393 stream or presentation is to be halted. This point is referred to as 2394 the "pause point". The time parameter in the Range MUST NOT be used. 2395 The Range header MUST contain a single value, expressed as the 2396 beginning value an open range. For example, the following clip will 2397 be played from 10 seconds through 21 seconds of the clip's normal 2398 play time, under the assumption that the PAUSE request reaches the 2399 server within 11 seconds of the PLAY request. Note that some lines 2400 has been broken in an non-correct way to fit the page: 2402 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 2403 CSeq: 834 2404 Session: 12345678 2405 Range: npt=10-30 2407 S->C: RTSP/1.0 200 OK 2408 CSeq: 834 2409 Date: 23 Jan 1997 15:35:06 GMT 2410 Server: PhonyServer 1.0 2411 Range: npt=10-30 2412 RTP-Info:url=rtsp://example.com/fizzle/audiotrack; 2413 seq=5712;rtptime=934207921, 2414 url=rtsp://example.com/fizzle/videotrack; 2415 seq=57654;rtptime=2792482193 2416 Session: 12345678 2418 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2419 CSeq: 835 2420 Session: 12345678 2421 Range: npt=21- 2423 S->C: RTSP/1.0 200 OK 2424 CSeq: 835 2425 Date: 23 Jan 1997 15:35:09 GMT 2426 Server: PhonyServer 1.0 2427 Range: npt=21- 2428 Session: 12345678 2430 The pause request becomes effective the first time the server is 2431 encountering the time point specified in any of the multiple ranges. 2432 If the Range header specifies a time outside any range from the PLAY 2433 request, the error 457 (Invalid Range) SHALL be returned. If a media 2434 unit (such as an audio or video frame) starts presentation at exactly 2435 the pause point, it is not played. If the Range header is missing, 2436 stream delivery is interrupted immediately on receipt of the message 2437 and the pause point is set to the current normal play time. However, 2438 the pause point in the media stream MUST be maintained. A subsequent 2439 PLAY request without Range header SHALL resume from the pause point 2440 and play until media end. 2442 If the server has already sent data beyond the time specified in the 2443 PAUSE request's Range header, a PLAY without range SHALL resume at 2444 the point in time specified by the PAUSE request's Range header, as 2445 it is assumed that the client has discarded data after that point. 2446 This ensures continuous pause/play cycling without gaps. 2448 The pause point after any PAUSE request SHALL be returned to the 2449 client by adding a Range header with what remains unplayed of the 2450 PLAY request's ranges, i.e. including all the remaining ranges part 2451 of multiple range specification. If one desires to resume playing a 2452 ranged request, one simply includes the Range header from the PAUSE 2453 response. Note that this server behavior was not mandated previously 2454 and servers implementing according to RFC 2326 will probably not 2455 return the range header. 2457 For example, if the server have a play request for ranges 10 to 15 2458 and 20 to 29 pending and then receives a pause request for NPT 21, it 2459 would start playing the second range and stop at NPT 21. If the pause 2460 request is for NPT 12 and the server is playing at NPT 13 serving the 2461 first play request, the server stops immediately. If the pause 2462 request is for NPT 16, the server returns a 457 error message. To 2463 prevent that the second range is played and the server stops after 2464 completing the first range, a PAUSE request for NPT 20 needs to be 2465 issued. 2467 As another example, if a server has received requests to play ranges 2468 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 2469 request for NPT=14 would take effect while the server plays the first 2470 range, with the second range effectively being ignored, assuming the 2471 PAUSE request arrives before the server has started playing the 2472 second, overlapping range. Regardless of when the PAUSE request 2473 arrives, it sets the pause point to 14. The below example messages is 2474 for the above case when the PAUSE request arrives before the first 2475 occurrence of NPT=14. 2477 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 2478 CSeq: 834 2479 Session: 12345678 2480 Range: npt=10-15, npt=13-20 2482 S->C: RTSP/1.0 200 OK 2483 CSeq: 834 2484 Date: 23 Jan 1997 15:35:06 GMT 2485 Server: PhonyServer 1.0 2486 Range: npt=10-15, npt=13-20 2487 RTP-Info:url=rtsp://example.com/fizzle/audiotrack; 2488 seq=5712;rtptime=934207921, 2489 url=rtsp://example.com/fizzle/videotrack; 2490 seq=57654;rtptime=2792482193 2492 Session: 12345678 2494 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2495 CSeq: 835 2496 Session: 12345678 2497 Range: npt=14- 2499 S->C: RTSP/1.0 200 OK 2500 CSeq: 835 2501 Date: 23 Jan 1997 15:35:09 GMT 2502 Server: PhonyServer 1.0 2503 Range: npt=14-15, npt=13-20 2504 Session: 12345678 2506 If a client issues a PAUSE request and the server acknowledges and 2507 enters the READY state, the proper server response, if the player 2508 issues another PAUSE, is still 200 OK. The 200 OK response MUST 2509 include the Range header with the current pause point, even if the 2510 PAUSE request is asking for some other pause point. See examples 2511 below: 2513 Examples: 2515 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2516 CSeq: 834 2517 Session: 12345678 2519 S->C: RTSP/1.0 200 OK 2520 CSeq: 834 2521 Session: 12345678 2522 Date: 23 Jan 1997 15:35:06 GMT 2523 Range: npt=45.76-98.36 2525 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 2526 CSeq: 835 2527 Session: 12345678 2528 Range: 86- 2530 S->C: RTSP/1.0 200 OK 2531 CSeq: 835 2532 Session: 12345678 2533 Date: 23 Jan 1997 15:35:07 GMT 2534 Range: npt=45.76-98.36 2536 11.6 TEARDOWN 2538 The TEARDOWN client to server request stops the stream delivery for 2539 the given URI, freeing the resources associated with it. A TEARDOWN 2540 request MAY be performed on either an aggregated or a media control 2541 URI. However some restrictions apply depending on the current state. 2542 The TEARDOWN request SHALL contain a Session header indicating what 2543 session the request applies to. 2545 A TEARDOWN using the aggregated control URI or the media URI in a 2546 session under non-aggregated control MAY be done in any state (Ready, 2547 and Play). A successful request SHALL result in that media delivery 2548 is immediately halted and the session state is destroyed. This SHALL 2549 be indicated through the lack of a Session header in the response. 2551 A TEARDOWN using a media URI in an aggregated session MAY only be 2552 done in Ready state. Such a request only removes the indicated media 2553 stream and associated resources from the session. This may result in 2554 that a session returns to non-aggregated control, due to that it only 2555 contains a single media after the requests completion. A session that 2556 will exist after the processing of the TEARDOWN request SHALL in the 2557 response to that TEARDOWN request contain a Session header. Thus the 2558 presence of the Session indicates to the receiver of the response if 2559 the session is still existing or has been removed. 2561 Note, the indication with the session header if sessions state remain 2562 may not be done correctly by a RFC 2326 client, but will be for any 2563 server signalling the "play.basic" tag. 2565 Example: 2567 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 2568 CSeq: 892 2569 Session: 12345678 2571 S->C: RTSP/1.0 200 OK 2572 CSeq: 892 2573 Server: PhonyServer 1.0 2575 11.7 GET_PARAMETER 2577 The GET_PARAMETER request retrieves the value of a parameter or 2578 parameters for a presentation or stream specified in the URI. If the 2579 Session header is present in a request, the value of a parameter MUST 2580 be retrieved in the specified session context. The content of the 2581 reply and response is left to the implementation. 2583 The method MAY also be used without a body (entity). If the this 2584 request is successful, i.e. a 200 OK response is received, then the 2585 keep-alive timer has been updated. Any non-required header present in 2586 such a request may or may not been processed. To allow a client to 2587 determine if any such header has been processed, it is necessary to 2588 use a feature tag and the Require header. Due to this reason it is 2589 RECOMMENDED that any parameters to be retrieved are sent in the body, 2590 rather than using any header. 2592 Example: 2594 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 2595 CSeq: 431 2596 Content-Type: text/parameters 2597 Session: 12345678 2598 Content-Length: 15 2600 packets_received 2601 jitter 2603 C->S: RTSP/1.0 200 OK 2604 CSeq: 431 2605 Content-Length: 46 2606 Content-Type: text/parameters 2608 packets_received: 10 2609 jitter: 0.3838 2611 The "text/parameters" section is only an example type for 2612 parameter body. 2614 11.8 SET_PARAMETER 2616 This method requests to set the value of a parameter or a set of 2617 parameters for a presentation or stream specified by the URI. The 2618 method MAY also be used without a body (entity). If this request is 2619 successful, i.e. a 200 OK response is received, then the keep-alive 2620 timer has been updated. Any non-required header present in such a 2621 request may or may not been processed. To allow a client to determine 2622 if any such header has been processed, it is necessary to use a 2623 feature tag and the Require header. Due to this reason it is 2624 RECOMMENDED that any parameters are sent in the body, rather than 2625 using any header. 2627 A request is RECOMMENDED to only contain a single parameter to allow 2628 the client to determine why a particular request failed. If the 2629 request contains several parameters, the server MUST only act on the 2630 request if all of the parameters can be set successfully. A server 2631 MUST allow a parameter to be set repeatedly to the same value, but it 2632 MAY disallow changing parameter values. If the receiver of the 2633 request does not understand or cannot locate a parameter, error 451 2634 (Parameter Not Understood) SHALL be used. In the case a parameter is 2635 not allowed to change, the error code is 458 (Parameter Is Read- 2636 Only). The response body SHOULD contain only the parameters that have 2637 errors. Otherwise no body SHALL be returned. 2639 Note: transport parameters for the media stream MUST only be set with 2640 the SETUP command. 2642 Restricting setting transport parameters to SETUP is for 2643 the benefit of firewalls. 2645 The parameters are split in a fine-grained fashion so that 2646 there can be more meaningful error indications. However, it 2647 may make sense to allow the setting of several parameters 2648 if an atomic setting is desirable. Imagine device control 2649 where the client does not want the camera to pan unless it 2650 can also tilt to the right angle at the same time. 2652 Example: 2654 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 2655 CSeq: 421 2656 Content-length: 20 2657 Content-type: text/parameters 2659 barparam: barstuff 2661 S->C: RTSP/1.0 451 Parameter Not Understood 2662 CSeq: 421 2663 Content-length: 10 2664 Content-type: text/parameters 2666 barparam 2668 The "text/parameters" section is only an example type for 2669 parameter. This method is intentionally loosely defined 2670 with the intention that the reply content and response 2671 content will be defined after further experimentation. 2673 11.9 REDIRECT 2675 The REDIRECT method is issued by a server to inform a client that it 2676 required to connect to another server location to access the resource 2677 indicated by the Request-URI. The presence of the Session header in a 2678 REDIRECT request indicates the scope of the request, and determines 2679 the specific semantics of the request. 2681 A REDIRECT request with a Session header has end-to-end (i.e. server 2682 to client) scope and applies only to the given session. Any 2683 intervening proxies SHOULD NOT disconnect the control channel while 2684 there are other remaining end-to-end sessions. The OPTIONAL Location 2685 header, if included in such a request, SHALL contain a complete 2686 absolute URI pointing to the resource to which the client SHOULD 2687 reconnect. Specifically, the Location SHALL NOT contain just the 2688 host and port. A client may receive a REDIRECT request with a Session 2689 header, if and only if, an end-to-end session has been established. 2691 A client may receive a REDIRECT request without a Session header at 2692 any time when it has communication or a connection established with a 2693 server. The scope of such a request is limited to the next-hop (i.e. 2694 the RTSP agent in direct communication with the server) and applies, 2695 as well, to the control connection between the next-hop RTSP agent 2696 and the server. A REDIRECT request without a Session header 2697 indicates that all sessions and pending requests being managed via 2698 the control connection MUST be redirected. The OPTIONAL Location 2699 header, if included in such a request, SHOULD contain an absolute URI 2700 with only the host address and the OPTIONAL port number of the server 2701 to which the RTSP agent SHOULD reconnect. Any intervening proxies 2702 SHOULD do all of the following in the order listed: 2704 1. respond to the REDIRECT request 2706 2. disconnect the control channel from the requesting server 2708 3. connect to the server at the given host address 2710 4. pass the REDIRECT request to each applicable client 2711 (typically those clients with an active session or an 2712 unanswered request) 2714 Note: The proxy is responsible for accepting REDIRECT responses from 2715 its clients; these responses MUST NOT be passed on to either the 2716 original server or the redirected server. 2718 The lack of a Location header in any REDIRECT request is indicative 2719 of the server no longer being able to fulfill the current request and 2720 having no alternatives for the client to continue with its normal 2721 operation. It is akin to a server initiated TEARDOWN that applies 2722 both to sessions as well as the general connection associated with 2723 that client. 2725 When the Range header is not included in a REDIRECT request, the 2726 client SHOULD perform the redirection immediately and return a 2727 response to the server. The server can consider the session as 2728 terminated and can free any associated state after it receives the 2729 successful (2xx) response. The server MAY close the signalling 2730 connection upon receiving the response and the client SHOULD close 2731 the signalling connection after sending the 2xx response. The 2732 exception to this is when the client has several sessions on the 2733 server being managed by the given signalling connection. In this 2734 case, the client SHOULD close the connection when it has received and 2735 responded to REDIRECT requests for all the sessions managed by the 2736 signalling connection. 2738 If the OPTIONAL Range header is included in a REDIRECT request, it 2739 indicates when the redirection takes effect. The range value MUST be 2740 an open ended single value, e.g. npt=59-, indicating the play out 2741 time when redirection SHALL occur. Alternatively, a range with a 2742 time= parameter indicates the wall clock time by when the redirection 2743 MUST take place. When the time= parameter is present in the range, 2744 any range value MUST be ignored even though it MUST be syntactically 2745 correct. When the indicated redirect point is reached, a client MUST 2746 issue a TEARDOWN request and SHOULD close the signalling connection 2747 after receiving a 2xx response. The normal connection considerations 2748 apply for the server. 2750 The differentiation of REDIRECT requests with and without 2751 range headers is to allow for clear and explicit state 2752 handling. As the state in the server needs to be kept until 2753 the point of redirection, the handling becomes more clear 2754 if the client is required to TEARDOWN the session at the 2755 redirect point. 2757 After a REDIRECT request has been processed, a client that wants to 2758 continue to send or receive media for the resource identified by the 2759 Request-URI will have to establish a new session with the designated 2760 host. If the URI given in the Location header is a valid resource 2761 URI, a client SHOULD issue a DESCRIBE request for the URI. 2763 Note: The media resource indicated by the Location header 2764 can be identical, slightly different or totally different. 2765 This is the reason why a new DESCRIBE request SHOULD be 2766 issued. 2768 If the Location header contains only a host address, the client MAY 2769 assume that the media on the new server is identical to the media on 2770 the old server, i.e. all media configuration information from the old 2771 session is still valid except for the host address. 2773 This example request redirects traffic for this session to the new 2774 server at the given absolute time: 2776 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 2777 CSeq: 732 2778 Location: rtsp://s2.example.com:8001 2779 Range: npt=0- ;time=19960213T143205Z 2780 Session: uZ3ci0K+Ld-M 2782 11.10 PING 2784 This method is a bi-directional mechanism for server or client 2785 liveness checking. It has no side effects. The issuer of the request 2786 MUST include a session header with the session ID of the session that 2787 is being checked for liveness. 2789 Prior to using this method, an OPTIONS method is RECOMMENDED to be 2790 issued in the direction which the PING method would be used. This 2791 method MUST NOT be used if support is not indicated by the Public 2792 header. Note: That an 501 (Not Implemented) response means that the 2793 keep-alive timer has not been updated. 2795 When a proxy is in use, PING with a * indicates a single-hop liveness 2796 check, whereas PING with an URI including an host address indicates 2797 an end-to-end liveness check. 2799 Example: 2801 C->S: PING * RTSP/1.0 2802 CSeq: 123 2803 Session:12345678 2805 S->C: RTSP/1.0 200 OK 2806 CSeq: 123 2807 Session:12345678 2809 12 Embedded (Interleaved) Binary Data 2811 In order to fulfill certain requirements on the network side, e.g. 2812 in conjunction with firewalls that block RTP traffic, it may be 2813 necessary to interleave RTSP messages and media stream data. This 2814 interleaving should generally be avoided unless necessary since it 2815 complicates client and server operation and imposes additional 2816 overhead. Also head of line blocking may cause problems. Interleaved 2817 binary data SHOULD only be used if RTSP is carried over TCP. 2819 Stream data such as RTP packets is encapsulated by an ASCII dollar 2820 sign (24 decimal), followed by a one-byte channel identifier, 2821 followed by the length of the encapsulated binary data as a binary, 2822 two-byte integer in network byte order. The stream data follows 2823 immediately afterwards, without a CRLF, but including the upper-layer 2824 protocol headers. Each $ block SHALL contain exactly one upper-layer 2825 protocol data unit, e.g., one RTP packet. 2827 0 1 2 3 2828 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 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 "$" = 24 Channel ID Length in bytes 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 : Length number of bytes of binary data : 2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 The channel identifier is defined in the Transport header with the 2836 interleaved parameter(Section 14.45). 2838 When the transport choice is RTP, RTCP messages are also interleaved 2839 by the server over the TCP connection. The usage of RTCP messages is 2840 indicated by including a range containing a second channel in the 2841 interleaved parameter of the Transport header, see section 14.45. If 2842 RTCP is used, packets SHALL be sent on the first available channel 2843 higher than the RTP channel. The channels are bi-directional and 2844 therefore RTCP traffic are sent on the second channel in both 2845 directions. 2847 RTCP is needed for synchronization when two or more streams 2848 are interleaved in such a fashion. Also, this provides a 2849 convenient way to tunnel RTP/RTCP packets through the TCP 2850 control connection when required by the network 2851 configuration and transfer them onto UDP when possible. 2853 C->S: SETUP rtsp://example.com/bar.file RTSP/1.0 2854 CSeq: 2 2855 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 2857 S->C: RTSP/1.0 200 OK 2858 CSeq: 2 2859 Date: 05 Jun 1997 18:57:18 GMT 2860 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 2861 Session: 12345678 2863 C->S: PLAY rtsp://example.com/bar.file RTSP/1.0 2864 CSeq: 3 2865 Session: 12345678 2867 S->C: RTSP/1.0 200 OK 2868 CSeq: 3 2869 Session: 12345678 2870 Date: 05 Jun 1997 18:59:15 GMT 2871 RTP-Info: url=rtsp://example.com/bar.file; 2872 seq=232433;rtptime=972948234 2874 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2875 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2876 S->C: $006{2 byte length}{"length" bytes RTCP packet} 2878 13 Status Code Definitions 2880 Where applicable, HTTP status [H10] codes are reused. Status codes 2881 that have the same meaning are not repeated here. See Table 4 for a 2882 listing of which status codes may be returned by which requests. All 2883 error messages, 4xx and 5xx MAY return a body containing further 2884 information about the error. 2886 13.1 Success 1xx 2888 13.1.1 100 Continue 2890 See, [H10.1.1]. 2892 13.2 Success 2xx 2893 13.3 Redirection 3xx 2895 The notation "3rr" indicates response codes from 300 to 399 inclusive 2896 which are meant for redirection. The response code 304 is excluded 2897 from this set, as it is not used for redirection. 2899 See [H10.3] for definition of status code 300 to 305. However 2900 comments are given for some to how they apply to RTSP. 2902 Within RTSP, redirection may be used for load balancing or 2903 redirecting stream requests to a server topologically closer to the 2904 client. Mechanisms to determine topological proximity are beyond the 2905 scope of this specification. 2907 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 2908 that they are used if necessary before a session is established, i.e. 2909 in response to DESCRIBE or SETUP. However in cases where a server is 2910 not able to send a REDIRECT request to the client, the server MAY 2911 need to resort to using 3rr responses to inform a client with a 2912 established session about the need for redirecting the session. If an 2913 3rr response is received for an request in relation to a established 2914 session, the client SHOULD send a TEARDOWN request for the session, 2915 and MAY reestablish the session using the resource indicated by the 2916 Location. 2918 If the the Location header is used in a response it SHALL contain an 2919 absolute URI pointing out the media resource the client is redirected 2920 to, the URI SHALL NOT only contain the host name. 2922 13.3.1 300 Multiple Choices 2924 See [H10.3.1] [TBW] 2926 13.3.2 301 Moved Permanently 2928 The request resource are moved permanently and resides now at the URI 2929 given by the location header. The user client SHOULD redirect 2930 automatically to the given URI. This response MUST NOT contain a 2931 message-body. 2933 13.3.3 302 Found 2935 The requested resource reside temporarily at the URI given by the 2936 Location header. The Location header MUST be included in the 2937 response. Is intended to be used for many types of temporary 2938 redirects, e.g. load balancing. It is RECOMMENDED that one set the 2939 reason phrase to something more meaningful than "Found" in these 2940 cases. The user client SHOULD redirect automatically to the given 2941 URI. This response MUST NOT contain a message-body. 2943 13.3.4 303 See Other 2945 This status code SHALL NOT be used in RTSP. However as it was allowed 2946 to use in RFC 2326 it is possible that such response may be received, 2947 in which case the behavior is undefined. 2949 13.3.5 304 Not Modified 2951 If the client has performed a conditional DESCRIBE or SETUP (see 2952 14.26) and the requested resource has not been modified, the server 2953 SHOULD send a 304 response. This response MUST NOT contain a 2954 message-body. 2956 The response MUST include the following header fields: 2958 o Date 2960 o ETag and/or Content-Location, if the header would have been 2961 sent in a 200 response to the same request. 2963 o Expires, Cache-Control, and/or Vary, if the field-value might 2964 differ from that sent in any previous response for the same 2965 variant. 2967 This response is independent for the DESCRIBE and SETUP requests. 2968 That is, a 304 response to DESCRIBE does NOT imply that the resource 2969 content is unchanged and a 304 response to SETUP does NOT imply that 2970 the resource description is unchanged. The ETag and If-Match headers 2971 may be used to link the DESCRIBE and SETUP in this manner. 2973 13.3.6 305 Use Proxy 2975 See [H10.3.6]. 2977 13.4 Client Error 4xx 2979 13.4.1 400 Bad Request 2981 The request could not be understood by the server due to malformed 2982 syntax. The client SHOULD NOT repeat the request without 2983 modifications [H10.4.1]. If the request does not have a CSeq header, 2984 the server MUST NOT include a CSeq in the response. 2986 13.4.2 405 Method Not Allowed 2988 The method specified in the request is not allowed for the resource 2989 identified by the Request-URI. The response MUST include an Allow 2990 header containing a list of valid methods for the requested resource. 2991 This status code is also to be used if a request attempts to use a 2992 method not indicated during SETUP, e.g., if a RECORD request is 2993 issued even though the mode parameter in the Transport header only 2994 specified PLAY. 2996 13.4.3 451 Parameter Not Understood 2998 The recipient of the request does not support one or more parameters 2999 contained in the request. When returning this error message the 3000 sender SHOULD return a entity body containing the offending 3001 parameter(s). 3003 13.4.4 452 reserved 3005 This error code was removed from RFC 2326 [1] and is obsolete. 3007 13.4.5 453 Not Enough Bandwidth 3009 The request was refused because there was insufficient bandwidth. 3010 This may, for example, be the result of a resource reservation 3011 failure. 3013 13.4.6 454 Session Not Found 3015 The RTSP session identifier in the Session header is missing, 3016 invalid, or has timed out. 3018 13.4.7 455 Method Not Valid in This State 3020 The client or server cannot process this request in its current 3021 state. The response SHOULD contain an Allow header to make error 3022 recovery easier. 3024 13.4.8 456 Header Field Not Valid for Resource 3026 The server could not act on a required request header. For example, 3027 if PLAY contains the Range header field but the stream does not allow 3028 seeking. This error message may also be used for specifying when the 3029 time format in Range is impossible for the resource. In that case the 3030 Accept-Ranges header SHOULD be returned to inform the client of which 3031 format(s) that are allowed. 3033 13.4.9 457 Invalid Range 3035 The Range value given is out of bounds, e.g., beyond the end of the 3036 presentation. 3038 13.4.10 458 Parameter Is Read-Only 3040 The parameter to be set by SET_PARAMETER can be read but not 3041 modified. When returning this error message the sender SHOULD return 3042 a entity body containing the offending parameter(s). 3044 13.4.11 459 Aggregate Operation Not Allowed 3046 The requested method may not be applied on the URI in question since 3047 it is an aggregate (presentation) URI. The method may be applied on a 3048 media URI. 3050 13.4.12 460 Only Aggregate Operation Allowed 3052 The requested method may not be applied on the URI in question since 3053 it is not an aggregate control (presentation) URI. The method may be 3054 applied on the aggregate control URI. 3056 13.4.13 461 Unsupported Transport 3058 The Transport field did not contain a supported transport 3059 specification. 3061 13.4.14 462 Destination Unreachable 3063 The data transmission channel could not be established because the 3064 client address could not be reached. This error will most likely be 3065 the result of a client attempt to place an invalid Destination 3066 parameter in the Transport field. 3068 13.4.15 470 Connection Authorization Required 3070 The secured connection attempt need user or client authorization 3071 before proceeding. The next hops certificate is included in this 3072 response in the Accept-Credentials header. 3074 13.4.16 471 Connection Credentials not accepted 3076 When performing a secure connection over multiple connections, a 3077 intermediary has refused to connect to the next hop and carry out the 3078 request due to unacceptable credentials for the used policy. 3080 13.5 Server Error 5xx 3082 13.5.1 551 Option not supported 3084 A feature-tag given in the Require or the Proxy-Require fields was 3085 not supported. The Unsupported header SHOULD be returned stating the 3086 feature for which there is no support. 3088 14 Header Field Definitions 3090 method direction object acronym Body 3091 _________________________________________________ 3092 DESCRIBE C -> S P,S DES r 3093 GET_PARAMETER C -> S, S -> C P,S GPR R,r 3094 OPTIONS C -> S P,S OPT 3095 S -> C 3096 PAUSE C -> S P,S PSE 3097 PING C -> S, S -> C P,S PNG 3098 PLAY C -> S P,S PLY 3099 REDIRECT S -> C P,S RDR 3100 SETUP C -> S S STP 3101 SET_PARAMETER C -> S, S -> C P,S SPR R,r 3102 TEARDOWN C -> S P,S TRD 3104 Table 8: Overview of RTSP methods, their direction, and what objects 3105 (P: presentation, S: stream) they operate on. Body notes if a method 3106 is allowed to carry body and in which direction, R = Request, 3107 r=response. Note: It is allowed for all error messages 4xx and 5xx to 3108 have a body 3110 The general syntax for header fields is covered in Section 4.2 This 3111 section lists the full set of header fields along with notes on 3112 meaning, and usage. The syntax definition for headers are present in 3113 section 18.2.3. Throughout this section, we use [HX.Y] to refer to 3114 Section X.Y of the current HTTP/1.1 specification RFC 2616 [4]. 3115 Examples of each header field are given. 3117 Information about header fields in relation to methods and proxy 3118 processing is summarized in Tables 9, 10, 11, and 12. 3120 The "where" column describes the request and response types in which 3121 the header field can be used. Values in this column are: 3123 R: header field may only appear in requests; 3125 r: header field may only appear in responses; 3127 2xx, 4xx, etc.: A numerical value or range indicates response 3128 codes with which the header field can be used; 3130 c: header field is copied from the request to the response. 3132 An empty entry in the "where" column indicates that the header field 3133 may be present in all requests and responses. 3135 The "proxy" column describes the operations a proxy may perform on a 3136 header field. An empty proxy column indicates that the proxy SHALL 3137 NOT do any changes to that header, all allowed operations are 3138 explicitly stated: 3140 a: A proxy can add or concatenate the header field if not 3141 present. 3143 m: A proxy can modify an existing header field value. 3145 d: A proxy can delete a header field value. 3147 r: A proxy needs to be able to read the header field, and thus 3148 this header field cannot be encrypted. 3150 The rest of the columns relate to the presence of a header field in a 3151 method. The method names when abbreviated, are according to table 8: 3153 c: Conditional; requirements on the header field depend on the 3154 context of the message. 3156 m: The header field is mandatory. 3158 m*: The header field SHOULD be sent, but clients/servers need to 3159 be prepared to receive messages without that header field. 3161 o: The header field is optional. 3163 *: The header field is SHALL be present if the message body is 3164 not empty. See sections 14.16, 14.18 and 4.3 for details. 3166 -: The header field is not applicable. 3168 "Optional" means that a Client/Server MAY include the header field in 3169 a request or response. The Client/Server behavior when receiving such 3170 headers varies, for some it may ignore the header field, in other 3171 case it is request to process the header. This is regulated by the 3172 method and header descriptions. Example of such headers that require 3173 processing are the Require and Proxy-Require header fields discussed 3174 in 14.37 and 14.31. A "mandatory" header field MUST be present in a 3175 request, and MUST be understood by the Client/Server receiving the 3176 request. A mandatory response header field MUST be present in the 3177 response, and the header field MUST be understood by the 3178 Client/Server processing the response. "Not applicable" means that 3179 the header field MUST NOT be present in a request. If one is placed 3180 in a request by mistake, it MUST be ignored by the Client/Server 3181 receiving the request. Similarly, a header field labeled "not 3182 applicable" for a response means that the Client/Server MUST NOT 3183 place the header field in the response, and the Client/Server MUST 3184 ignore the header field in the response. 3186 A Client/Server SHOULD ignore extension header parameters that are 3187 not understood. 3189 The From, Location, and RTP-Info header fields contain an URI. If the 3190 URI contains a comma, or semicolon, the URI MUST be enclosed in 3191 double quotas ("). Any URI parameters are contained within these 3192 quotas. If the URI is not enclosed in double quotas, any semicolon- 3193 delimited parameters are header-parameters, not URI parameters. 3195 14.1 Accept 3197 The Accept request-header field can be used to specify certain 3198 presentation description content types which are acceptable for the 3199 response. 3201 The "level" parameter for presentation descriptions is 3202 properly defined as part of the MIME type registration, not 3203 here. 3205 See [H14.1] for syntax. 3207 Example of use: 3209 Accept: application/rtsl q=1.0, application/sdp 3211 14.2 Accept-Credentials 3213 The Accept-Credentials header is a request header used to indicate to 3214 any trusted intermediary how to handle further secured connections to 3215 proxies or servers. See section 17 for the usage of this header. It 3216 SHALL only be included in client to server requests. 3218 In a request the header SHALL contain the method (User, Proxy, or 3219 Any) for approving credentials selected by the requestor. The method 3220 SHALL NOT be changed by any proxy. If the method is "User" the header 3221 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3222 _________________________________________________________________ 3223 Accept R o - - - - - 3224 Accept-Credentials R r o o o o o o 3225 Accept-Encoding R r o - - - - - 3226 Accept-Language R r o - - - - - 3227 Accept-Ranges r r - - o - - - 3228 Accept-Ranges 456 r - - - o o - 3229 Allow r - o - - - - 3230 Allow 405 m m m m m m 3231 Authorization R o o o o o o 3232 Bandwidth R o o o o - - 3233 Blocksize R o - o o - - 3234 Cache-Control r - - o - - - 3235 Connection o o o o o o 3236 Connection-Credentials 470,407 ar o o o o o o 3237 Content-Base r o - - - - - 3238 Content-Base 4xx o o o o o o 3239 Content-Encoding R r - - - - - - 3240 Content-Encoding r r o - - - - - 3241 Content-Encoding 4xx r o o o o o o 3242 Content-Language R r - - - - - - 3243 Content-Language r r o - - - - - 3244 Content-Language 4xx r o o o o o o 3245 Content-Length r r * - - - - - 3246 Content-Length 4xx r * * * * * * 3247 Content-Location r o - - - - - 3248 Content-Location 4xx o o o o o o 3249 Content-Type r * - - - - - 3250 Content-Type 4xx * * * * * * 3251 CSeq Rc m m m m m m 3252 Date am o o o o o o 3253 ETag r r o - o - - - 3254 Expires r r o - - - - - 3255 From R r o o o o o o 3256 Host - - - - - - 3257 If-Match R r - - o - - - 3258 If-Modified-Since R r o - o - - - 3259 If-None-Match R r o - - - - - 3260 Last-Modified r r o - - - - - 3261 Location 3rr o o o o o o 3263 Table 9: Overview of RTSP header fields (A-L) related to methods 3264 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3266 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3267 _____________________________________________________________ 3268 Proxy-Authenticate 407 amr m m m m m m 3269 Proxy-Require R ar o o o o o o 3270 Proxy-Supported R amr oc oc oc oc oc oc 3271 Proxy-Supported r c c c c c c 3272 Public r admr - m* - - - - 3273 Public 501 admr m* m* m* m* m* m* 3274 Range R - - - o o - 3275 Range r - - c m* m* - 3276 Referer R o o o o o o 3277 Require R o o o o o o 3278 Retry-After 3rr,503 o o o - - - 3279 RTP-Info r - - o c - - 3280 Scale - - - o - - 3281 Session R - o o m m m 3282 Session r - c m m m o 3283 Server R - o - - - - 3284 Server r o o o o o o 3285 Speed - - - o - - 3286 Supported R o o o o o o 3287 Supported r c c c c c c 3288 Timestamp R o o o o o o 3289 Timestamp c m m m m m m 3290 Transport - - m - - - 3291 Unsupported r c c c c c c 3292 User-Agent R m* m* m* m* m* m* 3293 Vary r c c c c c c 3294 Via R amr o o o o o o 3295 Via c dr m m m m m m 3296 WWW-Authenticate 401 m m m m m m 3298 _____________________________________________________________ 3299 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3301 Table 10: Overview of RTSP header fields (P-W) related to methods 3302 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3304 contains zero or more of credentials that the client accept. Each 3305 credential SHALL consist of one URI identifying the proxy or server, 3306 and the SHA-1 [15] hash computed over that entity's DER encoded 3307 certificate [16] in Base64 [36]. 3309 Example: 3311 Header Where Proxy GPR SPR RDR PNG 3312 ______________________________________________________ 3313 Accept-Credentials R r o o o o 3314 Allow 405 m m m m 3315 Authorization R o o o o 3316 Bandwidth R - o - - 3317 Blocksize R - o - - 3318 Connection o o o - 3319 Connection-Credentials 470,407 ar o o o o 3320 Content-Base R o o - - 3321 Content-Base r o o - - 3322 Content-Base 4xx o o o - 3323 Content-Encoding R r o o - - 3324 Content-Encoding r r o o - - 3325 Content-Encoding 4xx r o o o - 3326 Content-Language R r o o - - 3327 Content-Language r r o o - - 3328 Content-Language 4xx r o o o - 3329 Content-Length R r * * - - 3330 Content-Length r r * * - - 3331 Content-Length 4xx r * * * - 3332 Content-Location R o o - - 3333 Content-Location r o o - - 3334 Content-Location 4xx o o o - 3335 Content-Type R * * - - 3336 Content-Type r * * - - 3337 Content-Type 4xx * * * - 3338 CSeq Rc m m m m 3339 Date am o o o o 3340 From R r o o o o 3341 Host - - - - 3342 Last-Modified R r - - - - 3343 Last-Modified r r o - - - 3344 Location 3rr o o o o 3345 Location R - - m - 3346 Proxy-Authenticate 407 amr m m m m 3347 Proxy-Require R ar o o o o 3348 Proxy-Supported R amr oc oc oc oc 3349 Proxy-Supported r c c c c 3350 Public 501 admr m* m* m* m* 3352 ______________________________________________________ 3353 Header Where Proxy GPR SPR RDR PNG 3355 Table 11: Overview of RTSP header fields (A-P) related to methods 3356 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. 3358 Header Where Proxy GPR SPR RDR PNG 3359 ________________________________________________ 3360 Range R - - o - 3361 Referer R o o o - 3362 Require R o o o o 3363 Retry-After 3rr,503 o o - - 3364 Scale - - - - 3365 Session R o o o m 3366 Session r c c o m 3367 Server R o o o o 3368 Server r o o - o 3369 Supported R o o o o 3370 Supported r c c c c 3371 Timestamp R o o o o 3372 Timestamp c m m m m 3373 Unsupported r c c c c 3374 User-Agent R m* m* - m* 3375 User-Agent r - - m* - 3376 Vary r c c - - 3377 Via R amr o o o o 3378 Via c dr m m m m 3379 WWW-Authenticate 401 m m m m 3381 ________________________________________________ 3382 Header Where Proxy GPR SPR RDR PNG 3384 Table 12: Overview of RTSP header fields (R-W) related to methods 3385 GET_PARAMETER, SET_PARAMETER, REDIRECT, and PING. 3387 "rtsps://server.example.com/";lurbjj5khhB0NhIuOXtt4bBRH1M= 3389 14.3 Accept-Encoding 3391 See [H14.3] 3393 14.4 Accept-Language 3395 See [H14.4]. Note that the language specified applies to the 3396 presentation description and any reason phrases, not the media 3397 content. 3399 14.5 Accept-Ranges 3401 The Accept-Ranges response-header field allows the server to indicate 3402 its acceptance of range requests and possible formats for a resource: 3404 Accept-Ranges: NPT, SMPTE 3406 This header has the same syntax as [H14.5] and the syntax is defined 3407 in 18.2.3. However, new range-units are defined. Inclusion of any of 3408 the time formats indicates acceptance by the server for PLAY and 3409 PAUSE requests with this format. The headers value is valid for the 3410 resource specified by the URI in the request, this response 3411 corresponds to. A server SHOULD use this header in SETUP responses to 3412 indicate to the client which range time formats the media supports. 3413 The header SHOULD also be included in "456" responses which is a 3414 result of use of unsupported range formats. 3416 14.6 Allow 3418 The Allow entity-header field lists the methods supported by the 3419 resource identified by the Request-URI. The purpose of this field is 3420 to strictly inform the recipient of valid methods associated with the 3421 resource. An Allow header field MUST be present in a 405 (Method Not 3422 Allowed) response. See [H14.7] for syntax definition. 3424 Example of use: 3426 Allow: SETUP, PLAY, SET_PARAMETER 3428 14.7 Authorization 3430 See [H14.8] 3432 14.8 Bandwidth 3434 The Bandwidth request-header field describes the estimated bandwidth 3435 available to the client, expressed as a positive integer and measured 3436 in bits per second. The bandwidth available to the client may change 3437 during an RTSP session, e.g., due to mobility. 3439 Example: 3441 Bandwidth: 4000 3443 14.9 Blocksize 3445 The Blocksize request-header field is sent from the client to the 3446 media server asking the server for a particular media packet size. 3447 This packet size does not include lower-layer headers such as IP, 3448 UDP, or RTP. The server is free to use a blocksize which is lower 3449 than the one requested. The server MAY truncate this packet size to 3450 the closest multiple of the minimum, media-specific block size, or 3451 override it with the media-specific size if necessary. The block size 3452 MUST be a positive decimal number, measured in octets. The server 3453 only returns an error (4xx) if the value is syntactically invalid. 3455 14.10 Cache-Control 3457 The Cache-Control general-header field is used to specify directives 3458 that MUST be obeyed by all caching mechanisms along the 3459 request/response chain. 3461 Cache directives MUST be passed through by a proxy or gateway 3462 application, regardless of their significance to that application, 3463 since the directives may be applicable to all recipients along the 3464 request/response chain. It is not possible to specify a cache- 3465 directive for a specific cache. 3467 Cache-Control should only be specified in a SETUP request and its 3468 response. Note: Cache-Control does not govern the caching of 3469 responses as for HTTP, instead it applies to the media stream 3470 identified by the SETUP request. The caching of RTSP requests are 3471 generally not cacheable, for further information see 15. Below is the 3472 description of the cache directives that can be included in the 3473 Cache-Control header. 3475 no-cache: Indicates that the media stream MUST NOT be cached 3476 anywhere. This allows an origin server to prevent caching 3477 even by caches that have been configured to return stale 3478 responses to client requests. 3480 public: Indicates that the media stream is cacheable by any 3481 cache. 3483 private: Indicates that the media stream is intended for a 3484 single user and MUST NOT be cached by a shared cache. A 3485 private (non-shared) cache may cache the media stream. 3487 no-transform: An intermediate cache (proxy) may find it useful 3488 to convert the media type of a certain stream. A proxy 3489 might, for example, convert between video formats to save 3490 cache space or to reduce the amount of traffic on a slow 3491 link. Serious operational problems may occur, however, 3492 when these transformations have been applied to streams 3493 intended for certain kinds of applications. For example, 3494 applications for medical imaging, scientific data analysis 3495 and those using end-to-end authentication all depend on 3496 receiving a stream that is bit-for-bit identical to the 3497 original media stream. Therefore, if a response includes 3498 the no-transform directive, an intermediate cache or proxy 3499 MUST NOT change the encoding of the stream. Unlike HTTP, 3500 RTSP does not provide for partial transformation at this 3501 point, e.g., allowing translation into a different 3502 language. 3504 only-if-cached: In some cases, such as times of extremely poor 3505 network connectivity, a client may want a cache to return 3506 only those media streams that it currently has stored, and 3507 not to receive these from the origin server. To do this, 3508 the client may include the only-if-cached directive in a 3509 request. If it receives this directive, a cache SHOULD 3510 either respond using a cached media stream that is 3511 consistent with the other constraints of the request, or 3512 respond with a 504 (Gateway Timeout) status. However, if a 3513 group of caches is being operated as a unified system with 3514 good internal connectivity, such a request MAY be forwarded 3515 within that group of caches. 3517 max-stale: Indicates that the client is willing to accept a 3518 media stream that has exceeded its expiration time. If 3519 max-stale is assigned a value, then the client is willing 3520 to accept a response that has exceeded its expiration time 3521 by no more than the specified number of seconds. If no 3522 value is assigned to max-stale, then the client is willing 3523 to accept a stale response of any age. 3525 min-fresh: Indicates that the client is willing to accept a 3526 media stream whose freshness lifetime is no less than its 3527 current age plus the specified time in seconds. That is, 3528 the client wants a response that will still be fresh for at 3529 least the specified number of seconds. 3531 must-revalidate: When the must-revalidate directive is present 3532 in a SETUP response received by a cache, that cache MUST 3533 NOT use the entry after it becomes stale to respond to a 3534 subsequent request without first revalidating it with the 3535 origin server. That is, the cache is required to do an 3536 end-to-end revalidation every time, if, based solely on the 3537 origin server's Expires, the cached response is stale.) 3539 proxy-revalidate: The proxy-revalidate directive has the same 3540 meaning as the must-revalidate directive, except that it 3541 does not apply to non-shared user agent caches. It can be 3542 used on a response to an authenticated request to permit 3543 the user's cache to store and later return the response 3544 without needing to revalidate it (since it has already been 3545 authenticated once by that user), while still requiring 3546 proxies that service many users to revalidate each time (in 3547 order to make sure that each user has been authenticated). 3548 Note that such authenticated responses also need the public 3549 cache control directive in order to allow them to be cached 3550 at all. 3552 max-age: When an intermediate cache is forced, by means of a 3553 max-age=0 directive, to revalidate its own cache entry, and 3554 the client has supplied its own validator in the request, 3555 the supplied validator might differ from the validator 3556 currently stored with the cache entry. In this case, the 3557 cache MAY use either validator in making its own request 3558 without affecting semantic transparency. 3560 However, the choice of validator might affect performance. 3561 The best approach is for the intermediate cache to use its 3562 own validator when making its request. If the server 3563 replies with 304 (Not Modified), then the cache can return 3564 its now validated copy to the client with a 200 (OK) 3565 response. If the server replies with a new entity and cache 3566 validator, however, the intermediate cache can compare the 3567 returned validator with the one provided in the client's 3568 request, using the strong comparison function. If the 3569 client's validator is equal to the origin server's, then 3570 the intermediate cache simply returns 304 (Not Modified). 3571 Otherwise, it returns the new entity with a 200 (OK) 3572 response. 3574 14.11 Connection 3576 See [H14.10]. The use of the connection option "close" in RTSP 3577 messages SHOULD be limited to error messages when the server is 3578 unable to recover and therefore see it necessary to close the 3579 connection. The reason is that the client has the choice of 3580 continuing using a connection indefinitely, as long as it sends valid 3581 messages. 3583 14.12 Connection-Credentials 3585 The Connection-Credentials response header is used to carry the 3586 credentials of any next hop that need to be approved by the 3587 requestor. It SHALL only be used in server to client responses. 3589 The Connection-Credentials header in an RTSP response SHALL, if 3590 included, contain the credentials information of the next hop that an 3591 intermediary needs to securely connect to. The credential MUST 3592 include the URI of the next proxy or server and the DER encoded 3593 X.509v3 [16] certificate in base64 [36]. 3595 Example: 3596 Accept-Credentials:"rtsps://proxy2.example.com/";MIIDNTCCAp6gA... 3598 14.13 Content-Base 3600 The Content-Base entity-header field may be used to specify the base 3601 URI for resolving relative URIs within the entity. 3603 Content-Base: rtsp://media.example.com/movie/twister 3605 If no Content-Base field is present, the base URI of an entity is 3606 defined either by its Content-Location (if that Content-Location URI 3607 is an absolute URI) or the URI used to initiate the request, in that 3608 order of precedence. Note, however, that the base URI of the contents 3609 within the entity-body may be redefined within that entity-body. 3611 14.14 Content-Encoding 3613 See [H14.11] 3615 14.15 Content-Language 3617 See [H14.12] 3619 14.16 Content-Length 3621 The Content-Length general-header field contains the length of the 3622 content of the method (i.e. after the double CRLF following the last 3623 header). Unlike HTTP, it MUST be included in all messages that carry 3624 content beyond the header portion of the message. If it is missing, a 3625 default value of zero is assumed. It is interpreted according to 3626 [H14.13]. 3628 14.17 Content-Location 3629 See [H14.14] 3631 14.18 Content-Type 3633 See [H14.17]. Note that the content types suitable for RTSP are 3634 likely to be restricted in practice to presentation descriptions and 3635 parameter-value types. 3637 14.19 CSeq 3639 The CSeq general-header field specifies the sequence number for an 3640 RTSP request-response pair. This field MUST be present in all 3641 requests and responses. For every RTSP request containing the given 3642 sequence number, the corresponding response will have the same 3643 number. Any retransmitted request MUST contain the same sequence 3644 number as the original (i.e. the sequence number is not incremented 3645 for retransmissions of the same request). For each new RTSP request 3646 the CSeq value SHALL be incremented by one. The initial sequence 3647 number MAY be any number, however it is RECOMMENDED to start at 1. 3648 Each sequence number series is unique between each requester and 3649 responder, i.e. the client has one series for its request to a server 3650 and the server has another when sending request to the client. Each 3651 requester and responder is identified with its network address. 3653 Example: 3655 CSeq: 239 3657 14.20 Date 3659 See [H14.18]. An RTSP message containing a body MUST include a Date 3660 header if the sending host has a clock. Servers SHOULD include a Date 3661 header in all other RTSP messages. 3663 14.21 ETag 3665 The ETag response header MAY be included in DESCRIBE or SETUP 3666 responses. The entity tag returned in a DESCRIBE response is for the 3667 included entity, while for SETUP it refers to the media resource just 3668 set up. This differentiation allows for cache validation of both 3669 session description and the media resource associated with the 3670 description. If the ETag is provided both inside the entity, e.g. 3671 within the "a=etag" attribute in SDP, and in the response message, 3672 then both tags SHALL be identical. It is RECOMMENDED that the ETag is 3673 primarily given in the RTSP response message, to ensure that caches 3674 can use the ETag without requiring content inspection. 3676 SETUP and DESCRIBE requests can be made conditional upon the ETag 3677 using the headers If-Match (Section 14.25) and If-None-Match (Section 3678 14.27). 3680 14.22 Expires 3682 The Expires entity-header field gives a date and time after which the 3683 description or media-stream should be considered stale. The 3684 interpretation depends on the method: 3686 DESCRIBE response: The Expires header indicates a date and time 3687 after which the description SHOULD be considered stale. 3689 SETUP response: The Expires header indicate a date and time 3690 after which the media stream SHOULD be considered stale. 3692 A stale cache entry may not normally be returned by a cache (either a 3693 proxy cache or an user agent cache) unless it is first validated with 3694 the origin server (or with an intermediate cache that has a fresh 3695 copy of the entity). See section 15 for further discussion of the 3696 expiration model. 3698 The presence of an Expires field does not imply that the original 3699 resource will change or cease to exist at, before, or after that 3700 time. 3702 The format is an absolute date and time as defined by HTTP-date in 3703 [H3.3]; it MUST be in RFC1123-date format: 3705 An example of its use is 3707 Expires: Thu, 01 Dec 1994 16:00:00 GMT 3709 RTSP/1.0 clients and caches MUST treat other invalid date formats, 3710 especially including the value "0", as having occurred in the past 3711 (i.e., already expired). 3713 To mark a response as "already expired," an origin server should use 3714 an Expires date that is equal to the Date header value. To mark a 3715 response as "never expires," an origin server SHOULD use an Expires 3716 date approximately one year from the time the response is sent. 3717 RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in 3718 the future. 3720 The presence of an Expires header field with a date value of some 3721 time in the future on a media stream that otherwise would by default 3722 be non-cacheable indicates that the media stream is cacheable, unless 3723 indicated otherwise by a Cache-Control header field (Section 14.10). 3725 14.23 From 3727 See [H14.22]. 3729 14.24 Host 3731 The Host HTTP request header field [H14.23] is not needed for RTSP, 3732 and SHALL NOT be sent. It SHALL be silently ignored if received. 3734 14.25 If-Match 3736 See [H14.24]. 3738 The If-Match request-header field is especially useful for ensuring 3739 the integrity of the presentation description, in both the case where 3740 it is fetched via means external to RTSP (such as HTTP), or in the 3741 case where the server implementation is guaranteeing the integrity of 3742 the description between the time of the DESCRIBE message and the 3743 SETUP message. By including the ETag given in or with the session 3744 description in a SETUP request, the client ensures that resources set 3745 up are matching the description. A SETUP request for which the ETag 3746 validation check fails, SHALL responde using 412 (Precondition 3747 Failed). 3749 This validation check is also very useful if a session has been 3750 redirected from one server to another. 3752 14.26 If-Modified-Since 3754 The If-Modified-Since request-header field is used with the DESCRIBE 3755 and SETUP methods to make them conditional. If the requested variant 3756 has not been modified since the time specified in this field, a 3757 description will not be returned from the server (DESCRIBE) or a 3758 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 3759 response SHALL be returned without any message-body. 3761 An example of the field is: 3763 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 3765 14.27 If-None-Match 3767 See [H14.26]. 3769 This request header can be used with entity tags to make DESCRIBE 3770 requests conditional. A new session description is retrieved only if 3771 another entity than the already available would be included. If the 3772 entity available for delivery is matching the one the client already 3773 has, then a 304 (Not Modified) response is given. 3775 14.28 Last-Modified 3777 The Last-Modified entity-header field indicates the date and time at 3778 which the origin server believes the presentation description or 3779 media stream was last modified. See [H14.29]. For the methods 3780 DESCRIBE, the header field indicates the last modification date and 3781 time of the description, for SETUP that of the media stream. 3783 14.29 Location 3785 See [H14.30]. 3787 14.30 Proxy-Authenticate 3789 See [H14.33]. 3791 14.31 Proxy-Require 3793 The Proxy-Require request-header field is used to indicate proxy- 3794 sensitive features that MUST be supported by the proxy. Any Proxy- 3795 Require header features that are not supported by the proxy MUST be 3796 negatively acknowledged by the proxy to the client using the 3797 Unsupported header. The proxy SHALL use the 551 (Option Not 3798 Supported) status code in the response. Any feature tag included in 3799 the Proxy-Require does not apply to the end-point (server or client). 3800 To ensure that a feature is supported by both proxies and servers the 3801 tag needs to be included in also a Require header. 3803 See Section 14.37 for more details on the mechanics of this message 3804 and a usage example. 3806 Example of use: 3808 Proxy-Require: play.basic 3810 14.32 Proxy-Supported 3812 The Proxy-Supported header field enumerates all the extensions 3813 supported by the proxy using feature tags. The header carries the 3814 intersection of extensions supported by the forwarding proxies. The 3815 Proxy-Supported header MAY be included in any request by a proxy. It 3816 SHALL be added by any proxy if the Supported header is present in a 3817 request. When present in a request, the receiver MUST in the response 3818 copy the received Proxy-Supported header. 3820 The Proxy-Supported header field contains a list of feature-tags 3821 applicable to proxies, as described in Section 3.7. The list are the 3822 intersection of all feature-tags understood by the proxies. To 3823 achieve an intersection, the proxy adding the Proxy-Supported header 3824 includes all proxy feature-tags it understands. Any proxy receiving a 3825 request with the header, checks the list and removes any feature tag 3826 it do not support. A Proxy-Supported header present in the response 3827 SHALL NOT be touched by the proxies. 3829 Example: 3831 C->P1: OPTIONS rtsp://example.com/ RTSP/1.0 3832 Supported: foo, bar, blech 3834 P1->P2: OPTIONS rtsp://example.com/ RTSP/1.0 3835 Supported: foo, bar, blech 3836 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 3837 Via: 1.0 prox1.example.com 3839 P2->S: OPTIONS rtsp://example.com/ RTSP/1.0 3840 Supported: foo, bar, blech 3841 Proxy-Supported: proxy-foo, proxy-blech 3842 Via: 1.0 prox1.example.com, 1.0 prox2.example.com 3844 S->C: RTSP/1.0 200 OK 3845 Supported: foo, bar, baz 3846 Proxy-Supported: proxy-foo, proxy-blech 3847 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3848 Via: 1.0 prox1.example.com, 1.0 prox2.example.com 3850 14.33 Public 3852 The Public response header field lists the set of methods supported 3853 by the response sender. This header applies to the general 3854 capabilities of the sender and its only purpose is to indicate the 3855 sender's capabilities to the recipient. The methods listed may or may 3856 not be applicable to the Request-URI; the Allow header field (section 3857 14.7) MAY be used to indicate methods allowed for a particular URI. 3859 Example of use: 3861 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3863 In the event that there are proxies between the sender and the 3864 recipient of a response, each intervening proxy MUST modify the 3865 Public header field to remove any methods that are not supported via 3866 that proxy. The resulting Public header field will contain an 3867 intersection of the sender's methods and the methods allowed through 3868 by the intervening proxies. 3870 In general proxies should allow all methods to 3871 transparently pass through from the sending RTSP agent to 3872 the receiving RTSP agent, but there may be cases where this 3873 is not desirable for a given proxy. Modification of the 3874 Public response header field by the intervening proxies 3875 ensures that the request sender gets an accurate response 3876 indicating the methods that can be used on the target agent 3877 via the proxy chain. 3879 14.34 Range 3881 The Range request and response header field specifies a range of 3882 time. The header is used in PLAY request to indicate the range of 3883 time the client desires the server to play back. The Range header in 3884 a PLAY indicates what range of time that is actually being played. In 3885 a SETUP response the header MAY be used, to ensure correct 3886 synchronization information after changes of transport parameters. 3888 The range can be specified in a number of units. This specification 3889 defines the smpte (Section 3.4), npt (Section 3.5), and clock 3890 (Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are 3891 normally not meaningful, and the behavior is unspecified, but they 3892 and other extended units MAY be used. Servers supporting the Range 3893 header MUST understand the NPT range format and SHOULD understand the 3894 SMPTE range format. If the Range header is given in a time format 3895 that is not understood, the recipient should return 456 (Header Field 3896 Not Valid for Resource) and include a Accept-Ranges header indicating 3897 which time format that is supported for this resource. 3899 The header MAY contain a time parameter in UTC, specifying the time 3900 at which the operation is to be made effective. This functionality 3901 SHALL only be used with the REDIRECT method. 3903 Ranges are half-open intervals, including the first point, but 3904 excluding the second point. In other words, a range of A-B starts 3905 exactly at time A, but stops just before B. Only the start time of a 3906 media unit such as a video or audio frame is relevant. As an example, 3907 assume that video frames are generated every 40 ms. A range of 3908 10.0-10.1 would include a video frame starting at 10.0 or later time 3909 and would include a video frame starting at 10.08, even though it 3910 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 3911 would exclude the frame at 10.08. 3913 Example: 3915 Range: clock=19960213T143205Z-;time=19970123T143720Z 3917 The notation is similar to that used for the HTTP/1.1 [4] 3918 byte-range header. It allows clients to select an excerpt 3919 from the media object, and to play from a given point to 3920 the end as well as from the current location to a given 3921 point. The start of playback can be scheduled for any time 3922 in the future, although a server may refuse to keep server 3923 resources for extended idle periods. 3925 By default, range intervals increase, where the second point is 3926 larger than the first point. 3928 Example: 3930 Range: npt=10-15 3932 However, range intervals can also decrease if the Scale header (see 3933 section 14.39) indicates a negative scale value. For example, this 3934 would be the case when a playback in reverse is desired. 3936 Example: 3938 Scale: -1 3939 Range: npt=15-10 3941 Decreasing ranges are still half open intervals as described above. 3942 Thus, For range A-B, A is closed and B is open. In the above example, 3943 15 is closed and 10 is open. An exception to this rule is the case 3944 when B=0 in a decreasing range. In this case, the range is closed on 3945 both ends, as otherwise there would be no way to reach 0 on a reverse 3946 playback. 3948 Example: 3950 Scale: -1 3951 Range: npt=15-0 3953 In this range both 15 and 0 are closed. 3955 A decreasing range interval without a corresponding negative Scale 3956 header is not valid. 3958 14.35 Referer 3960 See [H14.36]. The URI refers to that of the presentation description, 3961 typically retrieved via HTTP. 3963 14.36 Retry-After 3965 See [H14.37]. 3967 14.37 Require 3969 The Require request-header field is used by clients or servers to 3970 ensure that the other end-point supports features that are required 3971 in respect to this request. It can also be used to query if the other 3972 end-point supports certain features, however the use of the Supported 3973 (Section 14.43) is much more effective in this purpose. The server 3974 MUST respond to this header by using the Unsupported header to 3975 negatively acknowledge those feature-tags which are NOT supported. 3976 The response SHALL use the error code 551 (Option Not Supported). 3977 This header does not apply to proxies, for the same functionality in 3978 respect to proxies see, header Proxy-Require (Section 14.31). 3980 This is to make sure that the client-server interaction 3981 will proceed without delay when all features are understood 3982 by both sides, and only slow down if features are not 3983 understood (as in the example below). For a well-matched 3984 client-server pair, the interaction proceeds quickly, 3985 saving a round-trip often required by negotiation 3986 mechanisms. In addition, it also removes state ambiguity 3987 when the client requires features that the server does not 3988 understand. 3990 Example: 3992 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 3993 CSeq: 302 3994 Require: funky-feature 3995 Funky-Parameter: funkystuff 3997 S->C: RTSP/1.0 551 Option not supported 3998 CSeq: 302 3999 Unsupported: funky-feature 4001 In this example, "funky-feature" is the feature-tag which indicates 4002 to the client that the fictional Funky-Parameter field is required. 4003 The relationship between "funky-feature" and Funky-Parameter is not 4004 communicated via the RTSP exchange, since that relationship is an 4005 immutable property of "funky-feature" and thus should not be 4006 transmitted with every exchange. 4008 Proxies and other intermediary devices SHALL ignore this header. If a 4009 particular extension requires that intermediate devices support it, 4010 the extension should be tagged in the Proxy-Require field instead 4011 (see Section 14.31). 4013 14.38 RTP-Info 4015 The RTP-Info response-header field is used to set RTP-specific 4016 parameters in the PLAY response. These parameters correspond to the 4017 synchronization source identified by the first value of the ssrc 4018 parameter of the Transport response header in the SETUP response. For 4019 streams using RTP as transport protocol the RTP-Info header SHOULD be 4020 part of a 200 response to PLAY. 4022 The exclusion of the RTP-Info in a PLAY response for RTP 4023 transported media will result in that a client needs to 4024 synchronize the media streams using RTCP. This may have 4025 negative impact as the RTCP can be lost, and does not need 4026 to be particulary timely in their arrival. Also 4027 functionality as informing the client from which packet a 4028 seek has occurred is affected. 4030 The RTP-Info MAY also be included in SETUP responses to provide 4031 synchronization information when changing transport parameters, see 4032 11.3. 4034 The header can carry the following parameters: 4036 url: Indicates the stream URI which for which the following RTP 4037 parameters correspond, this URI MUST be the same used in 4038 the SETUP request for this media stream. Any relative URI 4039 SHALL use the Request-URI as base URI. 4041 seq: Indicates the sequence number of the first packet of the 4042 stream that is direct result of the request. This allows 4043 clients to gracefully deal with packets when seeking. The 4044 client uses this value to differentiate packets that 4045 originated before the seek from packets that originated 4046 after the seek. Note that a client may not receive the 4047 packet with the expressed sequence number, and instead 4048 packets with a higher sequence number, due to packet loss 4049 or reordering. 4051 rtptime: Indicates the RTP timestamp corresponding to the time 4052 value in the Range response header. (Note: For aggregate 4053 control, a particular stream may not actually generate a 4054 packet for the Range time value returned or implied. Thus, 4055 there is no guarantee that the packet with the sequence 4056 number indicated by seq actually has the timestamp 4057 indicated by rtptime.) The client uses this value to 4058 calculate the mapping of RTP time to NPT. 4060 A mapping from RTP timestamps to NTP timestamps (wall 4061 clock) is available via RTCP. However, this 4062 information is not sufficient to generate a mapping 4063 from RTP timestamps to NPT. Furthermore, in order to 4064 ensure that this information is available at the 4065 necessary time (immediately at startup or after a 4066 seek), and that it is delivered reliably, this mapping 4067 is placed in the RTSP control channel. 4069 In order to compensate for drift for long, uninterrupted 4070 presentations, RTSP clients should additionally map NPT to 4071 NTP, using initial RTCP sender reports to do the mapping, 4072 and later reports to check drift against the mapping. 4074 Additionally, the RTP-Info header parameter fields only apply to a 4075 single SSRC within a stream (the first SSRC reported in the transport 4076 response header; see section 14.45). If there are multiple 4077 synchronization sources (SSRCs) present within a RTP session 4078 transmitting media, RTCP needs to be used to map RTP and NTP 4079 timestamps for those sources, for both synchronization and drift- 4080 checking. Due to backwards compatibility reasons these shortcomings 4081 can't be fixed without defining a new header, which is for future 4082 work if needed. 4084 Additional constraint: The syntax element "safe-url" (see section 4085 18.2.3) MUST NOT contain the semicolon (";") or comma (",") 4086 characters. The quoted-url form SHOULD only be used when an URI does 4087 not meet the safe-url constraint, in order to ensure compatibility 4088 with implementations conformant to RFC 2326 [1]. 4090 Example: 4092 RTP-Info: url=rtsp://example.com/bar.avi/streamid=0;seq=45102, 4093 url=rtsp://example.com/bar.avi/streamid=1;seq=30211 4095 14.39 Scale 4097 A scale value of 1 indicates normal play at the normal forward 4098 viewing rate. If not 1, the value corresponds to the rate with 4099 respect to normal viewing rate. For example, a ratio of 2 indicates 4100 twice the normal viewing rate ("fast forward") and a ratio of 0.5 4101 indicates half the normal viewing rate. In other words, a ratio of 2 4102 has normal play time increase at twice the wallclock rate. For every 4103 second of elapsed (wallclock) time, 2 seconds of content will be 4104 delivered. A negative value indicates reverse direction. For certain 4105 media transports this may require certain considerations to work 4106 consistent, see section B.1 for description on how RTP handles this. 4108 Unless requested otherwise by the Speed parameter, the data rate 4109 SHOULD not be changed. Implementation of scale changes depends on the 4110 server and media type. For video, a server may, for example, deliver 4111 only key frames or selected key frames. For audio, it may time-scale 4112 the audio while preserving pitch or, less desirably, deliver 4113 fragments of audio. 4115 The server should try to approximate the viewing rate, but may 4116 restrict the range of scale values that it supports. The response 4117 MUST contain the actual scale value chosen by the server. 4119 If the server does not implement the possibility to scale, it will 4120 not return a Scale header. A server supporting Scale operations for 4121 PLAY SHALL indicate this with the use of the "play.scale" feature- 4122 tags. 4124 When indicating a negative scale for a reverse playback, the Range 4125 header MUST indicate a decreasing range as described in section 4126 14.34. 4128 Example of playing in reverse at 3.5 times normal rate: 4130 Scale: -3.5 4131 Range: npt=15-10 4133 14.40 Speed 4135 The Speed request-header field requests the server to deliver data to 4136 the client at a particular speed, contingent on the server's ability 4137 and desire to serve the media stream at the given speed. 4138 Implementation by the server is OPTIONAL. The default is the bit rate 4139 of the stream. 4141 The parameter value is expressed as a decimal ratio, e.g., a value of 4142 2.0 indicates that data is to be delivered twice as fast as normal. A 4143 speed of zero is invalid. All speeds may not be possible to support. 4144 Therefore the actual used speed MUST be included in the response. The 4145 lack of a response header is indication of lack of support from the 4146 server of this functionality. Support of the speed functionality are 4147 indicated by the "play.speed" featuretag. 4149 Example: 4151 Speed: 2.5 4153 Use of this field changes the bandwidth used for data delivery. It is 4154 meant for use in specific circumstances where preview of the 4155 presentation at a higher or lower rate is necessary. Implementors 4156 should keep in mind that bandwidth for the session may be negotiated 4157 beforehand (by means other than RTSP), and therefore re-negotiation 4158 may be necessary. When data is delivered over UDP, it is highly 4159 recommended that means such as RTCP be used to track packet loss 4160 rates. If the data transport is performed over public best-effort 4161 networks the sender SHOULD perform congestion control of the 4162 stream(s). This can result in that the communicated speed is 4163 impossible to maintain. 4165 14.41 Server 4167 See [H14.38], however the header syntax is corrected in section 4168 18.2.3. 4170 14.42 Session 4172 The Session request-header and response-header field identifies an 4173 RTSP session. An RTSP session is created by the server as a result of 4174 a successful SETUP request and in the response the session identifier 4175 is given to the client. The RTSP session exist until destroyed by a 4176 TEARDOWN or timed out by the server. 4178 The session identifier is chosen by the server (see Section 3.3) and 4179 MUST be returned in the SETUP response. Once a client receives a 4180 session identifier, it SHALL be included in any request related to 4181 that session. This means that the Session header MUST be included in 4182 a request using the following methods: PLAY, PAUSE, PING, and 4183 TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, 4184 GET_PARAMETER, and REDIRECT, and SHALL NOT be included in DESCRIBE. 4185 In an RTSP response the session header SHALL be included in methods, 4186 SETUP, PING, PLAY, and PAUSE, and MAY be included in methods, 4187 TEARDOWN, and REDIRECT, and if included in the request of the 4188 following methods it SHALL also be included in the response, OPTIONS, 4189 GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in 4190 DESCRIBE. 4192 Note that RFC 2326 servers and client may in some cases not include 4193 or return a Session header when expected according to the above text. 4194 Any client or server is RECOMMENDED to be forgiving of this error if 4195 possible (which it is in many cases). 4197 The timeout parameter MAY be included in a SETUP response, and SHALL 4198 NOT be included in requests. The server uses it to indicate to the 4199 client how long the server is prepared to wait between RTSP commands 4200 or other signs of life before closing the session due to lack of 4201 activity (see below and Section A). The timeout is measured in 4202 seconds, with a default of 60 seconds (1 minute). The length of the 4203 session timeout SHALL NOT be changed in a established session. 4205 The mechanisms for showing liveness of the client is, any RTSP 4206 request with a Session header, if RTP & RTCP is used an RTCP message, 4207 or through any other used media protocol capable of indicating 4208 liveness of the RTSP client. It is RECOMMENDED that a client does not 4209 wait to the last second of the timeout before trying to send a 4210 liveness message. The RTSP message may be lost or when using reliable 4211 protocols, such as TCP, the message may take some time to arrive 4212 safely at the receiver. To show liveness between RTSP request issued 4213 to accomplish other things, the following mechanisms can be used, in 4214 descending order of preference: 4216 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 4217 RTCP is used to report transport statistics, it SHALL also 4218 work as keep alive. The server can determine the client by 4219 used network address and port together with the fact that 4220 the client is reporting on the servers SSRC(s). A downside 4221 of using RTCP is that it only gives statistical guarantees 4222 to reach the server. However that probability is so low 4223 that it can be ignored in most cases. For example, a 4224 session with 60 seconds timeout and enough bitrate assigned 4225 to RTCP messages to send a message from client to server on 4226 average every 5 seconds. That client have for a network 4227 with 5 % packet loss, the probability to fail showing 4228 liveness sign in that session within the timeout interval 4229 of 2.4*E-16. In sessions with shorter timeout times, or 4230 much higher packet loss, or small RTCP bandwidths SHOULD 4231 also use any of the mechanisms below. 4233 PING: The use of the PING method is the best of the RTSP based 4234 methods. It has no other effects than updating the timeout 4235 timer. In that way it will be a minimal message, that also 4236 does not cause any extra processing for the server. The 4237 downside is that it may not be implemented. A client SHOULD 4238 use a OPTIONS request to verify support of the PING at the 4239 server. It is also possible to detect support by sending a 4240 PING to the server. If a 200 (OK) message is received the 4241 server supports it. In case a 501 (Not Implemented) is 4242 received it does not support PING and there is no meaning 4243 in continue trying. Also the reception of a error message 4244 will also mean that the liveness timer has not been 4245 updated. 4247 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 4248 SHOULD be included. This method is basically as good as 4249 PING, however the implementation support of the method is 4250 today limited. The same considerations as for PING apply 4251 regarding checking of support in server and proxies. 4253 OPTIONS: This method does also work. However it causes the 4254 server to perform unnecessary processing and result in 4255 bigger responses than necessary for the task. The reason 4256 for this is that the Public is always included creating 4257 overhead. 4259 Note that a session identifier identifies an RTSP session across 4260 transport sessions or connections. RTSP requests for a given session 4261 can use different URIs (Presentation and media URIs). Note, that 4262 there are restrictions depending on the session which URIs that are 4263 acceptable for a given method. However, multiple "user" sessions for 4264 the same URI from the same client will require use of different 4265 session identifiers. 4267 The session identifier is needed to distinguish several 4268 delivery requests for the same URI coming from the same 4269 client. 4271 The response 454 (Session Not Found) SHALL be returned if the session 4272 identifier is invalid. 4274 14.43 Supported 4276 The Supported header field enumerates all the extensions supported by 4277 the client or server using feature tags. The header carries the 4278 extensions supported by the message sending entity. The Supported 4279 header MAY be included in any request. When present in a request, 4280 the receiver MUST respond with its corresponding Supported header. 4281 Note, also in 4xx and 5xx responses is the supported header included. 4283 The Supported header field contains a list of feature-tags, described 4284 in Section 3.7, that are understood by the client or server. 4286 Example: 4288 C->S: OPTIONS rtsp://example.com/ RTSP/1.0 4289 Supported: foo, bar, blech 4291 S->C: RTSP/1.0 200 OK 4292 Supported: bar, blech, baz 4294 14.44 Timestamp 4296 The Timestamp general-header field describes when the client sent the 4297 request to the server. The value of the timestamp is of significance 4298 only to the client and may use any timescale. The server MUST echo 4299 the exact same value and MAY, if it has accurate information about 4300 this, add a floating point number indicating the number of seconds 4301 that has elapsed since it has received the request. The timestamp is 4302 used by the client to compute the round-trip time to the server so 4303 that it can adjust the timeout value for retransmissions. It also 4304 resolves retransmission ambiguities for unreliable transport of RTSP. 4306 14.45 Transport 4308 The Transport request and response header field indicates which 4309 transport protocol is to be used and configures its parameters such 4310 as destination address, compression, multicast time-to-live and 4311 destination port for a single stream. It sets those values not 4312 already determined by a presentation description. 4314 Transports are comma separated, listed in order of preference. 4315 Parameters may be added to each transport, separated by a semicolon. 4316 The server SHOULD return a Transport response-header field in the 4317 response to indicate the values actually chosen. The Transport header 4318 field MAY also be used to change certain transport parameters. A 4319 server MAY refuse to change parameters of an existing stream. 4321 A Transport request header field MAY contain a list of transport 4322 options acceptable to the client, in the form of multiple 4323 transportspec entries. In that case, the server MUST return the 4324 single option (transport-spec) which was actually chosen. The number 4325 of transportspec entries is expected to be limited as the client will 4326 get guidance on what configurations that are possible from the 4327 presentation description. 4329 A transport-spec transport option may only contain one of any given 4330 parameter within it. Parameters may be given in any order. 4331 Additionally, it may only contain the unicast or multicast transport 4332 type parameter. Unknown transport parameters SHALL be ignored. The 4333 requester need to ensure that the responder understands the 4334 parameters through the use of feature tags and the Require header. 4336 A request or a response including a transport header with any 4337 parameter not defined in RFC 2326 SHOULD use the Require header and 4338 the "play.basic" feature tag. This is to ensure consistent behavior 4339 with the new parameters. Any parameters part of future extensions 4340 requires clarification if they are safe to ignore in accordance to 4341 this specification, or is required to be understood. If a parameter 4342 is required to be understood, then a feature tag MUST be defined and 4343 used in the Require and/or Proxy-Require headers. 4345 The Transport header field is restricted to describing a 4346 single media stream. (RTSP can also control multiple 4347 streams as a single entity.) Making it part of RTSP rather 4348 than relying on a multitude of session description formats 4349 greatly simplifies designs of firewalls. 4351 The syntax for the transport specifier is 4353 transport/profile/lower-transport. 4355 The default value for the "lower-transport" parameters is specific to 4356 the profile. For RTP/AVP, the default is UDP. 4358 There is three different methods for how to specify where the media 4359 should be delivered: 4361 o The presence of this parameter and its values indicates 4362 address and port pairs for one or more IP flow necessary for 4363 the media transport. This is an improved version of the 4364 Destination parameter. 4366 o The presence of this parameter and its value indicates what IP 4367 address the media SHALL be delivered to. This method is kept 4368 for backwards compatibility reasons, dest_addr is a better 4369 choice. 4371 o The lack of of both of the above parameters indicates that the 4372 server SHALL send media to same address for which the RTSP 4373 messages originates. 4375 The choice of method for indicating where the media is to be 4376 delivered depends on the use case. In many case the only allowed 4377 method will be to use no explicit indication and have the server 4378 deliver media to the source of the RTSP messages. 4380 An RTSP proxy will also need to take care. If the media is not 4381 desired to be routed through the proxy, the proxy will need to 4382 introduce the destination indication. 4384 Below are the configuration parameters associated with transport: 4386 General parameters: 4388 unicast / multicast: This parameter is a mutually exclusive 4389 indication of whether unicast or multicast delivery will be 4390 attempted. One of the two values MUST be specified. Clients 4391 that are capable of handling both unicast and multicast 4392 transmission MUST indicate such capability by including two 4393 full transport-specs with separate parameters for each. 4395 destination: The address of the stream recipient to which a 4396 stream will be sent. The client originating the RTSP 4397 request may specify the destination address of the stream 4398 recipient with the destination parameter. When the 4399 destination field is specified, the recipient may be a 4400 different party than the originator of the request. To 4401 avoid becoming the unwitting perpetrator of a remote- 4402 controlled denial-of-service attack, a server SHOULD 4403 authenticate the client originating the request and SHOULD 4404 log such attempts before allowing the client to direct a 4405 media stream to a recipient address not chosen by the 4406 server. Implementations cannot rely on TCP as reliable 4407 means of client identification. 4409 The server SHOULD NOT allow the destination field to be set 4410 unless a mechanism exists in the system to authorize the 4411 request originator to direct streams to the recipient. It 4412 is preferred that this authorization be performed by the 4413 recipient itself and the credentials passed along to the 4414 server. However, in certain cases, such as when recipient 4415 address is a multicast group, or when the recipient is 4416 unable to communicate with the server in an out-of-band 4417 manner, this may not be possible. In these cases server may 4418 chose another method such as a server-resident 4419 authorization list to ensure that the request originator 4420 has the proper credentials to request stream delivery to 4421 the recipient. 4423 This parameter SHALL NOT be used when src_addr and 4424 dest_addr is used in a transport declaration. For IPv6 4425 addresses it is RECOMMENDED that they be given as fully 4426 qualified domain to make it backwards compatible with RFC 4427 2326 implementations. 4429 source: If the source address for the stream is different than 4430 can be derived from the RTSP end-point address (the server 4431 in playback), the source address SHOULD be specified. To 4432 maintain backwards compatibility with RFC 2326, any IPv6 4433 host's address needs to be given as a fully qualified 4434 domain name. This parameter SHALL NOT be used when src_addr 4435 and dest_addr is used in a transport declaration. 4437 This information may also be available through SDP. 4438 However, since this is more a feature of transport 4439 than media initialization, the authoritative source 4440 for this information should be in the SETUP response. 4442 layers: The number of multicast layers to be used for this media 4443 stream. The layers are sent to consecutive addresses 4444 starting at the destination address. 4446 dest_addr: A general destination address parameter that can 4447 contain one or more address and port pair. For each 4448 combination of Protocol/Profile/Lower Transport the 4449 interpretation of the address or addresses needs to be 4450 defined. The host address part of the tuple MAY be empty, 4451 for example ":8000", in cases when only destination port is 4452 desired to be specified. 4454 The client or server SHALL NOT use this parameter unless 4455 both client and server has shown support. This parameter 4456 MUST be supported by client and servers that implements 4457 this specification. Support is indicated by the use of the 4458 feature-tag "play.basic". This parameter SHALL NOT be used 4459 in the same transport specification as any of the 4460 parameters "destination", "source", "port", "client_port", 4461 and "server_port". 4463 The same security consideration that are given for the 4464 "Destination" parameter does also applies to this 4465 parameter. This parameter can be used for redirecting 4466 traffic to recipient not desiring the media traffic. 4468 src_addr: A general source address parameter that can contain 4469 one or more address and port pairs. For each combination of 4470 Protocol/Profile/Lower Transport the interpretation of the 4471 address or addresses needs to be defined. The client or 4472 server SHALL NOT use this parameter unless both client and 4473 server have shown support. This parameter MUST be supported 4474 by client and servers that implement this specification. 4475 Support is indicated by the use the feature-tag 4476 "play.basic". This parameter SHALL NOT be used in the same 4477 transport specification as any of the parameters 4478 "destination", "source", "port", "client_port", and 4479 "server_port". 4481 This parameter MUST be specified by the server if it 4482 transmits media packets from another address than the one 4483 RTSP messages are sent to. This will allow the client to 4484 verify source address and give it a destination address for 4485 its RTCP feedback packets if RTP is used. The address or 4486 addresses indicated in the src_addr parameter SHOULD be 4487 used both for sending and receiving of the media streams 4488 data packets. The main reasons are threefold: First, 4489 indicating the port and source address(s) lets the receiver 4490 know where from the packets is expected to originate. 4491 Secondly, traversal of NATs are greatly simplified when 4492 traffic is flowing symmetrically over a NAT binding. 4493 Thirdly, certain NAT traversal mechanisms, needs to know to 4494 which address and port to send so called "binding packets" 4495 from the receiver to the sender, thus creating a address 4496 binding in the NAT that the sender to receiver packet flow 4497 can use. 4499 mode: The mode parameter indicates the methods to be supported 4500 for this session. Valid values are PLAY and RECORD. If not 4501 provided, the default is PLAY. The RECORD value was 4502 defined in RFC 2326 and is deprecated in this 4503 specification. 4505 append: The append parameter was used together with RECORD and 4506 is now deprecated. 4508 interleaved: The interleaved parameter implies mixing the media 4509 stream with the control stream in whatever protocol is 4510 being used by the control stream, using the mechanism 4511 defined in Section 12. The argument provides the channel 4512 number to be used in the $ statement and MUST be present. 4513 This parameter MAY be specified as a range, e.g., 4514 interleaved=4-5 in cases where the transport choice for the 4515 media stream requires it, e.g. for RTP with RTCP. The 4516 channel number given in the request are only a guidance 4517 from the client to the server on what channel number(s) to 4518 use. The server MAY set any valid channel number in the 4519 response. The declared channel(s) are bi-directional, so 4520 both end-parties MAY send data on the given channel. One 4521 example of such usage is the second channel used for RTCP, 4522 where both server and client sends RTCP packets on the same 4523 channel. 4525 This allows RTP/RTCP to be handled similarly to the 4526 way that it is done with UDP, i.e., one channel for 4527 RTP and the other for RTCP. 4529 Multicast-specific: 4531 ttl: multicast time-to-live. 4533 RTP-specific: 4535 These parameters are MAY only be used if the media transport protocol 4536 is RTP. 4538 port: This parameter provides the RTP/RTCP port pair for a 4539 multicast session. It is should be specified as a range, 4540 e.g., port=3456-3457 4542 client_port: This parameter provides the unicast RTP/RTCP port 4543 pair on the client where media data and control information 4544 is to be sent. It is specified as a range, e.g., 4545 port=3456-3457. This parameter SHALL NOT be used when 4546 src_addr and dest_addr is used in a transport declaration. 4548 server_port: This parameter provides the unicast RTP/RTCP port 4549 pair on the server where media data and control information 4550 is to be sent. It is specified as a range, e.g., 4551 port=3456-3457. This parameter SHALL NOT be used when 4552 src_addr and dest_addr is used in a transport declaration. 4554 ssrc: The ssrc parameter, if included in a SETUP response, 4555 indicates the RTP SSRC [17] value(s) that will be used by 4556 the media server for RTP packets within the stream. It is 4557 expressed as an eight digit hexadecimal value. Multiple 4558 values MAY only be specified if the client has indicated 4559 support for this specification, i.e. if including multiple 4560 SSRC values, the request is required to include the 4561 "Require: play.basic" or "Supported: play.basic" headers. 4562 If no such support is present only a single value SHALL be 4563 included. 4565 If the server does not act as a synchronization source for 4566 stream data (for instance, server is a translator, 4567 reflector, etc.), and only a single value can be specified, 4568 the value will be the "packet sender's SSRC" that would 4569 have been used in the RTCP Receiver Reports generated by 4570 the server, regardless of whether the server actually 4571 generates RTCP RRs. 4573 The first SSRC value is the one that RTP-Info 4574 synchronization information relates to, see section 14.38. 4576 The functionality of specifying the ssrc parameter in a 4577 SETUP request is deprecated as it is incompatible with the 4578 specification of RTP in RFC 3550 [17]. If the parameter is 4579 included in the transport header of a SETUP request, the 4580 server MAY ignore it, and choose an appropriate SSRC for 4581 the stream. The server MAY set the ssrc parameter in the 4582 transport header of the response. 4584 The combination of transport protocol, profile and lower transport 4585 needs to be defined. A number of combinations are defined in the 4586 appendix B. 4588 Below is a usage example, showing a client advertising the capability 4589 to handle multicast or unicast, preferring multicast. Since this is 4590 a unicast-only stream, the server responds with the proper transport 4591 parameters for unicast. 4593 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 4594 CSeq: 302 4595 Transport: RTP/AVP;multicast;mode="PLAY", 4596 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" 4598 S->C: RTSP/1.0 200 OK 4599 CSeq: 302 4600 Date: 23 Jan 1997 15:35:06 GMT 4601 Session: 47112344 4602 Transport: RTP/AVP;unicast;client_port=3456-3457; 4603 server_port=6256-6257;mode="PLAY" 4605 14.46 Unsupported 4607 The Unsupported response-header field lists the features not 4608 supported by the server. In the case where the feature was specified 4609 via the Proxy-Require field (Section 14.31), if there is a proxy on 4610 the path between the client and the server, the proxy MUST send a 4611 response message with a status code of 551 (Option Not Supported). 4612 The request SHALL NOT be forwarded. 4614 See Section 14.37 for a usage example. 4616 14.47 User-Agent 4618 See [H14.43] for explanation, however the syntax is clarified due to 4619 an error in RFC 2616. A Client SHOULD include this header in all RTSP 4620 messages it sends. 4622 14.48 Vary 4624 See [H14.44] 4626 14.49 Via 4628 See [H14.45]. 4630 14.50 WWW-Authenticate 4632 See [H14.47]. 4634 15 Caching 4636 In HTTP, response-request pairs are cached. RTSP differs 4637 significantly in that respect. Responses are not cacheable, with the 4638 exception of the presentation description returned by DESCRIBE. 4639 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4640 not return any data, caching is not really an issue for these 4641 requests.) However, it is desirable for the continuous media data, 4642 typically delivered out-of-band with respect to RTSP, to be cached, 4643 as well as the session description. 4645 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4646 has an up-to-date copy of the continuous media content and its 4647 description. It can determine whether the copy is up-to-date by 4648 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4649 Last-Modified header with that of the cached copy. If the copy is not 4650 up-to-date, it modifies the SETUP transport parameters as appropriate 4651 and forwards the request to the origin server. Subsequent control 4652 commands such as PLAY or PAUSE then pass the proxy unmodified. The 4653 proxy delivers the continuous media data to the client, while 4654 possibly making a local copy for later reuse. The exact behavior 4655 allowed to the cache is given by the cache-response directives 4656 described in Section 14.10. A cache MUST answer any DESCRIBE requests 4657 if it is currently serving the stream to the requestor, as it is 4658 possible that low-level details of the stream description may have 4659 changed on the origin-server. 4661 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 4662 through" variety. Rather than retrieving the whole resource from the 4663 origin server, the cache simply copies the streaming data as it 4664 passes by on its way to the client. Thus, it does not introduce 4665 additional latency. 4667 To the client, an RTSP proxy cache appears like a regular media 4668 server, to the media origin server like a client. Just as an HTTP 4669 cache has to store the content type, content language, and so on for 4670 the objects it caches, a media cache has to store the presentation 4671 description. Typically, a cache eliminates all transport-references 4672 (that is, multicast information) from the presentation description, 4673 since these are independent of the data delivery from the cache to 4674 the client. Information on the encodings remains the same. If the 4675 cache is able to translate the cached media data, it would create a 4676 new presentation description with all the encoding possibilities it 4677 can offer. 4679 16 Examples 4681 This section contains several different examples trying to illustrate 4682 possible ways of using RTSP. The examples can also help with the 4683 understanding of how functions of RTSP work. However remember that 4684 this is examples and the normative and syntax description in the 4685 other sections takes precedence. Please also note that many of the 4686 example MAY contain syntax illegal line breaks to accommodate the 4687 formatting restriction that the RFC series impose. 4689 16.1 Media on Demand (Unicast) 4691 Client C requests a movie distributed from two different media 4692 servers A (audio.example.com ) and V (video.example.com ). The media 4693 description is stored on a web server W. The media description 4694 contains descriptions of the presentation and all its streams, 4695 including the codecs that are available, dynamic RTP payload types, 4696 the protocol stack, and content information such as language or 4697 copyright restrictions. It may also give an indication about the 4698 timeline of the movie. 4700 In this example, the client is only interested in the last part of 4701 the movie. 4703 C->W: GET /twister.sdp HTTP/1.1 4704 Host: www.example.com 4705 Accept: application/sdp 4707 W->C: HTTP/1.0 200 OK 4708 Date: 23 Jan 1997 15:35:06 GMT 4709 Content-Type: application/sdp 4710 Content-Length: 255 4711 Expires: 23 Jan 1998 15:35:06 GMT 4713 v=0 4714 o=- 2890844526 2890842807 IN IP4 192.16.24.202 4715 s=RTSP Session 4716 e=adm@example.com 4717 a=range:npt=0-1:49:34 4718 t=0 0 4719 m=audio 0 RTP/AVP 0 4720 a=control:rtsp://audio.example.com/twister/audio.en 4721 m=video 0 RTP/AVP 31 4722 a=control:rtsp://video.example.com/twister/video 4724 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 4725 CSeq: 1 4726 User-Agent: PhonyClient/1.2 4727 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, 4728 RTP/AVP/TCP;unicast;interleaved=0-1 4730 A->C: RTSP/1.0 200 OK 4731 CSeq: 1 4732 Session: 12345678 4733 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; 4734 server_port=5000-5001 4735 Date: 23 Jan 1997 15:35:12 GMT 4736 Server: PhonyServer/1.0 4737 Expires: 24 Jan 1997 15:35:12 GMT 4738 Cache-Control: public 4739 Accept-Ranges: NPT, SMPTE 4741 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 4742 CSeq: 1 4743 User-Agent: PhonyClient/1.2 4744 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059, 4745 RTP/AVP/TCP;unicast;interleaved=0-1 4747 V->C: RTSP/1.0 200 OK 4748 CSeq: 1 4749 Session: 23456789 4750 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; 4751 server_port=5002-5003 4752 Date: 23 Jan 1997 15:35:12 GMT 4753 Server: PhonyServer/1.0 4754 Cache-Control: public 4755 Expires: 24 Jan 1997 15:35:12 GMT 4756 Accept-Ranges: NPT, SMPTE 4758 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 4759 CSeq: 2 4760 User-Agent: PhonyClient/1.2 4761 Session: 23456789 4762 Range: smpte=0:10:00- 4764 V->C: RTSP/1.0 200 OK 4765 CSeq: 2 4766 Session: 23456789 4767 Range: smpte=0:10:00-1:49:23 4768 RTP-Info: url=rtsp://video.example.com/twister/video; 4769 seq=12312232;rtptime=78712811 4770 Server: PhonyServer/2.0 4771 Date: 23 Jan 1997 15:35:13 GMT 4773 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 4774 CSeq: 2 4775 User-Agent: PhonyClient/1.2 4776 Session: 12345678 4777 Range: smpte=0:10:00- 4779 A->C: RTSP/1.0 200 OK 4780 CSeq: 2 4781 Session: 12345678 4782 Range: smpte=0:10:00-1:49:23 4783 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; 4784 seq=876655;rtptime=1032181 4785 Server: PhonyServer/1.0 4786 Date: 23 Jan 1997 15:35:13 GMT 4788 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 4789 CSeq: 3 4790 User-Agent: PhonyClient/1.2 4791 Session: 12345678 4793 A->C: RTSP/1.0 200 OK 4794 CSeq: 3 4795 Server: PhonyServer/1.0 4796 Date: 23 Jan 1997 15:36:52 GMT 4798 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 4799 CSeq: 3 4800 User-Agent: PhonyClient/1.2 4801 Session: 23456789 4803 V->C: RTSP/1.0 200 OK 4804 CSeq: 3 4805 Server: PhonyServer/2.0 4806 Date: 23 Jan 1997 15:36:52 GMT 4808 Even though the audio and video track are on two different servers, 4809 may start at slightly different times, and may drift with respect to 4810 each other, the client can synchronize the two using standard RTP 4811 methods, in particular the time scale contained in the RTCP sender 4812 reports. Initial synchronization is achieved through the RTP-Info and 4813 Range headers information in the PLAY response. 4815 16.2 Streaming of a Container file 4817 For purposes of this example, a container file is a storage entity in 4818 which multiple continuous media types pertaining to the same end-user 4819 presentation are present. In effect, the container file represents an 4820 RTSP presentation, with each of its components being RTSP streams. 4821 Container files are a widely used means to store such presentations. 4822 While the components are transported as independent streams, it is 4823 desirable to maintain a common context for those streams at the 4824 server end. 4826 This enables the server to keep a single storage handle 4827 open easily. It also allows treating all the streams 4828 equally in case of any prioritization of streams by the 4829 server. 4831 It is also possible that the presentation author may wish to prevent 4832 selective retrieval of the streams by the client in order to preserve 4833 the artistic effect of the combined media presentation. Similarly, in 4834 such a tightly bound presentation, it is desirable to be able to 4835 control all the streams via a single control message using an 4836 aggregate URI. 4838 The following is an example of using a single RTSP session to control 4839 multiple streams. It also illustrates the use of aggregate URIs. In a 4840 container file it is also desirable to not write any URI parts which 4841 is not kept, when the container is distributed, like the host and 4842 most of the path element. Therefore this example also uses the "*" 4843 and relative URI in the delivered SDP. 4845 Client C requests a presentation from media server M. The movie is 4846 stored in a container file. The client has obtained an RTSP URI to 4847 the container file. 4849 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/1.0 4850 CSeq: 1 4851 User-Agent: PhonyClient/1.2 4853 M->C: RTSP/1.0 200 OK 4854 CSeq: 1 4855 Server: PhonyServer/1.0 4856 Date: 23 Jan 1997 15:35:06 GMT 4857 Content-Type: application/sdp 4858 Content-Length: 257 4859 Content-Base: rtsp://example.com/twister.3gp/ 4860 Expires: 24 Jan 1997 15:35:06 GMT 4862 v=0 4863 o=- 2890844256 2890842807 IN IP4 172.16.2.93 4864 s=RTSP Session 4865 i=An Example of RTSP Session Usage 4866 e=adm@example.com 4867 a=control: * 4868 a=range: npt=0-0:10:34.10 4869 t=0 0 4870 m=audio 0 RTP/AVP 0 4871 a=control: trackID=1 4872 m=video 0 RTP/AVP 26 4873 a=control: trackID=4 4875 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/1.0 4876 CSeq: 2 4877 User-Agent: PhonyClient/1.2 4878 Require: play.basic 4879 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 4881 M->C: RTSP/1.0 200 OK 4882 CSeq: 2 4883 Server: PhonyServer/1.0 4884 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; 4885 src_addr="172.16.2.93:9000"/"172.16.2.93:9001" 4886 ssrc=93CB001E 4887 Session: 12345678 4888 Expires: 24 Jan 1997 15:35:12 GMT 4889 Date: 23 Jan 1997 15:35:12 GMT 4890 Accept-Ranges: NPT 4892 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/1.0 4893 CSeq: 3 4894 User-Agent: PhonyClient/1.2 4895 Require: play.basic 4896 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 4897 Session: 12345678 4899 M->C: RTSP/1.0 200 OK 4900 CSeq: 3 4901 Server: PhonyServer/1.0 4902 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; 4903 src_addr="172.16.2.93:9002"/"172.16.2.93:9003"; 4904 ssrc=A813FC13 4905 Session: 12345678 4906 Expires: 24 Jan 1997 15:35:13 GMT 4907 Date: 23 Jan 1997 15:35:13 GMT 4908 Accept-Range: NPT 4910 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 4911 CSeq: 4 4912 User-Agent: PhonyClient/1.2 4913 Range: npt=0-10, npt=30- 4914 Session: 12345678 4916 M->C: RTSP/1.0 200 OK 4917 CSeq: 4 4918 Server: PhonyServer/1.0 4919 Date: 23 Jan 1997 15:35:14 GMT 4920 Session: 12345678 4921 Range: npt=0-10, npt=30-623.10 4922 RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4; 4923 seq=12345;rtptime=3450012, 4924 url=rtsp://example.com/twister.3gp/trackID=1; 4925 seq=54321;rtptime=2876889 4927 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/1.0 4928 CSeq: 5 4929 User-Agent: PhonyClient/1.2 4930 Session: 12345678 4932 M->C: RTSP/1.0 200 OK 4933 CSeq: 5 4934 Server: PhonyServer/1.0 4935 Date: 23 Jan 1997 15:36:01 GMT 4936 Session: 12345678 4937 Range: npt=34.57-623.10 4939 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/1.0 4940 CSeq: 6 4941 User-Agent: PhonyClient/1.2 4942 Range: npt=34.57-623.10 4943 Session: 12345678 4945 M->C: RTSP/1.0 200 OK 4946 CSeq: 6 4947 Server: PhonyServer/1.0 4948 Date: 23 Jan 1997 15:36:01 GMT 4949 Session: 12345678 4950 Range: npt=34.57-623.10 4951 RTP-Info: url=rtsp://example.com/twister.3gp/trackID=4; 4952 seq=12555;rtptime=6330012, 4953 url=rtsp://example.com/twister.3gp/trackID=1; 4954 seq=55021;rtptime=3132889 4956 16.3 Single Stream Container Files 4958 Some RTSP servers may treat all files as though they are "container 4959 files", yet other servers may not support such a concept. Because of 4960 this, clients SHOULD use the rules set forth in the session 4961 description for Request-URIs, rather than assuming that a consistent 4962 URI may always be used throughout. Below are an example of how a 4963 multi-stream server might expect a single-stream file to be served: 4965 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 4966 Accept: application/x-rtsp-mh, application/sdp 4967 CSeq: 1 4968 User-Agent: PhonyClient/1.2 4970 S->C: RTSP/1.0 200 OK 4971 CSeq: 1 4972 Content-base: rtsp://foo.com/test.wav/ 4973 Content-type: application/sdp 4974 Content-length: 48 4975 Server: PhonyServer/1.0 4976 Date: 23 Jan 1997 15:35:06 GMT 4977 Expires: 23 Jan 1997 17:00:00 GMT 4979 v=0 4980 o=- 872653257 872653257 IN IP4 172.16.2.187 4981 s=mu-law wave file 4982 i=audio test 4983 t=0 0 4984 a=control: * 4985 m=audio 0 RTP/AVP 0 4986 a=control:streamid=0 4988 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 4989 Transport: RTP/AVP/UDP;unicast; 4990 client_port=6970-6971;mode="PLAY" 4991 CSeq: 2 4992 User-Agent: PhonyClient/1.2 4994 S->C: RTSP/1.0 200 OK 4995 Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; 4996 server_port=6970-6971;mode="PLAY";ssrc=EAB98712 4997 CSeq: 2 4998 Session: 2034820394 4999 Expires: 23 Jan 1997 16:00:00 GMT 5000 Server: PhonyServer/1.0 5001 Date: 23 Jan 1997 15:35:07 GMT 5003 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/1.0 5004 CSeq: 3 5005 User-Agent: PhonyClient/1.2 5006 Session: 2034820394 5008 S->C: RTSP/1.0 200 OK 5009 CSeq: 3 5010 Server: PhonyServer/1.0 5011 Date: 23 Jan 1997 15:35:08 GMT 5012 Session: 2034820394 5013 Range: npt=0-600 5014 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; 5015 seq=981888;rtptime=3781123 5017 Note the different URI in the SETUP command, and then the switch back 5018 to the aggregate URI in the PLAY command. This makes complete sense 5019 when there are multiple streams with aggregate control, but is less 5020 than intuitive in the special case where the number of streams is 5021 one. However the server has declared that the aggregated control URI 5022 in the SDP and therefore this is legal. 5024 In this case, it is also required that servers accept implementations 5025 that use the non-aggregated interpretation and use the individual 5026 media URI, like this: 5028 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/1.0 5029 CSeq: 3 5030 User-Agent: PhonyClient/1.2 5032 16.4 Live Media Presentation Using Multicast 5034 The media server M chooses the multicast address and port. Here, it 5035 is assumed that the web server only contains a pointer to the full 5036 description, while the media server M maintains the full description. 5038 Editors note: Is this example really valid? In what situations does 5039 it make sense to do a setup to a multicast distribution channel, and 5040 also issue PLAY requests? 5042 C->W: GET /sessions.html HTTP/1.1 5043 Host: www.example.com 5045 W->C: HTTP/1.1 200 OK 5046 Content-Type: text/html 5048 5049 ... 5050 5052 ... 5053 5055 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 5056 CSeq: 1 5057 Supported: play.basic, play.scale 5059 M->C: RTSP/1.0 200 OK 5060 CSeq: 1 5061 Content-Type: application/sdp 5062 Content-Length: 181 5063 Server: PhonyServer/1.0 5064 Date: 23 Jan 1997 15:35:06 GMT 5065 Supported: play.basic 5067 v=0 5068 o=- 2890844526 2890842807 IN IP4 192.16.24.202 5069 s=RTSP Session 5070 m=audio 3456 RTP/AVP 0 5071 c=IN IP4 224.2.0.1/16 5072 a=control: rtsp://live.example.com/concert/audio 5073 a=range:npt=0- 5075 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 5076 CSeq: 2 5077 Transport: RTP/AVP;multicast 5079 M->C: RTSP/1.0 200 OK 5080 CSeq: 2 5081 Server: PhonyServer/1.0 5082 Date: 23 Jan 1997 15:35:06 GMT 5083 Transport: RTP/AVP;multicast;destination=224.2.0.1; 5084 port=3456-3457;ttl=16 5085 Session: 0456804596 5086 Accept-Ranges: NPT, UTC 5088 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 5089 CSeq: 3 5090 Session: 0456804596 5092 M->C: RTSP/1.0 200 OK 5093 CSeq: 3 5094 Server: PhonyServer/1.0 5095 Date: 23 Jan 1997 15:35:07 GMT 5096 Session: 0456804596 5097 Range:npt=1256- 5098 RTP-Info: url=rtsp://live.example.com/concert/audio; 5099 seq=1473; rtptime=80000 5101 16.5 Capability Negotiation 5103 This examples illustrate how the client and server determines their 5104 capability to support a special feature, in this case "play.scale". 5105 The server, through the clients request and the included Supported 5106 header, learns that the client is supporting this updated 5107 specification, and also supports the playback time scaling feature of 5108 RTSP. The server's response contains the following feature related 5109 information to the client; it supports the updated specification 5110 (play.basic), the extended functionality of time scaling of content 5111 (play.scale), and one "example.com" proprietary feature 5112 (example.com.flight). The client also learns the methods supported 5113 (Public header) by the server for the indicated resource. 5115 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/1.0 5116 CSeq: 1 5117 Supported: play.basic, play.scale 5118 User-Agent: PhonyClient/1.2 5120 S->C: RTSP/1.0 200 OK 5121 CSeq: 1 5122 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 5123 Server: PhonyServer/2.0 5124 Supported: play.basic, play.scale, example.com.flight 5126 When the client sends its SETUP request it tells the server that it 5127 is requires support of the play.scale feature for this session by 5128 including the Require header. 5130 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/1.0 5131 CSeq: 3 5132 User-Agent: PhonyClient/1.2 5133 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057, 5134 RTP/AVP/TCP;unicast;interleaved=0-1 5135 Require: play.scale 5137 S->C: RTSP/1.0 200 OK 5138 CSeq: 3 5139 Session: 12345678 5140 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; 5141 server_port=5000-5001 5142 Server: PhonyServer/2.0 5143 Accept-Ranges: NPT, SMPTE 5145 17 Security Framework 5147 The RTSP security framework consists of two high level components: 5148 the pure authentication mechanisms based on HTTP authentication, and 5149 the transport protection based on TLS, which is independent of RTSP. 5150 Because of the similarity in syntax and usage between RTSP servers 5151 and HTTP servers, the security for HTTP is re-used to a large extent. 5153 17.1 RTSP and HTTP Authentication 5155 RTSP and HTTP share common authentication schemes, and thus follow 5156 the same usage guidelines as specified in [8] and also in [H15]. 5157 Servers SHOULD implement both basic and digest [8] authentication. 5159 It should be stressed that using the HTTP authentication alone does 5160 not provide full control message security. Therefore, in environments 5161 requiring tighter security for the control messages, TLS SHOULD be 5162 used, see Section 17.2. 5164 17.2 RTSP over TLS 5166 RTSP SHALL follow the same guidelines with regards to TLS [7] usage 5167 as specified for HTTP, see [18]. RTSP over TLS is separated from 5168 unsecured RTSP both on URI level and port level. Instead of using the 5169 "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier 5170 MUST be used to signal RTSP over TLS. If no port is given in a URI 5171 with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP. 5173 When a client tries to setup an insecure channel to the server (using 5174 the "rtsp" URI), and the policy for the resource requires a secure 5175 channel, the server SHALL redirect the client to the secure service 5176 by sending a 301 redirect response code together with the correct 5177 Location URI (using the "rtsps" scheme). 5179 It should be noted that TLS allows for mutual authentication (when 5180 using both server and client certificates). Still, one of the more 5181 common way TLS is used is to only provide server side authentication 5182 (often to avoid client certificates). TLS is then used in addition to 5183 HTTP authentication, providing transport security and server 5184 authentication, while HTTP Authentication is used to authenticate the 5185 client. 5187 RTSP includes the possibility to keep a TCP session up between the 5188 client and server, throughout the RTSP session lifetime. It may be 5189 convenient to keep the TCP session, not only to save the extra setup 5190 time for TCP, but also the extra setup time for TLS (even if TLS uses 5191 the resume function, there will be almost two extra roundtrips). 5192 Still, when TLS is used, such behavior introduces extra active state 5193 in the server, not only for TCP and RTSP, but also for TLS. This may 5194 increase the vulnerability to DoS attacks. 5196 In addition to these recommendations, Section 17.3 gives further 5197 recommendations of TLS usage with proxies. 5199 17.3 Security and Proxies 5201 The nature of a proxy is often to act as a "man-in-the-middle", while 5202 security is often about preventing the existence of a "man-in-the- 5203 middle". This section provides the clients with the possibility to 5204 use proxies even when applying secure transports (TLS). The client 5205 needs to select between using the below specified procedure or using 5206 a TLS connection directly (by-passing any proxies) to the server. The 5207 choice may be dependent on policies. 5209 There are basically two categories of inspecting proxies, the 5210 transparent proxies (which the client is not aware of) and the non- 5211 transparent proxies (which the client is aware of). An infrastructure 5212 based on proxies requires that the trust model is such that both 5213 client and servers can trust the proxies to handle the RTSP messages 5214 correctly. To be able to trust a proxy, the client and server also 5215 needs to be aware of the proxy. Hence, transparent proxies cannot 5216 generally be seen as trusted and will not work well with security 5217 (unless they work only at transport layer). In the rest of this 5218 section any reference to proxy will be to a non-transparent proxy, 5219 which requires to inspect/manipulate the RTSP messages. 5221 The HTTP Authentication is built on the assumption of proxies and can 5222 provide user-proxy authentication and proxy-proxy/server 5223 authentication in addition to the client-server authentication. 5225 When TLS is applied and a proxy is used, the client will use the 5226 proxy's destination URI address when sending messages. This implies 5227 that for TLS, the client will authenticate the proxy server and not 5228 the end server. Note that, when the client checks the server 5229 certificate in TLS, it MUST check the proxy's identity (URI or 5230 possibly other known identity) against the proxy's identity as 5231 presented in the proxy's Certificate message. 5233 The problem is that for proxy accepted by the client, it needs to be 5234 provided information on which grounds it should accept the next-hop 5235 certificate. Both the proxy and the user may have rules for this, and 5236 the user have the possibility to select the desired behavior. To 5237 handle this case, the Accept-Credentials header (See Section 14.2) is 5238 used, where the client can force the proxy/proxies to relay back the 5239 certificates used by any intermediate proxies as well as the server. 5240 Given the assumption that the proxies are viewed as trusted, it gives 5241 the user a possibility to enforce policies to each trusted proxy of 5242 whether it should accept the next entity in the chain. 5244 A proxy MUST use TLS for the next hop if the RTSP request includes a 5245 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 5246 client and proxy, or between proxy and proxy), even if the resource 5247 and the end server does not require to use it. 5249 17.3.1 Accept-Credentials 5251 The Accept-Credentials header can be used by the client to distribute 5252 simple authorization policies to intermediate proxies. The client 5253 includes the Accept-Credentials header to dictate how the proxy 5254 treats the server/next proxy certificate. There are currently three 5255 methods defined: 5257 Any, which means that the proxy (or proxies) SHALL accept 5258 whatever certificate presented. This is of course not a 5259 recommended option to use, but may be useful in certain 5260 circumstances (such as testing). 5262 Proxy, which means that the proxy (or proxies) MUST use its own 5263 policies to validate the certificate and decide whether to 5264 accept it or not. This is convenient in cases where the 5265 user has a strong trust relation with the proxy. Reason why 5266 a strong trust relation may exist are; personal/company 5267 proxy, proxy has a out-of-band policy configuration 5268 mechanism. 5270 User, which means that the proxy (or proxies) MUST send 5271 credential information about the next hop to the client for 5272 authorization. The client can then decide whether the proxy 5273 should accept the certificate or not. See section 17.3.2 5274 for further details. 5276 If the Accept-Credentials header is not included in the RTSP request 5277 from the client, the default method used SHALL be "Proxy". If 5278 something else than the "Proxy" method is used, the Accept- 5279 Credentials header SHALL always be included in the RTSP request from 5280 the client. This is because it cannot be assumed that the proxy 5281 always keeps the TLS state or the users previously preference between 5282 different RTSP messages (in particular if the time interval between 5283 the messages is long). 5285 The "Any" and "Proxy" methods does not require the proxy to provide 5286 any specific response, but only apply the policy as defined for 5287 respectively method. If the policy do not accept the credentials of 5288 the next hop, the entity SHALL respond with a message using status 5289 code 471 (Connection Credentials not accepted). 5291 An RTSP request in the direction server to client MUST NOT include 5292 the Accept-Credential header. As for the non-secured communication, 5293 the possibility for these request depends on the presence of a client 5294 established connection. However if the server to client request is 5295 in relation to a session established over a TLS secured channel, if 5296 MUST be sent in a TLS secured connection. That secured connection 5297 MUST also be the one used by the last client to server request. If no 5298 such transport connection exist at the time when the server desire to 5299 send the request, it silently fails. 5301 Further policies MAY be defined and registered, but should be done so 5302 with caution. 5304 17.3.2 User approved TLS procedure 5306 For the "User" method each proxy MUST perform the the following 5307 procedure for each RTSP request: 5309 o Setup the TLS session to the next hop if not already present 5310 (i.e. run the TLS handshake, but do not send the RTSP 5311 request). 5313 o Extract the peer certificate for the TLS session. 5315 o Check if a matching identity and hash of the peer certificate 5316 is present in the Accept-Credentials header. If present, send 5317 the message to the next hop, and conclude these procedures. If 5318 not, go to the next step. 5320 o The proxy responds to the RTSP request with a 470 or 407 5321 response code. The 407 response code MAY be used when the 5322 proxy requires both user and connection authorization from 5323 user or client. In this message the proxy SHALL include a 5324 Connection-Credentials header, see section 14.12 with the next 5325 hop's identity and certificate. 5327 The client MUST upon receiving a 470 or 407 response with 5328 Connection-Credentials header take the decision on whether to accept 5329 the certificate or not (if it cannot do so, the user SHOULD be 5330 consulted). If the certificate is accepted, the client has to again 5331 send the RTSP request. In that request the client has to include the 5332 Accept-Credentials header including the hash over the DER encoded 5333 certificate for all trusted proxies in the chain. 5335 Example: 5336 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/1.0 5337 CSeq: 2 5338 Transport: RTP/AVP ;unicast ;client_port=4588-4589 5340 P->C: RTSP/1.0 470 Connection Authorization Required 5341 CSeq: 2 5342 Connection-Credentials: "rtsps://test.example.org"; 5343 MIIDNTCCAp... 5345 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/1.0 5346 CSeq: 2 5347 Transport: RTP/AVP ;unicast ;client_port=4588-4589 5348 Accept-Credentials: User "rtsps://test.example.org" ; 5349 dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ... 5351 One implication of this process is that the connection for secured 5352 RTSP messages may take significantly more round-trip times for the 5353 first message. An complete extra message exchange between the proxy 5354 connecting to the next hop and the client results because of the 5355 process for approval for each hop. However after the first message 5356 exchange the remaining message should not be delayed, if each message 5357 contains the chain of proxies that the requestor accepts. The 5358 procedure of including the credentials in each request rather than 5359 building state in each proxy, avoids the need for revocation 5360 procedures. 5362 18 Syntax 5364 The RTSP syntax is described in an augmented Backus-Naur Form (BNF) 5365 as defined in RFC 2234 [5]. 5367 18.1 Base Syntax 5369 OCTET = %x00-FF ; any 8-bit sequence of data 5370 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 5371 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 5372 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 5373 ALPHA = UPALPHA / LOALPHA 5374 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 5375 CTL = %x00-1F / %x7F ; any US-ASCII control character 5376 (octets 0 - 31) and DEL (127)> 5377 CR = %x0D ; US-ASCII CR, carriage return (13)> 5378 LF = %x0A ; US-ASCII LF, linefeed (10)> 5379 SP = %x20 ; US-ASCII SP, space (32)> 5380 HT = %x09 ; US-ASCII HT, horizontal-tab (9)> 5381 DQUOTE = %x22 ; US-ASCII double-quote mark (34)> 5382 BACKSLASH = %x5C ; US-ASCII backslash (92)> 5383 CRLF = CR LF 5384 LWS = [CRLF] 1*( SP / HT ) 5385 TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs> 5386 tspecials = "(" / ")" / "<" / ">" / "@" 5387 / "," / ";" / ":" / BACKSLASH / DQUOTE 5388 / "/" / "[" / "]" / "?" / "=" 5389 / "{" / "}" / SP / HT 5390 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 5391 / %x41-5A / %x5E-7A / %x7C / %x7E) 5392 ; 1* 5393 quoted-string = ( DQUOTE *(qdtext) DQUOTE ) 5394 qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> 5395 quoted-pair = BACKSLASH CHAR 5397 safe = "$" / "-" / "_" / "." / "+" 5398 extra = "!" / "*" / "'" / "(" / ")" / "," 5399 hex = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / 5400 "a" / "b" / "c" / "d" / "e" / "f" 5401 escape = "%" hex hex 5402 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 5403 unreserved = alpha / digit / safe / extra 5404 xchar = unreserved / reserved / escape 5405 base64 = 0*base64-unit [base64-pad] 5406 base64-unit = 4base64-char 5407 base64-pad = (2base64-char "==") / (3base64-char "=") 5408 base64-char = ALPHA / DIGIT / "+" / "/" 5410 18.2 RTSP Protocol Definition 5412 18.2.1 Generic Protocol elements 5414 absoluteURL = < as defined in RFC 2396 [13] and RFC2732 [12] > 5415 relativeURL = < as defined in RFC 2396 [13] and RFC2732 [12] > 5416 rtsp-URI = rtsp-scheme "//" host [":" port] 5417 [abs-path ["?" query]] ["#" fragment] 5418 rtsp-scheme = ( "rtsp:" / "rtspu:" / "rtsps:" ) 5419 host = As defined by RFC 2732 [12] 5420 abs-path = As defined by RFC 2396 [13] 5421 port = *DIGIT ; Is expected to be 1*5DIGIT 5422 query = As defined by RFC 2396 [13] 5423 fragment = As defined by RFC 2396 [13] 5425 smpte-range = smpte-type "=" smpte-range-spec 5426 ;Section 3.4 5427 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 5428 / ( "-" smpte-time ) 5429 smpte-type = "smpte" / "smpte-30-drop" 5430 / "smpte-25" / smpte-type-extension 5431 ; other timecodes may be added 5432 smpte-type-extension = token 5433 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 5434 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 5436 npt-range = ["npt" "="] npt-range-spec ; Section 3.5 5437 ; implementations SHOULD use npt= prefix, 5438 ;but SHOULD be prepared to interoperate with 5439 ; RFC 2326 implementations which don't use it. 5440 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 5441 npt-time = "now" / npt-sec / npt-hhmmss 5442 npt-sec = 1*DIGIT [ "." *DIGIT ] 5443 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 5444 npt-hh = 1*DIGIT ; any positive number 5445 npt-mm = 1*2DIGIT ; 0-59 5446 npt-ss = 1*2DIGIT ; 0-59 5448 utc-range = "clock" "=" utc-range-spec ; Section 3.6 5449 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 5450 utc-time = utc-date "T" utc-clock "Z" 5451 utc-date = 8DIGIT ; < YYYYMMDD > 5452 utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > 5453 fraction = 1*DIGIT 5455 feature-tag = token 5456 session-id = 8*( ALPHA / DIGIT / safe ) 5457 message-header = field-name ":" [ field-value ] CRLF 5458 field-name = token 5459 field-value = *( field-content / LWS ) 5460 field-content = 5464 18.2.2 Message Syntax 5465 RTSP-message = Request / Response ; RTSP/1.0 messages 5466 Request = Request-Line ; Section 6.1 5467 *( general-header ; Section 5 5468 / request-header ; Section 6.2 5469 / entity-header ) ; Section 8.1 5470 CRLF 5471 [ message-body ] ; Section 4.3 5472 Response = Status-Line ; Section 7.1 5473 *( general-header ; Section 5 5474 / response-header ; Section 7.1.2 5475 / entity-header ) ; Section 8.1 5476 CRLF 5477 [ message-body ] ; Section 4.3 5479 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 5480 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 5482 Method = "DESCRIBE" ; Section 11.2 5483 / "GET_PARAMETER" ; Section 11.7 5484 / "OPTIONS" ; Section 11.1 5485 / "PAUSE" ; Section 11.5 5486 / "PLAY" ; Section 11.4 5487 / "PING" ; Section 11.10 5488 / "REDIRECT" ; Section 11.9 5489 / "SETUP" ; Section 11.3 5490 / "SET_PARAMETER" ; Section 11.8 5491 / "TEARDOWN" ; Section 11.6 5492 / extension-method 5493 extension-method = token 5495 Request-URI = "*" / absolute-URL 5496 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 5498 Status-Code = "100" ; Continue 5499 / "200" ; OK 5500 / "201" ; Created 5501 / "250" ; Low on Storage Space 5502 / "300" ; Multiple Choices 5503 / "301" ; Moved Permanently 5504 / "302" ; Moved Temporarily 5505 / "303" ; See Other 5506 / "304" ; Not Modified 5507 / "305" ; Use Proxy 5508 / "400" ; Bad Request 5509 / "401" ; Unauthorized 5510 / "402" ; Payment Required 5511 / "403" ; Forbidden 5512 / "404" ; Not Found 5513 / "405" ; Method Not Allowed 5514 / "406" ; Not Acceptable 5515 / "407" ; Proxy Authentication Required 5516 / "408" ; Request Time-out 5517 / "410" ; Gone 5518 / "411" ; Length Required 5519 / "412" ; Precondition Failed 5520 / "413" ; Request Entity Too Large 5521 / "414" ; Request-URI Too Large 5522 / "415" ; Unsupported Media Type 5523 / "451" ; Parameter Not Understood 5524 / "452" ; reserved 5525 / "453" ; Not Enough Bandwidth 5526 / "454" ; Session Not Found 5527 / "455" ; Method Not Valid in This State 5528 / "456" ; Header Field Not Valid for Resource 5529 / "457" ; Invalid Range 5530 / "458" ; Parameter Is Read-Only 5531 / "459" ; Aggregate operation not allowed 5532 / "460" ; Only aggregate operation allowed 5533 / "461" ; Unsupported transport 5534 / "462" ; Destination unreachable 5535 / "470" ; Connection Authorization Required 5536 / "471" ; Connection Credentials not accepted 5537 / "500" ; Internal Server Error 5538 / "501" ; Not Implemented 5539 / "502" ; Bad Gateway 5540 / "503" ; Service Unavailable 5541 / "504" ; Gateway Time-out 5542 / "505" ; RTSP Version not supported 5543 / "551" ; Option not supported 5544 / extension-code 5546 extension-code = 3DIGIT 5547 Reason-Phrase = * 5549 general-header = Cache-Control ; Section 14.10 5550 / Connection ; Section 14.11 5551 / CSeq ; Section 14.19 5552 / Date ; Section 14.20 5553 / Proxy-Supported ; Section 14.32 5554 / Supported ; Section 14.43 5555 / Timestamp ; Section 14.44 5556 / Via ; Section 14.49 5557 / extension-header 5559 request-header = Accept ; Section 14.1 and [H14.1] 5560 / Accept-Credentials ; Section 14.2 5561 / Accept-Encoding ; Section 14.3 and [H14.3] 5562 / Accept-Language ; Section 14.4 and [H14.4] 5563 / Authorization ; Section 14.7 and [H14.8] 5564 / Bandwidth ; Section 14.8 5565 / Blocksize ; Section 14.9 5566 / From ; Section 14.23 5567 / If-Match ; Section 14.25 5568 / If-Modified-Since ; Section 14.26 and [H14.25] 5569 / If-None-Match ; Section 14.27 5570 / Proxy-Require ; Section 14.31 5571 / Range ; Section 14.34 5572 / Referer ; Section 14.35 5573 / Require ; Section 14.37 5574 / Scale ; Section 14.39 5575 / Session ; Section 14.42 5576 / Speed ; Section 14.40 5577 / Supported ; Section 14.43 5578 / Transport ; Section 14.45 5579 / User-Agent ; Section 14.47 5580 / extension-header 5582 response-header = Accept-Credentials ; Section 14.2 5583 / Accept-Ranges ; Section 14.5 5584 / Connection-Creds ; Section 14.12 5585 / ETag ; Section 14.21 5586 / Location ; Section 14.29 5587 / Proxy-Authenticate ; Section 14.30 5588 / Public ; Section 14.33 5589 / Range ; Section 14.34 5590 / Retry-After ; Section 14.36 5591 / RTP-Info ; Section 14.38 5592 / Scale ; Section 14.39 5593 / Session ; Section 14.42 5594 / Server ; Section 14.41 5595 / Speed ; Section 14.40 5596 / Transport ; Section 14.45 5597 / Unsupported ; Section 14.46 5598 / Vary ; Section 14.48 5599 / WWW-Authenticate ; Section 14.50 5600 / extension-header 5602 entity-header = Allow ; Section 14.6 5603 / Content-Base ; Section 14.13 5604 / Content-Encoding ; Section 14.14 5605 / Content-Language ; Section 14.15 5606 / Content-Length ; Section 14.16 5607 / Content-Location ; Section 14.17 5608 / Content-Type ; Section 14.18 5609 / Expires ; Section 14.22 and [H14.21] 5610 / Last-Modified ; Section 14.28 5611 / extension-header 5612 extension-header = message-header 5614 18.2.3 Header Syntax 5616 All header syntaxes not defined in this section are defined in 5617 section 14 of the HTTP 1.1 specification [4]. 5619 accept-credentials = "Accept-Credentials" ":" credential-decision 5620 credential-decision = ("User" "," [credential-info]) 5621 / "Proxy" 5622 / "Any" 5623 / token ; For future extensions 5624 credential-info = cred-info-data 0*("," cred-info-data) 5625 cred-info-data = DQUOTE rtsp-URI DQUOTE ";" base64 5626 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges 5627 acceptable-ranges = (range-unit *("," LWS range-unit)) 5628 / "none" 5629 range-unit = NPT / SMPTE / UTC / extension-format 5630 extension-format = token 5631 Bandwidth = "Bandwidth" ":" 1*DIGIT 5632 Blocksize = "Blocksize" ":" 1*DIGIT 5634 Cache-Control = "Cache-Control" ":" cache-directive 5635 *("," LWS cache-directive) 5637 cache-directive = cache-request-directive 5638 / cache-response-directive 5639 cache-request-directive = "no-cache" 5640 / "max-stale" ["=" delta-seconds] 5641 / "min-fresh" "=" delta-seconds 5642 / "only-if-cached" 5643 / cache-extension 5644 cache-response-directive = "public" 5645 / "private" 5646 / "no-cache" 5647 / "no-transform" 5648 / "must-revalidate" 5649 / "proxy-revalidate" 5650 / "max-age" "=" delta-seconds 5651 / cache-extension 5652 cache-extension = token ["=" (token / quoted-string)] 5653 delta-seconds = 1*DIGIT 5655 connection-creds = "Connection-Credentials" ":" credential-info 5656 connection = "Connection" ":" (connection-token) 5657 *("," connection-token) 5658 connection-token = token 5659 Content-Base = "Content-Base" ":" absoluteURL 5660 CSeq = "Cseq" ":" 1*DIGIT 5661 Proxy-Require = "Proxy-Require" ":" feature-tag 5662 *("," LWS feature-tag) 5663 Proxy-Supported = "Proxy-Supported" ":" feature-tag 5664 *("," LWS feature-tag) 5665 Public = "Public" ":" method *("," LWS method) 5666 Range = "Range" ":" ranges-spec *("," LWS ranges-spec) 5667 [ ";" "time" "=" utc-time ] 5668 ranges-spec = npt-range / utc-range / smpte-range 5669 Require = "Require" ":" feature-tag *("," LWS feature-tag) 5671 RTP-Info = "RTP-Info" ":" rtsp-info-spec 5672 *("," LWS rtsp-info-spec) 5673 rtsp-info-spec = stream-url 1*ri-parameter 5674 stream-url = quoted-url / unquoted-url 5675 unquoted-url = "url" "=" safe-url 5676 quoted-url = "url" "=" DQUOTE needquote-url DQUOTE 5677 safe-url = url 5678 needquote-url = url //That contains ; or , 5679 url = ( absoluteURL / relativeURL ) 5680 ri-parameter = ";" "seq" "=" 1*DIGIT 5681 / ";" "rtptime" "=" 1*DIGIT 5683 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 5684 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] 5685 Server = "Server" ":" ( product / comment ) 5686 *(SP (product / comment)) 5687 Session = "Session" ":" session-id 5688 [ ";" "timeout" "=" delta-seconds ] 5689 Supported = "Supported" ":" [feature-tag *("," LWS feature-tag)] 5691 Timestamp = "Timestamp" ":" *(DIGIT) ["." *(DIGIT)] [delay] 5692 delay = *(DIGIT) [ "." *(DIGIT) ] 5693 Transport = "Transport" ":" transport-spec 5694 *("," LWS transport-spec) 5695 transport-spec = transport-id *tr-parameter 5696 transport-id = transport-prot "/" profile ["/" lower-transport] 5697 ; no LWS is allowed inside transport-id 5699 transport-prot = "RTP" / token 5700 profile = "AVP" / token 5701 lower-transport = "TCP" / "UDP" / token 5702 tr-parameter = ";" ( "unicast" / "multicast" ) 5703 / ";" "source" "=" host 5704 / ";" "destination" [ "=" host ] 5705 / ";" "interleaved" "=" channel [ "-" channel ] 5706 / ";" "append" 5707 / ";" "ttl" "=" ttl 5708 / ";" "layers" "=" 1*DIGIT 5709 / ";" "port" "=" port-spec 5710 / ";" "client_port" "=" port-spec 5711 / ";" "server_port" "=" port-spec 5712 / ";" "ssrc" "=" ssrc *("/" ssrc) 5713 / ";" "client_ssrc" "=" ssrc 5714 / ";" "mode" "=" mode-spec 5715 / ";" "dest_addr" "=" addr-list 5716 / ";" "src_addr" "=" addr-list 5717 / ";" trn-param-ext 5718 port-spec = port [ "-" port ] 5719 trn-param-ext = par-name "=" trn-par-value 5720 par-name = token 5721 trn-par-value = *(unreserved / DQUOTE *TEXT DQUOTE) 5722 ttl = 1*3(DIGIT) 5723 ssrc = 8*8(HEX) 5724 channel = 1*3(DIGIT) 5725 mode-spec = ( DQUOTE mode *("," *SP mode) DQUOTE ) / mode 5726 mode = "PLAY" / "RECORD" / token 5727 addr-list = quoted-host-port *("/" quoted-host-port) 5728 quoted-host-port = DQUOTE host [":" port] DQUOTE 5730 Unsupported = "Unsupported" ":" feature-tag *("," feature-tag) 5731 User-Agent = "User-Agent" ":" ( product / comment ) 5732 0*(SP (product / comment) 5734 19 Security Considerations 5736 Because of the similarity in syntax and usage between RTSP servers 5737 and HTTP servers, the security considerations outlined in [H15] 5738 apply. Specifically, please note the following: 5740 Abuse of Server Log Information: RTSP and HTTP servers will 5741 presumably have similar logging mechanisms, and thus should 5742 be equally guarded in protecting the contents of those 5743 logs, thus protecting the privacy of the users of the 5744 servers. See [H15.1.1] for HTTP server recommendations 5745 regarding server logs. 5747 Transfer of Sensitive Information: There is no reason to believe 5748 that information transferred via RTSP may be any less 5749 sensitive than that normally transmitted via HTTP. 5750 Therefore, all of the precautions regarding the protection 5751 of data privacy and user privacy apply to implementors of 5752 RTSP clients, servers, and proxies. See [H15.1.2] for 5753 further details. 5755 Attacks Based On File and Path Names: Though RTSP URIs are 5756 opaque handles that do not necessarily have file system 5757 semantics, it is anticipated that many implementations will 5758 translate portions of the Request-URIs directly to file 5759 system calls. In such cases, file systems SHOULD follow the 5760 precautions outlined in [H15.5], such as checking for ".." 5761 in path components. 5763 Personal Information: RTSP clients are often privy to the same 5764 information that HTTP clients are (user name, location, 5765 etc.) and thus should be equally sensitive. See [H15.1] 5766 for further recommendations. 5768 Privacy Issues Connected to Accept Headers: Since may of the 5769 same "Accept" headers exist in RTSP as in HTTP, the same 5770 caveats outlined in [H15.1.4] with regards to their use 5771 should be followed. 5773 DNS Spoofing: Presumably, given the longer connection times 5774 typically associated to RTSP sessions relative to HTTP 5775 sessions, RTSP client DNS optimizations should be less 5776 prevalent. Nonetheless, the recommendations provided in 5777 [H15.3] are still relevant to any implementation which 5778 attempts to rely on a DNS-to-IP mapping to hold beyond a 5779 single use of the mapping. 5781 Location Headers and Spoofing: If a single server supports 5782 multiple organizations that do not trust each another, then 5783 it needs to check the values of Location and Content- 5784 Location header fields in responses that are generated 5785 under control of said organizations to make sure that they 5786 do not attempt to invalidate resources over which they have 5787 no authority. ([H15.4]) 5789 In addition to the recommendations in the current HTTP specification 5790 (RFC 2616 [4], as of this writing) and also of the previous RFC2068 5791 [19], future HTTP specifications may provide additional guidance on 5792 security issues. 5794 The following are added considerations for RTSP implementations. 5796 Concentrated denial-of-service attack: The protocol offers the 5797 opportunity for a remote-controlled denial-of-service 5798 attack. 5800 The attacker may initiate traffic flows to one or more IP 5801 addresses by specifying them as the destination in SETUP 5802 requests. While the attacker's IP address may be known in 5803 this case, this is not always useful in prevention of more 5804 attacks or ascertaining the attackers identity. Thus, an 5805 RTSP server SHOULD only allow client-specified destinations 5806 for RTSP-initiated traffic flows if the server has verified 5807 the client's identity, either against a database of known 5808 users using RTSP authentication mechanisms (preferably 5809 digest authentication or stronger), or other secure means. 5811 Session hijacking: Since there is no or little relation between 5812 a transport layer connection and an RTSP session, it is 5813 possible for a malicious client to issue requests with 5814 random session identifiers which would affect unsuspecting 5815 clients. The server SHOULD use a large, random and non- 5816 sequential session identifier to minimize the possibility 5817 of this kind of attack. 5819 Authentication: Servers SHOULD implement both basic and digest 5820 [8] authentication. In environments requiring tighter 5821 security for the control messages, the transport layer 5822 mechanism TLS (RFC 2246 [7]) SHOULD be used. 5824 Stream issues: RTSP only provides for stream control. Stream 5825 delivery issues are not covered in this section, nor in the 5826 rest of this draft. RTSP implementations will most likely 5827 rely on other protocols such as RTP, IP multicast, RSVP and 5828 IGMP, and should address security considerations brought up 5829 in those and other applicable specifications. 5831 Persistently suspicious behavior: RTSP servers SHOULD return 5832 error code 403 (Forbidden) upon receiving a single instance 5833 of behavior which is deemed a security risk. RTSP servers 5834 SHOULD also be aware of attempts to probe the server for 5835 weaknesses and entry points and MAY arbitrarily disconnect 5836 and ignore further requests clients which are deemed to be 5837 in violation of local security policy. 5839 20 IANA Considerations 5841 This section set up a number of registers for RTSP that should be 5842 maintained by IANA. For each registry there is a description on what 5843 it is required to contain, what specification is needed when adding a 5844 entry with IANA, and finally the entries that this document needs to 5845 register. See also the section 1.6 "Extending RTSP". There is also an 5846 IANA registration of two SDP attributes. 5848 The sections describing how to register an item uses some of the 5849 requirements level described in RFC 2434 [20], namely " First Come, 5850 First Served", "Specification Required", and "Standards Action". 5852 A registration request to IANA MUST contain the following 5853 information: 5855 o A name of the item to register according to the rules 5856 specified by the intended registry. 5858 o Indication of who has change control over the feature (for 5859 example, IETF, ISO, ITU-T, other international standardization 5860 bodies, a consortium, a particular company or group of 5861 companies, or an individual); 5863 o A reference to a further description, if available, for 5864 example (in order of preference) an RFC, a published standard, 5865 a published paper, a patent filing, a technical report, 5866 documented source code or a computer manual; 5868 o For proprietary features, contact information (postal and 5869 email address); 5871 20.1 Feature-tags 5873 20.1.1 Description 5875 When a client and server try to determine what part and functionality 5876 of the RTSP specification and any future extensions that its counter 5877 part implements there is need for a namespace. This registry 5878 contains named entries representing certain functionality. 5880 The usage of feature-tags is explained in section 10 and 11.1. 5882 20.1.2 Registering New Feature-tags with IANA 5884 The registering of feature-tags is done on a first come, first served 5885 basis. 5887 The name of the feature MUST follow these rules: The name may be of 5888 any length, but SHOULD be no more than twenty characters long. The 5889 name MUST not contain any spaces, or control characters. The 5890 registration SHALL indicate if the feature tag applies to servers 5891 only, proxies only or both server and proxies. Any proprietary 5892 feature SHALL have as the first part of the name a vendor tag, which 5893 identifies the organization. 5895 20.1.3 Registered entries 5897 The following feature-tags are in this specification defined and 5898 hereby registered. The change control belongs to the Authors and the 5899 IETF MMUSIC WG. 5901 play.basic: The minimal implementation for playback operations 5902 according to section D. Applies for both servers and 5903 proxies. 5905 play.scale: Support of scale operations for media playback. 5906 Applies only for servers. 5908 play.speed: Support of the speed functionality for playback. 5909 Applies only for servers 5911 20.2 RTSP Methods 5913 20.2.1 Description 5915 What a method is, is described in section 11. Extending the protocol 5916 with new methods allow for totally new functionality. 5918 20.2.2 Registering New Methods with IANA 5920 A new method MUST be registered through an IETF standard track 5921 document. The reason is that new methods may radically change the 5922 protocols behavior and purpose. 5924 A specification for a new RTSP method MUST consist of the following 5925 items: 5927 o A method name which follows the BNF rules for methods. 5929 o A clear specification on what action and response a request 5930 with the method will result in. Which directions the method is 5931 used, C -> S or S -> C or both. How the use of headers, if 5932 any, modifies the behavior and effect of the method. 5934 o A list or table specifying which of the registered headers 5935 that are allowed to use with the method in request or/and 5936 response. 5938 o Describe how the method relates to network proxies. 5940 20.2.3 Registered Entries 5942 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 5943 GET_PARAMETER, OPTIONS, PAUSE, PING, PLAY, REDIRECT, SETUP, 5944 SET_PARAMETER, and TEARDOWN. 5946 20.3 RTSP Status Codes 5948 20.3.1 Description 5950 A status code is the three digit numbers used to convey information 5951 in RTSP response messages, see 7. The number space is limited and 5952 care should be taken not to fill the space. 5954 20.3.2 Registering New Status Codes with IANA 5956 A new status code can only be registered by an IETF standards track 5957 document. A specification for a new status code MUST specify the 5958 following: 5960 o The requested number. 5962 o A description what the status code means and the expected 5963 behavior of the sender and receiver of the code. 5965 20.3.3 Registered Entries 5967 RFCXXX, registers the numbered status code defined in the BNF entry 5968 "Status-Code" except "extension-code" in section 18.2.2. 5970 20.4 RTSP Headers 5972 20.4.1 Description 5974 By specifying new headers a method(s) can be enhanced in many 5975 different ways. An unknown header will be ignored by the receiving 5976 entity. If the new header is vital for a certain functionality, a 5977 feature-tag for the functionality can be created and demanded to be 5978 used by the counter-part with the inclusion of a Require header 5979 carrying the feature-tag. 5981 20.4.2 Registering New Headers with IANA 5983 A public available specification is required to register a header. 5984 The specification SHOULD be a standards document, preferable an IETF 5985 RFC. 5987 The specification MUST contain the following information: 5989 o The name of the header. 5991 o A BNF specification of the header syntax. 5993 o A list or table specifying when the header may be used, 5994 encompassing all methods, their request or response, the 5995 direction (C -> S or S -> C). 5997 o How the header is to be handled by proxies. 5999 o A description of the purpose of the header. 6001 20.4.3 Registered entries 6003 All headers specified in section 14 in RFCXXXX are to be registered. 6005 Furthermore the following RTSP headers defined in other 6006 specifications are registered: 6008 o x-wap-profile defined in [37]. 6010 o x-wap-profile-diff defined in [37]. 6012 o x-wap-profile-warning defined in [37]. 6014 o x-predecbufsize defined in [37]. 6016 o x-initpredecbufperiod defined in [37]. 6018 o x-initpostdecbufperiod defined in [37]. 6020 The use of "X-" is NOT RECOMMENDED but the above headers in the 6021 register list was defined prior to the clarification. 6023 20.5 Transport Header registries 6025 The transport header contains a number of parameters which have 6026 possibilities for future extensions. Therefore registries for these 6027 needs to be defined. 6029 20.5.1 Transport Protocols 6031 A registry for the parameter transport-protocol SHALL be defined with 6032 the following rules: 6034 o Registering require an public available standards 6035 specification. 6037 o A contact person or organization with address and email. 6039 o A value definition that are following the BNF token 6040 definition. 6042 o A describing text that explains how the registered value are 6043 used in RTSP. 6045 This specification registers 1 value: 6047 o Use of the RTP [17] protocol for media transport. The usage 6048 is explained in RFC XXXX, appendix B.1. 6050 20.5.2 Profile 6052 A registry for the parameter profile SHALL be defined with the 6053 following rules: 6055 o Registering requires public available standards specification. 6057 o A contact person or organization with address and email. 6059 o A value definition that are following the BNF token 6060 definition. 6062 o A definition of which Transport protocol(s) that this profile 6063 is valid for. 6065 o A describing text that explains how the registered value are 6066 used in RTSP. 6068 This specification registers 1 value: 6070 o The "RTP profile for audio and video conferences with minimal 6071 control" [3] MUST only be used when the transport 6072 specification's transport-protocol is "RTP". 6074 20.5.3 Lower Transport 6076 A registry for the parameter lower-transport SHALL be defined with 6077 the following rules: 6079 o Registering requires public available standards specification. 6081 o A contact person or organization with address and email. 6083 o A value definition that are following the BNF token 6084 definition. 6086 o A text describing how the registered value are used in RTSP. 6088 This specification registers 2 values: 6090 UDP: Indicates the use of the "User datagram protocol" [9] for 6091 media transport. 6093 TCP: Indicates the use Transmission control protocol [10] for 6094 media transport. 6096 20.5.4 Transport modes 6098 A registry for the transport parameter mode SHALL be defined with the 6099 following rules: 6101 o Registering requires an IETF standard tracks document. 6103 o A contact person or organization with address and email. 6105 o A value definition that are following the BNF token 6106 definition. 6108 o A describing text that explains how the registered value are 6109 used in RTSP. 6111 This specification registers 2 values: 6113 PLAY: See RFC XXXX. 6115 RECORD: See RFC XXXX. 6117 20.6 Cache Directive Extensions 6119 There exist a number of cache directives which can be sent in the 6120 Cache-Control header. A registry for this cache directives SHALL be 6121 defined with the following rules: 6123 o Registering requires an IETF standard tracks document. 6125 o A registration is required to contain a contact person. 6127 o Name of the directive and a definition of the value, if any. 6129 o Specification if it is an request or response directive. 6131 o A describing text that explains how the cache directive is 6132 used for RTSP controlled media streams. 6134 This specification registers the following values: 6136 no-cache: 6138 public: 6140 private: 6142 no-transform: 6144 only-if-cached: 6146 max-stale: 6148 min-fresh: 6150 must-revalidate: 6152 proxy-revalidate: 6154 max-age: 6156 20.7 Accept-Credentials policies 6158 In section 17.3.1 three policies for how to handle certificates. 6160 Further policies may be defined and SHALL be registered with IANA 6161 using the following rules: 6163 o Registering requires an IETF standard tracks document. 6165 o A registration is required name a contact person. 6167 o Name of the policy. 6169 o A describing text that explains how the policy works for 6170 handling the certificates. 6172 This specification registers the following values: 6174 Any 6176 Proxy 6178 User 6180 20.8 URI Schemes 6182 This specification defines two URI schemes ("rtsp" and "rtsps") and 6183 reserves a third one ("rtspu"). 6185 This will need to be done in accordance with RFC 2717. 6187 20.9 SDP attributes 6189 This specification defines two SDP [2] attributes that it is 6190 requested that IANA register. 6192 SDP Attribute ("att-field"): 6194 Attribute name: range 6195 Long form: Media Range Attribute 6196 Type of name: att-field 6197 Type of attribute: Media and session level 6198 Subject to charset: No 6199 Purpose: RFC XXXX 6200 Reference: RFC XXXX 6201 Values: See ABNF definition. 6203 Attribute name: control 6204 Long form: RTSP control URI 6205 Type of name: att-field 6206 Type of attribute: Media and session level 6207 Subject to charset: No 6208 Purpose: RFC XXXX 6209 Reference: RFC XXXX 6210 Values: Absolute or Relative URIs. 6212 Attribute name: etag 6213 Long form: Entity Tag 6214 Type of name: att-field 6215 Type of attribute: Media and session level 6216 Subject to charset: No 6217 Purpose: RFC XXXX 6218 Reference: RFC XXXX 6219 Values: See ABNF definition 6221 A RTSP Protocol State Machine 6223 The RTSP session state machine describes the behavior of the protocol 6224 from RTSP session initialization through RTSP session termination. 6226 The State machine is defined on a per session basis which is uniquely 6227 identified by the RTSP session identifier. The session may contain 6228 one or more media streams depending on state. If a single media 6229 stream is part of the session it is in non-aggregated control. If two 6230 or more is part of the session it is in aggregated control. 6232 The below state machine is a normative description of the protocols 6233 behavior. However, in case of ambiguity with the earlier parts of 6234 this specification, the description in the earlier parts SHALL take 6235 precedence. 6237 A.1 States 6239 The state machine contains three states, described below. For each 6240 state there exist a table which shows which requests and events that 6241 is allowed and if they will result in a state change. 6243 Init: Initial state no session exist. 6245 Ready: Session is ready to start playing. 6247 Play: Session is playing, i.e. sending media stream data in the 6248 direction S -> C. 6250 A.2 State variables 6252 This representation of the state machine needs more than its state to 6253 work. A small number of variables are also needed and is explained 6254 below. 6256 NRM: The number of media streams part of this session. 6258 RP: Resume point, the point in the presentation time line at 6259 which a request to continue will resume from. A time format 6260 for the variable is not mandated. 6262 A.3 Abbreviations 6264 To make the state tables more compact a number of abbreviations are 6265 used, which are explained below. 6267 IFI: IF Implemented. 6269 md: Media 6271 PP: Pause Point, the point in the presentation time line at 6272 which the presentation was paused. 6274 Prs: Presentation, the complete multimedia presentation. 6276 RedP: Redirect Point, the point in the presentation time line at 6277 which a REDIRECT was specified to occur. 6279 SES: Session. 6281 A.4 State Tables 6283 This section contains a table for each state. The table contains all 6284 the requests and events that this state is allowed to act on. The 6285 events which is method names are, unless noted, requests with the 6286 given method in the direction client to server (C -> S). In some 6287 cases there exist one or more requisite. The response column tells 6288 what type of response actions should be performed. Possible actions 6289 that is requested for an event includes: response codes, e.g. 200, 6290 headers that MUST be included in the response, setting of state 6291 variables, or setting of other session related parameters. The new 6292 state column tells which state the state machine changes to. 6294 The response to valid request meeting the requisites is normally a 6295 2xx (SUCCESS) unless other noted in the response column. The 6296 exceptions needs to be given a response according to the response 6297 column. If the request does not meet the requisite, is erroneous or 6298 some other type of error occur the appropriate response code MUST be 6299 sent. If the response code is a 4xx the session state is unchanged. A 6300 response code of 3rr will result in that the session is ended and its 6301 state is changed to Init. A response code of 304 results in no state 6302 change. However there exist restrictions to when a 3xx response may 6303 be used. A 5xx response SHALL not result in any change of the session 6304 state, except if the error is not possible to recover from. A 6305 unrecoverable error SHALL result the ending of the session. As it in 6306 the general case can't be determined if it was a unrecoverable error 6307 or not the client will be required to test. In the case that the next 6308 request after a 5xx is responded with 454 (Session Not Found) the 6309 client knows that the session has ended. 6311 The server will timeout the session after the period of time 6312 specified in the SETUP response, if no activity from the client is 6313 detected. Therefore there exist a timeout event for all states 6314 except Init. 6316 In the case that NRM=1 the presentation URI is equal to the media 6317 URI. For NRM>1 the presentation URI MUST be other than any of the 6318 medias that are part of the session. This applies to all states. 6320 Event Prerequisite Response 6321 ______________________________________________________________ 6322 DESCRIBE Needs REDIRECT 3rr Redirect 6323 DESCRIBE 200, Session description 6324 OPTIONS Session ID 200, Reset session timeout timer 6325 OPTIONS 200 6326 SET_PARAMETER Valid parameter 200, change value of parameter 6327 GET_PARAMETER Valid parameter 200, return value of parameter 6329 Table 13: None state-machine changing events 6331 The methods in Table 13 do not have any effect on the state machine 6332 or the state variables. However some methods do change other session 6333 related parameters, for example SET_PARAMETER which will set the 6334 parameter(s) specified in its body. 6336 The initial state of the state machine, see Table 14 can only be left 6337 by processing a correct SETUP request. As seen in the table the two 6338 state variables are also set by a correct request. This table also 6339 shows that a correct SETUP can in some cases be redirected to another 6340 Action Requisite New State Response 6341 _____________________________________________________________ 6342 SETUP Ready NRM=1, RP=0.0 6343 SETUP Needs Redirect Init 3rr Redirect 6344 S -> C:REDIRECT No Session hdr Init Terminate all SES 6346 Table 14: State: Init 6348 URI and/or server by a 3rr response. 6350 Action Requisite New State Response 6352 _____________________________________________________________________ 6353 SETUP New URI Ready NRM+=1 6354 SETUP Setten up URI Ready Change transport param 6355 TEARDOWN Prs URI,NRM>1 Init No session hdr 6356 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 6357 TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1 6358 PLAY Prs URI, No range Play Play from RP 6359 PLAY Prs URI, Range Play according to range 6360 PAUSE Prs URI Ready Return PP 6361 S -> C:REDIRECT Range hdr Ready Set RedP 6362 S -> C:REDIRECT no range hdr Init Session is removed 6363 Timeout Init 6364 RedP reached Ready TEARDOWN of session 6366 Table 15: State: Ready 6368 In the Ready state, see Table 15, some of the actions are depending 6369 on the number of media streams (NRM) in the session, i.e. aggregated 6370 or non-aggregated control. A setup request in the ready state can 6371 either add one more media stream to the session or if the media 6372 stream (same URI) already is part of the session change the transport 6373 parameters. TEARDOWN is depending on both the Request-URI and the 6374 number of media stream within the session. If the Request-URI is the 6375 presentations URI the whole session is torn down. If a media URI is 6376 used in the TEARDOWN request and more than one media exist in the 6377 session, the session will remain and a session header MUST be 6378 returned in the response. If only a single media stream remains in 6379 the session when performing a TEARDOWN with a media URI the session 6380 is removed. The number of media streams remaining after tearing down 6381 a media stream determines the new state. 6383 The Play state table, see Table 16, is the largest. The table 6384 Action Requisite New State Response 6385 _____________________________________________________________________ 6386 PAUSE PrsURI,No range Ready Set RP to present point 6387 PAUSE PrsURI,Range>now Play Set RP & PP to given p. 6388 PAUSE PrsURI,Range1 Media plays Play No action 6392 End of range Play Set RP = End of range 6393 SETUP New URI Play 455 6394 SETUP Setuped URI Play 455 6395 SETUP Setuped URI, IFI Play Change transport param. 6396 TEARDOWN Prs URI,NRM>1 Init No session hdr 6397 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 6398 TEARDOWN md URI Play 455 6399 S -> C:REDIRECT Range hdr Play Set RedP 6400 S -> C:REDIRECT no range hdr Init Session is removed 6401 RedP reached Play TEARDOWN of session 6402 Timeout Init Stop Media playout 6404 Table 16: State: Play 6406 contains an number of requests that has presentation URI as a 6407 prerequisite on the Request-URI, this is due to the exclusion of 6408 non-aggregated stream control in sessions with more than one media 6409 stream. 6411 To avoid inconsistencies between the client and server, automatic 6412 state transitions are avoided. This can be seen at for example "End 6413 of media" event when all media has finished playing, the session 6414 still remain in Play state. An explicit PAUSE request MUST be sent to 6415 change the state to Ready. It may appear that there exist two 6416 automatic transitions in "RedP reached" and "PP reached", however 6417 they are requested and acknowledge before they take place. The time 6418 at which the transition will happen is known by looking at the range 6419 header. If the client sends request close in time to these 6420 transitions it needs to be prepared for getting error message as the 6421 state may or may not have changed. 6423 B Media Transport Alternatives 6425 This section defines how certain combinations of protocols, profiles 6426 and lower transports are used. This includes the usage of the 6427 Transport header's general source and destination parameters 6428 "src_addr" and "dest_addr". 6430 B.1 RTP 6432 This section defines the interaction of RTSP with respect to the RTP 6433 protocol [17]. It also defines any necessary media transport 6434 signalling with regards to RTP. 6436 The available RTP profiles and lower layer transports are described 6437 below along with rules on signalling the available combinations. 6439 B.1.1 AVP 6441 The usage of the "RTP Profile for Audio and Video Conferences with 6442 Minimal Control" [3] when using RTP for media transport over 6443 different lower layer transport protocols is defined below in regards 6444 to RTSP. 6446 One such case is defined within this document, the use of embedded 6447 (interleaved) binary data as defined in section 12. The usage of 6448 this method is indicated by include the "interleaved" parameter. 6450 When using embedded binary data the "src_addr" and "dest_addr" SHALL 6451 NOT be used. This addressing and multiplexing is used as defined with 6452 use of channel numbers and the interleaved parameter. 6454 B.1.2 AVP/UDP 6456 This part describes sending of RTP [17] over lower transport layer 6457 UDP [9] according to the profile "RTP Profile for Audio and Video 6458 Conferences with Minimal Control" defined in RFC 3551 [3]. This 6459 profiles requires one or two uni- or bi-directional UDP flows per 6460 media stream. The first UDP flow is for RTP and the second is for 6461 RTCP. Embedding of RTP data with the RTSP messages, in accordance 6462 with section 12, SHOULD NOT be performed when RTSP messages are 6463 transported over unreliable transport protocols, like UDP [9]. 6465 The RTP/UDP and RTCP/UDP flows can be established in two ways using 6466 the Transport header's parameters. The way provided in RFC 2326 was 6467 to use the necessary parameters from the set of "source", 6468 "destination", "client_port", and "server_port". This has the 6469 advantage of being compatible with all RTP capable RTSP servers and 6470 clients. However this method does not provide the means to specify 6471 non-continues port ranges for RTP and RTCP. The other way is to use 6472 the parameters "src_addr", and "dest_addr". This method provides 6473 total flexibility in specifying address and port number for each 6474 transport flow. However the disadvantage is that it is not supported 6475 by non-updated clients, i.e. clients not supporting the "play.basic" 6476 feature-tag. 6478 When using the "source", "destination", "client_port", and 6479 "server_port" the packets are be addressed in the following way for 6480 media playback: 6482 o RTP/UDP packet from the server to the client SHALL be sent to 6483 the address specified in the "destination" parameter and first 6484 even port number given in client_port range. If only an RTP 6485 port is to be specified, then only that even port number SHALL 6486 be given, i.e. no range including an odd number SHALL be used. 6488 o The server SHOULD send its RTP/UDP packets from the address 6489 specified in "source" parameter and from the first even port 6490 number specified in "server_port" parameter. 6492 o When the range specified in the "client_port" parameter 6493 contains at least two port numbers, the RTCP/UDP packets from 6494 server to client SHALL be sent to the address specified in the 6495 "destination" parameter and using the first odd port number 6496 belonging to the range specified in the client_port parameter. 6498 o The Server SHOULD send its RTCP/UDP packets from the address 6499 specified in "source" parameter and from the first odd port 6500 number greater than the RTP port number specified in 6501 "server_port" parameter. 6503 o RTCP/UDP packets from the client to the server SHALL be sent 6504 to the address specified in the "source" parameter and first 6505 odd port number greater than the RTP port number given in 6506 server_port range. 6508 o The client SHOULD send its RTCP/UDP packets from the address 6509 specified in "destination" parameter and from the first odd 6510 port number specified in client_port" parameter. 6512 The usage of "src_addr" and "dest_addr" parameters to specify the 6513 address and port numbers is performed in the following way for media 6514 playback, i.e. Mode=PLAY: 6516 o The "src_addr" and "dest_addr" parameters MUST contain either 6517 1 or 2 address and port pairs. 6519 o Each address and port pair MUST contain both and address and a 6520 port number. 6522 o The first address and port pair given in either of the 6523 parameters applies to the RTP stream. The second address and 6524 port pair if present applies to the RTCP stream. 6526 o The RTP/UDP packets from the server to the client SHALL be 6527 sent to the address and port given by first address and port 6528 pair of the "dest_addr" parameter. 6530 o The RTCP/UDP packets from the server to the client SHALL be 6531 sent to the address and port given by the second address and 6532 port pair of the "dest_addr" parameter. If no second pair is 6533 given RTCP SHALL NOT be sent. 6535 o The RTCP/UDP packets from the client to the server SHALL be 6536 sent to the address and port given by the second address and 6537 port pair of the "src_addr" parameter. If no second pair is 6538 given RTCP SHALL NOT be sent. 6540 o RTP and RTCP Packets SHOULD be sent from the corresponding 6541 receiver port, i.e. RTCP packets from server should be sent 6542 from the "src_addr" parameters second address port pair. 6544 B.1.3 AVP/TCP 6546 Note that this combination is not yet defined using sperate TCP 6547 connections. However the use of embedded (interleaved) binary data 6548 transported on the RTSP connection is possible as specified in 6549 section 12. When using this declared combination of interleaved 6550 binary data the RTSP messages MUST be transported over TCP. 6552 A possible future for this profile would be to define the 6553 use of a combination of the two drafts "Connection-Oriented 6554 Media Transport in SDP" [38] and "Framing RTP and RTCP 6555 Packets over Connection-Oriented Transport" [39]. However 6556 as this work is not finished, this functionality is 6557 unspecified. 6559 B.1.4 Handling NPT Jumps in the RTP Media Layer 6561 RTSP allows media clients to control selected, non-contiguous 6562 sections of media presentations, rendering those streams with an RTP 6563 media layer[17]. Such control allows jumps to be created in NPT 6564 timeline of the RTSP session. For example, jumps in NPT can be caused 6565 by multiple ranges in the range specifier of a PLAY request or 6566 through a "seek" opertaion on an RTSP session which involves a PLAY, 6567 PAUSE, PLAY scenario where a new NPT is set for the session. The 6568 media layer rendering the RTP stream should not be affected by jumps 6569 in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be 6570 continuous and monotonic across jumps of NPT. 6572 We cannot assume that the RTSP client can communicate with 6573 the RTP media agent, as the two may be independent 6574 processes. If the RTP timestamp shows the same gap as the 6575 NPT, the media agent will assume that there is a pause in 6576 the presentation. If the jump in NPT is large enough, the 6577 RTP timestamp may roll over and the media agent may believe 6578 later packets to be duplicates of packets just played out. 6580 As an example, assume a clock frequency of 8000 Hz, a packetization 6581 interval of 100 ms and an initial sequence number and timestamp of 6582 zero. 6584 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 6585 CSeq: 4 6586 Session: abcdefg 6587 Range: npt=10-15 6589 S->C: RTSP/1.0 200 OK 6590 CSeq: 4 6591 Session: abcdefg 6592 Range: npt=10-15 6593 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0; 6594 rtptime=0 6596 The ensuing RTP data stream is depicted below: 6598 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6599 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6600 . . . 6601 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 6603 Immediately after the end of the play range, the client follows up 6604 with a request to PLAY from a new NPT. 6606 C->S: PAUSE rtsp://xyz/fizzle RTSP/1.0 6607 CSeq: 5 6608 Session: abcdefg 6610 S->C: RTSP/1.0 200 OK 6611 CSeq: 5 6612 Session: abcdefg 6613 Range: npt=15-15 6615 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 6616 CSeq: 6 6617 Session: abcdefg 6618 Range: npt=18-20; 6620 S->C: RTSP/1.0 200 OK 6621 CSeq: 6 6622 Session: abcdefg 6623 Range: npt=18-20 6624 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=50; 6625 rtptime=40100 6627 The ensuing RTP data stream is depicted below: 6629 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 6630 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 6631 . . . 6632 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 6634 In this example, first, NPT 10 through 15 is played, then the client 6635 request the server to skip ahead and play NPT 18 through 20. The 6636 first segment is presented as RTP packets with sequence numbers 0 6637 through 49 and timestamp 0 through 39,200. The second segment 6638 consists of RTP packets with sequence number 50 through 69, with 6639 timestamps 40,100 through 55,200. While there is a gap in the NPT, 6640 there is no gap in the sequence number space of the RTP data stream. 6642 The RTP timestamp gap is present in the above example due to the time 6643 it takes to perform the second play request, in this case 12.5 ms 6644 (100/8000). To avoid this gap in playback due to the time it takes to 6645 perform RTSP requests, a PLAY request with multiple ranges needs to 6646 be specified. That would result in the following example: 6648 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 6649 CSeq: 4 6650 Session: abcdefg 6651 Range: npt=10-15;npt=18-20 6653 S->C: RTSP/1.0 200 OK 6654 CSeq: 4 6655 Session: abcdefg 6656 Range: npt=10-15 6657 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0; 6658 rtptime=0 6660 The ensuing RTP data stream is depicted below: 6662 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6663 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6664 . . . 6665 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 6666 S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 6667 S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 6668 . . . 6669 S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 6671 B.1.5 Handling RTP Timestamps after PAUSE 6673 During a PAUSE / PLAY interaction in an RTSP session, the duration of 6674 time for which the RTP transmission was halted MUST be reflected in 6675 the RTP timestamp of each RTP stream. The duration can be calculated 6676 for each RTP stream as the time elapsed from when the last RTP packet 6677 was sent before the PAUSE request was received and when the first RTP 6678 packet was sent after the subsequent PLAY request was received. The 6679 duration includes all latency incurred and processing time required 6680 to complete the request. 6682 The RTP RFC [17] states that: The RTP timestamp for each 6683 unit[packet] would be related to the wallclock time at 6684 which the unit becomes current on the virtual presentation 6685 timeline. 6687 In order to satisfy the requirements of [17], the RTP timestamp space 6688 needs to increase continuously with real time. While this is not 6689 optimal for stored media, it is required for RTP and RTCP to function 6690 as intended. Using a continuous RTP timestamp space allows the same 6691 timestamp model for both stored and live media and allows better 6692 opportunity to integrate both types of media under a single control. 6694 As an example, assume a clock frequency of 8000 Hz, a packetization 6695 interval of 100 ms and an initial sequence number and timestamp of 6696 zero. 6698 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 6699 CSeq: 4 6700 Session: abcdefg 6701 Range: npt=10-15; 6703 S->C: RTSP/1.0 200 OK 6704 CSeq: 4 6705 Session: abcdefg 6706 Range: npt=10-15 6707 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=0; 6708 rtptime=0 6710 The ensuing RTP data stream is depicted below: 6712 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6713 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6714 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 6715 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 6717 The client then sends a PAUSE request: 6719 C->S: PAUSE rtsp://xyz/fizzle RTSP/1.0 6720 CSeq: 5 6721 Session: abdcdefg 6723 S->C: RTSP/1.0 200 OK 6724 CSeq: 5 6725 Session: abcdefg 6726 Range: npt=10.4-15 6728 20 seconds elapse and then the client sends a PLAY request. In 6729 addition the server requires 15 ms to process the request: 6731 C->S: PLAY rtsp://xyz/fizzle RTSP/1.0 6732 CSeq: 6 6733 Session: abcdefg 6735 S->C: RTSP/1.0 200 OK 6736 CSeq: 6 6737 Session: abcdefg 6738 Range: npt=10.4-15 6739 RTP-Info: url= rtsp://xyz/fizzle/audiotrack;seq=4; 6740 rtptime=164400 6742 The ensuing RTP data stream is depicted below: 6744 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 6745 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 6746 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 6748 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 6749 server. After 20 seconds a PLAY is received by the server which take 6750 15ms to process. The duration of time for which the session was 6751 paused is reflected in the RTP timestamp of the RTP packets sent 6752 after this PLAY request. 6754 A client can use the RTSP range header and RTP-Info header to map NPT 6755 time of a presentation with the RTP timestamp. 6757 Note: In RFC 2326 [1], this matter was not clearly defined and was 6758 misunderstood commonly. Therefore, clients SHOULD expect servers to 6759 break the continuity of the RTP timestamp space in various arbitrary 6760 manners after a PAUSE request. In these cases, it is RECOMMENDED that 6761 clients accept the RTP stream after the pause with appropriate 6762 mappings provided by the RTP-Info and Range headers. 6764 B.1.6 RTSP / RTP Integration 6766 For certain datatypes, tight integration between the RTSP layer and 6767 the RTP layer will be necessary. This by no means precludes the above 6768 restrictions. Combined RTSP/RTP media clients should use the RTP-Info 6769 field to determine whether incoming RTP packets were sent before or 6770 after a seek or before or after a PAUSE. 6772 B.1.7 Scaling with RTP 6774 For scaling (see Section 14.39), RTP timestamps should correspond to 6775 the playback timing. For example, when playing video recorded at 30 6776 frames/second at a scale of two and speed (Section 14.40) of one, the 6777 server would drop every second frame to maintain and deliver video 6778 packets with the normal timestamp spacing of 3,000 per frame, but NPT 6779 would increase by 1/15 second for each video frame. 6781 Note: The above scaling puts requirements on the media 6782 codec or a media stream to support it. For example motion 6783 JPEG or other non-predictive video coding can easier handle 6784 the above example. 6786 B.1.8 Maintaining NPT synchronization with RTP timestamps 6788 The client can maintain a correct display of NPT by noting the RTP 6789 timestamp value of the first packet arriving after repositioning. 6790 The sequence parameter of the RTP-Info (Section 14.38) header 6791 provides the first sequence number of the next segment. 6793 B.1.9 Continuous Audio 6795 For continuous audio, the server SHOULD set the RTP marker bit at the 6796 beginning of serving a new PLAY request. This allows the client to 6797 perform playout delay adaptation. 6799 B.1.10 Multiple Sources in an RTP Session 6801 Note that more than one SSRC MAY be sent in the media stream. 6802 However, without further extensions RTSP can't synchronize more than 6803 the single one indicated in the Transport header. In these cases RTCP 6804 needs to be used for synchronization. 6806 B.1.11 Usage of SSRCs and the RTCP BYE Message During an RTSP Session 6808 The RTCP BYE message indicates the end of use of a given SSRC. If all 6809 sources leave an RTP session, it can, in most cases, be assumed to 6810 have ended. Therefore, a client or server SHALL NOT send a RTCP BYE 6811 message until it has finished using a SSRC. A server SHOULD keep 6812 using a SSRC until the RTP session is terminated. Prologing the use 6813 of a SSRC allows the established synchronization context associated 6814 with that SSRC to be used to sychronize subsequent PLAY requests even 6815 if the PLAY response is late. Additionally, changing the server side 6816 SSRC will prevent the server from synchronizing the new SSRC within 6817 RTSP as it is connected to the one declared in the ssrc parameter in 6818 the Transport header. 6820 An SSRC collision with the SSRC that transmits media does also have 6821 consequences, as it will force the media sender to change its SSRC in 6822 accordance with the RTP specification [17]. This will result in a 6823 loss of synchronization context, and require any receiver to wait for 6824 RTCP sender reports for all media requiring synchronization before 6825 being able to play out synchronized. Due to these reasons a client 6826 joining a session should take care to not select the same SSRC as the 6827 server. Any SSRC signalled in the Transport header SHOULD be avoided. 6828 Also a client detecting a collision prior to sending any RTP or RTCP 6829 messages can also select a new SSRC. 6831 B.2 Future Additions 6833 It is the intention that any future protocol or profile regarding 6834 both for media delivery and lower transport should be easy to add to 6835 RTSP. This section provides the necessary steps that needs to be 6836 meet. 6838 The following things needs to be considered when adding a new 6839 protocol of profile for use with RTSP: 6841 o The protocol or profile needs to define a name tag 6842 representing it. This tag is required to be a ABNF "token" to 6843 be possible to use in the Transport header specification. 6845 o The useful combinations of protocol/profile/lower-layer needs 6846 to be defined and for each combination declare the necessary 6847 parameters to use in the Transport header. 6849 o For new media protocols the interaction with RTSP needs to be 6850 addressed. One important factor will be the media 6851 synchronization. 6853 See the IANA section (20) for information how to register new 6854 attributes. 6856 C Use of SDP for RTSP Session Descriptions 6858 The Session Description Protocol (SDP, RFC 2327 [2]) may be used to 6859 describe streams or presentations in RTSP. This description is 6860 typically returned in reply to a DESCRIBE request on an URI from a 6861 server to a client, or received via HTTP from a server to a client. 6863 This appendix describes how an SDP file determines the operation of 6864 an RTSP session. SDP as is provides no mechanism by which a client 6865 can distinguish, without human guidance, between several media 6866 streams to be rendered simultaneously and a set of alternatives 6867 (e.g., two audio streams spoken in different languages). However the 6868 SDP extension "Grouping of Media Lines in the Session Description 6869 Protocol (SDP)" [40] may provide such functionality depending on 6870 need. Also future grouping semantics may in the future be developed. 6872 C.1 Definitions 6873 The terms "session-level", "media-level" and other key/attribute 6874 names and values used in this appendix are to be used as defined in 6875 SDP (RFC 2327 [2]): 6877 C.1.1 Control URI 6879 The "a=control:" attribute is used to convey the control URI. This 6880 attribute is used both for the session and media descriptions. If 6881 used for individual media, it indicates the URI to be used for 6882 controlling that particular media stream. If found at the session 6883 level, the attribute indicates the URI for aggregate control 6884 (presentation URI). The session level URI SHALL be different from any 6885 media level URI. The presence of a session level control attribute 6886 SHALL be interpreted as support for aggregated control. The control 6887 attribute SHALL be present on media level unless the presentation 6888 only contains a single media stream, in which case the attribute MAY 6889 only be present on the session level. 6891 control-attribute = "a=" "control" ":" url 6893 Example: 6895 a=control:rtsp://example.com/foo 6897 This attribute MAY contain either relative and absolute URIs, 6898 following the rules and conventions set out in RFC 2396 [13]. 6899 Implementations SHALL look for a base URI in the following order: 6901 1. the RTSP Content-Base field; .IP 2. the RTSP Content- 6902 Location field; .IP 3. the RTSP Request-URI. 6904 If this attribute contains only an asterisk (*), then the URI SHALL 6905 be treated as if it were an empty embedded URI, and thus inherit the 6906 entire base URI. 6908 The URI handling for SDPs from container files need special 6909 consideration. For example in a container file with the URI: 6910 "rtsp://example.com/container.mp4". Lets assume this URI as base URI, 6911 and a media level URI: "rtsp://example.com/container.mp4/trackID=2". 6912 A relative media level URI that resolves in accordance with RFC 2396 6913 [13] to the above given media URI are: "container.mp4/trackID=2". It 6914 is usually not desirable to need to include in or modify the SDP 6915 stored within the container file with the server local name of the 6916 container file. To avoid this, one can modify the base URI used to 6917 include a trailing slash, e.g. "rtsp://example.com/container.mp4/". 6918 In this case the relative URI for the media will only need to be: 6919 "trackID=2". However this will also mean that using "*" in the SDP 6920 will result in control URI including the trailing slash, i.e. 6921 "rtsp://example.com/container.mp4/". 6923 C.1.2 Media Streams 6925 The "m=" field is used to enumerate the streams. It is expected that 6926 all the specified streams will be rendered with appropriate 6927 synchronization. If the session is a multicast, the port number 6928 indicated SHOULD be used for reception. The client MAY try to 6929 override the destination port, through the Transport header. The 6930 servers MAY allow this, the response will indicate if allowed or not. 6931 If the session is unicast, the port number is the ones RECOMMENDED by 6932 the server to the client, about which receiver ports to use; the 6933 client MUST still include its receiver ports in its SETUP request. 6934 The client MAY ignore this recommendation. If the server has no 6935 preference, it SHOULD set the port number value to zero. 6937 The "m=" lines contain information about what transport protocol, 6938 profile, and possibly lower-layer is to be used for the media stream. 6939 The combination of transport, profile and lower layer, like 6940 RTP/AVP/UDP needs to be defined for how to be used with RTSP. The 6941 currently defined combinations are defined in section B, further 6942 combinations MAY be specified. 6944 TODO: Write something about the usage of Grouping of media line, RFC 6945 3388 [40]. 6947 Example: 6949 m=audio 0 RTP/AVP 31 6951 C.1.3 Payload Type(s) 6953 The payload type(s) are specified in the "m=" field. In case the 6954 payload type is a static payload type from RFC 3551 [3], no other 6955 information may be required. In case it is a dynamic payload type, 6956 the media attribute "rtpmap" is used to specify what the media is. 6957 The "encoding name" within the "rtpmap" attribute may be one of those 6958 specified in RFC 3551 (Sections 5 and 6), or an MIME type registered 6959 with IANA, or an experimental encoding as specified in SDP (RFC 2327 6960 [2]). Codec-specific parameters are not specified in this field, but 6961 rather in the "fmtp" attribute described below. 6963 C.1.4 Format-Specific Parameters 6965 Format-specific parameters are conveyed using the "fmtp" media 6966 attribute. The syntax of the "fmtp" attribute is specific to the 6967 encoding(s) that the attribute refers to. Note that some of the 6968 format specific parameters may be specified outside of the fmtp 6969 parameters, like for example the "ptime" attribute for most audio 6970 encodings. 6972 C.1.5 Range of Presentation 6974 The "a=range" attribute defines the total time range of the stored 6975 session or an individual media. Non-seekable live sessions can be 6976 indicated, while the length of live sessions can be deduced from the 6977 "t" and "r" SDP parameters. 6979 The attribute is both a session and a media level attribute. For 6980 presentations that contains media streams of the same durations, the 6981 range attribute SHOULD only be used at session-level. In case of 6982 different length the range attribute MUST be given at media level for 6983 all media, and SHOULD NOT be given at session level. If the attribute 6984 is present at both media level and session level the media level 6985 values SHALL be used. 6987 The unit is specified first, followed by the value range. The units 6988 and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY 6989 be extended with further formats. Any open ended range (start-), i.e. 6990 without stop range, is of unspecified duration and SHALL be 6991 considered as non-seekable content unless this property is 6992 overridden. 6994 This attribute is defined in ABNF [5] as: 6996 a-range-def = "a" "=" "range" ":" ranges-specifier CRLF 6998 Examples: 7000 a=range:npt=0-34.4368 7001 a=range:clock=19971113T2115-19971113T2203 7002 Non seekable stream of unknown duration: 7003 a=range:npt=0- 7005 C.1.6 Time of Availability 7007 The "t=" field MUST contain suitable values for the start and stop 7008 times for both aggregate and non-aggregate stream control. The 7009 server SHOULD indicate a stop time value for which it guarantees the 7010 description to be valid, and a start time that is equal to or before 7011 the time at which the DESCRIBE request was received. It MAY also 7012 indicate start and stop times of 0, meaning that the session is 7013 always available. 7015 For sessions that are of live type, i.e. specific start time, unknown 7016 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 7017 to indicate the start time of the event. The stop time SHOULD be 7018 given so that the live event will with high probability have ended at 7019 that time, while still not be unnecessary long into the future. 7021 C.1.7 Connection Information 7023 In SDP, the "c=" field contains the destination address for the media 7024 stream. For a media destination address that is a IPv6 one, the SDP 7025 extension defined in [21] needs to be used. For on-demand unicast 7026 streams and some multicast streams, the destination address MAY be 7027 specified by the client via the SETUP request, thus overriding any 7028 specified address. To identify streams without a fixed destination 7029 address, where the client is required to specify a destination 7030 address, the "c=" field SHOULD be set to a null value. For addresses 7031 of type "IP4", this value SHALL be "0.0.0.0", and for type "IP6", 7032 this value SHALL be "0:0:0:0:0:0:0:0", i.e. the unspecified address 7033 according to RFC 3513 [22]. 7035 C.1.8 Entity Tag 7037 The optional "a=etag" attribute identifies a version of the session 7038 description. It is opaque to the client. SETUP requests may include 7039 this identifier in the If-Match field (see section 14.25) to only 7040 allow session establishment if this attribute value still corresponds 7041 to that of the current description. The attribute value is opaque 7042 and may contain any character allowed within SDP attribute values. 7044 a-etag-def = "a" "=" "etag" ":" etag-string CRLF 7045 etag-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 7047 Example: 7049 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 7050 One could argue that the "o=" field provides identical 7051 functionality. However, it does so in a manner that would 7052 put constraints on servers that need to support multiple 7053 session description types other than SDP for the same piece 7054 of media content. 7056 C.2 Aggregate Control Not Available 7058 If a presentation does not support aggregate control no session level 7059 "a=control:" attribute is specified. For a SDP with multiple media 7060 sections specified, each section will have its own control URI 7061 specified via the "a=control:" attribute. 7063 Example: 7065 v=0 7066 o=- 2890844256 2890842807 IN IP4 204.34.34.32 7067 s=I came from a web page 7068 e=adm@example.com 7069 c=IN IP4 0.0.0.0 7070 t=0 0 7071 m=video 8002 RTP/AVP 31 7072 a=control:rtsp://audio.com/movie.aud 7073 m=audio 8004 RTP/AVP 3 7074 a=control:rtsp://video.com/movie.vid 7076 Note that the position of the control URI in the description implies 7077 that the client establishes separate RTSP control sessions to the 7078 servers audio.com and video.com 7080 It is recommended that an SDP file contains the complete media 7081 initialization information even if it is delivered to the media 7082 client through non-RTSP means. This is necessary as there is no 7083 mechanism to indicate that the client should request more detailed 7084 media stream information via DESCRIBE. 7086 C.3 Aggregate Control Available 7088 In this scenario, the server has multiple streams that can be 7089 controlled as a whole. In this case, there are both a media-level 7090 "a=control:" attributes, which are used to specify the stream URIs, 7091 and a session-level "a=control:" attribute which is used as the 7092 Request-URI for aggregate control. If the media-level URI is 7093 relative, it is resolved to absolute URIs according to Section C.1.1 7094 above. 7096 Example: 7098 C->M: DESCRIBE rtsp://example.com/movie RTSP/1.0 7099 CSeq: 1 7101 M->C: RTSP/1.0 200 OK 7102 CSeq: 1 7103 Date: 23 Jan 1997 15:35:06 GMT 7104 Content-Type: application/sdp 7105 Content-Base: rtsp://example.com/movie/ 7106 Content-Length: 164 7108 v=0 7109 o=- 2890844256 2890842807 IN IP4 204.34.34.32 7110 s=I contain 7111 i= 7112 e=adm@example.com 7113 c=IN IP4 0.0.0.0 7114 t=0 0 7115 a=control:* 7116 m=video 8002 RTP/AVP 31 7117 a=control:trackID=1 7118 m=audio 8004 RTP/AVP 3 7119 a=control:trackID=2 7121 In this example, the client is required to establish a single RTSP 7122 session to the server, and uses the URIs 7123 rtsp://example.com/movie/trackID=1 and 7124 rtsp://example.com/movie/trackID=2 to set up the video and audio 7125 streams, respectively. The URI rtsp://example.com/movie/ , which is 7126 resolved from the "*", controls the whole presentation (movie). 7128 A client is not required to issues SETUP requests for all streams 7129 within an aggregate object. Servers should allow the client to ask 7130 for only a subset of the streams. 7132 C.4 RTSP external SDP delivery 7134 There are some considerations that needs to be made when the session 7135 description is delivered to client outside of RTSP, for example in 7136 HTTP or email. 7138 First of all the SDP needs to contain absolute URIs, relative will in 7139 most cases not work as the delivery will not correctly forward the 7140 base URI. And as SDP might be temporarily stored on file system 7141 before being loaded into an RTSP capable client, thus if possible to 7142 transport the base URI it still would need to be merged into the 7143 file. 7145 The writing of the SDP session availability information, i.e. "t=" 7146 and "r=", needs to be carefully considered. When the SDP is fetched 7147 by the DESCRIBE method it is with very high probability that the it 7148 is valid. However the same are much less certain for SDPs distributed 7149 using other methods. Therefore the publisher of the SDP should take 7150 care to follow the recommendations about availability in the SDP 7151 specification [2]. 7153 D Minimal RTSP implementation 7155 D.1 Client 7157 A client implementation MUST be able to do the following : 7159 o Generate the following requests: SETUP, TEARDOWN, PLAY. 7161 o Include the following headers in requests: CSeq, Connection, 7162 Session, Transport. 7164 o Parse and understand the following headers in responses: 7165 CSeq, Connection, Session, Transport, Content-Language, 7166 Content-Encoding, Content-Length, Content-Type. 7168 o Understand the class of each error code received and notify 7169 the end-user, if one is present, of error codes in classes 4xx 7170 and 5xx. The notification requirement may be relaxed if the 7171 end-user explicitly does not want it for one or all status 7172 codes. 7174 o Expect and respond to asynchronous requests from the server, 7175 such as REDIRECT. This does not necessarily mean that it 7176 should implement the REDIRECT method, merely that it MUST 7177 respond positively or negatively to any request received from 7178 the server. 7180 Though not required, the following are RECOMMENDED. 7182 o Implement RTP/AVP/UDP as a valid transport. 7184 o Inclusion of the User-Agent header. 7186 o Understand SDP session descriptions as defined in Appendix C 7188 o Accept media initialization formats (such as SDP) from 7189 standard input, command line, or other means appropriate to 7190 the operating environment to act as a "helper application" for 7191 other applications (such as web browsers). 7193 There may be RTSP applications different from those 7194 initially envisioned by the contributors to the RTSP 7195 specification for which the requirements above do not make 7196 sense. Therefore, the recommendations above serve only as 7197 guidelines instead of strict requirements. 7199 D.1.1 Basic Playback 7201 To support on-demand playback of media streams, the client MUST 7202 additionally be able to do the following: 7204 o generate the PAUSE request; 7206 o implement the REDIRECT method, and the Location header. 7208 D.1.2 Authentication-enabled 7210 In order to access media presentations from RTSP servers that require 7211 authentication, the client MUST additionally be able to do the 7212 following: 7214 o recognize the 401 (Unauthorized) status code; 7216 o parse and include the WWW-Authenticate header; 7218 o implement Basic Authentication and Digest Authentication. 7220 D.2 Server 7222 A minimal server implementation MUST be able to do the following: 7224 o Implement the following methods: SETUP, TEARDOWN, OPTIONS and 7225 PLAY. 7227 o Include the following headers in responses: Connection, 7228 Content-Length, Content-Type, Content-Language, Content- 7229 Encoding, Timestamp, Transport, Proxy-Supported, Public, and 7230 Via, and Unsupported. RTP-compliant implementations MUST also 7231 implement the RTP-Info field. 7233 o Parse and respond appropriately to the following headers in 7234 requests: Connection, Proxy-Require, Session, Transport, and 7235 Require. 7237 Though not required, the following are highly recommended at the time 7238 of publication for practical interoperability with initial 7239 implementations and/or to be a "good citizen". 7241 o Implement RTP/AVP/UDP as a valid transport. 7243 o Inclusion of the Server, Cache-Control Date, and Expires 7244 headers. 7246 o Implement the DESCRIBE method. 7248 o Generate SDP session descriptions as defined in Appendix C 7250 There may be RTSP applications different from those 7251 initially envisioned by the contributors to the RTSP 7252 specification for which the requirements above do not make 7253 sense. Therefore, the recommendations above serve only as 7254 guidelines instead of strict requirements. 7256 D.2.1 Basic Playback 7258 To support on-demand playback of media streams, the server MUST 7259 additionally be able to do the following: 7261 o Recognize the Range header, and return an error if seeking is 7262 not supported. 7264 o Implement the PAUSE method. 7266 In addition, in order to support commonly-accepted user interface 7267 features, the following are highly recommended for on-demand media 7268 servers: 7270 o Include and parse the Range header, with NPT units. 7271 Implementation of SMPTE units is recommended. 7273 o Include the length of the media presentation in the media 7274 initialization information. 7276 o Include mappings from data-specific timestamps to NPT. When 7277 RTP is used, the rtptime portion of the RTP-Info field may be 7278 used to map RTP timestamps to NPT. 7280 Client implementations may use the presence of length 7281 information to determine if the clip is seekable, and 7282 visably disable seeking features for clips for which the 7283 length information is unavailable. A common use of the 7284 presentation length is to implement a "slider bar" which 7285 serves as both a progress indicator and a timeline 7286 positioning tool. 7288 Mappings from RTP timestamps to NPT are necessary to ensure correct 7289 positioning of the slider bar. 7291 D.2.2 Authentication-enabled 7293 In order to correctly handle client authentication, the server MUST 7294 additionally be able to do the following: 7296 o Generate the 401 (Unauthorized) status code when 7297 authentication is required for the resource. 7299 o Parse and include the WWW-Authenticate header 7301 o Implement Basic Authentication and Digest Authentication 7303 E Requirements for Unreliable Transport of RTSP messages 7305 This section provides any one intending to define how to transport of 7306 RTSP messages over a unreliable transport protocol with some 7307 information learned by the attempt in RFC 2326 [1]. RFC 2326 define 7308 both an URI scheme and some basic functionality for transport of RTSP 7309 messages over UDP, however it was not sufficient for reliable usage 7310 and successful interoperability. 7312 The RTSP scheme defined for unreliable transport of RTSP messages was 7313 "rtspu". It has been reserved by this specification as at least one 7314 commercial implementation exist, thus avoiding any collisions in the 7315 name space. 7317 The following considerations should exist for operation of RTSP over 7318 an unreliable transport protocol: 7320 o Request shall be acknowledged by the receiver. If there is no 7321 acknowledgement, the sender may resend the same message after 7322 a timeout of one round-trip time (RTT). Any retransmissions 7323 due to lack of acknowledgement must carry the same sequence 7324 number as the original request. 7326 o The round-trip time can be estimated as in TCP (RFC 1123) 7327 [41], with an initial round-trip value of 500 ms. An 7328 implementation may cache the last RTT measurement as the 7329 initial value for future connections. 7331 o If RTSP is used over a small-RTT LAN, standard procedures for 7332 optimizing initial TCP round trip estimates, such as those 7333 used in T/TCP (RFC 1644) [42], can be beneficial. 7335 o The Timestamp header (Section 14.44) is used to avoid the 7336 retransmission ambiguity problem [43] and obviates the need 7337 for Karn's algorithm. 7339 o The registered default port for UDP for the RTSP server is 7340 554. 7342 o RTSP messages can be carried over any lower-layer transport 7343 protocol that is 8-bit clean. 7345 o RTSP messages are vulnerable to bit errors and SHOULD NOT be 7346 subjected to them. 7348 o Source authentication, or at least validation that RTSP 7349 messages comes from the same entity becomes extremely 7350 important, as session hijacking may be substantially easier 7351 for RTSP message transport using an unreliable protocol like 7352 UDP than for TCP. 7354 There exist two RTSP header thats primarily are intended for being 7355 used by the unreliable handling of RTSP messages and which will be 7356 maintained: 7358 CSeq See section 14.19 7360 Timestamp See section 14.44 7362 F Backwards Compatibility Considerations 7364 This section contains notes on issues about backwards compatibility 7365 with clients or servers being implemented according to RFC 2326 [1]. 7366 Any mechanism described in this section is intended for a migration 7367 period and are expected to be possible to phase out. 7369 F.1 Requirement on Pause before Play in Play mode 7371 The behavior in Play mode after having run to the end of a media 7372 stream has been changed, see section 11.4. For state handling 7373 consistency, a client is now required to issue an PAUSE prior to a 7374 PLAY request. However as this could make a RFC 2326 client become 7375 stuck after having played a media stream to its end, the following 7376 mitigation is suggested: 7378 If a server receives a PLAY request when in play state and all media 7379 has finished the requested play out, the server MAY interpret this as 7380 a PLAY request received in ready state. 7382 However the server SHALL NOT do the above if the client has shown any 7383 support for this or newer specifications, for example by sending a 7384 Supported header with the play.basic feature tag. 7386 F.2 Usage of persistent connections 7388 Some implementations according to RFC 2326, requires the client to 7389 use persistent connection. The client closing the connection may 7390 result in that the server removes the session. To achieve 7391 interoperability with old servers any client is strongly RECOMMENDED 7392 to use persistent connections. 7394 G Open Issues 7396 This section contains a list of open issues that still needs to be 7397 resolved. However also any open issues in the bug tracker at 7398 http://rtspspec.sourceforge.net should also be considered. 7400 1. Is the example in Section 16.4 valid? 7402 2. Should the SDP appendix contain any text in regards to the 7403 grouping of media line? 7405 3. Following resolved Issue needs text: "Should refusal by 7406 server to perform media redirection have its own error 7407 code?" http://rtsp.org/bug991609. 7409 4. Need to shape up language in relation to the following 7410 issue: "Is current methods to prevent undesired media 7411 redirection sufficient." http://rtsp.org/bug889699 7413 5. Shape up language to what was decided in San Diego on 7414 issue: "Lacking Specification text for "Implicit 7415 Redirect?"" http://rtsp.org/bug742348 7417 6. Need write up on issue: "Should further explanation on 7418 proxies be written?" http://rtsp.org/bug631148 7420 7. Needs to add explicit white spacing for the syntax. 7421 Consider to copy the RFC 3261 concept to include white 7422 spacing in separators a COLON, SEMI, etc. 7424 8. ABNF Syntax needs to be run through verifier. 7426 9. The proxy indications in the two header tables in section 7427 14 needs review. 7429 10. Should the Allow header be possible to use optional in 7430 request or responses besides the now specified 405 error 7431 code? 7433 11. The minimal implementation needs to be checked to see if it 7434 complies with the specification. All shall, must and 7435 shoulds needs to be included in the minimal. Feature-tags 7436 for these needs to be defined. Further feature-tags needs 7437 to be discussed. 7439 12. The list specifying which status codes are allowed on which 7440 request methods seem to be in error and need review. 7442 13. There is need for clearer rule in regards to Transport 7443 parameters changes in mid session. It needs to be 7444 determined if there should be any clarification on how and 7445 which Transport header parameters that may be changed. 7447 14. Normative suggestion is needed for doing RTSP session keep 7448 alives. Currently there are too many options being 7449 suggested by RTSP such as OPTIONS with Session ID, PING, 7450 SET_PARAMETER. This leads to interoperability problems, 7451 maintenance issues and additional development for 7452 implementers for little gain. 7454 H Changes 7456 H.1 Issues Addressed 7458 Compared to RFC 2326, the following issues has been addressed: 7460 o The Transport header has been changed in the following way: 7462 - The ABNF has been changed to define that extensions are 7463 possible, and that unknown extension parameters are to be 7464 ignored. 7466 - To prevent backwards compatibility issues, any extension or 7467 new parameter requires the usage of a feature tag combined 7468 with the Require header. 7470 - Syntax unclarities with the Mode parameter has been 7471 resolved. 7473 - Syntax error with ";" for multicast and unicast has been 7474 resolved. 7476 - Two new addressing parameters has been defined, src_addr and 7477 dest_addr. These allow one to specify more than one complete 7478 address and port tuple if needed. 7480 - Support for IPv6 explicit addresses in all address fields 7481 has been included. 7483 - To handle URI definitions that contain ";" or "," a quoted 7484 URI format has been introduced. 7486 - Defined IANA registries for the transport headers 7487 parameters, transport-protocol, profile, lower-transport, 7488 and mode. 7490 - The transport headers interleaved parameter's text was made 7491 more strict and use formal requirements levels. However no 7492 change on how it is used was made. 7494 - It has been clarified that the client can't request of the 7495 server to use a certain RTP SSRC, using a request with the 7496 transport parameter SSRC. 7498 - Syntax definition for SSRC has been clarified to require 8*8 7499 HEX. It has also been extend to allow multiple values for 7500 clients supporting this version. 7502 - Updated the text on the transport headers "destination" and 7503 "dest_addr" parameters regarding what security precautions 7504 the server is required to perform. 7506 - The embedded (interleaved) binary data and its transport 7507 parameter was clarified to being symmetric and that it is 7508 the server that sets the channel numbers. 7510 H.2 Changes made to the protocol and specification 7512 o The Range formats has been changed in the following way: 7514 - The NPT format has been given a initial NPT identifier that should 7515 be used, if missing NPT is assumed. 7517 - All formats now support initial open ended formats of type "npt=- 7518 10". 7520 o RTSP message handling has been changed in the following way: 7522 - RTSP messages now uses URIs rather then URLs. 7524 - It has been clarified that a 4xx message due to missing CSeq header 7525 shall be returned without a CSeq header. 7527 - Rules for how to handle timing out RTSP messages has been added. 7529 o The HTTP references has been updated to RFC 2616 and RFC 2617. This 7530 has resulted in that the Public, and the Content-Base header needed 7531 to be defined in the RTSP specification. Known effects on RTSP due to 7532 HTTP clarifications: 7534 - Content-Encoding header can include encoding of type "identity". 7536 o The state machine section has completely been rewritten. It includes 7537 now more details and are also more clear about the model used. 7539 o A IANA section has been included with contains a number of registries 7540 and their rules. This will allow us to use IANA to keep track of all 7541 RTSP extensions. 7543 o Than transport of RTSP messages has seen the following changes: 7545 - The use of UDP for RTSP message transport has been deprecated due 7546 to missing interest and to broken specification. 7548 - The rules for how TCP connections is to be handled has been 7549 clarified. Now it is made clear that servers should not close the 7550 TCP connection unless they have been unused for significant time. 7552 - Strong recommendations why server and clients should use persistent 7553 connections has also been added. 7555 - There is now a requirement to handle non-persistent connections as 7556 this provides great fault tolerance. 7558 - Added wording on the usage of Connection:Close for RTSP. 7560 - specified usage of TLS for RTSP messages, including a scheme to 7561 approve a proxies TLS connection to the next hop. 7563 o The following header related changes have been made: 7565 - Accept-Ranges response header is added. This header clarifies which 7566 range formats that can be used for a resource. 7568 - Clarified that Range header allows multiple ranges to allow for 7569 creating editing list. 7571 - Fixed the missing definitions for the Cache-Control header. Also 7572 added to the syntax definition the missing delta-seconds for max- 7573 stale and min-fresh parameters. 7575 - Put requirement on CSeq header that the value is increased by one 7576 for each new RTSP request. A Recommendation to start at 1 has also 7577 been added. 7579 - Added requirement that the Date header must be used for all 7580 messages with entity. Also the Server should always include it. 7582 - Removed possibility of using Range header with Scale header to 7583 indicate when it is to be activated, since it can't work as 7584 defined. Also added rule that lack of Scale header in response 7585 indicates lack of support for the header. Feature-tags for scaled 7586 playback has been defined. 7588 - The Speed header must now be responded to indicate support and the 7589 actual speed going to be used. A feature-tag is defined. Notes on 7590 congestion control was also added. 7592 - The Supported header was borrowed from SIP to help with the feature 7593 negotiation in RTSP. 7595 - Clarified that the Timestamp header can be used to resolve 7596 retransmission ambiguities. 7598 - The Session header text has been expanded with a explanation on 7599 keep alive and which methods to use. 7601 - It has been clarified how the Range header formats is used to 7602 indicate pause points. 7604 - Clarified that RTP-Info URIs that are relative, uses the Request- 7605 URI as base URI. Also clarified that the URI that must be used is 7606 the SETUP. 7608 - Added text that requires the Range to always be present in PLAY 7609 responses. Clarified what should be sent in case of live streams. 7611 - The quoted URI format may also be used with the RTP-Info header. 7612 Backwards compatibility issues exist with such usage, thus it can 7613 only be used for implementations following this specification. 7615 - The headers table has been updated using a structured borrowed from 7616 SIP. This table carries much more information and should provide a 7617 good overview of the available headers. 7619 - It has been is clarified that any message with a message body is 7620 required to have a Content-Length header. This was the case in RFC 7621 2326 but could be misinterpreted. 7623 - To resolve functionality around ETag. The ETag and If-None-Match 7624 header has been added from HTTP with necessary clarification in 7625 regards to RTSP operation. 7627 - Imported the Public header from HTTP RFC 2068 [19] since it has 7628 been removed from HTTP due to lack of use. Public is used quite 7629 frequently in RTSP. 7631 - Clarified rules for populating the Public header so that it is an 7632 intersection of the capabilities of all the RTSP agents in a chain. 7634 o The minimal implementation specification has been changed: 7636 - Required Timestamp, Via, and Unsupported headers for a minimal 7637 server implementation. 7639 - Recommended that Cache-Control, Expires and Date headers be 7640 supported by server implementations. 7642 o The Protocol Syntax has been changed in the following way: 7644 - All BNF definitions are updated according to the rules defined in 7645 RFC 2234 [5] and has been gathered in a separate section 18. 7647 - The BNF for the User-Agent and Server headers has been corrected so 7648 now only the description is in the HTTP specification. 7650 - The definition in the introduction of the RTSP session has been 7651 changed. 7653 - The protocol has been made fully IPv6 capable. Certain of the 7654 functionality, like using explicit IPv6 addresses in fields 7655 requires that the protocol support this updated specification. 7657 - Added a fragment part to the RTSP URI. This seem to be indicated by 7658 the note below the definition however it was not part of the BNF. 7660 - The CHAR rule has been changed to exclude NULL. 7662 o The Status codes has been changed in the following way: 7664 - The use of status code 303 "See Other" has been deprecated as it 7665 does not make sense to use in RTSP. 7667 - When sending response 451 and 458 the response body should contain 7668 the offending parameters. 7670 - Clarification on when a 3rr redirect status code can be received 7671 has been added. This includes receiving 3rr as a result of request 7672 within a established session. This provides clarification to a 7673 previous unspecified behavior. 7675 - Removed the 250 (Low On Storage Space) status code as it only is 7676 relevant to recording which is deprecated. 7678 o The following functionality has been deprecated from the protocol: 7680 - The use of Queued Play. 7682 - The use of PLAY method for keep-alive in play state. 7684 - The RECORD and ANNOUNCE methods and all related functionality. Some 7685 of the syntax has been removed. 7687 - The possibility to use timed execution of methods with the time 7688 parameter in the Range header. 7690 - The description on how rtspu works is not part of the core 7691 specification and will require external description. Only that it 7692 exist is defined here and some requirements for the the transport 7693 is provided. 7695 o Text specifying the special behavior of PLAY for live content. 7697 o The following changes has been made in relation to methods: 7699 - The OPTIONS method has been clarified with regards to the use of 7700 the Public and Allow headers. 7702 - The RECORD and ANNOUNCE methods are removed as they are lacking 7703 implementation and not considered necessary in the core 7704 specification. Any work on these methods should be done as a 7705 extension document to RTSP. 7707 - Added text clarifying the usage of SET_PARAMETER for keep-alive and 7708 usage without any body. 7710 - Added a backwards compatibility resolution for how to handle the 7711 new state machine without automatic state transition, for example 7712 for returning to ready when finished playing. 7714 o Wrote a new section about how to setup different media transport 7715 alternatives and their profiles, and lower layer protocols. This 7716 resulted that the appendix on RTP interaction was moved there instead 7717 in the part describing RTP. The section also includes guidelines what 7718 to think of when writing usage guidelines for new protocols and 7719 profiles. 7721 o Added a new section describing the available mechanisms to determine 7722 if functionality is supported, called "Capability Handling". Renamed 7723 option-tags to feature-tags. 7725 o Added a contributors section with people who has contribute actual 7726 text to the specification. 7728 o Added a section Use Cases that describes the major use cases for 7729 RTSP. 7731 o Clarified the usage of a=range and how to indicate live content that 7732 are not seekable with this header. 7734 Note that this list does not reflect minor changes in wording or 7735 correction of typographical errors. 7737 A word-by-word diff from RFC 2326 can be found at http://rtsp.org/ 7739 I Author Addresses 7741 Henning Schulzrinne 7742 Dept. of Computer Science 7743 Columbia University 7744 1214 Amsterdam Avenue 7745 New York, NY 10027 7746 USA 7747 electronic mail: schulzrinne@cs.columbia.edu 7749 Anup Rao 7750 Cisco 7751 USA 7752 electronic mail: anrao@cisco.com 7754 Robert Lanphier 7755 RealNetworks 7756 P.O. Box 91123 7757 Seattle, WA 98111-9223 7758 USA 7759 electronic mail: robla@real.com 7761 Magnus Westerlund 7762 Ericsson AB, EAB/TVA/A 7763 Torshamsgatan 23 7764 SE-164 80 STOCKHOLM 7765 SWEDEN 7766 electronic mail: magnus.westerlund@ericsson.com 7768 Aravind Narasimhan 7769 Princeton, NJ 7770 USA 7771 electronic mail: aravind.narasimhan@gmail.com 7773 J Contributors 7775 The following people has made written contribution included in the 7776 specification: 7778 o Tom Marshall has contributed with text about the usage of 3rr 7779 status codes. 7781 o Thomas Zheng has contributed with text regarding the usage of 7782 the Range in PLAY responses. 7784 o Sean Sheedy has contributed the text regarding the timing out 7785 of RTSP messages. 7787 o Fredrik Lindholm has contributed with text for the RTSP 7788 security framework. 7790 The following persons has provided detailed comments on the updated 7791 version of the specification: 7793 o Stephan Wenger 7795 K Acknowledgements 7797 This draft is based on the functionality of the original RTSP draft 7798 submitted in October 1996. It also borrows format and descriptions 7799 from HTTP/1.1. 7801 This document has benefited greatly from the comments of all those 7802 participating in the MMUSIC-WG. In addition to those already 7803 mentioned, the following individuals have contributed to this 7804 specification: 7806 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 7807 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 7808 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 7809 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 7810 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 7811 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 7812 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 7813 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 7814 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 7815 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 7816 Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, 7817 and Mela Martti. 7819 L Normative References 7821 [1] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 7822 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 7823 1998. 7825 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 7826 RFC 2327, Internet Engineering Task Force, Apr. 1998. 7828 [3] H. Schulzrinne and S. Casner, "RTP profile for audio and video 7829 conferences with minimal control," RFC 3551, Internet Engineering 7830 Task Force, July 2003. 7832 [4] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 7833 J. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- 7834 HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999. 7836 [5] "Augmented BNF for syntax specifications: ABNF," RFC 2234, 7837 Internet Engineering Task Force, Nov. 1997. 7839 [6] S. Bradner, "Key words for use in RFCs to indicate requirement 7840 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 7842 [7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, 7843 Internet Engineering Task Force, Jan. 1999. 7845 [8] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. J. 7846 Leach, A. Luotonen, and L. Stewart, "HTTP authentication: Basic and 7847 digest access authentication," RFC 2617, Internet Engineering Task 7848 Force, June 1999. 7850 [9] J. B. Postel, "User datagram protocol," RFC 768, Internet 7851 Engineering Task Force, Aug. 1980. 7853 [10] J. B. Postel, "Transmission control protocol," RFC 793, Internet 7854 Engineering Task Force, Sept. 1981. 7856 [11] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, 7857 Internet Engineering Task Force, Apr. 1996. 7859 [12] R. Hinden, B. E. Carpenter, and L. Masinter, "Format for literal 7860 IPv6 addresses in URL's," RFC 2732, Internet Engineering Task Force, 7861 Dec. 1999. 7863 [13] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 7864 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 7865 Task Force, Aug. 1998. 7867 [14] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 7868 2279, Internet Engineering Task Force, Jan. 1998. 7870 [15] NIST, "Fips pub 180-1:secure hash standard," tech. rep., 7871 National Institute of Standards and Technology, Apr. 1995. 7873 [16] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 7874 public key infrastructure certificate and certificate revocation list 7875 (CRL) profile," RFC 3280, Internet Engineering Task Force, Apr. 2002. 7877 [17] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 7878 a transport protocol for real-time applications," RFC 3550, Internet 7879 Engineering Task Force, July 2003. 7881 [18] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering 7882 Task Force, May 2000. 7884 [19] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. 7885 Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, 7886 Internet Engineering Task Force, Jan. 1997. 7888 [20] T. Narten and H. Alvestrand, "Guidelines for writing an IANA 7889 considerations section in RFCs," RFC 2434, Internet Engineering Task 7890 Force, Oct. 1998. 7892 [21] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in 7893 session description protocol (SDP)," RFC 3266, Internet Engineering 7894 Task Force, June 2002. 7896 [22] R. Hinden and S. E. Deering, "Internet protocol version 6 (ipv6) 7897 addressing architecture," RFC 3513, Internet Engineering Task Force, 7898 Apr. 2003. 7900 M Informative References 7902 [23] T. Z. M. Westerlund, "How to make real-time streaming protocol 7903 (rtsp) traverse network address translators (nat) and interact with 7904 firewalls.," internet draft, Internet Engineering Task Force, Feb. 7905 2004. Work in progress. 7907 [24] A. Narasimhan, "Mute and unmute extension to rtsp," internet 7908 draft, Internet Engineering Task Force, Feb. 2002. Work in progress. 7910 [25] P. Gentric, "Rtsp stream switching," internet draft, Internet 7911 Engineering Task Force, Jan. 2004. Work in progress. 7913 [26] A. L. G. Srikantan, J. Murata, "Streaming relays," internet 7914 draft, Internet Engineering Task Force, Dec. 2003. Work in progress. 7916 [27] F. Yergeau, G. Nicol, G. C. Adams, and M. Duerst, 7917 "Internationalization of the hypertext markup language," RFC 2070, 7918 Internet Engineering Task Force, Jan. 1997. 7920 [28] H. Schulzrinne, "A comprehensive multimedia control architecture 7921 for the Internet," in Proc. International Workshop on Network and 7922 Operating System Support for Digital Audio and Video (NOSSDAV), (St. 7923 Louis, Missouri), May 1997. 7925 [29] International Telecommunication Union, "Visual telephone systems 7926 and equipment for local area networks which provide a non-guaranteed 7927 quality of service," Recommendation H.323, Telecommunication 7928 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 7930 [30] P. McMahon, "GSS-API authentication method for SOCKS version 5," 7931 RFC 1961, Internet Engineering Task Force, June 1996. 7933 [31] J. Miller, P. Resnick, and D. Singer, "Rating services and 7934 rating systems (and their machine readable descriptions)," 7935 Recommendation REC-PICS-services-961031, W3C (World Wide Web 7936 Consortium), Boston, Massachusetts, Oct. 1996. 7938 [32] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 7939 distribution label syntax and communication protocols," 7940 Recommendation REC-PICS-labels-961031, W3C (World Wide Web 7941 Consortium), Boston, Massachusetts, Oct. 1996. 7943 [33] D. L. Mills, "Network time protocol (version 3) specification, 7944 implementation," RFC 1305, Internet Engineering Task Force, Mar. 7945 1992. 7947 [34] ISO/IEC, "Information technology -- generic coding of moving 7948 pictures and associated audio informaiton -- part 6: extension for 7949 digital storage media and control," Draft International Standard ISO 7950 13818-6, International Organization for Standardization ISO/IEC 7951 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 7953 [35] ISO/IEC, "Data elements and interchange formats -- information 7954 interchange -- representation of dates and times," Published standard 7955 ISO 8601, International Organization for Standardization ISO/IEC, 7956 Geneva, Switzerland, Dec. 2000. 7958 [36] S. Josefsson and I. W. Ed., "The base16, base32, and base64 data 7959 encodings," RFC 3548, Internet Engineering Task Force, July 2003. 7961 [37] Third Generation Partnership Project (3GPP), "Transparent end- 7962 to-end packet-switched streaming service (pss); protocols and 7963 codecs," Technical Specification 26.234, Third Generation Partnership 7964 Project (3GPP), Dec. 2002. 7966 [38] D. Yon, "Connection-oriented media transport in sdp," internet 7967 draft, Internet Engineering Task Force, Mar. 2003. Work in progress. 7969 [39] J. Lazzaro, "Framing rtp and rtcp packets over connection- 7970 oriented transport," internet draft, Internet Engineering Task Force, 7971 Oct. 2003. Work in progress. 7973 [40] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, 7974 "Grouping of media lines in the session description protocol (SDP)," 7975 RFC 3388, Internet Engineering Task Force, Dec. 2002. 7977 [41] "Requirements for Internet hosts - application and support," RFC 7978 1123, Internet Engineering Task Force, Oct. 1989. 7980 [42] R. Braden, "T/TCP -- TCP extensions for transactions functional 7981 specification," RFC 1644, Internet Engineering Task Force, July 1994. 7983 [43] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 7984 Reading, Massachusetts: Addison-Wesley, 1994. 7986 IPR Notice 7988 The IETF takes no position regarding the validity or scope of any 7989 Intellectual Property Rights or other rights that might be claimed to 7990 pertain to the implementation or use of the technology described in 7991 this document or the extent to which any license under such rights 7992 might or might not be available; nor does it represent that it has 7993 made any independent effort to identify any such rights. Information 7994 on the procedures with respect to rights in RFC documents can be 7995 found in BCP 78 and BCP 79. 7997 Copies of IPR disclosures made to the IETF Secretariat and any 7998 assurances of licenses to be made available, or the result of an 7999 attempt made to obtain a general license or permission for the use of 8000 such proprietary rights by implementers or users of this 8001 specification can be obtained from the IETF on-line IPR repository at 8002 http://www.ietf.org/ipr. 8004 The IETF invites any interested party to bring to its attention any 8005 copyrights, patents or patent applications, or other proprietary 8006 rights that may cover technology that may be required to implement 8007 this standard. Please address the information to the IETF at ietf- 8008 ipr@ietf.org. 8010 Full Copyright Statement 8012 Copyright (C) The Internet Society (2004). This document is subject 8013 to the rights, licenses and restrictions contained in BCP 78, and 8014 except as set forth therein, the authors retain all their rights. 8016 This document and the information contained herein are provided on an 8017 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 8018 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 8019 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 8020 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 8021 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 8022 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.