Operator Connect vs Direct Routing — How to Choose for a Real Customer

If you’ve deployed Teams Calling more than a few times, you’ve had this conversation. The customer needs PSTN connectivity, Microsoft Calling Plans aren’t the right fit, and now you’re deciding between Operator Connect and Direct Routing. On paper both options get calls in and out. In practice the gap between them is significant — and picking the wrong one creates problems that outlast the deployment.

This article gives you a practical decision framework based on what actually matters in production, not a feature checklist.

What You’re Actually Deciding

The choice between Operator Connect and Direct Routing isn’t really about features. It’s about who owns the infrastructure, who owns the carrier relationship, and how much ongoing engineering overhead the customer can absorb.

Operator Connect means Microsoft-certified carriers connect their PSTN infrastructure directly into the customer’s Teams tenant via a certified API. You manage everything through Teams Admin Center. The carrier owns the PSTN side. You own the Teams configuration.

Direct Routing means you deploy a Session Border Controller that bridges the customer’s carrier or on-premises telephony to Teams. You own the SBC. You own the carrier relationship. You own the dial plan. You own the routing policies. You own every layer of the call path.

That’s the real difference. Everything else flows from it.

The Case for Operator Connect

Operator Connect gets dismissed by engineers who equate “managed” with “less capable.” That’s the wrong frame. Here’s what it actually gives you:

Certified carrier integration that Microsoft maintains. Operators go through a rigorous certification process to connect directly into Teams infrastructure. That integration is maintained and updated by the carrier and Microsoft together. You’re not responsible for SBC firmware updates, TLS certificate renewals, or keeping the SIP trunk healthy when Microsoft updates the Teams infrastructure.

Full number management in Teams Admin Center. You assign numbers, manage porting, set calling policies, and configure auto attendants and call queues from the same interface you use for everything else in Teams. There’s no separate carrier portal for day-to-day operations.

No SBC to size, deploy, or maintain. This is the one that gets underestimated. An SBC isn’t a set-and-forget appliance. It needs firmware updates, license renewals, certificate management, capacity monitoring, and someone who knows how to read SIP traces when calls start failing. Operator Connect eliminates that entire layer.

Predictable carrier SLA. When call quality degrades or numbers go dark, you have a support relationship with a certified carrier who is accountable to Microsoft’s program standards. That’s a different conversation than opening a ticket with a generic SIP trunk provider.

Single point of contact for support — including Microsoft escalations. This one gets overlooked until you actually need it. Because your Operator Connect carrier has direct access to your tenant and a formal relationship with Microsoft, they become your single call for anything PSTN-related — and often for tenant-level issues that touch calling as well. When something breaks they can open escalations with Microsoft directly on your behalf through their support agreement. That path is faster than you opening a TAC case yourself, and cheaper — Microsoft may charge for assisted support depending on your support tier, while your operator’s support is covered under the agreement you already have with them. If you’ve ever waited days on a Microsoft support ticket for a calling issue, you understand exactly why this matters.

When Operator Connect wins:

Customer has no existing carrier contract to honor
No on-premises PBX infrastructure in the picture
Call volume is medium to high but complexity requirements are standard
Customer doesn’t have a dedicated telephony team for ongoing management
You want a clean, maintainable deployment that doesn’t require specialized SBC knowledge to keep running

The Case for Direct Routing

Direct Routing exists for a reason. There are real scenarios where it’s the right answer — but they’re more specific than most people think.

Existing carrier investment. If the customer has a SIP trunk contract with two years left on it, or a carrier relationship with favorable rates they’ve negotiated over years, Direct Routing lets them connect that carrier to Teams without breaking the contract or renegotiating. This is the most legitimate business case for Direct Routing in a greenfield Teams deployment.

Phased PBX migration. If the customer is moving off an on-premises PBX but can’t cut over everything at once — either due to budget, complexity, or departments that aren’t ready — Direct Routing lets you run Teams and the legacy PBX in parallel. Calls can traverse the SBC in both directions during the transition period. Operator Connect can’t bridge a legacy PBX.

Custom routing requirements. Least-cost routing across multiple carriers, specific hunt group behavior that Teams doesn’t natively support, complex normalization across multi-site deployments with legacy dial plans, or toll bypass between sites — these are scenarios where Direct Routing’s routing policy flexibility is genuinely necessary. If you need to route calls differently based on originating site, time of day, or number prefix in ways that go beyond what Teams policies natively support, Direct Routing is where that lives.

Regulatory or compliance constraints. Some industries have requirements about where call traffic can traverse. If a customer needs their calls to stay on-premises or within a specific network boundary before hitting the PSTN, Direct Routing with a local SBC gives you that control. Operator Connect routes through Microsoft’s cloud infrastructure — that’s not negotiable.

When Direct Routing wins:

Existing SIP carrier contract that needs to be honored
Active on-premises PBX that needs to coexist with Teams during migration
Specific routing logic that can’t be handled by Teams voice routing policies alone
Compliance or data residency requirements that prohibit cloud PSTN routing
Customer has a dedicated telephony engineering resource who will own it long-term

The Total Cost of Ownership Conversation

Engineers get pulled into cost comparisons that only look at per-seat licensing. That’s not the full picture, and it leads to Direct Routing getting recommended for the wrong reasons.

Operator Connect TCO is mostly predictable. Per-seat carrier costs negotiated with the operator, plus your standard Teams administration overhead. No hardware. No SBC licensing. No SBC support contracts.

Direct Routing TCO has more variables:

SBC hardware or virtual appliance licensing (typically annual)
SBC support contract
Professional services for initial deployment and dial plan configuration
Ongoing management — firmware updates, certificate renewals, capacity reviews
Carrier SIP trunk costs
E911 provider integration costs if required
Engineering time for troubleshooting — SIP trace analysis isn’t fast

For a 50-user deployment, Direct Routing is almost never cheaper than Operator Connect when you factor in all of those layers. The math only starts to shift at scale, and even then only if the customer already has existing infrastructure that absorbs some of those costs.

If a customer is considering Direct Routing primarily to save money, do the full TCO before committing. The SBC alone will often offset any carrier savings, and that’s before you account for engineering time.

SBC Considerations for Direct Routing Deployments

If you land on Direct Routing, SBC selection matters. A few things to know going in:

Vendor certification is non-negotiable. Microsoft maintains a list of certified SBC vendors. If it’s not on the list, it won’t work with Teams Direct Routing. The major vendors you’ll encounter are AudioCodes, Ribbon (formerly GENBAND/SONUS), Oracle, and TE-Systems. Each has hardware and virtual/cloud options.

Hardware vs. virtual SBC. Hardware appliances make sense for large on-premises deployments with high concurrent call capacity and existing data center infrastructure. Virtual SBCs (deployed on-prem as a VM or in Azure) are increasingly common for mid-size deployments — lower hardware cost, easier to scale, and Azure-hosted virtual SBCs simplify the network path to Teams. If the customer is already in Azure, an Azure-hosted SBC is worth evaluating seriously.

Size by concurrent calls, not total users. The most common SBC sizing mistake is using total user count instead of peak concurrent call volume. A 200-user organization where 20 people are ever on the phone simultaneously needs a much smaller SBC than the user count suggests. Get real call volume data — CDR exports from the existing phone system if available — before specifying hardware.

Plan for redundancy. In a production deployment, a single SBC is a single point of failure. Plan for geo-redundant SBCs or at minimum a warm standby, especially for customers where phone availability is business-critical.

Dial Plan and Normalization — Where Direct Routing Deployments Break

This section exists because it’s the part of Direct Routing that causes the most post-deployment problems and gets the least attention upfront.

Teams uses E.164 format for all numbers internally (+1XXXXXXXXXX for North America). Your dial plan’s job is to normalize whatever users dial into E.164 before Teams processes the call. This sounds simple until you’re dealing with:

Multi-site deployments where Site A dials 4-digit extensions, Site B dials 7-digit local numbers, and both need to reach the PSTN and each other
Legacy PBX extensions that need to route through the SBC rather than the PSTN
International sites with different national numbering formats
Users who dial 9 for an outside line out of habit

Poorly written normalization rules fail silently. The call appears to route in the Teams Admin Center, the user hears a ringback, and then nothing happens — or worse, the wrong number gets dialed. Always test normalization against real dialing patterns from real users at every site before go-live, not just the patterns you think they use.

Build your tenant dial plan in stages: start with the most specific patterns first (extensions, internal routing), work out to less specific (local, long distance, international), and always end with a catch-all that routes unmatched patterns to a defined behavior rather than failing silently.

Migration: Moving from Direct Routing to Operator Connect

This comes up more than you’d expect. A customer deployed Direct Routing two or three years ago, the SBC contract is up for renewal, the engineer who built it left, and now the new person is asking if they can simplify.

The good news is that migration from Direct Routing to Operator Connect is well-supported by Microsoft and most major Operator Connect carriers. The general path:

Choose your Operator Connect carrier and connect them to the tenant
Port numbers from the SIP trunk to the operator — or have the operator provision new numbers if porting isn’t required
Reassign numbers to users through Teams Admin Center under the new operator
Update voice routing policies to point affected users to the Operator Connect PSTN rather than the SBC
Validate call flows — inbound, outbound, emergency calling, call queues, auto attendants
Decommission the SBC and SIP trunk once all users are migrated

You can do this in phases by user group, which reduces risk on larger deployments. Keep the SBC live until every user is validated on Operator Connect — don’t pull it until you’re certain nothing is still routing through it.

The Decision in One Question

If you want a single question that cuts through most of the analysis: does this customer have something they need to connect to Teams that Operator Connect can’t reach?

That means an existing SIP carrier they can’t leave, a live PBX that needs to stay up during migration, or a routing requirement that Microsoft’s native voice policies can’t satisfy.

If the answer is yes — Direct Routing.

If the answer is no — Operator Connect. Don’t add complexity you don’t need.

Quick Reference

Factor	Operator Connect	Direct Routing
Infrastructure overhead	None	SBC + carrier management
Carrier relationship	Managed via Teams Admin Center	You own it directly
Existing SIP carrier	Replace with operator	Keep and connect via SBC
Legacy PBX coexistence	No	Yes
Custom routing logic	Limited to Teams policies	Full control
Emergency calling	Operator handles	Requires E911 integration
Support escalation path	Operator handles Microsoft TAC	You open tickets yourself
TCO at small/mid scale	Lower	Higher
Engineering overhead	Low	High
Right for one-person teams	Yes	No