[prev in list] [next in list] [prev in thread] [next in thread]
List: serusers
Subject: Re: [SR-Users] [ANNOUNCE]: sipnagios, a Nagios Plugin to check Call Quality in SIP VoIP (compatible
From: Julien Chavanton <jchavanton () gmail ! com>
Date: 2021-04-23 20:44:53
Message-ID: CAKmcL2nss9wkNc_FGYm2KL6KvT_dkKzmODOaw+EXuXfStp8=vQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Apr 22, 2021 at 12:36 AM Giovanni Maruzzelli <gmaruzz@gmail.com>
wrote:
> On Wed, Apr 21, 2021 at 5:19 PM Julien Chavanton <jchavanton@gmail.com>
> 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.
>
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.
>
>> 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?
>
sipjs, I haven't looked, but I usually expect to find the interarrival
jitter defined in the RTP 3550, which is an estimation / EWMA
>
>
>> 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
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Apr 22, 2021 at 12:36 AM Giovanni Maruzzelli <<a \
href="mailto:gmaruzz@gmail.com">gmaruzz@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Apr 21, 2021 \
at 5:19 PM Julien Chavanton <<a href="mailto:jchavanton@gmail.com" \
target="_blank">jchavanton@gmail.com</a>> wrote:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div><br></div><div>Few notes on the mos-lq (listening quality), it \
consider both losses from jitter (discarded) and never received.<br></div><div>I \
tried to keep the equation and variables as defined in the ITU, but it is relatively \
simple in the end.<br></div><div>One thing missing is the delay impairment to have \
mos-cq this would be RTT + jitter buffer size of both endpoints.</div><div>This way \
we will correctly account for jitter impairment in terms of loss and \
delay.<br></div><div><br></div></div></blockquote><div><br></div><div>Nice!</div><div><br></div><div>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.</div><div>It will be easier and more precise to combine \
these statistics to obtain better \
accuracy.</div></div></div></blockquote><div><br></div><div>Makes sense to me, \
RTCP-XR is proposing many new metrics, some related to transmission other to signal \
and filters.<br></div><div>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.<br></div><div>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.<br></div><div> <br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>More context \
on jitter, as I recently went back looking at some MOS score \
computation.<br></div><div><div>Since we compute MOS in the endpoint it can be more \
precise when it comes to jitter.<br></div><div>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.</div><div>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.<br></div></div></div></blockquote><div><br></div><div>How do \
you judge sipjs implementation of jitter measurements? \
<br></div></div></div></blockquote><div><br></div><div>sipjs, I haven't looked, \
but I usually expect to find the interarrival jitter defined in the RTP 3550, which \
is an estimation / EWMA <br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><div></div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div><div></div><div><br></div><div>Let's remember to keep each other \
posted if we improve this \
further.</div><div><br></div></div></div></blockquote><div><br></div><div>Definitely!!!</div><div>And \
thanks again for VoIP \
Patrol!</div><div><br></div><div>-giovanni</div><div><br></div></div>-- <br><div \
dir="ltr">Sincerely,<br><br>Giovanni Maruzzelli<br>OpenTelecom.IT<br>cell: +39 347 \
266 56 18<br><br></div></div> </blockquote></div></div>
_______________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic