rfc2326.txt
上传用户:sy_wanhua
上传日期:2013-07-25
资源大小:3048k
文件大小:190k
源码类别:

流媒体/Mpeg4/MP4

开发平台:

C/C++

  1. RFC 2326              Real Time Streaming Protocol            April 1998
  2.    Bandwidth = "Bandwidth" ":" 1*DIGIT
  3.    Example:
  4.      Bandwidth: 4000
  5. 12.7 Blocksize
  6.    This request header field is sent from the client to the media server
  7.    asking the server for a particular media packet size. This packet
  8.    size does not include lower-layer headers such as IP, UDP, or RTP.
  9.    The server is free to use a blocksize which is lower than the one
  10.    requested. The server MAY truncate this packet size to the closest
  11.    multiple of the minimum, media-specific block size, or override it
  12.    with the media-specific size if necessary. The block size MUST be a
  13.    positive decimal number, measured in octets. The server only returns
  14.    an error (416) if the value is syntactically invalid.
  15. 12.8 Cache-Control
  16.    The Cache-Control general header field is used to specify directives
  17.    that MUST be obeyed by all caching mechanisms along the
  18.    request/response chain.
  19.    Cache directives must be passed through by a proxy or gateway
  20.    application, regardless of their significance to that application,
  21.    since the directives may be applicable to all recipients along the
  22.    request/response chain. It is not possible to specify a cache-
  23.    directive for a specific cache.
  24.    Cache-Control should only be specified in a SETUP request and its
  25.    response. Note: Cache-Control does not govern the caching of
  26.    responses as for HTTP, but rather of the stream identified by the
  27.    SETUP request.  Responses to RTSP requests are not cacheable, except
  28.    for responses to DESCRIBE.
  29.    Cache-Control            =   "Cache-Control" ":" 1#cache-directive
  30.    cache-directive          =   cache-request-directive
  31.                             |   cache-response-directive
  32.    cache-request-directive  =   "no-cache"
  33.                             |   "max-stale"
  34.                             |   "min-fresh"
  35.                             |   "only-if-cached"
  36.                             |   cache-extension
  37.    cache-response-directive =   "public"
  38.                             |   "private"
  39.                             |   "no-cache"
  40.                             |   "no-transform"
  41.                             |   "must-revalidate"
  42. Schulzrinne, et. al.        Standards Track                    [Page 47]
  43. RFC 2326              Real Time Streaming Protocol            April 1998
  44.                             |   "proxy-revalidate"
  45.                             |   "max-age" "=" delta-seconds
  46.                             |   cache-extension
  47.    cache-extension          =   token [ "=" ( token | quoted-string ) ]
  48.    no-cache:
  49.           Indicates that the media stream MUST NOT be cached anywhere.
  50.           This allows an origin server to prevent caching even by caches
  51.           that have been configured to return stale responses to client
  52.           requests.
  53.    public:
  54.           Indicates that the media stream is cacheable by any cache.
  55.    private:
  56.           Indicates that the media stream is intended for a single user
  57.           and MUST NOT be cached by a shared cache. A private (non-
  58.           shared) cache may cache the media stream.
  59.    no-transform:
  60.           An intermediate cache (proxy) may find it useful to convert
  61.           the media type of a certain stream. A proxy might, for
  62.           example, convert between video formats to save cache space or
  63.           to reduce the amount of traffic on a slow link. Serious
  64.           operational problems may occur, however, when these
  65.           transformations have been applied to streams intended for
  66.           certain kinds of applications. For example, applications for
  67.           medical imaging, scientific data analysis and those using
  68.           end-to-end authentication all depend on receiving a stream
  69.           that is bit-for-bit identical to the original entity-body.
  70.           Therefore, if a response includes the no-transform directive,
  71.           an intermediate cache or proxy MUST NOT change the encoding of
  72.           the stream. Unlike HTTP, RTSP does not provide for partial
  73.           transformation at this point, e.g., allowing translation into
  74.           a different language.
  75.    only-if-cached:
  76.           In some cases, such as times of extremely poor network
  77.           connectivity, a client may want a cache to return only those
  78.           media streams that it currently has stored, and not to receive
  79.           these from the origin server. To do this, the client may
  80.           include the only-if-cached directive in a request. If it
  81.           receives this directive, a cache SHOULD either respond using a
  82.           cached media stream that is consistent with the other
  83.           constraints of the request, or respond with a 504 (Gateway
  84.           Timeout) status. However, if a group of caches is being
  85.           operated as a unified system with good internal connectivity,
  86.           such a request MAY be forwarded within that group of caches.
  87. Schulzrinne, et. al.        Standards Track                    [Page 48]
  88. RFC 2326              Real Time Streaming Protocol            April 1998
  89.    max-stale:
  90.           Indicates that the client is willing to accept a media stream
  91.           that has exceeded its expiration time. If max-stale is
  92.           assigned a value, then the client is willing to accept a
  93.           response that has exceeded its expiration time by no more than
  94.           the specified number of seconds. If no value is assigned to
  95.           max-stale, then the client is willing to accept a stale
  96.           response of any age.
  97.    min-fresh:
  98.           Indicates that the client is willing to accept a media stream
  99.           whose freshness lifetime is no less than its current age plus
  100.           the specified time in seconds. That is, the client wants a
  101.           response that will still be fresh for at least the specified
  102.           number of seconds.
  103.    must-revalidate:
  104.           When the must-revalidate directive is present in a SETUP
  105.           response received by a cache, that cache MUST NOT use the
  106.           entry after it becomes stale to respond to a subsequent
  107.           request without first revalidating it with the origin server.
  108.           That is, the cache must do an end-to-end revalidation every
  109.           time, if, based solely on the origin server's Expires, the
  110.           cached response is stale.)
  111. 12.9 Conference
  112.    This request header field establishes a logical connection between a
  113.    pre-established conference and an RTSP stream. The conference-id must
  114.    not be changed for the same RTSP session.
  115.    Conference = "Conference" ":" conference-id Example:
  116.      Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
  117.    A response code of 452 (452 Conference Not Found) is returned if the
  118.    conference-id is not valid.
  119. 12.10 Connection
  120.    See [H14.10]
  121. 12.11 Content-Base
  122.    See [H14.11]
  123. 12.12 Content-Encoding
  124.    See [H14.12]
  125. Schulzrinne, et. al.        Standards Track                    [Page 49]
  126. RFC 2326              Real Time Streaming Protocol            April 1998
  127. 12.13 Content-Language
  128.    See [H14.13]
  129. 12.14 Content-Length
  130.    This field contains the length of the content of the method (i.e.
  131.    after the double CRLF following the last header). Unlike HTTP, it
  132.    MUST be included in all messages that carry content beyond the header
  133.    portion of the message. If it is missing, a default value of zero is
  134.    assumed. It is interpreted according to [H14.14].
  135. 12.15 Content-Location
  136.    See [H14.15]
  137. 12.16 Content-Type
  138.    See [H14.18]. Note that the content types suitable for RTSP are
  139.    likely to be restricted in practice to presentation descriptions and
  140.    parameter-value types.
  141. 12.17 CSeq
  142.    The CSeq field specifies the sequence number for an RTSP request-
  143.    response pair. This field MUST be present in all requests and
  144.    responses. For every RTSP request containing the given sequence
  145.    number, there will be a corresponding response having the same
  146.    number.  Any retransmitted request must contain the same sequence
  147.    number as the original (i.e. the sequence number is not incremented
  148.    for retransmissions of the same request).
  149. 12.18 Date
  150.    See [H14.19].
  151. 12.19 Expires
  152.    The Expires entity-header field gives a date and time after which the
  153.    description or media-stream should be considered stale. The
  154.    interpretation depends on the method:
  155.    DESCRIBE response:
  156.           The Expires header indicates a date and time after which the
  157.           description should be considered stale.
  158. Schulzrinne, et. al.        Standards Track                    [Page 50]
  159. RFC 2326              Real Time Streaming Protocol            April 1998
  160.    A stale cache entry may not normally be returned by a cache (either a
  161.    proxy cache or an user agent cache) unless it is first validated with
  162.    the origin server (or with an intermediate cache that has a fresh
  163.    copy of the entity). See section 13 for further discussion of the
  164.    expiration model.
  165.    The presence of an Expires field does not imply that the original
  166.    resource will change or cease to exist at, before, or after that
  167.    time.
  168.    The format is an absolute date and time as defined by HTTP-date in
  169.    [H3.3]; it MUST be in RFC1123-date format:
  170.    Expires = "Expires" ":" HTTP-date
  171.    An example of its use is
  172.      Expires: Thu, 01 Dec 1994 16:00:00 GMT
  173.    RTSP/1.0 clients and caches MUST treat other invalid date formats,
  174.    especially including the value "0", as having occurred in the past
  175.    (i.e., "already expired").
  176.    To mark a response as "already expired," an origin server should use
  177.    an Expires date that is equal to the Date header value. To mark a
  178.    response as "never expires," an origin server should use an Expires
  179.    date approximately one year from the time the response is sent.
  180.    RTSP/1.0 servers should not send Expires dates more than one year in
  181.    the future.
  182.    The presence of an Expires header field with a date value of some
  183.    time in the future on a media stream that otherwise would by default
  184.    be non-cacheable indicates that the media stream is cacheable, unless
  185.    indicated otherwise by a Cache-Control header field (Section 12.8).
  186. 12.20 From
  187.    See [H14.22].
  188. 12.21 Host
  189.    This HTTP request header field is not needed for RTSP. It should be
  190.    silently ignored if sent.
  191. 12.22 If-Match
  192.    See [H14.25].
  193. Schulzrinne, et. al.        Standards Track                    [Page 51]
  194. RFC 2326              Real Time Streaming Protocol            April 1998
  195.    This field is especially useful for ensuring the integrity of the
  196.    presentation description, in both the case where it is fetched via
  197.    means external to RTSP (such as HTTP), or in the case where the
  198.    server implementation is guaranteeing the integrity of the
  199.    description between the time of the DESCRIBE message and the SETUP
  200.    message.
  201.    The identifier is an opaque identifier, and thus is not specific to
  202.    any particular session description language.
  203. 12.23 If-Modified-Since
  204.    The If-Modified-Since request-header field is used with the DESCRIBE
  205.    and SETUP methods to make them conditional. If the requested variant
  206.    has not been modified since the time specified in this field, a
  207.    description will not be returned from the server (DESCRIBE) or a
  208.    stream will not be set up (SETUP). Instead, a 304 (not modified)
  209.    response will be returned without any message-body.
  210.    If-Modified-Since = "If-Modified-Since" ":" HTTP-date
  211.    An example of the field is:
  212.      If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
  213. 12.24 Last-Modified
  214.    The Last-Modified entity-header field indicates the date and time at
  215.    which the origin server believes the presentation description or
  216.    media stream was last modified. See [H14.29]. For the methods
  217.    DESCRIBE or ANNOUNCE, the header field indicates the last
  218.    modification date and time of the description, for SETUP that of the
  219.    media stream.
  220. 12.25 Location
  221.    See [H14.30].
  222. 12.26 Proxy-Authenticate
  223.    See [H14.33].
  224. 12.27 Proxy-Require
  225.    The Proxy-Require header is used to indicate proxy-sensitive features
  226.    that MUST be supported by the proxy. Any Proxy-Require header
  227.    features that are not supported by the proxy MUST be negatively
  228.    acknowledged by the proxy to the client if not supported. Servers
  229. Schulzrinne, et. al.        Standards Track                    [Page 52]
  230. RFC 2326              Real Time Streaming Protocol            April 1998
  231.    should treat this field identically to the Require field.
  232.    See Section 12.32 for more details on the mechanics of this message
  233.    and a usage example.
  234. 12.28 Public
  235.    See [H14.35].
  236. 12.29 Range
  237.    This request and response header field specifies a range of time.
  238.    The range can be specified in a number of units. This specification
  239.    defines the smpte (Section 3.5), npt (Section 3.6), and clock
  240.    (Section 3.7) range units. Within RTSP, byte ranges [H14.36.1] are
  241.    not meaningful and MUST NOT be used. The header may also contain a
  242.    time parameter in UTC, specifying the time at which the operation is
  243.    to be made effective. Servers supporting the Range header MUST
  244.    understand the NPT range format and SHOULD understand the SMPTE range
  245.    format. The Range response header indicates what range of time is
  246.    actually being played or recorded. If the Range header is given in a
  247.    time format that is not understood, the recipient should return "501
  248.    Not Implemented".
  249.    Ranges are half-open intervals, including the lower point, but
  250.    excluding the upper point. In other words, a range of a-b starts
  251.    exactly at time a, but stops just before b. Only the start time of a
  252.    media unit such as a video or audio frame is relevant. As an example,
  253.    assume that video frames are generated every 40 ms. A range of 10.0-
  254.    10.1 would include a video frame starting at 10.0 or later time and
  255.    would include a video frame starting at 10.08, even though it lasted
  256.    beyond the interval. A range of 10.0-10.08, on the other hand, would
  257.    exclude the frame at 10.08.
  258.    Range            = "Range" ":" 1#ranges-specifier
  259.                           [ ";" "time" "=" utc-time ]
  260.    ranges-specifier = npt-range | utc-range | smpte-range
  261.    Example:
  262.      Range: clock=19960213T143205Z-;time=19970123T143720Z
  263.      The notation is similar to that used for the HTTP/1.1 [2] byte-
  264.      range header. It allows clients to select an excerpt from the media
  265.      object, and to play from a given point to the end as well as from
  266.      the current location to a given point. The start of playback can be
  267.      scheduled for any time in the future, although a server may refuse
  268.      to keep server resources for extended idle periods.
  269. Schulzrinne, et. al.        Standards Track                    [Page 53]
  270. RFC 2326              Real Time Streaming Protocol            April 1998
  271. 12.30 Referer
  272.    See [H14.37]. The URL refers to that of the presentation description,
  273.    typically retrieved via HTTP.
  274. 12.31 Retry-After
  275.    See [H14.38].
  276. 12.32 Require
  277.    The Require header is used by clients to query the server about
  278.    options that it may or may not support. The server MUST respond to
  279.    this header by using the Unsupported header to negatively acknowledge
  280.    those options which are NOT supported.
  281.      This is to make sure that the client-server interaction will
  282.      proceed without delay when all options are understood by both
  283.      sides, and only slow down if options are not understood (as in the
  284.      case above). For a well-matched client-server pair, the interaction
  285.      proceeds quickly, saving a round-trip often required by negotiation
  286.      mechanisms. In addition, it also removes state ambiguity when the
  287.      client requires features that the server does not understand.
  288.    Require =   "Require" ":"  1#option-tag
  289.    Example:
  290.      C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
  291.              CSeq: 302
  292.              Require: funky-feature
  293.              Funky-Parameter: funkystuff
  294.      S->C:   RTSP/1.0 551 Option not supported
  295.              CSeq: 302
  296.              Unsupported: funky-feature
  297.      C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
  298.              CSeq: 303
  299.      S->C:   RTSP/1.0 200 OK
  300.              CSeq: 303
  301.    In this example, "funky-feature" is the feature tag which indicates
  302.    to the client that the fictional Funky-Parameter field is required.
  303.    The relationship between "funky-feature" and Funky-Parameter is not
  304.    communicated via the RTSP exchange, since that relationship is an
  305.    immutable property of "funky-feature" and thus should not be
  306.    transmitted with every exchange.
  307. Schulzrinne, et. al.        Standards Track                    [Page 54]
  308. RFC 2326              Real Time Streaming Protocol            April 1998
  309.    Proxies and other intermediary devices SHOULD ignore features that
  310.    are not understood in this field. If a particular extension requires
  311.    that intermediate devices support it, the extension should be tagged
  312.    in the Proxy-Require field instead (see Section 12.27).
  313. 12.33 RTP-Info
  314.    This field is used to set RTP-specific parameters in the PLAY
  315.    response.
  316.    url:
  317.           Indicates the stream URL which for which the following RTP
  318.           parameters correspond.
  319.    seq:
  320.           Indicates the sequence number of the first packet of the
  321.           stream. This allows clients to gracefully deal with packets
  322.           when seeking. The client uses this value to differentiate
  323.           packets that originated before the seek from packets that
  324.           originated after the seek.
  325.    rtptime:
  326.           Indicates the RTP timestamp corresponding to the time value in
  327.           the Range response header. (Note: For aggregate control, a
  328.           particular stream may not actually generate a packet for the
  329.           Range time value returned or implied. Thus, there is no
  330.           guarantee that the packet with the sequence number indicated
  331.           by seq actually has the timestamp indicated by rtptime.) The
  332.           client uses this value to calculate the mapping of RTP time to
  333.           NPT.
  334.      A mapping from RTP timestamps to NTP timestamps (wall clock) is
  335.      available via RTCP. However, this information is not sufficient to
  336.      generate a mapping from RTP timestamps to NPT. Furthermore, in
  337.      order to ensure that this information is available at the necessary
  338.      time (immediately at startup or after a seek), and that it is
  339.      delivered reliably, this mapping is placed in the RTSP control
  340.      channel.
  341.      In order to compensate for drift for long, uninterrupted
  342.      presentations, RTSP clients should additionally map NPT to NTP,
  343.      using initial RTCP sender reports to do the mapping, and later
  344.      reports to check drift against the mapping.
  345. Schulzrinne, et. al.        Standards Track                    [Page 55]
  346. RFC 2326              Real Time Streaming Protocol            April 1998
  347.    Syntax:
  348.    RTP-Info        = "RTP-Info" ":" 1#stream-url 1*parameter
  349.    stream-url      = "url" "=" url
  350.    parameter       = ";" "seq" "=" 1*DIGIT
  351.                    | ";" "rtptime" "=" 1*DIGIT
  352.    Example:
  353.      RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
  354.                url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
  355. 12.34 Scale
  356.    A scale value of 1 indicates normal play or record at the normal
  357.    forward viewing rate. If not 1, the value corresponds to the rate
  358.    with respect to normal viewing rate. For example, a ratio of 2
  359.    indicates twice the normal viewing rate ("fast forward") and a ratio
  360.    of 0.5 indicates half the normal viewing rate. In other words, a
  361.    ratio of 2 has normal play time increase at twice the wallclock rate.
  362.    For every second of elapsed (wallclock) time, 2 seconds of content
  363.    will be delivered. A negative value indicates reverse direction.
  364.    Unless requested otherwise by the Speed parameter, the data rate
  365.    SHOULD not be changed. Implementation of scale changes depends on the
  366.    server and media type. For video, a server may, for example, deliver
  367.    only key frames or selected key frames. For audio, it may time-scale
  368.    the audio while preserving pitch or, less desirably, deliver
  369.    fragments of audio.
  370.    The server should try to approximate the viewing rate, but may
  371.    restrict the range of scale values that it supports. The response
  372.    MUST contain the actual scale value chosen by the server.
  373.    If the request contains a Range parameter, the new scale value will
  374.    take effect at that time.
  375.    Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
  376.    Example of playing in reverse at 3.5 times normal rate:
  377.      Scale: -3.5
  378. Schulzrinne, et. al.        Standards Track                    [Page 56]
  379. RFC 2326              Real Time Streaming Protocol            April 1998
  380. 12.35 Speed
  381.    This request header fields parameter requests the server to deliver
  382.    data to the client at a particular speed, contingent on the server's
  383.    ability and desire to serve the media stream at the given speed.
  384.    Implementation by the server is OPTIONAL. The default is the bit rate
  385.    of the stream.
  386.    The parameter value is expressed as a decimal ratio, e.g., a value of
  387.    2.0 indicates that data is to be delivered twice as fast as normal. A
  388.    speed of zero is invalid. If the request contains a Range parameter,
  389.    the new speed value will take effect at that time.
  390.    Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
  391.    Example:
  392.      Speed: 2.5
  393.    Use of this field changes the bandwidth used for data delivery. It is
  394.    meant for use in specific circumstances where preview of the
  395.    presentation at a higher or lower rate is necessary. Implementors
  396.    should keep in mind that bandwidth for the session may be negotiated
  397.    beforehand (by means other than RTSP), and therefore re-negotiation
  398.    may be necessary. When data is delivered over UDP, it is highly
  399.    recommended that means such as RTCP be used to track packet loss
  400.    rates.
  401. 12.36 Server
  402.    See [H14.39]
  403. 12.37 Session
  404.    This request and response header field identifies an RTSP session
  405.    started by the media server in a SETUP response and concluded by
  406.    TEARDOWN on the presentation URL. The session identifier is chosen by
  407.    the media server (see Section 3.4). Once a client receives a Session
  408.    identifier, it MUST return it for any request related to that
  409.    session.  A server does not have to set up a session identifier if it
  410.    has other means of identifying a session, such as dynamically
  411.    generated URLs.
  412.  Session  = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
  413.    The timeout parameter is only allowed in a response header. The
  414.    server uses it to indicate to the client how long the server is
  415.    prepared to wait between RTSP commands before closing the session due
  416.    to lack of activity (see Section A). The timeout is measured in
  417. Schulzrinne, et. al.        Standards Track                    [Page 57]
  418. RFC 2326              Real Time Streaming Protocol            April 1998
  419.    seconds, with a default of 60 seconds (1 minute).
  420.    Note that a session identifier identifies a RTSP session across
  421.    transport sessions or connections. Control messages for more than one
  422.    RTSP URL may be sent within a single RTSP session. Hence, it is
  423.    possible that clients use the same session for controlling many
  424.    streams constituting a presentation, as long as all the streams come
  425.    from the same server. (See example in Section 14). However, multiple
  426.    "user" sessions for the same URL from the same client MUST use
  427.    different session identifiers.
  428.      The session identifier is needed to distinguish several delivery
  429.      requests for the same URL coming from the same client.
  430.    The response 454 (Session Not Found) is returned if the session
  431.    identifier is invalid.
  432. 12.38 Timestamp
  433.    The timestamp general header describes when the client sent the
  434.    request to the server. The value of the timestamp is of significance
  435.    only to the client and may use any timescale. The server MUST echo
  436.    the exact same value and MAY, if it has accurate information about
  437.    this, add a floating point number indicating the number of seconds
  438.    that has elapsed since it has received the request. The timestamp is
  439.    used by the client to compute the round-trip time to the server so
  440.    that it can adjust the timeout value for retransmissions.
  441.    Timestamp  = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
  442.    delay      =  *(DIGIT) [ "." *(DIGIT) ]
  443. 12.39 Transport
  444.    This request header indicates which transport protocol is to be used
  445.    and configures its parameters such as destination address,
  446.    compression, multicast time-to-live and destination port for a single
  447.    stream. It sets those values not already determined by a presentation
  448.    description.
  449.    Transports are comma separated, listed in order of preference.
  450.    Parameters may be added to each transport, separated by a semicolon.
  451.    The Transport header MAY also be used to change certain transport
  452.    parameters. A server MAY refuse to change parameters of an existing
  453.    stream.
  454.    The server MAY return a Transport response header in the response to
  455.    indicate the values actually chosen.
  456. Schulzrinne, et. al.        Standards Track                    [Page 58]
  457. RFC 2326              Real Time Streaming Protocol            April 1998
  458.    A Transport request header field may contain a list of transport
  459.    options acceptable to the client. In that case, the server MUST
  460.    return a single option which was actually chosen.
  461.    The syntax for the transport specifier is
  462.        transport/profile/lower-transport.
  463.    The default value for the "lower-transport" parameters is specific to
  464.    the profile. For RTP/AVP, the default is UDP.
  465.    Below are the configuration parameters associated with transport:
  466.    General parameters:
  467.    unicast | multicast:
  468.           mutually exclusive indication of whether unicast or multicast
  469.           delivery will be attempted. Default value is multicast.
  470.           Clients that are capable of handling both unicast and
  471.           multicast transmission MUST indicate such capability by
  472.           including two full transport-specs with separate parameters
  473.           for each.
  474.    destination:
  475.           The address to which a stream will be sent. The client may
  476.           specify the multicast address with the destination parameter.
  477.           To avoid becoming the unwitting perpetrator of a remote-
  478.           controlled denial-of-service attack, a server SHOULD
  479.           authenticate the client and SHOULD log such attempts before
  480.           allowing the client to direct a media stream to an address not
  481.           chosen by the server. This is particularly important if RTSP
  482.           commands are issued via UDP, but implementations cannot rely
  483.           on TCP as reliable means of client identification by itself. A
  484.           server SHOULD not allow a client to direct media streams to an
  485.           address that differs from the address commands are coming
  486.           from.
  487.    source:
  488.           If the source address for the stream is different than can be
  489.           derived from the RTSP endpoint address (the server in playback
  490.           or the client in recording), the source MAY be specified.
  491.      This information may also be available through SDP. However, since
  492.      this is more a feature of transport than media initialization, the
  493.      authoritative source for this information should be in the SETUP
  494.      response.
  495. Schulzrinne, et. al.        Standards Track                    [Page 59]
  496. RFC 2326              Real Time Streaming Protocol            April 1998
  497.    layers:
  498.           The number of multicast layers to be used for this media
  499.           stream. The layers are sent to consecutive addresses starting
  500.           at the destination address.
  501.    mode:
  502.           The mode parameter indicates the methods to be supported for
  503.           this session. Valid values are PLAY and RECORD. If not
  504.           provided, the default is PLAY.
  505.    append:
  506.           If the mode parameter includes RECORD, the append parameter
  507.           indicates that the media data should append to the existing
  508.           resource rather than overwrite it. If appending is requested
  509.           and the server does not support this, it MUST refuse the
  510.           request rather than overwrite the resource identified by the
  511.           URI. The append parameter is ignored if the mode parameter
  512.           does not contain RECORD.
  513.    interleaved:
  514.           The interleaved parameter implies mixing the media stream with
  515.           the control stream in whatever protocol is being used by the
  516.           control stream, using the mechanism defined in Section 10.12.
  517.           The argument provides the channel number to be used in the $
  518.           statement. This parameter may be specified as a range, e.g.,
  519.           interleaved=4-5 in cases where the transport choice for the
  520.           media stream requires it.
  521.      This allows RTP/RTCP to be handled similarly to the way that it is
  522.      done with UDP, i.e., one channel for RTP and the other for RTCP.
  523.    Multicast specific:
  524.    ttl:
  525.           multicast time-to-live
  526.    RTP Specific:
  527.    port:
  528.           This parameter provides the RTP/RTCP port pair for a multicast
  529.           session. It is specified as a range, e.g., port=3456-3457.
  530.    client_port:
  531.           This parameter provides the unicast RTP/RTCP port pair on
  532.           which the client has chosen to receive media data and control
  533.           information.  It is specified as a range, e.g.,
  534.           client_port=3456-3457.
  535. Schulzrinne, et. al.        Standards Track                    [Page 60]
  536. RFC 2326              Real Time Streaming Protocol            April 1998
  537.    server_port:
  538.           This parameter provides the unicast RTP/RTCP port pair on
  539.           which the server has chosen to receive media data and control
  540.           information.  It is specified as a range, e.g.,
  541.           server_port=3456-3457.
  542.    ssrc:
  543.           The ssrc parameter indicates the RTP SSRC [24, Sec. 3] value
  544.           that should be (request) or will be (response) used by the
  545.           media server. This parameter is only valid for unicast
  546.           transmission. It identifies the synchronization source to be
  547.           associated with the media stream.
  548.    Transport           =    "Transport" ":"
  549.                             1#transport-spec
  550.    transport-spec      =    transport-protocol/profile[/lower-transport]
  551.                             *parameter
  552.    transport-protocol  =    "RTP"
  553.    profile             =    "AVP"
  554.    lower-transport     =    "TCP" | "UDP"
  555.    parameter           =    ( "unicast" | "multicast" )
  556.                        |    ";" "destination" [ "=" address ]
  557.                        |    ";" "interleaved" "=" channel [ "-" channel ]
  558.                        |    ";" "append"
  559.                        |    ";" "ttl" "=" ttl
  560.                        |    ";" "layers" "=" 1*DIGIT
  561.                        |    ";" "port" "=" port [ "-" port ]
  562.                        |    ";" "client_port" "=" port [ "-" port ]
  563.                        |    ";" "server_port" "=" port [ "-" port ]
  564.                        |    ";" "ssrc" "=" ssrc
  565.                        |    ";" "mode" = <"> 1#mode <">
  566.    ttl                 =    1*3(DIGIT)
  567.    port                =    1*5(DIGIT)
  568.    ssrc                =    8*8(HEX)
  569.    channel             =    1*3(DIGIT)
  570.    address             =    host
  571.    mode                =    <"> *Method <"> | Method
  572.    Example:
  573.      Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
  574.                 RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
  575.      The Transport header is restricted to describing a single RTP
  576.      stream. (RTSP can also control multiple streams as a single
  577.      entity.) Making it part of RTSP rather than relying on a multitude
  578.      of session description formats greatly simplifies designs of
  579.      firewalls.
  580. Schulzrinne, et. al.        Standards Track                    [Page 61]
  581. RFC 2326              Real Time Streaming Protocol            April 1998
  582. 12.40 Unsupported
  583.    The Unsupported response header lists the features not supported by
  584.    the server. In the case where the feature was specified via the
  585.    Proxy-Require field (Section 12.32), if there is a proxy on the path
  586.    between the client and the server, the proxy MUST insert a message
  587.    reply with an error message "551 Option Not Supported".
  588.    See Section 12.32 for a usage example.
  589. 12.41 User-Agent
  590.    See [H14.42]
  591. 12.42 Vary
  592.    See [H14.43]
  593. 12.43 Via
  594.    See [H14.44].
  595. 12.44 WWW-Authentica
  596.    See [H14.46].
  597. 13 Caching
  598.    In HTTP, response-request pairs are cached. RTSP differs
  599.    significantly in that respect. Responses are not cacheable, with the
  600.    exception of the presentation description returned by DESCRIBE or
  601.    included with ANNOUNCE. (Since the responses for anything but
  602.    DESCRIBE and GET_PARAMETER do not return any data, caching is not
  603.    really an issue for these requests.) However, it is desirable for the
  604.    continuous media data, typically delivered out-of-band with respect
  605.    to RTSP, to be cached, as well as the session description.
  606.    On receiving a SETUP or PLAY request, a proxy ascertains whether it
  607.    has an up-to-date copy of the continuous media content and its
  608.    description. It can determine whether the copy is up-to-date by
  609.    issuing a SETUP or DESCRIBE request, respectively, and comparing the
  610.    Last-Modified header with that of the cached copy. If the copy is not
  611.    up-to-date, it modifies the SETUP transport parameters as appropriate
  612.    and forwards the request to the origin server. Subsequent control
  613.    commands such as PLAY or PAUSE then pass the proxy unmodified. The
  614.    proxy delivers the continuous media data to the client, while
  615.    possibly making a local copy for later reuse. The exact behavior
  616.    allowed to the cache is given by the cache-response directives
  617. Schulzrinne, et. al.        Standards Track                    [Page 62]
  618. RFC 2326              Real Time Streaming Protocol            April 1998
  619.    described in Section 12.8. A cache MUST answer any DESCRIBE requests
  620.    if it is currently serving the stream to the requestor, as it is
  621.    possible that low-level details of the stream description may have
  622.    changed on the origin-server.
  623.    Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
  624.    through" variety. Rather than retrieving the whole resource from the
  625.    origin server, the cache simply copies the streaming data as it
  626.    passes by on its way to the client. Thus, it does not introduce
  627.    additional latency.
  628.    To the client, an RTSP proxy cache appears like a regular media
  629.    server, to the media origin server like a client. Just as an HTTP
  630.    cache has to store the content type, content language, and so on for
  631.    the objects it caches, a media cache has to store the presentation
  632.    description. Typically, a cache eliminates all transport-references
  633.    (that is, multicast information) from the presentation description,
  634.    since these are independent of the data delivery from the cache to
  635.    the client. Information on the encodings remains the same. If the
  636.    cache is able to translate the cached media data, it would create a
  637.    new presentation description with all the encoding possibilities it
  638.    can offer.
  639. 14 Examples
  640.    The following examples refer to stream description formats that are
  641.    not standards, such as RTSL. The following examples are not to be
  642.    used as a reference for those formats.
  643. 14.1 Media on Demand (Unicast)
  644.    Client C requests a movie from media servers A ( audio.example.com)
  645.    and V (video.example.com). The media description is stored on a web
  646.    server W . The media description contains descriptions of the
  647.    presentation and all its streams, including the codecs that are
  648.    available, dynamic RTP payload types, the protocol stack, and content
  649.    information such as language or copyright restrictions. It may also
  650.    give an indication about the timeline of the movie.
  651.    In this example, the client is only interested in the last part of
  652.    the movie.
  653.      C->W: GET /twister.sdp HTTP/1.1
  654.            Host: www.example.com
  655.            Accept: application/sdp
  656.      W->C: HTTP/1.0 200 OK
  657.            Content-Type: application/sdp
  658. Schulzrinne, et. al.        Standards Track                    [Page 63]
  659. RFC 2326              Real Time Streaming Protocol            April 1998
  660.            v=0
  661.            o=- 2890844526 2890842807 IN IP4 192.16.24.202
  662.            s=RTSP Session
  663.            m=audio 0 RTP/AVP 0
  664.            a=control:rtsp://audio.example.com/twister/audio.en
  665.            m=video 0 RTP/AVP 31
  666.            a=control:rtsp://video.example.com/twister/video
  667.      C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
  668.            CSeq: 1
  669.            Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
  670.      A->C: RTSP/1.0 200 OK
  671.            CSeq: 1
  672.            Session: 12345678
  673.            Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
  674.                       server_port=5000-5001
  675.      C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
  676.            CSeq: 1
  677.            Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
  678.      V->C: RTSP/1.0 200 OK
  679.            CSeq: 1
  680.            Session: 23456789
  681.            Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
  682.                       server_port=5002-5003
  683.      C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
  684.            CSeq: 2
  685.            Session: 23456789
  686.            Range: smpte=0:10:00-
  687.      V->C: RTSP/1.0 200 OK
  688.            CSeq: 2
  689.            Session: 23456789
  690.            Range: smpte=0:10:00-0:20:00
  691.            RTP-Info: url=rtsp://video.example.com/twister/video;
  692.              seq=12312232;rtptime=78712811
  693.      C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
  694.            CSeq: 2
  695.            Session: 12345678
  696.            Range: smpte=0:10:00-
  697.      A->C: RTSP/1.0 200 OK
  698.            CSeq: 2
  699.            Session: 12345678
  700. Schulzrinne, et. al.        Standards Track                    [Page 64]
  701. RFC 2326              Real Time Streaming Protocol            April 1998
  702.            Range: smpte=0:10:00-0:20:00
  703.            RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
  704.              seq=876655;rtptime=1032181
  705.      C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
  706.            CSeq: 3
  707.            Session: 12345678
  708.      A->C: RTSP/1.0 200 OK
  709.            CSeq: 3
  710.      C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
  711.            CSeq: 3
  712.            Session: 23456789
  713.      V->C: RTSP/1.0 200 OK
  714.            CSeq: 3
  715.    Even though the audio and video track are on two different servers,
  716.    and may start at slightly different times and may drift with respect
  717.    to each other, the client can synchronize the two using standard RTP
  718.    methods, in particular the time scale contained in the RTCP sender
  719.    reports.
  720. 14.2 Streaming of a Container file
  721.    For purposes of this example, a container file is a storage entity in
  722.    which multiple continuous media types pertaining to the same end-user
  723.    presentation are present. In effect, the container file represents an
  724.    RTSP presentation, with each of its components being RTSP streams.
  725.    Container files are a widely used means to store such presentations.
  726.    While the components are transported as independent streams, it is
  727.    desirable to maintain a common context for those streams at the
  728.    server end.
  729.      This enables the server to keep a single storage handle open
  730.      easily. It also allows treating all the streams equally in case of
  731.      any prioritization of streams by the server.
  732.    It is also possible that the presentation author may wish to prevent
  733.    selective retrieval of the streams by the client in order to preserve
  734.    the artistic effect of the combined media presentation. Similarly, in
  735.    such a tightly bound presentation, it is desirable to be able to
  736.    control all the streams via a single control message using an
  737.    aggregate URL.
  738.    The following is an example of using a single RTSP session to control
  739.    multiple streams. It also illustrates the use of aggregate URLs.
  740. Schulzrinne, et. al.        Standards Track                    [Page 65]
  741. RFC 2326              Real Time Streaming Protocol            April 1998
  742.    Client C requests a presentation from media server M . The movie is
  743.    stored in a container file. The client has obtained an RTSP URL to
  744.    the container file.
  745.      C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
  746.            CSeq: 1
  747.      M->C: RTSP/1.0 200 OK
  748.            CSeq: 1
  749.            Content-Type: application/sdp
  750.            Content-Length: 164
  751.            v=0
  752.            o=- 2890844256 2890842807 IN IP4 172.16.2.93
  753.            s=RTSP Session
  754.            i=An Example of RTSP Session Usage
  755.            a=control:rtsp://foo/twister
  756.            t=0 0
  757.            m=audio 0 RTP/AVP 0
  758.            a=control:rtsp://foo/twister/audio
  759.            m=video 0 RTP/AVP 26
  760.            a=control:rtsp://foo/twister/video
  761.      C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
  762.            CSeq: 2
  763.            Transport: RTP/AVP;unicast;client_port=8000-8001
  764.      M->C: RTSP/1.0 200 OK
  765.            CSeq: 2
  766.            Transport: RTP/AVP;unicast;client_port=8000-8001;
  767.                       server_port=9000-9001
  768.            Session: 12345678
  769.      C->M: SETUP rtsp://foo/twister/video RTSP/1.0
  770.            CSeq: 3
  771.            Transport: RTP/AVP;unicast;client_port=8002-8003
  772.            Session: 12345678
  773.      M->C: RTSP/1.0 200 OK
  774.            CSeq: 3
  775.            Transport: RTP/AVP;unicast;client_port=8002-8003;
  776.                       server_port=9004-9005
  777.            Session: 12345678
  778.      C->M: PLAY rtsp://foo/twister RTSP/1.0
  779.            CSeq: 4
  780.            Range: npt=0-
  781.            Session: 12345678
  782. Schulzrinne, et. al.        Standards Track                    [Page 66]
  783. RFC 2326              Real Time Streaming Protocol            April 1998
  784.      M->C: RTSP/1.0 200 OK
  785.            CSeq: 4
  786.            Session: 12345678
  787.            RTP-Info: url=rtsp://foo/twister/video;
  788.              seq=9810092;rtptime=3450012
  789.      C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
  790.            CSeq: 5
  791.            Session: 12345678
  792.      M->C: RTSP/1.0 460 Only aggregate operation allowed
  793.            CSeq: 5
  794.      C->M: PAUSE rtsp://foo/twister RTSP/1.0
  795.            CSeq: 6
  796.            Session: 12345678
  797.      M->C: RTSP/1.0 200 OK
  798.            CSeq: 6
  799.            Session: 12345678
  800.      C->M: SETUP rtsp://foo/twister RTSP/1.0
  801.            CSeq: 7
  802.            Transport: RTP/AVP;unicast;client_port=10000
  803.      M->C: RTSP/1.0 459 Aggregate operation not allowed
  804.            CSeq: 7
  805.    In the first instance of failure, the client tries to pause one
  806.    stream (in this case video) of the presentation. This is disallowed
  807.    for that presentation by the server. In the second instance, the
  808.    aggregate URL may not be used for SETUP and one control message is
  809.    required per stream to set up transport parameters.
  810.      This keeps the syntax of the Transport header simple and allows
  811.      easy parsing of transport information by firewalls.
  812. 14.3 Single Stream Container Files
  813.    Some RTSP servers may treat all files as though they are "container
  814.    files", yet other servers may not support such a concept. Because of
  815.    this, clients SHOULD use the rules set forth in the session
  816.    description for request URLs, rather than assuming that a consistent
  817.    URL may always be used throughout. Here's an example of how a multi-
  818.    stream server might expect a single-stream file to be served:
  819.           Accept: application/x-rtsp-mh, application/sdp
  820. Schulzrinne, et. al.        Standards Track                    [Page 67]
  821. RFC 2326              Real Time Streaming Protocol            April 1998
  822.           CSeq: 1
  823.     S->C  RTSP/1.0 200 OK
  824.           CSeq: 1
  825.           Content-base: rtsp://foo.com/test.wav/
  826.           Content-type: application/sdp
  827.           Content-length: 48
  828.           v=0
  829.           o=- 872653257 872653257 IN IP4 172.16.2.187
  830.           s=mu-law wave file
  831.           i=audio test
  832.           t=0 0
  833.           m=audio 0 RTP/AVP 0
  834.           a=control:streamid=0
  835.     C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
  836.           Transport: RTP/AVP/UDP;unicast;
  837.                      client_port=6970-6971;mode=play
  838.           CSeq: 2
  839.     S->C  RTSP/1.0 200 OK
  840.           Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
  841.                      server_port=6970-6971;mode=play
  842.           CSeq: 2
  843.           Session: 2034820394
  844.     C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
  845.           CSeq: 3
  846.           Session: 2034820394
  847.     S->C  RTSP/1.0 200 OK
  848.           CSeq: 3
  849.           Session: 2034820394
  850.           RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
  851.             seq=981888;rtptime=3781123
  852.    Note the different URL in the SETUP command, and then the switch back
  853.    to the aggregate URL in the PLAY command. This makes complete sense
  854.    when there are multiple streams with aggregate control, but is less
  855.    than intuitive in the special case where the number of streams is
  856.    one.
  857.    In this special case, it is recommended that servers be forgiving of
  858.    implementations that send:
  859.     C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
  860.           CSeq: 3
  861. Schulzrinne, et. al.        Standards Track                    [Page 68]
  862. RFC 2326              Real Time Streaming Protocol            April 1998
  863.    In the worst case, servers should send back:
  864.     S->C  RTSP/1.0 460 Only aggregate operation allowed
  865.           CSeq: 3
  866.    One would also hope that server implementations are also forgiving of
  867.    the following:
  868.     C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
  869.           Transport: rtp/avp/udp;client_port=6970-6971;mode=play
  870.           CSeq: 2
  871.    Since there is only a single stream in this file, it's not ambiguous
  872.    what this means.
  873. 14.4 Live Media Presentation Using Multicast
  874.    The media server M chooses the multicast address and port. Here, we
  875.    assume that the web server only contains a pointer to the full
  876.    description, while the media server M maintains the full description.
  877.      C->W: GET /concert.sdp HTTP/1.1
  878.            Host: www.example.com
  879.      W->C: HTTP/1.1 200 OK
  880.            Content-Type: application/x-rtsl
  881.            <session>
  882.              <track src="rtsp://live.example.com/concert/audio">
  883.            </session>
  884.      C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
  885.            CSeq: 1
  886.      M->C: RTSP/1.0 200 OK
  887.            CSeq: 1
  888.            Content-Type: application/sdp
  889.            Content-Length: 44
  890.            v=0
  891.            o=- 2890844526 2890842807 IN IP4 192.16.24.202
  892.            s=RTSP Session
  893.            m=audio 3456 RTP/AVP 0
  894.            a=control:rtsp://live.example.com/concert/audio
  895.            c=IN IP4 224.2.0.1/16
  896.      C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
  897.            CSeq: 2
  898. Schulzrinne, et. al.        Standards Track                    [Page 69]
  899. RFC 2326              Real Time Streaming Protocol            April 1998
  900.            Transport: RTP/AVP;multicast
  901.      M->C: RTSP/1.0 200 OK
  902.            CSeq: 2
  903.            Transport: RTP/AVP;multicast;destination=224.2.0.1;
  904.                       port=3456-3457;ttl=16
  905.            Session: 0456804596
  906.      C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
  907.            CSeq: 3
  908.            Session: 0456804596
  909.      M->C: RTSP/1.0 200 OK
  910.            CSeq: 3
  911.            Session: 0456804596
  912. 14.5 Playing media into an existing session
  913.    A conference participant C wants to have the media server M play back
  914.    a demo tape into an existing conference. C indicates to the media
  915.    server that the network addresses and encryption keys are already
  916.    given by the conference, so they should not be chosen by the server.
  917.    The example omits the simple ACK responses.
  918.      C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0
  919.            CSeq: 1
  920.            Accept: application/sdp
  921.      M->C: RTSP/1.0 200 1 OK
  922.            Content-type: application/sdp
  923.            Content-Length: 44
  924.            v=0
  925.            o=- 2890844526 2890842807 IN IP4 192.16.24.202
  926.            s=RTSP Session
  927.            i=See above
  928.            t=0 0
  929.            m=audio 0 RTP/AVP 0
  930.      C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
  931.            CSeq: 2
  932.            Transport: RTP/AVP;multicast;destination=225.219.201.15;
  933.                       port=7000-7001;ttl=127
  934.            Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
  935.      M->C: RTSP/1.0 200 OK
  936.            CSeq: 2
  937.            Transport: RTP/AVP;multicast;destination=225.219.201.15;
  938. Schulzrinne, et. al.        Standards Track                    [Page 70]
  939. RFC 2326              Real Time Streaming Protocol            April 1998
  940.                       port=7000-7001;ttl=127
  941.            Session: 91389234234
  942.            Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
  943.      C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
  944.            CSeq: 3
  945.            Session: 91389234234
  946.      M->C: RTSP/1.0 200 OK
  947.            CSeq: 3
  948. 14.6 Recording
  949.    The conference participant client C asks the media server M to record
  950.    the audio and video portions of a meeting. The client uses the
  951.    ANNOUNCE method to provide meta-information about the recorded
  952.    session to the server.
  953.      C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
  954.            CSeq: 90
  955.            Content-Type: application/sdp
  956.            Content-Length: 121
  957.            v=0
  958.            o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
  959.            s=IETF Meeting, Munich - 1
  960.            i=The thirty-ninth IETF meeting will be held in Munich, Germany
  961.            u=http://www.ietf.org/meetings/Munich.html
  962.            e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
  963.            p=IETF Channel 1 +49-172-2312 451
  964.            c=IN IP4 224.0.1.11/127
  965.            t=3080271600 3080703600
  966.            a=tool:sdr v2.4a6
  967.            a=type:test
  968.            m=audio 21010 RTP/AVP 5
  969.            c=IN IP4 224.0.1.11/127
  970.            a=ptime:40
  971.            m=video 61010 RTP/AVP 31
  972.            c=IN IP4 224.0.1.12/127
  973.      M->C: RTSP/1.0 200 OK
  974.            CSeq: 90
  975.      C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
  976.            CSeq: 91
  977.            Transport: RTP/AVP;multicast;destination=224.0.1.11;
  978.                       port=21010-21011;mode=record;ttl=127
  979. Schulzrinne, et. al.        Standards Track                    [Page 71]
  980. RFC 2326              Real Time Streaming Protocol            April 1998
  981.      M->C: RTSP/1.0 200 OK
  982.            CSeq: 91
  983.            Session: 50887676
  984.            Transport: RTP/AVP;multicast;destination=224.0.1.11;
  985.                       port=21010-21011;mode=record;ttl=127
  986.      C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
  987.            CSeq: 92
  988.            Session: 50887676
  989.            Transport: RTP/AVP;multicast;destination=224.0.1.12;
  990.                       port=61010-61011;mode=record;ttl=127
  991.      M->C: RTSP/1.0 200 OK
  992.            CSeq: 92
  993.            Transport: RTP/AVP;multicast;destination=224.0.1.12;
  994.                       port=61010-61011;mode=record;ttl=127
  995.      C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
  996.            CSeq: 93
  997.            Session: 50887676
  998.            Range: clock=19961110T1925-19961110T2015
  999.      M->C: RTSP/1.0 200 OK
  1000.            CSeq: 93
  1001. 15 Syntax
  1002.    The RTSP syntax is described in an augmented Backus-Naur form (BNF)
  1003.    as used in RFC 2068 [2].
  1004. 15.1 Base Syntax
  1005.    OCTET              =      <any 8-bit sequence of data>
  1006.    CHAR               =      <any US-ASCII character (octets 0 - 127)>
  1007.    UPALPHA            =      <any US-ASCII uppercase letter "A".."Z">
  1008.    LOALPHA            =      <any US-ASCII lowercase letter "a".."z">
  1009.    ALPHA              =      UPALPHA | LOALPHA
  1010.    DIGIT              =      <any US-ASCII digit "0".."9">
  1011.    CTL                =      <any US-ASCII control character
  1012.                               (octets 0 - 31) and DEL (127)>
  1013.    CR                 =      <US-ASCII CR, carriage return (13)>
  1014.    LF                 =      <US-ASCII LF, linefeed (10)>
  1015.    SP                 =      <US-ASCII SP, space (32)>
  1016.    HT                 =      <US-ASCII HT, horizontal-tab (9)>
  1017.    <">                =      <US-ASCII double-quote mark (34)>
  1018.    CRLF               =      CR LF
  1019. Schulzrinne, et. al.        Standards Track                    [Page 72]
  1020. RFC 2326              Real Time Streaming Protocol            April 1998
  1021.    LWS                =      [CRLF] 1*( SP | HT )
  1022.    TEXT               =      <any OCTET except CTLs>
  1023.    tspecials          =      "(" | ")" | "<" | ">" | "@"
  1024.                       |       "," | ";" | ":" | "" | <">
  1025.                       |       "/" | "[" | "]" | "?" | "="
  1026.                       |       "{" | "}" | SP | HT
  1027.    token              =      1*<any CHAR except CTLs or tspecials>
  1028.    quoted-string      =      ( <"> *(qdtext) <"> )
  1029.    qdtext             =      <any TEXT except <">>
  1030.    quoted-pair        =      "" CHAR
  1031.    message-header     =      field-name ":" [ field-value ] CRLF
  1032.    field-name         =      token
  1033.    field-value        =      *( field-content | LWS )
  1034.    field-content      =      <the OCTETs making up the field-value and
  1035.                               consisting of either *TEXT or
  1036.                               combinations of token, tspecials, and
  1037.                               quoted-string>
  1038.    safe               =  "$" | "-" | "_" | "." | "+"
  1039.    extra              =  "!" | "*" | "$'$" | "(" | ")" | ","
  1040.    hex                =  DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
  1041.                         "a" | "b" | "c" | "d" | "e" | "f"
  1042.    escape             =  "%" hex hex
  1043.    reserved           =  ";" | "/" | "?" | ":" | "@" | "&" | "="
  1044.    unreserved         =  alpha | digit | safe | extra
  1045.    xchar              =  unreserved | reserved | escape
  1046. 16 Security Considerations
  1047.    Because of the similarity in syntax and usage between RTSP servers
  1048.    and HTTP servers, the security considerations outlined in [H15]
  1049.    apply.  Specifically, please note the following:
  1050.    Authentication Mechanisms:
  1051.           RTSP and HTTP share common authentication schemes, and thus
  1052.           should follow the same prescriptions with regards to
  1053.           authentication. See [H15.1] for client authentication issues,
  1054.           and [H15.2] for issues regarding support for multiple
  1055.           authentication mechanisms.
  1056.    Abuse of Server Log Information:
  1057.           RTSP and HTTP servers will presumably have similar logging
  1058.           mechanisms, and thus should be equally guarded in protecting
  1059.           the contents of those logs, thus protecting the privacy of the
  1060. Schulzrinne, et. al.        Standards Track                    [Page 73]
  1061. RFC 2326              Real Time Streaming Protocol            April 1998
  1062.           users of the servers. See [H15.3] for HTTP server
  1063.           recommendations regarding server logs.
  1064.    Transfer of Sensitive Information:
  1065.           There is no reason to believe that information transferred via
  1066.           RTSP may be any less sensitive than that normally transmitted
  1067.           via HTTP. Therefore, all of the precautions regarding the
  1068.           protection of data privacy and user privacy apply to
  1069.           implementors of RTSP clients, servers, and proxies. See
  1070.           [H15.4] for further details.
  1071.    Attacks Based On File and Path Names:
  1072.           Though RTSP URLs are opaque handles that do not necessarily
  1073.           have file system semantics, it is anticipated that many
  1074.           implementations will translate portions of the request URLs
  1075.           directly to file system calls. In such cases, file systems
  1076.           SHOULD follow the precautions outlined in [H15.5], such as
  1077.           checking for ".." in path components.
  1078.    Personal Information:
  1079.           RTSP clients are often privy to the same information that HTTP
  1080.           clients are (user name, location, etc.) and thus should be
  1081.           equally. See [H15.6] for further recommendations.
  1082.    Privacy Issues Connected to Accept Headers:
  1083.           Since may of the same "Accept" headers exist in RTSP as in
  1084.           HTTP, the same caveats outlined in [H15.7] with regards to
  1085.           their use should be followed.
  1086.    DNS Spoofing:
  1087.           Presumably, given the longer connection times typically
  1088.           associated to RTSP sessions relative to HTTP sessions, RTSP
  1089.           client DNS optimizations should be less prevalent.
  1090.           Nonetheless, the recommendations provided in [H15.8] are still
  1091.           relevant to any implementation which attempts to rely on a
  1092.           DNS-to-IP mapping to hold beyond a single use of the mapping.
  1093.    Location Headers and Spoofing:
  1094.           If a single server supports multiple organizations that do not
  1095.           trust one another, then it must check the values of Location
  1096.           and Content-Location headers in responses that are generated
  1097.           under control of said organizations to make sure that they do
  1098.           not attempt to invalidate resources over which they have no
  1099.           authority. ([H15.9])
  1100.    In addition to the recommendations in the current HTTP specification
  1101.    (RFC 2068 [2], as of this writing), future HTTP specifications may
  1102.    provide additional guidance on security issues.
  1103. Schulzrinne, et. al.        Standards Track                    [Page 74]
  1104. RFC 2326              Real Time Streaming Protocol            April 1998
  1105.    The following are added considerations for RTSP implementations.
  1106.    Concentrated denial-of-service attack:
  1107.           The protocol offers the opportunity for a remote-controlled
  1108.           denial-of-service attack. The attacker may initiate traffic
  1109.           flows to one or more IP addresses by specifying them as the
  1110.           destination in SETUP requests. While the attacker's IP address
  1111.           may be known in this case, this is not always useful in
  1112.           prevention of more attacks or ascertaining the attackers
  1113.           identity. Thus, an RTSP server SHOULD only allow client-
  1114.           specified destinations for RTSP-initiated traffic flows if the
  1115.           server has verified the client's identity, either against a
  1116.           database of known users using RTSP authentication mechanisms
  1117.           (preferably digest authentication or stronger), or other
  1118.           secure means.
  1119.    Session hijacking:
  1120.           Since there is no relation between a transport layer
  1121.           connection and an RTSP session, it is possible for a malicious
  1122.           client to issue requests with random session identifiers which
  1123.           would affect unsuspecting clients. The server SHOULD use a
  1124.           large, random and non-sequential session identifier to
  1125.           minimize the possibility of this kind of attack.
  1126.    Authentication:
  1127.           Servers SHOULD implement both basic and digest [8]
  1128.           authentication. In environments requiring tighter security for
  1129.           the control messages, the RTSP control stream may be
  1130.           encrypted.
  1131.    Stream issues:
  1132.           RTSP only provides for stream control. Stream delivery issues
  1133.           are not covered in this section, nor in the rest of this memo.
  1134.           RTSP implementations will most likely rely on other protocols
  1135.           such as RTP, IP multicast, RSVP and IGMP, and should address
  1136.           security considerations brought up in those and other
  1137.           applicable specifications.
  1138.    Persistently suspicious behavior:
  1139.           RTSP servers SHOULD return error code 403 (Forbidden) upon
  1140.           receiving a single instance of behavior which is deemed a
  1141.           security risk. RTSP servers SHOULD also be aware of attempts
  1142.           to probe the server for weaknesses and entry points and MAY
  1143.           arbitrarily disconnect and ignore further requests clients
  1144.           which are deemed to be in violation of local security policy.
  1145. Schulzrinne, et. al.        Standards Track                    [Page 75]
  1146. RFC 2326              Real Time Streaming Protocol            April 1998
  1147. Appendix A: RTSP Protocol State Machines
  1148.    The RTSP client and server state machines describe the behavior of
  1149.    the protocol from RTSP session initialization through RTSP session
  1150.    termination.
  1151.    State is defined on a per object basis. An object is uniquely
  1152.    identified by the stream URL and the RTSP session identifier. Any
  1153.    request/reply using aggregate URLs denoting RTSP presentations
  1154.    composed of multiple streams will have an effect on the individual
  1155.    states of all the streams. For example, if the presentation /movie
  1156.    contains two streams, /movie/audio and /movie/video, then the
  1157.    following command:
  1158.      PLAY rtsp://foo.com/movie RTSP/1.0
  1159.      CSeq: 559
  1160.      Session: 12345678
  1161.    will have an effect on the states of movie/audio and movie/video.
  1162.      This example does not imply a standard way to represent streams in
  1163.      URLs or a relation to the filesystem. See Section 3.2.
  1164.    The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER,
  1165.    SET_PARAMETER do not have any effect on client or server state and
  1166.    are therefore not listed in the state tables.
  1167. A.1 Client State Machine
  1168.    The client can assume the following states:
  1169.    Init:
  1170.           SETUP has been sent, waiting for reply.
  1171.    Ready:
  1172.           SETUP reply received or PAUSE reply received while in Playing
  1173.           state.
  1174.    Playing:
  1175.           PLAY reply received
  1176.    Recording:
  1177.           RECORD reply received
  1178.    In general, the client changes state on receipt of replies to
  1179.    requests. Note that some requests are effective at a future time or
  1180.    position (such as a PAUSE), and state also changes accordingly. If no
  1181.    explicit SETUP is required for the object (for example, it is
  1182. Schulzrinne, et. al.        Standards Track                    [Page 76]
  1183. RFC 2326              Real Time Streaming Protocol            April 1998
  1184.    available via a multicast group), state begins at Ready. In this
  1185.    case, there are only two states, Ready and Playing. The client also
  1186.    changes state from Playing/Recording to Ready when the end of the
  1187.    requested range is reached.
  1188.    The "next state" column indicates the state assumed after receiving a
  1189.    success response (2xx). If a request yields a status code of 3xx, the
  1190.    state becomes Init, and a status code of 4xx yields no change in
  1191.    state. Messages not listed for each state MUST NOT be issued by the
  1192.    client in that state, with the exception of messages not affecting
  1193.    state, as listed above. Receiving a REDIRECT from the server is
  1194.    equivalent to receiving a 3xx redirect status from the server.
  1195.    state       message sent     next state after response
  1196.    Init        SETUP            Ready
  1197.                TEARDOWN         Init
  1198.    Ready       PLAY             Playing
  1199.                RECORD           Recording
  1200.                TEARDOWN         Init
  1201.                SETUP            Ready
  1202.    Playing     PAUSE            Ready
  1203.                TEARDOWN         Init
  1204.                PLAY             Playing
  1205.                SETUP            Playing (changed transport)
  1206.    Recording   PAUSE            Ready
  1207.                TEARDOWN         Init
  1208.                RECORD           Recording
  1209.                SETUP            Recording (changed transport)
  1210. A.2 Server State Machine
  1211.    The server can assume the following states:
  1212.    Init:
  1213.           The initial state, no valid SETUP has been received yet.
  1214.    Ready:
  1215.           Last SETUP received was successful, reply sent or after
  1216.           playing, last PAUSE received was successful, reply sent.
  1217.    Playing:
  1218.           Last PLAY received was successful, reply sent. Data is being
  1219.           sent.
  1220.    Recording:
  1221.           The server is recording media data.
  1222. Schulzrinne, et. al.        Standards Track                    [Page 77]
  1223. RFC 2326              Real Time Streaming Protocol            April 1998
  1224.    In general, the server changes state on receiving requests. If the
  1225.    server is in state Playing or Recording and in unicast mode, it MAY
  1226.    revert to Init and tear down the RTSP session if it has not received
  1227.    "wellness" information, such as RTCP reports or RTSP commands, from
  1228.    the client for a defined interval, with a default of one minute. The
  1229.    server can declare another timeout value in the Session response
  1230.    header (Section 12.37). If the server is in state Ready, it MAY
  1231.    revert to Init if it does not receive an RTSP request for an interval
  1232.    of more than one minute. Note that some requests (such as PAUSE) may
  1233.    be effective at a future time or position, and server state changes
  1234.    at the appropriate time. The server reverts from state Playing or
  1235.    Recording to state Ready at the end of the range requested by the
  1236.    client.
  1237.    The REDIRECT message, when sent, is effective immediately unless it
  1238.    has a Range header specifying when the redirect is effective. In such
  1239.    a case, server state will also change at the appropriate time.
  1240.    If no explicit SETUP is required for the object, the state starts at
  1241.    Ready and there are only two states, Ready and Playing.
  1242.    The "next state" column indicates the state assumed after sending a
  1243.    success response (2xx). If a request results in a status code of 3xx,
  1244.    the state becomes Init. A status code of 4xx results in no change.
  1245.      state           message received  next state
  1246.      Init            SETUP             Ready
  1247.                      TEARDOWN          Init
  1248.      Ready           PLAY              Playing
  1249.                      SETUP             Ready
  1250.                      TEARDOWN          Init
  1251.                      RECORD            Recording
  1252.      Playing         PLAY              Playing
  1253.                      PAUSE             Ready
  1254.                      TEARDOWN          Init
  1255.                      SETUP             Playing
  1256.      Recording       RECORD            Recording
  1257.                      PAUSE             Ready
  1258.                      TEARDOWN          Init
  1259.                      SETUP             Recording
  1260. Schulzrinne, et. al.        Standards Track                    [Page 78]
  1261. RFC 2326              Real Time Streaming Protocol            April 1998
  1262. Appendix B: Interaction with RTP
  1263.    RTSP allows media clients to control selected, non-contiguous
  1264.    sections of media presentations, rendering those streams with an RTP
  1265.    media layer[24]. The media layer rendering the RTP stream should not
  1266.    be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP
  1267.    timestamps MUST be continuous and monotonic across jumps of NPT.
  1268.    As an example, assume a clock frequency of 8000 Hz, a packetization
  1269.    interval of 100 ms and an initial sequence number and timestamp of
  1270.    zero. First we play NPT 10 through 15, then skip ahead and play NPT
  1271.    18 through 20. The first segment is presented as RTP packets with
  1272.    sequence numbers 0 through 49 and timestamp 0 through 39,200. The
  1273.    second segment consists of RTP packets with sequence number 50
  1274.    through 69, with timestamps 40,000 through 55,200.
  1275.      We cannot assume that the RTSP client can communicate with the RTP
  1276.      media agent, as the two may be independent processes. If the RTP
  1277.      timestamp shows the same gap as the NPT, the media agent will
  1278.      assume that there is a pause in the presentation. If the jump in
  1279.      NPT is large enough, the RTP timestamp may roll over and the media
  1280.      agent may believe later packets to be duplicates of packets just
  1281.      played out.
  1282.      For certain datatypes, tight integration between the RTSP layer and
  1283.      the RTP layer will be necessary. This by no means precludes the
  1284.      above restriction. Combined RTSP/RTP media clients should use the
  1285.      RTP-Info field to determine whether incoming RTP packets were sent
  1286.      before or after a seek.
  1287.    For continuous audio, the server SHOULD set the RTP marker bit at the
  1288.    beginning of serving a new PLAY request. This allows the client to
  1289.    perform playout delay adaptation.
  1290.    For scaling (see Section 12.34), RTP timestamps should correspond to
  1291.    the playback timing. For example, when playing video recorded at 30
  1292.    frames/second at a scale of two and speed (Section 12.35) of one, the
  1293.    server would drop every second frame to maintain and deliver video
  1294.    packets with the normal timestamp spacing of 3,000 per frame, but NPT
  1295.    would increase by 1/15 second for each video frame.
  1296.    The client can maintain a correct display of NPT by noting the RTP
  1297.    timestamp value of the first packet arriving after repositioning. The
  1298.    sequence parameter of the RTP-Info (Section 12.33) header provides
  1299.    the first sequence number of the next segment.
  1300. Schulzrinne, et. al.        Standards Track                    [Page 79]
  1301. RFC 2326              Real Time Streaming Protocol            April 1998
  1302. Appendix C: Use of SDP for RTSP Session Descriptions
  1303.    The Session Description Protocol (SDP, RFC 2327 [6]) may be used to
  1304.    describe streams or presentations in RTSP. Such usage is limited to
  1305.    specifying means of access and encoding(s) for:
  1306.    aggregate control:
  1307.           A presentation composed of streams from one or more servers
  1308.           that are not available for aggregate control. Such a
  1309.           description is typically retrieved by HTTP or other non-RTSP
  1310.           means. However, they may be received with ANNOUNCE methods.
  1311.    non-aggregate control:
  1312.           A presentation composed of multiple streams from a single
  1313.           server that are available for aggregate control. Such a
  1314.           description is typically returned in reply to a DESCRIBE
  1315.           request on a URL, or received in an ANNOUNCE method.
  1316.    This appendix describes how an SDP file, retrieved, for example,
  1317.    through HTTP, determines the operation of an RTSP session. It also
  1318.    describes how a client should interpret SDP content returned in reply
  1319.    to a DESCRIBE request. SDP provides no mechanism by which a client
  1320.    can distinguish, without human guidance, between several media
  1321.    streams to be rendered simultaneously and a set of alternatives
  1322.    (e.g., two audio streams spoken in different languages).
  1323. C.1 Definitions
  1324.    The terms "session-level", "media-level" and other key/attribute
  1325.    names and values used in this appendix are to be used as defined in
  1326.    SDP (RFC 2327 [6]):
  1327. C.1.1 Control URL
  1328.    The "a=control:" attribute is used to convey the control URL. This
  1329.    attribute is used both for the session and media descriptions. If
  1330.    used for individual media, it indicates the URL to be used for
  1331.    controlling that particular media stream. If found at the session
  1332.    level, the attribute indicates the URL for aggregate control.
  1333.    Example:
  1334.      a=control:rtsp://example.com/foo
  1335.    This attribute may contain either relative and absolute URLs,
  1336.    following the rules and conventions set out in RFC 1808 [25].
  1337.    Implementations should look for a base URL in the following order:
  1338. Schulzrinne, et. al.        Standards Track                    [Page 80]
  1339. RFC 2326              Real Time Streaming Protocol            April 1998
  1340.    1.     The RTSP Content-Base field
  1341.    2.     The RTSP Content-Location field
  1342.    3.     The RTSP request URL
  1343.    If this attribute contains only an asterisk (*), then the URL is
  1344.    treated as if it were an empty embedded URL, and thus inherits the
  1345.    entire base URL.
  1346. C.1.2 Media streams
  1347.    The "m=" field is used to enumerate the streams. It is expected that
  1348.    all the specified streams will be rendered with appropriate
  1349.    synchronization. If the session is unicast, the port number serves as
  1350.    a recommendation from the server to the client; the client still has
  1351.    to include it in its SETUP request and may ignore this
  1352.    recommendation.  If the server has no preference, it SHOULD set the
  1353.    port number value to zero.
  1354.    Example:
  1355.      m=audio 0 RTP/AVP 31
  1356. C.1.3 Payload type(s)
  1357.    The payload type(s) are specified in the "m=" field. In case the
  1358.    payload type is a static payload type from RFC 1890 [1], no other
  1359.    information is required. In case it is a dynamic payload type, the
  1360.    media attribute "rtpmap" is used to specify what the media is. The
  1361.    "encoding name" within the "rtpmap" attribute may be one of those
  1362.    specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
  1363.    with a "X-" prefix as specified in SDP (RFC 2327 [6]).  Codec-
  1364.    specific parameters are not specified in this field, but rather in
  1365.    the "fmtp" attribute described below. Implementors seeking to
  1366.    register new encodings should follow the procedure in RFC 1890 [1].
  1367.    If the media type is not suited to the RTP AV profile, then it is
  1368.    recommended that a new profile be created and the appropriate profile
  1369.    name be used in lieu of "RTP/AVP" in the "m=" field.
  1370. C.1.4 Format-specific parameters
  1371.    Format-specific parameters are conveyed using the "fmtp" media
  1372.    attribute. The syntax of the "fmtp" attribute is specific to the
  1373.    encoding(s) that the attribute refers to. Note that the packetization
  1374.    interval is conveyed using the "ptime" attribute.
  1375. Schulzrinne, et. al.        Standards Track                    [Page 81]
  1376. RFC 2326              Real Time Streaming Protocol            April 1998
  1377. C.1.5 Range of presentation
  1378.    The "a=range" attribute defines the total time range of the stored
  1379.    session. (The length of live sessions can be deduced from the "t" and
  1380.    "r" parameters.) Unless the presentation contains media streams of
  1381.    different durations, the range attribute is a session-level
  1382.    attribute. The unit is specified first, followed by the value range.
  1383.    The units and their values are as defined in Section 3.5, 3.6 and
  1384.    3.7.
  1385.    Examples:
  1386.      a=range:npt=0-34.4368
  1387.      a=range:clock=19971113T2115-19971113T2203
  1388. C.1.6 Time of availability
  1389.    The "t=" field MUST contain suitable values for the start and stop
  1390.    times for both aggregate and non-aggregate stream control. With
  1391.    aggregate control, the server SHOULD indicate a stop time value for
  1392.    which it guarantees the description to be valid, and a start time
  1393.    that is equal to or before the time at which the DESCRIBE request was
  1394.    received. It MAY also indicate start and stop times of 0, meaning
  1395.    that the session is always available. With non-aggregate control, the
  1396.    values should reflect the actual period for which the session is
  1397.    available in keeping with SDP semantics, and not depend on other
  1398.    means (such as the life of the web page containing the description)
  1399.    for this purpose.
  1400. C.1.7 Connection Information
  1401.    In SDP, the "c=" field contains the destination address for the media
  1402.    stream. However, for on-demand unicast streams and some multicast
  1403.    streams, the destination address is specified by the client via the
  1404.    SETUP request. Unless the media content has a fixed destination
  1405.    address, the "c=" field is to be set to a suitable null value. For
  1406.    addresses of type "IP4", this value is "0.0.0.0".
  1407.   C.1.8 Entity Tag
  1408.    The optional "a=etag" attribute identifies a version of the session
  1409.    description. It is opaque to the client. SETUP requests may include
  1410.    this identifier in the If-Match field (see section 12.22) to only
  1411.    allow session establishment if this attribute value still corresponds
  1412.    to that of the current description. The attribute value is opaque and
  1413.    may contain any character allowed within SDP attribute values.
  1414.    Example:
  1415.      a=etag:158bb3e7c7fd62ce67f12b533f06b83a
  1416. Schulzrinne, et. al.        Standards Track                    [Page 82]
  1417. RFC 2326              Real Time Streaming Protocol            April 1998
  1418.      One could argue that the "o=" field provides identical
  1419.      functionality. However, it does so in a manner that would put
  1420.      constraints on servers that need to support multiple session
  1421.      description types other than SDP for the same piece of media
  1422.      content.
  1423. C.2 Aggregate Control Not Available
  1424.    If a presentation does not support aggregate control and multiple
  1425.    media sections are specified, each section MUST have the control URL
  1426.    specified via the "a=control:" attribute.
  1427.    Example:
  1428.      v=0
  1429.      o=- 2890844256 2890842807 IN IP4 204.34.34.32
  1430.      s=I came from a web page
  1431.      t=0 0
  1432.      c=IN IP4 0.0.0.0
  1433.      m=video 8002 RTP/AVP 31
  1434.      a=control:rtsp://audio.com/movie.aud
  1435.      m=audio 8004 RTP/AVP 3
  1436.      a=control:rtsp://video.com/movie.vid
  1437.    Note that the position of the control URL in the description implies
  1438.    that the client establishes separate RTSP control sessions to the
  1439.    servers audio.com and video.com.
  1440.    It is recommended that an SDP file contains the complete media
  1441.    initialization information even if it is delivered to the media
  1442.    client through non-RTSP means. This is necessary as there is no
  1443.    mechanism to indicate that the client should request more detailed
  1444.    media stream information via DESCRIBE.
  1445. C.3 Aggregate Control Available
  1446.    In this scenario, the server has multiple streams that can be
  1447.    controlled as a whole. In this case, there are both media-level
  1448.    "a=control:" attributes, which are used to specify the stream URLs,
  1449.    and a session-level "a=control:" attribute which is used as the
  1450.    request URL for aggregate control. If the media-level URL is
  1451.    relative, it is resolved to absolute URLs according to Section C.1.1
  1452.    above.
  1453.    If the presentation comprises only a single stream, the media-level
  1454.    "a=control:" attribute may be omitted altogether. However, if the
  1455.    presentation contains more than one stream, each media stream section
  1456.    MUST contain its own "a=control" attribute.
  1457. Schulzrinne, et. al.        Standards Track                    [Page 83]
  1458. RFC 2326              Real Time Streaming Protocol            April 1998
  1459.    Example:
  1460.      v=0
  1461.      o=- 2890844256 2890842807 IN IP4 204.34.34.32
  1462.      s=I contain
  1463.      i=<more info>
  1464.      t=0 0
  1465.      c=IN IP4 0.0.0.0
  1466.      a=control:rtsp://example.com/movie/
  1467.      m=video 8002 RTP/AVP 31
  1468.      a=control:trackID=1
  1469.      m=audio 8004 RTP/AVP 3
  1470.      a=control:trackID=2
  1471.    In this example, the client is required to establish a single RTSP
  1472.    session to the server, and uses the URLs
  1473.    rtsp://example.com/movie/trackID=1 and
  1474.    rtsp://example.com/movie/trackID=2 to set up the video and audio
  1475.    streams, respectively. The URL rtsp://example.com/movie/ controls the
  1476.    whole movie.
  1477. Schulzrinne, et. al.        Standards Track                    [Page 84]
  1478. RFC 2326              Real Time Streaming Protocol            April 1998
  1479. Appendix D: Minimal RTSP implementation
  1480. D.1 Client
  1481.    A client implementation MUST be able to do the following :
  1482.      * Generate the following requests: SETUP, TEARDOWN, and one of PLAY
  1483.        (i.e., a minimal playback client) or RECORD (i.e., a minimal
  1484.        recording client). If RECORD is implemented, ANNOUNCE must be
  1485.        implemented as well.
  1486.      * Include the following headers in requests: CSeq, Connection,
  1487.        Session, Transport. If ANNOUNCE is implemented, the capability to
  1488.        include headers Content-Language, Content-Encoding, Content-
  1489.        Length, and Content-Type should be as well.
  1490.      * Parse and understand the following headers in responses: CSeq,
  1491.        Connection, Session, Transport, Content-Language, Content-
  1492.        Encoding, Content-Length, Content-Type. If RECORD is implemented,
  1493.        the Location header must be understood as well.  RTP-compliant
  1494.        implementations should also implement RTP-Info.
  1495.      * Understand the class of each error code received and notify the
  1496.        end-user, if one is present, of error codes in classes 4xx and
  1497.        5xx. The notification requirement may be relaxed if the end-user
  1498.        explicitly does not want it for one or all status codes.
  1499.      * Expect and respond to asynchronous requests from the server, such
  1500.        as ANNOUNCE. This does not necessarily mean that it should
  1501.        implement the ANNOUNCE method, merely that it MUST respond
  1502.        positively or negatively to any request received from the server.
  1503.    Though not required, the following are highly recommended at the time
  1504.    of publication for practical interoperability with initial
  1505.    implementations and/or to be a "good citizen".
  1506.      * Implement RTP/AVP/UDP as a valid transport.
  1507.      * Inclusion of the User-Agent header.
  1508.      * Understand SDP session descriptions as defined in Appendix C
  1509.      * Accept media initialization formats (such as SDP) from standard
  1510.        input, command line, or other means appropriate to the operating
  1511.        environment to act as a "helper application" for other
  1512.        applications (such as web browsers).
  1513.      There may be RTSP applications different from those initially
  1514.      envisioned by the contributors to the RTSP specification for which
  1515.      the requirements above do not make sense. Therefore, the
  1516.      recommendations above serve only as guidelines instead of strict
  1517.      requirements.
  1518. Schulzrinne, et. al.        Standards Track                    [Page 85]
  1519. RFC 2326              Real Time Streaming Protocol            April 1998
  1520. D.1.1 Basic Playback
  1521.    To support on-demand playback of media streams, the client MUST
  1522.    additionally be able to do the following:
  1523.      * generate the PAUSE request;
  1524.      * implement the REDIRECT method, and the Location header.
  1525. D.1.2 Authentication-enabled
  1526.    In order to access media presentations from RTSP servers that require
  1527.    authentication, the client MUST additionally be able to do the
  1528.    following:
  1529.      * recognize the 401 status code;
  1530.      * parse and include the WWW-Authenticate header;
  1531.      * implement Basic Authentication and Digest Authentication.
  1532. D.2 Server
  1533.    A minimal server implementation MUST be able to do the following:
  1534.      * Implement the following methods: SETUP, TEARDOWN, OPTIONS and
  1535.        either PLAY (for a minimal playback server) or RECORD (for a
  1536.        minimal recording server).  If RECORD is implemented, ANNOUNCE
  1537.        should be implemented as well.
  1538.      * Include the following headers in responses: Connection,
  1539.        Content-Length, Content-Type, Content-Language, Content-Encoding,
  1540.        Transport, Public. The capability to include the Location header
  1541.        should be implemented if the RECORD method is. RTP-compliant
  1542.        implementations should also implement the RTP-Info field.
  1543.      * Parse and respond appropriately to the following headers in
  1544.        requests: Connection, Session, Transport, Require.
  1545.    Though not required, the following are highly recommended at the time
  1546.    of publication for practical interoperability with initial
  1547.    implementations and/or to be a "good citizen".
  1548.      * Implement RTP/AVP/UDP as a valid transport.
  1549.      * Inclusion of the Server header.
  1550.      * Implement the DESCRIBE method.
  1551.      * Generate SDP session descriptions as defined in Appendix C
  1552.      There may be RTSP applications different from those initially
  1553.      envisioned by the contributors to the RTSP specification for which
  1554.      the requirements above do not make sense. Therefore, the
  1555.      recommendations above serve only as guidelines instead of strict
  1556.      requirements.
  1557. Schulzrinne, et. al.        Standards Track                    [Page 86]
  1558. RFC 2326              Real Time Streaming Protocol            April 1998
  1559. D.2.1 Basic Playback
  1560.    To support on-demand playback of media streams, the server MUST
  1561.    additionally be able to do the following:
  1562.      * Recognize the Range header, and return an error if seeking is not
  1563.        supported.
  1564.      * Implement the PAUSE method.
  1565.    In addition, in order to support commonly-accepted user interface
  1566.    features, the following are highly recommended for on-demand media
  1567.    servers:
  1568.      * Include and parse the Range header, with NPT units.
  1569.        Implementation of SMPTE units is recommended.
  1570.      * Include the length of the media presentation in the media
  1571.        initialization information.
  1572.      * Include mappings from data-specific timestamps to NPT. When RTP
  1573.        is used, the rtptime portion of the RTP-Info field may be used to
  1574.        map RTP timestamps to NPT.
  1575.      Client implementations may use the presence of length information
  1576.      to determine if the clip is seekable, and visibly disable seeking
  1577.      features for clips for which the length information is unavailable.
  1578.      A common use of the presentation length is to implement a "slider
  1579.      bar" which serves as both a progress indicator and a timeline
  1580.      positioning tool.
  1581.      Mappings from RTP timestamps to NPT are necessary to ensure correct
  1582.      positioning of the slider bar.
  1583. D.2.2 Authentication-enabled
  1584.    In order to correctly handle client authentication, the server MUST
  1585.    additionally be able to do the following:
  1586.      * Generate the 401 status code when authentication is required for
  1587.        the resource.
  1588.      * Parse and include the WWW-Authenticate header
  1589.      * Implement Basic Authentication and Digest Authentication
  1590. Schulzrinne, et. al.        Standards Track                    [Page 87]
  1591. RFC 2326              Real Time Streaming Protocol            April 1998
  1592. Appendix E: Authors' Addresses
  1593.    Henning Schulzrinne
  1594.    Dept. of Computer Science
  1595.    Columbia University
  1596.    1214 Amsterdam Avenue
  1597.    New York, NY 10027
  1598.    USA
  1599.    EMail: schulzrinne@cs.columbia.edu
  1600.    Anup Rao
  1601.    Netscape Communications Corp.
  1602.    501 E. Middlefield Road
  1603.    Mountain View, CA 94043
  1604.    USA
  1605.    EMail: anup@netscape.com
  1606.    Robert Lanphier
  1607.    RealNetworks
  1608.    1111 Third Avenue Suite 2900
  1609.    Seattle, WA 98101
  1610.    USA
  1611.    EMail: robla@real.com
  1612. Schulzrinne, et. al.        Standards Track                    [Page 88]
  1613. RFC 2326              Real Time Streaming Protocol            April 1998
  1614. Appendix F: Acknowledgements
  1615.    This memo is based on the functionality of the original RTSP document
  1616.    submitted in October 96. It also borrows format and descriptions from
  1617.    HTTP/1.1.
  1618.    This document has benefited greatly from the comments of all those
  1619.    participating in the MMUSIC-WG. In addition to those already
  1620.    mentioned, the following individuals have contributed to this
  1621.    specification:
  1622.    Rahul Agarwal, Torsten Braun, Brent Browning, Bruce Butterfield,
  1623.    Steve Casner, Francisco Cortes, Kelly Djahandari, Martin Dunsmuir,
  1624.    Eric Fleischman, Jay Geagan, Andy Grignon, V. Guruprasad, Peter
  1625.    Haight, Mark Handley, Brad Hefta-Gaub, John K. Ho, Philipp Hoschka,
  1626.    Anne Jones, Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan
  1627.    Lennox, Eduardo F. Llach, Rob McCool, David Oran, Maria Papadopouli,
  1628.    Sujal Patel, Ema Patki, Alagu Periyannan, Igor Plotnikov, Pinaki
  1629.    Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen, and
  1630.    John Francis Stracke.
  1631. Schulzrinne, et. al.        Standards Track                    [Page 89]
  1632. RFC 2326              Real Time Streaming Protocol            April 1998
  1633. References
  1634.    1      Schulzrinne, H., "RTP profile for audio and video conferences
  1635.           with minimal control", RFC 1890, January 1996.
  1636.    2      Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
  1637.           Berners-Lee, "Hypertext transfer protocol - HTTP/1.1", RFC
  1638.           2068, January 1997.
  1639.    3      Yergeau, F., Nicol, G., Adams, G., and M. Duerst,
  1640.           "Internationalization of the hypertext markup language", RFC
  1641.           2070, January 1997.
  1642.    4      Bradner, S., "Key words for use in RFCs to indicate
  1643.           requirement levels", BCP 14, RFC 2119, March 1997.
  1644.    5      ISO/IEC, "Information technology - generic coding of moving
  1645.           pictures and associated audio information - part 6: extension
  1646.           for digital storage media and control," Draft International
  1647.           Standard ISO 13818-6, International Organization for
  1648.           Standardization ISO/IEC JTC1/SC29/WG11, Geneva, Switzerland,
  1649.           Nov. 1995.
  1650.    6      Handley, M., and V. Jacobson, "SDP: Session Description
  1651.           Protocol", RFC 2327, April 1998.
  1652.    7      Franks, J., Hallam-Baker, P., and J. Hostetler, "An extension to
  1653.           HTTP: digest access authentication", RFC 2069, January 1997.
  1654.    8      Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
  1655.           1980.
  1656.    9      Hinden, B. and C. Partridge, "Version 2 of the reliable data
  1657.           protocol (RDP)", RFC 1151, April 1990.
  1658.    10     Postel, J., "Transmission control protocol", STD 7, RFC 793,
  1659.           September 1981.
  1660.    11     H. Schulzrinne, "A comprehensive multimedia control
  1661.           architecture for the Internet," in Proc. International
  1662.           Workshop on Network and Operating System Support for Digital
  1663.           Audio and Video (NOSSDAV), (St. Louis, Missouri), May 1997.
  1664.    12     International Telecommunication Union, "Visual telephone
  1665.           systems and equipment for local area networks which provide a
  1666.           non-guaranteed quality of service," Recommendation H.323,
  1667.           Telecommunication Standardization Sector of ITU, Geneva,
  1668.           Switzerland, May 1996.
  1669. Schulzrinne, et. al.        Standards Track                    [Page 90]
  1670. RFC 2326              Real Time Streaming Protocol            April 1998
  1671.    13     McMahon, P., "GSS-API authentication method for SOCKS version
  1672.           5", RFC 1961, June 1996.
  1673.    14     J. Miller, P. Resnick, and D. Singer, "Rating services and
  1674.           rating systems (and their machine readable descriptions),"
  1675.           Recommendation REC-PICS-services-961031, W3C (World Wide Web
  1676.           Consortium), Boston, Massachusetts, Oct. 1996.
  1677.    15     J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS
  1678.           label distribution label syntax and communication protocols,"
  1679.           Recommendation REC-PICS-labels-961031, W3C (World Wide Web
  1680.           Consortium), Boston, Massachusetts, Oct. 1996.
  1681.    16     Crocker, D. and P. Overell, "Augmented BNF for syntax
  1682.           specifications: ABNF", RFC 2234, November 1997.
  1683.    17     Braden, B., "Requirements for internet hosts - application and
  1684.           support", STD 3, RFC 1123, October 1989.
  1685.    18     Elz, R., "A compact representation of IPv6 addresses", RFC
  1686.           1924, April 1996.
  1687.    19     Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
  1688.           resource locators (URL)", RFC 1738, December 1994.
  1689.    20     Yergeau, F., "UTF-8, a transformation format of ISO 10646",
  1690.           RFC 2279, January 1998.
  1691.    22     Braden, B., "T/TCP - TCP extensions for transactions
  1692.           functional specification", RFC 1644, July 1994.
  1693.    22     W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
  1694.           Reading, Massachusetts: Addison-Wesley, 1994.
  1695.    23     Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
  1696.           "RTP: a transport protocol for real-time applications", RFC
  1697.           1889, January 1996.
  1698.    24     Fielding, R., "Relative uniform resource locators", RFC 1808,
  1699.           June 1995.
  1700. Schulzrinne, et. al.        Standards Track                    [Page 91]
  1701. RFC 2326              Real Time Streaming Protocol            April 1998
  1702. Full Copyright Statement
  1703.    Copyright (C) The Internet Society (1998). All Rights Reserved.
  1704.    This document and translations of it may be copied and furnished to
  1705.    others, and derivative works that comment on or otherwise explain it
  1706.    or assist in its implementation may be prepared, copied, published
  1707.    and distributed, in whole or in part, without restriction of any
  1708.    kind, provided that the above copyright notice and this paragraph are
  1709.    included on all such copies and derivative works. However, this
  1710.    document itself may not be modified in any way, such as by removing
  1711.    the copyright notice or references to the Internet Society or other
  1712.    Internet organizations, except as needed for the purpose of
  1713.    developing Internet standards in which case the procedures for
  1714.    copyrights defined in the Internet Standards process must be
  1715.    followed, or as required to translate it into languages other than
  1716.    English.
  1717.    The limited permissions granted above are perpetual and will not be
  1718.    revoked by the Internet Society or its successors or assigns.
  1719.    This document and the information contained herein is provided on an
  1720.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1721.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1722.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1723.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1724.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1725. Schulzrinne, et. al.        Standards Track                    [Page 92]