Private RTC meetings: architecture, bandwidth and operations

Multi-party audio and video is one of the few workloads where a five-second outage is immediately visible to every participant. When the media path runs inside your own network, you gain control over data and topology — and you also become responsible for capacity, NAT traversal and upgrades.

This article walks through the planning work that determines whether a private RTC meeting deployment holds up under real usage.

Why private deployment changes the design

In a managed service, capacity, edge placement and network path are the provider’s problem. In a private deployment, you choose the topology and you own the failure modes. That makes three questions central:

1. Where do media streams flow, and through which network segments?
2. How much bandwidth and how many media nodes are required at peak?
3. Who operates, monitors and upgrades the cluster?

Reference architecture

A typical private meeting stack separates the media plane from the control plane.

Client SDK

Handles capture, encoding, packet loss resilience, rendering and network adaptation. Mobile, desktop and browser clients share a room model, but their behaviour under backgrounding and network changes differs — test them separately.

Signalling and room service

Manages room lifecycle, authentication, membership and negotiation. It is usually stateless or lightly stateful and can sit behind a standard load balancer.

SFU media service

Receives each publisher’s stream and forwards it to subscribers. For a meeting with n participants, mesh topologies require each client to upload n−1 streams; an SFU requires one upload per client and lets the server handle fan-out. That is why SFUs dominate meeting deployments.

TURN / relay service

Provides a relay path when direct connectivity fails. In an intranet, this may be limited, but hybrid and cross-site scenarios usually need it. Plan relay capacity separately: relayed traffic costs the same bandwidth twice.

Optional media processing

Recording, transcoding or gateway functions should be treated as separate services with their own capacity and storage plans. Not every deployment needs them; adding them after go-live is easier if the topology already reserves a place for them.

Bandwidth and capacity estimation

Bandwidth planning is arithmetic with assumptions. Start from a per-participant target and derive the facility requirement.

A common planning approach:

1. Choose an average send bitrate per participant for the dominant resolution and content type.
2. Multiply by the number of concurrent publishers.
3. Add a forwarding factor for the SFU: forwarded streams equal roughly subscribers × publishers for a single room, and aggregated across rooms for a cluster.
4. Add relay overhead where TURN or cross-site links are involved.
5. Add headroom for retransmissions and bursts — typically a meaningful percentage, not a rounding error.

Worked example with clearly hypothetical assumptions:

• 200 concurrent participants across meetings.
• Average 1.0 Mbit/s video plus 0.05 Mbit/s audio per participant.
• SFU forwarding factor of 2.5 (average subscribers per published stream).
• Peak factor of 1.5 over average.

Upload traffic ≈ 200 × 1.05 ≈ 210 Mbit/s. Forwarding traffic ≈ 210 × 2.5 ≈ 525 Mbit/s, and with the peak factor, plan links and nodes for roughly 800 Mbit/s of media traffic in the cluster. These numbers are illustrative: your resolution policy, content mix and room sizes will dominate the result.

Also plan:

• Per-node limits. CPU for encryption and forwarding, memory for jitter buffers, and network interface capacity.
• Failure headroom. Losing one media node should not drop the whole meeting. Size for n+1 where it matters.
• Cross-site traffic. If participants are split across sites, decide whether media is forwarded across the WAN or terminated locally and bridged.

Network considerations

• UDP is the default. Provide clear port ranges and firewall rules for media, and test with the same firewall policy as production.
• NAT and symmetric networks. Intranet-only deployments may avoid public STUN, but hybrid scenarios still need TURN or a relay.
• MTU and fragmentation. VPNs and tunnels can shrink usable MTU; validate large-packet behaviour.
• QoS markings. If your network supports it, mark audio and video traffic so congestion affects the right flow first.

Codecs and adaptation

Browser and device support constrains codec choice more than preference does. For meetings, consider:

• Hardware-accelerated codecs for battery and CPU.
• Simulcast or scalable video so the SFU can forward different qualities to different receivers.
• Audio processing and echo cancellation, which matter more to perceived quality than resolution.

Test adaptation explicitly: force packet loss and bandwidth limits, then verify that audio survives when video degrades.

Day-two operations

Private RTC does not end at go-live. Plan for:

1. Monitoring — join success rate, time to first frame, packet loss, round-trip time, per-node load. Alert on user-visible symptoms, not only CPU.
2. Upgrades — component compatibility, rolling upgrades, and a rollback path. Media nodes are stateful during a call; draining needs care.
3. Capacity review — track peak concurrency and update plans before quarterly business peaks.
4. Incident playbooks — relay failures, certificate expiry, node loss, and network policy changes.
5. Configuration management — treat topology and policy as code so environments stay consistent.

Security

• Authenticate room joins with short-lived tokens issued by your system.
• Encrypt media in transit; if end-to-end encryption is required, confirm what the server can still observe.
• Restrict administrative interfaces to management networks.
• Log access to recordings and any media storage separately from application logs.

Acceptance criteria for a proof of concept

A useful POC is small but adversarial:

• One room with 10–20 participants on mixed networks and devices.
• Packet loss and latency injection on a media path.
• Node failure during a call.
• An upgrade from the previous version.
• A bandwidth test at the planned peak, with monitoring reviewed afterwards.

When private RTC is not the right call

If meetings are sporadic, capacity is hard to predict, or you have no operations team for media infrastructure, a managed service will usually deliver a better experience per unit of effort. Private deployment pays off when data control, network isolation or integration depth genuinely outweigh the operational burden.

Feiyan RTC is built for private deployment and we will tell you honestly when a managed service fits your situation better.