Peers exchange intent and discover reachable candidates.
Real-time media architecture
A WebRTC server is a set of roles, not one box
Separate application signaling, ICE discovery, TURN relay and SFU media routing so capacity, privacy and failure tests match the service you are building.
Size from routed media and relay probability—not room count alone.
Decision map workflow boundary
Plan bandwidth for restrictive networks.
Forward selected layers without hiding client limits.
ICE successTURN shareSFU egresspacket loss
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.
Capacity must be modeled from media, not room count
“One hundred rooms” is not a capacity specification. Record the number of publishers and subscribers per room, resolutions, frame rates, codecs, simulcast layers, expected 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.
Where Callaba fits
Callaba provides compatible browser-oriented video-call and media workflow modules alongside routing, Multiview, recording, protocol conversion, and delivery capabilities. Start in the product UI with one accepted room or source. Verify capture permissions, connection path, picture, audio, participant identity, and recovery. Add recording or downstream delivery as 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.
Production acceptance checklist
- Test admitted browsers, operating systems, devices, cameras, microphones, and permission states.
- Test direct, STUN-assisted, and TURN-relayed paths across representative networks.
- Verify identity, room admission, reconnection, duplicate session, and credential expiry behavior.
- Load the real publisher/subscriber composition with the intended codec and layers.
- Observe client WebRTC statistics and server/network metrics on the same timeline.
- Stop a media node or network path and rehearse the documented recovery behavior.
- Verify recordings and protocol-converted outputs independently from the live call.
WebRTC server FAQ
Does WebRTC require a server?
Production applications require at least signaling and usually STUN/TURN services. Whether media passes through an SFU, gateway, or compositor depends on participants, network policy, recording, routing, and product requirements.
What is the difference between STUN and TURN?
STUN helps discover address information used during ICE. TURN relays traffic when a suitable direct route cannot be established or policy requires relay. They are complementary roles, not interchangeable brand choices.
Is an SFU the same as a WebRTC server?
An SFU is one server-side media role. A complete system also needs application signaling, connectivity services, identity, permissions, observability, and often recording or other media workflows.
Can Callaba convert another protocol to WebRTC?
Callaba supports reviewed conversion workflows such as the existing SRT-to-WebRTC path. The exact source, codecs, audio, latency, participant behavior, and browser experience must be tested end to end.
