MOQT uses a pair of unidirectional streams for creating the session and exchanging control messages. Each peer opens one control stream beginning with a SETUP message. Using a pair of unidirectional streams rather than a single bidirectional stream allows either peer to send data as soon as it is able. Depending on whether 0-RTT is available on the QUIC connection, either client or server might be able to send stream data first.
In addition to the control streams, this specification uses bidirectional streams
to carry requests. A request stream begins with one of these six message types:
TRACK_STATUS, SUBSCRIBE, PUBLISH, FETCH, PUBLISH_NAMESPACE, and
SUBSCRIBE_NAMESPACE. Bidirectional streams MUST NOT
begin with any other message type unless negotiated. If they do, the peer MUST
close the Session with a PROTOCOL_VIOLATION. Objects are sent on unidirectional
streams.
Unidirectional streams containing Objects or bidirectional stream(s) beginning with a request message could arrive prior to the control streams, in which case the data SHOULD be buffered until both control streams arrive and setup is complete. If an implementation does not want to buffer or if the message type is not supported, it MAY reset such bidirectional streams before the session and control streams are established.
A control stream MUST NOT be closed at the underlying transport layer during the
session's lifetime. Doing so results in the session being closed as a
PROTOCOL_VIOLATION.
3.3.1. 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 SHOULD cancel requests by abruptly terminating any directions of a stream that are still open using RESET_STREAM / RESET_STREAM_AT or STOP_SENDING.
When an endpoint rejects a request without performing any application processing, it SHOULD send a REQUEST_ERROR and FIN the stream.