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