webrtc

by

Understanding WebRTC Internals

The chrome://webrtc-internals/ page is Chrome’s built-in tool for debugging WebRTC applications. When you save a dump from this page, it generates an HTML file containing the complete lifecycle and telemetry of all active RTCPeerConnections.

Key Components of a WebRTC Dump

1. Peer Connection Tabs

At the top of the document, each tab represents an individual RTCPeerConnection. A single web page can have multiple connections (e.g., one for receiving media, one for sending, or multiple participants).

2. ICE Candidate Grid

This table shows the network routing used for the media.
– Local Candidate: The IP and port of your local machine.
– Remote Candidate: The IP and port of the remote server or peer.
– Active Pair: The row marked with succeeded reveals the exact path the media is taking (e.g., UDP routing over a specific port).

3. Update Log (Signaling & SDP)

The update log records every WebRTC API event chronologically.
The most valuable information is found inside setLocalDescription and setRemoteDescription, which contain the SDP (Session Description Protocol).

What to look for in the SDP:
– Direction: Is it sendrecv, sendonly, or recvonly?
– Codecs: Check the a=rtpmap lines to see which codecs were negotiated (e.g., H264, VP8, Opus).
– Server Identity: Sometimes the SDP reveals the backend (e.g., a=msid-semantic: WMS janus indicates a Janus media server).

4. Stats Tables (getStats API)

These tables provide real-time metrics about the connection’s health.

inbound-rtp / outbound-rtp

These tables show metrics for incoming and outgoing media streams.
– inbound-rtp: Stats for media your browser is receiving (e.g., the video you are watching).
– outbound-rtp: Stats for media your browser is sending (e.g., the video from your camera).

  • packetsLost & jitter: High numbers here indicate poor network quality.
  • framesDecoded & framesReceived/s: Shows the actual framerate the browser is successfully processing.
  • nackCount / pliCount: Shows how many times the browser had to request dropped packets or full keyframes due to corruption.

candidate-pair

  • currentRoundTripTime (RTT): The latency of the connection.
  • availableIncomingBitrate: The estimated bandwidth available for the stream.

data-channel

If the application uses WebRTC DataChannels (for text/binary data instead of A/V), this section shows the label of the channel, its state (open), and the number of messages sent and received.

transport

Shows the cryptographic protocols securing the connection:
– dtlsCipher: e.g., TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
– srtpCipher: e.g., AEAD_AES_256_GCM

Common Troubleshooting Workflows

  1. Video is stuttering/freezing: Check inbound-rtp for high packetsLost, high jitter, or a rising jitterBufferDelay.
  2. No Video/Black Screen: Check the Update Log to ensure SDP negotiation completed successfully and that bytesReceived in inbound-rtp is incrementing.
  3. High Latency: Check candidate-pair for high currentRoundTripTime or look for relay (TURN) candidates being used instead of direct host/srflx candidates in the ICE grid.