Re: per-DataChannel stats: on PeerConnection or on DataChannel?

Hi Peter,

Thank you for putting together the proposal, I like that the we can query the DataChannel streams separately. Also like the idea of for RtpSender and RtpReceiver, instead of passing the selector. However, I would still like the ability to get all the stats from all the objects in a PC via a single API call, for example for monitoring purposes.

I believe we would need to at least restructure the stats and associate them in more meaningful ways, see below.

In the case of RtpSender, it would report the:
- current OutboundRtpStats
- MediaStreamTrackStats depending on the associated track.
- associated stats from the RTCP RR/XR (with a reception timestamp).

And in the case of RtpReceiver, it would report the:
- current InboundRtpStats
- almost all the MediaStreamTrackStats associated to the track.
- any additional metrics exposed via Extension Reports.
- associated stats from the RTCP SR (with a reception timestamp).

Additionally, we have several stats that are not yet associated to any object and those I suppose these would still need to be accessed via the PeerConnection, for example:
- Transport Stats (apply to the complete PC)
- IceCandidatePairStats (how much sent/received on a particular pair)
- IceCandidateAtrributes and CertificateStats  (IIRC at the TPAC14, we decided to also expose them via an alternative API?)


Cheers,
Varun


On 18 Dec 2014, at 22:20, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

​In the current WebRTC draft, we have:

partial interface RTCPeerConnection {
    void getStats (MediaStreamTrack? selector, RTCStatsCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
}

To add the ability to get stats about a particular RTCDataChannel do we want to have

A.  ​PeerConnection.getStats(RTCDataChannel, ..., ...), like so:

partial interface RTCPeerConnection {
    void getStats (RTCDataChannel? selector, RTCStatsCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
}


or


B.  RTCDataChannel.getStats(..., ...) like so:



partial interface RTCDataChannel {
    void getStats (RTCStatsCallback successCallback, RTCPeerConnectionErrorCallback failureCallback);
}



I prefer B.  LIkewise, I think it makes sense to eventually have RtpSender.getStats, DtlsTransport.getStats, and IceTransport.getStats.  That way, the browser doesn't have to gather stats about everything to get stats about something, and we don't have to add a new PeerConnection.getStats overload for every single new object we add.


Has there already been discussion about this that I don't remember?




—
http://www.netlab.tkk.fi/~varun