Introduction

If you are building a realtime sales avatar in JavaScript, you are usually deciding between two layers of the stack that solve different problems: the transport/runtime that carries audio and video, and the avatar service that turns speech into a lip-synced face. WebRTC is the transport. It gives you low-latency audio/video delivery, NAT traversal, congestion control, and browser-native media APIs. It does not give you an avatar, session orchestration, or a simple way to wire a voice agent to a talking face.

This is where Protoface fits: it is the avatar layer that you can plug into a voice agent or embed in a web app. By the end of this post, you should be able to decide when to build directly on WebRTC, when to use a managed realtime layer like LiveKit, and where a Protoface integration actually saves time without hiding the important details.

What WebRTC gives you, and what it does not

WebRTC is the right mental model for realtime media delivery in the browser. In practice, that means:

• Capture microphone and camera input with getUserMedia().

• Negotiate a peer connection with SDP and ICE.

• Send audio/video tracks over a low-latency, congestion-controlled channel.

• Render remote media streams in the page with minimal delay.

For a sales avatar, this matters because lip sync is only as good as the end-to-end latency budget. If the audio arrives late, the face will look wrong even if the animation itself is perfect. WebRTC is the transport that keeps latency low enough to make realtime interaction feel natural.

But WebRTC is only the media pipe. You still need to solve:

• session setup and teardown,

• identity and auth,

• reconnection and media renegotiation,

• audio mixing or voice-agent orchestration,

• and the actual avatar rendering pipeline.

If you try to build all of that from raw browser WebRTC APIs, you quickly end up writing a backend media service, a signaling layer, and a set of recovery paths that are much less interesting than the product you were trying to ship.

When LiveKit is the right abstraction

LiveKit sits above raw WebRTC and gives you a production-oriented realtime room model. For JavaScript developers, that usually means less code around signaling and media plumbing, and more time spent on the application logic: who joins, what role they have, and which tracks are published or subscribed.

For sales avatars, LiveKit is often the cleanest choice when you already have a voice agent or a multi-party realtime system. The agent can speak over audio, and the avatar can subscribe to that same audio stream and render a synchronized talking face. The key point is that LiveKit is not replacing WebRTC; it is packaging WebRTC into a system you can operate more sanely.

A practical decision rule:

• Use raw WebRTC only if you need full control over transport and signaling, and you are prepared to own the complexity.

• Use LiveKit if you want a realtime room abstraction, client/server SDKs, and easier integration with voice agents.

• Use an avatar service if your problem is “make this voice agent look like a real talking face,” not “invent a media stack.”

JavaScript implementation shape: publish audio, subscribe to the face

In a sales avatar flow, the browser usually does one of two things:

1. capture the user’s mic and send it into a realtime room, or

2. receive synthesized agent audio and render the avatar video alongside it.

With a managed room layer, the browser code stays relatively small. Pseudocode looks like this:

import { Room, RoomEvent } from 'livekit-client';

});

import { Room, RoomEvent } from 'livekit-client';

});

import { Room, RoomEvent } from 'livekit-client';

});

The important thing here is not the exact API surface; it is the media flow. The avatar should be treated like a realtime participant whose video track is driven by the agent’s speech stream. That is what keeps the experience coherent. If you instead try to “play audio in the browser and animate a face separately,” drift and lag become very visible.

Also, do not confuse transport latency with model latency. A fast WebRTC path can still feel slow if the speech-to-text, LLM, or TTS pipeline is overloaded. In sales flows, the user notices the worst stage. The transport can be perfect and the product still feel sluggish if the agent response path is slow.

Where avatar integration gets tricky in practice

The hard parts are usually not rendering a video tag. They are session boundaries and trust boundaries.

For example, if you are embedding a sales avatar on a marketing site, you may not want any browser-visible API key at all. In that case, a direct browser-to-backend integration is the wrong shape. You want an embedded runtime that can enforce origin allowlists, limit session duration, and isolate customer-specific configuration from the public client.

Another common gotcha is synchronization. A sales avatar needs to look like it is speaking the exact audio the user hears. That means:

• the same session should own both the audio source and the video face,

• the avatar renderer should be driven by the speech timeline, not a separate timer,

• and reconnect behavior should preserve state where possible, or at least fail cleanly.

If you are building a browser-first demo, it is easy to get fooled by a local setup with minimal latency. Production conditions are harsher: mobile networks, tab throttling, NAT weirdness, and variable TTS timing. That is where the abstraction layer matters more than the initial happy path.

How Protoface fits this stack

The useful mental model is that LiveKit or WebRTC handles the media path, while Protoface provides the avatar and session side of the problem. If you are already using a LiveKit-based voice agent, the LiveKit plugin is the fastest way to give the agent a synchronized face. The plugin lives in the Protoface GitHub org and is designed to drop into the agent pipeline rather than force you to rewrite it. See the plugin repository for examples: github.com/protoface-ai/protoface-quickstart-openai-realtime is a good starting point for understanding the wiring around realtime voice agents.

At a code level, the integration pattern is straightforward: create or reference an avatar, attach it to the voice session, then let the runtime keep the face synchronized with the agent’s speech. Exact fields and parameters depend on the API shape in the docs, but the flow is roughly:

# illustrative only; check docs for exact fields

)

# illustrative only; check docs for exact fields

)

# illustrative only; check docs for exact fields

)

If you want to manage sessions directly from a backend, the REST API is the right surface. That keeps API keys off the browser and makes it easier to enforce your own business rules before you create a session. The docs at docs.protoface.com are the place to verify request shapes and session lifecycle details.

For teams already committed to Python on the agent side, the Python SDK is also a clean fit. It keeps avatar/session orchestration in application code instead of scattering it across browser logic and ad hoc server routes.

Choosing the right architecture for a sales avatar

If your use case is a simple embedded sales concierge on a website, you should optimize for deployment speed and security. A customer-managed iframe embed is often the least risky option because the browser never sees your backend credentials, and the embedded runtime can enforce origin allowlists and session limits.

If your use case is a voice agent that already runs in LiveKit, do not rebuild the media path. Keep LiveKit for realtime transport and attach the avatar layer where it belongs. That gives you predictable media behavior and lets you focus on agent behavior, not RTC plumbing.

If your use case is a custom JavaScript app where you own the whole stack, raw WebRTC is still viable, but only if you genuinely need the control. Most teams do not need to own ICE retries, signaling edge cases, or media-session bookkeeping for a sales avatar.

Conclusion

For realtime sales avatars, the choice is usually not “LiveKit or WebRTC” in isolation. WebRTC is the transport primitive. LiveKit packages that transport into something you can operate. Protoface supplies the avatar/session layer that turns a voice agent into a talking face.

The practical recommendation is simple: start with the highest-level abstraction that still fits your requirements. If you need browser-only embedding, look at the iframe approach. If you already have a LiveKit voice agent, use the LiveKit plugin. If you need backend-controlled session creation, use the REST API or Python SDK. The docs at docs.protoface.com and the quickstarts in the Protoface GitHub org are the fastest way to validate the exact integration for your stack.