WebRTC QoS方法之NetEQ在流量卡弱网应用下失效

一、网络背景移动流量卡网络会呈现‘平时极稳切换极抖’的特征。稳定网络下几乎不丢包并且报文间时间间隔稳定。但是在基站切换等场景下网络会经历‘突发高延迟 - 连续大丢包 - 积压包密集回补’的完整故障链条。二、问题分析这种情况下原生WebRTC会有几个问题1、丢包NACK失效无法恢复丢包无法恢复主要原因是经历秒级大抖动后音频缓冲区池子里面的水已经干了来了一个音频包无论与之前报文是否连续马上直接播放。导致NACK重传失效。要么不会申请重传要么即便重传等报文到来该音频已经播放完了。2、ReorderOptimizer 抖动估算机制失效原生 WebRTC 的 ReorderOptimizer 模块主要依赖移动平均结合直方图统计来动态计算目标延迟这种基于统计分布的模型在面对“基站切换”产生的非平稳流量时表现出严重的滞后性故障发生期出现秒级大抖动直方图的长尾分布开始向右偏移。但由于统计算法需要积累足够的异常样本才能显著改变分布中心导致估算值缓慢爬升。此时实际缓冲区早已干涸而算法尚未及时提升目标延迟以预留缓冲空间直接导致播放卡顿、 NACK 失效。故障恢复期积压包密集回补当切换完成积压数据包密集到达时直方图左侧迅速堆积大量“早到”样本。然而受限于平滑策略算法无法立即识别这是“网络恢复信号”导致估算值缓慢下降。这使得 NetEq 在本应激进加速Accelerate以消除延迟累积的关键窗口期依然维持着虚高的目标延迟人为拉长了端到端延迟错失了对用户无感知的“消缓冲”良机。所以这种场景下基于历史统计的 ReorderOptimizer 不仅丧失了预测指导价值其缓慢的收敛特性反而成为了阻碍快速恢复的负面因素导致“该扩音时没扩够该加速时没加”。3、PacketArrivalHistory网络抖动算法缺陷分析arrival_timestamp时间的计算并不是操作系统层面的系统时间而是基于TickTimer的逻辑时间TickTimer是在NetEqImpl::GetAudioInternal函数中进行计数。默认NetEqImpl::GetAudioInternal函数每次输出10ms的音频数据若某些系统一次需要20/60/120ms数据就需要连续调用NetEqImpl::GetAudioInternal导致arrival_timestamp计算的时间与实际偏差很大。这样会导致虚假抖动注入、统计模型污染最终决策错误。GetPacketArrivalDelayMs函数也对流量网模型不友好这个代码本质逻辑当前包的绝对网络延迟 - 窗口内最快包的绝对网络延迟。也就是说所有的抖动计算都是相对于“窗口内最好的那个时刻”而言的。这样的计算在“基站切换”引发的 “突发高延迟 - 连续大丢包 - 积压包密集回补” 这一完整故障链条中基于“滑动窗口内最小值”的统计方法存在严重的统计丢失和特征掩盖问题。无法真实反映故障的剧烈程度反而会将秒级大抖动平滑为普通波动。