音视频RTT值为何存在差异？是否为RTCP通道ping检测结果？

RTT值的统计来源 #

音视频流的RTT统计结果并非全部来自RTCP通道的ping检测，不同实时通信框架的实现逻辑差异很大，常见的统计口径有三类：

• 标准RTCP收发报告（SR/RR）计算：这是RTP协议规定的通用RTT计算方式，发送方在SR包中携带自身NTP发送时间戳，接收方收到后在后续反馈的RR包中回写对应时间戳，发送方收到RR时用当前时间减去原始发送时间、扣除接收方的处理延迟偏移，就能算出链路RTT。注意这个计算是音频、视频流各自独立执行的，不会跨流复用计算结果。
• 拥塞控制/丢包重传反馈计算：如果开启了WebRTC类框架的拥塞控制，视频流通常会单独通过传输层拥塞控制反馈（TWCC）、丢包重传请求（NACK）的收发时间差计算即时RTT；音频流因为码率低、RTP包间隔大，多数实现不会单独为其跑TWCC统计，仅依赖RTCP SR/RR的周期计算结果。
• 应用层主动探测：部分实现会发送自定义RTCP APP包做链路连通性探测，如果这类探测是绑定单条媒体流的，统计结果也只会计入对应流的RTT指标，不会同步给其他流。

音视频流RTT存在差异的核心原因 #

你提到的“同链路下音视频RTT应大致相近”的常规认知，成立前提是音视频包走完全相同的传输路径、享受相同的转发调度优先级、使用相同的统计窗口，实际生产环境中这几个前提经常不成立，常见的差异诱因包括：

• 网络QoS优先级调度差异：绝大多数运营商网络、企业防火墙、家用WiFi的QoS规则会给音频流标记更高的DSCP优先级（通常是EF加速转发等级），视频流一般标记为AF41或者普通流量优先级。高优先级的音频包会被网络设备优先转发，链路排队延迟远低于视频包，最终统计到的RTT自然更低。如果是开启了多路径传输的场景（比如ICE多路径选路、移动端WiFi+蜂窝链路聚合），音视频甚至可能走不同的物理链路，RTT差值会达到几十到上百毫秒。
• 统计逻辑差异：音频流对抖动敏感度更高，RTT统计通常采用更短的时间窗口，且会自动过滤偏离均值过大的异常抖动值；视频流因为存在I帧大包、码率突发的特性，统计窗口更长，会把突发拥塞导致的排队延迟全部计入RTT。比如视频发送I帧导致网卡发送队列积压时，视频流统计到的RTT可能瞬间涨到几百毫秒，而音频流因为优先级高不受队列积压影响，RTT仍会维持在几十毫秒的正常水平。
• 端侧调度差异：多数实时通信客户端会给音频流分配独立的发送线程、接收缓存，避免被其他任务阻塞；视频流一般走通用媒体处理线程，如果视频线程出现CPU调度抢占、解码卡顿导致缓存堆积，RTT统计会把这部分端侧处理延迟算进去，结果会比纯链路RTT高很多，音频流因为独立调度不受这类问题影响。
• 重传策略差异：视频流通常开启NACK丢包重传，部分实现的RTT统计会把重传包的往返时间计入均值；音频流因为对播放时效要求极高，超过音频缓存时长的丢包不会触发重传，统计到的都是首包传输时延，不会包含重传带来的额外延迟。

补充：如果手动关闭QoS优先级标记、音视频共用同一套RTCP统计实例、关闭多路径传输、且端侧媒体处理没有阻塞的场景下，音视频流的RTT确实会基本对齐，差值一般不会超过10ms。

内容的提问来源于stack exchange，提问作者Kris