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

Posted 2021-11-09 anyRTC

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的成熟商业化实时音视频产品方案。

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