Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 7826

 
 
 

Real-Time Streaming Protocol Version 2.0

Part 6 of 13, p. 106 to 134
Prev Section       Next Section

 


prevText      Top      ToC       Page 106 
16.  Caching

   In HTTP, request/response pairs are cached.  RTSP differs
   significantly in that respect.  Responses are not cacheable, with the
   exception of the presentation description returned by DESCRIBE.
   (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 allowed behavior of the cache is given by the cache-response
   directives described in Section 18.11.  A cache MUST answer any
   DESCRIBE requests if it is currently serving the stream to the
   requester, as it is possible that low-level details of the stream
   description may have changed on the origin server.

   Note that an RTSP 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, an RTSP proxy cache appears 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 (e.g., 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.

Top      Up      ToC       Page 107 
16.1.  Validation Model

   When a cache has a stale entry that it would like to use as a
   response to a client's request, it first has to check with the origin
   server (or possibly an intermediate cache with a fresh response) to
   see if its cached entry is still usable.  This is called "validating"
   the cache entry.  To avoid having to pay the overhead of
   retransmitting the full response if the cached entry is good, and at
   the same time avoiding having to pay the overhead of an extra round
   trip if the cached entry is invalid, RTSP supports the use of
   conditional methods.

   The key protocol features for supporting conditional methods are
   those concerned with "cache validators."  When an origin server
   generates a full response, it attaches some sort of validator to it,
   which is kept with the cache entry.  When a client (user agent or
   proxy cache) makes a conditional request for a resource for which it
   has a cache entry, it includes the associated validator in the
   request.

   The server then checks that validator against the current validator
   for the requested resource, and, if they match (see Section 16.1.3),
   it responds with a special status code (usually, 304 (Not Modified))
   and no message body.  Otherwise, it returns a full response
   (including message body).  Thus, avoiding transmitting the full
   response if the validator matches and avoiding an extra round trip if
   it does not match.

   In RTSP, a conditional request looks exactly the same as a normal
   request for the same resource, except that it carries a special
   header (which includes the validator) that implicitly turns the
   method (usually DESCRIBE or SETUP) into a conditional.

   The protocol includes both positive and negative senses of cache-
   validating conditions.  That is, it is possible to request that a
   method be performed either if and only if a validator matches or if
   and only if no validators match.

      Note: a response that lacks a validator may still be cached, and
      served from cache until it expires, unless this is explicitly
      prohibited by a cache directive (see Section 18.11).  However, a
      cache cannot perform a conditional retrieval if it does not have a
      validator for the resource, which means it will not be refreshable
      after it expires.

Top      Up      ToC       Page 108 
   Media streams that are being adapted based on the transport capacity
   between the server and the cache make caching more difficult.  A
   server needs to consider how it views the caching of media streams
   that it adapts and potentially instruct any caches not to cache such
   streams.

16.1.1.  Last-Modified Dates

   The Last-Modified header (Section 18.27) value is often used as a
   cache validator.  In simple terms, a cache entry is considered to be
   valid if the cache entry was created after the Last-Modified time.

16.1.2.  Message Body Tag Cache Validators

   The MTag response-header field-value, a message body tag, provides
   for an "opaque" cache validator.  This might allow more reliable
   validation in situations where it is inconvenient to store
   modification dates, where the one-second resolution of RTSP-date
   values is not sufficient, or where the origin server wishes to avoid
   certain paradoxes that might arise from the use of modification
   dates.

   Message body tags are described in Section 4.6

16.1.3.  Weak and Strong Validators

   Since both origin servers and caches will compare two validators to
   decide if they represent the same or different entities, one normally
   would expect that if the message body (i.e., the presentation
   description) or any associated message body headers changes in any
   way, then the associated validator would change as well.  If this is
   true, then this validator is a "strong validator".  The Message body
   (i.e., the presentation description) or any associated message body
   headers is named an entity for a better understanding.

   However, there might be cases when a server prefers to change the
   validator only on semantically significant changes and not when
   insignificant aspects of the entity change.  A validator that does
   not always change when the resource changes is a "weak validator".

   Message body tags are normally strong validators, but the protocol
   provides a mechanism to tag a message body tag as "weak".  One can
   think of a strong validator as one that changes whenever the bits of
   an entity changes, while a weak value changes whenever the meaning of
   an entity changes.  Alternatively, one can think of a strong
   validator as part of an identifier for a specific entity, while a
   weak validator is part of an identifier for a set of semantically
   equivalent entities.

Top      Up      ToC       Page 109 
      Note: One example of a strong validator is an integer that is
      incremented in stable storage every time an entity is changed.

      An entity's modification time, if represented with one-second
      resolution, could be a weak validator, since it is possible that
      the resource might be modified twice during a single second.

      Support for weak validators is optional.  However, weak validators
      allow for more efficient caching of equivalent objects.

   A "use" of a validator is either when a client generates a request
   and includes the validator in a validating header field or when a
   server compares two validators.

   Strong validators are usable in any context.  Weak validators are
   only usable in contexts that do not depend on exact equality of an
   entity.  For example, either kind is usable for a conditional
   DESCRIBE of a full entity.  However, only a strong validator is
   usable for a subrange retrieval, since otherwise the client might end
   up with an internally inconsistent entity.

   Clients MAY issue DESCRIBE requests with either weak or strong
   validators.  Clients MUST NOT use weak validators in other forms of
   requests.

   The only function that RTSP defines on validators is comparison.
   There are two validator comparison functions, depending on whether or
   not the comparison context allows the use of weak validators:

   o  The strong comparison function: in order to be considered equal,
      both validators MUST be identical in every way, and both MUST NOT
      be weak.

   o  The weak comparison function: in order to be considered equal,
      both validators MUST be identical in every way, but either or both
      of them MAY be tagged as "weak" without affecting the result.

   A message body tag is strong unless it is explicitly tagged as weak.

   A Last-Modified time, when used as a validator in a request, is
   implicitly weak unless it is possible to deduce that it is strong,
   using the following rules:

   o  The validator is being compared by an origin server to the actual
      current validator for the entity and,

Top      Up      ToC       Page 110 
   o  That origin server reliably knows that the associated entity did
      not change more than once during the second covered by the
      presented validator.

   OR

   o  The validator is about to be used by a client in an If-Modified-
      Since, because the client has a cache entry for the associated
      entity, and

   o  That cache entry includes a Date value, which gives the time when
      the origin server sent the original response, and

   o  The presented Last-Modified time is at least 60 seconds before the
      Date value.

   OR

   o  The validator is being compared by an intermediate cache to the
      validator stored in its cache entry for the entity, and

   o  That cache entry includes a Date value, which gives the time when
      the origin server sent the original response, and

   o  The presented Last-Modified time is at least 60 seconds before the
      Date value.

   This method relies on the fact that if two different responses were
   sent by the origin server during the same second, but both had the
   same Last-Modified time, then at least one of those responses would
   have a Date value equal to its Last-Modified time.  The arbitrary
   60-second limit guards against the possibility that the Date and
   Last-Modified values are generated from different clocks or at
   somewhat different times during the preparation of the response.  An
   implementation MAY use a value larger than 60 seconds, if it is
   believed that 60 seconds is too short.

   If a client wishes to perform a subrange retrieval on a value for
   which it has only a Last-Modified time and no opaque validator, it
   MAY do this only if the Last-Modified time is strong in the sense
   described here.

16.1.4.  Rules for When to Use Message Body Tags and Last-Modified Dates

   This document adopts a set of rules and recommendations for origin
   servers, clients, and caches regarding when various validator types
   ought to be used, and for what purposes.

Top      Up      ToC       Page 111 
   RTSP origin servers:

   o  SHOULD send a message body tag validator unless it is not feasible
      to generate one.

   o  MAY send a weak message body tag instead of a strong message body
      tag, if performance considerations support the use of weak message
      body tags, or if it is unfeasible to send a strong message body
      tag.

   o  SHOULD send a Last-Modified value if it is feasible to send one,
      unless the risk of a breakdown in semantic transparency that could
      result from using this date in an If-Modified-Since header would
      lead to serious problems.
   In other words, the preferred behavior for an RTSP origin server is
   to send both a strong message body tag and a Last-Modified value.

   In order to be legal, a strong message body tag MUST change whenever
   the associated entity value changes in any way.  A weak message body
   tag SHOULD change whenever the associated entity changes in a
   semantically significant way.

      Note: in order to provide semantically transparent caching, an
      origin server MUST avoid reusing a specific strong message body
      tag value for two different entities or reusing a specific weak
      message body tag value for two semantically different entities.
      Cache entries might persist for arbitrarily long periods,
      regardless of expiration times, so it might be inappropriate to
      expect that a cache will never again attempt to validate an entry
      using a validator that it obtained at some point in the past.

   RTSP clients:

   o  If a message body tag has been provided by the origin server, MUST
      use that message body tag in any cache-conditional request (using
      If-Match or If-None-Match).

   o  If only a Last-Modified value has been provided by the origin
      server, SHOULD use that value in non-subrange cache-conditional
      requests (using If-Modified-Since).

   o  If both a message body tag and a Last-Modified value have been
      provided by the origin server, SHOULD use both validators in
      cache-conditional requests.

   An RTSP origin server, upon receiving a conditional request that
   includes both a Last-Modified date (e.g., in an If-Modified-Since
   header) and one or more message body tags (e.g., in an If-Match,

Top      Up      ToC       Page 112 
   If-None-Match, or If-Range header field) as cache validators, MUST
   NOT return a response status of 304 (Not Modified) unless doing so is
   consistent with all of the conditional header fields in the request.

      Note: The general principle behind these rules is that RTSP
      servers and clients should transmit as much non-redundant
      information as is available in their responses and requests.  RTSP
      systems receiving this information will make the most conservative
      assumptions about the validators they receive.

16.1.5.  Non-validating Conditionals

   The principle behind message body tags is that only the service
   author knows the semantics of a resource well enough to select an
   appropriate cache validation mechanism, and the specification of any
   validator comparison function more complex than octet equality would
   open up a can of worms.  Thus, comparisons of any other headers are
   never used for purposes of validating a cache entry.

16.2.  Invalidation after Updates or Deletions

   The effect of certain methods performed on a resource at the origin
   server might cause one or more existing cache entries to become non-
   transparently invalid.  That is, although they might continue to be
   "fresh," they do not accurately reflect what the origin server would
   return for a new request on that resource.

   There is no way for RTSP to guarantee that all such cache entries are
   marked invalid.  For example, the request that caused the change at
   the origin server might not have gone through the proxy where a cache
   entry is stored.  However, several rules help reduce the likelihood
   of erroneous behavior.

   In this section, the phrase "invalidate an entity" means that the
   cache will either remove all instances of that entity from its
   storage or mark these as "invalid" and in need of a mandatory
   revalidation before they can be returned in response to a subsequent
   request.

   Some RTSP methods MUST cause a cache to invalidate an entity.  This
   is either the entity referred to by the Request-URI or by the
   Location or Content-Location headers (if present).  These methods
   are:

   o  DESCRIBE

   o  SETUP

Top      Up      ToC       Page 113 
   In order to prevent DoS attacks, an invalidation based on the URI in
   a Location or Content-Location header MUST only be performed if the
   host part is the same as in the Request-URI.

   A cache that passes through requests for methods it does not
   understand SHOULD invalidate any entities referred to by the Request-
   URI.

17.  Status Code Definitions

   Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are
   reused.  See Table 4 in Section 8.1 for a listing of which status
   codes may be returned by which requests.  All error messages, 4xx and
   5xx, MAY return a body containing further information about the
   error.

17.1.  Informational 1xx

17.1.1.  100 Continue

   The requesting agent SHOULD continue with its request.  This interim
   response is used to inform the requesting agent that the initial part
   of the request has been received and has not yet been rejected by the
   responding agent.  The requesting agent SHOULD continue by sending
   the remainder of the request or, if the request has already been
   completed, continue to wait for a final response (see Section 10.4).
   The responding agent MUST send a final response after the request has
   been completed.

17.2.  Success 2xx

   This class of status code indicates that the agent's request was
   successfully received, understood, and accepted.

17.2.1.  200 OK

   The request has succeeded.  The information returned with the
   response is dependent on the method used in the request.

17.3.  Redirection 3xx

   The notation "3xx" indicates response codes from 300 to 399 inclusive
   that are meant for redirection.  We use the notation "3rr" to
   indicate all 3xx codes used for redirection, i.e., excluding 304.
   The 304 response code appears here, rather than a 2xx response code,
   which would have been appropriate; 304 has also been used in RTSP 1.0
   [RFC2326].

Top      Up      ToC       Page 114 
   Within RTSP, redirection may be used for load-balancing or
   redirecting stream requests to a server topologically closer to the
   agent.  Mechanisms to determine topological proximity are beyond the
   scope of this specification.

   A 3rr code MAY be used to respond to any request.  The Location
   header MUST be included in any 3rr response.  It is RECOMMENDED that
   they are used if necessary before a session is established, i.e., in
   response to DESCRIBE or SETUP.  However, in cases where a server is
   not able to send a REDIRECT request to the agent, the server MAY need
   to resort to using 3rr responses to inform an agent with an
   established session about the need for redirecting the session.  If a
   3rr response is received for a request in relation to an established
   session, the agent SHOULD send a TEARDOWN request for the session and
   MAY reestablish the session using the resource indicated by the
   Location.

   If the Location header is used in a response, it MUST contain an
   absolute URI pointing out the media resource the agent is redirected
   to; the URI MUST NOT only contain the hostname.

   In the event that an unknown 3rr status code is received, the agent
   SHOULD behave as if a 302 response code had been received
   (Section 17.3.3).

17.3.1.  300

   The 300 response code is not used in RTSP 2.0.

17.3.2.  301 Moved Permanently

   The requested resource is moved permanently and resides now at the
   URI given by the Location header.  The user agent SHOULD redirect
   automatically to the given URI.  This response MUST NOT contain a
   message body.  The Location header MUST be included in the response.

17.3.3.  302 Found

   The requested resource resides temporarily at the URI given by the
   Location header.  This response is intended to be used for many types
   of temporary redirects, e.g., load balancing.  It is RECOMMENDED that
   the server set the reason phrase to something more meaningful than
   "Found" in these cases.  The Location header MUST be included in the
   response.  The user agent SHOULD redirect automatically to the given
   URI.  This response MUST NOT contain a message body.

Top      Up      ToC       Page 115 
   This example shows a client being redirected to a different server:

     C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: npt, smpte, clock
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 302 Try Other Server
           CSeq: 2
           Location: rtsp://s2.example.com:8001/fizzle/foo

17.3.4.  303 See Other

   This status code MUST NOT be used in RTSP 2.0.  However, it was
   allowed in RTSP 1.0 [RFC2326].

17.3.5.  304 Not Modified

   If the agent has performed a conditional DESCRIBE or SETUP (see
   Sections 18.25 and 18.26) and the requested resource has not been
   modified, the server SHOULD send a 304 response.  This response MUST
   NOT contain a message body.

   The response MUST include the following header fields:

   o  Date

   o  MTag or Content-Location, if the headers would have been sent in a
      200 response to the same request.

   o  Expires and Cache-Control if the field-value might differ from
      that sent in any previous response for the same variant.

   This response is independent for the DESCRIBE and SETUP requests.
   That is, a 304 response to DESCRIBE does NOT imply that the resource
   content is unchanged (only the session description) and a 304
   response to SETUP does NOT imply that the resource description is
   unchanged.  The MTag and If-Match header (Section 18.24) may be used
   to link the DESCRIBE and SETUP in this manner.

17.3.6.  305 Use Proxy

   The requested resource MUST be accessed through the proxy given by
   the Location header that MUST be included.  The Location header
   field-value gives the URI of the proxy.  The recipient is expected to
   repeat this single request via the proxy. 305 responses MUST only be
   generated by origin servers.

Top      Up      ToC       Page 116 
17.4.  Client Error 4xx

17.4.1.  400 Bad Request

   The request could not be understood by the agent due to malformed
   syntax.  The agent SHOULD NOT repeat the request without
   modifications.  If the request does not have a CSeq header, the agent
   MUST NOT include a CSeq in the response.

17.4.2.  401 Unauthorized

   The request requires user authentication using the HTTP
   authentication mechanism [RFC7235].  The usage of the error code is
   defined in [RFC7235] and any applicable HTTP authentication scheme,
   such as Digest [RFC7616].  The response is to include a WWW-
   Authenticate header (Section 18.58) field containing a challenge
   applicable to the requested resource.  The agent can repeat the
   request with a suitable Authorization header field.  If the request
   already included authorization credentials, then the 401 response
   indicates that authorization has been refused for those credentials.
   If the 401 response contains the same challenge as the prior
   response, and the user agent has already attempted authentication at
   least once, then the user SHOULD be presented the message body that
   was given in the response, since that message body might include
   relevant diagnostic information.

17.4.3.  402 Payment Required

   This code is reserved for future use.

17.4.4.  403 Forbidden

   The agent understood the request, but is refusing to fulfill it.
   Authorization will not help, and the request SHOULD NOT be repeated.
   If the agent wishes to make public why the request has not been
   fulfilled, it SHOULD describe the reason for the refusal in the
   message body.  If the agent does not wish to make this information
   available to the agent, the status code 404 (Not Found) can be used
   instead.

17.4.5.  404 Not Found

   The agent has not found anything matching the Request-URI.  No
   indication is given of whether the condition is temporary or
   permanent.  The 410 (Gone) status code SHOULD be used if the agent
   knows, through some internally configurable mechanism, that an old
   resource is permanently unavailable and has no forwarding address.

Top      Up      ToC       Page 117 
   This status code is commonly used when the agent does not wish to
   reveal exactly why the request has been refused, or when no other
   response is applicable.

17.4.6.  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.

17.4.7.  406 Not Acceptable

   The resource identified by the request is only capable of generating
   response message bodies that have content characteristics not
   acceptable according to the Accept headers sent in the request.

   The response SHOULD include a message body containing a list of
   available message body characteristics and location(s) from which the
   user or user agent can choose the one most appropriate.  The message
   body format is specified by the media type given in the Content-Type
   header field.  Depending upon the format and the capabilities of the
   user agent, selection of the most appropriate choice MAY be performed
   automatically.  However, this specification does not define any
   standard for such automatic selection.

   If the response could be unacceptable, a user agent SHOULD
   temporarily stop receipt of more data and query the user for a
   decision on further actions.

17.4.8.  407 Proxy Authentication Required

   This code is similar to 401 (Unauthorized) (Section 17.4.2), but it
   indicates that the client must first authenticate itself with the
   proxy.  The usage of this error code is defined in [RFC7235] and any
   applicable HTTP authentication scheme, such as Digest [RFC7616].  The
   proxy MUST return a Proxy-Authenticate header field (Section 18.34)
   containing a challenge applicable to the proxy for the requested
   resource.

17.4.9.  408 Request Timeout

   The agent did not produce a request within the time that the agent
   was prepared to wait.  The agent MAY repeat the request without
   modifications at any later time.

Top      Up      ToC       Page 118 
17.4.10.  410 Gone

   The requested resource is no longer available at the server and the
   forwarding address is not known.  This condition is expected to be
   considered permanent.  If the server does not know, or has no
   facility to determine, whether or not the condition is permanent, the
   status code 404 (Not Found) SHOULD be used instead.  This response is
   cacheable unless indicated otherwise.

   The 410 response is primarily intended to assist the task of
   repository maintenance by notifying the recipient that the resource
   is intentionally unavailable and that the server owners desire that
   remote links to that resource be removed.  Such an event is common
   for limited-time, promotional services and for resources belonging to
   individuals no longer working at the server's site.  It is not
   necessary to mark all permanently unavailable resources as "gone" or
   to keep the mark for any length of time -- that is left to the
   discretion of the owner of the server.

17.4.11.  412 Precondition Failed

   The precondition given in one or more of the 'if-' request-header
   fields evaluated to false when it was tested on the agent.  See these
   sections for the 'if-' headers: If-Match Section 18.24, If-Modified-
   Since Section 18.25, and If-None-Match Section 18.26.  This response
   code allows the agent to place preconditions on the current resource
   meta-information (header field data) and, thus, prevent the requested
   method from being applied to a resource other than the one intended.

17.4.12.  413 Request Message Body Too Large

   The agent is refusing to process a request because the request
   message body is larger than the agent is willing or able to process.
   The agent MAY close the connection to prevent the requesting agent
   from continuing the request.

   If the condition is temporary, the agent SHOULD include a Retry-After
   header field to indicate that it is temporary and after what time the
   requesting agent MAY try again.

17.4.13.  414 Request-URI Too Long

   The responding agent is refusing to service the request because the
   Request-URI is longer than the agent is willing to interpret.  This
   rare condition is only likely to occur when an agent has used a
   request with long query information, when the agent has descended
   into a URI "black hole" of redirection (e.g., a redirected URI prefix
   that points to a suffix of itself), or when the agent is under attack

Top      Up      ToC       Page 119 
   by an agent attempting to exploit security holes present in some
   agents using fixed-length buffers for reading or manipulating the
   Request-URI.

17.4.14.  415 Unsupported Media Type

   The server is refusing to service the request because the message
   body of the request is in a format not supported by the requested
   resource for the requested method.

17.4.15.  451 Parameter Not Understood

   The recipient of the request does not support one or more parameters
   contained in the request.  When returning this error message the
   agent SHOULD return a message body containing the offending
   parameter(s).

17.4.16.  452 Illegal Conference Identifier

   This status code MUST NOT be used in RTSP 2.0.  However, it was
   allowed in RTSP 1.0 [RFC2326].

17.4.17.  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.

17.4.18.  454 Session Not Found

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

17.4.19.  455 Method Not Valid in This State

   The agent cannot process this request in its current state.  The
   response MUST contain an Allow header to make error recovery
   possible.

17.4.20.  456 Header Field Not Valid for Resource

   The targeted agent could not act on a required request-header.  For
   example, if PLAY request contains the Range header field but the
   stream does not allow seeking.  This error message may also be used
   for specifying when the time format in Range is impossible for the
   resource.  In that case, the Accept-Ranges header MUST be returned to
   inform the agent of which formats are allowed.

Top      Up      ToC       Page 120 
17.4.21.  457 Invalid Range

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

17.4.22.  458 Parameter Is Read-Only

   The parameter to be set by SET_PARAMETER can be read but not
   modified.  When returning this error message, the sender SHOULD
   return a message body containing the offending parameter(s).

17.4.23.  459 Aggregate Operation Not Allowed

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

17.4.24.  460 Only Aggregate Operation Allowed

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

17.4.25.  461 Unsupported Transport

   The Transport field did not contain a supported transport
   specification.

17.4.26.  462 Destination Unreachable

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

17.4.27.  463 Destination Prohibited

   The data transmission channel was not established because the server
   prohibited access to the agent address.  This error is most likely
   the result of an agent attempt to redirect media traffic to another
   destination with a dest_addr parameter in the Transport header.

Top      Up      ToC       Page 121 
17.4.28.  464 Data Transport Not Ready Yet

   The data transmission channel to the media destination is not yet
   ready for carrying data.  However, the responding agent still expects
   that the data transmission channel will be established at some point
   in time.  Note, however, that this may result in a permanent failure
   like 462 (Destination Unreachable).

   An example of when this error may occur is in the case in which a
   client sends a PLAY request to a server prior to ensuring that the
   TCP connections negotiated for carrying media data were successfully
   established (in violation of this specification).  The server would
   use this error code to indicate that the requested action could not
   be performed due to the failure of completing the connection
   establishment.

17.4.29.  465 Notification Reason Unknown

   This indicates that the client has received a PLAY_NOTIFY
   (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to
   the client.

17.4.30.  466 Key Management Error

   This indicates that there has been an error in a Key Management
   function used in conjunction with a request.  For example, usage of
   Multimedia Internet KEYing (MIKEY) [RFC3830] according to
   Appendix C.1.4.1 may result in this error.

17.4.31.  470 Connection Authorization Required

   The secured connection attempt needs user or client authorization
   before proceeding.  The next hop's certificate is included in this
   response in the Accept-Credentials header.

17.4.32.  471 Connection Credentials Not Accepted

   When performing a secure connection over multiple connections, an
   intermediary has refused to connect to the next hop and carry out the
   request due to unacceptable credentials for the used policy.

17.4.33.  472 Failure to Establish Secure Connection

   A proxy fails to establish a secure connection to the next-hop RTSP
   agent.  This is primarily caused by a fatal failure at the TLS
   handshake, for example, due to the agent not accepting any cipher
   suites.

Top      Up      ToC       Page 122 
17.5.  Server Error 5xx

   Response status codes beginning with the digit "5" indicate cases in
   which the server is aware that it has erred or is incapable of
   performing the request.  The server SHOULD include a message body
   containing an explanation of the error situation and whether it is a
   temporary or permanent condition.  User agents SHOULD display any
   included message body to the user.  These response codes are
   applicable to any request method.

17.5.1.  500 Internal Server Error

   The agent encountered an unexpected condition that prevented it from
   fulfilling the request.

17.5.2.  501 Not Implemented

   The agent does not support the functionality required to fulfill the
   request.  This is the appropriate response when the agent does not
   recognize the request method and is not capable of supporting it for
   any resource.

17.5.3.  502 Bad Gateway

   The agent, while acting as a gateway or proxy, received an invalid
   response from the upstream agent it accessed in attempting to fulfill
   the request.

17.5.4.  503 Service Unavailable

   The server is currently unable to handle the request due to a
   temporary overloading or maintenance of the server.  The implication
   is that this is a temporary condition that will be alleviated after
   some delay.  If known, the length of the delay MAY be indicated in a
   Retry-After header.  If no Retry-After is given, the agent SHOULD
   handle the response as it would for a 500 response.  The agent MUST
   honor the length, if given, in the Retry-After header.

         Note: The existence of the 503 status code does not imply that
         a server must use it when becoming overloaded.  Some servers
         may wish to simply refuse the transport connection.

   The response scope is dependent on the request.  If the request was
   in relation to an existing RTSP session, the scope of the overload
   response is to this individual RTSP session.  If the request was not
   session specific or intended to form an RTSP session, it applies to
   the RTSP server identified by the hostname in the Request-URI.

Top      Up      ToC       Page 123 
17.5.5.  504 Gateway Timeout

   The agent, while acting as a proxy, did not receive a timely response
   from the upstream agent specified by the URI or some other auxiliary
   server (e.g., DNS) that it needed to access in attempting to complete
   the request.

17.5.6.  505 RTSP Version Not Supported

   The agent does not support, or refuses to support, the RTSP version
   that was used in the request message.  The agent is indicating that
   it is unable or unwilling to complete the request using the same
   major version as the agent other than with this error message.  The
   response SHOULD contain a message body describing why that version is
   not supported and what other protocols are supported by that agent.

17.5.7.  551 Option Not Supported

   A feature tag given in the Require or the Proxy-Require fields was
   not supported.  The Unsupported header MUST be returned stating the
   feature for which there is no support.

17.5.8.  553 Proxy Unavailable

   The proxy is currently unable to handle the request due to a
   temporary overloading or maintenance of the proxy.  The implication
   is that this is a temporary condition that will be alleviated after
   some delay.  If known, the length of the delay MAY be indicated in a
   Retry-After header.  If no Retry-After is given, the agent SHOULD
   handle the response as it would for a 500 response.  The agent MUST
   honor the length, if given in the Retry-After header.

         Note: The existence of the 553 status code does not imply that
         a proxy must use it when becoming overloaded.  Some proxies may
         wish to simply refuse the connection.

   The response scope is dependent on the Request.  If the request was
   in relation to an existing RTSP session, the scope of the overload
   response is to this individual RTSP session.  If the request was non-
   session specific or intended to form an RTSP session, it applies to
   all such requests to this proxy.

Top      Up      ToC       Page 124 
18.  Header Field Definitions

       +---------------+----------------+--------+---------+------+
       | method        | direction      | object | acronym | Body |
       +---------------+----------------+--------+---------+------+
       | DESCRIBE      | C -> S         | P,S    | DES     | r    |
       |               |                |        |         |      |
       | GET_PARAMETER | C -> S, S -> C | P,S    | GPR     | R,r  |
       |               |                |        |         |      |
       | OPTIONS       | C -> S, S -> C | P,S    | OPT     |      |
       |               |                |        |         |      |
       | PAUSE         | C -> S         | P,S    | PSE     |      |
       |               |                |        |         |      |
       | PLAY          | C -> S         | P,S    | PLY     |      |
       |               |                |        |         |      |
       | PLAY_NOTIFY   | S -> C         | P,S    | PNY     | R    |
       |               |                |        |         |      |
       | REDIRECT      | S -> C         | P,S    | RDR     |      |
       |               |                |        |         |      |
       | SETUP         | C -> S         | S      | STP     |      |
       |               |                |        |         |      |
       | SET_PARAMETER | C -> S, S -> C | P,S    | SPR     | R,r  |
       |               |                |        |         |      |
       | TEARDOWN      | C -> S         | P,S    | TRD     |      |
       |               |                |        |         |      |
       |               | S -> C         | P      | TRD     |      |
       +---------------+----------------+--------+---------+------+

   This table is an overview of RTSP methods, their direction, and what
   objects (P: presentation, S: stream) they operate on.  "Body" denotes
     if a method is allowed to carry body and in which direction; R =
    request, r=response.  Note: All error messages for statuses 4xx and
                     5xx are allowed to carry a body.

                     Table 8: Overview of RTSP Methods

   The general syntax for header fields is covered in Section 5.2.  This
   section lists the full set of header fields along with notes on
   meaning and usage.  The syntax definitions for header fields are
   present in Section 20.2.3.  Examples of each header field are given.

   Information about header fields in relation to methods and proxy
   processing is summarized in Figures 2, 3, 4, and 5.

Top      Up      ToC       Page 125 
   The "where" column describes the request and response types in which
   the header field can be used.  Values in this column are:

   R:                header field may only appear in requests;

   r:                header field may only appear in responses;

   2xx, 4xx, etc.:   numerical value or range indicates response codes
                     with which the header field can be used;

   c:                header field is copied from the request to the
                     response.

   G:                header field is a general-header and may be present
                     in both requests and responses.

   Note: General headers do not always use the "G" value in the "where"
   column.  This is due to differences when the header may be applied in
   requests compared to responses.  When such differences exist, they
   are expressed using two different rows: one with "where" being "R"
   and one with it being "r".

   The "proxy" column describes the operations a proxy may perform on a
   header field.  An empty proxy column indicates that the proxy MUST
   NOT make any changes to that header, all allowed operations are
   explicitly stated:

   a:    A proxy can add or concatenate the header field if not present.

   m:    A proxy can modify an existing header field value.

   d:    A proxy can delete a header field-value.

   r:    A proxy needs to be able to read the header field; thus, this
         header field cannot be encrypted.

   The rest of the columns relate to the presence of a header field in a
   method.  The method names when abbreviated, are according to Table 8:

   c:    Conditional; requirements on the header field depend on the
         context of the message.

   m:    The header field is mandatory.

   m*:   The header field SHOULD be sent, but agents need to be prepared
         to receive messages without that header field.

   o:    The header field is optional.

Top      Up      ToC       Page 126 
   *:    The header field MUST be present if the message body is not
         empty.  See Sections 18.17, 18.19 and 5.3 for details.

   -:    The header field is not applicable.

   "Optional" means that an agent MAY include the header field in a
   request or response.  The agent behavior when receiving such headers
   varies; for some, it may ignore the header field.  In other cases, it
   is a request to process the header.  This is regulated by the method
   and header descriptions.  Examples of headers that require processing
   are the Require and Proxy-Require header fields discussed in Sections
   18.43 and 18.37.  A "mandatory" header field MUST be present in a
   request, and it MUST be understood by the agent receiving the
   request.  A mandatory response-header field MUST be present in the
   response, and the header field MUST be understood by the processing
   the response.  "Not applicable" means that the header field MUST NOT
   be present in a request.  If one is placed in a request by mistake,
   it MUST be ignored by the agent receiving the request.  Similarly, a
   header field labeled "not applicable" for a response means that the
   agent MUST NOT place the header field in the response, and the agent
   MUST ignore the header field in the response.

   An RTSP agent MUST ignore extension headers that are not understood.

   The From and Location header fields contain a URI.  If the URI
   contains a comma (') or semicolon (;), the URI MUST be enclosed in
   double quotes (").  Any URI parameters are contained within these
   quotes.  If the URI is not enclosed in double quotes, any semicolon-
   delimited parameters are header-parameters, not URI parameters.

Top      Up      ToC       Page 127 
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | Header            |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | Accept            | R    |      | o  | -  | -   | -   | -   | -   |
   | Accept-           | R    | rm   | o  | o  | o   | o   | o   | o   |
   | Credentials       |      |      |    |    |     |     |     |     |
   | Accept-Encoding   | R    | r    | o  | -  | -   | -   | -   | -   |
   | Accept-Language   | R    | r    | o  | -  | -   | -   | -   | -   |
   | Accept-Ranges     | G    | r    | -  | -  | m   | -   | -   | -   |
   | Accept-Ranges     | 456  | r    | -  | -  | -   | m   | -   | -   |
   | Allow             | r    | am   | c  | c  | c   | -   | -   | -   |
   | Allow             | 405  | am   | m  | m  | m   | m   | m   | m   |
   | Authentication-   | r    |      | o  | o  | o   | o   | o   | o/- |
   | Info              |      |      |    |    |     |     |     |     |
   | Authorization     | R    |      | o  | o  | o   | o   | o   | o/- |
   | Bandwidth         | R    |      | o  | o  | o   | o   | -   | -   |
   | Blocksize         | R    |      | o  | -  | o   | o   | -   | -   |
   | Cache-Control     | G    | r    | o  | -  | o   | -   | -   | -   |
   | Connection        | G    | ad   | o  | o  | o   | o   | o   | o   |
   | Connection-       | 470, | ar   | o  | o  | o   | o   | o   | o   |
   | Credentials       | 407  |      |    |    |     |     |     |     |
   | Content-Base      | r    |      | o  | -  | -   | -   | -   | -   |
   | Content-Base      | 4xx, |      | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Encoding  | R    | r    | -  | -  | -   | -   | -   | -   |
   | Content-Encoding  | r    | r    | o  | -  | -   | -   | -   | -   |
   | Content-Encoding  | 4xx, | r    | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Language  | R    | r    | -  | -  | -   | -   | -   | -   |
   | Content-Language  | r    | r    | o  | -  | -   | -   | -   | -   |
   | Content-Language  | 4xx, | r    | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Length    | r    | r    | *  | -  | -   | -   | -   | -   |
   | Content-Length    | 4xx, | r    | *  | *  | *   | *   | *   | *   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Location  | r    | r    | o  | -  | -   | -   | -   | -   |
   | Content-Location  | 4xx, | r    | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Type      | r    | r    | *  | -  | -   | -   | -   | -   |
   | Content-Type      | 4xx, | ar   | *  | *  | *   | *   | *   | *   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | CSeq              | Gc   | rm   | m  | m  | m   | m   | m   | m   |
   | Date              | G    | am   | o/*| o/*| o/* | o/* | o/* | o/* |
   | Expires           | r    | r    | o  | -  | o   | -   | -   | -   |
   | From              | R    | r    | o  | o  | o   | o   | o   | o   |
   | If-Match          | R    | r    | -  | -  | o   | -   | -   | -   |
   | If-Modified-Since | R    | r    | o  | -  | o   | -   | -   | -   |
   | If-None-Match     | R    | r    | o  | -  | o   | -   | -   | -   |

Top      Up      ToC       Page 128 
   | Last-Modified     | r    | r    | o  | -  | o   | -   | -   | -   |
   | Location          | 3rr  |      | m  | m  | m   | m   | m   | m   |
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | Header            |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
   +-------------------+------+------+----+----+-----+-----+-----+-----+

     Figure 2: Overview of RTSP Header Fields (A-L) Related to Methods
            DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN

Top      Up      ToC       Page 129 
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | Header           | Where   |Proxy|DES |OPT |STP | PLY | PSE | TRD |
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | Media-Properties | r       |     | -  | -  | m  | o   | o   | -   |
   | Media-Range      | r       |     | -  | -  | c  | c   | c   | -   |
   | MTag             | r       | r   | o  | -  | o  | -   | -   | -   |
   | Pipelined-       | G       | amd | -  | o  | o  | o   | o   | o   |
   | Requests         |         | r   |    |    |    |     |     |     |
   | Proxy-           | 407     | amr | m  | m  | m  | m   | m   | m   |
   | Authenticate     |         |     |    |    |    |     |     |     |
   | Proxy-           | r       | amd | o  | o  | o  | o   | o   | o/- |
   | Authentication-  |         | r   |    |    |    |     |     |     |
   | Info             |         |     |    |    |    |     |     |     |
   | Proxy-           | R       | rd  | o  | o  | o  | o   | o   | o   |
   | Authorization    |         |     |    |    |    |     |     |     |
   | Proxy-Require    | R       | ar  | o  | o  | o  | o   | o   | o   |
   | Proxy-Require    | r       | r   | c  | c  | c  | c   | c   | c   |
   | Proxy-Supported  | R       | amr | c  | c  | c  | c   | c   | c   |
   | Proxy-Supported  | r       |     | c  | c  | c  | c   | c   | c   |
   | Public           | r       | amr | -  | m  | -  | -   | -   | -   |
   | Public           | 501     | amr | m  | m  | m  | m   | m   | m   |
   | Range            | R       |     | -  | -  | -  | o   | -   | -   |
   | Range            | r       |     | -  | -  | c  | m   | m   | -   |
   | Referrer         | R       |     | o  | o  | o  | o   | o   | o   |
   | Request-Status   | R       |     | -  | -  | -  | -   | -   | -   |
   | Require          | R       |     | o  | o  | o  | o   | o   | o   |
   | Retry-After      | 3rr,503 |     | o  | o  | o  | o   | o   | -   |
   |                  | ,553    |     |    |    |    |     |     |     |
   | Retry-After      | 413     |     | o  | -  | -  | -   | -   | -   |
   | RTP-Info         | r       |     | -  | -  | c  | c   | -   | -   |
   | Scale            | R       | r   | -  | -  | -  | o   | -   | -   |
   | Scale            | r       | amr | -  | -  | c  | c   | c   | -   |
   | Seek-Style       | R       |     | -  | -  | -  | o   | -   | -   |
   | Seek-Style       | r       |     | -  | -  | -  | m   | -   | -   |
   | Server           | R       | r   | -  | o  | -  | -   | -   | o   |
   | Server           | r       | r   | o  | o  | o  | o   | o   | o   |
   | Session          | R       | r   | -  | o  | o  | m   | m   | m   |
   | Session          | r       | r   | -  | c  | m  | m   | m   | o   |
   | Speed            | R       | admr| -  | -  | -  | o   | -   | -   |
   | Speed            | r       | admr| -  | -  | -  | c   | -   | -   |
   | Supported        | R       | r   | o  | o  | o  | o   | o   | o   |
   | Supported        | r       | r   | c  | c  | c  | c   | c   | c   |
   | Terminate-Reason | R       | r   | -  | -  | -  | -   | -   | -/o |
   | Timestamp        | R       | admr| o  | o  | o  | o   | o   | o   |
   | Timestamp        | c       | admr| m  | m  | m  | m   | m   | m   |
   | Transport        | G       | mr  | -  | -  | m  | -   | -   | -   |
   | Unsupported      | r       |     | c  | c  | c  | c   | c   | c   |
   | User-Agent       | R       |     | m* | m* | m* | m*  | m*  | m*  |

Top      Up      ToC       Page 130 
   | Via              | R       | amr | c  | c  | c  | c   | c   | c   |
   | Via              | r       | amr | c  | c  | c  | c   | c   | c   |
   | WWW-Authenticate | 401     |     | m  | m  | m  | m   | m   | m   |
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | Header           | Where   |Proxy|DES |OPT |STP | PLY | PSE | TRD |
   +------------------+---------+-----+----+----+----+-----+-----+-----+

     Figure 3: Overview of RTSP Header Fields (M-W) Related to Methods
            DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN

Top      Up      ToC       Page 131 
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | Header                    | Where | Proxy | GPR | SPR | RDR | PNY |
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | Accept-Credentials        | R     | rm    | o   | o   | o   | -   |
   | Accept-Encoding           | R     | r     | o   | o   | o   | -   |
   | Accept-Language           | R     | r     | o   | o   | o   | -   |
   | Accept-Ranges             | G     | rm    | o   | -   | -   | -   |
   | Allow                     | 405   | amr   | m   | m   | m   | m   |
   | Authentication-Info       | r     |       | o/- | o/- | -   | -   |
   | Authorization             | R     |       | o   | o   | o   | -   |
   | Bandwidth                 | R     |       | -   | o   | -   | -   |
   | Blocksize                 | R     |       | -   | o   | -   | -   |
   | Cache-Control             | G     | r     | o   | o   | -   | -   |
   | Connection                | G     |       | o   | o   | o   | o   |
   | Connection-Credentials    | 470,  | ar    | o   | o   | o   | -   |
   |                           | 407   |       |     |     |     |     |
   | Content-Base              | R     |       | o   | o   | -   | o   |
   | Content-Base              | r     |       | o   | o   | -   | -   |
   | Content-Base              | 4xx,  |       | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Encoding          | R     | r     | o   | o   | -   | o   |
   | Content-Encoding          | r     | r     | o   | o   | -   | -   |
   | Content-Encoding          | 4xx,  | r     | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Language          | R     | r     | o   | o   | -   | o   |
   | Content-Language          | r     | r     | o   | o   | -   | -   |
   | Content-Language          | 4xx,  | r     | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Length            | R     | r     | *   | *   | -   | *   |
   | Content-Length            | r     | r     | *   | *   | -   | -   |
   | Content-Length            | 4xx,  | r     | *   | *   | *   | *   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Location          | R     |       | o   | o   | -   | o   |
   | Content-Location          | r     |       | o   | o   | -   | -   |
   | Content-Location          | 4xx,  |       | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Type              | R     |       | *   | *   | -   | *   |
   | Content-Type              | r     |       | *   | *   | -   | -   |
   | Content-Type              | 4xx,  |       | *   | *   | *   | *   |
   |                           | 5xx   |       |     |     |     |     |
   | CSeq                      | R,c   | mr    | m   | m   | m   | m   |
   | Date                      | R     | a     | o/* | o/* | m   | o/* |
   | Date                      | r     | am    | o/* | o/* | o/* | o/* |
   | Expires                   | r     | r     | -   | -   | -   | -   |
   | From                      | R     | r     | o   | o   | o   | -   |
   | If-Match                  | R     | r     | -   | -   | -   | -   |
   | If-Modified-Since         | R     | am    | o   | -   | -   | -   |
   | If-None-Match             | R     | am    | o   | -   | -   | -   |

Top      Up      ToC       Page 132 
   | Last-Modified             | R     | r     | -   | -   | -   | -   |
   | Last-Modified             | r     | r     | o   | -   | -   | -   |
   | Location                  | 3rr   |       | m   | m   | m   | -   |
   | Location                  | R     |       | -   | -   | m   | -   |
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | Header                    | Where | Proxy | GPR | SPR | RDR | PNY |
   +---------------------------+-------+-------+-----+-----+-----+-----+

     Figure 4: Overview of RTSP Header Fields (A-L) Related to Methods
          GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY

Top      Up      ToC       Page 133 
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | Header                    |  Where  | Proxy | GPR | SPR | RDR | PNY |
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | Media-Properties          | R       | amr   | o   | -   | -   | c   |
 | Media-Properties          | r       | mr    | c   | -   | -   | -   |
 | Media-Range               | R       |       | o   | -   | -   | c   |
 | Media-Range               | r       |       | c   | -   | -   | -   |
 | MTag                      | r       | r     | o   | -   | -   | -   |
 | Notify-Reason             | R       |       | -   | -   | -   | m   |
 | Pipelined-Requests        | R       | amdr  | o   | o   | -   | -   |
 | Proxy-Authenticate        | 407     | amdr  | m   | m   | m   | -   |
 | Proxy-Authentication-Info | r       | amdr  | o/- | o/- | -   | -   |
 | Proxy-Authorization       | R       | amdr  | o   | o   | o   | -   |
 | Proxy-Require             | R       | ar    | o   | o   | o   | -   |
 | Proxy-Supported           | R       | amr   | c   | c   | c   | -   |
 | Proxy-Supported           | r       |       | c   | c   | c   | -   |
 | Public                    | 501     | admr  | m   | m   | m   | -   |
 | Range                     | R       |       | o   | -   | -   | m   |
 | Range                     | r       |       | c   | -   | -   | -   |
 | Referrer                  | R       |       | o   | o   | o   | -   |
 | Request-Status            | R       | mr    | -   | -   | -   | c   |
 | Require                   | R       | r     | o   | o   | o   | o   |
 | Retry-After               | 3rr,503,|       | o   | o   | -   | -   |
 |                           | 553     |       |     |     |     |     |
 | Retry-After               | 413     |       | o   | o   | -   | -   |
 | RTP-Info                  | R       | r     | o   | -   | -   | C   |
 | RTP-Info                  | r       | r     | c   | -   | -   | -   |
 | Scale                     | G       |       | c   | -   | c   | c   |
 | Seek-Style                | G       |       | -   | -   | -   | -   |
 | Server                    | R       | r     | o   | o   | o   | o   |
 | Server                    | r       | r     | o   | o   | -   | -   |
 | Session                   | R       | r     | o   | o   | o   | m   |
 | Session                   | r       | r     | c   | c   | o   | m   |
 | Speed                     | G       |       | -   | -   | -   | -   |
 | Supported                 | R       | r     | o   | o   | o   | -   |
 | Supported                 | r       | r     | c   | c   | c   | -   |
 | Terminate-Reason          | R       | r     | -   | -   | m   | -   |
 | Timestamp                 | R       | adrm  | o   | o   | o   | o   |
 | Timestamp                 | c       | adrm  | m   | m   | m   | m   |
 | Transport                 | G       | mr    | -   | -   | -   | -   |
 | Unsupported               | r       | arm   | c   | c   | c   | c   |
 | User-Agent                | R       | r     | m*  | m*  | -   | -   |
 | User-Agent                | r       | r     | m*  | m*  | m*  | m*  |
 | Via                       | R       | amr   | c   | c   | c   | c   |

Top      Up      ToC       Page 134 
 | Via                       | r       | amr   | c   | c   | c   | c   |
 | WWW-Authenticate          | 401     |       | m   | m   | m   | -   |
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | Header                    |  Where  | Proxy | GPR | SPR | RDR | PNY |
 +---------------------------+---------+-------+-----+-----+-----+-----+

     Figure 5: Overview of RTSP Header Fields (M-W) Related to Methods
          GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY



(page 134 continued on part 7)

Next Section