摘要

  • RTCP XR 报告可以包含丢包游程、重复包、接收时间、往返时间、语音质量和抖动缓冲指标，但每个数值仍属于某个报告者、某条媒体流、某个测量点和某段窗口。
  • 缺少报告块不等于指标为零，127 等不可用哨兵不等于坏分数；网络丢失、接收端丢弃、解码播放和人的感受也不能压成同一个结论。

数字增加，边界也增加

传统 RTCP 接收报告只给出有限的统计。2003 年 11 月发布的 RFC 3611 定义了 RTCP Extended Reports，分配了包类型 207，并用“块类型 + 长度”建立可扩展框架。最初七种块涵盖 Loss RLE、Duplicate RLE、Packet Receipt Times、Receiver Reference Time、DLRR、Statistics Summary 和 VoIP Metrics。后来 IANA 登记了更多类型。

这套结构的价值在于可扩展，也正因为可扩展，接收方被允许跳过自己不认识或不相关的块。一个采集器没有解析某个块，只能说明它没有取得该块的语义；一份 XR 包没有携带某项，只能说明该项没有出现在这次报告中。二者都不能被数据库默认值翻译为零。

XR 包头写的是报告发起者的 SSRC，许多报告块内部又写明被测媒体源的 SSRC。谁作证与谁被测从协议上就是两个身份。只留下数值、删掉两个身份的区别，会让接收端观察、转发设备观察和汇总代表的报告混成一种“网络事实”。后来的 Reporting Group 机制进一步说明：公共报告源可以代表一组 SSRC，但媒体专属指标仍必须由相关 SSRC 提供。

规范本身也有版本。RFC 3611 的三项已验证勘误修正了接收端 RTT 参数名、无参数 SDP 属性的冒号语法，以及 burst density 示例中的数值。使用哪个解释不是实现细节；如果事故分析无法说明采用了哪个修正版，相同字节可能被两个系统赋予不同含义。

不能把 127、空白和零装进同一个格子

VoIP Metrics 中一些字段用 127 表示 unavailable。它不是 127 分，也不是“最差”，更不是零。部分字段还有自己的有效范围、保留值和忽略规则。会话拓扑也影响语义：某些会话质量指标并不适用于多播会议，应明确标记不可用。

因此，一个成熟的数据模型至少需要四个状态：测得为零、无法测得、没有请求或没有上报、采集器不认识。还可能有第五种：为了隐私而过滤。若这些状态都映射为 SQL 的 0 或 null，报表看起来整齐，证据却已经丢失。后续任何模型都无法判断“没有问题”与“没有视野”的差别。

缺块语义同样适用于可选指标。Statistics Summary 通过标志说明报告了哪些字段；块本身也可能不存在。应用可以只选择一部分接收端上报，限制块大小，降低频率。没有收到某个接收端的 Loss RLE，不是那台接收端零丢包；它可能没有被选中、没有协商、没有实现、报告太大被裁剪，或者报告在路上丢失。

一条媒体流里至少有三种“丢”

网络丢包表示预期报文没有到达测量点。接收端丢弃表示报文可能已经到达，却因过早、过晚或不符合抖动缓冲策略而失去用途。应用层还可能在解码、组帧或播放阶段出现第三种失败。RFC 3611 把 loss 与 discard 分开，后续 RFC 7002、7003、7005 和 7097 又细化了丢弃计数、突发/间隙、缓冲器和逐包 RLE。

这个分界直接决定责任。网络 loss 稳定而 discard 上升，应该先检查时延变化、缓冲适配、设备负载和接收策略；loss 上升则要复核传输路径。即使二者都很低，也不能推出用户听得清楚：编解码器、丢包隐藏、冗余、帧边界和应用卡顿仍会影响结果。传输、终端、应用和人是四个证人，不是四个字段拼成的一个证人。

MOS 和 R factor 是估计值，不是用户亲口提交的评价。它们可以支持诊断，但必须附带算法、输入、适用场景与不可用状态。把估算分数命名为“用户体验真值”，会让模型的假设替代用户结果。

窗口决定数字到底说了什么

Loss RLE 和 Packet Receipt Times 通过开始、结束序列号限定范围，还可能使用 thinning 按规则省略观察，以控制块大小。被 thinning 的报告可以忠实执行协议，却不是完整逐包日志。图表若把未上报的序列位置自动补齐，就在创造数据。

汇总指标还要说明属于最近一个报告间隔、从会话开始累计，还是某个另行定义的时间段。RFC 6776 后来定义 Measurement Information Block，携带会话起点、当前窗口的扩展序列边界、最近窗口时长和累计时长。RFC 6792 进一步区分 interval、cumulative 与 sampled。相同的字段名，不同窗口就是不同数学对象。

RFC 8861 指出：如果 XR 与对应的 SR/RR 位于不同 compound packet，测量窗口没有同步，组合价值会下降。采集平台按“入库时间”对齐会制造同时性。真正需要对齐的是被测区间、序列空间和报告来源，而不是消息抵达数据库的毫秒数。

Burst/gap 也由参数定义。Gmin 是划分突发与间隙的阈值；RFC 3611 推荐 16，并要求在会话期间保持非零且恒定。相同事件序列在不同阈值下可能得到不同分类。没有保存 Gmin、窗口和勘误版本的趋势线，无法承担跨供应商比较。

更详细的报告也更昂贵、更敏感

XR 仍受 RTCP 带宽约束。块越大，平均 RTCP 包越大，平均报告间隔可能随之拉长。应用会限制块大小、thinning、上报者数量和频率。要求“所有指标都更细”可能反过来降低时间分辨率。观察系统会影响观察节奏，这是合同设计的一部分。

RFC 3611 的安全章节还明确指出，XR 带来更高的保密风险。逐包信息可以帮助推断多播拓扑，VoIP 指标可能泄露个人信息。加密或过滤可以保护这些内容，却会损失监测信息。隐私控制上线后仪表板出现空白，首先应记录为可观测性变化，而不是质量突然变好。

正确目标不是无上限采集，而是按用途分级：谁能读逐包信息，保存多久，何时只暴露汇总，哪些字段因隐私被删除。可以拒绝披露敏感细节，但必须保留“已过滤”这一事实，不能用零替代。

让每个数值带着自己的证词边界

一条可审计记录不需要很庞大：报告者 SSRC、被测 SSRC、会话关联、块类型、规范/勘误版本、测量点、窗口类型、序列边界、时长、单位、时钟、payload context、thinning、算法参数与哨兵解释。再列明哪些块未请求、未收到、不认识或被过滤。最后分别关联网络到达、终端处理、解码播放和用户结果。

这是一种最小共同层。它允许不同设备交换可比证据，又不要求所有端点公开所有本地状态。运行中的接收端产生观察，标准使观察可传递；只有在保留观察条件之后，管理者才有资格把它用于判断。

RFC 3611 没有发明“媒体质量真值”。它给多个有限证人安排了可组合的格式。今天真正需要防止的，是平台把多个证人的名字、窗口和沉默原因删掉，再用一张漂亮的总分表宣告案件已经结案。

来源