- From: Varun Singh via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Apr 2019 16:14:19 +0000
- To: public-webrtc-logs@w3.org
No issues with doing `totalRoundTripTime` And IIUC you are making a proposal for `reportsReceived` and `reportsSent`, which I thought we already had... if we dont have these, it makes sense to add them. > averageRtcpInterval of type double > >The average RTCP interval between two consecutive compound RTCP packets. This is calculated by the sending endpoint when sending compound RTCP reports. Compound packets must contain at least a RTCP RR or SR packet and an SDES packet with the CNAME item. if we go with reportSent/Received, I would ament the above . to do totalRtcpInterval and divide it with the report counters. --- Reasons we were fine with the most current value or latest RTT estimate: RTCP Reports are not sent very often, according to RFC3550 they are sent 5 +/- 2.5 seconds, i.e., as early as 2.5s or as late as 7.5s, and the RTCP interval value changes after each RTCP. And if we poll getStats API at say 1 or 2s intervals, we should be fine. However, if the RTCP interval were shorter than the polling interval for getStats (there are several cases, where people poll just at the end of the call)... the totalRoundTripTime would be useful. Also it should be noted that if we poll getStats more often than RTCP interval, we would get the same value and timestamp for these remote reports would be the same. -- GitHub Notification of comment by vr000m Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/426#issuecomment-481319449 using your GitHub account
Received on Tuesday, 9 April 2019 16:14:20 UTC