流媒体协议之RTCP

头快撑不住了2024-08-29 22:07

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

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

一、RTCP作用

  1. 流同步：可以用 RTCP 将多个媒体流进行同步，保证音视频的同步播放。

  2. 带宽管理：RTCP 可以监控网络带宽和质量，确保多个媒体流之间的带宽使用均衡，保证整个网络的带宽使用效率。

  3. QoS 保证：RTCP 可以监控 RTP 流的传输质量，包括延迟、丢包、抖动等，通过传递 RTCP 报告信息给应用程序，应用程序可以及时调整传输策略，提高媒体流的质量。

  4. 流控制：RTCP 可以控制媒体流的发送速率，避免网络拥塞和带宽浪费。

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

二、RTCP基本工作原理

  1. RTCP 发送方：在 RTP 会话开始时，RTCP 发送方会周期性地发送 RTCP 报告。RTCP 报告包含有关 RTP 流的统计信息，例如发送方和接收方的 SSRC、延迟、抖动、丢包率等信息。

  2. RTCP 接收方：在接收到 RTP 流时，RTCP 接收方会从 RTP 数据包中提取信息并维护相关的状态信息，用于生成 RTCP 报告。在收到 RTCP 报告后，RTCP 接收方会更新状态信息，并根据需要发送 RTCP 应答报文。

  3. RTCP 控制：RTCP 报告不仅包含有关 RTP 流的统计信息，还包括控制信息，例如建立或终止 RTP 会话、限制发送速率等。发送方可以根据接收到的 RTCP 报告和应答报告调整发送速率，以避免网络拥塞和带宽浪费，同时确保 RTP 流的传输质量。

  4. RTCP 会话控制：RTCP 会话控制协议定义了用于控制 RTCP 的一组协议，例如在 RTP 会话开始和结束时启动和终止 RTCP 报告的机制。

三、RTCP报文解析

3.1 RTCP数据包格式

C++ 复制代码 
 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)
C++ 复制代码 
        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
C++ 复制代码 
        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中主要使用了如下两个报文

报文名称 用途 相关字段及说明 备注
NACK 接收端通知发送方丢包情况 PID：标识从哪个包开始统计丢包；BLP（16 位）：表示从 PID 包开始，接下来 16 个 RTP 包的丢失情况
TFB WebRTC 中 TCC 算法的反馈报文 记录包的延迟情况，交由发送端的 TCC 算法计算下行带宽
3.4.2 PT = 206 表示PSFB

举例，

报文名称 用途 相关字段及说明
PLI 图像丢失指示 在接收端解码器无法解码时发送的报文
SLI 片丢失指示 图像丢失zhi shi

四、总结

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

相关推荐
Amagi.10 分钟前
http连接与ssh连接的区别
网络协议·http·ssh
一只邪恶大泡26 分钟前
TCP与HTTP的关系
网络协议·tcp/ip·http
Nigoridl1 小时前
TCP-IP5层模型
网络·网络协议·tcp/ip
qq_254674412 小时前
ssl 协议工作过程
网络·网络协议·ssl
白总Server2 小时前
SSL认证解说
运维·服务器·网络·网络协议·云原生·kubernetes·ssl
PlumCarefree4 小时前
基于鸿蒙API10的RTSP播放器(三：底部视频滑轨进度显示）
音视频
利哥AI实例探险4 小时前
【图像识别】摄像头捕捉运动到静止视频帧(免费源码分享)
音视频
cuijiecheng20184 小时前
音视频入门基础：AAC专题（2）——使用FFmpeg命令生成AAC裸流文件
ffmpeg·音视频·aac
叶北辰CHINA4 小时前
【TCP三次握手+四次挥手（个人理解版本）】
网络·网络协议·tcp/ip
Q8343158196 小时前
JL6107S 7端口管理型MAC（1*RGMII+1*SGMII）千兆以太网交换机芯片P2P替代RTL8367S
网络·嵌入式硬件·网络协议·硬件工程·信息与通信·p2p
热门推荐
01RAG 实践- Ollama+RagFlow 部署本地知识库022024年高教社杯数学建模国赛C题超详细解题思路分析03【2024数模国赛赛题思路公开】国赛B题思路丨附可运行代码丨无偿自提04组基轨迹建模 GBTM的介绍与实现（Stata 或 R）05【2024高教社杯全国大学生数学建模竞赛】B题 生产过程中的决策问题——解题思路 代码 论文062024 高教社杯 数学建模国赛 （A题）深度剖析|“板凳龙” 闹元宵|数学建模完整代码+建模过程全解全析07yolov8实战第五天——yolov8+ffmpg实时视频流检测并进行实时推流——（推流，保姆教学）082024数学建模国赛高教社杯C题:农作物的种植策略 思路代码文章助攻手把手保姆级092024年高教杯国赛（C题）数学建模竞赛解题思路|完整代码论文集合10Codeforces 969 div2[A~E] 个人题解