0

作者:Sam Dutton(原文链接)

翻译:刘通

原标题:WebRTC in the real world: STUN, TURN and signaling

前文链接:实际中的WebRTC:STUN,TURN以及信令(一)实际中的WebRTC:STUN,TURN以及信令(二)实际中的WebRTC:STUN,TURN以及信令(三)实际中的WebRTC:STUN,TURN以及信令(四)

 

STUN

NAT给设备提供了一个IP地址以使用专用局域网,但是这个地址不能在外部使用。由于没有公用地址,WebRTC对等端就无法进行通信。而WebRTC使用 STUN来解决这个问题。

STUN服务器位于公共网络上,并且有一个简单的任务:检查传入请求的IP地址(来自运行在NAT后面的应用程序),并将该地址作为响应发送回去。换句话说,应用程序使用 STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址,然后通过信令机制将其传递给另一个对等端以建立直接链接。(实际上不同NAT工作方式都有所不同,可能有多个NAT层,但是原理是一样的)。

因为 STUN服务器不需要做太多的工作或者记特别多的东西,所以相对低规格的 STUN服务器就可以处理大量的请求。

根据webrtcstats.com的统计(2013年),大多数WebRTC通话都成功地使用 STUN进行连接,有86%。尽管对于防火墙之后的对等端之间的呼叫以及复杂的NAT配置,成功通话量会更少一些。

real51

TURN

RTCPeerConnection尝试通过UDP建立对等端之间的直接通信。如果失败的话,RTCPeerConnection就会使用TCP进行连接。如果使用TCP还失败的话,可以用 TURN服务器作为后备,在终端之间转发数据。

重申: TURN用于中继对等端之间的音频/视频/数据流,而不是信令数据。

TURN服务器具有公共地址,因此即使对等端位于防火墙或代理之后也可以与其他人联系。 TURN服务器有一个概念上来讲简单的任务—中继数据流—但是与 STUN服务器不同的是,他们会消耗大量的带宽。换句话说, TURN服务器需要更加的强大。

real52

上图显示了 TURN的作用:单纯的 STUN没有成功建立连接,所以每个对等端还需要使用 TURN服务器。

部署 STUNTURN服务器

为了进行测试,Google运行了一个公共 STUN服务器 stun.l.google.com:19302,就是apprtc.appspot.com所使用的那样。对于产品的 STUN/ TURN服务,我们推荐使用rfc5766-turn-server; STUNTURN服务器的源代码可从code.google.com/p/rfc5766-turn-server获得,该代码还提供了有关服务器安装的多个信息源的链接。Amazon Web Services的VM映像也可用。

另一个 TURN服务器是restund,可用作源代码,也可用于AWS。以下是如何在Google Compute Engine上设置restund的说明。

         1. 根据需要打开防火墙,对于tcp = 443,udp/tcp = 3478

         2. 创建四个实例,每个公共IP标准一个,Standard Ubuntu 12.06映像

         3. 设置本地防火墙配置

         4. 安装工具:

                   sudo apt-get install make

                   sudo apt-get install gcc

         5. 从creytiv.com/re.html安装libre

         6. 从creytiv.com/restund.html获取并解压缩restund

         7. wget hancke.name/restund-auth.patch并且使用patch – p1

         8. 对libre和restund运行make, sudo make install

         9. 根据你的需要(替换IP地址并确保它包含相同的共享密钥)对restund.conf进行调整,并复制到/etc

         10. 复制restund/etc/restund到/etc/init.d/

         11. 配置restund:

                   设置LD_LIBRARY_PATH

                   复制restund.conf到/etc/restund.conf

                   设置restund.conf以使用正确的 10. IP地址

         12. 运行restund

         13. 从远端机上使用社团的客户端进行测试:./client IP:port

多方WebRTC

你可能还想查看一下Justin Uberti提出的用于访问TURN服务的REST API的IETF标准

很容易想象媒体流的使用情况超出了简单的一对一呼叫:例如,一组同事之间的视频会议,或一个发言者和数百(数百万)个关公的公共事件。

WebRTC应用程序可以使用多个RTCPeerConnection,以便每个端点都可以连接到网格配置中的每个其他端点。这是talky.io等应用程序所采取的方法,对于值有少数几个对等端的情况来说可以很好的工作。除此之外,处理和带宽会过度消耗,对于移动客户端来说尤其是这样。

real53

或者,WebRTC应用程序可以选择一个端点以星形配置将流分配给所有其他端点。也可以在服务器上运行WebRTC端点并构建自己的重新分配机制。(webrtc.org提供了一个客户端应用示例

从Chrome 31和Opera 18开始,来自一个RTCPeerConnection的MediaStream可以用作另一个的输入:在simpl.info/multi上有一个演示。这可以启用更灵活的体系结构,因为它使Web应用程序能够通过选择要连接的其他对等端来处理呼叫路由。

多点控制单元

大量端点情况的更好选择是使用多点控制单元(Multipoint Control Unit,MCU)。它是一个服务器,可以作为在大量参与者之间分发媒体的桥。MCU可以处理视频会议中的不同分辨率,编解码器和帧速率,处理转码,选择性流转发,混音或录制音频和视频。对于多方通话,需要考虑许多问题:特别是如何显示多个视频输入并混合来自多个来源的音频。

你可以购买一个完整的MCU硬件包,或者建立自己的MCU。

real54

有几个开源的MCU软件可供选择。比如说,Licode为WebRTC做了一个开源MCU;OpenTok也有Mantis

除了浏览器以外还有:VoIP,电话和消息

WebRTC的标准化特性使得在浏览器中运行的WebRTC应用程序与另一个通信平台运行的设备或停牌(例如电话或视频会议系统)之间建立通信成为可能。

SIP是VoIP和视频会议系统使用的信令协议。为了实现WebRTC应用程序与视频会议系统等SIP客户端之间的通信,WebRTC需要代理服务器来调解信令。信令必须通过网关流动,但一旦通信建立,SRTP流量(视频和音频)就可以直接流向对等端。

公共交换电话网(PSTN)是所有“普通老式”模拟电话的电路交换网络。对于WebRTC应用程序和电话之间的通话,通信必须通过PSTN网关。同样,WebRTC应用程序需要中间的XMPP服务器来与Jingle端点(如IM客户端)进行通信。Jingle由Google开发,作为XMPP的扩展,为语音和视频提供消息传递服务:当前的WebRTC实现是基于C++ libjingle库的,这是一个最初为Google Talk开发的Jingle实现。

许多应用程序,库,和平台利用WebRTC与外部世界的沟通能力:sipML5,jsSIP,Phono,Zingaya,Twilio和Uberconference等等。

sipML5开发者也构建了webrtc2sip网关。Tethr和Tropo展示了一个在灾难通信框架,使用OpenBTS单元通过WebRTC实现手机和计算机之间的通信。这是一个没有运营商在中间的电话通信!

(本文终)



期待你一针见血的评论,Come on!

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