WebRTC源码分析之RTP/RTCP（一）

首先学习一下RTP/RTCP的基础知识。

RTP/RTCP协议

---

RTP报头

当没有CSRC时RTP报头一共12个字节。
报头格式如下：
版本号（V）：2比特，用来标志使用的RTP版本，当前协议版本号为2。
填充位（P）：1比特，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
扩展位（X）：1比特，如果X=1，RTP固定头部后面就跟有一个扩展头部。
CSRC计数器（CC）：4比特，表示含有固定头部后面跟着几个CSRC。
标记位（M）：1比特，该位的解释由配置文档（Profile）来承担。不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。（对于分组中的重要事件可用该位标识）。
有效载荷类型（PT）：7比特，标识了RTP载荷的类型。比如H264视频、AAC音频等。
序列号（SN）：16比特，发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。
时间戳：32比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加。时间戳是去除抖动和实现同步不可缺少的。
同步源标识符(SSRC)：32比特，同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的，RFC1889推荐了MD5随机算法。

当上面CSRC计数器（CC）等于0时上面一共12字节，当大于0时有以下CSRC列表：
贡献源列表（CSRC List）：0～15项，每项32比特，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。

SSRC代表会话中的一路数据流id，比如一个会话中的一个用户有一路音频和一路视频，这时就有两个不同的SSRC。
CSRC是在用到mixer混合（混音）时才会出现，也就是说几个源rtp包经过mixer后，mixer会将他们各自的payload整合，并生成一个新的ssrc代替原来的各个ssrc，并且把他们各自的ssrc作为csrc插入新的rtp包中。
也就是说csrc的值为混合前每一路的ssrc。
CC是CSRC计数，只有4位，表示一共有几个CSRC。所以CSRC如果多于15个那最多只能有15个CSRC被标识。
CSRC是为了在混音后指出当前发言者。

有效载荷根据不同的音视频类型有不同的打包方式。比如H264使用PS流封装，MPEG2使用PES封装。

RTCP

由于每个对话成员定期发送RTCP信息包，随着参加者不断增加，RTCP信息包频繁发送将占用过多的网络资源，为了防止拥塞，必须限制RTCP信息包的流量，控制信息所占带宽一般不超过可用带宽的 5%，因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包，因此终端的总数很容易估计出来，应用程序根据参加者总数就可以调整RTCP包的发送速率。

RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。
根据所携带的控制信息不同RTCP信息包可分为5类：
类型：200，SR 发送端报告
类型：201，RR 接收端报告
类型：202，SEDS 源描述包
类型：203，BYE 结束传输
类型：204，APP 应用描述功能

SR和RR为报告包，比较重要，每个复合包的第一个包必须为SR或者RR，就算没有SR/RR信息也应该发一个空的报告包。

RTCP的详细协议参考RFC3550，本文底部附有英文原版和中文版(不全)地址。

附

---

RFC3550英文版 - RTP: A Transport Protocol for Real-Time Applications
RFC3550 RTP 中文版
RTP协议全解析（H264码流和PS流）