What is an eCDN?

An enterprise content delivery network distributes content within an organization’s private network. It may use caches, multicast, peer delivery, or strategically placed edge nodes to limit repeated upstream traffic.

How eCDNs work

HTTP video streaming is unicast: as Microsoft describes for Teams events, every viewer gets an individual stream from the internet. When a large share of one office watches the same town hall, those identical streams compete for the same internet gateway or WAN link. An eCDN lets most viewers at a site obtain the video from inside the network instead, by one of three methods. Peer-to-peer eCDNs have viewers’ browsers or apps exchange video segments with each other over WebRTC data channels on the LAN, coordinated by a cloud service. Caching eCDNs place a video cache at a site, which serves nearby viewers. Multicast eCDNs send a single stream onto a multicast-enabled network that every receiver joins. In each case the video still originates upstream, typically at the streaming platform’s internet CDN. Peer-to-peer eCDNs also use that CDN as the fallback: in Microsoft’s design, for example, each viewer still downloads some segments over HTTP, and manifests and DRM licenses always come from the HTTP server so that the platform’s own authorization keeps applying. Unlike a public CDN, whose edge locations follow worldwide audience geography, an eCDN’s topology follows the organization’s sites, subnets, and VPNs.

Key facts

Peer-to-peer, cache, or multicast: what does each ask of the network? Peer-to-peer needs no servers on site, but peers must reach each other directly over UDP inside the LAN and reach the vendor’s coordination service over HTTPS and WebSocket; Microsoft expects TLS inspection to interfere with that WebSocket connection and recommends exempting its domains. A caching eCDN needs a cache server deployed where the viewers are. Ramp’s OmniCache, as Brightcove documents it, is an on-premises software appliance: a plug-in in the web player rewrites the stream URL so that desktops and mobile devices pull from the cache, which fetches from the platform’s CDN whatever it does not already hold. Multicast needs routers that run a multicast routing protocol and hosts that signal group membership, and in Ramp’s implementation an on-premises server plus a receiver client on each viewing computer; in exchange, Ramp describes it as using one viewer’s worth of bandwidth however large the audience. Vendors combine the methods: Ramp’s player can fall back to a local cache where the receiver or the multicast stream is unavailable.
Does browser-based peering work without client changes? Often not. Browsers hide local IP addresses from WebRTC behind mDNS names, so Microsoft’s setup guide calls the WebRtcLocalIpsAllowedUrls policy in Chrome and Edge, which exposes local IPs to its service, a required component for its browser client to take part in peering (the Teams desktop app is unaffected), and Kollective’s requirements as published by Vimeo say peering efficiency is limited without an equivalent policy. The same guide says a second policy, LocalNetworkAccessAllowedForUrls, which lets the listed sites reach local network endpoints, must also be configured; without it, Microsoft says, browser clients may be prevented from establishing peer connections. Microsoft’s instructions set both through the Windows registry and describe customers rolling out the first at scale with Group Policy or an endpoint management system such as Intune. Devices that cannot peer are not blocked. They fall back to ordinary server delivery, which is the load the eCDN was meant to remove.
How is peering kept inside a site and off the VPN? Through the coordination service and subnet configuration. Microsoft’s service maps which peers are adjacent on the network, does not connect peers it detects to be on different sites, and can enforce peering by local IP from a customer-supplied subnet mapping; the same mapping can stop Wi-Fi clients from uploading to peers, to avoid congesting their upload link. For VPN users, Microsoft recommends split tunneling and switching peering off for VPN subnets, and Vimeo gives matching advice for Kollective and Hive Streaming so that peers do not exchange video through the VPN concentrator. Subnet rules act on the address the service sees: Microsoft warns that the local-IP browser policy exposes only a device’s most preferred network adapter, so a browser viewer with several adapters, for example on an always-on VPN, can be assigned to the wrong subnet group. Include VPN-connected browsers in the pre-event test and check which group they land in. With peering off, each VPN viewer still pulls an individual stream, and on a forced (full) tunnel that stream is routed through the VPN infrastructure unless it is given a direct route; Microsoft publishes such an exception for Teams event attendee traffic. On access control, Microsoft states that only viewers authenticated by the video platform join the peer network and that peer connections are encrypted with DTLS.
How do you know the eCDN is actually offloading traffic? Not from playback succeeding, because fallback to HTTP delivery is automatic. The measure is the share of bytes delivered inside the network. Microsoft’s dashboard reports peer-to-peer efficiency as peer bytes divided by total bytes, alongside rebuffering, and its worked example has a 2 Mbps stream to 1,000 viewers needing 2 Gbps without offload and 200 Mbps at 90% efficiency. Test before the event at realistic concurrency: Microsoft provides a silent test that simulates a live event and notes that the achievable offload is capped at 50% with two viewers and 67% with three, so a handful of test machines understates the result.

What is an eCDN?

How eCDNs work

Key facts

When eCDNs matter

Sources

Turn media knowledge into a working pipeline