Replace Twilio with a SIP Trunk and an SBC

A few years ago, rebuilding Twilio’s API layer yourself was a real project. Now it is a weekend. AI-assisted coding has made the programmable-voice glue (the webhooks, the call-control logic, the number provisioning) cheap enough that a small team can reproduce the parts of Twilio they actually use in a few days. So the question changes. If the API layer is no longer the hard part, what is the one piece you still need in order to leave Twilio?

The answer is the connection to the phone network itself. A carrier will not hand you a SIP trunk and let you point it straight at your PBX or your application. They need a clean, hardened SIP endpoint at the border, and that endpoint is a Session Border Controller (SBC). In this article, we’ll walk you through the literal mechanics: why the carrier insists on an SBC, how the SIP trunk to SBC to PBX path actually fits together, and what owning that SBC opens up once the calls are flowing.

Why You Can’t Just Point a Carrier SIP Trunk at Your PBX

Here is the situation most teams hit the moment they contract a carrier directly. They have their app running, they have a SIP trunk provisioned, and they assume the next step is to put the carrier’s IP in their PBX config and dial out. Then the carrier’s onboarding engineer asks for the address of their SBC, and the project stops.

The carrier is not being difficult. A SIP trunk terminates somewhere, and whatever it terminates on is exposed to the public network. A raw PBX or a bare application sitting on a public IP is a target: SIP scanners find it within hours, toll-fraud attempts follow, and any malformed signaling the internet throws at it lands directly on the thing running your calls. Carriers require a controlled demarcation point so that what connects to their network presents a static signaling IP they can whitelist, speaks clean signaling, terminates TLS, and hides everything behind it.

That demarcation point is a Back-to-Back User Agent (B2BUA), which is what a full SBC is. A B2BUA does not relay SIP packets the way a proxy does. It fully terminates the inbound SIP session on the carrier side and originates a brand-new, independent session toward your PBX, per RFC 3261. Because it owns both call legs, it can present exactly what the carrier expects on one side while presenting exactly what your PBX expects on the other. A SIP proxy cannot do that; it forwards messages largely untouched, which is fine inside a single-vendor cluster and not fine at a public carrier border.

We saw this play out with a logistics SaaS company that had been on Twilio since 2014. As AI made it faster to rebuild voice-agent workflows, they rebuilt the Twilio API pieces they depended on over a single weekend. The genuinely hard blocker turned out to be the one they had not thought about: their carrier, which happened to be the same carrier Twilio uses in that region, told them they needed an SBC before a single call could cross. The API was the easy part. The border was the real work.

The Replacement Path: SIP Trunk to SBC to Your PBX or App

The full path from Twilio to a carrier-owned voice stack has five moving parts, and only one of them is new to most teams.

1. Rebuild or keep your application and API layer. This is the piece AI has made cheap. Your call-control logic, your number handling, and your webhooks stay yours; you are not changing what your app does, only what it connects to underneath.
2. Contract a SIP trunk directly with a carrier. This is the Bring Your Own Carrier (BYOC) model. You buy trunk capacity from a wholesale or retail carrier instead of renting minutes from a CPaaS platform that is buying that same trunk on your behalf.
3. Put an SBC at the border. The SBC terminates the carrier’s SIP trunk and re-originates a clean session toward your infrastructure. It handles SIP over TLS and SRTP on the carrier leg, topology hiding so your internal addresses never leak, and header normalization so the carrier’s specific SIP dialect gets rewritten into whatever your PBX or app expects.
4. Register, or don’t. Some carriers deliver a static-IP trunk with no registration; others expect a SIP registration. The SBC handles either, and forwards registrations upstream when the carrier requires them.
5. Point your PBX or app at the SBC’s internal interface. Your application now talks to a friendly, private, standards-clean SIP endpoint on your own network and never touches the public carrier trunk directly.

That is the whole shape of it. The SBC is the translation and enforcement layer that turns a raw carrier trunk into something your application can safely use.

This page is deliberately about the replacement mechanics. If what you actually need is the deeper reference on how an SBC secures and normalizes a trunk you already have, the companion SBC SIP trunk guide covers that ground; this one is specifically about getting off Twilio.

What Owning the SBC Opens Up

Here is the part that changes the economics beyond the obvious cost saving. When you rent voice from a CPaaS platform, you get one abstracted path to the phone network. When you own the SBC, the SBC is now a control point you can build on.

The first thing it opens up is multi-carrier routing. A single SBC can define a large number of separate trunk groups, called Network Access Points (NAPs), with ProSBC supporting up to 1,024 NAPs on one server. Each NAP is a distinct carrier or endpoint relationship with its own encryption, header rules, and codec policy. Practically, that means you can connect several carriers behind one SBC and let it pick the route: cheapest per destination, or a preferred carrier with automatic failover to a backup when a route degrades. That is least-cost routing, and it is something a single CPaaS relationship structurally cannot give you because you only ever see one provider’s rate.

The second thing is routing on quality, not just price. An SBC in the media path produces per-call Mean Opinion Score (MOS) estimates and can capture live traffic for diagnosis. Combined with programmable routing, that lets you make route decisions informed by measured call quality rather than routing blind and hoping. You can decide that a given destination goes to the carrier delivering the better MOS even when it is not the absolute cheapest.

The third thing is programmable routing itself. ProSBC exposes a routing engine you drive through Ruby modules and a REST API, so route selection can query an external system mid-call: a least-cost-routing table, a fraud-scoring service, a number-portability lookup, or your own business logic. The SBC REST API routing pattern is how carrier selection, fraud checks, and CRM-aware routing get wired in without touching the carrier config. This is also what makes an SBC a natural fit in front of voice AI agents, where traffic is bursty and you want per-campaign routing and attestation decisions made programmatically.

And the fourth thing, quietly, is ownership. You hold the Call Detail Records for billing reconciliation, you set the fraud posture, and you own the carrier relationships and the margin between what the carrier charges and what your product earns. None of that is visible when a CPaaS platform sits in the middle.

The Economics: Why This Beats Per-Minute at Scale

CPaaS pricing is per minute, and per-minute pricing is comfortable at low volume and brutal at high volume. The reason is simple. Underneath, the CPaaS platform is buying the same carrier SIP trunk you could buy, adding an API and a margin, and reselling you minutes. At ten concurrent calls that margin is a rounding error. At a few hundred concurrent calls it becomes the largest line item in your voice budget, and it scales with your success rather than with your cost.

Moving to a direct carrier trunk plus an SBC converts that variable per-minute markup into a fixed trunk cost plus a predictable SBC subscription. To give you a sense of the shape (and these are illustrative figures, not a price list), a customer-hosted deployment with the SBC managed for you can land in the neighborhood of $6,000 a year for up to a couple hundred concurrent calls, and a fully hosted and managed deployment with transcoding included sits higher, around $15,000 a year. The point is not the exact number, it is that the SBC cost is flat while the CPaaS per-minute cost keeps climbing with volume. For the detailed side-by-side on where the crossover happens, the companion Twilio voice pricing at scale breakdown runs the math. For current ProSBC rates, the pricing page lists them openly rather than hiding them behind a quote.

The same economics are why teams building elastic SIP trunking capacity for a CPaaS-style workload often move to a direct-carrier BYOC model as they scale past the point where per-minute pricing made sense.

Practical Considerations Before You Cut Over

A few things are worth checking honestly before you commit to a cutover date, because getting them wrong is how a clean migration turns into a bad week.

Transcoding matters if the codecs do not line up. If your carrier delivers calls in a mobile codec such as AMR and your application expects G.711, something has to convert between them, and where that conversion happens is a real design decision. ProSBC handles G.711 A-law and mu-law in software; converting AMR, G.729, or Opus needs hardware transcoding acceleration today, with software transcoding for additional codecs on the roadmap. Whether you need it at all depends on whether your carrier already handles mobile codec conversion on its side, so confirm that before you size anything.

Hosting and redundancy are a choice, not a default. You can run the SBC on AWS, Microsoft Azure, VMware, KVM, or bare metal, and you can host it yourself or have it hosted and managed for you. For call continuity, an active/standby SBC pair gives you redundancy for maximum uptime and minimal downtime through a node failure. Size for geo-redundancy across two locations if the business needs calls to survive a data-center outage.

Timelines deserve candor. A trunk-and-SBC migration is not a two-week guarantee, and anyone who promises one has not looked at your carrier’s onboarding process, your codec situation, or your existing dial logic. Plan a parallel run: stand the SBC up alongside Twilio, move one traffic slice across, validate it, then cut the rest over with a rollback path in your pocket.

Frequently Asked Questions

Conclusion

The only hard dependency in leaving Twilio is getting your calls onto the public telephone network through a carrier, and a carrier will not terminate a trunk onto a bare PBX or application. The SBC is the piece that makes a direct carrier trunk usable and safe: it satisfies what the carrier requires at the border, and it hands your application a clean, private SIP endpoint on the inside. Rebuild the API layer over a weekend if you like; the durable work, and the durable payoff, is owning the border. Once you do, multi-carrier least-cost routing, quality-aware routing, and programmable call control stop being someone else’s product and start being yours.