OBSERVERTC / Client Monitor

Application context

Application context tells the monitor what your application expects. A paused camera and a camera that unexpectedly stops sending may produce similar statistics, but they should lead to different conclusions.

Describe a track

monitor.setOutboundTrackContext(track.id, {
  contentType: 'screenshare',
  paused: false,
});

Use the actual media track identifier. Keep context up to date when your application changes its intent, such as pausing or resuming a track. Context can be supplied before the monitor discovers the track.

Available context

DirectionContext fieldsWhy you would supply them
InboundcontentType, paused, remoteOutboundTrackPausedTell the monitor what kind of media this is and whether either side intentionally paused it.
Inbound videomotionType, presentedResolution, videoTagDescribe the expected motion and displayed video so detectors can evaluate what the user sees.
Inbound audiolinkedVideoTrackIdIdentify the corresponding video track for audio/video synchronization checks.
OutboundcontentType, pausedDescribe what you are sending and whether sending is intentionally paused. Capture settings provide additional evidence.

Context updates merge with existing values. Pass undefined for a field to clear it. Supply the actual paired video track identifier rather than guessing from another participant. A videoTag is a local element reference, not something to serialize to your backend.

Source references

Local state and attachments

appData is local arbitrary working state. attachments is the explicit serializable envelope. Track createSample() sends id, kind, timestamp, attachments, score and reasons; it does not automatically send the context object, HTML element, flags or all derived metrics. Put required backend application context into an appropriate serializable contract explicitly.

Application measurements

Use addExtensionStats({ type, payload, id }) when you have application measurements beyond browser WebRTC stats. It updates an identified local ExtensionStatsMonitor; providers can also supply measurements during collection.

When automatic sampling or bufferingEventsForSamples is enabled, the measurement is buffered for a sample and extension-stats is emitted. The sample entry contains type and payload; the optional local monitor id is not included in that entry. Put any identifier your backend needs into your explicit payload contract.

These local monitors expire as measurements become stale. They do not provide historical storage. getExtensionStatsPayload<T> gives a TypeScript type assertion, so validate externally supplied data yourself. Observer receives these records through client-extension-stats events rather than reconstructing the browser’s local extension-monitor registry.

Source references
Version coverage varies by reference. Source revisions · Markdown source