从WebRtc学习RTCP协议

文章目录

- RTCP支持的消息类型
- RTCP协议头
- WebRTC的反馈报文
- - RTPFB支持的报文类型：
  - PSFB支持的报文类型：
参考

RTCP是RTP的控制协议.
那么RTCP能对RTP做哪些控制呢？其中最为大家熟知的就是 丢包控制。
发送端发送数据后，接收端如果发现有RTP包丢失了，可以使用RTCP的 NACK报文通知发送方，告诉对方具体是哪些包丢失了，然后让发送方重发前面丢失的包。
此外，接收端还可以使用RTCP的 RR报文向发送端发送接收报告，报告中记录着从上一次报告到本次报告之间丢失了多少包、丢包率是多少、延时是多少等一系列信息。
同理，发送端也可以向接收端发送 SR报文，报告一段时间内一共发送了多少包等。
RTCP支持的消息非常多，在此我们将一些最常见的RTCP报文消息整理了出来.
SR和RR报文。这两个报文在WebRTC中至关重要，因为网络质量评估与控制需要的大量参数都是从这两个报文中获得的。
下面介绍一下RTCP支持的其他的消息类型：

RTCP支持的消息类型

在这里插入图片描述
SDES报文是用来描述（音视频）媒体源的。它可以描述的内容包括媒体源的名称、Email地址，电话等。但实际上，这些描述项都没太大价值。唯一有价值的是CNAME项，其作用是将不同的源（SSRC）绑定到同一个CNAME上。举个例子，当SSRC有冲突时，可以通过CNAME将旧的SSRC更换成新的SSRC，从而保证在通信的每个SSRC都是唯一的。
BYE报文用于说明哪些（音视频）媒体源现在不可用了。当WebRTC收到该报文后，应该将SSRC所对应的通道删除。
APP报文是给应用预留的RTCP报文，应用可以根据自己的需要自定义一些应用层可以解析的报文。
RTPFB报文，即RTP的反馈报文，是指RTP传输层面的报文。该报文可以装入不同类型的子报文。
与RTPFB对应的是PSFB，即RTP中与负载相关的反馈报文。同样，该报文也可以装入不同类型的子报文。

RTCP协议头

RTCP协议头如下：
在这里插入图片描述

Version即协议版本，固定值为2。P字段为填充位标识。PT字段即Payload Type，与RTP中的PT字段类似。
RTCP中的Count字段是RTP中所没有的，该值针对RTCP中不同的报文有不同的含义：
对于RR/SR报文而言，Count表示它们所携带的接收报告的个数；
对SDES报文而言，Count表示SDES报文中item的个数；
对于BYE报文而言，Count表示BYE报文中SSRC/CSRC的个数；
而对于APP报文来说变化就比较大了，Count用于标识应用自定义的子消息类型。
Length字段表示整个RTCP包的大小，包括RTCP头、RTCP负载以及填充字节。需要注意的是，Length字段是以4字节为单位的，即（N−1）个4字节。

WebRTC的反馈报文

已知PT为205和206的报文类型属于反馈报文。报文中可以包含多个子报文，其中WebRTC使用到的报文只有某几项。

RTPFB支持的报文类型：

在这里插入图片描述
第一项NACK，用于通知发送方在上次包发送周期内有哪些包丢失了：
NACK报文中包含两个字段：PID和BLP。PID（Package ID）字段用于标识从哪个包开始统计丢包；
而BLP（16位）字段表示从PID包开始，接下来的16个RTP包的丢失情况。（BLP（Bitmask of Following Lost Packet），从丢失包开始的位掩码）
第二项TMMBR和第三项TMMBN是一对报文，TMMBR表示临时最大码流请求报文，TMMBN是对临时最大码流请求的应答报文。这两个报文虽然在WebRTC中实现了，但已被WebRTC废弃，其功能由TFB和REMB报文所代替。
第四项TFB是WebRTC中TCC[插图]算法的反馈报文，该报文会记录包的延迟情况，然后交由发送端的TCC算法计算下行带宽。(TCC（Transport-wide Congestion Control），基于发送端的带宽评估算法)

PSFB支持的报文类型：

在这里插入图片描述
PSFB报文包括PLI报文、FIR报文以及REMB报文。
其中PLI报文与FIR报文很类似，当发送端收到这两个报文时，都会触发生成关键帧（IDR帧）。
PLI报文是在接收端解码器无法解码时发送的报文。
FIR报文主要应用于多方通信时后加入房间的参与者向已加入房间的共享者申请关键帧。通过这种方式，可以保障后加入房间的参与者不会因收到的第一帧不是关键帧而引起花屏或黑屏的问题。
REMB报文是WebRTC增加的反馈报文，用于将接收端评估出的带宽值发给发送端。不过，由于最新的WebRTC已全面启用基于发送端的带宽估算方法，即TCC，因此目前REMB仅用于向后兼容，不再做进一步更新。