When Microsoft Teams Phone Error Code 487 appears, the code alone does not finish the story. In SIP language, 487 means the request was terminated. In Teams Phone, that can point to a call answered on another endpoint, a ring attempt that was canceled, a timeout, or a Direct Routing path that needs attention. Read the SIP code, the Microsoft subcode, and the call path together. Start there. Microsoft states that Teams platform supports over 320 million monthly active users, which is why the troubleshooting path relies on reports, analytics, and signaling traces rather than on one popup message. [✅Source-1]
Start Here Before You Change Anything
- 487 is a termination result, not a root cause by itself.
- If the call shows “Call completed elsewhere”, the call may have been answered on another Teams endpoint or forked path.
- For repeated failures, the most useful fields are Final SIP Code, Final Microsoft Subcode, Final SIP Phrase, Event Type, and SBC FQDN.
- For Direct Routing, check the admin-side trace first. The code becomes much easier to read when the ladder view is open.
Table of Contents
What Error Code 487 Means in Teams Phone
SIP 487 is defined in RFC 3261 as Request Terminated. The standard says the request was terminated by a BYE or CANCEL request, and it also notes that this response is not returned for the CANCEL request itself. Engineers often cross-check this behavior against other documented Microsoft Teams calling error scenarios to confirm whether the termination came from normal call forking, a user hang-up, or a Direct Routing signaling path. That matters because it tells you something very practical: 487 usually describes how the call attempt ended, not why your whole voice setup is broken. Read it as a signaling outcome first. [✅Source-2]
Inside Teams Phone, the same code can show up in more than one healthy or unhealthy situation. That is why administrators should avoid treating 487 as a one-line diagnosis. A normal forked-call event, a caller hang-up before answer, a no-answer timeout, or a routing problem can all leave you staring at the same code. The field that breaks the tie is often the Microsoft subcode and its related phrase.
Where 487 Appears in Teams Phone
Teams Phone runs across desktop clients, mobile clients, and certified third-party devices. Because of that, the same 487 result may be surfaced through a user client, a Teams-certified desk phone, a PSTN report, or a Direct Routing trace. You are not looking at one narrow device problem. You are looking at a voice workflow that can span client settings, user behavior, telephony routing, and SBC signaling at the same time. [✅Source-3]
- Teams Admin Center under PSTN usage reports
- SIP call flow for Direct Routing calls
- Call Analytics for user-level investigation
- Client logs when one endpoint behaves differently from the rest
Common Scenarios That Produce 487
Call Completed Elsewhere
One of the most common and most misunderstood cases is a call answered on another endpoint or fork. Microsoft documents a Direct Routing example in which the call is recorded as an Attempt with Final SIP Code 487, Microsoft subcode 540200, and the phrase Call completed elsewhere. If that exact pattern appears, your next move is not random policy changes. It is to confirm which endpoint or fork accepted the call. [✅Source-4]
Canceled or Unanswered Ring Attempt
A plain 487 can also fit a simple ring attempt that ended before answer. The caller may have hung up. The destination may never have picked up. A simultaneous ring path may have stopped because another rule fired first. Short call attempts often look dramatic in reports, yet the root event can be quite ordinary. That is why the phrase, the event type, and the related leg matter more than the raw code.
Direct Routing Path Problems
When 487 repeats across many users or many numbers, look beyond user actions. Direct Routing depends on SBCs, Microsoft cloud components, and telecom trunks. Microsoft also explains that Direct Routing uses SIP OPTIONS to monitor SBC health and uses that information in routing decisions. If OPTIONS are irregular, if TLS trust is broken, or if the SBC is not marked healthy, the code you see at the end of the call may be only the last breadcrumb. [✅Source-5]
What to Read First in the Admin Data
For Teams Phone troubleshooting, the PSTN usage report is the fastest place to anchor your reading. Microsoft states that the Direct Routing tab includes the call start and end times, SIP address, SIP call flow, Event Type, Final SIP Code, Final Microsoft Subcode, Final SIP Phrase, SBC FQDN, and correlation identifiers. Those fields tell you whether you are looking at a short failed attempt, a routed call that ended elsewhere, or a pattern tied to one SBC or one route. [✅Source-6]
- Event Type: Success or Attempt
- Final SIP Code: the code with which the call ended
- Final Microsoft Subcode: the extra action marker that often explains the path
- Final SIP Phrase: the human-readable clue
- SBC FQDN: useful for pattern matching when one route is noisy
- Correlation ID: useful when opening a support case
Read those fields before you restart clients, before you alter voice policies, and before you touch the SBC. Done in that order, troubleshooting gets shorter. Often much shorter.
Numbers and Time Windows That Matter
| Signal | What It Tells You |
|---|---|
| PSTN Usage Report | The report can be run for 7 days or 28 days, and Microsoft notes a usual 24 to 48 hour latency from activity time to report visibility. [✅Source-7] |
| SIP Call Flow | Direct Routing SIP call flow data may take up to 30 minutes to appear, and call records older than 30 days are not available there. [✅Source-8] |
| Call Analytics | Per-user Call Analytics covers the last 30 days, while Real-Time Analytics remains available for 72 hours after a meeting ends. [✅Source-9] |
| SBC Health Checks | Microsoft says an SBC is considered healthy when it sends SIP OPTIONS every minute, and the last valid OPTIONS should fall within the previous 3 minutes. [✅Source-10] |
Those time windows matter more than many admins expect. If you check too early, data may not be there yet. If you check too late, the ladder may already be gone.
A Troubleshooting Path That Saves Time
- Decide whether the pattern is normal or abnormal. If the phrase points to Call completed elsewhere, treat it as a forked-answer case until proven otherwise. If the same 487 appears for many users, many numbers, or one SBC, treat it as infrastructure-related.
- Open the PSTN usage record first. Read Event Type, Final SIP Code, Final Microsoft Subcode, Final SIP Phrase, SBC FQDN, and the timing fields together.
- Use SIP Call Flow for Direct Routing calls. Microsoft provides a visual ladder that shows the chronological SIP exchange between your SBC and Microsoft SIP Proxy. That view is where 487 becomes readable. [✅Source-11]
- Run the built-in admin diagnostics that match the symptom. Microsoft documents self-help tests for Direct Routing, PSTN ability, dial pad visibility, voicemail, call forwarding, and call queue scenarios. Use the one that matches the failure pattern instead of guessing. [✅Source-12]
- Check SBC trust and connectivity when the pattern is route-specific. Microsoft lists common SBC issues around SIP OPTIONS, TLS certificates, non-response, and inactive status in the Teams admin center. If an SBC is not healthy, call outcomes downstream can become noisy and misleading. [✅Source-13]
- Collect client logs when one endpoint is the outlier. Microsoft documents support-log collection for Windows and Mac, including the keyboard shortcuts and the fact that logs are written to the Downloads folder by default. That evidence matters when only one user, one client, or one hardware type keeps producing the same result. [✅Source-14]
Read the subcode first, not last. The same 487 can point to a normal endpoint race or to a route that deserves investigation. Without the subcode and phrase, you are only reading half of the event.
Fixes That Usually Clear Persistent 487 Cases
If the Call Was Completed Elsewhere
Review which endpoint actually answered. In real environments that can be a desk phone, desktop client, mobile app, call group target, or another forked destination. If users see the result often and report confusion, check simultaneous ring behavior, forwarding rules, and which endpoint they prefer to answer on. Often, the fix is not technical at all. It is alignment.
If the Pattern Is Tied to One SBC or Route
Look for SIP OPTIONS health, TLS trust, FQDN correctness, and recent route changes. A route-specific cluster of 487 attempts deserves an SBC-first review. Compare affected and unaffected calls by SBC FQDN, time window, caller direction, and whether media bypass was in use. Quietly, that comparison often exposes the route that drifted.
If the Pattern Is Tied to One Client or One User
Collect logs, test the same user on another endpoint, and then reset the local client only if the admin-side data does not show a routing issue. Microsoft notes that clearing the Teams client cache can help when Teams is affected and that Teams should be restarted after the cache reset. For Windows and macOS, Microsoft documents the exact paths and reset steps for both classic and new Teams. [✅Source-15]
A clean pattern beats a long checklist. If 487 appears only on one device, stay local. If it appears on one route, stay on the SBC side. If it says Call completed elsewhere, verify the accepted leg first.
When 487 Is Normal and When It Needs Work
Usually Normal
- The SIP phrase shows Call completed elsewhere.
- The call was clearly answered on another endpoint or fork.
- The pattern is occasional, not widespread.
- Only the non-winning call leg shows 487 while the accepted leg succeeded.
Needs Investigation
- The same 487 repeats across many users or many external numbers.
- One SBC or one route appears again and again in affected records.
- The call never reaches the expected endpoint and nobody answers elsewhere.
- The issue started after certificate, trunk, route, firmware, or client changes.
That split is simple, but it works. Normal 487 events are common in forked calling behavior. Persistent 487 clusters with no accepted leg deserve a proper trace.
FAQ
Does Error Code 487 always mean a failed Teams Phone setup?
No. 487 does not always mean the setup is broken. In Teams Phone it can describe a call attempt that ended because another endpoint answered first, because the attempt was canceled, or because the ring path ended before answer.
What is the first field I should read after 487?
Start with Final Microsoft Subcode and Final SIP Phrase. They usually tell you whether you are looking at a normal call-leg termination or a route that needs work.
Why would a successful call still leave a 487 record?
Because one call leg can lose while another leg wins. In forked or multi-endpoint scenarios, the accepted leg succeeds and the non-winning leg can still show 487.
Where do I check 487 for Direct Routing calls?
Use the PSTN usage report in the Teams admin center, then open SIP Call Flow for the affected record. That is the fastest way to see the signaling sequence between the SBC and Microsoft SIP Proxy.
When should I suspect the SBC instead of the user client?
Suspect the SBC path when many users, many numbers, or one specific route show the same 487 pattern. Suspect the client when the issue stays with one endpoint while the same user works on another device.
Should I clear the Teams cache as my first fix?
Usually no. Read the admin data first. Cache reset is useful when one client is the outlier and the reports do not point to routing, trunk, or SBC health issues.