# RTCP 报告 · SR 与 RR，通话的仪表盘

> RTP 传媒体，RTCP 传反馈。这一章讲清 RTCP 的两种基本报告：发送方报告 SR（带 NTP/RTP 时间戳映射，是音视频同步的关键）和接收方报告 RR（报丢包率、抖动、往返时延），以及它们怎么构成一次通话的「仪表盘」。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/webrtc/rtcp-reports
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# RTCP 报告 · SR 与 RR，通话的仪表盘

[RTP 传的是媒体](https://daiw.org/manual/webrtc/rtp-packet)，但光发媒体不够——发送方需要知道**对端收得怎么样**：丢了多少？延迟多大？网络堵不堵？这些**反馈**由 RTP 的孪生协议 **RTCP（RTP Control Protocol）** 承载。这一章讲 RTCP 最基本的两种报告，它们是通话的「仪表盘」。

## RTP 的孪生：RTCP

RTCP 和 RTP 成对出现（都在 RFC 3550 里定义）。分工清晰：**RTP 走媒体数据，RTCP 走控制与统计**。RTCP 的包**周期性**发送（比如每几秒一次），量很小（相比媒体），却携带着维持通话质量的关键信息。[启用 rtcp-mux](https://daiw.org/manual/webrtc/srtp-encryption) 后，RTCP 和 RTP [共用一条传输](https://daiw.org/manual/webrtc/jsep-transport-controller)，靠[包类型字段区分](https://daiw.org/manual/webrtc/payload-types)。

生成和解析它的，是 [`ModuleRtpRtcpImpl2`](https://daiw.org/manual/webrtc/rtp-rtcp-module) 手下的 `RTCPSender` 和 `RTCPReceiver`。

## 两种基本报告：SR 与 RR

RTCP 最基础的两种报告：

<Callout type="info">
  **发送方报告 SR（Sender Report）和接收方报告 RR（Receiver Report），是 RTCP 的两块基石。**

  - **SR（发送方报告）** —— **正在发送媒体的一方**发出，报告：「我到目前发了多少包、多少字节」，以及一个**至关重要的时间戳映射**——把这条流的 [RTP 时间戳](https://daiw.org/manual/webrtc/rtp-packet)和一个绝对的 **NTP 墙上时钟**对应起来。
  - **RR（接收方报告）** —— **接收媒体的一方**发出，报告它的**收货质量**：丢包率（fraction lost）、累计丢包数、收到的最高序号、**到达间隔抖动（jitter）**、以及「上次收到 SR 是多久前」（据此对端能算出[往返时延 RTT](https://daiw.org/manual/webrtc/connection-and-checks)）。

  一发一收，一份「我发了什么」，一份「我收到多少、质量如何」——两份报告拼起来，双方就都掌握了这条流的**真实传输状况**。发送方看着 RR 里的丢包和抖动，就知道该不该[降码率](https://daiw.org/manual/webrtc/source-map)、要不要[发 FEC](https://daiw.org/manual/webrtc/fec)；接收方的 jitter 数据则喂给[抖动缓冲](https://daiw.org/manual/webrtc/source-map)。
</Callout>

## SR 的隐藏使命：音视频同步

SR 里那个「[RTP 时间戳](https://daiw.org/manual/webrtc/rtp-packet) ↔ NTP 墙上时钟」的映射，是一个不起眼却极关键的设计：

<Callout type="info">
  **音视频同步（口型对得上），靠的正是 SR 里的时间戳映射。** 问题在于：音频流和视频流是**两条独立的 RTP 流**，各有各的 [SSRC](https://daiw.org/manual/webrtc/rtp-packet) 和**互不相干的时间戳基准**（音频按 48kHz 走、视频按 90kHz 走，起点还是随机的）。光看各自的 RTP 时间戳，**没法知道「这段音频」和「那帧视频」是不是同一时刻采集的**。

  SR 补上了这块拼图：每条流的 SR 都给出「我的 RTP 时间戳 X 对应绝对时间 T」。于是接收端能把两条流的时间戳**都换算到同一个绝对时间轴**上，从而知道「音频的这一段」和「视频的这一帧」在**真实世界的同一刻**发生——据此对齐播放，口型才不会飘。**跨流同步这个难题，SR 用一个时间戳映射优雅地解决了。** WebRTC 里 `rtp_to_ntp_estimator` 等就是干这个换算的。
</Callout>

## 复合包：一次发一叠

RTCP 包很少单独发，而是**复合（compound）** 发送——把 SR/RR、[源描述 SDES](https://daiw.org/manual/webrtc/rtp-packet)（[CNAME](https://daiw.org/manual/webrtc/rtp-packet) 等）、以及各种[反馈](https://daiw.org/manual/webrtc/rtcp-feedback)打成一叠，一个 UDP 包发出。这样省包、也保证相关信息一起到达。所以你在网络上看到的一个 RTCP 包，里面往往叠着好几种报告。

## 小结与下一章

**RTCP 是 RTP 的孪生协议，走控制与统计反馈**（周期性、量小、[rtcp-mux 共用传输](https://daiw.org/manual/webrtc/srtp-encryption)），由 [`ModuleRtpRtcpImpl2`](https://daiw.org/manual/webrtc/rtp-rtcp-module) 的 `RTCPSender`/`RTCPReceiver` 处理。两种基本报告：**SR**（发送方：发了多少 + **RTP↔NTP 时间戳映射**，是[音视频同步](https://daiw.org/manual/webrtc/source-map)的关键）、**RR**（接收方：丢包率、**抖动**、据以算 [RTT](https://daiw.org/manual/webrtc/connection-and-checks)）。它们是通话的仪表盘。RTCP 常**复合**发送，一叠多种报告。

SR/RR 是「统计报告」，但 RTCP 还有一类更主动的——**反馈报文**：请求重传、请求关键帧、报告带宽。下一章看它们。👉 [RTCP 反馈：NACK / PLI / REMB](https://daiw.org/manual/webrtc/rtcp-feedback)。

## 参考资料

- [1] libwebrtc 源码.`modules/rtp_rtcp/source/rtcp_sender.h`、`rtcp_receiver.h`、`rtp_to_ntp_estimator.h`。
- [2] libwebrtc 源码.`modules/rtp_rtcp/source/rtcp_packet/sender_report.h`、`receiver_report.h`。
- [3] IETF RFC 3550「RTP/RTCP」§ 6（SR/RR）。