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