What is a Session Border Controller (SBC)?

What Does SBC Mean in Telecom?

In telecom, SBC stands for Session Border Controller. The “session” refers to a
SIP-based communication session such as a phone call, video conference, or messaging exchange. The
“border” refers to the boundary between two IP networks. The “controller” reflects the device’s role in
managing and securing traffic at that crossing point.

Every time a SIP call crosses from one network to another, whether carrier to carrier,
enterprise to cloud provider, or PBX to SIP trunk, an SBC sits at that boundary to enforce security
policies, normalize protocols, and route the session to its destination. Without an SBC, voice networks
are exposed to fraud, service disruptions, and interoperability failures that firewalls and SIP proxies
alone cannot address.

What Does an SBC Do?

An SBC performs several functions simultaneously on every call that passes through it.
These responsibilities fall into five categories.

Security and access control is the most visible role. SBCs protect
voice infrastructure against DoS and DDoS
attacks, SIP registration scanning floods, toll fraud, and unauthorized access attempts. They enforce
IP-based access control lists, dynamic blacklisting, and rate limiting to keep malicious traffic from
reaching the applications behind them. SBCs also handle encryption demarcation, terminating TLS for signaling and SRTP for
media at the network edge so internal systems can operate on unencrypted streams when needed.

SIP interoperability and normalization addresses the practical
reality of multi-vendor voice networks. Different PBX vendors, carriers, and cloud platforms implement SIP
differently. An SBC uses SIP header manipulation
rules to add, modify, or remove header fields on each call leg, ensuring that a Cisco PBX can communicate
cleanly with an Avaya system through a carrier trunk even when both use proprietary SIP extensions.

Topology hiding conceals internal network IP addresses, server names,
and infrastructure details from external parties. When a call leaves the network, the SBC substitutes its
own address for any internal addresses in SIP headers, preventing attackers from mapping or directly
targeting devices inside the private network.

Media handling includes codec transcoding (converting between
audio formats like G.711 and
G.729), media anchoring (keeping media streams flowing through the SBC for monitoring and policy
enforcement), and services like call recording, voice quality measurement, and announcement playback.

Call routing and policy enforcement gives network operators control
over where calls go and under what conditions. SBCs apply routing rules based on calling and called
numbers, time of day, trunk group utilization, and external data sources accessed through API integrations. This same policy engine
supports fraud detection and
regulatory compliance functions like STIR/SHAKEN
call authentication.

How an SBC Works: The B2BUA Architecture

The core of an SBC’s capability is its Back-to-Back User Agent
(B2BUA) architecture. Unlike a SIP proxy, which simply forwards SIP requests from one side to the
other, a B2BUA fully terminates the incoming SIP session and creates an entirely new session on the
outbound side. The SBC maintains two independent call legs and correlates them internally.

This two-leg model is what gives an SBC its power. Because the SBC owns both legs of
the call independently, it can modify SIP headers, change codecs, enforce different security policies on
each side, and hide the topology of one network from the other. A SIP proxy, by contrast, passes messages
through without modifying them and has no awareness of or control over the media stream. For a detailed
comparison of these two approaches, see SBC vs. SIP Server: What is
the Difference?

When a call arrives at the SBC, it processes the incoming SIP INVITE, applies routing
logic and security policies, and generates a new INVITE toward the destination. The two legs proceed
through the normal SIP call
flow independently, with the SBC bridging signaling and media between them for the duration of the
call.

SBC vs. Firewall

Firewalls inspect network packets at the IP and transport layer, but they cannot
understand the relationship between SIP signaling messages and the RTP media streams they negotiate. A SIP
call uses dynamic port allocation described inside the SDP body of the INVITE message. A standard
firewall sees an incoming media stream on an unexpected port and either blocks it (breaking the call) or
must open wide port ranges (creating a security gap).

An SBC is SIP-aware. It reads the SDP content, understands which ports will carry
media, and opens only those specific ports for the duration of the call. It also inspects the SIP messages
themselves for malformed headers, injection attempts, and protocol violations that a firewall would pass
through unexamined. Firewalls remain necessary for general network security, but they cannot replace the
SIP-layer intelligence an SBC provides.

SBC vs. SIP Proxy

A SIP
proxy forwards SIP requests without terminating sessions. It cannot modify SIP headers beyond adding
Via entries, cannot enforce media encryption, and cannot hide internal topology. SIP proxies are useful
within a homogeneous single-vendor environment for load balancing or call distribution, but they lack the
B2BUA architecture required for carrier interconnects, multi-vendor interoperability, or internet-facing
deployments where security and protocol normalization are requirements.

An SBC’s B2BUA model fully terminates and re-originates both signaling and media,
giving it complete control over every aspect of the call on both sides. This is what makes SBCs the
standard for any deployment where SIP traffic crosses a network boundary.

Where SBCs Sit in a Telecom Network

SBCs are deployed at every point where SIP traffic crosses from one trust domain to
another. The two most common deployment patterns are peering SBCs and access SBCs.

A peering SBC sits between two service providers or between a service
provider and a carrier. It manages carrier interconnection, enforces SIP interoperability between
different vendor platforms, applies routing policies, and generates call detail records for billing.
Service providers, ISPs, and wholesale voice carriers use peering SBCs to control and secure their traffic
exchange points.

An access SBC sits between external users (or external networks) and
an enterprise’s internal voice infrastructure. It protects IP-PBX systems, unified communications
platforms, and contact centers from the public internet. Access SBCs handle NAT traversal, TLS/SRTP
encryption termination, and registration forwarding for remote workers. MSPs managing Microsoft Teams Direct Routing, contact
centers migrating to cloud platforms, and enterprises with SIP trunking deployments all use access
SBCs.

In both patterns, the SBC enforces security at the network edge while ensuring that
calls between different systems, vendors, and networks complete reliably. For a detailed look at all SBC
deployment scenarios, see the SBC use cases
page.

SBC Deployment Models

Historically, SBCs were purpose-built hardware appliances. Today, most new deployments
run on software. A software SBC installs on standard servers, virtual machines (VMware, KVM, Proxmox), or
cloud instances (AWS, Azure), delivering the same carrier-grade functionality without the capital expense
and vendor lock-in of proprietary hardware.

Common deployment models include on-premises bare-metal servers for maximum
performance, virtualized
environments for flexibility and consolidation, cloud
deployments on public cloud platforms for elastic scalability, and managed SBC services where a vendor
handles deployment, monitoring, and maintenance. The shift from hardware to software SBCs has been one of
the most significant changes in telecom infrastructure over the past decade, making carrier-grade voice
security accessible to organizations of all sizes.

For a comprehensive guide covering SBC architecture, features, deployment models, and
evaluation criteria, see the full Session Border Controller guide in
our learning center.