Error Code 400 in Microsoft Teams Phone is not a final diagnosis. It is a rejection code. Engineers often compare cases like this with other documented Microsoft Teams SIP and calling error codes to determine whether the failure belongs to device authentication, number normalization, or the Direct Routing SIP path. In real deployments, it usually shows up in one of two layers: the phone cannot finish an authentication request, or Direct Routing rejects a malformed or unsupported SIP request before the call settles. Same number, different failure path.
Start Here Split the case first. If the user cannot sign in on the phone, check authentication, Conditional Access, shared-device policy, and local device state. If the user signs in but PSTN calling fails, read the SIP path, headers, number normalization, certificate state, and SBC behavior.
Table of Contents
What Error Code 400 Usually Means
On the Direct Routing side, Microsoft documents the 540400 / SIP 400 combination as a case where the SBC sends an invalid or unsupported SIP message format to Microsoft. When that exact pair appears in traces or admin tooling, start with the message itself before you touch routing policies or user licensing. [✅Source-1]
At the SIP standard level, a 400 Bad Request means the request could not be understood because of malformed syntax, and the same request should not be retried unchanged. Engineers troubleshooting these failures often cross-check them against other documented Microsoft Teams Direct Routing and SIP error codes to determine whether the fault sits in header structure, trunk configuration, or SBC message formatting. That detail matters because many Teams Phone cases waste time on retries when the real fix is to repair the SIP message or header set. [✅Source-2]
When the Problem Is in the Call Path
Look at SIP first. INVITE, OPTIONS, Contact, Record-Route, Request-URI, From, certificate name matching, and trunk behavior sit at the front of the queue. A routing policy can be perfect and still lose to a malformed message.
When the Problem Is on the Phone
Look at authentication first. Conditional Access, shared-device rules, app state, device networking, and the sign-in method on the handset decide whether the request can even reach a clean session state. Different layer. Different fix.
Direct Routing Causes That Commonly Produce 400
Microsoft’s Direct Routing SIP flow checks more than the dialed number. It validates the certificate against the FQDN in the Contact header, attempts tenant lookup by the full FQDN, falls back to the domain portion if needed, performs reverse number lookup, and only then applies trunk settings. Contact is required on incoming OPTIONS and INVITE, Microsoft recommends using only Contact when no proxy SBC is in the path, and the SIP proxy prefers top-level Record-Route first and Contact second when both exist. Also, do not mix this with a nearby 403 case: if Contact or Record-Route uses an IP instead of an FQDN, Microsoft documents that as 403 Forbidden, not 400. [✅Source-3]
- Make sure every inbound OPTIONS and INVITE carries a clean Contact header.
- Use the paired SBC FQDN, never an IP address, in Contact and in Record-Route when Record-Route is present.
- Keep the FQDN aligned with the certificate Common Name or Subject Alternative Name.
- If Contact and Record-Route both exist, keep their values aligned so Teams calculates the next hop correctly.
- Check the Request-URI and From values before you edit dial plans; header shape breaks calls earlier than route policy does.
Request-URI example: sip:+14255551212@sip.pstnhub.microsoft.com
From example: <sip:+14255550100@sbc.contoso.com;transport=tls>
Certificates and Activation Checks That Are Easy to Miss
If the SBC was added recently, verify the tenant-side prerequisites before you rewrite SIP. Microsoft states that a self-signed SBC certificate is not valid, the certificate must contain at least one FQDN that belongs to the Microsoft 365 tenant, and the subdomain used by the SBC must have at least one licensed user assigned so the domain can fully activate. Even after the pieces are in place, activation can still take up to 24 hours. [✅Source-4]
The Direct Routing Health Dashboard adds two useful signals here. It warns when an SBC certificate will expire within 30 days, and it shows how many calls were analyzed for each parameter. That second number helps you decide whether you are looking at a narrow fault on one trunk or a pattern that touches a larger share of calls. [✅Source-5]
Practical read: if 400 starts soon after trunk onboarding, certificate renewal, or domain changes, check activation and certificate naming before touching user voice routes. Early in the rollout, often is where this code appears.
Dial Rules and Number Normalization
Number formatting still matters even when the trunk looks healthy. Microsoft documents Direct Routing number values as 3 to 38 digits without common symbols, while extensions use the ;ext= delimiter and can contain 1 to 12 digits. If shared base numbers exist, the extension becomes part of the lookup logic. These are small fields, but small fields stop calls. [✅Source-6]
| Value | Expected Form | Why It Matters |
|---|---|---|
| Calling Plan or Operator Connect number | E.164, for example +14255551212 | Inbound user resolution expects a clean normalized number. |
| Direct Routing number | 3 to 38 digits without common symbols | Route matching fails fast when the normalized output is not acceptable. |
| Extension | ;ext=12345 | Helps user lookup when more than one object shares the same base number. |
Sign-In and Device-Side Causes
When the error appears during authentication, Microsoft says Error 400 usually means the sign-in request with a password could not be processed. The two first checks are plain but worth doing: too many sign-in attempts in a row, or an issue in the app, browser, device, or network path that handles the request. [✅Source-7]
On Teams Phones, one policy combination is documented as unsupported: MFA Conditional Access together with Terms of Use Conditional Access. Microsoft notes that this mix can create sign-in loops or sign-in failure on Teams Phones, so when the handset keeps cycling back to authentication, check policy assignment before you replace the device. [✅Source-8]
Shared Teams devices also need shared-device rules. Microsoft warns that Teams phones should not use the same enrollment and compliance requirements designed for personal Android devices, because that policy shape leads to sign-out and sign-in trouble on shared hardware. Policy fit matters. Even when the account is valid, a mismatched device policy can still block a clean session. [✅Source-9]
Teams-certified phones use Modern Authentication and support sign-in on the phone itself or from another device such as a PC or smartphone. That alternate path is useful in troubleshooting because it helps separate a handset-local problem from an account or policy problem. [✅Source-10]
- Try the handset’s alternate sign-in flow before you reassign numbers.
- Review Conditional Access on the shared or resource account before you reset credentials again.
- Check whether the device is being treated like a personal Android endpoint.
- Only after those checks should you clear local app state or re-enroll the handset.
Network and Session Values Worth Checking
Firewall and capacity numbers can hide the real fault. Microsoft lists Direct Routing media processor destination ports as 3478-3481 and 49152-53247, and it recommends at least two ports per concurrent call on the SBC. If those values are undersized or filtered incorrectly, the trace can look messy enough to distract you from the real 400 trigger. [✅Source-11]
| Check | Value | Why It Helps |
|---|---|---|
| Media processor destination ports | 3478-3481 and 49152-53247 | Confirms the firewall is not masking a signaling fault with a media-path problem. |
| Ports on the SBC | At least 2 per concurrent call | Reduces port starvation during bursts and keeps call traces easier to read. |
Session behavior has its own limits. Microsoft states that Direct Routing allows a maximum of two TCP/TLS connections per remote FQDN/IP for each SIP proxy virtual machine, uses a two-minute TCP idle timeout, expects the SBC to renew the connection at least once per hour, and does not support in-band DTMF. Rarely is an intermittent case random; often, it follows one of these timing rules. [✅Source-12]
| Session Rule | Value | Troubleshooting Use |
|---|---|---|
| Max TCP/TLS connections | 2 per remote FQDN/IP, per SIP proxy virtual machine | Explains why connections may be reused instead of rebuilt every time. |
| TCP idle timeout | 2 minutes | Explains why a quiet trunk may reconnect before the next call attempt. |
| Recommended SBC connection renewal | At least once per hour | Useful after certificate or domain changes. |
| In-band DTMF | Not supported | Prevents false assumptions when validating media negotiation. |
Logs and Evidence That Save Time
When the failure sits on authentication, go straight to Microsoft Entra sign-in logs: Entra ID > Monitoring & health > Sign-in logs. Microsoft also separates the data into interactive, non-interactive, service principal, and managed identity sign-ins, which makes filtering far easier when you already know whether the phone is acting as a user device or a shared device. [✅Source-13]
For Teams Android devices, collect the actual diagnostic package from the Teams admin center instead of relying on a photo of the error screen. Microsoft documents the path: select the Android device, choose Download device logs, wait for processing, then open the History tab and download the diagnostics file. [✅Source-14]
Capture These Before You Change More Settings
- Exact time of the failed call or failed sign-in.
- SIP INVITE and OPTIONS trace from the SBC if Direct Routing is involved.
- The phone number exactly as normalized before routing.
- The account’s Conditional Access assignment if the issue is on a handset.
- Entra sign-in log record or Teams device diagnostics ZIP.
When you collect evidence in that order, the root cause usually narrows down fast without forcing guesswork between policy, transport, and SIP formatting.
FAQ
Does Error Code 400 Always Mean the Same Thing in Teams Phone?
No. On Direct Routing, it usually points to a malformed or unsupported SIP request. On a phone or shared Android device, it can appear during authentication when the sign-in request cannot be processed cleanly.
Is Error 400 the Same as a Contact Header FQDN Problem?
Not always. If the Contact or Record-Route uses an IP address instead of an FQDN, Microsoft documents that as a 403 case. That distinction saves time because a 400 investigation and a 403 investigation start in different places.
Can Conditional Access Create a Teams Phone 400 Sign-In Loop?
Yes. A documented example is the unsupported combination of MFA Conditional Access and Terms of Use Conditional Access on Teams Phones. Shared-device policy mismatch can also keep the handset from reaching a stable sign-in state.
Which Numeric Values Should I Verify Before Deeper Packet Work?
Start with media destination ports, SBC port capacity per concurrent call, Direct Routing number format, extension format, and session timing values such as the two-minute TCP idle timeout.
What Evidence Is Most Useful Before Opening a Support Case?
The most useful set is the exact failure time, SIP traces for Direct Routing, the normalized dialed number, Entra sign-in logs for auth issues, and the Teams device diagnostics package for Android-based phones.