Microsoft Teams Phone: Error Code 603 usually points to a call outcome, not to a broken app by itself. In Microsoft’s own signaling references, the same 603 can show up as “did not answer” in voice flows, as “declined” in conference or sharing flows, and as “participant not available” during some transfer cases. Read it as a status of what happened to the call path. Not as automatic proof of a wider Teams failure. [✅Source-2]
That detail matters because Error Code 603 sits inside a platform Microsoft describes as serving over 320 million monthly active users. When a code changes meaning across call legs, support teams need a tighter reading of the record, the device state, and the route that handled the call. [✅Source-1]
Table of Contents
Start with three questions. Did the target reject the call, did the call ring out without answer, or did a transfer leg become unavailable? In Direct Routing environments, ask one more: did the SBC or provider retry after a decline and create extra missed calls?
603Primary Signal
Call disposition, not a single universal fault.
3478–3481Client Media Ports
Teams uses these UDP ports for core media roles.
49152–53247Direct Routing Media
Used on the media processor side for Direct Routing.
>500 ms / >30 ms / >0.1CQD Poor Audio Flags
Round trip, jitter, and packet loss thresholds for poor streams.
What Error Code 603 Means in Teams Phone
Error Code 603 is better read as a final state of the call attempt than as a single root cause. On one record it may tell you the call was not answered. On another, it may show that the invitation was declined. In a transfer path, it can mean one participant was not available at that moment. Same number. Different call context. When you see patterns like this, it helps to compare the behavior with other entries in a broader Microsoft Teams error codes reference to understand how different Teams signaling outcomes are interpreted across call flows.
| Where 603 Appears | Typical Message | What It Usually Tells You |
|---|---|---|
| Voice calling | User did not answer | The call reached the far side but ended without answer. |
| Transfer flow | Cannot complete the transfer | One participant was not available at that time. |
| Conference or sharing flow | Declined your invitation | The invitation was explicitly declined. |
| Direct Routing SIP handling | 603 response / decline handling | The SIP leg returned a decline-style final response. |
| Nearby code to compare | 606 = Do Not Disturb | Do not merge 603 and 606 into the same diagnosis. |
Microsoft’s signaling tables separate 603 from 606, and that helps. When the record says 603, start with no-answer, decline, or temporary participant availability before you jump to a policy block or a service-wide issue. [✅Source-2]
For Direct Routing, Microsoft adds one very practical note: when users see several missed calls for one declined call, the SBC or PSTN trunk retry logic is usually the place to inspect. In other words, the retry behavior can become the visible problem even when the first call outcome was already final. [✅Source-3]
What Usually Triggers Error Code 603
- The far end let the call ring out. The user did not answer before the call timer expired.
- The call was rejected on one endpoint. This matters more in environments with multiple devices, delegation, or simultaneous ringing.
- A transfer target was not available. The original leg may be healthy while the transfer leg fails.
- The SBC or carrier retried after a final response. Users then see duplicate or repeated missed-call behavior.
- The code was read too broadly. Many teams blame the network first; often, the call simply ended without answer.
Useful Reading Rule
If Error Code 603 shows up for only one user, one number, or one transfer target, start with endpoint behavior and call routing. If it appears across many users in one site, then widen the scope to firewall rules, SBC health, or trunk behavior. Narrow first. Faster, and usually more accurate.
Checks Users Can Do First
- Retry the same target from a different client. Test the desktop app, web app, mobile app, or the Teams phone itself. A single-client failure often points to local client state.
- Ask whether the other side actually saw the call. A quick confirmation separates declined from never rang and saves time.
- Review forwarding and simultaneous ring behavior. The ringing logic can make a simple no-answer case look messy.
- On a Teams phone, sign out and sign back in. Then place one internal call and one external call. Keep the test small and clean.
- Test a direct call and a transfer separately. If direct calls work but transfers fail with 603, the transfer target or transfer path deserves the attention, not the whole phone system.
Do not skip the smallest test. One user to one user. One user to PSTN. One transfer. A short sequence like that often tells you more than a long, messy reproduction attempt.
Admin Checks That Find the Real Cause
In the Teams PSTN usage report, the Direct Routing tab exposes the call start and end times, the SIP address, the visual SIP call flow, the Final SIP code, the Final Microsoft subcode, and the final phrase for the call. For a 603 case, that is usually the fastest place to confirm which leg ended the call and what label Microsoft assigned to the ending. [✅Source-8]
Call Analytics adds the user-level view: device details, network details, connectivity data, and call quality data for the affected user. Microsoft also notes that admins can review the user’s calls and meetings from the last 30 days in this view. That makes it easy to compare one bad event with normal sessions from the same user. [✅Source-9]
In Direct Routing, keep the SBC side visible all the way through. Microsoft says the service monitors SBC health with SIP OPTIONS; an SBC sends options every minute, and the route treats it as healthy when options were seen during the last three minutes. If a 603 appears beside route instability, slow failover, or intermittent carrier behavior, check the SBC health timeline before you blame the endpoint. [✅Source-11]
- Read the final code and final phrase first.
- Open the SIP call flow and align the timestamps with the user complaint.
- Match the event with SBC logs if you use Direct Routing.
- Check whether the failure is direct-call only, transfer only, or PSTN only.
- Only after that should you widen the blast radius. Rarely is 603 the first code that should send you straight to a Microsoft-wide outage assumption.
Network and SBC Details That Matter
For standard Teams calling, Microsoft says clients need TCP 80 and 443 and UDP 3478, 3479, 3480, and 3481. When those basics are filtered or treated inconsistently, support teams can end up reading a call-end code while the real trouble started earlier in setup or media negotiation. [✅Source-5]
For Direct Routing, Microsoft lists the media processor IP ranges as 52.112.0.0/14 and 52.120.0.0/14. It also lists UDP/SRTP ports 3478–3481 and 49152–53247 and recommends at least two ports per concurrent call on the SBC. Those numbers are not background trivia. They are the first firewall and capacity checks when 603 starts appearing across a site or trunk. [✅Source-4]
| Area to Verify | What to Look For | Why It Matters for 603 Cases |
|---|---|---|
| Client connectivity | 80/443 TCP and 3478–3481 UDP open and stable | Bad setup conditions can blur the real reason a call ended. |
| SBC media capacity | Enough ports for active concurrency | Port pressure can create erratic behavior that users describe poorly. |
| Direct Routing route health | SBC monitoring, carrier path, timing of OPTIONS | Intermittent route problems can sit beside 603 and mislead first-line support. |
| Retry behavior | Repeated invites after a decline | One declined call can look like several missed calls. |
When 603 Is Not the Main Problem
A 603 record answers how the call attempt ended. It does not fully answer how the media performed. Microsoft’s CQD stream classification marks audio as poor when round trip is above 500 ms, packet loss rate is above 0.1, or jitter is above 30 ms. Those thresholds help you separate a call-outcome label from an actual quality problem. [✅Source-6]
If users report that calls “fail” but the records vary from one device or one site to another, run the Microsoft Teams Network Assessment Tool. Microsoft says the tool tests the path to the nearest Teams relay and collects loss, jitter, and round-trip time. That gives you a cleaner baseline than guesswork. [✅Source-7]
Microsoft also groups troubleshooting into four lanes: CQD for org-wide patterns, Call analytics for individual calls, Real-time analytics for in-progress scheduled meetings, and QoS for traffic priority. Use the lane that matches the symptom. Clean method, fewer false leads. [✅Source-10]
Keep the questions separate. 603 asks, “How did this call attempt end?” CQD and network testing ask, “How healthy was the path?” Mixing those two questions slows troubleshooting every time.
FAQ
Does Error Code 603 Always Mean the Other Person Rejected the Call?
No. In Teams Phone records, Error Code 603 can point to did not answer, declined, or a participant unavailable state in a transfer path. The call context decides the reading.
Why Did One Declined Call Create Several Missed Calls?
That pattern usually points to retry behavior on the SBC or PSTN trunk. In Direct Routing, Microsoft explicitly tells admins to inspect retry handling when one declined call produces multiple missed-call traces.
Is 603 Usually a Service Outage Code?
Usually no. 603 is more often a call-disposition code. When the main issue is network quality or service responsiveness, the deeper evidence usually shows up in call flow details, CQD, or other SIP responses.
Where Should an Admin Look First for a 603 Case?
Start with the PSTN usage report and the SIP call flow for the affected call. Then open Call Analytics for the affected user. If Direct Routing is involved, line up those findings with SBC logs.
Can Poor Audio Quality by Itself Produce a 603 Record?
Not directly. 603 describes how the call attempt ended. Poor audio is measured with different signals such as latency, jitter, and packet loss. A call can connect badly, or end cleanly, without those being the same problem.