Every voice, video, and messaging session that crosses the edge of your network is not only a potential point of failure, but also a potential way in for attackers.
As enterprises move communications onto multi-vendor unified communications (UC) platforms, the device that controls IP communications sessions has become mission-critical. A session border controller (SBC) controls and protects core network borders. In this guide, we'll explain what an SBC is, how it works, why it matters for security, and how to monitor and optimise SBC performance once it's live.
An SBC is a hardware or software solution that regulates IP communication flows. It manages, secures, and optimises voice, video, and real-time communications sessions as they cross network boundaries. SBCs redirect media traffic to help with quality consistency, alleviating missed or dropped calls, poor call quality, or both.
SBCs route sessions across network interfaces to ensure high availability or enable least cost routing (LCR). They also control VoIP networks, protecting them from threats, and enable interoperability between disparate systems, keeping communications reliable across both enterprise and service provider networks.
Real-time communications travel in two parts:
An SBC sits at the border between two networks and controls both streams, regulating IP communication flows. When a call attempts to cross that boundary — for example, from your internal UC platform out to a SIP trunk provider — the SBC inspects the signalling, decides whether to admit the session, and then manages the media path for its full duration.
A session border controller acts as a back-to-back user agent, terminating each session on one side and re-originating it on the other. This gives it full control to authenticate traffic, hide internal network topology, fix protocol mismatches, and apply policy before anything reaches your core infrastructure.
In practice, SBCs are deployed at the edge of VoIP and unified communications networks: between an enterprise and its carrier, between two carriers at an interconnect, or between a UC platform like Microsoft Teams and the public telephone network.
A Session Initiation Protocol (SIP)-based network exposed directly to the internet is an open target. SBCs are the primary security control at the communications perimeter, and their importance comes down to a few protections working together.
Without an SBC, every one of these risks lands directly on your PBX or UC platform, which was never designed to act as a security gateway.
Beyond acting as a security gateway, an SBC performs a set of functions that keep real-time communications working reliably across networks that were never designed to talk to each other.
CAC governs how many simultaneous sessions an SBC will allow across a given interface or trunk. By capping concurrent calls at a level the network can comfortably carry, it prevents the bandwidth over-subscription that causes choppy audio and dropped calls during busy periods.
Policies can be set per trunk, per site, or per codec, giving you a predictable ceiling rather than letting peak demand quietly degrade quality for everyone.
Most endpoints sit behind firewalls and routers that use network address translation, rewriting private IP addresses into public ones.
SIP and RTP were not designed with NAT in mind, so without help, signalling and media can frequently break down, often showing up as one-way or no audio. The SBC resolves this by anchoring the media, correcting address information inside the signalling, and maintaining the pinholes that keep sessions connected across the boundary.
No two vendors implement SIP in exactly the same way. SBCs enable interworking between diverse protocols.
Header ordering, optional fields, and message structure vary enough to cause interoperability failures. Protocol normalisation rewrites and standardises SIP messages in real time, so that a Cisco environment and a carrier's softswitch, or Teams and a legacy PBX, can exchange calls without manual reconfiguration on either side.
Closely related, protocol interworking bridges more complex differences between SIP variants, between SIP and older signalling such as H.323, and between transport options like UDP, TCP, and TLS.
This is what lets a single call flow connect modern UC platforms to legacy systems and diverse carrier networks without the need to re-engineer your network.
When the two ends of a call don't share a common codec, the SBC transcodes the media on the fly so the call still connects with usable quality. Transcoding is resource-intensive, which is why available transcoding capacity is a key sizing decision and a metric worth watching in production.
SBCs make policy-based routing decisions such as directing calls to the correct trunk, failing over to a backup path when a route is unavailable, and selecting the lowest-cost carrier for a given destination. For organisations with high outbound volumes, least-cost routing alone can deliver meaningful and ongoing savings.
To keep communications private and tamper-resistant, SBCs encrypt signalling with TLS and media with SRTP. Beyond confidentiality, this protects against eavesdropping and call manipulation, and encryption at the border is increasingly a baseline compliance requirement in regulated sectors such as finance and healthcare.
SBCs fall into two broad categories that differ in scale, placement, and purpose. Service provider SBCs are typically deployed at access, core, and interconnect network borders, while enterprise SBCs are used at the edge of the enterprise network, often as the termination point for SIP trunking services.
The SBC can also serve as a firewall for session traffic, applying its own QoS rules and identifying specific incoming threats to the communications environment — in effect controlling SIP by admitting or denying, then directing, communications between multiple parties and devices.
| Enterprise SBC | Service provider SBC | |
|---|---|---|
| Sits between | Corporate UC and the SIP trunk/carrier | Carrier networks at access and peering points |
| Scale | Hundreds to thousands of sessions | Hundreds of thousands to millions of sessions |
| Primary goal | Secure interoperability for one organisation | High-volume routing, peering, and access control |
| Typical buyer | IT and communications teams | Telecom operators and ISPs |
An enterprise SBC is optimised for secure interoperability at the edge of one organisation, prioritising flexible vendor integration and manageability. A service provider SBC is engineered for throughput and resilience at carrier scale, where redundancy is non-negotiable. The underlying functions overlap, but the engineering trade-offs — capacity, hardware acceleration, and high-availability design — are very different.
Typical enterprise use cases include Microsoft Teams Direct Routing, securing SIP trunks to a chosen carrier, connecting a contact centre to the PSTN, and joining multiple sites or a hybrid on-premises and cloud estate. In each case, the SBC provides the security boundary and the translation layer that lets a mixed-vendor environment behave as one coherent system.
Carriers deploy SBCs as access points that sit between the network and subscribers, and as the control point for hosted and wholesale UC services. Here the SBC enforces commercial routing policy, protects core infrastructure at scale, and maintains service quality across millions of sessions.
Deciding which option suits your enterprise network comes down to your organisation's philosophy on in-house management, internal IP networks, outsourcing, and use of cloud media services.
For most enterprises today, the SBC conversation starts with Microsoft Teams.
Direct Routing connects Teams to the public telephone network through your own carrier, rather than buying calling plans from Microsoft.
The SBC sits between Teams and your SIP trunk, terminating the connection on the Teams side and re-originating it toward the carrier. This gives organisations freedom to choose their telephony provider, retain existing contracts, and keep PSTN connectivity under their own control.
Microsoft maintains a list of SBCs certified for Direct Routing. Certification covers the specific firmware versions, signalling behaviour, and security configuration that Teams expects. Attempting to connect uncertified equipment is a common source of subtle, hard-to-diagnose failures.
Frequent issues include:
Because the fault can lie on either the Teams side, the SBC, or the carrier, these problems are notoriously difficult to isolate without visibility across the full path — this is where monitoring and observability becomes mission-critical.
Find out more about the importance of monitoring and observability in our comprehensive guide: Monitoring to Observability: A Complete Guide for Enterprise Systems in 2026
SIP trunking is what the SBC ultimately protects and optimises.
A SIP trunk replaces traditional phone lines with VoIP protocols. While flexible and cost-effective, VoIP calls are also internet-facing, which makes them a target for fraud, eavesdropping, and DoS attacks.
An SBC authenticates and encrypts the trunk, hides internal topology, and applies admission control — turning an exposed IP connection into a defended, policy-controlled boundary.
Jitter, latency, and packet loss are the usual culprits behind degraded calls, and they are often intermittent — tied to congestion, routing changes, or capacity peaks. Because the symptoms come and go, they are easy to dismiss and hard to reproduce without continuous quality measurement.
The continuing growth of VoIP networks pushes SBC requirements further to the edge, mandating adaptation in capacity and complexity as traffic volume increases. Every SBC has finite session and transcoding capacity, governed by licensing and hardware.
Hitting those limits during peak periods leads to rejected calls and degraded quality, often with little warning unless utilisation is tracked against capacity over time.
Vendors are addressing new scale requirements by developing separate load balancing systems to sit in front of SBC clusters, or by using new architectures with advanced chipsets for higher performance and scalability.
This is where most SBC guidance stops short — and where operational excellence is won or lost.
An SBC is a real-time, high-throughput security and routing device, and can't be regarded as set-and-forget. SBCs are a critical element of network performance, and a lack of adequate monitoring guarantees you will learn about failures from frustrated users rather than from your own systems.
A focused monitoring strategy tracks:
The real value of monitoring is proactive insight rather than reactive troubleshooting. Observability across signalling, media, and the surrounding infrastructure ties SBC performance directly to business outcomes: call quality, customer experience, and service reliability.
Few enterprises run a single-vendor IT infrastructure. A typical environment spans Teams, Cisco, Avaya, Zoom, and several carriers, and a fault can originate anywhere along that chain. Visibility confined to one vendor's management console leaves blind spots exactly where multi-vendor calls break.
End-to-end visibility across signalling and media — including VoIP traffic, instant messaging, and team collaboration — is what makes root-cause analysis possible.
Selecting an SBC is as much about how you will run it as which features it comes with.
Security considerations: Confirm the SBC provides TLS and SRTP encryption, topology hiding, toll-fraud prevention, and DoS/DDoS protection appropriate to your exposure.
Scalability and high availability requirements: Size for peak demand, plan for high availability, and account for transcoding load separately from raw session counts.
Operational monitoring requirements: Treat monitoring as a selection criterion, not an afterthought. Ask how you will gain real-time, multi-vendor visibility into performance, how issues will be detected proactively, and how quickly you could isolate a fault.
Session border controllers are the cornerstone of secure, interoperable enterprise communications, and as UC environments grow more complex, their role only deepens. But choosing and deploying the right SBC is only part of the job. Sustained call quality, security, and reliability depend on continuous monitoring and observability across the whole communications chain — that's how organisations turn a significant deployment investment into dependable, business-grade communications, and catch problems before users ever notice them.
IR brings nearly four decades of communications performance expertise and a vendor-independent view across complex, multi-vendor UC environments. If you want to move beyond deploying SBCs to confidently monitoring, troubleshooting, and optimising them in production, see how IR's observability and service-assurance capabilities help keep your enterprise communications secure and reliable.
An SBC is a hardware or software solution that manages, secures, and optimises voice, video, and real-time communications sessions as they cross network boundaries, protecting VoIP environments and enabling interoperability between different systems.
It sits at the border between two networks and controls both the SIP signalling and the RTP media of each session. Acting as a user agent server and a user agent client, it terminates a session on one side and re-originates it on the other, applying security, policy, and protocol fixes in between.
It acts as the security gateway for real-time communications — hiding network topology, encrypting traffic, blocking DoS/DDoS attacks, and preventing toll fraud before threats reach your call servers.
An enterprise SBC secures interoperability for a single organisation at modest session volumes, while a service provider SBC is engineered for carrier-scale throughput, peering, and access control across very large session counts.
Yes, if you use Direct Routing to connect Teams to the PSTN through your own carrier. A Microsoft-certified SBC is required to bridge Teams and your SIP trunk.
It's the process of rewriting and standardising SIP messages in real time so that equipment from different vendors, which implement SIP slightly differently, can exchange calls without manual reconfiguration.
It anchors media and corrects address information inside the signalling so that calls connect reliably across networks using network address translation, preventing the one-way or no-audio problems NAT otherwise causes.
Yes. SBCs rate-limit and filter signalling and media traffic, dropping malformed or malicious packets to protect call infrastructure from denial-of-service attacks.
Concurrent sessions versus capacity, SIP registration and error rates, call success rates, media quality (MOS, jitter, latency, packet loss), and transcoding and resource utilisation.
By surfacing quality degradation and signalling errors as trends before they become outages, monitoring lets teams fix issues proactively, so users experience consistent call quality instead of reporting problems after the fact.