iMSC级联会议调度的研究与实现硕士毕业论文(53页).doc

《iMSC级联会议调度的研究与实现硕士毕业论文(53页).doc》由会员分享，可在线阅读，更多相关《iMSC级联会议调度的研究与实现硕士毕业论文(53页).doc（53页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-iMSC级联会议调度的研究与实现硕士毕业论文-第 47 页 iMSC级联会议调度的研究与实现 摘要由于网络的不断普及及应用，视频会议越来越广泛地应用于各个领域，视讯市场也在不断的发展壮大。目前，单个MCU(Multipoint Control Unit)所能承受的会议容量已经不能满足特定环境下的需求，而不同会议存在于不同MCU时，我们又很难进行统一管理。因此，MCU需要高效灵活的平台进行统一管理和调度，当单个MCU不能满足要求的时候，我们需要调度多个MCU进行级联，以实现会议的扩容。基于此，本文主要结合某公司开发的iMOS(IP Multimedia Open System)平台，针对MCU

2、间的互控级联进行进一步的研究和分析，实现基于iMSC(Intelligent Multimedia Service Center)平台下对MCU互控级联进行统一管理和调度。本文从会议创建、会议控制和会议备份分析其流程实现，还考虑从原MCU稳定性出发，分析比较重要的几个策略。根据级联会议的特性，分析测试的测试策略及测试方案，以保障产品在开发完成时的质量。关键词：视频会议，终端，多媒体控制单元，互控级联AbstractAs the growing popularity of the network and applications, video conferencing is becoming m

3、ore widely used in various fields, the video market has continued to grow and develop. At present, the meeting can bear a single MCU(Multipoint Control Unit) capacity can not meet the needs of specific environments, and different meetings exist in different MCU, we are difficult to unified managemen

4、t. Thus, MCU need flexible and efficient platform for unified management and scheduling, when a single MCU can not meet the requirements, we need to schedule more than one MCU cascaded to achieve the meeting of the expansion. Based on this, this paper developed iMOS (Integrate Multimedia Open System

5、) with a platform for interaction between the control cascade MCU for further research and analysis, platform-based iMSC (Intelligent Multimedia Service Center) cascade of mutual control of the MCU for unified management and scheduling. This created from the meeting, conference and meeting control a

6、nalysis of their backup processes to achieve, but also consider the stability of departure from the original MCU, the more important analysis of several strategies. According to the characteristics of cascaded conference, analysis of the test program test strategy and test to ensure product quality

7、in the development is completed.Key Words：videoconferencing, terminals, multimedia control unit, each cascade control 目录摘要iAbstractii图目录III第1章 绪论11.1 项目背景及意义11.2 级联会议现状及趋势21.3 本文主要内容4第2章 课题支撑技术简介62.1 TCP/IP及RTP/RTCP协议简介62.1.1 TCP/IP协议简介62.1.2 RTP/TCP协议简介72.2 H.323实时通信协议简介92.2.1 多点控制单元MCU92.2.2 终端102

8、.2.3 网关102.2.4 网闸112.3 iMOS平台简介112.4 本章小结13第3章 总体设计143.1 iMSC整体结构143.2 本章小结17第4章 详细设计184.1 实现策略184.1.1 MCU时间同步策略184.1.2 广播和观看下级会场策略194.1.3 会议生命周期策略204.1.4 iMSC会议参数下发策略224.1.5 当会议中MCU异常后会议角色处理234.2 创建会议-会议调度234.3 控制会议254.3.1 发言申请264.3.2 广播图像284.3.3 FECC控制304.3.4 结束会议324.4 会议备份-故障恢复334.5 本章小结36第5章 测试验

9、证375.1 测试策略385.2 具体测试方法405.2.1 配置测试405.2.2 功能测试415.2.3 性能压力测试545.2.4 异常测试555.2.5 组合测试565.3 本章小结56第6章 总结与展望57参考文献58作者简历60致谢61图目录图1.1多媒体会议组网图1图1.2 MCU按MP only模式实现互控级联总体组网图3图2.1 TCP/IP协议分层结构6图2.2 RTP报文各字段含义8图2.3 H.323典型组网图9图2.4 iMOS分层模型12图3.1 iMSC 和MCU、MG交互内部模块总体情况15图3.2级联会议实现MG、MCU及iMSC总体模块及关系17图4.1 M

10、P模块音视频处理流程图20图4.2 级联会议生命周期21图4.3 会议调度算法流程图25图4.4 级联会议发言申请流程图28图4.5 广播图像流程图30图4.6 FECC控制流程图31图4.7 FECC受控流程图32图4.8 结束会议流程图33图4.9 会议备份流程图35图4.10 查找备份MCU流程图36第1章 绪论1.1 项目背景及意义随着计算机网络、广播电视和通信技术的不断发展，随着金融、政府部门、服务、跨国等行业对通信特别是视讯会议系统的需求的不断提升，随着网络IP技术的不断发展，带宽的不断增加，视讯会议经过了数十年的发展，已经逐渐成熟化合市场化。目前，基于H.323协议的视讯会议系统

11、得到了最广泛的应用。视讯会议最基本的包含会议服务器、会议终端和网络。典型的组网图1.1：图1.1多媒体会议组网图伴随着视讯会议系统地发展，我们面临着下面几个挑战：首先，ADSL已经将2M的带宽成功的送到了大部分用户手中，而三网融合又是大势所趋，大部分用户所处网络环境的带宽会进一步提高，使用视讯系统的用户可能进一步飙升，而用户对视讯的基本知识却没有，如何提高互控级联会议中的易用性和可操作性成为视讯系统中首要关注的点。其次，由于大中型企业分布于全国各地，随着业务的不断拓展，对视讯会议容量要求也在不断提高。从用户的角度出发，如何更好的利用调度并使用会议服务器资源成为省钱的关键，也为用户更好的体验多媒

12、体带来的便利。在网络环境复杂的情况下，如何避免由于网络或会议服务器异常给用户带来损失成为开发级联会议的另一个突破点。伴随着视讯会议系统发展起来的互控级联技术会得到较好的发展机遇，而解决上面的问题，给用户带来全新的多媒体体验是此刻迫切的需求。1.2 级联会议现状及趋势首先，简单介绍下基本H.323协议下的视讯会议系统的两个最基本的组成单元会议终端MG和会议服务器MCU，具体如下：MG（Multimedia Gateway，即多媒体网关）是视讯会议系统中的终端，主要将本端会场的图像和声音进行编码并发送给远端，同时也可以接收远端的图像和声音，解码并显示于本端。MCU（Multipoint Contr

13、ol Unit，即多点控制单元）是视讯会议系统中核心的组件之一，主要集中对各个会场终端发送过来的音视频码流进行转发或编解码处理，对各个入会终端进行统一的状态信息管理和会控操作，从而实现音视频多点会议井然有序的进行。其中多点会议包含：非级联会议、简单级联会议和互控级联会议，文本主要关注互控级联会议。随着视讯会议系统不断的普及，国内华为、POLYCOM、中兴、Radvision等企业均意识到单个MCU由于硬件的限制，单台设备已经无法满足日益增长的市场需要，如何实现会议扩容和多个MCU间会议调度及资源优化成为急需解决的问题，现在国内市场上为了拓展会议容量各自采用不同的互控级联技术，而且其实现方式也非

14、常复杂，这里主要介绍两种比较典型技术：1.建立级联树，下级MCU以终端身份参加会议；2.将MCU区分为MC+MP模式和MP only模式。这里主要从功能和易用角度考虑MCU互控级联实现，具体如下：第一、建立级联树，下级MCU以终端身份参加会议该方案的设计思想为：通过建立一颗级联树，确定该局域网内所有的MCU和MG设备，通过级联树还可以确定不同MCU所在的层，最顶层为顶级MCU，有且只能由一个，该顶级MCU拥有控制该级联树上所有MCU的权限，其他的根据级联树统称为下级MCU，在会议召开后，下级MCU和MG接收顶级MCU的统一调度和管理。该方法的优点为：功能上：只要级联树建立好后，可以直接在原先的

15、MCU控制台上进行会控操作，对非互控级联会议无影响，不需要再开发一个系统，实现起来相对开发周期较短；可用/易用性：在用户熟悉原MCU系统用户界面的情况下，只要在界面上添加互控级联功能，其他不会影响原用户的使用习惯，增加易用性。该方法的缺点：功能上：在级联关系树确定好后，同为下级的MCU想进行级联会议就不能进行，造成资源的浪费；在上级MCU对设备的管理时出现瓶颈，无法在MCU上实现动态的设备管理；在会控中，如果有MCU由于网络或其他原因掉线，无法调度出其他MCU将会议信息同步过去；在会议实现过程中，不支持多个级联树并存，如果一个MCU在多个级联树中，引起权限混乱和其他一些问题。可用/易用性：对设

16、备不能进行实时管理，资源浪费比较大第二、将MCU区分为MC+MP模式和MP only模式MCU主要由MC和MP模块构成（MP为音视频处理模块，MC为多媒体控制模块），当单个MCU可满足需求时，我们配置MCU为MC+MP模式；当单个MCU满足不了用户需求时，我们需要多个MCU，并且配置一个MC和多个MP的级联会议，通过多个MP来解决单个MCU音视频数据处理不过来的瓶颈，具体如图1.2：图1.2 MCU按MP only模式实现互控级联总体组网图该方法的优点：功能上：功能的拓展了MCU的会议容量，功能上容易实现可用/易用性：没有很大的修改用户原先的使用环境，让用户感觉还是在单台MCU上进行会议，操作

17、方便该方法的缺点：功能上：实现复杂，需要修改MCU的配置，并使其注册到上级MCU上，设备的可维护性较差；用户在开完互控级联之后想单台使用时，需要自己手工配置回单台模式；在多台MCU处于不同网络或网络延迟比较高的时候，而MC和MP之间的通信比较频繁，这种方法带来的弊端是频繁的会控会控操作会使图像反应很慢，带来更高的延迟。可用/易用性：配置繁琐，灵活性较差当然，现在国内还有其他实现互控级联的方法，不过大同小异，这里不再一一列举，它们共同的缺点就是易用性和灵活性上，不能动态的分配并调度资源，导致用户只能花更多的钱，固定的使用互控级联会议网络环境，不可以随心所欲的调度。由于网络的不断普及及应用，视频会

18、议越来越广泛地应用于各个领域，视讯市场也在不断的发展壮大。目前，单个MCU所能承受的会议容量已经不能满足特定环境下的需求，而不同会议存在于不同MCU时，我们又很难进行统一管理。因此，MCU需要高效灵活地平台进行统一管理和调度，当单个MCU不能满足的要求的时候，我们需要调度多个MCU进行级联，以实现会议的扩容。基于此，本文主要结合某公司开发的iMOS平台，针对MCU间的互控级联进行进一步的研究和分析，实现基于iMSC平台下对MCU互控级联进行统一管理和调度。1.3 本文主要内容本章主要介绍多级级联会议在国内的发展状况，阐述了iMSC级联会议的开发的必要性。本文主要研究视讯会议多级级联的实现和测试

19、方案，主要分成下面6章介绍：第1章：介绍项目背景及其研究意义，分析当前过年视频会议及级联会议的研究现状和它的发展趋势。第2章：介绍在研究本课题前需要具备的专业知识。第3章：主要介绍iMSC多级会议实现的总体模块架构和级联会议调度在整个iMSC中所述的位置。第4章：主要介绍多级级联会议的实现策略，详细介绍级联会议中关键步骤如创建会议、控制会议和会议备份的实现流程和方法。第5章：主要介绍级联会议特性的测试策略及测试方案。第6章：对此次开发过程中优点和缺点的分析，并展望后续开发的需求。第2章 课题支撑技术简介2.1 TCP/IP及RTP/RTCP协议简介2.1.1 TCP/IP协议简介TCP/IP协

20、议包含IP协议（Internet Protocol）、TCP协议（Transmission Control Protocol）、UDP协议（User Datagram Protocol）、ICMP协议（Internet Control Message Protocol）和其他一些协议，此处仅对ip、tcp、icmp、udp协议进行简单介绍。TCP/IP协议可分为4层结构，分别为应用层、传输层、网络层、链路层6，具体协议应用如图2.1：图2.1 TCP/IP协议分层结构11）应用层：主要负责处理特定的网络应用程序，如SMTP应用于简单邮件传送、SNMP简单网络设备管理协议、Telnet远程访问登

21、录、FTP文件传输协议等。2）传输层：主要提供点对点的通信传输服务。主要包含：TCP协议（Transmission Control Protocol传输控制协议）和UDP协议（User Datagram Protocol用户数据报协议）。为了保证网络传输数据的可靠性，TCP提供一种可靠传输协议。它主要负责大块数据包分成多块数据包，通过包的序号，保证在传输的时候不会乱报，并且在TCP协议的报头有对数据进行验证11。而另一方面，TCP需要进行3次握手，对于一些数据比较多或者数据丢一两个包不是很重要的时候，需要一种协议来提高实时性和传输效率，UDP协议从此而产生，为应用层提供一种非常简单的服务。它仅

22、仅把数据包分组传输过去，不保证数据一定能传输到达，当使用该协议进行传输时，任何保证数据输出完整性的验证只能在应用层进行1。这两种协议各有各的优势，在不同的应用程序中发挥不同的作用，没有孰优孰劣的绝对之分。3）网络层：主要负责数据的封包传输，让每一个数据包都能达到目的地址。ICMP协议和IP协议处于同一层，主要获取IP层上的控制信息，ICMP上的Redirect信息告诉主机同乡目的地址更准确的路径，而ICMP上的Unreachable信息则表示该路径不可达或有问题。当出现路径不可用时，ICMP可以正常的中断TCP连接5。4）链路层：链路层也叫网络接口层或数据链路层，主要负责设备驱动和计算机网络设

23、备的对应。2.1.2 RTP/RTCP协议简介RTP（Real-time Transport Protocol实时传输协议）是一种多媒体数据流传输协议，它提供了点到点的媒体数据实时传输的服务。RTP协议负责将媒体流数据进行封装并传输，每个RTP数据报由头部和负载两部分组成，头部前12个字符含义是固定的，负载可以是音频数据也可以是视频数据。具体如图2.2：图2.2 RTP报文各字段含义 4其具体含义如下：1）时间戳(Timestamp)：长度为32字节。它是RTP数据信息包中第一个字节的采样时间。利用这个时间戳，接收方可以去除由网络引起的信息包的抖动，实现与接收方同步的功能17。2）序列号(Se

24、quence Number Field)：长度为16位。当发送一个RTP数据包序列号就加1，这样接收端用它来检验数据包是否有丢包，但是RTP协议本身不负责丢包数据重传，需要应用层软件来做相关处理。3）负载类型（Payload Type Field）：长度为7位，故RTP支持128种不同的载荷类型，包含采用的承载通道、采样频率、编码算法等。可通过这个域来通知接收端。如果发送端在会话过程中需改变编码方法，发送端可以发送信令通知接受端1。4）同步源标识符（Synchronization Source Identifier）：长度为32位，用来标识RTP码流数据包的第一个包，在RTP会话中的每一个数据

25、包都有一个同步源标识符。同步源标识符不是发送端所带的IP地址，而是在新数据包开始时发送端随机生成的一个号码。从上面可以看出RTP提供了点对点的传送服务，通常在UDP上运行RTP，一般使用这两种协议来完成码流的传输。RTCP（Real-time Transport Control Protocol实时传输协议的缩写），主要功能是就RTP正在提供的服务质量做出反馈，此处不做重点介绍。2.2 H.323实时通信协议简介基于H.323实时通信协议的视讯会议系统主要由下面四个部分组成：多点控制单元（MCU）、终端（MG）、网关（GateWay）、网守（GK）。H.323系统组网图具体如图2.3：图2.3

26、 H.323典型组网图2.2.1 多点控制单元MCU多点控制单元是多媒体视讯会议中最关键的设备，主要集中对各个会场终端发送过来的音视频码流进行转发或编解码处理，对各个入会终端进行统一的状态信息管理和会控操作，从而实现音视频多点会议井然有序的进行。MCU是会议中一个端点，它为其他终端及网关参加一个多点会议提供服务。它可以连接两个终端构成点对点会议，随后再扩展为多点会议。MCU通常以H.231 MCU的方式工作，但音频处理器并不是必需的。MCU由两部分组成：必需的多点控制器MC（Media Control，简称MC）和可选的多点处理器MP（Media Process，简称MP）。本系统中采用的MC

27、U是同时具有MC和MP功能的MCU。2.2.2 终端MG是视讯会议系统中的终端，主要将本端会场的图像和声音进行编码并发送给远端，同时也可以接收远端的图像和声音，解码并显示于本端。终端是H.323会议系统中面向用户的设备，也是提供实时以及双向通信的设备，提供对用户音视频信号的输入采集、压缩和解压缩输出处理，模拟会议参与者的行为，终端所在地即为用户实际所在地。初始设计时，终端仅支持语音数据的接入，随着数字化的发展，图像压缩技术的日益发展和成熟，目前绝大多数的终端设备尤其是硬终端，均支持语音、视频以及数据的融合通信方式10。H.323是当前视频会议系统使用的主流协议，它规定了不同的音频、视频以及数据

28、协同工作所需要的工作模式，该协议在很长一段时间内都将会是因特网电话、音视频终端以及视频会议系统的主要标准4。2.2.3 网关网关是H.323系统与现有的公用电路交换网(PSTN)或其它异构网络(如ISDN)的互通设备，其核心功能是对不同网络结构的会议媒体信息和信令控制信息进行转换6。也就是说如果视频会议系统的所有终端都在同一个IP网络内，那么网关则是一个可选设备。网关支持与H.320、H.324、常规电话、ISDN的其它终端类型或其它网络顺利、低时延的进行互通。网关的主要功能有以下几类：1）传输格式的转换，如对于H.323会议网络(如IP网)和电路交换网(SCN)之间就必须通过网关实现H.22

29、5.0 码流和H.221.0 码流之间的互译，以完成链路层的连接15。2）音频、视频和数据信息编码格式之间的互译，以完成表示层之间的互相通信。3）通信协议和通信规程(如H.245与H.242)之间的互译，以实现应用层的通信。4）在LAN端和WAN端进行呼叫建立和解除。 在实际的H.323视频会议系统中，在会议中的终端和MCU等处于不同的网络，如一些设备处于IP网络中，而其他设备处于PSDN网络中，这种情况下需要使用网关，或者虽然所有的设备都在同一个网络中，但是由于在传输的过程中会经过一些低速的传输通道，为了避开这种情况，也需要使用网关7。2.2.4 网闸网守是H.323视频会议系统的一个可选组

30、件，网守在系统中向终端和网关单元提供呼叫控制服务，根据接收到的指令控制是否允许用户接入该会议系统。如果该会议系统中存在网守，那么整个“域”中的设备则都要接收网守的管理。网守逻辑上可以与设备分离，目前的实现主要包含两种情况：内置GK和外置GK，内置GK是指在终端或这MCU中嵌入GK设备，实现呼叫控制，外置GK是指网守作为单独的设备对整个系统的设备进行管理控制4。根据H.323的标准得到网守主要有以下基本功能：1）地址翻译：将终端和网关的别名转换为网络地址，在实际设置使用网守的情况下，为方便起见设置test作为设备的别名，建立呼叫经过网守时，则会在相应的列表中查找该别名对应的IP地址如192.16

31、8.91.60，将该地址反馈给呼叫的另一端，这样就可以建立端到端的呼叫了。2）许可控制，即访问控制，防止未经授权的视频会话的进行。终端在发起呼叫时必须经过网守的允许，呼叫所使用的带宽最终也是由网守来决定。3）带宽控制：网守支持BRQ/BCF/BRJ消息，根据带宽管理的原则对实际接入的终端进行带宽控制。4）域管理功能：将若干终端、网关和MCU作为一个称之为H.32x域的逻辑组来进行管理另外在实际视频会议系统应用中，网守还可以起到呼叫接纳控制、呼叫信令控制等功能。2.3 iMOS平台简介IMOS 的全称为IP Multimedia Operating System（IP多媒体操作系统），与公司IT

32、oIP的理念一脉相承，意在打造IP领域的多媒体开发平台。短期内，支持监控、视讯、媒体发布业务，节约公司开发和维护成本。长远上，为H3C产品的不断丰富和完善奠定基础，为价值链上的客户和友商开发增值业务，技术合作、技术创新提供弹性的空间9。多媒体平台中间件，提供全开放的集成框架，在“多媒体基础模型”的基础上更进一步，提供“多媒体中间件”的功能。它将通过抽象具有相似特点的功能来建立各种平台组件框架，通过提供“脚本规则”或“插件规范”或”接口实现”的替换功能给用户以实现用户对组件模型的充分定制化。.SOA的开放框架，实现平台所有功能全方位的开放，实现“开发即开放”，良好的适应性和互通性，通过对多媒体应

33、用建模来实现，将体现更好的分层结构和更合理的功能划分，各个组件间功能耦合度低，可独立的实现向前演进。下面再简单介绍下iMOS平台的总体架构，如图2.4：图2.4 iMOS分层模型1).业务展示层运营商、不同行业的客户有不同的要求；取决于应用模式，还有B/S和C/S之分；不少大客户还有业务系统强集成的需求。可替换的分层模型和开发接口允许完全替换开发新的展示，多套展示可以并存，从而最大化的贴近用户的体验。2).业务逻辑层通过对原子业务的简单组合或者定制开发，可以快速构建新的业务。“搭积木”的开发方式，节省大量的重复开发成本，开发和稳定周期更短。3).多媒体基础设施层多媒体领域通用模型和标准实现，支

34、持对实现的扩展。提供了“原子”业务（基础业务）。4).数据访问层对多媒体数据的封装。数据的存在形式不受位置（本地/远程）、形式（数据库/文件/原始磁盘块）、格式（结构化/非结构化）的限制，同时支持对数据的扩展和替换。5)OS基础设施层对操作系统、数据库、多媒体协议的封装，屏蔽差异，实现上层应用的平台无关性，提高开发效率和系统兼容性。2.4 本章小结本章主要介绍TCP/IP、RTP/RTCP协议、H323实时通信协议及iMSC的开发环境iMOS。通过对TCP/IP、RTP/RTCP协议及H323协议，了解一般视频会议的实现方式，再通过iMOS平台的学习，了解iMSC级联会议分析及开发需要的知识及

35、环境，为后续总体设计及详细设计奠定理论基础。第3章 总体设计3.1 iMSC整体结构互控级联特性是在iMSC已有功能的基础上，开发支持会议级联的功能；需求来源于单个MCU的容量已经不能满足视讯会议市场的迅速发展，必须通过新的技术来解决，此时就引入了MCU的级联技术即：各个厂商均支持在一个会议中，使用多个MCU的级联关系，来增加会议容量，满足客户需求。会议备份是对会议中一种异常情况的考虑，即当召开该会议所使用的MCU出现故障无法使用时，该会议可选择其它可用的MCU继续召开，不会使得该会议被中断，无法继续召开，影响客户使用。该特性开发不改变原有系统架构，仍然通过SS(调度服务Switch Serv

36、ice)模块来实现对视讯业务的管理；仍通过接收由SDK发来的ASN.1消息进行相关逻辑的控制；通过调用MM、CC、MC等的相关平台组件接口，实现相关的业务操作，并进行业务状态信息的维护。下面先主要介绍iMSC内部的各个模块及各个模块的具体作用，具体如图3.1：图3.1 iMSC 和MCU、MG交互内部模块总体情况1）VM_SS模块：VM_SS为iMSC最核心的模块，主要负责视讯信令的接收、调度、分发和维护；负责和数据库的数据交互；VM_SS完成视讯会议的业务管理功能，通过自定义的信令和视讯设备进行交互。在设备管理方面，通过SNMP协议负责设备注册及状态维护。2）SIP-H.323网关模块：SI

37、P-H.323网关模块（包括H323协议栈的移植），用于实现视讯、监控的呼叫互通。在视讯对监控的呼叫中，视讯设备把监控域的资源看成会议的“虚拟会场”。在监控对视讯的呼叫中，监控解码端把视讯终端看成摄像机资源。这样，呼叫层面，监控视讯实现标准化意义上的互通。未来即使支持视讯录播等，控制面上也可以看成是一个呼叫过程。支持基于H323/SIP的呼叫模型，并支持各自转换网关。3）WEB SEVER模块：WEB SEVER模块接收WEB UI的HTTP请求，调用SDK的相关业务接口，并将相关响应返回给UI。4）SDK模块：SDK其内部主要封装SIP-H.323网关和VM_SS中函数，用于接收WEB SE

38、RVER的函数调用。5）Web UI/XP模块：Web UI/XP模块主要实现给用户提供图形化界面，便于操作。6）GIS SERVER模块：GIS SERVER模块主要接受WEB UI发送的HTTP请求，并返回处理后的数据。7）MDP模块：MDP模块负责内部模块间消息的转发，包括进程间和线程间8）NS模块：NS负责给各个注册到MDP的模块分发唯一的名字。9）MM：负责IMOS管理模型的构建和接口提供，包括系统管理、权限管理、设备管理、事件管理、任务管理、升级管理等功能。10）BP模块：BP是IMOS的基础平台，提供了与业务无关的底层框架功能，包括：第一、操作系统函数封装：基于ACE，封装了操作

39、系统提供的常用API，屏蔽了不同操作系统之间的差异。消息通讯框架：基于iMF，提供了基于私有ASN.1消息的进程内外部通信框架。ASN.1（AbstractSyntaxNotationOne）是一种标记语言，它可以描述计算机系统之间和各种应用程序之间要交换和传递的结构化信息，因为不同计算机接受数据后数据重组的顺序不同，所以需要定义传送数据的表达方式，即传送语法。它是一种标准的、与具体的网络环境无关的语法格式1。第二、数据库封装：屏蔽了不同数据库之间的接口差异，抽象了统一的C+接口，支持连接池和事务。运行和调试接口：提供对运行日志信息的输出、级别控制功能，同时提供对系统内部信息的在线调试功能。第

40、三、工具函数库：提供了一些常用的函数封装，如加密解密、动态库管理等。运行和调试接口：提供对运行日志信息的输出、级别控制功能，同时提供对系统内部信息的在线调试功能。如果MCU组网为简单级联，MCU各自召开自己会议，同一个会控命令发给某一个MCU还是所有的MCU，需要具体情况具体讨论。如果会控命令针对具体的一个终端，则查找该终端所在的MCU，会控命令直接下发给该MCU；否则需要将会控命令逐个下发给所有的MCU。简单级联会议召开的时候，如果存在某个MCU无法召开会议，简单级联会议仍然召开，之后的会控操作指令向如下的MCU发送：已经正常召开会议的MCU、该MCU上线。 为了实现上述iMSC的功能，需要

41、再原MCU和MG系统上配合修改，增加“iMSC平台管理模块”，由该模块负责MCU和MG侧消息的接收和下发，但这个不是本文研究的重点。其总体实现结构如图3.2：图3.2级联会议实现MG、MCU及iMSC总体模块及关系3.2 本章小结本章主要介绍iMSC各个模块及其主要作用，通过对iMSC的了解，在整体模块和流程上对级联会议有个总体上的了解，为下步详细设计打下了坚实的基础。第4章 详细设计本章主要介绍iMSC互控级联会议于实现上述功能几个主要的策略及几个主要功能的实现。4.1 实现策略4.1.1 MCU时间同步策略在互控级联会议中，时间同步十分重要，由于各个MCU上的时间以及MCU与iMSC上的时

42、间可能存在差异，所以需要对每台MCU的时间进行同步，同步各个MCU的时间可以有以下3种方式：1) 在创建互控级联会议时，获取MCU与iMSC之间的时间差，根据用户在iMSC上创建会议的时间，如果MCU的时间与iMSC上的时间不一致，在MCU上创建会议时推迟或提前召开该会议。比如iMSC上的时间为2011年3月15日10点整，且创建一个时间为1小时的会议，其中级联MCUA和MCUB，而此时在MCUA的时间为2011年3月15日9点整，MCUB的时间为2011年3月15日11点整，则在创建会议前，获取MCUA的时间与MCUB的时间后，在MCUA上创建一个从2011年3月15日9点开始持续1h的会议

43、；同样根据时间差在MCUB上创建一个2011年3月15日11点开始持续1h的会议。这种方式增加软件代码量，提高流程的复杂度，可能在软件稳定性上存在风险。2) 在创建级联会议前，检查各个MCU上的时间与iMSC上的时间是否相同，若不相同，则提示管理员去修改该MCU的上时间；如果时间不能被修改，比如正在召开会议等，则该MCU包括其下级MCU不能被级联入会；如果MCU与iMSC上的时间一致，则可以正常召开该互控级联会议。该方法可以减少软件的代码量，但是在实际使用过程中维护起来麻烦。3) 设置一个NTP服务器，在使用iMSC时先用与NTP上的时间同步，在MCU注册到iMSC上时进行一次时间同步，之后每

44、个10分钟再进行一次时间同步。这种方法比较简单，只需要在实施布置视频会议网络环境是布置一个NTP服务器就可以，降低了软件实现的复杂度，也降低的维护成本，使管理时间同步变得的简单。故在iMSC处理iMSC和MCU时间同步问题时采用该方法。解决了时间同步问题后，在后面召开会议和对会议进行控制都是在该前提下进行。4.1.2 广播和观看下级会场策略广播和观看夏季会场策略对iMSC互控级联会议影响最大，由于MCU上MP及硬件的限制，国内视频会议系统MCU和MG之间的通信都只有8路，具体为音频通道、视频通道、辅流通道、数据能力通道各占两路，其中数据能力指传输摄像机控制等信息的通道，每条通道分为上行和下行通

45、道。iMSC是基于原先稳定的MCU和MG视讯产品的基础上开发的，在互控级联中，下级MCU以终端的方式被呼叫入会，这样上级MCU与下级MCU之间的关系实际上为MCU与MG之间的能力关系，故在iMSC的互控级联中也存在该限制。即当设计广播或会场观看的时候，如果所需要的通道被占用，就不能实现该功能，也就是当广播下级会场而其他用户再执行选择观看该MCU下的其他会场，则此时不能正常观看；当多画面中有两个子画面同时为同一下级MCU的两个会场时，也不能实现。下图为MCU中MP模块音视频处理的模块图，在vpn处开启通道，然后再pool池中缓存各个数据，再发到vpc对图像进行整理，在mixer中将数据分发到各个

46、通道中，具体如图4.1：图4.1 MP模块音视频处理流程图看到上图后，也许大家还有疑问是：为什么下级会场不直接发码流给顶级MCU呢？原因很简单，下级会场已经在会议中，其视频发送的通道已经通过H.225建立连接，不能再次与顶级MCU建立连接。为了维护原先H.323视讯系统的稳定性，无法将下级会场的码流直接发送到顶级MCU。为了解决该问题，考虑通过当某个下级MCU有两路或两路以上码流需要上传时，可以通过先在该MCU上进行图像的编解码处理，这样可以实际上传一路码流，而其中包含多路码流的信息。不过这样处理带来的最大的影响就是在编解码的时候增加了延时，实现复杂，对系统影响较大，且考虑一般用户使用互控级联

47、时，均为某个组织或区域下的观看特定的会场，一般观看一个就已经足够，故在该项目第一期的时候暂不考虑。4.1.3 会议生命周期策略这里主要描述： 会议状态从未召开到活动会议，从活动会议到历史会议；以及数据库的会议数据的如何操作。会议开始与会议结束触发的具体流程，如下图图4.2 图4.2 级联会议生命周期在这里让会议开始定时器和会议结束定时器规定比正常的时间延后10秒， 以便给MCU上报状态留有时间余量，这里使用定时器为了防止当MCU离线或异常时，iMSC上的会议信息显示正常，即能正常的召开与结束。各MCU上的时间和iMSC上的时间应该保持一致（在上面策略中已经说明）， 这样可以防止会议状态混乱。当SS没有收到MCU状态上报，定时器触发。会议的召开和结束分为下面4个步骤：F1：会议预约成功后在数据库中记录会议数据，会议基本信息表中会议状态为未召开。如果预约会议是立即会议，则会议状态为召开中，直接进入F3流程。F2：会议开始定时器超时或SS收到MCU上报会议状态变更消息；则将会议基本信息表中会议状态变更为已召开； F3：SS收到MCU会议状态变更“召开中”与“在解散中”，只更新数据库会议基本信息表中会议状态，不做其他处理。F4：会议结束定时器