4. RTCP协议核心概念
RTP负责把音视频数据以最小开销实时送达对端，但它本身几乎不携带任何“质量信息”。如果只有RTP，发送方无法知道网络是否拥塞、接收方丢了多少包、抖动有多大，也就无法做码率自适应。RTCP（RTP Control Protocol）正是为补齐这一环而设计的伴生控制协议：它不传输媒体数据，而是周期性地在同一个RTP会话中传输控制报文，用统计与反馈把“发送—接收”两端连接成一个可观测、可调节的闭环。
理解RTCP，关键要抓住三件事：报文类型决定“说什么”，SR/RR决定“谁在报告什么”，反馈机制与统计信息决定“这些数字如何被用来调整编码与流控”。本节围绕这三点展开。
一、RTCP的五种核心报文类型
RTCP通过报文类型字段（PT，Packet Type）区分不同功能。最常用的五种报文构成了RTCP会话的基本骨架：
- SR（Sender Report，发送者报告，PT=200）：由正在发送媒体的一方发出，包含该发送者的RTP时间戳与NTP绝对时间的对应关系，以及自上次报告以来的发送统计（发包数、发送字节数）。
- RR（Receiver Report，接收者报告，PT=201）：由只接收不发送（或暂时不发送）的一方发出，核心是接收质量统计：丢包率、累计丢包数、最高序列号、到达间隔抖动、上次SR时间。
- SDES（Source Description，源描述，PT=202）：携带CNAME等源描述项。CNAME是跨媒体流关联同一用户的稳定标识，也是解决SSRC冲突的关键。
- BYE（PT=203）：表示某个SSRC即将离开会话，用于优雅退出，避免对端继续等待。
- APP（Application-defined，PT=204）：应用自定义扩展报文，供特定场景传递私有控制信息。
这些报文通常被组合在一个复合RTCP包中发送，例如“SR + SDES”或“RR + SDES”。复合结构保证了即使某个报文丢失，接收方仍能获得源标识等基础信息。
二、SR与RR：发送者报告与接收者报告
SR和RR是RTCP的统计核心，二者结构相似，差别在于SR多了一段20字节的发送者信息。可以把它们理解为“双向体检表”：发送方报告自己发了多少，接收方报告自己收得怎么样。
SR中的关键字段包括：
- NTP时间戳：发送时刻的绝对时间，用于跨流同步与音画对齐。
- RTP时间戳：与NTP时间戳对应的同一时刻的RTP时间，建立媒体时间与墙钟时间的映射。
- 发送包数、发送字节数：用于接收方估算发送速率与丢包比例。
RR中的关键字段包括：
- 丢包率（fraction lost）：自上次报告以来丢失包的比例，是拥塞判断最直接的信号。
- 累计丢包数：从会话开始到现在的累计丢失数量。
- 最高序列号：接收到的最大RTP序列号，用于计算期望收包数。
- 抖动（jitter）：到达间隔时间的统计方差，反映网络时延稳定性。
- LSR与DLSR：上次SR的NTP时间与收到该SR到发出本RR的延迟，用于发送方计算RTT。
发送方收到RR后，可以用LSR和DLSR计算往返时延：RTT = 当前时间 − LSR − DLSR。这个RTT与丢包率、抖动一起，构成码率控制器的输入。
三、反馈机制与统计信息如何驱动流控
RTCP的反馈是周期性的，通常带宽被限制在会话总带宽的5%左右，因此报告间隔会随参与者数量动态调整。接收方在每个报告周期内汇总统计，发送方据此调整编码参数。典型闭环如下：
- 接收方持续统计丢包、抖动、RTT。
- 周期到达时，构造RR（或SR）并发送。
- 发送方解析报告，计算丢包率与RTT。
- 若丢包率上升且RTT增大，判定为拥塞，降低目标码率或切换更保守的编码档位。
- 若丢包率低且抖动稳定，逐步提升码率，探测可用带宽。
这一机制与编解码协同的关键在于：码率调整不是瞬间完成的，编码器需要时间切换分辨率、帧率或量化参数。因此RTCP报告周期、编码器切换延迟与网络变化速度必须匹配，否则会出现“刚降码率网络已恢复”或“网络已恶化但码率还没降下来”的滞后问题。
四、典型场景：一次码率自适应调整
假设一路720p视频以2 Mbps发送，接收方每5秒发送一次RR。某次报告中丢包率从0.5%升至8%，抖动从12 ms升至45 ms，RTT从60 ms升至180 ms。发送方据此判断链路出现拥塞，将目标码率降至1.2 Mbps，并降低帧率以减小突发。下一周期RR显示丢包率回落至1%以内，发送方再缓慢提升码率。这个过程就是RTCP反馈驱动流控的典型闭环。
关键参数示例：
RTCP 带宽占比：5%
报告间隔：约 5 s（随参与者数量动态调整）
丢包率阈值：>5% 触发降码率
RTT 阈值：>150 ms 触发保守策略
抖动阈值：>30 ms 触发抗抖动缓冲调整五、常见误区与复盘
误区一：把RTCP当作可靠传输。RTCP本身不保证可靠，报告可能丢失或延迟。流控算法必须容忍报告缺失，不能因一次RR未到就做出剧烈调整。
误区二：忽略CNAME。没有SDES中的CNAME，跨音频、视频流无法关联到同一用户，同步与统计都会出错。
误区三：报告周期过短。过于频繁的RTCP会挤占媒体带宽，反而加剧拥塞；周期过长则反馈滞后，码率调整跟不上网络变化。
误区四：只看丢包率不看抖动。高抖动即使丢包率低，也会导致播放卡顿，必须结合抖动与RTT综合判断。
复盘时建议重点检查：RTCP复合包是否包含SDES、报告间隔是否合理、丢包率与RTT是否被正确解析、码率调整是否与编码器切换延迟匹配。只有把RTCP的统计信息真正接入编码与流控决策，RTP会话才能从“能通”走向“稳定好用”。