A Session Border Controller (SBC) is the bridge between Microsoft Teams Phone and the public switched telephone network (PSTN). It's the piece of infrastructure that makes Direct Routing work — and if it's not configured correctly, your users can't make calls.

This guide covers SBC architecture, vendor selection, configuration steps, certificate management, firewall requirements, and testing. It's written for telecom architects and IT engineers who need to understand the technical scope of a Direct Routing deployment.

What Is a Session Border Controller?

An SBC is a network device or software that sits at the boundary between two voice networks — in this case, between Microsoft Teams (in the cloud) and your SIP trunk (to your carrier or the PSTN). The SBC handles:

Without an SBC, Teams Phone cannot connect to a third-party SIP trunk. The SBC is mandatory for Direct Routing.

Microsoft-Certified SBC Vendors

Microsoft certifies specific SBC vendors for Direct Routing compatibility. Not every SBC works with Teams — only certified models from approved vendors. As of 2026, the primary certified vendors are:

AudioCodes — Mediant VE (virtual), Mediant 8000/9000 (appliance), Mediant 3000 (enterprise). AudioCodes is one of the most popular SBC vendors for Teams Direct Routing, with strong analog device support (MP-1xx ATAs), intuitive management interface, and deep Microsoft integration. Best for: enterprises with analog infrastructure, mid-to-large deployments.

Ribbon (formerly Sonus) — SWe Lite (virtual, small), SWe Standard (virtual, mid), SBC 1000/2000 (appliance). Ribbon has excellent SIP normalization capabilities, strong HA architecture, and is widely deployed in enterprise Teams environments. Best for: enterprises prioritizing HA and SIP normalization.

Oracle (Acme Packet) — Session Border Controller 1100/3900/4600. Enterprise-grade, complex, powerful. More common in large carrier environments than enterprise Teams deployments. Best for: very large enterprises with existing Oracle infrastructure.

TE-Systems (anynode) — Software-based SBC running on Windows Server. Flexible, cost-effective, good for smaller deployments. Best for: budget-conscious deployments comfortable with Windows-based infrastructure.

Telcobridges (ProSBC) — Virtual SBC with strong Teams Direct Routing support. Good value proposition. Best for: mid-size enterprises looking for cost-effective SBC.

For most enterprises, the choice comes down to AudioCodes vs Ribbon. Both are excellent, both are Microsoft-certified, and both support all Direct Routing requirements. The decision factors are:

Architecture: Active-Active High Availability

For enterprise deployments, single-SBC architecture is not acceptable. A single SBC is a single point of failure — if it goes down, all voice traffic stops. The enterprise standard is active-active HA with dual-region deployment:

Two SBCs, two regions. Deploy one SBC in your primary data center (or Azure region) and a second SBC in a secondary region. Both SBCs are active — they both handle call traffic simultaneously. If one fails, the other takes over immediately.

DNS configuration. The SBC FQDN (e.g., sbc.cutoverpartners.com) resolves to both SBC IP addresses. Teams connects to whichever SBC responds. If one SBC is down, DNS health checks remove it from rotation.

SIP trunk configuration. Your SIP trunk provider routes calls to both SBCs. Inbound calls can arrive at either SBC; outbound calls go out through either SBC. Your carrier should support dual-SBC registration or IP-based routing.

Failover behavior. When an SBC fails, active calls on that SBC drop (this is a limitation of SIP — active calls don't survive SBC failover). But new calls immediately route to the surviving SBC. The outage window is seconds, not minutes.

Geographic redundancy. If your primary data center loses connectivity, the secondary region SBC continues handling all calls. This is why dual-region (not just dual-SBC in one data center) is the enterprise standard.

SBC Configuration Steps (High-Level)

This is an overview — not a replacement for vendor-specific documentation. Every SBC vendor has different configuration interfaces, but the steps are conceptually the same:

1. Certificate procurement. Your SBC needs a TLS certificate from a trusted Certificate Authority. Microsoft requires specific CAs (check the current list in Microsoft's Direct Routing documentation). The certificate's CN or SAN must match your SBC's FQDN (e.g., sbc.cutoverpartners.com).

2. SIP signaling configuration. Configure the SBC to listen for TLS-encrypted SIP from Microsoft 365 on port 5061. The SBC must present its certificate during the TLS handshake. Microsoft's SIP proxy IPs are published and must be allowed through your firewall.

3. Media configuration. Configure the SBC to use SRTP (encrypted media) for Teams-facing traffic. Media ports must be configured to match Microsoft's expected ranges. Your firewall must allow UDP media traffic from Microsoft 365 IP ranges to the SBC.

4. Dial plan and voice routing policy in Teams. In the Teams admin center (or via PowerShell), configure:

5. PSTN trunk configuration on the SBC. Configure your SIP trunk to your carrier on the SBC — SIP signaling (TCP/TLS or UDP), media (RTP), codec preferences (G.711, G.722), and DTMF relay. This is the carrier-facing side of the SBC.

6. SBC pairing with Teams. In the Teams admin center, add your SBC FQDN. Teams validates the certificate and establishes a SIP signaling connection. The SBC should show as "Active" in the Teams admin center.

CA Trust-Store and Certificate Management

Microsoft's Direct Routing infrastructure uses specific Root CAs. As of 2026, Microsoft uses the RSA Root CA 2017 (and previously the Baltimore CyberTrust Root). Your SBC's trust-store must include the correct Root CA, and your SBC certificate must be signed by a CA in Microsoft's trusted list.

Common trust-store issues:

Best practice: Set up certificate expiration monitoring. When your SBC certificate is 30 days from expiration, renew it. A lapsed certificate means no calls — for everyone.

We offer a free SBC trust-store audit that checks your certificate validity, trust chain, TLS configuration, and security posture.

Firewall and Network Requirements

Microsoft publishes the IP ranges and ports required for Direct Routing. Your firewall must allow:

SIP signaling (inbound from Microsoft 365 to SBC):

Media (inbound from Microsoft 365 to SBC):

SIP trunk (between SBC and your carrier):

NAT considerations. If your SBC is behind NAT (common in virtual deployments), ensure NAT traversal is configured correctly. The SBC's advertised IP in SIP messages must match the public IP that Microsoft 365 connects to.

QoS. For voice quality, implement DSCP marking (EF for voice, CS3 for signaling) on your network. Tag media traffic at the SBC and prioritize it on your switches and routers.

Testing and Validation

Before production cutover, validate every call path:

SBC connectivity test. In the Teams admin center, run the SBC connectivity test. This validates that Teams can reach your SBC, the certificate is valid, and SIP signaling is established.

Test call flows:

E911 test. Call your PSAP's non-emergency line and ask to perform a 911 test call. Verify that the PSAP receives your dispatchable location (building, floor, room). This is the one test you cannot skip.

Failover test. Simulate an SBC failure (power off or block traffic) and verify that calls failover to the secondary SBC. Measure the failover time.

When to Call a Specialist

Setting up an SBC for Direct Routing is a well-documented process — Microsoft's documentation is thorough, and vendor documentation covers the specifics. If you have an experienced telecom engineer on staff, a straightforward deployment is achievable.

But for enterprises with any of these complexities, a specialist is worth it:

The cost of getting it wrong — dropped calls, E911 failures, cutover disasters — is far higher than the cost of getting it right the first time.

Get a free SBC trust-store audit or talk to us about your Direct Routing deployment.