精品基于RTP的linux实时语音通信系统的设计与实现毕业论文设计Word格式文档下载.docx

精品基于RTP的linux实时语音通信系统的设计与实现毕业论文设计Word格式文档下载.docx

《精品基于RTP的linux实时语音通信系统的设计与实现毕业论文设计Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《精品基于RTP的linux实时语音通信系统的设计与实现毕业论文设计Word格式文档下载.docx（22页珍藏版）》请在冰豆网上搜索。

ThecurrentflowsthroughtheInternet"

bits"

representedbythecontentsofwhichhavebeengraduallyfromtheoriginaldatatoreal-timemultimediadata,thecharacteristicofthemisveryhighdemandforreal-time.However,theInternetisbasedonTCP/IPcomputernetworks,theinitialdesignoflocationdeterminesitisnotsuitableforreal-timedatatransmission.Therefore,IETFaudioandvideotransmissionworkinJanuary1996issuedforreal-timeapplicationofreal-timetransmissionprotocolRTP/RTCP.RTP/RTCPmakeInternettheoreticallywiththereal-timeabilityofthebusiness,themediasynchronizationproblemsandmeettherequirementsofthemultimediacommunicationservice,theIPtelephone,network,multimediaconference,remotenetworkteachingandremotediagnosis,etcallhaveimportantapplications.

Inthispaper,combiningwiththecharacteristicsofRTP/RTCPhighreal-timeperformance,mainlyforlocalareanetwork（LAN）,isputforwardusingG729aaudiodatacompression,datatransmissionusingortplibrary,developmentofreal-timevoicecommunicationsystemontheLinuxplatform.Thispaperfirstintroducesthesimpleapplicationofreal-timetransportprotocol,RTP/RTCPprotocolareanalyzedindetail.Thenthispaperintroducestheimplementationofsystem,mainlydividedintothreeparts:

audiodataacquisitionandplayback,audiodatadecodingandencodingandaudiopacketssentandreceived.Thelastsimplyexpoundsthesystemscalabilityandprospectsinotherareas.

【Keywords】Realtimeaudiotransmission,RTP/RTCP,audiocompression

前言

随着多媒体网络的发展，RTP/RTCP在众多领域也得到了深入的应用，如VOIP电话、多媒体会议系统等应用的出现，也让语音传输通信技术也得到了迅速的发展。

然而，语音通信需要的实时性是非常高的，而且数据量大。

例如，一个多媒体会议系统，我们总是希望发言者的发言能够尽早让收听者收听到，也就是说时延尽量短；

另外一个就是我们希望在收听者收听语音信息时，一句话平滑的，即中间没有断点，也就是等时性。

这些都是实现实时语音通话应达到的要求。

为此，本人在导师的指导下，详细研究分析了RTP/RTCP协议，结合RTP/RTCP协议高实时性的特点，利用现有的音频编程和网络编程知识，设计和开发了这个基于RTP的linux实时语音通信系统。

目前只实现了单播功能，即点对点的通信。

论文的主要内容如下：

第一章：

引言，主要介绍了实时多媒体数据传输的发展，阐述了TCP不适合多媒体传输的原因并引入了RTP.

第二章：

根据RFC3550官方文档，详细分析了RTP/RTCP协议。

第三章：

介绍了linux下基于RTP的实时语音通信系统实现的基本原理和总体架构。

第四章：

介绍了linux音频编程。

第五章：

讲解了音频传输的实现。

第六章：

介绍了音频解码和编码的实现。

第七章：

总结与展望。

第一章引言

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（InternetEngineeringTaskForce）在SanDiego召开的会议是分组网上第一次大规模的音频多播应用。

会议使用的音频传输软件主要是Vat（VisualAudioTool）,它是由LBNL（LawrenceBerkeleyNationalLaboratory）网络研究小组开发的一个音频会议工具，该小组还开发了视频工具vic和白板工具wb。

会议还使用的另一个音频软件是NeVoT（NetworkVoiceTerminal）,它是H.Schulzrinne等人在90年代初开发出来的。

该软件最初使用的是vat协议，但是在RTP协议制定出来后也开始支持RTP协议了。

还有其他大学，研究组织研究

开发出来的音频工具TAT（RobustAudioTool），会议目录工具SDR（sessiondirectory），CU-SeeMe音频会议工具等等。

在国内，清华电子工程系网络研究所多媒体通信课题组也在这方面做了大量的研究，并开发出了Cool-audio、Cool-Video、Cool-Meeting等一系列软件。

其中Cool-audio网络电话于1998年推出，它是我国第一套自主版权且最有影响的Internet电话软件。

另外，东南大学计算机系，北京邮电大学电信工程学院和华中科技大学等研究机构也在这方面做出了大量的研究工作。

北京的微软亚洲研究院的网络多媒体组正在做SMART音/视频传输（SMARTA/VDelivery）等项。

但是总的来说，国内的研究水平要远远落后于国外。

可以说，实时多媒体数据传输研究已经有了长足的进步，制定了许多相关的传输协议，例如：

RTP（Real-timeTransportProtocol）和RTCP（Real-timeTransportControlProtocol）,RTSP（Real-timeStreamingProtocol）,SIP（SessionInitiationProtocol），H.232，RSVP（ResourceReserveProtocol），服务区分协议（Diff-Serv），多协议标记交换协议（Mulit-ProtocolLabelSwitching，MPLS）等等，这些都是构建当前多媒体通信的主要协议。

在这些协议中，RTP和RTCP主要负责实时数据以及实现最基本的传输控制，本设计就是Linux下基于RTP协议的实时音频传输的实现。

1.3实时多媒体数据传输的特点

实现多媒体数据传输的核心是声、文、图等多媒体信息的传输技术，它的一个显著特点是数据量大，并且许多应用对实时性都有比较高的要求，例如，一个多媒体会议系统，我们总是希望发言者的发言能够尽早让收听者收听到，也就是说时延尽量短；

1.4TCP不适合传输实时多媒体数据

Internet是建立在TCP/IP之上的计算机网络，它最初是为提供非实时数据业务而设计的。

IP协议是面向无连接的，负责主机之间的数据传输，但只提供“尽力而为”（best-effort）的服务，不进行检错和纠错，因此经常发生数据丢失现象。

为保证数据的可靠传输，在传输层使用TCP协议，当接收端检测到数据包丢失或错误时，要求发送端重新发送，但这样不可避免地引起传输延时和占用网络带宽。

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

当然在传输用于回放的视频和音频数据时，TCP也是一种选择。

如果有足够大的缓冲区和充足的网络带宽，比如在局域网内，在TCP协议上，接近实时的传输也是可能的。

但是在大多数情况下，我们需要再广域网内传输数据，在这种丢包率较高、网络状况不好的情况下，利用TCP协议进行视频或音频通信显然不是很好的一个选择。

TCP协议是面向连接的协议，它的重传机制和拥塞控制机制都是不适合用于实时多媒体传输的。

下面具体分析网络运行一下TCP和其他可靠传输层协议如XTP不适合实时传输的几个主要原因。

（1）.启动速度慢

即便在网络运行状况良好，没有丢失包的情况下，由于TCP的建立连接需“三次握手”，因而在初始化的过程中，需要较长的时间。

而在一个实时多媒体的应用中，我们期望尽量少的延迟。

（2）.TCP的重传机制

在TCP/IP协议中，当发送方收不到接收方发来的确认，并超过一定的时间，就认定该数据已丢失，这时它将重传丢失的数据包。

这一过程将需要一个甚至更多的周期，这种重传机制对于实时性要求较高的多媒体数据传输来说是灾难性的，因为接收不得不等待重传数据的到来，从而造成了延时和断点。

（3）.TCP的拥塞控制机制

TCP拥塞控制机制在探测到有数据包丢失时，它就会减少它的拥塞窗口。

另一方面，音频、视频在特定的编码方式下，产生的编码数量是不可能突然改变的，例如，标准的PCM音频需要64Kb/s，加上一些额外控制信息，它不能再低于这个带宽要求的网络上传输。

正确的拥塞控制应该是变换音频、视频信息的编码方式，调节视频信息的帧频或者图像的大小。

（4）.报文头的大小

TCP和XTP报文头都比UDP的报文头大，TCP和XTP3.6的报文头为40字节，XTP4.0为32字节，而RTP的固定报文头为12字节，因而它们所能携带的信息占整个报文的比例相对来说比较小。

并且这些可靠的传输协议不能提供时间戳和编解码信息，而这些信息是接收方应用程序所需要的，因此它们是不适合进行多媒体信息传输的。

1.5RTP的引入

基于上一节的分析，我们可以清楚的认识到TCP协议是不适合用来进行传输实时多媒体数据的，因此考虑选择UDP作为RTP的传输层协议。

UDP是一种面向无连接的数据报方式，当通信一旦开始，发送方就不断地发送数据而不需要接收端做出确认信息。

它取消了重发校验机制，因此能够达到较高的通信速率，但不能保证报文的先后顺序，也不能保证数据传输的可靠性。

因为音频、视频码流比传统数据对实时性要求更高，即使少量的时延，对音频、视频播放来说也是无法忍受的，但它们对于少量的包丢失却不太敏感。

所以本文在IP网络上建立的实时音频传输系统采用面向无连接的UDP协议进行传输。

但是UDP传输的不可靠带来丢包、乱序等问题，所以如果在应用层采用合适的封装方式并增加一些有利于媒体播放的信息进行传输，可以使得接收端在一定程度上弥补传输带来的损失，这就是引入RTP的原因。

同时如果收发端能够实时了解网络和传输状况，就可以适当调节自己的任务，最终使得在接收端能够达到最好的效果，由此引入RTCP传输控制协议对传输状况进行实时监测和报告。

RTP（Real-timeTransportProtocol）实时传输协议，是由Internet工程任务组（IETF）的音频/视频传输工作组制定，主要用于VoIP、视频等实时多媒体信息的传输。

音频和视频编码信数据均封装在RTP协议数据包中，RTP提供定时信息和数据报序号，供接收方重组数据包，但是RTP本省并不能为按顺序传送数据包提供可靠的传输机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。

RTCP（Real-timeTransportControlProtocol）实时传输控制协议，它提供服务质量的统计信息及提供传输可靠性的保证和流量的拥塞控制机制。

第二章RTP/RTCP协议介绍

2.1实时传输协议的简单介绍

RTP全名是Real-timeTransportProtocol（实时传输协议）。

它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。

RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-timeTransportControlProtocol，即实时传输控制协议）。

RTP协议包括RTP（Real-timeTransportProtocol）实时传输协议和RTCP（Real-timeTransportControlProtocol）实时传输控制协议这两个协议。

其中RTP被定义为一对一或一对多的传输情况下工作，实现实时数据的传输，但是它并不提供任何传输可靠性的保证和流量的拥塞控制机制，这些工作将由RTCP来完成。

RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，所以特别适合传输实时数据。

RTP为交互式音频、视频等具有实时特性的数据提供端到端的传输。

它不是典型意义上的传输层协议，因为它并不具备一个典型传输协议的所有特点。

例如：

RTP没有连接的概念，它必须建立在底层的面向连接的或无连接的传输协议之上；

本身不依赖于特别的地址格式，而需要底层传输协议支持成帧和分段。

一般来说，RTP是在传输层协议之上作为应用程序的一部分加以实现的。

在IP网络上，RTP协议一般是运行在UDP之上。

首先RTP可以利用UDP的多路复用功能来分别传输RTP数据包和RTCP控制包。

其次，RTCP能实时监控数据传输和服务质量，不需要下层协议来保证实时业务的服务质量。

再次，由于UDP的传输时延低于TCP，能与音频和视频流很好匹配，保证了实时性的要求。

因此，在实际应用中，RTP/RTCP/UDP用于音频、视频媒体，而TCP用于数据和控制信令的传输。

当然，RTP还可以和其他合适的底层网络和传输协议一起工作。

例如它也可以在TCP或ATM等其它协议之上工作。

如果底层网络支持多点传播的话，RTP还支持使用多点传播向多个目的端点发送数据。

下图表示了RTP与各种网络协议的关系。

2.1RTP与各种网络协议的关系

2.2RTP协议的三类主要应用

（1）简单的多播音频会议

这里的多播主要指IP网络的多播业务用于语音通信。

它通过一个多播地址和一对端口来实现。

一个端口用于RTP传输音频数据，另一个端口用于传输RTCP控制包。

这个地址和端口的信息要发布给各个与会者。

当一个与会者将要发言时，其话音将以每20毫秒为一帧的间隔分成许多音频数据包，并在数据包前加上RTP头，然后按照RTP包头在前，数据在后的顺序将它们封装在UDP包中。

RTP包头可以指明语音编程类型（如PCM，ADPCM或LPC），以便发送方在会议过程中改变编码的类型了。

Ineternet和其他报文网络一样，会有丢包，报文失序以及报文的不同时延问题。

为了克服这些不利因素，RTP包头携带时间戳和序列号，这样接收方就可以重建源产生的计时信息，语音报文可以按照20毫秒的间隔连续回放了。

其计时信息是接收方按照会议中不同的RTP源分别重建的。

同时，接收方也可以利用序列号来估算包丢失数。

与会者在会议进行期间可能加入或退出，因此了解在某一时刻有哪些人参加了会议，以及它们的语音数据接收情况是很有必要的。

因此每个与会者的应用程序都周期性地广播含有自己名字的RTCP接收报告。

RTCP接收报告表明了这一与会者接收语音数据的效果，同时它可以用来控制自适应编码器。

另外，用户也可以使用名字以外的其它表示信息，这要视控制带宽的情况而定。

一个与会者离开会议时要发送RTCPBYE报文，以通知其它的参与者自己离开了。

（2）音频和视频会议

如果在一个会议里同时有音频和视频，它们将采用独立的RTP会话来传送，两个媒体流的RTCP报文采用不同的UDP端口对或多播地址。

在RTP层音频和视频并没有直接的联系，除非某个特定的用户需要在RTCP报文中使用相同的标识将这两个RTP会话联系起来。

音频和视频采用独立的RTP会话的原因之一是可以允许部分与会者根据需要只接收者音频或视频流。

尽管采用独立的RTP会话，同源的音频和视频可以根据RTCP的时间信息进行同步回放。

（3）混合器和转换器

当某一与会者采用低速链路接入会议，而大部分与会者采用高速链路接入，如果让每个与会者使用窄带，低质量的语音编码器，这显然不是一个很好的解决办法，这时就需要使用“混合器”。

混合器（Mixer）是一个RTP层的中继设备，将它置于低速链路端，它对到来的音频报文按20毫秒的间隔重新进行同步，然后将重构的音频数据流混合成一路窄带的数据流转发给窄带用户。

这些新的报文可以按照单播或多播的形式发送给接收者。

RTP包头提供了一个字段CSRC，使混合器可以辨别混合报文的各个信源，这样在接收端就可以正确获知谁是发送者。

“转换器”（Translators）也是一种RTP层的中继设备，当某些与会者不能通过多播（multicast）方式直接连接到会与，比如它们处在不让任何IP包通过的应用级防火墙之后，这时就需要用到“转换器”。

在防火墙内外各安装一个转换器，当外面的转换器接收到安全的数据包后，将它们以隧道方式直接发送给防火墙内的转换器，由它转发给防火墙内的用户。

混合器和转换器可以针对很多不同的目的而设计。

比如视频混合器，它可以将多路不同的视频流的单个图像混合成一路视频流，模拟一个群体场景。

转换器的一个应用例子是连接一些只能使用IP/UDP的主机和只能使用ST-II主机，或者对单个信源的视频流进行逐包的编码翻译，而不作重新同步或混合。

2.3RTP数据包格式

2．3．1RTP数据包格式

RTP报文头格式（见RFC3550Page12）：

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X|CC|M|PT|sequencenumber|

|timestamp|

|synchronizationsource（SSRC）identifier|

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|contributingsource（CSRC）identifiers|

|....|

以上域具体意义如下：

（1）版本（V）:

2比特此域定义了RTP的版本.此协议定义的版本是2.（值1被RTP草案版本使用,值0用在最初"

vat"

语音工具使用的协议中.）

（2）填料（P）:

1比特若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包.

（3）扩展（X）:

1比特若设置扩展比特,固定头（仅）后面跟随一个头扩展.

（4）CSRC计数（CC）:

4比特CSRC计数包含了跟在固定头后面CSRC识别符的数目.

（5）标志（M）:

1比特标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位.

（6）负载类型（PT）:

7比特此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.RTP发射机在任意给定时间发出一个单独的RTP负载类型;

此域不用来复用不同的媒体流.

（7）序列号（sequencenumber）:

16比特每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的（不可