idnits 2.17.1 draft-ietf-mmusic-rtsp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 20) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 81: '...vers and clients MAY use the HTTP stat...' RFC 2119 keyword, line 299: '... A server SHOULD implement all heade...' RFC 2119 keyword, line 482: '...ddresses in URLs SHOULD be avoided whe...' RFC 2119 keyword, line 520: '...conference identifier MUST be globally...' RFC 2119 keyword, line 646: '...se message which MUST NOT include a me...' (63 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 472 has weird spacing: '... scheme rtsp ...' == Line 473 has weird spacing: '... scheme rtspu...' == Line 871 has weird spacing: '... Code rea...' == Line 893 has weird spacing: '...equired all...' == Line 1037 has weird spacing: '... object req...' == (8 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Notes on Table 2: PAUSE is recommend, but not required in that a fully functional server can be built that does not support this method, for example, for live feeds. If a server does not support a particular method, it MUST return "501 Not Implemented" and a client SHOULD not try this method again for this server. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 27, 1997) is 9884 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 2590 looks like a reference -- Missing reference section? '2' on line 2594 looks like a reference -- Missing reference section? '3' on line 2597 looks like a reference -- Missing reference section? '4' on line 2601 looks like a reference -- Missing reference section? '5' on line 2605 looks like a reference -- Missing reference section? '6' on line 2609 looks like a reference -- Missing reference section? '7' on line 2612 looks like a reference -- Missing reference section? '8' on line 2616 looks like a reference -- Missing reference section? '9' on line 2620 looks like a reference -- Missing reference section? '10' on line 2623 looks like a reference -- Missing reference section? '11' on line 2627 looks like a reference -- Missing reference section? '12' on line 2630 looks like a reference -- Missing reference section? '13' on line 2634 looks like a reference -- Missing reference section? '14' on line 2637 looks like a reference -- Missing reference section? '15' on line 2641 looks like a reference -- Missing reference section? '16' on line 2644 looks like a reference -- Missing reference section? '17' on line 2648 looks like a reference -- Missing reference section? '18' on line 2653 looks like a reference -- Missing reference section? 'H6' on line 721 looks like a reference -- Missing reference section? 'H10' on line 1447 looks like a reference -- Missing reference section? 'CRLF' on line 2315 looks like a reference -- Missing reference section? 'H15' on line 2347 looks like a reference -- Missing reference section? '19' on line 2659 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 24 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, A. Rao, R. Lanphier 4 ietf-mmusic-rtsp-02.txt Columbia U./Netscape/Progressive Networks 5 March 27, 1997 6 Expires: September 26, 1997 8 Real Time Streaming Protocol (RTSP) 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 The Real Time Streaming Protocol, or RTSP, is an 33 application-level protocol for control over the delivery 34 of data with real-time properties. RTSP provides an 35 extensible framework to enable controlled, on-demand 36 delivery of real-time data, such as audio and video. 37 Sources of data can include both live data feeds and 38 stored clips. This protocol is intended to control 39 multiple data delivery sessions, provide a means for 40 choosing delivery channels such as UDP, multicast UDP and 41 TCP, and delivery mechanisms based upon RTP (RFC 1889). 43 1 Introduction 45 1.1 Purpose 47 The Real-Time Streaming Protocol (RTSP) establishes and controls 48 either a single or several time-synchronized streams of continuous 49 media such as audio and video. It does not typically deliver the 50 continuous streams itself, although interleaving of the continuous 51 media stream with the control stream is possible (see Section 9.11). 52 In other words, RTSP acts as a "network remote control" for 53 multimedia servers. 55 The set of streams to be controlled is defined by a presentation 56 description. This memorandum does not define a format for a 57 presentation description. 59 There is no notion of an RTSP connection; instead, a server maintains 60 a session labeled by an identifier. An RTSP session is in no way tied 61 to a transport-level connection such as a TCP connection. During an 62 RTSP session, an RTSP client may open and close many reliable 63 transport connections to the server to issue RTSP requests. 64 Alternatively, it may use a connectionless transport protocol such as 65 UDP. 67 The streams controlled by RTSP may use RTP [1], but the operation of 68 RTSP does not depend on the transport mechanism used to carry 69 continuous media. 71 The protocol is intentionally similar in syntax and operation to 72 HTTP/1.1, so that extension mechanisms to HTTP can in most cases also 73 be added to RTSP. However, RTSP differs in a number of important 74 aspects from HTTP: 76 o RTSP introduces a number of new methods and has a different 77 protocol identifier. 79 o An RTSP server needs to maintain state by default in almost 80 all cases, as opposed to the stateless nature of HTTP. (RTSP 81 servers and clients MAY use the HTTP state maintenance 82 mechanism [2].) 84 o Both an RTSP server and client can issue requests. 86 o Data is carried out-of-band, by a different protocol. (There 87 is an exception to this.) 89 o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 90 8859-1, consistent with current HTML internationalization 91 efforts [3]. 93 o The Request-URI always contains the absolute URI. Because of 94 backward compatibility with a historical blunder, HTTP/1.1 95 carries only the absolute path in the request 96 This makes virtual hosting easier. However, this is 97 incompatible with HTTP/1.1, which may be a bad idea. 99 The protocol supports the following operations: 101 Retrieval of media from media server: The client can request a 102 presentation description via HTTP or some other method. If the 103 presentation is being multicast, the presentation description 104 contains the multicast addresses and ports to be used for the 105 continuous media. If the presentation is to be sent only to the 106 client via unicast, the client provides the destination for 107 security reasons. 109 Invitation of a media server to a conference: A media server can be 110 "invited" to join an existing conference, either to play back 111 media into the presentation or to record all or a subset of the 112 media in a presentation. This mode is useful for distributed 113 teaching applications. Several parties in the conference may 114 take turns "pushing the remote control buttons". 116 Addition of media to an existing presentation: Particularly for live 117 presentations, it is useful if the server can tell the client 118 about additional media becoming available. 120 RTSP requests may be handled by proxies, tunnels and caches as in 121 HTTP/1.1. 123 1.2 Requirements 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC xxxx [4]. 129 1.3 Terminology 131 Some of the terminology has been adopted from HTTP/1.1 [5]. Terms 132 not listed here are defined as in HTTP/1.1. 134 Conference: a multiparty, multimedia presentation, where "multi" 135 implies greater than or equal to one. 137 Client: The client requests continuous media data from the media 138 server. 140 Connection: A transport layer virtual circuit established between two 141 programs for the purpose of communication. 143 Continuous media: Data where there is a timing relationship between 144 source and sink, that is, the sink must reproduce the timing 145 relationshop that existed at the source. The most common 146 examples of continuous media are audio and motion video. 147 Continuous media can be realtime (interactive) , where there is 148 a "tight" timing relationship between source and sink, or 149 streaming (playback) , where the relationship is less strict. 151 Participant: Participants are members of conferences. A participant 152 may be a machine, e.g., a media record or playback server. 154 Media server: The network entity providing playback or recording 155 services for one or more media streams. Different media streams 156 within a presentation may originate from different media 157 servers. A media server may reside on the same or a different 158 host as the web server the presentation is invoked from. 160 Media parameter: Parameter specific to a media type that may be 161 changed while the stream is being played or prior to it. 163 (Media) stream: A single media instance, e.g., an audio stream or a 164 video stream as well as a single whiteboard or shared 165 application group. When using RTP, a stream consists of all RTP 166 and RTCP packets created by a source within an RTP session. This 167 is equivalent to the definition of a DSM-CC stream. 169 Message: The basic unit of RTSP communication, consisting of a 170 structured sequence of octets matching the syntax defined in 171 Section 14 and transmitted via a connection or a connectionless 172 protocol. 174 Presentation: A set of one or more streams which the server allows 175 the client to manipulate together. A presentation has a single 176 time axis for all streams belonging to it. Presentations are 177 defined by presentation descriptions (see below). A presentation 178 description contains RTSP URIs that define which streams can be 179 controlled individually and an RTSP URI to control the whole 180 presentation. A movie or live concert consisting of one or more 181 audio and video streams is be an example of a presentation. 183 Presentation description: A presentation description contains 184 information about one or more media streams within a 185 presentation, such as the set of encodings, network addresses 186 and information about the content. Other IETF protocols such as 187 SDP [6] use the term "session" for a live presentation. The 188 presentation description may take several different formats, 189 including but not limited to the session description format SDP. 191 Response: An RTSP response. If an HTTP response is meant, that is 192 indicated explicitly. 194 Request: An RTSP request. If an HTTP request is meant, that is 195 indicated explicitly. 197 RTSP session: A complete RTSP "transaction", e.g., the viewing of a 198 movie. A session typically consist of a client setting up a 199 transport mechanism for the continuous media stream ( SETUP), 200 starting the stream with PLAY or RECORD and closing the stream 201 with TEARDOWN. 203 1.4 Protocol Properties 205 RTSP has the following properties: 207 Extendable: New methods and parameters can be easily added to RTSP. 209 Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers. 211 Secure: RTSP re-uses web security mechanisms, either at the transport 212 level (TLS [7]) or within the protocol itself. All HTTP 213 authentication mechanisms such as basic [5] and digest 214 authentication [8] are directly applicable. 216 Transport-independent: RTSP may use either an unreliable datagram 217 protocol (UDP) [9], a reliable datagram protocol (RDP, not 218 widely used [10]) or a reliable stream protocol such as TCP [11] 219 as it implements application-level reliability. 221 Multi-server capable: Each media stream within a presentation can 222 reside on a different server. The client automatically 223 establishes several concurrent control sessions with the 224 different media servers. Media synchronization is performed at 225 the transport level. 227 Control of recording devices: The protocol can control both recording 228 and playback devices, as well as devices that can alternate 229 between the two modes ("VCR"). 231 Separation of stream control and conference initiation: Stream 232 control is divorced from inviting a media server to a 233 conference. The only requirement is that the conference 234 initiation protocol either provides or can be used to create a 235 unique conference identifier. In particular, SIP [12] or H.323 236 may be used to invite a server to a conference. 238 Suitable for professional applications: RTSP supports frame-level 239 accuracy through SMPTE time stamps to allow remote digital 240 editing. 242 Presentation description neutral: The protocol does not impose a 243 particular presentation description or metafile format and can 244 convey the type of format to be used. However, the presentation 245 description must contain at least one RTSP URI. 247 Proxy and firewall friendly: The protocol should be readily handled 248 by both application and transport-layer (SOCKS [13]) firewalls. 249 A firewall may need to understand the SETUP method to open a 250 "hole" for the UDP media stream. 252 HTTP-friendly: Where sensible, RTSP re-uses HTTP concepts, so that 253 the existing infrastructure can be re-used. This infrastructure 254 includes JEPI (the Joint Electronic Payment Initiative) for 255 electronic payments and PICS (Platform for Internet Content 256 Selection) for associating labels with content. However, RTSP 257 does not just add methods to HTTP, since the controlling 258 continuous media requires server state in most cases. 260 Appropriate server control: If a client can start a stream, it must 261 be able to stop a stream. Servers should not start streaming to 262 clients in such a way that clients cannot stop the stream. 264 Transport negotiation: The client can negotiate the transport method 265 prior to actually needing to process a continuous media stream. 267 Capability negotiation: If basic features are disabled, there must be 268 some clean mechanism for the client to determine which methods 269 are not going to be implemented. This allows clients to present 270 the appropriate user interface. For example, if seeking is not 271 allowed, the user interface must be able to disallow moving a 272 sliding position indicator. 274 An earlier requirement in RTSP' was multi-client 275 capability. However, it was determined that a better 276 approach was to make sure that the protocol is easily 277 extensible to the multi-client scenario. Stream identifiers 278 can be used by several control streams, so that "passing 279 the remote" would be possible. The protocol would not 280 address how several clients negotiate access; this is left 281 to either a "social protocol" or some other floor control 282 mechanism. 284 1.5 Extending RTSP 286 Since not all media servers have the same functionality, media 287 servers by necessity will support different sets of requests. For 288 example: 290 o A server may only be capable of playback, not recording and 291 thus has no need to support the RECORD request. 293 o A server may not be capable of seeking (absolute positioning), 294 say, if it is to support live events only. 296 o Some servers may not support setting stream parameters and 297 thus not support GET_PARAMETER and SET_PARAMETER. 299 A server SHOULD implement all header fields described in Section 11. 301 It is up to the creators of presentation descriptions not to ask the 302 impossible of a server. This situation is similar in HTTP/1.1, where 303 the methods described in [H19.6] are not likely to be supported 304 across all servers. 306 RTSP can be extended in three ways, listed in order of the magnitude 307 of changes supported: 309 o Existing methods can be extended with new parameters, as long 310 as these parameters can be safely ignored by the recipient. 311 (This is equivalent to adding new parameters to an HTML tag.) 313 o New methods can be added. If the recipient of the message does 314 not understand the request, it responds with error code 501 315 (Not implemented) and the sender can then attempt an earlier, 316 less functional version. 318 o A new version of the protocol can be defined, allowing almost 319 all aspects (except the position of the protocol version 320 number) to change. 322 1.6 Overall Operation 324 Each presentation and media stream may be identified by an RTSP URL. 325 The overall presentation and the properties of the media the 326 presentation is made up of are defined by a presentation description 327 file, the format of which is outside the scope of this specification. 328 The presentation description file may be obtained by the client using 329 HTTP or other means such as email and may not necessarily be stored 330 on the media server. 332 For the purposes of this specification, a presentation description is 333 assumed to describe one or more presentations, each of which 334 maintains a common time axis. For simplicity of exposition and 335 without loss of generality, it is assumed that the presentation 336 description contains exactly one such presentation. A presentation 337 may contain several media streams. 339 The presentation description file contains a description of the media 340 streams making up the presentation, including their encodings, 341 language, and other parameters that enable the client to choose the 342 most appropriate combination of media. In this presentation 343 description, each media stream that is individually controllable by 344 RTSP is identified by an RTSP URL, which points to the media server 345 handling that particular media stream and names the stream stored on 346 that server. Several media streams can be located on different 347 servers; for example, audio and video streams can be split across 348 servers for load sharing. The description also enumerates which 349 transport methods the server is capable of. 351 Besides the media parameters, the network destination address and 352 port need to be determined. Several modes of operation can be 353 distinguished: 355 Unicast: The media is transmitted to the source of the RTSP request, 356 with the port number chosen by the client. Alternatively, the 357 media is transmitted on the same reliable stream as RTSP. 359 Multicast, server chooses address: The media server picks the 360 multicast address and port. This is the typical case for a live 361 or near-media-on-demand transmission. 363 Multicast, client chooses address: If the server is to participate in 364 an existing multicast conference, the multicast address, port 365 and encryption key are given by the conference description, 366 established by means outside the scope of this specification. 368 1.7 RTSP States 370 RTSP controls a stream which may be sent via a separate protocol, 371 independent of the control channel. For example, RTSP control may 372 occur on a TCP connection while the data flows via UDP. Thus, data 373 delivery continues even if no RTSP requests are received by the media 374 server. Also, during its lifetime, a single media stream may be 375 controlled by RTSP requests issued sequentially on different TCP 376 connections. Therefore, the server needs to maintain "session state" 377 to be able to correlate RTSP requests with a stream. The state 378 transitions are described in Section A. 380 Many methods in RTSP do not contribute to state. However, the 381 following play a central role in defining the allocation and usage of 382 stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and 383 TEARDOWN. 385 SETUP: Causes the server to allocate resources for a stream and start 386 an RTSP session. 388 PLAY and RECORD: Starts data transmission on a stream allocated via 389 SETUP. 391 PAUSE: Temporarily halts a stream, without freeing server resources. 393 TEARDOWN: Frees resources associated with the stream. The RTSP 394 session ceases to exist on the server. 396 1.8 Relationship with Other Protocols 398 RTSP has some overlap in functionality with HTTP. It also may 399 interact with HTTP in that the initial contact with streaming content 400 is often to be made through a web page. The current protocol 401 specification aims to allow different hand-off points between a web 402 server and the media server implementing RTSP. For example, the 403 presentation description can be retrieved using HTTP or RTSP. Having 404 the presentation description be returned by the web server makes it 405 possible to have the web server take care of authentication and 406 billing, by handing out a presentation description whose media 407 identifier includes an encrypted version of the requestor's IP 408 address and a timestamp, with a shared secret between web and media 409 server. 411 However, RTSP differs fundamentally from HTTP in that data delivery 412 takes place out-of-band, in a different protocol. HTTP is an 413 asymmetric protocol, where the client issues requests and the server 414 responds. In RTSP, both the media client and media server can issue 415 requests. RTSP requests are also not stateless, in that they may set 416 parameters and continue to control a media stream long after the 417 request has been acknowledged. 419 Re-using HTTP functionality has advantages in at least two 420 areas, namely security and proxies. The requirements are 421 very similar, so having the ability to adopt HTTP work on 422 caches, proxies and authentication is valuable. 424 While most real-time media will use RTP as a transport protocol, RTSP 425 is not tied to RTP. 427 RTSP assumes the existence of a presentation description format that 428 can express both static and temporal properties of a presentation 429 containing several media streams. 431 2 Notational Conventions 433 Since many of the definitions and syntax are identical to HTTP/1.1, 434 this specification only points to the section where they are defined 435 rather than copying it. For brevity, [HX.Y] is to be taken to refer 436 to Section X.Y of the current HTTP/1.1 specification (RFC 2068). 438 All the mechanisms specified in this document are described in both 439 prose and an augmented Backus-Naur form (BNF) similar to that used in 440 RFC 2068 [H2.1]. It is described in detail in [14]. 442 In this draft, we use indented and smaller-type paragraphs to provide 443 background and motivation. Some of these paragraphs are marked with 444 HS, AR and RL, designating opinions and comments by the individual 445 authors which may not be shared by the co-authors and require 446 resolution. 448 3 Protocol Parameters 450 3.1 RTSP Version 452 applies, with HTTP replaced by RTSP. 454 3.2 RTSP URL 456 The "rtsp" and "rtspu" schemes are used to refer to network resources 457 via the RTSP protocol. This section defines the scheme-specific 458 syntax and semantics for RTSP URLs. 460 rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path] 461 host = 464 port = *DIGIT 466 abs_path is defined in [H3.2.1]. 468 Note that fragment and query identifiers do not have a 469 well-defined meaning at this time, with the interpretation 470 left to the RTSP server. 472 The scheme rtsp requires that commands are issued via a reliable 473 protocol (within the Internet, TCP), while the scheme rtspu 474 identifies an unreliable protocol (within the Internet, UDP). 476 If the port is empty or not given, port 554 is assumed. The semantics 477 are that the identified resource can be controlled be RTSP at the 478 server listening for TCP (scheme "rtsp") connections or UDP (scheme 479 "rtspu") packets on that port of host , and the Request-URI for the 480 resource is rtsp_URL 482 The use of IP addresses in URLs SHOULD be avoided whenever possible 483 (see RFC 1924 [15]). 485 A presentation or a stream is identified by an textual media 486 identifier, using the character set and escape conventions [H3.2] of 487 URLs [16]. Requests described in Section 9 can refer to either the 488 whole presentation or an individual stream within the presentation. 489 Note that some methods can only be applied to streams, not 490 presentations and vice versa. A specific instance of a presentation 491 or stream, e.g., one of several concurrent transmissions of the same 492 content, an RTSP session , is indicated by the Session header field 493 (Section 11.26) where needed. 495 For example, the RTSP URL 497 rtsp://media.example.com:554/twister/audiotrack 499 identifies the audio stream within the presentation "twister", which 500 can be controlled via RTSP requests issued over a TCP connection to 501 port 554 of host media.example.com 503 This does not imply a standard way to reference streams in 504 URLs. The presentation description defines the hierarchical 505 relationships in the presentation and the URLs for the 506 individual streams. A presentation description may name a 507 stream 'a.mov' and the whole presentation 'b.mov'. 509 The path components of the RTSP URL are opaque to the client and do 510 not imply any particular file system structure for the server. 512 This decoupling also allows presentation descriptions to be 513 used with non-RTSP media control protocols, simply by 514 replacing the scheme in the URL. 516 3.3 Conference Identifiers 518 Conference identifiers are opaque to RTSP and are encoded using 519 standard URI encoding methods (i.e., LWS is escaped with %). They can 520 contain any octet value. The conference identifier MUST be globally 521 unique. For H.323, the conferenceID value is to be used. 523 conference-id = 1*OCTET ; LWS must be URL-escaped 525 Conference identifiers are used to allow to allow RTSP 526 sessions to obtain parameters from multimedia conferences 527 the media server is participating in. These conferences are 528 created by protocols outside the scope of this 529 specification, e.g., H.323 [17] or SIP [12]. Instead of the 530 RTSP client explicitly providing transport information, for 531 example, it asks the media server to use the values in the 532 conference description instead. If the conference 533 participant inviting the media server would only supply a 534 conference identifier which is unique for that inviting 535 party, the media server could add an internal identifier 536 for that party, e.g., its Internet address. However, this 537 would prevent that the conference participant and the 538 initiator of the RTSP commands are two different entities. 540 3.4 SMPTE Relative Timestamps 542 A SMPTE relative time-stamp expresses time relative to the start of 543 the clip. Relative timestamps are expressed as SMPTE time codes for 544 frame-level access accuracy. The time code has the format 545 hours:minutes:seconds.frames 546 , 547 with the origin at the start of the clip. For NTSC, the frame rate is 548 29.97 frames per second. This is handled by dropping the first frame 549 index of every minute, except every tenth minute. If the frame value 550 is zero, it may be omitted. 552 smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ] 553 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ] 555 Examples: 557 smpte=10:12:33.40- 558 smpte=10:7:33- 559 smpte=10:7:0-10:7:33 561 3.5 Normal Play Time 563 Normal play time (NPT) indicates the stream absolute position 564 relative to the beginning of the presentation, measured in seconds 565 and microseconds. The beginning of a presentation corresponds to 0 566 seconds and 0 microseconds. Negative values are not defined. The 567 microsecond field is always less than 1,000,000. NPT is defined as in 568 DSM-CC: "Intuitively, NPT is the clock the viewer associates with a 569 program. It is often digitally displayed on a VCR. NPT advances 570 normally when in normal play mode (scale = 1), advances at a faster 571 rate when in fast scan forward (high positive scale ratio), 572 decrements when in scan reverse (high negative scale ratio) and is 573 fixed in pause mode. NPT is [logically] equivalent to SMPTE time 574 codes." [18] 576 npt-range = "npt" "=" npt-time "-" [ npt-time ] 577 npt-time = 1*DIGIT [ ":" *DIGIT ] 579 Examples: 581 npt=123:45-125 583 3.6 Absolute Time 585 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 586 Fractions of a second may be indicated. 588 utc-range = "clock" "=" utc-time "-" [ utc-time ] 589 utc-time = utc-date "T" utc-time "Z" 590 utc-date = 8DIGIT ; < YYYYMMDD > 591 utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > 593 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 594 UTC: 596 19961108T143720.25Z 598 Example 600 4 RTSP Message 601 RTSP is a text-based protocol and uses the ISO 10646 character set in 602 UTF-8 encoding (RFC 2044). Lines are terminated by CRLF, but 603 receivers should be prepared to also interpret CR and LF by 604 themselves as line terminators. 606 Text-based protocols make it easier to add optional 607 parameters in a self-describing manner. Since the number of 608 parameters and the frequency of commands is low, processing 609 efficiency is not a concern. Text-based protocols, if done 610 carefully, also allow easy implementation of research 611 prototypes in scripting languages such as Tcl, Visual Basic 612 and Perl. 614 The 10646 character set avoids tricky character set switching, but is 615 invisible to the application as long as US-ASCII is being used. This 616 is also the encoding used for RTCP. ISO 8859-1 translates directly 617 into Unicode, with a high-order octet of zero. ISO 8859-1 characters 618 with the most-significant bit set are represented as 1100001x 619 10xxxxxx. 621 RTSP messages can be carried over any lower-layer transport protocol 622 that is 8-bit clean. 624 Requests contain methods, the object the method is operating upon and 625 parameters to further describe the method. Methods are idempotent, 626 unless otherwise noted. Methods are also designed to require little 627 or no state maintenance at the media server. 629 4.1 Message Types 631 See [H4.1] 633 4.2 Message Headers 635 See [H4.2] 637 4.3 Message Body 639 See [H4.3] 641 4.4 Message Length 643 When a message-body is included with a message, the length of that 644 body is determined by one of the following (in order of precedence): 646 1. Any response message which MUST NOT include a message-body 647 (such as the 1xx, 204, and 304 responses) is always 648 terminated by the first empty line after the header fields, 649 regardless of the entity-header fields present in the 650 message. (Note: An empty line consists of only CRLF.) 652 2. If a Content-Length header field (section 11.12) is 653 present, its value in bytes represents the length of the 654 message-body. If this header field is not present, a value 655 of zero is assumed. 657 3. By the server closing the connection. (Closing the 658 connection cannot be used to indicate the end of a request 659 body, since that would leave no possibility for the server 660 to send back a response.) 662 Note that RTSP does not (at present) support the HTTP/1.1 "chunked" 663 transfer coding and requires the presence of the Content-Length 664 header field. 666 Given the moderate length of presentation descriptions 667 returned, the server should always be able to determine its 668 length, even if it is generated dynamically, making the 669 chunked transfer encoding unnecessary. Even though 670 Content-Length must be present if there is any entity body, 671 the rules ensure reasonable behavior even if the length is 672 not given explicitly. 674 5 Request 676 A request message from a client to a server or vice versa includes, 677 within the first line of that message, the method to be applied to 678 the resource, the identifier of the resource, and the protocol 679 version in use. 681 Request = Request-line CRLF 682 *request-header 683 CRLF 684 [ message-body ] 686 Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF 688 Method = "DESCRIBE" ; Section 689 | "GET_PARAMETER" ; Section 690 | "OPTIONS" ; Section 691 | "PAUSE" ; Section 692 | "PLAY" ; Section 693 | "RECORD" ; Section 694 | "REDIRECT" ; Section 695 | "SETUP" ; Section 696 | "SET_PARAMETER" ; Section 697 | "TEARDOWN" ; Section 698 | extension-method 700 extension-method = token 702 Request-URI = "*" | absolute_URI 704 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 706 seq-no = 1*DIGIT 708 Note that in contrast to HTTP/1.1, RTSP requests always contain the 709 absolute URL (that is, including the scheme, host and port) rather 710 than just the absolute path. 712 The asterisk "*" in the Request-URI means that the request does not 713 apply to a particular resource, but to the server itself, and is only 714 allowed when the method used does not necessarily apply to a 715 resource. One example would be 717 OPTIONS * RTSP/1.0 719 6 Response 721 [H6] applies except that HTTP-Version is replaced by RTSP-Version 722 define some HTTP codes. The valid response codes and the methods they 723 can be used with are defined in the table 1. 725 After receiving and interpreting a request message, the recipient 726 responds with an RTSP response message. 728 Response = Status-Line ; Section 729 *( general-header ; Section 730 | response-header ; Section 731 | entity-header ) ; Section 732 CRLF 733 [ message-body ] ; Section 735 6.1 Status-Line 737 The first line of a Response message is the Status-Line , consisting 738 of the protocol version followed by a numeric status code, the 739 sequence number of the corresponding request and the textual phrase 740 associated with the status code, with each element separated by SP 741 characters. No CR or LF is allowed except in the final CRLF sequence. 742 Note that the addition of a 744 Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF 746 6.1.1 Status Code and Reason Phrase 748 The Status-Code element is a 3-digit integer result code of the 749 attempt to understand and satisfy the request. These codes are fully 750 defined in section10. The Reason-Phrase is intended to give a short 751 textual description of the Status-Code. The Status-Code is intended 752 for use by automata and the Reason-Phrase is intended for the human 753 user. The client is not required to examine or display the Reason- 754 Phrase 756 The first digit of the Status-Code defines the class of response. The 757 last two digits do not have any categorization role. There are 5 758 values for the first digit: 760 o 1xx: Informational - Request received, continuing process 762 o 2xx: Success - The action was successfully received, 763 understood, and accepted 765 o 3xx: Redirection - Further action must be taken in order to 766 complete the request 768 o 4xx: Client Error - The request contains bad syntax or cannot 769 be fulfilled 771 o 5xx: Server Error - The server failed to fulfill an apparently 772 valid request 774 The individual values of the numeric status codes defined for 775 RTSP/1.0, and an example set of corresponding Reason-Phrase below. 776 The reason phrases listed here are only recommended -- they may be 777 replaced by local equivalents without affecting the protocol. Note 778 that RTSP adopts most HTTP/1.1 status codes and adds RTSP-specific 779 status codes in the starting at 450 to avoid conflicts with newly 780 defined HTTP status codes. 782 Status-Code = "100" ; Continue 783 | "200" ; OK 784 | "201" ; Created 785 | "300" ; Multiple Choices 786 | "301" ; Moved Permanently 787 | "302" ; Moved Temporarily 788 | "303" ; See Other 789 | "304" ; Not Modified 790 | "305" ; Use Proxy 791 | "400" ; Bad Request 792 | "401" ; Unauthorized 793 | "402" ; Payment Required 794 | "403" ; Forbidden 795 | "404" ; Not Found 796 | "405" ; Method Not Allowed 797 | "406" ; Not Acceptable 798 | "407" ; Proxy Authentication Required 799 | "408" ; Request Time-out 800 | "409" ; Conflict 801 | "410" ; Gone 802 | "411" ; Length Required 803 | "412" ; Precondition Failed 804 | "413" ; Request Entity Too Large 805 | "414" ; Request-URI Too Large 806 | "415" ; Unsupported Media Type 807 | "451" ; Parameter Not Understood 808 | "452" ; Conference Not Found 809 | "453" ; Not Enough Bandwidth 810 | "45x" ; Session Not Found 811 | "45x" ; Method Not Valid in This State 812 | "45x" ; Header Field Not Valid for Resource 813 | "45x" ; Invalid Range 814 | "45x" ; Parameter Is Read-Only 815 | "500" ; Internal Server Error 816 | "501" ; Not Implemented 817 | "502" ; Bad Gateway 818 | "503" ; Service Unavailable 819 | "504" ; Gateway Time-out 820 | "505" ; HTTP Version not supported 821 | extension-code 823 extension-code = 3DIGIT 825 Reason-Phrase = * 827 RTSP status codes are extensible. RTSP applications are not required 828 to understand the meaning of all registered status codes, though such 829 understanding is obviously desirable. However, applications MUST 830 understand the class of any status code, as indicated by the first 831 digit, and treat any unrecognized response as being equivalent to the 832 x00 status code of that class, with the exception that an 833 unrecognized response MUST NOT be cached. For example, if an 834 unrecognized status code of 431 is received by the client, it can 835 safely assume that there was something wrong with its request and 836 treat the response as if it had received a 400 status code. In such 837 cases, user agents SHOULD present to the user the entity returned 838 with the response, since that entity is likely to include human- 839 readable information which will explain the unusual status. 841 6.1.2 Response Header Fields 843 The response-header fields allow the request recipient to pass 844 additional information about the response which cannot be placed in 845 the Status-Line server and about further access to the resource 846 identified by the Request-URI 848 response-header = Location ; Section 849 | Proxy-Authenticate ; Section 850 | Public ; Section 851 | Retry-After ; Section 852 | Server ; Section 853 | Vary ; Section 854 | WWW-Authenticate ; Section 856 Response-header field names can be extended reliably only in 857 combination with a change in the protocol version. However, new or 858 experimental header fields MAY be given the semantics of response- 859 header fields if all parties in the communication recognize them to 860 be response-header fields. Unrecognized header fields are treated as 861 entity-header fields. 863 7 Entity 865 Request and Response messages MAY transfer an entity if not otherwise 866 restricted by the request method or response status code. An entity 867 consists of entity-header fields and an entity-body, although some 868 responses will only include the entity-headers. 870 In this section, both sender and recipient refer to either the client 871 Code reason 872 _______________________________________________________________ 873 100 Continue all 875 _______________________________________________________________ 876 200 OK all 877 201 Created RECORD 878 _______________________________________________________________ 879 300 Multiple Choices all 880 301 Moved Permanently all 881 302 Moved Temporarily all 882 303 See Other all 883 305 Use Proxy all 885 _______________________________________________________________ 886 400 Bad Request all 887 401 Unauthorized all 888 402 Payment Required all 889 403 Forbidden all 890 404 Not Found all 891 405 Method Not Allowed all 892 406 Not Acceptable all 893 407 Proxy Authentication Required all 894 408 Request Timeout all 895 409 Conflict 896 410 Gone all 897 411 Length Required SETUP 898 412 Precondition Failed 899 413 Request Entity Too Large SETUP 900 414 Request-URI Too Long all 901 415 Unsupported Media Type SETUP 902 45x Only Valid for Stream SETUP 903 45x Invalid parameter SETUP 904 45x Not Enough Bandwidth SETUP 905 45x Illegal Conference Identifier SETUP 906 45x Illegal Session Identifier PLAY, RECORD, TEARDOWN 907 45x Parameter Is Read-Only SET_PARAMETER 908 45x Header Field Not Valid all 909 _______________________________________________________________ 910 500 Internal Server Error all 911 501 Not Implemented all 912 502 Bad Gateway all 913 503 Service Unavailable all 914 504 Gateway Timeout all 915 505 RTSP Version Not Supported all 917 Table 1: Status codes and their usage with RTSP methods 918 or the server, depending on who sends and who receives the entity. 920 7.1 Entity Header Fields 922 Entity-header fields define optional metainformation about the 923 entity-body or, if no body is present, about the resource identified 924 by the request. 926 entity-header = Allow ; Section 14.7 927 | Content-Encoding ; Section 14.12 928 | Content-Language ; Section 14.13 929 | Content-Length ; Section 14.14 930 | Content-Type ; Section 14.18 931 | Expires ; Section 14.21 932 | Last-Modified ; Section 14.29 933 | extension-header 935 extension-header = message-header 937 The extension-header mechanism allows additional entity-header fields 938 to be defined without changing the protocol, but these fields cannot 939 be assumed to be recognizable by the recipient. Unrecognized header 940 fields SHOULD be ignored by the recipient and forwarded by proxies. 942 7.2 Entity Body 944 See [H7.2] 946 8 Connections 948 RTSP requests can be transmitted in several different ways: 950 o persistent transport connections used for several request- 951 response transactions; 953 o one connection per request/response transaction; 955 o connectionless mode. 957 The type of transport connection is defined by the RTSP URI (Section 958 3.2). For the scheme "rtsp", a persistent connection is assumed, 959 while the scheme "rtspu" calls for RTSP requests to be send without 960 setting up a connection. 962 Unlike HTTP, RTSP allows the media server to send requests to the 963 media client. However, this is only supported for persistent 964 connections, as the media server otherwise has no reliable way of 965 reaching the client. Also, this is the only way that requests from 966 media server to client are likely to traverse firewalls. 968 8.1 Pipelining 970 A client that supports persistent connections or connectionless mode 971 MAY "pipeline" its requests (i.e., send multiple requests without 972 waiting for each response). A server MUST send its responses to those 973 requests in the same order that the requests were received. 975 8.2 Reliability and Acknowledgements 977 Requests are acknowledged by the receiver unless they are sent to a 978 multicast group. If there is no acknowledgement, the sender may 979 resend the same message after a timeout of one round-trip time (RTT). 980 The round-trip time is estimated as in TCP (RFC TBD), with an initial 981 round-trip value of 500 ms. An implementation MAY cache the last RTT 982 measurement as the initial value for future connections. If a 983 reliable transport protocol is used to carry RTSP, the timeout value 984 MAY be set to an arbitrarily large value. 986 This can greatly increase responsiveness for proxies 987 operating in local-area networks with small RTTs. The 988 mechanism is defined such that the client implementation 989 does not have be aware of whether a reliable or unreliable 990 transport protocol is being used. It is probably a bad idea 991 to have two reliability mechanisms on top of each other, 992 although the RTSP RTT estimate is likely to be larger than 993 the TCP estimate. 995 Each request carries a sequence number, which is incremented by one 996 for each request transmitted. If a request is repeated because of 997 lack of acknowledgement, the sequence number is incremented. 999 This avoids ambiguities when computing round-trip time 1000 estimates. [TBD: An initial sequence number negotiation 1001 needs to be added for UDP; otherwise, a new stream 1002 connection may see a request be acknowledged by a delayed 1003 response from an earlier "connection". This handshake can 1004 be avoided with a sequence number containing a timestamp of 1005 sufficiently high resolution.] 1007 The reliability mechanism described here does not protect against 1008 reordering. This may cause problems in some instances. For example, a 1009 TEARDOWN followed by a PLAY has quite a different effect than the 1010 reverse. Similarly, if a PLAY request arrives before all parameters 1011 are set due to reordering, the media server would have to issue an 1012 error indication. Since sequence numbers for retransmissions are 1013 incremented (to allow easy RTT estimation), the receiver cannot just 1014 ignore out-of-order packets. [TBD: This problem could be fixed by 1015 including both a sequence number that stays the same for 1016 retransmissions and a timestamp for RTT estimation.] 1018 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1019 support UDP. The default port for the RTSP server is 554 for both UDP 1020 and TCP. 1022 A number of RTSP packets destined for the same control end point may 1023 be packed into a single lower-layer PDU or encapsulated into a TCP 1024 stream. RTSP data MAY be interleaved with RTP and RTCP packets. 1025 Unlike HTTP, an RTSP method header MUST contain a Content-Length 1026 whenever that method contains a payload. Otherwise, an RTSP packet is 1027 terminated with an empty line immediately following the method 1028 header. 1030 9 Method Definitions 1032 The method token indicates the method to be performed on the resource 1033 identified by the Request-URI case-sensitive. New methods may be 1034 defined in the future. Method names may not start with a $ character 1035 (decimal 24) and must be a token 1037 method direction object requirement 1038 ________________________________________________________ 1039 DESCRIBE C -> S, S -> C P,S recommended 1040 GET_PARAMETER C -> S, S -> C P,S optional 1041 OPTIONS C -> S P,S required 1042 PAUSE C -> S P,S recommended 1043 PLAY C -> S P,S required 1044 RECORD C -> S P,S optional 1045 REDIRECT S -> C P,S optional 1046 SETUP C -> S S required 1047 SET_PARAMETER C -> S, S -> C P,S optional 1048 TEARDOWN C -> S P,S required 1050 Table 2: Overview of RTSP methods, their direction, and what objects 1051 (P: presentation, S: stream) they operate on 1053 Notes on Table 2: PAUSE is recommend, but not required in that a 1054 fully functional server can be built that does not support this 1055 method, for example, for live feeds. If a server does not support a 1056 particular method, it MUST return "501 Not Implemented" and a client 1057 SHOULD not try this method again for this server. 1059 9.1 OPTIONS 1061 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1062 request may be issued at any time, e.g., if the client is about to 1063 try a non-standard request. It does not influence server state. 1065 In addition, if the optional Require header is present, option tags 1066 within the header indicate features needed by the requestor that are 1067 not required at the version level of the protocol. 1069 Example 1: 1071 C->S: OPTIONS * RTSP/1.0 1 1072 Require: implicit-play, record-feature 1073 Transport-Require: switch-to-udp-control, gzipped-messages 1075 Note that these are fictional features (though we may want to make 1076 them real one day). 1078 Example 2 (using RFC2069-style authentication only as an example): 1080 S->C: OPTIONS * RTSP/1.0 1 1081 Authenticate: Digest realm="testrealm@host.com", 1082 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 1083 opaque="5ccc069c403ebaf9f0171e9517f40e41" 1085 S->C: RTSP/1.0 200 1 OK 1086 Date: 23 Jan 1997 15:35:06 GMT 1087 Nack-Transport-Require: switch-to-udp-control 1089 Note that these are fictional features (though we may want to make 1090 them real one day). 1092 Example 2 (using RFC2069-style authentication only as an example): 1094 C->S: RTSP/1.0 401 1 Unauthorized 1095 Authorization: Digest username="Mufasa", 1096 realm="testrealm@host.com", 1097 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 1098 uri="/dir/index.html", 1099 response="e966c932a9242554e42c8ee200cec7f6", 1100 opaque="5ccc069c403ebaf9f0171e9517f40e41" 1102 9.2 DESCRIBE 1104 The DESCRIBE method retrieves the description of a presentation or 1105 media object identified by the request URL from a server. It may use 1106 the Accept header to specify the description formats that the client 1107 understands. The server responds with a description of the requested 1108 resource. Alternatively, the server may "push" a new description to 1109 the client, for example, if a new stream has become available. If a 1110 new media stream is added to a presentation (e.g., during a live 1111 presentation), the whole presentation description should be sent 1112 again, rather than just the additional components, so that components 1113 can be deleted. 1115 Example: 1117 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 312 1118 Accept: application/sdp, application/rtsl, application/mheg 1120 S->C: RTSP/1.0 200 312 OK 1121 Date: 23 Jan 1997 15:35:06 GMT 1122 Content-Type: application/sdp 1123 Content-Length: 376 1125 v=0 1126 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1127 s=SDP Seminar 1128 i=A Seminar on the session description protocol 1129 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1130 e=mjh@isi.edu (Mark Handley) 1131 c=IN IP4 224.2.17.12/127 1132 t=2873397496 2873404696 1133 a=recvonly 1134 m=audio 3456 RTP/AVP 0 1135 m=video 2232 RTP/AVP 31 1136 m=whiteboard 32416 UDP WB 1137 a=orient:portrait 1139 or 1141 S->C: RTSP/1.0 200 312 OK 1142 Date: 23 Jan 1997 15:35:06 GMT 1143 Content-Type: application/rtsl 1144 Content-Length: 2782 1146 <2782 octets of data containing stream description> 1148 Server to client example: 1150 S->C: DESCRIBE /twister RTSP/1.0 902 1151 Session: 1234 1152 Content-Type: application/rtsl 1154 new RTSL presentation description 1156 9.3 SETUP 1158 The SETUP request for a URI specifies the transport mechanism to be 1159 used for the streamed media. A client can issue a SETUP request for 1160 a stream that is already playing to change transport parameters. For 1161 the benefit of any intervening firewalls, a client must indicate the 1162 transport parameters even if it has no influence over these 1163 parameters, for example, where the server advertises a fixed 1164 multicast address. 1166 This avoids having firewall to parse numerous different 1167 presentation description formats, for information which is 1168 irrelevant. 1170 If the optional Require header is present, option tags within the 1171 header indicate features needed by the requestor that are not 1172 required at the version level of the protocol. The Transport-Require 1173 header is used to indicate proxy-sensitive features that MUST be 1174 stripped by the proxy to the server if not supported. Furthermore, 1175 any Transport-Require header features that are not supported by the 1176 proxy MUST be negatively acknowledged by the proxy to the client if 1177 not supported. 1179 HS: In my opinion, the Require header should be replaced by 1180 PEP since PEP is standards-track, has more functionality 1181 and somebody already did the work. 1183 The Transport header specifies the transport parameters acceptable 1184 to the client for data transmission; the response will contain the 1185 transport parameters selected by the server. 1187 C->S: SETUP foo/bar/baz.rm RTSP/1.0 302 1188 Transport: rtp/udp;port=458 1190 S->C: RTSP/1.0 200 302 OK 1191 Date: 23 Jan 1997 15:35:06 GMT 1192 Transport: cush/udp;port=458 1194 9.4 PLAY 1196 The PLAY method tells the server to start sending data via the 1197 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 1198 until any outstanding SETUP requests have been acknowledged as 1199 successful. 1201 The PLAY request positions the normal play time to the beginning of 1202 the range specified and delivers stream data until the end of the 1203 range is reached. PLAY requests may be pipelined (queued); a server 1204 MUST queue PLAY requests to be executed in order. That is, a PLAY 1205 request arriving while a previous PLAY request is still active is 1206 delayed until the first has been completed. 1208 This allows precise editing. For example, regardless of 1209 how closely spaced the two PLAY commands in the example 1210 below arrive, the server will play first second 10 through 1211 15 and then, immediately following, seconds 20 to 25 and 1212 finally seconds 30 through the end. 1214 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 835 1215 Range: npt=10-15 1217 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 836 1218 Range: npt=20-25 1220 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 837 1221 Range: npt=30- 1223 See the description of the PAUSE request for further examples. 1225 A PLAY request without a Range header is legal. It starts playing a 1226 stream from the beginning unless the stream has been paused. If a 1227 stream has been paused via PAUSE, stream delivery resumes at the 1228 pause point. If a stream is playing, such a PLAY request causes no 1229 further action and can be used by the client to test server liveness. 1231 The Range header may also contain a time parameter. This parameter 1232 specifies a time in UTC at which the playback should start. If the 1233 message is received after the specified time, playback is started 1234 immediately. The time parameter may be used to aid in 1235 synchronisation of streams obtained from different sources. 1237 For a on-demand stream, the server replies back with the actual range 1238 that will be played back. This may differ from the requested range if 1239 alignment of the requested range to valid frame boundaries is 1240 required for the media source. If no range is specified in the 1241 request, the current position is returned in the reply. The unit of 1242 the range in the reply is the same as that in the request. 1244 After playing the desired range, the presentation is automatically 1245 paused, as if a PAUSE request had been issued. 1247 The following example plays the whole presentation starting at SMPTE 1248 time code 0:10:20 until the end of the clip. The playback is to start 1249 at 15:36 on 23 Jan 1997. 1251 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833 1252 Range: smpte=0:10:20-;time=19970123T153600Z 1254 S->C: RTSP/1.0 200 833 OK 1255 Date: 23 Jan 1997 15:35:06 GMT 1256 Range: smpte=0:10:22-;time=19970123T153600Z 1258 For playing back a recording of a live presentation, it may be 1259 desirable to use clock units: 1261 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835 1262 Range: clock=19961108T142300Z-19961108T143520Z 1264 S->C: RTSP/1.0 200 833 OK 1265 Date: 23 Jan 1997 15:35:06 GMT 1267 A media server only supporting playback MUST support the smpte format 1268 and MAY support the clock format. 1270 9.5 PAUSE 1271 The PAUSE request causes the stream delivery to be interrupted 1272 (halted) temporarily. If the request URL names a stream, only 1273 playback and recording of that stream is halted. For example, for 1274 audio, this is equivalent to muting. If the request URL names a 1275 presentation or group of streams, delivery of all currently active 1276 streams within the presentation or group is halted. After resuming 1277 playback or recording, synchronization of the tracks MUST be 1278 maintained. Any server resources are kept. 1280 The PAUSE request may contain a Range header specifying when the 1281 stream or presentation is to be halted. The header must contain 1282 exactly one value rather than a time range. The normal play time for 1283 the stream is set to that value. The pause request becomes effective 1284 the first time the server is encountering the time point specified. 1285 If this header is missing, stream delivery is interrupted immediately 1286 on receipt of the message. 1288 For example, if the server has play requests for ranges 10 to 15 and 1289 20 to 29 pending and then receives a pause request for NPT 21, it 1290 would start playing the second range and stop at NPT 21. If the pause 1291 request is for NPT 12 and the server is playing at NPT 13 serving the 1292 first play request, it stops immediately. If the pause request is for 1293 NPT 16, it stops after completing the first play request and discards 1294 the second play request. 1296 As another example, if a server has received requests to play ranges 1297 10 to 15 and then 13 to 20, that is, overlapping ranges, the PAUSE 1298 request for NPT=14 would take effect while playing the first range, 1299 with the second PLAY request effectively being ignored, assuming the 1300 PAUSE request arrives before the server has started playing the 1301 second, overlapping range. Regardless of when the PAUSE request 1302 arrives, it sets the NPT to 14. 1304 If the server has already sent data beyond the time specified in the 1305 Range header, a PLAY would still resume at that point in time, as it 1306 is assumed that the client has discarded data after that point. This 1307 ensures continuous pause/play cycling without gaps. 1309 Example: 1311 C->S: PAUSE /fizzle/foo RTSP/1.0 834 1313 S->C: RTSP/1.0 200 834 OK 1314 Date: 23 Jan 1997 15:35:06 GMT 1316 9.6 TEARDOWN 1318 Stop the stream delivery for the given URI, freeing the resources 1319 associated with it. If the URI is the root node for this 1320 presentation, any RTSP session identifier associated with the session 1321 is no longer valid. Unless all transport parameters are defined by 1322 the session description, a SETUP request has to be issued before the 1323 session can be played again. 1325 Example: 1327 C->S: TEARDOWN /fizzle/foo RTSP/1.0 892 1329 S->C: RTSP/1.0 200 892 OK 1331 9.7 GET_PARAMETER 1333 The requests retrieves the value of a parameter of a presentation or 1334 stream specified in the URI. Multiple parameters can be requested in 1335 the message body using the content type text/rtsp-parameters Note 1336 that parameters include server and client statistics. IANA registers 1337 parameter names for statistics and other purposes. GET_PARAMETER with 1338 no entity body may be used to test client or server liveness 1339 ("ping"). 1341 Example: 1343 S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431 1344 Content-Type: text/rtsp-parameters 1345 Session: 1234 1346 Content-Length: 15 1348 packets_received 1349 jitter 1351 C->S: RTSP/1.0 200 431 OK 1352 Content-Length: 46 1353 Content-Type: text/rtsp-parameters 1355 packets_received: 10 1356 jitter: 0.3838 1358 9.8 SET_PARAMETER 1360 This method requests to set the value of a parameter for a 1361 presentation or stream specified by the URI. 1363 A request SHOULD only contain a single parameter to allow the client 1364 to determine why a particular request failed. A server MUST allow a 1365 parameter to be set repeatedly to the same value, but it MAY disallow 1366 changing parameter values. 1368 Note: transport parameters for the media stream MUST only be set with 1369 the SETUP command. 1371 Restricting setting transport parameters to SETUP is for 1372 the benefit of firewalls. 1374 The parameters are split in a fine-grained fashion so that 1375 there can be more meaningful error indications. However, it 1376 may make sense to allow the setting of several parameters 1377 if an atomic setting is desirable. Imagine device control 1378 where the client does not want the camera to pan unless it 1379 can also tilt to the right angle at the same time. 1381 A SET_PARAMETER request without parameters can be used as a way to 1382 detect client or server liveness. 1384 Example: 1386 C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421 1387 Content-type: text/rtsp-parameters 1389 fooparam: foostuff 1390 barparam: barstuff 1392 S->C: RTSP/1.0 450 421 Invalid Parameter 1393 Content-Length: 6 1395 barparam 1397 9.9 REDIRECT 1399 A redirect request informs the client that it must connect to another 1400 server location. It contains the mandatory header Location, which 1401 indicates that the client should issue a DESCRIBE for that URL. It 1402 may contain the parameter Range, which indicates when the 1403 redirection takes effect. 1405 This example request redirects traffic for this URI to the new server 1406 at the given play time: 1408 S->C: REDIRECT /fizzle/foo RTSP/1.0 732 1409 Location: rtsp://bigserver.com:8001 1410 Range: clock=19960213T143205Z- 1412 9.10 RECORD 1414 This method initiates recording a range of media data according to 1415 the presentation description. The timestamp reflects start and end 1416 time (UTC). If no time range is given, use the start or end time 1417 provided in the presentation description. If the session has already 1418 started, commence recording immediately. The Conference header is 1419 mandatory. 1421 The server decides whether to store the recorded data under the 1422 request-URI or another URI. If the server does not use the request- 1423 URI, the response SHOULD be 201 (Created) and contain an entity which 1424 describes the status of the request and refers to the new resource, 1425 and a Location header. 1427 A media server supporting recording of live presentations MUST 1428 support the clock range format; the smpte format does not make sense. 1430 In this example, the media server was previously invited to the 1431 conference indicated. 1433 C->S: RECORD /meeting/audio.en RTSP/1.0 954 1434 Session: 1234 1435 Conference: 128.16.64.19/32492374 1437 9.11 Embedded Binary Data 1439 Binary packets such as RTP data are encapsulated by an ASCII dollar 1440 sign (24 decimal), followed by a one-byte session identifier, 1441 followed by the length of the encapsulated binary data as a binary, 1442 two-byte integer in network byte order. The binary data follows 1443 immediately afterwards, without a CRLF. 1445 10 Status Code Definitions 1447 Where applicable, HTTP status [H10] codes are re-used. Status codes 1448 that have the same meaning are not repeated here. See Table 1 for a 1449 listing of which status codes may be returned by which request. 1451 10.1 Redirection 3xx 1453 See [H10.3]. 1455 Within RTSP, redirection may be used for load balancing or 1456 redirecting stream requests to a server topologically closer to the 1457 client. Mechanisms to determine topological proximity are beyond the 1458 scope of this specification. 1460 10.2 Client Error 4xx 1462 10.2.1 451 Parameter Not Understood 1464 The recipient of the request does not support one or more parameters 1465 contained in the request. 1467 10.2.2 452 Conference Not Found 1469 The conference indicated by a Conference header field is unknown to 1470 the media server. 1472 10.2.3 453 Not Enough Bandwidth 1474 The request was refused since there was insufficient bandwidth. This 1475 may, for example, be the result of a resource reservation failure. 1477 10.2.4 45x Session Not Found 1479 The RTSP session identifier is invalid or has timed out. 1481 10.2.5 45x Method Not Valid in This State 1483 The client or server cannot process this request in its current 1484 state. 1486 10.2.6 45x Header Field Not Valid for Resource 1488 The server could not act on a required request header. For example, 1489 if PLAY contains the Range header field, but the stream does not 1490 allow seeking. 1492 10.2.7 45x Invalid Range 1493 The Range value given is out of bounds, e.g., beyond the end of the 1494 presentation. 1496 10.2.8 45x Parameter Is Read-Only 1498 The parameter to be set by SET_PARAMETER can only be read, but not 1499 modified. 1501 11 Header Field Definitions 1503 HTTP/1.1 or other, non-standard header fields not listed here 1504 currently have no well-defined meaning and SHOULD be ignored by the 1505 recipient. 1507 Tables 3 summarizes the header fields used by RTSP. Type "R" 1508 designates request headers, type "r" response headers. Fields marked 1509 with "req." in the column labeled "support" MUST be implemented by 1510 the recipient for a particular method, while fields marked "opt." are 1511 optional. Note that not all fields marked 'r' will be send in every 1512 request of this type; merely, that client (for response headers) and 1513 server (for request headers) MUST implement them. The last column 1514 lists the method for which this header field is meaningful; the 1515 designation "entity" refers to all methods that return a message 1516 body. Within this specification, DESCRIBE and GET_PARAMETER fall 1517 into this class. 1519 If the field content does not apply to the particular resource, the 1520 server MUST return status 45x (Header Field Not Valid for Resource). 1522 11.1 Accept 1524 The Accept request-header field can be used to specify certain 1525 presentation description content types which are acceptable for the 1526 response. 1528 The "level" parameter for presentation descriptions is 1529 properly defined as part of the MIME type registration, not 1530 here. 1532 See [H14.1] for syntax. 1534 Example of use: 1536 Accept: application/rtsl, application/sdp;level=2 1537 Header type support methods 1538 _________________________________________________________________ 1539 Accept R opt. entity 1540 Accept-Encoding R opt. entity 1541 Accept-Language R opt. all 1542 Authorization R opt. all 1543 Bandwidth R opt. SETUP 1544 Blocksize R opt. all but OPTIONS, TEARDOWN 1545 Cache-Control Rr opt. SETUP 1546 Conference R opt. SETUP 1547 Connection Rr req. all 1548 Content-Encoding R req. SET_PARAMETER 1549 Content-Encoding r req. DESCRIBE 1550 Content-Length R req. SET_PARAMETER 1551 Content-Length r req. entity 1552 Content-Type R req. SET_PARAMETER 1553 Content-Type r req. entity 1554 Date Rr opt. all 1555 Expires r opt. DESCRIBE 1556 If-Modified-Since R opt. DESCRIBE, SETUP 1557 Last-Modified r opt. entity 1558 Public r opt. all 1559 Range R opt. PLAY, PAUSE, RECORD 1560 Range r opt. PLAY, PAUSE, RECORD 1561 Referer R opt. all 1562 Require R req. all 1563 Retry-After r opt. all 1564 Scale Rr opt. PLAY, RECORD 1565 Session Rr req. all but SETUP, OPTIONS 1566 Server r opt. all 1567 Speed Rr opt. PLAY 1568 Transport Rr req. SETUP 1569 Transport-Require R xeq. all 1570 User-Agent R opt. all 1571 Via Rr opt. all 1572 WWW-Authenticate r opt. all 1574 Table 3: Overview of RTSP header fields 1576 11.2 Accept-Encoding 1578 See [H14.3] 1580 11.3 Accept-Language 1582 See [H14.4]. Note that the language specified applies to the 1583 presentation description and any reason phrases, not the media 1584 content. 1586 11.4 Allow 1588 The Allow response header field lists the methods supported by the 1589 resource identified by the request-URI. The purpose of this field is 1590 to strictly inform the recipient of valid methods associated with the 1591 resource. An Allow header field must be present in a 405 (Method not 1592 allowed) response. 1594 Example of use: 1596 Allow: SETUP, PLAY, RECORD, SET_PARAMETER 1598 11.5 Authorization 1600 See [H14.8] 1602 11.6 Bandwidth 1604 The Bandwidth request header field describes the estimated bandwidth 1605 available to the client, expressed as a positive integer and measured 1606 in bits per second. 1608 Bandwidth = "Bandwidth" ":" 1*DIGIT 1610 Example: 1612 Bandwidth: 4000 1614 11.7 Blocksize 1616 This request header field is sent from the client to the media server 1617 asking the server for a particular media packet size. This packet 1618 size does not include lower-layer headers such as IP, UDP, or RTP. 1619 The server is free to use a blocksize which is lower than the one 1620 requested. The server MAY truncate this packet size to the closest 1621 multiple of the minimum media-specific block size or overrides it 1622 with the media specific size if necessary. The block size is a 1623 strictly positive decimal number and measured in octets. The server 1624 only returns an error (416) if the value is syntactically invalid. 1626 11.8 Cache-Control 1628 The Cache-Control general header field is used to specify directives 1629 that MUST be obeyed by all caching mechanisms along the 1630 request/response chain. 1632 Cache directives must be passed through by a proxy or gateway 1633 application, regardless of their significance to that application, 1634 since the directives may be applicable to all recipients along the 1635 request/response chain. It is not possible to specify a cache- 1636 directive for a specific cache. 1638 Cache-Control should only be specified in a SETUP request and its 1639 response. Note: Cache-Control does not govern the caching of 1640 responses as for HTTP, but rather of the stream identified by the 1641 SETUP request. Responses to RTSP requests are not cacheable. 1643 [HS: Should there be an exception for DESCRIBE?] 1645 Cache-Control = "Cache-Control" ":" 1#cache-directive 1647 cache-directive = cache-request-directive 1648 | cache-response-directive 1650 cache-request-directive = 1651 "no-cache" 1652 | "max-stale" 1653 | "min-fresh" 1654 | "only-if-cached" 1655 | cache-extension 1657 cache-response-directive = 1658 "public" 1659 | "private" 1660 | "no-cache" 1661 | "no-transform" 1662 | "must-revalidate" 1663 | "proxy-revalidate" 1664 | "max-age" "=" delta-seconds 1665 | cache-extension 1667 cache-extension = token [ "=" ( token | quoted-string ) ] 1669 no-cache: Indicates that the media stream MUST NOT be cached 1670 anywhere. This allows an origin server to prevent caching even 1671 by caches that have been configured to return stale responses to 1672 client requests. 1674 public: Indicates that the media stream is cachable by any cache. 1676 private: Indicates that the media stream is intended for a single 1677 user and MUST NOT be cached by a shared cache. A private (non- 1678 shared) cache may cache the media stream. 1680 no-transform: An intermediate cache (proxy) may find it useful to 1681 convert the media type of certain stream. A proxy might, for 1682 example, convert between video formats to save cache space or to 1683 reduce the amount of traffic on a slow link. Serious operational 1684 problems may occur, however, when these transformations have 1685 been applied to streams intended for certain kinds of 1686 applications. For example, applications for medical imaging, 1687 scientific data analysis and those using end-to-end 1688 authentication, all depend on receiving a stream that is bit for 1689 bit identical to the original entity-body. Therefore, if a 1690 response includes the no-transform directive, an intermediate 1691 cache or proxy MUST NOT change the encoding of the stream. 1692 Unlike HTTP, RTSP does not provide for partial transformation at 1693 this point, e.g., allowing translation into a different 1694 language. 1696 only-if-cached: In some cases, such as times of extremely poor 1697 network connectivity, a client may want a cache to return only 1698 those media streams that it currently has stored, and not to 1699 receive these from the origin server. To do this, the client may 1700 include the only-if-cached directive in a request. If it 1701 receives this directive, a cache SHOULD either respond using a 1702 cached media stream that is consistent with the other 1703 constraints of the request, or respond with a 504 (Gateway 1704 Timeout) status. However, if a group of caches is being operated 1705 as a unified system with good internal connectivity, such a 1706 request MAY be forwarded within that group of caches. 1708 max-stale: Indicates that the client is willing to accept a media 1709 stream that has exceeded its expiration time. If max-stale is 1710 assigned a value, then the client is willing to accept a 1711 response that has exceeded its expiration time by no more than 1712 the specified number of seconds. If no value is assigned to 1713 max-stale, then the client is willing to accept a stale response 1714 of any age. 1716 min-fresh: Indicates that the client is willing to accept a media 1717 stream whose freshness lifetime is no less than its current age 1718 plus the specified time in seconds. That is, the client wants a 1719 response that will still be fresh for at least the specified 1720 number of seconds. 1722 must-revalidate: When the must-revalidate directive is present in a 1723 SETUP response received by a cache, that cache MUST NOT use the 1724 entry after it becomes stale to respond to a subsequent request 1725 without first revalidating it with the origin server. (I.e., the 1726 cache must do an end-to-end revalidation every time, if, based 1727 solely on the origin server's Expires, the cached response is 1728 stale.) 1730 11.9 Conference 1732 This request header field establishes a logical connection between a 1733 conference, established using non-RTSP means, and an RTSP stream. The 1734 conference-id must not be changed for the same RTSP session. 1736 Conference = "Conference" ":" conference-id 1738 Example: 1740 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu 1742 11.10 Connection 1744 See [H14.10]. 1746 11.11 Content-Encoding 1748 See [H14.12] 1750 11.12 Content-Length 1752 This field contains the length of the content of the method (i.e. 1753 after the double CRLF following the last header). Unlike HTTP, it 1754 MUST be included in all messages that carry content beyond the header 1755 portion of the message. It is interpreted according to [H14.14]. 1757 11.13 Content-Type 1759 See [H14.18]. Note that the content types suitable for RTSP are 1760 likely to be restricted in practice to presentation descriptions and 1761 parameter-value types. 1763 11.14 Date 1765 See [H14.19]. 1767 11.15 Expires 1769 The Expires entity-header field gives the date/time after which the 1770 media-stream should be considered stale. A stale cache entry may not 1771 normally be returned by a cache (either a proxy cache or an user 1772 agent cache) unless it is first validated with the origin server (or 1773 with an intermediate cache that has a fresh copy of the entity). See 1774 section 13.2 for further discussion of the expiration model. 1776 The presence of an Expires field does not imply that the original 1777 resource will change or cease to exist at, before, or after that 1778 time. 1780 The format is an absolute date and time as defined by HTTP-date in 1781 [H3.3]; it MUST be in RFC1123-date format: 1783 Expires = "Expires" ":" HTTP-date 1785 An example of its use is 1787 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1789 RTSP/1.0 clients and caches MUST treat other invalid date formats, 1790 especially including the value "0", as in the past (i.e., "already 1791 expired"). 1793 To mark a response as "already expired," an origin server should use 1794 an Expires date that is equal to the Date header value. 1796 To mark a response as "never expires," an origin server should use an 1797 Expires date approximately one year from the time the response is 1798 sent. RTSP/1.0 servers should not send Expires dates more than one 1799 year in the future. 1801 The presence of an Expires header field with a date value of some 1802 time in the future on a media stream that otherwise would by default 1803 be non-cacheable indicates that the media stream is cachable, unless 1804 indicated otherwise by a Cache-Control header field (Section 11.8. 1806 11.16 If-Modified-Since 1808 The If-Modified-Since request-header field is used with the DESCRIBE 1809 and SETUP methods to make them conditional: if the requested variant 1810 has not been modified since the time specified in this field, a 1811 description will not be returned from the server ( DESCRIBE) or a 1812 stream will not be setup ( SETUP); instead, a 304 (not modified) 1813 response will be returned without any message-body. 1815 If-Modified-Since = "If-Modified-Since" ":" HTTP-date 1817 An example of the field is: 1819 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1821 11.17 Last-modified 1823 The Last-Modified entity-header field indicates the date and time at 1824 which the origin server believes the variant was last modified. See 1825 [H14.29]. If the request URI refers to an aggregate, the field 1826 indicates the last modification time across all leave nodes of that 1827 aggregate. 1829 11.18 Location 1831 See [H14.30]. 1833 11.19 Nack-Transport-Require 1835 Negative acknowledgement of features not supported by the server. If 1836 there is a proxy on the path between the client and the server, the 1837 proxy MUST insert a message reply with an error message 506 (Feature 1838 not supported). 1840 HS: Same caveat as for Require applies. 1842 11.20 Range 1844 This request header field specifies a range of time. The range can be 1845 specified in a number of units. This specification defines the smpte 1846 (see Section 3.4) and clock (see Section 3.6) range units. Within 1847 RTSP, byte ranges [H14.36.1] are not meaningful and MUST NOT be used. 1848 The header may also contain a time parameter in UTC, specifying the 1849 time at which the operation is to be made effective. 1851 Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ] 1853 ranges-specifier = npt-range | utc-range | smpte-range 1855 Example: 1857 Range: clock=19960213T143205Z-;Time=19970123T143720Z 1859 The notation is similar to that used for the HTTP/1.1 1860 header. It allows to select a clip from the media object, 1861 to play from a given point to the end and from the current 1862 location to a given point. 1864 11.21 Require 1866 The Require header is used by clients to query the server about 1867 features that it may or may not support. The server MUST respond to 1868 this header by negatively acknowledging those features which are NOT 1869 supported in the Unsupported header. 1871 HS: Naming of features -- yet another name space. I believe 1872 this header field to be redundant. PEP should be used 1873 instead. 1875 For example 1877 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302 1878 Require: funky-feature 1879 Funky-Parameter: funkystuff 1881 S->C: RTSP/1.0 200 506 Option not supported 1882 Unsupported: funky-feature 1884 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 303 1886 S->C: RTSP/1.0 200 303 OK 1887 This is to make sure that the client-server interaction will proceed 1888 optimally when all options are understood by both sides, and only 1889 slow down if options aren't understood (as in the case above). For a 1890 well-matched client-server pair, the interaction proceeds quickly, 1891 saving a round-trip often required by negotiation mechanisms. In 1892 addition, it also removes state ambiguity when the client requires 1893 features that the server doesn't understand. 1895 11.22 Retry-After 1897 See [H14.38]. 1899 11.23 Scale 1901 A scale value of 1 indicates normal play or record at the normal 1902 forward viewing rate. If not 1, the value corresponds to the rate 1903 with respect to normal viewing rate. For example, a ratio of 2 1904 indicates twice the normal viewing rate ("fast forward") and a ratio 1905 of 0.5 indicates half the normal viewing rate. In other words, a 1906 ratio of 2 has normal play time increase at twice the wallclock rate. 1907 For every second of elapsed (wallclock) time, 2 seconds of content 1908 will be delivered. A negative value indicates reverse direction. 1910 Unless requested otherwise by the Speed parameter, the data rate 1911 SHOULD not be changed. Implementation of scale changes depends on the 1912 server and media type. For video, a server may, for example, deliver 1913 only key frames or selected key frames. For audio, it may time-scale 1914 the audio while preserving pitch or, less desirably, deliver 1915 fragments of audio. 1917 The server should try to approximate the viewing rate, but may 1918 restrict the range of scale values that it supports. The response 1919 MUST contain the actual scale value chosen by the server. 1921 If the request contains a Range parameter, the new scale value will 1922 take effect at that time. 1924 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 1926 Example of playing in reverse at 3.5 times normal rate: 1928 Scale: -3.5 1930 11.24 Speed 1932 This request header fields parameter requests the server to deliver 1933 data to the client at a particular speed, contingent on the server's 1934 ability and desire to serve the media stream at the given speed. 1935 Implementation by the server is OPTIONAL. The default is the bit rate 1936 of the stream. 1938 The parameter value is expressed as a decimal ratio, e.g., a value of 1939 2.0 indicates that data is to be delivered twice as fast as normal. A 1940 speed of zero is invalid. A negative value indicates that the stream 1941 is to be played back in reverse direction. 1943 HS: With 'Scale', the negative value is redundant and 1944 should probably be removed since it only leads to possible 1945 conflicts when Scale is positive and Speed negative. 1947 If the request contains a Range parameter, the new speed value will 1948 take effect at that time. 1950 Speed = "Speed" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 1952 Example: 1954 Speed: 2.5 1956 11.25 Server 1958 See [H14.39] 1960 11.26 Session 1962 This request and response header field identifies an RTSP session, 1963 started by the media server in a SETUP response and concluded by 1964 TEARDOWN on the presentation URL. The session identifier is chosen by 1965 the media server and has the same syntax as a conference identifier. 1966 Once a client receives a Session identifier, it MUST return it for 1967 any request related to that session. 1969 HS: This may be redundant with the standards-track HTTP 1970 state maintenance mechanism [2]. The equivalent way of 1971 doing this would be for the server to send Set-Cookie: 1972 Session="123"; Version=1; Path = "/twister" and for the 1973 client to return later Cookie: Session = "123"; $Version=1; 1974 $Path = "/twister" response to the TEARDOWN message, the 1975 server would simply send Set-Cookie: Session="123"; 1976 Version=1; Max-Age=0 to get rid of the cookie on the client 1977 side. Cookies also have a time-out, so that a server may 1978 limit the lifetime of a session at will. Unlike a web 1979 browser, a client would not store these states on disk. To 1980 avoid privacy issues, we should prohibit the Host 1981 parameter. 1983 11.27 Transport 1985 This request header indicates which transport protocol is to be used 1986 and configures its parameters such as multicast, compression, 1987 multicast time-to-live and destination port for a single stream. It 1988 sets those values not already determined by a presentation 1989 description. In some cases, the presentation description contains all 1990 necessary information. In those cases, a Transport header field 1991 (and the SETUP request containing it) are not needed. 1993 in whatever protocol is being used by the control stream. Currently, 1994 the next-layer protocols RTP is defined. Parameters may be added to 1995 each protocol, separated by a semicolon. For RTP, the boolean 1996 parameter compressed is defined, indicating compressed RTP according 1997 to RFC XXXX. For multicast UDP, the integer parameter ttl defines 1998 the time-to-live value to be used. The client may specify the 1999 multicast address with the multicast parameter. A server SHOULD 2000 authenticate the client before allowing the client to direct a media 2001 stream to a multicast address not chosen by the server to avoid 2002 becoming the unwitting perpetrator of a denial-of-service attack. For 2003 UDP and TCP, the parameter port defines the port data is to be sent 2004 to. 2006 The SSRC parameter indicates the RTP SSRC value that should be 2007 (request) or will be (response) used by the media server. This 2008 parameter is only valid for unicast transmission. It identifies the 2009 synchronization source to be associated with the media stream. 2011 The Transport header MAY also be used to change certain transport 2012 parameters. A server MAY refuse to change parameters of an existing 2013 stream. 2015 The server MAY return a Transport response header in the response to 2016 indicate the values actually chosen. 2018 A Transport request header field may contain a list of transport 2019 options acceptable to the client. In that case, the server MUST 2020 return a single option which was actually chosen. The Transport 2021 header field makes sense only for an individual media stream, not a 2022 presentation. 2024 Transport = "Transport" ":" 2025 1#transport-protocol/upper-layer *parameter 2026 transport-protocol = "UDP" | "TCP" 2027 upper-layer = "RTP" 2028 parameters = ";" "multicast" [ "=" mca ] 2029 | ";" "compressed" 2030 | ";" "interleaved" 2031 | ";" "ttl" "=" ttl 2032 | ";" "port" "=" port 2033 | ";" "ssrc" "=" ssrc 2034 ttl = 1*3(DIGIT) 2035 port = 1*5(DIGIT) 2036 ssrc = 8*8(HEX) 2037 mca = host 2039 Example: 2041 Transport: udp/rtp;compressed;ttl=127;port=3456 2043 11.28 Transport-Require 2045 The Transport-Require header is used to indicate proxy-sensitive 2046 features that MUST be stripped by the proxy to the server if not 2047 supported. Furthermore, any Transport-Require header features that 2048 are not supported by the proxy MUST be negatively acknowledged by the 2049 proxy to the client if not supported. 2051 See Section 11.21 for more details on the mechanics of this message 2052 and a usage example. 2054 HS: Same caveat as for Require applies. 2056 11.29 Unsupported 2058 See Section 11.21 for a usage example. 2060 HS: same caveat as for Require applies. 2062 11.30 User-Agent 2064 See [H14.42] 2066 11.31 Via 2068 See [H14.44]. 2070 11.32 WWW-Authenticate 2072 See [H14.46]. 2074 12 Caching 2076 In HTTP, response-request pairs are cached. RTSP differs 2077 significantly in that respect. Responses are not cachable, with the 2078 exception of the stream description returned by DESCRIBE. (Since the 2079 responses for anything but DESCRIBE and GET_PARAMETER do not return 2080 any data, caching is not really an issue for these requests.) 2081 However, it is desirable for the continuous media data, typically 2082 delivered out-of-band with respect to RTSP, to be cached. 2084 On receiving a SETUP or PLAY request, the proxy would ascertain as 2085 to whether it has an up-to-date copy of the continuous media content. 2086 If not, it would modify the SETUP transport parameters as 2087 appropriate and forward the request to the origin server. Subsequent 2088 control commands such as PLAY or PAUSE would pass the proxy 2089 unmodified. The proxy would then pass the continuous media data to 2090 the client, while possibly making a local copy for later re-use. The 2091 exact behavior allowed to the cache is given by the cache-response 2092 directives described in Section 11.8. A cache MUST answer any 2093 DESCRIBE requests if it is currently serving the stream to the 2094 requestor, as it is possible that low-level details of the stream 2095 description may have changed on the origin-server. 2097 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 2098 through" variety. Rather than retrieving the whole resource from the 2099 origin server, the cache simply copies the streaming data as it 2100 passes by on its way to the client, thus, it does not introduce 2101 additional latency. 2103 To the client, an RTSP proxy cache would appear like a regular media 2104 server, to the media origin server like a client. Just like an HTTP 2105 cache has to store the content type, content language, etc. for the 2106 objects it caches, a media cache has to store the presentation 2107 description. Typically, a cache would eliminate all transport- 2108 references (that is, multicast information) from the presentation 2109 description, since these are independent of the data delivery from 2110 the cache to the client. Information on the encodings remains the 2111 same. If the cache is able to translate the cached media data, it 2112 would create a new presentation description with all the encoding 2113 possibilities it can offer. 2115 13 Examples 2117 The following examples reference stream description formats that are 2118 not finalized, such as RTSL and SDP. Please do not use these examples 2119 as a reference for those formats. 2121 13.1 Media on Demand (Unicast) 2123 Client C requests a movie from media servers A ( audio.example.com ) 2124 and V ( video.example.com ). The media description is stored on a web 2125 server W. The media description contains descriptions of the 2126 presentation and all its streams, including the codecs that are 2127 available, dynamic RTP payload types, the protocol stack and content 2128 information such as language or copyright restrictions. It may also 2129 give an indication about the time line of the movie. 2131 In our example, the client is only interested in the last part of the 2132 movie. The server requires authentication for this movie. The audio 2133 track can be dynamically switched between between two sets of 2134 encodings. The URL with scheme rtpsu indicates the media servers 2135 want to use UDP for exchanging RTSP messages. 2137 C->W: DESCRIBE /twister HTTP/1.1 2138 Host: www.example.com 2139 Accept: application/rtsl; application/sdp 2141 W->C: 200 OK 2142 Content-Type: application/rtsl 2144 2145 2146 2147 2150 2153 2154 2156 2158 2160 C->A: SETUP rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 1 2161 Transport: rtp/udp;compression;port=3056 2163 A->C: RTSP/1.0 200 1 OK 2164 Session: 1234 2166 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 1 2167 Transport: rtp/udp;compression;port=3058 2169 V->C: RTSP/1.0 200 1 OK 2170 Session: 1235 2172 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 2 2173 Session: 1235 2174 Range: smpte=0:10:00- 2176 V->C: RTSP/1.0 200 2 OK 2178 C->A: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 2 2179 Session: 1234 2180 Range: smpte=0:10:00- 2182 A->C: 200 2 OK 2184 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 3 2185 Session: 1234 2187 A->C: 200 3 OK 2189 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 3 2190 Session: 1235 2192 V->C: 200 3 OK 2194 Even though the audio and video track are on two different servers, 2195 may start at slightly different times and may drift with respect to 2196 each other, the client can synchronize the two using standard RTP 2197 methods, in particular the time scale contained in the RTCP sender 2198 reports. 2200 13.2 Live Media Presentation Using Multicast 2202 The media server M chooses the multicast address and port. Here, we 2203 assume that the web server only contains a pointer to the full 2204 description, while the media server M maintains the full description. 2205 During the RTSP session, a new subtitling stream is added. 2207 C->W: GET /concert HTTP/1.1 2208 Host: www.example.com 2210 W->C: HTTP/1.1 200 OK 2211 Content-Type: application/rtsl 2213 2214 2215 2217 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 1 2219 M->C: RTSP/1.0 200 1 OK 2220 Content-Type: application/rtsl 2222 2224 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 2 2225 Transport: multicast=224.2.0.1; port=3456; ttl=16 2227 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3 2228 Range: smpte 1:12:0 2230 M->C: RTSP/1.0 405 3 No positioning possible 2232 M->C: DESCRIBE concert RTSP/1.0 2233 Content-Type: application/rtsl 2235 2236 2238 2240 2242 C->M: PLAY rtsp://live.example.com/concert/lyrics RTSP/1.0 2244 The attempt to position the stream fails since this is a live 2245 presentation. 2247 13.3 Playing media into an existing session 2248 A conference participant C wants to have the media server M play back 2249 a demo tape into an existing conference. When retrieving the 2250 presentation description, C indicates to the media server that the 2251 network addresses and encryption keys are already given by the 2252 conference, so they should not be chosen by the server. The example 2253 omits the simple ACK responses. 2255 C->M: GET /demo HTTP/1.1 2256 Host: www.example.com 2257 Accept: application/rtsl, application/sdp 2259 M->C: HTTP/1.1 200 1 OK 2260 Content-type: application/rtsl 2262 2263 2265 2267 C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 2 2268 Conference: 218kadjk 2270 13.4 Recording 2272 The conference participant C asks the media server M to record a 2273 meeting. If the presentation description contains any alternatives, 2274 the server records them all. 2276 C->M: DESCRIBE rtsp://server.example.com/meeting RTSP/1.0 89 2277 Content-Type: application/sdp 2279 v=0 2280 s=Mbone Audio 2281 i=Discussion of Mbone Engineering Issues 2283 M->C: 415 89 Unsupported Media Type 2284 Accept: application/rtsl 2286 C->M: DESCRIBE rtsp://server.example.com/meeting RTSP/1.0 90 2287 Content-Type: application/rtsl 2289 M->C: 200 90 OK 2291 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 91 2292 Range: clock 19961110T1925-19961110T2015 2294 14 Syntax 2296 The RTSP syntax is described in an augmented Backus-Naur form (BNF) 2297 as used in RFC 2068 (HTTP/1.1). 2299 14.1 Base Syntax 2301 OCTET = 2302 CHAR = 2303 UPALPHA = 2304 LOALPHA = 2305 ALPHA = UPALPHA | LOALPHA 2306 DIGIT = 2307 CTL = 2309 CR = 2310 LF = 2311 SP = 2312 HT = 2313 <"> = 2314 CRLF = CR LF 2315 LWS = [CRLF] 1*( SP | HT ) 2316 TEXT = 2317 tspecials = "(" | ")" | "<" | ">" | "@" 2318 | "," | ";" | ":" | " 2319 | "/" | "[" | "]" | "?" | "=" 2320 | "{" | "}" | SP | HT 2321 token = 1* 2322 quoted-string = ( <"> *(qdtext) <"> ) 2323 qdtext = > 2324 quoted-pair = " 2326 message-header = field-name ":" [ field-value ] CRLF 2327 field-name = token 2328 field-value = *( field-content | LWS ) 2329 field-content = 2333 15 Security Considerations 2334 The protocol offers the opportunity for a remote-control denial-of- 2335 service attack. The attacker, using a forged source IP address, can 2336 ask for a stream to be played back to that forged IP address. 2338 Since there is no relation between a transport layer connection and 2339 an RTSP session, it is possible for a malicious client to issue 2340 requests with random session identifiers which would affect 2341 unsuspecting clients. This does not require spoofing of network 2342 packet addresses. The server SHOULD use a large random session 2343 identifier to make this attack more difficult. 2345 Both problems can be be prevented by appropriate authentication. 2347 In addition, the security considerations outlined in [H15] apply. 2349 A RTSP Protocol State Machines 2351 The RTSP client and server state machines describe the behavior of 2352 the protocol from RTSP session initialization through RTSP session 2353 termination. 2355 [TBD: should we allow for the trivial case of a server that only 2356 implements the PLAY message, with no control.] 2358 State is defined on a per object basis. An object is uniquely 2359 identified by the stream URL and the RTSP session identifier. (A 2360 server may choose to generate dynamic presentation descriptions where 2361 the URL is unique for a particular RTSP session and thus may not need 2362 an explicit RTSP session identifier in the request header.) Any 2363 request/reply using URLs denoting an RTSP session comprised of 2364 multiple streams will have an effect on the individual states of all 2365 the substreams. For example, if the stream /movie contains two 2366 substreams /movie/audio and /movie/video, then the following command: 2368 PLAY /movie RTSP/1.0 559 2369 Session: 12345 2371 will have an effect on the states of movie/audio and movie/video. 2373 This example does not imply a standard way to represent 2374 substreams in URLs or a relation to the filesystem. See 2375 Section 3.2. 2377 The requests OPTIONS, DESCRIBE, GET_PARAMETER, SET_PARAMETER do 2378 not have any effect on client or server state and are therefore not 2379 listed in the state tables. 2381 Client and servers MUST disregard messages with a sequence number 2382 less than the last one. If no message has been received, the first 2383 received message's sequence number will be the starting point. 2385 A.1 Client State Machine 2387 The client can assume the following states: 2389 Init: SETUP has been sent, waiting for reply. 2391 Ready: SETUP reply received OR after playing, PAUSE reply received. 2393 Playing: PLAY reply received 2395 Recording: RECORD reply received 2397 The client changes state on receipt of replies to requests. If no 2398 explicit SETUP is required for the object (for example, it is 2399 available via a multicast group), state begins at READY. In this 2400 case, there are only two states, READY and PLAYING. 2402 The "next state" column indicates the state assumed after receiving a 2403 success response (2xx). If a request yields a status code greater or 2404 equal to 300, the client state becomes Init, with the exception of 2405 status codes 401 (Unauthorized) and 402 (Payment Required), where the 2406 state remains unchanged and the request should be re-issued with the 2407 appropriate authentication or payment information. Messages not 2408 listed for each state MUST NOT be issued by the client in that state, 2409 with the exception of messages not affecting state, as listed above. 2410 Receiving a REDIRECT from the server is equivalent to receiving a 3xx 2411 redirect status from the server. 2413 HS: Depends on allowing PLAY without SETUP. After 4xx or 2414 5xx error, do we go back to Init? 2416 state message next state 2417 _______________________________________________________ 2418 Init SETUP Ready 2419 TEARDOWN Init 2420 Ready PLAY Playing 2421 RECORD Recording 2422 TEARDOWN Init 2423 Playing PAUSE Ready 2424 TEARDOWN Init 2425 PLAY Playing 2426 RECORD Recording 2427 SETUP Playing (changed transport) 2428 Recording PAUSE Init 2429 TEARDOWN Init 2430 PLAY Playing 2431 RECORD Recording 2432 SETUP Recording (changed transport) 2434 A.2 Server State Machine 2436 The server can assume the following states: 2438 Init: The initial state, no valid SETUP received. 2440 Ready: Last SETUP received was successful, reply sent or after 2441 playing, last PAUSE received was successful, reply sent. 2443 Playing: Last PLAY received was successful, reply sent. Data is 2444 being sent. 2446 Recording: The server is recording media data. 2448 The server changes state on receiving requests. If the server is in 2449 state Playing or Recording and in unicast mode, it MAY revert to Init 2450 and tear down the RTSP session if it has not received "wellness" 2451 information, such as RTCP reports, from the client for a defined 2452 interval, with a default of one minute. If the server is in state 2453 Ready, it MAY revert to Init if it does not receive an RTSP request 2454 for an interval of more than one minute. 2456 The REDIRECT message, when sent, is effective immediately. If a 2457 similar change of location occurs at a certain time in the future, 2458 this is assumed to be indicated by the presentation description. 2460 SETUP is valid in states Init and Ready only. An error message should 2461 be returned in other cases. If no explicit SETUP is required for the 2462 object, state starts at READY, there are only two states READY and 2463 PLAYING. 2465 state message next state 2466 ___________________________________ 2467 Init SETUP Ready 2468 TEARDOWN Init 2469 Ready PLAY Playing 2470 SETUP Ready 2471 TEARDOWN Ready 2473 Playing PLAY Playing 2474 PAUSE Ready 2475 TEARDOWN Ready 2476 RECORD Recording 2477 SETUP Playing 2478 Recording RECORD Recording 2479 PAUSE Ready 2480 TEARDOWN Ready 2481 PLAY Playing 2482 SETUP Recording 2484 B Open Issues 2486 o Define text/rtsp-parameter MIME type. 2488 o HS believes that RTSP should only control individual media 2489 objects rather than aggregates. This avoids disconnects between 2490 presentation descriptions and streams and avoids having to deal 2491 separately with single-host and multi-host case. Cost: several 2492 PLAY/PAUSE/RECORD in one packet, one for each stream. 2494 o Allow changing of transport for a stream that's playing? May 2495 not be a great idea since the same can be accomplished by tear 2496 down and re-setup. 2498 o Allow fragment (#) identifiers for controlling substreams in 2499 Quicktime, AVI and ASF files? 2501 o How does the server get back to the client unless a persistent 2502 connection is used? Probably cannot, in general. 2504 o Cache and proxy behavior? 2506 o Session: or Set-Cookie: ? 2508 o When do relative RTSP URLs make sense? 2510 o Nack-require, etc. are dubious. This is getting awfully close 2511 to the HTTP extension mechanisms [19] in complexity, but is 2512 different. 2514 o Use HTTP absolute path + Host field or do the right thing and 2515 carry full URL, including host in request? 2517 C Changes 2519 Since the February 1997 version, the following changes were made: 2521 o Various editorial changes and clarifications. 2523 o Removed references to SDF and replaced by RTSL. 2525 o Added Scale general header. 2527 o Clarify behavior of PLAY. 2529 o Rename GET to DESCRIBE. 2531 o Removed SESSION since it is just DESCRIBE in the other 2532 direction. 2534 o Rename CLOSE to TEARDOWN, in symmetry with SETUP. 2536 o Terminology adjusted to "presentation" and "stream". 2538 o Redundant syntax BNF in appendix removed since it just 2539 duplicates HTTP spec. 2541 o Beginnings of cache control. 2543 Changes are marked by changebars in the margins of the PostScript 2544 version. 2546 D Author Addresses 2548 Henning Schulzrinne 2549 Dept. of Computer Science 2550 Columbia University 2551 1214 Amsterdam Avenue 2552 New York, NY 10027 2553 USA 2554 electronic mail: schulzrinne@cs.columbia.edu 2556 Anup Rao 2557 Netscape Communications Corp. 2558 USA 2559 electronic mail: anup@netscape.com 2561 Robert Lanphier 2562 Progressive Networks 2563 1111 Third Avenue Suite 2900 2564 Seattle, WA 98101 2565 USA 2566 electronic mail: robla@prognet.com 2568 E Acknowledgements 2569 This draft is based on the functionality of the RTSP draft. It also 2570 borrows format and descriptions from HTTP/1.1. 2572 This document has benefited greatly from the comments of all those 2573 participating in the MMUSIC-WG. In addition to those already 2574 mentioned, the following individuals have contributed to this 2575 specification: 2577 Rahul Agarwal Eduardo F. Llach 2578 Bruce Butterfield Rob McCool 2579 Martin Dunsmuir Sujal Patel 2580 Eric Fleischman 2581 Mark Handley Igor Plotnikov 2582 Peter Haight Pinaki Shah 2583 Brad Hefta-Gaub Jeff Smith 2584 John K. Ho Alexander Sokolsky 2585 Ruth Lang Dale Stammen 2586 Stephanie Leif John Francis Stracke 2588 F Bibliography 2590 [1] H. Schulzrinne, "RTP profile for audio and video conferences with 2591 minimal control," RFC 1890, Internet Engineering Task Force, Jan. 2592 1996. 2594 [2] D. Kristol and L. Montulli, "HTTP state management mechanism," 2595 RFC 2109, Internet Engineering Task Force, Feb. 1997. 2597 [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 2598 "Internationalization of the hypertext markup language," RFC 2070, 2599 Internet Engineering Task Force, Jan. 1997. 2601 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 2602 levels," Internet Draft, Internet Engineering Task Force, Jan. 1997. 2603 Work in progress. 2605 [5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, 2606 "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 2607 Engineering Task Force, Jan. 1997. 2609 [6] M. Handley, "SDP: Session description protocol," Internet Draft, 2610 Internet Engineering Task Force, Nov. 1996. Work in progress. 2612 [7] A. Freier, P. Karlton, and P. Kocher, "The TLS protocol," 2613 Internet Draft, Internet Engineering Task Force, Dec. 1996. Work in 2614 progress. 2616 [8] J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and E. 2617 L. Stewart, "An extension to HTTP: digest access authentication," 2618 RFC 2069, Internet Engineering Task Force, Jan. 1997. 2620 [9] J. Postel, "User datagram protocol," STD 6, RFC 768, Internet 2621 Engineering Task Force, Aug. 1980. 2623 [10] R. Hinden and C. Partridge, "Version 2 of the reliable data 2624 protocol (RDP)," RFC 1151, Internet Engineering Task Force, Apr. 2625 1990. 2627 [11] J. Postel, "Transmission control protocol," STD 7, RFC 793, 2628 Internet Engineering Task Force, Sept. 1981. 2630 [12] M. Handley, H. Schulzrinne, and E. Schooler, "SIP: Session 2631 initiation protocol," Internet Draft, Internet Engineering Task 2632 Force, Dec. 1996. Work in progress. 2634 [13] P. McMahon, "GSS-API authentication method for SOCKS version 5," 2635 RFC 1961, Internet Engineering Task Force, June 1996. 2637 [14] D. Crocker, "Augmented BNF for syntax specifications: ABNF," 2638 Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in 2639 progress. 2641 [15] R. Elz, "A compact representation of IPv6 addresses," RFC 1924, 2642 Internet Engineering Task Force, Apr. 1996. 2644 [16] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 2645 locators (URL)," RFC 1738, Internet Engineering Task Force, Dec. 2646 1994. 2648 [17] International Telecommunication Union, "Visual telephone systems 2649 and equipment for local area networks which provide a non-guaranteed 2650 quality of service," Recommendation H.323, Telecommunication 2651 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 2653 [18] ISO/IEC, "Information technology -- generic coding of moving 2654 pictures and associated audio informaiton -- part 6: extension for 2655 digital storage media and control," Draft International Standard ISO 2656 13818-6, International Organization for Standardization ISO/IEC 2657 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 2659 [19] D. Connolly, "PEP: an extension mechanism for http," Internet 2660 Draft, Internet Engineering Task Force, Jan. 1997. Work in progress. 2662 Table of Contents 2664 1 Introduction ........................................ 1 2665 1.1 Purpose ............................................. 1 2666 1.2 Requirements ........................................ 3 2667 1.3 Terminology ......................................... 3 2668 1.4 Protocol Properties ................................. 5 2669 1.5 Extending RTSP ...................................... 6 2670 1.6 Overall Operation ................................... 7 2671 1.7 RTSP States ......................................... 8 2672 1.8 Relationship with Other Protocols ................... 9 2673 2 Notational Conventions .............................. 10 2674 3 Protocol Parameters ................................. 10 2675 3.1 H3.1 ................................................ 10 2676 3.2 RTSP URL ............................................ 10 2677 3.3 Conference Identifiers .............................. 11 2678 3.4 SMPTE Relative Timestamps ........................... 12 2679 3.5 Normal Play Time .................................... 13 2680 3.6 Absolute Time ....................................... 13 2681 4 RTSP Message ........................................ 13 2682 4.1 Message Types ....................................... 14 2683 4.2 Message Headers ..................................... 14 2684 4.3 Message Body ........................................ 14 2685 4.4 Message Length ...................................... 14 2686 5 Request ............................................. 15 2687 6 Response ............................................ 16 2688 6.1 Status-Line ......................................... 17 2689 6.1.1 Status Code and Reason Phrase ....................... 17 2690 6.1.2 Response Header Fields .............................. 19 2691 7 Entity .............................................. 19 2692 7.1 Entity Header Fields ................................ 21 2693 7.2 Entity Body ......................................... 21 2694 8 Connections ......................................... 21 2695 8.1 Pipelining .......................................... 22 2696 8.2 Reliability and Acknowledgements .................... 22 2697 9 Method Definitions .................................. 23 2698 9.1 OPTIONS ............................................. 24 2699 9.2 DESCRIBE ........................................... 25 2700 9.3 SETUP .............................................. 26 2701 9.4 PLAY ............................................... 27 2702 9.5 PAUSE .............................................. 28 2703 9.6 TEARDOWN ........................................... 30 2704 9.7 GET_PARAMETER ...................................... 30 2705 9.8 SET_PARAMETER ...................................... 31 2706 9.9 REDIRECT ........................................... 31 2707 9.10 RECORD ............................................. 32 2708 9.11 Embedded Binary Data ................................ 32 2709 10 Status Code Definitions ............................. 33 2710 10.1 Redirection 3xx ..................................... 33 2711 10.2 Client Error 4xx .................................... 33 2712 10.2.1 451 Parameter Not Understood ........................ 33 2713 10.2.2 452 Conference Not Found ............................ 33 2714 10.2.3 453 Not Enough Bandwidth ............................ 33 2715 10.2.4 45x Session Not Found ............................... 33 2716 10.2.5 45x Method Not Valid in This State .................. 33 2717 10.2.6 45x Header Field Not Valid for Resource ............. 33 2718 10.2.7 45x Invalid Range ................................... 33 2719 10.2.8 45x Parameter Is Read-Only .......................... 34 2720 11 Header Field Definitions ............................ 34 2721 11.1 Accept .............................................. 34 2722 11.2 Accept-Encoding ..................................... 35 2723 11.3 Accept-Language ..................................... 35 2724 11.4 Allow ............................................... 36 2725 11.5 Authorization ....................................... 36 2726 11.6 Bandwidth ........................................... 36 2727 11.7 Blocksize ........................................... 36 2728 11.8 Cache-Control ....................................... 37 2729 11.9 Conference .......................................... 39 2730 11.10 Connection .......................................... 39 2731 11.11 Content-Encoding .................................... 39 2732 11.12 Content-Length ...................................... 39 2733 11.13 Content-Type ........................................ 39 2734 11.14 Date ................................................ 40 2735 11.15 Expires ............................................. 40 2736 11.16 If-Modified-Since ................................... 41 2737 11.17 Last-modified ....................................... 41 2738 11.18 Location ............................................ 41 2739 11.19 Nack-Transport-Require .............................. 41 2740 11.20 Range ............................................... 41 2741 11.21 Require ............................................. 42 2742 11.22 Retry-After ......................................... 43 2743 11.23 Scale ............................................... 43 2744 11.24 Speed ............................................... 44 2745 11.25 Server .............................................. 44 2746 11.26 Session ............................................. 44 2747 11.27 Transport ........................................... 45 2748 11.28 Transport-Require ................................... 46 2749 11.29 Unsupported ......................................... 46 2750 11.30 User-Agent .......................................... 47 2751 11.31 Via ................................................. 47 2752 11.32 WWW-Authenticate .................................... 47 2753 12 Caching ............................................. 47 2754 13 Examples ............................................ 48 2755 13.1 Media on Demand (Unicast) ........................... 48 2756 13.2 Live Media Presentation Using Multicast ............. 49 2757 13.3 Playing media into an existing session .............. 50 2758 13.4 Recording ........................................... 51 2759 14 Syntax .............................................. 52 2760 14.1 Base Syntax ......................................... 52 2761 15 Security Considerations ............................. 52 2762 A RTSP Protocol State Machines ........................ 53 2763 A.1 Client State Machine ................................ 54 2764 A.2 Server State Machine ................................ 55 2765 B Open Issues ......................................... 56 2766 C Changes ............................................. 56 2767 D Author Addresses .................................... 57 2768 E Acknowledgements .................................... 57 2769 F Bibliography ........................................ 58