A session border controller, almost always shortened to SBC, is the checkpoint where two IP networks hand voice calls to each other. It sits at the edge of a network, terminates the SIP signaling and usually the audio of every call that crosses, and decides what is allowed through: which calls may start, which codecs they may use, how much traffic is too much, and whether the signaling and media are encrypted.
The short answer for most readers: if your company already runs a PBX or carrier SIP trunks, you almost certainly have an SBC somewhere in the path, even if nobody has mentioned it, and your job is to point it at your voice agent platform. If you are building a voice-agent stack from scratch, you almost certainly do not need to buy one, because the agent platform’s own SIP endpoint can do the SBC’s core security jobs at the border. The rest of this guide is what an SBC actually does, so you can tell which situation you are in.
What a session border controller is
An SBC is a network element deployed at the border between two IP networks to protect and control SIP-based real-time communications, as Wikipedia’s definition puts it. The name is literal once unpacked: a “session” is a call, the “border” is the demarcation point between one network and another, and the “controller” is the policy enforced on what crosses.
Two design choices define the species:
- It is a back-to-back user agent (B2BUA). Unlike a SIP proxy, which forwards messages, an SBC terminates each side of the call independently and re-originates it on the other. The caller’s network only ever sees the SBC, never the equipment behind it, which is what “topology hiding” means in vendor brochures.
- It touches the media, not just the signaling. An SBC sits in the RTP path as well as the SIP path, so it can encrypt, transcode, and measure the audio itself, and cut calls whose signaling looks fine but whose media is abusive.
SBCs first appeared at the peering points between carriers, where networks with mutual distrust exchange calls. The role has since expanded to the enterprise edge, between a company’s phone system and its SIP trunk provider, which is where most people meet them today.
What an SBC does
Vendor datasheets list dozens of features, but they cluster into six jobs:
| Job | What the SBC actually does |
|---|---|
| Security | Blocks denial-of-service floods and malformed SIP, prevents toll fraud, hides internal addresses, encrypts signaling with TLS and media with SRTP |
| Connectivity | Traverses NAT, normalizes the quirks between vendors’ SIP stacks, interworks IPv4 and IPv6, translates between SIP variants and older protocols like H.323 |
| Quality of service | Admits or rejects calls based on load, rate-limits, polices traffic, marks packets for priority |
| Regulatory | Prioritizes emergency calls, supports lawful interception where required |
| Media services | Transcodes between codecs, relays DTMF between in-band tones and telephone-events, plays tones and announcements |
| Statistics and billing | Produces call detail records at the natural measurement point, the border |
The security row is why SBCs became standard equipment. An open SIP endpoint on the public internet is found by scanners within minutes and hammered with free-call attempts, so someone has to be the bouncer. The interworking row is why they stayed: every vendor implements SIP slightly differently, and the SBC is where those differences get ironed out before they can break calls.
SBC vs firewall vs SIP proxy
The three boxes get confused because they all sit at network edges:
| Box | Sees | Acts on |
|---|---|---|
| Firewall | Generic IP packets | Ports, addresses, protocols, with no understanding of calls |
| SIP proxy | Signaling only | Routes INVITEs to the right destination; never touches media |
| SBC | Signaling and media, with full call state | Security policy, interworking, admission control, encryption, transcoding |
A firewall that “passes SIP” merely lets port 5060 through; it cannot tell a legitimate INVITE from a toll-fraud attempt, and it cannot fix the fact that the SDP inside the INVITE names a private IP the other side cannot reach. A SIP proxy routes calls but does not protect them. The SBC is the one that does both jobs with voice awareness, which is why it sits between the firewall and the phone system in a typical enterprise diagram.
Hardware, virtual, cloud, and open source
SBCs started as rack appliances, and that market is still here: Oracle’s Acme Packet lineage, AudioCodes’ Mediant series, and Ribbon’s SWe line are the names on most enterprise purchase orders, and Cisco’s CUBE, the border element built into its routers, is the quiet incumbent in Cisco shops. The same functions now ship as virtual machines, cloud-native microservices, and managed per-session services, so “an SBC” today is more often a license than a box.
On the open-source side, Kamailio and OpenSIPS handle the signaling role, usually paired with RTPEngine for media, and cover a large share of what a commercial SBC does for teams willing to operate them. They are a real option for carriers and large platforms; they are rarely the right answer for a team that just wants its calls to reach an agent.
Do you actually need one?
Three situations cover nearly everyone asking:
- You already have one. If your company runs a PBX or carrier SIP trunks, there is an SBC (or a CUBE, or the carrier’s own) at the edge, and it is doing its job. Keep it as the demarcation point, and point it at the agent platform’s SIP endpoint when you add voice agents.
- Your carrier has one. Every trunk provider runs SBCs on its own border; that is part of what the per-minute fee buys. Calls between two carriers’ SBCs are the normal case, not the exception.
- You are building net-new voice agents. If there is no legacy phone system to protect, an appliance SBC is a hop you do not need. The security jobs it would do, TLS for signaling, SRTP for media, digest authentication, and source-IP allowlists, are features of the agent platform’s own SIP endpoint. Every box you insert is also latency: each hop between the caller and the agent adds delay callers can hear, as the SIP trunking guide covers.
The honest summary: an SBC is load-bearing infrastructure when you have a network to protect, and overhead when you do not.
Where an SBC meets a voice agent
When a call reaches an AI voice agent over a SIP trunk, the path is caller, carrier, maybe your SBC, the agent platform’s SIP endpoint, and then the agent itself. The SBC-related details that matter in practice:
- Terminate encryption deliberately. SBCs are where TLS and SRTP usually start or end. A trunk that negotiates SRTP on one side and plain RTP on the other produces calls that connect and carry silence, the same failure as enabling encryption on one side only.
- Watch DTMF translation. SBCs routinely convert keypresses between in-band tones and out-of-band telephone-events. If callers press digits and the agent never hears them, the SBC’s DTMF interworking settings are the first place to look.
- Transfers cross the SBC as REFERs. When the agent hands a call to a person, the platform sends a SIP REFER, and the SBC has to pass it. A trunk that strips REFER turns every warm transfer into a dropped call.
- Codec lists are policy. An SBC can force or transcode the codec on a call. Phone paths settle on G.711, the 8 kHz codec that shapes what the agent’s speech recognition hears; a transcoding SBC in the path is one more thing to check when recognition quality is off.
- Jitter is measurable at the border. SBCs report per-call statistics, including the RTCP jitter figures the VoIP jitter guide shows how to read. When a call sounds choppy, the SBC’s report is the authoritative source for what the far end experienced.
On Cartesia, Managed Agents terminate SIP trunks over TCP or TLS, negotiate SRTP with a media_encryption setting of disabled, allowed, or required, and authenticate inbound calls with digest credentials or an IP allowlist once at least one access-control method is configured, so the platform endpoint plays the SBC’s security role on its own border, and your existing SBC, if you have one, just needs to point at it. The SIP trunking integration guide walks through the configuration, including the Twilio-specific notes.