Does Conversational AI Really Need WebRTC? HTTP vs WebRTC for AI Avatars

Conversational AI does not always need a continuously open WebRTC connection. WebRTC is an excellent fit for applications that genuinely need continuous, full-duplex, low-latency media: phone calls, video calls, natural interruption, live perception and unstable mobile networks. But many AI character experiences are fundamentally turn-based. In those cases, modern speech and AI models can be fast enough to process each turn over ordinary HTTP.

That sounds like an implementation detail. It is not. The transport model affects infrastructure complexity, session costs, scaling, failure modes and which business models are economically viable.

Why WebRTC became the default for voice AI

WebRTC was designed for real-time communication. Browser APIs such as RTCPeerConnection can carry continuous audio, video and data with low latency, while ICE, STUN and TURN help establish connections across firewalls and network-address translation. That makes WebRTC a natural foundation for video conferencing, internet calling and voice agents.

Mozilla's WebRTC documentation describes it as a set of browser technologies for exchanging live media and data. Google's WebRTC documentation also notes that TURN relays are needed when peers cannot establish a direct connection.

For a traditional call, this architecture is exactly what you want. Audio is continuously flowing in both directions, the caller may interrupt at any moment, network quality may vary, and the application needs to preserve a live session until somebody hangs up.

Voice AI inherited the architecture of a phone call

Many modern voice-agent systems therefore model an AI conversation as a call.

A browser or phone joins a room. An AI agent joins as another participant. The user's microphone is streamed continuously to the agent. Speech-to-text, turn detection, an LLM and text-to-speech run inside that stateful session. The response audio is streamed back over the same real-time transport.

LiveKit's Agents documentation, for example, describes its agent as a stateful real-time bridge between the user and AI models. The frontend communicates with the agent over WebRTC, while the agent itself may talk to model providers over HTTP or WebSockets.

This is a good architecture when the AI experience really behaves like a call.

But not every AI conversation is a call

Consider a role-play training experience:

1. A virtual customer asks a question.
2. The learner listens.
3. The learner thinks for several seconds.
4. The learner gives a six-second answer.
5. The system transcribes and evaluates the answer.
6. The character replies for eight seconds.
7. The learner watches the character and considers what to say next.

There is a conversation, but there is not necessarily a continuous stream of useful media in both directions.

The same pattern appears in language learning, interview practice, tutoring, interactive stories, games, historical characters and many website assistants. The user speaks in turns. The character replies in turns. Much of the wall-clock session is silence, thinking, playback, animation or scene progression.

For these products, the useful engineering question is not “How do we make a cheaper call?” It is: do we need a call at all?

The alternative: STT → LLM → TTS → STA over HTTP

Liforma is built around a request-based model for many conversational experiences:

1. The browser captures the user's turn.
2. The audio is sent for speech-to-text (STT).
3. The transcript and experience state are sent to the LLM.
4. The response is converted to speech with text-to-speech (TTS).
5. The speech drives speech-to-animation (STA).
6. The browser plays the audio and animation.

Each turn can be treated as a discrete request rather than one segment of a permanently open media session.

That does not mean every stage must wait for the previous stage to finish completely. The server can stream partial results, start TTS as text becomes available, generate animation as audio arrives and deliver the first playable data before the full response is complete. HTTP is a request/response model, but the response itself can still be streamed.

Modern model speed changes the architectural trade-off

A request-based architecture would feel terrible if every turn required several seconds just to initialize models and establish processing. Historically, that was a strong argument for keeping everything connected and warm.

The trade-off changes as STT, LLM, TTS and animation models become faster and as inference systems keep models warm independently of an individual user's session.

The important distinction is between keeping inference capacity warm and keeping a per-user media session open. You can do the former without necessarily doing the latter.

A shared speech or animation service can remain hot and serve many short HTTP jobs from many users. The expensive model stays resident; the user's connection does not have to.

HTTP does not mean “slow polling”

When developers hear “HTTP instead of WebRTC,” they sometimes imagine a browser uploading a WAV file, waiting for a complete MP3 and then starting playback several seconds later.

That is not the architecture we mean.

Modern HTTP supports streamed request and response bodies. A turn can therefore begin processing as audio arrives and the response can begin returning before generation is complete. Server-Sent Events, fetch streams, chunked responses and ordinary API calls can also carry control events and incremental data.

The difference is not “streaming versus no streaming.” The difference is session-oriented transport versus request-oriented transport.

What does the LiveKit real-time agent layer actually cost?

For a developer building a conversational AI product with LiveKit, the economically relevant starting point is the hosted agent session. As of 22 September 2026, LiveKit's pricing calculator shows $0.0100 per connected minute for the agent session.

That is essentially the managed real-time session layer around the conversation: the agent process is kept attached to the live WebRTC session and LiveKit handles the connection and session orchestration. LiveKit separately meters raw WebRTC participant usage at a much lower rate, but that is not the meaningful cost comparison for an AI agent using LiveKit's hosted agent runtime.

If LiveKit observability is enabled in the calculator, that adds another $0.0100 per connected minute. Before any STT, LLM or TTS is selected, the hosted agent-session plus observability layer is therefore about $0.0200 per connected minute.

The AI pipeline is then added separately. Using the exact example currently shown in LiveKit's calculator:

If the user connects by phone through a LiveKit US local number, the calculator adds another $0.0100/min for telephony, bringing that example to $0.0479/min. For a web or mobile avatar experience, the telephony line is not relevant.

The important point is that LiveKit is providing a real-time agent platform, not a complete visual avatar stack. STT, LLM and TTS are chosen and priced separately. The quoted stack also has no speech-to-animation (STA) component, so a developer who wants an animated visual character needs to add a separate avatar rendering or animation system on top.

LiveKit observability includes capabilities such as recordings, transcripts, trace spans and logs. Liforma's analytics and diagnostics are not identical, but Liforma includes its experience analytics as part of the platform rather than adding a separate per-minute observability charge.

Why this is different from Liforma's pricing model

Liforma Live is currently priced at $0.01 per generated speech minute for the complete STT → intelligence → TTS → STA pipeline. Session orchestration and experience analytics do not have a separate per-connected-minute charge.

That creates a very different cost structure:

If a Liforma character speaks for half of a 30-minute experience, that is roughly 15 generated speech minutes, or about $0.15 at the published Liforma Live rate.

The LiveKit calculator example, by contrast, is about 3.79¢ for every connected minute before any avatar animation is added. Over 30 connected minutes, that is about $1.14 before the visual-character layer.

This is the architectural point behind Liforma's HTTP approach. We do not need to charge a per-user real-time session fee simply to keep a conversational connection alive. Instead, the platform can charge primarily for the useful AI work performed when the character actually responds.

Request-based architecture changes what you pay for

With a turn-based request architecture, infrastructure can more closely follow useful work.

This is particularly attractive for visual character experiences because the browser can do useful work independently: render a 3D backdrop, play animation, display captions, apply weather effects, show UI and progress between scenes without requiring a live media server to remain involved.

When WebRTC is clearly the better choice

There are important cases where we would choose WebRTC.

• Natural barge-in: the user should be able to interrupt the AI at any instant.
• Full-duplex conversation: both sides may speak and listen simultaneously.
• Continuous visual perception: the agent is constantly receiving webcam or screen video.
• Telephony: the product fundamentally behaves like a phone call.
• Challenging networks: adaptive real-time media handling and TURN fallback matter.
• Very rapid turn-taking: conversation is fluid enough that discrete turns become artificial.

LiveKit explicitly optimises for these conditions. Its documentation describes WebRTC as the frontend-to-agent transport because it provides reliable real-time communication even on unstable networks, along with turn detection and interruption handling.

If those properties are central to the product, replacing WebRTC merely to save infrastructure money would be a poor trade.

When HTTP is often enough

A turn-based HTTP architecture becomes attractive when:

• users naturally take turns speaking;
• the character can finish a response before the user replies;
• mid-sentence barge-in is not essential;
• most of the experience is interaction, playback or thinking rather than continuous media;
• the browser can handle presentation and animation locally;
• sessions may be long but actual generated speech is relatively short; and
• cost at consumer or educational scale matters.

Many role-playing, training, education, entertainment and website-assistant experiences fit this pattern.

WebRTC vs HTTP for conversational AI

What about latency?

Transport is only one part of perceived conversational latency.

For a turn-based system, the important timeline is usually:

end of user speech → transcript ready → first useful LLM output → first TTS audio → first animation frames → playback.

If those stages are streamed and overlapped, the user does not need to wait for the complete answer to exist before the character begins responding.

WebRTC can reduce transport friction and is especially valuable at the edges of a turn: continuous uplink, turn detection and interruption. But it cannot make a slow LLM, TTS model or avatar renderer fast. Conversely, sufficiently fast models can make request-based transport feel conversational for use cases that do not require full duplex.

This is why architecture should be chosen from the required interaction model, not from the assumption that “real-time AI” automatically means WebRTC.

State does not require a stateful media connection

Another common assumption is that a persistent experience needs a persistent network connection. Those are separate concerns.

An interactive experience can keep durable state on the server: conversation history, character state, scores, stats, current scene, inventory, objectives or tool results. Each HTTP turn can reference the same session state even though the media connection itself is short-lived.

This distinction is particularly useful for multi-scene experiences. The user may spend time reading feedback, navigating a scene or interacting with the environment without needing an AI media stream at all. When the next conversational turn happens, the backend simply resumes from the stored experience state.

The browser can be more than a video player

Photorealistic avatar systems often stream a rendered video feed to the user. That makes real-time media transport central to the product.

Liforma takes a different approach. The browser is an active runtime for the experience. It can render characters, play generated speech and animation, display scenes and 3D backdrops, apply environmental effects and manage interaction UI.

That allows the network to carry the information needed to produce the experience rather than necessarily carrying a continuous rendered video call.

It is one reason non-photorealistic and browser-native characters can have an economic advantage: the client can perform more of the presentation work locally.

A better rule: pay for capabilities you actually need

WebRTC is not legacy technology. It is mature technology solving a difficult problem extremely well. The mistake is using it by default for products that do not have that problem.

The same applies in the opposite direction. HTTP should not be chosen merely because it is simpler or cheaper if the product needs continuous real-time media.

A useful architecture decision starts with the experience:

• Does the user need to interrupt naturally at any time?
• Do both sides need to speak simultaneously?
• Is microphone or video input continuously meaningful?
• How much of a typical session is actual inference versus silence and playback?
• Can generated speech and animation be streamed quickly enough to feel responsive?
• Does the browser already own most of the presentation layer?

If the answers point toward a call, use a call architecture. If they point toward structured turns, a request architecture may be the better abstraction.

Our thesis at Liforma

We think a large class of embodied-AI products have inherited a call architecture from the first generation of voice agents even though their actual interaction model is closer to an interactive application.

As model latency falls, that distinction becomes increasingly important. The user can still experience an intelligent character that listens, thinks, speaks and animates in real time without requiring every second of the experience to be represented by a continuously open AI media session.

That is particularly important when the goal is not merely a one-to-one voice assistant, but multi-character, multi-scene experiences that people might use for 20, 30 or 60 minutes at a time.

The result is a different optimisation target: keep the models warm, not necessarily the connection.