创建生产就绪的 WebRTC 视频通话应用：开发人员的 5 个考虑因素

实时视频通话正在彻底改变我们与全球各地人们的互动方式。但视频通话不仅仅是实时视频。将通信集成到工作流程中以实现特定目标——使其与日常工作相关——至关重要，而 WebRTC 是实现这些目标的一种经过验证的平台。

与独立的通信平台 Skype 不同，WebRTC 是一项开源技术，它允许将实时通信功能（如实时视频通话）直接添加到浏览器应用程序和网站中。它是一组易于集成的 JavaScript API，无需处理使用时必需的下载或插件的内在复杂性。

在您开始独立使用 WebRTC 之前，需要考虑一些问题并了解一些问题，尤其是在部署大规模视频通话应用程序时。

我需要媒体服务器吗？

如果您只需要将两个人或三个人连接到视频通话，则不需要媒体服务器——但这假设他们处于高速、不拥挤的网络上。一旦您从一对一视频会话转向两个以上参与者，或者预计会有大规模的网络研讨会或广播，分发和延迟等问题就会出现。而且，当您想要添加录制、转码和将通话连接到 PSTN 等功能时，负担会增加。

这是因为 WebRTC 构建在点对点（网状）拓扑之上。会话中的每个参与者都直接与其他参与者连接。当参与者数量增加时，在所有参与者之间维护直接连接（包括编码和解码）会消耗大量 CPU 资源且不可持续（请参阅下图）。因此，视频通话的质量会下降（表现为视频冻结和声音问题）。

基于服务器的拓扑，如选择性转发单元 (SFU) 或多点控制 (MCU)，可以帮助解决这些限制。

用于可扩展性的基于服务器的拓扑

基于 SFU 的拓扑在计算上要求较低。它不需要转码和混合，因此更具可扩展性和经济性。每个参与者将其视频流发送到服务器。然后，服务器将这些流（以数据包形式）转发给其他参与者（其他订阅者的浏览器）。这减少了带宽要求，因为它最大限度地减少了每个参与者的上行带宽需求。此外，有了服务器，开发转码、录制和会话发起协议 (SIP) 集成等其他功能会更简单（稍后将讨论）。

附加提示：为长远打算：即使您当前的需求仅为一对一通话，也要确保您的实现能够轻松扩展到未来。WebRTC 堆栈没有 QoS 保证，当用户在受限网络上时，WebRTC 需要 TURN 服务器来进行点发现。

如何优化带宽？

假设您决定使用 SFU。您可能还想引入 simulcast。在带宽不成问题的完美情况下，所有参与者都将使用高质量的 720p 视频分辨率，每位参与者需要 1.5Mbps。在下面的示例中，会话中的每个参与者发送 1.5Mbps 并接收三个 1.5Mbps 的流。在四方通话中，媒体服务器需要接收 6Mbps 并发送 18Mbps。

分辨率	720p (1.5 Mbps)
个人用户（出站）	1.5Mbps（1 个流）
个人用户（入站）	4.5Mbps（3 个流）
SFU（出站）	18Mbps（12 个流）
SFU（入站）	6Mbps（4 个流）

实际上，为每个参与者提供持续的高带宽是不太可能的——随着参与者数量的增加更是如此。在多带宽场景中，如果没有 simulcast，SFU 将从每个参与者那里接收有关其网络连接的反馈，并以最低比特率进行流式传输，以确保所有会话中的参与者都能看到内容。这明显的问题是，一个参与者的流可能会降低所有参与者的质量。

Simulcast 优化的视频质量

另一方面，Simulcast 是一种机制，通过该机制，设备可以发送包含多个比特率的视频流。

通过 simulcast，用户/客户端会将视频编码成多种不同的比特率。然后，SFU 会接收这些视频流，SFU 可以根据订阅者的可用带宽来选择将哪个流发送给哪个参与者。这在广播场景中非常有用。每个参与者都可以使用最适合他们的比特率。

以上面的例子为例，使用 simulcast，媒体服务器所需的出站带宽仅为 8.4Mbps，入站带宽为 8.8Mbps（假设有两个参与者在较小的窗口中，因此只需要 300kbps 的带宽）。如您所见，simulcast 环境提高了带宽消耗的效率和群组通话的质量。

分辨率	假设 720p 是最高的（150Kbps – 1.5Mbps）
个人用户（出站）	2.2Mbps（具有多个比特率的视频流）
个人用户（入站）	1.5Mbps（1 个流）和 0.3Mbps（2 个流）
SFU（出站）	8.4Mbps（12 个流）
SFU（入站）	8.8Mbps（4 个流）

附加提示：对于大型通话，您不必将所有人“挤”在同一个窗口中。相反，您只需在屏幕上显示最后几个活跃的参与者。我们称之为“活跃发言人”。与 simulcast 一起，您可以获得更现实、更有效的用户体验。活跃发言人不是 WebRTC 中的一项功能。

如何连接到 VoIP/PSTN？

虽然 Web 浏览器和原生应用程序往往是现代通信的主要焦点，但我们不能忽视使用 VoIP 终端或通过 PSTN 进行移动或固定电话连接的用户。因此，用户能够从电话拨入活跃的基于 WebRTC 的会话，或者在受邀加入时让他们的电话响起，这是至关重要的。

WebRTC 应用的 SIP 信令

为此，您需要一个可以理解 VoIP 电话普遍使用的协议：SIP 的网关或交换机。尽管 WebRTC 使用与 VoIP 相同的底层协议，包括实时传输协议 (RTP)、实时控制协议 (RTCP)、安全实时传输协议 (SRTP) 和会话描述协议 (SDP)，但它本身不支持 SIP 信令。相反，如何选择信令以建立呼叫的选择权留给了开发人员。因此，将 WebRTC 连接到 PSTN/VoIP 终端需要一个 WebRTC/SIP 网关。所以您有两个选择：要么自行开发，要么使用网关。这需要对 WebRTC 和 SIP 协议有足够的了解，才能使两者协同工作。

附加提示：要连接到 PSTN 线路，您可能还需要处理法律问题。例如，在印度次大陆发起的 VoIP 呼叫中，您不能合法地混合 VoIP 和 PSTN 流量。

如何将录制添加到我的工作流程中？

客户端录制和 服务器端录制 技术都可以帮助您解决网状网络录制带来的挑战。JavaScript 编码人员倾向于偏爱客户端录制，但这有其局限性。例如，视频会在本地录制并存储以供以后使用，因此您无法了解需要多少可用存储空间。而且，由于 WebRTC 媒体是通过 UDP 传输的，如果传输通道中存在数据包丢失，录制的视频质量可能会不理想。

服务器端录制

通过 服务器端录制，媒体不是在浏览器之间发送的。相反，它直接通过媒体服务器发送。当媒体准备好传输时，WebRTC 会话会启动，并将服务器作为会话中介。媒体通过服务器路由到接收端，同时，解码后的媒体被发送用于录制和后期处理。录制处理包括将所有参与者的多个媒体输入合并到一个媒体文件中，更改回放格式，以及压缩文件大小。

附加提示：录制媒体只是一个步骤。您还需要考虑存档、处理元数据以及回放如何、何时以及何地进行。别忘了也要纳入访问安全。

我的媒体安全吗？

WebRTC 在很多方面本质上更安全。因为它不使用插件，所以消除了通过恶意插件或恶意软件进行攻击的一种可能的途径。此外，浏览器补丁的部署速度很快且定期进行。WebRTC 还强制要求所有媒体都进行端到端加密，并且应用程序必须符合 HTTPS 标准。

附加安全性

WebRTC 通过安全的 Datagram 传输层安全 (DTLS) 通道发送加密媒体，并且只允许通过 SRTP 发送加密的 RTP 流。但是，WebRTC 的信令层以及媒体服务器都应该进行加密。为了增加安全性，您可能需要考虑在本地托管媒体服务器。对于寻求最大程度控制和隐私数据的组织来说，这是一个绝佳的选择。

附加提示：在开发应用程序时，请务必了解相关的法规和合规性要求。例如，医疗保健组织需要遵守《健康保险流通与责任法案》(HIPAA) 的规定，以保护患者的个人数据隐私。

DIY 还是 CPaaS？

虽然 WebRTC 的源代码是免费且易于开发人员获取的，但创建自己的应用程序可能充满挑战。有许多需要考虑的因素，例如媒体和信令服务器的来源、集成和安全性。WebRTC 堆栈没有 QoS 保证，并且当用户在受限网络上时，需要 TURN 服务器来进行点发现。

目前，全球 WebRTC 专家并不多，这使得 CPaaS 提供商成为一个更可行的替代方案。EnableX 就是这样的提供商之一。EnableX 构建在运营商级平台之上，为开发人员提供了所有必要的工具包，用于开发引人入胜的通信体验，从一对一聊天到大规模广播和网络研讨会，而无需构建后端基础设施和界面。

EnableX 是一个功能丰富、可扩展且安全的平台，提供录制、活跃发言人、翻译、通话前后分析功能等。该平台不断针对最高的视频质量进行优化。

对于那些希望缩短上市时间并降低前期开发成本，同时又想在解决方案设计和开发方面保持高度控制的人来说，EnableX 是一个不错的选择。要了解更多信息，请访问 www.enablex.io。