W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2019

Re: Regarding webrtc-stats monitored object ID

From: westhawk <thp@westhawk.co.uk>
Date: Tue, 25 Jun 2019 10:25:15 +0100
Cc: public-webrtc@w3.org
Message-Id: <67699C61-88A5-4702-8586-EF4EACFEA6F3@westhawk.co.uk>
To: Hugo Arregui <hugo.arregui@mykolab.com>

> On 24 Jun 2019, at 20:52, Hugo Arregui <hugo.arregui@mykolab.com> wrote:
> Hello,
> I'm starting the implementation of the webrtc-stats spec in pion (https://github.com/pion/webrtc), a pure go webrtc library. We are discussing what's the best approach to follow in regards to the ids of the monitored objects. You can read the full discussion (or review the implementation) in https://github.com/pion/webrtc/pull/721 but I'll put all the information here.
> The spec is pretty clear regarding the id, quoting:
>> A unique id that is associated with the object that was inspected to produce this RTCStats object. Two RTCStats objects, extracted from two different RTCStatsReport objects, MUST have the same id if they were produced by inspecting the same underlying object. User agents are free to pick any format for the id as long as it meets the requirements above.
> So I think is fair to say:
> a) every monitored object has an ID
> b) the stats for a given object are referenced by such ID
> We understand the spec doesn't indicate the monitored object ID should be available in the monitored object itself, and we are a bit worried about adding it for some general push back against the idea of adding ids to webrtc objects https://www.w3.org/2018/04/12-webrtc-minutes#item06, however, at the same time, we can see how exposing such ids will be a quite convenient way of accessing stats, for example:
> report := conn.GetStats()
> // get connection stats
> report[conn.ObjectID()]
> // get DC stats
> report[dc.ObjectID()]
> We are wondering if you have any thoughts or suggestions as how to resolve this situation, or if perhaps we are missing the point and that's not the intended usage of the API.

Reading between the lines ( I wasn’t at that meeting) - I think the intent of the spec is to ensure that you can correlate the data from 2 invocations of getStats(), even if some of the underlying ids have changed - eg ssrc or rid - due to user actions.

id := findIdForSsrc(ssrc)
report1 := conn.GetStats()
//time passes
report2 := conn.GetStats()

traffic := report2[id].octets - report1[id].octets

should work 

The reticence (I guess) you see is probably about fingerprinting - so a user re-visiting a page and reconnecting to a webRTC service should _not_ generate the same (or predictable) stats Ids that could be used to track them. 
The slightly oblique notes are probably about how to preserve the usefulness of stored ids in the case of SDP rollback. 

I quite like your 
> report[dc.ObjectID()]

idea, 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 ?

> Thanks,
> Regards,
> Hugo Arregui

P.S. It is _great_ to see more webrtc stacks emerging!

Received on Tuesday, 25 June 2019 09:25:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:48 UTC