WebRTC调用在我们的应用程序中不可靠。有时我们会看到黑屏,有时我们根本看不到调用开始,有时会看到巨大的延迟或音频/视频不同步。
设定:
- 谷歌的公共STUN服务器
stun:stun.l.google.com:19302
; - TURN服务器是
Coturn
托管在docker中的azure; - 信令服务器是使用express作为web服务器的定制https://github.com/andyet/signalmaster
- 客户端使用JS,客户端为
simplewebrtc
; - 对于iOS支持,使用Cordova插件-https://github.com/eface2face/cordova-plugin-iosrtc
几乎100%重现的问题是从LTE上的一个客户端呼叫到Wi-Fi上的另一个客户端。在这种情况下,我们在两个设备上都看到黑屏,但是,默认的背景颜色是白色,所以至少在WebRTC端发生了一些事情。
为解决问题采取了哪些措施:
- 检查Coturn日志...有时我们会看到“未授权”错误,但很难说它们是否会影响任何东西;
- 已检查Coturn的流量:在Wi-Fi到Wi-Fi的场景中,它很低,因此真正实现了点对点连接。如果有LTE,我们看到大约40- 120 KiB/秒的负载(这对于音频/视频来说是不是太低了?),所以TURN似乎可以工作;
- 检查了客户端应用程序日志,没有什么特别的;
请建议任何可能的研究或修复方法,以使WebRTC尽可能可靠。
1条答案
按热度按时间z8dt9xmd1#
上面的方案来自于我写的this article,它详细介绍了这个主题。
很快,以下3个步骤中的任何一个步骤都会出现问题:
1.发信号
1.使用STUN/TURN发现
1.对等连接
"我会这么做"
1.在限制条件下使用较低的最小分辨率,如320 x240,这将确保没有简单的getUserMedia() errors
1.确保通过端口80或443发送信号
1.在许多情况下,对等端无法与STUN/TURN服务器 * 通信 *,因此请尝试使用TCP(
stun:stun.l.google.com:19302?transport=tcp
)和端口80与STUN/TURN通信(对于Google的STUN,默认为UDP端口3478或19302,它们可能会被您的路由器/防火墙/代理/移动的网络阻止)1.在LTE/WiFi设备上使用TrickleICE(带有您自己的STUN/TURN)和WebRTC Troubleshooter,您将了解到有关如何将它们连接 * 到 * 的大量信息