Error Code 420 in Microsoft Teams Phone usually points to a SIP signaling mismatch inside Direct Routing, not a local desktop cache issue. Microsoft maps this failure to 420 Bad Extension and lists two practical combinations for it: 540420 and 560420. That split matters. One path often points to an unsupported required extension such as 100rel; the other often points to a header path that must be checked more carefully, including transfer-related signaling such as Replaces. [✅Source-1]
If you start with a Teams reinstall, cache cleanup, or headset swap, you often lose time. For this code, start with the SIP ladder, the SBC, and the headers exchanged between the SBC and Microsoft SIP Proxy. What fails first is the signaling. Not the media.
Table of Contents
What Error Code 420 Means
The fastest way to read this fault is simple: the remote side did not accept a SIP extension requirement, or the request reached Microsoft with a header pattern that the flow could not use. In real Teams Phone deployments, that usually means the trouble sits between the paired SBC, transfer behavior, and the headers inside the failed SIP message. Engineers often confirm this by comparing similar cases documented across broader Microsoft Teams SIP and signaling errors, which helps distinguish trunk-level signaling failures from client-side Teams issues.
This is why Error 420 rarely behaves like a laptop-only issue. It is usually a call setup and signaling problem. If one user, one trunk, or one transfer method fails while ordinary desktop actions change nothing, that pattern fits 420 very well.
Which Subcodes Matter Most
Microsoft’s published pairings make triage much shorter. Treat 540420 and 560420 as two different lanes, because they usually send you to different parts of the trace.
| Microsoft Response Code | SIP Meaning | What to Inspect First | First Move |
|---|---|---|---|
| 540420 | 420 Bad Extension | Require, Proxy-Require, Unsupported, 100rel, PRACK | Check whether the SBC or another element is forcing an extension requirement that the other side does not accept. |
| 560420 | 420 Bad Extension | INVITE, REFER, Replaces, transfer behavior, supported methods | Inspect transfer-related signaling and confirm what the SBC advertises in Allow and Supported. |
Use the subcode before you change anything. A 540420 case and a 560420 case can look similar to users, yet the work on the wire is different. That one detail saves hours.
How SIP 420 Works
RFC 3261 defines 420 Bad Extension as a case where the server does not understand the protocol extension named in a Require or Proxy-Require header, and it says the response should include the unsupported item in an Unsupported header. Read that part of the trace closely. For 420, your first grep targets are usually Require, Proxy-Require, and Unsupported before you spend time on codec work or media paths. [✅Source-2]
The extension that appears most often on Microsoft’s 540420 path is 100rel. RFC 3262 ties that option tag to reliable provisional responses and the PRACK method. So when an SBC, gateway, or intermediary demands 100rel in a way the far side does not accept, the call can fail before ordinary call setup finishes. [✅Source-3]
Transfer cases need another lens. RFC 3891 defines the Replaces header as a way to replace one SIP dialog with another, often for attended transfer and call pickup. If Error 420 appears during transfer, queue answer, park retrieval, or a similar handoff, inspect the transfer signaling first. Dial plan edits can wait. [✅Source-4]
Microsoft’s current Direct Routing SIP protocol documentation adds an important guardrail: Direct Routing rejects SIP requests that include Replaces, and Microsoft does not support a third-party SIP proxy or User Agent Server placed between the paired SBC and Microsoft SIP Proxy if it rewrites the request path. Put plainly, blindly enabling transfer-related headers is risky. Validate the exact flow that reached Microsoft, not the flow you expected to send. [✅Source-5]
Where to Inspect the Failed Call
Use evidence, not guesswork. Microsoft documents a SIP call flow view in the Teams admin center for Direct Routing. The path is Analytics & reports > Usage reports > PSTN Usage report > Direct Routing, then drill into the failed call and inspect the SIP events. Microsoft also notes two numbers that matter during troubleshooting: the data can take up to 30 minutes to appear, and records older than 30 days are not available there. [✅Source-7]
- Find the exact failed call and confirm whether the visible code is 540420 or 560420.
- Open the SIP ladder and isolate the first rejected request.
- Read the request and response as a pair, not in isolation.
- Search the request for
Require,Proxy-Require,Allow,Supported,Refer-To,Referred-By, andReplaces. - Then compare the failing call with a working call from the same SBC. Side by side, the missing clue often appears fast.
When a call never reaches the internal Direct Routing components, the Teams-side reports may not tell the whole story. Microsoft notes that rejected INVITE requests or SBC pairing issues can require SBC logs, even when other views look normal. For 420, a full trace from the SBC is often the shortest path to the answer. [✅Source-8]
Headers and Methods Worth Reading First
RequireandProxy-Require: look for forced option tags.Unsupported: if present, it often tells you what the far side rejected.AllowandSupported: confirm what the SBC actually advertised.REFER,NOTIFY,Refer-To,Referred-By: these matter in transfer scenarios.Replaces: inspect whether it was inserted, passed through, stripped, or rewritten.
A Fix Path That Usually Works Faster
- Confirm the exact lane. Start with 540420 or 560420, not just “420”.
- Read the first rejected request. Do not start from the end of the ladder.
- If it is 540420, inspect whether the SBC or another element is forcing
100relor another option tag throughRequireorProxy-Require. - If it is 560420, inspect transfer signaling, advertised methods, and any use of
Replaces,REFER, and related headers. - Compare with a working call. Same route, same SBC, same call type if possible. One working trace next to one failed trace is often enough.
- Change one behavior at a time. Disable, strip, or correct the suspected header path, then test again.
- Retest the same scenario. Ordinary inbound calling may work while attended transfer still fails. Test the exact failed action.
Do not force a header because it looks familiar. In Teams Phone Direct Routing, a header can be valid in SIP theory and still be the wrong move for the flow you are running. That subtle difference causes many 420 cases.
Configuration Patterns That Trigger 420
Forced 100rel
If the SBC or an adjacent element requires 100rel where the far side does not accept it in the expected way, 540420 is a natural result.
Transfer Header Mismatch
A transfer flow that inserts or expects Replaces at the wrong point can break 560420 scenarios very quickly.
Advertised Methods Do Not Match Reality
If the SBC advertises REFER or related support one way, then behaves another way during the call, transfer logic can move into the wrong branch.
Intermediary Rewrites
A third-party SIP layer that rewrites headers, methods, or the request path can turn a clean call into a hard-to-read 420. Small changes matter here.
Technical Values Worth Checking
Microsoft documents a set of operating values that are easy to ignore and easy to regret. An SBC is treated as healthy when it sends SIP OPTIONS every minute and the service has seen OPTIONS during the last three minutes. Microsoft also states that the SIP proxy allows a maximum of two TCP/TLS connections per remote FQDN/IP per SIP proxy virtual machine, uses a two-minute TCP idle timeout, recommends that the SBC renew connections at least once per hour, and notes that some domain configuration changes may take up to four hours unless connections are renewed. [✅Source-6]
| Value | Why It Matters During 420 Triage |
|---|---|
| OPTIONS every 1 minute | Shows whether the SBC is reporting health on the cadence Microsoft expects. |
| Last 3 minutes health window | Explains why a route may look fine now but still have been treated as unhealthy at call time. |
| Max 2 TCP/TLS connections per remote FQDN/IP per SIP proxy VM | Helps when transfer or retry behavior opens new signaling paths. |
| TCP idle timeout: 2 minutes | Useful when intermittent failures appear after quiet periods. |
| Renew connections at least once per hour | Good hygiene after certificate or routing changes. |
| Domain configuration update delay: up to 4 hours without renewed connections | Prevents false “it still fails” conclusions right after changes. |
What to Include in an Escalation Case
When you escalate to the SBC vendor or to Microsoft, send the material that narrows the case on the first pass. A thin ticket often comes back with a request for basics you could have included up front.
- The exact failed timestamp in UTC.
- Call direction: inbound, outbound, blind transfer, attended transfer, queue answer, park retrieval, and so on.
- The visible result code pair: 540420 or 560420.
- The full SIP ladder from the SBC for the failed call.
- A matching working call trace for comparison.
- The relevant headers from the failed request:
Require,Proxy-Require,Unsupported,Allow,Supported,Refer-To,Referred-By, andReplaces. - Any recent SBC firmware, transfer policy, certificate, or routing changes.
A short ticket creates a long thread. A precise ticket does the opposite.
Is Microsoft Teams Phone Error Code 420 a user device problem?
No, not in most real cases. Error 420 usually points to SIP signaling in Direct Routing, especially the path between the SBC and Microsoft SIP Proxy. That is why header inspection and call traces matter more than a local app reset.
What is the difference between 540420 and 560420?
540420 usually sends you toward unsupported required extensions such as 100rel. 560420 usually sends you toward header or transfer-related signaling checks, including whether Replaces, REFER, or related behavior is involved.
Which SIP headers should I inspect first for Error 420?
Start with Require, Proxy-Require, and Unsupported. In transfer cases, also read Allow, Supported, REFER, NOTIFY, Refer-To, Referred-By, and Replaces.
Can the Teams admin center help with this error?
Yes. The SIP call flow view for Direct Routing is useful for reading the chronological request and response sequence. Still, if the call fails before it reaches the internal Direct Routing components, SBC logs may tell you more.
Should I enable or pass through Replaces to fix 420?
Do not assume that. Validate the exact flow first. A transfer design may mention Replaces in SIP theory, yet Microsoft’s current Direct Routing protocol documentation states that Direct Routing rejects SIP requests that include Replaces. The safer move is to inspect the failed message and the SBC’s advertised behavior before changing headers.