VoIP & SIP
The SBC decision most VoIP deployments get wrong
Two constraints, on two different layers of a SIP deployment, turn out to share one fix. Most teams discover this the hard way — after a carrier rejects their trunk, or after a caller reports a call that connects, looks healthy on every server-side counter, and is completely silent.
The first constraint: REGISTER
Open-source SIP-to-WebRTC bridges — the kind of software that sits between a carrier and a media server — are usually built as trunk endpoints, not clients. A trunk endpoint expects a carrier to deliver calls to it directly, over a connection the carrier already trusts (an IP allowlist, most often). What it typically does not do is REGISTER — the SIP verb a client uses to log in to a provider with a username and password.
That distinction matters because it splits SIP providers into two camps:
- IP-authenticated trunks. The provider whitelists your server's IP and delivers calls to it directly. No login step. This is how most carrier-grade trunks work — Telnyx, Twilio, and most providers selling directly to businesses.
- Registration-based accounts. The provider issues a username and password, and expects your equipment to register with it periodically, the way a softphone does. This is common with resellers and with providers whose primary market is small offices and PBXs rather than platforms.
If your bridge can't send REGISTER, the second category is closed to you — not degraded, closed. The call never arrives, because the provider never sees a device it recognises as online.
The second constraint: IPv4-only media
The second issue is quieter, and much harder to diagnose, because it doesn't fail — it half-succeeds. Some SIP media stacks scan the host's network interfaces for an address to advertise in SDP (the protocol that negotiates where audio actually flows), and skip anything that isn't IPv4. That's a reasonable default. It becomes a problem the moment a caller's device offers IPv6 media.
When that happens, the call still connects. Signalling completes normally. Every counter on the server side — packets sent, jitter, round-trip time — looks correct, because the server genuinely is sending audio. What's missing is that the caller's device advertised an IPv6 address for its own media, the IPv4-only side never learned to reach it, and audio flows one way. The caller hears the call. Nobody hears the caller.
We found this after several calls that "worked" by every server metric we had. The only evidence was in the handset's own logs, showing it had negotiated an IPv6 media address the server side never saw.
Why one box fixes both
A Session Border Controller sits between the carrier and your media server, and it resolves both problems at once:
- It can register with a provider on your behalf, so your inner media server never needs to. As far as it's concerned, calls simply arrive.
- It terminates the caller's media — including IPv6 — and re-originates it as IPv4 toward the inner network. The IPv4-only assumption downstream stops being a problem because nothing downstream ever sees IPv6.
- It gives you one hardened edge instead of an internal media server sitting exposed on the public internet — worth doing on its own, since port 5060 is scanned continuously by toll-fraud bots regardless of which provider you use.
Between the common SBC choices, we lean toward Asterisk over Kamailio for this role specifically: Asterisk handles registration and media in one process, where Kamailio typically needs a separate media proxy (commonly rtpengine) alongside it — more moving parts for the same outcome.
How to know if you need one
The trigger is the provider, not IPv6 in the abstract. Carrier-grade trunks are overwhelmingly IPv4, IP-authenticated, and never send you a registration-based account — so if you've bought from a major carrier, the IPv6 failure mode may simply never come up in production. It surfaces when a client device — a softphone, a modern handset with IPv6 enabled by default — dials in directly, or when your provider only offers registration-based accounts.
Decide the provider question first. If it requires REGISTER, the SBC is mandatory — there's no path around it. If it doesn't, the SBC is a hardening measure you can schedule rather than a blocker, but the IPv6 media issue is worth closing regardless: better to reject an incompatible offer outright with a clear failure than to answer a call that goes silent one way.