嘉应学院毕业论文(设计)
第一章 引言
1.1实时数据传输的发展
我们已经步入一个高速发展的信息社会，Internet已经成为很多人生活不可缺少的一部分。Internet中流动的“比特”所代表的内容已从原来的数据逐渐向多媒体演变。随着IPv6，RSVP,RTP/RTCP一系列协议的出现，在Internet上实现多媒体通信成为可能。IPv6解决了IPv4地址资源有限，不能控制带宽等问题，RSVP(资源预留协议)，RTP/RTCP（实时传输/控制协议）使Internet从理论上具备了处理实时 业务的能力，解决了媒体同步问题和满足多媒体通信业务的要求。越来越多的实时多媒体应用的出现，极大的丰富了人们生活，如成为这几年的热点的IP电话，另外还有VID、远程网络教学、远程网络诊断和网络多媒体会议业务、多媒体消息型业务等。
1.2国内外研究状况
早在20世纪70年代末80年代初，如何在分组上实时传输语音就是一个很活跃的研究方向，到了九十年代初这个方向研究又变得异常活跃。1992年3月，IETF（Internet Engineering Task Force）在San Diego召开的会议是分组网上第一次大规模的音频多播应用。会议使用的音频传输软件主要是Vat（Visual Audio Tool）,它是由LBNL（Lawrence Berkeley National Laboratory）网络研究小组开发的一个音频会议工具，该小组还开发了视频工具vic和白板工具wb。会议还使用的另一个音频软件是NeVoT(Network Voice Terminal),它是H.Schulzrinne等人在90年代初开发出来的。该软件最初使用的是vat协议，但是在RTP协议制定出来后也开始支持RTP协议了。还有其他大学，研究组织研究 开发出来的音频工具TAT（Robust Audio Tool），会议目录工具SDR(session directory)，CU-SeeMe音频会议工具等等。
在国内，清华电子工程系网络研究所多媒体通信课题组也在这方面做了大量的研究，并开发出了Cool-audio、Cool-Video、Cool-Meeting等一系列软件。其中Cool-audio网络电话于1998年推出，它是我国第一套自主版权且最有影响的Internet电话软件。另外，东南大学计算机系，北京邮电大学电信工程学院和华中科技大学等研究机构也在这方面做出了大量的研究工作。北京的微软亚洲研究院的网络多媒体组正在做SMART音/视频传输(SMART A/V Delivery)等项。但是总的来说，国内的研究水平要远远落后于国外。可以说，
2
嘉应学院毕业论文(设计)
实时多媒体数据传输研究已经有了长足的进步，制定了许多相关的传输协议，例如：RTP（Real-time Transport Protocol）和RTCP(Real-time Transport Control
Protocol),RTSP(Real-time Streaming Protocol),SIP(Session Initiation Protocol)，H.232，RSVP(Resource Reserve Protocol)，服务区分协议（Diff-Serv），多协议标记交换协议（Mulit-Protocol Label Switching，MPLS）等等，这些都是构建当前多媒体通信的主要协议。在这些协议中，RTP和RTCP主要负责实时数据以及实现最基本的传输控制，本设计就是Linux下基于RTP协议的实时音频传输的实现。
1.3实时多媒体数据传输的特点
实现多媒体数据传输的核心是声、文、图等多媒体信息的传输技术，它的一个显著特点是数据量大，并且许多应用对实时性都有比较高的要求，例如，一个多媒体会议系统，我们总是希望发言者的发言能够尽早让收听者收听到，也就是说时延尽量短；另外一个就是我们希望在收听者收听语音信息时，一句话平滑的，即中间没有断点，也就是等时性。这些都是实现实时语音通话应达到的要求。
1.4 TCP不适合传输实时多媒体数据
Internet是建立在TCP/IP之上的计算机网络，它最初是为提供非实时数据业务而设计的。IP协议是面向无连接的，负责主机之间的数据传输，但只提供“尽力而为”（best-effort）的服务，不进行检错和纠错，因此经常发生数据丢失现象。为保证数据的可靠传输，在传输层使用TCP协议，当接收端检测到数据包丢失或错误时，要求发送端重新发送，但这样不可避免地引起传输延时和占用网络带宽。因此传统的TCP/IP协议传输实时音频、视频数据的能力比较差。当然在传输用于回放的视频和音频数据时，TCP也是一种选择。如果有足够大的缓冲区和充足的网络带宽，比如在局域网内，在TCP协议上，接近实时的传输也是可能的。但是在大多数情况下，我们需要再广域网内传输数据，在这种丢包率较高、网络状况不好的情况下，利用TCP协议进行视频或音频通信显然不是很好的一个选择。TCP协议是面向连接的协议，它的重传机制和拥塞控制机制都是不适合用于实时多媒体传输的。下面具体分析网络运行一下TCP和其他可靠传输层协议如XTP不适合实时传输的几个主要原因。
（1）.启动速度慢
即便在网络运行状况良好，没有丢失包的情况下，由于TCP的建立连接需“三次握手”，
3
嘉应学院毕业论文(设计)
因而在初始化的过程中，需要较长的时间。而在一个实时多媒体的应用中，我们期望尽量少的延迟。
（2）.TCP的重传机制
在TCP/IP协议中，当发送方收不到接收方发来的确认，并超过一定的时间，就认定该数据已丢失，这时它将重传丢失的数据包。这一过程将需要一个甚至更多的周期，这种重传机制对于实时性要求较高的多媒体数据传输来说是灾难性的，因为接收不得不等待重传数据的到来，从而造成了延时和断点。
（3）.TCP的拥塞控制机制
TCP拥塞控制机制在探测到有数据包丢失时，它就会减少它的拥塞窗口。另一方面，音频、视频在特定的编码方式下，产生的编码数量是不可能突然改变的，例如，标准的PCM音频需要64Kb/s，加上一些额外控制信息，它不能再低于这个带宽要求的网络上传输。正确的拥塞控制应该是变换音频、视频信息的编码方式，调节视频信息的帧频或者图像的大小。
（4）.报文头的大小
TCP和XTP报文头都比UDP的报文头大，TCP和XTP3.6的报文头为40字节，XTP4.0为32字节，而RTP的固定报文头为12字节，因而它们所能携带的信息占整个报文的比例相对来说比较小。并且这些可靠的传输协议不能提供时间戳和编解码信息，而这些信息是接收方应用程序所需要的，因此它们是不适合进行多媒体信息传输的。
1.5 RTP的引入
基于上一节的分析，我们可以清楚的认识到TCP协议是不适合用来进行传输实时多媒体数据的，因此考虑选择UDP作为RTP的传输层协议。UDP是一种面向无连接的数据报方式，当通信一旦开始，发送方就不断地发送数据而不需要接收端做出确认信息。它取消了重发校验机制，因此能够达到较高的通信速率，但不能保证报文的先后顺序，也不能保证数据传输的可靠性。因为音频、视频码流比传统数据对实时性要求更高，即使少量的时延，对音频、视频播放来说也是无法忍受的，但它们对于少量的包丢失却不太敏感。所以本文在IP网络上建立的实时音频传输系统采用面向无连接的UDP协议进行传输。但是UDP传输的不可靠带来丢包、乱序等问题，所以如果在应用层采用合适的封装方式并增加一些有利于媒体播放的信息进行传输，可以使得接收端在一定程度上弥补传输带来的损失，这就是引入RTP的原因。同时如果收发端能够实时了解网络和传输状况，就可以适当调节自己
4
嘉应学院毕业论文(设计)
的任务，最终使得在接收端能够达到最好的效果，由此引入RTCP传输控制协议对传输状况进行实时监测和报告。
RTP（Real-time Transport Protocol）实时传输协议，是由Internet工程任务组（IETF）的音频/视频传输工作组制定，主要用于VoIP、视频等实时多媒体信息的传输。音频和视频编码信数据均封装在RTP协议数据包中，RTP提供定时信息和数据报序号，供接收方重组数据包，但是RTP本省并不能为按顺序传送数据包提供可靠的传输机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。RTCP（Real-time Transport Control Protocol）实时传输控制协议，它提供服务质量的统计信息及提供传输可靠性的保证和流量的拥塞控制机制。
第二章 RTP/RTCP协议介绍
2.1 实时传输协议的简单介绍
RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。
RTP协议包括RTP（Real-time Transport Protocol）实时传输协议和RTCP（Real-time Transport Control Protocol）实时传输控制协议这两个协议。其中RTP被定义为一对一或一对多的传输情况下工作，实现实时数据的传输，但是它并不提供任何传输可靠性的保证和流量的拥塞控制机制，这些工作将由RTCP来完成。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，所以特别适合传输实时数据。
RTP为交互式 音频、视频等具有实时特性的数据提供端到端的传输。它不是典型意义上的传输层协议，因为它并不具备一个典型传输协议的所有特点。例如：RTP没有连接的概念，它必须建立在底层的面向连接的或无连接的传输协议之上；本身不依赖于特别的地址格式，而需要底层传输协议支持成帧和分段。一般来说，RTP是在传输层协议之上作为应用程序的一部分加以实现的。
在IP网络上，RTP协议一般是运行在UDP之上。首先RTP可以利用UDP的多路复用功能来分别传输RTP数据包和RTCP控制包。其次，RTCP能实时监控数据传输和服务质量，
5
嘉应学院毕业论文(设计)
不需要下层协议来保证实时业务的服务质量。再次，由于UDP的传输时延低于TCP，能与音频和视频流很好匹配，保证了实时性的要求。因此，在实际应用中，RTP/RTCP/UDP用于音频、视频媒体，而TCP用于数据和控制信令的传输。当然，RTP还可以和其他合适的底层网络和传输协议一起工作。例如它也可以在TCP或ATM等其它协议之上工作。如果底层网络支持多点传播的话，RTP还支持使用多点传播向多个目的端点发送数据。下图表示了RTP与各种网络协议的关系。
2.1 RTP与各种网络协议的关系
2.2 RTP协议的三类主要应用
（1）简单的多播音频会议
这里的多播主要指IP网络的多播业务用于语音通信。它通过一个多播地址和一对端口来实现。一个端口用于RTP传输音频数据，另一个端口用于传输RTCP控制包。这个地址和端口的信息要发布给各个与会者。当一个与会者将要发言时，其话音将以每20毫秒为一帧的间隔分成许多音频数据包，并在数据包前加上RTP头，然后按照RTP包头在前，数据在后的顺序将它们封装在UDP包中。RTP包头可以指明语音编程类型（如PCM，ADPCM或LPC），以便发送方在会议过程中改变编码的类型了。
Ineternet和其他报文网络一样，会有丢包，报文失序以及报文的不同时延问题。为
6