TECHNICAL
much of Europe and North America because competing ISP networks rarely coordinate multicast peering. In smaller markets, that coordination is easier; in larger fragmented markets, it is usually the operating model, not the technology, that gets in the way. Multicast is not on every path, but that argues for fallback, not abandonment. I would advocate multicast by default with routed unicast as graceful fallback: multicast wherever the network supports it and, where a segment does not, extend the same RTP-based service by routed unicast and rapid acquisition. The viewer receives the same live stream whether the path is multicast or routed unicast; the design penalty is extra bandwidth on the unicast segment, not reduced audio or video quality.
Part of the answer is that live IP streaming has often been treated as a transport problem, when it is really an architecture problem. Newer transports such as MoQ are promising and welcome, but the hard question remains: how do we deliver national-scale live services with synchronised viewing, resilient recovery and economics that scale with channels, not viewers? Live IP streaming has had a mature answer for years: multicast, native or routed. A single copy of a channel enters the network and is fanned out within it, so forwarding cost tracks channels, not viewers. Large-scale managed IPTV services already prove the model, yet multicast remains underused across
A connection can fail every test we use to judge it and still carry high-quality live television. We treat throughput and loss figures as verdicts on what a path can deliver; they are not. What a live feed needs is timing and recovery, not a clean bill of health. Broadcast television met that bar for decades. Real-time IP streaming has yet to match it at national and international scale, where serving live per viewer makes the busiest moments the most expensive and the most fragile. The question is architecture, not bandwidth. There is a demonstration image I keep coming back to. On the right (Figure 1a), a conventional internet throughput test rates the connection unsuitable for live streaming: it reports only 0.12 to 0.3Mbps download and 0Mbps upload before eventually failing. On the right, a Nokia-controlled live test feed at approximately 7.5Mbps HD TV continues to play smoothly and in sync. Both run over the same impaired connection, with heavy packet loss and added delay. The same path can still carry high-quality live television when the delivery architecture is built around live-media timing, resilience and recovery. Instead of giving up, stalling or reducing audio and video quality, it keeps the stream on time and repairs what matters before it reaches the viewer. That contrast captures most of the argument in one frame. For years, we have built live “streaming” out of tools meant for something else. HTTP adaptive streaming (HLS, DASH), traditionally over TCP, was originally a clever answer to on- demand video: it buffers, adapts bitrate and rides out rough network patches. But for live content, those strengths become limits. Buffering is latency. Adaptation can read loss as congestion and shed quality even when bandwidth exists. Per-viewer delivery also makes bandwidth, server and energy cost rise with the audience. For major live sports and national or international events, “good” is simple. The audio and video should arrive a second or two behind real life and at full QoE, not a minute late, degraded or rebuffering. Everyone should see the same moment at once, so the action is not spoiled by the neighbour’s television, a cheer through the wall or a text message. It should survive lossy Wi-Fi, a congested cell or a satellite hop without a data centre’s worth of hardware and energy per channel.
Figure 1a. (Top) Over the same impaired connection, a conventional throughput test reports 0.12 to 0.3Mbps download and 0Mbps upload before failing, while the live test feed continues to play smoothly. Figure 1b (Bottom) High-level architecture: the CDN-for-Live edge delivers the live stream by multicast or routed unicast, while a lightweight recovery loop keeps playback aligned and resilient.
Volume 48 No.23 SEPTEMBER 2026
101
Made with FlippingBook - Online magazine maker