On Wed, Apr 21, 2021 at 5:19 PM Julien Chavanton <[email protected]>
wrote:

>
> Few notes on the mos-lq (listening quality), it consider both losses from
> jitter (discarded) and never received.
> I tried to keep the equation and variables as defined in the ITU, but it
> is relatively simple in the end.
> One thing missing is the delay impairment to have mos-cq this would be RTT
> + jitter buffer size of both endpoints.
> This way we will correctly account for jitter impairment in terms of loss
> and delay.
>
>
Nice!

What I would liker to do, in an undefined future :), is to use the pjsip
machinery for streaming audio from and to a file, so it will have their
tried and true rtcp, rtcp-xr, etc implementation.
It will be easier and more precise to combine these statistics to obtain
better accuracy.


> More context on jitter, as I recently went back looking at some MOS score
> computation.
> Since we compute MOS in the endpoint it can be more precise when it comes
> to jitter.
> In most cases, when done in a relay, I found that jitter is hard (or not
> accounted) for properly, since we extrapolate adaptive / static buffers
> that will receive the packets.
> What I found in most cases was jitter x 2 like in rtp-engine seems like
> the best option but should endup underestimating the impairment as this
> would mean an adaptive buffer and assume not too much jitter of jitter
> meaning the size of the buffer based on estimate is always fine with the
> given jitter and not dropping late packets and it must drop packets when it
> shrinks.
>

How do you judge sipjs implementation of jitter measurements?


> Let's remember to keep each other posted if we improve this further.
>
>
Definitely!!!
And thanks again for VoIP Patrol!

-giovanni

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to