副标题：webRTC 使用准备之流媒体协议
RTP 协议定义流媒体数据在互联网上传输的数据包格式，而 RTCP 协议则负责可靠传输、流量控制和拥塞控制等服务质量保证。有名的是Google的GCC（拥塞控制算法(Google Congestion Control,简称GCC[1])））.
UDP 协议：源端口、目的端口、UDP 长度、校验和、数据
- 相比 TCP 协议，数据有效性、有序性等等完全不管，更适合流媒体的实时传输。
- TCP 为了保证包的有序到达，具有丢包重传机制，比如丢包时的计时器从 200ms 到 400ms 到更久的时间，所以不适合实时传输。但当 UDP 不通时，需要换用 TCP 来保证连通率。但当 TCP 不通时，需要换用 HTTPS 来保证连通。
- UDP 无法解决的有序性等问题，由应用层的协议来解决。
RTP 协议：UDP 的上层协议，也能跑在 TCP 上（但一般不会这么干）。
- 具有 sequence number 字段，用于对数据包进行排序。
- timestamp 字段，用于判断某些包是否属于同一帧。若多个包具有相同的 timestamp，说明它们属于同一帧。
- SSRC 字段，synchronization source identifier，同步信源。占 32 位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
- CSRC 字段，共享源。每个 CSRC 标识符占 32 位，可以有 0～15 个。每个 CSRC 标识了包含在该RTP报文有效载荷中的所有特约信源。
- 视频或音频的接收端通常有一个环形队列，计算：一秒 30 帧数据，控制 200 毫秒以内的延迟，然后一个队列中能够装多少包，是可以计算出的，进而推算出环形队列的大小。
RTCP 协议：
- 标准的 Header：version+P(即 padding)+Count+Type+Length = 2 + 1 + 5 + 8 + 16 bit
RTCP Type：
| PT | 缩写 | 说明 | tips |
|---|---|---|---|
| 200 | SR | Sender Report packet | 重要※ |
| 201 | RR | Receiver Report packet | 重要※ |
| 202 | SDES | Source Description packet | 源描述协议，用于切源 |
| 203 | BYE | Goodbye packet | |
| 204 | APP | Application-defined packet | 应用层自定义 |
| 192 | FIR | Full INTRA-frame Request | 请求完整的I-帧，用于完全重新开始接收时（废弃，功能由 206 完成） |
| 193 | NACK | Negative Acknowledgement | 标记收包情况（废弃，功能由 206 完成） |
| 205 | RTPFB | Generic RTP Feedback | 传输层的返回包 |
| 206 | PSFB | Payload-specific Feedback | 应用层的返回包，对内容编解码器进行反馈 |
Intra的含义是图像内编码，不需要其他图像信息即可解码.
RTCP SR
- SR = header + sender info + report block * N 。
- header 也就是标准的 RTCP header。
- Sender info block 和 report block 如下。
Sender Information block：
- NTP timestamp，用于音视频同步的时间戳，网络时间戳，64 位。
- RTP timestamp， RTP 的普通时间戳，32 位，与 RTP 包时间戳一致。
- SPC，发送的包的总数，32 位。
- SOC，发送的包的全部字节，32 位。
Report block:
- SSRC_1：标识哪个 SSRC，32 位
- fraction lost：丢包率，8 位。
- packets lost：自接收开始的丢包总数，迟到包不计入，24 位。
- cumulative number of packets lost：丢包总数
- extended highest sequence number received：一般 2^16个包算一个段，这个字段里面，高 16 位标识属于哪个段，低 16 位标识属于段中哪里 sequence number。
- jitter：RTP 包接收时间间隔的统计方差，用于拥塞防止的重要参考字段，如果持续增长，说明可能存在拥塞。
- last SR（LSR），上次发送SR 的时间戳，34 位。
- delay since last SR： 接收 SR 的时间与发送 SR 的时间差。
RTCP RR
RR = header + report block * N
看下图，跟 SR 类似，不再赘述。
RTCP SDES
SDES：header + （SSRC + SDES items）* N
SDES item 采用TLV 结构类型：type + length + value
- 举例： CNAME + length + name…
| type | 说明 |
|---|---|
| CNAME | CNAME 与 SSRC 对应，CNAME 为源的唯一标识 |
| NAME | 用于描述源名，人类可读 |
| PHONE | |
| LOC | |
| TOOL | 没啥用 |
| NOTE | 备注 |
| PRIV | 私有扩展 |
RTCP BYE
BYE = header + SSRC * N + length + opt（reason for leaving）
RTCP APP
APP = header + SSRC + nameN + applicationData
RTCP RTPFB & PSFB
FB = header(传统 RTCP 的 header 小改) + SSRC + SSRC2 + FCI
| 类型 | 说明 |
|---|---|
| 传输层的 FB | RTPFB，是对传输层的控制，如 NACK |
| 负载层的 FB | PSFB，是对负载层的控制，如编解码器，如 PLI |
| 应用层的 FB | 应用层自己识别，一般认为是一种特殊的 PSFB |
RTPFB分类：
- NACK：对丢包请求的
- TMMBR：最大媒体流比特率请求，max media stream bitrate request。表明接收端当前带宽受限，告诉发送端控制码率。
- TMMBN：max media stream bitrate notification.响应的通知，会告知最大的带宽，是 TMMBR 的响应。
PsFB 分类：
- PLI：picture loss indication, 图片丢失，可能会将这个帧的所有包都发送过来。
- SLI：slice loss indication, 每个视频帧可能包含多个 slice，每个 slice 可能对应一个包，slice 如果丢失时可能会发送这个请求。
- RPSI：reference picture selection indication, 参考图片丢失，相当于 B 帧丢失。
- FIR：full intra request command, 请求一个完整的内部帧。
- TSTR：temporal-spatial trade-off request, 空间时间交互系统的请求。
- TSTN：temporal-spatial trade-off notification, 上面 5 的响应。