Missing FMTP in 200OK during Re-INVITE processing

[rafaltelaczynski]

trafficstars

Describe the bug FreeSWITCH breaks RFC3264 by not generating FMTP string during Re-INVITE processing when codec changes.

Example media flow: INVITE offer:

2025-05-19 07:29:57.150197 94.37% [DEBUG] sofia.c:7503 Remote SDP:
v=0
o=HuaweiATS9900 233052942 233052942 IN IP4 10.32.148.204
s=FreeSWITCH
c=IN IP4 10.10.48.45
t=0 0
m=audio 44278 RTP/AVP 102 103 0 8 104 105 101 13
a=rtpmap:102 AMR-WB/16000
a=fmtp:102 octet-align=0; mode-set=0,1,2; max-red=0; mode-change-capability=2
a=rtpmap:103 AMR/8000
a=fmtp:103 octet-align=0; mode-set=0,1,2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:104 telephone-event/16000
a=fmtp:104 0-16
a=rtpmap:105 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

FreeSWITCH correctly selecting AMR-WB codec in answer:

2025-05-19 07:29:57.210174 94.37% [DEBUG] mod_sofia.c:2607 Ring SDP:
v=0
o=FreeSWITCH 1747622791 1747622792 IN IP4 127.0.0.1
s=FreeSWITCH
c=IN IP4 127.0.0.1
t=0 0
m=audio 17006 RTP/AVP 102 104 105
a=rtpmap:102 AMR-WB/16000
a=fmtp:102 mode-set=0,1,2;mode-change-capability=2;max-red=0
a=rtpmap:104 telephone-event/16000
a=fmtp:104 0-15
a=rtpmap:105 CN/16000
a=ptime:20
a=sendrecv

Re-INVITE received with codec changing to e.g. AMR:

2025-05-19 07:29:57.230208 94.37% [DEBUG] sofia.c:7503 Remote SDP:
v=0
o=HuaweiATS9900 233052942 233052943 IN IP4 10.32.148.204
s=FreeSWITCH
c=IN IP4 10.10.48.45
t=0 0
m=audio 44278 RTP/AVP 103 104 105 101 13
a=rtpmap:103 AMR/8000
a=fmtp:103 octet-align=0; mode-set=0,1,2
a=rtpmap:104 telephone-event/16000
a=fmtp:104 0-16
a=rtpmap:105 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

FreeSWITCH responding with:

v=0
o=FreeSWITCH 1747622791 1747622793 IN IP4 127.0.0.1
s=FreeSWITCH
c=IN IP4 127.0.0.1
t=0 0
m=audio 17006 RTP/AVP 103 101 13
a=rtpmap:103 AMR/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=ptime:20

Note there is no FMTP line related to AMR codec, which violates RFC3264:

RFC 3264, Section 6.1 (Codec Parameters):
"The interpretation of fmtp parameters in an offer depends on the parameters. In many cases, those parameters describe specific configurations of the media format [...] the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer."

Logs from the call processing attached.

To Reproduce Steps to reproduce the behavior:

1. Establish regular call.
2. Use Re-INVITE to change codec and payload type different than actually used codec.
3. FreeSWITCH generates SDP without mandatory FMTP line causing media not to be processed correctly.

Expected behavior Valid FMTP line to be present in SDP answer to offer presented in Re-INVITE.

Package version or git hash

• Version 1.10.12

Trace logs 20250519_freeswitch_missing_fmtp_issue.log

[briankwest]

You need to set the in your settings in amr.conf.xml

[rafaltelaczynski]

Hello @briankwest Set what in amr.conf.xml? Unfortuntely, I highly doubt this is related to particular codec, e.g. AMR, as this is happening no matter what audio codec has been negotiated.