Learn › Microsoft Teams › 5 · Calling & Enterprise Voice

PSTN connectivity: the three roads to the phone network

Teams Phone is one product with three completely different ways to reach the public phone network. Pick wrong and you re-architect in two years; most real estates end up running two of them at once.

The flow — what actually happens

Plain-language first; the packet-level view underneath each step is what you'd see in a Wireshark trace, and what healthy looks like.

  1. A user dials +44 20 7946 0958

    Regardless of which road you bought, the first hop is identical: the Teams client sends the dialled digits to the Teams calling service, which normalises the number (your dial plan), checks the user's calling policies, and asks one question — WHO carries this call to the phone network for this user?

    On the wire HTTPS 443 signalling to the Teams service. Identical for all three options — a packet capture cannot tell you which PSTN road a tenant uses at this stage.
  2. The routing decision

    Calling Plan user: Microsoft is the carrier, the call stays entirely inside Microsoft's cloud. Operator Connect: the call hands off to your operator's infrastructure, pre-plumbed into Microsoft's network. Direct Routing: the service consults YOUR voice routing policy — usages, routes, and finally your SBC's FQDN.

    On the wire Still nothing at your site for the first two. For Direct Routing, Microsoft's proxy opens SIP-over-TLS toward your SBC's public interface (port you configured, typically 5061) — the first packet that is yours to capture.
  3. Media takes its own road

    Voice packets do not follow the signalling. Calling Plan/Operator Connect: client media goes to Microsoft relays as in any call. Direct Routing without bypass: media hairpins client → Microsoft → SBC. With media bypass enabled: the client sends SRTP STRAIGHT to your SBC — shortest path, and the reason bypass exists.

    On the wire Direct Routing with bypass is unmistakable: client SRTP to the SBC's public IP instead of Microsoft ranges. Without bypass: standard relay traffic plus a second leg Microsoft to SBC that you only see on the SBC's own capture.
  4. The SBC talks to the trunk

    Direct Routing only: your SBC converts the call to whatever your carrier speaks — SIP trunk, ISDN, an analogue gateway in a warehouse. This is the flexibility you paid the complexity tax for: any carrier, any country, any legacy equipment.

    On the wire Carrier-side SIP/RTP per your trunk config. Health underneath it all: Microsoft sends SIP OPTIONS to your SBC continuously — an SBC that stops answering drops out of routing (that is the failover mechanism, and your early-warning signal).

One product, three carriers

Calling Plan Operator Connect Direct Routing
Who is the carrier Microsoft A partner operator Whoever you contract
Your infrastructure None None SBC(s) you run (or host)
Number management M365 admin center Operator portal → TAC You + carrier
Countries Microsoft's list only Operator's footprint Anywhere you can get a trunk
Analogue/legacy kit No No Yes (via SBC/ATA)
Complexity Lowest Low Highest
Typical fit Small/simple estates Mid-size, carrier relationship Global, legacy, contact centres, cost-optimised minutes

The honest architecture note: large estates usually run a mix — Operator Connect or Calling Plans for simple countries, Direct Routing where there is legacy kit, a favoured carrier, or no Microsoft/operator coverage. Teams supports per-user coexistence; design for it rather than pretending one road fits every country.

What each road actually is

Calling Plans — Microsoft is your telco. Numbers, minutes and emergency services all come from Redmond. You trade money and flexibility for zero infrastructure. The ceiling: country coverage, calling-plan economics at volume, and no path for analogue devices.

Operator Connect — the operator pre-builds Direct Routing INTO Microsoft's network and sells it as a service. You get carrier pricing and support with no SBC to own. The trade: you are inside the operator's footprint and feature set, and moving operators later is a number-porting project.

Direct Routing — you (or a hosting partner) run certified SBCs pairing with Microsoft over SIP/TLS. Total freedom: any carrier, least-cost routing, analogue integration, survivability appliances at branches. Total responsibility: certificates, trunk health, capacity, and every failure between Teams and the carrier is yours to triage.

Failure signatures

Symptom Likely cause
All outbound dead, one Direct Routing site SBC dropped from rotation — check whether it's answering Microsoft's SIP OPTIONS, and its TLS cert expiry
Outbound works, inbound dead (DR) Carrier trunk or number routing at the carrier — Microsoft never saw the call
"Call failed" instantly for one user No voice routing path for that user's dialled number: usage/route/policy mismatch, or unassigned number
One-way audio on DR only Media bypass enabled but client cannot reach the SBC's public media interface (firewall assumed hairpin)
Dead air then drop at exactly 30–32 s Signalling answered but ACK/media path broken — classic NAT/SIP-ALG interference at the SBC edge
Random users can't dial premium/international Different calling policies or usages — compare Get-CsOnlineVoiceRoutingPolicy assignments, not the SBC

Choosing (and re-choosing)

Start from constraints, not preference: countries with no Calling Plan/operator coverage → Direct Routing is decided for you. Analogue anything → Direct Routing. No telecoms skills in-house and coverage fits → Calling Plans or Operator Connect. Contact centre with least-cost routing ambitions → Direct Routing, budget for real SBC expertise. And whichever you pick: the migration between roads is mostly a number-porting and user-policy exercise — painful but survivable, which is why the mixed estate is a legitimate end state, not a failure.

The wire

  • Signalling: client -> Teams service HTTPS 443 (identical on all three roads)
  • Direct Routing pairing: Microsoft proxy <-> SBC, SIP over TLS (sip.pstnhub.microsoft.com), certs mandatory
  • Health: continuous SIP OPTIONS from Microsoft to the SBC — no answer = out of rotation
  • Media bypass: client SRTP direct to SBC public IP; without it, media hairpins via Microsoft

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.