Microsoft Teams Phone: Error Code 422 Fix – Causes & Solutions

Error Code 422 in Microsoft Teams Phone usually points to a Direct Routing timer mismatch, not a user-side setting. In the Teams Phone scenario covered here, the code is commonly recorded as 540422 / 422 Session Interval Too Small, which means the offered Session-Expires value sits below what the far side accepts. Start with the SBC SIP profile, the timer values, and the refresh method before you touch policies, number assignment, or licensing. [✅Source-1]

Contents

Why Error 422 Appears in Teams Phone

In Teams Phone Direct Routing, the 422 result belongs to SIP signaling between Microsoft’s SIP Proxy and your Session Border Controller. Microsoft documents the pair as a SIP response code and a Microsoft response code that should be read together, because the SIP code shows what happened and the Microsoft subcode adds why it happened. When engineers compare this behavior with other documented Microsoft Teams error codes, the pattern usually confirms the issue sits in trunk signaling rather than client-side Teams troubleshooting. For this scenario, that pairing points the investigation toward timer negotiation on the trunk rather than random desktop cleanup steps. [✅Source-2]

Where the Timer Mismatch Starts

The timer exchange is simple once you isolate the fields. Session-Expires is the requested session interval. Min-SE is the smallest interval the far side is willing to accept. If the request supports timers and the offered interval is below policy, a proxy or UAS may reject the INVITE with 422 Session Interval Too Small and must include Min-SE in the response. RFC 4028 also states that this minimum cannot be lower than 90 seconds, and that a UAS must not increase Session-Expires in the 2xx response. Small field. Big effect. [✅Source-3]

1. Session-Expires: the requested lifetime of the dialog before a refresh is expected.
2. Min-SE: the lowest accepted floor for that dialog.
3. Supported: timer: signals that the timer extension is understood.
4. Refresher behavior: decides which side sends the session refresh during longer calls.

That is why a 422 fix usually lives on the Teams-facing SIP profile. Not on the user account. Not on the dial plan. On the trunk profile itself (or on the inherited template feeding it).

What to Check on the SBC

Base Connectivity Checks

Before you change any timer, verify the SBC object that Teams is actually using. Microsoft requires the SBC FQDN to match a domain registered in the tenant, and the pairing should show proper SIP OPTIONS behavior with 200 OK responses in both directions. If the gateway object or pairing is off, timer tuning becomes noisy because the signaling path is already unstable. [✅Source-4]

Profile and Refresh Settings

• Check the Session Timer value on the Teams-facing trunk.
• Check the Minimum Session Timer on that same trunk.
• Confirm the SBC still sends re-INVITEs for longer calls where the vendor expects them.
• Review any header normalization rule that rewrites, strips, or overrides Session-Expires or Min-SE.
• Look for inherited defaults from another carrier template (this is common after profile cloning).
• Retest on the exact trunk that handles Teams traffic, not on a lab profile that never receives production calls.

If your vendor supplies a Teams-certified SBC profile, use that profile rather than a generic carrier template whenever possible. Microsoft notes that certified SBCs pass third-party testing, are checked daily in production and preproduction environments, and follow a joint support path with the vendor. That reduces drift between vendor defaults and Teams Direct Routing behavior. [✅Source-5]

How to Verify the Failure in Teams Admin Center

Use the PSTN Usage report, open the Direct Routing tab, and inspect the failing call record. Microsoft exposes the Final SIP code, Final Microsoft subcode, and Final SIP phrase there. Selecting the Final SIP code opens the SIP call flow, which is the fastest way to confirm whether the reject came from timer negotiation or from another signaling step. [✅Source-6]

Field	What It Tells You	What to Look For
Final SIP Code	The protocol result that ended the call	422
Final Microsoft Subcode	The more specific action code behind the SIP result	540422 in this scenario
Final SIP Phrase	Readable description of the code pair	Session Interval Too Small
SIP Call Flow	Chronological ladder of signaling messages	The exact message where the reject appears

The ladder view is not instant. Microsoft says the SIP call data can take up to 30 minutes to appear in Teams Admin Center, and call records older than 30 days are not available in that view. So after a timer change, wait for the reporting window to catch up before you decide the fix did nothing. [✅Source-7]

Health Signals That Matter Before and After the Fix

Direct Routing treats regular SIP OPTIONS as a live health signal. Microsoft describes a healthy SBC as one that sends OPTIONS every minute, and the service considers the SBC healthy when it has seen OPTIONS within the last three minutes. If those messages stop, route preference can change and your 422 test results may stop reflecting the active path. [✅Source-8]

In the Health Dashboard, watch the overall count of SBCs with issues, the TLS connectivity status, the SIP options status, and the call sample behind each metric. Microsoft notes that a low NER may still be normal when fewer than 100 calls were analyzed, that certificates are flagged when they are within 30 days of expiry, and that an average call duration around 15 seconds can signal users are hanging up and redialing. Those figures help separate an isolated timer mismatch from a wider trunk health pattern. [✅Source-9]

Metric	Value Worth Noticing	Why It Helps
Analyzed Calls	Fewer than 100	NER can look low while the sample is still small
Certificate Warning	Within 30 days of expiry	Renewal can prevent a second issue from masking the timer fix
Average Call Duration	Around 15 seconds	Users may be hanging up early and redialing

Fixes That Usually Clear Error 422

The cleanest fix is usually on the Teams-facing SBC profile. Not everywhere. Just there. Raise the session values so the offered interval is not below the accepted floor, keep the refresh behavior aligned with the vendor’s Teams profile, and then retest with a fresh call record.

1. Raise Session Timer and Min-SE together on the active Teams trunk when they are out of step.
2. Confirm the SBC still sends RFC-aligned re-INVITEs for longer calls after the change.
3. Remove or adjust any manipulation rule that rewrites Session-Expires or strips Min-SE.
4. Place one controlled test call, then compare the new ladder with the earlier failed ladder.
5. If the final subcode begins with 540 or 560, inspect the SBC logs first. Microsoft notes that this pattern generally means the SBC generated the final response in Direct Routing troubleshooting. [✅Source-10]

A Short Sequence That Saves Time

When the first failing call appears, work in this order. It keeps tenant configuration separate from SBC signaling and saves a lot of repeat testing.

1. Run Microsoft’s Direct Routing diagnostic for the affected user.
2. If the diagnostic is clean, open the PSTN Usage report and then the SIP call flow for the failed call.
3. Compare the failed ladder with one successful call on the same SBC and route.
4. Read the SBC logs for the exact INVITE that returned 422.
5. Apply the timer change to the active Teams profile, publish it, and retest after the reporting delay.

Microsoft’s Direct Routing diagnostic is built to show whether the affected user is configured correctly and to point to the next steps when the issue sits in tenant, user, or policy configuration. If that diagnostic passes, the focus should move back to the Direct Routing trunk and the SIP dialog. [✅Source-11]

FAQ