实时传输协议 RTP

流媒体是指Internet上使用流式传输 技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式：下载和流式传输。

下载情况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播结束，也就 是用户至少要在直播结束后才能看到直播节目，所以用下载方式不能实现直播。

流式传输是指传输之前首先对多媒体进行预处理(降低质量和高效压缩)，然后使用缓存系统来保证数据连续正确地进 行传输。使用流式传输可以边下载边观看流媒体节目，使传输那些事先不知道或无法知道大小的媒 体数据(如网上直播、视频会议等) 成为可能。

目前，支持流媒体传输的协议主要有：实时传输协议RTP、实时传输控制协议RTCP和实 时流协议RTSP(Real-time Streaming Protocol) 等。

实时传输协议 RTP(Real-time Transport Protocol)

RTP是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。 RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。

RTP 为实时应用提供端到端的运输，但不提供任何服务质量的保证，服务质量由RTCP来提供。多媒体数据块经 压缩编码处理后，先送给 RTP 封装成为 RTP 分组，再装入运输层的 UDP 用户数据报，然后再交给 IP 层。

RTP的协议层次

从应用开发者的角度看，RTP 应当是应用层的一部分。在应用的发送端，开发者必须编 写用 RTP 封装分组的程序代码，然后把 RTP 分组交给 UDP 插口接口。在接收端，RTP 分组通过 UDP 插口接口进入应用层后，还要利用开发者编写的程序代码从 RTP 分组中把应用数据块提取出来。

RTP 封装了多媒体应用的数据块。由于 RTP 向多媒体应用程序提供了服务（如时间戳和序号），因此也可以将 RTP 看成是在 UDP 之上的一个运输层的子层。

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端口对中的奇数端口。

RTP分组只包含RTP数据，而控制是由另一个配套使用的RTCP协议提供。 RTP在1025到65535之间选择一个未使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个奇数UDP端口号。端口号5004和 5005分别用作RTP和RTCP的默认端口号。

RTP数据包格式

在RTP分组的首部中，前12个字节是必须的，12字节以后的是可选的。完整的RTP 数据包格式如下：

前12个字节在每一个RTP packet中都存在，而一系列的CSRC标记只有存在Mixer时才有。

   version (V): 2 bits
      标明RTP版本号。协议初始版本为0，RFC3550中规定的版本号为2。

   padding (P): 1 bit
      如果该位被设置，则在该packet末尾包含了额外的附加信息，附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因 为一些加密机制需要固定长度的数据块，或者为了在一个底层协议数据单元中传输多个RTP packets。

   extension (X): 1 bit
      如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。

   CSRC count (CC): 4 bits
      在固定头部后存在多少个CSRC标记。

   marker (M): 1 bit
      该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。

   payload type (PT): 7 bits
      标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。

   sequence number: 16 bits
      序列号，每个RTP packet发送后该序列号加1，接收方可以根据该序列号重新排列数据包顺序。

   timestamp: 32 bits
      时间戳。反映RTP packet所携带信息包中第一个字节的采样时间。

   SSRC: 32 bits
      标识数据源。在一个RTP Session其间每个数据流都应该有一个不同的SSRC。

   CSRC list: 0 to 15 items, 32 bits each
      标识贡献的数据源。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。

santi 发表于 2006-3-8 20:24:00

另一处引用：
协议结构

1	2	3	8	9	16bit
V	P	X	CSRC Count	M	Payload Type
Sequence number				Timestamp
SSRC				CSRC (variable 0 – 15 items 32bits each)

• V ― 版本。识别 RTP 版本。
• P ― 间隙（Padding）。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。
• X ― 扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。
• CSRC Count ― 包含 CSRC 标识符（在固定头后）的编号。
• M ― 标记。标记的解释由 Profile 文件定义。允许重要事件如帧边界在数据包流中进行标记。
• Payload Type ― 识别 RTP 有效载荷的格式，并通过应用程序决定其解释。Profile 文件规定了从 Payload 编码到 Payload 格式的缺省静态映射。另外的 Payload Type 编码可能通过非 RTP 方法实现动态定义。
• Sequence Number ― 每发送一个 RTP 数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。
• Timestamp ― 反映 RTP 数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。
• SSRC ― 同步源。该标识符随机选择，旨在确保在同一个 RTP 会话中不存在两个同步源具有相同的 SSRC 标识符。

　 　CSRC ― 贡献源标识符。识别该数据包中的有效载荷的贡献源。

RTP是目前解决流媒体实时传输问题的最好办法，存在一些开放源代码的RTP库，如LIBRTP、JRTPLIB等。JRTPLIB是一个面向对象的 RTP库，它完全遵循RFC 3550（RFC 1889已过时）设计，是一个用C++语言实现的RTP库。

实时传输控制协议 RTCP (RTP Control Protocol)

RTCP 是与 RTP 配合使用的协议。
RTCP 协议的主要功能是：服务质量的监视与反馈、媒体间的同步，以 及多播组中成员的标识。RTCP 分组也使用 UDP 传送，但 RTCP 并不对声音或视像分组进行封装。可将多个 RTCP 分组封装在一个 UDP 用户数据报中。RTCP 分组周期性地在网上传送，它带有发送端和接收端对服务质量的统计信息报告。

RTCP使用的五种分组类型

结束分组 BYE 表示关闭一个数据流。
特定应用分组 APP 使应用程序能够定义新的分组类型。
接收端报告分组 RR 用来使接收端周期性地向所有的点用多播方式进行报告。
发送端报告分组 SR 用来使发送端周期性地向所有接收端用多播方式进行报告。
源点描述分组 SDES 给出会话中参加者的描述。

==================================================================================

RTP（Real-timeTransportProtocol）是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。实时传输控制协议RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

6.2.1 RTP数据传输协议

　RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。

2.1.1 RTP固定头
　RTP 头格式如下：
　-----------------------------------------------------------------------------------------------
　|V=2|P|X| CC |M| PT | 系列号 |
　-----------------------------------------------------------------------------------------------
　| 时标 |
　-----------------------------------------------------------------------------------------------
　| 同步源标识(SSRC) |
　-----------------------------------------------------------------------------------------------
　| 作用标识 (CSRC) |
　| .... |
　-----------------------------------------------------------------------------------------------

　开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
　2.1.2 复用 RTP 连接
　为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
　如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
　RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
　RTP混合器不能将不兼容媒体流合并成一个流。
　在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。

2.1.3 对RTP头特定设置的修改
　可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
　其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变。