在对我的网络应用程序进行故障排除时，我发现草稿-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 也有同样的错误。）
