一、网络背景
移动流量卡网络，会呈现'平时极稳，切换极抖'的特征。稳定网络下几乎不丢包，并且报文间时间间隔稳定。但是在基站切换等场景下，网络会经历'突发高延迟 -> 连续大丢包 -> 积压包密集回补'的完整故障链条。
二、问题分析
这种情况下，原生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函数也对流量网模型不友好：
这个代码本质逻辑：当前包的绝对网络延迟 - 窗口内最快包的绝对网络延迟。也就是说，所有的抖动计算都是相对于"窗口内最好的那个时刻"而言的。
这样的计算，在"基站切换"引发的 "突发高延迟 -> 连续大丢包 -> 积压包密集回补" 这一完整故障链条中，基于"滑动窗口内最小值"的统计方法存在严重的统计丢失和特征掩盖问题。无法真实反映故障的剧烈程度，反而会将秒级大抖动平滑为普通波动。