Re: stats api webidl implementers feedback

On 10/24/13 2:14 AM, Harald Alvestrand wrote:
> Missed one question earlier:
>
> you added "unsigned long long priority". 64-bit? What does this 
> correspond to?
I'm told that in ICE every candidate pair has a 64-bit priority that 
determines the order in which the pairs are checked. It is the two 
candidates' 32-bit priorities concatenated (it is how the ICE spec is 
written, and how the values are stored in nICEr which we use)

We include them for debugging, if only to detect duplicate priority (a 
moderately bad thing).

(more below)

> On 10/23/2013 05:28 PM, Jan-Ivar Bruaroey wrote:
>>>> dictionary RTCIceCandidatePairStats : RTCStats {
>>>> - DOMString componentId;
>>>> + DOMString candidatePairId;
>>>
>>> Don't understand this change. componentId is needed to group all the 
>>> candidate pairs that are
>>> linked to the same component. The candidate pair already has an ID - 
>>> the "id" field.
>>
>> OK, thanks. Probably a misunderstanding. This is an ICE "component"?
>>
>>>
>>>> DOMString localCandidateId;
>>>> DOMString remoteCandidateId;
>>>> + RTCStatsIceCandidatePairState state;
>>>> - boolean writable; // Has gotten ACK to an ICE request
>>>> - boolean readable; // Has gotten a valid incoming ICE request
>>>
>>> Where will you keep the information about whether a candidate pair 
>>> is working or not, if you
>>> don't keep it here?
>>
>> Not sure, will check with the person who did this part. :-)

Apparently, writable can be deduced from RTCStatsIceCandidatePairState 
== "succeeded".

Though "readable" we should probably put back in. Is it useful?

.: Jan-Ivar :.

>>
>>>
>>>> + unsigned long long priority;
>>>> + boolean nominated; // Internal?
>>>> + boolean selected; // Internal?
>>>> -}
>>>> +};