有奖小调查

3 分钟回答 几 个小问题,让内容更符合你的 WebRTC 学习与开发期望。
每个月最后一天会随机抽出 5 名获奖者,并通过邮件联系送上奖品。
填写问卷

在部署WebRTC的时候要知道什么时候转方向(使用TURN)二

延迟最小化

遵循下面几点减少数据包从A到B传输的时间可以增加通话质量。

传输POP的地理距离

当我们讨论传输的时候,必须注意这些事情:出于传输POP的原因要知道用户在哪里,我们在POP之间用什么做回程,以及当质量受影响之后该怎么处理。举个例子:

# Alice在波士顿想要打电话给在香港的Bob

# Bob的防火墙限制VoIP数据流,所以他需要使用TURN服务器

# 所使用的TURN服务器在德克萨斯

在上面这个例子中,通话需要一路传到德州来进行连接,这就增加了延迟也破坏了通话质量。如果TURN网络已经连入了德国和纽约,那么系统就需要对比这些不同地点之间的端到端延时,来选择一条延时最低的线路。通常都是连入最近的点,但是不是所有的情况都这样。地理上分布开的TURN网络会给出更多的低延时选择。

传输回程线路

下一个问题是,“传输通信数据如何到其他传输POP端,以及之后如何到达远端用户这个终点?”一个词来回答就是“回程(backhaul)”。我们需要一个快速的,能回复的,以及倾向使用私人网络连接这些POP。

服务质量(QOS)以及监控

我们可以依靠一些机器学习的知识来更进一步,帮助数据流实时选择最佳的路径。当通话进行的时候,我们知道通话延时的基准是200毫秒左右。如果我们发现通话延时超过了上限,比如超过了500毫秒,我们就可以切换到一条更快的传输线路来确保服务质量是可接受的。

通话建立时间

实施TURN可以帮你降低通话失败,未完成的通话建立,以及半双工语音的几率,那通话建立时间怎么办呢?过长的通话建立时间会让使用者对你服务的信心极大的降低。如果通话花了几秒或更长的时间来建立,你就会收到大量的投诉和抱怨,或者更坏的情况—用户会不再使用你的服务,而你永远都不会知道原因。

ICE过程会占用很多的时间。幸运的是,WebRTC包含像Trickle ICE这样的技术在整个ICE过程完成前就开始通话开始流程。但还是,只是启动ICE流程也会占用一些时间。还好,有一些其他的手段可以帮助这一过程加快速度。

TURN优先

TURN优先,或者传输优先,很快的成为了可以帮助你降低过长通话设立时间的方法,这样你的用户就不会在使用过程中卡住了。简单来说,它是这样工作的:

# 建立一个通话最快的方式是通过一条已知的路线

# 我们所知道的最优路线是Relay/TURN

# 在通话还在处理过程中的时候,我们就进行ICE检查

# 如果通话可以从端到端传输,那么当路线确定后,网络服务会重新路由数据包

现在我们已经可以尽可能的快速建立通话,而且我们没有浪费一丁点时间在寻找最佳路线上。

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营