No idea about Zabbix api, at the moment, maybe is the same as the Nagios one. If not, it will be easy to implement, just by changing exit status and the way perf data are printed (if Zabbix supports perf data). I'll add this to the TODO. Thanks Daniel! -giovanni answered from mobile, please pardon terseness and typos, -giovanni On Wed, Apr 21, 2021, 14:51 Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: Hello, On 21.04.21 11:42, Giovanni Maruzzelli wrote: <https://github.com/gmaruzz/sipnagios> <https://github.com/gmaruzz/sipnagios>> performance Nagios Patrol, on thanks for letting everyone here know about this tool! Do you know if other monitoring platforms (e.g., Zabbix) have the same plugin API and can be used with? Or it is for Nagios only? Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)   * https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>

Yep, I believe monitoring systems are in Nagios compatible family (most of them), or in Zabbix clan. From these pages:

From a quick check seems in Zabbix sipnagios would be an entity called "external check", and it seems Zabbix does not gather multiple performance data, just one value. But I will check it better. Btw, sipnagios can be used also as a standalone tool to originate a call and gather it's results, like sipsak for OPTIONS et al. -giovanni answered from mobile, please pardon terseness and typos, -giovanni On Wed, Apr 21, 2021, 15:04 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; wrote: > Personally I do not need such feature (e.g., Zabbix), I was more curious > if there is sort of common plugin API between some of the monitoring > systems (like seems to be now for web browsers) -- if I am not wrong, some > of these monitoring systems have common roots. > > Cheers, > Daniel > On 21.04.21 14:56, Giovanni Maruzzelli wrote: > > No idea about Zabbix api, at the moment, maybe is the same as the Nagios > one. > > If not, it will be easy to implement, just by changing exit status and > the way perf data are printed (if Zabbix supports perf data). > > I'll add this to the TODO. > > Thanks Daniel! > > -giovanni > > > answered from mobile, please pardon terseness and typos, > -giovanni > > On Wed, Apr 21, 2021, 14:51 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; > wrote: > >> Hello, >> >> On 21.04.21 11:42, Giovanni Maruzzelli wrote: >> > Hello fellow VoIPers and RTCers, >> > >> > on GitHub there is an early release of sipnagios, opensource. >> > >> > check it out: https://github.com/gmaruzz/sipnagios >> > <https://github.com/gmaruzz/sipnagios> >> > >> > sipnagios is a Nagios Plugin to check Call Quality in SIP VoIP >> > (compatible with checkmk, etc) >> > >> > sipnagios implements the Nagios plugin API for monitoring and >> > performance data.sipnagios.c is a modification of the original >> > siprtp.c sample in pjproject distribution. Supposedly, it works on >> > Linux, Windows, and anywhere you can compile pjproject on.It makes a >> > call, checks all the various resulting values (mos, rtt, pdd, tta, >> > jitter, packet loss, bytes and packets transferred, and so on). It >> > verifies these values are included into acceptable, warning, or >> > critical ranges.If the call has gone well, sipnagios print performance >> > data for Nagios graphs, and returns 0.If the call fails, or if its >> > measured values are not inside acceptable ranges, it exits with Nagios >> > conventional WARNING or CRITICAL values. >> > >> > mos calculation is scraped from Julien Chavanton work (VoIP Patrol, on >> > GitHub too) I can't even understand :) (merci Julien!) >> >> thanks for letting everyone here know about this tool! >> >> Do you know if other monitoring platforms (e.g., Zabbix) have the same >> plugin API and can be used with? Or it is for Nagios only? >> >> Cheers, >> Daniel >> >> -- >> Daniel-Constantin Mierla -- www.asipto.com >> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> Kamailio Advanced Training - Online >> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >> * https://www.asipto.com/sw/kamailio-advanced-training-online/ >> >> -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - Online > May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) > * https://www.asipto.com/sw/kamailio-advanced-training-online/ > >

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.

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.

Let's remember to keep each other posted if we improve this further.