Fix *mos_min_mult10 calculation

[olebowle]

Fix mos_min_mult10, a_mos_min_mult10, b_mos_min_mult10 being derived from mos*_avg and not from mos*_min, as one would expect: mos.patch

Also, opt_mosmin_f2 should IMHO default to zero. Why is this option available anyway?

[voipmonitor]

mos_min_mult10 is used for

                            cdr.add(mos_min_mult10[i], c+"_mos_min_mult10");

which stores MIN(mos_f1,mos_f2,mos_adapt) - where all trhee are derived from average mos (for f1,f2,adapt). It might look confusing but the code is intended to store minimal f1,f2,adapt to single mos column a|b__mos_min_mult10

[olebowle]

Thanks for the comment!

From the column field name I assumed, that it is the absolute minimum MOS value seen during the conversation and not the minimum of the average MOS from f1, f2, adapt. Using mos*_min instead of mos*_avg would show a degraded call quality much more quickly, which I'd consider a feature. Due to the averaging nature I assume mos_min_mult10, a_mos_min_mult10 and b_mos_min_mult10 are 45 most of the time, even if there was a short issue during the call (depending on the call duration of course). Thus, for our purpose I'd ignore those values and rather look at {a,b}_mos_{f1,f2,adapt}_min_mult10.

Anyway, you still always overwrite mos_min_mult10[i] with mos_f2_mult10 if the latter is available, since opt_mosmin_f2 equals 1.

[voipmonitor]

Hi Ole,

The beggist problem is how to incorporate characteristic of the MOS into single value. MIN can generate too much false positive issues with MOS since some calls can have only very short low mos duration while the average will mask / hide small burst low MOS scores. The best might be to use some percentiles instead like 99th percentile MOS but this requires sorting and additional memory for calculating it.

Regarding opt_mosmin_f2 - this is because the most relevant MOS score is for the fixed 200ms jitterbuffer instead of f1 (50ms) which will alert whenever there is jitter - thats why there is this option which in the end takes mos score from the f2. Maybe this can be changed to avoid only mos f1 and use min(f2,adapt). What is your thought.

2016-06-08 15:36 GMT+02:00 Ole Ernst notifications@github.com:

Thanks for the comment!

From the column field name I assumed, that it is the absolute minimum MOS value seen during the conversation and not the minimum of the average MOS from f1, f2, adapt. Using mosmin instead of mosavg would show a degraded call quality much more quickly, which I'd consider a feature. Due to the averaging nature I assume mos_min_mult10, a_mos_min_mult10 and b_mos_min_mult10 are 45 most of the time, even if there was a short issue during the call (depending on the call duration of course). Thus, for our purpose I'd ignore those values and rather look at {a,b}mos{f1,f2,adapt}_min_mult10.

Anyway, you still always overwrite mos_min_mult10[i] with mos_f2_mult10 if the latter is available, since opt_mosmin_f2 equals 1.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/voipmonitor/sniffer/issues/32#issuecomment-224590503, or mute the thread https://github.com/notifications/unsubscribe/AGt_pxztHhsC4AnysQ9zhL8RBfky3gr9ks5qJsVCgaJpZM4Iw4Iw .

Best regards Martin Vit

[olebowle]

I got your point regarding false positives. I'm not too familiar with the MOS values yet, as I just started using voipmonitor. I'll keep on watching the MOS values and see if they work for us (I believe they will).

Regarding opt_mosmin_f2: I think an option in voipmonitor.conf (along with a short explanation) would be the best and most transparent solution for the user.

[voipmonitor]

yes, good idea. Internal ticket VS-452 created.