​​STUN​​

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

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

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

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

​实际中的WebRTC：STUN，TURN以及信令（五）_服务器​

​​TURN​​

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

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

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

​实际中的WebRTC：STUN，TURN以及信令（五）_应用程序_02​

上图显示了 ​​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

         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：STUN，TURN以及信令（五）_应用程序_03​

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

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

多点控制单元

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

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

​实际中的WebRTC：STUN，TURN以及信令（五）_服务器_04​

有几个开源的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实现手机和计算机之间的通信。这是一个没有运营商在中间的电话通信！