RTP

RTP协议介绍RTP概要RTP定义在RFC 1889中。

RTP是 IETF提出的适合实时数据传输的协议，支持在单目标广播和多目标广播网络服务中传输实时数据，能为实时媒体数据提供点到点的传输服务。

RTP 主要应用在Internet上传输对时延敏感的业务，如音频流和视频流。

RTP也可以用于传输电话呼叫，国际电信联盟在多媒体通信标准H.323 中采用了RTP。

RTP特性1、协议独立性RTP是独立于底层协议的传输机制，可以在UDP/IP、ATM AAL5和IPX层上实现。

2、同步机制RTP采用时间戳(Times tamp)来控制单一媒体数据流，但它本身并不能控制不同媒体数据流间的同步。

若要实现不同数据流之间的同步，必须由应用程序参与完成。

3、包传输路径回溯RTP中使用了混合器（把多个视频流混合成一个视频流）和解释器（网关或传输路径上编码格式转换器），因此它提供了当分组到达接收端后进行包传输路径回溯的机制，这种机制主要通过RTP包头中的SSRC和CSRC域来完成。

4、可靠性由于RTP的设计目的是传输实时数据流，而不是可靠的数据流，因此它不提供有关数据传输时间、错误检测和包顺序监控的机制，也就是讲RTP提供的实时服务没有资源预约，也没有Qos保证，这些任务依靠下层协议来完成。

5、RTP层不支持多路复用多路复用由低层协议来完成，如：UDP。

RTP信息包被封装在UDP中，当接收端同时收到来自不同地方的多个数据分组，通过UDP实现多路复用、检查和服务。

6、扩展性支持在单目标广播（Unicast）和多目标广播（Multicast）。

7、安全性RTP考虑到安全性能，支持数据加密和身份鉴别认证功能。

8、灵活性控制数据与媒体数据分离，RTP协议只提供完成实时传输的机制，开发者可以根据应用环境选择控制方式。

RTP在网络中的传输TCP协议是面向连接的协议，它的重传机制和拥塞控制机制(Congestion Control Mechanism)都是不适合用于实时多媒体传输的。

TCP/ IP协议最初是为提供非实时数据业务而设计的。

IP协议负责主机之间的数据传输，不进行检错和纠错。

因此，经常发生数据丢失或失序现象。

为保证数据的可靠传输，人们将TCP协议用于IP数据的传输，提高接收端的检错、纠错能力。

当检测到数据包丢失或错误时，要求发送端重新发送，但这样不可避免地引起传输延时和耗用网络带宽。

因此传统的TCP/ IP协议传输实时音频、视频数据的能力较差。

UDP是最简单的传输协议，几乎不提供可靠性措施。

但是，UDP的效率却非常高。

音频数据和视频图像数据的传输往往要求实时传输及保证时间的连续性。

同时又允许传输中存在一定的数据错误率以及数据丢失率。

UDP协议不进行数据的确认与重传，大大提高了传输速率，具有高效快速的特点，因此适合对音频视频数据的传输。

RTP依赖下层网络来多路传输RTP数据流和RTCP控制流，当下层协议为UDP时，RTP 使用一个编号为偶数的传输端口，相应的RTCP使用接下来编号为奇数的传输端口。

RTP数据包没有包含长度域或其它边界，由下层网络为RTP提供长度表示，因此RTP 包的最大长度是由下层网络限制。

RTP对下层网络没有任何限制。

但是为了使用UDP的端口号和检查和，执行RTP的程序常常运行在UDP的上层。

如下图所示，RTP可以看成是传输层的子层。

由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，然后再封装在IP数据包中。

图 RTP是传输层上的协议RTP执行程序应该是应用程序的一部分，因为必需把RTP集成到应用程序中。

在发送端，执行RTP协议的程序被写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接端口(socket interface)；同样，在接收端，RTP信息包通过UDP套接端口输入到应用程序，因此，执行RTP协议的程序必需被写入到从RTP信息包中抽出媒体数据的应用程序。

下面用RTP传输声音为例来说明它的工作过程。

假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。

应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。

然后RTP信息包被送到UDP套接端口，在那里再被封装在UDP信息包中。

在接收端，应用程序从套接端口处接收RTP信息包，并从RTP信息包中抽出声音数据块，然后使用RTP信息包标题域中的信息正确地译码和播放声音。

如果应用程序使用标准的RTP协议提供有效载荷类型(payload type)、顺序号或者时间戳，应用程序将更容易与其他的网络应用程序配合运行。

例如，如果有两个不同的公司都在开发因特网电话软件，他们都把RTP合并到他们的产品中，这样就可能让使用不同公司电话软件的用户之间能够进行通信。

这里需要强调的是，RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量，它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。

RTP的封装只是在系统端才能看到，中间的路由器并不区分哪一个IP数据报运载的是RTP 信息包。

RTP允许给每个媒体源分配一个单独的RTP信息包流，使得视频和音频可以分开单独编码。

例如，有两个团体参与的电视会议，这就可能打开4个信息包流：两台摄像机传送电视流和两个麦克风传送声音流。

然而，许多流行的编码技术，包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流，一个方向就生成一个RTP信息包流。

RTP信息包可应用于单目标广播，也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。

例如，多对多的多目标广播，在这种应用场合下，所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。

RTP信息包的传输流程RTP在接收方和发送方之间引入了两种类型的中间节点：混合器和解释器，通过它们来完成实时数据传输。

混合器是一个中间系统，它接收来自一个或多个发送方的RTP信息包，将这些包以某种方式组合，期间有可能会改变这些包的数据格式，然后转发一个新的RTP包。

在多个发送方之间的定时一般是不同步的，混合器对各个流之间的定时加以调整，并为这个组合的流产生它自己的定时。

因此，从一个混合器出来的所有数据包要用混合器作为它们的同步源来识别。

来自不同发送方的信息包由于在网络中传输的路径不同，到达混合器可能是非同步的，混合器改变了媒体流的临时结构。

RTP混合器不能将不兼容媒体流合并成一个流。

混合器的一个典型例子是将某个多点会议的多个音频源组合成一个音频流转发给所有接收方。

解释器是一个中间系统，它与混合器不同，解释器只改变信息包的内容，而并不把媒体流组合在一起。

解释器只对单个媒体流进行操作，可能是编码转换或者协议翻译，它用完整的同步源标识符来转发RTP包。

例如：多媒体会议中不同端系统之间的视频编解码转换器，以及防火墙中应用层的过滤器等。

RTP信息包结构RTP信息包由标题域和有效载荷的数据组成。

通常情况底层协议的一个包只包含一个RTP信息包，但是如果封装的方法允许，也可以包含几个RTP信息包。

RTP信息包的结构包含广泛用于多媒体的若干个域，包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)等。

RTP协议没有规定声音和电视的压缩格式，它可以被用来传输普通格式的文件。

例如，WAV或者GSM(G lobal S ystem for M obile communications)格式的声音、MPEG-1和MPEG-2的电视，也可以用来传输专有格式存储的声音和电视文件。

RTP标题域的前12个字节出现在每一个RTP包中，CSRC列表仅出现在有混合器的情况下。

RTP信息包的标题域的结构如下图所示：图RTP信息包的标题域格式版本号（V）:占用2比特，定义了RTP的版本。

目前所用的版本V=2，版本1用于RTP 草案。

填充位（P）：占用1比特，当填充位被设置成1时，在标题域的最后将有一个或多个附加的字节，附加的最后一个字节表示附加字节的长度。

填充位使用在一些加密算法中，当下层网络数据包携带了多个RTP包时也需要用到填充位。

扩展位（X）：占用1比特，当扩展位被设置成1时，一个标题扩展域会加在RTP标题域的后面。

CSRC数（CC）:占用4比特，定义了在标题域中包含的CSRC标识符数目。

标记（M）：占用4比特，标记的解释由具体的应用来定义。

有效载荷类型（PT）：占用7比特，定义了RTP负载的格式。

RTP可支持128种不同的有效载荷类型。

对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等等。

如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。

下表列出了目前RTP所能支持的声音有效载荷类型。

表目前RTP所能支持的声音有效载荷类型对电视流，有效载荷类型可以用来指示电视编码的类型，例如motion JPEG, MPEG-1，MPEG-2或者H.231等等。

发送端也可以在会话或者期间随时改变电视的编码方法。

下表列出了目前RTP所能支持的某些电视有效载荷类型。

表目前RTP所能支持的声音有效载荷类型序列号：占用16比特，每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按序列号顺序处理信息包。

例如，接收端的应用程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数据。

序列号的初始值是随机的，对加密传输来讲，即使信息源没有被加密，信息包流经过传输后被加密，不可预料的序列号初始值使得对加密的攻击更为困难。

时间戳(Timestamp)：占用32比特，表示RTP数据信息包中第一个字节的采样时刻(时间)。

为了便于同步和延时抖动的计算，时间戳从一个单调线性递增的时钟获得，并且该时钟的分辨率对于同步和计算包到达时间的抖动是足够的。

时钟频率与有效载荷类型有关，可以在每个应用中静态定义，也可以用非RTP方式动态定义。

对于周期产生的RTP信息包，数据分组的标称采样时间是由采样时钟获得，而不是由系统时钟决定。

例如，对于一个音频信号，时间戳可设置为每个采样周期加1，如果一个应用程序读取了50个采样周期的数据块，时间戳就应该增加50，无论该数据块最终是被丢弃还是被重传。