Re: [webrtc-stats] End-to-end delay metrics (#537)

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  - 

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 using your GitHub account

Received on Monday, 10 February 2020 09:31:07 UTC