Closed Bug 978239 Opened 6 years ago Closed 6 years ago

RTCP packets from Windows machines are 62 years 9 months in the future (bug in WebRTC RtpRtcpClock)


(Core :: WebRTC, defect)

Windows 7
Not set





(Reporter: jib, Assigned: jib)





(1 file)

62 years 9 months and change. Found in Bug 970686 comment 11 from try of a new test:

STR local Windows:

1. Go to URL, hit "Capture!" + OK followed by "Connect!"
2. Wait 5 seconds and observe that Remote timestamps are wrong time of day
   (you have to peek at the js to see the date and year).

STR Windows to Mac call:

1. Set up a call between Windows and a Mac in Nightlies.
2. Hit refresh in about:webrtc (open in separate tab) on both sides during call.
3. Observe that only RTCP packets originating from the Windows machine are whack.

Basically, we never synchronize WindowsRealTimeClock, which means get_time() returns time elapsed since Windows started instead of since January 1, 1601 UTC, which majorly underflows when we subtract the Unix Epoch.

The reason things work is that myopically everything is fine since time is steady, but in absolute time things are yaers off which looks bad now that we have stats.

I don't know if there are other effects of fixing this or other uses affected.
Comment on attachment 8383895 [details] [diff] [review]
Synchronize WindowsRealTimeClock to unmess RTCP timestamps

Review of attachment 8383895 [details] [diff] [review]:

Also check upstream to see if they've fixed this; if so take their patch, else open an issue and put our patch up for codereview.
Attachment #8383895 - Flags: review?(rjesup) → review+
I checked ahead of time this time. They have not.
Keywords: checkin-needed
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
No longer blocks: webrtc_upstream_bugs
You need to log in before you can comment on or make changes to this bug.