在对我的网络应用程序进行故障排除时,我发现草稿-mdns-ice-候选者,这是关于使用 mDNS 混淆候选主机中的地址。
我发现,当两个对等点(代理 L、代理 R)处于如下图 7 所示的拓扑时,WebRTC 对等点连接失败,因为代理 R 的主机地址被混淆,并且代理 R 的 srflx 地址被丢弃,因为代理 R 不在 NAT 后面。中的相关表述rfc8445关于丢弃代理 R 的 srflx 地址如下。
5.1.3.消除多余的候选人
接下来,ICE 代理(发起和响应)消除冗余
候选人。两个候选人可以具有相同的传输地址
不同的基础,这些不会被认为是多余的。
通常,服务器自反候选者和主机候选者将是
当代理不在 NAT 之后时是冗余的。候选人是
冗余当且仅当其传输地址和基址等于这些
另一位候选人的。代理应该消除多余的
优先级较低的候选人。 -rfc8445 第 5.1.3 节
(图7来自rfc8445 第 15.1 节)
And in 草案 mdns-ice-candidates 第 5 节,我没有找到关于图7的情况的解释。当我测试最新版本的Chrome、Firefox和Safari时,在图7的情况下,WebRTC对等连接在所有浏览器中都失败,原因是我上面写的— 代理 R 的主机地址被混淆,代理 R 的 srflx 地址被丢弃。
通过更改浏览器设置关闭本地地址混淆(默认情况下进行混淆)时,WebRTC 对等连接已成功建立。 (我在 Chrome 和 FireFox 上测试了此成功连接。在 Chrome 中,通过禁用Anonymize local IPs exposed by WebRTC
在“关于:标志”页面中。在 Firefox 中,通过设置false
media.peerconnection.ice.obfuscate_host_addresses
在“关于:配置”页面中。)
这是 IETF 的 WebRTC 规范的问题吗? (也许之间发生碰撞草稿-mdns-ice-候选者 and rfc8445?)还是现代浏览器的实现问题?有没有办法在图7的情况下建立WebRTC对等连接而不关闭混淆主机地址?我想知道。
好消息!
实施中的这个错误是fixed通过上游 WebRTC 存储库中的补丁(这是我的贡献!):https://webrtc.googlesource.com/src/+/7eea6672285f765599fd883a5737f5cae8d20917
应用了补丁的上游 WebRTC 代码开始包含在 Chromium 上版本 110.0.5452.0. Thus 所有 Chromium 浏览器(包括 Chrome)版本或更高版本110.0.5452.0
应该应用补丁。
自补丁提交以来upstream WebRTC 存储库, 我们还可以预期其他浏览器(如 Firefox 或 Safari)迟早会应用该补丁.
UPDATE:
上游补丁是Webkit 中精选的.
事实证明,对于 Firefox,一个单独的补丁是需要的。 (这个补丁也是我的贡献。) Firefox其 ICE 堆栈使用与上游 WebRTC 不同的库。因此,在上游应用补丁对 Firefox 不起作用。 (关于这一点,有趣的是 Firefox 也有同样的错误。)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)