idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 26) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 85 instances of too long lines in the document, the longest one being 71 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 532 has weird spacing: '... scheme rtsp ...' == Line 533 has weird spacing: '... scheme rtspu...' == Line 536 has weird spacing: '... If the port ...' == Line 539 has weird spacing: '...on that port ...' == Line 540 has weird spacing: '...urce is rtsp_...' == (31 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Name and description of option. The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST not contain any spaces, control characters or periods. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Notes on Table 2: PAUSE is recommended, but not required in that a fully functional server can be built that does not support this method, for example, for live feeds. If a server does not support a particular method, it MUST return 501 (Not Implemented) and a client SHOULD not try this method again for this server. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications [H10.4.1]. If the request does not have a CSeq header, the server MUST not include a CSeq in the response. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2002) is 8092 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 4077 looks like a reference -- Missing reference section? '2' on line 4081 looks like a reference -- Missing reference section? '3' on line 4085 looks like a reference -- Missing reference section? '4' on line 4089 looks like a reference -- Missing reference section? '5' on line 4093 looks like a reference -- Missing reference section? '6' on line 4099 looks like a reference -- Missing reference section? '7' on line 4103 looks like a reference -- Missing reference section? '8' on line 4106 looks like a reference -- Missing reference section? '9' on line 4111 looks like a reference -- Missing reference section? '10' on line 4114 looks like a reference -- Missing reference section? '11' on line 4118 looks like a reference -- Missing reference section? '12' on line 4121 looks like a reference -- Missing reference section? '13' on line 4125 looks like a reference -- Missing reference section? '14' on line 4130 looks like a reference -- Missing reference section? '15' on line 4134 looks like a reference -- Missing reference section? '16' on line 4139 looks like a reference -- Missing reference section? '17' on line 4144 looks like a reference -- Missing reference section? '19' on line 4152 looks like a reference -- Missing reference section? '20' on line 4155 looks like a reference -- Missing reference section? '22' on line 4164 looks like a reference -- Missing reference section? 'H6' on line 891 looks like a reference -- Missing reference section? '18' on line 4148 looks like a reference -- Missing reference section? '23' on line 4168 looks like a reference -- Missing reference section? '24' on line 4172 looks like a reference -- Missing reference section? 'H10' on line 1757 looks like a reference -- Missing reference section? '25' on line 4175 looks like a reference -- Missing reference section? '26' on line 4179 looks like a reference -- Missing reference section? '27' on line 4183 looks like a reference -- Missing reference section? 'CRLF' on line 3270 looks like a reference -- Missing reference section? 'H15' on line 3303 looks like a reference -- Missing reference section? '28' on line 4187 looks like a reference -- Missing reference section? '21' on line 4159 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 A. Rao 6 Cisco 7 R. Lanphier 8 RealNetworks 9 draft-ietf-mmusic-rfc2326bis-00.txt 10 February 22, 2002 11 Expires: July 2002 13 Real Time Streaming Protocol (RTSP) 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This memorandum is a revision of RFC 2326, which is currently a 39 Proposed Standard. 41 The Real Time Streaming Protocol, or RTSP, is an application-level 42 protocol for control over the delivery of data with real-time 43 properties. RTSP provides an extensible framework to enable 44 controlled, on-demand delivery of real-time data, such as audio and 45 video. Sources of data can include both live data feeds and stored 46 clips. This protocol is intended to control multiple data delivery 47 sessions, provide a means for choosing delivery channels such as UDP, 48 multicast UDP and TCP, and provide a means for choosing delivery 49 mechanisms based upon RTP (RFC 1889). 51 1 Introduction 53 1.1 Purpose 55 The Real-Time Streaming Protocol (RTSP) establishes and controls 56 either a single or several time-synchronized streams of continuous 57 media such as audio and video. It does not typically deliver the 58 continuous streams itself, although interleaving of the continuous 59 media stream with the control stream is possible (see Section 10.12). 60 In other words, RTSP acts as a "network remote control" for 61 multimedia servers. 63 The set of streams to be controlled is defined by a presentation 64 description. This memorandum does not define a format for a 65 presentation description. 67 There is no notion of an RTSP connection; instead, a server maintains 68 a session labeled by an identifier. An RTSP session is in no way tied 69 to a transport-level connection such as a TCP connection. During an 70 RTSP session, an RTSP client may open and close many reliable 71 transport connections to the server to issue RTSP requests. 72 Alternatively, it may use a connectionless transport protocol such as 73 UDP. 75 The streams controlled by RTSP may use RTP [1], but the operation of 76 RTSP does not depend on the transport mechanism used to carry 77 continuous media. 79 The protocol is intentionally similar in syntax and operation to 80 HTTP/1.1 [2] so that extension mechanisms to HTTP can in most cases 81 also be added to RTSP. However, RTSP differs in a number of important 82 aspects from HTTP: 84 o RTSP introduces a number of new methods and has a different 85 protocol identifier. 87 o An RTSP server needs to maintain state by default in almost 88 all cases, as opposed to the stateless nature of HTTP. 90 o Both an RTSP server and client can issue requests. 92 o Data is carried out-of-band by a different protocol. (There is 93 an exception to this.) 95 o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 96 8859-1, consistent with current HTML internationalization 97 efforts [3]. 99 o The Request-URI always contains the absolute URI. Because of 100 backward compatibility with a historical blunder, HTTP/1.1 [2] 101 carries only the absolute path in the request and puts the 102 host name in a separate header field. 104 This makes "virtual hosting" easier, where a single 105 host with one IP address hosts several document trees. 107 The protocol supports the following operations: 109 Retrieval of media from media server: The client can request a 110 presentation description via HTTP or some other method. If 111 the presentation is being multicast, the presentation 112 description contains the multicast addresses and ports to 113 be used for the continuous media. If the presentation is 114 to be sent only to the client via unicast, the client 115 provides the destination for security reasons. 117 Invitation of a media server to a conference: A media server can 118 be "invited" to join an existing conference, either to play 119 back media into the presentation or to record all or a 120 subset of the media in a presentation. This mode is useful 121 for distributed teaching applications. Several parties in 122 the conference may take turns "pushing the remote control 123 buttons". 125 Addition of media to an existing presentation: Particularly for 126 live presentations, it is useful if the server can tell the 127 client about additional media becoming available. 129 RTSP requests may be handled by proxies, tunnels and caches as in 130 HTTP/1.1 [2]. 132 1.2 Requirements 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [4]. 138 1.3 Terminology 140 Some of the terminology has been adopted from HTTP/1.1 [2]. Terms 141 not listed here are defined as in HTTP/1.1. 143 Aggregate control: The control of the multiple streams using a 144 single timeline by the server. For audio/video feeds, this 145 means that the client may issue a single play or pause 146 message to control both the audio and video feeds. 148 Conference: a multiparty, multimedia presentation, where "multi" 149 implies greater than or equal to one. 151 Client: The client requests continuous media data from the media 152 server. 154 Connection: A transport layer virtual circuit established 155 between two programs for the purpose of communication. 157 Container file: A file which may contain multiple media streams 158 which often comprise a presentation when played together. 159 RTSP servers may offer aggregate control on these files, 160 though the concept of a container file is not embedded in 161 the protocol. 163 Continuous media: Data where there is a timing relationship 164 between source and sink; that is, the sink must reproduce 165 the timing relationship that existed at the source. The 166 most common examples of continuous media are audio and 167 motion video. Continuous media can be real-time 168 (interactive) , where there is a "tight" timing 169 relationship between source and sink, or streaming 170 (playback) , where the relationship is less strict. 172 Entity: The information transferred as the payload of a request 173 or response. An entity consists of metainformation in the 174 form of entity-header fields and content in the form of an 175 entity-body, as described in Section 8. 177 Media initialization: Datatype/codec specific initialization. 178 This includes such things as clockrates, color tables, etc. 179 Any transport-independent information which is required by 180 a client for playback of a media stream occurs in the media 181 initialization phase of stream setup. 183 Media parameter: Parameter specific to a media type that may be 184 changed before or during stream playback. 186 Media server: The server providing playback or recording 187 services for one or more media streams. Different media 188 streams within a presentation may originate from different 189 media servers. A media server may reside on the same or a 190 different host as the web server the presentation is 191 invoked from. 193 Media server indirection: Redirection of a media client to a 194 different media server. 196 (Media) stream: A single media instance, e.g., an audio stream 197 or a video stream as well as a single whiteboard or shared 198 application group. When using RTP, a stream consists of all 199 RTP and RTCP packets created by a source within an RTP 200 session. This is equivalent to the definition of a DSM-CC 201 stream([5]). 203 Message: The basic unit of RTSP communication, consisting of a 204 structured sequence of octets matching the syntax defined 205 in Section 15 and transmitted via a connection or a 206 connectionless protocol. 208 Participant: Member of a conference. A participant may be a 209 machine, e.g., a media record or playback server. 211 Presentation: A set of one or more streams presented to the 212 client as a complete media feed, using a presentation 213 description as defined below. In most cases in the RTSP 214 context, this implies aggregate control of those streams, 215 but does not have to. 217 Presentation description: A presentation description contains 218 information about one or more media streams within a 219 presentation, such as the set of encodings, network 220 addresses and information about the content. Other IETF 221 protocols such as SDP (RFC 2327 [6]) use the term "session" 222 for a live presentation. The presentation description may 223 take several different formats, including but not limited 224 to the session description format SDP. 226 Response: An RTSP response. If an HTTP response is meant, that 227 is indicated explicitly. 229 Request: An RTSP request. If an HTTP request is meant, that is 230 indicated explicitly. 232 RTSP session: A complete RTSP "transaction", e.g., the viewing 233 of a movie. A session typically consists of a client 234 setting up a transport mechanism for the continuous media 235 stream ( SETUP), starting the stream with PLAY or RECORD, 236 and closing the stream with TEARDOWN. 238 Transport initialization: The negotiation of transport 239 information (e.g., port numbers, transport protocols) 240 between the client and the server. 242 1.4 Protocol Properties 244 RTSP has the following properties: 246 Extendable: New methods and parameters can be easily added to 247 RTSP. 249 Easy to parse: RTSP can be parsed by standard HTTP or MIME 250 parsers. 252 Secure: RTSP re-uses web security mechanisms, either at the 253 transport level (TLS, RFC 2246 [7]) or within the protocol 254 itself. All HTTP authentication mechanisms such as basic 255 (RFC 2068 [2]) and digest authentication (RFC 2069 [8]) are 256 directly applicable. 258 Transport-independent: RTSP may use either an unreliable 259 datagram protocol (UDP) (RFC 768 [9]), a reliable datagram 260 protocol (RDP, RFC 1151, not widely used [10]) or a 261 reliable stream protocol such as TCP (RFC 793 [11]) as it 262 implements application-level reliability. 264 Multi-server capable: Each media stream within a presentation 265 can reside on a different server. The client automatically 266 establishes several concurrent control sessions with the 267 different media servers. Media synchronization is 268 performed at the transport level. 270 Control of recording devices: The protocol can control both 271 recording and playback devices, as well as devices that can 272 alternate between the two modes ("VCR"). 274 Separation of stream control and conference initiation: Stream 275 control is divorced from inviting a media server to a 276 conference. The only requirement is that the conference 277 initiation protocol either provides or can be used to 278 create a unique conference identifier. In particular, SIP 279 [12] or H.323 [13] may be used to invite a server to a 280 conference. 282 Suitable for professional applications: RTSP supports frame- 283 level accuracy through SMPTE time stamps to allow remote 284 digital editing. 286 Presentation description neutral: The protocol does not impose a 287 particular presentation description or metafile format and 288 can convey the type of format to be used. However, the 289 presentation description must contain at least one RTSP 290 URI. 292 Proxy and firewall friendly: The protocol should be readily 293 handled by both application and transport-layer (SOCKS 294 [14]) firewalls. A firewall may need to understand the 295 SETUP method to open a "hole" for the UDP media stream. 297 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so 298 that the existing infrastructure can be reused. This 299 infrastructure includes PICS (Platform for Internet Content 300 Selection [15,16]) for associating labels with content. 301 However, RTSP does not just add methods to HTTP since the 302 controlling continuous media requires server state in most 303 cases. 305 Appropriate server control: If a client can start a stream, it 306 must be able to stop a stream. Servers should not start 307 streaming to clients in such a way that clients cannot stop 308 the stream. 310 Transport negotiation: The client can negotiate the transport 311 method prior to actually needing to process a continuous 312 media stream. 314 Capability negotiation: If basic features are disabled, there 315 must be some clean mechanism for the client to determine 316 which methods are not going to be implemented. This allows 317 clients to present the appropriate user interface. For 318 example, if seeking is not allowed, the user interface must 319 be able to disallow moving a sliding position indicator. 321 An earlier requirement in RTSP was multi-client capability. 322 However, it was determined that a better approach was to 323 make sure that the protocol is easily extensible to the 324 multi-client scenario. Stream identifiers can be used by 325 several control streams, so that "passing the remote" would 326 be possible. The protocol would not address how several 327 clients negotiate access; this is left to either a "social 328 protocol" or some other floor control mechanism. 330 1.5 Extending RTSP 332 Since not all media servers have the same functionality, media 333 servers by necessity will support different sets of requests. For 334 example: 336 o A server may only be capable of playback thus has no need to 337 support the RECORD request. 339 o A server may not be capable of seeking (absolute positioning) 340 if it is to support live events only. 342 o Some servers may not support setting stream parameters and 343 thus not support GET_PARAMETER and SET_PARAMETER. 345 A server SHOULD implement all header fields described in Section 12. 347 It is up to the creators of presentation descriptions not to ask the 348 impossible of a server. This situation is similar in HTTP/1.1 [2], 349 where the methods described in [H19.6] are not likely to be supported 350 across all servers. 352 RTSP can be extended in three ways, listed here in order of the 353 magnitude of changes supported: 355 o Existing methods can be extended with new parameters, as long 356 as these parameters can be safely ignored by the recipient. 357 (This is equivalent to adding new parameters to an HTML tag.) 358 If the client needs negative acknowledgement when a method 359 extension is not supported, a tag corresponding to the 360 extension may be added in the Require: field (see Section 361 12.33). 363 o New methods can be added. If the recipient of the message does 364 not understand the request, it responds with error code 501 365 (Not Implemented) and the sender should not attempt to use 366 this method again. A client may also use the OPTIONS method 367 to inquire about methods supported by the server. The server 368 SHOULD list the methods it supports using the Public response 369 header. 371 o A new version of the protocol can be defined, allowing almost 372 all aspects (except the position of the protocol version 373 number) to change. 375 1.6 Overall Operation 377 Each presentation and media stream may be identified by an RTSP URL. 378 The overall presentation and the properties of the media the 379 presentation is made up of are defined by a presentation description 380 file, the format of which is outside the scope of this specification. 381 The presentation description file may be obtained by the client using 382 HTTP or other means such as email and may not necessarily be stored 383 on the media server. 385 For the purposes of this specification, a presentation description is 386 assumed to describe one or more presentations, each of which 387 maintains a common time axis. For simplicity of exposition and 388 without loss of generality, it is assumed that the presentation 389 description contains exactly one such presentation. A presentation 390 may contain several media streams. 392 The presentation description file contains a description of the media 393 streams making up the presentation, including their encodings, 394 language, and other parameters that enable the client to choose the 395 most appropriate combination of media. In this presentation 396 description, each media stream that is individually controllable by 397 RTSP is identified by an RTSP URL, which points to the media server 398 handling that particular media stream and names the stream stored on 399 that server. Several media streams can be located on different 400 servers; for example, audio and video streams can be split across 401 servers for load sharing. The description also enumerates which 402 transport methods the server is capable of. 404 Besides the media parameters, the network destination address and 405 port need to be determined. Several modes of operation can be 406 distinguished: 408 Unicast: The media is transmitted to the source of the RTSP 409 request, with the port number chosen by the client. 410 Alternatively, the media is transmitted on the same 411 reliable stream as RTSP. 413 Multicast, server chooses address: The media server picks the 414 multicast address and port. This is the typical case for a 415 live or near-media-on-demand transmission. 417 Multicast, client chooses address: If the server is to 418 participate in an existing multicast conference, the 419 multicast address, port and encryption key are given by the 420 conference description, established by means outside the 421 scope of this specification. 423 1.7 RTSP States 425 RTSP controls a stream which may be sent via a separate protocol, 426 independent of the control channel. For example, RTSP control may 427 occur on a TCP connection while the data flows via UDP. Thus, data 428 delivery continues even if no RTSP requests are received by the media 429 server. Also, during its lifetime, a single media stream may be 430 controlled by RTSP requests issued sequentially on different TCP 431 connections. Therefore, the server needs to maintain "session state" 432 to be able to correlate RTSP requests with a stream. The state 433 transitions are described in Section A. 435 Many methods in RTSP do not contribute to state. However, the 436 following play a central role in defining the allocation and usage of 437 stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and 438 TEARDOWN. 440 SETUP: Causes the server to allocate resources for a stream and 441 start an RTSP session. 443 PLAY and RECORD: Starts data transmission on a stream allocated 444 via SETUP. 446 PAUSE: Temporarily halts a stream without freeing server 447 resources. 449 TEARDOWN: Frees resources associated with the stream. The RTSP 450 session ceases to exist on the server. 452 RTSP methods that contribute to state use the Session 453 header field (Section 12.38) to identify the RTSP session 454 whose state is being manipulated. The server generates 455 session identifiers in response to SETUP requests (Section 456 10.4). 458 1.8 Relationship with Other Protocols 460 RTSP has some overlap in functionality with HTTP. It also may 461 interact with HTTP in that the initial contact with streaming content 462 is often to be made through a web page. The current protocol 463 specification aims to allow different hand-off points between a web 464 server and the media server implementing RTSP. For example, the 465 presentation description can be retrieved using HTTP or RTSP, which 466 reduces roundtrips in web-browser-based scenarios, yet also allows 467 for standalone RTSP servers and clients which do not rely on HTTP at 468 all. 470 However, RTSP differs fundamentally from HTTP in that data delivery 471 takes place out-of-band in a different protocol. HTTP is an 472 asymmetric protocol where the client issues requests and the server 473 responds. In RTSP, both the media client and media server can issue 474 requests. RTSP requests are also not stateless; they may set 475 parameters and continue to control a media stream long after the 476 request has been acknowledged. 478 Re-using HTTP functionality has advantages in at least two 479 areas, namely security and proxies. The requirements are 480 very similar, so having the ability to adopt HTTP work on 481 caches, proxies and authentication is valuable. 483 While most real-time media will use RTP as a transport protocol, RTSP 484 is not tied to RTP. 486 RTSP assumes the existence of a presentation description format that 487 can express both static and temporal properties of a presentation 488 containing several media streams. 490 2 Notational Conventions 492 Since many of the definitions and syntax are identical to HTTP/1.1, 493 this specification only points to the section where they are defined 494 rather than copying it. For brevity, [HX.Y] is to be taken to refer 495 to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [2]). 497 All the mechanisms specified in this document are described in both 498 prose and an augmented Backus-Naur form (BNF) similar to that used in 499 [H2.1]. It is described in detail in RFC 2234 [17], with the 500 difference that this RTSP specification maintains the "1#" notation 501 for comma-separated lists. 503 In this draft, we use indented and smaller-type paragraphs to provide 504 background and motivation. This is intended to give readers who were 505 not involved with the formulation of the specification an 506 understanding of why things are the way that they are in RTSP. 508 3 Protocol Parameters 510 3.1 RTSP Version 512 applies, with HTTP replaced by RTSP. 514 3.2 RTSP URL 516 The "rtsp" and "rtspu" schemes are used to refer to network resources 517 via the RTSP protocol. This section defines the scheme-specific 518 syntax and semantics for RTSP URLs. 520 rtsp_URL _ ( "rtsp:" | "rtspu:" ) 521 "//" host [ ":" port ] [ abs_path ] 522 host _ 525 port _ *DIGIT 526 abs_path is defined in [H3.2.1]. 528 Note that fragment and query identifiers do not have a 529 well-defined meaning at this time, with the interpretation 530 left to the RTSP server. 532 The scheme rtsp requires that commands are issued via a reliable 533 protocol (within the Internet, TCP), while the scheme rtspu 534 identifies an unreliable protocol (within the Internet, UDP). 536 If the port is empty or not given, port 554 is assumed. The 537 semantics are that the identified resource can be controlled by RTSP 538 at the server listening for TCP (scheme "rtsp") connections or UDP 539 (scheme "rtspu") packets on that port of host, and the Request-URI 540 for the resource is rtsp_URL. 542 The use of IP addresses in URLs SHOULD be avoided whenever possible 543 (see RFC 1924 [19]). 545 A presentation or a stream is identified by a textual media 546 identifier, using the character set and escape conventions [H3.2] of 547 URLs (RFC 1738 [20]). URLs may refer to a stream or an aggregate of 548 streams, i.e., a presentation. Accordingly, requests described in 549 Section 10 can apply to either the whole presentation or an 550 individual stream within the presentation. Note that some request 551 methods can only be applied to streams, not presentations and vice 552 versa. 554 For example, the RTSP URL: 556 rtsp://media.example.com:554/twister/audiotrack 558 identifies the audio stream within the presentation "twister", which 559 can be controlled via RTSP requests issued over a TCP connection to 560 port 554 of host media.example.com 562 Also, the RTSP URL: 564 rtsp://media.example.com:554/twister 566 identifies the presentation "twister", which may be composed of audio 567 and video streams. 569 This does not imply a standard way to reference streams in 570 URLs. The presentation description defines the hierarchical 571 relationships in the presentation and the URLs for the 572 individual streams. A presentation description may name a 573 stream "a.mov" and the whole presentation "b.mov". 575 The path components of the RTSP URL are opaque to the client and do 576 not imply any particular file system structure for the server. 578 This decoupling also allows presentation descriptions to be 579 used with non-RTSP media control protocols simply by 580 replacing the scheme in the URL. 582 3.3 Conference Identifiers 584 Conference identifiers are opaque to RTSP and are encoded using 585 standard URI encoding methods (i.e., LWS is escaped with %). They can 586 contain any octet value. The conference identifier MUST be globally 587 unique. For H.323, the conferenceID value is to be used. 589 conference-id _ 1*xchar 591 Conference identifiers are used to allow RTSP sessions to 592 obtain parameters from multimedia conferences the media 593 server is participating in. These conferences are created 594 by protocols outside the scope of this specification, e.g., 595 H.323 [13] or SIP [12]. Instead of the RTSP client 596 explicitly providing transport information, for example, it 597 asks the media server to use the values in the conference 598 description instead. 600 3.4 Session Identifiers 602 Session identifiers are opaque strings of arbitrary length. Linear 603 white space must be URL-escaped. A session identifier MUST be chosen 604 randomly and MUST be at least eight octets long to make guessing it 605 more difficult. (See Section 16.) 607 session-id _ 8*( ALPHA | DIGIT | safe ) 609 3.5 SMPTE Relative Timestamps 611 A SMPTE relative timestamp expresses time relative to the start of 612 the clip. Relative timestamps are expressed as SMPTE time codes for 613 frame-level access accuracy. The time code has the format 614 hours:minutes:seconds:frames.subframes 615 , 616 with the origin at the start of the clip. The default smpte format 617 is"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 618 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 619 use of alternative use of "smpte time". For the "frames" field in the 620 time value can assume the values 0 through 29. The difference between 621 30 and 29.97 frames per second is handled by dropping the first two 622 frame indices (values 00 and 01) of every minute, except every tenth 623 minute. If the frame value is zero, it may be omitted. Subframes are 624 measured in one-hundredth of a frame. 626 smpte-range _ smpte-type "=" smpte-range-spec 627 smpte-range-spec _ ( smpte-time "-" [ smpte-time ] ) | ( "-" smpte-time ) 628 smpte-type _ "smpte" | "smpte-30-drop" | "smpte-25" 629 ; other timecodes may be added 630 smpte-time _ 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 631 [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ] 633 Examples: 635 smpte=10:12:33:20- 636 smpte=10:07:33- 637 smpte=10:07:00-10:07:33:05.01 638 smpte-25=10:07:00-10:07:33:05.01 640 3.6 Normal Play Time 642 Normal play time (NPT) indicates the stream absolute position 643 relative to the beginning of the presentation. The timestamp consists 644 of a decimal fraction. The part left of the decimal may be expressed 645 in either seconds or hours, minutes, and seconds. The part right of 646 the decimal point measures fractions of a second. 648 The beginning of a presentation corresponds to 0.0 seconds. Negative 649 values are not defined. The special constant now is defined as the 650 current instant of a live event. It may be used only for live events. 652 NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the 653 viewer associates with a program. It is often digitally displayed on 654 a VCR. NPT advances normally when in normal play mode (scale = 1), 655 advances at a faster rate when in fast scan forward (high positive 656 scale ratio), decrements when in scan reverse (high negative scale 657 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 658 SMPTE time codes." [5] 660 npt-range _ ["npt" "="] npt-range-spec 661 ; implementations SHOULD use npt= prefix, but SHOULD 662 ; be prepared to interoperate with RFC 2326 663 ; implementations which don't use it 664 npt-range-spec _ ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) 665 npt-time _ "now" | npt-sec | npt-hhmmss 666 npt-sec _ 1*DIGIT [ "." *DIGIT ] 667 npt-hhmmss _ npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 668 npt-hh _ 1*DIGIT ; any positive number 669 npt-mm _ 1*2DIGIT ; 0-59 670 npt-ss _ 1*2DIGIT ; 0-59 672 Examples: 674 npt=123.45-125 675 npt=12:05:35.3- 676 npt=now- 678 The syntax conforms to ISO 8601. The npt-sec notation is 679 optimized for automatic generation, the ntp-hhmmss notation 680 for consumption by human readers. The "now" constant allows 681 clients to request to receive the live feed rather than the 682 stored or time-delayed version. This is needed since 683 neither absolute time nor zero time are appropriate for 684 this case. 686 3.7 Absolute Time 688 Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT). 689 Fractions of a second may be indicated. 691 utc-range _ "clock" "=" utc-time "-" [ utc-time ] 692 utc-time _ utc-date "T" utc-time "Z" 693 utc-date _ 8DIGIT ; < YYYYMMDD > 694 utc-time _ 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > 696 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 697 UTC: 699 19961108T143720.25Z 701 3.8 Option Tags 703 Option tags are unique identifiers used to designate new options in 704 RTSP. These tags are used in in Require (Section 12.33) and Proxy- 705 Require (Section 12.28) header fields. 707 Syntax: 709 option-tag _ token 711 The creator of a new RTSP option should either prefix the option with 712 a reverse domain name (e.g., "com.foo.mynewfeature" is an apt name 713 for a feature whose inventor can be reached at "foo.com"), or 714 register the new option with the Internet Assigned Numbers Authority 715 (IANA). 717 3.8.1 Registering New Option Tags with IANA 719 When registering a new RTSP option, the following information should 720 be provided: 722 o Name and description of option. The name may be of any length, 723 but SHOULD be no more than twenty characters long. The name 724 MUST not contain any spaces, control characters or periods. 726 o Indication of who has change control over the option (for 727 example, IETF, ISO, ITU-T, other international standardization 728 bodies, a consortium or a particular company or group of 729 companies); 731 o A reference to a further description, if available, for 732 example (in order of preference) an RFC, a published paper, a 733 patent filing, a technical report, documented source code or a 734 computer manual; 736 o For proprietary options, contact information (postal and email 737 address); 739 4 RTSP Message 741 RTSP is a text-based protocol and uses the ISO 10646 character set in 742 UTF-8 encoding (RFC 2279 [22]). Lines are terminated by CRLF, but 743 receivers should be prepared to also interpret CR and LF by 744 themselves as line terminators. 746 Text-based protocols make it easier to add optional 747 parameters in a self-describing manner. Since the number of 748 parameters and the frequency of commands is low, processing 749 efficiency is not a concern. Text-based protocols, if done 750 carefully, also allow easy implementation of research 751 prototypes in scripting languages such as Tcl, Visual Basic 752 and Perl. 754 The 10646 character set avoids tricky character set switching, but is 755 invisible to the application as long as US-ASCII is being used. This 756 is also the encoding used for RTCP. ISO 8859-1 translates directly 757 into Unicode with a high-order octet of zero. ISO 8859-1 characters 758 with the most-significant bit set are represented as 1100001x 759 10xxxxxx. (See RFC 2279 [22]) 761 RTSP messages can be carried over any lower-layer transport protocol 762 that is 8-bit clean. 764 Requests contain methods, the object the method is operating upon and 765 parameters to further describe the method. Methods are idempotent, 766 unless otherwise noted. Methods are also designed to require little 767 or no state maintenance at the media server. 769 4.1 Message Types 771 See [H4.1] 773 4.2 Message Headers 775 See [H4.2] 777 4.3 Message Body 779 See [H4.3] 781 4.4 Message Length 783 When a message body is included with a message, the length of that 784 body is determined by one of the following (in order of precedence): 786 1. Any response message which MUST NOT include a message body 787 (such as the 1xx, 204, and 304 responses) is always 788 terminated by the first empty line after the header fields, 789 regardless of the entity-header fields present in the 790 message. (Note: An empty line consists of only CRLF.) 792 2. If a Content-Length header field (section 12.15) is 793 present, its value in bytes represents the length of the 794 message-body. If this header field is not present, a value 795 of zero is assumed. 797 Note that RTSP does not (at present) support the HTTP/1.1 "chunked" 798 transfer coding(see [H3.6]) and requires the presence of the 799 Content-Length header field. 801 Given the moderate length of presentation descriptions 802 returned, the server should always be able to determine its 803 length, even if it is generated dynamically, making the 804 chunked transfer encoding unnecessary. 806 5 General Header Fields 808 See [H4.5], except that Pragma, Transfer-Encoding and Upgrade 809 headers are not defined: 811 general-header = Cache-Control ; Section 12.9 812 | Connection ; Section 12.11 813 | CSeq ; Section 12.18 814 | Date ; Section 12.19 815 | Via ; Section 12.44 817 6 Request 819 A request message from a client to a server or vice versa includes, 820 within the first line of that message, the method to be applied to 821 the resource, the identifier of the resource, and the protocol 822 version in use. 824 Request = Request-Line ; Section 6.1 825 *( general-header ; Section 5 826 | request-header ; Section 6.2 827 | entity-header ) ; Section 8.1 828 CRLF 829 [ message-body ] ; Section 4.3 831 6.1 Request Line 833 Request-Line _ Method SP Request-URI SP RTSP-Version CRLF 834 Method = "DESCRIBE" ; Section 10.2 835 | "ANNOUNCE" ; Section 10.3 836 | "GET_PARAMETER" ; Section 10.8 837 | "OPTIONS" ; Section 10.1 838 | "PAUSE" ; Section 10.6 839 | "PLAY" ; Section 10.5 840 | "RECORD" ; Section 10.11 841 | "REDIRECT" ; Section 10.10 842 | "SETUP" ; Section 10.4 843 | "SET_PARAMETER" ; Section 10.9 844 | "TEARDOWN" ; Section 10.7 845 | extension-method 847 extension-method _ token 848 Request-URI _ "*" | absolute_URI 849 RTSP-Version _ "RTSP" "/" 1*DIGIT "." 1*DIGIT 851 6.2 Request Header Fields 853 request-header = Accept ; Section 12.1 854 | Accept-Encoding ; Section 12.2 855 | Accept-Language ; Section 12.3 856 | Authorization ; Section 12.6 857 | Bandwidth ; Section 12.7 858 | Blocksize ; Section 12.8 859 | Conference ; Section 12.10 860 | From ; Section 12.21 861 | If-Modified-Since ; Section 12.24 862 | Proxy-Require ; Section 12.28 863 | Range ; Section 12.30 864 | Referer ; Section 12.31 865 | Require ; Section 12.33 866 | Scale ; Section 12.35 867 | Session ; Section 12.38 868 | Speed ; Section 12.36 869 | Transport ; Section 12.40 870 | User-Agent ; Section 12.42 872 Note that in contrast to HTTP/1.1 [2], RTSP requests always contain 873 the absolute URL (that is, including the scheme, host and port) 874 rather than just the absolute path. 876 HTTP/1.1 requires servers to understand the absolute URL, 877 but clients are supposed to use the Host request header. 878 This is purely needed for backward-compatibility with 879 HTTP/1.0 servers, a consideration that does not apply to 880 RTSP. 882 The asterisk "*" in the Request-URI means that the request does not 883 apply to a particular resource, but to the server itself, and is only 884 allowed when the method used does not necessarily apply to a 885 resource. One example would be: 887 OPTIONS * RTSP/1.0 889 7 Response 891 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 892 Also, RTSP defines additional status codes and does not define some 893 HTTP codes. The valid response codes and the methods they can be used 894 with are defined in Table 1. 896 After receiving and interpreting a request message, the recipient 897 responds with an RTSP response message. 899 Response = Status-Line ; Section 7.1 900 *( general-header ; Section 5 901 | response-header ; Section 7.1.2 902 | entity-header ) ; Section 8.1 903 CRLF 904 [ message-body ] ; Section 4.3 906 7.1 Status-Line 908 The first line of a Response message is the Status-Line, consisting 909 of the protocol version followed by a numeric status code, and the 910 textual phrase associated with the status code, with each element 911 separated by SP characters. No CR or LF is allowed except in the 912 final CRLF sequence. 914 Status-Line _ RTSP-Version SP Status-Code SP Reason-Phrase CRLF 916 7.1.1 Status Code and Reason Phrase 917 The Status-Code element is a 3-digit integer result code of the 918 attempt to understand and satisfy the request. These codes are fully 919 defined in Section 11. The Reason-Phrase is intended to give a short 920 textual description of the Status-Code. The Status-Code is intended 921 for use by automata and the Reason-Phrase is intended for the human 922 user. The client is not required to examine or display the Reason- 923 Phrase. 925 The first digit of the Status-Code defines the class of response. 926 The last two digits do not have any categorization role. There are 5 927 values for the first digit: 929 o 1xx: Informational - Request received, continuing process 931 o 2xx: Success - The action was successfully received, 932 understood, and accepted 934 o 3xx: Redirection - Further action must be taken in order to 935 complete the request 937 o 4xx: Client Error - The request contains bad syntax or cannot 938 be fulfilled 940 o 5xx: Server Error - The server failed to fulfill an apparently 941 valid request 943 The individual values of the numeric status codes defined for 944 RTSP/1.0, and an example set of corresponding Reason-Phrase's, are 945 presented below. The reason phrases listed here are only recommended 946 -- they may be replaced by local equivalents without affecting the 947 protocol. Note that RTSP adopts most HTTP/1.1 [2] status codes and 948 adds RTSP-specific status codes starting at x50 to avoid conflicts 949 with newly defined HTTP status codes. 951 Status-Code = "100" ; Continue 952 | "200" ; OK 953 | "201" ; Created 954 | "250" ; Low on Storage Space 955 | "300" ; Multiple Choices 956 | "301" ; Moved Permanently 957 | "302" ; Moved Temporarily 958 | "303" ; See Other 959 | "304" ; Not Modified 960 | "305" ; Use Proxy 961 | "400" ; Bad Request 962 | "401" ; Unauthorized 963 | "402" ; Payment Required 964 | "403" ; Forbidden 965 | "404" ; Not Found 966 | "405" ; Method Not Allowed 967 | "406" ; Not Acceptable 968 | "407" ; Proxy Authentication Required 969 | "408" ; Request Time-out 970 | "410" ; Gone 971 | "411" ; Length Required 972 | "412" ; Precondition Failed 973 | "413" ; Request Entity Too Large 974 | "414" ; Request-URI Too Large 975 | "415" ; Unsupported Media Type 976 | "451" ; Parameter Not Understood 977 | "452" ; Conference Not Found 978 | "453" ; Not Enough Bandwidth 979 | "454" ; Session Not Found 980 | "455" ; Method Not Valid in This State 981 | "456" ; Header Field Not Valid for Resource 982 | "457" ; Invalid Range 983 | "458" ; Parameter Is Read-Only 984 | "459" ; Aggregate operation not allowed 985 | "460" ; Only aggregate operation allowed 986 | "461" ; Unsupported transport 987 | "462" ; Destination unreachable 988 | "500" ; Internal Server Error 989 | "501" ; Not Implemented 990 | "502" ; Bad Gateway 991 | "503" ; Service Unavailable 992 | "504" ; Gateway Time-out 993 | "505" ; RTSP Version not supported 994 | "551" ; Option not supported 995 | extension-code 997 extension-code = 3DIGIT 998 Reason-Phrase = * 1000 RTSP status codes are extensible. RTSP applications are not required 1001 to understand the meaning of all registered status codes, though such 1002 understanding is obviously desirable. However, applications MUST 1003 understand the class of any status code, as indicated by the first 1004 digit, and treat any unrecognized response as being equivalent to the 1005 x00 status code of that class, with the exception that an 1006 unrecognized response MUST NOT be cached. For example, if an 1007 unrecognized status code of 431 is received by the client, it can 1008 safely assume that there was something wrong with its request and 1009 treat the response as if it had received a 400 status code. In such 1010 cases, user agents SHOULD present to the user the entity returned 1011 with the response, since that entity is likely to include human- 1012 readable information which will explain the unusual status. 1014 7.1.2 Response Header Fields 1016 The response-header fields allow the request recipient to pass 1017 additional information about the response which cannot be placed in 1018 the Status-Line. These header fields give information about the 1019 server and about further access to the resource identified by the 1020 Request-URI. 1022 response-header = Location ; Section 12.26 1023 | Proxy-Authenticate ; Section 12.27 1024 | Public ; Section 12.29 1025 | Range ; Section 12.30 1026 | Retry-After ; Section 12.32 1027 | RTP-Info ; Section 12.34 1028 | Scale ; Section 12.35 1029 | Session ; Section 12.38 1030 | Server ; Section 12.37 1031 | Speed ; Section 12.36 1032 | Transport ; Section 12.40 1033 | Unsupported ; Section 12.41 1034 | Vary ; Section 12.43 1035 | WWW-Authenticate ; Section 12.45 1037 Response-header field names can be extended reliably only in 1038 combination with a change in the protocol version. However, new or 1039 experimental header fields MAY be given the semantics of response- 1040 header fields if all parties in the communication recognize them to 1041 be response-header fields. Unrecognized header fields are treated as 1042 entity-header fields. 1044 8 Entity 1046 Request and Response messages MAY transfer an entity if not otherwise 1047 restricted by the request method or response status code. An entity 1048 consists of entity-header fields and an entity-body, although some 1049 responses will only include the entity-headers. 1051 In this section, both sender and recipient refer to either the client 1052 or the server, depending on who sends and who receives the entity. 1054 8.1 Entity Header Fields 1056 Entity-header fields define optional metainformation about the 1057 entity-body or, if no body is present, about the resource identified 1058 by the request. 1060 entity-header = Allow ; Section 12.5 1061 | Content-Base ; Section 12.12 1062 | Content-Encoding ; Section 12.13 1063 | Content-Language ; Section 12.14 1064 | Content-Length ; Section 12.15 1065 | Content-Location ; Section 12.16 1066 | Content-Type ; Section 12.17 1067 | Expires ; Section 12.20 1068 | Last-Modified ; Section 12.25 1069 | extension-header 1070 extension-header = message-header 1072 The extension-header mechanism allows additional entity-header fields 1073 to be defined without changing the protocol, but these fields cannot 1074 be assumed to be recognizable by the recipient. Unrecognized header 1075 fields SHOULD be ignored by the recipient and forwarded by proxies. 1077 8.2 Entity Body 1079 See [H7.2] 1081 9 Connections 1083 RTSP requests can be transmitted in several different ways: 1085 o persistent transport connections used for several request- 1086 response transactions; 1088 o one connection per request/response transaction; 1090 o connectionless mode. 1092 The type of transport connection is defined by the RTSP URI (Section 1093 3.2). For the scheme "rtsp", a persistent connection is assumed, 1094 while the scheme "rtspu" calls for RTSP requests to be sent without 1095 setting up a connection. 1097 Unlike HTTP, RTSP allows the media server to send requests to the 1098 media client. However, this is only supported for persistent 1099 connections, as the media server otherwise has no reliable way of 1100 Code reason 1101 _______________________________________________________ 1102 100 Continue all 1104 _______________________________________________________ 1105 200 OK all 1106 201 Created RECORD 1107 250 Low on Storage Space RECORD 1108 _______________________________________________________ 1109 300 Multiple Choices all 1110 301 Moved Permanently all 1111 302 Moved Temporarily all 1112 303 See Other all 1113 305 Use Proxy all 1115 _______________________________________________________ 1116 400 Bad Request all 1117 401 Unauthorized all 1118 402 Payment Required all 1119 403 Forbidden all 1120 404 Not Found all 1121 405 Method Not Allowed all 1122 406 Not Acceptable all 1123 407 Proxy Authentication Required all 1124 408 Request Timeout all 1125 410 Gone all 1126 411 Length Required all 1127 412 Precondition Failed DESCRIBE, SETUP 1128 413 Request Entity Too Large all 1129 414 Request-URI Too Long all 1130 415 Unsupported Media Type all 1131 451 Parameter Not Understood SETUP 1132 452 Illegal Conference Identifier SETUP 1133 453 Not Enough Bandwidth SETUP 1134 454 Session Not Found all 1135 455 Method Not Valid In This State all 1136 456 Header Field Not Valid all 1137 457 Invalid Range PLAY 1138 458 Parameter Is Read-Only SET_PARAMETER 1139 459 Aggregate Operation Not Allowed all 1140 460 Only Aggregate Operation Allowed all 1141 461 Unsupported Transport all 1142 462 Destination Unreachable all 1143 _______________________________________________________ 1144 500 Internal Server Error all 1145 501 Not Implemented all 1146 502 Bad Gateway all 1147 503 Service Unavailable all 1148 504 Gateway Timeout all 1149 505 RTSP Version Not Supported all 1150 551 Option not support all 1152 Table 1: Status codes and their usage with RTSP methods 1153 reaching the client. Also, this is the only way that requests from 1154 media server to client are likely to traverse firewalls. 1156 9.1 Pipelining 1158 A client that supports persistent connections or connectionless mode 1159 MAY "pipeline" its requests (i.e., send multiple requests without 1160 waiting for each response). A server MUST send its responses to those 1161 requests in the same order that the requests were received. 1163 9.2 Reliability and Acknowledgements 1165 Requests are acknowledged by the receiver unless they are sent to a 1166 multicast group. If there is no acknowledgement, the sender may 1167 resend the same message after a timeout of one round-trip time (RTT). 1168 The round-trip time is estimated as in TCP (RFC 1123) [18], with an 1169 initial round-trip value of 500 ms. An implementation MAY cache the 1170 last RTT measurement as the initial value for future connections. 1172 If a reliable transport protocol is used to carry RTSP, requests MUST 1173 NOT be retransmitted; the RTSP application MUST instead rely on the 1174 underlying transport to provide reliability. 1176 If both the underlying reliable transport such as TCP and 1177 the RTSP application retransmit requests, it is possible 1178 that each packet loss results in two retransmissions. The 1179 receiver cannot typically take advantage of the 1180 application-layer retransmission since the transport stack 1181 will not deliver the application-layer retransmission 1182 before the first attempt has reached the receiver. If the 1183 packet loss is caused by congestion, multiple 1184 retransmissions at different layers will exacerbate the 1185 congestion. 1187 If RTSP is used over a small-RTT LAN, standard procedures for 1188 optimizing initial TCP round trip estimates, such as those used in 1189 T/TCP (RFC 1644) [23], can be beneficial. 1191 The Timestamp header (Section 12.39) is used to avoid the 1192 retransmission ambiguity problem [24] and obviates the need for 1193 Karn's algorithm. 1195 Each request carries a sequence number in the CSeq header (Section 1196 12.18), which is incremented by one for each distinct request 1197 transmitted. If a request is repeated because of lack of 1198 acknowledgement, the request MUST carry the original sequence number 1199 (i.e., the sequence number is not incremented). 1201 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1202 support UDP. The default port for the RTSP server is 554 for both UDP 1203 and TCP. 1205 A number of RTSP packets destined for the same control end point may 1206 be packed into a single lower-layer PDU or encapsulated into a TCP 1207 stream. RTSP data MAY be interleaved with RTP and RTCP packets. 1208 Unlike HTTP, an RTSP message MUST contain a Content-Length header 1209 field whenever that message contains a payload. Otherwise, an RTSP 1210 packet is terminated with an empty line immediately following the 1211 last message header. 1213 10 Method Definitions 1215 The method token indicates the method to be performed on the resource 1216 identified by the Request-URI case-sensitive. New methods may be 1217 defined in the future. Method names may not start with a $ character 1218 (decimal 24) and must be a token. Methods are summarized in Table 2. 1220 method direction object requirement 1221 __________________________________________________________________ 1222 DESCRIBE C -> S P,S recommended 1223 ANNOUNCE C -> S, S -> C P,S optional 1224 GET_PARAMETER C -> S, S -> C P,S optional 1225 OPTIONS C -> S, S -> C P,S required (S -> C: optional) 1226 PAUSE C -> S P,S recommended 1227 PLAY C -> S P,S required 1228 RECORD C -> S P,S optional 1229 REDIRECT S -> C P,S optional 1230 SETUP C -> S S required 1231 SET_PARAMETER C -> S, S -> C P,S optional 1232 TEARDOWN C -> S P,S required 1234 Table 2: Overview of RTSP methods, their direction, and what objects 1235 (P: presentation, S: stream) they operate on 1237 Notes on Table 2: PAUSE is recommended, but not required in that a 1238 fully functional server can be built that does not support this 1239 method, for example, for live feeds. If a server does not support a 1240 particular method, it MUST return 501 (Not Implemented) and a client 1241 SHOULD not try this method again for this server. 1243 10.1 OPTIONS 1245 The behavior is equivalent to that described in [H9.2]. An OPTIONS 1246 request may be issued at any time, e.g., if the client is about to 1247 try a nonstandard request. It does not influence server state. 1249 Example: 1251 C->S: OPTIONS * RTSP/1.0 1252 CSeq: 1 1253 Require: implicit-play 1254 Proxy-Require: gzipped-messages 1256 S->C: RTSP/1.0 200 OK 1257 CSeq: 1 1258 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1260 Note that these are necessarily fictional features (one would hope 1261 that we would not purposefully overlook a truly useful feature just 1262 so that we could have a strong example in this section). 1264 10.2 DESCRIBE 1266 The DESCRIBE method retrieves the description of a presentation or 1267 media object identified by the request URL from a server. It may use 1268 the Accept header to specify the description formats that the client 1269 understands. The server responds with a description of the requested 1270 resource. The DESCRIBE reply-response pair constitutes the media 1271 initialization phase of RTSP. 1273 Example: 1275 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 1276 CSeq: 312 1277 Accept: application/sdp, application/rtsl, application/mheg 1279 S->C: RTSP/1.0 200 OK 1280 CSeq: 312 1281 Date: 23 Jan 1997 15:35:06 GMT 1282 Content-Type: application/sdp 1283 Content-Length: 376 1285 v=0 1286 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1287 s=SDP Seminar 1288 i=A Seminar on the session description protocol 1289 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1290 e=mjh@isi.edu (Mark Handley) 1291 c=IN IP4 224.2.17.12/127 1292 t=2873397496 2873404696 1293 a=recvonly 1294 m=audio 3456 RTP/AVP 0 1295 m=video 2232 RTP/AVP 31 1296 m=whiteboard 32416 UDP WB 1297 a=orient:portrait 1299 The DESCRIBE response MUST contain all media initialization 1300 information for the resource(s) that it describes. If a media client 1301 obtains a presentation description from a source other than DESCRIBE 1302 and that description contains a complete set of media initialization 1303 parameters, the client SHOULD use those parameters and not then 1304 request a description for the same media via RTSP. 1306 Additionally, servers SHOULD NOT use the DESCRIBE response as a means 1307 of media indirection. 1309 By forcing a DESCRIBE response to contain all media 1310 initialization for the set of streams that it describes, 1311 and discouraging use of DESCRIBE for media indirection, we 1312 avoid looping problems that might result from other 1313 approaches. 1315 Media initialization is a requirement for any RTSP-based system, but 1316 the RTSP specification does not dictate that this must be done via 1317 the DESCRIBE method. There are three ways that an RTSP client may 1318 receive initialization information: 1320 o via RTSP's DESCRIBE method; 1322 o via some other protocol (HTTP, email attachment, etc.); 1324 o via the command line or standard input (thus working as a 1325 browser helper application launched with an SDP file or other 1326 media initialization format). 1328 It is RECOMMENDED that minimal servers support the DESCRIBE method, 1329 and highly recommended that minimal clients support the ability to 1330 act as a "helper application" that accepts a media initialization 1331 file from standard input, command line, and/or other means that are 1332 appropriate to the operating environment of the client. 1334 10.3 ANNOUNCE 1335 The ANNOUNCE method serves two purposes: 1337 When sent from client to server, ANNOUNCE posts the description of a 1338 presentation or media object identified by the request URL to a 1339 server. When sent from server to client, ANNOUNCE updates the 1340 session description in real-time. 1342 If a new media stream is added to a presentation (e.g., during a live 1343 presentation), the whole presentation description should be sent 1344 again, rather than just the additional components, so that components 1345 can be deleted. 1347 Example: 1349 C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0 1350 CSeq: 312 1351 Date: 23 Jan 1997 15:35:06 GMT 1352 Session: 47112344 1353 Content-Type: application/sdp 1354 Content-Length: 332 1356 v=0 1357 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 1358 s=SDP Seminar 1359 i=A Seminar on the session description protocol 1360 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1361 e=mjh@isi.edu (Mark Handley) 1362 c=IN IP4 224.2.17.12/127 1363 t=2873397496 2873404696 1364 a=recvonly 1365 m=audio 3456 RTP/AVP 0 1366 m=video 2232 RTP/AVP 31 1368 S->C: RTSP/1.0 200 OK 1369 CSeq: 312 1371 10.4 SETUP 1373 The SETUP request for a URI specifies the transport mechanism to be 1374 used for the streamed media. A client can issue a SETUP request for a 1375 stream that is already playing to change transport parameters, which 1376 a server MAY allow. If it does not allow this, it MUST respond with 1377 error 455 (Method Not Valid In This State). For the benefit of any 1378 intervening firewalls, a client must indicate the transport 1379 parameters even if it has no influence over these parameters, for 1380 example, where the server advertises a fixed multicast address. 1382 Since SETUP includes all transport initialization 1383 information, firewalls and other intermediate network 1384 devices (which need this information) are spared the more 1385 arduous task of parsing the DESCRIBE response, which has 1386 been reserved for media initialization. 1388 The Transport header specifies the transport parameters acceptable 1389 to the client for data transmission; the response will contain the 1390 transport parameters selected by the server. 1392 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 1393 CSeq: 302 1394 Transport: RTP/AVP;unicast;client_port=4588-4589 1396 S->C: RTSP/1.0 200 OK 1397 CSeq: 302 1398 Date: 23 Jan 1997 15:35:06 GMT 1399 Session: 47112344 1400 Transport: RTP/AVP;unicast; 1401 client_port=4588-4589;server_port=6256-6257 1403 The server generates session identifiers in response to SETUP 1404 requests. If a SETUP request to a server includes a session 1405 identifier, the server MUST bundle this setup request into the 1406 existing session or return error 459 (Aggregate Operation Not 1407 Allowed) (see Section 11.4.10). 1409 10.5 PLAY 1411 The PLAY method tells the server to start sending data via the 1412 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 1413 until any outstanding SETUP requests have been acknowledged as 1414 successful. 1416 The PLAY request positions the normal play time to the beginning of 1417 the range specified and delivers stream data until the end of the 1418 range is reached. PLAY requests may be pipelined (queued); a server 1419 MUST queue PLAY requests to be executed in order. That is, a PLAY 1420 request arriving while a previous PLAY request is still active is 1421 delayed until the first has been completed. 1423 This allows precise editing. For example, regardless of 1424 how closely spaced the two PLAY requests in the example 1425 below arrive, the server will first play seconds 10 through 1426 15, then, immediately following, seconds 20 to 25, and 1427 finally seconds 30 through the end. 1429 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1430 CSeq: 835 1431 Session: 12345678 1432 Range: npt=10-15 1434 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1435 CSeq: 836 1436 Session: 12345678 1437 Range: npt=20-25 1439 C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0 1440 CSeq: 837 1441 Session: 12345678 1442 Range: npt=30- 1444 See the description of the PAUSE request for further examples. 1446 A PLAY request without a Range header is legal. It starts playing a 1447 stream from the beginning unless the stream has been paused. If a 1448 stream has been paused via PAUSE, stream delivery resumes at the 1449 pause point. If a stream is playing, such a PLAY request causes no 1450 further action and can be used by the client to test server liveness. 1452 The Range header may also contain a time parameter. This parameter 1453 specifies a time in UTC at which the playback should start. If the 1454 message is received after the specified time, playback is started 1455 immediately. The time parameter may be used to aid in 1456 synchronization of streams obtained from different sources. 1458 For a on-demand stream, the server replies with the actual range that 1459 will be played back. This may differ from the requested range if 1460 alignment of the requested range to valid frame boundaries is 1461 required for the media source. If no range is specified in the 1462 request, the current position is returned in the reply. The unit of 1463 the range in the reply is the same as that in the request. 1465 After playing the desired range, the presentation is automatically 1466 paused, as if a PAUSE request had been issued. 1468 The following example plays the whole presentation starting at SMPTE 1469 time code 0:10:20 until the end of the clip. The playback is to start 1470 at 15:36 on 23 Jan 1997. 1472 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 1473 CSeq: 833 1474 Session: 12345678 1475 Range: smpte=0:10:20-;time=19970123T153600Z 1477 S->C: RTSP/1.0 200 OK 1478 CSeq: 833 1479 Date: 23 Jan 1997 15:35:06 GMT 1480 Range: smpte=0:10:22-;time=19970123T153600Z 1482 For playing back a recording of a live presentation, it may be 1483 desirable to use clock units: 1485 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 1486 CSeq: 835 1487 Session: 12345678 1488 Range: clock=19961108T142300Z-19961108T143520Z 1490 S->C: RTSP/1.0 200 OK 1491 CSeq: 835 1492 Date: 23 Jan 1997 15:35:06 GMT 1494 A media server only supporting playback MUST support the npt format 1495 and MAY support the clock and smpte formats. 1497 10.6 PAUSE 1499 The PAUSE request causes the stream delivery to be interrupted 1500 (halted) temporarily. If the request URL names a stream, only 1501 playback and recording of that stream is halted. For example, for 1502 audio, this is equivalent to muting. If the request URL names a 1503 presentation or group of streams, delivery of all currently active 1504 streams within the presentation or group is halted. After resuming 1505 playback or recording, synchronization of the tracks MUST be 1506 maintained. Any server resources are kept, though servers MAY close 1507 the session and free resources after being paused for the duration 1508 specified with the timeout parameter of the Session header in the 1509 SETUP message. 1511 Example: 1513 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 1514 CSeq: 834 1515 Session: 12345678 1517 S->C: RTSP/1.0 200 OK 1518 CSeq: 834 1519 Date: 23 Jan 1997 15:35:06 GMT 1521 The PAUSE request may contain a Range header specifying when the 1522 stream or presentation is to be halted. We refer to this point as the 1523 "pause point". The header must contain exactly one value rather than 1524 a time range. The normal play time for the stream is set to the pause 1525 point. The pause request becomes effective the first time the server 1526 is encountering the time point specified in any of the currently 1527 pending PLAY requests. If the Range header specifies a time outside 1528 any currently pending PLAY requests, the error 457 (Invalid Range) is 1529 returned. If a media unit (such as an audio or video frame) starts 1530 presentation at exactly the pause point, it is not played or 1531 recorded. If the Range header is missing, stream delivery is 1532 interrupted immediately on receipt of the message and the pause point 1533 is set to the current normal play time. 1535 A PAUSE request discards all queued PLAY requests. However, the pause 1536 point in the media stream MUST be maintained. A subsequent PLAY 1537 request without Range header resumes from the pause point. 1539 For example, if the server has play requests for ranges 10 to 15 and 1540 20 to 29 pending and then receives a pause request for NPT 21, it 1541 would start playing the second range and stop at NPT 21. If the pause 1542 request is for NPT 12 and the server is playing at NPT 13 serving the 1543 first play request, the server stops immediately. If the pause 1544 request is for NPT 16, the server stops after completing the first 1545 play request and discards the second play request. 1547 As another example, if a server has received requests to play ranges 1548 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 1549 request for NPT=14 would take effect while the server plays the first 1550 range, with the second PLAY request effectively being ignored, 1551 assuming the PAUSE request arrives before the server has started 1552 playing the second, overlapping range. Regardless of when the PAUSE 1553 request arrives, it sets the NPT to 14. 1555 If the server has already sent data beyond the time specified in the 1556 Range header, a PLAY would still resume at that point in time, as it 1557 is assumed that the client has discarded data after that point. This 1558 ensures continuous pause/play cycling without gaps. 1560 10.7 TEARDOWN 1562 The TEARDOWN request stops the stream delivery for the given URI, 1563 freeing the resources associated with it. If the URI is the 1564 presentation URI for this presentation, any RTSP session identifier 1565 associated with the session is no longer valid. Unless all transport 1566 parameters are defined by the session description, a SETUP request 1567 has to be issued before the session can be played again. 1569 Example: 1571 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 1572 CSeq: 892 1573 Session: 12345678 1575 S->C: RTSP/1.0 200 OK 1576 CSeq: 892 1578 10.8 GET_PARAMETER 1580 The GET_PARAMETER request retrieves the value of a parameter of a 1581 presentation or stream specified in the URI. The content of the reply 1582 and response is left to the implementation. GET_PARAMETER with no 1583 entity body may be used to test client or server liveness ("ping"). 1585 Example: 1587 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1588 CSeq: 431 1589 Content-Type: text/parameters 1590 Session: 12345678 1591 Content-Length: 15 1593 packets_received 1594 jitter 1596 C->S: RTSP/1.0 200 OK 1597 CSeq: 431 1598 Content-Length: 46 1599 Content-Type: text/parameters 1600 packets_received: 10 1601 jitter: 0.3838 1603 The "text/parameters" section is only an example type for 1604 parameter. This method is intentionally loosely defined 1605 with the intention that the reply content and response 1606 content will be defined after further experimentation. 1608 10.9 SET_PARAMETER 1610 This method requests to set the value of a parameter for a 1611 presentation or stream specified by the URI. 1613 A request SHOULD only contain a single parameter to allow the client 1614 to determine why a particular request failed. If the request contains 1615 several parameters, the server MUST only act on the request if all of 1616 the parameters can be set successfully. A server MUST allow a 1617 parameter to be set repeatedly to the same value, but it MAY disallow 1618 changing parameter values. 1620 Note: transport parameters for the media stream MUST only be set with 1621 the SETUP command. 1623 Restricting setting transport parameters to SETUP is for 1624 the benefit of firewalls. 1626 The parameters are split in a fine-grained fashion so that 1627 there can be more meaningful error indications. However, it 1628 may make sense to allow the setting of several parameters 1629 if an atomic setting is desirable. Imagine device control 1630 where the client does not want the camera to pan unless it 1631 can also tilt to the right angle at the same time. 1633 Example: 1635 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 1636 CSeq: 421 1637 Content-length: 20 1638 Content-type: text/parameters 1640 barparam: barstuff 1642 S->C: RTSP/1.0 451 Parameter Not Understood 1643 CSeq: 421 1644 Content-length: 10 1645 Content-type: text/parameters 1647 barparam 1649 The "text/parameters" section is only an example type for 1650 parameter. This method is intentionally loosely defined 1651 with the intention that the reply content and response 1652 content will be defined after further experimentation. 1654 10.10 REDIRECT 1656 A redirect request informs the client that it must connect to another 1657 server location. It contains the mandatory header Location, which 1658 indicates that the client should issue requests for that URL. It may 1659 contain the parameter Range, which indicates when the redirection 1660 takes effect. If the client wants to continue to send or receive 1661 media for this URI, the client MUST issue a TEARDOWN request for the 1662 current session and a SETUP for the new session at the designated 1663 host. 1665 This example request redirects traffic for this URI to the new server 1666 at the given play time: 1668 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 1669 CSeq: 732 1670 Location: rtsp://bigserver.com:8001 1671 Range: clock=19960213T143205Z- 1673 10.11 RECORD 1675 This method initiates recording a range of media data according to 1676 the presentation description. The timestamp reflects start and end 1677 time (UTC). If no time range is given, use the start or end time 1678 provided in the presentation description. If the session has already 1679 started, commence recording immediately. 1681 The server decides whether to store the recorded data under the 1682 request-URI or another URI. If the server does not use the request- 1683 URI, the response SHOULD be 201 (Created) and contain an entity which 1684 describes the status of the request and refers to the new resource, 1685 and a Location header. 1687 A media server supporting recording of live presentations MUST 1688 support the clock range format; the smpte format does not make sense. 1690 In this example, the media server was previously invited to the 1691 conference indicated. 1693 C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 1694 CSeq: 954 1695 Session: 12345678 1696 Conference: 128.16.64.19/32492374 1698 10.12 Embedded (Interleaved) Binary Data 1700 Certain firewall designs and other circumstances may force a server 1701 to interleave RTSP methods and stream data. This interleaving should 1702 generally be avoided unless necessary since it complicates client and 1703 server operation and imposes additional overhead. Interleaved binary 1704 data SHOULD only be used if RTSP is carried over TCP. 1706 Stream data such as RTP packets is encapsulated by an ASCII dollar 1707 sign (24 decimal), followed by a one-byte channel identifier, 1708 followed by the length of the encapsulated binary data as a binary, 1709 two-byte integer in network byte order. The stream data follows 1710 immediately afterwards, without a CRLF, but including the upper-layer 1711 protocol headers. Each $ block contains exactly one upper-layer 1712 protocol data unit, e.g., one RTP packet. 1714 The channel identifier is defined in the Transport header with the 1715 interleaved parameter(Section 12.40). 1717 When the transport choice is RTP, RTCP messages are also interleaved 1718 by the server over the TCP connection. As a default, RTCP packets are 1719 sent on the first available channel higher than the RTP channel. The 1720 client MAY explicitly request RTCP packets on another channel. This 1721 is done by specifying two channels in the interleaved parameter of 1722 the Transport header(Section 12.40). 1724 RTCP is needed for synchronization when two or more streams 1725 are interleaved in such a fashion. Also, this provides a 1726 convenient way to tunnel RTP/RTCP packets through the TCP 1727 control connection when required by the network 1728 configuration and transfer them onto UDP when possible. 1730 C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 1731 CSeq: 2 1732 Transport: RTP/AVP/TCP;interleaved=0-1 1734 S->C: RTSP/1.0 200 OK 1735 CSeq: 2 1736 Date: 05 Jun 1997 18:57:18 GMT 1737 Transport: RTP/AVP/TCP;interleaved=0-1 1738 Session: 12345678 1740 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 1741 CSeq: 3 1742 Session: 12345678 1744 S->C: RTSP/1.0 200 OK 1745 CSeq: 3 1746 Session: 12345678 1747 Date: 05 Jun 1997 18:59:15 GMT 1748 RTP-Info: url=rtsp://foo.com/bar.file; 1749 seq=232433;rtptime=972948234 1751 S->C: $000{2 byte length}{"length" bytes data, w/RTP header} 1752 S->C: $000{2 byte length}{"length" bytes data, w/RTP header} 1753 S->C: $001{2 byte length}{"length" bytes RTCP packet} 1755 11 Status Code Definitions 1757 Where applicable, HTTP status [H10] codes are reused. Status codes 1758 that have the same meaning are not repeated here. See Table 1 for a 1759 listing of which status codes may be returned by which requests. 1761 11.1 Success 2xx 1763 11.1.1 250 Low on Storage Space 1765 The server returns this warning after receiving a RECORD request 1766 that it may not be able to fulfill completely due to insufficient 1767 storage space. If possible, the server should use the Range header to 1768 indicate what time period it may still be able to record. Since other 1769 processes on the server may be consuming storage space 1770 simultaneously, a client should take this only as an estimate. 1772 11.2 Redirection 3xx 1773 See [H10.3]. 1775 Within RTSP, redirection may be used for load balancing or 1776 redirecting stream requests to a server topologically closer to the 1777 client. Mechanisms to determine topological proximity are beyond the 1778 scope of this specification. 1780 11.3 Client Error 4xx 1782 11.4 400 Bad Request 1784 The request could not be understood by the server due to malformed 1785 syntax. The client SHOULD NOT repeat the request without 1786 modifications [H10.4.1]. If the request does not have a CSeq header, 1787 the server MUST not include a CSeq in the response. 1789 11.4.1 405 Method Not Allowed 1791 The method specified in the request is not allowed for the resource 1792 identified by the request URI. The response MUST include an Allow 1793 header containing a list of valid methods for the requested resource. 1794 This status code is also to be used if a request attempts to use a 1795 method not indicated during SETUP, e.g., if a RECORD request is 1796 issued even though the mode parameter in the Transport header only 1797 specified PLAY. 1799 11.4.2 451 Parameter Not Understood 1801 The recipient of the request does not support one or more parameters 1802 contained in the request. 1804 11.4.3 452 Conference Not Found 1806 The conference indicated by a Conference header field is unknown to 1807 the media server. 1809 11.4.4 453 Not Enough Bandwidth 1811 The request was refused because there was insufficient bandwidth. 1812 This may, for example, be the result of a resource reservation 1813 failure. 1815 11.4.5 454 Session Not Found 1817 The RTSP session identifier in the Session header is missing, 1818 invalid, or has timed out. 1820 11.4.6 455 Method Not Valid in This State 1821 The client or server cannot process this request in its current 1822 state. The response SHOULD contain an Allow header to make error 1823 recovery easier. 1825 11.4.7 456 Header Field Not Valid for Resource 1827 The server could not act on a required request header. For example, 1828 if PLAY contains the Range header field but the stream does not 1829 allow seeking. 1831 11.4.8 457 Invalid Range 1833 The Range value given is out of bounds, e.g., beyond the end of the 1834 presentation. 1836 11.4.9 458 Parameter Is Read-Only 1838 The parameter to be set by SET_PARAMETER can be read but not 1839 modified. 1841 11.4.10 459 Aggregate Operation Not Allowed 1843 The requested method may not be applied on the URL in question since 1844 it is an aggregate (presentation) URL. The method may be applied on a 1845 stream URL. 1847 11.4.11 460 Only Aggregate Operation Allowed 1849 The requested method may not be applied on the URL in question since 1850 it is not an aggregate (presentation) URL. The method may be applied 1851 on the presentation URL. 1853 11.4.12 461 Unsupported Transport 1855 The Transport field did not contain a supported transport 1856 specification. 1858 11.4.13 462 Destination Unreachable 1860 The data transmission channel could not be established because the 1861 client address could not be reached. This error will most likely be 1862 the result of a client attempt to place an invalid Destination 1863 parameter in the Transport field. 1865 11.5 Server Error 5xx 1867 11.5.1 551 Option not supported 1868 An option given in the Require or the Proxy-Require fields was not 1869 supported. The Unsupported header should be returned stating the 1870 option for which there is no support. 1872 12 Header Field Definitions 1874 HTTP/1.1 [2] or other, non-standard header fields not listed here 1875 currently have no well-defined meaning and SHOULD be ignored by the 1876 recipient. 1878 Table 3 summarizes the header fields used by RTSP. Type "g" 1879 designates general request headers to be found in both requests and 1880 responses, type "R" designates request headers, type "r" designates 1881 response headers, and type "e" designates entity header fields. 1882 Fields marked with "req." in the column labeled "support" MUST be 1883 implemented by the recipient for a particular method, while fields 1884 marked "opt." are optional. Note that not all fields marked "req." 1885 will be sent in every request of this type. The "req." means only 1886 that client (for response headers) and server (for request headers) 1887 MUST implement the fields. The last column lists the method for which 1888 this header field is meaningful; the designation "entity" refers to 1889 all methods that return a message body. Within this specification, 1890 DESCRIBE and GET_PARAMETER fall into this class. 1892 12.1 Accept 1894 The Accept request-header field can be used to specify certain 1895 presentation description content types which are acceptable for the 1896 response. 1898 The "level" parameter for presentation descriptions is 1899 properly defined as part of the MIME type registration, not 1900 here. 1902 See [H14.1] for syntax. 1904 Example of use: 1906 Accept: application/rtsl, application/sdp;level=2 1908 12.2 Accept-Encoding 1910 See [H14.3] 1912 12.3 Accept-Language 1913 See [H14.4]. Note that the language specified applies to the 1914 presentation description and any reason phrases, not the media 1915 content. 1917 12.4 Accept-Ranges 1919 12.5 Allow 1921 The Allow entity-header field lists the methods supported by the 1922 resource identified by the request-URI. The purpose of this field is 1923 to strictly inform the recipient of valid methods associated with the 1924 resource. An Allow header field must be present in a 405 (Method Not 1925 Allowed) response. 1927 Example of use: 1929 Allow: SETUP, PLAY, RECORD, SET_PARAMETER 1931 12.6 Authorization 1933 See [H14.8] 1935 12.7 Bandwidth 1937 The Bandwidth request-header field describes the estimated bandwidth 1938 available to the client, expressed as a positive integer and measured 1939 in bits per second. The bandwidth available to the client may change 1940 during an RTSP session, e.g., due to modem retraining. 1942 Bandwidth _ "Bandwidth" ":" 1*DIGIT 1944 Example: 1946 Bandwidth: 4000 1948 12.8 Blocksize 1950 The Blocksize request-header field is sent from the client to the 1951 media server asking the server for a particular media packet size. 1952 This packet size does not include lower-layer headers such as IP, 1953 UDP, or RTP. The server is free to use a blocksize which is lower 1954 than the one requested. The server MAY truncate this packet size to 1955 Header type support methods 1956 ____________________________________________________________ 1957 Accept R opt. entity 1958 Accept-Encoding R opt. entity 1959 Accept-Language R opt. all 1960 Accept-Ranges R opt. all 1961 Allow e opt. all 1962 Authorization R opt. all 1963 Bandwidth R opt. all 1964 Blocksize R opt. all but OPTIONS, TEARDOWN 1965 Cache-Control g opt. SETUP 1966 Conference R opt. SETUP 1967 Connection g req. all 1968 Content-Base e opt. entity 1969 Content-Encoding e req. SET_PARAMETER 1970 Content-Encoding e req. DESCRIBE, ANNOUNCE 1971 Content-Language e req. DESCRIBE, ANNOUNCE 1972 Content-Length e req. SET_PARAMETER, ANNOUNCE 1973 Content-Length e req. entity 1974 Content-Location e opt. entity 1975 Content-Type e req. SET_PARAMETER, ANNOUNCE 1976 CSeq g req. all 1977 Date g opt. all 1978 Expires e opt. DESCRIBE, ANNOUNCE 1979 From R opt. all 1980 If-Match R opt. SETUP 1981 If-Modified-Since R opt. DESCRIBE, SETUP 1982 Last-Modified e opt. entity 1983 Location r opt. 201, 30x 1984 Proxy-Authenticate r req. 407 1985 Proxy-Require R req. all 1986 Public r opt. all 1987 Range R opt. PLAY, PAUSE, RECORD 1988 Range r opt. PLAY, PAUSE, RECORD 1989 Referer R opt. all 1990 Require R req. all 1991 Retry-After r opt. all 1992 RTP-Info r req. PLAY 1993 Scale g opt. PLAY, RECORD 1994 Session g req. all but OPTIONS 1995 Server r opt. all 1996 Speed g opt. PLAY 1997 Transport g req. SETUP 1998 Unsupported r req. all 1999 User-Agent R opt. all 2000 Vary r opt. all 2001 Via g opt. all 2002 WWW-Authenticate r opt. all 2004 Table 3: Overview of RTSP header fields 2006 the closest multiple of the minimum, media-specific block size, or 2007 override it with the media-specific size if necessary. The block size 2008 MUST be a positive decimal number, measured in octets. The server 2009 only returns an error (416) if the value is syntactically invalid. 2011 Blocksize _ "Blocksize" ":" 1*DIGIT 2013 12.9 Cache-Control 2015 The Cache-Control general-header field is used to specify directives 2016 that MUST be obeyed by all caching mechanisms along the 2017 request/response chain. 2019 Cache directives must be passed through by a proxy or gateway 2020 application, regardless of their significance to that application, 2021 since the directives may be applicable to all recipients along the 2022 request/response chain. It is not possible to specify a cache- 2023 directive for a specific cache. 2025 Cache-Control should only be specified in a SETUP request and its 2026 response. Note: Cache-Control does not govern the caching of 2027 responses as for HTTP, but rather of the stream identified by the 2028 SETUP request. Responses to RTSP requests are not cacheable, except 2029 for responses to DESCRIBE. 2031 Cache-Control = "Cache-Control" ":" 1#cache-directive 2032 cache-directive = cache-request-directive 2033 | cache-response-directive 2034 cache-request-directive = "no-cache" 2035 | "max-stale" 2036 | "min-fresh" 2037 | "only-if-cached" 2038 | cache-extension 2039 cache-response-directive = "public" 2040 | "private" 2041 | "no-cache" 2042 | "no-transform" 2043 | "must-revalidate" 2044 | "proxy-revalidate" 2045 | "max-age" "=" delta-seconds 2046 | cache-extension 2047 cache-extension = token [ "=" ( token | quoted-string ) ] 2048 no-cache: Indicates that the media stream MUST NOT be cached 2049 anywhere. This allows an origin server to prevent caching 2050 even by caches that have been configured to return stale 2051 responses to client requests. 2053 public: Indicates that the media stream is cacheable by any 2054 cache. 2056 private: Indicates that the media stream is intended for a 2057 single user and MUST NOT be cached by a shared cache. A 2058 private (non-shared) cache may cache the media stream. 2060 no-transform: An intermediate cache (proxy) may find it useful 2061 to convert the media type of a certain stream. A proxy 2062 might, for example, convert between video formats to save 2063 cache space or to reduce the amount of traffic on a slow 2064 link. Serious operational problems may occur, however, when 2065 these transformations have been applied to streams intended 2066 for certain kinds of applications. For example, 2067 applications for medical imaging, scientific data analysis 2068 and those using end-to-end authentication all depend on 2069 receiving a stream that is bit-for-bit identical to the 2070 original entity-body. Therefore, if a response includes the 2071 no-transform directive, an intermediate cache or proxy MUST 2072 NOT change the encoding of the stream. Unlike HTTP, RTSP 2073 does not provide for partial transformation at this point, 2074 e.g., allowing translation into a different language. 2076 only-if-cached: In some cases, such as times of extremely poor 2077 network connectivity, a client may want a cache to return 2078 only those media streams that it currently has stored, and 2079 not to receive these from the origin server. To do this, 2080 the client may include the only-if-cached directive in a 2081 request. If it receives this directive, a cache SHOULD 2082 either respond using a cached media stream that is 2083 consistent with the other constraints of the request, or 2084 respond with a 504 (Gateway Timeout) status. However, if a 2085 group of caches is being operated as a unified system with 2086 good internal connectivity, such a request MAY be forwarded 2087 within that group of caches. 2089 max-stale: Indicates that the client is willing to accept a 2090 media stream that has exceeded its expiration time. If 2091 max-stale is assigned a value, then the client is willing 2092 to accept a response that has exceeded its expiration time 2093 by no more than the specified number of seconds. If no 2094 value is assigned to max-stale, then the client is willing 2095 to accept a stale response of any age. 2097 min-fresh: Indicates that the client is willing to accept a 2098 media stream whose freshness lifetime is no less than its 2099 current age plus the specified time in seconds. That is, 2100 the client wants a response that will still be fresh for at 2101 least the specified number of seconds. 2103 must-revalidate: When the must-revalidate directive is present 2104 in a SETUP response received by a cache, that cache MUST 2105 NOT use the entry after it becomes stale to respond to a 2106 subsequent request without first revalidating it with the 2107 origin server. That is, the cache must do an end-to-end 2108 revalidation every time, if, based solely on the origin 2109 server's Expires, the cached response is stale.) 2111 12.10 Conference 2113 The Conference request-header field establishes a logical connection 2114 between a pre-established conference and an RTSP stream. The 2115 conference-id must not be changed for the same RTSP session. 2117 Conference _ "Conference" ":" conference-id 2119 Example: 2121 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 2123 A response code of 452 (Conference Not Found) is returned if the 2124 conference-id is not valid. 2126 12.11 Connection 2128 See [H14.10] 2130 12.12 Content-Base 2132 See [H14.11] 2134 12.13 Content-Encoding 2136 See [H14.12] 2138 12.14 Content-Language 2140 See [H14.13] 2142 12.15 Content-Length 2144 The Content-Length general-header field contains the length of the 2145 content of the method (i.e. after the double CRLF following the last 2146 header). Unlike HTTP, it MUST be included in all messages that carry 2147 content beyond the header portion of the message. If it is missing, a 2148 default value of zero is assumed. It is interpreted according to 2149 [H14.14]. 2151 12.16 Content-Location 2153 See [H14.15] 2155 12.17 Content-Type 2157 See [H14.18]. Note that the content types suitable for RTSP are 2158 likely to be restricted in practice to presentation descriptions and 2159 parameter-value types. 2161 12.18 CSeq 2163 The CSeq general-header field specifies the sequence number for an 2164 RTSP request-response pair. This field MUST be present in all 2165 requests and responses. For every RTSP request containing the given 2166 sequence number, the corresponding response will have the same 2167 number. Any retransmitted request must contain the same sequence 2168 number as the original (i.e. the sequence number is not incremented 2169 for retransmissions of the same request). 2171 CSeq _ "Cseq" ":" 1*DIGIT 2173 12.19 Date 2175 See [H14.19]. 2177 12.20 Expires 2179 The Expires entity-header field gives a date and time after which 2180 the description or media-stream should be considered stale. The 2181 interpretation depends on the method: 2183 DESCRIBE response: The Expires header indicates a date and time 2184 after which the description should be considered stale. 2186 A stale cache entry may not normally be returned by a cache (either a 2187 proxy cache or an user agent cache) unless it is first validated with 2188 the origin server (or with an intermediate cache that has a fresh 2189 copy of the entity). See section 13 for further discussion of the 2190 expiration model. 2192 The presence of an Expires field does not imply that the original 2193 resource will change or cease to exist at, before, or after that 2194 time. 2196 The format is an absolute date and time as defined by HTTP-date in 2197 [H3.3]; it MUST be in RFC1123-date format: 2199 Expires _ "Expires" ":" HTTP-date 2201 An example of its use is 2203 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2205 RTSP/1.0 clients and caches MUST treat other invalid date formats, 2206 especially including the value "0", as having occurred in the past 2207 (i.e., already expired). 2209 To mark a response as "already expired," an origin server should use 2210 an Expires date that is equal to the Date header value. To mark a 2211 response as "never expires," an origin server should use an Expires 2212 date approximately one year from the time the response is sent. 2213 RTSP/1.0 servers should not send Expires dates more than one year in 2214 the future. 2216 The presence of an Expires header field with a date value of some 2217 time in the future on a media stream that otherwise would by default 2218 be non-cacheable indicates that the media stream is cacheable, unless 2219 indicated otherwise by a Cache-Control header field (Section 12.9). 2221 12.21 From 2223 See [H14.22]. 2225 12.22 Host 2227 The Host HTTP request header field is not needed for RTSP. It should 2228 be silently ignored if sent. 2230 12.23 If-Match 2231 See [H14.25]. 2233 The If-Match request-header field is especially useful for ensuring 2234 the integrity of the presentation description, in both the case where 2235 it is fetched via means external to RTSP (such as HTTP), or in the 2236 case where the server implementation is guaranteeing the integrity of 2237 the description between the time of the DESCRIBE message and the 2238 SETUP message. 2240 The identifier is an opaque identifier, and thus is not specific to 2241 any particular session description language. 2243 12.24 If-Modified-Since 2245 The If-Modified-Since request-header field is used with the DESCRIBE 2246 and SETUP methods to make them conditional. If the requested variant 2247 has not been modified since the time specified in this field, a 2248 description will not be returned from the server (DESCRIBE) or a 2249 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 2250 response will be returned without any message-body. 2252 If-Modified-Since _ "If-Modified-Since" ":" HTTP-date 2254 An example of the field is: 2256 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 2258 12.25 Last-Modified 2260 The Last-Modified entity-header field indicates the date and time at 2261 which the origin server believes the presentation description or 2262 media stream was last modified. See [H14.29]. For the methods 2263 DESCRIBE or ANNOUNCE, the header field indicates the last 2264 modification date and time of the description, for SETUP that of the 2265 media stream. 2267 12.26 Location 2269 See [H14.30]. 2271 12.27 Proxy-Authenticate 2273 See [H14.33]. 2275 12.28 Proxy-Require 2277 The Proxy-Require request-header field is used to indicate proxy- 2278 sensitive features that MUST be supported by the proxy. Any Proxy- 2279 Require header features that are not supported by the proxy MUST be 2280 negatively acknowledged by the proxy to the client if not supported. 2281 Servers should treat this field identically to the Require field. 2283 See Section 12.33 for more details on the mechanics of this message 2284 and a usage example. 2286 12.29 Public 2288 See [H14.35]. 2290 12.30 Range 2292 The Range request and response header field specifies a range of 2293 time. The range can be specified in a number of units. This 2294 specification defines the smpte (Section 3.5), npt (Section 3.6), 2295 and clock (Section 3.7) range units. Within RTSP, byte ranges 2296 [H14.36.1] are not meaningful and MUST NOT be used. The header may 2297 also contain a time parameter in UTC, specifying the time at which 2298 the operation is to be made effective. Servers supporting the Range 2299 header MUST understand the NPT range format and SHOULD understand the 2300 SMPTE range format. The Range response header indicates what range 2301 of time is actually being played or recorded. If the Range header is 2302 given in a time format that is not understood, the recipient should 2303 return 501 (Not Implemented). 2305 Ranges are half-open intervals, including the lower point, but 2306 excluding the upper point. In other words, a range of a-b starts 2307 exactly at time a, but stops just before b. Only the start time of a 2308 media unit such as a video or audio frame is relevant. As an example, 2309 assume that video frames are generated every 40 ms. A range of 2310 10.0-10.1 would include a video frame starting at 10.0 or later time 2311 and would include a video frame starting at 10.08, even though it 2312 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 2313 would exclude the frame at 10.08. 2315 Range _ "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ] 2316 ranges-specifier _ npt-range | utc-range | smpte-range 2318 Example: 2320 Range: clock=19960213T143205Z-;time=19970123T143720Z 2321 The notation is similar to that used for the HTTP/1.1 [2] 2322 byte-range header. It allows clients to select an excerpt 2323 from the media object, and to play from a given point to 2324 the end as well as from the current location to a given 2325 point. The start of playback can be scheduled for any time 2326 in the future, although a server may refuse to keep server 2327 resources for extended idle periods. 2329 12.31 Referer 2331 See [H14.37]. The URL refers to that of the presentation description, 2332 typically retrieved via HTTP. 2334 12.32 Retry-After 2336 See [H14.38]. 2338 12.33 Require 2340 The Require request-header field is used by clients to query the 2341 server about options that it may or may not support. The server MUST 2342 respond to this header by using the Unsupported header to negatively 2343 acknowledge those options which are NOT supported. 2345 This is to make sure that the client-server interaction 2346 will proceed without delay when all options are understood 2347 by both sides, and only slow down if options are not 2348 understood (as in the case above). For a well-matched 2349 client-server pair, the interaction proceeds quickly, 2350 saving a round-trip often required by negotiation 2351 mechanisms. In addition, it also removes state ambiguity 2352 when the client requires features that the server does not 2353 understand. 2355 Require _ "Require" ":" 1#option-tag 2357 Example: 2359 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 2360 CSeq: 302 2361 Require: funky-feature 2362 Funky-Parameter: funkystuff 2364 S->C: RTSP/1.0 551 Option not supported 2365 CSeq: 302 2366 Unsupported: funky-feature 2368 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 2369 CSeq: 303 2371 S->C: RTSP/1.0 200 OK 2372 CSeq: 303 2374 In this example, "funky-feature" is the feature tag which indicates 2375 to the client that the fictional Funky-Parameter field is required. 2376 The relationship between "funky-feature" and Funky-Parameter is not 2377 communicated via the RTSP exchange, since that relationship is an 2378 immutable property of "funky-feature" and thus should not be 2379 transmitted with every exchange. 2381 Proxies and other intermediary devices SHOULD ignore features that 2382 are not understood in this field. If a particular extension requires 2383 that intermediate devices support it, the extension should be tagged 2384 in the Proxy-Require field instead (see Section 12.28). 2386 12.34 RTP-Info 2388 The RTP-Info response-header field is used to set RTP-specific 2389 parameters in the PLAY response. 2391 url: Indicates the stream URL which for which the following RTP 2392 parameters correspond. 2394 seq: Indicates the sequence number of the first packet of the 2395 stream. This allows clients to gracefully deal with packets 2396 when seeking. The client uses this value to differentiate 2397 packets that originated before the seek from packets that 2398 originated after the seek. 2400 rtptime: Indicates the RTP timestamp corresponding to the time 2401 value in the Range response header. (Note: For aggregate 2402 control, a particular stream may not actually generate a 2403 packet for the Range time value returned or implied. Thus, 2404 there is no guarantee that the packet with the sequence 2405 number indicated by seq actually has the timestamp 2406 indicated by rtptime.) The client uses this value to 2407 calculate the mapping of RTP time to NPT. 2409 A mapping from RTP timestamps to NTP timestamps (wall 2410 clock) is available via RTCP. However, this 2411 information is not sufficient to generate a mapping 2412 from RTP timestamps to NPT. Furthermore, in order to 2413 ensure that this information is available at the 2414 necessary time (immediately at startup or after a 2415 seek), and that it is delivered reliably, this mapping 2416 is placed in the RTSP control channel. 2418 In order to compensate for drift for long, uninterrupted 2419 presentations, RTSP clients should additionally map NPT to 2420 NTP, using initial RTCP sender reports to do the mapping, 2421 and later reports to check drift against the mapping. 2423 Syntax: 2425 RTP-Info ______________________________ "RTP-Info" ":" 1#rtsp-info-spec 2426 rtsp-info-spec ______________________________ stream-url 1*parameter 2427 stream-url ______________________________ quoted-url | unquoted-url 2428 unquoted-url ______________________________ "url" "=" safe-url 2429 | ";" "mode" = <"> 1#Method <"> 2430 quoted-url ______________________________ "url" "=" <"> needquote-url <"> 2431 safe-url ______________________________ url 2432 needquote-url ______________________________ url 2433 url ______________________________ ( absoluteURI | relativeURI ) 2434 parameter ______________________________ ";" "seq" "=" 1*DIGIT 2435 | ";" "rtptime" "=" 1*DIGIT 2437 Additional constraint: safe-url MUST NOT contain the semicolon (";") 2438 or comma (",") characters. The quoted-url form SHOULD only be used 2439 when a URL does not meet the safe-url constraint, in order to ensure 2440 compatibility with implementations conformant to RFC 2326 [25]. 2442 absoluteURI and relativeURI are defined in RFC 2396 [26]. 2444 Example: 2446 RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, 2447 url=rtsp://foo.com/bar.avi/streamid=1;seq=30211 2449 12.35 Scale 2451 A scale value of 1 indicates normal play or record at the normal 2452 forward viewing rate. If not 1, the value corresponds to the rate 2453 with respect to normal viewing rate. For example, a ratio of 2 2454 indicates twice the normal viewing rate ("fast forward") and a ratio 2455 of 0.5 indicates half the normal viewing rate. In other words, a 2456 ratio of 2 has normal play time increase at twice the wallclock rate. 2457 For every second of elapsed (wallclock) time, 2 seconds of content 2458 will be delivered. A negative value indicates reverse direction. 2460 Unless requested otherwise by the Speed parameter, the data rate 2461 SHOULD not be changed. Implementation of scale changes depends on the 2462 server and media type. For video, a server may, for example, deliver 2463 only key frames or selected key frames. For audio, it may time-scale 2464 the audio while preserving pitch or, less desirably, deliver 2465 fragments of audio. 2467 The server should try to approximate the viewing rate, but may 2468 restrict the range of scale values that it supports. The response 2469 MUST contain the actual scale value chosen by the server. 2471 If the request contains a Range parameter, the new scale value will 2472 take effect at that time. 2474 Scale _ "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ] 2476 Example of playing in reverse at 3.5 times normal rate: 2478 Scale: -3.5 2480 12.36 Speed 2482 The Speed request-header field requests the server to deliver data 2483 to the client at a particular speed, contingent on the server's 2484 ability and desire to serve the media stream at the given speed. 2485 Implementation by the server is OPTIONAL. The default is the bit rate 2486 of the stream. 2488 The parameter value is expressed as a decimal ratio, e.g., a value of 2489 2.0 indicates that data is to be delivered twice as fast as normal. A 2490 speed of zero is invalid. If the request contains a Range parameter, 2491 the new speed value will take effect at that time. 2493 Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ] 2495 Example: 2497 Speed: 2.5 2499 Use of this field changes the bandwidth used for data delivery. It is 2500 meant for use in specific circumstances where preview of the 2501 presentation at a higher or lower rate is necessary. Implementors 2502 should keep in mind that bandwidth for the session may be negotiated 2503 beforehand (by means other than RTSP), and therefore re-negotiation 2504 may be necessary. When data is delivered over UDP, it is highly 2505 recommended that means such as RTCP be used to track packet loss 2506 rates. 2508 12.37 Server 2510 See [H14.39] 2512 12.38 Session 2514 The Session request-header and response-header field identifies an 2515 RTSP session started by the media server in a SETUP response and 2516 concluded by TEARDOWN on the presentation URL. The session 2517 identifier is chosen by the media server (see Section 3.4) and MUST 2518 be returned in the SETUP response. Once a client receives a Session 2519 identifier, it MUST return it for any request related to that 2520 session. 2522 Session _ "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ] 2524 The timeout parameter is only allowed in a response header. The 2525 server uses it to indicate to the client how long the server is 2526 prepared to wait between RTSP commands before closing the session due 2527 to lack of activity (see Section A). The timeout is measured in 2528 seconds, with a default of 60 seconds (1 minute). 2530 Note that a session identifier identifies an RTSP session across 2531 transport sessions or connections. Control messages for more than one 2532 RTSP URL may be sent within a single RTSP session. Hence, it is 2533 possible that clients use the same session for controlling many 2534 streams constituting a presentation, as long as all the streams come 2535 from the same server. (See example in Section 14). However, multiple 2536 "user" sessions for the same URL from the same client MUST use 2537 different session identifiers. 2539 The session identifier is needed to distinguish several 2540 delivery requests for the same URL coming from the same 2541 client. 2543 The response 454 (Session Not Found) is returned if the session 2544 identifier is invalid. 2546 12.39 Timestamp 2548 The Timestamp general-header field describes when the client sent 2549 the request to the server. The value of the timestamp is of 2550 significance only to the client and may use any timescale. The server 2551 MUST echo the exact same value and MAY, if it has accurate 2552 information about this, add a floating point number indicating the 2553 number of seconds that has elapsed since it has received the request. 2554 The timestamp is used by the client to compute the round-trip time to 2555 the server so that it can adjust the timeout value for 2556 retransmissions. 2558 Timestamp _ "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] 2559 delay _ *(DIGIT) [ "." *(DIGIT) ] 2561 12.40 Transport 2563 The Transport request-header field indicates which transport 2564 protocol is to be used and configures its parameters such as 2565 destination address, compression, multicast time-to-live and 2566 destination port for a single stream. It sets those values not 2567 already determined by a presentation description. 2569 Transports are comma separated, listed in order of preference. 2570 Parameters may be added to each transport, separated by a semicolon. 2572 The Transport header field MAY also be used to change certain 2573 transport parameters. A server MAY refuse to change parameters of an 2574 existing stream. 2576 The server MAY return a Transport response-header field in the 2577 response to indicate the values actually chosen. 2579 A Transport request header field may contain a list of transport 2580 options acceptable to the client, in the form of multiple transport- 2581 spec entries. In that case, the server MUST return a single option ( 2582 transport-spec) which was actually chosen. 2584 A transport-spec transport option may only contain one of any given 2585 parameter within it. Parameters may be given in any order. 2586 Additionally, it may only contain the unicast or multicast transport 2587 parameter. 2589 The Transport header field is restricted to describing a 2590 single RTP stream. (RTSP can also control multiple streams 2591 as a single entity.) Making it part of RTSP rather than 2592 relying on a multitude of session description formats 2593 greatly simplifies designs of firewalls. 2595 The syntax for the transport specifier is 2597 transport 2598 / 2599 profile 2600 / 2601 lower-transport 2603 The default value for the "lower-transport" parameters is specific to 2604 the profile. For RTP/AVP, the default is UDP. 2606 Below are the configuration parameters associated with transport: 2608 General parameters: 2610 unicast | multicast: This parameter is a mutually exclusive 2611 indication of whether unicast or multicast delivery will be 2612 attempted. One of the two values MUST be specified. Clients 2613 that are capable of handling both unicast and multicast 2614 transmission MUST indicate such capability by including two 2615 full transport-specs with separate parameters for each. 2617 destination: The address to which a stream will be sent. The 2618 client may specify the destination address with the 2619 destination parameter. To avoid becoming the unwitting 2620 perpetrator of a remote-controlled denial-of-service 2621 attack, a server SHOULD authenticate the client and SHOULD 2622 log such attempts before allowing the client to direct a 2623 media stream to an address not chosen by the server. This 2624 is particularly important if RTSP commands are issued via 2625 UDP, but implementations cannot rely on TCP as reliable 2626 means of client identification by itself. 2628 source: If the source address for the stream is different than 2629 can be derived from the RTSP endpoint address (the server 2630 in playback or the client in recording), the source address 2631 MAY be specified. 2633 This information may also be available through SDP. 2634 However, since this is more a feature of transport 2635 than media initialization, the authoritative source 2636 for this information should be in the SETUP response. 2638 layers: The number of multicast layers to be used for this media 2639 stream. The layers are sent to consecutive addresses 2640 starting at the destination address. 2642 mode: The mode parameter indicates the methods to be supported 2643 for this session. Valid values are PLAY and RECORD. If not 2644 provided, the default is PLAY. 2646 append: If the mode parameter includes RECORD, the append 2647 parameter indicates that the media data should append to 2648 the existing resource rather than overwrite it. If 2649 appending is requested and the server does not support 2650 this, it MUST refuse the request rather than overwrite the 2651 resource identified by the URI. The append parameter is 2652 ignored if the mode parameter does not contain RECORD. 2654 interleaved: The interleaved parameter implies mixing the media 2655 stream with the control stream in whatever protocol is 2656 being used by the control stream, using the mechanism 2657 defined in Section 10.12. The argument provides the channel 2658 number to be used in the $ statement. This parameter may be 2659 specified as a range, e.g., interleaved=4-5 in cases where 2660 the transport choice for the media stream requires it. 2662 This allows RTP/RTCP to be handled similarly to the 2663 way that it is done with UDP, i.e., one channel for 2664 RTP and the other for RTCP. 2666 Multicast-specific: 2668 ttl: multicast time-to-live. 2670 RTP-specific: 2672 port: This parameter provides the RTP/RTCP port pair for a 2673 multicast session. It is specified as a range, e.g., 2674 port=3456-3457 2676 client_port: This parameter provides the unicast RTP/RTCP port 2677 pair on the client where media data and control information 2678 is to be sent. It is specified as a range, e.g., 2679 port=3456-3457 2681 server_port: This parameter provides the unicast RTP/RTCP port 2682 pair on the server where media data and control information 2683 is to be sent. It is specified as a range, e.g., 2684 port=3456-3457 2686 ssrc: The ssrc parameter indicates the RTP SSRC [27] value that 2687 should be (request) or will be (response) used by the media 2688 server. This parameter is only valid for unicast 2689 transmission. It identifies the synchronization source to 2690 be associated with the media stream, and is expressed as an 2691 eight digit hexidecimal value. 2693 Transport ______________________________________________ "Transport" ":" 1#transport-spec 2694 transport-spec = transport-id *parameter 2695 transport-id = transport-protocol "/" profile ["/" lower-transport] 2696 ; no LWS is allowed inside transport-id 2697 transport-protocol = "RTP" | token 2698 profile = "AVP" | token 2699 lower-transport = "TCP" | "UDP" | token 2700 parameter = ";" ( "unicast" | "multicast" ) 2701 | ";" "source" [ "=" address ] 2702 | ";" "destination" [ "=" address ] 2703 | ";" "interleaved" "=" channel [ "-" channel ] 2704 | ";" "append" 2705 | ";" "ttl" "=" ttl 2706 | ";" "layers" "=" 1*DIGIT 2707 | ";" "port" "=" port [ "-" port ] 2708 | ";" "client_port" "=" port [ "-" port ] 2709 | ";" "server_port" "=" port [ "-" port ] 2710 | ";" "source" "=" address 2711 | ";" "ssrc" "=" ssrc 2712 | ";" "mode" "=" mode-spec 2713 ttl = 1*3(DIGIT) 2714 port = 1*5(DIGIT) 2715 ssrc = 8*8(HEX) 2716 channel = 1*3(DIGIT) 2717 address = host 2718 mode-spec = <"> 1#mode <"> | mode 2719 mode = "PLAY" | "RECORD" | token 2721 Below is a usage example, showing a client advertising the capability 2722 to handle multicast or unicast, preferring multicast. Since this is a 2723 unicast-only stream, the server responds with the proper transport 2724 parameters for unicast. 2726 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 2727 CSeq: 302 2728 Transport: RTP/AVP;multicast;mode="PLAY", 2729 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" 2731 S->C: RTSP/1.0 200 OK 2732 CSeq: 302 2733 Date: 23 Jan 1997 15:35:06 GMT 2734 Session: 47112344 2735 Transport: RTP/AVP;unicast;client_port=3456-3457; 2736 server_port=6256-6257;mode="PLAY" 2738 12.41 Unsupported 2740 The Unsupported response-header field lists the features not 2741 supported by the server. In the case where the feature was specified 2742 via the Proxy-Require field (Section 12.33), if there is a proxy on 2743 the path between the client and the server, the proxy MUST insert a 2744 response message with a status code of 551 (Option Not Supported). 2746 See Section 12.33 for a usage example. 2748 Unsupported _ "Unsupported" ":" 1#option-tag 2750 12.42 User-Agent 2752 See [H14.42] 2754 12.43 Vary 2756 See [H14.43] 2758 12.44 Via 2760 See [H14.44]. 2762 12.45 WWW-Authenticate 2764 See [H14.46]. 2766 13 Caching 2768 In HTTP, response-request pairs are cached. RTSP differs 2769 significantly in that respect. Responses are not cacheable, with the 2770 exception of the presentation description returned by DESCRIBE or 2771 included with ANNOUNCE. (Since the responses for anything but 2772 DESCRIBE and GET_PARAMETER do not return any data, caching is not 2773 really an issue for these requests.) However, it is desirable for the 2774 continuous media data, typically delivered out-of-band with respect 2775 to RTSP, to be cached, as well as the session description. 2777 On receiving a SETUP or PLAY request, a proxy ascertains whether it 2778 has an up-to-date copy of the continuous media content and its 2779 description. It can determine whether the copy is up-to-date by 2780 issuing a SETUP or DESCRIBE request, respectively, and comparing 2781 the Last-Modified header with that of the cached copy. If the copy 2782 is not up-to-date, it modifies the SETUP transport parameters as 2783 appropriate and forwards the request to the origin server. Subsequent 2784 control commands such as PLAY or PAUSE then pass the proxy 2785 unmodified. The proxy delivers the continuous media data to the 2786 client, while possibly making a local copy for later reuse. The exact 2787 behavior allowed to the cache is given by the cache-response 2788 directives described in Section 12.9. A cache MUST answer any 2789 DESCRIBE requests if it is currently serving the stream to the 2790 requestor, as it is possible that low-level details of the stream 2791 description may have changed on the origin-server. 2793 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 2794 through" variety. Rather than retrieving the whole resource from the 2795 origin server, the cache simply copies the streaming data as it 2796 passes by on its way to the client. Thus, it does not introduce 2797 additional latency. 2799 To the client, an RTSP proxy cache appears like a regular media 2800 server, to the media origin server like a client. Just as an HTTP 2801 cache has to store the content type, content language, and so on for 2802 the objects it caches, a media cache has to store the presentation 2803 description. Typically, a cache eliminates all transport-references 2804 (that is, multicast information) from the presentation description, 2805 since these are independent of the data delivery from the cache to 2806 the client. Information on the encodings remains the same. If the 2807 cache is able to translate the cached media data, it would create a 2808 new presentation description with all the encoding possibilities it 2809 can offer. 2811 14 Examples 2813 The following examples refer to stream description formats that are 2814 not standards, such as RTSL. The following examples are not to be 2815 used as a reference for those formats. 2817 14.1 Media on Demand (Unicast) 2818 Client C requests a movie from media servers A ( audio.example.com ) 2819 and V ( video.example.com ). The media description is stored on a web 2820 server W. The media description contains descriptions of the 2821 presentation and all its streams, including the codecs that are 2822 available, dynamic RTP payload types, the protocol stack, and content 2823 information such as language or copyright restrictions. It may also 2824 give an indication about the timeline of the movie. 2826 In this example, the client is only interested in the last part of 2827 the movie. 2829 C->W: GET /twister.sdp HTTP/1.1 2830 Host: www.example.com 2831 Accept: application/sdp 2833 W->C: HTTP/1.0 200 OK 2834 Content-Type: application/sdp 2836 v=0 2837 o=- 2890844526 2890842807 IN IP4 192.16.24.202 2838 s=RTSP Session 2839 m=audio 0 RTP/AVP 0 2840 a=control:rtsp://audio.example.com/twister/audio.en 2841 m=video 0 RTP/AVP 31 2842 a=control:rtsp://video.example.com/twister/video 2844 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 2845 CSeq: 1 2846 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 2848 A->C: RTSP/1.0 200 OK 2849 CSeq: 1 2850 Session: 12345678 2851 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; 2852 server_port=5000-5001 2854 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 2855 CSeq: 1 2856 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 2858 V->C: RTSP/1.0 200 OK 2859 CSeq: 1 2860 Session: 23456789 2861 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; 2862 server_port=5002-5003 2864 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 2865 CSeq: 2 2866 Session: 23456789 2867 Range: smpte=0:10:00- 2869 V->C: RTSP/1.0 200 OK 2870 CSeq: 2 2871 Session: 23456789 2872 Range: smpte=0:10:00-0:20:00 2873 RTP-Info: url=rtsp://video.example.com/twister/video; 2874 seq=12312232;rtptime=78712811 2876 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 2877 CSeq: 2 2878 Session: 12345678 2879 Range: smpte=0:10:00- 2881 A->C: RTSP/1.0 200 OK 2882 CSeq: 2 2883 Session: 12345678 2884 Range: smpte=0:10:00-0:20:00 2885 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; 2886 seq=876655;rtptime=1032181 2888 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 2889 CSeq: 3 2890 Session: 12345678 2892 A->C: RTSP/1.0 200 OK 2893 CSeq: 3 2895 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 2896 CSeq: 3 2897 Session: 23456789 2899 V->C: RTSP/1.0 200 OK 2900 CSeq: 3 2902 Even though the audio and video track are on two different servers, 2903 and may start at slightly different times and may drift with respect 2904 to each other, the client can synchronize the two using standard RTP 2905 methods, in particular the time scale contained in the RTCP sender 2906 reports. 2908 14.2 Streaming of a Container file 2910 For purposes of this example, a container file is a storage entity in 2911 which multiple continuous media types pertaining to the same end-user 2912 presentation are present. In effect, the container file represents an 2913 RTSP presentation, with each of its components being RTSP streams. 2914 Container files are a widely used means to store such presentations. 2915 While the components are transported as independent streams, it is 2916 desirable to maintain a common context for those streams at the 2917 server end. 2919 This enables the server to keep a single storage handle 2920 open easily. It also allows treating all the streams 2921 equally in case of any prioritization of streams by the 2922 server. 2924 It is also possible that the presentation author may wish to prevent 2925 selective retrieval of the streams by the client in order to preserve 2926 the artistic effect of the combined media presentation. Similarly, in 2927 such a tightly bound presentation, it is desirable to be able to 2928 control all the streams via a single control message using an 2929 aggregate URL. 2931 The following is an example of using a single RTSP session to control 2932 multiple streams. It also illustrates the use of aggregate URLs. 2934 Client C requests a presentation from media server M. The movie is 2935 stored in a container file. The client has obtained an RTSP URL to 2936 the container file. 2938 C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 2939 CSeq: 1 2941 M->C: RTSP/1.0 200 OK 2942 CSeq: 1 2943 Content-Type: application/sdp 2944 Content-Length: 164 2946 v=0 2947 o=- 2890844256 2890842807 IN IP4 172.16.2.93 2948 s=RTSP Session 2949 i=An Example of RTSP Session Usage 2950 a=control:rtsp://foo/twister 2951 t=0 0 2952 m=audio 0 RTP/AVP 0 2953 a=control:rtsp://foo/twister/audio 2954 m=video 0 RTP/AVP 26 2955 a=control:rtsp://foo/twister/video 2957 C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 2958 CSeq: 2 2959 Transport: RTP/AVP;unicast;client_port=8000-8001 2961 M->C: RTSP/1.0 200 OK 2962 CSeq: 2 2963 Transport: RTP/AVP;unicast;client_port=8000-8001; 2964 server_port=9000-9001 2965 Session: 12345678 2967 C->M: SETUP rtsp://foo/twister/video RTSP/1.0 2968 CSeq: 3 2969 Transport: RTP/AVP;unicast;client_port=8002-8003 2970 Session: 12345678 2972 M->C: RTSP/1.0 200 OK 2973 CSeq: 3 2974 Transport: RTP/AVP;unicast;client_port=8002-8003; 2975 server_port=9004-9005 2976 Session: 12345678 2978 C->M: PLAY rtsp://foo/twister RTSP/1.0 2979 CSeq: 4 2980 Range: npt=0- 2981 Session: 12345678 2983 M->C: RTSP/1.0 200 OK 2984 CSeq: 4 2985 Session: 12345678 2986 RTP-Info: url=rtsp://foo/twister/video; 2987 seq=9810092;rtptime=3450012 2989 C->M: PAUSE rtsp://foo/twister/video RTSP/1.0 2990 CSeq: 5 2991 Session: 12345678 2993 M->C: RTSP/1.0 460 Only aggregate operation allowed 2994 CSeq: 5 2996 C->M: PAUSE rtsp://foo/twister RTSP/1.0 2997 CSeq: 6 2998 Session: 12345678 3000 M->C: RTSP/1.0 200 OK 3001 CSeq: 6 3002 Session: 12345678 3004 C->M: SETUP rtsp://foo/twister RTSP/1.0 3005 CSeq: 7 3006 Transport: RTP/AVP;unicast;client_port=10000 3008 M->C: RTSP/1.0 459 Aggregate operation not allowed 3009 CSeq: 7 3011 In the first instance of failure, the client tries to pause one 3012 stream (in this case video) of the presentation. This is disallowed 3013 for that presentation by the server. In the second instance, the 3014 aggregate URL may not be used for SETUP and one control message is 3015 required per stream to set up transport parameters. 3017 This keeps the syntax of the Transport header simple and 3018 allows easy parsing of transport information by firewalls. 3020 14.3 Single Stream Container Files 3022 Some RTSP servers may treat all files as though they are "container 3023 files", yet other servers may not support such a concept. Because of 3024 this, clients SHOULD use the rules set forth in the session 3025 description for request URLs, rather than assuming that a consistent 3026 URL may always be used throughout. Here's an example of how a multi- 3027 stream server might expect a single-stream file to be served: 3029 C->S DESCRIBE rtsp://foo.com/test.wav RTSP/1.0 3030 Accept: application/x-rtsp-mh, application/sdp 3031 CSeq: 1 3033 S->C RTSP/1.0 200 OK 3034 CSeq: 1 3035 Content-base: rtsp://foo.com/test.wav/ 3036 Content-type: application/sdp 3037 Content-length: 48 3039 v=0 3040 o=- 872653257 872653257 IN IP4 172.16.2.187 3041 s=mu-law wave file 3042 i=audio test 3043 t=0 0 3044 m=audio 0 RTP/AVP 0 3045 a=control:streamid=0 3047 C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 3048 Transport: RTP/AVP/UDP;unicast; 3049 client_port=6970-6971;mode="PLAY" 3050 CSeq: 2 3052 S->C RTSP/1.0 200 OK 3053 Transport: RTP/AVP/UDP;unicast;client_port=6970-6971; 3054 server_port=6970-6971;mode="PLAY" 3055 CSeq: 2 3056 Session: 2034820394 3058 C->S PLAY rtsp://foo.com/test.wav RTSP/1.0 3059 CSeq: 3 3060 Session: 2034820394 3062 S->C RTSP/1.0 200 OK 3063 CSeq: 3 3064 Session: 2034820394 3065 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; 3066 seq=981888;rtptime=3781123 3068 Note the different URL in the SETUP command, and then the switch 3069 back to the aggregate URL in the PLAY command. This makes complete 3070 sense when there are multiple streams with aggregate control, but is 3071 less than intuitive in the special case where the number of streams 3072 is one. 3074 In this special case, it is recommended that servers be forgiving of 3075 implementations that send: 3077 C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0 3078 CSeq: 3 3080 In the worst case, servers should send back: 3082 S->C RTSP/1.0 460 Only aggregate operation allowed 3083 CSeq: 3 3085 One would also hope that server implementations are also forgiving of 3086 the following: 3088 C->S SETUP rtsp://foo.com/test.wav RTSP/1.0 3089 Transport: rtp/avp/udp;client_port=6970-6971;mode="PLAY" 3090 CSeq: 2 3092 Since there is only a single stream in this file, it's not ambiguous 3093 what this means. 3095 14.4 Live Media Presentation Using Multicast 3097 The media server M chooses the multicast address and port. Here, we 3098 assume that the web server only contains a pointer to the full 3099 description, while the media server M maintains the full description. 3101 C->W: GET /concert.sdp HTTP/1.1 3102 Host: www.example.com 3104 W->C: HTTP/1.1 200 OK 3105 Content-Type: application/x-rtsl 3107 3108 3109 3111 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0 3112 CSeq: 1 3114 M->C: RTSP/1.0 200 OK 3115 CSeq: 1 3116 Content-Type: application/sdp 3117 Content-Length: 44 3119 v=0 3120 o=- 2890844526 2890842807 IN IP4 192.16.24.202 3121 s=RTSP Session 3122 m=audio 3456 RTP/AVP 0 3123 c=IN IP4 224.2.0.1/16 3124 a=control:rtsp://live.example.com/concert/audio 3126 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0 3127 CSeq: 2 3128 Transport: RTP/AVP;multicast 3130 M->C: RTSP/1.0 200 OK 3131 CSeq: 2 3132 Transport: RTP/AVP;multicast;destination=224.2.0.1; 3133 port=3456-3457;ttl=16 3134 Session: 0456804596 3136 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 3137 CSeq: 3 3138 Session: 0456804596 3140 M->C: RTSP/1.0 200 OK 3141 CSeq: 3 3142 Session: 0456804596 3144 14.5 Playing media into an existing session 3146 A conference participant C wants to have the media server M play back 3147 a demo tape into an existing conference. C indicates to the media 3148 server that the network addresses and encryption keys are already 3149 given by the conference, so they should not be chosen by the server. 3150 The example omits the simple ACK responses. 3152 C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0 3153 CSeq: 1 3154 Accept: application/sdp 3156 M->C: RTSP/1.0 200 1 OK 3157 Content-type: application/sdp 3158 Content-Length: 44 3160 v=0 3161 o=- 2890844526 2890842807 IN IP4 192.16.24.202 3162 s=RTSP Session 3163 i=See above 3164 t=0 0 3165 m=audio 0 RTP/AVP 0 3167 C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 3168 CSeq: 2 3169 Transport: RTP/AVP;multicast;destination=225.219.201.15; 3170 port=7000-7001;ttl=127 3171 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 3173 M->C: RTSP/1.0 200 OK 3174 CSeq: 2 3175 Transport: RTP/AVP;multicast;destination=225.219.201.15; 3176 port=7000-7001;ttl=127 3177 Session: 91389234234 3178 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 3180 C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 3181 CSeq: 3 3182 Session: 91389234234 3184 M->C: RTSP/1.0 200 OK 3185 CSeq: 3 3187 14.6 Recording 3189 The conference participant client C asks the media server M to record 3190 the audio and video portions of a meeting. The client uses the 3191 ANNOUNCE method to provide meta-information about the recorded 3192 session to the server. 3194 C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 3195 CSeq: 90 3196 Content-Type: application/sdp 3197 Content-Length: 121 3199 v=0 3200 o=camera1 3080117314 3080118787 IN IP4 195.27.192.36 3201 s=IETF Meeting, Munich - 1 3202 i=The thirty-ninth IETF meeting will be held in Munich, Germany 3203 u=http://www.ietf.org/meetings/Munich.html 3204 e=IETF Channel 1 3205 p=IETF Channel 1 +49-172-2312 451 3206 c=IN IP4 224.0.1.11/127 3207 t=3080271600 3080703600 3208 a=tool:sdr v2.4a6 3209 a=type:test 3210 m=audio 21010 RTP/AVP 5 3211 c=IN IP4 224.0.1.11/127 3212 a=ptime:40 3213 m=video 61010 RTP/AVP 31 3214 c=IN IP4 224.0.1.12/127 3216 M->C: RTSP/1.0 200 OK 3217 CSeq: 90 3219 C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0 3220 CSeq: 91 3221 Transport: RTP/AVP;multicast;destination=224.0.1.11; 3222 port=21010-21011;mode=record;ttl=127 3224 M->C: RTSP/1.0 200 OK 3225 CSeq: 91 3226 Session: 50887676 3227 Transport: RTP/AVP;multicast;destination=224.0.1.11; 3228 port=21010-21011;mode=record;ttl=127 3230 C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0 3231 CSeq: 92 3232 Session: 50887676 3233 Transport: RTP/AVP;multicast;destination=224.0.1.12; 3234 port=61010-61011;mode=record;ttl=127 3236 M->C: RTSP/1.0 200 OK 3237 CSeq: 92 3238 Transport: RTP/AVP;multicast;destination=224.0.1.12; 3239 port=61010-61011;mode=record;ttl=127 3241 C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0 3242 CSeq: 93 3243 Session: 50887676 3244 Range: clock=19961110T1925-19961110T2015 3246 M->C: RTSP/1.0 200 OK 3247 CSeq: 93 3249 15 Syntax 3251 The RTSP syntax is described in an augmented Backus-Naur form (BNF) 3252 as used in RFC 2068 [2]. 3254 15.1 Base Syntax 3256 OCTET ____________________________ 3257 CHAR ____________________________ 3258 UPALPHA ____________________________ 3259 LOALPHA ____________________________ 3260 ALPHA ____________________________ UPALPHA | LOALPHA 3261 DIGIT ____________________________ 3262 CTL ____________________________ 3264 CR ____________________________ 3265 LF ____________________________ 3266 SP ____________________________ 3267 HT ____________________________ 3268 <"> ____________________________ 3269 CRLF ____________________________ CR LF 3270 LWS ____________________________ [CRLF] 1*( SP | HT ) 3271 TEXT ____________________________ 3272 tspecials ____________________________ "(" | ")" | "<" | ">" | "@" 3273 | "," | ";" | ":" | " 3274 \&\h'|\n(40u'\h'|\n(41u'\h'|\n(42u' 3275 " | <"> 3276 | "/" | "[" | "]" | "?" | "=" 3277 | "{" | "}" | SP | HT 3278 token ____________________________ 1* 3279 quoted-string ____________________________ ( <"> *(qdtext) <"> ) 3280 qdtext ____________________________ > 3281 quoted-pair ____________________________ " 3282 \&\h'|\n(40u'\h'|\n(41u'\h'|\n(42u' 3283 " CHAR 3284 message-header ____________________________ field-name ":" [ field-value ] CRLF 3285 field-name ____________________________ token 3286 field-value ____________________________ *( field-content | LWS ) 3287 field-content ____________________________ 3291 safe ____________________________ "$" | "-" | "_" | "." | "+" 3292 extra ____________________________ "!" | "*" | "'" | "(" | ")" | "," 3293 hex ____________________________ DIGIT | "A" | "B" | "C" | "D" | "E" | "F" | 3294 "a" | "b" | "c" | "d" | "e" | "f" 3295 escape ____________________________ "%" hex hex 3296 reserved ____________________________ ";" | "/" | "?" | ":" | "@" | "&" | "=" 3297 unreserved ____________________________ alpha | digit | safe | extra 3298 xchar ____________________________ unreserved | reserved | escape 3300 16 Security Considerations 3302 Because of the similarity in syntax and usage between RTSP servers 3303 and HTTP servers, the security considerations outlined in [H15] 3304 apply. Specifically, please note the following: 3306 Authentication Mechanisms: RTSP and HTTP share common 3307 authentication schemes, and thus should follow the same 3308 prescriptions with regards to authentication. See [H15.1] 3309 for client authentication issues, and [H15.2] for issues 3310 regarding support for multiple authentication mechanisms. 3312 Abuse of Server Log Information: RTSP and HTTP servers will 3313 presumably have similar logging mechanisms, and thus should 3314 be equally guarded in protecting the contents of those 3315 logs, thus protecting the privacy of the users of the 3316 servers. See [H15.3] for HTTP server recommendations 3317 regarding server logs. 3319 Transfer of Sensitive Information: There is no reason to believe 3320 that information transferred via RTSP may be any less 3321 sensitive than that normally transmitted via HTTP. 3322 Therefore, all of the precautions regarding the protection 3323 of data privacy and user privacy apply to implementors of 3324 RTSP clients, servers, and proxies. See [H15.4] for further 3325 details. 3327 Attacks Based On File and Path Names: Though RTSP URLs are 3328 opaque handles that do not necessarily have file system 3329 semantics, it is anticipated that many implementations will 3330 translate portions of the request URLs directly to file 3331 system calls. In such cases, file systems SHOULD follow the 3332 precautions outlined in [H15.5], such as checking for ".." 3333 in path components. 3335 Personal Information: RTSP clients are often privy to the same 3336 information that HTTP clients are (user name, location, 3337 etc.) and thus should be equally. See [H15.6] for further 3338 recommendations. 3340 Privacy Issues Connected to Accept Headers: Since may of the 3341 same "Accept" headers exist in RTSP as in HTTP, the same 3342 caveats outlined in [H15.7] with regards to their use 3343 should be followed. 3345 DNS Spoofing: Presumably, given the longer connection times 3346 typically associated to RTSP sessions relative to HTTP 3347 sessions, RTSP client DNS optimizations should be less 3348 prevalent. Nonetheless, the recommendations provided in 3349 [H15.8] are still relevant to any implementation which 3350 attempts to rely on a DNS-to-IP mapping to hold beyond a 3351 single use of the mapping. 3353 Location Headers and Spoofing: If a single server supports 3354 multiple organizations that do not trust one another, then 3355 it must check the values of Location and Content-Location 3356 header fields in responses that are generated under control 3357 of said organizations to make sure that they do not attempt 3358 to invalidate resources over which they have no authority. 3359 ([H15.9]) 3361 In addition to the recommendations in the current HTTP specification 3362 (RFC 2068 [2], as of this writing), future HTTP specifications may 3363 provide additional guidance on security issues. 3365 The following are added considerations for RTSP implementations. 3367 Concentrated denial-of-service attack: The protocol offers the 3368 opportunity for a remote-controlled denial-of-service 3369 attack. 3371 The attacker may initiate traffic flows to one or more IP 3372 addresses by specifying them as the destination in SETUP 3373 requests. While the attacker's IP address may be known in 3374 this case, this is not always useful in prevention of more 3375 attacks or ascertaining the attackers identity. Thus, an 3376 RTSP server SHOULD only allow client-specified destinations 3377 for RTSP-initiated traffic flows if the server has verified 3378 the client's identity, either against a database of known 3379 users using RTSP authentication mechanisms (preferably 3380 digest authentication or stronger), or other secure means. 3382 Session hijacking: Since there is no relation between a 3383 transport layer connection and an RTSP session, it is 3384 possible for a malicious client to issue requests with 3385 random session identifiers which would affect unsuspecting 3386 clients. The server SHOULD use a large, random and non- 3387 sequential session identifier to minimize the possibility 3388 of this kind of attack. 3390 Authentication: Servers SHOULD implement both basic and digest 3391 [8] authentication. In environments requiring tighter 3392 security for the control messages, transport layer 3393 mechanisms such as TLS (RFC 2246 [7]) SHOULD be used. 3395 Stream issues: RTSP only provides for stream control. Stream 3396 delivery issues are not covered in this section, nor in the 3397 rest of this draft. RTSP implementations will most likely 3398 rely on other protocols such as RTP, IP multicast, RSVP and 3399 IGMP, and should address security considerations brought up 3400 in those and other applicable specifications. 3402 Persistently suspicious behavior: RTSP servers SHOULD return 3403 error code 403 (Forbidden) upon receiving a single instance 3404 of behavior which is deemed a security risk. RTSP servers 3405 SHOULD also be aware of attempts to probe the server for 3406 weaknesses and entry points and MAY arbitrarily disconnect 3407 and ignore further requests clients which are deemed to be 3408 in violation of local security policy. 3410 A RTSP Protocol State Machines 3412 The RTSP client and server state machines describe the behavior of 3413 the protocol from RTSP session initialization through RTSP session 3414 termination. 3416 State is defined on a per object basis. An object is uniquely 3417 identified by the stream URL and the RTSP session identifier. Any 3418 request/reply using aggregate URLs denoting RTSP presentations 3419 composed of multiple streams will have an effect on the individual 3420 states of all the streams. For example, if the presentation /movie 3421 contains two streams, /movie/audio and /movie/video , then the 3422 following command: 3424 PLAY rtsp://foo.com/movie RTSP/1.0 3425 CSeq: 559 3426 Session: 12345678 3428 will have an effect on the states of movie/audio and movie/video 3430 This example does not imply a standard way to represent 3431 streams in URLs or a relation to the filesystem. See 3432 Section 3.2. 3434 The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, 3435 SET_PARAMETER do not have any effect on client or server state and 3436 are therefore not listed in the state tables. 3438 A.1 Client State Machine 3440 The client can assume the following states: 3442 Init : SETUP has been sent, waiting for reply. 3444 Ready : SETUP reply received or PAUSE reply received while in 3445 Playing state. 3447 Playing : PLAY reply received 3449 Recording : RECORD reply received 3451 In general, the client changes state on receipt of replies to 3452 requests. Note that some requests are effective at a future time or 3453 position (such as a PAUSE), and state also changes accordingly. If 3454 no explicit SETUP is required for the object (for example, it is 3455 available via a multicast group), state begins at Ready are only two 3456 states, Ready and Playing The client also changes state from 3457 Playing/Recording to Ready when the end of the requested range is 3458 reached. 3460 The "next state" column indicates the state assumed after receiving a 3461 success response (2xx). If a request yields a status code of 3xx, the 3462 state becomes Init , and a status code of 4xx yields no change in 3463 state. Messages not listed for each state MUST NOT be issued by the 3464 client in that state, with the exception of messages not affecting 3465 state, as listed above. Receiving a REDIRECT from the server is 3466 equivalent to receiving a 3xx redirect status from the server. 3468 state message sent next state after response 3469 ____________________________________________________________ 3470 Init SETUP 3471 Ready 3472 TEARDOWN 3473 Init 3474 Ready PLAY 3475 Playing 3476 RECORD 3477 Recording 3478 TEARDOWN 3479 Init 3480 SETUP 3481 Ready 3482 Playing PAUSE 3483 Ready 3484 TEARDOWN 3485 Init 3486 PLAY 3487 Playing 3488 SETUP 3489 Playing 3490 (changed transport) 3491 Recording PAUSE 3492 Ready 3493 TEARDOWN 3494 Init 3495 RECORD 3496 Recording 3497 SETUP 3498 Recording 3499 (changed transport) 3501 A.2 Server State Machine 3503 The server can assume the following states: 3505 Init : The initial state, no valid SETUP has been received yet. 3507 Ready : Last SETUP received was successful, reply sent or after 3508 playing, last PAUSE received was successful, reply sent. 3510 Playing : Last PLAY received was successful, reply sent. Data 3511 is being sent. 3513 Recording : The server is recording media data. 3515 In general, the server changes state on receiving requests. If the 3516 server is in state Playing or Recording and in unicast mode, it MAY 3517 revert to Init and tear down the RTSP session if it has not received 3518 "wellness" information, such as RTCP reports or RTSP commands, from 3519 the client for a defined interval, with a default of one minute. The 3520 server can declare another timeout value in the Session response 3521 header (Section 12.38). If the server is in state Ready , it MAY 3522 revert to Init if it does not receive an RTSP request for an interval 3523 of more than one minute. Note that some requests (such as PAUSE) may 3524 be effective at a future time or position, and server state changes 3525 at the appropriate time. The server reverts from state Playing or 3526 Recording to state Ready at the end of the range requested by the 3527 client. 3529 The REDIRECT message, when sent, is effective immediately unless it 3530 has a Range header specifying when the redirect is effective. In 3531 such a case, server state will also change at the appropriate time. 3533 If no explicit SETUP is required for the object, the state starts at 3534 Ready and there are only two states, Ready and Playing 3536 The "next state" column indicates the state assumed after sending a 3537 success response (2xx). If a request results in a status code of 3xx, 3538 the state becomes Init change. 3540 state message received next state 3541 _______________________________________ 3542 Init 3543 SETUP 3544 Ready 3545 TEARDOWN 3546 Init 3547 Ready 3548 PLAY 3549 Playing 3550 SETUP 3551 Ready 3552 TEARDOWN 3553 Init 3554 RECORD 3555 Recording 3556 Playing 3557 PLAY 3558 Playing 3559 PAUSE 3560 Ready 3561 TEARDOWN 3562 Init 3563 SETUP 3564 Playing 3565 Recording 3566 RECORD 3567 Recording 3568 PAUSE 3569 Ready 3570 TEARDOWN 3571 Init 3572 SETUP 3573 Recording 3575 B Interaction with RTP 3577 RTSP allows media clients to control selected, non-contiguous 3578 sections of media presentations, rendering those streams with an RTP 3579 media layer[27]. The media layer rendering the RTP stream should not 3580 be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP 3581 timestamps MUST be continuous and monotonic across jumps of NPT. 3583 As an example, assume a clock frequency of 8000 Hz, a packetization 3584 interval of 100 ms and an initial sequence number and timestamp of 3585 zero. First we play NPT 10 through 15, then skip ahead and play NPT 3586 18 through 20. The first segment is presented as RTP packets with 3587 sequence numbers 0 through 49 and timestamp 0 through 39,200. The 3588 second segment consists of RTP packets with sequence number 50 3589 through 69, with timestamps 40,000 through 55,200. 3591 We cannot assume that the RTSP client can communicate with 3592 the RTP media agent, as the two may be independent 3593 processes. If the RTP timestamp shows the same gap as the 3594 NPT, the media agent will assume that there is a pause in 3595 the presentation. If the jump in NPT is large enough, the 3596 RTP timestamp may roll over and the media agent may believe 3597 later packets to be duplicates of packets just played out. 3599 For certain datatypes, tight integration between the RTSP layer and 3600 the RTP layer will be necessary. This by no means precludes the above 3601 restriction. Combined RTSP/RTP media clients should use the RTP-Info 3602 field to determine whether incoming RTP packets were sent before or 3603 after a seek. 3605 For continuous audio, the server SHOULD set the RTP marker bit at the 3606 beginning of serving a new PLAY request. This allows the client to 3607 perform playout delay adaptation. 3609 For scaling (see Section 12.35), RTP timestamps should correspond to 3610 the playback timing. For example, when playing video recorded at 30 3611 frames/second at a scale of two and speed (Section 12.36) of one, the 3612 server would drop every second frame to maintain and deliver video 3613 packets with the normal timestamp spacing of 3,000 per frame, but NPT 3614 would increase by 1/15 second for each video frame. 3616 The client can maintain a correct display of NPT by noting the RTP 3617 timestamp value of the first packet arriving after repositioning. The 3618 sequence parameter of the RTP-Info (Section 12.34) header provides 3619 the first sequence number of the next segment. 3621 C Use of SDP for RTSP Session Descriptions 3623 The Session Description Protocol (SDP, RFC 2327 [6]) may be used to 3624 describe streams or presentations in RTSP. Such usage is limited to 3625 specifying means of access and encoding(s) for: 3627 aggregate control: A presentation composed of streams from one 3628 or more servers that are available for aggregate control. 3629 Such a description is typically retrieved by HTTP or other 3630 non-RTSP means. However, they may be received with 3631 ANNOUNCE methods. 3633 non-aggregate control: A presentation composed of multiple 3634 streams from a single server that are not available for 3635 aggregate control. Such a description is typically 3636 returned in reply to a DESCRIBE request on a URL, or 3637 received in an ANNOUNCE method. 3639 This appendix describes how an SDP file, retrieved, for example, 3640 through HTTP, determines the operation of an RTSP session. It also 3641 describes how a client should interpret SDP content returned in reply 3642 to a DESCRIBE request. SDP provides no mechanism by which a client 3643 can distinguish, without human guidance, between several media 3644 streams to be rendered simultaneously and a set of alternatives 3645 (e.g., two audio streams spoken in different languages). 3647 C.1 Definitions 3649 The terms "session-level", "media-level" and other key/attribute 3650 names and values used in this appendix are to be used as defined in 3651 SDP (RFC 2327 [6]): 3653 C.1.1 Control URL 3655 The "a=control:" attribute is used to convey the control URL. This 3656 attribute is used both for the session and media descriptions. If 3657 used for individual media, it indicates the URL to be used for 3658 controlling that particular media stream. If found at the session 3659 level, the attribute indicates the URL for aggregate control. 3661 Example: 3663 a=control:rtsp://example.com/foo 3665 This attribute may contain either relative and absolute URLs, 3666 following the rules and conventions set out in RFC 1808 [28]. 3667 Implementations should look for a base URL in the following order: 3669 1. the RTSP Content-Base field; 3671 2. the RTSP Content-Location field; 3673 3. the RTSP request URL. 3675 If this attribute contains only an asterisk (*), then the URL is 3676 treated as if it were an empty embedded URL, and thus inherits the 3677 entire base URL. 3679 C.1.2 Media Streams 3681 The "m=" field is used to enumerate the streams. It is expected that 3682 all the specified streams will be rendered with appropriate 3683 synchronization. If the session is unicast, the port number serves as 3684 a recommendation from the server to the client; the client still has 3685 to include it in its SETUP request and may ignore this 3686 recommendation. If the server has no preference, it SHOULD set the 3687 port number value to zero. 3689 Example: 3691 m=audio 0 RTP/AVP 31 3693 C.1.3 Payload Type(s) 3695 The payload type(s) are specified in the "m=" field. In case the 3696 payload type is a static payload type from RFC 1890 [1], no other 3697 information is required. In case it is a dynamic payload type, the 3698 media attribute "rtpmap" is used to specify what the media is. The 3699 "encoding name" within the "rtpmap" attribute may be one of those 3700 specified in RFC 1890 (Sections 5 and 6), or an experimental encoding 3701 with a "X-" prefix as specified in SDP (RFC 2327 [6]). Codec-specific 3702 parameters are not specified in this field, but rather in the "fmtp" 3703 attribute described below. Implementors seeking to register new 3704 encodings should follow the procedure in RFC 1890 [1]. If the media 3705 type is not suited to the RTP AV profile, then it is recommended that 3706 a new profile be created and the appropriate profile name be used in 3707 lieu of "RTP/AVP" in the "m=" field. 3709 C.1.4 Format-Specific Parameters 3711 Format-specific parameters are conveyed using the "fmtp" media 3712 attribute. The syntax of the "fmtp" attribute is specific to the 3713 encoding(s) that the attribute refers to. Note that the packetization 3714 interval is conveyed using the "ptime" attribute. 3716 C.1.5 Range of Presentation 3718 The "a=range" attribute defines the total time range of the stored 3719 session. (The length of live sessions can be deduced from the "t" and 3720 "r" parameters.) Unless the presentation contains media streams of 3721 different durations, the length attribute is a session-level 3722 attribute. The unit is specified first, followed by the value range. 3723 The units and their values are as defined in Section 3.5, 3.6 and 3724 3.7. 3726 Examples: 3728 a=range:npt=0-34.4368 3729 a=range:clock=19971113T2115-19971113T2203 3731 C.1.6 Time of Availability 3732 The "t=" field MUST contain suitable values for the start and stop 3733 times for both aggregate and non-aggregate stream control. With 3734 aggregate control, the server SHOULD indicate a stop time value for 3735 which it guarantees the description to be valid, and a start time 3736 that is equal to or before the time at which the DESCRIBE request was 3737 received. It MAY also indicate start and stop times of 0, meaning 3738 that the session is always available. With non-aggregate control, the 3739 values should reflect the actual period for which the session is 3740 available in keeping with SDP semantics, and not depend on other 3741 means (such as the life of the web page containing the description) 3742 for this purpose. 3744 C.1.7 Connection Information 3746 In SDP, the "c=" field contains the destination address for the media 3747 stream. However, for on-demand unicast streams and some multicast 3748 streams, the destination address is specified by the client via the 3749 SETUP request. Unless the media content has a fixed destination 3750 address, the "c=" field is to be set to a suitable null value. For 3751 addresses of type "IP4", this value is "0.0.0.0". 3753 C.1.8 Entity Tag 3755 The optional "a=etag" attribute identifies a version of the session 3756 description. It is opaque to the client. SETUP requests may include 3757 this identifier in the If-Match field (see section 12.23) to only 3758 allow session establishment if this attribute value still corresponds 3759 to that of the current description. The attribute value is opaque 3760 and may contain any character allowed within SDP attribute values. 3762 Example: 3764 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 3766 One could argue that the "o=" field provides identical 3767 functionality. However, it does so in a manner that would 3768 put constraints on servers that need to support multiple 3769 session description types other than SDP for the same piece 3770 of media content. 3772 C.2 Aggregate Control Not Available 3774 If a presentation does not support aggregate control and multiple 3775 media sections are specified, each section MUST have the control URL 3776 specified via the "a=control:" attribute. 3778 Example: 3780 v=0 3781 o=- 2890844256 2890842807 IN IP4 204.34.34.32 3782 s=I came from a web page 3783 c=IN IP4 0.0.0.0 3784 t=0 0 3785 m=video 8002 RTP/AVP 31 3786 a=control:rtsp://audio.com/movie.aud 3787 m=audio 8004 RTP/AVP 3 3788 a=control:rtsp://video.com/movie.vid 3790 Note that the position of the control URL in the description implies 3791 that the client establishes separate RTSP control sessions to the 3792 servers audio.com and video.com 3794 It is recommended that an SDP file contains the complete media 3795 initialization information even if it is delivered to the media 3796 client through non-RTSP means. This is necessary as there is no 3797 mechanism to indicate that the client should request more detailed 3798 media stream information via DESCRIBE. 3800 C.3 Aggregate Control Available 3802 In this scenario, the server has multiple streams that can be 3803 controlled as a whole. In this case, there are both a media-level 3804 "a=control:" attributes, which are used to specify the stream URLs, 3805 and a session-level "a=control:" attribute which is used as the 3806 request URL for aggregate control. If the media-level URL is 3807 relative, it is resolved to absolute URLs according to Section C.1.1 3808 above. 3810 If the presentation comprises only a single stream, the media-level 3811 "a=control:" attribute may be omitted altogether. However, if the 3812 presentation contains more than one stream, each media stream section 3813 MUST contain its own "a=control" attribute. 3815 Example: 3817 v=0 3818 o=- 2890844256 2890842807 IN IP4 204.34.34.32 3819 s=I contain 3820 i= 3821 c=IN IP4 0.0.0.0 3822 t=0 0 3823 a=control:rtsp://example.com/movie/ 3824 m=video 8002 RTP/AVP 31 3825 a=control:trackID=1 3826 m=audio 8004 RTP/AVP 3 3827 a=control:trackID=2 3829 In this example, the client is required to establish a single RTSP 3830 session to the server, and uses the URLs 3831 rtsp://example.com/movie/trackID=1 and 3832 rtsp://example.com/movie/trackID=2 to set up the video and audio 3833 streams, respectively. The URL rtsp://example.com/movie/ controls the 3834 whole movie. 3836 A client is not required to issues SETUP requests for all streams 3837 within an aggregate object. Servers SHOULD allow the client to ask 3838 for only a subset of the streams. 3840 D Minimal RTSP implementation 3842 D.1 Client 3844 A client implementation MUST be able to do the following : 3846 o Generate the following requests: SETUP, TEARDOWN, and one of 3847 PLAY (i.e., a minimal playback client) or RECORD (i.e., a 3848 minimal recording client). If RECORD is implemented, ANNOUNCE 3849 MUST be implemented as well. 3851 o Include the following headers in requests: CSeq, Connection, 3852 Session, Transport. If ANNOUNCE is implemented, the 3853 capability to include headers Content-Language, Content- 3854 Encoding, Content-Length, and Content-Type should be as well. 3856 o Parse and understand the following headers in responses: 3857 CSeq, Connection, Session, Transport, Content-Language, 3858 Content-Encoding, Content-Length, Content-Type. If RECORD is 3859 implemented, the Location header must be understood as well. 3860 RTP-compliant implementations should also implement RTP-Info. 3862 o Understand the class of each error code received and notify 3863 the end-user, if one is present, of error codes in classes 4xx 3864 and 5xx. The notification requirement may be relaxed if the 3865 end-user explicitly does not want it for one or all status 3866 codes. 3868 o Expect and respond to asynchronous requests from the server, 3869 such as ANNOUNCE. This does not necessarily mean that it 3870 should implement the ANNOUNCE method, merely that it MUST 3871 respond positively or negatively to any request received from 3872 the server. 3874 Though not required, the following are RECOMMENDED. 3876 o Implement RTP/AVP/UDP as a valid transport. 3878 o Inclusion of the User-Agent header. 3880 o Understand SDP session descriptions as defined in Appendix C 3882 o Accept media initialization formats (such as SDP) from 3883 standard input, command line, or other means appropriate to 3884 the operating environment to act as a "helper application" for 3885 other applications (such as web browsers). 3887 There may be RTSP applications different from those 3888 initially envisioned by the contributors to the RTSP 3889 specification for which the requirements above do not make 3890 sense. Therefore, the recommendations above serve only as 3891 guidelines instead of strict requirements. 3893 D.1.1 Basic Playback 3895 To support on-demand playback of media streams, the client MUST 3896 additionally be able to do the following: 3898 o generate the PAUSE request; 3900 o implement the REDIRECT method, and the Location header. 3902 D.1.2 Authentication-enabled 3904 In order to access media presentations from RTSP servers that require 3905 authentication, the client MUST additionally be able to do the 3906 following: 3908 o recognize the 401 (Unauthorized) status code; 3910 o parse and include the WWW-Authenticate header; 3912 o implement Basic Authentication and Digest Authentication. 3914 D.2 Server 3916 A minimal server implementation MUST be able to do the following: 3918 o Implement the following methods: SETUP, TEARDOWN, OPTIONS and 3919 either PLAY (for a minimal playback server) or RECORD (for a 3920 minimal recording server). 3922 If RECORD is implemented, ANNOUNCE SHOULD be implemented as 3923 well. 3925 o Include the following headers in responses: Connection, 3926 Content-Length, Content-Type, Content-Language, Content- 3927 Encoding, Transport, Public. The capability to include the 3928 Location header should be implemented if the RECORD method is. 3929 RTP-compliant implementations should also implement the RTP- 3930 Info field. 3932 o Parse and respond appropriately to the following headers in 3933 requests: Connection, Session, Transport, Require. 3935 Though not required, the following are highly recommended at the time 3936 of publication for practical interoperability with initial 3937 implementations and/or to be a "good citizen". 3939 o Implement RTP/AVP/UDP as a valid transport. 3941 o Inclusion of the Server header. 3943 o Implement the DESCRIBE method. 3945 o Generate SDP session descriptions as defined in Appendix C 3947 There may be RTSP applications different from those 3948 initially envisioned by the contributors to the RTSP 3949 specification for which the requirements above do not make 3950 sense. Therefore, the recommendations above serve only as 3951 guidelines instead of strict requirements. 3953 D.2.1 Basic Playback 3955 To support on-demand playback of media streams, the server MUST 3956 additionally be able to do the following: 3958 o Recognize the Range header, and return an error if seeking is 3959 not supported. 3961 o Implement the PAUSE method. 3963 In addition, in order to support commonly-accepted user interface 3964 features, the following are highly recommended for on-demand media 3965 servers: 3967 o Include and parse the Range header, with NPT units. 3968 Implementation of SMPTE units is recommended. 3970 o Include the length of the media presentation in the media 3971 initialization information. 3973 o Include mappings from data-specific timestamps to NPT. When 3974 RTP is used, the rtptime portion of the RTP-Info field may 3975 be used to map RTP timestamps to NPT. 3977 Client implementations may use the presence of length 3978 information to determine if the clip is seekable, and 3979 visably disable seeking features for clips for which the 3980 length information is unavailable. A common use of the 3981 presentation length is to implement a "slider bar" which 3982 serves as both a progress indicator and a timeline 3983 positioning tool. 3985 Mappings from RTP timestamps to NPT are necessary to ensure correct 3986 positioning of the slider bar. 3988 D.2.2 Authentication-enabled 3990 In order to correctly handle client authentication, the server MUST 3991 additionally be able to do the following: 3993 o Generate the 401 (Unauthorized) status code when 3994 authentication is required for the resource. 3996 o Parse and include the WWW-Authenticate header 3998 o Implement Basic Authentication and Digest Authentication 4000 E Changes 4002 Since RFC 2326, the following issues were addressed: 4004 o http://rtsp.org/bug448521 - URLs in Rtp-Info need to be quoted 4006 o http://rtsp.org/bug448525 - Syntax for SSRC should be 4007 clarified 4009 o http://rtsp.org/bug461083 - Body w/o Content-Length 4010 clarification 4012 o http://rtsp.org/bug477407 - Transport BNF doesn't properly 4013 deal with semicolon and comma 4015 o http://rtsp.org/bug477413 - Transport BNF: mode parameter 4016 issues 4018 o http://rtsp.org/bug477416 - BNF error section 3.6 NPT 4020 o http://rtsp.org/bug477421 - When to send response 4022 o http://rtsp.org/bug507347 - Removal of destination redirection 4024 Note that this list does not reflect minor changes in wording or 4025 correction of typographical errors. 4027 A word-by-word diff from RFC 2326 can be found at 4028 http://rtsp.org/2002/drafts 4030 F Author Addresses 4032 Henning Schulzrinne 4033 Dept. of Computer Science 4034 Columbia University 4035 1214 Amsterdam Avenue 4036 New York, NY 10027 4037 USA 4038 electronic mail: schulzrinne@cs.columbia.edu 4040 Anup Rao 4041 Cisco 4042 USA 4043 electronic mail: anrao@cisco.com 4045 Robert Lanphier 4046 RealNetworks 4047 P.O. Box 91123 4048 Seattle, WA 98111-9223 4049 USA 4050 electronic mail: robla@real.com 4052 G Acknowledgements 4054 This draft is based on the functionality of the original RTSP draft 4055 submitted in October 1996. It also borrows format and descriptions 4056 from HTTP/1.1. 4058 This document has benefited greatly from the comments of all those 4059 participating in the MMUSIC-WG. In addition to those already 4060 mentioned, the following individuals have contributed to this 4061 specification: 4063 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 4064 Bruce Butterfield, Ema Patki, Steve Casner, Francisco Cortes, Kelly 4065 Djahandari, Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy 4066 Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, 4067 Volker Hilt, John K. Ho, Philipp Hoschka, Anne Jones, Anders Klemets, 4068 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 4069 Marshall, Rob McCool, Aravind Narasimhan, David Oran, Joerg Ott, 4070 Maria Papadopouli, Sujal Patel, Alagu Periyannan, Colin Perkins, Igor 4071 Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Jeff Smith, 4072 Alexander Sokolsky, Dale Stammen, John Francis Stracke, David Walker, 4073 and Magnus Westerlund. 4075 H Bibliography 4077 [1] H. Schulzrinne, "RTP profile for audio and video conferences with 4078 minimal control," Request for Comments 1890, Internet Engineering 4079 Task Force, Jan. 1996. 4081 [2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, 4082 "Hypertext transfer protocol -- HTTP/1.1," Request for Comments 2068, 4083 Internet Engineering Task Force, Jan. 1997. 4085 [3] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 4086 "Internationalization of the hypertext markup language," Request for 4087 Comments 2070, Internet Engineering Task Force, Jan. 1997. 4089 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 4090 levels," Request for Comments 2119, Internet Engineering Task Force, 4091 Mar. 1997. 4093 [5] ISO/IEC, "Information technology -- generic coding of moving 4094 pictures and associated audio informaiton -- part 6: extension for 4095 digital storage media and control," Draft International Standard ISO 4096 13818-6, International Organization for Standardization ISO/IEC 4097 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 4099 [6] M. Handley and V. Jacobson, "SDP: session description protocol," 4100 Request for Comments 2327, Internet Engineering Task Force, Apr. 4101 1998. 4103 [7] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request 4104 for Comments 2246, Internet Engineering Task Force, Jan. 1999. 4106 [8] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, 4107 E. Sink, and L. Stewart, "An extension to HTTP : Digest access 4108 authentication," Request for Comments 2069, Internet Engineering Task 4109 Force, Jan. 1997. 4111 [9] J. Postel, "User datagram protocol," Request for Comments 768, 4112 Internet Engineering Task Force, Aug. 1980. 4114 [10] C. Partridge and R. M. Hinden, "Version 2 of the reliable data 4115 protocol (RDP)," Request for Comments 1151, Internet Engineering Task 4116 Force, Apr. 1990. 4118 [11] J. Postel, "Transmission control protocol," Request for Comments 4119 793, Internet Engineering Task Force, Sept. 1981. 4121 [12] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 4122 session initiation protocol," Request for Comments 2543, Internet 4123 Engineering Task Force, Mar. 1999. 4125 [13] International Telecommunication Union, "Visual telephone systems 4126 and equipment for local area networks which provide a non-guaranteed 4127 quality of service," Recommendation H.323, Telecommunication 4128 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 4130 [14] P. McMahon, "GSS-API authentication method for SOCKS version 5," 4131 Request for Comments 1961, Internet Engineering Task Force, June 4132 1996. 4134 [15] J. Miller, P. Resnick, and D. Singer, "Rating services and 4135 rating systems (and their machine readable descriptions)," 4136 Recommendation REC-PICS-services-961031, W3C (World Wide Web 4137 Consortium), Boston, Massachusetts, Oct. 1996. 4139 [16] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 4140 distribution label syntax and communication protocols," 4141 Recommendation REC-PICS-labels-961031, W3C (World Wide Web 4142 Consortium), Boston, Massachusetts, Oct. 1996. 4144 [17] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax 4145 specifications: ABNF," Request for Comments 2234, Internet 4146 Engineering Task Force, Nov. 1997. 4148 [18] R. Braden and Ed, "Requirements for internet hosts - application 4149 and support," Request for Comments 1123, Internet Engineering Task 4150 Force, Oct. 1989. 4152 [19] R. Elz, "A compact representation of IPv6 addresses," Request 4153 for Comments 1924, Internet Engineering Task Force, Apr. 1996. 4155 [20] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 4156 locators (URL)," Request for Comments 1738, Internet Engineering Task 4157 Force, Dec. 1994. 4159 [21] H. Schulzrinne, "A comprehensive multimedia control architecture 4160 for the Internet," in Proc. International Workshop on Network and 4161 Operating System Support for Digital Audio and Video (NOSSDAV) , (St. 4162 Louis, Missouri), May 1997. 4164 [22] F. Yergeau, "UTF-8, a transformation format of ISO 10646," 4165 Request for Comments 2279, Internet Engineering Task Force, Jan. 4166 1998. 4168 [23] R. Braden, "T/TCP -- TCP extensions for transactions functional 4169 specification," Request for Comments 1644, Internet Engineering Task 4170 Force, July 1994. 4172 [24] W. R. Stevens, TCP/IP illustrated: the implementation , vol. 2. 4173 Reading, Massachusetts: Addison-Wesley, 1994. 4175 [25] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 4176 protocol (RTSP)," Request for Comments 2326, Internet Engineering 4177 Task Force, Apr. 1998. 4179 [26] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 4180 identifiers (URI): generic syntax," Request for Comments 2396, 4181 Internet Engineering Task Force, Aug. 1998. 4183 [27] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 4184 a transport protocol for real-time applications," Request for 4185 Comments 1889, Internet Engineering Task Force, Jan. 1996. 4187 [28] R. Fielding, "Relative uniform resource locators," Request for 4188 Comments 1808, Internet Engineering Task Force, June 1995. 4190 Full Copyright Statement 4192 Copyright (C) The Internet Society (2002). All Rights Reserved. 4194 This document and translations of it may be copied and furnished to 4195 others, and derivative works that comment on or otherwise explain it 4196 or assist in its implmentation may be prepared, copied, published and 4197 distributed, in whole or in part, without restriction of any kind, 4198 provided that the above copyright notice and this paragraph are 4199 included on all such copies and derivative works. However, this 4200 document itself may not be modified in any way, such as by removing 4201 the copyright notice or references to the Internet Society or other 4202 Internet organizations, except as needed for the purpose of 4203 developing Internet standards in which case the procedures for 4204 copyrights defined in the Internet Standards process must be 4205 followed, or as required to translate it into languages other than 4206 English. 4208 The limited permissions granted above are perpetual and will not be 4209 revoked by the Internet Society or its successors or assigns. 4211 This document and the information contained herein is provided on an 4212 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4213 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4214 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4215 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4216 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4218 Table of Contents 4220 1 Introduction ........................................ 3 4221 1.1 Purpose ............................................. 3 4222 1.2 Requirements ........................................ 4 4223 1.3 Terminology ......................................... 4 4224 1.4 Protocol Properties ................................. 7 4225 1.5 Extending RTSP ...................................... 8 4226 1.6 Overall Operation ................................... 9 4227 1.7 RTSP States ......................................... 10 4228 1.8 Relationship with Other Protocols ................... 11 4229 2 Notational Conventions .............................. 12 4230 3 Protocol Parameters ................................. 12 4231 3.1 H3.1 ................................................ 12 4232 3.2 RTSP URL ............................................ 12 4233 3.3 Conference Identifiers .............................. 14 4234 3.4 Session Identifiers ................................. 14 4235 3.5 SMPTE Relative Timestamps ........................... 14 4236 3.6 Normal Play Time .................................... 15 4237 3.7 Absolute Time ....................................... 16 4238 3.8 Option Tags ......................................... 17 4239 3.8.1 Registering New Option Tags with IANA ............... 17 4240 4 RTSP Message ........................................ 17 4241 4.1 Message Types ....................................... 18 4242 4.2 Message Headers ..................................... 18 4243 4.3 Message Body ........................................ 18 4244 4.4 Message Length ...................................... 18 4245 5 General Header Fields ............................... 19 4246 6 Request ............................................. 19 4247 6.1 Request Line ........................................ 19 4248 6.2 Request Header Fields ............................... 20 4249 7 Response ............................................ 21 4250 7.1 Status-Line ......................................... 21 4251 7.1.1 Status Code and Reason Phrase ....................... 21 4252 7.1.2 Response Header Fields .............................. 24 4253 8 Entity .............................................. 24 4254 8.1 Entity Header Fields ................................ 25 4255 8.2 Entity Body ......................................... 25 4256 9 Connections ......................................... 25 4257 9.1 Pipelining .......................................... 27 4258 9.2 Reliability and Acknowledgements .................... 27 4259 10 Method Definitions .................................. 28 4260 10.1 OPTIONS ............................................. 28 4261 10.2 DESCRIBE ............................................ 29 4262 10.3 ANNOUNCE ............................................ 30 4263 10.4 SETUP ............................................... 31 4264 10.5 PLAY ................................................ 32 4265 10.6 PAUSE ............................................... 34 4266 10.7 TEARDOWN ............................................ 36 4267 10.8 GET_PARAMETER ....................................... 36 4268 10.9 SET_PARAMETER ....................................... 37 4269 10.10 REDIRECT ............................................ 38 4270 10.11 RECORD .............................................. 38 4271 10.12 Embedded (Interleaved) Binary Data .................. 39 4272 11 Status Code Definitions ............................. 40 4273 11.1 Success 2xx ......................................... 40 4274 11.1.1 250 Low on Storage Space ............................ 40 4275 11.2 Redirection 3xx ..................................... 40 4276 11.3 Client Error 4xx .................................... 41 4277 11.4 400 Bad Request ..................................... 41 4278 11.4.1 405 Method Not Allowed .............................. 41 4279 11.4.2 451 Parameter Not Understood ........................ 41 4280 11.4.3 452 Conference Not Found ............................ 41 4281 11.4.4 453 Not Enough Bandwidth ............................ 41 4282 11.4.5 454 Session Not Found ............................... 41 4283 11.4.6 455 Method Not Valid in This State .................. 41 4284 11.4.7 456 Header Field Not Valid for Resource ............. 42 4285 11.4.8 457 Invalid Range ................................... 42 4286 11.4.9 458 Parameter Is Read-Only .......................... 42 4287 11.4.10 459 Aggregate Operation Not Allowed ................. 42 4288 11.4.11 460 Only Aggregate Operation Allowed ................ 42 4289 11.4.12 461 Unsupported Transport ........................... 42 4290 11.4.13 462 Destination Unreachable ......................... 42 4291 11.5 Server Error 5xx .................................... 42 4292 11.5.1 551 Option not supported ............................ 42 4293 12 Header Field Definitions ............................ 43 4294 12.1 Accept .............................................. 43 4295 12.2 Accept-Encoding ..................................... 43 4296 12.3 Accept-Language ..................................... 43 4297 12.4 Accept-Ranges ....................................... 44 4298 12.5 Allow ............................................... 44 4299 12.6 Authorization ....................................... 44 4300 12.7 Bandwidth ........................................... 44 4301 12.8 Blocksize ........................................... 44 4302 12.9 Cache-Control ....................................... 46 4303 12.10 Conference .......................................... 48 4304 12.11 Connection .......................................... 48 4305 12.12 Content-Base ........................................ 48 4306 12.13 Content-Encoding .................................... 48 4307 12.14 Content-Language .................................... 48 4308 12.15 Content-Length ...................................... 49 4309 12.16 Content-Location .................................... 49 4310 12.17 Content-Type ........................................ 49 4311 12.18 CSeq ................................................ 49 4312 12.19 Date ................................................ 49 4313 12.20 Expires ............................................. 49 4314 12.21 From ................................................ 50 4315 12.22 Host ................................................ 50 4316 12.23 If-Match ............................................ 50 4317 12.24 If-Modified-Since ................................... 51 4318 12.25 Last-Modified ....................................... 51 4319 12.26 Location ............................................ 51 4320 12.27 Proxy-Authenticate .................................. 51 4321 12.28 Proxy-Require ....................................... 52 4322 12.29 Public .............................................. 52 4323 12.30 Range .............................................. 52 4324 12.31 Referer ............................................. 53 4325 12.32 Retry-After ......................................... 53 4326 12.33 Require ............................................. 53 4327 12.34 RTP-Info ............................................ 54 4328 12.35 Scale ............................................... 55 4329 12.36 Speed ............................................... 56 4330 12.37 Server .............................................. 57 4331 12.38 Session ............................................. 57 4332 12.39 Timestamp ........................................... 58 4333 12.40 Transport ........................................... 58 4334 12.41 Unsupported ......................................... 62 4335 12.42 User-Agent .......................................... 62 4336 12.43 Vary ................................................ 62 4337 12.44 Via ................................................. 62 4338 12.45 WWW-Authenticate .................................... 62 4339 13 Caching ............................................. 62 4340 14 Examples ............................................ 63 4341 14.1 Media on Demand (Unicast) ........................... 63 4342 14.2 Streaming of a Container file ....................... 65 4343 14.3 Single Stream Container Files ....................... 68 4344 14.4 Live Media Presentation Using Multicast ............. 70 4345 14.5 Playing media into an existing session .............. 71 4346 14.6 Recording ........................................... 72 4347 15 Syntax .............................................. 73 4348 15.1 Base Syntax ......................................... 73 4349 16 Security Considerations ............................. 74 4350 A RTSP Protocol State Machines ........................ 77 4351 A.1 Client State Machine ................................ 77 4352 A.2 Server State Machine ................................ 79 4353 B Interaction with RTP ................................ 80 4354 C Use of SDP for RTSP Session Descriptions ............ 81 4355 C.1 Definitions ......................................... 82 4356 C.1.1 Control URL ......................................... 82 4357 C.1.2 Media Streams ....................................... 82 4358 C.1.3 Payload Type(s) ..................................... 83 4359 C.1.4 Format-Specific Parameters .......................... 83 4360 C.1.5 Range of Presentation ............................... 83 4361 C.1.6 Time of Availability ................................ 83 4362 C.1.7 Connection Information .............................. 84 4363 C.1.8 Entity Tag .......................................... 84 4364 C.2 Aggregate Control Not Available ..................... 84 4365 C.3 Aggregate Control Available ......................... 85 4366 D Minimal RTSP implementation ......................... 86 4367 D.1 Client .............................................. 86 4368 D.1.1 Basic Playback ...................................... 87 4369 D.1.2 Authentication-enabled .............................. 87 4370 D.2 Server .............................................. 87 4371 D.2.1 Basic Playback ...................................... 88 4372 D.2.2 Authentication-enabled .............................. 89 4373 E Changes ............................................. 89 4374 F Author Addresses .................................... 90 4375 G Acknowledgements .................................... 90 4376 H Bibliography ........................................ 91