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

Question

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

设置：

• 谷歌的公共 STUN 服务器stun:stun.l.google.com:19302；
• TURN 服务器Coturn托管在 docker 中的 azure 中；
• 信令服务器是一个定制的https://github.com/andyet/signalmaster，使用 express 作为 web 服务器
• 在客户端使用 JS，simplewebrtc作为客户端；
• 对于 iOS 支持使用 Cordova 插件 - https://github.com/eface2face/cordova-plugin-iosrtc

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

为解决问题做了哪些工作：

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

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

Answer 1

上面的方案来自我写的这篇文章，其中详细介绍了这个主题。

很快，以下 3 个步骤中的任何一个都可能出现问题：

1. 信令
2. 使用 STUN/TURN 进行发现
3. 点对点连接

这就是我要做的：

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