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