libdatachannel中多视频轨道传输问题的分析与解决

问题背景

在使用libdatachannel进行WebRTC视频传输时，开发者经常会遇到需要同时传输多个视频轨道的情况。例如在医疗影像传输场景中，可能需要同时传输普通摄像头视频和超声影像视频。然而，在实际实现过程中，开发者发现当尝试同时传输多个视频轨道时，会出现接收端无法正常接收所有轨道数据的问题。

问题现象

开发者报告了以下具体现象：

1. 单向单轨道传输时工作正常（Peer A→Peer B或Peer B→Peer A）
2. 双向单轨道传输时（Peer A→Peer B同时Peer B→Peer A），只有一方能收到视频
3. 单方向双轨道传输时（Peer A同时发送两个视频轨道给Peer B），接收端无法收到任何视频数据
4. 通过自定义MediaHandler调试发现，发送端数据正常发送，但接收端处理链路的入口处没有收到数据

技术分析

通过对问题描述和提供的SDP信令分析，可以定位到问题的核心在于SSRC(同步源标识符)的设置方式不正确。在WebRTC中：

1. SSRC用于在RTP会话中唯一标识一个媒体源
2. 每个媒体轨道必须具有唯一的SSRC
3. SSRC应当由媒体发送方设置，而不是接收方

在开发者提供的SDP中，可以看到接收方(offer)尝试设置SSRC，而发送方(answer)却没有设置SSRC。这种反向设置方式违反了WebRTC的规范，导致媒体流无法正确建立。

解决方案

正确的实现方式应该是：

1. 发送方在创建轨道时为其分配唯一的SSRC
2. 发送方在SDP answer中明确指定每个轨道的SSRC
3. 接收方不应在SDP offer中预设SSRC

具体到libdatachannel的实现，可以通过以下代码在onTrack回调中设置SSRC：

pc->onTrack([mySSRC](shared_ptr<Track> track) {
    auto description = track->description();
    description.addSSRC(mySSRC, "video");
    track->setDescription(std::move(description));
});

最佳实践建议

1. 对于多轨道传输场景，确保每个轨道具有唯一的SSRC
2. SSRC应当由媒体发送方设置
3. 在调试多轨道问题时，可以检查SDP中的SSRC设置情况
4. 考虑使用不同的媒体类型(mid)来区分不同类型的轨道
5. 在复杂网络环境下，确保ICE候选地址正确，避免因NAT穿越问题导致媒体流中断

总结

多视频轨道传输是WebRTC应用中的常见需求，但需要特别注意SSRC等关键参数的设置。通过正确理解WebRTC规范并在libdatachannel中合理实现，可以构建稳定可靠的多轨道视频传输系统。本文分析的问题和解决方案不仅适用于libdatachannel，对于其他WebRTC实现也具有参考价值。