Microsoft Teams Phone: Error Code 491 Fix – Meaning & Workarounds

Microsoft Teams Phone Error Code 491 usually points to a signaling timing conflict, not a dial-pad mistake and not a normal user permission issue. In SIP terms, 491 means “Request Pending”: a new INVITE or re-INVITE reached the dialog while another INVITE transaction was still open. In plain language, two call changes overlapped—often hold, resume, transfer, session refresh, or media renegotiation. [✅Source-1]

Table of Contents

What Error Code 491 Means in Teams Phone

Error 491 sits in the SIP 4xx class. That class covers request-level problems, but 491 is narrower than codes such as 403, 404, or 408. Engineers often compare this pattern with other documented Microsoft Teams signaling and call setup errors to confirm that the failure comes from overlapping dialog changes rather than routing or identity issues. It does not mean the number is missing, the policy is blocked, or the server timed out in the normal way. It means the call dialog already had an INVITE-related change in motion.

That detail matters. A Teams Phone call may already be established, yet the call can still hit 491 during a later action. A user presses hold. Someone resumes the call. A transfer starts. The SBC refreshes a session timer. Media parameters change. Then another INVITE arrives too soon. State collision—that is usually the real story.

Where This Code Appears in Microsoft Teams

In Microsoft’s Direct Routing records, failed calls are tracked with a Final SIP code, a Final SIP phrase, and a Microsoft subcode that is usually six digits long. That combination helps you tell whether the last response was produced by a Microsoft service or by the Session Border Controller side. [✅Source-2]

You will most often see Teams Phone 491 in the Direct Routing section of the PSTN usage report, where Microsoft exposes call start and end times, SIP address details, SIP call flow access, Final SIP Code, Final Microsoft Subcode, and the final phrase used for the call record. [✅Source-3]

For deeper work, open the SIP call flow from the selected Direct Routing call. Microsoft notes that the SIP ladder data can take up to 30 minutes to appear in the admin center, and records older than 30 days are not available there. [✅Source-4]

Why Teams Phone Returns Error Code 491

Re-INVITE Glare During Mid-Call Changes

The most common trigger is overlapping re-INVITEs. One side tries to modify the session while the other side is already doing the same thing. SIP calls this a glare situation. It often shows up around hold and resume, consult transfer, attended transfer, or fast back-to-back session refresh activity.

Session Refresh or Transfer Logic That Fires Too Early

Some environments create the problem with automation, not with a human click. An SBC, PBX, or trunk element may send a refresh, a transfer-related INVITE, or another session change before the earlier transaction settles. The call can look normal for a moment. Then it trips over itself.

In-Dialog Routing and Header Problems

Direct Routing depends on stable in-dialog routing. Microsoft documents that the SIP proxy uses Contact or Record-Route to calculate the next hop for new in-dialog client transactions such as BYE or re-INVITE. Microsoft also requires FQDNs instead of IP addresses in these headers and states that requests carrying a Replaces header are rejected in Direct Routing. [✅Source-5]

SBC Health Drift

A weak SBC state does not automatically create 491, but it can make dialog handling messy. If the SBC is unstable, inactive, capacity-limited, or not sending expected monitoring traffic, the chance of odd mid-call behavior goes up. That is why repeated 491 events should never be read in isolation.

• Common real-world patterns behind repeated 491 events:
• A user places a call on hold and resumes it quickly while the far side starts a transfer.
• The SBC sends a session refresh while Teams is still completing an earlier renegotiation.
• Transfer logic injects another INVITE before the previous one reaches final state.
• Header normalization or routing rules make the next in-dialog hop inconsistent.

How to Confirm the Real Trigger

1. Open Teams admin center → Analytics & reports → Usage reports → PSTN and SMS (preview) usage → Direct Routing.
2. Find the failed call and note the Final SIP Code, Final SIP Phrase, and Final Microsoft Subcode.
3. Open SIP call flow from the call row or from the Final SIP Code field.
4. Look for crossed INVITE or re-INVITE messages in the same dialog. A second INVITE landing before the first one settles is the pattern to watch.
5. Match the SIP ladder timestamps against the SBC log. If the same call fails only when transfer, hold, or refresh actions cluster together, you have a timing issue, not a basic dialing issue.

Steps That Usually Clear the Problem

1. Retry the exact action once. A one-off 491 can be transient. If it repeats, stop treating it as random and move to SIP flow inspection.
2. Slow down the feature sequence. Test the same call by pausing between hold, resume, and transfer actions. A cleaner result here points to overlap rather than routing absence.
3. Serialize session changes on the SBC side. The SBC should not send another INVITE or re-INVITE while one is still in progress on the same dialog.
4. Review transfer behavior. If the issue appears only during transfer, inspect whether the transfer method, normalization rules, or session refresh logic is stacking requests too quickly.
5. Confirm header consistency. Keep Contact and any Record-Route values aligned with the paired SBC FQDN and certificate. Avoid unsupported Replaces-driven behavior in Direct Routing.
6. Check session refresh rules. A refresh that lands in the middle of another update can recreate 491 again and again.
7. Use Microsoft’s Direct Routing diagnostic for the affected user to verify that the user’s tenant, policy, and routing-side setup are not adding another layer of misconfiguration. [✅Source-6]

RFC 3261 also gives retry behavior for a 491 on a re-INVITE: the sender should back off using a random timer, with a range of 2.1 to 4 seconds if it owns the Call-ID and 0 to 2 seconds if it does not. That does not replace vendor tuning, but it explains why well-behaved SIP peers do not hammer the same dialog again immediately.

Checks Inside the SBC and Direct Routing Layer

Microsoft’s Direct Routing monitoring guidance says SBCs send SIP OPTIONS every minute by default, and the platform treats recent OPTIONS traffic as part of its health decision. In Microsoft’s description, the service uses a three-minute recent window when deciding whether an SBC is healthy for routing. [✅Source-7]

The Health Dashboard for Direct Routing adds another layer: it shows SBC health, warns about no SIP options, inactivity, capacity limits, and even flags certificates that are set to expire within 30 days. When 491 repeats on one gateway, this page is worth opening before you blame the end user. [✅Source-8]

What This Error Usually Does Not Mean

• It is not usually a license problem by itself.
• It is not the same as a busy signal.
• It does not automatically point to packet loss, although network instability can make signaling behavior less clean.
• It does not always mean Microsoft is at fault. In Direct Routing, the last SIP response may come from the SBC side.
• It is not solved by random number reassignment unless your logs show a separate routing issue.

Data Points That Matter During Triage

Data Point	What to Look For	Why It Matters
Final SIP Code	491	Confirms the failure is a pending-request collision at the SIP level.
Final SIP Phrase	Request Pending	Gives the human-readable meaning of the code in the call record.
Final Microsoft Subcode	Usually a six-digit value	Helps separate Microsoft-generated failures from SBC-generated ones.
SIP Call Flow	Crossed INVITE/re-INVITE messages	This is where the actual overlap becomes visible.
Contact / Record-Route	FQDN aligned with the certificate	Bad in-dialog routing can make renegotiation unstable.
SIP OPTIONS Status	Regular traffic, no stale state	Shows whether the paired SBC looks healthy to Direct Routing.
Certificate Window	Near expiry or mismatch	TLS and identity problems can weaken call handling around the edge.
Time Pattern	Only during transfer, hold, or resume	Points away from generic calling issues and toward session-change timing.

How Call Analytics Helps Even When 491 Is a SIP Error

Per-user Call Analytics is still useful. Microsoft keeps a user’s Meetings & Calls history for the last 30 days, and admins can open session details to see device, network, and call-side clues. That does not replace SBC logs for 491, but it tells you whether the same user, site, or device pattern shows up around the failed calls. [✅Source-9]

Use it as a supporting view. If one user sees 491 only when transferring from one certified phone, that narrows the search. If many users hit it only on one carrier path or one SBC, the user endpoint is probably not the main problem. Read the pattern, then follow the protocol trail.

A Practical Reading of 491 During Troubleshooting

• Single event, no pattern: retry once and watch.
• Repeats during transfer: inspect transfer method, header handling, and re-INVITE timing.
• Repeats after hold or resume: look for crossed session refresh and resume logic.
• Repeats on one SBC: inspect SIP ladder, OPTIONS health, certificate, and vendor-side dialog handling.
• Repeats across many users at once: check Direct Routing health, route behavior, and any recent SBC or trunk changes.

FAQ

What does Microsoft Teams Phone Error Code 491 mean?

It means the SIP dialog received a new INVITE or re-INVITE while another INVITE transaction was still pending. In most cases, the issue is a timing collision during a mid-call change rather than a missing number or blocked license.

Is Error Code 491 a user account or license issue?

Usually, no. A repeated 491 points more often to Direct Routing signaling, SBC behavior, transfer handling, or session refresh overlap. Check user setup too, but do not stop there.

Where can I see the failed Teams Phone 491 call?

Use the Teams admin center PSTN and SMS usage report, open the Direct Routing tab, and inspect Final SIP Code, Final SIP Phrase, Final Microsoft Subcode, and SIP call flow for the failed call.

Does restarting Teams fix Error 491?

It can clear a one-off event, but it does not fix the underlying cause when the problem repeats. If 491 happens around the same transfer or SBC path, inspect SIP signaling instead of relying on client restarts.

Should I troubleshoot Microsoft or the SBC first?

Start with the call record and Microsoft subcode, then read the SIP call flow. If the pattern points to an SBC-generated response or the issue is tied to one gateway, begin on the SBC side. If user or tenant setup fails Microsoft’s Direct Routing diagnostic, fix that first.