如何修复不可靠的 WebRTC 调用？答案

【问题标题】：How to fix unreliable WebRTC calling?如何修复不可靠的 WebRTC 调用？
【发布时间】：2017-08-07 18:48:46
【问题描述】：

WebRTC 调用在我们的应用程序中不可靠。有时我们会看到黑屏，有时我们根本看不到通话开始，有时会看到巨大的延迟或音频/视频不同步。

设置：

几乎100% 重现的问题是从一个使用 LTE 的客户端呼叫另一个使用 Wi-Fi 的客户端。在这种情况下，我们在两个设备上都看到黑屏，但是，默认的 bg-color 是白色，所以至少 WebRTC 端发生了一些事情。

为解决问题采取了哪些措施：

检查 Coturn 日志...有时我们会看到“未经授权”的错误，但很难说它们是否会影响任何东西；
检查 Coturn 的流量：在 Wi-Fi 到 Wi-Fi 的情况下，流量很低，因此确实建立了点对点连接。如果有 LTE，我们会看到大约 40–120KiB/秒的负载（这对于音频/视频来说是不是太低了？），所以 TURN 似乎可以工作；
检查了客户端应用日志，没什么特别的；

请提出任何可能的研究或修复方法，以使 WebRTC 尽可能可靠。

【问题讨论】：

您是否验证过您的轮机服务器确实可以工作？参见示例 #2 here
@PhilippHancke 当没有点对点连接时，我们看到一些流量通过 TURN 服务器，40-120KiB/秒。而这个高峰与呼唤相匹配。
40-120kbps 对于音频/视频通话来说太低了。此外，TURN 是一个后备，因此在直接连接工作时不会使用。检查这一点的最简单方法是在连接建立时停止转向服务器 - 如果呼叫继续，则它没有使用 TURN 服务器
@PhilippHancke 刚刚测试过，通话确实停止了。但是，我们现在看到了大约 200–250KiB 的流量。仍然不是很好的质量。

【解决方案1】：

以上方案来自this article我写的关于这个话题的很多细节。

简而言之，问题可能出现在 3 个步骤中的任何一个中：

我会这样做：

在 320x240 等限制条件下使用较低的最小分辨率，这将确保没有简单的可避免getUserMedia() errors
确保信号通过端口 80 或 443 完成
在许多情况下，对等点无法与 STUN/TURN 服务器通信，因此请尝试使用 TCP (stun:stun.l.google.com:19302?transport=tcp) 和端口 80（默认为 UDP 端口 3478 或 19302）与 STUN/TURN 通信Google 的 STUN，它们可能被您的路由器/防火墙/代理/移动网络阻止）
在 LTE/WiFi 设备上使用TrickleICE（与您自己的 STUN/TURN）和WebRTC Troubleshooter，您将了解很多关于如何将它们连接到到

【讨论】：