WebRTC带宽评估 -- Transport-wide Congestion Control

简述：在RTP包中增加transport-wide-cc扩展头，放置传输层面的包序号。视频接收端记录RTP包的接收时间，并通过RTCP Feedback消息反馈到视频发送端，发送端结合缓存的RTP包发送时间，基于丢包和延迟估算当前带宽，从而及时调整流媒体的发送速率，减少网络拥塞，提高整体视频效果。该方法主要的估算和决策在发送方，采用了线性回归和最小二乘法。

协议：draft-holmer-rmcat-transport-wide-cc-extensions-01

具体实现：

1. SDP

a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

a=rtcp-fb:102 transport-cc

2. RTP

在RTP中都增加一个Transport-wide Sequence number扩展头（扩展头格式参考RFC5285），放置传输层面的包序号，格式如下

在同一个transport中，每发送一个 RTP 包，Transport-wide Sequence number值加1。

3. RTCP

增加一个RTCP Feedback消息，用于receiver向sender反馈RTP包的接收状态（是否收到、收到时间），具体格式如下：

 base sequence number：该RTPC Feeback描述的首个RTP包的transport-wide sequence number.

packet status count: 该RTPC Feeback描述的RTP包的个数。

reference time：该RTPC Feeback描述的首个RTP包的到达时间（单位：64ms)

fb pkt.count : 该RTPC Feeback的计数。

packet chunk：描述RTP包的到达状态（详见下文描述）

recv delta：与上一个RTP包达到的时间的间隔（单位：250us）

Packet Chunk

描述RTP包的到达状态，用2个比特描述，有4种状态:

00   Packet not received

01   Packet received, small delta，此时recv delta取值[0,255],  也就是[0, 63.75] ms

10   Packet received, large or negative delta，此时recv delta取值-32768, 32767],  也就是[-8192.0, 8191.75] ms

11   [Reserved]

按位来表示包的到达状态，packet chunk有两种格式，分别为：

Run Length Chunk

 T：1 bit，表示chunk type，此时为Run Length Chunk，值为0

 S：2 bit, 表示包的到达状态

Run Length：13 bit，表示连续有多少包都是这种状态

所以在接收端看到包的状态都相同，则使用这种格式更节省。

Status Vector Chunk

 T：1 bit，表示chunk type，此时为Status Vector Chunk，值为1

 S：1 bit, 0表示后面symbol list中用1 bit表示1个RTP包的状态（0没收到，1收到），所以1个chunk最多能描述14个RTP包的到达状态；1表示后面symbol list中用2 bit表示1个RTP包的状态（00没收到，01收到小delta，10收到大delta），所以1个chunk最多能描述7个RTP包的到达状态

因为，如果有大的delta的时候，才用S=1.

对比上述两种chunk，1个Status Vector Chunk最多能表示14个包的状态，所以如果有连续>=14包的状态相同，则优先使用Run Length Chunk。一个Run Length Chunk最多能表示2^13 -1 个包的状态。

一个RTCP Feedback中可以混合使用Run Length Chunk和Status Vector Chunk。

一个WebRTC的抓包示例：（使用janus-gateway测试）