libdatachannel中在协商过程中添加轨道的问题解析

背景介绍

在WebRTC开发中，轨道(Track)的添加和协商是一个核心功能。libdatachannel作为一个C++的WebRTC数据通道库，在处理轨道添加时存在一些特殊行为需要开发者注意。

问题现象

在libdatachannel使用过程中，开发者发现如果在协商过程中添加新的轨道，会出现轨道丢失的情况。具体表现为：

1. 当两个添加轨道的事件几乎同时发生时，第二个轨道会被静默丢弃
2. 当两端同时发送offer时，其中一端添加的轨道会被完全移除而没有任何通知

技术分析

协商状态管理

libdatachannel当前的实现中，协商需求状态的跟踪机制较为简单：

• 添加轨道时设置一个标志位
• 调用setLocalDescription()时清除该标志位

这种实现方式导致在并发事件发生时，某些轨道可能未被协商，但库却"忘记"了需要协商的状态。

与WebRTC标准的差异

根据WebRTC标准规范：

• 添加轨道操作(addTrack)应只在稳定(Stable)状态下进行
• 当两端同时发送offer时，应实现"礼貌协商"(polite negotiation)机制，其中一端应放弃自己的offer而接受对方的offer

libdatachannel当前的行为与这些标准要求存在偏差，特别是在处理并发添加轨道和offer冲突时的行为不够完善。

解决方案建议

临时解决方案

开发者可以采取以下临时措施：

1. 在调用addTrack()前检查信令状态，若非稳定状态则排队等待
2. 处理offer冲突时，实现自己的轨道添加队列机制
3. 对于冲突情况下添加的轨道，需要跟踪其状态并适时重新添加

长期改进

从库的实现角度看，需要：

1. 完善协商需求状态的跟踪机制
2. 实现标准的礼貌协商行为
3. 在非稳定状态下调用addTrack()时应明确返回错误而非静默失败
4. 确保所有添加的轨道最终都能得到协商

最佳实践

在使用libdatachannel进行轨道管理时，建议：

1. 避免在非稳定状态下添加轨道
2. 实现轨道添加队列机制处理并发情况
3. 监控信令状态变化，在适当时机处理积压的轨道添加请求
4. 对于冲突情况下添加的轨道，做好生命周期管理

总结

libdatachannel当前在协商过程中添加轨道的行为存在改进空间，开发者需要了解这些特性并采取相应措施确保轨道添加的可靠性。随着库的不断完善，这些问题有望得到解决，使轨道管理更加符合WebRTC标准行为。