3. RTCP协议详解
RTP负责把音视频数据以最小的时延送达对端，但它本身几乎不携带任何“我收到了什么、我丢了多少、网络抖成什么样”的信息。真正承担这条反馈回路的，是它的姊妹协议RTCP（RTP Control Protocol）。理解RTCP，是理解WebRTC、SIP视频、直播连麦等系统如何做拥塞控制、码率自适应和故障定位的关键一步。
一、RTCP的核心原理：周期性、多播友好的控制通道
RTCP与RTP共用同一组端口对（RTP用偶数端口，RTCP用相邻的奇数端口），但它的定位完全不同：RTP传媒体，RTCP传控制。RTCP报文按固定周期发送，通常占会话带宽的5%左右，其中发送者/接收者报告占25%，其余留给SDES等报文。这个带宽约束决定了RTCP不能像TCP ACK那样逐包反馈，而是“批量、周期、统计式”的反馈。
RTCP的报文种类由报文头中的PT（Packet Type）字段标识，常见类型如下表所示：
| PT值 | 报文类型 | 主要作用 |
|---|---|---|
| 200 | SR（Sender Report） | 发送者的发送统计 + NTP/RTP时间戳映射 |
| 201 | RR（Receiver Report） | 接收者的丢包率、抖动、最高序号等反馈 |
| 202 | SDES | 源描述，如CNAME、NAME、EMAIL |
| 203 | BYE | 参与者离开会话 |
| 204 | APP | 应用自定义扩展 |
| 205 | RTPFB | 传输层反馈，如NACK、PLI |
| 206 | PSFB | 载荷相关反馈，如REMB、FIR |
二、SR与RR：质量反馈的两大支柱
SR由媒体发送方发出，包含两部分信息：一是发送统计，如本周期内发送的RTP包数、字节数；二是时间戳映射，即NTP绝对时间与RTP时间戳的对应关系。这个映射是音视频同步（Lip Sync）的基础——接收端只有拿到SR，才能把不同流的RTP时间戳换算到同一绝对时间轴上。
RR由接收方发出，是质量反馈的核心。它针对每个同步源（SSRC）报告以下字段：
- 丢包率（fraction lost）：自上次RR以来丢失包的比例，8位定点数，用于判断当前链路拥塞程度。
- 累计丢包数（cumulative lost）：整个会话期间丢失的包总数，用于长期质量评估。
- 最高扩展序号（extended highest sequence number）：接收到的最大RTP序号，用于检测乱序和丢包。
- 抖动（jitter）：RTP包到达间隔的统计方差，反映网络时延抖动，直接影响播放缓冲策略。
- LSR与DLSR：上次SR的NTP时间戳及距上次SR的延迟，用于计算RTT。
RTT的计算公式为：RTT = 当前时间 - DLSR - LSR。发送方收到RR后，就能知道“我的包到对端再回来要多久”，这是判断是否触发重传、是否降低码率的重要依据。
关键理解：SR是“我发了什么”，RR是“我收到了什么”。两者配对使用，才能构成完整的发送—接收质量闭环。
三、SDES、BYE与APP：会话管理的三件套
SDES（Source Description）用于携带参与者的描述信息，其中最重要的是CNAME（Canonical Name）。CNAME在同一个终端的所有RTP流中保持一致，即使SSRC因冲突而改变，CNAME也能帮助接收端把同一用户的多路流关联起来。没有CNAME，音视频同步和流绑定就会变得非常困难。
BYE用于通知会话中的其他参与者“我要离开了”。它通常携带SSRC列表和离开原因。在多人会议中，BYE能帮助其他端及时释放资源、更新成员列表，避免向已离开的参与者继续发送媒体。
APP报文是RTCP的扩展机制，允许应用自定义报文类型。例如某些厂商用APP报文传递私有质量指标、屏幕共享状态或自定义控制指令。APP报文不改变RTCP的基本框架，但为特定场景提供了灵活性。
四、RTCP在质量反馈中的实际角色与场景
在WebRTC中，RTCP的反馈链路直接驱动了拥塞控制。接收端通过RR报告丢包和抖动，发送端据此调整码率；同时，RTPFB中的NACK用于请求重传丢失的包，PLI用于请求关键帧。这些反馈共同构成了“感知—决策—调整”的闭环。
一个典型的排障场景是：用户反馈视频卡顿，但发送端码率并未下降。此时查看RR中的丢包率和抖动字段，如果丢包率很高但发送端没有降码率，说明拥塞控制算法可能未正确响应，或者RR报文本身丢失。进一步检查LSR/DLSR，可以判断RTT是否异常增大，从而定位是网络路径问题还是终端处理问题。
实操建议：在抓包分析时，先用Wireshark过滤rtcp，再按PT字段区分SR/RR。重点关注RR中的fraction lost和jitter，以及SR中的NTP时间戳是否连续。如果发现RR周期明显变长，可能是RTCP带宽被媒体流挤占，需要检查带宽分配策略。
五、常见误区与复盘
误区一：认为RTCP可以实时反馈每一个包。实际上RTCP是周期性的，反馈粒度是“统计窗口”，不能替代逐包ACK。误区二：忽略CNAME的作用，导致多流关联失败。误区三：把RTCP当作可靠传输，实际上RTCP报文本身也可能丢失，设计时不能假设每次反馈都能到达。
复盘时，建议把RTCP反馈与RTP发送日志对齐时间轴，观察“丢包率上升—码率下降—抖动恢复”的因果链是否成立。如果反馈滞后严重，可能需要缩短RTCP发送间隔，但要注意不能超过带宽上限。
总结来看，RTCP不是RTP的附属品，而是流媒体系统实现自适应、可观测和可运维的基础设施。SR提供时间基准，RR提供质量反馈，SDES提供身份关联，BYE和APP提供会话管理与扩展能力。只有把这些报文放在同一条反馈链路上理解，才能真正掌握流媒体性能优化的抓手。