Think of your phone system the way you’d think of your electrical wiring. You don’t rip out the wiring in your building every time you want to plug in a new appliance — you just need the right socket. The same problem is showing up right now for a lot of teams evaluating AI voice agents: the agent platform speaks one language, the office PBX speaks another, and the honest answer to “how do I connect them” usually turns into “replace your whole phone system first.”
That answer is wrong for most businesses running Asterisk or FreeSWITCH today. It’s also unnecessary.
Why AI voice agents can’t just “plug in” to a phone line
Platforms like Vapi, Retell AI, Bland AI, and ElevenLabs’ agent tooling — along with developer frameworks like LiveKit and Pipecat that teams use to build their own — rely on WebRTC for real-time audio streaming. That’s what lets them stream audio to and from a large language model in real time. A traditional business phone line, and the Asterisk or FreeSWITCH PBX behind it, speaks SIP: a different signalling protocol, with its own approach to media negotiation, NAT traversal, and encryption that WebRTC doesn’t share out of the box.
In the AI voice agent world this gap has a name: BYOC, or “Bring Your Own Carrier.” It’s the piece of infrastructure that translates between the two worlds so a WebRTC-native agent can actually ring a real phone number, and so a call to your existing business line can actually reach the agent.
The two ways to close that gap
Most of the current advice on this treats BYOC as a carrier decision: switch your telephony to a cloud provider that’s already compatible, and route everything through them. That works, but it means moving your phone numbers, your call routing, and often your existing PBX configuration onto someone else’s platform just to get one new feature.
The other way is to bridge the gap in place. If your Asterisk or FreeSWITCH deployment already does everything you need it to do, the more direct fix is a proxy that sits between your PBX and the WebRTC side — handling the protocol translation, NAT traversal, and media negotiation — so the AI agent platform can connect to a phone number that still lives on your own infrastructure. This is what Siperb’s WebRTC-to-SIP proxy already does for browser- and mobile-based softphone calling — the same protocol translation, NAT traversal, and media negotiation apply regardless of what’s generating the WebRTC audio on the other end, whether that’s a person’s browser or an AI agent’s audio pipeline. For PBXs that don’t natively support WebRTC’s encrypted media format, the proxy also handles DTLS-to-RTP transcoding, so calls still connect cleanly on both sides.
Who this actually matters for
This isn’t a general pitch for every business exploring AI voice agents — most small teams are well served by a platform’s own bundled telephony. It matters specifically for:
- MSPs and resellers who already run client PBX deployments and want to offer an AI voice agent as a new billable service, without re-platforming a client’s entire phone system to do it.
- Teams with real investment in Asterisk or FreeSWITCH — custom dialplans, existing integrations, compliance requirements — who don’t want an AI experiment to force a migration decision.
- Anyone evaluating Vapi, Retell, Bland, ElevenLabs, or a LiveKit/Pipecat build who has asked their existing PBX vendor “can this plug into what we already have” and gotten a shrug.
What practitioners say: the AI is the easy part
We asked VoIP and contact-centre practitioners who have added AI voice agents to phone systems they already had what actually caused trouble. Every answer made the same point: the AI model wasn’t the problem. The problems were in routing, hand-offs and the plumbing around the call.
“Most businesses don’t need to rip out their PBX to add AI voice agents. The practical route is to layer the agent into specific SIP call paths first, prove containment and transfer reliability, and keep the existing telephony stack doing what it already does well. The technical risk usually sits in routing, latency, and handoff logic, not in the AI itself.”
— Dieter Blom, Director at Versys Media
“The AI was the easy half. What broke was the plumbing around it: caller ID, who owns the call after a transfer, and what the admin sees when a trunk misbehaves. Get those three right and an AI agent will sit in front of a ten-year-old PBX without complaint.”
— Tim Molter, Co-founder & CTO, AI Receptionist
On the second of those, Molter’s advice is to decide up front who owns the call after the hand-off. A SIP REFER tells the PBX to take the call back and complete the transfer itself, so the AI platform drops out of the media path and stops billing minutes. An INVITE bridges the call through the AI platform instead, keeping it on the line for the rest of the conversation. REFER only works when the call arrived over SIP in the first place, so you need both paths and a rule for choosing between them.
Jack Wright, VP of Operations at HealthWright Technologies, found the same thing when his team added AI voice agents to the phone setup they already had: “the agent was never the hard part. The handoffs were.” His warning is one that’s easy to miss:
“Publishing a new call flow can quietly seize the inbound route on a number an AI agent is already answering, so the agent goes silent while the dashboard still looks healthy. Check the binding on the number itself after every publish.”
— Jack Wright, VP of Operations, HealthWright Technologies
What to check before you commit to either path
Whichever route you take — a pure-carrier BYOC provider or a proxy that bridges your existing PBX — the same technical questions apply: does it support the codecs your agent platform expects, does it handle NAT traversal cleanly for your network, and does it keep media encrypted end to end. Ask any vendor those questions directly; a platform that can’t answer them plainly is a platform you should be wary of trusting with live calls.
If keeping your existing PBX in place is the right call for your business, Siperb’s WebRTC-to-SIP proxy is built for exactly this kind of bridging — worth a look before assuming the only path forward is starting over.
Leave a Reply