getStats feedback

I 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
http://ortc.org/wp-content/uploads/2015/06/ortc.html#rtcstatstype*
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
http://w3c.github.io/webrtc-stats/#candidatepair-dict* 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
http://ortc.org/wp-content/uploads/2015/06/ortc.html#example) 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).

cheers

philipp