]> Akamai

wilaw@akamai.com

Cisco

snandaku@cisco.com

Applications and Real-Time Media Over QUIC MoQ MoQTransport MSF This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction MOQT Streaming Format (MSF) is a media format designed to deliver LOC compliant media content over Media Over QUIC Transport (MOQT) . MSF works by fragmenting the bitstream into objects that can be independently transmitted. MSF leverages a catalog format to describe the output of the original publisher. MSF specifies how content should be packaged and signaled, defines how the catalog communicates the content, specifies prioritization strategies for real-time and workflows for beginning and terminating broadcasts. MSF also details how end-subscribers may perform adaptive bitrate switching. MSF is targeted at real-time and interactive levels of live latency, as well as VOD content. This document describes version 1 of the streaming format.

Conventions 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 when, and only when, they appear in all capitals, as shown here. This document uses the conventions detailed in Section 1.3 of when describing the binary encoding.

Scope The purpose of MSF is to provide an interoperable media streaming format operating over . Interoperability implies that:

• An original publisher can package incoming media content into tracks, prepare a catalog and announce the availability of the content to an MOQT relay. Media content refers to audio and video data, as well as ancillary data such as captions, subtitles, accessibility and other timed-text data.
• An MOQT relay can process the announcement as well as cache and propagate the tracks, both to other relays or to the final subscriber.
• A final subscriber can parse the catalog, request tracks, decode and render the received media data.

MSF is intended to provide a format for delivering commercial media content. To that end, the following features are within scope:

• Video codecs - all codecs supported by
• Audio codecs - all audio codecs supported by
• Catalog track - describes the availability and characteristics of content produced by the original publisher.
• Timeline track - describes the relationship between MOQT Group and Object IDs to media time.
• Token-based authorization and access control
• Captions + Subtitles - support for and transmission
• Latency support across multiple regimes (thresholds are informative only and describe the delay between the original publisher placing the content on the wire and the final subscriber rendering it)
• Real-time - less than 500ms
• Interactive - between 500ms and 2500ms
• Standard - above 2500ms
• VOD latency - content that was previously produced, is no longer live and is available indefinitely.
• Content encryption
• ABR between time-synced tracks - subscribers may switch between tracks at different quality levels in order to maximize visual or audio quality under conditions of throughput variability.
• Capable of delivering interstitial advertising.
• Logs and analytics management - support for the reporting of client-side QoE and relay delivery actions via publish tracks using and .

Initial versions of MSF will prioritize basic features necessary to exercise interoperability across delivery systems. Later versions will add commercially necessary features.

Media packaging MSF delivers LOC packaged media bitstreams.

LOC packaging This specification references Low Overhead Container (LOC) to define how audio and video content is packaged. With this packaging mode, each EncodedAudioChunk or EncodedVideoChunk sample is placed in a separate MOQT Object. Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. When LOC packaging is used for a track, the catalog packaging attribute () MUST be present and it MUST be populated with a value of "loc".

Time-alignment MSF Tracks MAY be time-aligned. Those that are, are subject to the following requirements:

• Tracks advertised in the catalog as belonging to a common alternate group MUST be time-aligned.
• The render duration of the first media object of each equally numbered MOQT Group, after decoding, SHOULD have overlapping presentation time.

A consequence of this restriction is that an MSF receiver SHOULD be able to cleanly switch between time-aligned media tracks at group boundaries. If time-aligned media tracks do not have overlapping presentation time at equally-numbered group boundaries, then an alternate mechanism, not defined by this specification, must be provided to the client to enable it to switch smoothly between time-aligned, but numerically dissimilar, Group IDs.

Content protection and encryption MSF supports end-to-end encryption of media content using MoQ Secure Objects . When encryption is enabled, the payload of LOC-packaged media objects is encrypted and authenticated, while relays can still route content based on unencrypted header information.

Encryption scheme signaling The encryption scheme and parameters are signaled in the catalog using the following track-level fields:

• encryptionScheme - identifies the encryption mechanism
• cipherSuite - specifies the AEAD algorithm
• keyId - identifies the key material for decryption
• trackBaseKey - the base key material for this track

When the encryptionScheme field is present in a track definition, subscribers MUST decrypt the object payload using the specified scheme before processing.

Key management The keyId and trackBaseKey values are obtained from an external key management system and the mechanism for obtaining these values is out of scope for this specification. Examples of key management systems include MLS-based key distribution or other out-of-band key exchange mechanisms. Depending on the key management mechanism in use, a keyId MAY be scoped to:

• A single track
• A single MoQ Session
• Multiple tracks across one or more MoQ sessions

Publishers and subscribers MUST use the same key management system and agree on the keyId scope semantics for interoperable operation.

Recommended encryption scheme The RECOMMENDED encryption scheme for MSF is "moq-secure-objects". Implementations supporting content encryption MUST implement the "moq-secure-objects" scheme as defined in . When using the "moq-secure-objects" scheme:

• The cipherSuite field MUST be present and set to a supported cipher suite value
• The keyId field MUST be present to identify the key material
• The trackBaseKey field MUST be present to provide the base key material

Encrypted object structure For LOC-packaged tracks with encryption enabled (see ):

• The immutable header extensions (including Group ID and Object ID) remain in plaintext and are authenticated
• The object payload is encrypted and authenticated using the specified cipher
• Private header extensions (type 0xA) are encrypted alongside the payload

Catalog A Catalog is an MOQT Track that provides information about the other tracks being produced by a MSF publisher. A Catalog is used by MSF publishers for advertising their output and for subscribers in consuming that output. The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted. The Catalog provides the names and namespaces of the tracks being produced, along with the relationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. The catalog track MUST have a case-sensitive Track Name of "catalog". A catalog object MAY be independent of other catalog objects or it MAY represent a delta update of a prior catalog object. The first catalog object published within a new group MUST be independent and MUST provide a complete catalog that does not require any prior catalog object for interpretation. Any catalog updates that precede the first Object of the latest Group MUST be ignored. A catalog object SHOULD be published only when the availability of tracks changes, or after a period of time has passed such that the catalog object might fall out of cache in a delivery network. Each catalog update MUST be mapped to an MOQT Object. All catalog updates, both independent and delta, MUST be mapped to MOQT sub-group 0. The first Object (with Object ID 0) in any Group in a catalog track MUST hold an independent copy of the catalog. All subsequent Objects within that Group (i.e Objects IDs >= 1) MUST hold a delta update. As soon as an independent update is produced, it MUST be placed at the start of a new Group. Subscribers accessing the catalog MUST use SUBSCRIBE with a Joining FETCH (offset = 0) in order to obtain the latest complete catalog along with all subsequent catalog objects, including delta updates, that follow. A catalog is a JSON document, comprised of a series of mandatory and optional fields. At a minimum, a catalog MUST provide all mandatory fields. Some fields are conditional depending on the type of content carried. A producer MAY add additional fields to the ones described in this draft. Custom field names MUST NOT collide with field names described in this draft. A parser MUST ignore fields it does not understand.

Root Catalog Fields Table 1 lists the fields defined at the root of the catalog JSON object.

Field	Name	Definition
MSF version	version
Generated at	generatedAt
Is Complete	isComplete
Tracks	tracks
Publish tracks	publishTracks
Delta update	deltaUpdate
Initialization Data List	initDataList

MSF version Required: Yes JSON Type: String Location: Root Catalog Specifies the version of MSF referenced by this catalog. There is no guarantee that future catalog versions are backwards compatible and field definitions and interpretation may change between versions. A subscriber MUST NOT attempt to parse a catalog version which it does not understand. For usage against IETF Internet-Draft releases, follow the convention of specifying the version as "draft-XX". For example "draft-03" refers to the -03 draft release.

Generated at Required: Optional JSON Type: Number Location: Root Catalog The wallclock time at which this catalog instance was generated, expressed as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT). This field SHOULD NOT be included if the isLive field is false.

Is Complete Required: Optional JSON Type: Boolean Location: Root Catalog A catalog-level indication that the broadcast is complete. This is a commitment that all tracks are complete, no new tracks will be added to the catalog, and no new content will be published on any track. Note that even if all individual tracks have isLive set to FALSE, new tracks could still be added to the catalog until isComplete is set to TRUE. This field MUST NOT be included if it is FALSE. This field MUST NOT be removed from a catalog once it has been added.

Tracks Required: Yes JSON Type: Array Location: Root Catalog An array of track objects .

Publish tracks Location: R Required: Optional JSON Type: Array An array of publish track objects. Publish tracks define tracks to which the subscriber can publish data, such as logs, metrics, or other QoE data. This enables bi-directional communication where the subscriber acts as a publisher for specific tracks. Each publish track object follows the same structure as a regular track object but is used for the reverse direction of data flow.

Delta update Required: Optional JSON Type: Array Location: Root Catalog An ordered Array of operation objects that specify changes to apply to the catalog. If this field is present, the catalog represents a delta (or partial) update with a restricted set of fields and special processing rules - see . If this field is absent, the catalog is independent. Operations are applied sequentially in the order they appear in the array. Each operation object MUST contain an "op" field indicating the operation type, and a "tracks" field containing an Array of track objects . The following operation types are defined:

• "add" - Add new tracks that have not previously been declared. The value of the "tracks" field is an Array of track objects .
• "remove" - Remove tracks that have been previously declared. The value of the "tracks" field is an Array of track objects . Each track object MUST include a Track Name field, MAY include a Track Namespace field, and MUST NOT hold any other fields.
• "clone" - Clone new tracks from previously declared tracks. The value of the "tracks" field is an Array of track objects . Each track object MUST include a Parent Name field and MAY include a Parent namespace field. The cloned track inherits all attributes from the parent except the Track Name which MUST be new. Attributes redefined in the track object override inherited values.

Initialization Data List Required: Optional JSON Type: Array Location: Root Catalog An array of initialization reference objects. Each initialization reference object has the following fields:

• id : a string defining a reference to this initialization data which is unique within the scope of the catalog.
• type: as string defining the type of reference. This version of the specification defines a single allowed type, per the table below

Type	Data field definition
inline	Base64 encoded initialization data

• data: a string holding the init payload as defined by the type.

The Initialization Data List, if present, MUST be located after the tracks array in the root of the JSON catalog. The purpose of this is to improve the human readability of the catalog tracks by moving the verbose init data towards the end of the document.

Track Object Fields Table 2 lists the fields defined within each track object.

Field	Name	Definition
Track namespace	namespace
Track name	name
Packaging	packaging
Event timeline type	eventType
Is Live	isLive
Target latency	targetLatency
Buffers	buffers
Track role	role
Track label	label
Render group	renderGroup
Alternate group	altGroup
Initialization ref	initRef
Dependencies	depends
Temporal ID	temporalId
Spatial ID	spatialId
Codec	codec
Mime type	mimeType
Framerate	framerate
Timescale	timescale
Maximum Bitrate	bitrate
Average Bitrate	avgBitrate
Maximum GOP Duration	maxGopDuration
Maximum Group Duration	maxGroupDuration
Width	width
Height	height
Audio sample rate	samplerate
Channel configuration	channelConfig
Display width	displayWidth
Display height	displayHeight
Language	lang
Parent name	parentName
Parent namespace	parentNamespace
Track duration	trackDuration
Authorization Info	authInfo
Accessibility	accessibility

Tracks object A track object is a JSON Object containing a collection of fields whose location is specified in Table 2.

Track namespace Required: Optional JSON Type: String Location: Track Object The name space under which the track name is defined. See section 2.3 of . The track namespace is optional. If it is not declared within a track, then each track MUST inherit the namespace of the catalog track. A namespace declared in a track object overrides any inherited name space.

Track name Required: Yes JSON Type: String Location: Track Object A string defining the name of the track. See section 2.3 of . Within the catalog, track names MUST be unique per namespace.

Packaging Required: Yes JSON Type: String Location: Track Object A string defining the type of payload encapsulation. Allowed values are strings as defined in Table 3.

Name	Value	Reference
LOC	loc	See RFC XXXX
Media Timeline	mediatimeline	See
Event Timeline	eventtimeline	See
MoQ Log	moqlog	See
MoQ Metrics	moqmetrics	See

Table 3: Allowed packaging values

Event timeline type Required: Optional JSON Type: String Location: Track Object A String defining the type & structure of the data contained within the data field of the Event timeline track. Types are defined by the application provider and are not centrally registered. Implementers are encouraged to use a unique naming scheme, such as Reverse Domain Name Notation, where domain name components are listed in reverse order (e.g., "com.example.myeventtype"), to avoid naming collisions. This field is required if the value is "eventtimeline". This field MUST NOT be used if the packaging value is not "eventtimeline".

Track role Required: Optional JSON Type: String Location: Track Object A string defining the role of content carried by the track. Specified roles are described in Table 4. These role values are case-sensitive. This role field MAY be used in conjunction with the Mimetype to fully describe the content of the track. Table 4: Reserved track roles

Role	Description
audiodescription	An audio description for visually impaired users
video	Visual content
audio	Audio content
mediatimeline	An MSF media timeline
eventtimeline	An MSF event timeline
caption	A textual representation of the audio track
subtitle	A transcription of the spoken dialogue
signlanguage	A visual track for hearing impaired users.
log	A log publishing track per .
metrics	A metrics publishing track per .

Custom roles MAY be used as long as they do not collide with the specified roles.

Is Live Required: Yes JSON Type: Boolean Location: Track Object A track-level indication of whether new Objects will be added to this specific track. True if new Objects will be added to the track. False if no new Objects will be added to the track. A False value is sent under two possible conditions: * the publisher of a previously live track has ended the track. * the track is Video-On-Demand (VOD) and was never live. A True value MUST never follow a False value.

Target latency Required: Optional JSON Type: Number Location: Track Object The target latency in milliseconds. Target latency is defined as the offset in wallclock time between when content was encoded and when it is displayed to the end user. For example, if a frame of video is encoded at 10:08:32.638 UTC and the target latency is 5000, then that frame should be rendered to the end-user at 10:08:37.638 UTC. If isLive is FALSE, this field MUST be ignored. All tracks belonging to the same render group MUST have identical target latencies. All tracks belonging to the same alternate group MUST have identical target latencies. If this field is absent from the track definition, and isLive is TRUE, then the player MAY choose the latency with which it renders the content. This property MUST NOT be present if the buffers property is present within a track definition.

Buffers Required: Optional JSON Type: Object Location: Track Object An object defining a set of target buffers. Buffer is defined as the duration of media data that MUST be buffered before decoding commences. This is typically known as a forward or jitter-buffer in a media player.Players with identical buffer lengths are likely to be synchronized. The target buffer object has these keys:

• target : defines the target buffer in integer milliseconds. Players SHOULD attempt to stabilize playback at this value.
• min : defines the minimum buffer in milliseconds. Players SHOULD NOT operate below this value.
• max : defines the maximum buffer in milliseconds. Players SHOULD NOT operate above this value.

Keys are optional. Unknown keys in the target buffer object MUST be ignored. If isLive is FALSE, this target buffer property MUST be ignored. All tracks belonging to the same render group MUST have identical target buffers. All tracks belonging to the same alternate group MUST have identical target buffers. If this field is absent from the track definition, and isLive is TRUE, then the player MAY choose the buffers with which it conducts playback. This property MUST NOT be present if the target latency property is present within a track definition.

Track label Required: Optional JSON Type: String Location: Track Object A string defining a human-readable label for the track. Examples might be "Overhead camera view" or "Deutscher Kommentar". Note that the spec requires UTF-8 support by decoders.

Render group Required: Optional JSON Type: Number Location: Track Object An integer specifying a group of tracks which are designed to be rendered together. Tracks with the same group number SHOULD be rendered simultaneously and are designed to accompany one another. A common example would be tying together audio and video tracks.

Alternate group Required: Optional JSON Type: Number Location: Track Object An integer specifying a group of tracks which are alternate versions of one-another. Alternate tracks represent the same media content, but differ in their selection properties. Alternate tracks MUST have matching media time sequences. A subscriber typically subscribes to one track from a set of tracks specifying the same alternate group number. A common example would be a set video tracks of the same content offered in alternate bitrates.

Initialization reference Required: Optional JSON Type: String Location: Track Object A string pointing at the id field of an entry in the Initialization Data List .

Dependencies Required: Optional JSON Type: Array Location: Track Object Certain tracks may depend on other tracks for decoding. Dependencies holds an array of track names on which the current track is dependent. Since only the track name is signaled, the namespace of the dependencies is assumed to match that of the track declaring the dependencies.

Template Required: Optional JSON Type: Array Location: Track Object A media timeline template for tracks with fixed-duration segments. It specifies the relationship between media time, MOQT Location, and wallclock time through starting points and intervals. See for the complete format specification, field definitions, and computation formulas. Tracks that include a template field SHOULD NOT also have a separate media timeline track, as the template provides equivalent functionality. Different tracks (e.g., audio and video) MAY have independent template values to accommodate different group durations.

Temporal ID Required: Optional JSON Type: Number Location: Track Object A number identifying the temporal layer/sub-layer encoding of the track, starting with 0 for the base layer, and increasing by 1 for the next higher temporal fidelity.

Spatial ID Required: Optional JSON Type: Number Location: Track Object A number identifying the spatial layer encoding of the track, starting with 0 for the base layer, and increasing by 1 for the next higher fidelity.

Codec Required: Conditional JSON Type: String Location: Track Object A string defining the codec used to encode the track. For LOC packaged content, the string codec registrations are defined in Sect 3 and Section 4 of . This property MUST be specified for tracks which have an inherent codec associated with them (e.g., audio and video tracks). It is not required for raw data tracks or event streams.

Mimetype Required: Optional JSON Type: String Location: Track Object A string defining the mime type of the track.

Framerate Required: Optional JSON Type: Number Location: Track Object A number defining the framerate of the track, expressed as frames per second. This property SHOULD only accompany video or other frame-based content.

Timescale Required: Optional JSON Type: Number Location: Track Object The number of time units that pass per second.

Maximum Bitrate Required: Conditional JSON Type: Number Location: Track Object A number defining the maximum bitrate of the track, expressed in bits per second. This property MUST be specified for audio and video tracks.

Average Bitrate Required: Optional JSON Type: Number Location: Track Object A number defining the average bitrate of the track, over the lifetime of the track, expressed in bits per second.

Maximum GOP Duration Required: Optional JSON Type: Number Location: Track Object A number defining the maximum duration, expressed in milliseconds, between successive independently decodable points (random access points) in the media track. This property SHOULD only accompany video tracks.

Maximum Group Duration Required: Optional JSON Type: Number Location: Track Object A number defining the maximum duration, expressed in milliseconds, of any MOQT Group in this track. This value helps subscribers estimate buffer requirements for the track.

Width Required: Optional JSON Type: Number Location: Track Object A number expressing the maximum encoded width of the video frames in pixels. This property SHOULD accompany tracks which have a visual representation.

Height Required: Optional JSON Type: Number Location: Track Object A number expressing the maximum encoded height of the video frames in pixels. This property SHOULD accompany tracks which have a visual representation.

Audio sample rate Required: Conditional JSON Type: Number Location: Track Object The number of audio frame samples per second. This property MUST accompany tracks for which audio codecs are specified.

Channel configuration Required: Conditional JSON Type: String Location: Track Object A string specifying the audio channel configuration. A string is used in order to provide the flexibility to describe complex channel configurations for multi-channel and Next Generation Audio schemas. This property MUST accompany tracks for which audio codecs are specified.

Display width Required: Optional JSON Type: Number Location: Track Object A number expressing the intended display width of the track content in pixels. This property SHOULD only accompany tracks which have a visual representation.

Display height Required: Optional JSON Type: Number Location: Track Object A number expressing the intended display height of the track content in pixels. This property SHOULD only accompany tracks which have a visual representation.

Language Required: Optional JSON Type: String Location: Track Object A string defining the dominant language of the track. The string MUST be one of the standard Tags for Identifying Languages as defined by .

Parent name Required: Optional JSON Type: String Location: Track Object A string defining the parent track name to be cloned. This field MUST only be included inside a clone operation in a delta update .

Parent namespace Required: Optional JSON Type: String Location: Track Object A string defining the parent track namespace to be cloned. This field MUST only be included inside a clone operation in a delta update . If this field is missing from a clone operation, then the namespace of the catalog is assumed.

Track duration Required: Optional JSON Type: Number Location: Track Object The duration of the track expressed in integer milliseconds. This field MUST NOT be included if the isLive field value is true.

Connection URI Required: Optional JSON Type: String Location: Track Object A string containing the MOQT connection endpoint URI for the publish track. When specified, the subscriber MUST establish a new MOQT connection to this URI for publishing the track data. If this field is absent, the subscriber SHOULD reuse the existing MOQT connection that was used to receive the catalog. The URI MUST be a valid MOQT endpoint URI as defined by (Sect 3.1.1). Examples include "moqt://logs.example.com:4443", "moqt://metrics.example.com:8443", or "https://logs.example.com/moqt".

Token Required: Optional JSON Type: String Location: Track Object A string containing an authentication token or credential for the track. For publish tracks, this token authorizes the subscriber to publish data to the specified track. The format and validation of the token is application-specific.

Encryption scheme Required: Optional JSON Type: String Location: Track Object A string identifying the encryption scheme used to protect the track content. The default and RECOMMENDED value is "moq-secure-objects" as defined in . If this field is absent, the track content is unencrypted. Table 5: Registered encryption schemes

Name	Value	Reference
MoQ Secure Objects	moq-secure-objects

Custom encryption schemes MAY be used. Custom scheme names SHOULD use Reverse Domain Name Notation to avoid collisions (e.g., "com.example.custom-encryption").

Cipher suite Required: Optional JSON Type: String Location: Track Object A string identifying the AEAD cipher suite used for encryption. This field MUST be present when encryptionScheme is specified. For the "moq-secure-objects" scheme, the following cipher suites are defined: Table 6: Cipher suites for moq-secure-objects

Name	Value	Tag Size
AES-128-GCM-SHA256	aes-128-gcm-sha256	128 bits
AES-256-GCM-SHA512	aes-256-gcm-sha512	128 bits
AES-128-CTR-HMAC-SHA256-80	aes-128-ctr-hmac-sha256-80	80 bits

Implementations MUST support "aes-128-gcm-sha256". Implementations SHOULD support "aes-128-ctr-hmac-sha256-80" for scenarios requiring smaller authentication tags.

Key ID Required: Optional JSON Type: String Location: Track Object A string identifying the key material used for encryption. This value is transmitted in the Secure Object KID extension header as defined in () of each encrypted object. The keyId and associated trackBaseKey are obtained from an external key management system. The mechanism for obtaining these values is out of scope for this specification. Examples include MLS-based key distribution or other out-of-band key exchange mechanisms. The scope of a keyId is determined by the key management system in use. A keyId MAY be scoped to a single track, a single MSF session, or multiple tracks and sessions. When multiple tracks share the same Key ID, they MAY share the same base key material, though per-track keys are derived using the track name as defined in ().

Track Base Key Required: Optional JSON Type: String Location: Track Object A base64-encoded string containing the base key material for this track, as defined in (). This field works in conjunction with keyId to provide the cryptographic material needed for decryption. The trackBaseKey is obtained from the same key management system that provides the keyId. When present, this field contains the raw key material that, together with the track name and other parameters defined in (), is used to derive the actual encryption keys. Publishers and subscribers MUST use matching trackBaseKey values for successful decryption.

Authorization Info Required: Optional JSON Type: Object Location: Track Object An object indicating that authorization is required to access this track. The presence of this field signals to subscribers that they must obtain and present valid authorization tokens when subscribing to this track. The keys of this object are authorization scheme identifiers. Registered schemes are defined in Table 7. The values are scheme-specific configuration objects defined by the referenced specifications. Table 7: Registered Authorization Schemes

Scheme	Value	Reference
Privacy Pass	privacy-pass
CAT	cat

Custom authorization schemes MAY be used. Custom scheme names MUST use a unique naming convention, such as Reverse Domain Name Notation (e.g., "com.example.custom-auth"), to avoid naming collisions. Subscribers inspect the authInfo field to determine which authorization scheme to use and then obtain tokens through out-of-band mechanisms. The specific token format, acquisition process, and presentation method are defined by the authorization scheme specification.

Token Delivery via URI Tokens can be delivered to subscribers through the catalog request URI using variable substitution. Fragment parameters (following the # character) are processed client-side and can be substituted into catalog fields using the variable substitution mechanism defined in . For example, given a URI: A catalog with: Would be resolved by the subscriber to include "cat": "XYZ789", which is then presented in control messages as specified by the authorization scheme.

Accessibility Required: Optional JSON Type: Array Location: Track Object An array of accessibility descriptors indicating accessibility features embedded within the track. Each descriptor is a JSON Object containing:

• A required 'scheme' field (String) identifying the accessibility scheme.
• A required 'value' field (String) specifying the accessibility channels or features available.

Table 6: Registered accessibility schemes

Scheme	Description
urn:scte:dash:cc:cea-608:2015	CEA-608 closed captions
urn:scte:dash:cc:cea-708:2015	CEA-708 closed captions

The 'value' field for CEA-608/708 schemes uses the format defined by , where caption service channels are specified as semicolon-separated pairs of channel identifier and language code (e.g., "CC1=eng;CC3=spa"). A subscriber MAY use this information to determine caption availability and configure an appropriate caption decoder.

Delta updates A catalog update might contain incremental changes. This is a useful property if many tracks may be initially declared but then there are small changes to a subset of tracks. The producer can issue a delta update to describe these changes. Changes are described incrementally, meaning that a delta update can itself modify a prior delta update. A restricted set of operations are allowed with each delta update: * Add a new track that has not previously been declared. * Add a new track by cloning a previously declared track. * Remove a track that has been previously declared. The following rules are to be followed in constructing and processing delta updates:

• A delta update MUST include the Delta Update field with at least one operation. It MUST NOT contain an instance of a Tracks field or an MSF version field.
• Operations are applied sequentially in the order they appear in the deltaUpdate array. Each operation is applied to the target document; the resulting document becomes the target of the next operation. Evaluation continues until all operations are successfully applied.
• The tuple of Track Namespace and Track Name defines a fixed set of Track attributes which MUST NOT be modified after being declared. To modify any attribute, a new track with a different Namespace|Name tuple is created by Adding or Cloning and then the old track is removed.
• Producers that publish frequent delta updates SHOULD periodically publish a new independent catalog in a new MOQT Group in order to bound the amount of delta processing required for joining subscribers.

Variable Substitution Catalog field values MAY contain variables that are substituted at delivery time. This mechanism enables a single cached catalog to be customized for each viewer, supporting use cases such as personalized advertising, A/B watermarking, QoE reporting endpoints, and logging identifiers.

Variable Syntax Variables are denoted by enclosing the variable name in percent characters (%). Variable names MUST consist of alphanumeric characters, hyphens, and underscores. Variable names are case-sensitive. The percent character (%) MUST NOT appear in catalog field values except as part of a variable reference. Literal percent characters are not permitted. Variable values MUST consist only of alphanumeric characters, hyphens, underscores, and the at sign (@). Special characters including commas, semicolons, quotes, ampersands, and other punctuation MUST NOT appear in variable values. This restriction prevents injection attacks and ensures safe substitution into catalog field values.

Variable Resolution Variables are resolved from the fragment identifier of the URI used to access the catalog. The fragment identifier is the portion following the # character and is processed entirely client-side, making it suitable for per-viewer customization without affecting server-side caching. Query parameters (following the ? character) are reserved for server-side processing and MUST NOT be used for variable substitution. When a subscriber requests a catalog using a URI containing a fragment identifier, the fragment is parsed as key-value pairs (using & as delimiter and = as separator). Each key becomes available as a variable name, and the variable is replaced with the corresponding value.

Catalog Compression Catalogs can contain significant redundancy, particularly when initialization data is included. To reduce payload size, catalog objects MAY be compressed using the MSF_COMPRESSION property (). If all catalog objects are compressed, the track property () is used. If only some catalog objects are compressed (for example, the complete catalog is compressed while delta updates are not), the object property () is used on each compressed object.

Catalog Examples The following section provides non-normative JSON examples of various catalogs compliant with this draft.

Time-aligned Audio/Video Tracks with single quality This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks.

Simulcast video tracks - 3 alternate qualities along with audio This example shows a catalog for a media producer capable of sending 3 time-aligned video tracks for high definition, low definition and medium definition video qualities, along with an audio track. In this example the namespace is absent, which infers that each track must inherit the namespace of the catalog.

SVC video tracks with 2 spatial and 2 temporal qualities This example shows a catalog for a media producer capable of sending scalable video codec with 2 spatial and 2 temporal layers with a dependency relation as shown below: | S1T1 | | | 1080p30 | | +----------+ | ^ | | +----------+ | | S1TO | | | 1080p15 | | +----------+ +-----+----+ ^ | SOT1 | | | 480p30 | | +----------+ | ^ +----------+ | | SOTO | | | 480p15 |---------+ +----------+ ]]> The corresponding catalog uses "depends" attribute to express the track relationships.

Delta update - adding two tracks This example shows the catalog delta update for a media producer adding two tracks to an established video conference. One track is newly declared, the other is cloned from a previous track.

Delta update removing tracks This example shows a delta update for a media producer removing two tracks from an established video conference.

Time-aligned Audio/Video Tracks with custom field values This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks along with custom fields in each track description.

Time-aligned VOD Audio/Video Tracks This example shows a catalog for a media producer offering VOD (video on-demand) non-live content. The content is LOC packaged, and includes time-aligned audio and video tracks.

Encrypted Audio/Video Tracks This example shows a catalog for encrypted LOC-packaged audio and video tracks using MoQ Secure Objects with AES-128-GCM.

Media timeline and Event timeline This example shows a catalog for a media producer capable of sending LOC packaged, time-aligned audio and video tracks, along with a Media Timeline which describes the history of those tracks and an Event Timeline providing synchronized data.

Media timeline template This example shows a catalog using inline media timeline templates instead of an explicit media timeline track. The attribute on each track defines a regular pattern where each segment is 2002ms long. Clients can compute any entry using the template parameters. Note that different tracks MAY have different template values to accommodate different group durations.

Video track with embedded captions and SCTE-35 events This example shows a live broadcast with CEA-608 closed captions embedded in the video track and a separate SCTE-35 event timeline for ad insertion.

Video track with CEA-708 captions This example shows a live broadcast with CEA-708 closed captions embedded in the video track, demonstrating multiple caption services.

Terminating a live broadcast This example shows a catalog for a media producer terminating a previously live broadcast containing a video and an audio track.

Variable Substitution for personalized delivery This example shows a catalog using variable substitution to enable personalized advertising and reporting while maintaining cacheability. Given a catalog request URI of: The fragment parameters (token, id, event) are available for variable substitution. The following catalog template: Would be resolved by the subscriber as:

Time-aligned Audio/Video Tracks with Authorization This example shows a catalog for a media producer requiring authorization for premium content. The premium 4K track uses CAT authorization with a token resolved via variable substitution from %cat-token%. The standard 720p track uses Privacy Pass with a token resolved from %pp-token%. Token presentation timing is determined by the authorization scheme specification.

Publish tracks for logs and metrics This example shows a catalog that includes publish tracks for client-side logging and metrics collection. The subscriber can publish QoE data and logs back to the delivery system using these track definitions. The namespace and track name formats follow the conventions defined in and . In this example:

• The metrics track uses the namespace format defined in with %resourceId% as a placeholder for the subscriber's unique resource identifier. The track name "4" indicates Warning level granularity.
• The log track uses the namespace format defined in with %resourceId% as a placeholder. The track name "6" indicates Informational level priority. This track establishes a separate connection to logs.example.com.
• Both tracks include authentication tokens for publishing authorization.
• The subscriber MUST replace %resourceId% with their actual resource identifier as defined in the respective specifications.

Media transmission The MOQT Groups and MOQT Objects need to be mapped to MOQT Streams. Irrespective of the in place, each MOQT Object MUST be mapped to a new MOQT Stream.

Group numbering Group IDs for a track MUST be unique and MUST increase monotonically. Within a continuous publishing session, each subsequent Group ID SHOULD increase by 1. When a publisher restarts (e.g., after connectivity loss or encoder restart), it MUST ensure the new starting Group ID is greater than any previously published Group ID for that track. One approach is to use the current wall clock time in milliseconds since the Unix epoch as the starting Group ID. If a publisher maintains state across a restart and knows the previous Group ID, it SHOULD signal the gap using the MOQT Prior Group ID Gap Extension header.

Object Numbering Object ID MUST be zero for the first Object within a Group and then MUST increase monotonically by one within that Group.

Media Timeline track The media timeline track provides data about the previously published Groups and their relationship to wallclock time and media time. Media timeline tracks allow players to seek to precise points behind the live head in a live broadcast, or for random access in a VOD asset. Media timeline tracks are optional. Multiple media timeline tracks can exist inside a catalog.

Media Timeline track payload A media timeline track is a JSON document. This document MAY be compressed using the MSF_COMPRESSION property (). The document supports two formats: an explicit entry format and a template format. Publishers MAY combine both formats in a single document.

Explicit entry format The explicit format contains an array of records. Each record consists of an array of three required items, whose ordinal position defines their type:

• The first item holds the media presentation timestamp, expressed as a JSON Number. This value MUST match the media presentation timestamp, expressed as the floor in integral milliseconds, of the first media sample in the referenced Object. Implementers who require increased time precision can parse the retrieved media object itself.
• The second item holds the MOQT Location of the entry, defined as a tuple of the MOQT Group ID and MOQT Object ID, and expressed as a JSON Array of Numbers, where the first number is the Group ID and the second number is the Object ID.
• The third item holds the wallclock time at which the media was encoded, defined as the number of milliseconds that have elapsed since January 1, 1970 (midnight UTC/GMT) and expressed as a JSON Number. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0.

An example media timeline is shown below:

Media Timeline Catalog requirements A media timeline track MUST carry a 'type' identifier in the Catalog with a value of "mediatimeline". A media timeline track MUST carry a 'depends' attribute which contains an array of all track names to which the media timeline track applies. The mime-type of a media timeline track MUST be specified as "application/json".

Media Timeline track updating The publisher MUST publish an independent media timeline in the first MOQT Object of each MOQT Group of a media timeline track. An independent media timeline object MUST contain all media timeline records accumulated and accessible up to that point, allowing a subscriber joining at any group boundary to receive the accessible timeline history. The publisher MAY publish incremental updates in the second and subsequent Objects within each Group. Incremental updates contain only new media timeline records since the previous media timeline Object in that Group.

Media Timeline Template When the relationship between media time, MOQT Location and wallclock time follows a regular, predictable pattern, a media timeline template MAY be used instead of an explicit media timeline track. The template approach is best suited for content with fixed-duration segments, such as VOD assets or live broadcasts with constant segment durations. For content with variable segment durations, the explicit media timeline track () MUST be used instead.

Template Format A media timeline template is expressed as an inline track attribute using the field. The template is a JSON Array containing six mandatory values in the following fixed order:

1. startMediaTime - The media presentation timestamp of the first entry, as defined for media timeline entries in .
2. deltaMediaTime - The constant interval between media presentation timestamps, expressed as a JSON Number in milliseconds.
3. startLocation - The MOQT Location of the first entry, as defined for media timeline entries in .
4. deltaLocation - The constant interval between MOQT Locations, expressed as a JSON Array of two Numbers where the first number is the Group ID delta and the second number is the Object ID delta.
5. startWallclock - The wallclock time of the first entry, as defined for media timeline entries in . For VOD assets, or if the wallclock time is not known, the value SHOULD be 0.
6. deltaWallclock - The constant interval between wallclock times, expressed as a JSON Number in milliseconds. For VOD assets, or if the wallclock time is not known, the value SHOULD be 0.

All six values are mandatory and MUST appear in the specified order. Clients compute entry values using the following formulas, where n is the zero-based entry index: An example template value is shown below: This template indicates that the first entry has media time 0ms, location [0,0], and wallclock time 1759924158381. Each subsequent entry increments media time by 2002ms, location by [1,0] (next group, same object), and wallclock by 2002ms.

Template Immutability Unlike the explicit media timeline track, the media timeline template is intended to be immutable once publishing starts. Publishers MUST NOT change the template values for a track after the first Object has been published.

Event Timeline track The event timeline track provides a mechanism to associate ad-hoc event metadata with the broadcast. Use-case examples include live sports score data, GPS coordinates of race cars, SAP-types for media segments or active speaker notifications in web conferences. To allow the client to bind this event metadata with the broadcast content described by the media timeline track, each event record MUST contain a reference to one of Media PTS, wallclock time or MOQT Location. Event timeline tracks are optional. Multiple event timeline tracks can exist inside a catalog. The type & structure of the data contained within each event timeline track is declared in the catalog, to facilitate client selection and parsing.

Event Timeline data format An event timeline track is a JSON document. This document MAY be compressed using the MSF_COMPRESSION property (). The document contains an array of records. Each record consists of a JSON Object containing the following required fields:

• An index reference, which MUST be either 't' for wallclock time, 'l' for Location or 'm' for Media PTS. Only one of these index values may be used within each record. Event timelines SHOULD use the same index reference type for each record. The definitions for wallclock time, Location and Media PTS are identical to those defined for media timeline payload . Wallclock time and media PTS values are JSON Number, while Location value is an Array of Numbers, where the first item represents the MOQT GroupID and the second item the MOQT Object ID.
• A 'data' Object, whose structure is defined by the value declared for this track in the Catalog.

Event Timeline Catalog requirements An event timeline track MUST carry:

• a attribute with a value of "eventtimeline".
• a attribute which contains an array of all track names to which the event timeline track applies.
• a attribute with a value of "application/json".
• an attribute declaring the type & structure of data contained in the event timeline track.

Event Timeline track updating The publisher MUST publish an independent event timeline in the first MOQT Object of each MOQT Group of an event timeline track. An independent event timeline object MUST contain all event timeline records accumulated and accessible up to that point, allowing a subscriber joining at any group boundary to receive the accessible event history. The publisher MAY publish incremental updates in the second and subsequent Objects within each Group. Incremental updates contain only new event timeline records since the previous event timeline Object in that Group.

Event timeline track examples

Event timeline track with wallclock time indexing This example shows how sports scores and game information might be defined in a live sports broadcast.

Event timeline track with MOQT Location indexing This example shows drone GPS coordinates synched with the start of each Group.

Log track Log tracks provide a mechanism for subscribers to publish diagnostic and operational log data back to the delivery system. This enables QoE monitoring, debugging, and analytics collection. Log tracks are defined in the catalog's publishTracks array with a packaging value of "moqlog".

Log track payload The log track payload format is defined in . Each MOQT Object contains a single JSON-formatted log entry. The log entry structure includes optional fields such as severity, timestamp, hostname, application name, process ID, message ID, and the log message itself. Additional structured data fields support distributed tracing integration with TraceID, SpanID, and InstrumentationScope aligned with OpenTelemetry specifications. Implementations MUST follow the object payload format specified in Section 4 of .

Log track namespace and name TODO: Finalize on track naming Log tracks MUST use the namespace and track name format defined in Section 3 of . The Track Namespace consists of the tuples: (moq://moq-syslog.arpa/logs-v1/),(resourceID) where resourceID is a unique identifier for the publishing resource. The Track Name is a single byte containing the log priority level in binary. Priority levels range from 0 (Emergency) to 7 (Debug), following syslog severity conventions.

Log track Group ID and Object ID The Group ID represents the timestamp at which the log entry was captured, truncated to a 62-bit binary integer representing microseconds since the Unix epoch. This allows log entries to be naturally ordered by time within the MOQT object model. The Object ID is set to zero for a log entry unless multiple log messages occur within the same microsecond, in which case the Object ID increments to distinguish between messages captured at the same timestamp.

Log track catalog requirements A log track MUST be declared in the publishTracks array of the catalog with:

• a attribute with a value of "moqlog".
• a attribute with a value of "log".

A log track MAY include:

• a attribute if logs should be published to a different endpoint.
• a attribute for publish authorization.

Metrics track Metrics tracks provide a mechanism for subscribers to publish quantitative measurements back to the delivery system. This enables QoE analytics, performance monitoring, and operational dashboards. Metrics tracks are defined in the catalog's publishTracks array with a packaging value of "moqmetrics".

Metrics track payload The metrics track payload format is defined in . The data model consists of Resources (systems generating metrics identified by ResourceID), optional Attributes (dimensional key-value pairs), and Metrics (named measurements with timeseries values). defines two metric value types - Gauge and Counter. Both value types support either 64-bit floating point or integer representation. Implementations MUST follow the object payload format specified in Section 3 of .

Metrics track namespace and name TODO: Finalize the track naming. Metrics tracks MUST use the namespace and track name format defined in Section 3 of . The Track Namespace consists of the tuples: (moq://metrics.moq.arpa/v1/),(resourceID) where resourceID is a unique identifier for the publishing resource. The Track Name identifies the granularity level for the metrics being published, specified as a single tuple (<granularity-level>) where granularity-level is a value from 0 (Emergency) to 7 (Debug). Higher priority levels (lower numbers) indicate more critical metrics that should always be reported.

Metrics track Group ID and Object ID The Group ID represents the capture time as the number of milliseconds since January 1, 1970 (Unix epoch). This allows metrics to be naturally grouped and ordered by their capture timestamp within the MOQT object model. Within each Group, Object IDs are assigned as follows:

• Object ID 0: Contains the capture timestamp as Unix epoch time in nanoseconds, along with any optional attributes for the metrics in this group.
• Object ID 1 and above: Each subsequent Object contains an individual metric as a name-value pair.

This structure allows a single capture event to include multiple metrics while maintaining efficient MOQT caching and distribution.

Metrics track catalog requirements A metrics track MUST be declared in the publishTracks array of the catalog with:

• a attribute with a value of "moqmetrics".
• a attribute with a value of "metrics".

A metrics track MAY include:

• a attribute if metrics should be published to a different endpoint.
• a attribute for publish authorization.

Well-known event timeline types Event timelines can carry various types of broadcast metadata synchronized with media content. The "MSF Event Timeline Types" registry () maintains a list of well-known event types. Publishers SHOULD use registered types when applicable to ensure interoperability. Event timelines can carry data types including but not limited to:

• Ad insertion signaling (e.g., SCTE-35 splice points) - see
• Out-of-band timed-text cues (WebVTT, IMSC1) - see and
• Sports scores and game state
• GPS coordinates and telemetry
• Active speaker notifications
• Custom application-specific metadata

The packaging format and data structure for each event type is defined by the specification referenced in the registry. Custom event types not in the registry SHOULD use Reverse Domain Name Notation (e.g., "com.example.myeventtype") to avoid naming collisions.

Workflow

URL construction and interpretation An MSF URL identifies a MOQT session and an optional sub-resource within that session. It inherits the MOQT URI scheme defined in and extends it to add a fragment definition, which defines the type, the namespace and name of the track along with optional key-value attributes. The MOQT specification carries the normative definition of these components, along with processing instructions. They are repeated here for clarity. In the event of any conflict, the definition in is authoritative.

• Scheme: This case-insensitive scheme defines the underlying transport. The client may use either a WebTransport or native QUIC connection. A moqt URI can be converted to an https URI by replacing the scheme, so the path-abempty and query components use the same syntax as https URIs.
• Authority: Required. Contains the host and optional port (defaulting to 443). This information is used by the client to establish the transport session.
• Path: Optional. If present, it provides server-specific configuration or routing information used during connection initialization.
• Query: Optional. Contains key-value parameters separated by &. If the query is absent, the ? separator MUST be omitted. Query arguments are intended for the server and SHOULD be ignored by the client.

This specification registers a fragment type of "msf" in the "MOQT URI Fragment Types" registry established by (see ). This type is required for any URL defining an MSF resource. The value of this type is the msf-fragment-value. The msf-fragment is defined by the following ABNF: The msf-fragment-value identifies a specific Track. The track-identifier MUST be formatted as an MSF namespace-name string (see ). The client uses this identifier to initiate a SUBSCRIBE or FETCH command once the transport session is established. The namespace-name string MAY be followed by a series of key-value parameters, each separated from the preceding element by &. These key-value parameters are intended for processing by the client and, being part of the fragment, are not transferred to the server at connection time. Certain of the fragment key-value parameters have a reserved meaning, as defined by .

Reserved fragment parameters Table 8 defines reserved key names for the parameter portion of the msf-fragment. Keynames are case-sensitive.

Name	Description
wallclock-range	A subclip defined by a wallclock time range
mediatime-range	A subclip defined by a media time range
location-range	A subclip defined by a MOQT Location range
c4m	A base64 encoded C4M token
connection	Mandates a connection type

• wallclock-range - a range defined by start and end wallclock times, each expressed as milliseconds since Unix Epoch and separated by a "-" dash. The dash and end time MAY be omitted to indicate an open range. The range definition is inclusive.
• mediatime-range - a range defined by start and end media times, each expressed as milliseconds and separated by a "-" dash. The dash and end time MAY be omitted to indicate an open range. The range definition is inclusive.
• location-range - a range defined by start and end media MOQT Location separated by a "-" dash. Range definitions are inclusive. MOQT Location is expressed as Group ID and Object ID separated by a "." dot. End Location may be omitted to indicate an open range which continues to the end of the content. End Object ID may be omitted, indicating the whole end group is included in the range. The "." dot and "-" dash separators MUST be omitted when the second value is omitted.
• c4m - a base64 encoded token, as defined by .
• connection - mandates the client to use a particular connection type when connecting to the server. There are two allowed values - "q" or "wt". "q" indicates that a Native QUIC connection MUST be used. "wt" indicates that a WebTransport connection MUST be used.

If multiple ranges are specified within the same URL for the same parameter, the client MUST process the union of those ranges. Example fragment parameters:

• connection=q
• connection=wt
• wallclock-range=1761759637565-1761759836189
• wallclock-range=1761751753894
• mediatime-range=0-13421
• mediatime-range=982
• location-range=34.0-2145.16
• location-range=16.24 (open range starting at Group ID 16 Object ID 24)
• location-range=16-24 (range from Group ID 16 through to and including all Objects in Group ID 24)
• c4m=gqhkYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5uZWlhdGVwQWNyZW5lY

MSF Namespace-Name String Encoding To represent MoQ Tuples (which are sequences of byte strings) within the URL fragment, MSF uses a specific encoding convention, which is normatively defined by MOQT and repeated here for convenience:

• Hierarchy: Each element of the Namespace tuple is rendered in order, separated by a single hyphen (-).
• Delimiter: The Track Name is appended to the end, separated from the namespace by a double hyphen (--).
• Character Escaping:
  • Unreserved characters (a-z, A-Z, 0-9, _) are represented literally.
  • All other byte values (including hyphens and periods used as data) MUST be percent-encoded using a period (.) followed by two lowercase hexadecimal digits (e.g., a literal hyphen in a name becomes .2d).

Note: This encoding ensures that the structural delimiters (- and --) remain unambiguous.

Example MSF URLs

• URL pointing at a catalog track (either WebTransport or native QUIC may be used): moqt://example.com/server/config?a=1&b=2#msf:customer-livestream-123--catalog
  • Session: example.com/server/config?a=1&b=2
  • Streaming format type: msf
  • Namespace: ('customer', 'livestream', '123')
  • Track Name: 'catalog'
• URL with a required raw QUIC connection pointing at a catalog: moqt://example.com/relay-app/relayID#msf:customerID-broadcastID--catalog&connection=q
• URL pointing at a non-catalog track, with a required WebTransport connection moqt://example.com/relay-app/relayID#msf:customerID-broadcastID--video&connection=wt
• URL pointing at a subclip: moqt://example.com/relay-app/relayID#msf:customerID-broadcastID--catalog&location-range=34-64
• URL pointing at a catalog and supplying a token for the client: (linebreaks for display only) moqt://example.com/relay-app/relayID#msf:customerID-broadcastID-- catalog&c4m=gqhkYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2 aW5uZWlhdGVwQWNyZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xNzMwNDM
• URL pointing at a catalog and supplying a token for the client along with a separate token for the server: (linebreaks for display only) moqt://example.com/relay-app/relayID?token=HTRCII74GHFT@JHBCV SW56HKKneH2Dbyq6NHBI2#msf:customerID-broadcastID--catalog&c4m=gqh kYWxnIGVzaGFyqGR0eXBNhdZ9hdWQAY3VybGZlbWlzcwZleWV2aW5uZWlhdGVwQWN yZW5lYnJmcmVqMTIzNDU2NzgwMHZpc3VlZF9hdD0xNzMwNDM

Initiating a broadcast An MSF publisher MUST publish a catalog track object before publishing any media track objects.

Ending a live broadcast After publishing a catalog and defining tracks carrying live content, an original publisher can deliver a deterministic signal to all subscribers that the broadcast is complete by taking the following steps:

• Send a SUBSCRIBE_DONE (See MOQT Sect 8.1.2) message for all active tracks using status code 0x2 Track Ended.
• If the live stream is being converted instantly to a VOD asset, then publish an independent (non-delta) catalog update which, for each track, sets isLive to FALSE and adds a track duration field.
• If the live stream is being terminated permanently without conversion to VOD, then publish an independent catalog update which signals isComplete as TRUE and which contains an empty Tracks field.

Authorization MSF supports token-based authorization through pluggable authentication schemes. Both original publishers and end subscribers can independently acquire authorization tokens and present them to relays. Relays use these tokens to authorize whether an end subscriber is permitted to setup the connection, as well as to receive content and/or to send content.

Discovering Authorization Requirements End subscribers discover authorization requirements by parsing the catalog. For each track of interest, examine the authInfo field. If present, the track requires authorization and the subscriber must obtain appropriate credentials for one of the schemes listed in the field. Original publishers and end subscribers may obtain authorization tokens from multiple sources, including out-of-band provisioning or as a parameter in the connection URI. These tokens can be presented either in the connection setup message (CLIENT_SETUP) or in control messages (SUBSCRIBE, FETCH, PUBLISH, PUBLISH_NAMESPACE) as described in .

Token Acquisition Token acquisition is out of scope for this specification. Both original publishers and end subscribers independently obtain tokens through mechanisms such as:

• Direct authentication with a distribution service
• OAuth 2.0 or OpenID Connect flows
• Out-of-band provisioning

The token acquisition endpoint and flow depend on the authorization scheme and deployment configuration. Original publishers and end subscribers MAY use the same or different authorization services depending on the deployment. Tokens MAY also be supplied as parameters in the connection URI. When a connection URI contains token parameters, the subscriber extracts the token value and includes it in the appropriate MOQT message. For example: URI parameters provide a convenient mechanism for distributing pre-authorized playback links. The parameter name and format are deployment-specific.

Presenting Authorization Once tokens are obtained, both original publishers and end subscribers present them to relays according to the scheme specification. Tokens MAY be presented in the SETUP message (CLIENT_SETUP or SERVER_SETUP) using the AUTHORIZATION TOKEN setup parameter, or in individual control messages using the AUTHORIZATION TOKEN message parameter. When a token is associated with a track, it MUST be included in ALL control messages that accept the AUTHORIZATION TOKEN parameter and are associated with that track. For end subscribers, this includes SUBSCRIBE, SUBSCRIBE_NAMESPACE, FETCH, and REQUEST_UPDATE messages. For original publishers, this includes PUBLISH and PUBLISH_NAMESPACE messages. This requirement applies regardless of whether the token was also provided in SETUP.

Handling Authorization Failures When a relay rejects an authorization token, subscribers SHOULD handle the failure gracefully:

• If a SUBSCRIBE or FETCH request is rejected due to invalid or expired authorization, the subscriber MAY attempt to obtain a fresh token and retry the request.
• If a token is rejected due to insufficient scope, the subscriber SHOULD NOT retry with the same token.
• For interactive applications, subscribers MAY prompt users to re-authenticate when authorization fails.
• Subscribers SHOULD implement exponential backoff when retrying failed authorization attempts to avoid overwhelming the relay or token issuer.

The specific error codes and retry semantics are defined by the authorization scheme specifications. See for Privacy Pass error handling and for CAT error handling.

MSF Properties MSF defines MOQT Track Properties and Object Properties (see ) to signal metadata about MSF tracks and objects. These properties are carried in MOQT control messages and object headers, allowing endpoints to learn track and object characteristics before processing payload data.

Compression Signaling MSF provides two mutually exclusive mechanisms to signal compression of track payloads, including catalogs (), media timeline tracks (), and event timeline tracks (). Publishers MUST use one of the following approaches:

• Track Property (): Signals that ALL objects in the track are compressed using the specified algorithm.
• Object Property (): Signals compression on individual objects, allowing a mixture of compressed and uncompressed objects within the same track.

A publisher MUST NOT use both mechanisms on the same track. If the track property is set, then every object in the track is compressed and the object property MUST NOT be present. If compression varies between objects, then the track property MUST NOT be set and the object property MUST be used on each compressed object. The compression algorithm values used by both mechanisms are:

Value	Compression Algorithm	Reference
0	None (uncompressed)	RFC XXXX
1	GZIP

Table: MSF Compression Values All MSF implementations MUST support both uncompressed payloads (value 0 or property absent) and GZIP compressed payloads (value 1).

MSF_COMPRESSION Track Property The MSF_COMPRESSION track property signals that ALL objects in the track are compressed using the specified algorithm. This mechanism is appropriate when every object published on the track uses the same compression. Publishers MUST include the MSF_COMPRESSION track property in the PUBLISH message (publisher-initiated flow) or SUBSCRIBE_OK (subscriber-initiated flow). Subscribers MUST check for this property in the corresponding message before processing the track payload. If the property is absent, and no per-object compression is signaled, the subscriber MUST treat the payload as uncompressed. If the property is present with a value the subscriber does not support, the subscriber MUST NOT attempt to process the payload and SHOULD unsubscribe from the track.

MSF_COMPRESSION Object Property The MSF_COMPRESSION object property signals that an individual object is compressed. This mechanism is appropriate when a track contains a mixture of compressed and uncompressed objects. For example, a catalog track where the first object in a group (the complete catalog) is compressed, but subsequent delta update objects within the same group are uncompressed. Publishers MUST include the MSF_COMPRESSION object property on each compressed object. Subscribers MUST check for this property on each received object before processing its payload. If the property is absent on an object, the subscriber MUST treat that object's payload as uncompressed. If the property is present with a value the subscriber does not support, the subscriber MUST NOT attempt to process that object.

Security Considerations ToDo

IANA Considerations

"MOQT URI Fragment Types" registry This document creates a new entry in the "MOQT URI Fragment Types" registry (see Sect 14.3).

Fragment Type	Description	Specification
msf	MOQT Streaming Format	this

"MSF Event Timeline Types" registry This document establishes the "MSF Event Timeline Types" registry. This registry lists the event types that can be used with the eventType field in MSF catalogs. New entries in this registry are subject to Expert Review policy as defined in . The initial contents of this registry are:

Event Type	Description	Specification
urn:scte:scte35:2013:bin	SCTE-35 binary splice_info_section
urn:scte:scte35:2013:xml	SCTE-35 XML representation
urn:msf:timedtext:webvtt	WebVTT timed text cues
urn:msf:timedtext:imsc1	IMSC1 timed text cues

MSF_COMPRESSION Track Property This document requests IANA to register the following entry in the "Track Properties" registry established by (Section 14.4):

Property Name	Property ID	Value Type	Reference
MSF_COMPRESSION	TBD	varint	RFC XXXX

The MSF_COMPRESSION track property indicates that ALL objects on the track are compressed using the specified algorithm. See for the full specification.

MSF_COMPRESSION Object Property This document requests IANA to create a new "MSF Compression Algorithms" registry with the following initial values:

Value	Compression Algorithm	Reference
0	None (uncompressed)	RFC XXXX
1	GZIP

Values 2-127 are available for registration via Standards Action. Values 128 and above are reserved for private use.

References Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Cisco Cisco Microsoft This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the MOQT Streaming Format (MSF) specification, which defines a catalog format for publishers to declare and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. Cisco Cisco Cisco This document specifies an end-to-end authenticated encryption scheme for application objects transmitted via Media over QUIC (MoQ) Transport. The scheme enables original publishers to securely share a symmetric key with end subscribers, ensuring that MoQ relays are unable to decrypt object contents. Additionally, subscribers can verify the integrity and authenticity of received objects, confirming that the content has not been modified in transit. Akamai Comcast Synamedia Cisco A token-based authentication scheme for use with Media Over QUIC Transport. Cisco Cisco Cloudflare Inc. This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Cisco Cisco Real time systems often run into the problems where the network bandwidth for logging in shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is blow the peak rate while not impact the peak rate available for media. This document specifies how to send syslog RFC5424 type information over the Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport]. Cisco Cisco This document specifies how to send metrics type information over the Media Over QUIC Transport (MOQT). Many systems produce significant volumes of metrics which either are not all needed at the same time for consumption by collection/ aggregation endpoints or may also compete for bandwidth with the primary application, thus exacerbating congestion conditions especially in low-bandwidth networks. Delivering these over architectures enabled by publish/subscribe transport like Media Over QUIC Transport (MOQT) [I-D.ietf-moq-transport], allows metrics data to be prioritized within the congestion context of the primary application as well as enabling local nodes to cache the metric value to be later retrieved via new subscriptions. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Cisco Cisco Cisco The Media over QUIC system allows relays to assist in the delivery of real-time media. While these relays are trusted to facilitate media delivery, they are not trusted to access the media content. The document describes an end-to-end security system that prevents relays from accessing media content. MLS is used to establish keys that are available only to legitimate participants in a session, which are then used to protect media data using SFrame.

Acknowledgments

• the MoQ Workgroup and mailing lists.

Contributors The following persons where the co-authors of the individual draft (draft-law-moq-warpstreamingformat) this document is based on:

• Luke Curley
• Victor Vasiliev
• Suhas Nandakumar
• Kirill Pugin
• Will Law