WebRTC NTP Server

[Corey Cole]

WebRTC has an experimental statistic googCaptureStartNtpTimeMs in the ssrc recv report of WebRTC stats. I believe it is defined as the NTP time when the stream started on the sender's side in milliseconds.

I'm want to sync my clients with the same NTP clock WebRTC uses to generate that googCaptureStartNtpTimeMs.

I've been googling around and searching/reading WebRTC source and I cannot find which NTP server(s) are used to generate this stat. I'm assuming all NTP servers cannot possibly be in sync, so I need to figure out exactly which NTP server(s) WebRTC is using so I can sync my clients with their googCaptureStartNtpTimeMs timestamp.

I see a few options:

• pool.ntp.org
• time.google.com
• time1.google.com
• ntp.google.com

Searching for these in the WebRTC source yields no results. pool.ntp.org seems promising because it will help find an NTP server close (low latency) to where the request was made from. But, if the NTP pool is not in sync with NTP WebRTC, it will be useless to me unless I can get the offset between NTP pool and NTP WebRTC.

My question boils down to:

• Are all NTP servers standardized and in sync with each other?
• If not, which NTP server(s) does WebRTC use to generate googCaptureStartNtpTimeMs?

I've asked on Stack Overflow if anyone would like to answer there :)

Thank you,

Corey

[Chen Xing]

Hi Corey,

When WebRTC refers to NTP timestamps, it means timestamps with an epoch of January 1st 1900, rather than actually syncing of clocks through NTP servers.

See RFC 3550:

   Wallclock time (absolute date and time) is represented using the
   timestamp format of the Network Time Protocol (NTP), which is in
   seconds relative to 0h UTC on 1 January 1900 [4].  The full
   resolution NTP timestamp is a 64-bit unsigned fixed-point number with
   the integer part in the first 32 bits and the fractional part in the
   last 32 bits.  In some fields where a more compact representation is
   appropriate, only the middle 32 bits are used; that is, the low 16
   bits of the integer part and the high 16 bits of the fractional part.
   The high 16 bits of the integer part must be determined
   independently.

   An implementation is not required to run the Network Time Protocol in
   order to use RTP.  Other time sources, or none at all, may be used
   (see the description of the NTP timestamp field in Section 6.4.1).
   However, running NTP may be useful for synchronizing streams
   transmitted from separate hosts.

   The NTP timestamp will wrap around to zero some time in the year
   2036, but for RTP purposes, only differences between pairs of NTP
   timestamps are used.  So long as the pairs of timestamps can be
   assumed to be within 68 years of each other, using modular arithmetic
   for subtractions and comparisons makes the wraparound irrelevant.

More specifically, usually the timestamps from the clock used to generate the NTP timestamp field in RTCP sender reports:

   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.

Cheers,

Chen

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/f2d621f6-8a3c-4fdc-a88a-2ec4f052309a%40googlegroups.com.

[Corey Cole]

When WebRTC refers to NTP timestamps, it means timestamps with an epoch of January 1st 1900, rather than actually syncing of clocks through NTP servers.

Are you sure about this? I see a comment here about how the epoch value might be synchronized against an NTP time server.

I'm interested in synchronizing audio playback on multiple devices on a local network. I think RFC 7273 is what I need for this, but I'm not sure how I can do this with WebRTC or how to synchronize clocks across the devices. 

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[Andreas Smas]

On Mon, Feb 10, 2020 at 11:38 AM Corey Cole <corey...@gmail.com> wrote:
>>
>> When WebRTC refers to NTP timestamps, it means timestamps with an epoch of January 1st 1900, rather than actually syncing of clocks through NTP servers.
>
> Are you sure about this? I see a comment here about how the epoch value might be synchronized against an NTP time server.
>
> I'm interested in synchronizing audio playback on multiple devices on a local network. I think RFC 7273 is what I need for this, but I'm not sure how I can do this with WebRTC or how to synchronize clocks across the devices.

In my experience the NTP clock you receive in the sender-report RTCP
frames can't really be used for
global synchronization as they're just the computers local clock (at
least with Chrome), so they can
just be anything really.

To make things worse, I've also seen cases where it jumps back and
forth every now and then.
I could verify this by looking at the actual screen capture which
included the current time that
also jumped in tandem with the NTP value in the sender-report message.

IMO the only thing it can reliably be used for in the real world is to
synchronize streams from the same sender.

[Corey Cole]

To make things worse, I've also seen cases where it jumps back and forth every now and then.

Yeah I've seen the googCaptureStartNtpTimeMs stat switch between two values between polling stat reports from the same peer connection.

IMO the only thing it can reliably be used for in the real world is to synchronize streams from the same sender.

That is my use case. I am trying to use this formula to adjust the streams:

e2e_delay = (time_now) - (googCaptureStartNtpTimeMs + track_playout_duration + NTP_EPOCH_OFFSET)

This is where I adjust time_now to be in sync with googCaptureStartNtpTimeMs using the offset between the two measurements. Then I can compare the track_playout_duration across all my receiving devices to sync them.

I am using the native iOS and Android binaries built from m79 source (not chrome). I'm not sure how to get the NTP_EPOCH_OFFSET. I thought I would use an NTP server, but apparently there isn't one. Anyone have guidance on how to get this offset?

I found this NtpOffsetMs() function in the rtp_rtcp module, but I'm not sure how to access that from my application through the API. I'm also not sure how I can get the same time_now that will be useful given that offset.