作者：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配置，成功通话量会更少一些。
TURN
RTCPeerConnection尝试通过UDP建立对等端之间的直接通信。如果失败的话，RTCPeerConnection就会使用TCP进行连接。如果使用TCP还失败的话，可以用TURN服务器作为后备，在终端之间转发数据。
重申：TURN用于中继对等端之间的音频/视频/数据流，而不是信令数据。
TURN服务器具有公共地址，因此即使对等端位于防火墙或代理之后也可以与其他人联系。TURN服务器有一个概念上来讲简单的任务—中继数据流—但是与STUN服务器不同的是，他们会消耗大量的带宽。换句话说，TURN服务器需要更加的强大。
上图显示了TURN的作用：单纯的STUN没有成功建立连接，所以每个对等端还需要使用TURN服务器。
部署STUN和TURN服务器
为了进行测试，Google运行了一个公共STUN服务器stun.l.google.com:19302，就是apprtc.appspot.com所使用的那样。对于产品的STUN/TURN服务，我们推荐使用rfc5766-turn-server；STUN和TURN服务器的源代码可从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 < restund-auth.patch
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等应用程序所采取的方法，对于值有少数几个对等端的情况来说可以很好的工作。除此之外，处理和带宽会过度消耗，对于移动客户端来说尤其是这样。
或者，WebRTC应用程序可以选择一个端点以星形配置将流分配给所有其他端点。也可以在服务器上运行WebRTC端点并构建自己的重新分配机制。（webrtc.org提供了一个客户端应用示例）
从Chrome 31和Opera 18开始，来自一个RTCPeerConnection的MediaStream可以用作另一个的输入：在simpl.info/multi上有一个演示。这可以启用更灵活的体系结构，因为它使Web应用程序能够通过选择要连接的其他对等端来处理呼叫路由。
多点控制单元
大量端点情况的更好选择是使用多点控制单元（Multipoint Control Unit，MCU）。它是一个服务器，可以作为在大量参与者之间分发媒体的桥。MCU可以处理视频会议中的不同分辨率，编解码器和帧速率，处理转码，选择性流转发，混音或录制音频和视频。对于多方通话，需要考虑许多问题：特别是如何显示多个视频输入并混合来自多个来源的音频。
你可以购买一个完整的MCU硬件包，或者建立自己的MCU。
有几个开源的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实现手机和计算机之间的通信。这是一个没有运营商在中间的电话通信！
（本文终）
