.png?width=141&height=141&name=Transact%20(1).png)
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
%201.svg){kind=small}
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.
What is a session border controller and how does it work?
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:
- The signalling that sets up and manages a call
- The media packets, consisting of actual voice or video packets, typically carried over RTP
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.
Why are session border controllers important?
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.
- They hide internal topology so attackers can't map your network from call signalling.
- They encrypt signalling and media using TLS and SRTP, keeping conversations confidential in transit.
- They defend against denial-of-service and distributed denial-of-service (DoS/DDoS) attacks by rate-limiting and filtering malformed or malicious traffic before it overwhelms your call servers.
- They guard against toll fraud, one of the costliest VoIP threats, by enforcing call admission policies that stop unauthorised or anomalous calling patterns.
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.
Core functions of a session border controller
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.
Call Admission Control (CAC)
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.
Network Address Translation (NAT) traversal
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.
Protocol normalisation
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.
SIP interoperability and protocol interworking
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.
Media transcoding and codec translation
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.
Session routing and least-cost routing
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.
Signalling and media encryption
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.
Enterprise Session Border Controller (E-SBC) vs. Service Provider SBC
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 |
Key differences in architecture and scale
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.
Common enterprise deployment scenarios
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.
Service provider SBC use cases
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.
SBC or SBCaaS?
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.
Session border controllers and Microsoft Teams
For most enterprises today, the SBC conversation starts with Microsoft Teams.
Direct Routing architecture overview
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.
SBC certification requirements
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.
Common Teams integration challenges
Frequent issues include:
- Certification or firmware mismatches
- Codec negotiation failures between Teams and the carrier
- One-way audio caused by NAT or media-path problems
- Registration or transport-layer security errors
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 and session border controllers
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.
Call quality issues and packet loss
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.
Capacity and scalability constraints
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.
Monitoring and managing SBC performance
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.
Key SBC metrics to monitor
A focused monitoring strategy tracks:
- Concurrent and peak session counts against licensed capacity
- SIP registration success and failure rates
- SIP response codes, especially 4xx and 5xx errors
- Call setup and completion (answer-seizure) rates
- Media quality indicators: Mean Opinion Score (MOS), jitter, latency, and packet loss
- Transcoding load and codec usage
- Underlying CPU, memory, and interface utilisation
Detecting SIP and media stream issues before users are impacted
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.
Multi-vendor unified communications visibility
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.
How to choose the right session border controller strategy
Selecting an SBC is as much about how you will run it as which features it comes with.
Enterprise requirements checklist
- Which platforms does it need to connect? Teams, Cisco, Avaya, Zoom, contact centre, carriers?
- What concurrent and peak session volumes must it support, with room for growth?
- Is it certified for the integrations you depend on, particularly Teams Direct Routing?
- Hardware, software, or cloud-based — which best fits your scale, budget, and deployment model?
- How will you monitor and assure its performance once it's live?
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.
Why SBCs remain critical for secure enterprise communications
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.
See how IR helps organisations monitor and optimise session border controller performance
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.
Frequently asked questions
What is a session border controller (SBC)?
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.
How does an SBC work?
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.
Why is an SBC important for VoIP security?
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.
What is the difference between an enterprise SBC and a service provider SBC?
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.
Does Microsoft Teams require a session border controller?
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.
What is SBC protocol normalisation?
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.
How does an SBC support NAT traversal?
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.
Can an SBC prevent DDoS attacks?
Yes. SBCs rate-limit and filter signalling and media traffic, dropping malformed or malicious packets to protect call infrastructure from denial-of-service attacks.
What metrics should organisations monitor on an SBC?
Concurrent sessions versus capacity, SIP registration and error rates, call success rates, media quality (MOS, jitter, latency, packet loss), and transcoding and resource utilisation.
How does SBC monitoring improve user experience?
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.
