作者：Rafael Viscarra（原文链接）
翻译：刘通
原标题：A Guide to: WebRTC Media Servers & Open Source Options
WebRTC生态系统非常的庞大，所以有的时候对于新手来说可能会有点吓人。当我最初尝试了解WebRTC的时候，我记得遇到了好多好多缩略词。本篇文章将提供一个WebRTC媒体服务器的指南，并且提供一些开源代码的供读者选择，比如kurento，janus，jitsi.org等等。我还将努力降低理解WebRTC价值所必需的技术门槛。
什么是WebRTC服务器？
自从WebRTC诞生之初，该技术的主要卖点之一就是它允许端到端（浏览器到浏览器）通信，几乎不需要服务器的干预，通常服务器只会用于信令。这就是为什么WebRTC媒体服务器的概念可能自相矛盾。
接下来，我将要阐述为什么媒体服务器是有用的，他们通常提供什么类型的功能，以及用户有哪些开源替代品可以选择。
多人参与的视频通话
尽管可以使用对等通信（图一所的网状结构）与多个参与方保持视频通话，但随着参与者数量的增加，这件事情的可行性会越来越低。因为这要求每个对等端都将他/她的音视频流发送给每个对话参与者，同时还要接受从每个参与者处传来的音视频流。
现实情况中，即便是处在最优的网络环境下，参与人数超过了5人之后，网状结构的视频通话就很难良好地运行了。这就是媒体服务器派上用场的地方，因为它可以有助于减少客户端需要发送的数据流数量，甚至可以减少客户端需要接收的数据流数量，这取决于媒体服务器的功能。
当一个媒体服务器作为这种媒体中继时，通常称为SFU（Single Forwarding Unit，单向转发单元），主要目的是在客户端之间转发媒体流。
还有一个MCU（Multipoint Conferencing Unit，多点会议单元）的概念，它用于寻址一个媒体服务器，它不仅可以进行转发，还可以在通过它的媒体流上操作（比如将所有视频或者音频流混合成一个）。
视频录制
让所有视频流都通过一个媒体服务器的主要好处之一是我们可以录制媒体并且存储下来以备它用，比如一些在网格结构中非常难完成的事情。
与其他通信技术的整合
使用媒体服务器的另一个优势是可以与超出网页技术允许范围内的系统相通信，比如说通过SIP中继与PSTN进行通信，或者穿过RTMP流传输到支持它的服务中，比如Facebook Live和YouTube流直播。
媒体流的处理
一些媒体服务器允许以非常低的水平处理音视频流，比如能够在视频上运行机器视觉模型，或者将音频流发送给语音识别引擎，就像Google Speech一样。这些功能将WebRTC提升到了另一个层次；在我看来，它允许在一个普通的通信平台上添加更丰富和创新的互动，会大大提升它的价值。
有哪些开源媒体服务器可以选择使用？
正如上文提到过的，WebRTC生态系统是非常庞大的，在市场上有一些开源产品可以选择。
下面是一些最成熟/最知名的产品：
Jitsi不仅是一个WebRTC媒体服务器，而且还是一个围绕其搭建的完整的平台。Jitsi的产品家族包括了Jitsi Videobridge（媒体传输，SFU），Jitsi Meet（会议网络客户端），Jicofo（Jitsi会议焦点），Jitsi SIP电话等等。Jitsi平台最吸引人的特点是它包含了一个交流平台的一切，可以在几个小时内就启动和实现运行。它还使用了Jingle（XMPP）和全功能的Web界面实现自己的信号传输。遗憾的是，最大的缺点就是实施媒体录制，因为Jitsi没有可靠的，易于使用的解决方案。
这是目前最通用的解决方案之一。它不仅仅是一个媒体服务器，还是一个用来搭建媒体服务器的工具箱。Kurento的主要优势在于它的多功能性，通过引入媒体工作流的概念允许在代码中定义媒体要如何进行流动，以及向哪里流动。这使得WebRTC开发者能够编写和集成注入机器视觉（例如二维码扫描，人脸识别），实时媒体修改，以及与RTP（VoIP）服务互操作的非常有趣的特性。Kurento在一个实例中也可以配置充当SFU或者MCU，或者两者。
尽管在它的描述中没有任何地方提到“媒体服务器”，但是Janus可以很容易地就被设置为一个SFU。其最显著的特点之一是它的插件架构，可以增强服务的核心功能。在这个demo页中，展示了Janus的一些有趣的用例。
这是一个相对较新而且比较有趣的媒体服务器，与其他媒体服务器不同的是，它被设计为一个库（用于Node），允许它集成到更大的应用程序中去。
结语
希望这篇文章能够帮助你揭开WebRTC媒体服务器的神秘面纱，解释它们提供的功能，并且提供一些可用的开源选项。
