我前一段时间在与老朋友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失败，并且存在我们在上文中没有提到的其他潜在失败原因，这些可能也会阻挠端到端音视频通信的连接。
