RTSP-Simple-Server中WebRTC ICE候选缺失问题分析与修复

问题背景

在RTSP-Simple-Server（现更名为MediaMTX）v1.11.1版本中，用户报告了一个关于WebRTC ICE候选收集的问题。具体表现为在特定网络环境下，某些关键的TCP类型ICE候选无法被正确收集，导致在受限网络（如企业内部网络环境）中无法建立WebRTC连接。

技术细节分析

WebRTC的ICE（Interactive Connectivity Establishment）框架负责在两个对等体之间寻找最佳的连接路径。ICE候选代表可能的通信端点，包括：

1. 主机候选（host）：本地网络接口的直接地址
2. 服务器反射候选（srflx）：通过STUN服务器获取的公网地址
3. 对等反射候选（prflx）：在连接检查过程中发现的地址
4. 中继候选（relay）：通过TURN服务器中继的地址

在v1.11.1版本中，当配置了webrtcAdditionalHosts（指定额外主机IP）且webrtcIPsFromInterfaces设置为no（不从网络接口收集IP）时，系统无法正确生成TCP类型的候选对，特别是那些通过webrtcAdditionalHosts指定的公网IP相关的候选。

问题根源

该问题源于v1.11.0到v1.11.1版本升级过程中引入的pions/ice库从v2升级到v4版本（也可能是pions/webrtc从v2到v4的升级）。这一变更影响了TCP候选的收集逻辑，特别是在以下配置组合下：

webrtcAdditionalHosts: [公网IP地址]
webrtcIPsFromInterfaces: no

临时解决方案

在修复版本发布前，用户发现可以通过修改配置来恢复功能：

webrtcAdditionalHosts: [公网IP地址]
webrtcIPsFromInterfaces: yes

这种配置虽然会生成一些不必要的本地接口候选，但能够恢复缺失的关键TCP候选。

官方修复

项目维护者在v1.11.2版本中修复了这个问题。修复主要针对TCP候选收集逻辑，确保当指定了webrtcAdditionalHosts时，无论webrtcIPsFromInterfaces如何设置，都能正确生成所有必要的ICE候选。

技术启示

1. ICE候选收集：WebRTC连接建立依赖于完整的候选收集，特别是在复杂网络环境中，TCP候选可能成为关键路径。

2. 库版本升级影响：底层库的升级（如pions/ice）可能引入不明显的行为变化，需要全面测试各种配置组合。

3. 网络环境适配：在企业网络环境中，UDP流量可能被限制，TCP候选成为连接建立的唯一选择，确保TCP候选的完整性尤为重要。

最佳实践建议

1. 在升级WebRTC相关服务时，应全面测试各种网络环境下的连接建立情况。

2. 对于企业部署，建议同时测试UDP和TCP候选的工作情况，确保在限制性网络中的可用性。

3. 使用webrtcAdditionalHosts指定公网IP时，建议保持默认的webrtcIPsFromInterfaces设置，除非有特殊需求。

该问题的修复体现了开源社区对WebRTC连通性问题的快速响应能力，为在复杂网络环境中部署实时媒体服务提供了更可靠的保障。