by pbx.lu Editorial on May 11, 2026
β± 16 min read Β· Article Β· Microsoft Teams
Microsoft Teams can make and receive calls to ordinary phone numbers. What most guides skip is the explanation of what actually happens between the moment a user dials and the moment the call connects. This article covers that: the architecture, the components, the call flow, and the configuration layers that make Direct Routing work.
If you are still deciding whether Teams Phone should replace your fixed-line system at all, start with the Microsoft Teams and fixed-line telephony guide first. This article assumes you have made that decision and are now choosing which Teams calling path to implement.
π‘ Key takeaway. Direct Routing works by placing a certified device called a Session Border Controller between Microsoft Teams and a telephone operator's network. The SBC translates between Microsoft's voice infrastructure and the public phone network, controls what numbers are used, enforces security, and handles failover. Everything else β routing rules, number assignment, emergency calling β is configured on top of that foundation.
The problem Direct Routing solves
Microsoft Teams is, at its core, a data application. It sends voice as packets over the internet, not as traditional telephone signals. The public phone network speaks a different language: SIP (Session Initiation Protocol) in its many operator-specific variants, with its own rules for number presentation, codec formats, and signalling behaviour.
These two worlds do not connect natively. Something has to sit in between, translate between them, and enforce the rules that each side expects.
π‘ That something is the Session Border Controller (SBC). Direct Routing is the name Microsoft gives to the framework that allows a certified SBC to perform this role for Teams. It is not a product you buy from Microsoft. It is a supported architecture: a defined set of technical requirements, a certification programme for SBC vendors, and a set of configuration tools inside the Teams admin centre.
The three components
Every Direct Routing deployment has three moving parts.
π’ Microsoft Teams Phone is the Microsoft-side licence and service that gives users the ability to make and receive external calls. It handles the Teams client, voicemail, auto-attendants, call queues, and the policies that control how calls are routed within the tenant. Teams Phone does not touch the public phone network directly. It hands calls off to the SBC at the boundary.
βοΈ The Session Border Controller (SBC) is the physical appliance or virtual machine that sits at the edge of the architecture. It is the sole point of contact between Microsoft's cloud and the operator's network. Microsoft certifies specific SBC models and firmware versions; only certified devices can be used. The SBC terminates the encrypted connection from Microsoft on one side and the operator's SIP trunk on the other. It translates signalling, negotiates audio codecs, enforces security, and manages the media stream.
π The SIP trunk is the connection from the SBC to a telephone operator's network. The operator provides a block of phone numbers, handles routing to and from the public phone network, and bills for call minutes. The trunk is a standard SIP connection, identical to what any Cloud PBX would use. What makes it specific to Direct Routing is that the SBC on the other end is registered to a Microsoft Teams tenant.
These three components form a chain. A call from a Teams user travels through Teams Phone to the SBC, across the SIP trunk to the operator, and then out to the destination. Inbound calls travel the reverse path.
The call flow, step by step
π€ Outbound call
1. Dial
A Teams user dials an external number in the Teams client on their laptop, mobile, or desk phone.
2. Policy check
Teams Phone evaluates the number against the voice routing policies assigned to that user and identifies which SBC trunk to use.
3. Signalling to SBC
The call leaves the Microsoft cloud over a TLS-encrypted SIP connection to the SBC. Microsoft acts as signalling proxy; it does not handle the audio at this stage.
4. SBC processing
The SBC receives the SIP INVITE, normalises the number and CLI presentation, and forwards the request to the operator's SIP trunk.
5. PSTN routing
The operator routes the call through the public phone network to the destination number.
6. Audio stream
Once established, audio travels as an encrypted RTP stream β either directly between the Teams client and the operator (media bypass) or via the SBC (non-bypass mode).
π₯ Inbound call
The reverse path applies. The caller dials a number, the operator routes it to the SBC, the SBC forwards the INVITE to Microsoft, and Teams rings the correct user or resource account. The audio stream connects on the same path as outbound.
π‘ What media bypass is and why it matters
In the default configuration, all audio packets travel through the SBC even after the call is established. Media bypass is an optional mode where, once signalling is complete, the audio stream goes directly between the Teams client and the operator's media gateway, skipping the SBC entirely for the duration of the call. This reduces latency, lowers processing load on the SBC, and improves audio quality on congested networks. Media bypass requires the Teams client to have a routable IP address, so it works better on wired corporate networks than over VPN or home connections.
What the SBC actually does
The SBC's role is often described simply as "translation". In practice it does six things simultaneously.
SIP signalling translation. Microsoft's SIP implementation and operator SIP implementations differ in subtle ways: header fields, response codes, handling of re-INVITEs, and session timers. The SBC normalises these differences so each side sees behaviour it expects.
Codec negotiation. Microsoft Teams uses SILK and Opus codecs for audio. Operators may support G.711, G.722, or G.729. The SBC negotiates a codec both sides can use and, where necessary, transcodes between them in real time.
Encryption boundary. The Microsoft-to-SBC leg must use TLS for signalling and SRTP for media. The SBC-to-operator leg may use a different security model. The SBC handles both ends independently.
Number presentation. Outbound calls must present a valid CLI. Inbound calls must deliver the called number in a format Teams can match to a user. The SBC normalises both directions.
Capacity management. The SBC tracks concurrent calls and enforces the capacity limits of the SIP trunk, returning a busy signal rather than allowing unpredictable rejections from the operator.
Security enforcement. The SBC protects against SIP denial-of-service attacks, toll fraud, and unauthorised registration. It validates that inbound calls arrive from known operator IP addresses.
How voice routing policies work
The SBC and SIP trunk handle the physical call path. Voice routing policies determine which calls go where and who is allowed to make them. This is configured inside the Teams admin centre and PowerShell, independent of the SBC.
The configuration has three layers.
πΊοΈ Voice routes are the foundation. Each voice route matches a dialled number pattern (a regular expression) to one or more SBC trunks. A route might say: "any number starting with +352 goes to the Luxembourg SBC trunk." Another catches everything else and routes it through a default international trunk.
π·οΈ PSTN usages group voice routes into permission categories. A usage called "Luxembourg local" contains the Luxembourg route. A usage called "international" contains the international route. Usages are not assigned directly to users; they exist as an intermediate grouping layer.
π€ Voice routing policies bundle one or more PSTN usages and are assigned to individual users or groups. A "standard" policy might include Luxembourg local and international calls. A "restricted" policy might include local only. A user with no policy cannot make external calls at all.
When a Teams user dials a number, Teams works through the layers in order: routing policy, then PSTN usages, then voice routes, then SBC trunk. The call goes to the first matching route. If no route matches, the call fails with a "no route found" error.
π§ Why the three-layer model exists
The layered system looks unnecessary for a single-site SMB with one trunk. Its purpose becomes clear with multiple SBCs, operators, countries, and permission levels. A sales team might need unrestricted international calling; a warehouse might need local calls only; an executive might need a failover route through a second SBC if the primary is unreachable. All of this is controlled through the same framework without touching the SBC configuration.
How numbers are managed
Numbers under Direct Routing live in two places: the operator's system and the Teams admin centre. Both must stay in sync.
π Operator side
The operator provisions a block of numbers on the SBC trunk. These numbers exist in the operator's routing tables and are delivered to the SBC when an inbound call arrives.
π₯οΈ Teams side
Each number is assigned in the Teams admin centre to a user, a resource account (auto-attendant or call queue), or a conference bridge. This links the number to a Teams identity.
If a number is provisioned at the operator but not assigned in Teams, inbound calls fail. If a number is assigned in Teams but not provisioned at the operator, inbound calls never arrive. The two records must match exactly.
Number porting is handled entirely by the operator. Teams-side configuration does not change during a port; the number is simply re-pointed to the new operator's trunk once the port completes.
Emergency calling
β οΈ Emergency calling is a compliance requirement, not optional configuration. In the EU, 112 calls must route correctly and carry location information. Under Direct Routing, this is the customer's or partner's responsibility to configure and validate per country before go-live.
The challenge is location. A Teams user might dial 112 from a Luxembourg office, a home in Germany, or a hotel room in Belgium. The emergency service needs to know where the caller is.
Microsoft supports dynamic emergency calling under Direct Routing. The mechanism maps network identifiers (IP subnet, Wi-Fi access point, switch port) to physical addresses stored in the Teams admin centre. When a 112 call is made, Teams reads the client's current network location, looks up the corresponding address, and passes it in the SIP signalling to the SBC.
The SBC must support the relevant SIP headers to carry location data to the operator. The operator must deliver it to the correct PSAP (Public Safety Answering Point) for the caller's country. Each country in the Greater Region has its own PSAP routing rules.
π What happens when a location is not mapped
Users connecting from an unrecognised network β a home office, a hotel, a client site β fall back to a registered address configured in the Teams admin centre, or may trigger an alert to a security desk. This fallback must be configured deliberately. An unmapped location that silently fails to deliver location data on a 112 call is a compliance gap, not just a configuration inconvenience.
Redundancy
A single SBC is a single point of failure for all external calling. Microsoft's recommendation is to register at least two SBCs against the Teams tenant.
π Active-standby
One SBC handles all calls. A second is registered as backup in the same voice routes. If the primary becomes unreachable, Teams automatically tries the secondary. Calls in progress on the failed SBC are dropped and must be re-dialled.
β‘ Active-active
Both SBCs are live simultaneously and share the call load. Voice routes distribute calls between them by priority or by load. This provides both redundancy and capacity headroom, but requires the operator to support multiple trunks or a trunk group configuration.
For SMBs using an operator-hosted SBC service, redundancy is typically included and managed by the operator. The SLA should specify how failover is handled and what the target recovery time is.
Frequently asked questions
Does Direct Routing require an on-premises server?
No. The SBC can be a physical appliance on your premises, a virtual machine in a data centre, or a cloud-hosted service provided by your operator. Most SMBs use an operator-hosted SBC, which means no on-premises hardware at all.
Can one SBC serve multiple Microsoft Teams tenants?
Yes. Enterprise-grade SBCs support multi-tenant configurations where a single device handles Direct Routing for several Teams tenants simultaneously. Each tenant has its own trunk configuration and routing policies. This is common for operators and partners who manage Direct Routing as a service for multiple customers.
What happens to internal Teams calls under Direct Routing?
Nothing changes. Calls between Teams users in the same tenant travel entirely within Microsoft's infrastructure and never touch the SBC or the SIP trunk. Direct Routing only applies to calls that need to reach the public phone network.
How does the SBC know which Teams tenant a call belongs to?
Each SBC is registered to a Teams tenant using a fully qualified domain name (FQDN) verified in the Microsoft 365 admin centre. When Microsoft sends a call to the SBC, it uses that FQDN as the destination. The SBC uses it to identify the correct trunk and routing context.
Can Direct Routing coexist with Microsoft Calling Plans in the same tenant?
Yes. Some users can be on Calling Plan numbers while others use Direct Routing. This is used during phased migrations or when an operator does not have PSTN coverage in a specific country where Calling Plans are available.
π Part of the Microsoft Teams telephony cluster on pbx.lu. Read next: What Microsoft Teams means for fixed-line business telephony Β· What certifications should your Microsoft Teams partner have?.
π Keep exploring. Browse the Microsoft Teams feature page for an overview of how Teams integrates with Cloud PBX platforms, or compare providers active in Luxembourg and the Greater Region.
Latest Insights (sidebar)
π
Ready to explore Direct Routing for your business?
A free 20-minute consultation, independent of any provider.