RTCP协议与实战
在音视频通话中，我们常常使用 RTP 协议包承载音视频负载数据，使用 RTCP 协议包反馈当前传输统计数据，控制传输特性以保证提供较高的服务质量，本文将介绍 RTCP 协议以及 RTCP 常用报文的应用。
目录
SDES 报文协议格式（Source Description）
APP 报文协议格式（Application-Defined）
一. 前言
在音视频通话中，我们常常使用 RTP 协议包承载音视频负载数据，使用 RTCP 协议包反馈当前传输统计数据，控制传输特性以保证提供较高的服务质量，本文将介绍 RTCP 协议以及 RTCP 常用报文的应用。
二. RTCP协议报文
RTCP（Realtime Transport Control Protocol）称为传输控制报文协议，它是基于 UDP 协议之上的应用协议。在网络中传输 RTP 数据难免存在丢包，乱序等问题，当网络链路质量变差时接收端如何快速能够通知到源端并作出响应动作，以保证提供较好的传输质量，这便是 RTCP 报文的作用。
RTCP 报文格式如下所示，不同类型的报文有不同的 Data 结构。
Version：RTCP 报文版本
P：填充标识，如果该位为 1 表示 RTCP 报文最后有填充字节
Count：报文类型不同时含义不同，见具体报文类型解释
Type：报文类型，常见类型有 SR（发送报告报文），RR（接收报告报文），SDES（源端描述信息报文），BYE（会话结束报文），APP（应用自定义报文）
Length：表示 RTCP 报文长度，报文长度为 (Length+1) * 4
RR 报文协议格式（Receiver Report）
用户会发送所接收流的接收报告，发送端才能知道当前接收端的接收状态，接收报告通常包含多个 report block。
SSRC_n：流标识
fraction lost：从上一次 RR 报文发送之后的丢包率
cumulative number of packets lost：从开始接收 SSRC_n 数据包到当前时刻总共接收丢失的包数
extend highest sequence number received：从 SSRC_n 收到的 RTP 数据包中最大的序列号，其中低 16 位表示收到的最大 seq，高 16 位表示 seq 循环次数
interarrival jitter：接收抖动
last SR (LSR)：上一次接收到 SSRC_n SR 包时间戳（取 SR 报文 NTP 时间戳的中间 32 位）
delay since last SR (DLSR)：上一次接收到 SSRC_n SR 报文到本 RR 报文发送的延时
结合 LSR 和 DLSR，发送端可以测算 RTT 时间，RTT 为发送端收到 RR 报文的时间减去 LSR 再减去 DLSR 时间。
SR 报文协议格式（Sender Report）
流的生产者需要发送 SR 报文，SR 报文包含该流的发送包数，发送字节数，流的接收者可以根据发送者报文结合自己的接收情况计算丢包率等信息。
SSRC：流标识
NTP timestamp：NTP 时间戳，64 bit，表示绝对时间戳
高 32 位 seconds 表示从 1900 年 1 月 1 日到现在经历的秒数，ntp.seconds = ms / 1000
低 32 位 fractions 用于表示剩余微秒部分，其值为剩余的微秒部分乘以 2^32 后四舍五入的结果值
假设目前得到的时间戳是 3877076839.123456s，则 seconds = 3877076839，fractions = 0.123456 * 2^32 + 0.5（530239482）
static constexpr uint64_t NtpFractionalUnit{ 1LL << 32 };
struct Ntp {
uint32_t seconds;
uint32_t fractions;
}RTP timestamp：相对时间戳。它的单位表示经过一个采样间隔的时间，例如对于音频 8K 的采样频率，采样间隔为 1/8 ms，timestamp 加一表示经过了 1/8 ms，其初始值随机产生。
sender's packet count：发送的总包数
sender's octet count：发送的总字节数
SR 报文内容也可以同时包含接收报告。
SDES 报文协议格式（Source Description）
该报文用于描述 SSRC 信息，PT = 202，SC 表示描述的 SSRC SDES 个数，SDES items 是TLV 格式数。
可描述信息有：流对应的 NAME，关联的 EMAIL，PHONE，LOC 等信息。
WebRTC 在媒体协商时会为每个 SSRC 设置 CNAME，然后通过 RTCP SDES 报文确认 CNAME 与 SSRC 的关系
BYE 报文协议格式（Goodbye）
该报文用于 SSRC 流离开/结束通知，PT = 203，SC 表示 SSRC 个数。
APP 报文协议格式（Application-Defined）
该报文用于应用自定义消息类型，PT = 204，ST 表示自定义消息子类型，name 表示自定义消息名字，data 表示消息携带的数据。
RTPFB / PSFB 报文协议格式（Feedback）
SSRC of media source：表示是对哪个媒体源的反馈报告
Feedback Control Information：反馈内容，需要根据具体反馈类型确定内容含义
RTPFB 称为传输层反馈包，PT = 205，主要用于传输控制，FMT 表示反馈的具体子类型。
| PT | FMT | RTPFB Type | 说明 |
| 205 | 1 | NACK | 丢包反馈 |
| 205 | 3 | TMMBR | 临时最大码率设置请求 |
| 205 | 4 | TMMBN | 临时最大码率设置响应 |
| 205 | 15 | TFB | 传输带宽反馈（收包状况的反馈信息） |
PSFB 称为负载反馈包，PT = 206。
| PT | FMT | PSFB Type | 说明 |
| 206 | 1 | PLI | 图像丢失指示 |
| 206 | 2 | SLI | 片丢失指示 |
| 206 | 3 | RPSI | 参考图像丢失 |
| 206 | 4 | FIR | 关键帧请求 |
| 206 | 5 | TSTR | 时空交换请求 |
| 206 | 6 | TSTN | 时空交换响应 |
PLI 和 FIR 很类似，发送端收到 PLI 或者 FIR 报文时都会触发生成关键帧的动作，但 PLI 通常在接收端无法解码图像时候使用（例如因丢包无法收到帧的完整 RTP 包），而 FIR 主要用于主动申请关键帧（例如会议场景，新加入会议的用户需要主动请求其他用户的关键帧才能看到画面，如果一直收到参考帧是无法单独解码的）。
XR 报文协议格式（Extended Report）
XR 报文 PT=207，主要用来提供更详细的时间，丢包等统计信息，其包体由 report blocks 组成。
report block 构成如上所示，BT 指示该 block 的类型，block 有 7 种类型，分别是 LRLE(BT=1)，DRLE(BT=2)，PRT(BT=3)，RRT(BT=4)，DLRR(BT=5)，SS(BT=6)，VM(BT=7)，block length 指示块长度，以及跟 BT 类型相关的特定含义的字段，比较常用的有 RRT 和 DLRR。
RRT (Receiver Reference Time) 报告块格式如上，主要包含发送该报告块的 NTP 时间，发送该报告块主要用于接收端结合 DLRR 报告块测算 RTT 时间。
DLRR (Delay Since Last RR) 报告块格式如上，LRR 表示上次收到的 SSRC_1 RRT 报告块里的 NTP 时间的中间 32 位，DLRR 表示上次接收到 RRT 报告块到发送端发送此 DLRR 报告块的时间差。
当接收端收到此报告块时，就可以测算 RTT = 当前时间 - RRT 时间 - DLRR 时间。
mediasoup 中 NACK 模块的 RTT 便是用此方式计算得到的。
三. RTCP协议实战
RTCP-RTPFB NACK 类型报文在丢包重传请求中的应用
四. 参考资料
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
5
0- 0
已为社区贡献3条内容
所有评论(0)