| Internet-Draft | CMCD over MSF | August 2026 |
| Law | Expires 11 February 2027 | [Page] |
Defines the transmission of CMCD data over MSF Event Timeline tracks.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://wilaw.github.io/CMCD-over-MSF-event-timeline/draft-wilaw-moq-cmcd-event-timeline-latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wilaw-moq-cmcd-event-timeline/.¶
Source for this draft and an issue tracker can be found at https://github.com/wilaw/CMCD-over-MSF-event-timeline.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
MOQT Streaming Format [MSF] defines Event Timeline tracks as a generic mechanism for transmitting ad hoc data associated with MSF media tracks. CMCD [CMCD] defines a means by which a media player can communicate structured data and have it processed consistently by delivery networks and third-party data collection services. This draft specifies how an MSF catalog can instruct a publisher to publish configurable CMCD data at a target destination using MSF Event Timeline tracks.¶
This specification defines transmission for version 2 of CMCD.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
CMCD supports two reporting modes - Request Mode and Event Mode. Since Request mode is tied to HTTP requests, which are not present in MOQT, this specification constrains CMCD usage to those options offered in Event Mode. Request mode MUST NOT be used.¶
Furthermore, there are certain keys under Event Mode which reference request semantics and therefore are not allowed in this specification. The keys which MUST NOT be used are: 'ab', 'cmsdd', 'cmsds', 'd', 'dl', 'h', 'lab', 'nor', 'nr', 'ot', 'rc', 'rtp', 'sf', 'smrt', 'su', 'tab', 'ttfb', 'ttfbb', 'ttlb' and 'url'.¶
The following keys MAY be used in Event Mode: 'bl', 'bg', 'br', 'bs', 'bsa', 'bsd', 'bsda', 'cen', 'cid', 'cs', 'dfa', 'e', 'ec', 'lb', 'ltc', 'msd', 'mtp', 'pb', 'pr', 'pt', 'sid', 'sn', 'st', 'sta', 'tb', 'tbl' and 'tpb'.¶
The Event key 'e' MUST NOT use the 'h' and 'rr' tokens. While the 'ts' data is mandatory for every report, it is transmitted as the index value of each event timeline record.¶
When the CMCD spec refers to a 'manifest' in the description of a key, interpret that as the 'catalog' in the context of this specification.¶
The version key 'v' MUST be present in each report and MUST carry a value of 2.¶
A broadcaster triggers a catalog recipient to send CMCD data by including a 'publishTracks' (see [MSF] Section 5.1.5) entry. That entry MUST point at a CMCD track Section 4.2. Multiple CMCD tracks MAY be included in the publishTracks array in order to target data at different destinations.¶
A CMCD track defines a track which is to be published by the receiver of the catalog. It defines the configuration of the CMCD data to be sent within the payload of that track, as well as the namespace and name under which the track will be published. A CMCD track MUST only be included in a 'publishTracks' array and MUST NOT be present in a 'tracks' array.¶
An MSF track carrying [CMCD] data MUST¶
declare a packaging value of "eventtimeline".¶
declare an eventType value of "urn:cta:cmcd:2026".¶
be referenced in the 'publishTracks' array¶
carry a 'cmcdConfig' Section 4.3 custom track field.¶
A CMCD track is an Event Timeline track (See [MSF] Section 8). The "T" wall-clock time index MUST be used. The 'data' field of each timeline entry is defined as a CMCD_DATA object Section 4.2.1.¶
Each CMCD track record MUST be published as a new Group unless batching is in effect, in which case multiple records MUST be accumulated within each Group. The Group ID SHOULD begin at 0 and then increment by one for the duration of the session.¶
Each CMCD track record MUST be published as soon as possible after the event which triggered it, unless batching is in effect, in which case the batching constraints (see Section 4.3) apply.¶
The CMCD_DATA Object is a sequence of key-value pairs. The key is a string which matches one of the allowed CMCD keys specified in Section 3. The value is always a string and it holds the CMCD-defined value for that key. The value is NOT URLEncoded.¶
The 'ts' key MUST NOT appear in the CMCD_DATA Object. The value of the 'ts' key MUST be used as the "T" value of the record index.¶
Example CMCD track record¶
{
"T": 1756885678361,
"data": {
"sid":"6e2fb550-c457-11e9-bb97-0800200c9a66",
"bl": 4068,
"br": "(5000;v 320;a)",
"bsd": 321,
"e":"t",
"sta": "p",
"v": 2
}
}
¶
This specification defines a new, custom MOQT track field, intended solely for use within a CMCD track. The name of the field is "cmcdConfig" and the value is a JSON [JSON] object. The purpose of this field is to instruct the publisher on which CMCD keys to send in the track, how to send them and where to send them.¶
The JSON Object contains the following fields:¶
"events": an array containing one or more triggering events. Each event MUST be in the set ('abs','abe','ae', 'as','b','bc','c','ce','e','m','pc','pe','pr','ps','sk','t','um'). This array MUST NOT be empty.¶
"interval": optional, the time interval in milliseconds between 't' events. This field MUST only be present if the 't' event is included in the 'events' array. Intervals below 5000 SHOULD NOT be used.¶
"enabledKeys": an array of the allowed CMCD keys to be included in the report. By default, all keys are excluded so each key MUST be explicitly enabled, with the exception of the 'v' key. The 'v' key is mandatory and MUST be included in each record even if it is not specified in the 'enabledKeys' array.¶
"sid": optional, a session ID to use as the value of the 'sid' key. This field MUST only be present if the 'sid' key is included in the 'enabledKeys' array. If not provided and 'sid' is specified in the 'enabledKeys' array, then the publisher MUST synthesize its own session ID using the guidelines specified in [CMCD] Section 4.3.¶
"batchCount": optional, the number of records to accrue before publishing a new Group.¶
"batchInterval": optional, the minimum interval in milliseconds before publishing a new Group.¶
If both batchCount and batchInterval are specified, then the publisher MUST publish a new Group when either constraint is first satisfied.¶
An example cmcdConfig track entry, instructing the publisher, every 30 seconds and at every playstate change, to publish a CMCD record containing session ID (which has been provided), buffer length, bitrate, play state and absolute buffer starvation CMCD data.¶
"cmcdConfig" : {
"events": ["t","ps"],
"interval": 30000,
"enabledKeys": ["sid","bl","br","sta","bsa"],
"sid":"6e2fb550-c457-11e9-bb97-0800200c9a66"
}
¶
This catalog excerpt shows the catalog instructing the publisher to send CMCD data to 3 different targets. Each target receives a different set of CMCD keys:¶
The first target is a player monitoring system, which receives general health information every 30s.¶
The second target is a play state monitoring system. These reports are batched and then sent once a minute.¶
The third target is an error collection system, which receives only player errors.¶
Note the use of the MSF variable substitution scheme to pass down a custom track name. This is a useful mechanism for giving each end-receiver a cacheable catalog while still allowing individualized reports.¶
"publishTracks": [
{
"namespace": "example.com/collection/cmcd/health",
"name": "%player-id%",
"packaging": "eventtimeline",
"eventType": "urn:cta:cmcd:2026",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"cmcdConfig" : {
"events": ["t"],
"interval": 30000,
"enabledKeys": ["sid","bl","br","bs","ltc","msd","mtp"]
}
},
{
"namespace": "example.com/collection/cmcd/playstate",
"name": "%player-id%",
"packaging": "eventtimeline",
"eventType": "urn:cta:cmcd:2026",
"token": "kkjh68n3DVun23csFGk418kHNU5VDrwb...",
"cmcdConfig" : {
"events": ["ps"],
"batchInterval": 60000,
"enabledKeys": ["sid","ps"],
"sid":"6e2fb550-c457-11e9-bb97-0800200c9a66"
}
},
{
"namespace": "example.com/errors",
"name": "%player-id%",
"packaging": "eventtimeline",
"eventType": "urn:cta:cmcd:2026",
"cmcdConfig" : {
"events": ["e"],
"enabledKeys": ["sid","ec"]
}
}
]
¶
The carriage of CMCD signals within the MSF Event Timeline track inherits the security considerations of both the underlying MSF transport and the CMCD standard itself. CMCD data is sent by an untrusted player and may therefore be falsified.¶
The ability of a publishTrack to direct output at a third-party site could be used to DoS both the sender and receiver of the data if the CMCD payload were high and the interval low. Setting a 't' interval to 1, for example, would cause a very high report rate. Client implementers SHOULD protect themselves from high report rates by coercing low values to a higher, sustainable level.¶
This document adds one entry to the "MSF Event Timeline Types" registry.¶
| Event Type | Description | Specification |
|---|---|---|
| urn:cta:cmcd:2026 | CMCD data transmission | This document |
Thanks to the IETF MOQ working group and the CTA WAVE CMCD working group for their review and input.¶