RTCP 报告 · SR 与 RR，通话的仪表盘 · 音视频与 WebRTC 详解

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

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

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

RTP 的孪生：RTCP

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

生成和解析它的，是 ModuleRtpRtcpImpl2 手下的 RTCPSender 和 RTCPReceiver。

两种基本报告：SR 与 RR

RTCP 最基础的两种报告：

发送方报告 SR（Sender Report）和接收方报告 RR（Receiver Report），是 RTCP 的两块基石。

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

一发一收，一份「我发了什么」，一份「我收到多少、质量如何」——两份报告拼起来，双方就都掌握了这条流的真实传输状况。发送方看着 RR 里的丢包和抖动，就知道该不该降码率、要不要发 FEC；接收方的 jitter 数据则喂给抖动缓冲。

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

SR 里那个「RTP 时间戳 ↔ NTP 墙上时钟」的映射，是一个不起眼却极关键的设计：

音视频同步（口型对得上），靠的正是 SR 里的时间戳映射。 问题在于：音频流和视频流是两条独立的 RTP 流，各有各的 SSRC 和互不相干的时间戳基准（音频按 48kHz 走、视频按 90kHz 走，起点还是随机的）。光看各自的 RTP 时间戳，没法知道「这段音频」和「那帧视频」是不是同一时刻采集的。

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

[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）。

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