摘要

  • RFC 3158 没把 RTP 媒体变换与 RTCP 报告分开处理。编码、分组方式、序列号或时间戳频率一旦改变，字节数、分组数、时间戳与接收报告也必须进入同一个新历史。
  • 接收报告逆着媒体方向返回，而且描述的是输出侧的序列空间。若转换器无法把丢包和扩展序列号有意义地映射回输入侧，明确省略或标成转换器本地观测的合成报告，比转发一组貌似完整却指向错误分组的数字更诚实。
  • 这份测试策略也限制了自身权威：它能发现常见实现错误并展示特定场景的互通，却不能仅凭“通过”证明完整合规、安全、生产质量或用户体验。

画面可以正常，统计却已经属于另一条流

设想源端发出两个 RTP 分组。转换器为了让媒体通过较窄链路，先重编码，再把两个分组合并为一个。接收端顺利解码并显示画面。若只看播放器，这次转换已经成功。

接收端随后发出的 RTCP Receiver Report 却属于输出侧：它看见一个分组，而不是源端的两个。转换器若把报告原样送回，源端会收到一份语法完全正确、但描述了自己从未发送过的序列历史的记录。输出侧丢失一个合并分组，也不能自动等同于输入侧丢失一个分组。

这里不需要任何比特损坏。SSRC 可以不变，RTCP 可以解析，完整性校验也可以通过，媒体甚至可以听清看清。错误发生在数字与它所声称计量的分组集合之间。一个数字在转换器下游可能真实，到上游却可能失去意义。

RFC 3158 因而不只检查“另一端能否播放”。它还检查转换器改变 payload type、时间戳、序列号、padding 或 marker 后，是否同步修改了对应 RTCP 信息。控制信道不是附属装饰，而是对数据历史的紧凑陈述。

测试仪器创造了第三个观测点

文档建议在两个 RTP 实现之间放置一个应用层转发器。两端都把分组送给测试仪器，再由它交给另一端。正常情况下它不额外引入延迟或丢包；特定试验中，它可以延迟、丢弃并记录分组内容。

这样就有了三份可比较的证据：第一端声称发出了什么，第二端收到什么，中间仪器实际做了什么。仪器随机丢弃大约百分之一的数据分组时，接收报告中的丢包比例和累计丢包应当与已知注入相符。关闭丢包、改为随机增加延迟时，报告的到达间隔抖动应随之上升。

仪器仍不是全知见证者。它只看见特定位置、特定构建和预设条件。RFC 3158 在开头就声明：测试并不穷尽所有情形，通过它们也不必然意味着符合完整 RTP 规范。

因此，一次通过只能证明被记录的版本在被执行的场景里表现如此。它不能自行扩张为对所有 payload、拓扑、异常输入、加密模式、网络负载或人类感受的认证。

RTP 承载媒体，RTCP 描述媒体如何被观察

Sender Report 把 SSRC、NTP 时间、RTP 时间戳、分组数和字节数放在一起。Receiver Report 则记录所观察源的丢包、最高扩展序列号、抖动、最后一个发送报告及其后经过的时间。

每个字段都依赖具体的分组集合和观测位置。离开时间戳频率，时间戳没有统一尺度；离开序列空间，最高序列号不是全局位置；离开分母和观测段，丢包也不是端到端常数。

RFC 3158 检查的是对应关系：SR 的 SSRC 是否与媒体一致，RTP 时间是否与媒体时间线一致，计数是否对应实际发送，RR 的丢包是否对应测试仪器注入的损伤。报告按时出现，只能证明它出现了；不能证明它说的是正确历史。

运维系统往往更偏爱体积小、结构清楚的报告，而不是完整抓包。但报告是数据事件的投影，不是替代品。中间系统若改写事件而保留旧投影，最整洁的仪表板反而可能离真实最远。

SSRC 保持不变，不等于计量单位保持不变

RTP 把 translator 与 mixer 分开。转换器让各来源保持独立，并保留原 SSRC；混合器把多个流合成一个新流，自行生成时序并使用自己的 SSRC，必要时用 CSRC 列出贡献源。

转换器保留 SSRC，却可以改变周围几乎所有测量条件：编码和字节量、payload type、分组间隔、帧率、时间戳频率、分组合并或拆分、序列号、padding、加解密与 marker。

SSRC 的连续性帮助接收者认出来源，但不能证明字节数、分组数、序列位置或时间单位连续。身份线索与测量空间是两件事。若两个不同分组历史被同一个熟悉数字遮住，监控恰恰最容易漏掉转换边界。

每项正向变换都带来一项报告责任

RFC 3158 给出明确对应。改变数据编码，就要改 Sender Report 的字节数；把多个分组合为一个，就要改分组数；改变采样频率，就要改 SR 中的 RTP 时间戳。

若低码率输出仍沿用输入字节数，窄链路会被记成承载了并不存在的流量。若三入一出却仍把三记为输出分组数，后续速率和丢包计算即使算术无误，也建立在错误事实之上。

反向报告更难。接收端只知道输出序列。合并或拆分改变序列号后，转换器需要把丢包字段与最高扩展序列号逆向映射回输入历史。这需要保存输入与输出之间的关系，而不是加一个固定偏移。

一个丢失的输出分组可能包住多个输入贡献；拆分后丢失一个片段，也可能只影响原分组的一部分。“丢一个包”跨过边界后，分母与影响都变了。

能生成输出，不代表能完整逆推原因

媒体从源端向接收端前进，接收报告却逆向返回。转换器必须把输出侧的观测翻译成输入侧可理解的证据。这种逆运算不一定存在。

多对一合并会消除区别。接收端丢失合并结果后，无法知道若原分组保持分离，会分别发生什么。重编码还可能重划帧与分组的边界，使简单比例或偏移彻底失效。

后来取代原始 RTP 规范的 RFC 3550 把原则写得更强：转换 payload 的中间系统必须同步转换 SR 与 RR，不得简单原样转发；同时，它承认逆向处理可能很复杂，极端情况下根本没有有意义的换算。

正向处理权没有自动带来反向解释权。转换器可以负责制造可用输出，却缺乏足够信息把每一次下游损失精确归因到上游单位。系统需要保存这条界线，而不是制造精度。

明确的空白比虚假的完整更可靠

RFC 3158 允许在无法合理转换时移除 reception report block，发送空的 SR/RR。RFC 3550 又区分两种做法：不转发接收报告，或依据转换器自身接收情况生成合成报告。

二者都不代表零丢包。没有报告意味着无法提出有依据的端到端投影；合成报告只描述转换器这个观测点及其上游或本地段。它不是最终接收者对原始序列的见证。

为了填满数据库而硬塞数字，会用语义真实性换来字段完整性。保留空白，反而保护了其余证据的范围。标准留下“按具体变换采取有意义做法”的余地，不等于允许隐藏报告来源或冒充端到端测量。

复制、转换与混合必须分别解释

只把未修改分组从组播复制到单播的转换器，可以原样转发 RTCP。责任来自实际变换，而不是“路径上有中间设备”这一事实。

payload 转换器保留源，但要重建报告。它也可以用自己的 SSRC 报告自己收到的情况；这种报告必须明确属于转换器的观测点。

混合器建立新同步源，不能把一侧对原源的报告照搬到另一侧，好像那些源在那里仍是 SSRC。把三类设备都称为“媒体中继”，会抹掉它们不同的证据权限。

报告聚合也会影响含义。RFC 3550 通常不建议把不同来源的 SR/RR 合并，因为 LSR 与 DLSR 参与传播时延测量。中间设备即使不改字段，只改变发送时机和包装，也可能改变结果。

密码完整性不能证明语义换算正确

SRTP 与 SRTCP 后来为媒体和控制流提供机密性、完整性及重放保护。它们能证明受保护关系之外的篡改或重放，却不能验证转换器选择的序列映射是否正确。

一份报告可以真实出自转换器，同时是本地合成的；可以比特完整，却不是最终接收端的报告；可以通过认证，却把输入计数带进输出路径。

因此，安全校验只是证据链中的一项。它保护“谁在受保护上下文中发了哪些字节”，并不扩大该发送者实际观察到的范围。签过名的局部统计不会自动成为端到端事实。

测试规范本身也要接受算术检查

RFC 3158 的 SSRC 随机性章节主动说，它只能做粗略验证。文本写了 2,500 个样本分入 25 个区间，却又写每个区间期望 40 个；直接相除得到 100。为本研究冻结的 RFC Editor 勘误查询没有返回 RFC 3158 的记录。

这不是官方勘误，也不能被夸大成对 RTP 的否定。它只说明：即使测试方法已经出版，执行者仍要保存精确参数、独立检查期望值，并把偏差如实记录。RFC 编号不能代替可重复计算。

RFC 2762 解释了均匀 SSRC 分布对群组抽样的意义。RFC 3158 自己把检测称为粗略，也提醒读者不要把有限样本通过误读成“拥有完美的 32 位随机性”。

更多指标仍然需要来源坐标

RFC 3611 扩展了 RTCP 报告指标，RFC 7667 归纳了更多 RTP 拓扑，RFC 3551 说明 payload、时钟与 marker 依赖具体 profile，RFC 3711 为传输增加保护。

这些改进丰富了词汇，没有让任何观测者无处不在。每个指标仍需说明发送者、时间区间、分组集合、序列空间和位置。后转换指标不会因为装进更丰富格式就变成前转换指标。

可靠档案应连接：输入抓包、转换规则与版本、输入—输出映射、输出抓包、SR 改写、RR 逆算或省略理由、合成报告的观测点、密码校验、解码与播放结果，以及应用是否真正得到所需服务。

RFC 3158 留下的历史纪律，并不是强迫中间系统保留每一个数字，而是禁止在数字已经失去原义后，仍保留它“从未改变”的外观。分组变了，报告就要一起变；若跟不上，就应准确说明知识终止在哪里。

来源