The CL[1] in progress does not address an important TODO that needs to be addressed before closing this issue. Quoting deadbeef@:
It's not sufficient to make candidate stats from ConnectionInfos (which are
effectively candidate pairs). The channel could have candidates that aren't
paired with anything.
Really we need to add individual candidate lists to TransportChannelStats, and
implement forming the list in P2PTransportChannel. Which isn't completely
trivial, since there aren't ready-built lists; local candidates come from Port
objects, and prflx candidates (both local and remote) are only stored in
candidate pairs.
[1] https://codereview.webrtc.org/2384143002/
I think one example of such non-paired stats is if one end has IPv6 (and thus IPv6 candidates) and the other end has IPv4 only. The IPv6 candidates won't be paired with anything. But we still want them returned.
(This argues that candidates should be marked with whether they are remote or local, even when not paired. https://github.com/w3c/webrtc-stats/issues/65
This example may be useful in writing a test.
This stats dictionary is partially supported (see landed CLs in this thread).
To better track what's left, a webrtc bug has been created to track the remaining work related to this dictionary - merging into that one.
Comment 1 by hbos@chromium.org
, Oct 7 2016