Know Where to ‘TURN’ When Deploying WebRTC
Eric Lagerway
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 减少通话设定时间
