: RTPEngine v14 not preserving AMR/AMR-WB octet-aligned variants in answer SDP

[Avremy Cohen]

Environment:

• RTPEngine version: 14.0.1.1-1~bpo12+1
• Previous working version: 9.5
• OS: Debian 12 (bookworm)

After upgrading from RTPEngine v9.5 to v14, I am unable to transcode AMR, AMR-WB and the octet-aligned variants of AMR and AMR-WB .

Incoming INVITE SDP from IMS (all variants present):

m=audio 1316 RTP/AVP 112 116 107 118 96 111 110 a=rtpmap:112 EVS/16000 a=fmtp:112 br=5.9-24.4;bw=nb-swb;ch-aw-recv=-1 a=rtpmap:116 AMR-WB/16000/1 a=fmtp:116 mode-change-capability=2;max-red=220 a=rtpmap:107 AMR-WB/16000/1 a=fmtp:107 octet-align=1;mode-change-capability=2;max-red=220 a=rtpmap:118 AMR/8000/1 a=fmtp:118 mode-set=0,2,4,7;mode-change-capability=2;max-red=220 a=rtpmap:96 AMR/8000/1 a=fmtp:96 mode-set=0,2,4,7;octet-align=1;mode-change-capability=2;max-red=220

Offer direction (to Asterisk) - WORKS CORRECTLY:

All variants are preserved in the offer to Asterisk:

m=audio 51710 RTP/AVP 112 116 107 118 96 8 0 111 110

Answer from Asterisk:

m=audio 11342 RTP/AVP 116 118 8 0 111 110 a=rtpmap:116 AMR-WB/16000 a=fmtp:116 mode-change-capability=2;max-red=220 a=rtpmap:118 AMR/8000 a=fmtp:118 mode-set=0,2,4,7;mode-change-capability=2;max-red=220

Asterisk only supports bandwidth-efficient mode, which is expected.

Answer SDP back to IMS - MISSING OCTET-ALIGNED VARIANTS:

m=audio 59032 RTP/AVP 116 118 112 111 110 a=rtpmap:116 AMR-WB/16000 a=fmtp:116 mode-change-capability=2;max-red=220 a=rtpmap:118 AMR/8000 a=fmtp:118 mode-set=0,2,4,7;mode-change-capability=2;max-red=220 a=rtpmap:112 EVS/16000 a=fmtp:112 br=5.9-24.4; bw=nb-swb

Expected behavior:

The answer should include PT 107 (AMR-WB octet-aligned) and PT 96 (AMR octet-aligned) so the IMS endpoint can choose its preferred variant.

What I've tried:

1. codec-accept flags:

codec-accept-AMR-WB codec-accept-AMR codec-accept-PCMA codec-accept-PCMU codec-accept-EVS

2. codec-transcode with full fmtp parameters:

codec-transcode-AMR-WB/16000/1///mode-change-capability--2;max-red--220 codec-transcode-AMR-WB/16000/1///octet-align--1;mode-change-capability--2;max-red--220 codec-transcode-AMR/8000/1///mode-set--0,2,4,7;mode-change-capability--2;max-red--220 codec-transcode-AMR/8000/1///octet-align--1;mode-set--0,2,4,7;mode-change-capability--2;max-red--220

3. codec-set flags:

codec-set-AMR-WB/16000/1///octet-align--1;mode-change-capability--2;max-red--220 codec-set-AMR/8000/1///octet-align--1;mode-set--0,2,4,7;mode-change-capability--2;max-red--220

4. codec-strip followed by codec-set:

codec-strip-AMR-WB codec-strip-AMR codec-set-AMR-WB/16000/1///mode-change-capability--2;max-red--220 codec-set-AMR-WB/16000/1///octet-align--1;mode-change-capability--2;max-red--220 ...

Relevant debug log showing the issue:

During answer processing, the log shows that RTPEngine recognizes the codecs are "already present" and skips adding the octet-aligned variants:

[codec] Codec AMR-WB already present (107) [codec] Codec AMR-WB/16000/1///mode-change-capability=2 already present (116) [codec] Codec AMR-WB/16000/1///octet-align=1;mode-change-capability=2 already present (107)

However, in the final answer SDP output, only PT 116 (bandwidth-efficient) appears - PT 107 (octet-aligned) is missing.

Analysis:

It appears that RTPEngine v14 treats bandwidth-efficient and octet-aligned as variants of the "same codec family" and only includes one variant in the answer. In v9.5, both variants were preserved.

This is problematic for IMS/VoLTE networks where the endpoint may prefer or require octet-aligned mode, and the answer must reflect all supported variants from the original offer.

Questions:

1. Is this a known behavioral change in v14?
2. Is there a flag combination that forces RTPEngine to include both bandwidth-efficient AND octet-aligned variants in the answer?
3. Should this be considered a bug/regression from v9.5 behavior?

Thank you for any guidance.