What is an SBC?
An SBC (Session Border Controller) is a specialised piece of equipment — hardware appliance, virtual machine, or cloud service — that sits at the boundary between two real-time communications networks and controls the traffic that crosses that boundary. "Session" refers to a SIP session (a call); "border" is the network boundary; "controller" because it doesn't just forward packets — it actively inspects, modifies and decides what to do with each one.
The closest analogy in the data world is a next-generation firewall: a deep-inspection device at a trust boundary that knows the application protocol well enough to enforce policy on it. An SBC is that, for SIP and RTP.
Where the SBC sits
Three common deployment positions:
- Enterprise-edge SBC. Between your PBX (or UC platform) and the SIP trunks from one or more carriers. The most common position — sometimes called an E-SBC.
- Carrier-edge SBC. Between the carrier's voice core and the enterprise customer or another carrier. You don't see these directly; the carrier operates them.
- Cloud-attached SBC. For Microsoft Teams Direct Routing, Zoom Phone BYOC, and similar — an SBC (often virtual or hosted) sits between the cloud UC service and the PSTN carrier. With Microsoft Operator Connect this SBC is operated by the carrier, not the customer.
Functionally all three do the same things; the differences are in scale, who runs them, and exactly which features are emphasised.
The seven jobs of an SBC
- Security — block attacks, enforce authentication, drop malformed SIP.
- Interoperability — normalise SIP differences between the PBX and the carrier.
- Transcoding — convert between voice codecs when each side speaks a different one.
- Topology hiding — prevent your internal addresses leaking outward.
- NAT / firewall traversal — get SIP and RTP working across address translation reliably.
- Call admission control & QoS — enforce concurrent-call limits and protect quality.
- Recording, monitoring, lawful intercept — give you a controlled tap point.
Detail on each below.
Security: signalling & media
SIP networks face two distinct kinds of attack:
- Toll fraud. An attacker compromises an extension or finds a misconfigured trunk and uses it to place expensive international calls — bills can hit five or six figures inside a weekend. SBCs block this with rate-limiting, destination-blacklisting, geo-restrictions, time-of-day controls, and concurrent-call caps.
- Denial of service. Floods of
REGISTERorINVITEattempts that can overwhelm a PBX. SBCs absorb the flood with anti-flood policies, packet-rate limits, and per-source quotas.
The SBC also enforces:
- Authentication on REGISTER from endpoints (when supported).
- TLS for signalling and SRTP for media at the boundary — so SIP and audio aren't sent in clear over the WAN.
- SIP message sanitisation — dropping malformed messages and protocol fuzzing attempts that could crash PBXs known to handle them badly.
Because the SBC fully terminates SIP and RTP at the boundary, the internal PBX never directly faces the public internet. That's a major attack-surface reduction even before any specific rules are configured.
Interoperability & SIP normalisation
SIP is a standard, but every vendor implements its own dialect. Differences include:
- How call transfer is signalled (REFER vs Refer-To handling).
- How the From, To and P-Asserted-Identity headers are populated for caller ID.
- Codec ordering and DTMF transport (RFC 2833 vs in-band vs SIP INFO).
- Handling of fax (T.38) and DTMF during a re-INVITE.
- Trunk authentication style (IP-based ACL vs SIP Digest vs OAuth).
The SBC's SIP normalisation capability rewrites headers, re-orders codec lists, translates DTMF formats, and generally massages the conversation so the carrier sees something it likes and the PBX sees something it likes — even when those are different. Without an SBC, the answer to "this feature works against carrier A but not carrier B" is usually a custom PBX patch. With an SBC, it's a config change in the normalisation rules.
Transcoding
If your PBX wants to talk Opus or G.722 (HD voice) but your SIP trunk only supports G.711, someone has to convert in real time. The SBC can transcode codecs end-to-end — at a CPU cost, so transcoding capacity is often licensed separately and a number to size carefully.
You generally want to avoid transcoding when you can — it adds delay and a small quality penalty. The SBC's "passthrough" mode lets the same codec flow end-to-end whenever both sides agree, which is the default for most modern deployments.
Topology hiding & NAT
SIP messages carry a lot of network detail — your PBX's IP, the codecs it offers, sometimes user agent strings that identify the exact PBX vendor and version. A carrier or attacker on the other side of the trunk can fingerprint your environment from these.
The SBC rewrites SIP messages so the only address visible outside your network is the SBC's. Combined with NAT traversal — fixing up SDP addresses so RTP flows to and from public IPs even when endpoints sit behind NAT — this gives you a clean boundary regardless of internal topology.
Call admission control & QoS
The SBC enforces hard limits on:
- Maximum concurrent calls per trunk (preventing your trunk from being oversold and your carrier dropping new attempts).
- Maximum bandwidth per trunk (so voice traffic doesn't unexpectedly exceed what the WAN can handle).
- Per-user, per-extension, per-destination limits (for fraud protection).
It also marks egress traffic with QoS markings (DSCP EF for voice, AF for video) so downstream network equipment can prioritise it on congested links. Some SBCs do active media monitoring (MOS scoring) so you can spot quality issues before users complain.
Hardware, virtual, and cloud SBCs
- Hardware appliance. A dedicated box (often based on AudioCodes Mediant, Ribbon EdgeMarc/SBC SWe, Oracle Acme Packet, Cisco CUBE on routers, Sangoma). Highest performance, best for high-density enterprise or carrier deployments.
- Virtual SBC. The same software running on VMware, KVM, Hyper-V, or in your private cloud. Most enterprise-edge deployments today are virtual.
- Public-cloud SBC. AudioCodes, Ribbon, Oracle and others publish their SBCs as AWS / Azure / GCP marketplace images. Common for Teams Direct Routing and similar architectures.
- SBC-as-a-service. A few carriers and integrators offer hosted SBCs with per-channel pricing — useful when you want SBC capability without operating one.
Vendors & reference deployments
Major SBC vendors active in Singapore:
- AudioCodes — particularly strong in Microsoft Teams Direct Routing deployments.
- Ribbon Communications — both enterprise (SBC SWe Edge) and carrier-class platforms.
- Oracle Communications — Acme Packet, common in tier-1 carriers and large enterprises.
- Cisco CUBE — runs as a feature on IOS routers; common where Cisco UCM is the PBX.
- Sangoma — open-source-friendly options that integrate well with FreePBX.
In practice the choice is usually driven by what your PBX or UC platform integrates best with, what your carrier requires, and what your integrator already supports.
Do I really need an SBC?
Five tests. If you answer "yes" to any one of these, you need an SBC.
The "I don't need one because my deployment is small" argument is the most common reason small voice deployments get hit by toll fraud. The boxes are cheap; the bills aren't.
Where to go next
- Step back: From PSTN to SIP Trunking for the broader migration context (step 2 of the Voice Modernisation path).
- Foundations: VoIP Fundamentals for the SIP/RTP basics.
- Networking: LAN vs WAN Basics for the network performance side.
Browse SIP & SBC specialists in Singapore
Looking for help scoping or operating an SBC?