Multicast doesn’t cross the IXP — and your app can’t receive it either

It is one of the most attractive-sounding ideas in Indian IPTV distribution, and one of the most misunderstood: ‘we’ll peer at the IXP and multicast our channels to every ISP.’ It does not work that way, and understanding exactly why saves an enormous amount of wasted design.

The one-line reality

Inter-domain multicast — the protocols that were supposed to carry multicast between networks (MSDP, MBGP) — is effectively dead in production. Practically nobody runs it across public exchanges. So while multicast is brilliant inside one operator’s network, the IXP is a hard domain boundary. Everything past it is unicast HTTP.

So how do you actually deliver at scale?

The workable design is three separate domains, each with its own transport:

• Your backbone (multicast). Origin to your own regional edges can be SSM multicast — one copy of each channel on the backbone.
• The hand-off to each ISP (unicast, or private multicast). You deliver the channel set once to each partner ISP, typically as unicast over the IXP, or via a small re-origination node placed inside the ISP’s PoP.
• Inside the ISP (multicast, their job). The ISP runs IGMPv3 + PIM-SSM and IGMP snooping on their access network so a set-top box joins only the channel it wants.

And no — the mobile app can’t receive multicast

This is the second half of the same misunderstanding. An Android or iOS app on home Wi-Fi or mobile data cannot receive your multicast, for the same reason: the moment the stream would need to cross the internet, a mobile core or a home router’s WAN, multicast is dropped. (Carrier multicast for mobile — eMBMS — was never really deployed in India and is dead.) The only Android device that can take multicast is a set-top / Android-TV box sitting inside the operator’s LAN, where multicast is enabled.

Multicast also changes your content protection

Multicast delivery is MPEG-TS over RTP/UDP, not DASH/HLS over HTTP — and that changes DRM. ClearKey/Widevine as used on DASH does not apply to a raw transport stream; multicast needs classic CAS TS-scrambling (ECM/EMM). You also need fast-channel-change and retransmission servers, because UDP has none of the buffering that hides loss on an HTTP player. These are real components, not footnotes.

The honest conclusion: hybrid, always

Every serious Indian IPTV platform ends up hybrid: multicast for on-net set-top boxes (the real bandwidth win), and unicast DASH + DRM for every OTT app (mobile, smart-TV, web) served from a CDN edge. Your edge is never redundant — it always serves the app audience — and multicast only offloads the STB portion, inside networks that support it.

HySky is built around this split: SSM on the backbone where it helps, CAS and DRM across both transports, and an OTT app path that authorises playback at the edge over HMAC tokens rather than hair-pinning to the origin. The player can even join multicast when it detects it is on an operator LAN and fall back to unicast otherwise.

Lessons

• Multicast never crosses the IXP into another network — the exchange is a hard boundary.
• Apps on mobile/Wi-Fi can’t receive multicast; only on-net STBs can.
• Multicast changes transport (TS/RTP) and DRM (CAS scrambling) — plan for both.
• The real architecture is hybrid: multicast STB + unicast OTT. The CDN edge is always needed.