[asterisk-dev] Support for amr codec?

[Michael Maier]

On 20.08.20 at 15:12 Alexander Traud wrote:
> Software bugs love to be talked about. That helps them to hide. Bugs hate to be tracked down. That might kill them.
> 
>> comfort noise, which is not supported by Asterisk
> 
> In case of AMR(-WB), Comfort Noise (CN) is part of the decoder itself already. Consequently, no additional support in Asterisk is required. My patch can be changed to enable Voice Activity Detection (VAD) in the encoder. Then, the patch does Discontinuous Transmission (DTX) automatically: /res/res_format_attr_amr.c:amr_clone set attr->vad = 1.
> Although optional, VAD/DTX/CN are tested scenarios since Nov. 2016.
> 
>> Samsung S20
> 
> Puh. Are you using my patch? There is a software bug in Comfort Noise, when you use an *old* version of the OpenCORE-AMR library [1]. Only AMR-WB. Only decoding. This gets solved by patching your library or by using version 0.1.5 of OpenCORE-AMR. That version is included in Ubuntu 20.04 LTS already. For Debian, you have to go wait for Debian 11 (Bullseye).
> 
> If you use my patch, the latest library, and still face any issue with Comfort Noise, please, please, please, create an issue report on my GitHub (or talk to me privately). For example, which firmware variant you use on your Samsung S20. Software bugs hate to be tracked down and I hate software bugs.

After reviewing the sip (only!) traces, I found an inbound call, which was answered by my wife. The caller was on Vodafone IMS and we are on Deutsche Telekom / landline (SVDSL). The
call leg from Telekom to asterisk was AMR-WB and from asterisk to C610IP (Gigaset) was G722 (-> transcoding).
I asked her, if she noticed anything during this 45 min call. She stated, that this call would have been brilliant regarding call quality - especially taking into account, that it's
been a mobile call :-). She didn't realize any distortions. (There have been no codec changes during the call.)

Just to say, that things seem to work pretty good! There is a high WAF :-)


One more thing: There was an interesting codec negotiation at the startup of the call.
At the moment, I adjusted G722/G711/AMR-WB/AMR (which was the answer in 200 OK to Telekom and which would have meant G722).
Promptly I got a reInvite to use AMR-WB (which was acked by asterisk).

The Invite from Telekom was:
AMR-WB/16000 fmtp:96 mode-set=0,1,2; mode-change-period=2; mode-change-neighbor=1; max-red=0
AMR-WB/16000 fmtp:97 mode-change-capability=2; max-red=0
G722
G711

The acked codec after reInvite:
AMR-WB/16000 fmtp:96 mode-set=0,1,2;mode-change-period=2;mode-change-neighbor=1;max-red=0

Well, I'm thinking about reordering codecs to AMR-WB,AMR,G722,G711 ... .


BTW: this call (as each call here) was encrypted using the mediasec patch.


Thanks
Michael