Gor*_*son 8 mdns webrtc rtcpeerconnection
在对我的网络应用程序进行故障排除时,我发现了Draft-mdns-ice-candidates,它是关于使用 mDNS 来混淆候选主机中的地址。
\n我发现,当两个对等点(代理 L、代理 R)处于如下图 7 所示的拓扑时,WebRTC 对等点连接失败,因为代理 R 的主机地址被混淆,并且代理 R 的 srflx 地址被丢弃,因为代理 R 不在 NAT 后面。rfc8445中的相关表述如下。
\n\n\n5.1.3. 消除多余的候选人
\n
\n\n接下来,ICE 代理(发起和响应)消除冗余\n候选者。两个候选者可以具有相同的传输地址,但\n不同的基数,并且这些不会被视为冗余。\n当代理不在 NAT 之后时,\n通常,服务器自反候选者和主机候选者\n将是冗余的。当且仅当一个候选者的传输地址和基址等于另一个候选者的传输地址和基址时,\n该候选者才是冗余的。代理应该消除具有较低优先级的冗余候选。- rfc8445 第 5.1.3 节
\n
\n\n\n
\n\n(图7来自rfc8445的15.1节)
\n
在Draft-mdns-ice-candidates 的第 5 节中,我没有找到有关图 7 的情况的解释。当我测试最新版本的 Chrome、Firefox 和 Safari 时,WebRTC 对等连接在所有浏览器中均失败在图7的情况下,由于我上面写的\xe2\x80\x94的原因,代理R的主机地址被混淆,并且代理R的srflx地址被丢弃。
\n通过更改浏览器设置关闭本地地址混淆(默认情况下进行混淆)时,WebRTC 对等连接已成功建立。(我在 Chrome 和 FireFox 上测试了此成功连接。在 Chrome 中,通过Anonymize local IPs exposed by WebRTC在“about:flags”页面中禁用。在 Firefox 中,通过在“about:config”页面中设置false media.peerconnection.ice.obfuscate_host_addresses。)
这是 IETF\xe2\x80\x99s WebRTC 规范的问题吗?(也许draft-mdns-ice-candidates和rfc8445之间发生冲突?)或者现代浏览器的实现问题?有没有办法在图7的情况下建立WebRTC对等连接而不关闭混淆主机地址?我想知道。
\n来自Draft-ietf-mmusic-mdns-ice-candidates-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 地址相匹配而忽略 SRFLX 候选者,这似乎是明确不合格的。
| 归档时间: |
|
| 查看次数: |
1648 次 |
| 最近记录: |