RoundTripTime not defined when the underlying stream can't calculate it

[jesup]

RoundTripTime can only be calculated after an exchange of RTCP packets with the relevant information. Until then, it's not possible to calculate. What should be RoundTripTime have before we know the time? 0? undefined? null? And what will be the impact on existing applications if we choose something like undefined or null?

[vr000m]

@jesup: I think at the TPAC the decision was to use undefined if it is not measured. and 0 or any good starting value, if it is measuring but doe not have a measurement.

I think -1 would make sense in this case.

[vr000m]

for deployments when no RTCP RR is sent/received (some legacy middleboxes do not send RTCP RRs, although send RTCP SRs), I think it will remain -1.

[jan-ivar]

We just moved roundTripTime to the isRemote == true dictionary which doesn't exist until RTCP packlets come in.

[henbos]

If we don't have a value for it (because we haven't exchanged packets) then it should be undefined, not -1.

[jan-ivar]

Again, there should never be a need for either, since the whole dictionary will be absent in that case, and the associate stats dictionary's associateStatsId (remoteId in Firefox atm) will be undefined.

That's my best reading of the spec, and is how Firefox implements it.

[henbos]

Oh right, that makes sense.

[jan-ivar]

@jesup schooled me on the round-trip time calculation, and it turns out it can't be calculated until an RR comes in with data based off a remotely-receivecd SR. In other words, not necessarily the first RR.

So based on the same reading of the stats spec I mentioned above I think it makes sense for the roundTripTime member to be missing (effectively undefined) until a proper value is available. Does that make sense?

[henbos]

Yes.

[jesup]

I agree - missing/undefined

[vr000m]

I will fix it.