WebRTC ICE Candidate Failures on BYOC Trunks

Could someone explain why WebRTC sessions are dropping when using specific carriers? The ICE candidates fail to gather properly, causing immediate call failures on the softphone. This happens specifically with our APAC trunk configurations.

The logs show ice-gathering-failed errors around 14:00 SGT daily. We have 15 BYOC trunks active, and this affects only the Singapore region. Is there a known conflict with the default STUN server settings or carrier NAT traversal rules?

The documentation actually says to verify the iceServers configuration in the WebRTC settings. Ensure the STUN servers listed match the carrier’s public IP ranges to avoid NAT traversal issues.

Make sure you verify the STUN server list in your WebRTC config.

It’s like checking the outbound email relay in Zendesk settings.

Wrong IPs mean the NAT traversal fails immediately.

This is actually a known issue with APAC carriers and default STUN setups. The previous suggestions hit the mark, but double-check that your iceServers array explicitly includes the carrier’s recommended endpoints. Here is the payload structure that stabilizes our Singapore trunks:

{
 "iceServers": [
 {"urls": "stun:carrier-stun.apac.example.com:3478"},
 {"urls": "turn:carrier-turn.apac.example.com:3478", "credential": "secure_key"}
 ]
}

Adding the TURN server fallback usually resolves the ice-gathering-failed errors during peak hours.