WebRTC
Master WebRTC: peer-to-peer communication, video/audio streaming, and real-time collaboration.
What is WebRTC?
WebRTC is a set of browser and native APIs for carrying real-time audio, video, and application data between endpoints. It captures local media, negotiates compatible formats, finds a network path, encrypts the transport, and continuously adapts to changing bandwidth.
WebRTC matters when delay changes the experience: a conversation, remote consultation, multiplayer interaction, screen share, or collaborative cursor cannot wait for the store-and-forward path used by ordinary uploads. It can connect two peers directly, but production group calls usually introduce media servers for scale and control.
The core invariant is one authenticated session must negotiate a reachable, encrypted media or data path and keep that path usable as the network changes. WebRTC secures the transport, but the application still owns identity, room authorization, signaling, TURN credentials, topology, abuse controls, and recovery behavior.
Media devices
Capture
getUserMedia() and getDisplayMedia() create audio, camera, and screen tracks after the user grants permission. The application owns device selection and mute state.
Session contract
Negotiate
RTCPeerConnection exchanges offers and answers that describe codecs, tracks, directions, extensions, and transport parameters.
ICE + STUN + TURN
Connect
ICE gathers candidate addresses and tests candidate pairs. STUN can expose a public mapping; TURN relays traffic when no direct pair works.
Live transport
Protect + adapt
DTLS establishes keys, SRTP protects media, and feedback loops adjust bitrate and quality as loss, jitter, delay, and available bandwidth change.
Separate signaling from the media path
WebRTC does not define signaling. The application must provide an authenticated control channel, often HTTPS plus WebSocket, that exchanges session descriptions, ICE candidates, room membership, and call state. Review WebSocket first if a long-lived bidirectional control channel is unfamiliar.
Signaling messages help endpoints agree on a path; they do not have to carry the media after the connection is established. A signaling outage and a media-path outage are therefore different failures.
Control plane establishes the media plane
The signaling service coordinates identity and negotiation. ICE selects the reachable transport path, which may be direct, relayed through TURN, or terminated by a media server.
Capture + intent
Authenticated client
Join an authorized room, request device permission, add tracks, and express the desired send and receive directions.
Control messages
Signaling service
Route offers, answers, candidates, membership changes, and negotiation state to the correct session. Reject messages from unauthorized participants.
Connectivity
ICE services
Use STUN to discover public mappings and TURN to provide a relay candidate. Credentials should be scoped and short-lived.
DTLS + SRTP
Selected transport
Run connectivity checks, establish cryptographic keys, then carry protected media or a data channel over the nominated candidate pair.
Receive + adapt
Media server or peer
Forward, mix, decode, or render media while transport feedback changes the sender's rate and the receiver's selected quality.
Follow one connection from permission to first media
1 Application
Authorize the room
Authenticate the user, verify room membership and role, issue scoped signaling and TURN credentials, and decide which tracks the participant may publish.
2 Browser
Capture and add tracks
Request only the devices needed for the current action. Add each
MediaStreamTrackto the peer connection and expose clear mute and stop controls.3 SDP
Exchange offer and answer
Negotiate media sections, codecs, directions, header extensions, and transport parameters. Serialize concurrent negotiation so crossed offers do not corrupt state.
4 Network
Trickle ICE candidates
Send candidates as they are discovered. The remote endpoint adds them and ICE tests candidate pairs according to priority.
5 Transport
Select and secure a pair
Nominate a working pair, complete the DTLS handshake, derive SRTP keys, and begin media or data flow. A relay candidate means TURN stays on that path.
6 Runtime
Observe and adapt
Read connection state and statistics, preserve audio under pressure, change layers or bitrate, and recover deliberately when the path fails.
The example injects the peer-connection constructor and signaling function so its control boundary is testable outside a browser. Real signaling messages also need a session ID, sender identity, authorization check, schema version, ordering strategy, and replay or duplicate protection.
Make ICE fallback an explicit reliability contract
A candidate is one possible address and transport for an endpoint. ICE gathers several candidate classes, exchanges them through signaling, and checks pairs until it finds a working route.
Local interface
Host candidate
A local address can be the best path on the same network. It usually cannot cross the public internet, and browsers may obscure local addresses for privacy.
STUN mapping
Server-reflexive candidate
STUN reveals the public IP and port mapping created by a NAT. ICE still has to prove that the remote endpoint can reach that mapping.
TURN allocation
Relay candidate
TURN allocates a reachable relay address and forwards packets. It improves connection success while adding infrastructure cost, another failure domain, and path latency.
STUN is not a media relay, and TURN is not a signaling server. A production design normally offers TURN/UDP plus a carefully tested restrictive-network fallback such as TURN over TLS/TCP 443. Relay-only policy can hide peer addresses or enforce a network boundary, but every session then consumes relay capacity.
Use the lab to move from a local network to home NAT, symmetric NAT, an UDP-blocking firewall, and a TURN outage. Then change candidate and relay policy rather than assuming one fallback works everywhere.
Loading network scenarios
The lab makes direct and relay fallback behavior inspectable.
Loading ICE scenarios...
Engineer TURN as part of the availability path
- Deploy relays in the regions where users connect, and steer allocations by measured network path rather than account geography alone.
- Budget both ingress and egress bandwidth, concurrent allocations, port ranges, and loss of one relay node or availability zone.
- Issue short-lived credentials after room authorization; never embed a permanent relay secret in client code.
- Monitor allocation failures, relay share, transport mix, packet loss, RTT, throughput, and regional saturation.
- Test direct-path failure, blocked UDP, expired credentials, DNS failure, certificate rotation, and relay-region evacuation before an incident.
Choose topology before multiplying participants
The phrase "peer to peer" describes one possible WebRTC path, not a complete group-call architecture. With n participants, a full mesh creates n x (n - 1) / 2 peer connections. Each publisher sends a separate copy to every other participant, so client upload and encoding work grow with room size.
No media server
Peer mesh
Every endpoint connects to every other endpoint. It is simple for very small rooms and keeps the media path direct, but weak clients and uplinks become the scale limit.
Select + forward
SFU
Each publisher sends one or more encoded layers to a selective forwarding unit. The SFU forwards the layers each receiver needs without composing one shared frame.
Decode + mix
MCU
A multipoint control unit decodes inputs and produces a composed output. Clients receive one stream, while the server pays central decode, layout, and encode cost.
Topology is a product decision as well as an infrastructure choice. An SFU preserves independent participant streams for active-speaker layouts and adaptation. An MCU can simplify constrained endpoints or produce a canonical composite, but it centralizes compute and can remove receiver-side layout flexibility.
Loading the media planning model
The lab keeps every bandwidth and infrastructure assumption visible.
Loading conference assumptions...
The capacity lab exposes assumptions instead of claiming universal limits. Codec, content motion, screen sharing, simulcast configuration, receiver layout, hardware, packet loss, regional fan-out, and implementation quality all change the measured envelope. Benchmark representative calls and preserve failure headroom.
Adapt media before the network drops the call
Real-time media cannot wait for perfect delivery. The sender, receiver, and media server must trade visual quality for bounded delay while keeping audio intelligible.
Protect the path
Congestion control
Transport feedback estimates available bandwidth. The sender changes bitrate and may reduce resolution or frame rate before queues create seconds of latency.
Several encodings
Simulcast
A sender publishes multiple spatial qualities. An SFU can forward a thumbnail layer to one receiver and a larger layer to another without transcoding each view.
Layered stream
Scalable coding
Temporal or spatial enhancement layers build on a base layer. Dropping enhancements can reduce rate while preserving the decodable base, when the codec path supports it.
Conversation first
Audio priority
Preserve voice continuity before high-resolution video. Apply audio processing and packet-loss strategies carefully, then validate with real devices and noisy networks.
Treat screen share as a different workload
- Text and diagrams need sharp detail but often tolerate a lower frame rate.
- Camera video usually values motion continuity more than perfectly crisp individual frames.
- A receiver layout should subscribe only to visible or important streams and reduce off-screen work.
- Pausing a track, disabling a sender, and replacing a track have different negotiation and resource consequences; define the product behavior explicitly.
- Codec choice must account for browser and device support, hardware acceleration, quality at the target rate, decode power, and media-server capabilities.
WebRTC data channels use SCTP over the secured peer-connection transport. Reliable, ordered delivery fits chat and control messages. Unordered delivery with a bounded retransmission policy can fit rapidly superseded game or cursor updates. A data channel still needs message-size limits, backpressure through bufferedAmount, authorization, and an application schema.
Recover the right layer instead of restarting everything
Connection state is a diagnostic input, not a complete recovery policy. The signaling channel, ICE transport, DTLS transport, individual tracks, decoder, and media server can fail independently.
1 Observe
Detect user-visible degradation
Combine join time, connection state, inbound and outbound statistics, freeze signals, and user actions. One packet-loss sample should not trigger a call rebuild.
2 Reduce
Adapt inside the current path
Lower sender rate, request a different layer, reduce visible subscriptions, and protect audio while the congestion controller and jitter buffer respond.
3 Re-route
Restart ICE when connectivity failed
Gather fresh candidates and renegotiate transport when the network interface, NAT mapping, or selected pair is no longer usable. Keep the room identity stable.
4 Replace
Rebuild only when state is unrecoverable
Create a new peer connection after bounded recovery attempts, clean up every sender and track deliberately, and reject stale signaling from the replaced generation.
Monitor outcomes and causes together
connected / attempted
Join success
Segment by browser, device, network, region, and direct versus relay path
permission to decoded frame
Time to first media
Separate signaling, ICE, DTLS, and media-start delays
RTT + jitter + loss
Network quality
Correlate with bitrate, frames, freezes, and selected candidate type
restored / disrupted
Recovery
Track adaptation, ICE restart, rebuild, and permanent failure outcomes
- Sample
RTCPeerConnection.getStats()at a bounded interval and calculate deltas; cumulative counters alone hide when degradation happened. - Record the selected candidate type and transport without logging raw peer addresses unless the privacy and retention need is explicit.
- Correlate client quality with SFU, MCU, and TURN region metrics using a call-scoped trace identifier.
- Measure percentiles and failure cohorts. Fleet averages hide one browser version, mobile radio, ISP, or relay region that cannot connect.
- Preserve enough diagnostic context to reproduce negotiation and routing decisions, but do not log SDP, access tokens, room secrets, or media payloads indiscriminately.
Secure the room, not only the packets
WebRTC media transport is encrypted, but transport encryption does not decide who may join a room or what an authorized participant may publish, subscribe to, record, or forward.
Define the trust boundary
- Authenticate every signaling connection and authorize every room action on the server; do not trust a client-supplied participant or room identifier.
- Bind offers, answers, candidates, and renegotiation messages to one authorized session generation so stale or cross-room messages are rejected.
- Use short-lived TURN credentials and rate limits to prevent the relay fleet from becoming an open proxy or bandwidth theft target.
- Make screen sharing, recording, transcription, bots, and server-side media processing visible product states with explicit authorization and audit trails.
- Apply origin controls, content security policy, dependency review, and narrow device permissions around the web application that can access camera and microphone data.
Be precise about end-to-end encryption
DTLS-SRTP protects media on each WebRTC transport. In a multi-party architecture, that does not automatically protect media from every forwarding, recording, or processing service in the trust boundary. If the product requires media to remain opaque to the SFU, it needs a compatible encoded-media encryption design, separate key management, participant verification, recovery rules, and feature trade-offs for recording, moderation, and server-side processing.
Use WebRTC when interactivity justifies the control plane
Human-scale latency
Strong fit
Use WebRTC for calls, live collaboration, interactive support, remote control, cloud gaming inputs, and peer data where low latency and continuous adaptation matter.
One to very many
Use broadcast delivery
Segmented HTTP streaming plus a CDN is often simpler and cheaper when viewers can tolerate more delay and do not need to send media back interactively.
Durable messages or files
Use ordinary APIs
HTTP uploads, object storage, WebSocket messages, or a queue are better when data must be durably stored, retried, audited, and processed rather than consumed as a live path.
Before launch, prove the whole operating contract:
- Join succeeds across home NAT, mobile networks, enterprise firewalls, and TURN-only policy at the supported browser and device matrix.
- The topology survives the largest room, concurrent-room peak, one media-node loss, and one relay-region loss without saturating remaining capacity.
- Audio remains usable under constrained bandwidth, loss, jitter, handoff between networks, backgrounding, and device changes.
- Renegotiation, ICE restart, signaling reconnect, and complete peer-connection rebuild are bounded, observable, and protected from stale messages.
- Room authorization, publishing permissions, TURN credentials, recording state, abuse controls, privacy retention, and incident access are reviewed together.
- Support teams can connect a user's symptom to signaling, selected candidate path, browser statistics, and the responsible media or relay region.