LearnMicrosoft Teams › 6 · Call flows & troubleshooting

PSTN call flows: where your call actually travels

The same dialled number takes radically different journeys depending on Calling Plan, Operator Connect or Direct Routing — and on whether media bypass is doing its job. Map the legs and 'where did it break' becomes a lookup, not an argument.

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. Leg 1 — client to Teams (identical everywhere)

    The normalisation/authorisation/routing chain (dial-plans concept) runs in the service. The client's only job so far: send signalling and prepare media. Any failure here fails FAST with no ring — the 'instant call failed' class is always this leg.

    On the wire HTTPS signalling; no SIP visible to you on Calling Plan/OC. Instant failures never reach any SBC/carrier log — absence of the call in downstream logs IS the diagnosis.
  2. Leg 2 — Teams to the PSTN edge (the road splits)

    Calling Plan: stays inside Microsoft to their carrier fabric. Operator Connect: crosses the operator's managed interconnect. Direct Routing: SIP INVITE leaves Microsoft for YOUR SBC — the first moment the call exists in equipment you can read.

    On the wire DR only: INVITE at the SBC with the E.164 number, Teams-side correlation ID in headers. Ring-but-never-connect on DR usually dies here-to-leg-3: check the SBC's response codes (4xx/5xx from carrier vs SBC itself).
  3. Leg 3 — media assembles (bypass or hairpin)

    Signalling connected; now audio picks its route. Calling Plan/OC: client relay path to Microsoft, Microsoft to carrier. DR without bypass: client -> Microsoft -> SBC (a hairpin that can cross a continent). DR with media bypass/LMO: client straight to the SBC — the flat, low-latency path bypass exists for.

    On the wire At the SBC: media from Microsoft ranges (hairpin) vs from client IPs (bypass working). One glance at RTP source addresses verifies your bypass design in production.
  4. Mid-call — DTMF, hold, and the carrier's opinions

    Menu digits (RFC2833/RTP events), hold music, transfers — each re-touches the path. Carrier-side quirks (early media, ringback differences, DTMF duplication) surface here and are provider-specific: the same Teams tenant behaves differently per trunk.

    On the wire DTMF visible as RTP event payloads at the SBC — 'IVR doesn't hear my keypresses' is diagnosed in one trace (events absent, duplicated, or re-timed).

The blame-map table

Failure feel Leg First evidence to pull
Instant "call failed", no ring 1 User's routing chain (Test-CsEffectiveTenantDialPlan + policy walk); nothing will exist in SBC/carrier logs
Rings, connects, no audio either way 3 RTP arrival at SBC (DR) / Call Analytics media section (CP/OC)
One-way audio 3 Asymmetric path: bypass reachability one direction, NAT on the return leg
Connects, drops at ~30s 2/3 boundary ACK or media-path confirmation lost — SIP-ALG, NAT timeout at the edge
Caller hears wrong ringback / silence before answer 4 (early media) Carrier trunk config vs SBC early-media handling
IVR ignores keypresses 4 DTMF events in SBC trace

What to watch (proofs)

  • Per-call, service side: TAC PSTN usage report (number as-routed, duration, connectivity type) + the user's Call Analytics entry — start every PSTN ticket by finding the call HERE.
  • Per-call, your side (DR): SBC CDR + SIP/RTP trace matched by time/number — the two-log join answers 'Microsoft or us' definitively.
  • Bypass verification: RTP source IPs at the SBC (clients vs Microsoft) — audit after every LMO/network change, not just at deployment.
  • Carrier quirks ledger: keep per-trunk notes of early-media/DTMF behaviours proven by traces — institutional memory that turns week-long carrier disputes into an email with a pcap attached.

The wire

  • Leg 1: client -> Teams service (signalling; instant failures live here)
  • Leg 2: Teams -> carrier fabric / operator interconnect / your SBC (DR: first SIP you can read)
  • Leg 3: media — relay path, hairpin, or bypass direct-to-SBC
  • DTMF: RTP named events; visible and diagnosable at the SBC

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.