You commission a new IPMX control room. Cameras, encoders, and displays are spec’d. The 10 GbE fabric is racked, the patch is clean, and everything passes acceptance. Two weeks later the calls start. Streams drop silently for no reason anyone can find. Restarting the receiver fixes it for a few hours. Nobody can reproduce the problem on the bench.

The cause, almost every time, is something that should have been configured at install: a network that nobody designed for multicast.

For integrators coming from SDI, this is the largest mental adjustment in moving to ST 2110, IPMX, and the rest of the media-over-IP world. SDI delivers what you wired. IP delivers what you configured and uncompressed video at multicast scale punishes networks that haven’t been configured for it.

What follows is a field guide to the parts of multicast that actually affect your installs, and the decisions you need to make before the first camera comes up.

Why multicast at all

In a small AV-over-IP system, you can sometimes get away with unicast. Each receiver opens its own connection to each source, the way a web browser fetches a page. NDI, SDVoE, and Dante AV all support unicast for simple deployments. It works because most systems are small and most streams are bandwidth-modest.

ST 2110 and IPMX break that model fast. Picture one 4K camera feeding four displays. With unicast, that’s four identical 12 Gb/s streams leaving the camera (using 12G-SDI’s line rate as a reference for 4K UHD60 4:2:2 10-bit). 48 Gb/s in total, all flowing out of one camera port. Add a second camera and you’re at 96 Gb/s. The math collapses immediately.

Multicast solves this by replicating traffic inside the network instead of at the source. The camera sends one stream to a special group address. The switches in the path make copies only where they’re needed. Each link carries one instance of the flow, regardless of how many receivers are watching.

That is the whole reason ST 2110 and IPMX assume multicast. Without it, you cannot scale.

The first piece: groups and snooping

Every multicast flow starts with a sender (a camera, an encoder, a server) transmitting to a destination address in the administratively scoped 239.0.0.0/8 range. The sender does not check whether anyone is listening. It simply sends.

Receivers join a group by sending an IGMP membership report, a small message that effectively says “I want to receive 239.1.1.1.” A switch with IGMP snooping enabled listens for these messages and adds the requesting port to its forwarding table. Packets for that group are then sent only to the ports that asked for them.

That last sentence is the important one. Without IGMP snooping, the switch treats multicast like broadcast and sends every stream to every port, which on a multi-gigabit AV fabric is unworkable. IGMP snooping is what separates a multicast-capable switch from one that will saturate the fabric the moment a 6 Gb/s flow shows up.

Most managed switches support snooping, but defaults vary. Some enable it globally; some require turning it on per VLAN. Verify before you commission, not after.

The second piece: the Querier

IGMP snooping by itself is not stable. Receiver subscriptions age out unless something keeps the table fresh. That something is the IGMP Querier, a device on each VLAN that periodically asks “is anyone still listening to this group?” Receivers respond, the table refreshes, and traffic keeps flowing.

In any network with a Layer 3 router on the VLAN, the router is automatically the Querier and you don’t have to think about it. In a flat Layer 2 AV network with no router, you have to configure one switch to act as the snooping Querier. This is the single most common cause of “the stream worked for a few minutes and then stopped.” The snooping table aged out, the switch stopped forwarding, and there was nobody asking the question that would have kept the table alive.

If you take one thing from this article, take that one. Confirm a Querier exists on every VLAN that carries multicast.

Crossing VLANs: PIM and the ASM/SSM choice

IGMP works inside a VLAN. The moment you have to move multicast across VLANs or subnets, you need something more, and that something is PIM (Protocol Independent Multicast). PIM runs on Layer 3 devices and uses the same unicast routing table the device already maintains to figure out how to deliver multicast traffic between subnets.

PIM operates in two flavors that matter for AV deployments. The choice between them is one of the few real architectural decisions you will make.

In Any-Source Multicast (ASM), receivers ask for a group without specifying which source they want. Because multicast addresses don’t reveal where the source lives, the network needs a Rendezvous Point (RP), a designated router that brokers the connection between sender and receiver. ASM works, it is robust, and the gear has supported it for two decades. The cost is configuration complexity and an RP that can become a bottleneck under load.

In Source-Specific Multicast (SSM), receivers specify both the source and the group as a pair. No Rendezvous Point is needed. Routers build a direct path between source and receiver. Configuration is simpler, behavior is more deterministic, and the RP bottleneck disappears. SSM uses the 232.0.0.0/8 address range by convention.

The catch is that SSM requires IGMPv3 at the receiver, and not every endpoint or control system supports it. If yours does, prefer SSM. If it doesn’t, ASM works fine for small to mid-size systems. What you cannot do is mix the two on the same address ranges without creating problems.

Designing the network around multicast

Once the protocols are sorted, the design rules are mercifully short.

Bandwidth is unforgiving. Multicast saves duplication, not bytes. A 6 Gb/s stream is still 6 Gb/s on every link it traverses. Provision your switch interconnects and uplinks for the worst-case sum of multicast traffic that will share them, plus headroom for bursts. Spine-leaf topologies are popular in ST 2110 networks specifically...

Sound & Video Contractor

Message History

Delivery option(s)