A WebRTC server is a set of roles, not one box

A WebRTC server is not one mandatory box defined by the browser API. A production system usually combines application signaling, ICE connectivity, STUN and TURN services, and—when more than two endpoints or server-side media handling are required—an SFU, MCU, gateway, recorder, or other media service. The architecture depends on who must exchange media, what the server must observe or transform, and which networks the users actually inhabit.

The WebRTC server stack

Signaling belongs to the application

The browser WebRTC specification defines APIs such as RTCPeerConnection, but it does not prescribe one application signaling protocol. Your service still needs a controlled way to exchange offers, answers, ICE candidates, room membership, identity, permissions, and lifecycle events.

This is why a WebSocket service is often present without WebSocket being the media transport. Signaling carries session data; media uses the negotiated WebRTC transports. Keep those two paths separate in diagrams, telemetry, and incident reports.

ICE, STUN, and TURN are operational dependencies

WebRTC endpoints use ICE to gather and test possible network paths. STUN can help an endpoint discover a server-reflexive address. TURN provides a relay when a usable direct path is unavailable or policy requires relaying. The IETF's WebRTC transport requirements require browser support for STUN and TURN configuration and describe TURN support for difficult NAT and firewall cases.

A demo that works between two laptops on one network proves very little about enterprise Wi-Fi, mobile carrier NAT, a UDP-blocking firewall, or a privacy policy that forces relay. Include TURN capacity and geography in the first production load model, not as an emergency patch.

When an SFU or media server is needed

A direct peer-to-peer path can fit a simple two-endpoint call. Multi-party rooms, one-to-many distribution, recording, server-side observability, composition, moderation, or protocol conversion normally introduce a server-side media role.

• SFU: receives streams and forwards selected media without mixing every participant into one composite. It may choose among simulcast or scalable layers.
• MCU/compositor: decodes and combines media into one or more composed outputs, increasing processing cost and changing failure behavior.
• Gateway: bridges WebRTC to another compatible media workflow such as SRT, RTMP, HLS, recording, or a production environment.
• Recorder: preserves selected participants, tracks, or a programme output under explicit retention and access rules.

Media, not room count, determines capacity

“One hundred rooms” is not a capacity specification. A useful model includes publishers and subscribers per room, resolutions, frame rates, codecs, simulcast and forwarded layers, TURN relay share, recording, composition and geographic traffic. Network egress can dominate an SFU; CPU or accelerator capacity can dominate a compositor or transcoding gateway.

Use a staged test: one real call, a representative room, peak room composition, then concurrency. Observe packet loss, RTT, jitter, selected candidate pair, bitrate, quality limitation reasons, CPU, memory, ingress, egress, TURN allocation, and downstream jobs.

Security is larger than media encryption

WebRTC media security is built around protocols including DTLS-SRTP, but the application still owns identity, authorization, room access, signaling security, abuse prevention, logging, credential lifetime, and TURN policy. The IETF's WebRTC security architecture is the standards reference; use it as a starting point for the application's operational threat model rather than treating encrypted media as complete protection.

The first Callaba room anchors downstream work

Callaba provides compatible browser-oriented video-call and media workflow modules alongside routing, Multiview, recording, protocol conversion and delivery capabilities. The product UI should first establish one accepted room or source, including capture permissions, connection path, picture, audio, participant identity and recovery. Recording or downstream delivery can then remain separate jobs.

The generic What is WebRTC? page owns the protocol introduction. The SRT-to-WebRTC guide owns one concrete conversion workflow. This page stays focused on the server-side architecture required to operate WebRTC at product scale.

Evidence for production acceptance

1. Test admitted browsers, operating systems, devices, cameras, microphones, and permission states.
2. Test direct, STUN-assisted, and TURN-relayed paths across representative networks.
3. Verify identity, room admission, reconnection, duplicate session, and credential expiry behavior.
4. Load the real publisher/subscriber composition with the intended codec and layers.
5. Observe client WebRTC statistics and server/network metrics on the same timeline.
6. Stop a media node or network path and rehearse the documented recovery behavior.
7. Verify recordings and protocol-converted outputs independently from the live call.

The topology becomes the capacity model

For each room type, estimate publishers, subscribers, simulcast layers, average selected layer, audio, retransmission overhead and the share of sessions expected to relay through TURN. An SFU that receives three layers from every publisher but forwards one per subscriber has different ingress, egress and CPU pressure from a simple room-count estimate. Model a popular speaker viewed by many people and a gallery where every receiver subscribes to many streams; both can exist in the same product.

Forced-TURN networks belong in rehearsal

A test between two laptops on the same office network says little about enterprise firewalls, carrier NAT, mobile handoff or UDP blocking. Rehearsal needs restrictive networks, intentional relay and supported TCP or TLS fallback, along with credential expiry and rotation. Candidate-pair type and region are useful evidence without retaining sensitive addresses beyond policy.

Failure should degrade deliberately. Decide whether a participant receives audio only, a lower simulcast layer, a reconnect prompt or a clean refusal when capacity is exhausted. Silent black video with a connected UI is not graceful degradation.