w3c
remoteTimestamp does not specify how to derive the RTCP SR NTP timestamp
The spec for RTCRemoteOutboundRtpStreamStats.remoteTimestamp says:
remoteTimestamp of type DOMHighResTimeStamp remoteTimestamp, of type DOMHighResTimeStamp [HIGHRES-TIME], represents the remote timestamp at which these statistics were sent by the remote endpoint. This differs from timestamp, which represents the time at which the statistics were generated or received by the local endpoint. The remoteTimestamp, if present, is derived from the NTP timestamp in an RTCP Sender Report (SR) block, which reflects the remote endpoint's clock. That clock may not be synchronized with the local clock.
The text on the timestamp referred to in RFC3550 says:
NTP timestamp: 64 bits
Indicates the wallclock time (see Section 4) when this report was
sent so that it may be used in combination with timestamps
returned in reception reports from other receivers to measure
round-trip propagation to those receivers. Receivers should
expect that the measurement accuracy of the timestamp may be
limited to far less than the resolution of the NTP timestamp. The
measurement uncertainty of the timestamp is not indicated as it
may not be known. On a system that has no notion of wallclock
time but does have some system-specific clock such as "system
uptime", a sender MAY use that clock as a reference to calculate
relative NTP timestamps. It is important to choose a commonly
used clock so that if separate implementations are used to produce
the individual streams of a multimedia session, all
implementations will use the same clock. Until the year 2036,
relative and absolute timestamps will differ in the high bit so
(invalid) comparisons will show a large difference; by then one
hopes relative timestamps will no longer be needed. A sender that
has no notion of wallclock or elapsed time MAY set the NTP
timestamp to zero.
What could be useful here is specifying what an implementation should do when coming across a relative timestamp, or one that is zero.
This came up because a whereby.com SFU sent timestamps that when interpreted as absolute pointed to June 1900. These triggered a debug assert in Firefox.
Chromium assumes the timestamp is absolute when it does its conversion to DOMHighResTimeStamp. Firefox does the same (in non-debug builds).
