Octet-Align mode issues

[access2praveen]

Asterisk is playing bad audio , when octet-align is enabled in the source code (res_format_amr.c file)

[traud]

Puh. Both modes are tested by me regularly, because I have devices which offer/use only the octet-aligned mode. Therefore, to reproduce your issue, I need more information:

1. Which branch/version of Asterisk are you using (13, 15, or Master)?
2. Which AMR implementation are you testing against (manufacturer, product name, version)?
3. AMR, AMR-WB, or both?
4. Which direction from Asterisk (incoming or originating call)?

In the command-line interface (CLI) of Asterisk, you are able to sip set debug on. Do you see anything suspicious like the remote party is not advertising mode=1in the SDP (fmtp)? Please note, even if you change that parameter, Asterisk still negotiates that parameter. That parameter (at the top of the mentioned C file) is just the default value for calls originating from your Asterisk. If the remote party does not advertise correctly, we have to force mode=1. Anyway, before I give a guide for that, please, answer the questions above.

[access2praveen]

Hi Alex

Thank you very much for getting back to me , Sorry for the delay in my response

Here are the details of my setup

I am using asterisk 13.11.0

I am using MicroSIP endpoint which is trying to reach the media server via Asterisk

MicroSIP initiates the call with G.711 Call, I have configured asterisk to transcode G.711 to AMRWB ( so In this case asterisk is originating the call)

Issue is reproducible with both AMR/AMR-WB But ONLY in Octet-align mode (works fine in bandwidth efficient mode)

I dont see distorted audio issue , When I directly connect MicroSIP to Media Server (removing asterisk in the path) ,

Below is the SDP that asterisk is sending towards media server

v=0 o=root 1550976657 1550976657 IN IP4 10.204.66.30 s=Asterisk PBX 13.11.0 c=IN IP4 10.204.66.30 t=0 0 m=audio 15734 RTP/AVP 108 101 a=rtpmap:108 AMR-WB/16000 a=fmtp:108 octet-align=1;mode-change-capability=1;mode-change-period=1;mode-change-neighbor=1;max-red=220 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=maxptime:20 a=sendrecv

Below is the Response-SDP from Media Server

v=0 o=- 1532020549 1532020549 IN IP4 10.204.66.84 s=media server session c=IN IP4 10.204.66.84 t=0 0 m=audio 40000 RTP/AVP 108 101 a=rtpmap:108 AMR-WB/16000 a=fmtp:108 mode-change-period=1; mode-change-capability=2; mode-change-neighbor=0; max-red=0; octet-align=1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

Thanks in Advance for your support

Regards Praveen

On Fri, Jul 13, 2018 at 4:10 AM Alexander Traud notifications@github.com wrote:

Puh. Both modes are tested by me regularly, because I have devices which offer/use only the octet-aligned mode. Therefore, to reproduce your issue, I need more information:

• Which branch/version of Asterisk are you using (13, 15, or Master)?
• Which AMR implementation are you testing against (manufacturer, product name, version)?
• AMR, AMR-WB, or both?
• Which direction from Asterisk (incoming or originating call)?

In the command-line interface (CLI) of Asterisk, you are able to sip set debug on. Do you see anything suspicious like the remote party is not advertising mode=1in the SDP (fmtp)? Please note, even if you change that parameter, Asterisk still negotiates that parameter. That parameter (at the top of the mentioned C file) is just the default value for calls originating from your Asterisk. If the remote party does not advertise correctly, we have to force mode=1. Anyway, before I give a guide for that, please, answer the questions above.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/traud/asterisk-amr/issues/15#issuecomment-404601456, or mute the thread https://github.com/notifications/unsubscribe-auth/AWW4kodOpXxu4WIrEvocrrh6bpTmbdRvks5uF5EPgaJpZM4VMEQL .

[traud]

OK. With that new information, two more questions:

1. On default my module uses bandwidth-efficient mode. How did you change / which part of the module did you change to switch to octet-aligned mode?
2. Is there a reason not to use the latest Asterisk release (currently: 13.22)?

[access2praveen]

I have just changed the below file in the source code and recompiled asterisk

/usr/local/src/asterisk-13.11.0/res/res_format_attr_amr.c

static struct amr_attr default_amr_attr = { .octet_align = 1, / bandwidth efficient / .mode_set = 0, / all modes / .mode_change_period = 1, / not specified / .mode_change_capability = 1, / not supported / .mode_change_neighbor = 1, / change to any / .crc = 1, / off / .robust_sorting = 0, / off / .interleaving = 0, / off / .max_red = 220, / no redundancy limit / };

Asterisk 13.11.0 was the latest one when i installed the asterisk, I can update to 13.22, Do you reckon to update asterisk to 13.22 or 15.X ?

Does this patch work on both asterisk 13.X and 15.X ?

Thanks Praveen

On Fri, Jul 20, 2018 at 1:11 AM Alexander Traud notifications@github.com wrote:

OK. With that new information, two more questions:

1. On default my module uses bandwidth-efficient mode. How did you change / which part of the module did you change to switch to octet-aligned mode?
2. Is there a reason not to use the latest Asterisk release http://www.asterisk.org/downloads/asterisk/all-asterisk-versions (currently: 13.22)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/traud/asterisk-amr/issues/15#issuecomment-406311287, or mute the thread https://github.com/notifications/unsubscribe-auth/AWW4khw6rCvl0AjHFf8m800qlP5C8gRnks5uIKGOgaJpZM4VMEQL .

[traud]

I am mentioning the Asterisk version just because I have to reproduce your issue. Therefore, I am trying to replicate an environment as exact as yours. However, because SIP servers face a lot of attacks, one should go for the latest security patches – and that is the latest version of Asterisk. My patch should work with your version. Anyway, it should work with the latest version of Asterisk 13 and Asterisk 15 as well. Personally, I use long-term-support versions, so Asterisk 13 is the best tested environment.

Anyway, back to the issue in this thread:

1. You changed quite a lot of parameters. Some were never tested with the value you are using. Why do you change so many? Or in other words: Is it possible just to change octet-align and leave all other parameters as is?
2. Are you sure your ‘media server’ supports octet-aligned mode at all?
3. Why do you want to go for that mode at all?

[bfoot2018]

Hi all,

I apologize for the invasion. Maybe my case is similar to your one. If not let me know to add as separate issue.

asterisk -V

Asterisk 13.22.0

I'm trying to make call to asterisk to check call recording support of AMR/AMR-WB enabled calls. During recording can find the following suspicious messages:

<-------------> -- Executing [222@public:3] Record("SIP/6002-00000013", "asterisk-recording%d:wav,0,100,q") in new stack [Aug 3 11:32:17] WARNING[2957][C-00000014]: codec_amr.c:236 amrtolin_framein: multiple frames per packet were not tested

0x7f40dc00c930 -- Strict RTP learning complete - Locking on source address 192.168.5.33:4004

<--- SIP read from UDP:192.168.5.33:59910 ---> BYE sip:222@192.168.0.10:5060 SIP/2.0

Pl find in the attached pcap in zip and the example of recorded audio. In pcap 192.168.0.10 - asterisk, 192.168.5.33 - SIP client https://www.microsip.org/ based on popular SIP/Media stacks.

asterisk-recording1.zip asterisk_13_amr_recording_test.zip

[traud]

@bfoot2018 although your symptom is similar, the cause is different. Therefore, please create a new issue for this. MicroSIP is sending 40ms per RTP packet = two AMR-WB frames. This was not tested, yet. Which version of MicroSIP did you use?

In case of access2praveen, MicroSIP is using G.711 between it and Asterisk. I am closing the issue of access2praveen, because I cannot reproduce, yet. access2praveen, when you have more information, please, re-open this issue, so this issue can be solved for everyone.