RTC 融合通信服务架构与场景应用 | 2021稀土开发者大会音视频专场

导读： 5G 与 AI 技术推动音视频技术持续演进，RTC 技术在多个行业得到了充分应用，但各行业的业务有着不同的需求，因此就需要构建一套 RTC 融合通信服务系统，为产品的创新提供坚实的基础。本次分享将重点分享：网易云信 RTC 融合通信服务架构，并结合近期热门的娱乐社交与在线教育场景，从解决各业务场景痛点和难点切入，为大家讲解 RTC 融合通信的核心技术和最佳实践。

文｜吴桐

网易云信流媒体首席架构师

背景

 RTC 行业2021年整体发展 

这两年 RTC 行业的迅猛发展，不管是在泛娱乐行业的云游戏、音乐、社交、语聊、直播和短视频，还是在在线教育，都能看到增长曲线是非常可观的。从技术发展方向上来说，RTC、直播和 VOIP 通信越来越往融合一体化方案架构上发展，各平台也逐步推出 All in One 的解决方案，这方面的内容我会在今天分享的第二部分详细展开；娱乐社交和在线教育的 RTC 技术不断创新，针对各类垂直领域也涌现出很多的音视频技术的创新方案，这些创新方案会在今天分享的第三、四部分重点阐述；我相信随着音视频相关需求的日益增加，未来音视频行业还将持续高速的增长，也有着无限的机会等着音视频行业的从业人员，有机会当然也会有挑战。

 RTC 融合通信后端服务挑战 

• 在融合通信系统里，需要接入各种类型的客户端，各客户端的协议也非常多样，包括私有协议，以及各类标准协议，比如：WebRTC、RTMP、SIP、PSTN 和 RTSP 等等；为了解决协议接入的问题，融合通信服务端必须具备很强的协议兼容能力。

• 随着 All in One 的推行，融合通信服务端需要承载的并发也越来越大，包括单频道的百万并发，以及晚高峰的的流量蜂拥，这就要求我们的系统具备很好的弹性扩缩容能力。

• 随着全球化用户接入，还需要面对全球范围内复杂多变的网络情况，包括小运营商，偏远地区和非洲等国家的 2.5G 和 3G 网络，以及更为复杂的跨国通话的网络问题。
  

RTC 融合通信服务架构

 多协议融合通信 RTC 系统 

首先我们从全局的维度来看看云信是怎么做的多协议融合通信 RTC 系统的，整个架构的中间，是我们的流媒体传输与处理服务器，其中包括了边缘媒体接入系统、实时传输网系统、流媒体处理服务系统以及直播点播服务系统。在新一代的音视频融合通信系统中，我们除了云信 SDK 以外还支持了多种协议客户端的接入，在边缘媒体接入服务模块中，我们的边缘媒体服务器既支持云信 SDK 的接入，也直接支持了标准 Web 端使用 WebRTC 接入；另外我们自研了 SIP 网关服务器，实现了 SIP、PSTN 的接入；我们使用通用媒体网关实现了标准 RTMP 推流工具、小程序、RTSP 监控摄像头的接入。

在边缘媒体服务系统收到各协议客户端的媒体数据包以后，会再通过我们实时传输网的边缘节点和路由节点进行全球的实时媒体数据分发，保证端到端的最优体验。同时利用流媒体处理服务的通用 MCU 和转码服务器，可以将媒体流混合以后通过旁路转推到我们的互动直播服务器，再通过我们直播的融合 CDN 系统进行分发；还可以在云端进行录制后，存储到云信的点播服务系统中。

在流媒体传输与处理服务系统的左侧是我们的全局流媒体控制服务，它包括了：频道与流管理服务，统一媒体调度服务和实时传输网调度服务，他是整个音视频融合通信系统的大脑，由它来动态控制整个系统的运转。

在最右侧，是我们的大数据与配置服务系统，它包括了我们的全局大数据分析和挖掘系统，负责全链路各个采集的数据处理、告警和质量透明，并利用大数据挖掘的结果指导全链路各模块算法和策略的制定，另一个是我们智能全局配置管理和下发服务，它负责对我们各类云端参数的下发，包括 QoS 参数，音视频编解码参数以及 A/B test 的相关开关。

我们对新一代音视频融合系统架构做个总结，首先新版音视频融合通信系统是一个混合了实时媒体边缘服务器、实时传输网以及融合 CDN 的一个多协议混合组网系统，它可以满足用户的各类对场景和网络实时性的需求；第二，我们的媒体边缘服务器和媒体网关下沉到边缘，大大降低了用户到第一跳接入服务的的距离，也可以更好的发挥 5G 边缘计算的能力。

虽然我们可以靠媒体服务器级联来实现 RTC 服务器的高并发，但是为了降低成本和提升整个系统的容量上限，最大程度的提升单台服务器并发能力还是非常重要的。

 超高并发 RTC 媒体服务器 

为了提高服务器的性能，从充分利用多核 CPU 的角度上至少有两种明确的方案（第三种就近年来以 golang 为主的协程方案）：多线程和多进程。云信先后使用了这两种方案来实现云信 RTC 的媒体服务器。

单进程多线程：

首先我们来看看单进程多线程的架构，我们采用 Reuseport+IO 读多线程的方案来实现高性能的 IO 读，这里利用了 Linux 内核 Reuseport 的负载均衡，会根据收发四元组做负载均衡。IO 线程收到数据包以后，会将数据包投递到后侧的 Worker 多线程上进一步处理业务逻辑，信令和媒体的处理都在 Worker 多线程上。这个架构使用多线程很好的利用了多核 CPU 的能力，整体的性能在业务逻辑不复杂的阶段，还是非常不错的。但是随着需求的演进也面临很多问题和挑战：

1、在业务逻辑复杂以后，多线程的架构的加锁操作会过多，导致性能受到影响；

2、因为是单进程，而 C++程序的崩溃是一个很难不发生的问题，单进程崩溃后，影响范围比较大；

3、多线程程序对编码要求高，特别是很多新人对代码不熟悉时，比较容易犯错，而多线程的问题，往往又比较隐蔽，定位和 debug 的难度也比较大。

所以随着项目的迭代，渐渐的我们开始针对单进程多线程的架构进一步进行了迭代。

多进程架构：

在新的架构中，我们采用了多进程的架构。Master 进程作为父进程，同时也作为其它进程的守护进程，不做其它任何复杂业务，因此 Master 进程的稳定性是比较高的。信令、媒体进程均作为 Master 进程的子进程，信令进程和媒体进程都是单进程单线程架构，大大减少了多线程加锁的操作；所有的媒体进程只需要和信令进程交互，媒体进程相互之间无需交互。这个架构其实有点像 Nginx 的架构，架构的性能、稳定性都比较好。目前云信在全球范围的媒体服务器都采用这种架构，系统的的稳定性得到明显的提高。

 WE-CAN 全球组网 

看完了接入协议的多样性和海量并发的应对方案以后，我们来解决全球范围内节点网络互联问题。为了解决这个问题我们把目光转移到音视频融合通信服务端的另一个核心系统——云信自研的大规模分布式实时传输网 WE-CAN。

两个边缘媒体服务器在需要级联的时候，会通过实时传输网的边缘接入节点将流量导入实时传输网。实时传输网的边缘节点根据实时传输网调度服务的统一调配，通过传输网的路由节点，将数据包以最优路径发送到目的边缘媒体服务器。在这个过程中实时传输网路由探测和计算服务是链路路由选择且保证最优质量的的控制大脑。云信自研的大规模分布式实时传输网有四大特点：

1、低延迟：边缘接入节点全球覆盖，所以可以做到用户接入超低延迟，质量可以媲美专线；

2、低成本：使用边缘计算能力，而不是核心 BGP 机房，在降低成本的同时也保证了质量；

3、高到达：实时传输网路由节点的路径规划非常智能，在全球范围内能做到多通道备份保证数据的高可达；

4、高可靠：实时传输网支持分级服务，同时多个链路通道可以自动快速切换，能够在秒级做到故障隔离，保证链路的稳定可靠。另外相比同类产品，云信自研的大规模分布式实时传输网，支持了大规模级联场景下的应用层组播技术，做到流量复用；同时还借鉴媒体服务器的分段 QoS 思路，支持分段重传和 FEC ，保证了全链路的网络传输质量。

另外相比同类产品，云信自研的大规模分布式实时传输网，支持了大规模级联场景下的应用层组播技术，做到流量复用；同时还借鉴媒体服务器的分段 QoS 思路，支持分段重传和 FEC，保证了全链路的网络传输质量。

娱乐社交场景技术实战

 ClubHouse 万人连麦 

今年年初，由“当代钢铁侠”埃隆马斯克的亲自引流，为 ClubHouse 这个在线多人语音聊天的平台引入了大批用户，ClubHouse 由此进入了一码难求的阶段，甚至 eBay 上一个邀请码被炒到数百美元。抛开 ClubHouse 在产品运营维度的相关内容，ClubHouse 本质上就是一个全球的语聊房，从服务端的角度来剖析它的技术难点，我认为有以下三点：全球通话、超大并发以及上麦人数不限制。其中全球通话和超大并发的技术解决方案我们在第二部分都已经涉及这里就不再赘述。这里我们重点展开聊聊上麦人数不限制。

首先，我们先分析一下上麦人数不限制有什么技术难点，我举个相对极端的例子，一个5000人的频道，5000人都需要开麦说话，那么这个频道在系统里面就会有5000路上行，这时候如果服务端是一个纯转发的 SFU 服务器，就需要转发近两千五百万路的音频给所有的用户，这个转发的量是一个特别大的压力；同时每个用户的客户端收到4999个下行语音流的时候，客户端并不会把这些所有的声音都进行混音播放，因为在一般理解上，一个混音里有超过3人的声音的时候，就完全听不清了，所以一般情况下客户端会选择音量最大的3~5路语音进行混音后再播放出来。可以看出来这么做的性价比是特别低的，浪费了大量的下行带宽流量。因此合理的做法是在服务端上进行语音选路，为客户端选出合适的语音后再转发。

在单机里面做音频选路其实是比较简单的，只需要在上行的 RTP 包的扩展字段里面打上这个 RTP 包 PayLoad 部分的语音的音量信息，然后在服务器收到语音包以后经过音频选路器，将里面的音量最高的 N 路选择出来，当然这里也涉及历史数据和渐入渐出等相关音频选路算法，但是总体而言难度不大。但在一个有大规模级联的分布式环境下来实现选路就有一定的难度了，首先我们能想到的一个简单的方案就是在整个系统中，同一个频道的在一个统一的服务上做音频选路，这种方案在人数不超过1000人场景下是适用的，但是当人数越多，这台负责整个频道选路的服务器就会成为系统的瓶颈点，而且这台服务器的可用性会直接影响整个系统的可用性，它成为彻彻底底的短板。那云信是如何解决这个问题的？

是因为云信采用了分布式音频选路方案！

我们来简单的看一下这个方案，客户端连到边缘媒体服务器以后，这台边缘媒体服务器本机收到的音频包进入本机的上行选路器进行音频选择，上行选路器选择完成以后会将选路通过的语音包交由下行选路器，同时也会同步一份给级联的服务器，这部分数据就会进入对端媒体服务器的下行选路器，总结来说就是每台机器的上行选路器只选直连本机的用户的音频包，而下行选路器需要将本机上行选路器和远端上行选路器的结果再次选路，最终选择出发给客户端的数据。通过这个方案，我们最终实现了超大并发下的分布式音频选路方案，在这套架构下整个选路系统不存在单点故障点，也就是任意一台边缘媒体服务器宕机不会影响音频通话的正常进行，同时级联的选路和下行选路也大大降低了服务器间的流量和下行客户端的流量。当然这里还有一个点，就是选路到底应该选音量最大的几路的问题，以我们的经验，一般情况下3路就够了，但是在某些特殊场景下，比如齐声朗读、大合唱的时候，选择8路也足够，因此云信将选路的路数是开放成接口让客户根据自己的场景来设置的。

 在线 KTV 

这两年随着音乐社交的不断发展，在线 KTV 这个场景也越来越火。在线 KTV 主要是为了模拟真实 KTV 的场景，包括单人 K 歌和多人合唱。首先，我们来思考一个问题，在线 KTV 的场景和一般 RTC 场景有什么区别，其实本质上是一样的，但是有一个技术点在线 KTV 的要求是特别严格的，那就是延迟和同步。

单人 K 歌

对于主播来说，主播自己在演唱的时候，看着 MV 和歌词、听到的伴奏开始演唱，所以主播的体验是肯定可以做得同步的，但是观众侧要做到 MV、伴奏、延迟以及歌词的完全同步就有一定的技术含量了，这里其实有两种方案来实现。

• 主播发送音视频

方案具体细节：主播侧将含有歌词的 MV 视频和 MV 伴奏在本地播放，同时主播开始演唱，SDK 将 MV 和 MV 伴奏使用自定义入口输入的 SDK 引擎，同时采集麦克风的主播演唱声音，在 SDK 引擎内部将 MV 的伴奏和主播声音进行混音，并使用通用的音画同步方案将MV和混合出来的声音做同步后发送到听众接收端；此时听众接收端只需要把收到音频和视频按常规的播放渲染流程就能得到同步的效果了。

这个方案的明显优势就是：简单、并且能做的很好的同步；但是也存在明显的劣势：MV 视频是通过 RTC 的视频流进行传输的，流量成本特别高，而且往往 MV 的视频分辨率都比较高至少在720p，高分辨率的视频也比较容易引起传输的拥塞，最后造成观众侧体验卡顿。

• 主播发送纯音频

为了应对第一种方案的问题，我们提出了第二种相对复杂的方案，如右图。主播不需要将高清的 MV 视频发送给对端，我们利用补充增强信息 SEI NAL，主播侧将当前 MV 的播放时间戳填入到 SEI 中。

主播侧的 SDK 会在引擎内部做主播演唱的语音和 SEI 的对齐，接着 SDK 把 SEI 和主播的演唱发送到听众侧，听众侧根据 SEI 里面时间戳信息控制 MV 的播放节奏，这样就可以做到同步了，通过这个方案可以就大大减少了视频的流量。当然这个方案在听众侧 MV 的播放控制方面也有一定的实现难度，需要深入到播放器的内核。总结来说这两个方案也各有优劣吧，各位同学可以按需选择。

多人合唱

其实多人 K 歌这几年也有多套方案在演进，早期的方案存在主播无法听到合唱者的声音等众多问题。随着音视频技术的不断迭代进步，云信解决了多人合唱最核心的两大问题，全球时间戳精准同步和端到端的延迟控制；端到端的延迟控制，不仅涉及端语音采集播放的低延时处理，还涉及了全球范围内全链路端到端的延迟要控制在 70ms 以内。这里利用了 WE-CAN，分段 QoS 等多种手段。

而全球时间戳精准同步，云信自研了利用 WE-CAN 的分布式 NTP 对时系统，让全球所有的边缘媒体服务器的 NTP 时间都能做到1ms 内的误差，这样所有的主播、合唱者和听众再和边缘媒体服务器进行高精度时间戳同步，就能做到在全球范围内超高精度同步，目前云信的时间戳同步能做主播和合唱者 的1ms 误差。有了这样的技术解决方案，主播与合唱者就只需要在同步的开始在本地播放伴奏，然后演唱就可以做到很好的多人合唱体验了。

 元宇宙——Metaverse 

 “元宇宙”一词源自90年代的一本科幻小说，它指的是现实中的人可以在一个沉浸式的虚拟世界中，使用数字化的特定身份相互交流，获得互动体验。2021年被大家称为元宇宙元年，我相信大家或多或少都听说过，特别是在《头号玩家》电影里面大家也都体验过了那种在虚拟世界里面体验人生的感觉。从 RTC 技术的挑战的角度，我简单提几个点：

VR、AR 技术是元宇宙的核心基础，这几年 VR 与 RTC 的结合业界已经有很多探索，核心要解决超高清视频和超低延迟，对于超高清 8K 及以上分辨率的视频非常依赖高性能视频编解码技术和底层硬件的支持；而超低延迟除了需要传输协议层面和 QoS 做相关优化，也依赖 5G 乃至 6G 的底层通信技术；另外，为了让大家在元宇宙的世界中有身临其境的感觉 RTC 里面需要 3D 立体音，另外前面我们提到的大房间音频选路，在元宇宙里面还需要在服务端上实现根据距离的音频选路。

上面这幅图是游戏公司 Beamable 的创始人近期发表解析的元宇宙文章里的配图，他从结构化方向上深度解析了元宇宙7层价值链，感兴趣的同学可以进一步的去了解一下。

元宇宙价值链包括七个层面：体验（Experience）；发现（Discovery）；创作者经济（Creator economy）；空间计算（Spatial Computing）；去中心化（Decentralizition）；人机交互（Human Interface）；基础设施（Infrastructure）。

在线教育场景技术实战

大家应该都知道今年因为“双减”政策对在线教育公司有不少影响，但是在线教育的场景这几年是一直推着 RTC 技术不断往前的迭代优化的。在这一部分，我会与大家分享小班课、大班课还有超级小班课的技术实战。

 在线教育小班课的优质体验 

在线教育的小班课作为音视频场景里面相对复杂的一个场景，其实需要面临的挑战很多，小班课中各个终端的观看需求不同、网络情况也各不相同。因此为了做好小班课的体验，我们需要有一个完善的发布订阅系统，同时配合好服务端的智能选择，这依赖于服务器上的一套智能码率分配以及码流选择算法；另一个核心功能是要实现服务器的分段 QoS，所谓分段 QoS 就是在服务器上需要分别针对用户到服务器的上行链路和服务器到用户的下行链路做好 QoS 保障，当然对于服务器来说核心是要做好下行的带宽估计、拥塞控制和弱网对抗。

为了做好自动适配下行带宽，首先针对每个上行用户和下行用户需要分别估算他们的上行和下行可用带宽，这里涉及到分段带宽估计以及带宽估计算法的优化，云信在融合了 GCC 和 BBR 算法优势的基础上研发了自己的发送侧带宽估计算法，该算法带宽估计准确度能做到95%。在估算到准确带宽以后，为了适配下行带宽，我们使用了各类策略包括：

1、最基础的是基于大小流（simuclast）的选流策略，发送端发送不同分辨率的视频流到服务器上，服务器根据下行带宽情况，选择相匹配的分辨率发送给各个下行客户端；

2、云信实现了基于 SVC 时域分层的选流策略，再结合大小流，就能提供更精细的码率分配策略；

3、除了码率选择，云信还在系统中提供了基于优先级的带宽分配策略，特别是会议和在线教育场景，主讲者的优先级明显高于其他参会者，这时候就设置主讲者为高优先级，那么下行策略就会优先把更多带宽留给主讲者，保证大家看到主讲者的画面是最优的；

4、基于 TopN 的带宽反馈策略，在默认情况下我们会尽量保证多数用户都能看到高清的画面，这个时候会适当压制上行的码率，以匹配 TopN 的客户，N 是可配参数。

通过上诉手段我们就能保证在服务端上，为所有用户决策出最佳匹配当前下行网络状态的码流分配结果。

低延时大班课的平衡之道 

当前，大班课绝大多数都是通过传统的直播解决方案实现的。传统方案采用基于  TCP 协议的 CDN 直播，尽管经过了多年发展和改进，但由于 TCP 协议本身的特性决定了它在实时流媒体领域的固有问题是很难攻克的，这就导致了延迟高、弱网抗性差等问题，直接影响了学生的用户体验。而 RTC 方案虽能解决上述问题，但其高昂的成本让人“又爱又恨”，也让众多平台望而却步。所谓的平衡之道，其实就是要在效果（也就是清晰度、端到端延时、流畅度）与成本间去找到二者之间的平衡点。

为了实现低延时大班课的平衡之道， 我们实现了低延时直播。

在推流端支持第三个推流工具和云信推流 SDK，将流用 RTMP 或者云信的私有协议推到媒体边缘加速服务器，对于开通了低延时功能的会通过 WE-CAN 大网进行高效分发，否则就通过融合 CDN 分发。WE-CAN 针对低延时直播的流做了全链路的延时优化，相比于 CDN 直播 4s 以上的延迟，低延时直播可以将延时控制在0.6~1.2s。另外，低延时直播也复用了部分 RTC 的弱网对抗和首屏优化技术，可以将首屏控制在500ms 以内；我们实际测试，在30%的丢包的场景下基于传统 CDN 基本上已经不可用了，而低延时直播还是非常流畅。通过各类技术保障，其实就是让用户用 CDN 的价格体验到了 RTC 的效果。

 超级小班课场景落地 

在在线教育的领域，优质的老师资源一直是稀缺资源，因此很多教育场景使用了直播大班的方案来最大化利用优质教师的内容，但是直播大班课相比与小班课也有一个弊端就是学生的互动体验较差，为了解决这个问题云信提出了超级小班课方案。

它就是直播大班与互动小班的合体，即：一名主讲老师面向数万名学生进行直播授课，学生被分成若干个小班，在小班内与老师、班内其他同学进行互动，同时还可以安排多名助教分别进入多个小班，助教负责管理小班内课堂秩序和辅助教学。通过该方案就完美了平衡了名师资源和学生互动的问题。

超级小班课的技术要点，我们分别需要实现聊天室的超级小班能力以及音视频的超级小班能力。

对于 IM 聊天室，核心技术是 IM 聊天室标签功能——灵活地支持聊天室消息定向收发、聊天室权限定向管理、聊天室成员定向查询等个性化功能，分组互动。而对于音视频，核心技术有两个：

1、跨房间连麦，这个在今天分享第二部分提到，云信的媒体服务器是以流的作为管理单元而不是以房间作为管理单元，那么实现跨房间连麦时，就非常方便；

2、加入多房间，客户端需要支持同时加入多房间，这样学生就可以同时加入老师的大班课和互动小班两个房间；

云信通过这些 IM 和音视频的底层能力，完美的解决了超级小班课的痛点，也为多个在线教育平台提供了超级小班的能力。

RTC 数据驱动

大家都知道现在是一个大数据时代，我认为做好大数据驱动对于音视频技术持续演进来说极其重要。

为了做好大数据驱动，我们从 SDK、引擎、调度服务器、频道与流管理服务器、边缘媒体服务器、实时传输网，也就是音视频业务的每一个环节都做了数据采集上报。我们上报了100+的关键事件，这些事件包括了用户行为，各系统行为，QoS 行为，还有很多的音视频 QoE 体验相关的关键事件，比如：分辨率切换、登录耗时、出图时间等等；还上报了300+的核心指标，这些指标包括：全链路的系统运行时状态，QoS 指标，QoE 指标以及服务端状态。这些上报的数据都会经由我们大数据平台进行处理，日均有百亿行的数据，有 T 级的存储。利用我们的高性能大数据平台，我们可以秒级的实时处理这些数据。有了这些数据以后，我们可以驱动很多事情，包括质量透明平台（对用户开放）、业务质量报表、产出接入调度优化、大网路由优化、QoS 算法优化、QoE 故障实时告警、各维度聚合质量分析。云信新一代音视频，就是在源源不断的大数据驱动下，不断打磨，提升自身的质量。

展望

最后来对 RTC 技术做个简单的展望，同时也是我个人比较关注的几的技术方向，我认为：低成本 RTC 会成为业界一个标配，低成本体现在两个方面：接入低成本和费用低成本， RTC 的接入会像现在 CDN 接入这么简单，而价格也会匹配目前 CDN 的价格，RTC-CDN 应该会在未来几年内到来；而未来的音视频编解码还是会断的迭代创新：比如视频编码器 AV1 和基于 AI 的音频编器 SoundStream，未来肯定还会涌现出更多优秀的音视频编解码器；对于 Web 技术：我个人比较关注 Webtransport 和 WebCodec，我相信 Webtransport 会大大优化 Web 端的传输方式，而 WebRTC 的 Next Version 会开放更多 low level 的底层接口，也会让 WebRTC 的使用更加灵活，值得大家保持持续关注；AI 与大数据挖掘技术，肯定会不断在 RTC 领域中发挥重要作用。

我坚信技术的进步是永无止境的，同时技术也是可以改变世界的，音视频领域未来还有无限可能的！

 作者简介 

吴桐，网易云信流媒体首席架构师，网易多媒体开发专家。2013年从浙江大学硕士毕业后加入网易，现任网易云信云平台技术负责人、在线教育行业线负责人，全面负责实时音视频、互动白板、低延时直播、互动直播、WE-CAN 全球传输网等项目的架构设计与研发，对音视频、高性能服务器以及网络传输等领域均有多年的工作与项目经验。