idnits 2.17.1 draft-ietf-mmusic-rtsp-03.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-25) 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. == 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 71) being 96 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 139 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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. RFC 2119 keyword, line 448: '... A server SHOULD implement all heade...' RFC 2119 keyword, line 465: '...the server. The server SHOULD list the...' RFC 2119 keyword, line 638: '...ddresses in URLs SHOULD be avoided whe...' RFC 2119 keyword, line 679: '...conference identifier MUST be globally...' RFC 2119 keyword, line 701: '... A session identifier SHOULD be chosen...' (70 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1051 has weird spacing: '...equired all...' == Line 1067 has weird spacing: '...s State all...' == Line 1068 has weird spacing: '...allowed all...' == Line 1069 has weird spacing: '...allowed all...' == Line 1750 has weird spacing: '... type supp...' == (4 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 recommended, but not required in that a fully functional server can be built that does not support this method, for example, for live feeds. If a server does not support a particular method, it MUST return "501 Not Implemented" and a client SHOULD not try this method again for this server. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: destination: The address to which a stream will be sent. The client may specify the multicast address with the destination parameter. A server SHOULD authenticate the client and SHOULD log such attempts before allowing the client to direct a media stream to an address not chosen by the server to avoid becoming the unwitting perpetrator of a remote-controlled denial-of-service attack. This is particularly important if RTSP commands are issued via UDP, but TCP cannot be relied upon as reliable means of client identification by itself. A server SHOULD not allow a client to direct media streams to an address that differs from the address commands are coming from. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 196 looks like a reference -- Missing reference section? '3' on line 213 looks like a reference -- Missing reference section? '4' on line 254 looks like a reference -- Missing reference section? '5' on line 257 looks like a reference -- Missing reference section? '18' on line 739 looks like a reference -- Missing reference section? '6' on line 325 looks like a reference -- Missing reference section? '7' on line 630 looks like a reference -- Missing reference section? '8' on line 2736 looks like a reference -- Missing reference section? '9' on line 362 looks like a reference -- Missing reference section? '10' on line 363 looks like a reference -- Missing reference section? '11' on line 364 looks like a reference -- Missing reference section? '12' on line 688 looks like a reference -- Missing reference section? '13' on line 398 looks like a reference -- Missing reference section? '20' on line 405 looks like a reference -- Missing reference section? '14' on line 594 looks like a reference -- Missing reference section? '15' on line 639 looks like a reference -- Missing reference section? '16' on line 643 looks like a reference -- Missing reference section? '17' on line 687 looks like a reference -- Missing reference section? 'H6' on line 917 looks like a reference -- Missing reference section? 'H10' on line 1652 looks like a reference -- Missing reference section? '21' on line 1866 looks like a reference -- Missing reference section? 'CRLF' on line 2699 looks like a reference -- Missing reference section? 'H15' on line 2738 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MMUSIC WG 2 Internet Draft H. Schulzrinne, A. Rao, R. Lanphier 3 draft-ietf-mmusic-rtsp-03.txt Columbia U./Netscape/Progressive Networks 4 July 30, 1997 Expires: January 30, 1998 6 Real Time Streaming Protocol (RTSP) 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress''. 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Distribution of this document is unlimited. 28 Abstract: 30 The Real Time Streaming Protocol, or RTSP, is an application-level 31 protocol for control over the delivery of data with real-time 32 properties. RTSP provides an extensible framework to enable 33 controlled, on-demand delivery of real-time data, such as audio and 34 video. Sources of data can include both live data feeds and stored 35 clips. This protocol is intended to control multiple data delivery 36 sessions, provide a means for choosing delivery channels such as UDP, 37 multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC 38 1889). 40 H. Schulzrinne, A. Rao, R. Lanphier Page 1 41 Contents 43 * 1 Introduction 44 + 1.1 Purpose 45 + 1.2 Requirements 46 + 1.3 Terminology 47 + 1.4 Protocol Properties 48 + 1.5 Extending RTSP 49 + 1.6 Overall Operation 50 + 1.7 RTSP States 51 + 1.8 Relationship with Other Protocols 52 * 2 Notational Conventions 53 * 3 Protocol Parameters 54 + 3.1 RTSP Version 55 + 3.2 RTSP URL 56 + 3.3 Conference Identifiers 57 + 3.4 Session Identifiers 58 + 3.5 SMPTE Relative Timestamps 59 + 3.6 Normal Play Time 60 + 3.7 Absolute Time 61 * 4 RTSP Message 62 + 4.1 Message Types 63 + 4.2 Message Headers 64 + 4.3 Message Body 65 + 4.4 Message Length 66 * 5 General Header Fields 67 * 6 Request 68 + 6.1 Request Line 69 + 6.2 Request Header Fields 70 * 7 Response 71 + 7.1 Status-Line 72 o 7.1.1 Status Code and Reason Phrase 73 o 7.1.2 Response Header Fields 74 * 8 Entity 75 + 8.1 Entity Header Fields 76 + 8.2 Entity Body 77 * 9 Connections 78 + 9.1 Pipelining 79 + 9.2 Reliability and Acknowledgements 80 * 10 Method Definitions 81 + 10.1 OPTIONS 82 + 10.2 DESCRIBE 83 + 10.3 ANNOUNCE 84 + 10.4 SETUP 85 + 10.5 PLAY 86 + 10.6 PAUSE 87 + 10.7 TEARDOWN 88 + 10.8 GET_PARAMETER 89 + 10.9 SET_PARAMETER 90 + 10.10 REDIRECT 92 H. Schulzrinne, A. Rao, R. Lanphier Page 2 93 + 10.11 RECORD 94 + 10.12 Embedded (Interleaved) Binary Data 95 * 11 Status Code Definitions 96 + 11.1 Redirection 3xx 97 + 11.2 Client Error 4xx 98 o 11.2.1 405 Method Not Allowed 99 o 11.2.2 451 Parameter Not Understood 100 o 11.2.3 452 Conference Not Found 101 o 11.2.4 453 Not Enough Bandwidth 102 o 11.2.5 45x Session Not Found 103 o 11.2.6 45x Method Not Valid in This State 104 o 11.2.7 45x Header Field Not Valid for Resource 105 o 11.2.8 45x Invalid Range 106 o 11.2.9 45x Parameter Is Read-Only 107 o 11.2.10 45x Aggregate operation not allowed 108 o 11.2.11 45x Only aggregate operation allowed 109 * 12 Header Field Definitions 110 + 12.1 Accept 111 + 12.2 Accept-Encoding 112 + 12.3 Accept-Language 113 + 12.4 Allow 114 + 12.5 Authorization 115 + 12.6 Bandwidth 116 + 12.7 Blocksize 117 + 12.8 C-PEP 118 + 12.9 C-PEP-Info 119 + 12.10 Cache-Control 120 + 12.11 Conference 121 + 12.12 Connection 122 + 12.13 Content-Encoding 123 + 12.14 Content-Language 124 + 12.15 Content-Length 125 + 12.16 Content-Type 126 + 12.17 Date 127 + 12.18 Expires 128 + 12.19 From 129 + 12.20 Host 130 + 12.21 If-Modified-Since 131 + 12.22 Last-Modified 132 + 12.23 Location 133 + 12.24 PEP 134 + 12.25 PEP-Info 135 + 12.26 Proxy-Authenticate 136 + 12.27 Public 137 + 12.28 Range 138 + 12.29 Referer 139 + 12.30 Retry-After 140 + 12.31 Scale 141 + 12.32 Speed 142 + 12.33 Server 144 H. Schulzrinne, A. Rao, R. Lanphier Page 3 145 + 12.34 Session 146 + 12.35 Transport 147 + 12.36 Transport-Info 148 + 12.37 User-Agent 149 + 12.38 Vary 150 + 12.39 Via 151 + 12.40 WWW-Authenticate 152 * 13 Caching 153 * 14 Examples 154 + 14.1 Media on Demand (Unicast) 155 + 14.2 Streaming of a Container file 156 + 14.3 Live Media Presentation Using Multicast 157 + 14.4 Playing media into an existing session 158 + 14.5 Recording 159 * 15 Syntax 160 + 15.1 Base Syntax 161 * 16 Security Considerations 162 * A RTSP Protocol State Machines 163 + A.1 Client State Machine 164 + A.2 Server State Machine 165 * B Open Issues 166 * C Changes 167 * D Author Addresses 168 * E Acknowledgements 169 * References 171 1 Introduction 173 1.1 Purpose 175 The Real-Time Streaming Protocol (RTSP) establishes and controls 176 either a single or several time-synchronized streams of continuous 177 media such as audio and video. It does not typically deliver the 178 continuous streams itself, although interleaving of the continuous 179 media stream with the control stream is possible (see Section 10.12). 180 In other words, RTSP acts as a ``network remote control'' for 181 multimedia servers. 183 The set of streams to be controlled is defined by a presentation 184 description. This memorandum does not define a format for a 185 presentation description. 187 H. Schulzrinne, A. Rao, R. Lanphier Page 4 188 There is no notion of an RTSP connection; instead, a server maintains 189 a session labeled by an identifier. An RTSP session is in no way tied 190 to a transport-level connection such as a TCP connection. During an 191 RTSP session, an RTSP client may open and close many reliable 192 transport connections to the server to issue RTSP requests. 193 Alternatively, it may use a connectionless transport protocol such as 194 UDP. 196 The streams controlled by RTSP may use RTP [1], but the operation of 197 RTSP does not depend on the transport mechanism used to carry 198 continuous media. 200 The protocol is intentionally similar in syntax and operation to 201 HTTP/1.1, so that extension mechanisms to HTTP can in most cases also 202 be added to RTSP. However, RTSP differs in a number of important 203 aspects from HTTP: 205 * RTSP introduces a number of new methods and has a different 206 protocol identifier. 207 * An RTSP server needs to maintain state by default in almost all 208 cases, as opposed to the stateless nature of HTTP. 209 * Both an RTSP server and client can issue requests. 210 * Data is carried out-of-band, by a different protocol. (There is an 211 exception to this.) 212 * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, 213 consistent with current HTML internationalization efforts [3]. 214 * The Request-URI always contains the absolute URI. Because of 215 backward compatibility with a historical blunder, HTTP/1.1 carries 216 only the absolute path in the request and puts the host name in a 217 separate header field. 219 This makes ``virtual hosting'' easier, where a single host with one 220 IP address hosts several document trees. 222 The protocol supports the following operations: 224 Retrieval of media from media server: 225 The client can request a presentation description via HTTP or 226 some other method. If the presentation is being multicast, the 227 presentation description contains the multicast addresses and 228 ports to be used for the continuous media. If the presentation 229 is to be sent only to the client via unicast, the client 230 provides the destination for security reasons. 232 H. Schulzrinne, A. Rao, R. Lanphier Page 5 233 Invitation of a media server to a conference: 234 A media server can be ``invited'' to join an existing 235 conference, either to play back media into the presentation or 236 to record all or a subset of the media in a presentation. This 237 mode is useful for distributed teaching applications. Several 238 parties in the conference may take turns ``pushing the remote 239 control buttons''. 241 Addition of media to an existing presentation: 242 Particularly for live presentations, it is useful if the server 243 can tell the client about additional media becoming available. 245 RTSP requests may be handled by proxies, tunnels and caches as in 246 HTTP/1.1. 248 1.2 Requirements 250 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 251 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and 252 ``OPTIONAL'' in this document are to be interpreted as described in 253 RFC 2119 [4]. 255 1.3 Terminology 257 Some of the terminology has been adopted from HTTP/1.1 [5]. Terms not 258 listed here are defined as in HTTP/1.1. 260 Conference: 261 a multiparty, multimedia presentation, where ``multi'' implies 262 greater than or equal to one. 264 Client: 265 The client requests continuous media data from the media 266 server. 268 Connection: 269 A transport layer virtual circuit established between two 270 programs for the purpose of communication. 272 H. Schulzrinne, A. Rao, R. Lanphier Page 6 273 Continuous media: 274 Data where there is a timing relationship between source and 275 sink, that is, the sink must reproduce the timing relationshop 276 that existed at the source. The most common examples of 277 continuous media are audio and motion video. Continuous media 278 can be realtime (interactive), where there is a ``tight'' 279 timing relationship between source and sink, or streaming 280 (playback), where the relationship is less strict. 282 Participant: 283 Participants are members of conferences. A participant may be a 284 machine, e.g., a media record or playback server. 286 Media server: 287 The network entity providing playback or recording services for 288 one or more media streams. Different media streams within a 289 presentation may originate from different media servers. A 290 media server may reside on the same or a different host as the 291 web server the presentation is invoked from. 293 Media parameter: 294 Parameter specific to a media type that may be changed while 295 the stream is being played or prior to it. 297 (Media) stream: 298 A single media instance, e.g., an audio stream or a video 299 stream as well as a single whiteboard or shared application 300 group. When using RTP, a stream consists of all RTP and RTCP 301 packets created by a source within an RTP session. This is 302 equivalent to the definition of a DSM-CC stream([18]). 304 Message: 305 The basic unit of RTSP communication, consisting of a 306 structured sequence of octets matching the syntax defined in 307 Section 15 and transmitted via a connection or a connectionless 308 protocol. 310 Presentation: 311 A set of one or more streams which the server allows the client 312 to manipulate together. A presentation has a single time axis 313 for all streams belonging to it. Presentations are defined by 314 presentation descriptions (see below). A presentation 315 description contains RTSP URIs that define which streams can be 316 controlled individually and an RTSP URI to control the whole 317 presentation. A movie or live concert consisting of one or more 318 audio and video streams is an example of a presentation. 320 H. Schulzrinne, A. Rao, R. Lanphier Page 7 321 Presentation description: 322 A presentation description contains information about one or 323 more media streams within a presentation, such as the set of 324 encodings, network addresses and information about the content. 325 Other IETF protocols such as SDP [6] use the term ``session'' 326 for a live presentation. The presentation description may take 327 several different formats, including but not limited to the 328 session description format SDP. 330 Response: 331 An RTSP response. If an HTTP response is meant, that is 332 indicated explicitly. 334 Request: 335 An RTSP request. If an HTTP request is meant, that is indicated 336 explicitly. 338 RTSP session: 339 A complete RTSP ``transaction'', e.g., the viewing of a movie. 340 A session typically consists of a client setting up a transport 341 mechanism for the continuous media stream (SETUP), starting the 342 stream with PLAY or RECORD and closing the stream with 343 TEARDOWN. 345 1.4 Protocol Properties 347 RTSP has the following properties: 349 Extendable: 350 New methods and parameters can be easily added to RTSP. 352 Easy to parse: 353 RTSP can be parsed by standard HTTP or MIME parsers. 355 Secure: 356 RTSP re-uses web security mechanisms, either at the transport 357 level (TLS [7]) or within the protocol itself. All HTTP 358 authentication mechanisms such as basic [5, Section 11.1] and 359 digest authentication [8] are directly applicable. 361 Transport-independent: 362 RTSP may use either an unreliable datagram protocol (UDP) [9], 363 a reliable datagram protocol (RDP, not widely used [10]) or a 364 reliable stream protocol such as TCP [11] as it implements 365 application-level reliability. 367 H. Schulzrinne, A. Rao, R. Lanphier Page 8 368 Multi-server capable: 369 Each media stream within a presentation can reside on a 370 different server. The client automatically establishes several 371 concurrent control sessions with the different media servers. 372 Media synchronization is performed at the transport level. 374 Control of recording devices: 375 The protocol can control both recording and playback devices, 376 as well as devices that can alternate between the two modes 377 (``VCR''). 379 Separation of stream control and conference initiation: 380 Stream control is divorced from inviting a media server to a 381 conference. The only requirement is that the conference 382 initiation protocol either provides or can be used to create a 383 unique conference identifier. In particular, SIP [12] or H.323 384 may be used to invite a server to a conference. 386 Suitable for professional applications: 387 RTSP supports frame-level accuracy through SMPTE time stamps to 388 allow remote digital editing. 390 Presentation description neutral: 391 The protocol does not impose a particular presentation 392 description or metafile format and can convey the type of 393 format to be used. However, the presentation description must 394 contain at least one RTSP URI. 396 Proxy and firewall friendly: 397 The protocol should be readily handled by both application and 398 transport-layer (SOCKS [13]) firewalls. A firewall may need to 399 understand the SETUP method to open a ``hole'' for the UDP 400 media stream. 402 HTTP-friendly: 403 Where sensible, RTSP re-uses HTTP concepts, so that the 404 existing infrastructure can be re-used. This infrastructure 405 includes PICS (Platform for Internet Content Selection [20]) 406 for associating labels with content. However, RTSP does not 407 just add methods to HTTP, since the controlling continuous 408 media requires server state in most cases. 410 Appropriate server control: 411 If a client can start a stream, it must be able to stop a 412 stream. Servers should not start streaming to clients in such a 413 way that clients cannot stop the stream. 415 H. Schulzrinne, A. Rao, R. Lanphier Page 9 416 Transport negotiation: 417 The client can negotiate the transport method prior to actually 418 needing to process a continuous media stream. 420 Capability negotiation: 421 If basic features are disabled, there must be some clean 422 mechanism for the client to determine which methods are not 423 going to be implemented. This allows clients to present the 424 appropriate user interface. For example, if seeking is not 425 allowed, the user interface must be able to disallow moving a 426 sliding position indicator. 428 An earlier requirement in RTSP was multi-client capability. 429 However, it was determined that a better approach was to make sure 430 that the protocol is easily extensible to the multi-client 431 scenario. Stream identifiers can be used by several control 432 streams, so that ``passing the remote'' would be possible. The 433 protocol would not address how several clients negotiate access; 434 this is left to either a ``social protocol'' or some other floor 435 control mechanism. 437 1.5 Extending RTSP 439 Since not all media servers have the same functionality, media servers 440 by necessity will support different sets of requests. For example: 441 * A server may only be capable of playback, not recording and thus 442 has no need to support the RECORD request. 443 * A server may not be capable of seeking (absolute positioning), 444 say, if it is to support live events only. 445 * Some servers may not support setting stream parameters and thus 446 not support GET_PARAMETER and SET_PARAMETER. 448 A server SHOULD implement all header fields described in Section 12. 450 It is up to the creators of presentation descriptions not to ask the 451 impossible of a server. This situation is similar in HTTP/1.1, where 452 the methods described in [H19.6] are not likely to be supported across 453 all servers. 455 RTSP can be extended in three ways, listed in order of the magnitude 456 of changes supported: 458 * Existing methods can be extended with new parameters, as long as 459 these parameters can be safely ignored by the recipient. (This is 460 equivalent to adding new parameters to an HTML tag.) 461 * New methods can be added. If the recipient of the message does not 462 understand the request, it responds with error code 501 (Not 463 implemented) and the sender should not attempt to use this method 464 again. A client may also use the OPTIONS method to inquire about 465 methods supported by the server. The server SHOULD list the 466 methods it supports using the Public response header. 467 * A new version of the protocol can be defined, allowing almost all 468 aspects (except the position of the protocol version number) to 469 change. 471 1.6 Overall Operation 473 Each presentation and media stream may be identified by an RTSP URL. 474 The overall presentation and the properties of the media the 475 presentation is made up of are defined by a presentation description 476 file, the format of which is outside the scope of this specification. 477 The presentation description file may be obtained by the client using 478 HTTP or other means such as email and may not necessarily be stored on 479 the media server. 481 For the purposes of this specification, a presentation description is 482 assumed to describe one or more presentations, each of which maintains 483 a common time axis. For simplicity of exposition and without loss of 484 generality, it is assumed that the presentation description contains 485 exactly one such presentation. A presentation may contain several 486 media streams. 488 The presentation description file contains a description of the media 489 streams making up the presentation, including their encodings, 490 language, and other parameters that enable the client to choose the 491 most appropriate combination of media. In this presentation 492 description, each media stream that is individually controllable by 493 RTSP is identified by an RTSP URL, which points to the media server 494 handling that particular media stream and names the stream stored on 495 that server. Several media streams can be located on different 496 servers; for example, audio and video streams can be split across 497 servers for load sharing. The description also enumerates which 498 transport methods the server is capable of. 500 Besides the media parameters, the network destination address and port 501 need to be determined. Several modes of operation can be 502 distinguished: 504 Unicast: 505 The media is transmitted to the source of the RTSP request, 506 with the port number chosen by the client. Alternatively, the 507 media is transmitted on the same reliable stream as RTSP. 509 Multicast, server chooses address: 510 The media server picks the multicast address and port. This is 511 the typical case for a live or near-media-on-demand 512 transmission. 514 Multicast, client chooses address: 515 If the server is to participate in an existing multicast 516 conference, the multicast address, port and encryption key are 517 given by the conference description, established by means 518 outside the scope of this specification. 520 1.7 RTSP States 522 RTSP controls a stream which may be sent via a separate protocol, 523 independent of the control channel. For example, RTSP control may 524 occur on a TCP connection while the data flows via UDP. Thus, data 525 delivery continues even if no RTSP requests are received by the media 526 server. Also, during its lifetime, a single media stream may be 527 controlled by RTSP requests issued sequentially on different TCP 528 connections. Therefore, the server needs to maintain ``session state'' 529 to be able to correlate RTSP requests with a stream. The state 530 transitions are described in Section A. 532 Many methods in RTSP do not contribute to state. However, the 533 following play a central role in defining the allocation and usage of 534 stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and 535 TEARDOWN. 537 SETUP: 538 Causes the server to allocate resources for a stream and start 539 an RTSP session. 541 PLAY and RECORD: 542 Starts data transmission on a stream allocated via SETUP. 544 PAUSE: 545 Temporarily halts a stream, without freeing server resources. 547 TEARDOWN: 548 Frees resources associated with the stream. The RTSP session 549 ceases to exist on the server. 551 1.8 Relationship with Other Protocols 553 RTSP has some overlap in functionality with HTTP. It also may interact 554 with HTTP in that the initial contact with streaming content is often 555 to be made through a web page. The current protocol specification aims 556 to allow different hand-off points between a web server and the media 557 server implementing RTSP. For example, the presentation description 558 can be retrieved using HTTP or RTSP. Having the presentation 559 description be returned by the web server makes it possible to have 560 the web server take care of authentication and billing, by handing out 561 a presentation description whose media identifier includes an 562 encrypted version of the requestor's IP address and a timestamp, with 563 a shared secret between web and media server. 565 However, RTSP differs fundamentally from HTTP in that data delivery 566 takes place out-of-band, in a different protocol. HTTP is an 567 asymmetric protocol, where the client issues requests and the server 568 responds. In RTSP, both the media client and media server can issue 569 requests. RTSP requests are also not stateless, in that they may set 570 parameters and continue to control a media stream long after the 571 request has been acknowledged. 573 Re-using HTTP functionality has advantages in at least two areas, 574 namely security and proxies. The requirements are very similar, so 575 having the ability to adopt HTTP work on caches, proxies and 576 authentication is valuable. 578 While most real-time media will use RTP as a transport protocol, RTSP 579 is not tied to RTP. 581 RTSP assumes the existence of a presentation description format that 582 can express both static and temporal properties of a presentation 583 containing several media streams. 585 2 Notational Conventions 587 Since many of the definitions and syntax are identical to HTTP/1.1, 588 this specification only points to the section where they are defined 589 rather than copying it. For brevity, [HX.Y] is to be taken to refer to 590 Section X.Y of the current HTTP/1.1 specification (RFC 2068). 592 All the mechanisms specified in this document are described in both 593 prose and an augmented Backus-Naur form (BNF) similar to that used in 594 RFC 2068 [H2.1]. It is described in detail in [14]. 596 In this draft, we use indented and smaller-type paragraphs to provide 597 background and motivation. Some of these paragraphs are marked with 598 HS, AR and RL, designating opinions and comments by the individual 599 authors which may not be shared by the co-authors and require 600 resolution. 602 3 Protocol Parameters 604 3.1 RTSP Version 606 [H3.1] applies, with HTTP replaced by RTSP. 608 3.2 RTSP URL 610 The ``rtsp'', ``rtspu'' and ``rtsps'' schemes are used to refer to 611 network resources via the RTSP protocol. This section defines the 612 scheme-specific syntax and semantics for RTSP URLs. 614 rtsp_URL = ( "rtsp:" | "rtspu:" | "rtsps:" ) 615 "//" host [ ":" port ] [abs_path] 616 host = 619 port = *DIGIT 621 abs_path is defined in [H3.2.1]. 623 Note that fragment and query identifiers do not have a well-defined 624 meaning at this time, with the interpretation left to the RTSP 625 server. 627 The scheme rtsp requires that commands are issued via a reliable 628 protocol (within the Internet, TCP), while the scheme rtspu identifies 629 an unreliable protocol (within the Internet, UDP). The scheme rtsps 630 indicates that a TCP connection secured by TLS [7] must be used. 632 If the port is empty or not given, port 554 is assumed. The semantics 633 are that the identified resource can be controlled be RTSP at the 634 server listening for TCP (scheme ``rtsp'') connections or UDP (scheme 635 ``rtspu'') packets on that port of host, and the Request-URI for the 636 resource is rtsp_URL. 638 The use of IP addresses in URLs SHOULD be avoided whenever possible 639 (see RFC 1924 [15]). 641 A presentation or a stream is identified by an textual media 642 identifier, using the character set and escape conventions [H3.2] of 643 URLs [16]. URLs may refer to a stream or an aggregate of streams ie. a 644 presentation. Accordingly, requests described in Section 10 can apply 645 to either the whole presentation or an individual stream within the 646 presentation. Note that some request methods can only be applied to 647 streams, not presentations and vice versa. 649 For example, the RTSP URL 650 rtsp://media.example.com:554/twister/audiotrack 652 identifies the audio stream within the presentation ``twister'', which 653 can be controlled via RTSP requests issued over a TCP connection to 654 port 554 of host media.example.com. 656 Also, the RTSP URL 657 rtsp://media.example.com:554/twister 659 identifies the presentation ``twister'', which may be composed of 660 audio and video streams. 662 This does not imply a standard way to reference streams in URLs. 663 The presentation description defines the hierarchical relationships 664 in the presentation and the URLs for the individual streams. A 665 presentation description may name a stream 'a.mov' and the whole 666 presentation 'b.mov'. 668 The path components of the RTSP URL are opaque to the client and do 669 not imply any particular file system structure for the server. 671 This decoupling also allows presentation descriptions to be used 672 with non-RTSP media control protocols, simply by replacing the 673 scheme in the URL. 675 3.3 Conference Identifiers 677 Conference identifiers are opaque to RTSP and are encoded using 678 standard URI encoding methods (i.e., LWS is escaped with %). They can 679 contain any octet value. The conference identifier MUST be globally 680 unique. For H.323, the conferenceID value is to be used. 682 conference-id = 1*OCTET ; LWS must be URL-escaped 684 Conference identifiers are used to allow to allow RTSP sessions to 685 obtain parameters from multimedia conferences the media server is 686 participating in. These conferences are created by protocols 687 outside the scope of this specification, e.g., H.323 [17] or SIP 688 [12]. Instead of the RTSP client explicitly providing transport 689 information, for example, it asks the media server to use the 690 values in the conference description instead. If the conference 691 participant inviting the media server would only supply a 692 conference identifier which is unique for that inviting party, the 693 media server could add an internal identifier for that party, e.g., 694 its Internet address. However, this would prevent that the 695 conference participant and the initiator of the RTSP commands are 696 two different entities. 698 3.4 Session Identifiers 700 Session identifiers are opaque strings of arbitrary length. Linear 701 white space must be URL-escaped. A session identifier SHOULD be chosen 702 randomly and SHOULD be at least eight octets long to make guessing it 703 more difficult. (See Section 16). 705 session-id = 1*OCTET ; LWS must be URL-escaped 707 3.5 SMPTE Relative Timestamps 709 A SMPTE relative time-stamp expresses time relative to the start of 710 the clip. Relative timestamps are expressed as SMPTE time codes for 711 frame-level access accuracy. The time code has the format 712 hours:minutes:seconds:frames.subframes, with the origin at the start 713 of the clip. For NTSC, the frame rate is 29.97 frames per second. This 714 is handled by dropping the first two frame indices (values 00 and 01) 715 of every minute, except every tenth minute. If the frame value is 716 zero, it may be omitted. Subframes are measured in one-hundredth of a 717 frame. 719 smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ] 720 smpte-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT ] [ "." 2DIGIT] 722 Examples: 723 smpte=10:12:33:20- 724 smpte=10:07:33- 725 smpte=10:07:00-10:07:33:05.01 727 3.6 Normal Play Time 729 Normal play time (NPT) indicates the stream absolute position relative 730 to the beginning of the presentation, measured in seconds and 731 microseconds. The beginning of a presentation corresponds to 0 seconds 732 and 0 microseconds. Negative values are not defined. The microsecond 733 field is always less than 1,000,000. NPT is defined as in DSM-CC [18]: 734 ``Intuitively, NPT is the clock the viewer associates with a program. 735 It is often digitally displayed on a VCR. NPT advances normally when 736 in normal play mode (scale = 1), advances at a faster rate when in 737 fast scan forward (high positive scale ratio), decrements when in scan 738 reverse (high negative scale ratio) and is fixed in pause mode. NPT is 739 (logically) equivalent to SMPTE time codes.'' [18] 741 npt-range = "npt" "=" npt-time "-" [ npt-time ] 742 npt-time = 1*DIGIT [ ":" *DIGIT ] 744 Examples: 745 npt=123:45-125 747 3.7 Absolute Time 749 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 750 Fractions of a second may be indicated. 752 utc-range = "clock" "=" utc-time "-" [ utc-time ] 753 utc-time = utc-date "T" utc-time "Z" 754 utc-date = 8DIGIT ; < YYYYMMDD > 755 utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > 757 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 758 UTC: 760 19961108T143720.25Z 762 Example 764 4 RTSP Message 766 RTSP is a text-based protocol and uses the ISO 10646 character set 767 in UTF-8 encoding (RFC 2044). Lines are terminated by CRLF, but 768 receivers should be prepared to also interpret CR and LF by themselves 769 as line terminators. 771 Text-based protocols make it easier to add optional parameters in a 772 self-describing manner. Since the number of parameters and the 773 frequency of commands is low, processing efficiency is not a 774 concern. Text-based protocols, if done carefully, also allow easy 775 implementation of research prototypes in scripting languages such 776 as Tcl, Visual Basic and Perl. 778 The 10646 character set avoids tricky character set switching, but 779 is invisible to the application as long as US-ASCII is being used. 780 This is also the encoding used for RTCP. ISO 8859-1 translates 781 directly into Unicode, with a high-order octet of zero. ISO 8859-1 782 characters with the most-significant bit set are represented as 783 1100001x 10xxxxxx. 785 RTSP messages can be carried over any lower-layer transport protocol 786 that is 8-bit clean. 788 Requests contain methods, the object the method is operating upon and 789 parameters to further describe the method. Methods are idempotent, 790 unless otherwise noted. Methods are also designed to require little or 791 no state maintenance at the media server. 793 4.1 Message Types 795 See [H4.1] 797 4.2 Message Headers 799 See [H4.2] 801 4.3 Message Body 803 See [H4.3] 805 4.4 Message Length 807 When a message-body is included with a message, the length of that 808 body is determined by one of the following (in order of precedence): 810 1. 811 Any response message which MUST NOT include a message-body 812 (such as the 1xx, 204, and 304 responses) is always terminated 813 by the first empty line after the header fields, regardless of 814 the entity-header fields present in the message. (Note: An 815 empty line consists of only CRLF.) 816 2. 817 If a Content-Length header field (section 12.15) is present, 818 its value in bytes represents the length of the message-body. 819 If this header field is not present, a value of zero is 820 assumed. 821 3. 822 By the server closing the connection. (Closing the connection 823 cannot be used to indicate the end of a request body, since 824 that would leave no possibility for the server to send back a 825 response.) 827 Note that RTSP does not (at present) support the HTTP/1.1 ``chunked'' 828 transfer coding(see [H3.6]) and requires the presence of the 829 Content-Length header field. 831 Given the moderate length of presentation descriptions returned, 832 the server should always be able to determine its length, even if 833 it is generated dynamically, making the chunked transfer encoding 834 unnecessary. Even though Content-Length must be present if there is 835 any entity body, the rules ensure reasonable behavior even if the 836 length is not given explicitly. 838 5 General Header Fields 840 See [H4.5], except that Pragma, Transfer-Encoding and Upgrade 841 headers are not defined: 843 general-header = Cache-Control ; Section 12.10 844 | Connection ; Section 12.12 845 | Date ; Section 12.17 846 | Via ; Section 12.39 848 6 Request 850 A request message from a client to a server or vice versa includes, 851 within the first line of that message, the method to be applied to the 852 resource, the identifier of the resource, and the protocol version in 853 use. 855 Request = Request-Line ; Section 6.1 856 *( general-header ; Section 5 857 | request-header ; Section 6.2 858 | entity-header ) ; Section 8.1 859 CRLF 860 [ message-body ] ; Section 4.3 862 6.1 Request Line 864 Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF 866 Method = "DESCRIBE" ; Section 10.2 867 | "ANNOUNCE" ; Section 10.3 868 | "GET_PARAMETER" ; Section 10.8 869 | "OPTIONS" ; Section 10.1 870 | "PAUSE" ; Section 10.6 871 | "PLAY" ; Section 10.5 872 | "RECORD" ; Section 10.11 873 | "REDIRECT" ; Section 10.10 874 | "SETUP" ; Section 10.4 875 | "SET_PARAMETER" ; Section 10.9 876 | "TEARDOWN" ; Section 10.7 877 | extension-method 879 extension-method = token 881 Request-URI = "*" | absolute_URI 883 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 885 seq-no = 1*DIGIT 887 6.2 Request Header Fields 889 request-header = Accept ; Section 12.1 890 | Accept-Encoding ; Section 12.2 891 | Accept-Language ; Section 12.3 892 | Authorization ; Section 12.5 893 | From ; Section 12.19 894 | If-Modified-Since ; Section 12.21 895 | Range ; Section 12.28 896 | Referer ; Section 12.29 897 | User-Agent ; Section 12.37 899 Note that in contrast to HTTP/1.1, RTSP requests always contain the 900 absolute URL (that is, including the scheme, host and port) rather 901 than just the absolute path. 903 HTTP/1.1 requires servers to understand the absolute URL, but 904 clients are supposed to use the Host request header. This is purely 905 needed for backward-compatibility with HTTP/1.0 servers, a 906 consideration that does not apply to RTSP. 908 The asterisk "*" in the Request-URI means that the request does not 909 apply to a particular resource, but to the server itself, and is only 910 allowed when the method used does not necessarily apply to a resource. 911 One example would be 913 OPTIONS * RTSP/1.0 915 7 Response 917 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 918 Also, RTSP defines additional status codes and does not define some 919 HTTP codes. The valid response codes and the methods they can be used 920 with are defined in the table 1. 922 After receiving and interpreting a request message, the recipient 923 responds with an RTSP response message. 925 Response = Status-Line ; Section 7.1 926 *( general-header ; Section 5 927 | response-header ; Section 7.1.2 928 | entity-header ) ; Section 8.1 929 CRLF 930 [ message-body ] ; Section 4.3 932 7.1 Status-Line 934 The first line of a Response message is the Status-Line, consisting 935 of the protocol version followed by a numeric status code, the 936 sequence number of the corresponding request and the textual phrase 937 associated with the status code, with each element separated by SP 938 characters. No CR or LF is allowed except in the final CRLF sequence. 940 Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF 942 7.1.1 Status Code and Reason Phrase 944 The Status-Code element is a 3-digit integer result code of the 945 attempt to understand and satisfy the request. These codes are fully 946 defined in section11. The Reason-Phrase is intended to give a short 947 textual description of the Status-Code. The Status-Code is intended 948 for use by automata and the Reason-Phrase is intended for the human 949 user. The client is not required to examine or display the 950 Reason-Phrase. 952 The first digit of the Status-Code defines the class of response. The 953 last two digits do not have any categorization role. There are 5 954 values for the first digit: 956 * 1xx: Informational - Request received, continuing process 957 * 2xx: Success - The action was successfully received, understood, 958 and accepted 959 * 3xx: Redirection - Further action must be taken in order to 960 complete the request 961 * 4xx: Client Error - The request contains bad syntax or cannot be 962 fulfilled 963 * 5xx: Server Error - The server failed to fulfill an apparently 964 valid request 966 The individual values of the numeric status codes defined for 967 RTSP/1.0, and an example set of corresponding Reason-Phrase's, are 968 presented below. The reason phrases listed here are only recommended - 969 they may be replaced by local equivalents without affecting the 970 protocol. Note that RTSP adopts most HTTP/1.1 status codes and adds 971 RTSP-specific status codes in the starting at 450 to avoid conflicts 972 with newly defined HTTP status codes. 974 Status-Code = "100" ; Continue 975 | "200" ; OK 976 | "201" ; Created 977 | "300" ; Multiple Choices 978 | "301" ; Moved Permanently 979 | "302" ; Moved Temporarily 980 | "303" ; See Other 981 | "304" ; Not Modified 982 | "305" ; Use Proxy 983 | "400" ; Bad Request 984 | "401" ; Unauthorized 985 | "402" ; Payment Required 986 | "403" ; Forbidden 987 | "404" ; Not Found 988 | "405" ; Method Not Allowed 989 | "406" ; Not Acceptable 990 | "407" ; Proxy Authentication Required 991 | "408" ; Request Time-out 992 | "409" ; Conflict 993 | "410" ; Gone 994 | "411" ; Length Required 995 | "412" ; Precondition Failed 996 | "413" ; Request Entity Too Large 997 | "414" ; Request-URI Too Large 998 | "415" ; Unsupported Media Type 999 | "451" ; Parameter Not Understood 1000 | "452" ; Conference Not Found 1001 | "453" ; Not Enough Bandwidth 1002 | "45x" ; Session Not Found 1003 | "45x" ; Method Not Valid in This State 1004 | "45x" ; Header Field Not Valid for Resource 1005 | "45x" ; Invalid Range 1006 | "45x" ; Parameter Is Read-Only 1007 | "45x" ; Aggregate operation not allowed 1008 | "45x" ; Only aggregate operation allowed 1009 | "500" ; Internal Server Error 1010 | "501" ; Not Implemented 1011 | "502" ; Bad Gateway 1012 | "503" ; Service Unavailable 1013 | "504" ; Gateway Time-out 1014 | "505" ; RTSP Version not supported 1015 | extension-code 1017 extension-code = 3DIGIT 1019 Reason-Phrase = * 1021 RTSP status codes are extensible. RTSP applications are not required 1022 to understand the meaning of all registered status codes, though such 1023 understanding is obviously desirable. However, applications MUST 1024 understand the class of any status code, as indicated by the first 1025 digit, and treat any unrecognized response as being equivalent to the 1026 x00 status code of that class, with the exception that an unrecognized 1027 response MUST NOT be cached. For example, if an unrecognized status 1028 code of 431 is received by the client, it can safely assume that there 1029 was something wrong with its request and treat the response as if it 1030 had received a 400 status code. In such cases, user agents SHOULD 1031 present to the user the entity returned with the response, since that 1032 entity is likely to include human-readable information which will 1033 explain the unusual status. 1035 Code Reason 1036 100 Continue all 1037 200 OK all 1038 201 Created RECORD 1039 300 Multiple Choices all 1040 301 Moved Permanently all 1041 302 Moved Temporarily all 1042 303 See Other all 1043 305 Use Proxy all 1044 400 Bad Request all 1045 401 Unauthorized all 1046 402 Payment Required all 1047 403 Forbidden all 1048 404 Not Found all 1049 405 Method Not Allowed all 1050 406 Not Acceptable all 1051 407 Proxy Authentication Required all 1052 408 Request Timeout all 1053 409 Conflict RECORD 1054 410 Gone all 1055 411 Length Required SETUP 1056 412 Precondition Failed DESCRIBE, SETUP 1057 413 Request Entity Too Large SETUP 1058 414 Request-URI Too Long all 1059 415 Unsupported Media Type SETUP 1060 45x Session not found all 1061 45x Invalid parameter SETUP 1062 45x Not Enough Bandwidth SETUP 1063 45x Illegal Conference Identifier SETUP 1064 45x Illegal Session Identifier PLAY, RECORD, TEARDOWN 1065 45x Parameter Is Read-Only SET_PARAMETER 1066 45x Header Field Not Valid all 1067 45x Method Not Valid In This State all 1068 45x Aggregate operation not allowed all 1069 45x Only aggregate operation allowed all 1070 500 Internal Server Error all 1071 501 Not Implemented all 1072 502 Bad Gateway all 1073 503 Service Unavailable all 1074 504 Gateway Timeout all 1075 505 RTSP Version Not Supported all 1076 ! 1077 Table 1: Status codes and their usage with RTSP methods 1079 7.1.2 Response Header Fields 1081 The response-header fields allow the request recipient to pass 1082 additional information about the response which cannot be placed in 1083 the Status-Line. These header fields give information about the server 1084 and about further access to the resource identified by the 1085 Request-URI. 1087 response-header = Location ; Section 12.23 1088 | Proxy-Authenticate ; Section 12.26 1089 | Public ; Section 12.27 1090 | Retry-After ; Section 12.30 1091 | Server ; Section 12.33 1092 | Vary ; Section 12.38 1093 | WWW-Authenticate ; Section 12.40 1095 Response-header field names can be extended reliably only in 1096 combination with a change in the protocol version. However, new or 1097 experimental header fields MAY be given the semantics of 1098 response-header fields if all parties in the communication recognize 1099 them to be response-header fields. Unrecognized header fields are 1100 treated as entity-header fields. 1102 8 Entity 1104 Request and Response messages MAY transfer an entity if not 1105 otherwise restricted by the request method or response status code. An 1106 entity consists of entity-header fields and an entity-body, although 1107 some responses will only include the entity-headers. 1109 In this section, both sender and recipient refer to either the client 1110 or the server, depending on who sends and who receives the entity. 1112 8.1 Entity Header Fields 1114 Entity-header fields define optional metainformation about the 1115 entity-body or, if no body is present, about the resource identified 1116 by the request. 1118 entity-header = Allow ; Section 12.4 1119 | Content-Encoding ; Section 12.13 1120 | Content-Language ; Section 12.14 1121 | Content-Length ; Section 12.15 1122 | Content-Type ; Section 12.16 1123 | Expires ; Section 12.18 1124 | Last-Modified ; Section 12.22 1125 | extension-header 1126 extension-header = message-header 1128 The extension-header mechanism allows additional entity-header fields 1129 to be defined without changing the protocol, but these fields cannot 1130 be assumed to be recognizable by the recipient. Unrecognized header 1131 fields SHOULD be ignored by the recipient and forwarded by proxies. 1133 8.2 Entity Body 1135 See [H7.2] 1137 9 Connections 1139 RTSP requests can be transmitted in several different ways: 1141 * persistent transport connections used for several request-response 1142 transactions; 1143 * one connection per request/response transaction; 1144 * connectionless mode. 1146 The type of transport connection is defined by the RTSP URI 1147 (Section 3.2). For the scheme ``rtsp'', a persistent connection is 1148 assumed, while the scheme ``rtspu'' calls for RTSP requests to be send 1149 without setting up a connection. 1151 Unlike HTTP, RTSP allows the media server to send requests to the 1152 media client. However, this is only supported for persistent 1153 connections, as the media server otherwise has no reliable way of 1154 reaching the client. Also, this is the only way that requests from 1155 media server to client are likely to traverse firewalls. 1157 9.1 Pipelining 1159 A client that supports persistent connections or connectionless mode 1160 MAY ``pipeline'' its requests (i.e., send multiple requests without 1161 waiting for each response). A server MUST send its responses to those 1162 requests in the same order that the requests were received. 1164 9.2 Reliability and Acknowledgements 1166 Requests are acknowledged by the receiver unless they are sent to a 1167 multicast group. If there is no acknowledgement, the sender may resend 1168 the same message after a timeout of one round-trip time (RTT). The 1169 round-trip time is estimated as in TCP (RFC TBD), with an initial 1170 round-trip value of 500 ms. An implementation MAY cache the last RTT 1171 measurement as the initial value for future connections. If a reliable 1172 transport protocol is used to carry RTSP, the timeout value MAY be set 1173 to an arbitrarily large value. 1175 This can greatly increase responsiveness for proxies operating in 1176 local-area networks with small RTTs. The mechanism is defined such 1177 that the client implementation does not have be aware of whether a 1178 reliable or unreliable transport protocol is being used. It is 1179 probably a bad idea to have two reliability mechanisms on top of 1180 each other, although the RTSP RTT estimate is likely to be larger 1181 than the TCP estimate. 1183 Each request carries a sequence number, which is incremented by one 1184 for each request transmitted. If a request is repeated because of lack 1185 of acknowledgement, the sequence number is incremented. 1187 This avoids ambiguities when computing round-trip time estimates. 1189 [TBD: An initial sequence number negotiation needs to be added for 1190 UDP; otherwise, a new stream connection may see a request be 1191 acknowledged by a delayed response from an earlier ``connection''. 1192 This handshake can be avoided with a sequence number containing a 1193 timestamp of sufficiently high resolution.] 1195 The reliability mechanism described here does not protect against 1196 reordering. This may cause problems in some instances. For example, a 1197 TEARDOWN followed by a PLAY has quite a different effect than the 1198 reverse. Similarly, if a PLAY request arrives before all parameters 1199 are set due to reordering, the media server would have to issue an 1200 error indication. Since sequence numbers for retransmissions are 1201 incremented (to allow easy RTT estimation), the receiver cannot just 1202 ignore out-of-order packets. [TBD: This problem could be fixed by 1203 including both a sequence number that stays the same for 1204 retransmissions and a timestamp for RTT estimation.] 1206 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1207 support UDP. The default port for the RTSP server is 554 for both UDP 1208 and TCP. 1210 A number of RTSP packets destined for the same control end point may 1211 be packed into a single lower-layer PDU or encapsulated into a TCP 1212 stream. RTSP data MAY be interleaved with RTP and RTCP packets. Unlike 1213 HTTP, an RTSP message MUST contain a Content-Length header whenever 1214 that message contains a payload. Otherwise, an RTSP packet is 1215 terminated with an empty line immediately following the last message 1216 header. 1218 10 Method Definitions 1220 The method token indicates the method to be performed on the 1221 resource identified by the Request-URI. The method is case-sensitive. 1222 New methods may be defined in the future. Method names may not start 1223 with a $ character (decimal 24) and must be a token. Methods are 1224 summarized in Table 2. 1226 method direction object requirement 1227 DESCRIBE C->S P,S recommended 1228 ANNOUNCE C->S, S->C P,S optional 1229 GET_PARAMETER C->S, S->C P,S optional 1230 OPTIONS C->S P,S required 1231 PAUSE C->S P,S recommended 1232 PLAY C->S P,S required 1233 RECORD C->S P,S optional 1234 REDIRECT S->C P,S optional 1235 SETUP C->S S required 1236 SET_PARAMETER C->S, S->C P,S optional 1237 TEARDOWN C->S P,S required 1238 ! 1239 Table 2: Overview of RTSP methods, their direction, and what objects (P: 1240 presentation, S: stream) they operate on 1242 Notes on Table 2: PAUSE is recommended, but not required in that a 1243 fully functional server can be built that does not support this 1244 method, for example, for live feeds. If a server does not support a 1245 particular method, it MUST return "501 Not Implemented" and a client 1246 SHOULD not try this method again for this server. 1248 10.1 OPTIONS 1250 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1251 request may be issued at any time, e.g., if the client is about to try 1252 a non-standard request. It does not influence server state. 1254 Example : 1255 C->S: OPTIONS * RTSP/1.0 1 1256 PEP: {{map "http://www.iana.org/rtsp/implicit-play"}} 1257 {{map "http://www.iana.org/rtsp/record-feature"}} 1258 C-PEP: {{map "http://www.iana.org/rtsp/udp-control"}} 1259 {{map "http://www.iana.org/rtsp/gzipped-messages"}} 1261 S->C: RTSP/1.0 200 2 OK 1262 PEP-Info: {{map "http://www.iana.org/rtsp/implicit-play"} 1263 {for "/" *}} 1264 {{map "http://www.iana.org/rtsp/record-feature"} 1265 {for "/" *}} 1266 C-PEP-Info: {{map "http://www.iana.org/rtsp/udp-control"} 1267 {for "/" *}} 1268 {{map "http://www.iana.org/rtsp/gzipped-messages"} 1269 {for "/" *}} 1270 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1272 Note that these are fictional features (though we may want to make 1273 them real one day). 1275 DESCRIBE 1277 The DESCRIBE method retrieves the description of a presentation or 1278 media object identified by the request URL from a server. It may use 1279 the Accept header to specify the description formats that the client 1280 understands. The server responds with a description of the requested 1281 resource. 1283 Example: 1285 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 312 1286 Accept: application/sdp, application/rtsl, application/mheg 1288 S->C: RTSP/1.0 200 312 OK 1289 Date: 23 Jan 1997 15:35:06 GMT 1290 Content-Type: application/sdp 1291 Content-Length: 376 1292 v=0 1293 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1294 s=SDP Seminar 1295 i=A Seminar on the session description protocol 1296 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1297 e=mjh@isi.edu (Mark Handley) 1298 c=IN IP4 224.2.17.12/127 1299 t=2873397496 2873404696 1300 a=recvonly 1301 m=audio 3456 RTP/AVP 0 1302 m=video 2232 RTP/AVP 31 1303 m=whiteboard 32416 UDP WB 1304 a=orient:portrait 1306 ANNOUNCE 1308 The ANNOUNCE method serves two purposes: 1310 When sent from client to server, ANNOUNCE posts the description of a 1311 presentation or media object identified by the request URL to a 1312 server. 1314 When sent from server to client, ANNOUNCE updates the session 1315 description in real-time. 1317 If a new media stream is added to a presentation (e.g., during a live 1318 presentation), the whole presentation description should be sent 1319 again, rather than just the additional components, so that components 1320 can be deleted. 1322 Example: 1324 C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0 312 1325 Date: 23 Jan 1997 15:35:06 GMT 1326 Content-Type: application/sdp 1327 Content-Length: 332 1328 v=0 1329 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 1330 s=SDP Seminar 1331 i=A Seminar on the session description protocol 1332 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1333 e=mjh@isi.edu (Mark Handley) 1334 c=IN IP4 224.2.17.12/127 1335 t=2873397496 2873404696 1336 a=recvonly 1337 m=audio 3456 RTP/AVP 0 1338 m=video 2232 RTP/AVP 31 1340 S->C: RTSP/1.0 200 312 OK 1342 SETUP 1344 The SETUP request for a URI specifies the transport mechanism to be 1345 used for the streamed media. A client can issue a SETUP request for a 1346 stream that is already playing to change transport parameters, which a 1347 server MAY allow(If it does not allow it, it must respond with error 1348 ``45x Method not valid in this state'' ). For the benefit of any 1349 intervening firewalls, a client must indicate the transport parameters 1350 even if it has no influence over these parameters, for example, where 1351 the server advertises a fixed multicast address. 1353 Segregating content desciption into a DESCRIBE message and 1354 transport information in SETUP avoids having firewall to parse 1355 numerous different presentation description formats for information 1356 which is irrelevant to transport. 1358 The Transport header specifies the transport parameters acceptable to 1359 the client for data transmission; the response will contain the 1360 transport parameters selected by the server. 1362 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 302 1363 Transport: RTP/AVP;port=4588 1365 S->C: RTSP/1.0 200 302 OK 1366 Date: 23 Jan 1997 15:35:06 GMT 1367 Transport: RTP/AVP;port=4588 1369 PLAY 1371 The PLAY method tells the server to start sending data via the 1372 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 1373 until any outstanding SETUP requests have been acknowledged as 1374 successful. 1376 The PLAY request positions the normal play time to the beginning of 1377 the range specified and delivers stream data until the end of the 1378 range is reached. PLAY requests may be pipelined (queued); a server 1379 MUST queue PLAY requests to be executed in order. That is, a PLAY 1380 request arriving while a previous PLAY request is still active is 1381 delayed until the first has been completed. 1383 This allows precise editing. 1385 For example, regardless of how closely spaced the two PLAY commands in 1386 the example below arrive, the server will play first second 10 through 1387 15 and then, immediately following, seconds 20 to 25 and finally 1388 seconds 30 through the end. 1390 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 835 1391 Range: npt=10-15 1393 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 836 1394 Range: npt=20-25 1396 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 837 1397 Range: npt=30- 1399 See the description of the PAUSE request for further examples. 1401 A PLAY request without a Range header is legal. It starts playing a 1402 stream from the beginning unless the stream has been paused. If a 1403 stream has been paused via PAUSE, stream delivery resumes at the pause 1404 point. If a stream is playing, such a PLAY request causes no further 1405 action and can be used by the client to test server liveness. 1407 The Range header may also contain a time parameter. This parameter 1408 specifies a time in UTC at which the playback should start. If the 1409 message is received after the specified time, playback is started 1410 immediately. The time parameter may be used to aid in synchronisation 1411 of streams obtained from different sources. 1413 For a on-demand stream, the server replies back with the actual range 1414 that will be played back. This may differ from the requested range if 1415 alignment of the requested range to valid frame boundaries is required 1416 for the media source. If no range is specified in the request, the 1417 current position is returned in the reply. The unit of the range in 1418 the reply is the same as that in the request. 1420 After playing the desired range, the presentation is automatically 1421 paused, as if a PAUSE request had been issued. 1423 The following example plays the whole presentation starting at SMPTE 1424 time code 0:10:20 until the end of the clip. The playback is to start 1425 at 15:36 on 23 Jan 1997. 1427 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833 1428 Range: smpte=0:10:20-;time=19970123T153600Z 1430 S->C: RTSP/1.0 200 833 OK 1431 Date: 23 Jan 1997 15:35:06 GMT 1432 Range: smpte=0:10:22-;time=19970123T153600Z 1434 For playing back a recording of a live presentation, it may be 1435 desirable to use clock units: 1437 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835 1438 Range: clock=19961108T142300Z-19961108T143520Z 1440 S->C: RTSP/1.0 200 833 OK 1441 Date: 23 Jan 1997 15:35:06 GMT 1443 A media server only supporting playback MUST support the npt format 1444 and MAY support the clock and smpte formats. 1446 PAUSE 1448 The PAUSE request causes the stream delivery to be interrupted 1449 (halted) temporarily. If the request URL names a stream, only playback 1450 and recording of that stream is halted. For example, for audio, this 1451 is equivalent to muting. If the request URL names a presentation or 1452 group of streams, delivery of all currently active streams within the 1453 presentation or group is halted. After resuming playback or recording, 1454 synchronization of the tracks MUST be maintained. Any server resources 1455 are kept. 1457 The PAUSE request may contain a Range header specifying when the 1458 stream or presentation is to be halted. The header must contain 1459 exactly one value rather than a time range. The normal play time for 1460 the stream is set to that value. The pause request becomes effective 1461 the first time the server is encountering the time point specified. If 1462 this header is missing, stream delivery is interrupted immediately on 1463 receipt of the message. 1465 For example, if the server has play requests for ranges 10 to 15 and 1466 20 to 29 pending and then receives a pause request for NPT 21, it 1467 would start playing the second range and stop at NPT 21. If the pause 1468 request is for NPT 12 and the server is playing at NPT 13 serving the 1469 first play request, it stops immediately. If the pause request is for 1470 NPT 16, it stops after completing the first play request and discards 1471 the second play request. 1473 As another example, if a server has received requests to play ranges 1474 10 to 15 and then 13 to 20, that is, overlapping ranges, the PAUSE 1475 request for NPT=14 would take effect while playing the first range, 1476 with the second PLAY request effectively being ignored, assuming the 1477 PAUSE request arrives before the server has started playing the 1478 second, overlapping range. Regardless of when the PAUSE request 1479 arrives, it sets the NPT to 14. 1481 If the server has already sent data beyond the time specified in the 1482 Range header, a PLAY would still resume at that point in time, as it 1483 is assumed that the client has discarded data after that point. This 1484 ensures continuous pause/play cycling without gaps. 1486 Example: 1488 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 834 1489 Session: 1234 1491 S->C: RTSP/1.0 200 834 OK 1492 Date: 23 Jan 1997 15:35:06 GMT 1494 TEARDOWN 1496 Stop the stream delivery for the given URI, freeing the resources 1497 associated with it. If the URI is the presentation URI for this 1498 presentation, any RTSP session identifier associated with the session 1499 is no longer valid. Unless all transport parameters are defined by the 1500 session description, a SETUP request has to be issued before the 1501 session can be played again. 1503 Example: 1505 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 892 1506 Session: 1234 1508 S->C: RTSP/1.0 200 892 OK 1510 GET_PARAMETER 1512 The requests retrieves the value of a parameter of a presentation or 1513 stream specified in the URI. Multiple parameters can be requested in 1514 the message body using the content type text/rtsp-parameters. Note 1515 that parameters include server and client statistics. IANA registers 1516 parameter names for statistics and other purposes. GET_PARAMETER with 1517 no entity body may be used to test client or server liveness 1518 (``ping''). 1520 Example: 1522 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 431 1523 Content-Type: text/rtsp-parameters 1524 Session: 1234 1525 Content-Length: 15 1527 packets_received 1528 jitter 1530 C->S: RTSP/1.0 200 431 OK 1531 Content-Length: 46 1532 Content-Type: text/rtsp-parameters 1534 packets_received: 10 1535 jitter: 0.3838 1537 SET_PARAMETER 1539 This method requests to set the value of a parameter for a 1540 presentation or stream specified by the URI. 1542 A request SHOULD only contain a single parameter to allow the client 1543 to determine why a particular request failed. A server MUST allow a 1544 parameter to be set repeatedly to the same value, but it MAY disallow 1545 changing parameter values. 1547 Note: transport parameters for the media stream MUST only be set with 1548 the SETUP command. 1550 Restricting setting transport parameters to SETUP is for the 1551 benefit of firewalls. 1553 The parameters are split in a fine-grained fashion so that there 1554 can be more meaningful error indications. However, it may make 1555 sense to allow the setting of several parameters if an atomic 1556 setting is desirable. Imagine device control where the client does 1557 not want the camera to pan unless it can also tilt to the right 1558 angle at the same time. 1560 A SET_PARAMETER request without parameters can be used as a way to 1561 detect client or server liveness. 1563 Example: 1565 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 421 1566 Content-type: text/rtsp-parameters 1568 barparam: barstuff 1570 S->C: RTSP/1.0 450 421 Invalid Parameter 1571 Content-Length: 6 1573 barparam 1575 REDIRECT 1577 A redirect request informs the client that it must connect to 1578 another server location. It contains the mandatory header Location, 1579 which indicates that the client should issue requests for that URL. It 1580 may contain the parameter Range, which indicates when the redirection 1581 takes effect. 1583 This example request redirects traffic for this URI to the new server 1584 at the given play time: 1586 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 732 1587 Location: rtsp://bigserver.com:8001 1588 Range: clock=19960213T143205Z- 1590 RECORD 1592 This method initiates recording a range of media data according to 1593 the presentation description. The timestamp reflects start and end 1594 time (UTC). If no time range is given, use the start or end time 1595 provided in the presentation description. If the session has already 1596 started, commence recording immediately. 1598 The server decides whether to store the recorded data under the 1599 request-URI or another URI. If the server does not use the 1600 request-URI, the response SHOULD be 201 (Created) and contain an 1601 entity which describes the status of the request and refers to the new 1602 resource, and a Location header. 1604 A media server supporting recording of live presentations MUST support 1605 the clock range format; the smpte format does not make sense. 1607 In this example, the media server was previously invited to the 1608 conference indicated. 1610 C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 954 1611 Session: 1234 1612 Conference: 128.16.64.19/32492374 1614 10.12 Embedded (Interleaved) Binary Data 1616 Certain firewall designs and other circumstances may force a server 1617 to interleave RTSP methods and stream data. This interleaving should 1618 generally be avoided unless necessary since it complicates client and 1619 server operation and imposes additional overhead. Interleaved binary 1620 data SHOULD only be used if RTSP is carried over TCP. 1622 Stream data such as RTP packets is encapsulated by an ASCII dollar 1623 sign (24 decimal), followed by a one-byte channel identifier, followed 1624 by the length of the encapsulated binary data as a binary, two-byte 1625 integer in network byte order. The stream data follows immediately 1626 afterwards, without a CRLF, but including the upper-layer protocol 1627 headers. Each $ block contains exactly one upper-layer protocol data 1628 unit, e.g., one RTP packet. 1630 The channel identifier is defined in the Transport header 12.35. 1632 C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 2 1633 Transport: RTP/AVP/TCP;channel=0 1635 S->C: RTSP/1.0 200 2 OK 1636 Date: 05 Jun 1997 18:57:18 GMT 1637 Transport: RTP/AVP/TCP;channel=0 1638 Session: 12345 1640 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 3 1641 Session: 12345 1643 S->C: RTSP/1.0 200 3 OK 1644 Session: 12345 1645 Date: 05 Jun 1997 18:59:15 GMT 1647 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} 1648 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} 1650 11 Status Code Definitions 1652 Where applicable, HTTP status [H10] codes are re-used. Status codes 1653 that have the same meaning are not repeated here. See Table 1 for a 1654 listing of which status codes may be returned by which request. 1656 11.1 Redirection 3xx 1658 See [H10.3]. 1660 Within RTSP, redirection may be used for load balancing or redirecting 1661 stream requests to a server topologically closer to the client. 1662 Mechanisms to determine topological proximity are beyond the scope of 1663 this specification. 1665 11.2 Client Error 4xx 1667 11.2.1 405 Method Not Allowed 1669 The method specified in the request is not allowed for the resource 1670 identified by the request URI. The response MUST include an Allow 1671 header containing a list of valid methods for the requested resource. 1672 This status code is also to be used if a request attempts to use a 1673 method not indicated during SETUP, e.g., if a RECORD request is issued 1674 even though the mode parameter in the Transport header only specified 1675 PLAY. 1677 11.2.2 451 Parameter Not Understood 1679 The recipient of the request does not support one or more parameters 1680 contained in the request. 1682 11.2.3 452 Conference Not Found 1684 The conference indicated by a Conference header field is unknown to 1685 the media server. 1687 11.2.4 453 Not Enough Bandwidth 1689 The request was refused since there was insufficient bandwidth. This 1690 may, for example, be the result of a resource reservation failure. 1692 11.2.5 45x Session Not Found 1694 The RTSP session identifier is invalid or has timed out. 1696 11.2.6 45x Method Not Valid in This State 1698 The client or server cannot process this request in its current state. 1700 11.2.7 45x Header Field Not Valid for Resource 1702 The server could not act on a required request header. For example, if 1703 PLAY contains the Range header field, but the stream does not allow 1704 seeking. 1706 11.2.8 45x Invalid Range 1708 The Range value given is out of bounds, e.g., beyond the end of the 1709 presentation. 1711 11.2.9 45x Parameter Is Read-Only 1713 The parameter to be set by SET_PARAMETER can only be read, but not 1714 modified. 1716 11.2.10 45x Aggregate operation not allowed 1718 The requested method may not be applied on the URL in question since 1719 it is an aggregate(presentation) URL. The method may be applied on a 1720 stream URL. 1722 11.2.11 45x Only aggregate operation allowed 1724 The requested method may not be applied on the URL in question since 1725 it is not an aggregate(presentation) URL. The method may be applied on 1726 the presentation URL. 1728 12 Header Field Definitions 1730 HTTP/1.1 or other, non-standard header fields not listed here 1731 currently have no well-defined meaning and SHOULD be ignored by the 1732 recipient. 1734 Tables 3 summarizes the header fields used by RTSP. Type ``g'' 1735 designates general request headers, to be found in both requests and 1736 responses, type ``R'' designates request headers, type ``r'' response 1737 headers, type ``e'' entity header fields. Fields marked with ``req.'' 1738 in the column labeled ``support'' MUST be implemented by the recipient 1739 for a particular method, while fields marked ``opt.'' are optional. 1740 Note that not all fields marked 'r' will be send in every request of 1741 this type; merely, that client (for response headers) and server (for 1742 request headers) MUST implement them. The last column lists the method 1743 for which this header field is meaningful; the designation ``entity'' 1744 refers to all methods that return a message body. Within this 1745 specification, DESCRIBE and GET_PARAMETER fall into this class. 1747 If the field content does not apply to the particular resource, the 1748 server MUST return status 45x (Header Field Not Valid for Resource). 1750 Header type support methods 1751 Accept R opt. entity 1752 Accept-Encoding R opt. entity 1753 Accept-Language R opt. all 1754 Authorization R opt. all 1755 Bandwidth R opt. all 1756 Blocksize R opt. all but OPTIONS, TEARDOWN 1757 Cache-Control g opt. SETUP 1758 Conference R opt. SETUP 1759 Connection g req. all 1760 Content-Encoding e req. SET_PARAMETER 1761 Content-Encoding e req. DESCRIBE, ANNOUNCE 1762 Content-Language e req. DESCRIBE, ANNOUNCE 1763 Content-Length e req. SET_PARAMETER, ANNOUNCE 1764 Content-Length e req. entity 1765 Content-Type e req. SET_PARAMETER, ANNOUNCE 1766 Content-Type r req. entity 1767 Date g opt. all 1768 Expires e opt. DESCRIBE, ANNOUNCE 1769 From R opt. all 1770 If-Modified-Since R opt. DESCRIBE, SETUP 1771 Last-Modified e opt. entity 1772 Public r opt. all 1773 Range R opt. PLAY, PAUSE, RECORD 1774 Range r opt. PLAY, PAUSE, RECORD 1775 Referer R opt. all 1776 Retry-After r opt. all 1777 Scale Rr opt. PLAY, RECORD 1778 Session Rr req. all but SETUP, OPTIONS 1779 Server r opt. all 1780 Speed Rr opt. PLAY 1781 Transport Rr req. SETUP 1782 Transport-Info r req. PLAY 1783 User-Agent R opt. all 1784 Via g opt. all 1785 WWW-Authenticate r opt. all 1786 ! 1787 Table 3: Overview of RTSP header fields 1789 12.1 Accept 1791 The Accept request-header field can be used to specify certain 1792 presentation description content types which are acceptable for the 1793 response. 1795 The ``level'' parameter for presentation descriptions is properly 1796 defined as part of the MIME type registration, not here. 1798 See [H14.1] for syntax. 1800 Example of use: 1801 Accept: application/rtsl, application/sdp;level=2 1803 12.2 Accept-Encoding 1805 See [H14.3] 1807 12.3 Accept-Language 1809 See [H14.4]. Note that the language specified applies to the 1810 presentation description and any reason phrases, not the media 1811 content. 1813 12.4 Allow 1815 The Allow response header field lists the methods supported by the 1816 resource identified by the request-URI. The purpose of this field is 1817 to strictly inform the recipient of valid methods associated with the 1818 resource. An Allow header field must be present in a 405 (Method not 1819 allowed) response. 1821 Example of use: 1822 Allow: SETUP, PLAY, RECORD, SET_PARAMETER 1824 12.5 Authorization 1826 See [H14.8] 1828 12.6 Bandwidth 1830 The Bandwidth request header field describes the estimated bandwidth 1831 available to the client, expressed as a positive integer and measured 1832 in bits per second. 1834 The bandwidth available to the client may change during an RTSP 1835 session, e.g., due to modem retraining. 1837 Bandwidth = "Bandwidth" ":" 1*DIGIT 1839 Example: 1840 Bandwidth: 4000 1842 12.7 Blocksize 1844 This request header field is sent from the client to the media 1845 server asking the server for a particular media packet size. This 1846 packet size does not include lower-layer headers such as IP, UDP, or 1847 RTP. The server is free to use a blocksize which is lower than the one 1848 requested. The server MAY truncate this packet size to the closest 1849 multiple of the minimum media-specific block size or override it with 1850 the media specific size if necessary. The block size is a strictly 1851 positive decimal number and measured in octets. The server only 1852 returns an error (416) if the value is syntactically invalid. 1854 12.8 C-PEP 1856 This corresponds to the C-PEP: header in the ``Protocol Extension 1857 Protocol'' defined in RFC XXXX [21]. This field differs from the PEP 1858 field (Section 12.24) only in that it is hop-by-hop rather than 1859 end-to-end as PEP is. Servers and proxies MUST parse this field and 1860 MUST return "420 Bad Extension" when there is a PEP extension of 1861 strength "must". See RFC XXXX for more details on this. 1863 12.9 C-PEP-Info 1865 This corresponds to the C-PEP-Info: header in the ``Protocol 1866 Extension Protocol'' defined in RFC XXXX [21]. 1868 12.10 Cache-Control 1870 The Cache-Control general header field is used to specify directives 1871 that MUST be obeyed by all caching mechanisms along the 1872 request/response chain. 1874 Cache directives must be passed through by a proxy or gateway 1875 application, regardless of their significance to that application, 1876 since the directives may be applicable to all recipients along the 1877 request/response chain. It is not possible to specify a cache- 1878 directive for a specific cache. 1880 Cache-Control should only be specified in a SETUP request and its 1881 response. Note: Cache-Control does not govern the caching of responses 1882 as for HTTP, but rather of the stream identified by the SETUP request. 1883 Responses to RTSP requests are not cacheable, except for responses to 1884 DESCRIBE. 1886 Cache-Control = "Cache-Control" ":" 1#cache-directive 1888 cache-directive = cache-request-directive 1889 | cache-response-directive 1891 cache-request-directive = 1892 "no-cache" 1893 | "max-stale" 1894 | "min-fresh" 1895 | "only-if-cached" 1896 | cache-extension 1898 cache-response-directive = 1899 "public" 1900 | "private" 1901 | "no-cache" 1902 | "no-transform" 1903 | "must-revalidate" 1904 | "proxy-revalidate" 1905 | "max-age" "=" delta-seconds 1906 | cache-extension 1908 cache-extension = token [ "=" ( token | quoted-string ) ] 1910 no-cache: 1911 Indicates that the media stream MUST NOT be cached anywhere. 1912 This allows an origin server to prevent caching even by caches 1913 that have been configured to return stale responses to client 1914 requests. 1916 public: 1917 Indicates that the media stream is cachable by any cache. 1919 private: 1920 Indicates that the media stream is intended for a single user 1921 and MUST NOT be cached by a shared cache. A private 1922 (non-shared) cache may cache the media stream. 1924 no-transform: 1925 An intermediate cache (proxy) may find it useful to convert the 1926 media type of certain stream. A proxy might, for example, 1927 convert between video formats to save cache space or to reduce 1928 the amount of traffic on a slow link. Serious operational 1929 problems may occur, however, when these transformations have 1930 been applied to streams intended for certain kinds of 1931 applications. For example, applications for medical imaging, 1932 scientific data analysis and those using end-to-end 1933 authentication, all depend on receiving a stream that is bit 1934 for bit identical to the original entity-body. Therefore, if a 1935 response includes the no-transform directive, an intermediate 1936 cache or proxy MUST NOT change the encoding of the stream. 1937 Unlike HTTP, RTSP does not provide for partial transformation 1938 at this point, e.g., allowing translation into a different 1939 language. 1941 only-if-cached: 1942 In some cases, such as times of extremely poor network 1943 connectivity, a client may want a cache to return only those 1944 media streams that it currently has stored, and not to receive 1945 these from the origin server. To do this, the client may 1946 include the only-if-cached directive in a request. If it 1947 receives this directive, a cache SHOULD either respond using a 1948 cached media stream that is consistent with the other 1949 constraints of the request, or respond with a 504 (Gateway 1950 Timeout) status. However, if a group of caches is being 1951 operated as a unified system with good internal connectivity, 1952 such a request MAY be forwarded within that group of caches. 1954 max-stale: 1955 Indicates that the client is willing to accept a media stream 1956 that has exceeded its expiration time. If max-stale is assigned 1957 a value, then the client is willing to accept a response that 1958 has exceeded its expiration time by no more than the specified 1959 number of seconds. If no value is assigned to max-stale, then 1960 the client is willing to accept a stale response of any age. 1962 min-fresh: 1963 Indicates that the client is willing to accept a media stream 1964 whose freshness lifetime is no less than its current age plus 1965 the specified time in seconds. That is, the client wants a 1966 response that will still be fresh for at least the specified 1967 number of seconds. 1969 must-revalidate: 1970 When the must-revalidate directive is present in a SETUP 1971 response received by a cache, that cache MUST NOT use the entry 1972 after it becomes stale to respond to a subsequent request 1973 without first revalidating it with the origin server. (I.e., 1974 the cache must do an end-to-end revalidation every time, if, 1975 based solely on the origin server's Expires, the cached 1976 response is stale.) 1978 12.11 Conference 1980 This request header field establishes a logical connection between a 1981 conference, established using non-RTSP means, and an RTSP stream. The 1982 conference-id must not be changed for the same RTSP session. 1984 Conference = "Conference" ":" conference-id 1986 Example: 1987 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 1989 12.12 Connection 1991 See [H14.10]. 1993 12.13 Content-Encoding 1995 See [H14.12] 1997 12.14 Content-Language 1999 See [H14.13] 2001 12.15 Content-Length 2003 This field contains the length of the content of the method (i.e. 2004 after the double CRLF following the last header). Unlike HTTP, it MUST 2005 be included in all messages that carry content beyond the header 2006 portion of the message. It is interpreted according to [H14.14]. 2008 12.16 Content-Type 2010 See [H14.18]. Note that the content types suitable for RTSP are 2011 likely to be restricted in practice to presentation descriptions and 2012 parameter-value types. 2014 12.17 Date 2016 See [H14.19]. 2018 12.18 Expires 2020 The Expires entity-header field gives the date/time after which the 2021 media-stream should be considered stale. A stale cache entry may not 2022 normally be returned by a cache (either a proxy cache or an user agent 2023 cache) unless it is first validated with the origin server (or with an 2024 intermediate cache that has a fresh copy of the entity). See section 2025 13.2 for further discussion of the expiration model. 2027 The presence of an Expires field does not imply that the original 2028 resource will change or cease to exist at, before, or after that time. 2030 The format is an absolute date and time as defined by HTTP-date in 2031 [H3.3]; it MUST be in RFC1123-date format: 2033 Expires = "Expires" ":" HTTP-date 2035 An example of its use is 2037 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2039 RTSP/1.0 clients and caches MUST treat other invalid date formats, 2040 especially including the value "0", as in the past (i.e., "already 2041 expired"). 2043 To mark a response as "already expired," an origin server should use 2044 an Expires date that is equal to the Date header value. 2046 To mark a response as "never expires," an origin server should use an 2047 Expires date approximately one year from the time the response is 2048 sent. RTSP/1.0 servers should not send Expires dates more than one 2049 year in the future. 2051 The presence of an Expires header field with a date value of some time 2052 in the future on a media stream that otherwise would by default be 2053 non-cacheable indicates that the media stream is cachable, unless 2054 indicated otherwise by a Cache-Control header field (Section 12.10). 2056 12.19 From 2058 See [H14.22]. 2060 12.20 Host 2062 This HTTP request header field is not needed for RTSP. It should be 2063 silently ignored if sent. 2065 12.21 If-Modified-Since 2067 The If-Modified-Since request-header field is used with the DESCRIBE 2068 and SETUP methods to make them conditional: if the requested variant 2069 has not been modified since the time specified in this field, a 2070 description will not be returned from the server (DESCRIBE) or a 2071 stream will not be setup (SETUP); instead, a 304 (not modified) 2072 response will be returned without any message-body. 2074 If-Modified-Since = "If-Modified-Since" ":" HTTP-date 2076 An example of the field is: 2078 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 2080 12.22 Last-Modified 2082 The Last-Modified entity-header field indicates the date and time at 2083 which the origin server believes the variant was last modified. See 2084 [H14.29]. If the request URI refers to an aggregate, the field 2085 indicates the last modification time across all leave nodes of that 2086 aggregate. 2088 12.23 Location 2090 See [H14.30]. 2092 12.24 PEP 2094 This corresponds to the PEP: header in the ``Protocol Extension 2095 Protocol'' defined in RFC XXXX. Servers MUST parse this field and MUST 2096 return ``420 Bad Extension'' when there is a PEP extension of strength 2097 ``must'' (see RFC XXXX). 2099 12.25 PEP-Info 2101 This corresponds to the PEP-Info: header in the ``Protocol Extension 2102 Protocol'' defined in RFC XXXX. 2104 12.26 Proxy-Authenticate 2106 See [H14.33]. 2108 12.27 Public 2110 See [H14.35]. 2112 12.28 Range 2114 This request header field specifies a range of time. The range can 2115 be specified in a number of units. This specification defines the 2116 smpte (see Section 3.5) and clock (see Section 3.7) range units. 2117 Within RTSP, byte ranges [H14.36.1] are not meaningful and MUST NOT be 2118 used. The header may also contain a time parameter in UTC, specifying 2119 the time at which the operation is to be made effective. Servers 2120 supporting the Range header MUST understand the NPT and SMPTE range 2121 formats. 2123 Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ] 2125 ranges-specifier = npt-range | utc-range | smpte-range 2127 Example: 2128 Range: clock=19960213T143205Z-;time=19970123T143720Z 2130 The notation is similar to that used for the HTTP/1.1 header. It 2131 allows to select a clip from the media object, to play from a given 2132 point to the end and from the current location to a given point. 2133 The start of playback can be scheduled for at any time in the 2134 future, although a server may refuse to keep server resources for 2135 extended idle periods. 2137 12.29 Referer 2139 See [H14.37]. The URL refers to that of the presentation 2140 description, typically retrieved via HTTP. 2142 12.30 Retry-After 2144 See [H14.38]. 2146 12.31 Scale 2148 A scale value of 1 indicates normal play or record at the normal 2149 forward viewing rate. If not 1, the value corresponds to the rate with 2150 respect to normal viewing rate. For example, a ratio of 2 indicates 2151 twice the normal viewing rate (``fast forward'') and a ratio of 0.5 2152 indicates half the normal viewing rate. In other words, a ratio of 2 2153 has normal play time increase at twice the wallclock rate. For every 2154 second of elapsed (wallclock) time, 2 seconds of content will be 2155 delivered. A negative value indicates reverse direction. 2157 Unless requested otherwise by the Speed parameter, the data rate 2158 SHOULD not be changed. Implementation of scale changes depends on the 2159 server and media type. For video, a server may, for example, deliver 2160 only key frames or selected key frames. For audio, it may time-scale 2161 the audio while preserving pitch or, less desirably, deliver fragments 2162 of audio. 2164 The server should try to approximate the viewing rate, but may 2165 restrict the range of scale values that it supports. The response MUST 2166 contain the actual scale value chosen by the server. 2168 If the request contains a Range parameter, the new scale value will 2169 take effect at that time. 2171 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 2173 Example of playing in reverse at 3.5 times normal rate: 2175 Scale: -3.5 2177 12.32 Speed 2179 This request header fields parameter requests the server to deliver 2180 data to the client at a particular speed, contingent on the server's 2181 ability and desire to serve the media stream at the given speed. 2182 Implementation by the server is OPTIONAL. The default is the bit rate 2183 of the stream. 2185 The parameter value is expressed as a decimal ratio, e.g., a value of 2186 2.0 indicates that data is to be delivered twice as fast as normal. A 2187 speed of zero is invalid. If the request contains a Range parameter, 2188 the new speed value will take effect at that time. 2190 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] 2192 Example: 2193 Speed: 2.5 2195 Use of this field changes the bandwidth used for data delivery. It is 2196 meant for use in specific circumstances where preview of the 2197 presentation at a higher or lower rate is necessary. Implementors 2198 should keep in mind that bandwidth for the session may be negotiated 2199 beforehand (by means other than RTSP), and therefore re-negotiation 2200 may be necessary. When data is delivered over UDP, it is highly 2201 recommended that means such as RTCP be used to track packet loss 2202 rates. 2204 12.33 Server 2206 See [H14.39] 2208 12.34 Session 2210 This request and response header field identifies an RTSP session, 2211 started by the media server in a SETUP response and concluded by 2212 TEARDOWN on the presentation URL. The session identifier is chosen by 2213 the media server (see Section 3.4). Once a client receives a Session 2214 identifier, it MUST return it for any request related to that session. 2216 Session = "Session" ":" session-id 2218 Note that a session identifier identifies a RTSP session across 2219 transport sessions or connections. Control messages for more than one 2220 RTSP URL may be sent within a single RTSP session. Hence, it is 2221 possible that clients use the same session for controlling many 2222 streams comprising a presentation, as long as all the streams come 2223 from the same server. (See example in Section 14). However, multiple 2224 ``user'' sessions for the same URL from the same client MUST use 2225 different session identifiers. 2227 The session identifier is needed to distinguish several delivery 2228 requests for the same URL coming from the same client. 2230 12.35 Transport 2232 This request header indicates which transport protocol is to be used 2233 and configures its parameters such as destination address, 2234 compression, multicast time-to-live and destination port for a single 2235 stream. It sets those values not already determined by a presentation 2236 description. 2238 Transports are comma separated, listed in order of preference. 2239 Parameters may be added to each tranpsort, separated by a semicolon. 2241 The Transport header MAY also be used to change certain transport 2242 parameters. A server MAY refuse to change parameters of an existing 2243 stream. 2245 The server MAY return a Transport response header in the response to 2246 indicate the values actually chosen. 2248 A Transport request header field may contain a list of transport 2249 options acceptable to the client. In that case, the server MUST return 2250 a single option which was actually chosen. 2252 The syntax for the transport specifier is 2253 transport/profile/lower-transport. Defaults for "lower-transport" are 2254 specific to the profile. For RTP/AVP, the default is UDP. 2256 Below are the configuration parameters associated with transport: 2258 General parameters: 2260 destination: 2261 The address to which a stream will be sent. The client may 2262 specify the multicast address with the destination parameter. A 2263 server SHOULD authenticate the client and SHOULD log such 2264 attempts before allowing the client to direct a media stream to 2265 an address not chosen by the server to avoid becoming the 2266 unwitting perpetrator of a remote-controlled denial-of-service 2267 attack. This is particularly important if RTSP commands are 2268 issued via UDP, but TCP cannot be relied upon as reliable means 2269 of client identification by itself. A server SHOULD not allow a 2270 client to direct media streams to an address that differs from 2271 the address commands are coming from. 2273 mode: 2274 The mode parameter indicates the methods to be supported for 2275 this session. Valid values are PLAY and RECORD. If not 2276 provided, the default is PLAY. For RECORD, the append flag 2277 indicates that the media data should be appended to the 2278 existing resource rather than overwriting it. If appending is 2279 requested and the server does not support this, it MUST refuse 2280 the request rather than overwrite the resouce identified by the 2281 URI. The append parameter is ignored if the mode parameter does 2282 not contain RECORD. 2284 interleaved: 2285 The interleaved parameter implies mixing the media stream with 2286 the control stream, in whatever protocol is being used by the 2287 control stream. Currently, the next-layer protocols RTP is 2288 defined. The `channel' parameter defines the channel number to 2289 be used in the $ statement (see section 10.12). 2291 Multicast specific: 2293 ttl: 2294 multicast time-to-live 2296 RTP Specific: 2298 compressed: 2299 Boolean parameter indicating compressed RTP according to RFC 2300 XXXX. 2302 port: 2303 RTP/RTCP destination ports on client. The client receives RTCP 2304 reports on the value of port plus one, as is standard RTP 2305 convention. 2307 cport: 2308 the control port that the data server wishes the client to send 2309 its RTCP reports to. 2311 ssrc: 2312 Indicates the RTP SSRC [19, Sec. 3] value that should be 2313 (request) or will be (response) used by the media server. This 2314 parameter is only valid for unicast transmission. It identifies 2315 the synchronization source to be associated with the media 2316 stream. 2318 Transport = "Transport" ":" 2319 1#transport-protocol/profile[/lower-transport] *parameter 2320 transport-protocol = "RTP" 2321 profile = "AVP" 2322 lower-transport = "TCP" | "UDP" 2323 parameter = ";" "destination" [ "=" address ] 2324 | ";" "compressed" 2325 | ";" "channel" "=" channel 2326 | ";" "append" 2327 | ";" "ttl" "=" ttl 2328 | ";" "port" "=" port 2329 | ";" "cport" "=" port 2330 | ";" "ssrc" "=" ssrc 2331 | ";" "mode" = <"> 1#mode <"> 2332 ttl = 1*3(DIGIT) 2333 port = 1*5(DIGIT) 2334 ssrc = 8*8(HEX) 2335 channel = 1*3(DIGIT) 2336 address = host 2337 mode = "PLAY" | "RECORD" *parameter 2339 Example: 2340 Transport: RTP/AVP;compressed;ttl=127;port=3456; 2341 mode="PLAY,RECORD;append" 2343 The Transport header is restricted to describing a single RTP 2344 stream. (RTSP can also control multiple streams as a single 2345 entity.) Making it part of RTSP rather than relying on a multitude 2346 of session description formats greatly simplifies designs of 2347 firewalls. 2349 12.36 Transport-Info 2351 This field is used to set Transport specific parameters in the PLAY 2352 response. 2354 seq: 2355 Indicates the sequence number of the first packet of the 2356 stream. This allows clients to gracefully deal with packets 2357 when seeking. The client uses this value to differentiate 2358 packets that originated before the seek from packets that 2359 originated after the seek. 2361 Transport-Info = "Transport-Info" ":" 2362 1#transport-protocol/profile[/lower-transport] ";" 2363 streamid 2364 *parameter 2365 transport-protocol = "RTP" 2366 profile = "AVP" 2367 lower-transport = "TCP" | "UDP" 2368 stream-id = "streamid" "=" streamid 2369 parameter = ";" "seq" "=" sequence number 2370 sequence-number = 1*16(DIGIT) 2372 Example: 2373 Transport-Info: RTP/AVP;streamid=0;seq=43754027, 2374 RTP/AVP;streamid=1;seq=34834738 2376 12.37 User-Agent 2378 See [H14.42] 2380 12.38 Vary 2382 See [H14.43] 2384 12.39 Via 2386 See [H14.44]. 2388 12.40 WWW-Authenticate 2390 See [H14.46]. 2392 13 Caching 2394 In HTTP, response-request pairs are cached. RTSP differs 2395 significantly in that respect. Responses are not cachable, with the 2396 exception of the stream description returned by DESCRIBE. (Since the 2397 responses for anything but DESCRIBE and GET_PARAMETER do not return 2398 any data, caching is not really an issue for these requests.) However, 2399 it is desirable for the continuous media data, typically delivered 2400 out-of-band with respect to RTSP, to be cached. 2402 On receiving a SETUP or PLAY request, the proxy would ascertain as to 2403 whether it has an up-to-date copy of the continuous media content. If 2404 not, it would modify the SETUP transport parameters as appropriate and 2405 forward the request to the origin server. Subsequent control commands 2406 such as PLAY or PAUSE would pass the proxy unmodified. The proxy would 2407 then pass the continuous media data to the client, while possibly 2408 making a local copy for later re-use. The exact behavior allowed to 2409 the cache is given by the cache-response directives described in 2410 Section 12.10. A cache MUST answer any DESCRIBE requests if it is 2411 currently serving the stream to the requestor, as it is possible that 2412 low-level details of the stream description may have changed on the 2413 origin-server. 2415 Note that an RTSP cache, unlike the HTTP cache, is of the 2416 ``cut-through'' variety. Rather than retrieving the whole resource 2417 from the origin server, the cache simply copies the streaming data as 2418 it passes by on its way to the client, thus, it does not introduce 2419 additional latency. 2421 To the client, an RTSP proxy cache would appear like a regular media 2422 server, to the media origin server like a client. Just like an HTTP 2423 cache has to store the content type, content language, etc. for the 2424 objects it caches, a media cache has to store the presentation 2425 description. Typically, a cache would eliminate all 2426 transport-references (that is, multicast information) from the 2427 presentation description, since these are independent of the data 2428 delivery from the cache to the client. Information on the encodings 2429 remains the same. If the cache is able to translate the cached media 2430 data, it would create a new presentation description with all the 2431 encoding possibilities it can offer. 2433 14 Examples 2435 The following examples reference stream description formats that are 2436 not finalized, such as RTSL and SDP. Please do not use these examples 2437 as a reference for those formats. 2439 14.1 Media on Demand (Unicast) 2441 Client C requests a movie from media servers A ( audio.example.com) 2442 and V (video.example.com). The media description is stored on a web 2443 server W . The media description contains descriptions of the 2444 presentation and all its streams, including the codecs that are 2445 available, dynamic RTP payload types, the protocol stack and content 2446 information such as language or copyright restrictions. It may also 2447 give an indication about the time line of the movie. 2449 In our example, the client is only interested in the last part of the 2450 movie. The server requires authentication for this movie. 2452 C->W: GET /twister.sdp HTTP/1.1 2453 Host: www.example.com 2454 Accept: application/sdp 2456 W->C: HTTP/1.0 200 OK 2457 Content-Type: application/sdp 2459 v=0 2460 o=- 2890844526 2890842807 IN IP4 192.16.24.202 2461 s=RTSP Session 2462 m=audio 0 RTP/AVP 0 2463 a=murl:rtsp://audio.example.com/twister/audio.en 2464 m=video 0 RTP/AVP 31 2465 a=murl:rtsp://audio.example.com/twister/video 2467 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 1 2468 Transport: rtp/udp;port=3056 2470 A->C: RTSP/1.0 200 1 OK 2471 Session: 1234 2473 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 1 2474 Transport: rtp/udp;port=3058 2476 V->C: RTSP/1.0 200 1 OK 2477 Session: 1235 2479 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 2 2480 Session: 1235 2481 Range: smpte=0:10:00- 2483 V->C: RTSP/1.0 200 2 OK 2485 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 2 2486 Session: 1234 2487 Range: smpte=0:10:00- 2489 A->C: RTSP/1.0 200 2 OK 2491 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 3 2492 Session: 1234 2494 A->C: RTSP/1.0 200 3 OK 2496 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 3 2497 Session: 1235 2499 V->C: RTSP/1.0 200 3 OK 2501 Even though the audio and video track are on two different servers, 2502 and may start at slightly different times and may drift with respect 2503 to each other, the client can synchronize the two using standard RTP 2504 methods, in particular the time scale contained in the RTCP sender 2505 reports. 2507 14.2 Streaming of a Container file 2509 For purposes of this example, a container file is a storage entity in 2510 which multiple continuous media types pertaining to the same end-user 2511 presentation are present. In effect, the container file represents a 2512 RTSP presentation, with each of its components being RTSP streams. 2513 Container files are a widely used means to store such presentations. 2514 While the components are essentially transported as independant 2515 streams, it is desirable to maintain a common context for those 2516 streams at the server end. 2518 This enables the server to keep a single storage handle open 2519 easily. It also allows treating all the streams equally in case of 2520 any prioritization of streams by the server. 2522 It is also possible that the presentation author may wish to prevent 2523 selective retreival of the streams by client in order to preserve the 2524 artistic effect of the combined media presentation. Similarly, in such 2525 a tightly bound presentation, it is desirable to be able to control 2526 all the streams via a single control message using an aggregate URL. 2528 The following is an example of using a single RTSP session to control 2529 multiple streams. It also illustrates the use of aggregate URLs. 2531 Client C requests a presentation from media server M . The movie is 2532 stored in a container file. The client has obtained a RTSP URL to the 2533 container file. 2535 C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 1 2537 M->C: RTSP/1.0 200 1 OK 2538 Content-Type: application/sdp 2539 Content-Length: 64 2540 s= sample rtsp presentation 2541 r = rtsp://foo/twister /* aggregate URL*/ 2542 m= audio 0 RTP/AVP 0 2543 r = rtsp://foo/twister/audio 2544 m=video 0 RTP/AVP 26 2545 r = rtsp://foo/twister/video 2547 C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 2 2548 Transport: RTP/AVP;port=8000 2550 M->C: RTSP/1.0 200 2 OK 2551 Session: 1234 2553 C->M: SETUP rtsp://foo/twister/video RTSP/1.0 3 2554 Transport: RTP/AVP;port=8002 2555 Session: 1234 2557 M->C: RTSP/1.0 200 3 OK 2558 Session: 1234 2560 C->M: PLAY rtsp://foo/twister RTSP/1.0 4 2561 Range: npt=0- 2562 Session: 1234 2564 M->C: RTSP/1.0 200 4 OK 2565 Session: 1234 2567 C->M: PAUSE rtsp://foo/twister/video RTSP/1.0 5 2568 Session: 1234 2570 M->C: RTSP/1.0 4xx 5 Only aggregate operation allowed 2572 C->M: PAUSE rtsp://foo/twister RTSP/1.0 6 2573 Session: 1234 2575 M->C: RTSP/1.0 200 6 OK 2576 Session: 1234 2578 C->M: SETUP rtsp://foo/twister RTSP/1.0 7 2579 Transport: RTP/AVP;port=10000 2581 M->C: RTSP/1.0 4xx 7 Aggregate operation not allowed 2583 In the first instance of failure, the client tries to pause one 2584 stream(in this case video) of the presentation which is disallowed for 2585 that presentation by the server. In the second instance, the aggregate 2586 URL may not be used for SETUP and one control message is required per 2587 stream to setup transport parameters. 2589 This keeps the syntax of the Transport header simple, and allows 2590 easy parsing of transport information by firewalls. 2592 14.3 Live Media Presentation Using Multicast 2594 The media server M chooses the multicast address and port. Here, we 2595 assume that the web server only contains a pointer to the full 2596 description, while the media server M maintains the full description. 2598 C->W: GET /concert.sdp HTTP/1.1 2599 Host: www.example.com 2601 W->C: HTTP/1.1 200 OK 2602 Content-Type: application/rtsl 2604 2605 2606 2608 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 1 2610 M->C: RTSP/1.0 200 1 OK 2611 Content-Type: application/sdp 2613 v=0 2614 o=- 2890844526 2890842807 IN IP4 192.16.24.202 2615 s=RTSP Session 2616 m=audio 3456 RTP/AVP 0 2617 c=IN IP4 224.2.0.1/16 2619 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 2 2620 Transport: multicast=224.2.0.1; port=3456; ttl=16 2622 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3 2624 M->C: RTSP/1.0 200 3 OK 2626 The attempt to position the stream fails since this is a live 2627 presentation. 2629 14.4 Playing media into an existing session 2631 A conference participant C wants to have the media server M play back 2632 a demo tape into an existing conference. When retrieving the 2633 presentation description, C indicates to the media server that the 2634 network addresses and encryption keys are already given by the 2635 conference, so they should not be chosen by the server. The example 2636 omits the simple ACK responses. 2638 C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0 1 2639 Accept: application/sdp 2641 M->C: RTSP/1.0 200 1 OK 2642 Content-type: application/rtsl 2644 v=0 2645 o=- 2890844526 2890842807 IN IP4 192.16.24.202 2646 s=RTSP Session 2647 m=audio 0 RTP/AVP 0 2649 C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 2 2650 Conference: 218kadjk 2652 14.5 Recording 2654 The conference participant C asks the media server M to record a 2655 meeting. If the presentation description contains any alternatives, 2656 the server records them all. 2658 C->M: DESCRIBE rtsp://server.example.com/meeting RTSP/1.0 90 2659 Content-Type: application/sdp 2661 v=0 2662 s=Mbone Audio 2663 i=Discussion of Mbone Engineering Issues 2665 M->C: RTSP/1.0 200 90 OK 2667 C->S: SETUP rtsp://server.example.com/meeting RTSP/1.0 91 2668 Transport: RTP/AVP;mode=record 2670 S->C: RTSP/1.0 200 91 OK 2671 Transport: RTP/AVP;port=3244;mode=record 2672 Session: 508876 2674 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 92 2675 Session: 508876 2676 Range: clock 19961110T1925-19961110T2015 2678 15 Syntax 2680 The RTSP syntax is described in an augmented Backus-Naur form (BNF) 2681 as used in RFC 2068 (HTTP/1.1). 2683 15.1 Base Syntax 2685 OCTET = 2686 CHAR = 2687 UPALPHA = 2688 LOALPHA = 2689 ALPHA = UPALPHA | LOALPHA 2690 DIGIT = 2691 CTL = 2693 CR = 2694 LF = 2695 SP = 2696 HT = 2697 <"> = 2698 CRLF = CR LF 2699 LWS = [CRLF] 1*( SP | HT ) 2700 TEXT = 2701 tspecials = "(" | ")" | "<" | ">" | "@" 2702 | "," | ";" | ":" | "\" | <"> 2703 | "/" | "[" | "]" | "?" | "=" 2704 | "{" | "}" | SP | HT 2705 token = 1* 2706 quoted-string = ( <"> *(qdtext) <"> ) 2707 qdtext = > 2708 quoted-pair = "\" CHAR 2709 message-header = field-name ":" [ field-value ] CRLF 2710 field-name = token 2711 field-value = *( field-content | LWS ) 2712 field-content = 2716 16 Security Considerations 2718 The protocol offers the opportunity for a remote-controlled 2719 denial-of-service attack. 2721 The attacker, using a forged source IP address, can ask for a stream 2722 to be played back to that forged IP address. Thus, an RTSP server 2723 SHOULD only allow client-specified destinations for RTSP-initiated 2724 traffic flows if the server has verified the client's identity, e.g., 2725 using the RTSP authentication mechanisms. 2727 Since there is no relation between a transport layer connection and an 2728 RTSP session, it is possible for a malicious client to issue requests 2729 with random session identifiers which would affect unsuspecting 2730 clients. This does not require spoofing of network packet addresses. 2731 The server SHOULD use a large random session identifier to make this 2732 attack more difficult. 2734 Both problems can be be prevented by appropriate authentication. 2736 Servers SHOULD implement both basic and digest [8] authentication. 2738 In addition, the security considerations outlined in [H15] apply. 2740 A RTSP Protocol State Machines 2742 The RTSP client and server state machines describe the behavior of 2743 the protocol from RTSP session initialization through RTSP session 2744 termination. 2746 State is defined on a per object basis. An object is uniquely 2747 identified by the stream URL and the RTSP session identifier. Any 2748 request/reply using aggregate URLs denoting RTSP presentations 2749 comprised of multiple streams will have an effect on the individual 2750 states of all the streams. For example, if the presentation /movie 2751 contains two streams /movie/audio and /movie/video, then the following 2752 command: 2754 PLAY rtsp://foo.com/movie RTSP/1.0 559 2755 Session: 12345 2757 will have an effect on the states of movie/audio and movie/video. 2759 This example does not imply a standard way to represent streams in 2760 URLs or a relation to the filesystem. See Section 3.2. 2762 The requests OPTIONS, DESCRIBE, GET_PARAMETER, SET_PARAMETER do not 2763 have any effect on client or server state and are therefore not listed 2764 in the state tables. 2766 A.1 Client State Machine 2768 The client can assume the following states: 2770 Init: 2771 SETUP has been sent, waiting for reply. 2773 Ready: 2774 SETUP reply received OR after playing, PAUSE reply received. 2776 Playing: 2777 PLAY reply received 2779 Recording: 2780 RECORD reply received 2782 In general, the client changes state on receipt of replies to 2783 requests. Note that some requests are effective at a future time or 2784 position(such as a PAUSE), and state also changes accordingly. If no 2785 explicit SETUP is required for the object (for example, it is 2786 available via a multicast group), state begins at READY. In this case, 2787 there are only two states, READY and PLAYING. 2789 The client also changes state from Playing/Recording to Ready when the 2790 end of the requested range is reached. 2792 The ``next state'' column indicates the state assumed after receiving 2793 a success response (2xx). If a request yields a status code of 3xx, 2794 the state becomes Init, and a status code of 4xx yields no change in 2795 state. Messages not listed for each state MUST NOT be issued by the 2796 client in that state, with the exception of messages not affecting 2797 state, as listed above. Receiving a REDIRECT from the server is 2798 equivalent to receiving a 3xx redirect status from the server. 2800 state message next state 2801 Init SETUP Ready 2802 TEARDOWN Init 2803 Ready PLAY Playing 2804 RECORD Recording 2805 TEARDOWN Init 2806 Playing PAUSE Ready 2807 TEARDOWN Init 2808 PLAY Playing 2809 SETUP Playing (changed transport) 2810 Recording PAUSE Ready 2811 TEARDOWN Init 2812 RECORD Recording 2813 SETUP Recording (changed transport) 2815 A.2 Server State Machine 2817 The server can assume the following states: 2819 Init: 2820 The initial state, no valid SETUP received. 2822 Ready: 2823 Last SETUP received was successful, reply sent or after 2824 playing, last PAUSE received was successful, reply sent. 2826 Playing: 2827 Last PLAY received was successful, reply sent. Data is being 2828 sent. 2830 Recording: 2831 The server is recording media data. 2833 In general,the server changes state on receiving requests. If the 2834 server is in state Playing or Recording and in unicast mode, it MAY 2835 revert to Init and tear down the RTSP session if it has not received 2836 ``wellness'' information, such as RTCP reports, from the client for a 2837 defined interval, with a default of one minute. If the server is in 2838 state Ready, it MAY revert to Init if it does not receive an RTSP 2839 request for an interval of more than one minute. Note that some 2840 requests(such as PAUSE) may be effective at a future time or position, 2841 and server state transitions at the appropriate time. The server 2842 reverts from state Playing or Recording to state Ready at the end of 2843 the range requested by the client. 2845 The REDIRECT message, when sent, is effective immediately unless it 2846 has a Range: header specifying when the redirect is effective. In such 2847 a case, server state will also change at the appropriate time. 2849 If no explicit SETUP is required for the object, state starts at 2850 READY, there are only two states READY and PLAYING. 2852 The ``next state'' column indicates the state assumed after sending a 2853 success response (2xx). If a request results in a status code of 3xx, 2854 the state becomes Init. A status code of 4xx results in no change. 2856 state message next state 2857 Init SETUP Ready 2858 TEARDOWN Init 2859 Ready PLAY Playing 2860 SETUP Ready 2861 TEARDOWN Init 2862 RECORD Recording 2863 Playing PLAY Playing 2864 PAUSE Ready 2865 TEARDOWN Init 2866 SETUP Playing 2867 Recording RECORD Recording 2868 PAUSE Ready 2869 TEARDOWN Init 2870 SETUP Recording 2872 B Open Issues 2874 1. 2875 Define text/rtsp-parameter MIME type. 2876 2. 2877 Reverse: Scale: -1, with reversed start times, or both? 2878 3. 2879 HS believes that RTSP should only control individual media 2880 objects rather than aggregates. This avoids disconnects between 2881 presentation descriptions and streams and avoids having to deal 2882 separately with single-host and multi-host case. Cost: several 2883 PLAY/PAUSE/RECORD in one packet, one for each stream. 2884 4. 2885 Allow changing of transport for a stream that's playing? May 2886 not be a great idea since the same can be accomplished by tear 2887 down and re-setup. Exception: near-video-on-demand, where the 2888 server changes the address in a PLAY response. Servers may not 2889 be able to reliably send TEARDOWN to clients and the client 2890 wouldn't know why this happened in any event. 2891 5. 2892 How does the server get back to the client unless a persistent 2893 connection is used? Probably cannot, in general. 2894 6. 2895 Server issues TEARDOWN and other 'event' notifications to 2896 client? This raises the problem discussed in the previous open 2897 issue, but is useful for the client if the data stream contains 2898 no end indication. 2900 C Changes 2902 Since the March 1997 version, the following changes were made: 2904 * Allowing the Transport header to direct media streams to unicast 2905 and multicast addresses, with an appropriate warning about 2906 denial-of-service attacks. 2907 * Add mode parameter to Transport header to allow RECORD or PLAY. 2908 * The Embedded binary data section was modified to clearly indicate 2909 the stream the data corresponds to, and a reference to the 2910 Transport header was added. 2911 * The Transport header format has been changed to use a more general 2912 means to specify data channel and application level protocol. It 2913 also conveys the port to be used at the server for RTCP messages, 2914 and the start sequence number that will be used in the RTP 2915 packets. 2916 * The use of the Session: header has been enhanced. Requests for 2917 multiple URLs may be sent in a single session. 2918 * There is a distinction between aggregate(presentation) URLs and 2919 stream URLs. Error codes have been added to reflect the fact that 2920 some methods may be allowed only on a particular type of URL. 2921 * Example showing the use of aggregate/presentation control using a 2922 single RTSP session has been added. 2923 * Support for the PEP(Protocol Extension Protocol) headers has been 2924 added. 2925 * Server-Client DESCRIBE messages have been renamed to ANNOUNCE for 2926 better clarity and differentiation. 2928 Note that this list does not reflect minor changes in wording or 2929 correction of typographical errors. 2931 D Author Addresses 2933 Henning Schulzrinne 2934 Dept. of Computer Science 2935 Columbia University 2936 1214 Amsterdam Avenue 2937 New York, NY 10027 2938 USA 2939 electronic mail: schulzrinne@cs.columbia.edu 2940 Anup Rao 2941 Netscape Communications Corp. 2942 501 E. Middlefield Road 2943 Mountain View, CA 94043 2944 USA 2945 electronic mail: anup@netscape.com 2947 Robert Lanphier 2948 Progressive Networks 2949 1111 Third Avenue Suite 2900 2950 Seattle, WA 98101 2951 USA 2952 electronic mail: robla@prognet.com 2954 E Acknowledgements 2956 This draft is based on the functionality of the original RTSP draft 2957 submitted in October 96. It also borrows format and descriptions from 2958 HTTP/1.1. 2960 This document has benefited greatly from the comments of all those 2961 participating in the MMUSIC-WG. In addition to those already 2962 mentioned, the following individuals have contributed to this 2963 specification: 2965 Rahul Agarwal Eduardo F. Llach 2966 Bruce Butterfield Rob McCool 2967 Steve Casner David Oran 2968 Martin Dunsmuir Sujal Patel 2969 Eric Fleischman 2970 Mark Handley Igor Plotnikov 2971 Peter Haight Pinaki Shah 2972 Brad Hefta-Gaub Jeff Smith 2973 John K. Ho Alexander Sokolsky 2974 Ruth Lang Dale Stammen 2975 Stephanie Leif John Francis Stracke 2977 References 2979 1 2980 H. Schulzrinne, ``RTP profile for audio and video conferences 2981 with minimal control,'' RFC 1890, Internet Engineering Task 2982 Force, Jan. 1996. 2983 2 2984 D. Kristol and L. Montulli, ``HTTP state management 2985 mechanism,'' RFC 2109, Internet Engineering Task Force, Feb. 2986 1997. 2987 3 2988 F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 2989 ``Internationalization of the hypertext markup language,'' RFC 2990 2070, Internet Engineering Task Force, Jan. 1997. 2991 4 2992 S. Bradner, ``Key words for use in RFCs to indicate requirement 2993 levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. 2994 5 2995 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. 2996 Berners-Lee, ``Hypertext transfer protocol - HTTP/1.1,'' RFC 2997 2068, Internet Engineering Task Force, Jan. 1997. 2998 6 2999 M. Handley, ``SDP: Session description protocol,'' Internet 3000 Draft, Internet Engineering Task Force, Nov. 1996. 3001 Work in progress. 3002 7 3003 A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' 3004 Internet Draft, Internet Engineering Task Force, Dec. 1996. 3005 Work in progress. 3006 8 3007 J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and 3008 E. L. Stewart, ``An extension to HTTP: digest access 3009 authentication,'' RFC 2069, Internet Engineering Task Force, 3010 Jan. 1997. 3011 9 3012 J. Postel, ``User datagram protocol,'' STD 6, RFC 768, Internet 3013 Engineering Task Force, Aug. 1980. 3014 10 3015 R. Hinden and C. Partridge, ``Version 2 of the reliable data 3016 protocol (RDP),'' RFC 1151, Internet Engineering Task Force, 3017 Apr. 1990. 3018 11 3019 J. Postel, ``Transmission control protocol,'' STD 7, RFC 793, 3020 Internet Engineering Task Force, Sept. 1981. 3021 12 3022 M. Handley, H. Schulzrinne, and E. Schooler, ``SIP: Session 3023 initiation protocol,'' Internet Draft, Internet Engineering 3024 Task Force, Dec. 1996. 3025 Work in progress. 3026 13 3027 P. McMahon, ``GSS-API authentication method for SOCKS version 3028 5,'' RFC 1961, Internet Engineering Task Force, June 1996. 3029 14 3030 D. Crocker, ``Augmented BNF for syntax specifications: ABNF,'' 3031 Internet Draft, Internet Engineering Task Force, Oct. 1996. 3032 Work in progress. 3033 15 3034 R. Elz, ``A compact representation of IPv6 addresses,'' RFC 3035 1924, Internet Engineering Task Force, Apr. 1996. 3036 16 3037 T. Berners-Lee, L. Masinter, and M. McCahill, ``Uniform 3038 resource locators (URL),'' RFC 1738, Internet Engineering Task 3039 Force, Dec. 1994. 3040 17 3041 International Telecommunication Union, ``Visual telephone 3042 systems and equipment for local area networks which provide a 3043 non-guaranteed quality of service,'' Recommendation H.323, 3044 Telecommunication Standardization Sector of ITU, Geneva, 3045 Switzerland, May 1996. 3046 18 3047 ISO/IEC, ``Information technology - generic coding of moving 3048 pictures and associated audio informaiton - part 6: extension 3049 for digital storage media and control,'' Draft International 3050 Standard ISO 13818-6, International Organization for 3051 Standardization ISO/IEC JTC1/SC29/WG11, Geneva, Switzerland, 3052 Nov. 1995. 3053 19 3054 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 3055 ``RTP: a transport protocol for real-time applications,'' RFC 3056 1889, Internet Engineering Task Force, Jan. 1996. 3057 20 3058 J. Miller, P. Resnick, and D. Singer, ``Rating Services and 3059 Rating Systems(and Their Machine Readable Descriptions), '' 3060 REC-PICS-services-961031, Worldwide Web Consortium, Oct. 1996. 3061 21 3062 D. Connolly, R. Khare, H.F. Nielsen, ``PEP - an Extension 3063 Mechanism for HTTP", Internet draft, work-in-progress. W3C 3064 Draft WD-http-pep-970714 3065 http://www.w3.org/TR/WD-http-pep-970714, July, 1996.