Microsoft Teams Phone — Design Reference

For reuse in documentation that renders Mermaid. The SVG above is hand-drawn so this page stays self-contained and needs no renderer.

flowchart LR
  PSTN[External PSTN callers] --> CAR[PSTN carrier]
  CAR --> TP[Microsoft Teams Phone]
  CAR -.Direct Routing, when required.-> SBC[Certified SBC]
  SBC -.SIP over TLS.-> TP
  TP --> AA[Auto Attendant]
  AA --> CQ1[Sales queue]
  AA --> CQ2[Support queue]
  AA --> CQ3[Billing queue]
  AA --> REC[Reception / operator]
  AA --> VM[Shared voicemail]
  CQ1 --> U[Teams users]
  CQ2 --> U
  CQ3 --> U
  CQ1 -.overflow / timeout.-> VM
  CQ2 -.overflow / timeout.-> VM
  CQ3 -.overflow / timeout.-> VM
  ENT[Microsoft Entra ID] --> TP
  TAC[Teams admin center] --> TP
  TP --> CQD[Call Analytics and Call Quality Dashboard]

flowchart TD
  IN[Call to main business number] --> SCHED{Schedule}
  SCHED -->|Business hours| MENU[Auto Attendant menu]
  SCHED -->|After hours| AH[Announcement] --> SV[Shared voicemail]
  SCHED -->|Holiday| HOL[Holiday greeting] --> SV
  MENU -->|1| SALES[Sales queue]
  MENU -->|2| SUP[Support queue]
  MENU -->|3| BILL[Billing queue]
  MENU -->|0| OPR[Reception]
  MENU -->|No input or invalid| OPR
  SALES -->|Answered| AG[Representative]
  SALES -->|Overflow or timeout| SV
  SUP -->|Overflow or timeout| SV
  BILL -->|Overflow or timeout| SV

1. Confirm the user is actually voice-enabled and holds both a Teams Phone license and, where the model requires one, a PSTN service license. A license assigned an hour ago may not have propagated.
2. Check the number assignment exists and is in E.164 with no tel: prefix. Assigning a number sets enterprise voice enabled automatically, so if that flag is false the assignment probably did not take.
3. Look at the calling policy. A restriction that blocks the call type is the answer more often than anything technical — and it should be, because that restriction was deliberate.
4. Test what the user dialed against the effective dial plan. If normalization produces something other than a valid E.164 number, the routing layer never gets a chance.
5. For Direct Routing, confirm a voice routing policy is assigned, then walk the chain: policy to usages, usages to routes, routes to gateways. Remember the first matching usage wins and later usages are never evaluated, so a route that looks correct can be shadowed by one above it.
6. Check the gateway is enabled and not drained.

1. Confirm the number is assigned to the object you think it is. A number that was moved during testing and never moved back is a common cause.
2. Establish where the call is dying: at the carrier, at the SBC, or in Teams. The usage report and, for Direct Routing, the SIP ladder will tell you whether the call reached Microsoft at all.
3. If the call never reaches Microsoft, it is a carrier or porting question, not a Teams question. Check the port completed and the number is live on the intended trunk.
4. For Direct Routing, check the inbound number format the carrier is sending. A carrier presenting a national-format number against a route expecting E.164 fails silently.
5. Check the target object’s state — a resource account missing its license, or one that had Teams Phone Standard assigned to it by mistake, will not answer.

1. Confirm which call flow is actually running. Nine times in ten the answer is a time zone: the schedule is correct in local terms and the attendant is evaluating it somewhere else.
2. Check the holiday set. Holidays take precedence over both other flows, so a stale entry silently overrides everything on the day it matches.
3. Verify each menu key maps to the destination on the signed-off call tree, and that the destination object is voice-enabled and licensed.
4. Check the operator is set. If it is not, the failure path and the no-input path have nowhere to go.
5. Count the transitions if attendants are chained. Twenty-five transitions across voice applications is the ceiling, after which the call is disconnected — which presents as a mysterious drop rather than an error.
6. For external transfer targets, confirm the licensing that permits an outbound call on behalf of the resource account. This changed on 1 November 2025 and a configuration that worked before then can stop working with no change at your end.

1. Check membership resolved. Group and channel-based membership takes time to become operational after a change — hours, not minutes — so a queue built and tested in the same session can look broken when it is only slow.
2. Check whether presence-based routing is on. If the routing method is longest idle it is on whether or not anyone chose it, and anyone on Do Not Disturb is being skipped by design.
3. Check who has opted out. Opt-out is enabled by default and people use it.
4. Confirm every member is individually voice-enabled and licensed. One unlicensed member in a group does not break the queue, it just quietly never rings.
5. Check the agent alert time against the routing method. Serial routing with a long alert time can exhaust the queue timeout before it reaches the third person.
6. If conference mode is on, confirm the client estate supports it — and note it is not supported for calls arriving through a gateway enabled for location-based routing.

1. Confirm which caller ID policy the user has. A user with no policy assigned gets the global one, which presents their own number.
2. Check the substitution method. If the policy was written against the deprecated service-number method it needs rebuilding with resource-account substitution.
3. Confirm the resource account named in the policy still holds the number you expect.
4. For Direct Routing, check whether the SBC or the carrier is rewriting the calling number downstream. Teams can present exactly the right identity and the carrier can replace it.
5. Check any number translation rules on the gateway. These are easy to forget because they live outside Microsoft 365 entirely.

1. Start at the health dashboard. It reports SIP OPTIONS status, TLS connectivity, network effectiveness ratio and concurrent calls against the configured maximum, which usually names the problem before you touch the SBC.
2. Check certificate expiry. The dashboard warns at 30 days, and an expired certificate is a total outage rather than a degradation.
3. Confirm DNS still resolves the SBC FQDN to the expected public address, and that the name matches the certificate subject or a SAN.
4. Check whether OPTIONS are being sent at all. A trunk configured not to send them cannot report health, and the dashboard says so explicitly rather than showing a fault.
5. Look at concurrent sessions against the configured maximum. A trunk at its ceiling rejects calls while appearing entirely healthy.
6. Confirm the firewall still permits signaling to Microsoft’s SIP proxies and media on the required ranges. Firewall changes made for other reasons are a recurring cause.

1. This is almost always media path, not signaling — signaling clearly worked, because the call connected.
2. Check firewall rules in both directions for the media ranges. A rule that permits outbound but not the return flow produces exactly this symptom.
3. Check NAT behaviour. Symmetric NAT and inconsistent address translation break the media negotiation while leaving signaling intact.
4. For Direct Routing, confirm the media ranges are open to the SBC in both directions, and that the SBC has enough ports — Microsoft recommends at least two per concurrent call.
5. If media bypass is enabled, confirm the SBC public address is actually reachable from the client. If it is not, the call should fall back rather than fail, so failing here points at a partial reachability problem.
6. Check for a device inspecting or rewriting media in the path.

1. Treat this as a symptom rather than a setting. TCP works and sounds worse; something is blocking UDP.
2. Check UDP 3478–3481 outbound to the Microsoft 365 Optimize ranges. A firewall permitting only TCP 443 produces exactly this.
3. Check whether a proxy is in the path. Media has no URL, so a proxy configured by URL will not catch it, and a device forcing all traffic through TCP will.
4. Check VPN routing. Media pulled into a tunnel often loses UDP along the way.
5. Confirm the client version is recent enough to honour the intended routing in the VPN scenario in use.

1. Get specifics before touching anything. Which users, which sites, wired or wireless, which times of day, one direction or both.
2. Look at Call Analytics for an affected session and read jitter, packet loss and round-trip time on each stream. Poor thresholds are jitter above 30 ms, average loss above 10 percent, round-trip time above 500 ms.
3. Use the Call Quality Dashboard to find the shape of the problem — whether it clusters by building, subnet, wireless access point, VPN, or client version. A single bad call tells you little; a cluster names the cause.
4. Check whether QoS marking survives the whole path. Marking at the endpoint that a switch or firewall clears is the most common finding, and it is invisible from the Teams side.
5. Check wireless coverage and roaming for the affected area rather than signal strength at one desk.
6. Rule out the endpoint. Headset firmware and USB power management account for a surprising share of complaints that telemetry says are clean.

1. Separate personal voicemail from shared voicemail — they fail for different reasons.
2. For personal voicemail, check the user’s voicemail settings and calling policy, and confirm the mailbox itself is healthy.
3. For shared voicemail, confirm the target group mailbox exists and that the group is configured to accept mail from outside the organization. This one setting accounts for most shared-voicemail failures.
4. Confirm the queue’s overflow and timeout actions actually point at shared voicemail rather than at a destination that was changed during testing.
5. Check whether transcription is expected and whether the language is supported, because a missing transcript often gets reported as a missing message.

1. Confirm the address is validated. An unvalidated address cannot be assigned to users or network identifiers at all.
2. Check the address has geo coordinates. Without them it cannot be used for dynamic location.
3. Check the address age. Addresses more than a couple of years old cannot be assigned to network identifiers, which turns into a silent failure on a record nobody has touched in a while. Re-create rather than edit.
4. Confirm the client’s external IP matches the trusted IP list. If it does not, the client is treated as outside the corporate network and subnet-based lookup will not run. Note that switch, port and access-point lookups proceed regardless.
5. Check the subnet entry uses the network address rather than a client address — a frequent and easily missed error.
6. Allow for propagation. Network configuration changes take up to four hours, so a change made this morning may simply not be live yet.
7. Check the client type. Access-point-based location is not supported on Teams phones, and the remote-user confirmation experience is desktop only.