SDP Offer/Answer模型中DTMF rtpmap/fmtp不匹配问题咨询

原始Offer SDP #

m=audio 35904 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

原始Answer SDP #

m=audio 1235 RTP/AVP 8 120
a=rtpmap:8 PCMA/8000
a=rtpmap:120 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

合规性分析（基于RFC 3264） #

咱们先锚定RFC 3264的核心规则：Answer里的媒体参数必须和自身m行的载荷类型正确绑定，尤其是动态载荷（比如DTMF的telephone-event），rtpmap和fmtp必须指向同一个载荷号，而且这个载荷号必须出现在当前m行的载荷列表里。

针对这个场景的问题点：

• Offer的配置完全合规：m行列出了载荷101，rtpmap把101绑定到telephone-event，fmtp又为101指定了DTMF范围0-15，三者一一对应，没有问题。
• Answer存在明显的合规性问题：
  1. m行只包含载荷8和120，但fmtp却指向了101——这个载荷号根本不在当前媒体行的列表里，属于无效参数。
  2. rtpmap把120绑定到telephone-event，但对应的fmtp却错误关联了不存在的101，违反了“fmtp必须与同一条媒体描述中的rtpmap载荷号一一对应”的硬性要求。

处理方案 #

对于接收Answer的一方（Offer发起方） #

你有两种合理的处理路径可选：

• 严格合规路径：直接拒绝该Answer，返回488 Not Acceptable Here响应，并在Reason头里明确说明问题：“DTMF参数不匹配：fmtp指向的载荷号101未出现在Answer的m行中，且与rtpmap绑定的120不对应”。这是最安全的做法，能避免后续DTMF传输出现兼容性故障。
• 容错修复路径：如果你的系统允许一定程度的容错，可以忽略无效的a=fmtp:101 0-15条目，默认使用rtpmap:120 telephone-event/8000的配置，同时沿用Offer中协商的DTMF范围0-15（毕竟telephone-event的默认范围也是0-15，和Offer一致）。但要注意，这种修复需要双方设备都有类似的容错逻辑，否则可能出现DTMF无法识别的情况。

对于生成Answer的一方（应答方） #

需要修正Answer的SDP，确保参数完全匹配：

• 修正方案1：保持DTMF载荷号与Offer一致，把m行改回包含101，同时保留对应的rtpmap和fmtp：

  m=audio 1235 RTP/AVP 8 101
  a=rtpmap:8 PCMA/8000
  a=rtpmap:101 telephone-event/8000
  a=fmtp:101 0-15
  a=sendrecv
  

• 修正方案2：如果确实需要使用120作为DTMF载荷号，必须把fmtp的载荷号改为120，确保和rtpmap对应：

  m=audio 1235 RTP/AVP 8 120
  a=rtpmap:8 PCMA/8000
  a=rtpmap:120 telephone-event/8000
  a=fmtp:120 0-15
  a=sendrecv
  

内容的提问来源于stack exchange，提问作者takobaba