Microsoft Teams Phone error code 600 usually points to one thing: the destination is already busy. In Microsoft’s own SIP error mapping, voice code 600 is shown as the other person being in another call, and the same family of behavior also appears when a transfer target is occupied. That changes the whole troubleshooting path. You are not chasing a random app crash first; you are checking whether the call hit a busy person, busy route, or busy policy instead. [✅Source-1]
At the protocol layer, 600 means Busy Everywhere. In plain English, the call attempt reached the far side, but there was no alternate endpoint available for that attempt. That is why reinstalling Teams often does nothing for this code by itself. The real fix sits in call handling, routing, or availability. [✅Source-2]
Table of Contents
What Error Code 600 Means
Error 600 is a busy-state response, not a format error, not a codec mismatch, and not the usual sign of a broken installation. Most of the time, the call landed on a person who was already occupied, a transfer target that could not accept another call, or a route that had no usable fallback at that moment. Short version? The destination could not take your call right then.
Where this code usually comes from:
- A direct Teams call to someone who is already speaking on another Teams or PSTN call.
- A transfer attempt to a person whose line is occupied.
- A tenant policy that rejects second calls with a busy result.
- A personal number being used where a call queue or auto attendant would fit better.
- A shared number design where users expect personal forwarding rules to apply, but the queue logic behaves differently.
Codes That Users Commonly Mix Up With 600
| Teams Voice Code | What It Usually Means on Screen | What to Check First |
|---|---|---|
| 600 | The other side is in another call or the transfer target is busy | Availability, Busy on Busy, transfer path |
| 603 | The other side did not answer | Ring duration, forwarding, voicemail path |
| 606 | The other side is set to Do Not Disturb | Presence, priority access, call routing rules |
| 504 | The calling service did not respond | Service path, transient routing issue, retry timing |
| 484 | The dialed number format is invalid | Dial plan, normalization, typed number format |
One detail worth knowing: Teams can expose more than one “busy-style” outcome. Engineers often compare these outcomes across broader Microsoft Teams error code patterns to see whether the difference comes from the user endpoint, a transfer step, or the SIP signaling layer. So if one user reports 486 and another reports 600, they may still be describing the same practical experience from different points in the SIP path. That is why the call flow, not just the number on the pop-up, deserves attention.
Why Teams Phone Shows This Code
Teams Phone includes a setting called Busy on Busy. Microsoft says it can control how incoming calls behave when a user is already in a call, in a conference, or has a call on hold. Depending on configuration, the caller may hear a busy signal or be routed through the callee’s unanswered-call handling. Microsoft also notes that this feature is disabled by default. [✅Source-3]
Admins do not manage that behavior in random places. It sits in Voice > Calling policies in the Teams admin center, alongside forwarding, call groups, delegation, voicemail, and related calling controls. When error 600 appears for many users, the first admin question should be whether the assigned calling policy is intentionally rejecting second calls. [✅Source-4]
Patterns Often Seen on the User Side
- The recipient is already on another call and the tenant allows no second-call presentation.
- The user expected call waiting, but the policy uses a busy result instead.
- The call is being transferred to a person, not to a queue, and that person is occupied.
- A desk phone and desktop client are both signed in, yet the call handling rules are still tied to the same busy state.
Patterns Often Seen on the Admin Side
- Busy on Busy is enabled for the assigned calling policy.
- Simultaneous ring, delegates, or unanswered routing are not configured the way staff assume.
- A department is using personal lines instead of a shared voice design.
- Users are judging queue calls as if they were normal personal calls, which leads to wrong fixes.
Checks That Save Time
- Ask whether the failed call was a direct call, a transfer, or a call into a shared department number.
- Check whether the target person was already in a Teams call, PSTN call, or meeting at the same moment.
- Look at whether the issue affects one user or many users with the same policy.
- Retry from another client type if possible: desktop, mobile, or certified phone. This helps separate routing behavior from one-device confusion.
- Notice the exact outcome. Busy tone, immediate failure, voicemail, or no answer each point in a different direction.
- For department numbers, verify whether the call is reaching a queue resource account or a person’s own line.
That last check matters more than many teams realize. A personal line, a delegated line, and a call queue can all look similar to the caller while behaving very differently under load.
Actions End Users Should Take
Teams gives users direct access to their calling setup. Under Settings > Calls, users can review call answering rules, forwarding behavior, voicemail handling, delegates, and ringtones. On desktop, they can also run Make a test call from device settings to confirm that mic and speaker behavior is normal before they blame call routing. [✅Source-5]
- If the same colleague triggers error 600 repeatedly, message them first and confirm whether they are already on a call.
- If you are the person receiving the call, review Call Handling and Forwarding so callers do not hit a dead end when you are occupied.
- If your desk phone and desktop app both ring in confusing ways, keep the rules simple: either forward, use simultaneous ring, or let voicemail take the unanswered path.
- If calls fail only during heavy network use, open Call Health during a live call instead of guessing.
- If a transfer keeps failing with 600, transfer to a queue, delegate, or voicemail path rather than back to the same busy person.
A simple rule works well here: if the problem follows one person, inspect that person’s availability and call rules. If it follows a team or department, inspect policy and routing.
Actions Admins Should Review
Admins can inspect a user’s voice behavior from the Voice tab in the Teams admin center. Microsoft states that if the Voice tab is not visible, the user does not have a Teams Phone license assigned. The same admin flow also exposes immediate forwarding, simultaneous ring, unanswered delay, and delegation, while PowerShell can show the current state with Get-CsUserCallingSettings. [✅Source-6]
- Check the assigned calling policy first. If many users see 600 while already busy, review whether Busy on Busy is enabled or routed to unanswered handling.
- Open the user’s voice settings and confirm whether calls ring only their own devices, ring delegates too, or forward immediately.
- Review unanswered delay. A delay that is too short can make users feel like calls are being rejected when the system is really moving them on too fast.
- Inspect transfer targets. If staff are trained to transfer to a person instead of a queue, repeat busy responses are normal.
- For front desks, service teams, and reception roles, move away from personal DIDs where possible and use shared voice routing.
Shared Numbers and Call Queues
For shared inbound traffic, a call queue is usually the cleaner design. Microsoft describes call queues as waiting areas where callers stay on hold until the next available agent can take the call. That setup fits reception, sales, service, and other roles where the caller needs someone available, not one exact person. [✅Source-7]
There is a detail many teams miss. Microsoft also says that call queue calls do not follow the user’s personal call-answering rules, and agents do not receive missed-call or voicemail notifications for those queue calls. So if a department number behaves differently from a personal number, that is not strange behavior; it is expected queue logic. [✅Source-8]
Use a personal line when the caller needs one person. Use a queue when the caller needs the next free person. Mix those two models, and error 600 reports pile up fast.
Network and Call Quality Data Worth Checking
Not every 600 case is a network case, but weak media conditions often make users describe several different calling problems as “the same error.” In Teams Call Health, Microsoft says metrics refresh every 15 seconds. The support ranges shown there are practical: round-trip time under 200 ms, received packet loss under 2%, and received jitter under 30 ms. [✅Source-9]
| Metric | User-Friendly Value to Aim For | Why It Matters |
|---|---|---|
| Round-trip time | < 200 ms | Higher delay makes call setup and response feel sluggish |
| Received packet loss | < 2% | Lost packets can create clipped or broken audio |
| Received jitter | < 30 ms | Packet timing swings can create robotic or uneven sound |
| Audio sent bitrate | 36–128 kbps is typical | Very low bitrate often reflects constrained network conditions |
For tenant-wide analysis, the admin view is stricter in a different way. Microsoft’s Call Quality Dashboard marks an audio stream as poor when packet utilization is high enough and one of these thresholds is crossed: round trip above 500 ms, packet loss rate above 0.1, or jitter above 30 ms. That packet-loss figure is a rate value, so it reads as 10% in percentage terms. [✅Source-10]
Bandwidth matters too, especially when users say busy errors appear “only when everyone is online.” Microsoft’s network planning table lists audio one-to-one minimum bandwidth at 10/10 kbps, recommended at 58/58 kbps, and best performance at 76/76 kbps. For one-to-one video, the published values move from 150/150 kbps minimum to 1,500/1,500 kbps recommended. [✅Source-11]
| Teams Modality | Minimum | Recommended | Best Performance |
|---|---|---|---|
| Audio one-to-one | 10 / 10 kbps | 58 / 58 kbps | 76 / 76 kbps |
| Audio meetings | 10 / 10 kbps | 58 / 58 kbps | 76 / 76 kbps |
| Video one-to-one | 150 / 150 kbps | 1,500 / 1,500 kbps | 4,000 / 4,000 kbps |
| Screen sharing one-to-one | 200 / 200 kbps | 1,500 / 1,500 kbps | 4,000 / 4,000 kbps |
That does not mean poor bandwidth causes code 600 by itself. It means noisy networks make calling behavior harder to read, and they can hide the real busy-state issue behind broader call complaints. First separate availability from media quality. Then the fix becomes much clearer.
FAQ
Does Microsoft Teams Phone Error Code 600 Mean Teams Is Broken?
No. Error 600 usually means the destination is busy or the transfer target cannot accept another call. It is normally a call-state or routing issue, not proof of a damaged Teams installation.
Can an Admin Change How Teams Behaves When a User Is Already Busy?
Yes. Admins can review calling policies, especially Busy on Busy, and they can also inspect user forwarding, delegation, simultaneous ring, and unanswered settings. Those controls often decide whether callers hear a busy result, reach voicemail, or move to another path.
Why Does a Department Number Behave Differently From a Personal Number?
Because many department numbers run through auto attendants or call queues. Queue calls do not behave like normal personal calls, and an agent’s own call-answering rules may not apply to them in the same way.
Should I Reinstall Teams to Fix Error 600?
Usually no. Reinstalling can make sense only after you confirm the problem is local to one device. Most of the time, the faster path is to inspect availability, transfer targets, policy, and queue design.
When Should This Issue Be Escalated?
Escalate when multiple users under the same policy report the same behavior, when a shared number fails under normal traffic, when queue logic does not match the intended design, or when call health shows persistent packet loss, jitter, or delay during the same window.