【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展
作者：互联网
【网络通信 -- 直播】网络通信协议简介 -- RTCP 协议的 WebRTC 扩展
【1】RTCP 的头部格式
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 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 字段 | 长度 | 说明 |
| 版本(V) | 2 位 | 当前版本号 |
| 填充位(P) | 1 位 | 指明分组末端是否存在填充字节 |
| 接收报告数(RC) | 5 位 | 指明分组所包含的接收者报告块的数量 |
| 净荷类型(PT) | 8 位 | 指明净荷类型 |
| 长度 | 16 位 | 指明分组的长度 |
【2】SR/RR/BYE/APP/SDES 分组
参考博客，【网络通信 -- 直播】网络通信协议简介 -- RTP/RTCP
【3】WebRTC 相关的 RTCP 分组
WebRTC 相关的 RTCP 分组总结如下
RTCP 反馈信息的一般格式如下
| 字段 | 长度 | 说明 |
| 版本(V) | 2 位 | 当前版本号 |
| 填充位(P) | 1 位 | 指明分组末端是否存在填充字节 |
| 反馈信息类型(FMT) | 5 位 | 指明反馈信息的类型 |
| 净荷类型(PT) | 8 位 | 指明净荷类型 |
| 长度 | 16 位 | 指明分组长度 |
【3.1】RTPFB (Transport layer FB messages，传输层反馈信息)
- NACK (negative acknowledgement)，未确认、丢包请求
P = RTPFB (205)，FMT = 1，用于反馈接受端未收到的一个或多个 RTP 数据包
| 字段 | 长度 | 说明 |
| PID | 16 位 | 第一个丢失的 RTP 数据包的序列号 |
| BLP | 16 位 | 继第一个序号之后的 16 个包的丢失情况，若丢失则此二进制位就会被 mark 为 1 |
当后续丢失的包序号大于第一个丢失的包序号 16 以上就需要重新使用一个新的 FCI 反馈包表示，NACK 包可以存在多个 FCI；
- TMMBR (Temporary Maximum Media Stream Bit Rate Request)，临时最大媒体码流请求
P = RTPFB (205)，FMT = 3，用于流控，请求发送端按指定的最大比特率传输数据流，通常用于网络抖动情况下保证 VOIP 通信的流畅性 (临时降低质量)
| 字段 | 长度 | 说明 |
| SSRC | 32 位 | 被请求遵循新的最大比特率的媒体发送器的 SSRC 值 |
| MxTBR ExP | 6 位 | 指数 |
| MxTBR Mantissa | 17 位 | 系数 |
| Measured Overhead | 9 位 | 测量的平均开销 |
最大比特率 = 系数 * 2 ^ 指数，MxTBR = mantissa * 2 ^ exp；
- TMMBN (Temporary Maximum Media Stream Bit Rate Notification)，临时最大媒体码流通知
P = RTPFB (205)，FMT = 4，此反馈消息用于通知任何 TMMBR 消息的发送者已收到一个或多个TMMBR 消息，或者所有者已离开会话
| 字段 | 长度 | 说明 |
| SSRC | 32 位 | 该 "元组" 所有者的 SSRC 值 |
| MxTBR ExP | 6 位 | 指数 |
| MxTBR Mantissa | 17 位 | 系数 |
| Measured Overhead | 9 位 | 测量的平均开销 |
- TW (Transport-wide RTCP Feedback Message)，传输带宽反馈信息
P = RTPFB (205)，FMT = 15，用于反馈接收端收到的包和间隔
| 字段 | 长度 | 说明 |
| 版本(V) | 2 位 | 当前版本号 |
| 填充(P) | 1 位 | 指明分组末端是否存在填充字节 |
| 反馈信息类型(FMT) | 5 位 | 指明反馈信息的类型 |
| 净荷类型(PT) | 8 位 | 指明净荷类型 |
| 长度 | 16 位 | 指明分组长度 |
| SSRC of packet sender | 32 位 | 数据包发送者的 SSRC 值 |
| SSRC of media source | 32 位 | 媒体源的 SSRC 值 |
| base sequence number | 16 位 | 反馈中第一个数据包的序列号 |
| packet status count | 16 位 | 反馈中数据包的数量 |
| reference time | 24 位 | 有符号整数，表示反馈包的发送方选择的某个时基中的绝对参考时间 |
| fb pkt. count | 8 位 | 对于发送的每个反馈数据包，计数器递增一 |
| packet chunk | 16 位 | 数据包状态块列表 |
| recv delta | 8 位 |
数据包的状态标识
| 状态值 | 说明 |
| 00 | 未收到数据包 |
| 01 | 收到数据包，小延迟，small delta |
| 10 | 收到数据包，大延迟，large or negative delta |
| 11 | 保留状态 |
packet chunk
run length chunk
| 字段 | 长度 | 说明 |
| T | 1 位 | 取值 0，表示 run length chunk |
| S | 2 位 | 数据包的状态标识 |
| Run Length | 13 位 | 表示长度的无符号整数 |
status vector chunk
| 字段 | 长度 | 说明 |
| T | 1 位 | 取值 1，表示 status vector chunk |
| S | 1 位 | 取值 0，表示该 vector 仅包含 "收到数据包 (0)" 以及 "未收到数据包 (1)" 取值 1，表示该 vector 使用 2 位标识状态 |
| symbol list | 14 位 | 状态列表 |
Receive Delta
Delta 用 250 us 的倍数标识
- "Packet received，small delta"，8 位无符号数标识 delta
- "Packet received，large or negative delta"，16 位有符号数标识 delta
- "delta 超过最大限制"，追加一个新的反馈信息，24 位数标识 delta
【3.2】PSFB (Payload-specific FB messages，有效载荷反馈信息)
- PLI (Picture Loss Indication)，图像丢失指示
P = PSFB (206)，FMT = 1，用于解码器通知编码器属于一个或多个图片的未定义量的编码视频数据的丢失，FCI 域只包含一个 PLI 信息；在发生丢包或解码错误时，请求对端发送关键帧；
PLI 无需参数，无需任何反馈控制信息；
- SLI (Slice Loss Indication)，片丢失指示
P = PSFB (206)，FMT = 2，用于解码器通知编码器，按扫描顺序已检测到一个或多个连续宏块丢失或损坏，FCI 域可以包含一个或多个 SLI 信息 (至少一个)；
| 字段 | 长度 | 说明 |
| First | 13 位 | 第一个丢失宏块的地址 |
| Number | 13 位 | 丢失宏块的数量 |
| PictureID | 6 位 | 编解码器特定标识符的六个最低有效位，用于指示宏块丢失的图片 |
- RPSI (Reference Picture Selection Indication)，参考图像选择指示
P = PSFB (206)，FMT = 3，在发生丢包或解码错误时，请求对端发送关键帧；
| 字段 | 长度 | 说明 |
| PB | 8 位 | 填充位的位数 |
| 0 | 1 位 | 传输时必须设置为 0 接收时忽略 |
| Payload Type | 7 位 | Native RPSI bit string 表示的载荷类型 |
| Native RPSI bit string | 可变长度 | 本端视频编解码器定义的 RPSI 信息 |
| Padding | 填充位 |
- FIR (Full Intra Request Command)，完整帧请求
P = PSFB (206)，FMT = 4，用于一个中心化的 Video Conference 中，新的参与者加入，就需要发送一个 FIR，通知其他的参与者发送一个关键帧，从而实现解码；
| 字段 | 长度 | 说明 |
| SSRC | 32 位 | 被请求发送解码器刷新点的媒体发送器的 SSRC 值 |
| Seq nr. | 8 位 | 命令序列号 |
- TSTR (Temporal-Spatial Trade-off Request)，时空交换请求
P = PSFB (206)，FMT = 5，解码器可以通过向编码器发送 TSTR 消息来建议时间 - 空间权衡水平；
| 字段 | 长度 | 说明 |
| SSRC | 32 位 | 被请求应用索引中给定的折衷值的媒体发送方的 SSRC 值 |
| Seq nr. | 8 位 | 请求序列号，每一个新的命令该序列号加一 |
| Reserved | 19 位 | 保留位 |
| Index | 5 位 | 指示请求的相对折衷值 |
- TSTN (Temporal-Spatial Trade-off Notification)，时空交换响应
P = PSFB (206)，FMT = 6，此反馈消息用于确认 TSTR 的接收；
| 字段 | 长度 | 说明 |
| SSRC | 32 位 | 导致此通知的 TSTR 来源的 SSRC |
| Seq nr. | 8 位 | 请求序列号，从 TSTR 消息中获取 |
| Reserved | 19 位 | 保留位 |
| Index | 5 位 | 媒体发送者将会使用的折衷值 |
- VBCM (Video Back Channel Message)，
P = PSFB (206)，FMT = 7，
| 字段 | 长度 | 说明 |
| SSRC | 32 位 | 被请求指示其编码器对 VBCM 作出反应的媒体发送器的 SSRC 值 |
| Seq nr. | 8 位 | 命令序列号，每一个新的命令该序列号加一 |
| 0 | 1 位 | 默认为 0，接收端忽略 |
| Payload Type | 7 位 | VBCM 比特流必须理解的 RTP 载荷类型 |
| Length | 16 位 | VBCM 八位字节字符串的长度，以八位字节为单位，不包括任何填充八位字节 |
| VBCM Octet String | 可变长度 | 带特定反馈子消息的由解码器生成的八位字节字符串 |
| Padding | 填充位 |
参考致谢
本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。
【1】WebRTC之RTCP
【3】rtcp 关键帧请求总结
标签：网络通信,SSRC,段长度,--,FMT,反馈,RTCP,数据包 来源： https://blog.csdn.net/qq_27788177/article/details/119032657