skip to content

A WebRTC call fails for users on a corporate network that blocks outbound UDP and allows only TCP to port 443; how would you configure TURN, and what does that fallback cost?

level: seniorimportance: should knowfreq 12%

answer

  1. no UDP means no reflexive candidate
  2. the client leg can be TCP
  3. turns: on 443 resembles HTTPS
  4. relay to peer stays UDP
  5. head-of-line delay on media

basics

~20 s

Add a turns: TURN entry on TCP port 443 beside the UDP and TCP ones. The browser reaches the relay over TLS, which such firewalls usually pass, while the relay speaks UDP to the peer; the price is head-of-line delay, TLS overhead and relayed bandwidth.

solid answer

~50 s

With UDP blocked, the STUN Binding fails so there is no server-reflexive candidate, host candidates only work inside the LAN, and `turn:` over UDP fails too. RFC 8835 requires WebRTC endpoints to support TURN over TCP and TURN over TLS-over-TCP for exactly this firewall. So list `turn:...?transport=udp`, `turn:...?transport=tcp` and `turns:...:443?transport=tcp`; ICE tries them all and prefers what works best. Port 443 is a deployment choice, not an RFC default (that is 5349), made so that port-filtering firewalls treat the session like HTTPS. Whatever the client leg, RFC 8656 relays to the peer over UDP. The costs: a lost TCP segment stalls every later media packet, TLS adds a handshake and a second layer of encryption over DTLS-SRTP, and every such call consumes relay bandwidth. Confirm what won by reading `relayProtocol` on the selected pair's local candidate.

go deeper

for a junior

Remember that TURN can be reached over UDP, TCP or TLS, and that turns: is the TLS form.

for a middle

Explain why each candidate type fails behind a UDP-blocking firewall and why the relay-to-peer leg stays UDP.

for a senior

Justify the fallback ladder and its costs, and show how relayProtocol on the selected pair verifies which rung each call used.

for a principal

Decide when to run TURN on 443 yourselves and when to ask enterprise customers to provide their own relay, weighing support load against relay cost.

## Why the call fails A WebRTC endpoint behind a strict corporate firewall loses most of its options at once: - **Host candidates** (the machine's own addresses) only reach peers on the same network. - **Server-reflexive candidates** need a STUN Binding over UDP, which never leaves the building. - **Relay candidates over UDP** need an Allocate to the TURN server on UDP port 3478, also blocked. - **ICE-TCP candidates**, which RFC 8835 requires endpoints to support, can reach a peer with a public address over TCP, but rarely another user behind a NAT. Unless a relay is reachable over TCP, every candidate pair fails its checks and the connection ends in the `failed` state. The pattern is easy to recognise in client logs: gathering yields host candidates only, and `icecandidateerror` reports the STUN entry and the UDP TURN entry as unreachable. The same user connects fine from home, which is why such reports arrive as "works for some customers, never for others". ## The fallback ladder RFC 8835 says WebRTC endpoints **MUST** support TURN over TCP and TURN over TLS-over-TCP "to deal with firewalls that block all UDP traffic". RFC 8656 keeps the relay-to-peer leg on UDP whatever the client uses: | `iceServers` URI | Client to relay | Relay to peer | Gets through | Extra cost | |---|---|---|---|---| | `turn:turn.example.org?transport=udp` | UDP | UDP | networks that allow UDP | relay bandwidth only | | `turn:turn.example.org?transport=tcp` | TCP | UDP | firewalls allowing TCP to port 3478 | head-of-line delay | | `turns:turn.example.org:443?transport=tcp` | TLS over TCP | UDP | firewalls allowing only port 443 | delay, TLS handshake, double encryption | List all three in one `RTCIceServer` entry. ICE gathers a relay candidate from each one that answers and checks the pairs in priority order; which relay transport an implementation prefers is its own local preference, so verify rather than assume. ## Why TLS, and why port 443 The RFC default for TURN over TLS is **5349** (RFC 7065). Running it on **443** is a deployment convention: many firewalls allow outbound TCP only to the port HTTPS uses, and some reject traffic on 443 that does not begin with a TLS handshake. TLS also brings what RFC 8656 lists as its reasons for (D)TLS transport: the client can verify it reached the right server, and TURN control messages are confidential. Limits: - An HTTP proxy is a separate path. RFC 8835 says an endpoint **MAY** support reaching the Internet through one, and then must send the ALPN header of RFC 7639; whether a given endpoint does is the implementation's choice. - A middlebox that terminates and inspects TLS may still drop the session. Then only a relay the enterprise itself operates helps; RFC 8828 notes an organisation can force WebRTC through its own TURN server by firewall policy. ## What TCP does to real-time media - **Head-of-line blocking.** TCP delivers in order, so one lost segment holds back every later packet until it is retransmitted; audio and video arrive late instead of slightly incomplete. - **Reliability on one leg only.** The relay converts to UDP toward the peer, so losses beyond the relay are not retransmitted. - **Double encryption.** Media already protected by DTLS-SRTP is encrypted again by TLS, as RFC 8656 points out. - **Relay cost.** Every call on this network now crosses the relay, both directions. ## Verifying and operating it 1. From the connection's ICE transport, read the selected candidate pair with `getSelectedCandidatePair()`. 2. If the local candidate's `type` is `relay`, its `relayProtocol` says `udp`, `tcp` or `tls`, and its `url` names the entry used. 3. Log `icecandidateerror`: a 701 on the UDP entry, alongside a working TLS relay, typically identifies a UDP-blocked network. 4. Size the relay for long-lived TCP and TLS connections from those clients, not just for packet throughput.

  • If the relay talks UDP to the peer anyway, why offer TURN over TLS and not just TURN over plain TCP?
    Plain TCP to port 3478 passes firewalls that block UDP but allow arbitrary TCP. Networks that allow only port 443 often also expect a TLS handshake there, so a raw TURN stream is dropped. TLS also authenticates the relay and hides TURN control messages. Offer both: ICE uses whichever works, and the TLS entry is the last resort with the highest overhead.
  • Does running the client leg over TCP make the media reliable end to end?
    No. TCP retransmits only between the client and the relay; RFC 8656 relays to the peer over UDP, where loss is handled by the media stack as usual. The call gets TCP's delay on one leg without end-to-end reliability, which is why it is a fallback and not a default.
  • How do you confirm a call actually fell back to TLS on 443?
    Read the ICE transport's selected candidate pair. A local candidate of type `relay` with `relayProtocol` `tls`, and a `url` naming the `turns:` entry, proves the TLS relay carries the call. Aggregating those values per network shows how many users depend on the fallback.

saying these in an interview costs you the question

  • Port 443 is the standard RFC port for TURN over TLS.
  • With TURN over TCP the media becomes reliable all the way to the peer.
  • A stun: entry alone is enough, because STUN tunnels media through the firewall.
  • TURN over TLS is needed because WebRTC media otherwise travels unencrypted.
  • If outbound UDP is blocked, WebRTC cannot connect at all.