RFC 7826
Real-Time Streaming Protocol Version 2.0
16. Caching
In HTTP, request/response pairs are cached. RTSP differs significantly in that respect. Responses are not cacheable, with the exception of the presentation description returned by DESCRIBE. (Since the responses for anything but DESCRIBE and GET_PARAMETER do not return any data, caching is not really an issue for these requests.) However, it is desirable for the continuous media data, typically delivered out-of-band with respect to RTSP, to be cached, as well as the session description. On receiving a SETUP or PLAY request, a proxy ascertains whether it has an up-to-date copy of the continuous media content and its description. It can determine whether the copy is up to date by issuing a SETUP or DESCRIBE request, respectively, and comparing the Last-Modified header with that of the cached copy. If the copy is not up to date, it modifies the SETUP transport parameters as appropriate and forwards the request to the origin server. Subsequent control commands such as PLAY or PAUSE then pass the proxy unmodified. The proxy delivers the continuous media data to the client, while possibly making a local copy for later reuse. The exact allowed behavior of the cache is given by the cache-response directives described in Section 18.11. A cache MUST answer any DESCRIBE requests if it is currently serving the stream to the requester, as it is possible that low-level details of the stream description may have changed on the origin server. Note that an RTSP cache is of the "cut-through" variety. Rather than retrieving the whole resource from the origin server, the cache simply copies the streaming data as it passes by on its way to the client. Thus, it does not introduce additional latency. To the client, an RTSP proxy cache appears like a regular media server. To the media origin server, an RTSP proxy cache appears like a client. Just as an HTTP cache has to store the content type, content language, and so on for the objects it caches, a media cache has to store the presentation description. Typically, a cache eliminates all transport references (e.g., multicast information) from the presentation description, since these are independent of the data delivery from the cache to the client. Information on the encodings remains the same. If the cache is able to translate the cached media data, it would create a new presentation description with all the encoding possibilities it can offer.
16.1. Validation Model
When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. This is called "validating" the cache entry. To avoid having to pay the overhead of retransmitting the full response if the cached entry is good, and at the same time avoiding having to pay the overhead of an extra round trip if the cached entry is invalid, RTSP supports the use of conditional methods. The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request. The server then checks that validator against the current validator for the requested resource, and, if they match (see Section 16.1.3), it responds with a special status code (usually, 304 (Not Modified)) and no message body. Otherwise, it returns a full response (including message body). Thus, avoiding transmitting the full response if the validator matches and avoiding an extra round trip if it does not match. In RTSP, a conditional request looks exactly the same as a normal request for the same resource, except that it carries a special header (which includes the validator) that implicitly turns the method (usually DESCRIBE or SETUP) into a conditional. The protocol includes both positive and negative senses of cache- validating conditions. That is, it is possible to request that a method be performed either if and only if a validator matches or if and only if no validators match. Note: a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited by a cache directive (see Section 18.11). However, a cache cannot perform a conditional retrieval if it does not have a validator for the resource, which means it will not be refreshable after it expires.
Media streams that are being adapted based on the transport capacity between the server and the cache make caching more difficult. A server needs to consider how it views the caching of media streams that it adapts and potentially instruct any caches not to cache such streams.16.1.1. Last-Modified Dates
The Last-Modified header (Section 18.27) value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the cache entry was created after the Last-Modified time.16.1.2. Message Body Tag Cache Validators
The MTag response-header field-value, a message body tag, provides for an "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of RTSP-date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates. Message body tags are described in Section 4.616.1.3. Weak and Strong Validators
Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the message body (i.e., the presentation description) or any associated message body headers changes in any way, then the associated validator would change as well. If this is true, then this validator is a "strong validator". The Message body (i.e., the presentation description) or any associated message body headers is named an entity for a better understanding. However, there might be cases when a server prefers to change the validator only on semantically significant changes and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator". Message body tags are normally strong validators, but the protocol provides a mechanism to tag a message body tag as "weak". One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
Note: One example of a strong validator is an integer that is
incremented in stable storage every time an entity is changed.
An entity's modification time, if represented with one-second
resolution, could be a weak validator, since it is possible that
the resource might be modified twice during a single second.
Support for weak validators is optional. However, weak validators
allow for more efficient caching of equivalent objects.
A "use" of a validator is either when a client generates a request
and includes the validator in a validating header field or when a
server compares two validators.
Strong validators are usable in any context. Weak validators are
only usable in contexts that do not depend on exact equality of an
entity. For example, either kind is usable for a conditional
DESCRIBE of a full entity. However, only a strong validator is
usable for a subrange retrieval, since otherwise the client might end
up with an internally inconsistent entity.
Clients MAY issue DESCRIBE requests with either weak or strong
validators. Clients MUST NOT use weak validators in other forms of
requests.
The only function that RTSP defines on validators is comparison.
There are two validator comparison functions, depending on whether or
not the comparison context allows the use of weak validators:
o The strong comparison function: in order to be considered equal,
both validators MUST be identical in every way, and both MUST NOT
be weak.
o The weak comparison function: in order to be considered equal,
both validators MUST be identical in every way, but either or both
of them MAY be tagged as "weak" without affecting the result.
A message body tag is strong unless it is explicitly tagged as weak.
A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong,
using the following rules:
o The validator is being compared by an origin server to the actual
current validator for the entity and,
o That origin server reliably knows that the associated entity did
not change more than once during the second covered by the
presented validator.
OR
o The validator is about to be used by a client in an If-Modified-
Since, because the client has a cache entry for the associated
entity, and
o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the
Date value.
OR
o The validator is being compared by an intermediate cache to the
validator stored in its cache entry for the entity, and
o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the
Date value.
This method relies on the fact that if two different responses were
sent by the origin server during the same second, but both had the
same Last-Modified time, then at least one of those responses would
have a Date value equal to its Last-Modified time. The arbitrary
60-second limit guards against the possibility that the Date and
Last-Modified values are generated from different clocks or at
somewhat different times during the preparation of the response. An
implementation MAY use a value larger than 60 seconds, if it is
believed that 60 seconds is too short.
If a client wishes to perform a subrange retrieval on a value for
which it has only a Last-Modified time and no opaque validator, it
MAY do this only if the Last-Modified time is strong in the sense
described here.
16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates
This document adopts a set of rules and recommendations for origin
servers, clients, and caches regarding when various validator types
ought to be used, and for what purposes.
RTSP origin servers:
o SHOULD send a message body tag validator unless it is not feasible
to generate one.
o MAY send a weak message body tag instead of a strong message body
tag, if performance considerations support the use of weak message
body tags, or if it is unfeasible to send a strong message body
tag.
o SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that could
result from using this date in an If-Modified-Since header would
lead to serious problems.
In other words, the preferred behavior for an RTSP origin server is
to send both a strong message body tag and a Last-Modified value.
In order to be legal, a strong message body tag MUST change whenever
the associated entity value changes in any way. A weak message body
tag SHOULD change whenever the associated entity changes in a
semantically significant way.
Note: in order to provide semantically transparent caching, an
origin server MUST avoid reusing a specific strong message body
tag value for two different entities or reusing a specific weak
message body tag value for two semantically different entities.
Cache entries might persist for arbitrarily long periods,
regardless of expiration times, so it might be inappropriate to
expect that a cache will never again attempt to validate an entry
using a validator that it obtained at some point in the past.
RTSP clients:
o If a message body tag has been provided by the origin server, MUST
use that message body tag in any cache-conditional request (using
If-Match or If-None-Match).
o If only a Last-Modified value has been provided by the origin
server, SHOULD use that value in non-subrange cache-conditional
requests (using If-Modified-Since).
o If both a message body tag and a Last-Modified value have been
provided by the origin server, SHOULD use both validators in
cache-conditional requests.
An RTSP origin server, upon receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since
header) and one or more message body tags (e.g., in an If-Match,
If-None-Match, or If-Range header field) as cache validators, MUST
NOT return a response status of 304 (Not Modified) unless doing so is
consistent with all of the conditional header fields in the request.
Note: The general principle behind these rules is that RTSP
servers and clients should transmit as much non-redundant
information as is available in their responses and requests. RTSP
systems receiving this information will make the most conservative
assumptions about the validators they receive.
16.1.5. Non-validating Conditionals
The principle behind message body tags is that only the service
author knows the semantics of a resource well enough to select an
appropriate cache validation mechanism, and the specification of any
validator comparison function more complex than octet equality would
open up a can of worms. Thus, comparisons of any other headers are
never used for purposes of validating a cache entry.
16.2. Invalidation after Updates or Deletions
The effect of certain methods performed on a resource at the origin
server might cause one or more existing cache entries to become non-
transparently invalid. That is, although they might continue to be
"fresh," they do not accurately reflect what the origin server would
return for a new request on that resource.
There is no way for RTSP to guarantee that all such cache entries are
marked invalid. For example, the request that caused the change at
the origin server might not have gone through the proxy where a cache
entry is stored. However, several rules help reduce the likelihood
of erroneous behavior.
In this section, the phrase "invalidate an entity" means that the
cache will either remove all instances of that entity from its
storage or mark these as "invalid" and in need of a mandatory
revalidation before they can be returned in response to a subsequent
request.
Some RTSP methods MUST cause a cache to invalidate an entity. This
is either the entity referred to by the Request-URI or by the
Location or Content-Location headers (if present). These methods
are:
o DESCRIBE
o SETUP
In order to prevent DoS attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI. A cache that passes through requests for methods it does not understand SHOULD invalidate any entities referred to by the Request- URI.17. Status Code Definitions
Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are reused. See Table 4 in Section 8.1 for a listing of which status codes may be returned by which requests. All error messages, 4xx and 5xx, MAY return a body containing further information about the error.17.1. Informational 1xx
17.1.1. 100 Continue
The requesting agent SHOULD continue with its request. This interim response is used to inform the requesting agent that the initial part of the request has been received and has not yet been rejected by the responding agent. The requesting agent SHOULD continue by sending the remainder of the request or, if the request has already been completed, continue to wait for a final response (see Section 10.4). The responding agent MUST send a final response after the request has been completed.17.2. Success 2xx
This class of status code indicates that the agent's request was successfully received, understood, and accepted.17.2.1. 200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request.17.3. Redirection 3xx
The notation "3xx" indicates response codes from 300 to 399 inclusive that are meant for redirection. We use the notation "3rr" to indicate all 3xx codes used for redirection, i.e., excluding 304. The 304 response code appears here, rather than a 2xx response code, which would have been appropriate; 304 has also been used in RTSP 1.0 [RFC2326].
Within RTSP, redirection may be used for load-balancing or redirecting stream requests to a server topologically closer to the agent. Mechanisms to determine topological proximity are beyond the scope of this specification. A 3rr code MAY be used to respond to any request. The Location header MUST be included in any 3rr response. It is RECOMMENDED that they are used if necessary before a session is established, i.e., in response to DESCRIBE or SETUP. However, in cases where a server is not able to send a REDIRECT request to the agent, the server MAY need to resort to using 3rr responses to inform an agent with an established session about the need for redirecting the session. If a 3rr response is received for a request in relation to an established session, the agent SHOULD send a TEARDOWN request for the session and MAY reestablish the session using the resource indicated by the Location. If the Location header is used in a response, it MUST contain an absolute URI pointing out the media resource the agent is redirected to; the URI MUST NOT only contain the hostname. In the event that an unknown 3rr status code is received, the agent SHOULD behave as if a 302 response code had been received (Section 17.3.3).17.3.1. 300
The 300 response code is not used in RTSP 2.0.17.3.2. 301 Moved Permanently
The requested resource is moved permanently and resides now at the URI given by the Location header. The user agent SHOULD redirect automatically to the given URI. This response MUST NOT contain a message body. The Location header MUST be included in the response.17.3.3. 302 Found
The requested resource resides temporarily at the URI given by the Location header. This response is intended to be used for many types of temporary redirects, e.g., load balancing. It is RECOMMENDED that the server set the reason phrase to something more meaningful than "Found" in these cases. The Location header MUST be included in the response. The user agent SHOULD redirect automatically to the given URI. This response MUST NOT contain a message body.
This example shows a client being redirected to a different server:
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server
CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo
17.3.4. 303 See Other
This status code MUST NOT be used in RTSP 2.0. However, it was
allowed in RTSP 1.0 [RFC2326].
17.3.5. 304 Not Modified
If the agent has performed a conditional DESCRIBE or SETUP (see
Sections 18.25 and 18.26) and the requested resource has not been
modified, the server SHOULD send a 304 response. This response MUST
NOT contain a message body.
The response MUST include the following header fields:
o Date
o MTag or Content-Location, if the headers would have been sent in a
200 response to the same request.
o Expires and Cache-Control if the field-value might differ from
that sent in any previous response for the same variant.
This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is
unchanged. The MTag and If-Match header (Section 18.24) may be used
to link the DESCRIBE and SETUP in this manner.
17.3.6. 305 Use Proxy
The requested resource MUST be accessed through the proxy given by
the Location header that MUST be included. The Location header
field-value gives the URI of the proxy. The recipient is expected to
repeat this single request via the proxy. 305 responses MUST only be
generated by origin servers.
17.4. Client Error 4xx
17.4.1. 400 Bad Request
The request could not be understood by the agent due to malformed syntax. The agent SHOULD NOT repeat the request without modifications. If the request does not have a CSeq header, the agent MUST NOT include a CSeq in the response.17.4.2. 401 Unauthorized
The request requires user authentication using the HTTP authentication mechanism [RFC7235]. The usage of the error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The response is to include a WWW- Authenticate header (Section 18.58) field containing a challenge applicable to the requested resource. The agent can repeat the request with a suitable Authorization header field. If the request already included authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the message body that was given in the response, since that message body might include relevant diagnostic information.17.4.3. 402 Payment Required
This code is reserved for future use.17.4.4. 403 Forbidden
The agent understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. If the agent wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the message body. If the agent does not wish to make this information available to the agent, the status code 404 (Not Found) can be used instead.17.4.5. 404 Not Found
The agent has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the agent knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the agent does not wish to reveal exactly why the request has been refused, or when no other response is applicable.17.4.6. 405 Method Not Allowed
The method specified in the request is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. This status code is also to be used if a request attempts to use a method not indicated during SETUP.17.4.7. 406 Not Acceptable
The resource identified by the request is only capable of generating response message bodies that have content characteristics not acceptable according to the Accept headers sent in the request. The response SHOULD include a message body containing a list of available message body characteristics and location(s) from which the user or user agent can choose the one most appropriate. The message body format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.17.4.8. 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized) (Section 17.4.2), but it indicates that the client must first authenticate itself with the proxy. The usage of this error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The proxy MUST return a Proxy-Authenticate header field (Section 18.34) containing a challenge applicable to the proxy for the requested resource.17.4.9. 408 Request Timeout
The agent did not produce a request within the time that the agent was prepared to wait. The agent MAY repeat the request without modifications at any later time.
17.4.10. 410 Gone
The requested resource is no longer available at the server and the forwarding address is not known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise. The 410 response is primarily intended to assist the task of repository maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the owner of the server.17.4.11. 412 Precondition Failed
The precondition given in one or more of the 'if-' request-header fields evaluated to false when it was tested on the agent. See these sections for the 'if-' headers: If-Match Section 18.24, If-Modified- Since Section 18.25, and If-None-Match Section 18.26. This response code allows the agent to place preconditions on the current resource meta-information (header field data) and, thus, prevent the requested method from being applied to a resource other than the one intended.17.4.12. 413 Request Message Body Too Large
The agent is refusing to process a request because the request message body is larger than the agent is willing or able to process. The agent MAY close the connection to prevent the requesting agent from continuing the request. If the condition is temporary, the agent SHOULD include a Retry-After header field to indicate that it is temporary and after what time the requesting agent MAY try again.17.4.13. 414 Request-URI Too Long
The responding agent is refusing to service the request because the Request-URI is longer than the agent is willing to interpret. This rare condition is only likely to occur when an agent has used a request with long query information, when the agent has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the agent is under attack
by an agent attempting to exploit security holes present in some agents using fixed-length buffers for reading or manipulating the Request-URI.17.4.14. 415 Unsupported Media Type
The server is refusing to service the request because the message body of the request is in a format not supported by the requested resource for the requested method.17.4.15. 451 Parameter Not Understood
The recipient of the request does not support one or more parameters contained in the request. When returning this error message the agent SHOULD return a message body containing the offending parameter(s).17.4.16. 452 Illegal Conference Identifier
This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].17.4.17. 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. This may, for example, be the result of a resource reservation failure.17.4.18. 454 Session Not Found
The RTSP session identifier in the Session header is missing, is invalid, or has timed out.17.4.19. 455 Method Not Valid in This State
The agent cannot process this request in its current state. The response MUST contain an Allow header to make error recovery possible.17.4.20. 456 Header Field Not Valid for Resource
The targeted agent could not act on a required request-header. For example, if PLAY request contains the Range header field but the stream does not allow seeking. This error message may also be used for specifying when the time format in Range is impossible for the resource. In that case, the Accept-Ranges header MUST be returned to inform the agent of which formats are allowed.
17.4.21. 457 Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the presentation.17.4.22. 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not modified. When returning this error message, the sender SHOULD return a message body containing the offending parameter(s).17.4.23. 459 Aggregate Operation Not Allowed
The requested method may not be applied on the URI in question since it is an aggregate (presentation) URI. The method may be applied on a media URI.17.4.24. 460 Only Aggregate Operation Allowed
The requested method may not be applied on the URI in question since it is not an aggregate control (presentation) URI. The method may be applied on the aggregate control URI.17.4.25. 461 Unsupported Transport
The Transport field did not contain a supported transport specification.17.4.26. 462 Destination Unreachable
The data transmission channel could not be established because the agent address could not be reached. This error will most likely be the result of an agent attempt to place an invalid dest_addr parameter in the Transport field.17.4.27. 463 Destination Prohibited
The data transmission channel was not established because the server prohibited access to the agent address. This error is most likely the result of an agent attempt to redirect media traffic to another destination with a dest_addr parameter in the Transport header.
17.4.28. 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet ready for carrying data. However, the responding agent still expects that the data transmission channel will be established at some point in time. Note, however, that this may result in a permanent failure like 462 (Destination Unreachable). An example of when this error may occur is in the case in which a client sends a PLAY request to a server prior to ensuring that the TCP connections negotiated for carrying media data were successfully established (in violation of this specification). The server would use this error code to indicate that the requested action could not be performed due to the failure of completing the connection establishment.17.4.29. 465 Notification Reason Unknown
This indicates that the client has received a PLAY_NOTIFY (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to the client.17.4.30. 466 Key Management Error
This indicates that there has been an error in a Key Management function used in conjunction with a request. For example, usage of Multimedia Internet KEYing (MIKEY) [RFC3830] according to Appendix C.1.4.1 may result in this error.17.4.31. 470 Connection Authorization Required
The secured connection attempt needs user or client authorization before proceeding. The next hop's certificate is included in this response in the Accept-Credentials header.17.4.32. 471 Connection Credentials Not Accepted
When performing a secure connection over multiple connections, an intermediary has refused to connect to the next hop and carry out the request due to unacceptable credentials for the used policy.17.4.33. 472 Failure to Establish Secure Connection
A proxy fails to establish a secure connection to the next-hop RTSP agent. This is primarily caused by a fatal failure at the TLS handshake, for example, due to the agent not accepting any cipher suites.
17.5. Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. The server SHOULD include a message body containing an explanation of the error situation and whether it is a temporary or permanent condition. User agents SHOULD display any included message body to the user. These response codes are applicable to any request method.17.5.1. 500 Internal Server Error
The agent encountered an unexpected condition that prevented it from fulfilling the request.17.5.2. 501 Not Implemented
The agent does not support the functionality required to fulfill the request. This is the appropriate response when the agent does not recognize the request method and is not capable of supporting it for any resource.17.5.3. 502 Bad Gateway
The agent, while acting as a gateway or proxy, received an invalid response from the upstream agent it accessed in attempting to fulfill the request.17.5.4. 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given, in the Retry-After header. Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the transport connection. The response scope is dependent on the request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was not session specific or intended to form an RTSP session, it applies to the RTSP server identified by the hostname in the Request-URI.
17.5.5. 504 Gateway Timeout
The agent, while acting as a proxy, did not receive a timely response from the upstream agent specified by the URI or some other auxiliary server (e.g., DNS) that it needed to access in attempting to complete the request.17.5.6. 505 RTSP Version Not Supported
The agent does not support, or refuses to support, the RTSP version that was used in the request message. The agent is indicating that it is unable or unwilling to complete the request using the same major version as the agent other than with this error message. The response SHOULD contain a message body describing why that version is not supported and what other protocols are supported by that agent.17.5.7. 551 Option Not Supported
A feature tag given in the Require or the Proxy-Require fields was not supported. The Unsupported header MUST be returned stating the feature for which there is no support.17.5.8. 553 Proxy Unavailable
The proxy is currently unable to handle the request due to a temporary overloading or maintenance of the proxy. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given in the Retry-After header. Note: The existence of the 553 status code does not imply that a proxy must use it when becoming overloaded. Some proxies may wish to simply refuse the connection. The response scope is dependent on the Request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was non- session specific or intended to form an RTSP session, it applies to all such requests to this proxy.
18. Header Field Definitions
+---------------+----------------+--------+---------+------+ | method | direction | object | acronym | Body | +---------------+----------------+--------+---------+------+ | DESCRIBE | C -> S | P,S | DES | r | | | | | | | | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | | | | | | | | OPTIONS | C -> S, S -> C | P,S | OPT | | | | | | | | | PAUSE | C -> S | P,S | PSE | | | | | | | | | PLAY | C -> S | P,S | PLY | | | | | | | | | PLAY_NOTIFY | S -> C | P,S | PNY | R | | | | | | | | REDIRECT | S -> C | P,S | RDR | | | | | | | | | SETUP | C -> S | S | STP | | | | | | | | | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | | | | | | | | TEARDOWN | C -> S | P,S | TRD | | | | | | | | | | S -> C | P | TRD | | +---------------+----------------+--------+---------+------+ This table is an overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. "Body" denotes if a method is allowed to carry body and in which direction; R = request, r=response. Note: All error messages for statuses 4xx and 5xx are allowed to carry a body. Table 8: Overview of RTSP Methods The general syntax for header fields is covered in Section 5.2. This section lists the full set of header fields along with notes on meaning and usage. The syntax definitions for header fields are present in Section 20.2.3. Examples of each header field are given. Information about header fields in relation to methods and proxy processing is summarized in Figures 2, 3, 4, and 5.
The "where" column describes the request and response types in which
the header field can be used. Values in this column are:
R: header field may only appear in requests;
r: header field may only appear in responses;
2xx, 4xx, etc.: numerical value or range indicates response codes
with which the header field can be used;
c: header field is copied from the request to the
response.
G: header field is a general-header and may be present
in both requests and responses.
Note: General headers do not always use the "G" value in the "where"
column. This is due to differences when the header may be applied in
requests compared to responses. When such differences exist, they
are expressed using two different rows: one with "where" being "R"
and one with it being "r".
The "proxy" column describes the operations a proxy may perform on a
header field. An empty proxy column indicates that the proxy MUST
NOT make any changes to that header, all allowed operations are
explicitly stated:
a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value.
d: A proxy can delete a header field-value.
r: A proxy needs to be able to read the header field; thus, this
header field cannot be encrypted.
The rest of the columns relate to the presence of a header field in a
method. The method names when abbreviated, are according to Table 8:
c: Conditional; requirements on the header field depend on the
context of the message.
m: The header field is mandatory.
m*: The header field SHOULD be sent, but agents need to be prepared
to receive messages without that header field.
o: The header field is optional.
*: The header field MUST be present if the message body is not
empty. See Sections 18.17, 18.19 and 5.3 for details.
-: The header field is not applicable.
"Optional" means that an agent MAY include the header field in a
request or response. The agent behavior when receiving such headers
varies; for some, it may ignore the header field. In other cases, it
is a request to process the header. This is regulated by the method
and header descriptions. Examples of headers that require processing
are the Require and Proxy-Require header fields discussed in Sections
18.43 and 18.37. A "mandatory" header field MUST be present in a
request, and it MUST be understood by the agent receiving the
request. A mandatory response-header field MUST be present in the
response, and the header field MUST be understood by the processing
the response. "Not applicable" means that the header field MUST NOT
be present in a request. If one is placed in a request by mistake,
it MUST be ignored by the agent receiving the request. Similarly, a
header field labeled "not applicable" for a response means that the
agent MUST NOT place the header field in the response, and the agent
MUST ignore the header field in the response.
An RTSP agent MUST ignore extension headers that are not understood.
The From and Location header fields contain a URI. If the URI
contains a comma (') or semicolon (;), the URI MUST be enclosed in
double quotes ("). Any URI parameters are contained within these
quotes. If the URI is not enclosed in double quotes, any semicolon-
delimited parameters are header-parameters, not URI parameters.
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - |
| Accept- | R | rm | o | o | o | o | o | o |
| Credentials | | | | | | | | |
| Accept-Encoding | R | r | o | - | - | - | - | - |
| Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Ranges | G | r | - | - | m | - | - | - |
| Accept-Ranges | 456 | r | - | - | - | m | - | - |
| Allow | r | am | c | c | c | - | - | - |
| Allow | 405 | am | m | m | m | m | m | m |
| Authentication- | r | | o | o | o | o | o | o/- |
| Info | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o/- |
| Bandwidth | R | | o | o | o | o | - | - |
| Blocksize | R | | o | - | o | o | - | - |
| Cache-Control | G | r | o | - | o | - | - | - |
| Connection | G | ad | o | o | o | o | o | o |
| Connection- | 470, | ar | o | o | o | o | o | o |
| Credentials | 407 | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - |
| Content-Base | 4xx, | | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - |
| Content-Encoding | r | r | o | - | - | - | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Language | R | r | - | - | - | - | - | - |
| Content-Language | r | r | o | - | - | - | - | - |
| Content-Language | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | 4xx, | r | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Type | r | r | * | - | - | - | - | - |
| Content-Type | 4xx, | ar | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| CSeq | Gc | rm | m | m | m | m | m | m |
| Date | G | am | o/*| o/*| o/* | o/* | o/* | o/* |
| Expires | r | r | o | - | o | - | - | - |
| From | R | r | o | o | o | o | o | o |
| If-Match | R | r | - | - | o | - | - | - |
| If-Modified-Since | R | r | o | - | o | - | - | - |
| If-None-Match | R | r | o | - | o | - | - | - |
| Last-Modified | r | r | o | - | o | - | - | - | | Location | 3rr | | m | m | m | m | m | m | +-------------------+------+------+----+----+-----+-----+-----+-----+ | Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD | +-------------------+------+------+----+----+-----+-----+-----+-----+ Figure 2: Overview of RTSP Header Fields (A-L) Related to Methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Media-Properties | r | | - | - | m | o | o | - |
| Media-Range | r | | - | - | c | c | c | - |
| MTag | r | r | o | - | o | - | - | - |
| Pipelined- | G | amd | - | o | o | o | o | o |
| Requests | | r | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | |
| Proxy- | r | amd | o | o | o | o | o | o/- |
| Authentication- | | r | | | | | | |
| Info | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o |
| Authorization | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | o | o | o |
| Proxy-Require | r | r | c | c | c | c | c | c |
| Proxy-Supported | R | amr | c | c | c | c | c | c |
| Proxy-Supported | r | | c | c | c | c | c | c |
| Public | r | amr | - | m | - | - | - | - |
| Public | 501 | amr | m | m | m | m | m | m |
| Range | R | | - | - | - | o | - | - |
| Range | r | | - | - | c | m | m | - |
| Referrer | R | | o | o | o | o | o | o |
| Request-Status | R | | - | - | - | - | - | - |
| Require | R | | o | o | o | o | o | o |
| Retry-After | 3rr,503 | | o | o | o | o | o | - |
| | ,553 | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - |
| RTP-Info | r | | - | - | c | c | - | - |
| Scale | R | r | - | - | - | o | - | - |
| Scale | r | amr | - | - | c | c | c | - |
| Seek-Style | R | | - | - | - | o | - | - |
| Seek-Style | r | | - | - | - | m | - | - |
| Server | R | r | - | o | - | - | - | o |
| Server | r | r | o | o | o | o | o | o |
| Session | R | r | - | o | o | m | m | m |
| Session | r | r | - | c | m | m | m | o |
| Speed | R | admr| - | - | - | o | - | - |
| Speed | r | admr| - | - | - | c | - | - |
| Supported | R | r | o | o | o | o | o | o |
| Supported | r | r | c | c | c | c | c | c |
| Terminate-Reason | R | r | - | - | - | - | - | -/o |
| Timestamp | R | admr| o | o | o | o | o | o |
| Timestamp | c | admr| m | m | m | m | m | m |
| Transport | G | mr | - | - | m | - | - | - |
| Unsupported | r | | c | c | c | c | c | c |
| User-Agent | R | | m* | m* | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c | c | c | | Via | r | amr | c | c | c | c | c | c | | WWW-Authenticate | 401 | | m | m | m | m | m | m | +------------------+---------+-----+----+----+----+-----+-----+-----+ | Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD | +------------------+---------+-----+----+----+----+-----+-----+-----+ Figure 3: Overview of RTSP Header Fields (M-W) Related to Methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Accept-Credentials | R | rm | o | o | o | - |
| Accept-Encoding | R | r | o | o | o | - |
| Accept-Language | R | r | o | o | o | - |
| Accept-Ranges | G | rm | o | - | - | - |
| Allow | 405 | amr | m | m | m | m |
| Authentication-Info | r | | o/- | o/- | - | - |
| Authorization | R | | o | o | o | - |
| Bandwidth | R | | - | o | - | - |
| Blocksize | R | | - | o | - | - |
| Cache-Control | G | r | o | o | - | - |
| Connection | G | | o | o | o | o |
| Connection-Credentials | 470, | ar | o | o | o | - |
| | 407 | | | | | |
| Content-Base | R | | o | o | - | o |
| Content-Base | r | | o | o | - | - |
| Content-Base | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Encoding | R | r | o | o | - | o |
| Content-Encoding | r | r | o | o | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Language | R | r | o | o | - | o |
| Content-Language | r | r | o | o | - | - |
| Content-Language | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Length | R | r | * | * | - | * |
| Content-Length | r | r | * | * | - | - |
| Content-Length | 4xx, | r | * | * | * | * |
| | 5xx | | | | | |
| Content-Location | R | | o | o | - | o |
| Content-Location | r | | o | o | - | - |
| Content-Location | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Type | R | | * | * | - | * |
| Content-Type | r | | * | * | - | - |
| Content-Type | 4xx, | | * | * | * | * |
| | 5xx | | | | | |
| CSeq | R,c | mr | m | m | m | m |
| Date | R | a | o/* | o/* | m | o/* |
| Date | r | am | o/* | o/* | o/* | o/* |
| Expires | r | r | - | - | - | - |
| From | R | r | o | o | o | - |
| If-Match | R | r | - | - | - | - |
| If-Modified-Since | R | am | o | - | - | - |
| If-None-Match | R | am | o | - | - | - |
| Last-Modified | R | r | - | - | - | - | | Last-Modified | r | r | o | - | - | - | | Location | 3rr | | m | m | m | - | | Location | R | | - | - | m | - | +---------------------------+-------+-------+-----+-----+-----+-----+ | Header | Where | Proxy | GPR | SPR | RDR | PNY | +---------------------------+-------+-------+-----+-----+-----+-----+ Figure 4: Overview of RTSP Header Fields (A-L) Related to Methods GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Media-Properties | R | amr | o | - | - | c |
| Media-Properties | r | mr | c | - | - | - |
| Media-Range | R | | o | - | - | c |
| Media-Range | r | | c | - | - | - |
| MTag | r | r | o | - | - | - |
| Notify-Reason | R | | - | - | - | m |
| Pipelined-Requests | R | amdr | o | o | - | - |
| Proxy-Authenticate | 407 | amdr | m | m | m | - |
| Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - |
| Proxy-Authorization | R | amdr | o | o | o | - |
| Proxy-Require | R | ar | o | o | o | - |
| Proxy-Supported | R | amr | c | c | c | - |
| Proxy-Supported | r | | c | c | c | - |
| Public | 501 | admr | m | m | m | - |
| Range | R | | o | - | - | m |
| Range | r | | c | - | - | - |
| Referrer | R | | o | o | o | - |
| Request-Status | R | mr | - | - | - | c |
| Require | R | r | o | o | o | o |
| Retry-After | 3rr,503,| | o | o | - | - |
| | 553 | | | | | |
| Retry-After | 413 | | o | o | - | - |
| RTP-Info | R | r | o | - | - | C |
| RTP-Info | r | r | c | - | - | - |
| Scale | G | | c | - | c | c |
| Seek-Style | G | | - | - | - | - |
| Server | R | r | o | o | o | o |
| Server | r | r | o | o | - | - |
| Session | R | r | o | o | o | m |
| Session | r | r | c | c | o | m |
| Speed | G | | - | - | - | - |
| Supported | R | r | o | o | o | - |
| Supported | r | r | c | c | c | - |
| Terminate-Reason | R | r | - | - | m | - |
| Timestamp | R | adrm | o | o | o | o |
| Timestamp | c | adrm | m | m | m | m |
| Transport | G | mr | - | - | - | - |
| Unsupported | r | arm | c | c | c | c |
| User-Agent | R | r | m* | m* | - | - |
| User-Agent | r | r | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c |
| Via | r | amr | c | c | c | c | | WWW-Authenticate | 401 | | m | m | m | - | +---------------------------+---------+-------+-----+-----+-----+-----+ | Header | Where | Proxy | GPR | SPR | RDR | PNY | +---------------------------+---------+-------+-----+-----+-----+-----+ Figure 5: Overview of RTSP Header Fields (M-W) Related to Methods GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY
(page 134 continued on part 7)
