Pick your phone route before you pick a voice AI framework

Here's a view we hold firmly: work out how calls will reach your agent before you choose the framework. SIP trunking is the reliable path for production phone traffic, and WebRTC belongs to calls that start in a browser. That one choice also decides, quietly, whether a caller who asks for a human can ever get one.

Pipelines and models matter, of course. But what bites teams a month in is usually the phone side, so that's the lens here.

The transfer that isn't there

Pipecat is a lovely piece of engineering. A call is a pipeline of processors passing frames along, and the quickstart chains transport input, Deepgram speech-to-text, Silero voice activity detection, an OpenAI model, Cartesia text-to-speech and transport output. The transport at each end is swappable, so the same agent logic can answer a browser over WebRTC or a phone call over a carrier WebSocket. If it's Twilio, set the input and output sample rates to 8000, since Twilio streams 8 kHz mono audio and you don't want to resample.

Here's the catch. Pipecat's telephony guide lists its WebSocket integrations for Twilio, Telnyx, Plivo and Exotel with "No advanced call center features like transfers or reconnects". The carrier WebSocket is the fastest way to get a bot on a phone number, and it's also a route where "let me put you through to someone" has nowhere to go.

Transfers in Pipecat come from Daily PSTN or a SIP connection, which Pipecat lists for transfers, forwarding and multi-party calls. None of that is hard to set up. It's just much nicer to choose it on day one than to discover it after the demo, when someone in support asks how a caller reaches them.

LiveKit starts from SIP

LiveKit Agents comes at it from the other end. Your agent is a participant in a room on the LiveKit media server, and phone callers join that room over SIP. An inbound trunk takes calls from your carrier and a dispatch rule sends each caller, and your agent, into a room. Dialling out is an outbound trunk plus a SIP participant.

Transfers are native here: cold transfers over SIP REFER, plus agent-assisted transfers. LiveKit Cloud also sells US local and toll-free numbers, so you can skip a separate carrier if all your callers are in the US.

Self-hosting is where the phone side gets heavier. LiveKit says plainly that "the SIP service needs to be deployed separately", and its SIP signalling port and media port range have to be open to the internet. Budget a bit of ops time for that.

LiveKit deserves real credit on testing, too. The Python starter ships simulations that play whole conversations against your agent, plus a debugger that steps through one text turn at a time.

TEN and Vocode, quickly

TEN Framework builds an agent as a graph of extensions, and its default real-time transport runs on Agora, so the voice assistant example wants an Agora App ID and App Certificate next to your model keys. There's a WebSocket example and a SIP call example in the repo. The part to read slowly is the licence file: Apache 2.0 with added conditions from Agora. You can't host the framework on end-user devices like mobile phones, and you can't deploy it in a way that competes with Agora's offerings. For an on-device product or a voice platform, those two lines can settle the decision before any code is written.

Vocode is an MIT Python library and one of the earliest open voice agent projects, with inbound and outbound phone calls and integrations for lots of speech and voice providers. If you have a Vocode codebase and you're weighing a move, Pipecat is the shortest hop, since both are Python pipelines.

Your browser demo is too kind

One more phone-side trap. Most phone calls still reach the agent as 8 kHz audio, while a browser demo runs at 16 kHz. An agent that sounds sharp in a web test can mishear names and numbers on a real line, and how much depends on the speech-to-text model and the phone path. Place actual calls from a mobile and a landline before you commit to anything.

What's still on your plate

Even with the right route, a framework gives you the real-time loop as code and stops there. Pipecat is an excellent base, and production deployment still needs significant plumbing around it. There's no screen where a support lead edits the greeting without a pull request, and no outbound dialler with calling hours. Reviewing finished calls is yours to build as well.

That gap is where Dograh, the open-source AI voice agent platform we build, sits. It runs its call pipeline on our own fork of Pipecat, and you can self-host it or run it on our cloud.

Transfer Call in our case works on Twilio, Telnyx, Plivo, Cloudonix and Asterisk ARI, so the hand-off question from earlier has an answer on each of those carriers.

After each call, a QA node scores every step separately with tags, a 1-10 score, sentiment and a summary, so call review isn't a side project.

Our rough rule for the frameworks themselves: if your developers want Python control and transport freedom, start with Pipecat and plan a Daily PSTN or SIP route for transfers before launch. If you'd rather have native SIP and a media server you can also use for video, LiveKit Agents fits better, and LiveKit Cloud saves you running the SIP service.

If you've shipped a phone agent on Pipecat or LiveKit, which route did you end up on for transfers, and did you find out before launch or after?

The licence terms, transports and remaining build work for all five projects sit side by side in our comparison of open-source voice agent frameworks for phone calls.