Re: Regarding webrtc-stats monitored object ID

That said, it's easy to add utility/helper functions or extensions to any
of the objects that do exist in the API to help look up specific objects in
stats. If you have an RTCStatsReport and a relevant object such as a
MediaStreamTrack, it's easy to iterate the report and filter out the
associated stats objects, it just requires some special logic depending on
which type of object was used for lookup. In some cases there are multiple
"related" stats objects (e.g. "track"), in some cases there is just one.

Here's a picture of the graph produced by getStats(), where the arrows
indicate "Id" reference. (Showing stats types, not actual stats object,
i.e. there would be multiple objects of most types in a real dump).




On Sat, Jun 29, 2019 at 9:18 PM Henrik Boström <hbos@google.com> wrote:

> 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
>>
>>