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

Know Where to ‘TURN’ When Deploying WebRTC

Eric Lagerway

Lagerway_0606-WebRTC-2

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 减少通话设定时间

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

WebRTC 中文社区由

运营