视频会议服务器系统(视频会议管理服务器)

WebRTC可以实现很多的应用场景，基于WebRTC的视频会议是WebRTC应用场景中比较重要的一个场景。在疫情期间，很多用户使用视频会议进行各种沟通，包括公司业务会议沟通，教育机构的在线课程等使用。在使用过程中，很多用户和笔者自己也有不同的体验结果。用户体验结果取决于视频会议的性能，在性能表现中，很多因素对视频会议的性能有制约作用。为了能够了解这些制约因素，结合笔者最近部署使用情况，和一些研究人员的结果，笔者通过漫谈的形式对这些制约要素做一个完整介绍，以方便WebRTC开发人员，部署人员针对WebRTC媒体服务器，特别是开源WebRTC媒体服务器以及测试等参数做分享介绍。

再次说明，笔者不会涉及具体的视频会议平台，所以只是进行比较宽泛的讨论。因为目前缺乏比较完整的非常专业的视频会议的测试工具，我们只能借助于很多第三方技术人员的数据来说明关于视频会议性能的瓶颈讨论。

在本文章的讨论中，笔者准备从几个不同的方面来介绍WebRTC 服务器端的性能处理的介绍，具体包括：服务器端MCU/SFU模式的性能处理，主要影响要素，视频会议画面布局影响，测试工具讨论，级联/分布式部署讨论和测试架构以及不同环境和角度的测试数据分享。

说明：

1）引用的论文和研究数据可能存在时间延后，读者最好参考最新文章。

2）数据分享没有过多介绍数据结果的具体测试背景，笔者最好进一步阅读论文原文。

3）引用数据都来自于互联网资源。

在讨论视频会议的性能时，我们首先需要确定基本的媒体处理架构。如果在没有确定基本的技术架构之前讨论视频会议的性能是没有任何意义，也不存在任何的可比性。因此，在以下的测试数据讨论中一定要注意这个前提条件。

SFU vs MCU

本图片以及以下图例均来自于互联网资源

根据以上图例，我们可以看出，无论用户部署采用何种方式，这些方式本身都有自己的特色，用户需要自己根据实际情况做决定，决定因素包括网络带宽费用，CPU资源费用和部署管理方式等都需要考虑。目前，市场上主流厂家基本上或者使用MCU方式，或者使用SFU方式。因此，在接下来的各种稳定性的数据说明中可能会涉及这些关键数据，因为部署方式的不同，这些数据也完全不同。除了以上说明以外，另外补充的几点是：

• MCU方式带宽消耗/CPU消耗的成本是否可以支撑业务本身
• MCU管理是一个非常大的挑战，一旦MCU服务器出现问题，会影响所有终端的稳定性。SFU在这方面相对风险比较小。
• SFU寄希望终端来处理，消耗终端带宽和CPU比较多。终端需要一定的优化策略来完成高负载。随着终端性能越来越高，目前看效果比较好。
• 因为MCU服务器承担了更多的媒体管理能力，所以，相对来说，MCU容易提供业务处理，SFU需要结合其他方式进行处理。

以上分析仅简单介绍了三种部署方式的存在的优缺点。当然，很多研究人员针对这些部署方式有很多更加完善的深度讨论，读者可以结合自己的用户场景做进一步学习，这里不再花费时间介绍。

大家都知道，基于互联网的产品或者应用的性能受制于很多环境因素，这些因素制约其性能。同样，基于WebRTC的视频会议系统也因为很多因素的制约，其性能会受到这些因素的影响。首先，笔者和大家分享一些笔者阅读的关于WebRTC性能测试的一些研究结果和其相关论文。Bart Jansen在他发表的论文中提到了时延，丢包, 带宽，部署方式（Mesh/SFU），视频编码（VP8，VP9，H264），移动网络，无线网络环境来进行综合测试。另外一位研究人员Sajjad Taheri在他发表的论文中，通过具体WebRTC的创建和媒体性能进行了分析评价：

连接测试评价参数

媒体处理性能评价参数

Boni García在其发表的论文中针对WebRTC的浏览器进行了比较深入的测试。Boris Grozev在关于其SFU测试和MCU测试中的测试了图像质量，客户端资源占用率，渲染Rendered Frame Rate，服务器端资源占用率，流媒体切换时延等做了非常深度的分析。Cristian Constantin Spoiala针对WebRTC在容器和虚拟机境中针对Kurento做了完整的测试。Vamis XHAgjika∗†‡针对WebRTC云部署（MCU/SFU）环境发表了一篇关于WebRTC服务器的负载和性能测试的模型。做了部署环境以上这些测试都是从不同角度使用各种模型和工具对WebRTC资源和性能做的充分的测试。针对我们讨论关于WebRTC 视频会议服务器的性能有非常完整的认识。

本文章中仅讨论关于WebRTC的使用场景和WebRTC会议中的一些编码和参数。如果涉及到更底层的图像处理的参数和编码处理，视频质量会取决于更多的影响参数。视频会议著名厂家思科对传输网络中其视频质量的服务保障有基本的参数标准：

思科针对视频会议和视频媒体流推荐的质量影响变量：

虽然以上研究人员从不同的角度和应用场景针对WebRTC性能做了详细分析，但是因为我们使用场景不同，我们不可能完全针对这些环境做深入了解，我们只能针对比较接近自己的环境进行研究。因为当前关于WebRTC视频会议的应用比较关心，因此，我们更多会讨论视频会议部署中关于服务器端资源，终端资源和视频图像质量等进行进一步分析。其他测试手段和项目读者可以查阅相关行业研究成果来学习。

在前面的讨论中，笔者介绍了很多研究人员针对WebRTC的性能进行的各种测试。但是，在这些测试中，针对浏览器界面布局的设置和分辨率的讨论相对比较少。事实上，这个因素也是影响视频会议稳定性的重要因素。因此，这里我们单独加以具体讨论。在视频会议的测试讨论中，一般会根据基本的三个参数，分辨率（resolution），比特率和会话人数来确定。当然，如果针对视频还有更多细节的其他特性，例如颜色清晰度，稳定性，伪影，锐度，对比度，亮度等非常专业的特性，这些特性可能会应用在WebRTC环境中的一些行业应用中，应用软件通过摄像头获取更多分析数据，进行实时分析。这里，我们仅讨论一般情况下，视频会议中分辨率，传输比特率和会会人数的测试讨论。根据这三个数据，用户在视频会议的画面布局将会决定服务器端和终端的处理能力。在视频会议的场景中，我们一般也做不到大家都使用非常高的分辨率，或者使用其他高清终端（实际上每个人都想获得高清效果），但是视频会议还有其特殊性，一般来说，会议主持人和演讲人具有相对比较大的权限，这些人的布局设计可以通过调整的方式来实现，这样就可以优化整个视频会议的系统性能。假设，如果用户WQHD显示器的话，有四个会议用户的话，使用SFU的模式处理方式的话，根据布局和分辨率的不同，SFU服务器所占用的发送和接收到带宽都完全不同，用户端的带宽占用也完全不同。一些图例对比了如果用户使用720P，VGA和Hangouts模式的实际带宽：

目前，比较热门的一些视频会议基本上都采用Hangouts的模式，会议主讲人显示图像显示比较大，其他人的相对比较小，很多其他用户可能关闭了图像功能，仅留语音功能。另外，还有的开源视频会议系统，例如，jitsi，它提供了更为灵活的优化方式，根据自己的网络环境和其必要性，用户端可以灵活调整图像质量。这样就更加保证了会议的稳定性。

当然，如果用户都开启了摄像头，整个测试的数据肯定会完全不同。通过以上数据可以看出，事实上，视频会议支持的人数在MCU和SFU环境中是完全不同的。如果是MCU的话，支持人数更多取决于MCU本身的支持能力。如果是SFU的话，读者可能需要考虑SFU的部署环境设置，客户端的能力，SFU的级联配置。另外，如果读者部署在云平台的话，例如CPaaS，用户还要考虑平台的支持能力。

50 participants in a single session

几个开源的视频会议平台所支持的人数以及拓展支持

平台名称支持人数（建议使用人数/测试用户）摄像头数量拓展支持（会议房间是否可以调整）Jitsi

75/35/测试1000-4000用户120用户-静音5摄像头支持均衡负载，HAbigbluebutton（BBB）150/200150-<10摄像头HA拓展支持更多会议房间/用户

100用户/测试用户/2000用户（MX）135用户-<10摄像头支持HA均衡负载

为了满足更多的用户需求，级联方式是SFU使用的主要的配置方式：

如果使用MCU方式，或者需要单台服务器支持更多用户人数的话，部署视频会议只能通过增加CPU的处理能力，增加带宽和控制人数方式来进行优化。

除了前面笔者讨论的画面布局问题带来的视频会议服务器的性能影响以外，如果视频会议需要拓展支持的话，特别是SFU模式下的拓展支持，级联的技术架构和数据延迟也会带来视频会议的稳定性问题。在实际生产环境中，我们自己也经常会遇到会议状态的不确定性：会议人数很难确定，会议人员地理位置很难确定，终端网络质量和终端处理能力。这样就会导致视频会议的不稳定性和潜在问题。从几个会议人员一下子攀升到几十个或者上百个，甚至于上千人数等问题。

当会议人数达到一定的数量时，视频会议服务器端网络带宽和技术架构肯定会受到极大冲击。一般的解决办法可以通过限制会议人数，在确认的人数基础上增加带宽，设置I-frame控制丢包，针对流媒体支持，支持WebRTC的前向纠错（FEC），通过WebRTC客户端支持图像质量特征设置支持。为了完全实现视频会议的拓展和HA服务，几乎所有开源的WebRTC视频服务器或者媒体服务器都可以通过不同的方式实现拓展。以下就是一个Jitsi实现级联的技术架构示例，通过Jitsi会议桥来创建不同的拓展和HA高可靠性部署。

当然，这种级联部署方式仍然可能会出现其他的问题，比如，会议人员的地理位置的不确定导致的数据交互延时，还有丢包问题，RTP媒体流延迟，TURN服务器解析DNS的延迟。在以下示例中，Jitsi的jicofo作为信令服务器和jvb（jitsi-videobridge） 媒体服务器进行拓展交互，这样可以达到最佳优化效果。

除了在平台进行拓展处理以外，底层服务器端也可能进行优化拓展。

另外，在WebRTC的视频会议或者媒体服务器端，一个非常消耗CPU资源的处理就是编码转换。为了保证媒体服务器的稳定性和可拓展性，一些WebRTC服务器也充分使用了拓展的技术架构，例如kurento的媒体服务器(底层是GStreamer)，然后通过底层的拓展来实现人群跟踪检测，车牌识别等具体的业务场景。在各种WebRTC服务器对比中，Kurento服务器端对各种场景和中间件处理比较灵活。其实，这种特性也是因为Kurento本身特性决定的，应该不能说是它的一个优点。Kurento本身的设计初衷就是支持不同媒体服务器场景的，因此相对比较灵活，其他的几个媒体服务器更多侧重于视频会议一种业务，没有其他的场景支持，因此也没有kurento设计的那么灵活。

Kurento支持了多种非常具体的业务场景，包括人脸识别，车牌识别（支持IP摄像头），物体跟踪，人群监控等场景，因此对中间件支持比较丰富，也支持了多种编码格式和编码转换的处理。

根据研究人员Boni García在关于Kurento 的WebRTC 媒体服务器的论文中的总结，如果需要拓展媒体服务器的话，基于kurento的WebRTC服务器可以通过横向增加服务器数量, 如果是云平台的话增加实例，CPU，内存来实现媒体服务器的拓展。具体的拓展方式以及其灵活性取决于WebRTC服务器的设计架构，读者可以参考此讨论来进行学习。关于kurento的背景介绍，读者可以参考以前的文章：

Scalelite是开源的均衡负载项目，它支持了BigBlueButto（BBB）的技术架构，通过界面可以配置

Scalelite支持的BBB均衡负载技术架构

它可以实现数据库，Scalelite Server，Redis Cache 服务器。录像/录音共享，通过媒体服务器BBB拓展可以实现更多会议人数。

在前面的章节中，我们讨论了关于级联的技术架构HA处理方式的不同，还有媒体服务器拓展的方式。但是，这些拓展的技术架构都是为了保证其WebRTC服务器的稳定性，那么，如何针对WebRTC服务器进行测试呢？其实，市场上和开源社区也提供了一些非常有效的测试工具，可以帮助用户从不同角度来测试WebRTC服务器端的一些性能，以下是目前几个主流的WebRTC 服务器测试工具：

• WebRTC-Analyzer：基于SimpleWebRTC开发的分析工具
• WebRTCBench：WebRTC基准测试框架，由Parallel Architectures and Systems LAB开发，由Intel赞助
• Jitsi-Hammer：专门针对Jitsi开发的测试工具，可以创建会议室，播放视频，克隆用户，生成RTP流
• testRTC：商业版本的WebRTC视频会议测试工具
• cosmosoftware：通过多种WebRTC场景测试工具，包括黑客工具，端对端加密服务，WebRTC视频质量评估工具。它支持目前几个主流的WebRTC开源服务器（Janus, Jitsi, Medooze ，kurento等）
• ElasTest：开源基于云平台业务的测试工具，支持WebRTC测试
• Selenium Framework：商业的自动测试工具，可以针对WebRTC进行测试。
• Jattack：开源的针对WebRTC服务器端的压力测试工具，但是目前仅支持Janus。

笔者在前面讨论了几个关于WebRTC的性能的重要指标以及相关的测试工具。但是，如果我们看一些测试分享时，我们仍然发现，测试人员进行的测试都是从不同的角度进行的。事实上，业内很多研究人员以及提出了比较完整的WebRTC测试技术架构，测试人员可以从这个技术架构中选择不同的角度进行测试。Boni García发布了关于WebRTC 测试的挑战和实践解决办法，如果读者计划对WebRTC进行测试的话，可以参考这个测试架构进行测试。

WebRTC 测试技术架构

在实际的测试数据中，测试结果以及相关测试包括网络带宽的结果影响参数（编码类型，分辨率，Frame rate，图像大小，呼叫量），用户人数，呼叫创建耗时，浏览器类型，媒体服务器类型（MCU/SFU），平台部署方式（容器/虚拟机/云平台），时延，视频质量等对比，CPU消耗，内存消耗，QoS/QoE。Muhammad Shahid在他们团队的论文中讨论了关于视频会议QoS和QoE的相关测试参数，在进行测试时也需要按照这些参数对比测试。

下面，笔者分享一些不同测试结果，读者通过这些结果可以基本上了解相关WebRTC性能以及完整的相关要素，这些数据具有一定的参考意义。

浏览器是WebRTC呼叫中非常敏感的终端，很多WebRTC功能经常受限于浏览器的版本。WebRTC应用环境中，使用不同浏览器实现的信令创建结果。

脸部识别的CPU消耗

内存消耗

存储设备使用情况

网络带宽使用情况

http://www.kurento.org/blog/kurento-webrtc-gateway-ip-cameras

Sajjad Taheri发布了关于针对WebRTC性能测试的基础测试方法，他不同终端环境下WebRTC呼叫初始时间，ICE创建时间等做了非常深入的研究调查。这也是很多WebRTC用户经常会遇到的问题，为什么WebRTC呼叫时间总是很长的一个合理的解释。

关于ICE创建/offer/answer时间

不同网络环境中ICE打洞时间耗费

不同终端VP8编码解码渲染执行情况

Emmanuel Andr´e针对不同开源WebRTC 媒体服务器SFU模式下的对比测试，包括了加载不同数量的用户进行测试，传输结果，时延和视频效果评价得出来不同的测试结果。

Transmission bit rates （Jitsi，Janus，Medooze，Kurento和Mediasoup）结果

视频会议评价结果：

WebRTC媒体服务器可以部署在物理机，也可以部署在虚拟机容器。这些不同平台针对WebRTC服务器的性能有不同的影响。研究人员针对容器和虚拟机（KVM）上进行了WebRTC媒体服务器的性能测试。使用的WebRTC媒体服务器是Kurento Media Server (KMS）。测试架构如下：

根据此研究人员的测试，容器的整体性能优于KVM，特别是实时通信应用中时延的处理比KVM表现要好。

针对具体的WebRTC视频会议服务器性能测试中，Jitsi的测试相对比较多，测试参数有非常明确。Boris Grozev 和 Emil Ivov根据以下几个指标对Jitsi进行了测试评估（每秒中进行的测试参数变量）

• conferences —活动会议数量
• endpoints — 所有会议加载的终端数量
• cpu_usage —CPU负载，包括CPU状态
• network_in—接收的网络数据bitrate
• network_out — 发出的bitrate
• bitrate —总和（network_in 和network_out），以Mbps计算。
• streams —Jitsi会议桥能够处理的语音视频数据流总和，这个数值取决于终端数量。

1056语音/视频占用50Mbps带宽

1056语音/视频消耗20%CPU

其他语音/视频终端加载的带宽和CPU消耗状态

关于针对视频会议QoE的研究论文很多，有的研究论文针对H264高分辨率的研究，有的针对解码算法进行研究，还有的针对视频质量和压缩进行研究。这些视频会议的算法研究都对QoE有非常大的影响。很多关于QoE评价方法，读者有兴趣的话，可以进行进一步研究。

常用的关于QoS和QoE评价方式中的参数

如果用户需要进行测试的话，在有限资源条件下尽量采用比较常用的参数，例如抖动，时延，带宽和丢包测试。这里，我们分享Ahmad Vakili的关于QoE和Frame Rate，压缩比，Bit Rate以及带宽预估的研究结果。

WebRTC视频会议可以使用不同的视频编码，目前使用最多的三种编码中，它们都有各自的特点，特别是在网络拥塞或者网络带宽有限时，它们的表现都不同。在720P测试环境下，三种视频编码的不同表现。H264相对VP8和V9，在带宽有限时，它会产生更大的延迟，同时在分辨率不同的环境下，H264相对支持表现比较差。

在WebRTC视频会议使用环境中，CPU和带宽是非常重要的参数（内存相对不太敏感），这两个参数会直接影响视频的质量。以下是一个视频会议测试中，使用SFU模式，不同带宽环境下的视频质量表现（使用VP8编码）。

设置为 low quality时的结果：

设置为high quality时的结果：

不同quality的jitter buffer delay结果

在本文章介绍中，笔者主要分享了关于基于WebRTC的媒体服务器和视频会议的介绍。首先，笔者介绍了分享了关于WebRTC性能的一些重要指标，然后介绍了关于WebRTC目前研究的比较新的研究成果，影响WebRTC服务器执行的几个要素，关于视频会议画面布局带来的影响，接下来，笔者介绍了关于WebRTC测试的几个主要工具，最后笔者和读者分享了WebRTC的测试架构，以及不同研究人员针对不同环境和不同角度进行的WebRTC的测试和相关性能报告。

虽然，笔者尽可能完整介绍了关于WebRTC服务器端性能测试的一些数据，但是，因为资源有限，我们缺少针对STUN和TURN的测试报告，也缺少基于App端的测试报告，还缺少关于WebRTC各种开源终端的测试报告。希望以后有机会能够获得更多资源来和读者分享。

再次说明，如果读者有兴趣对某些数据或者测试手段进行进一步研究的话，建议读者阅读完整的论文原文和其相关研究论文。

参考资料：

www.w3.org

www.jitsi.org

www.jitsi.org.cn

Bart Jansen，Performance Evaluation of WebRTC based Video Conferencing

Sajjad Taheri，WebRTCBench: A Benchmark for Performance Assessment of WebRTC Implementations

Boni García，WebRTC Testing: State of the Art

Boris Grozev，Experimental Evaluation of Simulcast for WebRTC

Cristian Constantin Spoiala，Performance comparison of a WebRTC server on Docker versus Virtual Machine

Vamis Xhagjika∗†‡, Load and Video Performance Patterns of a Cloud Based WebRTC Architecture

Boris Grozev，Jitsi Videobridge Performance Evaluation

Emmanuel Andr´e， Comparative Study of WebRTC Open Source SFUs

for Video Conferencing

Boni García，Kurento: The Swiss Army Knife of WebRTC Media Servers

https://github.com/havfo/multiparty-meeting/blob/master/HAproxy.md

https://www.polycom.fr/content/dam/polycom/common/documents/whitepapers/benchmarking-videoconferencing-success-wp-enus.pdf

https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-video/212134-Video-Quality-of-Service-QOS-Tutorial.html#anc19

https://github.com/blindsidenetworks/scalelite

Boni García，WebRTC Testing: Challenges and Practical Solutions

https://www.red5pro.com/blog/guest-post-tashi-levent-levi-webrtc-scaling-challenges/

https://jitsi.org/blog/new-tutorial-video-scaling-jitsi-meet-in-the-cloud/

B.A. Jansen，Performance Analysis of WebRTC-based Video Conferencing

原创声明：以上文章或文稿中文字或图片涉及版权等问题，如需转载请注明来源：友好会议服公司：www.ynyhhy.com