although those support both modes, only the bandwidth-efficient mode is offered when they call the Asterisk server. Furthermore, they do not re-negotiate when octet-align=1 is answered in that session. Therefore, those drop to the next preferred audio-codec. Consequently, those VoIP clients are not able to leverage this module on calls started from these clients. Workaround: Implement Opus, GSM-EFR, or G.722.
CSipSimple
is based on PJSIP and ignoresoctet-align=1 on incoming AMR-WB calls; AMR works. Therefore, ingress AMR-WB creates distorted audio until that patch makes it into CSipSimple. Workaround: Wait until CSipSimple includes that patch/version.
CounterPath Bria 3.4
Since that version, the format AMR-WB does not answer with a fmtp line anymore. Therefore, Asterisk changes to the next audio-codec, which creates non-audio situations. Workaround: In Asterisk, always prefer Opus over AMR-WB on outgoing calls. How?
Nokia Symbian/S60
Nokia Series 40
although those support both modes, they offer only one mode. Furthermore, the user has to change to the octet-aligned mode manually. If the server answers with octet-align=1 although the phone expects bandwidth-efficient mode in that session (because the user did not change manually), AMR is chosen but the call is dropped because the frame data is in unexpected mode. Workaround: Ignore the format AMR when bandwidth-efficient mode is requested. How?
although those support both modes, only the bandwidth-efficient mode is offered when they call the Asterisk server. Furthermore, they do not re-negotiate when
octet-align=1is answered in that session. Therefore, those drop to the next preferred audio-codec. Consequently, those VoIP clients are not able to leverage this module on calls started from these clients. Workaround: Implement Opus, GSM-EFR, or G.722.is based on PJSIP and ignores
octet-align=1on incoming AMR-WB calls; AMR works. Therefore, ingress AMR-WB creates distorted audio until that patch makes it into CSipSimple. Workaround: Wait until CSipSimple includes that patch/version.Since that version, the format AMR-WB does not answer with a
fmtpline anymore. Therefore, Asterisk changes to the next audio-codec, which creates non-audio situations. Workaround: In Asterisk, always prefer Opus over AMR-WB on outgoing calls. How?although those support both modes, they offer only one mode. Furthermore, the user has to change to the octet-aligned mode manually. If the server answers with
octet-align=1although the phone expects bandwidth-efficient mode in that session (because the user did not change manually), AMR is chosen but the call is dropped because the frame data is in unexpected mode. Workaround: Ignore the format AMR when bandwidth-efficient mode is requested. How?