在现代浏览器中，由于主机地址混淆而使得对等方不在NAT后面时，WebRTC无法工作。
在对我的web应用程序进行故障排除时，我发现了选秀-mdns-冰候选人，它是关于使用mDNS混淆主机候选地址的。
我发现，当两个对等点(代理L，代理R)处于如下图7所示的拓扑结构中时，WebRTC对等连接失败，因为代理R的主机地址被混淆，并且由于代理R不在NAT后面，代理R的srflx地址被丢弃。rfc8445中关于丢弃代理R的srflx地址的相关表达式如下。
5.1.3。接下来，ICE代理(启动和响应)消除冗余候选人。两个候选人可以有相同的传输地址，但不同的基地，这些不会被认为是多余的。通常，当代理不在NAT后面时，服务器自反式候选和主机候选将是冗余的。一个候选人是多余的当且仅当它的传输地址和基相等于另一个候选人。代理应消除优先级较低的冗馀候选人。- rfc8445 5.1.3节
(图7来自rfc8445第15.1节)
在选秀第5节-冰上候选人中，我没有找到对图7的解释。当我测试最新版本的Chrome、Firefox和Safari时，图7中所有浏览器的WebRTC对等连接都失败了，因为我上面写的原因--代理R的主机地址被混淆了，代理R的srflx地址被丢弃了。
当通过更改浏览器设置关闭混淆本地地址时(默认情况下混淆是完成的)，成功地建立了WebRTC对等连接。(我在Chrome和FireFox上测试了这个成功的连接。在Chrome中，禁用“关于:标志”页面中的Anonymize local IPs exposed by WebRTC。在Firefox中，通过在"about:config“页面中设置false media.peerconnection.ice.obfuscate_host_addresses。)
这是IETF的WebRTC规范的问题吗？(也许是选秀-mdns-冰候选人和rfc8445之间的碰撞？)或者是现代浏览器的实现问题？在图7中，是否有一种方法可以在不关闭模糊主机地址的情况下建立WebRTC对等连接？我想知道。
回答 2
Stack Overflow用户
发布于 2021-11-18 19:07:37
来自草案-ietf-mmusic-mdns-冰-候选-02，3.1.2.2节
不管结果如何，都会生成一个服务器自反式候选；该候选的传输地址是一个IP地址，因此不同于关联的mDNS候选的主机名传输地址，因此，根据RFC8445第5.1.3节中的指导，不应将其视为冗余。为了避免意外的IP地址泄漏，此服务器-自反式候选服务器必须将其raddr字段设置为"0.0.0.0"/"::“，并将其rport字段设置为"9"，如ICESDP第9.1节所述。
忽略SRFLX候选地址，因为其服务器自反IP地址匹配用于产生本地模糊候选的IP地址，这似乎是显式不符合的。
Stack Overflow用户
发布于 2022-12-02 06:55:47
好消息！
实现中的这个错误是通过上游WebRTC回购程序中的一个补丁修复了WebRTC(这是我的贡献！)：https://webrtc.googlesource.com/src/+/7eea6672285f765599fd883a5737f5cae8d20917
应用补丁的上游WebRTC代码开始包含在版本110.0.5452.0的铬上。因此，所有浏览器(包括Chrome) (包括Chrome)在版本110.0.5452.0 上都应该被应用到修补程序.中。
由于该修补程序是在 WebRTC回购上提交的，所以也可以预期其他浏览器(如火狐或Safari)迟早会应用该修补程序。
https://stackoverflow.com/questions/61629450
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号