SIPSorcery项目中WebRTC SetRemoteDescription错误分析与解决

问题背景

在WebRTC开发过程中，使用SIPSorcery库时遇到SetRemoteDescription调用返回错误的情况。具体场景是一个请求方Peer A和一个提供方Peer B之间的连接建立过程。Peer A发送了一个offer，其中视频设置为recvonly（仅接收），音频设置为inactive（非活跃）。

错误现象分析

当Peer B尝试设置远程描述时，SetRemoteDescription状态返回为Error。经过排查，发现可能的原因包括：

1. 缺少音频轨道：虽然Peer A的offer中将音频设置为inactive，但Peer B没有正确处理这种情况
2. SDP协商问题：视频或音频的格式协商可能存在问题
3. 内部状态不一致：RTPSession在处理轨道时可能出现并发修改问题

技术细节解析

SDP协商机制

在WebRTC中，SDP(会话描述协议)用于媒体协商。Peer A发送的offer中明确指定了：

• 视频：recvonly（Peer B需要提供视频发送能力）
• 音频：inactive（双方都不发送或接收音频）

轨道管理问题

当Peer B仅添加视频轨道而忽略音频轨道时，SIPSorcery内部会进行检查。虽然音频被标记为inactive，但系统仍期望存在对应的音频轨道。

并发修改异常

在尝试添加inactive音频轨道时，出现了"Collection was modified"异常。这表明在枚举集合时，集合被其他线程修改，这是典型的并发访问问题。

解决方案

1. 正确处理inactive音频：即使音频设置为inactive，也应添加对应的音频轨道
2. 线程安全处理：确保在添加轨道时不会出现并发修改
3. 错误处理增强：捕获并记录SetRemoteDescription过程中的详细异常信息

最佳实践建议

1. 始终为所有媒体类型添加轨道，即使设置为inactive
2. 在添加轨道前确保RTPSession处于稳定状态
3. 实现完善的错误日志记录机制，便于排查协商问题
4. 对于复杂的媒体协商场景，逐步验证每个媒体轨道的状态

总结

在SIPSorcery项目中处理WebRTC连接时，正确处理各种媒体轨道状态至关重要。即使某些媒体被标记为inactive，也应遵循完整的轨道管理流程。通过理解底层协商机制和加强错误处理，可以显著提高WebRTC连接的稳定性。