Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7826

Real-Time Streaming Protocol Version 2.0

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

Top   ToC   RFC7826 - Page 106   prevText

16. Caching

In HTTP, request/response pairs are cached. RTSP differs significantly in that respect. Responses are not cacheable, with the exception of the presentation description returned by DESCRIBE. (Since the responses for anything but DESCRIBE and GET_PARAMETER do not return any data, caching is not really an issue for these requests.) However, it is desirable for the continuous media data, typically delivered out-of-band with respect to RTSP, to be cached, as well as the session description. On receiving a SETUP or PLAY request, a proxy ascertains whether it has an up-to-date copy of the continuous media content and its description. It can determine whether the copy is up to date by issuing a SETUP or DESCRIBE request, respectively, and comparing the Last-Modified header with that of the cached copy. If the copy is not up to date, it modifies the SETUP transport parameters as appropriate and forwards the request to the origin server. Subsequent control commands such as PLAY or PAUSE then pass the proxy unmodified. The proxy delivers the continuous media data to the client, while possibly making a local copy for later reuse. The exact allowed behavior of the cache is given by the cache-response directives described in Section 18.11. A cache MUST answer any DESCRIBE requests if it is currently serving the stream to the requester, as it is possible that low-level details of the stream description may have changed on the origin server. Note that an RTSP cache is of the "cut-through" variety. Rather than retrieving the whole resource from the origin server, the cache simply copies the streaming data as it passes by on its way to the client. Thus, it does not introduce additional latency. To the client, an RTSP proxy cache appears like a regular media server. To the media origin server, an RTSP proxy cache appears like a client. Just as an HTTP cache has to store the content type, content language, and so on for the objects it caches, a media cache has to store the presentation description. Typically, a cache eliminates all transport references (e.g., multicast information) from the presentation description, since these are independent of the data delivery from the cache to the client. Information on the encodings remains the same. If the cache is able to translate the cached media data, it would create a new presentation description with all the encoding possibilities it can offer.
Top   ToC   RFC7826 - Page 107

16.1. Validation Model

When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. This is called "validating" the cache entry. To avoid having to pay the overhead of retransmitting the full response if the cached entry is good, and at the same time avoiding having to pay the overhead of an extra round trip if the cached entry is invalid, RTSP supports the use of conditional methods. The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request. The server then checks that validator against the current validator for the requested resource, and, if they match (see Section 16.1.3), it responds with a special status code (usually, 304 (Not Modified)) and no message body. Otherwise, it returns a full response (including message body). Thus, avoiding transmitting the full response if the validator matches and avoiding an extra round trip if it does not match. In RTSP, a conditional request looks exactly the same as a normal request for the same resource, except that it carries a special header (which includes the validator) that implicitly turns the method (usually DESCRIBE or SETUP) into a conditional. The protocol includes both positive and negative senses of cache- validating conditions. That is, it is possible to request that a method be performed either if and only if a validator matches or if and only if no validators match. Note: a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited by a cache directive (see Section 18.11). However, a cache cannot perform a conditional retrieval if it does not have a validator for the resource, which means it will not be refreshable after it expires.
Top   ToC   RFC7826 - Page 108
   Media streams that are being adapted based on the transport capacity
   between the server and the cache make caching more difficult.  A
   server needs to consider how it views the caching of media streams
   that it adapts and potentially instruct any caches not to cache such
   streams.

16.1.1. Last-Modified Dates

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

16.1.2. Message Body Tag Cache Validators

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

16.1.3. Weak and Strong Validators

Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the message body (i.e., the presentation description) or any associated message body headers changes in any way, then the associated validator would change as well. If this is true, then this validator is a "strong validator". The Message body (i.e., the presentation description) or any associated message body headers is named an entity for a better understanding. However, there might be cases when a server prefers to change the validator only on semantically significant changes and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator". Message body tags are normally strong validators, but the protocol provides a mechanism to tag a message body tag as "weak". One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
Top   ToC   RFC7826 - Page 109
      Note: One example of a strong validator is an integer that is
      incremented in stable storage every time an entity is changed.

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

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

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

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

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

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

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

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

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

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

   o  The validator is being compared by an origin server to the actual
      current validator for the entity and,
Top   ToC   RFC7826 - Page 110
   o  That origin server reliably knows that the associated entity did
      not change more than once during the second covered by the
      presented validator.

   OR

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

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

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

   OR

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

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

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

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

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

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

This document adopts a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types ought to be used, and for what purposes.
Top   ToC   RFC7826 - Page 111
   RTSP origin servers:

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

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

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

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

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

   RTSP clients:

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

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

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

   An RTSP origin server, upon receiving a conditional request that
   includes both a Last-Modified date (e.g., in an If-Modified-Since
   header) and one or more message body tags (e.g., in an If-Match,
Top   ToC   RFC7826 - Page 112
   If-None-Match, or If-Range header field) as cache validators, MUST
   NOT return a response status of 304 (Not Modified) unless doing so is
   consistent with all of the conditional header fields in the request.

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

16.1.5. Non-validating Conditionals

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

16.2. Invalidation after Updates or Deletions

The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non- transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource. There is no way for RTSP to guarantee that all such cache entries are marked invalid. For example, the request that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior. In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from its storage or mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request. Some RTSP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI or by the Location or Content-Location headers (if present). These methods are: o DESCRIBE o SETUP
Top   ToC   RFC7826 - Page 113
   In order to prevent DoS attacks, an invalidation based on the URI in
   a Location or Content-Location header MUST only be performed if the
   host part is the same as in the Request-URI.

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

17. Status Code Definitions

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

17.1. Informational 1xx

17.1.1. 100 Continue

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

17.2. Success 2xx

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

17.2.1. 200 OK

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

17.3. Redirection 3xx

The notation "3xx" indicates response codes from 300 to 399 inclusive that are meant for redirection. We use the notation "3rr" to indicate all 3xx codes used for redirection, i.e., excluding 304. The 304 response code appears here, rather than a 2xx response code, which would have been appropriate; 304 has also been used in RTSP 1.0 [RFC2326].
Top   ToC   RFC7826 - Page 114
   Within RTSP, redirection may be used for load-balancing or
   redirecting stream requests to a server topologically closer to the
   agent.  Mechanisms to determine topological proximity are beyond the
   scope of this specification.

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

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

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

17.3.1. 300

The 300 response code is not used in RTSP 2.0.

17.3.2. 301 Moved Permanently

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

17.3.3. 302 Found

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

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

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

17.3.4. 303 See Other

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

17.3.5. 304 Not Modified

If the agent has performed a conditional DESCRIBE or SETUP (see Sections 18.25 and 18.26) and the requested resource has not been modified, the server SHOULD send a 304 response. This response MUST NOT contain a message body. The response MUST include the following header fields: o Date o MTag or Content-Location, if the headers would have been sent in a 200 response to the same request. o Expires and Cache-Control if the field-value might differ from that sent in any previous response for the same variant. This response is independent for the DESCRIBE and SETUP requests. That is, a 304 response to DESCRIBE does NOT imply that the resource content is unchanged (only the session description) and a 304 response to SETUP does NOT imply that the resource description is unchanged. The MTag and If-Match header (Section 18.24) may be used to link the DESCRIBE and SETUP in this manner.

17.3.6. 305 Use Proxy

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

17.4. Client Error 4xx

17.4.1. 400 Bad Request

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

17.4.2. 401 Unauthorized

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

17.4.3. 402 Payment Required

This code is reserved for future use.

17.4.4. 403 Forbidden

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

17.4.5. 404 Not Found

The agent has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the agent knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
Top   ToC   RFC7826 - Page 117
   This status code is commonly used when the agent does not wish to
   reveal exactly why the request has been refused, or when no other
   response is applicable.

17.4.6. 405 Method Not Allowed

The method specified in the request is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. This status code is also to be used if a request attempts to use a method not indicated during SETUP.

17.4.7. 406 Not Acceptable

The resource identified by the request is only capable of generating response message bodies that have content characteristics not acceptable according to the Accept headers sent in the request. The response SHOULD include a message body containing a list of available message body characteristics and location(s) from which the user or user agent can choose the one most appropriate. The message body format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection. If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

17.4.8. 407 Proxy Authentication Required

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

17.4.9. 408 Request Timeout

The agent did not produce a request within the time that the agent was prepared to wait. The agent MAY repeat the request without modifications at any later time.
Top   ToC   RFC7826 - Page 118

17.4.10. 410 Gone

The requested resource is no longer available at the server and the forwarding address is not known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise. The 410 response is primarily intended to assist the task of repository maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the owner of the server.

17.4.11. 412 Precondition Failed

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

17.4.12. 413 Request Message Body Too Large

The agent is refusing to process a request because the request message body is larger than the agent is willing or able to process. The agent MAY close the connection to prevent the requesting agent from continuing the request. If the condition is temporary, the agent SHOULD include a Retry-After header field to indicate that it is temporary and after what time the requesting agent MAY try again.

17.4.13. 414 Request-URI Too Long

The responding agent is refusing to service the request because the Request-URI is longer than the agent is willing to interpret. This rare condition is only likely to occur when an agent has used a request with long query information, when the agent has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the agent is under attack
Top   ToC   RFC7826 - Page 119
   by an agent attempting to exploit security holes present in some
   agents using fixed-length buffers for reading or manipulating the
   Request-URI.

17.4.14. 415 Unsupported Media Type

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

17.4.15. 451 Parameter Not Understood

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

17.4.16. 452 Illegal Conference Identifier

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

17.4.17. 453 Not Enough Bandwidth

The request was refused because there was insufficient bandwidth. This may, for example, be the result of a resource reservation failure.

17.4.18. 454 Session Not Found

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

17.4.19. 455 Method Not Valid in This State

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

17.4.20. 456 Header Field Not Valid for Resource

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

17.4.21. 457 Invalid Range

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

17.4.22. 458 Parameter Is Read-Only

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

17.4.23. 459 Aggregate Operation Not Allowed

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

17.4.24. 460 Only Aggregate Operation Allowed

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

17.4.25. 461 Unsupported Transport

The Transport field did not contain a supported transport specification.

17.4.26. 462 Destination Unreachable

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

17.4.27. 463 Destination Prohibited

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

17.4.28. 464 Data Transport Not Ready Yet

The data transmission channel to the media destination is not yet ready for carrying data. However, the responding agent still expects that the data transmission channel will be established at some point in time. Note, however, that this may result in a permanent failure like 462 (Destination Unreachable). An example of when this error may occur is in the case in which a client sends a PLAY request to a server prior to ensuring that the TCP connections negotiated for carrying media data were successfully established (in violation of this specification). The server would use this error code to indicate that the requested action could not be performed due to the failure of completing the connection establishment.

17.4.29. 465 Notification Reason Unknown

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

17.4.30. 466 Key Management Error

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

17.4.31. 470 Connection Authorization Required

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

17.4.32. 471 Connection Credentials Not Accepted

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

17.4.33. 472 Failure to Establish Secure Connection

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

17.5. Server Error 5xx

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

17.5.1. 500 Internal Server Error

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

17.5.2. 501 Not Implemented

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

17.5.3. 502 Bad Gateway

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

17.5.4. 503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given, in the Retry-After header. Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the transport connection. The response scope is dependent on the request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was not session specific or intended to form an RTSP session, it applies to the RTSP server identified by the hostname in the Request-URI.
Top   ToC   RFC7826 - Page 123

17.5.5. 504 Gateway Timeout

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

17.5.6. 505 RTSP Version Not Supported

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

17.5.7. 551 Option Not Supported

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

17.5.8. 553 Proxy Unavailable

The proxy is currently unable to handle the request due to a temporary overloading or maintenance of the proxy. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given in the Retry-After header. Note: The existence of the 553 status code does not imply that a proxy must use it when becoming overloaded. Some proxies may wish to simply refuse the connection. The response scope is dependent on the Request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was non- session specific or intended to form an RTSP session, it applies to all such requests to this proxy.
Top   ToC   RFC7826 - Page 124

18. Header Field Definitions

+---------------+----------------+--------+---------+------+ | method | direction | object | acronym | Body | +---------------+----------------+--------+---------+------+ | DESCRIBE | C -> S | P,S | DES | r | | | | | | | | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | | | | | | | | OPTIONS | C -> S, S -> C | P,S | OPT | | | | | | | | | PAUSE | C -> S | P,S | PSE | | | | | | | | | PLAY | C -> S | P,S | PLY | | | | | | | | | PLAY_NOTIFY | S -> C | P,S | PNY | R | | | | | | | | REDIRECT | S -> C | P,S | RDR | | | | | | | | | SETUP | C -> S | S | STP | | | | | | | | | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | | | | | | | | TEARDOWN | C -> S | P,S | TRD | | | | | | | | | | S -> C | P | TRD | | +---------------+----------------+--------+---------+------+ This table is an overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. "Body" denotes if a method is allowed to carry body and in which direction; R = request, r=response. Note: All error messages for statuses 4xx and 5xx are allowed to carry a body. Table 8: Overview of RTSP Methods The general syntax for header fields is covered in Section 5.2. This section lists the full set of header fields along with notes on meaning and usage. The syntax definitions for header fields are present in Section 20.2.3. Examples of each header field are given. Information about header fields in relation to methods and proxy processing is summarized in Figures 2, 3, 4, and 5.
Top   ToC   RFC7826 - Page 125
   The "where" column describes the request and response types in which
   the header field can be used.  Values in this column are:

   R:                header field may only appear in requests;

   r:                header field may only appear in responses;

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

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

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

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

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

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

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

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

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

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

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

   m:    The header field is mandatory.

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

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

   -:    The header field is not applicable.

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

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

   The From and Location header fields contain a URI.  If the URI
   contains a comma (') or semicolon (;), the URI MUST be enclosed in
   double quotes (").  Any URI parameters are contained within these
   quotes.  If the URI is not enclosed in double quotes, any semicolon-
   delimited parameters are header-parameters, not URI parameters.
Top   ToC   RFC7826 - Page 127
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | Header            |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | Accept            | R    |      | o  | -  | -   | -   | -   | -   |
   | Accept-           | R    | rm   | o  | o  | o   | o   | o   | o   |
   | Credentials       |      |      |    |    |     |     |     |     |
   | Accept-Encoding   | R    | r    | o  | -  | -   | -   | -   | -   |
   | Accept-Language   | R    | r    | o  | -  | -   | -   | -   | -   |
   | Accept-Ranges     | G    | r    | -  | -  | m   | -   | -   | -   |
   | Accept-Ranges     | 456  | r    | -  | -  | -   | m   | -   | -   |
   | Allow             | r    | am   | c  | c  | c   | -   | -   | -   |
   | Allow             | 405  | am   | m  | m  | m   | m   | m   | m   |
   | Authentication-   | r    |      | o  | o  | o   | o   | o   | o/- |
   | Info              |      |      |    |    |     |     |     |     |
   | Authorization     | R    |      | o  | o  | o   | o   | o   | o/- |
   | Bandwidth         | R    |      | o  | o  | o   | o   | -   | -   |
   | Blocksize         | R    |      | o  | -  | o   | o   | -   | -   |
   | Cache-Control     | G    | r    | o  | -  | o   | -   | -   | -   |
   | Connection        | G    | ad   | o  | o  | o   | o   | o   | o   |
   | Connection-       | 470, | ar   | o  | o  | o   | o   | o   | o   |
   | Credentials       | 407  |      |    |    |     |     |     |     |
   | Content-Base      | r    |      | o  | -  | -   | -   | -   | -   |
   | Content-Base      | 4xx, |      | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Encoding  | R    | r    | -  | -  | -   | -   | -   | -   |
   | Content-Encoding  | r    | r    | o  | -  | -   | -   | -   | -   |
   | Content-Encoding  | 4xx, | r    | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Language  | R    | r    | -  | -  | -   | -   | -   | -   |
   | Content-Language  | r    | r    | o  | -  | -   | -   | -   | -   |
   | Content-Language  | 4xx, | r    | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Length    | r    | r    | *  | -  | -   | -   | -   | -   |
   | Content-Length    | 4xx, | r    | *  | *  | *   | *   | *   | *   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Location  | r    | r    | o  | -  | -   | -   | -   | -   |
   | Content-Location  | 4xx, | r    | o  | o  | o   | o   | o   | o   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | Content-Type      | r    | r    | *  | -  | -   | -   | -   | -   |
   | Content-Type      | 4xx, | ar   | *  | *  | *   | *   | *   | *   |
   |                   | 5xx  |      |    |    |     |     |     |     |
   | CSeq              | Gc   | rm   | m  | m  | m   | m   | m   | m   |
   | Date              | G    | am   | o/*| o/*| o/* | o/* | o/* | o/* |
   | Expires           | r    | r    | o  | -  | o   | -   | -   | -   |
   | From              | R    | r    | o  | o  | o   | o   | o   | o   |
   | If-Match          | R    | r    | -  | -  | o   | -   | -   | -   |
   | If-Modified-Since | R    | r    | o  | -  | o   | -   | -   | -   |
   | If-None-Match     | R    | r    | o  | -  | o   | -   | -   | -   |
Top   ToC   RFC7826 - Page 128
   | Last-Modified     | r    | r    | o  | -  | o   | -   | -   | -   |
   | Location          | 3rr  |      | m  | m  | m   | m   | m   | m   |
   +-------------------+------+------+----+----+-----+-----+-----+-----+
   | Header            |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
   +-------------------+------+------+----+----+-----+-----+-----+-----+

     Figure 2: Overview of RTSP Header Fields (A-L) Related to Methods
            DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
Top   ToC   RFC7826 - Page 129
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | Header           | Where   |Proxy|DES |OPT |STP | PLY | PSE | TRD |
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | Media-Properties | r       |     | -  | -  | m  | o   | o   | -   |
   | Media-Range      | r       |     | -  | -  | c  | c   | c   | -   |
   | MTag             | r       | r   | o  | -  | o  | -   | -   | -   |
   | Pipelined-       | G       | amd | -  | o  | o  | o   | o   | o   |
   | Requests         |         | r   |    |    |    |     |     |     |
   | Proxy-           | 407     | amr | m  | m  | m  | m   | m   | m   |
   | Authenticate     |         |     |    |    |    |     |     |     |
   | Proxy-           | r       | amd | o  | o  | o  | o   | o   | o/- |
   | Authentication-  |         | r   |    |    |    |     |     |     |
   | Info             |         |     |    |    |    |     |     |     |
   | Proxy-           | R       | rd  | o  | o  | o  | o   | o   | o   |
   | Authorization    |         |     |    |    |    |     |     |     |
   | Proxy-Require    | R       | ar  | o  | o  | o  | o   | o   | o   |
   | Proxy-Require    | r       | r   | c  | c  | c  | c   | c   | c   |
   | Proxy-Supported  | R       | amr | c  | c  | c  | c   | c   | c   |
   | Proxy-Supported  | r       |     | c  | c  | c  | c   | c   | c   |
   | Public           | r       | amr | -  | m  | -  | -   | -   | -   |
   | Public           | 501     | amr | m  | m  | m  | m   | m   | m   |
   | Range            | R       |     | -  | -  | -  | o   | -   | -   |
   | Range            | r       |     | -  | -  | c  | m   | m   | -   |
   | Referrer         | R       |     | o  | o  | o  | o   | o   | o   |
   | Request-Status   | R       |     | -  | -  | -  | -   | -   | -   |
   | Require          | R       |     | o  | o  | o  | o   | o   | o   |
   | Retry-After      | 3rr,503 |     | o  | o  | o  | o   | o   | -   |
   |                  | ,553    |     |    |    |    |     |     |     |
   | Retry-After      | 413     |     | o  | -  | -  | -   | -   | -   |
   | RTP-Info         | r       |     | -  | -  | c  | c   | -   | -   |
   | Scale            | R       | r   | -  | -  | -  | o   | -   | -   |
   | Scale            | r       | amr | -  | -  | c  | c   | c   | -   |
   | Seek-Style       | R       |     | -  | -  | -  | o   | -   | -   |
   | Seek-Style       | r       |     | -  | -  | -  | m   | -   | -   |
   | Server           | R       | r   | -  | o  | -  | -   | -   | o   |
   | Server           | r       | r   | o  | o  | o  | o   | o   | o   |
   | Session          | R       | r   | -  | o  | o  | m   | m   | m   |
   | Session          | r       | r   | -  | c  | m  | m   | m   | o   |
   | Speed            | R       | admr| -  | -  | -  | o   | -   | -   |
   | Speed            | r       | admr| -  | -  | -  | c   | -   | -   |
   | Supported        | R       | r   | o  | o  | o  | o   | o   | o   |
   | Supported        | r       | r   | c  | c  | c  | c   | c   | c   |
   | Terminate-Reason | R       | r   | -  | -  | -  | -   | -   | -/o |
   | Timestamp        | R       | admr| o  | o  | o  | o   | o   | o   |
   | Timestamp        | c       | admr| m  | m  | m  | m   | m   | m   |
   | Transport        | G       | mr  | -  | -  | m  | -   | -   | -   |
   | Unsupported      | r       |     | c  | c  | c  | c   | c   | c   |
   | User-Agent       | R       |     | m* | m* | m* | m*  | m*  | m*  |
Top   ToC   RFC7826 - Page 130
   | Via              | R       | amr | c  | c  | c  | c   | c   | c   |
   | Via              | r       | amr | c  | c  | c  | c   | c   | c   |
   | WWW-Authenticate | 401     |     | m  | m  | m  | m   | m   | m   |
   +------------------+---------+-----+----+----+----+-----+-----+-----+
   | Header           | Where   |Proxy|DES |OPT |STP | PLY | PSE | TRD |
   +------------------+---------+-----+----+----+----+-----+-----+-----+

     Figure 3: Overview of RTSP Header Fields (M-W) Related to Methods
            DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
Top   ToC   RFC7826 - Page 131
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | Header                    | Where | Proxy | GPR | SPR | RDR | PNY |
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | Accept-Credentials        | R     | rm    | o   | o   | o   | -   |
   | Accept-Encoding           | R     | r     | o   | o   | o   | -   |
   | Accept-Language           | R     | r     | o   | o   | o   | -   |
   | Accept-Ranges             | G     | rm    | o   | -   | -   | -   |
   | Allow                     | 405   | amr   | m   | m   | m   | m   |
   | Authentication-Info       | r     |       | o/- | o/- | -   | -   |
   | Authorization             | R     |       | o   | o   | o   | -   |
   | Bandwidth                 | R     |       | -   | o   | -   | -   |
   | Blocksize                 | R     |       | -   | o   | -   | -   |
   | Cache-Control             | G     | r     | o   | o   | -   | -   |
   | Connection                | G     |       | o   | o   | o   | o   |
   | Connection-Credentials    | 470,  | ar    | o   | o   | o   | -   |
   |                           | 407   |       |     |     |     |     |
   | Content-Base              | R     |       | o   | o   | -   | o   |
   | Content-Base              | r     |       | o   | o   | -   | -   |
   | Content-Base              | 4xx,  |       | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Encoding          | R     | r     | o   | o   | -   | o   |
   | Content-Encoding          | r     | r     | o   | o   | -   | -   |
   | Content-Encoding          | 4xx,  | r     | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Language          | R     | r     | o   | o   | -   | o   |
   | Content-Language          | r     | r     | o   | o   | -   | -   |
   | Content-Language          | 4xx,  | r     | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Length            | R     | r     | *   | *   | -   | *   |
   | Content-Length            | r     | r     | *   | *   | -   | -   |
   | Content-Length            | 4xx,  | r     | *   | *   | *   | *   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Location          | R     |       | o   | o   | -   | o   |
   | Content-Location          | r     |       | o   | o   | -   | -   |
   | Content-Location          | 4xx,  |       | o   | o   | o   | o   |
   |                           | 5xx   |       |     |     |     |     |
   | Content-Type              | R     |       | *   | *   | -   | *   |
   | Content-Type              | r     |       | *   | *   | -   | -   |
   | Content-Type              | 4xx,  |       | *   | *   | *   | *   |
   |                           | 5xx   |       |     |     |     |     |
   | CSeq                      | R,c   | mr    | m   | m   | m   | m   |
   | Date                      | R     | a     | o/* | o/* | m   | o/* |
   | Date                      | r     | am    | o/* | o/* | o/* | o/* |
   | Expires                   | r     | r     | -   | -   | -   | -   |
   | From                      | R     | r     | o   | o   | o   | -   |
   | If-Match                  | R     | r     | -   | -   | -   | -   |
   | If-Modified-Since         | R     | am    | o   | -   | -   | -   |
   | If-None-Match             | R     | am    | o   | -   | -   | -   |
Top   ToC   RFC7826 - Page 132
   | Last-Modified             | R     | r     | -   | -   | -   | -   |
   | Last-Modified             | r     | r     | o   | -   | -   | -   |
   | Location                  | 3rr   |       | m   | m   | m   | -   |
   | Location                  | R     |       | -   | -   | m   | -   |
   +---------------------------+-------+-------+-----+-----+-----+-----+
   | Header                    | Where | Proxy | GPR | SPR | RDR | PNY |
   +---------------------------+-------+-------+-----+-----+-----+-----+

     Figure 4: Overview of RTSP Header Fields (A-L) Related to Methods
          GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY
Top   ToC   RFC7826 - Page 133
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | Header                    |  Where  | Proxy | GPR | SPR | RDR | PNY |
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | Media-Properties          | R       | amr   | o   | -   | -   | c   |
 | Media-Properties          | r       | mr    | c   | -   | -   | -   |
 | Media-Range               | R       |       | o   | -   | -   | c   |
 | Media-Range               | r       |       | c   | -   | -   | -   |
 | MTag                      | r       | r     | o   | -   | -   | -   |
 | Notify-Reason             | R       |       | -   | -   | -   | m   |
 | Pipelined-Requests        | R       | amdr  | o   | o   | -   | -   |
 | Proxy-Authenticate        | 407     | amdr  | m   | m   | m   | -   |
 | Proxy-Authentication-Info | r       | amdr  | o/- | o/- | -   | -   |
 | Proxy-Authorization       | R       | amdr  | o   | o   | o   | -   |
 | Proxy-Require             | R       | ar    | o   | o   | o   | -   |
 | Proxy-Supported           | R       | amr   | c   | c   | c   | -   |
 | Proxy-Supported           | r       |       | c   | c   | c   | -   |
 | Public                    | 501     | admr  | m   | m   | m   | -   |
 | Range                     | R       |       | o   | -   | -   | m   |
 | Range                     | r       |       | c   | -   | -   | -   |
 | Referrer                  | R       |       | o   | o   | o   | -   |
 | Request-Status            | R       | mr    | -   | -   | -   | c   |
 | Require                   | R       | r     | o   | o   | o   | o   |
 | Retry-After               | 3rr,503,|       | o   | o   | -   | -   |
 |                           | 553     |       |     |     |     |     |
 | Retry-After               | 413     |       | o   | o   | -   | -   |
 | RTP-Info                  | R       | r     | o   | -   | -   | C   |
 | RTP-Info                  | r       | r     | c   | -   | -   | -   |
 | Scale                     | G       |       | c   | -   | c   | c   |
 | Seek-Style                | G       |       | -   | -   | -   | -   |
 | Server                    | R       | r     | o   | o   | o   | o   |
 | Server                    | r       | r     | o   | o   | -   | -   |
 | Session                   | R       | r     | o   | o   | o   | m   |
 | Session                   | r       | r     | c   | c   | o   | m   |
 | Speed                     | G       |       | -   | -   | -   | -   |
 | Supported                 | R       | r     | o   | o   | o   | -   |
 | Supported                 | r       | r     | c   | c   | c   | -   |
 | Terminate-Reason          | R       | r     | -   | -   | m   | -   |
 | Timestamp                 | R       | adrm  | o   | o   | o   | o   |
 | Timestamp                 | c       | adrm  | m   | m   | m   | m   |
 | Transport                 | G       | mr    | -   | -   | -   | -   |
 | Unsupported               | r       | arm   | c   | c   | c   | c   |
 | User-Agent                | R       | r     | m*  | m*  | -   | -   |
 | User-Agent                | r       | r     | m*  | m*  | m*  | m*  |
 | Via                       | R       | amr   | c   | c   | c   | c   |
Top   ToC   RFC7826 - Page 134
 | Via                       | r       | amr   | c   | c   | c   | c   |
 | WWW-Authenticate          | 401     |       | m   | m   | m   | -   |
 +---------------------------+---------+-------+-----+-----+-----+-----+
 | Header                    |  Where  | Proxy | GPR | SPR | RDR | PNY |
 +---------------------------+---------+-------+-----+-----+-----+-----+

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



(page 134 continued on part 7)

Next Section