Issue 230: Stats API: getStats on the IceGatherer??

>From Philipp Hancke:

getStats on the IceGatherer doesn't make much sense to me. Everything interesting (candidate pairs) will happen on the IceTransport. Now the IceTransport knows about remote candidates but (technically) not about local candidates. But that means that the candidate pair from the transport references local candidate ids which need to be obtained from a getStats call to the ice gatherer.
So if the icetransport knows the local candidate ids, can't it just proxy stats for them?

More from Philipp:

Noticed another issue with getStats. Unlike in the peerconnection API, stats are separate for each object. As an application developer, I've often been filtering the "snowball" returned by the peerconnection getStats to kind of emulate this so this makes sense. But...

Looking at*

it seems like the iceTransport would return stats with type candidatePair and remoteCandidate

whereas the iceGatherer would return stats with type=localCandidate.

The candidate pair statistics, defined in* reference the remote candidate and the local candidate. However, a naive approach to lookup the local candidate based on that id (similar to what is shown in will fail.

This is likely to affect other stats reports as well.

For the iceTransport I wonder if it could/should proxy the stats from the associated gatherer.

Using Promise.all it's not terribly difficult to merge the results from two or more getStats calls into one result set which might the pragmatic thing for an application developer to do. At least the API allows the flexibility to ignore things we are not interested in :-)

Also, I am not sure if getStats on the iceGatherer makes sense. The only attribute of the stats that is not directly available from the gatherer (e.g. through g is addressSourceUrl (which indicates the url of the stun/turn server used to gather this candidate).
[Peter Thatcher]

Received on Thursday, 24 September 2015 07:12:46 UTC