在部署WebRTC的时候什么时候使用TURN

12%，这就是Callstats.io的CEO Varun Singh，告诉WebRTC Conference-in-Conference大会上的听众WebRTC通话失败的比例。对于那些失败的通话，有22%的通话需要某些形式的媒体传输。造成12%这个比例的主要原因是因为网络工程师们没有考虑到NAT防火墙穿透，当搭建很多RTC网络的时候，这是对企业部署十分重要的。

关于NAT和防火墙穿透

NAT一直以来都是VoIP服务质量的破坏者，因为它会改变VoIP设备所需要寻址访问的IP地址和端口。与此同时，为了安全起见，一些防火墙会阻挡某些类型的传输。但是NAT穿透和媒体传输产品使得VoIP和WebRTC数据包能够穿透多数的企业防火墙。

简单地说，这就意味着用户可以连接并听到另一端使用者所说的话了—对其自己来说将NAT穿透作为你企业WebRTC或者UC网络设计战略的一部分也是十分有说服力的原因。传统方式是通过会话边缘控制器（SBCs）来完成，但是WebRTC已经接收了其他技术—STUN，TURN，以及ICE。

这些技术允许端点之间互相通信，通常都是直接通信而不通过SBCs这种又贵又要求高质量的的设备。STUN，将公共IP地址锚定回端点。TURN，当端到端连接不能被建立的时候会像轻量的媒体传输一样工作。ICE，是一个绑定了本地地址、STUN和TURN的框架，来寻找最佳的可能连接方式。

ICE是嵌入在WebRTC之内的。STUN服务器是轻型的，而且准备提供免费试用。TURN服务器，相反的，可以根据你对其的使用方式，可以处理大量的媒体。TURN需要你设定一个独立的服务器，或者使用TURN服务，并且不是免费提供的。

为WebRTC部署TURN

现在已经知道了NAT穿透必须作为网络设计的一部分，你需要考虑如何在你的网络中实现它，以及打造最好的用户体验度。

这可以总结为下面两个关键点：

#1 将延迟控制到最小

#2 减少通话设定时间

延迟最小化

遵循下面几点减少数据包从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检查

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

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