Diagnosing Network Issues with Firefox about:webrtc

Firefox’s built-in about:webrtc page is an essential diagnostic utility that provides network engineers with deep, real-time visibility into active and historical WebRTC sessions. This article explains how engineers can leverage this internal interface to rapidly troubleshoot real-time communication bottlenecks, focusing specifically on diagnosing Interactive Connectivity Establishment (ICE) candidate failures, verifying STUN and TURN server connectivity, and pinpointing Real-time Transport Protocol (RTP) packet loss.

Diagnosing ICE Candidate Failures

The ICE framework is responsible for finding the best path to connect peers through NATs and firewalls. When a WebRTC call fails to connect, the "ICE Stats" section within a session's log on the about:webrtc page is the primary troubleshooting tool.

Network engineers can use the ICE table to view every candidate pair generated during the session. The table breaks down the connection attempts into specific columns:

  • Local and Remote Candidates: Displays the IP addresses, ports, and transport protocols (UDP/TCP) being tested by both peers.
  • ICE State: Indicates the exact status of each candidate pair, such as Succeeded, In-Progress, Frozen, or Failed.
  • Priority and Nominated: Shows which path the browser prefers and which pair was ultimately selected for media transmission.

If all candidate pairs show a Failed state, engineers can immediately deduce that bidirectional communication is blocked. By inspecting the IP addresses and ports of the failed pairs, an engineer can identify if a specific subnet, port range, or protocol is being dropped by a corporate firewall or an improperly configured Access Control List (ACL).

Verifying STUN and TURN Server Connectivity

STUN and TURN servers are critical for traversing strict NAT architectures. The about:webrtc page allows engineers to verify if the browser can successfully reach and authenticate with these servers by analyzing the candidate types generated in the ICE table.

  • Host Candidates (host): Represent the local network interface. If only host candidates are present, the browser cannot reach outside its local network to query STUN or TURN servers.
  • Server Reflexive Candidates (srflx): Generated via STUN. If srflx candidates are missing from the Local Candidate column, the STUN server is unreachable. This typically points to outbound UDP traffic being blocked on port 3478 (or the configured STUN port) or a DNS resolution failure for the STUN server hostname.
  • Relayed Candidates (relay): Generated via TURN. If a peer-to-peer connection fails and no relay candidates are gathered, the TURN server is failing. Engineers can look at the trickle status and the "Connection Log" at the bottom of the about:webrtc page to see if the TURN failure is due to a network timeout (firewall block on UDP/TCP/TLS) or an authentication error (401 Unauthorized) caused by expired credentials.

Analyzing RTP Packet Loss

Once a connection is established, media quality issues such as robotic audio or frozen video are typically caused by network congestion. The "RTP Stats" section of the about:webrtc page monitors the health of the media streams in real time, separating data into Inbound RTP and Outbound RTP for both audio and video tracks.

Engineers use this section to track the following metrics:

  • Packets Lost: The Inbound RTP log shows the exact number of packets dropped on the way to the user. A rapidly increasing number indicates downstream bandwidth saturation or a faulty local wireless connection.
  • RTCP Receiver Reports: Within the Outbound RTP section, Firefox displays data sent back from the remote peer via RTCP. This allows the engineer to see if the packets leaving the local browser are being lost before they reach the destination, indicating upstream congestion or ISP routing issues.
  • Jitter: Measured in milliseconds, this metric shows the variation in packet arrival times. High jitter alongside packet loss confirms that network queues are filling up and dropping packets, signaling the need for Quality of Service (QoS) adjustments on the local network routers.
  • Bitrate and Framerate: By clicking "Show Details" under RTP stats, engineers can view historical graphs of bitrate and framerate drops, correlating media degradation directly with spikes in packet loss.

Utilizing the Connection Log for Deep Inspection

For issues that cannot be resolved through the GUI tables alone, the about:webrtc page includes a "Connection Log" and a "Debug Mode" toggle. Enabling Debug Mode generates low-level C++ trace logs of the entire WebRTC stack. Network engineers can use the Connection Log to view the exact timestamps of ICE binding requests, DTLS handshake failures, and socket errors, providing the granular packet-level detail required to resolve complex enterprise network incompatibilities.