Re: [webrtc-pc] Why is RTCIceCandidatePairStats.totalRoundTripTime mandatory to implement, but not responsesReceived? (#2819)

> Note that we don't ask for totalRoundTripTime on remote-inbound-rtp as MTI either.

Yes we seem to have discrepancies in both approach (preference/redundancy), naming, and MTI for RTT:

| stats type | naming | divisor naming | [MTI]( |
| "remote-inbound-rtp" | [roundTripTime]( | | Yes |
|  | [totalRoundTripTime]( | [roundTripTimeMeasurements]( | No |
| "remote-outbound-rtp" | [roundTripTime]( | | No |
|  | [totalRoundTripTime]( | [roundTripTimeMeasurements]( | No |
| "candidate-pair" | [currentRoundTripTime]( | | Yes |
| | [totalRoundTripTime]( | [responsesReceived]( | Yes / No |
| "sctp-transport" | [smoothedRoundTripTime]( | | No |

Is it too late to make naming consistent (x vs currentX vs smoothedX, and XMeasurements vs responsesReceived)?
Is it too late to make MTI consistent (x vs totalX/divisor vs both as MTI)?

That being said, [responsesReceived]( not being MTI seems like a bug, so a PR to match it to [totalRoundTripTime]( seems editorial, which would close out this issue. OTOH, looking at the table above, mandating totalX/divisor looks inconsistent.

@docfaraday correct me if I'm wrong, but no answer to this issue would help Firefox though, unless we also remove MTI from "candidate-pair"'s [currentRoundTripTime](, isn't that so?

> All that said - the users have already had to deal with the lack of these numbers because of Mozilla not implementing them, so I guess they can live without them.

Yes, I think Mozilla's preference would be to remove [currentRoundTripTime](, [totalRoundTripTime]( and [smoothedRoundTripTime]( from MTI for this reason. But I'm not sure we have consensus to do so.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 21 February 2023 22:05:02 UTC