idnits 2.17.1 draft-ietf-mmusic-rtsp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 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 183 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 516: '... A server SHOULD implement all heade...' RFC 2119 keyword, line 536: '...the server. The server SHOULD list the...' RFC 2119 keyword, line 708: '...ddresses in URLs SHOULD be avoided whe...' RFC 2119 keyword, line 749: '...conference identifier MUST be globally...' RFC 2119 keyword, line 765: '...d. A session identifier MUST be chosen...' (111 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1178 has weird spacing: '...equired all...' == Line 1190 has weird spacing: '...s State all...' == Line 1194 has weird spacing: '...Allowed all...' == Line 1997 has weird spacing: '... type supp...' == Line 3571 has weird spacing: '...eceived next ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Name and description of option. The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST not contain any spaces, control characters or periods. * Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium or a particular company or group of companies); * A reference to a further description, if available, for example (in order of preference) an RFC, a published paper, a patent filing, a technical report, documented source code or a computer manual; * For proprietary options, contact information (postal and email address); == 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. To avoid becoming the unwitting perpetrator of a remote-controlled denial-of-service attack, 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. This is particularly important if RTSP commands are issued via UDP, but implementations cannot rely on TCP 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. 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 3712 looks like a reference -- Missing reference section? '2' on line 3402 looks like a reference -- Missing reference section? '3' on line 253 looks like a reference -- Missing reference section? '4' on line 294 looks like a reference -- Missing reference section? '5' on line 817 looks like a reference -- Missing reference section? '6' on line 3709 looks like a reference -- Missing reference section? '7' on line 3433 looks like a reference -- Missing reference section? '8' on line 3430 looks like a reference -- Missing reference section? '9' on line 433 looks like a reference -- Missing reference section? '10' on line 434 looks like a reference -- Missing reference section? '11' on line 435 looks like a reference -- Missing reference section? '12' on line 758 looks like a reference -- Missing reference section? '13' on line 757 looks like a reference -- Missing reference section? '14' on line 467 looks like a reference -- Missing reference section? '15' on line 474 looks like a reference -- Missing reference section? '16' on line 474 looks like a reference -- Missing reference section? '17' on line 662 looks like a reference -- Missing reference section? '19' on line 709 looks like a reference -- Missing reference section? '20' on line 713 looks like a reference -- Missing reference section? '21' on line 906 looks like a reference -- Missing reference section? 'H6' on line 1037 looks like a reference -- Missing reference section? '18' on line 1301 looks like a reference -- Missing reference section? '22' on line 1320 looks like a reference -- Missing reference section? 'H10' on line 1870 looks like a reference -- Missing reference section? 'CRLF' on line 3307 looks like a reference -- Missing reference section? 'H15' on line 3342 looks like a reference -- Missing reference section? '24' on line 3591 looks like a reference -- Missing reference section? '25' on line 3677 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 30 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-08.txt Columbia U./Netscape/RealNetworks 4 January 15, 1998 Expires: July 15, 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 provide a means for choosing delivery 38 mechanisms based upon RTP (RFC 1889). 40 This is a snapshot of the current draft which will become the next 41 version of the ``official'' Internet Draft. 43 Copyright Notice: 45 Copyright (C) The Internet Society (1997). All Rights Reserved. 47 H. Schulzrinne, A. Rao, R. Lanphier Page 1 48 Table of Contents 50 * Contents 51 * 1 Introduction 52 + 1.1 Purpose 53 + 1.2 Requirements 54 + 1.3 Terminology 55 + 1.4 Protocol Properties 56 + 1.5 Extending RTSP 57 + 1.6 Overall Operation 58 + 1.7 RTSP States 59 + 1.8 Relationship with Other Protocols 60 * 2 Notational Conventions 61 * 3 Protocol Parameters 62 + 3.1 RTSP Version 63 + 3.2 RTSP URL 64 + 3.3 Conference Identifiers 65 + 3.4 Session Identifiers 66 + 3.5 SMPTE Relative Timestamps 67 + 3.6 Normal Play Time 68 + 3.7 Absolute Time 69 + 3.8 Option Tags 70 o 3.8.1 Registering New Option Tags with IANA 71 * 4 RTSP Message 72 + 4.1 Message Types 73 + 4.2 Message Headers 74 + 4.3 Message Body 75 + 4.4 Message Length 76 * 5 General Header Fields 77 * 6 Request 78 + 6.1 Request Line 79 + 6.2 Request Header Fields 80 * 7 Response 81 + 7.1 Status-Line 82 o 7.1.1 Status Code and Reason Phrase 83 o 7.1.2 Response Header Fields 84 * 8 Entity 85 + 8.1 Entity Header Fields 86 + 8.2 Entity Body 87 * 9 Connections 88 + 9.1 Pipelining 89 + 9.2 Reliability and Acknowledgements 90 * 10 Method Definitions 91 + 10.1 OPTIONS 92 + 10.2 DESCRIBE 93 + 10.3 ANNOUNCE 95 H. Schulzrinne, A. Rao, R. Lanphier Page 2 96 + 10.4 SETUP 97 + 10.5 PLAY 98 + 10.6 PAUSE 99 + 10.7 TEARDOWN 100 + 10.8 GET_PARAMETER 101 + 10.9 SET_PARAMETER 102 + 10.10 REDIRECT 103 + 10.11 RECORD 104 + 10.12 Embedded (Interleaved) Binary Data 105 * 11 Status Code Definitions 106 + 11.1 Success 2xx 107 o 11.1.1 250 Low on Storage Space 108 + 11.2 Redirection 3xx 109 + 11.3 Client Error 4xx 110 o 11.3.1 405 Method Not Allowed 111 o 11.3.2 451 Parameter Not Understood 112 o 11.3.3 452 Conference Not Found 113 o 11.3.4 453 Not Enough Bandwidth 114 o 11.3.5 454 Session Not Found 115 o 11.3.6 455 Method Not Valid in This State 116 o 11.3.7 456 Header Field Not Valid for Resource 117 o 11.3.8 457 Invalid Range 118 o 11.3.9 458 Parameter Is Read-Only 119 o 11.3.10 459 Aggregate Operation Not Allowed 120 o 11.3.11 460 Only Aggregate Operation Allowed 121 o 11.3.12 461 Unsupported Transport 122 o 11.3.13 462 Destination Unreachable 123 o 11.3.14 551 Option not supported 124 * 12 Header Field Definitions 125 + 12.1 Accept 126 + 12.2 Accept-Encoding 127 + 12.3 Accept-Language 128 + 12.4 Allow 129 + 12.5 Authorization 130 + 12.6 Bandwidth 131 + 12.7 Blocksize 132 + 12.8 Cache-Control 133 + 12.9 Conference 134 + 12.10 Connection 135 + 12.11 Content-Base 136 + 12.12 Content-Encoding 137 + 12.13 Content-Language 138 + 12.14 Content-Length 139 + 12.15 Content-Location 140 + 12.16 Content-Type 141 + 12.17 CSeq 143 H. Schulzrinne, A. Rao, R. Lanphier Page 3 144 + 12.18 Date 145 + 12.19 Expires 146 + 12.20 From 147 + 12.21 Host 148 + 12.22 If-Match 149 + 12.23 If-Modified-Since 150 + 12.24 Last-Modified 151 + 12.25 Location 152 + 12.26 Proxy-Authenticate 153 + 12.27 Proxy-Require 154 + 12.28 Public 155 + 12.29 Range 156 + 12.30 Referer 157 + 12.31 Retry-After 158 + 12.32 Require 159 + 12.33 RTP-Info 160 + 12.34 Scale 161 + 12.35 Speed 162 + 12.36 Server 163 + 12.37 Session 164 + 12.38 Timestamp 165 + 12.39 Transport 166 + 12.40 Unsupported 167 + 12.41 User-Agent 168 + 12.42 Vary 169 + 12.43 Via 170 + 12.44 WWW-Authenticate 171 * 13 Caching 172 * 14 Examples 173 + 14.1 Media on Demand (Unicast) 174 + 14.2 Streaming of a Container file 175 + 14.3 Single Stream Container Files 176 + 14.4 Live Media Presentation Using Multicast 177 + 14.5 Playing media into an existing session 178 + 14.6 Recording 179 * 15 Syntax 180 + 15.1 Base Syntax 181 * 16 Security Considerations 182 * A RTSP Protocol State Machines 183 + A.1 Client State Machine 184 + A.2 Server State Machine 185 * B Interaction with RTP 186 * C Use of SDP for RTSP Session Descriptions 187 + C.1 Definitions 188 o C.1.1 Control URL 189 o C.1.2 Media streams 191 H. Schulzrinne, A. Rao, R. Lanphier Page 4 192 o C.1.3 Payload type(s) 193 o C.1.4 Format-specific parameters 194 o C.1.5 Range of presentation 195 o C.1.6 Time of availability 196 o C.1.7 Connection Information 197 o C.1.8 Entity Tag 198 + C.2 Aggregate Control Not Available 199 + C.3 Aggregate Control Available 200 * D Minimal RTSP implementation 201 + D.1 Client 202 o D.1.1 Basic Playback 203 o D.1.2 Authentication-enabled 204 + D.2 Server 205 o D.2.1 Basic Playback 206 o D.2.2 Authentication-enabled 207 * E Author Addresses 208 * F Acknowledgements 209 * References 211 1 Introduction 213 1.1 Purpose 215 The Real-Time Streaming Protocol (RTSP) establishes and controls 216 either a single or several time-synchronized streams of continuous 217 media such as audio and video. It does not typically deliver the 218 continuous streams itself, although interleaving of the continuous 219 media stream with the control stream is possible (see Section 10.12). 220 In other words, RTSP acts as a ``network remote control'' for 221 multimedia servers. 223 The set of streams to be controlled is defined by a presentation 224 description. This memorandum does not define a format for a 225 presentation description. 227 There is no notion of an RTSP connection; instead, a server maintains 228 a session labeled by an identifier. An RTSP session is in no way tied 229 to a transport-level connection such as a TCP connection. During an 230 RTSP session, an RTSP client may open and close many reliable 231 transport connections to the server to issue RTSP requests. 232 Alternatively, it may use a connectionless transport protocol such as 233 UDP. 235 The streams controlled by RTSP may use RTP [1], but the operation of 236 RTSP does not depend on the transport mechanism used to carry 237 continuous media. 239 H. Schulzrinne, A. Rao, R. Lanphier Page 5 240 The protocol is intentionally similar in syntax and operation to 241 HTTP/1.1 [2] so that extension mechanisms to HTTP can in most cases 242 also be added to RTSP. However, RTSP differs in a number of important 243 aspects from HTTP: 245 * RTSP introduces a number of new methods and has a different 246 protocol identifier. 247 * An RTSP server needs to maintain state by default in almost all 248 cases, as opposed to the stateless nature of HTTP. 249 * Both an RTSP server and client can issue requests. 250 * Data is carried out-of-band by a different protocol. (There is an 251 exception to this.) 252 * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, 253 consistent with current HTML internationalization efforts [3]. 254 * The Request-URI always contains the absolute URI. Because of 255 backward compatibility with a historical blunder, HTTP/1.1 [2] 256 carries only the absolute path in the request and puts the host 257 name in a separate header field. 259 This makes ``virtual hosting'' easier, where a single host with one 260 IP address hosts several document trees. 262 The protocol supports the following operations: 264 Retrieval of media from media server: 265 The client can request a presentation description via HTTP or 266 some other method. If the presentation is being multicast, the 267 presentation description contains the multicast addresses and 268 ports to be used for the continuous media. If the presentation 269 is to be sent only to the client via unicast, the client 270 provides the destination for security reasons. 272 Invitation of a media server to a conference: 273 A media server can be ``invited'' to join an existing 274 conference, either to play back media into the presentation or 275 to record all or a subset of the media in a presentation. This 276 mode is useful for distributed teaching applications. Several 277 parties in the conference may take turns ``pushing the remote 278 control buttons''. 280 Addition of media to an existing presentation: 281 Particularly for live presentations, it is useful if the server 282 can tell the client about additional media becoming available. 284 RTSP requests may be handled by proxies, tunnels and caches as in 285 HTTP/1.1 [2]. 287 H. Schulzrinne, A. Rao, R. Lanphier Page 6 288 1.2 Requirements 290 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 291 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and 292 ``OPTIONAL'' in this document are to be interpreted as described in 293 RFC 2119 [4]. 295 1.3 Terminology 297 Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not 298 listed here are defined as in HTTP/1.1. 300 Aggregate control: 301 The control of the multiple streams using a single timeline by 302 the server. For audio/video feeds, this means that the client 303 may issue a single play or pause message to control both the 304 audio and video feeds. 306 Conference: 307 a multiparty, multimedia presentation, where ``multi'' implies 308 greater than or equal to one. 310 Client: 311 The client requests continuous media data from the media 312 server. 314 Connection: 315 A transport layer virtual circuit established between two 316 programs for the purpose of communication. 318 Container file: 319 A file which may contain multiple media streams which often 320 comprise a presentation when played together. RTSP servers may 321 offer aggregate control on these files, though the concept of a 322 container file is not embedded in the protocol. 324 Continuous media: 325 Data where there is a timing relationship between source and 326 sink; that is, the sink must reproduce the timing relationship 327 that existed at the source. The most common examples of 328 continuous media are audio and motion video. Continuous media 329 can be real-time (interactive), where there is a ``tight'' 330 timing relationship between source and sink, or streaming 331 (playback), where the relationship is less strict. 333 H. Schulzrinne, A. Rao, R. Lanphier Page 7 334 Entity: 335 The information transferred as the payload of a request or 336 response. An entity consists of metainformation in the form of 337 entity-header fields and content in the form of an entity-body, 338 as described in Section 8. 340 Media initialization: 341 Datatype/codec specific initialization. This includes such 342 things as clockrates, color tables, etc. Any 343 transport-independent information which is required by a client 344 for playback of a media stream occurs in the media 345 initialization phase of stream setup. 347 Media parameter: 348 Parameter specific to a media type that may be changed before 349 or during stream playback. 351 Media server: 352 The server providing playback or recording services for one or 353 more media streams. Different media streams within a 354 presentation may originate from different media servers. A 355 media server may reside on the same or a different host as the 356 web server the presentation is invoked from. 358 Media server indirection: 359 Redirection of a media client to a different media server. 361 (Media) stream: 362 A single media instance, e.g., an audio stream or a video 363 stream as well as a single whiteboard or shared application 364 group. When using RTP, a stream consists of all RTP and RTCP 365 packets created by a source within an RTP session. This is 366 equivalent to the definition of a DSM-CC stream([5]). 368 Message: 369 The basic unit of RTSP communication, consisting of a 370 structured sequence of octets matching the syntax defined in 371 Section 15 and transmitted via a connection or a connectionless 372 protocol. 374 Participant: 375 Member of a conference. A participant may be a machine, e.g., a 376 media record or playback server. 378 H. Schulzrinne, A. Rao, R. Lanphier Page 8 379 Presentation: 380 A set of one or more streams presented to the client as a 381 complete media feed, using a presentation description as 382 defined below. In most cases in the RTSP context, this implies 383 aggregate control of those streams, but does not have to. 385 Presentation description: 386 A presentation description contains information about one or 387 more media streams within a presentation, such as the set of 388 encodings, network addresses and information about the content. 389 Other IETF protocols such as SDP (RFC XXXX [6]) use the term 390 ``session'' for a live presentation. The presentation 391 description may take several different formats, including but 392 not limited to the session description format SDP. 394 Response: 395 An RTSP response. If an HTTP response is meant, that is 396 indicated explicitly. 398 Request: 399 An RTSP request. If an HTTP request is meant, that is indicated 400 explicitly. 402 RTSP session: 403 A complete RTSP ``transaction'', e.g., the viewing of a movie. 404 A session typically consists of a client setting up a transport 405 mechanism for the continuous media stream (SETUP), starting the 406 stream with PLAY or RECORD, and closing the stream with 407 TEARDOWN. 409 Transport initialization: 410 The negotiation of transport information (e.g., port numbers, 411 transport protocols) between the client and the server. 413 1.4 Protocol Properties 415 RTSP has the following properties: 417 Extendable: 418 New methods and parameters can be easily added to RTSP. 420 Easy to parse: 421 RTSP can be parsed by standard HTTP or MIME parsers. 423 H. Schulzrinne, A. Rao, R. Lanphier Page 9 424 Secure: 425 RTSP re-uses web security mechanisms, either at the transport 426 level (TLS, RFC XXXX [7]) or within the protocol itself. All 427 HTTP authentication mechanisms such as basic (RFC 2068 [2, 428 Section 11.1]) and digest authentication (RFC 2069 [8]) are 429 directly applicable. 431 Transport-independent: 432 RTSP may use either an unreliable datagram protocol (UDP) (RFC 433 768 [9]), a reliable datagram protocol (RDP, RFC 1151, not 434 widely used [10]) or a reliable stream protocol such as TCP 435 (RFC 793 [11]) as it implements application-level reliability. 437 Multi-server capable: 438 Each media stream within a presentation can reside on a 439 different server. The client automatically establishes several 440 concurrent control sessions with the different media servers. 441 Media synchronization is performed at the transport level. 443 Control of recording devices: 444 The protocol can control both recording and playback devices, 445 as well as devices that can alternate between the two modes 446 (``VCR''). 448 Separation of stream control and conference initiation: 449 Stream control is divorced from inviting a media server to a 450 conference. The only requirement is that the conference 451 initiation protocol either provides or can be used to create a 452 unique conference identifier. In particular, SIP [12] or H.323 453 [13] may be used to invite a server to a conference. 455 Suitable for professional applications: 456 RTSP supports frame-level accuracy through SMPTE time stamps to 457 allow remote digital editing. 459 Presentation description neutral: 460 The protocol does not impose a particular presentation 461 description or metafile format and can convey the type of 462 format to be used. However, the presentation description must 463 contain at least one RTSP URI. 465 Proxy and firewall friendly: 466 The protocol should be readily handled by both application and 467 transport-layer (SOCKS [14]) firewalls. A firewall may need to 468 understand the SETUP method to open a ``hole'' for the UDP 469 media stream. 471 HTTP-friendly: 472 Where sensible, RTSP reuses HTTP concepts, so that the existing 473 infrastructure can be reused. This infrastructure includes PICS 474 (Platform for Internet Content Selection [15,16]) for 475 associating labels with content. However, RTSP does not just 476 add methods to HTTP since the controlling continuous media 477 requires server state in most cases. 479 Appropriate server control: 480 If a client can start a stream, it must be able to stop a 481 stream. Servers should not start streaming to clients in such a 482 way that clients cannot stop the stream. 484 Transport negotiation: 485 The client can negotiate the transport method prior to actually 486 needing to process a continuous media stream. 488 Capability negotiation: 489 If basic features are disabled, there must be some clean 490 mechanism for the client to determine which methods are not 491 going to be implemented. This allows clients to present the 492 appropriate user interface. For example, if seeking is not 493 allowed, the user interface must be able to disallow moving a 494 sliding position indicator. 496 An earlier requirement in RTSP was multi-client capability. 497 However, it was determined that a better approach was to make sure 498 that the protocol is easily extensible to the multi-client 499 scenario. Stream identifiers can be used by several control 500 streams, so that ``passing the remote'' would be possible. The 501 protocol would not address how several clients negotiate access; 502 this is left to either a ``social protocol'' or some other floor 503 control mechanism. 505 1.5 Extending RTSP 507 Since not all media servers have the same functionality, media servers 508 by necessity will support different sets of requests. For example: 509 * A server may only be capable of playback thus has no need to 510 support the RECORD request. 511 * A server may not be capable of seeking (absolute positioning) if 512 it is to support live events only. 513 * Some servers may not support setting stream parameters and thus 514 not support GET_PARAMETER and SET_PARAMETER. 516 A server SHOULD implement all header fields described in Section 12. 518 It is up to the creators of presentation descriptions not to ask the 519 impossible of a server. This situation is similar in HTTP/1.1 [2], 520 where the methods described in [H19.6] are not likely to be supported 521 across all servers. 523 RTSP can be extended in three ways, listed here in order of the 524 magnitude of changes supported: 526 * Existing methods can be extended with new parameters, as long as 527 these parameters can be safely ignored by the recipient. (This is 528 equivalent to adding new parameters to an HTML tag.) If the client 529 needs negative acknowledgement when a method extension is not 530 supported, a tag corresponding to the extension may be added in 531 the Require: field (see Section 12.32). 532 * New methods can be added. If the recipient of the message does not 533 understand the request, it responds with error code 501 (Not 534 implemented) and the sender should not attempt to use this method 535 again. A client may also use the OPTIONS method to inquire about 536 methods supported by the server. The server SHOULD list the 537 methods it supports using the Public response header. 538 * A new version of the protocol can be defined, allowing almost all 539 aspects (except the position of the protocol version number) to 540 change. 542 1.6 Overall Operation 544 Each presentation and media stream may be identified by an RTSP URL. 545 The overall presentation and the properties of the media the 546 presentation is made up of are defined by a presentation description 547 file, the format of which is outside the scope of this specification. 548 The presentation description file may be obtained by the client using 549 HTTP or other means such as email and may not necessarily be stored on 550 the media server. 552 For the purposes of this specification, a presentation description is 553 assumed to describe one or more presentations, each of which maintains 554 a common time axis. For simplicity of exposition and without loss of 555 generality, it is assumed that the presentation description contains 556 exactly one such presentation. A presentation may contain several 557 media streams. 559 The presentation description file contains a description of the media 560 streams making up the presentation, including their encodings, 561 language, and other parameters that enable the client to choose the 562 most appropriate combination of media. In this presentation 563 description, each media stream that is individually controllable by 564 RTSP is identified by an RTSP URL, which points to the media server 565 handling that particular media stream and names the stream stored on 566 that server. Several media streams can be located on different 567 servers; for example, audio and video streams can be split across 568 servers for load sharing. The description also enumerates which 569 transport methods the server is capable of. 571 Besides the media parameters, the network destination address and port 572 need to be determined. Several modes of operation can be 573 distinguished: 575 Unicast: 576 The media is transmitted to the source of the RTSP request, 577 with the port number chosen by the client. Alternatively, the 578 media is transmitted on the same reliable stream as RTSP. 580 Multicast, server chooses address: 581 The media server picks the multicast address and port. This is 582 the typical case for a live or near-media-on-demand 583 transmission. 585 Multicast, client chooses address: 586 If the server is to participate in an existing multicast 587 conference, the multicast address, port and encryption key are 588 given by the conference description, established by means 589 outside the scope of this specification. 591 1.7 RTSP States 593 RTSP controls a stream which may be sent via a separate protocol, 594 independent of the control channel. For example, RTSP control may 595 occur on a TCP connection while the data flows via UDP. Thus, data 596 delivery continues even if no RTSP requests are received by the media 597 server. Also, during its lifetime, a single media stream may be 598 controlled by RTSP requests issued sequentially on different TCP 599 connections. Therefore, the server needs to maintain ``session state'' 600 to be able to correlate RTSP requests with a stream. The state 601 transitions are described in Section A. 603 Many methods in RTSP do not contribute to state. However, the 604 following play a central role in defining the allocation and usage of 605 stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and 606 TEARDOWN. 608 SETUP: 609 Causes the server to allocate resources for a stream and start 610 an RTSP session. 612 PLAY and RECORD: 613 Starts data transmission on a stream allocated via SETUP. 615 PAUSE: 616 Temporarily halts a stream without freeing server resources. 618 TEARDOWN: 619 Frees resources associated with the stream. The RTSP session 620 ceases to exist on the server. 622 1.8 Relationship with Other Protocols 624 RTSP has some overlap in functionality with HTTP. It also may interact 625 with HTTP in that the initial contact with streaming content is often 626 to be made through a web page. The current protocol specification aims 627 to allow different hand-off points between a web server and the media 628 server implementing RTSP. For example, the presentation description 629 can be retrieved using HTTP or RTSP, which reduces roundtrips in 630 web-browser-based scenarios, yet also allows for standalone RTSP 631 servers and clients which do not rely on HTTP at all. 633 However, RTSP differs fundamentally from HTTP in that data delivery 634 takes place out-of-band in a different protocol. HTTP is an asymmetric 635 protocol where the client issues requests and the server responds. In 636 RTSP, both the media client and media server can issue requests. RTSP 637 requests are also not stateless; they may set parameters and continue 638 to control a media stream long after the request has been 639 acknowledged. 641 Re-using HTTP functionality has advantages in at least two areas, 642 namely security and proxies. The requirements are very similar, so 643 having the ability to adopt HTTP work on caches, proxies and 644 authentication is valuable. 646 While most real-time media will use RTP as a transport protocol, RTSP 647 is not tied to RTP. 649 RTSP assumes the existence of a presentation description format that 650 can express both static and temporal properties of a presentation 651 containing several media streams. 653 2 Notational Conventions 655 Since many of the definitions and syntax are identical to HTTP/1.1, 656 this specification only points to the section where they are defined 657 rather than copying it. For brevity, [HX.Y] is to be taken to refer to 658 Section X.Y of the current HTTP/1.1 specification (RFC 2068 [2]). 660 All the mechanisms specified in this document are described in both 661 prose and an augmented Backus-Naur form (BNF) similar to that used in 662 [H2.1]. It is described in detail in RFC 2234 [17], with the 663 difference that this RTSP specification maintains the ``1#'' notation 664 for comma-separated lists. 666 In this draft, we use indented and smaller-type paragraphs to provide 667 background and motivation. This is intended to give readers who were 668 not involved with the formulation of the specification an 669 understanding of why things are the way that they are in RTSP. 671 3 Protocol Parameters 673 3.1 RTSP Version 675 [H3.1] applies, with HTTP replaced by RTSP. 677 3.2 RTSP URL 679 The ``rtsp'', ``rtspu'' and ``rtsps'' schemes are used to refer to 680 network resources via the RTSP protocol. This section defines the 681 scheme-specific syntax and semantics for RTSP URLs. 683 rtsp_URL = ( "rtsp:" | "rtspu:" | "rtsps:" ) 684 "//" host [ ":" port ] [ abs_path ] 685 host = 688 port = *DIGIT 690 abs_path is defined in [H3.2.1]. 692 Note that fragment and query identifiers do not have a well-defined 693 meaning at this time, with the interpretation left to the RTSP 694 server. 696 The scheme rtsp requires that commands are issued via a reliable 697 protocol (within the Internet, TCP), while the scheme rtspu identifies 698 an unreliable protocol (within the Internet, UDP). The scheme rtsps 699 indicates that a TCP connection secured by TLS (RFC XXXX) [7] must be 700 used. 702 If the port is empty or not given, port 554 is assumed. The semantics 703 are that the identified resource can be controlled by RTSP at the 704 server listening for TCP (scheme ``rtsp'') connections or UDP (scheme 705 ``rtspu'') packets on that port of host, and the Request-URI for the 706 resource is rtsp_URL. 708 The use of IP addresses in URLs SHOULD be avoided whenever possible 709 (see RFC 1924 [19]). 711 A presentation or a stream is identified by a textual media 712 identifier, using the character set and escape conventions [H3.2] of 713 URLs (RFC 1738 [20]). URLs may refer to a stream or an aggregate of 714 streams, i.e., a presentation. Accordingly, requests described in 715 Section 10 can apply to either the whole presentation or an individual 716 stream within the presentation. Note that some request methods can 717 only be applied to streams, not presentations and vice versa. 719 For example, the RTSP URL: 720 rtsp://media.example.com:554/twister/audiotrack 722 identifies the audio stream within the presentation ``twister'', which 723 can be controlled via RTSP requests issued over a TCP connection to 724 port 554 of host media.example.com. 726 Also, the RTSP URL: 727 rtsp://media.example.com:554/twister 729 identifies the presentation ``twister'', which may be composed of 730 audio and video streams. 732 This does not imply a standard way to reference streams in URLs. 733 The presentation description defines the hierarchical relationships 734 in the presentation and the URLs for the individual streams. A 735 presentation description may name a stream ``a.mov'' and the whole 736 presentation ``b.mov''. 738 The path components of the RTSP URL are opaque to the client and do 739 not imply any particular file system structure for the server. 741 This decoupling also allows presentation descriptions to be used 742 with non-RTSP media control protocols simply by replacing the 743 scheme in the URL. 745 3.3 Conference Identifiers 747 Conference identifiers are opaque to RTSP and are encoded using 748 standard URI encoding methods (i.e., LWS is escaped with %). They can 749 contain any octet value. The conference identifier MUST be globally 750 unique. For H.323, the conferenceID value is to be used. 752 conference-id = 1*xchar 754 Conference identifiers are used to allow RTSP sessions to obtain 755 parameters from multimedia conferences the media server is 756 participating in. These conferences are created by protocols 757 outside the scope of this specification, e.g., H.323 [13] or SIP 758 [12]. Instead of the RTSP client explicitly providing transport 759 information, for example, it asks the media server to use the 760 values in the conference description instead. 762 3.4 Session Identifiers 764 Session identifiers are opaque strings of arbitrary length. Linear 765 white space must be URL-escaped. A session identifier MUST be chosen 766 randomly and MUST be at least eight octets long to make guessing it 767 more difficult. (See Section 16.) 769 session-id = 1*( ALPHA | DIGIT | safe ) 771 3.5 SMPTE Relative Timestamps 773 A SMPTE relative timestamp expresses time relative to the start of 774 the clip. Relative timestamps are expressed as SMPTE time codes for 775 frame-level access accuracy. The time code has the format 776 hours:minutes:seconds:frames.subframes, with the origin at the start 777 of the clip. The default smpte format is``SMPTE 30 drop'' format, with 778 frame rate is 29.97 frames per second. Other SMPTE codes MAY be 779 supported (such as "SMPTE 25") through the use of alternative use of 780 "smpte time". For the ``frames'' field in the time value can assume 781 the values 0 through 29. The difference between 30 and 29.97 frames 782 per second is handled by dropping the first two frame indices (values 783 00 and 01) of every minute, except every tenth minute. If the frame 784 value is zero, it may be omitted. Subframes are measured in 785 one-hundredth of a frame. 787 smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ] 788 smpte-type = "smpte" | "smpte-30-drop" | "smpte-25" 789 ; other timecodes may be added 790 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] 791 [ "." 1*2DIGIT ] 793 Examples: 794 smpte=10:12:33:20- 795 smpte=10:07:33- 796 smpte=10:07:00-10:07:33:05.01 797 smpte-25=10:07:00-10:07:33:05.01 799 3.6 Normal Play Time 801 Normal play time (NPT) indicates the stream absolute position 802 relative to the beginning of the presentation. The timestamp consists 803 of a decimal fraction. The part left of the decimal may be expressed 804 in either seconds or hours, minutes, and seconds. The part right of 805 the decimal point measures fractions of a second. 807 The beginning of a presentation corresponds to 0.0 seconds. Negative 808 values are not defined. The special constant now is defined as the 809 current instant of a live event. It may be used only for live events. 811 NPT is defined as in DSM-CC: ``Intuitively, NPT is the clock the 812 viewer associates with a program. It is often digitally displayed on a 813 VCR. NPT advances normally when in normal play mode (scale = 1), 814 advances at a faster rate when in fast scan forward (high positive 815 scale ratio), decrements when in scan reverse (high negative scale 816 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 817 SMPTE time codes.'' [5] 819 npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) 820 npt-time = "now" | npt-sec | npt-hhmmss 821 npt-sec = 1*DIGIT [ "." *DIGIT ] 822 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 823 npt-hh = 1*DIGIT ; any positive number 824 npt-mm = 1*2DIGIT ; 0-59 825 npt-ss = 1*2DIGIT ; 0-59 827 Examples: 828 npt=123.45-125 829 npt=12:05:35.3- 830 npt=now- 831 The syntax conforms to ISO 8601. The npt-sec notation is optimized 832 for automatic generation, the ntp-hhmmss notation for consumption 833 by human readers. The ``now'' constant allows clients to request to 834 receive the live feed rather than the stored or time-delayed 835 version. This is needed since neither absolute time nor zero time 836 are appropriate for this case. 838 3.7 Absolute Time 840 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 841 Fractions of a second may be indicated. 843 utc-range = "clock" "=" utc-time "-" [ utc-time ] 844 utc-time = utc-date "T" utc-time "Z" 845 utc-date = 8DIGIT ; < YYYYMMDD > 846 utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > 848 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 849 UTC: 851 19961108T143720.25Z 853 3.8 Option Tags 855 Option tags are unique identifiers used to designate new options in 856 RTSP. These tags are used in in Require (Section 12.32) and 857 Proxy-Require (Section 12.27) header fields. 859 Syntax: 861 option-tag = 1*xchar 863 The creator of a new RTSP option should either prefix the option with 864 a reverse domain name (e.g., ``com.foo.mynewfeature'' is an apt name 865 for a feature whose inventor can be reached at ``foo.com''), or 866 register the new option with the Internet Assigned Numbers Authority 867 (IANA). 869 3.8.1 Registering New Option Tags with IANA 871 When registering a new RTSP option, the following information should 872 be provided: 874 * Name and description of option. The name may be of any length, but 875 SHOULD be no more than twenty characters long. The name MUST not 876 contain any spaces, control characters or periods. 877 * Indication of who has change control over the option (for example, 878 IETF, ISO, ITU-T, other international standardization bodies, a 879 consortium or a particular company or group of companies); 880 * A reference to a further description, if available, for example 881 (in order of preference) an RFC, a published paper, a patent 882 filing, a technical report, documented source code or a computer 883 manual; 884 * For proprietary options, contact information (postal and email 885 address); 887 4 RTSP Message 889 RTSP is a text-based protocol and uses the ISO 10646 character set 890 in UTF-8 encoding (RFC XXXX [21]). Lines are terminated by CRLF, but 891 receivers should be prepared to also interpret CR and LF by themselves 892 as line terminators. 894 Text-based protocols make it easier to add optional parameters in a 895 self-describing manner. Since the number of parameters and the 896 frequency of commands is low, processing efficiency is not a 897 concern. Text-based protocols, if done carefully, also allow easy 898 implementation of research prototypes in scripting languages such 899 as Tcl, Visual Basic and Perl. 901 The 10646 character set avoids tricky character set switching, but 902 is invisible to the application as long as US-ASCII is being used. 903 This is also the encoding used for RTCP. ISO 8859-1 translates 904 directly into Unicode with a high-order octet of zero. ISO 8859-1 905 characters with the most-significant bit set are represented as 906 1100001x 10xxxxxx. (See RFC XXXX [21]) 908 RTSP messages can be carried over any lower-layer transport protocol 909 that is 8-bit clean. 911 Requests contain methods, the object the method is operating upon and 912 parameters to further describe the method. Methods are idempotent, 913 unless otherwise noted. Methods are also designed to require little or 914 no state maintenance at the media server. 916 4.1 Message Types 918 See [H4.1] 920 4.2 Message Headers 922 See [H4.2] 924 4.3 Message Body 926 See [H4.3] 928 4.4 Message Length 930 When a message body is included with a message, the length of that 931 body is determined by one of the following (in order of precedence): 933 1. Any response message which MUST NOT include a message body 934 (such as the 1xx, 204, and 304 responses) is always terminated 935 by the first empty line after the header fields, regardless of 936 the entity-header fields present in the message. (Note: An 937 empty line consists of only CRLF.) 939 2. If a Content-Length header field (section 12.14) is present, 940 its value in bytes represents the length of the message-body. 941 If this header field is not present, a value of zero is 942 assumed. 944 3. By the server closing the connection. (Closing the connection 945 cannot be used to indicate the end of a request body, since 946 that would leave no possibility for the server to send back a 947 response.) 949 Note that RTSP does not (at present) support the HTTP/1.1 ``chunked'' 950 transfer coding(see [H3.6]) and requires the presence of the 951 Content-Length header field. 953 Given the moderate length of presentation descriptions returned, 954 the server should always be able to determine its length, even if 955 it is generated dynamically, making the chunked transfer encoding 956 unnecessary. Even though Content-Length must be present if there is 957 any entity body, the rules ensure reasonable behavior even if the 958 length is not given explicitly. 960 5 General Header Fields 962 See [H4.5], except that Pragma, Transfer-Encoding and Upgrade 963 headers are not defined: 965 general-header = Cache-Control ; Section 12.8 966 | Connection ; Section 12.10 967 | Date ; Section 12.18 968 | Via ; Section 12.43 970 6 Request 972 A request message from a client to a server or vice versa includes, 973 within the first line of that message, the method to be applied to the 974 resource, the identifier of the resource, and the protocol version in 975 use. 977 Request = Request-Line ; Section 6.1 978 *( general-header ; Section 5 979 | request-header ; Section 6.2 980 | entity-header ) ; Section 8.1 981 CRLF 982 [ message-body ] ; Section 4.3 984 6.1 Request Line 986 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 988 Method = "DESCRIBE" ; Section 10.2 989 | "ANNOUNCE" ; Section 10.3 990 | "GET_PARAMETER" ; Section 10.8 991 | "OPTIONS" ; Section 10.1 992 | "PAUSE" ; Section 10.6 993 | "PLAY" ; Section 10.5 994 | "RECORD" ; Section 10.11 995 | "REDIRECT" ; Section 10.10 996 | "SETUP" ; Section 10.4 997 | "SET_PARAMETER" ; Section 10.9 998 | "TEARDOWN" ; Section 10.7 999 | extension-method 1001 extension-method = token 1003 Request-URI = "*" | absolute_URI 1005 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 1007 6.2 Request Header Fields 1009 request-header = Accept ; Section 12.1 1010 | Accept-Encoding ; Section 12.2 1011 | Accept-Language ; Section 12.3 1012 | Authorization ; Section 12.5 1013 | From ; Section 12.20 1014 | If-Modified-Since ; Section 12.23 1015 | Range ; Section 12.29 1016 | Referer ; Section 12.30 1017 | User-Agent ; Section 12.41 1019 Note that in contrast to HTTP/1.1 [2], RTSP requests always contain 1020 the absolute URL (that is, including the scheme, host and port) rather 1021 than just the absolute path. 1023 HTTP/1.1 requires servers to understand the absolute URL, but 1024 clients are supposed to use the Host request header. This is purely 1025 needed for backward-compatibility with HTTP/1.0 servers, a 1026 consideration that does not apply to RTSP. 1028 The asterisk "*" in the Request-URI means that the request does not 1029 apply to a particular resource, but to the server itself, and is only 1030 allowed when the method used does not necessarily apply to a resource. 1031 One example would be: 1033 OPTIONS * RTSP/1.0 1035 7 Response 1037 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1038 Also, RTSP defines additional status codes and does not define some 1039 HTTP codes. The valid response codes and the methods they can be used 1040 with are defined in Table 1. 1042 After receiving and interpreting a request message, the recipient 1043 responds with an RTSP response message. 1045 Response = Status-Line ; Section 7.1 1046 *( general-header ; Section 5 1047 | response-header ; Section 7.1.2 1048 | entity-header ) ; Section 8.1 1049 CRLF 1050 [ message-body ] ; Section 4.3 1052 7.1 Status-Line 1054 The first line of a Response message is the Status-Line, consisting 1055 of the protocol version followed by a numeric status code, and the 1056 textual phrase associated with the status code, with each element 1057 separated by SP characters. No CR or LF is allowed except in the final 1058 CRLF sequence. 1060 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 1062 7.1.1 Status Code and Reason Phrase 1064 The Status-Code element is a 3-digit integer result code of the 1065 attempt to understand and satisfy the request. These codes are fully 1066 defined in Section 11. The Reason-Phrase is intended to give a short 1067 textual description of the Status-Code. The Status-Code is intended 1068 for use by automata and the Reason-Phrase is intended for the human 1069 user. The client is not required to examine or display the 1070 Reason-Phrase. 1072 The first digit of the Status-Code defines the class of response. The 1073 last two digits do not have any categorization role. There are 5 1074 values for the first digit: 1076 * 1xx: Informational - Request received, continuing process 1077 * 2xx: Success - The action was successfully received, understood, 1078 and accepted 1079 * 3xx: Redirection - Further action must be taken in order to 1080 complete the request 1081 * 4xx: Client Error - The request contains bad syntax or cannot be 1082 fulfilled 1083 * 5xx: Server Error - The server failed to fulfill an apparently 1084 valid request 1086 The individual values of the numeric status codes defined for 1087 RTSP/1.0, and an example set of corresponding Reason-Phrase's, are 1088 presented below. The reason phrases listed here are only recommended - 1089 they may be replaced by local equivalents without affecting the 1090 protocol. Note that RTSP adopts most HTTP/1.1 [2] status codes and 1091 adds RTSP-specific status codes starting at x50 to avoid conflicts 1092 with newly defined HTTP status codes. 1094 Status-Code = "100" ; Continue 1095 | "200" ; OK 1096 | "201" ; Created 1097 | "250" ; Low on Storage Space 1098 | "300" ; Multiple Choices 1099 | "301" ; Moved Permanently 1100 | "302" ; Moved Temporarily 1101 | "303" ; See Other 1102 | "304" ; Not Modified 1103 | "305" ; Use Proxy 1104 | "400" ; Bad Request 1105 | "401" ; Unauthorized 1106 | "402" ; Payment Required 1107 | "403" ; Forbidden 1108 | "404" ; Not Found 1109 | "405" ; Method Not Allowed 1110 | "406" ; Not Acceptable 1111 | "407" ; Proxy Authentication Required 1112 | "408" ; Request Time-out 1113 | "410" ; Gone 1114 | "411" ; Length Required 1115 | "412" ; Precondition Failed 1116 | "413" ; Request Entity Too Large 1117 | "414" ; Request-URI Too Large 1118 | "415" ; Unsupported Media Type 1119 | "451" ; Parameter Not Understood 1120 | "452" ; Conference Not Found 1121 | "453" ; Not Enough Bandwidth 1122 | "454" ; Session Not Found 1123 | "455" ; Method Not Valid in This State 1124 | "456" ; Header Field Not Valid for Resource 1125 | "457" ; Invalid Range 1126 | "458" ; Parameter Is Read-Only 1127 | "459" ; Aggregate operation not allowed 1128 | "460" ; Only aggregate operation allowed 1129 | "461" ; Unsupported transport 1130 | "462" ; Destination unreachable 1131 | "500" ; Internal Server Error 1132 | "501" ; Not Implemented 1133 | "502" ; Bad Gateway 1134 | "503" ; Service Unavailable 1135 | "504" ; Gateway Time-out 1136 | "505" ; RTSP Version not supported 1137 | "551" ; Option not supported 1138 | extension-code 1140 extension-code = 3DIGIT 1142 Reason-Phrase = * 1144 RTSP status codes are extensible. RTSP applications are not required 1145 to understand the meaning of all registered status codes, though such 1146 understanding is obviously desirable. However, applications MUST 1147 understand the class of any status code, as indicated by the first 1148 digit, and treat any unrecognized response as being equivalent to the 1149 x00 status code of that class, with the exception that an unrecognized 1150 response MUST NOT be cached. For example, if an unrecognized status 1151 code of 431 is received by the client, it can safely assume that there 1152 was something wrong with its request and treat the response as if it 1153 had received a 400 status code. In such cases, user agents SHOULD 1154 present to the user the entity returned with the response, since that 1155 entity is likely to include human-readable information which will 1156 explain the unusual status. 1158 Code reason 1160 100 Continue all 1162 200 OK all 1163 201 Created RECORD 1164 250 Low on Storage Space RECORD 1166 300 Multiple Choices all 1167 301 Moved Permanently all 1168 302 Moved Temporarily all 1169 303 See Other all 1170 305 Use Proxy all 1171 400 Bad Request all 1172 401 Unauthorized all 1173 402 Payment Required all 1174 403 Forbidden all 1175 404 Not Found all 1176 405 Method Not Allowed all 1177 406 Not Acceptable all 1178 407 Proxy Authentication Required all 1179 408 Request Timeout all 1180 410 Gone all 1181 411 Length Required all 1182 412 Precondition Failed DESCRIBE, SETUP 1183 413 Request Entity Too Large all 1184 414 Request-URI Too Long all 1185 415 Unsupported Media Type all 1186 451 Invalid parameter SETUP 1187 452 Illegal Conference Identifier SETUP 1188 453 Not Enough Bandwidth SETUP 1189 454 Session Not Found all 1190 455 Method Not Valid In This State all 1191 456 Header Field Not Valid all 1192 457 Invalid Range PLAY 1193 458 Parameter Is Read-Only SET_PARAMETER 1194 459 Aggregate Operation Not Allowed all 1195 460 Only Aggregate Operation Allowed all 1196 461 Unsupported Transport all 1197 462 Destination Unreachable all 1199 500 Internal Server Error all 1200 501 Not Implemented all 1201 502 Bad Gateway all 1202 503 Service Unavailable all 1203 504 Gateway Timeout all 1204 505 RTSP Version Not Supported all 1205 551 Option not support all 1207 Table 1: Status codes and their usage with RTSP methods 1209 7.1.2 Response Header Fields 1211 The response-header fields allow the request recipient to pass 1212 additional information about the response which cannot be placed in 1213 the Status-Line. These header fields give information about the server 1214 and about further access to the resource identified by the 1215 Request-URI. 1217 response-header = Location ; Section 12.25 1218 | Proxy-Authenticate ; Section 12.26 1219 | Public ; Section 12.28 1220 | Retry-After ; Section 12.31 1221 | Server ; Section 12.36 1222 | Vary ; Section 12.42 1223 | WWW-Authenticate ; Section 12.44 1225 Response-header field names can be extended reliably only in 1226 combination with a change in the protocol version. However, new or 1227 experimental header fields MAY be given the semantics of 1228 response-header fields if all parties in the communication recognize 1229 them to be response-header fields. Unrecognized header fields are 1230 treated as entity-header fields. 1232 8 Entity 1234 Request and Response messages MAY transfer an entity if not 1235 otherwise restricted by the request method or response status code. An 1236 entity consists of entity-header fields and an entity-body, although 1237 some responses will only include the entity-headers. 1239 In this section, both sender and recipient refer to either the client 1240 or the server, depending on who sends and who receives the entity. 1242 8.1 Entity Header Fields 1244 Entity-header fields define optional metainformation about the 1245 entity-body or, if no body is present, about the resource identified 1246 by the request. 1248 entity-header = Allow ; Section 12.4 1249 | Content-Base ; Section 12.11 1250 | Content-Encoding ; Section 12.12 1251 | Content-Language ; Section 12.13 1252 | Content-Length ; Section 12.14 1253 | Content-Location ; Section 12.15 1254 | Content-Type ; Section 12.16 1255 | Expires ; Section 12.19 1256 | Last-Modified ; Section 12.24 1257 | extension-header 1258 extension-header = message-header 1260 The extension-header mechanism allows additional entity-header fields 1261 to be defined without changing the protocol, but these fields cannot 1262 be assumed to be recognizable by the recipient. Unrecognized header 1263 fields SHOULD be ignored by the recipient and forwarded by proxies. 1265 8.2 Entity Body 1267 See [H7.2] 1269 9 Connections 1271 RTSP requests can be transmitted in several different ways: 1273 * persistent transport connections used for several request-response 1274 transactions; 1275 * one connection per request/response transaction; 1276 * connectionless mode. 1278 The type of transport connection is defined by the RTSP URI 1279 (Section 3.2). For the scheme ``rtsp'', a persistent connection is 1280 assumed, while the scheme ``rtspu'' calls for RTSP requests to be sent 1281 without setting up a connection. 1283 Unlike HTTP, RTSP allows the media server to send requests to the 1284 media client. However, this is only supported for persistent 1285 connections, as the media server otherwise has no reliable way of 1286 reaching the client. Also, this is the only way that requests from 1287 media server to client are likely to traverse firewalls. 1289 9.1 Pipelining 1291 A client that supports persistent connections or connectionless mode 1292 MAY ``pipeline'' its requests (i.e., send multiple requests without 1293 waiting for each response). A server MUST send its responses to those 1294 requests in the same order that the requests were received. 1296 9.2 Reliability and Acknowledgements 1298 Requests are acknowledged by the receiver unless they are sent to a 1299 multicast group. If there is no acknowledgement, the sender may resend 1300 the same message after a timeout of one round-trip time (RTT). The 1301 round-trip time is estimated as in TCP (RFC 1123) [18], with an 1302 initial round-trip value of 500 ms. An implementation MAY cache the 1303 last RTT measurement as the initial value for future connections. 1305 If a reliable transport protocol is used to carry RTSP, requests 1306 SHOULD NOT be retransmitted; the RTSP application SHOULD instead rely 1307 on the underlying transport to provide reliability. 1309 If both the underlying reliable transport such as TCP and the RTSP 1310 application retransmit requests, it is possible that each packet 1311 loss results in two retransmissions. The receiver cannot typically 1312 take advantage of the application-layer retransmission since the 1313 transport stack will not deliver the application-layer 1314 retransmission before the first attempt has reached the receiver. 1315 If the packet loss is caused by congestion, multiple 1316 retransmissions at different layers will exacerbate the congestion. 1318 If RTSP is used over a small-RTT LAN, standard procedures for 1319 optimizing inital TCP round trip estimates, such as those used in 1320 T/TCP (RFC 1644) [22], can be beneficial. 1322 The Timestamp header (Section 12.38) is used to avoid the 1323 retransmission ambiguity problem [23, p. 301] and obviates the need 1324 for Karn's algorithm. 1326 Each request carries a sequence number in the CSeq header 1327 (Section 12.17), which is incremented by one for each distinct request 1328 transmitted. If a request is repeated because of lack of 1329 acknowledgement, the request MUST carry the original sequence number 1330 (i.e. sequence number is not incremented). 1332 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1333 support UDP. The default port for the RTSP server is 554 for both UDP 1334 and TCP. 1336 A number of RTSP packets destined for the same control end point may 1337 be packed into a single lower-layer PDU or encapsulated into a TCP 1338 stream. RTSP data MAY be interleaved with RTP and RTCP packets. Unlike 1339 HTTP, an RTSP message MUST contain a Content-Length header whenever 1340 that message contains a payload. Otherwise, an RTSP packet is 1341 terminated with an empty line immediately following the last message 1342 header. 1344 10 Method Definitions 1346 The method token indicates the method to be performed on the 1347 resource identified by the Request-URI. The method is case-sensitive. 1348 New methods may be defined in the future. Method names may not start 1349 with a $ character (decimal 24) and must be a token. Methods are 1350 summarized in Table 2. 1352 method direction object requirement 1353 DESCRIBE C->S P,S recommended 1354 ANNOUNCE C->S, S->C P,S optional 1355 GET_PARAMETER C->S, S->C P,S optional 1356 OPTIONS C->S, S->C P,S required 1357 (S->C: optional) 1358 PAUSE C->S P,S recommended 1359 PLAY C->S P,S required 1360 RECORD C->S P,S optional 1361 REDIRECT S->C P,S optional 1362 SETUP C->S S required 1363 SET_PARAMETER C->S, S->C P,S optional 1364 TEARDOWN C->S P,S required 1366 Table 2: Overview of RTSP methods, their direction, and what 1367 objects (P: presentation, S: stream) they operate on 1369 Notes on Table 2: PAUSE is recommended, but not required in that a 1370 fully functional server can be built that does not support this 1371 method, for example, for live feeds. If a server does not support a 1372 particular method, it MUST return "501 Not Implemented" and a client 1373 SHOULD not try this method again for this server. 1375 10.1 OPTIONS 1377 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1378 request may be issued at any time, e.g., if the client is about to try 1379 a nonstandard request. It does not influence server state. 1381 Example: 1383 C->S: OPTIONS * RTSP/1.0 1384 CSeq: 1 1385 Require: implicit-play 1386 Proxy-Require: gzipped-messages 1388 S->C: RTSP/1.0 200 OK 1389 CSeq: 1 1390 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1392 Note that these are necessarily fictional features (one would hope 1393 that we would not purposefully overlook a truly useful feature just so 1394 that we could have a strong example in this section). 1396 10.2 DESCRIBE 1398 The DESCRIBE method retrieves the description of a presentation or 1399 media object identified by the request URL from a server. It may use 1400 the Accept header to specify the description formats that the client 1401 understands. The server responds with a description of the requested 1402 resource. The DESCRIBE reply-response pair constitutes the media 1403 initialization phase of RTSP. 1405 Example: 1407 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 1408 CSeq: 312 1409 Accept: application/sdp, application/rtsl, application/mheg 1411 S->C: RTSP/1.0 200 OK 1412 CSeq: 312 1413 Date: 23 Jan 1997 15:35:06 GMT 1414 Content-Type: application/sdp 1415 Content-Length: 376 1417 v=0 1418 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1419 s=SDP Seminar 1420 i=A Seminar on the session description protocol 1421 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1422 e=mjh@isi.edu (Mark Handley) 1423 c=IN IP4 224.2.17.12/127 1424 t=2873397496 2873404696 1425 a=recvonly 1426 m=audio 3456 RTP/AVP 0 1427 m=video 2232 RTP/AVP 31 1428 m=whiteboard 32416 UDP WB 1429 a=orient:portrait 1431 The DESCRIBE response MUST contain all media initialization 1432 information for the resource(s) that it describes. If a media client 1433 obtains a presentation description from a source other than DESCRIBE 1434 and that description contains a complete set of media initialization 1435 parameters, the client SHOULD use those parameters and not then 1436 request a description for the same media via RTSP. 1438 Additionally, servers SHOULD NOT use the DESCRIBE response as a means 1439 of media indirection. 1441 Clear ground rules need to be established so that clients have an 1442 unambiguous means of knowing when to request media initialization 1443 information via DESCRIBE, and when not to. By forcing a DESCRIBE 1444 response to contain all media initialization for the set of streams 1445 that it describes, and discouraging use of DESCRIBE for media 1446 indirection, we avoid looping problems that might result from other 1447 approaches. 1449 Media initialization is a requirement for any RTSP-based system, 1450 but the RTSP specification does not dictate that this must be done 1451 via the DESCRIBE method. There are three ways that an RTSP client 1452 may receive initialization information: 1454 * via RTSP's DESCRIBE method; 1455 * via some other protocol (HTTP, email attachment, etc.); 1456 * via the command line or standard input (thus working as a browser 1457 helper application launched with an SDP file or other media 1458 initialization format). 1460 In the interest of practical interoperability, it is highly 1461 recommended that minimal servers support the DESCRIBE method, and 1462 highly recommended that minimal clients support the ability to act 1463 as a ``helper application'' that accepts a media initialization 1464 file from standard input, command line, and/or other means that are 1465 appropriate to the operating environment of the client. 1467 10.3 ANNOUNCE 1469 The ANNOUNCE method serves two purposes: 1471 When sent from client to server, ANNOUNCE posts the description of a 1472 presentation or media object identified by the request URL to a 1473 server. When sent from server to client, ANNOUNCE updates the session 1474 description in real-time. 1476 If a new media stream is added to a presentation (e.g., during a live 1477 presentation), the whole presentation description should be sent 1478 again, rather than just the additional components, so that components 1479 can be deleted. 1481 Example: 1483 C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0 1484 CSeq: 312 1485 Date: 23 Jan 1997 15:35:06 GMT 1486 Session: 4711 1487 Content-Type: application/sdp 1488 Content-Length: 332 1490 v=0 1491 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 1492 s=SDP Seminar 1493 i=A Seminar on the session description protocol 1494 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1495 e=mjh@isi.edu (Mark Handley) 1496 c=IN IP4 224.2.17.12/127 1497 t=2873397496 2873404696 1498 a=recvonly 1499 m=audio 3456 RTP/AVP 0 1500 m=video 2232 RTP/AVP 31 1502 S->C: RTSP/1.0 200 OK 1503 CSeq: 312 1505 10.4 SETUP 1507 The SETUP request for a URI specifies the transport mechanism to be 1508 used for the streamed media. A client can issue a SETUP request for a 1509 stream that is already playing to change transport parameters, which a 1510 server MAY allow. If it does not allow this, it MUST respond with 1511 error ``455 Method Not Valid In This State''. For the benefit of any 1512 intervening firewalls, a client must indicate the transport parameters 1513 even if it has no influence over these parameters, for example, where 1514 the server advertises a fixed multicast address. 1516 Since SETUP includes all transport initialization information, 1517 firewalls and other intermediate network devices (which need this 1518 information) are spared the more arduous task of parsing the 1519 DESCRIBE response, which has been reserved for media 1520 initialization. 1522 The Transport header specifies the transport parameters acceptable to 1523 the client for data transmission; the response will contain the 1524 transport parameters selected by the server. 1526 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 1527 CSeq: 302 1528 Transport: RTP/AVP;unicast;client_port=4588-4589 1530 S->C: RTSP/1.0 200 OK 1531 CSeq: 302 1532 Date: 23 Jan 1997 15:35:06 GMT 1533 Session: 4711 1534 Transport: RTP/AVP;unicast; 1535 client_port=4588-4589;server_port=6256-6257 1537 10.5 PLAY 1539 The PLAY method tells the server to start sending data via the 1540 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 1541 until any outstanding SETUP requests have been acknowledged as 1542 successful. 1544 The PLAY request positions the normal play time to the beginning of 1545 the range specified and delivers stream data until the end of the 1546 range is reached. PLAY requests may be pipelined (queued); a server 1547 MUST queue PLAY requests to be executed in order. That is, a PLAY 1548 request arriving while a previous PLAY request is still active is 1549 delayed until the first has been completed. 1551 This allows precise editing. 1553 For example, regardless of how closely spaced the two PLAY requests in 1554 the example below arrive, the server will first play seconds 10 1555 through 15, then, immediately following, seconds 20 to 25, and finally 1556 seconds 30 through the end. 1558 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1559 CSeq: 835 1560 Range: npt=10-15 1562 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1563 CSeq: 836 1564 Range: npt=20-25 1566 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1567 CSeq: 837 1568 Range: npt=30- 1570 See the description of the PAUSE request for further examples. 1572 A PLAY request without a Range header is legal. It starts playing a 1573 stream from the beginning unless the stream has been paused. If a 1574 stream has been paused via PAUSE, stream delivery resumes at the pause 1575 point. If a stream is playing, such a PLAY request causes no further 1576 action and can be used by the client to test server liveness. 1578 The Range header may also contain a time parameter. This parameter 1579 specifies a time in UTC at which the playback should start. If the 1580 message is received after the specified time, playback is started 1581 immediately. The time parameter may be used to aid in synchronization 1582 of streams obtained from different sources. 1584 For a on-demand stream, the server replies with the actual range that 1585 will be played back. This may differ from the requested range if 1586 alignment of the requested range to valid frame boundaries is required 1587 for the media source. If no range is specified in the request, the 1588 current position is returned in the reply. The unit of the range in 1589 the reply is the same as that in the request. 1591 After playing the desired range, the presentation is automatically 1592 paused, as if a PAUSE request had been issued. 1594 The following example plays the whole presentation starting at SMPTE 1595 time code 0:10:20 until the end of the clip. The playback is to start 1596 at 15:36 on 23 Jan 1997. 1598 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 1599 CSeq: 833 1600 Range: smpte=0:10:20-;time=19970123T153600Z 1602 S->C: RTSP/1.0 200 OK 1603 CSeq: 833 1604 Date: 23 Jan 1997 15:35:06 GMT 1605 Range: smpte=0:10:22-;time=19970123T153600Z 1607 For playing back a recording of a live presentation, it may be 1608 desirable to use clock units: 1610 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 1611 CSeq: 835 1612 Range: clock=19961108T142300Z-19961108T143520Z 1614 S->C: RTSP/1.0 200 OK 1615 CSeq: 835 1616 Date: 23 Jan 1997 15:35:06 GMT 1618 A media server only supporting playback MUST support the npt format 1619 and MAY support the clock and smpte formats. 1621 10.6 PAUSE 1623 The PAUSE request causes the stream delivery to be interrupted 1624 (halted) temporarily. If the request URL names a stream, only playback 1625 and recording of that stream is halted. For example, for audio, this 1626 is equivalent to muting. If the request URL names a presentation or 1627 group of streams, delivery of all currently active streams within the 1628 presentation or group is halted. After resuming playback or recording, 1629 synchronization of the tracks MUST be maintained. Any server resources 1630 are kept, though servers MAY close the session and free resources 1631 after being paused for the duration specified with the timeout 1632 parameter of the Session header in the SETUP message. 1634 Example: 1636 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1637 CSeq: 834 1638 Session: 1234 1640 S->C: RTSP/1.0 200 OK 1641 CSeq: 834 1642 Date: 23 Jan 1997 15:35:06 GMT 1644 The PAUSE request may contain a Range header specifying when the 1645 stream or presentation is to be halted. The header must contain 1646 exactly one value rather than a time range. The normal play time for 1647 the stream is set to that value. The pause request becomes effective 1648 the first time the server is encountering the time point specified in 1649 any of the currently pending PLAY requests. If the Range header 1650 specifies a time outside any currently pending PLAY requests, the 1651 error ``457 Invalid Range'' is returned. If this header is missing, 1652 stream delivery is interrupted immediately on receipt of the message. 1654 For example, if the server has play requests for ranges 10 to 15 and 1655 20 to 29 pending and then receives a pause request for NPT 21, it 1656 would start playing the second range and stop at NPT 21. If the pause 1657 request is for NPT 12 and the server is playing at NPT 13 serving the 1658 first play request, the server stops immediately. If the pause request 1659 is for NPT 16, the server stops after completing the first play 1660 request and discards the second play request. 1662 As another example, if a server has received requests to play ranges 1663 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 1664 request for NPT=14 would take effect while the server plays the first 1665 range, with the second PLAY request effectively being ignored, 1666 assuming the PAUSE request arrives before the server has started 1667 playing the second, overlapping range. Regardless of when the PAUSE 1668 request arrives, it sets the NPT to 14. 1670 If the server has already sent data beyond the time specified in the 1671 Range header, a PLAY would still resume at that point in time, as it 1672 is assumed that the client has discarded data after that point. This 1673 ensures continuous pause/play cycling without gaps. 1675 10.7 TEARDOWN 1677 The TEARDOWN request stops the stream delivery for the given URI, 1678 freeing the resources associated with it. If the URI is the 1679 presentation URI for this presentation, any RTSP session identifier 1680 associated with the session is no longer valid. Unless all transport 1681 parameters are defined by the session description, a SETUP request has 1682 to be issued before the session can be played again. 1684 Example: 1685 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 1686 CSeq: 892 1687 Session: 1234 1688 S->C: RTSP/1.0 200 OK 1689 CSeq: 892 1691 10.8 GET_PARAMETER 1693 The GET_PARAMETER request retrieves the value of a parameter of a 1694 presentation or stream specified in the URI. The content of the reply 1695 and response is left to the implementation. GET_PARAMETER with no 1696 entity body may be used to test client or server liveness (``ping''). 1698 Example: 1700 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1701 CSeq: 431 1702 Content-Type: text/parameters 1703 Session: 1234 1704 Content-Length: 15 1706 packets_received 1707 jitter 1709 C->S: RTSP/1.0 200 OK 1710 CSeq: 431 1711 Content-Length: 46 1712 Content-Type: text/parameters 1714 packets_received: 10 1715 jitter: 0.3838 1717 The ``text/parameters'' section is only an example type for 1718 parameter. This method is intentionally loosely defined with the 1719 intention that the reply content and response content will be 1720 defined after further experimentation. 1722 10.9 SET_PARAMETER 1724 This method requests to set the value of a parameter for a 1725 presentation or stream specified by the URI. 1727 A request SHOULD only contain a single parameter to allow the client 1728 to determine why a particular request failed. If the request contains 1729 several parameters, the server MUST only act on the request if all of 1730 the parameters can be set successfully. A server MUST allow a 1731 parameter to be set repeatedly to the same value, but it MAY disallow 1732 changing parameter values. 1734 Note: transport parameters for the media stream MUST only be set with 1735 the SETUP command. 1737 Restricting setting transport parameters to SETUP is for the 1738 benefit of firewalls. 1740 The parameters are split in a fine-grained fashion so that there 1741 can be more meaningful error indications. However, it may make 1742 sense to allow the setting of several parameters if an atomic 1743 setting is desirable. Imagine device control where the client does 1744 not want the camera to pan unless it can also tilt to the right 1745 angle at the same time. 1747 Example: 1749 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1750 CSeq: 421 1751 Content-length: 20 1752 Content-type: text/parameters 1754 barparam: barstuff 1756 S->C: RTSP/1.0 451 Invalid Parameter 1757 CSeq: 421 1758 Content-length: 10 1759 Content-type: text/parameters 1761 barparam 1763 The ``text/parameters'' section is only an example type for 1764 parameter. This method is intentionally loosely defined with the 1765 intention that the reply content and response content will be 1766 defined after further experimentation. 1768 10.10 REDIRECT 1770 A redirect request informs the client that it must connect to 1771 another server location. It contains the mandatory header Location, 1772 which indicates that the client should issue requests for that URL. It 1773 may contain the parameter Range, which indicates when the redirection 1774 takes effect. If the client wants to continue to send or receive media 1775 for this URI, the client MUST issue a TEARDOWN request for the current 1776 session and a SETUP for the new session at the designated host. 1778 This example request redirects traffic for this URI to the new server 1779 at the given play time: 1781 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 1782 CSeq: 732 1783 Location: rtsp://bigserver.com:8001 1784 Range: clock=19960213T143205Z- 1786 10.11 RECORD 1788 This method initiates recording a range of media data according to 1789 the presentation description. The timestamp reflects start and end 1790 time (UTC). If no time range is given, use the start or end time 1791 provided in the presentation description. If the session has already 1792 started, commence recording immediately. 1794 The server decides whether to store the recorded data under the 1795 request-URI or another URI. If the server does not use the 1796 request-URI, the response SHOULD be 201 (Created) and contain an 1797 entity which describes the status of the request and refers to the new 1798 resource, and a Location header. 1800 A media server supporting recording of live presentations MUST support 1801 the clock range format; the smpte format does not make sense. 1803 In this example, the media server was previously invited to the 1804 conference indicated. 1806 C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 1807 CSeq: 954 1808 Session: 1234 1809 Conference: 128.16.64.19/32492374 1811 10.12 Embedded (Interleaved) Binary Data 1813 Certain firewall designs and other circumstances may force a server 1814 to interleave RTSP methods and stream data. This interleaving should 1815 generally be avoided unless necessary since it complicates client and 1816 server operation and imposes additional overhead. Interleaved binary 1817 data SHOULD only be used if RTSP is carried over TCP. 1819 Stream data such as RTP packets is encapsulated by an ASCII dollar 1820 sign (24 decimal), followed by a one-byte channel identifier, followed 1821 by the length of the encapsulated binary data as a binary, two-byte 1822 integer in network byte order. The stream data follows immediately 1823 afterwards, without a CRLF, but including the upper-layer protocol 1824 headers. Each $ block contains exactly one upper-layer protocol data 1825 unit, e.g., one RTP packet. 1827 The channel identifier is defined in the Transport header with the 1828 interleaved parameter(Section 12.39). 1830 When the transport choice is RTP, RTCP messages are also interleaved 1831 by the server over the TCP connection. As a default, RTCP packets are 1832 sent on the first available channel higher than the RTP channel. The 1833 client MAY explicitly request RTCP packets on another channel. This is 1834 done by specifying two channels in the interleaved parameter of the 1835 Transport header(Section 12.39). 1837 RTCP is needed for synchronization when two or more streams are 1838 interleaved in such a fashion. Also, this provides a convenient way 1839 to tunnel RTP/RTCP packets through the TCP control connection when 1840 required by the network configuration and transfer them onto UDP 1841 when possible. 1843 C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 1844 CSeq: 2 1845 Transport: RTP/AVP/TCP;interleaved=0-1 1847 S->C: RTSP/1.0 200 OK 1848 CSeq: 2 1849 Date: 05 Jun 1997 18:57:18 GMT 1850 Transport: RTP/AVP/TCP;interleaved=0-1 1851 Session: 12345 1853 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 1854 CSeq: 3 1855 Session: 12345 1857 S->C: RTSP/1.0 200 OK 1858 CSeq: 3 1859 Session: 12345 1860 Date: 05 Jun 1997 18:59:15 GMT 1861 RTP-Info: url=rtsp://foo.com/bar.file; 1862 seq=232433;rtptime=972948234 1864 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} 1865 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} 1866 S->C: $\001{2 byte length}{"length" bytes RTCP packet} 1868 11 Status Code Definitions 1870 Where applicable, HTTP status [H10] codes are reused. Status codes 1871 that have the same meaning are not repeated here. See Table 1 for a 1872 listing of which status codes may be returned by which requests. 1874 11.1 Success 2xx 1876 11.1.1 250 Low on Storage Space 1878 The server returns this warning after receiving a RECORD request that 1879 it may not be able to fulfill completely due to insufficient storage 1880 space. If possible, the server should use the Range header to indicate 1881 what time period it may still be able to record. Since other processes 1882 on the server may be consuming storage space simultaneously, a client 1883 should take this only as an estimate. 1885 11.2 Redirection 3xx 1887 See [H10.3]. 1889 Within RTSP, redirection may be used for load balancing or redirecting 1890 stream requests to a server topologically closer to the client. 1891 Mechanisms to determine topological proximity are beyond the scope of 1892 this specification. 1894 11.3 Client Error 4xx 1896 11.3.1 405 Method Not Allowed 1898 The method specified in the request is not allowed for the resource 1899 identified by the request URI. The response MUST include an Allow 1900 header containing a list of valid methods for the requested resource. 1901 This status code is also to be used if a request attempts to use a 1902 method not indicated during SETUP, e.g., if a RECORD request is issued 1903 even though the mode parameter in the Transport header only specified 1904 PLAY. 1906 11.3.2 451 Parameter Not Understood 1908 The recipient of the request does not support one or more parameters 1909 contained in the request. 1911 11.3.3 452 Conference Not Found 1913 The conference indicated by a Conference header field is unknown to 1914 the media server. 1916 11.3.4 453 Not Enough Bandwidth 1918 The request was refused because there was insufficient bandwidth. This 1919 may, for example, be the result of a resource reservation failure. 1921 11.3.5 454 Session Not Found 1923 The RTSP session identifier in the Session header is missing, invalid, 1924 or has timed out. 1926 11.3.6 455 Method Not Valid in This State 1928 The client or server cannot process this request in its current state. 1929 The response SHOULD contain an Allow header to make error recovery 1930 easier. 1932 11.3.7 456 Header Field Not Valid for Resource 1934 The server could not act on a required request header. For example, if 1935 PLAY contains the Range header field but the stream does not allow 1936 seeking. 1938 11.3.8 457 Invalid Range 1940 The Range value given is out of bounds, e.g., beyond the end of the 1941 presentation. 1943 11.3.9 458 Parameter Is Read-Only 1945 The parameter to be set by SET_PARAMETER can be read but not modified. 1947 11.3.10 459 Aggregate Operation Not Allowed 1949 The requested method may not be applied on the URL in question since 1950 it is an aggregate (presentation) URL. The method may be applied on a 1951 stream URL. 1953 11.3.11 460 Only Aggregate Operation Allowed 1955 The requested method may not be applied on the URL in question since 1956 it is not an aggregate (presentation) URL. The method may be applied 1957 on the presentation URL. 1959 11.3.12 461 Unsupported Transport 1961 The Transport field did not contain a supported transport 1962 specification. 1964 11.3.13 462 Destination Unreachable 1966 The data transmission channel could not be established because the 1967 client address could not be reached. This error will most likely be 1968 the result of a client attempt to place an invalid Destination 1969 parameter in the Transport field. 1971 11.3.14 551 Option not supported 1973 An option given in the Require or the Proxy-Require fields was not 1974 supported. The Unsupported header should be returned stating the 1975 option for which there is no support. 1977 12 Header Field Definitions 1979 HTTP/1.1 [2] or other, non-standard header fields not listed here 1980 currently have no well-defined meaning and SHOULD be ignored by the 1981 recipient. 1983 Table 3 summarizes the header fields used by RTSP. Type ``g'' 1984 designates general request headers to be found in both requests and 1985 responses, type ``R'' designates request headers, type ``r'' 1986 designates response headers, and type ``e'' designates entity header 1987 fields. Fields marked with ``req.'' in the column labeled ``support'' 1988 MUST be implemented by the recipient for a particular method, while 1989 fields marked ``opt.'' are optional. Note that not all fields marked 1990 ``req.'' will be sent in every request of this type. The ``req.'' 1991 means only that client (for response headers) and server (for request 1992 headers) MUST implement the fields. The last column lists the method 1993 for which this header field is meaningful; the designation ``entity'' 1994 refers to all methods that return a message body. Within this 1995 specification, DESCRIBE and GET_PARAMETER fall into this class. 1997 Header type support methods 1998 Accept R opt. entity 1999 Accept-Encoding R opt. entity 2000 Accept-Language R opt. all 2001 Allow r opt. all 2002 Authorization R opt. all 2003 Bandwidth R opt. all 2004 Blocksize R opt. all but OPTIONS, TEARDOWN 2005 Cache-Control g opt. SETUP 2006 Conference R opt. SETUP 2007 Connection g req. all 2008 Content-Base e opt. entity 2009 Content-Encoding e req. SET_PARAMETER 2010 Content-Encoding e req. DESCRIBE, ANNOUNCE 2011 Content-Language e req. DESCRIBE, ANNOUNCE 2012 Content-Length e req. SET_PARAMETER, ANNOUNCE 2013 Content-Length e req. entity 2014 Content-Location e opt. entity 2015 Content-Type e req. SET_PARAMETER, ANNOUNCE 2016 Content-Type r req. entity 2017 CSeq g req. all 2018 Date g opt. all 2019 Expires e opt. DESCRIBE, ANNOUNCE 2020 From R opt. all 2021 If-Modified-Since R opt. DESCRIBE, SETUP 2022 Last-Modified e opt. entity 2023 Proxy-Authenticate 2024 Proxy-Require R req. all 2025 Public r opt. all 2026 Range R opt. PLAY, PAUSE, RECORD 2027 Range r opt. PLAY, PAUSE, RECORD 2028 Referer R opt. all 2029 Require R req. all 2030 Retry-After r opt. all 2031 RTP-Info r req. PLAY 2032 Scale Rr opt. PLAY, RECORD 2033 Session Rr req. all but SETUP, OPTIONS 2034 Server r opt. all 2035 Speed Rr opt. PLAY 2036 Transport Rr req. SETUP 2037 Unsupported r req. all 2038 User-Agent R opt. all 2039 Via g opt. all 2040 WWW-Authenticate r opt. all 2041 Overview of RTSP header fields 2043 12.1 Accept 2045 The Accept request-header field can be used to specify certain 2046 presentation description content types which are acceptable for the 2047 response. 2049 The ``level'' parameter for presentation descriptions is properly 2050 defined as part of the MIME type registration, not here. 2052 See [H14.1] for syntax. 2054 Example of use: 2055 Accept: application/rtsl, application/sdp;level=2 2057 12.2 Accept-Encoding 2059 See [H14.3] 2061 12.3 Accept-Language 2063 See [H14.4]. Note that the language specified applies to the 2064 presentation description and any reason phrases, not the media 2065 content. 2067 12.4 Allow 2069 The Allow response header field lists the methods supported by the 2070 resource identified by the request-URI. The purpose of this field is 2071 to strictly inform the recipient of valid methods associated with the 2072 resource. An Allow header field must be present in a 405 (Method not 2073 allowed) response. 2075 Example of use: 2076 Allow: SETUP, PLAY, RECORD, SET_PARAMETER 2078 12.5 Authorization 2080 See [H14.8] 2082 12.6 Bandwidth 2084 The Bandwidth request header field describes the estimated bandwidth 2085 available to the client, expressed as a positive integer and measured 2086 in bits per second. The bandwidth available to the client may change 2087 during an RTSP session, e.g., due to modem retraining. 2089 Bandwidth = "Bandwidth" ":" 1*DIGIT 2091 Example: 2092 Bandwidth: 4000 2094 12.7 Blocksize 2096 This request header field is sent from the client to the media 2097 server asking the server for a particular media packet size. This 2098 packet size does not include lower-layer headers such as IP, UDP, or 2099 RTP. The server is free to use a blocksize which is lower than the one 2100 requested. The server MAY truncate this packet size to the closest 2101 multiple of the minimum, media-specific block size, or override it 2102 with the media-specific size if necessary. The block size MUST be a 2103 positive decimal number, measured in octets. The server only returns 2104 an error (416) if the value is syntactically invalid. 2106 12.8 Cache-Control 2108 The Cache-Control general header field is used to specify directives 2109 that MUST be obeyed by all caching mechanisms along the 2110 request/response chain. 2112 Cache directives must be passed through by a proxy or gateway 2113 application, regardless of their significance to that application, 2114 since the directives may be applicable to all recipients along the 2115 request/response chain. It is not possible to specify a cache- 2116 directive for a specific cache. 2118 Cache-Control should only be specified in a SETUP request and its 2119 response. Note: Cache-Control does not govern the caching of responses 2120 as for HTTP, but rather of the stream identified by the SETUP request. 2121 Responses to RTSP requests are not cacheable, except for responses to 2122 DESCRIBE. 2124 Cache-Control = "Cache-Control" ":" 1#cache-directive 2125 cache-directive = cache-request-directive 2126 | cache-response-directive 2127 cache-request-directive = "no-cache" 2128 | "max-stale" 2129 | "min-fresh" 2130 | "only-if-cached" 2131 | cache-extension 2132 cache-response-directive = "public" 2133 | "private" 2134 | "no-cache" 2135 | "no-transform" 2136 | "must-revalidate" 2137 | "proxy-revalidate" 2138 | "max-age" "=" delta-seconds 2139 | cache-extension 2140 cache-extension = token [ "=" ( token | quoted-string ) ] 2142 no-cache: 2143 Indicates that the media stream MUST NOT be cached anywhere. 2144 This allows an origin server to prevent caching even by caches 2145 that have been configured to return stale responses to client 2146 requests. 2148 public: 2149 Indicates that the media stream is cacheable by any cache. 2151 private: 2152 Indicates that the media stream is intended for a single user 2153 and MUST NOT be cached by a shared cache. A private 2154 (non-shared) cache may cache the media stream. 2156 no-transform: 2157 An intermediate cache (proxy) may find it useful to convert the 2158 media type of a certain stream. A proxy might, for example, 2159 convert between video formats to save cache space or to reduce 2160 the amount of traffic on a slow link. Serious operational 2161 problems may occur, however, when these transformations have 2162 been applied to streams intended for certain kinds of 2163 applications. For example, applications for medical imaging, 2164 scientific data analysis and those using end-to-end 2165 authentication all depend on receiving a stream that is 2166 bit-for-bit identical to the original entity-body. Therefore, 2167 if a response includes the no-transform directive, an 2168 intermediate cache or proxy MUST NOT change the encoding of the 2169 stream. Unlike HTTP, RTSP does not provide for partial 2170 transformation at this point, e.g., allowing translation into a 2171 different language. 2173 only-if-cached: 2174 In some cases, such as times of extremely poor network 2175 connectivity, a client may want a cache to return only those 2176 media streams that it currently has stored, and not to receive 2177 these from the origin server. To do this, the client may 2178 include the only-if-cached directive in a request. If it 2179 receives this directive, a cache SHOULD either respond using a 2180 cached media stream that is consistent with the other 2181 constraints of the request, or respond with a 504 (Gateway 2182 Timeout) status. However, if a group of caches is being 2183 operated as a unified system with good internal connectivity, 2184 such a request MAY be forwarded within that group of caches. 2186 max-stale: 2187 Indicates that the client is willing to accept a media stream 2188 that has exceeded its expiration time. If max-stale is assigned 2189 a value, then the client is willing to accept a response that 2190 has exceeded its expiration time by no more than the specified 2191 number of seconds. If no value is assigned to max-stale, then 2192 the client is willing to accept a stale response of any age. 2194 min-fresh: 2195 Indicates that the client is willing to accept a media stream 2196 whose freshness lifetime is no less than its current age plus 2197 the specified time in seconds. That is, the client wants a 2198 response that will still be fresh for at least the specified 2199 number of seconds. 2201 must-revalidate: 2202 When the must-revalidate directive is present in a SETUP 2203 response received by a cache, that cache MUST NOT use the entry 2204 after it becomes stale to respond to a subsequent request 2205 without first revalidating it with the origin server. That is, 2206 the cache must do an end-to-end revalidation every time, if, 2207 based solely on the origin server's Expires, the cached 2208 response is stale.) 2210 12.9 Conference 2212 This request header field establishes a logical connection between a 2213 pre-established conference and an RTSP stream. The conference-id must 2214 not be changed for the same RTSP session. 2216 Conference = "Conference" ":" conference-id 2218 Example: 2219 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 2221 A response code of 452 (452 Conference Not Found) is returned if the 2222 conference-id is not valid. 2224 12.10 Connection 2226 See [H14.10] 2228 12.11 Content-Base 2230 See [H14.11] 2232 12.12 Content-Encoding 2234 See [H14.12] 2236 12.13 Content-Language 2238 See [H14.13] 2240 12.14 Content-Length 2242 This field contains the length of the content of the method (i.e. 2243 after the double CRLF following the last header). Unlike HTTP, it MUST 2244 be included in all messages that carry content beyond the header 2245 portion of the message. If it is missing, a default value of zero is 2246 assumed. It is interpreted according to [H14.14]. 2248 12.15 Content-Location 2250 See [H14.15] 2252 12.16 Content-Type 2254 See [H14.18]. Note that the content types suitable for RTSP are 2255 likely to be restricted in practice to presentation descriptions and 2256 parameter-value types. 2258 12.17 CSeq 2260 The CSeq field specifies the sequence number for an RTSP 2261 request-response pair. This field MUST be present in all requests and 2262 responses. For every RTSP request containing the given sequence 2263 number, there will be a corresponding response having the same number. 2264 Any retransmitted request must contain the same sequence number as the 2265 original (i.e. the sequence number is not incremented for 2266 retransmissions of the same request). 2268 12.18 Date 2270 See [H14.19]. 2272 12.19 Expires 2274 The Expires entity-header field gives a date and time after which 2275 the description or media-stream should be considered stale. The 2276 interpretation depends on the method: 2278 DESCRIBE response: 2279 The Expires header indicates a date and time after which the 2280 description should be considered stale. 2282 A stale cache entry may not normally be returned by a cache (either a 2283 proxy cache or an user agent cache) unless it is first validated with 2284 the origin server (or with an intermediate cache that has a fresh copy 2285 of the entity). See section 13 for further discussion of the 2286 expiration model. 2288 The presence of an Expires field does not imply that the original 2289 resource will change or cease to exist at, before, or after that time. 2291 The format is an absolute date and time as defined by HTTP-date in 2292 [H3.3]; it MUST be in RFC1123-date format: 2294 Expires = "Expires" ":" HTTP-date 2296 An example of its use is 2298 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2300 RTSP/1.0 clients and caches MUST treat other invalid date formats, 2301 especially including the value "0", as having occured in the past 2302 (i.e., ``already expired''). 2304 To mark a response as ``already expired,'' an origin server should use 2305 an Expires date that is equal to the Date header value. To mark a 2306 response as ``never expires,'' an origin server should use an Expires 2307 date approximately one year from the time the response is sent. 2308 RTSP/1.0 servers should not send Expires dates more than one year in 2309 the future. 2311 The presence of an Expires header field with a date value of some time 2312 in the future on a media stream that otherwise would by default be 2313 non-cacheable indicates that the media stream is cacheable, unless 2314 indicated otherwise by a Cache-Control header field (Section 12.8). 2316 12.20 From 2318 See [H14.22]. 2320 12.21 Host 2322 This HTTP request header field is not needed for RTSP. It should be 2323 silently ignored if sent. 2325 12.22 If-Match 2327 See [H14.25]. 2329 This field is especially useful for ensuring the integrity of the 2330 presentation description, in both the case where it is fetched via 2331 means external to RTSP (such as HTTP), or in the case where the server 2332 implementation is guaranteeing the integrity of the description 2333 between the time of the DESCRIBE message and the SETUP message. 2335 The identifier is an opaque identifier, and thus is not specific to 2336 any particular session description language. 2338 12.23 If-Modified-Since 2340 The If-Modified-Since request-header field is used with the DESCRIBE 2341 and SETUP methods to make them conditional. If the requested variant 2342 has not been modified since the time specified in this field, a 2343 description will not be returned from the server (DESCRIBE) or a 2344 stream will not be set up (SETUP). Instead, a 304 (not modified) 2345 response will be returned without any message-body. 2347 If-Modified-Since = "If-Modified-Since" ":" HTTP-date 2349 An example of the field is: 2351 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 2353 12.24 Last-Modified 2355 The Last-Modified entity-header field indicates the date and time at 2356 which the origin server believes the presentation description or media 2357 stream was last modified. See [H14.29]. For the methods DESCRIBE or 2358 ANNOUNCE, the header field indicates the last modification date and 2359 time of the description, for SETUP that of the media stream. 2361 12.25 Location 2363 See [H14.30]. 2365 12.26 Proxy-Authenticate 2367 See [H14.33]. 2369 12.27 Proxy-Require 2371 The Proxy-Require header is used to indicate proxy-sensitive 2372 features that MUST be supported by the proxy. Any Proxy-Require header 2373 features that are not supported by the proxy MUST be negatively 2374 acknowledged by the proxy to the client if not supported. Servers 2375 should treat this field identically to the Require field. 2377 See Section 12.32 for more details on the mechanics of this message 2378 and a usage example. 2380 12.28 Public 2382 See [H14.35]. 2384 12.29 Range 2386 This request and response header field specifies a range of time. 2387 The range can be specified in a number of units. This specification 2388 defines the smpte (Section 3.5), npt (Section 3.6), and clock 2389 (Section 3.7) range units. Within RTSP, byte ranges [H14.36.1] are not 2390 meaningful and MUST NOT be used. The header may also contain a time 2391 parameter in UTC, specifying the time at which the operation is to be 2392 made effective. Servers supporting the Range header MUST understand 2393 the NPT range format and SHOULD understand the SMPTE range format. The 2394 Range response header indicates what range of time is actually being 2395 played or recorded. If the Range header is given in a time format that 2396 is not understood, the recipient should return ``501 Not 2397 Implemented''. 2399 Range = "Range" ":" 1#ranges-specifier 2400 [ ";" "time" "=" utc-time ] 2401 ranges-specifier = npt-range | utc-range | smpte-range 2403 Example: 2404 Range: clock=19960213T143205Z-;time=19970123T143720Z 2406 The notation is similar to that used for the HTTP/1.1 [2] 2407 byte-range header. It allows clients to select an excerpt from the 2408 media object, and to play from a given point to the end as well as 2409 from the current location to a given point. The start of playback 2410 can be scheduled for any time in the future, although a server may 2411 refuse to keep server resources for extended idle periods. 2413 12.30 Referer 2415 See [H14.37]. The URL refers to that of the presentation 2416 description, typically retrieved via HTTP. 2418 12.31 Retry-After 2420 See [H14.38]. 2422 12.32 Require 2424 The Require header is used by clients to query the server about 2425 options that it may or may not support. The server MUST respond to 2426 this header by using the Unsupported header to negatively acknowledge 2427 those options which are NOT supported. 2429 This is to make sure that the client-server interaction will 2430 proceed without delay when all options are understood by both 2431 sides, and only slow down if options are not understood (as in the 2432 case above). For a well-matched client-server pair, the interaction 2433 proceeds quickly, saving a round-trip often required by negotiation 2434 mechanisms. In addition, it also removes state ambiguity when the 2435 client requires features that the server does not understand. 2437 Require = "Require" ":" 1#option-tag 2439 Example: 2440 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 2441 CSeq: 302 2442 Require: funky-feature 2443 Funky-Parameter: funkystuff 2445 S->C: RTSP/1.0 551 Option not supported 2446 CSeq: 302 2447 Unsupported: funky-feature 2449 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 2450 CSeq: 303 2452 S->C: RTSP/1.0 200 OK 2453 CSeq: 303 2455 In this example, ``funky-feature'' is the feature tag which indicates 2456 to the client that the fictional Funky-Parameter field is required. 2457 The relationship between ``funky-feature'' and Funky-Parameter is not 2458 communicated via the RTSP exchange, since that relationship is an 2459 immutable property of ``funky-feature'' and thus should not be 2460 transmitted with every exchange. 2462 Proxies and other intermediary devices SHOULD ignore features that are 2463 not understood in this field. If a particular extension requires that 2464 intermediate devices support it, the extension should be tagged in the 2465 Proxy-Require field instead (see Section 3.4). 2467 12.33 RTP-Info 2469 This field is used to set RTP-specific parameters in the PLAY 2470 response. 2472 url: 2473 Indicates the stream URL which for which the following RTP 2474 parameters correspond. 2476 seq: 2477 Indicates the sequence number of the first packet of the 2478 stream. This allows clients to gracefully deal with packets 2479 when seeking. The client uses this value to differentiate 2480 packets that originated before the seek from packets that 2481 originated after the seek. 2483 rtptime: 2484 Indicates the RTP timestamp of the first packet of the stream. 2485 The client uses this value to calculate the mapping of RTP time 2486 to NPT. 2488 A mapping from RTP timestamps to NTP timestamps (wall clock) is 2489 available via RTCP. However, this information is not sufficient to 2490 generate a mapping from RTP timestamps to NPT. Furthermore, in 2491 order to ensure that this information is available at the necessary 2492 time (immediately at startup or after a seek), and that it is 2493 delivered reliably, this mapping is placed in the RTSP control 2494 channel. 2496 In order to compensate for drift for long, uninterrupted 2497 presentations, RTSP clients should additionally map NPT to NTP, 2498 using initial RTCP sender reports to do the mapping, and later 2499 reports to check drift against the mapping. 2501 Syntax: 2503 RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter 2504 stream-url = "url" "=" url 2505 parameter = ";" "seq" "=" 1*DIGIT 2506 | ";" "rtptime" "=" 1*DIGIT 2508 Example: 2510 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, 2511 url=rtsp://foo.com/bar.avi/streamid=1;seq=30211 2513 12.34 Scale 2515 A scale value of 1 indicates normal play or record at the normal 2516 forward viewing rate. If not 1, the value corresponds to the rate with 2517 respect to normal viewing rate. For example, a ratio of 2 indicates 2518 twice the normal viewing rate (``fast forward'') and a ratio of 0.5 2519 indicates half the normal viewing rate. In other words, a ratio of 2 2520 has normal play time increase at twice the wallclock rate. For every 2521 second of elapsed (wallclock) time, 2 seconds of content will be 2522 delivered. A negative value indicates reverse direction. 2524 Unless requested otherwise by the Speed parameter, the data rate 2525 SHOULD not be changed. Implementation of scale changes depends on the 2526 server and media type. For video, a server may, for example, deliver 2527 only key frames or selected key frames. For audio, it may time-scale 2528 the audio while preserving pitch or, less desirably, deliver fragments 2529 of audio. 2531 The server should try to approximate the viewing rate, but may 2532 restrict the range of scale values that it supports. The response MUST 2533 contain the actual scale value chosen by the server. 2535 If the request contains a Range parameter, the new scale value will 2536 take effect at that time. 2538 Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 2540 Example of playing in reverse at 3.5 times normal rate: 2542 Scale: -3.5 2544 12.35 Speed 2546 This request header fields parameter requests the server to deliver 2547 data to the client at a particular speed, contingent on the server's 2548 ability and desire to serve the media stream at the given speed. 2549 Implementation by the server is OPTIONAL. The default is the bit rate 2550 of the stream. 2552 The parameter value is expressed as a decimal ratio, e.g., a value of 2553 2.0 indicates that data is to be delivered twice as fast as normal. A 2554 speed of zero is invalid. If the request contains a Range parameter, 2555 the new speed value will take effect at that time. 2557 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] 2559 Example: 2560 Speed: 2.5 2562 Use of this field changes the bandwidth used for data delivery. It is 2563 meant for use in specific circumstances where preview of the 2564 presentation at a higher or lower rate is necessary. Implementors 2565 should keep in mind that bandwidth for the session may be negotiated 2566 beforehand (by means other than RTSP), and therefore re-negotiation 2567 may be necessary. When data is delivered over UDP, it is highly 2568 recommended that means such as RTCP be used to track packet loss 2569 rates. 2571 12.36 Server 2573 See [H14.39] 2575 12.37 Session 2577 This request and response header field identifies an RTSP session 2578 started by the media server in a SETUP response and concluded by 2579 TEARDOWN on the presentation URL. The session identifier is chosen by 2580 the media server (see Section 3.4). Once a client receives a Session 2581 identifier, it MUST return it for any request related to that session. 2582 A server does not have to set up a session identifier if it has other 2583 means of identifying a session, such as dynamically generated URLs. 2585 Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ] 2587 The timeout parameter is only allowed in a response header. The server 2588 uses it to indicate to the client how long the server is prepared to 2589 wait between RTSP commands before closing the session due to lack of 2590 activity (see Section A). The timeout is measured in seconds, with a 2591 default of 60 seconds (1 minute). 2593 Note that a session identifier identifies a RTSP session across 2594 transport sessions or connections. Control messages for more than one 2595 RTSP URL may be sent within a single RTSP session. Hence, it is 2596 possible that clients use the same session for controlling many 2597 streams constituting a presentation, as long as all the streams come 2598 from the same server. (See example in Section 14). However, multiple 2599 ``user'' sessions for the same URL from the same client MUST use 2600 different session identifiers. 2602 The session identifier is needed to distinguish several delivery 2603 requests for the same URL coming from the same client. 2605 The response 454 (Session Not Found) is returned if the session 2606 identifier is invalid. 2608 12.38 Timestamp 2610 The timestamp general header describes when the client sent the 2611 request to the server. The value of the timestamp is of significance 2612 only to the client and may use any timescale. The server MUST echo the 2613 exact same value and MAY, if it has accurate information about this, 2614 add a floating point number indicating the number of seconds that has 2615 elapsed since it has received the request. The timestamp is used by 2616 the client to compute the round-trip time to the server so that it can 2617 adjust the timeout value for retransmissions. 2619 Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] 2620 delay = *(DIGIT) [ "." *(DIGIT) ] 2622 12.39 Transport 2624 This request header indicates which transport protocol is to be used 2625 and configures its parameters such as destination address, 2626 compression, multicast time-to-live and destination port for a single 2627 stream. It sets those values not already determined by a presentation 2628 description. 2630 Transports are comma separated, listed in order of preference. 2631 Parameters may be added to each transport, separated by a semicolon. 2633 The Transport header MAY also be used to change certain transport 2634 parameters. A server MAY refuse to change parameters of an existing 2635 stream. 2637 The server MAY return a Transport response header in the response to 2638 indicate the values actually chosen. 2640 A Transport request header field may contain a list of transport 2641 options acceptable to the client. In that case, the server MUST return 2642 a single option which was actually chosen. 2644 The syntax for the transport specifier is 2646 transport/profile/lower-transport. 2648 The default value for the ``lower-transport'' parameters is specific 2649 to the profile. For RTP/AVP, the default is UDP. 2651 Below are the configuration parameters associated with transport: 2653 General parameters: 2655 unicast | multicast 2656 : mutually exclusive indication of whether unicast or multicast 2657 delivery will be attempted. Default value is multicast. Clients 2658 that are capable of handling both unicast and multicast 2659 transmission MUST indicate such capability by including two 2660 full transport-specs with separate parameters for each. 2662 destination: 2663 The address to which a stream will be sent. The client may 2664 specify the multicast address with the destination parameter. 2665 To avoid becoming the unwitting perpetrator of a 2666 remote-controlled denial-of-service attack, a server SHOULD 2667 authenticate the client and SHOULD log such attempts before 2668 allowing the client to direct a media stream to an address not 2669 chosen by the server. This is particularly important if RTSP 2670 commands are issued via UDP, but implementations cannot rely on 2671 TCP as reliable means of client identification by itself. A 2672 server SHOULD not allow a client to direct media streams to an 2673 address that differs from the address commands are coming from. 2675 source: 2676 If the source address for the stream is different than can be 2677 derived from the RTSP endpoint address (the server in playback 2678 or the client in recording), the source MAY be specified. 2680 This information may also be available through SDP. However, since 2681 this is more a feature of transport than media initialization, the 2682 authoritative source for this information should be in the SETUP 2683 response. 2685 layers: 2686 The number of multicast layers to be used for this media 2687 stream. The layers are sent to consecutive addresses starting 2688 at the destination address. 2690 mode: 2691 The mode parameter indicates the methods to be supported for 2692 this session. Valid values are PLAY and RECORD. If not 2693 provided, the default is PLAY. 2695 append: 2696 If the mode parameter includes RECORD, the append parameter 2697 indicates that the media data should append to the existing 2698 resource rather than overwrite it. If appending is requested 2699 and the server does not support this, it MUST refuse the 2700 request rather than overwrite the resource identified by the 2701 URI. The append parameter is ignored if the mode parameter does 2702 not contain RECORD. 2704 interleaved: 2705 The interleaved parameter implies mixing the media stream with 2706 the control stream in whatever protocol is being used by the 2707 control stream, using the mechanism defined in Section 10.12. 2708 The argument provides the channel number to be used in the $ 2709 statement. This parameter may be specified as a range, e.g., 2710 interleaved=4-5 in cases where the transport choice for the 2711 media stream requires it. 2713 This allows RTP/RTCP to be handled similarly to the way that it is 2714 done with UDP, i.e., one channel for RTP and the other for RTCP. 2716 Multicast specific: 2718 ttl: 2719 multicast time-to-live 2721 RTP Specific: 2723 port: 2724 This parameter provides the RTP/RTCP port pair for a multicast 2725 session. It is specified as a range, e.g., port=3456-3457. 2727 client_port: 2728 This parameter provides the unicast RTP/RTCP port pair on the 2729 client where media data and control information is to be sent. 2730 It is specified as a range, e.g., port=3456-3457. 2732 server_port: 2733 This parameter provides the unicast RTP/RTCP port pair on the 2734 server where media data and control information is to be sent. 2735 It is specified as a range, e.g., port=3456-3457. 2737 ssrc: 2738 The ssrc parameter indicates the RTP SSRC [24, Sec. 3] value 2739 that should be (request) or will be (response) used by the 2740 media server. This parameter is only valid for unicast 2741 transmission. It identifies the synchronization source to be 2742 associated with the media stream. 2744 Transport = "Transport" ":" 2745 1\#transport-spec 2746 transport-spec = transport-protocol/profile[/lower-transport] 2747 *parameter 2748 transport-protocol = "RTP" 2749 profile = "AVP" 2750 lower-transport = "TCP" | "UDP" 2751 parameter = ( "unicast" | "multicast" ) 2752 | ";" "destination" [ "=" address ] 2753 | ";" "interleaved" "=" channel [ "-" channel ] 2754 | ";" "append" 2755 | ";" "ttl" "=" ttl 2756 | ";" "layers" "=" 1*DIGIT 2757 | ";" "port" "=" port [ "-" port ] 2758 | ";" "client_port" "=" port [ "-" port ] 2759 | ";" "server_port" "=" port [ "-" port ] 2760 | ";" "ssrc" "=" ssrc 2761 | ";" "mode" = <"> 1\#mode <"> 2762 ttl = 1*3(DIGIT) 2763 port = 1*5(DIGIT) 2764 ssrc = 8*8(HEX) 2765 channel = 1*3(DIGIT) 2766 address = host 2767 mode = <"> *Method <"> | Method 2769 Example: 2770 Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", 2771 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" 2773 The Transport header is restricted to describing a single RTP 2774 stream. (RTSP can also control multiple streams as a single 2775 entity.) Making it part of RTSP rather than relying on a multitude 2776 of session description formats greatly simplifies designs of 2777 firewalls. 2779 12.40 Unsupported 2781 The Unsupported response header lists the features not supported by 2782 the server. In the case where the feature was specified via the 2783 Proxy-Require field (Section 12.32), if there is a proxy on the path 2784 between the client and the server, the proxy MUST insert a message 2785 reply with an error message ``551 Option Not Supported''. 2787 See Section 12.32 for a usage example. 2789 12.41 User-Agent 2791 See [H14.42] 2793 12.42 Vary 2795 See [H14.43] 2797 12.43 Via 2799 See [H14.44]. 2801 12.44 WWW-Authenticate 2803 See [H14.46]. 2805 13 Caching 2807 In HTTP, response-request pairs are cached. RTSP differs 2808 significantly in that respect. Responses are not cacheable, with the 2809 exception of the presentation description returned by DESCRIBE or 2810 included with ANNOUNCE. (Since the responses for anything but DESCRIBE 2811 and GET_PARAMETER do not return any data, caching is not really an 2812 issue for these requests.) However, it is desirable for the continuous 2813 media data, typically delivered out-of-band with respect to RTSP, to 2814 be cached, as well as the session description. 2816 On receiving a SETUP or PLAY request, a proxy ascertains whether it 2817 has an up-to-date copy of the continuous media content and its 2818 description. It can determine whether the copy is up-to-date by 2819 issuing a SETUP or DESCRIBE request, respectively, and comparing the 2820 Last-Modified header with that of the cached copy. If the copy is not 2821 up-to-date, it modifies the SETUP transport parameters as appropriate 2822 and forwards the request to the origin server. Subsequent control 2823 commands such as PLAY or PAUSE then pass the proxy unmodified. The 2824 proxy delivers the continuous media data to the client, while possibly 2825 making a local copy for later reuse. The exact behavior allowed to the 2826 cache is given by the cache-response directives described in 2827 Section 12.8. A cache MUST answer any DESCRIBE requests if it is 2828 currently serving the stream to the requestor, as it is possible that 2829 low-level details of the stream description may have changed on the 2830 origin-server. 2832 Note that an RTSP cache, unlike the HTTP cache, is of the 2833 ``cut-through'' variety. Rather than retrieving the whole resource 2834 from the origin server, the cache simply copies the streaming data as 2835 it passes by on its way to the client. Thus, it does not introduce 2836 additional latency. 2838 To the client, an RTSP proxy cache appears like a regular media 2839 server, to the media origin server like a client. Just as an HTTP 2840 cache has to store the content type, content language, and so on for 2841 the objects it caches, a media cache has to store the presentation 2842 description. Typically, a cache eliminates all transport-references 2843 (that is, multicast information) from the presentation description, 2844 since these are independent of the data delivery from the cache to the 2845 client. Information on the encodings remains the same. If the cache is 2846 able to translate the cached media data, it would create a new 2847 presentation description with all the encoding possibilities it can 2848 offer. 2850 14 Examples 2852 The following examples refer to stream description formats that are 2853 not standards, such as RTSL. The following examples are not to be used 2854 as a reference for those formats. 2856 14.1 Media on Demand (Unicast) 2858 Client C requests a movie from media servers A ( audio.example.com) 2859 and V (video.example.com). The media description is stored on a web 2860 server W . The media description contains descriptions of the 2861 presentation and all its streams, including the codecs that are 2862 available, dynamic RTP payload types, the protocol stack, and content 2863 information such as language or copyright restrictions. It may also 2864 give an indication about the timeline of the movie. 2866 In this example, the client is only interested in the last part of the 2867 movie. 2869 C->W: GET /twister.sdp HTTP/1.1 2870 Host: www.example.com 2871 Accept: application/sdp 2873 W->C: HTTP/1.0 200 OK 2874 Content-Type: application/sdp 2876 v=0 2877 o=- 2890844526 2890842807 IN IP4 192.16.24.202 2878 s=RTSP Session 2879 m=audio 0 RTP/AVP 0 2880 a=control:rtsp://audio.example.com/twister/audio.en 2881 m=video 0 RTP/AVP 31 2882 a=control:rtsp://video.example.com/twister/video 2884 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 2885 CSeq: 1 2886 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 2888 A->C: RTSP/1.0 200 OK 2889 CSeq: 1 2890 Session: 1234 2891 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; 2892 server_port=5000-5001 2894 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 2895 CSeq: 1 2896 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 2898 V->C: RTSP/1.0 200 OK 2899 CSeq: 1 2900 Session: 1235 2901 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; 2902 server_port=5002-5003 2904 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 2905 CSeq: 2 2906 Session: 1235 2907 Range: smpte=0:10:00- 2909 V->C: RTSP/1.0 200 OK 2910 CSeq: 2 2911 Session: 1235 2912 Range: smpte=0:10:00-0:20:00 2913 RTP-Info: url=rtsp://video.example.com/twister/video; 2914 seq=12312232;rtptime=78712811 2916 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 2917 CSeq: 2 2918 Session: 1234 2919 Range: smpte=0:10:00- 2921 A->C: RTSP/1.0 200 OK 2922 CSeq: 2 2923 Session: 1234 2924 Range: smpte=0:10:00-0:20:00 2925 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; 2926 seq=876655;rtptime=1032181 2928 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 2929 CSeq: 3 2930 Session: 1234 2932 A->C: RTSP/1.0 200 OK 2933 CSeq: 3 2935 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 2936 CSeq: 3 2937 Session: 1235 2939 V->C: RTSP/1.0 200 OK 2940 CSeq: 3 2942 Even though the audio and video track are on two different servers, 2943 and may start at slightly different times and may drift with respect 2944 to each other, the client can synchronize the two using standard RTP 2945 methods, in particular the time scale contained in the RTCP sender 2946 reports. 2948 14.2 Streaming of a Container file 2950 For purposes of this example, a container file is a storage entity in 2951 which multiple continuous media types pertaining to the same end-user 2952 presentation are present. In effect, the container file represents a 2953 RTSP presentation, with each of its components being RTSP streams. 2954 Container files are a widely used means to store such presentations. 2955 While the components are transported as independent streams, it is 2956 desirable to maintain a common context for those streams at the server 2957 end. 2959 This enables the server to keep a single storage handle open 2960 easily. It also allows treating all the streams equally in case of 2961 any prioritization of streams by the server. 2963 It is also possible that the presentation author may wish to prevent 2964 selective retrieval of the streams by the client in order to preserve 2965 the artistic effect of the combined media presentation. Similarly, in 2966 such a tightly bound presentation, it is desirable to be able to 2967 control all the streams via a single control message using an 2968 aggregate URL. 2970 The following is an example of using a single RTSP session to control 2971 multiple streams. It also illustrates the use of aggregate URLs. 2973 Client C requests a presentation from media server M . The movie is 2974 stored in a container file. The client has obtained a RTSP URL to the 2975 container file. 2977 C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 2978 CSeq: 1 2980 M->C: RTSP/1.0 200 OK 2981 CSeq: 1 2982 Content-Type: application/sdp 2983 Content-Length: 164 2984 v=0 2985 o=- 2890844256 2890842807 IN IP4 172.16.2.93 2986 s=RTSP Session 2987 i=An Example of RTSP Session Usage 2988 a=control:rtsp://foo/twister 2989 t=0 0 2990 m=audio 0 RTP/AVP 0 2991 a=control:rtsp://foo/twister/audio 2992 m=video 0 RTP/AVP 26 2993 a=control:rtsp://foo/twister/video 2995 C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 2996 CSeq: 2 2997 Transport: RTP/AVP;unicast;client_port=8000-8001 2999 M->C: RTSP/1.0 200 OK 3000 CSeq: 2 3001 Transport: RTP/AVP;unicast;client_port=8000-8001; 3002 server_port=9000-9001 3003 Session: 1234 3005 C->M: SETUP rtsp://foo/twister/video RTSP/1.0 3006 CSeq: 3 3007 Transport: RTP/AVP;unicast;client_port=8002-8003 3008 Session: 1234 3010 M->C: RTSP/1.0 200 OK 3011 CSeq: 3 3012 Transport: RTP/AVP;unicast;client_port=8002-8003; 3013 server_port=9004-9005 3014 Session: 1234 3016 C->M: PLAY rtsp://foo/twister RTSP/1.0 3017 CSeq: 4 3018 Range: npt=0- 3019 Session: 1234 3021 M->C: RTSP/1.0 200 OK 3022 CSeq: 4 3023 Session: 1234 3024 RTP-Info: url=rtsp://foo/twister/video; 3025 seq=9810092;rtptime=3450012 3027 C->M: PAUSE rtsp://foo/twister/video RTSP/1.0 3028 CSeq: 5 3029 Session: 1234 3031 M->C: RTSP/1.0 460 Only aggregate operation allowed 3032 CSeq: 5 3034 C->M: PAUSE rtsp://foo/twister RTSP/1.0 3035 CSeq: 6 3036 Session: 1234 3038 M->C: RTSP/1.0 200 OK 3039 CSeq: 6 3040 Session: 1234 3042 C->M: SETUP rtsp://foo/twister RTSP/1.0 3043 CSeq: 7 3044 Transport: RTP/AVP;unicast;client_port=10000 3046 M->C: RTSP/1.0 459 Aggregate operation not allowed 3047 CSeq: 7 3049 In the first instance of failure, the client tries to pause one stream 3050 (in this case video) of the presentation. This is disallowed for that 3051 presentation by the server. In the second instance, the aggregate URL 3052 may not be used for SETUP and one control message is required per 3053 stream to set up transport parameters. 3055 This keeps the syntax of the Transport header simple and allows 3056 easy parsing of transport information by firewalls. 3058 14.3 Single Stream Container Files 3060 Some RTSP servers may treat all files as though they are ``container 3061 files'', yet other servers may not support such a concept. Because of 3062 this, clients SHOULD use the rules set forth in the session 3063 description for request URLs, rather than assuming that a consistant 3064 URL may always be used throughout. Here's an example of how a 3065 multi-stream server might expect a single-stream file to be served: 3067 C->S DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 3068 Accept: application/x-rtsp-mh, application/sdp 3069 CSeq: 1 3071 S->C RTSP/1.0 200 OK 3072 CSeq: 1 3073 Content-base: rtsp://foo.com/test.wav/ 3074 Content-type: application/sdp 3075 Content-length: 48 3076 v=0 3077 o=- 872653257 872653257 IN IP4 172.16.2.187 3078 s=mu-law wave file 3079 i=audio test 3080 t=0 0 3081 m=audio 0 RTP/AVP 0 3082 a=control:streamid=0 3084 C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 3085 Transport: RTP/AVP/UDP;unicast; 3086 client_port=6970-6971;mode=play 3087 CSeq: 2 3089 S->C RTSP/1.0 200 OK 3090 Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; 3091 server_port=6970-6971;mode=play 3092 CSeq: 2 3093 Session: 2034820394 3095 C->S PLAY rtsp://foo.com/test.wav RTSP/1.0 3096 CSeq: 3 3097 Session: 2034820394 3099 S->C RTSP/1.0 200 OK 3100 CSeq: 3 3101 Session: 2034820394 3102 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; 3103 seq=981888;rtptime=3781123 3105 Note the different URL in the SETUP command, and then the switch back 3106 to the aggregate URL in the PLAY command. This makes complete sense 3107 when there are multiple streams with aggregate control, but is less 3108 than intuitive in the special case where the number of streams is one. 3110 In this special case, it is recommended that servers be forgiving of 3111 implementations that send: 3113 C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 3114 CSeq: 3 3116 In the worst case, servers should send back: 3118 S->C RTSP/1.0 460 Only aggregate operation allowed 3119 CSeq: 3 3121 One would also hope that server implementations are also forgiving of 3122 the following: 3124 C->S SETUP rtsp://foo.com/test.wav RTSP/1.0 3125 Transport: rtp/avp/udp;client_port=6970-6971;mode=play 3126 CSeq: 2 3128 Since there is only a single stream in this file, it's not ambiguous 3129 what this means. 3131 14.4 Live Media Presentation Using Multicast 3133 The media server M chooses the multicast address and port. Here, we 3134 assume that the web server only contains a pointer to the full 3135 description, while the media server M maintains the full description. 3137 C->W: GET /concert.sdp HTTP/1.1 3138 Host: www.example.com 3140 W->C: HTTP/1.1 200 OK 3141 Content-Type: application/x-rtsl 3143 3144 3145 3147 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 3148 CSeq: 1 3150 M->C: RTSP/1.0 200 OK 3151 CSeq: 1 3152 Content-Type: application/sdp 3153 Content-Length: 44 3155 v=0 3156 o=- 2890844526 2890842807 IN IP4 192.16.24.202 3157 s=RTSP Session 3158 m=audio 3456 RTP/AVP 0 3159 a=control:rtsp://live.example.com/concert/audio 3160 c=IN IP4 224.2.0.1/16 3162 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 3163 CSeq: 2 3164 Transport: RTP/AVP;multicast 3166 M->C: RTSP/1.0 200 OK 3167 CSeq: 2 3168 Transport: RTP/AVP;multicast;destination=224.2.0.1; 3169 port=3456-3457;ttl=16 3170 Session: 0456804596 3172 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3173 CSeq: 3 3174 Session: 0456804596 3176 M->C: RTSP/1.0 200 OK 3177 CSeq: 3 3178 Session: 0456804596 3180 14.5 Playing media into an existing session 3182 A conference participant C wants to have the media server M play back 3183 a demo tape into an existing conference. C indicates to the media 3184 server that the network addresses and encryption keys are already 3185 given by the conference, so they should not be chosen by the server. 3186 The example omits the simple ACK responses. 3188 C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0 3189 CSeq: 1 3190 Accept: application/sdp 3192 M->C: RTSP/1.0 200 1 OK 3193 Content-type: application/sdp 3194 Content-Length: 44 3196 v=0 3197 o=- 2890844526 2890842807 IN IP4 192.16.24.202 3198 s=RTSP Session 3199 i=See above 3200 t=0 0 3201 m=audio 0 RTP/AVP 0 3203 C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 3204 CSeq: 2 3205 Transport: RTP/AVP;multicast;destination=225.219.201.15; 3206 port=7000-7001;ttl=127 3207 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 3209 M->C: RTSP/1.0 200 OK 3210 CSeq: 2 3211 Transport: RTP/AVP;multicast;destination=225.219.201.15; 3212 port=7000-7001;ttl=127 3213 Session: 91389234234 3214 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 3216 C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 3217 CSeq: 3 3218 Session: 91389234234 3220 M->C: RTSP/1.0 200 OK 3221 CSeq: 3 3223 14.6 Recording 3225 The conference participant client C asks the media server M to record 3226 the audio and video portions of a meeting. The client uses the 3227 ANNOUNCE method to provide meta-information about the recorded session 3228 to the server. 3230 C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 3231 CSeq: 90 3232 Content-Type: application/sdp 3233 Content-Length: 121 3235 v=0 3236 o=camera1 3080117314 3080118787 IN IP4 195.27.192.36 3237 s=IETF Meeting, Munich - 1 3238 i=The thirty-ninth IETF meeting will be held in Munich, Germany 3239 u=http://www.ietf.org/meetings/Munich.html 3240 e=IETF Channel 1 3241 p=IETF Channel 1 +49-172-2312 451 3242 c=IN IP4 224.0.1.11/127 3243 t=3080271600 3080703600 3244 a=tool:sdr v2.4a6 3245 a=type:test 3246 m=audio 21010 RTP/AVP 5 3247 c=IN IP4 224.0.1.11/127 3248 a=ptime:40 3249 m=video 61010 RTP/AVP 31 3250 c=IN IP4 224.0.1.12/127 3252 M->C: RTSP/1.0 200 OK 3253 CSeq: 90 3255 C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0 3256 CSeq: 91 3257 Transport: RTP/AVP;multicast;destination=224.0.1.11; 3258 port=21010-21011;mode=record;ttl=127 3260 M->C: RTSP/1.0 200 OK 3261 CSeq: 91 3262 Session: 508876 3263 Transport: RTP/AVP;multicast;destination=224.0.1.11; 3264 port=21010-21011;mode=record;ttl=127 3266 C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0 3267 CSeq: 92 3268 Session: 508876 3269 Transport: RTP/AVP;multicast;destination=224.0.1.12; 3270 port=61010-61011;mode=record;ttl=127 3272 M->C: RTSP/1.0 200 OK 3273 CSeq: 92 3274 Transport: RTP/AVP;multicast;destination=224.0.1.12; 3275 port=61010-61011;mode=record;ttl=127 3277 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 3278 CSeq: 93 3279 Session: 508876 3280 Range: clock=19961110T1925-19961110T2015 3282 M->C: RTSP/1.0 200 OK 3283 CSeq: 93 3285 15 Syntax 3287 The RTSP syntax is described in an augmented Backus-Naur form (BNF) 3288 as used in RFC 2068 [2]. 3290 15.1 Base Syntax 3292 OCTET = 3293 CHAR = 3294 UPALPHA = 3295 LOALPHA = 3296 ALPHA = UPALPHA | LOALPHA 3297 DIGIT = 3298 CTL = 3300 CR = 3301 LF = 3303 SP = 3304 HT = 3305 <"> = 3306 CRLF = CR LF 3307 LWS = [CRLF] 1*( SP | HT ) 3309 TEXT = 3310 tspecials = "(" | ")" | "<" | ">" | "@" 3311 | "," | ";" | ":" | "\" | <"> 3312 | "/" | "[" | "]" | "?" | "=" 3313 | "{" | "}" | SP | HT 3315 token = 1* 3316 quoted-string = ( <"> *(qdtext) <"> ) 3317 qdtext = > 3318 quoted-pair = "\" CHAR 3320 message-header = field-name ":" [ field-value ] CRLF 3321 field-name = token 3322 field-value = *( field-content | LWS ) 3323 field-content = 3328 safe = "\$" | "-" | "_" | "." | "+" 3329 extra = "!" | "*" | "$'$" | "(" | ")" | "," 3331 hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" | 3332 "a" | "b" | "c" | "d" | "e" | "f" 3333 escape = "\%" hex hex 3334 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" 3336 unreserved = alpha | digit | safe | extra 3337 xchar = unreserved | reserved | escape 3339 16 Security Considerations 3341 Because of the similarity in syntax and usage between RTSP servers 3342 and HTTP servers, the security considerations outlined in [H15] apply. 3343 Specifically, please note the following: 3345 Authentication Mechanisms: 3346 RTSP and HTTP share common authentication schemes, and thus 3347 should follow the same prescriptions with regards to 3348 authentication. See [H15.1] for client authentication issues, 3349 and [H15.2] for issues regarding support for multiple 3350 authentication mechanisms. 3352 Abuse of Server Log Information: 3353 RTSP and HTTP servers will presumably have similar logging 3354 mechanisms, and thus should be equally guarded in protecting 3355 the contents of those logs, thus protecting the privacy of the 3356 users of the servers. See [H15.3] for HTTP server 3357 recommendations regarding server logs. 3359 Transfer of Sensitive Information: 3360 There is no reason to believe that information transferred via 3361 RTSP may be any less sensitive than that normally transmitted 3362 via HTTP. Therefore, all of the precautions regarding the 3363 protection of data privacy and user privacy apply to 3364 implementors of RTSP clients, servers, and proxies. See [H15.4] 3365 for further details. 3367 Attacks Based On File and Path Names: 3368 Though RTSP URLs are opaque handles that do not necessarily 3369 have file system semantics, it is anticipated that many 3370 implementations will translate portions of the request URLs 3371 directly to file system calls. In such cases, file systems 3372 SHOULD follow the precautions outlined in [H15.5], such as 3373 checking for ``..'' in path components. 3375 Personal Information: 3376 RTSP clients are often privy to the same information that HTTP 3377 clients are (user name, location, etc.) and thus should be 3378 equally. See [H15.6] for further recommendations. 3380 Privacy Issues Connected to Accept Headers: 3381 Since may of the same ``Accept'' headers exist in RTSP as in 3382 HTTP, the same caveats outlined in [H15.7] with regards to 3383 their use should be followed. 3385 DNS Spoofing: 3386 Presumably, given the longer connection times typically 3387 associated to RTSP sessions relative to HTTP sessions, RTSP 3388 client DNS optimizations should be less prevalent. Nonetheless, 3389 the recommendations provided in [H15.8] are still relevant to 3390 any implementation which attempts to rely on a DNS-to-IP 3391 mapping to hold beyond a single use of the mapping. 3393 Location Headers and Spoofing: 3394 If a single server supports multiple organizations that do not 3395 trust one another, then it must check the values of Location 3396 and Content-Location headers in responses that are generated 3397 under control of said organizations to make sure that they do 3398 not attempt to invalidate resources over which they have no 3399 authority. ([H15.9]) 3401 In addition to the recommendations in the current HTTP specification 3402 (RFC 2068 [2], as of this writing), future HTTP specifications may 3403 provide additional guidance on security issues. 3405 The following are added considerations for RTSP implementations. 3407 Concentrated denial-of-service attack: 3408 The protocol offers the opportunity for a remote-controlled 3409 denial-of-service attack. The attacker may initiate traffic 3410 flows to one or more IP addresses by specifying them as the 3411 destination in SETUP requests. While the attacker's IP address 3412 may be known in this case, this is not always useful in 3413 prevention of more attacks or ascertaining the attackers 3414 identity. Thus, an RTSP server SHOULD only allow 3415 client-specified destinations for RTSP-initiated traffic flows 3416 if the server has verified the client's identity, either 3417 against a database of known users using RTSP authentication 3418 mechanisms (preferrably digest authentication or stronger), or 3419 other secure means. 3421 Session hijacking: 3422 Since there is no relation between a transport layer connection 3423 and an RTSP session, it is possible for a malicious client to 3424 issue requests with random session identifiers which would 3425 affect unsuspecting clients. The server SHOULD use a large, 3426 random and non-sequential session identifier to minimize the 3427 possibility of this kind of attack. 3429 Authentication: 3430 Servers SHOULD implement both basic and digest [8] 3431 authentication. In environments requiring tighter security for 3432 the control messages, transport layer mechanisms such as TLS 3433 (RFC XXXX [7]) SHOULD be used. 3435 Stream issues: 3436 RTSP only provides for stream control. Stream delivery issues 3437 are not covered in this section, nor in the rest of this draft. 3438 RTSP implementations will most likely rely on other protocols 3439 such as RTP, IP multicast, RSVP and IGMP, and should address 3440 security considerations brought up in those and other 3441 applicable specifications. 3443 Persistently suspicious behavior: 3444 RTSP servers SHOULD return error code 403 (Forbidden) upon 3445 receiving a single instance of behavior which is deemed a 3446 security risk. RTSP servers SHOULD also be aware of attempts to 3447 probe the server for weaknesses and entry points and MAY 3448 arbitrarily disconnect and ignore further requests clients 3449 which are deemed to be in violation of local security policy. 3451 Appendix A: RTSP Protocol State Machines 3453 The RTSP client and server state machines describe the behavior of 3454 the protocol from RTSP session initialization through RTSP session 3455 termination. 3457 State is defined on a per object basis. An object is uniquely 3458 identified by the stream URL and the RTSP session identifier. Any 3459 request/reply using aggregate URLs denoting RTSP presentations 3460 composed of multiple streams will have an effect on the individual 3461 states of all the streams. For example, if the presentation /movie 3462 contains two streams, /movie/audio and /movie/video, then the 3463 following command: 3465 PLAY rtsp://foo.com/movie RTSP/1.0 3466 CSeq: 559 3467 Session: 12345 3469 will have an effect on the states of movie/audio and movie/video. 3471 This example does not imply a standard way to represent streams in 3472 URLs or a relation to the filesystem. See Section 3.2. 3474 The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER 3475 do not have any effect on client or server state and are therefore not 3476 listed in the state tables. 3478 A.1 Client State Machine 3480 The client can assume the following states: 3482 Init: 3483 SETUP has been sent, waiting for reply. 3485 Ready: 3486 SETUP reply received or PAUSE reply received while in Playing 3487 state. 3489 Playing: 3490 PLAY reply received 3492 Recording: 3493 RECORD reply received 3495 In general, the client changes state on receipt of replies to 3496 requests. Note that some requests are effective at a future time or 3497 position (such as a PAUSE), and state also changes accordingly. If no 3498 explicit SETUP is required for the object (for example, it is 3499 available via a multicast group), state begins at Ready. In this case, 3500 there are only two states, Ready and Playing. The client also changes 3501 state from Playing/Recording to Ready when the end of the requested 3502 range is reached. 3504 The ``next state'' column indicates the state assumed after receiving 3505 a success response (2xx). If a request yields a status code of 3xx, 3506 the state becomes Init, and a status code of 4xx yields no change in 3507 state. Messages not listed for each state MUST NOT be issued by the 3508 client in that state, with the exception of messages not affecting 3509 state, as listed above. Receiving a REDIRECT from the server is 3510 equivalent to receiving a 3xx redirect status from the server. 3512 state message sent next state after response 3513 Init SETUP Ready 3514 TEARDOWN Init 3515 Ready PLAY Playing 3516 RECORD Recording 3517 TEARDOWN Init 3518 SETUP Ready 3519 Playing PAUSE Ready 3520 TEARDOWN Init 3521 PLAY Playing 3522 SETUP Playing (changed transport) 3523 Recording PAUSE Ready 3524 TEARDOWN Init 3525 RECORD Recording 3526 SETUP Recording (changed transport) 3528 A.2 Server State Machine 3530 The server can assume the following states: 3532 Init: 3533 The initial state, no valid SETUP has been received yet. 3535 Ready: 3536 Last SETUP received was successful, reply sent or after 3537 playing, last PAUSE received was successful, reply sent. 3539 Playing: 3540 Last PLAY received was successful, reply sent. Data is being 3541 sent. 3543 Recording: 3544 The server is recording media data. 3546 In general, the server changes state on receiving requests. If the 3547 server is in state Playing or Recording and in unicast mode, it MAY 3548 revert to Init and tear down the RTSP session if it has not received 3549 ``wellness'' information, such as RTCP reports or RTSP commands, from 3550 the client for a defined interval, with a default of one minute. The 3551 server can declare another timeout value in the Session response 3552 header (Section 12.37). If the server is in state Ready, it MAY revert 3553 to Init if it does not receive an RTSP request for an interval of more 3554 than one minute. Note that some requests (such as PAUSE) may be 3555 effective at a future time or position, and server state changes at 3556 the appropriate time. The server reverts from state Playing or 3557 Recording to state Ready at the end of the range requested by the 3558 client. 3560 The REDIRECT message, when sent, is effective immediately unless it 3561 has a Range header specifying when the redirect is effective. In such 3562 a case, server state will also change at the appropriate time. 3564 If no explicit SETUP is required for the object, the state starts at 3565 Ready and there are only two states, Ready and Playing. 3567 The ``next state'' column indicates the state assumed after sending a 3568 success response (2xx). If a request results in a status code of 3xx, 3569 the state becomes Init. A status code of 4xx results in no change. 3571 state message received next state 3572 Init SETUP Ready 3573 TEARDOWN Init 3574 Ready PLAY Playing 3575 SETUP Ready 3576 TEARDOWN Init 3577 RECORD Recording 3578 Playing PLAY Playing 3579 PAUSE Ready 3580 TEARDOWN Init 3581 SETUP Playing 3582 Recording RECORD Recording 3583 PAUSE Ready 3584 TEARDOWN Init 3585 SETUP Recording 3587 Appendix B: Interaction with RTP 3589 RTSP allows media clients to control selected, non-contiguous 3590 sections of media presentations, rendering those streams with an RTP 3591 media layer[24]. The media layer rendering the RTP stream should not 3592 be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP 3593 timestamps MUST be continuous and monotonic across jumps of NPT. 3595 As an example, assume a clock frequency of 8000 Hz, a packetization 3596 interval of 100 ms and an initial sequence number and timestamp of 3597 zero. First we play NPT 10 through 15, then skip ahead and play NPT 18 3598 through 20. The first segment is presented as RTP packets with 3599 sequence numbers 0 through 49 and timestamp 0 through 39,200. The 3600 second segment consists of RTP packets with sequence number 50 through 3601 69, with timestamps 40,000 through 55,200. 3603 We cannot assume that the RTSP client can communicate with the RTP 3604 media agent, as the two may be independent processes. If the RTP 3605 timestamp shows the same gap as the NPT, the media agent will 3606 assume that there is a pause in the presentation. If the jump in 3607 NPT is large enough, the RTP timestamp may roll over and the media 3608 agent may believe later packets to be duplicates of packets just 3609 played out. 3611 For certain datatypes, tight integration between the RTSP layer and 3612 the RTP layer will be necessary. This by no means precludes the 3613 above restriction. Combined RTSP/RTP media clients should use the 3614 RTP-Info field to determine whether incoming RTP packets were sent 3615 before or after a seek. 3617 For continuous audio, the server SHOULD set the RTP marker bit at the 3618 beginning of serving a new PLAY request. This allows the client to 3619 perform playout delay adaptation. 3621 For scaling (see Section 12.34), RTP timestamps should correspond to 3622 the playback timing. For example, when playing video recorded at 30 3623 frames/second at a scale of two and speed (Section 12.35) of one, the 3624 server would drop every second frame to maintain and deliver video 3625 packets with the normal timestamp spacing of 3,000 per frame, but NPT 3626 would increase by 1/15 second for each video frame. 3628 The client can maintain a correct display of NPT by noting the RTP 3629 timestamp value of the first packet arriving after repositioning. The 3630 sequence parameter of the RTP-Info (Section 12.33) header provides the 3631 first sequence number of the next segment. 3633 Appendix C: Use of SDP for RTSP Session Descriptions 3635 The Session Description Protocol (SDP, RFC XXXX [6]) may be used to 3636 describe streams or presentations in RTSP. Such usage is limited to 3637 specifying means of access and encoding(s) for: 3639 aggregate control: 3640 A presentation composed of streams from one or more servers 3641 that are not available for aggregate control. Such a 3642 description is typically retrieved by HTTP or other non-RTSP 3643 means. However, they may be received with ANNOUNCE methods. 3645 non-aggregate control: 3646 A presentation composed of multiple streams from a single 3647 server that are available for aggregate control. Such a 3648 description is typically returned in reply to a DESCRIBE 3649 request on a URL, or received in an ANNOUNCE method. 3651 This appendix describes how an SDP file, retrieved, for example, 3652 through HTTP, determines the operation of an RTSP session. It also 3653 describes how a client should interpret SDP content returned in reply 3654 to a DESCRIBE request. SDP provides no mechanism by which a client can 3655 distinguish, without human guidance, between several media streams to 3656 be rendered simultaneously and a set of alternatives (e.g., two audio 3657 streams spoken in different languages). 3659 C.1 Definitions 3661 The terms ``session-level'', ``media-level'' and other key/attribute 3662 names and values used in this appendix are to be used as defined in 3663 SDP (RFC XXXX [6]): 3665 C.1.1 Control URL 3667 The ``a=control:'' attribute is used to convey the control URL. This 3668 attribute is used both for the session and media descriptions. If used 3669 for individual media, it indicates the URL to be used for controlling 3670 that particular media stream. If found at the session level, the 3671 attribute indicates the URL for aggregate control. 3673 Example: 3674 a=control:rtsp://example.com/foo 3676 This attribute may contain either relative and absolute URLs, 3677 following the rules and conventions set out in RFC 1808 [25]. 3678 Implementations should look for a base URL in the following order: 3680 1. The RTSP Content-Base field 3681 2. The RTSP Content-Location field 3682 3. The RTSP request URL 3684 If this attribute contains only an asterisk (*), then the URL is 3685 treated as if it were an empty embedded URL, and thus inherits the 3686 entire base URL. 3688 C.1.2 Media streams 3690 The ``m='' field is used to enumerate the streams. It is expected that 3691 all the specified streams will be rendered with appropriate 3692 synchronization. If the session is unicast, the port number serves as 3693 a recommendation from the server to the client; the client still has 3694 to include it in its SETUP request and may ignore this recommendation. 3695 If the server has no preference, it SHOULD set the port number value 3696 to zero. 3698 Example: 3699 m=audio 0 RTP/AVP 31 3701 C.1.3 Payload type(s) 3703 The payload type(s) are specified in the ``m='' field. In case the 3704 payload type is a static payload type from RFC 1890 [1], no other 3705 information is required. In case it is a dynamic payload type, the 3706 media attribute ``rtpmap'' is used to specify what the media is. The 3707 ``encoding name'' within the ``rtpmap'' attribute may be one of those 3708 specified in RFC 1890 (Sections 5 and 6), or an experimental encoding 3709 with a ``X-'' prefix as specified in SDP (RFC XXXX [6]). 3710 Codec-specific parameters are not specified in this field, but rather 3711 in the ``fmtp'' attribute described below. Implementors seeking to 3712 register new encodings should follow the procedure in RFC 1890 [1]. If 3713 the media type is not suited to the RTP AV profile, then it is 3714 recommended that a new profile be created and the appropriate profile 3715 name be used in lieu of ``RTP/AVP'' in the ``m='' field. 3717 C.1.4 Format-specific parameters 3719 Format-specific parameters are conveyed using the ``fmtp'' media 3720 attribute. The syntax of the ``fmtp'' attribute is specific to the 3721 encoding(s) that the attribute refers to. Note that the packetization 3722 interval is conveyed using the ``ptime'' attribute. 3724 C.1.5 Range of presentation 3726 The ``a=range'' attribute defines the total time range of the stored 3727 session. (The length of live sessions can be deduced from the ``t'' 3728 and ``r'' parameters.) Unless the presentation contains media streams 3729 of different durations, the length attribute is a session-level 3730 attribute. The unit is specified first, followed by the value range. 3731 The units and their values are as defined in Section 3.5, 3.6 and 3.7. 3733 Examples: 3734 a=range:npt=0-34.4368 3735 a=range:clock=19971113T2115-19971113T2203 3737 C.1.6 Time of availability 3739 The ``t='' field MUST contain suitable values for the start and stop 3740 times for both aggregate and non-aggregate stream control. With 3741 aggregate control, the server SHOULD indicate a stop time value for 3742 which it guarantees the description to be valid, and a start time that 3743 is equal to or before the time at which the DESCRIBE request was 3744 received. It MAY also indicate start and stop times of 0, meaning that 3745 the session is always available. With non-aggregate control, the 3746 values should reflect the actual period for which the session is 3747 available in keeping with SDP semantics, and not depend on other means 3748 (such as the life of the web page containing the description) for this 3749 purpose. 3751 C.1.7 Connection Information 3753 In SDP, the ``c='' field contains the destination address for the 3754 media stream. However, for on-demand unicast streams and some 3755 multicast streams, the destination address is specified by the client 3756 via the SETUP request. Unless the media content has a fixed 3757 destination address, the ``c='' field is to be set to a suitable null 3758 value. For addresses of type ``IP4'', this value is ``0.0.0.0''. 3760 C.1.8 Entity Tag 3762 The optional ``a=etag'' attribute identifies a version of the session 3763 description. It is opaque to the client. SETUP requests may include 3764 this identifier in the If-Match field (see section 12.22) to only 3765 allow session establishment if this attribute value still corresponds 3766 to that of the current description. The attribute value is opaque and 3767 may contain any character allowed within SDP attribute values. 3769 Example: 3770 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 3772 One could argue that the ``o='' field provides identical 3773 functionality. However, it does so in a manner that would put 3774 constraints on servers that need to support multiple session 3775 description types other than SDP for the same piece of media 3776 content. 3778 C.2 Aggregate Control Not Available 3780 If a presentation does not support aggregate control and multiple 3781 media sections are specified, each section MUST have the control URL 3782 specified via the ``a=control:'' attribute. 3784 Example: 3785 v=0 3786 o=- 2890844256 2890842807 IN IP4 204.34.34.32 3787 s=I came from a web page 3788 t=0 0 3789 c=IN IP4 0.0.0.0 3790 m=video 8002 RTP/AVP 31 3791 a=control:rtsp://audio.com/movie.aud 3792 m=audio 8004 RTP/AVP 3 3793 a=control:rtsp://video.com/movie.vid 3795 Note that the position of the control URL in the description implies 3796 that the client establishes separate RTSP control sessions to the 3797 servers audio.com and video.com. 3799 It is recommended that an SDP file contains the complete media 3800 initialization information even if it is delivered to the media client 3801 through non-RTSP means. This is necessary as there is no mechanism to 3802 indicate that the client should request more detailed media stream 3803 information via DESCRIBE. 3805 C.3 Aggregate Control Available 3807 In this scenario, the server has multiple streams that can be 3808 controlled as a whole. In this case, there are both a media-level 3809 ``a=control:'' attributes, which are used to specify the stream URLs, 3810 and a session-level ``a=control:'' attribute which is used as the 3811 request URL for aggregate control. If the media-level URL is relative, 3812 it is resolved to absolute URLs according to Section C.1.1 above. 3814 If the presentation comprises only a single stream, the media-level 3815 ``a=control:'' attribute may be omitted altogether. However, if the 3816 presentation contains more than one stream, each media stream section 3817 MUST contain its own ``a=control'' attribute. 3819 Example: 3820 v=0 3821 o=- 2890844256 2890842807 IN IP4 204.34.34.32 3822 s=I contain 3823 i= 3824 t=0 0 3825 c=IN IP4 0.0.0.0 3826 a=control:rtsp://example.com/movie/ 3827 m=video 8002 RTP/AVP 31 3828 a=control:trackID=1 3829 m=audio 8004 RTP/AVP 3 3830 a=control:trackID=2 3832 In this example, the client is required to establish a single RTSP 3833 session to the server, and uses the URLs 3834 rtsp://example.com/movie/trackID=1 and 3835 rtsp://example.com/movie/trackID=2 to set up the video and audio 3836 streams, respectively. The URL rtsp://example.com/movie/ controls the 3837 whole movie. 3839 Appendix D: Minimal RTSP implementation 3841 D.1 Client 3843 A client implementation MUST be able to do the following : 3845 * Generate the following requests : 3846 SETUP, TEARDOWN, and one of PLAY (i.e., a minimal playback client) 3847 or RECORD (i.e., a minimal recording client). If RECORD is 3848 implemented, ANNOUNCE must be implemented as well. 3849 * Include the following headers in requests: 3850 CSeq, Connection, Session, Transport. If ANNOUNCE is implemented, 3851 the capability to include headers Content-Language, 3852 Content-Encoding, Content-Length, and Content-Type should be as 3853 well. 3854 * Parse and understand the following headers in responses: CSeq, 3855 Connection, Session, Transport, Content-Language, 3856 Content-Encoding, Content-Length, Content-Type. If RECORD is 3857 implemented, the Location header must be understood as well. 3858 RTP-compliant implementations should also implement RTP-Info. 3859 * Understand the class of each error code received and notify the 3860 end-user, if one is present, of error codes in classes 4xx and 3861 5xx. The notification requirement may be relaxed if the end-user 3862 explicitly does not want it for one or all status codes. 3863 * Expect and respond to asynchronous requests from the server, such 3864 as ANNOUNCE. This does not necessarily mean that it should 3865 implement the ANNOUNCE method, merely that it MUST respond 3866 positively or negatively to any request received from the server. 3868 Though not required, the following are highly recommended at the time 3869 of publication for practical interoperability with initial 3870 implementations and/or to be a ``good citizen''. 3872 * Implement RTP/AVP/UDP as a valid transport. 3873 * Inclusion of the User-Agent header. 3874 * Understand SDP session descriptions as defined in Appendix C 3875 * Accept media initialization formats (such as SDP) from standard 3876 input, command line, or other means appropriate to the operating 3877 environment to act as a ``helper application'' for other 3878 applications (such as web browsers). 3880 There may be RTSP applications different from those initially 3881 envisioned by the contributors to the RTSP specification for which 3882 the requirements above do not make sense. Therefore, the 3883 recommendations above serve only as guidelines instead of strict 3884 requirements. 3886 D.1.1 Basic Playback 3888 To support on-demand playback of media streams, the client MUST 3889 additionally be able to do the following: 3890 * generate the PAUSE request; 3891 * implement the REDIRECT method, and the Location header. 3893 D.1.2 Authentication-enabled 3895 In order to access media presentations from RTSP servers that require 3896 authentication, the client MUST additionally be able to do the 3897 following: 3898 * recognize the 401 status code; 3899 * parse and include the WWW-Authenticate header; 3900 * implement Basic Authentication and Digest Authentication. 3902 D.2 Server 3904 A minimal server implementation MUST be able to do the following: 3906 * Implement the following methods: SETUP, TEARDOWN, OPTIONS and 3907 either PLAY (for a minimal playback server) or RECORD (for a 3908 minimal recording server). 3909 If RECORD is implemented, ANNOUNCE should be implemented as well. 3910 * Include the following headers in responses: Connection, 3911 Content-Length, Content-Type, Content-Language, Content-Encoding, 3912 Transport, Public. The capability to include the Location header 3913 should be implemented if the RECORD method is. RTP-compliant 3914 implementations should also implement the RTP-Info field. 3915 * Parse and respond appropriately to the following headers in 3916 requests: Connection, Session, Transport, Require. 3918 Though not required, the following are highly recommended at the time 3919 of publication for practical interoperability with initial 3920 implementations and/or to be a ``good citizen''. 3922 * Implement RTP/AVP/UDP as a valid transport. 3923 * Inclusion of the Server header. 3924 * Implement the DESCRIBE method. 3925 * Generate SDP session descriptions as defined in Appendix C 3927 There may be RTSP applications different from those initially 3928 envisioned by the contributors to the RTSP specification for which 3929 the requirements above do not make sense. Therefore, the 3930 recommendations above serve only as guidelines instead of strict 3931 requirements. 3933 D.2.1 Basic Playback 3935 To support on-demand playback of media streams, the server MUST 3936 additionally be able to do the following: 3938 * Recognize the Range header, and return an error if seeking is not 3939 supported. 3940 * Implement the PAUSE method. 3942 In addition, in order to support commonly-accepted user interface 3943 features, the following are highly recommended for on-demand media 3944 servers: 3946 * Include and parse the Range header, with NPT units. Implementation 3947 of SMPTE units is recommended. 3948 * Include the length of the media presentation in the media 3949 initialization information. 3950 * Include mappings from data-specific timestamps to NPT. When RTP is 3951 used, the rtptime portion of the RTP-Info field may be used to map 3952 RTP timestamps to NPT. 3954 Client implementations may use the presence of length information 3955 to determine if the clip is seekable, and visably disable seeking 3956 features for clips for which the length information is unavailable. 3957 A common use of the presentation length is to implement a ``slider 3958 bar'' which serves as both a progress indicator and a timeline 3959 positioning tool. 3961 Mappings from RTP timestamps to NPT are necessary to ensure correct 3962 positioning of the slider bar. 3964 D.2.2 Authentication-enabled 3966 In order to correctly handle client authentication, the server MUST 3967 additionally be able to do the following: 3969 * Generate the 401 status code when authentication is required for 3970 the resource. 3971 * Parse and include the WWW-Authenticate header 3972 * Implement Basic Authentication and Digest Authentication 3974 Appendix E: Author Addresses 3976 Henning Schulzrinne 3977 Dept. of Computer Science 3978 Columbia University 3979 1214 Amsterdam Avenue 3980 New York, NY 10027 3981 USA 3982 electronic mail: schulzrinne@cs.columbia.edu 3984 Anup Rao 3985 Netscape Communications Corp. 3986 501 E. Middlefield Road 3987 Mountain View, CA 94043 3988 USA 3989 electronic mail: anup@netscape.com 3991 Robert Lanphier 3992 RealNetworks 3993 1111 Third Avenue Suite 2900 3994 Seattle, WA 98101 3995 USA 3996 electronic mail: robla@prognet.com 3998 Appendix F: Acknowledgements 4000 This draft is based on the functionality of the original RTSP draft 4001 submitted in October 96. It also borrows format and descriptions from 4002 HTTP/1.1. 4004 This document has benefited greatly from the comments of all those 4005 participating in the MMUSIC-WG. In addition to those already 4006 mentioned, the following individuals have contributed to this 4007 specification: 4009 Rahul Agarwal, Torsten Braun, Brent Browning, Bruce Butterfield, Ema 4010 Patki, Steve Casner, Francisco Cortes, Kelly Djahandari, Martin 4011 Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Guruprasad, 4012 Peter Haight, Mark Handley, Brad Hefta-Gaub, John K. Ho, Philipp 4013 Hoschka, Anne Jones, Anders Klemets, Ruth Lang, Stephanie Leif, 4014 Jonathan Lennox, Eduardo F. Llach, Rob McCool, David Oran, Maria 4015 Papadopouli, Sujal Patel, Alagu Periyannan, Igor Plotnikov, Pinaki 4016 Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen, and 4017 John Francis Stracke. 4019 References 4021 1 H. Schulzrinne, ``RTP profile for audio and video conferences 4022 with minimal control,'' RFC 1890, Internet Engineering Task 4023 Force, Jan. 1996. 4025 2 R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. 4026 Berners-Lee, ``Hypertext transfer protocol - HTTP/1.1,'' RFC 4027 2068, Internet Engineering Task Force, Jan. 1997. 4029 3 F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 4030 ``Internationalization of the hypertext markup language,'' RFC 4031 2070, Internet Engineering Task Force, Jan. 1997. 4033 4 S. Bradner, ``Key words for use in RFCs to indicate requirement 4034 levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. 4036 5 ISO/IEC, ``Information technology - generic coding of moving 4037 pictures and associated audio informaiton - part 6: extension 4038 for digital storage media and control,'' Draft International 4039 Standard ISO 13818-6, International Organization for 4040 Standardization ISO/IEC JTC1/SC29/WG11, Geneva, Switzerland, 4041 Nov. 1995. 4043 6 M. Handley and V. Jacobson, ``SDP: Session description 4044 protocol,'' Request for Comments XXXX, Internet Engineering 4045 Task Force, Feb. 1998. 4047 7 A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' 4048 Request for Comments XXXX, Internet Engineering Task Force, 4049 Feb. 1998. 4051 8 J. Franks, P. Hallam-Baker, and J. Hostetler, ``An extension to 4052 HTTP: digest access authentication,'' RFC 2069, Internet 4053 Engineering Task Force, Jan. 1997. 4055 9 J. Postel, ``User datagram protocol,'' RFC STD 6, 768, Internet 4056 Engineering Task Force, Aug. 1980. 4058 10 B. Hinden and C. Partridge, ``Version 2 of the reliable data 4059 protocol (RDP),'' RFC 1151, Internet Engineering Task Force, 4060 Apr. 1990. 4062 11 J. Postel, ``Transmission control protocol,'' RFC STD 7, 793, 4063 Internet Engineering Task Force, Sept. 1981. 4065 12 H. Schulzrinne, ``A comprehensive multimedia control 4066 architecture for the Internet,'' in Proc. International 4067 Workshop on Network and Operating System Support for Digital 4068 Audio and Video (NOSSDAV), (St. Louis, Missouri), May 1997. 4070 13 International Telecommunication Union, ``Visual telephone 4071 systems and equipment for local area networks which provide a 4072 non-guaranteed quality of service,'' Recommendation H.323, 4073 Telecommunication Standardization Sector of ITU, Geneva, 4074 Switzerland, May 1996. 4076 14 P. McMahon, ``GSS-API authentication method for SOCKS version 4077 5,'' RFC 1961, Internet Engineering Task Force, June 1996. 4079 15 J. Miller, P. Resnick, and D. Singer, ``Rating services and 4080 rating systems (and their machine readable descriptions),'' 4081 Recommendation REC-PICS-services-961031, W3C (World Wide Web 4082 Consortium), Boston, Massachusetts, Oct. 1996. 4084 16 J. Miller, T. Krauskopf, P. Resnick, and W. Treese, ``PICS 4085 label distribution label syntax and communication protocols,'' 4086 Recommendation REC-PICS-labels-961031, W3C (World Wide Web 4087 Consortium), Boston, Massachusetts, Oct. 1996. 4089 17 D. Crocker and P. Overell, ``Augmented BNF for syntax 4090 specifications: ABNF,'' RFC 2234, Internet Engineering Task 4091 Force, Nov. 1997. 4093 18 B. Braden, ``Requirements for internet hosts - application and 4094 support,'' RFC STD 3, 1123, Internet Engineering Task Force, 4095 Oct. 1989. 4097 19 R. Elz, ``A compact representation of IPv6 addresses,'' RFC 4098 1924, Internet Engineering Task Force, Apr. 1996. 4100 20 T. Berners-Lee, L. Masinter, and M. McCahill, ``Uniform 4101 resource locators (URL),'' RFC 1738, Internet Engineering Task 4102 Force, Dec. 1994. 4104 21 F. Yergeau, ``Utf-8, a transformation format of iso 10646,'' 4105 Request for Comments XXXX, Internet Engineering Task Force, 4106 Jan. 1998. 4108 22 B. Braden, ``T/TCP - TCP extensions for transactions functional 4109 specification,'' RFC 1644, Internet Engineering Task Force, 4110 July 1994. 4112 23 W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 4113 Reading, Massachusetts: Addison-Wesley, 1994. 4115 24 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 4116 ``RTP: a transport protocol for real-time applications,'' RFC 4117 1889, Internet Engineering Task Force, Jan. 1996. 4119 25 R. Fielding, ``Relative uniform resource locators,'' RFC 1808, 4120 Internet Engineering Task Force, June 1995. 4122 Full Copyright Statement 4124 Copyright (C) The Internet Society (1997). All Rights Reserved. 4126 This document and translations of it may be copied and furnished to 4127 others, and derivative works that comment on or otherwise explain it 4128 or assist in its implmentation may be prepared, copied, published and 4129 distributed, in whole or in part, without restriction of any kind, 4130 provided that the above copyright notice and this paragraph are 4131 included on all such copies and derivative works. However, this 4132 document itself may not be modified in any way, such as by removing 4133 the copyright notice or references to the Internet Society or other 4134 Internet organizations, except as needed for the purpose of developing 4135 Internet standards in which case the procedures for copyrights defined 4136 in the Internet Standards process must be followed, or as required to 4137 translate it into languages other than English. 4139 The limited permissions granted above are perpetual and will not be 4140 revoked by the Internet Society or its successors or assigns. 4142 This document and the information contained herein is provided on an 4143 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4144 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 4145 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 4146 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4147 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.