为什么 WebRTC 有时会使用 TURN？答案

【问题标题】：Why does WebRTC use TURN sometimes?为什么 WebRTC 有时会使用 TURN？
【发布时间】：2021-01-15 00:16:02
【问题描述】：

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

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

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

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

此行为是否表明我的代码中存在明显问题？
如果不是，这怎么可能？无论哪个客户端是控制器，ICE 协议不应该产生相同的两个候选吗？

【问题讨论】：

可能相关：stackoverflow.com/a/59485045 特别是关于 STUN 如何不适用于所有 NAT 的部分。这可能就是原因。我不确定它们不兼容的确切点，因此这可能是总体答案。

标签： javascript webrtc stun turn ice-protocol

【解决方案1】：

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

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

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

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

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

查看WebRTC for the 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

【讨论】：