Microsoft Teams Direct Routing Calls Failing? A Practical Troubleshooting Guide

A Microsoft Teams Direct Routing call can fail before it reaches the Session Border Controller, at the SBC itself, or after the SBC has handed the call to the carrier. The fastest way to troubleshoot is to stop guessing and identify the last platform that handled the call. This guide explains how to separate Teams policy, number normalization, voice-route, SBC, SIP trunk, carrier and media problems using evidence from each layer.

Why Direct Routing failures are often misdiagnosed

Direct Routing joins several systems into one calling experience: the Teams client, Microsoft Teams Phone, user licensing and voice enablement, dial plans, voice-routing policies, PSTN usages, voice routes, Microsoft’s Direct Routing service, the SBC, the SIP carrier or PBX, and finally the destination network. A user sees only one result—“the call failed”—but the technical cause can sit anywhere in that chain.

The error displayed in Teams is useful, but it is not always specific enough to identify the failing system. For example, Your organization’s policy does not permit this call strongly suggests a Teams-side authorization or routing problem. By contrast, if the call appears in the carrier portal with a Call ID and a final SIP response, Teams has already sent the call. The investigation should then move downstream instead of repeatedly changing Teams policies.

A disciplined diagnostic process answers three questions in order:

1. Did Teams select an eligible voice route and send the call to an SBC?
2. Did the SBC accept and forward the SIP INVITE to the intended trunk, carrier or PBX?
3. Did the downstream network accept, reject, ring or answer the call—and did media flow after answer?

Once the last successful hop is known, the troubleshooting scope becomes much smaller.

Understand the outbound call path

A typical outbound Direct Routing call follows this logical path:

Teams user → Teams Phone service → voice-routing policy → PSTN usage → matching voice route → enabled SBC → carrier or PBX → destination network

Each element depends on the previous one. The user can have a Teams Phone licence and a telephone number, but still fail to call because the assigned voice-routing policy does not contain the correct PSTN usage. The policy can contain the usage, but the route’s number pattern may not match the normalized destination. The route can match, but the gateway may be disabled or unhealthy. The SBC can be healthy, but the carrier can reject an unverified caller ID or a particular destination.

Microsoft defines a voice-routing policy as a container for PSTN usage records. A PSTN usage links the user’s policy to one or more voice routes. Each voice route contains a number pattern and one or more SBC gateways. This chain is the centre of most outbound-routing investigations.

First decision: did the call reach the SBC?

This is the most important split in the investigation.

If the SBC has no INVITE for the attempted call

Focus on Teams-side configuration and route selection:

• The user may not be correctly enabled for Teams Phone or Enterprise Voice.
• The user may not have the expected voice-routing policy.
• The policy may be missing the PSTN usage required by the route.
• The dialled number may not match the voice route after normalization.
• The selected gateway may be disabled or unavailable.
• A recent policy change may not yet have reached the Teams client or service.

Do not change the SBC or carrier configuration until Teams is proven to be sending an INVITE.

If the SBC receives and forwards the INVITE

Teams has selected a route. The next evidence comes from the SBC and carrier:

• Confirm the destination number remained correct after translation.
• Confirm the intended outbound trunk was selected.
• Check the From and P-Asserted-Identity values against carrier caller-ID rules.
• Read the provisional and final SIP responses in sequence.
• Correlate the SIP Call-ID with the carrier’s call record or support reference.

A carrier record is strong proof that the call left Teams and the SBC. Continuing to rebuild the Teams route after that point can introduce new faults without changing the carrier outcome.

Step 1: verify the user is truly enabled for Direct Routing

Start with one affected user and one known-good user. Comparing the two is faster than reviewing the entire tenant.

Check the following:

• Teams Phone entitlement: the user needs the appropriate Teams Phone capability in addition to the required base licensing.
• Enterprise Voice: the account must be voice-enabled for Direct Routing.
• Telephone number: the user should have the intended Direct Routing LineURI in a valid format.
• Dial pad: its presence is a useful client-side sign, although it does not prove that the full outbound route is correct.
• Voice-routing policy: confirm the effective assignment, including whether it is Global, direct, group-based or inherited.
• Calling policy: confirm the effective policy does not block the required calling behaviour.

Microsoft notes that assigning a voice-routing policy alone does not enable PSTN calling; the user must also be enabled and correctly provisioned for Direct Routing.

For an administrator using Teams PowerShell, a targeted user check can include:

Get-CsOnlineUser -Identity user@company.com |
  Format-List Identity,EnterpriseVoiceEnabled,LineURI,
  OnlineVoiceRoutingPolicy,TeamsCallingPolicy

Property availability and naming can change between Teams PowerShell versions, so administrators should validate commands against the current Microsoft documentation and module installed in their environment.

Step 2: trace the policy, PSTN usage and voice-route chain

This is where a configuration can look complete in the Teams admin centre while still being unusable.

Voice-routing policy

Identify the effective policy assigned to the user. If a custom policy is expected, verify that it is actually applied rather than merely created. For production environments, clear naming such as UAE-International-Users or Branch-A-Domestic-Only makes troubleshooting easier than ambiguous names.

PSTN usage

Open the policy and confirm that the required PSTN usage is present. This is not decorative metadata: it is the link that makes the associated voice routes eligible for the user. A route can exist, an SBC can be healthy, and the user can still be blocked before the SBC if the applicable PSTN usage is absent from the user’s policy.

If several PSTN usages are assigned, review their order and purpose. Avoid a large, unexplained catch-all usage when separate domestic, international, emergency or branch-specific routes are required.

Voice route

Confirm that the route:

• uses the same PSTN usage that appears in the user’s policy;
• contains a valid regular-expression pattern;
• matches the number after Teams dial-plan normalization;
• enrols the intended SBC or SBC pair;
• has the correct priority relative to broader or fallback routes; and
• does not contain invisible characters copied from a formatted editor.

Microsoft specifically warns that invisible characters can enter routing-policy data when text is pasted from rich-text editors. When a pattern appears correct but behaves inconsistently, recreate it from plain text and retest.

Step 3: normalize every dialled number to a predictable format

Users may enter a national number, an international number, a number with spaces or punctuation, or an extension. The route usually expects a normalized value. For most multi-country Direct Routing deployments, E.164 format—such as +971…—is the cleanest internal standard.

Review the complete transformation:

1. What did the user type?
2. Which tenant or user dial plan normalized it?
3. What exact number did the voice route evaluate?
4. What number did the SBC receive in the Request-URI and To header?
5. Did the SBC translate it again before sending it to the carrier?

Common mistakes include allowing +971 destinations but forgetting another authorised country, expecting a 10-digit national number while the dial plan produces E.164, or using an expression that accidentally permits invalid lengths. Number rules should be tested with allowed, blocked and edge-case examples before they are assigned broadly.

For security and cost control, route patterns should express the real business requirement. A universal catch-all route is convenient during a laboratory test but can create fraud, billing and governance risk in production.

Step 4: check SBC health in the Teams admin centre

Go to Voice → Direct Routing and review the health of the enrolled SBC. Microsoft’s Direct Routing health dashboard is designed to monitor the connection between the SBC and the Direct Routing interface.

Review these signals:

• TLS connectivity: confirms that the secure signalling relationship is active. Certificate expiry, certificate-chain trust, FQDN mismatch and firewall issues can break this layer.
• SIP OPTIONS: confirms application-level trunk monitoring. An SBC can be reachable at the network layer while its SIP service is unhealthy.
• SBC enabled state: an enrolled but disabled gateway will not carry the intended calls.
• Certificate expiry warning: renewal should be handled before the service window becomes critical.
• Concurrent-call capacity: compare the configured capacity with actual call demand.
• Network effectiveness and call quality: review trends carefully, particularly when enough calls exist to make the measurement meaningful.

“Active” TLS and SIP OPTIONS show that Microsoft and the SBC can maintain signalling health. They do not prove that every user policy, number pattern, carrier permission or caller ID is correct. Treat health indicators as necessary evidence, not as a complete end-to-end test.

Step 5: use the SBC as the boundary of truth

The SBC provides the clearest boundary between Microsoft and the downstream telephony environment. For a specific failed attempt, capture:

• local time and UTC time;
• calling user or anonymised source identity;
• destination number, with masking where appropriate;
• SIP Call-ID;
• Microsoft source address or hostname;
• selected outbound trunk;
• translated Request-URI, From and P-Asserted-Identity;
• provisional responses such as 100 Trying or 180 Ringing; and
• the final SIP response and reason phrase.

The interpretation is straightforward:

• No INVITE: investigate Teams policy, usage, route matching, gateway selection or propagation.
• INVITE arrives but is not forwarded: investigate SBC access control, routing logic, trunk selection, number rules or configuration validation.
• INVITE is forwarded and the carrier replies: investigate the carrier result, caller-ID requirements, permissions, destination routing or account status.
• Call answers but audio fails: move to RTP/SRTP, codec, NAT and firewall analysis.

Production traces can contain telephone numbers, network details and identity headers. Access should be role-controlled, retained only as long as necessary and shared with vendors in a redacted form.

Step 6: distinguish an SBC rejection from a carrier rejection

A SIP response observed at the SBC does not always identify the organisation that originated the underlying failure. A provider may return one response to the SBC while its internal voice-insights view shows a different downstream carrier code. Correlate both sides before assigning blame.

Examples:

• 100 Trying, then 403 Forbidden: the provider accepted the transaction for processing and then rejected it. Check caller-ID verification, trunk authentication, geographic permissions, account restrictions and downstream details.
• 404 Not Found or 484 Address Incomplete: review the destination format and translation rules.
• 408 Request Timeout or 504 Server Time-out: investigate reachability, downstream response time and the provider route.
• 486 Busy Here: the destination may be busy; this is not automatically an SBC fault.
• 487 Request Terminated: the calling side may have cancelled before answer, often after the user ended the attempt.
• 5xx response: review whether it came from the SBC, provider platform or destination carrier before changing the configuration.

Carrier portals, Call IDs, Voice Insights and packet captures are valuable because they provide independent evidence. If the provider has generated a call record for the correct destination, the call has already moved beyond Teams route selection.

When every number works except one

A single-destination failure is an important diagnostic signal. If the same user can reach other numbers through the same policy, route, SBC and trunk, the shared configuration is probably functioning. Investigate what is unique about the failing destination:

• destination carrier or numbering range;
• mobile versus fixed-line classification;
• ported-number routing data;
• international caller-ID acceptance;
• provider route selection;
• temporary network failure or destination blocking; and
• whether the same number works from another carrier.

Run a controlled comparison: call one known-good destination in the same country, one destination on another network, and the failing number. Record exact times and carrier references. This produces a much stronger escalation than “one number does not work.”

If the call connects but audio is missing

Signalling success does not guarantee media success. Once the call receives a final answer, troubleshoot the RTP or SRTP path separately.

Check:

• the media IP addresses and UDP port ranges offered in SDP;
• Azure Network Security Group, host firewall and upstream firewall rules;
• NAT handling and whether the SBC advertises the correct public media address;
• codec agreement, preferably avoiding unnecessary transcoding;
• SRTP/RTP interworking and media anchoring;
• whether packets flow in both directions after answer;
• packet loss, jitter and round-trip latency; and
• whether media bypass is enabled and appropriate for the design.

One-way audio usually means one direction of the media flow is blocked or advertised incorrectly. No audio in either direction can point to a broader media-path, SDP or port-range issue. Capture only what is necessary and protect voice packets as sensitive operational data.

A 30-minute diagnostic workflow

Minutes 0-5: reproduce one clean test

Use one affected user, one full E.164 destination and one exact timestamp. Record the visible Teams error. Avoid several simultaneous test calls because they make log correlation harder.

Minutes 5-10: confirm the effective Teams configuration

Verify licensing, Enterprise Voice, LineURI, effective voice-routing policy, PSTN usage, route pattern and enrolled gateway. Compare against a working user if one exists.

Minutes 10-15: check Direct Routing health

Review TLS, SIP OPTIONS, enabled state, certificate warnings and recent health. If the dashboard is healthy, do not stop—the user route can still be wrong.

Minutes 15-20: find the call at the SBC

Search by time, destination and Call-ID. Determine whether the INVITE arrived, which trunk was selected, how the number and caller ID were presented, and what final response returned.

Minutes 20-25: correlate the carrier record

Use the carrier Call ID or portal record. Check account status, destination permissions, caller-ID rules, response codes and downstream carrier details.

Minutes 25-30: retest one controlled change

Change only the proven failing layer. Retest once and compare the new evidence. Document the result before making another change.

Build an evidence pack before escalating

A useful support case should include:

• business impact and number of affected users;
• exact test time with timezone;
• source and destination, partially masked if required;
• Teams error message or screenshot;
• effective voice policy, PSTN usage and matched route;
• SBC FQDN and health state;
• SIP Call-ID and final response;
• carrier Call ID and downstream result;
• whether other destinations and users work; and
• the single change already tested.

This evidence prevents Teams, SBC and carrier support teams from sending the case back and forth without ownership.

Common mistakes to avoid

• Assuming a healthy SBC means the user’s policy is correct.
• Creating a PSTN usage but not adding it to the effective voice-routing policy.
• Testing route patterns against what the user typed instead of the normalized number.
• Changing Teams, SBC and carrier settings at the same time.
• Treating every 403 as the same problem without reading provider-side details.
• Rebuilding Teams routes after the carrier has already logged the call.
• Using catch-all international routes without fraud and cost controls.
• Declaring success after ringing without verifying answer and two-way audio.
• Sharing unredacted packet captures or credentials in support tickets.
• Leaving certificate renewal, backups and failover untested until an outage.

Production prevention checklist

• Use documented naming and ownership for policies, usages, routes and gateways.
• Maintain a test matrix for domestic, international, mobile, fixed-line and blocked destinations.
• Validate route expressions and number translations before every deployment.
• Monitor TLS connectivity, SIP OPTIONS and certificate expiry.
• Keep SBC configuration versioned with validation, backup and rollback.
• Set caller-ID rules and carrier permissions deliberately.
• Retain searchable, access-controlled call traces and carrier references.
• Monitor call quality, packet loss, jitter, latency and abnormal failure rates.
• Test failover and recovery rather than relying only on design documents.
• Document the escalation boundary between Microsoft, the SBC operator and the carrier.

Official references

• Microsoft: Manage call routing policies for Direct Routing
• Microsoft: Configure call routing for Direct Routing
• Microsoft: Health dashboard for Direct Routing
• Microsoft: Issues that affect outbound Direct Routing calls

Where this connects

For organisations planning or troubleshooting Teams calling, this topic connects directly with Vivolution services and solution areas:

• Microsoft Teams Voice
• Direct Routing Solutions
• VoIP & Teams Calling
• Unified Communications
• Contact Vivolution

Vivolution Technologies LLC can help organisations assess Teams Phone readiness, design Direct Routing, validate SBC and carrier connectivity, troubleshoot call failures, document call flows and establish a practical support model. Start with one repeatable failed call and a clear evidence trail; the correct layer usually reveals itself quickly.