漫游RTP/RTCP协议(卷一)
本来是想一篇文章介绍完的，写着写着发现太多了，所以就分割成两篇文章，请各位鉴赏，有问题留言，谢谢。
一、概念
1.1 RTP/RTCP是什么
RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为 RFC3550。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。
RTCP全名是Real-time Transport Control Protocol（实时传输控制协议 ），是RTP的配套协议，主要用于音视频同步，流量控制，拥塞控制，保证流数据的可靠性。
1.2 RTP的应用环境
RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。
A、简单的多播音频会议
语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。
B、音频和视频会议，比如WebRTC
如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。
二、RTP详解
2.1 RTP的协议层次
图 1 流媒体体系结构
从上图中可以看出，RTP/RTCP被划分在传输层，它建立在UDP/TCP上。RTP主要是基于UDP协议传输，当然也可以基于TCP，但由于TCP协议的可靠性保证，如果应用于流媒体数据包传输会比较重，但可以作为一个备选方案，如果在某个特殊局域网内，在UDP不通的情况下，可以走TCP。
图二、基于UDP协议的RTP分组示意图
2.2. RTP Header
RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个 RTP 数据报都由
头部（Header）
和有效载荷
（Payload）
两个部分组成，其中头部前
12 个字节
的含义是固定的，而负载则可以是
音频
或者
视频
数据。RTP 数据报的头部格式如图：
图三 RTP的头部格式
RTP Header解析
|
字段
|
位宽
|
含义
|
|
V
|
2
|
RTP 协议的版本号，当前协议版本号为 2。
|
|
P
|
1
|
填充标志，如果 P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
|
|
X
|
1
|
扩展标志，如果 X=1，则在 RTP 报头后跟有一个扩展报头。
|
|
CC
|
4
|
CSRC 计数器， 指示 CSRC 标识符的个数。
|
|
M
|
1
|
标记，不同的有效载荷有不同的含义，对于
视频，标记一帧的结束；对于
音频，标记会话的开始。
|
|
PT
|
7
|
有效载荷类型，用于说明 RTP 报文中有效载荷的类型，如 GSM 音频、JPEM 图像等。
|
|
sequence number
|
16
|
用于标识发送者所发送的 RTP 报文的序列号，每发送一个报文，序列号增 1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。
|
|
timestamp
|
32
|
时戳反映了该 RTP 报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
|
|
SSRC
|
32
|
用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的 SSRC。
|
|
CSRC
|
32
|
每个 CSRC 标识符占 32 位，可以有 0～15 个。每个 CSRC 标识了包含在该 RTP 报文有效载荷中的所有特约信源。
|
RTP Header头结构定义
/*
* RTP data header
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */
u_int32 ts; /* timestamp */
u_int32 ssrc; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */
} rtp_hdr_t;
RTP Header码流举例：
80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kIe1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????头解析如下：80 ===> 10_0_0_0000 ====> V_P_X_CCe0 ===> 1_1110000 ====> M_PT00 1e ===> SequenceNum00 00 d2 f0 ===> Timestamp00 00 00 00 ===> SSRC
2.3 RTP PayLoad
根据RTP Header中PT值，我们可以判断PayLoad是什么格式，具体可以看 Real-Time Transport Protocol (RTP) Parameters。本文以最常用的H.264编码格式来介绍Payload Format，具体协议请参考 RFC6184.
H264 PayLoad是通过Network Abstraction Layer Units (NALUs)来封装的，定义了三种不同payload打包格式，在PayLoad的第一个字节里type有定义，具体看下面格式。
图四 NALU Type字段说明
|
字段
|
位宽
|
含义
|
|
F
|
1
|
0代表NAL单元类型字段和其内容可能存在bit级别的错误或其他语义错误部分。1代表包含bit不存在bit级别的错误或其他语义错误部分
|
|
NRI
|
2
|
此帧数据是否影响参考帧完整性，取值从00 ~ 11重要性依次递增，00：
不用来为I帧来重构参考帧 11：表示
I帧，见图五
|
|
Type
|
5
|
打包类型，见图六
|
说明：
图五 NRI说明表
图六 NAL单元类型说明表
2.3.1 打包类型
1、Single NAL Unit Packet: 该负载类型只包含一个NAL单元。NAL单元类型字段值范围为对应上图1~23, 具体格式如下：
图七
RTP payload format for single NAL unit packet
单NAL单元报文定义: 只包含一个NAL单元。也就是说聚合报文和分片报文都不能放在单NAL单元报文中。单NAL单元报文构造的时候，必须和RTP sequence的顺序是一致的
2、
Aggregation Packet: 该类型包含多个NAL单元到一个RTP负载中，
NAL单元类型字段值范围为对应图六的24~27，具体格式如下：
图八
RTP payload format for aggregation packets
3、
Fragementation unit: 一个NAL单元的包大小超过1MTU，那么一个NAL单元分片到多个RTP报文中。有两个版本: FUa, FUb,
NAL单元类型字段值分别对应图六的28，29, 具体格式如下：
图九、
RTP payload format for FU-B
图十、FU indicator
图十一 FU header
说明：
FU indicator就不说了，此处说一下
FU header，具体说明如下：
|
字段
|
位宽
|
含义
|
|
S
|
1
|
0：起始包 1：分包
|
|
E
|
1
|
0：分包 1：终止包
|
|
R
|
1
|
缺省预留
|
|
Type
|
5
|
打包类型，见图六
|
当然还有另外一种打包类型FUb，这里就不讲了，大家有兴趣的可以去参考RFC6428协议。
三、参考
[1] RFC文档：RFC3550对应RTP/RTCP，RTC6184对应Playload format for h264
[2] http://www.faqs.org/rfcs/，上面有全面的英文RFC文档
[3] http://www.cnpaf.net/，有不少协议分析文档，也有中文RFC文档，但质量不是特别高。