Debugging
WebRTC connections fail in ways a normal web request does not. The handshake can stall, ICE can find no path, media can arrive late or not at all. Debugging is the work of seeing inside a connection that runs mostly out of view.
What it enables
A clear picture of why a connection behaves the way it does. With the right signals, a developer can tell a signaling failure from an ICE failure, spot packet loss eating into call quality, and watch a connection recover or degrade in real time. This turns "it does not work" into a specific, fixable cause.
How it works (high level)
The connection exposes its progress through state. ICE moves through gathering, checking, connected, and failed. The overall connection state reports when the link is established, disconnected, or lost. Watching these transitions shows where a handshake stops: a connection stuck in checking points at NAT or candidate problems, not at signaling.
For numbers, getStats returns an RTCStatsReport: a collection of timestamped records covering the connection. It reports the candidate pair in use, round-trip time, bytes and packets sent and received, packet loss, jitter, and per-codec media stats. Sampling the report over time turns a frozen call or a slow transfer into a measurable trend, such as loss climbing or bitrate falling.
The browser also ships an internals page, chrome://webrtc-internals in Chromium, that graphs these same stats live for every active connection without any application code. It is the fastest way to inspect a connection during development.
A common workflow: confirm signaling delivered the offer and answer, watch ICE reach connected, then read getStats to check the media is flowing and the chosen path is healthy. Each step rules out a layer.
Where it's used
Connection failures behind strict NAT, call quality complaints, slow or stalled file transfers, and monitoring dashboards that surface live connection health to operators.