v150 · WebRTC

Logging lifecycle

A diagnostic-logging session is a tiny state machine built from three synchronous static methods on RTCPeerConnection. startDiagnosticLogging() begins recording and returns a session ID; stopDiagnosticLogging() finalises the local log; cancelDiagnosticLogging() discards it. Call any of them out of order and the spec requires an InvalidStateError. The buttons below make the real calls and report exactly what they return.

RTCPeerConnection.startDiagnosticLogging() is not available in this browser.
The current API is a static method on RTCPeerConnection (there is no navigator.rtc). Launch Chrome 150+ with --enable-blink-features=RTCDiagnosticLogging, or enable chrome://flags/#enable-experimental-web-platform-features and reload over HTTPS/localhost. The buttons call the real API and report exactly what it returns.

Idle. Start a logging session.

Current session ID (all the page ever receives — the logs stay in the browser)

—

Call log

(no calls yet)

// Before a call, start capturing WebRTC diagnostics
const sessionId = RTCPeerConnection.startDiagnosticLogging();
// returns "530b630f-8b8b-41ae-b239-a3692fbb4970" synchronously (a DOMString, not a Promise)

// When the call ends normally, finalise the local log
RTCPeerConnection.stopDiagnosticLogging();

// …or, if nothing useful happened, discard it
RTCPeerConnection.cancelDiagnosticLogging();

// All three throw InvalidStateError when called out of order:
// start while a session is active, or stop/cancel with no active session.

implementation reference

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

see also

implementation reference