Section 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
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
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.