idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 424 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1118 has weird spacing: '...s State all...' == Line 1122 has weird spacing: '...Allowed all...' == Line 1123 has weird spacing: '...Allowed all...' == Line 1447 has weird spacing: '...rection obje...' == Line 1449 has weird spacing: '...mmended rec...' == (18 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: Notes on Table 2: PAUSE is recommended, but not required in that a fully functional server can be built that does not support this method, for example, for live feeds. If a server does not support a particular method, it MUST return 501 (Not Implemented) and a client SHOULD not try this method again for this server. == 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 frag-ments 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. Any propri-etary 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 excep-tions shall be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occur the appropriate response code MUST be sent. If the response code is a 4xx the session state is unchanged. A response | code of 3rr will result in that the session is ended and its state is | changed to Init. A response code of 304 results in no state change. | However there exist restrictions to when a 3xx | response may be used. A 5xx response SHALL not result in any change of the session state, except if the error is not possible to recover from. A unre-coverable error SHALL result the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client SHALL assume that the session has been ended. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2003) is 7603 days in the past. Is this intentional? 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? '21' on line 6018 looks like a reference -- Missing reference section? '33' on line 6063 looks like a reference -- Missing reference section? '34' on line 6068 looks like a reference -- Missing reference section? '1' on line 5943 looks like a reference -- Missing reference section? '26' on line 6036 looks like a reference -- Missing reference section? '3' on line 5951 looks like a reference -- Missing reference section? '4' on line 5955 looks like a reference -- Missing reference section? '5' on line 5958 looks like a reference -- Missing reference section? '24' on line 6030 looks like a reference -- Missing reference section? '27' on line 6039 looks like a reference -- Missing reference section? '6' on line 5964 looks like a reference -- Missing reference section? '7' on line 5968 looks like a reference -- Missing reference section? '8' on line 5971 looks like a reference -- Missing reference section? '9' on line 5974 looks like a reference -- Missing reference section? '10' on line 5977 looks like a reference -- Missing reference section? '28' on line 6042 looks like a reference -- Missing reference section? '11' on line 5982 looks like a reference -- Missing reference section? '12' on line 5985 looks like a reference -- Missing reference section? '13' on line 5990 looks like a reference -- Missing reference section? '14' on line 5995 looks like a reference -- Missing reference section? '30' on line 6051 looks like a reference -- Missing reference section? '22' on line 6022 looks like a reference -- Missing reference section? '16' on line 6002 looks like a reference -- Missing reference section? '18' on line 6009 looks like a reference -- Missing reference section? 'H6' on line 956 looks like a reference -- Missing reference section? '15' on line 5998 looks like a reference -- Missing reference section? '19' on line 6012 looks like a reference -- Missing reference section? '20' on line 6015 looks like a reference -- Missing reference section? 'H10' on line 2216 looks like a reference -- Missing reference section? '23' on line 6026 looks like a reference -- Missing reference section? 'H15' on line 4427 looks like a reference -- Missing reference section? '2' on line 5947 looks like a reference -- Missing reference section? '29' on line 6047 looks like a reference -- Missing reference section? '35' on line 6072 looks like a reference -- Missing reference section? '36' on line 6076 looks like a reference -- Missing reference section? '37' on line 6080 looks like a reference -- Missing reference section? 'NPT' on line 5691 looks like a reference -- Missing reference section? '17' on line 6005 looks like a reference -- Missing reference section? '25' on line 6033 looks like a reference -- Missing reference section? '31' on line 6055 looks like a reference -- Missing reference section? '32' on line 6059 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 17 warnings (==), 43 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 A. Rao 6 Cisco 7 R. Lanphier 8 RealNetworks 9 M. Westerlund 10 Ericsson 11 A. Narasimhan 12 Sun 14 draft-ietf-mmusic-rfc2326bis-04.txt 15 June 30, 2003 16 Expires: December, 2003 18 Real Time Streaming Protocol (RTSP) 20 STATUS OF THIS MEMO 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference mate- 33 rial or to cite them other than as "work in progress". 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 To view the list Internet-Draft Shadow Directories, see 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This memorandum is a revision of RFC 2326, which is currently a Pro- 44 posed Standard. 46 The Real Time Streaming Protocol, or RTSP, is an application-level 47 protocol for control over the delivery of data with real-time 48 properties. RTSP provides an extensible framework to enable con- 49 trolled, on-demand delivery of real-time data, such as audio and 50 video. Sources of data can include both live data feeds and stored 51 clips. This protocol is intended to control multiple data delivery 52 sessions, provide a means for choosing delivery channels such as UDP, 53 multicast UDP and TCP, and provide a means for choosing delivery 54 mechanisms based upon RTP (RFC 1889). 56 1 Introduction 58 1.1 The Update of the RTSP Specification 60 This is the draft to an update of RTSP which is currently a proposed 61 standard defined in RFC 2326 [21]. Many flaws have been found in 62 RTSP since it was published. While this draft tries to address the 63 flaws, not all known issues have been resolved. 65 The goal of the current work on RTSP is to progress it to draft stan- 66 dard status. Whether this is possible without first publishing RTSP 67 as a proposed standard depends on the changes necessary to make the 68 protocol work. The list of changes in chapter F indicates the issues 69 that have already been addressed. The currently open issues are 70 listed in chapter E. 72 There is also a list of reported bugs available at "http://rtsp- 73 spec.sourceforge.net". These bugs should be taken into account when 74 reading this specification. While a lot of these bugs are addressed, 75 not all are yet accounted for in this specification. Input on the 76 unresolved bugs and other issues can be sent via e-mail to the MMUSIC 77 WG's mailing list mmusic@ietf.org and the authors. 79 Take special notice of the following: 81 + The example section 15 has not yet been revised since the 82 changes to protocol have not been completed. 84 + The BNF chapter 16 has not been compiled completely. 86 + Not all of the contents of RFC 2326 are part of this draft. In 87 an attempt to prevent the draft from exploding in size, the spec- 88 ification has been reduced and split. The content of this draft 89 is the core specification of the protocol. It contains the gen- 90 eral idea behind RTSP and the basic functionality necessary to 91 establish an on-demand play-back session. It also contains the 92 mechanisms for extending the protocol. Any other functionality 93 will be published as extension documents. Two proposals exist at 94 this time: 96 + NAT and FW traversal mechanisms for RTSP are described in a docu- 97 ment called "How to make Real-Time Streaming Protocol (RTSP) tra- 98 verse Network Address Translators (NAT) and interact with Fire- 99 walls." [33]. 101 + The MUTE extension [34] contains a proposal on adding functional- 102 ity to mute and unmute media streams in an aggregated media ses- 103 sion without affecting the time-line of the playback. 105 There have also been discussions about the following extensions to 106 RTSP: 108 + Transport security for RTSP messages (rtsps). 110 + Unreliable transport of RTSP messages (rtspu). 112 + The Record functionality. 114 + A text body type with suitable syntax for basic parameters to be 115 used in SET_PARAMETER, and GET_PARAMETER. Including IANA registry 116 within the defined name space. 118 + A RTSP MIB. 120 However, so far, they have not become concrete proposals. 122 1.2 Purpose 124 The Real-Time Streaming Protocol (RTSP) establishes and controls sin- 125 gle or several time-synchronized streams of continuous media such as 126 audio and video. Put simply, RTSP acts as a "network remote control" 127 for multimedia servers. 129 There is no notion of a RTSP connection in the protocol. Instead, a 130 RTSP server maintains a session labelled by an identifier to associ- 131 ate groups of media streams and their states. A RTSP session is nor- 132 mally not tied to a transport-level connection such as a TCP connec- 133 tion. During a session, a client may open and close many reliable 134 transport connections to the server to issue RTSP requests for that 135 session. 137 This memorandum describes the use of RTSP over a reliable connection 138 based transport level protocol such as TCP. RTSP may be implemented 139 over an unreliable connectionless transport protocol such as UDP. 140 While nothing in RTSP precludes this, additional definition of this 141 problem area must be handled as an extension to the core specifica- 142 tion. 144 The mechanisms of RTSP's operation over UDP were left out of 145 this spec. because they were poorly defined in RFC 2336 [21] 146 and the tradeoff in size and complexity of this spec. for a 147 small gain in a targeted problem space was not deemed justifi- 148 able. 150 The set of streams to be controlled is defined by a presentation 151 description. This memorandum does not define a format for the 152 presentation description. The streams controlled by RTSP may use RTP 153 [1] for their data transport, but the operation of RTSP does not 154 depend on the transport mechanism used to carry continuous media. The 155 protocol is intentionally similar in syntax and operation to HTTP/1.1 156 [26] so that extension mechanisms to HTTP can in most cases also be 157 added to RTSP. However, RTSP differs in a number of important 158 aspects from HTTP: 160 + RTSP introduces a number of new methods and has a different pro- 161 tocol identifier. 163 + RTSP has the notion of a session built into the protocol. 165 + A RTSP server needs to maintain state by default in almost all 166 cases, as opposed to the stateless nature of HTTP. 168 + Both a RTSP server and client can issue requests. 170 + Data is usually carried out-of-band by a different protocol. 171 Session descriptions returned in a DESCRIBE response (see Section 172 11.2) and interleaving of RTP with RTSP over TCP are exceptions 173 to this rule (see Section 11.11). 175 + RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, 176 consistent with current HTML internationalization efforts [3]. 178 + The Request-URI always contains the absolute URI. Because of 179 backward compatibility with a historical blunder, HTTP/1.1 [26] 180 carries only the absolute path in the request and puts the host 181 name in a separate header field. 183 This makes "virtual hosting" easier, where a single host 184 with one IP address hosts several document trees. 186 The protocol supports the following operations: 188 Retrieval of media from media server: The client can request a pre- 189 sentation description via HTTP or some other method. If the 190 presentation is being multicast, the presentation description 191 contains the multicast addresses and ports to be used for the 192 continuous media. If the presentation is to be sent only to 193 the client via unicast, the client provides the destination 194 for security reasons. 196 Invitation of a media server to a conference: A media server can be | 197 "invited" to join an existing conference to play back media | 198 into the presentation. This mode is useful for distributed | 199 teaching applications. Several parties in the conference may | 200 take turns "pushing the remote control buttons". 202 Addition of media to an existing presentation: Particularly for 203 live presentations, it is useful if the server can tell the 204 client about additional media becoming available. 206 RTSP requests may be handled by proxies, tunnels and caches as in 207 HTTP/1.1 [26]. 209 1.3 Requirements 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in RFC 2119 [4]. 215 1.4 Terminology 217 Some of the terminology has been adopted from HTTP/1.1 [26]. Terms 218 not listed here are defined as in HTTP/1.1. 220 Aggregate control: The concept of controlling multiple streams 221 using a single timeline, generally maintained by the server. A 222 client, for example, uses aggregate control when it issues a 223 single play or pause message to simultaneously control both 224 the audio and video in a movie. 226 Aggregate control URI: The URI used in a RTSP request to refer to 227 and control an aggregated session. It normally, but not 228 always, corresponds to the presentation URI specified in the 229 session description. See Section 11.3 for more information. 231 Conference: a multiparty, multimedia presentation, where "multi" 232 implies greater than or equal to one. 234 Client: The client requests media service from the media server. 236 Connection: A transport layer virtual circuit established between 237 two programs for the purpose of communication. 239 Container file: A file which may contain multiple media streams 240 which often comprise a presentation when played together. RTSP 241 servers may offer aggregate control on these files, though the 242 concept of a container file is not embedded in the protocol. 244 Continuous media: Data where there is a timing relationship between 245 source and sink; that is, the sink must reproduce the timing 246 relationship that existed at the source. The most common exam- 247 ples of continuous media are audio and motion video. Continu- 248 ous media can be real-time (interactive), where there is a 249 "tight" timing relationship between source and sink, or 250 streaming (playback), where the relationship is less strict. 252 Entity: The information transferred as the payload of a request or 253 response. An entity consists of meta-information in the form 254 of entity-header fields and content in the form of an entity- 255 body, as described in Section 8. 257 Feature-tag: A tag representing a certain set of functionality, 258 i.e. a feature. 260 Media initialization: Datatype/codec specific initialization. This 261 includes such things as clockrates, color tables, etc. Any 262 transport-independent information which is required by a 263 client for playback of a media stream occurs in the media ini- 264 tialization phase of stream setup. 266 Media parameter: Parameter specific to a media type that may be 267 changed before or during stream playback. 269 Media server: The server providing playback services for one or | 270 more media streams. Different media streams within a presenta- | 271 tion may originate from different media servers. A media | 272 server may reside on the same or a different host as the web | 273 server the presentation is invoked from. 275 Media server indirection: Redirection of a media client to a dif- 276 ferent media server. 278 (Media) stream: A single media instance, e.g., an audio stream or a 279 video stream as well as a single whiteboard or shared applica- 280 tion group. When using RTP, a stream consists of all RTP and 281 RTCP packets created by a source within an RTP session. This 282 is equivalent to the definition of a DSM-CC stream([5]). 284 Message: The basic unit of RTSP communication, consisting of a 285 structured sequence of octets matching the syntax defined in 286 Section 16 and transmitted via a connection or a connection- 287 less protocol. 289 Non-Aggregated Control: Control of a single media stream. Only 290 possible in RTSP sessions with a single media. 292 Participant: Member of a conference. A participant may be a | 293 machine, e.g., a playback server. 295 Presentation: A set of one or more streams presented to the client 296 as a complete media feed, using a presentation description as 297 defined below. In most cases in the RTSP context, this implies 298 aggregate control of those streams, but does not have to. 300 Presentation description: A presentation description contains 301 information about one or more media streams within a presenta- 302 tion, such as the set of encodings, network addresses and 303 information about the content. Other IETF protocols such as 304 SDP (RFC 2327 [24]) use the term "session" for a live presen- 305 tation. The presentation description may take several differ- 306 ent formats, including but not limited to the session descrip- 307 tion format SDP. 309 Response: A RTSP response. If an HTTP response is meant, that is 310 indicated explicitly. 312 Request: A RTSP request. If an HTTP request is meant, that is indi- 313 cated explicitly. 315 RTSP session: A stateful abstraction upon which the main control 316 methods of RTSP operate. A RTSP session is a server entity; it 317 is created, maintained and destroyed by the server. It is 318 established by a RTSP server upon the completion of a success- 319 ful SETUP request (when 200 OK response is sent) and is 320 labelled by a session identifier at that time. The session 321 exists until timed out by the server or explicitly removed by 322 a TEARDOWN request. A RTSP session is also a stateful entity; 323 a RTSP server maintains an explicit session state machine (see 324 Appendix A) where most state transitions are triggered by 325 client requests. The existence of a session implies the exis- 326 tence of state about the session's media streams and their 327 respective transport mechanisms. A given session can have zero 328 or more media streams associated with it. A RTSP server uses 329 the session to aggregate control over multiple media streams. 331 Transport initialization: The negotiation of transport information 332 (e.g., port numbers, transport protocols) between the client 333 and the server. 335 1.5 Protocol Properties 337 RTSP has the following properties: 339 Extendable: New methods and parameters can be easily added to RTSP. 341 Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. 343 Secure: RTSP re-uses web security mechanisms, either at the trans- 344 port level (TLS, RFC 2246 [27]) or within the protocol itself. 345 All HTTP authentication mechanisms such as basic (RFC 2616 346 [26]) and digest authentication (RFC 2069 [6]) are directly 347 applicable. 349 Transport-independent: RTSP does not preclude the use of an unreli- 350 able datagram protocol (UDP) (RFC 768 [7]), a reliable data- 351 gram protocol (RDP, RFC 1151, not widely used [8]) or a reli- 352 able stream protocol such as TCP (RFC 793 [9]) as it imple- 353 ments application-level reliability. The use of a connection- 354 less datagram protocol such as UDP or RDP requires additional 355 definition that may be provided as extensions to the core RTSP 356 specification. 358 Multi-server capable: Each media stream within a presentation can 359 reside on a different server. The client automatically estab- 360 lishes several concurrent control sessions with the different 361 media servers. Media synchronization is performed at the 362 transport level. 364 Separation of stream control and conference initiation: Stream con- 365 trol is divorced from inviting a media server to a conference. 366 In particular, SIP [10] or H.323 [28] may be used to invite a 367 server to a conference. 369 Suitable for professional applications: RTSP supports frame-level 370 accuracy through SMPTE time stamps to allow remote digital 371 editing. 373 Presentation description neutral: The protocol does not impose a 374 particular presentation description or metafile format and can 375 convey the type of format to be used. However, the presenta- 376 tion description must contain at least one RTSP URI. 378 Proxy and firewall friendly: The protocol should be readily handled 379 by both application and transport-layer (SOCKS [11]) fire- 380 walls. A firewall may need to understand the SETUP method to 381 open a "hole" for the UDP media stream. 383 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that 384 the existing infrastructure can be reused. This infrastructure 385 includes PICS (Platform for Internet Content Selection 386 [12,13]) for associating labels with content. However, RTSP 387 does not just add methods to HTTP since the controlling con- 388 tinuous media requires server state in most cases. 390 Appropriate server control: If a client can start a stream, it must 391 be able to stop a stream. Servers should not start streaming 392 to clients in such a way that clients cannot stop the stream. 394 Transport negotiation: The client can negotiate the transport 395 method prior to actually needing to process a continuous media 396 stream. 398 Capability negotiation: If basic features are disabled, there must 399 be some clean mechanism for the client to determine which 400 methods are not going to be implemented. This allows clients 401 to present the appropriate user interface. For example, if 402 seeking is not allowed, the user interface must be able to 403 disallow moving a sliding position indicator. 405 An earlier requirement in RTSP was multi-client capability. 406 However, it was determined that a better approach was to make 407 sure that the protocol is easily extensible to the multi- 408 client scenario. Stream identifiers can be used by several 409 control streams, so that "passing the remote" would be possi- 410 ble. The protocol would not address how several clients nego- 411 tiate access; this is left to either a "social protocol" or 412 some other floor control mechanism. 414 1.6 Extending RTSP 416 Since not all media servers have the same functionality, media 417 servers by necessity will support different sets of requests. For 418 example: 420 + A server may not be capable of seeking (absolute positioning) if 421 it is to support live events only. 423 + Some servers may not support setting stream parameters and thus 424 not support GET_PARAMETER and SET_PARAMETER. 426 A server SHOULD implement all header fields described in Section 13. 428 It is up to the creators of presentation descriptions not to ask the 429 impossible of a server. This situation is similar in HTTP/1.1 [26], 430 where the methods described in [H19.5] are not likely to be supported 431 across all servers. 433 RTSP can be extended in three ways, listed here in order of the mag- 434 nitude of changes supported: 436 + Existing methods can be extended with new parameters, as long as 437 these parameters can be safely ignored by the recipient. (This is 438 equivalent to adding new parameters to an HTML tag.) If the 439 client needs negative acknowledgement when a method extension is 440 not supported, a tag corresponding to the extension may be added 441 in the Require: field (see Section 13.32). 443 + New methods can be added. If the recipient of the message does 444 not understand the request, it responds with error code 501 (Not 445 Implemented) and the sender should not attempt to use this method 446 again. A client may also use the OPTIONS method to inquire about 447 methods supported by the server. The server SHOULD list the meth- 448 ods it supports using the Public response header. 450 + A new version of the protocol can be defined, allowing almost all 451 aspects (except the position of the protocol version number) to 452 change. 454 The basic capability discovery mechanism can be used to both discover 455 support for a certain feature and to ensure that a feature is avail- 456 able when performing a request. For detailed explanation of this see 457 chapter 10. 459 1.7 Overall Operation 461 Each presentation and media stream may be identified by a RTSP URL. 462 The overall presentation and the properties of the media the presen- 463 tation is made up of are defined by a presentation description file, 464 the format of which is outside the scope of this specification. The 465 presentation description file may be obtained by the client using 466 HTTP or other means such as email and may not necessarily be stored 467 on the media server. 469 For the purposes of this specification, a presentation description is 470 assumed to describe one or more presentations, each of which main- 471 tains a common time axis. For simplicity of exposition and without 472 loss of generality, it is assumed that the presentation description 473 contains exactly one such presentation. A presentation may contain 474 several media streams. 476 The presentation description file contains a description of the media 477 streams making up the presentation, including their encodings, lan- 478 guage, and other parameters that enable the client to choose the most 479 appropriate combination of media. In this presentation description, 480 each media stream that is individually controllable by RTSP is 481 identified by a RTSP URL, which points to the media server handling 482 that particular media stream and names the stream stored on that 483 server. Several media streams can be located on different servers; 484 for example, audio and video streams can be split across servers for 485 load sharing. The description also enumerates which transport methods 486 the server is capable of. 488 Besides the media parameters, the network destination address and 489 port need to be determined. Several modes of operation can be distin- 490 guished: 492 Unicast: The media is transmitted to the source of the RTSP 493 request, with the port number chosen by the client. Alterna- 494 tively, the media is transmitted on the same reliable stream 495 as RTSP. 497 Multicast, server chooses address: The media server picks the mul- 498 ticast address and port. This is the typical case for a live 499 or near-media-on-demand transmission. 501 Multicast, client chooses address: If the server is to participate 502 in an existing multicast conference, the multicast address, 503 port and encryption key are given by the conference descrip- 504 tion, established by means outside the scope of this specifi- 505 cation. 507 1.8 RTSP States 509 RTSP controls a stream which may be sent via a separate protocol, 510 independent of the control channel. For example, RTSP control may 511 occur on a TCP connection while the data flows via UDP. Thus, data 512 delivery continues even if no RTSP requests are received by the media 513 server. Also, during its lifetime, a single media stream may be con- 514 trolled by RTSP requests issued sequentially on different TCP connec- 515 tions. Therefore, the server needs to maintain "session state" to be 516 able to correlate RTSP requests with a stream. The state transitions 517 are described in Appendix A. 519 Many methods in RTSP do not contribute to state. However, the follow- | 520 ing play a central role in defining the allocation and usage of | 521 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, PING | 522 and TEARDOWN. 524 SETUP: Causes the server to allocate resources for a stream and 525 create a RTSP session. 527 PLAY: Starts data transmission on a stream allocated via SETUP. | 529 PAUSE: Temporarily halts a stream without freeing server resources. 531 REDIRECT: Indicates that the session should be moved to new server 532 / location 534 PING: Prevents the identified session from being timed out. 536 TEARDOWN: Frees resources associated with the stream. The RTSP 537 session ceases to exist on the server. 539 RTSP methods that contribute to state use the Session header field 540 (Section 13.37) to identify the RTSP session whose state is being 541 manipulated. The server generates session identifiers in response to 542 SETUP requests (Section 11.3). 544 1.9 Relationship with Other Protocols 546 RTSP has some overlap in functionality with HTTP. It also may inter- 547 act with HTTP in that the initial contact with streaming content is 548 often to be made through a web page. The current protocol specifica- 549 tion aims to allow different hand-off points between a web server and 550 the media server implementing RTSP. For example, the presentation 551 description can be retrieved using HTTP or RTSP, which reduces 552 roundtrips in web-browser-based scenarios, yet also allows for stan- 553 dalone RTSP servers and clients which do not rely on HTTP at all. 554 However, RTSP differs fundamentally from HTTP in that most data 555 delivery takes place out-of-band in a different protocol. HTTP is an 556 asymmetric protocol where the client issues requests and the server 557 responds. In RTSP, both the media client and media server can issue 558 requests. RTSP requests are also stateful; they may set parameters 559 and continue to control a media stream long after the request has 560 been acknowledged. 562 Re-using HTTP functionality has advantages in at least two 563 areas, namely security and proxies. The requirements are very 564 similar, so having the ability to adopt HTTP work on caches, 565 proxies and authentication is valuable. 567 RTSP assumes the existence of a presentation description format that 568 can express both static and temporal properties of a presentation 569 containing several media streams. Session Description Protocol (SDP) 570 [24] is generally the format of choice; however, RTSP is not bound to 571 it. For data delivery, most real-time media will use RTP as a trans- 572 port protocol. While RTSP works well with RTP, it is not tied to RTP. 574 2 Notational Conventions 576 Since many of the definitions and syntax are identical to HTTP/1.1, 577 this specification only points to the section where they are defined 578 rather than copying it. For brevity, [HX.Y] is to be taken to refer 579 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [26]). 581 All the mechanisms specified in this document are described in both 582 prose and an augmented Backus-Naur form (BNF) similar to that used in 583 [H2.1]. It is described in detail in RFC 2234 [14], with the differ- 584 ence that this RTSP specification maintains the "#" notation for 585 comma-separated lists from [H2.1]. 587 In this draft, we use indented and smaller-type paragraphs to provide 588 background and motivation. This is intended to give readers who were 589 not involved with the formulation of the specification an understand- 590 ing of why things are the way that they are in RTSP. 592 b 594 3 Protocol Parameters 596 3.1 RTSP Version 598 HTTP Specification Section [H3.1] applies, with HTTP replaced by 599 RTSP. This specification defines version 1.0 of RTSP. 601 3.2 RTSP URL 603 The "rtsp", "rtsps" and "rtspu" schemes are used to refer to network 604 resources via the RTSP protocol. This section defines the scheme-spe- 605 cific syntax and semantics for RTSP URLs. The RTSP URL is case sensi- 606 tive. | 608 rtsp_URL = ( "rtsp:" / "rtspu:" / "rtsps:" ) || 609 "//" host [ ":" port ] [ abs_path [ "?" query ]] || 610 host = As defined by RFC 2732 [30] || 611 abs_path = As defined by RFC 2396 [22] || 612 port = *DIGIT || 613 query = As defined by RFC 2396 [22] || 615 Note that fragment and query identifiers do not have a well- 616 defined meaning at this time, with the interpretation left to 617 the RTSP server. 619 The scheme rtsp requires that commands are issued via a reliable pro- | 620 tocol (within the Internet, TCP), while the scheme rtspu identifies | 621 an unreliable protocol (within the Internet, UDP). The scheme rtsps | 622 identifies a reliable transport using secure transport, perhaps TLS | 623 [27]. The rtspu and rtsps is not defined in this specification and if | 624 for future extensions of the protocol. 626 If the port is empty or not given, port 554 SHALL be assumed. The 627 semantics are that the identified resource can be controlled by RTSP 628 at the server listening for TCP (scheme "rtsp") connections or UDP 629 (scheme "rtspu") packets on that port of host, and the Request-URI 630 for the resource is rtsp_URL. 632 The use of IP addresses in URLs SHOULD be avoided whenever possible 633 (see RFC 1924 [16]). Note: Using qualified domain names in any URL is 634 one requirement for making it possible for RFC 2326 implementations 635 of RTSP to use IPv6. This specification is updated to allow for lit- 636 eral IPv6 addresses in RTSP URLs using the host specification in RFC 637 2732 [30]. 639 A presentation or a stream is identified by a textual media identi- 640 fier, using the character set and escape conventions [H3.2] of URLs 641 (RFC 2396 [22]). URLs may refer to a stream or an aggregate of 642 streams, i.e., a presentation. Accordingly, requests described in 643 Section 11 can apply to either the whole presentation or an individ- 644 ual stream within the presentation. Note that some request methods 645 can only be applied to streams, not presentations and vice versa. 647 For example, the RTSP URL: 649 rtsp://media.example.com:554/twister/audiotrack 651 identifies the audio stream within the presentation "twister", which can 652 be controlled via RTSP requests issued over a TCP connection to port 554 653 of host media.example.com 655 Also, the RTSP URL: 657 rtsp://media.example.com:554/twister 659 identifies the presentation "twister", which may be composed of audio 660 and video streams. 662 This does not imply a standard way to reference streams in 663 URLs. The presentation description defines the hierarchical 664 relationships in the presentation and the URLs for the indi- 665 vidual streams. A presentation description may name a stream 666 "a.mov" and the whole presentation "b.mov". 668 The path components of the RTSP URL are opaque to the client and do 669 not imply any particular file system structure for the server. 671 This decoupling also allows presentation descriptions to be 672 used with non-RTSP media control protocols simply by replacing 673 the scheme in the URL. 675 3.3 Session Identifiers 677 Session identifiers are strings of any arbitrary length. A session | 678 identifier MUST be chosen randomly and MUST be at least eight charac- | 679 ters long to make guessing it more difficult. (See Section 17.) 681 session-id = 8*( ALPHA / DIGIT / safe ) 683 3.4 SMPTE Relative Timestamps 685 A SMPTE relative timestamp expresses time relative to the start of 686 the clip. Relative timestamps are expressed as SMPTE time codes for 687 frame-level access accuracy. The time code has the format 688 hours:minutes:seconds:frames.subframes, 689 with the origin at the start of the clip. The default smpte format 690 is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 691 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 692 use of alternative use of "smpte time". For the "frames" field in the 693 time value can assume the values 0 through 29. The difference between 694 30 and 29.97 frames per second is handled by dropping the first two 695 frame indices (values 00 and 01) of every minute, except every tenth 696 minute. If the frame value is zero, it may be omitted. Subframes are 697 measured in one-hundredth of a frame. 699 smpte-range = smpte-type "=" smpte-range-spec 700 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 701 / ( "-" smpte-time ) 702 smpte-type = "smpte" / "smpte-30-drop" / "smpte-25" 703 ; other timecodes may be added 704 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 705 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 707 Examples: 709 smpte=10:12:33:20- 710 smpte=10:07:33- 711 smpte=10:07:00-10:07:33:05.01 712 smpte-25=10:07:00-10:07:33:05.01 714 3.5 Normal Play Time 716 Normal play time (NPT) indicates the stream absolute position rela- 717 tive to the beginning of the presentation, not to be confused with 718 the Network Time Protocol (NTP). The timestamp consists of a decimal 719 fraction. The part left of the decimal may be expressed in either 720 seconds or hours, minutes, and seconds. The part right of the decimal 721 point measures fractions of a second. 723 The beginning of a presentation corresponds to 0.0 seconds. Negative 724 values are not defined. The special constant now is defined as the 725 current instant of a live event. It MAY only be used for live events, 726 and SHALL NOT be used for on-demand content. 728 NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the 729 viewer associates with a program. It is often digitally displayed on 730 a VCR. NPT advances normally when in normal play mode (scale = 1), 731 advances at a faster rate when in fast scan forward (high positive 732 scale ratio), decrements when in scan reverse (high negative scale 733 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 734 SMPTE time codes." [5] 736 npt-range = ["npt" "="] npt-range-spec 737 ; implementations SHOULD use npt= prefix, but SHOULD 738 ; be prepared to interoperate with RFC 2326 739 ; implementations which don't use it 740 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 741 npt-time = "now" / npt-sec / npt-hhmmss 742 npt-sec = 1*DIGIT [ "." *DIGIT ] 743 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 744 npt-hh = 1*DIGIT ; any positive number 745 npt-mm = 1*2DIGIT ; 0-59 746 npt-ss = 1*2DIGIT ; 0-59 748 Examples: 750 npt=123.45-125 751 npt=12:05:35.3- 752 npt=now- 754 The syntax conforms to ISO 8601. The npt-sec notation is opti- 755 mized for automatic generation, the ntp-hhmmss notation for 756 consumption by human readers. The "now" constant allows 757 clients to request to receive the live feed rather than the 758 stored or time-delayed version. This is needed since neither 759 absolute time nor zero time are appropriate for this case. 761 3.6 Absolute Time 763 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 764 Fractions of a second may be indicated. 766 utc-range = "clock" "=" utc-range-spec 767 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 768 utc-time = utc-date "T" utc-time "Z" 769 utc-date = 8DIGIT ; < YYYYMMDD > 770 utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > 771 fraction = 1*DIGIT 773 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 774 UTC: 776 19961108T143720.25Z 778 3.7 Feature-tags 780 Feature-tags are unique identifiers used to designate new features in 781 RTSP. These tags are used in in Require (Section 13.32), Proxy- 782 Require (Section 13.27), Unsupported (Section 13.41), and Supported 783 (Section 13.38) header fields. 785 Syntax: 787 feature-tag = token 789 The creator of a new RTSP feature-tag should either prefix the fea- 790 ture-tag with a reverse domain name (e.g., "com.foo.mynewfeature" is 791 an apt name for a feature whose inventor can be reached at 792 "foo.com"), or register the new feature-tag with the Internet 793 Assigned Numbers Authority (IANA), see IANA Section 18. 795 4 RTSP Message 797 RTSP is a text-based protocol and uses the ISO 10646 character set in 798 UTF-8 encoding (RFC 2279 [18]). Lines are terminated by CRLF, but 799 receivers should be prepared to also interpret CR and LF by them- 800 selves as line terminators. 802 Text-based protocols make it easier to add optional parameters 803 in a self-describing manner. Since the number of parameters 804 and the frequency of commands is low, processing efficiency is 805 not a concern. Text-based protocols, if done carefully, also 806 allow easy implementation of research prototypes in scripting 807 languages such as Tcl, Visual Basic and Perl. 809 The 10646 character set avoids tricky character set switching, but is 810 invisible to the application as long as US-ASCII is being used. This 811 is also the encoding used for RTCP. ISO 8859-1 translates directly 812 into Unicode with a high-order octet of zero. ISO 8859-1 characters 813 with the most-significant bit set are represented as 1100001x 814 10xxxxxx. (See RFC 2279 [18]) 816 RTSP messages can be carried over any lower-layer transport protocol 817 that is 8-bit clean. RTSP messages are vulnerable to bit errors and 818 SHOULD NOT be subjected to them. 820 Requests contain methods, the object the method is operating upon and 821 parameters to further describe the method. Methods are idempotent, 822 unless otherwise noted. Methods are also designed to require little 823 or no state maintenance at the media server. 825 4.1 Message Types 827 See [H4.1]. 829 4.2 Message Headers 831 See [H4.2]. 833 4.3 Message Body 835 See [H4.3] 837 4.4 Message Length 838 When a message body is included with a message, the length of that 839 body is determined by one of the following (in order of precedence): 841 1. Any response message which MUST NOT include a message body 842 (such as the 1xx, 204, and 304 responses) is always terminated 843 by the first empty line after the header fields, regardless of 844 the entity-header fields present in the message. (Note: An 845 empty line consists of only CRLF.) 847 2. If a Content-Length header field (section 13.14) is present, 848 its value in bytes represents the length of the message-body. 849 If this header field is not present, a value of zero is 850 assumed. 852 Note that RTSP does not (at present) support the HTTP/1.1 "chunked" 853 transfer coding(see [H3.6.1]) and requires the presence of the Con- 854 tent-Length header field. 856 Given the moderate length of presentation descriptions 857 returned, the server should always be able to determine its 858 length, even if it is generated dynamically, making the chun- 859 ked transfer encoding unnecessary. 861 5 General Header Fields 863 See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, 864 and Warning headers are not defined. RTSP further defines the CSeq, 865 and Timestamp: 867 general-header = Cache-Control ; Section 13.9 868 / Connection ; Section 13.10 869 / CSeq ; Section 13.17 870 / Date ; Section 13.18 871 / Timestamp ; Section 13.39 872 / Via ; Section 13.44 874 6 Request 876 A request message from a client to a server or vice versa includes, 877 within the first line of that message, the method to be applied to 878 the resource, the identifier of the resource, and the protocol ver- 879 sion in use. 881 Request = Request-Line ; Section 6.1 882 *( general-header ; Section 5 883 / request-header ; Section 6.2 884 / entity-header ) ; Section 8.1 885 CRLF 886 [ message-body ] ; Section 4.3 888 6.1 Request Line 890 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 892 Method = "DESCRIBE" ; Section 11.2 893 / "GET_PARAMETER" ; Section 11.7 894 / "OPTIONS" ; Section 11.1 895 / "PAUSE" ; Section 11.5 896 / "PLAY" ; Section 11.4 897 / "PING" ; Section 11.10 898 / "REDIRECT" ; Section 11.9 899 / "SETUP" ; Section 11.3 900 / "SET_PARAMETER" ; Section 11.8 901 / "TEARDOWN" ; Section 11.6 902 / extension-method 904 extension-method = token 905 Request-URI = "*" / absolute_URI 906 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 908 6.2 Request Header Fields 910 request-header = Accept ; Section 13.1 911 / Accept-Encoding ; Section 13.2 912 / Accept-Language ; Section 13.3 913 / Authorization ; Section 13.6 914 / Bandwidth ; Section 13.7 915 / Blocksize ; Section 13.8 916 / From ; Section 13.20 917 / If-Modified-Since ; Section 13.23 918 / Proxy-Require ; Section 13.27 919 / Range ; Section 13.29 920 / Referer ; Section 13.30 921 / Require ; Section 13.32 922 / Scale ; Section 13.34 923 / Session ; Section 13.37 924 / Speed ; Section 13.35 925 / Supported ; Section 13.38 926 / Transport ; Section 13.40 927 / User-Agent ; Section 13.42 929 Note that in contrast to HTTP/1.1 [26], RTSP requests always contain 930 the absolute URL (that is, including the scheme, host and port) 931 rather than just the absolute path. 933 HTTP/1.1 requires servers to understand the absolute URL, but 934 clients are supposed to use the Host request header. This is 935 purely needed for backward-compatibility with HTTP/1.0 936 servers, a consideration that does not apply to RTSP. 938 The asterisk "*" in the Request-URI means that the request does not 939 apply to a particular resource, but to the server or proxy itself, 940 and is only allowed when the method used does not necessarily apply 941 to a resource. 943 One example would be as follows: 945 OPTIONS * RTSP/1.0 947 An OPTIONS in this form will determine the capabilities of the server 948 or the proxy that first receives the request. If one needs to address 949 the server explicitly, then one should use an absolute URL with the 950 server's address. 952 OPTIONS rtsp://example.com RTSP/1.0 954 7 Response 956 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 957 Also, RTSP defines additional status codes and does not define some 958 HTTP codes. The valid response codes and the methods they can be used 959 with are defined in Table 1. 961 After receiving and interpreting a request message, the recipient 962 responds with an RTSP response message. 964 Response = Status-Line ; Section 7.1 965 *( general-header ; Section 5 966 / response-header ; Section 7.1.2 967 / entity-header ) ; Section 8.1 968 CRLF 969 [ message-body ] ; Section 4.3 971 7.1 Status-Line 973 The first line of a Response message is the Status-Line, consisting 974 of the protocol version followed by a numeric status code, and the 975 textual phrase associated with the status code, with each element 976 separated by SP characters. No CR or LF is allowed except in the 977 final CRLF sequence. 979 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 981 7.1.1 Status Code and Reason Phrase 983 The Status-Code element is a 3-digit integer result code of the 984 attempt to understand and satisfy the request. These codes are fully 985 defined in Section 12. The Reason-Phrase is intended to give a short 986 textual description of the Status-Code. The Status-Code is intended 987 for use by automata and the Reason-Phrase is intended for the human 988 user. The client is not required to examine or display the Reason- 989 Phrase. 991 The first digit of the Status-Code defines the class of response. The 992 last two digits do not have any categorization role. There are 5 993 values for the first digit: 995 + 1xx: Informational - Request received, continuing process 997 + 2xx: Success - The action was successfully received, understood, 998 and accepted 1000 + 3rr: Redirection - Further action must be taken in order to com- 1001 plete the request 1003 + 4xx: Client Error - The request contains bad syntax or cannot be 1004 fulfilled 1006 + 5xx: Server Error - The server failed to fulfill an apparently 1007 valid request 1009 The individual values of the numeric status codes defined for 1010 RTSP/1.0, and an example set of corresponding Reason-Phrase's, are 1011 presented below. The reason phrases listed here are only recommended 1012 -- they may be replaced by local equivalents without affecting the 1013 protocol. Note that RTSP adopts most HTTP/1.1 [26] status codes and 1014 adds RTSP-specific status codes starting at x50 to avoid conflicts 1015 with newly defined HTTP status codes. 1017 Status-Code = "100" ; Continue 1018 / "200" ; OK 1019 / "201" ; Created 1020 / "250" ; Low on Storage Space 1021 / "300" ; Multiple Choices 1022 / "301" ; Moved Permanently 1023 / "302" ; Moved Temporarily 1024 / "303" ; See Other 1025 / "304" ; Not Modified 1026 / "305" ; Use Proxy 1027 / "350" ; Going Away 1028 / "351" ; Load Balancing 1029 / "400" ; Bad Request 1030 / "401" ; Unauthorized 1031 / "402" ; Payment Required 1032 / "403" ; Forbidden 1033 / "404" ; Not Found 1034 / "405" ; Method Not Allowed 1035 / "406" ; Not Acceptable 1036 / "407" ; Proxy Authentication Required 1037 / "408" ; Request Time-out 1038 / "410" ; Gone 1039 / "411" ; Length Required 1040 / "412" ; Precondition Failed 1041 / "413" ; Request Entity Too Large 1042 / "414" ; Request-URI Too Large 1043 / "415" ; Unsupported Media Type 1044 / "451" ; Parameter Not Understood 1045 / "452" ; reserved 1046 / "453" ; Not Enough Bandwidth 1047 / "454" ; Session Not Found 1048 / "455" ; Method Not Valid in This State 1049 / "456" ; Header Field Not Valid for Resource 1050 / "457" ; Invalid Range 1051 / "458" ; Parameter Is Read-Only 1052 / "459" ; Aggregate operation not allowed 1053 / "460" ; Only aggregate operation allowed 1054 / "461" ; Unsupported transport 1055 / "462" ; Destination unreachable 1056 / "500" ; Internal Server Error 1057 / "501" ; Not Implemented 1058 / "502" ; Bad Gateway 1059 / "503" ; Service Unavailable 1060 / "504" ; Gateway Time-out 1061 / "505" ; RTSP Version not supported 1062 / "551" ; Option not supported 1063 / extension-code 1064 extension-code = 3DIGIT 1065 Reason-Phrase = * 1067 RTSP status codes are extensible. RTSP applications are not required 1068 to understand the meaning of all registered status codes, though such 1069 understanding is obviously desirable. However, applications MUST 1070 understand the class of any status code, as indicated by the first 1071 digit, and treat any unrecognized response as being equivalent to the 1072 x00 status code of that class, with the exception that an unrecog- 1073 nized response MUST NOT be cached. For example, if an unrecognized 1074 status code of 431 is received by the client, it can safely assume 1075 that there was something wrong with its request and treat the 1076 response as if it had received a 400 status code. In such cases, user 1077 agents SHOULD present to the user the entity returned with the 1078 response, since that entity is likely to include human-readable 1079 information which will explain the unusual status. 1081 Code Reason Method 1082 -------------------------------------------------------- 1083 100 Continue all 1084 -------------------------------------------------------- 1085 200 OK all 1086 201 Created RECORD 1087 250 Low on Storage Space RECORD 1088 -------------------------------------------------------- 1089 300 Multiple Choices all 1090 301 Moved Permanently all 1091 302 Found all 1092 303 See Other all 1093 305 Use Proxy all 1094 350 Going Away all 1095 351 Load Balancing all 1096 -------------------------------------------------------- 1097 Code Reason Method 1098 -------------------------------------------------------- 1099 400 Bad Request all 1100 401 Unauthorized all 1101 402 Payment Required all 1102 403 Forbidden all 1103 404 Not Found all 1104 405 Method Not Allowed all 1105 406 Not Acceptable all 1106 407 Proxy Authentication Required all 1107 408 Request Timeout all 1108 410 Gone all 1109 411 Length Required all 1110 412 Precondition Failed DESCRIBE, SETUP 1111 413 Request Entity Too Large all 1112 414 Request-URI Too Long all 1113 415 Unsupported Media Type all 1114 451 Parameter Not Understood SET_PARAMETER 1115 452 reserved n/a 1116 453 Not Enough Bandwidth SETUP 1117 454 Session Not Found all 1118 455 Method Not Valid In This State all 1119 456 Header Field Not Valid all 1120 457 Invalid Range PLAY, PAUSE 1121 458 Parameter Is Read-Only SET_PARAMETER 1122 459 Aggregate Operation Not Allowed all 1123 460 Only Aggregate Operation Allowed all 1124 461 Unsupported Transport all 1125 462 Destination Unreachable all 1126 -------------------------------------------------------- 1127 500 Internal Server Error all 1128 501 Not Implemented all 1129 502 Bad Gateway all 1130 503 Service Unavailable all 1131 504 Gateway Timeout all 1132 505 RTSP Version Not Supported all 1133 551 Option not support all 1135 Table 1: Status codes and their usage with RTSP methods 1137 7.1.2 Response Header Fields 1139 The response-header fields allow the request recipient to pass addi- 1140 tional information about the response which cannot be placed in the 1141 Status-Line. These header fields give information about the server 1142 and about further access to the resource identified by the Request- 1143 URI. 1145 response-header = Accept-Ranges ; Section 13.4 1146 / Location ; Section 13.25 1147 / Proxy-Authenticate ; Section 13.26 1148 / Public ; Section 13.28 1149 / Range ; Section 13.29 1150 / Retry-After ; Section 13.31 1151 / RTP-Info ; Section 13.33 1152 / Scale ; Section 13.34 1153 / Session ; Section 13.37 1154 / Server ; Section 13.36 1155 / Speed ; Section 13.35 1156 / Transport ; Section 13.40 1157 / Unsupported ; Section 13.41 1158 / Vary ; Section 13.43 1159 / WWW-Authenticate ; Section 13.45 1161 Response-header field names can be extended reliably only in combina- 1162 tion with a change in the protocol version. However, new or experi- 1163 mental header fields MAY be given the semantics of response-header 1164 fields if all parties in the communication recognize them to be 1165 response-header fields. Unrecognized header fields are treated as 1166 entity-header fields. 1168 8 Entity 1170 Request and Response messages MAY transfer an entity if not otherwise 1171 restricted by the request method or response status code. An entity 1172 consists of entity-header fields and an entity-body, although some 1173 responses will only include the entity-headers. 1175 In this section, both sender and recipient refer to either the client 1176 or the server, depending on who sends and who receives the entity. 1178 8.1 Entity Header Fields 1180 Entity-header fields define optional meta-information about the 1181 entity-body or, if no body is present, about the resource identified 1182 by the request. 1184 entity-header = Allow ; Section 13.5 1185 / Content-Base ; Section 13.11 1186 / Content-Encoding ; Section 13.12 1187 / Content-Language ; Section 13.13 1188 / Content-Length ; Section 13.14 1189 / Content-Location ; Section 13.15 1190 / Content-Type ; Section 13.16 1191 / Expires ; Section 13.19 1192 / Last-Modified ; Section 13.24 1193 / extension-header 1194 extension-header = message-header 1196 The extension-header mechanism allows additional entity-header fields 1197 to be defined without changing the protocol, but these fields cannot 1198 be assumed to be recognizable by the recipient. Unrecognized header 1199 fields SHOULD be ignored by the recipient and forwarded by proxies. 1201 8.2 Entity Body 1203 See [H7.2] with the addition that a RTSP message with an entity body 1204 MUST include a Content-Type header. 1206 9 Connections 1208 RTSP requests can be transmitted in several different ways: 1210 + persistent transport connections used for several request- 1211 response transactions; 1213 + one connection per request/response transaction; 1215 + connectionless mode. 1217 The type of transport connection is defined by the RTSP URI (Section 1218 3.2). For the scheme "rtsp", a connection is assumed, while the 1219 scheme "rtspu" calls for RTSP requests to be sent without setting up 1220 a connection. 1222 Unlike HTTP, RTSP allows the media server to send requests to the 1223 media client. However, this is only supported for persistent connec- 1224 tions, as the media server otherwise has no reliable way of reaching 1225 the client. Also, this is the only way that requests from media 1226 server to client are likely to traverse firewalls. 1228 9.1 Pipelining 1230 A client that supports persistent connections or connectionless mode 1231 MAY "pipeline" its requests (i.e., send multiple requests without 1232 waiting for each response). A server MUST send its responses to those 1233 requests in the same order that the requests were received. 1235 9.2 Reliability and Acknowledgements 1237 Requests are acknowledged by the receiver unless they are sent to a 1238 multicast group. If there is no acknowledgement, the sender may 1239 resend the same message after a timeout of one round-trip time (RTT). 1240 The round-trip time is estimated as in TCP (RFC 1123) [15], with an 1241 initial round-trip value of 500 ms. An implementation MAY cache the 1242 last RTT measurement as the initial value for future connections. 1244 If a reliable transport protocol is used to carry RTSP, requests MUST 1245 NOT be retransmitted; the RTSP application MUST instead rely on the 1246 underlying transport to provide reliability. 1248 If both the underlying reliable transport such as TCP and the 1249 RTSP application retransmit requests, it is possible that each 1250 packet loss results in two retransmissions. The receiver can- 1251 not typically take advantage of the application-layer retrans- 1252 mission since the transport stack will not deliver the appli- 1253 cation-layer retransmission before the first attempt has 1254 reached the receiver. If the packet loss is caused by conges- 1255 tion, multiple retransmissions at different layers will exac- 1256 erbate the congestion. 1258 If RTSP is used over a small-RTT LAN, standard procedures for opti- 1259 mizing initial TCP round trip estimates, such as those used in T/TCP 1260 (RFC 1644) [19], can be beneficial. 1262 The Timestamp header (Section 13.39) is used to avoid the retransmis- 1263 sion ambiguity problem [20] and obviates the need for Karn's algo- 1264 rithm. 1266 Each request carries a sequence number in the CSeq header (Section 1267 13.17), which MUST be incremented by one for each distinct request 1268 transmitted. If a request is repeated because of lack of acknowledge- 1269 ment, the request MUST carry the original sequence number (i.e., the 1270 sequence number is not incremented). 1272 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1273 support UDP. The default port for the RTSP server is 554 for both UDP 1274 and TCP. 1276 A number of RTSP packets destined for the same control end point may 1277 be packed into a single lower-layer PDU or encapsulated into a TCP 1278 stream. RTSP data MAY be interleaved with RTP and RTCP packets. 1280 Unlike HTTP, an RTSP message MUST contain a Content-Length header 1281 field whenever that message contains a payload. Otherwise, an RTSP 1282 packet is terminated with an empty line immediately following the 1283 last message header. 1285 9.3 The usage of connections 1287 TCP can be used for both persistent connections and for one message 1288 exchange per connection, as presented above. This section gives fur- 1289 ther rules and recommendations on how to handle these connections so 1290 maximum interoperability and flexibility can be achieved. 1292 A server SHALL handle both persistent connections and one 1293 request/response transaction per connection. A persistent connection 1294 MAY be used for all transactions between the server and client, 1295 including messages to multiple RTSP sessions. However the persistent 1296 connection MAY also be closed after a few message exchanges, e.g. the 1297 initial setup and play command in a session. Later when the client 1298 wishes to send a new request, e.g. pause, to the session a new con- 1299 nection is opened. This connection may either be for a single message 1300 exchange or can be kept open for several messages, i.e. persistent. 1302 A major motivation for allowing non-persistent connections are that 1303 they ensure fault tolerance. A server and client supporting non-per- 1304 sistent connection can survive a loss of a TCP connection, e.g. due 1305 to a NAT timeout. When the it is discovered that the TCP connection 1306 has been lost one sets up a new one. 1308 The client MAY close the connection at any time when no outstanding | 1309 request/response transactions exist. The server SHOULD NOT close the | 1310 connection unless at least one RTSP session timeout period has passed | 1311 without data traffic. A server MUST NOT initiate a close of a connec- | 1312 tion directly after responding to a TEARDOWN request for the whole | 1313 session. A server MUST NOT close the connection as a result of | 1314 responding to a request with an error code. Doing this would prevent | 1315 or result in extra overhead for the client when testing advanced or | 1316 special types of requests. 1318 The client SHOULD NOT have more than one connection to the server at 1319 any given point. If a client or proxy handles multiple RTSP sessions 1320 on the same server, it is RECOMMENDED to use only a single connec- 1321 tion. 1323 Older services which was implemented according to RFC 2326 sometimes 1324 requires the client to use persistent connection. The client closing 1325 the connection may result in that the server removes the session. To 1326 achieve interoperability with old servers any client is strongly REC- 1327 OMMENDED to use persistent connections. 1329 A Client is also strongly RECOMMENDED to use persistent connections 1330 as it allows the server to send request to the client. In cases 1331 where no connection exist between the server and the client, this may 1332 cause the server to be forced to drop the RTSP session without noti- 1333 fying the client why,due to the lack of signalling channel. An exam- 1334 ple of such a case is when the server desires to send a REDIRECT 1335 request for a RTSP session to the client. 1337 If a service requires the use of persistent connection an feature-tag 1338 is specified for usage in the Require and Proxy-Require headers. 1340 con.persistent 1342 A server implemented according to this specification MUST respond 1343 that it supports the "play.basic" feature-tag above. A client MAY 1344 send a request including the Supported header in a request to deter- 1345 mine support of non-persistent connections. A server supporting non- 1346 persistent connections will return the "play.basic" feature-tag in 1347 its response. If the client receives the feature-tag in the response, 1348 it can be certain that the server handles non-persistent connections. 1350 9.4 Use of IPv6 1352 This specification has been updated so that it supports IPv6. How- 1353 ever this support was not present in RFC 2326 therefore some interop- 1354 erability issues exist. A RFC 2326 implementation can support IPv6 as 1355 long as no explicit IPv6 addresses are used within RTSP messages. 1356 This require that any RTSP URL pointing at a IPv6 host must use fully 1357 qualified domain name and not a IPv6 address. Further the Transport 1358 header must not use the parameters source and destination. 1360 Implementations according to this specification MUST understand IPv6 1361 addresses in URLs, and headers. By this requirement the feature-tag 1362 "play.basic" can be used to determine that a server or client is 1363 capable of handling IPv6 within RTSP. 1365 10 Capability Handling 1367 This chapter describes the capability handling mechanism available in 1368 RTSP which allows RTSP to be extended. Extensions too this version of 1369 the protocol are basically done in two ways. First, new headers can 1370 be added. Secondly, new methods can be added. The capability handling 1371 mechanism is designed to handle these two cases. 1373 When a method is added the involved parties can use the OPTIONS 1374 method to discover if it is supported. This is done by issuing a 1375 OPTIONS request to the other party. Depending on the URL it will 1376 either apply in regards to a certain media resource, the whole server 1377 in general, or simply the next hop. The OPTIONS response will contain 1378 a Public which declares all methods supported for the indicated 1379 resource. 1381 It is not necessary to use OPTIONS to discover support of a method, 1382 it is possible to simple try it. If the receiver of the request does 1383 not support the method it will respond with an error code indicating 1384 the the method are either not implemented (501) or does not apply for 1385 the resource (405). The choice between the two discovery methods 1386 depends on the requirements of the service. 1388 To handle functionality additions that are not new methods feature- 1389 tags are defined. Each feature-tag represents a certain block of 1390 functionality. The amount of functionality that a feature-tag repre- 1391 sents can vary significant. A simple feature-tag can simple represent 1392 the functionality a single header gives. Another feature-tag is 1393 "play.basic" which represents the minimal playback implementation 1394 according to the updated specification. 1396 The feature-tags are then used to determine if the client, server or 1397 proxy supports the functionality that is necessary to achieve the 1398 desired service. To determine support of a feature-tag several dif- 1399 ferent headers can be used, each explained below: 1401 Supported: The supported header are used to determine the complete 1402 set of functionality that both client and server has. The 1403 intended usage is to determine before one needs to use a func- 1404 tionality that it is supported. If can be used in any method 1405 however OPTIONS is the most suitable as one at the same time 1406 determines all methods that are implemented. When sending a 1407 request the requestor declares all its capabilities by includ- 1408 ing all supported feature-tags. The results in that the 1409 receiver learns the requestors feature support. The receiver 1410 then includes its set of features in the response. 1412 Require: The Require header can be included in any request where 1413 the end point, i.e. the client or server, is required to 1414 understand the feature to correctly perform the request. This 1415 can for example be a SETUP request where the server must 1416 understand a certain parameter to be able to set up the media 1417 delivery correctly. Ignoring this parameter would not have the 1418 desired effect and is not acceptable. Therefore the end-point 1419 receiving a request containing a Require must negatively 1420 acknowledge any feature that it does not understand and not 1421 perform the request. The response in cases where features are 1422 not understood are 551 (Option Not Supported). Also the 1423 features that are not understood are given in the Unsupported 1424 header in the response. 1426 Proxy-Require: This method has the same purpose and workings as 1427 Require except that it only applies to proxies and not the end 1428 point. Features that needs to be supported by both proxies and 1429 end-point needs to be included in both the Require and Proxy- 1430 Require header. 1432 Unsupported: This header is used in 551 error response to tell 1433 which feature(s) that was not supported. Such a response is 1434 only the result of the usage of the Require and/or Proxy- 1435 Require header where one or more feature where not supported. 1436 This information allows the requestor to make the best of sit- 1437 uations as it knows which features that was not supported. 1439 11 Method Definitions 1441 The method token indicates the method to be performed on the resource 1442 identified by the Request-URI case-sensitive. New methods may be 1443 defined in the future. Method names may not start with a $ character 1444 (decimal 24) and must be a token as defined by the ABNF. Methods are 1445 summarized in Table 2. 1447 method direction object Server req. Client req. 1448 ---------------------------------------------------------------- 1449 DESCRIBE C->S P,S recommended recommended 1450 GET_PARAMETER C->S, S->C P,S optional optional 1451 OPTIONS C->S, S->C P,S R=Req, Sd=Opt Sd=Req, R=Opt 1452 PAUSE C->S P,S recommended recommended 1453 PING C->S, S->C P,S recommended optional 1454 PLAY C->S P,S required required 1455 REDIRECT S->C P,S optional optional 1456 SETUP C->S S required required 1457 SET_PARAMETER C->S, S->C P,S optional optional 1458 TEARDOWN C->S P,S required required 1460 Table 2: Overview of RTSP methods, their direction, and what objects 1461 (P: presentation, S: stream) they operate on. Legend: R=Responde to, 1462 Sd=Send, Opt: Optional, Req: Required, Rec: Recommended 1464 Notes on Table 2: PAUSE is recommended, but not required in that a 1465 fully functional server can be built that does not support this 1466 method, for example, for live feeds. If a server does not support a 1467 particular method, it MUST return 501 (Not Implemented) and a client 1468 SHOULD not try this method again for this server. 1470 11.1 OPTIONS 1472 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1473 request may be issued at any time, e.g., if the client is about to 1474 try a nonstandard request. It does not influence the session state. 1475 The Public header MUST be included in responses to indicate which 1476 methods that are supported by the server. To specify which methods 1477 that are possible to use for the specified resource, the Allow MAY be 1478 used. By including in the OPTIONS request a Supported header, the 1479 requester can determine which features the other part supports. 1481 The request URI determines which scope the OPTIONS request has. By 1482 giving the URI of a certain media the capabilities regarding this 1483 media will be responded. By using the "*" URI the request regards the 1484 next hop only, while having a URL with only the host address regards 1485 the server without any media relevance. 1487 Example: 1489 C->S: OPTIONS * RTSP/1.0 1490 CSeq: 1 1491 User-Agent: PhonyClient/1.2 1492 Require: 1493 Proxy-Require: gzipped-messages 1494 Supported: play-basic 1496 S->C: RTSP/1.0 200 OK 1497 CSeq: 1 1498 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1499 Supported: play-basic, implicit-play, gzipped-messages 1500 Server: PhonyServer/1.0 1502 Note that some of the feature-tags in Require and Proxy-Require are 1503 necessarily fictional features (one would hope that we would not pur- 1504 posefully overlook a truly useful feature just so that we could have 1505 a strong example in this section). 1507 11.2 DESCRIBE 1509 The DESCRIBE method retrieves the description of a presentation or 1510 media object identified by the request URL from a server. It may use 1511 the Accept header to specify the description formats that the client 1512 understands. The server responds with a description of the requested 1513 resource. The DESCRIBE reply-response pair constitutes the media ini- 1514 tialization phase of RTSP. 1516 Example: 1518 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 1519 CSeq: 312 1520 User-Agent: PhonyClient 1.2 1521 Accept: application/sdp, application/rtsl, application/mheg 1523 S->C: RTSP/1.0 200 OK 1524 CSeq: 312 1525 Date: 23 Jan 1997 15:35:06 GMT 1526 Server: PhonyServer 1.0 1527 Content-Type: application/sdp 1528 Content-Length: 376 1530 v=0 1531 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1532 s=SDP Seminar 1533 i=A Seminar on the session description protocol 1534 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1535 e=mjh@isi.edu (Mark Handley) 1536 c=IN IP4 224.2.17.12/127 1537 t=2873397496 2873404696 1538 a=recvonly 1539 m=audio 3456 RTP/AVP 0 1540 m=video 2232 RTP/AVP 31 1541 m=application 32416 UDP WB 1542 a=orient:portrait 1544 The DESCRIBE response MUST contain all media initialization informa- 1545 tion for the resource(s) that it describes. If a media client obtains 1546 a presentation description from a source other than DESCRIBE and that 1547 description contains a complete set of media initialization parame- 1548 ters, the client SHOULD use those parameters and not then request a 1549 description for the same media via RTSP. 1551 Additionally, servers SHOULD NOT use the DESCRIBE response as a means 1552 of media indirection. 1554 By forcing a DESCRIBE response to contain all media initial- 1555 ization for the set of streams that it describes, and discour- 1556 aging use of DESCRIBE for media indirection, we avoid looping 1557 problems that might result from other approaches. 1559 Media initialization is a requirement for any RTSP-based system, but 1560 the RTSP specification does not dictate that this must be done via 1561 the DESCRIBE method. There are three ways that an RTSP client may 1562 receive initialization information: 1564 + via RTSP's DESCRIBE method; 1566 + via some other protocol (HTTP, email attachment, etc.); 1568 + via the command line or standard input (thus working as a browser 1569 helper application launched with an SDP file or other media ini- 1570 tialization format). 1572 It is RECOMMENDED that minimal servers support the DESCRIBE method, 1573 and highly recommended that minimal clients support the ability to 1574 act as a "helper application" that accepts a media initialization 1575 file from standard input, command line, and/or other means that are 1576 appropriate to the operating environment of the client. 1578 11.3 SETUP 1580 The SETUP request for a URI specifies the transport mechanism to be 1581 used for the streamed media. A client can issue a SETUP request for a 1582 stream that is already set up or playing in the session to change 1583 transport parameters, which a server MAY allow. If it does not allow 1584 this, it MUST respond with error 455 (Method Not Valid In This 1585 State). 1587 A server MAY allow a client to do SETUP while in playing state to add 1588 additional media streams. If not supported, the server SHALL respond 1589 with error 455 (Method Not Allowed In This State). If supported, the 1590 added media SHALL then start to play in sync with the already playing 1591 media. To be able to sync the media with the already playing streams 1592 the SETUP response MUST include a RTP-Info header with the timestamp 1593 value, and a Range header with the corresponding normal play time. To 1594 indicate support for this optional feature the feature-tag: 1595 "setup.playing" is defined. 1597 The Transport header specifies the transport parameters acceptable to 1598 the client for data transmission; the response will contain the 1599 transport parameters selected by the server. 1601 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 1602 CSeq: 302 1603 Transport: RTP/AVP;unicast;client_port=4588-4589 1605 S->C: RTSP/1.0 200 OK 1606 CSeq: 302 1607 Date: 23 Jan 1997 15:35:06 GMT 1608 Server: PhonyServer 1.0 1609 Session: 47112344 1610 Transport: RTP/AVP;unicast; 1611 client_port=4588-4589;server_port=6256-6257 1613 For the benefit of any intervening firewalls, a client must indicate 1614 the transport parameters even if it has no influence over these 1615 parameters, for example, where the server advertises a fixed multi- 1616 cast address. 1618 Since SETUP includes all transport initialization information, 1619 firewalls and other intermediate network devices (which need 1620 this information) are spared the more arduous task of parsing 1621 the DESCRIBE response, which has been reserved for media ini- 1622 tialization. 1624 The server generates a session identifier in response to a SETUP 1625 request. If a SETUP request to a server includes a session identi- 1626 fier, the server MUST bundle this setup request into the existing 1627 session (aggregated session) or return error 459 (Aggregate Operation 1628 Not Allowed) (see Section 12.4.11). An Aggregate control URI MUST be 1629 used to control an aggregated session. This URI MUST be different 1630 from the stream control URIs of the individual media streams included 1631 in the aggregate. The Aggregate control URI SHOULD be specified by 1632 the session description since there is no general rule for deriving 1633 it from the various stream control URIs in the session. If an Aggre- 1634 gate control URI is not specified in the session description, a 1635 client MUST create an URI for aggregate control of the session. This 1636 URI MUST contain the servers host address and MUST contain the port, 1637 if applicable. Once an URI is used to refer to an aggregation for a 1638 given session, that URI MUST be used to refer to that aggregation for 1639 the duration of the session. If the contents of the aggregation 1640 change, then a different aggregate control URI SHOULD be used. 1642 While the session ID has enough information for aggregate con- 1643 trol of a session, the Aggregate control URI is still impor- 1644 tant for some methods such as SET_PARAMETER where the control 1645 URI enables the resource in question to be easily identified. 1646 The Aggregate control URI is also useful for proxies, enabling 1647 them to route the request to the appropriate server, and for 1648 logging, where it is useful to note the actual resource that a 1649 request was operating on. Finally, presence of the Aggregate 1650 control URI allows for backwards compatibility with RFC 2326 1651 [21]. 1653 A session will exist until it is either removed by a TEARDOWN request 1654 or is timed-out by the server. The server MAY remove a session that 1655 has not demonstrated liveness signs from the client within a certain 1656 timeout period. The default timeout value is 60 seconds; the server 1657 MAY set this to a different value and indicate so in the timeout 1658 field of the Session header in the SETUP response. For further dis- 1659 cussion see chapter 13.37. Signs of liveness for a RTSP session are: 1661 + Any RTSP request from a client which includes a Session header 1662 with that session's ID. 1664 + If RTP is used as a transport for the underlying media streams, 1665 an RTCP sender or receiver report from the client for any of the 1666 media streams in that RTSP session. 1668 If a SETUP request on a session fails for any reason, the session | 1669 state, as well as transport and other parameters for associated | 1670 streams SHALL remain unchanged from their values as if the SETUP | 1671 request had never been received by the server. 1673 11.4 PLAY 1675 The PLAY method tells the server to start sending data via the mecha- 1676 nism specified in SETUP. A client MUST NOT issue a PLAY request until 1677 any outstanding SETUP requests have been acknowledged as successful. 1679 In an aggregated session the PLAY request MUST contain an aggregated 1680 control URL. A server SHALL responde with error 460 (Only Aggregate 1681 Operation Allowed) if the client PLAY request URI is for one of the 1682 media. The media in an aggregate SHALL be played in sync. If a client 1683 want individual control of the media it must use separate RTSP ses- 1684 sions for each media. 1686 The PLAY request positions the normal play time to the beginning of 1687 the range specified by the Range header and delivers stream data 1688 until the end of the range is reached. To allow for precise composi- 1689 tion multiple ranges MAY be specified. The range values are valid if 1690 all given ranges are part of any media. If a given range value points 1691 outside of the media, the response SHALL be the 457 (Invalid Range) 1692 error code. 1694 The below example will first play seconds 10 through 15, then, imme- 1695 diately following, seconds 20 to 25, and finally seconds 30 through 1696 the end. 1698 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1699 CSeq: 835 1700 Session: 12345678 1701 Range: npt=10-15, npt=20-25, npt=30- 1703 See the description of the PAUSE request for further examples. 1705 A PLAY request without a Range header is legal. It starts playing a 1706 stream from the beginning unless the stream has been paused. If a 1707 stream has been paused via PAUSE, stream delivery resumes at the 1708 pause point. 1710 The Range header MUST NOT contain a time parameter. The usage of time | 1711 has been deprecated. 1713 Server MUST include a "Range" header in any PLAY response. The | 1714 response MUST use the same format as the request's range header con- | 1715 tained. If no Range header was in the request, the NPT time format | 1716 SHOULD be used unless the client showed support for other formats. | 1717 For a session with live media streams the Range header MUST also be | 1718 given, containing a valid time indication. It is RECOMMENDED that | 1719 either "npt=now-" or a absolute time value (clock) for the corre- | 1720 sponding time is given, i.e. "clock=20030213T143205Z-". The UTC | 1721 clock format SHOULD only be used if client has shown support for it. 1723 For a on-demand stream, the server MUST reply with the actual range 1724 that will be played back. This may differ from the requested range if 1725 alignment of the requested range to valid frame boundaries is 1726 required for the media source. If no range is specified in the 1727 request, the start position SHALL still be returned in the reply. The 1728 unit of the range in the reply is the same as that in the request. If 1729 the medias part of an aggregate has different lengths the PLAY 1730 request and any Range SHALL be performed as long it is valid for the 1731 longest media. Media will be sent whenever it is available for the 1732 given play-out point. 1734 After playing the desired range, the presentation is NOT automati- 1735 cally paused, media deliver simply stops. A PAUSE request MUST be 1736 issued before another PLAY request can issued. Note: This is one 1737 change resulting in a non-operability with RFC 2326 implementations. 1738 A client not issuing a PAUSE request before a new PLAY will be stuck 1739 in PLAYING state. A client desiring to play the media from the begin- 1740 ning MUST send a PLAY request with a Range header pointing at the 1741 beginning, e.g. npt=0-. 1743 The following example plays the whole presentation starting at SMPTE 1744 time code 0:10:20 until the end of the clip. The playback is to start 1745 at 15:36 on 23 Jan 1997. Note: The RTP-Info headers has been broken 1746 into several lines to fit the page. 1748 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 1749 CSeq: 833 1750 Session: 12345678 1751 Range: smpte=0:10:20-;time=19970123T153600Z 1753 S->C: RTSP/1.0 200 OK 1754 CSeq: 833 1755 Date: 23 Jan 1997 15:35:06 GMT 1756 Server: PhonyServer 1.0 1757 Range: smpte=0:10:22-;time=19970123T153600Z 1758 RTP-Info:url=rtsp://example.com/twister.en; 1759 seq=14783;rtptime=2345962545 1761 For playing back a recording of a live presentation, it may be desir- 1762 able to use clock units: 1764 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 1765 CSeq: 835 1766 Session: 12345678 1767 Range: clock=19961108T142300Z-19961108T143520Z 1769 S->C: RTSP/1.0 200 OK 1770 CSeq: 835 1771 Date: 23 Jan 1997 15:35:06 GMT 1772 Server:PhonyServer 1.0 1773 Range: clock=19961108T142300Z-19961108T143520Z 1774 RTP-Info:url=rtsp://example.com/meeting.en; 1775 seq=53745;rtptime=484589019 1777 A media server only supporting playback MUST support the npt format 1778 and MAY support the clock and smpte formats. 1780 All range specifiers in this specification allow for ranges with 1781 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 1782 request, the server treats this as a request to start/resume playback 1783 from the current pause point, ending at the end time specified in the 1784 Range header. If the pause point is located later than the given end 1785 value, a 457 (Invalid Range) response SHALL be given. 1787 The queued play functionality described in RFC 2326 [21] is removed 1788 and multiple ranges can be used to achieve a similar performance. If 1789 a server receives a PLAY request while in the PLAY state, the server 1790 SHALL responde using the error code 455 (Method Not Valid In This 1791 State). This will signal the client that queued play are not sup- 1792 ported. 1794 The use of PLAY for keep-alive signaling, i.e. PLAY request without a 1795 range header, has also been depreciated. Instead a client can use, 1796 PING, SET_PARAMETER or OPTIONS for keep alive. A server receiving a 1797 PLAY keep alive SHALL respond with the 455 error code. 1799 When playing live media, indicated by the Accept-Ranges header the | 1800 session are in a live state. This live state will put some restric- | 1801 tions on the action available for a client. A PLAY request without a | 1802 Range header will start media deliver at the current point in the | 1803 live presentation, i.e. now. Any seeking in the media will be impos- | 1804 sible. The only allowed usage of the Range header is npt=now-, and | 1805 certain clock units. The usage of npt=now- is unnecessary as it has | 1806 the exact same meaning as a request without Range header. The clock | 1807 format can be used to specify start and stop times for media delivery | 1808 in a live session. 1810 11.5 PAUSE 1812 The PAUSE request causes the stream delivery to be interrupted | 1813 (halted) temporarily. A PAUSE request MUST be done with the aggre- | 1814 gated control URI for aggregated sessions, resulting in all media | 1815 being halted, or the media URI for non-aggregated sessions. Any | 1816 attempt to do muting of a single media with an PAUSE request in an | 1817 aggregated session SHALL be responded with error 460 (Only Aggregate | 1818 Operation Allowed). After resuming playback, synchronization of the | 1819 tracks MUST be maintained. Any server resources are kept, though | 1820 servers MAY close the session and free resources after being paused | 1821 for the duration specified with the timeout parameter of the Session | 1822 header in the SETUP message. 1824 Example: 1826 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1827 CSeq: 834 1828 Session: 12345678 1830 S->C: RTSP/1.0 200 OK 1831 CSeq: 834 1832 Date: 23 Jan 1997 15:35:06 GMT 1833 Range: npt=45.76 1835 The PAUSE request may contain a Range header specifying when the 1836 stream or presentation is to be halted. We refer to this point as the 1837 "pause point". The time parameter in the Range MUST NOT be used. | 1838 The header MUST contain a single value, expressed as the beginning 1839 value an open range. For example, the following clip will be played 1840 from 10 seconds through 21 seconds of the clip's normal play time, 1841 under the assumption that the PAUSE request reaches the server within 1842 11 seconds of the PLAY request. Note that some lines has been broken 1843 in an non-correct way to fit the page: 1845 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 1846 CSeq: 834 1847 Session: 12345678 1848 Range: npt=10-30 1850 S->C: RTSP/1.0 200 OK 1851 CSeq: 834 1852 Date: 23 Jan 1997 15:35:06 GMT 1853 Server: PhonyServer 1.0 1854 Range: npt=10-30 1855 RTP-Info:url=rtsp://example.com/fizzle/audiotrack; 1856 seq=5712;rtptime=934207921, 1857 url=rtsp://example.com/fizzle/videotrack; 1858 seq=57654;rtptime=2792482193 1859 Session: 12345678 1861 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1862 CSeq: 835 1863 Session: 12345678 1864 Range: npt=21- 1866 S->C: RTSP/1.0 200 OK 1867 CSeq: 835 1868 Date: 23 Jan 1997 15:35:09 GMT 1869 Server: PhonyServer 1.0 1870 Range: npt=21- 1871 Session: 12345678 1873 The pause request becomes effective the first time the server is | 1874 encountering the time point specified in any of the multiple ranges. | 1875 If the Range header specifies a time outside any range from the PLAY | 1876 request, the error 457 (Invalid Range) SHALL be returned. If a media | 1877 unit (such as an audio or video frame) starts presentation at exactly | 1878 the pause point, it is not played. If the Range header is missing, | 1879 stream delivery is interrupted immediately on receipt of the message | 1880 and the pause point is set to the current normal play time. However, | 1881 the pause point in the media stream MUST be maintained. A subsequent | 1882 PLAY request without Range header resumes from the pause point and | 1883 play until media end. 1885 The actual pause point after any PAUSE request SHALL be returned to 1886 the client by adding a Range header with what remains unplayed of the 1887 PLAY request's ranges, i.e. including all the remaining ranges part 1888 of multiple range specification. If one desires to resume playing a 1889 ranged request, one simple included the Range header from the PAUSE 1890 response. 1892 For example, if the server have a play request for ranges 10 to 15 1893 and 20 to 29 pending and then receives a pause request for NPT 21, it 1894 would start playing the second range and stop at NPT 21. If the pause 1895 request is for NPT 12 and the server is playing at NPT 13 serving the 1896 first play request, the server stops immediately. If the pause 1897 request is for NPT 16, the server returns a 457 error message. To 1898 prevent that the second range is played and the server stops after 1899 completing the first range, a PAUSE request for 20 must be issued. 1901 As another example, if a server has received requests to play ranges 1902 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 1903 request for NPT=14 would take effect while the server plays the first 1904 range, with the second range effectively being ignored, assuming the 1905 PAUSE request arrives before the server has started playing the sec- 1906 ond, overlapping range. Regardless of when the PAUSE request arrives, 1907 it sets the pause point to 14. 1909 If the server has already sent data beyond the time specified in the 1910 the PAUSE request Range header, a PLAY without range would still 1911 resume at that point in time, specified by the PAUSE request's Range 1912 header, as it is assumed that the client has discarded data after 1913 that point. This ensures continuous pause/play cycling without gaps. 1915 If a client issues a PAUSE request and the server acknowledges and 1916 enters the ready state, the proper server response, if the player 1917 issues another PAUSE, is 200 OK. The 200 OK response MUST include the 1918 Range header with the current pause point, even if the PAUSE request 1919 is asking for some other pause point. See examples below: 1921 Examples: 1923 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1924 CSeq: 834 1925 Session: 12345678 1927 S->C: RTSP/1.0 200 OK 1928 CSeq: 834 1929 Session: 12345678 1930 Date: 23 Jan 1997 15:35:06 GMT 1931 Range: npt=45.76- 1933 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1934 CSeq: 835 1935 Session: 12345678 1936 Range: 86- 1938 S->C: RTSP/1.0 200 OK 1939 CSeq: 835 1940 Session: 12345678 1941 Date: 23 Jan 1997 15:35:07 GMT 1942 Range: npt=45.76- 1944 11.6 TEARDOWN 1946 The TEARDOWN request stops the stream delivery for the given URI, 1947 freeing the resources associated with it. If the URI is the aggre- 1948 gated control URI for this presentation, any RTSP session identifier 1949 associated with the session is no longer valid. The use of "*" as URI 1950 in TEARDOWN will also result in that the session is removed indepen- 1951 dent of the number of medias that was part of it. If the URI in the 1952 request was for a media within an aggregated session that media is 1953 removed from the aggregate. However the session and any other media 1954 stream yet not torn down remains, and any valid request, e.g. PLAY or 1955 SETUP, can be issued. As an optional feature a server MAY keep the 1956 session in case the last remaining media is torn down with a TEARDOWN 1957 request with an URI equal to the media URI. To Indicate what has been 1958 performed, a server that after any TEARDOWN request, still has a 1959 valid session MUST in the response return a session header. 1961 A server MAY choose to allow TEARDOWN of individual media while in 1962 PLAY state. When this is not allowed the response SHALL be 455 1963 (Method Not Valid In This State). If a server implements TEARDOWN and 1964 SETUP in PLAY state it MUST signal this using the "setup.playing" 1965 feature-tag. 1967 Example: 1969 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 1970 CSeq: 892 1971 Session: 12345678 1973 S->C: RTSP/1.0 200 OK 1974 CSeq: 892 1975 Server: PhonyServer 1.0 1977 11.7 GET_PARAMETER 1979 The GET_PARAMETER request retrieves the value of a parameter of a 1980 presentation or stream specified in the URI. If the Session header is 1981 present in a request, the value of a parameter MUST be retrieved in 1982 the sessions context. The content of the reply and response is left 1983 to the implementation. GET_PARAMETER with no entity body may be used 1984 to test client or server liveness ("ping"). 1986 Example: 1988 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1989 CSeq: 431 1990 Content-Type: text/parameters 1991 Session: 12345678 1992 Content-Length: 15 1994 packets_received 1995 jitter 1997 C->S: RTSP/1.0 200 OK 1998 CSeq: 431 1999 Content-Length: 46 2000 Content-Type: text/parameters 2002 packets_received: 10 2003 jitter: 0.3838 2005 The "text/parameters" section is only an example type for 2006 parameter. This method is intentionally loosely defined with 2007 the intention that the reply content and response content will 2008 be defined after further experimentation. 2010 11.8 SET_PARAMETER 2012 This method requests to set the value of a parameter for a presenta- 2013 tion or stream specified by the URI. 2015 A request is RECOMMENDED to only contain a single parameter to allow 2016 the client to determine why a particular request failed. If the 2017 request contains several parameters, the server MUST only act on the 2018 request if all of the parameters can be set successfully. A server 2019 MUST allow a parameter to be set repeatedly to the same value, but it 2020 MAY disallow changing parameter values. If the receiver of the 2021 request does not understand or can locate a parameter error 451 2022 (Parameter Not Understood) SHALL be used. In the case a parameter is 2023 not allowed to change the error code 458 (Parameter Is Read-Only). 2024 The response body SHOULD contain only the parameters that has errors. 2025 Otherwise no body SHALL be returned. 2027 Note: transport parameters for the media stream MUST only be set with 2028 the SETUP command. 2030 Restricting setting transport parameters to SETUP is for the 2031 benefit of firewalls. 2033 The parameters are split in a fine-grained fashion so that 2034 there can be more meaningful error indications. However, it 2035 may make sense to allow the setting of several parameters if 2036 an atomic setting is desirable. Imagine device control where 2037 the client does not want the camera to pan unless it can also 2038 tilt to the right angle at the same time. 2040 Example: 2042 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 2043 CSeq: 421 2044 Content-length: 20 2045 Content-type: text/parameters 2047 barparam: barstuff 2049 S->C: RTSP/1.0 451 Parameter Not Understood 2050 CSeq: 421 2051 Content-length: 10 2052 Content-type: text/parameters 2053 barparam 2055 The "text/parameters" section is only an example type for 2056 parameter. This method is intentionally loosely defined with 2057 the intention that the reply content and response content will 2058 be defined after further experimentation. 2060 11.9 REDIRECT 2062 A redirect request informs the client that it MUST connect to another | 2063 server location. The REDIRECT request MAY contain the header Loca- | 2064 tion, which indicates that the client should issue requests for that | 2065 URL. If the Location URL only contains a host address the client | 2066 shall connect to the given host, while using the path from the URL on | 2067 the current server. | 2069 If a REDIRECT request contains a Session header, it is end-to-end and | 2070 applies only to the given session. If there are proxies in the | 2071 request chain, they SHOULD NOT disconnect the control channel unless | 2072 there are no remaining sessions. | 2074 If a REDIRECT request does not contain a Session header, it is next- | 2075 hop and applies to the control connection. The Location header SHOULD | 2076 only contain a host address. If there are proxies in the request | 2077 chain, they SHOULD do all of the following: (1) respond to the REDI- | 2078 RECT request, (2) disconnect the control channel from the requestor, | 2079 (3) reconnect to the given host address, and (4) pass the request to | 2080 each applicable client (typically those clients with an active ses- | 2081 sion or unanswered request from the requestor). Note that the proxy | 2082 is responsible for accepting the REDIRECT response from its clients | 2083 and these responses MUST NOT be passed on to either the requesting or | 2084 the destination server. 2086 The redirect request MAY contain the header Range, which indicates 2087 when the redirection takes effect. If the Range contains a "time=" 2088 value that is the wall clock time that the redirection MUST at the 2089 latest take place. When the "time=" parameter is present the range 2090 value MUST be ignored. However the range entered MUST be syntactical 2091 correct and SHALL point at the beginning of any on-demand content. If 2092 no time parameter is part of the Range header then redirection SHALL 2093 take place when the media playout from the server reaches the given 2094 time. The range value MUST be a single value in the open ended form, 2095 e.g. npt=59-. 2097 If the client wants to continue to send or receive media for this 2098 resource, the client MUST issue a TEARDOWN request for the current 2099 session. A new session must be established with the designated host. 2100 A client SHOULD issue a new DESCRIBE request with the URL given in 2101 the Location header, unless the URL only contains a host address. In 2102 the cases the Location only contains a host address the client MAY 2103 assume that the media on the server it is redirected to is identical. 2104 Identical media means that all media configuration information from 2105 the old session still is valid except for the host address. In the 2106 case of absolute URLs in the location header the media redirected to 2107 can be either identical, slightly different or totally different. 2108 This is the reason why a new DESCRIBE request SHOULD be issued. 2110 This example request redirects traffic for this session to the new 2111 server at the given absolute time: 2113 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 2114 CSeq: 732 2115 Location: rtsp://bigserver.com:8001 2116 Range: npt=0- ;time=19960213T143205Z 2117 Session: uZ3ci0K+Ld-M 2119 11.10 PING 2121 This method is a bi-directional mechanism for server or client live- 2122 ness checking. It has no side effects. The issuer of the request MUST 2123 include a session header with the session ID of the session that is 2124 being checked for liveness. 2126 Prior to using this method, an OPTIONS method is RECOMMENDED to be 2127 issued in the direction which the PING method would be used. This 2128 method MUST NOT be used if support is not indicated by the Public 2129 header. Note: That an 501 (Not Implemented) response means that the 2130 keep-alive timer has not been updated. 2132 When a proxy is in use, PING with a * indicates a single-hop liveness 2133 check, whereas PING with a URL including an host address indicates an 2134 end-to-end liveness check. 2136 Example: 2138 C->S: PING * RTSP/1.0 2139 CSeq: 123 2140 Session:12345678 2142 S->C: RTSP/1.0 200 OK 2143 CSeq: 123 2144 Session:12345678 2146 11.11 Embedded (Interleaved) Binary Data 2148 Certain firewall designs and other circumstances may force a server 2149 to interleave RTSP messages and media stream data. This interleaving 2150 should generally be avoided unless necessary since it complicates 2151 client and server operation and imposes additional overhead. Also 2152 head of line blocking may cause problems. Interleaved binary data 2153 SHOULD only be used if RTSP is carried over TCP. 2155 Stream data such as RTP packets is encapsulated by an ASCII dollar 2156 sign (24 decimal), followed by a one-byte channel identifier, fol- 2157 lowed by the length of the encapsulated binary data as a binary, two- 2158 byte integer in network byte order. The stream data follows immedi- 2159 ately afterwards, without a CRLF, but including the upper-layer pro- 2160 tocol headers. Each $ block contains exactly one upper-layer protocol 2161 data unit, e.g., one RTP packet. 2163 0 1 2 3 2164 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 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | "$" = 24 | Channel ID | Length in bytes | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 : Length number of bytes of binary data : 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 The channel identifier is defined in the Transport header with the 2172 interleaved parameter(Section 13.40). 2174 When the transport choice is RTP, RTCP messages are also interleaved 2175 by the server over the TCP connection. The usage of RTCP messages is 2176 indicated by including a range containing a second channel in the 2177 interleaved parameter of the Transport header, see section 13.40. If 2178 RTCP is used, packets SHALL be sent on the first available channel 2179 higher than the RTP channel. The channels are bi-directional and 2180 therefore RTCP traffic are sent on the second channel in both direc- 2181 tions. 2183 RTCP is needed for synchronization when two or more streams 2184 are interleaved in such a fashion. Also, this provides a con- 2185 venient way to tunnel RTP/RTCP packets through the TCP control 2186 connection when required by the network configuration and 2187 transfer them onto UDP when possible. 2189 C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 2190 CSeq: 2 2191 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 2193 S->C: RTSP/1.0 200 OK 2194 CSeq: 2 2195 Date: 05 Jun 1997 18:57:18 GMT 2196 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 2197 Session: 12345678 2199 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 2200 CSeq: 3 2201 Session: 12345678 2203 S->C: RTSP/1.0 200 OK 2204 CSeq: 3 2205 Session: 12345678 2206 Date: 05 Jun 1997 18:59:15 GMT 2207 RTP-Info: url=rtsp://foo.com/bar.file; 2208 seq=232433;rtptime=972948234 2210 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2211 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2212 S->C: $006{2 byte length}{"length" bytes RTCP packet} 2214 12 Status Code Definitions 2216 Where applicable, HTTP status [H10] codes are reused. Status codes 2217 that have the same meaning are not repeated here. See Table 1 for a 2218 listing of which status codes may be returned by which requests. All 2219 error messages, 4xx and 5xx MAY return a body containing further 2220 information about the error. 2222 12.1 Success 1xx 2224 12.1.1 100 Continue 2226 See, [H10.1.1]. 2228 12.2 Success 2xx 2230 12.2.1 250 Low on Storage Space 2232 The server returns this warning after receiving a RECORD request that 2233 it may not be able to fulfill completely due to insufficient storage 2234 space. If possible, the server should use the Range header to indi- 2235 cate what time period it may still be able to record. Since other 2236 processes on the server may be consuming storage space simultane- 2237 ously, a client should take this only as an estimate. 2239 12.3 Redirection 3xx 2241 The notation "3rr" indicates response codes from 300 to 399 inclusive 2242 which are meant for redirection. The response code 304 is excluded 2243 from this set, as it is not used for redirection. 2245 See [H10.3] for definition of status code 300 to 305. However com- 2246 ments are given for some to how they apply to RTSP. 2248 Within RTSP, redirection may be used for load balancing or redirect- 2249 ing stream requests to a server topologically closer to the client. 2250 Mechanisms to determine topological proximity are beyond the scope of 2251 this specification. 2253 12.3.1 300 Multiple Choices 2255 12.3.2 301 Moved Permanently 2257 The request resource are moved permanently and resides now at the URI 2258 given by the location header. The user client SHOULD redirect auto- 2259 matically to the given URI. This response MUST NOT contain a message- 2260 body. 2262 12.3.3 302 Found 2264 The requested resource reside temporarily at the URI given by the 2265 Location header. The Location header MUST be included in the 2266 response. Is intended to be used for many types of temporary redi- 2267 rects, e.g. load balancing. It is RECOMMENDED that one set the reason 2268 phrase to something more meaningful than "Found" in these cases. The 2269 user client SHOULD redirect automatically to the given URI. This 2270 response MUST NOT contain a message-body. 2272 12.3.4 303 See Other 2274 This status code SHALL NOT be used in RTSP. However as it was allowed 2275 to use in RFC 2326 it is possible that such response may be received. 2277 12.3.5 304 Not Modified 2279 If the client has performed a conditional DESCRIBE or SETUP (see 2280 12.23) and the requested resource has not been modified, the server 2281 SHOULD send a 304 response. This response MUST NOT contain a message- 2282 body. 2284 The response MUST include the following header fields: 2286 + Date 2288 + ETag and/or Content-Location, if the header would have been sent 2289 in a 200 response to the same request. 2291 + Expires, Cache-Control, and/or Vary, if the field-value might 2292 differ from that sent in any previous response for the same vari- 2293 ant. 2295 This response is independent for the DESCRIBE and SETUP requests. 2296 That is, a 304 response to DESCRIBE does NOT imply that the resource 2297 content is unchanged and a 304 response to SETUP does NOT imply that 2298 the resource description is unchanged. The ETag and If-Match headers 2299 may be used to link the DESCRIBE and SETUP in this manner. 2301 12.3.6 305 Use Proxy 2303 See [H10.3.6]. 2305 12.4 Client Error 4xx 2307 12.4.1 400 Bad Request 2309 The request could not be understood by the server due to malformed 2310 syntax. The client SHOULD NOT repeat the request without modifica- 2311 tions [H10.4.1]. If the request does not have a CSeq header, the 2312 server MUST NOT include a CSeq in the response. 2314 12.4.2 405 Method Not Allowed 2316 The method specified in the request is not allowed for the resource 2317 identified by the request URI. The response MUST include an Allow 2318 header containing a list of valid methods for the requested resource. 2319 This status code is also to be used if a request attempts to use a 2320 method not indicated during SETUP, e.g., if a RECORD request is 2321 issued even though the mode parameter in the Transport header only 2322 specified PLAY. 2324 12.4.3 451 Parameter Not Understood 2326 The recipient of the request does not support one or more parameters 2327 contained in the request.When returning this error message the sender 2328 SHOULD return a entity body containing the offending parameter(s). 2330 12.4.4 452 reserved 2332 This error code was removed from RFC 2326 [21] and is obsolete. 2334 12.4.5 453 Not Enough Bandwidth 2336 The request was refused because there was insufficient bandwidth. 2337 This may, for example, be the result of a resource reservation fail- 2338 ure. 2340 12.4.6 454 Session Not Found 2342 The RTSP session identifier in the Session header is missing, 2343 invalid, or has timed out. 2345 12.4.7 455 Method Not Valid in This State 2347 The client or server cannot process this request in its current 2348 state. The response SHOULD contain an Allow header to make error 2349 recovery easier. 2351 12.4.8 456 Header Field Not Valid for Resource 2353 The server could not act on a required request header. For example, 2354 if PLAY contains the Range header field but the stream does not allow 2355 seeking. This error message may also be used for specifying when the 2356 time format in Range is impossible for the resource. In that case the 2357 Accept-Ranges header SHOULD be returned to inform the client of which 2358 format(s) that are allowed. 2360 12.4.9 457 Invalid Range 2362 The Range value given is out of bounds, e.g., beyond the end of the 2363 presentation. 2365 12.4.10 458 Parameter Is Read-Only 2367 The parameter to be set by SET_PARAMETER can be read but not modi- 2368 fied. When returning this error message the sender SHOULD return a 2369 entity body containing the offending parameter(s). 2371 12.4.11 459 Aggregate Operation Not Allowed 2373 The requested method may not be applied on the URL in question since 2374 it is an aggregate (presentation) URL. The method may be applied on a 2375 media URL. 2377 12.4.12 460 Only Aggregate Operation Allowed 2379 The requested method may not be applied on the URL in question since 2380 it is not an aggregate control (presentation) URL. The method may be 2381 applied on the aggregate control URL. 2383 12.4.13 461 Unsupported Transport 2385 The Transport field did not contain a supported transport specifica- 2386 tion. 2388 12.4.14 462 Destination Unreachable 2390 The data transmission channel could not be established because the 2391 client address could not be reached. This error will most likely be 2392 the result of a client attempt to place an invalid Destination param- 2393 eter in the Transport field. 2395 12.5 Server Error 5xx 2397 12.5.1 551 Option not supported 2399 An feature-tag given in the Require or the Proxy-Require fields was 2400 not supported. The Unsupported header SHOULD be returned stating the 2401 feature for which there is no support. 2403 13 Header Field Definitions 2405 The general syntax for header fields is covered in Section 4.2 This 2406 section lists the full set of header fields along with notes on syn- 2407 tax, meaning, and usage. Throughout this section, we use [HX.Y] to 2408 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 2409 [26]. Examples of each header field are given. 2411 Information about header fields in relation to methods and proxy pro- 2412 cessing is summarized in Table 4 and Table 5. 2414 The "where" column describes the request and response types in which 2415 the header field can be used. Values in this column are: 2417 method direction object acronym Body 2418 ----------------------------------------------- 2419 DESCRIBE C->S P,S DES r 2420 GET_PARAMETER C->S, S->C P,S GPR R,r 2421 OPTIONS C->S P,S OPT 2422 S->C 2423 PAUSE C->S P,S PSE 2424 PING C->S, S->C P,S PNG 2425 PLAY C->S P,S PLY 2426 REDIRECT S->C P,S RDR 2427 SETUP C->S S STP 2428 SET_PARAMETER C->S, S->C P,S SPR R,r 2429 TEARDOWN C->S P,S TRD 2431 Table 3: Overview of RTSP methods, their direction, and what objects 2432 (P: presentation, S: stream) they operate on. Body notes if a method 2433 is allowed to carry body and in which direction, R = Request, 2434 r=response. Note: It is allowed for all error messages 4xx and 5xx to 2435 have a body 2437 R: header field may only appear in requests; 2439 r: header field may only appear in responses; 2441 2xx, 4xx, etc.: A numerical value or range indicates response codes 2442 with which the header field can be used; 2444 c: header field is copied from the request to the response. 2446 An empty entry in the "where" column indicates that the header field 2447 may be present in all requests and responses. 2449 The "proxy" column describes the operations a proxy may perform on a 2450 header field: 2452 a: A proxy can add or concatenate the header field if not present. 2454 m: A proxy can modify an existing header field value. 2456 d: A proxy can delete a header field value. 2458 r: A proxy must be able to read the header field, and thus this 2459 header field cannot be encrypted. 2461 The rest of the columns relate to the presence of a header field in a 2462 method. The method names when abbreviated, are according to table 3: 2464 c: Conditional; requirements on the header field depend on the con- 2465 text of the message. 2467 m: The header field is mandatory. 2469 m*: The header field SHOULD be sent, but clients/servers need to be 2470 prepared to receive messages without that header field. 2472 o: The header field is optional. 2474 *: The header field is required if the message body is not empty. 2475 See sections 13.14, 13.16 and 4.3 for details. 2477 -: The header field is not applicable. 2479 "Optional" means that a Client/Server MAY include the header field in 2480 a request or response, and a Client/Server MAY ignore the header 2481 field if present in the request or response (The exception to this 2482 rule is the Require header field discussed in 13.32). A "mandatory" 2483 header field MUST be present in a request, and MUST be understood by 2484 the Client/Server receiving the request. A mandatory response header 2485 field MUST be present in the response, and the header field MUST be 2486 understood by the Client/Server processing the response. "Not appli- 2487 cable" means that the header field MUST NOT be present in a request. 2488 If one is placed in a request by mistake, it MUST be ignored by the 2489 Client/Server receiving the request. Similarly, a header field 2490 labeled "not applicable" for a response means that the Client/Server 2491 MUST NOT place the header field in the response, and the 2492 Client/Server MUST ignore the header field in the response. 2494 A Client/Server SHOULD ignore extension header parameters that are 2495 not understood. 2497 The From, Location, and RTP-Info header fields contain a URI. If the 2498 URI contains a comma, or semicolon, the URI MUST be enclosed in dou- 2499 ble quotas ("). Any URI parameters are contained within these quotas. 2500 If the URI is not enclosed in double quotas, any semicolon- delimited 2501 parameters are header-parameters, not URI parameters. 2503 13.1 Accept 2505 The Accept request-header field can be used to specify certain pre- 2506 sentation description content types which are acceptable for the 2507 response. 2509 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 2510 -------------------------------------------------------------- 2511 Accept R o - - - - - 2512 Accept-Encoding R r o - - - - - 2513 Accept-Language R r o - - - - - 2514 Accept-Ranges r r - - o - - - 2515 Accept-Ranges 456 r - - - o o - 2516 Allow r - o - - - - 2517 Allow 405 - - - m m - 2518 Authorization R o o o o o o 2519 Bandwidth R o o o o - - 2520 Blocksize R o - o o - - 2521 Cache-Control r - - o - - - 2522 Connection o o o o o o 2523 Content-Base r o - - - - - 2524 Content-Base 4xx o o o o o o 2525 Content-Encoding R r - - - - - - 2526 Content-Encoding r r o - - - - - 2527 Content-Encoding 4xx r o o o o o o 2528 Content-Language R r - - - - - - 2529 Content-Language r r o - - - - - 2530 Content-Language 4xx r o o o o o o 2531 Content-Length r r * - - - - - 2532 Content-Length 4xx r * * * * * * 2533 Content-Location r o - - - - - 2534 Content-Location 4xx o o o o o o 2535 Content-Type r * - - - - - 2536 Content-Type 4xx * * * * * * 2537 CSeq Rc m m m m m m 2538 Date am o o o o o o 2539 Expires r r o - - - - - 2540 From R r o o o o o o 2541 Host o o o o o o 2542 If-Match R r - - o - - - 2543 If-Modified-Since R r o - o - - - 2544 Last-Modified r r o - - - - - 2545 Location 3rr o o o o o o 2546 Proxy-Authenticate 407 amr m m m m m m 2547 Proxy-Require R ar o o o o o o 2548 Public r admr - m* - - - - 2549 Public 501 admr m* m* m* m* m* m* 2550 Range R - - - o o - 2551 Range r - - c m* m* - 2552 Referer R o o o o o o 2553 Require R o o o o o o 2554 Retry-After 3rr,503 o o o - - - 2555 RTP-Info r - - o m - - 2556 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 2557 ---------------------------------------------------------- 2558 Scale - - - o - - 2559 Session R - o o m m m 2560 Session r - c m m m o 2561 Server R - o - - - - 2562 Server r o o o o o o 2563 Speed - - - o - - 2564 Supported R o o o o o o 2565 Supported r c c c c c c 2566 Timestamp R o o o o o o 2567 Timestamp c m m m m m m 2568 Transport - - m - - - 2569 Unsupported r c c c c c c 2570 User-Agent R m* m* m* m* m* m* 2571 Vary r c c c c c c 2572 Via R amr o o o o o o 2573 Via c dr m m m m m m 2574 WWW-Authenticate 401 m m m m m m 2575 ---------------------------------------------------------- 2576 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 2578 Table 4: Overview of RTSP header fields related to methods DESCRIBE, 2579 OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 2581 The "level" parameter for presentation descriptions is prop- 2582 erly defined as part of the MIME type registration, not here. 2584 See [H14.1] for syntax. 2586 Example of use: 2588 Accept: application/rtsl q=1.0, application/sdp;level=2 2590 Header Where Proxy GPR SPR RDR PNG 2591 ----------------------------------------------------- 2592 Allow 405 - - - - 2593 Authorization R o o o o 2594 Bandwidth R - o - - 2595 Blocksize R - o - - 2596 Connection o o o - 2597 Content-Base R o o - - 2598 Content-Base r o o - - 2599 Content-Base 4xx o o o - 2600 Content-Encoding R r o o - - 2601 Content-Encoding r r o o - - 2602 Content-Encoding 4xx r o o o - 2603 Content-Language R r o o - - 2604 Content-Language r r o o - - 2605 Content-Language 4xx r o o o - 2606 Content-Length R r * * - - 2607 Content-Length r r * * - - 2608 Content-Length 4xx r * * * - 2609 Content-Location R o o - - 2610 Content-Location r o o - - 2611 Content-Location 4xx o o o - 2612 Content-Type R * * - - 2613 Content-Type r * * - - 2614 Content-Type 4xx * * * - 2615 CSeq Rc m m m m 2616 Date am o o o o 2617 From R r o o o o 2618 Host o o o o 2619 Last-Modified R r - - - - 2620 Last-Modified r r o - - - 2621 Location 3rr o o o o 2622 Location R - - m - 2623 Proxy-Authenticate 407 amr m m m m 2624 Proxy-Require R ar o o o o 2625 Public 501 admr m* m* m* m* 2626 Range R - - o - 2627 Referer R o o o - 2628 Require R o o o o 2629 Retry-After 3rr,503 o o - - 2630 Scale - - - - 2631 Session R o o o m 2632 Session r c c o m 2633 Server R o o o o 2634 Server r o o - o 2635 Supported R o o o o 2636 Supported r c c c c 2637 Timestamp R o o o o 2638 Timestamp c m m m m 2639 Unsupported r c c c c 2640 User-Agent R m* m* - m* 2641 User-Agent r - - m* - 2642 Vary r c c - - 2643 Via R amr o o o o 2644 Via c dr m m m m 2645 WWW-Authenticate 401 m m m m 2646 ----------------------------------------------------- 2647 Header Where Proxy GPR SPR RDR PNG 2649 Table 5: Overview of RTSP header fields related to methods GET_PARAM- 2650 ETER, SET_PARAMETER,REDIRECT, and PING. 2652 13.2 Accept-Encoding 2654 See [H14.3] 2656 13.3 Accept-Language 2658 See [H14.4]. Note that the language specified applies to the presen- 2659 tation description and any reason phrases, not the media content. 2661 13.4 Accept-Ranges 2663 The Accept-Ranges response-header field allows the server to indicate 2664 its acceptance of range requests and possible formats for a resource: | 2666 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges || 2667 acceptable-ranges = 1#range-unit / "none" || 2668 range-unit = NPT / SMPTE / UTC / LIVE / extension-format || 2669 extension-format = token || 2671 This header has the same syntax as [H14.5]. However new range-units 2672 are defined and byte-ranges SHALL NOT be used. Inclusion of any of 2673 the three time formats indicates acceptance by the server for PLAY 2674 and PAUSE requests with this format. Inclusion of the "LIVE" tag 2675 indicates that the resource has LIVE properties. The headers value is 2676 valid for the resource specified by the URI in the request, this 2677 response corresponds to. 2679 A server is RECOMMENDED to use this header in SETUP responses to 2680 indicate to the client which range time formats the media supports. 2681 The header SHOULD also be included in "456" responses which is a 2682 result of use of unsupported range formats. 2684 13.5 Allow 2686 The Allow entity-header field lists the methods supported by the 2687 resource identified by the request-URI. The purpose of this field is 2688 to strictly inform the recipient of valid methods associated with the 2689 resource. An Allow header field MUST be present in a 405 (Method Not 2690 Allowed) response. See [H14.7] for syntax definition. 2692 Example of use: 2694 Allow: SETUP, PLAY, SET_PARAMETER 2696 13.6 Authorization 2698 See [H14.8] 2700 13.7 Bandwidth 2702 The Bandwidth request-header field describes the estimated bandwidth 2703 available to the client, expressed as a positive integer and measured 2704 in bits per second. The bandwidth available to the client may change 2705 during an RTSP session, e.g., due to modem retraining. 2707 Bandwidth = "Bandwidth" ":" 1*DIGIT 2709 Example: 2711 Bandwidth: 4000 2713 13.8 Blocksize 2715 The Blocksize request-header field is sent from the client to the 2716 media server asking the server for a particular media packet size. 2717 This packet size does not include lower-layer headers such as IP, 2718 UDP, or RTP. The server is free to use a blocksize which is lower 2719 than the one requested. The server MAY truncate this packet size to 2720 the closest multiple of the minimum, media-specific block size, or 2721 override it with the media-specific size if necessary. The block size 2722 MUST be a positive decimal number, measured in octets. The server 2723 only returns an error 2725 (400) if the value is syntactically invalid. 2727 Blocksize = "Blocksize" ":" 1*DIGIT 2729 13.9 Cache-Control 2731 The Cache-Control general-header field is used to specify directives 2732 that MUST be obeyed by all caching mechanisms along the 2733 request/response chain. 2735 Cache directives must be passed through by a proxy or gateway appli- 2736 cation, regardless of their significance to that application, since 2737 the directives may be applicable to all recipients along the 2738 request/response chain. It is not possible to specify a cache-direc- 2739 tive for a specific cache. 2741 Cache-Control should only be specified in a SETUP request and its 2742 response. Note: Cache-Control does not govern the caching of 2743 responses as for HTTP, but rather of the stream identified by the 2744 SETUP request. Responses to RTSP requests are not cacheable, except 2745 for responses to DESCRIBE. 2747 Cache-Control = "Cache-Control" ":" 1#cache-directive 2748 cache-directive = cache-request-directive 2749 / cache-response-directive 2750 cache-request-directive = "no-cache" 2751 / "max-stale" ["=" delta-seconds] 2752 / "min-fresh" "=" delta-seconds 2753 / "only-if-cached" 2754 / cache-extension 2755 cache-response-directive = "public" 2756 / "private" 2757 / "no-cache" 2758 / "no-transform" 2759 / "must-revalidate" 2760 / "proxy-revalidate" 2761 / "max-age" "=" delta-seconds 2762 / cache-extension 2763 cache-extension = token [ "=" ( token / quoted-string ) ] 2764 delta-seconds = 1*DIGIT 2765 no-cache: Indicates that the media stream MUST NOT be cached any- 2766 where. This allows an origin server to prevent caching even by 2767 caches that have been configured to return stale responses to 2768 client requests. 2770 public: Indicates that the media stream is cacheable by any cache. 2772 private: Indicates that the media stream is intended for a single 2773 user and MUST NOT be cached by a shared cache. A private (non- 2774 shared) cache may cache the media stream. 2776 no-transform: An intermediate cache (proxy) may find it useful to 2777 convert the media type of a certain stream. A proxy might, for 2778 example, convert between video formats to save cache space or 2779 to reduce the amount of traffic on a slow link. Serious opera- 2780 tional problems may occur, however, when these transformations 2781 have been applied to streams intended for certain kinds of 2782 applications. For example, applications for medical imaging, 2783 scientific data analysis and those using end-to-end authenti- 2784 cation all depend on receiving a stream that is bit-for-bit 2785 identical to the original entity-body. Therefore, if a 2786 response includes the no-transform directive, an intermediate 2787 cache or proxy MUST NOT change the encoding of the stream. 2788 Unlike HTTP, RTSP does not provide for partial transformation 2789 at this point, e.g., allowing translation into a different 2790 language. 2792 only-if-cached: In some cases, such as times of extremely poor net- 2793 work connectivity, a client may want a cache to return only 2794 those media streams that it currently has stored, and not to 2795 receive these from the origin server. To do this, the client 2796 may include the only-if-cached directive in a request. If it 2797 receives this directive, a cache SHOULD either respond using a 2798 cached media stream that is consistent with the other con- 2799 straints of the request, or respond with a 504 (Gateway Time- 2800 out) status. However, if a group of caches is being operated 2801 as a unified system with good internal connectivity, such a 2802 request MAY be forwarded within that group of caches. 2804 max-stale: Indicates that the client is willing to accept a media 2805 stream that has exceeded its expiration time. If max-stale is 2806 assigned a value, then the client is willing to accept a 2807 response that has exceeded its expiration time by no more than 2808 the specified number of seconds. If no value is assigned to 2809 max-stale, then the client is willing to accept a stale 2810 response of any age. 2812 min-fresh: Indicates that the client is willing to accept a media 2813 stream whose freshness lifetime is no less than its current 2814 age plus the specified time in seconds. That is, the client 2815 wants a response that will still be fresh for at least the 2816 specified number of seconds. 2818 must-revalidate: When the must-revalidate directive is present in a 2819 SETUP response received by a cache, that cache MUST NOT use 2820 the entry after it becomes stale to respond to a subsequent 2821 request without first revalidating it with the origin server. 2822 That is, the cache must do an end-to-end revalidation every 2823 time, if, based solely on the origin server's Expires, the 2824 cached response is stale.) 2826 proxy-revalidate: The proxy-revalidate directive has the same mean- 2827 ing as the must-revalidate directive, except that it does not 2828 apply to non-shared user agent caches. It can be used on a 2829 response to an authenticated request to permit the user's 2830 cache to store and later return the response without needing 2831 to revalidate it (since it has already been authenticated once 2832 by that user), while still requiring proxies that service many 2833 users to revalidate each time (in order to make sure that each 2834 user has been authenticated). Note that such authenticated 2835 responses also need the public cache control directive in 2836 order to allow them to be cached at all. 2838 max-age: When an intermediate cache is forced, by means of a max- 2839 age=0 directive, to revalidate its own cache entry, and the 2840 client has supplied its own validator in the request, the sup- 2841 plied validator might differ from the validator currently 2842 stored with the cache entry. In this case, the cache MAY use 2843 either validator in making its own request without affecting 2844 semantic transparency. 2846 However, the choice of validator might affect performance. The 2847 best approach is for the intermediate cache to use its own 2848 validator when making its request. If the server replies with 2849 304 (Not Modified), then the cache can return its now vali- 2850 dated copy to the client with a 200 (OK) response. If the 2851 server replies with a new entity and cache validator, however, 2852 the intermediate cache can compare the returned validator with 2853 the one provided in the client's request, using the strong 2854 comparison function. If the client's validator is equal to the 2855 origin server's, then the intermediate cache simply returns 2856 304 (Not Modified). Otherwise, it returns the new entity with 2857 a 200 (OK) response. 2859 13.10 Connection 2861 See [H14.10]. The use of the connection option "close" in RTSP mes- 2862 sages SHOULD be limited to error messages when the server is unable 2863 to recover and therefore see it necessary to close the connection. 2864 The reason is that the client shall have the choice of continue using 2865 a connection indefinitely as long as it sends valid messages. 2867 13.11 Content-Base 2869 The Content-Base entity-header field may be used to specify the base 2870 URI for resolving relative URLs within the entity. 2872 Content-Base = "Content-Base" ":" absoluteURI 2874 If no Content-Base field is present, the base URI of an entity is 2875 defined either by its Content-Location (if that Content-Location URI 2876 is an absolute URI) or the URI used to initiate the request, in that 2877 order of precedence. Note, however, that the base URI of the contents 2878 within the entity-body may be redefined within that entity-body. 2880 13.12 Content-Encoding 2882 See [H14.11] 2884 13.13 Content-Language 2886 See [H14.12] 2888 13.14 Content-Length 2890 The Content-Length general-header field contains the length of the 2891 content of the method (i.e. after the double CRLF following the last 2892 header). Unlike HTTP, it MUST be included in all messages that carry 2893 content beyond the header portion of the message. If it is missing, a 2894 default value of zero is assumed. It is interpreted according to 2895 [H14.13]. 2897 13.15 Content-Location 2899 See [H14.14] 2901 13.16 Content-Type 2903 See [H14.17]. Note that the content types suitable for RTSP are 2904 likely to be restricted in practice to presentation descriptions and 2905 parameter-value types. 2907 13.17 CSeq 2909 The CSeq general-header field specifies the sequence number for an 2910 RTSP request-response pair. This field MUST be present in all 2911 requests and responses. For every RTSP request containing the given 2912 sequence number, the corresponding response will have the same num- 2913 ber. Any retransmitted request must contain the same sequence number 2914 as the original (i.e. the sequence number is not incremented for 2915 retransmissions of the same request). For each new RTSP request the 2916 CSeq value SHALL be incremented by one. The initial sequence number 2917 MAY be any number. Each sequence number series is unique between each 2918 requester and responder, i.e. the client has one series for its 2919 request to a server and the server has another when sending request 2920 to the client. Each requester and responder is identified with its 2921 network address. 2923 CSeq = "Cseq" ":" 1*DIGIT 2925 13.18 Date 2927 See [H14.18]. An RTSP message containing a body MUST include a Date 2928 header if the sending host has a clock. Servers SHOULD include a Date 2929 header in all other RTSP messages. 2931 13.19 Expires 2933 The Expires entity-header field gives a date and time after which the 2934 description or media-stream should be considered stale. The interpre- 2935 tation depends on the method: 2937 DESCRIBE response: The Expires header indicates a date and time 2938 after which the description should be considered stale. 2940 A stale cache entry may not normally be returned by a cache (either a 2941 proxy cache or an user agent cache) unless it is first validated with 2942 the origin server (or with an intermediate cache that has a fresh 2943 copy of the entity). See section 14 for further discussion of the 2944 expiration model. 2946 The presence of an Expires field does not imply that the original 2947 resource will change or cease to exist at, before, or after that 2948 time. 2950 The format is an absolute date and time as defined by HTTP-date in 2951 [H3.3]; it MUST be in RFC1123-date format: 2953 Expires = "Expires" ":" HTTP-date 2955 An example of its use is 2957 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2959 RTSP/1.0 clients and caches MUST treat other invalid date formats, 2960 especially including the value "0", as having occurred in the past 2961 (i.e., already expired). 2963 To mark a response as "already expired," an origin server should use 2964 an Expires date that is equal to the Date header value. To mark a 2965 response as "never expires," an origin server SHOULD use an Expires 2966 date approximately one year from the time the response is sent. 2967 RTSP/1.0 servers SHOULD NOT send Expires dates more than one year in 2968 the future. 2970 The presence of an Expires header field with a date value of some 2971 time in the future on a media stream that otherwise would by default 2972 be non-cacheable indicates that the media stream is cacheable, unless 2973 indicated otherwise by a Cache-Control header field (Section 13.9). 2975 13.20 From 2977 See [H14.22]. 2979 13.21 Host 2981 The Host HTTP request header field [H14.23] is not needed for RTSP. 2982 It should be silently ignored if sent. 2984 13.22 If-Match 2986 See [H14.24]. 2988 The If-Match request-header field is especially useful for ensuring 2989 the integrity of the presentation description, in both the case where 2990 it is fetched via means external to RTSP (such as HTTP), or in the 2991 case where the server implementation is guaranteeing the integrity of 2992 the description between the time of the DESCRIBE message and the 2993 SETUP message. 2995 The identifier is an opaque identifier, and thus is not specific to 2996 any particular session description language. 2998 13.23 If-Modified-Since 3000 The If-Modified-Since request-header field is used with the DESCRIBE 3001 and SETUP methods to make them conditional. If the requested variant 3002 has not been modified since the time specified in this field, a 3003 description will not be returned from the server (DESCRIBE) or a 3004 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 3005 response will be returned without any message-body. 3007 If-Modified-Since = "If-Modified-Since" ":" HTTP-date 3009 An example of the field is: 3011 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 3013 13.24 Last-Modified 3015 The Last-Modified entity-header field indicates the date and time at 3016 which the origin server believes the presentation description or 3017 media stream was last modified. See [H14.29]. For the methods 3018 DESCRIBE, the header field indicates the last modification date and 3019 time of the description, for SETUP that of the media stream. 3021 13.25 Location 3023 See [H14.30]. 3025 13.26 Proxy-Authenticate 3027 See [H14.33]. 3029 13.27 Proxy-Require 3031 The Proxy-Require request-header field is used to indicate proxy-sen- 3032 sitive features that MUST be supported by the proxy. Any Proxy- 3033 Require header features that are not supported by the proxy MUST be 3034 negatively acknowledged by the proxy to the client using the Unsup- 3035 ported header. Servers should treat this field identically to the 3036 Require field, i.e. the Proxy-Require requirements does also apply to 3037 the server. 3039 See Section 13.32 for more details on the mechanics of this message 3040 and a usage example. 3042 Proxy-Require = "Proxy-Require" ":" 1#feature-tag 3044 Example of use: 3046 Proxy-Require: play.basic, con.persistent 3048 13.28 Public 3050 The Public response-header field lists the set of methods supported 3051 by the server. The purpose of this field is strictly to inform the 3052 recipient of the capabilities of the server regarding unusual meth- 3053 ods. The methods listed may or may not be applicable to the Request- 3054 URI; the Allow header field (section 14.7) MAY be used to indicate 3055 methods allowed for a particular URI. 3057 Public = "Public" ":" 1#method 3059 Example of use: 3061 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3063 This header field applies only to the server directly connected to 3064 the client (i.e., the nearest neighbor in a chain of connections). 3065 If the response passes through a proxy, the proxy MUST either remove 3066 the Public header field or replace it with one applicable to its own 3067 capabilities. 3069 13.29 Range 3071 The Range request and response header field specifies a range of 3072 time. The range can be specified in a number of units. This specifi- 3073 cation defines the smpte (Section 3.4), npt (Section 3.5), and clock 3074 (Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are | 3075 normally not meaningful. The header MAY contain a time parameter in | 3076 UTC, specifying the time at which the operation is to be made | 3077 effective. This functionality SHALL only be used with the REDIRECT | 3078 method. Servers supporting the Range header MUST understand the NPT 3079 range format and SHOULD understand the SMPTE range format. The Range 3080 response header indicates what range of time is actually being 3081 played. If the Range header is given in a time format that is not 3082 understood, the recipient should return 501 (Not Implemented). 3084 Ranges are half-open intervals, including the first point, but 3085 excluding the second point. In other words, a range of A-B starts 3086 exactly at time A, but stops just before B. Only the start time of a 3087 media unit such as a video or audio frame is relevant. As an example, 3088 assume that video frames are generated every 40 ms. A range of 3089 10.0-10.1 would include a video frame starting at 10.0 or later time 3090 and would include a video frame starting at 10.08, even though it 3091 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 3092 would exclude the frame at 10.08. 3094 Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ] 3095 ranges-specifier = npt-range / utc-range / smpte-range 3097 Example: 3099 Range: clock=19960213T143205Z-;time=19970123T143720Z 3101 The notation is similar to that used for the HTTP/1.1 [26] 3102 byte-range header. It allows clients to select an excerpt from 3103 the media object, and to play from a given point to the end as 3104 well as from the current location to a given point. The start 3105 of playback can be scheduled for any time in the future, 3106 although a server may refuse to keep server resources for 3107 extended idle periods. 3109 By default, range intervals increase, where the second point is 3110 larger than the first point. 3112 Example: 3114 Range: npt=10-15 3116 However, range intervals can also decrease if the Scale header (see 3117 section 13.34) indicates a negative scale value. For example, this 3118 would be the case when a playback in reverse is desired. 3120 Example: 3122 Scale: -1 3123 Range: npt=15-10 3125 Decreasing ranges are still half open intervals as described above. 3126 Thus, For range A-B, A is closed and B is open. In the above example, 3127 15 is closed and 10 is open. An exception to this rule is the case 3128 when B=0 in a decreasing range. In this case, the range is closed on 3129 both ends, as otherwise there would be no way to reach 0 on a reverse 3130 playback. 3132 Example: 3134 Scale: -1 3135 Range: npt=15-0 3137 In this range both 15 and 0 are closed. 3139 A decreasing range interval without a corresponding negative Scale 3140 header is not valid. 3142 13.30 Referer 3144 See [H14.36]. The URL refers to that of the presentation description, 3145 typically retrieved via HTTP. 3147 13.31 Retry-After 3149 See [H14.37]. 3151 13.32 Require 3153 The Require request-header field is used by clients or servers to 3154 ensure that the other end-point supports features that are required 3155 in respect to this request. It can also be used to query if the 3156 other end-point supports certain features, however the use of the 3157 Supported (Section 13.38) is much more effective in this purpose. 3158 The server MUST respond to this header by using the Unsupported 3159 header to negatively acknowledge those feature-tags which are NOT 3160 supported. The response SHALL use the error code 551 (Option Not Sup- 3161 ported). This header does not apply to proxies, for the same 3162 functionality in respect to proxies see, header Proxy-Require (Sec- 3163 tion 13.27). 3165 This is to make sure that the client-server interaction will 3166 proceed without delay when all features are understood by both 3167 sides, and only slow down if features are not understood (as 3168 in the example below). For a well-matched client-server pair, 3169 the interaction proceeds quickly, saving a round-trip often 3170 required by negotiation mechanisms. In addition, it also 3171 removes state ambiguity when the client requires features that 3172 the server does not understand. 3174 Require = "Require" ":" feature-tag *("," feature-tag) 3176 Example: 3178 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 3179 CSeq: 302 3180 Require: funky-feature 3181 Funky-Parameter: funkystuff 3183 S->C: RTSP/1.0 551 Option not supported 3184 CSeq: 302 3185 Unsupported: funky-feature 3187 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 3188 CSeq: 303 3190 S->C: RTSP/1.0 200 OK 3191 CSeq: 303 3193 In this example, "funky-feature" is the feature-tag which indicates 3194 to the client that the fictional Funky-Parameter field is required. 3195 The relationship between "funky-feature" and Funky-Parameter is not 3196 communicated via the RTSP exchange, since that relationship is an 3197 immutable property of "funky-feature" and thus should not be trans- 3198 mitted with every exchange. 3200 Proxies and other intermediary devices SHOULD ignore features that 3201 are not understood in this field. If a particular extension requires 3202 that intermediate devices support it, the extension should be tagged 3203 in the Proxy-Require field instead (see Section 13.27). 3205 13.33 RTP-Info 3207 The RTP-Info response-header field is used to set RTP-specific param- 3208 eters in the PLAY response. For streams using RTP as transport proto- 3209 col the RTP-Info header SHALL be part of a 200 response to PLAY. 3211 The RTP-Info response-header field is used to set RTP-specific param- 3212 eters in the PLAY response. These parameters correspond to the syn- 3213 chronization source identified by the ssrc parameter of the Transport 3214 response header in the SETUP reponse. For streams using RTP as trans- 3215 port protocol the RTP-Info header SHALL be part of a 200 response to 3216 PLAY. 3218 url: Indicates the stream URL which for which the following RTP 3219 parameters correspond, this URL MUST be the same used in the 3220 SETUP request for this media stream. Any relative URL SHALL 3221 use the request URL as base URL. 3223 seq: Indicates the sequence number of the first packet of the 3224 stream. This allows clients to gracefully deal with packets 3225 when seeking. The client uses this value to differentiate 3226 packets that originated before the seek from packets that 3227 originated after the seek. 3229 rtptime: Indicates the RTP timestamp corresponding to the time 3230 value in the Range response header. (Note: For aggregate con- 3231 trol, a particular stream may not actually generate a packet 3232 for the Range time value returned or implied. Thus, there is 3233 no guarantee that the packet with the sequence number indi- 3234 cated by seq actually has the timestamp indicated by rtptime.) 3235 The client uses this value to calculate the mapping of RTP 3236 time to NPT. 3238 A mapping from RTP timestamps to NTP timestamps (wall 3239 clock) is available via RTCP. However, this information 3240 is not sufficient to generate a mapping from RTP times- 3241 tamps to NPT. Furthermore, in order to ensure that this 3242 information is available at the necessary time (immedi- 3243 ately at startup or after a seek), and that it is deliv- 3244 ered reliably, this mapping is placed in the RTSP control 3245 channel. 3247 In order to compensate for drift for long, uninterrupted pre- 3248 sentations, RTSP clients should additionally map NPT to NTP, 3249 using initial RTCP sender reports to do the mapping, and later 3250 reports to check drift against the mapping. 3252 Additionally, the RTP-Info header parameter fields only apply to a 3253 single SSRC within a stream (the SSRC reported in the transport 3254 response header; see section 13.40). If there are multiple synchro- 3255 nization sources present within a RTP session, RTCP must be used to 3256 map RTP and NTP timestamps for those sources, for both synchroniza- 3257 tion and drift-checking. 3259 Syntax: 3261 RTP-Info = "RTP-Info" ":" 1#rtsp-info-spec 3262 rtsp-info-spec = stream-url 1*parameter 3263 stream-url = quoted-url / unquoted-url 3264 unquoted-url = "url" "=" safe-url 3265 quoted-url = "url" "=" <"> needquote-url <"> 3266 safe-url = url 3267 needquote-url = url //That contains ; or , 3268 url = ( absoluteURI / relativeURI ) 3269 parameter = ";" "seq" "=" 1*DIGIT 3270 / ";" "rtptime" "=" 1*DIGIT 3272 Additional constraint: safe-url MUST NOT contain the semicolon (";") 3273 or comma (",") characters. The quoted-url form SHOULD only be used 3274 when a URL does not meet the safe-url constraint, in order to ensure 3275 compatibility with implementations conformant to RFC 2326 [21]. 3277 absoluteURI and relativeURI are defined in RFC 2396 [22] with RFC 3278 2732 [30] applied. 3280 Example: 3282 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, 3283 url=rtsp://foo.com/bar.avi/streamid=1;seq=30211 3285 13.34 Scale 3287 A scale value of 1 indicates normal play at the normal forward view- 3288 ing rate. If not 1, the value corresponds to the rate with respect to 3289 normal viewing rate. For example, a ratio of 2 indicates twice the 3290 normal viewing rate ("fast forward") and a ratio of 0.5 indicates 3291 half the normal viewing rate. In other words, a ratio of 2 has normal 3292 play time increase at twice the wallclock rate. For every second of 3293 elapsed (wallclock) time, 2 seconds of content will be delivered. A 3294 negative value indicates reverse direction. 3296 Unless requested otherwise by the Speed parameter, the data rate 3297 SHOULD not be changed. Implementation of scale changes depends on the 3298 server and media type. For video, a server may, for example, deliver 3299 only key frames or selected key frames. For audio, it may time-scale 3300 the audio while preserving pitch or, less desirably, deliver frag- 3301 ments of audio. 3303 The server should try to approximate the viewing rate, but may 3304 restrict the range of scale values that it supports. The response 3305 MUST contain the actual scale value chosen by the server. 3307 If the server does not implement the possibility to scale, it will 3308 not return a Scale header. A server supporting Scale operations for 3309 PLAY SHALL indicate this with the use of the "play.scale" feature- 3310 tags. 3312 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 3314 When indicating a negative scale for a reverse playback, the Range 3315 header must indicate a decreasing range as described in section 3316 13.29. 3318 Example of playing in reverse at 3.5 times normal rate: 3320 Scale: -3.5 3321 Range: npt=15-10 3323 13.35 Speed 3325 The Speed request-header field requests the server to deliver data to 3326 the client at a particular speed, contingent on the server's ability 3327 and desire to serve the media stream at the given speed. Implementa- 3328 tion by the server is OPTIONAL. The default is the bit rate of the 3329 stream. 3331 The parameter value is expressed as a decimal ratio, e.g., a value of 3332 2.0 indicates that data is to be delivered twice as fast as normal. A 3333 speed of zero is invalid. All speeds may not be possible to support. 3334 Therefore the actual used speed MUST be included in the response. 3335 The lack of a response header is indication of lack of support from 3336 the server of this functionality. Support of the speed functionality 3337 are indicated by the "play.speed" feature-tag. 3339 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] 3341 Example: 3343 Speed: 2.5 3345 Use of this field changes the bandwidth used for data delivery. It is 3346 meant for use in specific circumstances where preview of the presen- 3347 tation at a higher or lower rate is necessary. Implementors should 3348 keep in mind that bandwidth for the session may be negotiated before- 3349 hand (by means other than RTSP), and therefore re-negotiation may be 3350 necessary. When data is delivered over UDP, it is highly recommended 3351 that means such as RTCP be used to track packet loss rates. If the 3352 data transport is performed over public best-effort networks the 3353 sender is responsible for performing congestion control of the 3354 stream. This MAY result in that the communicated speed is impossible 3355 to maintain. 3357 13.36 Server 3359 See [H14.38], however the header syntax is here corrected. 3361 Server = "Server" ":" ( product / comment ) *(SP (product / comment)) 3363 13.37 Session 3365 The Session request-header and response-header field identifies an 3366 RTSP session started by the media server in a SETUP response and con- 3367 cluded by TEARDOWN on the presentation URL. The session identifier is 3368 chosen by the media server (see Section 3.3) and MUST be returned in 3369 the SETUP response. Once a client receives a Session identifier, it 3370 MUST return it for any request related to that session. 3372 Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ] 3374 The timeout parameter is only allowed in a response header. The 3375 server uses it to indicate to the client how long the server is pre- 3376 pared to wait between RTSP commands or other signs of life before 3377 closing the session due to lack of activity (see Section A). The 3378 timeout is measured in seconds, with a default of 60 seconds (1 3379 minute). 3381 The mechanisms for showing liveness of the client is, any RTSP mes- 3382 sage with a Session header, or a RTCP message. It is RECOMMENDED that 3383 a client does not wait to the last second of the timeout before try- 3384 ing to send a liveness message. Even for RTSP messages using reliable 3385 protocols, such as TCP, the message may take some time to arrive 3386 safely at the receiver. To show liveness between RTSP request with 3387 other effects, the following mechanisms can be used, in descending 3388 order of preference: 3390 RTCP: Is used to report transport statistics and SHALL also work as 3391 keep alive. The server can determine the client by used net- 3392 work address and port together with the fact that the client 3393 is reporting on the servers SSRC(s). A downside of using RTCP 3394 is that it gives lower statistical guarantees to reach the 3395 server. However that probability is so little that it can be 3396 ignored in most cases. For example, a session with 60 seconds 3397 timeout and enough bitrate assigned to the RTCP messages, so 3398 the client sends a message on average every 5 seconds. That 3399 session have for a network with 5 % packet loss the probabil- 3400 ity to not get a liveness sign over to the server in the time- 3401 out interval is 2.4*E-16. In sessions with shorter timeout 3402 times, or much higher packet loss, or small RTCP bandwidths 3403 SHOULD use any of the mechanisms below. 3405 PING: The use of the PING method is the best of the RTSP based 3406 methods. It has no other effects than updating the timeout 3407 timer. In that way it will be a minimal message, that also 3408 does not cause any extra processing for the server. The down- 3409 side is that it may not be implemented. A client SHOULD use a 3410 OPTIONS request to verify support of the PING at the server. 3411 It is possible to detect support by sending a PING to the 3412 server. If a 200 (OK) message is received the server supports 3413 it. In case a 501 (Not Implemented) is received it does not 3414 support PING and there is no meaning in continue trying. Also 3415 the reception of a error message will also mean that the live- 3416 ness timer is not updated. 3418 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 3419 SHOULD be included. This method is basically as good as PING, 3420 however the implementation support of the method is today lim- 3421 ited. The same considerations as for PING apply regarding 3422 checking of support in server and proxies. 3424 OPTIONS: This method does also work. However it causes the server 3425 to perform unnecessary processing and result in bigger 3426 responses than necessary for the task. The reason for this is 3427 that the Public is always included creating overhead. 3429 Note that a session identifier identifies an RTSP session across 3430 transport sessions or connections. Control messages for more than one 3431 RTSP URL may be sent within a single RTSP session. Hence, it is pos- 3432 sible that clients use the same session for controlling many streams 3433 constituting a presentation, as long as all the streams come from the 3434 same server. (See example in Section 15). However, multiple "user" 3435 sessions for the same URL from the same client MUST use different 3436 session identifiers. 3438 The session identifier is needed to distinguish several deliv- 3439 ery requests for the same URL coming from the same client. 3441 The response 454 (Session Not Found) is returned if the session iden- 3442 tifier is invalid. 3444 13.38 Supported 3446 The Supported header field enumerates all the extensions supported by 3447 the client or server. When offered in a request, the receiver MUST 3448 respond with its corresponding Supported header. 3450 The Supported header field contains a list of feature-tags, described 3451 in Section 3.7, that are understood by the client or server. | 3453 Supported = "Supported" ":" [feature-tag *("," feature-tag)] || 3455 Example: | 3457 C->S: OPTIONS rtsp://example.com/ RTSP/1.0 | 3458 Supported: foo, bar, blech | 3460 S->C: RTSP/1.0 200 OK | 3461 Supported: bar, blech, baz | 3463 13.39 Timestamp 3465 The Timestamp general-header field describes when the client sent the 3466 request to the server. The value of the timestamp is of significance 3467 only to the client and may use any timescale. The server MUST echo 3468 the exact same value and MAY, if it has accurate information about 3469 this, add a floating point number indicating the number of seconds 3470 that has elapsed since it has received the request. The timestamp is 3471 used by the client to compute the round-trip time to the server so 3472 that it can adjust the timeout value for retransmissions. It also 3473 resolves retransmission ambiguities for unreliable transport of RTSP. 3475 Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] 3476 delay = *(DIGIT) [ "." *(DIGIT) ] 3478 13.40 Transport 3480 The Transport request- and response- header field indicates which 3481 transport protocol is to be used and configures its parameters such 3482 as destination address, compression, multicast time-to-live and des- 3483 tination port for a single stream. It sets those values not already 3484 determined by a presentation description. 3486 Transports are comma separated, listed in order of preference. 3487 Parameters may be added to each transport, separated by a semicolon. 3489 The Transport header field MAY also be used to change certain trans- 3490 port parameters. A server MAY refuse to change parameters of an 3491 existing stream. 3493 The server MAY return a Transport response-header field in the 3494 response to indicate the values actually chosen. 3496 A Transport request header field MAY contain a list of transport 3497 options acceptable to the client, in the form of multiple transport- 3498 spec entries. In that case, the server MUST return the single option 3499 (transport-spec) which was actually chosen. 3501 A transport-spec transport option may only contain one of any given 3502 parameter within it. Parameters may be given in any order. Addition- 3503 ally, it may only contain the unicast or multicast transport parame- 3504 ter. 3506 The Transport header field is restricted to describing a sin- 3507 gle media stream. (RTSP can also control multiple streams as a 3508 single entity.) Making it part of RTSP rather than relying on 3509 a multitude of session description formats greatly simplifies 3510 designs of firewalls. 3512 The syntax for the transport specifier is 3514 transport/profile/lower-transport. 3516 The default value for the "lower-transport" parameters is specific to 3517 the profile. For RTP/AVP, the default is UDP. 3519 Below are the configuration parameters associated with transport: 3521 General parameters: 3523 unicast / multicast: This parameter is a mutually exclusive indica- 3524 tion of whether unicast or multicast delivery will be 3525 attempted. One of the two values MUST be specified. Clients 3526 that are capable of handling both unicast and multicast trans- 3527 mission MUST indicate such capability by including two full 3528 transport-specs with separate parameters for each. 3530 destination: The address of the stream recipient to which a stream 3531 will be sent. The client originating the RTSP request may 3532 specify the destination address of the stream recipient with 3533 the destination parameter. When the destination field is spec- 3534 ified, the recipient may be a different party than the origi- 3535 nator of the request. To avoid becoming the unwitting perpe- 3536 trator of a remote-controlled denial-of-service attack, a 3537 server SHOULD authenticate the client originating the request 3538 and SHOULD log such attempts before allowing the client to 3539 direct a media stream to a recipient address not chosen by the 3540 server. While, this is particularly important if RTSP commands 3541 are issued via UDP, implementations cannot rely on TCP as 3542 reliable means of client identification by itself either. 3544 The server SHOULD NOT allow the destination field to be set 3545 unless a mechanism exists in the system to authorize the 3546 request originator to direct streams to the recipient. It is 3547 preferred that this authorization be performed by the recipi- 3548 ent itself and the credentials passed along to the server. 3549 However, in certain cases, such as when recipient address is a 3550 multicast group, or when the recipient is unable to communi- 3551 cate with the server in an out-of-band manner, this may not be 3552 possible. In these cases server may chose another method such 3553 as a server-resident authorization list to ensure that the 3554 request originator has the proper credentials to request 3555 stream delivery to the recipient. 3557 This parameter SHALL NOT be used when src_addr and dst_addr is | 3558 used in a transport declaration. IPv6 addresses are RECOM- | 3559 MENDED to be given as fully qualified domain to make it back- | 3560 wards compatible with RFC 2326 implementations. | 3562 source: If the source address for the stream is different than can | 3563 be derived from the RTSP endpoint address (the server in play- | 3564 back), the source address SHOULD be specified. To maintain | 3565 backwards compatibility with RFC 2326, any IPv6 host's address | 3566 must be given as a fully qualified domain name. This | 3567 parameter SHALL NOT be used when src_addr and dst_addr is used | 3568 in a transport declaration. 3570 This information may also be available through SDP. How- 3571 ever, since this is more a feature of transport than 3572 media initialization, the authoritative source for this 3573 information should be in the SETUP response. 3575 layers: The number of multicast layers to be used for this media 3576 stream. The layers are sent to consecutive addresses starting 3577 at the destination address. 3579 dest_addr: A general destination address parameter that can contain | 3580 one or more address and port pair. For each combination of | 3581 Protocol/Profile/Lower Transport the interpretation of the | 3582 address or addresses needs to be defined. The client or server | 3583 SHALL NOT use this parameter unless both client and server has | 3584 shown support. This parameter MUST be supported by client and | 3585 servers that implements this specification. Support is indi- | 3586 cated by the use of the feature-tag "play.basic". This parame- | 3587 ter SHALL NOT be used in the same transport specification as | 3588 any of the parameters "destination", "source", "port", | 3589 "client_port", and "server_port". | 3591 The same security consideration that are given for the "Desti- | 3592 nation" parameter does also applies to this parameter. This | 3593 parameter can be used for redirecting traffic to recipient not | 3594 desiring the media traffic. | 3596 src_addr: A General source address parameter that can contain one | 3597 or more address and port pair. For each combination of Proto- | 3598 col/Profile/Lower Transport the interpretation of the address | 3599 or addresses needs to be defined. The client or server SHALL | 3600 NOT use this parameter unless both client and server has shown | 3601 support. This parameter MUST be supported by client and | 3602 servers that implements this specification. Support is indi- | 3603 cated by the use the feature-tag "play.basic". This parameter | 3604 SHALL NOT be used in the same transport specification as any | 3605 of the parameters "destination", "source", "port", | 3606 "client_port", and "server_port". | 3608 The address or addresses indicated in the src_addr parameter | 3609 SHOULD be used both for sending and receiving of the media | 3610 streams data packet. The main reasons are two: First by send- | 3611 ing from the indicated ports the source address will be known | 3612 by the receiver of the packet. Secondly, in the presence of | 3613 NATs some traversal mechanism requires either knowledge from | 3614 which address and port a packet flow is coming, or having the | 3615 possibility to send data to the sender port. 3617 mode: The mode parameter indicates the methods to be supported for 3618 this session. Valid values are PLAY and RECORD. If not pro- 3619 vided, the default is PLAY. The RECORD value was defined in 3620 RFC 2326 and is deprecated in this specification. 3622 append: The append parameter was used together with RECORD and is 3623 now deprecated. 3625 interleaved: The interleaved parameter implies mixing the media 3626 stream with the control stream in whatever protocol is being 3627 used by the control stream, using the mechanism defined in 3628 Section 11.11. The argument provides the channel number to be 3629 used in the $ statement and MUST be present. This parameter 3630 MAY be specified as a range, e.g., interleaved=4-5 in cases 3631 where the transport choice for the media stream requires it, 3632 e.g. for RTP with RTCP. The channel number given in the 3633 request are only a guidance from the client to the server on 3634 what channel number(s) to use. The server MAY set any valid 3635 channel number in the response. The declared channel(s) are 3636 bi-directional, so both end-parties MAY send data on the given 3637 channel. One example of such usage is the second channel used 3638 for RTCP, where both server and client sends RTCP packets on 3639 the same channel. 3641 This allows RTP/RTCP to be handled similarly to the way 3642 that it is done with UDP, i.e., one channel for RTP and 3643 the other for RTCP. 3645 Multicast-specific: 3647 ttl: multicast time-to-live. 3649 RTP-specific: 3651 These parameters are MAY only be used if the media transport protocol 3652 is RTP. 3654 port: This parameter provides the RTP/RTCP port pair for a multi- 3655 cast session. It is should be specified as a range, e.g., 3656 port=3456-3457 3658 client_port: This parameter provides the unicast RTP/RTCP port pair | 3659 on the client where media data and control information is to | 3660 be sent. It is specified as a range, e.g., port=3456-3457 is | 3661 used in a transport declaration. | 3663 server_port: This parameter provides the unicast RTP/RTCP port pair | 3664 on the server where media data and control information is to | 3665 be sent. It is specified as a range, e.g., port=3456-3457 is | 3666 used in a transport declaration. 3668 ssrc: The ssrc parameter, if included in a SETUP response, indi- 3669 cates the RTP SSRC [23] value that will be used by the media 3670 server for RTP packets within the stream. It is expressed as 3671 an eight digit hexadecimal value. If the server does not act 3672 as a synchronization source for stream data (for instance, 3673 server is a translator, reflector, etc.) the value will be the 3674 "packet sender's SSRC" that would have been used in the RTCP 3675 Receiver Reports generated by the server, regardless of 3676 whether the server actually generates RTCP RRs. If there are 3677 multiple sources within the stream, the ssrc parameter only 3678 indicates the value for a single synchronization source. Other 3679 sources must be deduced from the actual RTP/RTCP stream. 3681 The functionality of specifying the ssrc parameter in a SETUP 3682 request is deprecated as it is incompatible with the specifi- 3683 cation of RTP in RFC 1889. If the parameter is included in the 3684 transport header of a SETUP request, the server MAY ignore the 3685 it, and choose an appropriate SSRC for the stream. It MAY set 3686 the ssrc parameter in the transport header of the response. 3688 Transport = "Transport" ":" 1#transport-spec || 3689 transport-spec = transport-id *parameter || 3690 transport-id = transport-protocol "/" profile ["/" lower-transport]|| 3691 ; no LWS is allowed inside transport-id || 3692 transport-protocol = "RTP" / token || 3693 profile = "AVP" / token || 3694 lower-transport = "TCP" / "UDP" / token || 3695 parameter = ";" ( "unicast" / "multicast" ) || 3696 / ";" "source" "=" host || 3697 / ";" "destination" [ "=" host ] || 3698 / ";" "interleaved" "=" channel [ "-" channel ]|| 3699 / ";" "append" || 3700 / ";" "ttl" "=" ttl || 3701 / ";" "layers" "=" 1*DIGIT || 3702 / ";" "port" "=" port-spec || 3703 / ";" "client_port" "=" port-spec || 3704 / ";" "server_port" "=" port-spec || 3705 / ";" "ssrc" "=" ssrc || 3706 / ";" "mode" "=" mode-spec || 3707 / ";" "dest_addr" "=" addr-list || 3708 / ";" "src_addr" "=" addr-list || 3709 / ";" trn-parameter-extension || 3710 port-spec = port [ "-" port ] || 3711 trn-parameter-extension = par-name "=" trn-par-value || 3712 par-name = token || 3713 trn-par-value = *unreserved || 3714 ttl = 1*3(DIGIT) || 3715 ssrc = 8*8(HEX) || 3716 channel = 1*3(DIGIT) || 3717 mode-spec = <"> 1#mode <"> / mode || 3718 mode = "PLAY" / "RECORD" / token || 3719 addr-list = host-port *("/" host-port) || 3720 host-port = host [":" port] || 3721 host = see chapter 16 || 3722 port = see chapter 16 || 3724 The combination of transport protocol, profile and lower transport | 3725 needs to be defined. A number of combinations are defined in the | 3726 appendix B. 3728 Below is a usage example, showing a client advertising the capability 3729 to handle multicast or unicast, preferring multicast. Since this is a 3730 unicast-only stream, the server responds with the proper transport 3731 parameters for unicast. 3733 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 3734 CSeq: 302 3735 Transport: RTP/AVP;multicast;mode="PLAY", 3736 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" 3738 S->C: RTSP/1.0 200 OK 3739 CSeq: 302 3740 Date: 23 Jan 1997 15:35:06 GMT 3741 Session: 47112344 3742 Transport: RTP/AVP;unicast;client_port=3456-3457; 3743 server_port=6256-6257;mode="PLAY" 3745 13.41 Unsupported 3747 The Unsupported response-header field lists the features not sup- 3748 ported by the server. In the case where the feature was specified via 3749 the Proxy-Require field (Section 13.27), if there is a proxy on the 3750 path between the client and the server, the proxy MUST send a 3751 response message with a status code of 551 (Option Not Supported). 3752 The request SHALL NOT be forwarded. 3754 See Section 13.32 for a usage example. 3756 Unsupported = "Unsupported" ":" feature-tag *("," feature-tag) 3758 13.42 User-Agent 3760 See [H14.43] for explanation, however the syntax is clarified due to 3761 an error in RFC 2616. A Client SHOULD include this header in all RTSP 3762 messages it sends. 3764 User-Agent = "User-Agent" ":" ( product / comment ) 0*(SP 3765 (product / comment) 3767 13.43 Vary 3769 See [H14.44] 3771 13.44 Via 3773 See [H14.45]. 3775 13.45 WWW-Authenticate 3777 See [H14.47]. 3779 14 Caching 3781 In HTTP, response-request pairs are cached. RTSP differs signifi- | 3782 cantly in that respect. Responses are not cacheable, with the excep- | 3783 tion of the presentation description returned by DESCRIBE. (Since the | 3784 responses for anything but DESCRIBE and GET_PARAMETER do not return | 3785 any data, caching is not really an issue for these requests.) How- | 3786 ever, it is desirable for the continuous media data, typically deliv- | 3787 ered out-of-band with respect to RTSP, to be cached, as well as the | 3788 session description. 3790 On receiving a SETUP or PLAY request, a proxy ascertains whether it 3791 has an up-to-date copy of the continuous media content and its 3792 description. It can determine whether the copy is up-to-date by 3793 issuing a SETUP or DESCRIBE request, respectively, and comparing the 3794 Last-Modified header with that of the cached copy. If the copy is not 3795 up-to-date, it modifies the SETUP transport parameters as appropriate 3796 and forwards the request to the origin server. Subsequent control 3797 commands such as PLAY or PAUSE then pass the proxy unmodified. The 3798 proxy delivers the continuous media data to the client, while possi- 3799 bly making a local copy for later reuse. The exact behavior allowed 3800 to the cache is given by the cache-response directives described in 3801 Section 13.9. A cache MUST answer any DESCRIBE requests if it is cur- 3802 rently serving the stream to the requestor, as it is possible that 3803 low-level details of the stream description may have changed on the 3804 origin-server. 3806 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 3807 through" variety. Rather than retrieving the whole resource from the 3808 origin server, the cache simply copies the streaming data as it 3809 passes by on its way to the client. Thus, it does not introduce addi- 3810 tional latency. 3812 To the client, an RTSP proxy cache appears like a regular media 3813 server, to the media origin server like a client. Just as an HTTP 3814 cache has to store the content type, content language, and so on for 3815 the objects it caches, a media cache has to store the presentation 3816 description. Typically, a cache eliminates all transport-references 3817 (that is, multicast information) from the presentation description, 3818 since these are independent of the data delivery from the cache to 3819 the client. Information on the encodings remains the same. If the 3820 cache is able to translate the cached media data, it would create a 3821 new presentation description with all the encoding possibilities it 3822 can offer. 3824 15 Examples 3826 The following examples refer to stream description formats that are 3827 not standards, such as RTSL. The following examples are not to be 3828 used as a reference for those formats. 3830 15.1 Media on Demand (Unicast) 3832 Client C requests a movie from media servers A (audio.example.com ) 3833 and V (video.example.com ). The media description is stored on a web 3834 server W. The media description contains descriptions of the presen- 3835 tation and all its streams, including the codecs that are available, 3836 dynamic RTP payload types, the protocol stack, and content informa- 3837 tion such as language or copyright restrictions. It may also give an 3838 indication about the timeline of the movie. 3840 In this example, the client is only interested in the last part of 3841 the movie. 3843 C->W: GET /twister.sdp HTTP/1.1 3844 Host: www.example.com 3845 Accept: application/sdp 3847 W->C: HTTP/1.0 200 OK 3848 Date: 23 Jan 1997 15:35:06 GMT 3849 Content-Type: application/sdp 3851 v=0 3852 o=- 2890844526 2890842807 IN IP4 192.16.24.202 3853 s=RTSP Session 3854 e=adm@example.com 3855 m=audio 0 RTP/AVP 0 3856 a=control:rtsp://audio.example.com/twister/audio.en 3857 m=video 0 RTP/AVP 31 3858 a=control:rtsp://video.example.com/twister/video 3860 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 3861 CSeq: 1 3862 User-Agent: PhonyClient/1.2 3863 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 3865 A->C: RTSP/1.0 200 OK 3866 CSeq: 1 3867 Session: 12345678 3868 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; 3869 server_port=5000-5001 3871 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 3872 CSeq: 1 3873 User-Agent: PhonyClient/1.2 3874 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 3876 V->C: RTSP/1.0 200 OK 3877 CSeq: 1 3878 Session: 23456789 3879 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; 3880 server_port=5002-5003 3882 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 3883 CSeq: 2 3884 User-Agent: PhonyClient/1.2 3885 Session: 23456789 3886 Range: smpte=0:10:00- 3888 V->C: RTSP/1.0 200 OK 3889 CSeq: 2 3890 Session: 23456789 3891 Range: smpte=0:10:00-0:20:00 3892 RTP-Info: url=rtsp://video.example.com/twister/video; 3893 seq=12312232;rtptime=78712811 3895 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 3896 CSeq: 2 3897 User-Agent: PhonyClient/1.2 3898 Session: 12345678 3899 Range: smpte=0:10:00- 3901 A->C: RTSP/1.0 200 OK 3902 CSeq: 2 3903 User-Agent: PhonyClient/1.2 3904 Session: 12345678 3905 Range: smpte=0:10:00-0:20:00 3906 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; 3907 seq=876655;rtptime=1032181 3909 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 3910 CSeq: 3 3911 User-Agent: PhonyClient/1.2 3912 Session: 12345678 3914 A->C: RTSP/1.0 200 OK 3915 CSeq: 3 3917 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 3918 CSeq: 3 3919 User-Agent: PhonyClient/1.2 3920 Session: 23456789 3922 V->C: RTSP/1.0 200 OK 3923 CSeq: 3 3925 Even though the audio and video track are on two different servers, 3926 and may start at slightly different times and may drift with respect 3927 to each other, the client can synchronize the two using standard RTP 3928 methods, in particular the time scale contained in the RTCP sender 3929 reports. 3931 15.2 Streaming of a Container file 3932 For purposes of this example, a container file is a storage entity in 3933 which multiple continuous media types pertaining to the same end-user 3934 presentation are present. In effect, the container file represents an 3935 RTSP presentation, with each of its components being RTSP streams. 3936 Container files are a widely used means to store such presentations. 3937 While the components are transported as independent streams, it is 3938 desirable to maintain a common context for those streams at the 3939 server end. 3941 This enables the server to keep a single storage handle open 3942 easily. It also allows treating all the streams equally in 3943 case of any prioritization of streams by the server. 3945 It is also possible that the presentation author may wish to prevent 3946 selective retrieval of the streams by the client in order to preserve 3947 the artistic effect of the combined media presentation. Similarly, in 3948 such a tightly bound presentation, it is desirable to be able to con- 3949 trol all the streams via a single control message using an aggregate 3950 URL. 3952 The following is an example of using a single RTSP session to control 3953 multiple streams. It also illustrates the use of aggregate URLs. 3955 Client C requests a presentation from media server M. The movie is 3956 stored in a container file. The client has obtained an RTSP URL to 3957 the container file. 3959 C->M: DESCRIBE rtsp://example.com/twister RTSP/1.0 3960 CSeq: 1 3962 M->C: RTSP/1.0 200 OK 3963 CSeq: 1 3964 Date: 23 Jan 1997 15:35:06 GMT 3965 Content-Type: application/sdp 3966 Content-Length: 164 3968 v=0 3969 o=- 2890844256 2890842807 IN IP4 172.16.2.93 3970 s=RTSP Session 3971 i=An Example of RTSP Session Usage 3972 e=adm@example.com 3973 a=control:rtsp://example.com/twister 3974 t=0 0 3975 m=audio 0 RTP/AVP 0 3976 a=control:rtsp://example.com/twister/audio 3977 m=video 0 RTP/AVP 26 3978 a=control:rtsp://example.com/twister/video 3980 C->M: SETUP rtsp://example.com/twister/audio RTSP/1.0 3981 CSeq: 2 3982 Transport: RTP/AVP;unicast;client_port=8000-8001 3984 M->C: RTSP/1.0 200 OK 3985 CSeq: 2 3986 Transport: RTP/AVP;unicast;client_port=8000-8001; 3987 server_port=9000-9001 3988 Session: 12345678 3990 C->M: SETUP rtsp://example.com/twister/video RTSP/1.0 3991 CSeq: 3 3992 Transport: RTP/AVP;unicast;client_port=8002-8003 3993 Session: 12345678 3995 M->C: RTSP/1.0 200 OK 3996 CSeq: 3 3997 Transport: RTP/AVP;unicast;client_port=8002-8003; 3998 server_port=9004-9005 3999 Session: 12345678 4001 C->M: PLAY rtsp://example.com/twister RTSP/1.0 4002 CSeq: 4 4003 Range: npt=0- 4004 Session: 12345678 4006 M->C: RTSP/1.0 200 OK 4007 CSeq: 4 4008 Session: 12345678 4009 Range: npt=0- 4010 RTP-Info: url=rtsp://example.com/twister/video; 4011 seq=12345;rtptime=3450012, 4012 url=rtsp://example.com/twister/audio; 4013 seq=54321;rtptime=2876889 4015 C->M: PAUSE rtsp://example.com/twister/video RTSP/1.0 4016 CSeq: 5 4017 Session: 12345678 4019 M->C: RTSP/1.0 460 Only aggregate operation allowed 4020 CSeq: 5 4022 C->M: PAUSE rtsp://example.com/twister RTSP/1.0 4023 CSeq: 6 4024 Session: 12345678 4026 M->C: RTSP/1.0 200 OK 4027 CSeq: 6 4028 Session: 12345678 4030 C->M: SETUP rtsp://example.com/twister RTSP/1.0 4031 CSeq: 7 4032 Transport: RTP/AVP;unicast;client_port=10000 4033 Session: 12345678 4035 M->C: RTSP/1.0 459 Aggregate operation not allowed 4036 CSeq: 7 4038 In the first instance of failure, the client tries to pause one 4039 stream (in this case video) of the presentation. This is not allowed 4040 as this session is set up for aggregated control. In the second 4041 instance, the aggregate URL may not be used for SETUP and one control 4042 message is required per stream to set up transport parameters. 4044 This keeps the syntax of the Transport header simple and 4045 allows easy parsing of transport information by firewalls. 4047 15.3 Single Stream Container Files 4049 Some RTSP servers may treat all files as though they are "container 4050 files", yet other servers may not support such a concept. Because of 4051 this, clients SHOULD use the rules set forth in the session descrip- 4052 tion for request URLs, rather than assuming that a consistent URL may 4053 always be used throughout. Here's an example of how a multi-stream 4054 server might expect a single-stream file to be served: 4056 C->S DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 4057 Accept: application/x-rtsp-mh, application/sdp 4058 CSeq: 1 4060 S->C RTSP/1.0 200 OK 4061 CSeq: 1 4062 Content-base: rtsp://foo.com/test.wav/ 4063 Content-type: application/sdp 4064 Content-length: 48 4066 v=0 4067 o=- 872653257 872653257 IN IP4 172.16.2.187 4068 s=mu-law wave file 4069 i=audio test 4070 t=0 0 4071 m=audio 0 RTP/AVP 0 4072 a=control:streamid=0 4074 C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 4075 Transport: RTP/AVP/UDP;unicast; 4076 client_port=6970-6971;mode="PLAY" 4077 CSeq: 2 4079 S->C RTSP/1.0 200 OK 4080 Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; 4081 server_port=6970-6971;mode="PLAY" 4082 CSeq: 2 4083 Session: 2034820394 4085 C->S PLAY rtsp://foo.com/test.wav RTSP/1.0 4086 CSeq: 3 4087 Session: 2034820394 4089 S->C RTSP/1.0 200 OK 4090 CSeq: 3 4091 Session: 2034820394 4092 Range: npt=0-600 4093 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; 4094 seq=981888;rtptime=3781123 4096 Note the different URL in the SETUP command, and then the switch back 4097 to the aggregate URL in the PLAY command. This makes complete sense 4098 when there are multiple streams with aggregate control, but is less 4099 than intuitive in the special case where the number of streams is 4100 one. 4102 In this special case, it is recommended that servers be forgiving of 4103 implementations that send: 4105 C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 4106 CSeq: 3 4108 In the worst case, servers should send back: 4110 S->C RTSP/1.0 460 Only aggregate operation allowed 4111 CSeq: 3 4113 One would also hope that server implementations are also forgiving of 4114 the following: 4116 C->S SETUP rtsp://foo.com/test.wav RTSP/1.0 4117 Transport: rtp/avp/udp;client_port=6970-6971;mode="PLAY" 4118 CSeq: 2 4120 Since there is only a single stream in this file, it's not ambiguous 4121 what this means. 4123 15.4 Live Media Presentation Using Multicast 4125 The media server M chooses the multicast address and port. Here, we 4126 assume that the web server only contains a pointer to the full 4127 description, while the media server M maintains the full description. 4129 C->W: GET /concert.sdp HTTP/1.1 4130 Host: www.example.com 4132 W->C: HTTP/1.1 200 OK 4133 Content-Type: application/x-rtsl 4135 4136 4137 4139 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 4140 CSeq: 1 4142 M->C: RTSP/1.0 200 OK 4143 CSeq: 1 4144 Content-Type: application/sdp 4145 Content-Length: 44 4147 v=0 4148 o=- 2890844526 2890842807 IN IP4 192.16.24.202 4149 s=RTSP Session 4150 m=audio 3456 RTP/AVP 0 4151 c=IN IP4 224.2.0.1/16 4152 a=control:rtsp://live.example.com/concert/audio 4154 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 4155 CSeq: 2 4156 Transport: RTP/AVP;multicast 4158 M->C: RTSP/1.0 200 OK 4159 CSeq: 2 4160 Transport: RTP/AVP;multicast;destination=224.2.0.1; 4161 port=3456-3457;ttl=16 4162 Session: 0456804596 4164 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 4165 CSeq: 3 4166 Session: 0456804596 4168 M->C: RTSP/1.0 200 OK 4169 CSeq: 3 4170 Session: 0456804596 4171 Range:npt=now- 4173 16 Syntax 4175 The RTSP syntax is described in an augmented Backus-Naur form (BNF) 4176 as defined in RFC 2234 [14]. Also the "#" rule from RFC 2616 [26] is 4177 also defined and used in this syntax description. 4179 16.1 Base Syntax 4181 OCTET = 4182 CHAR = 4183 UPALPHA = 4184 LOALPHA = 4185 ALPHA = UPALPHA / LOALPHA 4186 DIGIT = 4187 CTL = 4189 CR = 4190 LF = 4191 SP = 4192 HT = 4193 <"> = 4194 BACKSLASH = 4195 CRLF = CR LF 4196 LWS = [CRLF] 1*( SP / HT ) 4197 TEXT = 4198 tspecials = "(" / ")" / "<" / ">" / "@" 4199 / "," / ";" / ":" / BACKSLASH / <"> 4200 / "/" / "[" / "]" / "?" / "=" 4201 / "{" / "}" / SP / HT 4202 token = 1* 4203 quoted-string = ( <"> *(qdtext) <"> ) 4204 qdtext = > 4205 quoted-pair = BACKSLASH CHAR 4206 message-header = field-name ":" [ field-value ] CRLF 4207 field-name = token 4208 field-value = *( field-content / LWS ) 4209 field-content = 4213 safe = "$" / "-" / "_" / "." / "+" 4214 extra = "!" / "*" / "'" / "(" / ")" / "," 4215 hex = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / 4216 "a" / "b" / "c" / "d" / "e" / "f" 4217 escape = "%" hex hex 4218 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 4219 unreserved = alpha / digit / safe / extra 4220 xchar = unreserved / reserved / escape 4222 16.2 RTSP Protocol Definition 4224 16.2.1 Message Syntax 4226 generRTSP-message= st=rtRequest / Response ; RTSP/1.0 messages 4227 *(message-header CRLF) 4228 CRLF 4229 [ message-body ] 4230 start-line = Request-Line / Status-Line 4232 Request g=nerRequest-Line ; Sec;iSection 6.1 4233 / request-header ; Section 6.2 4234 / entity-header ) ; Section 8.1 4235 CRLF 4236 [ message-body ] ; Section 4.3 4237 Response = Status-Line ; Section 7.1 4238 *( general-header ; Section 5 4239 / response-header ; Section 7.1.2 4240 / entity-header ) ; Section 8.1 4241 CRLF 4242 [ message-body ] ; Section 4.3 4244 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 4245 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 4247 Method = "DESCRIBE" ; Section 11.2 4248 / "GET_PARAMETER" ; Section 11.7 4249 / "OPTIONS" ; Section 11.1 4250 / "PAUSE" ; Section 11.5 4251 / "PLAY" ; Section 11.4 4252 / "PING" ; Section 11.10 4253 / "REDIRECT" ; Section 11.9 4254 / "SETUP" ; Section 11.3 4255 / "SET_PARAMETER" ; Section 11.8 4256 / "TEARDOWN" ; Section 11.6 4257 / extension-method 4259 extension-method = token 4260 Request-URI = "*" / absolute_URI 4261 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 4263 Status-Code = "100" ; Continue 4264 / "200" ; OK 4265 / "201" ; Created 4266 / "250" ; Low on Storage Space 4267 / "300" ; Multiple Choices 4268 / "301" ; Moved Permanently 4269 / "302" ; Moved Temporarily 4270 / "303" ; See Other 4271 / "304" ; Not Modified 4272 / "305" ; Use Proxy 4273 / "400" ; Bad Request 4274 / "401" ; Unauthorized 4275 / "402" ; Payment Required 4276 / "403" ; Forbidden 4277 / "404" ; Not Found 4278 / "405" ; Method Not Allowed 4279 / "406" ; Not Acceptable 4280 / "407" ; Proxy Authentication Required 4281 / "408" ; Request Time-out 4282 / "410" ; Gone 4283 / "411" ; Length Required 4284 / "412" ; Precondition Failed 4285 / "413" ; Request Entity Too Large 4286 / "414" ; Request-URI Too Large 4287 / "415" ; Unsupported Media Type 4288 / "451" ; Parameter Not Understood 4289 / "452" ; reserved 4290 / "453" ; Not Enough Bandwidth 4291 / "454" ; Session Not Found 4292 / "455" ; Method Not Valid in This State 4293 / "456" ; Header Field Not Valid for Resource 4294 / "457" ; Invalid Range 4295 / "458" ; Parameter Is Read-Only 4296 / "459" ; Aggregate operation not allowed 4297 / "460" ; Only aggregate operation allowed 4298 / "461" ; Unsupported transport 4299 / "462" ; Destination unreachable 4300 / "500" ; Internal Server Error 4301 / "501" ; Not Implemented 4302 / "502" ; Bad Gateway 4303 / "503" ; Service Unavailable 4304 / "504" ; Gateway Time-out 4305 / "505" ; RTSP Version not supported 4306 / "551" ; Option not supported 4307 / extension-code 4309 extension-code = 3DIGIT 4310 Reason-Phrase = * 4312 general-header = Cache-Control ; Section 13.9 4313 / Connection ; Section 13.10 4314 / CSeq ; Section 13.17 4315 / Date ; Section 13.18 4316 / Timestamp ; Section 13.39 4317 / Via ; Section 13.44 4318 request-header = Accept ; Section 13.1 4319 / Accept-Encoding ; Section 13.2 4320 / Accept-Language ; Section 13.3 4321 / Authorization ; Section 13.6 4322 / Bandwidth ; Section 13.7 4323 / Blocksize ; Section 13.8 4324 / From ; Section 13.20 4325 / If-Modified-Since ; Section 13.23 4326 / Proxy-Require ; Section 13.27 4327 / Range ; Section 13.29 4328 / Referer ; Section 13.30 4329 / Require ; Section 13.32 4330 / Scale ; Section 13.34 4331 / Session ; Section 13.37 4332 / Speed ; Section 13.35 4333 / Supported ; Section 13.38 4334 / Transport ; Section 13.40 4335 / User-Agent ; Section 13.42 4337 response-header = Accept-Ranges ; Section 13.4 4338 / Location ; Section 13.25 4339 / Proxy-Authenticate ; Section 13.26 4340 / Public ; Section 13.28 4341 / Range ; Section 13.29 4342 / Retry-After ; Section 13.31 4343 / RTP-Info ; Section 13.33 4344 / Scale ; Section 13.34 4345 / Session ; Section 13.37 4346 / Server ; Section 13.36 4347 / Speed ; Section 13.35 4348 / Transport ; Section 13.40 4349 / Unsupported ; Section 13.41 4350 / Vary ; Section 13.43 4351 / WWW-Authenticate ; Section 13.45 4353 rtsp_URL = ( "rtsp:" / "rtspu:" / "rtsps" ) 4354 "//" host [ ":" port ] [ abs_path ] [ "#" fragment ] 4355 host = As defined by RFC 2732 [30] 4356 abs_path = As defined by RFC 2396 [22] 4357 port = *DIGIT 4358 smpte-range = smpte-type "=" smpte-range-spec 4359 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) / ( "-" smpte-time ) 4360 smpte-type = "smpte" / "smpte-30-drop" / "smpte-25" 4361 ; other timecodes may be added 4362 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 4363 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 4365 npt-range = ["npt" "="] npt-range-spec 4366 ; implementations SHOULD use npt= prefix, but SHOULD 4367 ; be prepared to interoperate with RFC 2326 4368 ; implementations which don't use it 4369 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 4370 npt-time = "now" / npt-sec / npt-hhmmss 4371 npt-sec = 1*DIGIT [ "." *DIGIT ] 4372 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 4373 npt-hh = 1*DIGIT ; any positive number 4374 npt-mm = 1*2DIGIT ; 0-59 4375 npt-ss = 1*2DIGIT ; 0-59 4376 utc-range = "clock" "=" utc-range-spec 4377 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 4378 utc-time = utc-date "T" utc-time "Z" 4379 utc-date = 8DIGIT ; < YYYYMMDD > 4380 utc-time = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > 4381 fraction = 1*DIGIT 4383 feature-tag = token 4385 16.2.2 Header Syntax 4387 Transport = "Transport" ":" 1#transport-spec 4388 transport-spec = transport-id *parameter 4389 transport-id = transport-protocol "/" profile ["/" lower-transport] 4390 ; no LWS is allowed inside transport-id 4391 transport-protocol = "RTP" / token 4392 profile = "AVP" / token 4393 lower-transport = "TCP" / "UDP" / token 4394 parameter = ";" ( "unicast" / "multicast" ) 4395 / ";" "source" "=" host 4396 / ";" "destination" [ "=" host ] 4397 / ";" "interleaved" "=" channel [ "-" channel ] 4398 / ";" "append" 4399 / ";" "ttl" "=" ttl 4400 / ";" "layers" "=" 1*DIGIT 4401 / ";" "port" "=" port-spec 4402 / ";" "client_port" "=" port-spec 4403 / ";" "server_port" "=" port-spec 4404 / ";" "ssrc" "=" ssrc 4405 / ";" "client_ssrc" "=" ssrc 4406 / ";" "mode" "=" mode-spec 4407 / ";" "dest_addresses" "=" addr-list 4408 / ";" "src_addresses" "=" addr-list 4409 / ";" trn-parameter-extension 4410 port-spec = port [ "-" port ] 4411 trn-parameter-extension = par-name "=" trn-par-value 4412 par-name = token 4413 trn-par-value = *unreserved 4414 ttl = 1*3(DIGIT) 4415 ssrc = 8*8(HEX) 4416 channel = 1*3(DIGIT) 4417 mode-spec = <"> 1#mode <"> / mode 4418 mode = "PLAY" / "RECORD" / token 4419 addr-list = host-port *("/" host-port) 4420 host-port = host [":" port] 4421 host = see chapter 16 4422 port = see chapter 16 4424 17 Security Considerations 4426 Because of the similarity in syntax and usage between RTSP servers 4427 and HTTP servers, the security considerations outlined in [H15] 4428 apply. Specifically, please note the following: 4430 Authentication Mechanisms: RTSP and HTTP share common authentica- 4431 tion schemes, and thus should follow the same prescriptions 4432 with regards to authentication . See chapter 15.1 of [2] for 4433 client authentication issues, and chapter 15.2 of [2] for 4434 issues regarding support for multiple authentication mecha- 4435 nisms. Also see [H15.6]. 4437 Abuse of Server Log Information: RTSP and HTTP servers will presum- 4438 ably have similar logging mechanisms, and thus should be 4439 equally guarded in protecting the contents of those logs, thus 4440 protecting the privacy of the users of the servers. See 4441 [H15.1.1] for HTTP server recommendations regarding server 4442 logs. 4444 Transfer of Sensitive Information: There is no reason to believe 4445 that information transferred via RTSP may be any less sensi- 4446 tive than that normally transmitted via HTTP. Therefore, all 4447 of the precautions regarding the protection of data privacy 4448 and user privacy apply to implementors of RTSP clients, 4449 servers, and proxies. See [H15.1.2] for further details. 4451 Attacks Based On File and Path Names: Though RTSP URLs are opaque 4452 handles that do not necessarily have file system semantics, it 4453 is anticipated that many implementations will translate por- 4454 tions of the request URLs directly to file system calls. In 4455 such cases, file systems SHOULD follow the precautions out- 4456 lined in [H15.5], such as checking for ".." in path compo- 4457 nents. 4459 Personal Information: RTSP clients are often privy to the same 4460 information that HTTP clients are (user name, location, etc.) 4461 and thus should be equally. See [H15.1] for further recommen- 4462 dations. 4464 Privacy Issues Connected to Accept Headers: Since may of the same 4465 "Accept" headers exist in RTSP as in HTTP, the same caveats 4466 outlined in [H15.1.4] with regards to their use should be fol- 4467 lowed. 4469 DNS Spoofing: Presumably, given the longer connection times typi- 4470 cally associated to RTSP sessions relative to HTTP sessions, 4471 RTSP client DNS optimizations should be less prevalent. 4472 Nonetheless, the recommendations provided in [H15.3] are still 4473 relevant to any implementation which attempts to rely on a 4474 DNS-to-IP mapping to hold beyond a single use of the mapping. 4476 Location Headers and Spoofing: If a single server supports multiple 4477 organizations that do not trust one another, then it must 4478 check the values of Location and Content-Location header 4479 fields in responses that are generated under control of said 4480 organizations to make sure that they do not attempt to invali- 4481 date resources over which they have no authority. ([H15.4]) 4483 In addition to the recommendations in the current HTTP specification 4484 (RFC 2616 [26], as of this writing) and also of the previous RFC2068 4485 [2], future HTTP specifications may provide additional guidance on 4486 security issues. 4488 The following are added considerations for RTSP implementations. 4490 Concentrated denial-of-service attack: The protocol offers the 4491 opportunity for a remote-controlled denial-of-service attack. 4493 The attacker may initiate traffic flows to one or more IP 4494 addresses by specifying them as the destination in SETUP 4495 requests. While the attacker's IP address may be known in this 4496 case, this is not always useful in prevention of more attacks 4497 or ascertaining the attackers identity. Thus, an RTSP server 4498 SHOULD only allow client-specified destinations for RTSP-ini- 4499 tiated traffic flows if the server has verified the client's 4500 identity, either against a database of known users using RTSP 4501 authentication mechanisms (preferably digest authentication or 4502 stronger), or other secure means. 4504 Session hijacking: Since there is no or little relation between a 4505 transport layer connection and an RTSP session, it is possible 4506 for a malicious client to issue requests with random session 4507 identifiers which would affect unsuspecting clients. The 4508 server SHOULD use a large, random and non-sequential session 4509 identifier to minimize the possibility of this kind of attack. 4511 Authentication: Servers SHOULD implement both basic and digest [6] 4512 authentication. In environments requiring tighter security for 4513 the control messages, transport layer mechanisms such as TLS 4514 (RFC 2246 [27]) SHOULD be used. 4516 Stream issues: RTSP only provides for stream control. Stream deliv- 4517 ery issues are not covered in this section, nor in the rest of 4518 this draft. RTSP implementations will most likely rely on 4519 other protocols such as RTP, IP multicast, RSVP and IGMP, and 4520 should address security considerations brought up in those and 4521 other applicable specifications. 4523 Persistently suspicious behavior: RTSP servers SHOULD return error 4524 code 403 (Forbidden) upon receiving a single instance of 4525 behavior which is deemed a security risk. RTSP servers SHOULD 4526 also be aware of attempts to probe the server for weaknesses 4527 and entry points and MAY arbitrarily disconnect and ignore 4528 further requests clients which are deemed to be in violation 4529 of local security policy. 4531 18 IANA Considerations 4533 This section set up a number of registers for RTSP that should be 4534 maintained by IANA. For each registry there is a description on what 4535 it shall contain, what specification is needed when adding a entry 4536 with IANA, and finally the entries that this document needs to regis- 4537 ter. See also the section 1.6 "Extending RTSP". There is also a IANA 4538 registration of two SDP attributes. 4540 The sections describing how to register an item uses some of the 4541 requirements level described in RFC 2434 [29], namely " First Come, 4542 First Served", "Specification Required", and "Standards Action". 4544 A registration request to IANA MUST contain the following informa- 4545 tion: 4547 + A name of the item to register according to the rules specified 4548 by the intended registry. 4550 + Indication of who has change control over the feature (for exam- 4551 ple, IETF, ISO, ITU-T, other international standardization 4552 bodies, a consortium or a particular company or group of compa- 4553 nies); 4555 + A reference to a further description, if available, for example 4556 (in order of preference) an RFC, a published standard, a pub- 4557 lished paper, a patent filing, a technical report, documented 4558 source code or a computer manual; 4560 + For proprietary features, contact information (postal and email 4561 address); 4563 18.1 Feature-tags 4565 18.1.1 Description 4567 When a client and server try to determine what part and functionality 4568 of the RTSP specification and any future extensions that its counter 4569 part implements there is need for a namespace. This registry con- 4570 tains named entries representing certain functionality. 4572 The usage of feature-tags is explained in section 10 and 11.1. 4574 18.1.2 Registering New Feature-tags with IANA 4576 The registering of feature-tags is done on a first come, first served 4577 basis. 4579 The name of the feature MUST follow these rules: The name may be of 4580 any length, but SHOULD be no more than twenty characters long. The 4581 name MUST not contain any spaces, or control characters. Any propri- 4582 etary feature SHALL have as the first part of the name a vendor tag, 4583 which identifies the organization. 4585 18.1.3 Registered entries 4587 The following feature-tags are in this specification defined and 4588 hereby registered. The change control belongs to the Authors and the 4589 IETF MMUSIC WG. 4591 play.basic: The minimal implementation for playback operations 4592 according to section D. 4594 play.scale: Support of scale operations for media playback. 4596 play.speed: Support of the speed functionality for playback. 4598 setup.playing: The use of SETUP and TEARDOWN in play state. 4600 con.persistent: Support and use of persistent connections, see 4601 chapter 9.3. 4603 18.2 RTSP Methods 4605 18.2.1 Description 4607 What a method is, is described in section 11. Extending the protocol 4608 with new methods allow for totally new functionality. 4610 18.2.2 Registering New Methods with IANA 4612 A new method MUST be registered through an IETF standard track docu- 4613 ment. The reason is that new methods may radically change the proto- 4614 cols behavior and purpose. 4616 A specification for a new RTSP method MUST consist of the following 4617 items: 4619 + A method name which follows the BNF rules for methods. 4621 + A clear specification on what action and response a request with 4622 the method will result in. Which directions the method is used, 4623 C->S or S->C or both. How the use of headers, if any, modifies 4624 the behavior and effect of the method. 4626 + A list or table specifying which of the registered headers that 4627 are allowed to use with the method in request or/and response. 4629 + Describe how the method relates to network proxies. 4631 18.2.3 Registered Entries 4633 This specification, RFCXXXX, registers 10 methods: DESCRIBE, 4634 GET_PARAMETER, OPTIONS, PAUSE, PING, PLAY, REDIRECT, SETUP, 4635 SET_PARAMETER, and TEARDOWN. 4637 18.3 RTSP Status Codes 4639 18.3.1 Description 4641 A status code is the three digit numbers used to convey information 4642 in RTSP response messages, see 7. The number space is limited and 4643 care should be taken not to fill the space. 4645 18.3.2 Registering New Status Codes with IANA 4646 A new status code can only be registered by an IETF standards track 4647 document. A specification for a new status code MUST specify the fol- 4648 lowing: 4650 + The requested number. 4652 + A description what the status code means and the expected behav- 4653 ior of the sender and receiver of the code. 4655 18.3.3 Registered Entries 4657 RFCXXX, registers the numbered status code defined in the BNF entry 4658 "Status-Code" except "extension-code" in section 7.1.1. 4660 18.4 RTSP Headers 4662 18.4.1 Description 4664 By specifying new headers a method(s) can be enhanced in many differ- 4665 ent ways. An unknown header will be ignored by the receiving entity. 4666 If the new header is vital for a certain functionality, a feature-tag 4667 for the functionality can be created and demanded to be used by the 4668 counter-part with the inclusion of a Require header carrying the fea- 4669 ture-tag. 4671 18.4.2 Registering New Headers with IANA 4673 A public available specification is required to register a header. 4674 The specification SHOULD be a standards document, preferable an IETF 4675 RFC. 4677 The specification MUST contain the following information: 4679 + The name of the header. 4681 + A BNF specification of the header syntax. 4683 + A list or table specifying when the header may be used, encom- 4684 passing all methods, their request or response, the direction 4685 (C->S or S->C). 4687 + How the header shall be handled by proxies. 4689 + A description of the purpose of the header. 4691 18.4.3 Registered entries 4692 All headers specified in section 13 in RFCXXXX are to be registered. 4694 Furthermore the following RTSP headers defined in other specifica- 4695 tions are registered: 4697 + x-wap-profile defined in [35]. 4699 + x-wap-profile-diff defined in [35]. 4701 + x-wap-profile-warning defined in [35]. 4703 + x-predecbufsize defined in [35]. 4705 + x-initpredecbufperiod defined in [35]. 4707 + x-initpostdecbufperiod defined in [35]. 4709 Note: The use of "X-" is NOT RECOMMENDED but the above headers in 4710 the register list was defined prior to the clarification. 4712 18.5 Transport Header registries 4714 The transport header contains a number of parameters which have pos- 4715 sibilities for future extensions. Therefore registries for these must 4716 be defined. 4718 18.5.1 Transport Protocols 4720 A registry for the parameter transport-protocol shall be defined with 4721 the following rules: 4723 + Registering requires public available standards specification. 4725 + A contact person or organization with address and email. 4727 + A value definition that are following the BNF token definition. 4729 + A describing text that explains how the registered value are used 4730 in RTSP. 4732 This specification register 1 value: 4734 + Use of the RTP [23] protocol for media transport. The usage is 4735 explained in RFC XXXX, appendix B.1. 4737 18.5.2 Profile 4738 A registry for the parameter profile shall be defined with the fol- 4739 lowing rules: 4741 + Registering requires public available standards specification. 4743 + A contact person or organization with address and email. 4745 + A value definition that are following the BNF token definition. 4747 + A definition of which Transport protocol(s) that this profile is 4748 valid for. 4750 + A describing text that explains how the registered value are used 4751 in RTSP. 4753 + The "RTP profile for audio and video conferences with minimal 4754 control" [1] MUST only be used when the transport headers trans- 4755 port-protocol is "RTP". 4757 18.5.3 Lower Transport 4759 A registry for the parameter lower-transport shall be defined with 4760 the following rules: 4762 + Registering requires public available standards specification. 4764 + A contact person or organization with address and email. 4766 + A value definition that are following the BNF token definition. 4768 + A describing text that explains how the registered value are used 4769 in RTSP. This includes 4771 + Indicates the use of the "User datagram protocol" [7] for media 4772 transport. 4774 + Indicates the use Transmission control protocol [9] for media 4775 transport. 4777 18.5.4 Transport modes 4779 A registry for the transport parameter mode shall be defined with the 4780 following rules: 4782 + Registering requires a IETF standard tracks document. 4784 + A contact person or organization with address and email. 4786 + A value definition that are following the BNF token definition. 4788 + A describing text that explains how the registered value are used 4789 in RTSP. 4791 + See RFC XXXX. 4793 + See RFC XXXX. 4795 18.6 Cache Directive Extensions 4797 There exist a number of cache directives which can be sent in the 4798 Cache-Control header. A registry for this cache directives shall be 4799 defined with the following rules: 4801 + Registering requires a IETF standard tracks document. 4803 + A registration shall name a contact person. 4805 + Name of the directive and a definition of the value, if any. 4807 + A describing text that explains how the cache directive is used 4808 for RTSP controlled media streams. 4810 18.7 SDP attributes 4812 This specification defines two SDP [24] attributes that it is request 4813 that IANA register. 4815 SDP Attribute ("att-field"): 4817 Attribute name: range 4818 Long form: Media Range Attribute 4819 Type of name: att-field 4820 Type of attribute: Media and session level 4821 Subject to charset: No 4822 Purpose: RFC XXXX 4823 Reference: RFC XXXX 4824 Values: See ABNF definition. 4826 Attribute name: control 4827 Long form: RTSP control URL 4828 Type of name: att-field 4829 Type of attribute: Media and session level 4830 Subject to charset: No 4831 Purpose: RFC XXXX 4832 Reference: RFC XXXX 4833 Values: Absolute or Relative URLs. 4835 A RTSP Protocol State Machine 4837 The RTSP session state machine describe the behavior of the protocol 4838 from RTSP session initialization through RTSP session termination. 4840 State machine is defined on a per session basis which is uniquely 4841 identified by the RTSP session identifier. The session may contain 4842 zero or more media streams depending on state. If a single media 4843 stream is part of the session it is in non-aggregated control. If two 4844 or more is part of the session it is in aggregated control. 4846 This state machine is one possible representation that helps explain 4847 how the protocol works and when different requests are allowed. We 4848 find it a reasonable representation but does not mandate it, and 4849 other representations can be created. 4851 A.1 States 4853 The state machine contains five states, described below. For each 4854 state there exist a table which shows which requests and events that 4855 is allowed and if they will result in a state change. 4857 Init: Initial state no session exist. 4859 Ready-nm: Ready state without any medias. 4861 Ready: Session is ready to start playing. 4863 Play: Session is playing, i.e. sending media stream data in the 4864 direction S->C. 4866 A.2 State variables 4868 This representation of the state machine needs more than its state to 4869 work. A small number of variables are also needed and is explained 4870 below. 4872 NRM: The number of media streams part of this session. 4874 RP: Resume point, the point in the presentation time line at which 4875 a request to continue will resume from. A time format for the 4876 variable is not mandated. 4878 A.3 Abbreviations 4880 To make the state tables more compact a number of abbreviations are 4881 used, which are explained below. 4883 IFI: IF Implemented. 4885 md: Media 4887 PP: Pause Point, the point in the presentation time line at which 4888 the presentation was paused. 4890 Prs: Presentation, the complete multimedia presentation. 4892 RedP: Redirect Point, the point in the presentation time line at 4893 which a REDIRECT was specified to occur. 4895 SES: Session. 4897 A.4 State Tables 4899 This section contains a table for each state. The table contains all 4900 the requests and events that this state is allowed to act on. The 4901 events which is method names are, unless noted, requests with the 4902 given method in the direction client to server (C->S). In some cases 4903 there exist one or more requisite. The response column tells what 4904 type of response actions should be performed. Possible actions that 4905 is requested for an event includes: response codes, e.g. 200, headers 4906 that MUST be included in the response, setting of state variables, or 4907 setting of other session related parameters. The new state column 4908 tells which state the state machine shall change to. 4910 The response to valid request meeting the requisites is normally a 4911 2xx (SUCCESS) unless other noted in the response column. The excep- 4912 tions shall be given a response according to the response column. If 4913 the request does not meet the requisite, is erroneous or some other 4914 type of error occur the appropriate response code MUST be sent. If 4915 the response code is a 4xx the session state is unchanged. A response | 4916 code of 3rr will result in that the session is ended and its state is | 4917 changed to Init. A response code of 304 results in no state change. | 4918 However there exist restrictions to when a 3xx | response may be 4919 used. A 5xx response SHALL not result in any change of the session 4920 state, except if the error is not possible to recover from. A unre- 4921 coverable error SHALL result the ending of the session. As it in the 4922 general case can't be determined if it was a unrecoverable error or 4923 not the client will be required to test. In the case that the next 4924 request after a 5xx is responded with 454 (Session Not Found) the 4925 client SHALL assume that the session has been ended. 4927 The server will timeout the session after the period of time speci- 4928 fied in the SETUP response, if no activity from the client is 4929 detected. Therefore there exist a timeout event for all states 4930 except Init. 4932 In the case that NRM=1 the presentation URL is equal to the media 4933 URL. For NRM>1 the presentation URL MUST be other than any of the 4934 medias that are part of the session. This applies to all states. 4936 Event Prerequisite Response 4937 --------------------------------------------------------------- 4938 DESCRIBE Needs REDIRECT 3rr Redirect 4939 DESCRIBE 200, Session description 4940 OPTIONS Session ID 200, Reset session timeout timer 4941 OPTIONS 200 4942 SET_PARAMETER Valid parameter 200, change value of parameter 4943 GET_PARAMETER Valid parameter 200, return value of parameter 4945 Table 6: None state-machine changing events 4947 The methods in Table 6 do not have any effect on the state machine or 4948 the state variables. However some methods do change other session 4949 related parameters, for example SET_PARAMETER which will set the 4950 parameter(s) specified in its body. 4952 Action Requisite New State Response 4953 ------------------------------------------------- 4954 SETUP Ready NRM=1, RP=0.0 4955 SETUP Needs Redirect Init 3rr Redirect 4957 Table 7: State: Init 4959 The initial state of the state machine, see Table 7 can only be left 4960 by processing a correct SETUP request. As seen in the table the two 4961 state variables are also set by a correct request. This table also 4962 shows that a correct SETUP can in some cases be redirected to another 4963 URL and/or server by a 3rr response. 4965 Action Requisite New State Response 4966 -------------------------------------------------------------- 4967 SETUP Ready NRM=1,RP=0.0 4968 SETUP Needs Redirect Init 3rr 4969 TEARDOWN URL=* Init No session hdr. 4970 Timeout Init 4971 S->C:REDIRECT Range hdr Ready-nm Set RedP 4972 S->C:REDIRECT no range hdr Ready-nm TEARDOWN of session 4973 RedP reached Ready-nm TEARDOWN of session 4975 Table 8: State: Ready-nm 4977 The optional Ready-nm state has no media streams and therefore can't | 4978 play. This state exist so that all session related parameters and | 4979 resources can be kept while changing media stream(s). As seen in | 4980 Table 8 the operations are limited to setting up a new media or tear- | 4981 ing down the session. The established session can also be redirected | 4982 with the REDIRECT method. 4984 Action Requisite New State Response 4985 --------------------------------------------------------------------- 4986 SETUP New URL Ready NRM+=1 4987 SETUP Setten up URL Ready Change transport param. 4988 TEARDOWN URL=* Init No session hdr 4989 TEARDOWN Prs URL,NRM>1 Init No session hdr 4990 TEARDOWN md URL,NRM=1IFI Ready-nm Session hdr, NRM=0 4991 TEARDOWN md URL,NRM=1 Init No Session hdr, NRM=0 4992 TEARDOWN md URL,NRM>1 Ready Session hdr, NRM-=1 4993 PLAY Prs URL, No range Play Play from RP 4994 PLAY Prs URL, Range Play according to range 4995 S->C:REDIRECT Range hdr Ready Set RedP 4996 S->C:REDIRECT no range hdr Ready TEARDOWN of session 4997 Timeout Init 4998 RedP reached Ready TEARDOWN of session 5000 Table 9: State: Ready 5002 In the Ready state, see Table 9, some of the actions are depending on 5003 the number of media streams (NRM) in the session, i.e. aggregated or 5004 non-aggregated control. A setup request in the ready state can either 5005 add one more media stream to the session or if the media stream (same 5006 URL) already is part of the session change the transport parameters. 5007 TEARDOWN is depending on both the request URI and the number of media 5008 stream within the session. If the request URI is either * or the pre- 5009 sentations URI the whole session is torn down. If a media URL is used 5010 in the TEARDOWN request and more than one media exist in the session, 5011 the session will remain and a session header MUST be returned in the 5012 response. If only a single media stream remains in the session when 5013 performing a TEARDOWN with a media URL , it is optional to keep the 5014 session. If the session still exist after the request a Session MUST 5015 be returned in the response. The number of media streams remaining 5016 after tearing down a media stream determines the new state. 5018 Action Requisite New State Response 5019 ------------------------------------------------------------------------ 5020 PAUSE PrsURL,No range Ready Set RP to present point 5021 PAUSE PrsURL,Range>now Play Set RP & PP to given point 5022 PAUSE PrsURL,Range<=now Ready Set RP to Range Hdr. 5023 PP reached Ready RP = PP 5024 End of media All media Play No action, RP = Invalid 5025 End of media >=1 Media plays Play No action 5026 End of range Play Set RP = End of range 5027 SETUP New URL,IFI Play NRM+=1, 200, *A 5028 SETUP New URL Play 455 5029 SETUP Setuped URL Play 455 5030 SETUP Setuped URL, IFI Play Change transport param. 5031 TEARDOWN URL=* Init No session hdr 5032 TEARDOWN Prs URL,NRM>1 Init No session hdr 5033 TEARDOWN md URL,NRM=1,IFI Ready-nm Session hdr 5034 TEARDOWN md URL,NRM>1,IFI Play Session hdr 5035 TEARDOWN md URL Play 455 5036 S->C:REDIRECT Range hdr Play Set RedP 5037 S->C:REDIRECT no range hdr Play TEARDOWN of session 5038 RedP reached Play TEARDOWN of session 5039 Timeout Init Stop Media playout 5041 Table 10: State: Play, *A: RTP-Info and Range header 5043 The Play state table, see Table 10, is the largest. The table con- 5044 tains an number of request that has presentation URL as a prerequi- 5045 site on the request URL, this is due to the exclusion of non-aggre- 5046 gated stream control in sessions with more than one media stream. 5048 To avoid inconsistencies between the client and server, automatic 5049 state transitions are avoided. This can be seen at for example "End 5050 of media" event when all media has finished playing, the session 5051 still remain in Play state. An explicit PAUSE request must be sent to 5052 change the state to Ready. It may appear that there exist two auto- 5053 matic transitions in "RedP reached" and "PP reached", however they 5054 are requested and acknowledge before they take place. The time at 5055 which the transition will happen is known by looking at the range 5056 header. If the client sends request close in time to these transi- 5057 tions it must be prepared for getting error message as the state may 5058 or may not have changed. 5060 SETUP and TEARDOWN requests with media URLs in aggregated sessions 5061 may not be handled by the server as it is optional functionality. Use 5062 the service discovery mechanism with OPTIONS to find out in before- 5063 hand if the server implements it. If the functionality is not imple- 5064 mented but still tried by the client a "501 Not Implemented" response 5065 SHALL be received. 5067 B Media Transport Alternatives 5069 This chapter defines how certain combinations of protocols, profiles | 5070 and lower transports are used. This includes the usage of the Trans- | 5071 port header's general source and destination parameters | 5072 "src_addresses" and "dst_addresses". | 5074 B.1 RTP | 5076 This section defines the interaction and needed media transport sig- | 5077 nalling in regards to the RTP protocol [23]. | 5079 RTSP allows media clients to control selected, non-contiguous sec- | 5080 tions of media presentations, rendering those streams with an RTP | 5081 media layer[23]. The media layer rendering the RTP stream should not | 5082 be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP | 5083 timestamps MUST be continuous and monotonic across jumps of NPT. | 5085 As an example, assume a clock frequency of 8000 Hz, a packetization | 5086 interval of 100 ms and an initial sequence number and timestamp of | 5087 zero. First we play NPT 10 through 15, then skip ahead and play NPT | 5088 18 through 20. The first segment is presented as RTP packets with | 5089 sequence numbers 0 through 49 and timestamp 0 through 39,200. The | 5090 second segment consists of RTP packets with sequence number 50 | 5091 through 69, with timestamps 40,000 through 55,200. | 5093 We cannot assume that the RTSP client can communicate with the | 5094 RTP media agent, as the two may be independent processes. If | 5095 the RTP timestamp shows the same gap as the NPT, the media | 5096 agent will assume that there is a pause in the presentation. | 5097 If the jump in NPT is large enough, the RTP timestamp may roll | 5098 over and the media agent may believe later packets to be | 5099 duplicates of packets just played out. | 5101 For certain datatypes, tight integration between the RTSP layer and | 5102 the RTP layer will be necessary. This by no means precludes the above | 5103 restriction. Combined RTSP/RTP media clients should use the RTP-Info | 5104 field to determine whether incoming RTP packets were sent before or | 5105 after a seek. | 5107 For continuous audio, the server SHOULD set the RTP marker bit at the | 5108 beginning of serving a new PLAY request. This allows the client to | 5109 perform playout delay adaptation. | 5111 For scaling (see Section 13.34), RTP timestamps should correspond to | 5112 the playback timing. For example, when playing video recorded at 30 | 5113 frames/second at a scale of two and speed (Section 13.35) of one, the | 5114 server would drop every second frame to maintain and deliver video | 5115 packets with the normal timestamp spacing of 3,000 per frame, but NPT | 5116 would increase by 1/15 second for each video frame. | 5118 The client can maintain a correct display of NPT by noting the RTP | 5119 timestamp value of the first packet arriving after repositioning. | 5120 The sequence parameter of the RTP-Info (Section 13.33) header pro- | 5121 vides the first sequence number of the next segment. | 5123 Below the available RTP profiles and lower layer transports are given | 5124 together with the necessary rules on how to signal that combination. | 5126 B.1.1 AVP | 5128 The usage of the "RTP Profile for Audio and Video Conferences with | 5129 Minimal Control" [1] when using RTP for media transport over differ- | 5130 ent lower layer transport protocols are defined below in regards to | 5131 RTSP. | 5133 On such case is defined within this document, the use of embedded | 5134 (interleaved) binary data as defined in section 11.11. The usage of | 5135 this method is indicated by include the "interleaved" parameter. | 5137 When using embedded binary data the "src_addresses" and | 5138 "dst_addresses" SHALL NOT be used. This addressing and multiplexing | 5139 is used as defined with use of channel numbers and the interleaved | 5140 parameter. | 5142 B.1.2 AVP/UDP | 5143 This part descibes sending of RTP [23] over lower transport layer UDP | 5144 [7] according to the profile "RTP Profile for Audio and Video Confer- | 5145 ences with Minimal Control" defined in RFC 1890 [1]. | 5147 This profiles requires that one or two uni- or bi-directional UDP | 5148 flows per media stream. The first UDP flow is for RTP and the second | 5149 is for RTCP. Embedded (interleaved) data when RTSP messages is trans- | 5150 ported over UDP SHOULD NOT be performed. | 5152 The RTP/UDP and RTCP/UDP flows can be established in two ways using | 5153 the Transport header's parameters. The way provided in RFC 2326 was | 5154 to use the necessary parameters from the set of "source", "destina- | 5155 tion", "client_port", and "server_port". This has the advantage of | 5156 being compatible with all RTP capable RTSP servers and clients. How- | 5157 ever this method does not provide a possibility to specify non-con- | 5158 tinues port ranges for RTP and RTCP. The other way is to use the | 5159 parameters "src_addresses", and "dst_addresses". This method provides | 5160 total flexibility in specifying address and port number for each | 5161 transport flow. However the disadvantage is that it is not supported | 5162 by non-updated clients, i.e. clients not supporting the "play.basic" | 5163 feature-tag. | 5165 When using the "source", "destination", "client_port", and | 5166 "server_port" the packets are be addressed in the following way for | 5167 media playback: | 5169 + RTP/UDP packet from the server to the client SHALL be sent to the | 5170 address specified in the "destination" parameter and first even | 5171 port number given in client_port range. If there is only a single | 5172 port number given that MUST be given. | 5174 + The server SHOULD send its RTP/UDP packets from the address spec- | 5175 ified in "source" parameter and from the first even port number | 5176 specified in "server_port" parameter. | 5178 + If there is specified a range in "client_port" parameter that | 5179 contains at least two port numbers, the RTCP/UDP packets from | 5180 server to client SHALL be sent to address specified in the "des- | 5181 tination" parameter and first odd port number part of the range | 5182 specified in the client_port parameter. | 5184 + The Server SHOULD send its RTCP/UDP packets from the address | 5185 specified in "source" parameter and from the first odd port num- | 5186 ber specified in "server_port" parameter. | 5188 + RTCP/UDP packets from the client to the server SHALL be sent to | 5189 the address specified in the "source" parameter and first odd | 5190 port number given in client_port range. | 5192 + The client SHOULD send its RTCP/UDP packets from the address | 5193 specified in "destination" parameter and from the first odd port | 5194 number specified in "server_port" parameter. | 5196 The usage of "src_addresses" and "dst_addresses" parameters to spec- | 5197 ify the address and port numbers are done in the following way for | 5198 media playback, i.e. Mode=PLAY: | 5200 + The "src_addresses" and "dst_addresses" parameters MUST contain | 5201 either 1 or 2 address and port pairs. | 5203 + Each address and port pair MUST contain both and address and a | 5204 port number. | 5206 + The first address and port pair given in either of the parameters | 5207 applies to the RTP stream. The second address and port pair if | 5208 present applies to the RTCP stream. | 5210 + The RTP/UDP packets from the server to the client SHALL be sent | 5211 to the address and port given by first address and port pair of | 5212 the "dst_addresses" parameter. | 5214 + The RTCP/UDP packets from the server to the client SHALL be sent | 5215 to the address and port given by the second address and port pair | 5216 of the "dst_addresses" parameter. If no second pair is given RTCP | 5217 SHALL NOT be sent. | 5219 + The RTCP/UDP packets from the client to the server SHALL be sent | 5220 to the address and port given by the second address and port pair | 5221 of the "dst_addresses" parameter. If no second pair is given RTCP | 5222 SHALL NOT be sent. | 5224 + RTP and RTCP Packets SHOULD be sent from the corresponding | 5225 receiver port, i.e. RTCP packets from server should be sent from | 5226 the "src_addresses" parameters second address port pair. | 5228 B.1.3 AVP/TCP | 5230 Note that this combination is not yet defined using sperate TCP con- | 5231 nections. However the use of embedded (interleaved) binary data | 5232 transported on the RTSP connection is possible as specified in sec- | 5233 tion 11.11. When using this declared combination of interleaved | 5234 binary data the RTSP messages MUST be transported over TCP. | 5236 A possible future for this profile would be to define the use of a | 5237 combination of the two drafts "Connection-Oriented Media Transport in | 5238 SDP" [36] and "Framing RTP and RTCP Packets over Connection-Oriented | 5239 Transport" [37]. | 5241 B.2 Future Additions | 5243 It is the intention that any future protocol or profile regarding | 5244 both for media delivery and lower transport should be easy to add to | 5245 RTSP. This chapter provides the necessary steps that needs to be | 5246 meet. | 5248 The following things needs to be considered when adding a new proto- | 5249 col of profile for use with RTSP: | 5251 + The protocol or profile needs to define a name tag representing | 5252 it. This tag is required to be a ABNF "token" to be possible to | 5253 use in the Transport header specification. | 5255 + The useful combinations of protocol/profile/lower-layer needs to | 5256 be defined and for each combination declare the necessary parame- | 5257 ters to use in the Transport header. | 5259 + For new media protocols the interaction with RTSP needs to be | 5260 addressed. One important factor will be the media synchroniza- | 5261 tion. | 5263 See the IANA section ( 18) on how to register the necessary | 5264 attributes. | 5266 C Use of SDP for RTSP Session Descriptions 5268 The Session Description Protocol (SDP, RFC 2327 [24]) may be used to 5269 describe streams or presentations in RTSP. This description is typi- 5270 cally returned in reply to a DESCRIBE request on a URL from a server 5271 to a client, received via HTTP from a server to a client. 5273 This appendix describes how an SDP file determines the operation of 5274 an RTSP session. SDP provides no mechanism by which a client can 5275 distinguish, without human guidance, between several media streams to 5276 be rendered simultaneously and a set of alternatives (e.g., two audio 5277 streams spoken in different languages). 5279 C.1 Definitions 5281 The terms "session-level", "media-level" and other key/attribute 5282 names and values used in this appendix are to be used as defined in 5283 SDP (RFC 2327 [24]): 5285 C.1.1 Control URL 5286 The "a=control:" attribute is used to convey the control URL. This 5287 attribute is used both for the session and media descriptions. If 5288 used for individual media, it indicates the URL to be used for con- 5289 trolling that particular media stream. If found at the session level, 5290 the attribute indicates the URL for aggregate control. 5292 control-attribute = "a=" "control" ":" url 5294 Example: 5296 a=control:rtsp://example.com/foo 5298 This attribute MAY contain either relative and absolute URLs, follow- | 5299 ing the rules and conventions set out in RFC 2396 [22]. Implementa- | 5300 tions SHALL look for a base URL in the following order: | 5302 1. the RTSP Content-Base field; | 5304 2. the RTSP Content-Location field; | 5306 3. the RTSP request URL. | 5308 If this attribute contains only an asterisk (*), then the URL is 5309 treated as if it were an empty embedded URL, and thus inherits the 5310 entire base URL. 5312 For SDP retrieved from a container file, there are certain things to 5313 consider. Lets say that the container file has the following URL: 5314 "rtsp://example.com/container.mp4". A media level relative URL needs 5315 to contain the file name container.mp4 in the beginning to be 5316 resolved correctly relative to the before given URL. An alternative 5317 if one does not desire to enter the container files name is to ensure 5318 that the base URL for the SDP document becomes: "rtsp://exam- 5319 ple.com/container.mp4/", i.e. an extra trailing slash. When using 5320 the URL resolution rules in RFC 2396 that will resolve correctly. 5321 However as a warning if the session level control URL is a * that 5322 control URL will be equal to "rtsp://example.com/container.mp4/" and 5323 include the slash. 5325 C.1.2 Media Streams 5327 The "m=" field is used to enumerate the streams. It is expected that 5328 all the specified streams will be rendered with appropriate 5329 synchronization. If the session is unicast, the port number serves as 5330 a recommendation from the server to the client; the client still has 5331 to include it in its SETUP request and may ignore this recommenda- 5332 tion. If the server has no preference, it SHOULD set the port number 5333 value to zero. 5335 Example: 5337 m=audio 0 RTP/AVP 31 5339 C.1.3 Payload Type(s) 5341 The payload type(s) are specified in the "m=" field. In case the pay- 5342 load type is a static payload type from RFC 1890 [1], no other infor- 5343 mation is required. In case it is a dynamic payload type, the media 5344 attribute "rtpmap" is used to specify what the media is. The "encod- 5345 ing name" within the "rtpmap" attribute may be one of those specified 5346 in RFC 1890 (Sections 5 and 6), or an MIME type registered with IANA, 5347 or an experimental encoding with a "X-" prefix as specified in SDP 5348 (RFC 2327 [24]). Codec-specific parameters are not specified in this 5349 field, but rather in the "fmtp" attribute described below. Implemen- 5350 tors seeking to register new encodings should follow the procedure in 5351 RFC 1890 [1]. If the media type is not suited to the RTP AV profile, 5352 then it is recommended that a new profile be created and the appro- 5353 priate profile name be used in lieu of "RTP/AVP" in the "m=" field. 5355 C.1.4 Format-Specific Parameters 5357 Format-specific parameters are conveyed using the "fmtp" media 5358 attribute. The syntax of the "fmtp" attribute is specific to the 5359 encoding(s) that the attribute refers to. Note that the packetization 5360 interval is conveyed using the "ptime" attribute. 5362 C.1.5 Range of Presentation 5364 The "a=range" attribute defines the total time range of the stored | 5365 session. (The length of live sessions can be deduced from the "t" and | 5366 "r" parameters.) The attribute is a session and media level | 5367 attribute. For presentations that contains media streams of the same | 5368 durations, the range attribute SHOULD only be used at session-level. | 5369 In case of different length the range attribute MUST be given at | 5370 media level for all media. The unit is specified first, followed by | 5371 the value range. The units and their values are as defined in Section | 5372 3.4, 3.5 and 3.6. The range attribute SHOULD NOT be present for live | 5373 media streams. | 5374 This attribute is defined in ABNF [14] as: | 5376 a-range-def = "a" "=" "range" ":" ranges-specifier CRLF || 5378 Examples: 5380 a=range:npt=0-34.4368 5381 a=range:clock=19971113T2115-19971113T2203 5383 C.1.6 Time of Availability 5385 The "t=" field MUST contain suitable values for the start and stop 5386 times for both aggregate and non-aggregate stream control. With 5387 aggregate control, the server SHOULD indicate a stop time value for 5388 which it guarantees the description to be valid, and a start time 5389 that is equal to or before the time at which the DESCRIBE request was 5390 received. It MAY also indicate start and stop times of 0, meaning 5391 that the session is always available. With non-aggregate control, the 5392 values should reflect the actual period for which the session is 5393 available in keeping with SDP semantics, and not depend on other 5394 means (such as the life of the web page containing the description) 5395 for this purpose. 5397 C.1.7 Connection Information 5399 In SDP, the "c=" field contains the destination address for the media 5400 stream. However, for on-demand unicast streams and some multicast 5401 streams, the destination address is specified by the client via the 5402 SETUP request. Unless the media content has a fixed destination 5403 address, the "c=" field is to be set to a suitable null value. For 5404 addresses of type "IP4", this value is "0.0.0.0". 5406 C.1.8 Entity Tag 5408 The optional "a=etag" attribute identifies a version of the session 5409 description. It is opaque to the client. SETUP requests may include 5410 this identifier in the If-Match field (see section 13.22) to only 5411 allow session establishment if this attribute value still corresponds 5412 to that of the current description. The attribute value is opaque 5413 and may contain any character allowed within SDP attribute values. 5415 Example: 5417 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 5418 One could argue that the "o=" field provides identical func- 5419 tionality. However, it does so in a manner that would put con- 5420 straints on servers that need to support multiple session 5421 description types other than SDP for the same piece of media 5422 content. 5424 C.2 Aggregate Control Not Available 5426 If a presentation does not support aggregate control and multiple 5427 media sections are specified, each section MUST have the control URL 5428 specified via the "a=control:" attribute. 5430 Example: 5432 v=0 5433 o=- 2890844256 2890842807 IN IP4 204.34.34.32 5434 s=I came from a web page 5435 e=adm@example.com 5436 c=IN IP4 0.0.0.0 5437 t=0 0 5438 m=video 8002 RTP/AVP 31 5439 a=control:rtsp://audio.com/movie.aud 5440 m=audio 8004 RTP/AVP 3 5441 a=control:rtsp://video.com/movie.vid 5443 Note that the position of the control URL in the description implies 5444 that the client establishes separate RTSP control sessions to the 5445 servers audio.com and video.com 5447 It is recommended that an SDP file contains the complete media ini- 5448 tialization information even if it is delivered to the media client 5449 through non-RTSP means. This is necessary as there is no mechanism to 5450 indicate that the client should request more detailed media stream 5451 information via DESCRIBE. 5453 C.3 Aggregate Control Available 5455 In this scenario, the server has multiple streams that can be con- 5456 trolled as a whole. In this case, there are both a media-level 5457 "a=control:" attributes, which are used to specify the stream URLs, 5458 and a session-level "a=control:" attribute which is used as the 5459 request URL for aggregate control. If the media-level URL is rela- 5460 tive, it is resolved to absolute URLs according to Section C.1.1 5461 above. 5463 If the presentation comprises only a single stream, the media-level 5464 "a=control:" attribute may be omitted altogether. However, if the 5465 presentation contains more than one stream, each media stream section 5466 MUST contain its own "a=control" attribute. 5468 Example: 5470 v=0 5471 o=- 2890844256 2890842807 IN IP4 204.34.34.32 5472 s=I contain 5473 i= 5474 e=adm@example.com 5475 c=IN IP4 0.0.0.0 5476 t=0 0 5477 a=control:rtsp://example.com/movie/ 5478 m=video 8002 RTP/AVP 31 5479 a=control:trackID=1 5480 m=audio 8004 RTP/AVP 3 5481 a=control:trackID=2 5483 In this example, the client is required to establish a single RTSP 5484 session to the server, and uses the URLs rtsp://exam- 5485 ple.com/movie/trackID=1 and rtsp://example.com/movie/trackID=2 to set 5486 up the video and audio streams, respectively. The URL rtsp://exam- 5487 ple.com/movie/ controls the whole movie. 5489 A client is not required to issues SETUP requests for all streams 5490 within an aggregate object. Servers SHOULD allow the client to ask 5491 for only a subset of the streams. 5493 D Minimal RTSP implementation 5495 D.1 Client 5497 A client implementation MUST be able to do the following : | 5499 + Generate the following requests: SETUP, TEARDOWN, PLAY. | 5501 + Include the following headers in requests: CSeq, Connection, Ses- | 5502 sion, Transport. | 5504 + Parse and understand the following headers in responses: CSeq, | 5505 Connection, Session, Transport, Content-Language, Content-Encod- | 5506 ing, Content-Length, Content-Type. | 5508 + Understand the class of each error code received and notify the | 5509 end-user, if one is present, of error codes in classes 4xx and | 5510 5xx. The notification requirement may be relaxed if the end-user | 5511 explicitly does not want it for one or all status codes. | 5513 + Expect and respond to asynchronous requests from the server, such | 5514 as REDIRECT. This does not necessarily mean that it should imple- | 5515 ment the REDIRECT method, merely that it MUST respond positively | 5516 or negatively to any request received from the server. | 5518 Though not required, the following are RECOMMENDED. 5520 + Implement RTP/AVP/UDP as a valid transport. 5522 + Inclusion of the User-Agent header. 5524 + Understand SDP session descriptions as defined in Appendix C 5526 + Accept media initialization formats (such as SDP) from standard 5527 input, command line, or other means appropriate to the operating 5528 environment to act as a "helper application" for other applica- 5529 tions (such as web browsers). 5531 There may be RTSP applications different from those initially 5532 envisioned by the contributors to the RTSP specification for 5533 which the requirements above do not make sense. Therefore, the 5534 recommendations above serve only as guidelines instead of 5535 strict requirements. 5537 D.1.1 Basic Playback 5539 To support on-demand playback of media streams, the client MUST addi- 5540 tionally be able to do the following: 5542 + generate the PAUSE request; 5544 + implement the REDIRECT method, and the Location header. 5546 D.1.2 Authentication-enabled 5548 In order to access media presentations from RTSP servers that require 5549 authentication, the client MUST additionally be able to do the fol- 5550 lowing: 5552 + recognize the 401 (Unauthorized) status code; 5553 + parse and include the WWW-Authenticate header; 5555 + implement Basic Authentication and Digest Authentication. 5557 D.2 Server 5559 A minimal server implementation MUST be able to do the following: | 5561 + Implement the following methods: SETUP, TEARDOWN, OPTIONS and | 5562 PLAY. | 5564 + Include the following headers in responses: Connection, Content- | 5565 Length, Content-Type, Content-Language, Content-Encoding, Times- | 5566 tamp, Transport, Public, and Via, and Unsupported. RTP-compliant | 5567 implementations MUST also implement the RTP-Info field. | 5569 + Parse and respond appropriately to the following headers in | 5570 requests: Connection, Proxy-Require, Session, Transport, and | 5571 Require. | 5573 Though not required, the following are highly recommended at the time 5574 of publication for practical interoperability with initial implemen- 5575 tations and/or to be a "good citizen". 5577 + Implement RTP/AVP/UDP as a valid transport. 5579 + Inclusion of the Server header. 5581 + Implement the DESCRIBE method. 5583 + Generate SDP session descriptions as defined in Appendix C 5585 There may be RTSP applications different from those initially 5586 envisioned by the contributors to the RTSP specification for 5587 which the requirements above do not make sense. Therefore, the 5588 recommendations above serve only as guidelines instead of 5589 strict requirements. 5591 D.2.1 Basic Playback 5593 To support on-demand playback of media streams, the server MUST addi- 5594 tionally be able to do the following: 5596 + Recognize the Range header, and return an error if seeking is not 5597 supported. 5599 + Implement the PAUSE method. 5601 In addition, in order to support commonly-accepted user interface 5602 features, the following are highly recommended for on-demand media 5603 servers: 5605 + Include and parse the Range header, with NPT units. Implementa- 5606 tion of SMPTE units is recommended. 5608 + Include the length of the media presentation in the media ini- 5609 tialization information. 5611 + Include mappings from data-specific timestamps to NPT. When RTP 5612 is used, the rtptime portion of the RTP-Info field may be used to 5613 map RTP timestamps to NPT. 5615 Client implementations may use the presence of length informa- 5616 tion to determine if the clip is seekable, and visably disable 5617 seeking features for clips for which the length information is 5618 unavailable. A common use of the presentation length is to 5619 implement a "slider bar" which serves as both a progress indi- 5620 cator and a timeline positioning tool. 5622 Mappings from RTP timestamps to NPT are necessary to ensure correct 5623 positioning of the slider bar. 5625 D.2.2 Authentication-enabled 5627 In order to correctly handle client authentication, the server MUST 5628 additionally be able to do the following: 5630 + Generate the 401 (Unauthorized) status code when authentication 5631 is required for the resource. 5633 + Parse and include the WWW-Authenticate header 5635 + Implement Basic Authentication and Digest Authentication 5637 E Open Issues 5639 1. Should we add the header Accept-Ranges as proposed in this 5640 specification? 5642 2. Upon receiving a response on a REDIRECT request can the server 5643 close the session or should it wait for a TEARDOWN request 5644 from the client? 5646 3. The proxy indications in the two header tables in chapter 13 5647 needs review. 5649 4. Should the Allow header be possible to use optional in request 5650 or responses besides the now specified 405 error code? 5652 5. What text should be written on use of authorization in this 5653 spec? 5655 6. How does entity tags relate to the If-Match header? The usage 5656 in SDP must also be clarified related to syntax, etc. 5658 7. Should the Last-Modified header be required on other level 5659 than optional? 5661 8. How to handle range headers for negative scale playback. 5663 9. The minimal implementation must be looked over to see if it 5664 complies with the specification. All must and should shall be 5665 included in the minimal. Feature-tags for these needs to be 5666 defined. Further feature-tags needs to be discussed. 5668 10. The list specifying which status codes are allowed on which 5669 request methods seem to be in error and need review. 5671 F Changes 5673 Compared to RFC 2326, the following issues are addressed: 5675 + http://rtsp.org/bug448521 - "URLs in Rtp-Info need to be quoted". 5676 URLs in RTP-info header now MAY be quoted if needed. 5678 + http://rtsp.org/bug448525 - Syntax for SSRC should be clarified. 5679 Require 8*8 HEX and corresponding text added. 5681 + http://rtsp.org/bug461083 - "Body w/o Content-Length clarifica- 5682 tion". This is clarified and any message with a message body is 5683 required to have a Content-Length header. 5685 + http://rtsp.org/bug477407 - Transport BNF doesn't properly deal 5686 with semicolon and comma 5688 + http://rtsp.org/bug477413 - Transport BNF: mode parameter issues 5690 + http://rtsp.org/bug477416 - "BNF error section 3.6 NPT", Added an 5691 optional [NPT] definition. Fixed so that the same possibilities 5692 exist for all time formats. 5694 + http://rtsp.org/bug477421 - "When to send response". A clarifying 5695 note in the status code chapter that when sending 400 responses, 5696 the server MUST NOT add cseq if missing. 5698 + http://rtsp.org/bug507347 - Removal of destination redirection in 5699 the transport header. 5701 + http://rtsp.org/bug477404 - "Errors in table in chapter 12". The 5702 table has been updated using the SIP structure. However the table 5703 become to big to fit in a single page and has been split. 5705 + http://rtsp.org/bug477419 - Updating HTTP references to rfc2616 5706 by adding public, and content-base header. Section references in 5707 header chapter updated. Known effects on RTSP due to HTTP clari- 5708 fications: 5710 - Content-Encoding header can include encoding of type "iden- 5711 tity". 5713 + http://rtsp.org/bug500803 - Rewritten the complete chapter on the 5714 state machine. 5716 + http://rtsp.org/bug513753 - Created a IANA section defining four 5717 registries. 5719 + http://rtsp.org/bug477427 - A new subsection in the connections 5720 chapter clarifying how the server and client may handle transport 5721 connections. Includes defining a feature-tag. 5723 + - Accept-Ranges response header is added. This header clarifies 5724 which range formats that can be used for a resource. 5726 + - Added Headers Timestamp, Via, Unsupported as required for a 5727 minimal server implementation. 5729 + http://rtsp.org/bug477425 - "Inconsistency between timeformats". 5730 Fixed so that all formats has the same capabilities as NPT. 5732 + http://rtsp.org/bug499573 - "Incorrect grammar on Server header". 5733 Added corrected BNF for User-Agent and Server header as a comple- 5734 ment to the reference. 5736 + The definition in the introduction of the RTSP session has been 5737 changed. 5739 + Updated RTSP URL's and source and destination parameters in the 5740 transport header to handle IPv6 addresses. 5742 + All BNF definitions are updated according to the rules defined in 5743 RFC 2234 [14]. 5745 + The use of status code 303 "See Other" has been decapitated as it 5746 does not make sense to use in RTSP. 5748 + Added status code 350, 351 and updated usage of the other redi- 5749 rect status codes, see chapter 12.3. 5751 + Removed Queued play (http://rtsp.org/bug508211) and decapitated 5752 use of PLAY for keep-alive while in playing state. 5754 + Explicitly wrote out the possibilities to use multiple ranges to 5755 allow for editing. 5757 + Text specifying the special behavior of PLAY for live content. 5759 + When sending response 451 and 458 the response body should con- 5760 tain the offending parameters. 5762 + Fixed the missing definitions for the Cache-Control header. Also 5763 added to the syntax definition the missing delta-seconds for max- 5764 stale and min-fresh parameters. 5766 + Added wording on the usage of Connection:Close for RTSP. 5768 + Put requirement on CSeq header that the value is increased by one 5769 for each new RTSP request. 5771 + Added requirement that the Date header must be used for all mes- 5772 sages with entity. Also the Server should always include it. 5774 + Removed possibility to use Range header combined with Scale 5775 header to indicate when it shall be activated, due to that it 5776 can't work as defined. Also added rule that lack of scale header 5777 in response indicate lack of support. Feature-tags for scaled 5778 playback defined. 5780 + The Speed header must now be responded to indicate support and 5781 the actual speed going to be used. A feature-tag is defined. 5782 Notes on congestion control was also added. 5784 + The Supported header was borrowed from SIP to help with the fea- 5785 ture negotiation in RTSP. 5787 + Clarified that the timestamp header can be used to resolve 5788 retransmission ambiguities. 5790 + Added two transport header parameters to be used to signal RTCP 5791 port for server and client when not assigned in pairs. Shall be 5792 used for NAT traversal with mechanisms like STUN. The interoper- 5793 ability issue is solved by requiring a client to know that a 5794 server supports this specification. 5796 + Defined a IANA registries for the transport headers parameters, 5797 transport-protocol, profile, lower-transport, and mode. 5799 + The OPTIONS method has been clarified on how to use the Public 5800 and Allow headers. 5802 + The Session header text has been expanded with a explanation on 5803 keep alive and which methods to use. 5805 + http://rtsp.org/bug503949 - Range header format for PAUSE is 5806 unclear. This has been resolved by requiring a ranged pause to 5807 only contain a single value as a beginning of an open range. 5809 + Servers may optional implement SETUP and TEARDOWN of a single 5810 media while in PLAY state. This is signaled using an feature-tag 5811 (play.setup). 5813 + The transport headers interleave parameter's text was made more 5814 strict and use formal requirements levels. However no change on 5815 how it is used was made. 5817 + Added a fragment part to the RTSP URL. This seem to be indicated 5818 by the note below the definition however it was not part of the 5819 BNF. 5821 + The RECORD and ANNOUNCE methods are removed as they are lacking 5822 implementation and not considered necessary in the core specifi- 5823 cation. Any work on these methods should be done as a extension 5824 document to RTSP. 5826 + The description on how rtspu and rtsps is not part of the core 5827 specification and will require external description. 5829 + The Transport headers RTP port parameters has been updated to 5830 support non-continuous port numbers. Also a possibility for the 5831 client to specify SSRC has been added. 5833 + Clarified that RTP-Info URLs that are relative uses the request 5834 URL as base URL. Also clarified that the URL that must be used is 5835 the SETUP. 5837 + Included two new general address parameters "src_addresses" and 5838 "dst_addresses" to be used to give address source and destination 5839 of media traffic. 5841 + Updated the text on the transport headers "destination" parameter 5842 regarding what security precautions the server shall perform. 5844 + Wrote a new chapter about how to setup different media transport 5845 alternatives and their profiles, and lower layer protocols. This 5846 resulted that the appendix on RTP interaction was moved there 5847 instead in the part describing RTP. The chapter also includes 5848 guidelines what to think of when writing usage guidelines for new 5849 protocols and profiles. 5851 + The embedded (interleaved) binary data and its transport parame- 5852 ter was clarified to being symmetric and that it is the server 5853 that sets the channel numbers. 5855 + Added a new chapter describing the available mechanisms to deter- 5856 mine if functionality is supported, called "Capability Handling". 5857 Renamed option-tags to feature-tags. 5859 + Added a contributors chapter with people who has contribute 5860 actual text to the specification. 5862 + Added text that requires the Range to always be present in PLAY 5863 responses. Clarified what should be sent in case of live streams. 5865 Note that this list does not reflect minor changes in wording or cor- 5866 rection of typographical errors. 5868 A word-by-word diff from RFC 2326 can be found at 5869 http://rtsp.org/2002/drafts 5871 G Author Addresses 5873 Henning Schulzrinne 5874 Dept. of Computer Science 5875 Columbia University 5876 1214 Amsterdam Avenue 5877 New York, NY 10027 5878 USA 5879 electronic mail: schulzrinne@cs.columbia.edu 5881 Anup Rao 5882 Cisco 5883 USA 5884 electronic mail: anrao@cisco.com 5885 Robert Lanphier 5886 RealNetworks 5887 P.O. Box 91123 5888 Seattle, WA 98111-9223 5889 USA 5890 electronic mail: robla@real.com 5892 Magnus Westerlund 5893 Ericsson AB, ERA/TVA/A 5894 Torshamsgatan 23 5895 SE-164 80 STOCKHOLM 5896 SWEDEN 5897 electronic mail: magnus.westerlund@ericsson.com 5899 Aravind Narasimhan 5900 Sun Microsystems, Inc. 5901 101 Park Avenue, 3rd & 4th Floor 5902 New York, NY 5903 USA 5904 electronic mail: aravind.narasimhan@sun.com 5906 H Contributors 5908 The following people has made written contribution included in the | 5909 specification: | 5911 + Tom Marshall has contributed with text about the usage of 3rr | 5912 status codes. | 5914 + Thomas Zheng has contributed with text regarding the usage of the | 5915 Range in PLAY responses. | 5917 + Aravind Narasimhan has contributed with updated text regarding | 5918 the allowed usage of destination. | 5920 I Acknowledgements 5922 This draft is based on the functionality of the original RTSP draft 5923 submitted in October 1996. It also borrows format and descriptions 5924 from HTTP/1.1. 5926 This document has benefited greatly from the comments of all those 5927 participating in the MMUSIC-WG. In addition to those already men- 5928 tioned, the following individuals have contributed to this specifica- 5929 tion: 5931 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 5932 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 5933 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 5934 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 5935 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 5936 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 5937 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 5938 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 5939 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 5940 Alexander Sokolsky, Dale Stammen, John Francis Stracke, and David 5941 Walker. 5943 [1] H. Schulzrinne, "RTP profile for audio and video conferences with 5944 minimal control," RFC 1890, Internet Engineering Task Force, Jan. 5945 1996. 5947 [2] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee, 5948 "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Engi- 5949 neering Task Force, Jan. 1997. 5951 [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Internationaliza- 5952 tion of the hypertext markup language," RFC 2070, Internet Engineer- 5953 ing Task Force, Jan. 1997. 5955 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 5956 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 5958 [5] ISO/IEC, "Information technology -- generic coding of moving pic- 5959 tures and associated audio informaiton -- part 6: extension for digi- 5960 tal storage media and control," Draft International Standard ISO 5961 13818-6, International Organization for Standardization ISO/IEC 5962 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 5964 [6] J. Franks, P. Hallam-Baker, and J. Hostetler, "An extension to 5965 HTTP: digest access authentication," RFC 2069, Internet Engineering 5966 Task Force, Jan. 1997. 5968 [7] J. Postel, "User datagram protocol," RFC STD 6, 768, Internet 5969 Engineering Task Force, Aug. 1980. 5971 [8] B. Hinden and C. Partridge, "Version 2 of the reliable data pro- 5972 tocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr. 1990. 5974 [9] J. Postel, "Transmission control protocol," RFC STD 7, 793, 5975 Internet Engineering Task Force, Sept. 1981. 5977 [10] H. Schulzrinne, "A comprehensive multimedia control architecture 5978 for the Internet," in Proc. International Workshop on Network and 5979 Operating System Support for Digital Audio and Video (NOSSDAV), (St. 5980 Louis, Missouri), May 1997. 5982 [11] P. McMahon, "GSS-API authentication method for SOCKS version 5," 5983 RFC 1961, Internet Engineering Task Force, June 1996. 5985 [12] J. Miller, P. Resnick, and D. Singer, "Rating services and rat- 5986 ing systems (and their machine readable descriptions)," Recommenda- 5987 tion REC-PICS-services-961031, W3C (World Wide Web Consortium), 5988 Boston, Massachusetts, Oct. 1996. 5990 [13] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 5991 distribution label syntax and communication protocols," Recommenda- 5992 tion REC-PICS-labels-961031, W3C (World Wide Web Consortium), Boston, 5993 Massachusetts, Oct. 1996. 5995 [14] D. Crocker and P. Overell, "Augmented BNF for syntax specifica- 5996 tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 1997. 5998 [15] B. Braden, "Requirements for internet hosts - application and 5999 support," RFC STD 3, 1123, Internet Engineering Task Force, Oct. 6000 1989. 6002 [16] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, 6003 Internet Engineering Task Force, Apr. 1996. 6005 [17] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 6006 locators (URL)," RFC 1738, Internet Engineering Task Force, Dec. 6007 1994. 6009 [18] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 6010 2279, Internet Engineering Task Force, Jan. 1998. 6012 [19] B. Braden, "T/TCP -- TCP extensions for transactions functional 6013 specification," RFC 1644, Internet Engineering Task Force, July 1994. 6015 [20] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 6016 Reading, Massachusetts: Addison-Wesley, 1994. 6018 [21] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 6019 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 6020 1998. 6022 [22] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 6023 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 6024 Task Force, Aug. 1998. 6026 [23] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 6027 a transport protocol for real-time applications," RFC 1889, Internet 6028 Engineering Task Force, Jan. 1996. 6030 [24] M. Handley and V. Jacobson, "SDP: session description protocol," 6031 RFC 2327, Internet Engineering Task Force, Apr. 1998. 6033 [25] R. Fielding, "Relative uniform resource locators," RFC 1808, 6034 Internet Engineering Task Force, June 1995. 6036 [26] R. Fielding, "Hypertext Transfer Protocol -- HTTP/1.1," RFC 6037 2616, Internet Engineering Task Force, June 1999. 6039 [27] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC 2246, 6040 Internet Engineering Task Force, Januari 1999. 6042 [28] International Telecommunication Union, "Visual telephone systems 6043 and equipment for local area networks which provide a non-guaranteed 6044 quality of service," Recommendation H.323, Telecommunications Stan- 6045 darization Sector of ITU, Geneva, Switzerland, May 1996. 6047 [29] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Con- 6048 siderations Section in RFCs," RFC2434, Internet Engineering Task 6049 Force, October 1998. 6051 [30] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal IPv6 6052 Addresses in URL's," RFC 2732, Internet Engineering Task Force, 6053 December 1999. 6055 [31] J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple 6056 Traversal of UDP Through Network Address Translators," Internet Engi- 6057 neering Task Force, Work in Progress, October 2002. 6059 [32] P. Srisuresh, K. Egevang, "Traditional IP Network Address Trans- 6060 lator (Traditional NAT)," RFC 3022, Internet Engineering Task Force, 6061 January 2001. 6063 [33] M. Westerlund, "How to make Real-Time Streaming Protocol (RTSP) 6064 traverse Network Address Translators (NAT) and interact with Fire- 6065 walls.", Internet Engineering Task Force Draft, draft-ietf-mmusic- 6066 rtsp-nat-00.txt, Work in Progress, Feb 2003. 6068 [34] A. Narasimhan, A. Narasimhan, "MUTE and UNMUTE extension to 6069 RTSP", Internet Engineering Task Force Draft, draft-sergent-rtsp- 6070 mute-00.txt, Work in Progress, Feb 2002. 6072 [35] Third Generation Partnership Project (3GPP), "Transparent end- 6073 to-end Packet-switched Streaming Service (PSS); Protocols and codecs" 6074 3GPP Technical Specification 26.234, Release 5. 6076 [36] D. Yon, "Connection-Oriented Media Transport in SDP", Internet 6077 Engineering Task Force Draft, draft-ietf-mmusic-sdp-comedia-04.txt, 6078 July 2002. 6080 [37] John Lazzaro, "Framing RTP and RTCP Packets over Connection-Ori- 6081 ented Transport", Internet Engineering Task Force Draft , draft-laz- 6082 zaro-avt-rtp-framing-contrans-00.txt, January 2003. 6084 IPR Notice 6086 The IETF takes no position regarding the validity or scope of any 6087 intellectual property or other rights that might be claimed to per- 6088 tain to the implementation or use of the technology described in this 6089 document or the extent to which any license under such rights might 6090 or might not be available; neither does it represent that it has made 6091 any effort to identify any such rights. Information on the IETF's 6092 procedures with respect to rights in standards-track and standards- 6093 related documentation can be found in BCP-11. Copies of claims of 6094 rights made available for publication and any assurances of licenses 6095 to be made available, or the result of an attempt made to obtain a 6096 general license or permission for the use of such proprietary rights 6097 by implementors or users of this specification can be obtained from 6098 the IETF Secretariat. 6100 The IETF invites any interested party to bring to its attention any 6101 copyrights, patents or patent applications, or other proprietary 6102 rights which may cover technology that may be required to practice 6103 this standard. Please address the information to the IETF Executive 6104 Director. 6106 Full Copyright Statement 6108 Copyright (C) The Internet Society (2003). All Rights Reserved. 6110 This document and translations of it may be copied and furnished to 6111 others, and derivative works that comment on or otherwise explain it 6112 or assist in its implmentation may be prepared, copied, published and 6113 distributed, in whole or in part, without restriction of any kind, 6114 provided that the above copyright notice and this paragraph are 6115 included on all such copies and derivative works. However, this docu- 6116 ment itself may not be modified in any way, such as by removing the 6117 copyright notice or references to the Internet Society or other 6118 Internet organizations, except as needed for the purpose of develop- 6119 ing Internet standards in which case the procedures for copyrights 6120 defined in the Internet Standards process must be followed, or as 6121 required to translate it into languages other than English. 6123 The limited permissions granted above are perpetual and will not be 6124 revoked by the Internet Society or its successors or assigns. 6126 This document and the information contained herein is provided on an 6127 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 6128 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 6129 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 6130 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 6131 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6133 Table of Contents 6135 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 3 6136 1.1 The Update of the RTSP Specification . . . . . . . . . . 3 6137 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 6138 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . 6 6139 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 6140 1.5 Protocol Properties . . . . . . . . . . . . . . . . . . . 8 6141 1.6 Extending RTSP . . . . . . . . . . . . . . . . . . . . . 10 6142 1.7 Overall Operation . . . . . . . . . . . . . . . . . . . . 11 6143 1.8 RTSP States . . . . . . . . . . . . . . . . . . . . . . . 12 6144 1.9 Relationship with Other Protocols . . . . . . . . . . . . 13 6145 2 Notational Conventions . . . . . . . . . . . . . . . . . 14 6146 3 Protocol Parameters . . . . . . . . . . . . . . . . . . . 14 6147 3.1 RTSP Version . . . . . . . . . . . . . . . . . . . . . . 14 6148 3.2 RTSP URL . . . . . . . . . . . . . . . . . . . . . . . . 14 6149 3.3 Session Identifiers . . . . . . . . . . . . . . . . . . . 16 6150 3.4 SMPTE Relative Timestamps . . . . . . . . . . . . . . . . 16 6151 3.5 Normal Play Time . . . . . . . . . . . . . . . . . . . . 17 6152 3.6 Absolute Time . . . . . . . . . . . . . . . . . . . . . . 18 6153 3.7 Feature-tags . . . . . . . . . . . . . . . . . . . . . . 18 6154 4 RTSP Message . . . . . . . . . . . . . . . . . . . . . . 19 6155 4.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 19 6156 4.2 Message Headers . . . . . . . . . . . . . . . . . . . . . 19 6157 4.3 Message Body . . . . . . . . . . . . . . . . . . . . . . 19 6158 4.4 Message Length . . . . . . . . . . . . . . . . . . . . . 19 6159 5 General Header Fields . . . . . . . . . . . . . . . . . . 20 6160 6 Request . . . . . . . . . . . . . . . . . . . . . . . . . 20 6161 6.1 Request Line . . . . . . . . . . . . . . . . . . . . . . 21 6162 6.2 Request Header Fields . . . . . . . . . . . . . . . . . . 21 6163 7 Response . . . . . . . . . . . . . . . . . . . . . . . . 22 6164 7.1 Status-Line . . . . . . . . . . . . . . . . . . . . . . . 23 6165 7.1.1 Status Code and Reason Phrase . . . . . . . . . . . . . . 23 6166 7.1.2 Response Header Fields . . . . . . . . . . . . . . . . . 25 6167 8 Entity . . . . . . . . . . . . . . . . . . . . . . . . . 27 6168 8.1 Entity Header Fields . . . . . . . . . . . . . . . . . . 27 6169 8.2 Entity Body . . . . . . . . . . . . . . . . . . . . . . . 28 6170 9 Connections . . . . . . . . . . . . . . . . . . . . . . . 28 6171 9.1 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 28 6172 9.2 Reliability and Acknowledgements . . . . . . . . . . . . 29 6173 9.3 The usage of connections . . . . . . . . . . . . . . . . 30 6174 9.4 Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . . 31 6175 10 Capability Handling . . . . . . . . . . . . . . . . . . . 31 6176 11 Method Definitions . . . . . . . . . . . . . . . . . . . 33 6177 11.1 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 34 6178 11.2 DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 34 6179 11.3 SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6180 11.4 PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6181 11.5 PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6182 11.6 TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 44 6183 11.7 GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 45 6184 11.8 SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 46 6185 11.9 REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 47 6186 11.10 PING . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6187 11.11 Embedded (Interleaved) Binary Data . . . . . . . . . . . 49 6188 12 Status Code Definitions . . . . . . . . . . . . . . . . . 50 6189 12.1 Success 1xx . . . . . . . . . . . . . . . . . . . . . . . 50 6190 12.1.1 100 Continue . . . . . . . . . . . . . . . . . . . . . . 50 6191 12.2 Success 2xx . . . . . . . . . . . . . . . . . . . . . . . 51 6192 12.2.1 250 Low on Storage Space . . . . . . . . . . . . . . . . 51 6193 12.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 51 6194 12.3.1 TBW . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6195 12.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . 51 6196 12.3.3 302 Found . . . . . . . . . . . . . . . . . . . . . . . . 51 6197 12.3.4 303 See Other . . . . . . . . . . . . . . . . . . . . . . 51 6198 12.3.5 304 Not Modified . . . . . . . . . . . . . . . . . . . . 52 6199 12.3.6 305 Use Proxy . . . . . . . . . . . . . . . . . . . . . . 52 6200 12.4 Client Error 4xx . . . . . . . . . . . . . . . . . . . . 52 6201 12.4.1 400 Bad Request . . . . . . . . . . . . . . . . . . . . . 52 6202 12.4.2 405 Method Not Allowed . . . . . . . . . . . . . . . . . 52 6203 12.4.3 451 Parameter Not Understood . . . . . . . . . . . . . . 53 6204 12.4.4 452 reserved . . . . . . . . . . . . . . . . . . . . . . 53 6205 12.4.5 453 Not Enough Bandwidth . . . . . . . . . . . . . . . . 53 6206 12.4.6 454 Session Not Found . . . . . . . . . . . . . . . . . . 53 6207 12.4.7 455 Method Not Valid in This State . . . . . . . . . . . 53 6208 12.4.8 456 Header Field Not Valid for Resource . . . . . . . . . 53 6209 12.4.9 457 Invalid Range . . . . . . . . . . . . . . . . . . . . 53 6210 12.4.10 458 Parameter Is Read-Only . . . . . . . . . . . . . . . 53 6211 12.4.11 459 Aggregate Operation Not Allowed . . . . . . . . . . . 54 6212 12.4.12 460 Only Aggregate Operation Allowed . . . . . . . . . . 54 6213 12.4.13 461 Unsupported Transport . . . . . . . . . . . . . . . . 54 6214 12.4.14 462 Destination Unreachable . . . . . . . . . . . . . . . 54 6215 12.5 Server Error 5xx . . . . . . . . . . . . . . . . . . . . 54 6216 12.5.1 551 Option not supported . . . . . . . . . . . . . . . . 54 6217 13 Header Field Definitions . . . . . . . . . . . . . . . . 54 6218 13.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . 56 6219 13.2 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 60 6220 13.3 Accept-Language . . . . . . . . . . . . . . . . . . . . . 60 6221 13.4 Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 60 6222 13.5 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6223 13.6 Authorization . . . . . . . . . . . . . . . . . . . . . . 61 6224 13.7 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 61 6225 13.8 Blocksize . . . . . . . . . . . . . . . . . . . . . . . . 61 6226 13.9 Cache-Control . . . . . . . . . . . . . . . . . . . . . . 62 6227 13.10 Connection . . . . . . . . . . . . . . . . . . . . . . . 65 6228 13.11 Content-Base . . . . . . . . . . . . . . . . . . . . . . 65 6229 13.12 Content-Encoding . . . . . . . . . . . . . . . . . . . . 65 6230 13.13 Content-Language . . . . . . . . . . . . . . . . . . . . 65 6231 13.14 Content-Length . . . . . . . . . . . . . . . . . . . . . 65 6232 13.15 Content-Location . . . . . . . . . . . . . . . . . . . . 65 6233 13.16 Content-Type . . . . . . . . . . . . . . . . . . . . . . 65 6234 13.17 CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6235 13.18 Date . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6236 13.19 Expires . . . . . . . . . . . . . . . . . . . . . . . . . 66 6237 13.20 From . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6238 13.21 Host . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6239 13.22 If-Match . . . . . . . . . . . . . . . . . . . . . . . . 67 6240 13.23 If-Modified-Since . . . . . . . . . . . . . . . . . . . . 68 6241 13.24 Last-Modified . . . . . . . . . . . . . . . . . . . . . . 68 6242 13.25 Location . . . . . . . . . . . . . . . . . . . . . . . . 68 6243 13.26 Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 68 6244 13.27 Proxy-Require . . . . . . . . . . . . . . . . . . . . . . 68 6245 13.28 Public . . . . . . . . . . . . . . . . . . . . . . . . . 69 6246 13.29 Range . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6247 13.30 Referer . . . . . . . . . . . . . . . . . . . . . . . . . 71 6248 13.31 Retry-After . . . . . . . . . . . . . . . . . . . . . . . 71 6249 13.32 Require . . . . . . . . . . . . . . . . . . . . . . . . . 71 6250 13.33 RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 73 6251 13.34 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6252 13.35 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6253 13.36 Server . . . . . . . . . . . . . . . . . . . . . . . . . 76 6254 13.37 Session . . . . . . . . . . . . . . . . . . . . . . . . . 76 6255 13.38 Supported . . . . . . . . . . . . . . . . . . . . . . . . 78 6256 13.39 Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 78 6257 13.40 Transport . . . . . . . . . . . . . . . . . . . . . . . . 79 6258 13.41 Unsupported . . . . . . . . . . . . . . . . . . . . . . . 84 6259 13.42 User-Agent . . . . . . . . . . . . . . . . . . . . . . . 85 6260 13.43 Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6261 13.44 Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6262 13.45 WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 85 6263 14 Caching . . . . . . . . . . . . . . . . . . . . . . . . . 85 6264 15 Examples . . . . . . . . . . . . . . . . . . . . . . . . 86 6265 15.1 Media on Demand (Unicast) . . . . . . . . . . . . . . . . 86 6266 15.2 Streaming of a Container file . . . . . . . . . . . . . . 88 6267 15.3 Single Stream Container Files . . . . . . . . . . . . . . 91 6268 15.4 Live Media Presentation Using Multicast . . . . . . . . . 93 6269 16 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 94 6270 16.1 Base Syntax . . . . . . . . . . . . . . . . . . . . . . . 94 6271 16.2 RTSP Protocol Definition . . . . . . . . . . . . . . . . 95 6272 16.2.1 Message Syntax . . . . . . . . . . . . . . . . . . . . . 95 6273 16.2.2 Header Syntax . . . . . . . . . . . . . . . . . . . . . . 99 6274 17 Security Considerations . . . . . . . . . . . . . . . . . 100 6275 18 IANA Considerations . . . . . . . . . . . . . . . . . . . 102 6276 18.1 Feature-tags . . . . . . . . . . . . . . . . . . . . . . 103 6277 18.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . 103 6278 18.1.2 Registering New Feature-tags with IANA . . . . . . . . . 103 6279 18.1.3 Registered entries . . . . . . . . . . . . . . . . . . . 103 6280 18.2 RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 104 6281 18.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 104 6282 18.2.2 Registering New Methods with IANA . . . . . . . . . . . . 104 6283 18.2.3 Registered Entries . . . . . . . . . . . . . . . . . . . 104 6284 18.3 RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 104 6285 18.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 104 6286 18.3.2 Registering New Status Codes with IANA . . . . . . . . . 104 6287 18.3.3 Registered Entries . . . . . . . . . . . . . . . . . . . 105 6288 18.4 RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 105 6289 18.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 105 6290 18.4.2 Registering New Headers with IANA . . . . . . . . . . . . 105 6291 18.4.3 Registered entries . . . . . . . . . . . . . . . . . . . 105 6292 18.5 Transport Header registries . . . . . . . . . . . . . . . 106 6293 18.5.1 Transport Protocols . . . . . . . . . . . . . . . . . . . 106 6294 18.5.2 Profile . . . . . . . . . . . . . . . . . . . . . . . . . 106 6295 18.5.3 Lower Transport . . . . . . . . . . . . . . . . . . . . . 107 6296 18.5.4 Transport modes . . . . . . . . . . . . . . . . . . . . . 107 6297 18.6 Cache Directive Extensions . . . . . . . . . . . . . . . 108 6298 18.7 SDP attributes . . . . . . . . . . . . . . . . . . . . . 108 6299 A RTSP Protocol State Machine . . . . . . . . . . . . . . . 109 6300 A.1 States . . . . . . . . . . . . . . . . . . . . . . . . . 109 6301 A.2 State variables . . . . . . . . . . . . . . . . . . . . . 109 6302 A.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 110 6303 A.4 State Tables . . . . . . . . . . . . . . . . . . . . . . 110 6304 B Media Transport Alternatives . . . . . . . . . . . . . . 114 6305 B.1 RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6306 B.1.1 AVP . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6307 B.1.2 AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . 115 6308 B.1.3 AVP/TCP . . . . . . . . . . . . . . . . . . . . . . . . . 117 6309 B.2 Future Additions . . . . . . . . . . . . . . . . . . . . 118 6310 C Use of SDP for RTSP Session Descriptions . . . . . . . . 118 6311 C.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 118 6312 C.1.1 Control URL . . . . . . . . . . . . . . . . . . . . . . . 118 6313 C.1.2 Media Streams . . . . . . . . . . . . . . . . . . . . . . 119 6314 C.1.3 Payload Type(s) . . . . . . . . . . . . . . . . . . . . . 120 6315 C.1.4 Format-Specific Parameters . . . . . . . . . . . . . . . 120 6316 C.1.5 Range of Presentation . . . . . . . . . . . . . . . . . . 120 6317 C.1.6 Time of Availability . . . . . . . . . . . . . . . . . . 121 6318 C.1.7 Connection Information . . . . . . . . . . . . . . . . . 121 6319 C.1.8 Entity Tag . . . . . . . . . . . . . . . . . . . . . . . 121 6320 C.2 Aggregate Control Not Available . . . . . . . . . . . . . 122 6321 C.3 Aggregate Control Available . . . . . . . . . . . . . . . 122 6322 D Minimal RTSP implementation . . . . . . . . . . . . . . . 123 6323 D.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . 123 6324 D.1.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 124 6325 D.1.2 Authentication-enabled . . . . . . . . . . . . . . . . . 124 6326 D.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . 125 6327 D.2.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 125 6328 D.2.2 Authentication-enabled . . . . . . . . . . . . . . . . . 126 6329 E Open Issues . . . . . . . . . . . . . . . . . . . . . . . 126 6330 F Changes . . . . . . . . . . . . . . . . . . . . . . . . . 127 6331 G Author Addresses . . . . . . . . . . . . . . . . . . . . 131 6332 H Contributors . . . . . . . . . . . . . . . . . . . . . . 132 6333 I Acknowledgements . . . . . . . . . . . . . . . . . . . . 132