Why WebRTC Falls Back to TCP Over UDP

While WebRTC is designed to prioritize UDP for real-time, low-latency media streaming, certain network restrictions prevent UDP packets from reaching their destination. In these restrictive environments, WebRTC’s Interactive Connectivity Establishment (ICE) framework must fall back to TCP to establish and maintain a connection. This article explores the specific network scenarios, firewall configurations, and proxy setups that force WebRTC to encapsulate media over TCP instead of UDP.

Strict Corporate Firewalls Blocking UDP Traffic

The most common scenario where WebRTC is forced to use TCP is within enterprise or corporate networks. Network administrators frequently implement strict security policies that block all outgoing UDP traffic, with the exception of essential services like DNS (Port 53).

Because UDP is connectionless and does not verify the recipient’s identity, administrators block it to prevent data exfiltration, malware communication, and unmonitored protocol usage. In this scenario, WebRTC cannot establish a direct Peer-to-Peer (P2P) UDP connection or connect to a UDP-based TURN (Traversal Using Relays around NAT) server. It must fall back to TCP, typically leveraging Port 443 (standard HTTPS traffic) to bypass the firewall.

Deep Packet Inspection (DPI) and Secure Web Gateways

In highly secure environments, firewalls do not just block ports; they also use Deep Packet Inspection (DPI) to analyze the actual payloads of passing network packets.

If a firewall detects UDP-based media protocols (like SRTP) disguised on allowed UDP ports, it will drop those packets. To bypass this, WebRTC is forced to establish a connection using TURN-over-TLS (TURNS) over TCP port 443. By wrapping the media in a standard TLS/TCP envelope, the traffic looks identical to secure web browsing (HTTPS) to the DPI engine, allowing the connection to succeed.

Enterprise Proxy Server Requirements

Many corporate networks route all outbound web traffic through an explicit forward proxy server (such as an HTTP or SOCKS5 proxy) for logging, caching, and security scanning.

Standard proxy servers are fundamentally designed to handle TCP connections and do not support UDP relaying. If a client device is behind an explicit proxy that mandates all external connections go through it, WebRTC cannot send UDP packets to the outside internet. It must establish a TCP connection to the proxy server, which then forwards the encapsulated media to a TURN server or the remote peer.

Symmetric NAT to Symmetric NAT Traversal Failures

WebRTC uses STUN (Session Traversal Utilities for NAT) to discover public IP addresses and establish direct UDP paths between peers. However, when both peers are behind Symmetric NATs (common in corporate networks and some mobile carriers), direct UDP hole punching fails.

When direct P2P connection via STUN fails, WebRTC must route traffic through a TURN relay server. If the network hosting either peer blocks outbound UDP to the TURN server, WebRTC is forced to fall back to a TCP connection to the TURN server (using either TURN-over-TCP or TURN-over-TLS) to bridge the media path between the two symmetric NATs.

Mobile Carrier CGNAT and UDP Throttling

Some mobile network operators utilize Carrier-Grade NAT (CGNAT) to conserve IPv4 addresses. In some instances, carriers aggressively throttle or completely drop UDP traffic that is not recognized as standard DNS or carrier-approved VoIP services (like VoLTE) to prevent network congestion. Under these network-constrained cellular conditions, WebRTC clients will experience high UDP packet loss, triggering the ICE agent to switch to a more stable TCP connection to maintain call viability, albeit at the cost of higher latency.