PJSIP Android项目中DTMF信号发送导致应用崩溃的分析与解决

问题背景

在基于PJSIP 2.15.1版本的Android VoIP应用开发过程中，开发人员遇到了一个特定场景下的应用崩溃问题。当应用通过RFC2833方法向特定IVR号码发送DTMF信号时，系统会触发断言失败，导致应用崩溃。值得注意的是，这一问题仅出现在特定的IVR号码上，而对其他测试号码则工作正常。

问题现象

应用崩溃时的核心错误信息显示，系统在sock_common.c文件中检测到了一个断言失败：

assertion "a->addr.sa_family == PJ_AF_INET || a->addr.sa_family == PJ_AF_INET6" failed

这个断言检查的是socket地址族是否为IPv4(PJ_AF_INET)或IPv6(PJ_AF_INET6)。当断言失败时，系统会抛出SIGABRT信号，导致应用崩溃。

技术分析

问题发生的上下文

从日志分析可以看出，问题发生在以下场景序列中：

1. 应用成功发送DTMF信号"2"（通过RFC2833方法）
2. 约0.5秒后，收到来自服务器的re-INVITE请求
3. 在媒体重新协商过程中，系统尝试处理socket地址时触发断言失败

根本原因

深入分析表明，这个问题与以下几个技术因素相关：

1. 媒体重新协商问题：当收到re-INVITE请求时，PJSIP会重新初始化媒体通道。在这个过程中，系统可能未能正确处理某些网络地址信息。

2. ICE交互影响：虽然表面上看起来是DTMF发送导致的问题，但实际上崩溃发生在媒体重新协商阶段。ICE(Interactive Connectivity Establishment)协议在此过程中可能产生了干扰。

3. 地址族验证不足：系统在验证socket地址族时没有充分考虑所有可能的中间状态，导致在特定网络条件下触发断言。

解决方案

经过多次测试和分析，开发团队确定了以下有效的解决方案：

方案一：禁用ICE功能

对于直接与CUCM(Cisco Unified Communications Manager)进行信令通信的场景，ICE功能并非必需。通过在PJSIP配置中禁用ICE，可以避免这个问题：

acccfg.natConfig.iceEnabled = false

这个方案简单有效，特别适合企业内网通信场景。

方案二：升级PJSIP版本

根据PJSIP开发团队的建议，这个问题可能已经在最新版本中得到修复。特别是与媒体拆除和重新初始化相关的改进，可能从根本上解决了这个断言失败问题。

最佳实践建议

1. 环境适配：在直接与企业通信系统(如CUCM)集成的场景下，评估是否真正需要ICE等NAT穿透功能。

2. 错误处理：增强应用的错误处理机制，特别是在媒体重新协商期间，避免在敏感操作期间发送DTMF信号。

3. 日志完善：确保完整记录时间戳信息(PJ_LOG_HAS_TIME)，以便更准确地分析事件序列。

4. 测试策略：针对不同的IVR系统进行充分测试，特别是那些可能发送re-INVITE请求的系统。

总结

这个案例展示了VoIP应用开发中常见的复杂性问题——表面现象(DTMF发送导致崩溃)往往掩盖了真正的根本原因(媒体重新协商过程中的地址处理)。通过深入分析日志和了解底层协议交互，开发人员能够找到有效的解决方案。同时，这个案例也提醒我们，在特定网络环境下，适当简化协议栈配置(如禁用非必需的ICE功能)可能是更可靠的选择。