RE: Stats interface - Some comments on specific stats

See below.

Andy

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: 17 September 2012 19:13
> 
> 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.

[AndyH] - Understood so maybe we need both. If the application is gathering and logging stats at the end of session then it would not want just the last RTT but an average for the session.

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

[AndyH] We need an indication how many periods of silence suppression there has been during the session. How this is counted I understand depends on the codec in use. For some codec's probably a simply count of the RTP packets received with the marker bit set would be ok.

> >
> > 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.

[AndyH] Probably we need something more than just the current value again for the case when an application just logs stats for the whole session when it ends.

> >
> >
> > 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 21:36:27 UTC