VoIP系统实时计费功能的研究及实现

发布: 2007-6-23 21:39 | 作者: | 来源: | 查看: 11次 | 进入软件测试论坛讨论

　　
　　一、计费系统框架结构
　　VoIP计费系统的设计遵循Inte.net实时计费的设计原则，具有实时性、稳定性、可靠性、可移植性、可扩展性等特性，功能的设计既考虑了Internet计费系统的基本功能，又考虑了用户的需求及VoIP系统的业务特点。
　　

　　系统的核心部分，包括中心数据库、可互备份的实时计费服务器RTBS，以及向外部设备开放的实时计费代理（RTBA）。通过RTBA向外部设备开放实时计费的所有功能，RTBA提供了一套完整的功能接口API，外部设备只需简单地调用这些函数就可以实现各种功能。从外部设备角度来看，计费系统的内部细节是透明的，因此系统可以方便地移植和集成。RTBA的设计是本系统的一大特点。外部设备与RTBA之间是函数调用关系，RTBA与RTBS之间则是在标准TCP/IP上的相互通信，可以是在LAN上，也可以是在WAN上。为了保证整个计费系统的性能，RTBA与RTBS必须在有QoS保障的网络上进行通信。
　　
　　系统中可以采用多个RTBS，RTBS之间可以互相备份，通过RTBS的冗余可以明显提高系统容量，还提高了系统的稳定性和可靠性。后台数据库采用Oracle，在RTBS 与数据库之间，仍然通过三层架构，中间层用Microsoft MTS以提高数据库访问的性能。
　　
　　系统同时还提供Keep Alive机制，GK通过RTBA与RTBS保持Keep Alive通信，无论GK异常还是RTBS异常，对方都能在第一时间知道。
　　
　　二、CDR格式
　　CDR就是呼叫详细记录（Call Detail Record），每个完整的呼叫都应有一个完整信息的CDR。IP电话中的CDR信息一般以两种形式存放，一种是文件形式，可以是文本文件、二进制文件或CSV格式文件；另一种是存放在数据库中，这也是最常用的形式，IP电话系统后台数据库都有专门存放CDR的表。
　　
　　CDR信息一般由GK收集。记录CDR有两个最主要的目的，一就是作为计费的依据，二就是用于客户查询审计。CDR中应该记录哪些信息并没有一个固定的要求，一般不同的IP电话系统根据业务的侧重点不同会有不同的CDR格式，同时客户最关心的一些信息一定要记录到CDR中。CDR格式是根据系统的具体业务特点和具体的客户需求制定的，除了一些必须有的信息字段外，还有一些特殊字段。表1是CDR中每个字段及其含义。
　　
　　三、资费策略的制定
　　资费策略是对各种服务进行计费的一套完整方案，表明对于每种服务应该向谁收费、怎样收费，主要包括正常费率的设置、折扣费率的设置、固定服务费和罚款的设置。不同的供应商根据所实现业务的不同会有一套符合自身特色的资费策略，但都必须遵守一个原则，即费率的统一，一个服务在该资费策略下只能计算出一个费用值，不能出现有歧义的计费方法。
　　
　　最常见的计费方法有：
　　
　　（1）按服务时长计费，这是使用最广泛的一种计费方法；
　　
　　（2）按服务次数计费；
　　
　　（3）按数据流量计费，可能是上行流量、下行流量或总流量；
　　
　　（4）按带宽使用情况进行计费；
　　
　　（5）按服务质量（QoS）参数计费；
　　
　　（6）混合计费，如结合带宽和流量的计费。
　　
　　目前许多ITSP主要提供PSTN＋IP网关形式的IP电话业务，这种情况下费用的计算一般分为两部分，即PSTN通话费用和IP内部服务费用。
　　
　　数据在三段网络中传输，第一段从用户电话到IP接入网关，接入网关有接入号，这段费用是PSTN的费用。第二段从接入网关到接出网关，语音数据通过IP网络传输，大IP电话运营商一般都通过专网或专线传输，这是IP内部服务的费用。第三段从接出网关到被叫电话，收取的也是PSTN通话费用。第一段费用一般由主叫支付，相当于市话费用。第二、三段的费用就是用户支付的IP 电话费用，由运营商核算综合成本后给出费率计算得到。这样的系统绝大多数都是按通话时长来计费的。
　　
　　IP电话资费策略中根据需要都会有折扣/优惠策略，一般有时段优惠、节假日优惠和总量优惠等方式。
　　
　　资费策略管理在VoIP业务中是很关键的，灵活的资费策略管理不仅有利于服务供应商的运营和业务的扩展，也极大地保护了客户的利益。好的资费策略管理应该支持费率的预定制和费率的回溯，支持实时费率，能够提供多种费率的核算和比较。
　　
　　VoIP除了基本的PC to PC、PC to Phone、Phone to PC、Phone to Phone四种业务模式外，还有收发Voice Mail、呼叫转移等增值业务，所以可以把所有业务分为两大类，一类是与PSTN相通的，一类是没有PSTN费用的内部业务。
　　
　　资费策略中除了上述对收费方法的规定外，还需要设置PSTN通话费率和优惠策略。
　　
　　四、计费系统主要业务实现
　　1. 时钟同步
　　
　　时钟同步在分布式应用中是很关键的，尤其是在VoIP系统中对时间的一致性更为重视，设备之间时钟误差不能超过1s。系统中所有设备都以中心数据库所在的机器时钟为基准时钟，提供一个时钟同步函数，每隔一段时间系统中各设备调用该函数，对本地时钟进行校对。
　　
　　2. 登录/认证
　　
　　在此以一个终端（Terminal）的登录为例，介绍本计费系统的认证过程。
　　
　　（1）终端向指定的顶级 GK发GRQ（Gatekeeper Request）。顶级 GK给终端回GCF（Gatekeeper Confirm）报文，给终端分配初级 GK，让终端向指定的初级GK注册。
　　
　　（2）在GCF消息中顶级GK把初级GK的IP、Port返回给终端。
　　
　　（3）终端向初级GK发RRQ（Registration Request）消息，带上用户ID、用户密码等参数。
　　
　　（4）初级GK调用RTBA提供的请求认证的API函数。
　　
　　（5）RTBA向RTBS发RADIUS的认证请求（Access-Request）消息。
　　
　　（6）RTBS查询中心数据库的用户ID—密码对，如果相同给RTBA返回RADIUS中的Access-Accept消息。
　　
　　（7）RTBA的API函数返回认证确认结果给初级GK。
　　
　　（8）初级GK得到认证通过的结果后，向终端发RCFv（RegistrationConfim）消息，接受用户登录。
　　
　　如果在第6步中用户ID、密码不符，RTBS向RTBA返回Access-Reject消息。则在接下来的第7步中API返回认证拒绝结果，并且在第8步中初级GK向终端发RRJ（Registration-Reject）消息，拒绝用户登录。
　　
　　3. 呼叫请求
　　
　　用户得到验证后，就可以进行呼叫操作。当一个终端要向另外的终端发起呼叫时，GK在建立呼叫前要通过计费系统确认该用户是否能够得到发起这个呼叫的授权。呼叫请求过程和呼叫建立过程从略。
　　
　　4. 检查点
　　
　　在很多计费系统中，只在服务开始和服务结束这两个时间点进行计费处理。例如在一个呼叫开始时通知一下计费服务器，然后在呼叫结束时再通知一下计费服务器，然后计费服务器一次性计算该呼叫的费用。这种处理方法比较简单，但不可靠，如果呼叫开始并进行了较长时间的通话，而这时候GK发生异常，不能通知计费服务器呼叫结束，那么计费系统就无法对这个呼叫进行计费，对客户对供应商都是一种损失。为了避免这种损失，我们在计费系统中启用了检查点（Checkpoint）机制，即在每个呼叫过程中设置检查点，检查呼叫情况，检查系统运行情况，并做如下处理：
　　
　　（1）更新客户最新费用信息；
　　
　　（2）写最新状态的CDR。
　　
　　通过Checkpoint机制可以最大程度地减少损失，利用Keep Alive可以在第一时间发现异常，并做相应处理。系统中可能出现的异常情况很多，在这里举两个例子，并介绍相应的处理方法。
　　
　　如果GK发现一个RTBS异常，由于该RTBS负责多路呼叫的计费处理，那么这时候GK要做的就是将该RTBS上负责的所有呼叫迁移到其他RTBS上，而且要避免费用的重复扣除，因为在过去的Checkpoint点已经扣除了呼叫前一段时间的费用。处理的方法，并不是将最新的呼叫状态也迁移过去，让RTBS从迁移时开始重新计费，而是将呼叫的最原始信息，如呼叫开始时间T0，该用户的原始费用balance0转移到新的RTBS， RTBS可以计算出T0到当前时间的费用cost1，用原始费用balance0减去cost1就得到该客户的最新余额，而不管前一个RTBS对该呼叫做了多少个Checkpoint操作。
　　
　　如果RTBS发现GK异常，在GK异常时系统有其他方法将GK所负责的呼叫拆除，所有RTBS可以把发现GK异常的时间作为呼叫的结束时间来处理，这样这种异常情况下的处理就显得简单。RTBS计算出这段时间的费用更新到客户账户上，并记录到目前为止的CDR信息中。
　　
　　5. 最后一分钟通知
　　
　　RTBS实时监测每个呼叫的最大通话时间，在通话费用结束前1min通知GK，要求GK主动拆除该呼叫，这是保证客户不透支费用的关键。在GK得到最后1min通知后会把这个信息通知到终端，并在1min后拆除该呼叫。
　　
　　6. 呼叫结束处理
　　
　　呼叫结束，表示完成一个服务。这之后要对这个服务进行完整的记录，同时计算该服务的准确费用。
　　
　　五、结束语
　　本文从Internet计费的基本理论出发，研究了针对VoIP业务的计费系统所应具有的功能以及计费系统中的一些关键问题，并结合一个VoIP系统的模型，着重介绍了一个实时计费系统的实现方法及其关键业务。