The border problem
A Session Border Controller sits at the boundary between your VoIP network and someone else's — a carrier, a branch office, the internet. Its job is to be the single controlled point where SIP and RTP cross that boundary.
The need arises because SIP is unusually awkward at borders. It carries IP addresses inside message bodies, so NAT breaks it in ways ordinary firewalls cannot fix. It exposes internal topology in its headers. It uses a wide dynamic port range for media. And different vendors implement it with enough variation that two compliant systems routinely fail to talk to each other.
An SBC exists to absorb all of that in one place.
What it actually does
Security
The SBC is the only device exposed to the outside, so your PBX is never directly reachable. It terminates SIP, inspects it, and re-originates toward the internal system — which means malformed messages and attacks stop at the border rather than reaching the thing that holds your credentials and dialplan.
It also enforces rate limiting and topology hiding: internal addresses, extension numbering and PBX version strings never leave the building. Scanners cannot map what they cannot see.
NAT traversal and media anchoring
Because the SBC handles both signalling and media, it can rewrite SDP correctly and anchor the RTP stream so both sides send audio to an address that is definitely routable. This resolves a large share of one-way audio problems structurally rather than case by case.
Interoperability
In practice this is the reason many organisations buy one. Carriers vary in what headers they expect, which codecs they will negotiate, how they format numbers and how they handle transfers. An SBC normalises those differences — rewriting headers, transcoding codecs, reformatting numbers — so your PBX sees one consistent interface regardless of which carrier is behind it.
This is what makes multi-carrier arrangements manageable. Without it, every carrier quirk becomes a special case in your dialplan.
Call admission control
The SBC can enforce a hard ceiling on concurrent sessions. That protects the PBX from overload, and it is a genuine fraud control: a cap of fifty concurrent calls bounds what a compromised extension can generate, no matter what the attacker attempts.
Encryption termination
Terminating TLS and SRTP at the border keeps that CPU cost off the PBX, and lets you present encrypted interfaces externally while running plain SIP internally on a trusted network.
When you do not need one
SBCs are sold hard, and a fair amount of that selling implies every VoIP deployment needs one. That is not true, and the honest position matters more than the sale.
You probably do not need an SBC if: you have a single carrier that works reliably, your PBX sits behind a properly configured firewall, your call volumes are modest, and your users are either on the LAN or on a VPN. A well-configured Asterisk with correct NAT settings, a restricted firewall, fail2ban and IP-restricted trunks covers a great deal of ground.
An SBC starts to earn its place when: you run multiple carriers with incompatible expectations; you have remote users connecting directly over the internet rather than a VPN; you need a hard concurrency cap for fraud control; compliance requires a documented, auditable security boundary; or you are large enough that the PBX should not be spending cycles on encryption and transcoding.
The blunt version: an SBC is not a substitute for configuring your PBX properly. Putting one in front of a system with weak SIP secrets and a permissive dialplan buys you very little — an attacker who authenticates legitimately passes straight through it. It secures the perimeter; it does not fix what is inside.
Hardware, virtual and open source
Commercial appliances and virtual SBCs from the established vendors are what large deployments and compliance-driven environments generally buy, and they come with support, which is often the actual product.
Open-source components can perform much of the same role. Kamailio and OpenSIPS are SIP proxies capable of acting as a signalling border, typically paired with RTPengine to anchor media. This is genuinely capable and widely used at scale — it is how many providers build their own infrastructure — but it is a construction kit rather than a product. You are taking on the engineering yourself.
The right question is not "which SBC" but "which of the five jobs above do I actually need". Sometimes the answer is one of them, and there is a simpler way to get it: media anchoring alone can be solved by keeping directmedia off; concurrency caps can be set on the trunk; topology hiding matters less if the PBX is not internet-facing in the first place.
Frequently asked questions
Do I need an SBC for a small business phone system?
Usually not. A single-carrier setup with a correctly configured firewall, strong credentials and users on the LAN or a VPN rarely justifies one.
Is an SBC a firewall?
No. A firewall filters packets by address and port; an SBC understands SIP, so it can inspect and rewrite the protocol itself — which is what NAT traversal and header normalisation require. They complement each other.
Will an SBC stop toll fraud?
Partly. It can rate-limit and cap concurrent sessions, which bounds the damage. It will not stop an attacker who has valid credentials from placing calls, so strong secrets and dialplan restrictions still matter.
Can I build one with open-source software?
Yes — Kamailio or OpenSIPS with RTPengine covers most SBC functions and is used in production at scale. It requires real SIP engineering, so weigh that against a supported product.