Section 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.
   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.
   *:    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.
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | 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   | -   | -   | -   |
   | 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
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | 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*  |
   | 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
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | 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   | -   | -   | -   |
   | 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
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | 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   |
 | 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
18.1.  Accept
   The Accept request-header field can be used to specify certain
   presentation description and parameter media types [RFC6838] that are
   acceptable for the response to the DESCRIBE request.
   See Section 20.2.3 for the syntax.
   The asterisk "*" character is used to group media types into ranges,
   with "*/*" indicating all media types and "type/*" indicating all
   subtypes of that type.  The range MAY include media type parameters
   that are generally applicable to that range.
   Each media type or range MAY be followed by one or more accept-
   params, beginning with the "q" parameter to indicate a relative
   quality factor.  The first "q" parameter (if any) separates the media
   type or range's parameters from the accept-params.  Quality factors
   allow the user or user agent to indicate the relative degree of
   preference for that media type, using the qvalue scale from 0 to 1
   (Section 5.3.1 of [RFC7231]).  The default value is q=1.
   Example of use:
     Accept: application/example ;q=0.7, application/sdp
   Indicates that the requesting agent prefers the media type
   application/sdp through the default 1.0 rating but also accepts the
   application/example media type with a 0.7 quality rating.
   If no Accept header field is present, then it is assumed that the
   client accepts all media types.  If an Accept header field is
   present, and if the server cannot send a response that is acceptable
   according to the combined Accept field-value, then the server SHOULD
   send a 406 (Not Acceptable) response.
18.2.  Accept-Credentials
   The Accept-Credentials header is a request-header used to indicate to
   any trusted intermediary how to handle further secured connections to
   proxies or servers.  It MUST NOT be included in server-to-client
   requests.  See Section 19 for the usage of this header
   In a request, the header MUST contain the method (User, Proxy, or
   Any) for approving credentials selected by the requester.  The method
   MUST NOT be changed by any proxy, unless it is "Proxy" when a proxy
   MAY change it to "user" to take the role of user approving each
   further hop.  If the method is "User", the header contains zero or
   more of the credentials that the client accepts.  The header may
   contain zero credentials in the first RTSP request to an RTSP server
   via a proxy when using the "User" method.  This is because the client
   has not yet received any credentials to accept.  Each credential MUST
   consist of one URI identifying the proxy or server, the hash
   algorithm identifier, and the hash over that agent's ASN.1 DER-
   encoded certificate [RFC5280] in Base64, according to Section 4 of
   [RFC4648] and where the padding bits are set to zero.  All RTSP
   clients and proxies MUST implement the SHA-256 [FIPS180-4] algorithm
   for computation of the hash of the DER-encoded certificate.  The
   SHA-256 algorithm is identified by the token "sha-256".
   The intention of allowing for other hash algorithms is to enable the
   future retirement of algorithms that are not implemented somewhere
   other than here.  Thus, the definition of future algorithms for this
   purpose is intended to be extremely limited.  A feature tag can be
   used to ensure that support for the replacement algorithm exists.
   Example:
   Accept-Credentials:User
     "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
     "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
18.3.  Accept-Encoding
   The Accept-Encoding request-header field is similar to Accept, but it
   restricts the content-codings (see Section 18.15), i.e.,
   transformation codings of the message body, such as gzip compression,
   that are acceptable in the response.
   A server tests whether a content-coding is acceptable, according to
   an Accept-Encoding field, using these rules:
   1.  If the content-coding is one of the content-codings listed in the
       Accept-Encoding field, then it is acceptable, unless it is
       accompanied by a qvalue of 0.  (As defined in Section 5.3.1 of
       [RFC7231], a qvalue of 0 means "not acceptable.")
   2.  The special "*" symbol in an Accept-Encoding field matches any
       available content-coding not explicitly listed in the header
       field.
   3.  If multiple content-codings are acceptable, then the acceptable
       content-coding with the highest non-zero qvalue is preferred.
   4.  The "identity" content-coding is always acceptable, i.e., no
       transformation at all, unless specifically refused because the
       Accept-Encoding field includes "identity;q=0" or because the
       field includes "*;q=0" and does not explicitly include the
       "identity" content-coding.  If the Accept-Encoding field-value is
       empty, then only the "identity" encoding is acceptable.
   If an Accept-Encoding field is present in a request, and if the
   server cannot send a response that is acceptable according to the
   Accept-Encoding header, then the server SHOULD send an error response
   with the 406 (Not Acceptable) status code.
   If no Accept-Encoding field is present in a request, the server MAY
   assume that the client will accept any content-coding.  In this case,
   if "identity" is one of the available content-codings, then the
   server SHOULD use the "identity" content-coding, unless it has
   additional information that a different content-coding is meaningful
   to the client.
18.4.  Accept-Language
   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.  Note that the language specified applies to
   the presentation description (response message body) and any reason
   phrases, but not the media content.
   A language tag identifies a natural language spoken, written, or
   otherwise conveyed by human beings for communication of information
   to other human beings.  Computer languages are explicitly excluded.
   The syntax and registry of RTSP 2.0 language tags are the same as
   those defined by [RFC5646].
   Each language-range MAY be given an associated quality value that
   represents an estimate of the user's preference for the languages
   specified by that range.  The quality value defaults to "q=1".  For
   example:
      Accept-Language: da, en-gb;q=0.8, en;q=0.7
   would mean: "I prefer Danish, but will accept British English and
   other types of English."  A language-range matches a language tag if
   it exactly equals the full tag or if it exactly equals a prefix of
   the tag, i.e., the primary-tag in the ABNF, such that the character
   following primary-tag is "-".  The special range "*", if present in
   the Accept-Language field, matches every tag not matched by any other
   range present in the Accept-Language field.
      Note: This use of a prefix matching rule does not imply that
      language tags are assigned to languages in such a way that it is
      always true that if a user understands a language with a certain
      tag, then this user will also understand all languages with tags
      for which this tag is a prefix.  The prefix rule simply allows the
      use of prefix tags if this is the case.
   In the process of selecting a language, each language tag is assigned
   a qualification factor, i.e., if a language being supported by the
   client is actually supported by the server and what "preference"
   level the language achieves.  The quality value (q-value) of the
   longest language-range in the field that matches the language tag is
   assigned as the qualification factor for a particular language tag.
   If no language-range in the field matches the tag, the language
   qualification factor assigned is 0.  If no Accept-Language header is
   present in the request, the server SHOULD assume that all languages
   are equally acceptable.  If an Accept-Language header is present,
   then all languages that are assigned a qualification factor greater
   than 0 are acceptable.
18.5.  Accept-Ranges
   The Accept-Ranges general-header field allows indication of the
   format supported in the Range header.  The client MUST include the
   header in SETUP requests to indicate which formats are acceptable
   when received in PLAY and PAUSE responses and REDIRECT requests.  The
   server MUST include the header in SETUP responses and 456 (Header
   Field Not Valid for Resource) error responses to indicate the formats
   supported for the resource indicated by the Request-URI.  The header
   MAY be included in GET_PARAMETER request and response pairs.  The
   GET_PARAMETER request MUST contain a Session header to identify the
   session context the request is related to.  The requester and
   responder will indicate their capabilities regarding Range formats
   respectively.
      Accept-Ranges: npt, smpte, clock
   The syntax is defined in Section 20.2.3.
18.6.  Allow
   The Allow message body header field lists the methods supported by
   the resource identified by the Request-URI.  The purpose of this
   field is to inform the recipient of the complete set of valid methods
   associated with the resource.  An Allow header field MUST be present
   in a 405 (Method Not Allowed) response.  The Allow header MUST also
   be present in all OPTIONS responses where the content of the header
   will not include exactly the same methods as listed in the Public
   header.
   The Allow message body header MUST also be included in SETUP and
   DESCRIBE responses, if the methods allowed for the resource are
   different from the complete set of methods defined in this memo.
   Example of use:
      Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
18.7.  Authentication-Info
   The Authentication-Info response-header is used by the server to
   communicate some information regarding the successful HTTP
   authentication [RFC7235] in the response message.  The definition of
   the header is in [RFC7615], and any applicable HTTP authentication
   schemes appear in other RFCs, such as Digest [RFC7616].  This header
   MUST only be used in response messages related to client to server
   requests.
18.8.  Authorization
   An RTSP client that wishes to authenticate itself with a server using
   the authentication mechanism from HTTP [RFC7235], usually (but not
   necessarily) after receiving a 401 response, does so by including an
   Authorization request-header field with the request.  The
   Authorization field-value consists of credentials containing the
   authentication information of the user agent for the realm of the
   resource being requested.  The definition of the header is in
   [RFC7235], and any applicable HTTP authentication schemes appear in
   other RFCs, such as Digest [RFC7616] and Basic [RFC7617].  This
   header MUST only be used in client-to-server requests.
   If a request is authenticated and a realm specified, the same
   credentials SHOULD be valid for all other requests within this realm
   (assuming that the authentication scheme itself does not require
   otherwise, such as credentials that vary according to a challenge
   value or using synchronized clocks).  Each client-to-server request
   MUST be individually authorized by including the Authorization header
   with the information.
   When a shared cache (see Section 16) receives a request containing an
   Authorization field, it MUST NOT return the corresponding response as
   a reply to any other request, unless one of the following specific
   exceptions holds:
   1.  If the response includes the "max-age" cache directive, the cache
       MAY use that response in replying to a subsequent request.  But
       (if the specified maximum age has passed) a proxy cache MUST
       first revalidate it with the origin server, using the request-
       headers from the new request to allow the origin server to
       authenticate the new request.  (This is the defined behavior for
       max-age.)  If the response includes "max-age=0", the proxy MUST
       always revalidate it before reusing it.
   2.  If the response includes the "must-revalidate" cache-control
       directive, the cache MAY use that response in replying to a
       subsequent request.  But if the response is stale, all caches
       MUST first revalidate it with the origin server, using the
       request-headers from the new request to allow the origin server
       to authenticate the new request.
   3.  If the response includes the "public" cache directive, it MAY be
       returned in reply to any subsequent request.
18.9.  Bandwidth
   The Bandwidth request-header field describes the estimated bandwidth
   available to the client, expressed as a positive integer and measured
   in kilobits per second.  The bandwidth available to the client may
   change during an RTSP session, e.g., due to mobility, congestion,
   etc.
   Clients may not be able to accurately determine the available
   bandwidth, for example, because the first hop is not a bottleneck.
   Such a case is when the local area network (LAN) is not the
   bottleneck, instead the LAN's Internet access link is, if the server
   is not in the same LAN.  Thus, link speeds of WLAN or Ethernet
   networks are normally not a basis for estimating the available
   bandwidth.  Cellular devices or other devices directly connected to a
   modem or connection-enabling device may more accurately estimate the
   bottleneck bandwidth and what is a reasonable share of it for RTSP-
   controlled media.  The client will also need to take into account
   other traffic sharing the bottleneck.  For example, by only assigning
   a certain fraction to RTSP and its media streams.  It is RECOMMENDED
   that only clients that have accurate and explicit information about
   bandwidth bottlenecks use this header.
   This header is not a substitute for proper congestion control.  It is
   only a method providing an initial estimate and coarsely determines
   if the selected content can be delivered at all.
   Example:
     Bandwidth: 62360
18.10.  Blocksize
   The Blocksize 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 that 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 (4xx) if the value is syntactically
   invalid.
18.11.  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 DESCRIBE, GET_PARAMETER,
   SET_PARAMETER, and SETUP request and its response.  Note: Cache-
   Control does not govern only the caching of responses for the RTSP
   messages, instead it also applies to the media stream identified by
   the SETUP request.  The RTSP requests are generally not cacheable;
   for further information, see Section 16.  Below are the descriptions
   of the cache directives that can be included in the Cache-Control
   header.
   no-cache:  Indicates that the media stream or RTSP response 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.  Note: there is no security
         function preventing the caching of content.
   public:  Indicates that the media stream or RTSP response is
         cacheable by any cache.
   private:  Indicates that the media stream or RTSP response is
         intended for a single user and MUST NOT be cached by a shared
         cache.  A private (non-shared) cache may cache the media
         streams.
   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 media stream or RTSP
         response.  Therefore, if a response includes the no-transform
         directive, an intermediate cache or proxy MUST NOT change the
         encoding of the stream or response.  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 or RTSP responses 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 the cache receives this directive, it SHOULD
         either respond using a cached media stream or response 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.
   max-stale:  Indicates that the client is willing to accept a media
         stream or RTSP response 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 or RTSP response 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
         cache entry after it becomes stale to respond to a subsequent
         request without first revalidating it with the origin server.
         That is, the cache is required to do an end-to-end revalidation
         every time, if, based solely on the origin server's Expires,
         the cached response is stale.
   proxy-revalidate:  The proxy-revalidate directive has the same
         meaning as the must-revalidate directive, except that it does
         not apply to non-shared user agent caches.  It can be used on a
         response to an authenticated request to permit the user's cache
         to store and later return the response without needing to
         revalidate it (since it has already been authenticated once by
         that user), while still requiring proxies that service many
         users to revalidate each time (in order to make sure that each
         user has been authenticated).  Note that such authenticated
         responses also need the "public" cache directive in order to
         allow them to be cached at all.
   max-age:  When an intermediate cache is forced, by means of a max-
         age=0 directive, to revalidate its own cache entry, and the
         client has supplied its own validator in the request, the
         supplied validator might differ from the validator currently
         stored with the cache entry.  In this case, the cache MAY use
         either validator in making its own request without affecting
         semantic transparency.
         However, the choice of validator might affect performance.  The
         best approach is for the intermediate cache to use its own
         validator when making its request.  If the server replies with
         304 (Not Modified), then the cache can return its now validated
         copy to the client with a 200 (OK) response.  If the server
         replies with a new message body and cache validator, however,
         the intermediate cache can compare the returned validator with
         the one provided in the client's request, using the strong
         comparison function.  If the client's validator is equal to the
         origin server's, then the intermediate cache simply returns 304
         (Not Modified).  Otherwise, it returns the new message body
         with a 200 (OK) response.
18.12.  Connection
   The Connection general-header field allows the sender to specify
   options that are desired for that particular connection.  It MUST NOT
   be communicated by proxies over further connections.
   RTSP 2.0 proxies MUST parse the Connection header field before a
   message is forwarded and, for each connection-token in this field,
   remove any header field(s) from the message with the same name as the
   connection-token.  Connection options are signaled by the presence of
   a connection-token in the Connection header field, not by any
   corresponding additional header field(s), since the additional header
   field may not be sent if there are no parameters associated with that
   connection option.
   Message headers listed in the Connection header MUST NOT include end-
   to-end headers, such as Cache-Control.
   RTSP 2.0 defines the "close" connection option for the sender to
   signal that the connection will be closed after completion of the
   response.  For example, "Connection: close in either the request or
   the response-header fields" indicates that the connection SHOULD NOT
   be considered "persistent" (Section 10.2) after the current request/
   response is complete.
   The use of the connection option "close" in RTSP messages SHOULD be
   limited to error messages when the server is unable to recover and
   therefore sees it necessary to close the connection.  The reason
   being that the client has the choice of continuing using a connection
   indefinitely, as long as it sends valid messages.
18.13.  Connection-Credentials
   The Connection-Credentials response-header is used to carry the chain
   of credentials for any next hop that needs to be approved by the
   requester.  It MUST only be used in server-to-client responses.
   The Connection-Credentials header in an RTSP response MUST, if
   included, contain the credential information (in the form of a list
   of certificates providing the chain of certification) of the next hop
   to which an intermediary needs to securely connect.  The header MUST
   include the URI of the next hop (proxy or server) and a
   Base64-encoded (according to Section 4 of [RFC4648] and where the
   padding bits are set to zero) binary structure containing a sequence
   of DER-encoded X.509v3 certificates [RFC5280].
   The binary structure starts with the number of certificates
   (NR_CERTS) included as a 16-bit unsigned integer.  This is followed
   by an NR_CERTS number of 16-bit unsigned integers providing the size,
   in octets, of each DER-encoded certificate.  This is followed by an
   NR_CERTS number of DER-encoded X.509v3 certificates in a sequence
   (chain).  This format is exemplified in Figure 6.  The certificate of
   the proxy or server must come first in the structure.  Each following
   certificate must directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority may optionally be omitted from the chain, under
   the assumption that the remote end must already possess it in order
   to validate it in any case.
   Example:
   Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
   Where MIIDNTCC... is a Base64 encoding of the following structure:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Number of certificates       | Size of certificate #1        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Size of certificate #2        | Size of certificate #3        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #1                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #2                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #3                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 6: Format Example of Connection-Credentials Header Certificate
18.14.  Content-Base
   The Content-Base message body header field may be used to specify the
   base URI for resolving relative URIs within the message body.
   Content-Base: rtsp://media.example.com/movie/twister/
   If no Content-Base field is present, the base URI of a message body
   is defined by either its Content-Location (if that Content-Location
   URI is an absolute URI) or the URI used to initiate the request, in
   that order of precedence.  Note, however, that the base URI of the
   contents within the message body may be redefined within that message
   body.
18.15.  Content-Encoding
   The Content-Encoding message body header field is used as a modifier
   of the media-type.  When present, its value indicates what additional
   content-codings have been applied to the message body, and thus what
   decoding mechanisms must be applied in order to obtain the media-type
   referenced by the Content-Type header field.  Content-Encoding is
   primarily used to allow a document to be compressed without losing
   the identity of its underlying media type.
   The content-coding is a characteristic of the message body identified
   by the Request-URI.  Typically, the message body is stored with this
   encoding and is only decoded before rendering or analogous usage.
   However, an RTSP proxy MAY modify the content-coding if the new
   coding is known to be acceptable to the recipient, unless the "no-
   transform" cache directive is present in the message.
   If the content-coding of a message body is not "identity", then the
   message MUST include a Content-Encoding message body header that
   lists the non-identity content-coding(s) used.
   If the content-coding of a message body in a request message is not
   acceptable to the origin server, the server SHOULD respond with a
   status code of 415 (Unsupported Media Type).
   If multiple encodings have been applied to a message body, the
   content-codings MUST be listed in the order in which they were
   applied, first to last from left to right.  Additional information
   about the encoding parameters MAY be provided by other header fields
   not defined by this specification.
18.16.  Content-Language
   The Content-Language message body header field describes the natural
   language(s) of the intended audience for the enclosed message body.
   Note that this might not be equivalent to all the languages used
   within the message body.
   Language tags are mentioned in Section 18.4.  The primary purpose of
   Content-Language is to allow a user to identify and differentiate
   entities according to the user's own preferred language.  Thus, if
   the body content is intended only for a Danish-literate audience, the
   appropriate field is
      Content-Language: da
   If no Content-Language is specified, the default is that the content
   is intended for all language audiences.  This might mean that the
   sender does not consider it to be specific to any natural language or
   that the sender does not know for which language it is intended.
   Multiple languages MAY be listed for content that is intended for
   multiple audiences.  For example, a rendition of the "Treaty of
   Waitangi", presented simultaneously in the original Maori and English
   versions, would call for
      Content-Language: mi, en
   However, just because multiple languages are present within a message
   body does not mean that it is intended for multiple linguistic
   audiences.  An example would be a beginner's language primer, such as
   "A First Lesson in Latin", which is clearly intended to be used by an
   English-literate audience.  In this case, the Content-Language would
   properly only include "en".
   Content-Language MAY be applied to any media type -- it is not
   limited to textual documents.
18.17.  Content-Length
   The Content-Length message body header field contains the length of
   the message body of the RTSP message (i.e., after the double CRLF
   following the last header) in octets of bits.  Unlike HTTP, it MUST
   be included in all messages that carry a message body beyond the
   header portion of the RTSP message.  If it is missing, a default
   value of zero is assumed.  Any Content-Length greater than or equal
   to zero is a valid value.
18.18.  Content-Location
   The Content-Location message body header field MAY be used to supply
   the resource location for the message body enclosed in the message
   when that body is accessible from a location separate from the
   requested resource's URI.  A server SHOULD provide a Content-Location
   for the variant corresponding to the response message body;
   especially in the case where a resource has multiple variants
   associated with it, and those entities actually have separate
   locations by which they might be individually accessed, the server
   SHOULD provide a Content-Location for the particular variant that is
   returned.
   As an example, if an RTSP client performs a DESCRIBE request on a
   given resource, e.g., "rtsp://a.example.com/movie/
   Plan9FromOuterSpace", then the server may use additional information,
   such as the User-Agent header, to determine the capabilities of the
   agent.  The server will then return a media description tailored to
   that class of RTSP agents.  To indicate which specific description
   the agent receives, the resource identifier
   ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is
   provided in Content-Location, while the description is still a valid
   response for the generic resource identifier, thus enabling both
   debugging and cache operation as discussed below.
   The Content-Location value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular variant at the time of the request.
   Future requests MAY specify the Content-Location URI as the Request-
   URI if the desire is to identify the source of that particular
   variant.  This is useful if the RTSP agent desires to verify if the
   resource variant is current through a conditional request.
   A cache cannot assume that a message body with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI.  However, the Content-
   Location can be used to differentiate between multiple variants
   retrieved from a single requested resource.
   If the Content-Location is a relative URI, the relative URI is
   interpreted relative to the Request-URI.
   Note that Content-Location can be used in some cases to derive the
   base-URI for relative URI(s) present in session description formats.
   This needs to be taken into account when Content-Location is used.
   The easiest way to avoid needing to consider that issue is to include
   the Content-Base whenever the Content-Location is included.
   Note also, when using Media Tags in conjunction with Content-
   Location, it is important that the different versions have different
   MTags, even if provided under different Content-Location URIs.  This
   is because the different content variants still have been provided in
   response to the same request URI.
   Note also, as in most cases, the URIs used in the DESCRIBE and the
   SETUP requests are different: the URI provided in a DESCRIBE Content-
   Location response can't directly be used in a SETUP request.
   Instead, the steps of deriving the media resource URIs are necessary.
   This commonly involves combing the media description's relative URIs,
   e.g., from the SDP's a=control attribute, with the base-URI to create
   the absolute URIs needed in the SETUP request.
18.19.  Content-Type
   The Content-Type message body header indicates the media type of the
   message body sent to the recipient.  Note that the content types
   suitable for RTSP are likely to be restricted in practice to
   presentation descriptions and parameter-value types.
18.20.  CSeq
   The CSeq general-header field specifies the sequence number (integer)
   for an RTSP request/response pair.  This field MUST be present in all
   requests and responses.  RTSP agents maintain a sequence number
   series for each responder to which they have an open message
   transport channel.  For each new RTSP request an agent originates on
   a particular RTSP message transport, the CSeq value MUST be
   incremented by one.  The initial sequence number can be any number;
   however, it is RECOMMENDED to start at 0.  Each sequence number
   series is unique between each requester and responder, i.e., the
   client has one series for its requests to a server and the server has
   another when sending requests to the client.  Each requester and
   responder is identified by its socket address (IP address and port
   number), i.e., per direction of a TCP connection.  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.  The RTSP agent receiving requests MUST process the
   requests arriving on a particular transport in the order of the
   sequence numbers.  Responses are sent in the order that they are
   generated.  The RTSP response MUST have the same sequence number as
   was present in the corresponding request.  An RTSP agent receiving a
   response MAY receive the responses out of order compared to the order
   of the requests it sent.  Thus, the agent MUST use the sequence
   number in the response to pair it with the corresponding request.
      The main purpose of the sequence number is to map responses to
      requests.
      The requirement to use a sequence-number increment of one for each
      new request is to support any future specification of RTSP message
      transport over a protocol that does not provide in-order delivery
      or is unreliable.
      The above rules relating to the initial sequence number may appear
      unnecessarily loose.  The reason for this is to cater to some
      common behavior of existing implementations: when using multiple
      reliable connections in sequence, it may still be easiest to use a
      single sequence-number series for a client connecting with a
      particular server.  Thus, the initial sequence number may be
      arbitrary depending on the number of previous requests.  For any
      unreliable transport, a stricter definition or other solution will
      be required to enable detection of any loss of the first request.
      When using multiple sequential transport connections, there is no
      protocol mechanism to ensure in-order processing as the sequence
      number is scoped on the individual transport connection and its
      five tuple.  Thus, there are potential issues with opening a new
      transport connection to the same host for which there already
      exists a transport connection with outstanding requests and
      previously dispatched requests related to the same RTSP session.
   RTSP Proxies also need to follow the above rules.  This implies that
   proxies that aggregate requests from multiple clients onto a single
   transport towards a server or a next-hop proxy need to renumber these
   requests to form a unified sequence on that transport, fulfilling the
   above rules.  A proxy capable of fulfilling some agent's request
   without emitting its own request (e.g., a caching proxy that fulfills
   a request from its cache) also causes a need to renumber as the
   number of received requests with a particular target may not be the
   same as the number of emitted requests towards that target agent.  A
   proxy that needs to renumber needs to perform the corresponding
   renumbering back to the original sequence number for any received
   response before forwarding it back to the originator of the request.
      A client connected to a proxy, and using that transport to send
      requests to multiple servers, creates a situation where it is
      quite likely to receive the responses out of order.  This is
      because the proxy will establish separate transports from the
      proxy to the servers on which to forward the client's requests.
      When the responses arrive from the different servers, they will be
      forwarded to the client in the order they arrive at the proxy and
      can be processed, not the order of the client's original sequence
      numbers.  This is intentional to avoid some session's requests
      being blocked by another server's slow processing of requests.
18.21.  Date
   The Date general-header field represents the date and time at which
   the message was originated.  The inclusion of the Date header in an
   RTSP message follows these rules:
   o  An RTSP message, sent by either the client or the server,
      containing a body MUST include a Date header, if the sending host
      has a clock;
   o  Clients and servers are RECOMMENDED to include a Date header in
      all other RTSP messages, if the sending host has a clock;
   o  If the server does not have a clock that can provide a reasonable
      approximation of the current time, its responses MUST NOT include
      a Date header field.  In this case, this rule MUST be followed:
      some origin-server implementations might not have a clock
      available.  An origin server without a clock MUST NOT assign
      Expires or Last-Modified values to a response, unless these values
      were associated with the resource by a system or user with a
      reliable clock.  It MAY assign an Expires value that is known, at
      or before server-configuration time, to be in the past (this
      allows "pre-expiration" of responses without storing separate
      Expires values for each resource).
   A received message that does not have a Date header field MUST be
   assigned one by the recipient if the message will be cached by that
   recipient.  An RTSP implementation without a clock MUST NOT cache
   responses without revalidating them on every use.  An RTSP cache,
   especially a shared cache, SHOULD use a mechanism, such as the
   Network Time Protocol (NTP) [RFC5905], to synchronize its clock with
   a reliable external standard.
   The RTSP-date, a full date as specified by Section 3.3 of [RFC5322],
   sent in a Date header SHOULD NOT represent a date and time subsequent
   to the generation of the message.  It SHOULD represent the best
   available approximation of the date and time of message generation,
   unless the implementation has no means of generating a reasonably
   accurate date and time.  In theory, the date ought to represent the
   moment just before the message body is generated.  In practice, the
   date can be generated at any time during the message origination
   without affecting its semantic value.
      Note: The RTSP 2.0 date format is defined to be the full-date
      format in RFC 5322.  This format is more flexible than the date
      use single spaces as separators, as recommended by RFC 5322, and
      support receiving the obsolete format.
      Further, note that the syntax allows for a comment to be added at
      the end of the date.
18.22.  Expires
   The Expires message body 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 presentation description (body) SHOULD be
         considered stale.
   SETUP response:  The Expires header indicates a date and time after
         which the media stream SHOULD be considered stale.
   A stale cache entry should not be returned by a cache (either a proxy
   cache or a user agent cache) unless it is first validated with the
   origin server (or with an intermediate cache that has a fresh copy of
   the message body).  See Section 16 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 RTSP-date.  An
   example of its use is
     Expires: Wed, 23 Jan 2013 15:36:52 +0000
   RTSP 2.0 clients and caches MUST treat other invalid date formats,
   especially those 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
   2.0 servers SHOULD NOT send Expires dates that are more than one year
   in the future.
18.23.  From
   The From request-header field, if given, SHOULD contain an Internet
   email address for the human user who controls the requesting user
   agent.  The address SHOULD be machine usable, as defined by "mailbox"
   in [RFC1123].
   This header field MAY be used for logging purposes and as a means for
   identifying the source of invalid or unwanted requests.  It SHOULD
   NOT be used as an insecure form of access protection.  The
   interpretation of this field is that the request is being performed
   on behalf of the person given, who accepts responsibility for the
   method performed.  In particular, robot agents SHOULD include this
   header so that the person responsible for running the robot can be
   contacted if problems occur on the receiving end.
   The Internet email address in this field MAY be separate from the
   Internet host that issued the request.  For example, when a request
   is passed through a proxy, the original issuer's address SHOULD be
   used.
   The client SHOULD NOT send the From header field without the user's
   approval, as it might conflict with the user's privacy interests or
   their site's security policy.  It is strongly recommended that the
   user be able to disable, enable, and modify the value of this field
   at any time prior to a request.
18.24.  If-Match
   The If-Match request-header field is especially useful for ensuring
   the integrity of the presentation description, independent of how the
   presentation description was received.  The presentation description
   can be fetched via means external to RTSP (such as HTTP) or via the
   DESCRIBE message.  In the case of retrieving the presentation
   description via RTSP, the server implementation is guaranteeing the
   integrity of the description between the time of the DESCRIBE message
   and the SETUP message.  By including the MTag given in or with the
   session description in an If-Match header part of the SETUP request,
   the client ensures that resources set up are matching the
   description.  A SETUP request with the If-Match header for which the
   MTag validation check fails MUST generate a response using 412
   (Precondition Failed).
   This validation check is also very useful if a session has been
   redirected from one server to another.
18.25.  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 MUST be returned without any message body.
   An example of the field is:
     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
18.26.  If-None-Match
   This request-header can be used with one or several message body tags
   to make DESCRIBE requests conditional.  A client that has one or more
   message bodies previously obtained from the resource can verify that
   none of those entities is current by including a list of their
   associated message body tags in the If-None-Match header field.  The
   purpose of this feature is to allow efficient updates of cached
   information with a minimum amount of transaction overhead.  As a
   special case, the value "*" matches any current entity of the
   resource.
   If any of the message body tags match the message body tag of the
   message body that would have been returned in the response to a
   similar DESCRIBE request (without the If-None-Match header) on that
   resource, or if "*" is given and any current entity exists for that
   resource, then the server MUST NOT perform the requested method,
   unless required to do so because the resource's modification date
   fails to match that supplied in an If-Modified-Since header field in
   the request.  Instead, if the request method was DESCRIBE, the server
   SHOULD respond with a 304 (Not Modified) response, including the
   cache-related header fields (particularly MTag) of one of the message
   bodies that matched.  For all other request methods, the server MUST
   respond with a status of 412 (Precondition Failed).
   See Section 16.1.3 for rules on how to determine if two message body
   tags match.
   If none of the message body tags match, then the server MAY perform
   the requested method as if the If-None-Match header field did not
   exist, but MUST also ignore any If-Modified-Since header field(s) in
   the request.  That is, if no message body tags match, then the server
   MUST NOT return a 304 (Not Modified) response.
   If the request would, without the If-None-Match header field, result
   in anything other than a 2xx or 304 status, then the If-None-Match
   header MUST be ignored.  (See Section 16.1.4 for a discussion of
   server behavior when both If-Modified-Since and If-None-Match appear
   in the same request.)
   The result of a request having both an If-None-Match header field and
   an If-Match header field is unspecified and MUST be considered an
   illegal request.
18.27.  Last-Modified
   The Last-Modified message body header field indicates the date and
   time at which the origin server believes the presentation description
   or media stream was last modified.  For the DESCRIBE method, the
   header field indicates the last modification date and time of the
   description, for the SETUP of the media stream.
   An origin server MUST NOT send a Last-Modified date that is later
   than the server's time of message origination.  In such cases, where
   the resource's last modification would indicate some time in the
   future, the server MUST replace that date with the message
   origination date.
   An origin server SHOULD obtain the Last-Modified value of the message
   body as close as possible to the time that it generates the Date
   value of its response.  This allows a recipient to make an accurate
   assessment of the message body's modification time, especially if the
   message body changes near the time that the response is generated.
   RTSP servers SHOULD send Last-Modified whenever feasible.
18.28.  Location
   The Location response-header field is used to redirect the recipient
   to a location other than the Request-URI for completion of the
   request or identification of a new resource.  For 3rr responses, the
   location SHOULD indicate the server's preferred URI for automatic
   redirection to the resource.  The field-value consists of a single
   absolute URI.
   Note: The Content-Location header field (Section 18.18) differs from
   Location in that the Content-Location identifies the original
   location of the message body enclosed in the request.  Therefore, it
   is possible for a response to contain header fields for both Location
   and Content-Location.  Also, see Section 16.2 for cache requirements
   of some methods.
18.29.  Media-Properties
   This general-header is used in SETUP responses or PLAY_NOTIFY
   requests to indicate the media's properties that currently are
   applicable to the RTSP session.  PLAY_NOTIFY MAY be used to modify
   these properties at any point.  However, the client SHOULD have
   received the update prior to any action related to the new media
   properties taking effect.  For aggregated sessions, the Media-
   Properties header will be returned in each SETUP response.  The
   header received in the latest response is the one that applies on the
   whole session from this point until any future update.  The header
   MAY be included without value in GET_PARAMETER requests to the server
   with a Session header included to query the current Media-Properties
   for the session.  The responder MUST include the current session's
   media properties.
   The media properties expressed by this header are the ones applicable
   to all media in the RTSP session.  For aggregated sessions, the
   header expressed the combined media-properties.  As a result,
   aggregation of media MAY result in a change of the media properties
   and, thus, the content of the Media-Properties header contained in
   subsequent SETUP responses.
   The header contains a list of property values that are applicable to
   the currently setup media or aggregate of media as indicated by the
   RTSP URI in the request.  No ordering is enforced within the header.
   Property values should be placed into a single group that handles a
   particular orthogonal property.  Values or groups that express
   multiple properties SHOULD NOT be used.  The list of properties that
   can be expressed MAY be extended at any time.  Unknown property
   values MUST be ignored.
   This specification defines the following four groups and their
   property values:
   Random Access:
      Random-Access:  Indicates that random access is possible.  May
         optionally include a floating-point value in seconds indicating
         the longest duration between any two random access points in
         the media.
      Beginning-Only:  Seeking is limited to the beginning only.
      No-Seeking:  No seeking is possible.
   Content Modifications:
      Immutable:  The content will not be changed during the lifetime of
         the RTSP session.
      Dynamic:  The content may be changed based on external methods or
         triggers.
      Time-Progressing:  The media accessible progresses as wallclock
         time progresses.
   Retention:
      Unlimited:  Content will be retained for the duration of the
         lifetime of the RTSP session.
      Time-Limited:  Content will be retained at least until the
         specified wallclock time.  The time must be provided in the
         absolute time format specified in Section 4.4.3.
      Time-Duration:  Each individual media unit is retained for at
         least the specified Time-Duration.  This definition allows for
         retaining data with a time-based sliding window.  The time
         duration is expressed as floating-point number in seconds.  The
         value 0.0 is a valid as this indicates that no data is retained
         in a time-progressing session.
   Supported Scale:
      Scales:  A quoted comma-separated list of one or more decimal
         values or ranges of scale values supported by the content in
         arbitrary order.  A range has a start and stop value separated
         by a colon.  A range indicates that the content supports a
         fine-grained selection of scale values.  Fine-graining allows
         for steps at least as small as one tenth of a scale value.
         Content is considered to support fine-grained selection when
         the server in response to a given scale value can produce
         content with an actual scale that is less than one tenth of
         scale unit, i.e., 0.1, from the requested value.  Negative
         values are supported.  The value 0 has no meaning and MUST NOT
         be used.
   Examples of this header for on-demand content and a live stream
   without recording are:
   On-demand:
   Media-Properties: Random-Access=2.5, Unlimited, Immutable,
        Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
   Live stream without recording/timeshifting:
   Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
18.30.  Media-Range
   The Media-Range general-header is used to give the range of the media
   at the time of sending the RTSP message.  This header MUST be
   included in the SETUP response, PLAY and PAUSE responses for media
   that are time-progressing, PLAY and PAUSE responses after any change
   for media that are Dynamic, and in PLAY_NOTIFY requests that are sent
   due to Media-Property-Update.  A Media-Range header without any range
   specifications MAY be included in GET_PARAMETER requests to the
   server to request the current range.  In this case, the server MUST
   include the current range at the time of sending the response.
   The header MUST include range specifications for all time formats
   supported for the media, as indicated in Accept-Ranges header
   (Section 18.5) when setting up the media.  The server MAY include
   more than one range specification of any given time format to
   indicate media that has non-continuous range.  The range
   specifications SHALL be ordered with the range with the lowest value
   or earliest start time first, followed by ranges with increasingly
   higher values or later start time.
   For media that has the time-progressing property, the Media-Range
   header values will only be valid for the particular point in time
   when it was issued.  As the wallclock progresses, so will the media
   range.  However, it shall be assumed that media time progresses in
   direct relationship to wallclock time (with the exception of clock
   skew) so that a reasonably accurate estimation of the media range can
   be calculated.
18.31.  MTag
   The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER,
   or SETUP responses.  The message body tags (Section 4.6) returned in
   a DESCRIBE response and the one in SETUP refer to the presentation,
   i.e., both the returned session description and the media stream.
   This allows for verification that one has the right session
   description to a media resource at the time of the SETUP request.
   However, it has the disadvantage that a change in any of the parts
   results in invalidation of all the parts.
   If the MTag is provided both inside the message body, e.g., within
   the "a=mtag" attribute in SDP, and in the response message, then both
   tags MUST be identical.  It is RECOMMENDED that the MTag be primarily
   given in the RTSP response message, to ensure that caches can use the
   MTag without requiring content inspection.  However, for session
   descriptions that are distributed outside of RTSP, for example, using
   HTTP, etc., it will be necessary to include the message body tag in
   the session description as specified in Appendix D.1.9.
   SETUP and DESCRIBE requests can be made conditional upon the MTag
   using the headers If-Match (Section 18.24) and If-None-Match
   (Section 18.26).
18.32.  Notify-Reason
   The Notify-Reason response-header is solely used in the PLAY_NOTIFY
   method.  It indicates the reason why the server has sent the
   asynchronous PLAY_NOTIFY request (see Section 13.5).
18.33.  Pipelined-Requests
   The Pipelined-Requests general-header is used to indicate that a
   request is to be executed in the context created by a previous
   request(s).  The primary usage of this header is to allow pipelining
   of SETUP requests so that any additional SETUP request after the
   first one does not need to wait for the session ID to be sent back to
   the requesting agent.  The header contains a unique identifier that
   is scoped by the persistent connection used to send the requests.
   Upon receiving a request with the Pipelined-Requests, the responding
   agent MUST look up if there exists a binding between this Pipelined-
   Requests identifier for the current persistent connection and an RTSP
   session ID.  If the binding exists, then the received request is
   processed the same way as if it contained the Session header with the
   found session ID.  If there does not exist a mapping and no Session
   header is included in the request, the responding agent MUST create a
   binding upon the successful completion of a session creating request,
   i.e., SETUP.  A binding MUST NOT be created, if the request failed to
   create an RTSP session.  In case the request contains both a Session
   header and the Pipelined-Requests header, the Pipelined-Requests
   header MUST be ignored.
   Note: Based on the above definition, at least the first request
   containing a new unique Pipelined-Requests header will be required to
   be a SETUP request (unless the protocol is extended with new methods
   of creating a session).  After that first one, additional SETUP
   requests or requests of any type using the RTSP session context may
   include the Pipelined-Requests header.
   When responding to any request that contained the Pipelined-Requests
   header, the server MUST also include the Session header when a
   binding to a session context exists.  An RTSP agent that knows the
   session identifier SHOULD NOT use the Pipelined-Requests header in
   any request and only use the Session header.  This as the Session
   identifier is persistent across transport contexts, like TCP
   connections, which the Pipelined-Requests identifier is not.
   The RTSP agent sending the request with a Pipelined-Requests header
   has the responsibility for using a unique and previously unused
   identifier within the transport context.  Currently, only a TCP
   connection is defined as such a transport context.  A server MUST
   delete the Pipelined-Requests identifier and its binding to a session
   upon the termination of that session.  Despite the previous mandate,
   RTSP agents are RECOMMENDED not to reuse identifiers to allow for
   better error handling and logging.
   RTSP Proxies may need to translate Pipelined-Requests identifier
   values from incoming requests to outgoing to allow for aggregation of
   requests onto a persistent connection.
18.34.  Proxy-Authenticate
   The Proxy-Authenticate response-header field MUST be included as part
   of a 407 (Proxy Authentication Required) response.  The field-value
   consists of a challenge that indicates the authentication scheme and
   parameters applicable to the proxy for this Request-URI.  The
   definition of the header is in [RFC7235], and any applicable HTTP
   authentication schemes appear in other RFCs, such as Digest [RFC7616]
   and Basic [RFC7617].
   The HTTP access authentication process is described in [RFC7235].
   This header MUST only be used in response messages related to client-
   to-server requests.
18.35.  Proxy-Authentication-Info
   The Proxy-Authentication-Info response-header is used by the proxy to
   communicate some information regarding the successful authentication
   to the proxy in the message response in some authentication schemes,
   such as the Digest scheme [RFC7616].  The definition of the header is
   in [RFC7615], and any applicable HTTP authentication schemes appear
   in other RFCs.  This header MUST only be used in response messages
   related to client-to-server requests.  This header has hop-by-hop
   scope.
18.36.  Proxy-Authorization
   The Proxy-Authorization request-header field allows the client to
   identify itself (or its user) to a proxy that requires
   authentication.  The Proxy-Authorization field-value consists of
   credentials containing the authentication information of the user
   agent for the proxy or realm of the resource being requested.  The
   definition of the header is in [RFC7235], and any applicable HTTP
   authentication schemes appear in other RFCs, such as Digest [RFC7616]
   and Basic [RFC7617].
   The HTTP access authentication process is described in [RFC7235].
   Unlike Authorization, the Proxy-Authorization header field applies
   only to the next-hop proxy.  This header MUST only be used in client-
   to-server requests.
18.37.  Proxy-Require
   The Proxy-Require request-header field 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 using the
   Unsupported header.  The proxy MUST use the 551 (Option Not
   Supported) status code in the response.  Any feature tag included in
   the Proxy-Require does not apply to the endpoint (server or client).
   To ensure that a feature is supported by both proxies and servers,
   the tag needs to be included in also a Require header.
   See Section 18.43 for more details on the mechanics of this message
   and a usage example.  See discussion in the proxies section
   (Section 15.1) about when to consider that a feature requires proxy
   support.
   Example of use:
      Proxy-Require: play.basic
18.38.  Proxy-Supported
   The Proxy-Supported general-header field enumerates all the
   extensions supported by the proxy using feature tags.  The header
   carries the intersection of extensions supported by the forwarding
   proxies.  The Proxy-Supported header MAY be included in any request
   by a proxy.  It MUST be added by any proxy if the Supported header is
   present in a request.  When present in a request, the receiver MUST
   copy the received Proxy-Supported header in the response.
   The Proxy-Supported header field contains a list of feature tags
   applicable to proxies, as described in Section 4.5.  The list is the
   intersection of all feature tags understood by the proxies.  To
   achieve an intersection, the proxy adding the Proxy-Supported header
   includes all proxy feature tags it understands.  Any proxy receiving
   a request with the header MUST check the list and remove any feature
   tag(s) it does not support.  A Proxy-Supported header present in the
   response MUST NOT be modified by the proxies.  These feature tags are
   the ones the proxy chains support in general and are not specific to
   the request resource.
   Example:
     C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            User-Agent: PhonyClient/1.2
    P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
            Via: 2.0 pro.example.com
    P2->S:  OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-blech
            Via: 2.0 pro.example.com, 2.0 prox2.example.com
     S->C:  RTSP/2.0 200 OK
            Supported: foo, bar, baz
            Proxy-Supported: proxy-foo, proxy-blech
            Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
            Via: 2.0 pro.example.com, 2.0 prox2.example.com
18.39.  Public
   The Public response-header field lists the set of methods supported
   by the response sender.  This header applies to the general
   capabilities of the sender, and its only purpose is to indicate the
   sender's capabilities to the recipient.  The methods listed may or
   may not be applicable to the Request-URI; the Allow header field
   (Section 18.6) MAY be used to indicate methods allowed for a
   particular URI.
   Example of use:
      Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
   In the event that there are proxies between the sender and the
   recipient of a response, each intervening proxy MUST modify the
   Public header field to remove any methods that are not supported via
   that proxy.  The resulting Public header field will contain an
   intersection of the sender's methods and the methods allowed through
   by the intervening proxies.
      In general, proxies should allow all methods to transparently pass
      through from the sending RTSP agent to the receiving RTSP agent,
      but there may be cases where this is not desirable for a given
      proxy.  Modification of the Public response-header field by the
      intervening proxies ensures that the request sender gets an
      accurate response indicating the methods that can be used on the
      target agent via the proxy chain.
18.40.  Range
   The Range general-header specifies a time range in PLAY
   (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), and
   PLAY_NOTIFY (Section 13.5) requests and responses.  It MAY be
   included in GET_PARAMETER requests from the client to the server with
   only a Range format and no value to request the current media
   position, whether the session is in Play or Ready state in the
   included format.  The server SHALL, if supporting the range format,
   respond with the current playing point or pause point as the start of
   the range.  If an explicit stop point was used in the previous PLAY
   request, then that value shall be included as stop point.  Note that
   if the server is currently under any type of media playback
   manipulation affecting the interpretation of the Range header, like
   scale value other than 1, that fact is also required to be included
   in any GET_PARAMETER response by including the Scale header to
   provide complete information.
   The range can be specified in a number of units.  This specification
   defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock
   (Section 4.4.3) range units.  While octet ranges (Byte Ranges) (see
   Section 2.1 of [RFC7233]) and other extended units MAY be used, their
   behavior is unspecified since they are not normally meaningful in
   RTSP.  Servers supporting the Range header MUST understand the NPT
   range format and SHOULD understand the SMPTE range format.  If the
   Range header is sent in a time format that is not understood, the
   recipient SHOULD return 456 (Header Field Not Valid for Resource) and
   include an Accept-Ranges header indicating the supported time formats
   for the given resource.
   Example:
     Range: clock=19960213T143205Z-
   The Range header contains a range of one single range format.  A
   range is a half-open interval with a start and an end point,
   including the start point but excluding the end point.  A range may
   either be fully specified with explicit values for start point and
   end point or have either the start or end point be implicit.  An
   implicit start point indicates the session's pause point, and if no
   pause point is set, the start of the content.  An implicit end point
   indicates the end of the content.  The usage of both implicit start
   and end points is not allowed in the same Range header; however, the
   omission of the Range header has that meaning, i.e., from pause point
   (or start) until end of content.
      As noted, Range headers define half-open intervals.  A range of
      A-B starts exactly at time A, but ends just before B.  Only the
      start time of a media unit such as a video or audio frame is
      relevant.  For 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.
      Please note the difference between NPT timescales' "now" and an
      implicit start value.  Implicit values reference the current
      pause-point, while "now" is the current time.  In a time-
      progressing session with recording (retention for some or full
      time), the pause point may be 2 min into the session while now
      could be 1 hour into the session.
   By default, range intervals increase, where the second point is
   larger than the first point.
   Example:
       Range: npt=10-15
   However, range intervals can also decrease if the Scale header (see
   Section 18.46) indicates a negative scale value.  For example, this
   would be the case when a playback in reverse is desired.
   Example:
       Scale: -1
       Range: npt=15-10
   Decreasing ranges are still half-open intervals as described above.
   Thus, for range A-B, A is closed and B is open.  In the above
   example, 15 is closed and 10 is open.  An exception to this rule is
   the case when B=0 is in a decreasing range.  In this case, the range
   is closed on both ends, as otherwise there would be no way to reach 0
   on a reverse playback for formats that have such a notion, like NPT
   and SMPTE.
   Example:
       Scale: -1
       Range: npt=15-0
   In this range, both 15 and 0 are closed.
   A decreasing range interval without a corresponding negative value in
   the Scale header is not valid.
18.41.  Referrer
   The Referrer request-header field allows the client to specify, for
   the server's benefit, the address (URI) of the resource from which
   the Request-URI was obtained.  The URI refers to that of the
   presentation description, typically retrieved via HTTP.  The Referrer
   request-header allows a server to generate lists of back-links to
   resources for interest, logging, optimized caching, etc.  It also
   allows obsolete or mistyped links to be traced for maintenance.  The
   Referrer field MUST NOT be sent if the Request-URI was obtained from
   a source that does not have its own URI, such as input from the user
   keyboard.
   If the field-value is a relative URI, it SHOULD be interpreted
   relative to the Request-URI.  The URI MUST NOT include a fragment
   identifier.
   Because the source of a link might be private information or might
   reveal an otherwise private information source, it is strongly
   recommended that the user be able to select whether or not the
   Referrer field is sent.  For example, a streaming client could have a
   toggle switch for openly/anonymously, which would respectively
   enable/disable the sending of Referrer and From information.
   Clients SHOULD NOT include a Referrer header field in an (non-secure)
   RTSP request if the referring page was transferred with a secure
   protocol.
18.42.  Request-Status
   This request-header is used to indicate the end result for requests
   that take time to complete, such as PLAY (Section 13.4).  It is sent
   in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
   how the PLAY request concluded, either in success or in failure.  The
   header carries a reference to the request it reports on using the
   CSeq number and the Session ID used in the request reported on.  This
   is not ensured to be unambiguous due to the fact that the CSeq number
   is scoped by the transport connection.  Agents originating requests
   can reduce the issue by using a monotonically increasing counter
   across all sequential transports used.  The header provides both a
   numerical status code (according to Section 8.1.1) and a human-
   readable reason phrase.
   Example:
   Request-Status: cseq=63 status=500 reason="Media data unavailable"
   Proxies that renumber the CSeq header need to perform corresponding
   remapping of the cseq parameter in this header when forwarding the
   request to the next-hop agent.
18.43.  Require
   The Require request-header field is used by agents to ensure that the
   other endpoint supports features that are required in respect to this
   request.  It can also be used to query if the other endpoint supports
   certain features; however, the use of the Supported general-header
   (Section 18.51) is much more effective in this purpose.  In case any
   of the feature tags listed by the Require header are not supported by
   the server or client receiving the request, it MUST respond to the
   request using the error code 551 (Option Not Supported) and include
   the Unsupported header listing those feature tags that are NOT
   supported.  This header does not apply to proxies; for the same
   functionality with respect to proxies, see the Proxy-Require header
   (Section 18.37) with the exception of media-modifying proxies.
   Media-modifying proxies, due to their nature of handling media in a
   way that is very similar to a server, do need to understand also the
   server's features to correctly serve the client.
      This is to make sure that the client-server interaction will
      proceed without delay when all features are understood by both
      sides and only slow down if features are not understood (as in the
      example below).  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.
   Example (Not complete):
   C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Require: funky-feature
           Funky-Parameter: funkystuff
   S->C:   RTSP/2.0 551 Option not supported
           CSeq: 302
           Unsupported: funky-feature
   In this example, "funky-feature" is the feature tag that 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.
   Proxies and other intermediary devices MUST ignore this header.  If a
   particular extension requires that intermediate devices support it,
   the extension should be tagged in the Proxy-Require field instead
   (see Section 18.37).  See discussion in the proxies section
   (Section 15.1) about when to consider that a feature requires proxy
   support.
18.44.  Retry-After
   The Retry-After response-header field can be used with a 503 (Service
   Unavailable) or 553 (Proxy Unavailable) response to indicate how long
   the service is expected to be unavailable to the requesting client.
   This field MAY also be used with any 3rr (Redirection) response to
   indicate the minimum time the user agent is asked to wait before
   issuing the redirected request.  A response using 413 (Request
   Message Body Too Large) when the restriction is temporary MAY also
   include the Retry-After header.  The value of this field can be
   either an RTSP-date or an integer number of seconds (in decimal)
   after the time of the response.
   Example:
   Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
   Retry-After: 120
   In the latter example, the delay is 2 minutes.
18.45.  RTP-Info
   The RTP-Info general-header field is used to set RTP-specific
   parameters in the PLAY and GET_PARAMETER responses or PLAY_NOTIFY and
   GET_PARAMETER requests.  For streams using RTP as transport protocol,
   the RTP-Info header SHOULD be part of a 200 response to PLAY.
      The exclusion of the RTP-Info in a PLAY response for RTP-
      transported media will result in a client needing to synchronize
      the media streams using RTCP.  This may have negative impact as
      the RTCP can be lost and does not need to be particularly timely
      in its arrival.  Also, functionality that informs the client from
      which packet a seek has occurred is affected.
   The RTP-Info MAY be included in SETUP responses to provide
   synchronization information when changing transport parameters, see
   Section 13.3.  The RTP-Info header and the Range header MAY be
   included in a GET_PARAMETER request from client to server without any
   values to request the current playback point and corresponding RTP
   synchronization information.  When the RTP-Info header is included in
   a Request, the Range header MUST also be included.  The server
   response SHALL include both the Range header and the RTP-Info header.
   If the session is in Play state, then the value of the Range header
   SHALL be filled in with the current playback point and with the
   corresponding RTP-Info values.  If the server is in another state, no
   values are included in the RTP-Info header.  The header is included
   in PLAY_NOTIFY requests with the Notify-Reason of the end of stream
   to provide RTP information about the end of the stream.
   The header can carry the following parameters:
   url:  Indicates the stream URI for which the following RTP parameters
         correspond; this URI MUST be the same as used in the SETUP
         request for this media stream.  Any relative URI MUST use the
         Request-URI as base URI.  This parameter MUST be present.
   ssrc: The SSRC to which the RTP timestamp and sequence number
         provided applies.  This parameter MUST be present.
   seq:  Indicates the sequence number of the first packet of the stream
         that is direct result of the request.  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.  Note that a
         client may not receive the packet with the expressed sequence
         number and instead may receive packets with a higher sequence
         number due to packet loss or reordering.  This parameter is
         RECOMMENDED to be present.
   rtptime:  MUST indicate the RTP timestamp value corresponding to the
         start time value in the Range response-header or, if not
         explicitly given, the implied start point.  The client uses
         this value to calculate the mapping of RTP time to NPT or other
         media timescale.  This parameter SHOULD be present to ensure
         inter-media synchronization is achieved.  There exists no
         requirement that any received RTP packet will have the same RTP
         timestamp value as the one in the parameter used to establish
         synchronization.
      A mapping from RTP timestamps to NTP format timestamps (wallclock)
      is available via RTCP.  However, this information is not
      sufficient to generate a mapping from RTP timestamps to media
      clock time (NPT, etc.).  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.
   Example:
   Range:npt=3.25-15
   RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
            rtptime=12345678,url="rtsp://example.com/foo/video"
            ssrc=9A9DE123:seq=30211;rtptime=29567112
   Lets assume that Audio uses a 16 kHz RTP timestamp clock and Video
   a 90 kHz RTP timestamp clock.  Then, the media synchronization is
   depicted in the following way.
   NPT    3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
   Audio               PA A
   Video                  V    PV
   X: NPT time value = 3.25, from Range header.
   A: RTP timestamp value for Audio from RTP-Info header (12345678).
   V: RTP timestamp value for Video from RTP-Info header (29567112).
   PA: RTP audio packet carrying an RTP timestamp of 12344878, which
       corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
   PV: RTP video packet carrying an RTP timestamp of 29573412, which
       corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
18.46.  Scale
   The Scale general-header indicates the requested or used view rate
   for the media resource being played back.  A scale value of 1
   indicates normal play at the normal forward viewing rate.  If not 1,
   the value corresponds to the rate with respect to normal viewing
   rate.  For example, a value of 2 indicates twice the normal viewing
   rate ("fast forward") and a value of 0.5 indicates half the normal
   viewing rate.  In other words, a value of 2 has content time increase
   at twice the playback time.  For every second of elapsed (wallclock)
   time, 2 seconds of content time will be delivered.  A negative value
   indicates reverse direction.  For certain media transports, this may
   require certain considerations to work consistently; see Appendix C.1
   for description on how RTP handles this.
   The transmitted-data rate SHOULD NOT be changed by selection of a
   different scale value.  The resulting bitrate should be reasonably
   close to the nominal bitrate of the content for scale = 1.  The
   server has to actively manipulate the data when needed to meet the
   bitrate constraints.  Implementation of scale changes depends on the
   server and media type.  For video, a server may, for example, deliver
   only key frames or selected frames.  For audio, it may time-scale the
   audio while preserving pitch or, less desirably, deliver fragments of
   audio, or completely mute the audio.
   The server and content may restrict the range of scale values that it
   supports.  The supported values are indicated by the Media-Properties
   header (Section 18.29).  The client SHOULD only indicate request
   values to be supported.  However, as the values may change as the
   content progresses, a requested value may no longer be valid when the
   request arrives.  Thus, a non-supported value in a request does not
   generate an error, it only forces the server to choose the closest
   value.  The response MUST always contain the actual scale value
   chosen by the server.
   If the server does not implement the possibility to scale, it will
   not return a Scale header.  A server supporting scale operations for
   PLAY MUST indicate this with the use of the "play.scale" feature tag.
   When indicating a negative scale for a reverse playback, the Range
   header MUST indicate a decreasing range as described in
   Section 18.40.
   Example of playing in reverse at 3.5 times normal rate:
     Scale: -3.5
     Range: npt=15-10
18.47.  Seek-Style
   When a client sends a PLAY request with a Range header to perform a
   random access to the media, the client does not know if the server
   will pick the first media samples or the first random access point
   prior to the request range.  Depending on the use case, the client
   may have a strong preference.  To express this preference and provide
   the client with information on how the server actually acted on that
   preference, the Seek-Style general-header is defined.
   Seek-Style is a general-header that MAY be included in any PLAY
   request to indicate the client's preference for any media stream that
   has the random access properties.  The server MUST always include the
   header in any PLAY response for media with random access properties
   to indicate what policy was applied.  A server that receives an
   unknown Seek-Style policy MUST ignore it and select the server
   default policy.  A client receiving an unknown policy MUST ignore it
   and use the Range header and any media synchronization information as
   basis to determine what the server did.
   This specification defines the following seek policies that may be
   requested (see also Section 4.7.1):
   RAP:  Random Access Point (RAP) is the behavior of requesting the
      server to locate the closest previous random access point that
      exists in the media aggregate and deliver from that.  By
      requesting a RAP, media quality will be the best possible as all
      media will be delivered from a point where full media state can be
      established in the media decoder.
   CoRAP:  Conditional Random Access Point (CoRAP) is a variant of the
      above RAP behavior.  This policy is primarily intended for cases
      where there is larger distance between the random access points in
      the media.  CoRAP uses the RAP policy if the condition that there
      is a Random Access Point closer to the requested start point than
      to the current pause point is fulfilled.  Otherwise, no seeking is
      performed and playback will continue from the current pause point.
      This policy assumes that the media state existing prior to the
      pause is usable if delivery is continued.  If the client or server
      knows that this is not the fact, the RAP policy should be used.
      In other words, in most cases when the client requests a start
      point prior to the current pause point, a valid decoding
      dependency chain from the media delivered prior to the pause and
      to the requested media unit will not exist.  If the server
      searched to a random access point, the server MUST return the
      CoRAP policy in the Seek-Style header and adjust the Range header
      to reflect the position of the selected RAP.  In case the random
      access point is farther away and the server chooses to continue
      from the current pause point, it MUST include the "Next" policy in
      the Seek-Style header and adjust the Range header start point to
      the current pause point.
   First-Prior:  The first-prior policy will start delivery with the
      media unit that has a playout time first prior to the requested
      time.  For discrete media, that would only include media units
      that would still be rendered at the request time.  For continuous
      media, that is media that will be rendered during the requested
      start time of the range.
   Next:  The next media units after the provided start time of the
      range: for continuous framed media, that would mean the first next
      frame after the provided time and for discrete media, the first
      unit that is to be rendered after the provided time.  The main
      usage for this case is when the client knows it has all media up
      to a certain point and would like to continue delivery so that a
      complete uninterrupted media playback can be achieved.  An example
      of such a scenario would be switching from a broadcast/multicast
      delivery to a unicast-based delivery.  This policy MUST only be
      used on the client's explicit request.
   Please note that these expressed preferences exist for optimizing the
   startup time or the media quality.  The "Next" policy breaks the
   normal definition of the Range header to enable a client to request
   media with minimal overlap, although some may still occur for
   aggregated sessions.  RAP and First-Prior both fulfill the
   requirement of providing media from the requested range and forward.
   However, unless RAP is used, the media quality for many media codecs
   using predictive methods can be severely degraded unless additional
   data is available as, for example, already buffered, or through other
   side channels.
18.48.  Server
   The Server general-header field contains information about the
   software used by the origin server to create or handle the request.
   This field can contain multiple product tokens and comments
   identifying the server and any significant subproducts.  The product
   tokens are listed in order of their significance for identifying the
   application.
   Example:
   Server: PhonyServer/1.0
   If the response is being forwarded through a proxy, the proxy
   application MUST NOT modify the Server response-header.  Instead, it
   SHOULD include a Via field (Section 18.57).  If the response is
   generated by the proxy, the proxy application MUST return the Server
   response-header as previously returned by the server.
18.49.  Session
   The Session general-header field identifies an RTSP session.  An RTSP
   session is created by the server as a result of a successful SETUP
   request, and in the response, the session identifier is given to the
   client.  The RTSP session exists until destroyed by a TEARDOWN or a
   REDIRECT or is timed out by the server.
   The session identifier is chosen by the server (see Section 4.3) and
   MUST be returned in the SETUP response.  Once a client receives a
   session identifier, it MUST be included in any request related to
   that session.  This means that the Session header MUST be included in
   a request, using the following methods: PLAY, PAUSE, PLAY_NOTIFY and
   TEARDOWN.  It MAY be included in SETUP, OPTIONS, SET_PARAMETER,
   GET_PARAMETER, and REDIRECT.  It MUST NOT be included in DESCRIBE.
   The Session header MUST NOT be included in the following methods, if
   these requests are pipelined and if the session identifier is not yet
   known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and
   GET_PARAMETER.
   In an RTSP response, the session header MUST be included in methods,
   SETUP, PLAY, PAUSE, and PLAY_NOTIFY, and it MAY be included in
   methods TEARDOWN and REDIRECT.  If included in the request of the
   following methods it MUST also be included in the response: OPTIONS,
   GET_PARAMETER, and SET_PARAMETER.  It MUST NOT be included in
   DESCRIBE responses.
   Note that a session identifier identifies an RTSP session across
   transport sessions or connections.  RTSP requests for a given session
   can use different URIs (Presentation and media URIs).  Note, that
   there are restrictions depending on the session as to which URIs are
   acceptable for a given method.  However, multiple "user" sessions for
   the same URI from the same client will require use of different
   session identifiers.
      The session identifier is needed to distinguish several delivery
      requests for the same URI coming from the same client.
   The response 454 (Session Not Found) MUST be returned if the session
   identifier is invalid.
   The header MAY include a parameter for session timeout period.  If
   not explicitly provided, this value is set to 60 seconds.  As this
   affects how often session keep-alives are needed, values smaller than
   30 seconds are not recommended.  However, larger-than-default values
   can be useful in applications of RTSP that have inactive but
   established sessions for longer time periods.
      The 60-second value was chosen as the session timeout value as it
      results in keep-alive messages that are not too frequent and low
      sensitivity to variations in request/response timing.  If one
      reduces the timeout value to below 30 seconds, the corresponding
      request/response timeout becomes a significant part of the session
      timeout.  The 60-second value also allows for reasonably rapid
      recovery of committed server resources in case of client failure.
18.50.  Speed
   The Speed general-header field requests the server to deliver
   specific amounts of nominal media time per unit of delivery time,
   contingent on the server's ability and desire to serve the media
   stream at the given speed.  The client requests the delivery speed to
   be within a given range with a lower and upper bound.  The server
   SHALL deliver at the highest possible speed within the range, but not
   faster than the upper bound, for which the underlying network path
   can support the resulting transport data rates.  As long as any speed
   value within the given range can be provided, the server SHALL NOT
   modify the media quality.  Only if the server is unable to deliver
   media at the speed value provided by the lower bound shall it reduce
   the media quality.
   Implementation of the Speed functionality by the server is OPTIONAL.
   The server can indicate its support through a feature tag,
   play.speed.  The lack of a Speed header in the response is an
   indication of lack of support of this functionality.
   The speed parameter values are expressed as a positive decimal value,
   e.g., a value of 2.0 indicates that data is to be delivered twice as
   fast as normal.  A speed value of zero is invalid.  The range is
   specified in the form "lower bound - upper bound".  The lower-bound
   value may be smaller or equal to the upper bound.  All speeds may not
   be possible to support.  Therefore, the server MAY modify the
   requested values to the closest supported.  The actual supported
   speed MUST be included in the response.  However, note that the use
   cases may vary and that Speed value ranges such as 0.7-0.8, 0.3-2.0,
   1.0-2.5, and 2.5-2.5 all have their usages.
   Example:
     Speed: 1.0-2.5
   Use of this header changes the bandwidth used for data delivery.  It
   is meant for use in specific circumstances where delivery of the
   presentation at a higher or lower rate is desired.  The main use
   cases are buffer operations or local scale operations.  Implementers
   should keep in mind that bandwidth for the session may be negotiated
   beforehand (by means other than RTSP) and, therefore, renegotiation
   may be necessary.  To perform Speed operations, the server needs to
   ensure that the network path can support the resulting bitrate.
   Thus, the media transport needs to support feedback so that the
   server can react and adapt to the available bitrate.
18.51.  Supported
   The Supported general-header enumerates all the extensions supported
   by the client or server using feature tags.  The header carries the
   extensions supported by the message-sending client or server.  The
   Supported header MAY be included in any request.  When present in a
   request, the receiver MUST respond with its corresponding Supported
   header.  Note that the Supported header is also included in 4xx and
   5xx responses.
   The Supported header contains a list of feature tags, described in
   Section 4.5, that are understood by the client or server.  These
   feature tags are the ones the server or client supports in general
   and are not specific to the request resource.
   Example:
     C->S:  OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            User-Agent: PhonyClient/1.2
     S->C:  RTSP/2.0 200 OK
            Supported: bar, blech, baz
18.52.  Terminate-Reason
   The Terminate-Reason request-header allows the server, when sending a
   REDIRECT or TEARDOWN request, to provide a reason for the session
   termination and any additional information.  This specification
   identifies three reasons for Redirections and may be extended in the
   future:
   Server-Admin:  The server needs to be shut down for some
      administrative reason.
   Session-Timeout:  A client's session has been kept alive for extended
      periods of time and the server has determined that it needs to
      reclaim the resources associated with this session.
   Internal-Error  An internal error that is impossible to recover from
      has occurred, forcing the server to terminate the session.
   The Server may provide additional parameters containing information
   around the redirect.  This specification defines the following ones.
   time:  Provides a wallclock time when the server will stop providing
      any service.
   user-msg:  A UTF-8 text string with a message from the server to the
      user.  This message SHOULD be displayed to the user.
18.53.  Timestamp
   The Timestamp general-header describes when the agent sent the
   request.  The value of the timestamp is of significance only to the
   agent and may use any timescale.  The responding agent 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 can be used
   by the agent to compute the round-trip time to the responding agent
   so that it can adjust the timeout value for retransmissions when
   running over an unreliable protocol.  It also resolves retransmission
   ambiguities for unreliable transport of RTSP.
   Note that the present specification provides only for reliable
   transport of RTSP messages.  The Timestamp general-header is
   specified in case the protocol is extended in the future to use
   unreliable transport.
18.54.  Transport
   The Transport general-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.
   A Transport request-header MAY contain a list of transport options
   acceptable to the client, in the form of multiple transport
   specification entries.  Transport specifications are comma separated
   and listed in decreasing order of preference.  Each transport
   specification consists of a transport protocol identifier, followed
   by any number of parameters separated by semicolons.  A Transport
   request-header MAY contain multiple transport specifications using
   the same transport protocol identifier.  The server MUST return a
   Transport response-header in the response to indicate the values
   actually chosen, if any.  If no transport specification is supported,
   no transport header is returned and the response MUST use the status
   code 461 (Unsupported Transport) (Section 17.4.25).  In case more
   than one transport specification was present in the request, the
   server MUST return the single transport specification (transport-
   spec) that was actually chosen, if any.  The number of transport-spec
   entries is expected to be limited as the client will receive guidance
   on what configurations are possible from the presentation
   description.
   The Transport header MAY also be used in subsequent SETUP requests to
   change transport parameters.  A server MAY refuse to change
   parameters of an existing stream.
   The transport protocol identifier defines, for each transport
   specification, which transport protocol to use and any related rules.
   Each transport protocol identifier defines the parameters that are
   required to occur; additional optional parameters MAY occur.  This
   flexibility is provided as parameters may be different and provide
   different options to the RTSP agent.  A transport specification may
   only contain one of any given parameter within it.  A parameter
   consists of a name and optionally a value string.  Parameters MAY be
   given in any order.  Additionally, a transport specification may only
   contain either the unicast or the multicast transport type parameter.
   The transport protocol identifier, and all parameters, need to be
   understood in a transport specification; if not, the transport
   specification MUST be ignored.  An RTSP proxy of any type that uses
   or modifies the transport specification, e.g., access proxy or
   security proxy, MUST remove specifications with unknown parameters
   before forwarding the RTSP message.  If that results in no remaining
   transport specification, the proxy SHALL send a 461 (Unsupported
   Transport) (Section 17.4.25) response without any Transport header.
      The Transport header is restricted to describing a single media
      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.
   The general syntax for the transport protocol identifier is a list of
   slash-separated tokens:
   Value1/Value2/Value3...
   Which, for RTP transports, takes the form:
   RTP/profile/lower-transport.
   The default value for the "lower-transport" parameters is specific to
   the profile.  For RTP/AVP, the default is UDP.
   There are two different methods for how to specify where the media
   should be delivered for unicast transport:
   dest_addr:  The presence of this parameter and its values indicates
         the destination address or addresses (host address and port
         pairs for IP flows) necessary for the media transport.
   No dest_addr:  The lack of the dest_addr parameter indicates that the
         server MUST send media to the same address from which the RTSP
         messages originates.
   The choice of method for indicating where the media is to be
   delivered depends on the use case.  In some cases, the only allowed
   method will be to use no explicit address indication and have the
   server deliver media to the source of the RTSP messages.
   For multicast, there are several methods for specifying addresses,
   but they are different in how they work compared with unicast:
   dest_addr with client picked address:  The address and relevant
         parameters, like TTL (scope), for the actual multicast group to
         deliver the media to.  There are security implications
         (Section 21) with this method that need to be addressed because
         an RTSP server can be used as a DoS attacker on an existing
         multicast group.
   dest_addr using Session Description Information:  The information
         included in the transport header can all be coming from the
         session description, e.g., the SDP "c=" and "m=" lines.  This
         mitigates some of the security issues of the previous methods
         as it is the session provider that picks the multicast group
         and scope.  The client MUST include the information if it is
         available in the session description.
   No dest_addr:  The behavior when no explicit multicast group is
         present in a request is not defined.
   An RTSP proxy will need to take care.  If the media is not desired to
   be routed through the proxy, the proxy will need to introduce the
   destination indication.
   Below are the configuration parameters associated with transport:
   General parameters:
   unicast / multicast:  This parameter is a mutually exclusive
         indication of whether unicast or multicast delivery will be
         attempted.  One of the two values MUST be specified.  Clients
         that are capable of handling both unicast and multicast
         transmission need to indicate such capability by including two
         full transport-specs with separate parameters for each.
   layers:  The number of multicast layers to be used for this media
         stream.  The layers are sent to consecutive addresses starting
         at the dest_addr address.  If the parameter is not included, it
         defaults to a single layer.
   dest_addr:  A general destination address parameter that can contain
         one or more address specifications.  Each combination of
         protocol/profile/lower transport needs to have the format and
         interpretation of its address specification defined.  For
         RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a
         tuple containing a host address and port.  Note, only a single
         destination parameter per transport spec is intended.  The
         usage of multiple destinations to distribute a single media to
         multiple entities is unspecified.
         The client originating the RTSP request MAY specify the
         destination address of the stream recipient with the host
         address as part of the tuple.  When the destination address is
         specified, the recipient may be a different party than the
         originator of the request.  To avoid becoming the unwitting
         perpetrator of a remote-controlled DoS attack, a server MUST
         perform security checks (see Section 21.2.1) and SHOULD log
         such attempts before allowing the client to direct a media
         stream to a recipient address not chosen by the server.
         Implementations cannot rely on TCP as a reliable means of
         client identification.  If the server does not allow the host
         address part of the tuple to be set, it MUST return 463
         (Destination Prohibited).
         The host address part of the tuple MAY be empty, for example
         ":58044", in cases when it is desired to specify only the
         destination port.  Responses to requests including the
         Transport header with a dest_addr parameter SHOULD include the
         full destination address that is actually used by the server.
         The server MUST NOT remove address information that is already
         present in the request when responding, unless the protocol
         requires it.
   src_addr:  A general source address parameter that can contain one or
         more address specifications.  Each combination of
         protocol/profile/lower transport needs to have the format and
         interpretation of its address specification defined.  For
         RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a
         tuple containing a host address and port.
         This parameter MUST be specified by the server if it transmits
         media packets from an address other than the one RTSP messages
         are sent to.  This will allow the client to verify the source
         address and give it a destination address for its RTCP feedback
         packets, if RTP is used.  The address or addresses indicated in
         the src_addr parameter SHOULD be used both for the sending and
         receiving of the media stream's data packets.  The main reasons
         are threefold: First, indicating the port and source address(s)
         lets the receiver know where from the packets is expected to
         originate.  Second, traversal of NATs is greatly simplified
         when traffic is flowing symmetrically over a NAT binding.
         Third, certain NAT traversal mechanisms need to know to which
         address and port to send so-called "binding packets" from the
         receiver to the sender, thus creating an address binding in the
         NAT that the sender-to-receiver packet flow can use.
            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.
   mode: The mode parameter indicates the methods to be supported for
         this session.  The currently defined valid value is "PLAY".  If
         not provided, the default is "PLAY".  The "RECORD" value was
         defined in RFC 2326; in this specification, it is unspecified
         but reserved.  RECORD and other values may be specified in the
         future.
   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 14.  The argument provides the channel number to be
         used in the $ block (see Section 14) and MUST be present.  This
         parameter MAY be specified as an interval, e.g.,
         interleaved=4-5 in cases where the transport choice for the
         media stream requires it, e.g., for RTP with RTCP.  The channel
         number given in the request is only a guidance from the client
         to the server on what channel number(s) to use.  The server MAY
         set any valid channel number in the response.  The declared
         channels are bidirectional, so both end parties MAY send data
         on the given channel.  One example of such usage is the second
         channel used for RTCP, where both server and client send RTCP
         packets on the same channel.
            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.
   MIKEY:  This parameter is used in conjunction with transport
         specifications that can utilize MIKEY [RFC3830] for security
         context establishment.  So far, only the SRTP-based RTP
         profiles SAVP and SAVPF can utilize MIKEY, and this is defined
         in Appendix C.1.4.1.  This parameter can be included both in
         request and response messages.  The binary MIKEY message SHALL
         be Base64-encoded [RFC4648] before being included in the value
         part of the parameter, where the encoding adheres to the
         definition in Section 4 of RFC 4648 and where the padding bits
         are set to zero.
   Multicast-specific:
   ttl:  multicast time-to-live for IPv4.  When included in requests,
         the value indicates the TTL value that the client requests the
         server to use.  In a response, the value actually being used by
         the server is returned.  A server will need to consider what
         values that are reasonable and also the authority of the user
         to set this value.  Corresponding functions are not needed for
         IPv6 as the scoping is part of the IPv6 multicast address
         [RFC4291].
   RTP-specific:
   These parameters MAY only be used if the media-transport protocol is
   RTP.
   ssrc: The ssrc parameter, if included in a SETUP response, indicates
         the RTP SSRC [RFC3550] value(s) that will be used by the media
         server for RTP packets within the stream.  The values are
         expressed as a slash-separated sequence of SSRC values, each
         SSRC expressed as an eight-digit hexadecimal value.
         The ssrc parameter MUST NOT be specified in requests.  The
         functionality of specifying the ssrc parameter in a SETUP
         request is deprecated as it is incompatible with the
         specification of RTP [RFC3550].  If the parameter is included
         in the Transport header of a SETUP request, the server SHOULD
         ignore it, and choose appropriate SSRCs for the stream.  The
         server SHOULD set the ssrc parameter in the Transport header of
         the response.
   RTCP-mux:  Used to negotiate the usage of RTP and RTCP multiplexing
         [RFC5761] on a single underlying transport stream/flow.  The
         presence of this parameter in a SETUP request indicates the
         client's support and requires the server to use RTP and RTCP
         multiplexing.  The client SHALL only include one transport
         stream in the Transport header specification.  To provide the
         server with a choice between using RTP/RTCP multiplexing or
         not, two different transport header specifications must be
         included.
   The parameter setup and connection defined below MAY only be used if
   the media-transport protocol of the lower-level transport is
   connection oriented (such as TCP).  However, these parameters MUST
   NOT be used when interleaving data over the RTSP connection.
   setup:  Clients use the setup parameter on the Transport line in a
         SETUP request to indicate the roles it wishes to play in a TCP
         connection.  This parameter is adapted from [RFC4145].  The use
         of this parameter in RTP/AVP/TCP non-interleaved transport is
         discussed in Appendix C.2.2; the discussion below is limited to
         syntactic issues.  Clients may specify the following values for
         the setup parameter:
         active:  The client will initiate an outgoing connection.
         passive:  The client will accept an incoming connection.
         actpass:  The client is willing to accept an incoming
            connection or to initiate an outgoing connection.
         If a client does not specify a setup value, the "active" value
         is assumed.
         In response to a client SETUP request where the setup parameter
         is set to "active", a server's 2xx reply MUST assign the setup
         parameter to "passive" on the Transport header line.
         In response to a client SETUP request where the setup parameter
         is set to "passive", a server's 2xx reply MUST assign the setup
         parameter to "active" on the Transport header line.
         In response to a client SETUP request where the setup parameter
         is set to "actpass", a server's 2xx reply MUST assign the setup
         parameter to "active" or "passive" on the Transport header
         line.
         Note that the "holdconn" value for setup is not defined for
         RTSP use, and MUST NOT appear on a Transport line.
   connection:  Clients use the connection parameter in a transport
         specification part of the Transport header in a SETUP request
         to indicate the client's preference for either reusing an
         existing connection between client and server (in which case
         the client sets the "connection" parameter to "existing") or
         requesting the creation of a new connection between client and
         server (in which cast the client sets the "connection"
         parameter to "new").  Typically, clients use the "new" value
         for the first SETUP request for a URL, and "existing" for
         subsequent SETUP requests for a URL.
         If a client SETUP request assigns the "new" value to
         "connection", the server response MUST also assign the "new"
         value to "connection" on the Transport line.
         If a client SETUP request assigns the "existing" value to
         "connection", the server response MUST assign a value of
         "existing" or "new" to "connection" on the Transport line, at
         its discretion.
         The default value of "connection" is "existing", for all SETUP
         requests (initial and subsequent).
   The combination of transport protocol, profile and lower transport
   needs to be defined.  A number of combinations are defined in the
   Appendix C.
   Below is a usage example, showing a client advertising the capability
   to handle multicast or unicast, preferring multicast.  Since this is
   a unicast-only stream, the server responds with the proper transport
   parameters for unicast.
     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Transport: RTP/AVP;multicast;mode="PLAY",
               RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
               "192.0.2.5:3457";mode="PLAY"
           Accept-Ranges: npt, smpte, clock
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 302
           Date: Fri, 20 Dec 2013 10:20:32 +0000
           Session: rQi1hBrGlFdiYld241FxUO
           Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
              "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
              "192.0.2.224:6257";mode="PLAY"
           Accept-Ranges: npt
           Media-Properties: Random-Access=0.6, Dynamic,
                             Time-Limited=20081128T165900
18.55.  Unsupported
   The Unsupported response-header lists the features not supported by
   the responding RTSP agent.  In the case where the feature was
   specified via the Proxy-Require field (Section 18.37), if there is a
   proxy on the path between the client and the server, the proxy MUST
   send a response message with a status code of 551 (Option Not
   Supported).  The request MUST NOT be forwarded.
   See Section 18.43 for a usage example.
18.56.  User-Agent
   The User-Agent general-header field contains information about the
   user agent originating the request or producing a response.  This is
   for statistical purposes, the tracing of protocol violations, and
   automated recognition of user agents for the sake of tailoring
   responses to avoid particular user agent limitations.  User agents
   SHOULD include this field with requests.  The field can contain
   multiple product tokens and comments identifying the agent and any
   subproducts which form a significant part of the user agent.  By
   convention, the product tokens are listed in order of their
   significance for identifying the application.
   Example:
   User-Agent: PhonyClient/1.2
18.57.  Via
   The Via general-header field MUST be used by proxies to indicate the
   intermediate protocols and recipients between the user agent and the
   server on requests and between the origin server and the client on
   responses.  The field is intended to be used for tracking message
   forwards, avoiding request loops, and identifying the protocol
   capabilities of all senders along the request/response chain.
   Each of multiple values in the Via field represents each proxy that
   has forwarded the message.  Each recipient MUST append its
   information such that the end result is ordered according to the
   sequence of forwarding applications.  So messages originating with
   the client or server do not include the Via header.  The first proxy
   or other intermediate adds the header and its information into the
   field.  Any additional intermediate adds additional field-values.
   Resulting in the server seeing the chains of intermediates in a
   client-to-server request and the client seeing the full chain in the
   response message.
   Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by
   default, forward the names and ports of hosts within the private/
   protected region.  This information SHOULD only be propagated if
   explicitly enabled.  If not enabled, the via-received of any host
   behind the firewall/NAT SHOULD be replaced by an appropriate
   pseudonym for that host.
   For organizations that have strong privacy requirements for hiding
   internal structures, a proxy MAY combine an ordered subsequence of
   Via header field entries with identical sent-protocol values into a
   single such entry.  Applications MUST NOT combine entries that have
   different received-protocol values.
18.58.  WWW-Authenticate
   The WWW-Authenticate header is specified in [RFC7235]; its usage
   depends on the used authentication schemes, such as Digest [RFC7616]
   and Basic [RFC7617].  The WWW-Authenticate response-header field MUST
   be included in 401 (Unauthorized) response messages.  The field-value
   consists of at least one challenge that indicates the authentication
   scheme(s) and parameters applicable to the Request-URI.  This header
   MUST only be used in response messages related to client to server
   requests.
   The HTTP access authentication process is described in [RFC7235] with
   some clarification in Section 19.1.  User agents are advised to take
   special care in parsing the WWW-Authenticate field-value as it might
   contain more than one challenge, or if more than one WWW-Authenticate
   header field is provided, the contents of a challenge itself can
   contain a comma-separated list of authentication parameters.