1

真的有12%的WebRTC通话都失败了?

已有 1,394 阅读此文人 - - 行业解读 -

Gustavo Garcia Bernardo

我前一段时间在与老朋友Philipp Hancke聊天,谈到了这个话题,怎么可能有12%的WebRTC通话都失败了呢?我们看到这个数字之后很惊讶,基于我们的报告,OpenToken的通话失败率要比12%低的多,即便这样准确的数字也是根据每次通话的特定情况而决定的。

所以,我们决定拿出一些数据来证明WebRTC比他们所说的要好的多。

WebRTC连接使基于ICE框架的。通过使用 ICE,浏览器集中他们的IP和尝试与远端WebRTC端点建立连接。他们通过分享地址来完成这项工作,并且检验是否存在任何本地-远端组合为特定的网络状况工作。

分析WebRTC的数据组

数据组

首先,你需要大量的通话来收集数据。我们收集了100,000次仅在我们产品上进行的通话。数据采集只是在基于网页的通信之上,而且集合了一对一以及多方通话情况。

我们包括了完成 ICE建立成功与否的通话,忽略了哪些根本没有进行 ICE建立的通话,这些通常是因为在建立过程中用户就关闭了浏览器所造成的。结果如下:

成功:74,455

失败:1,541

从上述数据我们可以看出,2.0%的通话“失败”了。这比那篇文章中所说的12%要可接受的多。

让我们探讨一下这些失败的原因和类型。

我们对 ICE失败的定义是“ ICE连接的状态是否变为失败”。我们确实注意到了 ICE失败率在去年12月份Chrome 47版本中大幅度的增加。这个问题现在还没有被解决,但是既然我们已经知道了这点,我们就可以只选择那些 ICE连接状态根本没有连接或完成的情况。

但是等一下,我们需要区分那些真正工作的通话,和那些在完成连接之后 ICE状态才变成“失败”的通话。

成功:74,455

未连接:1,349

连接失败:192

所以,只有0.2%的OpenTok通话遇到了那篇文章里所提到的真正的连接失败。

但还是,这些 ICE失败的例子中有多少是可以解释的,例如用户的网络阻拦了TURN服务器的接入?我们在API层收集数据,这样更容易决定要收集哪些数据。

介于我们大多数的通话都是基于SFU的,而且SFU有公共地址,其中最相关的一个特征就是判定浏览器是否能够收集 TURN候选。

失败的w/o TURN候选:147

失败的w TURN候选:45

所以我们可以看出,大部分的失败是在浏览器不能收集 TURN候选。一个通常会遇到的情况是某个代理需要授权,这会成为企业环境的一个问题。Chrome 浏览器并没有完全地实施这些,我们认为修改好439560号错误可以在这些情况中起到帮助的作用。在使用Firefox 浏览器的情况中,存在一个额外的限制,原因是缺少需要通过企业代理的 TURN TLS支持。有趣的是所有这些TLS之上的WebSocket都是工作的。这是因为 TURN和WebSocket堆栈使用的是不同限制的不同代码库。

还有45个失败的通话(0.05%)是无法解释的,没有找到原因。这可能是因为错误的log,我们SFU之中的bug,或者一些我们所不知道的原因,但无论怎样,这些都只占很小很小的一部分。

以上是的我们通话结果的统计和分析,需要记住的是,我们所处理的是 ICE失败,并且存在我们在上文中没有提到的其他潜在失败原因,这些可能也会阻挠端到端音视频通信的连接。





加入WebRTC技术交流群,免费获得学习资料,交流经验
群号:659922087
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.