RTP/RTCP基础

本文文档下载地址：http://download.csdn.net/detail/mandagod/9825045

1．   RTP/RTCP协议概述

实时传输协议(RTP)和实时控制协议(RTCP) 是为网上传送实时多媒体数据开发的协议，RTP和RTCP协议的详细规范定义在RFC3550(2003)中，并取代1996年发布的RFC 1889。H.263++提供RTP打包服务的格式描述文档为RFC2429， 为MPEG-4提供RTP打包服务的格式描述文档为RFC3016，而为H.264提供RTP打包服务的格式描述文档为RFC3984。

RTP提供端对端的实时数据传输服务

RTCP协议用于监视和控制实时数据的传输

   

实时传输协议(Real-timeTransport Protocol，RTP)

 

位于应用层和UDP之间，用于传输包括声音和影视等实时数据的协议。实时传输协议早期主要针对网上的多媒体广播应用，如用于单目标广播服务(单个广播源向单台接收机)和多目标广播服务(单个广播源向多台接收机)，通常与监视传输的RTCP联合使用。现在已广泛用在其他视听服务中。

 

实时控制协议(Real-TimeControl Protocol, RTCP)

 

与实时协议(RTP)一起工作的传输控制协议，用于在发送者和接收者之间交换控制实时数据传输的消息。RTCP每隔一定时间传送内含控制消息的数据包，用于测定向接收者传送的信息的质量

 

2．   RTP协议

实时传输协议(RTP)为在网上传输声音和视像数据定义标准的数据包，广泛用在包括声音点播(AoD)、影视点播(VoD)、因特网电话和电视会议的多媒体应用中。

1.   RTP协议概要

RTP协议提供端对端的实时声音和视像数据的传输，而对声音和视像数据的压缩和编码格式没有限制，可支持许多格式的声音和视像，如PCM(脉冲编码调制)、MP3、GSM(全球数字移动通信系统)等格式的声音、AVI和MPEG等格式的影视，也可用来传输专有文件存储格式的声音和影视数据。

 

RTP允许给每个广播源分配单独的RTP数据包流。例如，有两个团体参与的电视会议，两台摄像机和 两个麦克风生成4个RTP数据包流。许多流行编码技术(如MPEG影视)在编码过程中都把声音和视像复合在一起以形成单一流媒体，因此也可只生成一个 RTP数据包流。

 

RTP (Real-time TransportProtocol)名为“实时传输协议”，其实并非真正的“实时传输”，应理解为“实时数据”的传输协议。因为RTP本身不提供任何机制来确保把实时数据及时送到接收端，不保证在递送过 程中不丢失数据包，也没有使用防止数据包次序被 打乱的方法，但提供了减少或消除抖动、视听数据 同步和视听数据流复合的方法。因此，RTP协议需要使用RTCP来提高服务质量。

 

2.   RTP协议原理

 

使用RTP协议的多媒体应用程序运行在应用层，而执行RTP协议的程序运行在应用程序和UDP之间， 目的是利用UDP的端口和检查和等功能。

 

RTP既可看成应用层的子层，也可看成传输层的子层， 如下图是RTP在协议套中的位置，还有是以太网的数据包封装。

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

 

在发送端，开发人员必须把执行RTP协议的程序编写到创建RTP数据包的应用程序中，然后应用程序把RTP数据包发送到UDP套接口(socket)，通过执行UDP协议的程序生成UDP数据包。

 

在接收端，RTP数据包通过UDP套接口输入到应用程序，因此开发人员必须把执行RTP协议的程序编写到从RTP数据包抽出媒体数据的应用程序中。

3.   RTP数据包头结构

H.263++提供RTP打包服务的格式描述文档为RFC2429， 为MPEG-4提供RTP打包服务的格式描述文档为RFC3016，而为H.264提供RTP打包服务的格式描述文档为RFC3984。H.264确定将Slice层以下的语法元素作为RTP的净载加以传输，任何Slice层以上的信息均不在RTP流中传送，而是采用更加可靠的传输方式。

 

RTP包头主要由4个域组成, 至少有12个字节（CSRC可选）：有效载荷类型、顺序号、时间戳和同步源标识符；通常头信息部分的版本号2bit设置为2, 1bit的填充位设置为0， 1bit的扩展位设置为0，4bit的CSRC计数器设置为0，因此常见的RTP分组开头部分为0x80；最大有效载荷为MTU-12字节。

（1）有效载荷类型域：7位，可支持128种不同的有效载荷类型：

 接收端如果无法解析负载类型，就必须丢弃该分组，在RTP会话过程中，RTP源可以改变负载类型，这样可以根据用户需求或网络状况动态调整服务质量Qos。

 

对于声音数据，这个域用来指示声音使用的编码类型，如PCM、G.721等。如果发送端在会话或广播的中途决定改变编码方法， 发送端可通过改变这个域的内容来通知接收端。RFC3551(2003)指定的部分声音有效载荷类型。

对于视像数据，有效载荷类型用来指示视像编码类型，如MPEG- 1，H.261，MPEG-2，和MPEG-4。发送端也可以在会话期间改变视像的编码方法。RFC3551(2003)指定的部分视像有效载荷类型。

（2）顺序号：16位



每发送一个RTP数据包顺序号加1。接收端可用它来检查数据包是否有丢失，并按顺序号来处理数据包。例如，接收 端的应用程序接收一个RTP数据包流，这个RTP数据包在顺序号86和89之间有一个间隔，这就表明数据包87和88已经丢失，需要采取措施来处理。还有做重建序列包的作用。序列号的初始值是随机的（不可预测的），即便是在本身不加密的情况下，对加密算法泛知的普通文本攻击也会更加困难。

 

（3）时间戳：32位



反映RTP数据包中第一个字节的采样时刻。接收端可用这个时间戳来去除由网络引起的数据包的抖动，并可为播放提供同步功能。时钟频率依赖于负载数据格式，并在描述文件中进行描述，也可以通过RTP方法对负载格式动态描述。

如果RTP是周期性产生的，那么将使用采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块，那么对每个快，时间戳的值增加160。时间戳的初始值应当是随机的，就像序号一样。几个连续的RTP包如果同时产生的，如果属于同一个视频帧的RTP包，将有相同的时间戳。

（4）同步源标识符(SSRC)：32位

 

随机选择的32位号码，用于标识RTP数据包流的起源，在RTP会话期间的每个数据包中都有一个明确的SSRC号码。

用于识别同步源，标识符被随机产生，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC信息。尽管多个源选择同一个SSRC识别符的概率很低，所有RTP实现工具都必须检测和解决冲突。若一个源改变本身的源传输地址，必须选择新的SSRC识别符，以避免被当作一个环路源。

（5）贡献源标识符(CSRC)：每个标识符用32位

 

用于标识有效载荷的贡献源。贡献源的数目最多为15个， 其数目由CC域中的数值决定。CSRC识别符由混合器插入，并列出所有贡献源的SSRC识别符。例如语音包，混合产生新包的所有源的SSRC标识符都被列出来，以在接收端处正确指示参与者。

 

（6）其他域



①    本号(V): 2位，标识RTP版本号；②填充(P): 1位，其值设置为1，表示数据包结尾有附加的可用于加密的字节，但不属于有效载荷；③扩展(X): 1位，其值设置为1， 表示有一个扩展包头；④贡献源数目(CC): 4位；⑤标记(M): 1位，用于标记一些重要事件，如音频，视像帧的边界。其含义由应用层定义，通常为0；应用层可以定义更多的标志位，也可以不定义标志位，净荷类型字段的比特数也相应改变。

1.   分析Slice的大小满足MTU要求

    如果RTP协议在IP网络上传输（其他网络可能不同），MTU最大传输单元为1500字节。在使用IP/UDP/RTP的协议层次结构时候，至少包括20字节的IP 头，8字节的UDP头以及12字节的RTP头。这样头信息至少要占用40字节，那么RTP的载荷的最大尺寸就为1460字节。

Slice的大小尽可能接近MTU　size以便利用网络资源。如果RTP载荷大于1460字节，并且没有将数据封装进RTP包之前进行分割，那么会产生大于MTU的RTP包。这样在发送的时候会在IP层分割成几个小于MTU尺寸的包进行传输，这样就无法检测到是否有数据包丢失了，因为IP和UDP协议都没有提供分组到达的检测。

对于H.264来说，NAL包是传输的基本单位，NAL包中对多包含一个slice的数据，如果NAL包大于RTP载荷的最大尺寸就需要对NAL包进行分割；反之NAL包太小，则可以对NAL包进行合并。

NAL单元的RTP打包，RFC3984标准中描述了针对H.264的RTP负载类型，主要有三种，单一NAL分组(SNU)， 聚合分组(包括STAP和MTAP)，分割分组(FU)等。

 

RTP负载类型表

类型

包名称

负载内容

0

undefined

 

1~23

NAL unit

Single NAL unit packet per H.264

24

STAP-A

Single-time aggregation packet

25

STAP-B

Single-time aggregation packet

26

MTAP16

Multi-time aggregation packet

27

MTAP24

Multi-time aggregation packet

28

FU-A

Fregmentation unit

29

FU-B

Fregmentation unit

30~31

undefined

 

3. RTCP协议

由于RTP没有提供服务质量保障机制，因此应用程序要用RTCP来监视和控制实时数据的传输。

1.   RTCP协议概要

RTCP的主要功能是为收发两端的应用程序提供有关会话传送质量的数据包；

每个RTCP数据包不是封装声音数据或视像数据，而是封装收发两端的统计信息，包括实时数据的数据包数目、传输过程中丢失的数据包数目、数据包的抖动和往返的延迟时间等。

 

RTCP规范没有指定应用程序如何使用控制数据包中的信息，这完全取决于应用程序开发人员。例如，发送端可根据这些数据包中的信息来修改视听数据编码器的输出速率，接收端可用来判断问题是本地的、区域性的还是全球性的，网络管理员也可用数据包中的信息来评估网络在多媒体应用中的性能。

 

使用RTCP提高实时数据传输质量的原理，RTP会话期间，如图；

 

每个参与者周期性地向所有其他参与者发送RTCP控制数据包；

 

对于使用RTP的互动应用或广播应用，属于这个会话的所有RTP和RTCP数据包都使用相同的网络地址(如广播地址) 传送，但使用不同的端口号把RTP数据包和RTCP数据包区分开来，RTCP用的端口号是RTP端口号加1；

 

收发两端的应用程序使用这些数据包中提供的信息来监视服务质量，以便决定下一步该做什么工作。

 

当有许多接收者参与同一个会话时，RTCP数据包的数目就非常多，这就要限制发送RTCP数据包的时间间隔，以减少网络上的交通。

 

通常，执行RTCP协议的软件试图将RTCP的交通限制在会话带宽的5%。例如，发送端以2 Mbps的速率发送视像， RTCP的交通将被限制在100 kbps以内。

2.   RTCP数据包类型

实时控制协议(RTCP)定义了五种类型的控制数据包，用于携带各种控制信息。这些控制数据包统称 为“RTCP数据包(RTCPpacket)”，它们使用与其他数据包相同的方法发送；

（1）SR(Sender report)—发送者报告



用于给参与者发送实时数据的传送摘要，并接收来自 参与者的统计信息。传送摘要包括RTP流的同步源标识符，当前的时间，发送的数据包数目和发送的字节 数等。

（2）RR(Receiver report)—接收者报告



用于接收来自参与者的统计信息，包括丢失的数据包、 最后接收到的顺序号和平均的抖动间隔。

 

（3）SDES(Source description items)—RTP源描述项



包含标识RTP源的标识符，称为“规范名称(canonical name，简写为CNAME)”。由于同步源标识符(SSRC)是随机生成的，当出现冲突或应用程序重新启动时， SSRC有可能变化，而接收者需用CNAME来跟踪。

 

（4）BYE(Goodbye)—再见；



（5）APP(Application-specificfunctions)—特定应用功能。

 

4．   RTP协议的安全传输

RTCP本身不提供加密或认证方法，如有需要可使用RTP的扩展协议(RFC 3711)，称为安全实时传输协议(SecureReal-time Transport Protocol，SRTP)。

 

注：在使用RTCP协议的过程中，如在IPTV这样的大型应用中，网上已有实践报告和文章指出，在两个RTCP报告之间会产生很长的时延， 这可能会使发送者根据接收者报告的消息做出的评估与实际会话状况 有出入，因此需要有比较好的方法来解决。