Asterisk项目中DTMF负载类型错误问题的分析与修复

问题背景

在Asterisk VoIP系统中，当处理桥接呼叫时，DTMF（双音多频）信号的传输出现了一个关键问题。具体表现为：当呼叫双方协商DTMF负载类型时，系统未能正确使用协商一致的负载类型，而是错误地使用了未被接受的负载类型。

技术细节

在SIP协议中，DTMF信号可以通过两种方式传输：

1. 带内传输：直接将音频信号编码到RTP流中
2. 带外传输：使用专门的telephone-event负载类型（RFC 2833）

在本案例中，问题出现在带外传输方式上。呼叫方A在SDP（会话描述协议）中提供了两种telephone-event负载类型：

• telephone-event/16000（负载类型100）
• telephone-event/8000（负载类型101）

而被叫方B只接受了8000Hz采样率的telephone-event（负载类型101）。按照标准协议，双方最终协商的结果应该是使用负载类型101进行DTMF传输。

问题现象

尽管协商结果明确指定了使用负载类型101，但实际传输中Asterisk却错误地使用了负载类型100来发送DTMF事件。这会导致以下问题：

1. 对端设备可能无法识别DTMF信号
2. 可能触发对端设备的错误处理机制
3. 影响呼叫的交互功能

问题根源

通过分析代码提交记录，这个问题源于Asterisk的RTP处理模块（res_rtp_asterisk.c）。在桥接呼叫时，系统未能正确处理双方协商后的DTMF负载类型，而是简单地使用了第一个可用的telephone-event负载类型。

解决方案

修复方案需要确保：

1. 在SDP协商阶段正确记录双方都接受的DTMF负载类型
2. 在RTP传输阶段严格使用协商一致的负载类型
3. 对于桥接呼叫，需要分别维护两端的DTMF负载类型映射

影响范围

该问题影响所有基于Asterisk的VoIP系统，特别是：

1. 跨不同采样率设备间的呼叫
2. 使用多种编码方式的复杂呼叫场景
3. 需要精确DTMF识别的应用（如IVR系统）

最佳实践建议

为避免类似问题，建议：

1. 在SDP协商阶段明确指定优先的DTMF负载类型
2. 定期更新到Asterisk的最新稳定版本
3. 在复杂网络环境中进行充分的DTMF测试
4. 考虑使用SIP INFO作为DTMF传输的备选方案

总结

DTMF传输是VoIP系统中的基础功能，其可靠性直接影响用户体验。Asterisk团队通过这次修复，进一步提高了系统在不同网络环境下的兼容性和稳定性。对于系统管理员而言，及时应用这类基础功能的修复补丁至关重要。