EEPW论坛

1、RTP协议简介

RTP(Real-timeTransport Protocol)，由 IETF（http://www.ietf.org/）定义在 RFC 3550和3551中。被定义为传输音频、视频、模拟数据等实时数据的传输协议，与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性，此协议提供的服务包括数据顺序号、时间标记、传输控制等。

RTP位于传输层（通常是UDP）之上，应用程序之下，实时语音、视频数据经过模数转换和压缩编码处理后，先送给RTP封装成为RTP数据单元，RTP数据单元被封装为UDP数据报，然后再向下递交给IP封装为IP数据包。

RTP通常与辅助控制协议RTCP（RTP Control Protocol）一起工作，RTP只负责实时数据的传输，RTCP负责对RTP的通信和会话进行带外管理（如流量控制、拥塞控制、会话源管理等）。RTP分组只包含RTP数据，而控制由RTCP提供。RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个奇数UDP端口号。在RTP会话期间，各参与者周期的发送RTCP消息。RTCP消息含有已发送数据的丢包统计和网络拥塞等信息，服务器可以利用这些信息动态的改变传输速率，甚至改变净荷的类型。RTCP消息也被封装为UDP数据报进行传输。

2、RTP协议层次

RTP用来提供实时传输，因而可以看成是传输层的一个子层。

下图给出了流媒体应用中的一个典型的协议体系结构。

从图中可以看出，RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，由RTCP来保证其服务质量。

不少人把RTP归为应用层的一部分，这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务，而RTP部分的封闭还是要靠开发者自己来实现。因此从开发的角度来说，RTP的实现和应用层协议的实现没什么不同，所以可将RTP看成应用层协议。在发送RTP数据时，需先将数据封装成RTP包，而在接收到RTP数据包，需要将数据从RTP包中提取出来。

3、 常见RTP的术语简介

RTP负载（RTP payload）：通过RTP传输的数据，如:音频样本或压缩好的视频数据。

        RTP包（RTP packet）：封装后的数据包，其组成部分有：一个固定RTP报头，一个可能为空的作用源（contributing sources）列表，以及负载数据。

RTCP包（RTCP packet）：一种控制包，其组成部分有：一个类似RTP包的固定报头，后跟一个结构化的部分，该部分具体元素依不同RTCP包的类型而定。

　　端口（Port）：“传输协议用来在同一主机中区分不同目的地的一种抽象。TCP/IP协议使用正整数来标识不同端口。”[12]　OSI传输层使用的传输选择器（TSEL,the transport selectors）等同于这里的端口。RTP需依靠底层协议提供的多种机制，如“端口”用以传输多路复用会话中的RTP或RTCP包。

　　传输地址(Transport address)：是网络地址与端口的结合，用来标识一个传输层次的终端，例如一个IP地址与一个UDP端口。包是从源传输地址发送到目的传输地址。

　　RTP媒体类型（RTP media type）：一个RTP媒体类型是一个单独RTP会话所载有的负载类型的集合。RTP配置文件把RTP媒体类型指派给RTP负载类型。

　　多媒体会话（Multimedia session）：在一个参与者公共组中，并发的RTP会话的集合。例如，一个视频会议（为多媒体会话）可能包含一个音频RTP会话和一个视频RTP会话。

　　RTP会话（RTP session）：一群参与者通过RTP进行通信时所产生的关联。一个参与者可能同时参与多个RTP会话。在一个多媒体会话中，除非编码方式把多种媒体多路复用到一个单一数据流中，否则每种媒体都将使用各自的RTCP包，通过单独的RTP会话来传送。通过使用不同的目的传输地址对（一个网络地址加上一对分别用于RTP和RTCP的端口，构成了一个传输地址对）来接收不同的会话，参与者能把多个RTP会话区隔开来。单个RTP会话中的所有参与者，可能共享一个公用目的传输地址对，比如IP多播的情况；也可能各自使用不同的目的传输地址对，比如个体单播网络地址加上一个端口对。对于单播的情况，参与者可能使用相同端口对来收听其他所有参与者，也可能对来其他每个参与者使用不同的端口对来收听。

　　RTP会话间相互区别的特征，在于每个RTP会话都维护一个用于SSRC标识符的独立完整的空间。RTP会话所包含的参与者组，由能接收SSRC标识符的参与者组成，这些SSRC标识符由RTP（同步源或作用源）或RTCP中的任意参与者传递。例如，考虑下述情况，用单播UDP实现的三方会议，每方都用不同的端口对来收听其他两方。如果收到一方的数据，就只把RTCP反馈发送给那一方，则会议就相当于由三个单独的点到点RTP会话构成；如果收到一方的数据，却把RTCP反馈发送另两方，则会议就是由一个多方（multi-party)RTP会话构成。后者模拟了三方间进行IP多播通信时的行为。

　　RTP框架允许上述规定发生变化，但一个特定的控制协议或者应用程序在设计时常常对变化作出约束。

　　同步源(SSRC，Synchronization source)：RTP包流的源，用RTP报头中32位数值的SSRC标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP混频器（见下文）就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC标识符是一个随机选取的值，它在特定的RTP会话中是全局唯一（globally unique）的（见章节8）。参与者并不需要在一个多媒体会议的所有RTP会话中，使用相同的SSRC标识符；SSRC标识符的绑定通过RTCP（见章节6.5.1）。如果参与者在一个RTP会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源。

作用源（CSRC，Contributingsource )：若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。相关应用的例子如，在音频会议中，混频器向所有的说话人（talker)指出，谁的话语（speech)将被组合到即将发出的包中，即便所有的包都包含在同一个（混频器的）SSRC标识符中，也可让听者（接收者）可以清楚谁是当前说话人。  　

4、RTP的封装格式简介

下图展示了RTP数据报中RTP固定头的格式构成：

这些域有以下意义：    

  　 版本(V)：2比特   此域定义了RTP的版本。此协议定义的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"语音工具使用的协议中。)    

  　 填充(P)：1比特   若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。    

  　 扩展(X)：1比特   若设置扩展比特，固定头(仅)后面跟随一个头扩展。    

  　 CSRC计数(CC)：4比特   CSRC计数包含了跟在固定头后面CSRC识别符的数目。    

  　 标志(M)：1比特   标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。

  　 负载类型(PT)：7比特   此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发送端在任意给定时间发出一个单独的RTP负载类型；此域不用来复用不同的媒体流。    

 　  序列号（sequence number）：16比特   每发送一个RTP数据包，序列号加1，接收端可以据此检测丢包和重建包序列。

  时间戳（timestamp） 32比特时间戳反映了RTP数据包中第一个字节的采样时间。（采样时钟必须来源于一个及时的单调、线性递增时钟，以便允许同步和去除网络引起的数据包抖动（见RFC3550章节6.4.1）。该时钟的分辨率必须满足理想的同步精度和测量数据包到来时的抖动的需要（一种典型的时钟分辨率不满足情况是每个视频帧仅一个时钟周期）时钟频率依赖于负载数据的格式，并在描述文件（profile）中或者是在负载格式描述中（payload format speci_cation）进行静态描述。也可以通过非RTP方法（non-RTP means）对负载格式动态描述。

如果RTP包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟（时间戳时钟）将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块，那么对每个块，时间戳的值增加160，而不考虑该块是否用一个包传递或是被丢弃。

时间戳的初始值应当是随机的，就像序号一样。几个连续的RTP包如果（逻辑上）是同时产生的，如：属于同一个视频帧的RTP包，将有相同的序列号。如果数据并不是以它采样的顺序进行传输，那么连续的RTP包可以包含不是单调递增（或递减）的时间戳（RTP包的序列号仍然是单调变化的）。

SSRC：32比特  用以识别同步源。标识符应该被随机生成，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。一个用于创造随机标示符的示例算法在A.6第六章讲述。尽管多个源选择同一个SSRC识别符的概率很低，所有RTP实现工具都必须准备检测和解决冲突。第8章讲述了冲突的可能性及其解决机制。若一个源改变本身的源传输地址，必须选择新的SSRC识别符，以避免被当作一个环路源(see Section 8.2)。

        CSRC列表：0到15项，每项32比特   CSRC列表指出了对此包中负载内容的所有贡献源。识别符的数目在CC域中给定。若有贡献源多于15个，仅识别15个。CSRC识别符由混合器插入(see Section 7.1)，并列出所有贡献源的SSRC识别符。例如语音包，混合产生新包的所有源的SSRC标识符都被列出，以在接收端处正确指示参与者。