Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2326

Real Time Streaming Protocol (RTSP)

Pages: 92
Obsoleted by:  7826
Part 3 of 4 – Pages 41 to 72
First   Prev   Next

ToP   noToC   RFC2326 - Page 41   prevText
11 Status Code Definitions

   Where applicable, HTTP status [H10] codes are reused. Status codes
   that have the same meaning are not repeated here. See Table 1 for a
   listing of which status codes may be returned by which requests.

11.1 Success 2xx

11.1.1 250 Low on Storage Space

   The server returns this warning after receiving a RECORD request that
   it may not be able to fulfill completely due to insufficient storage
   space. If possible, the server should use the Range header to
   indicate what time period it may still be able to record. Since other
   processes on the server may be consuming storage space
   simultaneously, a client should take this only as an estimate.

11.2 Redirection 3xx

   See [H10.3].

   Within RTSP, redirection may be used for load balancing or
   redirecting stream requests to a server topologically closer to the
   client.  Mechanisms to determine topological proximity are beyond the
   scope of this specification.
ToP   noToC   RFC2326 - Page 42
11.3 Client Error 4xx

11.3.1 405 Method Not Allowed

   The method specified in the request is not allowed for the resource
   identified by the request URI. The response MUST include an Allow
   header containing a list of valid methods for the requested resource.
   This status code is also to be used if a request attempts to use a
   method not indicated during SETUP, e.g., if a RECORD request is
   issued even though the mode parameter in the Transport header only
   specified PLAY.

11.3.2 451 Parameter Not Understood

   The recipient of the request does not support one or more parameters
   contained in the request.

11.3.3 452 Conference Not Found

   The conference indicated by a Conference header field is unknown to
   the media server.

11.3.4 453 Not Enough Bandwidth

   The request was refused because there was insufficient bandwidth.
   This may, for example, be the result of a resource reservation
   failure.

11.3.5 454 Session Not Found

   The RTSP session identifier in the Session header is missing,
   invalid, or has timed out.

11.3.6 455 Method Not Valid in This State

   The client or server cannot process this request in its current
   state.  The response SHOULD contain an Allow header to make error
   recovery easier.

11.3.7 456 Header Field Not Valid for Resource

   The server could not act on a required request header. For example,
   if PLAY contains the Range header field but the stream does not allow
   seeking.
ToP   noToC   RFC2326 - Page 43
11.3.8 457 Invalid Range

   The Range value given is out of bounds, e.g., beyond the end of the
   presentation.

11.3.9 458 Parameter Is Read-Only

   The parameter to be set by SET_PARAMETER can be read but not
   modified.

11.3.10 459 Aggregate Operation Not Allowed

   The requested method may not be applied on the URL in question since
   it is an aggregate (presentation) URL. The method may be applied on a
   stream URL.

11.3.11 460 Only Aggregate Operation Allowed

   The requested method may not be applied on the URL in question since
   it is not an aggregate (presentation) URL. The method may be applied
   on the presentation URL.

11.3.12 461 Unsupported Transport

   The Transport field did not contain a supported transport
   specification.

11.3.13 462 Destination Unreachable

   The data transmission channel could not be established because the
   client address could not be reached. This error will most likely be
   the result of a client attempt to place an invalid Destination
   parameter in the Transport field.

11.3.14 551 Option not supported

   An option given in the Require or the Proxy-Require fields was not
   supported. The Unsupported header should be returned stating the
   option for which there is no support.
ToP   noToC   RFC2326 - Page 44
12 Header Field Definitions

   HTTP/1.1 [2] or other, non-standard header fields not listed here
   currently have no well-defined meaning and SHOULD be ignored by the
   recipient.

   Table 3 summarizes the header fields used by RTSP. Type "g"
   designates general request headers to be found in both requests and
   responses, type "R" designates request headers, type "r" designates
   response headers, and type "e" designates entity header fields.
   Fields marked with "req." in the column labeled "support" MUST be
   implemented by the recipient for a particular method, while fields
   marked "opt." are optional. Note that not all fields marked "req."
   will be sent in every request of this type. The "req."  means only
   that client (for response headers) and server (for request headers)
   MUST implement the fields. The last column lists the method for which
   this header field is meaningful; the designation "entity" refers to
   all methods that return a message body. Within this specification,
   DESCRIBE and GET_PARAMETER fall into this class.
ToP   noToC   RFC2326 - Page 45
   Header               type   support   methods
   Accept               R      opt.      entity
   Accept-Encoding      R      opt.      entity
   Accept-Language      R      opt.      all
   Allow                r      opt.      all
   Authorization        R      opt.      all
   Bandwidth            R      opt.      all
   Blocksize            R      opt.      all but OPTIONS, TEARDOWN
   Cache-Control        g      opt.      SETUP
   Conference           R      opt.      SETUP
   Connection           g      req.      all
   Content-Base         e      opt.      entity
   Content-Encoding     e      req.      SET_PARAMETER
   Content-Encoding     e      req.      DESCRIBE, ANNOUNCE
   Content-Language     e      req.      DESCRIBE, ANNOUNCE
   Content-Length       e      req.      SET_PARAMETER, ANNOUNCE
   Content-Length       e      req.      entity
   Content-Location     e      opt.      entity
   Content-Type         e      req.      SET_PARAMETER, ANNOUNCE
   Content-Type         r      req.      entity
   CSeq                 g      req.      all
   Date                 g      opt.      all
   Expires              e      opt.      DESCRIBE, ANNOUNCE
   From                 R      opt.      all
   If-Modified-Since    R      opt.      DESCRIBE, SETUP
   Last-Modified        e      opt.      entity
   Proxy-Authenticate
   Proxy-Require        R      req.      all
   Public               r      opt.      all
   Range                R      opt.      PLAY, PAUSE, RECORD
   Range                r      opt.      PLAY, PAUSE, RECORD
   Referer              R      opt.      all
   Require              R      req.      all
   Retry-After          r      opt.      all
   RTP-Info             r      req.      PLAY
   Scale                Rr     opt.      PLAY, RECORD
   Session              Rr     req.      all but SETUP, OPTIONS
   Server               r      opt.      all
   Speed                Rr     opt.      PLAY
   Transport            Rr     req.      SETUP
   Unsupported          r      req.      all
   User-Agent           R      opt.      all
   Via                  g      opt.      all
   WWW-Authenticate     r      opt.      all
ToP   noToC   RFC2326 - Page 46
   Overview of RTSP header fields

12.1 Accept

   The Accept request-header field can be used to specify certain
   presentation description content types which are acceptable for the
   response.

     The "level" parameter for presentation descriptions is properly
     defined as part of the MIME type registration, not here.

   See [H14.1] for syntax.

   Example of use:
     Accept: application/rtsl, application/sdp;level=2

12.2 Accept-Encoding

     See [H14.3]

12.3 Accept-Language

   See [H14.4]. Note that the language specified applies to the
   presentation description and any reason phrases, not the media
   content.

12.4 Allow

   The Allow response header field lists the methods supported by the
   resource identified by the request-URI. The purpose of this field is
   to strictly inform the recipient of valid methods associated with the
   resource. An Allow header field must be present in a 405 (Method not
   allowed) response.

   Example of use:
     Allow: SETUP, PLAY, RECORD, SET_PARAMETER

12.5 Authorization

     See [H14.8]

12.6 Bandwidth

   The Bandwidth request header field describes the estimated bandwidth
   available to the client, expressed as a positive integer and measured
   in bits per second. The bandwidth available to the client may change
   during an RTSP session, e.g., due to modem retraining.
ToP   noToC   RFC2326 - Page 47
   Bandwidth = "Bandwidth" ":" 1*DIGIT

   Example:
     Bandwidth: 4000

12.7 Blocksize

   This request header field is sent from the client to the media server
   asking the server for a particular media packet size. This packet
   size does not include lower-layer headers such as IP, UDP, or RTP.
   The server is free to use a blocksize which is lower than the one
   requested. The server MAY truncate this packet size to the closest
   multiple of the minimum, media-specific block size, or override it
   with the media-specific size if necessary. The block size MUST be a
   positive decimal number, measured in octets. The server only returns
   an error (416) if the value is syntactically invalid.

12.8 Cache-Control

   The Cache-Control general header field is used to specify directives
   that MUST be obeyed by all caching mechanisms along the
   request/response chain.

   Cache directives must be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain. It is not possible to specify a cache-
   directive for a specific cache.

   Cache-Control should only be specified in a SETUP request and its
   response. Note: Cache-Control does not govern the caching of
   responses as for HTTP, but rather of the stream identified by the
   SETUP request.  Responses to RTSP requests are not cacheable, except
   for responses to DESCRIBE.

   Cache-Control            =   "Cache-Control" ":" 1#cache-directive
   cache-directive          =   cache-request-directive
                            |   cache-response-directive
   cache-request-directive  =   "no-cache"
                            |   "max-stale"
                            |   "min-fresh"
                            |   "only-if-cached"
                            |   cache-extension
   cache-response-directive =   "public"
                            |   "private"
                            |   "no-cache"
                            |   "no-transform"
                            |   "must-revalidate"
ToP   noToC   RFC2326 - Page 48
                            |   "proxy-revalidate"
                            |   "max-age" "=" delta-seconds
                            |   cache-extension
   cache-extension          =   token [ "=" ( token | quoted-string ) ]

   no-cache:
          Indicates that the media stream MUST NOT be cached anywhere.
          This allows an origin server to prevent caching even by caches
          that have been configured to return stale responses to client
          requests.

   public:
          Indicates that the media stream is cacheable by any cache.

   private:
          Indicates that the media stream is intended for a single user
          and MUST NOT be cached by a shared cache. A private (non-
          shared) cache may cache the media stream.

   no-transform:
          An intermediate cache (proxy) may find it useful to convert
          the media type of a certain stream. A proxy might, for
          example, convert between video formats to save cache space or
          to reduce the amount of traffic on a slow link. Serious
          operational problems may occur, however, when these
          transformations have been applied to streams intended for
          certain kinds of applications. For example, applications for
          medical imaging, scientific data analysis and those using
          end-to-end authentication all depend on receiving a stream
          that is bit-for-bit identical to the original entity-body.
          Therefore, if a response includes the no-transform directive,
          an intermediate cache or proxy MUST NOT change the encoding of
          the stream. Unlike HTTP, RTSP does not provide for partial
          transformation at this point, e.g., allowing translation into
          a different language.

   only-if-cached:
          In some cases, such as times of extremely poor network
          connectivity, a client may want a cache to return only those
          media streams that it currently has stored, and not to receive
          these from the origin server. To do this, the client may
          include the only-if-cached directive in a request. If it
          receives this directive, a cache SHOULD either respond using a
          cached media stream that is consistent with the other
          constraints of the request, or respond with a 504 (Gateway
          Timeout) status. However, if a group of caches is being
          operated as a unified system with good internal connectivity,
          such a request MAY be forwarded within that group of caches.
ToP   noToC   RFC2326 - Page 49
   max-stale:
          Indicates that the client is willing to accept a media stream
          that has exceeded its expiration time. If max-stale is
          assigned a value, then the client is willing to accept a
          response that has exceeded its expiration time by no more than
          the specified number of seconds. If no value is assigned to
          max-stale, then the client is willing to accept a stale
          response of any age.

   min-fresh:
          Indicates that the client is willing to accept a media stream
          whose freshness lifetime is no less than its current age plus
          the specified time in seconds. That is, the client wants a
          response that will still be fresh for at least the specified
          number of seconds.

   must-revalidate:
          When the must-revalidate directive is present in a SETUP
          response received by a cache, that cache MUST NOT use the
          entry after it becomes stale to respond to a subsequent
          request without first revalidating it with the origin server.
          That is, the cache must do an end-to-end revalidation every
          time, if, based solely on the origin server's Expires, the
          cached response is stale.)

12.9 Conference

   This request header field establishes a logical connection between a
   pre-established conference and an RTSP stream. The conference-id must
   not be changed for the same RTSP session.

   Conference = "Conference" ":" conference-id Example:
     Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

   A response code of 452 (452 Conference Not Found) is returned if the
   conference-id is not valid.

12.10 Connection

   See [H14.10]

12.11 Content-Base

   See [H14.11]

12.12 Content-Encoding

   See [H14.12]
ToP   noToC   RFC2326 - Page 50
12.13 Content-Language

   See [H14.13]

12.14 Content-Length

   This field contains the length of the content of the method (i.e.
   after the double CRLF following the last header). Unlike HTTP, it
   MUST be included in all messages that carry content beyond the header
   portion of the message. If it is missing, a default value of zero is
   assumed. It is interpreted according to [H14.14].

12.15 Content-Location

   See [H14.15]

12.16 Content-Type

   See [H14.18]. Note that the content types suitable for RTSP are
   likely to be restricted in practice to presentation descriptions and
   parameter-value types.

12.17 CSeq

   The CSeq field specifies the sequence number for an RTSP request-
   response pair. This field MUST be present in all requests and
   responses. For every RTSP request containing the given sequence
   number, there will be a corresponding response having the same
   number.  Any retransmitted request must contain the same sequence
   number as the original (i.e. the sequence number is not incremented
   for retransmissions of the same request).

12.18 Date

   See [H14.19].

12.19 Expires

   The Expires entity-header field gives a date and time after which the
   description or media-stream should be considered stale. The
   interpretation depends on the method:

   DESCRIBE response:
          The Expires header indicates a date and time after which the
          description should be considered stale.
ToP   noToC   RFC2326 - Page 51
   A stale cache entry may not normally be returned by a cache (either a
   proxy cache or an user agent cache) unless it is first validated with
   the origin server (or with an intermediate cache that has a fresh
   copy of the entity). See section 13 for further discussion of the
   expiration model.

   The presence of an Expires field does not imply that the original
   resource will change or cease to exist at, before, or after that
   time.

   The format is an absolute date and time as defined by HTTP-date in
   [H3.3]; it MUST be in RFC1123-date format:

   Expires = "Expires" ":" HTTP-date

   An example of its use is

     Expires: Thu, 01 Dec 1994 16:00:00 GMT

   RTSP/1.0 clients and caches MUST treat other invalid date formats,
   especially including the value "0", as having occurred in the past
   (i.e., "already expired").

   To mark a response as "already expired," an origin server should use
   an Expires date that is equal to the Date header value. To mark a
   response as "never expires," an origin server should use an Expires
   date approximately one year from the time the response is sent.
   RTSP/1.0 servers should not send Expires dates more than one year in
   the future.

   The presence of an Expires header field with a date value of some
   time in the future on a media stream that otherwise would by default
   be non-cacheable indicates that the media stream is cacheable, unless
   indicated otherwise by a Cache-Control header field (Section 12.8).

12.20 From

   See [H14.22].

12.21 Host

   This HTTP request header field is not needed for RTSP. It should be
   silently ignored if sent.

12.22 If-Match

   See [H14.25].
ToP   noToC   RFC2326 - Page 52
   This field is especially useful for ensuring the integrity of the
   presentation description, in both the case where it is fetched via
   means external to RTSP (such as HTTP), or in the case where the
   server implementation is guaranteeing the integrity of the
   description between the time of the DESCRIBE message and the SETUP
   message.

   The identifier is an opaque identifier, and thus is not specific to
   any particular session description language.

12.23 If-Modified-Since

   The If-Modified-Since request-header field is used with the DESCRIBE
   and SETUP methods to make them conditional. If the requested variant
   has not been modified since the time specified in this field, a
   description will not be returned from the server (DESCRIBE) or a
   stream will not be set up (SETUP). Instead, a 304 (not modified)
   response will be returned without any message-body.

   If-Modified-Since = "If-Modified-Since" ":" HTTP-date

   An example of the field is:

     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

12.24 Last-Modified

   The Last-Modified entity-header field indicates the date and time at
   which the origin server believes the presentation description or
   media stream was last modified. See [H14.29]. For the methods
   DESCRIBE or ANNOUNCE, the header field indicates the last
   modification date and time of the description, for SETUP that of the
   media stream.

12.25 Location

   See [H14.30].

12.26 Proxy-Authenticate

   See [H14.33].

12.27 Proxy-Require

   The Proxy-Require header is used to indicate proxy-sensitive features
   that MUST be supported by the proxy. Any Proxy-Require header
   features that are not supported by the proxy MUST be negatively
   acknowledged by the proxy to the client if not supported. Servers
ToP   noToC   RFC2326 - Page 53
   should treat this field identically to the Require field.

   See Section 12.32 for more details on the mechanics of this message
   and a usage example.

12.28 Public

   See [H14.35].

12.29 Range

   This request and response header field specifies a range of time.
   The range can be specified in a number of units. This specification
   defines the smpte (Section 3.5), npt (Section 3.6), and clock
   (Section 3.7) range units. Within RTSP, byte ranges [H14.36.1] are
   not meaningful and MUST NOT be used. The header may also contain a
   time parameter in UTC, specifying the time at which the operation is
   to be made effective. Servers supporting the Range header MUST
   understand the NPT range format and SHOULD understand the SMPTE range
   format. The Range response header indicates what range of time is
   actually being played or recorded. If the Range header is given in a
   time format that is not understood, the recipient should return "501
   Not Implemented".

   Ranges are half-open intervals, including the lower point, but
   excluding the upper point. In other words, a range of a-b starts
   exactly at time a, but stops just before b. Only the start time of a
   media unit such as a video or audio frame is relevant. As an example,
   assume that video frames are generated every 40 ms. A range of 10.0-
   10.1 would include a video frame starting at 10.0 or later time and
   would include a video frame starting at 10.08, even though it lasted
   beyond the interval. A range of 10.0-10.08, on the other hand, would
   exclude the frame at 10.08.

   Range            = "Range" ":" 1\#ranges-specifier
                          [ ";" "time" "=" utc-time ]
   ranges-specifier = npt-range | utc-range | smpte-range

   Example:
     Range: clock=19960213T143205Z-;time=19970123T143720Z

     The notation is similar to that used for the HTTP/1.1 [2] byte-
     range header. It allows clients to select an excerpt from the media
     object, and to play from a given point to the end as well as from
     the current location to a given point. The start of playback can be
     scheduled for any time in the future, although a server may refuse
     to keep server resources for extended idle periods.
ToP   noToC   RFC2326 - Page 54
12.30 Referer

   See [H14.37]. The URL refers to that of the presentation description,
   typically retrieved via HTTP.

12.31 Retry-After

   See [H14.38].

12.32 Require

   The Require header is used by clients to query the server about
   options that it may or may not support. The server MUST respond to
   this header by using the Unsupported header to negatively acknowledge
   those options which are NOT supported.

     This is to make sure that the client-server interaction will
     proceed without delay when all options are understood by both
     sides, and only slow down if options are not understood (as in the
     case above). For a well-matched client-server pair, the interaction
     proceeds quickly, saving a round-trip often required by negotiation
     mechanisms. In addition, it also removes state ambiguity when the
     client requires features that the server does not understand.

   Require =   "Require" ":"  1#option-tag

   Example:
     C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 302
             Require: funky-feature
             Funky-Parameter: funkystuff

     S->C:   RTSP/1.0 551 Option not supported
             CSeq: 302
             Unsupported: funky-feature

     C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
             CSeq: 303

     S->C:   RTSP/1.0 200 OK
             CSeq: 303

   In this example, "funky-feature" is the feature tag which indicates
   to the client that the fictional Funky-Parameter field is required.
   The relationship between "funky-feature" and Funky-Parameter is not
   communicated via the RTSP exchange, since that relationship is an
   immutable property of "funky-feature" and thus should not be
   transmitted with every exchange.
ToP   noToC   RFC2326 - Page 55
   Proxies and other intermediary devices SHOULD ignore features that
   are not understood in this field. If a particular extension requires
   that intermediate devices support it, the extension should be tagged
   in the Proxy-Require field instead (see Section 12.27).

12.33 RTP-Info

   This field is used to set RTP-specific parameters in the PLAY
   response.

   url:
          Indicates the stream URL which for which the following RTP
          parameters correspond.

   seq:
          Indicates the sequence number of the first packet of the
          stream. This allows clients to gracefully deal with packets
          when seeking. The client uses this value to differentiate
          packets that originated before the seek from packets that
          originated after the seek.

   rtptime:
          Indicates the RTP timestamp corresponding to the time value in
          the Range response header. (Note: For aggregate control, a
          particular stream may not actually generate a packet for the
          Range time value returned or implied. Thus, there is no
          guarantee that the packet with the sequence number indicated
          by seq actually has the timestamp indicated by rtptime.) The
          client uses this value to calculate the mapping of RTP time to
          NPT.

     A mapping from RTP timestamps to NTP timestamps (wall clock) is
     available via RTCP. However, this information is not sufficient to
     generate a mapping from RTP timestamps to NPT. Furthermore, in
     order to ensure that this information is available at the necessary
     time (immediately at startup or after a seek), and that it is
     delivered reliably, this mapping is placed in the RTSP control
     channel.

     In order to compensate for drift for long, uninterrupted
     presentations, RTSP clients should additionally map NPT to NTP,
     using initial RTCP sender reports to do the mapping, and later
     reports to check drift against the mapping.
ToP   noToC   RFC2326 - Page 56
   Syntax:

   RTP-Info        = "RTP-Info" ":" 1#stream-url 1*parameter
   stream-url      = "url" "=" url
   parameter       = ";" "seq" "=" 1*DIGIT
                   | ";" "rtptime" "=" 1*DIGIT

   Example:

     RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
               url=rtsp://foo.com/bar.avi/streamid=1;seq=30211

12.34 Scale

   A scale value of 1 indicates normal play or record at the normal
   forward viewing rate. If not 1, the value corresponds to the rate
   with respect to normal viewing rate. For example, a ratio of 2
   indicates twice the normal viewing rate ("fast forward") and a ratio
   of 0.5 indicates half the normal viewing rate. In other words, a
   ratio of 2 has normal play time increase at twice the wallclock rate.
   For every second of elapsed (wallclock) time, 2 seconds of content
   will be delivered. A negative value indicates reverse direction.

   Unless requested otherwise by the Speed parameter, the data rate
   SHOULD not be changed. Implementation of scale changes depends on the
   server and media type. For video, a server may, for example, deliver
   only key frames or selected key frames. For audio, it may time-scale
   the audio while preserving pitch or, less desirably, deliver
   fragments of audio.

   The server should try to approximate the viewing rate, but may
   restrict the range of scale values that it supports. The response
   MUST contain the actual scale value chosen by the server.

   If the request contains a Range parameter, the new scale value will
   take effect at that time.

   Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]

   Example of playing in reverse at 3.5 times normal rate:

     Scale: -3.5
ToP   noToC   RFC2326 - Page 57
12.35 Speed

   This request header fields parameter requests the server to deliver
   data to the client at a particular speed, contingent on the server's
   ability and desire to serve the media stream at the given speed.
   Implementation by the server is OPTIONAL. The default is the bit rate
   of the stream.

   The parameter value is expressed as a decimal ratio, e.g., a value of
   2.0 indicates that data is to be delivered twice as fast as normal. A
   speed of zero is invalid. If the request contains a Range parameter,
   the new speed value will take effect at that time.

   Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]

   Example:
     Speed: 2.5

   Use of this field changes the bandwidth used for data delivery. It is
   meant for use in specific circumstances where preview of the
   presentation at a higher or lower rate is necessary. Implementors
   should keep in mind that bandwidth for the session may be negotiated
   beforehand (by means other than RTSP), and therefore re-negotiation
   may be necessary. When data is delivered over UDP, it is highly
   recommended that means such as RTCP be used to track packet loss
   rates.

12.36 Server

   See [H14.39]

12.37 Session

   This request and response header field identifies an RTSP session
   started by the media server in a SETUP response and concluded by
   TEARDOWN on the presentation URL. The session identifier is chosen by
   the media server (see Section 3.4). Once a client receives a Session
   identifier, it MUST return it for any request related to that
   session.  A server does not have to set up a session identifier if it
   has other means of identifying a session, such as dynamically
   generated URLs.

 Session  = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]

   The timeout parameter is only allowed in a response header. The
   server uses it to indicate to the client how long the server is
   prepared to wait between RTSP commands before closing the session due
   to lack of activity (see Section A). The timeout is measured in
ToP   noToC   RFC2326 - Page 58
   seconds, with a default of 60 seconds (1 minute).

   Note that a session identifier identifies a RTSP session across
   transport sessions or connections. Control messages for more than one
   RTSP URL may be sent within a single RTSP session. Hence, it is
   possible that clients use the same session for controlling many
   streams constituting a presentation, as long as all the streams come
   from the same server. (See example in Section 14). However, multiple
   "user" sessions for the same URL from the same client MUST use
   different session identifiers.

     The session identifier is needed to distinguish several delivery
     requests for the same URL coming from the same client.

   The response 454 (Session Not Found) is returned if the session
   identifier is invalid.

12.38 Timestamp

   The timestamp general header describes when the client sent the
   request to the server. The value of the timestamp is of significance
   only to the client and may use any timescale. The server MUST echo
   the exact same value and MAY, if it has accurate information about
   this, add a floating point number indicating the number of seconds
   that has elapsed since it has received the request. The timestamp is
   used by the client to compute the round-trip time to the server so
   that it can adjust the timeout value for retransmissions.

   Timestamp  = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
   delay      =  *(DIGIT) [ "." *(DIGIT) ]

12.39 Transport

   This request header indicates which transport protocol is to be used
   and configures its parameters such as destination address,
   compression, multicast time-to-live and destination port for a single
   stream. It sets those values not already determined by a presentation
   description.

   Transports are comma separated, listed in order of preference.
   Parameters may be added to each transport, separated by a semicolon.

   The Transport header MAY also be used to change certain transport
   parameters. A server MAY refuse to change parameters of an existing
   stream.

   The server MAY return a Transport response header in the response to
   indicate the values actually chosen.
ToP   noToC   RFC2326 - Page 59
   A Transport request header field may contain a list of transport
   options acceptable to the client. In that case, the server MUST
   return a single option which was actually chosen.

   The syntax for the transport specifier is

       transport/profile/lower-transport.

   The default value for the "lower-transport" parameters is specific to
   the profile. For RTP/AVP, the default is UDP.

   Below are the configuration parameters associated with transport:

   General parameters:

   unicast | multicast:
          mutually exclusive indication of whether unicast or multicast
          delivery will be attempted. Default value is multicast.
          Clients that are capable of handling both unicast and
          multicast transmission MUST indicate such capability by
          including two full transport-specs with separate parameters
          for each.

   destination:
          The address to which a stream will be sent. The client may
          specify the multicast address with the destination parameter.
          To avoid becoming the unwitting perpetrator of a remote-
          controlled denial-of-service attack, a server SHOULD
          authenticate the client and SHOULD log such attempts before
          allowing the client to direct a media stream to an address not
          chosen by the server. This is particularly important if RTSP
          commands are issued via UDP, but implementations cannot rely
          on TCP as reliable means of client identification by itself. A
          server SHOULD not allow a client to direct media streams to an
          address that differs from the address commands are coming
          from.

   source:
          If the source address for the stream is different than can be
          derived from the RTSP endpoint address (the server in playback
          or the client in recording), the source MAY be specified.

     This information may also be available through SDP. However, since
     this is more a feature of transport than media initialization, the
     authoritative source for this information should be in the SETUP
     response.
ToP   noToC   RFC2326 - Page 60
   layers:
          The number of multicast layers to be used for this media
          stream. The layers are sent to consecutive addresses starting
          at the destination address.

   mode:
          The mode parameter indicates the methods to be supported for
          this session. Valid values are PLAY and RECORD. If not
          provided, the default is PLAY.

   append:
          If the mode parameter includes RECORD, the append parameter
          indicates that the media data should append to the existing
          resource rather than overwrite it. If appending is requested
          and the server does not support this, it MUST refuse the
          request rather than overwrite the resource identified by the
          URI. The append parameter is ignored if the mode parameter
          does not contain RECORD.

   interleaved:
          The interleaved parameter implies mixing the media stream with
          the control stream in whatever protocol is being used by the
          control stream, using the mechanism defined in Section 10.12.
          The argument provides the channel number to be used in the $
          statement. This parameter may be specified as a range, e.g.,
          interleaved=4-5 in cases where the transport choice for the
          media stream requires it.

     This allows RTP/RTCP to be handled similarly to the way that it is
     done with UDP, i.e., one channel for RTP and the other for RTCP.

   Multicast specific:

   ttl:
          multicast time-to-live

   RTP Specific:

   port:
          This parameter provides the RTP/RTCP port pair for a multicast
          session. It is specified as a range, e.g., port=3456-3457.

   client_port:
          This parameter provides the unicast RTP/RTCP port pair on
          which the client has chosen to receive media data and control
          information.  It is specified as a range, e.g.,
          client_port=3456-3457.
ToP   noToC   RFC2326 - Page 61
   server_port:
          This parameter provides the unicast RTP/RTCP port pair on
          which the server has chosen to receive media data and control
          information.  It is specified as a range, e.g.,
          server_port=3456-3457.

   ssrc:
          The ssrc parameter indicates the RTP SSRC [24, Sec. 3] value
          that should be (request) or will be (response) used by the
          media server. This parameter is only valid for unicast
          transmission. It identifies the synchronization source to be
          associated with the media stream.

   Transport           =    "Transport" ":"
                            1\#transport-spec
   transport-spec      =    transport-protocol/profile[/lower-transport]
                            *parameter
   transport-protocol  =    "RTP"
   profile             =    "AVP"
   lower-transport     =    "TCP" | "UDP"
   parameter           =    ( "unicast" | "multicast" )
                       |    ";" "destination" [ "=" address ]
                       |    ";" "interleaved" "=" channel [ "-" channel ]
                       |    ";" "append"
                       |    ";" "ttl" "=" ttl
                       |    ";" "layers" "=" 1*DIGIT
                       |    ";" "port" "=" port [ "-" port ]
                       |    ";" "client_port" "=" port [ "-" port ]
                       |    ";" "server_port" "=" port [ "-" port ]
                       |    ";" "ssrc" "=" ssrc
                       |    ";" "mode" = <"> 1\#mode <">
   ttl                 =    1*3(DIGIT)
   port                =    1*5(DIGIT)
   ssrc                =    8*8(HEX)
   channel             =    1*3(DIGIT)
   address             =    host
   mode                =    <"> *Method <"> | Method


   Example:
     Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
                RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

     The Transport header is restricted to describing a single RTP
     stream. (RTSP can also control multiple streams as a single
     entity.) Making it part of RTSP rather than relying on a multitude
     of session description formats greatly simplifies designs of
     firewalls.
ToP   noToC   RFC2326 - Page 62
12.40 Unsupported

   The Unsupported response header lists the features not supported by
   the server. In the case where the feature was specified via the
   Proxy-Require field (Section 12.32), if there is a proxy on the path
   between the client and the server, the proxy MUST insert a message
   reply with an error message "551 Option Not Supported".

   See Section 12.32 for a usage example.

12.41 User-Agent

   See [H14.42]

12.42 Vary

   See [H14.43]

12.43 Via

   See [H14.44].

12.44 WWW-Authentica

   See [H14.46].

13 Caching

   In HTTP, response-request pairs are cached. RTSP differs
   significantly in that respect. Responses are not cacheable, with the
   exception of the presentation description returned by DESCRIBE or
   included with ANNOUNCE. (Since the responses for anything but
   DESCRIBE and GET_PARAMETER do not return any data, caching is not
   really an issue for these requests.) However, it is desirable for the
   continuous media data, typically delivered out-of-band with respect
   to RTSP, to be cached, as well as the session description.

   On receiving a SETUP or PLAY request, a proxy ascertains whether it
   has an up-to-date copy of the continuous media content and its
   description. It can determine whether the copy is up-to-date by
   issuing a SETUP or DESCRIBE request, respectively, and comparing the
   Last-Modified header with that of the cached copy. If the copy is not
   up-to-date, it modifies the SETUP transport parameters as appropriate
   and forwards the request to the origin server. Subsequent control
   commands such as PLAY or PAUSE then pass the proxy unmodified. The
   proxy delivers the continuous media data to the client, while
   possibly making a local copy for later reuse. The exact behavior
   allowed to the cache is given by the cache-response directives
ToP   noToC   RFC2326 - Page 63
   described in Section 12.8. A cache MUST answer any DESCRIBE requests
   if it is currently serving the stream to the requestor, as it is
   possible that low-level details of the stream description may have
   changed on the origin-server.

   Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
   through" variety. Rather than retrieving the whole resource from the
   origin server, the cache simply copies the streaming data as it
   passes by on its way to the client. Thus, it does not introduce
   additional latency.

   To the client, an RTSP proxy cache appears like a regular media
   server, to the media origin server like a client. Just as an HTTP
   cache has to store the content type, content language, and so on for
   the objects it caches, a media cache has to store the presentation
   description. Typically, a cache eliminates all transport-references
   (that is, multicast information) from the presentation description,
   since these are independent of the data delivery from the cache to
   the client. Information on the encodings remains the same. If the
   cache is able to translate the cached media data, it would create a
   new presentation description with all the encoding possibilities it
   can offer.

14 Examples

   The following examples refer to stream description formats that are
   not standards, such as RTSL. The following examples are not to be
   used as a reference for those formats.

14.1 Media on Demand (Unicast)

   Client C requests a movie from media servers A ( audio.example.com)
   and V (video.example.com). The media description is stored on a web
   server W . The media description contains descriptions of the
   presentation and all its streams, including the codecs that are
   available, dynamic RTP payload types, the protocol stack, and content
   information such as language or copyright restrictions. It may also
   give an indication about the timeline of the movie.

   In this example, the client is only interested in the last part of
   the movie.

     C->W: GET /twister.sdp HTTP/1.1
           Host: www.example.com
           Accept: application/sdp

     W->C: HTTP/1.0 200 OK
           Content-Type: application/sdp
ToP   noToC   RFC2326 - Page 64
           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           m=audio 0 RTP/AVP 0
           a=control:rtsp://audio.example.com/twister/audio.en
           m=video 0 RTP/AVP 31
           a=control:rtsp://video.example.com/twister/video

     C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 1
           Transport: RTP/AVP/UDP;unicast;client_port=3056-3057

     A->C: RTSP/1.0 200 OK
           CSeq: 1
           Session: 12345678
           Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
                      server_port=5000-5001

     C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 1
           Transport: RTP/AVP/UDP;unicast;client_port=3058-3059

     V->C: RTSP/1.0 200 OK
           CSeq: 1
           Session: 23456789
           Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
                      server_port=5002-5003

     C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 2
           Session: 23456789
           Range: smpte=0:10:00-

     V->C: RTSP/1.0 200 OK
           CSeq: 2
           Session: 23456789
           Range: smpte=0:10:00-0:20:00
           RTP-Info: url=rtsp://video.example.com/twister/video;
             seq=12312232;rtptime=78712811

     C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 2
           Session: 12345678
           Range: smpte=0:10:00-

     A->C: RTSP/1.0 200 OK
           CSeq: 2
           Session: 12345678
ToP   noToC   RFC2326 - Page 65
           Range: smpte=0:10:00-0:20:00
           RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
             seq=876655;rtptime=1032181

     C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
           CSeq: 3
           Session: 12345678

     A->C: RTSP/1.0 200 OK
           CSeq: 3

     C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
           CSeq: 3
           Session: 23456789

     V->C: RTSP/1.0 200 OK
           CSeq: 3

   Even though the audio and video track are on two different servers,
   and may start at slightly different times and may drift with respect
   to each other, the client can synchronize the two using standard RTP
   methods, in particular the time scale contained in the RTCP sender
   reports.

14.2 Streaming of a Container file

   For purposes of this example, a container file is a storage entity in
   which multiple continuous media types pertaining to the same end-user
   presentation are present. In effect, the container file represents an
   RTSP presentation, with each of its components being RTSP streams.
   Container files are a widely used means to store such presentations.
   While the components are transported as independent streams, it is
   desirable to maintain a common context for those streams at the
   server end.

     This enables the server to keep a single storage handle open
     easily. It also allows treating all the streams equally in case of
     any prioritization of streams by the server.

   It is also possible that the presentation author may wish to prevent
   selective retrieval of the streams by the client in order to preserve
   the artistic effect of the combined media presentation. Similarly, in
   such a tightly bound presentation, it is desirable to be able to
   control all the streams via a single control message using an
   aggregate URL.

   The following is an example of using a single RTSP session to control
   multiple streams. It also illustrates the use of aggregate URLs.
ToP   noToC   RFC2326 - Page 66
   Client C requests a presentation from media server M . The movie is
   stored in a container file. The client has obtained an RTSP URL to
   the container file.

     C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 164

           v=0
           o=- 2890844256 2890842807 IN IP4 172.16.2.93
           s=RTSP Session
           i=An Example of RTSP Session Usage
           a=control:rtsp://foo/twister
           t=0 0
           m=audio 0 RTP/AVP 0
           a=control:rtsp://foo/twister/audio
           m=video 0 RTP/AVP 26
           a=control:rtsp://foo/twister/video

     C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001

     M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;unicast;client_port=8000-8001;
                      server_port=9000-9001
           Session: 12345678

     C->M: SETUP rtsp://foo/twister/video RTSP/1.0
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003
           Session: 12345678

     M->C: RTSP/1.0 200 OK
           CSeq: 3
           Transport: RTP/AVP;unicast;client_port=8002-8003;
                      server_port=9004-9005
           Session: 12345678

     C->M: PLAY rtsp://foo/twister RTSP/1.0
           CSeq: 4
           Range: npt=0-
           Session: 12345678
ToP   noToC   RFC2326 - Page 67
     M->C: RTSP/1.0 200 OK
           CSeq: 4
           Session: 12345678
           RTP-Info: url=rtsp://foo/twister/video;
             seq=9810092;rtptime=3450012

     C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
           CSeq: 5
           Session: 12345678

     M->C: RTSP/1.0 460 Only aggregate operation allowed
           CSeq: 5

     C->M: PAUSE rtsp://foo/twister RTSP/1.0
           CSeq: 6
           Session: 12345678

     M->C: RTSP/1.0 200 OK
           CSeq: 6
           Session: 12345678

     C->M: SETUP rtsp://foo/twister RTSP/1.0
           CSeq: 7
           Transport: RTP/AVP;unicast;client_port=10000

     M->C: RTSP/1.0 459 Aggregate operation not allowed
           CSeq: 7


   In the first instance of failure, the client tries to pause one
   stream (in this case video) of the presentation. This is disallowed
   for that presentation by the server. In the second instance, the
   aggregate URL may not be used for SETUP and one control message is
   required per stream to set up transport parameters.

     This keeps the syntax of the Transport header simple and allows
     easy parsing of transport information by firewalls.

14.3 Single Stream Container Files

   Some RTSP servers may treat all files as though they are "container
   files", yet other servers may not support such a concept. Because of
   this, clients SHOULD use the rules set forth in the session
   description for request URLs, rather than assuming that a consistent
   URL may always be used throughout. Here's an example of how a multi-
   stream server might expect a single-stream file to be served:

          Accept: application/x-rtsp-mh, application/sdp
ToP   noToC   RFC2326 - Page 68
          CSeq: 1

    S->C  RTSP/1.0 200 OK
          CSeq: 1
          Content-base: rtsp://foo.com/test.wav/
          Content-type: application/sdp
          Content-length: 48

          v=0
          o=- 872653257 872653257 IN IP4 172.16.2.187
          s=mu-law wave file
          i=audio test
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:streamid=0

    C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          Transport: RTP/AVP/UDP;unicast;
                     client_port=6970-6971;mode=play
          CSeq: 2

    S->C  RTSP/1.0 200 OK
          Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
                     server_port=6970-6971;mode=play
          CSeq: 2
          Session: 2034820394

    C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
          CSeq: 3
          Session: 2034820394

    S->C  RTSP/1.0 200 OK
          CSeq: 3
          Session: 2034820394
          RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
            seq=981888;rtptime=3781123

   Note the different URL in the SETUP command, and then the switch back
   to the aggregate URL in the PLAY command. This makes complete sense
   when there are multiple streams with aggregate control, but is less
   than intuitive in the special case where the number of streams is
   one.

   In this special case, it is recommended that servers be forgiving of
   implementations that send:

    C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          CSeq: 3
ToP   noToC   RFC2326 - Page 69
   In the worst case, servers should send back:

    S->C  RTSP/1.0 460 Only aggregate operation allowed
          CSeq: 3

   One would also hope that server implementations are also forgiving of
   the following:

    C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 2

   Since there is only a single stream in this file, it's not ambiguous
   what this means.

14.4 Live Media Presentation Using Multicast

   The media server M chooses the multicast address and port. Here, we
   assume that the web server only contains a pointer to the full
   description, while the media server M maintains the full description.

     C->W: GET /concert.sdp HTTP/1.1
           Host: www.example.com

     W->C: HTTP/1.1 200 OK
           Content-Type: application/x-rtsl

           <session>
             <track src="rtsp://live.example.com/concert/audio">
           </session>

     C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 44

           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           m=audio 3456 RTP/AVP 0
           a=control:rtsp://live.example.com/concert/audio
           c=IN IP4 224.2.0.1/16

     C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 2
ToP   noToC   RFC2326 - Page 70
           Transport: RTP/AVP;multicast

     M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=224.2.0.1;
                      port=3456-3457;ttl=16
           Session: 0456804596

     C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
           CSeq: 3
           Session: 0456804596

     M->C: RTSP/1.0 200 OK
           CSeq: 3
           Session: 0456804596

14.5 Playing media into an existing session

   A conference participant C wants to have the media server M play back
   a demo tape into an existing conference. C indicates to the media
   server that the network addresses and encryption keys are already
   given by the conference, so they should not be chosen by the server.
   The example omits the simple ACK responses.

     C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 1
           Accept: application/sdp

     M->C: RTSP/1.0 200 1 OK
           Content-type: application/sdp
           Content-Length: 44

           v=0
           o=- 2890844526 2890842807 IN IP4 192.16.24.202
           s=RTSP Session
           i=See above
           t=0 0
           m=audio 0 RTP/AVP 0

     C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=225.219.201.15;
                      port=7000-7001;ttl=127
           Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

     M->C: RTSP/1.0 200 OK
           CSeq: 2
           Transport: RTP/AVP;multicast;destination=225.219.201.15;
ToP   noToC   RFC2326 - Page 71
                      port=7000-7001;ttl=127
           Session: 91389234234
           Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

     C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
           CSeq: 3
           Session: 91389234234

     M->C: RTSP/1.0 200 OK
           CSeq: 3

14.6 Recording

   The conference participant client C asks the media server M to record
   the audio and video portions of a meeting. The client uses the
   ANNOUNCE method to provide meta-information about the recorded
   session to the server.

     C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 90
           Content-Type: application/sdp
           Content-Length: 121

           v=0
           o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
           s=IETF Meeting, Munich - 1
           i=The thirty-ninth IETF meeting will be held in Munich, Germany
           u=http://www.ietf.org/meetings/Munich.html
           e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
           p=IETF Channel 1 +49-172-2312 451
           c=IN IP4 224.0.1.11/127
           t=3080271600 3080703600
           a=tool:sdr v2.4a6
           a=type:test
           m=audio 21010 RTP/AVP 5
           c=IN IP4 224.0.1.11/127
           a=ptime:40
           m=video 61010 RTP/AVP 31
           c=IN IP4 224.0.1.12/127

     M->C: RTSP/1.0 200 OK
           CSeq: 90

     C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
           CSeq: 91
           Transport: RTP/AVP;multicast;destination=224.0.1.11;
                      port=21010-21011;mode=record;ttl=127
ToP   noToC   RFC2326 - Page 72
     M->C: RTSP/1.0 200 OK
           CSeq: 91
           Session: 50887676
           Transport: RTP/AVP;multicast;destination=224.0.1.11;
                      port=21010-21011;mode=record;ttl=127

     C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
           CSeq: 92
           Session: 50887676
           Transport: RTP/AVP;multicast;destination=224.0.1.12;
                      port=61010-61011;mode=record;ttl=127

     M->C: RTSP/1.0 200 OK
           CSeq: 92
           Transport: RTP/AVP;multicast;destination=224.0.1.12;
                      port=61010-61011;mode=record;ttl=127

     C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
           CSeq: 93
           Session: 50887676
           Range: clock=19961110T1925-19961110T2015

     M->C: RTSP/1.0 200 OK
           CSeq: 93



(page 72 continued on part 4)

Next Section