技术分析| WebRTC 开源服务器商业化过程中遇到的问题及挑战

WebRTC 及其发展前景

WebRTC，名称源自网页即时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音通话或视频通话的 API，旨在建立一个互联网浏览器间的实时通信的平台。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。WebRTC 官网的介绍如下：

WebRTC 是一个免费的开源项目，它通过简单的 API 为浏览器和移动应用程序提供实时通信（RTC）功能。

WebRTC 虽然冠以“web”之名，但并不受限于传统互联网应用或浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备（Android 或 iOS）还是 IoT 设备，只要 IP 连接可到达且符合 WebRTC 规范就可以互通。这一点释放了大量智能终端（或运行在智能终端上的 app）的实时通信能力，打开了许多对于实时交互性要求较高的应用场景的想象空间，譬如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。WebRTC 也当之无愧的变成了当前实时音视频领域内的宠儿。

社区中的 WebRTC 开源服务器

WebRTC 作为当前实时音视频领域的宠儿，开源社区对 WebRTC 服务器的支持也很多，下面是几个比较出名的开源项目：

· Jitsi：开源的视频会议平台，对标 zoom，googlemeeting 包括 Jitsi Videobridge（媒体中继），Jitsi Meet（会议 web 客户端），Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）

· Kurento：它是功能比较强大的一个多媒体处理框架，支持 WebRTC 协议栈。它可以作为 Media server，后台有转码的能力，并且有 OpenCV 处理能力, 不仅仅是一个媒体服务器，且构建了一整套工具包。

· Licode：可以作为 WebRTC 的轻量通信平台，是纯转发的服务器处理模式。

· Janus：可以作为 WebRTC 通信网关，比较轻量。

· Red5Pro：专注于视频直播和媒体流转发处理的 WebRTC 媒体服务器，支持服务器端和客户端 SDK 开发，支持的编码方式较多。

· Ant-Media-Server：Ant-Media-Server 是从 red5pro 克隆出来的开源项目，它目前支持两个不同的版本：开源版本和企业版本。

· Mediasoup: 一个相对较新且有趣的媒体服务器，它与其他媒体服务器的不同之处在于它被设计为一个 Library（用于 Node），允许它集成到更多的应用程序中。

WebRTC 开源服务器商业化需要踩的坑

开源社区的支持让开发者可以很快搭建一个基于 WebRTC 开源服务器的 demo，比如一个视频会议系统，用开源的项目，搭建的速度很快，搭建完毕在 web 端就能使用，很容易让人产生可以快速产品商业化的感觉。一个商业化的产品，从最开始的 Demo，到最后的成型商业化运作， 需要踩哪些坑，经历哪些挑战呢？

• 多平台：WebRTC 主要是面向 web 应用的，虽然也能用 native 开发，但开源社区对手机端的支持几乎没有，在安卓或者 IOS 端，编译调试 WebRTC 的工程项目复杂过高，搭建编译环境时都会遇到很多意想不到的问题，特别是在大陆复杂的网络环境下。

• 多用户 &级联：WebRTC 服务器商用一般都使用 SFU 组网，大量用户接入单台服务器承载能力有限，需要考虑服务器集群之间的级联，音视频流需要在多台服务器间级联，开源服务器在这块缺乏整体的服务器设计和部署方案。

• 弱网接入：WebRTC 有一套自己的传输策略，比如重传，带宽监测，动态码率等，但是我们一但在中间加上一个转发节点，就做不到完整的端到端传输链路，WebRTC 自有的传输策略效果不怎么好。如何在客户端和服务器的上下行链路上分别做优化，如何在弱网的情况下尽力保障视频和音频的流畅性，有很多难题需要解决。

• 信令和媒体的分离：如果流媒体服务和信令服务混在一起，服务器高负载情况下媒体服务会占用非常多的系统资源，将影响到信令服务的正常工作，这两个服务的职责完全不一样，应该把服务的每个模块解藕分离开，每个服务专做一件事，提高服务器资源利用率。但不幸的是在 WebRTC 开源服务器中，它们是耦合在一起的。

• 单一端口：WebRTC 开源服务器在进行互动通信的时候，每一个音视频流需要占用一个端口，如果是 n 路视频需要 n 个 udp 端口，对端口资源造成极大浪费，一些政企、金融等安全要求高的单位会对防火墙多 udp 端口的开放做限制，实际互联网运维中多端口也会给运维造成极大的不便，从海量用户和运维的角度都需要把音视频流端口改造为单一端口模式。

• 兼容性：视频和音频设备的适配问题，比如如回声、录音失败、摄像头打不开、屏幕录制失败等问题层出不穷，单厂商的苹果系统，都要考虑 iPhone2G 到 iPhone13 这么多机型和版本的兼容性。更别提厂商混战的安卓，众多安卓厂商都会在标准的安卓框架上进行定制化，会有层出不穷的兼容性问题，调节音量失败，啸叫，摄像头镜像等等问题。还有各种 IoT 设备的兼容性适配。

• 边缘接入 &调度：之前提到 WebRTC 缺乏完整的服务器方案，面对多地多用户接入的场景，单节点是难以满足业务要求的，必须要引入多地部署的分布式服务器方案，这样就需要考虑多地部署的服务器之间数据流转路由，需要一套好的路由算法做支撑。

• 可用性/可定位性：为了产品商业化，WebRTC 的服务端逐步演进成了多地多机部署的分布式服务器架构。如何保证服务的高可用性，如何解决海量并发，如何监控这么复杂的组网，发生了掉线，卡顿，时延，怎么去定位问题原因，这些都是复杂的问题。

WebRTC 作为实时音视频领域最流行的框架，在开放源码中也提供了很多高技术含量的功能，但从一个 demo 演进到一个成熟商业化产品，需要一个集合音频，视频，运维等领域方面专家的团队，去日积月累的打磨特性，持之以恒的累积经验，才能高效稳定的提供基于 WebRTC 的成熟商业化实时音视频产品方案。

anyRTC 实时音视频通讯解决方案，底层基于 WebRTC，客户端 Sdk 兼容性强，音视频处理算法、音频 3A、降噪、网络传输、服务集群技术全部自研，极好的解决了开源 WebRTC 服务面临的痛点。anyRTC 实时音视频服务集群，不仅仅能在公有云上部署运行，像金融、政企、安防等对数据比较敏感的客户，还可提供私有化部署方案，保障数据的安全性。不管多复杂的网络环境，anyRTC 的服务架构灵活，只要客户所处环境需要实时音视频服务，可保障“有网即可达”。