Content Steering: The Standard Way to Do Multi-CDN

Why This Matters

For ten years, the multi-CDN industry was a collection of vendor-specific solutions that did not talk to each other — DNS-based steering at Cedexis (now Citrix Intelligent Traffic Management) and NS1, player-side static manifests at every video platform, and various proprietary signalling protocols inside player SDKs. None of those approaches could move a viewer between CDNs mid-session without a player restart, and none of them produced data a CDN-neutral analytics product could use. Content steering is the protocol-level fix to that decade of fragmentation. As of 2026, every major open-source player (hls.js, dash.js, Shaka Player, Video.js v10 with the Streaming Processor Framework, ExoPlayer on Android Media3) ships content steering support, every major CDN (Akamai, Cloudflare, Fastly, AWS CloudFront, Google Media CDN, Edgio) supports the pathway model, and several specialized steering-server vendors (THEO, MediaMelon, einbliq.io, Touchstream, Broadpeak) have product offerings designed for the spec. A product manager finishes this article able to ask "are we using HLS Pathway IDs or DASH ServiceLocations, and what is the TTL on the steering manifest?" without bluffing. An architect finishes it with a four-component blueprint, a clear understanding of how PATHWAY-CLONES lets the steering server announce a brand-new CDN to a player that has been running for an hour, and an unambiguous map of which spec field maps to which behaviour. An operations lead finishes it with the failure-mode catalogue, the telemetry plan, and the readiness checklist that ships with this article. Content steering is not a new optimisation; it is the lingua franca that multi-CDN was missing.

The One-Paragraph Definition (No Spec Numbers, Yet)

Imagine your video player is a customer in a café. The café is the manifest — the small text document that lists where each video chunk lives. Until 2021, the manifest told the customer exactly one address for each chunk and one chain of fallbacks. Content steering adds a second document: a short list, posted on a noticeboard the café updates every five minutes, of which suppliers (CDNs) are currently delivering the best coffee. The customer checks the noticeboard, picks the supplier at the top of the list, and orders the next chunk from there. If the suppliers' order changes between checks, the customer's next order goes to a different supplier — without a new menu, a new visit, or a new conversation with the café. The noticeboard is the steering manifest. The act of checking it on a timer is steering. Everything else — the JSON keys, the PATHWAY-ID attribute, the CMCD query parameters — is just plumbing.

Figure 1. The content steering architecture in one picture. One origin, multiple CDNs, one steering server. The steering server's job is to publish a small JSON document whose contents the player obeys on the next segment request.

Why Content Steering Replaces What Came Before

The mental model is easiest to build by contrast.

Before content steering, the multi-CDN industry shipped three architectures that all had the same shape and different failure modes. DNS-based steering — the oldest — answered the player's lookup of the manifest hostname with a different IP depending on which CDN the steering policy preferred. The control point was the recursive Domain Name System resolver, and the reaction time was bounded by the resolver's Time-To-Live cache, which was often longer than the resolver's nominal TTL because Internet Service Providers impose minimums. Player-side static failover shipped a list of CDN base URLs inside the player's configuration; the player walked the list when a request failed. Every player implemented this slightly differently, and the architecture could not see global health, only local errors. Proprietary signalling — bespoke approaches at Netflix, Twitch, YouTube — ran on each platform's own controller protocol; portable nothing.

The chronic problem all three architectures shared was the mid-session boundary. Once a viewer was playing a stream, moving them to a different CDN required either a player restart (DNS — wait for the resolver TTL or break the session) or a player error (static failover — wait for a request to fail). Neither architecture could push a global priority change to a player whose session was already running.

Content steering moves the control point into the application layer and decouples it from request failures. The steering manifest is a tiny JSON file the player polls on a schedule the steering server controls. When the priority list changes, the next refresh — typically within 60 to 300 seconds — picks up the new order. The player does not need to restart, does not need to fail a segment, and does not need to wait for a DNS TTL to expire.

The shorthand: DNS steering reacts in minutes (resolver TTLs), static failover reacts in seconds-per-failure (player errors), content steering reacts in steering-server seconds (the TTL on the JSON, which the steering server can set as low as 30 seconds and which dash.js and Shaka Player honour faithfully).

Architecture	Control point	Reaction time	Mid-session updates	Standardised
DNS-based steering	Recursive DNS resolver	Resolver TTL (minutes)	Only for new sessions	No (vendor-specific)
Player-side static failover	Player SDK	Per failure (seconds)	Limited (manifest reload)	No (per-player)
HLS/DASH Content Steering	Steering server	Steering TTL (seconds)	Yes, every refresh	Yes (Apple v1.2 + ETSI TS 103 998)

The HLS Side — Apple's Specification Walked Tag by Tag

Apple introduced HLS Content Steering in the September 2021 revision of the HLS Authoring Specification, with the WWDC21 session "Improve global streaming availability with HLS Content Steering" as the practitioner-facing rollout. The spec was revised at WWDC22 (session 10144) to add Pathway Cloning and PATHWAY-PRIORITY semantics, and the current version is HLS Content Steering Specification v1.2 (preliminary v1.2b1 in publication), aligned with draft-pantos-hls-rfc8216bis-22 dated 1 May 2026. Three pieces of vocabulary do most of the work.

EXT-X-CONTENT-STEERING — the tag on the multivariant playlist

The multivariant playlist — the top-level manifest that lists all the variants the player can choose between — gains one new tag. EXT-X-CONTENT-STEERING is optional, appears zero or once per multivariant playlist, and carries two attributes that matter: SERVER-URI (the URL of the steering manifest, the JSON document) and PATHWAY-ID (the identifier of the pathway the player should use at startup before the first steering manifest arrives).

A worked example. Suppose a publisher is delivering through two CDNs, identified as cdn-a and cdn-b. The multivariant playlist contains:

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-CONTENT-STEERING:SERVER-URI="https://steering.example.com/manifest?session=xyz",PATHWAY-ID="cdn-a"

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,PATHWAY-ID="cdn-a"
https://cdn-a.example.com/master/1080p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,PATHWAY-ID="cdn-b"
https://cdn-b.example.com/master/1080p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,PATHWAY-ID="cdn-a"
https://cdn-a.example.com/master/720p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,PATHWAY-ID="cdn-b"
https://cdn-b.example.com/master/720p.m3u8

Notice three things. First, the same variant — 1080p at 5 Mbps — appears twice, once per pathway, with two different URLs. Each line is a complete variant; the PATHWAY-ID is what groups them. Second, the player at startup uses the initial PATHWAY-ID from the EXT-X-CONTENT-STEERING tag — here cdn-a — until the first steering manifest arrives. Third, the SERVER-URI may include a session token or asset identifier; the steering server uses these to scope its decisions to the specific viewer.

The steering manifest — the JSON document

The steering server responds to the player's GET with a small JSON object. The fields the spec defines:

{
  "VERSION": 1,
  "TTL": 300,
  "RELOAD-URI": "https://steering.example.com/manifest?session=xyz",
  "PATHWAY-PRIORITY": ["cdn-b", "cdn-a"],
  "PATHWAY-CLONES": []
}

VERSION is 1 in the current spec; players that read a higher version must abort steering and fall back to the default pathway. TTL tells the player how long, in seconds, to wait before the next refresh — 300 seconds (5 minutes) is the Apple default; for live events 60 seconds is common, and 30 seconds is the practical floor before the request rate against the steering server itself becomes a load problem. RELOAD-URI lets the steering server move the player's polling URL — handy for stickiness, for sharding the steering load, or for retiring a steering endpoint without breaking sessions. PATHWAY-PRIORITY is the ordered list of pathway IDs the player should try, highest priority first.

The semantics: when the player gets a fresh steering manifest, it inspects PATHWAY-PRIORITY[0] — the first entry — and switches to that pathway for the next segment. If the variant on that pathway corresponding to the player's current rendition is reachable, the player uses it; if not, the player walks down PATHWAY-PRIORITY until it finds a reachable one. The current variant's resolution and bandwidth tier do not change just because the pathway did — the player swaps the CDN, not the rendition.

PATHWAY-CLONES — the trick that lets the steering server announce a brand-new CDN mid-session

This is the feature that earned content steering its place over DNS-based steering. Suppose a publisher started the session with two CDNs, cdn-a and cdn-b, and partway through the session decides to add a third — cdn-c. With DNS-based steering, this is a manifest-edit problem; the new CDN's URLs simply do not exist on the player's running multivariant playlist. With content steering, the steering server can put cdn-c into the next steering manifest using PATHWAY-CLONES:

{
  "VERSION": 1,
  "TTL": 300,
  "PATHWAY-PRIORITY": ["cdn-c", "cdn-b", "cdn-a"],
  "PATHWAY-CLONES": [
    {
      "BASE-ID": "cdn-a",
      "ID": "cdn-c",
      "URI-REPLACEMENT": {
        "HOST": "cdn-c.example.com",
        "PARAMS": {"region": "eu-west"}
      }
    }
  ]
}

The player reads the PATHWAY-CLONES array, sees that cdn-c is a clone of cdn-a (the BASE-ID) with the host replaced and an extra query parameter added, and constructs the URLs for cdn-c's variants by applying the URI replacement to every variant URL on cdn-a. From the player's point of view, cdn-c becomes a fully-fledged pathway it can switch to — without ever fetching a new multivariant playlist.

The mechanism rewards careful URL design on the origin: if every CDN's variant URLs follow the same path-and-filename structure differing only by hostname and a few query parameters, pathway cloning is a one-line operation on the steering server and the entire fleet of players migrates within one steering-manifest TTL. If the URL design is inconsistent — different path structures per CDN, different filenames per CDN — pathway cloning is impossible, and the publisher is stuck recompiling the multivariant playlist for every CDN addition.

![Sequence diagram with three swim lanes: player, steering server, CDN-A, CDN-B. The player fetches the multivariant playlist (containing both pathways), then fetches the steering manifest, gets back a JSON with PATHWAY-PRIORITY=[cdn-a, cdn-b], and begins requesting segments from cdn-a. Five minutes later, the player re-fetches the steering manifest; the response has flipped the priority to PATHWAY-PRIORITY=[cdn-b, cdn-a]; the next segment goes to cdn-b without a player restart.](./images/06_5-content-steering-multi-cdn__02-handshake-sequence.svg)
Figure 2. The full content-steering handshake. One initial bootstrap, then a steady cadence of small JSON polls whose contents the player obeys on the very next segment request.

The DASH Side — ETSI TS 103 998 in Plain Language

The DASH-IF version of content steering started as a Community Review document in late 2022, was developed in close alignment with Apple's HLS work, and was published as the formal European Telecommunications Standards Institute specification ETSI TS 103 998 V1.1.1 in January 2024. The design goal was explicit: the same steering server should be able to drive both an HLS player and a DASH player without code changes on the server side. The two specs are not identical — the words differ because the two manifest formats differ — but the JSON-level vocabulary is intentionally compatible.

Where the steering tag lives in the MPD

DASH's manifest, the Media Presentation Description (MPD), is XML. The content-steering tag is the ContentSteering element, a child of the MPD root:

<MPD ...>
  <ContentSteering
      defaultServiceLocation="cdn-a"
      queryBeforeStart="true">
    https://steering.example.com/manifest?session=xyz
  </ContentSteering>
  <Period>
    <AdaptationSet>
      <BaseURL serviceLocation="cdn-a">https://cdn-a.example.com/</BaseURL>
      <BaseURL serviceLocation="cdn-b">https://cdn-b.example.com/</BaseURL>
      <Representation .../>
    </AdaptationSet>
  </Period>
</MPD>

Three pieces of vocabulary do the work. ContentSteering itself contains the steering server URL as its text content. defaultServiceLocation plays the role of HLS's startup PATHWAY-ID — the CDN the player uses before the first steering manifest is fetched. queryBeforeStart (boolean) tells the player whether to block playback startup on the steering server's first response (true) or to start optimistically with the default and apply steering on the next refresh (false). The two-BaseURL pattern with different serviceLocation values is how DASH expresses what HLS expresses with two EXT-X-STREAM-INF entries with different PATHWAY-ID attributes.

The DASH steering manifest

The JSON the DASH steering server returns is intentionally close to HLS's:

{
  "VERSION": 1,
  "TTL": 300,
  "RELOAD-URI": "https://steering.example.com/manifest?session=xyz",
  "SERVICE-LOCATION-PRIORITY": ["cdn-b", "cdn-a"],
  "PATHWAY-PRIORITY": ["cdn-b", "cdn-a"]
}

SERVICE-LOCATION-PRIORITY is the DASH-native key — it matches the serviceLocation attribute on the MPD's BaseURL elements. PATHWAY-PRIORITY is the HLS-aligned alias, included for cross-spec interoperability: a server can publish either, both, or only SERVICE-LOCATION-PRIORITY and DASH-spec clients will obey. The VERSION, TTL, and RELOAD-URI keys carry identical semantics to HLS.

The practical implication for steering-server vendors: one HTTP endpoint, one JSON payload, both client families served. The cost of supporting DASH in addition to HLS is essentially zero on the server side. The cost on the player side is real but bounded — dash.js, Shaka Player, and Video.js v10's DASH engine all implement content steering through their MPD parser; hls.js, Shaka Player's HLS engine, and the native iOS / tvOS player implement it through their HLS multivariant-playlist parser.

Concept	HLS spec field	DASH spec field
Steering tag on the manifest	EXT-X-CONTENT-STEERING
Steering server URL	SERVER-URI attribute	Element text content
Initial CDN to use	PATHWAY-ID attribute	defaultServiceLocation
CDN identifier on a variant	PATHWAY-ID on EXT-X-STREAM-INF	serviceLocation on BaseURL
Priority list in the JSON	PATHWAY-PRIORITY	SERVICE-LOCATION-PRIORITY (HLS alias also accepted)
Mid-session new CDN	PATHWAY-CLONES	Not directly specified; achieved via MPD update

How the Steering Server Actually Decides

Up to this point the steering server has been a black box that produces a JSON list in some order. The interesting question is: how does it decide the order? The honest answer is "it depends on the vendor and on what telemetry the players are giving back". Three broad approaches are visible in the 2024–2026 deployment data.

Approach 1 — Health-and-weight. The simplest steering server. The operator configures a static priority order and a set of health checks against each CDN; if a CDN's health check fails, it drops to the bottom of the list. Weighted variants allow simple per-region splits — 70 percent of US viewers to CDN-A, 30 percent to CDN-B, computed by a deterministic hash of the session token. Most DIY steering servers ship this approach because it works without any player-side telemetry. The limitation is that the steering server cannot see what individual viewers are actually experiencing.

Approach 2 — CMCD-driven. The Consumer Technology Association's Common Media Client Data specification — CTA-5004, published in 2020 — defines a small set of keys (buffer length, throughput, content ID, session ID, dropped frames, requested bitrate) that the player attaches to every media object request either as a custom HTTP header or as a query parameter. A steering server that sits in front of the CDN can read those keys on the steering-manifest request itself — Apple's HLS spec defines query parameters _HLS_pathway (the player's current pathway) and _HLS_throughput (the player's measured throughput on that pathway) that the steering server can read directly — and aggregate them across thousands of concurrent viewers. The resulting decisions are data-driven: shift viewers off a CDN that is degrading in a specific region before the rebuffer events occur on the broader fleet. The Mile-High Video 2024 paper on dash.js's reference implementation, and the einbliq.io quality-aware-multi-CDN pilot, both demonstrate measurable QoE improvements (low-single-digit-percentage rebuffer reductions on average, larger gains on the bottom decile of viewers) over health-and-weight steering on the same workload.

Approach 3 — Learning-based. Recent academic work (CADENCE at the ACM Multimedia Systems Conference 2026; StreamWise at MMSys 2025; IMAC at MHV 2025) demonstrates multi-agent and reinforcement-learning steering decisions that beat both health-and-weight and CMCD-aggregation approaches in controlled experiments. None of these are widely deployed in 2026; the operational risk and the training-data requirement are still high enough that production teams stick with CMCD-driven heuristics. Expect the first commercial learning-based steering products in 2026–2027 from the same vendors that ship neural ABR — Bitmovin, Mux, Visionular.

The decision approach has nothing to do with the spec — the spec is silent on how the JSON gets produced. The spec dictates only the format of the JSON. The intelligence is the operator's problem, and the differentiator between steering-server vendors.

A Worked Example — The Math of a CMCD-Driven Switch

Suppose the publisher is running a major live event with 800,000 concurrent viewers, split across two CDNs by a 50/50 hash. The steering manifest TTL is 60 seconds. At T=0 minutes, both CDNs are healthy. At T=8 minutes, CDN-A's edge in Frankfurt begins to throttle a peering link, causing the average throughput on the player-reported _HLS_throughput parameter to drop from 18 Mbps to 6 Mbps for the 60,000 viewers routed there.

The steering server's CMCD aggregator detects the throughput drop within one minute — the average across the Frankfurt cohort crosses an alert threshold by T=9 minutes. The steering server flips the priority list for those 60,000 viewers: PATHWAY-PRIORITY changes from ["cdn-a", "cdn-b"] to ["cdn-b", "cdn-a"]. On the next steering-manifest refresh (between T=9 and T=10 minutes), each affected player picks up the new priority and switches CDN-B for the next segment.

The arithmetic of the saved rebuffer events:

• Pre-switch: 60,000 viewers × ~9.5 average video bitrate / 6 Mbps throughput = sustained download starvation; rebuffers expected within 30 seconds of buffer depletion on a 30-second player buffer.
• Switch detection latency: 60 seconds (CMCD aggregation window).
• Steering propagation: up to 60 seconds (steering manifest TTL).
• Total response latency: ≤ 120 seconds.
• Player buffer: 30 seconds for live (LL-HLS) or 30 seconds for standard HLS at typical configurations.

The race is uncomfortable. In a static-CDN deployment, all 60,000 viewers would have rebuffered. In a DNS-steered deployment with a 60-second TTL on the recursive resolver (best case), the new sessions would have moved to CDN-B but the existing sessions, holding cached DNS answers, would still have rebuffered. In the content-steering deployment, the steering server can push the priority change to every existing session within the steering-manifest TTL — and the 120-second total response latency just beats the 60-second player buffer for viewers who were not yet drawing down before the switch propagated.

The example is intentionally tight; in real deployments the steering-manifest TTL is set with knowledge of the player buffer length, the CMCD aggregation window, and the typical CDN failure mode. A 30-second TTL gives more headroom; the load on the steering server is twice as high. Tradeoffs accumulate.

Figure 3. A CMCD-driven steering switch in action. The cohort's experienced throughput recovers on the first steering-manifest refresh after the CMCD aggregator crosses the alert threshold.

Player and CDN Coverage — Who Actually Ships This in 2026

Spec coverage and shipping coverage are different questions. Here is the 2026 landscape, drawn from release notes, vendor docs, and the SVTA's Architectures-for-Multi-CDN-Switching working-group output.

Players that ship content steering for HLS, DASH, or both. The native Apple AVPlayer has supported HLS Content Steering since iOS 15 / tvOS 15 / macOS Monterey (2021) and was the first shipping implementation. The DASH-IF reference player dash.js added content steering through pull request #4031 in 2023 and reached full v1 support by dash.js 4.5. Shaka Player (Google) supports content steering v1 for both DASH and HLS — the first cross-protocol implementation. hls.js added content steering 1.3+ in April 2023, with continuing fixes through 1.5.x and 1.6.x (1.6.15 fixed URI-REPLACEMENT host handling; 1.6.x also fixed PARAMS ordering for pathway clones). Video.js v10 with the Streaming Processor Framework ships content steering through its videojs/http-streaming engine; the documentation page in the videojs/http-streaming repository details the implementation status. Android Media3 / ExoPlayer ships content steering as of the Media3 1.4 release line. smart-TV native players — Tizen, webOS, Vidaa — ship content-steering-capable engines on late-model firmware; older firmware in the install base does not always update, and the practical coverage on smart TVs is closer to 60–80 percent of the install base in 2026.

CDNs that support the pathway model. All major commercial CDNs — Akamai, Cloudflare, Fastly, AWS CloudFront, Google Media CDN, Edgio (formerly Limelight + EdgeCast) — work with content steering, because content steering does not require any CDN-side changes. The CDN serves the segments at the URLs the player requests; the pathway logic lives entirely between the player and the steering server. Some CDNs (Akamai, Cloudflare) offer turnkey steering-server products as part of their multi-CDN suites; others (Fastly, AWS) leave the steering server to the customer or a third-party.

Steering-server vendors. The 2026 market includes Cedexis / Citrix Intelligent Traffic Management, NS1 (now part of IBM), CDNetworks, MediaMelon (CDN-X), Touchstream Brewer, einbliq.io, THEO Technologies (HLS/DASH content steering as part of THEOplayer), and Broadpeak. Several customers run their own steering servers — the spec is small enough that a competent backend team can ship a working implementation in a couple of weeks, with the heavy lifting on the telemetry-aggregation side, not the JSON-format side.

Figure 4. The 2026 player–feature coverage matrix. Use this to scope your minimum-viable steering deployment.

Common Pitfalls

Multi-CDN deployments fail in repeatable ways, and content-steering deployments inherit most of those failure modes plus a small number unique to the spec.

Pitfall 1 — The steering server becomes a single point of failure. The whole architecture depends on the steering server being reachable. If the steering endpoint goes down — DNS failure, certificate expiry, deployment rollout, you-name-it — the players cannot refresh and either freeze on whatever pathway they last picked or fall back to the multivariant playlist's pathway order. Specs handle this gracefully (the player keeps playing on the current pathway), but the multi-CDN benefit evaporates the moment the steering server is unreachable. The mitigation is to run the steering endpoint on at least two regions with health checks, and to host it on a CDN-resilient infrastructure that is itself not dependent on any single CDN you are trying to steer between.

Pitfall 2 — TTL set too long for the failure profile. A 300-second TTL is fine for performance-driven rebalancing on a steady-state workload; it is too long for a CDN-level outage during a marquee live event. The right TTL is a function of the player buffer (≤ 30 seconds for live), the CMCD aggregation window (~60 seconds in most implementations), and the cost of running the steering server at a higher request rate. The recurring lesson from post-mortems: pick the TTL based on the worst case you need to survive, not the average case you want to optimise.

Pitfall 3 — Inconsistent URL design across CDNs blocks PATHWAY-CLONES. If CDN-A's variants live at https://cdn-a.example.com/streams/{contentid}/1080p_8.m3u8 and CDN-B's variants live at https://cdn-b.example.com/v1/{contentid}/master/1080p.m3u8, the steering server cannot announce a new CDN as a clone — the URLs are structurally different. The fix is to standardise URL structure across CDNs at origin-packaging time. The cost of doing this late is a manifest rebuild and a player session reset.

Pitfall 4 — CMCD identifiers leaking into cache keys. CMCD's query-parameter mode adds CMCD=... to every segment URL. If the CDN's cache key includes the full URL including query string (the default for most CDNs), the cache fragments per-session — every viewer is fetching a unique URL, and the cache hit ratio collapses. The fix is well-known and well-documented (configure the CDN to strip the CMCD query string before computing the cache key, or use CMCD's HTTP-header mode instead of query mode), but it is the single most common mistake teams make when first wiring up CMCD upstream.

Pitfall 5 — Smart-TV install base does not match the spec. Late-model Tizen, webOS, and Vidaa devices ship content-steering-capable native players. The install base of older devices does not. A multi-CDN strategy that assumes 100 percent of the audience can be steered will under-deliver on the older-firmware segments. Mitigation: monitor by user-agent string what proportion of the live audience is steering-capable, and keep DNS-based failover or static failover in place for the remainder.

Pitfall 6 — Treating the steering server as a marketing surface. The steering server's decisions are critical to delivery; they are not the right place for a content recommendation algorithm. Keep the steering server's decision logic narrow (performance, cost, resilience). Anything else belongs in the manifest, in the player, or in a separate service.

Where Fora Soft Fits In

In OTT and live-streaming products we have shipped — including video-conferencing platforms with WebRTC fallback to HLS, e-learning systems that serve recorded lectures plus live classes, telemedicine products that need session resilience across regions — multi-CDN became necessary not because of cost, but because of resilience. The HLS / DASH Content Steering standards changed how we ship it. Where we used to ship per-platform failover SDKs and DNS-steered configurations that worked differently across iOS, Android, web, and smart-TV apps, we now ship one steering manifest endpoint, one cross-platform JSON contract, and one telemetry pipe through CMCD. The operational discipline that matters is on the steering server itself — its uptime, its TTL, its observability, its decision logic. The article that follows this one in the Learn track, on token authentication and signed URLs, explains how to keep the per-CDN authentication tier from breaking the steering layer.

A One-Page Readiness Checklist

The checklist on the next page is the same one we use when scoping a content-steering deployment for a client. The PDF download contains a print-ready version.

The summary form:

1. Origin URL design — segment URLs structurally identical across all candidate CDNs (path, filename, query parameters); only host differs. PATHWAY-CLONES depends on this.
2. Manifest dual pathways — every variant published twice, once per CDN, with PATHWAY-ID (HLS) or serviceLocation (DASH) identifying the CDN.
3. Steering server endpoint — hosted on resilient infrastructure not dependent on the CDNs you are steering between; health-checked from at least two regions.
4. Steering manifest TTL — set as a function of your player buffer and CMCD aggregation window; 60–300 seconds is the working range.
5. CMCD upstream — players configured to attach CMCD via header (preferred) or query string (with cache-key exclusion configured on every CDN).
6. Player coverage check — minimum supported player versions documented: hls.js ≥ 1.4, dash.js ≥ 4.5, Shaka Player ≥ 4.5, Video.js v10 with VHS, AVPlayer iOS 15+, Android Media3 1.4+.
7. Smart-TV fallback — DNS or static failover retained for older smart-TV firmware that does not ship steering-capable engines.
8. Steering-server observability — request rate, JSON content history, per-pathway viewer counts, CMCD aggregation metrics dashboards.
9. Failure-mode runbook — what happens when the steering endpoint is unreachable; what happens when one CDN goes red; what happens when all CDNs go yellow at once.
10. A/B test plan — rolling out steering to a percentage of the audience first, measuring rebuffer ratio, startup time, and origin egress against the non-steering control before flipping 100 percent.

Download the Content Steering Readiness Checklist (PDF)

What to Read Next

• Multi-CDN: the architecture, the cost story, the failure modes — the architecture this article implements.
• Token authentication and signed URLs — how to keep auth from breaking the steering layer.
• QoE metrics: what every dashboard should show — the metrics that prove your steering deployment is working.

Talk to Us / See Our Work / Download

• Talk to a streaming engineer about scoping content steering for your live or VOD platform.
• See our case studies in OTT, telemedicine, e-learning, and video conferencing where multi-CDN resilience mattered.
• Download the Content Steering Readiness Checklist (PDF) — the same one-page checklist we use when scoping a deployment.

References

1. Apple, HLS Content Steering Specification v1.2 (preliminary v1.2b1). Apple Developer, accessed 2026-05-24. The HLS-side controlling specification for content steering — EXT-X-CONTENT-STEERING tag, PATHWAY-ID, PATHWAY-PRIORITY, PATHWAY-CLONES, RELOAD-URI, TTL, VERSION; query parameters CURRENT-PATHWAY-ID and THROUGHPUT.
2. IETF, draft-pantos-hls-rfc8216bis-22 — HTTP Live Streaming 2nd Edition, R. Pantos (ed.), 1 May 2026. Normative HLS protocol text including the EXT-X-CONTENT-STEERING tag and the PATHWAY-ID attribute on EXT-X-STREAM-INF and EXT-X-MEDIA. Internet-Draft, subject to change before RFC publication.
3. ETSI TS 103 998 V1.1.1 — Content Steering for DASH (Publicly Available Specification, formerly DASH-IF Content Steering), January 2024. The DASH-side controlling specification: ContentSteering element on the MPD, BaseURL/@serviceLocation, JSON steering manifest with VERSION, TTL, RELOAD-URI, SERVICE-LOCATION-PRIORITY; compatibility with HLS RFC 8216bis.
4. DASH-IF, Content Steering Community Review, late 2022. The pre-standardization community review that became ETSI TS 103 998. Implementation guidelines, alignment rationale with HLS.
5. CTA-5004 — Common Media Client Data (CMCD), Consumer Technology Association / CTA WAVE, 2020. Player-to-CDN/server telemetry as query parameters or custom HTTP headers; the upstream metric source for quality-aware content steering.
6. Apple, WWDC21 session 10141 — Improve global streaming availability with HLS Content Steering, June 2021. Original practitioner-facing introduction of HLS Content Steering.
7. Apple, WWDC22 session 10144 — Deliver reliable streams with HLS Content Steering, June 2022. PATHWAY-CLONES, PATHWAY-PRIORITY, URI-REPLACEMENT semantics.
8. D. Silhavy et al., Content Steering: A Standard for Multi-CDN Streaming, Proceedings of the 3rd Mile-High Video Conference (MHV 2024), ACM. Peer-reviewed treatment of the spec and the dash.js reference implementation.
9. Fraunhofer FOKUS, Dynamic CDN Switching — DASH-IF Content Steering in dash.js, MHV 2023 / 2nd Mile-High Video Conference, ACM. Reference-player implementation details, sequence diagrams, edge cases.
10. The Broadcast Bridge, Content Steering Goes Mainstream After Standardization, 2024. Industry-side recap of vendor adoption (THEO, MediaMelon, Akamai, EZDRM, einbliq.io).
11. Multi-Regional, Multi-CDN Delivery Optimizations using HLS/DASH Content Steering Standard, Proceedings of the 4th Mile-High Video Conference (MHV 2025), ACM. Quantitative results across three major CDNs.
12. videojs/http-streaming — Content Steering implementation docs, Brightcove / Video.js project, accessed 2026-05-24. Reference implementation in the HLS/DASH engine inside Video.js v10.
13. Shaka Player release notes — Content Steering v1 support, Google / Shaka Player project, accessed 2026-05-24. Cross-protocol implementation status.
14. einbliq.io, Pilot: Quality-aware multi-CDN based on CMCD and Content Steering, 2024. Production pilot pairing CMCD upstream with a content steering server; measured QoE deltas on the bottom decile of viewers.
15. SVTA — Architectures for Multi-CDN Switching, Streaming Video Technology Alliance working group document, accessed 2026-05-24. Reference architecture covering steering-layer placement, telemetry, and failover semantics.