Microsoft Teams Phone Error Code 402 is not a generic desktop glitch. In a confirmed Direct Routing case, the pair that matters is Final SIP code 402 with Final Microsoft subcode 560402. Microsoft ties that pair to a failed call path that should be checked in call records, with special attention to the called number and the destination country or region. Read that first, then the repair path becomes much shorter.
Start here: when the same user can place some PSTN calls but fails on a certain range, country, or route, carrier-side routing, SBC path selection, or voice routing deserves attention before you spend time reinstalling the client.
Table of Contents
560402
The Microsoft subcode documented for this Teams Direct Routing case.
402
The final SIP response code paired with that subcode.
3 Digits
SIP response codes are logged as three-digit call-end reasons.
6 Digits
Microsoft response codes are usually six digits and explain why the failure happened.
What Error Code 402 Means in Teams Phone
For Teams Phone with Direct Routing, Microsoft documents 560402 / 402 Payment required as a call failure that should be investigated through the tenant’s call records. The official action is very specific: review failures that carry CallEndSubReason = 560402 and look for patterns in called numbers or in the destination country or region. That wording matters. It points the first diagnostic step toward the route beyond Teams, not toward random client-side tweaks.
In plain terms, this error often means the call left the user side, reached the Direct Routing path, and then failed in a way that should be checked against number patterns, country distribution, and the carrier path used for that destination. Short sentence. The pattern is the clue.
How to Read the Code Pair in Call Records
Teams logs two different values for Direct Routing troubleshooting: a SIP response code and a Microsoft response code. Microsoft states that the SIP response code is three digits, while the Microsoft response code is usually six digits. Microsoft also states that when the Microsoft response code starts with 560, the final SIP response was generated by the SBC side. So when you see 560402, treat it as a route-path clue, not just a vague on-screen number.
One subtle point gets missed a lot. In RFC 3261, SIP 402 Payment Required is marked as reserved for future use. Engineers troubleshooting voice failures often cross-check cases like this against a broader Microsoft Teams error code reference to see whether the failure belongs to Direct Routing, authentication, or device-side behavior. Yet Microsoft still documents a live Teams Direct Routing troubleshooting case for the 560402 / 402 pair. That is why copying a generic SIP chart from somewhere else often sends people in the wrong direction.
| Field | What It Tells You | How to Use It for 402 |
|---|---|---|
| Final SIP code | The protocol-level end code for the call | Confirm it is 402 on the failed attempt |
| Final Microsoft subcode | The Teams-specific reason marker | Confirm it is 560402, not a different 4xx pair |
| Final SIP phrase | The readable label shown with the code | Use it to separate a route failure from number-format or busy-state failures |
| Callee number | The destination that was dialed | Group failures by prefix, country, or specific range |
| Call type | Inbound, outbound, transfer, forwarding, emergency | Find out whether the problem is only outbound, only inbound, or tied to a call action |
How to Verify the Failure in Teams Admin Center
The fastest clean check is inside the Teams admin center. The Direct Routing part of the PSTN usage report shows call start and end times, SIP address, SIP call flow, Final SIP code, Final Microsoft subcode, and the Final SIP phrase. That is enough to decide whether you are facing a routing-path pattern or a user-side provisioning miss.
- Open Analytics & reports > Usage reports, then run the PSTN and SMS usage report.
- Go to the Direct Routing tab.
- Find a failed call and confirm Final SIP code = 402 and Final Microsoft subcode = 560402.
- Capture the callee number, call type, timestamp, and SIP phrase.
- Open SIP Call Flow for the failed call and compare it with one successful call to the same country or prefix.
Use the built-in test too: the Direct Routing diagnostic in the Microsoft 365 admin center checks whether a user is configured correctly for Direct Routing. That saves time when the log looks like a route issue but the user is not actually voice-enabled or policy-ready.
Checks That Matter on the User and Tenant Side
Do not treat every 402 as a pure carrier problem. Teams Phone still needs the basic user setup to be right: the user must have licensing that includes the Teams Phone application, the tenant must have a PSTN connectivity option, and the user must be voice enabled. If one of those is missing, the troubleshooting path changes immediately.
| Check | What to Confirm | Why It Matters |
|---|---|---|
| License | User has a license that includes Microsoft 365 Phone System or a valid Teams Phone Standard combination | No phone entitlement, no reliable PSTN troubleshooting path |
| PSTN option | The tenant uses Direct Routing, Operator Connect, Calling Plan, or another supported PSTN model | Teams Phone by itself does not provide the full PSTN path |
| Voice enabled | Enterprise Voice is on for the user | Microsoft lists this as part of user setup for Teams Phone |
| Phone number | The user has the correct number assignment for the chosen PSTN model | Outbound and inbound behavior can differ if the number setup is incomplete |
| Voice routing policy | The right PSTN usage records and route order are assigned | Wrong policy can send only certain destinations down the wrong path |
- Confirm the user is licensed for Teams Phone.
- Confirm the tenant has a working PSTN connectivity model.
- Confirm the user is voice enabled and, where required, has the expected phone number.
- Confirm the user has the correct voice routing policy and that the intended PSTN usage is in the right order.
A useful separator: a missing dial pad is often a provisioning clue, not a 560402 route clue. Microsoft lists dial-pad prerequisites such as a Teams Phone license, the user being homed online, Enterprise Voice enabled, and Make private calls enabled. For Calling Plan users, Microsoft also notes that the dial pad can take up to 24 hours to appear after assignment. That is a different trail.
Checks That Matter on the SBC and Carrier Side
Direct Routing depends on three moving parts: the Session Border Controller, the Direct Routing cloud components, and the telecom trunk. For 402 cases that cluster by number range or destination, those three parts deserve a close read. Often, very close.
- Check whether the SBC FQDN is connected correctly and the domain is registered in the tenant.
- Validate SIP OPTIONS behavior. Microsoft states that Direct Routing uses OPTIONS to monitor SBC health.
- Check whether the SBC is returning 200 OK to OPTIONS and whether the SBC also receives 200 OK replies to its own outgoing OPTIONS messages.
- Review the voice route and PSTN usage order for the destination that fails.
- Compare a failed call and a successful call to the same country or prefix. The route split often becomes visible there.
Useful numbers from Microsoft’s monitoring model: an SBC is treated as healthy when it sends OPTIONS every minute, and Direct Routing looks at the last three minutes of OPTIONS activity when making routing decisions. That makes intermittent route behavior easier to spot in timestamped logs.
Patterns That Usually Lead to the Fix
Same User, Every PSTN Destination Fails
Check license, voice enablement, number assignment, and the user’s voice routing policy first. A clean route cannot help a user who is not ready for PSTN calling.
Many Users, One Country or Prefix Fails
This is where destination pattern analysis earns its keep. Group failures by country code, area code, or dialed prefix, then compare the voice route and the downstream carrier path used for that segment.
Outbound Fails, Inbound Works
Use the call type markers in the PSTN report. Microsoft exposes values such as dr_in, dr_out, dr_out_user_transfer, and dr_out_user_forwarding. If the problem sits only in dr_out, the route path for outbound dialing deserves the first pass.
Random Failures Across Different Destinations
Read the SIP call flow and check SBC health, OPTIONS cadence, FQDN pairing, and the carrier trunk state around the failed timestamps. With route issues, timing often speaks louder than the label.
Large-Scale Review Across Many Calls
If you need to export and group call data at scale, Microsoft Graph’s getDirectRoutingCalls endpoint returns Direct Routing call records and paginates when a date range contains more than 1,000 entries. That makes it practical to sort 560402 events by destination, user, or time window before you contact the carrier or SBC vendor.
FAQ
Is Microsoft Teams Phone Error Code 402 always a licensing problem?
No. A confirmed 560402 / 402 case in Direct Routing points first to call-record analysis, especially called number and destination pattern. Licensing still needs to be valid, but Microsoft’s own troubleshooting path for this pair starts with route evidence.
Where should I look first when a user reports 402?
Open the PSTN usage report, go to the Direct Routing tab, and confirm the exact pair: Final SIP code 402 and Final Microsoft subcode 560402. Then compare the failed destination with one successful destination.
Why do only some phone numbers fail with Error Code 402?
That pattern usually points to route-specific behavior: a certain prefix, country, or carrier path. Microsoft’s 402 troubleshooting note tells you to look for exactly those patterns in call records.
What details should I collect before I contact my SBC vendor or carrier?
Keep the failed number, timestamp, Final SIP code, Final Microsoft subcode, SIP phrase, call type, and one successful comparison call to the same destination family.
Can a missing dial pad and Error Code 402 be the same issue?
Sometimes they can sit in the same tenant, but they are not the same clue. A missing dial pad often points to provisioning prerequisites. A confirmed 560402 call record points to the Direct Routing call path.