RTSP-Simple-Server中RTCP复用设置失败问题分析

问题背景

在RTSP-Simple-Server项目（现更名为MediaMTX）的使用过程中，开发者报告了一个与WebRTC相关的兼容性问题。具体表现为：当使用WHEP协议从服务器获取视频流时，Chrome浏览器的WebRTC实现会抛出错误"Failed to setup RTCP mux"，导致视频流无法正常播放。

问题现象

开发者在使用最新版本的MediaMTX时遇到了以下错误信息：

InvalidAccessError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Failed to apply the description for m= section with mid='1': Failed to setup RTCP mux.

这个问题特别出现在获取经过AI推理处理后的视频流时，而直接获取原始视频流则工作正常。值得注意的是，在旧版本(1.6.0分支)中不存在此问题。

技术分析

RTCP复用(RTCP mux)机制

RTCP复用是WebRTC中的一项重要功能，它允许RTP和RTCP数据通过同一个端口传输，而不是传统RTP/RTCP实现中使用的两个连续端口。这种设计简化了NAT穿透，减少了端口使用数量，提高了连接成功率。

SDP对比分析

通过对比工作正常和异常的SDP(会话描述协议)内容，我们可以发现几个关键差异：

1. 媒体部分结构：

   • 异常SDP中，音频和视频部分被分开处理，音频部分的端口号为0(表示禁用)，而视频部分使用端口9
   • 正常SDP中，音频和视频部分都使用端口9，且被正确绑定(BUNDLE)在一起

2. 候选地址(candidate)位置：

   • 异常SDP中，候选地址仅出现在音频部分
   • 正常SDP中，候选地址出现在每个媒体部分之后

3. ICE凭证：

   • 异常SDP中，视频部分使用了独立的ICE凭证
   • 正常SDP中，音频和视频共享相同的ICE凭证

问题根源

从技术角度看，此问题源于SDP生成过程中的不一致性。WebRTC实现(特别是Chrome)对RTCP复用的设置有严格要求。当视频媒体部分缺少必要的候选地址信息，同时又声明了RTCP复用(rtcp-mux属性)时，浏览器无法建立完整的传输通道，导致设置失败。

解决方案

项目维护者在后续提交中修复了这个问题。修复的核心在于确保：

1. SDP生成过程中保持媒体部分的一致性
2. 正确传播候选地址到所有媒体部分
3. 确保ICE凭证的统一性

对于遇到类似问题的开发者，建议：

1. 检查SDP中所有媒体部分的候选地址是否完整
2. 验证RTCP复用属性是否在所有相关媒体部分一致设置
3. 确保ICE凭证在BUNDLE分组中的媒体部分保持一致

版本影响

这个问题主要出现在开发中的版本(介于1.8.2和1.8.3之间)，正式发布的1.8.2版本并不包含此问题。开发者在从源代码构建时需要注意版本稳定性。

总结

WebRTC实现中的SDP处理非常严格，特别是在RTCP复用等关键功能上。服务器端生成的SDP必须完全符合规范，才能确保与各种客户端兼容。这个案例也提醒我们，在进行媒体服务器升级时，需要全面测试各种使用场景，特别是边缘情况下的媒体流处理。