WebRTC Development in 2026: Architecture, Cost and Scope

WebRTC gives you encrypted, low-latency audio, video and data between browsers and native apps, for free and without plugins. It does not give you a product: signalling, NAT traversal (STUN/TURN), a media server for group calls, authentication, recording and monitoring are all yours to build or buy. Most of the cost and risk in WebRTC development sits in those pieces, not in the API itself.

What WebRTC handles, and what is left to you

The WebRTC API in the browser covers four things:

• Media capture (getUserMedia, getDisplayMedia) with device selection and constraints.
• Codecs and transport: Opus for audio; VP8, VP9, H.264 and increasingly AV1 for video; RTP over DTLS-SRTP with built-in congestion control.
• Connectivity: ICE, which tries candidate network paths gathered through STUN and TURN.
• Data channels: SCTP over DTLS for arbitrary messages, with reliable or unreliable delivery.

Everything around that is unspecified on purpose: signalling (exchanging SDP and ICE candidates), STUN and TURN servers, a media server for group calls, identity and room permissions, recording, monitoring (getStats gives raw numbers, not a pipeline) and SIP/PSTN interop. "Signalling is yours" is the first thing to internalise: the browser has no opinion on how two peers find each other, which is bad news for teams who assume the hard part is done once the demo works on localhost.

Architecture options: P2P mesh vs SFU vs MCU

The architecture decision is driven by one number: how many participants send video at the same time.

P2P mesh. Every participant connects directly to every other. No media server, but upload bandwidth and CPU grow linearly with participants; it degrades fast on mobile above three or four video senders.

SFU (Selective Forwarding Unit). Each participant sends one upstream (with simulcast layers) to the server, which forwards the streams each participant subscribes to without decoding. Low server CPU, latency close to P2P. The default for group calls in 2026.

MCU (Multipoint Control Unit). The server decodes every stream, composes one layout and re-encodes it. Clients receive a single stream regardless of room size. Expensive and slower, but right for legacy endpoints, constrained clients, or when you need a composited output anyway.

Criterion	P2P mesh	SFU	MCU
Practical participants (video)	2–4	10s to 100s per room (with simulcast and pagination)	10s, limited by server transcoding
Server cost	None (only STUN/TURN)	Moderate: bandwidth-bound, low CPU	High: CPU/GPU-bound
Bandwidth per client	Up: N-1 streams; Down: N-1 streams	Up: 1 stream (with layers); Down: subscribed streams	Up: 1; Down: 1
Added latency	Lowest	Small (forwarding only)	Highest (decode, mix, encode)
Recording	Client-side only, awkward	Per-track on server, compose later	Native, composite already exists
Best for	1:1 calls, telehealth consults, small huddles	Meetings, classrooms, webinars, live audio rooms	Legacy SIP/H.323 interop, broadcast, weak clients

Hybrids are common: P2P for 1:1 that upgrades to an SFU when a third participant joins. If unsure, start with an SFU; it covers the broadest range of products without repainting the architecture later. For the transport under the signalling itself, see WebSockets vs Server-Sent Events.

STUN, TURN and why TURN is mandatory in production

ICE gathers host, server-reflexive (public IP learned from STUN) and relay (TURN) candidates, and peers try pairs until one works. STUN is cheap and works when both NATs cooperate. It fails behind symmetric NATs, most corporate firewalls, some mobile carriers, and any network that blocks UDP. Then the only path is a relay through TURN.

Why mandatory: you will not see these failures in development. Your office and home networks connect fine; a share of real users, and a much larger share of enterprise users, do not. Without TURN those calls hang on "connecting" forever. Every serious deployment runs TURN, typically with:

• coturn self-hosted, or a managed relay (Twilio Network Traversal, Cloudflare Calls TURN, Xirsys, Metered).
• TURN over TCP and TLS on port 443 as a fallback for networks that block UDP entirely.
• Short-lived credentials generated per session (the REST API pattern from the TURN specification: username = expiry:userId, password = HMAC of that string with a shared secret). Never ship a static TURN username and password in a client bundle; it will be scraped and used as a free proxy.
• Regional placement. A single TURN in Frankfurt adds a round trip for users in São Paulo. Place relays near users.

Budget for it: relay traffic is the one WebRTC cost that scales with usage even in P2P architectures, and the relayed share is higher in corporate settings.

Managed platforms vs self-hosted media servers

This is the biggest build-vs-buy decision in a WebRTC project. Managed platforms sell an SDK, a global SFU fleet, TURN and recording, billed per minute. Self-hosting means running an open-source SFU and paying for compute and egress.

Option	Type	Model	Strengths	Watch out for
LiveKit	Open source SFU (Go) + LiveKit Cloud	Self-host or managed	Modern SDKs for web, iOS, Android, Flutter, React Native; simulcast, SVC, egress and ingress, agents framework for AI	Cloud pricing at scale; self-hosting still needs TURN and egress infra
mediasoup	Open source SFU (Node/C++ library)	Self-host	Excellent performance, fine-grained control, thin abstraction	It is a library, not a server: you write the signalling, rooms, scaling and recording
Janus	Open source general-purpose server (C)	Self-host	Mature, plugin architecture (video room, SIP, streaming), strong SIP interop	Older API surface; scaling across instances is your problem
Jitsi	Open source full meeting stack (Jitsi Videobridge, Prosody, web client)	Self-host or 8x8 JaaS	Complete product out of the box, good for internal meeting tools	Customising the UI deeply is harder than building on a bare SFU
Twilio Video	Managed	Per participant-minute	Strong docs, PSTN and SIP in the same ecosystem	Cost at scale; feature roadmap has been uneven
Daily	Managed	Per participant-minute	Prebuilt UI, fast time to first call, recording and transcription built in	Vendor lock-in through the SDK; less control over media pipeline
Agora	Managed	Per minute, tiered by resolution	Very large global edge network, strong in mobile and low-bandwidth regions	Data residency questions for EU workloads; pricing complexity

A practical way to decide:

• Choose managed when time to market matters more than unit cost, usage is uncertain, you have no one to run media infrastructure, or the video feature is secondary to the product.
• Choose self-hosted when minutes per month are high enough that per-minute billing dominates your margin, when EU data residency or on-premise deployment is a contractual requirement, or when you need control over the media pipeline (custom codecs, server-side processing, AI agents in the call).
• LiveKit is the common middle path: start on LiveKit Cloud, keep the option to self-host the same server later without rewriting clients.

If you self-host, remember the media server is a stateful, bandwidth-heavy workload: rooms are pinned to instances, autoscaling follows bandwidth and track counts, rolling deploys drop calls unless you drain, and the pods need host networking or a wide UDP port range.

Security: DTLS-SRTP is the easy part

Media encryption is handled: WebRTC negotiates DTLS between peers, derives SRTP keys from it, and refuses to send unencrypted media. The DTLS fingerprint travels in the SDP, so the integrity of your signalling channel is what protects media from substitution. The rest is ordinary application security on three surfaces:

Signalling. Run it over WSS. Authenticate the connection with a short-lived token issued by your identity provider (see OAuth 2.0, JWT and zero trust). Scope the token to a room and a role (publisher, subscriber, moderator). Validate every message server-side; the client's claim about which room it is in is not evidence. Rate-limit joins and offer/answer churn.

TURN. Ephemeral HMAC credentials as described above, with a TTL of minutes, not days. Restrict the relay to your media server's IP range when the SFU is the only peer clients ever talk to. Monitor allocation counts and bytes relayed per user to catch abuse.

Media server. Keep the SFU's control API off the public internet and issue room tokens from your backend, never from the client. Where the server must not see media (some healthcare and legal cases), Insertable Streams / SFrame give end-to-end encryption at the cost of server-side recording and transcription.

Compliance follows from the data map: who can join, what is recorded, where and for how long. The GDPR guide for European companies covers the documentation; for WebRTC specifically, treat IP addresses in ICE candidates and signalling logs as personal data.

Quality: simulcast, bandwidth estimation and mobile

Call quality is mostly a bandwidth management problem. The tools:

• Simulcast. The sender encodes two or three resolutions; the SFU forwards the layer each receiver can handle. Without it, one participant on a slow link drags everyone down. Enable it on every publisher in group calls.
• SVC with VP9 or AV1 does the same with one encoded stream and temporal/spatial layers. Better efficiency, narrower device support.
• Bandwidth estimation. The browser's congestion controller (TWCC) adjusts encoder bitrate continuously and the SFU switches layers downstream. Do not fight it: a fixed maxBitrate set too high produces packet loss, too low produces blurry video on good networks.
• Audio first. Use Opus with forward error correction and DTX. A meeting survives bad video, not choppy audio.
• Mobile. Hardware encoders vary, battery drains fast at 720p, and Wi-Fi to cellular switches need ICE restart handling. Native SDKs deal with most of this; a WebView does not. Test on real low-end Android devices.
• Measure. Poll getStats() and ship round-trip time, jitter, packet loss and selected layer to your analytics. Otherwise you cannot tell "the network was bad" from "the release was bad".

Recording and compliance

Recording sounds like a feature; it is an infrastructure component. Per-track recording (the SFU writes each stream separately) is cheap and flexible. Composite recording (a headless browser or MCU renders the room) gives a ready-to-play file at the cost of a rendering worker per room. Client-side recording (MediaRecorder) is fragile and depends on a large upload afterwards.

Compliance shapes the choice: consent shown before recording starts, retention enforced by policy, storage in the region your contracts require, and access controlled like the call itself. For regulated sectors, see healthcare application development regulations and security; the recording pipeline is usually what goes into the DPIA.

A minimal signalling flow

The protocol between two peers and your server is small. What matters is ordering and idempotency. A minimal exchange over WebSocket:

A -> server: join { room, token }
B -> server: join { room, token }
server -> A: peer-joined { peerId: B, iceServers: [...TURN with ephemeral creds] }
A -> server: offer  { to: B, sdp }
server -> B: offer  { from: A, sdp }
B -> server: answer { to: A, sdp }
server -> A: answer { from: B, sdp }
A <-> server <-> B: ice-candidate { to, candidate }   (many, in both directions)

On the client, the sequence for the offering side:

const pc = new RTCPeerConnection({ iceServers });
stream.getTracks().forEach((t) => pc.addTrack(t, stream));

pc.onicecandidate = ({ candidate }) => {
  if (candidate) ws.send(JSON.stringify({ type: "ice-candidate", to: peerId, candidate }));
};
pc.ontrack = ({ streams }) => (remoteVideo.srcObject = streams[0]);

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
ws.send(JSON.stringify({ type: "offer", to: peerId, sdp: pc.localDescription }));

ws.onmessage = async ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.type === "answer") await pc.setRemoteDescription(msg.sdp);
  if (msg.type === "ice-candidate") await pc.addIceCandidate(msg.candidate);
};

Two details cause most real bugs: ICE candidates arriving before the remote description is set (queue them), and both sides offering at once (glare; use the perfect-negotiation pattern from the WebRTC specification). With an SFU you do not write this at all: the SDK talks to the server and your backend only issues room tokens.

Scoping a WebRTC project: what drives cost and time

Teams looking for WebRTC development usually ask for a quote before they have an architecture. A handful of variables drive the estimate, and they matter far more than the size of the UI.

Driver	Low end	High end
Room size	1:1	Large rooms with pagination, active speaker, breakout rooms
Media platform	Managed SDK	Self-hosted SFU with autoscaling and TURN fleet
Clients	Web only	Web + iOS + Android native, plus desktop
Recording	None	Composite recording, transcription, retention policies
Interop	None	SIP/PSTN dial-in, legacy conferencing gear
Compliance	Standard GDPR	Healthcare/finance DPIA, EU-only data, end-to-end encryption
Observability	Basic logs	Per-call quality dashboards, alerting on connect success rate
Extras	Chat over data channel	Screen share with annotations, whiteboard, AI agents in the call

Rough ordering of effort:

1. 1:1 or small-group calls on a managed platform, web only. Weeks. Most of the work is auth, room lifecycle and UI.
2. Group calls with recording on a managed platform, web and mobile. A few months, with mobile testing the long pole.
3. Self-hosted SFU with TURN, recording, observability and compliance. Multi-month with a dedicated team, plus operations after launch. Load test with synthetic participants before go-live; this is where undersized TURN and SFU capacity shows up.

Operating cost is dominated by bandwidth (SFU egress, TURN relay), then media server compute, then recording storage. On a managed platform, model the per-minute bill against expected minutes per month; the crossover where self-hosting wins is clear once you have real usage data. For team and rate assumptions, see how much custom software costs in Europe. Our real-time application development service covers scoping and delivery of this kind of system.

Decision checklist

Before writing code, answer these:

• Maximum simultaneous video senders per room? If more than four, plan for an SFU.
• Managed platform or self-hosted? Decide on minutes per month, data residency and team capacity.
• TURN: which provider, which regions, ephemeral credentials issued from your backend?
• Signalling: transport, auth token lifetime, room and role scoping, glare handling?
• Simulcast or SVC enabled on all publishers?
• Target devices: which browsers, native mobile or WebView, lowest-end Android you support?
• Recording: per-track, composite or none; consent UI; retention; storage region?
• End-to-end encryption required? If so, accept losing server-side recording and transcription.
• Metrics: getStats collection, connect success rate, time to first frame, relay share?
• Interop: SIP/PSTN needed now or later?
• Load test plan with synthetic participants before launch?

Recommendation

For a new product in 2026: build on an SFU from day one, enable simulcast, and start managed (or LiveKit Cloud) unless you already know your minutes make self-hosting cheaper. Run TURN with ephemeral credentials from the first deployment. Issue every room token from your backend and keep the SFU's control API private. Instrument getStats before you have users. At Arvucore we usually recommend LiveKit for teams that want a managed start with a credible self-hosting path, and bare mediasoup or Janus only when the team has media engineering capacity in-house.