AMR, OPUS and PLC

[mtryfoss]

First of tall. Thank you for great work!

Initially we've been using asterisk-opus for webrtc. We found that the client reports "Interarrival jitter" around ~6500. This seems to be solved by applying this patch https://gerrit.asterisk.org/#/c/3215/ when transcoding between OPUS and alaw.

However, when Asterisk is transcoding between AMR and OPUS I get these messages on the console during the call: [Oct 18 15:01:58] NOTICE[15180][C-0000000d]: translate.c:568 ast_translate: Late Frame; got Sequence Number 0 expected 16035 (amr@8000)->(slin@8000)->(slin@48000) [Oct 18 15:01:58] NOTICE[15180][C-0000000d]: translate.c:568 ast_translate: Late Frame; got Sequence Number 0 expected 16035 (amr@8000)->(slin@8000)->(slin@48000) [Oct 18 15:01:58] NOTICE[15180][C-0000000d]: translate.c:568 ast_translate: Late Frame; got Sequence Number 0 expected 16035 (amr@8000)->(slin@8000)->(slin@48000)

In this case, there is audio both ways.

---

If the B-side is completely silent after answer, these messages appear and now there's one way audio (I can hear webrtc-user but not the other way). [Oct 18 15:00:09] NOTICE[14618][C-0000000b]: translate.c:579 ast_translate: 10392 lost frame(s) 0/55142 (amr@8000)->(slin@8000)->(slin@48000) [Oct 18 15:00:09] NOTICE[14618][C-0000000b]: translate.c:568 ast_translate: Late Frame; got Sequence Number 55143 expected 1 (amr@8000)->(slin@8000)->(slin@48000) [Oct 18 15:00:09] NOTICE[14618][C-0000000b]: translate.c:568 ast_translate: Late Frame; got Sequence Number 55144 expected 1 (amr@8000)->(slin@8000)->(slin@48000) [Oct 18 15:00:10] NOTICE[14618][C-0000000b]: translate.c:568 ast_translate: Late Frame; got Sequence Number 55145 expected 1 (amr@8000)->(slin@8000)->(slin@48000)

Any ideas? :-)

[mtryfoss]

For the first scenario. If B puts the call on hold and then back again, the NOTICE stops and everything seems to work as it should.

[traud]

In your case, the RTP sequence number does not advance as expected. For issues regarding Native PLC and this patch, please, follow-up in ASTERISK-25629…

There, describe your setup in greater detail, for example whether you use chan_sip or res_pjsip as SIP channel driver. Which WebRTC client are you using? If possible capture the RTP packets via Wireshark and look into the sequence number. Anything special? And so on … Apple summarized the parts which constitutes a good issue report… If you cannot debug this yourself, I must be able to reproduce your scenario within minutes, thanks to a detailed step-by-step description.

client reports "Interarrival jitter", around ~6500

That is another issue and should be looked into separately. I would like to continue with that issue here in this issue report. Again, which client do you use (manufacturer, product, version)? With that patch, Native PLC is applied only on the receiving side of Asterisk. Therefore, I am confused why the warning changes. Is that related to RTCP? Does this happen just between AMR and Opus or even between AMR and G.711?

[mtryfoss]

I was a little bit unsure about bringing this case up on the ASTERISK issue since I'm using a heavily patched Asterisk (OPUS + AMR).

This is also reproducable with Bria as sip client with only OPUS enabled. Setup is like: Bria -> (OPUS) Asterisk -> (AMR-NB or AMR-WB) Ericsson MSC (SIP to ISUP)

When only G.711 alaw is enabled between Asterisk and the MSC, jitter is reported correctly by Bria - with or without the patch. No notice-messages at all.

Regarding the issue:

• There issue is only there when the MSC is involved. Transcoding the same between Bria (mobile with AMR-WB) and Bria (mac with OPUS) is working.
• I use the AMR patch with ".mode_change_capability = 2". See the other issue reported by me (#4).
• Seems to be an issue when transcoding AMR - OPUS and AMR-NB - AMR-WB combined with the patch.
• Without the Native PLC patch everything seems to work, but Bria reports high interarrival jitter.
• With the patch, the jitter seems to be reported correctly when there's audio. However, the notice-messages appear on the console and sometimes there's no audio at all.

SDP in 200 OK from MSC: a=rtpmap:109 AMR-WB/16000 a=fmtp:109 mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0

SDP in 200 OK from Bria: a=rtpmap:109 AMR-WB/16000 a=fmtp:109 octet-align=0

Could it be that the MSC is trying to save bandwidth and Asterisk not liking missing packets?

If you still want me to post it in ASTERISK-25629, let me know.

There's a possibility that I can provide you with a temp trunk allowing you to test directly against the MSC if you would like.

Also see the attached dump of SIP + RTP from the communication between Asterisk and the MSC. rtp.pcap.zip

[mtryfoss]

The dump is showing a call with one-way audio.

[mtryfoss]

Oh, and I'm using chan_sip :) Chrome/JSSIP for Webrtc, but as I mentioned earlier. The same applies to Bria.

[mtryfoss]

Reverted mode_change_capability = 2 to mode_change_capability = 0 in res/res_format_attr_amr.c and adjusted this parameter from 0 to 1 on the MSC route.

OCTALGN Coding of AMR payload type Parameter is used for indication whether the bandwidth efficient mode or octet aligned mode or both is used for sending SDP offer for the AMR and payload types. Default value zero is not printed.

Numeral 0 - 2

0 Bandwidth efficient mode is offered (default) 1 Octet aligned mode is offered 2 Both bandwidth efficient mode and octet aligned mode are offered

Now it seems to work both with and without the patch (and correct jitter reported). Seems to be an issue with bandwidth-efficient mode then?

[traud]

When it comes to the Native PLC patch, please, go for Asterisk-25629. Currently, I am assigned to that issue. Consequently, no problem by using ‘my’ transcoding modules. If you cannot debug that issue yourself, I recommend to report the issue but not continuing to use that patch. That patch is still experimental. Furthermore, it is not designed to address your initial issue.

Here (and before that), I would like to look into your original issue, that wrong Jitter report. I had that once, too. However, I was not able to reproduce it again, yet. When it comes to CounterPath Bria:

1. Which exact version do you use on which platform (like macOS 10.12, iOS 10.0, or Android 7.0)? Please, post that information even if your are on the ‘latest’.
2. Do you get any warning message while calling – or are you about the ‘Call Statistics’ in Bria?
3. If you are about the Call Statistics, are you about ’Data Received’ or ‘Data Sent’?
4. Which field in Call Statistics exactly: Lost, Discarded, or Jitter?
5. Are you using sRTP or normal RTP between Bria and Asterisk?

If you are about ‘Data Sent’, then you face an issue with RTCP. In that case, please, capture the network traffic via Wireshark and filter for rtcp. In case when nothing is displayed, you have to filter for udp and mark the right UDP stream to be decoded as RTCP.

[mtryfoss]

Actually, I was a little bit quick on the last post regarding octec-aligned mode. It doesn't work after all. I accidently enabled alaw.

I've removed the PLC patch for now while debugging this issue.

1. Mac OS X 10.10.5, Bria version 4.1.1 (74256)
2. No warnings. Call statistics look good, but I get this reported back to the Asterisk (rtcp debugging on) by a report issued by Bria:

Reception reports: 1 SSRC of sender: 2139166730 NTP timestamp: 1476865716.2649952256 RTP timestamp: 2723943345

SPC: 941 SOC: 111766 Fraction lost: 0 Packets lost so far: 0 Highest sequence number: 17853 Sequence number cycles: 0 Interarrival jitter: 6695 <------ This Last SR(our NTP): 44331.779895060580794368 DLSR: 8.7753 (sec) RTT: 0.1123(sec)

3 and 4. See attached screenshot. Looks normal?

5. Normal RTP.

[mtryfoss]

Tried updating Bria to 4.6.0. Stille the same at Asterisk-side, but not call statistics show this:

[mtryfoss]

I also notice a lot of these debug messages in asterisk while there's silence.

[Oct 19 10:51:49] DEBUG[16770][C-00000008] res_rtp_asterisk.c: Received frame with no data for RTP instance '0x7f993c013898' so dropping frame

These stop when there's sound coming from Bria. When i mute the microphone, they start again.

Interarrival jitter drops a lot when there's sound coming from the MSC (AMR).

[traud]

To analyze your issue, I have to reproduce this (as fast and easy as possible). Therefore, please, answer the following questions, if known. If the answer is too time consuming, just skip the question.

1. Are you able to determine which RTP instance is that: A) Bria ↔︎ Asterisk or B) Asterisk ↔︎ MSC?
2. Are you able to determine which RTP instance is that RTCP report about?
3. Was AMR-WB (16000) or AMR (8000) negotiated?
4. Which version of Asterisk are you using? Please, do not change, just mention it.
5. Which symptom(s) do you face beside this RTCP statistics and debug message? You might have mentioned that already – however, I got lost a bit because of that Native PLC patch. Therefore, reiterate all symptoms with this particular issue, please.

[mtryfoss]

1. option B. Seems like the packets Asterisk are asked to send to the MSC is empty.
2. option A. RTCP is disabled between Asterisk and the MSC because of some call-hold issues.
3. AMR 8000 in this case, but the problem still exists with AMR-WB.
4. Asterisk 13.8 with chan_sip. Some additional patches, but none should be related to RTP/RTCP.
5. I digged into this while investigating an issue with a small audio delay on our WebRTC client (thought it might mess up Chrome's jitterbuffer), but it turned out only alaw was involved in that case. AMR is still only in use on our testlab. Currently I haven't noticed any issues other than that high jitter is reported over RTCP.

I'm also attaching a pcap with RTP on both sides of Asterisk. 185.97.84.21 is the MSC 158.58.154.47 is the Asterisk 158.58.154.97 is the RTP proxy relaying RTP between Asterisk and Bria

I notice Asterisk is sending a lot of packets to Bria with nothing but "78" (packet length 55) as payload during silence periods. Bria only send 1 in the opposite direction for each silence period?

rtp4.pcap.zip

[traud]

Thank you for reporting. Yes, I was able to reproduce your issue here.

Steps to reproduce

1. Asterisk is between a callee and a caller, for SIP, SDP, and RTP.
2. Asterisk translates: Opus-Codec ↔︎ Signed Linear (slin) ↔︎ AMR
3. The caller negotiated Opus-Codec.
4. The callee negotiated AMR.
5. The caller sends not much voice like a closed microphone or silence.
6. On the command-line interface of Asterisk, issue sip show channelstats
7. On the command-line interface of Asterisk, issue core set debug 1

Workaround In the file res/res_format_attr_amr.c method amr_clone, change attr->vad = 1 to attr->vad = 0. That disables VAD (Voice Activation Detection). This is a temporary workaround until I understand the correct behavior and I fix this software bug.

Please, report whether this fixes your issue at least for AMR. Then, please, re-test AMR-WB. This workaround is just about AMR. You might have found two issues.

[mtryfoss]

Great you managed to reproduce!

Tried your workaround, but it didn't seem to help on the jitter. However, I notice one thing. When my mobile is just laying on the table and there's not much noice in the room, Asterisk sends "78" as payload. When I mute then microphone, it seems to start sending "f8fffe". Then the jitter level normalizes.

Regarding AMR-WB. Asterisk never seems to send those f8fffe-packets here.

[mtryfoss]

Good morning!

Strange I haven't noticed before, but after some time during the call there's some really bad noise in Bria's speaker device. Seems to go away when silence stops.

This apply to transcoding AMR-WB and OPUS only.

Let me know if you would like access to our environment. You could email or message me your ip-address.

[traud]

1. in res/res_format_attr_amr.c:amr_clone enable VAD
2. on the command-line interface (CLI) of Asterisk, issue core set debug 1

You identified a severe bug in my transcoding module. That bug was even worse when octet-aligned mode was negotiated, because Asterisk was sending NO_DATA frames then (your 78 payload). I was able to fix this. Now, Asterisk only sends SID or speech frames. Furthermore, there is no false debug message anymore. Please, checkout or download the latest version to test your scenarios.

on the command-line interface (CLI) of Asterisk, issue sip show channelstats

For an unknown reason, I am not able to reproduce that issue anymore. This is not related to the above fix. If you still experience that issue, please, list a step-by-step (see the example above) what you did when see that inter-arrival jitter.

[mtryfoss]

Do you mean to enable VAD for AMR-WB as well as AMR-NB?

[traud]

This issue report was about AMR-NB.

For AMR-NB, VAD is enabled on default and should work now. If you like, you can play around with VAD in AMR-WB as well. However, then, you have to change the state of VAD in res/res_format_attr_amr.c:amr_clone. VAD in AMR-WB should work as I tested that scenario as well.

Please note: This issue report here is about DTX from Asterisk to your SIP user agent. That other issue report is about the opposite direction. However, this issue report here is still about the original symptom as well – that displayed ‘inter-arrival jitter’. Now that this debug message is solved and Asterisk is sending the RTP packets correctly, I would like you to double check this. When this is solved in your scenario as well, I would like to look into that ‘inter-arrival jitter’ again.

[mtryfoss]

The jitter issue seems to have been fixed in this case. Thanks!

Actually, the other issue is also about transcoding AMR to G.722/G.711. At least in my case.

[traud]

The jitter issue seems to have been fixed in this case.

OK. If you face that issue again, please, re-open this issue report (or create a new one).

the other issue is also about transcoding [from] AMR to G.722/G.711

Yes, and this issue here was about transcoding to AMR. In case of VAD, OpenCORE returns NO_DATA frames. Before this change, Asterisk sent NO_DATA to the remote party (in octet-aligned mode) or discarded such frames in a upper layer of Asterisk (in bandwidth-efficient mode) resulting in that debug message. Now, NO_DATA is discarded within the transcoding module already.

2 – both bandwidth efficient mode and octet aligned mode are offered

Perhaps on day when you have upgraded at least to Asterisk 13.12, you can do me a favor and test that mode. I wonder whether the correct RTP payload type gets negotiated via SDP, then.