W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2017

Re: [webrtc-stats] RTCPeerConnection.getStats: What to do with 'selector' argument?

From: Nils Ohlmeier via GitHub <sysbot+gh@w3.org>
Date: Mon, 09 Jan 2017 22:38:28 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-271430555-1484001507-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:41 UTC