cordova - 如何修复不可靠的 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. p2p连接

这是我要做的：

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 故障排除程序，您将了解很多有关如何连接它们的知识