Re: Stats interface - Some comments on specific stats

On 09/17/2012 10:05 AM, Hutton, Andrew wrote:
> Hi Harald,
>
> Some comments/questions on the proposal regarding.
>
> 1) My understanding of the spec is that the application is in full control of when to start/stop reporting, allowing the application to collect periodic reports or for the complete session. Can you confirm that the stats can be retrieved at the time the PeerConnection ends.
Yes, that is my intention.
>
> 2) RTT should be the average round trip time over the reporting period can you confirm that this is the case.
I don't think this is right, since when RTT changes over the course of 
the call, you often want the current estimate, not the estimate of 10 
minutes ago. The RTT estimate should be the current value of the metric 
defined in the relevant RFC.
>
> 3) The number of Silence suppressions in the RTP stream in a reporting period need to be included.
What's a silence suppression, and how do we count them?
>
> 4) "Jitter" implies maximum jitter in the reporting period, is this correct?
Again, I think this is the current value of the relevant metric. If we 
want a max value, it's best to define a separate metric for this.
>
>
> Regards
> Andy
>
>
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>> Sent: 02 September 2012 08:45
>> To: public-webrtc@w3.org
>> Subject: Re: Stats interface - modelling on IndexedDB API?
>>
>> Attaching the latest proposal after the changes.
>>
>> On 08/30/2012 01:03 PM, Stefan Hakansson LK wrote:
>>> On 08/30/2012 12:53 PM, Harald Alvestrand wrote:
>>>> Hi,
>>>>
>>>> when implementing the Stats interface, I've concluded that it's not
>>>> quite trivial to do it the way I'd written it up, due to the way
>> WebKit
>>>> hangs together.
>>>>
>>>> Would anyone mind terribly if I changed it around to do it the way
>> the
>>>> IndexedDB API does it?
>>>>
>>>> Basically, it seems to be:
>>>>
>>>> - Request returns a "request object" with a status and a result
>>>> - When the data is ready, it fires a "success" event at the request
>>>> object
>>>> - The caller can then read the data out from the request object
>>> I think the new approach you propose is better than the old one. It
>>> aligns with e.g. IndexDB and FileReader.
>>>
>>>> http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest
>>>>
>>>> Seems a bit easier to get threaded through WebKit than the "simpler"
>>>> method of "just" returning a complex structure in a callback.
>>>>
>>>>                         Harald
>>>>
>>>>
>>>

Received on Monday, 17 September 2012 18:13:05 UTC