论文 王军成 终稿.docx

论文 王军成 终稿.docx

《论文 王军成 终稿.docx》由会员分享，可在线阅读，更多相关《论文 王军成 终稿.docx（70页珍藏版）》请在冰豆网上搜索。

论文王军成终稿

毕业设计（论文）

题目IP语音电话设计与实现

学院理学院

专业信息与计算科学

班级2010级2班

学生王军成

学号10180211

指导教师杨际祥

重庆交通大学

2014年6月

摘要

随着Internet的迅速发展以及个人计算机处理能力的增强，软件实现方式的IP可视电话系统成为网络视频应用研究的一大热点。

但是，目前的IP网还存在网络服务质量欠缺、网络带宽瓶颈、网络访问限制等问题，这使得IP可视电话系统的普及变得困难。

针对以上问题，本文从视频流的压缩编码、传输与调度入手，研究具有高伸缩性、高质量、低成本的IP可视电话系统的设计与实现方法。

首先，视频的编码传输是实现整个系统的基础。

为了提高视频传输的实时性和效率，本文给出了一种Internet网上的基于MPEG-4视频压缩编码的视频流传输模型，保证了在低比特率及Internet网下能够提供良好的图像质量以及网络资源的有效利用。

其次，根据MPEG-4视频流特点和网络的拥塞程度，本文给出了一种改进的适合MPEG-4视频传输区分服务的模型，弥补了传统的IP网络“尽力而为”传输方式的不足，保证了网络服务质量。

然后，本文给出了一种新的穿越NAT的方法。

通过SIP协议及TCP/IP协议实现了局域网与局域网、局域网与互联网、互联网与互联网之间的数据通信，从而解决了网络访问障碍问题。

并且，服务器根据客户端之间的网络连接方式动态地决定采取单播或多播或P2P方案，减少了客户端与服务器间的通信量，从而减少了服务端的下行带宽，带宽瓶颈问题得以较好地解决。

最后，本文给出了IP可视电话系统的一个具体实现及其性能测试。

为分析该系统的性能，论文建立了一个客户端仿真模型，利用仿真程序对系统进行性能测试。

测试结果表明，该系统能够在宽带网上提供适时的良好质量的视频服务。

关键词：

流媒体，IP可视电话，QoS，MPEG-4，NAT，RTCP/RTP

Abstract

WiththerapiddevelopmentofInternetandtheimprovementintheprocessingabilityofPC,IPvideophonesystem,oneofthewaysofsoftwarerealization,hasbecomeafocusontheresearchofthenetworkvideoapplication.However,forthemoment,someproblemsstillexist,suchasservicequality,bandwidthbottleneck,networkaccesslimitsandsoon,whichincreasethedifficultyinmakingIPvideophonesystempopular.

Aimedattheproblemsmentionedabove,startingwiththevideostream’scompressionandcoding,transportationandscheduling,thisthesisworksonthedesignandrealizationoftheIPvideophonesystemwithgoodscalability,highqualityandlowcosts.

Firstly,withthetargettoimprovethereal-timeandeffectivenessofvideotransportation,thevideocompressionandcodingandtransportationarethefoundationofputthewholesystemintomotion.Thethesispresentsonemodelofvideostreamtransportation,whichisbasedontheMPEG-4videocompressioncoding.ThismodelensurestoprovidepicturesofhighqualityandmakeeffectiveuseoftheInternetresourcesinlowbitrateontheInternet.

Secondly,accordingtothefeaturesofvideostreamandthecongestionlevelofInternet,thisthesisprovidesoneimprovedmodel,fitforMPEG-4videotransportationDiffServ,whichmakesupthedisadvantageofthetraditionalIPInternettransportationcharacterizedbyits“best-effort”andassurestheInternetservicequality.

Thirdly,thethesisproposesanewmethodtotraverseNAT.ThroughSIPandTCP/IP,theproblemofaccessobstaclesonInternetissolvedbythecommunicationbetweenLANandLAN,LANandinternetnetwork,internetnetworkandinternetnetwork.What’smore,theserverdecidesifunicastormulticastorP2PwillbeusedaccordingtotheInternetlinkingstyleamongtheclients,whichreducestheamountofthecommunicationbetweentheclientandserver’soutput-bandwidth.Thus,theproblemofbandwidthbottleneckiswellsolved.

Lastly,thisthesisprovidesanapproachtotheactualrealizationandperformancetestingoftheIPvideophonesystem.Toanalyzeitsperformance,asimulationmodelontheclient’ssideiscreatedandsimulationprogramisemployedtotestthesystem’sperformance.Resultsprovedthatthesystemisableto,whenneeded,supplyvideoserviceofgoodqualityonbroadbandInternet.

Keywords：

StreamingMedia,IPvideophonesystemconferencing,QoS,MPEG-4,NAT,RTCP/RTP

目录

第1章绪论1

1.1课题的研究背景1

1.2国内外研究现状1

1.3论文的组织结构2

第2章端到端的MPEG-4视频流传输框架研究3

2.1引言3

2.2MPEG-4视频传输框架3

2.2.1概述3

2.2.2RTP/RTCP协议4

2.2.3反馈控制5

2.2.4源编码率控制6

2.2.5MPEG-4比特流打包7

2.2.6错误控制7

2.3端到端反馈控制协议8

2.4一个打包算法9

2.5仿真结果12

2.5.1仿真设置12

2.5.2对等网络配置下的性能12

2.6本章小结17

第3章MPEG-4视频流传输QoS的研究18

3.1引言18

3.2基于网络的QoS解决方案18

3.2.1DiffServ体系19

3.2.2MPEG-4视频流传输区分服务（DiffServ）21

3.3DiffServ网络模型22

3.4仿真实验及结果26

3.5本章小结30

第4章流数据跨NAT传输技术及调度方案31

4.1引言31

4.2相关技术32

4.2.1NAT基本原理32

4.2.2网络互连及NAT类型33

4.2.3SIP协议33

4.3穿越NAT的方法34

4.3.1局域网间及其与Internet网间通信35

4.3.2一个通用的解决方案38

4.3.3NAT中动态地址映射保存问题43

4.4流调度方案43

4.4.1调度方案43

4.4.2一个实例44

4.5本章小结45

第5章系统的设计实现及性能分析47

5.1系统实现分析47

5.1.1几个关键问题47

5.1.2采用的协议49

5.2系统的设计与实现49

5.2.1系统结构49

5.2.2主控模块50

5.2.3语音视频管理模块52

5.2.4语音视频压缩解压模块54

5.3系统测试56

5.3.1系统开始运行界面：

56

5.3.2呼叫界面56

5.3.3接收呼叫请求界面57

5.3.4会话建立后的界面57

5.4本章小结57

第6章总结及其展望59

5.1全文总结59

5.2展望59

参考文献61

致谢63

第1章绪论

1.1课题的研究背景

随着网络技术和数字通信技术的飞速发展，Intenet越来越影响着人们的生活，也带动了以IP为基础的各种应用的迅猛发展。

随着网络带宽和计算机处理能力的不断提高，在宽带网上实现高速多媒体通信己成为可能，一些传统的数据通信业务包括语音和视频等开始转向IP。

1995年2月以色列VocalTec公司研制出可以通过Intenet网打长途电话的软件产品“IntenetPhone”。

用户只要在多媒体PC机上安装该软件，就可以通过Intenet网和任何地方安装同样软件的联机用户进行通话。

这种在Intemct上实现电话业务被称为Intenet电话，应该说是IP电话的雏形。

IP电话的出现，以其低廉的通话费用及其诱人的市场前景吸引了众多公司包括服务提供商和电信运营商的眼球。

许多公司纷纷投资对其进行研究开发，从而使IP电话技术得到迅速发展。

起初由于技术的不成熟，电话在发明初期只能进行语音通信，但是人们对视频通信的期望从未减退过，在语音通话的同时还能看到对方的图像会使通话过程变得更有亲切感[1]，因为视频往往能传达语言无法表达的信息。

正因为如此，人们都愿意使用可视电话，或者远距离参加视频会议。

但到目前为止类似于可视电话以及视频会议的视频业务仍没有获得广泛应用。

这些视频业务没有走进寻常百姓家的主要原因是受到通信条件的制约，特别是传输资源紧缺和价格昂贵，接入技术单一、落后[2]。

随着网络建设的日益完善，网络环境的不断提升。

使计算机与电信之间的界限也被逐渐打破。

因此，基于纯软件的网络电话也就在这种融合中诞生了，随着技术的迅速发展，软件实现方式的IP电话技术已成为电信网的主流技术。

软件实现方式的IP电话技术是一项涉及计算机网络、电信网络、信令协议、数字信号处理等多个领域的综合性技术，是下一代网络应用的热点。

1.2国内外研究现状

随着IP技术框架中汇聚网络研究的发展，数据网络通信已经融入传统的话音业务领域。

从现实情况来看，在电信数据业务中，IP业务已占95%以上，可以说数据承载网业务已基本IP化。

可以看出，目前电信网中的业务除了传统电话业务外都是IP业务，而电话业务中的长途电话70%已是IP电话。

IP网络技术的优势是显而易见的，语音、传真、视频和数据等业务可以在IP网络上便宜的传送，如统一消息、虚拟电话、虚拟语音/传真邮箱、查号业务、Internet呼叫中心、Internet呼叫管理、电视会议、电子商务、传真存储转发和各种信息的存储转发等。

但是，国内在桌面IP可视电话系统尤其是纯软件实现方式研制方面一直比较落后，这与我国软件的总体水平不高有关系。

少数几个面世的系统，大多采用面向连接的技术，并且系统没有得到普及和推广。

另外，国内也有不少公司企业推出自己的桌面IP可视电话系统，其解决方案适合采用分组交换技术的网络环境，实现IP电话系统的基础是H.323协议，仍然是利用MCU和各个终端连接。

1.3论文的组织结构

本论文由5章构成。

第1章即本章是全文的绪论部分，给出了课题研究背景、国内外研究现状。

第2章主要介绍了一种基于MPEG-4与Internet网络环境下的视频流传输框架。

第3章主要介绍了网络服务质量技术。

介绍了MPEG-4视频特点以及网络的拥塞技术，给出了一种适合MPEG-4视频传输的区分服务模型。

第4章主要介绍了视频流数据跨越NAT网关传输的技术。

首先介绍了SIP与RTP/RTCP协议，然后介绍了如何突破NAT限制来解决网络访问障碍的技术。

第5章主要介绍了系统的实现及性能测试。

首先分析了系统实现的几个关键问题，然后介绍了系统的实现模型，最后对系统在局域网环境下进行了测试。

最后，总结了本文的工作并提出了下一步的设想。

第2章端到端的MPEG-4视频流传输框架研究

2.1引言

随着Internet网的成功以及多媒体通讯时代的到来，MPEG-4[3]国际标准已成为研究热点，基于MPEG-4的应用在不久的将来势必会成为网络多媒体的应用热点。

由于MPEG-4采用了基于对象的编码和基于模型的编码等第二代编码技术从而使之具有灵活性与高效性，除了传统的存储与视频传输外，它能够提供交互的基于内容的视频服务。

Internet视频传输不同于其它数据类型的传输，Internet视频应用对延迟与丢失有独特的要求。

此外，在Internet网上的通信量负载是随着时间急剧变化的，这影响了视频的传输。

因此，在Internet网上设计一个有效的既能够充分利用资源又能够为用户提供最佳的感知服务质量的视频传输框架将是一个挑战。

本章首先概述了一个视频传输框架的主要部分，包括源端速率自适应、打包、端到端反馈控制及错误控制。

由于当前的Internet仅提供“尽力而为”型的服务，因此，在端系统（发送端与接收端）之间实现反馈控制以便发送端能够调整它的传输速率是有必要的。

为了在网络上传输，需要对MPEG-4视频源数据进行打包。

因此，为了在效率与图像质量方面达到良好的性能，适当的打包算法是必要的。

最后，为了减少包在传输过程中由于包丢失而导致图像质量降低的影响，采用相应的错误控制方案也是必要的。

最后对MPEG-4视频传输框架的性能作了仿真测试。

2.2MPEG-4视频传输框架

在本章中，我们概述了在Internet之上传输视频的关键组成部分。

本章组织如下。

在2.2.1节，综述了本章的端到端系统。

从2.2.2节至2.2.5节简要描述了端到端系统的每一个组成部分。

2.2.1概述

图2-1说明了一个在Internet网上传输MPEG-4视频的框架。

给出的框架既适合预先压缩的视频又适合实况播放的视频。

如果视频源是预先压缩的视频，可以由反馈控制协议通过动态的速率调整或选择性地丢弃帧[4]来使速率与流比特率相匹配。

如果视频源是一个实况播放的视频，本章就使用2.4节所描述的MPEG-4速率自适应算法来控制编码器的输出率。

图2-1一种MPEG-4视频传输模型

在发送端，实况播放的视频的原始比特流经过一个自适应的MPEG-4编码器编码。

在这个阶段之后，已压缩的视频比特流首先在同步层（SL）被打成包，然后经过RTP/UDP/IP层进入Internet网络。

包可能在一个路由器/交换机（由于阻塞）或目的地（由于超时延迟）处被丢弃。

成功被传递到目的地的包在MPEG-4解码器处被解码前首先按反方向经过RTP/UDP/IP层。

在传输框架中，在接收端有一个QoS监测器，它根据到达包的行为（如包丢失与延迟）来推断网络阻塞状况。

这样的信息在反馈控制协议中将被用到，并被发送回源端。

基于这样的反馈信息，发送端估计可用网络带宽并控制MPEG-4编码器的输出速率。

2.2.2RTP/RTCP协议

由于TCP的重传机制引入了延迟，而MPEG-4视频应用对于延迟有严格的要求，所以一般不用TCP作为视频传输的协议，而采取UDP作为MPEG-4视频流的传输协议。

另外，由于UDP不提供包传输保证，接收方需要依赖于上层（如RTP/RTCP）来检测包的丢失。

RTP[5]是一个Internet标准协议，被设计用来提供端到端的传输功能以支持实时应用。

RTCP是一个传输控制协议，一般和RTP协议结合使用。

RTCP被设计来为一个RTP会话中的参与者提供QoS反馈。

RTP不提供QoS或可靠传输，但提供一些基本的几乎所有实时应用的公共功能。

一个RTP支持的关键的特征就是包序列号，它能够被用来在接收方检测包的丢失。

RTCP通过在源端与目的端分别使用发送方报告（SR）与接收方报告（RR）来提供QoS反馈。

特别地，RTCP保持总的控制包占总的会话带宽的5%。

在这些控制包中，25%被分配给发送方报告，而75%被分配给接收方报告。

为了避免控制包饿死，在发送方或者接收方每5秒以内至少发送一个控制包。

图2-2说明了RTP/UDP/IP层的实现模型。

该模型是实现基于速率的反馈控制协议与错误掩盖机制的一个关键部分。

从发送部分来看，MPEG-4编码器生成一个打包流，它被转变成RTP包。

另一方面，来自反馈控制协议（发送端）的信息被传递到RTCP发生器。

随后RTCP与RTP包下传到UDP/IP层用于在Internet网上传输。

在接收部分，已接收到的IP包首先被UDP/IP层拆包，然后被过滤器以及分发器分发到RTP与RTCP分析器。

RTP包在被解码前被RTP分析器拆包并被放入一个缓冲器用于丢失检测目的。

当检测到包丢失时，消息将被发送到错误掩盖部分。

另一方面，RTCP分析器拆分RTCP包并发送反馈信息到反馈控制协议部分。

2.2.3反馈控制

Internet视频应用具有独特的和其它数据类型有区别的延迟与丢失要求。

另一方面，当前的Internet并不广泛支持任何的带预留机制或其它的QoS保证。

此外，可用带宽不仅是不可知的，而且是随时间不断变化的。

因此，对于MPEG-4视频源必须要有一个机制来感知网络条件变化以便它能够用适当的输出速率来编码视频。

理想地，我们愿在网络阻塞点实现阻塞提示以及反馈，如，在一个交换机/路由器的链路瓶颈处。

在这样的一个环境下，在交换机处设计强大的速率计算算法并将精确的可用带宽信息[6]传达给源端是可能的。

不幸地，在当前的Internet环境下，IP交换机/路由器并不积极参与反馈控制。

所有的流控制与错误恢复功能留给了端系统与上层应用。

在这样的一个环境中，我们仅能够把Internet当作一个黑盒子来对待，包的丢失与延迟不在我们的控制之中。

反馈控制算法被单独地设计在端系统，在IP交换机/路由器上没有任何附加的要求。

在本框架中，让MPEG-4视频源逐渐地增加它的传输速率以探测可用带宽。

这样的一个速率增加将首先让源速率达到可用的网络带宽，然后源速率将会超过可用网络带宽并且陷入阻塞区。

接收方通过在接收到的包中的包丢失/延迟来检测阻塞。

接收方发送反馈RTCP包给源端来通知它关于阻塞的状况。

一旦源端接收到这样的一个反馈，它就降低它的传输速率。

反馈控制的挑战在于这样一个算法的合理设计：

源端能够跟上网络带宽的变化并且网络被有效利用。

在第2.3节，给出了采用包丢失作为阻塞信号以及使用RTCP控制包来传递阻塞信息的反馈控制算法的细节。

图2-2RTP/UDP/IP模块

2.2.4源编码率控制

源编码速率控制算法的目标就是在一个给定的编码速率条件下达到最好的感知质量。

这样的自适应编码可以通过编码器的压缩比或者视频帧率单独或同时变更来完成。

传统的视频编码器一般依赖于变更编码器的压缩比来实现速率自适应的。

这些编码方案使用固定帧率执行编码。

在这些编码器中，帧速率的变更经常不被采用，因为甚至一个微小的帧率的降低都能够充分降低接收方的感知质量，尤其是在动态场景变化期间。

另一方面，MPEG-4视频编码器将每个单独的视频对象划分成VOP并对每个VOP独立进行编码。

这种视频对象的分离给我们提供了执行自适应编码的更大的灵活性。

特别地，除了对每个VOP压缩比的变更外，我们还可以在视频对象之中动态地调整目标比特率的发送。

在2.4节，将给出一个MPEG-4源编码速率控制算法。

该算法能够达到期望的输出率以及很好的感知质量。

2.2.5MPEG-4比特流打包

因为MPEG-4视频流为了在网络上传输不得不需要转换成包，所以一个打包算法是很有必要的。

由于MPEG-4的VOP特性，需要仔细地设计一个适合Internet传输的MPEG-4打包算法，因为H.261/263与MPEG-1/2不能够在这里直接被应用。

本章在2-5节将给出一个同步层的既能达到高效性又能达到健壮性的MPEG-4视频打包算法。

2.2.6错误控制

Internet包丢失的主要原因在于路由器处的阻塞。

此外，网络的多路径路由，包可能延迟到达或者接收到的包失序。

由于接收方的适时性要求，如果延迟超过了一个最大的阀值，那么这样延迟到达的视频包可能被认为是丢失的包。

尽管MPEG-4视频流能够容忍一些丢失，但它在接收端降低了感知质量。

因此，错误控制与恢复机制必须达到能够维持一个可接受的感知质量的程度。

早先的关于错误控制的工作主要集中在两方面，如前向纠错（FEC）与重传[7~9]。

因为FEC需要占用较大的带宽，所以它不可能适合于甚低速率的MPEG-4视频。

我们也不赞成基于重传的错误控制方案，因为基于重传的视频传输方案会进一步恶化网络阻塞并引起网络崩溃。

另一个处理传输中的错误与丢失的方法是错误恢复编码。

错误恢复机制包括重同步标记、数据分离、数据恢复（如反向可变长度编码，RVLC）以及错误掩盖[10~14]。

然而，重同步标记、数据分离以及数据恢复面向的是像无线信道以及并不适合于Internet的易发生错误的环境。

对于在Internet上传输视频，在接收端的可变长度编码比特流中，一个包的边界提供了一个同步点。

由于一个包的丢失也许引起所有的运动数据以及与它相关联的形状/纹理数据的丢失，像重同步标记、数据分离以及数据恢复的机制也许对于Internet视频应用没有什么有益处。

另一方面，文献[13]讨论的大部分错误掩盖技术仅适合于ATM或无线环境，并且需要实质的额外的计算复杂性，这在解码静态图像情况下是可以容忍的，但在解码实时视频时却是无法容忍与接受的。

因此，本文仅考虑一种简单的适合于Internet视频应用的错误掩盖方案。

基于以上的考虑，本文采用一种简单的如下的错误控制方案。

包的丢失由接收端的QoS监测器通过检查RTP包序列号来检测（见图2-1）。

在本章的实现中，如果