VoIP.info Provider research

Microsoft Teams Direct Routing: tenant, SBC and carrier boundaries

Map a Teams Phone call through tenant policy, a certified SBC and a separately selected PSTN carrier without merging their licensing, routing, media or emergency responsibilities.

Reviewed 2026-10-09Current first-party Microsoft Teams Direct Routing planning, configuration, certified-SBC, number-translation, media-bypass, health, monitoring and emergency-calling documentation reviewed October 9, 2026; no tenant, license, user, number, carrier, trunk, SBC, certificate, DNS record, firewall, voice route, translation rule, SIP exchange, media stream, emergency workflow, message, availability, compatibility, price or call was inspected or testedAdvancedDocumentation based · not lab tested

Name every service owner before configuring a route

Direct Routing connects Teams Phone to customer-provided telephony infrastructure through a supported SBC. It can preserve an existing carrier, integrate a PBX or analog devices, and coexist with Calling Plan, Operator Connect or Teams Phone Mobile. It is not itself one universal carrier trunk, number catalogue or managed SBC service.

Record the tenant, Teams Phone license, user or resource account, number, voice route, PSTN usage, SBC, certificate, network, carrier trunk and support owners separately. A number visible in Teams admin center does not prove that the carrier activated it or that the SBC can deliver it.

Documented service facts

Reviewed 2026-10-09. Compare SIP trunk services →

SIP authentication

Documented

Direct Routing pairs a tenant-configured PSTN gateway with a public SBC FQDN in a verified Microsoft 365 domain and uses a publicly trusted certificate for TLS. That is not a digest username and password, a generic SIP-provider login or proof that the selected carrier authorized the other side of the SBC. Preserve the tenant, gateway object, exact SBC identity, certificate chain and carrier-side trust separately.

SIP registration

Documented

Microsoft documents a paired SBC, TLS connectivity and SIP OPTIONS health rather than a customer endpoint REGISTER flow. The dashboard can show an enrolled gateway that never connected as unhealthy. A healthy pairing or recent OPTIONS proves only the Microsoft-to-SBC control boundary; it does not prove carrier-trunk state, user assignment, number routing or a completed call.

Inbound delivery

Documented

Inbound calls use Reverse Number Lookup after any SBC-profile inbound number translation. The normalized called number must match a number assigned to a Teams user or resource account. Carrier assignment, SBC receipt, translation-rule order, tenant number assignment, RNL result and destination answer remain separate evidence states.

Routing and failover

Documented

Voice routes can include several SBCs, and Direct Routing considers SIP OPTIONS health. Microsoft describes demoting a gateway that has not sent OPTIONS within the expected three-minute window; equal healthy gateways can be distributed. Demotion is route selection, not proof of diverse carriers, sites, certificates, power or access, and it does not establish survival of an active call.

Number and regional availability

Not verified

Direct Routing lets an organization retain its selected PSTN carrier and number inventory, but Microsoft's platform documentation does not establish rate-centre inventory, portability, emergency eligibility, activation or serviceability for that carrier. Bind every number, country, site and activation date to current carrier and tenant records.

Audio codecs and DTMF

Documented

Microsoft lists SILK, G.711, G.722 and G.729 on the Teams-to-SBC boundary, with AMR-WB limited to non-bypass operation. Media bypass changes whether a Media Processor, Transport Relay or direct client-to-SBC path carries SRTP. Those listings do not prove the codec, packetization, transcoding, DTMF behavior, port translation or usable audio on the carrier-facing leg; retain both SDP bodies and measured media evidence.

T.38 fax

Not verified

The reviewed Microsoft planning, configuration and media-bypass pages do not establish T.38 entitlement, G.711 pass-through, switchover, redundancy, certified-SBC behavior or completed pages for the selected carrier and device. Treat fax and analog integrations as separate workflows with current SBC-vendor and carrier evidence.

Signaling and media encryption

Documented

Microsoft requires a public trusted SBC certificate and TLS signaling to its SIP proxies; the documented media paths use SRTP. That establishes the Teams-to-SBC requirements, not end-to-end protection through an existing PBX, analog gateway, carrier or PSTN destination. Record certificate validation, transport and negotiated media protection for every leg.

Concurrent calls and call starts

Documented

The PSTN gateway can carry a MaxConcurrentSessions value that the health dashboard compares with calls handled by Direct Routing on that SBC. Microsoft warns that this does not show actual SBC concurrency when the same device also serves other PBXs. Its media guidance recommends at least two SBC media ports per concurrent call. Neither value is calls per second, carrier capacity, CPU sizing, licensed tenant capacity or measured load.

Emergency calling

Documented

Direct Routing emergency call policies reference an online PSTN usage and voice route toward the intended gateway. Microsoft documents dynamic-location paths, Emergency Routing Service Providers and SBC ELIN applications with country-specific behavior, including a Canada screening difference. A stored user location, number or gateway does not prove routing, callback, notification, database acceptance or an approved test result.

Pricing model

Not verified

Microsoft documents Teams and Teams Phone licensing as prerequisites, while SBC software or service, carrier trunks, numbers, emergency services, access, support and usage remain separately sourced. The reviewed pages do not publish one account price or term. Bind every license, SBC, carrier and support charge to a dated quote, contract and bill.

Administration and support

Documented

Teams admin center exposes gateway TLS, OPTIONS, call and capacity observations, while Microsoft supports Direct Routing only with listed certified SBCs and directs SBC faults through the vendor's support process. Certification applies to specific firmware families and is not proof of the installed version, tenant policy or carrier compatibility. Assign tenant, SBC, carrier, network, certificate, alert, escalation and rollback owners.

SMS and MMS

Not verified

The reviewed Direct Routing voice pages do not establish SMS or MMS for Direct Routing numbers, sender registration, APIs, throughput, webhook security, retention or price. Require a separate current messaging product and number-eligibility record from Microsoft or the selected carrier; do not infer messaging from a Teams Phone number or working PSTN call.

Treat pairing, health and carrier reachability as different states

The SBC FQDN must belong to a verified Microsoft 365 domain and use a publicly trusted certificate. Microsoft monitors TLS and SIP OPTIONS; an enrolled gateway that never connected can appear unhealthy, while a recent OPTIONS exchange can make it eligible for routing. Neither state is a SIP endpoint registration or a carrier-side trunk result.

When several SBCs are available, recent OPTIONS health influences selection and equal healthy gateways can share calls. Preserve gateway priority, certificate, DNS, firewall, carrier peer, failure trigger and restoration sequence. Routing around a new call does not prove access diversity or survival of a call already in progress.

Follow the number through normalization and Reverse Number Lookup

For outbound calling, a user's effective dial plan normalizes digits, a voice route matches an approved PSTN usage and optional gateway translation rules can change the number presented to the SBC. For inbound calling, gateway-profile translation can normalize the called number before Reverse Number Lookup finds a user or resource account with the matching assignment.

Rule order matters and Microsoft permits several translation directions. Preserve the original digits, normalized value, matched route, ordered translation rules, carrier-facing value and tenant assignment. A correct translation does not prove caller identity authorization, carrier acceptance or destination answer.

Keep signaling, media and capacity evidence on their own legs

TLS signaling between Microsoft and the SBC, SRTP media and a healthy gateway are separate observations. With media bypass off, Microsoft Media Processors remain in the path for user calls; with bypass on, media can travel directly or through Transport Relays depending on reachability. Voice applications such as queues and auto attendants retain Media Processor behavior.

Microsoft's codec list and two-media-ports-per-concurrent-call guidance are planning inputs. MaxConcurrentSessions is a configured Direct Routing comparison value and can undercount total device load when the SBC also serves other PBXs. Do not convert any of these values into calls per second, carrier capacity or measured audio quality.

Design emergency calling for the actual country and gateway

Direct Routing emergency policies must select the intended online PSTN usage and voice route. Microsoft documents dynamic-location, Emergency Routing Service Provider and SBC ELIN models whose availability and behavior vary by country. The emergency dial string also has its own normalization boundary.

Retain the user's effective location, dispatchable address, callback identity, notification, gateway, carrier database state and approved validation result separately. Keep an independently powered alternative calling path. No tenant, license, user, number, carrier, trunk, SBC, certificate, DNS record, firewall, voice route, translation rule, SIP exchange, media stream, emergency workflow, message, availability, compatibility, price or call was inspected or tested for this guide.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.