流媒体协议之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

相关推荐
Estar.Lee32 分钟前
查手机号归属地免费API接口教程
android·网络·后端·网络协议·tcp/ip·oneapi
LNTON羚通1 小时前
摄像机视频分析软件下载LiteAIServer视频智能分析平台玩手机打电话检测算法技术的实现
算法·目标检测·音视频·监控·视频监控
傻啦嘿哟1 小时前
代理IP在后端开发中的应用与后端工程师的角色
网络·网络协议·tcp/ip
向阳12182 小时前
Dubbo HTTP接入之triple协议
网络协议·http·dubbo
Estar.Lee4 小时前
时间操作[计算时间差]免费API接口教程
android·网络·后端·网络协议·tcp/ip
小屁孩大帅-杨一凡5 小时前
Python-flet实现个人视频播放器
开发语言·python·音视频
EasyCVR8 小时前
私有化部署视频平台EasyCVR宇视设备视频平台如何构建视频联网平台及升级视频转码业务？
大数据·网络·音视频·h.265
天空中的野鸟8 小时前
Android音频采集
android·音视频
hgdlip8 小时前
主IP地址与从IP地址：深入解析与应用探讨
网络·网络协议·tcp/ip
计算机毕设孵化场9 小时前
计算机毕设-基于springboot的高校网上缴费综合务系统视频的设计与实现（附源码+lw+ppt+开题报告）
java·spring boot·计算机外设·音视频·课程设计·高校网上缴费综合务系统视频·计算机毕设ppt
热门推荐
01ICLR24大模型提示(1/11) | BadChain：大型语言模型的后门思维链提示02PyTorch机器学习实现液态神经网络03【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总04【音视频 | opus】opus编解码库(opus-1.4)详细介绍以及使用——附带解码示例代码05Coze扣子平台完整体验和实践（附国内和国际版对比）06(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明07IT专业入门，高考假期预习指南08玄机平台应急响应—webshell查杀09RAG 实践- Ollama+RagFlow 部署本地知识库10〔AI 绘画〕Stable Diffusion 之 解决绘制多人或面部很小的人物时面部崩坏问题 篇