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

Question

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

设定：

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

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

如何解决问题：

• 已审核的Coturn日志...有时我们会看到＆＃34;未经授权的＆＃34;错误，但很难说它们是否会影响任何事情;
• 检查了Coturn的流量：在Wi-Fi到Wi-Fi的情况下，它很低，因此真正建立了点对点连接。如果有LTE，我们看到大约40-120KiB /秒的负载（Isn＆＃39; t对音频/视频来说太低了？），所以TURN似乎有效;
• 检查客户端应用日志，没什么特别的;

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

Answer 1

上述方案来自我写的this article，其中详细介绍了该主题。

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

1. 信令
2. 使用STUN / TURN发现
3. p2p连接

以下是我要做的事情：

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