A county IT team moves IPTV-style briefing channels to Source-Specific Multicast so receivers join explicit (S,G) channels. What must be true for that model to work at the edge?
Select an answer to reveal the explanation.
Short Explanation
SSM is Netflix for multicast: you pick the show and the studio uplink. Receivers must speak a version of IGMP that can name sources, and ops must know those source IPs up front. No RP scavenger hunt—just straight (S,G) joins.
Full Explanation
When county IPTV-style briefing channels move to Source-Specific Multicast, receivers join explicit (S,G) channels. That model works at the edge only when source addresses are known and hosts can signal source-specific interest with IGMPv3 (or MLDv2). SSM typically avoids shared-tree RP dependency for those groups (commonly 232/8 in IPv4), so edge signaling and known encoders are mandatory.
Only IGMPv1 hosts and a dense-mode core with no RP cannot express (S,G) INCLUDE interest and push the wrong forwarding paradigm for SSM briefing channels.
An Auto-RP mapping agent advertising every briefing group to 224.0.1.40 is an ASM RP-discovery tool. Pure SSM channels do not rely on Auto-RP shared-tree mapping as their edge requirement.
A single static (*,G) RP entry covering all briefing groups reintroduces ASM shared-tree thinking. It does not provide the host-side (S,G) signaling SSM needs.
Exam caveat: mixed ASM/SSM domains are common; do not assume “no RP anywhere in the network” just because briefing channels are SSM—other groups may still need an RP.
Operational check: publish encoder IPs and 232/8 groups to edge teams, verify IGMPv3 on receiver VLANs, and confirm joins install (S,G) state without waiting on RP Registers. File the channel map in the county AV/IT runbook for council and emergency briefings.