WebRTC started as the technology behind browser-based video calls without plugins — Google Hangouts, then countless video conferencing products after it. In 2026, its use cases have expanded well past video calls, and one specific new use case is quietly changing how teams need to think about infrastructure cost.
Where WebRTC shows up now
Beyond the familiar video conferencing and voice call use cases, WebRTC now underpins telehealth platforms (letting doctors diagnose patients remotely without requiring an app install, with real-time audio/video that can meet healthcare compliance requirements), live streaming and screen sharing, real-time collaborative tools, IoT device communication, and increasingly, AI voice agents — the conversational AI assistants that talk with users in real time over voice.
That last category is growing fast and worth understanding on its own, because it breaks an assumption that's been true about WebRTC infrastructure planning for years.
The peer-to-peer assumption that no longer holds
Traditional WebRTC connections are peer-to-peer by design — two browsers connect directly to each other, and a TURN relay server is only needed as a fallback when a direct connection fails, which happens roughly 15-20% of the time depending on network conditions (corporate firewalls, symmetric NAT, and similar network topologies that block direct peer connections).
AI voice agents break this pattern completely: there's no second human on the other end of the call to connect directly to. Every conversation with an AI voice agent goes through server-side infrastructure by necessity, with no peer-to-peer fallback available. That means 100% of AI voice agent traffic hits TURN relay infrastructure, compared to the 15-20% baseline that traditional WebRTC deployments plan around. If you're building or scaling a product with an AI voice agent component, this fundamentally changes your infrastructure cost model and capacity planning — the assumptions from traditional video-calling WebRTC deployments don't transfer, and under-provisioning TURN capacity for a voice-agent product will surface as real call quality problems, not just an edge case.
Where the protocol itself is evolving
Media over QUIC (MoQ) is one of the more significant infrastructure developments worth watching — it aims to combine WebRTC's low latency with the scale characteristics of traditional streaming protocols like HLS and DASH, while reducing some of WebRTC's inherent technical complexity. It's not a WebRTC replacement so much as an attempt to close the gap between "very low latency, harder to scale" (WebRTC) and "scales well, higher latency" (HLS/DASH) protocols.
On the ingest side, WHIP (WebRTC-HTTP Ingestion Protocol) has been gaining adoption as a way to unify WebRTC-based ingest with more traditional streaming ingest protocols like RTMP and SRT under one pipeline, simplifying infrastructure for platforms that need to support multiple ingest methods.
Putting real numbers on the TURN cost gap
The infrastructure planning gap described above isn't abstract — it shows up directly in the bill. TURN relay traffic typically costs $0.10-$0.30 per relayed gigabyte, and traditional peer-to-peer-first WebRTC deployments budget for roughly 5-10% of traffic needing relay, translating to somewhere in the $200-$2,000/month range at moderate scale. Some providers price per participant-minute instead of per GB — Daily.co, for example, charges $0.004 per participant-minute after free tier minutes are exhausted, while AWS prices WebRTC TURN streaming at roughly $0.12 per thousand TURN minutes.
Run that same math against an AI voice agent product, where 100% of traffic requires relay instead of 5-10%, and the cost multiplier is roughly 10-20x per unit of call volume compared to a traditional video-calling deployment of similar size — not because the underlying per-GB or per-minute rate changes, but because the share of traffic hitting the more expensive path goes from a minority case to the entire workload. Conversely, for products that remain genuinely peer-to-peer, pushing more call volume onto direct P2P connections is one of the highest-leverage cost levers available: shifting 50% of call volume from relayed to direct P2P connections can cut total infrastructure spend by 30-45%, which is worth an explicit engineering investment (better ICE/STUN configuration, TURN-avoidance tuning) for any product where call volume is meaningfully peer-to-peer capable.
Why AI voice agents specifically need WebRTC, not WebSockets
It's tempting to reach for WebSockets for an AI voice agent's transport layer, since it's simpler to reason about and already familiar from other real-time features — but the latency characteristics make that a poor fit for conversational voice specifically. WebSockets introduce roughly 500ms-1.5s of delay for audio streaming, and HTTP streaming adds 2-5 seconds, both of which are too slow for a conversation to feel natural. WebRTC, by contrast, was purpose-built for live low-latency audio and ships with the Opus codec, echo cancellation, and voice activity detection already built into the browser-native stack.
The latency budget matters because callers notice it directly: the critical metric is the gap between a caller finishing their turn and the first syllable of the agent's reply, where under 300ms feels human, 300-600ms feels sluggish but tolerable, and anything above 600ms causes callers to mentally downgrade the experience to "touch-tone system" territory. In a well-optimized 2026 pipeline, speech-to-text takes 100-200ms, the LLM adds 300-500ms with streaming enabled, text-to-speech adds another 100-200ms, and WebRTC's network overhead contributes just 50-150ms — landing total round-trip latency around 1 second for a standard STT-LLM-TTS pipeline. Newer speech-to-speech models (bypassing text entirely) can cut that to 400-800ms. This is also why many voice-agent builders now sit LiveKit on top of raw WebRTC rather than managing the SFU (selective forwarding unit) layer themselves — it handles the distributed routing and regional latency optimization that a from-scratch WebRTC deployment would otherwise require building in-house.
The practical takeaway
If you're evaluating WebRTC for a new product, the calculation now depends heavily on whether your use case involves genuine peer-to-peer connections (video calls, collaborative tools where two humans connect) or server-mediated interactions (AI voice agents, broadcast-style streaming) — the infrastructure cost and capacity planning differ substantially between these. For AI voice agent products specifically, budget TURN relay capacity as if 100% of traffic needs it, not the 15-20% baseline that classic WebRTC deployment guidance assumes — that gap is the single most consequential planning mistake for this specific use case.
Sources: rtcleague.com, bloggeek.me, antmedia.io, trembit.com, daily.co, livekit.com, bloggeek.me
Keep reading
Get new posts as they publish
No spam — just the next post, straight to your inbox.