Baresip项目中test_call_bundle测试不稳定的分析与解决

问题背景

在Baresip项目的最新测试中发现，test_call_bundle测试用例在macOS平台上运行时表现出不稳定性。该测试主要验证SIP呼叫中的媒体捆绑(bundle)功能，这是WebRTC中常用的一种优化技术，允许将多个媒体流(如音频和视频)通过同一个传输通道传输。

问题现象

测试失败时的主要表现为：

1. 主循环超时(60秒)
2. SRTP解密失败，出现认证错误
3. 预期的事件顺序与实际不符，特别是CALL_RTPESTAB事件

技术分析

从日志中可以观察到几个关键点：

1. 事件顺序问题：测试期望的CALL_RTPESTAB事件顺序与实际发生的不一致。测试预期先由UA b触发，但实际上由UA a先触发。

2. 取消规则不完整：测试中使用了cancel_rule_new和cancel_rule_and来管理事件，但可能存在取消点数量不足的情况。当预期有5个取消点而实际只发生4个时，会导致测试挂起。

3. 平台差异：问题仅在macOS上出现，可能与macOS的网络栈实现或定时器精度有关。

解决方案

经过深入分析，开发团队采取了以下措施：

1. 完善取消规则：确保所有可能的事件路径都有对应的取消点，防止测试挂起。

2. 增加调试输出：在selftest中加入详细的取消规则调试信息，便于后续问题诊断。

3. 平台特定调整：针对macOS的网络特性，优化了测试的超时设置和事件等待逻辑。

技术要点

1. 媒体捆绑(Bundle)机制：这是WebRTC中的重要优化技术，允许多个媒体流共享同一个传输通道，减少端口使用和NAT穿透难度。

2. SRTP安全传输：测试中出现的SRTP解密失败表明可能在密钥协商或同步方面存在问题。

3. 事件驱动架构：Baresip采用事件驱动模型，正确的事件顺序和时序对系统稳定性至关重要。

总结

这次问题的解决不仅修复了macOS平台上的测试稳定性问题，还增强了对媒体捆绑机制的理解。通过完善事件取消规则和增加调试信息，提高了测试套件的健壮性，为后续开发奠定了更坚实的基础。这也提醒开发者在跨平台开发时需要特别注意平台差异对网络和定时行为的影响。