How to Inspect WebRTC PeerConnections and Packet Loss in Google Chrome Using chrome://webrtc-internals

Web Real-Time Communication (WebRTC) powers modern browser-based video conferencing, cloud gaming, and audio collaboration tools like Google Meet, Discord, and Microsoft Teams. When calls suffer from choppy audio, frozen video feeds, or unexpected disconnects, standard Network DevTools panels provide limited visibility into UDP-based media pipelines. Google Chrome includes a specialised internal diagnostic console—chrome://webrtc-internals—that exposes real-time telemetry, ICE connection candidates, codec negotiations, and per-stream packet loss statistics.

Overview of WebRTC Architecture and Diagnostics

WebRTC creates encrypted, low-latency peer-to-peer data and media pipelines directly between browsers and media gateways. The chrome://webrtc-internals dashboard surfaces data across three distinct architectural layers:

• getUserMedia / getDisplayMedia Requests: Tracks local hardware capture devices (webcams, microphones, screen shares), audio constraints (echo cancellation, noise suppression), and active track statuses.
• RTCPeerConnection Lifecycle: Logs every JavaScript API call executed on the connection object (such as createOffer(), setLocalDescription(), and addIceCandidate()), tracking state transitions from initialization to connection termination.
• Interactive Connectivity Establishment (ICE): Inspects STUN/TURN binding transactions, local vs remote candidate pairs, nominal transport protocols (UDP vs TCP), and round-trip times (RTT).
• RTP Media Streams (Inbound & Outbound): Telemetry reporting live framerates, jitter, video dimensions, bitrate graphs, and cumulative packet loss counts.

Opening and Navigating chrome://webrtc-internals

To inspect active real-time communications in Google Chrome:

1. Open Google Chrome and initiate or join a WebRTC video or audio call (e.g., in Google Meet or an interactive browser app).
2. Open a new browser tab.
3. In the address bar, type chrome://webrtc-internals and press Enter.
4. The interface displays a series of expandable panels for each active media stream and RTCPeerConnection currently open across all browser tabs.

Analysing the PeerConnection API Trace

When you expand an active RTCPeerConnection block, the top section presents a chronological execution log of every WebRTC method and signalling event:

1. Look for red error highlights indicating failed SDP (Session Description Protocol) offer/answer negotiations or rejected codec profiles.
2. Verify the iceconnectionstatechange sequence: a healthy session moves rapidly from checking to connected or completed.
3. If the state transitions into disconnected or failed, the underlying network path has dropped or NAT traversal via STUN/TURN has been blocked by an enterprise firewall.

Inspecting Active ICE Candidate Pairs and Transport Protocols

Scroll down to the IceCandidatePair section to determine how your browser connects to the remote endpoint:

• state: A value of succeeded indicates the candidate pair currently carrying live traffic.
• localCandidateType & remoteCandidateType:
  • host: Direct local LAN connection between devices on the same subnet.
  • srflx (Server Reflexive): Public IP connection negotiated via STUN.
  • relay: Connection proxied through a TURN relay server (necessary when symmetric NATs block direct P2P routing).
• currentRoundTripTime: Displays latency in seconds between endpoints; sustained spikes above 0.15s (150 ms) typically result in audible conversational lag.

Tracking Packet Loss, Jitter, and Frame Drop Graphs

To diagnose degraded video quality or audio robotic distortion:

1. Scroll down to the inbound-rtp (received media) and outbound-rtp (sent media) statistics sections.
2. Click on individual metric checkboxes to plot live visual telemetry graphs directly on the screen:
   • packetsLost: The cumulative count of dropped UDP packets. A steadily rising curve indicates network congestion or Wi-Fi interference.
   • jitter: Statistical variance in packet arrival intervals. Severe jitter causes audio crackling.
   • framesDropped: The count of video frames discarded before rendering due to CPU decoding bottlenecks.
   • bytesReceived / bytesSent: Live bandwidth throughput for audio and video streams.

Exporting Diagnostic Dumps for Bug Reports

If you need to share telemetry with engineering teams or network administrators:

1. Scroll to the top of chrome://webrtc-internals.
2. Click Create Dump.
3. Check Download the PeerConnection updates and stats data.
4. Click Download Dump to save a comprehensive JSON log file capturing the entire call session, signalling traces, and bandwidth graphs.