RTC、QoS、WebRTC 的定义
RTC 实时通信，泛指各种数据的实时传输技术，包括音频，视频，文本，图片等媒体和非媒体数据的实时传输。
QoS 服务质量，指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力，是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。
RTC 技术的出现满足了用户通过互联网进行实时音视频通话的需求，在 QoS 技术的加持下，RTC 技术在复杂的网络条件下能达到更高的弱网抗性、更低的延迟，极大地提升用户的实时通话体验。
WebRTC 是一个由 Google 发起的实时通讯解决方案，其中包含视频音频采集、编解码、传输、QoS、音视频渲染等功能。其名为 WebRTC，但是实际上它不光支持 Web 之间的音视频通讯，还支持 Android 以及 IOS 端。由于该项目是开源的，各即时通讯厂商都基于 WebRTC 进行研究、开发，研制自身的全平台的 RTC 解决方案。
WebRTC 中有很多优秀的算法、设计值得研究，音频 QoS 技术就是其中之一。
音频 QoS 技术
音频 QoS 技术主要包括了：带宽估计及编码码控、DTX、FEC、RED、RTX/NACK、加速/减速/PLC 等。
音频数据虽然没有视频数据那么大的量，但在 QoS 方面同样要面对：带宽、延迟、质量之间的三维平衡。把音频 QoS 技术的各项能力归纳到这三维平衡问题中时，我们可以知道：
带宽估计及编码码控：在既定的网络带宽情况下，估计的带宽越高、编码码率越高，音频质量越好；
DTX（输入编码器的音量低时编码器编出静音指示数据，后续不出编码数据或出静音指示数据，直到输入音量不再低）：有效节省静音情况下的编码码率；
FEC（通过前向纠错编解码算法，实现丢包恢复）：冗余度越高，恢复率越高，但带宽消耗越大；分组越大，恢复率越高，恢复延迟越大；在低丢包率、非连续丢包情况下，具有码率优势；
RED（原始音频包同时携带冗余的音频包）：冗余层数越多，带宽消耗越大；在低丢包率、非连续丢包、高延迟情况下，具有恢复延迟优势；对于冗余包拓展头的支持程度因实现而异；
RTX/NACK（丢包重传/丢包请求）：丢包重传属于按需重传，丢包越高，重传需求越高，带宽消耗越大，需要避免重传风暴；在高丢包、连续丢包情况下，具有恢复率优势，但有较大的恢复延迟劣势；
加速：接收端缓冲过多时，通过加速降低缓冲量，降低延迟，会带来一定的加速感；
减速：接收端缓冲不足时，通过减速提升缓冲量，增加延迟，会带来一定的减速感；
PLC（丢包补偿）：接收端缓存缺失时，通过收到的前序包模拟丢失包，会带来一定的音质损伤。
QoS 分段策略
从整体角度看，RTC 实时音视频系统至少会涉及 3 个端：发送端、服务端、接收端。云信 RTC 以 SFU 架构实现客户端媒体流的接入和转发。以此为基础形成了发送端到服务、服务到接收端（服务级联由网易云信 WE-CAN 大网提供）的分段 QoS 策略。
分段 QoS 的优势在于，上下行独立进行 QoS 策略有利于隔离上行段、下行段不同网络情况，对每条链路适用更佳的应对方法。但其劣势在于，策略的设计、开发、调优会更加复杂，问题排查难度增加，服务端性能可能成为瓶颈。
带宽估计
带宽估计主要用来对发送端（或服务器的下行转发端）进行码率控制。
上行端侧通过 GCC（Google Congestion Contrl）算法基于接收端的数据反馈对其发送带宽进行估计。估计出的带宽会分配到编码码率、RED 码率、FEC 码率、RTX 码率、PADDING（填充）码率。虽然带宽估计算法在各公司是大同小异，但是带宽分配策略却是五花八门。因为如何分派编码码率和抗性码率（包括 RED、FEC、RTX）决定了一款 RTC 产品在媒体质量、会话延迟、带宽耗费上的竞争力高低。
服务器下行转发侧同样也有带宽估计算法。服务端对下行链路的带宽估计结果是基于会话的，但服务端同时接通一个会议中的多个下行会话，因此服务端可以汇总多个下行会话的带宽估计结果，结合场景，利用如 topN 带宽回传上行做码率约束、VIP 用户 QoS 优先保证等策略，提升服务端的带宽利用率。
在带宽估计领域还有许多可以优化的方向，比如：反馈的码率纳入带宽估计、基于机器学习进行带宽估计和分配。
DTX 编码
OPUS 音频编码器的 DTX 特性，能够有效降低发声静音时的码率，它利用静音时发送端每 400ms 编码发送一个 DTX 包通知接收端静音状态仍在持续，接收端在接收到首个 DTX 包后，进入 DTX 状态，每次音频设备获取数据时编码器输出一个静音帧。服务端对 DTX 进行透传。
WebRTC 利用 OPUS 的 DTX 特性引入了一些断流误判、收包反馈的问题。云信对此进行了优化，利用了静音状态码率低的特性，同时保证了数据流的连续性。
FEC
端侧 FEC 分带内和带外两种，WebRTC 中视频是通过带外 FEC（ULPFEC、FLEXFEC）来产生冗余包，音频则可以通过 OPUS 带内 FEC 、带外 FEC 来生成冗余包。服务端 FEC 是用带外 FEC。
带内 FEC 由于会占用一部分编码码率，所以对音频的音质会有所降低。带外 FEC 不会影响音质，但会额外占用网络带宽，各有优缺点。
FEC 典型的编码方式有 XOR 和 Reed Solomon。WebRTC 的带外 FEC 使用的是 XOR 编码方式，其特点是计算量相对少，但其抗丢包能力有限。
在 WebRTC 中，带外 FEC，不论是 ULPFEC，还是 FLEXFEC 都是根据 MASK 掩码来确定 FEC 包和被保护的源 RTP 包的映射关系，其中定义了两种类型的掩码：RandMask 和 BurstMask，前者在随机丢包中保护效果要好些；后者则是对突发导致连续丢包效果会好些，但是不论哪种，都有其缺点。
FEC 冗余度和原始包分组长度计算准则是：根据丢包和 rtt 预置分组长度，在该分组长度下，根据贝叶斯定律，在当前丢包率下，确定至少需要多少冗余包能够保证接受到足够的原始包和冗余包来通过 FEC 解码恢复丢包。值得注意的是，分组长度对 FEC 的恢复延迟有决定作用。
RED
RED 是在一个包中额外携带前序若干包的抗性策略。其冗余层数以最大包长度为限制，同时也受到耗费带宽的约束。其优势在于 RED 包携带的冗余数据与原始包序号越接近，RED 恢复时延越低；原始包与冗余包的最大序号差，决定了最大恢复延迟。
端侧 RED 打包常采用连续相邻序号作为冗余数据，跳跃序号的打包方式未证明存在明显恢复优势，但会引入更大的平均恢复延迟。
服务端下行侧 RED 打包受到上行弱网、抗性恢复能力、恢复时间影响。若采用连续相邻序号作为打包方式，则需要等待上行丢包的恢复包；若采用跳跃序号的打包方式，则会引入更大的下行侧 RED 恢复延迟。延迟取决于上行丢包恢复的耗时。因此分段 RED 策略下，若上行存在弱网，那么服务端下行侧 RED 的恢复时间优势就不再明显。此时优化上行链路弱网的恢复时间更为有效。
RTX
RTX 是弱网抗性算法中引入延迟最严重的。一个包的重传请求到该重传包被成功恢复，至少要经历一个 rtt 耗时，在丢包严重、rtt 较大时，重传包也可能丢失进而造成多次重传，这个耗时将变得不可接受。
重传耗时的主要决定因素是：rtt、丢包率、重传请求时机、重传请求响应策略。其中 rtt、丢包率可能由于链路带宽拥塞、弱网测试引起的，重传请求时机取决于请求间隔约束、当前数据缓存量、丢包检测机制等；重传请求响应策略取决于发送端缓存、发送端拦截机制、估计带宽、是否有冗余重传机制等。综合考虑以上因素，可以极大地优化重传效果（包括恢复效果、恢复耗时、重传码率）。
结语
在网络飞速发展的今天，音频 QoS 的优化显得比视频更加容易，因为带宽的顾虑会越来越少。但是从企业运营角度考虑，当 RTC 业务中的音频业务占据主导时，控制音频带宽的成本时非常有价值的。这是音频 QoS 优化中，直接和利润相关的部分。因此上述策略中，有许多都提到了带宽耗用，这意味着我们不能一味追求抗性和实时性，而忽略了带宽成本的增加。
QoS 的终极课题就是在有限的带宽资源下，提升弱网抗性，降低恢复时延。在这条路上，还有非常多的空间等着 QoS 从业人员去探索。