NAT & Firewall TraversalCommunity-Reported-UnverifiedMicrosoft Teams · Direct Routing

Troubleshooting ICE Candidate Negotiation Failures in Teams Direct Routing Media Bypass

by Provider Adminlast verified 2026-08-19

Problem

Architecture Overview

In Microsoft Teams Direct Routing with Media Bypass enabled, Teams clients attempt to establish media paths directly with the Session Border Controller (SBC) using Interactive Connectivity Establishment (ICE). This bypasses the Microsoft Cloud Media Proxies to minimize latency and optimize audio quality.

ICE Negotiation Failure

When the ICE candidate exchange fails during SIP signaling, the Teams client and the SBC cannot agree on a mutually reachable UDP transport path. Consequently, the call connects signaling-wise, but media setup times out, resulting in immediate one-way/no-way audio followed by an automatic call termination after 10 seconds.

Illustration for Troubleshooting ICE Candidate Negotiation Failures in Teams Direct Routing Media Bypass

Symptoms

Calls connect successfully via SIP (200 OK), but silently drop after exactly 10 seconds.
One-way audio or total silence occurs immediately upon answering a Media Bypass call.
Microsoft Teams desktop client displays the message 'Call ended due to network policies or connectivity issues'.
Network packet traces show STUN Binding Requests sent by the client receiving no responses from the SBC.
Disabling Media Bypass in Teams PowerShell resolves call drop issues and restores bi-directional audio.

Root cause

Invalid or Missing Candidate Attributes

The SBC fails to include valid a=candidate SDP attributes in its 200 OK or INVITE SDP body. In many deployments, the SBC incorrectly advertises internal private RFC 1918 IP addresses rather than its publicly routable reflexive IP.

Firewall Filtering of STUN/RTP Traffic

Perimeter firewalls situated between the Teams client subnets and the SBC WAN interface actively block STUN Binding Requests or media ports.

Blocked UDP Port Ranges: Strict policies drop traffic within the 50000-59999 media range.
SIP ALG Interference: Stateful inspection devices modify or strip SDP candidate parameters, rendering ICE negotiations invalid.

Resolution steps

step #1
Verify SBC Media Bypass Configuration

Ensure the SBC signaling interface and IP group associated with Microsoft Teams are explicitly configured to support ICE and Media Bypass.
text
```
AudioCodes CLI Example:
(config-voip)# ip-group 1
(ip-group-1)# media-bypass-mode enable
(ip-group-1)# ice-mode lite-or-full
```
step #2
Validate Public IP NAT Candidate Mapping

Configure the SBC network settings to ensure it includes its external, publicly routed IP address as a candidate in all outbound SDP offers and answers.
bash
```
# Run tshark on the SBC external interface to verify public candidate generation
tshark -i eth0 -Y "sip.CSeq.method == INVITE || sip.Status-Code == 200" -V | grep "a=candidate"
```
step #3
Adjust Perimeter Firewall Policies

Update perimeter firewall rules to permit bidirectional UDP traffic between internal Teams client endpoints and the public interface of the SBC across the required media ports.
text
```
Rule Definition:
Source: Internal Client Networks / Any
Destination: SBC Public IP
Protocols: UDP / Ports 50000-59999
Options: Disable SIP ALG / Disable UDP Timeout Truncation
```
step #4
Confirm Teams Online PSTN Gateway Settings

Verify via Teams PowerShell that the target PSTN Gateway object has media bypass correctly enabled and configured for direct routing.
powershell
```
Get-CsOnlinePSTNGateway -Identity "sbc.example.com" | Select-Object Identity, MediaBypass, EnableMediaBypass, BypassMode
```
step #5
Capture and Validate STUN Traffic Flow

Perform a packet capture on the SBC WAN interface during call setup to confirm that STUN Binding Requests are arriving from the client and receiving prompt Binding Success Responses.
bash
```
tcpdump -nn -i any udp portrange 50000-59999 and host <SBC_PUBLIC_IP> -w /tmp/ice_stun_debug.pcap
```

Verification evidence

Wireshark STUN Trace Analysis

Filtering packet captures on stun during call setup reveals STUN Binding Requests originating from the client's IP to the SBC public IP, but zero corresponding STUN Binding Responses are returned.

SIP SDP Candidate Inspection

Inspection of the SDP payload inside the SIP 200 OK returned by the SBC reveals missing or incorrect candidate formatting:

Expected: a=candidate:1 1 UDP 2130706431 <SBC_PUBLIC_IP> 50004 typ host
Observed Defect: Missing a=candidate attributes entirely or candidate lines specifying private addresses like 192.168.1.50.

Report an issue with this article