Missing consent interval in RTCIceCandidatePairStats about webrtc-stats HOT 8 CLOSED

As Peter described in Lisbon, we don't really have a fixed consent interval, because for us, "consent checks" serve a double purpose as connectivity checks, and as a way of evaluating the RTT. So we may send them more or less frequently based on the state of the connection.

We still could probably expose some interval in the stats. But it would need to be variable.

from webrtc-stats.

That interval, although variable would be a sufficient.

Developers will probably query this when the ICE goes to the disconnected state, mainly to determine the duration of loss in connectivity.

from webrtc-stats.

So the useful number would be the interval between the last two connectivity checks sent?

from webrtc-stats.

Yes. The interval between the last two checks. And perhaps a long term average, sum of intervals should be sufficient as we can divide that by the (total number of checks-1)

from webrtc-stats.

Hm. If connectivity is lost, you won't get duration of loss in connectivity from the interval between the last two checks; both were sent before connectivity was lost.
Two interesting numbers are:

• Time of last successful check (which places an upper bound on how long connectivity has been lost)
• Sum and count of intervals

A third interesting number might be the time of the last check sent (which would be a failed one in the case of lost connectivity).

from webrtc-stats.

These two would work for me.

from webrtc-stats.

will you write the PR to add lastCheck and sumCheckInterval?

from webrtc-stats.

Yes.
On Tue, 18 Oct 2016 at 15.33, Harald Alvestrand [email protected]
wrote:

will you write the PR to add lastCheck and sumCheckInterval?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#63 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXVkt5cT3OKYVWEqI-15DuJB3PgTItfks5q1UlBgaJpZM4KEDIS
.

from webrtc-stats.