标签：fackbook guide 概念 -o 插件架构 工作流 work ide 其他
WebRTC生态系统是非常庞大的。当我第一次尝试理解WebRTC时，网络资源之多让人难以置信。本文针对webRTC媒体服务器和相关的开源项目（如kurento，janus，jitsi.org等）做一些介绍。并且将尝试降低理解WebRTC的业务价值所需要的技术门槛。
自从WebRTC诞生之初以来，该技术的主要卖点之一是它可以进行点对点（browser-to-browser）通信，而几乎不需要服务器的干预，服务器只用来发送信令。WebRTC媒体服务器的概念同p2p相比是相反的。
下面，我将试图说明为什么媒体服务器是有用的，他们通常提供什么类型的功能以及相应的可供用户使用的开源方案有哪些。
尽管确实可以使用p2p通信（图1网格体系结构）来让多点用户保持视频通话，但随着用户数量的增加，此方案变的不再实际，因为需要一个用户将他/她的视频/音频流传输给其余每个用户，同时接收其余每个用户的视频/音频流。
事实上，即使在最优的网络条件下，正常的mesh视频通话也不能超过5个用户。这是媒体服务器派上用场的地方，因为它可以减少客户端需要发送的流的数量，同时也能减少客户端需要接收的流的数量，其效果取决于媒体服务器性能。
当一个媒体服务器充当这种中间人的角色时，它通常被称为SFU（单一转发单元 Single Forwarding Unit），这也就意味着它的主要目的是在客户端之间转发媒体流。
还有一个MCU（多点会议单元 Multiponit Conferencing Unit）的概念，这样的服务器不仅仅能够转发媒体流，也能对通过它的媒体流进行处理（例如，将所有视频或音频流混合为一个）。
让所有视频流通过媒体服务器（群集）的主要好处之一是可以对媒体流进行出于任何目的的录制和存储，这在mesh架构上很难做到。
使用媒体服务器的另外一个优点是能够同web系统之外的其它系统进行通信，例如通过SIP中继的PSTN或者通过RTMP进行流传输的服务（像Fackbook直播或者Youtube直播流）。
你可以看到之前博客的一个实例，在此实例中Kurento媒体服务器用来在浏览器和SIP电话之间进行视频通话。
一些媒体服务器允许对视频和音频流做底层上的处理，比如能够在视频上运行计算机视觉模型或者将音频流发送到语音识别引引擎，例如google Speech。这些功能将webrtc提升到另外一个层次。依我看来，它提供了更加丰富和创新性的实时交互，为一个普通的通信平台增加了很多价值。
我们之前讨论过此问题，Kurento媒体服务器将人脸识别模型应用到了视频流上，在人的头上戴了一顶帽子。
如前所述，WebRTC生态系统非常庞大，市面上由很多开源项目。
下面是最成熟和受欢迎的：
Jitsi不仅仅是一个WebRTC媒体服务器，而是围绕者webrtc构建了一整个平台。 Jitsi系列产品包括Jitsi Videobridge（媒体中继，SFU），Jitsi Meet（会议web客户端），Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）和Jitsi SIP Phone。 Jitsi平台最吸引人的特性是它包含了在数小时内启动和运行的通信平台的所有功能。它还使用Jingle（XMPP）和功能齐全的Web interface实现了自己的信令。遗憾的是，它没有一个稳固易用的媒体录制功能实现。
这是最通用的解决方案之一。它也不仅仅是一个媒体服务器，而是构建了一个工具包。
Kurento的主要优点是通过引入媒体工作流(meidia workflow)的概念实现了多功能性，它允许在代码中定义媒体流以何种方式传输以及传到到哪里。这就允许WebRTC开发者将非常有趣的功能进行集成，例如计算机视觉（例如识别QR码，面部检测），实时媒体修正和与RTP（VoIP）服务的互操作。 Kurento还可以在单个实例中配置成SFU或MCU（或者同时使用）。
虽然它的描述中没有提到“meidia server”，但Janus可以很容易地将SFU设置为SFU。其最显着的特征之一是其插件架构，可以增强服务的核心功能。有一个演示页面，显示了一些有趣的Janus用例，例如SIP Gateway，屏幕共享等。
一个相对较新且有趣的媒体服务器，它与其他媒体服务器的不同之处在于它被设计为一个Library（用于Node），允许它集成到更大的应用程序中。
揭开webRTC媒体服务器的神秘面纱——WebRTC媒体服务器&开源项目介绍
标签：fackbook guide 概念 -o 插件架构 工作流 work ide 其他
原文地址：https://www.cnblogs.com/harlanc/p/9261484.html
