《基于RTP的linux实时语音通信系统的设计与实现毕业论文.doc》由会员分享，可在线阅读，更多相关《基于RTP的linux实时语音通信系统的设计与实现毕业论文.doc（66页珍藏版）》请在三一办公上搜索。
1、嘉 应 学 院毕业论文（设计）题目：基于RTP的linux实时语音通信系统的设计与实现申请学位 工学学士 学 院 计算机学院 专 业 计算机软件工程（师范）2014 年 6 月 18 日摘 要随着信息社会的高速发展，Internet已经成为很多人生活不可缺少的一部分。当前Internet中流动的“比特”所代表的内容已从原来的数据逐渐向实时多媒体数据演变，它们的特点是对实时性要求非常高。但是，Internet是建立在TCP/IP之上的计算机网络，最初设计时的定位决定了它不适合实时数据的传输。因此，1996年1月IETF音视频传输工作颁布了针对实时应用的实时传输协议RTP/RTCP。RTP/RTC
2、P 使Internet从理论上具备了处理实时业务的能力，解决了媒体同步问题和满足了多媒体通信业务的要求，现在在IP电话、网络多媒体会议、远程网络教学和远程网络诊断等领域都有着重大的应用。 本文结合RTP/RTCP高实时性的特点，主要针对局域网，提出了音频数据采用G729a压缩，传输数据采用ortp库，在linux平台下开发的实时语音通信系统。本文首先介绍了实时传输协议的简单应用后，详细分析了RTP/RTCP协议；接着介绍系统的具体实现，主要分三个部分：音频数据的采集和播放，音频数据的解码和编码以及音频数据包的发送和接收。最后简单阐述了本系统在其他领域的可扩展性及前景。【关键词】实时性，音频传输
3、，RTP/RTCP，音频压缩AbstractWith the rapid development of information society, the Internet has become an indispensable part of a lot of people life.The current flows through the Internet bits represented by the contents of which have been gradually from the original data to real-time multimedia data, the
4、 characteristic of them is very high demand for real-time.However, the Internet is based on TCP/IP computer networks, the initial design of location determines it is not suitable for real-time data transmission.Therefore, IETF audio and video transmission work in January 1996 issued for real-time ap
5、plication of real-time transmission protocol RTP/RTCP.RTP/RTCP make Internet theoretically with the real-time ability of the business, the media synchronization problems and meet the requirements of the multimedia communication service, the IP telephone, network, multimedia conference, remote networ
6、k teaching and remote diagnosis, etc all have important applications.In this paper, combining with the characteristics of RTP/RTCP high real-time performance, mainly for local area network (LAN), is put forward using G729a audio data compression, data transmission using ortp library, development of
7、real-time voice communication system on the Linux platform.This paper first introduces the simple application of real-time transport protocol, RTP/RTCP protocol are analyzed in detail.Then this paper introduces the implementation of system, mainly divided into three parts: audio data acquisition and
8、 playback, audio data decoding and encoding and audio packets sent and received.The last simply expounds the system scalability and prospects in other areas.【Keywords】 Real time audio transmission, RTP/RTCP, audio compression目 录前 言1第一章 绪论21.1项目概述21.1.1 编写目的21.1.2 背景21.1.3 术语定义21.1.4 论文的主要工作31.1.5 论文
9、的组织结构31.1.6 系统开发计划41.2网络多媒体教学系统概述41.2.1通用网络多媒体教学平台基本概念41.2.2通用网络多媒体教学平台的基本特点341.3网络教学提出的背景与意义51.3.1 提出的背景51.3.2 提出的意义51.4国内外网络教学研究发展状况和分析51.4.1网络教学的发展551.4.2国内著名通用网络多媒体教学平台61.4.3国外著名通用网络多媒体教学平台61.4.4存在不足的分析6第二章 技术基础72.1 C/S体系结构72.1.1传统的二层C/S体系结构72.1.2 三层的C/S体系结构72.1.3 C/S结构特点82.2 B/S体系结构82.2.1 B/S三层
10、体系结构82.2.2 B/S结构的特点82.2.3 B/S体系结构的不足92.3 C/S与B/S结构的分析比较92.4 技术平台的介绍102.4.1ASP简介9102.4.2 Microsoft SQL Server10112.4.3 IIS 11122.4.4 Ajax技术 12122.4.5 ADO技术 12122.5系统开发平台132.5.1系统开发环境132.5.2平台的搭建与优点132.5.3 目的142.6系统设计结构14第三章 系统分析153.1 引言153.2 系统目标153.3 系统的可行性分析153.3.1 技术可行性153.3.2 使用可行性163.3.3 经济可行性16
11、3.4需求分析13163.4.1 系统建设原则163.4.2 环境设备需求163.4.3 功能需求173.4.4 性能需求193.4.5 数据需求193.4.6 系统数据描述19第四章 概要设计234.1 系统设计的目标234.2 系统设计思想234.3 系统结构图和模块设计244.3.1 系统结构图244.3.2 模块设计244.4 接口设计254.4.1 用户接口254.4.2 外部接口254.4.3 内部接口254.5数据库设计254.5.1 逻辑结构设计264.5.2 数据表间的关系设计284.5.3 物理结构设计294.5.4 数据与程序间的关系294.6 系统出错处理设计294.6
12、.1 出错信息294.6.2 出错处理措施29第五章 详细设计305.1 引言305.2 数据库表的设计305.3 模块算法设计325.3.1公共模块设计（部分）325.3.2其它模块设计（部分）35第六章 平台测试416.1 测试概述416.1.1 目的416.1.2 测试人员416.2 测试计划416.2.1 测试环境416.2.2 测试方案416.2.3 测试项目416.2.4 测试用例（部分）416.3 测试分析426.3.1 测试项目执行情况分析426.3.2 系统评价426.3.3 系统的不足436.4 测试结论43第七章 系统运行447.1引言447.2运行环境447.3 系统配
13、置447.3.1运行WEB服务器的设置447.3.2运行数据库服务器的设置457.4 页面操作及关键技术说明45第八章 总结与展望548.1 设计总结及成果548.2 不足与展望55参考文献56致 谢57附录（其它核心代码）1前 言随着多媒体网络的发展，RTP/RTCP在众多领域也得到了深入的应用，如VOIP电话、多媒体会议系统等应用的出现，也让语音传输通信技术也得到了迅速的发展。然而，语音通信需要的实时性是非常高的，而且数据量大。例如，一个多媒体会议系统，我们总是希望发言者的发言能够尽早让收听者收听到，也就是说时延尽量短；另外一个就是我们希望在收听者收听语音信息时，一句话平滑的，即中间没有断
14、点，也就是等时性。这些都是实现实时语音通话应达到的要求。为此，本人在导师的指导下，详细研究分析了RTP/RTCP协议，结合RTP/RTCP协议高实时性的特点，利用现有的音频编程和网络编程知识，设计和开发了这个基于RTP的linux实时语音通信系统。目前只实现了单播功能，即点对点的通信。论文的主要内容如下：第一章：引言，主要介绍了实时多媒体数据传输的发展，阐述了TCP不适合多媒体传输的原因并引入了RTP.第二章：根据RFC3550官方文档，详细分析了RTP/RTCP协议。第三章：介绍了linux下基于RTP的实时语音通信系统实现的基本原理和总体架构。第四章：介绍了linux音频编程。第五章：讲解
15、了音频传输的实现。第六章：介绍了音频解码和编码的实现。第七章：总结与展望。第一章 引言1.1实时数据传输的发展我们已经步入一个高速发展的信息社会，Internet已经成为很多人生活不可缺少的一部分。Internet中流动的“比特”所代表的内容已从原来的数据逐渐向多媒体演变。随着IPv6，RSVP,RTP/RTCP一系列协议的出现，在Internet上实现多媒体通信成为可能。IPv6解决了IPv4地址资源有限，不能控制带宽等问题，RSVP(资源预留协议)，RTP/RTCP（实时传输/控制协议）使Internet从理论上具备了处理实时 业务的能力，解决了媒体同步问题和满足多媒体通信业务的要求。越来
16、越多的实时多媒体应用的出现，极大的丰富了人们生活，如成为这几年的热点的IP电话，另外还有VID、远程网络教学、远程网络诊断和网络多媒体会议业务、多媒体消息型业务等。1.2国内外研究状况早在20世纪70年代末80年代初，如何在分组上实时传输语音就是一个很活跃的研究方向，到了九十年代初这个方向研究又变得异常活跃。1992年3月，IETF（Internet Engineering Task Force）在San Diego召开的会议是分组网上第一次大规模的音频多播应用。会议使用的音频传输软件主要是Vat（Visual Audio Tool）,它是由LBNL（Lawrence Berkeley Nat
17、ional Laboratory）网络研究小组开发的一个音频会议工具，该小组还开发了视频工具vic和白板工具wb。会议还使用的另一个音频软件是NeVoT(Network Voice Terminal),它是H.Schulzrinne等人在90年代初开发出来的。该软件最初使用的是vat协议，但是在RTP协议制定出来后也开始支持RTP协议了。还有其他大学，研究组织研究开发出来的音频工具TAT（Robust Audio Tool），会议目录工具SDR(session directory)，CU-SeeMe音频会议工具等等。 在国内，清华电子工程系网络研究所多媒体通信课题组也在这方面做了大量的研究，并
18、开发出了Cool-audio、Cool-Video、Cool-Meeting等一系列软件。其中Cool-audio网络电话于1998年推出，它是我国第一套自主版权且最有影响的Internet电话软件。另外，东南大学计算机系，北京邮电大学电信工程学院和华中科技大学等研究机构也在这方面做出了大量的研究工作。北京的微软亚洲研究院的网络多媒体组正在做SMART音/视频传输(SMART A/V Delivery)等项。但是总的来说，国内的研究水平要远远落后于国外。可以说，实时多媒体数据传输研究已经有了长足的进步，制定了许多相关的传输协议，例如：RTP（Real-time Transport Protoc
19、ol）和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协议的实时音频传输
20、的实现。1.3实时多媒体数据传输的特点实现多媒体数据传输的核心是声、文、图等多媒体信息的传输技术，它的一个显著特点是数据量大，并且许多应用对实时性都有比较高的要求，例如，一个多媒体会议系统，我们总是希望发言者的发言能够尽早让收听者收听到，也就是说时延尽量短；另外一个就是我们希望在收听者收听语音信息时，一句话平滑的，即中间没有断点，也就是等时性。这些都是实现实时语音通话应达到的要求。1.4 TCP不适合传输实时多媒体数据Internet是建立在TCP/IP之上的计算机网络，它最初是为提供非实时数据业务而设计的。IP协议是面向无连接的，负责主机之间的数据传输，但只提供“尽力而为”（best-eff
21、ort）的服务，不进行检错和纠错，因此经常发生数据丢失现象。为保证数据的可靠传输，在传输层使用TCP协议，当接收端检测到数据包丢失或错误时，要求发送端重新发送，但这样不可避免地引起传输延时和占用网络带宽。因此传统的TCP/IP协议传输实时音频、视频数据的能力比较差。当然在传输用于回放的视频和音频数据时，TCP也是一种选择。如果有足够大的缓冲区和充足的网络带宽，比如在局域网内，在TCP协议上，接近实时的传输也是可能的。但是在大多数情况下，我们需要再广域网内传输数据，在这种丢包率较高、网络状况不好的情况下，利用TCP协议进行视频或音频通信显然不是很好的一个选择。TCP协议是面向连接的协议，它的重传
22、机制和拥塞控制机制都是不适合用于实时多媒体传输的。下面具体分析网络运行一下TCP和其他可靠传输层协议如XTP不适合实时传输的几个主要原因。（1）.启动速度慢即便在网络运行状况良好，没有丢失包的情况下，由于TCP的建立连接需“三次握手”，因而在初始化的过程中，需要较长的时间。而在一个实时多媒体的应用中，我们期望尽量少的延迟。（2）.TCP的重传机制在TCP/IP协议中，当发送方收不到接收方发来的确认，并超过一定的时间，就认定该数据已丢失，这时它将重传丢失的数据包。这一过程将需要一个甚至更多的周期，这种重传机制对于实时性要求较高的多媒体数据传输来说是灾难性的，因为接收不得不等待重传数据的到来，从而
23、造成了延时和断点。（3）.TCP的拥塞控制机制TCP拥塞控制机制在探测到有数据包丢失时，它就会减少它的拥塞窗口。另一方面，音频、视频在特定的编码方式下，产生的编码数量是不可能突然改变的，例如，标准的PCM音频需要64Kb/s，加上一些额外控制信息，它不能再低于这个带宽要求的网络上传输。正确的拥塞控制应该是变换音频、视频信息的编码方式，调节视频信息的帧频或者图像的大小。（4）.报文头的大小TCP和XTP报文头都比UDP的报文头大，TCP和XTP3.6的报文头为40字节，XTP4.0为32字节，而RTP的固定报文头为12字节，因而它们所能携带的信息占整个报文的比例相对来说比较小。并且这些可靠的传输
24、协议不能提供时间戳和编解码信息，而这些信息是接收方应用程序所需要的，因此它们是不适合进行多媒体信息传输的。1.5 RTP的引入基于上一节的分析，我们可以清楚的认识到TCP协议是不适合用来进行传输实时多媒体数据的，因此考虑选择UDP作为RTP的传输层协议。UDP是一种面向无连接的数据报方式，当通信一旦开始，发送方就不断地发送数据而不需要接收端做出确认信息。它取消了重发校验机制，因此能够达到较高的通信速率，但不能保证报文的先后顺序，也不能保证数据传输的可靠性。因为音频、视频码流比传统数据对实时性要求更高，即使少量的时延，对音频、视频播放来说也是无法忍受的，但它们对于少量的包丢失却不太敏感。所以本文
25、在IP网络上建立的实时音频传输系统采用面向无连接的UDP协议进行传输。但是UDP传输的不可靠带来丢包、乱序等问题，所以如果在应用层采用合适的封装方式并增加一些有利于媒体播放的信息进行传输，可以使得接收端在一定程度上弥补传输带来的损失，这就是引入RTP的原因。同时如果收发端能够实时了解网络和传输状况，就可以适当调节自己的任务，最终使得在接收端能够达到最好的效果，由此引入RTCP传输控制协议对传输状况进行实时监测和报告。RTP（Real-time Transport Protocol）实时传输协议，是由Internet工程任务组（IETF）的音频/视频传输工作组制定，主要用于VoIP、视频等实时多
26、媒体信息的传输。音频和视频编码信数据均封装在RTP协议数据包中，RTP提供定时信息和数据报序号，供接收方重组数据包，但是RTP本省并不能为按顺序传送数据包提供可靠的传输机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。RTCP（Real-time Transport Control Protocol）实时传输控制协议，它提供服务质量的统计信息及提供传输可靠性的保证和流量的拥塞控制机制。第二章 RTP/RTCP协议介绍2.1 实时传输协议的简单介绍RTP全名是Real-time Transport Proto
27、col（实时传输协议）。它是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被定义为一对一或一对多的传输情况下工作，实现实时数据的传输，但是它并不提供任何传输可靠性的保证和流量的拥塞
28、控制机制，这些工作将由RTCP来完成。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，所以特别适合传输实时数据。RTP为交互式 音频、视频等具有实时特性的数据提供端到端的传输。它不是典型意义上的传输层协议，因为它并不具备一个典型传输协议的所有特点。例如：RTP没有连接的概念，它必须建立在底层的面向连接的或无连接的传输协议之上；本身不依赖于特别的地址格式，而需要底层传输协议支持成帧和分段。一般来说，RTP是在传输层协议之上作为应用程序的一部分加以实现的。在IP网络上，RTP协议一般是运行在UDP之上。首先RTP可以利用UDP的多路复用功能来分别传输RTP数据包和RTCP控制
29、包。其次，RTCP能实时监控数据传输和服务质量，不需要下层协议来保证实时业务的服务质量。再次，由于UDP的传输时延低于TCP，能与音频和视频流很好匹配，保证了实时性的要求。因此，在实际应用中，RTP/RTCP/UDP用于音频、视频媒体，而TCP用于数据和控制信令的传输。当然，RTP还可以和其他合适的底层网络和传输协议一起工作。例如它也可以在TCP或ATM等其它协议之上工作。如果底层网络支持多点传播的话，RTP还支持使用多点传播向多个目的端点发送数据。下图表示了RTP与各种网络协议的关系。 2.1 RTP与各种网络协议的关系2.2 RTP协议的三类主要应用（1）简单的多播音频会议这里的多播主要指
30、IP网络的多播业务用于语音通信。它通过一个多播地址和一对端口来实现。一个端口用于RTP传输音频数据，另一个端口用于传输RTCP控制包。这个地址和端口的信息要发布给各个与会者。当一个与会者将要发言时，其话音将以每20毫秒为一帧的间隔分成许多音频数据包，并在数据包前加上RTP头，然后按照RTP包头在前，数据在后的顺序将它们封装在UDP包中。RTP包头可以指明语音编程类型（如PCM，ADPCM或LPC），以便发送方在会议过程中改变编码的类型了。Ineternet和其他报文网络一样，会有丢包，报文失序以及报文的不同时延问题。为了克服这些不利因素，RTP包头携带时间戳和序列号，这样接收方就可以重建源产生
31、的计时信息，语音报文可以按照20毫秒的间隔连续回放了。其计时信息是接收方按照会议中不同的RTP源分别重建的。同时，接收方也可以利用序列号来估算包丢失数。与会者在会议进行期间可能加入或退出，因此了解在某一时刻有哪些人参加了会议，以及它们的语音数据接收情况是很有必要的。因此每个与会者的应用程序都周期性地广播含有自己名字的RTCP接收报告。RTCP接收报告表明了这一与会者接收语音数据的效果，同时它可以用来控制自适应编码器。另外，用户也可以使用名字以外的其它表示信息，这要视控制带宽的情况而定。一个与会者离开会议时要发送RTCP BYE报文，以通知其它的参与者自己离开了。（2）音频和视频会议如果在一个会
32、议里同时有音频和视频，它们将采用独立的RTP会话来传送，两个媒体流的RTCP报文采用不同的UDP端口对或多播地址。在RTP层音频和视频并没有直接的联系，除非某个特定的用户需要在RTCP报文中使用相同的标识将这两个RTP会话联系起来。音频和视频采用独立的RTP会话的原因之一是可以允许部分与会者根据需要只接收者音频或视频流。尽管采用独立的RTP会话，同源的音频和视频可以根据RTCP的时间信息进行同步回放。（3）混合器和转换器当某一与会者采用低速链路接入会议，而大部分与会者采用高速链路接入，如果让每个与会者使用窄带，低质量的语音编码器，这显然不是一个很好的解决办法，这时就需要使用“混合器”。混合器（
33、Mixer）是一个RTP层的中继设备，将它置于低速链路端，它对到来的音频报文按20毫秒的间隔重新进行同步，然后将重构的音频数据流混合成一路窄带的数据流转发给窄带用户。这些新的报文可以按照单播或多播的形式发送给接收者。RTP包头提供了一个字段CSRC，使混合器可以辨别混合报文的各个信源，这样在接收端就可以正确获知谁是发送者。“转换器”（Translators）也是一种RTP层的中继设备，当某些与会者不能通过多播（multicast）方式直接连接到会与，比如它们处在不让任何IP包通过的应用级防火墙之后，这时就需要用到“转换器”。在防火墙内外各安装一个转换器，当外面的转换器接收到安全的数据包后，将它
34、们以隧道方式直接发送给防火墙内的转换器，由它转发给防火墙内的用户。混合器和转换器可以针对很多不同的目的而设计。比如视频混合器，它可以将多路不同的视频流的单个图像混合成一路视频流，模拟一个群体场景。转换器的一个应用例子是连接一些只能使用IP/UDP的主机和只能使用ST-II主机，或者对单个信源的视频流进行逐包的编码翻译，而不作重新同步或混合。2.3 RTP数据包格式231 RTP数据包格式RTP报文头格式（见RFC3550 Page12）： 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-
35、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+
36、=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+以上域具体意义如下： （1）版本(V):2比特 此域定义了RTP的版本.此协议定义的版本是2.(值1被RTP草案版本使用,值0用在最初vat语音工具使用的协议中.) （2）填料(P):1比特 若填料比特被设置,此包包含一到多个附加在末端的填充比特,不是负载的一部分.填料的最
37、后一个字节包含可以忽略多少个填充比特.填料可能用于某些具有固定长度的加密算法,或者在底层数据单元中传输多个RTP包. （3）扩展(X):1比特 若设置扩展比特,固定头(仅)后面跟随一个头扩展. （4）CSRC计数(CC):4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目. （5）标志(M):1比特 标志的解释由具体协议规定.它用来允许在比特流中标记重要的事件,如帧范围.规定该标志在静音后的第一个语音包时置位. （6）负载类型(PT):7比特 此域定义了负载的格式,由具体应用决定其解释.协议可以规定负载类型码和负载格式之间一个默认的匹配.其他的负载类型码可以通过非RTP方法动态定义.
38、RTP发射机在任意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流. （7）序列号（sequence number）:16比特 每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难. （8）时间标志（timestamp）:32比特 时间标志反映了RTP数据包中第一个比特的抽样瞬间.抽样瞬间必须由随时间单调和线形增长的时钟得到,以进行同步和抖动计算.时钟的分辨率必须满足要求的同步准确度,足以进行包到达抖动测量.时钟频率与作为负
39、载传输的数据格式独立,在协议中或定义此格式的负载类型说明中静态定义,也可以在通过非RTP方法定义的负载格式中动态说明.若RTP包周期性生成,可以使用由抽样时钟确定的额定抽样瞬间,而不是读系统时钟.例如,对于固定速率语音,时间标志钟可以每个抽样周期加1.若语音设备从输入设备读取覆盖160个抽样周期的数据块,对于每个这样的数据块,时间标志增加160,无论此块被发送还是被静音压缩. 时间标志的起始值是随机的,如同序列号.多个连续的RTP包可能由同样的时间标志,若他们在逻辑上同时产生.如属于同一个图象帧.若数据没有按照抽样的 顺序发送,连续的RTP包可以包含不单调的时间标志,如MPEG交织图象帧. （
40、9）同步源（SSRC）:32比特 SSRC域用以识别同步源.标识符被随机生成,以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符.尽管多个源选择同一个SSRC识别符的概率很低,所有RTP实现工具都必须准备检测和解决冲突.若一个源改变本身的源传输地址,必须选择新的SSRC识别符,以避免被当作一个环路源. （10）有贡献源（CSRC）列表:0到15项,每项32比特 CSRC列表识别在此包中负载的有贡献源.识别符的数目在CC域中给定.若有贡献源多于15个,仅识别15个.CSRC识别符由混合器插入,用有贡献源的SSRC识别符.例如语音包,混合产生新包的所有源的SSRC标识符都被陈列,以
41、期在接收机处正确指示交谈者.注意：前12个字节出现在每个RTP包中,仅仅在被混合器插入时,才出现CSRC识别符列表.RTP报文扩展头格式（见RFC3550 Page18）： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
42、-+-+-+-+-+-+-+-+-+-+-+ | header extension | | . |若RTP头中的扩展比特位X置1,则一个长度可变的头扩展部分被加到RTP固定头之后,头扩展包含16比特的长度域,指示扩展项中32比特字的个数,不包括4个字节扩展头(因此零是有效值).RTP固定头之后只允许有一个头扩展.为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前16比特用以识别标识符或参数.这16比特的格式由具体实现的上层协议定义.基本的RTP说明并不定义任何头扩展本身。第三章 实时语音通信系统简介3.1 系统平台本系统是在linux下实现的，选用Ubunt
43、u 12.04作为软件的实现平台，vim作为编写工具，编程语言采用C+。在linux平台上，音频采集采用ALSA（Advanced Linux Sound Architecture ）的lib库，利用网上现有的oRTP库实现基于RTP的实时语音传输。Linux是一位芬兰的年轻人Linus Benedict Torvalds于1991年10月在赫尔辛基大学对外正式发布一套操作系统，它一种Unix风格的操作系统，在源代码级上兼容绝大部分Unix标准，是一个支持多用户、多进程、多线程、功能强大而且执行稳定的操作系统。非常重要的一点，Linux还是一种开放、免费的操作系统，还具有可移植性和自由代码等特
44、性，这是其它操作系统所无法比拟的。目前Linux已经得到了越来越多的应用。3.2 系统实现的基本原理和框架结构本系统主要实现音频数据的实时传输通话。采用在计算机以太网上进行点对点的通信模式。具体的过程是：上层通过麦克风采集音频数据，然后采用G729a进行音频压缩，发送方RTP协议从上层接收音频数据（这里采用PCM编码），封装成RTP数据包发送给下层协议UDP，UDP提供RTP和RTCP的分流，RTP使用一个偶数号端口，相应的RTCP使用其后的奇数号端口。接收方则对网络层传来的数据包解封，并交由RTP提取音频数据，然后进行音频解压缩，再经扬声器播放出来。下面图3.1是本系统的基本框架流程图：实时
45、语音通信模块实现过程见下图3.1：图3.1 基本框架流程图本系统核心模块是语音通话模块的实现，下面是语音通话模块的流程图：3.2语音通话模块的流程图第四章 linux音频编程4.1 音频编程简介音频信号是一种连续变化的模拟信号，但计算机只能处理和记录二进制的数字信号，由自然音源得到的音频信号必须经过一定的变换，成为数字音频信号之后，才能送到计算机中作进一步的处理。数字音频系统通过将声波的波型转换成一系列二进制数据，来实现对原始声音的现，实现这一步骤的设备常被称为模/数转换器（A/D）。A/D转换器以每秒钟上万次的速率对声波进行采样，每个采样点都记录下了原始模拟声波在某一时刻的状态，通常称之为样本sample），而每一秒钟所采样的数目则称为采样频率，通过将一串连续的样本连接起来，就可以在计算机中描述一段声音了。对于采样过程中的每一个样本来说，数字音频系统会分配一定存储位来记录声波的振幅，一般称之为采样分辩率或者采样精度，采样精度越高，声音还原时就会越细腻。数字音频涉及到的概念非常多，对于在Linux下进行音频编程的程序员来说，最重要的是理解声音数字化的两个关键步骤：采样和量化。采样就是每隔一定时间就读一次声音信号的幅度，而量化则是将采样得到的声音信号幅度转换为数字值，从本质上讲，采样是时间上的数字化，而
