If you arrived from the business version, that piece made the cost case — always-on push versus on-demand pull, central fan-out, and failover. This is the companion “how,” for the architect who has to build or evaluate it. No re-running the cost math; we go straight to the wiring. Getting one RTSP camera into a browser is a solved problem, and we’ve documented the codec mechanics of it already.

Multi-site WebRTC surveillance is a different animal: the hard part isn’t any single camera-to-browser hop — it’s coordinating fifty of them into one Security Operations Centre (SOC) without transporting everything, all the time, across links you don’t control.

The mistake is to think of it as one big pipe. It’s three separate planes, each with its own engineering problem and its own failure mode.

The Topology of Multi-Site WebRTC Surveillance: Three Planes, Not One Pipe

Sort the system by where the work happens and it resolves into site edge, central aggregation, and SOC client. Each plane is tuned independently, and conflating them is how designs that demo fine fall over at forty sites.

Plane What runs Key tuning knob Primary failure mode
Site edge RTSP ingest, repackage or transcode, WebRTC egress Codec path, pull-on-subscribe Site goes dark
Central SFU: one ingest per site-stream, N forwards On-demand subscription Over-subscription / relay saturation
SOC client WebRTC subscriber, wall mosaic, focus view Sub-stream vs main-stream Workstation decode ceiling

Read left to right, this is the whole path: a camera’s RTSP stream at a site becomes a WebRTC track a SOC operator subscribes to — but only when they subscribe.

Start at the edge, because that’s where the codec economics and the pull-on-demand behaviour are actually implemented.

At the Site: The Edge Relay

Every site runs one small relay: a single point of contact between the local cameras and the outside world. It ingests RTSP locally, records locally, and speaks WebRTC to the center. Three decisions define it.

RTSP ingest: where to tap

The relay can pull from the camera’s RTSP endpoint directly or from the NVR’s restream. Camera-direct gives you both the main-stream and the sub-stream the camera already encodes; tapping the NVR avoids a second connection to the camera but couples you to the NVR’s restreaming behaviour. Which tap you choose, and how you avoid adding load the NVR wasn’t sized for, is its own topic — we cover it in depth in the NVR-coexistence piece [link]. For multi-site, the rule of thumb is: pull the sub-stream for the wall mosaic, reserve the main-stream for the focus view, and take both from the camera where the camera can serve two concurrent pulls.

The codec decision at the edge

This is where per-site CPU sizing is won or lost. If a camera sends H.264, the relay repackages it — RTP-from-RTSP re-wrapped into WebRTC’s RTP — with no re-encode: near-zero CPU, low-hundreds-of-milliseconds latency. If a camera sends H.265, which the 4K cameras bought to save storage almost certainly do, the browser can’t be relied on to decode it (Chrome and Safari have added H.265 over WebRTC recently; Firefox hasn’t), so the relay must transcode to H.264 — a full decode-and-re-encode of every frame. The codec deep-dive covers why this split exists [link]; what matters here is the multiplication: transcoding is per-stream, so an edge box that shrugs at one transcode becomes a server the moment all eight cameras at a site are being watched in H.265. The mitigation is architectural — transcode only the streams a human has actually subscribed to, never the whole site — which is exactly what pull-on-demand buys you.

Push vs pull, implemented

The relay keeps a lightweight control-plane connection to the center open at all times — a signaling channel (typically a WebSocket) over which it registers, heartbeats, and receives subscribe/unsubscribe commands. Media is different: the relay opens a WebRTC media path for a given camera only when the center tells it an operator has subscribed, and tears it down when the last subscriber leaves. Control plane always on; media plane on demand. That single implementation detail is what turns the business version’s “on-demand pull” from a slogan into the mechanism that keeps both bandwidth and transcode cost proportional to what’s being watched. It also has a happy side effect for NAT, which we’ll get to.

In the Middle: The Central SFU and Fan-Out

Why an SFU, and not an MCU or mesh

A mesh has every source send to every viewer and collapses past a handful; an MCU decodes and re-mixes everything into one stream, which is CPU-heavy and adds latency. A Selective Forwarding Unit (SFU) receives one upstream copy of each stream and selectively forwards packets to subscribers without re-encoding — low latency, light on CPU, and the standard for real-time video. The full SFU-versus-alternatives explainer lives in our enterprise video architecture piece [link]; here it’s enough that the center is an SFU.

Fan-out mechanics

The site relay pushes a camera’s stream to the SFU once. The SFU forwards it to every subscriber — three operators plus the video wall — as independent downstream tracks, without the site ever uploading more than that single copy. This is the fix for the per-viewer duplication the business version described: per-site upload stays flat regardless of how many people open the same feed. It’s also the layer where a wall showing dozens of tiles pulls sub-streams while a single focused operator pulls the main-stream — the SFU forwards whichever the client subscribed to.

On-demand subscription — the mechanism behind the cost gap

The SFU only asks a site for a stream when at least one client subscribes to it. No subscription, no media leaves the site. Across 400 cameras with 30–40 watched at peak, that’s the difference between forwarding everything and forwarding a tenth of it — the 10× swing, expressed as subscription state rather than a bandwidth bill.

One note for managed service providers running several client estates from one platform: because subscriptions and streams are keyed per session, the same SFU can isolate tenants into separate namespaces with per-tenant authentication, so estate A’s operators can never subscribe to estate B’s cameras. That’s the whole of what multi-tenancy needs to be for this architecture — namespace and auth isolation at the subscription layer, not a separate system. The harder problems are on the WAN.

Use the camera’s dual-stream instead of simulcast

WebRTC’s usual answer to “different viewers need different resolutions” is simulcast — encode several layers at the source. In surveillance you rarely need it, because the camera already encodes a main-stream and a sub-stream natively. The wall mosaic subscribes to sub-streams; the focus view subscribes to the main-stream; nothing at the edge has to generate extra layers. This is the same decode-ceiling logic as the video-wall piece [link], applied across the WAN: sub-streams keep both the link and the operator workstation inside budget, and the main-stream is spent only where someone is actually looking.

Long-haul links have higher round-trip time and more variable jitter than a LAN, and WebRTC’s defaults are tuned for shorter hops. The levers: widen the receiver jitter buffer / playout delay to trade a little latency for smoothness, size the NACK retransmission window to the actual RTT so retransmits still arrive useful, and let the bandwidth estimator settle rather than oscillate on a link that’s bursty by nature. For a live view an operator acts on, keep the target latency tight; for a low-priority wall tile, a slightly deeper buffer is the right trade.

NAT traversal across many remote sites

Remote sites are usually behind NAT, often carrier-grade NAT with no inbound reachability at all. Here the pull-on-demand design pays off again: because the edge relay dials home to the center over its outbound control channel and originates the media connection outward, the center never needs to reach into the site. That sidesteps inbound NAT for the site side entirely. You still run STUN/TURN for the general WebRTC handshake and for SOC clients on awkward networks, and you budget TURN relay capacity for the fraction of paths that can’t go direct — but you are not port-forwarding fifty sites. Which leaves the failure case every multi-site system has to answer for: a site going offline.

When a Site Drops: Failover and Reconnection

Local recording continuity. The edge relay records the main-stream to local storage continuously, independent of WAN state — H.265 for storage efficiency, retained per your policy. A WAN outage never creates a recording gap; the footage is on-site and indexes to the center when the link returns.

Health signaling. The control-plane heartbeat is what stops a frozen tile from masquerading as a live one. When heartbeats stop, the center marks the site unreachable and the SOC surfaces an explicit “site offline” state rather than the last decoded frame. Detecting the outage is the point; a green wall that silently froze is worse than an obviously red one.

Reconnection logic. On recovery the relay re-registers automatically, with exponential backoff so a flapping link doesn’t hammer the center, and resumes subscriptions the SOC still has open. No operator should have to manually re-establish eight feeds because a branch’s ISP blinked.

Put the three planes together and the build-versus-buy question stops being philosophical.

Build, Buy, or Deploy Multi-Site WebRTC Surveillance

Build on open source. MediaMTX or go2rtc at each site for RTSP ingest, H.264 repackaging, and transcode-when-forced, in front of a general-purpose SFU at the center — mediasoup, LiveKit, or Janus are the usual open-source SFUs — with your own signaling, TURN, recording, and reconnection logic around them. Maximum control, and you own the transcode and subscription economics directly. Right when the media path is core to the product and you have the team to operate a distributed real-time system.

Use a managed cloud relay. Fastest to a working SOC view, nothing to run — but your camera feeds route through a third party and you pay per stream as sites multiply. Right when speed outweighs owning the path.

Deploy a commercial platform. The whole stack — RTSP ingest, repackage/transcode, SFU fan-out, on-demand subscription, recording — delivered as a unit you run on-premise or as a managed deployment on infrastructure you choose. Samvyo is one such option: it’s based on SFU architecture and deploys on-prem or as a managed cloud deployment under a flat license, which is the model that fits always-on surveillance rather than per-minute. Where it doesn’t fit: a single site or a handful of cameras, where open source or a relay is more than enough.

Three approaches, one axis — how much of the media path you want to own.

The Bottom Line

Multi-site WebRTC surveillance reduces to four implementation choices: an edge relay that pulls on subscribe and repackages H.264 rather than transcoding when it can, a central SFU that forwards only subscribed streams, WAN tuning that respects RTT and leans on the camera’s own dual-stream instead of simulcast, and edge-local recording that survives the link. Name the three planes and their failure modes, and the architecture writes itself — bandwidth, CPU, and cost all scale with what’s watched, not with what exists.

What’s Next?

Need the decision-maker’s version — what breaks and what it costs, without the wiring? The companion business piece frames the same three planes as a cost and operations decision: link to business version.

Frequently Asked Questions

How do you get 50 remote sites into one WebRTC SOC?

Run a relay at each site that ingests RTSP locally and speaks WebRTC to a central SFU, and have the SFU pull a site’s stream only when an operator subscribes. That keeps bandwidth and transcode proportional to what’s being watched instead of streaming all cameras always-on. SFU-based platforms such as Samvyo implement this fan-out-on-subscribe pattern natively.

Should the site-edge relay transcode or pass through?

Repackage (pass through) H.264 whenever possible — it’s near-zero CPU and low latency. Transcode only H.265 streams that must reach browsers which can’t decode HEVC over WebRTC, and only the ones actually subscribed, because transcoding is a per-stream decode-and-re-encode cost that multiplies fast across a full site.

Push or pull for multi-site surveillance?

Keep the control plane always connected but pull media on demand: the relay registers and heartbeats continuously, and opens a media path for a camera only when someone subscribes. This is the mechanism behind the roughly 10× cost difference versus always-on push, and it also lets the site originate connections outward, sidestepping inbound NAT.

How do you tune WebRTC for a high-latency WAN?

Widen the jitter buffer and playout delay to trade a little latency for smoothness, size the NACK retransmission window to the real round-trip time, and let the bandwidth estimator settle on bursty links. Use the camera’s native sub-stream for wall tiles and the main-stream only for the focused view, rather than generating simulcast layers at the edge.

In a correct design the edge relay records to local storage continuously, independent of the WAN, so an outage never creates a recording gap; footage indexes to the center on reconnect. The control-plane heartbeat also marks the site unreachable so the SOC shows an explicit offline state rather than a frozen tile.

How do you isolate tenants for an MSP running multiple estates?

Key streams and subscriptions per tenant and enforce per-tenant authentication at the SFU, so one estate’s operators can never subscribe to another’s cameras. For this architecture that namespace-and-auth isolation at the subscription layer is the whole of what multi-tenancy requires — which is why an SFU-based platform like Samvyo can serve several white-label estates from one deployment.