Section Peer with allow=!all,amr creates an Encoder with Format (nil)

[mtryfoss]

Hello!

This is related to issue #7

Please listen to this recording done on the Asterisk transcoding AMR-WB to G.722. The same applies when transcoding to G.711 too. Seems like the destination codec is irrelevant since the noise exists when recording the caller-side in Asterisk.

In the wav file, the noise starts around 0:26 into the call. It stops, and then starts about 30 seconds after that again. Seems to happen when there's silence in the room I'm sitting in.

Attaching both recording and pcap. Source ip 185.97.84.21.
pcap-and-recording.zip

Please let me know if you need anything more.

[mtryfoss]

Actually, the clicking noise seems to be there at all times. It's just not very loud. Trying to debug a little bit more myself.

[traud]

Please, go through this guide how to write a qualified bug report. I do not know which VoIP/SIP client is involved. I do not know its release version. I do not know its settings regarding VAD/DTX/CN. Furthermore, I do not know what was negotiated on the SDP layer. If available by your VoIP/SIP client, I recommend to force the octet-aligned mode, because then Wireshark is able to help you decoding the AMR packets.

Every 20ms, a data packet should arrive. 185.97.84.21 is not your Asterisk server, I guess(!). Looking at the PCAP, the client is sending much less packets (around factor 8 = 160ms). Furthermore, your client is sending SID packets (CMR = 2, F = 0, FT = 9). Both scenarios were not tested by me, because I was not able to create such a scenario.

Please, double-check whether amrtolin_framein is creating the right amount of samples in your case. It should be 8 times more than usual, because not 20ms but 160ms (not 320 samples but 2560 samples) were covered by those SID data packets. Furthermore, I am not sure why 185.97.84.21 sends AMR-WB mode 2 and Asterisk (158.58.154.47) sends AMR-WB mode 0. Asterisk should follow the remote request and switch over to mode 2 as well. Please double-check/debug this and report (beside the information, which AMR-WB sender you are using in this case; i.e. CounterPath Bria supports AMR-WB as well).

[mtryfoss]

Thanks for your reply.
I'm still trying to debug this myself. Thanks for the input on what to check.

158.97.84.21 is our Ericsson MSC.

You're right. It's those SID packets creating this noise.
A simple if(type == 9) return 0; in amrtolin_framein removed the clicking noise, but then there's no RTP sent to the other side.

I wonder what's the best approach for this? Start some kind of CNG, send empty frames..?

Regarding the different modes. I will do some more testing here and let you know.

[traud]

What's the best approach for this?

First, we have to understand what D_IF_decode does in case of SID. Did you look into the source code of OpenCore AMR already?

Regarding the different modes. I will do some more testing here and let you know.

Who started that call: Ericsson MSC or Asterisk? Please, put a debug statement into lintoamr_frameout and double-check whether attr is NULL. If that is NULL, you found a bug. Is that still Asterisk 13.8 with chan_sip?

[mtryfoss]

I've not looked into the source code of OpenCore AMR yet.

Asterisk started the call. It's still Asterisk 13.8 and chan_sip.
I've already debugged that attr is null in that case.

Tried putting these lines in the end of amr_getjoint:
ast_format_set_attribute_data(format1, attr_res);
ast_format_set_attribute_data(format2 attr_res);

It gives a compiler warning (warning: passing argument 1 of ‘ast_format_set_attribute_data’ discards qualifiers from pointer target type), but still works. I don't know if that would break anything else.

[mtryfoss]

I've looked a bit at pjsip's implementation of this.

Check out https://github.com/chebur/pjsip/blob/27dc7a969434c80c95a5c86fb3a36d07bce4df74/build/pjproject/src/pjmedia/include/pjmedia-codec/amr_helper.h

They have a predecode function which handles the SID frame specially on line 812:
} else if (in_info->frame_type == SID_FT) {

This function is called before D_IF_decode.

    input_.buf = &bitstream[1];
    /* AMR max frame size */
    input_.size = (amr_data->dec_setting.amr_nb? 31: 60);
    pjmedia_codec_amr_predecode(input, &amr_data->dec_setting, &input_);
    info = (pjmedia_codec_amr_bit_info*)&input_.bit_info;

    /* VA AMR decoder requires frame info in the first byte. */
    bitstream[0] = (info->frame_type << 3) | (info->good_quality << 2);
    TRACE_((THIS_FILE, "AMR decode(): mode=%d, ft=%d, size=%d",
        info->mode, info->frame_type, input_.size));

    /* Decode */
    if (amr_data->dec_setting.amr_nb) {
#ifdef USE_AMRNB
        Decoder_Interface_Decode(amr_data->decoder, bitstream,
                                 (pj_int16_t*)output->buf, 0);
#endif
    } else {
#ifdef USE_AMRWB
        D_IF_decode(amr_data->decoder, bitstream,
                    (pj_int16_t*)output->buf, 0);
#endif
    }

[traud]

I've not looked into the source code of OpenCore AMR.

Please, do so. That is the first step to add SID handling (does it create silence, in-media comfort noise, how many samples). Because that feature does not tackle my scenarios, you have to drive that issue. If you have any questions, please, say so. The code and a mailing list can be found on SourceForge…

PJSIP

There were so many bugs in PJSIP, I had to fix before I could use AMR-WB. That indicated that AMR-WB was not used for years – if ever. Therefore, I would rather start with D_IF_decode and how/whether that handles SID.

I do not know if that would break anything else.

You should not change an existing format because you never know where that format is used or even re-used (for example on a subsequent different channel). For AMR, this format is used to communicate the CMR between the two call legs (incoming and outgoing RTP traffic). Now, you have to debug why amr_getjoint is called with a format which was
A) not a cached format but
B) created before the attribute module was loaded (and therefore has no attribute data).

If you documented your setup, I could try to reproduce your issue and help you in that regard. For example, how is your Ericsson MSC connected: UDP, TCP, TLS, or WebSocket.
A) Is Asterisk registered at that Ericsson MSC (SIP-REGISTER and SIP-INVITE)? Or
B) Is that Ericsson MSC just an outbound proxy (just SIP-INVITE)? Or
C) Is that Ericsson MSC used as VoIP/SIP client and registered at your Asterisk?

[mtryfoss]

I'll try to dig a little more.

The setup is like this (all UDP):
Cisco SPA504 (any phone would probably do) <- (G.722) -> Asterisk 13.8 <- (AMR-WB) -> Kamailio in front of the two MSC's.
No registrations. Only a defined peer in Asterisk against Kamailio's IP, which routes the call to the MSC's.

If you would like access, I could whitelist the IP of your Asterisk on the Kamailio. The debugging is then straight forward. Just start a call and stay silent :)

[mtryfoss]

One thing I notice in Wireshark. Every AMR packet coming from the MSC has CMR field set to 2, even though I'm now (for debugging purposes) forcing mode 2 that direction. I also have confirmed that in Wireshark.

Is this normal?

[mtryfoss]

Just updating this ticket with things I find.

I've debugged opencore decoder and I see that all SID frames are being decoded as SID_FIRST, instead of SID_FIRST and subsequent SID_UPDATE. I notice in Wireshark that the SID packets are different:

Payload in first SID packet:
20 4C 00 00 00 00 02
Payload in second, third (etc) SID packet:
20 4C E3 DF 3D E0 12

Could there be some bug in opencore-amr related to this?

[mtryfoss]

Here's the logic for decoding (mime_io.cpp):

        case MRSID:

            if (quality)
            {
                if (temp & 0x80)
                {
                    *frame_type = RX_SID_UPDATE;
                }
                else
                {
                    *frame_type = RX_SID_FIRST;
                }
            }

[mtryfoss]

The generation of comfort noise seems to stop way too early, and this is causing the clicking (generator stops between each SID).

Earlier you mention that a packet should arrive every 20 ms. Do this apply to SID packets as well? Isn't the whole point to save bandwidth? When there's voice activity the rate speeds up.

[traud]

packets should arrive every 20 ms

Here in this repository, my module expects a frame every 20 ms. Consequently, VAD/DTX/CN and SID packets are not handled correctly. Or stated differently: In amrtolin_framein, the variable frame_size is 320 samples for AMR-WB and 160 samples for AMR always. Consequently, pvt->samples and pvt->datalen get just 20 ms even in case of SID. This is incorrect because you saw 160 ms on the wire. You found a bug for sure. SID handling is missing. However, the follow-up questions are: Does OpenCore AMR handle SID? How? Or stated differently: What/how much does D_IF_decode write to pvt->outbuf.i16 in case of a SID packet?

all SID frames are being decoded as SID_FIRST, instead of SID_FIRST and subsequent SID_UPDATE

In mime_io.cpp, do you know how that variable temp is derived? If I read TS 26.201 sub-clause 4.2.3 correctly, that should be the STI. Is there a bug in the library itself? Or perhaps am I calling the API incorrectly: Do I have to fill seven NO_DATA frames for the remaining 160 ms - 20 ms. Or should I use that parameter bfi of D_IF_decode?

I could whitelist the IP of your Asterisk on the Kamailio. The debugging is then straight forward.

I do not have a static IP. Anyway, I have found an AMR implementation, which does VAD and I am able to reproduce that SID issue. You are ahead of me right now. And this is not a use-case in my scenario. Therefore, I would be more than happy if you could debug this. At least, I am able to double-check your findings at the end.

Every AMR packet coming from the MSC has CMR field set to 2, even though I'm now (for debugging purposes) forcing mode 2 that direction. I also have confirmed that in Wireshark. Is this normal?

Yes, that is normal. My module sends a ‘do not change’. Some implementations repeat the the current state all the time. You could do the same by replacing the two occurrences of 15 << 4 with attr->mode_current << 4 in codecs/codec_amr.c.

I've already debugged that attr is null in that case.

I am not able to reproduce this issue, yet. That is a separate one. Please create a new issue for that, copying over all bits required to reproduce that. Before you go for that, are you able to update to Asterisk 13.10? That is the version, I am using right now. Or are you on the ‘certified’ branch and therefore using Asterisk 13.8?

[mtryfoss]

Thanks for the reply. I'm only answering what I've been able to check right now.

Here in this repository, my module expects a frame every 20 ms. Consequently, VAD/DTX/CN and SID packets are not handled correctly. Or stated differently: In amrtolin_framein, the variable frame_size is 320 samples for AMR-WB and 160 samples for AMR always. Consequently, pvt->samples and pvt->datalen get just 20 ms even in case of SID. This is incorrect because you saw 160 ms on the wire. You found a bug for sure. SID handling is missing. However, the follow-up questions are: Does OpenCore AMR handle SID? How? Or stated differently: What/how much does D_IF_decode write to pvt->outbuf.i16 in case of a SID packet?

The same size as the in variable seems to be written to pvt->outbuf.i16 (8 bytes). Based on what I find on the net, it may seem like the SID frames are only meant to keep a timer based comfort noise generator going - not to be decoded. The payload shall contain characteristics of the background noise which is going to be generated. Correct me if I'm wrong.