多媒体系统中基于号码分析的呼叫路由框架的设计和实现硕士学位论文 精品.docx
- 文档编号:5154881
- 上传时间:2022-12-13
- 格式:DOCX
- 页数:57
- 大小:1.33MB
多媒体系统中基于号码分析的呼叫路由框架的设计和实现硕士学位论文 精品.docx
《多媒体系统中基于号码分析的呼叫路由框架的设计和实现硕士学位论文 精品.docx》由会员分享,可在线阅读,更多相关《多媒体系统中基于号码分析的呼叫路由框架的设计和实现硕士学位论文 精品.docx(57页珍藏版)》请在冰豆网上搜索。
多媒体系统中基于号码分析的呼叫路由框架的设计和实现硕士学位论文精品
硕士学位论文
多媒体系统中基于号码分析的呼叫路由框架的设计与实现
摘要
目前,多媒体系统已经应用到各个重要场合,各种各样的多媒体终端频频而出,从我们熟知的摄像机,监视器,电视墙,到现在的高清IPC等等,这些终端的发展,使得多媒体系统的功能也越来越强大了。
然而,现有的多媒体系统不是很完善,还有着许多需要改进的地方,比如多媒体系统中服务器与终端之间的交互以及服务器本身之间的交互的恢复机制等。
呼叫路由是多媒体系统的组成部分,旨在通过呼叫路由模块来找到各个终端和服务器的地址,以便完成服务器和终端之间的会话。
本文基于对呼叫路由模块的实现,分别从多媒体系统的组网、传输协议、数据库等方面对多媒体系统进行分析,指出了多媒体系统的一些需要改进的地方和改进的方案。
同时,本文为多媒体系统提供了一个独立的呼叫路由模块并完成呼叫路由模块数据库的设计、编码方案的设计和呼叫路由框架的设计。
针对呼叫路由的框架,本文给出了呼叫路由模块的几个主要的数据结构和函数接口,以便进一步分析呼叫路由框架的实现过程。
在呼叫路由模块的实现中,本文参考了电话交换网络中的号码分析的应用技术,为多媒体系统制订了一套基本的编码方案。
基于本文设计的呼叫路由模块,本文还为多媒体系统的业务的恢复提供了相关的实现策略并给出了多媒体系统中业务恢复的实例。
关键词:
多媒体系统,终端,呼叫路由,号码分析,会话
Abstract
Atpresent,IPMultimediaOperatingSystemhasbeenappliedtomanyimportantoccasions,variousmultimediaterminalscomeoutmoreandmorefrequentlyasweknow,fromthecamera,monitor,TVwall,tothepresenthighdefinitionIPC,etc,theseterminals’developmentmakesthemultimediasystembeingstrongerandstronger.However,theexistingmultimediasystemisnotperfectenough,therearemanyareasinneedofimprovementinthemultimediasystem,suchastherecoverymechanismoftheinteractionbetweenserversandterminalsinthemultimediasystemortheinteractionbetweenserversitself.Callroutingisacomponentofthemultimediasystem,aimstofindoutaddressesofthevariousterminalsandserversfromvisitingcallroutingmoduleinordertofinishthesessionsbetweenserversandterminals.Thisarticlesuggestssomeareasinneedofimprovementandtheimprovementplanbyanalyzingthemultimediasysteminthepointsofthemultimediasystem’snetworking,transferprotocol,databaseandsoonwhichbasedontherealizationofthecallroutingmodule.Atthesametime,thisarticleprovidesaseparatecallroutingmoduleformultimediasystem,completesthedesignforcallroutingmodule’sdatabase,codingschemeandframework.Accordingtotheframeworkofthecallroutingmodule,thispapergivesseveralmaindatastructuresandinterfacefunctionsinordertofurtheranalysiscallroutingframework’simplementationprocess.Bylearningtheapplicationtechnologyofthetelephoneexchangenetwork,thisessaydevelopsasetofbasiccodingschemeformultimediasystemintherealizationofthecallroutingmodule.Basedonthisdesign,thispaperalsoprovidessomestrategiesformultimediasystem’sbusinessrecoveryandgivessomebusinessrecoveryexamples.
KeyWords:
multimediasystem,terminals,call-routing,numberanalysis,session
图目录
表目录
第1章绪论
1.1多媒体系统的发展
1.1.1多媒体系统简介
本课题所研究的多媒体系统,也即IP多媒体系统(IPMultimediaOperatingSystem),简称IMOS[1]。
IP多媒体系统是一个基础的开发平台,短期内,支持监控、视讯、媒体发布等业务,节约开发和维护成本。
长远上,为产品的不断丰富和完善奠定基础,为价值链上的客户和友商开发增值业务,技术合作、技术创新提供弹性的空间。
目前,一些公司已经研究出自己的多媒体系统供使用,本课题所研究的多媒体系统,也即IMOS系统,是目前国内最普遍使用的多媒体系统之一。
多媒体系统已经形成了一个稳定的开发平台,基于这个开发平台,多媒体系统将逐步地完善功能,系统也越来越智能化,人性化。
1.1.2多媒体系统的应用
多媒体系统,包括多媒体软件系统和硬件系统,结合相关的应用领域,充分利用多媒体技术的关键特性,集成多种媒体的关联信息,就可以构成多媒体的应用系统[2]。
起初,多媒体终端类型并不是太多,并且应用场合很有限,还没有形成一个真正的多媒体系统。
随着应用的逐渐推广,终端类型的增多,管理这些终端,保持终端之间的会话越来越麻烦,多媒体系统才逐渐的发展起来。
目前多媒体系统还在进一步发展中,但是多媒体系统确实已经得到了极大的应用。
在电影里我们经常能到一个个的“监控室”,在监控室里,你可以看到本楼内几乎所有地方的视频,这就是多媒体监控领域的应用之一,当然,现在监控领域的应用远比那个“监控室”多的多,因为现在的多媒体系统支持的业务已经有很多了。
在交通系统中,我们需要监视路段的车辆情况,在公安局内,监狱等重要地方,我们需要全方位的监控各个角落,在景区内,我们也需要对各个景点进行监控,而且监控的角度还需要能够实时的调整,有时候更需要远距离监控,这些都是监控领域的应用,当然,要完成这些监控,需要一个足够强大的系统来支持这些业务。
IP多媒体系统发展至今,从功能上足够完成这些功能,所以,在国内的应用是非常广的。
早在20世纪80年代中期就投入人力与物理从事多媒体技术的开创性研究工作,涌现出一批具有代表性的公司和多媒体系统,如Commodore公司的Amiga系统,Apple公司的HyperCard系统,Philips/Sony公司的CD-I系统,Intel/IBM公司的DVI系统等[3]。
随着开发的逐步发展,多媒体系统的业务也会日益丰富,不难想象,将来的多媒体系统是十分智能和人性化的。
1.2多媒体系统的管理
1.2.1多媒体系统的终端管理
上面我们说过多媒体的一些应用,为了完成这些实际的需求的功能,系统应该足够强大来支持这些终端业务。
IMOS目前支持的业务有很多,比较重要的有下面几类:
实况,实况又可以分为硬解实况和软解实况。
完成实况首先需要的终端的采像设备,就是摄像机,采像设备把所得的媒体数据发送到编码器上。
编码器会根据配置的一些规则,比如H.264码流[4],进行编码,把媒体流变成数据流。
要想看到实况,就需要另一样设备,解码器和播放器,解码器用来解码,接收编码器发送过来的数据流,硬解实况的播放器是一个实体终端,比如监视器,电视墙等,解码器发送过来的媒体流可以在这些终端上播放。
软解实况的播放器是兼容在系统上的,有一个XP播放窗口,可以解码和播放实况。
云台控制,云台简单的说是一个可以转动的摄像机。
摄像机的角度比较死,不能自动的去移动,如果想换一个角度,看下周围的实况,就需要云台了。
多媒体系统支持云台的控制,随时可以控制云台的角度。
云台的出现大大节省了摄像机资源,一个云台足够把周围地区都监视起来了。
告警,告警是一个辅助功能,用来捕获一些异常,比如运动告警,如果监视器的某些地方出现画面变化,就会启动告警通知值班人员进行处理,这些应用大大节省了人力资源,还有很多告警类型,比如高温告警,画面丢失告警等等,告警的出现使管理方便很多。
IMOS还有很多其他的功能,完成这些功能,如上面所说,就需要IMOS能够管理这些终端,使终端能够正常的会话。
IMOS要管理的终端类型很多,有软终端和硬终端,如编码器(EC),解码器(DC),播放器(XP),媒体转发服务器(MS),监视器,摄像机,云台等等。
IMOS的终端管理与电话的管理有点类似。
要完成终端的管理,首先需要把各个终端注册到服务器上,不同的终端都在一个服务器上,这样就通过服务器来完成本域的终端管理。
当然不可能把所有的终端都注册到一个服务器上,一则远距离注册不方便,二来服务器性能会受到很大挑战。
所以,IMOS为了解决这个麻烦,设计出了多级多域管理系统,服务器之间进行注册管理,在一个服务器上能够通过共享域资源,使用其他域的终端,这样就完成了跨域的终端之间的交互。
在跨地区的终端管理中,目前就是这种形式,不同的是,IMOS的多级域有上下级域之分,就是,两台服务器的地位不是对等的,上级域能够使用下级域共享(推送)的资源,而上级域不能像下级域推送资源,这样做主要是为了完成管理的一个权限的划分。
1.2.2多媒体系统的一些缺陷
多媒体系统目前还在发展阶段,作者所在的公司的多媒体开发部门一直在努力去打造一个综合型的操作平台,目前在国内的业界发展已经较为先进。
小规模的终端应用简单的多,我们通过其他硬件终端来分析一下多媒体的发展。
就像电话机的出现一样,电话在发展的初始阶段,因为电话终端很少,所以可以通过简单的直连等就可以接通电话,所以初期,电话就没有什么较成型的管理方案。
然而,随着终端量的扩大,发现最初的管理相当麻烦,大量排线等造成了电话业务的致命影响,所以才会有一个“服务器”管理系统的出现,电话机通过连接到服务器,由服务器进一步进行管理,这样会少了很多麻烦,并且扩充了很多业务。
然而,随着终端数量的再一部扩大,电话的寻址方案越显重要了,为了能够完成电话间的寻址,服务器上有一套强大的路由寻址方案,而且经过这么多年的发展,电话交换网的发展已经相当成熟了。
多媒体的发展也是一样,随着项目的逐步扩大,多媒体终端也会越来越多,多媒体系统的应用也会越来越广。
这样问题就来了,如果把大量的终端都注册到一个服务器上,那显然是不行的,因此,本作者所在公司推出了多级多域管理方案,也就是把多台服务器相互注册,完成服务器间的资源共享。
在这套方案中,不可避免的会出现一个路由寻址的子方案,因为设备间终究是要寻址的。
而目前的多媒体系统因为设备量,开发代价等,没有把路由这一块做的很好,只是简单的和业务放在一起处理一下,提供了一个简单的路由查询接口供使用。
这样,业务的实现就会受到一定的限制,多台服务器间的管理由于路由的限制会受到一些影响。
还有,多媒体终端类型将会越来越多地出现,对这些终端的支持也是一个需要解决的问题。
还有就是业务的实现了,这是目前正在逐步解决的,对于新业务的实现也是一个需要长期解决的问题。
具体的缺陷会在第四章给出详细的解释与说明。
1.3本课题的研究背景以及拟解决的问题
1.3.1课题来源
本课题源于多媒体系统的业务和路由模块和IPX系统[5]的呼叫路由方案的实现。
作者经过对目前多媒体系统的一些特征的分析,总结出一些改善的方案,同时吸取现在的电话交换网络[6]的一些技术,完成一套分析设计文档。
本课题就是基于这套方案展开来,对路有模块逐步分析,形成了一个独立的路由的框架。
1.3.2呼叫路由技术在多媒体中的应用
在解决路由的问题之前,我们先来看一看目前呼叫路由在多媒体系统中的实现方式。
在目前的多媒体系统中,路由模块与业务模块集成在一起。
数据库中会有一张专门存放路有信息的路有表,在这张路由表中,存放的有终端设备的编码,IP地址,地址类型,端口号,以及nat穿越的地址信息。
路由模块会提供一个查询的接口来实现路由信息的查询,在需要应用地址查询的控制模块就直接调用这个接口就行了。
因为接口的代码量不是很大,所以没有单独做成一个模块,不划算,就直接写在控制模块里了。
路由表里还含有域的地址信息,通过查询路由表能够帮助业务控制模块查询到设备所在域的地址,然后再通过设备所在域服务器进一步查询。
这样就可以顺藤摸瓜,总能找到设备。
1.3.3课题拟解决的问题
本课题拟解决一些路由方面的问题,设计了一个新的路由模块,解决终端之间只有一条路径可达的局限性问题,同时智能化了呼叫路由模块的功能。
具体来说可以分为以下几个子问题。
路由表的规划。
对目前的路由表重新规划设计,使得数据库能够更方便地支持路由模块的功能,进而能支持更多的业务和增加效率。
设备编码。
对终端设备进行编码,为业务的实现增加提供方便,也为基于号码分析的呼叫路由的实现打下基础。
呼叫路由框架设计。
根据现有的一些呼叫路由技术和其他领域中的呼叫路由的应用,为多媒体系统提供一个有效的呼叫路由的模块结构。
基于以上三点,本文的问题与工作也就有了初步的认识,在后面几章里,作者将会对于多媒体的具体的一些会话的业务,多媒体系统的改进分析和呼叫路由的设计给出详细的分析和说明。
1.4本章小结
本章主要介绍了多媒体系统的一些应用,其中包括多媒体应用系统和终端设备等,基于这些指出了目前多媒体系统的一些缺陷。
本章还指出本课题所做的工作与目前哪些多媒体系统的缺陷的关系,利用本课题研究的成果,对多媒体系统有哪些改进。
同时,在本章中引入了本课题研究的对象,也就是呼叫路由的寻址,由此进一步指明了本课题所做的工作,也就是设计和实现一个独立的呼叫路由框架,以及在设计和实现过程中所需要的几项具体的工作和参考的资料等,为后面的具体的分析和设计打下基础。
第2章多媒体系统业务分析
2.1多媒体系统的基本架构
多媒体系统的业务很多,涉及到会话类的业务也有数十种之多,但这些业务都有一个基本的流程,这些业务也都会基于一个基础的多媒体架构来实现。
下面我们分别对IMOS的架构,组网,会话业务进行分析。
2.1.1多媒体业务通用的三层架构体系
图2.1多媒体三层架构图
如图2.1,这个是多媒体的基本三层架构[5]。
目前许多的多媒体系统都是基于这个架构衍生而来,对每个层进行逐步的细化。
我们能通过系统界面等看到一系列的业务,这些业务正是基于应用层的一些基本业务接口发展而来,这些业务接口是应用层的基础,是最基本的业务接口,我们在界面上的看到业务就是这些基本业务的逻辑的组合。
原子业务是最底层底层的业务,原子业务向前支持应用的业务,有了这些原子业务,就能构造出一系列的基础业务,应用层只需要根据这些业务加以逻辑处理,就能实现许多各种各样的新业务。
应用层的各种业务就是由原子业务经过控制层的逻辑组合发展而来。
可以举个很形象的例子,在画图版中会有各种各样的动作,比如多边形,圆形,涂色,等等,有了这些最基本的功能就能画出一副好看的图片。
那么,基本业务就是这些最基本的动作,在界面上展示的就是具体的应用。
多媒体系统支持的业务有很多,很多业务看起来很灵活多变,细细分析起来,也就是几个子业务的组合。
应用层是关系到用户体验的直接层,因此,多媒体系统的好坏,与应用层的展现有着最直接的关系。
控制层是多媒体系统的核心。
控制层提供了应用层中的原子业务的实现和封装,控制层在整个多媒体架构中起到了至关重要的作用。
在控制层中,不同的多媒体系统会有不同的模块划分,作者所研究的多媒体系统的控制层相当复杂,有许多子模块组成,在下一节会做相关分析。
呼叫控制是控制层实现业务的基本所在,呼叫控制与应用层的各种业务和底层的一些库、插件接口相连,为了实现各种业务,呼叫控制也分为了许多子模块进行。
在呼叫控制中,不可避免的会用到地址查询,对设备进行管理和控制,这样,就产生了呼叫路由。
呼叫路由模块也是控制层中核心的一环,在目前的多媒体系统中,由于呼叫路由的应用还没有较大的发展,目前呼叫路由的代码量也不是很大,有很多多媒体系统就直接把呼叫路由模块并入到呼叫控制中去了,没有形成一个单独的模块,在作者所在的系统中也是这样处理的。
在呼叫控制的实现中,各个子模块使用内部消息进行联系,消息构造出来在控制层中经过逐步的转化和处理,最后转换成符合规范的外部消息发送到设备终端等,在后面的业务流程分析中会有一定的介绍。
基础设施层为控制层提供了最基本的一些协议解析库、原子业务所需的硬件接口等。
在控制层中需要的协议,如SIP协议,H.323协议以及在处理这些协议中需要使用到的XML库等都会由基础设施层提供。
在现在的多媒体开发中,基础设施层都已经开发好了,开发多媒体系统一般都是开发控制层和应用层。
尽管基础设施层上已经为业务的实现提供了一些最基本的保障,但是这些和业务并没有直接的关系,为了实现业务控制,还需要控制层做好多事情。
2.1.2IP多媒体系统的基本架构分析
整个IMOS的架构十分复杂,但也是基于上面的三层架构演化而来。
IMOS的简单架构图如图2.2所示。
图2.2IMOS架构简图
下面我们就根据IMOS的架构[1]来简单分析下多媒体的一些业务的实现。
从IMOS的架构上我们明显可以看出多媒体系统的三成架构的轮廓。
IMOS平台分为5个层次,依次为OS基础设施层、数据访问层、多媒体基础设施层、业务逻辑层和业务展示层;这其中涵括9个组件:
用于用户交互的GUI组件、用于业务实现的AS应用服务组件和CS调度服务组件、用于信令调度的CC呼叫组件、用于媒体调度的MC组件、用于媒体处理的MP组件、用于配置管理的MM组件、底层框架的BP基础平台和DAO数据库组件。
IMOS的业务展示层展示了较为丰富的多媒体业务,有实时监控,点播回放,存储计划,云台操作,会议控制,设备管理,权限配置等等。
多媒体系统由一个系统的登陆页面,通过IE输入服务器地址可以登陆IMOS系统。
目前IMOS系统统一配置在一个Linux服务器[6]上,以普通的PC机作为客户端登陆。
在登陆界面上可以看到IMOS业务的分布情况。
图2.3IMOS系统部分业务截图
图2.3是IMOS登陆界面的部分截图。
从IMOS的登陆界面上可以看出业务的大致分布。
每个业务项都含有一堆子业务项,这些基于原子业务发展起来的各个业务共同构成了IMOS系统。
由于IMOS业务很多,而且还有很多不同的类型,为了更好的实现、维护和扩展这些业务,IMOS对控制层进行了一系列的划分,IMOS的每一个业务的实现都会遵循一个业务的流程。
从图2.2上,我们看到了IMOS的业务的一个简单流程,IMOS在应用层的调用接口之后,控制层首先对接口调用情况进行处理,在处理业务时会构造一条业务控制的消息,并且发送到下面一层。
控制层有XP播放器控制主要是因为IMOS系统本身兼容了XP播放器,IMOS支持硬解实况(利用单独的电视墙,监视器来播放实况)和软解实况(利用系统自带的播放器来播放实况),所以系统本身还需要对播放器进行处理。
消息处理层在接收到来自主线的消息后,根据消息的内容进行处理,转换消息并且转发消息到下面的具体的业务处理层进行处理。
消息管理层处理各种业务的消息。
业务控制层是控制层的关键层,实现具体的业务,业务控制层根据业务的不同又有具体的划分,比如呼叫控制模块(CC),媒体控制模块(MC)等等[1],每个模块都会处理部分业务。
呼叫控制模块是业务控制中的最重要的模块之一,本课题所研究的呼叫路由目前就是兼容在CC控制块之中的。
在呼叫控制的实现中,又会有一系列的具体的划分,在业务控制层中也是通过内部信令消息来完成模块之间的联系。
数据管理也是控制层中的一个重要的控制部分,在IMOS系统的数据库中存有大量的数据,控制层的其他模块不会去直接调用数据库进行数据管理,而是通过访问数据管理模块的接口间接的去完成。
同其他多媒体系统一样,控制层也是IMOS的核心,从IMOS控制层这么细致的划分就能有一定的体现。
控制层的好坏决定了系统的好坏。
IMOS在本服务器(本域)的业务和服务器间(跨域)的业务并存,控制层分别对其进行处理,但是不管是本域还是跨域,都会对设备资源进行管理,呼叫路由无疑是解决这些业务中关键的一环,在下一章中我们会针对呼叫路由方面展开分析。
基础设施层为控制层提供了最基本的保障。
在控制层处理业务时,会用到数据库、各种必要的原子业务接口等。
基础设施层的协议栈是处理控制层的信令处理的基础,在对信令消息进行分解,组合等都需要协议栈的支持,在解析消息中用到XML解析库无疑会大大增加解析的方便性和安全性,控制层需要对设备进行管理,这些设备管理的接口对于控制曾来说又是实现业务的基础。
控制层需要实现IMOS的功能,这些功能需要根据基础设施层提供的原子业务进行处理,原子业务的提供保障了最上层业务的实现。
2.2多媒体系统的协议分析
多媒体系统采用的协议主要有H.323[8]和SIP[9]协议,比如目前大公司内流行正热的的视频会议系统大多是采用H.323协议的,然而,鉴于SIP协议的灵活性,SIP协议在多媒体系统中也慢慢的应用起来,比如IMOS系统所采用的就是SIP协议。
H.323协议和SIP协议并不是指某个具体的协议,它们是一个协议族,H.323和SIP协议族中包含了RAS协议,Q.931协议,H.245协议[10],H.225协议等[11],在实际的应用中会根据具体的业务来选择协议。
2.2.1H.323协议
H.323是1997年ITU-T第16工作组的建议,H.323由一组协议构成,其中有负责音频与视频信号的编码、解码和包装,有负责呼叫信令收发和控制的信令,还有负责能力交换的信令[8]。
H.323标准标准建立在TCP/IP这一协议基础之上,可以提供丰富的管理功能,从H.323刚定义起经历了几个版本的变化,目前以及到版本五。
H.323协议网络在视频会议的应用上是属于总线型结构,H.323的终端都通过本身主机上的普通LAN网卡挂接在网络上。
H.323是多媒体通信的基础,基于H.323协议可以开发出许多业务层的应用,这些应用与底层网络传输无关,比如现在的视频会议系统,网上IP电话系统,网上IP传真系统等等
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 多媒体系统中基于号码分析的呼叫路由框架的设计和实现硕士学位论文 精品 多媒体 系统 基于 号码 分析 呼叫 路由 框架 设计 实现 硕士学位 论文