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 战略。

网易云信 RTC 音频 QoS 综述

分段 QoS 的优势在于，上下行独立进行 QoS 战略有利于阻隔上行段、下行段不同网络情况，对每条链路适用更佳的应对办法。但其劣势在于，战略的设计、开发、调优会更加杂乱，问题排查难度增加，服务端性能或许成为瓶颈。

带宽估量

带宽估量主要用来对发送端（或服务器的下行转发端）进行码率操控。

上行端侧经过 GCC（Google Congestion Contrl）算法依据接纳端的数据反应对其发送带宽进行估量。 估量出的带宽会分配到编码码率、RED 码率、FEC 码率、RTX 码率、PADDING（填充）码率。尽管带宽估量算法在各公司是大同小异，可是带宽分配战略却是形形色色。因为如何分配编码码率和抗性码率（包含 RED、FEC、RTX）决议了一款 RTC 产品在媒体质量、会话推迟、带宽消耗上的竞争力凹凸。

网易云信 RTC 音频 QoS 综述

服务器下行转发侧相同也有带宽估量算法。服务端对下行链路的带宽估量结果是依据会话的，但服务端一起接通一个会议中的多个下行会话，因而服务端能够汇总多个下行会话的带宽估量结果，结合场景，运用如 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从业人员去探索。