毕业设计（论文）-JMF语音视频聊天软件的实现.doc

目 录 摘 要随着网络的不断发展，在网络上的语音视频通信成为研究和应用的热点之一。要在网络上进行语音视频通信，便要解决音、视频信号的采集、回放、编解码以及数据的传输的问题。本文将用Java的JMF解决这些问题。JMF是Java的一种可选用的应用编程接口(API)软件包，它为音频和视频等媒体内容的采集、回放、传输和编码转换等提供了一个统一的架构。JMF用RTP协议传输实时媒体信号。RTP是针对Internet上多媒体数据流的一个传输协议。RTP能在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP建立在UDP上。RTP只保证实时数据的传输，并不提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTP的一对多的传输，由IP组播实现。IP组播是主机之间“一对一组”的通讯模式。加入了同一个组的主机可以接收到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需数据。IP组播能有效地节省网络和主机的资源，并且它允许在广域网上传输。由于NAT的存在，令许多P2P应用无法应用于NAT背后的主机，语音视频通信也不例外。根据NAT的原理，能用UDP打孔技术进行NAT的穿透。本文使用JMF完成语音视频聊天软件的实现。该软件既能进行点对点的语音视频通信，也能进行多人语音视频通信，并用UDP打孔技术完成了对NAT的穿透，使该软件能在广域网上使用。关键字：语音视频通信，JMF，RTP，组播，穿透NAT，UDP打孔技术IIIABSTRACTAlong with the constant development of the network, the voice and video communications on Internet is one of hot topic of research and application. In order to communication with voice and video on the network, it needs to solve sound and video signals collection, playback, codecs and data transmission problems. This paper uses the Javas JMF to solve these problems. JMF is an available Application Programming Interface (API) package of Java. It provides a unified framework for audio and video media content collection, playback, data conversion and transmission. JMF uses RTP to transmit real-time media signal. RTP is a special transmission protocol for Internet multimedia data streams. RTP can in point-to-point or point-to-multi-point transmission mode, the aim is to provide time information and to achieve flow synchronization. RTP bases on UDP. RTP only guaranteed real-time datas transmission. It does not provide reliable delivery mechanisms, flow control or congestion control. It relies on RTCP to provide these services. Point-to-multi-point transmission mode of RTP uses IP Multicast technology. IP Multicast is communication mode of hosts "one-to-one group". Computers join in a group can receive all the data from this group. Switches and routers only replicate and transmit the data to the computers who need the data. It can effectively to save networks and computers resources, and it is allowed to transmit on the wide-area network. Due to the existence of NAT, many P2P applications can not be used to the computers behind NAT. Audio and video communication is no exception. According to the theory of NAT, we can use UDP hole punching technology to complete NAT penetration. This paper uses JMF to complete voice and video chatting software. The software not only can be used to do point-to-point voice and video communications, but also can be used to do many-to-many communications. The software uses UDP hole punching technology to complete NAT penetration so that it can be successfully applied on WAN.Keywords: voice and video communication, JMF, RTP, multicast, NAT penetration, UDP hole punching目 录第一章 概述11.1语音通信系统的模型11.2语音聊天软件的设计2第二章 JMF基础42.1 关于JMF技术42.2 JMF模型42.3 JMF常用类52.4 事件模型11第三章 RTP、RTCP163.1 流媒体163.2 实时传输协议RTP173.3 实时传输控制协议RTCP20第四章 组播技术234.1 概述234.2 单播/组播/广播 通讯协议的特点及应用对比23第五章 穿透NAT285.1 NAT的作用285.2 NAT的分类及工作原理295.3 NAT产生的问题335.4 穿透NATUDP打孔技术33第六章 基于JMF的语音聊天软件的实现366.1 编程和运行环境366.2 主要功能模块的设计与实现366.3 运行结果476.4 总结50参考文献51致谢53- 1 -致谢 第一章 概述1.1语音通信系统的模型语音通信系统可分为以下几个模块，如图1-1所示。图1-1 语音通信系统模型1.1.1 音频信号的采集以及回放在进行音频信号的采集中，我们必须考虑到采样率的问题，声音信号的采样率有8KHz、16KHz、32KHz、44KHz等，每种数据采样率产生的数据量都不一样，越高的采样率产生的数据量越大，所以我们要选择合适的采样率以适应网络的带宽1。1.1.2 音频数字信号的编码与解码如果直接把采集到的音频信号数据流在网络上进行传输，它所占有的带宽也是十分大的，以8KHz的采样率采集14位的音频数据，那么就有以下这样的一个式子：14 bit × 8000Hz = 112,000 bits/second or 112 kbps从中我们可以看出以这样的方式传输音频数据，每秒需要向网络中发送112kb的数据。从节省带宽的角度考虑，我们很有必要对这样的数据进行压缩。对多媒体信号的压缩我们有许多可以选择的格式，如mp2、mp3、GSM等等。所以，我们这里也存在一个对压缩格式进行选择的问题，考虑到音频数据传输的及时性，对传输的音频数据质量的要求，以及各种压缩格式的压缩比率以及进行压缩和解压缩所要耗费的系统资源等方面问题，选择合适的压缩格式就显得尤为重要。1.1.3双方之间的数据传输网络上传输数据，有TCP和UDP。TCP较可靠，所以应用在不允许数据丢失的应用上。而UDP则较多应用于处理速度要求较快、数据传输可靠性要求不是很高的应用上，如数据广播。通信协议的选择取决于我们所要做的应用的类型。怎样建立网络连接，稳定的接收和发送音频信号的数据流是关键。1.2语音聊天软件的设计要实现在网络上进行语音通信，便要解决音频信号的采集、回放、编解码以及数据的传输的问题。Java的JMF是一种应用编程接口(API)软件包，它为音频和视频等媒体内容的捕获、回放、传输和编码转换等提供了一个统一的架构。本文将使用JMF完成对语音通信软件的设计。本文在第二章介绍了JMF的有关知识，第三章介绍RTP、RTCP原理，在第六章给出实现的方法。鉴于语音聊天软件的发展，多人语音聊天已成为语音聊天软件必不可少的一个功能，所以本软件也加入了这一功能。当前的网络中有三种通讯模式：单播、广播、组播。我们能够用这三模式中的其中一个完成多人语音聊天这一功能。单播为一对一的信息传送，如果10个客户机需要相同的数据，则服务器需要逐一传送，重复10次相同的工作，浪费网络和服务器的资源。发送广播，子网内所有主机均可收到数据报，通信量巨大，智能低，并且不允许跨越网段。组播为主机之间“一对一组”的通讯模式，加入了同一个组的主机可以接收到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需数据。由以上三种模式的比较，本文运用组播技术实现多人语音聊天这一功能。本文第四章介绍组播的基础知识，在第六章给出实现的方法。在广域网，P2P软件可能失灵，主要是由于NAT设备的存在。NAT是在IP地址日益缺乏的背景下产生的，它解决了地址不够用的问题。但它也导致了内外网无法直接通信或受到某些限制的问题。要使语音通信软件能在广域网上无误地运行，该软件便要穿透NAT。本文在第五章介绍了NAT的基本原理及NAT的穿透方法，在第六章给出实现的方法。- 53 -第二章 JMF基础2.1 关于JMF技术JMF(Java Media Framework)，Java媒体架构，是对应Java 2平台标准版(J2SE)的一种可选用的应用编程接口(API)软件包，它为音频和视频等媒体内容的捕获、回放、传输和编码转换等提供了一个统一的架构。JMF技术提供了先进的媒体处理能力，从而扩展了Java平台的功能。这些功能包括：媒体捕获、压缩、流转、回放，以及对各种主要媒体形式和编码的支持，如M-JPEG、H.263、MP3、RTP/RTSP (实时传送协议和实时流转协议)、Macromedias Flash、IBM的HotMedia和Beatniks的Rich Media Format (RMF)等。JMF 2.1.1还支持广受欢迎的媒体类型，如Quicktime、Microsofts AVI和MPEG-1等。此外，JMF软件中包括了一个开放的媒体架构，可使开发人员灵活采用各种媒体回放、捕获组件，或采用他们自己的定制的内插组件。2.2 JMF模型在开发JMF应用程序之前要理解JMF的体系架构、接口和类。就拿我们的家用摄像机系统作个例子。如图2-1所示，首先用摄像机拍摄内容，拍摄下来的内容录制在DV带中。DV带可以放在播放器里播放，播放器提供视频信号给电视机，提供音频信号给音箱，这样我们就可以在电视机上看到画面，从音箱那里听到声音。JMF API提供的也是同样的模型，从采集设备(Capture Device)里得到信号，放在数据源（DataSource）里，然后交给播放器(Player)播放，Player根据信号的格式，分别将它们送给不同的目的地（Destination）2。图2-1 JMF模型2.3 JMF常用类JMF的常用类包括以下几个： 数据源（DataSource） 媒体定位器（MediaLocator） 播放器（Player） 处理器（Processor） 数据池（DataSink） 数据格式（Format） 管理器（Manager） RTP管理器（RTPManager）2.3.1 数据源就像DV带中保存了视频和音频信号一样，数据源（DataSource）中包含了媒体数据流。在JMF中，DataSource对象就是数据源，它可以是从采集设备获得的数据，也可以是一个多媒体文件，也可以是从互联网上下载的数据流。对于DataSource对象，一旦你确定了它的位置和类型，对象中就包含了多媒体的位置信息和能够播放该多媒体的软件信息。当创建了 DataSource对象后，可以将它送入Player对象中，而Player对象不需要关心DataSource中的多媒体是如何获得的，以及格式是什么3。2.3.2 媒体定位器DataSource通常用两种方式来定义，媒体定位器（MediaLocator）或URL（Universal Resource Locator）。MediaLocator类似于URL，并且可以由URL来构造，即使在没有安装相应的协议处理机制的情况下，也能构造MediaLocator（在Java，只有在系统上安装了URL协议的处理机制的情况下，才能构造一个URL）。MediaLocator用来定位采集设备、本机的媒体文件、网络上的媒体文件以及网络RTP流。2.3.3 播放器如图2-2所示，播放器（Player）对象将音频、视频数据流作为输入，然后将数据流输出到音箱或屏幕上，就像播放器读取DV带中的数据，然后将音频信号送到音箱上，视频数据送到屏幕上一样。图2-2 JMF播放器（Player）模型Player对象有多种状态，JMF中定义了Player有六种状态，如图2-3所示。在正常情况下Player对象需要经历每个状态，然后才能播放多媒体。下面是对这些状态的说明。图2-3播放器的状态转换图 Unrealized：在这种状态下，Player对象已经被实例化，但是并不知道它需要播放的多媒体的任何信息。 Realizing：当调用realize( )方法时，Player对象的状态从Unrealized转变为Realizing。在这种状态下，Player对象正在确定它需要占用哪些资源。 Realized：在这种状态下Player对象已经确定了它需要哪些资源，并且也知道需要播放的多媒体的类型。 Prefetching：当调用prefetch( )方法时，Player对象的状态从Realized变为Prefetching。在该状态下的Player对象正在为播放多媒体做一些准备工作，其中包括加载多媒体数据，获得需要独占的资源等。这个过程被称为预取（Prefetch）。 Prefetched：当Player对象完成了预取操作后就到达了该状态。 Started：当调用start( )方法后，Player对象就进入了该状态并播放多媒体。当一个播放器从一个状态转换到另一个状态时，它将产生TransitionEvent事件（详细请看2.3 事件模型）。通过ControllerListener接口，你的程序可以确定播放器在什么状态并作出相应的反应。使用这种事件报告机制，你可以在调用播放器的方法前确定播放器是否在其适当的状态。为了避免混乱情况，在一个播放器所有状态下，不是所有的方法都能被调用的。如果你在一个播放器对象的当前状态下，调用了一个非法的方法，播放器对象将抛出异常或错误。2.3.4 处理器处理器（Processor）对应的接口是Processor。在JMF API中Processor接口继承了Player接口。Processor同样可以用来播放媒体数据。它是一种特殊的播放器，它可以对输入媒体流进行过程控制。处理器支持所有播放器拥有的播放控制功能。如图2-4所示，除了将媒体数据传送至播放终端外，处理器可以将媒体数据输出至一个数据源（DataSource），使用Processor的getDataOutput( )方法实现，此数据源可以作为其它的播放器的数据源，或是通过其它的处理器对其进行进一步操作控制，或将其作为数据池（DataSink）的参数，利用数据池或存储到一个文件，或传送到网络中去。图2-4 处理器模型如图2-5所示，除了在播放器中提到了的6种状态以外，处理器对象还包括两种新的状态。这两种状态是在Unrealized状态之后，在Realizing 状态之前。 Configuring：当调用configure( )方法后，处理器对象进入该状态。在该状态下处理器对象连接到数据源并获取输入数据的格式信息。 Configured：当完成数据源连接，获得输入数据格式的信息后，处理器对象就处于Configured状态。图2-5 处理器的状态转换图2.3.5 数据池数据池（DataSink）用来读取数据源（DataSource）的媒体数据和输出到特定的目的地这里的目的地不同于以上所说的如音箱或屏幕。一个特定的DataSink或把数据输出到一个文件，或通过网络传输数据，或进行RTP广播。像Player一样，DataSink对象以DataSource作为参数，通过管理器（Manager）来构造。2.3.6 数据格式在JMF架构中，数据格式（Format）对象中保存了媒体的格式（format）信息。它并不包括编码参数和全局时间信息。只是描述了该格式的编码名称和数据类别。Format的子类包括 AudioFormat和VideoFormat类，VideoFormat又有六个子类：H261Format、H263Format、IndexedColorFormat、JPEGFormat、RGBFormat和YUVFormat类4。在AudioFormat中，描述了音频格式的属性，如采样频率、每次采样的数据位数等等。在VideoFormat中则描述了视频数据的类型如H.263等。图2-6 表示JMF对音频格式和视频格式的定义：图2-6 JMF的媒体数据格式2.3.7 管理器JMF提供了下面四种管理器（Manager）： Manager：Manager相当于两个类之间的接口。例如当你需要播放一个DataSource对象，你可以通过使用Manager对象createPlayer( )方法创建一个 Player对象来播放它。使用Manager对象可以创建Player、Processor、DataSource和DataSink对象。 PackageManager：该管理器中保存了JMF类注册信息。 CaptureDeviceManager：该管理器中保存了截取设备的注册信息。 PlugInManager：该管理器中保存了JMF插件的注册信息。2.3.8 RTP管理器JMF在javax.media.rtp，javax.media.rtp.event，和javax.media.rtp.rtcp中定义了有关RTP的API，我们可利用它们进行RTP流的发送和接收。关于RTP的相关概念，请参考第三章。如图2-7所示，通过管理器（RTPManager），我们可以把采集到的音频或视频数据发送出去，或把本地的媒体文件发送出去。图2-7 RTP的发送如图2-8所示，通过RTPManager，我们也可以接收RTP数据流，并在本地播放它们，也可以把它们保存到文件。图2-8 RTP的接收在RTP传输中，如果还是用传统的AVI，MOV格式，将会增加服务器负荷，而且对网络要求特别高，因此需要将传统格式转化至易于传送的，网络适应性好，抗丢包性能和抗误码性能好的编码格式。表2-1是JMF支持的音频、视频在RTP传送的压缩格式，也就是说经过定制后的输出媒体流，还得进行一次转换，以便网络发送。表2-1 JMF支持的视音频在RTP传送中的格式多媒体类别RTP传输格式音频AUDIO_G711_ULAW/rtp，dvi/rtp ，g723/rtp ，gsm/rtp视频jpeg/rtp，h261/rtp，h263/rtp2.4 事件模型JMF利用事件报告机制来使基于JMF的程序获知媒体系统当前的状态，从而使程序能够对相应状态的改变作出相应的操作。在任何时候，当一个JMF对象需要报告当前的状态，它将发出一个MediaEvent事件。MediaEvent的子类包括ControllerEvern，DataSinkEvent，GainChangeEvent，RTPEvent。对于任何一个能发送MediaEvent的JMF对象而言，JMF都定义了一个相应的侦听接口(listener interface)。为了能在某一MediaEvent事件发生时得到相应的通知，必须实现适当的侦听接口以及在对应的类体中重写该接口中处理MediaEvent事件的方法体，并通过调用addListener方法来接收此MediaEvent事件。如图2-9所示，JMF中的Controller对象，例如播放器（Player）和处理器（Processor），以及Control对象，例如GainControl都可以发出MediaEvent事件。（Player和Processor继承于Controller类）图2-9 JMF的事件模型RTPManager对象也能产生事件，请看2.3.2 RTP事件。2.3.1 Controller事件图2-10 JMF Controller事件图2-10列出了所有的Controller事件，ControllerEvent由Controller（如Player或Processor）产生，可分为三类：改变通知（change notification），关闭事件（closed event），状态转变事件（transition event）：1改变通知事件如RateChangeEvent，DurationUpdateEvent，FormatChangeEvent表明一些Controller的属性的改变。2状态转变事件可以使你的程序对Controller对象的状态转变作出反应。Player当从一个状态转为另一状态时都会产生transition events。3当Controller关闭时，它将产生关闭事件。2.3.2 RTP事件RTP事件用来报告RTP会话和RTP流的状态。图2-11列出了所有的RTP事件。RTP事件可分为四类，ReceiveStreamEvent，通过它得到一个正在接收的RTP数据流状态的改变信息；RemoteEvent，通过它得到远端会话参与者的时间或RTP控制信息；SendStreamEvent，通过它得到一个正在传送的RTP数据流状态的改变信息；SessionEvent，通过它得到一个会话状态的改变信息。主要常用的几个事件：NewParticipantEvent：表示一个新的参与者加入会话。NewReceiveStreamEvent：表示RTPManager已经创建了一个从新的侦测到的地址传来的接收数据流。图2-11 JMF RTP事件第三章 RTP、RTCP3.1 流媒体3.1.1 流媒体概念流媒体(Streaming Media)技术是网络技术和多媒体技术发展到一定阶段的产物。术语流媒体既可以指在网上传输连续时基媒体的流式技术，也可以指使用流式技术的连续时基媒体本身。在网上传输音频、视频等多媒体信息目前主要有两种方式：下载和流式传输。采用下载方式，用户需要先下载整个媒体文件，然后才能进行播放。由于网络带宽的限制，下载常常要花很长时间，所以这种处理方式延迟很大。而流媒体实现的关键技术是流式传输。传输之前先对多媒体数据进行预处理(降低质量和高效压缩)，然后使用缓存系统来保证数据的连续传输。使用流式传输方式，用户不必像采用下载方式那样要等到整个文件全部下载完毕，而是只需经过几秒到几十秒的启动延时即可在客户端进行播放和观看，此时媒体文件的剩余部分将在后台继续下载。与单纯的下载方式相比，这种对多媒体文件边下载边播放的流式传输方式不仅使启动延时大幅度地缩短，而且对系统缓存容量的需求也大大降低。使用流式传输的另一个好处是使传输事先不知道或无法知道大小的媒体数据(如网上直播、视频会议等)成为可能。到目前为止，Internet上使用较多的流式视频格式主要有以下三种：RealNetworks公司的RealMedia，Apple公司的QuickTime以及Microsoft公司的Advanced Streaming Format (ASF)。3.1.2 支持流媒体的协议多媒体应用的一个显著特点是数据量大，并且许多应用对实时性要求比较高。传统的TCP协议是一个面向连接的协议，它的重传机制和拥塞控制机制都是不适用于实时多媒体传输的。RTP是一个应用型的传输层协议，它并不提供任何传输可靠性的保证和流量的拥塞控制机制。RTP位于UDP(User Datagram Protocol)之上。UDP虽然没有TCP那么可靠，并且无法保证实时业务的服务质量，需要RTCP实时监控数据传输和服务质量。但是，由于UDP的传输时延低于TCP，它能与音频和视频很好地配合。因此，在实际应用中，RTP/RTCP/UDP用于音频/视频媒体，而TCP用于数据和控制信令的传输。目前，支持流媒体传输的协议主要有实时传输协议RTP(Real-Time Transport Protocol)、实时传输控制协议RTCP(Real-Time Transport Control Protocol)和实时流协议RTSP(Real-Time Streaming Protocol)等。下面分别对RTP和RTCP协议作简要介绍。3.2 实时传输协议RTPRTP（Real-Time Transport Protocol）是针对Internet上多媒体数据流的一个传输协议，由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP之上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务5。3.2.1 RTP工作机制威胁多媒体数据传输的一个尖锐的问题是数据到达时间的不可预料性。但是流媒体的传输要求数据的实时到达。RTP协议提供了时间标签、序列号以及其它的结构用于控制实时数据的播放。在流的概念中“时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽地设置了时间标签。在接收端收到数据包后，就依照时间标签，按照正确的速率恢复成原始的实时数据。RTP本身并不负责同步，RTP只是传输层协议，为了简化运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。RTP协议和UDP二者共同完成传输层协议功能。UDP协议只是传输数据包，不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。RTP协议虽然是传输层协议，但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务，RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。3.2.2 RTP协议的报文结构图3-1 RTP头格式各段含义如下：1版本（V）：2位，标识RTP版本。 2填充标识（P）：1位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。 3扩展（X）：1位，如设置扩展位，固定头部后跟一个头扩展。 4CSRC计数（CC）：4位，CSRC计数包括紧接在固定头后CSRC标识符个数。 5标记（M）：1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位。6载荷类型（PT）：7位，记录使用哪种Codec，接收端找出相应的decoder解码。表3-1列出了常用的载荷类型。表3-1 常用类型Payload TypeCodec0PCM -Law8PCM-A Law9G.722 audio codec4G.723 audio codec15G.728 audio codec18G.729 audio codec34G.763 audio codec31G.761 audio codec7序列号：16位，序列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。 8时标：32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让接收端知道在正确的时间将数据播放出来。图3-2 时标由上图3-2可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将数据正确播放出来，如此我们才能播放出正确无误的信息。9SSRC：32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。10CSRC列表：0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。3.3 实时传输控制协议RTCP在RTP会话期间，各参与者周期性地传送RTCP(Real-Time Transport Control Protocol)包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。RTCP负责管理传输质量并在当前应用进程之间交换控制信息。3.3.1 RTCP工作机制当应用程序开始一个RTP会话时，它将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，应用程序可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。3.3.2 RTCP数据报在RTCP通信控制中，RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：1SR:发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。2RR:接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。3SDES:源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。4BYE:通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。5APP:由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。第四章 组播技术4.1 概述1组播技术引入的必要性随着宽带多媒体网络的不断发展，各种宽带网络应用层出不穷。IPTV、视频会议、数据和资料分发、网络音频应用、网络视频应用、多媒体远程教育等宽带应用都对现有宽带多媒体网络的承载能力提出了挑战。采用单播技术构建的传统网络已经无法满足新兴宽带网络应用在带宽和网络服务质量方面的要求，随之而来的是网络延时、数据丢失等等问题。此时通过引入IP组播技术，有助于解决以上问题。组播网络中，即使组播用户数量成倍增长，骨干网络中网络带宽也无需增加。简单来说，成百上千的组播应用用户和一个组播应用用户消耗的骨干网带宽是一样的，从而最大限度的解决目前宽带应用对带宽和网络服务质量的要求6。2IP组播历史在1980年代初斯坦福大学的一位博士生叫Steve Deering，在为其导师David Cheriton工作，设计一种叫做Vsystem的分布式操作系统。此操作系统允许一台计算机使用MAC层组播向在本地Ethernet段的一组其他计算机传递信息。随着工作的扩展组播必须跨越路由器，所以必须将组播扩展到OSI模型的第三层，此历史重任落到了Steve Deering身上，他总结了组播路由的通信协议基础，并最终在1991年12月发表的博士论文中进行了详细的阐述。4.2 单播/组播/广播 通讯协议的特点及应用对比当前的网络中有三种通讯模式：单播、广播、组播，其中的组播出现时间最晚，但同时具备单播和广播的优点，最具有发展前景。4.2.1 单播主机之间“一对一”的通讯模式，网络中的交换机和路由器对数据只进行转发不进行复制。如图4-1所示，如果9个客户机需要相同的数据，则服务器需要逐一传送，重复9次相同的工作。但由于其能够针对每个客户的及时响应，所以现在的网页浏览全部都是采用IP单播协议。网络中的路由器和交换