Session Border Controller (SBC): The Complete Guide to Software SBCs

A session border controller is the device that sits at the boundary between two IP voice networks and governs every SIP session that crosses it. It terminates signaling and media on one side, applies security policies, translates protocols, and re-originates a new session on the other, giving network operators full control over what enters and leaves their infrastructure.

For two decades, that function lived on proprietary hardware appliances. Today, a new generation of software-based session border controllers delivers the same carrier-grade capabilities on virtual machines, cloud instances, and commodity servers, at a fraction of the cost and with deployment flexibility that hardware could never match. This guide covers what an SBC does, how it works inside a real voice network, why the industry is moving from hardware to software, and what to evaluate when choosing an SBC for a production environment.

What Is a Session Border Controller?

A session border controller is a specialized network element that polices the border between two SIP-based voice networks. Unlike a SIP proxy — which forwards requests without terminating the session — an SBC operates as a Back-to-Back User Agent (B2BUA). It fully terminates the incoming SIP dialog, inspects and transforms every header and media stream, and re-originates a completely new dialog on the other side.

This B2BUA architecture is what gives the SBC its power. Because it maintains two independent call legs, it can apply different security policies, different encryption standards, and different SIP formatting on each side without either network needing to know anything about the other. The carrier sees the SBC’s address, not your internal topology. Your internal systems see clean, normalized SIP, not the carrier’s proprietary headers.

In practice, session border controllers serve three fundamental roles. First, they protect the network: blocking malicious SIP traffic, mitigating DoS and DDoS attacks, enforcing access control lists, and hiding internal infrastructure from external view. Second, they enable interoperability: normalizing SIP dialects between vendors, converting between encrypted and unencrypted media, and translating codecs so that incompatible endpoints can communicate. Third, they enforce policy: routing calls based on business rules, limiting concurrent sessions through call admission control, generating call detail records for billing, and ensuring regulatory compliance with frameworks like STIR/SHAKEN.

What Does a Session Border Controller Do?

The functions an SBC performs fall into five categories, each addressing a different operational requirement in a production voice network.

Security and Access Control

Security is the most common reason organizations deploy an SBC. At the network edge, the SBC acts as the single point of entry for all SIP traffic, which makes it the natural place to enforce security policy.

DoS and DDoS protection detects and blocks volumetric attacks — SIP floods, registration storms, and distributed denial-of-service attempts — before they reach the call processing infrastructure behind the SBC. Dynamic blacklisting allows the SBC to automatically block IP addresses or calling numbers that exhibit suspicious behavior, while static access control lists define which sources are permitted to send traffic in the first place. SIP registration scanning protection identifies and blocks brute-force registration attempts, a common precursor to toll fraud. Topology hiding ensures that internal IP addresses never leak into external SIP headers, preventing attackers from mapping your network.

When the SBC operates as a B2BUA, it also provides a natural demarcation for encryption. It can terminate TLS-encrypted SIP signaling on one leg and re-originate it on the other, with a different certificate, a different cipher suite, or no encryption at all, depending on what each side requires. The same applies to media: the SBC bridges between SRTP and plain RTP transparently, so that a carrier delivering unencrypted media can connect to a platform that mandates encryption without either side changing its configuration.

SIP Interoperability and Normalization

No two SIP implementations are identical. Carriers, PBX vendors, and collaboration platforms each interpret the SIP RFC differently, add proprietary headers, and handle edge cases in their own way. The SBC resolves these incompatibilities through SIP header manipulation, inspecting and rewriting headers on a per-trunk-group basis so that each side receives SIP it understands.

Common normalization tasks include correcting Via and Contact headers that contain private IP addresses, remapping P-Asserted-Identity (PAI) headers for caller ID presentation, stripping proprietary extensions one side doesn’t recognize, and adjusting session timer parameters (RFC 4028) that would otherwise cause premature call drops.

Media Handling and Transcoding

The SBC controls the media plane as well as signaling. It anchors media through its own IP address, ensuring RTP packets traverse the SBC rather than flowing directly between endpoints, which is essential for encryption bridging, lawful intercept, call recording, and quality monitoring.

When two endpoints use incompatible codecs, the SBC performs media transcoding to convert between them. For IP-to-IP deployments, this can mean converting between narrowband codecs (G.711, G.729) and wideband codecs (AMR-WB, Opus) so that mobile and WebRTC endpoints can interoperate with traditional PSTN infrastructure.

Call Routing and Policy Enforcement

Beyond basic SIP routing, an SBC provides a programmable routing engine that makes decisions based on calling number, called number, time of day, trunk group utilization, and external data lookups. Call admission control prevents oversubscription by capping the number of concurrent sessions per trunk group or across the system. Least-cost routing directs calls over the cheapest available path, with automatic failover to alternate routes when a carrier is unavailable.

Advanced SBCs expose an API layer that lets operators integrate external logic (CRM lookups, number portability databases, fraud scoring engines, and billing systems) directly into the call routing decision, executed during the signaling phase so there is no impact on media quality.

Regulatory Compliance

Telecommunications is a regulated industry, and the SBC is often the enforcement point for compliance requirements. STIR/SHAKEN caller ID authentication — mandated by the FCC under the TRACED Act — requires voice service providers to cryptographically sign outbound calls and verify inbound ones. The SBC integrates with external signing services to attach or validate digital identity tokens in the SIP INVITE header.

Fraud detection capabilities allow the SBC to inspect call patterns in real time, score calls for risk, and block fraudulent traffic before it generates charges. Call detail record (CDR) generation provides the billing and audit trail that regulators and finance teams require.

Hardware SBC vs. Software SBC: The Industry Shift

For most of SBC history, the device was a proprietary hardware appliance: a purpose-built box from AudioCodes, Oracle (Acme Packet), Ribbon Communications, or Cisco, with dedicated DSP chips for transcoding and a fixed capacity ceiling determined by the hardware purchased.

That model is changing. Session border controller software that runs on standard virtual machines, cloud instances, and commodity servers now delivers the same carrier-grade security, interoperability, and routing capabilities, without the capital expenditure, hardware refresh cycles, and vendor lock-in that come with appliances.

Why Service Providers Are Moving to Software SBCs

The shift from hardware to software-based session border controllers is driven by five operational realities.

Capital versus operating expense is the most immediate driver. A hardware SBC requires a large upfront purchase, a maintenance contract, and a hardware refresh every five to seven years. A software SBC runs on infrastructure you already own or rent, with subscription pricing that scales with actual usage. For service providers managing dozens or hundreds of customers, the difference in total cost of ownership is significant.

Deployment speed matters in competitive markets. A virtual session border controller can be deployed on VMware, KVM/Proxmox, AWS, or Azure in minutes, not the weeks or months required to procure, ship, rack, and configure a hardware appliance. For MSPs onboarding new customers or ISPs responding to a carrier interconnect request, this speed translates directly to revenue.

Elastic scalability eliminates capacity planning guesswork. A cloud SBC scales session capacity up or down without swapping hardware. When traffic grows, you increase the license tier. When a project ends, you scale back. Hardware appliances offer none of this flexibility; you pay for peak capacity whether you use it or not.

Platform independence removes the single-vendor dependency that has defined the SBC market for decades. A software SBC runs on the hypervisor, cloud provider, or bare-metal server the operator chooses, and migrating between platforms doesn’t require replacing hardware.

Continuous updates close the gap between release cycles. Software SBCs receive feature updates and security patches through standard software deployment pipelines, not through hardware-tied firmware upgrades that require maintenance windows and sometimes physical access.

When Hardware Still Makes Sense

Hardware SBCs retain advantages in specific scenarios. Deployments requiring very high-density transcoding (thousands of simultaneous codec conversions between AMR-WB and G.711, for example) still benefit from dedicated DSP hardware. Some regulatory environments mandate on-premises physical appliances. And organizations with existing hardware investments may choose to run their current appliances until end-of-life before migrating to software.

The practical path for most service providers is a hybrid approach: software SBCs for new deployments, cloud instances, and elastic workloads, with hardware transcoding resources added only where codec conversion at scale demands it.

How a Session Border Controller Works in a VoIP Network

An SBC operates at the edge of a voice network, sitting between trusted internal infrastructure and untrusted external networks. In a service provider environment, this typically means one or more SBC instances positioned between the provider’s core switching platform and the outside world: carrier interconnects on one side, subscriber endpoints on the other.

The Peering SBC

A peering SBC manages the interconnection between two service providers or between a service provider and a PSTN carrier. Every call entering or leaving the network traverses this SBC. It enforces trunk-level security (TLS, SRTP, access control), normalizes SIP between the two providers’ systems, generates CDRs for inter-carrier billing, and applies call admission control to prevent any single peer from consuming more capacity than contracted.

The Access SBC

An access SBC sits between subscriber endpoints (IP phones, PBXs, contact center platforms, collaboration tools) and the service provider’s core infrastructure. It handles NAT traversal for endpoints behind customer firewalls, enforces per-subscriber session limits, bridges encryption between the subscriber’s network and the provider’s core, and provides a layer of protection against compromised or misconfigured customer equipment.

SBC VoIP Call Flow

When a call arrives at the SBC, the processing sequence follows a predictable path. The SBC first validates the source against its access control list and checks for DoS patterns. It then inspects the SIP INVITE, applying header manipulation rules for the inbound trunk group. If STIR/SHAKEN verification is configured, the SBC sends the Identity header to the verification service. The routing engine determines the outbound path based on configured rules, external data lookups, or API-driven logic. The SBC builds a new SIP INVITE for the outbound leg, applying the header manipulation rules for the destination trunk group, negotiating codecs, and establishing encryption if required. Once the called party answers, the SBC anchors media through its own address, bridging between whatever encryption and codec formats each side uses.

Throughout the call, the SBC monitors quality (MOS scores, jitter, packet loss), generates real-time statistics, and writes a CDR when the session ends.

SBC Deployment Models

Modern session border controller software supports multiple deployment models, each suited to different operational requirements.

On-Premises Virtual SBC

The SBC runs as a virtual machine on the operator’s own hypervisor (VMware ESXi, KVM, or Proxmox). This model gives the operator full control over the host hardware, the network configuration, and the data path. It is the preferred model for service providers with existing data center infrastructure, for deployments in regulated environments that require on-premises data processing, and for organizations that need to integrate the SBC with TDM equipment in the same facility.

Cloud SBC

A cloud-native session border controller runs on AWS, Microsoft Azure, or another public cloud provider. This model eliminates data center overhead entirely and enables geo-redundant deployments across multiple cloud regions for maximum resilience. Cloud SBCs are the natural fit for providers serving distributed customer bases, for CPaaS integrations where the voice platform already lives in the cloud, and for organizations that want to avoid any hardware commitment.

Bare-Metal SBC

For operators who want maximum performance without a hypervisor layer, the SBC can run directly on commodity x86 servers. This model extracts the highest possible session density from a given hardware footprint and is common in high-capacity peering deployments where every session counts.

Hybrid Deployments

Many service providers combine models: an on-premises SBC for local carrier interconnects and TDM integration, paired with cloud SBC instances for remote sites, disaster recovery, or elastic overflow capacity. The same software image and configuration syntax across all deployment models makes this practical.

Who Needs a Session Border Controller?

Any organization operating a SIP-based voice network at the boundary between two trust domains needs an SBC. Whether you’re deploying an enterprise session border controller to protect a corporate voice environment or a carrier-grade SBC to manage tens of thousands of sessions across a service provider network, the core requirements are the same: security, interoperability, and policy enforcement. In practice, four buyer segments account for the vast majority of SBC deployments.

Internet Service Providers (ISPs)

ISPs offering voice services need an SBC to interconnect with upstream carriers, protect their switching infrastructure from external threats, enforce STIR/SHAKEN compliance, and manage the SIP normalization required when aggregating traffic from multiple carrier peers. For ISPs replacing legacy platforms (OpenSIPs deployments that have grown beyond their original scope, MetaSwitch/Perimeter systems that lack DDoS mitigation, or end-of-life hardware from Ribbon or Oracle), a software SBC provides a modern, cost-effective replacement path.

Managed Service Providers (MSPs)

MSPs delivering hosted voice, UCaaS, or Microsoft Teams Direct Routing to business customers need an SBC as the central point of traffic management and security. A single SBC deployment can serve dozens or hundreds of end customers, with per-tenant trunk groups, routing rules, and security policies. The SBC also enables the MSP to offer value-added services (call recording, fraud protection, compliance enforcement) that differentiate their offering from commodity voice resale.

UCaaS and CCaaS Platform Vendors

Software vendors building unified communications or contact center platforms need an SBC to handle the SIP trunking, security, and interoperability layer so their development teams can focus on application logic rather than carrier integration. In CPaaS and BYOC architectures, where the platform integrates with Twilio, RingCentral, Genesys, or similar, the SBC normalizes traffic from multiple carriers and provides the security perimeter the platform itself doesn’t include.

Contact Centers

Contact center operations, whether on-premises or migrating to cloud platforms like Genesys Cloud, Five9, or NICE, deploy SBCs to secure their voice infrastructure, manage high concurrent session counts, ensure quality of service for customer-facing calls, and maintain compliance with recording and audit requirements. For BYOC (Bring Your Own Carrier) cloud contact center deployments, the SBC is the bridge between the organization’s chosen carriers and the cloud platform.

Key Session Border Controller Features to Evaluate

When comparing SBC vendors, these are the capabilities that most directly affect production reliability, operational cost, and long-term flexibility.

B2BUA Architecture

A full B2BUA implementation, where the SBC terminates and re-originates both signaling and media on each leg, is non-negotiable for production deployments. A SIP proxy cannot perform header manipulation, independent per-leg encryption, topology hiding, or media anchoring. If the SBC you’re evaluating operates as a proxy rather than a B2BUA, it cannot deliver the security and interoperability functions described in this guide.

Security Depth

Look beyond checkbox claims. Evaluate whether the SBC provides real-time DoS/DDoS mitigation (not just rate limiting), dynamic blacklisting that reacts to traffic patterns automatically, SIP registration scanning protection, and granular access control lists at the trunk-group level. Encryption support should include TLS for signaling and SRTP for media, with the ability to bridge between encrypted and unencrypted legs transparently.

SIP Header Manipulation Engine

The quality of the SBC’s header manipulation engine determines how effectively it handles multi-vendor environments. Evaluate whether rules can be applied per trunk group, whether the engine supports regex-based pattern matching, and whether it can handle complex transformations like conditional header insertion based on call parameters.

API and Programmability

A modern SBC should expose a REST API for configuration management, status monitoring, and CDR retrieval. Beyond that, evaluate whether the SBC supports programmable routing: the ability to execute custom logic (external HTTP lookups, database queries, fraud scoring) during the signaling phase of every call. This capability transforms the SBC from a static policy enforcement device into a programmable edge that adapts to business requirements in real time.

Deployment Flexibility

Confirm that the SBC runs on the platforms your infrastructure uses today and may use tomorrow: VMware, KVM/Proxmox, AWS, Azure, and bare metal. A software SBC that ties you to a single hypervisor or cloud provider introduces the same kind of vendor lock-in that hardware appliances impose.

High Availability

For production voice infrastructure, 1+1 active/standby high availability is a baseline requirement. Evaluate how failover works, what state is preserved during failover, and whether HA is available at all deployment sizes, not just for enterprise-tier licenses.

Pricing Model

Hardware SBCs carry large upfront capital costs plus annual maintenance. Software SBCs typically use subscription pricing (per session, per server, or per month). Evaluate the total cost of ownership over three to five years, including support contracts, HA licensing, and add-on features. Transparent, published pricing is a strong signal that the vendor is confident in their value proposition.

STIR/SHAKEN Integration

With FCC rules now requiring providers to sign calls using their own STIR/SHAKEN certificates, evaluate how the SBC integrates with signing services. An open integration model, where the SBC works with any third-party signing service (TransNexus, Neustar, and others) rather than locking you to a vendor-chosen partner, provides the flexibility to switch providers if pricing or capabilities change.

Capability	Hardware SBC	Software SBC
Deployment speed	Weeks to months	Minutes to hours
Elastic scalability	Fixed by hardware	Scale on demand
Pricing model	Large CAPEX + maintenance	OPEX subscription
Platform choice	Vendor hardware only	VMware, KVM, AWS, Azure, bare metal
High availability at small scale	Often enterprise-tier only	Available at all tiers
Hardware transcoding	Built-in DSP	External DSP or software (codec-dependent)
Update cycle	Firmware + maintenance windows	Standard software deployment

Frequently Asked Questions

What is a session border controller in simple terms?

A session border controller is a specialized device or software that sits at the edge of a voice network and controls every call that crosses the boundary. It secures the network against attacks, translates between different SIP implementations so incompatible systems can communicate, encrypts voice traffic, and enforces routing and billing policies. Think of it as the security guard, translator, and traffic controller for your voice infrastructure, all in one.

What is the difference between an SBC and a firewall?

A firewall operates at the network layer: it filters packets based on IP addresses, ports, and protocols. An SBC operates at the application layer: it understands SIP signaling and RTP media, can inspect and modify the content of voice sessions, enforce call-specific policies, and bridge between different encryption standards. A firewall cannot perform SIP normalization, media transcoding, topology hiding, or call admission control. In production voice networks, both are required: the firewall for general network security, the SBC for voice-specific security and interoperability.

Do I need an SBC for Microsoft Teams?

Yes, if you are using Direct Routing to connect Teams to your own SIP trunks. Microsoft requires a certified or compatible SBC that supports TLS 1.2 for signaling, SRTP for media, FQDN-based configuration, and SIP OPTIONS heartbeats. The SBC handles the protocol translation between your carrier’s SIP and Teams’ SIP dialect, the encryption bridging between carrier RTP and Teams SRTP, and the header normalization that Teams requires. Without an SBC, Direct Routing does not function.

What is the difference between a hardware SBC and a software SBC?

A hardware SBC is a proprietary appliance with fixed capacity and dedicated DSP chips. A software SBC runs on virtual machines, cloud instances, or commodity servers, offering subscription pricing, elastic scalability, and deployment flexibility. Both provide the same core SBC functions: security, interoperability, routing, and compliance. The choice depends on your infrastructure model, budget preference (CAPEX vs. OPEX), and whether you need hardware-accelerated transcoding at high scale.

How many sessions can a software SBC handle?

Modern carrier-grade software SBCs can handle tens of thousands of concurrent sessions on a single server instance. Actual capacity depends on the server’s CPU and memory resources, whether transcoding is active, and the complexity of routing logic applied per call. For deployments requiring more capacity, multiple SBC instances can be deployed behind a load balancer or in a clustered configuration.

Is an SBC required for STIR/SHAKEN compliance?

The FCC requires voice service providers to sign outbound calls and verify inbound calls using the STIR/SHAKEN framework. The SBC is the most common enforcement point for this requirement because it already processes every SIP INVITE at the network edge. The SBC integrates with an external signing service to attach cryptographic identity tokens to outbound calls and to verify tokens on inbound calls. Providers must now use their own STIR/SHAKEN certificates for signing, rather than relying on a third party’s certificate.

Further Reading

To explore how a software SBC transforms cloud communications architectures, from elastic scalability and geo-redundant high availability to media bypass and CPaaS integration, read our in-depth guide on SBC for Cloud Communications.

To understand how Microsoft Teams Direct Routing connects Teams to the PSTN through an SBC, including the TLS, SRTP, and SIP normalization requirements that make it work, read our detailed walkthrough on What Is Teams Direct Routing?.

Deploy a Software SBC with ProSBC

ProSBC is a carrier-grade, software-based session border controller built for service providers. It delivers the full B2BUA architecture, SIP header manipulation engine, DoS/DDoS protection, dynamic blacklisting, and programmable routing capabilities discussed throughout this guide, running on VMware, KVM/Proxmox, AWS, Azure, or bare metal with subscription pricing starting from $1.25 per session per year.

ProSBC supports Microsoft Teams Direct Routing, integrates with STIR/SHAKEN signing services including TransNexus ClearIP, and exposes a REST API and Ruby-based routing scripts for custom call logic. High availability (1+1 active/standby) is available at every deployment size, and the ProSBC Lab, a permanent, free 3-session license that lets you test the full feature set in your own environment before committing.

For operators who prefer not to manage the SBC themselves, the ProSBC Managed Service provides a fully managed deployment with 1+1 HA, 24/7 support, and end-to-end setup, hosted on your chosen platform or by TelcoBridges.