RTCP

除了RTP外,在RTP协议簇中还包括RTCP,其与RTP处于同一层级。RTCP是RTP的控制协议,那么RTCP能对RTP做哪些控制呢?其中最为大家熟知的就是丢包控制。发送端发送数据后,接收端如果发现有RTP包丢失了,可以使用RTCP的NACK报文通知发送方,告诉对方具体是哪些包丢失了,然后让发送方重发前面丢失的包。此外,接收端还可以使用RTCP的RR报文向发送端发送接收报告,报告中记录着从上一次报告到本次报告之间丢失了多少包、丢包率是多少、延时是多少等一系列信息。同理,发送端也可以向接收端发送SR报文,报告一段时间内一共发送了多少包等。

RTCP报文分类

RTCP 支持的消息非常多,在此我们将一些最常见的 RTCP 报文消息整理了出来,同时它们也是 WebRTC 中正在使用的报文。如表 9.1 所示。

下面按表 9.1 中的顺序来看一下每个报文的作用。

SR 和 RR 报文。这两个报文前面已经做了简要介绍,一个是发送信息报文,另一个是接收信息报文。这两个报文在 WebRTC 中至关重要,如果要对 WebRTC 的网络质量做深入研究的话,一定要仔细研究一下这两个报文,因为网络质量评估与控制需要的大量参数都是从这两个报文中获得的。

image 2025 02 23 17 39 51 732
Figure 1. 表9.1 RTCP支持的消息类型

SDES 报文是用来描述(音视频)媒体源的。它可以描述的内容包括媒体源的名称、Email地址,电话等。但实际上,这些描述项都没太大价值。唯一有价值的是CNAME项,其作用是将不同的源(SSRC)绑定到同一个CNAME上。举个例子,当SSRC有冲突时,可以通过CNAME将旧的SSRC更换成新的SSRC,从而保证在通信的每个SSRC都是唯一的。这里介绍的CNAME与7.3.3节中介绍的CNAME是同一个。

BYE报文用于说明哪些(音视频)媒体源现在不可用了。当WebRTC收到该报文后,应该将SSRC所对应的通道删除。

APP报文是给应用预留的RTCP报文,应用可以根据自己的需要自定义一些应用层可以解析的报文。RTPFB报文,即RTP的反馈报文,是指RTP传输层面的报文。该报文可以装入不同类型的子报文。

与RTPFB对应的是PSFB,即RTP中与负载相关的反馈报文。同样,该报文也可以装入不同类型的子报文。

RTCP协议头

RTCP 协议头的格式与 RTP 协议头格式相比要简单不少,而且有些字段还很类似,如图 9.15 所示。

其中,Version字段、P(Padding)字段以及Type字段的含义与RTP中对应字段的含义是一样的。Version即协议版本,固定值为2。P字段为填充位标识。PT字段即Payload Type,与RTP中的PT字段类似,但两者中存放的内容有很大不同。RTP中的PT值是在SDP中定义的,而RTCP的PT值来自表9.1。

image 2025 02 23 17 40 55 578
Figure 2. 图9.15 RTCP协议头

此外,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字节。

Data里存放的内容与PT息息相关,不同类型的RTCP报文其Data内容千差万别,对于这些内容本书就不做详细讲解了,有兴趣的读者可以自行查阅RFC3550。

WebRTC的反馈报文

在9.3.1节中介绍了多种RTCP报文类型,其中PT为205和206的报文类型属于反馈报文。PT=205表示RTPFB报文,用于反馈RTP相关的信息;PT=206表示PSFB报文,用于反馈RTP负载相关的信息。

首先看一下RTPFB报文,如表9.2所示。该报文中可以包含多个子报文,其中We bRTC使用到的报文只有表中列出的4项。第一项NACK,用于通知发送方在上次包发送周期内有哪些包丢失了。它是如何通知发送端有哪些包丢失了呢?在NACK报文中包含两个字段:PID和BLP。PID(Package ID)字段用于标识从哪个包开始统计丢包;而BLP(16位)字段表示从PID包开始,接下来的16个RTP包的丢失情况。第二项TMMBR和第三项TMMBN是一对报文,TMMBR表示临时最大码流请求报文,TMMBN是对临时最大码流请求的应答报文。这两个报文虽然在WebRTC中实现了,但已被WebRTC废弃,其功能由TFB和REMB报文所代替。第四项TFB是WebRTC中TCC算法的反馈报文,该报文会记录包的延迟情况,然后交由发送端的TCC算法计算下行带宽。

image 2025 02 23 17 41 36 946
Figure 3. 表9.2 RTPFB支持的报文类型

接下来看一下 PSFB 类型的报文中都包含哪些子报文,以及这些子报文的含义。如表 9.3 所示。

image 2025 02 23 17 42 05 174
Figure 4. 表9.3 RTPFB支持的报文类型

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