Baresip项目中多路呼出通话的音频传输问题分析与解决方案

问题背景

在基于SIP协议的多媒体通信项目Baresip中，开发者遇到一个关于多路呼出通话的音频传输问题。当用户同时发起多个呼出通话时，系统设计为当其中一路被接听后自动取消其他通话。然而在实际测试中发现，被接听的通话仅能单向传输音频（sendonly模式），无法实现双向音频通信。

技术分析

通过深入分析日志和代码，我们发现问题的核心在于音频管道的初始化逻辑。在多个呼出通话场景下，系统对SDP（会话描述协议）中的媒体方向属性处理存在缺陷：

1. 当收到180 Ringing响应时，系统会初始化音频管道，但此时仅配置为单向传输
2. 即使SDP中明确包含"a=sendrecv"属性，表示支持双向传输，系统仍错误地保持单向模式
3. 问题函数audio_start()中的sdp_media_dir(m)调用始终返回2（表示sendonly），与实际的SDP内容不符

根本原因

经过代码审查，我们发现这与Baresip的"early-video"模式实现有关。在该模式下：

1. 被叫方（收到INVITE的UA）会请求来自主叫方的早期视频
2. 但被叫方自身不提供摄像头流
3. 系统默认禁用了早期音频功能
4. 当通话被接听后，本应通过re-INVITE重新协商启用双向音频/视频，但此流程未能正确执行

关键函数call_need_modify()未能按预期返回true，导致set_established_mdir()无法正确设置媒体方向。

解决方案

项目维护者提出了修复方案，主要包含以下改进：

1. 修正媒体方向协商逻辑，确保在通话建立后能正确识别双向传输需求
2. 完善early-video模式下的状态机转换
3. 确保音频管道在通话接听后能正确重新配置为双向模式

验证结果

开发者测试确认该修复方案有效解决了问题。修复后：

1. 多路呼出通话场景下，被接听的通话能正确建立双向音频通道
2. 音频管道完整初始化，包括ALSA播放器的正确配置
3. 系统日志显示音频收发管道均正常建立

总结

这个案例展示了SIP协议中媒体协商的复杂性，特别是在多路通话和特殊模式（如early-video）组合场景下。Baresip项目通过精确识别状态转换时机和正确解析SDP属性，确保了多媒体通信的可靠性。对于开发者而言，理解SIP协议的状态机和媒体协商机制对于构建稳定的VoIP应用至关重要。