4

我编写了一个小型 WebRTC 演示，它将视频文件流式传输到另一个对等点，并且一切正常（这是一个真正的 P2P 连接，不使用 TURN 服务器），除了这个：

一个客户端通过移动网络连接，一个通过 wifi 连接。当移动客户端创建报价并来回启动 ICE 候选人时，他们会选择 srflx 候选人并创建真正的 P2P 连接。

但是当 wifi-client 创建 offer 时，它们会退回到 TURN 服务器作为中继。

这发生在 Ubuntu 上的 Firefox 和 Chromium 中。

  1. 这种行为是否指向我的代码中的一个明显问题？
  2. 如果不是，这怎么可能？无论哪个客户端是控制器，ICE 协议不应该产生相同的两个候选者吗？
4

1 回答 1

3

如果两个 WebRTC 代理之间的连接成功，NAT 有两个属性影响。这些属性是filtering和mapping。

当您将数据包发送到 NAT 之外的地址时，您会创建一个mapping. 映射是你的IP:Port，人们通常称之为你的Public IP。这是Public IP其他人可以发送的。STUN 服务器只是一个响应您的映射的回显服务器。

第一种映射类型是Address IndependentNAT。这是你想要的。mapping在此配置中，您每次联系 NAT 外的 IP时都会重复使用。您可以将您的信息分mapping发给远程同行，他们可以发送给您。

第二种映射类型是Address Dependent. 在此配置中，您mapping为每个远程地址创建一个新地址。这意味着您从 STUN 服务器返回的 IP/端口不能被其他对等方使用。在这种情况下，您可能必须使用 TURN 服务器。

filtering控制谁被允许发送。一些 NAT 允许任何人发送流量。类似的mapping行为称为Address Independent. 其他 NAT 仅允许某人发送您尝试联系的流量，称为Address DependentNAT。

查看WebRTC 的 Curious's Connecting Chapter我试图更深入地解释这一点。Pion 还有一个工具stun-nat-behavior可以像这样打印出 NAT 的详细信息。

connecting to STUN server: stun.voip.blackberry.com:3478
=> NAT mapping behavior: endpoint independent
=> NAT filtering behavior: address and port dependent
于 2021-01-15T06:04:53.743 回答