[SR-Users] [ANNOUNCE]: sipnagios, a Nagios Plugin to check Call Quality in SIP VoIP (compatible with checkmk, etc)
gmaruzz at gmail.com
Thu Apr 22 09:36:18 CEST 2021
On Wed, Apr 21, 2021 at 5:19 PM Julien Chavanton <jchavanton at gmail.com>
> 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.
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
> More context on jitter, as I recently went back looking at some MOS score
> 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
How do you judge sipjs implementation of jitter measurements?
> Let's remember to keep each other posted if we improve this further.
And thanks again for VoIP Patrol!
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users