Not sure why you would use mean latency - for VoIP the thing that
matters is maximum latency - if some packets are late, then you don't
hear them. More precisely a small packet loss rate is OK, so you should
use something like the 99th percentile of latency. In my last jitter
buffer implementation I ran an estimator for 99th percentile latency,
and added 5ms.
That said, most jitter buffers in use are poor implementations, and
introduce more latency than necessary.
Simon
On 11/28/2012 11:21 AM, Greg White wrote:
Jitter on its own is not useful for estimating VoIP quality.
For (c), I've used:
Cole, Robert G., and Joshua H. Rosenbluth.
"Voice over IP performance
monitoring." ACM SIGCOMM Computer Communication Review 31, no. 2 (2001):
9-24.
Which I generally simplify to:
R= 94.2 - 0.024*Latency -
0.11*max(0,Latency-177.3 ms) - 30*log(1 +
15*Loss).
where Loss is mean packet loss rate (counting packets with latency >
(min_latency + 60ms) as lost), Latency is mean latency for packets not
counted as lost.
You can then translate R into an estimate of MOS using Eq.1 in the above
reference.
-Greg
On 11/27/12 5:51 PM, "Toke Høiland-Jørgensen" <[email protected]> wrote:
Oliver Hohlfeld
<[email protected]> writes:
The jitter measurements you have in mind will give you an idea on the
jitter specific to the chosen traffic scenario, nothing more --- and
in particular not the VoIP quality (although low vs. high jitter could
/indicate/ certain /possible/ quality degradations).
Well no, in this sense the only "real" test for voip quality is picking
up the (soft)phone and talking to someone. However, since the context
here is automated measuring tools (preferably generating solid
quantitative, comparable data), that is hardly feasible.
I guess the goal of a comprehensive testing suite is to gather as many
indicators of quality degradations (in the widest possible sense) as
possible and testing for them under a variety of traffic conditions. I
am by no means an expert on VoIP, but someone suggested measuring jitter
could be useful, and I've proposed a possible way to do that (using
iperf udp flows at a low-ish bandwidth).
Since for the purpose of this particular discussion I seem to be in the
test tool building business (at least for the time being), what I really
need before going forward with this is someone to comment on (a) if
using iperf udp flows is a valid way to measure jitter, (b) if measuring
jitter is actually something someone wants to do and (c) if there are
other tests that would be useful for testing VoIP (or general)
conditions instead of / in addition to the jitter measurements.
So far I don't have an answer to (a), only negative answers to (b) and
nothing concrete for (c). So for the time being I'm shelving the idea,
and will just note that it seems quite feasible to return to it should
someone change their mind on (b) :)
-Toke
--
Toke Høiland-Jørgensen
[email protected]
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
