Introduction

If you are building a plain HTML “virtual receptionist” UI, you usually need three things to happen at once: the browser needs to capture microphone input, a backend or agent needs to process that audio in real time, and the UI needs to render the response quickly enough to feel conversational. The first design decision that matters is transport: do you connect the browser to your service with WebRTC or with WebSocket?

The short version: WebRTC is usually the right choice for live audio/video streaming and low-latency conversational media. WebSocket is usually the right choice for control messages, transcripts, state updates, and simple browser-to-server signaling. For a receptionist-style UI, the best architecture is often not “WebRTC or WebSocket,” but “WebRTC for media, WebSocket for coordination.” By the end of this post, you should be able to choose the right transport for each part of the system and avoid a few common implementation mistakes.

What the browser actually needs to do

A receptionist UI looks simple from the outside: a button, a microphone indicator, maybe a talking avatar and some text. Under the hood, the browser is handling a real-time media pipeline:

• Capture audio from the microphone with low buffering.

• Send that audio to the server with minimal added latency.

• Receive audio and/or video back without stutter.

• Keep UI state in sync with the conversation lifecycle.

Those requirements favor media-oriented transports. WebRTC was designed for interactive media and includes congestion control, jitter buffering, packet loss handling, NAT traversal, and audio/video synchronization. WebSocket is just a bidirectional message channel over TCP. That makes it great for application data, but it is not a media transport in the same sense.

WebRTC for the media path

Use WebRTC when the browser is sending or receiving live audio/video frames and the user expects a conversational feel. For a receptionist, this is the path for microphone audio up to the agent and avatar video back down to the browser.

The practical advantages are:

• Lower end-to-end latency than building media over WebSocket.

• Better behavior on imperfect networks, especially for live audio.

• Native browser support for microphone capture and playback.

• Media sync if you need a talking face that matches the voice.

The trade-off is complexity. WebRTC usually needs signaling, session setup, ICE candidate exchange, and careful lifecycle handling. If you are just trying to get a receptionist UI on the page quickly, WebRTC may feel like a lot of ceremony.

WebSocket for control, state, and fallback-friendly messaging

Use WebSocket when the browser needs to exchange small, structured messages with your app: user actions, partial transcripts, state changes, agent events, and UI hints. For example, a receptionist UI might send “start session,” “mute microphone,” or “user clicked schedule callback,” and receive “agent is speaking,” “transcript updated,” or “handoff to human requested.”

WebSocket is also easier to reason about when you only need request/response-like behavior and do not actually need media in both directions. It is a good fit for:

• Signaling messages for a WebRTC session.

• Conversation state updates.

• Business events and notifications.

• Simple fallback paths when media is not required.

The important limitation is that WebSocket is not a substitute for a proper real-time media stack. You can push PCM frames over a socket, but you are then reinventing buffering, jitter handling, pacing, and playback synchronization. That tends to work for prototypes and degrade quickly in production.

Choosing between them for a plain HTML receptionist UI

If the UI is only a thin browser front end, the cleanest split is usually:

1. WebRTC for microphone input and avatar audio/video output.

2. WebSocket for signaling, UI events, session status, and transcript updates.

That split lets the browser stay simple while still delivering a responsive experience. The browser does not need to know anything about model inference, voice pipeline internals, lip sync, or avatar generation. It just opens a realtime media session and listens for a small set of control messages.

Where teams get into trouble is trying to do everything over one channel because it seems simpler. Common failure modes:

• Audio over WebSocket leading to latency spikes and awkward playback.

• Overloading WebRTC data channels with application logic that belongs in normal API calls.

• Putting secrets in the browser when the client should only see short-lived session data.

• Skipping session lifecycle, so reconnects become ambiguous and state leaks across calls.

A good mental model is that the browser should be thin, the transport should be specialized, and the conversation state should live somewhere authoritative on the server side.

Minimal HTML implementation shape

For a plain HTML UI, your page typically has one of two shapes:

1. A <video> or <audio> element attached to a WebRTC remote track, plus a small control panel.

2. A WebSocket client that mirrors application state while another component handles media.

Here is a bare-bones browser-side pattern for the control plane:

<script>
</script>

<script>
</script>

<script>
</script>

And here is the kind of shape you want for media signaling with WebRTC:

const pc = new RTCPeerConnection();

const pc = new RTCPeerConnection();

const pc = new RTCPeerConnection();

The browser code stays straightforward if you keep the responsibilities separated. The signaling channel negotiates the session; the media channel carries the live conversation.

Where Protoface fits in this architecture

This is exactly the kind of split Protoface is meant to support. If you are embedding a talking avatar into an agent or receptionist flow, you do not want to build lip-sync, avatar session management, and media plumbing from scratch unless you have to. In practice, you can keep your browser implementation thin and let the backend handle the avatar session and realtime media integration.

If you are using a voice-agent stack, the LiveKit path is particularly relevant. The quickstart examples show the general shape of a realtime agent integration, and the LiveKit plugin drops an avatar into the agent so the user sees a synchronized face while the audio conversation runs. That is the right abstraction level for a receptionist UI: your frontend focuses on UX and session state, while the avatar/media layer stays on the server side.

For browser-only embeds, the customer-managed iframe model is even simpler conceptually: the avatar session is isolated, no backend code is required in the parent page, and you avoid exposing API keys in the browser. That makes it a good fit when the “virtual receptionist” needs to live inside a plain marketing page or product UI without turning the frontend into an application server.

If you want the exact API shapes, session fields, or authentication details, use the public docs rather than guessing: docs.protoface.com. For programmatic control, the REST API and Python SDK are the main surfaces; for agent integration, the plugin is the useful starting point.

curl -X POST https://api.protoface.com/v1/sessions \
-d '{"avatar_id":"avatar_123","voice":"alloy"}'

curl -X POST https://api.protoface.com/v1/sessions \
-d '{"avatar_id":"avatar_123","voice":"alloy"}'

curl -X POST https://api.protoface.com/v1/sessions \
-d '{"avatar_id":"avatar_123","voice":"alloy"}'

That example is intentionally minimal. The exact request body depends on the session type and fields documented in the API reference, but the pattern is the same: create a server-side session, hand the browser only what it needs, and keep credentials off the client.

WebRTC vs WebSocket in practice

If you still want a direct rule of thumb, use this:

• Use WebRTC for audio/video that must feel interactive.

• Use WebSocket for app state and coordination around that media.

• Do not stream conversational media over WebSocket unless you have a very specific reason and are prepared to handle the transport problems yourself.

For a plain HTML virtual receptionist UI, that usually means the browser establishes a realtime media session, then uses a lightweight control channel to reflect state in the page. The result is lower latency, simpler UX code, and fewer surprises when users are on real networks instead of localhost.

Conclusion

For realtime receptionist experiences, WebRTC and WebSocket are complementary, not interchangeable. WebRTC is the right transport for live media; WebSocket is the right transport for coordination and state. If you keep that boundary clean, your HTML UI stays small, your latency stays low, and your agent architecture stays maintainable.

If you are building this with an avatar-backed voice agent, start with the docs, choose the narrowest integration surface that fits your app, and treat the browser as a thin client. The quickest way to move forward is to read the integration examples in the docs and then adapt the session flow to your own frontend.