RTSP Multicast: Groups, IGMP, SSM & Network Tests | Callaba
More live video workflow notes and product updates.
RTSP multicast uses RTSP to describe or control a session while multiple receivers obtain media from a multicast group. That is different from opening one unicast RTP flow per viewer, and it is also different from assuming every multicast MPEG-TS feed has an RTSP control plane. The design works only when group, source, port, interface, IGMP and routing policy agree end to end.
Control can be unicast while media is multicast
Before you try multicast with Callaba
Callaba documents direct RTSP inputs in Multiview and supported RTSP sources in restream workflows. Those paths are valid starting points for ordinary RTSP URLs. Its documentation does not specify an RTSP multicast receiver or publisher mode, an IGMP join control, source-specific multicast selection, TTL setting, or multicast interface binding.
Do not paste a multicast RTSP URL into production and assume the whole transport is supported because a unicast camera worked. Confirm current protocol support with Callaba, then test on an isolated network segment before making it part of the service design.
| Evidence | What it establishes | What still needs proof |
|---|---|---|
| RTSP DESCRIBE succeeds | The control endpoint and description are reachable | The receiver joined the correct multicast media group |
| IGMP report is present | The host requested membership on an interface | Packets reach the socket and contain the expected program |
| Packets arrive | The network forwards group traffic | RTP continuity, codec support and decoded frames are healthy |
RTSP negotiates unicast or multicast transport
RFC 7826 defines unicast and multicast transport parameters as mutually exclusive. A multicast transport can identify destination addresses, media and control ports, and scope. The client can offer alternatives; the server selects a supported transport in its SETUP response.
Save that response. It is the session's concrete network contract. Record the multicast group, RTP and RTCP ports, source if source filtering is used, and scope or TTL. A diagram that says only “multicast” omits the values an operator needs during an outage.
IGMP controls IPv4 group membership
RFC 9776 specifies IGMPv3, the current Internet Standard for IPv4 multicast membership. A receiving host reports which multicast groups—and, with source filtering, which sources—it wants to receive to neighboring multicast routers.
On a switched VLAN, IGMP snooping can use membership information to avoid flooding multicast to every switch port. The VLAN also needs a reliable querier policy so membership remains current. Put receivers and sources on different subnets, and multicast routing becomes an explicit design task; ordinary unicast routing does not automatically forward the group.
SSM removes source ambiguity
RFC 4607 defines Source-Specific Multicast. An SSM channel is identified by both source address and destination group. Receivers request traffic from that source, which is useful when a group address alone is not enough to distinguish authorized or redundant senders.
Keep the source address in the runbook and monitoring labels. If a backup sender takes over, make the change explicit. Two sources sending different media into one any-source group can produce a difficult failure that looks like random corruption rather than a clean outage.
Bind the intended network interface
A receiver with management, internet and media interfaces may send its join on the wrong NIC if the application or route selection is ambiguous. Confirm the local address used for group membership, the route to the multicast range, host firewall policy, reverse-path filtering behaviour and container or virtual-network boundary.
At the sender, verify the source interface, group, port, TTL, packet rate and bitrate. At the receiver, verify the IGMP report on the intended interface, switch membership state, incoming packets, RTP sequence continuity, codec identification and decoded frames. Each step removes a different possible cause.
Use multicast for controlled network fan-out
Multicast can deliver one network stream to many receivers without one source-side copy per receiver. That advantage applies inside a network engineered for multicast. It is not a general internet distribution method and does not remove access-control, monitoring or redundancy requirements.
Decide who owns the group-address plan and prevent accidental reuse. Reserve ranges by environment, document ports and sources, define maximum bitrate, and monitor unexpected groups. Test what happens when the querier restarts, a receiver changes VLAN, or the primary sender disappears.
One VLAN works; the next one does not
Control requests succeed from both control rooms, and the server returns the same multicast destination. Receivers in the source VLAN show video; receivers across the routed boundary show a black screen. Changing codecs does nothing. Compare IGMP reports on each receiver, switch membership tables, multicast-routing state, TTL, source filters and packet captures on both sides of the boundary. The remote VLAN has no multicast route for the group. Add the approved routing and querier configuration, keep the group within its intended scope, and verify that the remote interface receives the expected source packets, RTP sequence advances, and decoded frames match the source.
Commission the path one boundary at a time
- Record the session contract. Save group, source, ports, payload mapping and scope from SDP and SETUP.
- Choose interfaces. Bind sender and receiver to the media network intentionally.
- Verify membership. Observe the receiver's IGMP report and the switch state.
- Verify forwarding. Capture packets at each routed boundary before touching the codec.
- Verify media. Check RTP sequence, bitrate, timestamps and decoded frames.
- Exercise failure. Restart the querier, remove a route and switch sources in a controlled test.
RTSP multicast FAQ
Does RTSP itself multicast the video?
RTSP describes and controls the session. RTP or another negotiated media transport carries packets to the multicast group.
Can multicast cross subnets?
Yes, when multicast routing, scope, membership and security policy are deliberately configured. It does not cross ordinary routed boundaries by default.
What is the first thing to check when video is missing?
Confirm the SETUP destination and source, then observe an IGMP report on the intended receiver interface and packets at that interface.
Does Callaba support RTSP multicast?
Callaba documents RTSP URL workflows but does not specify an RTSP multicast contract. Confirm current support and test group membership and media before deployment.