FETCH — MoQT draft-20 §10.13.

A subscriber sends FETCH as the first message on a new bidi stream to a publisher to request a range of already published objects within a track.

The format of FETCH is as follows:

FETCH Message {
  Type (vi64) = 0x16,
  Length (16),
  Request ID (vi64),
  Track Namespace (..),
  Track Name Length (vi64),
  Track Name (..),
  Number of Parameters (vi64),
  Parameters (..) ...
}

Figure 16: MOQT FETCH Message

Request ID: See Section 10.1.
Track Namespace: Identifies the namespace of the track as defined in (Section 2.4.1).
Track Name: Identifies the track name as defined in (Section 2.4.1).
Parameters: The parameters are defined in Section 10.2.

A publisher responds to a FETCH request with either a FETCH_OK or a REQUEST_ERROR message. The publisher creates a new unidirectional stream that is used to send the Objects. The FETCH_OK or REQUEST_ERROR can come at any time relative to object delivery.

The publisher responding to a FETCH is responsible for delivering all available Objects in the requested range in the requested order (see Section 10.2.8). The Objects in the response are delivered on a single unidirectional stream. Any gaps in the Group and Object IDs in the response stream indicate objects that do not exist unless filters were requested. For Ascending Group Order this includes ranges between the first requested object and the first object in the stream; between objects in the stream; and between the last object in the stream and the Largest Group/Object indicated in FETCH_OK, so long as the fetch stream is terminated by a FIN. If no Objects exist in the requested range, the publisher opens the unidirectional stream, sends the FETCH_HEADER (see Section 11.4.4) and closes the stream with a FIN.

A relay that has cached objects from the beginning of the range MAY start sending objects immediately in response to a FETCH. If it encounters an object in the requested range that is not cached and has unknown status, the relay MUST pause subsequent delivery until it has confirmed the object's status upstream. If the upstream FETCH fails, the relay sends a REQUEST_ERROR and can reset the unidirectional stream. It can choose to do so immediately or wait until the cached objects have been delivered before resetting the stream.

The Object Forwarding Preference does not apply to fetches.

Fetch can include a Location Filter parameter (see Section 5.1.2) which specifies an inclusive range of Objects starting at Start Location and ending at End Location.

Objects with Locations larger than the Largest Object at the time the request is processed will not be retrieved by a FETCH. If the requested End Location exceeds the Largest Object, the actual end of the FETCH response is indicated in the FETCH_OK End Location.

If no Objects have been published for the track or Start Location is greater than the Largest Object (Section 10.7) the publisher MUST return REQUEST_ERROR with error code INVALID_RANGE.

A publisher MUST send fetched groups in the requested group order, either ascending or descending. Within each group, objects are sent in Object ID order; subgroup ID is not used for ordering.

If a Publisher receives a FETCH with a range that includes one or more Objects with unknown status (e.g. a Relay has temporarily lost contact with the Original Publisher and does not have the Object in cache), it can choose to reset the FETCH data stream with UNKNOWN_OBJECT_STATUS (Section 3.3.4), or indicate the range of unknown Objects and continue serving other known Objects.