- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Feb 2020 09:31:04 +0000
- To: public-webrtc-logs@w3.org
I see several issues with this stat (although as I said before, the more stats the better).
On congestion paths, rtt/2 is not a good proxy for one way delay, as you can have very asymmetric scenarios specially when competing against tcp based flows.
For the server case, I could implement the mapping of the RTP timestamp to the original sender NTP timestamp on my server, but I don't feel anyone will compensate the timestamps to account for the sender `rtt/2`, which will render this stat un-usable for relay server case.
How about removing the rtt of the stat and exposing the `playoutTimeInReceiverNtp` and `estimatedNtpDelta` ?
```
playoutTimeInReceiverNtp = current time according to local NTP clock
estimatedNtpDelta = reportReceivedInReceiverNtp - reportSentInSenderNtp;
estimatedPlayoutDelta = playoutTimeInReceiverNtp - estimatedPlayoutTimestamp -
estimatedNtpDelta
```
If anyone wants to calculate the e2edelay by adding the `smoothedRtt/2`, it can be done in js with the already known values.
--
GitHub Notification of comment by murillo128
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/537#issuecomment-584032187 using your GitHub account
Received on Monday, 10 February 2020 09:31:07 UTC