Why Wetel Chose LiveKit

Checked on 2026-10-19. Vendors change; verify before deciding.

Every vendor fact on this page was read on that vendor’s own public page on 2026-10-19 and is linked. Where we could only find a fact on a secondary page, the page says “according to” and names the source. Where we could not find something, we say “not found on the pages we checked”, which is not the same as “not supported”. Prices are quoted as published, with their unit, and are not totals for any workload. We did not benchmark any competitor, so this page makes no claim that any platform is faster or slower than another.

This page explains one decision: why Wetel Telephony is built on LiveKit. It is our reasoning for our requirements, not a ranking. A team with different requirements can reasonably choose differently.

Before and after LiveKit: the avatar SDK versus a live call

If you already use Wetel’s browser voice chat (the <vai-avatar> embed, the demo page and the SDK documented under Avatar and 3D rendering and Voice interface), the natural question is what LiveKit changes. The two coexist. Neither replaces the other. This is how each works, from Wetel’s own SDK source and API.

Before: the avatar SDK (sdkStart, then sdkSendMessage). The browser does the audio work. A voice-activity model (Silero) runs in the page. When the person finishes speaking, the page records that utterance as one audio clip and uploads it to the avatar service’s /stt endpoint. The text goes to the agent through the sdkSendMessage mutation, the reply comes back as text events on the sessionEvents subscription, and /tts turns it into speech that a 3D avatar (or a hosted video avatar) plays with lip-sync. It is turn-based: speech is captured whole, then transcribed, then answered, then spoken. The page pauses its voice detector while the avatar speaks, because speaker sound leaking into the microphone causes false interruptions, so a real interruption needs an explicit push-to-talk gate (setVoiceActive) or a manual handleBargeIn(); headphones are recommended. The page fills waiting time with a short spoken filler phrase.

After: a live call (sdkStartVoiceCall, LiveKit WebRTC). The audio work moves to a server-side voice worker in a LiveKit room. The caller’s audio streams continuously to the worker (WebRTC, with the browser’s echo cancellation), which runs voice-activity and end-of-turn detection and streaming speech recognition. The agent’s workflow answers, and streaming speech synthesis speaks the reply sentence by sentence. Because the worker hears the caller while it speaks, interruption is automatic with no push-to-talk gate, the agent can speak first, and its history is trimmed to what the caller actually heard. Any client that can join a LiveKit room can be the caller: a browser page or a mobile app today, and later WhatsApp calls (the connector) and phone calls (SIP), both planned. It is the same agent, workflow, session and memory model, and API key as chat.

	Avatar SDK (<vai-avatar>)	Live call (sdkStartVoiceCall)
Where audio is processed	In the caller’s browser page, plus the avatar service	On a server-side voice worker in a LiveKit room
How speech reaches the agent	One recorded clip per turn, uploaded for speech-to-text, then sent as text with sdkSendMessage	Continuous audio stream, streaming speech recognition, text to the workflow per turn
Interruption	Needs a push-to-talk gate or a manual handleBargeIn(); headphones recommended	Automatic; history trimmed to what the caller heard
Who speaks first	Page-driven	The agent, with an AI disclosure
Clients and channels	A web component in a browser page; no phone, WhatsApp or app-call path	Browser or app today; WhatsApp and phone planned, not available
Avatar and lip-sync	3D avatar with lip-sync, or a hosted video avatar	Audio only today
What you run	A ready-made embed; no media server	A voice worker (Wetel runs it for test sessions), a media-server dependency
Measured speed	Not compared	Not compared; about 2.6 to 3.7 s as heard (see below)
Status	Documented as live	On request on staging, not in production

We have not benchmarked the two paths against each other, so this page does not say the live call is faster. What follows from the architecture is capability: streaming, full duplex, server-side processing and channel reach.

Which to pick: the SDK when you want an on-page 3D avatar embed; the live call when you need a natural, interruptible conversation, an app, WhatsApp or the phone.

What we needed

1. Our own agent workflow as the brain. Rules, guardrails, hard-locked response nodes, tools and memory live in the agent’s published workflow. A voice platform must let us supply that step instead of a vendor-hosted prompt, and must let us replace the speech and language models per agent.
2. WhatsApp calling. Meta’s Calling API carries media over WebRTC (ICE, DTLS and SRTP) or, optionally, SIP. Its page does not describe an audio stream or fork, so the business has to terminate the media itself or use a platform that does.
3. An open-source core and a way out. A self-hostable media server and agents framework, plus a managed cloud.
4. Real-time quality features. Voice activity detection, end-of-turn detection, interruption (barge-in), history that reflects what the caller actually heard, and per-turn metrics.
5. Tenant isolation. A hard boundary between customers’ voice traffic, and explicit control over which agent joins which call.
6. A path to ordinary phone numbers over SIP, later.

How we decided

flowchart TD
  A[Real-time voice agent wanted] --> B{Must our own workflow be the brain?}
  B -- No, a vendor-hosted prompt is fine --> C[Managed voice-agent platforms or speech-to-speech APIs]
  B -- Yes --> D{Must we terminate WhatsApp calls ourselves?}
  D -- No --> E[Custom-LLM hooks on managed platforms, or a carrier plus WebSocket]
  D -- Yes --> F{Want an open-source core and an exit path?}
  F -- No --> G[Managed platforms that document WhatsApp calling]
  F -- Yes --> H[LiveKit or Pipecat]
  H --> I{Native WhatsApp connector, project isolation, one vendor for media and agents?}
  I -- Yes --> J[LiveKit, our choice]
  I -- Code-first Python and a different hosting model --> K[Pipecat with Daily or self-hosted]

The branches are our own simplification. Several platforms appear on more than one path; the table below shows what each documents.

Comparison at a glance

Cells say what the vendor’s own pages state on 2026-10-19. “Not found” means we did not find it on the pages we read. Sources for each row are in the last column and detailed in the sections below.

Option	Own brain (custom LLM hook)	WhatsApp calling	Open source	Phone numbers and SIP	Published price (see vendor for the rest)	Sources
LiveKit (Cloud and self-hosted)	Yes: override llm_node / llmNode in the Agents framework	Connector, inbound and outbound; LiveKit Cloud only	Server and Agents framework Apache-2.0; some models and connectors are Cloud-only	SIP trunks, tested providers; LiveKit numbers US-only, inbound-only	Ship plan from $50/mo; $0.01 per agent-session minute over 5,000	Pricing, nodes, WhatsApp, numbers, server, agents
Pipecat (with Daily or self-hosted)	Python framework you program	WhatsApp support documented, inbound only	Pipecat is BSD-2-Clause	Serializers for Twilio, Plivo, Telnyx, Vonage, Exotel, Genesys; Daily SIP/PSTN	Pipecat Cloud agent-1x $0.01 per active minute; Daily PSTN $0.018 per minute	Repo, WhatsApp, Cloud pricing
Vapi	Yes: Custom LLM option, your server URL	Not found	Not checked	Free Vapi numbers US-only, inbound-only; import from Twilio, Telnyx, DIDWW; SIP	$0.05 per minute Vapi hosting, provider costs separate	Pricing, phone calling, custom LLM
Retell AI	Yes: custom LLM over a per-call WebSocket	Not found	Not checked	SIP trunking, dial to SIP URI; trunk guides for Twilio, Telnyx, Vonage	$0.055 per minute voice infrastructure, plus TTS and LLM	Pricing, custom LLM, telephony
Twilio	ConversationRelay sends caller text to your WebSocket; Media Streams gives raw audio	WhatsApp Business Calling, generally available; cannot bridge to PSTN	Not checked	Carrier: numbers, SIP, PSTN	ConversationRelay $0.07 per minute (US page); US local inbound $0.0085 per minute	ConversationRelay, Media Streams, WhatsApp calling, voice pricing
ElevenLabs Agents	Yes: custom LLM server, OpenAI-compatible	Inbound and outbound calls and messages	Not checked	SIP trunking and Twilio listed for transfers; numbers not checked	$0.08 per additional call minute; LLM cost billed separately	Pricing, custom LLM, WhatsApp
OpenAI Realtime API	Model-hosted: you set instructions, tools, voice	Not mentioned on the SIP page	Not checked	Inbound SIP trunk; outbound via the newer Live API	Audio tokens, gpt-realtime-2.1: $32 input, $64 output per 1M	SIP guide, pricing
Google Gemini Live API	Model-hosted, with function calling	Not mentioned	Not checked	No SIP on the page; partner Voximplant listed for calls	See vendor	Live API
Deepgram Voice Agent API	Yes: OpenAI-compatible endpoint for the LLM	Not mentioned	Not checked	Phone networks for inbound and outbound	See vendor	Overview, LLM models
Telnyx AI Assistants	Custom LLM, according to Telnyx’s release note	Not found in assistant docs	Not checked	Carrier: SIP trunking from $0.0032 per minute inbound	$0.05 per minute voice engine; LLM and telephony extra	Pricing, custom LLM
Agora Conversational AI	Custom LLM, OpenAI-compatible, according to Agora’s docs	Not found	Not checked	Agent Studio: inbound and outbound via Elastic SIP Trunk	Not on the page we read	Product overview, custom LLM
Amazon Connect Customer, Chime SDK	Contact-center product; Chime SDK is a set of communications components	WhatsApp messaging documented; voice calling not found	Not checked	Phone numbers provisioned by administrators	Pay for use, see vendor	Connect, Chime SDK, WhatsApp messaging
Raw WebRTC or WebSocket, built by us	Whatever we build	Meta’s Calling API: WebRTC (ICE, DTLS, SRTP), Opus supported, or SIP	Our code	Through a carrier	Engineering time	Meta Calling API

Vonage is not in the table because the only developer page we read for it (AI Studio) did not cover voice agents or WhatsApp calling. According to Vonage’s own WhatsApp page, businesses can enable WhatsApp voice calls connected through the Vonage Voice API; we did not read the technical guide.

What each option documents

LiveKit

• Brain. The Agents framework documents overriding llm_node (llmNode in Node.js) to supply custom LLM logic, alongside stt_node and tts_node.
• Turn-taking. The turns documentation describes a turn-detector model, VAD, interruption detection, false-interruption handling (the agent can resume from where it stopped) and truncation of history to what the user heard. Metrics include end_of_utterance_delay, LLM ttft, TTS ttfb and a per-message e2e_latency.
• Isolation and dispatch. A Cloud project has its own URL, API key and secret, and LiveKit recommends one per environment. Explicit dispatch puts agent entries in the participant token’s room configuration; LiveKit calls it the recommended approach and says token dispatch happens only when the room is first created.
• Telephony. SIP trunks and dispatch rules connect a provider to rooms; tested providers listed are Twilio, Telnyx, Exotel, Plivo, Wavix, Sinch and didlogic; outbound uses CreateSIPParticipant. LiveKit Phone Numbers are US-only and inbound-only, with one free US local number on every Cloud plan.
• WhatsApp. The WhatsApp connector takes the SDP offer from Meta’s webhook through AcceptWhatsAppCall, puts the call in a room as a CONNECTOR participant and can dispatch an agent. Inbound and outbound are documented; outbound is “not available in all regions”. Requirements include a Meta developer account, a Cloud API token and call permissions.
• Open source, and what is not. The server and the Agents framework are Apache-2.0. The same repository says the turn-detection models use the “LiveKit Model License”. The docs state that connectors are available in LiveKit Cloud only (agents can run anywhere), and that adaptive interruption handling is available for agents deployed to LiveKit Cloud, with 40,000 free inference requests a month for local development; otherwise the framework relies on VAD. The full audio turn-detector model is served on LiveKit Inference; a smaller v1-mini runs locally on CPU.
• Price. Published Cloud plans, checked 2026-10-19:

Plan	Monthly	Agent-session minutes included	Overage	Concurrent agent sessions
Build	$0	1,000	none listed	5
Ship	starting at $50	5,000	$0.01 per minute	20
Scale	starting at $500	50,000	$0.01 per minute	up to 600
Enterprise	custom	custom	custom	custom

Connector minutes (WhatsApp and Twilio) are listed at $0.004 per minute on Ship and $0.003 per minute on Scale, with 5, 20 and 100 concurrent calls on Build, Ship and Scale. Third-party SIP minutes are listed at the same two rates after the included minutes.

Pipecat, Daily and Pipecat Cloud

Pipecat is an open-source Python framework (BSD-2-Clause), maintained by Daily and the community, with Daily, LiveKit and WebSocket transports and telephony serializers. Its WhatsApp page documents inbound voice calls only, through SmallWebRTCTransport. Pipecat Cloud lists agent hosting from $0.01 per active minute (agent-1x), Daily PSTN at $0.018 per minute and Daily SIP at $0.003 to $0.02 per minute. On our criteria it is the closest alternative to our choice: also open source, also code-first. We did not evaluate Pipecat beyond its documentation.

Managed voice-agent platforms: Vapi, Retell AI, ElevenLabs Agents, Telnyx, Agora

These host the call loop (speech, turn-taking, telephony) and, in most cases, let you point the language-model step at your own server.

• Vapi documents a Custom LLM option and a pricing page with “$0.05/min Vapi hosting” on the pay-as-you-go package; transcriber, model and voice are billed separately at provider cost. Free Vapi numbers are US-only and inbound-only; numbers can be imported from Twilio, Telnyx or DIDWW, or connected over SIP (phone calling).
• Retell AI documents a custom LLM over a per-call WebSocket. The docs add that Retell decides when the agent speaks and may discard a response if the caller keeps talking. The pricing page lists $0.055 per minute for voice infrastructure and shows an example total of $0.11 per minute with its stated components.
• ElevenLabs Agents documents a custom LLM server (OpenAI-compatible), and WhatsApp for messages and for inbound and outbound calls, with caveats: numbers already managed by another provider or active in the WhatsApp Business app are not supported, and an unassigned account rejects inbound calls. Its pricing page lists additional call minutes at $0.08 each, with LLM cost billed separately.
• Telnyx lists a voice engine at $0.05 per minute with telephony and LLM on top. According to Telnyx’s own release note, assistants can use any OpenAI-compatible LLM endpoint.
• Agora says in its overview that Agent Studio supports calls through an Elastic SIP Trunk; according to its custom LLM page, the engine can call an OpenAI-compatible service you host.

Carriers and communications platforms: Twilio, Vonage, Amazon

• Twilio has several layers. ConversationRelay converts speech to text, sends it to your WebSocket, and speaks your reply; its US voice pricing page lists it at $0.07 per minute, with local inbound at $0.0085 per minute. Media Streams gives raw call audio over a WebSocket, including bidirectional. WhatsApp Business Calling is generally available, with inbound calling in all Meta Cloud API countries; the page lists limits including that calls to or from WhatsApp cannot connect to PSTN endpoints.
• Amazon Connect Customer is a contact-center product (docs). We found WhatsApp messaging documented for it, and did not find native WhatsApp voice calling on AWS’s pages. The Chime SDK is described as real-time communications components for apps; we did not evaluate it further.

Speech-to-speech and voice-model APIs: OpenAI, Gemini, Deepgram

• OpenAI Realtime API can accept an incoming SIP call and then drive it with a WebSocket (SIP guide). Accepting a call sets the model, voice, tools and instructions. The page we read does not mention WhatsApp. Published audio token prices for gpt-realtime-2.1 are $32.00 input and $64.00 output per 1M tokens.
• Gemini Live API is a stateful WebSocket API with function calling and barge-in (docs). The page does not mention SIP or WhatsApp and lists Voximplant as a telephony partner. We did not record a price.
• Deepgram Voice Agent API documents a bring-your-own LLM through an OpenAI-compatible endpoint and lists phone-network connectivity (overview). We could not load its pricing page, so we quote no price.

Where the others are better

• Time to a first phone number and a first call. On the managed platforms you can get a hosted agent on a number without running a worker. Vapi offers free US inbound numbers, and Retell, Telnyx and Twilio document SIP trunking or numbers. LiveKit also needs a running agent worker, which Wetel operates.
• Ordinary phone numbers. LiveKit’s own numbers are US-only and inbound-only today. Carriers such as Twilio and Telnyx sell numbers and PSTN access directly and publish per-minute rates; LiveKit’s route to the rest of the world is a SIP trunk from one of them.
• WhatsApp calling in fewer steps. ElevenLabs documents importing a WhatsApp Business account and assigning an agent; Twilio documents a TwiML-based activation. Both avoid the webhook-handling and call-accept code that a LiveKit-based route needs on the side that holds the Meta token.
• Speech-to-speech models. OpenAI’s Realtime API and Gemini Live take audio in and give audio out in one model session, so they have no separate recognition and synthesis hop. We list this as a reason the approach is attractive for lowest latency, not as a measurement: we did not benchmark them. The trade-off is that the model hosts the reasoning, so our workflow would no longer be the brain.
• Vendor-owned voice. Platforms that run their own voice models (ElevenLabs, for example) offer them as part of the product. We have not compared voice quality across vendors, so we make no claim about it.
• A simpler operating model. On a managed platform the vendor runs the call loop; with LiveKit we run the worker ourselves.

What we pay for choosing LiveKit

• We still build and run a lot. The worker app and its operations (a 24/7 service, per-call CPU, capacity planning, deploys that do not drop live calls), streaming speech-provider adapters, the backend path that runs the agent’s workflow per turn, session, identity and tenancy glue, and call controls and disclosure. LiveKit removes media termination, turn-taking and interruption detection, which is the hardest real-time work.
• “Open source” has edges. The server and framework are Apache-2.0, but the WhatsApp connector is Cloud-only and adaptive interruption is a Cloud feature, so a self-hosted exit path gives up those, and the turn-detection models sit under a separate license.
• A new vendor dependency, for media transport and for the agent framework.
• Distance. Our project was offered LiveKit regions nearest-first Hyderabad (India South), Osaka, Tokyo, Dubai, Sydney and Jeddah, with no Singapore region offered; Wetel is in Malaysia, about 3,000 km from Hyderabad. LiveKit’s regions page (region groups last updated 2026-05-14) does list Singapore in its Asia Pacific realtime group, but not as an agent-deployment region (those are us-east, eu-central and ap-south), and region pinning needs the Scale plan or higher. We have not established why our project was not offered it.
• Our measured latency misses our target. See the next section.

What we measured

These are Wetel’s own measurements on 2026-10-18 and 2026-10-19: a laptop in Malaysia, synthetic speech, noise about 0.5 s. A LiveKit Agents (Node) worker with Silero VAD, LiveKit’s turn-detector model, streaming speech recognition, our own brain and streaming speech synthesis ran end to end from a browser.

• Barge-in worked. In a recorded call the agent stopped about 1.2 s after the caller started speaking.
• Reply time from the end of the caller’s speech to the first agent audio was about 2.1 to 2.9 s measured inside the agent and about 2.6 to 3.7 s as the caller heard it. Our target of about 1.5 s was not met.
• Setup note. Node 20 on an Intel Mac needed an onnxruntime override.

We did not benchmark any other platform. These numbers say nothing about whether LiveKit is faster or slower than an alternative.

What would make us switch

• A platform that documents the same things we need (our own brain, WhatsApp calling terminated on our side or by a connector, vendor-flexible speech, tenant isolation) and measures faster in our own test with the same synthetic calls.
• LiveKit changing pricing, regions, licensing or the Cloud-only boundary in a way that breaks our economics or exit path.
• A speech-to-speech model that can run our guardrails and hard-locked responses with the same assurance as our workflow.
• A nearer region becoming available to our project, which would make us re-measure rather than switch.
• Our inability to operate the worker reliably at the call volume pilots reach.

FAQ

Can I use another platform with Wetel agents? Today, Wetel’s voice path is built on LiveKit. The agent’s workflow is platform-independent and could be fronted by another voice layer through its session API, but that is not a supported integration today. See the session start reference for what exists.

Does this mean LiveKit is the best option? No. It is the best fit we found for our requirements. Other platforms are better on other dimensions, listed above.

Is WhatsApp calling available on Wetel? Not today. It is planned and in preparation; see the roadmap.

Is there a Wetel price for voice? Not set yet; see the overview. The vendor prices on this page are third-party prices, not Wetel prices.

Where is the data from? From the linked vendor pages, read on 2026-10-19, and from Wetel’s own measurements. Corrections are welcome.

Try it

Request a test session