流媒体协议之RTCP | 头快撑不住了

RTCP（Real-Time Control Protocol，实时控制协议）是用于实时音视频通信的控制协议，用于实现对RTP（Real-Time Transport Protocol，实时传输协议）流的监控和反馈。

例如，在一场网络视频会议中，RTCP 会定期向发送方报告接收方的数据包丢失率、延迟抖动等信息。发送方接收到这些反馈后，可以相应地调整编码速率和发送策略，以优化视频的流畅度和质量，确保 RTP 流能够更稳定、高效地传输。

一、RTCP作用

流同步：可以用 RTCP 将多个媒体流进行同步，保证音视频的同步播放。
带宽管理：RTCP 可以监控网络带宽和质量，确保多个媒体流之间的带宽使用均衡，保证整个网络的带宽使用效率。
QoS 保证：RTCP 可以监控 RTP 流的传输质量，包括延迟、丢包、抖动等，通过传递 RTCP 报告信息给应用程序，应用程序可以及时调整传输策略，提高媒体流的质量。
流控制：RTCP 可以控制媒体流的发送速率，避免网络拥塞和带宽浪费。

总之，RTCP 是 RTP 的重要补充，通过周期性发送 RTCP 报告，可以监控和控制 RTP 流的质量，提高实时多媒体传输的效率和质量。

二、RTCP基本工作原理

RTCP 发送方：在 RTP 会话开始时，RTCP 发送方会周期性地发送 RTCP 报告。RTCP 报告包含有关 RTP 流的统计信息，例如发送方和接收方的 SSRC、延迟、抖动、丢包率等信息。
RTCP 接收方：在接收到 RTP 流时，RTCP 接收方会从 RTP 数据包中提取信息并维护相关的状态信息，用于生成 RTCP 报告。在收到 RTCP 报告后，RTCP 接收方会更新状态信息，并根据需要发送 RTCP 应答报文。
RTCP 控制：RTCP 报告不仅包含有关 RTP 流的统计信息，还包括控制信息，例如建立或终止 RTP 会话、限制发送速率等。发送方可以根据接收到的 RTCP 报告和应答报告调整发送速率，以避免网络拥塞和带宽浪费，同时确保 RTP 流的传输质量。
RTCP 会话控制：RTCP 会话控制协议定义了用于控制 RTCP 的一组协议，例如在 RTP 会话开始和结束时启动和终止 RTCP 报告的机制。

三、RTCP报文解析

3.1 RTCP数据包格式

 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|  Count  |      PT       |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V(Version)：2 bit，协议版本号，当前为2
P(Padding)：1 bit，填充位，若有，最后一个字节为填充字节个数(包括该字节本身)
Count：5 bit，RTCP包中report block的个数
PT(Payload Type)：8 bit，载荷类型
Length：16 bit，RTCP包长度，包括Header和Payload，包大小计算方式为(Length-1)*4字节

3.2 RTCP的包类型

RTCP类，包括SR、RR、SDES、BYE、APP等5种类型，由rfc3550定义
RTCP Feedback类，包括RTPFB、PSFB两个子类，由rfc4585定义
- RTPFB：Transport layer FB，传输层反馈
- PSFB：Payload-specific FB、Application layer FB，负载和应用层反馈，比如解码发生了异常

3.3 RTCP类

3.3.31 RTCP SR(sender reporter)

        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                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SSRC of sender ：发送者的SSRC
sender info block 20个字节，描述了发送端相关的信息
- NTP timestamp ntp时间戳，用于音视频同步
- RTP 时间戳
- sender’s packet count SPC发送了多少个包
- sender’s octet count SOC发送了多少字节
report block 每一个接收者的报告块，音视频不共用
- SSRC_n **** 每个接收块所针对的RTP流的SSRC标识符。
- fraction lost:表示丢失的数据包的比例，范围从0到255（因为使用的是8位表示）。值为255表示丢失了所有数据包。
- cumulative number of packets lost:丢失的包的数量
- Extended highest sequence number received (32 bits): 收到的最高序列号数据包的扩展序列号，包含了序列号的包数周转信息。
- Interarrival jitter (32 bits): 接收数据包的到达时间抖动，是接收时间与预期到达时间的统计偏差。
- Last SR (LSR, 32 bits): 上一个发送者报告（SR）中时间戳字段的中位值，用于RTCP的时间同步。
- Delay since last SR (DLSR, 32 bits): 计算参考接收报告中的上一个发送者报告（SR）与当前收到的时间差，用纳秒计算。
Profile-specific extensions (可选): 这部分包含一些特定于应用程序或协议的拓展信息。这部分是可选的，并且其格式和内容是应用程序依赖的。

问题：为什么SR需要report block？

因为有时发送者也是接收者，比如可视对讲的情况下，可以在一个包里边即报告了发送RTP数据包的数据状态，又可以报告接收的数据包的数据状态。

3.3.2 RTCP RR

        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=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                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RR的内容和SR基本一致，除了RR中没有sender info 以及PT为201。

3.3.3 RTCP SDES

源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。其中有价值的是 CNAME，其作用是将不同的源（SSEC）绑定到同一个 CNAME 上。当重传流时，SSRC 会冲突，可以通过 CNAME 将旧的 SSRC 更换成新的 SSRC，从而保证通信的每一个 SSRC 都是唯一的。

3.3.4 RTCP BYE

通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。当 WebRTC 收到该报文时，就会删除该 SSRC 对应的通道。

3.3.5 RTCP APP

由应用程序自己定义，解决了 RTCP 的扩展性问题，并且为协议的实现者提供了很大的灵活性。

3.4 RTCP Feedback类

3.4.1 PT = 205 表示 RTPFB

webrtc中主要使用了如下两个报文

3.4.2 PT = 206 表示PSFB

举例，

四、总结

RTCP（Real-Time Control Protocol）是用于实时音视频通信的控制协议，用于监控和反馈RTP流。RTCP的作用包括流同步、带宽管理、QoS保证和流控制。它是RTP的重要补充，通过周期性发送RTCP报告，能监控和控制RTP流质量，提高实时多媒体传输效率和质量。

RTCP的基本工作原理如下：在RTP会话开始时，发送方周期性发送包含RTP流统计信息和控制信息的RTCP报告，接收方提取并维护相关状态信息用于生成报告，还会根据收到的报告更新状态和发送应答报文，发送方根据报告调整发送速率。

RTCP包类型包括RTCP类（SR、RR、SDES、BYE、APP）和RTCP Feedback类（RTPFB、PSFB）。SR包含发送者信息和接收者报告块，RR与SR内容基本一致但无发送者信息。SDES用于源描述，BYE用于通知离开，APP由应用程序自定义。RTPFB和PSFB分别用于RTP传输过程中的feedback以及码流相关的feedback