The short answer

WebRTC is how a voice agent runs in a browser rather than over a phone line. It removes telephony from the path entirely — no number, no carrier, no per-minute cost — and delivers wideband audio, which is materially better input for speech recognition than the 8 kHz the PSTN provides.

In detail

The standard bundles several pieces: capture and playback APIs, encrypted transport, congestion control, and the ICE machinery that negotiates a path between two endpoints behind NATs and firewalls. Media is always encrypted, which is not optional in the specification. When a direct path cannot be established, traffic relays through a TURN server, which is the usual reason a deployment needs infrastructure it did not plan for.

For voice AI the audio quality difference is the main draw. WebRTC typically carries wideband or fullband Opus rather than narrowband telephony codecs, preserving the high-frequency detail that distinguishes consonants. Recognition accuracy on the same speaker is generally better over WebRTC than over a phone call for exactly this reason.

The trade-off is reach and consistency. A phone number works from any handset; a WebRTC session requires the person to be on a page with microphone permission granted. And browser sessions run over the public internet, so packet loss and jitter vary far more than on a managed telephony path — which is why session lifetime, reconnection and expiry need to be handled explicitly.

How Rexa handles it

Rexa exposes browser voice sessions as rooms: creating one returns a room_url the visitor opens directly, with the WebRTC transport handled by Daily. Each room carries a ttl_seconds between 60 and 3600, defaulting to 900, after which the session expires — so an abandoned browser tab does not hold a session open indefinitely.

Rooms API

Back to the glossary

All 53 glossary terms