计算机应用研究
APPLICATION RESEARCH OF COMPUTERS
2000　Vol.17　No.2　P.6-8



网络多媒体实时传输协议浅析
高旭　沈苏彬　顾冠群
摘 要 对目前广泛使用的实时传输协议RTP作了简单的介绍与分析，并指出该协议存在的问题及在大规模会议中的解决途径。在此基础上，通过一个多媒体会议系统实例分析了RTP协议的具体实现。
关键词 RTP RTCP 多媒体会议 组播
1 引言
　　从80年代中期到现在，网络多媒体应用方兴未艾，无论在科学研究还是工程应用都取得了一批骄人的成果。在IETF组织中，仅仅与多媒体会议系统研究有关的工作组就有许多，如负责会议控制的MMUSIC工作组和分管音频、视频传输研究的AVT工作组。ITU-T也有专门研究多媒体会议的SG15工作组，并且推出了H.3XX系列的建议标准，特别是H.323标准采用RTP作为传输协议。在工程应用领域，视频会议系统、远程教学、视频点播和软件分发等显示了实时多媒体应用的强大生命力。
　　当然，目前多媒体应用还存在许多问题，其中关键是现有网络并不提供对实时应用的有效支持，如实时传输、服务质量保证等。在已有TCP和UDP协议无法提供有效服务的情况下，人们提出了一些新型高层协议，其中实时传输协议RTP是网络多媒体应用的核心协议。
　　RTP协议[1]是IETF的AVT工作组于1996年初公布的标准，目前已得到了广泛的应用。下面我们将介绍RTP协议的核心内容，分析存在的主要问题和可能的解决途径，并以多媒体会议为实例讨论RTP的具体实现方法。
2 RTP协议
2.1 RTP协议简介
　　RTP协议是专门为交互式话音、视频、仿真数据等实时媒体应用而设计的轻型传输协议，它为应用提供端到端的实时网络传输。但RTP协议本身并不提供对实时媒体应用的服务质量保证，需要下层协议提供支持。
　　RTP协议由紧密相关的两部分组成：负责媒体数据传输的RTP协议和负责反馈控制、传输监测的RTCP协议。RTP主要完成IP分组网络上实时多媒体数据的传输，如实时话音和视频。为此，RTP分组头中包含了负载类型标识、顺序号、帧结束标志和时间戳等字段，以助于媒体同步、丢失检测和分组标识。
　　RTCP控制分组和RTP媒体数据分组同属于一个群组，但使用不同的协议端口号来区分。群组的发送方和接收方都周期组播RTCP分组，来提供实时重传需要的不同服务。如参加成员用RTCP分组的源描述符(SDES)标识，接收方用RR发送QoS报告，发送方以SR来辅助媒体之间的同步等。这些控制信息对基于发送方的速率自适应、网络监控和会议控制都很关键。
　　由于RTP协议利用了组播技术，所以可以在小规模的(几个成员)会话到大规模(几百个成员)范围内使用。而随着多媒体应用需求的继续高涨，成千上万成员规模的多媒体应用也会很快实现。甚至有人建议，在将来的有线电视网络中也采用RTP协议传输数据。RTP协议在网络多媒体协议栈的位置如图1所示[2]。

图1 网络多媒体协议议栈
2.2 RTP协议的设计目标
　　从RTP最初的设计思想来看，主要为了实现如下几个目标[3]：
　　●轻型的传输协议。RTP提供端到端的实时媒体传输功能，但并不提供机制来确保实时传输和服务质量保证，协议本身相对轻型、快捷。由于RTP没有像TCP/IP那样完整的体系框架，只是一个轻型的传输协议，主要与具体应用结合在一起来实现。
　　●灵活性。体现在把协议机制与控制策略的具体算法分开。协议本身只提供完成实时传输的机制，对控制策略的有关算法实现不作具体规定。开发者可以根据不同的应用环境，选择实现效率较高的算法与合适的控制策略。
　　●协议独立性。RTP协议与下层协议无关，可以在UDP/IP、IPX、ATM的AAL层上实现。
　　●扩展性。既支持传统的单播(Unicast)应用，又支持新出现的组播(Multicast)应用。
　　●控制信息与媒体数据分离。RTCP控制分组采用与RTP媒体数据分组不同的“带外”方式传送。
　　●安全性。RTP协议在设计上考虑到安全功能，支持对数据加密和身份鉴别认证功能。
2.3 RTP协议的分组格式
　　在RTP分组头中，有几个与实时传输紧密相关的重要字段：顺序号、时间戳和源标识。
　　顺序号是一个16比特的序列空间，其初始值随机产生。每个RTP数据分组都把前一个分组的顺序号加1作为自己的顺序号。接收方通过检测收到的分组顺序号可以判断是否有分组丢失，并可重新恢复发送时的分组顺序。
　　时间戳为32比特，是数据分组第一个字节的采样时间。这个采样时间要求从一个时间单调线性增长的时钟获得，以便于同步和延时抖动的计算。数据分组的标称采样时间从采样时钟获得，而不是读取系统时钟。时间戳的初始值也是随机产生的，同时产生的几个相邻分组可以有相同的时间戳，如一个视频帧的相邻数据分组。
　　同步源标识SSRC占用32比特，是随机选择的，但要求同一个RTP会话中的同步源标识唯一。为此，在随机产生SSRC标识时，还要考虑到如何检测和解决SSRC碰撞的问题。在RTP文本中有避免冲突的具体算法。
2.4 RTP翻译器和混合器
　　RTP在接收方和发送方之间引入了两种类型的中间节点：翻译器和混合器(Mixers)。
　　混合器接收来自一个或多个发送方的RTP数据块，并把它们组合成一个新的RTP分组继续转发。这种组合数据块将有一个新的SSRC 标识，具有新标识的特别发送方被作为特别信源加入到RTP数据块中。因为来自不同特别发送方的数据块可以非同步到达(它们可以经不同的路径经过这个网络)，所以混合器改变了该媒体流的临时结构。混合器的典型例子是将某个多点会议的多个音频源组合成一个音频流转发给所有接收方。
　　与混合器不同，翻译器只改变数据块内容，而并不把媒体流组合在一起。翻译器只是对单个媒体流进行操作，可能进行编码转换或者协议翻译。典型的例子是多媒体会议中不同端系统之间的视频编解码转换器，以及在多媒体应用跨越内部网防火墙时的过滤器。
3 RTCP协议
　　与RTP同时存在的还有一个控制协议，称为RTCP。它把传输状态信息发送给所有与会者以进行媒体流性能和质量的监测。发送方也可以用它来确保SSRC标识符的唯一性。RTCP协议主要依靠在所有成员之间周期性地传输控制分组来实现控制监测功能，它要求下层协议必须提供时间和控制分组的复用功能，如UDP协议可以提供不同的端口号。
3.1 RTCP的功能
　　RTCP主要有下列四大功能，前三项是所有系统都支持的功能，最后一项是可以选择的功能。
　　●提供数据传输质量的反馈信息，主要通过发送方报告(SR, Sender Report)和接收方报告(RR, Receiver Report)来实现。这些反馈信息与流量控制和拥塞控制密切相关，也可以直接用于故障诊断。
　　●对每一个RTP信息源，RTC带有一致的传输层标识，称为通用名CNAME(Canonical Name)。当同步源标志SSRC在由于冲突而发生改变时，接收方需要CNAME标识来区分多个媒体流中给定应用的应用成员。
　　●当前参加成员的动态估计，可以用来计算数据发送速率，并且在成员动态变化时对速率进行动态地调整以合理利用网络资源。
　　●传送最少量的控制信息以保证系统可以容易地扩展成为大规模的松散耦合系统。
3.2 RTCP分组的传输间隔
　　RTP协议具有很好的缩放性，允许应用从几个人的小规模系统扩展成上千人的大规模系统。如果每个参加者发出的报告分组是速率固定的，那么随着系统规模的增加，控制分组的数量就会线性增长。由于网络带宽资源的有限，相应的数据分组就要减少，从而直接影响用户最关心信息的传输。所以控制信息分组应该限制在整个系统带宽的某个比例之内，以提高应用的有效带宽，RTCP协议建议以整个会话可用带宽的5％为上限。
3.3 RTCP分组类型
　　RTCP主要有五种分组类型，它们携带不同的控制信息。发送方报告SR，是来自各活跃发送者的传送和接收统计。接收方报告RR，是来自各非活跃发送者的接收统计。源描述分组SDES，包括CNAME。结束参与指示分组BYE和特别应用功能分组APP。
　　多个RTCP分组可以连接在一起构成混合分组。在混合分组中第一个RTCP分组通常必须是一个报告分组，以帮助进行分组头的确认，甚至在没有数据发送或接收时也应如此。这时发送空的RR，即使仅有的另一个RTCP分组是BYE。
　　在每个混合RTCP分组中必须包括一个含有CNAME项的SDES分组。SDES分组也可能包括其它的源描述项，这要根据特别的应用要求，并同时考虑带宽的限制。
　　在具体实现RTP协议时，到达的未知类型RTCP分组会被忽略。增加的RTCP分组类型可以在Internet指定成员机构(IANA)中注册，以获得合法的类型号。
4 RTP协议分析
　　RTP协议既不提供资源预留，也不提供QoS支持，但通过RTCP控制报文可以为质量控制提供相关辅助信息。应用还需要依靠其它协议来满足服务质量方面的要求。
　　RTP报文头的开销在低速链路上过大，如RTP＋UDP＋IP＝40字节/分组。目前采用RTP头压缩可以降到24字节/分组，这种压缩在低速链路上最好采用逐步压缩方法为好。此外，目前RTP采用的组播模型广播太多，IETF的AVT工作组正在着手相关的改进工作。
　　RTCP主要完成松散的会话控制、QoS报告和媒体同步。在RTP协议文本中提出了主机加入到一个RTP组播会话中计算RTCP分组发送速率的算法。这个算法允许加入成员从一个到百万数量级，然而当加入成员达到很大规模并且成员具有较快的动态变化性时，就会产生一些问题，如网络拥塞、状态保存和传输延时。
　　在很多情况下，用户的访问接入带宽远小于网络带宽。在某一时刻有许多成员同时加入的情况下，单纯通过倾听来估算群组规模会很不准确，因为每个同时加入的成员都无法估计到同时加入的成员数目。其结果将在低速的访问链路上产生RTCP分组泛滥，导致网络拥塞和分组丢失。
　　此外，为了估算群组规模，每个主机都要倾听组播分组来计算加入成员的数目。而为了保证不重复计算同一成员，必须保存成员的唯一标识SSRC。当群组规模很大时，保存的SSRC数目也相应增长，需要的内存量也会较大。
　　当群组规模变大，RTCP报告的发送间隔也变大。这个间隔可能会超过群组成员的有效期，从而导致某些成员的QoS报告不真实，甚至完全失去价值。
　　RTP协议遇到的关键问题是RTCP分组的泛滥，主要发生在大量成员同时加入到一个RTP组播会话时。目前已经有一些初步的研究成果，如Sharma等提出了如何平衡软状态定时器设置与链路容量和状态数量的变化，他们主要研究点到点的情况。此外，在服务定位协议(SLP)中提出了重置算法来控制群组的拥塞。Henning[4]等人提出解决RTCP分组泛滥的自适应定时器算法，称为定时器重置(Reconsideration)算法。在数学分析和评价该算法的同时，也采用了仿真来验证算法的高性能。
5 RTP实例分析
　　我们对劳伦斯伯克利实验室的Vic2.8[5]视频工具作简单分析，以探讨RTP的实现问题。
　　通常RTP协议并不作为一个独立的协议层次来实现，而是作为应用的一部分予以实现。在Vic工具源代码中与RTP最相关的是rtp.h和session_rtp.cc。rtp.h中主要按照RFC1889和RFC1990的规定，定义了标准的视频和音频编码数据结构、RTP和RTCP分组头、SR和RR分组格式和ntp时钟等。RTCP协议本身主要由session_rtp.cclai实现，它定义了对RTCP分组的几个处理函数，如分组分析判断、分组接收处理(RR)和分组发送处理(SR)等。RTP对媒体数据的处理影响到许多程序，如建立网络连接时套接口(Socket)的选择、媒体数据的容错、加密等。
　　目前对RTP协议的实现还没有相应的规范，RTP本身只是一个协议框架，可以有非常灵活的实现方式。现在许多厂家，如FVC、PictureTel、VCON、Intel和Cisco等都有支持RTP标准的产品问世，但如何保证不同厂家产品的互操作却是一个大问题。对遵循ITU-T标准的多媒体系统来说，已经有国际多媒体远程会议委员会IMTC来协调标准实现的互操作问题。对于RTP协议而言，互操作的代码实现依然是一个未解决的问题。
6 结论
　　尽管RTP协议到目前为止还仅仅是一个RFC标准，还存在一些问题，但它在多媒体应用研究人员和产业界的地位非同一般。首先，一些Internet应用系统，特别是MBone上的多媒体应用系统，都采用了RTP作为应用支撑协议。如Vic 、RAT、IVS和 Vat等MBone多媒体会议工具中都实现了RTP。其次，有着强大电信企业背景的ITU－T标准化组织，在制定Internet上多媒体应用标准时也采用了RTP协议作为多媒体流的运输协议，如H.323标准。可以说，RTP协议已经成为以多媒体会议为典型代表的网络多媒体应用的事实标准。
本项目获国家自然科学基金项目资助；本项目获江苏省应用基金资助
高旭（东南大学计算机科学与工程系 南京 210096）
沈苏彬（东南大学计算机科学与工程系 南京 210096）
顾冠群（东南大学计算机科学与工程系 南京 210096）
参考文献
1，RFC 1889, H. Schulzrinne, S. Casner, R. Frederik, V. Jacobson, RTP: A transport protocol for real-time applications
2，GMD Fokus, User Handbook of the Multimedia Internet terminal (MINT), 2nd November 1998
3，H. Schulzrinne, Real-time Multimedia Services in the Internet, GMD Fokus, April 1996
4，J. Rosenberg, H. Schulzrinne Timer reconsideration for enhanced RTP scalability, Internet Draft, IETF, July 1997
5，Steven McCanne and Van Jacobson. Software on-line, ftp://ftp.ee.lbl.gov/conferencing/vic
收稿日期：1999年9月18日
