Client Monitor attaches to your existing media objects. Start with a peer connection if your application uses the browser API directly, or attach a mediasoup device if mediasoup manages your transports.

RTCPeerConnection#

monitor.addSource(peerConnection);
// During application teardown:
monitor.removeSource(peerConnection);

Register the connection you already use for media. Removing a source stops monitoring it; your application still owns the connection.

mediasoup-client#

A mediasoup device creates the send and receive transports used by your application. Attaching the device early lets the monitor follow new transports. If a transport already exists, register that transport explicitly:

monitor.addSource(device, 'mediasoup-device');
// For a transport created before device instrumentation:
monitor.addSource(transport, 'mediasoup-transport');

Native WebRTC applications#

Using libwebrtc or libmediasoupclient outside the browser? See Native C++ integration for the C++ port, supported bindings, and current coverage. Its native listener API differs from the JavaScript examples on this page.

Application context#

The browser cannot tell whether a quiet stream is intentionally paused or unexpectedly broken. Tell the monitor about application intent through setInboundTrackContext and setOutboundTrackContext. Pausing, screen sharing and expected media flow can change the meaning of a silent interval. Context may be pending until the track appears.

Keep identifiers distinct: a browser stats ID, SSRC, MediaStreamTrack ID and SFU producer ID identify different things. Use track attachments and a server resolver for publisher/subscriber correlation.

Application context · Server SFU integration

Sources: ClientMonitor.addSource, Sources.