后疫情时代，云会议已经被越来越多的企业熟知、使用，正在成为企业数字化办公的“新基建”，而支撑云会议的底层技术，RTC、音视频技术等也备受关注，正在赋能更多行业提升数字化管理和无接触服务能力。本次邀请到科天云研发中心总经理张军分享RTC中的两大难点：兼容海量设备和应对复杂网络，分享科天云在其中的客户需求洞察、技术思考和技术创新实践。

内容源自科天云研发中心总经理 张军在视频会议下半场圆桌上的分享。

本次非常荣幸代表科天云做第一个分享，我过去20年都在做会议，今天我会根据近期我们在视频会议中设备兼容和网络应对的实践经验，进行分享。

首先介绍一下我自己，我从2003年加入Webex，2007年思科收购Webex后去了思科；2014年思科和TCL合作成立科天云，于是来到了科天云。2014年年底到今天在科天云已有6年半。在这个过程中，在科天云做了音视频基础平台，基于它做了视频会议、智能客服，将这些音视频产品与相关新兴技术做融合。

1 科天云介绍

上图是目前科天云做的产品。公司团队汇集很多曾在思科、华为、IBM等企业就职的人才，有非常丰富的音视频产品研发经验。

2 以音视频技术赋予各行业新的生命力

我们针对众多终端做了比较多的适配，一些需要音视频技术的终端可能大家都想不到，例如门铃、扫地机器人、无人机，也需要接入会议音视频的能力。我们自研的音视频通用SDK可将各种设备接进来，无论是在公有云上直接用，还是希望在私有云上部署。

3 RTC两个难点

RTC的两个难点：一是如何兼容海量设备、二是怎样应对复杂多变的网络。

3.1 适配海量终端

先从设备开始。图上主要说明了视频会议如何涵盖从口袋到董事会会议室的需求，从最左边最简单的手机、Pad，到桌面设备，到双屏、三屏的网真。用过视频会议的人应该都听说过网真，它的屏幕可以与真人大小一样，很多电视采访都使用了网真设备。

3.2 适配海量终端

很多人在家开会的时候可能没想到，但来了公司在会议室中大多数还是使用SIP\H.323硬件终端来开会。一些有安全要求的制造业客户用VDI虚拟桌面，这种硬件跑会议会碰到很多问题，VDI点对点呼叫会有所谓发卡效应，音视频都要到虚拟服务器绕一圈。在这种服务器上做音视频、会议客户端要采取特殊措施。像SIP\H.323协议兼容其实非常复杂，最少要兼容国际上三大厂商例如思科、POLYCOM、AVAYA，国内三大厂商例如最早的华为、中兴、厦门的亿联，这些头部厂商都要支持，这些厂商多年前的老设备老版本的兼容尤其挑战，在后面会讲到一些细节。

3.3 适配海量家电

到去年，随着万物互联的兴起，以及母公司TCL（因为其做屏幕有各种家电）提出将整个音视频带到所有家电中的战略，科天云开始扩展适配终端的类型。这也是非常大的挑战，以前主要做安卓手机，现在安卓电视要适配CPU、GPU，还有分辨率的适配，竖屏变横屏。现在市场上也推出了带摄像头的扫地机器人，带屏幕的吸油烟机、冰箱上有屏幕，智能门铃也有屏幕摄像头，这些设备多种多样。使用Linux系统的，例如图上右下角的树莓派扫地机器人。智能门铃是用华为LiteOS，还有一些是厂商自研的芯片，比如齐感芯片，配备FreeRTOS操作系统去做硬件和操作系统的适配。

我认为这是很有意义的，一些老人和小孩还是习惯看电视，新的电视上有摄像头，在外办公的我们想看家里的老人和孩子时，就可以很方便的在手机点一下，不需要在家那端的老人孩子做任何操作音视频就通了，很方便，时刻关爱家人。包括家庭的消息通和访客通话在所有家电都打通，可以产生协同效应。很多年前做会议室2B市场，疫情后，我们也在实践将音视频在海量家电中做适配。这些家电与在手机上用的芯片有很大不同。

3.4 章鱼跨平台全端SDK

我们花了很大的功夫去做到上述终端的适配。用纯C代码实现端侧所有功能，WebRTC是用C++写的，用C语言才能做到可移植，做到非常小的安装包，能适应超低功耗，利用不同编译器适应不同平台。虽然我们做了移植和裁减，但在抗弱网能力和首帧低延时方面还是实现了非常好的效果。

4 音频弱网卡顿现象

我将音频流程简单画了一下，音频整体比视频从发送到接收要简单一些。等下还会讲相较于音频更复杂的视频处理，整个损耗大部分发生在网络侧，设备侧损耗和信号处理方面也有一些，抗丢包拥塞控制方面，音视频的技术都类似。

4.1 音频抗丢包算法比较

上图简单的对音频抗丢包技术做了总结、比较。音频整体占用带宽不是很大，整体即使是64K的宽带音频，那翻一倍做FEC冗余也可以接受。很多客户还是希望用基于web的音视频SDK和自己的OA和CRM系统在浏览器里直接集成。在浏览器里用Opus带内FEC，抗丢包有上限，不像自己做的软客户端，可以有较多的抗弱网手段，根据丢包做动态冗余度调整。关于丢包重传，错误隐藏技术，这样的分享在LVS中有很多，本次就不细讲了。

4.2 章鱼音频抗丢包

在客户端方面，我们科天自研的冗余算法比较好，实测下在70%左右的网络丢包场景下音频可接受，在浏览器和SIP终端能做的优化手段，没有软客户端那么多，只能利用Opus带内FEC，可对抗40%左右丢包。

5 章鱼视频QoS指标

视频的QoS可以分成以下几个主要指标：首屏、帧率、延迟、尺寸、码率、卡顿。

5.1 RTC视频全流程

上图是RTC视频全流程的简图。它比音频复杂，做视频传输的核心是码率控制器，需要控制编码码率、FEC冗余度、丢包重传码率，最后通过Paced Sender控制发送码率到接收端。期间经过了很多代的迭代，最早完全靠接收端在REMB报文中反馈可接收带宽，现在主要在发送端进行带宽评估（基于接收端反馈的Transport-CC报文）。

5.2 章鱼视频抗丢包

最后通过以上各个环节优化，视频方面可对抗60%左右的丢包。根据NACK请求进行丢包重传，在低RTT的场景下NACK重传的抗丢包效果还是比较明显，同时也结合一些FEC的纠错。SIP在视频方面需要根据SIP设备反馈的丢包率及时延情况，动态调整视频分辨率和码率，SIP终端的软件硬件都比较难控制，有很多厂家，相较软客户端调优难度系数大。

5.3 视频流控——BBR

BBR这次不多说了，去年4月，谷歌在WebRTC里把这一部分代码删除了，原因是相较于GCC其整体效果有一定差距。

5.4 视频流控——GCC

上图是比较经典的谷歌拥塞控制模型，我们在下面案例里借鉴了它的Pacer模块。

5.5 通过Pacer来做视频流量整形

这里分享一个案例，如果发起会议推流和共享的是SIP硬件终端，它通过电脑HDMI线共享桌面，视频也通过SIP终端推流上来。另一端也是SIP终端，业内叫双流，左边是视频流，右边是共享流，双屏显示。一些老的SIP终端处理能力有限，会遇到一些问题。

去年遇到的客户CFO很喜欢用桌面SIP终端做共享，共享内容的I帧很大，财务报表密密麻麻数字，用各种颜色标注，接收端在弱网情况下有时看到有花屏和不太清楚的地方，因为发送端和接收端都是SIP，接收的设备比较老。如果密集地发共享流I帧，接收端由于CPU、内存资源有限，会在内核中将部分数据包丢弃掉，所以要在转发时做流量控制，让整体流量整形之后再转发，特别是共享流方面，流控带来的效果提升还是比较明显的，可以看到I帧和P帧有近乎十倍的流量差别，如果有多少发多少不受控制是会产生拥塞的，在转发部分一定要做好流控，相当于在洪水来之前修大坝。

6 Bandwidth Estimation

从WebRTC M55加入了发送端的带宽评估，之前主要是接收端做反馈，WebRTC现在主要通过发送端基于接收端反馈的Transport-CC来做带宽评估，和REMB接收端反馈的报文不一样，包括延时滤波器也用了比上一代有改进的技术。

7 通过FMO来做视频错误隐藏

之前分析了在两个SIP终端之间的屏幕共享在弱网情况下会引起接收端花屏的解决方案，在弱网情况下的视频也会有类似问题，做会议的同行知道用SIP终端接收时有可能是演讲者模式、等分屏模式。这时候视频是通过MCU，把视频混屏之后再推到接收端，我们在服务端重新编码时把FMO加进去，好处是防止错误被放大，不会引起长期大面积花屏，对于这一部分有很多细节大家可以自行去查。它的缺点是编码复杂度增加，且增加了带宽，但任何的优化都是有一定成本和代价的。

8 章鱼信令升级

如果把音视频都做到较好的弱网对抗性了，信令就是我们接下来需要优化的点了，要考虑信令的升级。最早比较多同行用WebSocket传信令，还有人在私有的RUDP协议上做信令传输，WebRTC新标准在推WebTransport，用它做信令升级，相较于基于TCP的WebSocket有很多优势。这里简单罗列了五个：更快连接握手、连接多路复用、协议内有内置FEC机制，支持连接迁移，如果从WIFI到4G，在回家，到Office切换网络时会议重连过程效果较好。

9 WebTransport

简单做了比较，新的WebTransport将直接基于Quic的Transport放弃了。新的标准是WebTransport over HTTP3，对比现在用WebSocket和dataChanel做信令，还是有改进的。

10 全链路质量监控来反馈传输优化和设备兼容情况

最终还是需要有一套全链路质量监控体系来对传输优化和设备兼容情况做反馈。例如我们写代码就需要有单元测试来做重构的反馈安全网才放心。我们也有很多指标做反馈。看一下传输优化和设备兼容的情况，做好指标上报和事件上报。

以上就是我今天的全部分享，谢谢大家！