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-0600 | Date Closed: | |
Priority: | Minor | Regression? | |
Status: | Open/New | Components: | Codecs/codec_opus Core/ManagerInterface |
Versions: | 13.13.1 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Centos x64 | Attachments: | |
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. |