Re: Regarding webrtc-stats monitored object ID

The purpose of the "id" is to correlate stats between getStats() calls
(e.g. calculate average over an interval based on two total counters), and
the id should not be predictable (issue
<https://github.com/w3c/webrtc-stats/issues/437>).

Not every underlying object that stats are produced for have an ID, or is
even accessible as an object (and sometimes they're conceptual,
representing a connection). Examples of underlying objects that don't have
an API are "outbound-rtp" and "inbound-rtp" objects, they represent RTP
media streams produced by RTCRtpSender/RTCRtpReceiver objects. There is no
API-visible "RTCOutboundRtp" object. In this case, the "ssrc" can be used
to figure out which packet stream is described, but there is no general
identifier pattern or actual object. In other cases there is an object with
an id, for example MediaStreamTrack.id, in these cases there is a
"trackIdentifier" (if you see a stats member name ending with "Identifier",
then it refers to an API-visible object's "id"). Would it be useful to have
a MediaStreamTrack.getStatsId()? Perhaps, but this would require an
extension to the GETUSERMEDIA spec (related to but outside the WebRTC
spec), and it doesn't solve the entire problem:

Sometimes the same object may result in multiple associated stats. For
example, "track" stats objects represent one attachment of a
MediaStreamTrack to a RTCRtpSender. In this case, there can exist multiple
track stats objects where track.trackIdentifier ==  MediaStreamTrack.id (if
you have multiple senders all sending the same track). In this case,
getStatsId() would have to return multiple IDs.
But it doesn't just end there. The same track could be used with multiple
RTCPeerConnections, i.e. with multiple totally independent stats
collectors. What would the API be then, "sequence<DOMString>
MediaStreamTrack::getStatsIds(RTCPeerConnection pc)"?

I think there is room for better stats-lookup, perhaps even more so in a
non-browser based implementation, but I'm skeptical to this happening in
the WebRTC 1.0 specs.

On Sat, Jun 29, 2019 at 7:43 PM Hugo Arregui <hugo.arregui@mykolab.com>
wrote:

> [Sorry I realise now that I didn't send my answer to the mailing list]
>
> Hello again,
>
> Thanks for your comments and suggestions!
>
> > and given that this is a fresh API and outside the browser you
> > are free to do as you will ;-)
> > but I think ObjectID is a bit too broad - perhaps StatsID ?
>
> I thought it might be useful to share the approach we decided to follow:
>
> We added the statsID to every monitored object, but we are keeping it
> private. Taking advantage of the fact that in go objects of the same
> package can access private members of each other, we added a set of
> helper methods to the report object to retrieve the associated stats of
> a given monitored object, for example:
>
> ```
> func (r StatsReport) GetConnectionStats(conn *PeerConnection)
> (PeerConnectionStats, bool) {
>      statsID := conn.getStatsID()
>      stats, ok := r[statsID]
> ...
>      return pcStats, true
> }
> ```
>
> This is a pretty neat API IMO, but unfortunately this is not a portable
> solution, since it relies on the package visibility of the go
> programming language. IMHO exposing the stats id of the monitored
> objects will help to have a cleaner API when you are doing things like
> online analysis (I mean that as oppose of storing stats for offline
> processing later).
>
> Thanks again!
> Regards,
> Hugo
>
>