Illustration representing WebRTC calling on mobile data and troubleshooting with ICE, STUN and TURN.

Why WebRTC Calls Fail on Mobile Data—and Fix Them Fast

6 January 2026 Justin 0 Comments

A familiar pattern for PBX admins and VoIP engineers: the browser softphone works perfectly on office Wi-Fi, then fails the moment the same user switches to mobile data. Sometimes it connects but delivers one-way audio. Sometimes it rings and then drops. Sometimes it never progresses past “Connecting…”.

This is not “random WebRTC behaviour”. In most cases, it is a predictable result of how modern networks handle NAT, UDP, and firewall policy—especially on mobile and corporate connections. The good news is that you can usually fix it with a small set of disciplined changes.

This guide explains what is actually happening, why mobile networks are a special case in 2026, and a practical checklist to stabilise browser calling.

The real culprit: connectivity, not signalling

In a WebRTC call, the signalling channel (how two endpoints exchange session info) can be rock-solid while media (audio/video) still fails. Signalling typically rides over HTTPS/WebSockets and behaves well on restrictive networks. Media, however, must find a viable path between endpoints, and that’s where Wi-Fi vs mobile data diverges.

WebRTC solves this using ICE (Interactive Connectivity Establishment)—a method for discovering possible network paths and selecting the best one. ICE builds candidates using STUN (to discover public-facing addresses) and, when direct connectivity is not possible, TURN (to relay traffic). This is not an implementation quirk; it is the foundation of how WebRTC is designed to traverse NAT.

For the plain-English view, see WebRTC’s own overview of how peer connections need an ICE server configuration (STUN or TURN). WebRTC
For the standards-level definition, ICE is specified in RFC 8445 and explicitly relies on STUN/TURN. IETF Datatracker

Why mobile data breaks “works-on-Wi-Fi” assumptions

1) Carrier-grade NAT (CGNAT) is normal on mobile

On many cellular networks, your handset is not sitting behind just one NAT. Your traffic may pass through carrier-grade NAT infrastructure designed to conserve IPv4 addresses. The IETF even reserves a specific shared IPv4 range (100.64.0.0/10) to support CGN deployments. IETF Datatracker

In practice, CGNAT can make “direct” peer-to-peer connectivity unreliable or impossible in certain scenarios, particularly if both sides are behind restrictive NATs or policies. In those cases, STUN-derived candidates may be insufficient, and you need TURN relay capability as the dependable fallback.

2) UDP is often throttled, shaped, or blocked

Wi-Fi networks (especially at home or in-office) frequently allow UDP fairly freely. Mobile networks and corporate environments may not. Some networks prioritise TCP flows, aggressively time out UDP mappings, or block UDP outright for policy reasons. That makes “direct media over UDP” brittle.

3) Port and protocol policy differs by environment

Even if UDP isn’t blocked, the ports available may differ. A configuration that assumes “TURN on 3478/UDP only” might work on Wi-Fi and fail on mobile or corporate networks. The standard mitigation is to offer TURN on multiple transports, including TCP and TLS.

The fix: stop treating TURN as optional

A common misconception is: “We added a STUN server, so we have NAT traversal.” STUN helps, but it is not a relay.

If you want reliable connectivity across mobile, enterprise, and hostile networks, TURN is typically required. WebRTC.org’s guidance is blunt: for most WebRTC apps, a TURN server is the common way to relay traffic when a direct socket isn’t possible. WebRTC

If your product includes browser calling into SIP/PBX estates, this is the point where operations and customer experience meet. A WebRTC softphone that intermittently fails on mobile will be perceived as “unreliable calling”, even if your PBX and SIP trunking are flawless.

If you are bridging WebRTC users into SIP infrastructure, a platform such as Siperb’s WebRTC-to-SIP proxy can sit cleanly in the signalling/media chain—but you still need to engineer TURN and firewall policy correctly for users on difficult networks.

A practical 2026 checklist for stable mobile WebRTC

1) Offer TURN on UDP and TCP/TLS

Implement a proper ICE server list that includes:

TURN/UDP (best latency when it works)
TURN/TCP (better success rate on restrictive networks)
TURN/TLS on port 443 (best chance through locked-down environments)

Your goal is not to force TURN for everyone. Your goal is to guarantee a working fallback when “direct” fails.

2) Put TURN close to your users

TURN relays media. Distance matters. Place TURN nodes in regions where your users actually are, or use a provider with POP coverage that matches your traffic patterns. High RTT to TURN is a direct hit to perceived call quality.

3) Watch for “Wi-Fi success / mobile fail” as a diagnostic signature

Treat this symptom as a strong indicator of:

CGNAT involvement, restrictive NAT type, or short-lived UDP mappings
UDP blocking or heavy shaping
TURN not available on viable transports (especially TLS/443)

4) Log ICE outcomes, not just SIP events

If you only monitor SIP registration and call setup, you will miss the real failure mode. Log:

Selected candidate type (host / srflx / relay)
Whether a relay candidate was attempted and why it failed
Time to connect (ICE completion time)

If you run a WebRTC-to-SIP bridge (for example, a deployment path using Siperb to integrate browser clients with an existing PBX), pair your SIP logs with ICE diagnostics so you can distinguish “PBX issue” from “network path issue” quickly.

5) Validate firewall rules explicitly

At minimum, ensure your environment allows:

Outbound connectivity from clients to TURN endpoints on the transports you advertise
Media relay ports for TURN (often a defined UDP port range on the TURN server)
The option for TURN/TLS on 443 for restrictive networks

Do not assume “because HTTPS works, WebRTC will work”. Signalling is not media.

What “good” looks like operationally

When your WebRTC implementation is healthy, you should see a pattern like this:

On open networks (many Wi-Fi environments), calls typically connect via direct candidates.
On restrictive networks (some mobile/corporate), calls fall back to TURN—often TURN/TLS on 443—without user-visible failure.
ICE connection time remains consistent (not spiking unpredictably by network type).
One-way audio becomes rare, and when it occurs you can correlate it to a specific network path choice.

This is exactly why mature WebRTC deployments treat TURN as a core reliability component, not an “advanced feature”.

The strategic takeaway for PBX teams

In 2026, “browser calling” is not judged on the elegance of WebRTC APIs. It is judged on whether it works everywhere your users expect it to work—Wi-Fi, mobile data, hotels, airports, and corporate networks.

If you design for the hardest network first (CGNAT + restrictive policy), everything else becomes simpler. ICE gives you the framework, TURN gives you the reliability, and disciplined logging gives you the ability to prove where failures really occur.

For more articles like this, visit SoftpageCMS.