[Home]

Summary:ASTERISK-26703: PJSIP Opus jitter rating incorrect over AMI RTCP events
Reporter:Luke Escude (lukeescude)Labels:
Date Opened:2017-01-07 11:25:13.000-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Codecs/codec_opus Core/ManagerInterface
Versions:13.13.1 Frequency of
Occurrence
Related
Issues:
Environment:Centos x64Attachments:
Description:In the following console readout, x101 is a device using Opus. You can see that asterisk is correctly measuring jitter (the audio quality was flawless, so jitter is close to 0).

{noformat}
testbed3*CLI> pjsip show channelstats

         100-00000001       00:20:20 ulaw    61001       2    0   0.000  61000       0    0   0.005 999.999
         101-00000003       00:01:20 ulaw      932       0    0   0.000   3890       0    0   0.003 999.999

testbed3*CLI> pjsip show channelstats

         100-00000001       00:20:20 ulaw    61034       2    0   0.000  61033       0    0   0.006 999.999
         101-00000003       00:01:20 ulaw      965       0    0   0.000   3923       0    0   0.003 999.999

testbed3*CLI> pjsip show channelstats

         100-00000001       00:20:21 ulaw    61075       2    0   0.000  61074       0    0   0.007 999.999
         101-00000003       00:01:21 ulaw     1007       1    0   0.000   3965       0    0   0.006 999.999

testbed3*CLI> pjsip show channelstats

         100-00000001       00:20:22 ulaw    61105       2    0   0.000  61104       0    0   0.004 999.999
         101-00000003       00:01:22 ulaw     1036       1    0   0.000   3994       0    0   0.004 999.999

testbed3*CLI> pjsip show channelstats

         100-00000001       00:20:22 ulaw    61138       2    0   0.000  61137       0    0   0.005 999.999
         101-00000003       00:01:22 ulaw     1069       1    0   0.000   4027       0    0   0.005 999.999
{noformat}

However, the AMI is receiving values that are insanely off:

{noformat}
253.0
172.0
237.0
etc.
{noformat}

All other codecs are correctly coming across the AMI.
Comments:By: Asterisk Team (asteriskteam) 2017-01-07 11:25:14.044-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rusty Newton (rnewton) 2017-01-12 09:44:21.772-0600

Luke, how are you receiving the values via AMI?

Can you give an example of the AMI actions and events that you receive or show us the debug?

Thanks!
By: Rusty Newton (rnewton) 2017-01-12 19:14:03.067-0600

[~kharwell] was able to reproduce this here, so no need for the additional debug.
By: Luke Escude (lukeescude) 2017-01-12 19:18:01.915-0600

Awesome - Quick question, the RTT in the jitterstats show 999.999... How does one go about populating that value?
By: Richard Mudgett (rmudgett) 2017-01-13 11:22:40.416-0600

I think this is a duplicate of ASTERISK-26710 which was just committed last night.
By: Kevin Harwell (kharwell) 2017-01-13 13:21:38.550-0600

I tested it again with the fix from ASTERISK-26710 and the problem still occurs (assuming the mismatched numbers reported are coming from the RTCPReceived ami event).
By: Sean Bright (seanbright) 2021-10-30 12:20:59.666-0500

I am pretty sure this is just math. {{Report0IAJitter}} is timestamp units which is a function of sample rate and because Opus has a sample rate of 48khz, you're going to have an IAJitter that is 6x higher than it would be for something like ulaw that has a sample rate of 8khz.