- From: Byron Campen <docfaraday@gmail.com>
- Date: Mon, 28 Oct 2013 10:32:16 -0700
- To: public-webrtc@w3.org
- Message-ID: <526E9FA0.8060809@gmail.com>
> 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