W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

RE: Media Stastics in API

From: Gunnar Heikkilä <gunnar.heikkila@ericsson.com>
Date: Thu, 1 Sep 2011 11:50:09 +0200
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
CC: Gunnar Heikkilä <gunnar.heikkila@ericsson.com>
Message-ID: <BCAD297FC0C0D244894589EE45FE8B47136B91972D@ESESSCMS0364.eemea.ericsson.se>
Hi Randall, others,

> > You also need to provide these measurements for each individual stream
> > which is part of the session (maybe this is implicit in your proposal).
> Yes, though with the expected multiplexing in most cases delay and several
> others should be the same.

I think this is mostly true for delay-related metrics. Other metrics could very well vary per media. For instance, video packets are usually larger than audio packets, and thus have a higher probability to be lost on channels with bursty disturbancies (e.g. mobile broadband). Even delay could (in theory) differ depending on packet sizes if the base station scheduler prioritizes small packets before large ones.

> Codecs in use in each direction  

Agree.

> Bitrate per stream

Agree. But average bitrate might not be suitable for all services. For instance, if you use DTX for voice traffic the average bitrate is about half of the full codec bitrate, but the exerienced voice quality is mainly dependent on the bitrate during active speech. So some kind of "average active bitrate", "90% percentile", or similar probably would make sense.

> For video streams, frame rate and resolution.

Also for speech the frame rate could be interesting (as it typically should be added (twice) to the RTCP RTT measurement to get user-perceived RTT). Or maybe report some kind of "processing delay" which can be added to RTCP RTT? Or even included in the reported RTT?

Best regards
   Gunnar Heikkilä (sitting some rooms away from Stefan Håkansson)
Received on Friday, 2 September 2011 08:18:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC