RE: Stats interface - Some comments on specific stats

Hi Harald,

See below

Regards
Andy

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: 18 September 2012 00:11
> To: public-webrtc@w3.org
> Subject: Re: Stats interface - Some comments on specific stats
> 
> On 09/17/2012 02:35 PM, Hutton, Andrew wrote:
> >
> >>> 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.
> I'm still a bit naive about this stuff, so could you explain it in
> excruitating detail for some example codec?
> IE if you have an SSRC that is switched between g.711 and comfort
> noise,
> we could count the packets with each payload type, but that's not the
> same data as "periods of silence suppression" - for that, we would have
> to count the number of times a CN packet arrived after a G.711 packet.

For G.711 and some other codec's then RFC 3389 states that "The receiver can detect silence suppression on the first packet received after the silence by observing that the RTP timestamp is not contiguous with the end of the interval covered by the previous packet even though the RTP sequence number has incremented only by one". 

Such a count would I think be useful if silence suppression is enabled as experience has shown that this can be the cause of audio quality issues.

> 
> I don't know how we would do this with OPUS.

It would not apply to OPUS assuming unless the OPUS implementation in the browser implements the discontinuous transmission mode.

> 
> Another question .... what's the use case - ie what decision do you
> want
> to make based on this data?
> 

Simply want to work out the likely source and cause of audio quality issues.


>

Received on Wednesday, 19 September 2012 18:58:15 UTC