23 Apr
2021
23 Apr
'21
11:44 p.m.
On Thu, Apr 22, 2021 at 12:36 AM Giovanni Maruzzelli <gmaruzz(a)gmail.com>
wrote:
sipjs, I haven't looked, but I usually expect to find the interarrival
jitter defined in the RTP 3550, which is an estimation / EWMA
On Wed, Apr 21, 2021 at 5:19 PM Julien Chavanton
<jchavanton(a)gmail.com>
wrote:
Makes sense to me, RTCP-XR is proposing many new metrics, some related to
transmission other to signal and filters.
Burst density seems interesting to extrapolate the impact of transmission
problems since PLC can only help for up to 60ms large bursts are more
likely to impact intelligibility than spreaded losses.
Even if all of this will always be a rough estimate since as an example the
impact on intelligibility will always be quite random, I still think the
ITU did more R&D than anyone else in this field.
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