为什么WebRTC有时需要使用TURN？

Question

我写了一个小的WebRTC演示，可以将视频文件流传输到另一个对等端，并且一切正常（它是一个真正的P2P连接，没有使用TURN服务器），除了这个问题：

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

但是当wifi客户端创建提议时，他们会退回到TURN服务器作为中继。

在Ubuntu上的Firefox和Chromium中出现此问题。

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

- Mt109

---

可能相关：https://dev59.com/_1IH5IYBdhLWcg3weOYr#59485045，特别是关于STUN无法与所有NAT一起使用的部分。这可能是原因。我不确定它们不兼容的确切点，所以这可能是总体答案。 - zero298

Answer 1

NAT具有两个属性，这些属性会影响两个WebRTC代理之间的连接是否成功。这些属性是过滤和映射。

当您向NAT外部地址发送数据包时，会创建一个映射。映射是您的IP:端口，一般人们称之为公共IP。这是其他人可以发送到的公共IP。STUN服务器只是一个回显服务器，用于响应您的映射。

第一种映射类型是地址独立的NAT。这是您需要的那种。在此配置中，每次与NAT外部的IP联系时，都会重新使用一个映射。您可以将映射提供给远程对等方，他们可以发送到您的计算机。

第二种映射类型是地址相关的。在此配置中，每个远程地址都将创建一个新的映射。这意味着您从STUN服务器获得的IP/端口无法被其他对等方使用。在这种情况下，您可能需要使用TURN服务器。 过滤控制谁被允许发送流量。有些NAT允许任何人发送流量。与映射行为一样，这被称为地址独立。其他NAT只允许您尝试联系过的人发送流量，称为地址相关 NAT。

请查看WebRTC for the Curious的“连接”章节，我会更深入地解释这个问题。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

- Sean DuBois