WebRTC Demo 开发的最佳实践

如果您正在为构建 WebRTC 应用程序而苦恼，无法让自己的 WebRTC Demo 或 POC正常运行，这里有一些最佳实践，可以节省您的时间，并大大提高项目的成功率。

使用 PaaS 类可编程视频解决方案

开发 Demo 或 POC 是为了证明某个观点。它可以是 “我们想验证项目的技术可行性 ”或 “我们想快速启动和运行一些东西，以开始获得真正客户的反馈”。

如果您想打造一个 MVP（最小化可行产品），目的是吸引一些友好的客户，向风险投资公司寻求资金，或者只是在投入之前试水，那么请使用 PaaS 或可编程视频解决方案。

这些解决方案通常基于使用量定价，因此在刚起步时并不昂贵。但它们会减少很多开发和维护基础设施方面的麻烦，因此物有所值。比如像ZEGO、声网、网易云信等实时音视频 PaaS 服务每月会提供免费额度，零成本就可以开始测试。

推荐测试：ZEGO 的示例源码，可以快速搭建一个 WebRTC Demo，体验基础的音视频通话服务。

有时，您需要的是一个 POC，以回答 “我们自己建立这个系统意味着什么 ”的问题。这不仅是成本问题，更主要的是所需要求的独特性，其中可能包括需要在封闭网络中运行、连接到某些受限组件等。在这种情况下，让 POC 不使用 PaaS，而是依靠开源的自托管组件将也是合理的。

使用 WebRTC 媒体服务器

由于点对点类型的解决方案不需要媒体服务器，因此 “更容易 ”开发出不错的Demo，这里不做讨论。而使用媒体服务器的服务通常更为强大和复杂，也会在 Demo 开发过程中陷入许多具有挑战性的陷阱。

媒体需要使用动态分配的临时端口。它需要协商连接。有更多的移动部件可能会损坏或失效。

如果不使用 PaaS，选择一些要使用的开源媒体服务器和组件，可以考虑目前使用较多的开源媒体服务器比如 SimpleRealtime Server、Janus、MediaMTX、MediaSoup，Jitsi 和 LiveKit 等。根据您的需求，可以有多种选择。

使用前，确保安装、运行并验证该开源媒体服务器的演示程序。这样做是因为：

• 您需要知道该开源组件是否真的能像宣传的那样运行
• 熟悉该组件，其构建系统、文档等
• 一步一步来，这将在后面讨论

不要使用 Docker 或原生应用

虽然 Docker 非常棒。但对于 WebRTC 媒体服务器来说，首次正确配置简直非常复杂。需要打开的端口太多，一些是 TCP，很多是 UDP。如果配置错误，媒体就无法连接或者有时可以连接(后面有大坑)。

建议对于您的 Demo 或 POC ，使用虚拟机或裸机上的操作系统。这将为您省去很多麻烦，确保不会因为 Docker 配置上的端口未正确打开而导致故障。

总之，在开发 WebRTC Demo 时，不用浪费太多时间。

不要使用原生应用，使用 Web 应用

开发 WebRTC Demo 的最简单方法是在客户端使用 Web 浏览器。更确切的说是使用 Chrome 浏览器。在初始 POC 中忽略 Firefox 和 Safari。跳过移动设备，假设这些设备工作量很大，但不会从架构上验证任何东西。至少对大多数应用类型来说不会。

👉仍然需要原生和移动？可以使用Web SDK的替代方案。支持 iOS、Android、Windows、macOS、HarmonyOS、Web、小程序并支持平台间互通。

使用第三方 TURN 服务

最初的 “hello world”很可能发生在本地局域网甚至同一台机器上。而一旦您开始将设备放置在不同的网络上，没有 TURN 服务器，事情就会开始失败。要确保不会出现这种情况，就必须配置 TURN。

而且要正确配置。

不要安装和托管自己的 TURN 服务器。

只需使用托管的 TURN 服务。

在此阶段，建议选择 Coturn、Twilio 或者 Cloudflare，较容易上手。

您以后可以用自己的服务器取代它们，而不会有任何供应商锁定的风险。但是，一开始就使用自己的服务太过费事，而且会带来一系列潜在的错误和拦截器，而这些都是您目前不需要的。

明确您的要求（并 “演示 ”这些要求）

不要以为在 Demo 应用程序中将单个用户连接到会议室就意味着可以将 20 个用户连接到该会议室。

将一个网络摄像头流式传输给一个观众和将同一个摄像头流式传输给 100 个观众是不一样的。

如果您打算进行真正的概念验证，请务必确定您的确切媒体要求，并在不同的会话规模下实施这些要求。如果不这样做，就意味着您没有真正验证架构中的任何内容。

1:1 会议使用的架构不同于 4 路视频会议，而 4 路视频会议使用的架构又不同于 20-50 人参加的会议，当您考虑到 100 或 200 人参加的会议时，架构就不同了，当你考虑到 1,000-10,000 人参加的会议时，架构又不同了，然后…..就会明白如何继续下去。

同样的道理也适用于使用屏幕共享、空间音频、多视频共享等。将所有这些作为 POC 的一部分。这可能会很笨拙，也有点难看，但必须要有。您必须了解它是否能工作以及如何工作——在使用它时会遇到哪些限制。

对于更大、更复杂的应用程序，在阅读本文之前，请务必了解本文中的所有建议。如果您不知道，那么应该加强对 WebRTC 基础设施和架构的了解，并积累更多的经验……

一步一个脚印

建立 WebRTC POC 是一项艰巨的任务。其中有多个活动部件，每个部件都有自己的问题。如果有一个环节出了问题，就什么都做不成了。

这对所有开发项目都是如此，但在 WebRTC 开发项目中却更为相关和明显。在开始这些探索步骤时，您需要建立一个 POC 或 Demo，有很多事情需要做好。配置、端口、服务器、客户端、通信渠道。

如果同时进行多个安装或配置步骤，很可能会因为其中一个步骤的错误而导致失败。要追溯到底是什么变化导致了失败，需要花费相当长的时间，从而导致延误和挫折。最好是一步一步来。每次都要验证所采取的步骤是否符合预期。

最后，您还必须掌握一些常用的工具，如 webrtc-internals，学会使用 dump-importer ，以及使用类似testRTC 这样的工具进行测试和监控。

资料来源：https://bloggeek.me/best-practices-webrtc-demo/