PJProject中DTMF发送失败问题分析与解决方案

问题背景

在使用PJProject 2.14.1版本进行VoIP开发时，开发者遇到了DTMF（双音多频）信号发送失败的问题。具体表现为调用call->dialDtmf(digit)方法时，系统返回错误信息"Remote does not support RFC 2833"，但实际上远程端是支持RFC 2833协议的。

问题现象

开发者在使用Xcode 15.3、iOS 17.2和macOS Sonoma 14.4.1环境下，调用PJProject的DTMF发送功能时遇到以下错误日志：

18:10:45.771            pjsua_aud.c !Call 0 dialing DTMF 1
18:10:45.771               call.cpp  pjsua_call_dial_dtmf(id, &pj_digits) error: Remote does not support RFC 2833 (PJMEDIA_RTP_EREMNORFC2833) (status=220107)

问题分析

RFC 2833协议简介

RFC 2833是定义在RTP中传输DTMF信号的标准协议。它通过在RTP数据包中携带特殊的事件载荷（telephone-event payload）来传输DTMF信号，而不是传统的音频信号方式。这种方式效率更高，且能准确传输DTMF信号的开始、结束和持续时间。

问题根源

根据错误信息和项目维护者的回复，该问题的根本原因是SDP（会话描述协议）协商过程中未能正确建立RFC 2833支持。具体表现为：

1. 远程端的SDP响应中没有包含tel-event载荷类型声明
2. 或者本地与远程端在tel-event格式协商上出现了问题

版本差异分析

开发者提到在PJProject 2.14版本中可以正常工作，但在2.14.1版本中出现问题。进一步调查发现，真正影响功能的因素不是版本差异，而是TLS后端的变更：

1. 之前使用OpenSSL作为TLS后端时可以正常工作
2. 切换到iOS原生TLS后端后出现问题

这表明TLS后端的变更可能影响了SDP协商过程，特别是对tel-event载荷类型的处理。

解决方案

经过深入调查和测试，开发者最终通过以下方法解决了问题：

1. 禁用部分编解码器：通过减少或调整使用的音频编解码器，可以避免SDP协商中的冲突，确保tel-event载荷类型能够被正确协商。

2. 检查SDP协商：开发者应该检查SDP offer/answer交换过程，确认tel-event载荷类型是否被正确包含在媒体描述中。

3. TLS后端选择：如果使用iOS原生TLS后端出现问题，可以考虑切换回OpenSSL后端进行测试验证。

最佳实践建议

1. SDP调试：在开发过程中，应该记录并分析完整的SDP交换过程，确保所有需要的媒体格式和载荷类型都被正确协商。

2. 编解码器配置：合理配置编解码器优先级，避免使用过多或不必要的编解码器，这可能会影响其他功能（如DTMF）的协商。

3. 版本升级测试：在升级PJProject版本时，应该全面测试所有功能，特别是与媒体协商相关的功能。

4. TLS后端选择：根据实际需求选择合适的TLS后端，并了解不同后端可能带来的行为差异。

总结

DTMF发送失败问题通常与SDP协商过程密切相关，特别是在RFC 2833支持方面。开发者应该深入理解SDP协商机制，合理配置编解码器和TLS后端，确保VoIP应用中的各种功能能够正常工作。通过系统性的分析和测试，可以有效解决这类问题。