Firefox下WebRTC SFU广播隔次失效问题排查求助
问题背景
基于Pion实现SFU搭建带审核机制的Webinar房间WebRTC项目，浏览器端采用自研JavaScript客户端，仅在Firefox环境下出现Peer B向Peer A广播音视频时隔次才能正常接收的异常，经多轮调试后整理以下现象与排查信息：
现象总结
成功/失败共性
- 双方均使用Firefox浏览器
- SFU生成的SDP仅mid标识不同，音视频Track均存在
- SDP协商全程无失败
- JS客户端正常触发
ontrack事件 - 音视频编码统一为OPUS/VP8
- m-line及对应transceivers方向变更符合预期
videoElement.srcObject已正确绑定MediaStream，音视频Track的muted=false、enable=true、readyState=live- JS客户端无流等待逻辑阻塞
- Firefox
about:webrtc显示ICE连接状态成功，候选地址为nominated和selected
失败时差异
- SFU发给Peer A的SDP中音视频Track顺序反转（视频在前）
- 仅触发视频Track的
onunmute事件，但画面空白 - 广播开启时静音Peer B的视频，Peer A的音频Track可正常触发
onunmute并播放 - 保持Peer B视频静音时，Peer A可稳定接收音频
- 失败时仅存在1条inbound-rtp音频Track，成功时则有音视频两条
补充排查信息
- 失败场景下音频Track存在高丢包：接收21854个包，丢失10927个（丢包率约50%）
- WebRTC内部状态观察：关闭广播后存在1条泄漏的入站视频Track；再次开启广播时，入站音频Track的SSRC发生变更
排查与解决建议
统一SDP的m-line顺序
Firefox对SDP中m-line的顺序敏感度较高，失败场景下的顺序反转可能导致Track与mid的绑定异常。需修改SFU逻辑，确保发送给Peer A的SDP始终保持与Peer B发送的SDP一致的m-line顺序（例如固定音频在前、视频在后），避免跨会话的顺序变更。清理残留的Track资源
关闭广播后泄漏的入站视频Track会干扰后续会话的Track绑定。需在Peer侧关闭广播时，主动调用transceiver.stop()或track.stop()清理对应资源；同时在SFU侧监听Peer连接状态，及时释放关联的Track、流及转发资源，避免残留资源冲突。稳定SSRC映射关系
再次开启广播时音频Track的SSRC变更伴随高丢包，说明SFU的RTP转发逻辑可能存在SSRC映射不稳定的问题。需调整SFU配置，在重新广播时复用原有SSRC，或在SDP中明确指定SSRC，确保Firefox能正确关联RTP流；同时检查SFU的转发路由逻辑，避免出现流转发中断或错误路由。优化JS客户端的Track处理逻辑
失败时仅触发视频onunmute但画面空白，需检查ontrack事件的处理逻辑，确保每个Track都正确关联到对应MediaStream；可在SDP协商完成后，主动检查Track的readyState并同步UI状态，避免依赖Firefox的自动事件触发。另外可尝试在Firefox的about:config中禁用media.peerconnection.mid_signaling，验证是否为mid与Track绑定的兼容性问题。调整多Track转发的资源分配
单一音频流可正常接收的现象说明，多Track转发时可能存在资源抢占问题。需在SFU中配置QoS参数，均衡音视频流的带宽与资源分配，避免视频流抢占音频流的转发资源导致丢包。
内容的提问来源于stack exchange，提问作者Marco Sacchi
