没有具有公共 IP 的 ICE 候选人，但 WebRTC 有时仍然可以工作答案

【问题标题】：No ICE Candidate with public IP, but WebRTC can still work sometimes没有具有公共 IP 的 ICE 候选人，但 WebRTC 有时仍然可以工作
【发布时间】：2017-07-19 01:08:30
【问题描述】：

我们正在 A、B 和 C 三个地方测试 WebRTC。

A和C是ADSL，一个在家里一个在写字楼。 B是公司静态IP直连公司防火墙和一些端口过滤规则。

结果是：A都可以连接，但是B和C只能连接A。

所以我们检查了他们的浏览器控制台输出。 A 和 C 可以获得内部和公共 IPv4 候选（192.168.1.xxx 和 123.34.xxx.xxx）。 B 可以找到 4 个 ICE 候选、2 个内部 IPv4 候选（10.0.xxx.xxx）和 2 个 IPv6 候选（不确定 IPv6 地址是内部的还是公共的）。

所以问题是：

什么阻止 B 从 STUN 服务器获取公共 IP 候选？是不是公司防火墙屏蔽了某个端口？
B 永远无法获得公共 IP 候选人，A 是如何与他联系的？ A 和 B 可以一直使用 WebRTC。
为什么C不能连接B？或者A和C有什么不同？两者都是用ADSL，光纤调制解调器到TPLINK路由器（PPPOE拨号+默认DHCP）到电脑，一模一样。

谢谢。

【问题讨论】：

#2 的一个可能答案是 A 能够从 B 接收数据包，因为 B 拥有 A 的公共地址。然后从收到的数据包中，A 生成一个“对等自反”候选者，并且能够将数据包发送回它接收它们的相同地址。您可以在 chrome://webrtc-internals 中检查这一点（“peer reflexive”表示“prflx”远程候选类型）。

标签： webrtc stun

【解决方案1】：

经过进一步研究，C没有使用ADSL。它实际上是一个带有防火墙的办公楼提供的网络。这就是为什么 C 不能连接 B 但 A 可以。

抱歉，客户“认为”他们知道自己的网络详细信息。

感谢泰勒，你是对的。 WebRTC 工作只需要一个开放的网络。

经过数小时的研究，我发现唯一的解决方案是 TURN 服务器。所以我认为这个问题现在可以结束了。

【讨论】：