WebRTC服务质量（03）- RTCP协议

一、前言：

RTCP（RTP Control Protocol）是一种控制协议，与RTP（Real-time Transport Protocol）一起用于实时通信中的控制和反馈。RTCP负责监控和调节实时媒体流。通过不断交换RTCP信息，WebRTC应用能够调整比特率、编码方式等，适应网络条件，确保音视频通话的质量。同时，RTCP与RTP共同工作，使得数据传输不仅准确，而且高效。

二、RTCP Header：

RTCP有很多格式，常见的有：SR（Sender Report）、RR（Receiver Report）、SDES（Source Description）、BYE（Goodbye）。他们格式各不相同，

但是，他们的Header的共同部分为：
在这里插入图片描述

Version (V)：占两位，表示RTCP版本，当前版本是2；
Padding §：占1位，表示是否有填充字节。如果该字段为1，则表示有填充字节；
Reception Report Count (RC)：占5位，表示报告块的数量。每个RTCP报文可以包含多个报告块；
Packet Type (PT)：表示该RTCP报文的类型，例如：
- SR（Sender Report，发送者报告）
- RR（Receiver Report，接收者报告）
- SDES（Source Description，源描述）
- BYE（结束会话）
- APP（应用层自定义信息）
Length：占16位，表示此 RTCP 数据包（包括报头本身）的长度（以 32 位为单位减一）。比如，一个 RTCP 报文的总长度（包括头部）是 80 个字节，那么我们需要将这个长度转换成 32 位单位，然后减去 1 来填写在 RTCP 头部的长度字段中。
- 首先，将总长度转换成 32 位单位：
  - 80 字节 = 80 * 8 = 640 位
  - 640 位 / 32 = 20 个 32 位字
- 接下来，根据文档的描述，需要减去 1，即：
  - 20 个 32 位字 - 1 = 19
SSRC of sender: 占用32位，表示发送该RTCP报文的源的同步源标识符（SSRC）。用来唯一标识一个媒体发送者。

三、RTCP Packet Type：

常见的有：

SR（Sender Report）：
- 发送者报告，包含有关发送者的统计信息，如发送的总包数、发送时的时间等。它提供了性能监控的关键指标，例如丢包率和延迟。
RR（Receiver Report）：
- 接收者报告，包含有关接收的数据包的统计信息，如接收的总包数、丢失的包数等。接收者使用此报告来向发送者反馈接收状态。
SDES（Source Description）：
- 源描述，提供有关媒体源的附加信息，例如源的名称、电子邮件地址、电话等。这有助于会话中的参与者识别彼此。
BYE：
- 结束报告，表示一个或多个参与者离开会话。当参与者不再发送数据时，它会向其他参与者发送 BYE 消息，以通知他们。
APP：
- 自定义的RTCP报告，允许应用程序定义自己所需的反馈和信息。
FIR（Full Intra Request）：
- 向对方请求发送关键帧（全内编码帧），主要用于视频流媒体的情况，以便重新同步流。
NACK：当接收端收到的数据有丢失的情况下，给发送端发送一个NACK；发送端收到NACK之后，首先看这个包有没有超时，如果没有超时，那么重新将这个包发送给接收端；
RTPFB（RTP Feedback）：
- 一般性RTP反馈，能够携带多种反馈信息，包括质量、丢包、抖动等。它通常是用于更详细的动态反馈机制。
PSFB（Payload Specific Feedback）：
- 根据负载的特殊情况返回的反馈，通常用于特定编解码器的附加功能，例如流量控制和优化。

下面详细看看每一中Type，当然，重点还是SR/RR。

3.1、SR：

RTCP SR（Sender Report）是实时传输控制协议（RTCP）中的一种报文类型，用于发送端向接收端提供有关发送者的信息。RTCP SR 报文包含了发送端的时间戳信息以及关于发送端发送媒体流的统计数据。

格式如下：

    0                   1                   2                   3
        0 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                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SR由以下部分组成：

Header：标准的RTCP头部，包括基础的控制信息，前面已经说明过了。
Sender Info：发送者信息，包括：
- NTP Timestamp：64位，表示真实世界的时间，可以用来进行音视频同步，因为不同的源，真实世界的时间是一样的。
- RTP timestamp：32位，相对时间，只真针对这一路流；和RTP里面的时间戳一致；
- Packet Count：32位，表示在统计期间内成功发送的RTP数据包总数。这有助于接收者了解发送者在给定时间窗口内的活动量。
- Octet Count：32位，总共发送的数据量，因为我们知道了总发包数，不一定知道总发送数据量，因为一个包大小有可能是50字节，也有可能是100字节。
n个Report block：每个报告块提供有关接收流的统计信息。每个接收的流（SSRC）都可能对应一个Report block，因此如果您接收了5路流，则可能会有5个Report block。每个Report block提供了关于特定源的接收信息。
SR中包含RR: 标准允许在SR中含有RR，这样可以节省带宽，就是我不光告诉你我发送的情况，我还会把我之前接收的报告顺便发给你。然而，在WebRTC中，通常情况下，发送者报告（SR）并不会包含接收者报告（RR），而是单独发送RR来避免复杂性和规模问题。这种设计使得每种报告可以专注于其主要作用，提高了传输效率。
- SSRC_1 (SSRC of first source)：
  - 描述：这一字段指定了发送者的同步源标识符（SSRC），它是发送方在RTCP中的唯一标识符，有助于接收方识别信息源。
- Fraction lost (丢包比例)：
  - 描述：表示自上次报告以来丢失的数据包的比例。它是一个8位字段，具体计算为丢包数与接收总数的比例。范围在0到255之间，值越低表示丢失的包越少。
- Cumulative number of packets lost (丢失的包总量)：
  - 描述：这个字段是一个32位的计数器，从会话开始到当前报告时已经丢失的所有包的累计数量。这有助于发送方评估网络的稳定性。
- Extended highest sequence number received (扩展的最高序列号)：
  - 描述：该字段的意义在于记录接收方所接收到的最高序列号。这是一个32位的值，能够帮助发送方了解接收方的接收情况。这也有助于分析包的顺序，判断是否发生了重传。
- Interarrival jitter (到达抖动)：
  - 描述：表示数据包到达时间的变化（抖动），是一个32位的值，用于衡量数据包传输的延迟变化。这对于实时应用（如音频和视频）至关重要，因为抖动会影响用户体验。
- Last SR (LSR) (上一个发送报告时间)：
  - 描述：该字段表示上一次发送报告的时间戳，通常以NTP（Network Time Protocol）时间格式表示。通过了解最近的发送时间，可以更好地评估当前的网络状况。
- Delay since last SR (DLSR) (自上次发送报告以来的延迟)：
  - 描述：表示当前报告时与上一次报告之间的延迟。这有助于发送方评估发送响应的时效性，确定网络延迟是否在可接受范围内。
- 示例场景:
  - 假设在一个视频会议中，有一个发送者和多个接收者，发送者使用RTCP Sender Report来反馈其数据包的发送情况。我们来看一份具体的Sender Report：

Sender Report (SR)
  SSRC: 123456789
  Fraction lost: 5
  Cumulative number of packets lost: 20
  Extended highest sequence number received: 500
  Interarrival jitter: 100
  Last SR (LSR): 1618848000 (NTP timestamp)
  Delay since last SR (DLSR): 50

字段分析:
1. SSRC (123456789)：发送者的唯一识别标识符。接收方可以在多方通话中通过这个值确认哪个发送者发送了该报告。
2. Fraction lost (5)：值为5，表示自上次报告以来，丢失的包占接收到总包数的比例。假设接收方共接收到100个包（即接收到的包总数可能是100 + 5 = 105），那么丢包率为5%。这表明网络传输不是很好，需要关注。
3. Cumulative number of packets lost (20)：自会话开始到当前时刻，已经丢失的包总数为20。这可帮助发送方了解其发送的稳定性，若持续增加，则可能需调整发送策略或改善网络条件。
4. Extended highest sequence number received (500)：该字段表示接收方接受到的最高序列号为500，意味着它已经成功收到的包的一个连续编号。这有助于检测出是否有包丢失，以及是否以正确的顺序到达。
5. Interarrival jitter (100)：100毫秒的抖动值表明数据包到达的时间不稳定，这可能会导致视频或音频播放时的延迟和不流畅感。较高的抖动值意味着网络不稳定，需要优化网络。
6. Last SR (LSR) (1618848000)：这是NTP时间戳，表示上一个发送报告的时间。假设该时间戳对应于某个特定的时刻（如2021年4月1日），这使得接收方能够判断报告的时效性。
7. Delay since last SR (DLSR) (50)：值50表示自上次发送SR报告以来经过的延迟为50毫秒。这表明数据传输的延迟相对较低，发送方能够及时得到反馈。

3.2、RR：

RR（Receiver Report）接收者报告，消息包含多个报告单元，分别反映不同的接收者关于接收数据的质量。

在这里插入图片描述

和SR相比，没有Sender Info字段；
其他和SR相同；

3.3、SDES：

SDES (Source Description) 格式用于传递与媒体源相关的描述信息，例如用户名、邮箱地址、流的名称等。

报文格式：

0                   1                   2                   3   
 0 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|    SC   |  PT=SDES=202  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SSRC/CSRC_1                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SDES items                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SDES items                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SDES 报文由一个 RTCP 头部和一个或多个SDES项组成。

SC：表示seds item count，就是后面带了多少item；
PT：202
length：表示这个包有多大；
item：由两部分组成，SSRC和具体SDES items；

后面的每个SDES items：

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SDES type     |     length    |         SDES text           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SDES type: 8 bits，表示SDES项的类型，指示该项包含的是何种信息，如参与者的名称、邮箱地址等。我们一般都是使用CNAME，除了CNAME，还有其他类型如下：
- 0：会话名称（CNAME）
- 1：邮箱（EMAIL）
- 2：用户名（NAME）
- 3：流名称（RID）
- 4：工具（Tool）
- 5：网址（LOCATION）
length: 8 bits，表示SDES项值的长度，以字节为单位。
SDES text: 包含SDES项的实际值，可以是参与者的名称、邮箱地址、电话号码等描述信息。

可以看出是一种TLV格式，如果作为服务器，接收到多路客户端一起推流，那么有可能ssrc会冲突，服务器就会告诉客户端使用原来的CNAME来重新计算一个SSRC，这个过程的协商就是SDES完成的；

示例：

在媒体协商时候，为每一个源都设置好了一个CNAME，假如抓到如下报文：

那么：
1. PT为202表示SDES，length为6（计算长度为（6+1）*4 = 28字节）；
2. SDES中每一项都叫做一个Chunk，Chunk中包含SSRC + Sdes item；
3. 每一个SSR对应多个item；
4. Text就是这个SDES item具体内容；

3.4、BYE：

主要用于告知其他参与者某个源（通常是发送者）已经结束通信或不再发送媒体流。

报文格式如下：

0                   1                   2                   3
 0 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|    SC   |   PT=BYE=203  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          length              |          reason for leaving    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTCP 头部：
- Version (2 bits): 表示 RTCP 的版本，当前版本为 2。
- Padding (1 bit): 指示报文是否有填充部分。
- Reception Report Count (RC) (5 bits): 在 BYE 报文中通常为 0。
- Packet Type (8 bits): 对于 BYE 报文，其值为 203。
- Length (16 bits): 表示后续负载的长度，以 32 位字（4 字节）为单位计算。
SSRC 列表：
- 该部分包含一个或多个发送源的同步源标识符（SSRC）。这些 SSRC 表示已结束的媒体流的发送者。
原因代码 (可选):
- BYE 报文中还可以包含一个可选的原因字段，以指示发送者停止原因（如正常停止、错误等）。
其他信息 (可选):
- 可包含文本信息，如告别消息等，长度取决于具体情况。

3.5、APP：

RTCP APP（Application-Defined RTP Control Protocol）报文是一种可扩展的 RTCP 控制消息，允许应用程序在 RTCP 报文中插入自定义信息。RTCP APP 报文灵活，能够提供应用特定的反馈、信息或统计数据，适用于多种场景，比如流媒体传输、实时会议和在线游戏。

报文格式如下：

0                   1                   2                   3
 0 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| subtype |   PT=APP=204  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC/CSRC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          name (ASCII)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    application-dependent data                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

前面都是xxx count，这儿变成了SubType，我们可以定义多个APP，使用这个ST区分。
body部分第一个是ssrc：表示这个包所有操作都是针对这个ssrc进行的；
name和data：名字和具体数据；

3.6、FIR：

用于请求发送者发送一个关键（全帧）帧。

报文格式如下：

0                   1                   2                   3
 0 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=4  |   PT=FIR=192  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC of packet sender                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC of media source                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V (Version):
- 2 bits，固定为 2，表示 RTCP 协议的版本。
P (Padding):
- 1 bit，指示是否存在填充字节。
FMT (Format):
- 5 bits，这里值为 4，表示 FIR 报文的特定格式。
PT (Packet Type):
- 8 bits，值为 192，指示这是一个 FIR 报文。
length:
- 16 bits，表示整个 RTCP 报文的长度，单位为 4 字节（即报文中包含的字的数量减去 1）。
SSRC of packet sender:
- 32 bits，表示发送 RTCP FIR 报文的发送者的同步源标识符（SSRC）。就是接收者自己SSRC。
SSRC of media source:
- 32 bits，表示希望请求关键帧的媒体源的 SSRC。接收者请求的发送者SSRC。

3.7：NACK：

RTCP NACK（Negative Acknowledgement）报文用于指示丢失的媒体包，以便发送端重传这些包。以下是RTCP NACK报文的格式：

0                   1                   2                   3
 0 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=1  |   PT=NACK=205 |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC of packet sender                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of media source for which NACK is sent   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    NACK PID PID PID PID ...                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V (Version):
- 2 bits，表示 RTCP 协议的版本，固定为 2。
P (Padding):
- 1 bit，指示报文是否包含填充字节。
FMT (Format):
- 5 bits，指定报文的格式类型。NACK 报文的格式为 1。
PT (Packet Type):
- 8 bits，指示报文类型。NACK 报文的类型值为 205。
length:
- 16 bits，表示整个 RTCP 报文的长度，以 32 位字（4 字节）为单位计算。
SSRC of packet sender:
- 32 bits，指示发送 RTCP NACK 报文的发送者的同步源标识符（SSRC）。
SSRC of media source:
- 32 bits，表示请求重传丢失媒体包的源的 SSRC。
NACK PID:
- 32 bits，后续字段用于列出丢失的媒体包的序列号（Packet IDs），以便发送方进行重传。

3.8、FB信息：

RTCP RTPFB（RTP Feedback）报文用于提供有关RTP数据流的反馈信息。

报文格式如下：

0                   1                   2                   3
  0 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          |             length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     SSRC of packet sender                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      SSRC of media source                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      FCI                                                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FMT：feedback message type，返回报文的消息类型，就可以区分比如前面的PLI、FIR、REMB；
PT：payload type，205或者206；
SSRC of packet sender：这个报文由谁发送的；
SSRC of media source：表示我们这个报文是针对哪个媒体源反馈的报文；
FCI：这个值就需要根据前面的FMT来确定了；不同FMT有不同的格式；

按照PT分类：

主要分为传输层的FB、负载层的FB和应用层的FB。这些不同类型的反馈报文通过FB Type字段来区分，以便接收端和发送端能够正确解释和处理反馈信息。

传输层的FB（RTPFB）：
- 传输层的FB主要关注RTP流的传输和接收情况，通常用于网络拥塞控制、丢包恢复等。
- 传输层的FB主要涉及网络传输方面的问题，如丢包、网络延迟等。
- 传输层的FB Type一般在范围0-191。
负载层的FB（PSFB）：
- 负载层的FB关注RTP载荷的内容，例如视频编解码方面的信息，如图像质量、分辨率等。
- 负载层的FB主要针对RTP载荷内容的质量和特征进行反馈。
- 负载层的FB Type一般在范围192-254。
应用层的FB：
- 应用层的FB与应用层的特定需求和协议相关，用于传递应用层特定的反馈信息。
- 应用层的FB主要用于特定应用场景下的反馈需求，例如实时协作应用、多媒体通信应用等。
- 应用层的FB Type一般在范围256-383。

3.9、RTPFB：

传输层的FB，报文头就是3.8、FB信息那样，PT为205：

payload type为205的时候，传输层的RTPFB，主要传输下面几种包：

NACK：就是一般的重传型；
TMMBR：表示发送一个最大码流请求；
TMMBN：最大码流请求的响应；
TFB：最重要，传输层的拥塞控制报文；

具体如下：

1）NACK（Negative Acknowledgement）

定义: 用于通知发送方哪些 RTP 数据包未被成功接收。
功能: 请求重传丢失的数据包，确保接收方能够获得完整的媒体流。
示例: 接收方发送 NACK 报文，指出包 123 和 124 丢失，请求发送方重传。

2）TMMBR（Temp Maximum Media Bit Rate）

定义: 临时最大媒体比特率请求，通知发送方在当前网络条件下建议的最大比特率。
功能: 当检测到网络拥塞或带宽不足时，接收方可以请求发送方降低比特率，以保证媒体流的稳定。
示例: 接收方通过 TMMBR 报文请求将发送比特率降低到 920 kbps，适应网络带宽。

3）TMMBN（Temp Maximum Media Bit Rate Notification）

定义: 对 TMMBR 请求的确认，指示接收方接受的最大媒体比特率。
功能: 确保发送方了解当前网络状况，并进行相应调整。
示例: 接收方确认发送方可以按照 920 kbps 的比特率发送数据流。

4）TFB（Transport Feedback）

定义: 传输反馈报文，专用于传输层的拥塞控制。
功能: 提供实时的网络状态反馈，包括丢包率、延迟和带宽利用率，帮助发送方优化其流量控制策略。
示例: 接收方发送 TFB 报文，通知发送方当前丢包率为 2%，建议减少发送速率以避免拥塞。

3.10、PSFB：

PSFB（Payload-Specific Feedback）是一种 RTCP（Real-time Control Protocol）反馈机制，用于针对特定负载类型提供反馈信息，报文头就是3.8、FB信息那样，PT为206。下面是三种常见的 PSFB 报文类型及其作用：

PLI（Picture Loss Indication）：
- PLI 用于指示接收端在视频通话中丢失了整个关键帧（I-frame），请求发送端发送下一个关键帧，以确保视频解码器能够正确重建视频帧序列。
- PLI 的接收端将其发送给发送端，发送端收到后会尽快发送下一个关键帧。
FIR（Full Intra Request）：
- FIR 用于请求发送端发送一个完整的关键帧（I-frame），通常用于视频通话中的图像清晰度恢复或者加入新的参与者时需要一个完整的起始点。
- FIR 报文的接收端发送给发送端，发送端收到后会立即发送一个完整的关键帧。
REMB（Receiver Estimated Maximum Bitrate）：
- REMB 用于接收端向发送端报告其估计的最大比特率，以便发送端可以根据接收端的带宽情况调整视频编码参数，以最大程度地利用可用的带宽。
- REMB 报文能够帮助发送端动态调整编码比特率，以优化视频传输并避免网络拥塞。

四、Compound RTCP：

Compound RTCP 是指将多个 RTCP（Real-time Control Protocol）包合并到一个复合包中一起发送，以减少网络传输开销和提高效率。

1、报文结构：

一般情况下，一个 Compound RTCP 数据包的结构如下：

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTCP SR/RR                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTCP SDES                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Other RTCP                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

可以看出，规定了必须先以SR/RR开头，然后紧接着SDES，后面是其他的信息。Compound RTCP 需要周期发送。