文｜网易云信资深流媒体开发工程师
背 景
科技的进步以及通讯基建的高速发展，使得人们对交流的模式要求越来越即时，对交流内容要求越来越具象，这些要求催化着内容交换模式的不断发展，从传统的信件，到短信电话再到互联网场景下的微信语音、抖音短视频、视频直播及实时音视频通话。随着5G正式商用元年的真正到来，更加即时与具象的实时音视频通讯将被更广泛的应用。实时音视频系统，是一个相对比较复杂的内容传输系统，从大的流程上来讲，系统覆盖音视频采集、音视频编码、音视频传输、音视频解码、音视频绘制。想要做到高质量的音视频通话，每个环节都需要丰富的手段才能进行各种场景及设备的适配与效果提优。
实时音视频的最显著的特点是低延迟，也就是说实时音视频对于网络的要求是非常高的，甚至可以说是矛盾的。一方面它为了追求低延迟，它能够允许网络传输中的丢包，另一方面因为视频编解码的传递参考性，任何的丢包都会造成很大的视频质量的损失，最终将降低实时通话的QoE评价，所以又不能容忍网络传输中的丢包。为此搭建一个高质量实时音视频系统，尤其是多方参与的会议系统，应对于参与通话各方上下行网络复杂性（带宽受限/丢包/抖动/高时延）的传输QoS策略的设计是非常有必要的。本文就会议场景下，服务器端的QoS策略，做一些详细的分享。
会议场景分段QoS
会议场景的通话，决定了参与通话的各方都要通过中转的流媒体分发服务器进行传输内容的交换。会话传输链路可以划分为实时通话发送端到流媒体分发服务器的上行传输链路，以及流媒体分发服务器到实时通话接受端的下行传输链路。上下行传输链路，从服务器角度而言其承担传输角色是不同的，传输策略作用轻重亦不相同，为此针对于这种多人会议场景，需要制定上下行独立的QoS传输方案，去保障上下行的传输质量。我们称之为分段QoS策略。
上行QoS
网易云信的设计里，QoS的强控制权都交由发送端。接收端做被动的接受信息反馈和丢包请求与恢复。针对于上行QoS的策略，服务器端作为接收端，设计了一系列的QoS手段，进行高可靠的链路传输。包括但不局限于：丢包重传请求（NACK）、前向纠错（FEC）、关键帧请求（PLI/FIR）、接受信息反馈（FeedBack）等手段。这里选取两个抗丢包手段做一些深入的讲解。
丢包重传请求
丢包重传请求，简单的实现就是服务器作为接收端，在实时接收传输的流媒体的时候，进行传输层媒体包序的连续性检查，当出现非连续包出现的时候，经过一定的超时时间（考虑到实时音的低时延要求往往这个超时时间会设置的比较短），便会向发送端进行丢失包的重传请求。由于丢包的不确定性，丢失的包序的分布也会呈现出不确定性。为此我们需要设计出一个合适的重传协议来覆盖丢包的各种分布情况，达到重传请求的最小带宽占用的目的。
我们设计了灵活NACK请求协议，其协议设计可以很好的解决上述情况：
协议允许单个NACK请求包对多个楾往是细节决定最终的通话质量。
音视频通讯本身一个复杂的通讯系统，本文开头也提到了，QoS的设计也只是其中的一环，想要达到最佳的通话效果，每个环节做到环节内的最优，环节间也要建立有效的反馈调节机制。才能将整个端到端的体验做到最优，这样才能得到用户的认可。
推荐阅读
《从入门到进阶｜如何基于WebRTC搭建一个视频会议》
《开源｜如何开发一个高性能的redis cluster proxy？》
点击【阅读原文】，了解网易云信。
转播
