Direct Routing fails in layers, and the trick to troubleshooting it is figuring out which layer broke before you start changing things. Is the SBC even talking to Teams? Does the routing send the call to the right place? Is the user set up to call out at all? Does signaling work but audio doesn’t? Each of those is a different fix, and guessing wastes hours.
The good news is the layers are stacked in a predictable order, so you can test them in sequence and stop at the one that’s broken. A whole-tenant outage points to the SBC or its certificate. One user failing while everyone else is fine points to that user’s enablement. A call that connects but has no audio points to media, not signaling. Match the symptom to the layer and you’ve narrowed the problem before touching a setting.
This guide works through Direct Routing top to bottom: the SBC connection and SIP signaling, the voice routing chain, per-user enablement, and the audio problems that show up after a call connects. Most of the checks run from Teams PowerShell.
How Direct Routing is wired
Direct Routing connects a customer-provided Session Border Controller (SBC) to Teams Phone, giving you on-premises PSTN connectivity. A call from a Teams user travels: Teams client → Direct Routing service → your SBC → your carrier → the outside number. The reverse path brings inbound calls back.
For that to work, several pieces must all be healthy:
- The SBC is paired with Teams, with a valid certificate and a reachable FQDN.
- SIP signaling flows between the SBC and the Direct Routing service, confirmed by SIP OPTIONS keepalives.
- A voice routing policy tells Teams which numbers go to which SBC.
- The user has a Teams Phone license, Enterprise Voice enabled, a number, and the routing policy granted.
- Media (the actual audio, RTP) can flow between the endpoints and the SBC.
Direct Routing is one of three PSTN options; if you’re still deciding whether it’s the right model versus a Calling Plan or Operator Connect, that comparison is in Calling Plan vs Operator Connect vs Direct Routing. This guide assumes you’ve chosen Direct Routing and something isn’t working.
Layer 1: Is the SBC connected?
Start here for any tenant-wide failure. In the Teams admin center under Voice > Direct Routing, the SBC has a health status. If it’s not showing healthy, no calls route through it, full stop.
Check the SBC from PowerShell:
Connect-MicrosoftTeams
# List configured SBCs / PSTN gateways
Get-CsOnlinePSTNGateway
# Inspect a specific SBC's settings
Get-CsOnlinePSTNGateway -Identity "sbc.contoso.com" | Format-ListThree things break the connection most often:
- Certificate. The SBC must present a certificate from a trusted public certificate authority, and the certificate name has to match the SBC’s FQDN registered in Teams. A self-signed cert, an expired cert, or a name mismatch all fail the TLS handshake.
- FQDN / DNS. The SBC FQDN registered in Teams must resolve publicly to the SBC and match the certificate. If the public IP or FQDN changed, the pairing breaks.
- SIP OPTIONS. Teams marks the SBC active based on SIP OPTIONS keepalives exchanged in both directions. If OPTIONS aren’t flowing, the SBC shows inactive even when everything else looks right.
Layer 2: Voice routing — the chain that sends calls to the SBC
If the SBC is healthy but calls still fail (or only calls to certain numbers fail), the problem is usually the voice routing chain. This chain has four linked parts, and a break anywhere stops the call:
The Direct Routing voice routing chain
| Voice routing policy | Assigned to users; contains one or more PSTN usages |
|---|---|
| PSTN usage | A named record that links the policy to voice routes |
| Voice route | Matches dialed numbers by regex pattern and selects which SBC to use |
| PSTN gateway (SBC) | The SBC the route sends matching calls to |
Read it as a sentence: a user’s voice routing policy contains a PSTN usage, which is linked to a voice route, which matches the dialed number and hands it to an SBC. Inspect each link:
# Voice routing policies and the PSTN usages they contain
Get-CsOnlineVoiceRoutingPolicy
# Voice routes: number patterns and which SBC they target
Get-CsOnlineVoiceRoute | Format-List Name, NumberPattern, OnlinePstnGatewayList, OnlinePstnUsages
# The PSTN usages defined in the tenant
Get-CsOnlinePstnUsageCommon breaks in this chain:
- The voice routing policy has no PSTN usage, so there’s no path to any route.
- The voice route’s number pattern doesn’t match the number being dialed — a regex that’s too narrow drops valid numbers.
- The route points at the wrong SBC, or an SBC that’s down.
- Multiple routes overlap and a higher-priority route with a broken SBC wins.
If calls to some destinations work and others fail, it’s almost always the number pattern on a voice route. Test the failing number against your route patterns.
Layer 3: Is the user actually enabled?
When everyone else can call out and one person can’t, stop looking at the SBC and the routes — they’re clearly working for others. The problem is that user’s setup. Four things must all be true:
A user must have all of these to call out via Direct Routing
- A Teams Phone license assigned
- Enterprise Voice enabled (EnterpriseVoiceEnabled = True)
- A phone number assigned with the on-premises routing option
- A voice routing policy granted that contains a working PSTN usage
Check them in one place:
Get-CsOnlineUser -Identity "[email protected]" |
Format-List UserPrincipalName, EnterpriseVoiceEnabled, LineUri, OnlineVoiceRoutingPolicyWhat you want to see: EnterpriseVoiceEnabled is True, LineUri shows the assigned number, and OnlineVoiceRoutingPolicy is the policy you intended (blank means the user is on the global/default policy, which may not have the right routing).
# Assign a Direct Routing (on-premises) number to the user
Set-CsPhoneNumberAssignment -Identity "[email protected]" `
-PhoneNumber "+15551234567" -PhoneNumberType DirectRouting
# Grant the voice routing policy
Grant-CsOnlineVoiceRoutingPolicy -Identity "[email protected]" `
-PolicyName "Contoso-National"The full number-assignment process, including the differences between Direct Routing, Calling Plan, and Operator Connect numbers, is in how to assign phone numbers to Teams users.
Layer 4: Calls connect but there’s no audio
This one fools people because the call works — it rings, it connects, the timer starts — but one or both parties hear nothing. That’s the signature of a media problem, not a signaling problem. SIP signaling is clearly fine, or the call wouldn’t connect. What’s blocked is the RTP media stream.
Usual suspects:
- Firewall or NAT blocking the media (RTP) port ranges in one direction. Inbound-blocked media gives you classic one-way audio.
- Media bypass misconfiguration. If media bypass is enabled, the media path changes, and a setup that doesn’t account for the client’s network location can break audio. Verify the media bypass configuration matches your network topology.
- Codec mismatch on the SBC, where the SBC and Teams can’t agree on a common codec.
Because the call connects, your instinct is to look at routing — but routing already succeeded. Audio problems live in the network and SBC media settings. If you see one-way audio specifically, trace which direction is silent; that tells you which leg of the media path is blocked. General Teams call media issues (not just Direct Routing) are covered in Microsoft Teams meeting not working troubleshooting, which is useful when you’re not sure whether the fault is Direct Routing-specific or a broader media problem.
A quick triage table
When you’re staring at a Direct Routing problem cold, this maps the symptom to where to start:
Direct Routing symptom-to-cause triage
| No one can call out (tenant-wide) | SBC connection — certificate expiry, FQDN/DNS, SIP OPTIONS |
|---|---|
| Calls to some numbers fail | Voice route number patterns and route priority |
| One user can't call out | That user's license, Enterprise Voice, number, routing policy |
| Call connects, no/one-way audio | Media: firewall/NAT, media bypass config, codec mismatch |
| Inbound calls fail only | Carrier/SBC inbound routing and number-to-user mapping |
Wrapping up
Direct Routing troubleshooting is about isolating the layer before you fix anything. A tenant-wide outage is the SBC or its certificate — and an expired certificate is the single most common “everything died at once” cause. Calls failing to specific numbers point to voice route patterns. One user failing points to that user’s license, Enterprise Voice flag, number, and routing policy. And a call that connects with no audio is a media problem, never signaling.
Work top down: confirm the SBC is healthy and exchanging SIP OPTIONS, walk the voice routing chain from policy to PSTN usage to route to SBC, verify the user’s four requirements, and only then chase media. Matching the symptom to the layer first is what turns a multi-hour hunt into a focused check. If you’re weighing Direct Routing against the alternatives, see Calling Plan vs Operator Connect vs Direct Routing, and find more in the Microsoft Teams guides.
