1.1.Motivation

The development of MOQT is driven by goals in a number of areas -specifically latency, the robustness of QUIC, workflow efficiency andrelay 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 asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear 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 entitly that is both a Publisher and a Subscriber, but not the OriginalPublisher 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 atrack. See (Section 2.2).¶

Object:

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

Track:

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

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 summaryof 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-lengthencoding 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 instancehas 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 asdescribed in ([RFC9000],Section 16), followed by that many bytesof binary data¶

x (f):

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

To reduce unnecessary use of bandwidth, variable length integersSHOULDbe encoded using the least number of bytes possible to represent therequired value.¶

2.1.Objects

The basic data element of MOQT is an object. An object is anaddressable unit whose payload is a sequence of bytes. All objectsbelong to a group, indicating ordering and potentialdependencies.Section 2.2 An object is uniquely identified byits track namespace, track name, group ID, and object ID, and must be anidentical sequence of bytes regardless of how or where it is retrieved.An Object can become unavailable, but it's contentsMUST NOT change overtime.¶

Objects are comprised of two parts: metadata and a payload. The metadata isnever encrypted and is always visible to relays. The payload portion may beencrypted, in which case it is only visible to the Original Publisher and EndSubscribers. The application is solely responsible for the content of the objectpayload. This includes the underlying encoding, compression, any end-to-endencryption, or authentication. A relayMUST NOT combine, split, or otherwisemodify object payloads.¶

2.2.Groups

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

2.3.Track

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

3.1.Session establishment

This document defines a protocol that can be used interchangeably bothover a QUIC connection directly[QUIC], and over WebTransport[WebTransport]. Both provide streams and datagrams with similarsemantics (see[I-D.ietf-webtrans-overview],Section 4); thus, themain difference lies in how the servers are identified and how theconnection is established. When using QUIC, datagramsMUST besupported via the [QUIC-DATAGRAM] extension, which is already arequirement 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 toanother 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 andany extensions to use.¶

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

Within any MOQT version, clients request the use of extensions by adding Setupparameters corresponding to that extension. No extensions are defined in thisdocument.¶

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

New versions of MOQTMUST specify which existing extensions can be used withthat version. New extensionsMUST specify the existing versions with which theycan be used.¶

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

3.3.Session initialization

The first stream opened is a client-initiated bidirectional control stream wherethe peers exchange Setup messages (Section 6.2). All messages defined inthis draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control streamafter the Setup message. Control messagesMUST NOT be sent on any other stream,and a peer receiving a control message on a different stream closes the sessionas a 'Protocol Violation'. ObjectsMUST NOT be sent on the control stream, and apeer receiving an Object on the control stream closes the session as a 'ProtocolViolation'.¶

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

The control streamMUST NOT be abruptly closed at the underlying transportlayer. Doing so results in the session being closed as a 'Protocol Violation'.¶

3.4.Stream Cancellation

Streams aside from the control streamMAY be canceled due to congestionor other reasons by either the publisher or subscriber. Early termination of astream does not affect the MoQ application state, and therefore has noeffect on outstanding subscriptions.¶

3.5.Termination

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

The applicationMAY use any error message andSHOULD use a relevantcode, 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, whichMAY have been pre-negotiated by the application.¶

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

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

• GOAWAY Timeout: The session was closed because the client took too long toclose 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 serviceprovider needs the ability to shutdown/restart a server without waiting for allsessions 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 anew session and migrate any active subscriptions. The GOAWAY message may containa new URI for the new session, otherwise the current URI is reused. The serverSHOULD terminate the session with 'GOAWAY Timeout' after a sufficient timeout ifthere are still open subscriptions on a connection.¶

The GOAWAY message does not immediately impact subscription state. A subscriberSHOULD individually UNSUBSCRIBE for each existing subscription, while apublisherMAY reject new SUBSCRIBEs while in the draining state. When the serveris a subscriber, itSHOULD send a GOAWAY message prior to any UNSUBSCRIBEmessages.¶

After the client receives a GOAWAY, it'sRECOMMENDED that the client waits untilthere are no more active subscriptions before closing the session with NO_ERROR.Ideally this is transparent to the application using MOQT, which involvesestablishing a new session in the background and migrating active subscriptionsand announcements. The client can choose to delay closing the session if itexpects 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 ofinterest. RelaysMUST ensure subscribers are authorized to access thecontent associated with the track. The authorizationinformation can be part of subscription request itself or part of theencompassing session. The specifics of how a relay authorizes a user areoutside the scope of this specification.¶

The subscriber making the subscribe request is notified of the result ofthe subscription, via SUBSCRIBE_OK (Section 6.12) or theSUBSCRIBE_ERRORSection 6.13 control message.The entity receiving the SUBSCRIBEMUST send only a single response toa given SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.¶

For successful subscriptions, the publisher maintains a list ofsubscribers for each track. Each new OBJECT belonging to thetrack within the subscription range is forwarded to each activesubscriber, dependent on the congestion response. A subscriptionremains active until the publisher of the track terminates thetrack with a SUBSCRIBE_DONE (seeSection 6.14).¶

ObjectsMUST NOT be sent for unsuccessful subscriptions, and if a subscriberreceives a SUBSCRIBE_ERROR after receiving objects, itMUST close the sessionwith a 'Protocol Violation'.¶

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

RelaysMAY aggregate authorized subscriptions for a given track whenmultiple subscribers request the same track. Subscription aggregationallows relays to make only a single forward subscription for thetrack. The published content received from the forward subscriptionrequest is cached and shared among the pending subscribers.¶

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

The applicationSHOULD use a relevant status code inSUBSCRIBE_DONE, as defined below:¶

5.2.Publisher Interactions

Publishing through the relay starts with publisher sending ANNOUNCEcontrol message with aTrack Namespace (Section 2.3).¶

RelaysMUST ensure that publishers are authorized by:¶

• Verifying that the publisher is authorized to publish the contentassociated with the set of tracks whose Track Namespace matches theannounced namespace. Specifics of where the authorization happens,either at the relays or forwarded for further processing, depends onthe way the relay is managed and is application specific (typicallybased on prior business agreement).¶

Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control messageproviding the result of announcement. The entity receiving theANNOUNCEMUST send only a single response to a given ANNOUNCE ofeither ANNOUNCE_OK or ANNOUNCE_ERROR. When a publisher wants to stopnew subscriptions for an announced namespace it sends an UNANNOUNCE.A subscriber indicates it will no longer route subscriptions for anamespace it previously responded ANNOUNCE_OK to by sending anANNOUNCE_CANCEL.¶

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

OBJECT message headers carry a short hop-by-hopTrack Alias that maps tothe Full Track Name (seeSection 6.12). Relays use theTrack Alias of an incoming OBJECT message to identify its track and findthe active subscribers for that track. RelaysMUST NOT depend on OBJECTpayload content for making forwarding decisions andMUST only depend on thefields, such as priority order and other metadata properties in theOBJECT message header. Unless determined by congestion response, RelaysMUST forward the OBJECT message to the matching subscribers.¶

5.3.Relay Object Handling

MOQT encodes the delivery information for a stream via OBJECT headers(Section 6.11). A relayMUST NOT modify Object properties whenforwarding.¶

A relayMUST treat the object payload as opaque. A relayMUST NOTcombine, split, or otherwise modify object payloads. A relaySHOULDprioritize sending Objects based onSection 4.¶

A publisherSHOULD begin sending incomplete objects when available toavoid incurring additional latency.¶

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

6.1.Parameters

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

SendersMUST NOT repeat the same parameter type in a message. ReceiversSHOULD check that there are no duplicate parameters and close the sessionas 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 theparameter. Setup message parameters use a namespace that is constant across allMoQ Transport versions. All other messages use a version-specific namespace. Forexample, the integer '1' can refer to different parameters for Setup messagesand for all other message types.¶

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

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

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

6.2.CLIENT_SETUP and SERVER_SETUP

TheCLIENT_SETUP andSERVER_SETUP messages are the first messages exchangedby the client and the server; they allows the peers to establish the mutuallysupported version and agree on the initial configuration before any objects areexchanged. It is a sequence of key-value pairs called Setup parameters; thesemantics and format of which can vary based on whether the client or server issending. To ensure future extensibility of MOQT, the peersMUST ignore unknownsetup 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 aGOAWAY message to initiate session migration(Section 3.6) with an optional URI.¶

The serverMUST terminate the session with a Protocol Violation(Section 3.5) if it receives a GOAWAY message. The clientMUSTterminate the session with a Protocol Violation (Section 3.5) if itreceives multiple GOAWAY messages.¶

GOAWAY Message {  New Session URI (b)}

• New Session URI: The clientMUST use this URI for the new session if provided.If the URI is zero bytes long, the current URI is reused instead. The newsession URISHOULD use the same scheme as the current URL to ensurecompatibility.¶

6.4.SUBSCRIBE

SUBSCRIBE Message {  Subscribe ID (i),  Track Alias (i),  Track Namespace (b),  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 toa prior subscription. Subscriptions can only become more narrower, not wider,because an attempt to widen a subscription could fail. If Objects before thestart or after the end of the current subscription are needed, a separatesubscription can be made. The start ObjectMUST NOT decrease and when it increases,there is no guarantee that a publisher will not have already sent Objects beforethe new start Object. The end ObjectMUST NOT increase and when it decreases,there is no guarantee that a publisher will not have already sent Objects afterthe new end Object. A publisherSHOULD close the Session as a 'Protocol Violation'if the SUBSCRIBE_UPDATE violates either rule or if the subscriber specifies aSubscribe ID that does not exist within the Session.¶

Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to bedelivered multiple times. Like SUBSCRIBE, EndGroup and EndObjectMUST specify thesame 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.ThisMUST 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 isopen-ended.¶

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

• Subscriber Priority: Specifies the priority of a subscription relative toother subscriptions in the same session. Lower numbers get higher priority.SeeSection 4.¶

• Subscribe Parameters: The parameters are defined inSection 6.1.1.¶

6.6.UNSUBSCRIBE

A subscriber issues aUNSUBSCRIBE message to a publisher indicating it is nolonger interested in receiving media for the specified track and Objectsshould stop being sent as soon as possible. The publisher sends aSUBSCRIBE_DONE to acknowledge the unsubscribe was successful and indicatethe final Object.¶

The format ofUNSUBSCRIBE is as follows:¶

UNSUBSCRIBE Message {  Subscribe ID (i)}

• Subscribe ID: Subscription Identifier as defined inSection 6.4.¶

6.7.ANNOUNCE_OK

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

ANNOUNCE_OK{  Track Namespace (b),}

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

6.8.ANNOUNCE_ERROR

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

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

• Track Namespace: Identifies the track namespace in the ANNOUNCEmessage 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 anANNOUNCE_CANCEL control message toindicate it will stop sending new subscriptions for trackswithin the provided Track Namespace.¶

If a publisher receives new subscriptions for that namespace afterreceiving an ANNOUNCE_CANCEL, itSHOULD close the session as a'Protocol Violation'.¶

ANNOUNCE_CANCEL Message {  Track Namespace (b),}

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

6.10.TRACK_STATUS_REQUEST

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

A TRACK_STATUS messageMUST be sent in response to each TRACK_STATUS_REQUEST.¶

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

6.11.OBJECT

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

OBJECT_STREAM Message {  Subscribe ID (i),  Track Alias (i),  Group ID (i),  Object ID (i),  Publisher Priority (8),  Object Status (i),  Object Payload (..),}

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

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_GROUP Message {  Subscribe ID (i),  Track Alias (i),  Group ID (i),  Publisher Priority (8),}

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

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"}

Stream = 2STREAM_HEADER_GROUP {  Subscribe ID = 2  Track Alias = 2  Group ID = 0  Publisher Priority = 0}{  Object ID = 0  Object Payload Length = 4  Payload = "abcd"}{  Object ID = 1  Object Payload Length = 4  Payload = "efgh"}Stream = 6OBJECT_STREAM {  Subscribe ID = 3  Track Alias = 3  Group ID = 0  Object ID = 1  Object Send Order = 0  Payload = "moqrocks"}

6.12.SUBSCRIBE_OK

A publisher sends a SUBSCRIBE_OK control message for successfulsubscriptions.¶

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

• Subscribe ID: Subscription Identifier as defined inSection 6.4.¶

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

• Group Order: Indicates the subscription will be delivered inAscending (0x1) or Descending (0x2) order by group. SeeSection 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 bepresent.¶

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

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

6.13.SUBSCRIBE_ERROR

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

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

• Subscribe ID: Subscription Identifier as defined inSection 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 subscriberSHOULD re-issue theSUBSCRIBE with this Track Alias instead. If this Track Alias is already in use,the subscriberMUST close the connection with a Duplicate Track Alias error(Section 3.5).¶

6.14.SUBSCRIBE_DONE

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

The format ofSUBSCRIBE_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 inSection 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 ifnot. 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 OBJECTmessage in this track.¶

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

6.15.ANNOUNCE

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

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

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

• Parameters: The parameters are defined inSection 6.1.1.¶

6.16.UNANNOUNCE

The publisher sends theUNANNOUNCE control message to indicateits intent to stop serving new subscriptions for trackswithin the provided Track Namespace.¶

UNANNOUNCE Message {  Track Namespace (b),}

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

6.17.TRACK_STATUS

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

TRACK_STATUS Message {  Track Namespace (b),  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 thetrack. ItMUST hold one of the following values. Any other value is a malformedmessage.¶

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

0x01: The track does not exist. Subsequent fieldsMUST be zero, and any othervalue is a malformed message.¶

0x02: The track has not yet begun. Subsequent fieldsMUST be zero. Any othervalue is a malformed message.¶

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

0x04: The publisher is a relay that cannot obtain the current track status fromupstream. 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 groupand object ID it has observed, whether or not that object was cached orcompletely delivered. If not subscribed, a relaySHOULD send aTRACK_STATUS_REQUEST upstream to obtain updated information.¶

Alternatively, the relayMAY subscribe to the track to obtain the sameinformation.¶

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

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

7.1.Resource Exhaustion

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

MOQT uses stream limits and flow control to impose resource limits atthe network layer. EndpointsSHOULD set flow control limits based on theanticipated bitrate.¶

EndpointsMAY impose a MAX STREAM count limit which would restrict thenumber of concurrent streams which a MOQT Streaming Format could have inflight.¶

The publisher prioritizes and transmits streams out of order. Streamsmight be starved indefinitely during congestion. The publisher andsubscriberMUST cancel a stream, preferably the lowest priority, afterreaching a resource limit.¶