5

ICE重启

已有 1,871 阅读此文人 - - NAT穿透 -

原作者:Philipp Hancke(原文链接

翻译:刘通

 

         我之前写过一篇关于ICE失败的文章。那时候我只是分析了初始化时候的失败,并没有讨论通话建立成功之后发生的ICE失败。现在我们来探讨一下 ICE重启的问题。

ice1

         当WebRTC连接失败的时候,我们可以看到 ICE连接状态也发生了改变。你可以加入一个事件监控:

ice2

         对于我们来说,iceConnectionState的值中我们所感兴趣的是disconnected和failed。简单的来说,disconnected是指连接被中断,但是还有可能不做任何工作就又可以重新连接。Failed状态更像是一个持续的错误状态,你需要将 ICE重启才能解决这个问题。通常,当连接中断的时候, ICE连接状态先是变成disconnected,过一段时间状态会变为failed。

         当 ICE连接状态变成failed之后你就可以进行 ICE重启了。这意味着你需要收集新的候选项,将他们送至对等端然后从对等端继续收集新的候选项。希望这样就可以把连接重新建立起来,如下面代码所示(点击查看完整示例):

ice3

         你会注意到SDP中的ice-ufrag和ice-pwd属性发生了改变。将其发送给对等端,之后对等端将会用这些变了的参数产生新的应答。

         我的同事Dag-Inge今年三月进行了了 ICE重启测试,只要一开始 ICE重启Firefox 浏览器就是闪退。

         但是我们从未对 ICE重启工作以及产生的冲击进行过任何评测。首先,让我们设定一个常见的100k的数据集。

ice4

         然后,我们需要看 ICE是否进行了重启。可以通过观察iceRestart的createOffer通话来实现。

ice4_2

         从上图我们可以看出大约8.7%的连接进行了 ICE重启的尝试。通过几个月的观察,我们发现这个比例大约维持在7.5%。

         这些数据说明了没有 ICE重启功能就提供WebRTC服务不是一个好主意,即使是这样用户也可能只是选择刷新整个网页来起到重启 ICE的作用。不幸的是,现在网上没有多少写 ICE重启的文章,希望本文章能够对你们起到一点作用。

         所以我们有8.7%的通话进行了 ICE重启。现在我们需要查看一下他们是否进行了任何修改。我们通过观察oniceconnectionstatechange的值是connected还是completed来决定 ice重启是否成功:

ice5

         上图表示大约有三分之二的 ICE重启重新建立了连接,意味着更高的通话成功率和更好的用户体验!

         但是仍有30%的失败率让人很担忧,我们能解释其产生的原因吗?大多数情况造成这些连接失败的原因是远端用户离开了。我们可以通过检查在createOffer之后是否产生了一个相应的setRemoteDescription调用来监测是否发生了上种情况。如果没有出现调用,说明远端用户已经失去了信令连接(可能他们已经把页面关闭了),或者没有运行 ICE重启:

ice6

         所以在不成功的 ICE重启之中有85%的情况我们无法从对等端哪里获得新的应答。可能意味着他们已经不再与信令服务器有任何连接了。他们可能已经关掉了网页,或者(几率没有前者大)意味着他们的浏览器版本不能够实施 ICE重启;Firefox最近才能在47版本中进行这项工作。这种情况除了给用户弹出提示框说明连接失败以外没有什么更好的办法了。

         剩下的400个实例需要进行更深入详细的调查,在其中肯定是存在一些bug的。当然如果对更大量的信令失败进行统计的话,发现bug的几率会增加,但是工作的优先级可能不允许你这么干。。。

         既然我们把 ICE重启视为改善WebRTC服务质量的一个重要因素。 ICE重启也是当用户的网络连接情况从WiFi切换到移动流量而产生的问题的解决方案。最近我们也发现Google的Duo可能不会用 ICE重启,而会选择持续指派的方法来解决连接失败的问题。





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

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