SIP Call Flow in Microsoft Teams Direct Routing: Every Packet Explained

Understanding the SIP call flow in Microsoft Teams Direct Routing is essential for troubleshooting, capacity planning, and passing your Teams Voice certification. Most documentation gives you a high-level overview. This article gives you every SIP message, every handshake, and every decision point — the way you'd see it in a packet capture.

The Architecture: What's Talking to What

Before we trace a call, let's establish the components in the signaling path:

Teams Client — The user's desktop, mobile, or web Teams app. Initiates and receives calls via the Microsoft cloud.

Microsoft Transport Relay — Microsoft's globally distributed media relay infrastructure. Handles media (RTP/SRTP) routing when Media Bypass is not enabled.

Teams SIP Proxy — Microsoft's SIP proxy farm. Three FQDNs:

sip.pstnhub.microsoft.com (primary)

sip2.pstnhub.microsoft.com (secondary)

sip3.pstnhub.microsoft.com (tertiary)

Your SBC — The Session Border Controller you manage. Sits between Microsoft's SIP proxy and your PSTN carrier.

PSTN Carrier — Your SIP trunk provider's infrastructure. Connects to the public telephone network.

Phase 1: Initial Setup — The TLS Connection

Before any calls can flow, your SBC must establish and maintain a secure connection to Microsoft's SIP proxies.

TLS Handshake

Your SBC initiates a TLS 1.2 connection to sip.pstnhub.microsoft.com on port 5061. The handshake involves:

SBC → Microsoft: ClientHello (TLS 1.2, cipher suites offered)

Microsoft → SBC: ServerHello + Certificate (signed by Baltimore CyberTrust Root or DigiCert Global Root G2)

SBC → Microsoft: Client Certificate (your public CA certificate with SBC FQDN as SAN)

Mutual TLS established — both sides have authenticated

Critical detail: Microsoft validates your SBC's certificate against the FQDN registered in your Teams admin center. If the certificate SAN doesn't match the registered FQDN exactly, the TLS handshake fails silently. This is the #1 cause of "SBC not connecting" issues I see in the field.

DNS Resolution

Your SBC must resolve sip.pstnhub.microsoft.com dynamically. Microsoft uses geo-based DNS — the IP address returned depends on your SBC's geographic location. Never hardcode IP addresses.

Phase 2: OPTIONS Keepalives — The Heartbeat

Once TLS is established, the SBC and Microsoft's SIP proxy exchange OPTIONS messages to verify ongoing availability and capabilities.

The OPTIONS Exchange

Every 60 seconds (configurable on most SBCs), your SBC sends:

SBC → Microsoft SIP Proxy:

SIP OPTIONS sip:sip.pstnhub.microsoft.com

Contact:

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

Microsoft SIP Proxy → SBC:

SIP 200 OK

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, NOTIFY, REFER

Supported: timer, replaces, 100rel

Why OPTIONS Matter

If Microsoft doesn't receive an OPTIONS response from your SBC within the timeout period, it marks the SBC as unhealthy in the Teams admin center. You'll see the SBC status change from "Active" to "Inactive." No calls will be routed to an inactive SBC.

Troubleshooting tip: If your SBC shows as "Inactive" in Teams admin center, the first thing to check is whether OPTIONS messages are flowing. Capture packets on port 5061 and look for the OPTIONS/200 OK exchange. Common culprits: firewall blocking return traffic, certificate expiry, DNS resolution failure.

Phase 3: Inbound Call Flow (PSTN → Teams User)

When an external caller dials a Teams user's phone number, here's every step:

Step-by-Step Signaling

1. External caller dials the number

The call enters the PSTN network and is routed to your SIP trunk provider.

2. Carrier → SBC: SIP INVITE

Your carrier sends a SIP INVITE to your SBC with:

From: the caller's number (caller ID)

To: the called DID number

SDP: media capabilities (codecs, IP, ports)

Via: carrier's SIP proxy address

3. SBC processes the INVITE

The SBC performs several actions:

Validates the source (is this from a trusted carrier?)

Applies inbound manipulation rules (number normalization)

Translates the called number to E.164 format if needed

Selects the correct SIP Interface/Realm for the Teams-facing side

4. SBC → Microsoft SIP Proxy: SIP INVITE

The SBC forwards the INVITE to sip.pstnhub.microsoft.com:

From: caller's number (E.164)

To: called user's number (E.164)

Contact: SBC's FQDN

SDP: updated media offer

5. Microsoft SIP Proxy: Tenant Identification

The SIP proxy uses the To: number to identify:

Which tenant owns this number

Which user is assigned this number

Whether the user is enabled for Enterprise Voice

6. Microsoft SIP Proxy: SBC Authentication

The proxy verifies:

The SBC's TLS certificate matches a registered SBC in the tenant

The SBC is in "Active" status

The incoming number is assigned to a user in this tenant

7. Microsoft → SBC: 100 Trying

Acknowledges receipt of the INVITE.

8. Microsoft → SBC: 180 Ringing

The Teams user's device is ringing. The SBC forwards 180 to the carrier, and the external caller hears ringback tone.

9. Teams user answers → Microsoft → SBC: 200 OK

Contains the final SDP answer with media negotiation parameters.

10. SBC → Microsoft: ACK

Confirms the 200 OK. The call is now established.

11. Media flows

With Media Bypass: RTP flows directly between Teams client and SBC

Without Media Bypass: RTP flows through Microsoft Transport Relay

Inbound Call Flow Diagram

External Caller → PSTN → Carrier → SBC → Teams SIP Proxy → Teams User

Signaling: INVITE → 100 → 180 → 200 OK → ACK

Media: RTP/SRTP between Teams client and SBC (or via Transport Relay)

Phase 4: Outbound Call Flow (Teams User → PSTN)

When a Teams user dials an external phone number:

Step-by-Step Signaling

1. Teams user dials a number

The Teams client sends the dialed digits to the Microsoft Phone System.

2. Phone System: Number Analysis

The Phone System applies:

Tenant dial plan normalization rules (your regex patterns)

Voice routing policy lookup

PSTN usage matching

Voice route selection (which SBC to use)

Number translation (if configured)

3. Microsoft SIP Proxy → SBC: SIP INVITE

Microsoft sends the INVITE to your SBC:

From: Teams user's assigned phone number (E.164)

To: dialed number (E.164, after normalization)

Contact: Microsoft's SIP proxy

SDP: media offer

X-MS headers: Microsoft-specific routing information

4. SBC processes the outbound INVITE

The SBC:

Identifies the outbound route based on called number pattern

Applies outbound manipulation rules

Selects the correct SIP trunk to the carrier

Translates headers if needed (P-Asserted-Identity, Diversion, etc.)

5. SBC → Carrier: SIP INVITE

The SBC forwards to your PSTN carrier with carrier-appropriate formatting.

6. Carrier → SBC: 100 Trying → 180 Ringing

Standard SIP progression. The SBC forwards these to Microsoft.

7. Called party answers → Carrier → SBC: 200 OK

The SBC relays the 200 OK to Microsoft.

8. Microsoft → SBC: ACK

Call established.

Outbound Call Flow Diagram

Teams User → Teams SIP Proxy → SBC → Carrier → PSTN → External Caller

Signaling: INVITE → 100 → 180 → 200 OK → ACK

Media: RTP/SRTP between Teams client and SBC (or via Transport Relay)

Phase 5: Media Flow — Where the Voice Actually Goes

Without Media Bypass (Default)

The voice packets (RTP/SRTP) flow through Microsoft's Transport Relay:

Teams Client ←→ Transport Relay ←→ SBC ←→ Carrier

Client to Transport Relay: SRTP (encrypted)

Transport Relay to SBC: SRTP (encrypted)

SBC to Carrier: RTP or SRTP (depends on carrier)

With Media Bypass

Voice packets flow directly between the Teams client and your SBC:

Teams Client ←→ SBC ←→ Carrier

Client to SBC: SRTP (encrypted, direct path)

SBC to Carrier: RTP or SRTP

Latency benefit: Media Bypass can reduce voice latency by 30-80ms by eliminating the Transport Relay hop. This is significant for users on the same network as the SBC.

Requirement: For Media Bypass, the Teams client must have direct IP connectivity to the SBC's media interface. If the client is behind a restrictive NAT or on a network that can't reach the SBC, Media Bypass falls back to Transport Relay automatically.

Phase 6: Call Termination (BYE)

When either party hangs up:

Hanging-up party's side sends: SIP BYE

Other side responds: 200 OK

Media streams stop

CDR generated on the SBC with call duration, codec used, quality metrics

Common SIP Issues and What They Look Like

403 Forbidden

Meaning: Microsoft rejected the SBC's INVITE

Common causes: SBC FQDN not registered, certificate mismatch, number not assigned to a user

Where to look: Teams admin center → SBC status; SBC certificate configuration

404 Not Found

Meaning: The called number doesn't exist in the tenant

Common causes: Number not assigned, dial plan normalization failed, wrong number format

Where to look: Teams admin center → Phone numbers; Tenant dial plan rules

408 Request Timeout

Meaning: No response received within timeout

Common causes: Network connectivity issue, firewall blocking, SBC overloaded

Where to look: Network path between SBC and Microsoft SIP proxies

480 Temporarily Unavailable

Meaning: The Teams user is not reachable

Common causes: User not logged into Teams, all endpoints offline, DND enabled

Where to look: User's Teams client status, presence settings

488 Not Acceptable Here

Meaning: Media negotiation failed

Common causes: Codec mismatch, no common codec between SBC and Microsoft

Where to look: SBC codec configuration, ensure SILK/Opus is supported

503 Service Unavailable

Meaning: Microsoft's SIP proxy or your SBC cannot handle the request

Common causes: Capacity exceeded, service disruption, SBC maintenance mode

Where to look: SBC concurrent session count, Microsoft service health

Key Security Points

All SIP signaling is encrypted via TLS 1.2 — no plaintext SIP between your SBC and Microsoft

Media is encrypted via SRTP — both with and without Media Bypass

Mutual TLS authentication — both Microsoft and your SBC present certificates

SBC acts as a security boundary — it's your firewall for voice traffic

No direct internet exposure of Teams clients — all PSTN traffic goes through the SBC

Practical Troubleshooting Workflow

When a call fails, follow this sequence:

Check SBC status in Teams admin center — is it Active?

Check OPTIONS flow — are keepalives healthy?

Capture the SIP INVITE on the SBC — what response code came back?

Check the SBC's SIP ladder diagram — where in the flow did it fail?

Check Microsoft CQD — does it show the call attempt?

Check the carrier side — did the INVITE reach the carrier? What was their response?

Most call failures can be diagnosed within 5 minutes using this workflow. The SBC's SIP trace is your best friend.

Final Thoughts

Understanding SIP call flow is not academic — it's the difference between a 5-minute fix and a 5-hour escalation. When you know exactly which SIP message should come next and what each response code means, troubleshooting becomes systematic rather than guesswork.

If you're deploying Direct Routing and need help with the dial plan and voice routing configuration that feeds into this call flow, SwiftM365 generates production-ready configurations for 203 countries — normalization rules, voice routes, PSTN usages, and VRPs — all from a single web interface.

---

Have questions about SIP call flows or Direct Routing troubleshooting? Reach out via our feedback page or contact me directly at +91 9011070193.