[webrtc-stats] remoteTimestamp does not specify how to derive the RTCP SR NTP timestamp (#665)

Pehrsons has just created a new issue for https://github.com/w3c/webrtc-stats:

== remoteTimestamp does not specify how to derive the RTCP SR NTP timestamp ==
The spec for [RTCRemoteOutboundRtpStreamStats](https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats).remoteTimestamp says:
> _remoteTimestamp_ of type DOMHighResTimeStamp
> [remoteTimestamp](https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-remotetimestamp), of type [DOMHighResTimeStamp](https://www.w3.org/TR/hr-time-3/#dom-domhighrestimestamp) [[HIGHRES-TIME](https://www.w3.org/TR/webrtc-stats/#bib-highres-time)], represents the remote [timestamp](https://www.w3.org/TR/webrtc-stats/#dom-rtcstats-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](https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-remotetimestamp), if present, is derived from the NTP timestamp in an [RTCP Sender Report](https://www.w3.org/TR/webrtc-stats/#dfn-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](https://www.rfc-editor.org/rfc/rfc3550#section-6.4.1) 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).

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/665 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 September 2022 13:34:34 UTC