RTCP详解
概要
RTCP是IETF在RFC 3550中定义的控制协议，其核心目标是为RTP会话提供质量监测、同步与最优带宽分配。RTCP报文周期性发送，不承载媒体负载，而是利用固定比例（默认5%）的会话带宽，收集并广播接收与发送统计信息，以及鉴别CNAME以支持多媒体流间同步。RTCP报文类型包括SR/SDES、RR、BYE、APP等，它们各自承担不同反馈与管理职责。通过这些机制，RTCP帮助应用端感知网络状况、调整发送速率，并为多媒体流同步和控制策略提供决策依据。
设计目标：
最小化带宽占用：RTCP使用固定会话带宽比例，默认5%，以免过度占用网络资源。
可扩展性：通过APP类型报文，支持应用自定义扩展字段与功能。
跨流同步：SDES报文中的CNAME字段确保同一参与者的多路RTP流能在接收端正确对齐。
公平性：所有参与者按相同策略发送RTCP报文，动态调整发送频率，保障大规模多播会话中的公平竞争。
RTCP报文格式详解
公共报文头部
公共报文头在所有 RTCP 报文中保持一致，由 8 字节组成 （2 + 1 + 5 + 8 + 16 + 32 = 8个字节）必须都要 32-bit 对⻬。
因为协议是高扩展，其中RC是一个概念，当PT=206时称为FMT，PT=200时称为RC。
V (Version, 2 bits)：协议版本，固定为 2。
P (Padding, 1 bit)：是否包含填充字节。
RC (Reception report count, 5 bits)：报告块数，即后续报告块的数量（0–31）。
PT (Packet Type, 8 bits)：报文类型，SR 的值为 200。
Length (16 bits)：整个 RTCP 报文（包括头部、固定体、报告块和填充）的长度，以 32 位字为单位减 1。必须都要 32-bit 对⻬。
SSRC（32 bits）：表示描述的是指定流的RTCP信息
typedef struct _rtcp_header_t
{uint32_t v:2; // versionuint32_t p:1; // paddinguint32_t rc:5; // reception report countuint32_t pt:8; // packet typeuint32_t length:16; /* pkt len in words, w/o this word */uint32_t ssrc;
} rtcp_header_t;RTCP包的类型
其中业务场景中主要⽤到 SR/RR/RTPFB/PSFB，接下来我们也将重点介绍这四种报⽂。如需扩展，从 208-223 中分配， 0 与 255 ⽬前禁⽌使⽤（对应PT值）。
| 类型(PT) | 简称 | 用途 | 传输对象 |
|---|---|---|---|
| 200 | SR | 发送者报告（RFC 3550），主要用于接收端音视频同步 | 发流端反馈给接收端 |
| 201 | RR | 接收者报告（RFC 3550），接收端反馈丢包率、延时等信息 | 接收流端发给发流端 |
| 202 | SDES | 源点描述（RFC 3550），源描述项，其中包括规范名 CNAME | 发流端发给接收端 |
| 203 | BYE | 结束（RFC 3550），参会者结束当前会话 | 接收端和发送端可以互相发 |
| 204 | APP | 实验性的功能和开发（RFC 3550） | 未指定 |
| 205 | RTPFB | 传输层反馈 RTP Feedback（RFC 4585 / 5104），RTP质量反馈报告 | 发流端发给接收端 |
| 206 | PSFB | 特定负荷类型反馈 Payload Specific Feedback（RFC 4585 / 5104），负载类型反馈报告，发流端发送关键帧请求，推流端发送码率估计信息 | PLI FIR：发流端反馈给接收端； AFB：发流端反馈给接收端 |
| 207 | XR | XR, RTCP扩展（RFC 3611），RTCP扩展（DLRR 用于计算RTT延时） | 发流端发给接收端 |
SR PT=200
SR包含两个信息，将报告⾃⼰发送的信息告诉对端，同时将⾃⼰接收的信息也告诉对端。
sendinfo
各字段含义如下：
1. NTP Timestamp：NTP 时间戳表达了报告发送时的绝对时间，用于跨媒体流同步。由两部分组成：
高 32 位：自 1900-01-01 00:00:00 UTC 以来的秒数；
低 32 位：秒的小数部分，表示为该秒内的分数 ×2^32。
接收端在收到 SR 后，结合历史收到的 SR，可以计算出网络传播延迟，并校正本地时钟。
2. RTP Timestamp：对应于 NTP 时间戳的 RTP 时间戳，用于媒体流的同步与时基转换。不同媒体（音频、视频）具有不同的时钟率（如 8 kHz、90 kHz），接收端据此将 RTP 时间戳映射到 NTP 时间域。
3. Sender’s Packet/Octet Count
这两项统计从会话开始累积，用于衡量发送端的带宽占用与传输量：
Packet Count：发送的 RTP 包总数；
Octet Count：RTP 载荷的字节数总和，不含 RTP 头与 RTCP 报文。
接收端可利用这些信息与其自身接收统计进行比对，评估丢包情况。
报告块 (Report Blocks)
如果 RC>0，则 SR 报文后紧跟 RC 个报告块，每个报告块 24 字节（6 个 32 位字）。每个报告块包含接收端针对某个源的接收质量统计：
字段 大小 (Bytes) 说明 SSRC_n 4 报告块所反馈的 RTP 源标识符 fraction lost 1 自上一次 SR/RR 以来丢包的比例（保留 8 bit） cumulative packets lost 3 自会话开始以来累计丢包数（24 bit，有符号） extended highest seq. number 4 扩展后的最高 RTP 序列号，考虑环绕（32 bit） interarrival jitter 4 抖动估计值（32 bit），基于指数滑动平均算法 last SR 4 最近一次收到的 SR 报文中的 NTP 时间戳低 32 位 delay since last SR 4 自接收到上述 SR 以来的时延，单位为 NTP 时间戳低 32 位周期数
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P| RC | PT=SR=200 | length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+sender | NTP timestamp, most significant word |info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| NTP timestamp, least significant word |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| sender's packet count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| sender's octet count |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_1 (SSRC of first source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1 | fraction lost | cumulative number of packets lost |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR (LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR (DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_2 (SSRC of second source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2 : ... :+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+填充 (Padding)
若 P 位为 1，则报文末尾包含若干填充字节，以使报文长度对 32 位字对齐。最后一个填充字节的值指出填充字节的总长度（包括自身）。接收端应在解析完有效内容后，依据此值忽略填充区。
示例解析
以下是一段假设的 SR 报文（16 进制表示）及其解析流程概要：
原始字节流（前 8 字节展示）： 80 C8 00 06 12 34 56 78
0x80：V=2 (10), P=0, RC=0
0xC8：PT=200 (SR)
0x0006：Length=6 → 总长度=(6+1)×4=28 bytes
0x12345678：SSRC=305419896
接下来的 20 字节固定体解码出 NTP/RTP 时间戳及统计，然后根据 Length 值跳过填充或报告块
小结
SR 报文将绝对时间、媒体时间与发送统计紧密结合，为实时传输提供了全面的控制与同步能力。了解 SR 各字段的编码与处理逻辑，对于实现高质量、多源融合和自适应编码均至关重要。在实际系统中，应结合 RTCP 带宽控制策略和扩展报文（如 TWCC、REMB）进一步提升性能与可扩展性。
RR PT=201
RR主要用于反馈接收质量和网络性能，为实时音视频传输会话的监测与调整提供数据基础。
报告块 (Report Blocks)
2. fraction lost：丢包率（8位）：自上次报告以来丢包的比例，数值范围0~255；实际丢包率=数值/256。
3. cumulative packets lost：累计丢包（24位有符号）：整个会话期间该源丢包总数，用于长期统计分析。
4. extended highest seq num received：扩展最高序号（32位）：含环绕计数，可跨越 RTP 序号回绕的场景。
5. interarrival jitter：到达抖动（32位）：采用滑动算法估算两包间到达延迟变化，反映网络波动性。
6. last SR：最近 SR 时间戳：表示接收端最近一次收到的发送端RTCP Sender Report（SR）报文中的NTP时间戳的低32位部分。这个时间戳代表发送端发送SR报文的时间，用于同步和时延估计。
7. delay since last SR：延时自最近 SR（32位）：表示接收端从收到上述last SR代表的SR报文起，经过的时间，以NTP时间戳周期的单位（1/65536秒）计量。该字段反映了接收端等待反馈发送端的时间间隔。
举例 ：
发送端在时间T1（绝对时间，对应NTP时间戳）发送了一个SR报文，报文中携带NTP时间戳，这个时间戳的低32位称为last SR。
接收端在时间T2收到这个SR报文。
接收端在时间T3发送RR报文反馈网络状态，RR报文中包含last SR和delay since last SR字段。
last SR字段回传的是T1的NTP低32位；
delay since last SR字段表示接收端从T2到T3的时延。
根据这些数据，发送端可以估算从发送SR报文→接收SR报文→反馈RR报文→接收RR报文的总往返时间。
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+header |V=2|P| RC | PT=RR=201 | length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of packet sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_1 (SSRC of first source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1 | fraction lost | cumulative number of packets lost |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR (LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR (DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+report | SSRC_2 (SSRC of second source) |block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2 : ... :+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+丢包率（fraction lost）计算方法
RTCP的Sender Report（SR）和Receiver Report（RR）报文中的fraction lost字段是一个8位无符号整数，表示自上一个报告周期以来的丢包比例，公式为：
具体解释：
期望收到的包数由RTP序列号推算，考虑了序列号从16位（最大65535）循环回绕的问题，因此需要做循环计数，将16位序列号扩展到32位整数范围，避免序号回绕带来统计混淆。
序列号的递增被视为连续的数字序列，通过比较最新包的扩展序列号与起始序列号，计算期望的包数。
通过期望包数减去实际收到包的数量算出丢失包数，再除以期望包数得到丢失比率。
RTP序列号循环计数及扩展
RTP序列号是16位无符号整数，范围0至65535，发送超过65535后会回绕到0。
为避免因序列号回绕产生的误判，接收端实现时将序列号用循环计数扩展为32位无符号整数，以连续的逻辑序列进行丢包和顺序判断。
在对比或排序包序号时，根据当前序号和上一个序号的差异用带符号16位整型差值来判断先后顺序，从而正确处理回绕情况。
Jitter
抖动的定义是信号在某特定时刻相对于其理想时间位置上的短期偏离。在⽹络传输中，数据包 可能会经过不同的路由链路，当时的⽹络或拥塞或空闲，最终到达⽬的地时，与预期会有所偏 差。通过数据包的到达情况，我们可以反过来估测⽹络的状态变化，⽤来对发送端进⾏指导。
RTT计算方法
除了丢包、抖动以外，⽹络中我们最常关注的⼀个指标就是 RTT。RTCP 中为了计算RTT，在 RR 中会携带上次收到的 SR 中的 NTPTime (last SR)，并计算其收到时在本机经历的时间，⽤ DelaySinceLastSR 表示。发送 端收到后，剔除掉 DelaySinceLastSR 便是 RTT。
往返时延RTT的计算公式通常如下：
$T_{now}$是发送端当前时间（对应NTP时间戳的低32位），即收到RR报文的时间；
$T_{lastSR}$是last SR字段值，即发送端之前发送SR报文的NTP时间戳低32位；
$DelaySinceLastSR$是接收端报告的delay since last SR字段值，单位转换为时间（秒）后减去。
SR与RR简要总结
| 使用角色 | 报文类型 | 功能说明 |
|---|---|---|
| RTP源发送端 | SR | 汇报发送统计、时间戳映射，用于流同步和带宽估计 |
| 纯接收端（不发包） | RR | 反馈接收质量统计，报告丢包、抖动及延时信息 |
| 既发送又接收端 | 同时发送SR和RR | 发送SR报告自己的发送情况，同时发送RR反馈其他流的接收质量 |
在多点会议或视频通话场景中：
-
每个发送方周期性发送SR，通报自身状态；
-
每个纯接收方发送RR，反馈网络接收质量；
-
发送方如果同时也是接收方，则发送SR时携带对应数量的RR报告块，实现双重角色。
因此，选择SR还是RR取决于该参与者是否发送RTP媒体包。这样设计保证了全会话的传输和反馈信息全面且高效。
RTFB PT=205
RTCP报文类型205通常称为“Transport Layer Feedback”（RTPFB，即传输层反馈报文），是RTCP协议中用于传输层反馈的报文类型，定义在RFC 4585及RFC 5104等标准中。主要用于快速反馈网络拥塞、丢包等传输状况，特别是在基于自适应拥塞控制的实时通信中应用广泛，如WebRTC。
报文总体结构
205报文的格式与其他RTCP报文相似，均包含公共报文头，但其payload部分是特定的反馈格式，主要用于传输层反馈。主要字段包括：
| 字段名 | 大小（bit或字节） | 说明 |
|---|---|---|
| Version (V) | 2 bits | RTCP版本，固定为2 |
| Padding (P) | 1 bit | 填充标志 |
| FMT (格式类型) | 5 bits | Feedback Message Type，反馈子类型，用于区分不同反馈格式 |
| PT (Packet Type) | 8 bits | 报文类型，固定为205 |
| Length | 16 bits | 报文长度，以32位字（4字节）为单位减1 |
| SSRC of Packet Sender | 32 bits (4字节) | 发送该RTCP 205报文的源标识符 |
| SSRC of Media Source | 32 bits (4字节) | 被反馈的RTP数据源标识符 |
| Feedback Control Information (FCI) | 可变 | 具体反馈数据结构，依FMT类型定义。 |
FCI举例：
对于负反馈（NACK）来说，FCI包含丢失包的序号信息；
对于拥塞控制反馈，可能包含接收时间戳、ECN标记、序列号等详细拥塞指标。
反馈子类型
| FMT 值 | 用途描述 |
|---|---|
| 1 | NACK（Negative Acknowledgment）请求发送方重传指定包 |
| 3 | TMMBR（Temporary Maximum Media Stream Bit Rate Request）临时最大码率请求 |
| 4 | TMMBN（Temporary Maximum Media Stream Bit Rate Notification）临时最大码率通知 |
| 5 | SR_REQ（Sender Report Request）请求发送方发送SR报文 |
| 6 | RAMS（Recovery Assist Message for Streams） |
| 7 | TLLEI（Too Late Loss Event Information） |
| 8 | ECN（Explicit Congestion Notification） |
| 9 | PS（Payload Specific） |
| 15 | Transport Wide CC（Transport Wide Congestion Control） |
NACK
在 RTCP 中 NACK 代表否定应答，当接收⽅监测到数据包丢失，发送⼀个 NACK 到发送⽅，表明⾃⼰没有收到某个报⽂。⽬前 NACK 可以认为是对抗弱⽹最主要的⼿段，报⽂格式如下:
| 字段 | 长度（位） | 说明 |
|---|---|---|
| Packet ID (PID) | 16 | 丢失RTP包的序列号 |
| Bitmask of Lost Packets (BLP) | 16 | 标识从PID开始连续16个包的丢失情况，1表示丢包 |
Transport-CC
Transport-cc 是⽬前 Webrtc 中最新的拥塞控制算法，替代旧的 GCC 算法; 基于RTP报头扩展机制，引入了统一的transport-wide sequence number（全局传输序列号），使得同一PeerConnection下所有媒体流的包均有唯一序列号，方便整体带宽估计与拥塞控制。
该报文详细反馈了接收到的每个包的状态（丢失、接收）以及精准的到达时间，用于发送端更精细地计算网络传输延迟、丢包情况和拥塞状态。
RTCP Transport-CC反馈报文结构示意：
| 字段 | 说明 |
|---|---|
| RTCP公共头部 | 版本、填充、FMT=15、PT=205、长度 |
| SSRC of packet sender | 发送反馈的端同步源标识符 |
| SSRC of media source | 被反馈的媒体流同步源标识符 |
| Base sequence number | 序列号起点 |
| Packet status count | 报告的包数量 |
| Reference time | 参考时间，单位为1/64秒 |
| Feedback packet count | 反馈包计数，用于区分不同反馈包 |
| Packet chunk(s) | 包状态集合，压缩编码包收发状态 |
| Reception delta(s) | 每个包的接收时间增量（以微秒或1/250ms为单位） |
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P| FMT=15 | PT=205 | length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of packet sender |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of media source |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| base sequence number | packet status count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| reference time | fb pkt. count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| packet chunk | packet chunk |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. .. .+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| packet chunk | recv delta | recv delta |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. .. .+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| recv delta | recv delta | zero padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TMMBR MMBN
1. TMMBR（Temporary Maximum Media Stream Bit Rate Request）
功能：接收端发送给发送端的临时最大码率请求，用于通知发送端当前网络条件下允许的最大媒体码率，以避免网络拥塞。
用途：在网络抖动或拥塞时，接收端通过TMMBR限制发送码率，保证数据流稳定，防止过载。
格式要点：报文中包含码率的指数（Exp）和尾数（Mantissa），以及测得的平均开销（Measured Overhead），计算最大码率为 系数×2^指数，单位是比特每秒。
发送方反应：发送端收到TMMBR后，应调整编码器输出码率，使其不超过请求值。
2. TMMBN（Temporary Maximum Media Stream Bit Rate Notification）
功能：这是对TMMBR请求的响应通知，由发送端发出，告知接收端当前采用的最大码率限制。
作用：反馈已接受的码率限制及其所有者，保障多接收端环境下码率限制的一致性。
发送主体不同：与其他反馈报文由接收端发出不同，TMMBN由发送端发出作为确认。
| 报文类型 | 描述 | 发送者 | 作用 |
|---|---|---|---|
| TMMBR | 临时最大码率请求 | 接收端 | 请求发送端降低码率以防网络拥塞 |
| TMMBN | 临时最大码率通知 | 发送端 | 通知接收端采用的码率限制及确认 |
PSFB PT=206
RTCP报文中，PT=206代表的是Payload Specific Feedback (PSFB)，即负载相关反馈报文。它是RTCP协议中用于传输针对特定负载类型的反馈信息的报文类型，定义在RFC 4585等扩展规范中，主要用于视频、音频等多媒体流的质量反馈与控制。
| 媒体类型 | 特点描述 | 参考关系 | RTCP反馈需求 |
|---|---|---|---|
| 音频 | 小包，前后帧无参考关系 | 无 | 需要基本的传输质量反馈，如丢包、抖动等 |
| 视频 | 帧间具有关联，帧之间有参考关系 | 关键帧为GOP内其他帧的主要参考 | 需要针对视频载荷的更精细化反馈机制，如关键帧请求、切片丢失反馈等 |
报文结构
公共报文头：与其他RTCP报文类似，包含版本（V=2）、填充（P）、反馈消息类型（FMT，5位）、报文类型（PT=206）和长度字段。
发送者SSRC（32位）：发送此反馈报文的参与者的同步源标识符。
媒体源SSRC（32位）：被反馈的RTP媒体流的同步源标识符。
反馈控制信息（FCI）：根据不同的反馈类型（FMT）具体定义，其长度和格式依具体反馈类型不同而变化。
反馈消息类型
由于Payload Specific Feedback覆盖了多个反馈消息，每种通过FMT字段区分，常见的包括但不限于：
PLI（Picture Loss Indication，格式值为1）：请求发送方重传完整关键帧，用于视频流中丢失帧的快速恢复。
FIR（Full Intra Request，格式值为4）：请求发送新完整关键帧，通常用于视频中快速同步。
SLI（Slice Loss Indication）：反馈视频编码中某些片段（slice）丢失情况。
RPSI（Reference Picture Selection Indication）：指示发送端调整参考帧以改善解码。
AFB（Application-layer Feedback）：扩展应用反馈。
⽬前业务中主要有以下类型：
| 类型 | 简称 | 作⽤描述 | 传输对象 |
|---|---|---|---|
| 1 | PLI | Picture Loss Indication，关键帧请求，用于接收端通知发送端快速发送关键帧。常用于丢包重传I帧。 | 接收端发给发流端 |
| 4 | FIR | Full Intra Request，完整关键帧请求，用于请求新关键帧以恢复视频同步。常用于首播强制I帧。 | 接收端发给发流端 |
| 15 | AFB | Application-layer Feedback，应用层反馈；用于码率控制器根据远端估计最大码率Ar计算并通过RTCP REMB报文反馈给发送端 | 接收端发给发流端 |
FIR和PLI的本质区别在于：
| 特性 | PLI | FIR |
|---|---|---|
| 触发场景 | 视频帧部分丢失或解码失败，要求发送关键帧恢复 | 解码器清空或重置，新接收方加入，或需硬性刷新关键帧 |
| 携带信息 | 不携带编码器参数，仅请求关键帧 | 携带编码器相关控制信息，帮助接收端清空解码器状态 |
| 功能侧重点 | 快速恢复丢失帧，恢复正常视频播放 | 彻底刷新解码器状态，保证解码同步和流的正确起始 |
| 使用频率 | 常用于丢包后的快速修复 | 用于解码器状态重置和新用户加入等特殊场景 |
REMB详解
REMB报文由接收端发送，告知发送端它所能接收的最大比特率（带宽估计值），以便发送端根据该反馈动态调整媒体的发送码率（如分辨率、帧率等），避免网络拥塞，改善实时视频通话或媒体传输质量。
REMB报文格式举例
Payload Type（PT）：206，表示Payload Specific Feedback。
FMT（Feedback Message Type）：15，表示应用层反馈（Application Layer Feedback）。
发送者SSRC：发送REMB报文的端的同步源标识符。
媒体源SSRC：此字段设为0（不使用），符合相关RFC的规定。
Unique Identifier：固定为ASCII字符"REMB"，用于标识该报文为REMB。
Num SSRC：反馈中涉及的SSRC数量。
BR Exp（带宽指数部分，6位）：用于带宽的指数扩展，表示带宽估计值的指数部分。
BR Mantissa（带宽尾数部分，18位）：带宽估计值的尾数部分
SSRC feedback列表：列出REMB反馈所涉及的具体媒体流SSRC。
常与RTP扩展头abs-send-time配合使用，通过精确时间戳提升带宽估计准确度。发送方收到REMB报文后，应尽快调整发送速率，确保发送码率不超过反馈的最大带宽估计，以避免网络拥塞。REMB虽未正式成为RFC标准，但已被各大浏览器和WebRTC实现广泛支持。
XR PT=207
RTCP 在很早之前就定义了扩展报告，主要是在 SR/RR 基础之上携带补充信息，它由IETF在RFC 3611中定义，目的是提供更丰富、更详细的传输质量和网络状态监测数据。满足如多播网络推断（MINC）和VoIP监控等应用需求。
报告块（Report Blocks）
官方文档：@see: http://www.rfc-editor.org/rfc/rfc3611.html#section-2
报文字段详细介绍：
报文头
版本（Version, 2 bits）：固定为2
填充（Padding, 1 bit）
保留字段(reserved 5 bit)
报文类型（Packet Type）：207，表示XR
报文长度（Length）：32位字为单位，报文总长度-1
发送者SSRC（32位）：发送此XR报文的同步源标识符
报告块（Report Blocks）
XR报文由零个或多个扩展报告块组成
报告块排列顺序紧随报文头，按块类型顺序堆叠
每个报告块都有自己的块类型字段（Block Type，8 bits）、类型特定字段和块长度
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|reserved | PT=XR=207 | length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: report blocks :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+XR报告块通用格式
每个报告块包括：
Block Type (BT, 8 bits)：区分不同报告块的格式和含义
Type-specific (8 bits)：字段内容依报告块类型而定
Block Length (16 bits)：单位为32位字长，不包括头部，指示块数据长度
Block Contents：具体报告块数据，按类型定义结构排列
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| BT | type-specific | block length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: type-specific block contents :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+XR报告块类型
RFC 3611中定义了七种主要XR报告块，涵盖网络性能的细节指标，具体包括：
Loss RLE Report Block：按包序号编码的丢包情况
Duplicate Report Block：重复包统计
Packet Receipt Times Report Block：包接收时间戳
Packet Delay Variation (PDV) Report Block：网络时延变化
VoIP Metrics Report Block：VoIP质量指标，如延迟、抖动、丢包等
Receiver Reference Time Report Block：接收端参考时钟时间
Discarded Packets Report Block（RFC 7243扩展）：丢弃包计数
具体详细信息，请看官方文档，每种类型有单独的报告块格式。
音视频同步
在RTP传输中，timestmap 的初始值是随机产⽣且是独立的，也就是说音频和视频不能相互参考。因此需要RTCP 提供额外信息来进⾏同步。为了实现音视频同步，发送端会定期发送 SR报文，携带rtp timestmap、ntptime，接收端把每路流收到的 rtp timestamp 都转换为 NTP 时间，实现同步。
其中音频的采样点数能反映出rtp.timestmap间隔，其中计算公式是
采样点 = 采样率 * ( 每帧间隔 / 采样率时间单位) 。
简写：采样点数=采样率×每帧间隔（秒）
其中推导公式是 采样点 / 采样率 = 采样率时间单位 / 每帧间隔 = 每个采样率时间单位内需采样次数。
比如使用Opus编码时，采样率（1s）是48000Hz，，每帧20ms，48000×( 20ms / 1000ms) = 960，会使得timestamp每次增加960，以保持时间上的同步和顺序。
对于视频的RTP时间戳计算，基于视频采样率和帧率的原理类似，但视频采样率时间单位是固定90 kHz时钟，对应每秒90000个时间单位。帧间间隔由帧率决定。视频时间戳递增计算公式为：
时间戳增量=采样率时间单位/帧率=90000/帧率
但是，视频帧的时间戳递增不一定完全固定，原因在于：视频帧的发送时间通常基于系统时钟动态计算，会有微小误差，导致时间戳递增不是绝对固定值。帧间隔较长，且帧间间隔易受关键帧生成、码率调整、网络拥塞和同步机制变化影响，因此视频时间戳增量会有明显波动。可以理解为画面不同码率分配，导致时间戳偏移量不固定。
参考文献
RFC5104 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
RFC 3611: RTP Control Protocol Extended Reports (RTCP XR)