A Microsoft Teams Phone 486 result points to a call handling decision, not a random app event. In plain language, Teams or a connected voice component refused the call at that moment. The fix changes fast when you identify where the rejection happened: a user, a bot, a call queue, or the Direct Routing path.
Table of Contents
Start with the subcode. If the failed call shows Microsoft subcode 10321, Microsoft documents that combination as a bot rejecting the incoming call because it is busy. If 10321 is absent, treat 486 as a broader busy-state signal and check user policy, queue behavior, or Direct Routing signaling next. [✅Source-1]
What 486 Means in Teams Phone
In SIP itself, 486 Busy Here means the called endpoint is not willing or not able to take another call at that end system. Engineers often compare this behavior with other documented Microsoft Teams phone system error codes to determine whether the busy signal originated from a user endpoint, queue logic, or Direct Routing signaling. That definition matters because it tells you this is not a vague failure bucket. It is a busy-state response, and your job is to find which component declared itself busy. [✅Source-2]
| Where You See 486 | What It Usually Means | Where to Fix It |
|---|---|---|
| User calling or receiving a PSTN call | User is already on a call, or busy handling is forcing a reject | Calling policy and unanswered settings |
| Bot, recorder, or app-assisted call | The bot declined the call because it was busy | Bot provider or Microsoft-supported bot path |
| Call queue path | Agent selection logic, presence, opt-out, or no-agent handling changed the result | Call queue configuration |
| Direct Routing traces | SBC or carrier signaling mapped the busy response in an unexpected way | SBC rules, SIP flow, carrier behavior |
The common mistake: treating every 486 as “the person was already talking.” Sometimes yes. Sometimes no. Bot traffic, queue routing, and Direct Routing signaling can all land on the same visible code.
Where to Check First
- Confirm the call type: user-to-user, PSTN, call queue, or bot-assisted.
- Check whether the user was already in a call, conference, or hold state when the failure happened.
- Look for a Final Microsoft subcode. A plain 486 and a 486 with 10321 do not point to the same fix path.
- Note the caller experience: busy tone, voicemail, repeated missed calls, no ringback, no audio, or a timed drop.
- If Direct Routing is involved, pull the SIP call flow before editing SBC rules.
The Teams PSTN usage report helps here. On the Direct Routing tab, admins can review SIP call flow, Final SIP code, Final Microsoft subcode, Final SIP phrase, and the Correlation ID. Microsoft also notes that these reports usually show a 24 to 48 hour latency, so check the timing before assuming the record is missing. [✅Source-3]
How to Fix 486 When a User Is Already Busy
Microsoft’s Busy on Busy during calls setting is often the fastest fix for ordinary user cases. It controls what happens when a user is already in a call, conference, or hold state. The available behaviors are Off, On, Use unanswered settings, and Let users decide. Microsoft states that this setting is Off by default. [✅Source-4]
- Open Teams admin center and go to Voice > Calling policies.
- Edit the policy assigned to the affected user.
- If callers should hear a busy tone immediately, set busy handling to On.
- If callers should reach voicemail or another forward target, choose Use unanswered settings.
- Save the policy, then verify the user’s own unanswered rule in Teams.
Use unanswered settings is usually the cleaner choice when the business wants continuity instead of a hard busy result. It lets Teams follow the user’s unanswered path, such as voicemail or forwarding, rather than ending the call at the first busy signal.
Set-CsTeamsCallingPolicy -Identity Global -BusyOnBusyEnabledType UnansweredThis PowerShell setting applies the busy behavior at policy level. Replace Global with a custom policy name when you want a narrower scope.
How to Fix 486 in Call Queues
Call queues can create busy-looking outcomes even when the user is not manually rejecting calls. Microsoft states that presence-based routing uses agent availability to decide who can receive calls, that Longest Idle automatically enables presence-based routing, and that the recommended Agent alert time is at least 20 seconds. Microsoft also notes a 15-minute sync window for Shifts-based adjustments. [✅Source-5]
| Queue Symptom | What to Review | Practical Change |
|---|---|---|
| Calls skip agents unexpectedly | Presence-based routing and agent availability | Confirm agents are truly Available, not just signed in |
| Queue feels too aggressive | Agent alert time | Raise ringing time to at least 20 seconds |
| No one gets the call | Opt-out or no-agent handling | Check opt-out state and queue exception handling |
| Behavior changes right after Shifts edits | Shifts synchronization delay | Wait for the sync window before testing again |
- Prefer Round Robin or Longest Idle for steadier distribution.
- Turn Presence-based routing on unless your design needs a different behavior.
- Allow agents to opt out only when that is part of the operating model.
- Test with agents set to Available, not Busy, Away, or Appear Offline.
- Recheck queue exception handling before assuming the carrier is at fault.
Set-CsCallQueue -Identity <CallQueueGUID> -RoutingMethod LongestIdle -PresenceBasedRouting $true -AllowOptOut $true -AgentAlertTime 20How to Fix 486 on Direct Routing
Direct Routing is where 486 analysis gets technical. Microsoft documents one case in which repeated missed calls happen because different standards map SIP 486 to different Q.850 cause codes. In Microsoft’s example, RFC 4497 maps 486 to cause 34, while ND1017:2006/07, used by Direct Routing, maps it to cause 17. Microsoft’s published fix is to remove the mapped Q.850 cause code for 486 or change it from 34 to 17. [✅Source-6]
| Observed Behavior | Technical Clue | Fix Direction |
|---|---|---|
| Multiple missed call notifications after one busy event | Q.850 mapping or carrier retries | Adjust SBC manipulation rules; stop post-486 retries |
| No ringback while the call is trying to connect | SIP 180 followed by 183 with SDP early media handling | Update SBC handling of multiple 18x responses |
| Call drops after about 4 seconds | SIP 100 Trying or ACK path issue | Check firewall, signaling reachability, and ACK behavior |
| No audio, then failure after 10 to 20 seconds | ICE or SDP media path problem | Verify ICE candidates and media negotiation |
| Call drops after 10 to 60 minutes | Session refresh failure | Inspect SESSION-EXPIRES and re-INVITE timing |
- Pull the SIP ladder for the failed call.
- Check whether the final record shows only 486 or a 486 plus Microsoft subcode.
- If the caller gets repeated retries, inspect Q.850 cause mapping first.
- If ringback is missing, review how the SBC handles 180 Ringing and 183 Session Progress.
- If the call fails around 4 seconds, verify that signaling is not blocked and that SIP acknowledgments are complete.
- If the call fails around 10 to 20 seconds, test the media path and ICE negotiation.
- If calls end after 30 minutes or another session timer boundary, inspect SESSION-EXPIRES and session refresh ownership.
SESSION-EXPIRES: 1800;refresher=uacMicrosoft uses this 1,800-second example to explain timed call drops tied to session refresh logic. Halfway refresh timing matters. So does which side owns it.
Admin Checks That Save Time
For user-facing PSTN cases, Microsoft provides a built-in Teams PSTN self-diagnostic that verifies whether a user is properly configured to make or receive PSTN calls. That is a fast way to rule out licensing, phone-number, and voice setup problems before you start tracing SIP. [✅Source-7]
For SBC-connected environments, Microsoft also provides a Teams Direct Routing self-diagnostic that checks whether a user is correctly configured for Direct Routing. Run it before changing voice routes, normalization rules, or carrier settings. Short path. Good signal. [✅Source-8]
If the tenant uses Direct Routing heavily, keep the troubleshooting order tight: policy first, queue logic next, SIP flow after that, then SBC manipulation rules. Editing the SBC too early slows everything down and can blur the original failure pattern.
FAQ
Does Microsoft Teams Phone error 486 always mean the person is already on another call?
No. 486 is a busy-state response, but the busy component can be a user, a bot, a call queue path, or the Direct Routing signaling chain.
What does Microsoft subcode 10321 mean with 486?
Microsoft documents 10321 + 486 as a case where a bot rejects the incoming call because it is busy. That points you toward the bot provider, recording path, or Microsoft-supported bot service rather than a normal user-busy setting.
Should I use Busy on Busy or unanswered settings?
Use Busy on Busy = On when the caller should hear a hard busy result. Use Use unanswered settings when the caller should still reach voicemail or another forward target.
Can a call queue create 486-like call failures?
Yes. Presence-based routing, opt-out state, no-agent handling, and short alert timing can all change how the call is treated and can make the result look like a busy rejection.
Why does the call fail after 10 to 20 seconds with no audio?
Microsoft links that pattern to media setup problems, especially missing or incorrect ICE candidates and SDP-related negotiation issues between the SBC and the Teams path.
Why do some calls end after about 30 minutes?
That usually points to a session timer refresh problem. Check SESSION-EXPIRES, confirm which side owns refresh behavior, and verify that the expected re-INVITE is being sent before the timer expires.