[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Suggestion for how to handle derived/computedmetricindraft-avt-rtcpxr-*



"Alan Clark" <alan.d.clark at telchemy.com> writes:
>The approach used for voice quality is fairly straightforward.  There are
>several parameters that are defined on a codec specific basis - notably Ie
>and Bpl, where Ie identifies the quality degradation due to the encoder and
>Bpl the robustness of the PLC algorithm against packet loss/ discard.  The
>endpoint incorporates a small table of these values for each voice codec
>that it supports.  Based on the codec selected for the call - the
>appropriate parameters are used.  Some other parameters, for example signal
>level, noise level, echo, delay, are less codec dependant.  A good source of
>information on how to do this using G.107 is ITU-T Recommendation G.799.1,
>which is a VoIP trunking gateway standard that incorporates a clear
>definition of how to compute the R factors and MOS scores required by RTCP
>XR.

I read G.799.1, and I saw no reference on how to calculate R or MOS.  Even
if they're elsewhere or in an appendix I missed, those may not (properly)
handle things like adaptive jitter buffers (G.799.1 mentions jitter buffers
briefly, but implies the delay must be chosen according to the goals of
the network - implying a fixed jitter buffer).  Given all the ways an
adaptive jitter buffer can deal with lengthening and shrinking the buffer,
I don't think any objective algorithm is going to do a good job of
measuring the effect of that operation, certainly not from outside the
jitter buffer/codec code.

Roni's point was that UA developers generally get black-box codecs to play
with.  They generally know about packet loss, jitter (going into the jitter
buffer), codec, etc , but PLC may well be hidden from them.  Also, a loss
of a packet when someone is listening (i.e. silence) has far less effect
than a loss at the start of a word (witness the Neil Armstrong moon
landing, sort of), and the UA developer probably doesn't know if the
packets on either side of the loss indicate that there was talking or not.

This is doubly the case for video.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt