- From: Nils Ohlmeier via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 Jan 2017 22:38:28 +0000
- To: public-webrtc-logs@w3.org
@henbos the candidate and pair stats were added to Fx way before the spec even mentioned them. And they were added purely for purpose of our own tests to verify transport parameters of a running call. Your point regarding localcandidates vs successful pair raises again the general question of the what the user is looking for. E.g. if getStats() gets called with the filter does he only want to see the successful pair, or is trying to find our if a relayed pair got generated but not used? Providing the "right" transport stats for a track is actually not easy, because of bundle. E.g. if the track happens to be an m-line which is the bundle-slave, should we provide the pair of the bundle-master (which is a different m-line and track) or nothing at all? I think the easiest solution forward regarding the filter is to not include any transport stats (ICE and DTLS/certs) at all if a filter was provided. And only provide the transport stats if getStats() gets called without a filter (and then provide everything: all candidates and pairs). IMO the most sensible thing would be to move transport related stats over to the ICE and DTLS transport objects. And not deliver them with any track, but only for the unfiltered call. Maybe a sensible alternative would be to add more/different filters to the getStats() call, to allow filtering down into the transport specifics stats only. But I guess both of these would be pretty big changes at this point. -- GitHub Notification of comment by nils-ohlmeier Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/116#issuecomment-271430555 using your GitHub account
Received on Monday, 9 January 2017 22:38:39 UTC