Hi Richard, On Tue, Feb 13, 2018 at 06:34:53PM -0500, Richard Fuchs wrote: When you say "between", do you mean the average of the values of the two respective legs? Thank you, I will investigate further. I had a preliminary look at the netstring just by sniffing the control protocol traffic, and saw that the stats were indeed being separated into the respective "inbound" and "outbound" classifications. But for some reason that was not percolating back into Kamailio PVs. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

On Tue, Feb 13, 2018 at 07:34:30PM -0500, Richard Fuchs wrote: Ach so! Jetzt alles ist klar! -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

Ah, okay, coercing it to use Convert::Bencode (for lack of CentOS rh524-perl Bencode module) was not a productive thing to do. :-) On Tue, Feb 13, 2018 at 09:29:49PM -0500, Alex Balashov wrote: -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

All right, I think what I have learned is that the stats simply aren't being collected for the SSRC in the endpoint that corresponds to my "inb" (inbound) label — just the "outb" (outbound): Here's the complete dump. Note in the MOS stats that the stats for this SSRC are empty: 222410830 => {} I did note that there are two SSRCs for the more viable outbound stream, one being RTP and the other being RTCP. The other direction also has an RTP and an RTCP stream, but an SSRC only for one of them. See below: -----8<-----8<-----8<-----8<-----8<----- { created => '1518590122', 'last signal' => '1518590124', tags => { sansay1987983383rdb28749 => { label => 'inb', medias => [ { type => 'audio', protocol => 'RTP/AVP', index => '1', flags => [ 'initialized', 'send', 'recv' ], streams => [ { stats => { packets => '1581', bytes => '271932', errors => '0' }, endpoint => { address => '<ITSP>', family => 'IPv4', port => '38930' }, 'advertised endpoint' => { address => '<ITSP>', port => '38930', family => 'IPv4' }, 'last packet' => '1518590156', 'local port' => '9078', flags => [ 'RTP', 'filled', 'confirmed', 'kernelized' ], SSRC => '222410830' }, { stats => { errors => '0', bytes => '0', packets => '0' }, 'advertised endpoint' => { family => 'IPv4', port => '38931', address => '<ITSP>' }, endpoint => { family => 'IPv4', port => '38931', address => '<ITSP>' }, 'last packet' => '1518590122', 'local port' => '9079', flags => [ 'RTCP', 'filled' ] } ] } ], created => '1518590122', tag => 'sansay1987983383rdb28749', 'in dialogue with' => '9C62E1A4-89AFCE63' }, '9C62E1A4-89AFCE63' => { 'in dialogue with' => 'sansay1987983383rdb28749', tag => '9C62E1A4-89AFCE63', created => '1518590122', medias => [ { protocol => 'RTP/AVP', type => 'audio', streams => [ { SSRC => '4088772468', flags => [ 'RTP', 'filled', 'confirmed', 'kernelized' ], 'local port' => '9088', 'last packet' => '1518590156', endpoint => { family => 'IPv4', port => '2250', address => '<home IP phone>' }, 'advertised endpoint' => { address => '172.30.105.251', family => 'IPv4', port => '2250' }, stats => { errors => '0', bytes => '270212', packets => '1571' } }, { SSRC => '4088772468', 'last packet' => '1518590152', 'local port' => '9089', flags => [ 'RTCP', 'filled', 'confirmed' ], endpoint => { family => 'IPv4', port => '2251', address => '<home IP phone>' }, 'advertised endpoint' => { port => '2251', family => 'IPv4', address => '172.30.105.251' }, stats => { errors => '0', bytes => '504', packets => '6' } } ], index => '1', flags => [ 'initialized', 'send', 'recv' ] } ], label => 'outb' } }, created_us => '624757', result => 'ok', SSRC => { '4088772468' => { 'highest MOS' => { 'packet loss' => '0', 'round-trip time' => '0', jitter => '2', 'reported at' => '1518590127', MOS => '44' }, 'lowest MOS' => { 'packet loss' => '0', 'round-trip time' => '0', 'reported at' => '1518590127', jitter => '2', MOS => '44' }, 'average MOS' => { MOS => '44', jitter => '2', samples => '6', 'round-trip time' => '0', 'packet loss' => '0' }, 'MOS progression' => { interval => '2', entries => [ { 'round-trip time' => '0', 'packet loss' => '0', 'reported at' => '1518590127', MOS => '44', jitter => '2' }, { 'packet loss' => '0', 'round-trip time' => '0', 'reported at' => '1518590132', MOS => '44', jitter => '3' }, { jitter => '0', 'reported at' => '1518590137', MOS => '44', 'round-trip time' => '0', 'packet loss' => '0' }, { 'reported at' => '1518590142', MOS => '44', jitter => '2', 'packet loss' => '0', 'round-trip time' => '0' }, { 'round-trip time' => '0', 'packet loss' => '0', 'reported at' => '1518590147', MOS => '44', jitter => '4' }, { 'round-trip time' => '0', 'packet loss' => '0', 'reported at' => '1518590152', jitter => '3', MOS => '44' } ] } }, 222410830 => {} }, totals => { RTCP => { errors => '0', bytes => '504', packets => '6' }, RTP => { errors => '0', bytes => '542144', packets => '3152' } } } ----->8----->8----->8----->8----->8----- -- Alex On Wed, Feb 14, 2018 at 12:15:29AM -0500, Alex Balashov wrote: -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

On 2018-02-14 02:44 AM, Alex Balashov wrote: It does gather some stats about the media streams on its own (even more so with the extended transcoding capabilities now), but at least one component of the MOS calculation (latency) depends on RTCP being provided by the RTP clients, so without that, no MOS score can be produced. Cheers

On 2018-02-14 12:21 PM, Alex Balashov wrote: It keeps track of packet and octet counts. With transcoding engaged for a call, it also keeps track of packet loss and duplications. It could calculate jitter, but doesn't currently do so. Not currently, but we may offer that capability in the future, especially to support video in an RTP/AVP to (S)AVFP bridging scenario. Cheers

On 2018-02-14 12:51 PM, Alex Balashov wrote: Correct, these are all currently extracted from RTCP only. Both are needed. Without transcoding engaged for a call, rtpengine ignores most aspects of RTP, including sequence numbers and timestamps, which would be needed for stats keeping. Cheerse