home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mmusic-rtsp-01.txt < prev    next >
Text File  |  1997-02-24  |  111KB  |  3,357 lines
  1.  
  2. INTERNET-DRAFT                   Henning Schulzrinne, Columbia University
  3.                                         Anup Rao, Netscape Communications
  4.                                        Rob Lanphier, Progressive Networks
  5. SUBMITTED: 24th February 1997                   Expires: 24th August 1997
  6.  
  7.                     Real Time Streaming Protocol (RTSP)
  8.                        draft-ietf-mmusic-rtsp-01.txt
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12. This is an Internet-Draft. Internet-Drafts are working documents of the
  13. Internet Engineering Task Force (IETF), its areas, and its working groups.
  14. Note that other groups may also distribute working documents as
  15. Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of
  16. six months and may be updated, replaced, or obsoleted by other documents at
  17. any time. It is inappropriate to use Internet-Drafts as reference material
  18. or to cite them other than as "work in progress."
  19.  
  20. To learn the current status of any Internet-Draft, please check the
  21. "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow
  22. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), mannari.oz.au
  23. (Pacific Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US West
  24. Coast).
  25.  
  26. Prior to the expiration of this draft, the list of open issues may be found
  27. at the following URL:
  28.  
  29. http://www.prognet.com/prognet/rt/openissues.html
  30.  
  31. Abstract:
  32.  
  33. The Real Time Streaming Protocol, or RTSP, is an application-level protocol
  34. for control over the delivery of data with real-time properties. RTSP
  35. provides an extensible framework to enable controlled, on-demand delivery
  36. of real-time data, such as audio and video. Sources of data can include
  37. both live data feeds and stored clips. This protocol is intended to control
  38. multiple data delivery sessions, provide a means for choosing delivery
  39. channels such as UDP, multicast UDP and TCP, and delivery mechanisms based
  40. upon RTP (RFC 1889).
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. H. Schulzrinne, A. Rao, R. Lanphier                            Page  1
  56.  
  57.  
  58. INTERNET-DRAFT                   RTSP                February 21, 1997
  59.  
  60.  
  61. Contents
  62.  
  63.    * 1 Introduction
  64.         o 1.1 Purpose
  65.         o 1.2 Requirements
  66.         o 1.3 Terminology
  67.         o 1.4 Protocol Properties
  68.         o 1.5 Extending RTSP
  69.         o 1.6 Overall Operation
  70.         o 1.7 RTSP States
  71.         o 1.8 Relationship with Other Protocols
  72.    * 2 Notational Conventions
  73.    * 3 Protocol Parameters
  74.         o 3.1 RTSP Version
  75.         o 3.2 RTSP URL
  76.         o 3.3 Conference Identifiers
  77.         o 3.4 Relative Timestamps
  78.         o 3.5 Absolute Time
  79.    * 4 RTSP Message
  80.         o 4.1 Message Types
  81.         o 4.2 Message Headers
  82.         o 4.3 Message Body
  83.         o 4.4 Message Length
  84.    * 5 Request
  85.    * 6 Response
  86.         o 6.1 Status-Line
  87.              + 6.1.1 Status Code and Reason Phrase
  88.              + 6.1.2 Response Header Fields
  89.    * 7 Entity
  90.         o 7.1 Entity Header Fields
  91.         o 7.2 Entity Body
  92.    * 8 Connections
  93.         o 8.1 Pipelining
  94.         o 8.2 Reliability and Acknowledgements
  95.    * 9 Method Definitions
  96.         o 9.1 HELLO
  97.         o 9.2 GET
  98.         o 9.3 SETUP
  99.         o 9.4 PLAY
  100.         o 9.5 PAUSE
  101.         o 9.6 CLOSE
  102.         o 9.7 BYE
  103.         o 9.8 GET_PARAMETER
  104.         o 9.9 SET_PARAMETER
  105.         o 9.10 REDIRECT
  106.         o 9.11 SESSION
  107.         o 9.12 RECORD
  108.         o 9.13 Embedded Binary Data
  109.  
  110. H. Schulzrinne, A. Rao, R. Lanphier                            Page  2
  111.  
  112.  
  113. INTERNET-DRAFT                   RTSP                February 21, 1997
  114.  
  115.  
  116.    * 10 Status Codes Definitions
  117.         o 10.1 Client Error 4xx
  118.              + 10.1.1 451 Parameter Not Understood
  119.              + 10.1.2 452 Conference Not Found
  120.              + 10.1.3 453 Not Enough Bandwidth
  121.              + 10.1.4 45x Session Not Found
  122.              + 10.1.5 45x Method Not Valid in This State
  123.              + 10.1.6 45x Header Field Not Valid for Resource
  124.              + 10.1.7 45x Invalid Range
  125.              + 10.1.8 45x Parameter Is Read-Only
  126.    * 11 Header Field Definitions
  127.         o 11.1 Accept
  128.         o 11.2 Accept-Encoding
  129.         o 11.3 Accept-Language
  130.         o 11.4 Allow
  131.         o 11.5 Authorization
  132.         o 11.6 Bandwidth
  133.         o 11.7 Blocksize
  134.         o 11.8 Conference
  135.         o 11.9 Content-Encoding
  136.         o 11.10 Content-Length
  137.         o 11.11 Content-Type
  138.         o 11.12 Date
  139.         o 11.13 If-Modified-Since
  140.         o 11.14 Last-modified
  141.         o 11.15 Location
  142.         o 11.16 Range
  143.         o 11.17 Require
  144.         o 11.18 Unsupported
  145.         o 11.19 Nack-Transport-Require
  146.         o 11.20 Transport-Require
  147.         o 11.21 Retry-After
  148.         o 11.22 Speed
  149.         o 11.23 Server
  150.         o 11.24 Session
  151.         o 11.25 Transport
  152.         o 11.26 User-Agent
  153.         o 11.27 Via
  154.         o 11.28 WWW-Authenticate
  155.    * 12 Caching
  156.    * 13 Examples
  157.         o 13.1 Media on Demand (Unicast)
  158.         o 13.2 Live Media Event Using Multicast
  159.         o 13.3 Playing media into an existing session
  160.         o 13.4 Recording
  161.  
  162.  
  163.  
  164.  
  165. H. Schulzrinne, A. Rao, R. Lanphier                            Page  3
  166.  
  167.  
  168. INTERNET-DRAFT                   RTSP                February 21, 1997
  169.  
  170.  
  171.    * 14 Syntax
  172.         o 14.1 Base Syntax
  173.         o 14.2 Internet Media Type Syntax
  174.         o 14.3 Universal Resource Identifier Syntax
  175.         o 14.4 RTSP-specific syntax
  176.    * 15 Experimental
  177.         o 15.1 Header Field Definitions
  178.              + 15.1.1 Address
  179.    * 16 Security Considerations
  180.    * A State Machines
  181.         o A.1 Client State Machine
  182.              + A.1.1 Client States
  183.              + A.1.2 Notes
  184.              + A.1.3 State Table
  185.         o A.2 Server State Machine
  186.              + A.2.1 Server States
  187.              + A.2.2 State Table
  188.    * B Open Issues
  189.    * C Author Addresses
  190.    * D Acknowledgements
  191.    * References
  192.  
  193. 1 Introduction
  194.  
  195. 1.1 Purpose
  196.  
  197. RTSP establishes and controls either single or several (time-synchronized)
  198. streams of continuous media. It does not typically deliver the continuous
  199. streams itself, although interleaving of the continuous media stream with
  200. the control stream is possible (Section 9.13).
  201.  
  202. There is no notion of an RTSP connection, but rather a session maintained
  203. by an identifier. An RTSP session is in no way tied to a transport-level
  204. session. During an RTSP session, an RTSP client may open and close many
  205. reliable transport connections to the server to issue RTSP requests.
  206. Alternatively, it may use a connectionless transport protocol such as UDP.
  207.  
  208. The protocol is intentionally similar in syntax and operation to HTTP/1.1,
  209. so that extension mechanisms to HTTP can in most cases also be added to
  210. RTSP. However, RTSP differs in a number of important aspects from HTTP:
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. H. Schulzrinne, A. Rao, R. Lanphier                            Page  4
  221.  
  222.  
  223. INTERNET-DRAFT                   RTSP                February 21, 1997
  224.  
  225.  
  226.    * RTSP introduces a number of new methods and has a different protocol
  227.      identifier.
  228.    * An RTSP server needs to maintain state by default in almost all cases,
  229.      as opposed to the stateless nature of HTTP. (RTSP servers and clients
  230.      MAY use the HTTP state maintenance mechanism [1].)
  231.    * Both an RTSP server and client can issue requests.
  232.    * Data is carried out-of-band, by a different protocol. (There is an
  233.      exception to this.)
  234.    * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,
  235.      consistent with current HTML internationalization efforts [2].
  236.  
  237.           HS: Probably the right thing to do, but may lead to
  238.           confusion with GET.
  239.  
  240.    * The Request-URI always contains the absolute URI. Because of backward
  241.      compatibility with a historical blunder, HTTP/1.1 carries only the
  242.      absolute path in the request
  243.  
  244.           This makes virtual hosting easier. However, this is
  245.           incompatible with HTTP/1.1, which may be a bad idea. Makes
  246.           definition of GET confusing, if it is included in RTSP.
  247.  
  248. The protocol supports the following operations:
  249.  
  250. Retrieval of media from media server:
  251.      The client can request a session description via HTTP or some other
  252.      method. If the session is being multicast, the session description
  253.      contains the multicast addresses and ports to be used for the
  254.      continuous media. If the session is to be sent only to the client via
  255.      unicast, the client provides the destination for security reasons.
  256.  
  257. Invitation of a media server to a conference:
  258.      A media server can be ``invited'' to join an existing conference,
  259.      either to play back media into the session or to record all or a
  260.      subset of the media in a session. This mode is useful for distributed
  261.      teaching applications. Several parties in the conference may take
  262.      turns ``pushing the remote control buttons''.
  263.  
  264. Addition of media to an existing session:
  265.      Particularly for live events, it is useful if the server can tell the
  266.      client about additional media becoming available.
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275. H. Schulzrinne, A. Rao, R. Lanphier                            Page  5
  276.  
  277.  
  278. INTERNET-DRAFT                   RTSP                February 21, 1997
  279.  
  280.  
  281. RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1.
  282.  
  283. 1.2 Requirements
  284.  
  285. The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
  286. NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and
  287. ``OPTIONAL'' in this document are to be interpreted as described in RFC
  288. xxxx [3].
  289.  
  290. 1.3 Terminology
  291.  
  292. Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not
  293. listed here are defined as in HTTP/1.1.
  294.  
  295. Conference:
  296.      a multiparty, multimedia session, where ``multi'' implies greater than
  297.      or equal to one.
  298.  
  299. Client:
  300.      The client requests continuous media data from the media server.
  301.  
  302. Connection:
  303.      A transport layer virtual circuit established between two programs for
  304.      the purpose of communication.
  305.  
  306. Continuous media:
  307.      Data where there is a timing relationship between source and sink,
  308.      that is, the sink must reproduce the timing relationshop that existed
  309.      at the source. The most common examples of continuous media are audio
  310.      and motion video. Continuous media can be realtime (interactive),
  311.      where there is a ``tight'' timing relationship between source and
  312.      sink, or streaming (playback), where the relationship is less strict.
  313.  
  314. Entity:
  315.      An entity is a participant in a conference. This participant may be
  316.      non-human, e.g., a media record or playback server.
  317.  
  318. Media server:
  319.      The network entity providing playback or recording services for one or
  320.      more media streams. Different media streams within a session may
  321.      originate from different media servers. A media server may reside on
  322.      the same or a different host as the web server the media session is
  323.      invoked from.
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330. H. Schulzrinne, A. Rao, R. Lanphier                            Page  6
  331.  
  332.  
  333. INTERNET-DRAFT                   RTSP                February 21, 1997
  334.  
  335.  
  336. Media session:
  337.      A collection of media streams to be treated as an aggregate, with a
  338.      single time axis. Typically, a client will synchronize in time all
  339.      media streams within a media session. An example of a media session is
  340.      a movie consisting of a video and audio track.
  341.  
  342. (Media) stream:
  343.      A single media instance, e.g., an audio stream or a video stream as
  344.      well as a single whiteboard or shared application group. When using
  345.      RTP, a stream consists of all RTP and RTCP packets created by a source
  346.      within an RTP session.
  347.  
  348.      [TBD: terminology is confusing since there's an RTP session, which is
  349.      used by a single RTSP stream.]
  350.  
  351. Message:
  352.      The basic unit of RTSP communication, consisting of a structured
  353.      sequence of octets matching the syntax defined in Section 14 and
  354.      transmitted via a connection or a connectionless protocol.
  355.  
  356. Response:
  357.      An RTSP response. If an HTTP response is meant, that is indicated
  358.      explicitly.
  359.  
  360. Request:
  361.      An RTSP request. If an HTTP request is meant, that is indicated
  362.      explicitly.
  363.  
  364. Session description:
  365.      A session description contains information about one or more media
  366.      within a session, such as the set of encodings, network addresses and
  367.      information about the content. The session description may take
  368.      several different formats, including SDP and SDF.
  369.  
  370. Media parameter:
  371.      Parameter specific to a media type that may be changed while the
  372.      stream is being played or prior to it.
  373.  
  374. 1.4 Protocol Properties
  375.  
  376. RTSP has the following properties:
  377.  
  378. Extendable:
  379.      New methods and parameters can be easily added to RTSP.
  380.  
  381.  
  382.  
  383.  
  384.  
  385. H. Schulzrinne, A. Rao, R. Lanphier                            Page  7
  386.  
  387.  
  388. INTERNET-DRAFT                   RTSP                February 21, 1997
  389.  
  390.  
  391. Easy to parse:
  392.      RTSP can be parsed by standard HTTP or MIME parsers.
  393.  
  394. Secure:
  395.      RTSP re-uses web security mechanisms, either at the transport level
  396.      (TLS [5]) or within the protocol itself. All HTTP authentication
  397.      mechanisms such as basic [4, Section 11.1,] and digest authentication
  398.      [6] are directly applicable.
  399.  
  400. Transport-independent:
  401.      RTSP may use either an unreliable datagram protocol (UDP) [7], a
  402.      reliable datagram protocol (RDP, not widely used [8]) or a reliable
  403.      stream protocol such as TCP [9] as it implements application-level
  404.      reliability.
  405.  
  406. Multi-server capable:
  407.      Each media stream within a session can reside on a different server.
  408.      The client automatically establishes several concurrent control
  409.      sessions with the different media servers. Media synchronization is
  410.      performed at the transport level.
  411.  
  412. Control of recording devices:
  413.      The protocol can control both recording and playback devices, as well
  414.      as devices that can alternate between the two modes (``VCR'').
  415.  
  416. Separation of stream control and conference initiation:
  417.      Stream control is divorced from inviting a media server to a
  418.      conference. The only requirement is that the conference initiation
  419.      protocol either provides or can be used to create a unique conference
  420.      identifier. In particular, SIP [10] or H.323 may be used to invite a
  421.      server to a conference.
  422.  
  423. Suitable for professional applications:
  424.      RTSP supports frame-level accuracy through SMPTE time stamps to allow
  425.      remote digital editing.
  426.  
  427. Session description neutral:
  428.      The protocol does not impose a particular session description or
  429.      metafile format and can convey the type of format to be used. However,
  430.      the session description must contain an RTSP URI.
  431.  
  432. Proxy and firewall friendly:
  433.      The protocol should be readily handled by both application and
  434.      transport-layer (SOCKS [11]) firewalls. A firewall may need to
  435.      understand the SETUP method to open a ``hole'' for the UDP media
  436.      stream.
  437.  
  438.  
  439.  
  440. H. Schulzrinne, A. Rao, R. Lanphier                            Page  8
  441.  
  442.  
  443. INTERNET-DRAFT                   RTSP                February 21, 1997
  444.  
  445.  
  446. HTTP-friendly:
  447.      Where sensible, RTSP re-uses HTTP concepts, so that the existing
  448.      infrastructure can be re-used. This infrastructure includes JEPI (the
  449.      Joint Electronic Payment Initiative) for electronic payments and PICS
  450.      (Platform for Internet Content Selection) for associating labels with
  451.      content. However, RTSP does not just add methods to HTTP, since the
  452.      controlling continuous media requires server state in most cases.
  453.  
  454. Appropriate server control:
  455.      If a client can start a stream, it must be able to stop a stream.
  456.      Servers should not start streaming to clients in such a way that
  457.      clients cannot stop the stream.
  458.  
  459. Transport negotiation:
  460.      The client can negotiate the transport method prior to actually
  461.      needing to process a continuous media stream.
  462.  
  463. Capability negotiation:
  464.      If basic features are disabled, there must be some clean mechanism for
  465.      the client to determine which methods are not going to be implemented.
  466.      This allows clients to present the appropriate user interface. For
  467.      example, if seeking is not allowed, the user interface must be able to
  468.      disallow moving a sliding position indicator.
  469.  
  470.      An earlier requirement in RTSP' was multi-client capability.
  471.      However, it was determined that a better approach was to make
  472.      sure that the protocol is easily extensible to the multi-client
  473.      scenario. Stream identifiers can be used by several control
  474.      streams, so that ``passing the remote'' would be possible. The
  475.      protocol would not address how several clients negotiate access;
  476.      this is left to either a ``social protocol'' or some other floor
  477.      control mechanism.
  478.  
  479. 1.5 Extending RTSP
  480.  
  481. RTSP can be extended in three ways, listed in order of the magnitude of
  482. changes supported:
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495. H. Schulzrinne, A. Rao, R. Lanphier                            Page  9
  496.  
  497.  
  498. INTERNET-DRAFT                   RTSP                February 21, 1997
  499.  
  500.  
  501.    * Existing methods can be extended with new parameters, as long as these
  502.      parameters can be safely ignored by the recipient. (This is equivalent
  503.      to adding new parameters to an HTML tag.)
  504.    * New methods can be added. If the recipient of the message does not
  505.      understand the request, it responds with error code 501 (Not
  506.      implemented) and the sender can then attempt an earlier, less
  507.      functional version.
  508.    * A new version of the protocol can be defined, allowing almost all
  509.      aspects (except the position of the protocol version number) to
  510.      change.
  511.  
  512. 1.6 Overall Operation
  513.  
  514. Each media stream and session may be identified by an RTSP URL. The overall
  515. session and the properties of the media the session is made up of are
  516. defined by a session description file, the format of which is outside the
  517. scope of this specification. The session description file is retrieved
  518. using HTTP, either from the web server or the media server, typically using
  519. an URL with scheme HTTP.
  520.  
  521. The session description file contains a description of the media streams
  522. making up the media session, including their encodings, language, and other
  523. parameters that enable the client to choose the most appropriate
  524. combination of media. In this session description, each media stream is
  525. identified by an RTSP URL, which points to the media server handling that
  526. particular media stream and names the stream stored on that server. Several
  527. media streams can be located on different servers; for example, audio and
  528. video tracks can be split across servers for load sharing. The description
  529. also enumerates which transport methods the server is capable of. If
  530. desired, the session description can also contain only an RTSP URL, with
  531. the complete session description retrieved via RTSP.
  532.  
  533. Besides the media parameters, the network destination address and port need
  534. to be determined. Several modes of operation can be distinguished:
  535.  
  536. Unicast:
  537.      The media is transmitted to the source of the RTSP request, with the
  538.      port number picked by the client. Alternatively, the media is
  539.      transmitted on the same reliable stream as RTSP.
  540.  
  541. Multicast, server chooses address:
  542.      The media server picks the multicast address and port. This is the
  543.      typical case for a live or near-media-on-demand transmission.
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550. H. Schulzrinne, A. Rao, R. Lanphier                            Page 10
  551.  
  552.  
  553. INTERNET-DRAFT                   RTSP                February 21, 1997
  554.  
  555.  
  556. Multicast, client chooses address:
  557.      If the server is to participate in an existing multicast conference,
  558.      the multicast address, port and encryption key are given by the
  559.      conference description, established by means outside the scope of this
  560.      specification.
  561.  
  562. 1.7 RTSP States
  563.  
  564. RTSP controls a stream which may be sent via a separate protocol,
  565. independent of the control channel. For example, RTSP control may occur on
  566. a TCP connection while the data flows via UDP. Thus, data delivery
  567. continues even if no RTSP requests are received by the media server. Also,
  568. during its lifetime, a single media stream may be controlled by RTSP
  569. requests issued sequentially on different TCP connections. Therefore, the
  570. server needs to maintain ``session state'' to be able to correlate RTSP
  571. requests with a stream.
  572.  
  573.      HS: This does not imply that the protocol has to be stateful in
  574.      the way described here. If state were to be defined by identifier
  575.      only, the first PLAY or RECORD request would initiate stream
  576.      flow, with no need for SETUP. It has been argued that a separate
  577.      setup simplifies the life of firewall writers.
  578.  
  579. Many methods in RTSP do not contribute to state. However, there are four
  580. that play a central role in defining the allocation and usage of stream
  581. resources on the server: SETUP, PLAY, PAUSE, and CLOSE. The roles they play
  582. are defined as follows.
  583.  
  584.  Step session allocation method  session control method
  585.  1    SETUP
  586.  2                               PLAY
  587.  3                               PAUSE
  588.  4    CLOSE
  589.  
  590.  SETUP Causes the server to allocate resources for a stream.
  591.  PLAY  Starts data transmission on a stream allocated via SETUP.
  592.  PAUSE Temporarily halts a stream, without freeing server resources.
  593.  
  594.  CLOSE Frees resources associated with the stream. The session ceases to
  595.        exist on the server.
  596.  
  597. A client must issue a SETUP request unless all necessary transport
  598. information is already available.
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605. H. Schulzrinne, A. Rao, R. Lanphier                            Page 11
  606.  
  607.  
  608. INTERNET-DRAFT                   RTSP                February 21, 1997
  609.  
  610.  
  611. 1.8 Relationship with Other Protocols
  612.  
  613. RTSP has some overlap in functionality with HTTP. It also may interact with
  614. HTTP in that the initial contact with streaming content is often to be made
  615. through a web page. The current protocol specification aims to allow
  616. different hand-off points between a web server and the media server
  617. implementing RTSP. For example, the session description can be retrieved
  618. using HTTP or RTSP. Having the session description be returned by the web
  619. server makes it possible to have the web server take care of authentication
  620. and billing, by handing out a session description whose media identifier
  621. includes an encrypted version of the requestor's IP address and a
  622. timestamp, with a shared secret between web and media server.
  623.  
  624. However, RTSP differs fundamentally from HTTP in that data delivery takes
  625. place out-of-band, in a different protocol. HTTP is an asymmetric protocol,
  626. where the client issues requests and the server responds. In RTSP, both the
  627. media client and media server can issue requests. RTSP requests are also
  628. not stateless, in that they may set parameters and continue to control a
  629. media stream long after the request has been acknowledged.
  630.  
  631.      Re-using HTTP functionality has advantages in at least two areas,
  632.      namely security and proxies. The requirements are very similar,
  633.      so having the ability to adopt HTTP work on caches, proxies and
  634.      authentication is valuable.
  635.  
  636. While most real-time media will use RTP as a transport protocol, RTSP is
  637. not tied to RTP.
  638.  
  639. RTSP assumes the existence of a session description format that can express
  640. both static and temporal properties of a media session containing several
  641. media streams.
  642.  
  643. 2 Notational Conventions
  644.  
  645. Since many of the definitions and syntax are identical to HTTP/1.1, this
  646. specification only points to the section where they are defined rather than
  647. copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of
  648. the current HTTP/1.1 specification (RFC 2068).
  649.  
  650. All the mechanisms specified in this document are described in both prose
  651. and an augmented Backus-Naur form (BNF) similar to that used in RFC 2068
  652. [H2.1]. It is described in detail in [12].
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660. H. Schulzrinne, A. Rao, R. Lanphier                            Page 12
  661.  
  662.  
  663. INTERNET-DRAFT                   RTSP                February 21, 1997
  664.  
  665.  
  666. In this draft, we use indented and smaller-type paragraphs to provide
  667. background and motivation. Some of these paragraphs are marked with HS, AR
  668. and RL, designating opinions and comments by the individual authors which
  669. may not be shared by the co-authors and require resolution.
  670.  
  671. 3 Protocol Parameters
  672.  
  673. 3.1 RTSP Version
  674.  
  675. [H3.1] applies, with HTTP replaced by RTSP.
  676.  
  677. 3.2 RTSP URL
  678.  
  679. The ``rtsp'' and ``rtspu'' schemes are used to refer to network resources
  680. via the RTSP protocol. This section defines the scheme-specific syntax and
  681. semantics for RTSP URLs.
  682.  
  683.   rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path]
  684.   host     = <A legal Internet host domain name of IP address
  685.              (in dotted decimal form), as defined by Section 2.1
  686.              of RFC 1123>
  687.   port     = *DIGIT
  688.  
  689. abs_path is defined in [H3.2.1].
  690.  
  691.      Note that fragment and query identifiers do not have a
  692.      well-defined meaning at this time, with the interpretation left
  693.      to the RTSP server.
  694.  
  695. The scheme rtsp requires that commands are issued via a reliable protocol
  696. (within the Internet, TCP), while the scheme rtspu identifies an unreliable
  697. protocol (within the Internet, UDP).
  698.  
  699. If the port is empty or not given, port 554 is assumed. The semantics are
  700. that the identified resource can be controlled be RTSP at the server
  701. listening for TCP (scheme ``rtsp'') connections or UDP (scheme ``rtspu'')
  702. packets on that port of host, and the Request-URI for the resource is
  703. rtsp_URL.
  704.  
  705. The use of IP addresses in URLs SHOULD be avoided whenever possible (see
  706. RFC 1924 [13]).
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715. H. Schulzrinne, A. Rao, R. Lanphier                            Page 13
  716.  
  717.  
  718. INTERNET-DRAFT                   RTSP                February 21, 1997
  719.  
  720.  
  721. A media presentation is identified by an textual media identifier, using
  722. the character set and escape conventions [H3.2] of URLs []. Requests
  723. described in Section 9 can refer to either the whole presentation or an
  724. individual track within the presentation. Note that some methods can only
  725. be applied to tracks, not presentations. A specific instance of a session,
  726. e.g., one of several concurrent transmissions of the same content, is
  727. indicated by the Session header field (Section 11.24) where needed.
  728.  
  729. For example, the RTSP URL
  730.  
  731.   rtsp://media.content.com:554/twister/audiotrack
  732.  
  733. identifies the audio track within the presentation ``twister'', which can
  734. be controlled via RTSP requests issued over a TCP connection to port 554 of
  735. host media.content.com.
  736.  
  737.      This does not imply a standard way to reference tracks in URLs.
  738.      The session description defines the hierarchical relationships in
  739.      the presentation and the URLs for the individual tracks. A
  740.      session description may name a track 'a.mov' and the whole
  741.      presentation 'b.mov'.
  742.  
  743. The path components of the RTSP URL are opaque to the client and do not
  744. imply any particular file system structure for the server.
  745.  
  746.      This decoupling also allows session descriptions to be used with
  747.      non-RTSP media control protocols, simply by replacing the scheme
  748.      in the URL.
  749.  
  750. 3.3 Conference Identifiers
  751.  
  752. Conference identifiers are opaque to RTSP and are encoded using standard
  753. URI encoding methods (i.e., LWS is escaped with %). They can contain any
  754. octet value. The conference identifier MUST be globally unique. For H.323,
  755. the conferenceID value is to be used.
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770. H. Schulzrinne, A. Rao, R. Lanphier                            Page 14
  771.  
  772.  
  773. INTERNET-DRAFT                   RTSP                February 21, 1997
  774.  
  775.  
  776.   conference-id = 1*OCTET  ; LWS must be URL-escaped
  777.  
  778.      Conference identifiers are used to allow to allow RTSP sessions
  779.      to obtain parameters from multimedia conferences the media server
  780.      is participating in. These conferences are created by protocols
  781.      outside the scope of this specification, e.g., H.323 [15] or SIP
  782.      [10]. Instead of the RTSP client explicitly providing transport
  783.      information, for example, it asks the media server to use the
  784.      values in the conference description instead. If the conference
  785.      participant inviting the media server would only supply a
  786.      conference identifier which is unique for that inviting party,
  787.      the media server could add an internal identifier for that party,
  788.      e.g., its Internet address. However, this would prevent that the
  789.      conference participant and the initiator of the RTSP commands are
  790.      two different entities.
  791.  
  792. 3.4 Relative Timestamps
  793.  
  794. A relative time-stamp expresses time relative to the start of the clip.
  795. Relative timestamps are expressed as SMPTE time codes for frame-level
  796. access accuracy. The time code has the format hours:minutes:seconds.frames,
  797. with the origin at the start of the clip. For NTSC, the frame rate is 29.97
  798. frames per second. This is handled by dropping the first frame index of
  799. every minute, except every tenth minute. If the frame value is zero, it may
  800. be omitted.
  801.  
  802.   smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ]
  803.   smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ]
  804.  
  805. Examples:
  806.  
  807.   10:12:33.40
  808.   10:7:33
  809.   10:7:0
  810.  
  811. 3.5 Absolute Time
  812.  
  813. Absolute time is expressed as ISO 8601 timestamps. It is always expressed
  814. as UTC (GMT).
  815.  
  816.   utc-range = "clock" "=" utc-time "-" [ utc-time ]
  817.   utc-time = utc-date "T" utc-time "Z"
  818.   utc-date = 8DIGIT ; < YYYYMMDD >
  819.   utc-time = 6DIGIT ; < HHMMSS >
  820.  
  821.  
  822.  
  823.  
  824.  
  825. H. Schulzrinne, A. Rao, R. Lanphier                            Page 15
  826.  
  827.  
  828. INTERNET-DRAFT                   RTSP                February 21, 1997
  829.  
  830.  
  831. Example for November 8, 1996 at 14h37 and 20 seconds UTC:
  832.  
  833.   19961108T143720Z
  834.  
  835. 4 RTSP Message
  836.  
  837. RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8
  838. encoding (RFC 2044). Lines are terminated by CRLF, but receivers should be
  839. prepared to also interpret CR and LF by themselves as line terminators.
  840.  
  841.      Text-based protocols make it easier to add optional parameters in
  842.      a self-describing manner. Since the number of parameters and the
  843.      frequency of commands is low, processing efficiency is not a
  844.      concern. Text-based protocols, if done carefully, also allow easy
  845.      implementation of research prototypes in scripting languages such
  846.      as Tcl, Visual Basic and Perl.
  847.  
  848.      The 10646 character set avoids tricky character set switching,
  849.      but is invisible to the application as long as US-ASCII is being
  850.      used. This is also the encoding used for RTCP. ISO 8859-1
  851.      translates directly into Unicode, with a high-order octet of
  852.      zero. ISO 8859-1 characters with the most-significant bit set are
  853.      represented as 1100001x 10xxxxxx.
  854.  
  855. RTSP messages can be carried over any lower-layer transport protocol that
  856. is 8-bit clean.
  857.  
  858. Requests contain methods, the object the method is operating upon and
  859. parameters to further describe the method. Methods are idempotent, unless
  860. otherwise noted. Methods are also designed to require little or no state
  861. maintenance at the media server.
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880. H. Schulzrinne, A. Rao, R. Lanphier                            Page 16
  881.  
  882.  
  883. INTERNET-DRAFT                   RTSP                February 21, 1997
  884.  
  885.  
  886. 4.1 Message Types
  887.  
  888. See [H4.1]
  889.  
  890. 4.2 Message Headers
  891.  
  892. See [H4.2]
  893.  
  894. 4.3 Message Body
  895.  
  896. See [H4.3]
  897.  
  898. 4.4 Message Length
  899.  
  900. When a message-body is included with a message, the length of that body is
  901. determined by one of the following (in order of precedence):
  902.  
  903.   1. Any response message which MUST NOT include a message-body (such as
  904.      the 1xx, 204, and 304 responses) is always terminated by the first
  905.      empty line after the header fields, regardless of the entity-header
  906.      fields present in the message.
  907.   2. If a Content-Length header field (section 11.10) is present, its value
  908.      in bytes represents the length of the message-body. If this header
  909.      field is not present, a value of zero is assumed.
  910.   3. By the server closing the connection. (Closing the connection cannot
  911.      be used to indicate the end of a request body, since that would leave
  912.      no possibility for the server to send back a response.)
  913.  
  914. Note that RTSP does not (at present) support the ``chunked'' transfer
  915. coding and requires the presence of the Content-Length header field.
  916.  
  917.      Given the moderate length of session descriptions returned, the
  918.      server should always be able to determine its length, even if it
  919.      is generated dynamically, making the chunked transfer encoding
  920.      unnecessary. Even though Content-Length must be present if there
  921.      is any entity body, the rules ensure reasonable behavior even if
  922.      the length is not given explicitly.
  923.  
  924. 5 Request
  925.  
  926. A request message from a client to a server or vice versa includes, within
  927. the first line of that message, the method to be applied to the resource,
  928. the identifier of the resource, and the protocol version in use.
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935. H. Schulzrinne, A. Rao, R. Lanphier                            Page 17
  936.  
  937.  
  938. INTERNET-DRAFT                   RTSP                February 21, 1997
  939.  
  940.  
  941.   Request = Request-line CRLF
  942.             *request-header
  943.             CRLF
  944.             [ message-body ]
  945.  
  946.   Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF
  947.  
  948.   Method = "GET"             ; Section
  949.          | "SETUP"           ; Section
  950.          | "PLAY"            ; Section
  951.          | "PAUSE"           ; Section
  952.          | "CLOSE"           ; Section
  953.          | "RECORD"          ; Section
  954.          | "REDIRECT"        ; Section
  955.          | "HELLO"           ; Section
  956.          | "SESSION"         ; Section
  957.          | "BYE"             ; Section
  958.          | "SET_PARAMETER"   ; Section
  959.          | "GET_PARAMETER"   ; Section
  960.          | extension-method
  961.  
  962.   extendion-method = token
  963.  
  964.   Request-URI = absolute_URI
  965.  
  966.   RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
  967.  
  968.   seq-no = 1*DIGIT
  969.  
  970. Note that in contrast to HTTP/1.1, RTSP requests always contain the
  971. absolute URL (that is, including the scheme, host and port) rather than
  972. just the absolute path.
  973.  
  974. 6 Response
  975.  
  976. [H6] applies except that HTTP-Version is replaced by RTSP-Version. Also,
  977. RTSP defines additional status codes and does not define some HTTP codes.
  978. The valid response codes and the methods they can be used with are defined
  979. in the table 1 and 2.
  980.  
  981. After receiving and interpreting a request message, the recipient responds
  982. with an RTSP response message.
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990. H. Schulzrinne, A. Rao, R. Lanphier                            Page 18
  991.  
  992.  
  993. INTERNET-DRAFT                   RTSP                February 21, 1997
  994.  
  995.  
  996.   Response = Status-Line             ; Section
  997.              *( general-header       ; Section
  998.               | response-header      ; Section
  999.               | entity-header )      ; Section
  1000.              CRLF
  1001.              [ message-body ]        ; Section
  1002.  
  1003. 6.1 Status-Line
  1004.  
  1005. The first line of a Response message is the Status-Line, consisting of the
  1006. protocol version followed by a numeric status code, the sequence number of
  1007. the corresponding request and the textual phrase associated with the status
  1008. code, with each element separated by SP characters. No CR or LF is allowed
  1009. except in the final CRLF sequence. Note that the addition of a
  1010.  
  1011.   Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF
  1012.  
  1013. 6.1.1 Status Code and Reason Phrase
  1014.  
  1015. The Status-Code element is a 3-digit integer result code of the attempt to
  1016. understand and satisfy the request. These codes are fully defined in
  1017. section10. The Reason-Phrase is intended to give a short textual
  1018. description of the Status-Code. The Status-Code is intended for use by
  1019. automata and the Reason-Phrase is intended for the human user. The client
  1020. is not required to examine or display the Reason-Phrase.
  1021.  
  1022. The first digit of the Status-Code defines the class of response. The last
  1023. two digits do not have any categorization role. There are 5 values for the
  1024. first digit:
  1025.  
  1026.    * 1xx: Informational - Request received, continuing process
  1027.    * 2xx: Success - The action was successfully received, understood, and
  1028.      accepted
  1029.    * 3xx: Redirection - Further action must be taken in order to complete
  1030.      the request
  1031.    * 4xx: Client Error - The request contains bad syntax or cannot be
  1032.      fulfilled
  1033.    * 5xx: Server Error - The server failed to fulfill an apparently valid
  1034.      request
  1035.  
  1036. The individual values of the numeric status codes defined for RTSP/1.0, and
  1037. an example set of corresponding Reason-Phrase's, are presented below. The
  1038. reason phrases listed here are only recommended - they may be replaced by
  1039. local equivalents without affecting the protocol. Note that RTSP adopts
  1040. most HTTP/1.1 status codes and adds RTSP-specific status codes in the
  1041. starting at 450 to avoid conflicts with newly defined HTTP status codes.
  1042.  
  1043.  
  1044.  
  1045. H. Schulzrinne, A. Rao, R. Lanphier                            Page 19
  1046.  
  1047.  
  1048. INTERNET-DRAFT                   RTSP                February 21, 1997
  1049.  
  1050.  
  1051.    Status-Code    = "100"   ; Continue
  1052.                   | "200"   ; OK
  1053.                   | "201"   ; Created
  1054.                   | "202"   ; Accepted
  1055.                   | "203"   ; Non-Authoritative Information
  1056.                   | "204"   ; No Content
  1057.                   | "205"   ; Reset Content
  1058.                   | "206"   ; Partial Content
  1059.                   | "300"   ; Multiple Choices
  1060.                   | "301"   ; Moved Permanently
  1061.                   | "302"   ; Moved Temporarily
  1062.                   | "303"   ; See Other
  1063.                   | "304"   ; Not Modified
  1064.                   | "305"   ; Use Proxy
  1065.                   | "400"   ; Bad Request
  1066.                   | "401"   ; Unauthorized
  1067.                   | "402"   ; Payment Required
  1068.                   | "403"   ; Forbidden
  1069.                   | "404"   ; Not Found
  1070.                   | "405"   ; Method Not Allowed
  1071.                   | "406"   ; Not Acceptable
  1072.                   | "407"   ; Proxy Authentication Required
  1073.                   | "408"   ; Request Time-out
  1074.                   | "409"   ; Conflict
  1075.                   | "410"   ; Gone
  1076.                   | "411"   ; Length Required
  1077.                   | "412"   ; Precondition Failed
  1078.                   | "413"   ; Request Entity Too Large
  1079.                   | "414"   ; Request-URI Too Large
  1080.                   | "415"   ; Unsupported Media Type
  1081.                   | "451"   ; Parameter Not Understood}
  1082.                   | "452"   ; Conference Not Found}
  1083.                   | "453"   ; Not Enough Bandwidth}
  1084.                   | "45x"   ; Session Not Found}
  1085.                   | "45x"   ; Method Not Valid in This State}
  1086.                   | "45x"   ; Header Field Not Valid for Resource}
  1087.                   | "45x"   ; Invalid Range}
  1088.                   | "45x"   ; Parameter Is Read-Only}
  1089.                   | "500"   ; Internal Server Error
  1090.                   | "501"   ; Not Implemented
  1091.                   | "502"   ; Bad Gateway
  1092.                   | "503"   ; Service Unavailable
  1093.                   | "504"   ; Gateway Time-out
  1094.                   | "505"   ; HTTP Version not supported
  1095.                   | extension-code
  1096.  
  1097.  
  1098.  
  1099.  
  1100. H. Schulzrinne, A. Rao, R. Lanphier                            Page 20
  1101.  
  1102.  
  1103. INTERNET-DRAFT                   RTSP                February 21, 1997
  1104.  
  1105.  
  1106.    extension-code = 3DIGIT
  1107.  
  1108.    Reason-Phrase  = *<TEXT, excluding CR, LF>
  1109.  
  1110. RTSP status codes are extensible. RTSP applications are not required to
  1111. understand the meaning of all registered status codes, though such
  1112. understanding is obviously desirable. However, applications MUST understand
  1113. the class of any status code, as indicated by the first digit, and treat
  1114. any unrecognized response as being equivalent to the x00 status code of
  1115. that class, with the exception that an unrecognized response MUST NOT be
  1116. cached. For example, if an unrecognized status code of 431 is received by
  1117. the client, it can safely assume that there was something wrong with its
  1118. request and treat the response as if it had received a 400 status code. In
  1119. such cases, user agents SHOULD present to the user the entity returned with
  1120. the response, since that entity is likely to include human-readable
  1121. information which will explain the unusual status.
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155. H. Schulzrinne, A. Rao, R. Lanphier                            Page 21
  1156.  
  1157.  
  1158. INTERNET-DRAFT                   RTSP                February 21, 1997
  1159.  
  1160.  
  1161.  Code reason                         HELLO GET  SETUP  PLAY  RECORD PAUSE
  1162.  100  Continue                       x     x    x      x     x      x
  1163.  200  OK                             x     x    x      x     x      x
  1164.  300  Multiple Choices               x     x    x      x     x
  1165.  301  Moved Permanently              x     x    x      x     x
  1166.  302  Moved Temporarily              x     x    x      x     x
  1167.  303  See Other                      x     x    x      x     x
  1168.  304  Not Modified                   x     x    x      x     x
  1169.  305  Use Proxy                      x     x    x      x     x
  1170.  400  Bad Request                    x     x    x      x     x      x
  1171.  401  Unauthorized                   x     x    x      x     x      x
  1172.  402  Payment Required               x     x    x      x     x      x
  1173.  403  Forbidden                      x     x    x      x     x
  1174.  404  Not Found                      x     x    x      x     x
  1175.  405  Method Not Allowed             x     x    x      x     x      x
  1176.  406  Not Acceptable                 x     x    x      x     x
  1177.  407  Proxy Authentication Required  x     x    x      x     x      x
  1178.  408  Request Timeout                x     x    x      x     x      x
  1179.  409  Conflict
  1180.  410  Gone                           x     x    x      x     x      x
  1181.  411  Length Required                x     x    x
  1182.  412  Precondition Failed            x     x
  1183.  413  Request Entity Too Large       x     x
  1184.  414  Request-URI Too Long           x     x    x      x     x      x
  1185.  415  Unsupported Media Type         x     x
  1186.  45x  Only Valid for Stream          x     x    x
  1187.  45x  Invalid parameter
  1188.  45x  Not Enough Bandwidth                      x
  1189.  45x  Illegal Conference Identifier
  1190.  45x  Illegal Session Identifier                x      x     x      x
  1191.  45x  Parameter Is Read-Only
  1192.  45x  Header Field Not Valid
  1193.  500  Internal Server Error          x     x    x      x     x      x
  1194.  501  Not Implemented                x     x    x      x     x      x
  1195.  502  Bad Gateway                    x     x    x      x     x      x
  1196.  503  Service Unavailable            x     x    x      x     x      x
  1197.  504  Gateway Timeout                x     x    x      x     x      x
  1198.  505  RTSP Version Not Supported     x     x    x      x     x      x
  1199.  
  1200. Table 1: Status codes and their usage with RTSP methods
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210. H. Schulzrinne, A. Rao, R. Lanphier                            Page 22
  1211.  
  1212.  
  1213. INTERNET-DRAFT                   RTSP                February 21, 1997
  1214.  
  1215.  
  1216.  Code reason                 CLOSE  REDIRECT  GET_PARAMETER SET_PARAMETER
  1217.  100  Continue               x      x         x             x
  1218.  200  OK                     x      x         x             x
  1219.  300  Multiple Choices              x         x             x
  1220.  301  Moved Permanently      x      x         x             x
  1221.  302  Moved Temporarily      x      x         x             x
  1222.  303  See Other              x      x         x             x
  1223.  304  Not Modified           x      x         x             x
  1224.  305  Use Proxy              x      x         x             x
  1225.  400  Bad Request            x      x         x             x
  1226.  401  Unauthorized                  x         x             x
  1227.  402  Payment Required              x         x             x
  1228.  403  Forbidden              x      x         x             x
  1229.  404  Not Found              x      x         x             x
  1230.  405  Method Not Allowed     x      x         x             x
  1231.  406  Not Acceptable         x      x         x             x
  1232.  
  1233.  407  Proxy Authentication   x      x         x             x
  1234.       Required
  1235.  408  Request Timeout        x      x         x             x
  1236.  409  Conflict                                x             x
  1237.  410  Gone                                    x             x
  1238.  411  Length Required                         x             x
  1239.  412  Precondition Failed                     x             x
  1240.  
  1241.  413  Request Entity Too     x      x         x             x
  1242.       Large
  1243.  414  Request-URI Too Long   x      x         x             x
  1244.  415  Unsupported Media Type
  1245.  45x  Only Valid for Stream
  1246.  45x  Invalid parameter
  1247.  45x  Not Enough Bandwidth
  1248.  
  1249.  45x  Illegal Conference
  1250.       Identifier
  1251.  
  1252.  45x  Illegal Session        x      x
  1253.       Identifier
  1254.  45x  Parameter Is Read-Only                                x
  1255.  45x  Header Field Not Valid
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265. H. Schulzrinne, A. Rao, R. Lanphier                            Page 23
  1266.  
  1267.  
  1268. INTERNET-DRAFT                   RTSP                February 21, 1997
  1269.  
  1270.  
  1271.  500  Internal Server Error  x      x         x             x
  1272.  501  Not Implemented        x      x         x             x
  1273.  502  Bad Gateway            x      x         x             x
  1274.  503  Service Unavailable    x      x         x             x
  1275.  504  Gateway Timeout        x      x         x             x
  1276.  
  1277.  505  RTSP Version Not       x      x         x             x
  1278.       Supported
  1279.  
  1280. Table 2: Status codes and their usage with RTSP methods
  1281.  
  1282. 6.1.2 Response Header Fields
  1283.  
  1284. The response-header fields allow the request recipient to pass additional
  1285. information about the response which cannot be placed in the Status-Line.
  1286. These header fields give information about the server and about further
  1287. access to the resource identified by the Request-URI.
  1288.  
  1289.   response-header = Location              ; Section
  1290.                     | Proxy-Authenticate  ; Section
  1291.                     | Public              ; Section
  1292.                     | Retry-After         ; Section
  1293.                     | Server              ; Section
  1294.                     | Vary                ; Section
  1295.                     | WWW-Authenticate    ; Section
  1296.  
  1297. Response-header field names can be extended reliably only in combination
  1298. with a change in the protocol version. However, new or experimental header
  1299. fields MAY be given the semantics of response-header fields if all parties
  1300. in the communication recognize them to be response-header fields.
  1301. Unrecognized header fields are treated as entity-header fields.
  1302.  
  1303. 7 Entity
  1304.  
  1305. Request and Response messages MAY transfer an entity if not otherwise
  1306. restricted by the request method or response status code. An entity
  1307. consists of entity-header fields and an entity-body, although some
  1308. responses will only include the entity-headers.
  1309.  
  1310. In this section, both sender and recipient refer to either the client or
  1311. the server, depending on who sends and who receives the entity.
  1312.  
  1313. 7.1 Entity Header Fields
  1314.  
  1315. Entity-header fields define optional metainformation about the entity-body
  1316. or, if no body is present, about the resource identified by the request.
  1317.  
  1318.  
  1319.  
  1320. H. Schulzrinne, A. Rao, R. Lanphier                            Page 24
  1321.  
  1322.  
  1323. INTERNET-DRAFT                   RTSP                February 21, 1997
  1324.  
  1325.  
  1326.   entity-header  = Allow                    ; Section 14.7
  1327.                    | Content-Encoding         ; Section 14.12
  1328.                    | Content-Language         ; Section 14.13
  1329.                    | Content-Length           ; Section 14.14
  1330.                    | Content-Type             ; Section 14.18
  1331.                    | Expires                  ; Section 14.21
  1332.                    | Last-Modified            ; Section 14.29
  1333.                    | extension-header
  1334.  
  1335.           extension-header = message-header
  1336.  
  1337. The extension-header mechanism allows additional entity-header fields to be
  1338. defined without changing the protocol, but these fields cannot be assumed
  1339. to be recognizable by the recipient. Unrecognized header fields SHOULD be
  1340. ignored by the recipient and forwarded by proxies.
  1341.  
  1342. 7.2 Entity Body
  1343.  
  1344. See [H7.2]
  1345.  
  1346. 8 Connections
  1347.  
  1348. RTSP requests can be transmitted in several different ways:
  1349.  
  1350.    * persistent transport connections used for several request-response
  1351.      transactions;
  1352.    * one connection per request/response transaction;
  1353.    * connectionless mode.
  1354.  
  1355. The type of transport connection is defined by the RTSP URI (Section 3.2).
  1356. For the scheme ``rtsp'', a persistent connection is assumed, while the
  1357. scheme ``rtspu'' calls for RTSP requests to be send without setting up a
  1358. connection.
  1359.  
  1360. Unlike HTTP, RTSP allows the media server to send requests to the media
  1361. client. However, this is only supported for persistent connections, as the
  1362. media server otherwise has no reliable way of reaching the client. Also,
  1363. this is the only way that requests from media server to client are likely
  1364. to traverse firewalls.
  1365.  
  1366. 8.1 Pipelining
  1367.  
  1368. A client that supports persistent connections or connectionless mode MAY
  1369. ``pipeline'' its requests (i.e., send multiple requests without waiting for
  1370. each response). A server MUST send its responses to those requests in the
  1371. same order that the requests were received.
  1372.  
  1373.  
  1374.  
  1375. H. Schulzrinne, A. Rao, R. Lanphier                            Page 25
  1376.  
  1377.  
  1378. INTERNET-DRAFT                   RTSP                February 21, 1997
  1379.  
  1380.  
  1381. 8.2 Reliability and Acknowledgements
  1382.  
  1383. Requests are acknowledged by the receiver unless they are sent to a
  1384. multicast group. If there is no acknowledgement, the sender may resend the
  1385. same message after a timeout of one round-trip time (RTT). The round-trip
  1386. time is estimated as in TCP (RFC TBD), with an initial round-trip value of
  1387. 500 ms. An implementation MAY cache the last RTT measurement as the initial
  1388. value for future connections. If a reliable transport protocol is used to
  1389. carry RTSP, the timeout value MAY be set to an arbitrarily large value.
  1390.  
  1391.      This can greatly increase responsiveness for proxies operating in
  1392.      local-area networks with small RTTs. The mechanism is defined
  1393.      such that the client implementation does not have be aware of
  1394.      whether a reliable or unreliable transport protocol is being
  1395.      used. It is probably a bad idea to have two reliability
  1396.      mechanisms on top of each other, although the RTSP RTT estimate
  1397.      is likely to be larger than the TCP estimate.
  1398.  
  1399. Each request carries a sequence number, which is incremented by one for
  1400. each request transmitted. If a request is repeated because of lack of
  1401. acknowledgement, the sequence number is incremented.
  1402.  
  1403.      This avoids ambiguities when computing round-trip time estimates.
  1404.  
  1405. [TBD: An initial sequence number negotiation needs to be added for UDP;
  1406. otherwise, a new stream connection may see a request be acknowledged by a
  1407. delayed response from an earlier ``connection''. This handshake can be
  1408. avoided with a sequence number containing a timestamp of sufficiently high
  1409. resolution.]
  1410.  
  1411. The reliability mechanism described here does not protect against
  1412. reordering. This may cause problems in some instances. For example, a CLOSE
  1413. followed by a PLAY has quite a different effect than the reverse.
  1414. Similarly, if a PLAY request arrives before all parameters are set due to
  1415. reordering, the media server would have to issue an error indication. Since
  1416. sequence numbers for retransmissions are incremented (to allow easy RTT
  1417. estimation), the receiver cannot just ignore out-of-order packets. [TBD:
  1418. This problem could be fixed by including both a sequence number that stays
  1419. the same for retransmissions and a timestamp for RTT estimation.]
  1420.  
  1421. Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
  1422. support UDP. The default port for the RTSP server is 554 for both UDP and
  1423. TCP.
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430. H. Schulzrinne, A. Rao, R. Lanphier                            Page 26
  1431.  
  1432.  
  1433. INTERNET-DRAFT                   RTSP                February 21, 1997
  1434.  
  1435.  
  1436. A number of RTSP packets destined for the same control end point may be
  1437. packed into a single lower-layer PDU or encapsulated into a TCP stream.
  1438. RTSP data MAY be interleaved with RTP and RTCP packets. Unlike HTTP, an
  1439. RTSP method header MUST contain a Content-Length whenever that method
  1440. contains a payload. Otherwise, an RTSP packet is terminated with an empty
  1441. line immediately following the method header.
  1442.  
  1443. 9 Method Definitions
  1444.  
  1445. The method token indicates the method to be performed on the resource
  1446. identified by the Request-URI. The method is case-sensitive. New methods
  1447. may be defined in the future. Method names may not start with a $ character
  1448. (decimal 24) and must be a token.
  1449.  
  1450.  method        direction   requirement
  1451.  GET           C->S        recommended
  1452.  SETUP         C->S        recommended
  1453.  PLAY          C->S        required
  1454.  PAUSE         C->S        recommended
  1455.  CLOSE         C->S        required
  1456.  REDIRECT      S->C        optional
  1457.  SESSION       S->C        optional
  1458.  RECORD        C->S        optional
  1459.  BYE           C->S        required?
  1460.  SET_PARAMETER C->S, S->C  optional
  1461.  GET_PARAMETER C->S, S->C  optional
  1462.  
  1463. Table 3: Overview of RTSP methods
  1464.  
  1465.      HS: PAUSE is recommend, but not required in that a fully
  1466.      functional server can be built that does not support this method,
  1467.      for example, for live feeds. Similarly, SETUP is not needed for a
  1468.      server that only handles multicast events with transport
  1469.      parameters set outside of RTSP. GET and BYE are controversial.
  1470.  
  1471. 9.1 HELLO
  1472.  
  1473. RTSP sessions MAY be initiated by a HELLO message. The request URI is "*"
  1474. to indicate that the request pertains to the session itself. The primary
  1475. use of the HELLO message is to verify the identity of the sender to the
  1476. receiver; both sides must authorize one another to enable full access to
  1477. server resources. Unauthorized clients may be disconnected or restricted to
  1478. a subset of server resources.
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485. H. Schulzrinne, A. Rao, R. Lanphier                            Page 27
  1486.  
  1487.  
  1488. INTERNET-DRAFT                   RTSP                February 21, 1997
  1489.  
  1490.  
  1491. In addition, if the optional Require header is present, option tags within
  1492. the header indicate features needed by the requestor that are not required
  1493. at the version level of the protocol.
  1494.  
  1495. Example 1:
  1496.  
  1497.   C->S:  HELLO * RTSP/1.0 1
  1498.          Require: implicit-play, record-feature
  1499.          Transport-Require: switch-to-udp-control, gzipped-messages
  1500.  
  1501. Note that these are fictional features (though we may want to make them
  1502. real one day).
  1503.  
  1504. Example 2 (using RFC2069-style authentication only as an example):
  1505.  
  1506.   S->C: HELLO * RTSP/1.0 1
  1507.         Authenticate: Digest realm="testrealm@host.com",
  1508.           nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  1509.           opaque="5ccc069c403ebaf9f0171e9517f40e41"
  1510.  
  1511. Response:
  1512.  
  1513. Possible errors: 401, Parameter Not Understood
  1514.  
  1515. Examples:
  1516.  
  1517.   S->C:  RTSP/1.0 200 1 OK
  1518.          Date: 23 Jan 1997 15:35:06 GMT
  1519.          Nack-Transport-Require: switch-to-udp-control
  1520.  
  1521. Note that these are fictional features (though we may want to make them
  1522. real one day).
  1523.  
  1524. Example 2 (using RFC2069-style authentication only as an example):
  1525.  
  1526.   C->S: RTSP/1.0 401 1 Unauthorized
  1527.         Authorization: Digest username="Mufasa",
  1528.             realm="testrealm@host.com",
  1529.             nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  1530.             uri="/dir/index.html",
  1531.             response="e966c932a9242554e42c8ee200cec7f6",
  1532.             opaque="5ccc069c403ebaf9f0171e9517f40e41"
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540. H. Schulzrinne, A. Rao, R. Lanphier                            Page 28
  1541.  
  1542.  
  1543. INTERNET-DRAFT                   RTSP                February 21, 1997
  1544.  
  1545.  
  1546.      HS: I consider HELLO superfluous, not fully specified and just
  1547.      complicating client and server. It is also not clear how this is
  1548.      supposed to work when a client connects to the server, since it
  1549.      can't know ahead of time whether the server will issus a HELLO
  1550.      request. So it may connect, issue a SETUP, be refused and then
  1551.      somehow guess that it's supposed to wait for HELLO.
  1552.      Authentication of the client can be readily achieved by standard
  1553.      HTTP-like methods. On either retrieving the session description
  1554.      or the first SETUP, the server would refuse with 401, supply the
  1555.      authentication methods (and nonces) it is willing to accept and
  1556.      wait for the request to be re-issued with proper authentication.
  1557.      As with standard web browser, a client can cache the
  1558.      authentication message for efficiency.
  1559.  
  1560.      Similarly, the client can ask the server to authenticate itself
  1561.      with the first request.
  1562.  
  1563.      Feature announcement can be done using standard HTTP mechanism,
  1564.      with a well-defined registration mechanism for feature names.
  1565.  
  1566.      RL: HELLO offers the opportunity to negotiate server features
  1567.      prior to actually needing them. A client may wish to poll a
  1568.      server for its features without actually causing any action to
  1569.      occur, and HELLO offers that opportunity.
  1570.  
  1571. 9.2 GET
  1572.  
  1573. The GET method retrieves a session description from a server. It may use
  1574. the Accept header to specify the session description formats that the
  1575. client understands.
  1576.  
  1577. If the media server has previously been invited to a conference by the
  1578. client, the GET request SHOULD contain the Conference header field. If the
  1579. GET request contains a conference identifier, the media server MAY locate
  1580. the conference description and use the multicast addresses and port numbers
  1581. supplied in that description. The media server SHOULD only offer media
  1582. types corresponding to the media types currently active within the
  1583. conference. If the media server has no local reference to this conference,
  1584. it returns status code 452.
  1585.  
  1586. The conference invitation should also contain an indication whether the
  1587. media server is expected to receive or generate media, or both. (A VCR-like
  1588. device would support both directions.) If the invitation does not contain
  1589. an indication of the operations to be performed, the media server should
  1590. accept and then reject inappropriate operations.
  1591.  
  1592.  
  1593.  
  1594.  
  1595. H. Schulzrinne, A. Rao, R. Lanphier                            Page 29
  1596.  
  1597.  
  1598. INTERNET-DRAFT                   RTSP                February 21, 1997
  1599.  
  1600.  
  1601. The server responds with a description of the requested resource.
  1602.  
  1603. Example:
  1604.  
  1605.   C->S: GET rtsp://server.example.com/fizzle/foo RTSP/1.0 312
  1606.         Accept: application/sdp, application/sdf, application/mheg
  1607.         Bandwidth: 4000
  1608.  
  1609.   S->C: RTSP/1.0 200 312 OK
  1610.         Date: 23 Jan 1997 15:35:06 GMT
  1611.         Content-Type: application/sdp
  1612.         Content-Length: 376
  1613.  
  1614.         v=0
  1615.         o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
  1616.         s=SDP Seminar
  1617.         i=A Seminar on the session description protocol
  1618.         u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
  1619.         e=mjh@isi.edu (Mark Handley)
  1620.         c=IN IP4 224.2.17.12/127
  1621.         t=2873397496 2873404696
  1622.         a=recvonly
  1623.         m=audio 3456 RTP/AVP 0
  1624.         m=video 2232 RTP/AVP 31
  1625.         m=whiteboard 32416 UDP WB
  1626.         a=orient:portrait
  1627.  
  1628. or
  1629.  
  1630.   S->C: RTSP/1.0 200 312 OK
  1631.         Date: 23 Jan 1997 15:35:06 GMT
  1632.         Content-Type: application/x-rtsp-mh
  1633.         Content-Length: 2782
  1634.  
  1635.         <2782 octets of data containing stream descriptions and
  1636.         headers for the requested presentation>
  1637.  
  1638.      The authors disagree amongst themselves as to whether having an
  1639.      GET method within RTSP is appropriate. The alternative would be
  1640.      that the stream header would be done as an HTTP GET, and then
  1641.      RTSP would be used for SETUP, PLAY, etc. RL believes there are a
  1642.      number of reasons why a GET method is appropriate within RTSP:
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650. H. Schulzrinne, A. Rao, R. Lanphier                            Page 30
  1651.  
  1652.  
  1653. INTERNET-DRAFT                   RTSP                February 21, 1997
  1654.  
  1655.  
  1656.         * An RTSP GET is a request for header information, while an
  1657.           HTTP GET is a request for the entire file. For instance, an
  1658.           RTSP GET on a Quicktime file with the name foo.mov would
  1659.           mean "please send me the header and packetization
  1660.           information for foo.mov", whereas an HTTP GET for that file
  1661.           would mean "please send me foo.mov".
  1662.         * Assuming the client only has an URL to a resource, it is
  1663.           highly desireable to get to the point where the client is
  1664.           actually receiving data all over one connection. Though this
  1665.           would be possible if one assumed that one can multiplex RTSP
  1666.           and HTTP on the same connection, there is a question of how
  1667.           much of a web server would have to be supported in order to
  1668.           fulfill this simpler requirement.
  1669.         * Since the RTSP GET contains information such as codec,
  1670.           packetization, total size, and whether the clip is live or
  1671.           stored, it is important to insure integrity between the
  1672.           session description and the media it represents. This
  1673.           information may be cached by HTTP proxies, but it would be
  1674.           needed by caching RTSP proxies.
  1675.  
  1676.      RL and AR feel that the scope and applicability of this message
  1677.      should be limited, and therefore, it may be appropriate to come
  1678.      up with another name for this message.
  1679.  
  1680.      HS believes that this only works if GET is required. Otherwise,
  1681.      the client has no way of knowing whether to first send a GET or
  1682.      SETUP. The easy alternative is to have any further descriptive
  1683.      information that is necessary encoded in the session description.
  1684.      Thus, the naming does not matter; the resource description can
  1685.      either have a separate name or the same name if the server can
  1686.      distinguish variants based on the requested type, as modern web
  1687.      servers can. (A single URL can return different objects depending
  1688.      on the content of the Accept fields.) It appears likely that the
  1689.      RTSP GET will over time acquire all the functionality of the HTTP
  1690.      GET and thus lead to unnecessary duplication. If the description
  1691.      is lengthy, the ability to use HTTP caches is likely to
  1692.      compensate for any additional latency due to having to open two
  1693.      streams. Also, note that relying on HTTP get does not mean that
  1694.      this has to be a separate server.
  1695.  
  1696. 9.3 SETUP
  1697.  
  1698. The SETUP request for a URI specifies the transport mechanism to be used
  1699. for the streamed media. Note that SETUP makes sense only for an individual
  1700. media stream, rather than an aggregate. A client can issue a SETUP request
  1701. for a stream that is already playing to change transport parameters.
  1702.  
  1703.  
  1704.  
  1705. H. Schulzrinne, A. Rao, R. Lanphier                            Page 31
  1706.  
  1707.  
  1708. INTERNET-DRAFT                   RTSP                February 21, 1997
  1709.  
  1710.  
  1711. If the optional Require header is present, option tags within the header
  1712. indicate features needed by the requestor that are not required at the
  1713. version level of the protocol. The Transport-Require header is used to
  1714. indicate proxy-sensitive features that MUST be stripped by the proxy to the
  1715. server if not supported. Furthermore, any Transport-Require header features
  1716. that are not supported by the proxy MUST be negatively acknowledged by the
  1717. proxy to the client if not supported.
  1718.  
  1719.      HS: In my opinion, the Require header should be replaced by PEP
  1720.      since PEP is standards-track, has more functionality and somebody
  1721.      already did the work.
  1722.  
  1723. The Transport header specifies the transports acceptable to the client for
  1724. data transmission; the response will contain the transport selected by the
  1725. server.
  1726.  
  1727.   C->S: SETUP foo/bar/baz.rm RTSP/1.0 302
  1728.         Transport: rtp/udp;port=458
  1729.  
  1730.   S->C: RTSP/1.0 200 302 OK
  1731.         Date: 23 Jan 1997 15:35:06 GMT
  1732.         Transport: cush/udp;port=458
  1733.  
  1734. 9.4 PLAY
  1735.  
  1736. The PLAY method tells the server to start sending data via the mechanism
  1737. specified in SETUP. A client MUST NOT issue a PLAY request until any
  1738. outstanding SETUP request have been acknowledged as successful.
  1739.  
  1740. A PLAY request without a Range header is legal. It starts playing a stream
  1741. from the beginning unless the stream has been paused. If a stream has been
  1742. paused via PAUSE, stream delivery resumes at the pause point. If a stream
  1743. is playing, such a PLAY request causes no further action and can be used by
  1744. the client to test server liveness.
  1745.  
  1746. The following example plays the whole session starting at SMPTE time code
  1747. 0:10:20 until the end of the clip.
  1748.  
  1749.   C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833
  1750.         Range: smpte=0:10:20-
  1751.  
  1752. For playing back a recording of a live event, it may be desirable to use
  1753. clock units:
  1754.  
  1755.   C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835
  1756.         Range: clock=19961108T142300Z-19961108T143520Z
  1757.  
  1758.  
  1759.  
  1760. H. Schulzrinne, A. Rao, R. Lanphier                            Page 32
  1761.  
  1762.  
  1763. INTERNET-DRAFT                   RTSP                February 21, 1997
  1764.  
  1765.  
  1766.   S->C: RTSP/1.0 200 833 OK
  1767.         Date: 23 Jan 1997 15:35:06 GMT
  1768.  
  1769. A media server only supporting playback MUST support the smpte format and
  1770. MAY support the clock format.
  1771.  
  1772.      RL says: We had considered optionally overloading PLAY with SETUP
  1773.      information. This would have potentially allowed a case where one
  1774.      could implement a minimal RTSP server that only handles the PLAY
  1775.      command. However, we decided that supporting that minimal of a
  1776.      server was problematic for a couple of reasons:
  1777.  
  1778.         * We must be able to negotiate the transport (i.e. have server
  1779.           acknowledgment) prior to actually needing to deal with the
  1780.           data. We don't want to have a server start spewing packets
  1781.           at us before we are ready to deal with them. The server
  1782.           acknowledgment with setup information MUST arrive before the
  1783.           first packet.
  1784.         * We need make sure that we aren't dealing with an allocation
  1785.           method every time we are dealing with PLAY. We anticipate
  1786.           the potential of dealing with PLAY frequently when a client
  1787.           chooses to issue several seeks, and so simplifying this
  1788.           message is imperative.
  1789.  
  1790.      HS says: PLAY without SETUP is useful and possible, in particular
  1791.      if the session description contains all necessary information,
  1792.      without options. The client knows whether it needs to configure
  1793.      transport parameters or not. For multicast delivery, for example,
  1794.      it likely would not have to set additional parameters. I doubt
  1795.      that allowing one additional parameter is going to greatly
  1796.      complicate or slow down a server.
  1797.  
  1798. 9.5 PAUSE
  1799.  
  1800. The PAUSE request causes the stream delivery to be interrupted (halted)
  1801. temporarily. If the request URL names a track, only playback and recording
  1802. of that track is halted. If the request URL names a presentation, delivery
  1803. of all currently active tracks is halted. After resuming playback or
  1804. recording, synchronization of the tracks MUST be maintained. Any server
  1805. resources are kept.
  1806.  
  1807.  
  1808.  
  1809.  
  1810.  
  1811.  
  1812.  
  1813.  
  1814.  
  1815. H. Schulzrinne, A. Rao, R. Lanphier                            Page 33
  1816.  
  1817.  
  1818. INTERNET-DRAFT                   RTSP                February 21, 1997
  1819.  
  1820.  
  1821. Example:
  1822.  
  1823.   C->S: PAUSE /fizzle/foo RTSP/1.0 834
  1824.  
  1825.   S->C: RTSP/1.0 200 834 OK
  1826.         Date: 23 Jan 1997 15:35:06 GMT
  1827.  
  1828. 9.6 CLOSE
  1829.  
  1830. Stop the stream delivery for the given URI, freeing the resources
  1831. associated with it. If the URI is the root node for this session, any
  1832. session identifier associated with the session is no longer valid. Unless
  1833. all transport parameters are defined by the session description, a SETUP
  1834. request has to be issued before the session can be played again.
  1835.  
  1836. Example:
  1837.  
  1838.   C->S: CLOSE /fizzle/foo RTSP/1.0 892
  1839.  
  1840.   S->C: RTSP/1.0 200 892 OK
  1841.  
  1842. 9.7 BYE
  1843.  
  1844. Terminate the session.
  1845.  
  1846. Example:
  1847.  
  1848.   C->S: BYE /movie RTSP/1.0 894
  1849.  
  1850.   S->C: RTSP/1.0 200 894 OK
  1851.         Date: 23 Jan 1997 15:35:06 GMT
  1852.  
  1853.      HS: I believe BYE to be unnecessary since CLOSE already frees
  1854.      resources and session descriptor.
  1855.  
  1856. 9.8 GET_PARAMETER
  1857.  
  1858. The requests retrieves the value value of a parameter of a session
  1859. component specified in the URI. Multiple parameters can be requested in the
  1860. message body using the content type text/rtsp-parameters. Note that
  1861. parameters include server and client statistics. [HS: registry of parameter
  1862. names for statistics and other purposes, possibly using the HTTP feature
  1863. registration mechanism.] A GET_PARAMETER with no entity body may be used to
  1864. test client or server liveness (``ping'').
  1865.  
  1866.  
  1867.  
  1868.  
  1869.  
  1870. H. Schulzrinne, A. Rao, R. Lanphier                            Page 34
  1871.  
  1872.  
  1873. INTERNET-DRAFT                   RTSP                February 21, 1997
  1874.  
  1875.  
  1876. Example:
  1877.  
  1878.   S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431
  1879.         Content-Type: text/rtsp-parameters
  1880.         Session: 1234
  1881.         Content-Length: 15
  1882.  
  1883.         packets_received
  1884.         jitter
  1885.  
  1886.   C->S: RTSP/1.0 200 431 OK
  1887.         Content-Length: 46
  1888.         Content-Type: text/rtsp-parameters
  1889.  
  1890.         packets_received: 10
  1891.         jitter: 0.3838
  1892.  
  1893. 9.9 SET_PARAMETER
  1894.  
  1895. This method requests to set the value of a parameter for a session
  1896. component specified by the URI.
  1897.  
  1898. A request SHOULD only contain a single parameter to allow the client to
  1899. determine why a particular request failed. A server MUST allow a parameter
  1900. to be set repeatedly to the same value, but it MAY disallow changing
  1901. parameter values.
  1902.  
  1903. Note: transport parameters for the media stream MUST only be set with the
  1904. SETUP command.
  1905.  
  1906.      Restricting setting transport parameters to SETUP is for the
  1907.      benefit of firewalls.
  1908.  
  1909.      The parameters are split in a fine-grained fashion so that there
  1910.      can be more meaningful error indications. However, it may make
  1911.      sense to allow the setting of several parameters if an atomic
  1912.      setting is desirable. Imagine device control where the client
  1913.      does not want the camera to pan unless it can also tilt to the
  1914.      right angle at the same time.
  1915.  
  1916. A SET_PARAMETER request without parameters can be used as a way to detect
  1917. client or server liveness.
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925. H. Schulzrinne, A. Rao, R. Lanphier                            Page 35
  1926.  
  1927.  
  1928. INTERNET-DRAFT                   RTSP                February 21, 1997
  1929.  
  1930.  
  1931. Example:
  1932.  
  1933.   C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421
  1934.         Content-type: text/rtsp-parameters
  1935.  
  1936.         fooparam: foostuff
  1937.         barparam: barstuff
  1938.  
  1939.   S->C: RTSP/1.0 450 421 Invalid Parameter
  1940.         Content-Length: 6
  1941.  
  1942.         barparam
  1943.  
  1944. 9.10 REDIRECT
  1945.  
  1946. A redirect request informs the client that it must connect to another
  1947. server location. It contains the mandatory header Location, which indicates
  1948. that the client should issue a GET for that URL. It may contain the
  1949. parameter Range, which indicates when the redirection takes effect.
  1950.  
  1951. Mandatory header: Location [XXX: add this to table if accepted]
  1952.  
  1953. Example: This request redirects traffic for this URI to the new server at
  1954. the given play time:
  1955.  
  1956.   S->C: REDIRECT /fizzle/foo RTSP/1.0 732
  1957.         Location: rtsp://bigserver.com:8001
  1958.         Range: clock=19960213T143205Z-
  1959.  
  1960. 9.11 SESSION
  1961.  
  1962. This request is used by a media server to send new media information to the
  1963. client. If a new media type is added to a session (e.g., during a live
  1964. event), the whole session description should be sent again, rather than
  1965. just the additional components.
  1966.  
  1967.      This allows the deletion of session components.
  1968.  
  1969. Example:
  1970.  
  1971.   S->C: SESSION /twister RTSP/1.0 902
  1972.         Session: 1234
  1973.         Content-Type: application/sdp
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980. H. Schulzrinne, A. Rao, R. Lanphier                            Page 36
  1981.  
  1982.  
  1983. INTERNET-DRAFT                   RTSP                February 21, 1997
  1984.  
  1985.  
  1986.         Session Description
  1987.  
  1988. 9.12 RECORD
  1989.  
  1990. This method initiates recording a range of media data according to the
  1991. session description. The timestamp reflects start and end time (UTC). If no
  1992. time range is given, use the start or end time provided in the session
  1993. description. If the session has already started, commence recording
  1994. immediately. The Conference header is mandatory.
  1995.  
  1996. A media server supporting recording of live events MUST support the clock
  1997. range format; the smpte format does not make sense.
  1998.  
  1999. In this example, the media server was previously invited to the conference
  2000. indicated.
  2001.  
  2002.   C->S:  RECORD /meeting/audio.en RTSP/1.0 954
  2003.          Session: 1234
  2004.          Conference: 128.16.64.19/32492374
  2005.  
  2006. 9.13 Embedded Binary Data
  2007.  
  2008. Binary packets such as RTP data are encapsulated by an ASCII dollar sign
  2009. (24 decimal), followed by a one-byte session identifier, followed by the
  2010. length of the encapsulated binary data as a binary, two-byte integer in
  2011. network byte order. The binary data follows immediately afterwards, without
  2012. a CRLF.
  2013.  
  2014. Status Codes Definitions
  2015.  
  2016. Where applicable, HTTP status [H10] codes are re-used. Status codes that
  2017. have the same meaning are not repeated here. See Tables 1 and 2 for a
  2018. listing of which status codes may be returned by which request.
  2019.  
  2020. 10.1 Client Error 4xx
  2021.  
  2022. 10.1.1 451 Parameter Not Understood
  2023.  
  2024. The recipient of the request does not support one or more parameters
  2025. contained in the request.
  2026.  
  2027. 10.1.2 452 Conference Not Found
  2028.  
  2029. The conference indicated by a Conference header field is unknown to the
  2030. media server.
  2031.  
  2032.  
  2033.  
  2034.  
  2035. H. Schulzrinne, A. Rao, R. Lanphier                            Page 37
  2036.  
  2037.  
  2038. INTERNET-DRAFT                   RTSP                February 21, 1997
  2039.  
  2040.  
  2041. 10.1.3 453 Not Enough Bandwidth
  2042.  
  2043. The request was refused since there was insufficient bandwidth. This may,
  2044. for example, be the result of a resource reservation failure.
  2045.  
  2046. 10.1.4 45x Session Not Found
  2047.  
  2048. 10.1.5 45x Method Not Valid in This State
  2049.  
  2050. 10.1.6 45x Header Field Not Valid for Resource
  2051.  
  2052. The server could not act on a required request header. For example, if PLAY
  2053. contains the Range header field, but the stream does not allow seeking.
  2054.  
  2055. 10.1.7 45x Invalid Range
  2056.  
  2057. The Range value given is out of bounds, e.g., beyond the end of the
  2058. presentation.
  2059.  
  2060. 10.1.8 45x Parameter Is Read-Only
  2061.  
  2062. The parameter to be set by SET_PARAMETER can only be read, but not
  2063. modified.
  2064.  
  2065. 11 Header Field Definitions
  2066.  
  2067. HTTP/1.1 or other, non-standard header fields not listed here currently
  2068. have no well-defined meaning and SHOULD be ignored by the recipient.
  2069.  
  2070. Tables 4 and 5 summarize the header fields used by RTSP. Type ``R''
  2071. designates requests, type ``r'' responses. Fields marked with ``x'' MUST be
  2072. implemented by the recipient. If the field content does not apply to the
  2073. particular resource, the server MUST return status 45x (Header Field Not
  2074. Valid for Resource).
  2075.  
  2076.  
  2077.  
  2078.  
  2079.  
  2080.  
  2081.  
  2082.  
  2083.  
  2084.  
  2085.  
  2086.  
  2087.  
  2088.  
  2089.  
  2090. H. Schulzrinne, A. Rao, R. Lanphier                            Page 38
  2091.  
  2092.  
  2093. INTERNET-DRAFT                   RTSP                February 21, 1997
  2094.  
  2095.  
  2096.                    type  HELLO  GET  SETUP PLAY  RECORD  PAUSE
  2097.  Accept            R            x
  2098.  Accept-Encoding   R            x
  2099.  Accept-Language   R            x    o     o
  2100.  Authorization     R     o      o    o     o     o       o
  2101.  Bandwidth         R                 o
  2102.  Blocksize         R                 o
  2103.  Conference        R            o    o     ?     ?       ?
  2104.  Connection        Rr           x    x     x     x       x
  2105.  Content-Encoding  Rr           x
  2106.  Content-Length    Rr           x
  2107.  Content-Type      Rr           x
  2108.  Date              Rr    o      o    o     o     o       o
  2109.  If-Modified-Since R            o
  2110.  Last-Modified     r            o
  2111.  Public            r     o      o    o     o     o       o
  2112.  Range             R                       x     x
  2113.  Referer           R     o      o    o     o     o       o
  2114.  Require           R     x      o    x     o     o       o
  2115.  Retry-After       r     o      o    o     o     o       o
  2116.  Session           Rr                x     x     x       x
  2117.  Server            r     o      o    o     o     o       o
  2118.  Speed             Rr                      o     o
  2119.  Transport         Rr                x
  2120.  Transport-Require R     x      o    x     o     o       o
  2121.  User-Agent        R     o      o    o     o     o       o
  2122.  Via               Rr    o      o    o     o     o       o
  2123.  WWW-Authenticate  r     o      o    o     o     o       o
  2124.  
  2125. Table 4: Overview of RTSP header fields for GET, SETUP, PLAY, RECORD and
  2126. PAUSE
  2127.  
  2128.  
  2129.  
  2130.  
  2131.  
  2132.  
  2133.  
  2134.  
  2135.  
  2136.  
  2137.  
  2138.  
  2139.  
  2140.  
  2141.  
  2142.  
  2143.  
  2144.  
  2145. H. Schulzrinne, A. Rao, R. Lanphier                            Page 39
  2146.  
  2147.  
  2148. INTERNET-DRAFT                   RTSP                February 21, 1997
  2149.  
  2150.  
  2151.                    CLOSE  REDIRECT  GET_PARAMETER  SET_PARAMETER
  2152.  Accept
  2153.  Accept-Encoding
  2154.  Accept-Language
  2155.  Authorization     o      o         o              o
  2156.  Bandwidth
  2157.  Blocksize
  2158.  Conference
  2159.  Connection        x      x         x              x
  2160.  Content-Encoding  x      x         x              x
  2161.  Content-Length    x      x         x              x
  2162.  Content-Type      x      x         x              x
  2163.  Date              o      o         o              o
  2164.  If-Modified-Since
  2165.  Last-Modified
  2166.  Public            o      o         o              o
  2167.  Range
  2168.  Referer           o      o         o              o
  2169.  Retry-After       o      o         o              o
  2170.  Session           x      x         x              x
  2171.  Server            o      o         o              o
  2172.  Speed
  2173.  Transport
  2174.  User-Agent        o      o         o              o
  2175.  Via               o      o         o              o
  2176.  WWW-Authenticate  o      o         o              o
  2177.  
  2178. Table 5: Overview of RTSP header fields for PAUSE, CLOSE, GET_PARAMETER and
  2179. SET_PARAMETER
  2180.  
  2181. 11.1 Accept
  2182.  
  2183. The Accept request-header field can be used to specify certain session
  2184. description content types which are acceptable for the response.
  2185.  
  2186.      The ``level'' parameter for session descriptions is properly
  2187.      defined as part of the MIME type registration, not here.
  2188.  
  2189.  
  2190.  
  2191.  
  2192.  
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200. H. Schulzrinne, A. Rao, R. Lanphier                            Page 40
  2201.  
  2202.  
  2203. INTERNET-DRAFT                   RTSP                February 21, 1997
  2204.  
  2205.  
  2206. See [H14.1] for syntax.
  2207.  
  2208. Example of use:
  2209.  
  2210. Accept: application/sdf, application/sdp;level=2
  2211.  
  2212. 11.2 Accept-Encoding
  2213.  
  2214. See [H14.3]
  2215.  
  2216. 11.3 Accept-Language
  2217.  
  2218. See [H14.4]. Note that the language specified applies to the session
  2219. description, not the media content.
  2220.  
  2221. 11.4 Allow
  2222.  
  2223. The Allow response header field lists the methods supported by the resource
  2224. identified by the request-URI. The purpose of this field is to strictly
  2225. inform the recipient of valid methods associated with the resource. An
  2226. Allow header field must be present in a 405 (Method not allowed) response.
  2227.  
  2228. Example of use:
  2229.  
  2230.   Allow: SETUP, PLAY, RECORD, SET_PARAMETER
  2231.  
  2232. 11.5 Authorization
  2233.  
  2234. See [H14.8]
  2235.  
  2236. 11.6 Bandwidth
  2237.  
  2238. The Bandwidth request header field describes the estimated bandwidth
  2239. available to the client, expressed as a positive integer and measured in
  2240. bits per second.
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254.  
  2255. H. Schulzrinne, A. Rao, R. Lanphier                            Page 41
  2256.  
  2257.  
  2258. INTERNET-DRAFT                   RTSP                February 21, 1997
  2259.  
  2260.  
  2261.   Bandwidth  = "Bandwidth" ":" 1*DIGIT
  2262.  
  2263. Example:
  2264.  
  2265.   Bandwidth: 4000
  2266.  
  2267. 11.7 Blocksize
  2268.  
  2269. This request header field is sent from the client to the media server
  2270. asking the server for a particular media packet size. This packet size does
  2271. not include lower-layer headers such as IP, UDP, or RTP. The server is free
  2272. to use a blocksize which is lower than the one requested. The server MAY
  2273. truncate this packet size to the closest multiple of the minimum
  2274. media-specific block size or overrides it with the media specific size if
  2275. necessary. The block size is a strictly positive decimal number and
  2276. measured in octets. The server only returns an error (416) if the value is
  2277. syntactically invalid.
  2278.  
  2279. 11.8 Conference
  2280.  
  2281. This request header field establishes a logical connection between a
  2282. conference, established using non-RTSP means, and an RTSP stream.
  2283.  
  2284.   Conference = "Conference" ":" conference-id
  2285.  
  2286. Example:
  2287.  
  2288.   Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
  2289.  
  2290. 11.9 Content-Encoding
  2291.  
  2292. See [H14.12]
  2293.  
  2294. 11.10 Content-Length
  2295.  
  2296. This field contains the length of the content of the method (i.e. after the
  2297. double CRLF following the last header). Unlike HTTP, it MUST be included in
  2298. all messages that carry content beyond the header portion of the message.
  2299. It is interpreted according to [H14.14].
  2300.  
  2301. 11.11 Content-Type
  2302.  
  2303. See [H14.18]. Note that the content types suitable for RTSP are likely to
  2304. be restricted in practice to session descriptions and parameter-value
  2305. types.
  2306.  
  2307.  
  2308.  
  2309.  
  2310. H. Schulzrinne, A. Rao, R. Lanphier                            Page 42
  2311.  
  2312.  
  2313. INTERNET-DRAFT                   RTSP                February 21, 1997
  2314.  
  2315.  
  2316. 11.12 Date
  2317.  
  2318. See [H14.19].
  2319.  
  2320. 11.13 If-Modified-Since
  2321.  
  2322. See [H14.24]. If the request URL refers to a presentation rather than a
  2323. track, the server is to return the presentation if any of the track has
  2324. been modified since the time stated in the header field.
  2325.  
  2326. 11.14 Last-modified
  2327.  
  2328. The Last-Modified entity-header field indicates the date and time at which
  2329. the origin server believes the variant was last modified. See [H14.29]. If
  2330. the request URI refers to an aggregate, the field indicates the last
  2331. modification time across all leave nodes of that aggregate.
  2332.  
  2333. 11.15 Location
  2334.  
  2335. See [H14.30].
  2336.  
  2337. 11.16 Range
  2338.  
  2339. This request header field specifies a range of time. The range can be
  2340. specified in a number of units. This specification defines the smpte (see
  2341. Section 3.4) and clock (see Section 3.5) range units. Within RTSP, byte
  2342. ranges [H14.36.1] are not meaningful and MUST NOT be used.
  2343.  
  2344.   Range = "Range" ":" 1#ranges-specifier
  2345.  
  2346.   ranges-specifier = utc-range | smpte-range
  2347.  
  2348. Example:
  2349.  
  2350.   Range: clock=19960213T143205Z-
  2351.  
  2352. 11.17 Require
  2353.  
  2354. The Require header is used by clients to query the server about features
  2355. that it may or may not support. The server MUST respond to this header by
  2356. negatively acknowledging those features which are NOT supported in the
  2357. Unsupported header.
  2358.  
  2359.      HS: Naming of features - yet another name space. I believe this
  2360.      header field to be redundant. PEP should be used instead.
  2361.  
  2362.  
  2363.  
  2364.  
  2365. H. Schulzrinne, A. Rao, R. Lanphier                            Page 43
  2366.  
  2367.  
  2368. INTERNET-DRAFT                   RTSP                February 21, 1997
  2369.  
  2370.  
  2371. For example
  2372.  
  2373. C->S:   SETUP /foo/bar/baz.rm RTSP/1.0 302
  2374.         Require: funky-feature
  2375.         Funky-Parameter: funkystuff
  2376.  
  2377. S->C:   RTSP/1.0 200 506 Option not supported
  2378.         Unsupported: funky-feature
  2379.  
  2380. C->S:   SETUP /foo/bar/baz.rm RTSP/1.0 303
  2381.  
  2382. S->C:   RTSP/1.0 200 303 OK
  2383.  
  2384. This is to make sure that the client-server interaction will proceed
  2385. optimally when all options are understood by both sides, and only slow down
  2386. if options aren't understood (as in the case above). For a well-matched
  2387. client-server pair, the interaction proceeds quickly, saving a round-trip
  2388. often required by negotiation mechanisms. In addition, it also removes
  2389. state ambiguity when the client requires features that the server doesn't
  2390. understand.
  2391.  
  2392. 11.18 Unsupported
  2393.  
  2394. See Section 11.17 for a usage example.
  2395.  
  2396.      HS: same caveat as for Require applies.
  2397.  
  2398. 11.19 Nack-Transport-Require
  2399.  
  2400. Negative acknowledgement of features not supported by the server. If there
  2401. is a proxy on the path between the client and the server, the proxy MUST
  2402. insert a message reply with an error message 506 (Feature not supported).
  2403.  
  2404.      HS: Same caveat as for Require applies.
  2405.  
  2406. 11.20 Transport-Require
  2407.  
  2408. The Transport-Require header is used to indicate proxy-sensitive features
  2409. that MUST be stripped by the proxy to the server if not supported.
  2410. Furthermore, any Transport-Require header features that are not supported
  2411. by the proxy MUST be negatively acknowledged by the proxy to the client if
  2412. not supported.
  2413.  
  2414. See Section 11.17 for more details on the mechanics of this message and a
  2415. usage example.
  2416.  
  2417.  
  2418.  
  2419.  
  2420. H. Schulzrinne, A. Rao, R. Lanphier                            Page 44
  2421.  
  2422.  
  2423. INTERNET-DRAFT                   RTSP                February 21, 1997
  2424.  
  2425.  
  2426.      HS: Same caveat as for Require applies.
  2427.  
  2428. 11.21 Retry-After
  2429.  
  2430. See [H14.38].
  2431.  
  2432. 11.22 Speed
  2433.  
  2434. This request header fields parameter requests the server to deliver data to
  2435. the client at a particular speed, contingent on the server's ability and
  2436. desire to serve the media stream at the given speed. Implementation by the
  2437. server is OPTIONAL. The default is the bit rate of the stream.
  2438.  
  2439. The parameter value is expressed as a decimal ratio, e.g., a value of 2.0
  2440. indicates that data is to be delivered twice as fast as normal. A speed of
  2441. zero is invalid. A negative value indicates that the stream is to be played
  2442. back in reverse direction.
  2443.  
  2444.   speed = "Speed" ":" ["-"]1*DIGIT [ "." *DIGIT ]
  2445.  
  2446. Example:
  2447.  
  2448.   Speed: 2.5
  2449.  
  2450. 11.23 Server
  2451.  
  2452. See [H14.39]
  2453.  
  2454. 11.24 Session
  2455.  
  2456. This request and response header field identifies a session, started by the
  2457. media server in a SETUP or PLAY response and concluded by CLOSE on the
  2458. session URL (presentation). The session identifier is chosen by the media
  2459. server and has the same syntax as a conference identifier. Once a client
  2460. receives a Session identifier, it MUST return it for any request related to
  2461. that session.
  2462.  
  2463.  
  2464.  
  2465.  
  2466.  
  2467.  
  2468.  
  2469.  
  2470.  
  2471.  
  2472.  
  2473.  
  2474.  
  2475. H. Schulzrinne, A. Rao, R. Lanphier                            Page 45
  2476.  
  2477.  
  2478. INTERNET-DRAFT                   RTSP                February 21, 1997
  2479.  
  2480.  
  2481.      HS: This may be redundant with the standards-track HTTP state
  2482.      maintenance mechanism [1]. The equivalent way of doing this would
  2483.      be for the server to send Set-Cookie: Session="123"; Version=1;
  2484.      Path = "/twister" and for the client to return later Cookie:
  2485.      Session = "123"; $Version=1; $Path = "/twister". In the response
  2486.      to the CLOSE message, the server would simply send Set-Cookie:
  2487.      Session="123"; Version=1; Max-Age=0 to get rid of the cookie on
  2488.      the client side. Cookies also have a time-out, so that a server
  2489.      may limit the lifetime of a session at will. Unlike a web
  2490.      browser, a client would not store these states on disk.
  2491.  
  2492. 11.25 Transport
  2493.  
  2494. This request header indicates which transport protocol is to be used and
  2495. configures its parameters such as multicast, compression, multicast
  2496. time-to-live and destination port for a single stream. It sets those values
  2497. not already determined by a session description. In some cases, the session
  2498. description contains all necessary information. In those cases, a Transport
  2499. header field (and the SETUP request containing it) are not needed.
  2500.  
  2501. 'Interleaved' implies mixing the media stream with the control stream, in
  2502. whatever protocol is being used by the control stream. Currently, the
  2503. next-layer protocols RTP is defined. Parameters may be added to each
  2504. protocol, separated by a semicolon. For RTP, the boolean parameter
  2505. compressed is defined, indicating compressed RTP according to RFC XXXX. For
  2506. multicast UDP, the integer parameter ttl defines the time-to-live value to
  2507. be used. For UDP and TCP, the parameter port defines the port data is to be
  2508. sent to.
  2509.  
  2510. The SSRC parameter indicates the RTP SSRC value that should be (request)i
  2511. or will be (response) used by the media server. This parameter is only
  2512. valid for unicast transmission. It identifies the synchronization source to
  2513. be associated with the media stream.
  2514.  
  2515. The Transport header MAY also be used to change certain transport
  2516. parameters. A server MAY refuse to change parameters of an existing stream.
  2517.  
  2518. The server MAY return a Transport response header in the response to
  2519. indicate the values actually chosen.
  2520.  
  2521. A Transport request header field may contain a list of transport options
  2522. acceptable to the client. In that case, the server MUST return a single
  2523. option which was actually chosen. The Transport header field makes sense
  2524. only for an individual media stream, not a session.
  2525.  
  2526.  
  2527.  
  2528.  
  2529.  
  2530. H. Schulzrinne, A. Rao, R. Lanphier                            Page 46
  2531.  
  2532.  
  2533. INTERNET-DRAFT                   RTSP                February 21, 1997
  2534.  
  2535.  
  2536.   Transport = "Transport" ":"
  2537.               1#transport-protocol/upper-layer *parameter
  2538.   transport-protocol = "UDP" | "TCP"
  2539.   upper-layer  = "RTP"
  2540.   parameters = ";" "multicast" |
  2541.                ";" "compressed" |
  2542.                ";" "interleaved" |
  2543.                ";" "ttl" "=" ttl |
  2544.                ";" "port" "=" port |
  2545.                ";" "ssrc" "=" ssrc
  2546.   ttl        = 1*3(DIGIT)
  2547.   port       = 1*5(DIGIT)
  2548.   ssrc       = 8*8(HEX)
  2549.  
  2550. Example:
  2551.  
  2552.   Transport: udp/rtp;compressed;ttl=127;port=3456
  2553.  
  2554. 11.26 User-Agent
  2555.  
  2556. See [H14.42]
  2557.  
  2558. 11.27 Via
  2559.  
  2560. See [H14.44].
  2561.  
  2562. 11.28 WWW-Authenticate
  2563.  
  2564. See [H14.46].
  2565.  
  2566. 12 Caching
  2567.  
  2568. In HTTP, response-request pairs are cached. RTSP differs significantly in
  2569. that respect. Typically, responses are not cachable (except maybe for the
  2570. GET response), rather it is desirable for the media data (that is typically
  2571. delivered outside of RTSP) to be cached. Since the responses for anything
  2572. but GET and GET_PARAMETER do not return any data, caching is not an issue
  2573. for these requests.
  2574.  
  2575.  
  2576.  
  2577.  
  2578.  
  2579.  
  2580.  
  2581.  
  2582.  
  2583.  
  2584.  
  2585. H. Schulzrinne, A. Rao, R. Lanphier                            Page 47
  2586.  
  2587.  
  2588. INTERNET-DRAFT                   RTSP                February 21, 1997
  2589.  
  2590.  
  2591. HS: A proxy cache for RTSP would look not much different from an HTTP
  2592. cache. To the client, the proxy cache would appear like a regular media
  2593. server, to the media server like a client. Just like an HTTP cache has to
  2594. store the content type, content language, etc. for the objects it caches, a
  2595. media cache has to store the session description. Typically, a cache would
  2596. eliminate all transport-references (that is, multicast information) from
  2597. the session description, since these are independent of the data delivery
  2598. from the cache to the client. Information on the encodings remains the
  2599. same. If the cache is able to translate the cached media data, it would
  2600. create a new session description with all the encoding possibilities it can
  2601. offer.
  2602.  
  2603. 13 Examples
  2604.  
  2605. To emphasize that RTSP is independent of the session description format,
  2606. the following examples use a fictional session description language which
  2607. is chosen to be sufficiently self-explanatory.
  2608.  
  2609. 13.1 Media on Demand (Unicast)
  2610.  
  2611. Client C requests a movie from media servers A ( audio.content.com) and V
  2612. (video.content.com). The media description is stored on a web server W.
  2613. This, however, is transparent to the client. The client is only interested
  2614. in the last part of the movie. The server requires authentication for this
  2615. movie. The audio track can be dynamically switched between between two sets
  2616. of encodings. The URL with scheme rtpsu indicates the media servers want to
  2617. use UDP for exchanging RTSP messages.
  2618.  
  2619. C->W: GET /twister HTTP/1.1
  2620.       Host: www.content.com
  2621.       Accept: application/sdf; application/sdp
  2622.  
  2623. W->C: 200 OK
  2624.       Content-Type: application/sdf
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640. H. Schulzrinne, A. Rao, R. Lanphier                            Page 48
  2641.  
  2642.  
  2643. INTERNET-DRAFT                   RTSP                February 21, 1997
  2644.  
  2645.  
  2646.       (session
  2647.         (all
  2648.          (media (t audio) (oneof
  2649.             ((e PCMU/8000/1 89 DVI4/8000/1 90) (id lofi))
  2650.             ((e DVI4/16000/2 90 DVI4/16000/2 91) (id hifi))
  2651.            )
  2652.            (language en)
  2653.            (id rtspu://audio.content.com/twister/audio.en)
  2654.            )
  2655.            (media (t video) (e JPEG)
  2656.              (id rtspu://video.content.com/twister/video)
  2657.            )
  2658.          )
  2659.        )
  2660.  
  2661. C->A: SETUP rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 1
  2662.       Transport: rtp/udp;compression;port=3056
  2663.  
  2664. A->C: RTSP/1.0 200 1 OK
  2665.       Session: 1234
  2666.  
  2667. C->V: SETUP rtsp://video.content.com/twister/video RTSP/1.0 1
  2668.       Transport: rtp/udp;compression;port=3058
  2669.  
  2670. V->C: RTSP/1.0 200 1 OK
  2671.       Session: 1235
  2672.  
  2673. C->V: PLAY rtsp://video.content.com/twister/video RTSP/1.0 2
  2674.       Session: 1235
  2675.       Range: smpte 0:10:00-
  2676.  
  2677. V->C: RTSP/1.0 200 2 OK
  2678.  
  2679. C->A: PLAY rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 2
  2680.       Session: 1234
  2681.       Range: smpte 0:10:00-
  2682.  
  2683. A->C: 200 2 OK
  2684.  
  2685. C->A: CLOSE rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 3
  2686.       Session: 1234
  2687.  
  2688. A->C: 200 3 OK
  2689.  
  2690. C->V: CLOSE rtsp://video.content.com/twister/video RTSP/1.0 3
  2691.       Session: 1235
  2692.  
  2693.  
  2694.  
  2695. H. Schulzrinne, A. Rao, R. Lanphier                            Page 49
  2696.  
  2697.  
  2698. INTERNET-DRAFT                   RTSP                February 21, 1997
  2699.  
  2700.  
  2701. V->C: 200 3 OK
  2702.  
  2703. Even though the audio and video track are on two different servers, may
  2704. start at slightly different times and may drift with respect to each other,
  2705. the client can synchronize the two using standard RTP methods, in
  2706. particular the time scale contained in the RTCP sender reports.
  2707.  
  2708. 13.2 Live Media Event Using Multicast
  2709.  
  2710. The media server M chooses the multicast address and port. Here, we assume
  2711. that the web server only contains a pointer to the full description, while
  2712. the media server M maintains the full description. During the session, a
  2713. new subtitling stream is added.
  2714.  
  2715. C->W: GET /concert HTTP/1.1
  2716.       Host: www.content.com
  2717.  
  2718. W->C: HTTP/1.1 200 OK
  2719.       Content-Type: application/sdf
  2720.  
  2721.       (session
  2722.         (id rtsp://live.content.com/concert)
  2723.       )
  2724.  
  2725. C->M: GET rtsp://live.content.com/concert RTSP/1.0 1
  2726.  
  2727. M->C: RTSP/1.0 200 1 OK
  2728.       Content-Type: application/sdf
  2729.  
  2730.       (session (all
  2731.         (media (t audio) (id music) (a IP4 224.2.0.1) (p 3456))
  2732.       ))
  2733.  
  2734. C->M: PLAY rtsp://live.content.com/concert/music RTSP/1.0 2
  2735.       Range: smpte 1:12:0
  2736.  
  2737. M->C: RTSP/1.0 405 2 No positioning possible
  2738.  
  2739. M->C: SESSION concert RTSP/1.0
  2740.       Content-Type: application/sdf
  2741.  
  2742.       (session (all
  2743.         (media (t audio) (id music))
  2744.         (media (t text) (id lyrics))
  2745.       ))
  2746.  
  2747.  
  2748.  
  2749.  
  2750. H. Schulzrinne, A. Rao, R. Lanphier                            Page 50
  2751.  
  2752.  
  2753. INTERNET-DRAFT                   RTSP                February 21, 1997
  2754.  
  2755.  
  2756. C->M: PLAY rtsp://live.content.com/concert/lyrics RTSP/1.0
  2757.  
  2758. Since the session description already contains the necessary address
  2759. information, the client does not set the transport address. The attempt to
  2760. position the stream fails since this is a live event.
  2761.  
  2762. 13.3 Playing media into an existing session
  2763.  
  2764. A conference participant C wants to have the media server M play back a
  2765. demo tape into an existing conference. When retrieving the session
  2766. description, C indicates to the media server that the network addresses and
  2767. encryption keys are already given by the conference, so they should not be
  2768. chosen by the server. The example omits the simple ACK responses.
  2769.  
  2770. C->M: GET /demo HTTP/1.1
  2771.       Host: www.content.com
  2772.       Accept: application/sdf, application/sdp
  2773.  
  2774. M->C: HTTP/1.1 200 1 OK
  2775.       Content-type: application/sdf
  2776.  
  2777.       (session
  2778.          (id 548)
  2779.          (media (t audio) (id sound)
  2780.       )
  2781.  
  2782. C->M: SETUP rtsp://server.content.com/demo/548/sound RTSP/1.0 2
  2783.       Conference: 218kadjk
  2784.  
  2785. 13.4 Recording
  2786.  
  2787. Conference participant C asks the media server M to record a session. If
  2788. the session description contains any alternatives, the server records them
  2789. all.
  2790.  
  2791. C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 89
  2792.       Content-Type: application/sdp
  2793.  
  2794.       v=0
  2795.       s=Mbone Audio
  2796.       i=Discussion of Mbone Engineering Issues
  2797.  
  2798. M->C: 415 89 Unsupported Media Type
  2799.       Accept: application/sdf
  2800.  
  2801.  
  2802.  
  2803.  
  2804.  
  2805. H. Schulzrinne, A. Rao, R. Lanphier                            Page 51
  2806.  
  2807.  
  2808. INTERNET-DRAFT                   RTSP                February 21, 1997
  2809.  
  2810.  
  2811. C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 90
  2812.       Content-Type: application/sdf
  2813.  
  2814. M->C: 200 90 OK
  2815.  
  2816. C->M: RECORD rtsp://server.content.com/meeting RTSP/1.0 91
  2817.       Range: clock 19961110T1925-19961110T2015
  2818.  
  2819. 14 Syntax
  2820.  
  2821. The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used
  2822. in RFC 2068 (HTTP/1.1).
  2823.  
  2824. 14.1 Base Syntax
  2825.  
  2826. OCTET     = <any 8-bit sequence of data>
  2827. CHAR      = <any US-ASCII character (octets 0 - 127)>
  2828. UPALPHA   = <any US-ASCII uppercase letter "A".."Z">
  2829. LOALPHA   = <any US-ASCII lowercase letter "a".."z">
  2830. ALPHA     = UPALPHA | LOALPHA
  2831. DIGIT     = <any US-ASCII digit "0".."9">
  2832. CTL       = <any US-ASCII control character
  2833.              (octets 0 - 31) and DEL (127)>
  2834. CR        = <US-ASCII CR, carriage return (13)>
  2835. LF        = <US-ASCII LF, linefeed (10)>
  2836. SP        = <US-ASCII SP, space (32)>
  2837. HT        = <US-ASCII HT, horizontal-tab (9)>
  2838. <">       = <US-ASCII double-quote mark (34)>
  2839. CRLF      = CR LF
  2840. LWS       = [CRLF] 1*( SP | HT )
  2841. TEXT      = <any OCTET except CTLs>
  2842. tspecials = "(" | ")" | "<" | ">" | "@"
  2843.           | "," | ";" | ":" | "\" | <">
  2844.           | "/" | "[" | "]" | "?" | "="
  2845.           | "{" | "}" | SP | HT
  2846. token = 1*<any CHAR except CTLs or tspecials>
  2847. quoted-string = ( <"> *(qdtext) <"> )
  2848. qdtext = <any TEXT except <">>
  2849. quoted-pair = "\" CHAR
  2850.  
  2851. message-header = field-name ":" [ field-value ] CRLF
  2852. field-name = token
  2853. field-value = *( field-content | LWS )
  2854. field-content = <the OCTETs making up the field-value and consisting
  2855.                  of either *TEXT or combinations of token, tspecials,
  2856.                  and quoted-string>
  2857.  
  2858.  
  2859.  
  2860. H. Schulzrinne, A. Rao, R. Lanphier                            Page 52
  2861.  
  2862.  
  2863. INTERNET-DRAFT                   RTSP                February 21, 1997
  2864.  
  2865.  
  2866. 14.2 Internet Media Type Syntax
  2867.  
  2868. media-type = type "/" subtype *( ";" parameter )
  2869. type = token
  2870. subtype = token
  2871. parameter = attribute "=" value
  2872. attribute = token
  2873. value = token | quoted-string
  2874.  
  2875. 14.3 Universal Resource Identifier Syntax
  2876.  
  2877. uri = ( absoluteURI | relativeURI ) [ "#" fragment ]
  2878. absoluteURI = scheme ":" *( uchar | reserved )
  2879. relativeURI = net-path | abs-path | rel-path
  2880. net-path = "//" net-loc [ abs-path ]
  2881. abs-path = "/" rel-path
  2882. rel-path = [ path ] [ ";" params ] [ "?" query ]
  2883. path = fsegment *( "/" segment )
  2884. fsegment = 1*pchar
  2885. segment = *pchar
  2886. params = param *( ";" param )
  2887. param = *( pchar | "/" )
  2888. scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
  2889. net_loc = *( pchar | ";" | "?" )
  2890. query = *( uchar | reserved )
  2891. fragment = *( uchar | reserved )
  2892. pchar = uchar | ":" | "@" | "&" | "=" | "+"
  2893. uchar = unreserved | escape
  2894. unreserved = ALPHA | DIGIT | safe | extra | national
  2895. escape = "%" HEX HEX
  2896. reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
  2897. extra = "!" | "*" | "'" | "(" | ")" | ","
  2898. safe = "$" | "-" | "_" | "."
  2899. unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
  2900. national = <any OCTET excluding ALPHA, DIGIT, reserverd, extra,
  2901.             safe, and unsafe>
  2902.  
  2903. 14.4 RTSP-specific syntax
  2904.  
  2905. setup-response = response-line
  2906.                  date-type-header
  2907.                  *( nack-require-header
  2908.                   | nack-require-transport-header )
  2909.                   CRLF
  2910.  
  2911.  
  2912.  
  2913.  
  2914.  
  2915. H. Schulzrinne, A. Rao, R. Lanphier                            Page 53
  2916.  
  2917.  
  2918. INTERNET-DRAFT                   RTSP                February 21, 1997
  2919.  
  2920.  
  2921. redirect-response = response-line
  2922.                     date-type-header
  2923.  
  2924. session-response = response-line
  2925.                    date-type-header
  2926.  
  2927. play-response = response-line
  2928.                 date-type-header
  2929.  
  2930. pause-response = response-line
  2931.                  date-type-header
  2932.  
  2933. message-body = *OCTET
  2934.  
  2935. accept-header = "Accept" ":" 1#media-type
  2936. allow-header = "Allow" ":" 1#method
  2937. blocksize-header = "Blocksize" ":" 1*DIGIT
  2938. content-length-header = "Content-Length" ":" 1*DIGIT
  2939. content-type-header = "Content-Type" ":" media-type
  2940. date-type-header = "Date" ":" rfc1123-date
  2941. location-header = "Location" ":" request-uri
  2942. require-header = "Require" ":" #parameters
  2943. transport-require-header = "Transport-Require" ":" #parameters
  2944. nack-require-header = "Nack-Require" ":" #parameters
  2945. nack-transport-require-header = "Nack-Transport-Require" ":" #parameters
  2946.  
  2947. auth-scheme = token
  2948. ip-address = <IP address in dotted-decimal form per RFC 1123>
  2949. port-number = 1*DIGIT
  2950. blocksize-value = 1*DIGIT
  2951. credentials = auth-scheme ":" #parameter
  2952. rfc1123-date = wkday "," SP date SP time SP "GMT"
  2953. date = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 12 Dec 1998)
  2954. time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59
  2955. wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
  2956. month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun"
  2957.       | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"
  2958.  
  2959. 15 Experimental
  2960.  
  2961. This section gathers parts of the protocol which are less well understood
  2962. and require extensive further discussion.
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970. H. Schulzrinne, A. Rao, R. Lanphier                            Page 54
  2971.  
  2972.  
  2973. INTERNET-DRAFT                   RTSP                February 21, 1997
  2974.  
  2975.  
  2976. 15.1 Header Field Definitions
  2977.  
  2978. The following additional HTTP headers may be useful for RTSP:
  2979.  
  2980.    * Accept-Language
  2981.    * Cache-Control
  2982.    * From
  2983.    * Max-Forwards
  2984.    * Proxy-Authenticate
  2985.    * Proxy-Authorization
  2986.    * Public
  2987.    * Referer
  2988.  
  2989. 15.1.1 Address
  2990.  
  2991. Designates address to send multimedia data to.
  2992.  
  2993.      It appears that in almost all cases, the destination address is
  2994.      the same one where the RTSP command originates from. If TCP is
  2995.      used for control, this also eliminates the possibilities of
  2996.      pointing a data stream at an unsuspecting third party.
  2997.  
  2998. 16 Security Considerations
  2999.  
  3000. The protocol offers the opportunity for a remote-control denial-of-service
  3001. attack. The attacker, using a forged source IP address, can ask for a
  3002. stream to be played back to that forged IP address.
  3003.  
  3004. Since there is no relation between a transport layer connection and an RTSP
  3005. session, it is possible for a malicious client to issue requests with
  3006. random session identifiers which would affect unsuspecting clients. This
  3007. does not require spoofing of network packet addresses. The server SHOULD
  3008. use a large random session identifier to make this attack more difficult.
  3009.  
  3010. Both problems can be be prevented by appropriate authentication.
  3011.  
  3012. In addition, the security considerations outlined in [H15] apply.
  3013.  
  3014. A State Machines
  3015.  
  3016. The RTSP client and server state machines describe the behavior of the
  3017. protocol from session initialization through session termination.
  3018.  
  3019. [TBD: should we allow for the trivial case of a server that only implements
  3020. the PLAY message, with no control.]
  3021.  
  3022.  
  3023.  
  3024.  
  3025. H. Schulzrinne, A. Rao, R. Lanphier                            Page 55
  3026.  
  3027.  
  3028. INTERNET-DRAFT                   RTSP                February 21, 1997
  3029.  
  3030.  
  3031. State is defined on a per object basis. An object is uniquely identified by
  3032. the stream URL AND the session identifier. (A server may choose to generate
  3033. dynamic session descriptions where the URL is unique for a particular
  3034. session and thus may not need an explicit session identifier in the request
  3035. header.) Any request/reply using URLs denoting a session comprised of
  3036. multiple streams will have an effect on the individual states of all the
  3037. substreams. For example:
  3038.  
  3039. Assuming the stream /coolmovie contains two substreams /coolmovie/audio and
  3040. /coolmovie/video, then the following command:
  3041.  
  3042.   PLAY /coolmovie RTSP/1.0 559
  3043.   Session: 12345
  3044.  
  3045. will have an effect on the states of coolmovie/audio and coolmovie/video.
  3046.  
  3047.      This example does not imply a standard way to represent
  3048.      substreams in URLs or a relation to the filesystem. See Section
  3049.      3.2.
  3050.  
  3051. A.1 Client State Machine
  3052.  
  3053. A.1.1 Client States
  3054.  
  3055. These are defined as follows:
  3056.  
  3057. NULL:
  3058.      No state
  3059. INIT:
  3060.      GET or SETUP has been sent, waiting for reply.
  3061. READY:
  3062.      SETUP reply received OR after playing, PAUSE reply received.
  3063. PLAYING:
  3064.      PLAY reply received
  3065.  
  3066. A.1.2 Notes
  3067.  
  3068. In general, the client transitions state on receipt of specific replies.
  3069. After a period of inactivity, state transitions back to NULL. "Inactivity"
  3070. is defined as one of the following:
  3071.  
  3072.    * For state PLAYING, no data being received and/or lack of wellness
  3073.      information from the server.
  3074.    * The client stays in any other state continuously for more than a
  3075.      specific interval. The choice of this interval is left to the
  3076.      implementation.
  3077.  
  3078.  
  3079.  
  3080. H. Schulzrinne, A. Rao, R. Lanphier                            Page 56
  3081.  
  3082.  
  3083. INTERNET-DRAFT                   RTSP                February 21, 1997
  3084.  
  3085.  
  3086. If no explicit SETUP is required for the object (for example, it is
  3087. available via a multicast group) , state begins at READY. In this case,
  3088. there are only two states, i.e READY and PLAYING.
  3089.  
  3090. A client MUST disregard messages with a sequence number less than the last
  3091. one . If no message has been received, the first received message's
  3092. sequence number will be the starting point.
  3093.  
  3094. A.1.3 State Table
  3095.  
  3096. In the NEXT STATE column, + indicates that the message was successful,
  3097. -indicates that it was unsuccessful.
  3098.  
  3099. STATE           MESSAGES                NEXT STATE(+)   NEXT STATE(-)
  3100.  
  3101. INIT            GET REPLY               INIT            NULL
  3102.                 SETUP REPLY             READY           INIT
  3103.                 REDIRECT                NULL            NULL
  3104.                 BYE                     NULL            NULL
  3105.                 OTHER                   INIT            INIT
  3106.  
  3107. READY           PLAY REPLY              PLAYING         READY
  3108.                 SETUP REPLY             READY           INIT
  3109.                 BYE                     NULL            NULL
  3110.                 OTHER                   READY           READY
  3111.  
  3112. PLAYING         PAUSE REPLY             READY           PLAYING
  3113.                 PLAY REPLY              PLAYING         CLOSED
  3114.                 BYE                     NULL            NULL
  3115.                 CLOSE REPLY             NULL            PLAYING
  3116.                 OTHER                   PLAYING         PLAYING
  3117.  
  3118. This assumes that a PLAY during state PLAYING is an implicit PAUSE, PLAY.
  3119.  
  3120.      HS: BYE should be replaced by CLOSE.
  3121.  
  3122. A.2 Server State Machine
  3123.  
  3124. A.2.1 Server States
  3125.  
  3126. INIT:
  3127.      The initial state, no valid SETUP receieved.
  3128. READY:
  3129.      Last SETUP received was successful, reply sent or after playing, last
  3130.      PAUSE received was successful, reply sent.
  3131.  
  3132.  
  3133.  
  3134.  
  3135. H. Schulzrinne, A. Rao, R. Lanphier                            Page 57
  3136.  
  3137.  
  3138. INTERNET-DRAFT                   RTSP                February 21, 1997
  3139.  
  3140.  
  3141. PLAYING:
  3142.      Last PLAY received was successful, reply sent. Data actually being
  3143.      sent.
  3144.  
  3145. In general, server state transitions occur on receiving requests. On
  3146. receiving a BYE, state transitions back to INIT. After inactivity for a
  3147. period, state also transitions back to INIT. "Inactivity" is defined as:
  3148.  
  3149.    * For states other than PLAYING, no messages for that object for a
  3150.      specific interval. The choice of interval is left to the
  3151.      implementation.
  3152.    * In state PLAYING, lack of wellness information from the client.(This
  3153.      information could be either RTCP or be requested by the server by
  3154.      other means)
  3155.  
  3156. The REDIRECT message, when sent, is effective immediately. If a similar
  3157. change of location occurs at a certain time in the future, this is assumed
  3158. to be indicated by the session description. For purposes of this table, a
  3159. REDIRECT is considered an unsuccessful GET.
  3160.  
  3161. A server MUST disregard messages with a sequence number less than the last
  3162. one. If no message has been received, the first received message's sequence
  3163. number will be the starting point.
  3164.  
  3165. SETUP is valid in states INIT and READY only. An error message should be
  3166. returned in other cases. If no explicit SETUP is required for the object,
  3167. state starts at READY, ie. there are only two states READY and PLAYING.
  3168.  
  3169. A.2.2 State Table
  3170.  
  3171. In the NEXT STATE column, + indicates that the message was successful,
  3172. -indicates that it was unsuccessful.
  3173.  
  3174. STATE           MESSAGES                NEXT STATE(+)   NEXT STATE(-)
  3175.  
  3176. INIT            GET                     INIT            INIT
  3177.                 SETUP                   READY           INIT
  3178.                 BYE                     INIT            INIT
  3179.                 OTHER                   -               INIT
  3180.  
  3181. READY           PLAY                    PLAYING         READY
  3182.                 SETUP                   READY           INIT
  3183.                 CLOSE                   INIT            -
  3184.                 BYE                     INIT            -
  3185.                 OTHER                   -               READY
  3186.  
  3187.  
  3188.  
  3189.  
  3190. H. Schulzrinne, A. Rao, R. Lanphier                            Page 58
  3191.  
  3192.  
  3193. INTERNET-DRAFT                   RTSP                February 21, 1997
  3194.  
  3195.  
  3196. PLAYING         PLAY                    PLAYING         READY
  3197.                 PAUSE                   READY           PLAYING
  3198.                 CLOSE                   INIT            PLAYING
  3199.                 BYE                     INIT            -
  3200.                 OTHER                   -               PLAYING
  3201.  
  3202. B Open Issues
  3203.  
  3204.    * Define text/rtsp-parameter MIME type.
  3205.    * Lots of inconsistencies need to be fixed: naming of methods in state
  3206.      definition, syntax.
  3207.    * Allow changing of transport for a stream that's playing? May not be a
  3208.      great idea since the same can be accomplished by tear down and
  3209.      re-setup.
  3210.    * How does the server get back to the client unless a persistent
  3211.      connection is used? Probably cannot, in general.
  3212.    * Cache and proxy behavior?
  3213.    * Session: or Set-Cookie: ?
  3214.    * Behavior of all methods in state diagram.
  3215.    * Error message for method
  3216.    * When do relative RTSP URLs make sense?
  3217.    * Nack-require, etc. are dubious. This is getting awfully close to the
  3218.      HTTP extension mechanisms [16] in complexity, but is different.
  3219.    * Suggestion (HS): shelve REDIRECT method for now, until necessity
  3220.      becomes clear.
  3221.    * Use HTTP absolute path + Host field or do the right thing and carry
  3222.      full URL, including host in request?
  3223.  
  3224. C Author Addresses
  3225.  
  3226. Henning Schulzrinne
  3227. Dept. of Computer Science
  3228. Columbia University
  3229. 1214 Amsterdam Avenue
  3230. New York, NY 10027
  3231. USA
  3232. electronic mail: schulzrinne@cs.columbia.edu
  3233.  
  3234. Anup Rao
  3235. Netscape Communications Corp.
  3236. USA
  3237. electronic mail: anup@netscape.com
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244.  
  3245. H. Schulzrinne, A. Rao, R. Lanphier                            Page 59
  3246.  
  3247.  
  3248. INTERNET-DRAFT                   RTSP                February 21, 1997
  3249.  
  3250.  
  3251. Robert Lanphier
  3252. Progressive Networks
  3253. 1111 Third Avenue Suite 2900
  3254. Seattle, WA 98101
  3255. USA
  3256. electronic mail: robla@prognet.com
  3257.  
  3258. D Acknowledgements
  3259.  
  3260. This draft is based on the functionality of the RTSP draft. It also borrows
  3261. format and descriptions from HTTP/1.1.
  3262.  
  3263. This document has benefited greatly from the comments of all those
  3264. participating in the MMUSIC-WG. In addition to those already mentioned, the
  3265. following individuals have contributed to this specification:
  3266.  
  3267.  Rahul Agarwal     Eduardo F. Llach
  3268.  Bruce Butterfield Rob McCool
  3269.  Martin Dunsmuir   Sujal Patel
  3270.  Mark Handley      Igor Plotnikov
  3271.  Peter Haight      Pinaki Shah
  3272.  Brad Hefta-Gaub   Jeff Smith
  3273.  John K. Ho        Alexander Sokolsky
  3274.  Ruth Lang         Dale Stammen
  3275.  Stephanie Leif    John Francis Stracke
  3276.  
  3277. References
  3278.  
  3279. 1     D. Kristol and L. Montulli, ``HTTP state management mechanism,'' RFC
  3280.      2109, Internet Engineering Task Force, Feb. 1997.
  3281.  
  3282. 2     F. Yergeau, G. Nicol, G. Adams, and M. Duerst, ``Internationalization
  3283.      of the hypertext markup language,'' RFC 2070, Internet Engineering
  3284.      Task Force, Jan. 1997.
  3285.  
  3286. 3     S. Bradner, ``Key words for use in RFCs to indicate requirement
  3287.      levels,'' Internet Draft, Internet Engineering Task Force, Jan. 1997.
  3288.      Work in progress.
  3289.  
  3290. 4     R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee,
  3291.      ``Hypertext transfer protocol - HTTP/1.1,'' RFC 2068, Internet
  3292.      Engineering Task Force, Jan. 1997.
  3293.  
  3294. 5     A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' Internet
  3295.      Draft, Internet Engineering Task Force, Dec. 1996. Work in progress.
  3296.  
  3297.  
  3298.  
  3299.  
  3300. H. Schulzrinne, A. Rao, R. Lanphier                            Page 60
  3301.  
  3302.  
  3303. INTERNET-DRAFT                   RTSP                February 21, 1997
  3304.  
  3305.  
  3306. 6     J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and E. L.
  3307.      Stewart, ``An extension to HTTP: digest access authentication,'' RFC
  3308.      2069, Internet Engineering Task Force, Jan. 1997.
  3309.  
  3310. 7     J. Postel, ``User datagram protocol,'' STD 6, RFC 768, Internet
  3311.      Engineering Task Force, Aug. 1980.
  3312.  
  3313. 8     R. Hinden and C. Partridge, ``Version 2 of the reliable data protocol
  3314.      (RDP),'' RFC 1151, Internet Engineering Task Force, Apr. 1990.
  3315.  
  3316. 9     J. Postel, ``Transmission control protocol,'' STD 7, RFC 793,
  3317.      Internet Engineering Task Force, Sept. 1981.
  3318.  
  3319. 10    M. Handley, H. Schulzrinne, and E. Schooler, ``SIP: Session
  3320.      initiation protocol,'' Internet Draft, Internet Engineering Task
  3321.      Force, Dec. 1996. Work in progress.
  3322.  
  3323. 11    P. McMahon, ``GSS-API authentication method for SOCKS version 5,''
  3324.      RFC 1961, Internet Engineering Task Force, June 1996.
  3325.  
  3326. 12    D. Crocker, ``Augmented BNF for syntax specifications: ABNF,''
  3327.      Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in
  3328.      progress.
  3329.  
  3330. 13    R. Elz, ``A compact representation of IPv6 addresses,'' RFC 1924,
  3331.      Internet Engineering Task Force, Apr. 1996.
  3332.  
  3333. 14    T. Berners-Lee, ``Universal resource identifiers in WWW: a unifying
  3334.      syntax for the expression of names and addresses of objects on the
  3335.      network as used in the world-wide web,'' RFC 1630, Internet
  3336.      Engineering Task Force, June 1994.
  3337.  
  3338. 15    International Telecommunication Union, ``Visual telephone systems and
  3339.      equipment for local area networks which provide a non-guaranteed
  3340.      quality of service,'' Recommendation H.323, Telecommunication
  3341.      Standardization Sector of ITU, Geneva, Switzerland, May 1996.
  3342.  
  3343. 16    D. Connolly, ``PEP: an extension mechanism for http,'' Internet
  3344.      Draft, Internet Engineering Task Force, Jan. 1997. Work in progress.
  3345.  
  3346.  
  3347.  
  3348.  
  3349.  
  3350.  
  3351.  
  3352.  
  3353.  
  3354.  
  3355. H. Schulzrinne, A. Rao, R. Lanphier                    Page 61
  3356.  
  3357.