简述：在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测试）
