Open Source Session Border Controller
At the edge of a VoIP network, the session border controller decides which calls get in, hides your internal SIP topology, and reconciles the incompatible signaling that real carriers send, which makes it the firewall and translator your voice traffic cannot work without. Open source options put that border under your control, so call routing, security policy, and how SIP is normalized at the perimeter become configuration you own rather than features gated behind a telecom appliance. That control cuts both ways: you also take on the interoperability testing, the TLS and media hardening, and the failover design that a vendor box would otherwise hide from you.
Kamailio
High-performance SIP server for routing, proxying, and registrar duties at carrier scale
OpenSIPS
High-performance SIP proxy and server for carrier-grade voice signaling platforms
LibreSBC
Dedicated Session Border Controller for securing and routing VoIP traffic at the network edge
Our picks
One is a finished SBC; the other two are the engines telecoms use to build their own.
Ready-made dedicated SBC: LibreSBC LibreSBC is a purpose-built session border controller on top of FreeSWITCH, meant to sit at the edge as a B2BUA. It handles NAT traversal, SIP normalization and header manipulation, topology hiding, TLS signaling and SRTP media, access control lists, and rate limiting by calls per second and concurrent calls, plus transcoding, a routing engine with load balancing and failover, JSON CDRs to an HTTP API, and Homer capture integration.
Carrier-scale signaling engine: Kamailio Kamailio is a SIP server that routes, proxies, and registers traffic at thousands of call setups per second, controlled by a configuration script and a large module set. It adds load balancing, least cost routing, NAT traversal, IMS and VoLTE support, and WebRTC over WebSocket. It is not a turnkey SBC; it is the engine you use to build one, which is the trade for its flexibility.
Multi-purpose platform builder: OpenSIPS OpenSIPS is a SIP proxy and server used to build Class 4 and 5 systems, trunking, virtual PBX, load balancers, and session border controllers, with more than 120 modules and throughput in the tens of thousands of calls per second over TCP and TLS. Like Kamailio, it is a building block for an SBC rather than one by itself, aimed at carriers and ITSPs.
Sizing an SBC to the border you actually run
The first fork in this category is whether you want an SBC or the parts to build one. LibreSBC is a purpose-built, dedicated SBC: it sits at the edge as a B2BUA doing topology hiding, NAT traversal, SIP normalization, TLS and SRTP, access control, and transcoding out of the box. Kamailio and OpenSIPS are high-performance SIP servers, the signaling engines carriers use to construct SBCs, edge proxies, and registrars through scripted routing and modules. They scale to enormous call volumes, but neither is turnkey; you assemble the border behavior yourself. Picking well starts with how much you want to build versus configure.
Decide how much media the controller should carry, because it drives everything downstream. Some deployments only need signaling control and RTP anchoring for NAT traversal; others need SRTP termination, codec filtering, WebRTC interop, or full transcoding. LibreSBC bundles transcoding and SRTP directly, while a Kamailio or OpenSIPS edge typically pairs with a separate media relay for RTP. Each choice changes CPU load, latency, and security exposure, so be deliberate about TLS certificate handling, cipher policy, and RTP port ranges rather than turning everything on and hoping.
Because an SBC becomes part of the voice edge, weigh how it behaves when things break. Look for deterministic configuration you can keep in version control, health checks that understand SIP responses, and high availability that is honest about whether in-progress calls survive a failover or only new calls route through a standby. Observability is just as important: searchable SIP traces, RTP statistics, and CDRs tied to call identifiers, where LibreSBC emits JSON CDRs to an HTTP API and integrates with Homer capture. It is a small field, but these three cover the range from a ready-made SBC to the engines behind custom ones.
Related categories
Frequently asked questions
What is the difference between a session border controller and a SIP proxy?+
A SIP proxy routes signaling to the next hop. An SBC sits at a trust boundary and enforces policy there: rewriting headers, hiding internal topology, anchoring or encrypting media, rate-limiting abusive sources, and normalizing carrier quirks. The distinction matters here because Kamailio and OpenSIPS are SIP servers and proxies at heart, which you extend with modules and scripting to take on SBC duties, while LibreSBC is built as a border controller from the start.
Do Kamailio and OpenSIPS work as SBCs on their own?+
Not out of the box. Both are high-performance signaling engines, the toolkits carriers use to build SBCs, edge proxies, registrars, and SIP firewalls through scripted routing and modules. You get enormous scale and flexibility, but you assemble the border behavior, and RTP usually goes to a separate media relay. If you want an SBC that already does topology hiding, SRTP, and transcoding without that assembly, LibreSBC is the purpose-built option here.
When does a smaller VoIP deployment actually need an SBC?+
You need one when SIP crosses an untrusted or messy boundary: an internet SIP trunk, several carriers, remote phones, customer endpoints, or a hosted PBX edge. If every device sits on one controlled LAN behind a simple carrier link, a PBX firewall policy may be enough. Add an SBC once NAT traversal, toll-fraud exposure, or carrier normalization becomes too much to manage safely on the PBX itself.
Does an SBC need to do transcoding?+
Not always, and avoiding it saves latency and CPU. If your carriers, endpoints, and PBX agree on codecs, plain RTP anchoring is enough. You need transcoding when bridging incompatible codecs, handling WebRTC audio, enforcing a narrow codec policy, or connecting legacy gear. LibreSBC includes transcoding directly; a Kamailio or OpenSIPS edge would pair with a media engine for it. Treat every concurrent transcoded call as real capacity planning, not a checkbox.
How important are TLS and SRTP?+
TLS protects the SIP signaling in transit and SRTP protects the media, and both matter whenever traffic crosses networks you do not control or carries sensitive caller data. LibreSBC terminates TLS signaling and SRTP media directly at the edge. Check certificate handling, cipher control, and mutual TLS, and confirm encrypted calls can still be routed, recorded, and diagnosed, because encryption that breaks troubleshooting tends to get quietly switched off later.
How do high-availability designs handle calls during a failover?+
Ask whether failover preserves existing call state or only routes new calls through a standby node. Many voice edges recover registrations and new outbound calls fast while dropping calls that were in progress, which can be acceptable if it is explicit. LibreSBC's routing engine handles load balancing and failover across peers. Test node loss, a network split, and carrier failure separately, because each exposes different assumptions about what survives.
What should I test for NAT traversal and remote phones?+
Test real endpoints behind home routers, carrier-grade NAT, VPNs, and mobile networks if you have such users. Watch Contact and Via rewriting, symmetric RTP, keepalives, registration expiry, and re-INVITE handling after hold or transfer, since one-way audio often shows up only after a mid-call event. LibreSBC handles NAT traversal and SIP normalization at the edge, but packet captures from both sides tell you more than a green registration status.