WebRTC RTCP 解析
2020-05-18 本文已影响0人
满衣兄
可将RCTP报文分为以下几个部分：
| 序号 | 名称 | 比特位 | 必选 | 说明 |
|---|---|---|---|---|
| 1 | 固定报头 | 4*8 | 是 | 包括标志位：V、P、RC、PT、length。 |
| 2 | 负载数据 | len*8 | 否 | 其中 len >= 0。 |
| 3 | 填充数据 | len*8 | 否 | 其中 len >= 0，自定义数据。 |
固定报头
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 序号 | 标记 | 比特位 | 名称 | 说明 |
|---|---|---|---|---|
| 1 | V | 2 | 版本号 | 目前版本值固定为2 。 |
| 2 | P | 1 | 填充标志 | 若值为1，则在报文尾部填充 若干大于零的额外字节。 |
| 3 | RC | 5 | ReportBlock 计数 | ReportBlock的个数。 |
| 4 | PT | 8 | 负载类型 | SR:200，RR:201，SDES:202， BYE:203，APP:204，RTPFB:205，PSFB:206。 |
| 5 | length | 16 | 负载长度。 | 负载真实长度=4*length。 |
- 固定报头大小为4字节，所以一帧合法的RTCP报文最少包含4个字节的数据。
负载数据
| 序号 | 标记 | 名称 | 值 | 说明 |
|---|---|---|---|---|
| 1 | SR | Sender Report | 200 | 发送端通过发送SR包告诉接收端发送端的信息 。 |
| 2 | RR | Receiver Report | 201 | 接收端通过RR包反馈接收端的接收情况 。 |
| 3 | SDES | Source Description | 202 | 发送源信息描述 。 |
| 4 | BYE | Bye | 203 | 发送端主动停止发送。 |
| 5 | APP | Application | 204 | 用户信息描述 。 |
| 6 | RTPFB | Transport layer FB messages | 205 | 丢包重传、拥塞检测 。 |
| 7 | PSFB | Payload-specific FB messages | 206 | 请求关键帧、码率估算 。 |
SR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- SR分为两部分：发送者信息SenderInfo和反馈块ReportBlock。
- 若发送端也作为接收端，则存在ReportBlock。
- 若存在多个码流，则反馈多个ReportBlock。
- ReportBlock最大个数为31。
SenderInfo
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | 同步信源(SSRC)标识符 | 4*8 | 随机生成的字符串，标记一路数据来源。 |
| 2 | NTP timestamp, most significant word | 4*8 | 单位是秒，64位NTP的第一部分。 |
| 3 | NTP timestamp, least significant word | 4*8 | 单位是分，64位NTP的第二部分。 |
| 4 | RTP timestamp | 4*8 | 时间戳。 |
| 5 | sender’s packet count | 4*8 | 到发送此SR包时已经发送包的个数。 |
| 6 | sender’s octet count | 4*8 | 到发送此SR包时已经发送包的大小(Byte)。 |
ReportBlock
- 参考下面RR包定义
RR（Receiver Report RTCP Packet）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | 同步信源(SSRC)标识符 | 4*8 | 随机生成的字符串，标记一路数据来源。 |
| 2 | fraction lost | 8 | 丢包率，到发送此ReportBlock时丢包率计算。 |
| 3 | cumulative number of packets lost | 3*8 | 报文丢失累积总数。 |
| 4 | extended highest sequence number received | 4*8 | 收到的包序号，前16位表示第几圈，后16位表示当前的序号。 |
| 5 | interarrival jitter | 4*8 | 包之间的平均间隔。 |
| 6 | Last SR | 4*8 | 上一个SR包的时间戳。 |
| 6 | Delay since last SR | 4*8 | 距离上一个LSR的时间间隔。 |
- Loss fraction 计算：loss fraction=lost rate x 256。例：丢包率为25%，该字段为25%*256=64。
- Last SR：SR报文里64位NTP时间戳中的32位bit的时间戳。如果没有收到SR报文，该字段为0。
- DLSR:：接收到SR报文的时刻与发送该RR报文时刻的时间差值，单位时间是1/65536 seconds. 如果没有收到SR报文，该字段为0.
- RTT: Round-Trip Time，发送者计算的发送来回时间。
发送者可以通过RR报文中的LSR和DLSR来计算RTT。
第一步：发送者用接收到RR报文的当前时间-RR报文的LSR，得到发送SR和接收到RR所花费的网络延时。
第二步： (接收到RR报文的当前时间-RR报文的LSR) - RR中的DLSR，也就是去除了在RTP接收者方本地的SR接收和RR发送的延时，这样就得到了RTT。
即：RTT = 接收到RR报文的当前时间-RR报文的LSR - RR中的DLSR。
SDES
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | 块名 | 8 | 块名：CNAME、NAME、EMAIL、PHONE、LOC、TOOL、NOTE、PRIV。 |
| 2 | length | 8 | 用于表示后面描述信息的长度。 |
| 1 | 描述信息 | length*8 | 描述信息。 |
- 发送源信息描述，可以用于描述发送端的名字、邮箱、电话等信息。
- chunk内需要包含一个SSRC和至少一个SEDS item，每个item用于描述不同的信息。
// SDES items
// Canonical End-Point Identifier SDES Item (CNAME)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 序号 | 名称 | 类型 | 比特位 | 说明 |
|---|---|---|---|---|
| 1 | CNAME | 1 | 2 * 8+length*8 | 规范点标识符。 |
| 2 | NAME | 2 | 2 * 8+length*8 | 用户名字。 |
| 3 | 3 | 2 * 8+length*8 | 邮箱。 | |
| 4 | PHONE | 4 | 2 * 8+length*8 | 电话号码。 |
| 5 | LOC | 5 | 2 * 8+length*8 | 用户位置信息(geographic location of site)。 |
| 6 | TOOL | 6 | 2 * 8+length*8 | 应用程序或者工具名字。 |
| 7 | NOTE | 7 | 2 * 8+length*8 | 用户状态的信息。 |
| 8 | PRIV | 8 | 2 * 8+length*8 | 私有扩展信息。 |
BYE（Goodbye RTCP Packet）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 发送端主动停止发送，最后会发送一个BYE包，有可能会说明离开信息（reason for leaving）
APP（Application-Defined RTCP Packet）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 用于描述用户信息的，这个包在WebRTC中并没有看到发送。
RTPFB（Transport layer FB messages）[NACK/TransportFeedback]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
- SSRC of packet sender：发送者的SSRC。
- SSRC of media source：反馈者的SSRC。
NACK
// Generic NACK (RFC 4585).
//
// FCI:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | PID | 16 | Packet ID，第一个丢失的序号。 |
| 2 | BLP | 16 | bitmask of following lost packets， 继第一个序号之后的16个包的丢失情况。 |
- 若FMT为1，别表示NACK请求。
- 用于反馈接接收端未收到什么包。
- BLP：若丢包，则此二进制位就会被置为1。例如PID等于666，如果668和692也丢失了，那么BLP等于100010。当后续丢失的包序号大于第一个丢失的包序号16以上就需要重新使用一个新的FCI反馈包表示。
- NACK包可以存在多个FCI。
TransportSequenceNumber
在理解TransportFeedback之前需要先了解TransportSequenceNumber概念。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=3 |transport-wide sequence number |T| seq count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|seq count cont.|
+-+-+-+-+-+-+-+-+
- TransportSequenceNumber属于RTP协议中的扩展报头部分，关于扩展报头描述可参考WebRTC RTP 解析。
- 在WebRTC中，若一个连接同时存在多路视频流数据源，则每路视频流的序列号在各自时间轴上分别单调递增；而进行带宽估计时计算的是整个链路的情况，所以在进入平滑发送模块（pacing\packet_router.cc）后，会重新打上全局序列号，多路视频流在同一个时间轴上序列号单调递增，这个序列号称之为TransportSequenceNumber。
TransportFeedback
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=15 | PT=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base sequence number | packet status count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reference time | fb pkt. count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet chunk | packet chunk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet chunk | recv delta | recv delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| recv delta | recv delta | zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | base sequence number | 16 | 第一个RTP包的transport sequence number。 |
| 2 | packet status count | 16 | 这个TransportFeedback包记录了多少个RTP包信息。 |
| 3 | reference time | 24 | 以64ms为单位，RTCP包记录的RTP包到达 时间信息以这个reference time为基准进行计算。 |
| 4 | feedback packet count | 8 | 计数发送的每个TransportFeedback包， 相当于RTCP包的序列号。 可用于检测TransportFeedback包的丢包情况。 |
| 5 | packet chunk | 16 | 记录RTP包的到达状态，记录的这些RTP包 transport sequence number通过base sequence number计算得到。 |
| 6 | recv delta | 8 | 对于"packet received"状态的包，也就是收到的RTP包， 在recv delta列表中添加对应的的到达时间间隔信息， 用于记录RTP包到达时间信息。通过前面的reference time 以及recv delta信息，我们就可以得到RTP包到达时间。 |
- 若FMT为15，则启用TransportFeedback。
- TransportFeedback是WebRTC自定义的，用于反馈接收端收到的包和间隔，这些信息是给发送端用于拥塞检测。
- packet status count：表示这个TransportFeedback包记录了多少个RTP包信息，这些RTP的transport sequence number以base sequence number为基准，比如记录的第一个RTP包的transport sequence number为base sequence number，那么记录的第二个RTP包transport sequence number为base sequence number+1。
PSFB（Payload-specific FB messages）[PLI/FIR/REMB]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
PLI
- 若FMT为1，则表示PLI请求。
- 向发送方请求关键帧。
FIR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | SSRC | 32 | 指定的媒体源SSRC。 |
| 2 | Seq nr | 8 | 序列号，标记第几次FIR请求。 |
| 3 | Reserved | 24 | 保留字段。 |
- 若FMT为4，则表示FIR请求。
- 向发送方请求关键帧。
- 和PLI不同，它会指明向那个SSRC请求关键帧，并且是第几次请求。当发送端存在多个视频发送源的时候，接收端就需要指明向哪个源请求关键帧。
REMB
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=15 | PT=206 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Unused = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Unique identifier 'R' 'E' 'M' 'B' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Num SSRC | BR Exp | BR Mantissa |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | SSRC feedback |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...
| 序号 | 名称 | 比特位 | 说明 |
|---|---|---|---|
| 1 | SSRC | 32 | 发送者SSRC。 |
| 2 | Unused | 32 | 未使用字段。 |
| 3 | Unique identifier | 32 | 标识符，必定是0x52454D42（'R' 'E' 'M' 'B'）。 |
| 4 | Num SSRC | 8 | SSRC的个数。 |
| 5 | BR Exp | 8 | 带宽的指数次幂。 |
| 5 | BR Mantissa | 16 | 带宽的底数。 |
- 若FMT为15，则表示REMB请求。
- 向发送方发送接收端估算的最大带宽。
- 带宽用一个uint64_t类型表示，但是传输的时候需要把64位封装到24位里面，WebRTC的做法是当码率大于18位能表示最大数0x3FFF时，用指数表示带宽。
填充数据
- 填充数据主要为了4字节对齐，全为0即可。关于填充数据说明可参考WebRTC RTP 解析。
参考资料
- RFC3550，SR/RR/BYE/APP/SDES
- RFC4585，RTPFB/PSFB
- draft-holmer-rmcat-transport-wide-cc-extensions-01，RTPFB扩展TransportFeedback
- WebRTC之RTCP
- WebRTC研究：Transport-cc之RTP及RTCP
