If Microsoft Teams Phone shows Error Code 423, start with the signaling layer. In SIP, 423 means Interval Too Brief: one side rejected the request because the requested expiry window was shorter than it allows. In real Teams Phone deployments, that usually points to Direct Routing, the SBC, or the carrier edge, not to speaker quality, headset pairing, or a menu setting inside the Teams app.
What Usually Matters First
- 423 is an expiry-interval rejection, not an audio-quality score.
- It often appears during registration or refresh behavior, where one SIP element wants a longer timer.
- 423 and 422 are not the same issue; mixing them leads to the wrong fix.
- When the problem lives on the SBC side, Teams client cleanup alone rarely changes the root cause.
Table of Contents
What Error Code 423 Means in Teams Phone
Error 423 belongs to SIP signaling. Its plain-English meaning is simple: the far end refused the request because the expiry interval was too short. Engineers often compare cases like this with other documented Microsoft Teams SIP error codes to confirm whether the rejection comes from registration timing, refresh intervals, or SBC timer policy. In practice, that usually shows up when a SIP element tries to register, refresh, or keep a resource alive on a timer the peer will not accept.
Inside Microsoft calling paths, 423 is most useful as a routing clue. Microsoft’s mediation error mapping ties 423 to a gateway response, which is why the fix often lives on the SBC profile, trunk policy, or carrier side. Quietly, that is where many long troubleshooting sessions begin.
What 423 Usually Does Not Mean
- It is not a packet-loss code.
- It is not a microphone, speaker, or headset hardware diagnosis.
- It is not the same thing as a call dropping after many minutes because of session refresh failure.
If your trace shows REGISTER, Expires, Contact expires, or Min-Expires around the failure point, you are looking in the right area for a 423 case.
How to Confirm Where the 423 Response Is Coming From
Do not stop at the number alone. Microsoft explains that in Direct Routing, when the Microsoft response code starts with 560, the final SIP response was generated by the SBC side. That changes the order of work immediately: inspect SBC logs first, then compare what Teams received.
- Open the Teams admin center entry for the failed call.
- Record the time stamp, user, number, trunk, and response pair.
- Pull the matching SBC trace or carrier trace.
- Search for the transaction that contains 423 and compare the timer-related headers around it.
For user-level history, Call Analytics shows per-user call and meeting records for the last 30 days and includes device, network, connectivity, and quality details for each session. That helps you separate a pure signaling rejection from a wider device or site pattern.
423 vs 422 and Why This Difference Matters
This is where many admins lose time. 423 and 422 sit next to each other in SIP, but they point to different timer families. Treat them as different branches from the first minute.
| Code | Meaning | Usually Tied to | What to Adjust First |
|---|---|---|---|
| 423 | Interval Too Brief | Registration or refresh expiry that is shorter than accepted | Expires, Contact expires, Min-Expires |
| 422 | Session Interval Too Small | Active-call session timer negotiation | Session-Expires, Min-SE, refresher |
If the call connects and later drops around the session timer window, look harder at 422-style session refresh behavior. If the request is rejected up front because the far end wants a longer expiry, think 423.
Headers and Timer Values That Matter
When you read a trace, a small set of headers carries most of the story. These are the fields worth isolating before you change anything.
- Expires — the requested life of a registration or refreshed resource.
- Contact expires — a per-contact expiry value inside a REGISTER path.
- Min-Expires — the minimum value the registrar or peer will accept; a request below this floor can trigger 423.
- Session-Expires — the lifetime of an active SIP session.
- Min-SE — the smallest accepted session timer for active call refresh negotiation.
- refresher=uac or refresher=uas — tells you which side must refresh an active session.
- Record-Route and Contact — these do not define the timer, but FQDN and routing mistakes here can break signaling even when the timer values look fine.
Do not edit Session-Expires first just because the number looks close. For a real 423 case, the cleaner path is usually to compare the requested registration or refresh expiry with the peer’s minimum accepted value.
Steps to Fix Error Code 423
- Capture the exact failure pair. Keep the SIP code, Microsoft subreason, user, called number, route, and time stamp together.
- Open the matching SBC or carrier trace. Search the failed transaction, not just the whole call ladder.
- Compare the offered expiry with the far-end minimum. If the peer advertises a higher minimum, raise the interval on the SBC or trunk profile.
- Separate registration timing from active-call timing. A 423 case and a mid-call session-refresh case often need different changes.
- Clean up signaling identity. Use a proper FQDN in Contact and Record-Route, make sure it resolves correctly, and avoid IP literals where Teams expects a known tenant identity.
- Retest with one user and one route. Then verify that the error disappears in both the SBC trace and the Teams-side record.
Microsoft’s Direct Routing troubleshooting notes also point to TLS version, certificate trust, FQDN formatting, Contact header content, and firewall rules as common blockers when the SBC side is not behaving correctly. Often, these issues sit beside timer mistakes and make the trace noisier than it first appears.
Use the Direct Routing Health Dashboard while you retest. Microsoft notes that SIP Options are normally sent every minute, that certificate expiry warnings appear within 30 days, and that average 1:1 PSTN call duration often sits around four to five minutes. If you see averages collapsing toward 15 seconds, the service path deserves immediate attention.
Checks on the SBC, Carrier, and Microsoft Side
On the SBC
- Compare the sent Expires or Contact expires value with the returned minimum.
- Check whether the SBC rewrites timer headers during registration or refresh.
- Verify that Contact and Record-Route use the right FQDN.
- Confirm TLS version, certificate chain, and DNS resolution.
On the Carrier
- Ask for the minimum accepted registration or refresh interval.
- Check whether the carrier rewrites expiry values on ingress.
- Review trunk keepalive behavior and SIP normalization rules.
- Match the carrier trace time stamp with the Teams-side event.
On the Microsoft Side
- Check whether the pattern is tied to one user, one site, or one route.
- Use Call Analytics for user history and Health Dashboard for trunk health.
- Note whether the Microsoft response code points back to the SBC.
- Retest after one change only. Then compare traces again.
What Usually Fixes It Faster
Raising the rejected expiry value to the accepted floor, keeping the SBC identity clean, and confirming the change with a fresh trace. Small, exact changes work better than broad edits here. Repeatedly so.
Signals That Point to a Different Issue
- Drops after about four seconds often point to SIP exchange or firewall path trouble, not 423.
- Drops after 10 to 20 seconds with no audio more often point to ICE or SDP path issues.
- Drops after several minutes usually push the investigation toward Session-Expires, refresh behavior, or reinvites rather than 423.
- Yellow and red quality flags in session details point to media or device quality trouble, not an expiry-interval rejection on its own.
Microsoft’s Direct Routing examples even show an active-call session timer of SESSION-EXPIRES: 1800;refresher=uac, with refresh work expected before the timer ends. That is a different branch from a 423 registration or refresh rejection, and it deserves a different fix.
Network Conditions That Can Make Troubleshooting Harder
423 is a signaling-side code, but rough networks can still blur the picture by creating retries, re-registrations, or very short abandoned tests. Microsoft’s network assessment for Teams measures UDP latency, UDP jitter, and UDP packet loss; scores above 87.5 are treated as good, while scores below 50 are treated as bad.
In CQD, an audio stream is marked poor when average round trip goes above 500 ms, packet loss rate goes above 0.1, or jitter rises above 30 ms. Those figures do not create a 423 by themselves, but they explain why users may say “calling is unstable” while the trace still shows a timer rejection at the signaling layer.
For Teams Phones themselves, Microsoft recommends about 100 kbps up and down per device. On wireless networks, Microsoft prefers 5 GHz, channel use below 50%, and signal strength around -60 dBm or better. Useful numbers, especially when a timer problem and a Wi-Fi problem arrive together.
FAQ
What does Microsoft Teams Phone Error Code 423 mean in plain English?
It means one SIP element rejected a request because the requested expiry interval was shorter than it accepts. In most Teams Phone cases, that points to signaling timers on the route, not to speaker or headset quality.
Is Error Code 423 the same as Error Code 422?
No. 423 is about expiry or registration timing. 422 is about active-call session timer negotiation. They sit close together in SIP numbering, but they usually send you to different headers and different fixes.
Should I change Session-Expires first when I see 423?
Usually no. Start with Expires, Contact expires, and Min-Expires. Move to Session-Expires and Min-SE only if the trace shows an active-call session timer problem instead of an upfront interval rejection.
Where should I check first in Microsoft 365?
Open the Teams admin center record for the failed call, note the Microsoft subreason, then compare that event with the matching SBC or carrier trace. After that, review Call Analytics for the user and the Direct Routing Health Dashboard for the trunk.
Can poor Wi-Fi by itself create a 423 response?
Usually no. Weak Wi-Fi hurts media quality and can cause retries or very short calls, but 423 itself is a signaling interval rejection. Wi-Fi problems can still make the full picture look worse, which is why both trace data and network data matter.
What if only one route or one carrier shows 423?
That pattern often points to a route-specific rule: a higher minimum expiry value, header rewriting on the carrier side, an SBC profile mismatch, or a signaling identity issue tied to that path.