WebRTC

Telephony & Infrastructurealso: Web Real-Time Communicationalso: browser real-time audio

In one sentence

WebRTC is a set of open browser standards for capturing, processing and transporting live audio and video in real time, and it is what lets a website hold a spoken conversation with no plugin, no app and no phone call.

W3C and IETF W3C and IETF WebRTC standards, 2026Last reviewed 30 July 2026

Not to be confused with SIP and SIP trunking, or PSTN.

Definition

WebRTC is the thing that lets a browser carry live audio and video both ways with nothing installed.

Put a voice conversation on a web page in real time and this is what is underneath it.

WebRTC, short for Web Real-Time Communication, came out of two standards bodies working in parallel: the W3C wrote the browser APIs and the IETF wrote the protocols sitting beneath them. Three of the things it hands a voice agent are exactly the three that agent needs, which are a way to take audio off the microphone, a transport built for real time, and an audio processing chain that ships with the browser.

The pieces a voice agent leans on

  • Microphone capture via getUserMedia, the call that makes the browser ask a visitor for permission.
  • The audio processing chain, which almost nobody gives enough credit. Echo cancellation, noise suppression and gain control all come built into the browser, and barge-in over laptop speakers is only possible because the first of those is running.
  • Transport that reaches for RTP over UDP whenever the network allows it, with congestion control and loss concealment tuned specifically for speech.
  • Codec negotiation, and for audio in the browser the default that falls out of it is Opus.

Why UDP transport matters for voice

  • Delay hurts a conversation more than loss does. Resend a dropped packet and it turns up after the moment it was needed, so a brief gap papered over by the codec beats a stall every time.
  • Web pages want the reverse, which is the underlying reason voice riding a plain WebSocket starts behaving differently the moment the network degrades.

WebRTC against WebSockets, the practical choice

  • TCP underneath WebSockets makes them easier to build against, friendlier to locked-down corporate networks, and perfectly serviceable for a great many voice deployments.
  • What WebRTC returns for the extra work is better behavior on bad networks, the audio chain thrown in, and less delay when packets go missing.
  • A good number of platforms take the WebSocket route for simplicity and live with the consequences. That is real engineering judgment rather than a corner cut, so long as somebody actually made the call.

What it costs to get the connection up

  • Before any audio flows there is signaling to exchange, ICE candidates to gather, and frequently a STUN or TURN server standing by to get through network address translation. All of it takes time, and unless the connection was opened ahead of the first word that time is charged to first-word latency.

Common misconception

That video calling is all this is for. A large share of live audio in the browser rides on it, most browser-based voice agents included, and for a voice agent the processing chain it brings along is plausibly the more valuable half of the package.

Why it matters commercially

Adopt it and the phone network simply stops being part of the picture. Nothing to provision, no carrier, no per-minute telephony bill, no spam label, no international dialing. That is the architectural advantage a website voice agent is built on, and it explains why on-site voice and telephony voice have such different economics.

In voice specifically

The browser's echo cancellation is what stops an agent hearing itself through the laptop speakers and treating its own voice as an interruption. Nothing in a text widget has an equivalent, which is why the audio chain is the part teams discover late and painfully.

Where AsqVox fits

Because the Orb lives inside a browser page, the transport story is browser-native real-time audio, echo cancellation and noise suppression included. Nowhere in the model is there a carrier to sign with or a number to provision, and getting it running is one script tag.

Visual

Two ways audio reaches a voice agent

Two ways audio reaches a voice agentA person with aquestionThe voice agentTelephonehandset, carrier, PSTN, SIP trunkNumber provisioningPer-minute carrier costSpam-likely riskNarrowband audioBrowser, WebRTCmicrophone, browser, direct real-time connectionNo numberNo carrier costWideband audioMicrophone permission promptSetup takes time, warm it before the first wordWhat the browser gives you freenot a third route, but what the browser route gets from the WebRTC stack without anyone building itAcoustic echo cancellation, which is what makes barge-in work on laptop speakersNoise suppressionAutomatic gain control

Same agent. One route has a phone bill and a spam label.

The wideband chip on the browser route traces back to Opus, which WebRTC requires every implementation to support. Narrowband on the telephony route is not a choice either, it is what the phone network gives you.

Statistics

Every figure carries its source and year. Vendor numbers are labelled as vendor numbers, and where no reliable figure exists this page says so rather than borrowing one.

Two bodies wrote WebRTC between them, the W3C covering browser APIs and the IETF covering protocols. That makes it an open standard rather than any vendor's property.

W3C and IETFindustry range

W3C and IETF WebRTC standards, 2026 - Verifiable from the specification rather than measured. What follows from it is that nobody owns it and nobody has to be paid for permission to implement it.

Every WebRTC implementation is required to support Opus, defined in IETF RFC 6716, and G.711 as well so that legacy telephony still interoperates.

Opus and G.711industry range

IETF RFC 6716 and the WebRTC codec requirements, 2026 - Cite the RFC number rather than the year recorded against this row. The G.711 requirement is the part that earns its keep the moment a browser call has to reach the phone network.

Conversational voice is designed to a sub-second first-audio target, and unless the connection was opened in advance, getting it established is spent from inside that same budget.

Under 1,000 msindustry range

Industry working threshold, 2026 - A working convention rather than a published standard. The WebRTC-specific point is that setup cost is inside the budget, not outside it.

Past roughly 1,500 milliseconds, an exchange starts to feel broken.

1,500 msindustry range

Industry working threshold, 2026 - A shared working line rather than a measured cliff, and the number a buyer will feel in a demo without being told to look for it.

Human speakers leave roughly 200 milliseconds between turns.

200 msindustry range

Widely cited conversational turn-taking baseline, 2026 - A reference point rather than a target. Cite it as the human baseline, not as a measurement of a system.

Nobody has published an authoritative figure for how long a WebRTC connection takes to establish, and for good reason: the answer swings on the state of the network, on whether traffic has to be relayed through TURN, and on how far the user sits from the closest point of presence.

-no reliable figure

Whatever single number you were quoted, it misleads. Take the measurement yourself, across the networks your visitors are really on, and report a percentile.

Nothing dependable has been published that puts WebRTC and WebSocket transport head to head on voice quality in real conditions.

-no reliable figure

In theory the tradeoff is well understood; in public it is barely measured. Which is why the choice deserves to be made deliberately rather than treated as settled in either direction.

Examples

In practice

A voice widget goes out over WebSockets. Testing looks fine. Then the complaints start arriving from mobile users on cellular, whose intermittent packet loss turns into audible stalls rather than the short concealed gaps WebRTC would have given them. Media moves to WebRTC, signaling stays where it was, and the mobile complaints stop. The bill for that is TURN infrastructure to serve users behind restrictive networks.

The everyday version

Because of WebRTC, a website can hold a conversation with you when you have installed nothing and dialed nobody. The same machinery is what puts you into a video meeting the moment you click a link.

Usage

Who says it

  • Infrastructure teams and the engineers who work on real-time media, constantly.
  • Almost never buyers, who have no reason to. What reaches them is simply that it runs in the browser, with nothing to install and nobody to call.
  • Security teams now and then, since how WebRTC behaves on a network and what it does to a corporate firewall are fair questions to ask.

Where it turns up

  • Filed beside supported browsers, the transport protocol, what STUN and TURN are needed, network and firewall requirements, and anything Content Security Policy has to permit.
  • Inside an enterprise it is the firewall and network clause that decides whether any of this ships. Better to answer it up front than to wait for it to be raised.

Common misuse

  • Taking WebRTC support to mean the call is peer-to-peer. In a voice agent deployment the media goes to a server, not straight from one user to another.
  • Treating the audio processing chain as something you can turn off. Killing echo cancellation to get at raw audio is a classic early mistake, and barge-in dies with it.
  • Letting WebRTC stand in for browser voice generally, when a good share of implementations are running WebSockets.

Questions people ask

What does WebRTC do in a voice agent?

Three jobs. Getting audio off the microphone through getUserMedia, which is the call that produces the browser permission prompt. Moving that audio in real time over RTP and UDP, with loss concealment and congestion control tuned for speech. And handing over echo cancellation, noise suppression and gain control that the browser already implements. That third one is why barge-in survives on laptop speakers.

Is WebRTC better than WebSockets for a voice agent?

WebRTC copes better when the network is poor, loses less time to dropped packets, and arrives with the audio chain attached. WebSockets sit on TCP, take less work to build against, pass through locked-down networks with fewer arguments, and serve plenty of deployments perfectly well. Since nothing dependable has been published comparing the two on voice quality in real conditions, treat this as a judgment call rather than a decided question.

Does WebRTC mean the call is peer-to-peer?

No. In a voice agent deployment media goes to a server rather than straight between users, so what the standard supports tells you nothing about how any particular product was assembled. Reading it the other way is among the most frequent misunderstandings of the term.

How long does a WebRTC connection take to set up?

Nobody has published an authoritative figure, and the reason is that the answer swings on the state of the network, on whether TURN has to relay the traffic, and on how far the user sits from the closest point of presence. Any one number would mislead. What counts operationally is that this setup time is charged to first-word latency unless the connection was opened ahead of it.

Share this definition

Last reviewed 30 July 2026. Written and reviewed by Dhruv Dholakia, founder of AsqVox.