Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7826

Real-Time Streaming Protocol Version 2.0

Pages: 318
Proposed Standard
Obsoletes:  2326
Part 7 of 13 – Pages 134 to 159
First   Prev   Next

Top   ToC   RFC7826 - Page 134   prevText

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.
Top   ToC   RFC7826 - Page 135

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://";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://";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.
Top   ToC   RFC7826 - Page 136
   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

   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].
Top   ToC   RFC7826 - Page 137
   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

      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
Top   ToC   RFC7826 - Page 138
   session context the request is related to.  The requester and
   responder will indicate their capabilities regarding Range formats

      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
Top   ToC   RFC7826 - Page 139
   [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
Top   ToC   RFC7826 - Page 140
   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.


     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
Top   ToC   RFC7826 - Page 141
   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

   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

   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.
Top   ToC   RFC7826 - Page 142
   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,
Top   ToC   RFC7826 - Page 143
         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
Top   ToC   RFC7826 - Page 144
   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.



   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://
Top   ToC   RFC7826 - Page 145
   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

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.
Top   ToC   RFC7826 - Page 146
   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
Top   ToC   RFC7826 - Page 147
   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

   As an example, if an RTSP client performs a DESCRIBE request on a
   given resource, e.g., "rtsp://
   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://") 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.
Top   ToC   RFC7826 - Page 148
   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.
Top   ToC   RFC7826 - Page 149
      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.
Top   ToC   RFC7826 - Page 150

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 format in RFC 1123 used by RTSP 1.0. Thus, implementations should use single spaces as separators, as recommended by RFC 5322, and support receiving the obsolete format.
Top   ToC   RFC7826 - Page 151
      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].
Top   ToC   RFC7826 - Page 152
   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

   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.
Top   ToC   RFC7826 - Page 153
   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.
Top   ToC   RFC7826 - Page 154

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
Top   ToC   RFC7826 - Page 155
   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

      Time-Progressing:  The media accessible progresses as wallclock
         time progresses.
Top   ToC   RFC7826 - Page 156

      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:

   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
Top   ToC   RFC7826 - Page 157
   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).
Top   ToC   RFC7826 - Page 158

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
Top   ToC   RFC7826 - Page 159
   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.

(page 159 continued on part 8)

Next Section