3. RTCP协议基础
RTP负责把音频、视频的媒体数据从发送端送到接收端，但它本身只关心“怎么把包送出去”，并不负责告诉对端“我收到了多少、丢了多少、抖动多大、音视频是否对得上”。这些控制与反馈信息，由与RTP配套的RTCP（RTP Control Protocol，RTP控制协议）来承担。理解RTCP，是解决音画不同步问题的关键一步，因为音画不同步的很多判断依据，恰恰来自RTCP报告中的时间戳、丢包和抖动数据。
一、RTCP的核心作用与设计思想
RTCP并不传输媒体数据，它传输的是控制信息。它和RTP通常使用相邻的端口，例如RTP用5004、RTCP用5005。RTCP的设计思想可以概括为三点：
- 反馈质量：接收端通过RTCP告诉发送端网络质量，如丢包率、抖动、往返时延。
- 标识身份：通过SDES报文携带CNAME等标识，让不同媒体流能够被关联到同一个发送者。
- 同步媒体：通过SR中的NTP时间戳和RTP时间戳，把音频和视频映射到同一时间轴，这是解决音画不同步的核心机制。
二、RTCP报文类型总览
RTCP通过报文类型字段区分不同功能。常见类型如下表所示：
| 类型值 | 缩写 | 名称 | 主要作用 |
|---|---|---|---|
| 200 | SR | Sender Report | 发送者报告，携带发送统计和NTP/RTP时间戳映射 |
| 201 | RR | Receiver Report | 接收者报告，反馈丢包、抖动、最高序列号等 |
| 202 | SDES | Source Description | 源描述，携带CNAME、NAME、EMAIL等 |
| 203 | BYE | Goodbye | 表示某个SSRC退出会话 |
| 204 | APP | Application-defined | 应用自定义扩展报文 |
这些报文通常被封装在一个复合RTCP包中一起发送。一个复合包中至少应包含SR或RR，再按需附加SDES、BYE、APP等。
三、SR与RR：发送者报告与接收者报告
SR（Sender Report）由正在发送媒体数据的端点发出。它包含两部分关键信息：一是发送统计，如发送的RTP包数、发送的字节数；二是NTP时间戳与RTP时间戳的对应关系。这个对应关系是音视频同步的基石：接收端拿到音频SR和视频SR后，可以把两路RTP时间戳换算到同一个NTP墙上时钟，从而判断音频和视频是否在同一时刻播放。
RR（Receiver Report）由接收端发出，用于反馈接收质量。它不包含发送者的时间戳映射，但包含每个SSRC的接收统计，例如：
- 丢包率（fraction lost）
- 累计丢包数（cumulative number of packets lost）
- 最高扩展序列号（extended highest sequence number received）
- 到达间隔抖动（interarrival jitter）
- 上次SR时间戳（last SR timestamp, LSR）
- 上次SR到现在的延迟（delay since last SR, DLSR）
其中LSR和DLSR配合发送端的当前时间，可以计算往返时延RTT。RTT和抖动数据虽然不直接等于音画不同步，但它们会影响播放缓冲策略，进而影响同步效果。
四、SDES、BYE与APP
SDES（Source Description）用于描述源。最重要的字段是CNAME（Canonical Name）。CNAME是一个稳定标识，即使SSRC因冲突或重启发生变化，CNAME仍保持不变。在音视频同步中，接收端通过CNAME判断某路音频和某路视频是否来自同一个终端，从而把它们归入同一同步组。
BYE表示某个SSRC即将退出会话。接收端收到BYE后，可以释放对应资源，停止等待该流的数据。对于音画同步而言，如果视频流发送BYE而音频流仍在继续，接收端需要及时调整同步策略，避免继续等待已经结束的视频流。
APP是应用自定义报文，允许厂商或应用扩展RTCP功能。例如某些实时通信系统会用APP报文传递自定义的同步辅助信息或控制指令。APP报文不改变RTCP基本框架，但为特定场景提供了灵活性。
五、RTCP复合包与发送流程
RTCP报文通常按复合包形式发送，典型结构如下：
复合RTCP包
├── SR 或 RR（必须）
├── SDES（通常包含CNAME）
├── BYE（可选，退出时）
└── APP（可选，应用扩展）发送周期由RTCP带宽控制，通常占会话带宽的5%左右。接收端收到复合包后，先解析SR/RR获取同步和统计信息，再解析SDES获取CNAME，最后根据BYE和APP做相应处理。
六、案例：用SR/RR判断音画不同步
假设一个视频会议终端同时发送音频和视频。音频SR中NTP时间为0xE8A1_0000，对应RTP时间戳为160000；视频SR中NTP时间为0xE8A1_0000，对应RTP时间戳为90000。接收端收到后，可以把两路RTP时间戳都映射到同一个NTP时间轴。如果音频和视频的NTP映射关系出现偏差，或者RR中视频抖动明显大于音频，就可能导致播放时音画不同步。
再比如，接收端发现视频RR中丢包率高达8%，而音频RR丢包率只有1%。视频解码器可能因为丢包而等待重传或触发缓冲，导致视频播放时间被拉长，而音频继续正常播放，最终表现为“声音先到、画面滞后”。这时RTCP报告就是定位问题的重要证据。
七、常见误区与复盘
- 误区一：只关注RTP，忽略RTCP。没有RTCP，接收端无法获得NTP/RTP映射，音视频同步只能靠猜。
- 误区二：认为SR只用于发送端。接收端也会解析SR，并利用其中的LSR/DLSR计算RTT。
- 误区三：忽略CNAME。SSRC可能变化，CNAME才是关联音视频流的稳定标识。
- 误区四：把RTCP当成媒体数据。RTCP不承载音频视频负载，它只承载控制与反馈信息。
总结来说，RTCP是RTP的“控制面”。SR提供发送者的时间基准，RR提供接收质量反馈，SDES用CNAME关联音视频流，BYE负责退出，APP用于扩展。只有把这些报文配合起来看，才能在音画不同步问题中快速定位是时间戳映射错误、网络丢包抖动，还是流关联判断失误。