v150 · WebRTC

WebRTC Diagnostic Logging API

Three static methods on RTCPeerConnection — startDiagnosticLogging(), stopDiagnosticLogging(), cancelDiagnosticLogging() — let an authorized app ask the browser to record internal WebRTC diagnostics to a local log file. The calls are synchronous: start returns a session-ID string immediately. Logs are never exposed to the page; the app only receives an ID it can attach to a bug report.

concepts

  1. Logging lifecycle

    Drive the state machine with real synchronous calls: start returns a session-ID string, stop finalises the local log, cancel discards it. Each button is enabled only when it is valid to call, and calling out of order throws InvalidStateError as the spec requires.

  2. Bug-report companion

    The real-world use case: start a session with structured metadata, then stamp the returned ID onto a bug report. Includes the spec's metadata limits — at most 5 entries, each key/value ≤ 100 chars — which now throw a TypeError synchronously.

  3. Capability & policy probe

    Feature-detect the three RTCPeerConnection statics in your browser, and understand the full gate: the RTCDiagnosticLogging runtime feature exposes the API, while production deployment additionally needs the enterprise policy WebRtcDiagnosticLogCollectionAllowedForOrigins. Honest reporting — including browsers that still ship the pre-rewrite navigator.rtc surface.

why it shipped

WebRTC calls fail in ways that are painful to reproduce: NAT traversal quirks, codec negotiation, packet loss, jitter — all buried in the browser's internal state. Chrome has long had chrome://webrtc-internals and an internal event-logging pipeline, but a web app couldn't trigger a capture around a user-reported problem or correlate it with its own bug report. This API gives authorized apps a programmatic hook to start a capture, tag it with app metadata, and get back an ID — the same pattern as crash IDs — so a support engineer can line the browser's diagnostics up with the app's own logs. Critically, the diagnostics never flow back into the page, preserving user privacy.

enabling it

The API is exposed as static methods on RTCPeerConnection; there is no navigator.rtc. ChromeStatus (feature detail, updated 2026-09-30) records status “Proposed” with a desktop shipping estimate of 156, is_released: false, and no origin trial listed (origintrial: false). As verified in Chrome 154.0.8037.97, the current stable browser does not implement the static surface — with or without the runtime feature. To experiment locally, launch Chrome with --enable-blink-features=RTCDiagnosticLogging or turn on chrome://flags/#enable-experimental-web-platform-features. Be aware: on Chrome 154 that flag exposes the pre-rewrite navigator.rtc surface (start/finish/cancel), not the current RTCPeerConnection statics. For a real deployment the enterprise policy WebRtcDiagnosticLogCollectionAllowedForOrigins must also list the origin. Every demo here feature-detects both surfaces and shows these exact steps.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗