idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-01.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 207 instances of too long lines in the document, the longest one being 21 characters in excess of 72. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 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 1004 has weird spacing: '... Code reaso...' == Line 1037 has weird spacing: '...s State all...' == Line 1041 has weird spacing: '...Allowed all...' == Line 1042 has weird spacing: '...Allowed all...' == Line 1187 has weird spacing: '...rection obje...' == (12 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: + Name and description of option. The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST not contain any spaces, control characters or periods. == 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 'MUST not' in this paragraph: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifica-tions [H10.4.1]. If the request does not have a CSeq header, the server MUST not include a CSeq in the response. == 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 option 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, control characters or periods. Any proprietary option SHOULD have as the first part of the name a vendor tag, which identifies the company/person. == 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: + The parameter name is a BNF token. The name SHOULD not be more than 20 characters long. Any proprietary parameter should start the name with a vendor tag, as clearly as possible identify the company or person. == 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 3xx will result in that the session is ended and its state is changed to Init. However there exist restrictions to when a 3xx response may be used. A 5xx response SHALL not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error SHOULD result in ending of the session. -- 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 06, 2002) is 7994 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? '1' on line 4413 looks like a reference -- Missing reference section? '26' on line 4506 looks like a reference -- Missing reference section? '3' on line 4421 looks like a reference -- Missing reference section? '4' on line 4425 looks like a reference -- Missing reference section? '5' on line 4428 looks like a reference -- Missing reference section? '24' on line 4500 looks like a reference -- Missing reference section? '27' on line 4509 looks like a reference -- Missing reference section? '6' on line 4434 looks like a reference -- Missing reference section? '7' on line 4438 looks like a reference -- Missing reference section? '8' on line 4441 looks like a reference -- Missing reference section? '9' on line 4444 looks like a reference -- Missing reference section? '10' on line 4447 looks like a reference -- Missing reference section? '28' on line 4512 looks like a reference -- Missing reference section? '11' on line 4452 looks like a reference -- Missing reference section? '12' on line 4455 looks like a reference -- Missing reference section? '13' on line 4460 looks like a reference -- Missing reference section? '14' on line 4465 looks like a reference -- Missing reference section? '16' on line 4472 looks like a reference -- Missing reference section? '17' on line 4475 looks like a reference -- Missing reference section? '18' on line 4479 looks like a reference -- Missing reference section? 'H6' on line 852 looks like a reference -- Missing reference section? '15' on line 4468 looks like a reference -- Missing reference section? '19' on line 4482 looks like a reference -- Missing reference section? '20' on line 4485 looks like a reference -- Missing reference section? 'H10' on line 1775 looks like a reference -- Missing reference section? '21' on line 4488 looks like a reference -- Missing reference section? '22' on line 4492 looks like a reference -- Missing reference section? '23' on line 4496 looks like a reference -- Missing reference section? '2' on line 4417 looks like a reference -- Missing reference section? 'CRLF' on line 3371 looks like a reference -- Missing reference section? 'H15' on line 3400 looks like a reference -- Missing reference section? '29' on line 4517 looks like a reference -- Missing reference section? '25' on line 4503 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 18 warnings (==), 35 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 12 draft-ietf-mmusic-rfc2326bis-01.txt 13 June 06, 2002 14 Expires: December, 2002 16 Real Time Streaming Protocol (RTSP) 18 STATUS OF THIS MEMO 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference mate- 31 rial or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This memorandum is a revision of RFC 2326, which is currently a Pro- 42 posed Standard. 44 The Real Time Streaming Protocol, or RTSP, is an application-level 45 protocol for control over the delivery of data with real-time proper- 46 ties. RTSP provides an extensible framework to enable controlled, on- 47 demand delivery of real-time data, such as audio and video. Sources 48 of data can include both live data feeds and stored clips. This pro- 49 tocol is intended to control multiple data delivery sessions, provide 50 a means for choosing delivery channels such as UDP, multicast UDP and 51 TCP, and provide a means for choosing delivery mechanisms based upon 52 RTP (RFC 1889). 54 1 Introduction 56 1.1 Purpose 58 The Real-Time Streaming Protocol (RTSP) establishes and controls 59 either a single or several time-synchronized streams of continuous 60 media such as audio and video. It does not typically deliver the con- 61 tinuous streams itself, although interleaving of the continuous media 62 stream with the control stream is possible (see Section 10.13). In 63 other words, RTSP acts as a "network remote control" for multimedia 64 servers. 66 The set of streams to be controlled is defined by a presentation 67 description. This memorandum does not define a format for a presenta- 68 tion description. 70 There is no notion of an RTSP connection; instead, a server maintains 71 a session labeled by an identifier. An RTSP session is in no way tied 72 to a transport-level connection such as a TCP connection. During an 73 RTSP session, an RTSP client may open and close many reliable trans- 74 port connections to the server to issue RTSP requests. Alternatively, 75 it may use a connectionless transport protocol such as UDP. 77 The streams controlled by RTSP may use RTP [1], but the operation of 78 RTSP does not depend on the transport mechanism used to carry contin- 79 uous media. 81 The protocol is intentionally similar in syntax and operation to 82 HTTP/1.1 [26] so that extension mechanisms to HTTP can in most cases 83 also be added to RTSP. However, RTSP differs in a number of important 84 aspects from HTTP: 86 + RTSP introduces a number of new methods and has a different pro- 87 tocol identifier. 89 + An RTSP server needs to maintain state by default in almost all 90 cases, as opposed to the stateless nature of HTTP. 92 + Both an RTSP server and client can issue requests. 94 + Data is carried out-of-band by a different protocol. (There is an 95 exception to this.) 97 + RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, 98 consistent with current HTML internationalization efforts [3]. 100 + The Request-URI always contains the absolute URI. Because of 101 backward compatibility with a historical blunder, HTTP/1.1 [26] 102 carries only the absolute path in the request and puts the host 103 name in a separate header field. 105 This makes "virtual hosting" easier, where a single host 106 with one IP address hosts several document trees. 108 The protocol supports the following operations: 110 Retrieval of media from media server: The client can request a pre- 111 sentation description via HTTP or some other method. If the 112 presentation is being multicast, the presentation description 113 contains the multicast addresses and ports to be used for the 114 continuous media. If the presentation is to be sent only to 115 the client via unicast, the client provides the destination 116 for security reasons. 118 Invitation of a media server to a conference: A media server can be 119 "invited" to join an existing conference, either to play back 120 media into the presentation or to record all or a subset of 121 the media in a presentation. This mode is useful for dis- 122 tributed teaching applications. Several parties in the confer- 123 ence may take turns "pushing the remote control buttons". 125 Addition of media to an existing presentation: Particularly for 126 live presentations, it is useful if the server can tell the 127 client about additional media becoming available. 129 RTSP requests may be handled by proxies, tunnels and caches as in 130 HTTP/1.1 [26]. 132 1.2 Requirements 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [4]. 138 1.3 Terminology 140 Some of the terminology has been adopted from HTTP/1.1 [26]. Terms 141 not listed here are defined as in HTTP/1.1. 143 Aggregate control: The control of the multiple streams using a sin- 144 gle timeline by the server. For audio/video feeds, this means 145 that the client may issue a single play or pause message to 146 control both the audio and video feeds. 148 Conference: a multiparty, multimedia presentation, where "multi" 149 implies greater than or equal to one. 151 Client: The client requests continuous media data from the media 152 server. 154 Connection: A transport layer virtual circuit established between 155 two programs for the purpose of communication. 157 Container file: A file which may contain multiple media streams 158 which often comprise a presentation when played together. RTSP 159 servers may offer aggregate control on these files, though the 160 concept of a container file is not embedded in the protocol. 162 Continuous media: Data where there is a timing relationship between 163 source and sink; that is, the sink must reproduce the timing 164 relationship that existed at the source. The most common exam- 165 ples of continuous media are audio and motion video. Continu- 166 ous media can be real-time (interactive), where there is a 167 "tight" timing relationship between source and sink, or 168 streaming (playback), where the relationship is less strict. 170 Entity: The information transferred as the payload of a request or 171 response. An entity consists of metainformation in the form of 172 entity-header fields and content in the form of an entity- 173 body, as described in Section 8. 175 Media initialization: Datatype/codec specific initialization. This 176 includes such things as clockrates, color tables, etc. Any 177 transport-independent information which is required by a 178 client for playback of a media stream occurs in the media ini- 179 tialization phase of stream setup. 181 Media parameter: Parameter specific to a media type that may be 182 changed before or during stream playback. 184 Media server: The server providing playback or recording services 185 for one or more media streams. Different media streams within 186 a presentation may originate from different media servers. A 187 media server may reside on the same or a different host as the 188 web server the presentation is invoked from. 190 Media server indirection: Redirection of a media client to a dif- 191 ferent media server. 193 (Media) stream: A single media instance, e.g., an audio stream or a 194 video stream as well as a single whiteboard or shared applica- 195 tion group. When using RTP, a stream consists of all RTP and 196 RTCP packets created by a source within an RTP session. This 197 is equivalent to the definition of a DSM-CC stream([5]). 199 Message: The basic unit of RTSP communication, consisting of a 200 structured sequence of octets matching the syntax defined in 201 Section 15 and transmitted via a connection or a connection- 202 less protocol. 204 Participant: Member of a conference. A participant may be a 205 machine, e.g., a media record or playback server. 207 Presentation: A set of one or more streams presented to the client 208 as a complete media feed, using a presentation description as 209 defined below. In most cases in the RTSP context, this implies 210 aggregate control of those streams, but does not have to. 212 Presentation description: A presentation description contains 213 information about one or more media streams within a presenta- 214 tion, such as the set of encodings, network addresses and 215 information about the content. Other IETF protocols such as 216 SDP (RFC 2327 [24]) use the term "session" for a live presen- 217 tation. The presentation description may take several differ- 218 ent formats, including but not limited to the session descrip- 219 tion format SDP. 221 Response: An RTSP response. If an HTTP response is meant, that is 222 indicated explicitly. 224 Request: An RTSP request. If an HTTP request is meant, that is 225 indicated explicitly. 227 RTSP session: A complete RTSP "transaction", e.g., the viewing of a 228 movie. A session typically consists of a client setting up a 229 transport mechanism for the continuous media stream (SETUP), 230 starting the stream with PLAY or RECORD, and closing the 231 stream with TEARDOWN. 233 Transport initialization: The negotiation of transport information 234 (e.g., port numbers, transport protocols) between the client 235 and the server. 237 1.4 Protocol Properties 239 RTSP has the following properties: 241 Extendable: New methods and parameters can be easily added to RTSP. 243 Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. 245 Secure: RTSP re-uses web security mechanisms, either at the trans- 246 port level (TLS, RFC 2246 [27]) or within the protocol itself. 247 All HTTP authentication mechanisms such as basic (RFC 2616 248 [26]) and digest authentication (RFC 2069 [6]) are directly 249 applicable. 251 Transport-independent: RTSP may use either an unreliable datagram 252 protocol (UDP) (RFC 768 [7]), a reliable datagram protocol 253 (RDP, RFC 1151, not widely used [8]) or a reliable stream pro- 254 tocol such as TCP (RFC 793 [9]) as it implements application- 255 level reliability. 257 Multi-server capable: Each media stream within a presentation can 258 reside on a different server. The client automatically estab- 259 lishes several concurrent control sessions with the different 260 media servers. Media synchronization is performed at the 261 transport level. 263 Control of recording devices: The protocol can control both record- 264 ing and playback devices, as well as devices that can alter- 265 nate between the two modes ("VCR"). 267 Separation of stream control and conference initiation: Stream con- 268 trol is divorced from inviting a media server to a conference. 269 In particular, SIP [10] or H.323 [28] may be used to invite a 270 server to a conference. 272 Suitable for professional applications: RTSP supports frame-level 273 accuracy through SMPTE time stamps to allow remote digital 274 editing. 276 Presentation description neutral: The protocol does not impose a 277 particular presentation description or metafile format and can 278 convey the type of format to be used. However, the presenta- 279 tion description must contain at least one RTSP URI. 281 Proxy and firewall friendly: The protocol should be readily handled 282 by both application and transport-layer (SOCKS [11]) fire- 283 walls. A firewall may need to understand the SETUP method to 284 open a "hole" for the UDP media stream. 286 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that 287 the existing infrastructure can be reused. This infrastructure 288 includes PICS (Platform for Internet Content Selection 289 [12,13]) for associating labels with content. However, RTSP 290 does not just add methods to HTTP since the controlling 291 continuous media requires server state in most cases. 293 Appropriate server control: If a client can start a stream, it must 294 be able to stop a stream. Servers should not start streaming 295 to clients in such a way that clients cannot stop the stream. 297 Transport negotiation: The client can negotiate the transport 298 method prior to actually needing to process a continuous media 299 stream. 301 Capability negotiation: If basic features are disabled, there must 302 be some clean mechanism for the client to determine which 303 methods are not going to be implemented. This allows clients 304 to present the appropriate user interface. For example, if 305 seeking is not allowed, the user interface must be able to 306 disallow moving a sliding position indicator. 308 An earlier requirement in RTSP was multi-client capability. 309 However, it was determined that a better approach was to make 310 sure that the protocol is easily extensible to the multi- 311 client scenario. Stream identifiers can be used by several 312 control streams, so that "passing the remote" would be possi- 313 ble. The protocol would not address how several clients nego- 314 tiate access; this is left to either a "social protocol" or 315 some other floor control mechanism. 317 1.5 Extending RTSP 319 Since not all media servers have the same functionality, media 320 servers by necessity will support different sets of requests. For 321 example: 323 + A server may only be capable of playback thus has no need to sup- 324 port the RECORD request. 326 + A server may not be capable of seeking (absolute positioning) if 327 it is to support live events only. 329 + Some servers may not support setting stream parameters and thus 330 not support GET_PARAMETER and SET_PARAMETER. 332 A server SHOULD implement all header fields described in Section 12. 334 It is up to the creators of presentation descriptions not to ask the 335 impossible of a server. This situation is similar in HTTP/1.1 [26], 336 where the methods described in [H19.5] are not likely to be supported 337 across all servers. 339 RTSP can be extended in three ways, listed here in order of the mag- 340 nitude of changes supported: 342 + Existing methods can be extended with new parameters, as long as 343 these parameters can be safely ignored by the recipient. (This is 344 equivalent to adding new parameters to an HTML tag.) If the 345 client needs negative acknowledgement when a method extension is 346 not supported, a tag corresponding to the extension may be added 347 in the Require: field (see Section 12.32). 349 + New methods can be added. If the recipient of the message does 350 not understand the request, it responds with error code 501 (Not 351 Implemented) and the sender should not attempt to use this method 352 again. A client may also use the OPTIONS method to inquire about 353 methods supported by the server. The server SHOULD list the meth- 354 ods it supports using the Public response header. 356 + A new version of the protocol can be defined, allowing almost all 357 aspects (except the position of the protocol version number) to 358 change. 360 1.6 Overall Operation 362 Each presentation and media stream may be identified by an RTSP URL. 363 The overall presentation and the properties of the media the presen- 364 tation is made up of are defined by a presentation description file, 365 the format of which is outside the scope of this specification. The 366 presentation description file may be obtained by the client using 367 HTTP or other means such as email and may not necessarily be stored 368 on the media server. 370 For the purposes of this specification, a presentation description is 371 assumed to describe one or more presentations, each of which main- 372 tains a common time axis. For simplicity of exposition and without 373 loss of generality, it is assumed that the presentation description 374 contains exactly one such presentation. A presentation may contain 375 several media streams. 377 The presentation description file contains a description of the media 378 streams making up the presentation, including their encodings, lan- 379 guage, and other parameters that enable the client to choose the most 380 appropriate combination of media. In this presentation description, 381 each media stream that is individually controllable by RTSP is iden- 382 tified by an RTSP URL, which points to the media server handling that 383 particular media stream and names the stream stored on that server. 384 Several media streams can be located on different servers; for exam- 385 ple, audio and video streams can be split across servers for load 386 sharing. The description also enumerates which transport methods the 387 server is capable of. 389 Besides the media parameters, the network destination address and 390 port need to be determined. Several modes of operation can be distin- 391 guished: 393 Unicast: The media is transmitted to the source of the RTSP 394 request, with the port number chosen by the client. Alterna- 395 tively, the media is transmitted on the same reliable stream 396 as RTSP. 398 Multicast, server chooses address: The media server picks the mul- 399 ticast address and port. This is the typical case for a live 400 or near-media-on-demand transmission. 402 Multicast, client chooses address: If the server is to participate 403 in an existing multicast conference, the multicast address, 404 port and encryption key are given by the conference descrip- 405 tion, established by means outside the scope of this specifi- 406 cation. 408 1.7 RTSP States 410 RTSP controls a stream which may be sent via a separate protocol, 411 independent of the control channel. For example, RTSP control may 412 occur on a TCP connection while the data flows via UDP. Thus, data 413 delivery continues even if no RTSP requests are received by the media 414 server. Also, during its lifetime, a single media stream may be con- 415 trolled by RTSP requests issued sequentially on different TCP connec- 416 tions. Therefore, the server needs to maintain "session state" to be 417 able to correlate RTSP requests with a stream. The state transitions 418 are described in Section A. 420 Many methods in RTSP do not contribute to state. However, the follow- 421 ing play a central role in defining the allocation and usage of 422 stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and TEAR- 423 DOWN. 425 SETUP: Causes the server to allocate resources for a stream and 426 start an RTSP session. 428 PLAY and RECORD: Starts data transmission on a stream allocated via 429 SETUP. 431 PAUSE: Temporarily halts a stream without freeing server resources. 433 TEARDOWN: Frees resources associated with the stream. The RTSP 434 session ceases to exist on the server. 436 RTSP methods that contribute to state use the Session header 437 field (Section 12.37) to identify the RTSP session whose state 438 is being manipulated. The server generates session identifiers 439 in response to SETUP requests (Section 10.4). 441 1.8 Relationship with Other Protocols 443 RTSP has some overlap in functionality with HTTP. It also may inter- 444 act with HTTP in that the initial contact with streaming content is 445 often to be made through a web page. The current protocol specifica- 446 tion aims to allow different hand-off points between a web server and 447 the media server implementing RTSP. For example, the presentation 448 description can be retrieved using HTTP or RTSP, which reduces 449 roundtrips in web-browser-based scenarios, yet also allows for stan- 450 dalone RTSP servers and clients which do not rely on HTTP at all. 452 However, RTSP differs fundamentally from HTTP in that data delivery 453 takes place out-of-band in a different protocol. HTTP is an asymmet- 454 ric protocol where the client issues requests and the server 455 responds. In RTSP, both the media client and media server can issue 456 requests. RTSP requests are also not stateless; they may set parame- 457 ters and continue to control a media stream long after the request 458 has been acknowledged. 460 Re-using HTTP functionality has advantages in at least two 461 areas, namely security and proxies. The requirements are very 462 similar, so having the ability to adopt HTTP work on caches, 463 proxies and authentication is valuable. 465 While most real-time media will use RTP as a transport protocol, RTSP 466 is not tied to RTP. 468 RTSP assumes the existence of a presentation description format that 469 can express both static and temporal properties of a presentation 470 containing several media streams. 472 2 Notational Conventions 474 Since many of the definitions and syntax are identical to HTTP/1.1, 475 this specification only points to the section where they are defined 476 rather than copying it. For brevity, [HX.Y] is to be taken to refer 477 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [26]). 479 All the mechanisms specified in this document are described in both 480 prose and an augmented Backus-Naur form (BNF) similar to that used in 481 [H2.1]. It is described in detail in RFC 2234 [14], with the differ- 482 ence that this RTSP specification maintains the "1#" notation for 483 comma-separated lists. 485 In this draft, we use indented and smaller-type paragraphs to provide 486 background and motivation. This is intended to give readers who were 487 not involved with the formulation of the specification an understand- 488 ing of why things are the way that they are in RTSP. 490 3 Protocol Parameters 492 3.1 RTSP Version 494 HTTP Specification Section [H3.1] applies, with HTTP replaced by 495 RTSP. 497 3.2 RTSP URL 499 The "rtsp" and "rtspu" schemes are used to refer to network resources 500 via the RTSP protocol. This section defines the scheme-specific syn- 501 tax and semantics for RTSP URLs. 503 rtsp_URL = ( "rtsp:" | "rtspu:" ) 504 "//" host [ ":" port ] [ abs_path ] 505 host = 508 port = *DIGIT 510 abs_path is defined in [H3.2.1]. 512 Note that fragment and query identifiers do not have a well- 513 defined meaning at this time, with the interpretation left to 514 the RTSP server. 516 The scheme rtsp requires that commands are issued via a reliable pro- 517 tocol (within the Internet, TCP), while the scheme rtspu identifies 518 an unreliable protocol (within the Internet, UDP). 520 If the port is empty or not given, port 554 is assumed. The semantics 521 are that the identified resource can be controlled by RTSP at the 522 server listening for TCP (scheme "rtsp") connections or UDP (scheme 523 "rtspu") packets on that port of host, and the Request-URI for the 524 resource is rtsp_URL. 526 The use of IP addresses in URLs SHOULD be avoided whenever possible 527 (see RFC 1924 [16]). 529 A presentation or a stream is identified by a textual media identi- 530 fier, using the character set and escape conventions [H3.2] of URLs 531 (RFC 1738 [17]). URLs may refer to a stream or an aggregate of 532 streams, i.e., a presentation. Accordingly, requests described in 533 Section 10 can apply to either the whole presentation or an individ- 534 ual stream within the presentation. Note that some request methods 535 can only be applied to streams, not presentations and vice versa. 537 For example, the RTSP URL: 539 rtsp://media.example.com:554/twister/audiotrack 541 identifies the audio stream within the presentation "twister", which can 542 be controlled via RTSP requests issued over a TCP connection to port 554 543 of host media.example.com 545 Also, the RTSP URL: 547 rtsp://media.example.com:554/twister 549 identifies the presentation "twister", which may be composed of audio 550 and video streams. 552 This does not imply a standard way to reference streams in 553 URLs. The presentation description defines the hierarchical 554 relationships in the presentation and the URLs for the indi- 555 vidual streams. A presentation description may name a stream 556 "a.mov" and the whole presentation "b.mov". 558 The path components of the RTSP URL are opaque to the client and do 559 not imply any particular file system structure for the server. 561 This decoupling also allows presentation descriptions to be 562 used with non-RTSP media control protocols simply by replacing 563 the scheme in the URL. 565 3.3 Session Identifiers 567 Session identifiers are opaque strings of arbitrary length. Linear 568 white space must be URL-escaped. A session identifier MUST be chosen 569 randomly and MUST be at least eight octets long to make guessing it 570 more difficult. (See Section 16.) 571 session-id = 8*( ALPHA | DIGIT | safe ) 573 3.4 SMPTE Relative Timestamps 575 A SMPTE relative timestamp expresses time relative to the start of 576 the clip. Relative timestamps are expressed as SMPTE time codes for 577 frame-level access accuracy. The time code has the format 578 hours:minutes:seconds:frames.subframes, 579 with the origin at the start of the clip. The default smpte format 580 is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 581 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 582 use of alternative use of "smpte time". For the "frames" field in the 583 time value can assume the values 0 through 29. The difference between 584 30 and 29.97 frames per second is handled by dropping the first two 585 frame indices (values 00 and 01) of every minute, except every tenth 586 minute. If the frame value is zero, it may be omitted. Subframes are 587 measured in one-hundredth of a frame. 589 smpte-range = smpte-type "=" smpte-range-spec 590 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) | ( "-" smpte-time ) 591 smpte-type = "smpte" | "smpte-30-drop" | "smpte-25" 592 ; other timecodes may be added 593 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 594 [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ] 596 Examples: 598 smpte=10:12:33:20- 599 smpte=10:07:33- 600 smpte=10:07:00-10:07:33:05.01 601 smpte-25=10:07:00-10:07:33:05.01 603 3.5 Normal Play Time 605 Normal play time (NPT) indicates the stream absolute position rela- 606 tive to the beginning of the presentation. The timestamp consists of 607 a decimal fraction. The part left of the decimal may be expressed in 608 either seconds or hours, minutes, and seconds. The part right of the 609 decimal point measures fractions of a second. 611 The beginning of a presentation corresponds to 0.0 seconds. Negative 612 values are not defined. The special constant now is defined as the 613 current instant of a live event. It may be used only for live events. 615 NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the 616 viewer associates with a program. It is often digitally displayed on 617 a VCR. NPT advances normally when in normal play mode (scale = 1), 618 advances at a faster rate when in fast scan forward (high positive 619 scale ratio), decrements when in scan reverse (high negative scale 620 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 621 SMPTE time codes." [5] 623 npt-range = ["npt" "="] npt-range-spec 624 ; implementations SHOULD use npt= prefix, but SHOULD 625 ; be prepared to interoperate with RFC 2326 626 ; implementations which don't use it 627 npt-range-spec = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) 628 npt-time = "now" | npt-sec | npt-hhmmss 629 npt-sec = 1*DIGIT [ "." *DIGIT ] 630 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 631 npt-hh = 1*DIGIT ; any positive number 632 npt-mm = 1*2DIGIT ; 0-59 633 npt-ss = 1*2DIGIT ; 0-59 635 Examples: 637 npt=123.45-125 638 npt=12:05:35.3- 639 npt=now- 641 The syntax conforms to ISO 8601. The npt-sec notation is opti- 642 mized for automatic generation, the ntp-hhmmss notation for 643 consumption by human readers. The "now" constant allows 644 clients to request to receive the live feed rather than the 645 stored or time-delayed version. This is needed since neither 646 absolute time nor zero time are appropriate for this case. 648 3.6 Absolute Time 650 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 651 Fractions of a second may be indicated. 653 utc-range = ["clock" "="] utc-range-spec 654 utc-range-spec = ( utc-time "-" [ utc-time ] ) | ( "-" utc-time ) 655 utc-time = utc-date "T" utc-time "Z" 656 utc-date = 8DIGIT ; < YYYYMMDD > 657 utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > 659 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 660 UTC: 662 19961108T143720.25Z 664 3.7 Option Tags 666 Option tags are unique identifiers used to designate new options in 667 RTSP. These tags are used in in Require (Section 12.32) and Proxy- 668 Require (Section 12.27) header fields. 670 Syntax: 672 option-tag = token 674 The creator of a new RTSP option should either prefix the option with 675 a reverse domain name (e.g., "com.foo.mynewfeature" is an apt name 676 for a feature whose inventor can be reached at "foo.com"), or regis- 677 ter the new option with the Internet Assigned Numbers Authority 678 (IANA). 680 3.7.1 Registering New Option Tags with IANA 682 When registering a new RTSP option, the following information should 683 be provided: 685 + Name and description of option. The name may be of any length, 686 but SHOULD be no more than twenty characters long. The name MUST 687 not contain any spaces, control characters or periods. 689 + Indication of who has change control over the option (for exam- 690 ple, IETF, ISO, ITU-T, other international standardization bod- 691 ies, a consortium or a particular company or group of companies); 693 + A reference to a further description, if available, for example 694 (in order of preference) an RFC, a published paper, a patent fil- 695 ing, a technical report, documented source code or a computer 696 manual; 698 + For proprietary options, contact information (postal and email 699 address); 701 4 RTSP Message 703 RTSP is a text-based protocol and uses the ISO 10646 character set in 704 UTF-8 encoding (RFC 2279 [18]). Lines are terminated by CRLF, but 705 receivers should be prepared to also interpret CR and LF by them- 706 selves as line terminators. 708 Text-based protocols make it easier to add optional parameters 709 in a self-describing manner. Since the number of parameters 710 and the frequency of commands is low, processing efficiency is 711 not a concern. Text-based protocols, if done carefully, also 712 allow easy implementation of research prototypes in scripting 713 languages such as Tcl, Visual Basic and Perl. 715 The 10646 character set avoids tricky character set switching, but is 716 invisible to the application as long as US-ASCII is being used. This 717 is also the encoding used for RTCP. ISO 8859-1 translates directly 718 into Unicode with a high-order octet of zero. ISO 8859-1 characters 719 with the most-significant bit set are represented as 1100001x 720 10xxxxxx. (See RFC 2279 [18]) 722 RTSP messages can be carried over any lower-layer transport protocol 723 that is 8-bit clean. 725 Requests contain methods, the object the method is operating upon and 726 parameters to further describe the method. Methods are idempotent, 727 unless otherwise noted. Methods are also designed to require little 728 or no state maintenance at the media server. 730 4.1 Message Types 732 See [H4.1] 734 4.2 Message Headers 736 See [H4.2] 738 4.3 Message Body 740 See [H4.3] 742 4.4 Message Length 744 When a message body is included with a message, the length of that 745 body is determined by one of the following (in order of precedence): 747 1. Any response message which MUST NOT include a message body 748 (such as the 1xx, 204, and 304 responses) is always terminated 749 by the first empty line after the header fields, regardless of 750 the entity-header fields present in the message. (Note: An 751 empty line consists of only CRLF.) 753 2. If a Content-Length header field (section 12.14) is present, 754 its value in bytes represents the length of the message-body. 755 If this header field is not present, a value of zero is 756 assumed. 758 Note that RTSP does not (at present) support the HTTP/1.1 "chunked" 759 transfer coding(see [H3.6.1]) and requires the presence of the Con- 760 tent-Length header field. 762 Given the moderate length of presentation descriptions 763 returned, the server should always be able to determine its 764 length, even if it is generated dynamically, making the chun- 765 ked transfer encoding unnecessary. 767 5 General Header Fields 769 See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, 770 and Warning headers are not defined: 772 general-header = Cache-Control ; Section 12.9 773 | Connection ; Section 12.10 774 | CSeq ; Section 12.17 775 | Date ; Section 12.18 776 | Via ; Section 12.44 778 6 Request 780 A request message from a client to a server or vice versa includes, 781 within the first line of that message, the method to be applied to 782 the resource, the identifier of the resource, and the protocol ver- 783 sion in use. 785 Request = Request-Line ; Section 6.1 786 *( general-header ; Section 5 787 | request-header ; Section 6.2 788 | entity-header ) ; Section 8.1 789 CRLF 791 [ message-body ] ; Section 4.3 793 6.1 Request Line 795 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 797 Method = "DESCRIBE" ; Section 10.2 798 | "ANNOUNCE" ; Section 10.3 799 | "GET_PARAMETER" ; Section 10.8 800 | "OPTIONS" ; Section 10.1 801 | "PAUSE" ; Section 10.6 802 | "PLAY" ; Section 10.5 803 | "RECORD" ; Section 10.11 804 | "REDIRECT" ; Section 10.10 805 | "SETUP" ; Section 10.4 806 | "SET_PARAMETER" ; Section 10.9 807 | "TEARDOWN" ; Section 10.7 808 | extension-method 810 extension-method = token 811 Request-URI = "*" | absolute_URI 812 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 814 6.2 Request Header Fields 816 request-header = Accept ; Section 12.1 817 | Accept-Encoding ; Section 12.2 818 | Accept-Language ; Section 12.3 819 | Authorization ; Section 12.6 820 | Bandwidth ; Section 12.7 821 | Blocksize ; Section 12.8 822 | From ; Section 12.20 823 | If-Modified-Since ; Section 12.23 824 | Proxy-Require ; Section 12.27 825 | Range ; Section 12.29 826 | Referer ; Section 12.30 827 | Require ; Section 12.32 828 | Scale ; Section 12.34 829 | Session ; Section 12.37 830 | Speed ; Section 12.35 831 | Transport ; Section 12.40 832 | User-Agent ; Section 12.42 834 Note that in contrast to HTTP/1.1 [26], RTSP requests always contain 835 the absolute URL (that is, including the scheme, host and port) 836 rather than just the absolute path. 838 HTTP/1.1 requires servers to understand the absolute URL, but 839 clients are supposed to use the Host request header. This is 840 purely needed for backward-compatibility with HTTP/1.0 841 servers, a consideration that does not apply to RTSP. 843 The asterisk "*" in the Request-URI means that the request does not 844 apply to a particular resource, but to the server itself, and is only 845 allowed when the method used does not necessarily apply to a 846 resource. One example would be: 848 OPTIONS * RTSP/1.0 850 7 Response 852 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 853 Also, RTSP defines additional status codes and does not define some 854 HTTP codes. The valid response codes and the methods they can be used 855 with are defined in Table 1. 857 After receiving and interpreting a request message, the recipient 858 responds with an RTSP response message. 860 Response = Status-Line ; Section 7.1 861 *( general-header ; Section 5 862 | response-header ; Section 7.1.2 863 | entity-header ) ; Section 8.1 864 CRLF 865 [ message-body ] ; Section 4.3 867 7.1 Status-Line 869 The first line of a Response message is the Status-Line, consisting 870 of the protocol version followed by a numeric status code, and the 871 textual phrase associated with the status code, with each element 872 separated by SP characters. No CR or LF is allowed except in the 873 final CRLF sequence. 875 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 877 7.1.1 Status Code and Reason Phrase 879 The Status-Code element is a 3-digit integer result code of the 880 attempt to understand and satisfy the request. These codes are fully 881 defined in Section 11. The Reason-Phrase is intended to give a short 882 textual description of the Status-Code. The Status-Code is intended 883 for use by automata and the Reason-Phrase is intended for the human 884 user. The client is not required to examine or display the Reason- 885 Phrase. 887 The first digit of the Status-Code defines the class of response. The 888 last two digits do not have any categorization role. There are 5 889 values for the first digit: 891 + 1xx: Informational - Request received, continuing process 893 + 2xx: Success - The action was successfully received, understood, 894 and accepted 896 + 3xx: Redirection - Further action must be taken in order to com- 897 plete the request 899 + 4xx: Client Error - The request contains bad syntax or cannot be 900 fulfilled 902 + 5xx: Server Error - The server failed to fulfill an apparently 903 valid request 905 The individual values of the numeric status codes defined for 906 RTSP/1.0, and an example set of corresponding Reason-Phrase's, are 907 presented below. The reason phrases listed here are only recommended 908 -- they may be replaced by local equivalents without affecting the 909 protocol. Note that RTSP adopts most HTTP/1.1 [26] status codes and 910 adds RTSP-specific status codes starting at x50 to avoid conflicts 911 with newly defined HTTP status codes. 913 Status-Code = "100" ; Continue 914 | "200" ; OK 915 | "201" ; Created 916 | "250" ; Low on Storage Space 917 | "300" ; Multiple Choices 918 | "301" ; Moved Permanently 919 | "302" ; Moved Temporarily 920 | "303" ; See Other 921 | "304" ; Not Modified 922 | "305" ; Use Proxy 923 | "400" ; Bad Request 924 | "401" ; Unauthorized 925 | "402" ; Payment Required 926 | "403" ; Forbidden 927 | "404" ; Not Found 928 | "405" ; Method Not Allowed 929 | "406" ; Not Acceptable 930 | "407" ; Proxy Authentication Required 931 | "408" ; Request Time-out 932 | "410" ; Gone 933 | "411" ; Length Required 934 | "412" ; Precondition Failed 935 | "413" ; Request Entity Too Large 936 | "414" ; Request-URI Too Large 937 | "415" ; Unsupported Media Type 938 | "451" ; Parameter Not Understood 939 | "452" ; reserved 940 | "453" ; Not Enough Bandwidth 941 | "454" ; Session Not Found 942 | "455" ; Method Not Valid in This State 943 | "456" ; Header Field Not Valid for Resource 944 | "457" ; Invalid Range 945 | "458" ; Parameter Is Read-Only 946 | "459" ; Aggregate operation not allowed 947 | "460" ; Only aggregate operation allowed 948 | "461" ; Unsupported transport 949 | "462" ; Destination unreachable 950 | "500" ; Internal Server Error 951 | "501" ; Not Implemented 952 | "502" ; Bad Gateway 953 | "503" ; Service Unavailable 954 | "504" ; Gateway Time-out 955 | "505" ; RTSP Version not supported 956 | "551" ; Option not supported 957 | extension-code 959 extension-code = 3DIGIT 960 Reason-Phrase = * 962 RTSP status codes are extensible. RTSP applications are not required 963 to understand the meaning of all registered status codes, though such 964 understanding is obviously desirable. However, applications MUST 965 understand the class of any status code, as indicated by the first 966 digit, and treat any unrecognized response as being equivalent to the 967 x00 status code of that class, with the exception that an unrecog- 968 nized response MUST NOT be cached. For example, if an unrecognized 969 status code of 431 is received by the client, it can safely assume 970 that there was something wrong with its request and treat the 971 response as if it had received a 400 status code. In such cases, user 972 agents SHOULD present to the user the entity returned with the 973 response, since that entity is likely to include human-readable 974 information which will explain the unusual status. 976 7.1.2 Response Header Fields 978 The response-header fields allow the request recipient to pass addi- 979 tional information about the response which cannot be placed in the 980 Status-Line. These header fields give information about the server 981 and about further access to the resource identified by the Request- 982 URI. 984 response-header = Location ; Section 12.25 985 | Proxy-Authenticate ; Section 12.26 986 | Public ; Section 12.28 987 | Range ; Section 12.29 988 | Retry-After ; Section 12.31 989 | RTP-Info ; Section 12.33 990 | Scale ; Section 12.34 991 | Session ; Section 12.37 992 | Server ; Section 12.36 993 | Speed ; Section 12.35 994 | Transport ; Section 12.40 995 | Unsupported ; Section 12.41 996 | Vary ; Section 12.43 997 | WWW-Authenticate ; Section 12.45 999 Response-header field names can be extended reliably only in combina- 1000 tion with a change in the protocol version. However, new or experi- 1001 mental header fields MAY be given the semantics of response-header 1002 fields if all parties in the communication recognize them to be 1003 response-header fields. Unrecognized header fields are treated as 1004 Code reason 1005 -------------------------------------------------------- 1006 100 Continue all 1007 -------------------------------------------------------- 1008 200 OK all 1009 201 Created RECORD 1010 250 Low on Storage Space RECORD 1011 -------------------------------------------------------- 1012 300 Multiple Choices all 1013 301 Moved Permanently all 1014 302 Moved Temporarily all 1015 303 See Other all 1016 305 Use Proxy all 1017 -------------------------------------------------------- 1018 400 Bad Request all 1019 401 Unauthorized all 1020 402 Payment Required all 1021 403 Forbidden all 1022 404 Not Found all 1023 405 Method Not Allowed all 1024 406 Not Acceptable all 1025 407 Proxy Authentication Required all 1026 408 Request Timeout all 1027 410 Gone all 1028 411 Length Required all 1029 412 Precondition Failed DESCRIBE, SETUP 1030 413 Request Entity Too Large all 1031 414 Request-URI Too Long all 1032 415 Unsupported Media Type all 1033 451 Parameter Not Understood SETUP 1034 452 reserved n/a 1035 453 Not Enough Bandwidth SETUP 1036 454 Session Not Found all 1037 455 Method Not Valid In This State all 1038 456 Header Field Not Valid all 1039 457 Invalid Range PLAY 1040 458 Parameter Is Read-Only SET_PARAMETER 1041 459 Aggregate Operation Not Allowed all 1042 460 Only Aggregate Operation Allowed all 1043 461 Unsupported Transport all 1044 462 Destination Unreachable all 1045 -------------------------------------------------------- 1046 500 Internal Server Error all 1047 501 Not Implemented all 1048 502 Bad Gateway all 1049 503 Service Unavailable all 1050 504 Gateway Timeout all 1051 505 RTSP Version Not Supported all 1052 551 Option not support all 1054 Table 1: Status codes and their usage with RTSP methods 1056 entity-header fields. 1058 8 Entity 1060 Request and Response messages MAY transfer an entity if not otherwise 1061 restricted by the request method or response status code. An entity 1062 consists of entity-header fields and an entity-body, although some 1063 responses will only include the entity-headers. 1065 In this section, both sender and recipient refer to either the client 1066 or the server, depending on who sends and who receives the entity. 1068 8.1 Entity Header Fields 1070 Entity-header fields define optional metainformation about the 1071 entity-body or, if no body is present, about the resource identified 1072 by the request. 1074 entity-header = Allow ; Section 12.5 1075 | Content-Base ; Section 12.11 1076 | Content-Encoding ; Section 12.12 1077 | Content-Language ; Section 12.13 1078 | Content-Length ; Section 12.14 1079 | Content-Location ; Section 12.15 1080 | Content-Type ; Section 12.16 1081 | Expires ; Section 12.19 1082 | Last-Modified ; Section 12.24 1083 | extension-header 1084 extension-header = message-header 1086 The extension-header mechanism allows additional entity-header fields 1087 to be defined without changing the protocol, but these fields cannot 1088 be assumed to be recognizable by the recipient. Unrecognized header 1089 fields SHOULD be ignored by the recipient and forwarded by proxies. 1091 8.2 Entity Body 1093 See [H7.2] 1095 9 Connections 1097 RTSP requests can be transmitted in several different ways: 1099 + persistent transport connections used for several request- 1100 response transactions; 1102 + one connection per request/response transaction; 1104 + connectionless mode. 1106 The type of transport connection is defined by the RTSP URI (Section 1107 3.2). For the scheme "rtsp", a persistent connection is assumed, 1108 while the scheme "rtspu" calls for RTSP requests to be sent without 1109 setting up a connection. 1111 Unlike HTTP, RTSP allows the media server to send requests to the 1112 media client. However, this is only supported for persistent connec- 1113 tions, as the media server otherwise has no reliable way of reaching 1114 the client. Also, this is the only way that requests from media 1115 server to client are likely to traverse firewalls. 1117 9.1 Pipelining 1119 A client that supports persistent connections or connectionless mode 1120 MAY "pipeline" its requests (i.e., send multiple requests without 1121 waiting for each response). A server MUST send its responses to those 1122 requests in the same order that the requests were received. 1124 9.2 Reliability and Acknowledgements 1126 Requests are acknowledged by the receiver unless they are sent to a 1127 multicast group. If there is no acknowledgement, the sender may 1128 resend the same message after a timeout of one round-trip time (RTT). 1129 The round-trip time is estimated as in TCP (RFC 1123) [15], with an 1130 initial round-trip value of 500 ms. An implementation MAY cache the 1131 last RTT measurement as the initial value for future connections. 1133 If a reliable transport protocol is used to carry RTSP, requests MUST 1134 NOT be retransmitted; the RTSP application MUST instead rely on the 1135 underlying transport to provide reliability. 1137 If both the underlying reliable transport such as TCP and the 1138 RTSP application retransmit requests, it is possible that each 1139 packet loss results in two retransmissions. The receiver can- 1140 not typically take advantage of the application-layer retrans- 1141 mission since the transport stack will not deliver the 1142 application-layer retransmission before the first attempt has 1143 reached the receiver. If the packet loss is caused by conges- 1144 tion, multiple retransmissions at different layers will exac- 1145 erbate the congestion. 1147 If RTSP is used over a small-RTT LAN, standard procedures for opti- 1148 mizing initial TCP round trip estimates, such as those used in T/TCP 1149 (RFC 1644) [19], can be beneficial. 1151 The Timestamp header (Section 12.39) is used to avoid the retransmis- 1152 sion ambiguity problem [20] and obviates the need for Karn's algo- 1153 rithm. 1155 Each request carries a sequence number in the CSeq header (Section 1156 12.17), which is incremented by one for each distinct request trans- 1157 mitted. If a request is repeated because of lack of acknowledgement, 1158 the request MUST carry the original sequence number (i.e., the 1159 sequence number is not incremented). 1161 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1162 support UDP. The default port for the RTSP server is 554 for both UDP 1163 and TCP. 1165 A number of RTSP packets destined for the same control end point may 1166 be packed into a single lower-layer PDU or encapsulated into a TCP 1167 stream. RTSP data MAY be interleaved with RTP and RTCP packets. 1168 Unlike HTTP, an RTSP message MUST contain a Content-Length header 1169 field whenever that message contains a payload. Otherwise, an RTSP 1170 packet is terminated with an empty line immediately following the 1171 last message header. 1173 10 Method Definitions 1175 The method token indicates the method to be performed on the resource 1176 identified by the Request-URI case-sensitive. New methods may be 1177 defined in the future. Method names may not start with a $ character 1178 (decimal 24) and must be a token. Methods are summarized in Table 2. 1180 Notes on Table 2: PAUSE is recommended, but not required in that a 1181 fully functional server can be built that does not support this 1182 method, for example, for live feeds. If a server does not support a 1183 particular method, it MUST return 501 (Not Implemented) and a client 1184 SHOULD not try this method again for this server. 1186 10.1 OPTIONS 1187 method direction object requirement 1188 ------------------------------------------------------------- 1189 DESCRIBE C->S P,S recommended 1190 ANNOUNCE C->S, S->C P,S optional 1191 GET_PARAMETER C->S, S->C P,S optional 1192 OPTIONS C->S, S->C P,S required (S->C: optional) 1193 PAUSE C->S P,S recommended 1194 PING C->S, S->C P,S optional 1195 PLAY C->S P,S required 1196 RECORD C->S P,S optional 1197 REDIRECT S->C P,S optional 1198 SETUP C->S S required 1199 SET_PARAMETER C->S, S->C P,S optional 1200 TEARDOWN C->S P,S required 1202 Table 2: Overview of RTSP methods, their direction, and what objects 1203 (P: presentation, S: stream) they operate on 1205 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1206 request may be issued at any time, e.g., if the client is about to 1207 try a nonstandard request. It does not influence server state. 1209 Example: 1211 C->S: OPTIONS * RTSP/1.0 1212 CSeq: 1 1213 Require: implicit-play 1214 Proxy-Require: gzipped-messages 1216 S->C: RTSP/1.0 200 OK 1217 CSeq: 1 1218 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1220 Note that these are necessarily fictional features (one would hope 1221 that we would not purposefully overlook a truly useful feature just 1222 so that we could have a strong example in this section). 1224 10.2 DESCRIBE 1226 The DESCRIBE method retrieves the description of a presentation or 1227 media object identified by the request URL from a server. It may use 1228 the Accept header to specify the description formats that the client 1229 understands. The server responds with a description of the requested 1230 resource. The DESCRIBE reply-response pair constitutes the media ini- 1231 tialization phase of RTSP. 1233 Example: 1235 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 1236 CSeq: 312 1237 Accept: application/sdp, application/rtsl, application/mheg 1239 S->C: RTSP/1.0 200 OK 1240 CSeq: 312 1241 Date: 23 Jan 1997 15:35:06 GMT 1242 Content-Type: application/sdp 1243 Content-Length: 376 1245 v=0 1246 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1247 s=SDP Seminar 1248 i=A Seminar on the session description protocol 1249 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1250 e=mjh@isi.edu (Mark Handley) 1251 c=IN IP4 224.2.17.12/127 1252 t=2873397496 2873404696 1253 a=recvonly 1254 m=audio 3456 RTP/AVP 0 1255 m=video 2232 RTP/AVP 31 1256 m=whiteboard 32416 UDP WB 1257 a=orient:portrait 1259 The DESCRIBE response MUST contain all media initialization informa- 1260 tion for the resource(s) that it describes. If a media client obtains 1261 a presentation description from a source other than DESCRIBE and that 1262 description contains a complete set of media initialization parame- 1263 ters, the client SHOULD use those parameters and not then request a 1264 description for the same media via RTSP. 1266 Additionally, servers SHOULD NOT use the DESCRIBE response as a means 1267 of media indirection. 1269 By forcing a DESCRIBE response to contain all media initial- 1270 ization for the set of streams that it describes, and discour- 1271 aging use of DESCRIBE for media indirection, we avoid looping 1272 problems that might result from other approaches. 1274 Media initialization is a requirement for any RTSP-based system, but 1275 the RTSP specification does not dictate that this must be done via 1276 the DESCRIBE method. There are three ways that an RTSP client may 1277 receive initialization information: 1279 + via RTSP's DESCRIBE method; 1281 + via some other protocol (HTTP, email attachment, etc.); 1283 + via the command line or standard input (thus working as a browser 1284 helper application launched with an SDP file or other media ini- 1285 tialization format). 1287 It is RECOMMENDED that minimal servers support the DESCRIBE method, 1288 and highly recommended that minimal clients support the ability to 1289 act as a "helper application" that accepts a media initialization 1290 file from standard input, command line, and/or other means that are 1291 appropriate to the operating environment of the client. 1293 10.3 ANNOUNCE 1295 The ANNOUNCE method serves two purposes: 1297 When sent from client to server, ANNOUNCE posts the description of a 1298 presentation or media object identified by the request URL to a 1299 server. When sent from server to client, ANNOUNCE updates the ses- 1300 sion description in real-time. 1302 If a new media stream is added to a presentation (e.g., during a live 1303 presentation), the whole presentation description should be sent 1304 again, rather than just the additional components, so that components 1305 can be deleted. 1307 Example: 1309 C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0 1310 CSeq: 312 1311 Date: 23 Jan 1997 15:35:06 GMT 1312 Session: 47112344 1313 Content-Type: application/sdp 1314 Content-Length: 332 1316 v=0 1317 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 1318 s=SDP Seminar 1319 i=A Seminar on the session description protocol 1320 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1321 e=mjh@isi.edu (Mark Handley) 1322 c=IN IP4 224.2.17.12/127 1323 t=2873397496 2873404696 1324 a=recvonly 1325 m=audio 3456 RTP/AVP 0 1326 m=video 2232 RTP/AVP 31 1328 S->C: RTSP/1.0 200 OK 1329 CSeq: 312 1331 10.4 SETUP 1333 The SETUP request for a URI specifies the transport mechanism to be 1334 used for the streamed media. A client can issue a SETUP request for a 1335 stream that is already playing to change transport parameters, which 1336 a server MAY allow. If it does not allow this, it MUST respond with 1337 error 455 (Method Not Valid In This State). For the benefit of any 1338 intervening firewalls, a client must indicate the transport parame- 1339 ters even if it has no influence over these parameters, for example, 1340 where the server advertises a fixed multicast address. 1342 Since SETUP includes all transport initialization information, 1343 firewalls and other intermediate network devices (which need 1344 this information) are spared the more arduous task of parsing 1345 the DESCRIBE response, which has been reserved for media ini- 1346 tialization. 1348 The Transport header specifies the transport parameters acceptable to 1349 the client for data transmission; the response will contain the 1350 transport parameters selected by the server. 1352 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 1353 CSeq: 302 1354 Transport: RTP/AVP;unicast;client_port=4588-4589 1356 S->C: RTSP/1.0 200 OK 1357 CSeq: 302 1358 Date: 23 Jan 1997 15:35:06 GMT 1359 Session: 47112344 1360 Transport: RTP/AVP;unicast; 1361 client_port=4588-4589;server_port=6256-6257 1363 The server generates session identifiers in response to SETUP 1364 requests. If a SETUP request to a server includes a session identi- 1365 fier, the server MUST bundle this setup request into the existing 1366 session or return error 459 (Aggregate Operation Not Allowed) (see 1367 Section 11.4.10). 1369 10.5 PLAY 1371 The PLAY method tells the server to start sending data via the mecha- 1372 nism specified in SETUP. A client MUST NOT issue a PLAY request until 1373 any outstanding SETUP requests have been acknowledged as successful. 1375 The PLAY request positions the normal play time to the beginning of 1376 the range specified and delivers stream data until the end of the 1377 range is reached. PLAY requests may be pipelined (queued); a server 1378 MUST queue PLAY requests to be executed in order. That is, a PLAY 1379 request arriving while a previous PLAY request is still active is 1380 delayed until the first has been completed. 1382 This allows precise editing. For example, regardless of how 1383 closely spaced the two PLAY requests in the example below 1384 arrive, the server will first play seconds 10 through 15, 1385 then, immediately following, seconds 20 to 25, and finally 1386 seconds 30 through the end. 1388 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1389 CSeq: 835 1390 Session: 12345678 1391 Range: npt=10-15 1393 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1394 CSeq: 836 1395 Session: 12345678 1396 Range: npt=20-25 1398 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1399 CSeq: 837 1400 Session: 12345678 1401 Range: npt=30- 1403 See the description of the PAUSE request for further examples. 1405 A PLAY request without a Range header is legal. It starts playing a 1406 stream from the beginning unless the stream has been paused. If a 1407 stream has been paused via PAUSE, stream delivery resumes at the 1408 pause point. 1410 The Range header may also contain a time parameter. This parameter 1411 specifies a time in UTC at which the playback should start. If the 1412 message is received after the specified time, playback is started 1413 immediately. The time parameter may be used to aid in synchronization 1414 of streams obtained from different sources. 1416 For a on-demand stream, the server replies with the actual range that 1417 will be played back. This may differ from the requested range if 1418 alignment of the requested range to valid frame boundaries is 1419 required for the media source. If no range is specified in the 1420 request, the current position is returned in the reply. The unit of 1421 the range in the reply is the same as that in the request. 1423 After playing the desired range, the presentation is automatically 1424 paused, as if a PAUSE request had been issued. 1426 The following example plays the whole presentation starting at SMPTE 1427 time code 0:10:20 until the end of the clip. The playback is to start 1428 at 15:36 on 23 Jan 1997. 1430 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 1431 CSeq: 833 1432 Session: 12345678 1433 Range: smpte=0:10:20-;time=19970123T153600Z 1435 S->C: RTSP/1.0 200 OK 1436 CSeq: 833 1437 Date: 23 Jan 1997 15:35:06 GMT 1438 Range: smpte=0:10:22-;time=19970123T153600Z 1439 RTP-Info:url=rtsp://audio.example.com/twister.en;seq=14783;rtptime=2345962545 1441 For playing back a recording of a live presentation, it may be desir- 1442 able to use clock units: 1444 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 1445 CSeq: 835 1446 Session: 12345678 1447 Range: clock=19961108T142300Z-19961108T143520Z 1449 S->C: RTSP/1.0 200 OK 1450 CSeq: 835 1451 Date: 23 Jan 1997 15:35:06 GMT 1452 Range: clock=19961108T142300Z-19961108T143520Z 1453 RTP-Info:url=rtsp://audio.example.com/meeting.en;seq=53745;rtptime=484589019 1455 A media server only supporting playback MUST support the npt format 1456 and MAY support the clock and smpte formats. 1458 All range specifiers in this specification allow for ranges with | 1459 unspecified begin times (e.g. "npt=-30"). When used in a PLAY | 1460 request, the server treats this as a request to start/resume playback | 1461 from the current pause point, ending at the end time specified in the | 1462 Range header. 1464 10.6 PAUSE 1466 The PAUSE request causes the stream delivery to be interrupted 1467 (halted) temporarily. If the request URL names a stream, only play- 1468 back and recording of that stream is halted. For example, for audio, 1469 this is equivalent to muting. If the request URL names a presentation 1470 or group of streams, delivery of all currently active streams within 1471 the presentation or group is halted. After resuming playback or 1472 recording, synchronization of the tracks MUST be maintained. Any 1473 server resources are kept, though servers MAY close the session and 1474 free resources after being paused for the duration specified with the 1475 timeout parameter of the Session header in the SETUP message. 1477 Example: 1479 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1480 CSeq: 834 1481 Session: 12345678 1483 S->C: RTSP/1.0 200 OK 1484 CSeq: 834 1485 Date: 23 Jan 1997 15:35:06 GMT 1487 The PAUSE request may contain a Range header specifying when the | 1488 stream or presentation is to be halted. We refer to this point as the | 1489 "pause point". The header must contain a single value, expressed as | 1490 the beginning value an open range. For example, the following clip | 1491 will be played from 10 seconds through 21 seconds of the clip's nor- | 1492 mal play time: | 1493 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/1.0 | 1494 CSeq: 834 | 1495 Session: 12345678 | 1496 Range: npt=10-30 | 1498 S->C: RTSP/1.0 200 OK | 1499 CSeq: 834 | 1500 Date: 23 Jan 1997 15:35:06 GMT | 1501 Range: npt=10-30 | 1502 RTP-Info:url=rtsp://example.com/fizzle/foo/audiotrack;seq=5712;rtptime=934207921,| 1503 url=rtsp://example.com/fizzle/foo/videotrack;seq=57654;rtptime=2792482193| 1505 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 | 1506 CSeq: 835 | 1507 Session: 12345678 | 1508 Range: npt=21- | 1510 S->C: RTSP/1.0 200 OK | 1511 CSeq: 835 | 1512 Date: 23 Jan 1997 15:35:09 GMT | 1513 Range: npt=21- | 1515 The normal play time for the stream is set to the pause point. The 1516 pause request becomes effective the first time the server is encoun- 1517 tering the time point specified in any of the currently pending PLAY 1518 requests. If the Range header specifies a time outside any currently 1519 pending PLAY requests, the error 457 (Invalid Range) is returned. If 1520 a media unit (such as an audio or video frame) starts presentation at 1521 exactly the pause point, it is not played or recorded. If the Range 1522 header is missing, stream delivery is interrupted immediately on 1523 receipt of the message and the pause point is set to the current nor- 1524 mal play time. 1526 A PAUSE request discards all queued PLAY requests. However, the pause 1527 point in the media stream MUST be maintained. A subsequent PLAY 1528 request without Range header resumes from the pause point. 1530 For example, if the server has play requests for ranges 10 to 15 and 1531 20 to 29 pending and then receives a pause request for NPT 21, it 1532 would start playing the second range and stop at NPT 21. If the pause 1533 request is for NPT 12 and the server is playing at NPT 13 serving the 1534 first play request, the server stops immediately. If the pause 1535 request is for NPT 16, the server stops after completing the first 1536 play request and discards the second play request. 1538 As another example, if a server has received requests to play ranges 1539 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 1540 request for NPT=14 would take effect while the server plays the first 1541 range, with the second PLAY request effectively being ignored, assum- 1542 ing the PAUSE request arrives before the server has started playing 1543 the second, overlapping range. Regardless of when the PAUSE request 1544 arrives, it sets the NPT to 14. 1546 If the server has already sent data beyond the time specified in the 1547 Range header, a PLAY would still resume at that point in time, as it 1548 is assumed that the client has discarded data after that point. This 1549 ensures continuous pause/play cycling without gaps. 1551 10.7 TEARDOWN 1553 The TEARDOWN request stops the stream delivery for the given URI, 1554 freeing the resources associated with it. If the URI is the presenta- 1555 tion URI for this presentation, any RTSP session identifier associ- 1556 ated with the session is no longer valid. Unless all transport param- 1557 eters are defined by the session description, a SETUP request has to 1558 be issued before the session can be played again. 1560 A server that after processing the TEARDOWN still has a valid session 1561 MUST in the response return a session header. 1563 Example: 1565 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 1566 CSeq: 892 1567 Session: 12345678 1569 S->C: RTSP/1.0 200 OK 1570 CSeq: 892 1572 10.8 GET_PARAMETER 1574 The GET_PARAMETER request retrieves the value of a parameter of a 1575 presentation or stream specified in the URI. The content of the reply 1576 and response is left to the implementation. GET_PARAMETER with no 1577 entity body may be used to test client or server liveness ("ping"). 1579 Example: 1581 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1582 CSeq: 431 1583 Content-Type: text/parameters 1584 Session: 12345678 1585 Content-Length: 15 1587 packets_received 1588 jitter 1590 C->S: RTSP/1.0 200 OK 1591 CSeq: 431 1592 Content-Length: 46 1593 Content-Type: text/parameters 1595 packets_received: 10 1596 jitter: 0.3838 1598 The "text/parameters" section is only an example type for 1599 parameter. This method is intentionally loosely defined with 1600 the intention that the reply content and response content will 1601 be defined after further experimentation. 1603 10.9 SET_PARAMETER 1605 This method requests to set the value of a parameter for a presenta- 1606 tion or stream specified by the URI. 1608 A request SHOULD only contain a single parameter to allow the client 1609 to determine why a particular request failed. If the request contains 1610 several parameters, the server MUST only act on the request if all of 1611 the parameters can be set successfully. A server MUST allow a parame- 1612 ter to be set repeatedly to the same value, but it MAY disallow 1613 changing parameter values. 1615 Note: transport parameters for the media stream MUST only be set with 1616 the SETUP command. 1618 Restricting setting transport parameters to SETUP is for the 1619 benefit of firewalls. 1621 The parameters are split in a fine-grained fashion so that 1622 there can be more meaningful error indications. However, it 1623 may make sense to allow the setting of several parameters if 1624 an atomic setting is desirable. Imagine device control where 1625 the client does not want the camera to pan unless it can also 1626 tilt to the right angle at the same time. 1628 Example: 1630 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1631 CSeq: 421 1632 Content-length: 20 1633 Content-type: text/parameters 1635 barparam: barstuff 1637 S->C: RTSP/1.0 451 Parameter Not Understood 1638 CSeq: 421 1639 Content-length: 10 1640 Content-type: text/parameters 1642 barparam 1644 The "text/parameters" section is only an example type for 1645 parameter. This method is intentionally loosely defined with 1646 the intention that the reply content and response content will 1647 be defined after further experimentation. 1649 10.10 REDIRECT 1651 A redirect request informs the client that it must connect to another 1652 server location. It contains the mandatory header Location, which 1653 indicates that the client should issue requests for that URL. It may 1654 contain the parameter Range, which indicates when the redirection 1655 takes effect. If the client wants to continue to send or receive 1656 media for this URI, the client MUST issue a TEARDOWN request for the 1657 current session and a SETUP for the new session at the designated 1658 host. 1660 This example request redirects traffic for this URI to the new server 1661 at the given play time: 1663 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 1664 CSeq: 732 1665 Location: rtsp://bigserver.com:8001 1666 Range: clock=19960213T143205Z- 1668 10.11 RECORD 1670 This method initiates recording a range of media data according to 1671 the presentation description. The timestamp reflects start and end 1672 time (UTC). If no time range is given, use the start or end time pro- 1673 vided in the presentation description. If the session has already 1674 started, commence recording immediately. 1676 The server decides whether to store the recorded data under the 1677 request-URI or another URI. If the server does not use the request- 1678 URI, the response SHOULD be 201 (Created) and contain an entity which 1679 describes the status of the request and refers to the new resource, 1680 and a Location header. 1682 A media server supporting recording of live presentations MUST sup- 1683 port the clock range format; the smpte format does not make sense. 1685 In this example, the media server was previously invited to the con- 1686 ference indicated. 1688 C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 1689 CSeq: 954 1690 Session: 12345678 1691 Conference: 128.16.64.19/32492374 1693 Note: this example needs work, or needs to be removed. 1695 10.12 PING | 1697 This method is a bi-directional mechanism for server or client live- | 1698 ness checking. It has no side effects. | 1700 Prior to using this method, an OPTIONS method MUST be issued in the | 1701 direction which the PING method would be used. This method MUST NOT | 1702 be used if support is not indicated by the Public header. | 1704 When a proxy is in use, PING with a * indicates a single-hop liveness | 1705 check, whereas PING with a URL indicates an end-to-end liveness | 1706 check. | 1708 Example: | 1710 C->S: PING * RTSP/1.0 | 1711 CSeq: 123 | 1713 S->C: RTSP/1.0 200 OK | 1714 CSeq: 123 | 1716 10.13 Embedded (Interleaved) Binary Data 1718 Certain firewall designs and other circumstances may force a server 1719 to interleave RTSP methods and stream data. This interleaving should 1720 generally be avoided unless necessary since it complicates client and 1721 server operation and imposes additional overhead. Interleaved binary 1722 data SHOULD only be used if RTSP is carried over TCP. 1724 Stream data such as RTP packets is encapsulated by an ASCII dollar 1725 sign (24 decimal), followed by a one-byte channel identifier, fol- 1726 lowed by the length of the encapsulated binary data as a binary, two- 1727 byte integer in network byte order. The stream data follows immedi- 1728 ately afterwards, without a CRLF, but including the upper-layer pro- 1729 tocol headers. Each $ block contains exactly one upper-layer protocol 1730 data unit, e.g., one RTP packet. 1732 The channel identifier is defined in the Transport header with the 1733 interleaved parameter(Section 12.40). 1735 When the transport choice is RTP, RTCP messages are also interleaved 1736 by the server over the TCP connection. As a default, RTCP packets are 1737 sent on the first available channel higher than the RTP channel. The 1738 client MAY explicitly request RTCP packets on another channel. This 1739 is done by specifying two channels in the interleaved parameter of 1740 the Transport header(Section 12.40). 1742 RTCP is needed for synchronization when two or more streams 1743 are interleaved in such a fashion. Also, this provides a con- 1744 venient way to tunnel RTP/RTCP packets through the TCP control 1745 connection when required by the network configuration and 1746 transfer them onto UDP when possible. 1748 C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 1749 CSeq: 2 1750 Transport: RTP/AVP/TCP;interleaved=0-1 1752 S->C: RTSP/1.0 200 OK 1753 CSeq: 2 1754 Date: 05 Jun 1997 18:57:18 GMT 1755 Transport: RTP/AVP/TCP;interleaved=0-1 1756 Session: 12345678 1758 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 1759 CSeq: 3 1760 Session: 12345678 1762 S->C: RTSP/1.0 200 OK 1763 CSeq: 3 1764 Session: 12345678 1765 Date: 05 Jun 1997 18:59:15 GMT 1766 RTP-Info: url=rtsp://foo.com/bar.file; 1767 seq=232433;rtptime=972948234 1769 S->C: $000{2 byte length}{"length" bytes data, w/RTP header} 1770 S->C: $000{2 byte length}{"length" bytes data, w/RTP header} 1771 S->C: $001{2 byte length}{"length" bytes RTCP packet} 1773 11 Status Code Definitions 1775 Where applicable, HTTP status [H10] codes are reused. Status codes 1776 that have the same meaning are not repeated here. See Table 1 for a 1777 listing of which status codes may be returned by which requests. 1779 11.1 Success 2xx 1781 11.1.1 250 Low on Storage Space 1783 The server returns this warning after receiving a RECORD request that 1784 it may not be able to fulfill completely due to insufficient storage 1785 space. If possible, the server should use the Range header to indi- 1786 cate what time period it may still be able to record. Since other 1787 processes on the server may be consuming storage space simultane- 1788 ously, a client should take this only as an estimate. 1790 11.2 Redirection 3xx 1792 See [H10.3]. 1794 Within RTSP, redirection may be used for load balancing or redirect- 1795 ing stream requests to a server topologically closer to the client. 1796 Mechanisms to determine topological proximity are beyond the scope of 1797 this specification. 1799 11.3 Client Error 4xx 1800 11.4 400 Bad Request 1802 The request could not be understood by the server due to malformed 1803 syntax. The client SHOULD NOT repeat the request without modifica- 1804 tions [H10.4.1]. If the request does not have a CSeq header, the 1805 server MUST not include a CSeq in the response. 1807 11.4.1 405 Method Not Allowed 1809 The method specified in the request is not allowed for the resource 1810 identified by the request URI. The response MUST include an Allow 1811 header containing a list of valid methods for the requested resource. 1812 This status code is also to be used if a request attempts to use a 1813 method not indicated during SETUP, e.g., if a RECORD request is 1814 issued even though the mode parameter in the Transport header only 1815 specified PLAY. 1817 11.4.2 451 Parameter Not Understood 1819 The recipient of the request does not support one or more parameters 1820 contained in the request. 1822 11.4.3 452 reserved 1824 This error code was removed from RFC 2326 [21] and is obsolete. 1826 11.4.4 453 Not Enough Bandwidth 1828 The request was refused because there was insufficient bandwidth. 1829 This may, for example, be the result of a resource reservation fail- 1830 ure. 1832 11.4.5 454 Session Not Found 1834 The RTSP session identifier in the Session header is missing, 1835 invalid, or has timed out. 1837 11.4.6 455 Method Not Valid in This State 1839 The client or server cannot process this request in its current 1840 state. The response SHOULD contain an Allow header to make error 1841 recovery easier. 1843 11.4.7 456 Header Field Not Valid for Resource 1845 The server could not act on a required request header. For example, 1846 if PLAY contains the Range header field but the stream does not allow 1847 seeking. 1849 11.4.8 457 Invalid Range 1851 The Range value given is out of bounds, e.g., beyond the end of the 1852 presentation. 1854 11.4.9 458 Parameter Is Read-Only 1856 The parameter to be set by SET_PARAMETER can be read but not modi- 1857 fied. 1859 11.4.10 459 Aggregate Operation Not Allowed 1861 The requested method may not be applied on the URL in question since 1862 it is an aggregate (presentation) URL. The method may be applied on a 1863 stream URL. 1865 11.4.11 460 Only Aggregate Operation Allowed 1867 The requested method may not be applied on the URL in question since 1868 it is not an aggregate (presentation) URL. The method may be applied 1869 on the presentation URL. 1871 11.4.12 461 Unsupported Transport 1873 The Transport field did not contain a supported transport specifica- 1874 tion. 1876 11.4.13 462 Destination Unreachable 1878 The data transmission channel could not be established because the 1879 client address could not be reached. This error will most likely be 1880 the result of a client attempt to place an invalid Destination param- 1881 eter in the Transport field. 1883 11.5 Server Error 5xx 1885 11.5.1 551 Option not supported 1887 An option given in the Require or the Proxy-Require fields was not 1888 supported. The Unsupported header should be returned stating the 1889 option for which there is no support. 1891 12 Header Field Definitions 1893 The general syntax for header fields is covered in Section 4.2 This | 1894 section lists the full set of header fields along with notes on | 1895 method direction object requirement acronym Body 1896 ----------------------------------------------------------- 1897 DESCRIBE C->S P,S recommended DES r 1898 ANNOUNCE C->S, S->C P,S optional ANN R 1899 GET_PARAMETER C->S, S->C P,S optional GPR R,r 1900 OPTIONS C->S P,S required OPT 1901 S->C optional 1902 PAUSE C->S P,S recommended PSE 1903 PING C->S, S->C P,S optional PNG 1904 PLAY C->S P,S required PLY 1905 RECORD C->S P,S optional REC 1906 REDIRECT S->C P,S optional RDR 1907 SETUP C->S S required STP 1908 SET_PARAMETER C->S, S->C P,S optional SPR R,r? 1909 TEARDOWN C->S P,S required TRD 1911 Table 3: Overview of RTSP methods, their direction, and what objects 1912 (P: presentation, S: stream) they operate on. Body notes if a method 1913 is allowed to carry body and in which direction, R = Request, 1914 r=response. Note: There has been some usage of the body to convey 1915 more information in error messages for responses containing error 1916 codes. Some error messages seem to mandate such usage. 1918 syntax, meaning, and usage. Throughout this section, we use [HX.Y] | 1919 to refer to Section X.Y of the current HTTP/1.1 specification RFC | 1920 2616 [26]. Examples of each header field are given. | 1922 Information about header fields in relation to methods and proxy pro- | 1923 cessing is summarized in Table 4. | 1925 The "where" column describes the request and response types in which | 1926 the header field can be used. Values in this column are: | 1928 R: header field may only appear in requests; | 1930 r: header field may only appear in responses; | 1932 2xx, 4xx, etc.: A numerical value or range indicates response codes | 1933 with which the header field can be used; | 1935 c: header field is copied from the request to the response. | 1937 An empty entry in the "where" column indicates that the header field | 1938 may be present in all requests and responses. | 1940 The "proxy" column describes the operations a proxy may perform on a | 1941 header field: | 1943 a: A proxy can add or concatenate the header field if not present. | 1945 m: A proxy can modify an existing header field value. | 1947 d: A proxy can delete a header field value. | 1949 r: A proxy must be able to read the header field, and thus this | 1950 header field cannot be encrypted. | 1952 The rest of the columns relate to the presence of a header field in a | 1953 method. The method names are abbreviated according to table 3: | 1955 c: Conditional; requirements on the header field depend on the con- | 1956 text of the message. | 1958 m: The header field is mandatory. | 1960 m*: The header field SHOULD be sent, but clients/servers need to be | 1961 prepared to receive messages without that header field. | 1963 o: The header field is optional. | 1965 t: The header field SHOULD be sent, but clients/servers need to be | 1966 prepared to receive messages without that header field. If a | 1967 stream-based protocol (such as TCP) is used as a transport, | 1968 then the header field MUST be sent. | 1970 *: The header field is required if the message body is not empty. | 1971 See sections 12.14, 12.16 and 4.3 for details. | 1973 -: The header field is not applicable. | 1975 "Optional" means that a Client/Server MAY include the header field in | 1976 a request or response, and a Client/Server MAY ignore the header | 1977 field if present in the request or response (The exception to this | 1978 rule is the Require header field discussed in 12.32). A "mandatory" | 1979 header field MUST be present in a request, and MUST be understood by | 1980 the Client/Server receiving the request. A mandatory response header | 1981 field MUST be present in the response, and the header field MUST be | 1982 understood by the Client/Server processing the response. "Not | 1983 applicable" means that the header field MUST NOT be present in a | 1984 request. If one is placed in a request by mistake, it MUST be ignored | 1985 by the Client/Server receiving the request. Similarly, a header field | 1986 labeled "not applicable" for a response means that the Client/Server | 1987 MUST NOT place the header field in the response, and the | 1988 Client/Server MUST ignore the header field in the response. | 1990 A Client/Server SHOULD ignore extension header parameters that are | 1991 not understood. | 1993 The From, Location, and RTP-Info header fields contain a URI. If the | 1994 URI contains a comma, or semicolon, the URI MUST be enclosed in dou- | 1995 ble quotas ("). Any URI parameters are contained within these quotas. | 1996 If the URI is not enclosed in double quotas, any semicolon- delimited | 1997 parameters are header-parameters, not URI parameters. | 1999 12.1 Accept 2001 The Accept request-header field can be used to specify certain pre- 2002 sentation description content types which are acceptable for the 2003 response. 2005 The "level" parameter for presentation descriptions is prop- 2006 erly defined as part of the MIME type registration, not here. 2008 See [H14.1] for syntax. 2010 Example of use: 2012 Accept: application/rtsl, application/sdp;level=2 2014 12.2 Accept-Encoding 2016 See [H14.3] 2018 12.3 Accept-Language 2020 See [H14.4]. Note that the language specified applies to the presen- 2021 tation description and any reason phrases, not the media content. 2023 12.4 Accept-Ranges | 2024 Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR PNG 2025 --------------------------------------------------------------------------------- 2026 Accept R o - - - - - - - - - - - 2027 Accept-Encoding R r o - - - - - - - - - - - 2028 Accept-Language R r o - - - - - - - - - - - 2029 Accept-Ranges r - - - - - - o - - - - - 2030 Allow 405 - - - - m - m m m - - - 2031 Authorization R o o o o o o o o o o o o 2032 Bandwidth R o - - o - o o - - - - - 2033 Blocksize R o - - o - o o - - - - - 2034 Cache-Control r - - - - - o - - - - - - 2035 Connection o o o o o o o o o o o - 2036 Content-Base R - - o o o - - - - - - - 2037 Content-Base r o - o o - - - - - - - - 2038 Content-Base 4xx o o o o o o o o o o o - 2039 Content-Encoding R r - - o o o - - - - - - - 2040 Content-Encoding r r o - o o - - - - - - - - 2041 Content-Encoding 4xx r o o o o o o o o o o o - 2042 Content-Language R r - - o o o - - - - - - - 2043 Content-Language r r o - o o - - - - - - - - 2044 Content-Language 4xx r o o o o o o o o o o o - 2045 Content-Length R r - - * * * - - - - - - - 2046 Content-Length r r * - * * - - - - - - - - 2047 Content-Length 4xx r * * * * * * * * * * * - 2048 Content-Location R - - o o o - - - - - - - 2049 Content-Location r o - o o - - - - - - - - 2050 Content-Location 4xx o o o o o o o o o o o - 2051 Content-Type R - - * * * - - - - - - - 2052 Content-Type r * - * * - - - - - - - - 2053 Content-Type 4xx * * * * * * * * * * * - 2054 CSeq Rc m m m m m m m m m m m m 2055 Date am o o o o o o o o o o o o 2056 Expires r r o - - - - - - - - - - - 2057 From R r o o o o o o o o o o o o 2058 Host o o o o o o o o o o o o 2059 If-Match R r - - - - - o - - - - - - 2060 If-Modified-Since R r o - - - - o - - - - - - 2061 Last-Modified R r - - - - o - - - - - - - 2062 Last-Modified r r o - o - - - - - - - - - 2063 Location R - - - - - - - - - - m - 2064 Location 3xx m - - - - m - - - - - - 2065 Proxy-Authenticate 407 amr m m m m m m m m m m m m 2066 Proxy-Require R ar o o o o o o o o o o o o 2067 Public r admr - m* - - - - - - - - - - 2068 Public 501 admr m* m* m* m* m* m* m* m* m* m* m* m* 2069 Range R - - - - - - o - o - o - 2070 Range r - - - - - - m* - - - - - 2071 Referer R o o o o o o o o o o o - 2072 Require R o o o o o o o o o o o o 2073 Retry-After 3xx,503 o o o o - o - - - - - - 2074 RTP-Info r - - - - - - m - - - - - 2075 Scale - - - - - - o o - - - - 2076 Session R - o o o m o m m m m m m 2077 Session r - c c c m m m m m o m m 2078 Server R - o o o o - - - - - o o 2079 Server r o o o o o o o o o o - o 2080 Speed - - - - - - o - - - - - 2081 Supported R o o o o o o o o o o o o 2082 Supported r c c c c c c c c c c c c 2083 Timestamp R o o o o o o o o o o o o 2084 Timestamp c m m m m m m m m m m m m 2085 Transport - - - - - m - - - - - - 2086 Unsupported r c c c c c c c c c c c c 2087 User-Agent R m* m* m* m* m* m* m* m* m* m* - - 2088 User-Agent r - - - - - - - - - - m* - 2089 Vary r c c c c c c c c c c - - 2090 Via R amr o o o o o o o o o o o o 2091 Via c dr m m m m m m m m m m m m 2092 WWW-Authenticate 401 m m m m m m m m m m m m 2093 --------------------------------------------------------------------------------- 2094 Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR PNG 2096 Table 4: Overview of RTSP header fields 2098 12.5 Allow 2100 The Allow entity-header field lists the methods supported by the 2101 resource identified by the request-URI. The purpose of this field is 2102 to strictly inform the recipient of valid methods associated with the 2103 resource. An Allow header field must be present in a 405 (Method Not 2104 Allowed) response. 2106 Example of use: 2108 Allow: SETUP, PLAY, RECORD, SET_PARAMETER 2110 12.6 Authorization 2111 See [H14.8] 2113 12.7 Bandwidth 2115 The Bandwidth request-header field describes the estimated bandwidth 2116 available to the client, expressed as a positive integer and measured 2117 in bits per second. The bandwidth available to the client may change 2118 during an RTSP session, e.g., due to modem retraining. 2120 Bandwidth = "Bandwidth" ":" 1*DIGIT 2122 Example: 2124 Bandwidth: 4000 2126 12.8 Blocksize 2128 The Blocksize request-header field is sent from the client to the 2129 media server asking the server for a particular media packet size. 2130 This packet size does not include lower-layer headers such as IP, 2131 UDP, or RTP. The server is free to use a blocksize which is lower 2132 than the one requested. The server MAY truncate this packet size to 2133 the closest multiple of the minimum, media-specific block size, or 2134 override it with the media-specific size if necessary. The block size 2135 MUST be a positive decimal number, measured in octets. The server 2136 only returns an error (416) if the value is syntactically invalid. 2138 Blocksize = "Blocksize" ":" 1*DIGIT 2140 12.9 Cache-Control 2142 The Cache-Control general-header field is used to specify directives 2143 that MUST be obeyed by all caching mechanisms along the 2144 request/response chain. 2146 Cache directives must be passed through by a proxy or gateway appli- 2147 cation, regardless of their significance to that application, since 2148 the directives may be applicable to all recipients along the 2149 request/response chain. It is not possible to specify a cache-direc- 2150 tive for a specific cache. 2152 Cache-Control should only be specified in a SETUP request and its 2153 response. Note: Cache-Control does not govern the caching of 2154 responses as for HTTP, but rather of the stream identified by the 2155 SETUP request. Responses to RTSP requests are not cacheable, except 2156 for responses to DESCRIBE. 2158 Cache-Control = "Cache-Control" ":" 1#cache-directive 2159 cache-directive = cache-request-directive 2160 | cache-response-directive 2161 cache-request-directive = "no-cache" 2162 | "max-stale" 2163 | "min-fresh" 2164 | "only-if-cached" 2165 | cache-extension 2166 cache-response-directive = "public" 2167 | "private" 2168 | "no-cache" 2169 | "no-transform" 2170 | "must-revalidate" 2171 | "proxy-revalidate" 2172 | "max-age" "=" delta-seconds 2173 | cache-extension 2174 cache-extension = token [ "=" ( token | quoted-string ) ] 2176 no-cache: Indicates that the media stream MUST NOT be cached any- 2177 where. This allows an origin server to prevent caching even by 2178 caches that have been configured to return stale responses to 2179 client requests. 2181 public: Indicates that the media stream is cacheable by any cache. 2183 private: Indicates that the media stream is intended for a single 2184 user and MUST NOT be cached by a shared cache. A private (non- 2185 shared) cache may cache the media stream. 2187 no-transform: An intermediate cache (proxy) may find it useful to 2188 convert the media type of a certain stream. A proxy might, for 2189 example, convert between video formats to save cache space or 2190 to reduce the amount of traffic on a slow link. Serious opera- 2191 tional problems may occur, however, when these transformations 2192 have been applied to streams intended for certain kinds of 2193 applications. For example, applications for medical imaging, 2194 scientific data analysis and those using end-to-end authenti- 2195 cation all depend on receiving a stream that is bit-for-bit 2196 identical to the original entity-body. Therefore, if a 2197 response includes the no-transform directive, an intermediate 2198 cache or proxy MUST NOT change the encoding of the stream. 2199 Unlike HTTP, RTSP does not provide for partial transformation 2200 at this point, e.g., allowing translation into a different 2201 language. 2203 only-if-cached: In some cases, such as times of extremely poor net- 2204 work connectivity, a client may want a cache to return only 2205 those media streams that it currently has stored, and not to 2206 receive these from the origin server. To do this, the client 2207 may include the only-if-cached directive in a request. If it 2208 receives this directive, a cache SHOULD either respond using a 2209 cached media stream that is consistent with the other con- 2210 straints of the request, or respond with a 504 (Gateway Time- 2211 out) status. However, if a group of caches is being operated 2212 as a unified system with good internal connectivity, such a 2213 request MAY be forwarded within that group of caches. 2215 max-stale: Indicates that the client is willing to accept a media 2216 stream that has exceeded its expiration time. If max-stale is 2217 assigned a value, then the client is willing to accept a 2218 response that has exceeded its expiration time by no more than 2219 the specified number of seconds. If no value is assigned to 2220 max-stale, then the client is willing to accept a stale 2221 response of any age. 2223 min-fresh: Indicates that the client is willing to accept a media 2224 stream whose freshness lifetime is no less than its current 2225 age plus the specified time in seconds. That is, the client 2226 wants a response that will still be fresh for at least the 2227 specified number of seconds. 2229 must-revalidate: When the must-revalidate directive is present in a 2230 SETUP response received by a cache, that cache MUST NOT use 2231 the entry after it becomes stale to respond to a subsequent 2232 request without first revalidating it with the origin server. 2233 That is, the cache must do an end-to-end revalidation every 2234 time, if, based solely on the origin server's Expires, the 2235 cached response is stale.) 2237 12.10 Connection 2239 See [H14.10] 2241 12.11 Content-Base 2243 The Content-Base entity-header field may be used to specify the base 2244 URI for resolving relative URLs within the entity. This header field 2245 is described as Base in RFC 1808, which is expected to be revised. 2247 Content-Base = "Content-Base" ":" absoluteURI 2249 If no Content-Base field is present, the base URI of an entity is 2250 defined either by its Content-Location (if that Content-Location URI 2251 is an absolute URI) or the URI used to initiate the request, in that 2252 order of precedence. Note, however, that the base URI of the contents 2253 within the entity-body may be redefined within that entity-body. 2255 12.12 Content-Encoding 2257 See [H14.11] 2259 12.13 Content-Language 2261 See [H14.12] 2263 12.14 Content-Length 2265 The Content-Length general-header field contains the length of the 2266 content of the method (i.e. after the double CRLF following the last 2267 header). Unlike HTTP, it MUST be included in all messages that carry 2268 content beyond the header portion of the message. If it is missing, a 2269 default value of zero is assumed. It is interpreted according to 2270 [H14.13]. 2272 12.15 Content-Location 2274 See [H14.14] 2276 12.16 Content-Type 2278 See [H14.17]. Note that the content types suitable for RTSP are 2279 likely to be restricted in practice to presentation descriptions and 2280 parameter-value types. 2282 12.17 CSeq 2284 The CSeq general-header field specifies the sequence number for an 2285 RTSP request-response pair. This field MUST be present in all 2286 requests and responses. For every RTSP request containing the given 2287 sequence number, the corresponding response will have the same num- 2288 ber. Any retransmitted request must contain the same sequence number 2289 as the original (i.e. the sequence number is not incremented for 2290 retransmissions of the same request). 2292 CSeq = "Cseq" ":" 1*DIGIT 2294 12.18 Date 2296 See [H14.18]. 2298 12.19 Expires 2300 The Expires entity-header field gives a date and time after which the 2301 description or media-stream should be considered stale. The interpre- 2302 tation depends on the method: 2304 DESCRIBE response: The Expires header indicates a date and time 2305 after which the description should be considered stale. 2307 A stale cache entry may not normally be returned by a cache (either a 2308 proxy cache or an user agent cache) unless it is first validated with 2309 the origin server (or with an intermediate cache that has a fresh 2310 copy of the entity). See section 13 for further discussion of the 2311 expiration model. 2313 The presence of an Expires field does not imply that the original 2314 resource will change or cease to exist at, before, or after that 2315 time. 2317 The format is an absolute date and time as defined by HTTP-date in 2318 [H3.3]; it MUST be in RFC1123-date format: 2320 Expires = "Expires" ":" HTTP-date 2322 An example of its use is 2324 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2326 RTSP/1.0 clients and caches MUST treat other invalid date formats, 2327 especially including the value "0", as having occurred in the past 2328 (i.e., already expired). 2330 To mark a response as "already expired," an origin server should use 2331 an Expires date that is equal to the Date header value. To mark a 2332 response as "never expires," an origin server should use an Expires 2333 date approximately one year from the time the response is sent. 2335 RTSP/1.0 servers should not send Expires dates more than one year in 2336 the future. 2338 The presence of an Expires header field with a date value of some 2339 time in the future on a media stream that otherwise would by default 2340 be non-cacheable indicates that the media stream is cacheable, unless 2341 indicated otherwise by a Cache-Control header field (Section 12.9). 2343 12.20 From 2345 See [H14.22]. 2347 12.21 Host 2349 The Host HTTP request header field [H14.23] is not needed for RTSP. 2350 It should be silently ignored if sent. 2352 12.22 If-Match 2354 See [H14.24]. 2356 The If-Match request-header field is especially useful for ensuring 2357 the integrity of the presentation description, in both the case where 2358 it is fetched via means external to RTSP (such as HTTP), or in the 2359 case where the server implementation is guaranteeing the integrity of 2360 the description between the time of the DESCRIBE message and the 2361 SETUP message. 2363 The identifier is an opaque identifier, and thus is not specific to 2364 any particular session description language. 2366 12.23 If-Modified-Since 2368 The If-Modified-Since request-header field is used with the DESCRIBE 2369 and SETUP methods to make them conditional. If the requested variant 2370 has not been modified since the time specified in this field, a 2371 description will not be returned from the server (DESCRIBE) or a 2372 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 2373 response will be returned without any message-body. 2375 If-Modified-Since = "If-Modified-Since" ":" HTTP-date 2377 An example of the field is: 2379 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 2381 12.24 Last-Modified 2383 The Last-Modified entity-header field indicates the date and time at 2384 which the origin server believes the presentation description or 2385 media stream was last modified. See [H14.29]. For the methods 2386 DESCRIBE or ANNOUNCE, the header field indicates the last modifica- 2387 tion date and time of the description, for SETUP that of the media 2388 stream. 2390 12.25 Location 2392 See [H14.30]. 2394 12.26 Proxy-Authenticate 2396 See [H14.33]. 2398 12.27 Proxy-Require 2400 The Proxy-Require request-header field is used to indicate proxy-sen- 2401 sitive features that MUST be supported by the proxy. Any Proxy- 2402 Require header features that are not supported by the proxy MUST be 2403 negatively acknowledged by the proxy to the client if not supported. 2404 Servers should treat this field identically to the Require field. 2406 See Section 12.32 for more details on the mechanics of this message 2407 and a usage example. 2409 12.28 Public 2411 The Public response-header field lists the set of methods supported 2412 by the server. The purpose of this field is strictly to inform the 2413 recipient of the capabilities of the server regarding unusual meth- 2414 ods. The methods listed may or may not be applicable to the Request- 2415 URI; the Allow header field (section 14.7) MAY be used to indicate 2416 methods allowed for a particular URI. 2418 Public = "Public" ":" 1#method 2420 Example of use: 2422 Public: OPTIONS, MGET, MHEAD, GET, HEAD 2424 This header field applies only to the server directly connected to 2425 the client (i.e., the nearest neighbor in a chain of connections). 2427 If the response passes through a proxy, the proxy MUST either remove 2428 the Public header field or replace it with one applicable to its own 2429 capabilities. 2431 12.29 Range 2433 The Range request and response header field specifies a range of 2434 time. The range can be specified in a number of units. This specifi- 2435 cation defines the smpte (Section 3.4), npt (Section 3.5), and clock 2436 (Section 3.6) range units. Within RTSP, byte ranges [H14.35.1] are 2437 not meaningful and MUST NOT be used. The header may also contain a 2438 time parameter in UTC, specifying the time at which the operation is 2439 to be made effective. Servers supporting the Range header MUST under- 2440 stand the NPT range format and SHOULD understand the SMPTE range for- 2441 mat. The Range response header indicates what range of time is actu- 2442 ally being played or recorded. If the Range header is given in a time 2443 format that is not understood, the recipient should return 501 (Not 2444 Implemented). 2446 Ranges are half-open intervals, including the lower point, but 2447 excluding the upper point. In other words, a range of a-b starts 2448 exactly at time a, but stops just before b. Only the start time of a 2449 media unit such as a video or audio frame is relevant. As an example, 2450 assume that video frames are generated every 40 ms. A range of 2451 10.0-10.1 would include a video frame starting at 10.0 or later time 2452 and would include a video frame starting at 10.08, even though it 2453 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 2454 would exclude the frame at 10.08. 2456 Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ] 2457 ranges-specifier = npt-range | utc-range | smpte-range 2459 Example: 2461 Range: clock=19960213T143205Z-;time=19970123T143720Z 2463 The notation is similar to that used for the HTTP/1.1 [26] 2464 byte-range header. It allows clients to select an excerpt from 2465 the media object, and to play from a given point to the end as 2466 well as from the current location to a given point. The start 2467 of playback can be scheduled for any time in the future, 2468 although a server may refuse to keep server resources for 2469 extended idle periods. 2471 12.30 Referer 2473 See [H14.36]. The URL refers to that of the presentation description, 2474 typically retrieved via HTTP. 2476 12.31 Retry-After 2478 See [H14.37]. 2480 12.32 Require 2482 The Require request-header field is used by clients to query the 2483 server about options that it may or may not support. The server MUST 2484 respond to this header by using the Unsupported header to negatively 2485 acknowledge those options which are NOT supported. 2487 This is to make sure that the client-server interaction will 2488 proceed without delay when all options are understood by both 2489 sides, and only slow down if options are not understood (as in 2490 the case above). For a well-matched client-server pair, the 2491 interaction proceeds quickly, saving a round-trip often 2492 required by negotiation mechanisms. In addition, it also 2493 removes state ambiguity when the client requires features that 2494 the server does not understand. 2496 Require = "Require" ":" 1#option-tag 2498 Example: 2500 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 2501 CSeq: 302 2502 Require: funky-feature 2503 Funky-Parameter: funkystuff 2505 S->C: RTSP/1.0 551 Option not supported 2506 CSeq: 302 2507 Unsupported: funky-feature 2509 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 2510 CSeq: 303 2512 S->C: RTSP/1.0 200 OK 2513 CSeq: 303 2515 In this example, "funky-feature" is the feature tag which indicates 2516 to the client that the fictional Funky-Parameter field is required. 2517 The relationship between "funky-feature" and Funky-Parameter is not 2518 communicated via the RTSP exchange, since that relationship is an 2519 immutable property of "funky-feature" and thus should not be trans- 2520 mitted with every exchange. 2522 Proxies and other intermediary devices SHOULD ignore features that 2523 are not understood in this field. If a particular extension requires 2524 that intermediate devices support it, the extension should be tagged 2525 in the Proxy-Require field instead (see Section 12.27). 2527 12.33 RTP-Info 2529 The RTP-Info response-header field is used to set RTP-specific param- 2530 eters in the PLAY response. 2532 url: Indicates the stream URL which for which the following RTP 2533 parameters correspond. 2535 seq: Indicates the sequence number of the first packet of the 2536 stream. This allows clients to gracefully deal with packets 2537 when seeking. The client uses this value to differentiate 2538 packets that originated before the seek from packets that 2539 originated after the seek. 2541 rtptime: Indicates the RTP timestamp corresponding to the time 2542 value in the Range response header. (Note: For aggregate con- 2543 trol, a particular stream may not actually generate a packet 2544 for the Range time value returned or implied. Thus, there is 2545 no guarantee that the packet with the sequence number indi- 2546 cated by seq actually has the timestamp indicated by rtptime.) 2547 The client uses this value to calculate the mapping of RTP 2548 time to NPT. 2550 A mapping from RTP timestamps to NTP timestamps (wall 2551 clock) is available via RTCP. However, this information 2552 is not sufficient to generate a mapping from RTP times- 2553 tamps to NPT. Furthermore, in order to ensure that this 2554 information is available at the necessary time (immedi- 2555 ately at startup or after a seek), and that it is deliv- 2556 ered reliably, this mapping is placed in the RTSP control 2557 channel. 2559 In order to compensate for drift for long, uninterrupted pre- 2560 sentations, RTSP clients should additionally map NPT to NTP, 2561 using initial RTCP sender reports to do the mapping, and later 2562 reports to check drift against the mapping. 2564 Syntax: 2566 RTP-Info = "RTP-Info" ":" 1#rtsp-info-spec 2567 rtsp-info-spec = stream-url 1*parameter 2568 stream-url = quoted-url | unquoted-url 2569 unquoted-url = "url" "=" safe-url 2570 | ";" "mode" = <"> 1#Method <"> 2571 quoted-url = "url" "=" <"> needquote-url <"> 2572 safe-url = url 2573 needquote-url = url 2574 url = ( absoluteURI | relativeURI ) 2575 parameter = ";" "seq" "=" 1*DIGIT 2576 | ";" "rtptime" "=" 1*DIGIT 2578 Additional constraint: safe-url MUST NOT contain the semicolon (";") 2579 or comma (",") characters. The quoted-url form SHOULD only be used 2580 when a URL does not meet the safe-url constraint, in order to ensure 2581 compatibility with implementations conformant to RFC 2326 [21]. 2583 absoluteURI and relativeURI are defined in RFC 2396 [22]. 2585 Example: 2587 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, 2588 url=rtsp://foo.com/bar.avi/streamid=1;seq=30211 2590 12.34 Scale 2592 A scale value of 1 indicates normal play or record at the normal for- 2593 ward viewing rate. If not 1, the value corresponds to the rate with 2594 respect to normal viewing rate. For example, a ratio of 2 indicates 2595 twice the normal viewing rate ("fast forward") and a ratio of 0.5 2596 indicates half the normal viewing rate. In other words, a ratio of 2 2597 has normal play time increase at twice the wallclock rate. For every 2598 second of elapsed (wallclock) time, 2 seconds of content will be 2599 delivered. A negative value indicates reverse direction. 2601 Unless requested otherwise by the Speed parameter, the data rate 2602 SHOULD not be changed. Implementation of scale changes depends on the 2603 server and media type. For video, a server may, for example, deliver 2604 only key frames or selected key frames. For audio, it may time-scale 2605 the audio while preserving pitch or, less desirably, deliver frag- 2606 ments of audio. 2608 The server should try to approximate the viewing rate, but may 2609 restrict the range of scale values that it supports. The response 2610 MUST contain the actual scale value chosen by the server. 2612 If the request contains a Range parameter, the new scale value will 2613 take effect at that time. 2615 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 2617 Example of playing in reverse at 3.5 times normal rate: 2619 Scale: -3.5 2621 12.35 Speed 2623 The Speed request-header field requests the server to deliver data to 2624 the client at a particular speed, contingent on the server's ability 2625 and desire to serve the media stream at the given speed. Implementa- 2626 tion by the server is OPTIONAL. The default is the bit rate of the 2627 stream. 2629 The parameter value is expressed as a decimal ratio, e.g., a value of 2630 2.0 indicates that data is to be delivered twice as fast as normal. A 2631 speed of zero is invalid. If the request contains a Range parameter, 2632 the new speed value will take effect at that time. 2634 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] 2636 Example: 2638 Speed: 2.5 2640 Use of this field changes the bandwidth used for data delivery. It is 2641 meant for use in specific circumstances where preview of the presen- 2642 tation at a higher or lower rate is necessary. Implementors should 2643 keep in mind that bandwidth for the session may be negotiated before- 2644 hand (by means other than RTSP), and therefore re-negotiation may be 2645 necessary. When data is delivered over UDP, it is highly recommended 2646 that means such as RTCP be used to track packet loss rates. 2648 12.36 Server 2650 See [H14.38] 2652 12.37 Session 2654 The Session request-header and response-header field identifies an 2655 RTSP session started by the media server in a SETUP response and con- 2656 cluded by TEARDOWN on the presentation URL. The session identifier is 2657 chosen by the media server (see Section 3.3) and MUST be returned in 2658 the SETUP response. Once a client receives a Session identifier, it 2659 MUST return it for any request related to that session. 2661 Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ] 2663 The timeout parameter is only allowed in a response header. The 2664 server uses it to indicate to the client how long the server is pre- 2665 pared to wait between RTSP commands before closing the session due to 2666 lack of activity (see Section A). The timeout is measured in seconds, 2667 with a default of 60 seconds (1 minute). 2669 Note that a session identifier identifies an RTSP session across 2670 transport sessions or connections. Control messages for more than one 2671 RTSP URL may be sent within a single RTSP session. Hence, it is pos- 2672 sible that clients use the same session for controlling many streams 2673 constituting a presentation, as long as all the streams come from the 2674 same server. (See example in Section 14). However, multiple "user" 2675 sessions for the same URL from the same client MUST use different 2676 session identifiers. 2678 The session identifier is needed to distinguish several deliv- 2679 ery requests for the same URL coming from the same client. 2681 The response 454 (Session Not Found) is returned if the session iden- 2682 tifier is invalid. 2684 12.38 Supported | 2686 The Supported header field enumerates all the extensions supported by | 2687 the client or server. When offered in a request, the receiver MUST | 2688 respond with its cooresponding Supported header. | 2690 The Supported header field contains a list of option tags, described | 2691 in Section 3.7, that are understood by the client or server. | 2692 Example: | 2694 C->S OPTIONS rtsp://example.com/ RTSP/1.0 || 2695 Supported: foo, bar, blech || 2697 SuppoS->C:RTSP/1.0e200 OKz || 2699 12.39 Timestamp 2701 The Timestamp general-header field describes when the client sent the 2702 request to the server. The value of the timestamp is of significance 2703 only to the client and may use any timescale. The server MUST echo 2704 the exact same value and MAY, if it has accurate information about 2705 this, add a floating point number indicating the number of seconds 2706 that has elapsed since it has received the request. The timestamp is 2707 used by the client to compute the round-trip time to the server so 2708 that it can adjust the timeout value for retransmissions. 2710 Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] 2711 delay = *(DIGIT) [ "." *(DIGIT) ] 2713 12.40 Transport 2715 The Transport request-header field indicates which transport protocol 2716 is to be used and configures its parameters such as destination 2717 address, compression, multicast time-to-live and destination port for 2718 a single stream. It sets those values not already determined by a 2719 presentation description. 2721 Transports are comma separated, listed in order of preference. 2722 Parameters may be added to each transport, separated by a semicolon. 2724 The Transport header field MAY also be used to change certain trans- 2725 port parameters. A server MAY refuse to change parameters of an 2726 existing stream. 2728 The server MAY return a Transport response-header field in the 2729 response to indicate the values actually chosen. 2731 A Transport request header field may contain a list of transport 2732 options acceptable to the client, in the form of multiple transport- 2733 spec entries. In that case, the server MUST return a single option 2734 (transport-spec) which was actually chosen. 2736 A transport-spec transport option may only contain one of any given | 2737 parameter within it. Parameters may be given in any order. Addition- | 2738 ally, it may only contain the unicast or multicast transport parame- | 2739 ter. 2741 The Transport header field is restricted to describing a sin- 2742 gle RTP stream. (RTSP can also control multiple streams as a 2743 single entity.) Making it part of RTSP rather than relying on 2744 a multitude of session description formats greatly simplifies 2745 designs of firewalls. 2747 The syntax for the transport specifier is 2749 transport/profile/lower-transport. 2751 The default value for the "lower-transport" parameters is specific to 2752 the profile. For RTP/AVP, the default is UDP. 2754 Below are the configuration parameters associated with transport: 2756 General parameters: 2758 unicast | multicast: This parameter is a mutually exclusive indica- 2759 tion of whether unicast or multicast delivery will be 2760 attempted. One of the two values MUST be specified. Clients 2761 that are capable of handling both unicast and multicast trans- 2762 mission MUST indicate such capability by including two full 2763 transport-specs with separate parameters for each. 2765 destination: The address to which a stream will be sent. The | 2766 client may specify the destination address with the destina- | 2767 tion parameter. To avoid becoming the unwitting perpetrator of | 2768 a remote-controlled denial-of-service attack, a server SHOULD | 2769 authenticate the client and SHOULD log such attempts before | 2770 allowing the client to direct a media stream to an address not | 2771 chosen by the server. This is particularly important if RTSP | 2772 commands are issued via UDP, but implementations cannot rely | 2773 on TCP as reliable means of client identification by itself. 2775 source: If the source address for the stream is different than can 2776 be derived from the RTSP endpoint address (the server in play- 2777 back or the client in recording), the source address MAY be 2778 specified. 2780 This information may also be available through SDP. How- 2781 ever, since this is more a feature of transport than 2782 media initialization, the authoritative source for this 2783 information should be in the SETUP response. 2785 layers: The number of multicast layers to be used for this media 2786 stream. The layers are sent to consecutive addresses starting 2787 at the destination address. 2789 mode: The mode parameter indicates the methods to be supported for 2790 this session. Valid values are PLAY and RECORD. If not pro- 2791 vided, the default is PLAY. 2793 append: If the mode parameter includes RECORD, the append parameter 2794 indicates that the media data should append to the existing 2795 resource rather than overwrite it. If appending is requested 2796 and the server does not support this, it MUST refuse the 2797 request rather than overwrite the resource identified by the 2798 URI. The append parameter is ignored if the mode parameter 2799 does not contain RECORD. 2801 interleaved: The interleaved parameter implies mixing the media 2802 stream with the control stream in whatever protocol is being 2803 used by the control stream, using the mechanism defined in 2804 Section 10.13. The argument provides the channel number to be 2805 used in the $ statement. This parameter may be specified as a 2806 range, e.g., interleaved=4-5 in cases where the transport 2807 choice for the media stream requires it. 2809 This allows RTP/RTCP to be handled similarly to the way 2810 that it is done with UDP, i.e., one channel for RTP and 2811 the other for RTCP. 2813 Multicast-specific: 2815 ttl: multicast time-to-live. 2817 RTP-specific: 2819 port: This parameter provides the RTP/RTCP port pair for a multi- 2820 cast session. It is specified as a range, e.g., port=3456-3457 2822 client_port: This parameter provides the unicast RTP/RTCP port pair 2823 on the client where media data and control information is to 2824 be sent. It is specified as a range, e.g., port=3456-3457 2826 server_port: This parameter provides the unicast RTP/RTCP port pair 2827 on the server where media data and control information is to 2828 be sent. It is specified as a range, e.g., port=3456-3457 2830 ssrc: The ssrc parameter indicates the RTP SSRC [23] value that 2831 should be (request) or will be (response) used by the media 2832 server. This parameter is only valid for unicast transmission. 2833 It identifies the synchronization source to be associated with 2834 the media stream, and is expressed as an eight digit hexideci- 2835 mal value. 2837 Transport = "Transport" ":" 1#transport-spec 2838 transport-spec = transport-id *parameter 2839 transport-id = transport-protocol "/" profile ["/" lower-transport] 2840 ; no LWS is allowed inside transport-id 2841 transport-protocol = "RTP" | token 2842 profile = "AVP" | token 2843 lower-transport = "TCP" | "UDP" | token 2844 parameter = ";" ( "unicast" | "multicast" ) 2845 | ";" "source" [ "=" address ] 2846 | ";" "destination" [ "=" address ] 2847 | ";" "interleaved" "=" channel [ "-" channel ] 2848 | ";" "append" 2849 | ";" "ttl" "=" ttl 2850 | ";" "layers" "=" 1*DIGIT 2851 | ";" "port" "=" port [ "-" port ] 2852 | ";" "client_port" "=" port [ "-" port ] 2853 | ";" "server_port" "=" port [ "-" port ] 2854 | ";" "source" "=" address 2855 | ";" "ssrc" "=" ssrc 2856 | ";" "mode" "=" mode-spec 2857 ttl = 1*3(DIGIT) 2858 port = 1*5(DIGIT) 2859 ssrc = 8*8(HEX) 2860 channel = 1*3(DIGIT) 2861 address = host 2862 mode-spec = <"> 1#mode <"> | mode 2863 mode = "PLAY" | "RECORD" | token 2865 Below is a usage example, showing a client advertising the capability 2866 to handle multicast or unicast, preferring multicast. Since this is a 2867 unicast-only stream, the server responds with the proper transport 2868 parameters for unicast. 2870 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 2871 CSeq: 302 2872 Transport: RTP/AVP;multicast;mode="PLAY", 2873 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" 2875 S->C: RTSP/1.0 200 OK 2876 CSeq: 302 2877 Date: 23 Jan 1997 15:35:06 GMT 2878 Session: 47112344 2879 Transport: RTP/AVP;unicast;client_port=3456-3457; 2880 server_port=6256-6257;mode="PLAY" 2882 12.41 Unsupported 2884 The Unsupported response-header field lists the features not sup- 2885 ported by the server. In the case where the feature was specified via 2886 the Proxy-Require field (Section 12.32), if there is a proxy on the 2887 path between the client and the server, the proxy MUST insert a 2888 response message with a status code of 551 (Option Not Supported). 2890 See Section 12.32 for a usage example. 2892 Unsupported = "Unsupported" ":" 1#option-tag 2894 12.42 User-Agent 2896 See [H14.43] 2898 12.43 Vary 2900 See [H14.44] 2902 12.44 Via 2904 See [H14.45]. 2906 12.45 WWW-Authenticate 2908 See [H14.47]. 2910 13 Caching 2912 In HTTP, response-request pairs are cached. RTSP differs signifi- 2913 cantly in that respect. Responses are not cacheable, with the excep- 2914 tion of the presentation description returned by DESCRIBE or included 2915 with ANNOUNCE. (Since the responses for anything but DESCRIBE and 2916 GET_PARAMETER do not return any data, caching is not really an issue 2917 for these requests.) However, it is desirable for the continuous 2918 media data, typically delivered out-of-band with respect to RTSP, to 2919 be cached, as well as the session description. 2921 On receiving a SETUP or PLAY request, a proxy ascertains whether it 2922 has an up-to-date copy of the continuous media content and its 2923 description. It can determine whether the copy is up-to-date by issu- 2924 ing a SETUP or DESCRIBE request, respectively, and comparing the 2925 Last-Modified header with that of the cached copy. If the copy is not 2926 up-to-date, it modifies the SETUP transport parameters as appropriate 2927 and forwards the request to the origin server. Subsequent control 2928 commands such as PLAY or PAUSE then pass the proxy unmodified. The 2929 proxy delivers the continuous media data to the client, while possi- 2930 bly making a local copy for later reuse. The exact behavior allowed 2931 to the cache is given by the cache-response directives described in 2932 Section 12.9. A cache MUST answer any DESCRIBE requests if it is cur- 2933 rently serving the stream to the requestor, as it is possible that 2934 low-level details of the stream description may have changed on the 2935 origin-server. 2937 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 2938 through" variety. Rather than retrieving the whole resource from the 2939 origin server, the cache simply copies the streaming data as it 2940 passes by on its way to the client. Thus, it does not introduce addi- 2941 tional latency. 2943 To the client, an RTSP proxy cache appears like a regular media 2944 server, to the media origin server like a client. Just as an HTTP 2945 cache has to store the content type, content language, and so on for 2946 the objects it caches, a media cache has to store the presentation 2947 description. Typically, a cache eliminates all transport-references 2948 (that is, multicast information) from the presentation description, 2949 since these are independent of the data delivery from the cache to 2950 the client. Information on the encodings remains the same. If the 2951 cache is able to translate the cached media data, it would create a 2952 new presentation description with all the encoding possibilities it 2953 can offer. 2955 14 Examples 2957 The following examples refer to stream description formats that are 2958 not standards, such as RTSL. The following examples are not to be 2959 used as a reference for those formats. 2961 14.1 Media on Demand (Unicast) 2962 Client C requests a movie from media servers A (audio.example.com ) 2963 and V (video.example.com ). The media description is stored on a web 2964 server W. The media description contains descriptions of the presen- 2965 tation and all its streams, including the codecs that are available, 2966 dynamic RTP payload types, the protocol stack, and content informa- 2967 tion such as language or copyright restrictions. It may also give an 2968 indication about the timeline of the movie. 2970 In this example, the client is only interested in the last part of 2971 the movie. 2973 C->W: GET /twister.sdp HTTP/1.1 2974 Host: www.example.com 2975 Accept: application/sdp 2977 W->C: HTTP/1.0 200 OK 2978 Content-Type: application/sdp 2980 v=0 2981 o=- 2890844526 2890842807 IN IP4 192.16.24.202 2982 s=RTSP Session 2983 m=audio 0 RTP/AVP 0 2984 a=control:rtsp://audio.example.com/twister/audio.en 2985 m=video 0 RTP/AVP 31 2986 a=control:rtsp://video.example.com/twister/video 2988 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 2989 CSeq: 1 2990 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 2992 A->C: RTSP/1.0 200 OK 2993 CSeq: 1 2994 Session: 12345678 2995 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; 2996 server_port=5000-5001 2998 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 2999 CSeq: 1 3000 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 3002 V->C: RTSP/1.0 200 OK 3003 CSeq: 1 3004 Session: 23456789 3005 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; 3006 server_port=5002-5003 3008 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 3009 CSeq: 2 3010 Session: 23456789 3011 Range: smpte=0:10:00- 3013 V->C: RTSP/1.0 200 OK 3014 CSeq: 2 3015 Session: 23456789 3016 Range: smpte=0:10:00-0:20:00 3017 RTP-Info: url=rtsp://video.example.com/twister/video; 3018 seq=12312232;rtptime=78712811 3020 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 3021 CSeq: 2 3022 Session: 12345678 3023 Range: smpte=0:10:00- 3025 A->C: RTSP/1.0 200 OK 3026 CSeq: 2 3027 Session: 12345678 3028 Range: smpte=0:10:00-0:20:00 3029 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; 3030 seq=876655;rtptime=1032181 3032 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 3033 CSeq: 3 3034 Session: 12345678 3036 A->C: RTSP/1.0 200 OK 3037 CSeq: 3 3039 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 3040 CSeq: 3 3041 Session: 23456789 3043 V->C: RTSP/1.0 200 OK 3044 CSeq: 3 3046 Even though the audio and video track are on two different servers, 3047 and may start at slightly different times and may drift with respect 3048 to each other, the client can synchronize the two using standard RTP 3049 methods, in particular the time scale contained in the RTCP sender 3050 reports. 3052 14.2 Streaming of a Container file 3053 For purposes of this example, a container file is a storage entity in 3054 which multiple continuous media types pertaining to the same end-user 3055 presentation are present. In effect, the container file represents an 3056 RTSP presentation, with each of its components being RTSP streams. 3057 Container files are a widely used means to store such presentations. 3058 While the components are transported as independent streams, it is 3059 desirable to maintain a common context for those streams at the 3060 server end. 3062 This enables the server to keep a single storage handle open 3063 easily. It also allows treating all the streams equally in 3064 case of any prioritization of streams by the server. 3066 It is also possible that the presentation author may wish to prevent 3067 selective retrieval of the streams by the client in order to preserve 3068 the artistic effect of the combined media presentation. Similarly, in 3069 such a tightly bound presentation, it is desirable to be able to con- 3070 trol all the streams via a single control message using an aggregate 3071 URL. 3073 The following is an example of using a single RTSP session to control 3074 multiple streams. It also illustrates the use of aggregate URLs. 3076 Client C requests a presentation from media server M. The movie is 3077 stored in a container file. The client has obtained an RTSP URL to 3078 the container file. 3080 C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 3081 CSeq: 1 3083 M->C: RTSP/1.0 200 OK 3084 CSeq: 1 3085 Content-Type: application/sdp 3086 Content-Length: 164 3088 v=0 3089 o=- 2890844256 2890842807 IN IP4 172.16.2.93 3090 s=RTSP Session 3091 i=An Example of RTSP Session Usage 3092 a=control:rtsp://foo/twister 3093 t=0 0 3094 m=audio 0 RTP/AVP 0 3095 a=control:rtsp://foo/twister/audio 3096 m=video 0 RTP/AVP 26 3097 a=control:rtsp://foo/twister/video 3099 C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 3100 CSeq: 2 3101 Transport: RTP/AVP;unicast;client_port=8000-8001 3103 M->C: RTSP/1.0 200 OK 3104 CSeq: 2 3105 Transport: RTP/AVP;unicast;client_port=8000-8001; 3106 server_port=9000-9001 3107 Session: 12345678 3109 C->M: SETUP rtsp://foo/twister/video RTSP/1.0 3110 CSeq: 3 3111 Transport: RTP/AVP;unicast;client_port=8002-8003 3112 Session: 12345678 3114 M->C: RTSP/1.0 200 OK 3115 CSeq: 3 3116 Transport: RTP/AVP;unicast;client_port=8002-8003; 3117 server_port=9004-9005 3118 Session: 12345678 3120 C->M: PLAY rtsp://foo/twister RTSP/1.0 3121 CSeq: 4 3122 Range: npt=0- 3123 Session: 12345678 3125 M->C: RTSP/1.0 200 OK 3126 CSeq: 4 3127 Session: 12345678 3128 RTP-Info: url=rtsp://foo/twister/video; 3129 seq=9810092;rtptime=3450012 3131 C->M: PAUSE rtsp://foo/twister/video RTSP/1.0 3132 CSeq: 5 3133 Session: 12345678 3135 M->C: RTSP/1.0 460 Only aggregate operation allowed 3136 CSeq: 5 3138 C->M: PAUSE rtsp://foo/twister RTSP/1.0 3139 CSeq: 6 3140 Session: 12345678 3142 M->C: RTSP/1.0 200 OK 3143 CSeq: 6 3144 Session: 12345678 3146 C->M: SETUP rtsp://foo/twister RTSP/1.0 3147 CSeq: 7 3148 Transport: RTP/AVP;unicast;client_port=10000 3150 M->C: RTSP/1.0 459 Aggregate operation not allowed 3151 CSeq: 7 3153 In the first instance of failure, the client tries to pause one 3154 stream (in this case video) of the presentation. This is disallowed 3155 for that presentation by the server. In the second instance, the 3156 aggregate URL may not be used for SETUP and one control message is 3157 required per stream to set up transport parameters. 3159 This keeps the syntax of the Transport header simple and 3160 allows easy parsing of transport information by firewalls. 3162 14.3 Single Stream Container Files 3164 Some RTSP servers may treat all files as though they are "container 3165 files", yet other servers may not support such a concept. Because of 3166 this, clients SHOULD use the rules set forth in the session descrip- 3167 tion for request URLs, rather than assuming that a consistent URL may 3168 always be used throughout. Here's an example of how a multi-stream 3169 server might expect a single-stream file to be served: 3171 C->S DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 3172 Accept: application/x-rtsp-mh, application/sdp 3173 CSeq: 1 3175 S->C RTSP/1.0 200 OK 3176 CSeq: 1 3177 Content-base: rtsp://foo.com/test.wav/ 3178 Content-type: application/sdp 3179 Content-length: 48 3181 v=0 3182 o=- 872653257 872653257 IN IP4 172.16.2.187 3183 s=mu-law wave file 3184 i=audio test 3185 t=0 0 3186 m=audio 0 RTP/AVP 0 3187 a=control:streamid=0 3189 C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 3190 Transport: RTP/AVP/UDP;unicast; 3191 client_port=6970-6971;mode="PLAY" 3192 CSeq: 2 3194 S->C RTSP/1.0 200 OK 3195 Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; 3196 server_port=6970-6971;mode="PLAY" 3197 CSeq: 2 3198 Session: 2034820394 3200 C->S PLAY rtsp://foo.com/test.wav RTSP/1.0 3201 CSeq: 3 3202 Session: 2034820394 3204 S->C RTSP/1.0 200 OK 3205 CSeq: 3 3206 Session: 2034820394 3207 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; 3208 seq=981888;rtptime=3781123 3210 Note the different URL in the SETUP command, and then the switch back 3211 to the aggregate URL in the PLAY command. This makes complete sense 3212 when there are multiple streams with aggregate control, but is less 3213 than intuitive in the special case where the number of streams is 3214 one. 3216 In this special case, it is recommended that servers be forgiving of 3217 implementations that send: 3219 C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 3220 CSeq: 3 3222 In the worst case, servers should send back: 3224 S->C RTSP/1.0 460 Only aggregate operation allowed 3225 CSeq: 3 3227 One would also hope that server implementations are also forgiving of 3228 the following: 3230 C->S SETUP rtsp://foo.com/test.wav RTSP/1.0 3231 Transport: rtp/avp/udp;client_port=6970-6971;mode="PLAY" 3232 CSeq: 2 3234 Since there is only a single stream in this file, it's not ambiguous 3235 what this means. 3237 14.4 Live Media Presentation Using Multicast 3239 The media server M chooses the multicast address and port. Here, we 3240 assume that the web server only contains a pointer to the full 3241 description, while the media server M maintains the full description. 3243 C->W: GET /concert.sdp HTTP/1.1 3244 Host: www.example.com 3246 W->C: HTTP/1.1 200 OK 3247 Content-Type: application/x-rtsl 3249 3250 3251 3253 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 3254 CSeq: 1 3256 M->C: RTSP/1.0 200 OK 3257 CSeq: 1 3258 Content-Type: application/sdp 3259 Content-Length: 44 3261 v=0 3262 o=- 2890844526 2890842807 IN IP4 192.16.24.202 3263 s=RTSP Session 3264 m=audio 3456 RTP/AVP 0 3265 c=IN IP4 224.2.0.1/16 3266 a=control:rtsp://live.example.com/concert/audio 3268 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 3269 CSeq: 2 3270 Transport: RTP/AVP;multicast 3272 M->C: RTSP/1.0 200 OK 3273 CSeq: 2 3274 Transport: RTP/AVP;multicast;destination=224.2.0.1; 3275 port=3456-3457;ttl=16 3276 Session: 0456804596 3278 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3279 CSeq: 3 3280 Session: 0456804596 3282 M->C: RTSP/1.0 200 OK 3283 CSeq: 3 3284 Session: 0456804596 3286 14.5 Recording 3288 The conference participant client C asks the media server M to record 3289 the audio and video portions of a meeting. The client uses the 3290 ANNOUNCE method to provide meta-information about the recorded ses- 3291 sion to the server. 3293 C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 3294 CSeq: 90 3295 Content-Type: application/sdp 3296 Content-Length: 121 3298 v=0 3299 o=camera1 3080117314 3080118787 IN IP4 195.27.192.36 3300 s=IETF Meeting, Munich - 1 3301 i=The thirty-ninth IETF meeting will be held in Munich, Germany 3302 u=http://www.ietf.org/meetings/Munich.html 3303 e=IETF Channel 1 3304 p=IETF Channel 1 +49-172-2312 451 3305 c=IN IP4 224.0.1.11/127 3306 t=3080271600 3080703600 3307 a=tool:sdr v2.4a6 3308 a=type:test 3309 m=audio 21010 RTP/AVP 5 3310 c=IN IP4 224.0.1.11/127 3311 a=ptime:40 3312 m=video 61010 RTP/AVP 31 3313 c=IN IP4 224.0.1.12/127 3315 M->C: RTSP/1.0 200 OK 3316 CSeq: 90 3318 C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0 3319 CSeq: 91 3320 Transport: RTP/AVP;multicast;destination=224.0.1.11; 3321 port=21010-21011;mode=record;ttl=127 3323 M->C: RTSP/1.0 200 OK 3324 CSeq: 91 3325 Session: 50887676 3326 Transport: RTP/AVP;multicast;destination=224.0.1.11; 3327 port=21010-21011;mode=record;ttl=127 3329 C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0 3330 CSeq: 92 3331 Session: 50887676 3332 Transport: RTP/AVP;multicast;destination=224.0.1.12; 3333 port=61010-61011;mode=record;ttl=127 3335 M->C: RTSP/1.0 200 OK 3336 CSeq: 92 3337 Transport: RTP/AVP;multicast;destination=224.0.1.12; 3338 port=61010-61011;mode=record;ttl=127 3340 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 3341 CSeq: 93 3342 Session: 50887676 3343 Range: clock=19961110T1925-19961110T2015 3345 M->C: RTSP/1.0 200 OK 3346 CSeq: 93 3348 15 Syntax 3350 The RTSP syntax is described in an augmented Backus-Naur form (BNF) 3351 as used in RFC 2068 [2]. 3353 15.1 Base Syntax 3355 OCTET = 3356 CHAR = 3357 UPALPHA = 3358 LOALPHA = 3359 ALPHA = UPALPHA | LOALPHA 3360 DIGIT = 3361 CTL = 3364 CR = 3365 LF = 3366 SP = 3367 HT = 3368 <"> = 3369 BACKSLASH = 3370 CRLF = CR LF 3371 LWS = [CRLF] 1*( SP | HT ) 3372 TEXT = 3373 tspecials = "(" | ")" | "<" | ">" | "@" 3374 | "," | ";" | ":" | BACKSLASH | <"> 3375 | "/" | "[" | "]" | "?" | "=" 3376 | "{" | "}" | SP | HT 3377 token = 1* 3378 quoted-string = ( <"> *(qdtext) <"> ) 3379 qdtext = > 3380 quoted-pair = BACKSLASH CHAR 3381 message-header = field-name ":" [ field-value ] CRLF 3382 field-name = token 3383 field-value = *( field-content | LWS ) 3384 field-content = 3388 safe = "$" | "-" | "_" | "." | "+" 3389 extra = "!" | "*" | "'" | "(" | ")" | "," 3390 hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" | 3391 "a" | "b" | "c" | "d" | "e" | "f" 3392 escape = "%" hex hex 3393 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" 3394 unreserved = alpha | digit | safe | extra 3395 xchar = unreserved | reserved | escape 3397 16 Security Considerations 3399 Because of the similarity in syntax and usage between RTSP servers 3400 and HTTP servers, the security considerations outlined in [H15] 3401 apply. Specifically, please note the following: 3403 Authentication Mechanisms: RTSP and HTTP share common authentica- 3404 tion schemes, and thus should follow the same prescriptions 3405 with regards to authentication. See chapter 15.1 of [2] for 3406 client authentication issues, and chapter 15.2 of [2] for 3407 issues regarding support for multiple authentication mecha- 3408 nisms. 3410 Abuse of Server Log Information: RTSP and HTTP servers will presum- 3411 ably have similar logging mechanisms, and thus should be 3412 equally guarded in protecting the contents of those logs, thus 3413 protecting the privacy of the users of the servers. See 3414 [H15.1.1] for HTTP server recommendations regarding server 3415 logs. 3417 Transfer of Sensitive Information: There is no reason to believe 3418 that information transferred via RTSP may be any less sensi- 3419 tive than that normally transmitted via HTTP. Therefore, all 3420 of the precautions regarding the protection of data privacy 3421 and user privacy apply to implementors of RTSP clients, 3422 servers, and proxies. See [H15.1.2] for further details. 3424 Attacks Based On File and Path Names: Though RTSP URLs are opaque 3425 handles that do not necessarily have file system semantics, it 3426 is anticipated that many implementations will translate por- 3427 tions of the request URLs directly to file system calls. In 3428 such cases, file systems SHOULD follow the precautions out- 3429 lined in [H15.5], such as checking for ".." in path compo- 3430 nents. 3432 Personal Information: RTSP clients are often privy to the same 3433 information that HTTP clients are (user name, location, etc.) 3434 and thus should be equally. See [H15.1] for further recommen- 3435 dations. 3437 Privacy Issues Connected to Accept Headers: Since may of the same 3438 "Accept" headers exist in RTSP as in HTTP, the same caveats 3439 outlined in [H15.1.4] with regards to their use should be fol- 3440 lowed. 3442 DNS Spoofing: Presumably, given the longer connection times typi- 3443 cally associated to RTSP sessions relative to HTTP sessions, 3444 RTSP client DNS optimizations should be less prevalent. 3445 Nonetheless, the recommendations provided in [H15.3] are still 3446 relevant to any implementation which attempts to rely on a 3447 DNS-to-IP mapping to hold beyond a single use of the mapping. 3449 Location Headers and Spoofing: If a single server supports multiple 3450 organizations that do not trust one another, then it must 3451 check the values of Location and Content-Location header 3452 fields in responses that are generated under control of said 3453 organizations to make sure that they do not attempt to invali- 3454 date resources over which they have no authority. ([H15.4]) 3456 In addition to the recommendations in the current HTTP specification 3457 (RFC 2616 [26], as of this writing) and also of the previous RFC2068 3459 [2], future HTTP specifications may provide additional guidance on 3460 security issues. 3462 The following are added considerations for RTSP implementations. 3464 Concentrated denial-of-service attack: The protocol offers the 3465 opportunity for a remote-controlled denial-of-service attack. 3467 The attacker may initiate traffic flows to one or more IP 3468 addresses by specifying them as the destination in SETUP 3469 requests. While the attacker's IP address may be known in this 3470 case, this is not always useful in prevention of more attacks 3471 or ascertaining the attackers identity. Thus, an RTSP server 3472 SHOULD only allow client-specified destinations for RTSP-ini- 3473 tiated traffic flows if the server has verified the client's 3474 identity, either against a database of known users using RTSP 3475 authentication mechanisms (preferably digest authentication or 3476 stronger), or other secure means. 3478 Session hijacking: Since there is no relation between a transport 3479 layer connection and an RTSP session, it is possible for a 3480 malicious client to issue requests with random session identi- 3481 fiers which would affect unsuspecting clients. The server 3482 SHOULD use a large, random and non-sequential session identi- 3483 fier to minimize the possibility of this kind of attack. 3485 Authentication: Servers SHOULD implement both basic and digest [6] 3486 authentication. In environments requiring tighter security for 3487 the control messages, transport layer mechanisms such as TLS 3488 (RFC 2246 [27]) SHOULD be used. 3490 Stream issues: RTSP only provides for stream control. Stream deliv- 3491 ery issues are not covered in this section, nor in the rest of 3492 this draft. RTSP implementations will most likely rely on 3493 other protocols such as RTP, IP multicast, RSVP and IGMP, and 3494 should address security considerations brought up in those and 3495 other applicable specifications. 3497 Persistently suspicious behavior: RTSP servers SHOULD return error 3498 code 403 (Forbidden) upon receiving a single instance of 3499 behavior which is deemed a security risk. RTSP servers SHOULD 3500 also be aware of attempts to probe the server for weaknesses 3501 and entry points and MAY arbitrarily disconnect and ignore 3502 further requests clients which are deemed to be in violation 3503 of local security policy. 3505 17 IANA Considerations 3506 This section set up a number of registers for RTSP that should be 3507 maintained by IANA. For each registry there is a description on what 3508 it shall contain, what specification is needed when adding a entry 3509 with IANA, and finally the entries that this document needs to regis- 3510 ter. See also the section 1.5 "Extending RTSP". 3512 The sections describing how to register an item uses some of the 3513 requirements level described in RFC 2434 [29], namely " First Come, 3514 First Served", "Specification Required", and "Standards Action". 3516 A registration request to IANA MUST contain the following informa- 3517 tion: 3519 + A name of the item to register according to the rules specified 3520 by the intended registry. 3522 + Indication of who has change control over the option (for exam- 3523 ple, IETF, ISO, ITU-T, other international standardization bod- 3524 ies, a consortium or a particular company or group of companies); 3526 + A reference to a further description, if available, for example 3527 (in order of preference) an RFC, a published paper, a patent fil- 3528 ing, a technical report, documented source code or a computer 3529 manual; 3531 + For proprietary options, contact information (postal and email 3532 address); 3534 17.1 Option-tags 3536 17.1.1 Description 3538 When a client and server try to determine what part and functionality 3539 of the RTSP specification and any future extensions that its counter 3540 part implements there is need for a namespace. This registry con- 3541 tains named entries representing certain functionality. 3543 The usage of option-tags is explained in section 3.7 and 10.1. 3545 17.1.2 Registering New Option Tags with IANA 3547 The registering of option tags is done on a first come, first served 3548 basis. 3550 The name of the option MUST follow these rules: The name may be of 3551 any length, but SHOULD be no more than twenty characters long. The 3552 name MUST not contain any spaces, control characters or periods. Any 3553 proprietary option SHOULD have as the first part of the name a vendor 3554 tag, which identifies the company/person. 3556 17.1.3 Registered entries 3558 The following options tags are in this specification defined and 3559 hereby registered. The change control belongs to the Authors and the 3560 IETF MMUSIC WG. 3562 play-basic: The minimal implementation for playback operations 3563 according to section D. 3565 record-basic: The minimal implementation for record operations 3566 according to section D. 3568 play-setup: The use of teardown and setup in play state. 3570 record-setup: The use of setup and teardown in record state. 3572 17.2 RTSP Methods 3574 17.2.1 Description 3576 What a method is, is described in section 10. Extending the protocol 3577 with new methods allow for totally new functionality. 3579 17.2.2 Registering New Methods with IANA 3581 A new method can only be registered through an IETF standards action. 3582 The reason is that new methods may radically change the protocols 3583 behavior and purpose. 3585 A specification for a new RTSP method MUST consist of the following 3586 items: 3588 + A method name which follows the BNF rules for methods. 3590 + A clear specification on what action and response a request with 3591 the method will result in. Which directions the method is used, 3592 C->S or S->C or both. How the use of headers, if any, modifies 3593 the behavior and effect of the method. 3595 + A list or table specifying which of the registered headers that 3596 are allowed to use with the method in request or/and response. 3598 + Describe how the method relates to network proxies. 3600 17.2.3 Registered entries 3601 This specification, RFCXXXX, registers 12 methods: DESCRIBE, 3602 ANNOUNCE, GET_PARAMETER, OPTIONS, PAUSE, PING, PLAY, RECORD, REDI- 3603 RECT, SETUP, SET_PARAMETER, and TEARDOWN. 3605 17.3 RTSP Headers 3607 17.3.1 Description 3609 By specifying new headers a method(s) can be enhanced in many differ- 3610 ent ways. An unknown header will be ignored by the receiving entity. 3611 If the new header is vital for a certain functionality, a option tag 3612 for the functionality can be created and demanded to be used by the 3613 counter-part with the inclusion of a Require header carrying the 3614 option tag. 3616 Unregistered headers SHALL have a name starting with "X-" to signal 3617 that it is a experimental header. 3619 17.3.2 Registering New Headers with IANA 3621 A specification is required to register a header. 3623 The specification MUST contain the following information: 3625 + The header name following the BNF definition. 3627 + A BNF specification of how information (if any) is carried in the 3628 header. 3630 + A list or table specifying when the header may be used, encom- 3631 passing all methods, their request or response, the direction 3632 (C->S or S->C). 3634 + How the header shall be handled by proxies. 3636 + A description of the purpose of the header. 3638 17.3.3 Registered entries 3640 All headers specified in section 12 in RFC XXXX are to be registered. 3642 17.4 Parameters 3644 17.4.1 Description 3646 A Parameter allow the counterpart to set something with the owner of 3647 the parameter. Both the client and the server can have parameters. 3649 17.4.2 Registering New Parameters with IANA 3651 Any Parameter is registered on a first come, first served basis. The 3652 following rules apply for parameters: 3654 + The parameter name is a BNF token. The name SHOULD not be more 3655 than 20 characters long. Any proprietary parameter should start 3656 the name with a vendor tag, as clearly as possible identify the 3657 company or person. 3659 + Any non proprietary parameter MUST in the form of BNF specify 3660 what value types that are associated with the parameter. 3662 17.4.3 Registered entries 3664 For the moment no known parameters are defined in RFC XXXX. 3666 A RTSP Protocol State Machine 3668 The RTSP session state machine describe the behavior of the protocol 3669 from RTSP session initialization through RTSP session termination. 3671 State machine is defined on a per session basis which is uniquely 3672 identified by the RTSP session identifier. The session may contain 3673 zero or more media streams depending on state. If a single media 3674 stream is part of the session it is in non-aggregated control. If two 3675 or more is part of the session it is in aggregated control. 3677 This state machine is one possible representation that helps explain 3678 how the protocol works and when different requests are allowed. We 3679 find it a reasonable representation but does not mandate it, and 3680 other representations can be created. 3682 A.1 States 3684 The state machine contains five states, described below. For each 3685 state there exist a table which shows which requests and events that 3686 is allowed and if they will result in a state change. 3688 Init: Initial state no session exist. 3690 Ready-nm: Ready state without any medias. 3692 Ready: Session is ready to start playing or recording. 3694 Play: Session is playing, i.e. sending media stream data in the 3695 direction S->C. 3697 Record: Session is recording, i.e. sending media stream data in the 3698 direction C->S. 3700 A.2 State variables 3702 This representation of the state machine needs more than its state to 3703 work. A small number of variables are also needed and is explained 3704 below. 3706 NRM: The number of media streams part of this session. 3708 RP: Resume point, the point in the presentation time line at which 3709 a request to continue will resume from. A time format for 3710 variable is not mandated. 3712 A.3 Abbreviations 3714 To make the state tables more compact a number of abbreviations are 3715 used, which are explained below. 3717 PP: Pause Point, the point in the presentation time line at which 3718 the presentation was paused. 3720 Prs: Presentation, the complete multimedia presentation. 3722 IFI: IF Implemented. 3724 RedP: Redirect Point, the point in the presentation time line at 3725 which a REDIRECT was specified to occur. 3727 SES: Session. 3729 A.4 State Tables 3731 This section contains a table for each state. The table contains all 3732 the requests and events that this state is allowed to act on. The 3733 events which is method names are, unless noted, requests with the 3734 given method in the direction client to server (C->S). In some cases 3735 there exist one or more requisite. The response column tells what 3736 type of response actions should be performed. Possible actions that 3737 is requested for an event includes: response codes, e.g. 200, headers 3738 that MUST be included in the response, setting of state variables, or 3739 setting of other session related parameters. The new state column 3740 tells which state the state machine shall change to. 3742 The response to valid request meeting the requisites is normally a 3743 2xx (SUCCESS) unless other noted in the response column. The excep- 3744 tions shall be given a response according to the response column. If 3745 the request does not meet the requisite, is erroneous or some other 3746 type of error occur the appropriate response code MUST be sent. If 3747 the response code is a 4xx the session state is unchanged. A response 3748 code of 3xx will result in that the session is ended and its state is 3749 changed to Init. However there exist restrictions to when a 3xx 3750 response may be used. A 5xx response SHALL not result in any change 3751 of the session state, except if the error is not possible to recover 3752 from. A unrecoverable error SHOULD result in ending of the session. 3754 The server will timeout the session after the period of time speci- 3755 fied in the SETUP response, if no activity from the client is 3756 detected. Therefore there exist a timeout event for all states 3757 except Init. 3759 In the case that NRM=1 the presentation URL is equal to the media 3760 URL. For NRM>1 the presentation URL MUST be other than any of the 3761 medias that are part of the session. This applies to all states. 3763 Event Prerequisite Response 3764 ----------------------------------------------------------------- 3765 DESCRIBE Needs REDIRECT 3xx Redirect 3766 DESCRIBE 200, Session description 3767 OPTIONS Session ID 200, Reset session timeout timer 3768 OPTIONS 200 3769 SET_PARAMETER Valid parameter 200, change value of parameter 3770 GET_PARAMETER Valid parameter 200, return value of parameter 3771 ANNOUNCE C->S, IFI record. 3772 ANNOUNCE S->C, Update SES descr. 3774 Table 5: None state-machine changing events 3776 The methods in Table 5 do not have any effect on the state machine or 3777 the state variables. However some methods do change other session 3778 related parameters, for example SET_PARAMETER which will set the 3779 parameter(s) specified in its body. 3781 The initial state of the state machine, see Table 6 can only be left 3782 by processing a correct SETUP request. As seen in the table the two 3783 state variables are also set by a correct request. This table also 3784 shows that a correct SETUP can in some cases be redirected to another 3785 URL and/or server by a 3xx response. 3787 Action Requisite New State Response 3788 ------------------------------------------------- 3789 SETUP Ready NRM=1, RP=0.0 3790 SETUP Needs Redirect Init 3xx Redirect 3792 Table 6: State: Init 3794 Action Requisite New State Response 3795 -------------------------------------------------------------- 3796 SETUP Ready NRM=1,RP=0.0 3797 SETUP Needs Redirect Init 3xx 3798 TEARDOWN URL=* Init No session hdr. 3799 Timeout Init 3800 S->C:REDIRECT Range hdr Play Set RedP 3801 S->C:REDIRECT no range hdr Init Stop Media Playout 3802 RedP reached Init 3804 Table 7: State: Ready-nm 3806 The Ready-nm state has no media streams and therefore can't play or 3807 record. This state exist so that all session related parameters and 3808 resources can be kept while changing media stream(s). As seen in 3809 Table 7 the operations are limited to setting up a new media or tear- 3810 ing down the session. The established session can also be redirected 3811 with the REDIRECT method. 3813 In the Ready state, see Table 8, some of the actions are depending on 3814 the number of media streams in the session, i.e. aggregated or non- 3815 aggregated control. A setup request in the ready state can either add 3816 one more media stream to the session or if the media stream (same 3817 URL) already is part of the session change the transport parameters. 3818 TEARDOWN is depending on both the request URI and the number of media 3819 stream within the session. If the request URI is either * or the pre- 3820 sentations URI the whole session is torn down. If a media URL is used 3821 in the TEARDOWN request the session will remain and a session header 3822 MUST be returned in the response. The number of media streams remain- 3823 ing after tearing down a media stream determines the new state. 3825 The Play state table, see Table 9, is the largest. The table contains 3826 an number of request that has presentation URL as a prerequisite on 3827 the request URL, this is due to the exclusion of non-aggregated 3828 stream control in sessions with more than one media stream. 3830 Action Requisite New State Response 3831 --------------------------------------------------------------------- 3832 SETUP New URL Ready NRM+=1 3833 SETUP Setten up URL Ready Change transport param. 3834 TEARDOWN URL=* Init No session hdr 3835 TEARDOWN Prs URL,NRM>1 Init No session hdr 3836 TEARDOWN md URL,NRM=1 Ready-nm Session hdr, NRM=0 3837 TEARDOWN md URL,NRM>1 Ready Session hdr, NRM-=1 3838 PLAY Prs URL, No range Play Play from RP 3839 PLAY Prs URL, Range Play according to range 3840 RECORD Record 3841 S->C:REDIRECT Range hdr Ready Set RedP 3842 S->C:REDIRECT no range hdr Init 3843 Timeout Init 3844 RedP reached Init 3846 Table 8: State: Ready 3848 Action Requisite New State Response 3849 ------------------------------------------------------------------------ 3850 PAUSE PrsURL,No range Ready Set RP to present point 3851 PAUSE PrsURL,Range>now Play Set RP & PP to given point 3852 PAUSE PrsURL,Range<=now Ready Set RP to present pos. 3853 PP reached Ready RP = PP 3854 End of media All media Play No action, RP = Invalid 3855 End of media >=1 Media plays Play No action 3856 End of range Play Set RP = End of range 3857 SETUP New URL,IFI Play NRM+=1, 200, RTP-Info 3858 SETUP New URL Play 501 3859 SETUP Setuped URL Play Change transport param. 3860 TEARDOWN URL=* Init No session hdr 3861 TEARDOWN Prs URL,NRM>1 Init No session hdr 3862 TEARDOWN md URL,NRM=1,IFI Ready-nm Session hdr 3863 TEARDOWN md URL,NRM>1,IFI Play Session hdr 3864 TEARDOWN md URL Play 501 3865 S->C:REDIRECT Range hdr Play Set RedP 3866 S->C:REDIRECT no range hdr Init Stop Media Playout 3867 RedP reached Init Stop Media playout 3868 Timeout Init 3870 Table 9: State: Play 3872 To avoid inconsistencies between the client and server, automatic 3873 state transitions are avoided. This can be seen at for example "End 3874 of media" event when all media has finished playing, the session 3875 still remain in Play state. An explicit PAUSE request must be sent to 3876 change the state to Ready. It may appear that there exist two auto- 3877 matic transitions in "RedP reached" and "PP reached", however they 3878 are requested and acknowledge before they take place. The time at 3879 which the transition will happen is known by looking at the range 3880 header. If the client sends request close in time to these transi- 3881 tions it must be prepared for getting error message as the state may 3882 or may not have changed. 3884 SETUP and TEARDOWN requests with media URLs in aggregated sessions 3885 may not be handled by the server as it is optional functionality. Use 3886 the service discovery mechanism with OPTIONS to find out in before- 3887 hand if the server implements it. If the functionality is not imple- 3888 mented but still tried by the client a "501 Not Implemented" response 3889 SHALL be received. 3891 Action Requisite New State Response 3892 ------------------------------------------------------------ 3893 PAUSE Ready 3894 Out-of-disc Record Stop recording 3895 TEARDOWN URL=* Init No session hdr 3896 TEARDOWN Prs URL,NRM>1 Init No session hdr 3897 TEARDOWN md URL,NRM=1,IFI Ready-nm Session hdr 3898 TEARDOWN md URL,NRM>1,IFI Record Session hdr 3899 TEARDOWN md URL Record 501 3900 S->C:REDIRECT Range hdr Record Set RedP 3901 S->C:REDIRECT w/o range hdr Init Stop Recording 3902 RedP reached Init Stop Recording 3903 Timeout Init 3905 Table 10: State: Record 3907 The Record state Table 10 has only one event which is unique for this 3908 table, namely the "out-of-disc" event. This event will happen if the 3909 recording server runs out of disc space. The state machine will 3910 remain in the Record state but the server will not be able to perform 3911 the actions related to the state. 3913 Something is needed to signal the client the fact that the 3914 server run out of disc space and not was capable of recording 3915 the data sent by the client. 3917 B Interaction with RTP 3919 RTSP allows media clients to control selected, non-contiguous sec- 3920 tions of media presentations, rendering those streams with an RTP 3921 media layer[23]. The media layer rendering the RTP stream should not 3922 be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP 3923 timestamps MUST be continuous and monotonic across jumps of NPT. 3925 As an example, assume a clock frequency of 8000 Hz, a packetization 3926 interval of 100 ms and an initial sequence number and timestamp of 3927 zero. First we play NPT 10 through 15, then skip ahead and play NPT 3928 18 through 20. The first segment is presented as RTP packets with 3929 sequence numbers 0 through 49 and timestamp 0 through 39,200. The 3930 second segment consists of RTP packets with sequence number 50 3931 through 69, with timestamps 40,000 through 55,200. 3933 We cannot assume that the RTSP client can communicate with the 3934 RTP media agent, as the two may be independent processes. If 3935 the RTP timestamp shows the same gap as the NPT, the media 3936 agent will assume that there is a pause in the presentation. 3937 If the jump in NPT is large enough, the RTP timestamp may roll 3938 over and the media agent may believe later packets to be 3939 duplicates of packets just played out. 3941 For certain datatypes, tight integration between the RTSP layer and 3942 the RTP layer will be necessary. This by no means precludes the above 3943 restriction. Combined RTSP/RTP media clients should use the RTP-Info 3944 field to determine whether incoming RTP packets were sent before or 3945 after a seek. 3947 For continuous audio, the server SHOULD set the RTP marker bit at the 3948 beginning of serving a new PLAY request. This allows the client to 3949 perform playout delay adaptation. 3951 For scaling (see Section 12.34), RTP timestamps should correspond to 3952 the playback timing. For example, when playing video recorded at 30 3953 frames/second at a scale of two and speed (Section 12.35) of one, the 3954 server would drop every second frame to maintain and deliver video 3955 packets with the normal timestamp spacing of 3,000 per frame, but NPT 3956 would increase by 1/15 second for each video frame. 3958 The client can maintain a correct display of NPT by noting the RTP 3959 timestamp value of the first packet arriving after repositioning. The 3960 sequence parameter of the RTP-Info (Section 12.33) header provides 3961 the first sequence number of the next segment. 3963 C Use of SDP for RTSP Session Descriptions 3965 The Session Description Protocol (SDP, RFC 2327 [24]) may be used to 3966 describe streams or presentations in RTSP. This description is typi- 3967 cally returned in reply to a DESCRIBE request on a URL from a server 3968 to a client, received via HTTP from a server to a client, or sent in 3969 an ANNOUNCE method from the client to the server. 3971 This appendix describes how an SDP file determines the operation of 3972 an RTSP session. SDP provides no mechanism by which a client can 3973 distinguish, without human guidance, between several media streams to 3974 be rendered simultaneously and a set of alternatives (e.g., two audio 3975 streams spoken in different languages). 3977 C.1 Definitions 3979 The terms "session-level", "media-level" and other key/attribute 3980 names and values used in this appendix are to be used as defined in 3981 SDP (RFC 2327 [24]): 3983 C.1.1 Control URL 3985 The "a=control:" attribute is used to convey the control URL. This 3986 attribute is used both for the session and media descriptions. If 3987 used for individual media, it indicates the URL to be used for con- 3988 trolling that particular media stream. If found at the session level, 3989 the attribute indicates the URL for aggregate control. 3991 Example: 3993 a=control:rtsp://example.com/foo 3995 This attribute may contain either relative and absolute URLs, follow- 3996 ing the rules and conventions set out in RFC 1808 [25]. Implementa- 3997 tions should look for a base URL in the following order: 3999 1. the RTSP Content-Base field; 4001 2. the RTSP Content-Location field; 4003 3. the RTSP request URL. 4005 If this attribute contains only an asterisk (*), then the URL is 4006 treated as if it were an empty embedded URL, and thus inherits the 4007 entire base URL. 4009 C.1.2 Media Streams 4011 The "m=" field is used to enumerate the streams. It is expected that 4012 all the specified streams will be rendered with appropriate synchro- 4013 nization. If the session is unicast, the port number serves as a rec- 4014 ommendation from the server to the client; the client still has to 4015 include it in its SETUP request and may ignore this recommendation. 4016 If the server has no preference, it SHOULD set the port number value 4017 to zero. 4019 Example: 4021 m=audio 0 RTP/AVP 31 4023 C.1.3 Payload Type(s) 4025 The payload type(s) are specified in the "m=" field. In case the pay- 4026 load type is a static payload type from RFC 1890 [1], no other infor- 4027 mation is required. In case it is a dynamic payload type, the media 4028 attribute "rtpmap" is used to specify what the media is. The "encod- 4029 ing name" within the "rtpmap" attribute may be one of those specified 4030 in RFC 1890 (Sections 5 and 6), or an experimental encoding with a 4031 "X-" prefix as specified in SDP (RFC 2327 [24]). Codec-specific 4032 parameters are not specified in this field, but rather in the "fmtp" 4033 attribute described below. Implementors seeking to register new 4034 encodings should follow the procedure in RFC 1890 [1]. If the media 4035 type is not suited to the RTP AV profile, then it is recommended that 4036 a new profile be created and the appropriate profile name be used in 4037 lieu of "RTP/AVP" in the "m=" field. 4039 C.1.4 Format-Specific Parameters 4041 Format-specific parameters are conveyed using the "fmtp" media 4042 attribute. The syntax of the "fmtp" attribute is specific to the 4043 encoding(s) that the attribute refers to. Note that the packetization 4044 interval is conveyed using the "ptime" attribute. 4046 C.1.5 Range of Presentation 4048 The "a=range" attribute defines the total time range of the stored 4049 session. (The length of live sessions can be deduced from the "t" and 4050 "r" parameters.) Unless the presentation contains media streams of 4051 different durations, the length attribute is a session-level 4052 attribute. The unit is specified first, followed by the value range. 4053 The units and their values are as defined in Section 3.4, 3.5 and 4054 3.6. 4056 Examples: 4058 a=range:npt=0-34.4368 4059 a=range:clock=19971113T2115-19971113T2203 4061 C.1.6 Time of Availability 4063 The "t=" field MUST contain suitable values for the start and stop 4064 times for both aggregate and non-aggregate stream control. With 4065 aggregate control, the server SHOULD indicate a stop time value for 4066 which it guarantees the description to be valid, and a start time 4067 that is equal to or before the time at which the DESCRIBE request was 4068 received. It MAY also indicate start and stop times of 0, meaning 4069 that the session is always available. With non-aggregate control, the 4070 values should reflect the actual period for which the session is 4071 available in keeping with SDP semantics, and not depend on other 4072 means (such as the life of the web page containing the description) 4073 for this purpose. 4075 C.1.7 Connection Information 4077 In SDP, the "c=" field contains the destination address for the media 4078 stream. However, for on-demand unicast streams and some multicast 4079 streams, the destination address is specified by the client via the 4080 SETUP request. Unless the media content has a fixed destination 4081 address, the "c=" field is to be set to a suitable null value. For 4082 addresses of type "IP4", this value is "0.0.0.0". 4084 C.1.8 Entity Tag 4086 The optional "a=etag" attribute identifies a version of the session 4087 description. It is opaque to the client. SETUP requests may include 4088 this identifier in the If-Match field (see section 12.22) to only 4089 allow session establishment if this attribute value still corresponds 4090 to that of the current description. The attribute value is opaque 4091 and may contain any character allowed within SDP attribute values. 4093 Example: 4095 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 4097 One could argue that the "o=" field provides identical func- 4098 tionality. However, it does so in a manner that would put 4099 constraints on servers that need to support multiple session 4100 description types other than SDP for the same piece of media 4101 content. 4103 C.2 Aggregate Control Not Available 4105 If a presentation does not support aggregate control and multiple 4106 media sections are specified, each section MUST have the control URL 4107 specified via the "a=control:" attribute. 4109 Example: 4111 v=0 4112 o=- 2890844256 2890842807 IN IP4 204.34.34.32 4113 s=I came from a web page 4114 c=IN IP4 0.0.0.0 4115 t=0 0 4116 m=video 8002 RTP/AVP 31 4117 a=control:rtsp://audio.com/movie.aud 4118 m=audio 8004 RTP/AVP 3 4119 a=control:rtsp://video.com/movie.vid 4121 Note that the position of the control URL in the description implies 4122 that the client establishes separate RTSP control sessions to the 4123 servers audio.com and video.com 4125 It is recommended that an SDP file contains the complete media ini- 4126 tialization information even if it is delivered to the media client 4127 through non-RTSP means. This is necessary as there is no mechanism to 4128 indicate that the client should request more detailed media stream 4129 information via DESCRIBE. 4131 C.3 Aggregate Control Available 4133 In this scenario, the server has multiple streams that can be con- 4134 trolled as a whole. In this case, there are both a media-level 4135 "a=control:" attributes, which are used to specify the stream URLs, 4136 and a session-level "a=control:" attribute which is used as the 4137 request URL for aggregate control. If the media-level URL is rela- 4138 tive, it is resolved to absolute URLs according to Section C.1.1 4139 above. 4141 If the presentation comprises only a single stream, the media-level 4142 "a=control:" attribute may be omitted altogether. However, if the 4143 presentation contains more than one stream, each media stream section 4144 MUST contain its own "a=control" attribute. 4146 Example: 4148 v=0 4149 o=- 2890844256 2890842807 IN IP4 204.34.34.32 4150 s=I contain 4151 i= 4152 c=IN IP4 0.0.0.0 4153 t=0 0 4154 a=control:rtsp://example.com/movie/ 4155 m=video 8002 RTP/AVP 31 4156 a=control:trackID=1 4157 m=audio 8004 RTP/AVP 3 4158 a=control:trackID=2 4160 In this example, the client is required to establish a single RTSP 4161 session to the server, and uses the URLs rtsp://exam- 4162 ple.com/movie/trackID=1 and rtsp://example.com/movie/trackID=2 to set 4163 up the video and audio streams, respectively. The URL rtsp://exam- 4164 ple.com/movie/ controls the whole movie. 4166 A client is not required to issues SETUP requests for all streams | 4167 within an aggregate object. Servers SHOULD allow the client to ask | 4168 for only a subset of the streams. 4170 D Minimal RTSP implementation 4172 D.1 Client 4174 A client implementation MUST be able to do the following : 4176 + Generate the following requests: SETUP, TEARDOWN, and one of PLAY 4177 (i.e., a minimal playback client) or RECORD (i.e., a minimal 4178 recording client). If RECORD is implemented, ANNOUNCE MUST be 4179 implemented as well. 4181 + Include the following headers in requests: CSeq, Connection, Ses- 4182 sion, Transport. If ANNOUNCE is implemented, the capability to 4183 include headers Content-Language, Content-Encoding, Content- 4184 Length, and Content-Type should be as well. 4186 + Parse and understand the following headers in responses: CSeq, 4187 Connection, Session, Transport, Content-Language, Content-Encod- 4188 ing, Content-Length, Content-Type. If RECORD is implemented, the 4189 Location header must be understood as well. RTP-compliant imple- 4190 mentations should also implement RTP-Info. 4192 + Understand the class of each error code received and notify the 4193 end-user, if one is present, of error codes in classes 4xx and 4194 5xx. The notification requirement may be relaxed if the end-user 4195 explicitly does not want it for one or all status codes. 4197 + Expect and respond to asynchronous requests from the server, such 4198 as ANNOUNCE. This does not necessarily mean that it should imple- 4199 ment the ANNOUNCE method, merely that it MUST respond positively 4200 or negatively to any request received from the server. 4202 Though not required, the following are RECOMMENDED. 4204 + Implement RTP/AVP/UDP as a valid transport. 4206 + Inclusion of the User-Agent header. 4208 + Understand SDP session descriptions as defined in Appendix C 4210 + Accept media initialization formats (such as SDP) from standard 4211 input, command line, or other means appropriate to the operating 4212 environment to act as a "helper application" for other applica- 4213 tions (such as web browsers). 4215 There may be RTSP applications different from those initially 4216 envisioned by the contributors to the RTSP specification for 4217 which the requirements above do not make sense. Therefore, the 4218 recommendations above serve only as guidelines instead of 4219 strict requirements. 4221 D.1.1 Basic Playback 4223 To support on-demand playback of media streams, the client MUST addi- 4224 tionally be able to do the following: 4226 + generate the PAUSE request; 4228 + implement the REDIRECT method, and the Location header. 4230 D.1.2 Authentication-enabled 4232 In order to access media presentations from RTSP servers that require 4233 authentication, the client MUST additionally be able to do the fol- 4234 lowing: 4236 + recognize the 401 (Unauthorized) status code; 4237 + parse and include the WWW-Authenticate header; 4239 + implement Basic Authentication and Digest Authentication. 4241 D.2 Server 4243 A minimal server implementation MUST be able to do the following: 4245 + Implement the following methods: SETUP, TEARDOWN, OPTIONS and 4246 either PLAY (for a minimal playback server) or RECORD (for a min- 4247 imal recording server). 4249 If RECORD is implemented, ANNOUNCE SHOULD be implemented as well. 4251 + Include the following headers in responses: Connection, Content- 4252 Length, Content-Type, Content-Language, Content-Encoding, Trans- 4253 port, Public. The capability to include the Location header 4254 should be implemented if the RECORD method is. RTP-compliant 4255 implementations should also implement the RTP-Info field. 4257 + Parse and respond appropriately to the following headers in 4258 requests: Connection, Session, Transport, Require. 4260 Though not required, the following are highly recommended at the time 4261 of publication for practical interoperability with initial implemen- 4262 tations and/or to be a "good citizen". 4264 + Implement RTP/AVP/UDP as a valid transport. 4266 + Inclusion of the Server header. 4268 + Implement the DESCRIBE method. 4270 + Generate SDP session descriptions as defined in Appendix C 4272 There may be RTSP applications different from those initially 4273 envisioned by the contributors to the RTSP specification for 4274 which the requirements above do not make sense. Therefore, the 4275 recommendations above serve only as guidelines instead of 4276 strict requirements. 4278 D.2.1 Basic Playback 4280 To support on-demand playback of media streams, the server MUST addi- 4281 tionally be able to do the following: 4283 + Recognize the Range header, and return an error if seeking is not 4284 supported. 4286 + Implement the PAUSE method. 4288 In addition, in order to support commonly-accepted user interface 4289 features, the following are highly recommended for on-demand media 4290 servers: 4292 + Include and parse the Range header, with NPT units. Implementa- 4293 tion of SMPTE units is recommended. 4295 + Include the length of the media presentation in the media ini- 4296 tialization information. 4298 + Include mappings from data-specific timestamps to NPT. When RTP 4299 is used, the rtptime portion of the RTP-Info field may be used to 4300 map RTP timestamps to NPT. 4302 Client implementations may use the presence of length informa- 4303 tion to determine if the clip is seekable, and visably disable 4304 seeking features for clips for which the length information is 4305 unavailable. A common use of the presentation length is to 4306 implement a "slider bar" which serves as both a progress indi- 4307 cator and a timeline positioning tool. 4309 Mappings from RTP timestamps to NPT are necessary to ensure correct 4310 positioning of the slider bar. 4312 D.2.2 Authentication-enabled 4314 In order to correctly handle client authentication, the server MUST 4315 additionally be able to do the following: 4317 + Generate the 401 (Unauthorized) status code when authentication 4318 is required for the resource. 4320 + Parse and include the WWW-Authenticate header 4322 + Implement Basic Authentication and Digest Authentication 4324 E Changes 4326 Since RFC 2326, the following issues were addressed: 4328 + http://rtsp.org/bug448521 - URLs in Rtp-Info need to be quoted 4329 + http://rtsp.org/bug448525 - Syntax for SSRC should be clarified 4331 + http://rtsp.org/bug461083 - Body w/o Content-Length clarification 4333 + http://rtsp.org/bug477407 - Transport BNF doesn't properly deal 4334 with semicolon and comma 4336 + http://rtsp.org/bug477413 - Transport BNF: mode parameter issues 4338 + http://rtsp.org/bug477416 - BNF error section 3.6 NPT 4340 + http://rtsp.org/bug477421 - When to send response 4342 + http://rtsp.org/bug507347 - Removal of destination redirection 4344 + http://rtsp.org/bug477404 - Expanded the table to something use- 4345 ful, proxy indications still missing. 4347 + http://rtsp.org/bug477419 - Started updating to rfc2616 by adding 4348 public header. Section references in header chapter needs update. 4350 + http://rtsp.org/bug500803 - Rewritten the complete chapter on the 4351 state machine. Needs review. 4353 + http://rtsp.org/bug513753 - Created a IANA section defining four 4354 registries. 4356 Note that this list does not reflect minor changes in wording or cor- 4357 rection of typographical errors. 4359 A word-by-word diff from RFC 2326 can be found at 4360 http://rtsp.org/2002/drafts 4362 F Author Addresses 4364 Henning Schulzrinne 4365 Dept. of Computer Science 4366 Columbia University 4367 1214 Amsterdam Avenue 4368 New York, NY 10027 4369 USA 4370 electronic mail: schulzrinne@cs.columbia.edu 4372 Anup Rao 4373 Cisco 4374 USA 4375 electronic mail: anrao@cisco.com 4376 Robert Lanphier 4377 RealNetworks 4378 P.O. Box 91123 4379 Seattle, WA 98111-9223 4380 USA 4381 electronic mail: robla@real.com 4383 Magnus Westerlund 4384 Ericsson AB, ERA/TVA/A 4385 Torshamsgatan 23 4386 SE-164 80 STOCKHOLM 4387 SWEDEN 4388 electronic mail: magnus.westerlund@ericsson.com 4390 G Acknowledgements 4392 This draft is based on the functionality of the original RTSP draft 4393 submitted in October 1996. It also borrows format and descriptions 4394 from HTTP/1.1. 4396 This document has benefited greatly from the comments of all those 4397 participating in the MMUSIC-WG. In addition to those already men- 4398 tioned, the following individuals have contributed to this specifica- 4399 tion: 4401 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 4402 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 4403 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 4404 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 4405 John K. Ho, Philipp Hoschka, Anne Jones, Anders Klemets, Ruth Lang, 4406 Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas Marshall, 4407 Rob McCool, Aravind Narasimhan, David Oran, Joerg Ott, Maria 4408 Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, 4409 Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Jeff 4410 Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, and 4411 David Walker. 4413 [1] H. Schulzrinne, "RTP profile for audio and video conferences with 4414 minimal control," RFC 1890, Internet Engineering Task Force, Jan. 4415 1996. 4417 [2] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee, 4418 "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet Engi- 4419 neering Task Force, Jan. 1997. 4421 [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Internationaliza- 4422 tion of the hypertext markup language," RFC 2070, Internet Engineer- 4423 ing Task Force, Jan. 1997. 4425 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 4426 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 4428 [5] ISO/IEC, "Information technology -- generic coding of moving pic- 4429 tures and associated audio informaiton -- part 6: extension for digi- 4430 tal storage media and control," Draft International Standard ISO 4431 13818-6, International Organization for Standardization ISO/IEC 4432 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 4434 [6] J. Franks, P. Hallam-Baker, and J. Hostetler, "An extension to 4435 HTTP: digest access authentication," RFC 2069, Internet Engineering 4436 Task Force, Jan. 1997. 4438 [7] J. Postel, "User datagram protocol," RFC STD 6, 768, Internet 4439 Engineering Task Force, Aug. 1980. 4441 [8] B. Hinden and C. Partridge, "Version 2 of the reliable data pro- 4442 tocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr. 1990. 4444 [9] J. Postel, "Transmission control protocol," RFC STD 7, 793, 4445 Internet Engineering Task Force, Sept. 1981. 4447 [10] H. Schulzrinne, "A comprehensive multimedia control architecture 4448 for the Internet," in Proc. International Workshop on Network and 4449 Operating System Support for Digital Audio and Video (NOSSDAV), (St. 4450 Louis, Missouri), May 1997. 4452 [11] P. McMahon, "GSS-API authentication method for SOCKS version 5," 4453 RFC 1961, Internet Engineering Task Force, June 1996. 4455 [12] J. Miller, P. Resnick, and D. Singer, "Rating services and rat- 4456 ing systems (and their machine readable descriptions)," Recommenda- 4457 tion REC-PICS-services-961031, W3C (World Wide Web Consortium), 4458 Boston, Massachusetts, Oct. 1996. 4460 [13] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 4461 distribution label syntax and communication protocols," Recommenda- 4462 tion REC-PICS-labels-961031, W3C (World Wide Web Consortium), Boston, 4463 Massachusetts, Oct. 1996. 4465 [14] D. Crocker and P. Overell, "Augmented BNF for syntax specifica- 4466 tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 1997. 4468 [15] B. Braden, "Requirements for internet hosts - application and 4469 support," RFC STD 3, 1123, Internet Engineering Task Force, Oct. 4470 1989. 4472 [16] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, 4473 Internet Engineering Task Force, Apr. 1996. 4475 [17] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 4476 locators (URL)," RFC 1738, Internet Engineering Task Force, Dec. 4477 1994. 4479 [18] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 4480 2279, Internet Engineering Task Force, Jan. 1998. 4482 [19] B. Braden, "T/TCP -- TCP extensions for transactions functional 4483 specification," RFC 1644, Internet Engineering Task Force, July 1994. 4485 [20] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 4486 Reading, Massachusetts: Addison-Wesley, 1994. 4488 [21] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 4489 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 4490 1998. 4492 [22] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 4493 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 4494 Task Force, Aug. 1998. 4496 [23] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 4497 a transport protocol for real-time applications," RFC 1889, Internet 4498 Engineering Task Force, Jan. 1996. 4500 [24] M. Handley and V. Jacobson, "SDP: session description protocol," 4501 RFC 2327, Internet Engineering Task Force, Apr. 1998. 4503 [25] R. Fielding, "Relative uniform resource locators," RFC 1808, 4504 Internet Engineering Task Force, June 1995. 4506 [26] R. Fielding, "Hypertext Transfer Protocol -- HTTP/1.1," RFC 4507 2616, Internet Engineering Task Force, June 1999. 4509 [27] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC 2246, 4510 Internet Engineering Task Force, Januari 1999. 4512 [28] International Telecommunication Union, "Visual telephone systems 4513 and equipment for local area networks which provide a non-guaranteed 4514 quality of service," Recommendation H.323, Telecommunications Stan- 4515 darization Sector of ITU, Geneva, Switzerland, May 1996. 4517 [29] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Con- 4518 siderations Section in RFCs," RFC2434, Internet Engineering Task 4519 Force, October 1998. 4521 Full Copyright Statement 4523 Copyright (C) The Internet Society (2002). All Rights Reserved. 4525 This document and translations of it may be copied and furnished to 4526 others, and derivative works that comment on or otherwise explain it 4527 or assist in its implmentation may be prepared, copied, published and 4528 distributed, in whole or in part, without restriction of any kind, 4529 provided that the above copyright notice and this paragraph are 4530 included on all such copies and derivative works. However, this docu- 4531 ment itself may not be modified in any way, such as by removing the 4532 copyright notice or references to the Internet Society or other 4533 Internet organizations, except as needed for the purpose of develop- 4534 ing Internet standards in which case the procedures for copyrights 4535 defined in the Internet Standards process must be followed, or as 4536 required to translate it into languages other than English. 4538 The limited permissions granted above are perpetual and will not be 4539 revoked by the Internet Society or its successors or assigns. 4541 This document and the information contained herein is provided on an 4542 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4543 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4544 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4545 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 4546 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4548 Table of Contents 4550 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 3 4551 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 4552 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . 4 4553 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 4554 1.4 Protocol Properties . . . . . . . . . . . . . . . . . . . 6 4555 1.5 Extending RTSP . . . . . . . . . . . . . . . . . . . . . 8 4556 1.6 Overall Operation . . . . . . . . . . . . . . . . . . . . 9 4557 1.7 RTSP States . . . . . . . . . . . . . . . . . . . . . . . 10 4558 1.8 Relationship with Other Protocols . . . . . . . . . . . . 11 4559 2 Notational Conventions . . . . . . . . . . . . . . . . . 11 4560 3 Protocol Parameters . . . . . . . . . . . . . . . . . . . 12 4561 3.1 RTSP Version . . . . . . . . . . . . . . . . . . . . . . 12 4562 3.2 RTSP URL . . . . . . . . . . . . . . . . . . . . . . . . 12 4563 3.3 Session Identifiers . . . . . . . . . . . . . . . . . . . 13 4564 3.4 SMPTE Relative Timestamps . . . . . . . . . . . . . . . . 14 4565 3.5 Normal Play Time . . . . . . . . . . . . . . . . . . . . 14 4566 3.6 Absolute Time . . . . . . . . . . . . . . . . . . . . . . 15 4567 3.7 Option Tags . . . . . . . . . . . . . . . . . . . . . . . 16 4568 3.7.1 Registering New Option Tags with IANA . . . . . . . . . . 16 4569 4 RTSP Message . . . . . . . . . . . . . . . . . . . . . . 17 4570 4.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 17 4571 4.2 Message Headers . . . . . . . . . . . . . . . . . . . . . 17 4572 4.3 Message Body . . . . . . . . . . . . . . . . . . . . . . 17 4573 4.4 Message Length . . . . . . . . . . . . . . . . . . . . . 17 4574 5 General Header Fields . . . . . . . . . . . . . . . . . . 18 4575 6 Request . . . . . . . . . . . . . . . . . . . . . . . . . 18 4576 6.1 Request Line . . . . . . . . . . . . . . . . . . . . . . 19 4577 6.2 Request Header Fields . . . . . . . . . . . . . . . . . . 19 4578 7 Response . . . . . . . . . . . . . . . . . . . . . . . . 20 4579 7.1 Status-Line . . . . . . . . . . . . . . . . . . . . . . . 20 4580 7.1.1 Status Code and Reason Phrase . . . . . . . . . . . . . . 21 4581 7.1.2 Response Header Fields . . . . . . . . . . . . . . . . . 23 4582 8 Entity . . . . . . . . . . . . . . . . . . . . . . . . . 25 4583 8.1 Entity Header Fields . . . . . . . . . . . . . . . . . . 25 4584 8.2 Entity Body . . . . . . . . . . . . . . . . . . . . . . . 25 4585 9 Connections . . . . . . . . . . . . . . . . . . . . . . . 26 4586 9.1 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 26 4587 9.2 Reliability and Acknowledgements . . . . . . . . . . . . 26 4588 10 Method Definitions . . . . . . . . . . . . . . . . . . . 27 4589 10.1 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 27 4590 10.2 DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 28 4591 10.3 ANNOUNCE . . . . . . . . . . . . . . . . . . . . . . . . 30 4592 10.4 SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4593 10.5 PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4594 10.6 PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4595 10.7 TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 36 4596 10.8 GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 36 4597 10.9 SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . . 37 4598 10.10 REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 38 4599 10.11 RECORD . . . . . . . . . . . . . . . . . . . . . . . . . 39 4600 10.12 PING . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4601 10.13 Embedded (Interleaved) Binary Data . . . . . . . . . . . 40 4602 11 Status Code Definitions . . . . . . . . . . . . . . . . . 41 4603 11.1 Success 2xx . . . . . . . . . . . . . . . . . . . . . . . 41 4604 11.1.1 250 Low on Storage Space . . . . . . . . . . . . . . . . 41 4605 11.2 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 41 4606 11.3 Client Error 4xx . . . . . . . . . . . . . . . . . . . . 41 4607 11.4 400 Bad Request . . . . . . . . . . . . . . . . . . . . . 42 4608 11.4.1 405 Method Not Allowed . . . . . . . . . . . . . . . . . 42 4609 11.4.2 451 Parameter Not Understood . . . . . . . . . . . . . . 42 4610 11.4.3 452 reserved . . . . . . . . . . . . . . . . . . . . . . 42 4611 11.4.4 453 Not Enough Bandwidth . . . . . . . . . . . . . . . . 42 4612 11.4.5 454 Session Not Found . . . . . . . . . . . . . . . . . . 42 4613 11.4.6 455 Method Not Valid in This State . . . . . . . . . . . 42 4614 11.4.7 456 Header Field Not Valid for Resource . . . . . . . . . 42 4615 11.4.8 457 Invalid Range . . . . . . . . . . . . . . . . . . . . 43 4616 11.4.9 458 Parameter Is Read-Only . . . . . . . . . . . . . . . 43 4617 11.4.10 459 Aggregate Operation Not Allowed . . . . . . . . . . . 43 4618 11.4.11 460 Only Aggregate Operation Allowed . . . . . . . . . . 43 4619 11.4.12 461 Unsupported Transport . . . . . . . . . . . . . . . . 43 4620 11.4.13 462 Destination Unreachable . . . . . . . . . . . . . . . 43 4621 11.5 Server Error 5xx . . . . . . . . . . . . . . . . . . . . 43 4622 11.5.1 551 Option not supported . . . . . . . . . . . . . . . . 43 4623 12 Header Field Definitions . . . . . . . . . . . . . . . . 43 4624 12.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . 46 4625 12.2 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 46 4626 12.3 Accept-Language . . . . . . . . . . . . . . . . . . . . . 46 4627 12.4 Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 46 4628 12.5 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4629 12.6 Authorization . . . . . . . . . . . . . . . . . . . . . . 48 4630 12.7 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 49 4631 12.8 Blocksize . . . . . . . . . . . . . . . . . . . . . . . . 49 4632 12.9 Cache-Control . . . . . . . . . . . . . . . . . . . . . . 49 4633 12.10 Connection . . . . . . . . . . . . . . . . . . . . . . . 51 4634 12.11 Content-Base . . . . . . . . . . . . . . . . . . . . . . 51 4635 12.12 Content-Encoding . . . . . . . . . . . . . . . . . . . . 52 4636 12.13 Content-Language . . . . . . . . . . . . . . . . . . . . 52 4637 12.14 Content-Length . . . . . . . . . . . . . . . . . . . . . 52 4638 12.15 Content-Location . . . . . . . . . . . . . . . . . . . . 52 4639 12.16 Content-Type . . . . . . . . . . . . . . . . . . . . . . 52 4640 12.17 CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4641 12.18 Date . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4642 12.19 Expires . . . . . . . . . . . . . . . . . . . . . . . . . 53 4643 12.20 From . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4644 12.21 Host . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4645 12.22 If-Match . . . . . . . . . . . . . . . . . . . . . . . . 54 4646 12.23 If-Modified-Since . . . . . . . . . . . . . . . . . . . . 54 4647 12.24 Last-Modified . . . . . . . . . . . . . . . . . . . . . . 55 4648 12.25 Location . . . . . . . . . . . . . . . . . . . . . . . . 55 4649 12.26 Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 55 4650 12.27 Proxy-Require . . . . . . . . . . . . . . . . . . . . . . 55 4651 12.28 Public . . . . . . . . . . . . . . . . . . . . . . . . . 55 4652 12.29 Range . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4653 12.30 Referer . . . . . . . . . . . . . . . . . . . . . . . . . 57 4654 12.31 Retry-After . . . . . . . . . . . . . . . . . . . . . . . 57 4655 12.32 Require . . . . . . . . . . . . . . . . . . . . . . . . . 57 4656 12.33 RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 58 4657 12.34 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4658 12.35 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4659 12.36 Server . . . . . . . . . . . . . . . . . . . . . . . . . 61 4660 12.37 Session . . . . . . . . . . . . . . . . . . . . . . . . . 61 4661 12.38 Supported . . . . . . . . . . . . . . . . . . . . . . . . 61 4662 12.39 Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 62 4663 12.40 Transport . . . . . . . . . . . . . . . . . . . . . . . . 62 4664 12.41 Unsupported . . . . . . . . . . . . . . . . . . . . . . . 66 4665 12.42 User-Agent . . . . . . . . . . . . . . . . . . . . . . . 66 4666 12.43 Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4667 12.44 Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4668 12.45 WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 66 4669 13 Caching . . . . . . . . . . . . . . . . . . . . . . . . . 66 4670 14 Examples . . . . . . . . . . . . . . . . . . . . . . . . 67 4671 14.1 Media on Demand (Unicast) . . . . . . . . . . . . . . . . 67 4672 14.2 Streaming of a Container file . . . . . . . . . . . . . . 69 4673 14.3 Single Stream Container Files . . . . . . . . . . . . . . 72 4674 14.4 Live Media Presentation Using Multicast . . . . . . . . . 74 4675 14.5 Recording . . . . . . . . . . . . . . . . . . . . . . . . 75 4676 15 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 76 4677 15.1 Base Syntax . . . . . . . . . . . . . . . . . . . . . . . 76 4678 16 Security Considerations . . . . . . . . . . . . . . . . . 77 4679 17 IANA Considerations . . . . . . . . . . . . . . . . . . . 79 4680 17.1 Option-tags . . . . . . . . . . . . . . . . . . . . . . . 80 4681 17.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . 80 4682 17.1.2 Registering New Option Tags with IANA . . . . . . . . . . 80 4683 17.1.3 Registered entries . . . . . . . . . . . . . . . . . . . 81 4684 17.2 RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 81 4685 17.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 81 4686 17.2.2 Registering New Methods with IANA . . . . . . . . . . . . 81 4687 17.2.3 Registered entries . . . . . . . . . . . . . . . . . . . 81 4688 17.3 RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 82 4689 17.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 82 4690 17.3.2 Registering New Headers with IANA . . . . . . . . . . . . 82 4691 17.3.3 Registered entries . . . . . . . . . . . . . . . . . . . 82 4692 17.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . 82 4693 17.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 82 4694 17.4.2 Registering New Parameters with IANA . . . . . . . . . . 83 4695 17.4.3 Registered entries . . . . . . . . . . . . . . . . . . . 83 4696 A RTSP Protocol State Machine . . . . . . . . . . . . . . . 83 4697 A.1 States . . . . . . . . . . . . . . . . . . . . . . . . . 83 4698 A.2 State variables . . . . . . . . . . . . . . . . . . . . . 84 4699 A.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 84 4700 A.4 State Tables . . . . . . . . . . . . . . . . . . . . . . 84 4701 B Interaction with RTP . . . . . . . . . . . . . . . . . . 89 4702 C Use of SDP for RTSP Session Descriptions . . . . . . . . 90 4703 C.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 90 4704 C.1.1 Control URL . . . . . . . . . . . . . . . . . . . . . . . 90 4705 C.1.2 Media Streams . . . . . . . . . . . . . . . . . . . . . . 91 4706 C.1.3 Payload Type(s) . . . . . . . . . . . . . . . . . . . . . 91 4707 C.1.4 Format-Specific Parameters . . . . . . . . . . . . . . . 91 4708 C.1.5 Range of Presentation . . . . . . . . . . . . . . . . . . 91 4709 C.1.6 Time of Availability . . . . . . . . . . . . . . . . . . 92 4710 C.1.7 Connection Information . . . . . . . . . . . . . . . . . 92 4711 C.1.8 Entity Tag . . . . . . . . . . . . . . . . . . . . . . . 92 4712 C.2 Aggregate Control Not Available . . . . . . . . . . . . . 93 4713 C.3 Aggregate Control Available . . . . . . . . . . . . . . . 93 4714 D Minimal RTSP implementation . . . . . . . . . . . . . . . 94 4715 D.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . 94 4716 D.1.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 95 4717 D.1.2 Authentication-enabled . . . . . . . . . . . . . . . . . 95 4718 D.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . 96 4719 D.2.1 Basic Playback . . . . . . . . . . . . . . . . . . . . . 96 4720 D.2.2 Authentication-enabled . . . . . . . . . . . . . . . . . 97 4721 E Changes . . . . . . . . . . . . . . . . . . . . . . . . . 97 4722 F Author Addresses . . . . . . . . . . . . . . . . . . . . 98 4723 G Acknowledgements . . . . . . . . . . . . . . . . . . . . 99