Transport-cc指的是Transport-wide Congestion Control。WebRTC最新的拥塞控制算法（Sendside BWE）基于Transport-cc，接收端记录数据包到达时间，构造相关RTCP包，然后反馈给发送端，在发送端做带宽估计，从而进行拥塞控制。之所以基于Transport-cc，放到发送端进行带宽估计，除了方便维护，也增加了相关算法的灵活性，因为大多数处理逻辑都放到了发送端。WebRTC中为了使用Transport-cc，需要用到RTP报头扩展以及增加新的RTCP类型。这里我们介绍下Transport-cc中的RTP以及RTCP。

RTP Header扩展

Transport sequence number

首先我们先来复习下RTP固定报头结构：

图1 - RTP头

可以看到有一个sequence number字段，用于记录RTP包的序列号。一般情况下我们一个传输通道（PeerConnection）只包含一路视频流，这个sequence number能满足大多数需求。但是在一些情况下，我们一个连接可能传输多个视频流，这些视频流复用一个传输通道，例如simulcast或者single PC场景，一个PeerConnection可能包含多个不同的视频流。在这些视频流中，RTP报头的sequence number是单独计数的。

这里举个例子，假设同一个PeerConnection下，我们传输两个视频流A与B，它们的RTP包记为Ra(n)，Rb(n)，n表示sequence number，这样我们观察同一个PeerConnection下，视频流按如下形式传输：
Ra(1),Ra(2),Rb(1),Rb(2),Ra(3),Ra(4),Rb(3),Rb(4)

在对某条PeerConnection进行带宽估计时，我们需要估计整条PeerConnection下所有视频流，而不是单独某个流。这样为了做一个RTP session（传输层）级别的带宽估计，原有各个流的sequence number就不能满足我们需要了。

为此Transport-cc中，使用了RTP报头扩展，用于记录transport sequence number，同一个PeerConnection连接下的所有流的transport sequence number，使用统一的计数器进行计数，方便进行同一个PeerConnection下的带宽估计。

这里我们使用前面的例子，视频流A与B，它们的RTP包记为Ra(n，m)，Rb(n,m)，n表示sequence number，m表示transport sequence number，这样同一个PeerConnection下，视频流按如下形式传输：
Ra(1,1),Ra(2,2),Rb(1,3),Rb(2,4),Ra(3,5),Ra(4,6),Rb(3,7),Rb(4,8)

这样进行带宽估计时，通过transport sequence number我们就能关心到这条传输通道下所有数据包的情况了。

RTP transport sequence number报头定义如下：

图2 -transport sequence number报头

由于属于RTP报头扩展，所以可以看到以0xBEDE固定字段开头，表示One-Byte Header类型的扩展。One-Byte Header相关知识请参考：实时传输协议RTP(一)

transport sequence number占两个字节，存储在One-Byte Header的Extension data字段。由于按4字节对齐，所以还有值为0的填充数据。

对于同一个PeerConnection下的每个包，这个transport sequence number是从1开始递增的。这里我们看下Wireshark中对带transport sequence numberRTP报头扩展的解析：

图3 - wirshark抓包

One-Byte Header中Extension data字段为0x0028，可知该RTP包的transport sequence number为0x0028。

代码导读

WebRTC中，要发送的数据都会经过Pacing模块，用于平滑发送处理，要发送数据会送到pacer thread，在pacer thread中的PacketRouter::SendPacket，对要发送的RTP数据包打上统一计数的TransportSequenceNumber扩展。

图4 - 代码导读

TransportFeedback RTCP

报文格式

Transport-cc中，接收端通过TransportFeedback RTCP向发送端反馈收到的各个RTP包的到达时间信息。首先我们看下TransportFeedback包格式定义：

图5 - TransportFeedback RTCP

base sequence number:2字节，TransportFeedback包中记录的第一个RTP包的transport sequence number，在反馈的各个TransportFeedback RTCP包中，这个字段不一定是递增的，也有可能比之前的RTCP包小。

packet status count:2字节，表示这个TransportFeedback包记录了多少个RTP包信息，这些RTP的transport sequence number与base sequence number为基准。比如记录的第一个RTP包的transport sequence number为base sequence number，那么记录的第二个RTP包transport sequence number为base sequence number+1。

reference time:3字节，表示参考时间，以64ms为单位，RTCP包记录的RTP包到达时间信息以这个reference time为基准进行计算。

feedback packet count:1字节，用于计数发送的每个TransportFeedback包，相当于RTCP包的序列号。可用于检测TransportFeedback包的丢包情况。

packet chunk:2字节，记录RTP包的到达状态，记录的这些RTP包transport sequence number通过base sequence number计算得到。

recv delta: 1字节，对于"packet received"状态的包，也就是收到的RTP包，在recv delta列表中添加对应的的到达时间间隔信息，用于记录RTP包到达时间信息。通过前面的reference time以及recv delta信息，我们就可以得到RTP包到达时间。

packet chunk

首先先了解下RTP包状态，目前定义了如下四种状态，每个状态值2bits，用来标识RTP包的到达状态，以及与前面RTP包的时间间隔大小信息：

1. 00-Packet not received
2. 01-Packet received, small delta
3. 10-Packet received, large or negative delta
4. 11-[Reserved]

packet chunk有两种类型，Run length chunk（行程长度编码数据块）与Status vector chunk（状态矢量编码数据块），对应packet chunk结构的两种编码方式。packet chunk的第一bit标识chunk类型。

①Run length chunk（行程长度）编码：一种简单的数据压缩算法，其基本思想是将重复且连续出现多次的字符使用“连续出现次数+字符”来描述，例如：aaabbbcdddd通过Run length编码就可以压缩为3a3bc4d。Run length chunk中就使用了Run length编码标识连续多个相同状态的包。

Run length chunk第一bit为0，后面跟着packet status以及run length。格式如下：

图6 - packet chunk

chunk type (T):1 bit，值为0。
packet status symbol (S):2 bits，标识包状态。
run length (L):13 bits，行程长度，标识有多少个连续包为相同状态。

图7 - 举例

packet status为00，由前面包状态可知为"Packet not received"状态，run lengh为221（11011101），说明连续有221个包为"Packet not received"状态。

②Status Vector Chunk 第一bit为1，后面跟着symbol size以及symbol list。格式如下：

图8 - Status Vector Chunk

1. chunk type (T):1 bit，值为1。
2. symbol size(S):1 bit，为0表示只包含"packet not received" (0)以及"packet received"（1）状态，每个状态使用1bit表示，这样后面14bits的symbol list能标识14个包的状态。为1表示使用2bits来标识包状态，这样symbol list中我们只能标识7个包的状态。
3. symbol list:14 bits，标识一系列包的状态, 总共能标识7或14个包的状态。

图9 - 举例

symbol size为0，这样能标识14个包的状态。第一个包状态为"packet not received"（0），接着后面5个包状态为"packet received"（1），再接着三个包状态为"packet not received"，再接着三个包状态为"packet received"，最后两个包状态为"packet not received"。

图10 - 举例

symbol size为1，这样只能标识7个包的状态。第一个包为"packet not received"（00）状态，第二个包为 "packet received, w/o timestamp"（11）状态，再接着三个包为"packet received"（01）状态，最后两个包为"packet not received"（00）状态。

Receive Delta

以250us(0.25ms)为单位，表示RTP包到达时间与前面一个RTP包到达时间的间隔，对于记录的第一个RTP包，该包的时间间隔是相对reference time的。

如果在packet chunk记录了一个"Packet received, small delta"状态的包，那么就会在receive delta列表中添加一个无符号1字节长度receive delta，无符号1字节取值范围[0,255]，由于Receive Delta以0.25ms为单位，故此时Receive Delta取值范围[0, 63.75]ms。

如果在packet chunk记录了一个"Packet received, large or negative delta"状态的包，那么就会在receive delta列表中添加一个有符号2字节长度的receive delta，范围[-8192.0, 8191.75] ms。如果时间间隔超过了最大限制，那么就会构建一个新的TransportFeedback RTCP包，由于reference time长度为3字节，所以目前的包中3字节长度能够覆盖很大范围了。

总结起来就是：对于收到的RTP包在TransportFeedback RTCP receive delta列表中通过时间间隔记录到达时间，如果与前面包时间间隔小，那么使用1字节表示，否则2字节，超过最大取值范围，就另起新RTCP包了。

对于"Packet received, small delta"状态的包来说，receive delta最大值63.75ms，那么一秒时间跨度最少能标识1000/63.75~=16个包。由于receive delta为250us的倍数，所以一秒时间跨度最多能标识4000个包。

packet chunk以及receive delta的使用是为了尽可能减小RTCP包大小。packet chunk用到了不同编码方式，对于收到的RTP包才添加到达时间信息，而且是通过时间间隔的方式记录到达时间。

代码导读

在RemoteEstimatorProxy中处理RTP包的到达时间，构造Transport-cc报文，反馈给发送端。大概函数调用流程如下：

RemoteEstimatorProxy::IncomingPacket↓

RemoteEstimatorProxy::Process↓

RemoteEstimatorProxy::SendPeriodicFeedbacks↓

RemoteEstimatorProxy::BuildFeedbackPacket

RemoteEstimatorProxy::IncomingPacket中，如果RTP包带有TransportSequenceNumber扩展，会记录该RTP包的到达时间，然后添加到构造的Transport-cc报文中。我们看下主要处理的代码：

图11 - 代码导读

在RTCPReceiver中处理收到的Transport-cc报文，然后送给TransportFeedbackObserver处理。大概函数调用流程如下：

RTCPReceiver::IncomingPacket↓

RTCPReceiver::TriggerCallbacksFromRtcpPacket↓

TransportFeedbackObserver::OnTransportFeedback

在webrtc::rtcp::TransportFeedback中负责TransportFeedback包的解析以及构造。

总结

熟悉上面这些有助于更好理解WebRTC中的带宽估计机制。