6.4.1. Unidirectional Streams
All unidirectional MOQT streams start with a variable-length integer indicating the type of the stream.
| ID | Type |
|---|---|
| 0x05 | FETCH_HEADER (Section 11.4.1) |
| 0b0XX1XXXX | SUBGROUP_HEADER (Section 11.3.1) |
| 0x2F00 | SETUP (Section 9.1) |
| 0x132B3E28 | PADDING (Section 11.5.1) |
An endpoint that receives an unknown stream type MUST close the session.
Control streams (SETUP) are described in Section 6.3. Data streams (FETCH_HEADER, SUBGROUP_HEADER) are described in Section 11. Padding streams are described in Section 11.5.
6.4.2. Bidirectional Request Streams
6.4.2.1. Request ID
Request ID is included in request messages and is used to identify requests across messages. For example, fetch streams reference the Request ID of a SUBSCRIBE, PUBLISH, FETCH, or REQUEST_UPDATE.
The client generates even numbered Request IDs, starting at 0, and the server generates odd numbered Request IDs, starting at 1. Each endpoint increments its Request ID by 2 for each new request.
Each SUBSCRIBE, PUBLISH, FETCH, SUBSCRIBE_NAMESPACE, SUBSCRIBE_TRACKS, PUBLISH_NAMESPACE, REQUEST_UPDATE, and TRACK_STATUS message consumes a Request ID. Only request messages include a Request ID; response messages do not, since they are sent on the same bidirectional stream as the request.
If an endpoint receives a Request ID where the least significant bit is
incorrect for the sender, or a duplicate Request ID, it MUST close the
session with INVALID_REQUEST_ID.
6.4.2.2. Graceful Request Stream Closure
A request stream is bidirectional and each direction is closed independently, either gracefully with a FIN or abruptly with RESET_STREAM.
A FIN only indicates that an endpoint will send no further messages in that
direction; it is not a request cancellation. An endpoint MUST NOT send a FIN on
a direction of a request stream until it has sent all required messages on that
direction for its request type. In particular, an endpoint sending a response to
a request MUST send the corresponding response message, and the publisher of an
Established subscription MUST send PUBLISH_DONE, before sending a FIN. A FIN
sent by the responder after its response and any subsequent messages for the
request signals that the request is complete; if it has not already done so, the
requester SHOULD then send a FIN on its direction, gracefully closing the stream.
An endpoint that receives a FIN before all required messages have arrived treats
the request as failed.
An endpoint SHOULD send a FIN promptly after a message when it has nothing further to send on that direction and will not need to respond to a future REQUEST_UPDATE. A requester, with the exception of the sender of PUBLISH, MAY FIN immediately after sending a message if it will not send a REQUEST_UPDATE.
6.4.2.3. Request Cancellation and Rejection
Once a request stream has been opened, the request MAY be cancelled by either endpoint. Senders cancel requests if the response is no longer of interest; Receivers cancel requests if they are unable to or choose not to respond. Implementations cancel a request by abruptly terminating any directions of the stream that are still open, using RESET_STREAM for a direction they are sending and STOP_SENDING for a direction they are receiving. An endpoint that has already sent a FIN on its sending direction and subsequently wishes to cancel sends STOP_SENDING on the receiving direction.
When an endpoint rejects a request without performing any application processing, it SHOULD send a REQUEST_ERROR and FIN the stream.