Voice AI, WebRTC, and MoQ

*This commentary is based on the Voice AI section of my November 2025 webrtcHacks analysis, WebRTC vs. MoQ by Use Case. *

Voice AI is often presented as an obvious WebRTC use case: capture microphone audio in the browser, send it to a real-time model, and play the generated voice with as little delay as possible. WebRTC already solves those browser media problems. That makes it a practical choice, but not necessarily the inevitable long-term transport.

The architecture is not the same as a human-to-human WebRTC call. A Voice AI client always sends media to a known public service. It does not need to discover another user behind an unknown firewall or establish a true peer-to-peer path. Some of WebRTC’s Interactive Connectivity Establishment (ICE) machinery is therefore solving a harder problem than the application actually has.

There is also a more fundamental question about what the model needs. WebRTC is optimized to deliver media that sounds and looks good to humans. A model may eventually prefer encoded features or tokens instead of the same waveform and pixels sent to a person. If more inference moves onto the device, the useful network payload could change substantially.

Media over QUIC (MoQ) could fit that client-server future, particularly if developers want a simpler way to carry new machine-oriented formats. That was speculative when I wrote the original analysis. I found active standards work and academic examples, but little direct evidence that Voice AI platforms were preparing to use MoQ. The section below captures that argument from my broader WebRTC vs. MoQ by Use Case review.

Voice AI: 1:1, but one party is AI

Voice AI is a relatively new use case for WebRTC where a client sends audio—and sometimes video—to a real-time large language model (LLM) and receives generated media in response. Cloudflare had characterized WebSockets as a good fit for server-to-server and less latency-sensitive work, while recommending WebRTC for low-delay user conversations.

On the other hand, this use case is client-server rather than peer-to-peer. WebRTC has a comprehensive, but relatively slow, ICE process for creating a connection between 2 peers that could both be behind network address translation or a firewall. Voice AI systems sit on public servers, so much of that process is overkill.

Do real-time LLM makers care about better media?

I wondered how much of a real-time media problem there was to solve because WebRTC did not appear to be a priority for most AI hyperscalers. OpenAI used WebRTC largely to send media to and from browsers. It was implemented as an add-on gateway to its WebSocket system, not as the native core of the platform. My interview with Sean DuBois at OpenAI covered that architecture in more detail.

OpenAI was actually the furthest ahead on WebRTC. Ironically, Google—the main force behind WebRTC—did not appear to use WebRTC in the Gemini experiences I examined. I did not see sessions in chrome://webrtc-internals when using Google AI Studio, Gemini, or Gemini in Chrome, and I had not found evidence that native mobile was different.

WebRTC advocates often make the case for low latency in Voice AI. But if media latency is the overriding problem, why was WebRTC not a native part of more speech-to-speech Voice AI systems?

Media for humans vs. LLMs

webrtcHacks contributor Gustavo Garcia suggested that Voice AI could be a fit for MoQ. His argument was that WebRTC is very good at transmitting human voice, but that is an intrinsically hard problem and the resulting solution is complex. LLMs may not need all the processing humans require, making a simpler transport attractive.

Local speech recognition introduced another possibility, and the same idea could extend to speech synthesis. Browsers already exposed JavaScript APIs for both. However, voice models were also beginning to interpret tone and accent and adjust their own delivery. Gemini’s Affective Dialog was one example. Commodity on-device speech engines did not convey or interpret that extra information.

I expected newer neural processors in phones and laptops to enable more on-device media tokenization, but that was not broadly happening yet.

Encoding tokens

Standards groups were already investigating formats designed for machine processing. MPEG’s Video Coding for Machines work targeted what machine detectors need rather than what a person needs to view. Feature Coding for Machines went further by compressing intermediate features or tensors instead of pixels. MPEG was also exploring Audio Coding for Machines for machine listening and audio-feature transport.

Splitting inference between the client and server sounded like the future to me. These standardization efforts were still early, and LLM vendors might instead create proprietary mechanisms. MoQ was a plausible transport for such formats because it was new and potentially easier to adapt. However, I could not find much direct evidence beyond standards activity and a small number of academic papers.

My 2030 bet was intentionally uncertain: hopefully Voice AI would use something better suited than raw media over a WebSocket, but that replacement might not be WebRTC or MoQ.

Read WebRTC vs. MoQ by Use Case for the complete comparison across 1:1 calls, meetings, streaming, live streaming, and webinars.