可将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