Become a Microsoft Teams Direct Routing Provider: The SBC Requirements

Every enterprise running Microsoft Teams Phone eventually asks the same question: who is going to connect it to the phone network, and at what price? For managed service providers, ISPs, and carriers, that question is an opening. Instead of watching customers pay Microsoft Calling Plan rates or hand their voice to an Operator Connect carrier, you can deliver PSTN connectivity yourself using your own numbers, your own rates, and your own routing. That is what becoming a Microsoft Teams Direct Routing provider means.

The whole model turns on one piece of infrastructure: a Session Border Controller (SBC). Microsoft does not connect Teams to a carrier directly. It requires a supported SBC to sit at the border, terminating the Teams trunk on one side and your carrier trunk on the other, and Teams simply refuses to connect to an SBC that does not meet its technical bar for encryption, SIP normalization, and health signaling. This guide is about that bar. If you already understand what Teams Direct Routing is, the next step is knowing exactly what the SBC has to do to serve Direct Routing as a business and how to scale it across many customer tenants. The commercial side, how to price, package, and sell the service, is covered separately in the MSP managed-service playbook.

Why Offer Teams Direct Routing as a Service?

Microsoft gives enterprises three ways to connect Teams Phone to the outside world, and two of them leave money and control on the table for the customer. Microsoft Calling Plans bundle minutes at Microsoft’s rates with no carrier choice. Operator Connect limits customers to carriers inside Microsoft’s program. Direct Routing is the open path: any carrier, any rates, full routing control, delivered through an SBC. For a detailed breakdown of how the three models compare, see Operator Connect versus Teams Direct Routing.

That open path is where a provider inserts itself. If you already run SIP trunks, wholesale minutes, or a hosted PBX business, Direct Routing lets you attach Teams voice to what you already sell. Across the North American market, Teams Direct Routing is the single most common reason a managed service provider goes shopping for an SBC in the first place. The customer wants Teams calling, they do not want to run their own SBC, and they would rather buy voice from a provider they already trust than from Microsoft.

Who Becomes a Direct Routing Provider

• Managed service providers add Teams calling to an existing stack of FreePBX, 3CX, or NetSapiens customers, delivering voice to dozens or hundreds of business clients from one platform. See how MSPs evaluate an SBC for the buyer’s view.
• ISPs and carriers already own the SIP trunks and the numbering, so Direct Routing is a way to move up the value chain from wholesale connectivity into a retail Teams service.
• Contact-center and CPaaS operators use the same SBC to deliver Bring Your Own Carrier paths into Teams alongside their other platforms.

Three Ways to Deliver Direct Routing

Before looking at the SBC itself, decide which delivery model you are building. The choice shapes how much of the platform you run and what your customers touch.

Model	Who runs the SBC	Best fit	Multi-tenant
Direct Routing as a Service	Provider hosts	MSPs serving many SMB tenants	Required
Customer-hosted, provider-managed	Customer’s cloud, you operate	Larger tenants with compliance needs	Per deployment
Self-hosted by the enterprise	Customer runs it	Single large enterprise, in-house voice team	Single tenant

Most providers building a repeatable business land on the first model, delivering Direct Routing as a Service from a shared, multi-tenant SBC. It carries the lowest per-customer cost and the fastest onboarding, because a new tenant is a configuration change rather than a new deployment. The middle model suits customers who need the SBC inside their own cloud account for data-residency or compliance reasons while still leaving day-to-day operation to you. This is a technical hosting choice; the commercial trade-off between running the SBC yourself and reselling a managed one is weighed in the MSP managed-service playbook. Whichever model you choose, the SBC requirements below apply.

What Microsoft Requires from a Direct Routing SBC

Microsoft publishes a set of technical requirements that every Direct Routing SBC has to satisfy, and Teams simply refuses to connect to an SBC that does not meet them. As a provider you meet these once, correctly, and then reuse the same configuration for every tenant you onboard.

A Supported SBC and a Registered FQDN

Microsoft maintains a list of SBCs validated for Direct Routing, and your SBC must either be on that list or otherwise satisfy the Direct Routing interface Teams expects. Each SBC needs a publicly resolvable Fully Qualified Domain Name registered in Teams Admin Center, which Teams uses for SIP routing and to validate the TLS certificate. Bare IP addresses are not accepted.

TLS for SIP Signaling

All SIP signaling between Teams and your SBC has to use Transport Layer Security, with a certificate from a Microsoft-trusted Certificate Authority whose Subject Alternative Name matches the SBC FQDN. Because Teams and the SBC authenticate each other, this is effectively a mutual-trust relationship, and the certificate chain has to stay valid over time. Microsoft periodically updates the CA roots it trusts for Direct Routing, so keeping the certificate current is part of running the service.

SRTP for Media Encryption

Teams accepts only encrypted media, so all RTP from the SBC has to be Secure RTP. Many carriers still deliver unencrypted RTP, which means your SBC converts transparently between the two formats, handling key exchange on each leg independently so neither the carrier nor Teams has to change anything.

The SIP OPTIONS Heartbeat

Teams sends periodic SIP OPTIONS requests to confirm the SBC is alive, and the SBC has to answer each one with a 200 OK. A missed or delayed response causes Teams to mark that trunk offline, and for a multi-tenant provider a single misconfiguration can affect the tenant that shares it. Missed OPTIONS responses are the most common root cause behind “SBC shows offline” tickets, a pattern covered in depth in the Direct Routing troubleshooting guide.

SIP Message Compatibility

Teams speaks a specific SIP dialect, and headers or bodies common in traditional carrier SIP such as certain P-headers or proprietary extensions may be rejected. Your SBC normalizes on both legs, stripping or remapping what Teams will not accept inbound and translating Teams SIP for your carrier outbound.

What a Provider-Grade SBC Needs Beyond the Minimum

Meeting Microsoft’s requirements gets one tenant connected. Running a Direct Routing business across many tenants demands more from the SBC, and this is where the choice of platform separates a viable service from a support burden.

Multi-Tenancy and Per-Tenant Isolation

A provider SBC has to serve many customers from one instance while keeping each tenant’s routing, numbering, and traffic logically separate. The practical mechanism is per-trunk-group configuration: every tenant gets its own trunk group with its own SIP rules and its own routing, and a base FQDN with per-tenant subdomains lets Teams address each one. The architecture behind this is covered in multi-tenant SBC for Teams Direct Routing. Without solid multi-tenancy, every new customer becomes a fresh deployment and the economics never work.

Trunk Group and Session Scale

Confirm the SBC’s ceiling on concurrent sessions, trunk groups, and endpoint registrations against your growth plan, not just today’s customer count. A platform that supports on the order of a thousand trunk groups and tens of thousands of concurrent sessions per instance gives a provider real headroom to add tenants without re-architecting.

B2BUA Architecture

A Back-to-Back User Agent (B2BUA) fully terminates the SIP session on one leg and re-originates a new one on the other, giving the SBC complete control over every message in both directions. A plain SIP proxy passes messages through with limited ability to modify them, which is a hard limit when you need to strip proprietary headers from a carrier before they reach Teams or adjust identity headers per tenant. B2BUA architecture is what enables deep header manipulation, independent encryption per leg, and topology hiding, and the difference is explained further in what an SBC is and does.

Configurable SIP Header Manipulation

Different carriers and different tenants need different SIP treatment, so a rule-based header manipulation engine, configurable per trunk group, is essential. The more configurable the engine, the easier it is to onboard a carrier with an unusual SIP implementation or a tenant with specific caller-ID presentation rules, without touching anyone else’s configuration.

Security at the Edge

Your SBC faces the internet on the carrier side, which makes it a target. Built-in DoS and DDoS mitigation, SIP registration scanning protection, and dynamic blacklisting of IP ranges or number patterns are baseline expectations for internet-facing voice infrastructure. For a provider delivering Direct Routing to paying customers, per-call fraud scoring matters too, because toll fraud on a shared platform becomes your billing exposure across every tenant at once.

High Availability

When one enterprise runs its own SBC, an outage affects one company. When a provider runs a shared SBC, an outage affects every tenant on it. That raises high availability from a nice-to-have to a baseline requirement. Look for active/standby redundancy, typically expressed as 1+1 HA, so that maintenance and failures do not take down your whole customer base.

Cloud and Hybrid Deployment

Teams Phone runs in Microsoft Azure, so an SBC deployable natively in Azure keeps latency to the Teams infrastructure low. For providers with existing data centers, or customers who require the SBC inside their own cloud account, availability across Azure and AWS or on VMware, KVM, and baremetal lets you place the SBC where the business needs it.

Provider SBC Requirements at a Glance

Requirement	Needed for	Provider priority
Supported SBC + registered FQDN	Teams accepting the connection at all	Mandatory
TLS signaling + trusted certificate	Encrypted, authenticated Teams trunk	Mandatory
SRTP with RTP-to-SRTP conversion	Bridging unencrypted carrier media to Teams	Mandatory
Per-tenant multi-tenancy	Serving many customers from one instance	Critical for scale
Configurable SIP header manipulation	Normalizing varied carriers and tenants	Critical for scale
Edge security and fraud scoring	Protecting a shared, internet-facing platform	Strongly recommended
1+1 high availability	Keeping every tenant online during faults	Strongly recommended

Onboarding a Tenant: The High-Level Path

Once the platform is running, adding a customer follows a repeatable sequence. The exact screens depend on your SBC, but the shape is consistent across a well-built Direct Routing service.

1. Register the tenant domain in Teams Admin CenterAdd the customer’s SBC FQDN or subdomain under Voice, Direct Routing, so Teams knows where to route the tenant’s calls and which certificate to validate.
2. Confirm the certificate covers the tenantVerify that your TLS certificate, or a wildcard covering your subdomains, is valid for the tenant’s FQDN and issued by a Microsoft-trusted CA.
3. Create the tenant’s trunk group toward TeamsSet transport to TLS, media to SRTP, apply your Teams-compatible SIP normalization rules, and enable topology hiding, all scoped to this tenant.
4. Map the tenant to a carrier trunkPoint the tenant at the carrier trunk that will carry its PSTN traffic, using either a shared wholesale carrier or a carrier assigned to that customer.
5. Assign numbers and configure routingProvision the tenant’s numbers and define inbound and outbound routing between the Teams trunk and the carrier trunk, with priority and fallback for resilience.
6. Verify OPTIONS and place test callsConfirm the tenant’s trunk shows healthy in Teams Admin Center, then test calls in both directions and check audio quality and caller-ID presentation before going live.

The Commercial Side: Pricing and Packaging

The cost structure of the SBC shapes your margins, and session-based licensing fits a provider model well because your cost scales with the concurrent capacity you actually use rather than a large upfront hardware purchase. How you then price and package Teams voice for your own customers, the per-seat, per-channel, and tiered models, the go/no-go rules for which accounts to take, and who owns STIR/SHAKEN attestation once you are the originating provider, is a business decision in its own right. That playbook is covered end to end in how to offer Teams Direct Routing as a managed service. This guide stays on the SBC requirements that make the service technically possible.

Frequently Asked Questions

Conclusion

Becoming a Microsoft Teams Direct Routing provider is less about Teams and more about the SBC you build the service on. Microsoft’s requirements, a supported SBC with a registered FQDN, TLS signaling, SRTP media, the OPTIONS heartbeat, and SIP compatibility, get a single tenant connected. Turning that into a business means an SBC that is genuinely multi-tenant, scales to your trunk-group and session targets, gives you configurable SIP control per tenant, defends a shared platform at the edge, and stays available when every one of your customers depends on it.

Get those pieces right and each new customer becomes a configuration change rather than a project, which is exactly the economics a provider needs. Whether you host the SBC yourself or resell it as a managed service, the platform underneath is the difference between a Direct Routing offering that scales and one that consumes your support team.