Two new data properties, captureTimestamp and senderCaptureTime, will be added to the RTCRtpContributingSource, returned by RTCRtpReceiver.getContributingSources(). (See These new properties are used to measure A/V sync and end-to-end delay in real-time communication (RTC) systems.


CaptureTimestamp and senderCaptureTime are introduced to overcome the difficulty of measuring A/V sync and end-to-end delay in an RTC system is that one or more RTCP-terminating sub-system are involved. In such a system, the round trip time measurement on RTCRemoteInboundRtpStreamStats only accounts for the "last hop": the connection between the receiver and the nearest RTCP-terminating sub-system that it receives RTCP packets from. This makes it hard to estimate the offset between the receiver's clock and the capturer's clock, and thus end-to-end delay. CaptureTimestamp and senderCaptureTime, as originated from RTP Header Extension for Absolute Capture Time, see can mitigate the problem.



Specification link

Unknown standards status - check spec link for status

Status in Chromium


Enabled by default (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • No signal
  • No signal
  • No signals


Search tags

WebRTC, Audio, Video, Synchronization, End-to-end delay, Blink, Javascript,

Last updated on 2022-01-04