（计算机科学与技术专业论文）基于voip设备的计费系统的设计与开发.pdf

独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究成果。 尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其 他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他教育机 构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献 均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：= 岳 日期：m 晕；珥：且 4 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保留并 向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借阅； 学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它复制 手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在年解密后适用本授权书。非保密论文注 释：本学位论文不属于保密范围，适用本授权书。 本人签名： 导师签名： 蓦吨， 日期： 日期：御j i ， 基于v o ip 设备的计费系统的设计与开发 摘要 随着网络带宽及语音传输质量的不断改善，i p 电话凭借其成本低 廉和传输速度快两大优势已成为传统电话的主要竞争对手。作为i p 电话业务的关键部分，一套高性能的通信计费与综合营帐系统，对运 营商来说，能够大幅降低营运成本、提升服务质量和管理水平。本文 着重介绍了基于l u c e n t 软交换平台系统和v a n l i n k 语音网守设备两 种计费系统的设计思路和开发模式。这两套计费系统采用了相同的设 计架构和开发模式。在设计架构上，都是以数据库为中心，将c d r ( 将 详细呼叫记录) 信息存储在数据中，由计费引擎模块对c d r 数据进行 处理，同时向业务层提供数据；在业务层上，都采用了b s 结构的开 发模式，用j a v a 实现底层的数据处理和数据库接口，用j s p 做数据 抽取，输出成x m l 文档，再由x s l t 负责模板的制作，结合j s p 输出 的x m l 文档，生成页面。数据库作为计费系统的核心，存储了系统所 需要的所有数据。对于数据表格的设计、优化，对s q l 语句的优化， 也是系统开发过程中尤为重要的步骤，这直接影响了系统的性能。设 计良好的数据表格、精简高效的s q i ：语句可以数倍、乃至数十倍的提 高系统的性能。针对不同的平台又采取了不一样的计费模式。基于 v a n l i n k 语音网守设备的计费系统采用了实时计费模式。这是基于 r a d i u s ( r e m o t ea u t h e n t i c a t i o nd i a l i nu s e rs e r v i c e 远程接入用户认 1 证服务) 协议的实时计费模式。而基于l u c e n t 软交换平台的计费系 统则是采用了定期接收话单的非实时计费模式，c d r 话单是通过f t p 方式定期由软交换平台发送到计费服务器，并由计费服务器对c d r 话 单做处理。在软交换平台和计费服务器之间交互c d r 话单的过程中， 也是有一系列的保障策略的。 关键词：v o i p 、计费、软交换、网守 d e s i g na n dd e v e l o p m e n to fb i l l i n gs y s t e m b a s e d0 nv b i pd e v i c e a b s t r a c t a sn e t w o r kb a n d w i d t ha n dt h e q u a l i t y o fv o i c e c o n t i n u o u s l y i m p r o v e d ，t h e i pt e l e p h o n eh a sb e c o m et h em a i nc o m p e t i t o rt ot h e t r a d i t i o n a lt e l e p h o n er e l i e so ni t st w ob i gs u p e r i o r i t i e s ，w h i c hi sl o wc o s t a n ds p e e d yt r a n s m i s s i o n b e i n gt h ek e yp a r to fi pt e l e p h o n e ，ah i g h p e r f o r m a n c ec o m p r e h e n s i v e t e l e c o m m u n i c a t i o nb i l l i n gs y s t e m c a n l a r g e l yr e d u c et h et r a n s p o r tb u s i n e s sc o s ta n dp r o m o t es e r v i c eq u a l i t ya n d m a n a g e m e n tl e v e l t h i sa r t i c l eh i g h l i g h t sd e s i g ni d e a sa n dd e v e l o p m e n t p a t t e r n so ft w os e tb i l l i n gs y s t e mw h i c hs e p a r a t eb a s eo ns o f t s w i t c ho f l u c e n ta n dv o i c eg a t e k e e p e ro fv a n l i n k t h i st w os e tb i l l i n gs y s t e ma r e f o l l o wt h es a m ed e s i g ns t r u c t u r ea n dd e v e l o p m e n tp a r e m o nt h es i d eo f d e s i g ns t r u c t u r e ，b o t ha r et a k i n gt h ed a t a b a s e a st h ec e n t e r ，s t o r i n gt h e c d r ( c a l l i n gd e t a i lr e c o r d ) i n t od a t a b a s e ，l e t t i n gb i l l i n ge n g i n ed e a l w i t hc d rd a t aa n do f f e rw o r k e dd a t at os e r v i c el a y e r o nt h es i d eo f s e r v i c el a y e r ，b o t ha r et a k i n gb ss t r u c t u r e ，i m p l e m e n t i n gu n d e r s t r a t u m d a t ap r o c e s s i n ga n dd a t a b a s ec o n n e c t i o nw i t hj a v a ，u s i n gj s pt oe x t r a c t d a t aa n do u t p u tx m ld o c u m e n t s ，c r e a t i n gp a g e s u s i n gt e m p l a t e s p r o d u c e db yx s l ta n dx m ld o c u m e n t so u t p u t t e db yj s r t ob et h e c e n t e ro fb i l l i n gs y s t e m ，d a t a b a s es t o r e sa l lt h ed a t ar e q u i r e db ys y s t e m i t i sam o r ei m p o r t a n ts t e pt od e s i g na n do p t i m i z ed a t at a b l e sa n ds q l s t a t e m e n t s i tw i l ld i r e c t l ya f f e c tt h ep e r f o r m a n c eo fs y s t e m i tm a yt a k e s e v e r a lt i m e so re v e ns e v e r a lt e nt i m e st oe n h a n c et h ep e r f o r m a n c eo f s y s t e mb yw e l l - - d e s i g n e dd a t at a b l e sa n ds i m p l y - e f f i c i e n ts q ls t a t e m e n t s i tt a k e st h ed i f f e r e n tb i l l i n gp a t t e mi na l l u s i o nt od i f f e r e n tp l a t f o r m o n e t a k e sr e a l t i m eb i l l i n gp a t t e mf o u n do nr a d i u s ( r e m o t ea u t h e n t i c a t i o n d i a l - i nu s e rs e r v i c e ) p r o t o c o l ，w h i c hb a s e do nv a n l i n kv o i c eg a t e k e e p e r d e v i c e t h eo t h e r t a k e sn o n er e a l t i m e b i l l i n gp a t t e r nt h r o u g hf t p c o n n e c t i o n t h ec d r sp a s so nb i l l i n gs e r v e rt h r o u g h 邱b i l l i n gs y s t e m p r o c e s s e sc d r sl a t e r i ta l s ot a k e sas e r i e so fs a f e g u a r d ss t r a t e g yt o p r o t e c tt h e t r a n s m i s s i o no fc d r sb e t w e e ns o f t s w i t c hp l a t f o r ma n d b i l l i n gs y s t e m k e y w o r d s ：v o l p 、b i l l i n g 、s o f l s w i t c h 、g a t e k e e p e r 6 第一章绪论 随着网络带宽及语音传输质量的不断改善，i p 电话凭借其成本低廉和传输 速度快两大优势已成为传统电话的主要竞争对手。虽然就通话质量来说，i p 电 话与传统电话之间尚有一段距离，但是其传输成本对一般消费者和企业用户具有 相当大的吸引力。作为i p 电话业务的关键部分，一个高性能的i p 电话计费与 综合营帐系统，对i n t e r n e t 时代的运营商来说，能够大幅降低营运成本、提升服 务质量和管理水平，轻松面对w t o 的挑战。本文设计了一个大型i p 电话计费与 综合营帐系统，重点阐述了该系统的整体结构、数据模型、可靠性设计、认证、 计费过程、用户管理等等。并对系统现状进行了分析，提出了改进的思想和方法。 1 1v o ip 技术简介 在当今社会，有了功能良好的电话，为什么人们还要使用v o l p 呢? 一台普 通的电话机能将你的声音讯息近乎完美地传递到目的地，你根本不必担心不能跟 某些人交谈。你要知道的只是谈话对象的电话号码和你怎样想尽办法记住号码。 但如果很多年过去了，你只知道朋友的号码而不是他的名字，那就太可怕了。但 这正是古老科技的魅力所在：记忆人的方式是通过各人的数字代码，也就是s s 7 的记忆方法。 有了计算机化的v o l p ，人们要记住的是名字，而不是号码，也正是为什么人 们有时会自然而然的想起别人。每个人是和他的名字，样貌特征联系在一起的。 人们很难记住号码，因此，最好的办法就是记名字。 在现代社会，人们不仅仅用声音，而且用影像和数据进行交流。人们在语音 交流的同时，也喜欢分享图画和文字，后者即是所提到的数据传输。不幸的是， 人们喜爱的电话网络不能够做到数据传输，人们被迫用言语去形容或用传真机来 传递。更不幸的是传真机不是动态的，每一次的改动都要重新传输。 所谓v o l p ( v o i c eo v e ri n t e m e tp r o t o c 0 1 ) 就是一种以i p 电话为主，并推出相应 的增值业务的技术。它通过i p 包发送实现的话音业务，是建立在i p 技术上的分 组化、数字化传输技术，其基本原理是：通过语音压缩算法对话音进行压缩编码 处理，然后把这些语音数据按i p 等相关协议进行打包，经过i p 网络把数据包传 输到目的地，再把这些语音数据包串起来，经过解码解压缩处理后，恢复成原来 的语音信号，从而达到由i p 网络传送话音的目的。 1 2v o ip 技术的发展趋势 驱使i n t e m e t 话音业务飞速发展的因素是什么呢? 主要因素是价格。原理十 分简单，就是传统的电话是占用固定的通道，无论你是否使用。而日积月累的租 费、折旧等费用导致高昂的成本。而v o l p 技术就是利用资源共享这个原理，在 同样的网络状况下，大大提升了网络的使用率，从而减低了成本，而为使用者带 来了便利。这样导致相同通话时间，通过i n t e r n e t 话音服务花费的费用仅仅为通 过传统话音服务花费的费用的几分之一，甚至几十分之一，其价格差异如此的悬 殊，i n t e m e t 电话的发展速度也就可想而知了。另一个因素是技术的发展。以往， i n t e m e t 电话留给人的印象是话音质量低劣、延迟长、经常断。但随着技术的发 展，这些现象将不复存在。一方面，随着s i p 、h 3 2 3 一系列协议的推出，使得 i n t e m e t 电话的规范逐步完善，各厂商的设备可以互通；另一方面，i p 网络的大 力兴建及硬件设备性能的提高为i p 电话的顺畅提供了保障：最后，话音压缩技 术的发展也为v o i p 的发展铺平了道路。 目前专家普遍认为v o l p 将代表电话技术未来的方向，甚至有这样的一句话： e v e r y t h i n gi so v e ri p ( 一切都将基于i p ) 。许多人相信i p 电话时代即将到来，据 f r o s t & s u l l i v a n 调研公司在报告中预计，到2 0 0 7 年v o l p 的通话量将占全部通话 量的7 5 13v o ip 中的相关协议 v o l p 的普遍运用也是与v o i p 网络技术的发展密不可分。v o l p 采用了基于统 计时分复用的i p 网络为基础进行话音业务传送，采用先进的数据信号处理技术 进行语音编码、语音压缩、静音监测、舒适噪音生成等等技术可以提供与电路交 换方式的传统p s i n 网络语音品质媲美的语音服务。技术发展到今天，目前主要 有两种v o i p 实施标准：丌1 j _ t 标准和i e t f 标准。 r r u - t 标准：h 3 2 3 协议 h 3 2 3 是最早被采纳的v o i p 标准。h 3 2 3 协议体系规定了基于分组网进行两 点多点实时媒体通信的系统逻辑组件、消息定义和通信过程。h 3 2 3 协议采用 了i s d n 的设计思想，使用q 9 3 1 协议完成呼叫的建立和释放，明显地带有电信 网可管理性和集中的特征。目前，h 3 2 3 协议已经在网上得到广泛应用，国际上 如i t x c 和a t t ，国内如中国电信、中国联通等均采用h 3 2 3 的体系结构组建 i p 电话运营网。与s i p 比较，h 3 2 3 更为成熟。 h 3 2 3 协议的特点： 基于网守的概念使得h 3 2 3 网络是集中控制的便于统一维护管理； 但由此，一个明显的缺点是，呼叫处理时延大； 网络规模也因此受到极大的限制； i e t f 标准：s i p 该协议体系是由l e v e l 3 、b e l l c o r e 和c i s i c o 发起的业务提供商，厂商共同体提 出并由i e t f ( i n t e r n e t 工程任务组：i n t e r n e te n g i n e e r i n gt a s kf o r c e ) 开发形 成的。s i p 协议具有简单，灵活性和扩展性好，以及和现有的i n t e r n e t 应用紧密 的特点，许多人认为该协议比较容易实施，近期，特别是在美国得到快速发展， 同时s i p 将在第三代移动通信核心网和智能业务中得到广泛应用。目前，s i p 协 议还处在发展的初期阶段，很多相应的标准还没完全统一，管理功能不完善，大 型的网络应用还没有。 应该说，h 3 2 3 和s i p 协议都是为构建i p 电话网而逐渐形成的，两者在发展 的初期是互斥的，但目前随着s i p 协议的发展，特别是其在软交换中的应用，使 得s i p 协议有了很大的发展，目前h 3 2 3 和s i p 协议的互连互通也已经在制订之 中。 另外，不管是基于h 3 2 3 协议还是基于s i p 协议的i p 电话网架构，都需要相 关的协议完成网守对媒体网关的承载控制、资源控制及管理。目前此接口使用媒 体网关控制协议( m g c p ：m e d i ag a t e w a yc o n t r o lp r o t o c 0 1 ) 或h 2 4 8 ( m e g a c 媒 体网关控制) 协议。 h 2 4 8 协议称为媒体网关控制协议，是由丌u t 第1 6 组提出来的，应用在 媒体网关和媒体网关控制器之间、媒体网关控制器与h 2 4 8 m e g a c o 终端之间。 m g c p 是i e t f 较早定义的媒体网关控制协议，主要从功能的角度定义媒体网 关控制器和媒体网关之间的行为，实现比较简单，没有h 2 4 8 那样对包和属性 的详细定义，事件交互的机制也比较简单。m g c p 具有实现简单等特点，但其互 通性和支持业务的能力受到限制。 h 2 4 8 m e g a c o 因其功能灵活、支持业务能力强而受到重视，而且不断有新 的附件补充其能力，是目前媒体网关的主流协议，它解决了m g c p 原有的缺点， 操作性强，但由于该协议推出不久，业界还缺乏成熟的产品和应用实例，需进一 步发展。 h 。2 4 8 和m e g a c o 在协议文本上相同，只是在协议消息传输语法上有所区别， h 2 4 8 采用a s n 1 语法格式( 丌u tx 6 8 01 9 9 7 ) ，m e g a c o 采用a b n f 语法格式 ( r f c 2 2 3 4 ) 。 v o i p 的关键技术包括： 媒体编码技术 包括流行的g 7 2 3 1 、g 7 2 9 、g 7 2 9 a 话音压缩编码算法和m p e g i i 多媒体 压缩技术。 控制信令技术 包括r r u - t h 3 2 3 和i e t f 会话初始化协议s i p 4 ( s e s s i o ni n i t a t i o np r o t o c 0 1 ) 两套标准体系，还涉及到进行实时同步连续媒体流传输控制的实时流协议t r s p 。 分组传输技术 主要采用实时传输协议r t p 。 业务质量保障技术 采用资源预留协议r s v p 、服务质量q o s 和用于业务质量监控的实时传输控 制协议r t c p 来避免网络拥塞，保障通话质量。 网络传输技术 主要是t c p 和u d p 。 1 4 论文背景 在v a n l i n k 网守计费系统的基础上，重新设计计费系统的架构，使得计费系 统能够更好的提供计费服务，是此次项目的第一个出发点。与此同时，在与l u c e n t 合作的软交换项目中，接到为l u c e n t 软交换平台开发计费系统的任务。根据软 交换平台的计费特征，结合在网守计费系统上的开发经验，设计开发了基于软交 换平台的计费系统，这是此次项目的第二个出发点。 本篇论文主要从这两点出发，阐述了作者对基于v o i p 设备的计费系统的设 计思路和开发模式。 1 5 本人所做的工作 作者在此次的设计和开发中，维护并重新设计开发了基于v a n l i n k 网守设备 的计费系统，设计开发了基于l u c e n t 软交换平台的计费系统，在其中担任了主 要设计开发人员，并且参与了项目的测试和实施。 在设计、开发过程中，作者查阅了大量的关于v o i p 计费及其相关的材料， 和课题组的其他成员密切配合，圆满的完成了网守计费系统的重设计、软交换平 台计费系统项目的设计工作。其中在开发网守计费系统中，作者开发的j a v a 代 码大约在1 0 0 0 0 行左右，j s p 和x s l t 代码在6 0 0 0 行左右；在软交换平台计费系 统项目中，作者开发的j a v a 代码大约在1 3 0 0 0 行左右，j s p 和x s l t 代码在7 0 0 0 行左右。 第二章v 0 lp 计费系统介绍 2 1v o ip 计费系统的介绍 随着网络带宽及语音传输质量的不断改善，i p 电话凭借其成本低廉和传输 速度快两大优势已成为传统电话的主要竞争对手。作为i p 电话业务的关键部分 一个高性能的通信计费与综合营帐系统，对运营商来说，能够大幅降低营运成本、 提升服务质量和管理水平。 通信计费系统是各种通信网络重要的支撑系统，经历了从人工到自动的变化 过程，计费系统正从初级走向高级、从分散处理走向集中处理，关于计费系统的 建设也已经逐步形成一套完整的理论。 计费系统正在向两个趋势发展： 向集中处理模式演变 向个性化、多样化的客户服务方向发展 针对市场上的语音产品，设计一套高标准的计费系统作为支撑子系统是非常 必要的。该计费系统从系统设计、技术实现、业务流程和管理模式等方面具有高 度的统一性和规范性，能够向用户提供不同形式的客户账单、不同的缴费方式、 不同的费用查询方法、不同的缴费周期，设置可以为用户提供定制的计费方式。 作者在这里叙述的计费系统包括两部分，一部分是基于v a n l i n k 公司网守设 备的计费系统，另一部分是基于l u c e n t 公司软交换平台的计费系统。其中，基 于v a n l i n k 公司网守设备的计费系统是在已有的基础之上，对其做架构上的改进， 重新设计计费流程和计费方式。这种设计主要是针对现有的基于v a n l i n k 公司网 守设备的一些弊端，这些弊端包括： 对话单记录无安全保障，对不完整话单记录没有处理措施 计费服务器没有安全措施 服务器端被动接受消息，无法获取更多信息 另一套计费系统是基于l u c e n t 公司软交换平台的，是一套全新开发的计费系 统。由于这两套计费系统都是基于同一种架构设计和分层设计的，并且进一步的 工作就是将两套计费系统整合到一起。所以，就将二者在这里一起讨论。 2 2v olp 计费系统的设计思路和设计考虑 两套计费系统是在相同的架构设计上进行开发的，拥有相同的体系结构。但 是由于两套计费系统接收c d r 话单的形式完全不一样：基于v a n l i n k 公司网守 设备的计费系统是接收来自网守的实时r a d i u s 消息，而基于l u c e n t 公司软交 换平台的计费系统是基于f t p 方式定时接收话单。所以两套计费系统在c d r 话 单的处理细节上又完全不一样。 2 21 计费引擎的体系结构 计费引擎体系结构的设计是整个计费系统的关键。如果不能设计一个良好的 体系结构，在以后的实现和应用中，都会遇到无法克服的困难。严重的话，甚至 要打破现有的结构，重头再来。所以，不重视结构的设计，只能盲目的加大开发 人员的劳动强度，而且还不能取得很好的预期效果。 在设计计费系统的体系结构的时候，首先要把计费系统所在的环境搞清楚， 根据实际的环境，才能开发出一个具有较高性能的系统结构。现在要设计的计费 系统主要运用在两种用途：1 、企业内部搭建的v o l p 网络；2 、运营商搭建的以 软交换平台为中心的v o l p 服务网络。对于这两种主要用途，计费系统要管理的 是网守设备和软交换平台，对于这两种设备的不同处理方式，我会在后面详细论 述。计费系统要同时管理多个网守设备，或者管理一个或多个软交换平台，可见， 整体的架构采用c s 模式较为合适。每个网守设备或软交换平台，做为整个系统 中的一个节点，向计费系统发送c d r 信息、认证信息( 软交换平台可以做呼叫 控制、认证管理) ，计费系统处理来自各个节点发来的信息，处理后发送反馈信 息，各个节点根据反馈信息继续下一步的状态变化。 计费系统的实现不仅仅是简单的实现计费的流程、帐务管理等必要的功能， 而且还要在保证功能实现的情况下，最大限度的保证服务的可靠性、安全性、稳 定性。可以想象一下，如果一套功能完整的计费系统，因为安全性、稳定性的问 题，今天不能正常服务了，明天数据丢失了，那么客户能够忍受么? 所以，保证 计费系统的稳定可靠安全，是非常重要的。随着网络技术的飞速发展，每一个放 置在网络上的节点，都是不安全的，而设计者和开发者要做的，就是最大限度的 保障系统的安全可靠。 在保障系统的安全问题上，现在已经有很多的实现方式：防火墙、v p n 等等。 这些方式可以对计费系统起到很好的保护作用。 在系统的可靠性问题上，需要面对两种要解决的问题：1 、硬件的问题；2 、 软件的问题。对于软件问题，这需要开发人员加强自己的编程功底、细致认真的 责任感和全面仔细的测试。同时还需要工程实施人员能经常的跟进、查看当前系 统的运行状态，及时准确的发现问题，并由开发人员及时对b u g 进行修正。对 于硬件上的问题，采用了多机冗余备份的方式，设置两台主机，一台作为主计费 系统，另一台作为备用机。当主计费系统出现问题不能正常服务的时候，备用机 会通过心跳检查探测到主计费系统的状态变化，并及时向所有管理的节点发布目 标系统主机的重定向命令，接管主计费系统的服务( 整个过程不应超过1 0 秒) 。 当主计费系统恢复正常后，再由主计费系统重新接管服务，并把备用机接管服务 时产生的数据导入到主计费系统，保持数据的一致性。 2 2 2 动态掌握网守状态以及通话状态 计费系统作为管理系统的一部分，不但要管理好下面的节点，同时还要为管 理人员提供良好的人机界面。如果计费系统不能提供一个人机界面的话，即使计 费系统完全正常的工作着，那么管理人员也看不到任何当前系统的运行状态，同 样要为系统的状态担忧。 由于软交换平台本身提供了强大的管理功能，所以这部分功能不需要计费软 件再次单独的实现。在这里叙述的，主要是网守设备。计费系统不需要向网管系 统那样，把网守设备的所有详细信息都反馈到管理员的面前。计费系统只需要反 馈和当前计费相关的信息：网守是否可用、每个网守当前的通话状态等等，这些 信息需要动态的反馈给管理人员。 计费系统将这些信息的交互建立在消息机制上，通过u d p 传输，和网守进 行交互。计费系统定期轮询每个管理节点，为网守做健康检查，判定该网守当前 是否可用。如果网守不能正确及时回复计费系统的健康检查，则认为该网守存在 问题，反馈给管理人员，期望及时给予解决，以保证正常服务。 对于网守的通话状态，采用通话时长权限授予机制。网守上的每路通话的时 长，都是由计费系统授予的，当快要达到一个时长结束点时，计费系统判断该网 守是否工作正常，如果网守工作正常，则再向网守发送一个时长权限，否则的话， 不再向该路通话继续授予权限，计费系统一侧认为通话结束，这样可以有效的防 止网守僵死，通话依然继续，但是计费系统却不能从僵死的网守处接收到任何关 于计费消息的情况。网守对于通话的时长管理完全依赖于计费系统所授予的时 长，一旦达到了时间点而又没有得到继续的权限授予，则必须结束该路通话，即 使由于网守僵死，不能继续对呼叫进行控制，那么也把运营商和企业的损失降到 了比较低的水平。这样的话，计费系统在内部为每个网守上的通话建立队列管理， 所有的通话状态都可以通过状态队列分析得到。这种应用主要运用在基于企业内 部搭建v o i p 网络的情况下。 2 2 3 处理记录不完整的话单和错误话单 当由于各种因素造成了计费系统收到了错误话单和不完整的话单时，当然 了，最简单的处理方式就是丢弃。但是，这样的处理方式对于运营商和企业造成 了很大的损失。为了把这种损失降低到最低，计费系统需要一种对于错误话单和 不完整话单的处理机制，根据已有的话单，做一些数据分析，尽可能的还原话单 数据。 22 4 计费服务器的热备份 为了保证服务的不间断，采用了双主机备份的策略：即一台计费服务器作为 主计费服务器，另一台作为从计费服务器。两台服务器同时放置在线上的服务中， 但是只有主计费服务器提供线上的服务，从计费服务器并不提供服务。从计费服 务器只有在主计费服务器出现异常状况，无法提供正常的线上服务后，才接管服 务。此时，所管理的节点也把服务都重定向到新的计费服务器上。 这种备份策略可以尽可能的保持线上服务的完整。对于基于v a n l i n k 语音网 守设备的计费系统，如果要实现这样的功能，就需要网守设各添加相应的功能和 配置，这些功能在网守设备上都是可实现的。对于l u c e n t 软交换平台来说，软 交换平台通过f t p 传输话单到计费服务器上。而且软交换平台的话单传送过程， 是通过s h e l l 脚本程序控制的，并且由c r o n t a b 命令完成定时发送流程的。话单的 传输过程是有可靠性保证的，如果话单传送失败，会转移到发送失败目录，等待 下一个时间点重新进行传输。所以当主计费系统出现问题时，从计费服务器会发 送报警信息给管理员( 可以通过m a i l 或短信方式) 。管理员只需要改动s h e l l 脚本，即可重定向到从服务器继续发送话单。 2 3v o ip 计费系统的效率、风险评估 根据需求分析和项目评估，计费系统应该能够支持1 0 0 0 0 3 0 0 0 0 线以上的终 端设备，大约2 0 5 0 个网守设备。至于年l l l u c e n t 的软交换平台，在需求分析的时 候，就是按照1 ：1 的模式进行设计的。如果能够保证多个软交换的独立性和资源 ( 特别是号码资源) 的不重复，计费系统是可以胜任对多个软交换平台的计费进 行处理的。 对于业务层的访问，根据和客户以及需求方的分析讨论，线上业务浏览和管 理的使用者，更多的是管理员，包括省管理员、地市管理员、代理商、大客户管 理员等。所以流量压力比较小，即使以管理3 0 0 0 0 线举例来说，日访问量也不会 超过1 0 0 0 0 0 次( 假设每线的用户平均日访问量为3 次) ，以晚1 8 点到晚2 2 点高峰 时段占8 0 流量的峰值来计算，高峰时的每秒访问量为1 0 0 0 0 0 0 8 ( 3 6 0 0 5 1 = 4 4 4 次。这样的低访问量，计费系统是完全可以承受住的。 从系统结构上分析，当访问量较大的时候，系统的瓶颈应该出现在数据库访 问上。因为计费系统的业务层，主要的功能就是向管理者和用户以各种方式展示 他们所要知道的数据( 当然是他们有权限看到的数据) 。所以数据库的访问压力 会成为系统的瓶颈。为了降低瓶颈出现的可能，就要提高数据库的访问能力。那 么就需要在数据表格设计的时候，用一些高级冗余数据，将尽可能多的、需要展 示的数据，在后台进行处理计算。当前端用户需要查找数据时，直接将计算好的 数据提取出来。这样可以大大降低数据库的压力，提高数据库的访问速度。同时， 由于话单数据量、用户数据量的增加，要想提高数据库的效率，还需要很好的使 用索引。使用索引可以极大的提高数据库的访问速度。 数据量的剧增，总会导致数据库系统效率的下降。那么，定时导出话单数据， 降低数据库的压力，也是一个提高系统性能的策略。 第三章计费系统的架构设计和数据模型 在这次计费系统的开发周期中，采用了快速原型的开发方式，严格按照软件 工程的开发步骤进行产品的开发。首先按照客户的大致需求，快速的开发出一套 基本满足需求的原型产品。然后按照客户在这套原型产品的基础上提出更细致、 更完善的需求，同时对于原型产品中不合理的处理流程提出更改建议。然后再在 原有的基础之上，按照新的需求，进一步的完善产品。 从开发过程中，通过分析可以得到，在第一次开发时所做的原型产品是非常 重要的。原型产品功能简单，但是，它却是整个产品的核心。如果原型产品做的 不好，不能实际的贴合客户的需求，那么在进行二次开发的时候，就必须重头再 来。这样不仅耽误了项目进度，而且大大加重了开发者的负担。 在此次的开发过程中，由于各种的原因，开发出的第一个原型产品就比较严 重的偏离了客户需求，导致在第二次丌发的时候，不得不重新设计系统框架，将 工期拖延。从这次的开发中，使对于系统的总体架构设计的重要性，体会的更加 清楚。 3 1 总体架构 系统的总体架构设计是整个工程中最为重要的一个环节。良好的系统体系结 构，可以大幅提高系统的性能、降低开发成本、减少开发者的劳动强度。这次设 计开发的计费系统主要是针对网守设备和软交换平台进行开发的。对于网守计费 和软交换平台计费这两种模式，在处理的流程上不尽相同。对于网守计费，采用 了基于r a d i u s 协议的实时计费模式，对于软交换平台计费，采用了基于f t p 话单的非实时计费模式。在这次计费系统的开发中，总体架构的设计主要包含了 这几方面：系统的体系结构、与网守的交互、与软交换平台的交互、以及计费预 处理的流程。 311 体系结构 基于网守的计费和基于软交换平台的计费，在体系结构的设计上基本一致。 体系结构的设计方案决定了以后的开发策略。 3 1 1 1 节点与计费服务器采用c s 结构 对于网守设备和软交换平台，采用的结构基本致，因为他们都是作为一个 节点添加到计费系统当中来的。不同的是，软交换平台具有更强大的管理功能。 采用通用的c s 结构，符合计费系统的实际环境，也方便开发人员的开发。以计 费系统作为服务器端，各个节点作为客户端。各个节点将数据信息发送到计费服 务器端做统一处理，并接收计费服务器发回的反馈信息做状态转移。 计费系统和网守之间的结构图： 检查( 时间、地址) 交互( 起始话单、终止话单) 图3 - 1网守计费架构 各个节点上的网守在一般情况下只和主计费服务器连接，进行消息交互，并 不与备用计费服务器连接。当主计费服务器出现异常时，备用计费服务器会主动 向网守发送目标服务器重定向的消息。此时各个节点上的网守并不直接更改目标 服务器，而是先向主计费服务器上的心跳检查端口发送心跳检查消息，作验证。 如果主计费服务器不能正确响应验证信息，则表示主计费服务器出现异常状况， 这时，网守才更改目标服务器地址为备用计费服务器的地址，并向备用计费服务 器发送目标地址更改成功消息。如果主计费服务器能够正常响应，则向备用计费 服务器返回更改无效的消息。如果备用计费服务器连续三次发送重定向命令，但 都收到更改无效的回复，则需要产生报警信息给管理人员。 计费系统和软交换平台之间的结构图： 交互数据： 话单交互( f t p 传输c d r 话单) 数据交互( c o r b a 接口) 图3 - 2软交换计费架构 计费服务器和软交换平台交互的c d r 话单是以f t p 方式传送的，每次都是批量传 输。软交换平台对于c d r 话单的传输有验证重传机制，当这次的话单传输失败的 时候，会将此次的话单转移到重传目录，等待下一传输时间点再次传输。在这样 的情况下，当备用计费服务器通过心跳检查检测到主计费服务器出现异常时，不 能向软交换平台发送目标主机的重定向命令，因为软交换平台对于该命令并不能 识别。这时的处理策略为：当备用计费服务器连续三次通过心跳检查检测到主计 费服务器出现问题，则向管理人员发送报警信息，由管理人员手工更改软交换平 台的目标地址到备用计费服务器上，备用计费服务器此时接管服务，并等待在下 一数据传送点时，接收数据处理。 3 1 1 2 服务器与用户之间采用b s 结构 管理员和电话用户需要通过一个平台查看到他们所需要的信息。在i n t e r n e t 网络快速发展的今天，以w e b 方式开发这种平台是快速、有效的策略。当然， 管理员作为一个特殊的用户群体，对于他们的登陆是需要有特殊限制的，常用的 有i p 限制和反向代理，但这不是这里讨论的重点。 以w e b 方式开发业务平台，那么就要采用b s 结构进行开发。在服务器一 端，建立h t t p 服务器，使得用户通过浏览器访问特定的地址，登录到业务平台， 查看相关信息。 可以用下面的图来表示这种结构： 计 费 交互 服 jl 务 器 队w e b 方式提 供查询视图、 管理页面 图3 - 3计费系统中人机交互 这种b s 结构的开发，成本比较低。基于服务器端的h t t p 服务器，可以采 用开源的a p a c h e 服务器。由于已经决定采用j a v a 作为开发工具，那么在这 里，也就采用j s p 的开发方式进行，所以h t t p 服务器也就采用了基于a p a c h e 核心的t o m c a t 服务器。t o m c a t 服务器同样是开源的。 业务平台向请求信息的用户提供各种的信息，而这些信息都是基于i n t e r n e t 网络传播的。即使管理员的连接可以在内网或者基于v p n ，以达到安全的保障， 但是普通用户的信息请求，其数据就要暴露在没有任何保护的i n t e m e t 网络上了， 这显然不是用户期望的。所以对于用户到服务器的访问，使用了基于s s l 安全 加密的h t t p s 协议，该协议可以保证数据信息的安全性。 3 1 1 3 计费服务器和数据库之间的结构设计 交互数据： 数据交互 数据同步信息交互 图3 - 4主机一数据库结构 出于对数据安全的考虑，应该将数据库放置在单独的主机上，而不与计费系 统放置在同一主机上。计费服务器和数据库之间通过数据连接池或者长连接进行 数据的传输。主计费服务器和备用计费服务器都通过网络与数据库连接，为了保 证网络连接的可靠性，应将计费服务器和数据库放置在同一子网内。为了保证数 据的安全可靠，一般情况下，会再设置一个从数据库，与主数据库之间保持数据 的实时同步，如果条件允许，可以再增加一台的冗余备份数据库。数据的同步时 间应该控制在平均1 0 m s 以下。在o r a c l e9 i 和m y s q l 上进行测试，向主数据 库中插入1 0 0 m 的数据( 以读取文件的形式) ，同步速度都控制在5 m s 以下( 主、 从数据库都处于同一内网) 。需要说明的是，如果使用m y s q l 自带的同步功能， 在大数据量、大压力下，会出现数据校验错误，从而导致某些数据同步失败。 计费服务器对于数据的浏览操作( 即对应s q l 语句中的s e l e c t 操作) ，负载 均衡到主数据库和从数据库上，保证不会让某一台数据库出现负载很大，而其他 的数据库负载很小的情况。计费服务器对于数据的更新操作( 即对应s q l 语句 中的i n s e r t 、u d a t e 、d e l e t e 等操作) ，只能在主数据库上进行操作，并且由主数据 库通过同步机制，将数据同步到其他的从数据库上。这样的话，可以保证数据的 一致、有效，不会产生数据的冲突。对于话单信息和用户信息( 如果需要的话) 还要做每天或定期的备份。 312 计费系统与网守的交互 基于v a n l i n k 公司网守设备的计费系统，需要和网守进行大量的信息交互。 在以前的基于网守的计费系统中，除了基于r a d i u s 的认证、计费的消息外， 计费系统和网守就没有其他的信息进行交互了。这样就导致计费系统是一个被动 接受消息的系统，计费系统并不能主动的掌握当前所管理的各个网守的工作状 态。计费系统作为网管系统的一部分，显然不能发挥更大的作用。 在这次的设计开发中，重点加强了计费系统和网守之间的消息交互，让计费 系统更多的掌握其管理的网守的状态情况。和网守的状态交互主要在三个方面： 通话状态的交互、网守的保活状态交互、更改计费服务器地址的交互。 3 1 2 1 与网守之间交互通话状态信息 在原来的计费系统中，一个呼叫、计费的流程如图所示： 图3 - 5网千呼叫流程 1 、主n q 号码所在网关( 网关1 ) 发送请求用户接入认证( a r q ) 消息 2 、网守接受到来自网关1 的a r q 消息后，将由网关l 发来的用户信息发送到 计费服务器进行认证( a c c e s s - - r e q u e s t ) 3 、计费服务器根据用户信息进行认证，如果认证成功，发送a c c e s s - - a c c e p t 给网 守，否则发送a c c e s s - - r e j e c t 给网守 4 、如果用户身份认证通过，则发送接入认证通过和授权( a c f ) 消息发送到网关： 否则，发送拒绝( a r j ) 消息网关。 5 、如果用户信息认证成功，网守向计费服务器发送计费开始消息( a c c o u n t - - s t a r t ) 消息，表示开始计费。 6 、计费服务器回应网守的计费开始消息。 7 、主叫网关和呼叫网关之间建立通信连接。 8 、假设主叫用户先挂机，主叫用户所在的网关l 向网守发送拆链请求( d r q ) 消息。 9 、网守回复网关1 的拆链请求，发送拆链确认( d c f ) 消息给网关1 。 1 0 、被叫用户所在的网关2