idnits 2.17.1 draft-ietf-mmusic-rtsp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 549 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 61 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 304 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 185: '... MAY use the HTTP state maintenance mechanism [1].)...' RFC 2119 keyword, line 572: '...ddresses in URLs SHOULD be avoided whe...' RFC 2119 keyword, line 608: '...rence identifier MUST be globally uniq...' RFC 2119 keyword, line 705: '...se message which MUST NOT include a me...' RFC 2119 keyword, line 874: '... However, applications MUST understand...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 474 has weird spacing: '... method sessi...' == Line 901 has weird spacing: '...equired x ...' == Line 942 has weird spacing: '...ication x ...' == Line 952 has weird spacing: '...oo Long x ...' == Line 965 has weird spacing: '...r Error x ...' == (8 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1997) is 9750 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1907 looks like a reference -- Missing reference section? '2' on line 190 looks like a reference -- Missing reference section? '3' on line 232 looks like a reference -- Missing reference section? '4' on line 235 looks like a reference -- Missing reference section? '5' on line 320 looks like a reference -- Missing reference section? '6' on line 322 looks like a reference -- Missing reference section? '7' on line 325 looks like a reference -- Missing reference section? '8' on line 326 looks like a reference -- Missing reference section? '9' on line 327 looks like a reference -- Missing reference section? '10' on line 617 looks like a reference -- Missing reference section? '11' on line 358 looks like a reference -- Missing reference section? '12' on line 531 looks like a reference -- Missing reference section? '13' on line 573 looks like a reference -- Missing reference section? '15' on line 616 looks like a reference -- Missing reference section? 'H6' on line 767 looks like a reference -- Missing reference section? 'H10' on line 1575 looks like a reference -- Missing reference section? 'CRLF' on line 2191 looks like a reference -- Missing reference section? 'H15' on line 2333 looks like a reference -- Missing reference section? '16' on line 2503 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Henning Schulzrinne, Columbia University 2 Anup Rao, Netscape Communications 3 Rob Lanphier, Progressive Networks 4 SUBMITTED: 24th February 1997 Expires: 24th August 1997 6 Real Time Streaming Protocol (RTSP) 7 draft-ietf-mmusic-rtsp-01.txt 9 STATUS OF THIS MEMO 11 This is an Internet-Draft. Internet-Drafts are working documents of the 12 Internet Engineering Task Force (IETF), its areas, and its working groups. 13 Note that other groups may also distribute working documents as 14 Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of 15 six months and may be updated, replaced, or obsoleted by other documents at 16 any time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the 20 "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), mannari.oz.au 22 (Pacific Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US West 23 Coast). 25 Prior to the expiration of this draft, the list of open issues may be found 26 at the following URL: 28 http://www.prognet.com/prognet/rt/openissues.html 30 Abstract: 32 The Real Time Streaming Protocol, or RTSP, is an application-level protocol 33 for control over the delivery of data with real-time properties. RTSP 34 provides an extensible framework to enable controlled, on-demand delivery 35 of real-time data, such as audio and video. Sources of data can include 36 both live data feeds and stored clips. This protocol is intended to control 37 multiple data delivery sessions, provide a means for choosing delivery 38 channels such as UDP, multicast UDP and TCP, and delivery mechanisms based 39 upon RTP (RFC 1889). 41 H. Schulzrinne, A. Rao, R. Lanphier Page 1 42 Contents 44 * 1 Introduction 45 o 1.1 Purpose 46 o 1.2 Requirements 47 o 1.3 Terminology 48 o 1.4 Protocol Properties 49 o 1.5 Extending RTSP 50 o 1.6 Overall Operation 51 o 1.7 RTSP States 52 o 1.8 Relationship with Other Protocols 53 * 2 Notational Conventions 54 * 3 Protocol Parameters 55 o 3.1 RTSP Version 56 o 3.2 RTSP URL 57 o 3.3 Conference Identifiers 58 o 3.4 Relative Timestamps 59 o 3.5 Absolute Time 60 * 4 RTSP Message 61 o 4.1 Message Types 62 o 4.2 Message Headers 63 o 4.3 Message Body 64 o 4.4 Message Length 65 * 5 Request 66 * 6 Response 67 o 6.1 Status-Line 68 + 6.1.1 Status Code and Reason Phrase 69 + 6.1.2 Response Header Fields 70 * 7 Entity 71 o 7.1 Entity Header Fields 72 o 7.2 Entity Body 73 * 8 Connections 74 o 8.1 Pipelining 75 o 8.2 Reliability and Acknowledgements 76 * 9 Method Definitions 77 o 9.1 HELLO 78 o 9.2 GET 79 o 9.3 SETUP 80 o 9.4 PLAY 81 o 9.5 PAUSE 82 o 9.6 CLOSE 83 o 9.7 BYE 84 o 9.8 GET_PARAMETER 85 o 9.9 SET_PARAMETER 86 o 9.10 REDIRECT 87 o 9.11 SESSION 88 o 9.12 RECORD 89 o 9.13 Embedded Binary Data 91 H. Schulzrinne, A. Rao, R. Lanphier Page 2 92 * 10 Status Codes Definitions 93 o 10.1 Client Error 4xx 94 + 10.1.1 451 Parameter Not Understood 95 + 10.1.2 452 Conference Not Found 96 + 10.1.3 453 Not Enough Bandwidth 97 + 10.1.4 45x Session Not Found 98 + 10.1.5 45x Method Not Valid in This State 99 + 10.1.6 45x Header Field Not Valid for Resource 100 + 10.1.7 45x Invalid Range 101 + 10.1.8 45x Parameter Is Read-Only 102 * 11 Header Field Definitions 103 o 11.1 Accept 104 o 11.2 Accept-Encoding 105 o 11.3 Accept-Language 106 o 11.4 Allow 107 o 11.5 Authorization 108 o 11.6 Bandwidth 109 o 11.7 Blocksize 110 o 11.8 Conference 111 o 11.9 Content-Encoding 112 o 11.10 Content-Length 113 o 11.11 Content-Type 114 o 11.12 Date 115 o 11.13 If-Modified-Since 116 o 11.14 Last-modified 117 o 11.15 Location 118 o 11.16 Range 119 o 11.17 Require 120 o 11.18 Unsupported 121 o 11.19 Nack-Transport-Require 122 o 11.20 Transport-Require 123 o 11.21 Retry-After 124 o 11.22 Speed 125 o 11.23 Server 126 o 11.24 Session 127 o 11.25 Transport 128 o 11.26 User-Agent 129 o 11.27 Via 130 o 11.28 WWW-Authenticate 131 * 12 Caching 132 * 13 Examples 133 o 13.1 Media on Demand (Unicast) 134 o 13.2 Live Media Event Using Multicast 135 o 13.3 Playing media into an existing session 136 o 13.4 Recording 138 H. Schulzrinne, A. Rao, R. Lanphier Page 3 139 * 14 Syntax 140 o 14.1 Base Syntax 141 o 14.2 Internet Media Type Syntax 142 o 14.3 Universal Resource Identifier Syntax 143 o 14.4 RTSP-specific syntax 144 * 15 Experimental 145 o 15.1 Header Field Definitions 146 + 15.1.1 Address 147 * 16 Security Considerations 148 * A State Machines 149 o A.1 Client State Machine 150 + A.1.1 Client States 151 + A.1.2 Notes 152 + A.1.3 State Table 153 o A.2 Server State Machine 154 + A.2.1 Server States 155 + A.2.2 State Table 156 * B Open Issues 157 * C Author Addresses 158 * D Acknowledgements 159 * References 161 1 Introduction 163 1.1 Purpose 165 RTSP establishes and controls either single or several (time-synchronized) 166 streams of continuous media. It does not typically deliver the continuous 167 streams itself, although interleaving of the continuous media stream with 168 the control stream is possible (Section 9.13). 170 There is no notion of an RTSP connection, but rather a session maintained 171 by an identifier. An RTSP session is in no way tied to a transport-level 172 session. During an RTSP session, an RTSP client may open and close many 173 reliable transport connections to the server to issue RTSP requests. 174 Alternatively, it may use a connectionless transport protocol such as UDP. 176 The protocol is intentionally similar in syntax and operation to HTTP/1.1, 177 so that extension mechanisms to HTTP can in most cases also be added to 178 RTSP. However, RTSP differs in a number of important aspects from HTTP: 180 H. Schulzrinne, A. Rao, R. Lanphier Page 4 181 * RTSP introduces a number of new methods and has a different protocol 182 identifier. 183 * An RTSP server needs to maintain state by default in almost all cases, 184 as opposed to the stateless nature of HTTP. (RTSP servers and clients 185 MAY use the HTTP state maintenance mechanism [1].) 186 * Both an RTSP server and client can issue requests. 187 * Data is carried out-of-band, by a different protocol. (There is an 188 exception to this.) 189 * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, 190 consistent with current HTML internationalization efforts [2]. 192 HS: Probably the right thing to do, but may lead to 193 confusion with GET. 195 * The Request-URI always contains the absolute URI. Because of backward 196 compatibility with a historical blunder, HTTP/1.1 carries only the 197 absolute path in the request 199 This makes virtual hosting easier. However, this is 200 incompatible with HTTP/1.1, which may be a bad idea. Makes 201 definition of GET confusing, if it is included in RTSP. 203 The protocol supports the following operations: 205 Retrieval of media from media server: 206 The client can request a session description via HTTP or some other 207 method. If the session is being multicast, the session description 208 contains the multicast addresses and ports to be used for the 209 continuous media. If the session is to be sent only to the client via 210 unicast, the client provides the destination for security reasons. 212 Invitation of a media server to a conference: 213 A media server can be ``invited'' to join an existing conference, 214 either to play back media into the session or to record all or a 215 subset of the media in a session. This mode is useful for distributed 216 teaching applications. Several parties in the conference may take 217 turns ``pushing the remote control buttons''. 219 Addition of media to an existing session: 220 Particularly for live events, it is useful if the server can tell the 221 client about additional media becoming available. 223 H. Schulzrinne, A. Rao, R. Lanphier Page 5 224 RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1. 226 1.2 Requirements 228 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 229 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and 230 ``OPTIONAL'' in this document are to be interpreted as described in RFC 231 xxxx [3]. 233 1.3 Terminology 235 Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not 236 listed here are defined as in HTTP/1.1. 238 Conference: 239 a multiparty, multimedia session, where ``multi'' implies greater than 240 or equal to one. 242 Client: 243 The client requests continuous media data from the media server. 245 Connection: 246 A transport layer virtual circuit established between two programs for 247 the purpose of communication. 249 Continuous media: 250 Data where there is a timing relationship between source and sink, 251 that is, the sink must reproduce the timing relationshop that existed 252 at the source. The most common examples of continuous media are audio 253 and motion video. Continuous media can be realtime (interactive), 254 where there is a ``tight'' timing relationship between source and 255 sink, or streaming (playback), where the relationship is less strict. 257 Entity: 258 An entity is a participant in a conference. This participant may be 259 non-human, e.g., a media record or playback server. 261 Media server: 262 The network entity providing playback or recording services for one or 263 more media streams. Different media streams within a session may 264 originate from different media servers. A media server may reside on 265 the same or a different host as the web server the media session is 266 invoked from. 268 H. Schulzrinne, A. Rao, R. Lanphier Page 6 269 Media session: 270 A collection of media streams to be treated as an aggregate, with a 271 single time axis. Typically, a client will synchronize in time all 272 media streams within a media session. An example of a media session is 273 a movie consisting of a video and audio track. 275 (Media) stream: 276 A single media instance, e.g., an audio stream or a video stream as 277 well as a single whiteboard or shared application group. When using 278 RTP, a stream consists of all RTP and RTCP packets created by a source 279 within an RTP session. 281 [TBD: terminology is confusing since there's an RTP session, which is 282 used by a single RTSP stream.] 284 Message: 285 The basic unit of RTSP communication, consisting of a structured 286 sequence of octets matching the syntax defined in Section 14 and 287 transmitted via a connection or a connectionless protocol. 289 Response: 290 An RTSP response. If an HTTP response is meant, that is indicated 291 explicitly. 293 Request: 294 An RTSP request. If an HTTP request is meant, that is indicated 295 explicitly. 297 Session description: 298 A session description contains information about one or more media 299 within a session, such as the set of encodings, network addresses and 300 information about the content. The session description may take 301 several different formats, including SDP and SDF. 303 Media parameter: 304 Parameter specific to a media type that may be changed while the 305 stream is being played or prior to it. 307 1.4 Protocol Properties 309 RTSP has the following properties: 311 Extendable: 312 New methods and parameters can be easily added to RTSP. 314 H. Schulzrinne, A. Rao, R. Lanphier Page 7 315 Easy to parse: 316 RTSP can be parsed by standard HTTP or MIME parsers. 318 Secure: 319 RTSP re-uses web security mechanisms, either at the transport level 320 (TLS [5]) or within the protocol itself. All HTTP authentication 321 mechanisms such as basic [4, Section 11.1,] and digest authentication 322 [6] are directly applicable. 324 Transport-independent: 325 RTSP may use either an unreliable datagram protocol (UDP) [7], a 326 reliable datagram protocol (RDP, not widely used [8]) or a reliable 327 stream protocol such as TCP [9] as it implements application-level 328 reliability. 330 Multi-server capable: 331 Each media stream within a session can reside on a different server. 332 The client automatically establishes several concurrent control 333 sessions with the different media servers. Media synchronization is 334 performed at the transport level. 336 Control of recording devices: 337 The protocol can control both recording and playback devices, as well 338 as devices that can alternate between the two modes (``VCR''). 340 Separation of stream control and conference initiation: 341 Stream control is divorced from inviting a media server to a 342 conference. The only requirement is that the conference initiation 343 protocol either provides or can be used to create a unique conference 344 identifier. In particular, SIP [10] or H.323 may be used to invite a 345 server to a conference. 347 Suitable for professional applications: 348 RTSP supports frame-level accuracy through SMPTE time stamps to allow 349 remote digital editing. 351 Session description neutral: 352 The protocol does not impose a particular session description or 353 metafile format and can convey the type of format to be used. However, 354 the session description must contain an RTSP URI. 356 Proxy and firewall friendly: 357 The protocol should be readily handled by both application and 358 transport-layer (SOCKS [11]) firewalls. A firewall may need to 359 understand the SETUP method to open a ``hole'' for the UDP media 360 stream. 362 H. Schulzrinne, A. Rao, R. Lanphier Page 8 363 HTTP-friendly: 364 Where sensible, RTSP re-uses HTTP concepts, so that the existing 365 infrastructure can be re-used. This infrastructure includes JEPI (the 366 Joint Electronic Payment Initiative) for electronic payments and PICS 367 (Platform for Internet Content Selection) for associating labels with 368 content. However, RTSP does not just add methods to HTTP, since the 369 controlling continuous media requires server state in most cases. 371 Appropriate server control: 372 If a client can start a stream, it must be able to stop a stream. 373 Servers should not start streaming to clients in such a way that 374 clients cannot stop the stream. 376 Transport negotiation: 377 The client can negotiate the transport method prior to actually 378 needing to process a continuous media stream. 380 Capability negotiation: 381 If basic features are disabled, there must be some clean mechanism for 382 the client to determine which methods are not going to be implemented. 383 This allows clients to present the appropriate user interface. For 384 example, if seeking is not allowed, the user interface must be able to 385 disallow moving a sliding position indicator. 387 An earlier requirement in RTSP' was multi-client capability. 388 However, it was determined that a better approach was to make 389 sure that the protocol is easily extensible to the multi-client 390 scenario. Stream identifiers can be used by several control 391 streams, so that ``passing the remote'' would be possible. The 392 protocol would not address how several clients negotiate access; 393 this is left to either a ``social protocol'' or some other floor 394 control mechanism. 396 1.5 Extending RTSP 398 RTSP can be extended in three ways, listed in order of the magnitude of 399 changes supported: 401 H. Schulzrinne, A. Rao, R. Lanphier Page 9 402 * Existing methods can be extended with new parameters, as long as these 403 parameters can be safely ignored by the recipient. (This is equivalent 404 to adding new parameters to an HTML tag.) 405 * New methods can be added. If the recipient of the message does not 406 understand the request, it responds with error code 501 (Not 407 implemented) and the sender can then attempt an earlier, less 408 functional version. 409 * A new version of the protocol can be defined, allowing almost all 410 aspects (except the position of the protocol version number) to 411 change. 413 1.6 Overall Operation 415 Each media stream and session may be identified by an RTSP URL. The overall 416 session and the properties of the media the session is made up of are 417 defined by a session description file, the format of which is outside the 418 scope of this specification. The session description file is retrieved 419 using HTTP, either from the web server or the media server, typically using 420 an URL with scheme HTTP. 422 The session description file contains a description of the media streams 423 making up the media session, including their encodings, language, and other 424 parameters that enable the client to choose the most appropriate 425 combination of media. In this session description, each media stream is 426 identified by an RTSP URL, which points to the media server handling that 427 particular media stream and names the stream stored on that server. Several 428 media streams can be located on different servers; for example, audio and 429 video tracks can be split across servers for load sharing. The description 430 also enumerates which transport methods the server is capable of. If 431 desired, the session description can also contain only an RTSP URL, with 432 the complete session description retrieved via RTSP. 434 Besides the media parameters, the network destination address and port need 435 to be determined. Several modes of operation can be distinguished: 437 Unicast: 438 The media is transmitted to the source of the RTSP request, with the 439 port number picked by the client. Alternatively, the media is 440 transmitted on the same reliable stream as RTSP. 442 Multicast, server chooses address: 443 The media server picks the multicast address and port. This is the 444 typical case for a live or near-media-on-demand transmission. 446 Multicast, client chooses address: 447 If the server is to participate in an existing multicast conference, 448 the multicast address, port and encryption key are given by the 449 conference description, established by means outside the scope of this 450 specification. 452 1.7 RTSP States 454 RTSP controls a stream which may be sent via a separate protocol, 455 independent of the control channel. For example, RTSP control may occur on 456 a TCP connection while the data flows via UDP. Thus, data delivery 457 continues even if no RTSP requests are received by the media server. Also, 458 during its lifetime, a single media stream may be controlled by RTSP 459 requests issued sequentially on different TCP connections. Therefore, the 460 server needs to maintain ``session state'' to be able to correlate RTSP 461 requests with a stream. 463 HS: This does not imply that the protocol has to be stateful in 464 the way described here. If state were to be defined by identifier 465 only, the first PLAY or RECORD request would initiate stream 466 flow, with no need for SETUP. It has been argued that a separate 467 setup simplifies the life of firewall writers. 469 Many methods in RTSP do not contribute to state. However, there are four 470 that play a central role in defining the allocation and usage of stream 471 resources on the server: SETUP, PLAY, PAUSE, and CLOSE. The roles they play 472 are defined as follows. 474 Step session allocation method session control method 475 1 SETUP 476 2 PLAY 477 3 PAUSE 478 4 CLOSE 480 SETUP Causes the server to allocate resources for a stream. 481 PLAY Starts data transmission on a stream allocated via SETUP. 482 PAUSE Temporarily halts a stream, without freeing server resources. 484 CLOSE Frees resources associated with the stream. The session ceases to 485 exist on the server. 487 A client must issue a SETUP request unless all necessary transport 488 information is already available. 490 1.8 Relationship with Other Protocols 492 RTSP has some overlap in functionality with HTTP. It also may interact with 493 HTTP in that the initial contact with streaming content is often to be made 494 through a web page. The current protocol specification aims to allow 495 different hand-off points between a web server and the media server 496 implementing RTSP. For example, the session description can be retrieved 497 using HTTP or RTSP. Having the session description be returned by the web 498 server makes it possible to have the web server take care of authentication 499 and billing, by handing out a session description whose media identifier 500 includes an encrypted version of the requestor's IP address and a 501 timestamp, with a shared secret between web and media server. 503 However, RTSP differs fundamentally from HTTP in that data delivery takes 504 place out-of-band, in a different protocol. HTTP is an asymmetric protocol, 505 where the client issues requests and the server responds. In RTSP, both the 506 media client and media server can issue requests. RTSP requests are also 507 not stateless, in that they may set parameters and continue to control a 508 media stream long after the request has been acknowledged. 510 Re-using HTTP functionality has advantages in at least two areas, 511 namely security and proxies. The requirements are very similar, 512 so having the ability to adopt HTTP work on caches, proxies and 513 authentication is valuable. 515 While most real-time media will use RTP as a transport protocol, RTSP is 516 not tied to RTP. 518 RTSP assumes the existence of a session description format that can express 519 both static and temporal properties of a media session containing several 520 media streams. 522 2 Notational Conventions 524 Since many of the definitions and syntax are identical to HTTP/1.1, this 525 specification only points to the section where they are defined rather than 526 copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of 527 the current HTTP/1.1 specification (RFC 2068). 529 All the mechanisms specified in this document are described in both prose 530 and an augmented Backus-Naur form (BNF) similar to that used in RFC 2068 531 [H2.1]. It is described in detail in [12]. 533 In this draft, we use indented and smaller-type paragraphs to provide 534 background and motivation. Some of these paragraphs are marked with HS, AR 535 and RL, designating opinions and comments by the individual authors which 536 may not be shared by the co-authors and require resolution. 538 3 Protocol Parameters 540 3.1 RTSP Version 542 [H3.1] applies, with HTTP replaced by RTSP. 544 3.2 RTSP URL 546 The ``rtsp'' and ``rtspu'' schemes are used to refer to network resources 547 via the RTSP protocol. This section defines the scheme-specific syntax and 548 semantics for RTSP URLs. 550 rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path] 551 host = 554 port = *DIGIT 556 abs_path is defined in [H3.2.1]. 558 Note that fragment and query identifiers do not have a 559 well-defined meaning at this time, with the interpretation left 560 to the RTSP server. 562 The scheme rtsp requires that commands are issued via a reliable protocol 563 (within the Internet, TCP), while the scheme rtspu identifies an unreliable 564 protocol (within the Internet, UDP). 566 If the port is empty or not given, port 554 is assumed. The semantics are 567 that the identified resource can be controlled be RTSP at the server 568 listening for TCP (scheme ``rtsp'') connections or UDP (scheme ``rtspu'') 569 packets on that port of host, and the Request-URI for the resource is 570 rtsp_URL. 572 The use of IP addresses in URLs SHOULD be avoided whenever possible (see 573 RFC 1924 [13]). 575 A media presentation is identified by an textual media identifier, using 576 the character set and escape conventions [H3.2] of URLs []. Requests 577 described in Section 9 can refer to either the whole presentation or an 578 individual track within the presentation. Note that some methods can only 579 be applied to tracks, not presentations. A specific instance of a session, 580 e.g., one of several concurrent transmissions of the same content, is 581 indicated by the Session header field (Section 11.24) where needed. 583 For example, the RTSP URL 585 rtsp://media.content.com:554/twister/audiotrack 587 identifies the audio track within the presentation ``twister'', which can 588 be controlled via RTSP requests issued over a TCP connection to port 554 of 589 host media.content.com. 591 This does not imply a standard way to reference tracks in URLs. 592 The session description defines the hierarchical relationships in 593 the presentation and the URLs for the individual tracks. A 594 session description may name a track 'a.mov' and the whole 595 presentation 'b.mov'. 597 The path components of the RTSP URL are opaque to the client and do not 598 imply any particular file system structure for the server. 600 This decoupling also allows session descriptions to be used with 601 non-RTSP media control protocols, simply by replacing the scheme 602 in the URL. 604 3.3 Conference Identifiers 606 Conference identifiers are opaque to RTSP and are encoded using standard 607 URI encoding methods (i.e., LWS is escaped with %). They can contain any 608 octet value. The conference identifier MUST be globally unique. For H.323, 609 the conferenceID value is to be used. 611 conference-id = 1*OCTET ; LWS must be URL-escaped 613 Conference identifiers are used to allow to allow RTSP sessions 614 to obtain parameters from multimedia conferences the media server 615 is participating in. These conferences are created by protocols 616 outside the scope of this specification, e.g., H.323 [15] or SIP 617 [10]. Instead of the RTSP client explicitly providing transport 618 information, for example, it asks the media server to use the 619 values in the conference description instead. If the conference 620 participant inviting the media server would only supply a 621 conference identifier which is unique for that inviting party, 622 the media server could add an internal identifier for that party, 623 e.g., its Internet address. However, this would prevent that the 624 conference participant and the initiator of the RTSP commands are 625 two different entities. 627 3.4 Relative Timestamps 629 A relative time-stamp expresses time relative to the start of the clip. 630 Relative timestamps are expressed as SMPTE time codes for frame-level 631 access accuracy. The time code has the format hours:minutes:seconds.frames, 632 with the origin at the start of the clip. For NTSC, the frame rate is 29.97 633 frames per second. This is handled by dropping the first frame index of 634 every minute, except every tenth minute. If the frame value is zero, it may 635 be omitted. 637 smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ] 638 smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ] 640 Examples: 642 10:12:33.40 643 10:7:33 644 10:7:0 646 3.5 Absolute Time 648 Absolute time is expressed as ISO 8601 timestamps. It is always expressed 649 as UTC (GMT). 651 utc-range = "clock" "=" utc-time "-" [ utc-time ] 652 utc-time = utc-date "T" utc-time "Z" 653 utc-date = 8DIGIT ; < YYYYMMDD > 654 utc-time = 6DIGIT ; < HHMMSS > 656 Example for November 8, 1996 at 14h37 and 20 seconds UTC: 658 19961108T143720Z 660 4 RTSP Message 662 RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 663 encoding (RFC 2044). Lines are terminated by CRLF, but receivers should be 664 prepared to also interpret CR and LF by themselves as line terminators. 666 Text-based protocols make it easier to add optional parameters in 667 a self-describing manner. Since the number of parameters and the 668 frequency of commands is low, processing efficiency is not a 669 concern. Text-based protocols, if done carefully, also allow easy 670 implementation of research prototypes in scripting languages such 671 as Tcl, Visual Basic and Perl. 673 The 10646 character set avoids tricky character set switching, 674 but is invisible to the application as long as US-ASCII is being 675 used. This is also the encoding used for RTCP. ISO 8859-1 676 translates directly into Unicode, with a high-order octet of 677 zero. ISO 8859-1 characters with the most-significant bit set are 678 represented as 1100001x 10xxxxxx. 680 RTSP messages can be carried over any lower-layer transport protocol that 681 is 8-bit clean. 683 Requests contain methods, the object the method is operating upon and 684 parameters to further describe the method. Methods are idempotent, unless 685 otherwise noted. Methods are also designed to require little or no state 686 maintenance at the media server. 688 4.1 Message Types 690 See [H4.1] 692 4.2 Message Headers 694 See [H4.2] 696 4.3 Message Body 698 See [H4.3] 700 4.4 Message Length 702 When a message-body is included with a message, the length of that body is 703 determined by one of the following (in order of precedence): 705 1. Any response message which MUST NOT include a message-body (such as 706 the 1xx, 204, and 304 responses) is always terminated by the first 707 empty line after the header fields, regardless of the entity-header 708 fields present in the message. 709 2. If a Content-Length header field (section 11.10) is present, its value 710 in bytes represents the length of the message-body. If this header 711 field is not present, a value of zero is assumed. 712 3. By the server closing the connection. (Closing the connection cannot 713 be used to indicate the end of a request body, since that would leave 714 no possibility for the server to send back a response.) 716 Note that RTSP does not (at present) support the ``chunked'' transfer 717 coding and requires the presence of the Content-Length header field. 719 Given the moderate length of session descriptions returned, the 720 server should always be able to determine its length, even if it 721 is generated dynamically, making the chunked transfer encoding 722 unnecessary. Even though Content-Length must be present if there 723 is any entity body, the rules ensure reasonable behavior even if 724 the length is not given explicitly. 726 5 Request 728 A request message from a client to a server or vice versa includes, within 729 the first line of that message, the method to be applied to the resource, 730 the identifier of the resource, and the protocol version in use. 732 Request = Request-line CRLF 733 *request-header 734 CRLF 735 [ message-body ] 737 Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF 739 Method = "GET" ; Section 740 | "SETUP" ; Section 741 | "PLAY" ; Section 742 | "PAUSE" ; Section 743 | "CLOSE" ; Section 744 | "RECORD" ; Section 745 | "REDIRECT" ; Section 746 | "HELLO" ; Section 747 | "SESSION" ; Section 748 | "BYE" ; Section 749 | "SET_PARAMETER" ; Section 750 | "GET_PARAMETER" ; Section 751 | extension-method 753 extendion-method = token 755 Request-URI = absolute_URI 757 RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 759 seq-no = 1*DIGIT 761 Note that in contrast to HTTP/1.1, RTSP requests always contain the 762 absolute URL (that is, including the scheme, host and port) rather than 763 just the absolute path. 765 6 Response 767 [H6] applies except that HTTP-Version is replaced by RTSP-Version. Also, 768 RTSP defines additional status codes and does not define some HTTP codes. 769 The valid response codes and the methods they can be used with are defined 770 in the table 1 and 2. 772 After receiving and interpreting a request message, the recipient responds 773 with an RTSP response message. 775 Response = Status-Line ; Section 776 *( general-header ; Section 777 | response-header ; Section 778 | entity-header ) ; Section 779 CRLF 780 [ message-body ] ; Section 782 6.1 Status-Line 784 The first line of a Response message is the Status-Line, consisting of the 785 protocol version followed by a numeric status code, the sequence number of 786 the corresponding request and the textual phrase associated with the status 787 code, with each element separated by SP characters. No CR or LF is allowed 788 except in the final CRLF sequence. Note that the addition of a 790 Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF 792 6.1.1 Status Code and Reason Phrase 794 The Status-Code element is a 3-digit integer result code of the attempt to 795 understand and satisfy the request. These codes are fully defined in 796 section10. The Reason-Phrase is intended to give a short textual 797 description of the Status-Code. The Status-Code is intended for use by 798 automata and the Reason-Phrase is intended for the human user. The client 799 is not required to examine or display the Reason-Phrase. 801 The first digit of the Status-Code defines the class of response. The last 802 two digits do not have any categorization role. There are 5 values for the 803 first digit: 805 * 1xx: Informational - Request received, continuing process 806 * 2xx: Success - The action was successfully received, understood, and 807 accepted 808 * 3xx: Redirection - Further action must be taken in order to complete 809 the request 810 * 4xx: Client Error - The request contains bad syntax or cannot be 811 fulfilled 812 * 5xx: Server Error - The server failed to fulfill an apparently valid 813 request 815 The individual values of the numeric status codes defined for RTSP/1.0, and 816 an example set of corresponding Reason-Phrase's, are presented below. The 817 reason phrases listed here are only recommended - they may be replaced by 818 local equivalents without affecting the protocol. Note that RTSP adopts 819 most HTTP/1.1 status codes and adds RTSP-specific status codes in the 820 starting at 450 to avoid conflicts with newly defined HTTP status codes. 822 Status-Code = "100" ; Continue 823 | "200" ; OK 824 | "201" ; Created 825 | "202" ; Accepted 826 | "203" ; Non-Authoritative Information 827 | "204" ; No Content 828 | "205" ; Reset Content 829 | "206" ; Partial Content 830 | "300" ; Multiple Choices 831 | "301" ; Moved Permanently 832 | "302" ; Moved Temporarily 833 | "303" ; See Other 834 | "304" ; Not Modified 835 | "305" ; Use Proxy 836 | "400" ; Bad Request 837 | "401" ; Unauthorized 838 | "402" ; Payment Required 839 | "403" ; Forbidden 840 | "404" ; Not Found 841 | "405" ; Method Not Allowed 842 | "406" ; Not Acceptable 843 | "407" ; Proxy Authentication Required 844 | "408" ; Request Time-out 845 | "409" ; Conflict 846 | "410" ; Gone 847 | "411" ; Length Required 848 | "412" ; Precondition Failed 849 | "413" ; Request Entity Too Large 850 | "414" ; Request-URI Too Large 851 | "415" ; Unsupported Media Type 852 | "451" ; Parameter Not Understood} 853 | "452" ; Conference Not Found} 854 | "453" ; Not Enough Bandwidth} 855 | "45x" ; Session Not Found} 856 | "45x" ; Method Not Valid in This State} 857 | "45x" ; Header Field Not Valid for Resource} 858 | "45x" ; Invalid Range} 859 | "45x" ; Parameter Is Read-Only} 860 | "500" ; Internal Server Error 861 | "501" ; Not Implemented 862 | "502" ; Bad Gateway 863 | "503" ; Service Unavailable 864 | "504" ; Gateway Time-out 865 | "505" ; HTTP Version not supported 866 | extension-code 868 extension-code = 3DIGIT 870 Reason-Phrase = * 872 RTSP status codes are extensible. RTSP applications are not required to 873 understand the meaning of all registered status codes, though such 874 understanding is obviously desirable. However, applications MUST understand 875 the class of any status code, as indicated by the first digit, and treat 876 any unrecognized response as being equivalent to the x00 status code of 877 that class, with the exception that an unrecognized response MUST NOT be 878 cached. For example, if an unrecognized status code of 431 is received by 879 the client, it can safely assume that there was something wrong with its 880 request and treat the response as if it had received a 400 status code. In 881 such cases, user agents SHOULD present to the user the entity returned with 882 the response, since that entity is likely to include human-readable 883 information which will explain the unusual status. 885 Code reason HELLO GET SETUP PLAY RECORD PAUSE 886 100 Continue x x x x x x 887 200 OK x x x x x x 888 300 Multiple Choices x x x x x 889 301 Moved Permanently x x x x x 890 302 Moved Temporarily x x x x x 891 303 See Other x x x x x 892 304 Not Modified x x x x x 893 305 Use Proxy x x x x x 894 400 Bad Request x x x x x x 895 401 Unauthorized x x x x x x 896 402 Payment Required x x x x x x 897 403 Forbidden x x x x x 898 404 Not Found x x x x x 899 405 Method Not Allowed x x x x x x 900 406 Not Acceptable x x x x x 901 407 Proxy Authentication Required x x x x x x 902 408 Request Timeout x x x x x x 903 409 Conflict 904 410 Gone x x x x x x 905 411 Length Required x x x 906 412 Precondition Failed x x 907 413 Request Entity Too Large x x 908 414 Request-URI Too Long x x x x x x 909 415 Unsupported Media Type x x 910 45x Only Valid for Stream x x x 911 45x Invalid parameter 912 45x Not Enough Bandwidth x 913 45x Illegal Conference Identifier 914 45x Illegal Session Identifier x x x x 915 45x Parameter Is Read-Only 916 45x Header Field Not Valid 917 500 Internal Server Error x x x x x x 918 501 Not Implemented x x x x x x 919 502 Bad Gateway x x x x x x 920 503 Service Unavailable x x x x x x 921 504 Gateway Timeout x x x x x x 922 505 RTSP Version Not Supported x x x x x x 924 Table 1: Status codes and their usage with RTSP methods 925 Code reason CLOSE REDIRECT GET_PARAMETER SET_PARAMETER 926 100 Continue x x x x 927 200 OK x x x x 928 300 Multiple Choices x x x 929 301 Moved Permanently x x x x 930 302 Moved Temporarily x x x x 931 303 See Other x x x x 932 304 Not Modified x x x x 933 305 Use Proxy x x x x 934 400 Bad Request x x x x 935 401 Unauthorized x x x 936 402 Payment Required x x x 937 403 Forbidden x x x x 938 404 Not Found x x x x 939 405 Method Not Allowed x x x x 940 406 Not Acceptable x x x x 942 407 Proxy Authentication x x x x 943 Required 944 408 Request Timeout x x x x 945 409 Conflict x x 946 410 Gone x x 947 411 Length Required x x 948 412 Precondition Failed x x 950 413 Request Entity Too x x x x 951 Large 952 414 Request-URI Too Long x x x x 953 415 Unsupported Media Type 954 45x Only Valid for Stream 955 45x Invalid parameter 956 45x Not Enough Bandwidth 958 45x Illegal Conference 959 Identifier 961 45x Illegal Session x x 962 Identifier 963 45x Parameter Is Read-Only x 964 45x Header Field Not Valid 965 500 Internal Server Error x x x x 966 501 Not Implemented x x x x 967 502 Bad Gateway x x x x 968 503 Service Unavailable x x x x 969 504 Gateway Timeout x x x x 971 505 RTSP Version Not x x x x 972 Supported 974 Table 2: Status codes and their usage with RTSP methods 976 6.1.2 Response Header Fields 978 The response-header fields allow the request recipient to pass additional 979 information about the response which cannot be placed in the Status-Line. 980 These header fields give information about the server and about further 981 access to the resource identified by the Request-URI. 983 response-header = Location ; Section 984 | Proxy-Authenticate ; Section 985 | Public ; Section 986 | Retry-After ; Section 987 | Server ; Section 988 | Vary ; Section 989 | WWW-Authenticate ; Section 991 Response-header field names can be extended reliably only in combination 992 with a change in the protocol version. However, new or experimental header 993 fields MAY be given the semantics of response-header fields if all parties 994 in the communication recognize them to be response-header fields. 995 Unrecognized header fields are treated as entity-header fields. 997 7 Entity 999 Request and Response messages MAY transfer an entity if not otherwise 1000 restricted by the request method or response status code. An entity 1001 consists of entity-header fields and an entity-body, although some 1002 responses will only include the entity-headers. 1004 In this section, both sender and recipient refer to either the client or 1005 the server, depending on who sends and who receives the entity. 1007 7.1 Entity Header Fields 1009 Entity-header fields define optional metainformation about the entity-body 1010 or, if no body is present, about the resource identified by the request. 1012 entity-header = Allow ; Section 14.7 1013 | Content-Encoding ; Section 14.12 1014 | Content-Language ; Section 14.13 1015 | Content-Length ; Section 14.14 1016 | Content-Type ; Section 14.18 1017 | Expires ; Section 14.21 1018 | Last-Modified ; Section 14.29 1019 | extension-header 1021 extension-header = message-header 1023 The extension-header mechanism allows additional entity-header fields to be 1024 defined without changing the protocol, but these fields cannot be assumed 1025 to be recognizable by the recipient. Unrecognized header fields SHOULD be 1026 ignored by the recipient and forwarded by proxies. 1028 7.2 Entity Body 1030 See [H7.2] 1032 8 Connections 1034 RTSP requests can be transmitted in several different ways: 1036 * persistent transport connections used for several request-response 1037 transactions; 1038 * one connection per request/response transaction; 1039 * connectionless mode. 1041 The type of transport connection is defined by the RTSP URI (Section 3.2). 1042 For the scheme ``rtsp'', a persistent connection is assumed, while the 1043 scheme ``rtspu'' calls for RTSP requests to be send without setting up a 1044 connection. 1046 Unlike HTTP, RTSP allows the media server to send requests to the media 1047 client. However, this is only supported for persistent connections, as the 1048 media server otherwise has no reliable way of reaching the client. Also, 1049 this is the only way that requests from media server to client are likely 1050 to traverse firewalls. 1052 8.1 Pipelining 1054 A client that supports persistent connections or connectionless mode MAY 1055 ``pipeline'' its requests (i.e., send multiple requests without waiting for 1056 each response). A server MUST send its responses to those requests in the 1057 same order that the requests were received. 1059 8.2 Reliability and Acknowledgements 1061 Requests are acknowledged by the receiver unless they are sent to a 1062 multicast group. If there is no acknowledgement, the sender may resend the 1063 same message after a timeout of one round-trip time (RTT). The round-trip 1064 time is estimated as in TCP (RFC TBD), with an initial round-trip value of 1065 500 ms. An implementation MAY cache the last RTT measurement as the initial 1066 value for future connections. If a reliable transport protocol is used to 1067 carry RTSP, the timeout value MAY be set to an arbitrarily large value. 1069 This can greatly increase responsiveness for proxies operating in 1070 local-area networks with small RTTs. The mechanism is defined 1071 such that the client implementation does not have be aware of 1072 whether a reliable or unreliable transport protocol is being 1073 used. It is probably a bad idea to have two reliability 1074 mechanisms on top of each other, although the RTSP RTT estimate 1075 is likely to be larger than the TCP estimate. 1077 Each request carries a sequence number, which is incremented by one for 1078 each request transmitted. If a request is repeated because of lack of 1079 acknowledgement, the sequence number is incremented. 1081 This avoids ambiguities when computing round-trip time estimates. 1083 [TBD: An initial sequence number negotiation needs to be added for UDP; 1084 otherwise, a new stream connection may see a request be acknowledged by a 1085 delayed response from an earlier ``connection''. This handshake can be 1086 avoided with a sequence number containing a timestamp of sufficiently high 1087 resolution.] 1089 The reliability mechanism described here does not protect against 1090 reordering. This may cause problems in some instances. For example, a CLOSE 1091 followed by a PLAY has quite a different effect than the reverse. 1092 Similarly, if a PLAY request arrives before all parameters are set due to 1093 reordering, the media server would have to issue an error indication. Since 1094 sequence numbers for retransmissions are incremented (to allow easy RTT 1095 estimation), the receiver cannot just ignore out-of-order packets. [TBD: 1096 This problem could be fixed by including both a sequence number that stays 1097 the same for retransmissions and a timestamp for RTT estimation.] 1099 Systems implementing RTSP MUST support carrying RTSP over TCP and MAY 1100 support UDP. The default port for the RTSP server is 554 for both UDP and 1101 TCP. 1103 A number of RTSP packets destined for the same control end point may be 1104 packed into a single lower-layer PDU or encapsulated into a TCP stream. 1105 RTSP data MAY be interleaved with RTP and RTCP packets. Unlike HTTP, an 1106 RTSP method header MUST contain a Content-Length whenever that method 1107 contains a payload. Otherwise, an RTSP packet is terminated with an empty 1108 line immediately following the method header. 1110 9 Method Definitions 1112 The method token indicates the method to be performed on the resource 1113 identified by the Request-URI. The method is case-sensitive. New methods 1114 may be defined in the future. Method names may not start with a $ character 1115 (decimal 24) and must be a token. 1117 method direction requirement 1118 GET C->S recommended 1119 SETUP C->S recommended 1120 PLAY C->S required 1121 PAUSE C->S recommended 1122 CLOSE C->S required 1123 REDIRECT S->C optional 1124 SESSION S->C optional 1125 RECORD C->S optional 1126 BYE C->S required? 1127 SET_PARAMETER C->S, S->C optional 1128 GET_PARAMETER C->S, S->C optional 1130 Table 3: Overview of RTSP methods 1132 HS: PAUSE is recommend, but not required in that a fully 1133 functional server can be built that does not support this method, 1134 for example, for live feeds. Similarly, SETUP is not needed for a 1135 server that only handles multicast events with transport 1136 parameters set outside of RTSP. GET and BYE are controversial. 1138 9.1 HELLO 1140 RTSP sessions MAY be initiated by a HELLO message. The request URI is "*" 1141 to indicate that the request pertains to the session itself. The primary 1142 use of the HELLO message is to verify the identity of the sender to the 1143 receiver; both sides must authorize one another to enable full access to 1144 server resources. Unauthorized clients may be disconnected or restricted to 1145 a subset of server resources. 1147 In addition, if the optional Require header is present, option tags within 1148 the header indicate features needed by the requestor that are not required 1149 at the version level of the protocol. 1151 Example 1: 1153 C->S: HELLO * RTSP/1.0 1 1154 Require: implicit-play, record-feature 1155 Transport-Require: switch-to-udp-control, gzipped-messages 1157 Note that these are fictional features (though we may want to make them 1158 real one day). 1160 Example 2 (using RFC2069-style authentication only as an example): 1162 S->C: HELLO * RTSP/1.0 1 1163 Authenticate: Digest realm="testrealm@host.com", 1164 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 1165 opaque="5ccc069c403ebaf9f0171e9517f40e41" 1167 Response: 1169 Possible errors: 401, Parameter Not Understood 1171 Examples: 1173 S->C: RTSP/1.0 200 1 OK 1174 Date: 23 Jan 1997 15:35:06 GMT 1175 Nack-Transport-Require: switch-to-udp-control 1177 Note that these are fictional features (though we may want to make them 1178 real one day). 1180 Example 2 (using RFC2069-style authentication only as an example): 1182 C->S: RTSP/1.0 401 1 Unauthorized 1183 Authorization: Digest username="Mufasa", 1184 realm="testrealm@host.com", 1185 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 1186 uri="/dir/index.html", 1187 response="e966c932a9242554e42c8ee200cec7f6", 1188 opaque="5ccc069c403ebaf9f0171e9517f40e41" 1190 HS: I consider HELLO superfluous, not fully specified and just 1191 complicating client and server. It is also not clear how this is 1192 supposed to work when a client connects to the server, since it 1193 can't know ahead of time whether the server will issus a HELLO 1194 request. So it may connect, issue a SETUP, be refused and then 1195 somehow guess that it's supposed to wait for HELLO. 1196 Authentication of the client can be readily achieved by standard 1197 HTTP-like methods. On either retrieving the session description 1198 or the first SETUP, the server would refuse with 401, supply the 1199 authentication methods (and nonces) it is willing to accept and 1200 wait for the request to be re-issued with proper authentication. 1201 As with standard web browser, a client can cache the 1202 authentication message for efficiency. 1204 Similarly, the client can ask the server to authenticate itself 1205 with the first request. 1207 Feature announcement can be done using standard HTTP mechanism, 1208 with a well-defined registration mechanism for feature names. 1210 RL: HELLO offers the opportunity to negotiate server features 1211 prior to actually needing them. A client may wish to poll a 1212 server for its features without actually causing any action to 1213 occur, and HELLO offers that opportunity. 1215 9.2 GET 1217 The GET method retrieves a session description from a server. It may use 1218 the Accept header to specify the session description formats that the 1219 client understands. 1221 If the media server has previously been invited to a conference by the 1222 client, the GET request SHOULD contain the Conference header field. If the 1223 GET request contains a conference identifier, the media server MAY locate 1224 the conference description and use the multicast addresses and port numbers 1225 supplied in that description. The media server SHOULD only offer media 1226 types corresponding to the media types currently active within the 1227 conference. If the media server has no local reference to this conference, 1228 it returns status code 452. 1230 The conference invitation should also contain an indication whether the 1231 media server is expected to receive or generate media, or both. (A VCR-like 1232 device would support both directions.) If the invitation does not contain 1233 an indication of the operations to be performed, the media server should 1234 accept and then reject inappropriate operations. 1236 The server responds with a description of the requested resource. 1238 Example: 1240 C->S: GET rtsp://server.example.com/fizzle/foo RTSP/1.0 312 1241 Accept: application/sdp, application/sdf, application/mheg 1242 Bandwidth: 4000 1244 S->C: RTSP/1.0 200 312 OK 1245 Date: 23 Jan 1997 15:35:06 GMT 1246 Content-Type: application/sdp 1247 Content-Length: 376 1249 v=0 1250 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 1251 s=SDP Seminar 1252 i=A Seminar on the session description protocol 1253 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 1254 e=mjh@isi.edu (Mark Handley) 1255 c=IN IP4 224.2.17.12/127 1256 t=2873397496 2873404696 1257 a=recvonly 1258 m=audio 3456 RTP/AVP 0 1259 m=video 2232 RTP/AVP 31 1260 m=whiteboard 32416 UDP WB 1261 a=orient:portrait 1263 or 1265 S->C: RTSP/1.0 200 312 OK 1266 Date: 23 Jan 1997 15:35:06 GMT 1267 Content-Type: application/x-rtsp-mh 1268 Content-Length: 2782 1270 <2782 octets of data containing stream descriptions and 1271 headers for the requested presentation> 1273 The authors disagree amongst themselves as to whether having an 1274 GET method within RTSP is appropriate. The alternative would be 1275 that the stream header would be done as an HTTP GET, and then 1276 RTSP would be used for SETUP, PLAY, etc. RL believes there are a 1277 number of reasons why a GET method is appropriate within RTSP: 1279 * An RTSP GET is a request for header information, while an 1280 HTTP GET is a request for the entire file. For instance, an 1281 RTSP GET on a Quicktime file with the name foo.mov would 1282 mean "please send me the header and packetization 1283 information for foo.mov", whereas an HTTP GET for that file 1284 would mean "please send me foo.mov". 1285 * Assuming the client only has an URL to a resource, it is 1286 highly desireable to get to the point where the client is 1287 actually receiving data all over one connection. Though this 1288 would be possible if one assumed that one can multiplex RTSP 1289 and HTTP on the same connection, there is a question of how 1290 much of a web server would have to be supported in order to 1291 fulfill this simpler requirement. 1292 * Since the RTSP GET contains information such as codec, 1293 packetization, total size, and whether the clip is live or 1294 stored, it is important to insure integrity between the 1295 session description and the media it represents. This 1296 information may be cached by HTTP proxies, but it would be 1297 needed by caching RTSP proxies. 1299 RL and AR feel that the scope and applicability of this message 1300 should be limited, and therefore, it may be appropriate to come 1301 up with another name for this message. 1303 HS believes that this only works if GET is required. Otherwise, 1304 the client has no way of knowing whether to first send a GET or 1305 SETUP. The easy alternative is to have any further descriptive 1306 information that is necessary encoded in the session description. 1307 Thus, the naming does not matter; the resource description can 1308 either have a separate name or the same name if the server can 1309 distinguish variants based on the requested type, as modern web 1310 servers can. (A single URL can return different objects depending 1311 on the content of the Accept fields.) It appears likely that the 1312 RTSP GET will over time acquire all the functionality of the HTTP 1313 GET and thus lead to unnecessary duplication. If the description 1314 is lengthy, the ability to use HTTP caches is likely to 1315 compensate for any additional latency due to having to open two 1316 streams. Also, note that relying on HTTP get does not mean that 1317 this has to be a separate server. 1319 9.3 SETUP 1321 The SETUP request for a URI specifies the transport mechanism to be used 1322 for the streamed media. Note that SETUP makes sense only for an individual 1323 media stream, rather than an aggregate. A client can issue a SETUP request 1324 for a stream that is already playing to change transport parameters. 1326 If the optional Require header is present, option tags within the header 1327 indicate features needed by the requestor that are not required at the 1328 version level of the protocol. The Transport-Require header is used to 1329 indicate proxy-sensitive features that MUST be stripped by the proxy to the 1330 server if not supported. Furthermore, any Transport-Require header features 1331 that are not supported by the proxy MUST be negatively acknowledged by the 1332 proxy to the client if not supported. 1334 HS: In my opinion, the Require header should be replaced by PEP 1335 since PEP is standards-track, has more functionality and somebody 1336 already did the work. 1338 The Transport header specifies the transports acceptable to the client for 1339 data transmission; the response will contain the transport selected by the 1340 server. 1342 C->S: SETUP foo/bar/baz.rm RTSP/1.0 302 1343 Transport: rtp/udp;port=458 1345 S->C: RTSP/1.0 200 302 OK 1346 Date: 23 Jan 1997 15:35:06 GMT 1347 Transport: cush/udp;port=458 1349 9.4 PLAY 1351 The PLAY method tells the server to start sending data via the mechanism 1352 specified in SETUP. A client MUST NOT issue a PLAY request until any 1353 outstanding SETUP request have been acknowledged as successful. 1355 A PLAY request without a Range header is legal. It starts playing a stream 1356 from the beginning unless the stream has been paused. If a stream has been 1357 paused via PAUSE, stream delivery resumes at the pause point. If a stream 1358 is playing, such a PLAY request causes no further action and can be used by 1359 the client to test server liveness. 1361 The following example plays the whole session starting at SMPTE time code 1362 0:10:20 until the end of the clip. 1364 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833 1365 Range: smpte=0:10:20- 1367 For playing back a recording of a live event, it may be desirable to use 1368 clock units: 1370 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835 1371 Range: clock=19961108T142300Z-19961108T143520Z 1373 S->C: RTSP/1.0 200 833 OK 1374 Date: 23 Jan 1997 15:35:06 GMT 1376 A media server only supporting playback MUST support the smpte format and 1377 MAY support the clock format. 1379 RL says: We had considered optionally overloading PLAY with SETUP 1380 information. This would have potentially allowed a case where one 1381 could implement a minimal RTSP server that only handles the PLAY 1382 command. However, we decided that supporting that minimal of a 1383 server was problematic for a couple of reasons: 1385 * We must be able to negotiate the transport (i.e. have server 1386 acknowledgment) prior to actually needing to deal with the 1387 data. We don't want to have a server start spewing packets 1388 at us before we are ready to deal with them. The server 1389 acknowledgment with setup information MUST arrive before the 1390 first packet. 1391 * We need make sure that we aren't dealing with an allocation 1392 method every time we are dealing with PLAY. We anticipate 1393 the potential of dealing with PLAY frequently when a client 1394 chooses to issue several seeks, and so simplifying this 1395 message is imperative. 1397 HS says: PLAY without SETUP is useful and possible, in particular 1398 if the session description contains all necessary information, 1399 without options. The client knows whether it needs to configure 1400 transport parameters or not. For multicast delivery, for example, 1401 it likely would not have to set additional parameters. I doubt 1402 that allowing one additional parameter is going to greatly 1403 complicate or slow down a server. 1405 9.5 PAUSE 1407 The PAUSE request causes the stream delivery to be interrupted (halted) 1408 temporarily. If the request URL names a track, only playback and recording 1409 of that track is halted. If the request URL names a presentation, delivery 1410 of all currently active tracks is halted. After resuming playback or 1411 recording, synchronization of the tracks MUST be maintained. Any server 1412 resources are kept. 1414 Example: 1416 C->S: PAUSE /fizzle/foo RTSP/1.0 834 1418 S->C: RTSP/1.0 200 834 OK 1419 Date: 23 Jan 1997 15:35:06 GMT 1421 9.6 CLOSE 1423 Stop the stream delivery for the given URI, freeing the resources 1424 associated with it. If the URI is the root node for this session, any 1425 session identifier associated with the session is no longer valid. Unless 1426 all transport parameters are defined by the session description, a SETUP 1427 request has to be issued before the session can be played again. 1429 Example: 1431 C->S: CLOSE /fizzle/foo RTSP/1.0 892 1433 S->C: RTSP/1.0 200 892 OK 1435 9.7 BYE 1437 Terminate the session. 1439 Example: 1441 C->S: BYE /movie RTSP/1.0 894 1443 S->C: RTSP/1.0 200 894 OK 1444 Date: 23 Jan 1997 15:35:06 GMT 1446 HS: I believe BYE to be unnecessary since CLOSE already frees 1447 resources and session descriptor. 1449 9.8 GET_PARAMETER 1451 The requests retrieves the value value of a parameter of a session 1452 component specified in the URI. Multiple parameters can be requested in the 1453 message body using the content type text/rtsp-parameters. Note that 1454 parameters include server and client statistics. [HS: registry of parameter 1455 names for statistics and other purposes, possibly using the HTTP feature 1456 registration mechanism.] A GET_PARAMETER with no entity body may be used to 1457 test client or server liveness (``ping''). 1459 Example: 1461 S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431 1462 Content-Type: text/rtsp-parameters 1463 Session: 1234 1464 Content-Length: 15 1466 packets_received 1467 jitter 1469 C->S: RTSP/1.0 200 431 OK 1470 Content-Length: 46 1471 Content-Type: text/rtsp-parameters 1473 packets_received: 10 1474 jitter: 0.3838 1476 9.9 SET_PARAMETER 1478 This method requests to set the value of a parameter for a session 1479 component specified by the URI. 1481 A request SHOULD only contain a single parameter to allow the client to 1482 determine why a particular request failed. A server MUST allow a parameter 1483 to be set repeatedly to the same value, but it MAY disallow changing 1484 parameter values. 1486 Note: transport parameters for the media stream MUST only be set with the 1487 SETUP command. 1489 Restricting setting transport parameters to SETUP is for the 1490 benefit of firewalls. 1492 The parameters are split in a fine-grained fashion so that there 1493 can be more meaningful error indications. However, it may make 1494 sense to allow the setting of several parameters if an atomic 1495 setting is desirable. Imagine device control where the client 1496 does not want the camera to pan unless it can also tilt to the 1497 right angle at the same time. 1499 A SET_PARAMETER request without parameters can be used as a way to detect 1500 client or server liveness. 1502 Example: 1504 C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421 1505 Content-type: text/rtsp-parameters 1507 fooparam: foostuff 1508 barparam: barstuff 1510 S->C: RTSP/1.0 450 421 Invalid Parameter 1511 Content-Length: 6 1513 barparam 1515 9.10 REDIRECT 1517 A redirect request informs the client that it must connect to another 1518 server location. It contains the mandatory header Location, which indicates 1519 that the client should issue a GET for that URL. It may contain the 1520 parameter Range, which indicates when the redirection takes effect. 1522 Mandatory header: Location [XXX: add this to table if accepted] 1524 Example: This request redirects traffic for this URI to the new server at 1525 the given play time: 1527 S->C: REDIRECT /fizzle/foo RTSP/1.0 732 1528 Location: rtsp://bigserver.com:8001 1529 Range: clock=19960213T143205Z- 1531 9.11 SESSION 1533 This request is used by a media server to send new media information to the 1534 client. If a new media type is added to a session (e.g., during a live 1535 event), the whole session description should be sent again, rather than 1536 just the additional components. 1538 This allows the deletion of session components. 1540 Example: 1542 S->C: SESSION /twister RTSP/1.0 902 1543 Session: 1234 1544 Content-Type: application/sdp 1545 Session Description 1547 9.12 RECORD 1549 This method initiates recording a range of media data according to the 1550 session description. The timestamp reflects start and end time (UTC). If no 1551 time range is given, use the start or end time provided in the session 1552 description. If the session has already started, commence recording 1553 immediately. The Conference header is mandatory. 1555 A media server supporting recording of live events MUST support the clock 1556 range format; the smpte format does not make sense. 1558 In this example, the media server was previously invited to the conference 1559 indicated. 1561 C->S: RECORD /meeting/audio.en RTSP/1.0 954 1562 Session: 1234 1563 Conference: 128.16.64.19/32492374 1565 9.13 Embedded Binary Data 1567 Binary packets such as RTP data are encapsulated by an ASCII dollar sign 1568 (24 decimal), followed by a one-byte session identifier, followed by the 1569 length of the encapsulated binary data as a binary, two-byte integer in 1570 network byte order. The binary data follows immediately afterwards, without 1571 a CRLF. 1573 Status Codes Definitions 1575 Where applicable, HTTP status [H10] codes are re-used. Status codes that 1576 have the same meaning are not repeated here. See Tables 1 and 2 for a 1577 listing of which status codes may be returned by which request. 1579 10.1 Client Error 4xx 1581 10.1.1 451 Parameter Not Understood 1583 The recipient of the request does not support one or more parameters 1584 contained in the request. 1586 10.1.2 452 Conference Not Found 1588 The conference indicated by a Conference header field is unknown to the 1589 media server. 1591 10.1.3 453 Not Enough Bandwidth 1593 The request was refused since there was insufficient bandwidth. This may, 1594 for example, be the result of a resource reservation failure. 1596 10.1.4 45x Session Not Found 1598 10.1.5 45x Method Not Valid in This State 1600 10.1.6 45x Header Field Not Valid for Resource 1602 The server could not act on a required request header. For example, if PLAY 1603 contains the Range header field, but the stream does not allow seeking. 1605 10.1.7 45x Invalid Range 1607 The Range value given is out of bounds, e.g., beyond the end of the 1608 presentation. 1610 10.1.8 45x Parameter Is Read-Only 1612 The parameter to be set by SET_PARAMETER can only be read, but not 1613 modified. 1615 11 Header Field Definitions 1617 HTTP/1.1 or other, non-standard header fields not listed here currently 1618 have no well-defined meaning and SHOULD be ignored by the recipient. 1620 Tables 4 and 5 summarize the header fields used by RTSP. Type ``R'' 1621 designates requests, type ``r'' responses. Fields marked with ``x'' MUST be 1622 implemented by the recipient. If the field content does not apply to the 1623 particular resource, the server MUST return status 45x (Header Field Not 1624 Valid for Resource). 1626 type HELLO GET SETUP PLAY RECORD PAUSE 1627 Accept R x 1628 Accept-Encoding R x 1629 Accept-Language R x o o 1630 Authorization R o o o o o o 1631 Bandwidth R o 1632 Blocksize R o 1633 Conference R o o ? ? ? 1634 Connection Rr x x x x x 1635 Content-Encoding Rr x 1636 Content-Length Rr x 1637 Content-Type Rr x 1638 Date Rr o o o o o o 1639 If-Modified-Since R o 1640 Last-Modified r o 1641 Public r o o o o o o 1642 Range R x x 1643 Referer R o o o o o o 1644 Require R x o x o o o 1645 Retry-After r o o o o o o 1646 Session Rr x x x x 1647 Server r o o o o o o 1648 Speed Rr o o 1649 Transport Rr x 1650 Transport-Require R x o x o o o 1651 User-Agent R o o o o o o 1652 Via Rr o o o o o o 1653 WWW-Authenticate r o o o o o o 1655 Table 4: Overview of RTSP header fields for GET, SETUP, PLAY, RECORD and 1656 PAUSE 1657 CLOSE REDIRECT GET_PARAMETER SET_PARAMETER 1658 Accept 1659 Accept-Encoding 1660 Accept-Language 1661 Authorization o o o o 1662 Bandwidth 1663 Blocksize 1664 Conference 1665 Connection x x x x 1666 Content-Encoding x x x x 1667 Content-Length x x x x 1668 Content-Type x x x x 1669 Date o o o o 1670 If-Modified-Since 1671 Last-Modified 1672 Public o o o o 1673 Range 1674 Referer o o o o 1675 Retry-After o o o o 1676 Session x x x x 1677 Server o o o o 1678 Speed 1679 Transport 1680 User-Agent o o o o 1681 Via o o o o 1682 WWW-Authenticate o o o o 1684 Table 5: Overview of RTSP header fields for PAUSE, CLOSE, GET_PARAMETER and 1685 SET_PARAMETER 1687 11.1 Accept 1689 The Accept request-header field can be used to specify certain session 1690 description content types which are acceptable for the response. 1692 The ``level'' parameter for session descriptions is properly 1693 defined as part of the MIME type registration, not here. 1695 See [H14.1] for syntax. 1697 Example of use: 1699 Accept: application/sdf, application/sdp;level=2 1701 11.2 Accept-Encoding 1703 See [H14.3] 1705 11.3 Accept-Language 1707 See [H14.4]. Note that the language specified applies to the session 1708 description, not the media content. 1710 11.4 Allow 1712 The Allow response header field lists the methods supported by the resource 1713 identified by the request-URI. The purpose of this field is to strictly 1714 inform the recipient of valid methods associated with the resource. An 1715 Allow header field must be present in a 405 (Method not allowed) response. 1717 Example of use: 1719 Allow: SETUP, PLAY, RECORD, SET_PARAMETER 1721 11.5 Authorization 1723 See [H14.8] 1725 11.6 Bandwidth 1727 The Bandwidth request header field describes the estimated bandwidth 1728 available to the client, expressed as a positive integer and measured in 1729 bits per second. 1731 Bandwidth = "Bandwidth" ":" 1*DIGIT 1733 Example: 1735 Bandwidth: 4000 1737 11.7 Blocksize 1739 This request header field is sent from the client to the media server 1740 asking the server for a particular media packet size. This packet size does 1741 not include lower-layer headers such as IP, UDP, or RTP. The server is free 1742 to use a blocksize which is lower than the one requested. The server MAY 1743 truncate this packet size to the closest multiple of the minimum 1744 media-specific block size or overrides it with the media specific size if 1745 necessary. The block size is a strictly positive decimal number and 1746 measured in octets. The server only returns an error (416) if the value is 1747 syntactically invalid. 1749 11.8 Conference 1751 This request header field establishes a logical connection between a 1752 conference, established using non-RTSP means, and an RTSP stream. 1754 Conference = "Conference" ":" conference-id 1756 Example: 1758 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr 1760 11.9 Content-Encoding 1762 See [H14.12] 1764 11.10 Content-Length 1766 This field contains the length of the content of the method (i.e. after the 1767 double CRLF following the last header). Unlike HTTP, it MUST be included in 1768 all messages that carry content beyond the header portion of the message. 1769 It is interpreted according to [H14.14]. 1771 11.11 Content-Type 1773 See [H14.18]. Note that the content types suitable for RTSP are likely to 1774 be restricted in practice to session descriptions and parameter-value 1775 types. 1777 11.12 Date 1779 See [H14.19]. 1781 11.13 If-Modified-Since 1783 See [H14.24]. If the request URL refers to a presentation rather than a 1784 track, the server is to return the presentation if any of the track has 1785 been modified since the time stated in the header field. 1787 11.14 Last-modified 1789 The Last-Modified entity-header field indicates the date and time at which 1790 the origin server believes the variant was last modified. See [H14.29]. If 1791 the request URI refers to an aggregate, the field indicates the last 1792 modification time across all leave nodes of that aggregate. 1794 11.15 Location 1796 See [H14.30]. 1798 11.16 Range 1800 This request header field specifies a range of time. The range can be 1801 specified in a number of units. This specification defines the smpte (see 1802 Section 3.4) and clock (see Section 3.5) range units. Within RTSP, byte 1803 ranges [H14.36.1] are not meaningful and MUST NOT be used. 1805 Range = "Range" ":" 1#ranges-specifier 1807 ranges-specifier = utc-range | smpte-range 1809 Example: 1811 Range: clock=19960213T143205Z- 1813 11.17 Require 1815 The Require header is used by clients to query the server about features 1816 that it may or may not support. The server MUST respond to this header by 1817 negatively acknowledging those features which are NOT supported in the 1818 Unsupported header. 1820 HS: Naming of features - yet another name space. I believe this 1821 header field to be redundant. PEP should be used instead. 1823 For example 1825 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 302 1826 Require: funky-feature 1827 Funky-Parameter: funkystuff 1829 S->C: RTSP/1.0 200 506 Option not supported 1830 Unsupported: funky-feature 1832 C->S: SETUP /foo/bar/baz.rm RTSP/1.0 303 1834 S->C: RTSP/1.0 200 303 OK 1836 This is to make sure that the client-server interaction will proceed 1837 optimally when all options are understood by both sides, and only slow down 1838 if options aren't understood (as in the case above). For a well-matched 1839 client-server pair, the interaction proceeds quickly, saving a round-trip 1840 often required by negotiation mechanisms. In addition, it also removes 1841 state ambiguity when the client requires features that the server doesn't 1842 understand. 1844 11.18 Unsupported 1846 See Section 11.17 for a usage example. 1848 HS: same caveat as for Require applies. 1850 11.19 Nack-Transport-Require 1852 Negative acknowledgement of features not supported by the server. If there 1853 is a proxy on the path between the client and the server, the proxy MUST 1854 insert a message reply with an error message 506 (Feature not supported). 1856 HS: Same caveat as for Require applies. 1858 11.20 Transport-Require 1860 The Transport-Require header is used to indicate proxy-sensitive features 1861 that MUST be stripped by the proxy to the server if not supported. 1862 Furthermore, any Transport-Require header features that are not supported 1863 by the proxy MUST be negatively acknowledged by the proxy to the client if 1864 not supported. 1866 See Section 11.17 for more details on the mechanics of this message and a 1867 usage example. 1869 HS: Same caveat as for Require applies. 1871 11.21 Retry-After 1873 See [H14.38]. 1875 11.22 Speed 1877 This request header fields parameter requests the server to deliver data to 1878 the client at a particular speed, contingent on the server's ability and 1879 desire to serve the media stream at the given speed. Implementation by the 1880 server is OPTIONAL. The default is the bit rate of the stream. 1882 The parameter value is expressed as a decimal ratio, e.g., a value of 2.0 1883 indicates that data is to be delivered twice as fast as normal. A speed of 1884 zero is invalid. A negative value indicates that the stream is to be played 1885 back in reverse direction. 1887 speed = "Speed" ":" ["-"]1*DIGIT [ "." *DIGIT ] 1889 Example: 1891 Speed: 2.5 1893 11.23 Server 1895 See [H14.39] 1897 11.24 Session 1899 This request and response header field identifies a session, started by the 1900 media server in a SETUP or PLAY response and concluded by CLOSE on the 1901 session URL (presentation). The session identifier is chosen by the media 1902 server and has the same syntax as a conference identifier. Once a client 1903 receives a Session identifier, it MUST return it for any request related to 1904 that session. 1906 HS: This may be redundant with the standards-track HTTP state 1907 maintenance mechanism [1]. The equivalent way of doing this would 1908 be for the server to send Set-Cookie: Session="123"; Version=1; 1909 Path = "/twister" and for the client to return later Cookie: 1910 Session = "123"; $Version=1; $Path = "/twister". In the response 1911 to the CLOSE message, the server would simply send Set-Cookie: 1912 Session="123"; Version=1; Max-Age=0 to get rid of the cookie on 1913 the client side. Cookies also have a time-out, so that a server 1914 may limit the lifetime of a session at will. Unlike a web 1915 browser, a client would not store these states on disk. 1917 11.25 Transport 1919 This request header indicates which transport protocol is to be used and 1920 configures its parameters such as multicast, compression, multicast 1921 time-to-live and destination port for a single stream. It sets those values 1922 not already determined by a session description. In some cases, the session 1923 description contains all necessary information. In those cases, a Transport 1924 header field (and the SETUP request containing it) are not needed. 1926 'Interleaved' implies mixing the media stream with the control stream, in 1927 whatever protocol is being used by the control stream. Currently, the 1928 next-layer protocols RTP is defined. Parameters may be added to each 1929 protocol, separated by a semicolon. For RTP, the boolean parameter 1930 compressed is defined, indicating compressed RTP according to RFC XXXX. For 1931 multicast UDP, the integer parameter ttl defines the time-to-live value to 1932 be used. For UDP and TCP, the parameter port defines the port data is to be 1933 sent to. 1935 The SSRC parameter indicates the RTP SSRC value that should be (request)i 1936 or will be (response) used by the media server. This parameter is only 1937 valid for unicast transmission. It identifies the synchronization source to 1938 be associated with the media stream. 1940 The Transport header MAY also be used to change certain transport 1941 parameters. A server MAY refuse to change parameters of an existing stream. 1943 The server MAY return a Transport response header in the response to 1944 indicate the values actually chosen. 1946 A Transport request header field may contain a list of transport options 1947 acceptable to the client. In that case, the server MUST return a single 1948 option which was actually chosen. The Transport header field makes sense 1949 only for an individual media stream, not a session. 1951 Transport = "Transport" ":" 1952 1#transport-protocol/upper-layer *parameter 1953 transport-protocol = "UDP" | "TCP" 1954 upper-layer = "RTP" 1955 parameters = ";" "multicast" | 1956 ";" "compressed" | 1957 ";" "interleaved" | 1958 ";" "ttl" "=" ttl | 1959 ";" "port" "=" port | 1960 ";" "ssrc" "=" ssrc 1961 ttl = 1*3(DIGIT) 1962 port = 1*5(DIGIT) 1963 ssrc = 8*8(HEX) 1965 Example: 1967 Transport: udp/rtp;compressed;ttl=127;port=3456 1969 11.26 User-Agent 1971 See [H14.42] 1973 11.27 Via 1975 See [H14.44]. 1977 11.28 WWW-Authenticate 1979 See [H14.46]. 1981 12 Caching 1983 In HTTP, response-request pairs are cached. RTSP differs significantly in 1984 that respect. Typically, responses are not cachable (except maybe for the 1985 GET response), rather it is desirable for the media data (that is typically 1986 delivered outside of RTSP) to be cached. Since the responses for anything 1987 but GET and GET_PARAMETER do not return any data, caching is not an issue 1988 for these requests. 1990 HS: A proxy cache for RTSP would look not much different from an HTTP 1991 cache. To the client, the proxy cache would appear like a regular media 1992 server, to the media server like a client. Just like an HTTP cache has to 1993 store the content type, content language, etc. for the objects it caches, a 1994 media cache has to store the session description. Typically, a cache would 1995 eliminate all transport-references (that is, multicast information) from 1996 the session description, since these are independent of the data delivery 1997 from the cache to the client. Information on the encodings remains the 1998 same. If the cache is able to translate the cached media data, it would 1999 create a new session description with all the encoding possibilities it can 2000 offer. 2002 13 Examples 2004 To emphasize that RTSP is independent of the session description format, 2005 the following examples use a fictional session description language which 2006 is chosen to be sufficiently self-explanatory. 2008 13.1 Media on Demand (Unicast) 2010 Client C requests a movie from media servers A ( audio.content.com) and V 2011 (video.content.com). The media description is stored on a web server W. 2012 This, however, is transparent to the client. The client is only interested 2013 in the last part of the movie. The server requires authentication for this 2014 movie. The audio track can be dynamically switched between between two sets 2015 of encodings. The URL with scheme rtpsu indicates the media servers want to 2016 use UDP for exchanging RTSP messages. 2018 C->W: GET /twister HTTP/1.1 2019 Host: www.content.com 2020 Accept: application/sdf; application/sdp 2022 W->C: 200 OK 2023 Content-Type: application/sdf 2024 (session 2025 (all 2026 (media (t audio) (oneof 2027 ((e PCMU/8000/1 89 DVI4/8000/1 90) (id lofi)) 2028 ((e DVI4/16000/2 90 DVI4/16000/2 91) (id hifi)) 2029 ) 2030 (language en) 2031 (id rtspu://audio.content.com/twister/audio.en) 2032 ) 2033 (media (t video) (e JPEG) 2034 (id rtspu://video.content.com/twister/video) 2035 ) 2036 ) 2037 ) 2039 C->A: SETUP rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 1 2040 Transport: rtp/udp;compression;port=3056 2042 A->C: RTSP/1.0 200 1 OK 2043 Session: 1234 2045 C->V: SETUP rtsp://video.content.com/twister/video RTSP/1.0 1 2046 Transport: rtp/udp;compression;port=3058 2048 V->C: RTSP/1.0 200 1 OK 2049 Session: 1235 2051 C->V: PLAY rtsp://video.content.com/twister/video RTSP/1.0 2 2052 Session: 1235 2053 Range: smpte 0:10:00- 2055 V->C: RTSP/1.0 200 2 OK 2057 C->A: PLAY rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 2 2058 Session: 1234 2059 Range: smpte 0:10:00- 2061 A->C: 200 2 OK 2063 C->A: CLOSE rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 3 2064 Session: 1234 2066 A->C: 200 3 OK 2068 C->V: CLOSE rtsp://video.content.com/twister/video RTSP/1.0 3 2069 Session: 1235 2071 V->C: 200 3 OK 2073 Even though the audio and video track are on two different servers, may 2074 start at slightly different times and may drift with respect to each other, 2075 the client can synchronize the two using standard RTP methods, in 2076 particular the time scale contained in the RTCP sender reports. 2078 13.2 Live Media Event Using Multicast 2080 The media server M chooses the multicast address and port. Here, we assume 2081 that the web server only contains a pointer to the full description, while 2082 the media server M maintains the full description. During the session, a 2083 new subtitling stream is added. 2085 C->W: GET /concert HTTP/1.1 2086 Host: www.content.com 2088 W->C: HTTP/1.1 200 OK 2089 Content-Type: application/sdf 2091 (session 2092 (id rtsp://live.content.com/concert) 2093 ) 2095 C->M: GET rtsp://live.content.com/concert RTSP/1.0 1 2097 M->C: RTSP/1.0 200 1 OK 2098 Content-Type: application/sdf 2100 (session (all 2101 (media (t audio) (id music) (a IP4 224.2.0.1) (p 3456)) 2102 )) 2104 C->M: PLAY rtsp://live.content.com/concert/music RTSP/1.0 2 2105 Range: smpte 1:12:0 2107 M->C: RTSP/1.0 405 2 No positioning possible 2109 M->C: SESSION concert RTSP/1.0 2110 Content-Type: application/sdf 2112 (session (all 2113 (media (t audio) (id music)) 2114 (media (t text) (id lyrics)) 2115 )) 2117 C->M: PLAY rtsp://live.content.com/concert/lyrics RTSP/1.0 2119 Since the session description already contains the necessary address 2120 information, the client does not set the transport address. The attempt to 2121 position the stream fails since this is a live event. 2123 13.3 Playing media into an existing session 2125 A conference participant C wants to have the media server M play back a 2126 demo tape into an existing conference. When retrieving the session 2127 description, C indicates to the media server that the network addresses and 2128 encryption keys are already given by the conference, so they should not be 2129 chosen by the server. The example omits the simple ACK responses. 2131 C->M: GET /demo HTTP/1.1 2132 Host: www.content.com 2133 Accept: application/sdf, application/sdp 2135 M->C: HTTP/1.1 200 1 OK 2136 Content-type: application/sdf 2138 (session 2139 (id 548) 2140 (media (t audio) (id sound) 2141 ) 2143 C->M: SETUP rtsp://server.content.com/demo/548/sound RTSP/1.0 2 2144 Conference: 218kadjk 2146 13.4 Recording 2148 Conference participant C asks the media server M to record a session. If 2149 the session description contains any alternatives, the server records them 2150 all. 2152 C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 89 2153 Content-Type: application/sdp 2155 v=0 2156 s=Mbone Audio 2157 i=Discussion of Mbone Engineering Issues 2159 M->C: 415 89 Unsupported Media Type 2160 Accept: application/sdf 2162 C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 90 2163 Content-Type: application/sdf 2165 M->C: 200 90 OK 2167 C->M: RECORD rtsp://server.content.com/meeting RTSP/1.0 91 2168 Range: clock 19961110T1925-19961110T2015 2170 14 Syntax 2172 The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used 2173 in RFC 2068 (HTTP/1.1). 2175 14.1 Base Syntax 2177 OCTET = 2178 CHAR = 2179 UPALPHA = 2180 LOALPHA = 2181 ALPHA = UPALPHA | LOALPHA 2182 DIGIT = 2183 CTL = 2185 CR = 2186 LF = 2187 SP = 2188 HT = 2189 <"> = 2190 CRLF = CR LF 2191 LWS = [CRLF] 1*( SP | HT ) 2192 TEXT = 2193 tspecials = "(" | ")" | "<" | ">" | "@" 2194 | "," | ";" | ":" | "\" | <"> 2195 | "/" | "[" | "]" | "?" | "=" 2196 | "{" | "}" | SP | HT 2197 token = 1* 2198 quoted-string = ( <"> *(qdtext) <"> ) 2199 qdtext = > 2200 quoted-pair = "\" CHAR 2202 message-header = field-name ":" [ field-value ] CRLF 2203 field-name = token 2204 field-value = *( field-content | LWS ) 2205 field-content = 2209 14.2 Internet Media Type Syntax 2211 media-type = type "/" subtype *( ";" parameter ) 2212 type = token 2213 subtype = token 2214 parameter = attribute "=" value 2215 attribute = token 2216 value = token | quoted-string 2218 14.3 Universal Resource Identifier Syntax 2220 uri = ( absoluteURI | relativeURI ) [ "#" fragment ] 2221 absoluteURI = scheme ":" *( uchar | reserved ) 2222 relativeURI = net-path | abs-path | rel-path 2223 net-path = "//" net-loc [ abs-path ] 2224 abs-path = "/" rel-path 2225 rel-path = [ path ] [ ";" params ] [ "?" query ] 2226 path = fsegment *( "/" segment ) 2227 fsegment = 1*pchar 2228 segment = *pchar 2229 params = param *( ";" param ) 2230 param = *( pchar | "/" ) 2231 scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) 2232 net_loc = *( pchar | ";" | "?" ) 2233 query = *( uchar | reserved ) 2234 fragment = *( uchar | reserved ) 2235 pchar = uchar | ":" | "@" | "&" | "=" | "+" 2236 uchar = unreserved | escape 2237 unreserved = ALPHA | DIGIT | safe | extra | national 2238 escape = "%" HEX HEX 2239 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" 2240 extra = "!" | "*" | "'" | "(" | ")" | "," 2241 safe = "$" | "-" | "_" | "." 2242 unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" 2243 national = 2246 14.4 RTSP-specific syntax 2248 setup-response = response-line 2249 date-type-header 2250 *( nack-require-header 2251 | nack-require-transport-header ) 2252 CRLF 2254 redirect-response = response-line 2255 date-type-header 2257 session-response = response-line 2258 date-type-header 2260 play-response = response-line 2261 date-type-header 2263 pause-response = response-line 2264 date-type-header 2266 message-body = *OCTET 2268 accept-header = "Accept" ":" 1#media-type 2269 allow-header = "Allow" ":" 1#method 2270 blocksize-header = "Blocksize" ":" 1*DIGIT 2271 content-length-header = "Content-Length" ":" 1*DIGIT 2272 content-type-header = "Content-Type" ":" media-type 2273 date-type-header = "Date" ":" rfc1123-date 2274 location-header = "Location" ":" request-uri 2275 require-header = "Require" ":" #parameters 2276 transport-require-header = "Transport-Require" ":" #parameters 2277 nack-require-header = "Nack-Require" ":" #parameters 2278 nack-transport-require-header = "Nack-Transport-Require" ":" #parameters 2280 auth-scheme = token 2281 ip-address = 2282 port-number = 1*DIGIT 2283 blocksize-value = 1*DIGIT 2284 credentials = auth-scheme ":" #parameter 2285 rfc1123-date = wkday "," SP date SP time SP "GMT" 2286 date = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 12 Dec 1998) 2287 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 2288 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" 2289 month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" 2290 | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" 2292 15 Experimental 2294 This section gathers parts of the protocol which are less well understood 2295 and require extensive further discussion. 2297 15.1 Header Field Definitions 2299 The following additional HTTP headers may be useful for RTSP: 2301 * Accept-Language 2302 * Cache-Control 2303 * From 2304 * Max-Forwards 2305 * Proxy-Authenticate 2306 * Proxy-Authorization 2307 * Public 2308 * Referer 2310 15.1.1 Address 2312 Designates address to send multimedia data to. 2314 It appears that in almost all cases, the destination address is 2315 the same one where the RTSP command originates from. If TCP is 2316 used for control, this also eliminates the possibilities of 2317 pointing a data stream at an unsuspecting third party. 2319 16 Security Considerations 2321 The protocol offers the opportunity for a remote-control denial-of-service 2322 attack. The attacker, using a forged source IP address, can ask for a 2323 stream to be played back to that forged IP address. 2325 Since there is no relation between a transport layer connection and an RTSP 2326 session, it is possible for a malicious client to issue requests with 2327 random session identifiers which would affect unsuspecting clients. This 2328 does not require spoofing of network packet addresses. The server SHOULD 2329 use a large random session identifier to make this attack more difficult. 2331 Both problems can be be prevented by appropriate authentication. 2333 In addition, the security considerations outlined in [H15] apply. 2335 A State Machines 2337 The RTSP client and server state machines describe the behavior of the 2338 protocol from session initialization through session termination. 2340 [TBD: should we allow for the trivial case of a server that only implements 2341 the PLAY message, with no control.] 2342 State is defined on a per object basis. An object is uniquely identified by 2343 the stream URL AND the session identifier. (A server may choose to generate 2344 dynamic session descriptions where the URL is unique for a particular 2345 session and thus may not need an explicit session identifier in the request 2346 header.) Any request/reply using URLs denoting a session comprised of 2347 multiple streams will have an effect on the individual states of all the 2348 substreams. For example: 2350 Assuming the stream /coolmovie contains two substreams /coolmovie/audio and 2351 /coolmovie/video, then the following command: 2353 PLAY /coolmovie RTSP/1.0 559 2354 Session: 12345 2356 will have an effect on the states of coolmovie/audio and coolmovie/video. 2358 This example does not imply a standard way to represent 2359 substreams in URLs or a relation to the filesystem. See Section 2360 3.2. 2362 A.1 Client State Machine 2364 A.1.1 Client States 2366 These are defined as follows: 2368 NULL: 2369 No state 2370 INIT: 2371 GET or SETUP has been sent, waiting for reply. 2372 READY: 2373 SETUP reply received OR after playing, PAUSE reply received. 2374 PLAYING: 2375 PLAY reply received 2377 A.1.2 Notes 2379 In general, the client transitions state on receipt of specific replies. 2380 After a period of inactivity, state transitions back to NULL. "Inactivity" 2381 is defined as one of the following: 2383 * For state PLAYING, no data being received and/or lack of wellness 2384 information from the server. 2385 * The client stays in any other state continuously for more than a 2386 specific interval. The choice of this interval is left to the 2387 implementation. 2389 If no explicit SETUP is required for the object (for example, it is 2390 available via a multicast group) , state begins at READY. In this case, 2391 there are only two states, i.e READY and PLAYING. 2393 A client MUST disregard messages with a sequence number less than the last 2394 one . If no message has been received, the first received message's 2395 sequence number will be the starting point. 2397 A.1.3 State Table 2399 In the NEXT STATE column, + indicates that the message was successful, 2400 -indicates that it was unsuccessful. 2402 STATE MESSAGES NEXT STATE(+) NEXT STATE(-) 2404 INIT GET REPLY INIT NULL 2405 SETUP REPLY READY INIT 2406 REDIRECT NULL NULL 2407 BYE NULL NULL 2408 OTHER INIT INIT 2410 READY PLAY REPLY PLAYING READY 2411 SETUP REPLY READY INIT 2412 BYE NULL NULL 2413 OTHER READY READY 2415 PLAYING PAUSE REPLY READY PLAYING 2416 PLAY REPLY PLAYING CLOSED 2417 BYE NULL NULL 2418 CLOSE REPLY NULL PLAYING 2419 OTHER PLAYING PLAYING 2421 This assumes that a PLAY during state PLAYING is an implicit PAUSE, PLAY. 2423 HS: BYE should be replaced by CLOSE. 2425 A.2 Server State Machine 2427 A.2.1 Server States 2429 INIT: 2430 The initial state, no valid SETUP receieved. 2431 READY: 2432 Last SETUP received was successful, reply sent or after playing, last 2433 PAUSE received was successful, reply sent. 2435 PLAYING: 2436 Last PLAY received was successful, reply sent. Data actually being 2437 sent. 2439 In general, server state transitions occur on receiving requests. On 2440 receiving a BYE, state transitions back to INIT. After inactivity for a 2441 period, state also transitions back to INIT. "Inactivity" is defined as: 2443 * For states other than PLAYING, no messages for that object for a 2444 specific interval. The choice of interval is left to the 2445 implementation. 2446 * In state PLAYING, lack of wellness information from the client.(This 2447 information could be either RTCP or be requested by the server by 2448 other means) 2450 The REDIRECT message, when sent, is effective immediately. If a similar 2451 change of location occurs at a certain time in the future, this is assumed 2452 to be indicated by the session description. For purposes of this table, a 2453 REDIRECT is considered an unsuccessful GET. 2455 A server MUST disregard messages with a sequence number less than the last 2456 one. If no message has been received, the first received message's sequence 2457 number will be the starting point. 2459 SETUP is valid in states INIT and READY only. An error message should be 2460 returned in other cases. If no explicit SETUP is required for the object, 2461 state starts at READY, ie. there are only two states READY and PLAYING. 2463 A.2.2 State Table 2465 In the NEXT STATE column, + indicates that the message was successful, 2466 -indicates that it was unsuccessful. 2468 STATE MESSAGES NEXT STATE(+) NEXT STATE(-) 2470 INIT GET INIT INIT 2471 SETUP READY INIT 2472 BYE INIT INIT 2473 OTHER - INIT 2475 READY PLAY PLAYING READY 2476 SETUP READY INIT 2477 CLOSE INIT - 2478 BYE INIT - 2479 OTHER - READY 2481 PLAYING PLAY PLAYING READY 2482 PAUSE READY PLAYING 2483 CLOSE INIT PLAYING 2484 BYE INIT - 2485 OTHER - PLAYING 2487 B Open Issues 2489 * Define text/rtsp-parameter MIME type. 2490 * Lots of inconsistencies need to be fixed: naming of methods in state 2491 definition, syntax. 2492 * Allow changing of transport for a stream that's playing? May not be a 2493 great idea since the same can be accomplished by tear down and 2494 re-setup. 2495 * How does the server get back to the client unless a persistent 2496 connection is used? Probably cannot, in general. 2497 * Cache and proxy behavior? 2498 * Session: or Set-Cookie: ? 2499 * Behavior of all methods in state diagram. 2500 * Error message for method 2501 * When do relative RTSP URLs make sense? 2502 * Nack-require, etc. are dubious. This is getting awfully close to the 2503 HTTP extension mechanisms [16] in complexity, but is different. 2504 * Suggestion (HS): shelve REDIRECT method for now, until necessity 2505 becomes clear. 2506 * Use HTTP absolute path + Host field or do the right thing and carry 2507 full URL, including host in request? 2509 C Author Addresses 2511 Henning Schulzrinne 2512 Dept. of Computer Science 2513 Columbia University 2514 1214 Amsterdam Avenue 2515 New York, NY 10027 2516 USA 2517 electronic mail: schulzrinne@cs.columbia.edu 2519 Anup Rao 2520 Netscape Communications Corp. 2521 USA 2522 electronic mail: anup@netscape.com 2523 Robert Lanphier 2524 Progressive Networks 2525 1111 Third Avenue Suite 2900 2526 Seattle, WA 98101 2527 USA 2528 electronic mail: robla@prognet.com 2530 D Acknowledgements 2532 This draft is based on the functionality of the RTSP draft. It also borrows 2533 format and descriptions from HTTP/1.1. 2535 This document has benefited greatly from the comments of all those 2536 participating in the MMUSIC-WG. In addition to those already mentioned, the 2537 following individuals have contributed to this specification: 2539 Rahul Agarwal Eduardo F. Llach 2540 Bruce Butterfield Rob McCool 2541 Martin Dunsmuir Sujal Patel 2542 Mark Handley Igor Plotnikov 2543 Peter Haight Pinaki Shah 2544 Brad Hefta-Gaub Jeff Smith 2545 John K. Ho Alexander Sokolsky 2546 Ruth Lang Dale Stammen 2547 Stephanie Leif John Francis Stracke 2549 References 2551 1 D. Kristol and L. Montulli, ``HTTP state management mechanism,'' RFC 2552 2109, Internet Engineering Task Force, Feb. 1997. 2554 2 F. Yergeau, G. Nicol, G. Adams, and M. Duerst, ``Internationalization 2555 of the hypertext markup language,'' RFC 2070, Internet Engineering 2556 Task Force, Jan. 1997. 2558 3 S. Bradner, ``Key words for use in RFCs to indicate requirement 2559 levels,'' Internet Draft, Internet Engineering Task Force, Jan. 1997. 2560 Work in progress. 2562 4 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, 2563 ``Hypertext transfer protocol - HTTP/1.1,'' RFC 2068, Internet 2564 Engineering Task Force, Jan. 1997. 2566 5 A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' Internet 2567 Draft, Internet Engineering Task Force, Dec. 1996. Work in progress. 2569 6 J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and E. L. 2570 Stewart, ``An extension to HTTP: digest access authentication,'' RFC 2571 2069, Internet Engineering Task Force, Jan. 1997. 2573 7 J. Postel, ``User datagram protocol,'' STD 6, RFC 768, Internet 2574 Engineering Task Force, Aug. 1980. 2576 8 R. Hinden and C. Partridge, ``Version 2 of the reliable data protocol 2577 (RDP),'' RFC 1151, Internet Engineering Task Force, Apr. 1990. 2579 9 J. Postel, ``Transmission control protocol,'' STD 7, RFC 793, 2580 Internet Engineering Task Force, Sept. 1981. 2582 10 M. Handley, H. Schulzrinne, and E. Schooler, ``SIP: Session 2583 initiation protocol,'' Internet Draft, Internet Engineering Task 2584 Force, Dec. 1996. Work in progress. 2586 11 P. McMahon, ``GSS-API authentication method for SOCKS version 5,'' 2587 RFC 1961, Internet Engineering Task Force, June 1996. 2589 12 D. Crocker, ``Augmented BNF for syntax specifications: ABNF,'' 2590 Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in 2591 progress. 2593 13 R. Elz, ``A compact representation of IPv6 addresses,'' RFC 1924, 2594 Internet Engineering Task Force, Apr. 1996. 2596 14 T. Berners-Lee, ``Universal resource identifiers in WWW: a unifying 2597 syntax for the expression of names and addresses of objects on the 2598 network as used in the world-wide web,'' RFC 1630, Internet 2599 Engineering Task Force, June 1994. 2601 15 International Telecommunication Union, ``Visual telephone systems and 2602 equipment for local area networks which provide a non-guaranteed 2603 quality of service,'' Recommendation H.323, Telecommunication 2604 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 2606 16 D. Connolly, ``PEP: an extension mechanism for http,'' Internet 2607 Draft, Internet Engineering Task Force, Jan. 1997. Work in progress.