REQUEST_ERROR — MoQT draft-23 §9.4

The REQUEST_ERROR message is sent in response to any request (SUBSCRIBE, FETCH, PUBLISH, SUBSCRIBE_NAMESPACE, SUBSCRIBE_TRACKS, PUBLISH_NAMESPACE, TRACK_STATUS, REQUEST_UPDATE).

9.4.1. REQUEST_ERROR Message Format

REQUEST_ERROR Message {
  Type (vi64) = 0x5,
  Length (vi64),
  Error Code (vi64),
  Retry Interval (vi64),
  Error Reason (Reason Phrase),
  Error Details (..) ...,
}

Figure 10: MOQT REQUEST_ERROR Message

Error Code: Identifies an integer error code for request failure.
Retry Interval: The minimum time (in milliseconds) before the request SHOULD be sent again, plus one. If the value is 0, the request SHOULD NOT be retried.
Error Reason: Provides a text description of the request error. See Section 8.5.
Error Details: Structured information about the error, serialized as Key-Value-Pairs (Figure 4) spanning the remainder of the message, bounded by the message Length field. See Section 9.4.2.

If a request is retryable with the same parameters at a later time, the sender of REQUEST_ERROR includes a non-zero Retry Interval in the message. To minimize the risk of synchronized retry storms, the sender can apply randomization to each retry interval so that retries are spread out over time. A Retry Interval value of 1 indicates the request can be retried immediately.

The error codes used in REQUEST_ERROR are defined in Section 12.3.

9.4.2. Error Details

Error Details carry structured information that helps the requester act on a REQUEST_ERROR. Each Error Detail type specifies which Error Codes it can accompany. Error Detail types are registered in the "MOQT Error Detail Types" registry (Section 16.11).

Receivers MUST ignore unknown Error Detail types, and MUST ignore a known Error Detail type that accompanies an Error Code it is not defined for. Senders MUST NOT repeat the same Error Detail type in a message unless the type's definition explicitly allows multiple instances. Receivers MUST allow duplicates of unknown Error Detail types.

Error Details describe the request error in the Session where the error occurred. A Relay that propagates an upstream error downstream decides for each Error Detail whether it also applies to the downstream request.

9.4.2.1. REDIRECT

The REDIRECT Error Detail directs the requester to retry a request at a different URI and/or for a different Full Track Name. It accompanies Error Code REDIRECT and MUST be present when the Error Code is REDIRECT. An endpoint that receives a REQUEST_ERROR with Error Code REDIRECT and no REDIRECT Error Detail MUST close the session with MALFORMED_MESSAGE.

REDIRECT Error Detail {
  Type (vi64) = 0x01,
  Length (vi64),
  Connect URI Length (vi64),
  Connect URI (..),
  Track Namespace (..),
  Track Name Length (vi64),
  Track Name (..),
}

Connect URI: The URI to connect to for the redirected request. If the length is zero, the requester SHOULD use the current session's URI. If a server receives a Redirect with a non-zero Connect URI Length it MUST close the session with ROLE_VIOLATION.
Track Namespace and Track Name: The Track Namespace and Track Name to use for the redirected request, together referred to as the Redirect target.

Track Name is not meaningful for namespace-scoped requests (SUBSCRIBE_NAMESPACE, PUBLISH_NAMESPACE, SUBSCRIBE_TRACKS) and MUST be empty; an endpoint that receives a non-empty Track Name in a Redirect for a namespace-scoped request MUST close the session with INVALID_FIELD.

9.4.2.2. UNSUPPORTED_PROPERTY

The UNSUPPORTED_PROPERTY Error Detail (Type 0x02) contains the Property Type (vi64) of a Mandatory Track Property (Section 3.7) that the sender does not understand. It accompanies Error Code UNSUPPORTED_EXTENSION. A sender that rejects a request with UNSUPPORTED_EXTENSION SHOULD include one UNSUPPORTED_PROPERTY Error Detail for each Mandatory Track Property it does not understand. Multiple instances of this type are allowed. A Relay that propagates UNSUPPORTED_EXTENSION downstream SHOULD include the UNSUPPORTED_PROPERTY Error Details it received.