W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

Re: stats api webidl implementers feedback

From: Byron Campen <docfaraday@gmail.com>
Date: Mon, 28 Oct 2013 10:32:16 -0700
Message-ID: <526E9FA0.8060809@gmail.com>
To: public-webrtc@w3.org
 > On 24 October 2013 12:41, Harald Alvestrand <harald@alvestrand.no> wrote:
 > > The 64-bit version seems to be here:
 > >
 > > http://tools.ietf.org/html/rfc5245#page-113
 > >
 > > Perhaps it's simplest to represent this as a 31-bit priority on the
 > > candidate; anyone who wants to compute the 64-bit value can easily 
do so
 > > from the 2 candidates.
 >
 > Right.  The transformation from candidate priorities to candidate pair
 > priorities is canonical, so no strong need to expose it as a separate
 > property.  In general, derived properties can be dropped.

Not so fast; in order to perform this computation, you need to know who 
is the ICE controller, which is not currently captured in this API. It 
is not always easy for content to guess whether they are the controller 
either (see http://tools.ietf.org/html/rfc5245#section-7.1.2.2). In 
addition, it is possible for this to change during ICE (see 
http://tools.ietf.org/html/rfc5245#appendix-B.11).

At a minimum, we need to include whether we think we are currently the 
controller. But even if we do, there are enough moving parts here that 
this computation could be buggy even in the implementation proper, let 
alone a parallel computation in content by a web developer who doesn't 
really want to learn ICE inside and out.

Given that part of the motivation for this API is debugging, I think it 
makes sense to convey both the individual priorities and the pair 
priority, along with whether we believe we are currently the controller. 
But that's just my two cents.

Best regards,
Byron Campen
Received on Wednesday, 30 October 2013 08:28:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC