RTP会话(RTP session):
RTP传输服务使用者之间的连接被称为RTP会话，就每一个会话参加者而言，会话由一对传输层地址(即一个网络层地址加上 两个端口地址,一个端口为 RTP 报文的发送/接收所占用,另一个端口为 RTCP报文的发送/接收所占用)标识。在 IP 多播方式中，每个参与者的目的地运输层地址对可以都相同；在单播方式中，每个参与者的地址对均不相同，因为每个人的网络层地址都不相同。在多媒体会话中，每个媒体信号由不同的 RTP 会话传送，有其自己的 RTCP 分组。各 RTP 会话由不同的端口对 （和/或） 不同的多播地址区分。
混合器(Mixer)和翻译器(Translator):
翻译器和混合器都是RTP级的中继系统。
翻译器用在通过IP多播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。
当与会者能接收的音频编码格式不一样，比如有一个与会者通过一条低速链路接入到高速会议，这时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进行重构，并把重构后的多个音频合并，采用另一种音频编码进行编码后，再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源（SSRC，见RTP的封装）来识别，可以通过贡献源列表（CSRC表，见RTP的封装）可以确认谈话者。
流媒体
流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式：下载和流式传输两种方式。
下载情况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播结束，也就是用户至少要在直播结束后才能看到直播节目，所以用下载方式不能实现直播。
流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的，所以接收端收到的数据包往往有延迟和乱序（流式传输构建在UDP上）。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进行预处理（降低质量和高效压缩）。在接收端为了恢复时序，采用了接收缓冲；而为了实现媒体的流畅播放，则采用了播放缓冲。
使用接收缓冲，可以将接收到的数据包缓存起来，然后根据数据包的封装信息（如包序号和时戳等），将乱序的包重新排序，最后将重新排序了的数据包放入播放缓冲播放。
为什么需要播放缓冲呢？容易想到，由于网络不可能很理想，并且对数据包排序需要处理时耗，我们得到排序好的数据包的时间间隔是不等的。如果不用播放缓冲，那么播放节目会很卡，这叫时延抖动。相反，使用播放缓冲，在开始播放时，花费几十秒钟先将播放缓冲填满（例如PPLIVE），可以有效地消除时延抖动，从而在不太损失实时性的前提下实现流媒体的顺畅播放。
到目前为止,Internet上使用较多的流式视频格式主要有以下三种：
RealNetworks 公司的RealMedia ，Apple 公司的QuickTime以及Microsoft 公司的Advanced Streaming Format (ASF) 。
上面在谈接收缓冲时，说到了流媒体数据包的封装信息（包序号和时戳等），这在后面的RTP封装中会有体现。另外，RealMedia这些流式媒体格式只是编解码有不同，但对于RTP来说，它们都是待封装传输的流媒体数据而没有什么不同。
RTP是传输层的子层
RTP（实时传输协议），顾名思义它是用来提供实时传输的，因而可以看成是传输层的一个子层。
RTP被划分在传输层，它建立在UDP（一般实际情况是基于UDP，基于TCP效率太低）上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。这些特点，在第4章可以看到。
RTP是应用层的一部分
不少人也把RTP归为应用层的一部分，这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务，而RTP的实现还是要靠开发者自己。因此从开发的角度来说，RTP的实现和应用层协议的实现没有不同，所以可将RTP看成应用层协议。
RTP实现者在发送RTP数据时，需先将数据封装成RTP包，而在接收到RTP数据包，需要将数据从RTP包中提取出来。
RTP的会话过程
当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。 RTP的发送过程如下，接收过程则相反。
1) RTP协议从上层接收流媒体信息码流（如H.263），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
2) RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。
实时流协议RTSP
实时流协议RTSP（Real-Time Streaming Protocol）是IETF提出的协议，对应的RFC文档为RFC2362。
，RTSP是一个应用层协议（TCP/IP网络体系中）。它以C/S模式工作，它是一个多媒体播放控制协议，主要用来使用户在播放流媒体时可以像操作本地的影碟机一样进行控制，即可以对流媒体进行暂停/继续、后退和前进等控制。
资源预定协议RSVP
资源预定协议RSVP(Resource Reservation Protocol)是IETF提出的协议，对应的RFC文档为RFC2208。
RSVP工作在IP层之上传输层之下，是一个网络控制协议。RSVP通过在路由器上预留一定的带宽，能在一定程度上为流媒体的传输提供服务质量。在某些试验性的系统如网络视频会议工具vic中就集成了RSVP。
声音和图像怎么同步（这里和上面的说法有一点点区别）
根据声音流和图像流的相对时间（即RTP包的时间戳），以及它们的绝对时间（即对应的RTCP包中的RTCP）（应该还有RTCP中的CNAME），可以实现声音和图像的同步。
4、RTP Header解析
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图1
前12字节是固定的，CSRC可以有多个。
1) V：RTP协议的版本号，占2位，当前协议版本号为2
2) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头
4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数
5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
6) PT（payload type）: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等，在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。
7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。当出现网络抖动的情况可以用来对数据进行重新排序。序列号的初始值是随机的，同时音频包和视频包的sequence 是分别记数的。
8) 时间戳(Timestamp)：占32位，必须使用90 kHz，时钟频率（程序中的90000）。时间戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时间戳来计算延迟和延迟抖动，并进行同步控制。可以根据RTP包的时间戳来获得数据包的时序。
9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。同步信源是指产生媒体流的信源，它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。
该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。
10) 提供信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个CSRC。每个CSRC标识了包含在该RTP报文有效载荷中的所有提供信源。
提供信源用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报文，并把混合器作为组合RTP报文的SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个SSRC。
注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理
如果扩展标志被置位则说明紧跟在报头后面是一个头扩展，其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
取一段码流如下：
80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kI
e1 0f 26 53 02 1a ff 06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.
cc 13 ec 52 77 4e e5 0e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?
f6 e1 29 d5 d6 a4 ef 3e 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 是V_P_X_CC
e0 是M_PT
00 1e 是SequenceNum
00 00 d2 f0 是Timestamp
00 00 00 00是SSRC
把前两字节 80 e0 换成二进制如下
1000 0000 1110 0000
按顺序解释如下：
10 是V；
0 是P；
0 是X；
0000 是CC；
1 是M；
110 0000 是PT；
RTP抓包实例
上面是某省IPTV２.０早期的一个数据包的情况。从包中可以看出RTP是怎么和RTSP配合一起使用的。从包402到411为RTSP的协商过程，RTSP在PLAYer命令后数据包就到来。紧跟其后412包就是一个mpeg 的PES包，它是有由rtp来承载的TS来形成。从在420包中就可以更加清析的看出这个RTP流的情况。其PT即payload type为mpeg2 transport streams 也就是ts流，其SSRC为：0x65737D6c，其Seq号为15764，从中也可以看出对于一个RTP流其SEQ号可以开始于一个随机的数值，但是肯定是逐包递增的。
从中可以看出承载RTP的为UDP的数据报，这个包中有x标志位为1，则说明其有header extensions。其header extensions为最下面。extension的 profile为23128,长度为：2。内容如上图最后两部分。
5、RTP载荷H264码流
RTP头后是RTP载荷，RTP载荷第一个字节格式跟NALU头一样：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
F和NRI也跟NALU头一样，只有Type有些不一样：
0 没有定义
1-23 NAL单元 单个 NAL 单元包.
24 STAP-A 单一时间的组合包
25 STAP-B 单一时间的组合包
26 MTAP16 多个时间的组合包
27 MTAP24 多个时间的组合包
28 FU-A 分片的单元
29 FU-B 分片的单元
30-31 没有定义
载荷格式定义三个不同的基本荷载结构，接收者可以通过RTP荷载的第一个字节后5位（Type）识别荷载结构：
1) 单个NAL单元包：荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元（NALU）类型，即Type在范围1到23之间。
2) 聚合包（组合包）：本类型用于聚合多个NAL单元到单个RTP荷载中。本包有四种版本，单时间聚合包类型A (STAP-A)，单时间聚合包类型B (STAP-B)，多时间聚合包类型(MTAP)16位位移(MTAP16), 多时间聚合包类型(MTAP)24位位移(MTAP24)。赋予STAP-A, STAP-B, MTAP16, MTAP24的NAL单元类型号（Type）分别是 24,25, 26, 27
3) 分片包：用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B,用NAL单元类型 （Type）28，29标识。
常用的打包时的分包规则是：如果小于MTU采用单个NAL单元包，如果大于MTU就采用FUs分片方式。
2.2、单个NAL单元包格式
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a Single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图3
对于 NALU（NAL单元）的长度小于 MTU 大小的包, 一般采用单一 NAL 单元模式.
定义在此的NAL单元包必须只包含一个。RTP序号必须符合NAL单元的解码顺序。这种情况下，NAL单元的第一字节和RTP荷载头第一个字节重合。如上图。
对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个 NALU 单元的开始, 必须是 00 00 00 01 或 00 00 01, NALU 头仅一个字节, 其后都是 NALU 单元载荷。
打包时去除 00 00 01 或 00 00 00 01 的开始码, 把其他数据封装成 RTP 包即可。
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]
这是一个序列参数集 NAL 单元。 [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 载荷.
封装成 RTP 包将如下:
[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ...]
即只要去掉 4 个字节的开始码就可以了.
2.3 组合封包格式
当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Data | : ：
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
这种模式下，有多个NALU载荷，多个NALU头。
2.4、分片单元（FU-A）
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FU-A RTP 载荷格式
其中 FU indicator 8位格式为：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
FU header 格式:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为 Fragmentation Units (FUs).
NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。同时，NAL单元必须按照RTP顺序号的顺序装配。
当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。STAPs，MTAPs不可以被分片。 FUs不可以嵌套。 即, 一个FU 不可以包含另一个FU。运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。
图 4 表示FU-A的RTP荷载格式。FU-A由1字节的分片单元指示（FU indicator）、1字节的分片单元头（ FU header）和分片单元荷载组成。
S（开始位）: 1 bit， 当设置成1，指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。
E（结束位）: 1 bit， 当设置成1，指示分片NAL单元的结束，即,荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的 FU荷载不是分片NAL单元的最后分片，结束位设置为0。
R（保留位）: 1 bit， 保留位必须设置为0，接收者必须忽略该位。
Type（类型）：5 bit， 是NAL Header中的Type。
打包时，原始的NAL头的前三位为FU indicator的前三位，原始的NAL头的后五位（Type）为FU header的后五位（Type）。
取一段码流分析如下：
80 60 01 0f 00 0e 10 00 00 00 00 00 7c 85 88 82 €`..........|???
00 0a 7f ca 94 05 3b 7f 3e 7f fe 14 2b 27 26 f8 ...??.;.>.?.+'&?
89 88 dd 85 62 e1 6d fc 33 01 38 1a 10 35 f2 14 ????b?m?3.8..5?.
84 6e 21 24 8f 72 62 f0 51 7e 10 5f 0d 42 71 12 ?n!$?rb?Q~._.Bq.
17 65 62 a1 f1 44 dc df 4b 4a 38 aa 96 b7 dd 24 .eb??D??KJ8????$
前12字节是RTP Header
7c是FU indicator
85是FU Header
FU indicator（0x7C）和FU Header（0x85）换成二进制如下
0111 1100 1000 0101
按顺序解析如下：
0 是F
11 是NRI
11100 是FU Type，这里是28，即FU-A
1 是S，Start，说明是分片的第一包
0 是E，End，如果是分片的最后一包，设置为1，这里不是
0 是R，Remain，保留位，总是0
00101 是NAL Type，这里是5，说明是关键帧（不知道为什么是关键帧请自行谷歌）
打包时，FU indicator的F、NRI是NAL Header中的F、NRI，Type是28（FU-A）；FU Header的S、E、R分别按照分片起始位置设置，Type是NAL Header中的Type。
解包时，取FU indicator的前三位和FU Header的后五位，即0110 0101（0x65）为NAL类型。
RTP，RTCP数据和RTSP数据共享TCP数据通道，所以必须有一个标识来区别三种数据。RTP和RTCP数据会以$符号＋1个字节的通道编号＋4个 字节的数据长度（有说2字节长），共6个字节的前缀开始，流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。 RTSP数据是没有前缀数据的。RTP数据和RTCP数据的区别在于第二个字节的通道编号，据观察RTP通道编号是偶数，RTCP通道编号是奇数。
当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
