idnits 2.17.1 draft-ietf-mmusic-rfc2326bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 8046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 8019. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 8026. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 8032. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 36) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == 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 1358 has weird spacing: '...equired all...' == Line 1359 has weird spacing: '...ccepted all...' == Line 1651 has weird spacing: '...mmended rec...' == Line 1661 has weird spacing: '...nd what objec...' == Line 2859 has weird spacing: '...nd what objec...' == (35 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The response to valid request meeting the requisites is normally a 2xx (SUCCESS) unless other noted in the response column. The exceptions needs to be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occur the appropriate response code MUST be sent. If the response code is a 4xx the session state is unchanged. A response code of 3rr will result in that the session is ended and its state is changed to Init. A response code of 304 results in no state change. However there exist restrictions to when a 3xx response may be used. A 5xx response SHALL not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error SHALL result the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client knows that the session has ended. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '24' on line 7932 looks like a reference -- Missing reference section? '25' on line 7935 looks like a reference -- Missing reference section? '1' on line 7851 looks like a reference -- Missing reference section? '2' on line 7854 looks like a reference -- Missing reference section? '3' on line 7857 looks like a reference -- Missing reference section? '26' on line 7940 looks like a reference -- Missing reference section? '4' on line 7861 looks like a reference -- Missing reference section? '5' on line 7864 looks like a reference -- Missing reference section? '6' on line 7867 looks like a reference -- Missing reference section? '7' on line 7870 looks like a reference -- Missing reference section? '8' on line 7873 looks like a reference -- Missing reference section? '9' on line 7877 looks like a reference -- Missing reference section? '10' on line 7880 looks like a reference -- Missing reference section? '27' on line 7944 looks like a reference -- Missing reference section? '28' on line 7949 looks like a reference -- Missing reference section? '29' on line 7954 looks like a reference -- Missing reference section? '30' on line 7957 looks like a reference -- Missing reference section? '31' on line 7962 looks like a reference -- Missing reference section? '16' on line 7900 looks like a reference -- Missing reference section? '11' on line 7883 looks like a reference -- Missing reference section? '12' on line 7886 looks like a reference -- Missing reference section? '32' on line 7967 looks like a reference -- Missing reference section? '33' on line 7970 looks like a reference -- Missing reference section? '34' on line 7976 looks like a reference -- Missing reference section? '13' on line 7890 looks like a reference -- Missing reference section? 'H6' on line 1157 looks like a reference -- Missing reference section? 'H10' on line 2628 looks like a reference -- Missing reference section? 'TBW' on line 2673 looks like a reference -- Missing reference section? '14' on line 7893 looks like a reference -- Missing reference section? '15' on line 7896 looks like a reference -- Missing reference section? '35' on line 7981 looks like a reference -- Missing reference section? 'H15' on line 5656 looks like a reference -- Missing reference section? '17' on line 7904 looks like a reference -- Missing reference section? '18' on line 7907 looks like a reference -- Missing reference section? '19' on line 7911 looks like a reference -- Missing reference section? '36' on line 7984 looks like a reference -- Missing reference section? '20' on line 7915 looks like a reference -- Missing reference section? '21' on line 7919 looks like a reference -- Missing reference section? '37' on line 7989 looks like a reference -- Missing reference section? '38' on line 7992 looks like a reference -- Missing reference section? '39' on line 7996 looks like a reference -- Missing reference section? '22' on line 7923 looks like a reference -- Missing reference section? '23' on line 7927 looks like a reference -- Missing reference section? '40' on line 8000 looks like a reference -- Missing reference section? '41' on line 8004 looks like a reference -- Missing reference section? '42' on line 8007 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 54 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 draft-ietf-mmusic-rfc2326bis-11.txt Columbia U. 5 October 24, 2005 A. Rao 6 Expires: April, 2006 Cisco 7 R. Lanphier 8 RealNetworks 9 Magnus Westerlund 10 Ericsson 11 A. Narasimhan 12 Overture 14 Real Time Streaming Protocol 2.0 (RTSP) 16 STATUS OF THIS MEMO 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 This memorandum defines RTSP version 2.0 which is a revision of the 42 Proposed Standard RTSP version 1.0 which is defined in RFC 2326. 44 The Real Time Streaming Protocol, or RTSP, is an application-level 45 protocol for control over the delivery of data with real-time 46 properties. RTSP provides an extensible framework to enable 47 controlled, on-demand delivery of real-time data, such as audio and 48 video. Sources of data can include both live data feeds and stored 49 clips. This protocol is intended to control multiple data delivery 50 sessions, provide a means for choosing delivery channels such as UDP, 51 multicast UDP and TCP, and provide a means for choosing delivery 52 mechanisms based upon RTP (RFC 3550). 54 1 Introduction 56 1.1 RTSP Specification Update 58 This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a 59 proposed standard defined in RFC 2326 [24]. The goal of this version 60 is to correct the many flaws that have been identified in RTSP 1.0 61 since its publication. The corrections are such that full backwards 62 compatibility was impossible. Thus a new version was decided the most 63 appropriate solution to get a more functional protocol. There are no 64 plans to revise RTSP 1.0. Appendix H catalogs the changes of this 65 version in relation to RTSP 1.0. 67 A few open issues still remain to be resolved, and are listed in 68 appendix G. These are intended to be close quickly. 70 A list of bugs against RFC 2326 is available at 71 "http://rtspspec.sourceforge.net". These bugs should be taken into 72 account when reading this memorandum. Input on the unresolved bugs 73 and other issues can be sent via e-mail to the MMUSIC WG's mailing 74 list mmusic@ietf.org and the authors. 76 RTSP 2.0 is reduced in functionality in regards to RTSP 1.0 and aims 77 at specifying the RTSP core, functionality and rules for extensions, 78 and basic interaction with the media delivery protocol RTP. 80 Any other functionality would be need to be published as extension 81 documents. The Working group has discussed a number of different 82 proposals to extensions and is currently working on: 84 o NAT and FW traversal mechanisms for RTSP are described in a 85 document called "How to make Real-Time Streaming Protocol 86 (RTSP) traverse Network Address Translators (NAT) and interact 87 with Firewalls." [25]. 89 1.2 Purpose 91 The Real-Time Streaming Protocol (RTSP) establishes and controls one 92 or several time-synchronized streams of continuous media such as 93 audio and video. Put simply, RTSP acts as a "network remote control" 94 for multimedia servers. 96 There is no notion of an RTSP connection in the protocol. Instead, an 97 RTSP server maintains a session labeled by an identifier to associate 98 groups of media streams and their states. An RTSP session is not tied 99 to a transport-level connection such as a TCP connection. During a 100 session, a client may open and close many reliable transport 101 connections to the server to issue RTSP requests for that session. 103 This memorandum describes the use of RTSP over a reliable connection 104 based transport level protocol such as TCP. RTSP may be implemented 105 over an unreliable connectionless transport protocol such as UDP. 106 While nothing in RTSP precludes this, additional definition of this 107 problem area needs to be handled as an extension to the core 108 specification. 110 The mechanisms of RTSP's operation over UDP were left out 111 of this spec. because they were poorly defined in RFC 2326 112 [24] and the tradeoff in size and complexity of this 113 memorandum for a small gain in a limited problem space was 114 not deemed justifiable. 116 The set of streams to be controlled in an RTSP session is defined by 117 a presentation description. This memorandum does not define a format 118 for the presentation description. However appendix C defines how SDP 119 [1] is used for this purpose. The streams controlled by RTSP may use 120 RTP [2] for their data transport, but the operation of RTSP does not 121 depend on the transport mechanism used to carry continuous media. 122 RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3] 123 so that extension mechanisms to HTTP can in most cases also be added 124 to RTSP. However, RTSP differs in a number of important aspects from 125 HTTP: 127 o RTSP introduces a number of new methods and has a different 128 protocol identifier. 130 o RTSP has the notion of a session built into the protocol. 132 o An RTSP server needs to maintain state by default in almost 133 all cases, as opposed to the stateless nature of HTTP. 135 o Both an RTSP server and client can issue requests. 137 o Data is usually carried out-of-band by a different protocol. 138 Session descriptions returned in a DESCRIBE response (see 139 Section 11.2) and interleaving of RTP with RTSP over TCP are 140 exceptions to this rule (see Section 12). 142 o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 143 8859-1, consistent with HTML internationalization efforts 144 [26]. 146 o The Request-URI always contains the absolute URI. Because of 147 backward compatibility with a historical blunder, HTTP/1.1 [3] 148 carries only the absolute path in the request and puts the 149 host name in a separate header field. 151 This makes "virtual hosting" easier, where a single 152 host with one IP address hosts several document trees. 154 The protocol supports the following operations: 156 Retrieval of media from media server: The client can either 157 request a presentation description via RTSP DESCRIBE, HTTP 158 or some other method. If the presentation is being 159 multicast, the presentation description contains the 160 multicast addresses and ports to be used for the continuous 161 media. If the presentation is to be sent only to the client 162 via unicast, the client provides the destination of 163 necessity. 165 Invitation of a media server to a conference: A media server can 166 be "invited" to join an existing conference to play back 167 media into the presentation. This mode is useful for 168 example distributed teaching applications. Several parties 169 in the conference may take turns "pushing the remote 170 control buttons". 172 RTSP requests may be handled by proxies, tunnels and caches as in 173 HTTP/1.1 [3]. 175 1.3 Notational Conventions 177 Since many of the definitions and syntax are identical to HTTP/1.1, 178 this specification only points to the section where they are defined 179 rather than copying it. For brevity, [HX.Y] is to be taken to refer 180 to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [3]). 182 All the mechanisms specified in this document are described in both 183 prose and the Augmented Backus-Naur form (ABNF) described in detail 184 in RFC 4234 [4]. 186 Indented and smaller-type paragraphs are used to provide informative 187 background and motivation. This is intended to give readers who were 188 not involved with the formulation of the specification an 189 understanding of why things are the way they are in RTSP. 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [5]. 195 The word, "unspecified" is used to indicate functionality or features 196 that are not defined in this specification. Such functionality cannot 197 be used in a standardized manner without further definition in an 198 extension specification to RTSP. 200 1.4 Terminology 202 Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not 203 listed here are defined as in HTTP/1.1. 205 Aggregate control: The concept of controlling multiple streams 206 using a single timeline, generally maintained by the 207 server. A client, for example, uses aggregate control when 208 it issues a single play or pause message to simultaneously 209 control both the audio and video in a movie. 211 Aggregate control URI: The URI used in an RTSP request to refer 212 to and control an aggregated session. It normally, but not 213 always, corresponds to the presentation URI specified in 214 the session description. See Section 11.3 for more 215 information. 217 Conference: a multiparty, multimedia presentation, where "multi" 218 implies greater than or equal to one. 220 Client: The client requests media service from the media server. 222 Connection: A transport layer virtual circuit established 223 between two programs for the purpose of communication. 225 Container file: A file which may contain multiple media streams 226 which often constitutes a presentation when played 227 together. The concept of a container file is not embedded 228 in the protocol. However, RTSP servers may offer aggregate 229 control on the media streams within these files. 231 Continuous media: Data where there is a timing relationship 232 between source and sink; that is, the sink needs to 233 reproduce the timing relationship that existed at the 234 source. The most common examples of continuous media are 235 audio and motion video. Continuous media can be real-time 236 (interactive or conversational), where there is a "tight" 237 timing relationship between source and sink, or streaming 238 (playback), where the relationship is less strict. 240 Entity: The information transferred as the payload of a request 241 or response. An entity consists of meta-information in the 242 form of entity-header fields and content in the form of an 243 entity-body, as described in Section 8. 245 Feature-tag: A tag representing a certain set of functionality, 246 i.e. a feature. 248 Live: Normally used to describe a presentation or session with 249 media coming from an ongoing event. This generally results 250 in that the session has a unbound or only loosely defined 251 duration, and that no seek operations are possible. 253 Media initialization: Datatype/codec specific initialization. 254 This includes such things as clock rates, color tables, 255 etc. Any transport-independent information which is 256 required by a client for playback of a media stream occurs 257 in the media initialization phase of stream setup. 259 Media parameter: Parameter specific to a media type that may be 260 changed before or during stream playback. 262 Media server: The server providing playback services for one or 263 more media streams. Different media streams within a 264 presentation may originate from different media servers. A 265 media server may reside on the same host or on a different 266 host from which the presentation is invoked. 268 Media server indirection: Redirection of a media client to a 269 different media server. 271 (Media) stream: A single media instance, e.g., an audio stream 272 or a video stream as well as a single whiteboard or shared 273 application group. When using RTP, a stream consists of all 274 RTP and RTCP packets created by a source within an RTP 275 session. 277 Message: The basic unit of RTSP communication, consisting of a 278 structured sequence of octets matching the syntax defined 279 in Section 19 and transmitted over a connection or a 280 connectionless transport. 282 Non-Aggregated Control: Control of a single media stream. Only 283 possible in RTSP sessions with a single media. 285 Participant: Member of a conference. A participant may be a 286 machine, e.g., a playback server. 288 Presentation: A set of one or more streams presented to the 289 client as a complete media feed and described by a 290 presentation description as defined below. Presentations 291 with more than one media stream is often handled in RTSP 292 under aggregate control. 294 Presentation description: A presentation description contains 295 information about one or more media streams within a 296 presentation, such as the set of encodings, network 297 addresses and information about the content. Other IETF 298 protocols such as SDP (RFC 2327 [1]) use the term "session" 299 for a presentation. The presentation description may take 300 several different formats, including but not limited to the 301 session description protocol format, SDP. 303 Response: An RTSP response. If an HTTP response is meant, that 304 is indicated explicitly. 306 Request: An RTSP request. If an HTTP request is meant, that is 307 indicated explicitly. 309 Request-URI: The URI used in a request to indicate the resource 310 on which the request is to be performed. 312 RTSP agent: Refers to either an RTSP client, an RTSP server, or 313 an RTSP Proxy. In this specification, there are many 314 capabilities that are common to these three entities such 315 as the capability to send requests or receive responses. 316 This term will be used when describing functionality that 317 is applicable to all three of these entities. 319 RTSP session: A stateful abstraction upon which the main control 320 methods of RTSP operate. An RTSP session is a server 321 entity; it is created, maintained and destroyed by the 322 server. It is established by an RTSP server upon the 323 completion of a successful SETUP request (when 200 OK 324 response is sent) and is labelled by a session identifier 325 at that time. The session exists until timed out by the 326 server or explicitly removed by a TEARDOWN request. An RTSP 327 session is a stateful entity; an RTSP server maintains an 328 explicit session state machine (see Appendix A) where most 329 state transitions are triggered by client requests. The 330 existence of a session implies the existence of state about 331 the session's media streams and their respective transport 332 mechanisms. A given session can have zero or more media 333 streams associated with it. An RTSP server uses the session 334 to aggregate control over multiple media streams. 336 Transport initialization: The negotiation of transport 337 information (e.g., port numbers, transport protocols) 338 between the client and the server. 340 URI: Universal Resource Identifier, see RFC 3986 [6]. In RTSP 341 the used URIs are as general rule in fact URL's as they 342 gives an location for the resource. As URLs are a subset of 343 URIs, they will be referred to as URIs to cover also the 344 cases when an RTSP URI would not be an URL. 346 URL: Universal Resource Locator, is an URI which identifies the 347 resource through its primary access mechanism, rather than 348 identifying the resource by name or by some other 349 attribute(s) of that resource. 351 1.5 Protocol Properties 353 RTSP has the following properties: 355 Extendable: New methods and parameters can be easily added to 356 RTSP. 358 Easy to parse: RTSP can be parsed by standard HTTP or MIME 359 parsers. 361 Secure: RTSP re-uses web security mechanisms, either at the 362 transport level (TLS, RFC 2246 [7]) or within the protocol 363 itself. All HTTP authentication mechanisms such as basic 364 (RFC 2616 [3]) and digest authentication (RFC 2617 [8]) are 365 directly applicable. 367 Transport-independent: RTSP does not preclude the use of an 368 unreliable datagram protocol (UDP) (RFC 768 [9]) as it 369 would be possible to implement application-level 370 reliability. The use of a connectionless datagram protocol 371 such as UDP requires additional definition that may be 372 provided as extensions to the core RTSP specification. The 373 usage of the reliable stream protocol TCP (RFC 793 [10]) 374 and secured reliable stream protocol TLS over TCP [7] is 375 what is currently defined as transport protocol of RTSP 376 messages. 378 Multi-server capable: Each media stream within a presentation 379 can reside on a different server. The client automatically 380 establishes several concurrent control sessions with the 381 different media servers. Media synchronization is 382 performed at the transport level. 384 Separation of stream control and conference initiation: Stream 385 control is divorced from inviting a media server to a 386 conference. In particular, SIP [27] or H.323 [28] may be 387 used to invite a server to a conference. 389 Suitable for professional applications: RTSP supports frame- 390 level accuracy through SMPTE time stamps to allow remote 391 digital editing. 393 Presentation description neutral: The protocol does not impose a 394 particular presentation description or metafile format and 395 can convey the type of format to be used. However, the 396 presentation description is required to contain at least 397 one RTSP URI. 399 Proxy and firewall friendly: The protocol should be readily 400 handled by both application and transport-layer (SOCKS 401 [29]) firewalls. A firewall may need to understand the 402 SETUP method to open a "hole" for the media stream. 404 HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so 405 that the existing infrastructure can be reused. This 406 infrastructure includes PICS (Platform for Internet Content 407 Selection [30,31]) for associating labels with content. 408 However, RTSP does not just add methods to HTTP since the 409 controlling continuous media requires server state in most 410 cases. 412 Appropriate server control: If a client can start a stream, it 413 needs to be able to stop a stream. Servers should not start 414 streaming to clients in such a way that clients cannot stop 415 the stream. 417 Transport negotiation: The client can negotiate the transport 418 method prior to actually needing to process a continuous 419 media stream. 421 1.6 Extending RTSP 423 Since not all media servers have the same functionality, media 424 servers by necessity will support different sets of requests. For 425 example: 427 o A server may not be capable of seeking (absolute positioning) 428 if it is to support live events only. 430 o Some servers may not support setting stream parameters and 431 thus not support GET_PARAMETER and SET_PARAMETER. 433 o Some server may support an RTSP extension. 435 A server SHOULD implement all header fields described in Section 14. 437 It is up to the creators of presentation descriptions not to ask the 438 impossible of a server. This situation is similar in HTTP/1.1 [3], 439 where the methods described in [H19.5] are not likely to be supported 440 across all servers. 442 RTSP can be extended in three ways, listed here in order of the 443 magnitude of changes supported: 445 o Existing methods can be extended with new parameters, e.g. 446 headers, as long as these parameters can be safely ignored by 447 the recipient. If the client needs negative acknowledgement 448 when a method extension is not supported, a tag corresponding 449 to the extension may be added in the Require: field (see 450 Section 14.37). 452 o New methods can be added. If the recipient of the message does 453 not understand the request, it responds with error code 501 454 (Not Implemented) and the sender should not attempt to use 455 this method again. A client may also use the OPTIONS method to 456 inquire about methods supported by the server. The server MUST 457 list the methods it supports using the Public response header. 459 o A new version of the protocol can be defined, allowing almost 460 all aspects (except the position of the protocol version 461 number) to change. 463 The basic capability discovery mechanism can be used to both discover 464 support for a certain feature and to ensure that a feature is 465 available when performing a request. For detailed explanation of this 466 see section 10. 468 1.7 Overall Operation 470 Each presentation and media stream is identified by an RTSP URI. The 471 overall presentation and the properties of the media the presentation 472 is made up of are defined by a presentation description file, the 473 format of which is outside the scope of this specification. The 474 presentation description file may be obtained by the client using 475 HTTP or other means such as email and may not necessarily be stored 476 on the media server. 478 For the purposes of this specification, a presentation description is 479 assumed to describe one or more presentations, each of which 480 maintains a common time axis. For simplicity of exposition and 481 without loss of generality, it is assumed that the presentation 482 description contains exactly one such presentation. A presentation 483 may contain several media streams. 485 The presentation description file contains a description of the media 486 streams making up the presentation, including their encodings, 487 language, and other parameters that enable the client to choose the 488 most appropriate combination of media. In this presentation 489 description, each media stream that is individually controllable by 490 RTSP is identified by an RTSP URI, which points to the media server 491 handling that particular media stream and names the stream stored on 492 that server. Several media streams can be located on different 493 servers; for example, audio and video streams can be split across 494 servers for load sharing. The description also enumerates which 495 transport methods the server is capable of. 497 Besides the media parameters, the network destination address and 498 port need to be determined. Several modes of operation can be 499 distinguished: 501 Unicast: The media is transmitted to the source of the RTSP 502 request, with the port number chosen by the client. 503 Alternatively, the media is transmitted on the same 504 reliable stream as RTSP. 506 Multicast, server chooses address: The media server picks the 507 multicast address and port. This is the typical case for a 508 live or near-media-on-demand transmission. 510 Multicast, client chooses address: If the server is to 511 participate in an existing multicast conference, the 512 multicast address, port and encryption key are given by the 513 conference description, established by means outside the 514 scope of this specification, for example by a SIP created 515 conference. 517 1.8 RTSP States 519 RTSP controls a stream which may be sent via a separate protocol, 520 independent of the control channel. For example, RTSP control may be 521 transported on a TCP connection while the media data is conveyed via 522 UDP. Thus, data delivery continues even if no RTSP requests are 523 received by the media server. Also, during its lifetime, a single 524 media stream may be controlled by RTSP requests issued sequentially 525 on different TCP connections. Therefore, the server needs to maintain 526 "session state" to be able to correlate RTSP requests with a stream. 527 The state transitions are described in Appendix A. 529 Many methods in RTSP do not contribute to state. However, the 530 following play a central role in defining the allocation and usage of 531 stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and 532 TEARDOWN. 534 SETUP: Causes the server to allocate resources for a stream and 535 create an RTSP session. 537 PLAY: Starts data transmission on a stream allocated via SETUP. 539 PAUSE: Temporarily halts a stream without freeing server 540 resources. 542 REDIRECT: Indicates that the session should be moved to new 543 server / location 545 TEARDOWN: Frees resources associated with the stream. The RTSP 546 session ceases to exist on the server. 548 RTSP methods that contribute to state use the Session header field 549 (Section 14.42) to identify the RTSP session whose state is being 550 manipulated. The server generates session identifiers in response to 551 SETUP requests (Section 11.3). 553 1.9 Relationship with Other Protocols 555 RTSP has some overlap in functionality with HTTP. It also may 556 interact with HTTP in that the initial contact with streaming content 557 is often to be made through a web page. The current protocol 558 specification aims to allow different hand-off points between a web 559 server and the media server implementing RTSP. For example, the 560 presentation description can be retrieved using HTTP or RTSP, which 561 reduces round trips in web-browser-based scenarios, yet also allows 562 for stand alone RTSP servers and clients which do not rely on HTTP at 563 all. However, RTSP differs fundamentally from HTTP in that most data 564 delivery takes place out-of-band in a different protocol. HTTP is an 565 asymmetric protocol where the client issues requests and the server 566 responds. In RTSP, both the media client and media server can issue 567 requests. RTSP requests are also stateful; they may set parameters 568 and continue to control a media stream long after the request has 569 been acknowledged. 571 Re-using HTTP functionality has advantages in at least two 572 areas, namely security and proxies. The requirements are 573 very similar, so having the ability to adopt HTTP work on 574 caches, proxies and authentication is valuable. 576 RTSP assumes the existence of a presentation description format that 577 can express both static and temporal properties of a presentation 578 containing several media streams. Session Description Protocol (SDP) 579 [1] is generally the format of choice; however, RTSP is not bound to 580 it. For data delivery, most real-time media will use RTP as a 581 transport protocol. While RTSP works well with RTP, it is not tied to 582 RTP. 584 2 RTSP Use Cases 585 This section describes the most important and considered use cases 586 for RTSP. They are listed in descending order of importance in 587 regards to ensuring that all necessary functionality is present. This 588 specification does only fully support usage of the two first. Also in 589 these first two cases, there are special cases or exceptions that are 590 not supported without extensions, e.g. the redirection of media to 591 another address than the controlling entity. 593 2.1 On-demand Playback of Stored Content 595 An RTSP capable server stores content suitable for being streamed to 596 a client. A client desiring playback of any of the stored content 597 then uses RTSP to set up and configure the media transport required 598 for the desired content. Then RTSP is used to initiate, halt and 599 manipulate the actual transmission (playout) of the content. There 600 are also requirement on being able to use RTSP to carry necessary 601 description and synchronization information for the content. The 602 above high level description can be broken down into a number of 603 functionalities that RTSP needs to be capable of. 605 Presentation Description: The possibility to carry 606 initialization information about the presentation 607 (content), for example, which media codec(s) that are 608 needed for the content. Other information that are 609 important; how many media stream that the presentation 610 contains; what transport protocols used for the media 611 streams; and identifiers for these media streams. This 612 information is required before setup of the content is 613 possible. The information is also needed by the client to 614 determine if it is capable at all to support the content. 615 This information is not required to be sent using RTSP, 616 instead other external protocols can be utilized to 617 transport presentation descriptions. Two good examples are 618 the use of HTTP [3] or email to fetch or receive 619 presentation descriptions like SDP [1]. .XP Setup: 620 Performing setup of some or all of the media streams in a 621 presentation. The setup itself consist of determining which 622 protocols for media transport to use; the necessary 623 parameters for the protocol, like addresses and ports. .XP 624 Control of Transmission: After the necessary media streams 625 has been established the client can request the server to 626 start transmitting the content. There is need to allow the 627 client to at arbitrary times start or stop the transmission 628 of the content. There are also exist need to be able to 629 start the transmission at an any point in the timeline of 630 the presentation. .XP Synchronization: For media transport 631 protocols like RTP [16] it might be beneficial to carry 632 synchronization information within RTSP. Either due to the 633 lack of inter media synchronization within the protocol 634 itself, or the potential delay before the synchronization 635 is established (which is the case for RTP when using RTCP). 636 .XP Termination There is also need to be able to terminate 637 the established contexts. 638 For this use cases there is a number of assumption about how it 639 works. These are listed below: 641 On-Demand content: The content available is stored at the server 642 and can be accessed at any time during a time period when 643 it is intended to be available. .XP Independent sessions: A 644 server is capable of serving a number of clients 645 simultaneously, including from the same piece of content at 646 different points in that presentations time-line. .XP 647 Unicast Transport: Content for each individual client is 648 transmitted to them using unicast traffic. 649 It is also possible to redirect the media traffic to another 650 destination than where the entity controlling traffic uses. 651 However allowing this without appropriate mechanisms for 652 checking that the destination approves of this is allows for 653 distributed denial of service attacks (DDoS). 655 2.2 Unicast distribution of Live Content 657 This use cases is not that different from the above on-demand content 658 case (see section 2.1. The difference is really the restriction the 659 content itself establish. Live content is continuously distributed as 660 it becomes available from a source, i.e. the main difference to on- 661 demand is that one starts distributing content before the end of it 662 has become available to the server. In many cases the consumer of 663 live content is only interested in consuming what is actually happens 664 "now", i.e. very similar to broadcast TV. However in this case it is 665 assumed that there exist no broadcast or multicast channel to the 666 users, and instead the server functions as a distribution node, 667 sending the same content to multiple receivers, using unicast traffic 668 between server and client. This unicast traffic and the transport 669 parameters are individually negotiated for each receiving client. 670 Another aspect of live content is that it has often very limited time 671 of availability, as it is only is available for the duration of the 672 event the content covers. A example of such a live content could for 673 example be a music concert, which lasts 2 hour and starts at a 674 predetermined time. Thus there is need to announce when and for how 675 long the live content is available. 677 2.3 On-demand Playback using Multicast 679 It is possible to use RTSP to request that media is delivered to a 680 multicast group. The entity setting up the session (the controller) 681 will then control when and what media that is delivered to the group. 682 Also this use case has some potential for denial of service attacks, 683 in this case flooding any multicast group. Therefore there is need 684 for a mechanism indicating that the group actually accepts the 685 traffic from the RTSP server. An open issue in this use case is how 686 one ensures that all receivers listening to the multicast or 687 broadcast receives the session presentation configuring the 688 receivers. 690 2.4 Inviting a RTSP server into a conference 692 If one has an established conference or group session, it is possible 693 to have a RTSP server distribute media to the whole group. The 694 transmission to the group is simplest controlled by a single 695 participant or leader of the conference. Shared control might be 696 possible, but would require further investigation and possibly 697 extensions. There are some protocol mechanisms missing for this 698 scenario. For reasonable complexity in the media transmission stage, 699 this use case assumes that there exist either multicast or a 700 conference focus that redistribute media to all participants. In some 701 more detail, this use case is intended to be able to handle the 702 following scenario: A conference leader or participant (from here 703 called the controller) has some pre-stored content on a RTSP server 704 that he likes to share with the group. The controller sets up an RTSP 705 session at the streaming server for the content the controller likes 706 to share. The session description for the content is retrieved by the 707 controller. The media destination for the media content is sent to 708 the shared multicast group or conference focus. When desired by the 709 controller, he/she can start and stop the transmission of the media 710 to the conference group. There are several issues with this use case 711 that is not solved by this core specification for RTSP: 713 o Denial of service threat, to avoid a RTSP server from being a 714 unknowing participant of a denial of service attack the server 715 needs to be able to verify the destinations acceptance for the 716 media. Such a mechanism does not yet exist that can be used to 717 verify the approval to received media, instead only policies 718 can be used, which can be made to work in controlled 719 environments. .IP o 2 The problem of distributing the 720 presentation description to all participants in the group. To 721 enable a media receiver to decode the content correctly the 722 media configuration information will need to be distributed 723 reliable to all participants. This will most likely require 724 support from an external protocol. .IP o 2 Passing the 725 control. If it is desired to be able to pass the control of 726 the RTSP session between the participants some support will be 727 required by an external protocol for the necessary exchange of 728 state information and possibly floor control of who is 729 controlling the RTSP session. 731 So if there interest in this use case further work on the necessary 732 extensions has to be performed. 734 2.5 Live Content using Multicast 736 This use case does in its simplest form do not require any use of 737 RTSP at all. This is what multicast conferences being announced with 738 SAP and SDP are intended to handle. However in use cases where more 739 advance features like access control to the multicast session is 740 desired, RTSP could be used for session establishment. A client 741 desiring to join a live multicasted media session with cryptographic 742 (encryption) access control could use RTSP in the following way. The 743 source of the session, announces the session and gives all interested 744 to join, a RTSP URI. The client connects to the server and requests 745 the presentation description allowing for configuration the 746 reception. In this step it is possible to use secured transport for 747 the client, and also desired levels of authentication, for example 748 for charging purposes or simply access control. An RTSP link also 749 allows for load balancing between multiple servers. However if this 750 was the only thing that occurred it could probably be solved as 751 simply using HTTP. However for session where the sender likes to keep 752 track of each individual receiver during the session, and possibly 753 use this side channel for pushing out key-updates or other side 754 information that is desirable to be done on a per receiver basis, and 755 the receivers are not know prior to the session start, the state 756 establishment that RTSP provides can be beneficial. In this case a 757 client would establish a RTSP session to the multicast group. The 758 RTSP server will not transmit any media, instead it will simply point 759 to the multicast group. However the client and server will be able to 760 keep the session alive for as long as the receiver participates in 761 the session. Thus enabling, for example server to client pushes of 762 updates. This use cases will most likely not be able to actually 763 implement without some extensions in relation to the server to client 764 push mechanism. Here a method like ANNOUNCE (see RFC 2326 [24] might 765 be suitable, however it will require a RTSP extension to revive the 766 method. 768 3 Protocol Parameters 770 3.1 RTSP Version 772 HTTP Specification Section [H3.1] applies, with HTTP replaced by 773 RTSP. This specification defines version 2.0 of RTSP. 775 3.2 RTSP URI 776 The "rtsp", "rtsps" schemes are used to refer to network resources 777 via the RTSP protocol. This section defines the scheme-specific 778 syntax and semantics for RTSP URIs. The RTSP URI is case sensitive. 779 An URI scheme "rtspu" was defined in RFC 2326 for transport of RTSP 780 messages over unreliable transport (UDP) and is currently deprecated 781 and reserved, and MUST NOT be used . See Appendix E for further 782 information. 784 Informative RTSP URI syntax: 786 rtsp[u|s]://host[:port]/abspath[?query]#fragment 788 See section 19.2.1 for the formal definition of the RTSP URI syntax. 790 The fragment identifier is used as defined in section 4.1 of [6], 791 i.e. the fragment is to be stripped from the URI by the requestor and 792 not included in the request. The user agent also needs to interpret 793 the value of the fragment based on the media type the request relates 794 to, i.e. the media type indicated in Content-Type header in the 795 response to DESCRIBE. 797 The syntax of any URI query string is unspecified and responder 798 (usually the server) specific. As it is from the requestor an opaque 799 string, it needs to be handled as such. 801 The URI scheme rtsp requires that commands are issued via a reliable 802 protocol (within the Internet, TCP), while the scheme rtsps 803 identifies a reliable transport using secure transport (TLS [7]). 805 If the no port number is provided in the URI, port number 554 SHALL 806 be used. The semantics are that the identified resource can be 807 controlled by RTSP at the server listening for TCP (scheme "rtsp") 808 connections on that port of host, and the Request-URI for the 809 resource is rtsp_URI. For the scheme rtsps the TCP and UDP port 322 810 is registered and SHALL be assumed. 812 The use of IP addresses in URIs SHOULD be avoided whenever possible 813 (see RFC 1924 [11]). This specification updates the RTSP URI scheme 814 to allow for literal IPv6 addresses using the host specification in 815 RFC 2732 [12]. 817 Note: Using qualified domain names in any URI is one 818 requirement for making it possible for RTSP 1.0 (RFC 2326) 819 implementations of RTSP to use IPv6. 821 A presentation or a stream is identified by a textual media 822 identifier, using the character set and escape conventions [H3.2] of 823 URIs (RFC 3986 [6]). URIs may refer to a stream or an aggregate of 824 streams, i.e., a presentation. Accordingly, requests described in 825 Section 11 can apply to either the whole presentation or an 826 individual stream within the presentation. Note that some request 827 methods can only be applied to streams, not presentations and vice 828 versa. 830 For example, the RTSP URI: 832 rtsp://media.example.com:554/twister/audiotrack 834 may identify the audio stream within the presentation "twister", 835 which can be controlled via RTSP requests issued over a TCP 836 connection to port 554 of host media.example.com 838 Also, the RTSP URI: 840 rtsp://media.example.com:554/twister 842 identifies the presentation "twister", which may be composed of audio 843 and video streams. 845 This does not imply a standard way to reference streams in 846 URIs. The presentation description defines the hierarchical 847 relationships in the presentation and the URIs for the 848 individual streams. A presentation description may name a 849 stream "a.mov" and the whole presentation "b.mov". 851 The path components of the RTSP URI are opaque to the client and do 852 not imply any particular file system structure for the server. 854 This decoupling also allows presentation descriptions to be 855 used with non-RTSP media control protocols simply by 856 replacing the scheme in the URI. 858 3.3 Session Identifiers 860 Session identifiers are strings of any arbitrary length. A session 861 identifier MUST be chosen randomly and MUST be at least eight 862 characters long to make guessing it more difficult. (See Section 20.) 864 3.4 SMPTE Relative Timestamps 865 A SMPTE relative timestamp expresses time relative to the start of 866 the clip. Relative timestamps are expressed as SMPTE time codes for 867 frame-level access accuracy. The time code has the format 868 hours:minutes:seconds:frames.subframes, 869 with the origin at the start of the clip. The default smpte format is 870 "SMPTE 30 drop" format, with frame rate is 29.97 frames per second. 871 Other SMPTE codes MAY be supported (such as "SMPTE 25") through the 872 use of alternative use of "smpte time". For the "frames" field in the 873 time value can assume the values 0 through 29. The difference between 874 30 and 29.97 frames per second is handled by dropping the first two 875 frame indices (values 00 and 01) of every minute, except every tenth 876 minute. If the frame value is zero, it may be omitted. Subframes are 877 measured in one-hundredth of a frame. 879 Examples: 881 smpte=10:12:33:20- 882 smpte=10:07:33- 883 smpte=10:07:00-10:07:33:05.01 884 smpte-25=10:07:00-10:07:33:05.01 886 3.5 Normal Play Time 888 Normal play time (NPT) indicates the stream absolute position 889 relative to the beginning of the presentation, not to be confused 890 with the Network Time Protocol (NTP) [32]. The timestamp consists of 891 a decimal fraction. The part left of the decimal may be expressed in 892 either seconds or hours, minutes, and seconds. The part right of the 893 decimal point measures fractions of a second. 895 The beginning of a presentation corresponds to 0.0 seconds. Negative 896 values are not defined. The special constant now is defined as the 897 current instant of a live type event. It MAY only be used for live 898 type events, and SHALL NOT be used for on-demand content. 900 NPT is defined as in DSM-CC [33]: "Intuitively, NPT is the clock the 901 viewer associates with a program. It is often digitally displayed on 902 a VCR. NPT advances normally when in normal play mode (scale = 1), 903 advances at a faster rate when in fast scan forward (high positive 904 scale ratio), decrements when in scan reverse (high negative scale 905 ratio) and is fixed in pause mode. NPT is (logically) equivalent to 906 SMPTE time codes." 908 Examples: 910 npt=123.45-125 911 npt=12:05:35.3- 912 npt=now- 914 The syntax conforms to ISO 8601 [34]. The npt-sec notation 915 is optimized for automatic generation, the ntp-hhmmss 916 notation for consumption by human readers. The "now" 917 constant allows clients to request to receive the live feed 918 rather than the stored or time-delayed version. This is 919 needed since neither absolute time nor zero time are 920 appropriate for this case. 922 3.6 Absolute Time 924 Absolute time is expressed as ISO 8601 [34] timestamps, using UTC 925 (GMT). Fractions of a second may be indicated. 927 Example for November 8, 1996 at 14h37 and 20 and a quarter seconds 928 UTC: 930 19961108T143720.25Z 932 3.7 Feature-tags 934 Feature-tags are unique identifiers used to designate features in 935 RTSP. These tags are used in Require (Section 14.37), Proxy-Require 936 (Section 14.31), Proxy-Supported (Section 14.32), Unsupported 937 (Section 14.46), and Supported (Section 14.43) header fields. 939 Feature tag needs to indicate which combination of clients, servers, 940 or proxies they applies too. 942 The creator of a new RTSP feature-tag should either prefix the 943 feature-tag with a reverse domain name (e.g., 944 "com.example.mynewfeature" is an apt name for a feature whose 945 inventor can be reached at "example.com"), or register the new 946 feature-tag with the Internet Assigned Numbers Authority (IANA), see 947 IANA Section 21. 949 The usage of feature tags are further described in section 10 that 950 deals with capability handling. 952 3.8 Entity Tags 953 Entity tags are opaque strings that are used to compare two entities 954 from the same resource, for example in caches or to optimize setup 955 after a redirect. Further explanation is present in [H3.11]. For 956 explanation on how to compare Entity tags see [H13.3]. Entity tags 957 can be carried in the ETag header (see section 14.21) or in SDP (see 958 section C.1.8). 960 Entity tags are used in RTSP to make some methods conditional. The 961 methods are made conditional through the inclusion of headers, see 962 14.25 and 14.27. 964 4 RTSP Message 966 RTSP is a text-based protocol and uses the ISO 10646 character set in 967 UTF-8 encoding (RFC 2279 [13]). Lines SHALL be terminated by CRLF. 969 Text-based protocols make it easier to add optional 970 parameters in a self-describing manner. Since the number of 971 parameters and the frequency of commands is low, processing 972 efficiency is not a concern. Text-based protocols, if done 973 carefully, also allow easy implementation of research 974 prototypes in scripting languages such as Tcl, Visual Basic 975 and Perl. 977 The 10646 character set avoids tricky character set switching, but is 978 invisible to the application as long as US-ASCII is being used. This 979 is also the encoding used for RTCP. ISO 8859-1 translates directly 980 into Unicode with a high-order octet of zero. ISO 8859-1 characters 981 with the most-significant bit set are represented as 1100001x 982 10xxxxxx. (See RFC 2279 [13]) 984 Requests contain methods, the object the method is operating upon and 985 parameters to further describe the method. Methods are idempotent, 986 unless otherwise noted. Methods are also designed to require little 987 or no state maintenance at the media server. 989 4.1 Message Types 991 See [H4.1]. 993 4.2 Message Headers 995 See [H4.2]. 997 4.3 Message Body 999 See [H4.3] 1001 4.4 Message Length 1003 When a message body is included with a message, the length of that 1004 body is determined by one of the following (in order of precedence): 1006 1. Any response message which MUST NOT include a message body 1007 (such as the 1xx, 204, and 304 responses) is always 1008 terminated by the first empty line after the header fields, 1009 regardless of the entity-header fields present in the 1010 message. (Note: An empty line consists of only CRLF.) 1012 2. If a Content-Length header field (section 14.16) is 1013 present, its value in bytes represents the length of the 1014 message-body. If this header field is not present, a value 1015 of zero is assumed. 1017 Unlike an HTTP message, an RTSP message MUST contain a Content-Length 1018 header field whenever it contains a message body. Note that RTSP does 1019 not (at present) support the HTTP/1.1 "chunked" transfer coding(see 1020 [H3.6.1]). 1022 Given the moderate length of presentation descriptions 1023 returned, the server should always be able to determine its 1024 length, even if it is generated dynamically, making the 1025 chunked transfer encoding unnecessary. 1027 5 General Header Fields 1029 See [H4.5], except that Pragma, Trailer, Transfer-Encoding, Upgrade, 1030 and Warning headers are not defined. RTSP further defines the CSeq, 1031 and Timestamp. The general headers are listed in table 1: 1033 Header Name Comment 1034 _________________________________ 1035 Cache-Control See section 14.10 1036 Connection See section 14.11 1037 CSeq See section 14.19 1038 Date See section 14.20 1039 Supported See section 14.43 1040 Timestamp See section 14.44 1041 Via See section 14.49 1043 Table 1: The General headers used in RTSP. 1045 6 Request 1047 A request messages uses the format outlined below, regardless of the 1048 direction of a request, client to server or server to client: 1050 o Request line, containing the method to be applied to the 1051 resource, the identifier of the resource, and the protocol 1052 version in use; 1054 o zero or more Header lines, that can be of the following types: 1055 general (Section 5), request (Section 6.2), or entity (Section 1056 8.1); 1058 o One empty line (CR/LF) to indicate the end of the header 1059 section; 1061 o Optionally a message body (entity), consisting of one or more 1062 lines. the length of the message body in number of bytes is 1063 indicated by the Content-Length entity header. 1065 6.1 Request Line 1067 The request line provides the key information about the request: 1068 What method, on what resources and using which RTSP version. The 1069 methods that are defined by this specification are listed in Table 2. 1071 Method Defined In Section 1072 _________________________________ 1073 DESCRIBE Section 11.2 1074 GET_PARAMETER Section 11.7 1075 OPTIONS Section 11.1 1076 PAUSE Section 11.5 1077 PLAY Section 11.4 1078 REDIRECT Section 11.9 1079 SETUP Section 11.3 1080 SET_PARAMETER Section 11.8 1081 TEARDOWN Section 11.6 1083 Table 2: The RTSP Methods 1085 The syntax of the RTSP request line is the following: 1087 SP SP CRLF 1088 Note: This syntax cannot be freely changed in future versions of 1089 RTSP. This line needs to remain parsable by older RTSP 1090 implementations since it indicates the RTSP version of the message. 1092 In contrast to HTTP/1.1 [3], RTSP requests identify the resource 1093 through an absolute RTSP URI (scheme, host, and port)(see section 1094 3.2) rather than just the absolute path. 1096 HTTP/1.1 requires servers to understand the absolute URI, 1097 but clients are supposed to use the Host request header. 1098 This is purely needed for backward-compatibility with 1099 HTTP/1.0 servers, a consideration that does not apply to 1100 RTSP. 1102 An asterisk "*" can be used in the Request-URI to indicate that the 1103 request does not apply to a particular resource, but to the server or 1104 proxy itself, and is only allowed when the request method does not 1105 necessarily apply to a resource. 1107 For example: 1109 OPTIONS * RTSP/2.0 1111 An OPTIONS in this form will determine the capabilities of the server 1112 or the proxy that first receives the request. If the capability of 1113 the specific server needs to be determined, without regard to the 1114 capability of an intervening proxy, the server should be addressed 1115 explicitly with an absolute URI that contains the server's address. 1117 For example: 1119 OPTIONS rtsp://example.com RTSP/2.0 1121 6.2 Request Header Fields 1123 The RTSP headers in Table 3 can be included in a request, as request 1124 headers, to modify the specifics of the request. These headers may 1125 also be used in the response to a request, as response headers, to 1126 modify the specifics of a response (Section 7.1.2). 1128 Detailed headers definition are provided in Section 14. 1130 Header Defined in Section 1131 _____________________________________ 1132 Accept Section 14.1 1133 Accept-Encoding Section 14.3 1134 Accept-Language Section 14.4 1135 Authorization Section 14.7 1136 Bandwidth Section 14.8 1137 Blocksize Section 14.9 1138 From Section 14.23 1139 If-Match Section 14.25 1140 If-Modified-Since Section 14.26 1141 If-None-Match Section 14.27 1142 Proxy-Require Section 14.31 1143 Range Section 14.34 1144 Referer Section 14.35 1145 Require Section 14.37 1146 Scale Section 14.39 1147 Session Section 14.42 1148 Speed Section 14.40 1149 Supported Section 14.43 1150 Transport Section 14.45 1151 User-Agent Section 14.47 1153 Table 3: The RTSP request headers 1155 7 Response 1157 [H6] applies except that HTTP-Version is replaced by RTSP-Version. 1158 Also, RTSP defines additional status codes and does not define some 1159 HTTP codes. The valid response codes and the methods they can be used 1160 with are defined in Table 4. 1162 After receiving and interpreting a request message, the recipient 1163 responds with an RTSP response message. 1165 7.1 Status-Line 1167 The first line of a Response message is the Status-Line, consisting 1168 of the protocol version followed by a numeric status code, and the 1169 textual phrase associated with the status code, with each element 1170 separated by SP characters. No CR or LF is allowed except in the 1171 final CRLF sequence. 1173 SP SP CRLF 1175 7.1.1 Status Code and Reason Phrase 1177 The Status-Code element is a 3-digit integer result code of the 1178 attempt to understand and satisfy the request. These codes are fully 1179 defined in Section 13. The Reason-Phrase is intended to give a short 1180 textual description of the Status-Code. The Status-Code is intended 1181 for use by automata and the Reason-Phrase is intended for the human 1182 user. The client is not required to examine or display the Reason- 1183 Phrase. 1185 The first digit of the Status-Code defines the class of response. The 1186 last two digits do not have any categorization role. There are 5 1187 values for the first digit: 1189 o 1xx: Informational - Request received, continuing process 1191 o 2xx: Success - The action was successfully received, 1192 understood, and accepted 1194 o 3rr: Redirection - Further action needs to be taken in order 1195 to complete the request 1197 o 4xx: Client Error - The request contains bad syntax or cannot 1198 be fulfilled 1200 o 5xx: Server Error - The server failed to fulfill an apparently 1201 valid request 1203 The individual values of the numeric status codes defined for 1204 RTSP/2.0, and an example set of corresponding Reason-Phrases, are 1205 presented in table 4. The reason phrases listed here are only 1206 recommended; they may be replaced by local equivalents without 1207 affecting the protocol. Note that RTSP adopts most HTTP/1.1 [3] 1208 status codes and adds RTSP-specific status codes starting at x50 to 1209 avoid conflicts with newly defined HTTP status codes. 1211 RTSP status codes are extensible. RTSP applications are not required 1212 to understand the meaning of all registered status codes, though such 1213 understanding is obviously desirable. However, applications MUST 1214 understand the class of any status code, as indicated by the first 1215 digit, and treat any unrecognized response as being equivalent to the 1216 x00 status code of that class, with the exception that an 1217 unrecognized response MUST NOT be cached. For example, if an 1218 unrecognized status code of 431 is received by the client, it can 1219 safely assume that there was something wrong with its request and 1220 treat the response as if it had received a 400 status code. In such 1221 cases, user agents SHOULD present to the user the entity returned 1222 with the response, since that entity is likely to include human- 1223 readable information which will explain the unusual status. 1225 7.1.2 Response Header Fields 1227 The response-header fields allow the request recipient to pass 1228 additional information about the response which cannot be placed in 1229 the Status-Line. These header fields give information about the 1230 server and about further access to the resource identified by the 1231 Request-URI. All headers currently being classified as response 1232 headers are listed in table 5. 1234 Response-header field names can be extended reliably only in 1235 combination with a change in the protocol version. However, new or 1236 experimental header fields MAY be given the semantics of response- 1237 header fields if all parties in the communication recognize them to 1238 be response-header fields. Unrecognized header fields are treated as 1239 entity-header fields. 1241 8 Entity 1243 Request and Response messages MAY transfer an entity if not otherwise 1244 restricted by the request method or response status code. An entity 1245 consists of entity-header fields and an entity-body, although some 1246 responses will only include the entity-headers. 1248 The SET_PARAMETER, and GET_PARAMETER request and response, and 1249 DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY 1250 also have an entity. 1252 In this section, both sender and recipient refer to either the client 1253 or the server, depending on who sends and who receives the entity. 1255 8.1 Entity Header Fields 1257 Entity-header fields define optional meta-information about the 1258 entity-body or, if no body is present, about the resource identified 1259 by the request. The entity header fields are listed in table 8.1. 1261 The extension-header mechanism allows additional entity-header fields 1262 to be defined without changing the protocol, but these fields cannot 1263 be assumed to be recognizable by the recipient. Unrecognized header 1264 fields SHOULD be ignored by the recipient and forwarded by proxies. 1266 8.2 Entity Body 1267 See [H7.2] with the addition that an RTSP message with an entity body 1268 MUST include the Content-Type and Content-Length headers. 1270 9 Connections 1272 RTSP requests can be transmitted over two different connection 1273 scenarios listed below: 1275 o persistent - transport connections used for several 1276 request/response transactions; 1278 o transient - transport connections used for a single 1279 request/response transaction. 1281 RFC 2326 attempted to specify an optional mechanism for transmitting 1282 RTSP messages in connectionless mode over a transport protocol such 1283 as UDP. However, it was not specified in sufficient enough detail to 1284 allow for interoperable implementations. In an attempt to reduce 1285 complexity and scope, and due to lack of interest, RTSP 2.0 does not 1286 attempt to define a mechanism for supporting RTSP over UDP or other 1287 connectionless transport protocols. A side-effect is that RTSP 1288 requests SHALL NOT be sent to multicast groups since no connection 1289 can be established with a specific receiver in multicast 1290 environments. 1292 Certain RTSP headers, such as the CSeq header (Section 14.19), which 1293 may appear to be relevant to only connectionless transport scenarios 1294 are still retained and must be implemented according to the 1295 specification. In the case of CSeq it is quite useful in proxy 1296 situations for keeping track of the different request when 1297 aggregating several client requests to a single TCP connection. 1299 9.1 Reliability and Acknowledgements 1301 Since RTSP is transmitted primarily over connection oriented, 1302 reliable transport protocols, all RTSP requests MUST be acknowledged 1303 by the receiver. RTSP requests that are not immediately acknowledged 1304 MUST NOT be retransmitted at the application level. Instead, the 1305 application must rely on the underlying transport to provide 1306 reliability. 1308 If both the underlying reliable transport such as TCP and 1309 the RTSP application retransmit requests, each packet loss 1310 or message loss may result in two retransmissions. The 1311 receiver typically cannot take advantage of the 1312 application-layer retransmission since the transport stack 1313 will not deliver the application-layer retransmission 1314 Code Reason Method 1315 __________________________________________________________ 1316 100 Continue all 1318 __________________________________________________________ 1319 200 OK all 1320 201 Reserved n/a 1321 250 Reserved n/a 1322 __________________________________________________________ 1323 300 Multiple Choices all 1324 301 Moved Permanently all 1325 302 Found all 1326 303 See Other all 1327 305 Use Proxy all 1329 __________________________________________________________ 1330 400 Bad Request all 1331 401 Unauthorized all 1332 402 Payment Required all 1333 403 Forbidden all 1334 404 Not Found all 1335 405 Method Not Allowed all 1336 406 Not Acceptable all 1337 407 Proxy Authentication Required all 1338 408 Request Timeout all 1339 410 Gone all 1340 411 Length Required all 1341 412 Precondition Failed DESCRIBE, SETUP 1342 413 Request Entity Too Large all 1343 414 Request-URI Too Long all 1344 415 Unsupported Media Type all 1345 451 Parameter Not Understood SET_PARAMETER 1346 452 reserved n/a 1347 453 Not Enough Bandwidth SETUP 1348 454 Session Not Found all 1349 455 Method Not Valid In This State all 1350 456 Header Field Not Valid all 1351 457 Invalid Range PLAY, PAUSE 1352 458 Parameter Is Read-Only SET_PARAMETER 1353 459 Aggregate Operation Not Allowed all 1354 460 Only Aggregate Operation Allowed all 1355 461 Unsupported Transport all 1356 462 Destination Unreachable all 1357 463 Destination Prohibited SETUP 1358 470 Connection Authorization Required all 1359 471 Connection Credentials not accepted all 1360 __________________________________________________________ 1361 500 Internal Server Error all 1362 501 Not Implemented all 1363 502 Bad Gateway all 1364 503 Service Unavailable all 1365 504 Gateway Timeout all 1367 Table 4: Status codes and their usage with RTSP methods 1369 Header Defined in Section 1370 __________________________________________ 1371 Accept-Ranges Section 14.5 1372 Connection-Credentials Section 14.12 1373 ETag Section 14.21 1374 Location Section 14.29 1375 Proxy-Authenticate Section 14.30 1376 Public Section 14.33 1377 Range Section 14.34 1378 Retry-After Section 14.36 1379 RTP-Info Section 14.38 1380 Scale Section 14.39 1381 Session Section 14.42 1382 Server Section 14.41 1383 Speed Section 14.40 1384 Transport Section 14.45 1385 Unsupported Section 14.46 1386 Vary Section 14.48 1387 WWW-Authenticate Section 14.50 1389 Table 5: The RTSP response headers 1391 Header Defined in Section 1393 ____________________________________ 1394 Allow Section 14.6 1395 Content-Base Section 14.13 1396 Content-Encoding Section 14.14 1397 Content-Language Section 14.15 1398 Content-Length Section 14.16 1399 Content-Location Section 14.17 1400 Content-Type Section 14.18 1401 Expires Section 14.22 1402 Last-Modified Section 14.28 1404 Table 6: The RTSP entity headers 1406 before the first attempt has reached the receiver. If the 1407 packet loss is caused by congestion, multiple 1408 retransmissions at different layers will exacerbate the 1409 congestion. 1411 Lack of acknowledgement of an RTSP request should be handled within 1412 the constraints of the connection timeout considerations described 1413 below (Section 9.4). 1415 9.2 Using Connections 1417 A TCP transport can be used for both persistent connections (for 1418 several message exchanges) and transient connections (for a single 1419 message exchange). Implementations of this specification MUST support 1420 RTSP over TCP. The scheme of the RTSP URI (Section 3.2) indicates the 1421 default port that the server will listen on. 1423 A server MUST handle both persistent and transient connections. 1425 Transient connections facilitate mechanisms for fault 1426 tolerance. They also allow for application layer mobility. 1427 A server and client pair that support transient connections 1428 can survive the loss of a TCP connection, e.g. due to a NAT 1429 timeout. When the client has discovered that the TCP 1430 connection has been lost, it can set up a new one when 1431 there is need to communicate again. 1433 A persistent connection MAY be used for all transactions between the 1434 server and client, including messages to multiple RTSP sessions. 1435 However a persistent connection MAY also be closed after a few 1436 message exchanges. For example, a client may use a persistent 1437 connection for the initial SETUP and PLAY message exchanges in a 1438 session and then close the connection. Later, when the client wishes 1439 to send a new request, such as a PAUSE for the session, a new 1440 connection would be opened. This connection may either be transient 1441 or persistent. 1443 A client SHOULD NOT have more than one connection to the server at 1444 any given point. If a client or proxy handles multiple RTSP sessions 1445 on the same server, it SHOULD use only one connection for managing 1446 those sessions. 1448 This saves connection resources on the server. It also 1449 reduces complexity by and enabling the server to maintain 1450 less state about its sessions and connections. 1452 Unlike HTTP, RTSP allows a server to send requests to a client. 1453 However, this can be supported only if a client establishes a 1454 persistent connection with the server. In cases where a persistent 1455 connection does not exist between a server and its client, due to the 1456 lack of a signalling channel, the server may be forced to drop an 1457 RTSP session without notifying the client. An example of such a case 1458 is when the server desires to send a REDIRECT request for an RTSP 1459 session to the client but is not able to do so because it cannot 1460 reach the client. 1462 Without a persistent connection between the client and the 1463 server, the media server has no reliable way of reaching 1464 the client. Also, this is the only way that requests from a 1465 server to its client are likely to traverse firewalls. 1467 In light of the above, it is RECOMMENDED that clients use persistent 1468 connections whenever possible. A client that supports persistent 1469 connections MAY "pipeline" its requests (i.e., send multiple requests 1470 without waiting for each response). A server MUST send its responses 1471 to those requests in the order that the requests were received. 1473 9.3 Closing Connections 1475 The client MAY close a connection at any point when no outstanding 1476 request/response transactions exist for any RTSP session being 1477 managed through the connection. The server, however, SHOULD NOT close 1478 a connection until all RTSP sessions being managed through the 1479 connection have been timed out (Section 14.42). A server SHOULD NOT 1480 close a connection immediately after responding to a session-level 1481 TEARDOWN request for the last RTSP session being controlled through 1482 the connection. Instead, it should wait for a reasonable amount of 1483 time for the client to: receive the TEARDOWN response, take 1484 appropriate action, and initiate the connection closing. The server 1485 SHOULD wait at least 10 seconds after sending the TEARDOWN response 1486 before closing the connection. 1488 This is to ensure that the client has time to issue a SETUP 1489 for a new session on the existing connection after having 1490 torn the last one down. 10 seconds should give the client 1491 ample opportunity get its message to the server. 1493 A server SHOULD NOT close the connection directly as a result of 1494 responding to a request with an error code. 1496 Certain error responses such as "460 Only Aggregate 1497 Operation Allowed" (Section 13.4.12) are used for 1498 negotiating capabilities of a server with respect to 1499 content or other factors. In such cases, it is inefficient 1500 for the server to close a connection on an error response. 1501 Also, such behavior would prevent implementation of 1502 advanced/special types of requests or result in extra 1503 overhead for the client when testing for new features. On 1504 the flip side, keeping connections open after sending an 1505 error response poses a Denial of Service security risk 1506 (Section 20). 1508 If a server initiates a connection close while the client is 1509 attempting to send a new request, the client will have to close its 1510 current connection, establish a new connection and send its request 1511 over the new connection. 1513 An RTSP message should not be terminated through a connection close. 1514 Such a message will be considered to be incomplete by the receiver 1515 and discarded. An RTSP message is properly terminated as defined in 1516 Section 4. 1518 9.4 Timing Out Connections and RTSP Messages 1520 Receivers of a request (responder) SHOULD respond to requests in a 1521 timely manner even when a reliable transport such as TCP is used. 1522 Similarly, the sender of a request (requestor) SHOULD wait for a 1523 sufficient time for a response before concluding that the responder 1524 will not be acting upon its request. 1526 A responder SHOULD respond to all requests within 5 seconds. If the 1527 responder recognizes that processing of a request will take longer 1528 than 5 seconds, it SHOULD send a 100 response as soon as possible. It 1529 SHOULD continue sending a 100 response every 5 seconds thereafter 1530 until it is ready to send the final response to the requestor. After 1531 sending a 100 response, the receiver MUST send a final response 1532 indicating the success or failure of the request. 1534 A requestor SHOULD wait at least 10 seconds for a response before 1535 concluding that the responder will not be responding to its request. 1536 After receiving a 100 response, the requestor SHOULD continue waiting 1537 for further responses. If more than 10 seconds elapses without 1538 receiving any response, the requestor MAY assume that the responder 1539 is unresponsive and abort the connection. 1541 A requestor SHOULD wait longer than 10 seconds for a response if it 1542 is experiencing significant transport delays on its connection to the 1543 responder. The requestor is capable of determining the RTT of the 1544 request/response cycle using the Timestamp header (section 14.44) in 1545 any RTSP request. 1547 9.5 Use of IPv6 1549 Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP 1550 2.0 has been updated for explicit IPv6 support. Implementations of 1551 RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. 1553 10 Capability Handling 1555 This section describes the capability handling mechanism available in 1556 RTSP which allows RTSP to be extended. Extensions to this version of 1557 the protocol are basically done in two ways. First, new headers can 1558 be added. Secondly, new methods can be added. The capability handling 1559 mechanism is designed to handle both cases. 1561 When a method is added, the involved parties can use the OPTIONS 1562 method to discover wether it is supported. This is done by issuing a 1563 OPTIONS request to the other party. Depending on the URI it will 1564 either apply in regards to a certain media resource, the whole server 1565 in general, or simply the next hop. The OPTIONS response will contain 1566 a Public header which declares all methods supported for the 1567 indicated resource. 1569 It is not necessary to use OPTIONS to discover support of a method, 1570 the client could simply try the method. If the receiver of the 1571 request does not support the method it will respond with an error 1572 code indicating the the method is either not implemented (501) or 1573 does not apply for the resource (405). The choice between the two 1574 discovery methods depends on the requirements of the service. 1576 Feature-Tags are defined to handle functionality additions that are 1577 not new methods. Each feature-tag represents a certain block of 1578 functionality. The amount of functionality that a feature-tag 1579 represents can vary significantly. A feature-tag can for example 1580 represent the functionality a single RTSP header provides. Another 1581 feature-tag can represent much more functionality, such as the 1582 "play.basic" feature tag which represents the minimal playback 1583 implementation. 1585 Feature-tags are used to determine wether the client, server or proxy 1586 supports the functionality that is necessary to achieve the desired 1587 service. To determine support of a feature-tag, several different 1588 headers can be used, each explained below: 1590 Supported: The supported header is used to determine the 1591 complete set of functionality that both client and server 1592 have. The intended usage is to determine before one needs 1593 to use a functionality that it is supported. It can be used 1594 in any method, however OPTIONS is the most suitable one as 1595 it at the same time determines all methods that are 1596 implemented. When sending a request the requestor declares 1597 all its capabilities by including all supported feature- 1598 tags. This results in that the receiver learns the 1599 requestors feature support. The receiver then includes its 1600 set of features in the response. 1602 Proxy-Supported: The Proxy-Supported header is used similar to 1603 the Supported header, but instead of giving the supported 1604 functionality of the client or server it provides both the 1605 requestor and the responder a view of what functionality 1606 the proxy chain between the two supports. Proxies are 1607 required to add this header whenever the Supported header 1608 is present, but proxies may independently of the requestor 1609 add it. 1611 Require: The Require header can be included in any request where 1612 the end-point, i.e. the client or server, is required to 1613 understand the feature to correctly perform the request. 1614 This can, for example, be a SETUP request where the server 1615 is required to understand a certain parameter to be able to 1616 set up the media delivery correctly. Ignoring this 1617 parameter would not have the desired effect and is not 1618 acceptable. Therefore the end-point receiving a request 1619 containing a Require MUST negatively acknowledge any 1620 feature that it does not understand and not perform the 1621 request. The response in cases where features are not 1622 supported are 551 (Option Not Supported). Also the 1623 features that are not supported are given in the 1624 Unsupported header in the response. 1626 Proxy-Require: This method has the same purpose and workings as 1627 Require except that it only applies to proxies and not the 1628 end-point. Features that needs to be supported by both 1629 proxies and end-point needs to be included in both the 1630 Require and Proxy-Require header. 1632 Unsupported: This header is used in a 551 error response, to 1633 indicate which feature(s) that was not supported. Such a 1634 response is only the result of the usage of the Require 1635 and/or Proxy-Require header where one or more feature where 1636 not supported. This information allows the requestor to 1637 make the best of situations as it knows which features are 1638 not supported. 1640 11 Method Definitions 1642 The method indicates what is to be performed on the resource 1643 identified by the Request-URI. The method name is case-sensitive. 1644 New methods may be defined in the future. Method names SHALL NOT 1645 start with a $ character (decimal 24) and MUST be a token as defined 1646 by the ABNF [4] in the syntax chapter 19. The methods are summarized 1647 in Table 7. 1649 method direction object Server req. Client req. 1650 ___________________________________________________________________ 1651 DESCRIBE C -> S P,S recommended recommended 1652 GET_PARAMETER C -> S, S -> C P,S optional optional 1653 OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt 1654 PAUSE C -> S P,S required required 1655 PLAY C -> S P,S required required 1656 REDIRECT S -> C P,S optional required 1657 SETUP C -> S S required required 1658 SET_PARAMETER C -> S, S -> C P,S required optional 1659 TEARDOWN C -> S P,S required required 1661 Table 7: Overview of RTSP methods, their direction, and what objects 1662 (P: presentation, S: stream) they operate on. Legend: R=Respond, 1663 Sd=Send, Opt: Optional, Req: Required, Rec: Recommended 1665 Note on Table 7: GET_PARAMETER is recommended, but not 1666 required. For example, a fully functional server can be 1667 built to deliver media without any parameters. 1668 SET_PARAMETER is required however due to its usage for 1669 keep-alive. PAUSE is now required due to that it is the 1670 only way of getting out of the state machines play state 1671 without terminating the whole session. 1673 If an RTSP agent does not support a particular method, it MUST return 1674 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 1675 NOT try this method again for the given agent / resource combination. 1677 11.1 OPTIONS 1679 The semantics of the RTSP OPTIONS method is equivalent to that of the 1680 HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is 1681 bi-directional, in that a client can request it to a server and vice 1682 versa. A client MUST implement the capability to send an OPTIONS 1683 request and a server or a proxy MUST implement the capability to 1684 respond to an OPTIONS request. The client, server or proxy MAY also 1685 implement the converse of their required capability. 1687 An OPTIONS request may be issued at any time. Such a request does not 1688 modify the session state. However, it may prolong the session 1689 lifespan (see below). The URI in an OPTIONS request determines the 1690 scope of the request and the corresponding response. If the Request- 1691 URI refers to a specific media resource on a given host, the scope is 1692 limited to the set of methods supported for that media resource by 1693 the indicated RTSP agent. A Request-URI with only the host address 1694 limits the scope to the specified RTSP agent's general capabilities 1695 without regard to any specific media. If the Request-URI is an 1696 asterisk ("*"), the scope is limited to the general capabilities of 1697 the next hop (i.e. the RTSP agent in direct communication with the 1698 request sender). 1700 Regardless of scope of the request, the Public header MUST always be 1701 included in the OPTIONS response listing the methods that are 1702 supported by the responding RTSP agent. In addition, if the scope of 1703 the request is limited to a media resource, the Allow header MUST be 1704 included in the response to enumerate the set of methods that are 1705 allowed for that resource unless the set of methods completely 1706 matches the set in the Public header. If the given resource is not 1707 available, the RTSP agent SHOULD return an appropriate response code 1708 such as 3rr or 4xx. The Supported header MAY be included in the 1709 request to query the set of features that are supported by the 1710 responding RTSP agent. 1712 The OPTIONS method can be used to keep an RTSP session alive. 1713 However, it is not the preferred means of session keep-alive 1714 signalling, see section 14.42. An OPTIONS request intended for 1715 keeping alive an RTSP session MUST include the Session header with 1716 the associated session ID. Such a request SHOULD also use the media 1717 or the aggregated control URI as the Request-URI. 1719 Example: 1721 C->S: OPTIONS * RTSP/2.0 1722 CSeq: 1 1723 User-Agent: PhonyClient/1.2 1724 Require: 1725 Proxy-Require: gzipped-messages 1726 Supported: play.basic 1728 S->C: RTSP/2.0 200 OK 1729 CSeq: 1 1730 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 1731 Supported: play.basic, implicit-play, gzipped-messages 1732 Server: PhonyServer/1.1 1734 Note that some of the feature-tags in Require and Proxy-Require are 1735 necessarily fictional features (one would hope that we would not 1736 purposefully overlook a truly useful feature just so that we could 1737 have a strong example in this section). 1739 11.2 DESCRIBE 1740 The DESCRIBE method is used to retrieve the description of a 1741 presentation or media object from a server. The Request-URI of the 1742 DESCRIBE request identifies the media resource of interest. The 1743 client MAY include the Accept header in the request to list the 1744 description formats that it understands. The server SHALL respond 1745 with a description of the requested resource and return the 1746 description in the entity of the response. The DESCRIBE reply- 1747 response pair constitutes the media initialization phase of RTSP. 1749 Example: 1751 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 1752 CSeq: 312 1753 User-Agent: PhonyClient 1.2 1754 Accept: application/sdp, application/rtsl, application/mheg 1756 S->C: RTSP/2.0 200 OK 1757 CSeq: 312 1758 Date: 23 Jan 1997 15:35:06 GMT 1759 Server: PhonyServer 1.1 1760 Content-Type: application/sdp 1761 Content-Length: 367 1763 v=0 1764 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1765 s=SDP Seminar 1766 i=A Seminar on the session description protocol 1767 u=http://www.example.com/lectures/sdp.ps 1768 e=seminar@example.com (Seminar Management) 1769 c=IN IP4 224.2.17.12/127 1770 t=2873397496 2873404696 1771 a=recvonly 1772 m=audio 3456 RTP/AVP 0 1773 m=video 2232 RTP/AVP 31 1774 m=application 32416 UDP WB 1775 a=orient:portrait 1777 The DESCRIBE response SHOULD contain all media initialization 1778 information for the resource(s) that it describes. Servers SHOULD NOT 1779 use the DESCRIBE response as a means of media indirection by having 1780 the description point at another server, instead usage of 3rr 1781 responses are recommended. 1783 By forcing a DESCRIBE response to contain all media 1784 initialization for the set of streams that it describes, 1785 and discouraging the use of DESCRIBE for media indirection, 1786 any looping problems can be avoided that might have 1787 resulted from other approaches. 1789 Media initialization is a requirement for any RTSP-based system, but 1790 the RTSP specification does not dictate that this is required to be 1791 done via the DESCRIBE method. There are three ways that an RTSP 1792 client may receive initialization information: 1794 o via an RTSP DESCRIBE request 1796 o via some other protocol (HTTP, email attachment, etc.) 1798 o via some form of a user interface 1800 If a client obtains a valid description from an alternate source, the 1801 client MAY use this description for initialization purposes without 1802 issuing a DESCRIBE request for the same media. 1804 It is RECOMMENDED that minimal servers support the DESCRIBE method, 1805 and highly recommended that minimal clients support the ability to 1806 act as "helper applications" that accept a media initialization file 1807 from a user interface, and/or other means that are appropriate to the 1808 operating environment of the clients. 1810 11.3 SETUP 1812 The SETUP request for an URI specifies the transport mechanism to be 1813 used for the streamed media. The SETUP method may be used in three 1814 different cases; Create an RTSP session, add a media to a session, 1815 and change the transport parameters of already set up media stream. 1816 When in PLAY state, using SETUP to create or add media to a session 1817 when in PLAY state is unspecified. Otherwise SETUP can be used in all 1818 three states; INIT, and READY, for both purposes and in PLAY to 1819 change the transport parameters. 1821 The Transport header, see section 14.45, specifies the transport 1822 parameters acceptable to the client for data transmission; the 1823 response will contain the transport parameters selected by the 1824 server. This allows the client to enumerate in priority order the 1825 transport mechanisms and parameters acceptable to it, while the 1826 server can select the most appropriate. It is expected that the 1827 session description format used will enable the client to select a 1828 limited number possible configurations that are offered to the server 1829 to choose from. All transport parameters SHOULD be included in the 1830 Transport header, the use of other headers for this purpose is 1831 discouraged due to middle boxes such as firewalls, or NATs. 1833 For the benefit of any intervening firewalls, a client SHOULD 1834 indicate the transport parameters even if it has no influence over 1835 these parameters, for example, where the server advertises a fixed 1836 multicast address. 1838 Since SETUP includes all transport initialization 1839 information, firewalls and other intermediate network 1840 devices (which need this information) are spared the more 1841 arduous task of parsing the DESCRIBE response, which has 1842 been reserved for media initialization. 1844 In a SETUP response the server SHOULD include the Accept-Ranges 1845 header (see section 14.5 to indicate which time formats that are 1846 acceptable to use for this media resource. 1848 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 1849 CSeq: 302 1850 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", 1851 RTP/AVP/TCP;unicast;interleaved=0-1 1853 S->C: RTSP/2.0 200 OK 1854 CSeq: 302 1855 Date: 23 Jan 1997 15:35:06 GMT 1856 Server: PhonyServer 1.1 1857 Session: 47112344;timeout=60 1858 Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; 1859 src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; 1860 ssrc=2A3F93ED 1861 Accept-Ranges: NPT 1863 In the above example the client wants to create an RTSP session 1864 containing the media resource "rtsp://example.com/foo/bar/baz.rm". 1865 The transport parameters acceptable to the client is either 1866 RTP/AVP/UDP (UDP per default) to be received on client port 4588 and 1867 4589 or RTP/AVP interleaved on the RTSP control channel. The server 1868 selects the RTP/AVP/UDP transport and adds the ports it will send and 1869 received RTP and RTCP from, and the RTP SSRC that will be used by the 1870 server. 1872 The server MUST generate a session identifier in response to a 1873 successful SETUP request, unless a SETUP request to a server includes 1874 a session identifier, in which case the server MUST bundle this setup 1875 request into the existing session (aggregated session) or return 1876 error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11). 1878 An Aggregate control URI MUST be used to control an aggregated 1879 session. This URI MUST be different from the stream control URIs of 1880 the individual media streams included in the aggregate. The Aggregate 1881 control URI is to be specified by the session description if the 1882 server supports aggregated control and aggregated control is desired 1883 for the session. However even if aggregated control is offered the 1884 client MAY chose to not set up the session in aggregated control. If 1885 an Aggregate control URI is not specified in the session description, 1886 it is normally an indication that non-aggregated control should be 1887 used. The SETUP of media streams in an aggregate which has not been 1888 given an aggregated control URI is unspecified. 1890 While the session ID sometimes has enough information for 1891 aggregate control of a session, the Aggregate control URI 1892 is still important for some methods such as SET_PARAMETER 1893 where the control URI enables the resource in question to 1894 be easily identified. The Aggregate control URI is also 1895 useful for proxies, enabling them to route the request to 1896 the appropriate server, and for logging, where it is useful 1897 to note the actual resource that a request was operating 1898 on. 1900 A session will exist until it is either removed by a TEARDOWN request 1901 or is timed-out by the server. The server MAY remove a session that 1902 has not demonstrated liveness signs from the client(s) within a 1903 certain timeout period. The default timeout value is 60 seconds; the 1904 server MAY set this to a different value and indicate so in the 1905 timeout field of the Session header in the SETUP response. For 1906 further discussion see section 14.42. Signs of liveness for an RTSP 1907 session are: 1909 o Any RTSP request from a client(s) which includes a Session 1910 header with that session's ID. 1912 o If RTP is used as a transport for the underlying media 1913 streams, an RTCP sender or receiver report from the client(s) 1914 for any of the media streams in that RTSP session. RTCP Sender 1915 Reports may for example be received in sessions where the 1916 server is invited into a conference session and is as valid 1917 for keep-alive. 1919 If a SETUP request on a session fails for any reason, the session 1920 state, as well as transport and other parameters for associated 1921 streams SHALL remain unchanged from their values as if the SETUP 1922 request had never been received by the server. 1924 11.3.1 Changing Transport Parameters 1925 A client MAY issue a SETUP request for a stream that is already set 1926 up or playing in the session to change transport parameters, which a 1927 server MAY allow. If it does not allow changing of parameters, it 1928 MUST respond with error 455 (Method Not Valid In This State). Reasons 1929 to support changing transport parameters, is to allow for application 1930 layer mobility and flexibility to utilize the best available 1931 transport as it becomes available. If a client receives a 455 when 1932 trying to change transport parameters while the server is in play 1933 state, it MAY try to put the server in ready state using PAUSE. 1934 Before trying issuing the SETUP request again. If also that fails the 1935 changing of transport parameters will require that the client 1936 performs a TEARDOWN of the affected media and then setting it up 1937 again. In aggregated session avoiding tearing down all the media at 1938 the same time will avoid the creation of a new session. 1940 All transport parameters MAY be changed. However the primary usage 1941 expected is to either change transport protocol completely, like 1942 switching from Interleaved TCP mode to RTP or vise versa or change 1943 delivery address. 1945 In a SETUP response for a request to change the transport parameters 1946 while in Play state, the server SHOULD include the Range to indicate 1947 from what point the new transport parameters are used. Further, if 1948 RTP is used for delivery, the server SHOULD also include the RTP-Info 1949 header to indicate from what timestamp and RTP sequence number the 1950 change has taken place. If both RTP-Info and Range is included in the 1951 response the "rtp_time" parameter and range MUST be for the 1952 corresponding time, i.e. be used in the same way as for PLAY to 1953 ensure the correct synchronization information is available. 1955 If the transport parameters change while in PLAY state results in a 1956 change of synchronization related information, for example changing 1957 RTP SSRC, the server MUST provide in the SETUP response the necessary 1958 synchronization information. However the server is RECOMMENDED to 1959 avoid changing the synchronization information if possible. 1961 11.4 PLAY 1963 The PLAY method tells the server to start sending data via the 1964 mechanism specified in SETUP. A client MUST NOT issue a PLAY request 1965 until any outstanding SETUP requests have been acknowledged as 1966 successful. PLAY requests are valid when the session is in READY or 1967 PLAY states. A PLAY request MUST include a Session header to indicate 1968 which session the request applies to. 1970 In an aggregated session the PLAY request MUST contain an aggregated 1971 control URI. A server SHALL responde with error 460 (Only Aggregate 1972 Operation Allowed) if the client PLAY Request-URI is for one of the 1973 media. The media in an aggregate SHALL be played in sync. If a client 1974 want individual control of the media it needs to use separate RTSP 1975 sessions for each media. 1977 The PLAY request SHALL position the normal play time to the beginning 1978 of the range specified by the Range header and delivers stream data 1979 until the end of the range if given, else to the end of the media is 1980 reached. To allow for precise composition multiple ranges MAY be 1981 specified in one PLAY Request. The range values are valid if all 1982 given ranges are part of any media within the aggregate. If a given 1983 range value points outside of the media, the response SHALL be the 1984 457 (Invalid Range) error code. 1986 The below example will first play seconds 10 through 15, then, 1987 immediately following, seconds 20 to 25, and finally seconds 30 1988 through the end. 1990 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 1991 CSeq: 835 1992 Session: 12345678 1993 Range: npt=10-15, npt=20-25, npt=30- 1995 See the description of the PAUSE request for further examples. 1997 A PLAY request without a Range header is legal. It SHALL start 1998 playing a stream from the beginning (npt=0-) unless the stream has 1999 been paused or is currently playing. If a stream has been paused via 2000 PAUSE, stream delivery resumes at the pause point. If a stream is 2001 currently playing, the new PLAY begins at the current stream 2002 position. The stream SHALL play until the end of the media. 2004 The Range header MUST NOT contain a time parameter. The usage of time 2005 in PLAY method has been deprecated. If a request with time parameter 2006 is received the server SHOULD respond with a 457 (Invalid Range) to 2007 indicate that the time parameter is not supported. 2009 Server MUST include a "Range" header in any PLAY response. The 2010 response MUST use the same format as the request's range header 2011 contained. If no Range header was in the request, the NPT time format 2012 SHOULD be used unless the client showed support for an other format 2013 more appropriate. Also for a session with live media streams the 2014 Range header MUST indicate a valid time. It is RECOMMENDED that 2015 normal play time is used, either the "now" indicator, for example 2016 "npt=now-", or the time since session start as an open interval, e.g. 2017 "npt=96.23-". An absolute time value (clock) for the corresponding 2018 time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock 2019 format SHOULD only be used if client has shown support for it. 2021 A media server only supporting playback MUST support the npt format 2022 and MAY support the clock and smpte formats. 2024 For an on-demand stream, the server MUST reply with the actual range 2025 that will be played back, i.e. for which duration any media (having 2026 content at this time) is delivered. This may differ from the 2027 requested range if alignment of the requested range to valid frame 2028 boundaries is required for the media source. Note that some media 2029 streams in an aggregate may need to be delivered from even earlier 2030 points. Also, some media format have a very long duration per 2031 individual data unit, therefore it might be necessary for the client 2032 to parse the data unit, and select where to start. 2034 Example: Single audio stream (MIDI) 2036 C->S: PLAY rtsp://example.com/audio RTSP/2.0 2037 CSeq: 836 2038 Session: 12345678 2039 Range: npt=7.05- 2041 S->C: RTSP/2.0 200 OK 2042 CSeq: 836 2043 Date: 23 Jan 1997 15:35:06 GMT 2044 Server: PhonyServer 1.0 2045 Range: npt=3.52- 2046 RTP-Info:url="rtsp://example.com/audio" 2047 ssrc=0D12F123:seq=14783;rtptime=2345962545 2049 S->C: RTP Packet TS=2345962545 => NPT=3.52 2050 Duration: 4.15 seconds 2052 In this example the client receives the first media packet that 2053 stretches all the way up and past the requested playtime. Thus, it is 2054 the client's decision if to render to the user the time between 3.52 2055 and 7.05, or to skip it. In most cases it is probably most suitable 2056 to not render that time period. 2058 For live media sources it might be impossible to specify from which 2059 point in time all media streams carrying active content can actually 2060 be delivered. Therefore a server MAY specify a start time (or now-) 2061 in the range header, for which not all media will be available from. 2063 If no range is specified in the request, the start position SHALL 2064 still be returned in the reply. If the medias that are part of an 2065 aggregate has different lengths, the PLAY request SHALL be performed 2066 as long as the given range is valid for any media, for example the 2067 longest media. Media will be sent whenever it is available for the 2068 given play-out point. 2070 A PLAY response MAY include a header(s) carrying synchronization 2071 information. As the information necessary is dependent on the media 2072 transport format, further rules specifying the header and its usage 2073 is needed. For RTP the RTP-Info header is specified, see section 2074 14.38. 2076 After playing the desired range, the presentation does NOT transition 2077 to the READY state, media delivery simply stops. A PAUSE request MUST 2078 be issued before the stream enters the READY state. A PLAY request 2079 while the stream is still in the PLAYING state is legal, and can be 2080 issued without an intervening PAUSE request. Such a request SHALL 2081 replace the current PLAY action with the new one requested, i.e. 2082 being handle the same as the request was received in ready state. In 2083 the case the first time range in Range header has a open start time 2084 (-endtime), the server SHALL continue to play from where it currently 2085 was. 2087 A client desiring to play the media from the beginning MUST send a 2088 PLAY request with a Range header pointing at the beginning, e.g. 2089 npt=0-. If a PLAY request is received without a Range header when 2090 media delivery has stopped at the end, the server SHOULD respond with 2091 a 457 "Invalid Range" error response. In that response the current 2092 pause point in a Range header SHALL be included. 2094 The following example plays the whole presentation starting at SMPTE 2095 time code 0:10:20 until the end of the clip. Note: The RTP-Info 2096 headers has been broken into several lines to fit the page. 2098 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 2099 CSeq: 833 2100 Session: 12345678 2101 Range: smpte=0:10:20- 2103 S->C: RTSP/2.0 200 OK 2104 CSeq: 833 2105 Date: 23 Jan 1997 15:35:06 GMT 2106 Server: PhonyServer 1.0 2107 Range: smpte=0:10:22-0:15:45 2108 RTP-Info:url="rtsp://example.com/twister.en" 2109 ssrc=0D12F123:seq=14783;rtptime=2345962545 2111 For playing back a recording of a live presentation, it may be 2112 desirable to use clock units: 2114 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 2115 CSeq: 835 2116 Session: 12345678 2117 Range: clock=19961108T142300Z-19961108T143520Z 2119 S->C: RTSP/2.0 200 OK 2120 CSeq: 835 2121 Date: 23 Jan 1997 15:35:06 GMT 2122 Server:PhonyServer 1.0 2123 Range: clock=19961108T142300Z-19961108T143520Z 2124 RTP-Info:url="rtsp://example.com/meeting.en" 2125 ssrc=0D12F123:seq=53745;rtptime=484589019 2127 All range specifiers in this specification allow for ranges with 2128 unspecified begin times (e.g. "npt=-30"). When used in a PLAY 2129 request, the server treats this as a request to start/resume playback 2130 from the current pause point, ending at the end time specified in the 2131 Range header. If the pause point is located later than the given end 2132 value, a 457 (Invalid Range) response SHALL be given. 2134 The possibility to replace a current PLAY request with a new one 2135 replaces two RTSP 1.0 functions: 2137 o The queued play functionality described in RFC 2326 [24] is 2138 removed and multiple ranges can be used to achieve a similar 2139 functionality. 2141 o The use of PLAY for keep-alive signaling, i.e. PLAY request 2142 without a range header in PLAY state, has also been 2143 deprecated. Instead a client can use, SET_PARAMETER 2144 (recommended) or OPTIONS (allowed) for keep alive. 2146 11.5 PAUSE 2148 The PAUSE request causes the stream delivery to be interrupted 2149 (halted) temporarily. A PAUSE request MUST be done with the 2150 aggregated control URI for aggregated sessions, resulting in all 2151 media being halted, or the media URI for non-aggregated sessions. 2152 Any attempt to do muting of a single media with an PAUSE request in 2153 an aggregated session SHALL be responded with error 460 (Only 2154 Aggregate Operation Allowed). After resuming playback, 2155 synchronization of the tracks MUST be maintained. Any server 2156 resources are kept, though servers MAY close the session and free 2157 resources after being paused for the duration specified with the 2158 timeout parameter of the Session header in the SETUP message. 2160 Example: 2162 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2163 CSeq: 834 2164 Session: 12345678 2166 S->C: RTSP/2.0 200 OK 2167 CSeq: 834 2168 Date: 23 Jan 1997 15:35:06 GMT 2169 Range: npt=45.76- 2171 The PAUSE request MAY contain a Range header specifying when the 2172 stream or presentation is to be halted. This point is referred to as 2173 the "pause point". The time parameter in the Range MUST NOT be used. 2174 The Range header MUST contain a single value, expressed as the 2175 beginning value an open range. For example, the following clip will 2176 be played from 10 seconds through 21 seconds of the clip's normal 2177 play time, under the assumption that the PAUSE request reaches the 2178 server within 11 seconds of the PLAY request. Note that some lines 2179 has been broken in an non-correct way to fit the page: 2181 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2182 CSeq: 834 2183 Session: 12345678 2184 Range: npt=10-30 2186 S->C: RTSP/2.0 200 OK 2187 CSeq: 834 2188 Date: 23 Jan 1997 15:35:06 GMT 2189 Server: PhonyServer 1.0 2190 Range: npt=10-30 2191 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2192 ssrc=0D12F123:seq=5712;rtptime=934207921, 2193 url="rtsp://example.com/fizzle/videotrack" 2194 ssrc=4FAD8726:seq=57654;rtptime=2792482193 2195 Session: 12345678 2197 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2198 CSeq: 835 2199 Session: 12345678 2200 Range: npt=21- 2202 S->C: RTSP/2.0 200 OK 2203 CSeq: 835 2204 Date: 23 Jan 1997 15:35:09 GMT 2205 Server: PhonyServer 1.0 2206 Range: npt=21- 2207 Session: 12345678 2209 The pause request becomes effective the first time the server is 2210 encountering the time point specified in any of the multiple ranges. 2211 If the Range header specifies a time outside any range from the PLAY 2212 request, the error 457 (Invalid Range) SHALL be returned. If a media 2213 unit (such as an audio or video frame) starts presentation at exactly 2214 the pause point, it is not played. If the Range header is missing, 2215 stream delivery is interrupted immediately on receipt of the message 2216 and the pause point is set to the current normal play time. However, 2217 the pause point in the media stream MUST be maintained. A subsequent 2218 PLAY request without Range header SHALL resume from the pause point 2219 and play until media end. 2221 If the server has already sent data beyond the time specified in the 2222 PAUSE request's Range header, a PLAY without range SHALL resume at 2223 the point in time specified by the PAUSE request's Range header, as 2224 it is assumed that the client has discarded data after that point. 2225 This ensures continuous pause/play cycling without gaps. 2227 The pause point after any PAUSE request SHALL be returned to the 2228 client by adding a Range header with what remains unplayed of the 2229 PLAY request's ranges, i.e. including all the remaining ranges part 2230 of multiple range specification. If one desires to resume playing a 2231 ranged request, one simply includes the Range header from the PAUSE 2232 response. 2234 For example, if the server have a play request for ranges 10 to 15 2235 and 20 to 29 pending and then receives a pause request for NPT 21, it 2236 would start playing the second range and stop at NPT 21. If the pause 2237 request is for NPT 12 and the server is playing at NPT 13 serving the 2238 first play request, the server stops immediately. If the pause 2239 request is for NPT 16, the server returns a 457 error message. To 2240 prevent that the second range is played and the server stops after 2241 completing the first range, a PAUSE request for NPT 20 needs to be 2242 issued. 2244 As another example, if a server has received requests to play ranges 2245 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE 2246 request for NPT=14 would take effect while the server plays the first 2247 range, with the second range effectively being ignored, assuming the 2248 PAUSE request arrives before the server has started playing the 2249 second, overlapping range. Regardless of when the PAUSE request 2250 arrives, it sets the pause point to 14. The below example messages is 2251 for the above case when the PAUSE request arrives before the first 2252 occurrence of NPT=14. 2254 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 2255 CSeq: 834 2256 Session: 12345678 2257 Range: npt=10-15, npt=13-20 2259 S->C: RTSP/2.0 200 OK 2260 CSeq: 834 2261 Date: 23 Jan 1997 15:35:06 GMT 2262 Server: PhonyServer 1.0 2263 Range: npt=10-15, npt=13-20 2264 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" 2265 ssrc=0D12F123:seq=5712;rtptime=934207921, 2266 url="rtsp://example.com/fizzle/videotrack" 2267 ssrc=789DAF12:seq=57654;rtptime=2792482193 2268 Session: 12345678 2270 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2271 CSeq: 835 2272 Session: 12345678 2273 Range: npt=14- 2275 S->C: RTSP/2.0 200 OK 2276 CSeq: 835 2277 Date: 23 Jan 1997 15:35:09 GMT 2278 Server: PhonyServer 1.0 2279 Range: npt=14-15, npt=13-20 2280 Session: 12345678 2282 If a client issues a PAUSE request and the server acknowledges and 2283 enters the READY state, the proper server response, if the player 2284 issues another PAUSE, is still 200 OK. The 200 OK response MUST 2285 include the Range header with the current pause point, even if the 2286 PAUSE request is asking for some other pause point. See examples 2287 below: 2289 Examples: 2291 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2292 CSeq: 834 2293 Session: 12345678 2295 S->C: RTSP/2.0 200 OK 2296 CSeq: 834 2297 Session: 12345678 2298 Date: 23 Jan 1997 15:35:06 GMT 2299 Range: npt=45.76-98.36 2301 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 2302 CSeq: 835 2303 Session: 12345678 2304 Range: 86- 2306 S->C: RTSP/2.0 200 OK 2307 CSeq: 835 2308 Session: 12345678 2309 Date: 23 Jan 1997 15:35:07 GMT 2310 Range: npt=45.76-98.36 2312 11.6 TEARDOWN 2314 The TEARDOWN client to server request stops the stream delivery for 2315 the given URI, freeing the resources associated with it. A TEARDOWN 2316 request MAY be performed on either an aggregated or a media control 2317 URI. However some restrictions apply depending on the current state. 2318 The TEARDOWN request SHALL contain a Session header indicating what 2319 session the request applies to. 2321 A TEARDOWN using the aggregated control URI or the media URI in a 2322 session under non-aggregated control MAY be done in any state (Ready, 2323 and Play). A successful request SHALL result in that media delivery 2324 is immediately halted and the session state is destroyed. This SHALL 2325 be indicated through the lack of a Session header in the response. 2327 A TEARDOWN using a media URI in an aggregated session MAY only be 2328 done in Ready state. Such a request only removes the indicated media 2329 stream and associated resources from the session. This may result in 2330 that a session returns to non-aggregated control, due to that it only 2331 contains a single media after the requests completion. A session that 2332 will exist after the processing of the TEARDOWN request SHALL in the 2333 response to that TEARDOWN request contain a Session header. Thus the 2334 presence of the Session indicates to the receiver of the response if 2335 the session is still existing or has been removed. 2337 Example: 2339 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 2340 CSeq: 892 2341 Session: 12345678 2343 S->C: RTSP/2.0 200 OK 2344 CSeq: 892 2345 Server: PhonyServer 1.0 2347 11.7 GET_PARAMETER 2349 The GET_PARAMETER request retrieves the value of a parameter or 2350 parameters for a presentation or stream specified in the URI. If the 2351 Session header is present in a request, the value of a parameter MUST 2352 be retrieved in the specified session context. The content of the 2353 reply and response is left to the implementation. 2355 The method MAY also be used without a body (entity). If the this 2356 request is successful, i.e. a 200 OK response is received, then the 2357 keep-alive timer has been updated. Any non-required header present in 2358 such a request may or may not been processed. To allow a client to 2359 determine if any such header has been processed, it is necessary to 2360 use a feature tag and the Require header. Due to this reason it is 2361 RECOMMENDED that any parameters to be retrieved are sent in the body, 2362 rather than using any header. 2364 Example: 2366 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 2367 CSeq: 431 2368 Content-Type: text/parameters 2369 Session: 12345678 2370 Content-Length: 26 2372 packets_received 2373 jitter 2375 C->S: RTSP/2.0 200 OK 2376 CSeq: 431 2377 Content-Length: 38 2378 Content-Type: text/parameters 2380 packets_received: 10 2381 jitter: 0.3838 2383 The "text/parameters" section is only an example type for a 2384 body carrying parameters. 2386 11.8 SET_PARAMETER 2388 This method requests to set the value of a parameter or a set of 2389 parameters for a presentation or stream specified by the URI. The 2390 method MAY also be used without a body (entity). It is the 2391 RECOMMENDED method to use in request sent for the sole purpose of 2392 updating the keep-alive timer. If this request is successful, i.e. a 2393 200 OK response is received, then the keep-alive timer has been 2394 updated. Any non-required header present in such a request may or may 2395 not been processed. To allow a client to determine if any such header 2396 has been processed, it is necessary to use a feature tag and the 2397 Require header. Due to this reason it is RECOMMENDED that any 2398 parameters are sent in the body, rather than using any header. 2400 A request is RECOMMENDED to only contain a single parameter to allow 2401 the client to determine why a particular request failed. If the 2402 request contains several parameters, the server MUST only act on the 2403 request if all of the parameters can be set successfully. A server 2404 MUST allow a parameter to be set repeatedly to the same value, but it 2405 MAY disallow changing parameter values. If the receiver of the 2406 request does not understand or cannot locate a parameter, error 451 2407 (Parameter Not Understood) SHALL be used. In the case a parameter is 2408 not allowed to change, the error code is 458 (Parameter Is Read- 2409 Only). The response body SHOULD contain only the parameters that have 2410 errors. Otherwise no body SHALL be returned. 2412 Note: transport parameters for the media stream MUST only be set with 2413 the SETUP command. 2415 Restricting setting transport parameters to SETUP is for 2416 the benefit of firewalls. 2418 The parameters are split in a fine-grained fashion so that 2419 there can be more meaningful error indications. However, it 2420 may make sense to allow the setting of several parameters 2421 if an atomic setting is desirable. Imagine device control 2422 where the client does not want the camera to pan unless it 2423 can also tilt to the right angle at the same time. 2425 Example: 2427 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 2428 CSeq: 421 2429 Content-length: 20 2430 Content-type: text/parameters 2432 barparam: barstuff 2434 S->C: RTSP/2.0 451 Parameter Not Understood 2435 CSeq: 421 2436 Content-length: 10 2437 Content-type: text/parameters 2439 barparam 2441 The "text/parameters" section is only an example type for 2442 parameters. This method is intentionally loosely defined 2443 with the intention that the reply content and response 2444 content will be defined by the one desiring to use this 2445 mechanism. 2447 11.9 REDIRECT 2449 The REDIRECT method is issued by a server to inform a client that it 2450 required to connect to another server location to access the resource 2451 indicated by the Request-URI. The presence of the Session header in a 2452 REDIRECT request indicates the scope of the request, and determines 2453 the specific semantics of the request. 2455 A REDIRECT request with a Session header has end-to-end (i.e. server 2456 to client) scope and applies only to the given session. Any 2457 intervening proxies SHOULD NOT disconnect the control channel while 2458 there are other remaining end-to-end sessions. The OPTIONAL Location 2459 header, if included in such a request, SHALL contain a complete 2460 absolute URI pointing to the resource to which the client SHOULD 2461 reconnect. Specifically, the Location SHALL NOT contain just the 2462 host and port. A client may receive a REDIRECT request with a Session 2463 header, if and only if, an end-to-end session has been established. 2465 A client may receive a REDIRECT request without a Session header at 2466 any time when it has communication or a connection established with a 2467 server. The scope of such a request is limited to the next-hop (i.e. 2468 the RTSP agent in direct communication with the server) and applies, 2469 as well, to the control connection between the next-hop RTSP agent 2470 and the server. A REDIRECT request without a Session header 2471 indicates that all sessions and pending requests being managed via 2472 the control connection MUST be redirected. The OPTIONAL Location 2473 header, if included in such a request, SHOULD contain an absolute URI 2474 with only the host address and the OPTIONAL port number of the server 2475 to which the RTSP agent SHOULD reconnect. Any intervening proxies 2476 SHOULD do all of the following in the order listed: 2478 1. respond to the REDIRECT request 2480 2. disconnect the control channel from the requesting server 2482 3. connect to the server at the given host address 2484 4. pass the REDIRECT request to each applicable client 2485 (typically those clients with an active session or an 2486 unanswered request) 2488 Note: The proxy is responsible for accepting REDIRECT responses from 2489 its clients; these responses MUST NOT be passed on to either the 2490 original server or the redirected server. 2492 The lack of a Location header in any REDIRECT request is indicative 2493 of the server no longer being able to fulfill the current request and 2494 having no alternatives for the client to continue with its normal 2495 operation. It is akin to a server initiated TEARDOWN that applies 2496 both to sessions as well as the general connection associated with 2497 that client. 2499 When the Range header is not included in a REDIRECT request, the 2500 client SHOULD perform the redirection immediately and return a 2501 response to the server. The server can consider the session as 2502 terminated and can free any associated state after it receives the 2503 successful (2xx) response. The server MAY close the signalling 2504 connection upon receiving the response and the client SHOULD close 2505 the signalling connection after sending the 2xx response. The 2506 exception to this is when the client has several sessions on the 2507 server being managed by the given signalling connection. In this 2508 case, the client SHOULD close the connection when it has received and 2509 responded to REDIRECT requests for all the sessions managed by the 2510 signalling connection. 2512 If the OPTIONAL Range header is included in a REDIRECT request, it 2513 indicates when the redirection takes effect. The range value MUST be 2514 an open ended single value, e.g. npt=59-, indicating the play out 2515 time when redirection SHALL occur. Alternatively, a range with a 2516 time= parameter indicates the wall clock time by when the redirection 2517 MUST take place. When the time= parameter is present in the range, 2518 any range value MUST be ignored even though it MUST be syntactically 2519 correct. When the indicated redirect point is reached, a client MUST 2520 issue a TEARDOWN request and SHOULD close the signalling connection 2521 after receiving a 2xx response. The normal connection considerations 2522 apply for the server. 2524 The differentiation of REDIRECT requests with and without 2525 range headers is to allow for clear and explicit state 2526 handling. As the state in the server needs to be kept until 2527 the point of redirection, the handling becomes more clear 2528 if the client is required to TEARDOWN the session at the 2529 redirect point. 2531 After a REDIRECT request has been processed, a client that wants to 2532 continue to send or receive media for the resource identified by the 2533 Request-URI will have to establish a new session with the designated 2534 host. If the URI given in the Location header is a valid resource 2535 URI, a client SHOULD issue a DESCRIBE request for the URI. 2537 Note: The media resource indicated by the Location header 2538 can be identical, slightly different or totally different. 2539 This is the reason why a new DESCRIBE request SHOULD be 2540 issued. 2542 If the Location header contains only a host address, the client MAY 2543 assume that the media on the new server is identical to the media on 2544 the old server, i.e. all media configuration information from the old 2545 session is still valid except for the host address. 2547 This example request redirects traffic for this session to the new 2548 server at the given absolute time: 2550 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 2551 CSeq: 732 2552 Location: rtsp://s2.example.com:8001 2553 Range: npt=0- ;time=19960213T143205Z 2554 Session: uZ3ci0K+Ld-M 2556 12 Embedded (Interleaved) Binary Data 2558 In order to fulfill certain requirements on the network side, e.g. 2559 in conjunction with network address translators that block RTP 2560 traffic over UDP, it may be necessary to interleave RTSP messages and 2561 media stream data. This interleaving should generally be avoided 2562 unless necessary since it complicates client and server operation and 2563 imposes additional overhead. Also head of line blocking may cause 2564 problems. Interleaved binary data SHOULD only be used if RTSP is 2565 carried over TCP. 2567 Stream data such as RTP packets is encapsulated by an ASCII dollar 2568 sign (24 decimal), followed by a one-byte channel identifier, 2569 followed by the length of the encapsulated binary data as a binary, 2570 two-byte integer in network byte order. The stream data follows 2571 immediately afterwards, without a CRLF, but including the upper-layer 2572 protocol headers. Each $ block SHALL contain exactly one upper-layer 2573 protocol data unit, e.g., one RTP packet. 2575 0 1 2 3 2576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | "$" = 24 | Channel ID | Length in bytes | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 : Length number of bytes of binary data : 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 The channel identifier is defined in the Transport header with the 2584 interleaved parameter(Section 14.45). 2586 When the transport choice is RTP, RTCP messages are also interleaved 2587 by the server over the TCP connection. The usage of RTCP messages is 2588 indicated by including a range containing a second channel in the 2589 interleaved parameter of the Transport header, see section 14.45. If 2590 RTCP is used, packets SHALL be sent on the first available channel 2591 higher than the RTP channel. The channels are bi-directional and 2592 therefore RTCP traffic are sent on the second channel in both 2593 directions. 2595 RTCP is needed for synchronization when two or more streams 2596 are interleaved in such a fashion. Also, this provides a 2597 convenient way to tunnel RTP/RTCP packets through the TCP 2598 control connection when required by the network 2599 configuration and transfer them onto UDP when possible. 2601 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 2602 CSeq: 2 2603 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 2605 S->C: RTSP/2.0 200 OK 2606 CSeq: 2 2607 Date: 05 Jun 1997 18:57:18 GMT 2608 Transport: RTP/AVP/TCP;unicast;interleaved=5-6 2609 Session: 12345678 2611 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 2612 CSeq: 3 2613 Session: 12345678 2615 S->C: RTSP/2.0 200 OK 2616 CSeq: 3 2617 Session: 12345678 2618 Date: 05 Jun 1997 18:59:15 GMT 2619 RTP-Info: url="rtsp://example.com/bar.file" 2620 ssrc=0D12F123:seq=232433;rtptime=972948234 2622 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2623 S->C: $005{2 byte length}{"length" bytes data, w/RTP header} 2624 S->C: $006{2 byte length}{"length" bytes RTCP packet} 2626 13 Status Code Definitions 2628 Where applicable, HTTP status [H10] codes are reused. Status codes 2629 that have the same meaning are not repeated here. See Table 4 for a 2630 listing of which status codes may be returned by which requests. All 2631 error messages, 4xx and 5xx MAY return a body containing further 2632 information about the error. 2634 13.1 Success 1xx 2636 13.1.1 100 Continue 2638 See, [H10.1.1]. 2640 13.2 Success 2xx 2642 13.3 Redirection 3xx 2644 The notation "3rr" indicates response codes from 300 to 399 inclusive 2645 which are meant for redirection. The response code 304 is excluded 2646 from this set, as it is not used for redirection. 2648 See [H10.3] for definition of status code 300 to 305. However 2649 comments are given for some to how they apply to RTSP. 2651 Within RTSP, redirection may be used for load balancing or 2652 redirecting stream requests to a server topologically closer to the 2653 client. Mechanisms to determine topological proximity are beyond the 2654 scope of this specification. 2656 A 3rr code MAY be used to respond to any request. It is RECOMMENDED 2657 that they are used if necessary before a session is established, i.e. 2658 in response to DESCRIBE or SETUP. However in cases where a server is 2659 not able to send a REDIRECT request to the client, the server MAY 2660 need to resort to using 3rr responses to inform a client with a 2661 established session about the need for redirecting the session. If an 2662 3rr response is received for an request in relation to a established 2663 session, the client SHOULD send a TEARDOWN request for the session, 2664 and MAY reestablish the session using the resource indicated by the 2665 Location. 2667 If the the Location header is used in a response it SHALL contain an 2668 absolute URI pointing out the media resource the client is redirected 2669 to, the URI SHALL NOT only contain the host name. 2671 13.3.1 300 Multiple Choices 2673 See [H10.3.1] [TBW] 2675 13.3.2 301 Moved Permanently 2677 The request resource are moved permanently and resides now at the URI 2678 given by the location header. The user client SHOULD redirect 2679 automatically to the given URI. This response MUST NOT contain a 2680 message-body. The Location header MUST be included in the response. 2682 13.3.3 302 Found 2684 The requested resource reside temporarily at the URI given by the 2685 Location header. The Location header MUST be included in the 2686 response. Is intended to be used for many types of temporary 2687 redirects, e.g. load balancing. It is RECOMMENDED that one set the 2688 reason phrase to something more meaningful than "Found" in these 2689 cases. The user client SHOULD redirect automatically to the given 2690 URI. This response MUST NOT contain a message-body. 2692 13.3.4 303 See Other 2694 This status code SHALL NOT be used in RTSP. However as it was allowed 2695 to use in RTSP 1.0 (RFC 2326). 2697 13.3.5 304 Not Modified 2699 If the client has performed a conditional DESCRIBE or SETUP (see 2700 14.26) and the requested resource has not been modified, the server 2701 SHOULD send a 304 response. This response MUST NOT contain a 2702 message-body. 2704 The response MUST include the following header fields: 2706 o Date 2708 o ETag and/or Content-Location, if the header would have been 2709 sent in a 200 response to the same request. 2711 o Expires, Cache-Control, and/or Vary, if the field-value might 2712 differ from that sent in any previous response for the same 2713 variant. 2715 This response is independent for the DESCRIBE and SETUP requests. 2716 That is, a 304 response to DESCRIBE does NOT imply that the resource 2717 content is unchanged (only the session description) and a 304 2718 response to SETUP does NOT imply that the resource description is 2719 unchanged. The ETag and If-Match headers may be used to link the 2720 DESCRIBE and SETUP in this manner. 2722 13.3.6 305 Use Proxy 2724 See [H10.3.6]. 2726 13.4 Client Error 4xx 2728 13.4.1 400 Bad Request 2730 The request could not be understood by the server due to malformed 2731 syntax. The client SHOULD NOT repeat the request without 2732 modifications [H10.4.1]. If the request does not have a CSeq header, 2733 the server MUST NOT include a CSeq in the response. 2735 13.4.2 405 Method Not Allowed 2737 The method specified in the request is not allowed for the resource 2738 identified by the Request-URI. The response MUST include an Allow 2739 header containing a list of valid methods for the requested resource. 2740 This status code is also to be used if a request attempts to use a 2741 method not indicated during SETUP, e.g., if a RECORD request is 2742 issued even though the mode parameter in the Transport header only 2743 specified PLAY. 2745 13.4.3 451 Parameter Not Understood 2747 The recipient of the request does not support one or more parameters 2748 contained in the request. When returning this error message the 2749 sender SHOULD return a entity body containing the offending 2750 parameter(s). 2752 13.4.4 452 reserved 2754 This error code was removed from RFC 2326 [24] and is obsolete. 2756 13.4.5 453 Not Enough Bandwidth 2758 The request was refused because there was insufficient bandwidth. 2759 This may, for example, be the result of a resource reservation 2760 failure. 2762 13.4.6 454 Session Not Found 2764 The RTSP session identifier in the Session header is missing, 2765 invalid, or has timed out. 2767 13.4.7 455 Method Not Valid in This State 2769 The client or server cannot process this request in its current 2770 state. The response SHOULD contain an Allow header to make error 2771 recovery easier. 2773 13.4.8 456 Header Field Not Valid for Resource 2775 The server could not act on a required request header. For example, 2776 if PLAY contains the Range header field but the stream does not allow 2777 seeking. This error message may also be used for specifying when the 2778 time format in Range is impossible for the resource. In that case the 2779 Accept-Ranges header SHOULD be returned to inform the client of which 2780 format(s) that are allowed. 2782 13.4.9 457 Invalid Range 2784 The Range value given is out of bounds, e.g., beyond the end of the 2785 presentation. 2787 13.4.10 458 Parameter Is Read-Only 2789 The parameter to be set by SET_PARAMETER can be read but not 2790 modified. When returning this error message the sender SHOULD return 2791 a entity body containing the offending parameter(s). 2793 13.4.11 459 Aggregate Operation Not Allowed 2795 The requested method may not be applied on the URI in question since 2796 it is an aggregate (presentation) URI. The method may be applied on a 2797 media URI. 2799 13.4.12 460 Only Aggregate Operation Allowed 2801 The requested method may not be applied on the URI in question since 2802 it is not an aggregate control (presentation) URI. The method may be 2803 applied on the aggregate control URI. 2805 13.4.13 461 Unsupported Transport 2807 The Transport field did not contain a supported transport 2808 specification. 2810 13.4.14 462 Destination Unreachable 2812 The data transmission channel could not be established because the 2813 client address could not be reached. This error will most likely be 2814 the result of a client attempt to place an invalid dest_addr 2815 parameter in the Transport field. 2817 13.4.15 463 Destination Prohibited 2819 The data transmission channel was not established because the server 2820 prohibited access to the client address. This error is most likely 2821 the result of a client attempt to redirect media traffic to another 2822 destination with a dest_addr parameter in the Transport header. 2824 13.4.16 470 Connection Authorization Required 2826 The secured connection attempt need user or client authorization 2827 before proceeding. The next hops certificate is included in this 2828 response in the Accept-Credentials header. 2830 13.4.17 471 Connection Credentials not accepted 2832 When performing a secure connection over multiple connections, a 2833 intermediary has refused to connect to the next hop and carry out the 2834 request due to unacceptable credentials for the used policy. 2836 13.5 Server Error 5xx 2838 13.5.1 551 Option not supported 2840 A feature-tag given in the Require or the Proxy-Require fields was 2841 not supported. The Unsupported header SHOULD be returned stating the 2842 feature for which there is no support. 2844 14 Header Field Definitions 2846 method direction object acronym Body 2847 _________________________________________________ 2848 DESCRIBE C -> S P,S DES r 2849 GET_PARAMETER C -> S, S -> C P,S GPR R,r 2850 OPTIONS C -> S P,S OPT 2851 S -> C 2852 PAUSE C -> S P,S PSE 2853 PLAY C -> S P,S PLY 2854 REDIRECT S -> C P,S RDR 2855 SETUP C -> S S STP 2856 SET_PARAMETER C -> S, S -> C P,S SPR R,r 2857 TEARDOWN C -> S P,S TRD 2859 Table 8: Overview of RTSP methods, their direction, and what objects 2860 (P: presentation, S: stream) they operate on. Body notes if a method 2861 is allowed to carry body and in which direction, R = Request, 2862 r=response. Note: It is allowed for all error messages 4xx and 5xx to 2863 have a body 2865 The general syntax for header fields is covered in Section 4.2 This 2866 section lists the full set of header fields along with notes on 2867 meaning, and usage. The syntax definition for header fields are 2868 present in section 19.2.3. Throughout this section, we use [HX.Y] to 2869 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 2870 [3]. Examples of each header field are given. 2872 Information about header fields in relation to methods and proxy 2873 processing is summarized in Tables 9, 10, 11, and 12. 2875 The "where" column describes the request and response types in which 2876 the header field can be used. Values in this column are: 2878 R: header field may only appear in requests; 2880 r: header field may only appear in responses; 2882 2xx, 4xx, etc.: A numerical value or range indicates response 2883 codes with which the header field can be used; 2885 c: header field is copied from the request to the response. 2887 An empty entry in the "where" column indicates that the header field 2888 may be present in all requests and responses. 2890 The "proxy" column describes the operations a proxy may perform on a 2891 header field. An empty proxy column indicates that the proxy SHALL 2892 NOT do any changes to that header, all allowed operations are 2893 explicitly stated: 2895 a: A proxy can add or concatenate the header field if not 2896 present. 2898 m: A proxy can modify an existing header field value. 2900 d: A proxy can delete a header field value. 2902 r: A proxy needs to be able to read the header field, and thus 2903 this header field cannot be encrypted. 2905 The rest of the columns relate to the presence of a header field in a 2906 method. The method names when abbreviated, are according to table 8: 2908 c: Conditional; requirements on the header field depend on the 2909 context of the message. 2911 m: The header field is mandatory. 2913 m*: The header field SHOULD be sent, but clients/servers need to 2914 be prepared to receive messages without that header field. 2916 o: The header field is optional. 2918 *: The header field is SHALL be present if the message body is 2919 not empty. See sections 14.16, 14.18 and 4.3 for details. 2921 -: The header field is not applicable. 2923 "Optional" means that a Client/Server MAY include the header field in 2924 a request or response. The Client/Server behavior when receiving such 2925 headers varies, for some it may ignore the header field, in other 2926 case it is request to process the header. This is regulated by the 2927 method and header descriptions. Example of such headers that require 2928 processing are the Require and Proxy-Require header fields discussed 2929 in 14.37 and 14.31. A "mandatory" header field MUST be present in a 2930 request, and MUST be understood by the Client/Server receiving the 2931 request. A mandatory response header field MUST be present in the 2932 response, and the header field MUST be understood by the 2933 Client/Server processing the response. "Not applicable" means that 2934 the header field MUST NOT be present in a request. If one is placed 2935 in a request by mistake, it MUST be ignored by the Client/Server 2936 receiving the request. Similarly, a header field labeled "not 2937 applicable" for a response means that the Client/Server MUST NOT 2938 place the header field in the response, and the Client/Server MUST 2939 ignore the header field in the response. 2941 A Client/Server SHOULD ignore extension header parameters that are 2942 not understood. 2944 The From and Location header fields contain an URI. If the URI 2945 contains a comma, or semicolon, the URI MUST be enclosed in double 2946 quotas ("). Any URI parameters are contained within these quotas. If 2947 the URI is not enclosed in double quotas, any semicolon- delimited 2948 parameters are header-parameters, not URI parameters. 2950 14.1 Accept 2952 The Accept request-header field can be used to specify certain 2953 presentation description content types which are acceptable for the 2954 response. 2956 The "level" parameter for presentation descriptions is 2957 properly defined as part of the MIME type registration, not 2958 here. 2960 See [H14.1] for syntax. 2962 Example of use: 2964 Accept: application/rtsl q=1.0, application/sdp 2966 14.2 Accept-Credentials 2968 The Accept-Credentials header is a request header used to indicate to 2969 any trusted intermediary how to handle further secured connections to 2970 proxies or servers. See section 18 for the usage of this header. It 2971 SHALL only be included in client to server requests. 2973 In a request the header SHALL contain the method (User, Proxy, or 2974 Any) for approving credentials selected by the requestor. The method 2975 SHALL NOT be changed by any proxy. If the method is "User" the header 2976 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 2977 _________________________________________________________________ 2978 Accept R o - - - - - 2979 Accept-Credentials R r o o o o o o 2980 Accept-Encoding R r o - - - - - 2981 Accept-Language R r o - - - - - 2982 Accept-Ranges r r - - o - - - 2983 Accept-Ranges 456 r - - - o o - 2984 Allow r am c c c - - - 2985 Allow 405 am m m m m m m 2986 Authorization R o o o o o o 2987 Bandwidth R o o o o - - 2988 Blocksize R o - o o - - 2989 Cache-Control r - - o - - - 2990 Connection o o o o o o 2991 Connection-Credentials 470,407 ar o o o o o o 2992 Content-Base r o - - - - - 2993 Content-Base 4xx o o o o o o 2994 Content-Encoding R r - - - - - - 2995 Content-Encoding r r o - - - - - 2996 Content-Encoding 4xx r o o o o o o 2997 Content-Language R r - - - - - - 2998 Content-Language r r o - - - - - 2999 Content-Language 4xx r o o o o o o 3000 Content-Length r r * - - - - - 3001 Content-Length 4xx r * * * * * * 3002 Content-Location r o - - - - - 3003 Content-Location 4xx o o o o o o 3004 Content-Type r * - - - - - 3005 Content-Type 4xx * * * * * * 3006 CSeq Rc rm m m m m m m 3007 Date am o o o o o o 3008 ETag r r o - o - - - 3009 Expires r r o - - - - - 3010 From R r o o o o o o 3011 Host - - - - - - 3012 If-Match R r - - o - - - 3013 If-Modified-Since R r o - o - - - 3014 If-None-Match R r o - - - - - 3015 Last-Modified r r o - - - - - 3016 Location 3rr o o o o o o 3018 Table 9: Overview of RTSP header fields (A-L) related to methods 3019 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3021 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3022 _____________________________________________________________ 3023 Proxy-Authenticate 407 amr m m m m m m 3024 Proxy-Require R ar o o o o o o 3025 Proxy-Require r r c c c c c c 3026 Proxy-Supported R amr oc oc oc oc oc oc 3027 Proxy-Supported r c c c c c c 3028 Public r admr - m* - - - - 3029 Public 501 admr m* m* m* m* m* m* 3030 Range R - - - o o - 3031 Range r - - c m* m* - 3032 Referer R o o o o o o 3033 Require R o o o o o o 3034 Retry-After 3rr,503 o o o - - - 3035 RTP-Info r - - o c - - 3036 Scale - - - o - - 3037 Session R r - o o m m m 3038 Session r r - c m m m o 3039 Server R r - o - - - - 3040 Server r r o o o o o o 3041 Speed - - - o - - 3042 Supported R amr o o o o o o 3043 Supported r amr c c c c c c 3044 Timestamp R admr o o o o o o 3045 Timestamp c admr m m m m m m 3046 Transport amr - - m - - - 3047 Unsupported r c c c c c c 3048 User-Agent R m* m* m* m* m* m* 3049 Vary r c c c c c c 3050 Via R amr o o o o o o 3051 Via c dr m m m m m m 3052 WWW-Authenticate 401 m m m m m m 3054 _____________________________________________________________ 3055 Header Where Proxy DES OPT SETUP PLAY PAUSE TRD 3057 Table 10: Overview of RTSP header fields (P-W) related to methods 3058 DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. 3060 contains zero or more of credentials that the client accept. Each 3061 credential SHALL consist of one URI identifying the proxy or server, 3062 and the SHA-1 [14] hash computed over that entity's DER encoded 3063 certificate [15] in Base64 [35]. 3065 Header Where Proxy GPR SPR RDR 3066 __________________________________________________ 3067 Accept-Credentials R r o o o 3068 Allow 405 amr m m m 3069 Authorization R o o o 3070 Bandwidth R - o - 3071 Blocksize R - o - 3072 Connection o o o 3073 Connection-Credentials 470,407 ar o o o 3074 Content-Base R o o - 3075 Content-Base r o o - 3076 Content-Base 4xx o o o 3077 Content-Encoding R r o o - 3078 Content-Encoding r r o o - 3079 Content-Encoding 4xx r o o o 3080 Content-Language R r o o - 3081 Content-Language r r o o - 3082 Content-Language 4xx r o o o 3083 Content-Length R r * * - 3084 Content-Length r r * * - 3085 Content-Length 4xx r * * * 3086 Content-Location R o o - 3087 Content-Location r o o - 3088 Content-Location 4xx o o o 3089 Content-Type R * * - 3090 Content-Type r * * - 3091 Content-Type 4xx * * * 3092 CSeq Rc mr m m m 3093 Date am o o o 3094 From R r o o o 3095 Host - - - 3096 Last-Modified R r - - - 3097 Last-Modified r r o - - 3098 Location 3rr o o o 3099 Location R - - m 3100 Proxy-Authenticate 407 amr m m m 3101 Proxy-Require R ar o o o 3102 Proxy-Require r r c c c 3103 Proxy-Supported R amr oc oc oc 3104 Proxy-Supported r c c c 3105 Public 501 admr m* m* m* 3107 __________________________________________________ 3108 Header Where Proxy GPR SPR RDR 3110 Table 11: Overview of RTSP header fields (A-P) related to methods 3111 GET_PARAMETER, SET_PARAMETER, and REDIRECT. 3113 Header Where Proxy GPR SPR RDR 3114 ____________________________________________ 3115 Range R - - o 3116 Referer R o o o 3117 Require R r o o o 3118 Retry-After 3rr,503 o o - 3119 Scale - - - 3120 Session R r o o o 3121 Session r r c c o 3122 Server R r o o o 3123 Server r r o o - 3124 Supported R adrm o o o 3125 Supported r adrm c c c 3126 Timestamp R adrm o o o 3127 Timestamp c adrm m m m 3128 Unsupported r arm c c c 3129 User-Agent R r m* m* - 3130 User-Agent r r - - m* 3131 Vary r c c - 3132 Via R amr o o o 3133 Via c dr m m m 3134 WWW-Authenticate 401 m m m 3136 ____________________________________________ 3137 Header Where Proxy GPR SPR RDR 3139 Table 12: Overview of RTSP header fields (R-W) related to methods 3140 GET_PARAMETER, SET_PARAMETER, and REDIRECT. 3142 "rtsps://proxy2.example.com/";exaIl9VMbQMOFGClx5rXnPJKVNI=, 3143 "rtsps://server.example.com/";lurbjj5khhB0NhIuOXtt4bBRH1M= 3145 14.3 Accept-Encoding 3147 See [H14.3] 3149 14.4 Accept-Language 3151 See [H14.4]. Note that the language specified applies to the 3152 presentation description and any reason phrases, not the media 3153 content. 3155 14.5 Accept-Ranges 3157 The Accept-Ranges response-header field allows the server to indicate 3158 its acceptance of range requests and possible formats for a resource: 3160 Accept-Ranges: NPT, SMPTE 3162 This header has the same syntax as [H14.5] and the syntax is defined 3163 in 19.2.3. However, new range-units are defined. Inclusion of any of 3164 the time formats indicates acceptance by the server for PLAY and 3165 PAUSE requests with this format. The headers value is valid for the 3166 resource specified by the URI in the request, this response 3167 corresponds to. A server SHOULD use this header in SETUP responses to 3168 indicate to the client which range time formats the media supports. 3169 The header SHOULD also be included in "456" responses which is a 3170 result of use of unsupported range formats. 3172 14.6 Allow 3174 The Allow entity-header field lists the methods supported by the 3175 resource identified by the Request-URI. The purpose of this field is 3176 to strictly inform the recipient of valid methods associated with the 3177 resource. An Allow header field MUST be present in a 405 (Method Not 3178 Allowed) response. See [H14.7] for syntax definition. The Allow 3179 header MUST also be present in all OPTIONS responses where the 3180 content of the header will not include exactly the same methods as 3181 listed in the Public header. 3183 The Allow SHALL also be included in SETUP and DESCRIBE responses, if 3184 the methods allowed for the resource is different than the minimal 3185 implementation set. 3187 Example of use: 3189 Allow: SETUP, PLAY, SET_PARAMETER 3191 14.7 Authorization 3193 See [H14.8] 3195 14.8 Bandwidth 3197 The Bandwidth request-header field describes the estimated bandwidth 3198 available to the client, expressed as a positive integer and measured 3199 in bits per second. The bandwidth available to the client may change 3200 during an RTSP session, e.g., due to mobility. 3202 Example: 3204 Bandwidth: 4000 3206 14.9 Blocksize 3208 The Blocksize request-header field is sent from the client to the 3209 media server asking the server for a particular media packet size. 3210 This packet size does not include lower-layer headers such as IP, 3211 UDP, or RTP. The server is free to use a blocksize which is lower 3212 than the one requested. The server MAY truncate this packet size to 3213 the closest multiple of the minimum, media-specific block size, or 3214 override it with the media-specific size if necessary. The block size 3215 MUST be a positive decimal number, measured in octets. The server 3216 only returns an error (4xx) if the value is syntactically invalid. 3218 14.10 Cache-Control 3220 The Cache-Control general-header field is used to specify directives 3221 that MUST be obeyed by all caching mechanisms along the 3222 request/response chain. 3224 Cache directives MUST be passed through by a proxy or gateway 3225 application, regardless of their significance to that application, 3226 since the directives may be applicable to all recipients along the 3227 request/response chain. It is not possible to specify a cache- 3228 directive for a specific cache. 3230 Cache-Control should only be specified in a SETUP request and its 3231 response. Note: Cache-Control does not govern the caching of 3232 responses as for HTTP, instead it applies to the media stream 3233 identified by the SETUP request. The caching of RTSP requests are 3234 generally not cacheable, for further information see section 16. 3235 Below is the description of the cache directives that can be included 3236 in the Cache-Control header. 3238 no-cache: Indicates that the media stream MUST NOT be cached 3239 anywhere. This allows an origin server to prevent caching 3240 even by caches that have been configured to return stale 3241 responses to client requests. 3243 public: Indicates that the media stream is cacheable by any 3244 cache. 3246 private: Indicates that the media stream is intended for a 3247 single user and MUST NOT be cached by a shared cache. A 3248 private (non-shared) cache may cache the media stream. 3250 no-transform: An intermediate cache (proxy) may find it useful 3251 to convert the media type of a certain stream. A proxy 3252 might, for example, convert between video formats to save 3253 cache space or to reduce the amount of traffic on a slow 3254 link. Serious operational problems may occur, however, 3255 when these transformations have been applied to streams 3256 intended for certain kinds of applications. For example, 3257 applications for medical imaging, scientific data analysis 3258 and those using end-to-end authentication all depend on 3259 receiving a stream that is bit-for-bit identical to the 3260 original media stream. Therefore, if a response includes 3261 the no-transform directive, an intermediate cache or proxy 3262 MUST NOT change the encoding of the stream. Unlike HTTP, 3263 RTSP does not provide for partial transformation at this 3264 point, e.g., allowing translation into a different 3265 language. 3267 only-if-cached: In some cases, such as times of extremely poor 3268 network connectivity, a client may want a cache to return 3269 only those media streams that it currently has stored, and 3270 not to receive these from the origin server. To do this, 3271 the client may include the only-if-cached directive in a 3272 request. If it receives this directive, a cache SHOULD 3273 either respond using a cached media stream that is 3274 consistent with the other constraints of the request, or 3275 respond with a 504 (Gateway Timeout) status. However, if a 3276 group of caches is being operated as a unified system with 3277 good internal connectivity, such a request MAY be forwarded 3278 within that group of caches. 3280 max-stale: Indicates that the client is willing to accept a 3281 media stream that has exceeded its expiration time. If 3282 max-stale is assigned a value, then the client is willing 3283 to accept a response that has exceeded its expiration time 3284 by no more than the specified number of seconds. If no 3285 value is assigned to max-stale, then the client is willing 3286 to accept a stale response of any age. 3288 min-fresh: Indicates that the client is willing to accept a 3289 media stream whose freshness lifetime is no less than its 3290 current age plus the specified time in seconds. That is, 3291 the client wants a response that will still be fresh for at 3292 least the specified number of seconds. 3294 must-revalidate: When the must-revalidate directive is present 3295 in a SETUP response received by a cache, that cache MUST 3296 NOT use the entry after it becomes stale to respond to a 3297 subsequent request without first revalidating it with the 3298 origin server. That is, the cache is required to do an 3299 end-to-end revalidation every time, if, based solely on the 3300 origin server's Expires, the cached response is stale.) 3302 proxy-revalidate: The proxy-revalidate directive has the same 3303 meaning as the must-revalidate directive, except that it 3304 does not apply to non-shared user agent caches. It can be 3305 used on a response to an authenticated request to permit 3306 the user's cache to store and later return the response 3307 without needing to revalidate it (since it has already been 3308 authenticated once by that user), while still requiring 3309 proxies that service many users to revalidate each time (in 3310 order to make sure that each user has been authenticated). 3311 Note that such authenticated responses also need the public 3312 cache control directive in order to allow them to be cached 3313 at all. 3315 max-age: When an intermediate cache is forced, by means of a 3316 max-age=0 directive, to revalidate its own cache entry, and 3317 the client has supplied its own validator in the request, 3318 the supplied validator might differ from the validator 3319 currently stored with the cache entry. In this case, the 3320 cache MAY use either validator in making its own request 3321 without affecting semantic transparency. 3323 However, the choice of validator might affect performance. 3324 The best approach is for the intermediate cache to use its 3325 own validator when making its request. If the server 3326 replies with 304 (Not Modified), then the cache can return 3327 its now validated copy to the client with a 200 (OK) 3328 response. If the server replies with a new entity and cache 3329 validator, however, the intermediate cache can compare the 3330 returned validator with the one provided in the client's 3331 request, using the strong comparison function. If the 3332 client's validator is equal to the origin server's, then 3333 the intermediate cache simply returns 304 (Not Modified). 3334 Otherwise, it returns the new entity with a 200 (OK) 3335 response. 3337 14.11 Connection 3339 See [H14.10]. The use of the connection option "close" in RTSP 3340 messages SHOULD be limited to error messages when the server is 3341 unable to recover and therefore see it necessary to close the 3342 connection. The reason is that the client has the choice of 3343 continuing using a connection indefinitely, as long as it sends valid 3344 messages. 3346 14.12 Connection-Credentials 3348 The Connection-Credentials response header is used to carry the 3349 credentials of any next hop that need to be approved by the 3350 requestor. It SHALL only be used in server to client responses. 3352 The Connection-Credentials header in an RTSP response SHALL, if 3353 included, contain the credentials information of the next hop that an 3354 intermediary needs to securely connect to. The credential MUST 3355 include the URI of the next proxy or server and the DER encoded 3356 X.509v3 [15] certificate in base64 [35]. 3358 Example: 3360 Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC... 3362 14.13 Content-Base 3364 The Content-Base entity-header field may be used to specify the base 3365 URI for resolving relative URIs within the entity. 3367 Content-Base: rtsp://media.example.com/movie/twister 3369 If no Content-Base field is present, the base URI of an entity is 3370 defined either by its Content-Location (if that Content-Location URI 3371 is an absolute URI) or the URI used to initiate the request, in that 3372 order of precedence. Note, however, that the base URI of the contents 3373 within the entity-body may be redefined within that entity-body. 3375 14.14 Content-Encoding 3377 See [H14.11] 3379 14.15 Content-Language 3381 See [H14.12] 3383 14.16 Content-Length 3385 The Content-Length general-header field contains the length of the 3386 body (entity) of the message (i.e. after the double CRLF following 3387 the last header). Unlike HTTP, it MUST be included in all messages 3388 that carry body beyond the header portion of the message. If it is 3389 missing, a default value of zero is assumed. It is interpreted 3390 according to [H14.13]. 3392 14.17 Content-Location 3394 See [H14.14] 3396 14.18 Content-Type 3398 See [H14.17]. Note that the content types suitable for RTSP are 3399 likely to be restricted in practice to presentation descriptions and 3400 parameter-value types. 3402 14.19 CSeq 3404 The CSeq general-header field specifies the sequence number for an 3405 RTSP request-response pair. This field MUST be present in all 3406 requests and responses. For every RTSP request containing the given 3407 sequence number, the corresponding response will have the same 3408 number. Any retransmitted request MUST contain the same sequence 3409 number as the original (i.e. the sequence number is not incremented 3410 for retransmissions of the same request). For each new RTSP request 3411 the CSeq value SHALL be incremented by one. The initial sequence 3412 number MAY be any number, however it is RECOMMENDED to start at 0. 3413 Each sequence number series is unique between each requester and 3414 responder, i.e. the client has one series for its request to a 3415 server and the server has another when sending request to the client. 3416 Each requester and responder is identified with its network address. 3418 Example: 3420 CSeq: 239 3422 14.20 Date 3424 See [H14.18]. An RTSP message containing a body MUST include a Date 3425 header if the sending host has a clock. Servers SHOULD include a Date 3426 header in all other RTSP messages. 3428 14.21 ETag 3430 The ETag response header MAY be included in DESCRIBE or SETUP 3431 responses. The entity tag returned in a DESCRIBE response is for the 3432 included entity, while for SETUP it refers to the media resource just 3433 set up. This differentiation allows for cache validation of both 3434 session description and the media resource associated with the 3435 description. If the ETag is provided both inside the entity, e.g. 3436 within the "a=etag" attribute in SDP, and in the response message, 3437 then both tags SHALL be identical. It is RECOMMENDED that the ETag is 3438 primarily given in the RTSP response message, to ensure that caches 3439 can use the ETag without requiring content inspection. 3441 SETUP and DESCRIBE requests can be made conditional upon the ETag 3442 using the headers If-Match (Section 14.25) and If-None-Match (Section 3443 14.27). 3445 14.22 Expires 3447 The Expires entity-header field gives a date and time after which the 3448 description or media-stream should be considered stale. The 3449 interpretation depends on the method: 3451 DESCRIBE response: The Expires header indicates a date and time 3452 after which the presentation description (body) SHOULD be 3453 considered stale. 3455 SETUP response: The Expires header indicate a date and time 3456 after which the media stream SHOULD be considered stale. 3458 A stale cache entry may not normally be returned by a cache (either a 3459 proxy cache or an user agent cache) unless it is first validated with 3460 the origin server (or with an intermediate cache that has a fresh 3461 copy of the entity). See section 16 for further discussion of the 3462 expiration model. 3464 The presence of an Expires field does not imply that the original 3465 resource will change or cease to exist at, before, or after that 3466 time. 3468 The format is an absolute date and time as defined by HTTP-date in 3469 [H3.3]; it MUST be in RFC1123-date format: 3471 An example of its use is 3473 Expires: Thu, 01 Dec 1994 16:00:00 GMT 3475 RTSP/2.0 clients and caches MUST treat other invalid date formats, 3476 especially including the value "0", as having occurred in the past 3477 (i.e., already expired). 3479 To mark a response as "already expired," an origin server should use 3480 an Expires date that is equal to the Date header value. To mark a 3481 response as "never expires," an origin server SHOULD use an Expires 3482 date approximately one year from the time the response is sent. 3483 RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in 3484 the future. 3486 The presence of an Expires header field with a date value of some 3487 time in the future on a media stream that otherwise would by default 3488 be non-cacheable indicates that the media stream is cacheable, unless 3489 indicated otherwise by a Cache-Control header field (Section 14.10). 3491 14.23 From 3493 See [H14.22]. 3495 14.24 Host 3497 The Host HTTP request header field [H14.23] is not needed for RTSP, 3498 and SHALL NOT be sent. It SHALL be silently ignored if received. 3500 14.25 If-Match 3502 See [H14.24]. 3504 The If-Match request-header field is especially useful for ensuring 3505 the integrity of the presentation description, in both the case where 3506 it is fetched via means external to RTSP (such as HTTP), or in the 3507 case where the server implementation is guaranteeing the integrity of 3508 the description between the time of the DESCRIBE message and the 3509 SETUP message. By including the ETag given in or with the session 3510 description in a SETUP request, the client ensures that resources set 3511 up are matching the description. A SETUP request for which the ETag 3512 validation check fails, SHALL responde using 412 (Precondition 3513 Failed). 3515 This validation check is also very useful if a session has been 3516 redirected from one server to another. 3518 14.26 If-Modified-Since 3520 The If-Modified-Since request-header field is used with the DESCRIBE 3521 and SETUP methods to make them conditional. If the requested variant 3522 has not been modified since the time specified in this field, a 3523 description will not be returned from the server (DESCRIBE) or a 3524 stream will not be set up (SETUP). Instead, a 304 (Not Modified) 3525 response SHALL be returned without any message-body. 3527 An example of the field is: 3529 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 3531 14.27 If-None-Match 3533 See [H14.26]. 3535 This request header can be used with entity tags to make DESCRIBE 3536 requests conditional. A new session description is retrieved only if 3537 another entity than the already available would be included. If the 3538 entity available for delivery is matching the one the client already 3539 has, then a 304 (Not Modified) response is given. 3541 14.28 Last-Modified 3543 The Last-Modified entity-header field indicates the date and time at 3544 which the origin server believes the presentation description or 3545 media stream was last modified. See [H14.29]. For the methods 3546 DESCRIBE, the header field indicates the last modification date and 3547 time of the description, for SETUP that of the media stream. 3549 14.29 Location 3551 See [H14.30]. 3553 14.30 Proxy-Authenticate 3555 See [H14.33]. 3557 14.31 Proxy-Require 3559 The Proxy-Require request-header field is used to indicate proxy- 3560 sensitive features that MUST be supported by the proxy. Any Proxy- 3561 Require header features that are not supported by the proxy MUST be 3562 negatively acknowledged by the proxy to the client using the 3563 Unsupported header. The proxy SHALL use the 551 (Option Not 3564 Supported) status code in the response. Any feature tag included in 3565 the Proxy-Require does not apply to the end-point (server or client). 3566 To ensure that a feature is supported by both proxies and servers the 3567 tag needs to be included in also a Require header. 3569 See Section 14.37 for more details on the mechanics of this message 3570 and a usage example. 3572 Example of use: 3574 Proxy-Require: play.basic 3576 14.32 Proxy-Supported 3578 The Proxy-Supported header field enumerates all the extensions 3579 supported by the proxy using feature tags. The header carries the 3580 intersection of extensions supported by the forwarding proxies. The 3581 Proxy-Supported header MAY be included in any request by a proxy. It 3582 SHALL be added by any proxy if the Supported header is present in a 3583 request. When present in a request, the receiver MUST in the response 3584 copy the received Proxy-Supported header. 3586 The Proxy-Supported header field contains a list of feature-tags 3587 applicable to proxies, as described in Section 3.7. The list are the 3588 intersection of all feature-tags understood by the proxies. To 3589 achieve an intersection, the proxy adding the Proxy-Supported header 3590 includes all proxy feature-tags it understands. Any proxy receiving a 3591 request with the header, checks the list and removes any feature tag 3592 it do not support. A Proxy-Supported header present in the response 3593 SHALL NOT be touched by the proxies. 3595 Example: 3597 C->P1: OPTIONS rtsp://example.com/ RTSP/2.0 3598 Supported: foo, bar, blech 3600 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0 3601 Supported: foo, bar, blech 3602 Proxy-Supported: proxy-foo, proxy-bar, proxy-blech 3603 Via: 2.0 prox1.example.com 3605 P2->S: OPTIONS rtsp://example.com/ RTSP/2.0 3606 Supported: foo, bar, blech 3607 Proxy-Supported: proxy-foo, proxy-blech 3608 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 3610 S->C: RTSP/2.0 200 OK 3611 Supported: foo, bar, baz 3612 Proxy-Supported: proxy-foo, proxy-blech 3613 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3614 Via: 2.0 prox1.example.com, 2.0 prox2.example.com 3616 14.33 Public 3618 The Public response header field lists the set of methods supported 3619 by the response sender. This header applies to the general 3620 capabilities of the sender and its only purpose is to indicate the 3621 sender's capabilities to the recipient. The methods listed may or may 3622 not be applicable to the Request-URI; the Allow header field (section 3623 14.7) MAY be used to indicate methods allowed for a particular URI. 3625 Example of use: 3627 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 3629 In the event that there are proxies between the sender and the 3630 recipient of a response, each intervening proxy MUST modify the 3631 Public header field to remove any methods that are not supported via 3632 that proxy. The resulting Public header field will contain an 3633 intersection of the sender's methods and the methods allowed through 3634 by the intervening proxies. 3636 In general proxies should allow all methods to 3637 transparently pass through from the sending RTSP agent to 3638 the receiving RTSP agent, but there may be cases where this 3639 is not desirable for a given proxy. Modification of the 3640 Public response header field by the intervening proxies 3641 ensures that the request sender gets an accurate response 3642 indicating the methods that can be used on the target agent 3643 via the proxy chain. 3645 14.34 Range 3647 The Range header specifies a time range in PLAY (Section 11.4), PAUSE 3648 (Section 11.5), SETUP (Section 11.3), and REDIRECT (Section 11.9) 3649 requests and/or responses. 3651 The range can be specified in a number of units. This specification 3652 defines smpte (Section 3.4), npt (Section 3.5), and clock (Section 3653 3.6) range units. While byte ranges [H14.35.1] and other extended 3654 units MAY be used, their behavior is unspecified since they are not 3655 normally meaningful in RTSP. Servers supporting the Range header MUST 3656 understand the NPT range format and SHOULD understand the SMPTE range 3657 format. If the Range header is sent in a time format that is not 3658 understood, the recipient SHOULD return 456 (Header Field Not Valid 3659 for Resource) and include an Accept-Ranges header indicating the 3660 supported time formats for the given resource. 3662 The Range header MAY contain a time parameter in UTC, specifying the 3663 time at which the operation is to be made effective. This 3664 functionality SHALL be used only with the REDIRECT method. 3666 Ranges are half-open intervals, including the first point, but 3667 excluding the second point. In other words, a range of A-B starts 3668 exactly at time A, but stops just before B. Only the start time of a 3669 media unit such as a video or audio frame is relevant. For example, 3670 assume that video frames are generated every 40 ms. A range of 3671 10.0-10.1 would include a video frame starting at 10.0 or later time 3672 and would include a video frame starting at 10.08, even though it 3673 lasted beyond the interval. A range of 10.0-10.08, on the other hand, 3674 would exclude the frame at 10.08. 3676 Example: 3678 Range: clock=19960213T143205Z-;time=19970123T143720Z 3680 The notation is similar to that used for the HTTP/1.1 [3] 3681 byte-range header. It allows clients to select an excerpt 3682 from the media object, and to play from a given point to 3683 the end as well as from the current location to a given 3684 point. 3686 By default, range intervals increase, where the second point is 3687 larger than the first point. 3689 Example: 3691 Range: npt=10-15 3693 However, range intervals can also decrease if the Scale header (see 3694 section 14.39) indicates a negative scale value. For example, this 3695 would be the case when a playback in reverse is desired. 3697 Example: 3699 Scale: -1 3700 Range: npt=15-10 3702 Decreasing ranges are still half open intervals as described above. 3703 Thus, for range A-B, A is closed and B is open. In the above example, 3704 15 is closed and 10 is open. An exception to this rule is the case 3705 when B=0 in a decreasing range. In this case, the range is closed on 3706 both ends, as otherwise there would be no way to reach 0 on a reverse 3707 playback. 3709 Example: 3711 Scale: -1 3712 Range: npt=15-0 3714 In this range both 15 and 0 are closed. 3716 A decreasing range interval without a corresponding negative Scale 3717 header is not valid. 3719 14.35 Referer 3721 See [H14.36]. The URI refers to that of the presentation description, 3722 typically retrieved via HTTP. 3724 14.36 Retry-After 3726 See [H14.37]. 3728 14.37 Require 3730 The Require request-header field is used by clients or servers to 3731 ensure that the other end-point supports features that are required 3732 in respect to this request. It can also be used to query if the other 3733 end-point supports certain features, however the use of the Supported 3734 (Section 14.43) is much more effective in this purpose. The server 3735 MUST respond to this header by using the Unsupported header to 3736 negatively acknowledge those feature-tags which are NOT supported. 3737 The response SHALL use the error code 551 (Option Not Supported). 3738 This header does not apply to proxies, for the same functionality in 3739 respect to proxies see, header Proxy-Require (Section 14.31). 3741 This is to make sure that the client-server interaction 3742 will proceed without delay when all features are understood 3743 by both sides, and only slow down if features are not 3744 understood (as in the example below). For a well-matched 3745 client-server pair, the interaction proceeds quickly, 3746 saving a round-trip often required by negotiation 3747 mechanisms. In addition, it also removes state ambiguity 3748 when the client requires features that the server does not 3749 understand. 3751 Example: 3753 C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0 3754 CSeq: 302 3755 Require: funky-feature 3756 Funky-Parameter: funkystuff 3758 S->C: RTSP/2.0 551 Option not supported 3759 CSeq: 302 3760 Unsupported: funky-feature 3762 In this example, "funky-feature" is the feature-tag which indicates 3763 to the client that the fictional Funky-Parameter field is required. 3764 The relationship between "funky-feature" and Funky-Parameter is not 3765 communicated via the RTSP exchange, since that relationship is an 3766 immutable property of "funky-feature" and thus should not be 3767 transmitted with every exchange. 3769 Proxies and other intermediary devices SHALL ignore this header. If a 3770 particular extension requires that intermediate devices support it, 3771 the extension should be tagged in the Proxy-Require field instead 3772 (see Section 14.31). 3774 14.38 RTP-Info 3776 The RTP-Info response-header field is used to set RTP-specific 3777 parameters in the PLAY response. For streams using RTP as transport 3778 protocol the RTP-Info header SHOULD be part of a 200 response to 3779 PLAY. 3781 The exclusion of the RTP-Info in a PLAY response for RTP 3782 transported media will result in that a client needs to 3783 synchronize the media streams using RTCP. This may have 3784 negative impact as the RTCP can be lost, and does not need 3785 to be particulary timely in their arrival. Also 3786 functionality as informing the client from which packet a 3787 seek has occurred is affected. 3789 The RTP-Info MAY also be included in SETUP responses to provide 3790 synchronization information when changing transport parameters, see 3791 11.3. 3793 The header can carry the following parameters: 3795 url: Indicates the stream URI which for which the following RTP 3796 parameters correspond, this URI MUST be the same used in 3797 the SETUP request for this media stream. Any relative URI 3798 SHALL use the Request-URI as base URI. This parameter SHALL 3799 be present. 3801 ssrc: The Synchronization source (SSRC) that the RTP timestamp 3802 and sequence number provide applies to. This parameter 3803 SHALL be present. 3805 seq: Indicates the sequence number of the first packet of the 3806 stream that is direct result of the request. This allows 3807 clients to gracefully deal with packets when seeking. The 3808 client uses this value to differentiate packets that 3809 originated before the seek from packets that originated 3810 after the seek. Note that a client may not receive the 3811 packet with the expressed sequence number, and instead 3812 packets with a higher sequence number, due to packet loss 3813 or reordering. This parameter is RECOMMENDED to be present. 3815 rtptime: SHALL indicate the RTP timestamp value corresponding to 3816 the start time value in the Range response header, or if 3817 not explicitly given the implied start point. The client 3818 uses this value to calculate the mapping of RTP time to NPT 3819 or other media timescale. This parameter SHOULD be present 3820 to ensure inter-media synchronization is achieved. There 3821 exist no requirement that any received RTP packet will have 3822 the same RTP timestamp value as the one in the parameter 3823 used to establish synchronization. 3825 A mapping from RTP timestamps to NTP timestamps (wall 3826 clock) is available via RTCP. However, this information is 3827 not sufficient to generate a mapping from RTP timestamps to 3828 media clock time (NPT, etc.). Furthermore, in order to 3829 ensure that this information is available at the necessary 3830 time (immediately at startup or after a seek), and that it 3831 is delivered reliably, this mapping is placed in the RTSP 3832 control channel. 3834 In order to compensate for drift for long, uninterrupted 3835 presentations, RTSP clients should additionally map NPT to NTP, using 3836 initial RTCP sender reports to do the mapping, and later reports to 3837 check drift against the mapping. 3839 Example: 3841 Range:npt=3.25-15 3842 RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; 3843 rtptime=12345678,url="rtsp://example.com/foo/video" 3844 ssrc=9A9DE123:seq=30211;rtptime=29567112 3846 Lets assume that audio uses a 16kHz RTP timestamp clock and Video 3847 a 90kHz RTP timestamp clock. Then the media synchronization is 3848 depicted in the following way. 3850 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 3851 Audio PA A 3852 Video V PV 3854 X: NPT time value = 3.25, from Range header. 3855 A: RTP timestamp value for Audio from RTP-Info header (12345678). 3856 V: RTP timestamp value for Video from RTP-Info header (29567112). 3857 PA: RTP audio packet carrying an RTP timestamp of 12344878. Which 3858 corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2 3859 PV: RTP video packet carrying an RTP timestamp of 29573412. Which 3860 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 3862 14.39 Scale 3864 A scale value of 1 indicates normal play at the normal forward 3865 viewing rate. If not 1, the value corresponds to the rate with 3866 respect to normal viewing rate. For example, a ratio of 2 indicates 3867 twice the normal viewing rate ("fast forward") and a ratio of 0.5 3868 indicates half the normal viewing rate. In other words, a ratio of 2 3869 has normal play time increase at twice the wallclock rate. For every 3870 second of elapsed (wallclock) time, 2 seconds of content will be 3871 delivered. A negative value indicates reverse direction. For certain 3872 media transports this may require certain considerations to work 3873 consistent, see section B.1 for description on how RTP handles this. 3875 Unless requested otherwise by the Speed parameter, the data rate 3876 SHOULD not be changed. Implementation of scale changes depends on the 3877 server and media type. For video, a server may, for example, deliver 3878 only key frames or selected key frames. For audio, it may time-scale 3879 the audio while preserving pitch or, less desirably, deliver 3880 fragments of audio. 3882 The server should try to approximate the viewing rate, but may 3883 restrict the range of scale values that it supports. The response 3884 MUST contain the actual scale value chosen by the server. 3886 If the server does not implement the possibility to scale, it will 3887 not return a Scale header. A server supporting Scale operations for 3888 PLAY SHALL indicate this with the use of the "play.scale" feature- 3889 tags. 3891 When indicating a negative scale for a reverse playback, the Range 3892 header MUST indicate a decreasing range as described in section 3893 14.34. 3895 Example of playing in reverse at 3.5 times normal rate: 3897 Scale: -3.5 3898 Range: npt=15-10 3900 14.40 Speed 3902 The Speed request-header field requests the server to deliver data to 3903 the client at a particular speed, contingent on the server's ability 3904 and desire to serve the media stream at the given speed. 3905 Implementation by the server is OPTIONAL. The default is the bit rate 3906 of the stream. 3908 The parameter value is expressed as a decimal ratio, e.g., a value of 3909 2.0 indicates that data is to be delivered twice as fast as normal. A 3910 speed of zero is invalid. All speeds may not be possible to support. 3911 Therefore the actual used speed MUST be included in the response. The 3912 lack of a response header is indication of lack of support from the 3913 server of this functionality. Support of the speed functionality are 3914 indicated by the "play.speed" featuretag. 3916 Example: 3918 Speed: 2.5 3920 Use of this field changes the bandwidth used for data delivery. It is 3921 meant for use in specific circumstances where preview of the 3922 presentation at a higher or lower rate is necessary. Implementors 3923 should keep in mind that bandwidth for the session may be negotiated 3924 beforehand (by means other than RTSP), and therefore re-negotiation 3925 may be necessary. When data is delivered over UDP, it is highly 3926 recommended that means such as RTCP be used to track packet loss 3927 rates. If the data transport is performed over public best-effort 3928 networks the sender MUST perform congestion control of the stream(s). 3929 This can result in that the communicated speed is impossible to 3930 maintain. 3932 14.41 Server 3934 See [H14.38], however the header syntax is corrected in section 3935 19.2.3. 3937 14.42 Session 3939 The Session request-header and response-header field identifies an 3940 RTSP session. An RTSP session is created by the server as a result of 3941 a successful SETUP request and in the response the session identifier 3942 is given to the client. The RTSP session exist until destroyed by a 3943 TEARDOWN or timed out by the server. 3945 The session identifier is chosen by the server (see Section 3.3) and 3946 MUST be returned in the SETUP response. Once a client receives a 3947 session identifier, it SHALL be included in any request related to 3948 that session. This means that the Session header MUST be included in 3949 a request using the following methods: PLAY, PAUSE, and TEARDOWN, and 3950 MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and 3951 REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response 3952 the session header SHALL be included in methods, SETUP, PLAY, and 3953 PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if 3954 included in the request of the following methods it SHALL also be 3955 included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER, 3956 and SHALL NOT be included in DESCRIBE. 3958 The timeout parameter MAY be included in a SETUP response, and SHALL 3959 NOT be included in requests. The server uses it to indicate to the 3960 client how long the server is prepared to wait between RTSP commands 3961 or other signs of life before closing the session due to lack of 3962 activity (see below and Section A). The timeout is measured in 3963 seconds, with a default of 60 seconds (1 minute). The length of the 3964 session timeout SHALL NOT be changed in a established session. 3966 The mechanisms for showing liveness of the client is, any RTSP 3967 request with a Session header, if RTP & RTCP is used an RTCP message, 3968 or through any other used media protocol capable of indicating 3969 liveness of the RTSP client. It is RECOMMENDED that a client does not 3970 wait to the last second of the timeout before trying to send a 3971 liveness message. The RTSP message may be lost or when using reliable 3972 protocols, such as TCP, the message may take some time to arrive 3973 safely at the receiver. To show liveness between RTSP request issued 3974 to accomplish other things, the following mechanisms can be used, in 3975 descending order of preference: 3977 RTCP: If RTP is used for media transport RTCP SHOULD be used. If 3978 RTCP is used to report transport statistics, it SHALL also 3979 work as keep alive. The server can determine the client by 3980 used network address and port together with the fact that 3981 the client is reporting on the servers SSRC(s). A downside 3982 of using RTCP is that it only gives statistical guarantees 3983 to reach the server. However that probability is so low 3984 that it can be ignored in most cases. For example, a 3985 session with 60 seconds timeout and enough bitrate assigned 3986 to RTCP messages to send a message from client to server on 3987 average every 5 seconds. That client have for a network 3988 with 5 % packet loss, the probability to fail showing 3989 liveness sign in that session within the timeout interval 3990 of 2.4*E-16. In sessions with shorter timeout times, or 3991 much higher packet loss, or small RTCP bandwidths SHOULD 3992 also use any of the mechanisms below. 3994 SET_PARAMETER: When using SET_PARAMETER for keep alive, no body 3995 SHOULD be included. This method is the RECOMMENDED RTSP 3996 method to use in request only intended to perform keep- 3997 alive. 3999 OPTIONS: This method does also work. However it causes the 4000 server to perform unnecessary processing and result in 4001 bigger responses than necessary for the task. The reason 4002 for this is that the server needs to determine what 4003 capabilities that are associated with the media resource to 4004 correctly populate the Public and Allow headers. 4006 Note that a session identifier identifies an RTSP session across 4007 transport sessions or connections. RTSP requests for a given session 4008 can use different URIs (Presentation and media URIs). Note, that 4009 there are restrictions depending on the session which URIs that are 4010 acceptable for a given method. However, multiple "user" sessions for 4011 the same URI from the same client will require use of different 4012 session identifiers. 4014 The session identifier is needed to distinguish several 4015 delivery requests for the same URI coming from the same 4016 client. 4018 The response 454 (Session Not Found) SHALL be returned if the session 4019 identifier is invalid. 4021 14.43 Supported 4023 The Supported header field enumerates all the extensions supported by 4024 the client or server using feature tags. The header carries the 4025 extensions supported by the message sending entity. The Supported 4026 header MAY be included in any request. When present in a request, 4027 the receiver MUST respond with its corresponding Supported header. 4028 Note, also in 4xx and 5xx responses is the supported header included. 4030 The Supported header field contains a list of feature-tags, described 4031 in Section 3.7, that are understood by the client or server. 4033 Example: 4035 C->S: OPTIONS rtsp://example.com/ RTSP/2.0 4036 Supported: foo, bar, blech 4038 S->C: RTSP/2.0 200 OK 4039 Supported: bar, blech, baz 4041 14.44 Timestamp 4043 The Timestamp general-header field describes when the agent sent the 4044 request. The value of the timestamp is of significance only to the 4045 agent and may use any timescale. The responding agent MUST echo the 4046 exact same value and MAY, if it has accurate information about this, 4047 add a floating point number indicating the number of seconds that has 4048 elapsed since it has received the request. The timestamp is used by 4049 the agent to compute the round-trip time to the responding agent so 4050 that it can adjust the timeout value for retransmissions. It also 4051 resolves retransmission ambiguities for unreliable transport of RTSP. 4053 14.45 Transport 4055 The Transport request and response header field indicates which 4056 transport protocol is to be used and configures its parameters such 4057 as destination address, compression, multicast time-to-live and 4058 destination port for a single stream. It sets those values not 4059 already determined by a presentation description. 4061 Transports are comma separated, listed in order of preference. 4062 Parameters may be added to each transport, separated by a semicolon. 4063 The server SHOULD return a Transport response-header field in the 4064 response to indicate the values actually chosen. The Transport header 4065 field MAY also be used to change certain transport parameters. A 4066 server MAY refuse to change parameters of an existing stream. 4068 A Transport request header field MAY contain a list of transport 4069 options acceptable to the client, in the form of multiple 4070 transportspec entries. In that case, the server MUST return the 4071 single (transport-spec) which was actually chosen. The number of 4072 transportspec entries is expected to be limited as the client will 4073 get guidance on what configurations that are possible from the 4074 presentation description. 4076 A transport-spec transport option may only contain one of any given 4077 parameter within it. Parameters MAY be given in any order. 4078 Additionally, it may only contain the unicast or the multicast 4079 transport type parameter. Unknown parameters SHALL be ignored. The 4080 requester need to ensure that the responder understands the 4081 parameters through the use of feature tags and the Require header. 4083 Any parameters part of future extensions requires clarification if 4084 they are safe to ignore in accordance to this specification, or is 4085 required to be understood. If a parameter is required to be 4086 understood, then a feature tag MUST be defined for the functionality 4087 and used in the Require and/or Proxy-Require headers. 4089 The Transport header field is restricted to describing a 4090 single media stream. (RTSP can also control multiple 4091 streams as a single entity.) Making it part of RTSP rather 4092 than relying on a multitude of session description formats 4093 greatly simplifies designs of firewalls. 4095 The syntax for the transport specifier is 4097 transport/profile/lower-transport. 4099 The default value for the "lower-transport" parameters is specific to 4100 the profile. For RTP/AVP, the default is UDP. 4102 There are two different methods for how to specify where the media 4103 should be delivered: 4105 o The presence of this parameter and its values indicates the 4106 destination address or addresses (host address and port pairs 4107 for IP flows) necessary for the media transport. 4109 o The lack of the dest_addr parameter indicates that the server 4110 SHALL send media to same address for which the RTSP messages 4111 originates. Does not work for transports requiring explicitly 4112 given destination ports. 4114 The choice of method for indicating where the media is to be 4115 delivered depends on the use case. In many case the only allowed 4116 method will be to use no explicit address indication and have the 4117 server deliver media to the source of the RTSP messages. 4119 An RTSP proxy will need to take care. If the media is not desired to 4120 be routed through the proxy, the proxy will need to introduce the 4121 destination indication. 4123 Below are the configuration parameters associated with transport: 4125 General parameters: 4127 unicast / multicast: This parameter is a mutually exclusive 4128 indication of whether unicast or multicast delivery will be 4129 attempted. One of the two values MUST be specified. Clients 4130 that are capable of handling both unicast and multicast 4131 transmission needs to indicate such capability by including 4132 two full transport-specs with separate parameters for each. 4134 layers: The number of multicast layers to be used for this media 4135 stream. The layers are sent to consecutive addresses 4136 starting at the dest_addr address. 4138 dest_addr: A general destination address parameter that can 4139 contain one or more address specifications. Each 4140 combination of Protocol/Profile/Lower Transport needs to 4141 have the format and interpretation of its address 4142 specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, 4143 the address specification is a tuple containing a host 4144 address and port. 4146 The client originating the RTSP request MAY specify the 4147 destination address of the stream recipient with the host 4148 address part of the tuple. When the destination address is 4149 specified, the recipient may be a different party than the 4150 originator of the request. To avoid becoming the unwitting 4151 perpetrator of a remote-controlled denial-of-service 4152 attack, a server MUST perform security checks (see Section 4153 20.1) and SHOULD log such attempts before allowing the 4154 client to direct a media stream to a recipient address not 4155 chosen by the server. Implementations cannot rely on TCP as 4156 reliable means of client identification. If the server does 4157 not allow the host address part of the tuple to be set, it 4158 SHALL return 463 (Destination Prohibited). 4160 The host address part of the tuple MAY be empty, for 4161 example ":58044", in cases when only destination port is 4162 desired to be specified. 4164 src_addr: A general source address parameter that can contain 4165 one or more address specifications. Each combination of 4166 Protocol/Profile/Lower Transport needs to have the format 4167 and interpretation of its address specification defined. 4168 For RTP/AVP/UDP and RTP/AVP/TCP, the address specification 4169 is a tuple containing a host address and port. 4171 This parameter MUST be specified by the server if it 4172 transmits media packets from another address than the one 4173 RTSP messages are sent to. This will allow the client to 4174 verify source address and give it a destination address for 4175 its RTCP feedback packets if RTP is used. The address or 4176 addresses indicated in the src_addr parameter SHOULD be 4177 used both for sending and receiving of the media streams 4178 data packets. The main reasons are threefold: First, 4179 indicating the port and source address(s) lets the receiver 4180 know where from the packets is expected to originate. 4181 Secondly, traversal of NATs are greatly simplified when 4182 traffic is flowing symmetrically over a NAT binding. 4183 Thirdly, certain NAT traversal mechanisms, needs to know to 4184 which address and port to send so called "binding packets" 4185 from the receiver to the sender, thus creating a address 4186 binding in the NAT that the sender to receiver packet flow 4187 can use. 4189 This information may also be available through SDP. 4190 However, since this is more a feature of transport 4191 than media initialization, the authoritative source 4192 for this information should be in the SETUP response. 4194 mode: The mode parameter indicates the methods to be supported 4195 for this session. Valid values are PLAY and RECORD. If not 4196 provided, the default is PLAY. The RECORD value was 4197 defined in RFC 2326 and is deprecated in this 4198 specification. 4200 append: The append parameter was used together with RECORD and 4201 is now deprecated. 4203 interleaved: The interleaved parameter implies mixing the media 4204 stream with the control stream in whatever protocol is 4205 being used by the control stream, using the mechanism 4206 defined in Section 12. The argument provides the channel 4207 number to be used in the $ statement and MUST be present. 4208 This parameter MAY be specified as a range, e.g., 4209 interleaved=4-5 in cases where the transport choice for the 4210 media stream requires it, e.g. for RTP with RTCP. The 4211 channel number given in the request are only a guidance 4212 from the client to the server on what channel number(s) to 4213 use. The server MAY set any valid channel number in the 4214 response. The declared channel(s) are bi-directional, so 4215 both end-parties MAY send data on the given channel. One 4216 example of such usage is the second channel used for RTCP, 4217 where both server and client sends RTCP packets on the same 4218 channel. 4220 This allows RTP/RTCP to be handled similarly to the 4221 way that it is done with UDP, i.e., one channel for 4222 RTP and the other for RTCP. 4224 Multicast-specific: 4226 ttl: multicast time-to-live. 4228 RTP-specific: 4230 These parameters are MAY only be used if the media transport protocol 4231 is RTP. 4233 ssrc: The ssrc parameter, if included in a SETUP response, 4234 indicates the RTP SSRC [16] value(s) that will be used by 4235 the media server for RTP packets within the stream. It is 4236 expressed as an eight digit hexadecimal value. 4238 The ssrc parameter SHALL NOT be specified in requests. The 4239 functionality of specifying the ssrc parameter in a SETUP 4240 request is deprecated as it is incompatible with the 4241 specification of RTP in RFC 3550 [16]. If the parameter is 4242 included in the Transport header of a SETUP request, the 4243 server MAY ignore it, and choose an appropriate SSRC for 4244 the stream. The server MAY set the ssrc parameter in the 4245 Transport header of the response. 4247 The combination of transport protocol, profile and lower transport 4248 needs to be defined. A number of combinations are defined in the 4249 appendix B. 4251 Below is a usage example, showing a client advertising the capability 4252 to handle multicast or unicast, preferring multicast. Since this is 4253 a unicast-only stream, the server responds with the proper transport 4254 parameters for unicast. 4256 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 4257 CSeq: 302 4258 Transport: RTP/AVP;multicast;mode="PLAY", 4259 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 4260 "192.0.2.5:3457";mode="PLAY" 4262 S->C: RTSP/2.0 200 OK 4263 CSeq: 302 4264 Date: 23 Jan 1997 15:35:06 GMT 4265 Session: 47112344 4266 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ 4267 "192.0.2.5:3457";src_addr="192.0.2.224:6256" 4268 /"192.0.2.224:6257";mode="PLAY" 4270 14.46 Unsupported 4272 The Unsupported response-header field lists the features not 4273 supported by the server. In the case where the feature was specified 4274 via the Proxy-Require field (Section 14.31), if there is a proxy on 4275 the path between the client and the server, the proxy MUST send a 4276 response message with a status code of 551 (Option Not Supported). 4277 The request SHALL NOT be forwarded. 4279 See Section 14.37 for a usage example. 4281 14.47 User-Agent 4283 See [H14.43] for explanation, however the syntax is clarified due to 4284 an error in RFC 2616. A Client SHOULD include this header in all RTSP 4285 messages it sends. 4287 14.48 Vary 4289 See [H14.44] 4291 14.49 Via 4293 See [H14.45]. 4295 14.50 WWW-Authenticate 4297 See [H14.47]. 4299 15 Proxies 4301 RTSP Proxies are RTSP agents that sit in between a client and a 4302 server. A proxy can take on both the role as a client and as server 4303 depending on what it tries to accomplish. Proxies are also introduced 4304 for several different reasons. 4306 Caching Proxy: This type of proxy is used to reduce the workload 4307 on servers and connections. By caching a presentation, both 4308 description and media streams the proxy can serve a client 4309 content without requesting it from the server once it has 4310 been cached and hasn't become stale. See the caching 4311 section 16. 4313 Access Proxy: This type of proxy is used to ensure that a RTSP 4314 client get access to servers on an external network. Thus 4315 this proxy is placed on the border between two domains, 4316 e.g. a private address space and the public internet. The 4317 proxy performs the necessary translation, usually 4318 addresses, and often also media stream translation or 4319 redirection. 4321 Security Proxy: This type of proxy is used to help facilitate 4322 security functions around RTSP. For example when having a 4323 firewalled network, the security proxy request that the 4324 necessary pinholes in the firewall is opened when a client 4325 in the protected network want to access media streams on 4326 the external side. It can also provide network owners with 4327 a logging and audit point for RTSP sessions, e.g. for 4328 corporations that tracks or limits their employees access 4329 to certain type of content. 4331 All type of proxies can be used also when using secured communication 4332 with TLS as RTSP 2.0 allows the client to approve certificates for 4333 connection establishment from a proxy, see section 18.3.2. 4335 Access proxies SHOULD NOT be used in equipment like NATs and 4336 firewalls that aren't expected to be regularly maintained, like home 4337 or small office equipment. In these cases it is better to use the NAT 4338 traversal procedures defined for RTSP 2.0 [25]. The reason for these 4339 recommendations is that any extensions of RTSP resulting in new media 4340 transport protocols or profiles, new parameters etc may fail in a 4341 proxy that isn't maintained. Thus resulting in blocking further 4342 development of RTSP and its usage. 4344 The existence of proxies must always be considered when developing 4345 new RTSP extensions. There must be definition of how proxies may 4346 handle the extension, if it is required to understand it, thus 4347 requiring a feature tag to be used in the Proxy-Require header. 4349 16 Caching 4351 In HTTP, response-request pairs are cached. RTSP differs 4352 significantly in that respect. Responses are not cacheable, with the 4353 exception of the presentation description returned by DESCRIBE. 4354 (Since the responses for anything but DESCRIBE and GET_PARAMETER do 4355 not return any data, caching is not really an issue for these 4356 requests.) However, it is desirable for the continuous media data, 4357 typically delivered out-of-band with respect to RTSP, to be cached, 4358 as well as the session description. 4360 On receiving a SETUP or PLAY request, a proxy ascertains whether it 4361 has an up-to-date copy of the continuous media content and its 4362 description. It can determine whether the copy is up-to-date by 4363 issuing a SETUP or DESCRIBE request, respectively, and comparing the 4364 Last-Modified header with that of the cached copy. If the copy is not 4365 up-to-date, it modifies the SETUP transport parameters as appropriate 4366 and forwards the request to the origin server. Subsequent control 4367 commands such as PLAY or PAUSE then pass the proxy unmodified. The 4368 proxy delivers the continuous media data to the client, while 4369 possibly making a local copy for later reuse. The exact behavior 4370 allowed to the cache is given by the cache-response directives 4371 described in Section 14.10. A cache MUST answer any DESCRIBE requests 4372 if it is currently serving the stream to the requestor, as it is 4373 possible that low-level details of the stream description may have 4374 changed on the origin-server. 4376 Note that an RTSP cache, unlike the HTTP cache, is of the "cut- 4377 through" variety. Rather than retrieving the whole resource from the 4378 origin server, the cache simply copies the streaming data as it 4379 passes by on its way to the client. Thus, it does not introduce 4380 additional latency. 4382 To the client, an RTSP proxy cache appears like a regular media 4383 server, to the media origin server like a client. Just as an HTTP 4384 cache has to store the content type, content language, and so on for 4385 the objects it caches, a media cache has to store the presentation 4386 description. Typically, a cache eliminates all transport-references 4387 (that is, multicast information) from the presentation description, 4388 since these are independent of the data delivery from the cache to 4389 the client. Information on the encodings remains the same. If the 4390 cache is able to translate the cached media data, it would create a 4391 new presentation description with all the encoding possibilities it 4392 can offer. 4394 17 Examples 4396 This section contains several different examples trying to illustrate 4397 possible ways of using RTSP. The examples can also help with the 4398 understanding of how functions of RTSP work. However remember that 4399 this is examples and the normative and syntax description in the 4400 other sections takes precedence. Please also note that many of the 4401 example MAY contain syntax illegal line breaks to accommodate the 4402 formatting restriction that the RFC series impose. 4404 17.1 Media on Demand (Unicast) 4406 Client C requests a movie distributed from two different media 4407 servers A (audio.example.com ) and V (video.example.com ). The media 4408 description is stored on a web server W. The media description 4409 contains descriptions of the presentation and all its streams, 4410 including the codecs that are available, dynamic RTP payload types, 4411 the protocol stack, and content information such as language or 4412 copyright restrictions. It may also give an indication about the 4413 timeline of the movie. 4415 In this example, the client is only interested in the last part of 4416 the movie. 4418 C->W: GET /twister.sdp HTTP/1.1 4419 Host: www.example.com 4420 Accept: application/sdp 4422 W->C: HTTP/1.0 200 OK 4423 Date: 23 Jan 1997 15:35:06 GMT 4424 Content-Type: application/sdp 4425 Content-Length: 264 4426 Expires: 23 Jan 1998 15:35:06 GMT 4428 v=0 4429 o=- 2890844526 2890842807 IN IP4 192.16.24.202 4430 s=RTSP Session 4431 e=adm@example.com 4432 a=range:npt=0-1:49:34 4433 t=0 0 4434 m=audio 0 RTP/AVP 0 4435 a=control:rtsp://audio.example.com/twister/audio.en 4436 m=video 0 RTP/AVP 31 4437 a=control:rtsp://video.example.com/twister/video 4439 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 4440 CSeq: 1 4441 User-Agent: PhonyClient/1.2 4442 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 4443 RTP/AVP/TCP;unicast;interleaved=0-1 4445 A->C: RTSP/2.0 200 OK 4446 CSeq: 1 4447 Session: 12345678 4448 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 4449 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 4450 Date: 23 Jan 1997 15:35:12 GMT 4451 Server: PhonyServer/1.0 4452 Expires: 24 Jan 1997 15:35:12 GMT 4453 Cache-Control: public 4454 Accept-Ranges: NPT, SMPTE 4456 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 4457 CSeq: 1 4458 User-Agent: PhonyClient/1.2 4459 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059", 4460 RTP/AVP/TCP;unicast;interleaved=0-1 4462 V->C: RTSP/2.0 200 OK 4463 CSeq: 1 4464 Session: 23456789 4465 Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059"; 4466 src_addr="192.0.2.5:5002"/"192.0.2.5:5003" 4467 Date: 23 Jan 1997 15:35:12 GMT 4468 Server: PhonyServer/1.0 4469 Cache-Control: public 4470 Expires: 24 Jan 1997 15:35:12 GMT 4471 Accept-Ranges: NPT, SMPTE 4473 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 4474 CSeq: 2 4475 User-Agent: PhonyClient/1.2 4476 Session: 23456789 4477 Range: smpte=0:10:00- 4479 V->C: RTSP/2.0 200 OK 4480 CSeq: 2 4481 Session: 23456789 4482 Range: smpte=0:10:00-1:49:23 4483 RTP-Info: url="rtsp://video.example.com/twister/video" 4484 ssrc=A17E189D:seq=12312232;rtptime=78712811 4485 Server: PhonyServer/2.0 4486 Date: 23 Jan 1997 15:35:13 GMT 4488 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0 4489 CSeq: 2 4490 User-Agent: PhonyClient/1.2 4491 Session: 12345678 4492 Range: smpte=0:10:00- 4494 A->C: RTSP/2.0 200 OK 4495 CSeq: 2 4496 Session: 12345678 4497 Range: smpte=0:10:00-1:49:23 4498 RTP-Info: url="rtsp://audio.example.com/twister/audio.en" 4499 ssrc=3D124F01:seq=876655;rtptime=1032181 4500 Server: PhonyServer/1.0 4501 Date: 23 Jan 1997 15:35:13 GMT 4503 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0 4504 CSeq: 3 4505 User-Agent: PhonyClient/1.2 4506 Session: 12345678 4508 A->C: RTSP/2.0 200 OK 4509 CSeq: 3 4510 Server: PhonyServer/1.0 4511 Date: 23 Jan 1997 15:36:52 GMT 4513 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0 4514 CSeq: 3 4515 User-Agent: PhonyClient/1.2 4516 Session: 23456789 4518 V->C: RTSP/2.0 200 OK 4519 CSeq: 3 4520 Server: PhonyServer/2.0 4521 Date: 23 Jan 1997 15:36:52 GMT 4523 Even though the audio and video track are on two different servers, 4524 may start at slightly different times, and may drift with respect to 4525 each other, the client can synchronize the two using standard RTP 4526 methods, in particular the time scale contained in the RTCP sender 4527 reports. Initial synchronization is achieved through the RTP-Info and 4528 Range headers information in the PLAY response. 4530 17.2 Streaming of a Container file 4532 For purposes of this example, a container file is a storage entity in 4533 which multiple continuous media types pertaining to the same end-user 4534 presentation are present. In effect, the container file represents an 4535 RTSP presentation, with each of its components being RTSP streams. 4536 Container files are a widely used means to store such presentations. 4537 While the components are transported as independent streams, it is 4538 desirable to maintain a common context for those streams at the 4539 server end. 4541 This enables the server to keep a single storage handle 4542 open easily. It also allows treating all the streams 4543 equally in case of any prioritization of streams by the 4544 server. 4546 It is also possible that the presentation author may wish to prevent 4547 selective retrieval of the streams by the client in order to preserve 4548 the artistic effect of the combined media presentation. Similarly, in 4549 such a tightly bound presentation, it is desirable to be able to 4550 control all the streams via a single control message using an 4551 aggregate URI. 4553 The following is an example of using a single RTSP session to control 4554 multiple streams. It also illustrates the use of aggregate URIs. In a 4555 container file it is also desirable to not write any URI parts which 4556 is not kept, when the container is distributed, like the host and 4557 most of the path element. Therefore this example also uses the "*" 4558 and relative URI in the delivered SDP. 4560 Client C requests a presentation from media server M. The movie is 4561 stored in a container file. The client has obtained an RTSP URI to 4562 the container file. 4564 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 4565 CSeq: 1 4566 User-Agent: PhonyClient/1.2 4568 M->C: RTSP/2.0 200 OK 4569 CSeq: 1 4570 Server: PhonyServer/1.0 4571 Date: 23 Jan 1997 15:35:06 GMT 4572 Content-Type: application/sdp 4573 Content-Length: 257 4574 Content-Base: rtsp://example.com/twister.3gp/ 4575 Expires: 24 Jan 1997 15:35:06 GMT 4577 v=0 4578 o=- 2890844256 2890842807 IN IP4 172.16.2.93 4579 s=RTSP Session 4580 i=An Example of RTSP Session Usage 4581 e=adm@example.com 4582 a=control: * 4583 a=range: npt=0-0:10:34.10 4584 t=0 0 4585 m=audio 0 RTP/AVP 0 4586 a=control: trackID=1 4587 m=video 0 RTP/AVP 26 4588 a=control: trackID=4 4590 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 4591 CSeq: 2 4592 User-Agent: PhonyClient/1.2 4593 Require: play.basic 4594 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 4596 M->C: RTSP/2.0 200 OK 4597 CSeq: 2 4598 Server: PhonyServer/1.0 4599 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; 4600 src_addr="192.0.2.5:9000"/"192.0.2.5:9001" 4601 ssrc=93CB001E 4602 Session: 12345678 4603 Expires: 24 Jan 1997 15:35:12 GMT 4604 Date: 23 Jan 1997 15:35:12 GMT 4605 Accept-Ranges: NPT 4607 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 4608 CSeq: 3 4609 User-Agent: PhonyClient/1.2 4610 Require: play.basic 4611 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" 4612 Session: 12345678 4614 M->C: RTSP/2.0 200 OK 4615 CSeq: 3 4616 Server: PhonyServer/1.0 4617 Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; 4618 src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; 4619 ssrc=A813FC13 4620 Session: 12345678 4621 Expires: 24 Jan 1997 15:35:13 GMT 4622 Date: 23 Jan 1997 15:35:13 GMT 4623 Accept-Range: NPT 4625 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 4626 CSeq: 4 4627 User-Agent: PhonyClient/1.2 4628 Range: npt=0-10, npt=30- 4629 Session: 12345678 4631 M->C: RTSP/2.0 200 OK 4632 CSeq: 4 4633 Server: PhonyServer/1.0 4634 Date: 23 Jan 1997 15:35:14 GMT 4635 Session: 12345678 4636 Range: npt=0-10, npt=30-623.10 4637 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 4638 ssrc=0D12F123:seq=12345;rtptime=3450012, 4639 url="rtsp://example.com/twister.3gp/trackID=1"; 4640 ssrc=4F312DD8:seq=54321;rtptime=2876889 4642 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 4643 CSeq: 5 4644 User-Agent: PhonyClient/1.2 4645 Session: 12345678 4647 M->C: RTSP/2.0 200 OK 4648 CSeq: 5 4649 Server: PhonyServer/1.0 4650 Date: 23 Jan 1997 15:36:01 GMT 4651 Session: 12345678 4652 Range: npt=34.57-623.10 4654 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 4655 CSeq: 6 4656 User-Agent: PhonyClient/1.2 4657 Range: npt=34.57-623.10 4658 Session: 12345678 4660 M->C: RTSP/2.0 200 OK 4661 CSeq: 6 4662 Server: PhonyServer/1.0 4663 Date: 23 Jan 1997 15:36:01 GMT 4664 Session: 12345678 4665 Range: npt=34.57-623.10 4666 RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" 4667 ssrc=0D12F123:seq=12555;rtptime=6330012, 4668 url="rtsp://example.com/twister.3gp/trackID=1" 4669 ssrc=4F312DD8:seq=55021;rtptime=3132889 4671 17.3 Single Stream Container Files 4673 Some RTSP servers may treat all files as though they are "container 4674 files", yet other servers may not support such a concept. Because of 4675 this, clients SHOULD use the rules set forth in the session 4676 description for Request-URIs, rather than assuming that a consistent 4677 URI may always be used throughout. Below are an example of how a 4678 multi-stream server might expect a single-stream file to be served: 4680 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0 4681 Accept: application/x-rtsp-mh, application/sdp 4682 CSeq: 1 4683 User-Agent: PhonyClient/1.2 4685 S->C: RTSP/2.0 200 OK 4686 CSeq: 1 4687 Content-base: rtsp://foo.com/test.wav/ 4688 Content-type: application/sdp 4689 Content-length: 148 4690 Server: PhonyServer/1.0 4691 Date: 23 Jan 1997 15:35:06 GMT 4692 Expires: 23 Jan 1997 17:00:00 GMT 4694 v=0 4695 o=- 872653257 872653257 IN IP4 172.16.2.187 4696 s=mu-law wave file 4697 i=audio test 4698 t=0 0 4699 a=control: * 4700 m=audio 0 RTP/AVP 0 4701 a=control:streamid=0 4703 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0 4704 Transport: RTP/AVP/UDP;unicast; 4705 dest_addr=":6970"/":6971";mode="PLAY" 4706 CSeq: 2 4707 User-Agent: PhonyClient/1.2 4709 S->C: RTSP/2.0 200 OK 4710 Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971"; 4711 src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; 4712 mode="PLAY";ssrc=EAB98712 4713 CSeq: 2 4714 Session: 2034820394 4715 Expires: 23 Jan 1997 16:00:00 GMT 4716 Server: PhonyServer/1.0 4717 Date: 23 Jan 1997 15:35:07 GMT 4719 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0 4720 CSeq: 3 4721 User-Agent: PhonyClient/1.2 4722 Session: 2034820394 4724 S->C: RTSP/2.0 200 OK 4725 CSeq: 3 4726 Server: PhonyServer/1.0 4727 Date: 23 Jan 1997 15:35:08 GMT 4728 Session: 2034820394 4729 Range: npt=0-600 4730 RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" 4731 ssrc=0D12F123:seq=981888;rtptime=3781123 4733 Note the different URI in the SETUP command, and then the switch back 4734 to the aggregate URI in the PLAY command. This makes complete sense 4735 when there are multiple streams with aggregate control, but is less 4736 than intuitive in the special case where the number of streams is 4737 one. However the server has declared that the aggregated control URI 4738 in the SDP and therefore this is legal. 4740 In this case, it is also required that servers accept implementations 4741 that use the non-aggregated interpretation and use the individual 4742 media URI, like this: 4744 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 4745 CSeq: 3 4746 User-Agent: PhonyClient/1.2 4748 17.4 Live Media Presentation Using Multicast 4750 The media server M chooses the multicast address and port. Here, it 4751 is assumed that the web server only contains a pointer to the full 4752 description, while the media server M maintains the full description. 4754 C->W: GET /sessions.html HTTP/2.0 4755 Host: www.example.com 4757 W->C: HTTP/2.0 200 OK 4758 Content-Type: text/html 4760 4761 ... 4762 4764 ... 4765 4767 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 4768 CSeq: 1 4769 Supported: play.basic, play.scale 4771 M->C: RTSP/2.0 200 OK 4772 CSeq: 1 4773 Content-Type: application/sdp 4774 Content-Length: 182 4775 Server: PhonyServer/1.0 4776 Date: 23 Jan 1997 15:35:06 GMT 4777 Supported: play.basic 4779 v=0 4780 o=- 2890844526 2890842807 IN IP4 192.16.24.202 4781 s=RTSP Session 4782 m=audio 3456 RTP/AVP 0 4783 c=IN IP4 224.2.0.1/16 4784 a=control: rtsp://live.example.com/concert/audio 4785 a=range:npt=0- 4787 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 4788 CSeq: 2 4789 Transport: RTP/AVP;multicast 4791 M->C: RTSP/2.0 200 OK 4792 CSeq: 2 4793 Server: PhonyServer/1.0 4794 Date: 23 Jan 1997 15:35:06 GMT 4795 Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/" 4796 224.2.0.1:3457";ttl=16 4797 Session: 0456804596 4798 Accept-Ranges: NPT, UTC 4800 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 4801 CSeq: 3 4802 Session: 0456804596 4804 M->C: RTSP/2.0 200 OK 4805 CSeq: 3 4806 Server: PhonyServer/1.0 4807 Date: 23 Jan 1997 15:35:07 GMT 4808 Session: 0456804596 4809 Range:npt=1256- 4810 RTP-Info: url="rtsp://live.example.com/concert/audio" 4811 ssrc=0D12F123:seq=1473; rtptime=80000 4813 17.5 Capability Negotiation 4815 This examples illustrate how the client and server determines their 4816 capability to support a special feature, in this case "play.scale". 4817 The server, through the clients request and the included Supported 4818 header, learns that the client is supporting this updated 4819 specification, and also supports the playback time scaling feature of 4820 RTSP. The server's response contains the following feature related 4821 information to the client; it supports the updated specification 4822 (play.basic), the extended functionality of time scaling of content 4823 (play.scale), and one "example.com" proprietary feature 4824 (example.com.flight). The client also learns the methods supported 4825 (Public header) by the server for the indicated resource. 4827 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 4828 CSeq: 1 4829 Supported: play.basic, play.scale 4830 User-Agent: PhonyClient/1.2 4832 S->C: RTSP/2.0 200 OK 4833 CSeq: 1 4834 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN 4835 Server: PhonyServer/2.0 4836 Supported: play.basic, play.scale, example.com.flight 4838 When the client sends its SETUP request it tells the server that it 4839 is requires support of the play.scale feature for this session by 4840 including the Require header. 4842 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 4843 CSeq: 3 4844 User-Agent: PhonyClient/1.2 4845 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", 4846 RTP/AVP/TCP;unicast;interleaved=0-1 4847 Require: play.scale 4849 S->C: RTSP/2.0 200 OK 4850 CSeq: 3 4851 Session: 12345678 4852 Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; 4853 src_addr="192.0.2.5:5000"/"192.0.2.5:5001" 4854 Server: PhonyServer/2.0 4855 Accept-Ranges: NPT, SMPTE 4857 18 Security Framework 4859 The RTSP security framework consists of two high level components: 4860 the pure authentication mechanisms based on HTTP authentication, and 4861 the transport protection based on TLS, which is independent of RTSP. 4862 Because of the similarity in syntax and usage between RTSP servers 4863 and HTTP servers, the security for HTTP is re-used to a large extent. 4865 18.1 RTSP and HTTP Authentication 4867 RTSP and HTTP share common authentication schemes, and thus follow 4868 the same usage guidelines as specified in [8] and also in [H15]. 4869 Servers SHOULD implement both basic and digest [8] authentication. 4871 It should be stressed that using the HTTP authentication alone does 4872 not provide full control message security. Therefore, in environments 4873 requiring tighter security for the control messages, TLS SHOULD be 4874 used, see Section 18.2. 4876 18.2 RTSP over TLS 4878 RTSP SHALL follow the same guidelines with regards to TLS [7] usage 4879 as specified for HTTP, see [17]. RTSP over TLS is separated from 4880 unsecured RTSP both on URI level and port level. Instead of using the 4881 "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier 4882 MUST be used to signal RTSP over TLS. If no port is given in a URI 4883 with the "rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP. 4885 When a client tries to setup an insecure channel to the server (using 4886 the "rtsp" URI), and the policy for the resource requires a secure 4887 channel, the server SHALL redirect the client to the secure service 4888 by sending a 301 redirect response code together with the correct 4889 Location URI (using the "rtsps" scheme). 4891 It should be noted that TLS allows for mutual authentication (when 4892 using both server and client certificates). Still, one of the more 4893 common way TLS is used is to only provide server side authentication 4894 (often to avoid client certificates). TLS is then used in addition to 4895 HTTP authentication, providing transport security and server 4896 authentication, while HTTP Authentication is used to authenticate the 4897 client. 4899 RTSP includes the possibility to keep a TCP session up between the 4900 client and server, throughout the RTSP session lifetime. It may be 4901 convenient to keep the TCP session, not only to save the extra setup 4902 time for TCP, but also the extra setup time for TLS (even if TLS uses 4903 the resume function, there will be almost two extra roundtrips). 4904 Still, when TLS is used, such behavior introduces extra active state 4905 in the server, not only for TCP and RTSP, but also for TLS. This may 4906 increase the vulnerability to DoS attacks. 4908 In addition to these recommendations, Section 18.3 gives further 4909 recommendations of TLS usage with proxies. 4911 18.3 Security and Proxies 4912 The nature of a proxy is often to act as a "man-in-the-middle", while 4913 security is often about preventing the existence of a "man-in-the- 4914 middle". This section provides the clients with the possibility to 4915 use proxies even when applying secure transports (TLS). The client 4916 needs to select between using the below specified procedure or using 4917 a TLS connection directly (by-passing any proxies) to the server. The 4918 choice may be dependent on policies. 4920 There are basically two categories of inspecting proxies, the 4921 transparent proxies (which the client is not aware of) and the non- 4922 transparent proxies (which the client is aware of). An infrastructure 4923 based on proxies requires that the trust model is such that both 4924 client and servers can trust the proxies to handle the RTSP messages 4925 correctly. To be able to trust a proxy, the client and server also 4926 needs to be aware of the proxy. Hence, transparent proxies cannot 4927 generally be seen as trusted and will not work well with security 4928 (unless they work only at transport layer). In the rest of this 4929 section any reference to proxy will be to a non-transparent proxy, 4930 which requires to inspect/manipulate the RTSP messages. 4932 The HTTP Authentication is built on the assumption of proxies and can 4933 provide user-proxy authentication and proxy-proxy/server 4934 authentication in addition to the client-server authentication. 4936 When TLS is applied and a proxy is used, the client will use the 4937 proxy's destination URI address when sending messages. This implies 4938 that for TLS, the client will authenticate the proxy server and not 4939 the end server. Note that, when the client checks the server 4940 certificate in TLS, it MUST check the proxy's identity (URI or 4941 possibly other known identity) against the proxy's identity as 4942 presented in the proxy's Certificate message. 4944 The problem is that for proxy accepted by the client, it needs to be 4945 provided information on which grounds it should accept the next-hop 4946 certificate. Both the proxy and the user may have rules for this, and 4947 the user have the possibility to select the desired behavior. To 4948 handle this case, the Accept-Credentials header (See Section 14.2) is 4949 used, where the client can force the proxy/proxies to relay back the 4950 certificates used by any intermediate proxies as well as the server. 4951 Given the assumption that the proxies are viewed as trusted, it gives 4952 the user a possibility to enforce policies to each trusted proxy of 4953 whether it should accept the next entity in the chain. 4955 A proxy MUST use TLS for the next hop if the RTSP request includes a 4956 "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between 4957 client and proxy, or between proxy and proxy), even if the resource 4958 and the end server does not require to use it. 4960 18.3.1 Accept-Credentials 4962 The Accept-Credentials header can be used by the client to distribute 4963 simple authorization policies to intermediate proxies. The client 4964 includes the Accept-Credentials header to dictate how the proxy 4965 treats the server/next proxy certificate. There are currently three 4966 methods defined: 4968 Any, which means that the proxy (or proxies) SHALL accept 4969 whatever certificate presented. This is of course not a 4970 recommended option to use, but may be useful in certain 4971 circumstances (such as testing). 4973 Proxy, which means that the proxy (or proxies) MUST use its own 4974 policies to validate the certificate and decide whether to 4975 accept it or not. This is convenient in cases where the 4976 user has a strong trust relation with the proxy. Reason why 4977 a strong trust relation may exist are; personal/company 4978 proxy, proxy has a out-of-band policy configuration 4979 mechanism. 4981 User, which means that the proxy (or proxies) MUST send 4982 credential information about the next hop to the client for 4983 authorization. The client can then decide whether the proxy 4984 should accept the certificate or not. See section 18.3.2 4985 for further details. 4987 If the Accept-Credentials header is not included in the RTSP request 4988 from the client, the default method used SHALL be "Proxy". If 4989 something else than the "Proxy" method is used, the Accept- 4990 Credentials header SHALL always be included in the RTSP request from 4991 the client. This is because it cannot be assumed that the proxy 4992 always keeps the TLS state or the users previously preference between 4993 different RTSP messages (in particular if the time interval between 4994 the messages is long). 4996 The "Any" and "Proxy" methods does not require the proxy to provide 4997 any specific response, but only apply the policy as defined for 4998 respectively method. If the policy do not accept the credentials of 4999 the next hop, the entity SHALL respond with a message using status 5000 code 471 (Connection Credentials not accepted). 5002 An RTSP request in the direction server to client MUST NOT include 5003 the Accept-Credential header. As for the non-secured communication, 5004 the possibility for these request depends on the presence of a client 5005 established connection. However if the server to client request is 5006 in relation to a session established over a TLS secured channel, if 5007 MUST be sent in a TLS secured connection. That secured connection 5008 MUST also be the one used by the last client to server request. If no 5009 such transport connection exist at the time when the server desire to 5010 send the request, it silently fails. 5012 Further policies MAY be defined and registered, but should be done so 5013 with caution. 5015 18.3.2 User approved TLS procedure 5017 For the "User" method each proxy MUST perform the the following 5018 procedure for each RTSP request: 5020 o Setup the TLS session to the next hop if not already present 5021 (i.e. run the TLS handshake, but do not send the RTSP 5022 request). 5024 o Extract the peer certificate for the TLS session. 5026 o Check if a matching identity and hash of the peer certificate 5027 is present in the Accept-Credentials header. If present, send 5028 the message to the next hop, and conclude these procedures. If 5029 not, go to the next step. 5031 o The proxy responds to the RTSP request with a 470 or 407 5032 response code. The 407 response code MAY be used when the 5033 proxy requires both user and connection authorization from 5034 user or client. In this message the proxy SHALL include a 5035 Connection-Credentials header, see section 14.12 with the next 5036 hop's identity and certificate. 5038 The client MUST upon receiving a 470 or 407 response with 5039 Connection-Credentials header take the decision on whether to accept 5040 the certificate or not (if it cannot do so, the user SHOULD be 5041 consulted). If the certificate is accepted, the client has to again 5042 send the RTSP request. In that request the client has to include the 5043 Accept-Credentials header including the hash over the DER encoded 5044 certificate for all trusted proxies in the chain. 5046 Example: 5047 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 5048 CSeq: 2 5049 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5050 "192.0.2.5:4589" 5052 P->C: RTSP/2.0 470 Connection Authorization Required 5053 CSeq: 2 5054 Connection-Credentials: "rtsps://test.example.org"; 5055 MIIDNTCCAp... 5057 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 5058 CSeq: 2 5059 Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ 5060 "192.0.2.5:4589" 5061 Accept-Credentials: User "rtsps://test.example.org" ; 5062 dPYD 7txp oGTb AqZZ QJ+v aeOk yH4= ... 5064 One implication of this process is that the connection for secured 5065 RTSP messages may take significantly more round-trip times for the 5066 first message. An complete extra message exchange between the proxy 5067 connecting to the next hop and the client results because of the 5068 process for approval for each hop. However after the first message 5069 exchange the remaining message should not be delayed, if each message 5070 contains the chain of proxies that the requestor accepts. The 5071 procedure of including the credentials in each request rather than 5072 building state in each proxy, avoids the need for revocation 5073 procedures. 5075 19 Syntax 5077 The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) 5078 as defined in RFC 4234 [4]. It uses the basic definitions present in 5079 RFC 4234. 5081 Please note that ABNF strings, e.g. "Accept", are case insensitive as 5082 specified in section 2.3 of RFC 4234. 5084 19.1 Base Syntax 5086 RTSP header field values can be folded onto multiple lines if the 5087 continuation line begins with a space or horizontal tab. All linear 5088 white space, including folding, has the same semantics as SP. A 5089 recipient MAY replace any linear white space with a single SP before 5090 interpreting the field value or forwarding the message downstream. 5091 This is intended to behave exactly as HTTP/1.1 as described in RFC 5092 2616 [8]. The SWS construct is used when linear white space is 5093 optional, generally between tokens and separators. 5095 To separate the header name from the rest of value, a colon is used, 5096 which, by the above rule, allows whitespace before, but no line 5097 break, and whitespace after, including a linebreak. The HCOLON 5098 defines this construct. 5100 OCTET = %x00-FF ; any 8-bit sequence of data 5101 CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) 5102 UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" 5103 LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" 5104 ALPHA = UPALPHA / LOALPHA 5105 DIGIT = %x30-39 ; any US-ASCII digit "0".."9" 5106 CTL = %x00-1F / %x7F ; any US-ASCII control character 5107 ; (octets 0 - 31) and DEL (127) 5108 CR = %x0D ; US-ASCII CR, carriage return (13 5109 LF = %x0A ; US-ASCII LF, linefeed (10) 5110 SP = %x20 ; US-ASCII SP, space (32) 5111 HT = %x09 ; US-ASCII HT, horizontal-tab (9) 5112 DQUOTE = %x22 ; US-ASCII double-quote mark (34) 5113 BACKSLASH = %x5C ; US-ASCII backslash (92) 5114 CRLF = CR LF 5116 LWS = [CRLF] 1*( SP / HT ) 5117 SWS = [LWS] ; sep whitespace 5118 HCOLON = *( SP / HTAB ) ":" SWS 5119 TEXT = %x20-7D / %x80-FF ; any OCTET except CTLs 5120 tspecials = "(" / ")" / "<" / ">" / "@" 5121 / "," / ";" / ":" / BACKSLASH / DQUOTE 5122 / "/" / "[" / "]" / "?" / "=" 5123 / "{" / "}" / SP / HT 5124 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 5125 / %x41-5A / %x5E-7A / %x7C / %x7E) 5126 ; 1* 5127 quoted-string = ( DQUOTE *qdtext DQUOTE ) 5128 qdtext = %x20-21 / %x23-7D / %x80-FF ; any TEXT except <"> 5129 quoted-pair = BACKSLASH CHAR 5130 ctext = %x20-27 / %x2A-7D 5131 / %x80-FF ; any OCTET except CTLs, "(" and ")" 5132 generic-param = token [ EQUAL gen-value ] 5133 gen-value = token / host / quoted-string 5135 safe = "$" / "-" / "_" / "." / "+" 5136 extra = "!" / "*" / "'" / "(" / ")" / "," 5137 rtsp-extra = "!" / "*" / "'" / "(" / ")" 5138 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 5139 / "a" / "b" / "c" / "d" / "e" / "f" 5140 LHEX = DIGIT / %x61-66 ;lowercase a-f 5141 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" 5142 unreserved = ALPHA / DIGIT / safe / extra 5143 rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra 5144 base64 = *base64-unit [base64-pad] 5145 base64-unit = 4base64-char 5146 base64-pad = (2base64-char "==") / (3base64-char "=") 5147 base64-char = ALPHA / DIGIT / "+" / "/" 5149 SLASH = SWS "/" SWS ; slash 5150 EQUAL = SWS "=" SWS ; equal 5151 LPAREN = SWS "(" SWS ; left parenthesis 5152 RPAREN = SWS ")" SWS ; right parenthesis 5153 COMMA = SWS "," SWS ; comma 5154 SEMI = SWS ";" SWS ; semicolon 5155 COLON = SWS ":" SWS ; colon 5156 LDQUOT = SWS DQUOTE ; open double quotation mark 5157 RDQUOT = DQUOTE SWS ; close double quotation mark 5158 RAQUOT = ">" SWS ; right angle quote 5159 LAQUOT = SWS "<" ; left angle quote 5160 TEXT-UTF8char = %x21-7E / UTF8-NONASCII 5161 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 5162 / %xE0-EF 2UTF8-CONT 5163 / %xF0-F7 3UTF8-CONT 5164 / %xF8-FB 4UTF8-CONT 5165 / %xFC-FD 5UTF8-CONT 5166 UTF8-CONT = %x80-BF 5168 19.2 RTSP Protocol Definition 5170 19.2.1 Generic Protocol elements 5172 URI-reference = RTSP-URI / relative-ref 5173 relative-ref = < As defined in RFC 3986 [6]> 5174 RTSP-URI = rtsp-uri-def / rtsps-uri-def / rtspu-uri-def 5175 rtsp-uri-def = "rtsp:" rtsp-uri-rest 5176 rtsps-uri-def = "rtsps:" rtsp-uri-rest 5177 rtspu-uri-def = "rtspu:" rtsp-uri-rest 5178 rtsp-uri-rest = "//" host [":" port] [abs-path-def] [frag-def] 5179 abs-path-def = abs-path ["?" query] 5180 frag-def = "#" fragment 5181 host = 5182 abs-path = 5183 port = *DIGIT ; Is expected to be 1*5DIGIT 5184 query = 5185 fragment = 5186 absolute-URI = 5187 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 5188 IPv6address = hexpart [ ":" IPv4address ] 5189 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 5190 hexseq = hex4 *( ":" hex4) 5191 hex4 = 1*4HEXDIG 5193 smpte-range = smpte-type "=" smpte-range-spec 5194 ;Section 3.4 5195 smpte-range-spec = ( smpte-time "-" [ smpte-time ] ) 5196 / ( "-" smpte-time ) 5197 smpte-type = "smpte" / "smpte-30-drop" 5198 / "smpte-25" / smpte-type-extension 5199 ; other timecodes may be added 5200 smpte-type-extension = token 5201 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 5202 [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] 5204 npt-range = "npt=" npt-range-spec ; Section 3.5 5205 npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) 5206 npt-time = "now" / npt-sec / npt-hhmmss 5207 npt-sec = 1*DIGIT [ "." *DIGIT ] 5208 npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] 5209 npt-hh = 1*DIGIT ; any positive number 5210 npt-mm = 1*2DIGIT ; 0-59 5211 npt-ss = 1*2DIGIT ; 0-59 5213 utc-range = "clock=" utc-range-spec ; Section 3.6 5214 utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) 5215 utc-time = utc-date "T" utc-clock "Z" 5216 utc-date = 8DIGIT ; < YYYYMMDD > 5217 utc-clock = 6DIGIT [ "." fraction ]; < HHMMSS.fraction > 5218 fraction = 1*DIGIT 5220 feature-tag = token 5221 session-id = 8*( ALPHA / DIGIT / safe ) 5222 extension-header = header-name HCOLON header-value 5223 header-name = token 5224 header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) 5226 19.2.2 Message Syntax 5227 RTSP-message = Request / Response ; RTSP/2.0 messages 5228 Request = Request-Line ; Section 6.1 5229 *( general-header ; Section 5 5230 / request-header ; Section 6.2 5231 / entity-header ) ; Section 8.1 5232 CRLF 5233 [ message-body ] ; Section 4.3 5234 Response = Status-Line ; Section 7.1 5235 *( general-header ; Section 5 5236 / response-header ; Section 7.1.2 5237 / entity-header ) ; Section 8.1 5238 CRLF 5239 [ message-body ] ; Section 4.3 5241 Request-Line = Method SP Request-URI SP RTSP-Version CRLF 5242 Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF 5244 Method = "DESCRIBE" ; Section 11.2 5245 / "GET_PARAMETER" ; Section 11.7 5246 / "OPTIONS" ; Section 11.1 5247 / "PAUSE" ; Section 11.5 5248 / "PLAY" ; Section 11.4 5249 / "REDIRECT" ; Section 11.9 5250 / "SETUP" ; Section 11.3 5251 / "SET_PARAMETER" ; Section 11.8 5252 / "TEARDOWN" ; Section 11.6 5253 / extension-method 5254 extension-method = token 5256 Request-URI = "*" / RTSP-URI 5257 RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT 5258 message-body = 1*OCTET 5260 Status-Code = "100" ; Continue 5261 / "200" ; OK 5262 / "201" ; Created 5263 / "250" ; Low on Storage Space 5264 / "300" ; Multiple Choices 5265 / "301" ; Moved Permanently 5266 / "302" ; Moved Temporarily 5267 / "303" ; See Other 5268 / "304" ; Not Modified 5269 / "305" ; Use Proxy 5270 / "400" ; Bad Request 5271 / "401" ; Unauthorized 5272 / "402" ; Payment Required 5273 / "403" ; Forbidden 5274 / "404" ; Not Found 5275 / "405" ; Method Not Allowed 5276 / "406" ; Not Acceptable 5277 / "407" ; Proxy Authentication Required 5278 / "408" ; Request Time-out 5279 / "410" ; Gone 5280 / "411" ; Length Required 5281 / "412" ; Precondition Failed 5282 / "413" ; Request Entity Too Large 5283 / "414" ; Request-URI Too Large 5284 / "415" ; Unsupported Media Type 5285 / "451" ; Parameter Not Understood 5286 / "452" ; reserved 5287 / "453" ; Not Enough Bandwidth 5288 / "454" ; Session Not Found 5289 / "455" ; Method Not Valid in This State 5290 / "456" ; Header Field Not Valid for Resource 5291 / "457" ; Invalid Range 5292 / "458" ; Parameter Is Read-Only 5293 / "459" ; Aggregate operation not allowed 5294 / "460" ; Only aggregate operation allowed 5295 / "461" ; Unsupported transport 5296 / "462" ; Destination unreachable 5297 / "463" ; Destination Prohibited 5298 / "470" ; Connection Authorization Required 5299 / "471" ; Connection Credentials not accepted 5300 / "500" ; Internal Server Error 5301 / "501" ; Not Implemented 5302 / "502" ; Bad Gateway 5303 / "503" ; Service Unavailable 5304 / "504" ; Gateway Time-out 5305 / "505" ; RTSP Version not supported 5306 / "551" ; Option not supported 5307 / extension-code 5308 extension-code = 3DIGIT 5309 Reason-Phrase = *TEXT 5311 general-header = Cache-Control ; Section 14.10 5312 / Connection ; Section 14.11 5313 / CSeq ; Section 14.19 5314 / Date ; Section 14.20 5315 / Proxy-Supported ; Section 14.32 5316 / Supported ; Section 14.43 5317 / Timestamp ; Section 14.44 5318 / Via ; Section 14.49 5319 / extension-header 5321 request-header = Accept ; Section 14.1 and [H14.1] 5322 / Accept-Credentials ; Section 14.2 5323 / Accept-Encoding ; Section 14.3 and [H14.3] 5324 / Accept-Language ; Section 14.4 and [H14.4] 5325 / Authorization ; Section 14.7 and [H14.8] 5326 / Bandwidth ; Section 14.8 5327 / Blocksize ; Section 14.9 5328 / From ; Section 14.23 5329 / If-Match ; Section 14.25 5330 / If-Modified-Since ; Section 14.26 and [H14.25] 5331 / If-None-Match ; Section 14.27 5332 / Proxy-Require ; Section 14.31 5333 / Range ; Section 14.34 5334 / Referer ; Section 14.35 5335 / Require ; Section 14.37 5336 / Scale ; Section 14.39 5337 / Session ; Section 14.42 5338 / Speed ; Section 14.40 5339 / Supported ; Section 14.43 5340 / Transport ; Section 14.45 5341 / User-Agent ; Section 14.47 5342 / extension-header 5344 response-header = Accept-Credentials ; Section 14.2 5345 / Accept-Ranges ; Section 14.5 5346 / Connection-Creds ; Section 14.12 5347 / ETag ; Section 14.21 5348 / Location ; Section 14.29 5349 / Proxy-Authenticate ; Section 14.30 5350 / Public ; Section 14.33 5351 / Range ; Section 14.34 5352 / Retry-After ; Section 14.36 5353 / RTP-Info ; Section 14.38 5354 / Scale ; Section 14.39 5355 / Session ; Section 14.42 5356 / Server ; Section 14.41 5357 / Speed ; Section 14.40 5358 / Transport ; Section 14.45 5359 / Unsupported ; Section 14.46 5360 / Vary ; Section 14.48 5361 / WWW-Authenticate ; Section 14.50 5362 / extension-header 5364 entity-header = Allow ; Section 14.6 5365 / Content-Base ; Section 14.13 5366 / Content-Encoding ; Section 14.14 5367 / Content-Language ; Section 14.15 5368 / Content-Length ; Section 14.16 5369 / Content-Location ; Section 14.17 5370 / Content-Type ; Section 14.18 5371 / Expires ; Section 14.22 and [H14.21] 5372 / Last-Modified ; Section 14.28 5373 / extension-header 5375 19.2.3 Header Syntax 5377 All header syntaxes not defined in this section are defined in 5378 section 14 of the HTTP 1.1 specification [3]. 5380 Accept = Accept-name HCOLON 5381 [ accept-range *(COMMA accept-range) ] 5382 accept-range = media-range *(SEMI accept-param) 5383 media-range = ( "*/*" 5384 / ( m-type SLASH "*" ) 5385 / ( m-type SLASH m-subtype ) 5386 ) *( SEMI m-parameter ) 5387 accept-param = ("q" EQUAL qvalue) / generic-param 5388 qvalue = ( "0" [ "." *3DIGIT ] ) 5389 / ( "1" [ "." *3("0") ] ) 5390 Accept-Credentials = "Accept-Credentials" HCOLON cred-decision CRLF 5391 cred-decision = ("User" COMMA [cred-info]) 5392 / "Proxy" 5393 / "Any" 5394 / token ; For future extensions 5395 cred-info = cred-info-data *(COMMA cred-info-data) 5396 cred-info-data = DQUOTE RTSP-URI DQUOTE SEMI base64 5397 Accept-Encoding = "Accept-Encoding" HCOLON 5398 [ encoding *(COMMA encoding) ] 5399 encoding = codings *(SEMI accept-param) 5400 codings = content-coding / "*" 5401 content-coding = token 5402 Accept-Language = "Accept-Language" HCOLON 5403 [ language *(COMMA language) ] 5404 language = language-range *(SEMI accept-param) 5405 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) 5406 Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF 5407 acceptable-ranges = (range-unit *(COMMA range-unit)) 5408 / "none" 5409 range-unit = "NPT" / "SMPTE" / "UTC" / extension-format 5410 extension-format = token 5411 Allow = "Allow" HCOLON [Method *(COMMA Method)] 5412 Authorization = "Authorization" HCOLON credentials 5413 credentials = ("Digest" LWS digest-response) 5414 / other-response 5415 digest-response = dig-resp *(COMMA dig-resp) 5416 dig-resp = username / realm / nonce / digest-uri 5417 / dresponse / algorithm / cnonce 5418 / opaque / message-qop 5419 / nonce-count / auth-param 5420 username = "username" EQUAL username-value 5421 username-value = quoted-string 5422 digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT 5423 digest-uri-value = Request-URI 5424 ; by HTTP/1.1 5425 message-qop = "qop" EQUAL qop-value 5426 cnonce = "cnonce" EQUAL cnonce-value 5427 cnonce-value = nonce-value 5428 nonce-count = "nc" EQUAL nc-value 5429 nc-value = 8LHEX 5430 dresponse = "response" EQUAL request-digest 5431 request-digest = LDQUOT 32LHEX RDQUOT 5432 auth-param = auth-param-name EQUAL 5433 ( token / quoted-string ) 5434 auth-param-name = token 5435 other-response = auth-scheme LWS auth-param 5436 *(COMMA auth-param) 5437 auth-scheme = token 5438 Bandwidth = "Bandwidth" HCOLON 1*DIGIT CRLF 5439 Blocksize = "Blocksize" HCOLON 1*DIGIT CRLF 5441 Cache-Control = "Cache-Control" HCOLON cache-directive CRLF 5442 *(COMMA cache-directive) 5443 cache-directive = cache-rqst-directive 5444 / cache-rspns-directive 5445 cache-rqst-directive = "no-cache" 5446 / "max-stale" [EQUAL delta-seconds] 5447 / "min-fresh" EQUAL delta-seconds 5448 / "only-if-cached" 5449 / cache-extension 5450 cache-rspns-directive = "public" 5451 / "private" 5452 / "no-cache" 5453 / "no-transform" 5454 / "must-revalidate" 5455 / "proxy-revalidate" 5456 / "max-age" EQUAL delta-seconds 5457 / cache-extension 5458 cache-extension = token [EQUAL (token / quoted-string)] 5459 delta-seconds = 1*DIGIT 5461 Connection-Creds = "Connection-Credentials" HCOLON cred-info CRLF 5462 Connection = "Connection" HCOLON (connection-token) 5463 *(COMMA connection-token) CRLF 5464 connection-token = token 5465 Content-Base = "Content-Base" HCOLON URI-reference CRLF 5466 Content-Encoding = "Content-Encoding" HCOLON 5467 content-coding *(COMMA content-coding) 5468 Content-Language = "Content-Language" HCOLON 5469 language-tag *(COMMA language-tag) 5470 language-tag = primary-tag *( "-" subtag ) 5471 primary-tag = 1*8ALPHA 5472 subtag = 1*8ALPHA 5473 Content-Length = "Content-Length" HCOLON 1*DIGIT 5474 Content-Location = "Content-Location" HCOLON URI-reference 5475 Content-Type = ( "Content-Type" / "c" ) HCOLON media-type 5476 media-type = m-type SLASH m-subtype *(SEMI m-parameter) 5477 m-type = discrete-type / composite-type 5478 discrete-type = "text" / "image" / "audio" / "video" 5479 / "application" / extension-token 5480 composite-type = "message" / "multipart" / extension-token 5481 extension-token = ietf-token / x-token 5482 ietf-token = token 5483 x-token = "x-" token 5484 m-subtype = extension-token / iana-token 5485 iana-token = token 5486 m-parameter = m-attribute EQUAL m-value 5487 m-attribute = token 5488 m-value = token / quoted-string 5489 CSeq = "Cseq" HCOLON 1*DIGIT CRLF 5490 Date = "Date" HCOLON RTSP-date 5491 RTSP-date = rfc1123-date ; HTTP-date 5492 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 5493 date1 = 2DIGIT SP month SP 4DIGIT 5494 ; day month year (e.g., 02 Jun 1982) 5495 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 5496 ; 00:00:00 - 23:59:59 5497 wkday = "Mon" / "Tue" / "Wed" 5498 / "Thu" / "Fri" / "Sat" / "Sun" 5499 month = "Jan" / "Feb" / "Mar" / "Apr" 5500 / "May" / "Jun" / "Jul" / "Aug" 5501 / "Sep" / "Oct" / "Nov" / "Dec" 5502 ETag = "ETag" HCOLON entity-tag 5503 Expires = "Expires" HCOLON delta-seconds 5504 From = "From" HCOLON from-spec 5505 from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) 5506 name-addr = [ display-name ] LAQUOT addr-spec RAQUOT 5507 addr-spec = RTSP-URI / absolute-URI 5508 display-name = *(token LWS)/ quoted-string 5509 from-param = tag-param / generic-param 5510 tag-param = "tag" EQUAL token 5511 If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) 5512 entity-tag-list = entity-tag *(COMMA entity-tag) 5513 entity-tag = [ weak ] opaque-tag 5514 weak = "W/" 5515 opaque-tag = quoted-string 5516 If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date 5517 If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) 5518 Last-Modified = "Last-Modified" HCOLON RTSP-date 5519 Location = "Location" HCOLON RTSP-URI 5520 Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge 5521 challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) 5522 / other-challenge 5523 other-challenge = auth-scheme LWS auth-param 5524 *(COMMA auth-param) 5525 digest-cln = realm / domain / nonce 5526 / opaque / stale / algorithm 5527 / qop-options / auth-param 5528 realm = "realm" EQUAL realm-value 5529 realm-value = quoted-string 5530 domain = "domain" EQUAL LDQUOT URI 5531 *( 1*SP URI ) RDQUOT 5532 URI = RTSP-URI / abs-path 5533 nonce = "nonce" EQUAL nonce-value 5534 nonce-value = quoted-string 5535 opaque = "opaque" EQUAL quoted-string 5536 stale = "stale" EQUAL ( "true" / "false" ) 5537 algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) 5538 qop-options = "qop" EQUAL LDQUOT qop-value 5539 *("," qop-value) RDQUOT 5540 qop-value = "auth" / "auth-int" / token 5541 Proxy-Require = "Proxy-Require" HCOLON feature-tag CRLF 5542 *(COMMA feature-tag) 5543 Proxy-Supported = "Proxy-Supported" HCOLON feature-tag 5544 *(COMMA feature-tag) CRLF 5545 Public = "Public" HCOLON Method *(COMMA Method) CRLF 5546 Range = "Range" HCOLON ranges-list [exec-time] CRLF 5547 ranges-list = ranges-spec *(COMMA ranges-spec) 5548 exec-time = SEMI "time" EQUAL utc-time 5549 ranges-spec = npt-range / utc-range / smpte-range 5550 Referer = "Referer" HCOLON URI-reference 5551 Require = "Require" HCOLON feature-tag-list CRLF 5552 feature-tag-list = feature-tag *(COMMA feature-tag) 5554 RTP-Info = "RTP-Info" HCOLON rtsp-info-spec 5555 *(COMMA rtsp-info-spec) CRLF 5556 rtsp-info-spec = stream-url 1*ssrc-parameter 5557 stream-url = "url" EQUAL DQUOTE URI-reference DQUOTE 5558 ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON 5559 ri-parameter *(SEMI ri-parameter) 5560 ri-parameter = "seq" EQUAL 1*DIGIT 5561 / "rtptime" EQUAL 1*DIGIT 5562 Retry-After = "Retry-After" HCOLON delta-seconds 5563 [ comment ] *( SEMI retry-param ) 5564 retry-param = ("duration" EQUAL delta-seconds) 5565 / generic-param 5567 Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] CRLF 5568 Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ] CRLF 5569 Server = "Server" HCOLON ( product / comment ) 5570 *(LWS (product / comment)) CRLF 5571 product = token [SLASH product-version] 5572 product-version = token 5573 comment = LPAREN *( ctext / quoted-pair) RPAREN 5574 Session = "Session" HCOLON session-id 5575 [ SEMI "timeout" EQUAL delta-seconds ] CRLF 5576 Supported = "Supported" HCOLON [feature-tag-list] CRLF 5578 Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] 5579 timestamp-value = *DIGIT [ "." *DIGIT ] 5580 delay = *DIGIT [ "." *DIGIT ] 5581 Transport = "Transport" HCOLON transport-spec 5582 *(COMMA transport-spec) CRLF 5584 transport-spec = transport-id *tr-parameter 5585 transport-id = trans-id-rtp / other-trans 5586 trans-id-rtp = "RTP/" profile ["/" lower-transport] 5587 ; no LWS is allowed inside transport-id 5588 other-trans = token *("/" token) 5590 profile = "AVP" / "SAVP" / "AVPF" / token 5591 lower-transport = "TCP" / "UDP" / token 5592 tr-parameter = SEMI ( "unicast" / "multicast" ) 5593 / SEMI "interleaved" EQUAL channel [ "-" channel ] 5594 / SEMI "append" 5595 / SEMI "ttl" EQUAL ttl 5596 / SEMI "layers" EQUAL 1*DIGIT 5597 / SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) 5598 / SEMI "client_ssrc" EQUAL ssrc 5599 / SEMI "mode" EQUAL mode-spec 5600 / SEMI "dest_addr" EQUAL addr-list 5601 / SEMI "src_addr" EQUAL addr-list 5602 / SEMI trn-param-ext 5603 trn-param-ext = par-name EQUAL trn-par-value 5604 par-name = token 5605 trn-par-value = *(rtsp-unreserved / DQUOTE *TEXT DQUOTE) 5606 ttl = 1*3DIGIT ; 0 to 255 5607 ssrc = 8HEX 5608 channel = 1*3DIGIT 5609 mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) 5610 mode = "PLAY" / "RECORD" / token 5611 addr-list = quoted-addr *(SLASH quoted-addr) 5612 quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE 5613 host-port = host [":" port] 5614 / ":" port 5615 extension-addr = 1*qdtext 5617 Unsupported = "Unsupported" HCOLON feature-tag-list CRLF 5618 User-Agent = "User-Agent" HCOLON ( product / comment ) 5619 0*(LWS (product / comment)) CRLF 5620 Vary = "Vary" HCOLON ( "*" / field-name-list) 5621 field-name-list = field-name *(COMMA field-name) 5622 field-name = token 5623 Via = "Via" HCOLON via-parm *(COMMA via-parm) 5624 via-parm = sent-protocol LWS sent-by *( SEMI via-params ) 5625 via-params = via-ttl / via-maddr 5626 / via-received / via-branch 5627 / via-extension 5629 via-ttl = "ttl" EQUAL ttl 5630 via-maddr = "maddr" EQUAL host 5631 via-received = "received" EQUAL (IPv4address / IPv6address) 5632 via-branch = "branch" EQUAL token 5633 via-extension = generic-param 5634 sent-protocol = protocol-name SLASH protocol-version 5635 SLASH transport-prot 5636 protocol-name = "RTSP" / token 5637 protocol-version = token 5638 transport-prot = "UDP" / "TCP" / "TLS" / other-transport 5639 other-transport = token 5640 sent-by = host [ COLON port ] 5641 WWW-Authenticate = "WWW-Authenticate" HCOLON challenge 5643 19.3 SDP extension Syntax 5645 This section defines in ABNF the SDP extensions defined for RTSP. 5646 See section C for the definition of the extensions in text. 5648 control-attribute = "a=control:" *SP RTSP-URI 5649 a-range-def = "a=range:" ranges-spec CRLF 5650 a-etag-def = "a=etag:" etag-string CRLF 5651 etag-string = 1*(%x01-09/%x0B-0C/%x0E-FF) 5653 20 Security Considerations 5655 Because of the similarity in syntax and usage between RTSP servers 5656 and HTTP servers, the security considerations outlined in [H15] 5657 apply. Specifically, please note the following: 5659 Abuse of Server Log Information: RTSP and HTTP servers will 5660 presumably have similar logging mechanisms, and thus should 5661 be equally guarded in protecting the contents of those 5662 logs, thus protecting the privacy of the users of the 5663 servers. See [H15.1.1] for HTTP server recommendations 5664 regarding server logs. 5666 Transfer of Sensitive Information: There is no reason to believe 5667 that information transferred via RTSP may be any less 5668 sensitive than that normally transmitted via HTTP. 5669 Therefore, all of the precautions regarding the protection 5670 of data privacy and user privacy apply to implementors of 5671 RTSP clients, servers, and proxies. See [H15.1.2] for 5672 further details. 5674 Attacks Based On File and Path Names: Though RTSP URIs are 5675 opaque handles that do not necessarily have file system 5676 semantics, it is anticipated that many implementations will 5677 translate portions of the Request-URIs directly to file 5678 system calls. In such cases, file systems SHOULD follow the 5679 precautions outlined in [H15.5], such as checking for ".." 5680 in path components. 5682 Personal Information: RTSP clients are often privy to the same 5683 information that HTTP clients are (user name, location, 5684 etc.) and thus should be equally sensitive. See [H15.1] 5685 for further recommendations. 5687 Privacy Issues Connected to Accept Headers: Since may of the 5688 same "Accept" headers exist in RTSP as in HTTP, the same 5689 caveats outlined in [H15.1.4] with regards to their use 5690 should be followed. 5692 DNS Spoofing: Presumably, given the longer connection times 5693 typically associated to RTSP sessions relative to HTTP 5694 sessions, RTSP client DNS optimizations should be less 5695 prevalent. Nonetheless, the recommendations provided in 5696 [H15.3] are still relevant to any implementation which 5697 attempts to rely on a DNS-to-IP mapping to hold beyond a 5698 single use of the mapping. 5700 Location Headers and Spoofing: If a single server supports 5701 multiple organizations that do not trust each another, then 5702 it needs to check the values of Location and Content- 5703 Location header fields in responses that are generated 5704 under control of said organizations to make sure that they 5705 do not attempt to invalidate resources over which they have 5706 no authority. ([H15.4]) 5708 In addition to the recommendations in the current HTTP specification 5709 (RFC 2616 [3], as of this writing) and also of the previous RFC2068 5710 [18], future HTTP specifications may provide additional guidance on 5711 security issues. 5713 The following are added considerations for RTSP implementations. 5715 Concentrated denial-of-service attack: The protocol offers the 5716 opportunity for a remote-controlled denial-of-service 5717 attack. See Section . 5719 Session hijacking: Since there is no or little relation between 5720 a transport layer connection and an RTSP session, it is 5721 possible for a malicious client to issue requests with 5722 random session identifiers which would affect unsuspecting 5723 clients. The server SHOULD use a large, random and non- 5724 sequential session identifier to minimize the possibility 5725 of this kind of attack. For real session security, client 5726 authentication needs to be performed. 5728 Authentication: Servers SHOULD implement both basic and digest 5729 [8] authentication. In environments requiring tighter 5730 security for the control messages, the transport layer 5731 mechanism TLS (RFC 2246 [7]) SHOULD be used. 5733 Stream issues: RTSP only provides for stream control. Stream 5734 delivery issues are not covered in this section, nor in the 5735 rest of this draft. RTSP implementations will most likely 5736 rely on other protocols such as RTP, IP multicast, RSVP and 5737 IGMP, and should address security considerations brought up 5738 in those and other applicable specifications. 5740 Persistently suspicious behavior: RTSP servers SHOULD return 5741 error code 403 (Forbidden) upon receiving a single instance 5742 of behavior which is deemed a security risk. RTSP servers 5743 SHOULD also be aware of attempts to probe the server for 5744 weaknesses and entry points and MAY arbitrarily disconnect 5745 and ignore further requests clients which are deemed to be 5746 in violation of local security policy. 5748 20.1 Remote denial of Service Attack 5750 The attacker may initiate traffic flows to one or more IP addresses 5751 by specifying them as the destination in SETUP requests. While the 5752 attacker's IP address may be known in this case, this is not always 5753 useful in prevention of more attacks or ascertaining the attackers 5754 identity. Thus, an RTSP server MUST only allow client-specified 5755 destinations for RTSP-initiated traffic flows if the server has 5756 ensured that the specified destination address accepts receiving 5757 media through different security mechanisms. Security mechanism that 5758 are acceptable in an increased generality are; verification of the 5759 client's identity, either against a database of known users using 5760 RTSP authentication mechanisms (preferably digest authentication or 5761 stronger); a list of addresses that accept to be media destinations, 5762 especially considering user identity; and media path based 5763 verification. 5765 The server SHOULD NOT allow the destination field to be set unless a 5766 mechanism exists in the system to authorize the request originator to 5767 direct streams to the recipient. It is preferred that this 5768 authorization be performed by the recipient itself and the 5769 credentials passed along to the server. However, in certain cases, 5770 such as when recipient address is a multicast group, or when the 5771 recipient is unable to communicate with the server in an out-of-band 5772 manner, this may not be possible. In these cases server may chose 5773 another method such as a server-resident authorization list to ensure 5774 that the request originator has the proper credentials to request 5775 stream delivery to the recipient. 5777 21 IANA Considerations 5779 This section set up a number of registers for RTSP 2.0 that should be 5780 maintained by IANA. For each registry there is a description on what 5781 it is required to contain, what specification is needed when adding a 5782 entry with IANA, and finally the entries that this document needs to 5783 register. See also the section 1.6 "Extending RTSP". There is also an 5784 IANA registration of two SDP attributes. 5786 The sections describing how to register an item uses some of the 5787 requirements level described in RFC 2434 [19], namely "First Come, 5788 First Served", "Specification Required", and "Standards Action". 5790 A registration request to IANA MUST contain the following 5791 information: 5793 o A name of the item to register according to the rules 5794 specified by the intended registry. 5796 o Indication of who has change control over the feature (for 5797 example, IETF, ISO, ITU-T, other international standardization 5798 bodies, a consortium, a particular company or group of 5799 companies, or an individual); 5801 o A reference to a further description, if available, for 5802 example (in order of preference) an RFC, a published standard, 5803 a published paper, a patent filing, a technical report, 5804 documented source code or a computer manual; 5806 o For proprietary features, contact information (postal and 5807 email address); 5809 21.1 Feature-tags 5811 21.1.1 Description 5813 When a client and server try to determine what part and functionality 5814 of the RTSP specification and any future extensions that its counter 5815 part implements there is need for a namespace. This registry 5816 contains named entries representing certain functionality. 5818 The usage of feature-tags is explained in section 10 and 11.1. 5820 21.1.2 Registering New Feature-tags with IANA 5822 The registering of feature-tags is done on a first come, first served 5823 basis. 5825 The name of the feature MUST follow these rules: The name may be of 5826 any length, but SHOULD be no more than twenty characters long. The 5827 name MUST NOT contain any spaces, or control characters. The 5828 registration SHALL indicate if the feature tag applies to clients, 5829 servers, or proxies only or any combinations of these. Any 5830 proprietary feature SHALL have as the first part of the name a vendor 5831 tag, which identifies the organization. 5833 21.1.3 Registered entries 5835 The following feature-tags are in this specification defined and 5836 hereby registered. The change control belongs to the Authors and the 5837 IETF MMUSIC WG. 5839 play.basic: The minimal implementation for playback operations 5840 according to section D. Applies for both clients, servers 5841 and proxies. 5843 play.scale: Support of scale operations for media playback. 5844 Applies only for servers. 5846 play.speed: Support of the speed functionality for playback. 5847 Applies only for servers 5849 21.2 RTSP Methods 5851 21.2.1 Description 5853 What a method is, is described in section 11. Extending the protocol 5854 with new methods allow for totally new functionality. 5856 21.2.2 Registering New Methods with IANA 5858 A new method MUST be registered through an IETF standard track 5859 document. The reason is that new methods may radically change the 5860 protocols behavior and purpose. 5862 A specification for a new RTSP method MUST consist of the following 5863 items: 5865 o A method name which follows the ABNF rules for methods. 5867 o A clear specification on what action and response a request 5868 with the method will result in. Which directions the method is 5869 used, C -> S or S -> C or both. How the use of headers, if 5870 any, modifies the behavior and effect of the method. 5872 o A list or table specifying which of the registered headers 5873 that are allowed to use with the method in request or/and 5874 response. 5876 o Describe how the method relates to network proxies. 5878 21.2.3 Registered Entries 5880 This specification, RFCXXXX, registers 9 methods: DESCRIBE, 5881 GET_PARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SET_PARAMETER, 5882 and TEARDOWN. 5884 21.3 RTSP Status Codes 5886 21.3.1 Description 5888 A status code is the three digit numbers used to convey information 5889 in RTSP response messages, see 7. The number space is limited and 5890 care should be taken not to fill the space. 5892 21.3.2 Registering New Status Codes with IANA 5894 A new status code can only be registered by an IETF standards track 5895 document. A specification for a new status code MUST specify the 5896 following: 5898 o The requested number. 5900 o A description what the status code means and the expected 5901 behavior of the sender and receiver of the code. 5903 21.3.3 Registered Entries 5905 RFCXXX, registers the numbered status code defined in the ABNF entry 5906 "Status-Code" except "extension-code" in section 19.2.2. 5908 21.4 RTSP Headers 5910 21.4.1 Description 5912 By specifying new headers a method(s) can be enhanced in many 5913 different ways. An unknown header will be ignored by the receiving 5914 entity. If the new header is vital for a certain functionality, a 5915 feature-tag for the functionality can be created and demanded to be 5916 used by the counter-part with the inclusion of a Require header 5917 carrying the feature-tag. 5919 21.4.2 Registering New Headers with IANA 5921 A public available specification is required to register a header. 5922 The specification SHOULD be a standards document, preferable an IETF 5923 RFC. 5925 The specification MUST contain the following information: 5927 o The name of the header. 5929 o An ABNF specification of the header syntax. 5931 o A list or table specifying when the header may be used, 5932 encompassing all methods, their request or response, the 5933 direction (C -> S or S -> C). 5935 o How the header is to be handled by proxies. 5937 o A description of the purpose of the header. 5939 21.4.3 Registered entries 5941 All headers specified in section 14 in RFCXXXX are to be registered. 5943 Furthermore the following RTSP headers defined in other 5944 specifications are registered: 5946 o x-wap-profile defined in [36]. 5948 o x-wap-profile-diff defined in [36]. 5950 o x-wap-profile-warning defined in [36]. 5952 o x-predecbufsize defined in [36]. 5954 o x-initpredecbufperiod defined in [36]. 5956 o x-initpostdecbufperiod defined in [36]. 5958 o 3gpp-videopostdecbufsize defined in [36]. 5960 o 3GPP-Link-Char defined in [36]. 5962 o 3GPP-Adaptation defined in [36]. 5964 o 3GPP-QoE-Metrics defined in [36]. 5966 o 3GPP-QoE-Feedback defined in [36]. 5968 The use of "X-" is NOT RECOMMENDED but the above headers in the 5969 register list was defined prior to the clarification. 5971 21.5 Transport Header registries 5973 The transport header contains a number of parameters which have 5974 possibilities for future extensions. Therefore registries for these 5975 needs to be defined. 5977 21.5.1 Transport Protocols 5979 A registry for the parameter transport-protocol SHALL be defined with 5980 the following rules: 5982 o Registering require an public available standards 5983 specification. 5985 o A contact person or organization with address and email. 5987 o A value definition that are following the ABNF token 5988 definition. 5990 o A describing text that explains how the registered value are 5991 used in RTSP. 5993 This specification registers 1 value: 5995 o Use of the RTP [16] protocol for media transport. The usage 5996 is explained in RFC XXXX, appendix B.1. 5998 21.5.2 Profile 6000 A registry for the parameter profile SHALL be defined with the 6001 following rules: 6003 o Registering requires public available standards specification. 6005 o A contact person or organization with address and email. 6007 o A value definition that are following the BNF token 6008 definition. 6010 o A definition of which Transport protocol(s) that this profile 6011 is valid for. 6013 o A describing text that explains how the registered value are 6014 used in RTSP. 6016 This specification registers 3 value: 6018 o The "RTP profile for audio and video conferences with minimal 6019 control" [2] MUST only be used when the transport 6020 specification's transport-protocol is "RTP". 6022 o The "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" 6023 [20] MUST only be used when the transport specification's 6024 transport-protocol is "RTP" 6026 o The "The Secure Real-time Transport Protocol (SRTP)" [21] MUST 6027 only be used when the transport specification's transport- 6028 protocol is "RTP". 6030 21.5.3 Lower Transport 6032 A registry for the parameter lower-transport SHALL be defined with 6033 the following rules: 6035 o Registering requires public available standards specification. 6037 o A contact person or organization with address and email. 6039 o A value definition that are following the BNF token 6040 definition. 6042 o A text describing how the registered value are used in RTSP. 6044 This specification registers 2 values: 6046 UDP: Indicates the use of the "User datagram protocol" [9] for 6047 media transport. 6049 TCP: Indicates the use Transmission control protocol [10] for 6050 media transport. 6052 21.5.4 Transport modes 6054 A registry for the transport parameter mode SHALL be defined with the 6055 following rules: 6057 o Registering requires an IETF standard tracks document. 6059 o A contact person or organization with address and email. 6061 o A value definition that are following the ABNF token 6062 definition. 6064 o A describing text that explains how the registered value are 6065 used in RTSP. 6067 This specification registers 1 values: 6069 PLAY: See RFC XXXX. 6071 21.5.5 Transport Parameters 6073 A registry for parameters that may be included in the Transport 6074 header SHALL be defined with the following rules: 6076 o Registering required a Open Standards document 6078 o A value definition that are following the ABNF token 6079 definition. 6081 o A describing text that explains how the registered value are 6082 used in RTSP. 6084 This specification registers all the transport parameters defined in 6085 Section 14.45. 6087 21.6 Cache Directive Extensions 6089 There exist a number of cache directives which can be sent in the 6090 Cache-Control header. A registry for this cache directives SHALL be 6091 defined with the following rules: 6093 o Registering requires an IETF standard tracks document. 6095 o A registration is required to contain a contact person. 6097 o Name of the directive and a definition of the value, if any. 6099 o Specification if it is an request or response directive. 6101 o A describing text that explains how the cache directive is 6102 used for RTSP controlled media streams. 6104 This specification registers the following values: 6106 no-cache: 6108 public: 6110 private: 6112 no-transform: 6114 only-if-cached: 6116 max-stale: 6118 min-fresh: 6120 must-revalidate: 6122 proxy-revalidate: 6124 max-age: 6126 21.7 Accept-Credentials policies 6128 In section 18.3.1 three policies for how to handle certificates. 6129 Further policies may be defined and SHALL be registered with IANA 6130 using the following rules: 6132 o Registering requires an IETF standard tracks document. 6134 o A registration is required name a contact person. 6136 o Name of the policy. 6138 o A describing text that explains how the policy works for 6139 handling the certificates. 6141 This specification registers the following values: 6143 Any 6145 Proxy 6147 User 6149 21.8 URI Schemes 6151 This specification defines two URI schemes ("rtsp" and "rtsps") and 6152 reserves a third one ("rtspu"). 6154 This will need to be done in accordance with RFC 2717. 6156 21.9 SDP attributes 6157 This specification defines two SDP [1] attributes that it is 6158 requested that IANA register. 6160 SDP Attribute ("att-field"): 6162 Attribute name: range 6163 Long form: Media Range Attribute 6164 Type of name: att-field 6165 Type of attribute: Media and session level 6166 Subject to charset: No 6167 Purpose: RFC XXXX 6168 Reference: RFC XXXX 6169 Values: See ABNF definition. 6171 Attribute name: control 6172 Long form: RTSP control URI 6173 Type of name: att-field 6174 Type of attribute: Media and session level 6175 Subject to charset: No 6176 Purpose: RFC XXXX 6177 Reference: RFC XXXX 6178 Values: Absolute or Relative URIs. 6180 Attribute name: etag 6181 Long form: Entity Tag 6182 Type of name: att-field 6183 Type of attribute: Media and session level 6184 Subject to charset: No 6185 Purpose: RFC XXXX 6186 Reference: RFC XXXX 6187 Values: See ABNF definition 6189 A RTSP Protocol State Machine 6191 The RTSP session state machine describes the behavior of the protocol 6192 from RTSP session initialization through RTSP session termination. 6194 The State machine is defined on a per session basis which is uniquely 6195 identified by the RTSP session identifier. The session may contain 6196 one or more media streams depending on state. If a single media 6197 stream is part of the session it is in non-aggregated control. If two 6198 or more is part of the session it is in aggregated control. 6200 The below state machine is a normative description of the protocols 6201 behavior. However, in case of ambiguity with the earlier parts of 6202 this specification, the description in the earlier parts SHALL take 6203 precedence. 6205 A.1 States 6207 The state machine contains three states, described below. For each 6208 state there exist a table which shows which requests and events that 6209 is allowed and if they will result in a state change. 6211 Init: Initial state no session exist. 6213 Ready: Session is ready to start playing. 6215 Play: Session is playing, i.e. sending media stream data in the 6216 direction S -> C. 6218 A.2 State variables 6220 This representation of the state machine needs more than its state to 6221 work. A small number of variables are also needed and is explained 6222 below. 6224 NRM: The number of media streams part of this session. 6226 RP: Resume point, the point in the presentation time line at 6227 which a request to continue will resume from. A time format 6228 for the variable is not mandated. 6230 A.3 Abbreviations 6232 To make the state tables more compact a number of abbreviations are 6233 used, which are explained below. 6235 IFI: IF Implemented. 6237 md: Media 6239 PP: Pause Point, the point in the presentation time line at 6240 which the presentation was paused. 6242 Prs: Presentation, the complete multimedia presentation. 6244 RedP: Redirect Point, the point in the presentation time line at 6245 which a REDIRECT was specified to occur. 6247 SES: Session. 6249 A.4 State Tables 6251 This section contains a table for each state. The table contains all 6252 the requests and events that this state is allowed to act on. The 6253 events which is method names are, unless noted, requests with the 6254 given method in the direction client to server (C -> S). In some 6255 cases there exist one or more requisite. The response column tells 6256 what type of response actions should be performed. Possible actions 6257 that is requested for an event includes: response codes, e.g. 200, 6258 headers that MUST be included in the response, setting of state 6259 variables, or setting of other session related parameters. The new 6260 state column tells which state the state machine changes to. 6262 The response to valid request meeting the requisites is normally a 6263 2xx (SUCCESS) unless other noted in the response column. The 6264 exceptions needs to be given a response according to the response 6265 column. If the request does not meet the requisite, is erroneous or 6266 some other type of error occur the appropriate response code MUST be 6267 sent. If the response code is a 4xx the session state is unchanged. A 6268 response code of 3rr will result in that the session is ended and its 6269 state is changed to Init. A response code of 304 results in no state 6270 change. However there exist restrictions to when a 3xx response may 6271 be used. A 5xx response SHALL not result in any change of the session 6272 state, except if the error is not possible to recover from. A 6273 unrecoverable error SHALL result the ending of the session. As it in 6274 the general case can't be determined if it was a unrecoverable error 6275 or not the client will be required to test. In the case that the next 6276 request after a 5xx is responded with 454 (Session Not Found) the 6277 client knows that the session has ended. 6279 The server will timeout the session after the period of time 6280 specified in the SETUP response, if no activity from the client is 6281 detected. Therefore there exist a timeout event for all states 6282 except Init. 6284 In the case that NRM=1 the presentation URI is equal to the media 6285 URI. For NRM>1 the presentation URI MUST be other than any of the 6286 medias that are part of the session. This applies to all states. 6288 The methods in Table 13 do not have any effect on the state machine 6289 or the state variables. However some methods do change other session 6290 related parameters, for example SET_PARAMETER which will set the 6291 parameter(s) specified in its body. Also all of these methods that 6292 allows Session header will also update the keep-alive timer for the 6293 session. 6295 Event Prerequisite Response 6296 ______________________________________________________________ 6297 DESCRIBE Needs REDIRECT 3rr, Redirect 6298 DESCRIBE 200, Session description 6299 OPTIONS Session ID 200, Reset session timeout timer 6300 OPTIONS 200 6301 SET_PARAMETER Valid parameter 200, change value of parameter 6302 GET_PARAMETER Valid parameter 200, return value of parameter 6304 Table 13: None state-machine changing events 6306 Action Requisite New State Response 6308 _____________________________________________________________ 6309 SETUP Ready NRM=1, RP=0.0 6310 SETUP Needs Redirect Init 3rr Redirect 6311 S -> C:REDIRECT No Session hdr Init Terminate all SES 6313 Table 14: State: Init 6315 The initial state of the state machine, see Table 14 can only be left 6316 by processing a correct SETUP request. As seen in the table the two 6317 state variables are also set by a correct request. This table also 6318 shows that a correct SETUP can in some cases be redirected to another 6319 URI and/or server by a 3rr response. 6321 In the Ready state, see Table 15, some of the actions are depending 6322 on the number of media streams (NRM) in the session, i.e. aggregated 6323 or non-aggregated control. A setup request in the ready state can 6324 either add one more media stream to the session or if the media 6325 stream (same URI) already is part of the session change the transport 6326 parameters. TEARDOWN is depending on both the Request-URI and the 6327 number of media stream within the session. If the Request-URI is the 6328 presentations URI the whole session is torn down. If a media URI is 6329 used in the TEARDOWN request and more than one media exist in the 6330 session, the session will remain and a session header MUST be 6331 returned in the response. If only a single media stream remains in 6332 the session when performing a TEARDOWN with a media URI the session 6333 is removed. The number of media streams remaining after tearing down 6334 a media stream determines the new state. 6336 Action Requisite New State Response 6337 _____________________________________________________________________ 6338 SETUP New URI Ready NRM+=1 6339 SETUP Setten up URI Ready Change transport param 6340 TEARDOWN Prs URI,NRM>1 Init No session hdr, NRM=0 6341 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 6342 TEARDOWN md URI,NRM>1 Ready Session hdr, NRM-=1 6343 PLAY Prs URI, No range Play Play from RP 6344 PLAY Prs URI, Range Play According to range 6345 PAUSE Prs URI Ready Return PP 6346 S -> C:REDIRECT Range hdr Ready Set RedP 6347 S -> C:REDIRECT no range hdr Init Session is removed 6348 Timeout Init 6349 RedP reached Init TEARDOWN of session 6351 Table 15: State: Ready 6353 Action Requisite New State Response 6355 ______________________________________________________________________ 6356 PAUSE PrsURI,No range Ready Set RP to present point 6357 PAUSE PrsURI,Range>now Play Set RP & PP to given p. 6358 PAUSE PrsURI,Range1 Init No session hdr 6368 TEARDOWN md URI,NRM=1 Init No Session hdr, NRM=0 6369 TEARDOWN md URI Play 455 6370 S -> C:REDIRECT Range hdr Play Set RedP 6371 S -> C:REDIRECT no range hdr Init Session is removed 6372 RedP reached Init TEARDOWN of session 6373 Timeout Init Stop Media playout 6375 Table 16: State: Play 6377 The Play state table, see Table 16, is the largest. The table 6378 contains an number of requests that has presentation URI as a 6379 prerequisite on the Request-URI, this is due to the exclusion of 6380 non-aggregated stream control in sessions with more than one media 6381 stream. 6383 To avoid inconsistencies between the client and server, automatic 6384 state transitions are avoided. This can be seen at for example "End 6385 of media" event when all media has finished playing, the session 6386 still remain in Play state. An explicit PAUSE request MUST be sent to 6387 change the state to Ready. It may appear that there exist two 6388 automatic transitions in "RedP reached" and "PP reached", however 6389 they are requested and acknowledge before they take place. The time 6390 at which the transition will happen is known by looking at the range 6391 header. If the client sends request close in time to these 6392 transitions it needs to be prepared for getting error message as the 6393 state may or may not have changed. 6395 B Media Transport Alternatives 6397 This section defines how certain combinations of protocols, profiles 6398 and lower transports are used. This includes the usage of the 6399 Transport header's source and destination address parameters 6400 "src_addr" and "dest_addr". 6402 B.1 RTP 6404 This section defines the interaction of RTSP with respect to the RTP 6405 protocol [16]. It also defines any necessary media transport 6406 signalling with regards to RTP. 6408 The available RTP profiles and lower layer transports are described 6409 below along with rules on signalling the available combinations. 6411 B.1.1 AVP 6413 The usage of the "RTP Profile for Audio and Video Conferences with 6414 Minimal Control" [2] when using RTP for media transport over 6415 different lower layer transport protocols is defined below in regards 6416 to RTSP. 6418 One such case is defined within this document, the use of embedded 6419 (interleaved) binary data as defined in section 12. The usage of 6420 this method is indicated by include the "interleaved" parameter. 6422 When using embedded binary data the "src_addr" and "dest_addr" SHALL 6423 NOT be used. This addressing and multiplexing is used as defined with 6424 use of channel numbers and the interleaved parameter. 6426 B.1.2 AVP/UDP 6428 This part describes sending of RTP [16] over lower transport layer 6429 UDP [9] according to the profile "RTP Profile for Audio and Video 6430 Conferences with Minimal Control" defined in RFC 3551 [2]. This 6431 profiles requires one or two uni- or bi-directional UDP flows per 6432 media stream. The first UDP flow is for RTP and the second is for 6433 RTCP. Embedding of RTP data with the RTSP messages, in accordance 6434 with section 12, SHOULD NOT be performed when RTSP messages are 6435 transported over unreliable transport protocols, like UDP [9]. 6437 The RTP/UDP and RTCP/UDP flows can be established using the Transport 6438 header's "src_addr", and "dest_addr" parameters. 6440 In RTSP PLAY mode, the transmission of RTP packets from client to 6441 server is unspecified. The behavior in regards to such RTP packets 6442 MAY be defined in future. 6444 The "src_addr" and "dest_addr" parameters are used in the following 6445 way for media playback, i.e. Mode=PLAY: 6447 o The "src_addr" and "dest_addr" parameters MUST contain either 6448 1 or 2 address specifications. 6450 o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST 6451 contain either: 6453 - both an address and a port number, or 6455 - a port number without an address 6457 o The first address and port pair given in either of the 6458 parameters applies to the RTP stream. The second address and 6459 port pair if present applies to the RTCP stream. 6461 o The RTP/UDP packets from the server to the client SHALL be 6462 sent to the address and port given by first address and port 6463 pair of the "dest_addr" parameter. 6465 o The RTCP/UDP packets from the server to the client SHALL be 6466 sent to the address and port given by the second address and 6467 port pair of the "dest_addr" parameter. If no second pair is 6468 given RTCP SHALL NOT be sent. 6470 o The RTCP/UDP packets from the client to the server SHALL be 6471 sent to the address and port given by the second address and 6472 port pair of the "src_addr" parameter. If no second pair is 6473 given RTCP SHALL NOT be sent. 6475 o The RTP/UDP packets from the client to the server SHALL be 6476 sent to the address and port given by the first address and 6477 port pair of the "src_addr" parameter. 6479 o RTP and RTCP Packets SHOULD be sent from the corresponding 6480 receiver port, i.e. RTCP packets from server should be sent 6481 from the "src_addr" parameters second address port pair. 6483 B.1.3 AVP/TCP 6485 Note that this combination is not yet defined using sperate TCP 6486 connections. However the use of embedded (interleaved) binary data 6487 transported on the RTSP connection is possible as specified in 6488 section 12. When using this declared combination of interleaved 6489 binary data the RTSP messages MUST be transported over TCP. 6491 A possible future for this profile would be to define the 6492 use of a combination of the two drafts "Connection-Oriented 6493 Media Transport in SDP" [37] and "Framing RTP and RTCP 6494 Packets over Connection-Oriented Transport" [38]. However 6495 as this work is not finished, this functionality is 6496 unspecified. 6498 B.1.4 AVPF 6500 The RTP profile "Extended RTP Profile for RTCP-based Feedback 6501 (RTP/AVPF)" [20] MAY be used as RTP profiles in session using RTP. 6502 All that is defined for AVP SHALL also apply for AVPF. 6504 The usage of AVPF is indicated by the media initialization protocol 6505 used. In the case of SDP it is indicated by media lines (m=) 6506 containing the profile RTP/AVPF. That SDP MAY also contain further 6507 AVPF related SDP attributes configuring the AVPF session regarding 6508 reporting interval and feedback messages that shall be used that 6509 SHALL be followed. 6511 B.1.5 SAVP 6513 The RTP profile "The Secure Real-time Transport Protocol (SRTP)" [21] 6514 is an RTP profile (SAVP) that MAY be used in RTSP sessions using RTP. 6515 All that is defined for AVP SHALL also apply for AVPF. 6517 The usage of SRTP requires that a security association is 6518 established. The protocol used are outside of the scope of RTSP, 6519 however a method must exist to enable the usage of the RTP profile 6520 SAVP. 6522 B.1.6 Handling NPT Jumps in the RTP Media Layer 6524 RTSP allows media clients to control selected, non-contiguous 6525 sections of media presentations, rendering those streams with an RTP 6526 media layer[16]. Such control allows jumps to be created in NPT 6527 timeline of the RTSP session. For example, jumps in NPT can be caused 6528 by multiple ranges in the range specifier of a PLAY request or 6529 through a "seek" opertaion on an RTSP session which involves a PLAY, 6530 PAUSE, PLAY scenario where a new NPT is set for the session. The 6531 media layer rendering the RTP stream should not be affected by jumps 6532 in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be 6533 continuous and monotonic across jumps of NPT. 6535 We cannot assume that the RTSP client can communicate with 6536 the RTP media agent, as the two may be independent 6537 processes. If the RTP timestamp shows the same gap as the 6538 NPT, the media agent will assume that there is a pause in 6539 the presentation. If the jump in NPT is large enough, the 6540 RTP timestamp may roll over and the media agent may believe 6541 later packets to be duplicates of packets just played out. 6543 As an example, assume a clock frequency of 8000 Hz, a packetization 6544 interval of 100 ms and an initial sequence number and timestamp of 6545 zero. 6547 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 6548 CSeq: 4 6549 Session: abcdefg 6550 Range: npt=10-15 6552 S->C: RTSP/2.0 200 OK 6553 CSeq: 4 6554 Session: abcdefg 6555 Range: npt=10-15 6556 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6557 ssrc=0D12F123:seq=0;rtptime=0 6559 The ensuing RTP data stream is depicted below: 6561 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6562 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6563 . . . 6564 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 6566 Immediately after the end of the play range, the client follows up 6567 with a request to PLAY from a new NPT. 6569 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 6570 CSeq: 5 6571 Session: abcdefg 6572 Range: npt=18-20; 6574 S->C: RTSP/2.0 200 OK 6575 CSeq: 5 6576 Session: abcdefg 6577 Range: npt=18-20 6578 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6579 ssrc=0D12F123:seq=50;rtptime=40100 6581 The ensuing RTP data stream is depicted below: 6583 S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 6584 S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 6585 . . . 6586 S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 6588 In this example, first, NPT 10 through 15 is played, then the client 6589 request the server to skip ahead and play NPT 18 through 20. The 6590 first segment is presented as RTP packets with sequence numbers 0 6591 through 49 and timestamp 0 through 39,200. The second segment 6592 consists of RTP packets with sequence number 50 through 69, with 6593 timestamps 40,100 through 55,200. While there is a gap in the NPT, 6594 there is no gap in the sequence number space of the RTP data stream. 6596 The RTP timestamp gap is present in the above example due to the time 6597 it takes to perform the second play request, in this case 12.5 ms 6598 (100/8000). To avoid this gap in playback due to the time it takes to 6599 perform RTSP requests, a PLAY request with multiple ranges needs to 6600 be specified. That would result in the following example: 6602 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 6603 CSeq: 4 6604 Session: abcdefg 6605 Range: npt=10-15;npt=18-20 6607 S->C: RTSP/2.0 200 OK 6608 CSeq: 4 6609 Session: abcdefg 6610 Range: npt=10-15 6611 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6612 ssrc=0D12F123:seq=0;rtptime=0 6614 The ensuing RTP data stream is depicted below: 6616 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6617 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6618 . . . 6619 S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s 6620 S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s 6621 S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s 6622 . . . 6623 S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s 6625 B.1.7 Handling RTP Timestamps after PAUSE 6627 During a PAUSE / PLAY interaction in an RTSP session, the duration of 6628 time for which the RTP transmission was halted MUST be reflected in 6629 the RTP timestamp of each RTP stream. The duration can be calculated 6630 for each RTP stream as the time elapsed from when the last RTP packet 6631 was sent before the PAUSE request was received and when the first RTP 6632 packet was sent after the subsequent PLAY request was received. The 6633 duration includes all latency incurred and processing time required 6634 to complete the request. 6636 The RTP RFC [16] states that: The RTP timestamp for each 6637 unit[packet] would be related to the wallclock time at 6638 which the unit becomes current on the virtual presentation 6639 timeline. 6641 In order to satisfy the requirements of [16], the RTP timestamp space 6642 needs to increase continuously with real time. While this is not 6643 optimal for stored media, it is required for RTP and RTCP to function 6644 as intended. Using a continuous RTP timestamp space allows the same 6645 timestamp model for both stored and live media and allows better 6646 opportunity to integrate both types of media under a single control. 6648 As an example, assume a clock frequency of 8000 Hz, a packetization 6649 interval of 100 ms and an initial sequence number and timestamp of 6650 zero. 6652 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 6653 CSeq: 4 6654 Session: abcdefg 6655 Range: npt=10-15; 6657 S->C: RTSP/2.0 200 OK 6658 CSeq: 4 6659 Session: abcdefg 6660 Range: npt=10-15 6661 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6662 ssrc=0D12F123:seq=0;rtptime=0 6664 The ensuing RTP data stream is depicted below: 6666 S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s 6667 S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s 6668 S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s 6669 S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s 6671 The client then sends a PAUSE request: 6673 C->S: PAUSE rtsp://xyz/fizzle RTSP/2.0 6674 CSeq: 5 6675 Session: abdcdefg 6677 S->C: RTSP/2.0 200 OK 6678 CSeq: 5 6679 Session: abcdefg 6680 Range: npt=10.4-15 6682 20 seconds elapse and then the client sends a PLAY request. In 6683 addition the server requires 15 ms to process the request: 6685 C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 6686 CSeq: 6 6687 Session: abcdefg 6689 S->C: RTSP/2.0 200 OK 6690 CSeq: 6 6691 Session: abcdefg 6692 Range: npt=10.4-15 6693 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" 6694 ssrc=0D12F123:seq=4;rtptime=164400 6696 The ensuing RTP data stream is depicted below: 6698 S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s 6699 S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s 6700 S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s 6702 First, NPT 10 through 10.3 is played, then a PAUSE is received by the 6703 server. After 20 seconds a PLAY is received by the server which take 6704 15ms to process. The duration of time for which the session was 6705 paused is reflected in the RTP timestamp of the RTP packets sent 6706 after this PLAY request. 6708 A client can use the RTSP range header and RTP-Info header to map NPT 6709 time of a presentation with the RTP timestamp. 6711 Note: In RFC 2326 [24], this matter was not clearly defined and was 6712 misunderstood commonly. However for RTSP 2.0 it is expected that this 6713 will be handled correctly and not exception handling will be 6714 required. 6716 B.1.8 RTSP / RTP Integration 6718 For certain datatypes, tight integration between the RTSP layer and 6719 the RTP layer will be necessary. This by no means precludes the above 6720 restrictions. Combined RTSP/RTP media clients should use the RTP-Info 6721 field to determine whether incoming RTP packets were sent before or 6722 after a seek or before or after a PAUSE. 6724 B.1.9 Scaling with RTP 6726 For scaling (see Section 14.39), RTP timestamps should correspond to 6727 the playback timing. For example, when playing video recorded at 30 6728 frames/second at a scale of two and speed (Section 14.40) of one, the 6729 server would drop every second frame to maintain and deliver video 6730 packets with the normal timestamp spacing of 3,000 per frame, but NPT 6731 would increase by 1/15 second for each video frame. 6733 Note: The above scaling puts requirements on the media 6734 codec or a media stream to support it. For example motion 6735 JPEG or other non-predictive video coding can easier handle 6736 the above example. 6738 B.1.10 Maintaining NPT synchronization with RTP timestamps 6740 The client can maintain a correct display of NPT by noting the RTP 6741 timestamp value of the first packet arriving after repositioning. 6742 The sequence parameter of the RTP-Info (Section 14.38) header 6743 provides the first sequence number of the next segment. 6745 B.1.11 Continuous Audio 6747 For continuous audio, the server SHOULD set the RTP marker bit at the 6748 beginning of serving a new PLAY request or at jumps in timeline. This 6749 allows the client to perform playout delay adaptation. 6751 B.1.12 Multiple Sources in an RTP Session 6753 Note that more than one SSRC MAY be sent in the media stream. If it 6754 happens all sources are expected to be rendered simultaneously. 6756 B.1.13 Usage of SSRCs and the RTCP BYE Message During an RTSP Session 6758 The RTCP BYE message indicates the end of use of a given SSRC. If all 6759 sources leave an RTP session, it can, in most cases, be assumed to 6760 have ended. Therefore, a client or server SHALL NOT send a RTCP BYE 6761 message until it has finished using a SSRC. A server SHOULD keep 6762 using a SSRC until the RTP session is terminated. Prolonging the use 6763 of a SSRC allows the established synchronization context associated 6764 with that SSRC to be used to synchronize subsequent PLAY requests 6765 even if the PLAY response is late. 6767 An SSRC collision with the SSRC that transmits media does also have 6768 consequences, as it will force the media sender to change its SSRC in 6769 accordance with the RTP specification [16]. This will result in a 6770 loss of synchronization context, and require any receiver to wait for 6771 RTCP sender reports for all media requiring synchronization before 6772 being able to play out synchronized. Due to these reasons a client 6773 joining a session should take care to not select the same SSRC as the 6774 server. Any SSRC signalled in the Transport header SHOULD be avoided. 6775 A client detecting a collision prior to sending any RTP or RTCP 6776 messages can also select a new SSRC. 6778 B.2 Future Additions 6780 It is the intention that any future protocol or profile regarding 6781 both for media delivery and lower transport should be easy to add to 6782 RTSP. This section provides the necessary steps that needs to be 6783 meet. 6785 The following things needs to be considered when adding a new 6786 protocol of profile for use with RTSP: 6788 o The protocol or profile needs to define a name tag 6789 representing it. This tag is required to be a ABNF "token" to 6790 be possible to use in the Transport header specification. 6792 o The useful combinations of protocol/profile/lower-layer needs 6793 to be defined and for each combination declare the necessary 6794 parameters to use in the Transport header. 6796 o For new media protocols the interaction with RTSP needs to be 6797 addressed. One important factor will be the media 6798 synchronization. 6800 See the IANA section (21) for information how to register new 6801 attributes. 6803 C Use of SDP for RTSP Session Descriptions 6805 The Session Description Protocol (SDP, RFC 2327 [1]) may be used to 6806 describe streams or presentations in RTSP. This description is 6807 typically returned in reply to a DESCRIBE request on an URI from a 6808 server to a client, or received via HTTP from a server to a client. 6810 This appendix describes how an SDP file determines the operation of 6811 an RTSP session. SDP as is provides no mechanism by which a client 6812 can distinguish, without human guidance, between several media 6813 streams to be rendered simultaneously and a set of alternatives 6814 (e.g., two audio streams spoken in different languages). However the 6815 SDP extension "Grouping of Media Lines in the Session Description 6816 Protocol (SDP)" [39] may provide such functionality depending on 6817 need. Also future grouping semantics may in the future be developed. 6819 C.1 Definitions 6821 The terms "session-level", "media-level" and other key/attribute 6822 names and values used in this appendix are to be used as defined in 6823 SDP (RFC 2327 [1]): 6825 C.1.1 Control URI 6826 The "a=control:" attribute is used to convey the control URI. This 6827 attribute is used both for the session and media descriptions. If 6828 used for individual media, it indicates the URI to be used for 6829 controlling that particular media stream. If found at the session 6830 level, the attribute indicates the URI for aggregate control 6831 (presentation URI). The session level URI SHALL be different from any 6832 media level URI. The presence of a session level control attribute 6833 SHALL be interpreted as support for aggregated control. The control 6834 attribute SHALL be present on media level unless the presentation 6835 only contains a single media stream, in which case the attribute MAY 6836 only be present on the session level. 6838 ABNF for the attribute is defined in section 19.3. 6840 Example: 6842 a=control:rtsp://example.com/foo 6844 This attribute MAY contain either relative or absolute URIs, 6845 following the rules and conventions set out in RFC 3986 [6]. 6846 Implementations SHALL look for a base URI in the following order: 6848 1. the RTSP Content-Base field; 6850 2. the RTSP Content-Location field; 6852 3. the RTSP Request-URI. 6854 If this attribute contains only an asterisk (*), then the URI SHALL 6855 be treated as if it were an empty embedded URI, and thus inherit the 6856 entire base URI. 6858 The URI handling for SDPs from container files need special 6859 consideration. For example lets assume that a container file has the 6860 URI: "rtsp://example.com/container.mp4". Lets further assume this URI 6861 is the base URI, and that there is a absolute media level URI: 6862 "rtsp://example.com/container.mp4/trackID=2". A relative media level 6863 URI that resolves in accordance with RFC 3986 [6] to the above given 6864 media URI is: "container.mp4/trackID=2". It is usually not desirable 6865 to need to include in or modify the SDP stored within the container 6866 file with the server local name of the container file. To avoid this, 6867 one can modify the base URI used to include a trailing slash, e.g. 6868 "rtsp://example.com/container.mp4/". In this case the relative URI 6869 for the media will only need to be: "trackID=2". However this will 6870 also mean that using "*" in the SDP will result in control URI 6871 including the trailing slash, i.e. 6873 "rtsp://example.com/container.mp4/". 6875 C.1.2 Media Streams 6877 The "m=" field is used to enumerate the streams. It is expected that 6878 all the specified streams will be rendered with appropriate 6879 synchronization. If the session is over multicast, the port number 6880 indicated SHOULD be used for reception. The client MAY try to 6881 override the destination port, through the Transport header. The 6882 servers MAY allow this, the response will indicate if allowed or not. 6883 If the session is unicast, the port number is the ones RECOMMENDED by 6884 the server to the client, about which receiver ports to use; the 6885 client MUST still include its receiver ports in its SETUP request. 6886 The client MAY ignore this recommendation. If the server has no 6887 preference, it SHOULD set the port number value to zero. 6889 The "m=" lines contain information about what transport protocol, 6890 profile, and possibly lower-layer is to be used for the media stream. 6891 The combination of transport, profile and lower layer, like 6892 RTP/AVP/UDP needs to be defined for how to be used with RTSP. The 6893 currently defined combinations are defined in section B, further 6894 combinations MAY be specified. 6896 Usage of grouping of media lines [39] to determine which media lines 6897 should or should not be included in a RTSP session is unspecified. 6899 Example: 6901 m=audio 0 RTP/AVP 31 6903 C.1.3 Payload Type(s) 6905 The payload type(s) are specified in the "m=" field. In case the 6906 payload type is a static payload type from RFC 3551 [2], no other 6907 information may be required. In case it is a dynamic payload type, 6908 the media attribute "rtpmap" is used to specify what the media is. 6909 The "encoding name" within the "rtpmap" attribute may be one of those 6910 specified in RFC 3551 (Sections 5 and 6), or an MIME type registered 6911 with IANA, or an experimental encoding as specified in SDP (RFC 2327 6912 [1]). Codec-specific parameters are not specified in this field, but 6913 rather in the "fmtp" attribute described below. 6915 C.1.4 Format-Specific Parameters 6917 Format-specific parameters are conveyed using the "fmtp" media 6918 attribute. The syntax of the "fmtp" attribute is specific to the 6919 encoding(s) that the attribute refers to. Note that some of the 6920 format specific parameters may be specified outside of the fmtp 6921 parameters, like for example the "ptime" attribute for most audio 6922 encodings. 6924 C.1.5 Range of Presentation 6926 The "a=range" attribute defines the total time range of the stored 6927 session or an individual media. Non-seekable live sessions can be 6928 indicated, while the length of live sessions can be deduced from the 6929 "t" and "r" SDP parameters. 6931 The attribute is both a session and a media level attribute. For 6932 presentations that contains media streams of the same durations, the 6933 range attribute SHOULD only be used at session-level. In case of 6934 different length the range attribute MUST be given at media level for 6935 all media, and SHOULD NOT be given at session level. If the attribute 6936 is present at both media level and session level the media level 6937 values SHALL be used. 6939 The unit is specified first, followed by the value range. The units 6940 and their values are as defined in Section 3.4, 3.5 and 3.6 and MAY 6941 be extended with further formats. Any open ended range (start-), i.e. 6942 without stop range, is of unspecified duration and SHALL be 6943 considered as non-seekable content unless this property is 6944 overridden. Multiple instances carrying different clock formats MAY 6945 be included at either session or media level. 6947 ABNF for the attribute is defined in section 19.3. 6949 Examples: 6951 a=range:npt=0-34.4368 6952 a=range:clock=19971113T2115-19971113T2203 6953 Non seekable stream of unknown duration: 6954 a=range:npt=0- 6956 C.1.6 Time of Availability 6958 The "t=" field MUST contain suitable values for the start and stop 6959 times for both aggregate and non-aggregate stream control. The 6960 server SHOULD indicate a stop time value for which it guarantees the 6961 description to be valid, and a start time that is equal to or before 6962 the time at which the DESCRIBE request was received. It MAY also 6963 indicate start and stop times of 0, meaning that the session is 6964 always available. 6966 For sessions that are of live type, i.e. specific start time, unknown 6967 stop time, likely unseekable, the "t=" and "r=" field SHOULD be used 6968 to indicate the start time of the event. The stop time SHOULD be 6969 given so that the live event will with high probability have ended at 6970 that time, while still not be unnecessary long into the future. 6972 C.1.7 Connection Information 6974 In SDP, the "c=" field contains the destination address for the media 6975 stream. For a media destination address that is a IPv6 one, the SDP 6976 extension defined in [22] needs to be used. For on-demand unicast 6977 streams and some multicast streams, the destination address MAY be 6978 specified by the client via the SETUP request, thus overriding any 6979 specified address. To identify streams without a fixed destination 6980 address, where the client is required to specify a destination 6981 address, the "c=" field SHOULD be set to a null value. For addresses 6982 of type "IP4", this value SHALL be "0.0.0.0", and for type "IP6", 6983 this value SHALL be "0:0:0:0:0:0:0:0", i.e. the unspecified address 6984 according to RFC 3513 [23]. 6986 C.1.8 Entity Tag 6988 The optional "a=etag" attribute identifies a version of the session 6989 description. It is opaque to the client. SETUP requests may include 6990 this identifier in the If-Match field (see section 14.25) to only 6991 allow session establishment if this attribute value still corresponds 6992 to that of the current description. The attribute value is opaque 6993 and may contain any character allowed within SDP attribute values. 6995 ABNF for the attribute is defined in section 19.3. 6997 Example: 6999 a=etag:158bb3e7c7fd62ce67f12b533f06b83a 7001 One could argue that the "o=" field provides identical 7002 functionality. However, it does so in a manner that would 7003 put constraints on servers that need to support multiple 7004 session description types other than SDP for the same piece 7005 of media content. 7007 C.2 Aggregate Control Not Available 7009 If a presentation does not support aggregate control no session level 7010 "a=control:" attribute is specified. For a SDP with multiple media 7011 sections specified, each section will have its own control URI 7012 specified via the "a=control:" attribute. 7014 Example: 7016 v=0 7017 o=- 2890844256 2890842807 IN IP4 204.34.34.32 7018 s=I came from a web page 7019 e=adm@example.com 7020 c=IN IP4 0.0.0.0 7021 t=0 0 7022 m=video 8002 RTP/AVP 31 7023 a=control:rtsp://audio.com/movie.aud 7024 m=audio 8004 RTP/AVP 3 7025 a=control:rtsp://video.com/movie.vid 7027 Note that the position of the control URI in the description implies 7028 that the client establishes separate RTSP control sessions to the 7029 servers audio.com and video.com 7031 It is recommended that an SDP file contains the complete media 7032 initialization information even if it is delivered to the media 7033 client through non-RTSP means. This is necessary as there is no 7034 mechanism to indicate that the client should request more detailed 7035 media stream information via DESCRIBE. 7037 C.3 Aggregate Control Available 7039 In this scenario, the server has multiple streams that can be 7040 controlled as a whole. In this case, there are both a media-level 7041 "a=control:" attributes, which are used to specify the stream URIs, 7042 and a session-level "a=control:" attribute which is used as the 7043 Request-URI for aggregate control. If the media-level URI is 7044 relative, it is resolved to absolute URIs according to Section C.1.1 7045 above. 7047 Example: 7049 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 7050 CSeq: 1 7052 M->C: RTSP/2.0 200 OK 7053 CSeq: 1 7054 Date: 23 Jan 1997 15:35:06 GMT 7055 Content-Type: application/sdp 7056 Content-Base: rtsp://example.com/movie/ 7057 Content-Length: 228 7059 v=0 7060 o=- 2890844256 2890842807 IN IP4 204.34.34.32 7061 s=I contain 7062 i= 7063 e=adm@example.com 7064 c=IN IP4 0.0.0.0 7065 t=0 0 7066 a=control:* 7067 m=video 8002 RTP/AVP 31 7068 a=control:trackID=1 7069 m=audio 8004 RTP/AVP 3 7070 a=control:trackID=2 7072 In this example, the client is required to establish a single RTSP 7073 session to the server, and uses the URIs 7074 rtsp://example.com/movie/trackID=1 and 7075 rtsp://example.com/movie/trackID=2 to set up the video and audio 7076 streams, respectively. The URI rtsp://example.com/movie/ , which is 7077 resolved from the "*", controls the whole presentation (movie). 7079 A client is not required to issues SETUP requests for all streams 7080 within an aggregate object. Servers should allow the client to ask 7081 for only a subset of the streams. 7083 C.4 RTSP external SDP delivery 7085 There are some considerations that needs to be made when the session 7086 description is delivered to client outside of RTSP, for example in 7087 HTTP or email. 7089 First of all the SDP needs to contain absolute URIs, relative will in 7090 most cases not work as the delivery will not correctly forward the 7091 base URI. And as SDP might be temporarily stored on file system 7092 before being loaded into an RTSP capable client, thus if possible to 7093 transport the base URI it still would need to be merged into the 7094 file. 7096 The writing of the SDP session availability information, i.e. "t=" 7097 and "r=", needs to be carefully considered. When the SDP is fetched 7098 by the DESCRIBE method it is with very high probability that the it 7099 is valid. However the same are much less certain for SDPs distributed 7100 using other methods. Therefore the publisher of the SDP should take 7101 care to follow the recommendations about availability in the SDP 7102 specification [1]. 7104 D Minimal RTSP implementation 7106 Note: This section is still under development! 7108 This section defines the minimal implementation requirements for any 7109 client and server. In addition the requirements for supporting the 7110 "play.basic" feature tag is defined here. 7112 D.1 Minimal Core Implementation 7114 The minimal core implementation is what is required to negotiate the 7115 usage of any other features. A minimal core implementation is not 7116 supporting any other feature set will be useless as the minimal 7117 implementation doesn't deliver any service. All feature sets SHALL 7118 include the minimal core. 7120 A minimal core implementation SHALL support the following 7121 functionalities: 7123 o Establishing a connection between RTSP agent using TCP. 7125 o Implement the reception and response to the OPTIONS method. 7127 o Implement the handling of all headers mandatory or conditional 7128 in regards to the usage of the OPTIONS method. See tables 9 7129 and 10. This include at least the capability to ignore 7130 unknown headers. 7132 o Implement the headers related to capability negotiation and 7133 exchange: 7135 - Require 7137 - Supported 7139 - Proxy-Require 7141 - Proxy-Supported 7143 - Unsupported 7145 D.2 The Basic Playback Feature Support 7147 This section defines what is required to be supported for clients, 7148 proxies and servers to be supporting the "play.basic" feature tag. 7150 D.2.1 Client 7152 A play.basic supporting client SHALL implement the following: 7154 o The RTSP methods as required by Table 7. 7156 o All the RTSP headers that are required required or conditional 7157 in requests or responses to method required to be supported 7158 according to Tables 9, 10, 11, and 12 and in addition the 7159 following headers: 7161 - Content-Base 7163 - Content-Encoding and at least the Identity method. 7165 - Content-Location 7167 - Location 7169 - Range 7171 - RTP-Info 7173 o Handling of all Status code categories and in addition the 7174 following specific status codes: 7176 o Media delivery using RTP/AVP over UDP. 7178 A play.basic client is RECOMMENDED to support the following: 7180 o RTSP basic and digest authentication: The 401 response, the 7181 WWW-Authenticate and Authorization headers, and both Basic and 7182 Digest authentication methods as defined by [8]. 7184 o Expires header 7186 o From header 7188 o Secure Transport as specified by section D.3. 7190 D.2.2 Server 7192 To be written! 7194 D.2.3 Proxy 7196 A play.basic supporting proxy SHALL implement the following: 7198 o Correct handling of the RTSP methods as required by Table 7. 7200 o The handling of all RTSP headers that are required to be 7201 handled by the server and clients supporting "play.basic" and 7202 in addition the following headers: 7204 - Cache-Control 7206 - Expires 7208 - Via 7210 D.3 Secure Transport 7212 Any Client, Proxy or Server supporting secure transport of RTSP 7213 messages and usage of the "rtsps" URI scheme SHALL implement; The 7214 Accept-Credentials and Connection-Credentials headers; TLS over TCP. 7216 D.4 Old Implementation Text 7218 The OLD Text follows from here on and is kept in this revision for 7219 comparison reasons: 7221 D.5 Client 7223 A client implementation MUST be able to do the following : 7225 o Generate the following requests: SETUP, TEARDOWN, PLAY. 7227 o Include the following headers in requests: CSeq, Connection, 7228 Session, Transport. 7230 o Parse and understand the following headers in responses: 7231 CSeq, Connection, Session, Transport, Content-Language, 7232 Content-Encoding, Content-Length, Content-Type. 7234 o Understand the class of each error code received and notify 7235 the end-user, if one is present, of error codes in classes 4xx 7236 and 5xx. The notification requirement may be relaxed if the 7237 end-user explicitly does not want it for one or all status 7238 codes. 7240 o Expect and respond to asynchronous requests from the server, 7241 such as REDIRECT. This does not necessarily mean that it 7242 should implement the REDIRECT method, merely that it MUST 7243 respond positively or negatively to any request received from 7244 the server. 7246 Though not required, the following are RECOMMENDED. 7248 o Implement RTP/AVP/UDP as a valid transport. 7250 o Inclusion of the User-Agent header. 7252 o Understand SDP session descriptions as defined in Appendix C 7254 o Accept media initialization formats (such as SDP) from 7255 standard input, command line, or other means appropriate to 7256 the operating environment to act as a "helper application" for 7257 other applications (such as web browsers). 7259 There may be RTSP applications different from those 7260 initially envisioned by the contributors to the RTSP 7261 specification for which the requirements above do not make 7262 sense. Therefore, the recommendations above serve only as 7263 guidelines instead of strict requirements. 7265 D.5.1 Basic Playback 7267 To support on-demand playback of media streams, the client MUST 7268 additionally be able to do the following: 7270 o generate the PAUSE request; 7272 o implement the REDIRECT method, and the Location header. 7274 D.5.2 Authentication-enabled 7276 In order to access media presentations from RTSP servers that require 7277 authentication, the client MUST additionally be able to do the 7278 following: 7280 o recognize the 401 (Unauthorized) status code; 7282 o parse and include the WWW-Authenticate header; 7284 o implement Basic Authentication and Digest Authentication. 7286 D.6 Server 7288 A minimal server implementation MUST be able to do the following: 7290 o Implement the following methods: SETUP, TEARDOWN, OPTIONS, 7291 SET_PARAMETER and PLAY. 7293 o Include the following headers in responses: Connection, 7294 Content-Length, Content-Type, Content-Language, Content- 7295 Encoding, Timestamp, Transport, Proxy-Supported, Public, and 7296 Via, and Unsupported. RTP-compliant implementations MUST also 7297 implement the RTP-Info field. 7299 o Parse and respond appropriately to the following headers in 7300 requests: Connection, Proxy-Require, Session, Transport, and 7301 Require. 7303 o Implement Date header if supporting DESCRIBE 7305 Though not required, the following are highly recommended at the time 7306 of publication for practical interoperability with initial 7307 implementations and/or to be a "good citizen". 7309 o Implement RTP/AVP/UDP as a valid transport. 7311 o Inclusion of the Server, Cache-Control, and Expires headers. 7313 o Implement the DESCRIBE method. 7315 o Generate SDP session descriptions as defined in Appendix C 7317 There may be RTSP applications different from those 7318 initially envisioned by the contributors to the RTSP 7319 specification for which the requirements above do not make 7320 sense. Therefore, the recommendations above serve only as 7321 guidelines instead of strict requirements. 7323 D.6.1 Basic Playback 7325 To support on-demand playback of media streams, the server MUST 7326 additionally be able to do the following: 7328 o Recognize the Range header, and return an error if seeking is 7329 not supported. 7331 o Implement the PAUSE method. 7333 In addition, in order to support commonly-accepted user interface 7334 features, the following are highly recommended for on-demand media 7335 servers: 7337 o Include and parse the Range header, with NPT units. 7338 Implementation of SMPTE units is recommended. 7340 o Include the length of the media presentation in the media 7341 initialization information. 7343 o Include mappings from data-specific timestamps to NPT. When 7344 RTP is used, the rtptime portion of the RTP-Info field may be 7345 used to map RTP timestamps to NPT. 7347 Client implementations may use the presence of length 7348 information to determine if the clip is seekable, and 7349 visably disable seeking features for clips for which the 7350 length information is unavailable. A common use of the 7351 presentation length is to implement a "slider bar" which 7352 serves as both a progress indicator and a timeline 7353 positioning tool. 7355 Mappings from RTP timestamps to NPT are necessary to ensure correct 7356 positioning of the slider bar. 7358 D.6.2 Authentication-enabled 7360 In order to correctly handle client authentication, the server MUST 7361 additionally be able to do the following: 7363 o Generate the 401 (Unauthorized) status code when 7364 authentication is required for the resource. 7366 o Parse and include the WWW-Authenticate header 7368 o Implement Basic Authentication and Digest Authentication 7370 E Requirements for Unreliable Transport of RTSP messages 7372 This section provides any one intending to define how to transport of 7373 RTSP messages over a unreliable transport protocol with some 7374 information learned by the attempt in RFC 2326 [24]. RFC 2326 define 7375 both an URI scheme and some basic functionality for transport of RTSP 7376 messages over UDP, however it was not sufficient for reliable usage 7377 and successful interoperability. 7379 The RTSP scheme defined for unreliable transport of RTSP messages was 7380 "rtspu". It has been reserved by this specification as at least one 7381 commercial implementation exist, thus avoiding any collisions in the 7382 name space. 7384 The following considerations should exist for operation of RTSP over 7385 an unreliable transport protocol: 7387 o Request shall be acknowledged by the receiver. If there is no 7388 acknowledgement, the sender may resend the same message after 7389 a timeout of one round-trip time (RTT). Any retransmissions 7390 due to lack of acknowledgement must carry the same sequence 7391 number as the original request. 7393 o The round-trip time can be estimated as in TCP (RFC 1123) 7394 [40], with an initial round-trip value of 500 ms. An 7395 implementation may cache the last RTT measurement as the 7396 initial value for future connections. 7398 o If RTSP is used over a small-RTT LAN, standard procedures for 7399 optimizing initial TCP round trip estimates, such as those 7400 used in T/TCP (RFC 1644) [41], can be beneficial. 7402 o The Timestamp header (Section 14.44) is used to avoid the 7403 retransmission ambiguity problem [42] and obviates the need 7404 for Karn's algorithm. 7406 o The registered default port for RTSP over UDP for the server 7407 is 554. 7409 o RTSP messages can be carried over any lower-layer transport 7410 protocol that is 8-bit clean. 7412 o RTSP messages are vulnerable to bit errors and should not be 7413 subjected to them. 7415 o Source authentication, or at least validation that RTSP 7416 messages comes from the same entity becomes extremely 7417 important, as session hijacking may be substantially easier 7418 for RTSP message transport using an unreliable protocol like 7419 UDP than for TCP. 7421 There exist two RTSP headers thats primarily are intended for being 7422 used by the unreliable handling of RTSP messages and which will be 7423 maintained: 7425 CSeq See section 14.19 7427 Timestamp See section 14.44 7429 F Backwards Compatibility Considerations 7431 This section contains notes on issues about backwards compatibility 7432 with clients or servers being implemented according to RFC 2326 [24]. 7434 A server implementing RTSP/2.0 MUST include a RTSP-Version of 7435 RTSP/2.0 in all responses to requests containing RTSP-Version 7436 RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond 7437 with a RTSP/1.0 response if it chooses to support RFC 2326. If the 7438 server chooses not to support RFC 2326, it SHOULD respond with a 505 7439 (RTSP Version not supported) status code. A server MUST NOT respond 7440 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 7441 response. 7443 Clients implementing RTSP/2.0 SHOULD use an OPTIONS request with a 7444 RTSP-Version of 2.0 to determine whether a server supports RTSP/2.0. 7445 If the server responds with either a RTSP-Version of 1.0 or a status 7446 code of 505 (RTSP Version not supported), the client MAY use RTSP/1.0 7447 requests if it chooses to support RFC 2326. 7449 F.1 Play Request in Play mode 7451 The behavior in the server when a Play is received in Play mode has 7452 changed (Section 11.4). In RFC 2326, the new PLAY request would be 7453 queued until the current Play completed. Any new PLAY request now 7454 take effect immediately replacing the previous request. 7456 F.2 Using Persistent Connections 7458 Some server implementations of RFC 2326 maintain a one-to-one 7459 relationship between a connection and an RTSP session. Such 7460 implementations require clients to use a persistent connection to 7461 communicate with the server and when a client closes its connection, 7462 the server may remove the RTSP session. This is worth noting if a 7463 RTSP 2.0 client connects to a 1.0 server. 7465 G Open Issues 7467 This section contains a list of open issues that still needs to be 7468 resolved. However also any open issues in the bug tracker at 7469 http://rtspspec.sourceforge.net should also be considered. 7471 1. The minimal implementation chapter is still under 7472 refinement. All shall, must and shoulds needs to be 7473 included in the minimal and relevant feature tags. 7474 Feature-tags for these needs to be defined. Further 7475 feature-tags needs to be discussed. 7477 H Changes 7479 Compared to RTSP 1.0 (RFC 2326), the below changes has been made when 7480 defining RTSP 2.0. Note that this list does not reflect minor changes 7481 in wording or correction of typographical errors. 7483 o The Transport header has been changed in the following way: 7485 - The ABNF has been changed to define that extensions are 7486 possible, and that unknown extension parameters are to be 7487 ignored. 7489 - To prevent backwards compatibility issues, any extension or 7490 new parameter requires the usage of a feature tag combined 7491 with the Require header. 7493 - Syntax unclarities with the Mode parameter has been 7494 resolved. 7496 - Syntax error with ";" for multicast and unicast has been 7497 resolved. 7499 - Two new addressing parameters has been defined, src_addr and 7500 dest_addr. These replaces the parameters "port", 7501 "client_port", "server_port", "destination", "source". 7503 - Support for IPv6 explicit addresses in all address fields 7504 has been included. 7506 - To handle URI definitions that contain ";" or "," a quoted 7507 URI format has been introduced and is required. 7509 - Defined IANA registries for the transport headers 7510 parameters, transport-protocol, profile, lower-transport, 7511 and mode. 7513 - The transport headers interleaved parameter's text was made 7514 more strict and use formal requirements levels. However no 7515 change on how it is used was made. 7517 - It has been clarified that the client can't request of the 7518 server to use a certain RTP SSRC, using a request with the 7519 transport parameter SSRC. 7521 - Syntax definition for SSRC has been clarified to require 8*8 7522 HEX. It has also been extend to allow multiple values for 7523 clients supporting this version. 7525 - Clarified the text on the transport headers "dest_addr" 7526 parameters regarding what security precautions the server is 7527 required to perform. 7529 - The embedded (interleaved) binary data and its transport 7530 parameter was clarified to being symmetric and that it is 7531 the server that sets the channel numbers. 7533 o The Range formats has been changed in the following way: 7535 - The NPT format has been given a initial NPT identifier that 7536 must now be used. 7538 - All formats now support initial open ended formats of type 7539 "npt=-10". 7541 o RTSP message handling has been changed in the following way: 7543 - RTSP messages now uses URIs rather then URLs. 7545 - It has been clarified that a 4xx message due to missing CSeq 7546 header shall be returned without a CSeq header. 7548 - Rules for how to handle timing out RTSP messages has been 7549 added. 7551 o The HTTP references has been updated to RFC 2616 and RFC 2617. 7552 This has resulted in that the Public, and the Content-Base 7553 header needed to be defined in the RTSP specification. Known 7554 effects on RTSP due to HTTP clarifications: 7556 - Content-Encoding header can include encoding of type 7557 "identity". 7559 o The state machine section has completely been rewritten. It 7560 includes now more details and are also more clear about the 7561 model used. 7563 o A IANA section has been included with contains a number of 7564 registries and their rules. This will allow us to use IANA to 7565 keep track of all RTSP extensions. 7567 o Than transport of RTSP messages has seen the following 7568 changes: 7570 - The use of UDP for RTSP message transport has been 7571 deprecated due to missing interest and to broken 7572 specification. 7574 - The rules for how TCP connections is to be handled has been 7575 clarified. Now it is made clear that servers should not 7576 close the TCP connection unless they have been unused for 7577 significant time. 7579 - Strong recommendations why server and clients should use 7580 persistent connections has also been added. 7582 - There is now a requirement on the servers to handle non- 7583 persistent connections as this provides fault tolerance. 7585 - Added wording on the usage of Connection:Close for RTSP. 7587 - specified usage of TLS for RTSP messages, including a scheme 7588 to approve a proxies TLS connection to the next hop. 7590 o The following header related changes have been made: 7592 - Accept-Ranges response header is added. This header 7593 clarifies which range formats that can be used for a 7594 resource. 7596 - Clarified that Range header allows multiple ranges to allow 7597 for creating editing list. 7599 - Fixed the missing definitions for the Cache-Control header. 7600 Also added to the syntax definition the missing delta- 7601 seconds for max-stale and min-fresh parameters. 7603 - Put requirement on CSeq header that the value is increased 7604 by one for each new RTSP request. A Recommendation to start 7605 at 1 has also been added. 7607 - Added requirement that the Date header must be used for all 7608 messages with entity. Also the Server should always include 7609 it. 7611 - Removed possibility of using Range header with Scale header 7612 to indicate when it is to be activated, since it can't work 7613 as defined. Also added rule that lack of Scale header in 7614 response indicates lack of support for the header. Feature- 7615 tags for scaled playback has been defined. 7617 - The Speed header must now be responded to indicate support 7618 and the actual speed going to be used. A feature-tag is 7619 defined. Notes on congestion control was also added. 7621 - The Supported header was borrowed from SIP to help with the 7622 feature negotiation in RTSP. 7624 - Clarified that the Timestamp header can be used to resolve 7625 retransmission ambiguities. 7627 - The Session header text has been expanded with a explanation 7628 on keep alive and which methods to use. SET_PARAMETER is now 7629 recommended to use if only keep-alive within RTSP is 7630 desired. 7632 - It has been clarified how the Range header formats is used 7633 to indicate pause points. 7635 - Clarified that RTP-Info URIs that are relative, uses the 7636 Request-URI as base URI. Also clarified that used URI must 7637 be that one that was used in the SETUP request. They are now 7638 also required to be quoted. The header also expresses the 7639 SSRC for the provided RTP timestamp and sequence number 7640 values. 7642 - Added text that requires the Range to always be present in 7643 PLAY responses. Clarified what should be sent in case of 7644 live streams. 7646 - The headers table has been updated using a structured 7647 borrowed from SIP. This table carries much more information 7648 and should provide a good overview of the available headers. 7650 - It has been is clarified that any message with a message 7651 body is required to have a Content-Length header. This was 7652 the case in RFC 2326 but could be misinterpreted. 7654 - To resolve functionality around ETag. The ETag and If-None- 7655 Match header has been added from HTTP with necessary 7656 clarification in regards to RTSP operation. 7658 - Imported the Public header from HTTP RFC 2068 [18] since it 7659 has been removed from HTTP due to lack of use. Public is 7660 used quite frequently in RTSP. 7662 - Clarified rules for populating the Public header so that it 7663 is an intersection of the capabilities of all the RTSP 7664 agents in a chain. 7666 o The Protocol Syntax has been changed in the following way: 7668 - All BNF definitions are updated according to the rules 7669 defined in RFC 4234 [4] and has been gathered in a separate 7670 section 19. 7672 - The BNF for the User-Agent and Server headers has been 7673 corrected so now only the description is in the HTTP 7674 specification. 7676 - The definition in the introduction of the RTSP session has 7677 been changed. 7679 - The protocol has been made fully IPv6 capable. Certain of 7680 the functionality, like using explicit IPv6 addresses in 7681 fields requires that the protocol support this updated 7682 specification. 7684 - Added a fragment part to the RTSP URI. This seem to be 7685 indicated by the note below the definition however it was 7686 not part of the BNF. 7688 - The CHAR rule has been changed to exclude NULL. 7690 o The Status codes has been changed in the following way: 7692 - The use of status code 303 "See Other" has been deprecated 7693 as it does not make sense to use in RTSP. 7695 - When sending response 451 and 458 the response body should 7696 contain the offending parameters. 7698 - Clarification on when a 3rr redirect status code can be 7699 received has been added. This includes receiving 3rr as a 7700 result of request within a established session. This 7701 provides clarification to a previous unspecified behavior. 7703 - Removed the 250 (Low On Storage Space) status code as it 7704 only is relevant to recording which is deprecated. 7706 o The following functionality has been deprecated from the 7707 protocol: 7709 - The use of Queued Play. 7711 - The use of PLAY method for keep-alive in play state. 7713 - The RECORD and ANNOUNCE methods and all related 7714 functionality. Some of the syntax has been removed. 7716 - The possibility to use timed execution of methods with the 7717 time parameter in the Range header. 7719 - The description on how rtspu works is not part of the core 7720 specification and will require external description. Only 7721 that it exist is defined here and some requirements for the 7722 the transport is provided. 7724 o The following changes has been made in relation to methods: 7726 - The OPTIONS method has been clarified with regards to the 7727 use of the Public and Allow headers. 7729 - The RECORD and ANNOUNCE methods are removed as they are 7730 lacking implementation and not considered necessary in the 7731 core specification. Any work on these methods should be done 7732 as a extension document to RTSP. 7734 - Added text clarifying the usage of SET_PARAMETER for keep- 7735 alive and usage without any body. 7737 o Wrote a new section about how to setup different media 7738 transport alternatives and their profiles, and lower layer 7739 protocols. This resulted that the appendix on RTP interaction 7740 was moved there instead in the part describing RTP. The 7741 section also includes guidelines what to think of when writing 7742 usage guidelines for new protocols and profiles. 7744 o Added a new section describing the available mechanisms to 7745 determine if functionality is supported, called "Capability 7746 Handling". Renamed option-tags to feature-tags. 7748 o Added a contributors section with people who has contribute 7749 actual text to the specification. 7751 o Added a section Use Cases that describes the major use cases 7752 for RTSP. 7754 o Clarified the usage of a=range and how to indicate live 7755 content that are not seekable with this header. 7757 o Text specifying the special behavior of PLAY for live content. 7759 H.1 Changes needing to be updated 7761 o The minimal implementation specification has been changed: 7763 - Required Timestamp, Via, and Unsupported headers for a minimal 7764 server implementation. 7766 - Recommended that Cache-Control, Expires and Date headers be 7767 supported by server implementations. 7769 I Author Addresses 7770 Henning Schulzrinne 7771 Dept. of Computer Science 7772 Columbia University 7773 1214 Amsterdam Avenue 7774 New York, NY 10027 7775 USA 7776 electronic mail: schulzrinne@cs.columbia.edu 7778 Anup Rao 7779 Cisco 7780 USA 7781 electronic mail: anrao@cisco.com 7783 Robert Lanphier 7784 RealNetworks 7785 P.O. Box 91123 7786 Seattle, WA 98111-9223 7787 USA 7788 electronic mail: robla@real.com 7790 Magnus Westerlund 7791 Ericsson AB, EAB/TVA/A 7792 Torshamsgatan 23 7793 SE-164 80 STOCKHOLM 7794 SWEDEN 7795 electronic mail: magnus.westerlund@ericsson.com 7797 Aravind Narasimhan 7798 Overture Computing Corp., 7799 East Windsor, NJ 08520 7800 USA 7801 electronic mail: aravind.narasimhan@gmail.com 7803 J Contributors 7805 The following people have made written contributions that were 7806 included in the specification: 7808 o Tom Marshall contributed text on the usage of 3rr status 7809 codes. 7811 o Thomas Zheng contributed text on the usage of the Range in 7812 PLAY responses. 7814 o Sean Sheedy contributed text on the timeout behavior of RTSP 7815 messages and connections, and the 463 status code. 7817 o Fredrik Lindholm contributed text about the RTSP security 7818 framework. 7820 The following people have provided detailed comments on updated 7821 versions of this specification: 7823 o Stephan Wenger 7825 K Acknowledgements 7827 This draft is based on the functionality of the original RTSP draft 7828 submitted in October 1996. It also borrows format and descriptions 7829 from HTTP/1.1. 7831 This document has benefited greatly from the comments of all those 7832 participating in the MMUSIC-WG. In addition to those already 7833 mentioned, the following individuals have contributed to this 7834 specification: 7836 Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, 7837 Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, 7838 Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. 7839 Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, 7840 John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, 7841 Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas 7842 Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal 7843 Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov, 7844 Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, 7845 Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen 7846 Chesire, David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, 7847 Jae-Hwan Kim and Mela Martti. 7849 L Normative References 7851 [1] M. Handley and V. Jacobson, "SDP: Session Description Protocol." 7852 RFC 2327 (Proposed Standard), Apr. 1998. Updated by RFC 3266. 7854 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 7855 Conferences with Minimal Control." RFC 3551 (Standard), July 2003. 7857 [3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 7858 Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." 7859 RFC 2616 (Draft Standard), June 1999. Updated by RFC 2817. 7861 [4] D. Crocker and P. Overell, "Augmented BNF for Syntax 7862 Specifications: ABNF." RFC 4234 (Draft Standard), Oct. 2005. 7864 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 7865 Levels." RFC 2119 (Best Current Practice), Mar. 1997. 7867 [6] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource 7868 Identifier (URI): Generic Syntax." RFC 3986 (Standard), Jan. 2005. 7870 [7] T. Dierks and C. Allen, "The TLS Protocol Version 1.0." RFC 2246 7871 (Proposed Standard), Jan. 1999. Updated by RFC 3546. 7873 [8] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 7874 A. Luotonen, and L. Stewart, "HTTP Authentication: Basic and Digest 7875 Access Authentication." RFC 2617 (Draft Standard), June 1999. 7877 [9] J. Postel, "User Datagram Protocol." RFC 768 (Standard), Aug. 7878 1980. 7880 [10] J. Postel, "Transmission Control Protocol." RFC 793 (Standard), 7881 Sept. 1981. Updated by RFC 3168. 7883 [11] R. Elz, "A Compact Representation of IPv6 Addresses." RFC 1924 7884 (Informational), Apr. 1996. 7886 [12] R. Hinden, B. Carpenter, and L. Masinter, "Format for Literal 7887 IPv6 Addresses in URL's." RFC 2732 (Proposed Standard), Dec. 1999. 7888 Obsoleted by RFC 3986. 7890 [13] F. Yergeau, "UTF-8, a transformation format of ISO 10646." RFC 7891 2279 (Draft Standard), Jan. 1998. Obsoleted by RFC 3629. 7893 [14] NIST, "Fips pub 180-1:secure hash standard," tech. rep., 7894 National Institute of Standards and Technology, Apr. 1995. 7896 [15] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 7897 Public Key Infrastructure Certificate and Certificate Revocation List 7898 (CRL) Profile." RFC 3280 (Proposed Standard), Apr. 2002. 7900 [16] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 7901 A Transport Protocol for Real-Time Applications." RFC 3550 7902 (Standard), July 2003. 7904 [17] E. Rescorla, "HTTP Over TLS." RFC 2818 (Informational), May 7905 2000. 7907 [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners- 7908 Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068 (Proposed 7909 Standard), Jan. 1997. Obsoleted by RFC 2616. 7911 [19] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 7912 Considerations Section in RFCs." RFC 2434 (Best Current Practice), 7913 Oct. 1998. Updated by RFC 3692. 7915 [20] e. a. J. Ott, "Extended rtp profile for rtcp-based feedback 7916 (rtp/avpf)," internet draft, Internet Engineering Task Force, Aug. 7917 2004. Work in progress. 7919 [21] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, 7920 "The Secure Real-time Transport Protocol (SRTP)." RFC 3711 (Proposed 7921 Standard), Mar. 2004. 7923 [22] S. Olson, G. Camarillo, and A. B. Roach, "Support for IPv6 in 7924 Session Description Protocol (SDP)." RFC 3266 (Proposed Standard), 7925 June 2002. 7927 [23] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) 7928 Addressing Architecture." RFC 3513 (Proposed Standard), Apr. 2003. 7930 M Informative References 7932 [24] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming 7933 Protocol (RTSP)." RFC 2326 (Proposed Standard), Apr. 1998. 7935 [25] T. Z. M. Westerlund, "How to make real-time streaming protocol 7936 (rtsp) traverse network address translators (nat) and interact with 7937 firewalls.," internet draft, Internet Engineering Task Force, Feb. 7938 2004. Work in progress. 7940 [26] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 7941 "Internationalization of the Hypertext Markup Language." RFC 2070 7942 (Historic), Jan. 1997. Obsoleted by RFC 2854. 7944 [27] H. Schulzrinne, "A comprehensive multimedia control architecture 7945 for the Internet," in Proc. International Workshop on Network and 7946 Operating System Support for Digital Audio and Video (NOSSDAV), (St. 7947 Louis, Missouri), May 1997. 7949 [28] International Telecommunication Union, "Visual telephone systems 7950 and equipment for local area networks which provide a non-guaranteed 7951 quality of service," Recommendation H.323, Telecommunication 7952 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 7954 [29] P. McMahon, "GSS-API Authentication Method for SOCKS Version 5." 7955 RFC 1961 (Proposed Standard), June 1996. 7957 [30] J. Miller, P. Resnick, and D. Singer, "Rating services and 7958 rating systems (and their machine readable descriptions)," 7959 Recommendation REC-PICS-services-961031, W3C (World Wide Web 7960 Consortium), Boston, Massachusetts, Oct. 1996. 7962 [31] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label 7963 distribution label syntax and communication protocols," 7964 Recommendation REC-PICS-labels-961031, W3C (World Wide Web 7965 Consortium), Boston, Massachusetts, Oct. 1996. 7967 [32] D. Mills, "Network Time Protocol (Version 3) Specification, 7968 Implementation and Analysis." RFC 1305 (Draft Standard), Mar. 1992. 7970 [33] ISO/IEC, "Information technology -- generic coding of moving 7971 pictures and associated audio informaiton -- part 6: extension for 7972 digital storage media and control," Draft International Standard ISO 7973 13818-6, International Organization for Standardization ISO/IEC 7974 JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995. 7976 [34] ISO/IEC, "Data elements and interchange formats -- information 7977 interchange -- representation of dates and times," Published standard 7978 ISO 8601, International Organization for Standardization ISO/IEC, 7979 Geneva, Switzerland, Dec. 2000. 7981 [35] S. Josefsson, "The Base16, Base32, and Base64 Data Encodings." 7982 RFC 3548 (Informational), July 2003. 7984 [36] Third Generation Partnership Project (3GPP), "Transparent end- 7985 to-end packet-switched streaming service (pss); protocols and 7986 codecs," Technical Specification 26.234, Third Generation Partnership 7987 Project (3GPP), Dec. 2002. 7989 [37] D. Yon, "Connection-oriented media transport in sdp," internet 7990 draft, Internet Engineering Task Force, Mar. 2003. Work in progress. 7992 [38] J. Lazzaro, "Framing rtp and rtcp packets over connection- 7993 oriented transport," internet draft, Internet Engineering Task Force, 7994 Oct. 2003. Work in progress. 7996 [39] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, 7997 "Grouping of Media Lines in the Session Description Protocol (SDP)." 7998 RFC 3388 (Proposed Standard), Dec. 2002. 8000 [40] R. Braden, "Requirements for Internet Hosts - Application and 8001 Support." RFC 1123 (Standard), Oct. 1989. Updated by RFCs 1349, 8002 2181. 8004 [41] R. Braden, "T/TCP -- TCP Extensions for Transactions Functional 8005 Specification." RFC 1644 (Experimental), July 1994. 8007 [42] W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 8008 Reading, Massachusetts: Addison-Wesley, 1994. 8010 IPR Notice 8012 The IETF takes no position regarding the validity or scope of any 8013 Intellectual Property Rights or other rights that might be claimed to 8014 pertain to the implementation or use of the technology described in 8015 this document or the extent to which any license under such rights 8016 might or might not be available; nor does it represent that it has 8017 made any independent effort to identify any such rights. Information 8018 on the procedures with respect to rights in RFC documents can be 8019 found in BCP 78 and BCP 79. 8021 Copies of IPR disclosures made to the IETF Secretariat and any 8022 assurances of licenses to be made available, or the result of an 8023 attempt made to obtain a general license or permission for the use of 8024 such proprietary rights by implementers or users of this 8025 specification can be obtained from the IETF on-line IPR repository at 8026 http://www.ietf.org/ipr. 8028 The IETF invites any interested party to bring to its attention any 8029 copyrights, patents or patent applications, or other proprietary 8030 rights that may cover technology that may be required to implement 8031 this standard. Please address the information to the IETF at ietf- 8032 ipr@ietf.org. 8034 Full Copyright Statement 8036 Copyright (C) The Internet Society (2005). This document is subject 8037 to the rights, licenses and restrictions contained in BCP 78, and 8038 except as set forth therein, the authors retain all their rights. 8040 This document and the information contained herein are provided on an 8041 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 8042 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 8043 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 8044 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 8045 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 8046 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8048 Table of Contents 8050 1 Introduction ........................................ 9 8051 1.1 RTSP Specification Update ........................... 9 8052 1.2 Purpose ............................................. 9 8053 1.3 Notational Conventions .............................. 11 8054 1.4 Terminology ......................................... 12 8055 1.5 Protocol Properties ................................. 15 8056 1.6 Extending RTSP ...................................... 16 8057 1.7 Overall Operation ................................... 17 8058 1.8 RTSP States ......................................... 18 8059 1.9 Relationship with Other Protocols ................... 19 8060 2 RTSP Use Cases ...................................... 19 8061 2.1 On-demand Playback of Stored Content ................ 20 8062 2.2 Unicast distribution of Live Content ................ 21 8063 2.3 On-demand Playback using Multicast .................. 21 8064 2.4 Inviting a RTSP server into a conference ............ 22 8065 2.5 Live Content using Multicast ........................ 23 8066 3 Protocol Parameters ................................. 23 8067 3.1 RTSP Version ........................................ 23 8068 3.2 RTSP URI ............................................ 23 8069 3.3 Session Identifiers ................................. 25 8070 3.4 SMPTE Relative Timestamps ........................... 25 8071 3.5 Normal Play Time .................................... 26 8072 3.6 Absolute Time ....................................... 27 8073 3.7 Feature-tags ........................................ 27 8074 3.8 Entity Tags ......................................... 27 8075 4 RTSP Message ........................................ 28 8076 4.1 Message Types ....................................... 28 8077 4.2 Message Headers ..................................... 28 8078 4.3 Message Body ........................................ 28 8079 4.4 Message Length ...................................... 29 8080 5 General Header Fields ............................... 29 8081 6 Request ............................................. 30 8082 6.1 Request Line ........................................ 30 8083 6.2 Request Header Fields ............................... 31 8084 7 Response ............................................ 32 8085 7.1 Status-Line ......................................... 32 8086 7.1.1 Status Code and Reason Phrase ....................... 33 8087 7.1.2 Response Header Fields .............................. 34 8088 8 Entity .............................................. 34 8089 8.1 Entity Header Fields ................................ 34 8090 8.2 Entity Body ......................................... 34 8091 9 Connections ......................................... 35 8092 9.1 Reliability and Acknowledgements .................... 35 8093 9.2 Using Connections ................................... 38 8094 9.3 Closing Connections ................................. 39 8095 9.4 Timing Out Connections and RTSP Messages ............ 40 8096 9.5 Use of IPv6 ......................................... 40 8097 10 Capability Handling ................................. 41 8098 11 Method Definitions .................................. 42 8099 11.1 OPTIONS ............................................. 43 8100 11.2 DESCRIBE ............................................ 44 8101 11.3 SETUP ............................................... 46 8102 11.3.1 Changing Transport Parameters ....................... 48 8103 11.4 PLAY ................................................ 49 8104 11.5 PAUSE ............................................... 53 8105 11.6 TEARDOWN ............................................ 57 8106 11.7 GET_PARAMETER ....................................... 58 8107 11.8 SET_PARAMETER ....................................... 59 8108 11.9 REDIRECT ............................................ 60 8109 12 Embedded (Interleaved) Binary Data .................. 62 8110 13 Status Code Definitions ............................. 64 8111 13.1 Success 1xx ......................................... 64 8112 13.1.1 100 Continue ........................................ 64 8113 13.2 Success 2xx ......................................... 64 8114 13.3 Redirection 3xx ..................................... 64 8115 13.3.1 300 Multiple Choices ................................ 65 8116 13.3.2 301 Moved Permanently ............................... 65 8117 13.3.3 302 Found ........................................... 65 8118 13.3.4 303 See Other ....................................... 65 8119 13.3.5 304 Not Modified .................................... 66 8120 13.3.6 305 Use Proxy ....................................... 66 8121 13.4 Client Error 4xx .................................... 66 8122 13.4.1 400 Bad Request ..................................... 66 8123 13.4.2 405 Method Not Allowed .............................. 66 8124 13.4.3 451 Parameter Not Understood ........................ 67 8125 13.4.4 452 reserved ........................................ 67 8126 13.4.5 453 Not Enough Bandwidth ............................ 67 8127 13.4.6 454 Session Not Found ............................... 67 8128 13.4.7 455 Method Not Valid in This State .................. 67 8129 13.4.8 456 Header Field Not Valid for Resource ............. 67 8130 13.4.9 457 Invalid Range ................................... 67 8131 13.4.10 458 Parameter Is Read-Only .......................... 67 8132 13.4.11 459 Aggregate Operation Not Allowed ................. 68 8133 13.4.12 460 Only Aggregate Operation Allowed ................ 68 8134 13.4.13 461 Unsupported Transport ........................... 68 8135 13.4.14 462 Destination Unreachable ......................... 68 8136 13.4.15 463 Destination Prohibited .......................... 68 8137 13.4.16 470 Connection Authorization Required ............... 68 8138 13.4.17 471 Connection Credentials not accepted ............. 68 8139 13.5 Server Error 5xx .................................... 68 8140 13.5.1 551 Option not supported ............................ 68 8141 14 Header Field Definitions ............................ 69 8142 14.1 Accept .............................................. 71 8143 14.2 Accept-Credentials .................................. 71 8144 14.3 Accept-Encoding ..................................... 75 8145 14.4 Accept-Language ..................................... 75 8146 14.5 Accept-Ranges ....................................... 75 8147 14.6 Allow ............................................... 76 8148 14.7 Authorization ....................................... 76 8149 14.8 Bandwidth ........................................... 76 8150 14.9 Blocksize ........................................... 77 8151 14.10 Cache-Control ....................................... 77 8152 14.11 Connection .......................................... 79 8153 14.12 Connection-Credentials .............................. 80 8154 14.13 Content-Base ........................................ 80 8155 14.14 Content-Encoding .................................... 80 8156 14.15 Content-Language .................................... 80 8157 14.16 Content-Length ...................................... 80 8158 14.17 Content-Location .................................... 81 8159 14.18 Content-Type ........................................ 81 8160 14.19 CSeq ................................................ 81 8161 14.20 Date ................................................ 81 8162 14.21 ETag ................................................ 81 8163 14.22 Expires ............................................. 82 8164 14.23 From ................................................ 83 8165 14.24 Host ................................................ 83 8166 14.25 If-Match ............................................ 83 8167 14.26 If-Modified-Since ................................... 83 8168 14.27 If-None-Match ....................................... 84 8169 14.28 Last-Modified ....................................... 84 8170 14.29 Location ............................................ 84 8171 14.30 Proxy-Authenticate .................................. 84 8172 14.31 Proxy-Require ....................................... 84 8173 14.32 Proxy-Supported ..................................... 85 8174 14.33 Public .............................................. 85 8175 14.34 Range ............................................... 86 8176 14.35 Referer ............................................. 88 8177 14.36 Retry-After ......................................... 88 8178 14.37 Require ............................................. 88 8179 14.38 RTP-Info ............................................ 89 8180 14.39 Scale ............................................... 91 8181 14.40 Speed ............................................... 92 8182 14.41 Server .............................................. 92 8183 14.42 Session ............................................. 93 8184 14.43 Supported ........................................... 94 8185 14.44 Timestamp ........................................... 95 8186 14.45 Transport ........................................... 95 8187 14.46 Unsupported ......................................... 100 8188 14.47 User-Agent .......................................... 100 8189 14.48 Vary ................................................ 100 8190 14.49 Via ................................................. 100 8191 14.50 WWW-Authenticate .................................... 100 8192 15 Proxies ............................................. 100 8193 16 Caching ............................................. 101 8194 17 Examples ............................................ 102 8195 17.1 Media on Demand (Unicast) ........................... 102 8196 17.2 Streaming of a Container file ....................... 105 8197 17.3 Single Stream Container Files ....................... 108 8198 17.4 Live Media Presentation Using Multicast ............. 110 8199 17.5 Capability Negotiation .............................. 111 8200 18 Security Framework .................................. 112 8201 18.1 RTSP and HTTP Authentication ........................ 113 8202 18.2 RTSP over TLS ....................................... 113 8203 18.3 Security and Proxies ................................ 113 8204 18.3.1 Accept-Credentials .................................. 115 8205 18.3.2 User approved TLS procedure ......................... 116 8206 19 Syntax .............................................. 117 8207 19.1 Base Syntax ......................................... 117 8208 19.2 RTSP Protocol Definition ............................ 119 8209 19.2.1 Generic Protocol elements ........................... 119 8210 19.2.2 Message Syntax ...................................... 120 8211 19.2.3 Header Syntax ....................................... 124 8212 19.3 SDP extension Syntax ................................ 130 8213 20 Security Considerations ............................. 130 8214 20.1 Remote denial of Service Attack ..................... 132 8215 21 IANA Considerations ................................. 133 8216 21.1 Feature-tags ........................................ 133 8217 21.1.1 Description ......................................... 133 8218 21.1.2 Registering New Feature-tags with IANA .............. 134 8219 21.1.3 Registered entries .................................. 134 8220 21.2 RTSP Methods ........................................ 134 8221 21.2.1 Description ......................................... 134 8222 21.2.2 Registering New Methods with IANA ................... 134 8223 21.2.3 Registered Entries .................................. 135 8224 21.3 RTSP Status Codes ................................... 135 8225 21.3.1 Description ......................................... 135 8226 21.3.2 Registering New Status Codes with IANA .............. 135 8227 21.3.3 Registered Entries .................................. 135 8228 21.4 RTSP Headers ........................................ 135 8229 21.4.1 Description ......................................... 135 8230 21.4.2 Registering New Headers with IANA ................... 136 8231 21.4.3 Registered entries .................................. 136 8232 21.5 Transport Header registries ......................... 137 8233 21.5.1 Transport Protocols ................................. 137 8234 21.5.2 Profile ............................................. 137 8235 21.5.3 Lower Transport ..................................... 138 8236 21.5.4 Transport modes ..................................... 138 8237 21.5.5 Transport Parameters ................................ 139 8238 21.6 Cache Directive Extensions .......................... 139 8239 21.7 Accept-Credentials policies ......................... 140 8240 21.8 URI Schemes ......................................... 140 8241 21.9 SDP attributes ...................................... 140 8242 A RTSP Protocol State Machine ......................... 141 8243 A.1 States .............................................. 142 8244 A.2 State variables ..................................... 142 8245 A.3 Abbreviations ....................................... 142 8246 A.4 State Tables ........................................ 143 8247 B Media Transport Alternatives ........................ 146 8248 B.1 RTP ................................................. 146 8249 B.1.1 AVP ................................................. 146 8250 B.1.2 AVP/UDP ............................................. 146 8251 B.1.3 AVP/TCP ............................................. 148 8252 B.1.4 AVPF ................................................ 148 8253 B.1.5 SAVP ................................................ 148 8254 B.1.6 Handling NPT Jumps in the RTP Media Layer ........... 148 8255 B.1.7 Handling RTP Timestamps after PAUSE ................. 151 8256 B.1.8 RTSP / RTP Integration .............................. 153 8257 B.1.9 Scaling with RTP .................................... 153 8258 B.1.10 Maintaining NPT synchronization with RTP 8259 timestamps ..................................................... 154 8260 B.1.11 Continuous Audio .................................... 154 8261 B.1.12 Multiple Sources in an RTP Session .................. 154 8262 B.1.13 Usage of SSRCs and the RTCP BYE Message During an 8263 RTSP Session ................................................... 154 8264 B.2 Future Additions .................................... 155 8265 C Use of SDP for RTSP Session Descriptions ............ 155 8266 C.1 Definitions ......................................... 155 8267 C.1.1 Control URI ......................................... 155 8268 C.1.2 Media Streams ....................................... 157 8269 C.1.3 Payload Type(s) ..................................... 157 8270 C.1.4 Format-Specific Parameters .......................... 157 8271 C.1.5 Range of Presentation ............................... 158 8272 C.1.6 Time of Availability ................................ 158 8273 C.1.7 Connection Information .............................. 159 8274 C.1.8 Entity Tag .......................................... 159 8275 C.2 Aggregate Control Not Available ..................... 159 8276 C.3 Aggregate Control Available ......................... 160 8277 C.4 RTSP external SDP delivery .......................... 161 8278 D Minimal RTSP implementation ......................... 162 8279 D.1 Minimal Core Implementation ......................... 162 8280 D.2 The Basic Playback Feature Support .................. 162 8281 D.2.1 Client .............................................. 163 8282 D.2.2 Server .............................................. 163 8283 D.2.3 Proxy ............................................... 163 8284 D.3 Secure Transport .................................... 164 8285 D.4 Old Implementation Text ............................. 164 8286 D.5 Client .............................................. 164 8287 D.5.1 Basic Playback ...................................... 165 8288 D.5.2 Authentication-enabled .............................. 165 8289 D.6 Server .............................................. 165 8290 D.6.1 Basic Playback ...................................... 166 8291 D.6.2 Authentication-enabled .............................. 167 8292 E Requirements for Unreliable Transport of RTSP 8293 messages ....................................................... 167 8294 F Backwards Compatibility Considerations .............. 168 8295 F.1 Play Request in Play mode ........................... 169 8296 F.2 Using Persistent Connections ........................ 169 8297 G Open Issues ......................................... 169 8298 H Changes ............................................. 169 8299 H.1 Changes needing to be updated ..................... 175 8300 I Author Addresses .................................... 175 8301 J Contributors ........................................ 176 8302 K Acknowledgements .................................... 177 8303 L Normative References ................................ 177 8304 M Informative References .............................. 179