Full Visibility for CMCD Headers

Extending CDN Observability with Gcore

CMCD as a First-Class Observability Layer

Modern adaptive streaming is a distributed feedback system. The player continuously evaluates throughput, buffer levels, and playback state. The CDN delivers segments under dynamic network conditions. Analytics systems attempt to reconstruct what happened, often after the fact.

Without structured client-side telemetry, the CDN operates with limited visibility into why specific delivery decisions were made.

This is where Common Media Client Data (CMCD, CTA-5004) changes the equation. CMCD standardizes how players communicate real-time metrics to the delivery infrastructure. Instead of inferring why a bitrate switch occurred or why rebuffering happened, infrastructure components can observe key signals directly from the client, such as:

• • Encoded bitrate (br)
  • Buffer length (bl)
  • Measured throughput (mtp)
  • Object duration (d)
  • Buffer starvation events (bs)
  • Session identifiers (cid)

CMCD effectively elevates the player into a structured observability source within the delivery chain.

Historically, most web-based players transmitted CMCD via query strings. This integrates naturally with traditional CDN logging models and makes extraction straightforward.

A common concern is potential cache-key fragmentation. This is not an inherent limitation of query-string-based CMCD. Modern CDNs can and should exclude CMCD parameters from cache-key calculation. When configured correctly, query-string transport does not negatively impact caching efficiency.
Native platforms, including Apple, Android, and RDK environments, instead transmit CMCD via dedicated HTTP headers:

• • CMCD-Object
  • CMCD-Request
  • CMCD-Session
  • CMCD-Status

Header-based delivery keeps URLs clean and aligns with HTTP semantics by separating metadata from resource identity.

Operationally, however, this introduced an observability gap: many CDN logging systems were historically optimized around query parameters and did not fully extract structured CMCD header data.

The telemetry was present in the request. It was just not consistently available in logs.

Closing the Observability Gap: The Gcore Implementation

To ensure full transport neutrality, we worked closely with Gcore to define a clear implementation objective:

CMCD delivered via HTTP headers must be indistinguishable from CMCD delivered via query strings at the log level.

Together, we aligned on the technical requirements, and the Gcore engineering team implemented full support for CMCD via HTTP headers within their logging infrastructure. The solution includes:

• • Native support for CMCD delivered via HTTP headers in addition to query strings
  • URL-encoded logging of CMCD values into a dedicated log field
  • Concatenation of all four CMCD header namespaces into a single, comma-separated field
  • Full equivalence between header-based and query-string-based CMCD in log output

The implemented solution operates directly at the CDN edge. When a request arrives, Gcore now:

1. 1. Detects all CMCD-related headers
   2. Extracts their values without semantic transformation
   3. URL-encodes the combined key-value pairs
   4. Concatenates them into a canonical representation
   5. Writes the result into a dedicated cmcd log field

The resulting log entry is functionally equivalent to a query-string-based CMCD payload. No parser changes are required. No ingestion branching logic is needed. Downstream analytics systems receive a unified CMCD representation, independent of how the player transmitted the data.
This implementation preserves core architectural properties:

• • Cache keys remain unaffected because CMCD stays outside the cache-key calculation
  • Analytics pipelines remain unchanged
  • Transport-mode detection becomes unnecessary

Operational Availability

The feature is already available as the Log CMCD headers application within the Gcore CDN platform through the FastEdge service (Gcore documentation). 

To enable it, customers simply add the Log CMCD headers application to their CDN configuration. No player modifications are required. No infrastructure redesign is necessary. Once activated, CMCD values delivered via HTTP headers are automatically captured and written into the dedicated log field.

This makes full header-based CMCD visibility operationally simple and immediately accessible.

CMCD v2: Expanding Telemetry While Preserving Request Mode

CMCD v2 was just officially released and introduces a significantly expanded and refined telemetry model with many beneficial new keys. Read more here CMCD v2 released or access the specs at CTA WAVE: Common Media Client Data (CTA-5004-A)

In addition to the extended metric vocabulary, CMCD v2 formally introduces event mode, enabling players to report telemetry directly to a configured third-party endpoint.

At the same time, request mode remains a critical observability mechanism. Request mode continues to provide:

• • Large-scale batch analytics
  • Historical quality-of-experience correlation
  • Independent validation of player-side reporting
  • Deep dive root cause analysis at logline level

Detailed CDN logs allow engineers to correlate CMCD values with HTTP status codes, retry behavior, cache interactions, and edge-to-origin flows. For complex production incidents, per-request visibility remains indispensable.

For this reason, request mode will continue to play a central role in many environments, even as event mode adoption grows.

By ensuring that header-based CMCD is logged in canonical form, this implementation facilitates full CMCD v2 coverage in request mode. New keys pass through transparently. Existing analytics pipelines remain stable. No structural redesign is required to benefit from the expanded standard.

CMCD transforms video delivery into a measurable control system. Ensuring that infrastructure sees what the player sees is not a feature enhancement. It is a prerequisite for delivering predictable quality at scale.

A sincere thank you to the Gcore engineering team, especially Ilja Karamisevs, for the fast, precise, and high-quality implementation. This kind of collaboration is exactly how standards adoption should work in practice.