Introduction

When developers ask whether they should use WebRTC “directly” or a higher-level stack like LiveKit for realtime avatars, the real question is usually: do you want to spend your time on media plumbing, or on avatar behavior and product logic?

For a realtime real-estate avatar, the hard parts are not just getting audio and video to flow. You also need low-latency turn-taking, lip sync that stays believable under jitter, a clean way to bridge speech input to generated speech, and a deployment model that does not turn every browser tab into a security review. By the end of this post, you should be able to choose the right stack for your use case, understand where the complexity actually lives, and know how to wire a Protoface avatar into a voice or web experience without overbuilding the backend.

WebRTC is the transport; LiveKit is the product layer

Start with the architecture distinction, because a lot of confusion comes from treating WebRTC and LiveKit as peers. They are not.

WebRTC is the underlying real-time media transport: peer-to-peer or server-assisted audio/video with congestion control, NAT traversal, jitter buffering, and codec negotiation. If you “use WebRTC directly,” you are generally building signaling, room management, media track orchestration, reconnection logic, and observability yourself. That can be fine for a small, tightly controlled application. It becomes expensive when you need production-grade behavior across browsers, mobile networks, and long-lived sessions.

LiveKit sits above that layer. It gives you a room model, SFU-based media routing, SDKs, permissions, and an agents framework for connecting AI systems into live audio/video flows. In practice, LiveKit is what you choose when you want a robust realtime media substrate without implementing the whole stack yourself. For avatars, that matters because the avatar is usually only one participant in a broader conversation flow: the user talks, your agent reasons, TTS produces audio, and the avatar must stay in sync with that audio while remaining responsive to interruptions and turn changes.

So the stack question is not really “WebRTC or LiveKit?” It is “How much media infrastructure do I want to own?” For most product teams, especially if the app already has a voice agent, the answer is “as little as possible.”

What realtime avatars need beyond basic video

A talking avatar is not a static video stream. It is a realtime rendering problem glued to a speech pipeline.

At minimum, you need:

• Audio-driven animation: the mouth shape must track the actual phonemes or visemes being spoken.

• Low end-to-end latency: if audio arrives too late, the face moves after the words, which reads as broken.

• Interruptibility: when the user speaks over the agent, the avatar should stop or change state quickly.

• Session lifecycle management: create, resume, tear down, and rate-limit sessions predictably.

• Secure browser integration: especially for customer-facing sites, where API keys should never be exposed in client-side code.

This is where a direct WebRTC implementation often starts to fray. WebRTC gets the media packets across the wire, but it does not tell you how to turn a streamed TTS response into a stable talking face, or how to manage one avatar session per call, or how to keep the browser integration secure. Those are application concerns.

LiveKit helps by giving you the event model and room semantics that voice agents need. But if you still need to build the avatar renderer, session control plane, and browser delivery path from scratch, you are only partially done. That is the gap a dedicated avatar API fills.

Where WebRTC direct makes sense, and where it does not

If you are building a highly specialized in-browser experience and already own your signaling, infrastructure, and media lifecycle, direct WebRTC can be justified. For example:

• You need a one-off custom peer connection topology.

• You control both endpoints and do not need a general-purpose room model.

• You are optimizing for a very narrow network or device profile.

But for realtime real-estate avatars, direct WebRTC is usually the wrong level of abstraction. The more realistic product shape is a voice agent that answers property questions, adapts to user intent, and presents a face. That means the media transport should be boring. The interesting work is in latency budgeting, prompt design, and session orchestration.

Here is the practical trade-off:

• Direct WebRTC: maximum control, maximum integration cost.

• LiveKit: strong media and agent primitives, moderate integration cost.

• Avatar service on top of LiveKit or web embeds: fastest path to a usable product, least media work.

If your team is two engineers trying to ship a real estate assistant, “maximum control” is usually just deferred complexity.

How the LiveKit agent path looks in practice

The cleanest LiveKit-based integration is to drop the avatar into a voice agent so the agent gains a synchronized talking video face. In the Protoface ecosystem, that is what the LiveKit Agents plugin is for. It lets you attach avatar rendering to an agent flow rather than inventing a parallel media pipeline.

The implementation details depend on your agent framework, but the shape is straightforward: your voice agent handles turn-taking and speech, and the avatar follows the audio stream. A minimal setup usually looks like this in Python:

from livekit import agents

await avatar.start(ctx)

from livekit import agents

await avatar.start(ctx)

from livekit import agents

await avatar.start(ctx)

The important bit is not the exact method names; it is the integration boundary. Let LiveKit handle room transport and agent connectivity, and let the avatar layer handle the visual representation. That separation tends to keep your codebase sane.

If you want examples or the plugin itself, the relevant repository is the LiveKit plugin package on GitHub, and the installation path is published on PyPI. The docs and quickstarts are the best place to confirm the current config shape before you wire it into production.

How Protoface fits without leaking browser secrets

For customer-facing web apps, the easiest way to get a realtime avatar onto a site is often not to expose any media credentials in the browser at all. That is where customer-managed iframe embeds are useful. The parent page can host the experience, while the avatar session, voice settings, and per-embed constraints live on the server side.

The server-side control plane is exposed through the REST API and Python SDK. A typical workflow is:

1. Create or configure an avatar.

2. Create a realtime session from your backend.

3. Pass the session into the browser experience, or render via a managed embed.

Example REST call from a backend service:

curl -X POST https://api.protoface.com/v1/sessions \
}'

curl -X POST https://api.protoface.com/v1/sessions \
}'

curl -X POST https://api.protoface.com/v1/sessions \
}'

And the same idea in Python, using the SDK:

from protoface import Client

)

from protoface import Client

)

from protoface import Client

)

The exact fields depend on the API version and your avatar/session configuration, so treat this as illustrative rather than copy-paste complete. The useful part is the pattern: create sessions server-side, keep API keys out of the browser, and enforce policy centrally. That matters a lot if you are embedding the avatar on a real estate listing page or inside a lead-gen funnel.

Choosing the right stack for a real estate avatar

For real estate, the avatar is usually there to improve conversion and answer repeated questions: price ranges, neighborhood features, scheduling, HOA rules, or whether a floor plan is still available. That makes reliability and deployment simplicity more important than low-level media control.

My default recommendation is:

• Use LiveKit if you already have a voice agent and need a robust real-time media layer.

• Avoid direct WebRTC unless you have a very specific media requirement and are prepared to own the full signaling and session stack.

• Use a managed avatar API for the face itself, especially if you want secure browser embeds or a backend-managed session lifecycle.

In other words: build the agent, not the transport. The transport should disappear into the background. If it does not, it is probably too low-level for your product phase.

Common gotchas

A few issues show up repeatedly in production:

• Latency creep: every extra hop between ASR, LLM, TTS, and avatar rendering adds delay. Measure end-to-end, not just model latency.

• Turn-taking bugs: if the user interrupts, make sure the agent and avatar both stop promptly.

• Network variability: mobile users and hotel Wi-Fi expose weaknesses in ad hoc WebRTC setups quickly.

• Secret handling: never ship API keys to the browser. Use backend session creation or a managed iframe approach.

• State drift: the avatar, audio, and conversation state must be tied to the same session identity or you will get mismatches after reconnects.

If you are evaluating the stack for a new build, prototype the full path early: one user, one agent, one avatar, one browser session. That will tell you more than a diagram ever will.

Conclusion

WebRTC is the plumbing. LiveKit is the operational media layer. A realtime avatar service is the piece that turns speech into a controllable, product-ready face. For a real estate assistant in Rust or any other backend stack, the best choice is usually the one that minimizes media complexity and maximizes control over session lifecycle, security, and latency.

If you want to build this without owning the whole avatar pipeline, start with the docs at docs.protoface.com, and use the integration surface that matches your architecture: the LiveKit plugin for voice agents, the REST API or Python SDK for backend-controlled sessions, or an iframe embed for browser delivery with no exposed API key. If you need a quick path from concept to working demo, the quickstarts linked from the repo are the fastest way to validate the end-to-end flow.