Media over QUIC Transport

1.1. Motivation

The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.¶

1.2. Terms and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Client:

The party initiating a MoQ transport session.¶

Server:

The party accepting an incoming transport session.¶

Endpoint:

A Client or Server.¶

Publisher:

An endpoint that handles subscriptions by sending requested Objects from the requested track.¶

Subscriber:

An endpoint that subscribes to and receives tracks.¶

Original Publisher:

The initial publisher of a given track.¶

End Subscriber:

A subscriber that initiates a subscription and does not send the data on to other subscribers.¶

Relay:

An entity that is both a Publisher and a Subscriber, but not the Original Publisher or End Subscriber.¶

Upstream:

In the direction of the Original Publisher¶

Downstream:

In the direction of the End Subscriber(s)¶

Transport session:

A raw QUIC connection or a WebTransport session.¶

Congestion:

Packet loss and queuing caused by degraded or overloaded networks.¶

Group:

A temporal sequence of objects. A group represents a join point in a track. See (Section 2.3).¶

Object:

An object is an addressable unit whose payload is a sequence of bytes. Objects form the base element in the MOQT model. See (Section 2.1).¶

Track:

An encoded bitstream. Tracks contain a sequential series of one or more groups and are the subscribable entity with MOQT. See (Section 2.4).¶

1.3. Notational Conventions

This document uses the conventions detailed in ([RFC9000], Section 1.3) when describing the binary encoding.¶

As a quick reference, the following list provides a non normative summary of the parts of RFC9000 field syntax that are used in this specification.¶

x (L):

Indicates that x is L bits long¶

x (i):

Indicates that x holds an integer value using the variable-length encoding as described in ([RFC9000], Section 16)¶

x (..):

Indicates that x can be any length including zero bits long. Values in this format always end on a byte boundary.¶

[x (L)]:

Indicates that x is optional and has a length of L¶

x (L) ...:

Indicates that x is repeated zero or more times and that each instance has a length of L¶

This document extends the RFC9000 syntax and with the additional field types:¶

x (b):

Indicates that x consists of a variable length integer encoding as described in ([RFC9000], Section 16), followed by that many bytes of binary data¶

x (f):

Indicates that x is a flag and is encoded as a single byte with the value 0 or 1. A value of 0 indicates the flag is false or off, while a value of 1 indicates the flag is true or on. Any other value is a protocol error and SHOULD terminate the session with a Protocol Violation (Section 3.5).¶

x (tuple):

Indicates that x is a tuple, consisting of a variable length integer encoded as described in ([RFC9000], Section 16), followed by that many variable length tuple fields, each of which are encoded as (b) above.¶

To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value.¶

2.1. Objects

The basic data element of MOQT is an object. An object is an addressable unit whose payload is a sequence of bytes. All objects belong to a group, indicating ordering and potential dependencies. Section 2.3 An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved. An Object can become unavailable, but its contents MUST NOT change over time.¶

Objects are comprised of two parts: metadata and a payload. The metadata is never encrypted and is always visible to relays. The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers. The application is solely responsible for the content of the object payload. This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads.¶

2.2. Subgroups

A subgroup is a sequence of one or more objects from the same group (Section 2.3) in ascending order by Object ID. Objects in a subgroup have a dependency and priority relationship consistent with sharing a QUIC stream. In some cases, a Group will be most effectively delivered using more than one QUIC stream.¶

When a Track's forwarding preference (see Section 7.1.1) is "Track" or "Datagram", Objects are not sent in Subgroups, no Subgroup IDs are assigned, and the description in the remainder of this section does not apply.¶

QUIC streams offer in-order reliable delivery and the ability to cancel sending and retransmission of data. Furthermore, many implementations offer the ability to control the relative priority of streams, which allows control over the scheduling of sending data on active streams.¶

Every object within a Group belongs to exactly one Subgroup.¶

Objects from two subgroups cannot be sent on the same QUIC stream. Objects from the same Subgroup MUST NOT be sent on different QUIC streams, unless one of the streams was reset prematurely, or upstream conditions have forced objects from a Subgroup to be sent out of Object ID order.¶

Original publishers assign each Subgroup a Subgroup ID, and do so as they see fit. The scope of a Subgroup ID is a Group, so Subgroups from different Groups MAY share a Subgroup ID without implying any relationship between them. In general, publishers assign objects to subgroups in order to leverage the features of QUIC streams as described above.¶

An example strategy for using QUIC stream properties follows. If object B is dependent on object A, then delivery of B can follow A, i.e. A and B can be usefully delivered over a single QUIC stream. Furthermore, in this example:¶

• If an object is dependent on all previous objects in a Subgroup, it is added to that Subgroup.¶

• If an object is not dependent on all of the objects in a Subgroup, it goes in a different Subgroup.¶

• There are often many ways to compose Subgroups that meet these criteria. Where possible, choose the composition that results in the fewest Subgroups in a group to minimize the number of QUIC streams used.¶

2.3. Groups

A group is a collection of objects and is a sub-unit of a track (Section 2.4). Objects within a group SHOULD NOT depend on objects in other groups. A group behaves as a join point for subscriptions. A new subscriber might not want to receive the entire track, and may instead opt to receive only the latest group(s). The publisher then selectively transmits objects based on their group membership.¶

2.4. Track

A track is a sequence of groups (Section 2.3). It is the entity against which a subscriber issues a subscription request. A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the publisher while the track is active.¶

3.1. Session establishment

This document defines a protocol that can be used interchangeably both over a QUIC connection directly [QUIC], and over WebTransport [WebTransport]. Both provide streams and datagrams with similar semantics (see [I-D.ietf-webtrans-overview], Section 4); thus, the main difference lies in how the servers are identified and how the connection is established. When using QUIC, datagrams MUST be supported via the [QUIC-DATAGRAM] extension, which is already a requirement for WebTransport over HTTP/3.¶

There is no definition of the protocol over other transports, such as TCP, and applications using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available.¶

moq-URI = "moqt" "://" authority path-abempty [ "?" query ]

3.2. Version and Extension Negotiation

Endpoints use the exchange of Setup messages to negotiate the MOQT version and any extensions to use.¶

The client indicates the MOQT versions it supports in the CLIENT_SETUP message (see Section 6.2). It also includes the union of all Setup Parameters Section 6.2.2 required for a handshake by any of those versions.¶

Within any MOQT version, clients request the use of extensions by adding Setup parameters corresponding to that extension. No extensions are defined in this document.¶

The server replies with a SERVER_SETUP message that indicates the chosen version, includes all parameters required for a handshake in that version, and parameters for every extension requested by the client that it supports.¶

New versions of MOQT MUST specify which existing extensions can be used with that version. New extensions MUST specify the existing versions with which they can be used.¶

If a given parameter carries the same information in multiple versions, but might have different optimal values in those versions, there SHOULD be separate Setup parameters for that information in each version.¶

3.3. Session initialization

The first stream opened is a client-initiated bidirectional control stream where the peers exchange Setup messages (Section 6.2). All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message. Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'. Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'.¶

This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams. Because there are no other uses of bidirectional streams, a peer MAY currently close the session as a 'Protocol Violation' if it receives a second bidirectional stream.¶

The control stream MUST NOT be abruptly closed at the underlying transport layer. Doing so results in the session being closed as a 'Protocol Violation'.¶

3.4. Stream Cancellation

Streams aside from the control stream MAY be canceled due to congestion or other reasons by either the publisher or subscriber. Early termination of a stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions.¶

3.5. Termination

The transport session can be terminated at any point. When native QUIC is used, the session is closed using the CONNECTION_CLOSE frame ([QUIC], Section 19.19). When WebTransport is used, the session is closed using the CLOSE_WEBTRANSPORT_SESSION capsule ([WebTransport], Section 5).¶

The application MAY use any error message and SHOULD use a relevant code, as defined below:¶

• No Error: The session is being terminated without an error.¶

• Internal Error: An implementation specific error occurred.¶

• Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.¶

• Protocol Violation: The remote endpoint performed an action that was disallowed by the specification.¶

• Duplicate Track Alias: The endpoint attempted to use a Track Alias that was already in use.¶

• Too Many Subscribes: The session was closed because the subscriber used a Subscribe ID equal or larger than the current Maximum Subscribe ID.¶

• GOAWAY Timeout: The session was closed because the client took too long to close the session in response to a GOAWAY (Section 6.3) message. See session migration (Section 3.6).¶

3.6. Migration

MoqTransport requires a long-lived and stateful session. However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media. MoqTransport avoids this via the GOAWAY message (Section 6.3).¶

The server sends a GOAWAY message, signaling that the client should establish a new session and migrate any active subscriptions. The GOAWAY message may contain a new URI for the new session, otherwise the current URI is reused. The server SHOULD terminate the session with 'GOAWAY Timeout' after a sufficient timeout if there are still open subscriptions on a connection.¶

The GOAWAY message does not immediately impact subscription state. A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new SUBSCRIBEs while in the draining state. When the server is a subscriber, it SHOULD send a GOAWAY message prior to any UNSUBSCRIBE messages.¶

After the client receives a GOAWAY, it's RECOMMENDED that the client waits until there are no more active subscriptions before closing the session with NO_ERROR. Ideally this is transparent to the application using MOQT, which involves establishing a new session in the background and migrating active subscriptions and announcements. The client can choose to delay closing the session if it expects more OBJECTs to be delivered. The server closes the session with a 'GOAWAY Timeout' if the client doesn't close the session quickly enough.¶

5.1. Subscriber Interactions

Subscribers interact with the Relays by sending a SUBSCRIBE (Section 6.4) control message for the tracks of interest. Relays MUST ensure subscribers are authorized to access the content associated with the track. The authorization information can be part of subscription request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification. The subscriber is notified of the result of the subscription via a SUBSCRIBE_OK (Section 6.13) or SUBSCRIBE_ERROR Section 6.14 control message. The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.¶

If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription. The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct.¶

For successful subscriptions, the publisher maintains a list of subscribers for each track. Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response. A subscription remains active until the publisher of the track terminates the subscription with a SUBSCRIBE_DONE (see Section 6.15).¶

A caching relay saves Objects to its cache identified by the Object's Full Track Name, Group ID and Object ID. Relays MUST be able to process objects for the same Full Track Name from multiple publishers and forward objects to active matching subscriptions. If multiple objects are received with the same Full Track Name, Group ID and Object ID, Relays MAY ignore subsequently received Objects or MAY use them to update the cache. Implementations that update the cache need to be protect against cache poisoning.¶

Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'.¶

A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has application specific information.¶

Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track. Subscription aggregation allows relays to make only a single upstream subscription for the track. The published content received from the upstream subscription request is cached and shared among the pending subscribers.¶

The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below:¶

The application SHOULD use a relevant status code in SUBSCRIBE_DONE, as defined below:¶

5.2. Publisher Interactions

Publishing through the relay starts with publisher sending ANNOUNCE control message with a Track Namespace (Section 2.4). The announce enables the relay to know which publisher to forward a SUBSCRIBE to.¶

Relays MUST ensure that publishers are authorized by:¶

• Verifying that the publisher is authorized to publish the content associated with the set of tracks whose Track Namespace matches the announced namespace. Where the authorization and identification of the publisher occurs depends on the way the relay is managed and is application specific.¶

Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control message providing the result of announcement. The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR.¶

A Relay can receive announcements from multiple publishers for the same Track Namespace and it SHOULD respond with the same response to each of the publishers, as though it was responding to an ANNOUNCE from a single publisher for a given tracknamespace.¶

When a publisher wants to stop new subscriptions for an announced namespace it sends an UNANNOUNCE. A subscriber indicates it will no longer route subscriptions for a namespace it previously responded ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL.¶

A relay manages sessions from multiple publishers and subscribers, connecting them based on the track namespace. This MUST use an exact match on track namespace unless otherwise negotiated by the application. For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar.¶

When a relay receives an incoming SUBSCRIBE request that triggers an upstream subscription, it SHOULD send a SUBSCRIBE request to each publisher that has announced the subscription's namespace, unless it already has an active subscription for the Objects requested by the incoming SUBSCRIBE request from all available publishers.¶

When a relay receives an incoming ANNOUCE for a given namespace, for each active upstream subscription that matches that namespace, it SHOULD send a SUBSCRIBE to that publisher that send the ANNOUNCE.¶

OBJECT message headers carry a short hop-by-hop Track Alias that maps to the Full Track Name (see Section 6.13). Relays use the Track Alias of an incoming OBJECT message to identify its track and find the active subscribers for that track. Relays MUST forward OBJECT messages to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout.¶

5.3. Relay Object Handling

MOQT encodes the delivery information for a stream via OBJECT headers (Section 7.1). A relay MUST NOT modify Object properties when forwarding.¶

A relay MUST treat the object payload as opaque. A relay MUST NOT combine, split, or otherwise modify object payloads. A relay SHOULD prioritize sending Objects based on Section 4.¶

A publisher SHOULD begin sending incomplete objects when available to avoid incurring additional latency.¶

A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking. Packet loss will cause stream data to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops. To mitigate this, a relay SHOULD read and write stream data out of order subject to flow control limits. See section 2.2 in [QUIC].¶

6.1. Parameters

Some messages include a Parameters field that encode optional message elements. They contain a type, length, and value.¶

Senders MUST NOT repeat the same parameter type in a message. Receivers SHOULD check that there are no duplicate parameters and close the session as a 'Protocol Violation' if found.¶

Receivers ignore unrecognized parameters.¶

The format of Parameters is as follows:¶

Parameter {
  Parameter Type (i),
  Parameter Length (i),
  Parameter Value (..),
}

Parameter Type is an integer that indicates the semantic meaning of the parameter. Setup message parameters use a namespace that is constant across all MoQ Transport versions. All other messages use a version-specific namespace. For example, the integer '1' can refer to different parameters for Setup messages and for all other message types.¶

SETUP message parameter types are defined in Section 6.2.2. Version- specific parameter types are defined in Section 6.1.1.¶

The Parameter Length field of the String Parameter encodes the length of the Parameter Value field in bytes.¶

Each parameter description will indicate the data type in the Parameter Value field. If a receiver understands a parameter type, and the parameter length implied by that type does not match the Parameter Length field, the receiver MUST terminate the session with error code 'Parameter Length Mismatch'.¶

6.2. CLIENT_SETUP and SERVER_SETUP

The CLIENT_SETUP and SERVER_SETUP messages are the first messages exchanged by the client and the server; they allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged. It is a sequence of key-value pairs called Setup parameters; the semantics and format of which can vary based on whether the client or server is sending. To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters. TODO: describe GREASE for those.¶

The wire format of the Setup messages are as follows:¶

CLIENT_SETUP Message Payload {
  Number of Supported Versions (i),
  Supported Version (i) ...,
  Number of Parameters (i) ...,
  Setup Parameters (..) ...,
}

SERVER_SETUP Message Payload {
  Selected Version (i),
  Number of Parameters (i) ...,
  Setup Parameters (..) ...,
}

The available versions and Setup parameters are detailed in the next sections.¶

6.3. GOAWAY

The server sends a GOAWAY message to initiate session migration (Section 3.6) with an optional URI.¶

The server MUST terminate the session with a Protocol Violation (Section 3.5) if it receives a GOAWAY message. The client MUST terminate the session with a Protocol Violation (Section 3.5) if it receives multiple GOAWAY messages.¶

GOAWAY Message {
  New Session URI (b)
}

• New Session URI: The client MUST use this URI for the new session if provided. If the URI is zero bytes long, the current URI is reused instead. The new session URI SHOULD use the same scheme as the current URL to ensure compatibility.¶

6.4. SUBSCRIBE

SUBSCRIBE Message {
  Subscribe ID (i),
  Track Alias (i),
  Track Namespace (tuple),
  Track Name (b),
  Subscriber Priority (8),
  Group Order (8),
  Filter Type (i),
  [StartGroup (i),
   StartObject (i)],
  [EndGroup (i),
   EndObject (i)],
  Number of Parameters (i),
  Subscribe Parameters (..) ...
}

6.5. SUBSCRIBE_UPDATE

A subscriber issues a SUBSCRIBE_UPDATE to a publisher to request a change to a prior subscription. Subscriptions can only become more narrower, not wider, because an attempt to widen a subscription could fail. If Objects before the start or after the end of the current subscription are needed, a separate subscription can be made. The start Object MUST NOT decrease and when it increases, there is no guarantee that a publisher will not have already sent Objects before the new start Object. The end Object MUST NOT increase and when it decreases, there is no guarantee that a publisher will not have already sent Objects after the new end Object. A publisher SHOULD close the Session as a 'Protocol Violation' if the SUBSCRIBE_UPDATE violates either rule or if the subscriber specifies a Subscribe ID that does not exist within the Session.¶

Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to be delivered multiple times. Like SUBSCRIBE, EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject.¶

The format of SUBSCRIBE_UPDATE is as follows:¶

SUBSCRIBE_UPDATE Message {
  Subscribe ID (i),
  StartGroup (i),
  StartObject (i),
  EndGroup (i),
  EndObject (i),
  Subscriber Priority (8),
  Number of Parameters (i),
  Subscribe Parameters (..) ...
}

• Subscribe ID: The subscription identifier that is unique within the session. This MUST match an existing Subscribe ID.¶

• StartGroup: The start Group ID.¶

• StartObject: The start Object ID.¶

• EndGroup: The end Group ID, plus 1. A value of 0 means the subscription is open-ended.¶

• EndObject: The end Object ID, plus 1. A value of 0 means the entire group is requested.¶

• Subscriber Priority: Specifies the priority of a subscription relative to other subscriptions in the same session. Lower numbers get higher priority. See Section 4.¶

• Subscribe Parameters: The parameters are defined in Section 6.1.1.¶

6.6. UNSUBSCRIBE

A subscriber issues a UNSUBSCRIBE message to a publisher indicating it is no longer interested in receiving media for the specified track and Objects should stop being sent as soon as possible. The publisher sends a SUBSCRIBE_DONE to acknowledge the unsubscribe was successful and indicate the final Object.¶

The format of UNSUBSCRIBE is as follows:¶

UNSUBSCRIBE Message {
  Subscribe ID (i)
}

• Subscribe ID: Subscription Identifier as defined in Section 6.4.¶

6.7. ANNOUNCE_OK

The subscriber sends an ANNOUNCE_OK control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.¶

ANNOUNCE_OK
{
  Track Namespace (tuple),
}

• Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided.¶

6.8. ANNOUNCE_ERROR

The subscriber sends an ANNOUNCE_ERROR control message for tracks that failed authorization.¶

ANNOUNCE_ERROR
{
  Track Namespace (tuple),
  Error Code (i),
  Reason Phrase (b),
}

• Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided.¶

• Error Code: Identifies an integer error code for announcement failure.¶

• Reason Phrase: Provides the reason for announcement error.¶

6.9. ANNOUNCE_CANCEL

The subscriber sends an ANNOUNCE_CANCEL control message to indicate it will stop sending new subscriptions for tracks within the provided Track Namespace.¶

If a publisher receives new subscriptions for that namespace after receiving an ANNOUNCE_CANCEL, it SHOULD close the session as a 'Protocol Violation'.¶

ANNOUNCE_CANCEL Message {
  Track Namespace (tuple),
  Error Code (i),
  Reason Phrase (b),
}

• Track Namespace: Identifies a track's namespace as defined in (Section 2.4.1).¶

• Error Code: Identifies an integer error code for canceling the announcement.¶

• Reason Phrase: Provides the reason for announcement cancelation.¶

6.10. TRACK_STATUS_REQUEST

A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the control stream to obtain information about the current status of a given track.¶

A TRACK_STATUS message MUST be sent in response to each TRACK_STATUS_REQUEST.¶

TRACK_STATUS_REQUEST Message {
  Track Namespace (tuple),
  Track Name (b),
}

6.11. SUBSCRIBE_NAMESPACE

The subscriber sends the SUBSCRIBE_NAMESPACE control message to a publisher to request the current set of matching announcements, as well as future updates to the set.¶

SUBSCRIBE_NAMESPACE Message {
  Track Namespace Prefix (tuple),
  Number of Parameters (i),
  Parameters (..) ...,
}

• Track Namespace Prefix: An ordered N-Tuple of byte fields which are matched against track namespaces known to the publisher. For example, if the publisher is a relay that has received ANNOUNCE messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", "participant=200"), a SUBSCRIBE_NAMESPACE for ("example.com", "meeting=123") would match both.¶

• Parameters: The parameters are defined in Section 6.1.1.¶

The publisher will respond with SUBSCRIBE_NAMESPACE_OK or SUBSCRIBE_NAMESPACE_ERROR. If the SUBSCRIBE_NAMESPACE is successful, the publisher will forward any matching ANNOUNCE messages to the subscriber that it has not yet sent. If the set of matching ANNOUNCE messages changes, the publisher sends the corresponding ANNOUNCE or UNANNOUNCE message.¶

A subscriber cannot make overlapping namespace subscriptions on a single session. Within a session, if a publisher receives a SUBSCRIBE_NAMESPACE with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_NAMESPACE or vice versa, it MUST respond with SUBSCRIBE_NAMESPACE_ERROR, with error code SUBSCRIBE_NAMESPACE_OVERLAP.¶

The publisher MUST ensure the subscriber is authorized to perform this namespace subscription.¶

SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE and UNANNOUNCE messages to a subscriber. It is useful in applications or relays where subscribers are only interested in or authorized to access a subset of available announcements.¶

6.12. UNSUBSCRIBE_NAMESPACE

A subscriber issues a UNSUBSCRIBE_NAMESPACE message to a publisher indicating it is no longer interested in ANNOUNCE and UNANNOUNCE messages for the specified track namespace prefix.¶

The format of UNSUBSCRIBE_NAMESPACE is as follows:¶

UNSUBSCRIBE_NAMESPACE Message {
  Track Namespace Prefix (tuple)
}

• Track Namespace Prefix: As defined in Section 6.11.¶

6.13. SUBSCRIBE_OK

A publisher sends a SUBSCRIBE_OK control message for successful subscriptions.¶

SUBSCRIBE_OK
{
  Subscribe ID (i),
  Expires (i),
  Group Order (8),
  ContentExists (f),
  [Largest Group ID (i)],
  [Largest Object ID (i)],
  Number of Parameters (i),
  Subscribe Parameters (..) ...
}

• Subscribe ID: Subscription Identifier as defined in Section 6.4.¶

• Expires: Time in milliseconds after which the subscription is no longer valid. A value of 0 indicates that the subscription does not expire or expires at an unknown time. Expires is advisory and a subscription can end prior to the expiry time or last longer.¶

• Group Order: Indicates the subscription will be delivered in Ascending (0x1) or Descending (0x2) order by group. See Section 4. Values of 0x0 and those larger than 0x2 are a protocol error.¶

• ContentExists: 1 if an object has been published on this track, 0 if not. If 0, then the Largest Group ID and Largest Object ID fields will not be present.¶

• Largest Group ID: The largest Group ID available for this track. This field is only present if ContentExists has a value of 1.¶

• Largest Object ID: The largest Object ID available within the largest Group ID for this track. This field is only present if ContentExists has a value of 1.¶

• Subscribe Parameters: The parameters are defined in Section 6.1.1.¶

6.14. SUBSCRIBE_ERROR

A publisher sends a SUBSCRIBE_ERROR control message in response to a failed SUBSCRIBE.¶

SUBSCRIBE_ERROR
{
  Subscribe ID (i),
  Error Code (i),
  Reason Phrase (b),
  Track Alias (i),
}

• Subscribe ID: Subscription Identifier as defined in Section 6.4.¶

• Error Code: Identifies an integer error code for subscription failure.¶

• Reason Phrase: Provides the reason for subscription error.¶

• Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead. If this Track Alias is already in use, the subscriber MUST close the connection with a Duplicate Track Alias error (Section 3.5).¶

6.15. SUBSCRIBE_DONE

A publisher sends a SUBSCRIBE_DONE message to indicate it is done publishing Objects for that subscription. The Status Code indicates why the subscription ended, and whether it was an error.¶

The format of SUBSCRIBE_DONE is as follows:¶

SUBSCRIBE_DONE Message {
  Subscribe ID (i),
  Status Code (i),
  Reason Phrase (b),
  ContentExists (f),
  [Final Group (i)],
  [Final Object (i)],
}

• Subscribe ID: Subscription identifier as defined in Section 6.4.¶

• Status Code: An integer status code indicating why the subscription ended.¶

• Reason Phrase: Provides the reason for subscription error.¶

• ContentExists: 1 if an object has been published for this subscription, 0 if not. If 0, then the Final Group and Final Object fields will not be present.¶

• Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.¶

• Final Object: The largest Object ID sent by the publisher in an OBJECT message in the Final Group for this track.¶

6.16. MAX_SUBSCRIBE_ID

A publisher sends a MAX_SUBSCRIBE_ID message to increase the number of subscriptions a subscriber can create within a session.¶

The Maximum Subscribe Id MUST only increase within a session, and receipt of a MAX_SUBSCRIBE_ID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'.¶

MAX_SUBSCRIBE_ID
{
  Subscribe ID (i),
}

• Subscribe ID: The new Maximum Subscribe ID for the session. If a Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'. More on Subscribe ID in Section 6.4.¶

6.17. ANNOUNCE

The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBEs for tracks within the announced Track Namespace. The receiver verifies the publisher is authorized to publish tracks under this namespace.¶

ANNOUNCE Message {
  Track Namespace (tuple),
  Number of Parameters (i),
  Parameters (..) ...,
}

• Track Namespace: Identifies a track's namespace as defined in (Section 2.4.1)¶

• Parameters: The parameters are defined in Section 6.1.1.¶

6.18. UNANNOUNCE

The publisher sends the UNANNOUNCE control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace.¶

UNANNOUNCE Message {
  Track Namespace (tuple),
}

• Track Namespace: Identifies a track's namespace as defined in (Section 2.4.1).¶

6.19. TRACK_STATUS

A publisher sends a 'TRACK_STATUS' message on the control stream in response to a TRACK_STATUS_REQUEST message.¶

TRACK_STATUS Message {
  Track Namespace (tuple),
  Track Name (b),
  Status Code (i),
  Last Group ID (i),
  Last Object ID (i),
}

The 'Status Code' field provides additional information about the status of the track. It MUST hold one of the following values. Any other value is a malformed message.¶

0x00: The track is in progress, and subsequent fields contain the highest group and object ID for that track.¶

0x01: The track does not exist. Subsequent fields MUST be zero, and any other value is a malformed message.¶

0x02: The track has not yet begun. Subsequent fields MUST be zero. Any other value is a malformed message.¶

0x03: The track has finished, so there is no "live edge." Subsequent fields contain the highest Group and object ID known.¶

0x04: The publisher is a relay that cannot obtain the current track status from upstream. Subsequent fields contain the largest group and object ID known.¶

Any other value in the Status Code field is a malformed message.¶

When a relay is subscribed to a track, it can simply return the highest group and object ID it has observed, whether or not that object was cached or completely delivered. If not subscribed, a relay SHOULD send a TRACK_STATUS_REQUEST upstream to obtain updated information.¶

Alternatively, the relay MAY subscribe to the track to obtain the same information.¶

If a relay cannot or will not do either, it should return its best available information with status code 0x04.¶

The receiver of multiple TRACK_STATUS messages for a track uses the information from the latest arriving message, as they are delivered in order on a single stream.¶

6.20. SUBSCRIBE_NAMESPACE_OK

A publisher sends a SUBSCRIBE_NAMESPACE_OK control message for successful namespace subscriptions.¶

SUBSCRIBE_NAMESPACE_OK
{
  Track Namespace Prefix (tuple),
}

• Track Namespace Prefix: As defined in Section 6.11.¶

6.21. SUBSCRIBE_NAMESPACE_ERROR

A publisher sends a SUBSCRIBE_NAMESPACE_ERROR control message in response to a failed SUBSCRIBE_NAMESPACE.¶

SUBSCRIBE_NAMESPACE_ERROR
{
  Track Namespace Prefix (tuple),
  Error Code (i),
  Reason Phrase (b),
}

• Track Namespace Prefix: As defined in Section 6.11.¶

• Error Code: Identifies an integer error code for the namespace subscription failure.¶

• Reason Phrase: Provides the reason for the namespace subscription error.¶

7.1. Object Headers

An OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, cache, and forward it. Objects are sent by publishers.¶

7.2. Object Datagram Message

An OBJECT_DATAGRAM message carries a single object in a datagram.¶

An Object received in an OBJECT_DATAGRAM message has an Object Forwarding Preference = Datagram. To send an Object with Object Forwarding Preference = Datagram, determine the length of the header and payload and send the Object as datagram. In certain scenarios where the object size can be larger than maximum datagram size for the session, the Object will be dropped.¶

OBJECT_DATAGRAM Message {
  Subscribe ID (i),
  Track Alias (i),
  Group ID (i),
  Object ID (i),
  Publisher Priority (8),
  Object Payload Length (i),
  [Object Status (i)],
  Object Payload (..),
}

7.3. Streams

When objects are sent on streams, the stream begins with a stream header message and is followed by one or more sets of serialized object fields. If a stream ends gracefully in the middle of a serialized Object, terminate the session with a Protocol Violation.¶

A publisher SHOULD NOT open more than one stream at a time with the same stream header message type and fields.¶

TODO: figure out how a relay closes these streams¶

STREAM_HEADER_TRACK Message {
  Subscribe ID (i)
  Track Alias (i),
  Publisher Priority (8),
}

{
  Group ID (i),
  Object ID (i),
  Object Payload Length (i),
  [Object Status (i)],
  Object Payload (..),
}

STREAM_HEADER_SUBGROUP Message {
  Subscribe ID (i),
  Track Alias (i),
  Group ID (i),
  Subgroup ID (i),
  Publisher Priority (8),
}

{
  Object ID (i),
  Object Payload Length (i),
  [Object Status (i)],
  Object Payload (..),
}

7.4. Examples

Sending a track on one stream:¶

STREAM_HEADER_TRACK {
  Subscribe ID = 1
  Track Alias = 1
  Publisher Priority = 0
}
{
  Group ID = 0
  Object ID = 0
  Object Payload Length = 4
  Payload = "abcd"
}
{
  Group ID = 1
  Object ID = 0
  Object Payload Length = 4
  Payload = "efgh"
}

Sending a subgroup on one stream:¶

Stream = 2

STREAM_HEADER_SUBGROUP {
  Subscribe ID = 2
  Track Alias = 2
  Group ID = 0
  Subgroup ID = 0
  Publisher Priority = 0
}
{
  Object ID = 0
  Object Payload Length = 4
  Payload = "abcd"
}
{
  Object ID = 1
  Object Payload Length = 4
  Payload = "efgh"
}

8.1. Resource Exhaustion

Live content requires significant bandwidth and resources. Failure to set limits will quickly cause resource exhaustion.¶

MOQT uses stream limits and flow control to impose resource limits at the network layer. Endpoints SHOULD set flow control limits based on the anticipated bitrate.¶

Endpoints MAY impose a MAX STREAM count limit which would restrict the number of concurrent streams which a MOQT Streaming Format could have in flight.¶

The publisher prioritizes and transmits streams out of order. Streams might be starved indefinitely during congestion. The publisher and subscriber MUST cancel a stream, preferably the lowest priority, after reaching a resource limit.¶

Normative References

[QUIC]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC7301]

Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[WebTransport]

Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport over HTTP/3", Work in Progress, Internet-Draft, draft-ietf-webtrans-http3-10, 25 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-10>.

Informative References

[I-D.ietf-webtrans-overview]

Vasiliev, V., "The WebTransport Protocol Framework", Work in Progress, Internet-Draft, draft-ietf-webtrans-overview-08, 25 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-08>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.