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.
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= 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. 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.
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. 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. 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.
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
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. 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.
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
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.
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.
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.
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.
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.
Further, note that the syntax allows for a comment to be added at the end of the date. 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. 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.
An example of the field is: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 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.
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.
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
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. 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).
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.