当对等方由于混淆主机地址而不在NAT之后时，WebRTC在现代浏览器中不起作用 [英] WebRTC does not work in the modern browsers when a peer is not behind a NAT because of the obfuscating host address
问题描述
在对我的Web应用进行故障排除时，我发现draft-mdns-ice-candidates，它与使用mDNS混淆候选主机中的地址有关。
我发现，当两个对等体(代理L、代理R)在下面的图7所示的拓扑中时，WebRTC对等体连接失败，因为代理R的主机地址被混淆，并且由于代理R不在NAT之后，代理R的srflx地址被丢弃。rfc8445中关于丢弃代理R的srflx地址的相关表达式如下所示。5.1.3。排除多余的候选人
接下来，ICE代理(启动和响应)消除冗余 候选人。两个候选人还可以拥有相同的交通地址 不同的基地，这些不会被认为是多余的。 通常，服务器自反候选者和主机候选者将 当代理不在NAT之后时是冗余的。候选人是 冗余当且仅当其传输地址和基址与其传输地址和基址相等时 另一位候选人的名字。代理商应该剔除多余的 优先级较低的候选人。-section 5.1.3 of rfc8445
(图7来自section 15.1 of rfc8445)
在section 5 of draft-mdns-ice-candidates中，我没有找到关于图7的情况的任何解释。当我测试最新版本的Chrome、Firefox和Safari时，由于我在上面写的原因-代理R的主机地址被混淆并且代理R的srflx地址被丢弃-WebRTC对等连接在图7的所有浏览器中都失败。
通过更改浏览器设置关闭本地地址模糊时(默认情况下进行模糊处理)，WebRTC对等连接建立成功。(我在Chrome和Firefox上测试了这个成功的连接。在Chrome中，通过禁用&Quot；About：FLAGS"；页中的Anonymize local IPs exposed by WebRTC。在Firefox中，通过在"关于：配置"页中设置falsemedia.peerconnection.ice.obfuscate_host_addresses。)
这是IETF的WebRTC规范的问题吗？(可能是draft-mdns-ice-candidates和rfc8445之间的冲突？)或者是现代浏览器的实现问题？在图7的情况下，有没有一种方法可以在不关闭混淆主机地址的情况下建立WebRTC对等连接？我想知道。
推荐答案
发自draft-ietf-mmusic-mdns-ice-candidates-02, Section 3.1.2.2：
无论结果如何，都将生成服务器自反候选；此候选的传输地址是IP地址，因此与关联mDNS候选的主机名传输地址不同，因此根据[RFC8445]第5.1.3节中的指导，不能将其视为冗余。为避免意外泄露IP地址，此服务器自反候选必须将其raddr字段设置为"；0.0.0.0"；/"；：："；，并将其rport字段设置为"；9"；，如[ICESDP]的第9.1节中所述。
省略SRFLX候选项，因为其服务器自反IP地址与用于生成本地混淆候选项的IP地址匹配，因此似乎显式不符合要求。
这篇关于当对等方由于混淆主机地址而不在NAT之后时，WebRTC在现代浏览器中不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
