CN107493175A - 预付费用户的呼叫控制方法、呼叫控制装置及系统 - Google Patents

Abstract

本发明实施例提供一种预付费用户的呼叫控制方法、呼叫控制装置及系统，当在线计费网元宕机之后，应用服务器向呼叫控制装置发送核验消息以确定核验消息中所携带用户标识信息在预设的控制名单中是否存在，当存在时，呼叫控制装置向应用服务器发送限制指令，使应用服务器根据限制指令对待控制呼叫用户的呼叫进行限制；当不存在时，对该待控制呼叫用户的通话进行离线计费，通过基于信任值的控制名单将信任值低于预设阈值和不低于预设阈值的待控制呼叫用户区分出来，针对这两类用户进行不同方式的呼叫控制。这种有针对性的控制方式在保证运营商利益的同时，又保证了信任值高于预设阈值的待控制呼叫用户的用户体验，增加了呼叫控制的灵活性。

Description

预付费用户的呼叫控制方法、呼叫控制装置及系统

技术领域

本发明涉及通讯技术领域，尤其涉及预付费用户的呼叫控制方法、呼叫控制装置及系统。

背景技术

IMS(IP Multimedia Subsystem，IP多媒体子系统)是一种全新的多媒体业务形式，它能够为终端用户提供新颖、多样化的多媒体业务，IMS不仅可以实现最初的VoIP(Voice over Internet Protocol，网络电话)业务，更重要的是IMS将更有效地对网络资源、用户资源及应用资源进行管理，提高网络的智能，使用户可以跨越各种网络并使用多种终端，感受融合的通信体验。目前IMS网络支持两种计费方式：离线计费和在线计费。

离线计费是指由CDF(Charging Data Function，离线计费网元)收集IMS实体产生的计费信息，将计费信息通过话单的形式传给计费系统，计费系统先保存话单，等到计费周期到来的时候再统一结算所有话单。支持离线计费方式的IMS实体包括AS(Application Server，应用服务器)、P-CSCF(Proxy-CallSession Control Funtion，代理呼叫会话控制功能)、S-CSCF(Serving Call SessionControl Funtion，服务呼叫会话控制功能)、MGCF(Media Gateway ControlFunction，媒体网关控制功能)。请参考图1，图1是现有计费系统的架构图。支持离线计费方式的IMS实体，如AS、P-CSCF等产生离线计费信息，通过Rf口发送给CDF，由CDF产生最终的话单发送给计费系统。离线计费主要在终端用户会话结束后收集计费信息，而且计费系统不会实时影响终端用户所使用服务。

在线计费指的是计费系统通过OCS(Online Charging System，在线计费系统)收集IMS实体产生的计费信息并进行费用扣取的计费方式，支持在线计费方式的IMS实体包括AS。和CDF不同，OCS会根据终端用户的实时账户信息对终端用户的会话进行控制，并且OCS会监视与终端用户所使用的服务有关的费用。请继续结合图1，支持离线计费方式的IMS实体，AS应用服务器将在线计费信息通过Ro口发送给OCS，由OCS负责实时扣费；或者呼叫同时产生在线计费信息和离线计费信息，在线计费信息通过Ro口发送给OCS，由OCS负责实时扣费；离线计费信息通过Rf口发送给CDF，由CDF产生最终的话单，单离线计费产生的话单一般不会用来收费，而是为了异常情况下的对账。

目前，在IMS网络中存在两种计费类型的用户：后付费用户和预付费用户。针对后付费用户只采用离线计费的方式进行计费，而预付费用户则基本采用在线计费的方式。正是由于预付费用户只能通过OCS进行在线计费，所以当OCS宕机，不能提供正常的在线计费功能时，预付费用户发起呼叫的计费就不能按照正常的方式进行了，对于这种情况，目前运营商通常有以下两种控制处理方式：

第一种，运营商利益优先原则，由于OCS宕机，无法获取在宕机期间进行的呼叫计费信息，所以为了不给运营商带来损失，在OCS宕机的时刻就释放所有预付费用户的呼叫，并且拒绝所有预付费用户发起新的呼叫。

第二种，用户体验优先原则，在OCS宕机后，将所有的与服务费用户的计费方式都转换成离线计费方式，即AS先将离线计费信息通过Rf口传递给CDF，由CDF产生话单并传输给计费系统，等到了计费周再统一结算OCS宕机过程中预付费用户所产生的话单。

对于第一种处理方式，运营商的利益暂时确实能够得到保障，之所以说是暂时，是由于这种处理方式太过粗暴，在很大程度上给用户造成了麻烦，降低了用户体验，极有可能会造成用户流失，所以从长期运营的角度来说，这种处理方式也不能保证运营商的利益。

毫无疑义，第二种处理方式的用户体验明显要优于第一种处理方式，但是其也存在一些问题，比如根据第二种处理方式，若用户已经欠费，在在线计费方式下，其已经不能再发起呼叫了，但如果OCS宕机，该用户还是可以发起呼叫。由于预付费用户本身的信用等级可能就不高，特别是那些非实名制的预付费用户，所以这些话单多数没有追缴的可能性，这就给运营商的利益又造成了损失。

综上，上述两种处理方式在OCS当机之后，要么不允许所有的预付费用户进行呼叫，要么就允许所有的预付费用户都可以进行呼叫，没有对预付费用户进行区分，而是通过统一的管理方式对所有预付费用户的呼叫进行控制，从而造成管理缺乏针对性的问题，现在亟需提出一种新的、在OCS宕机情况下对预付费用户的呼叫控制方式。

发明内容

本发明实施例提供的预付费用户的呼叫控制方法、呼叫控制装置及系统，主要解决的技术问题是：解决现有针对预付费用户的呼叫控制方法在OCS宕机之后对预付费用户的呼叫进行方式统一的管理而造成的运营商利益和用户体验度难以两全的技术问题。

为解决上述技术问题，本发明实施例提供一种预付费用户的呼叫控制方法，包括：

接收应用服务器在在线计费网元宕机之后针对待控制呼叫用户发送的核验信息；所述核验信息中包括所述待控制呼叫用户的标识信息；

当所述待控制呼叫用户的标识信息在预设的控制名单中存在时，向所述应用服务器返回对所述待控制呼叫用户进行呼叫限制的限制指令；所述控制名单中包含信任值低于预设阈值的各用户的标识信息；

当所述待控制呼叫用户的标识信息在预设的控制名单中不存在时，对所述待控制呼叫用户的通话进行离线计费。

本发明实施例还提供一种预付费用户的呼叫控制方法，包括：

当在线计费网元宕机之后应用服务器针对待控制呼叫用户向呼叫控制装置发送用于进行呼叫限制判定的核验信息；所述核验信息中包括所述待控制呼叫用户的标识信息；

所述呼叫控制装置接收所述核验消息并确定所述待控制呼叫用户的标识信息在预设的控制名单中是否存在，所述控制名单中包含信任值低于预设阈值的各用户的标识信息；

当存在时：

所述呼叫控制装置向所述应用服务器返回对所述待控制呼叫用户进行呼叫限制的限制指令；

所述应用服务器根据所述限制指令对所述待控制呼叫用户的呼叫进行限制；

当不存在时：

所述呼叫控制装置对所述待控制呼叫用户的通话进行离线计费。

本发明实施例还提供一种呼叫控制装置，包括：

接收模块，用于接收应用服务器在在线计费网元宕机之后针对待控制呼叫用户发送的核验信息；所述核验信息中包括所述待控制呼叫用户的标识信息；

发送模块，用于当所述待控制呼叫用户的标识信息在预设的控制名单中存在时，向所述应用服务器返回对所述待控制呼叫用户进行呼叫限制的限制指令；所述控制名单中包含信任值低于预设阈值的各用户的标识信息；

计费模块，用于当所述待控制呼叫用户的标识信息不在预设的控制名单中存在时，对所述待控制呼叫用户的通话进行离线计费。

本发明实施例还提供一种呼叫控制系统，包括应用服务器和如上所述的呼叫控制装置。

本发明实施例还提供一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行前述的任一项的预付费用户的呼叫控制方法。

本发明的有益效果是：

根据本发明实施例提供的预付费用户的呼叫控制方法、呼叫控制装置、系统以及计算机存储介质，在在线计费网元宕机之后，应用服务器向呼叫控制装置发送核验消息，由呼叫控制装置确定核验消息中所携带的待控制呼叫用户的标识信息在预设的控制名单中是否存在，以此确定该待控制呼叫用户的信任值是否低于预设阈值；当存在即表明需要对该待控制呼叫用户的呼叫进行限制，呼叫控制装置向应用服务器发送限制指令，使应用服务器根据限制指令对待控制呼叫用户的呼叫进行限制。通过基于信任值的控制名单将信任值低于预设阈值和不低于预设阈值的待控制呼叫用户区分出来，针对这两类用户进行不同方式的呼叫控制。这种有针对性的控制方式在保证运营商利益的同时，又保证了信任值高于预设阈值的待控制呼叫用户的用户体验，增加了呼叫控制的灵活性。

附图说明

图1为现有计费系统的一种架构图；

图2为现有在线计费网元正常在线计费的交互图；

图3为本发明实施例一提供的预付费用户的呼叫控制方法的一种流程图；

图4为本发明实施例一中进行离线计费的一种流程图；

图5为本发明实施例二中提供的呼叫控制装置的一种结构示意图；

图6为本发明实施例二中部署呼叫控制装置的服务器的一种结构示意图；

图7为本发明实施例三提供的呼叫控制系统的一种结构示意图；

图8为本发明实施例三提供的呼叫控制系统的另一种结构示意图。

具体实施方式

下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。

实施例一：

为了解决现有技术中R针对预付费用户的呼叫控制方案过于笼统粗放，没有对预付费用户进行针对性的管理从而造成的运营商利益和用户体验度难以两全的问题，本实施例提供一种预付费用户的呼叫控制方法，该方法主要由预付费用户的呼叫控制装置和应用服务器来实现。

为了方便本领域技术人员理解本发明实施例提供的预付费用户的呼叫控制方法，本实施例先对预付费用户正常在线计费的方式进行说明，在OCS正常的情况下，当终端用户发起呼叫的情况下，将会由OCS通过在线计费的方式来对终端用户的消费进行话费扣除，具体过程请参考图2：

S202、用户发起呼叫。

终端用户A请求发起与其他终端用户B之间的会话呼叫，并将呼叫接续请求传输给应用服务器。

S204、应用服务器向在线计费系统申请授权。

由于在线计费方式中，OCS会根据用户的实时账户信息对用户的会话进行控制，并且会监视与用户所使用的服务有关的费用。所以，应用服务器AS在向OCS申请授权的时候，会根据用户A账户中的余额初步向OCS申请通话时长，例如，终端用户A当前发起的呼叫为0.1元/分，其账户余额中已经只剩余1.8元钱了，这时候应用服务器AS可能会根据事先制定的策略先向OCS为用户A申请10分钟的通话时长，值的注意的是，AS申请的通话时长都是在保证运营商利益的前提下的。

S206、在线计费系统响应授权。

OCS接到应用服务器AS发送的授权申请之后，会向AS反馈授权响应，使AS根据授权响应为用户A接续呼叫，OCS会将反馈授权响应的时刻作为用户A呼叫的在线计费起点。

S208、应用服务器为用户A接续呼叫。

应用服务器AS根据OCS发送的授权响应为用户A接续与用户B之间的呼叫，让用户A与用户B进行通信。

当10分钟的通话时长结束后用户A和用户B之间的呼叫还未被释放，即用户A和用户B之间还没有任何一方挂机，这时候，应用服务器AS可能要再次为用户A申请通话时长。由于前10分钟内OCS并未接收到A释放呼叫的通知，所以当10分钟结束的时候，OCS可以确定用户A已经通话10分钟了，其将按照通话类型从用户A的账户余额中扣除前十分钟的话费，因此，这时候用户A的账户中已经仅剩余0.8元，所以当应用服务器AS想要再次为用户A申请通话时长时，只能在余额为0.8元的基础上进行申请。为了保证运营商的利益，这次AS可能只会为用户申请5分钟的通话时长。

S210、用户释放呼叫。

用户A使用新的5分钟通话时长与用户通话3分钟之后就挂断了电话，这时候用户服务器需要通知OCS用户A已经挂断了电话。

S212、应用服务器向OCS发送释放通知。

应用服务器AS获知用户A释放呼叫之后立即通知OCS，让OCS确定在线计费的终止点。

S214、OCS完成话费的扣取。

可以理解的是，当OCS接收到应用服务器AS发送的释放通知时，根据收到释放通知的时刻完成的是最后3分钟的话费扣取，因为之前的话费已经在通话过程中扣取过了。

在OCS宕机，即在线计费网元的在线计费功能不能正常使用时，本实施例提供的预付费用户的呼叫控制方法将通过应用服务器AS与呼叫控制装置的交互解决现有呼叫控制方案的不足。本实施例将从呼叫控制装置侧所执行的流程对预付费用户的呼叫控制方法进行说明。请参见图3：

S302、接收应用服务器在在线计费网元宕机之后针对待控制呼叫用户发送的核验信息。

应用服务器发送核验消息是在待控制呼叫用户已经发起呼叫之后，按照正常在线计费的流程，应用服务器在接收到用户的接续请求之后需要先向OCS发起授权申请，在OCS发出授权响应之后才会为待控制呼叫用户接续呼叫。但由于现在OCS已经宕机，因此应用服务器AS不需要向OCS申请授权，直接按照离线计费的方式为待控制呼叫用户接续呼叫。但为了保证运营商的利益，AS在呼叫接续完成后会立即向呼叫控制装置发送核验消息，以确定该待控制呼叫用户的呼叫是否应当被限制。

由于核验消息是针对待控制呼叫用户发送的，所以核验消息中包括该待控制呼叫用户的标识信息，可以理解的是，标识信息是能够唯一识别该用户的，因此，该标识信息可以是该用户的电话号码或者身份证号码等，由于姓名的重名几率比较高，如果要将姓名作为标识信息的话，可能还需要在标识信息中增加一些其他的能够唯一确定该用户身份的信息。

S304、判断待控制呼叫用户的标识信息在预设的控制名单中是否存在。

预设名单中包含信任值低于预设阈值的各用户的标识信息，在本实施例中，信任值是表征一个用户当前可被信任的程度。

可被信任的程度及信任值可以根据用户当前的账户余额来表征，当前账户余额越多，那么该用户当前就越值得运营商信任。

或者也可以采用用户的历史信用度来表征其信任值，如果采用历史信用度来表征用户的信任值，那么运营商需要建立用户信用系统专门用来对各个用户在日常消费过程中的信用程度进行记录，用户的信用度可以是从其他机构中获取的，例如银行接待、信用卡还款记录等，甚至还可以从现在比较流行的叫车平台上获取用户的消费记录来建立用户信用记录。当然运营商也可以根据用户消费其提供的各项服务的时候所呈现的信用状态自己建立的，例如用户缴纳话费的拖欠状况、用户在运营商提供的商城购买东西时的支付情况等。如果采用信用度来表征待控制呼叫用户的信任值时，其历史信用度越高就越值得运营商信任。

毫无疑义的是，信任值也可以通过上述两个因素共同来表征，例如通过某种算法对用户的当前账户余额和用户的历史信用度进行计算得到一个计算结果，通过这个计算结果来表征信任值，本领域技术人员可以理解的是，这时候不一定计算结果越大信任值就越值得信任，有可能因为算法的关系而导致信任值与计算结果呈反比。除此以外，还可以通过不同逻辑关系的两个因素来表征用户信任值的高低。例如，为用户的当前账户余额和用户的历史信用度分别设置第一阈值和第二阈值，当待控制呼叫用户当前的账户余额高于第一阈值，同时其历史信用度高于第二阈值的时候，就表示该用户的信任值高，值的运营商信任。或者，第一阈值与第二阈值之间为“或”的逻辑关系，用户当前的账户余额和历史信用度中的两者只要有一个满足对应的阈值即表征该用户的信任值高，值得运营商信任。

呼叫控制装置确定预设名单中存在待控制呼叫用户的标识信息的时候，就表示该待控制呼叫用户当前的信任值比较低，并不值得运营商信任。为了保证在在线计费网元OCS宕机之后，该待控制呼叫用户不会给运营商的利益造成损失，所以，在OCS宕机之后，如果呼叫控制装置接收到的核验消息中包含的标识信息在预设名单中存在，则呼叫控制装置向应用服务器返回限制指令，让应用服务器根据限制指令对该待控制呼叫用户的呼叫进行限制。

预设的控制名单可以由在线计费网元OCS在正常的时候实时同步给呼叫控制装置，现在以信任值通过用户的当前账户余额表征为例：在OCS正常的时候，就账户余额低于2元的用户的标识信息同步给呼叫控制装置，在其宕机之后，呼叫控制装置将会通过应用服务器限制余额低于2元的用户发起呼叫。可以理解的是，虽然余额低于2元的用户在OCS宕机后不能正常呼叫，但是如果OCS正常工作，其计费方式依然是在线计费方式，那么该用户依然可以进行正常呼叫直至进入欠费状态。

S306、向应用服务器返回对待控制呼叫用户进行呼叫限制的限制指令。

在确定待控制呼叫用户的标识信息在预设的控制名单中存在时，呼叫控制装置会向应用服务器返回限制指令，应用服务器可以根据接收到的限制指令限制待控制呼叫用户的呼叫。在本实施例中，待控制呼叫用户可以基于其发起呼叫的时间分为两类，第一类待控制呼叫用户发起呼叫的时间在OCS宕机之前，也就是说，在OCS宕机的时候，该待控制呼叫用户正处于通话过程中；另外一类是在OCS宕机之后才发起呼叫的待控制呼叫用户。

对于上述两类用户，只要呼叫控制装置确定控制名单中包含待控制呼叫用户的标识信息，则应用服务器都会对其呼叫进行限制，限制呼叫的方式有这样两种：

第一种，直接释放待控制呼叫用户当前正在进行的呼叫，就是只要确定该待控制呼叫用户的呼叫需要被限制，就立即释放其正在进行的呼叫，这种方式比较粗暴，很可能引起用的不满，因为针对那些在宕机之间已经发起呼叫的用户来说，这时候正处于通话过程中，这时候突然释放呼叫很可能会给用户带来巨大的损失。因此，本实施例还提出另外一种限制方式：

第二种，拒绝待控制呼叫用户在在线计费网元宕机之后发起的呼叫。这种限制方式和第一种限制方式对于在OCS宕机之后发起的呼叫的那些待控制呼叫用户来说并没有任何区别，但对于那些在OCS宕机之前就发起呼叫的用户来说就不一样了，因为这样的控制方式并不会对其正在进行的通话造成任何影响，只是不允许其后续发起的呼叫而已，这样能够在一定程度上减少给用户带来的不便，提高用户体验，减少投诉和客户流失。

S308、对待控制呼叫用户的通话进行离线计费。

当待控制呼叫用户的标识信息在预设的控制名单中不存在时，则说明该待控制呼叫用户的信任值不低于预设阈值，值得运营商的信任，所以，即使在OCS宕机的情况下也可以让继续保持呼叫，并对其通话进行离线计费。离线计费的过程请参见图4：

因为应用服务器是在为待控制呼叫用户进行接续之后才向呼叫控制装置发起呼叫的，所以，在后续的过程中，只要应用服务器不释放呼叫，该待控制呼叫用户就可以实现正常的通话，因此确认待控制呼叫用户的呼叫可以被保持之后，呼叫控制装置可以不向应用服务器AS返回任何消息，二者预先约定不返回限制指令即默认为允许保持通话。当然，呼叫控制装置也可以向AS返回保持指令，而AS则在接收到保持指令之后才保持待控制呼叫用户的呼叫，否则就视为应当对呼叫进行限制。

S402、向应用服务器反馈呼叫保持指令，并将发送呼叫保持指令的时刻作为通话的起始时刻。

呼叫控制装置可以在发送保持指令的同时开始对待控制呼叫用户的呼叫进行离线计费。

S404、接收应用服务器发送的呼叫释放通知，并将接收到呼叫释放通知的时刻作为通话的终止时刻。

待控制呼叫用户通话结束之后会自己挂断电话或者是由被叫端挂断电话，这时候应用服务器AS会通知呼叫控制装置，呼叫控制装置将接收到释放通知的时刻作为通话的终止时刻。

S406、生成待呼叫控制用户对应的离线话单。

通话结束之后，呼叫控制装置根据待控制呼叫用户的标识信息、通话的起始时刻和终止时刻生成话单，然后暂时存储该话单。

S408、在检测到在线计费网元恢复正常时，将离线话单发送给在线计费网元对通话完成扣费。

当呼叫控制装置检测到OCS已经恢复正常的时候，可以将在OCS宕机期间生成的话单都传输给OCS，由OCS根据话单中包含的用户标识信息、通话的起始时刻和终止时刻生成话单对发生在其宕机期间内的所有预付费用户的通话进行扣费。

可以理解的是，上述离线计费的过程可以由呼叫控制装置控制离线计费网元完成，这样能够沿用现有的计费方式，简化了计费流程，或者可以直接将呼叫控制装置部署在离线计费网元中。

在本实施例中，OCS同步到呼叫控制装置中的控制名单是信任值低于预设阈值的用户名单，也就是呼叫需要被限制的那些用户，但是本领域技术人员应当明白的是，如果OCS同步过去的是信任值不低于预设阈值的用户标识信息也是可以的，只是这种情况下呼叫控制装置在确定待控制呼叫用户的呼叫需要被限制时是通过确定待控制呼叫用户的标识信息在控制名单中不存在来进行的。

本发明实施例提供的预付费用户的呼叫控制方法，呼叫控制装置通过预设的控制名单来确定应用服务器是否需要对待控制呼叫用户的呼叫进行限制，能够将信任值低于预设阈值的用户区分出来并对其呼叫进行限制，保障了运营商的利益，同时又不会给其他值得运营商信任的用户造成任何不便，在保障运营商利益和用户体验之间找到了很好的平衡。

实施例二：

本实施例提供一种呼叫控制装置，该装置用于和应用服务器交互，完成OCS宕机期间内对预付费用户的呼叫控制，具体的，请参考图5中提出的呼叫控制装置50：

呼叫控制装置50中包括接收模块502、发送模块504和计费模块506。

接收模块502用于接收应用服务器在在线计费网元宕机之后针对待控制呼叫用户发送的核验信息。

应用服务器发送核验消息是在待控制呼叫用户已经发起呼叫之后，按照正常在线计费的流程，应用服务器在接收到用户的接续请求之后需要先向OCS发起授权申请，在OCS发出授权响应之后才会为待控制呼叫用户接续呼叫。但由于现在OCS已经宕机，因此应用服务器AS不需要向OCS申请授权，直接按照离线计费的方式为待控制呼叫用户接续呼叫。但为了保证运营商的利益，AS在呼叫接续完成后会立即向呼叫控制装置发送核验消息，以确定该待控制呼叫用户的呼叫是否应当被限制。

由于接收模块502接收的核验消息是针对待控制呼叫用户发送的，所以核验消息中包括该待控制呼叫用户的标识信息，可以理解的是，标识信息是能够唯一识别该用户的，因此，该标识信息可以是该用户的电话号码或者身份证号码等，由于姓名的重名几率比较高，如果要将姓名作为标识信息的话，可能还需要在标识信息中增加一些其他的能够唯一确定该用户身份的信息。

发送模块504用于当待控制呼叫用户的标识信息在预设的控制名单中存在时，向应用服务器返回对待控制呼叫用户进行呼叫限制的限制指令。

预设名单中包含信任值低于预设阈值的各用户的标识信息，在本实施例中，信任值是表征一个用户当前可被信任的程度。可被信任的程度及信任值可以根据用户当前的账户余额来表征，当前账户余额越多，那么该用户当前就越值得运营商信任。

或者也可以采用用户的历史信用度来表征其信任值，如果采用历史信用度来表征用户的信任值，那么运营商需要建立用户信用系统专门用来对各个用户在日常消费过程中的信用程度进行记录，用户的信用度可以是从其他机构中获取的，例如银行接待、信用卡还款记录等，甚至还可以从现在比较流行的叫车平台上获取用户的消费记录来建立用户信用记录。当然运营商也可以根据用户消费其提供的各项服务的时候所呈现的信用状态自己建立的，例如用户缴纳话费的拖欠状况、用户在运营商提供的商城购买东西时的支付情况等。如果采用信用度来表征待控制呼叫用户的信任值时，其历史信用度越高就越值得运营商信任。

毫无疑义的是，信任值也可以通过上述两个因素共同来表征，例如通过某种算法对用户的当前账户余额和用户的历史信用度进行计算得到一个计算结果，通过这个计算结果来表征信任值，本领域技术人员可以理解的是，这时候不一定计算结果越大信任值就越值得信任，有可能因为算法的关系而导致信任值与计算结果呈反比。除此以外，还可以通过不同逻辑关系的两个因素来表征用户信任值的高低。例如，为用户的当前账户余额和用户的历史信用度分别设置第一阈值和第二阈值，当待控制呼叫用户当前的账户余额高于第一阈值，同时其历史信用度高于第二阈值的时候，就表示该用户的信任值高，值的运营商信任。或者，第一阈值与第二阈值之间为“或”的逻辑关系，用户当前的账户余额和历史信用度中的两者只要有一个满足对应的阈值即表征该用户的信任值高，值得运营商信任。

发送模块504确定预设名单中存在待控制呼叫用户的标识信息的时候，就表示该待控制呼叫用户当前的信任值比较低，并不值得运营商信任。为了保证在在线计费网元OCS宕机之后，该待控制呼叫用户不会给运营商的利益造成损失，所以，在OCS宕机之后，如果接收模块502接收到了针对该用户的核验消息，则发送模块504向应用服务器返回限制指令，让应用服务器根据限制指令对该待控制呼叫用户的呼叫进行限制。

预设的控制名单可以由在线计费网元OCS在正常的时候实时同步给呼叫控制装置50，由接收模块502接收控制名单。在本实施例中，OCS发送给接收模块502的控制名单是信任值低于预设阈值的用户名单，也就是呼叫需要被限制的那些用户，但是本领域技术人员应当明白的是，如果OCS发送给接收模块502的控制名单是信任值不低于预设阈值的用户标识信息也是可以的，只是这种情况下呼叫控制装置50在确定待控制呼叫用户的呼叫需要被限制时是通过确定待控制呼叫用户的标识信息在控制名单中不存在来进行的。

现在以信任值通过用户的当前账户余额表征为例：在OCS正常的时候，就账户余额低于2元的用户的标识信息同步给呼叫控制装置，在其宕机之后，呼叫控制装置将会通过应用服务器限制余额低于2元的用户发起呼叫。可以理解的是，虽然余额低于2元的用户在OCS宕机后不能正常呼叫，但是如果OCS正常工作，其计费方式依然是在线计费方式，那么该用户依然可以进行正常呼叫直至进入欠费状态。

计费模块506确定当待控制呼叫用户的标识信息不在预设的控制名单中存在时，对待控制呼叫用户的通话进行离线计费。当待控制呼叫用户的标识信息在预设的控制名单中不存在时，则说明该待控制呼叫用户的信任值不低于预设阈值，值得运营商的信任，所以，即使在OCS宕机的情况下也可以让继续保持呼叫，并对其通话进行离线计费。因为应用服务器是在为待控制呼叫用户进行接续之后才向呼叫控制装置发起呼叫的，所以，在后续的过程中，只要应用服务器不释放呼叫，该待控制呼叫用户就可以实现正常的通话，因此确认待控制呼叫用户的呼叫可以被保持之后，呼叫控制装置可以不向应用服务器AS返回任何消息，二者预先约定不返回限制指令即默认为允许保持通话。当然，呼叫控制装置也可以向AS返回保持指令，而AS则在接收到保持指令之后才保持待控制呼叫用户的呼叫，否则就视为应当对呼叫进行限制。

计费模块506在开始离线计费的同时向送呼叫保持指令的时刻作为通话的起始时刻。待控制呼叫用户通话结束之后会自己挂断电话或者是由被叫端挂断电话，这时候应用服务器AS会通知呼叫控制装置50，接收到应用服务器发送的呼叫释放通知之后，计费模块506并将接收到呼叫释放通知的时刻作为通话的终止时刻。计费模块506根据待控制呼叫用户的标识信息、通话起始时刻、终止时刻生成话单并进行暂时存储，当检测到在线计费网元恢复正常时，计费模块506将离线话单发送给在线计费网元，由OCS根据话单中包含的用户标识信息、通话的起始时刻和终止时刻生成话单对发生在其宕机期间内的所有预付费用户的通话进行扣费。

本实施例提供的呼叫控制装置50的功能可以由离线计费网元来实现，其可以部署在服务器上，下面结合服务器的具体结构示意图来对本实施例中的呼叫控制装置50进行说明，请参考图6：

呼叫控制装置中的接收模块可以由服务器中通信装置66来实现，而发送模块的功能则由处理器62和通信装置66共同实现，最后计费模块执行的流程可以由处理器62、存储器64和通信装置66来执行。当通信装置66接收到应用服务器发送的核验信息后，通过输入输出总线68将信息传输给处理器62，处理器62从存储器64中读取预先存储的控制名单，如果控制名单中包含核验信息中携带的用户标识，则通过输入输出总线68控制通信装置66向应用服务器发送限制指令。如果处理器62确定控制名单中不存在核验信息中携带的用户标识信息，则通过通信装置66向应用服务器反馈保持指令，使应用服务器对待控制呼叫用户的呼叫进行保持。与此同时，处理器62将发送保持指令的时刻作为通话的起始时刻，当通过通信装置66接收到释放通知时，记录通话终止时刻，然后处理器62根据用户标识信息、通话起始时刻、结束时刻生成话单，本存储在存储器64内。当检测到OCS已经恢复正常的时候，将该话单通过通信装置66发送给OCS，使OCS对发生在其宕机期间内的所有预付费用户的通话进行扣费。在本实施例中，通信装置66与外界的通信可以采用有线的方式，也可以采用无线的方式。

实施例三：

本实施例提供一种呼叫控制系统，如图7所示，该呼叫控制系统7包括应用服务器60和实施例二提供的呼叫控制装置50。

实施例二中提及的服务器可以采用本实施例中的应用服务器60。

在确定待控制呼叫用户的标识信息在预设的控制名单中存在时，呼叫控制装置50会向应用服务器60返回限制指令，应用服务器60可以根据接收到的限制指令限制待控制呼叫用户的呼叫。在本实施例中，待控制呼叫用户可以基于其发起呼叫的时间分为两类，第一类待控制呼叫用户发起呼叫的时间在OCS宕机之前，也就是说，在OCS宕机的时候，该待控制呼叫用户正处于通话过程中；另外一类是在OCS宕机之后才发起呼叫的待控制呼叫用户。

对于上述两类用户，只要呼叫控制装置50确定控制名单中包含待控制呼叫用户的标识信息，则应用服务器60都会对其呼叫进行限制，限制呼叫的方式有这样两种：

第一种，直接释放待控制呼叫用户当前正在进行的呼叫，就是只要确定该待控制呼叫用户的呼叫需要被限制，就立即释放其正在进行的呼叫，这种方式比较粗暴，很可能引起用的不满，因为针对那些在宕机之间已经发起呼叫的用户来说，这时候正处于通话过程中，这时候突然释放呼叫很可能会给用户带来巨大的损失。因此，本实施例中的应用服务器60还提供另外一种限制方式：

第二种，应用服务器60拒绝待控制呼叫用户在在线计费网元宕机之后发起的呼叫。这种限制方式和第一种限制方式对于在OCS宕机之后发起的呼叫的那些待控制呼叫用户来说并没有任何区别，但对于那些在OCS宕机之前就发起呼叫的用户来说就不一样了，因为这样的控制方式并不会对其正在进行的通话造成任何影响，只是不允许其后续发起的呼叫而已，这样能够在一定程度上减少给用户带来的不便，提高用户体验，减少投诉和客户流失。

在确定待控制呼叫用户的标识信息在预设的控制名单中不存在时，呼叫控制装置50会向应用服务器60返回保持指令，并对待控制呼叫用户的通话进行离线计费。

在本实施例的另一个示例当中，如图8，呼叫控制系统7还包括在线计费网元80，针对离线积分生成的话单，呼叫控制装置50会在在线计费网元80恢复正常之后再传输给在线计费网元80，让在线计费网元80对预付费用户的通话完成扣费。

图8中所输出的在线计费网元80在其正常的时候，会将信任值低于预设阈值的预付费用户的标识信息实时同步至呼叫控制装置50中，形成呼叫控制装置50确定待控制呼叫用户是否需要被呼叫限制的控制名单。信任值的表征方式可以参考实施例一或二，这里不再赘述。可以理解的是，呼叫控制装置50功能可以由离线计费网元来实现。

在本实施例提供的呼叫控制系统，通过基于信任值的控制名单将信任值低于预设阈值和不低于预设阈值的待控制呼叫用户区分出来，针对这两类用户进行不同的呼叫控制方式。这种有针对性的控制方式在保证运营商利益的同时，又保证了信任值高于预设阈值的待控制呼叫用户的用户体验，增加了呼叫控制的灵活性。

显然，本领域的技术人员应该明白，上述本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在计算机存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (10)

1.一种预付费用户的呼叫控制方法，包括：

接收应用服务器在在线计费网元宕机之后针对待控制呼叫用户发送的核验信息；所述核验信息中包括所述待控制呼叫用户的标识信息；

当所述待控制呼叫用户的标识信息在预设的控制名单中存在时，向所述应用服务器返回对所述待控制呼叫用户进行呼叫限制的限制指令；所述控制名单中包含信任值低于预设阈值的各用户的标识信息；

当所述待控制呼叫用户的标识信息在预设的控制名单中不存在时，对所述待控制呼叫用户的通话进行离线计费。

2.如权利要求1所述的预付费用户的呼叫控制方法，其特征在于，所述信任值的确定方式包括以下三种中的任意一种：

通过用户的当前账户余额表征其信任值；

通过用户的历史信用度表征其信任值；

通过用户的当前账户余额和历史信用度表征其信任值。

3.如权利要求1所述的预付费用户的呼叫控制方法，其特征在于，所述接收应用服务器在在线计费网元宕机之后发送的核验信息之前还包括：接收所述在线计费网元发送的所述控制名单。

4.如权利要求1-3任一项所述的预付费用户的呼叫控制方法，其特征在于，所述对所述待控制呼叫用户的通话进行离线计费包括：

向所述应用服务器反馈呼叫保持指令，并将发送所述呼叫保持指令的时刻作为所述通话的起始时刻；

接收所述应用服务器发送的呼叫释放通知，并将接收到所述呼叫释放通知的时刻作为所述通话的终止时刻；

生成所述待呼叫控制用户对应的离线话单，所述离线话单中至少包括所述待呼叫控制用户的标识信息、所述起始时刻与所述终结时刻；

在检测到所述在线计费网元恢复正常时，将所述离线话单发送给所述在线计费网元对所述通话完成扣费。

5.一种预付费用户的呼叫控制方法，包括：

当在线计费网元宕机之后应用服务器针对待控制呼叫用户向呼叫控制装置发送用于进行呼叫限制判定的核验信息；所述核验信息中包括所述待控制呼叫用户的标识信息；

所述呼叫控制装置接收所述核验消息并确定所述待控制呼叫用户的标识信息在预设的控制名单中是否存在，所述控制名单中包含信任值低于预设阈值的各用户的标识信息；

当存在时：

所述呼叫控制装置向所述应用服务器返回对所述待控制呼叫用户进行呼叫限制的限制指令；

所述应用服务器根据所述限制指令对所述待控制呼叫用户的呼叫进行限制；

当不存在时：

所述呼叫控制装置对所述待控制呼叫用户的通话进行离线计费。

6.如权利要求5所述的预付费用户的呼叫控制方法，其特征在于，所述应用服务器根据所述限制指令对所述待控制呼叫用户的呼叫进行限制包括以下两种中的任意一种：

释放所述待控制呼叫用户正在进行的呼叫；所述待控制呼叫用户包括在所述在线计费网元宕机之前已经开始呼叫的用户或在所述在线计费网元宕机之后发起呼叫的用户；

拒绝所述待控制呼叫用户在在线计费网元宕机之后发起的呼叫。

7.一种呼叫控制装置，其特征在于，包括：

接收模块，用于接收应用服务器在在线计费网元宕机之后针对待控制呼叫用户发送的核验信息；所述核验信息中包括所述待控制呼叫用户的标识信息；

发送模块，用于当所述待控制呼叫用户的标识信息在预设的控制名单中存在时，向所述应用服务器返回对所述待控制呼叫用户进行呼叫限制的限制指令；所述控制名单中包含信任值低于预设阈值的各用户的标识信息；

计费模块，用于当所述待控制呼叫用户的标识信息不在预设的控制名单中存在时，对所述待控制呼叫用户的通话进行离线计费。

8.如权利要求7所述的呼叫控制装置，其特征在于，所述接收模块在接收应用服务器发送的所述核验信息之前还用于接收所述在线计费网元发送的所述控制名单。

9.如权利要求7或8所述的呼叫控制装置，其特征在于，所述计费模块用于：

向所述应用服务器反馈呼叫保持指令，并将发送所述呼叫保持指令的时刻作为所述通话的起始时刻；

接收所述应用服务器发送的呼叫释放通知，并将接收到所述呼叫释放通知的时刻作为所述通话的终止时刻；

生成所述待呼叫控制用户对应的离线话单，所述离线话单中至少包括所述待呼叫控制用户的标识信息、所述起始时刻与所述终结时刻；

在检测到所述在线计费网元恢复正常时，将所述离线话单发送给所述在线计费网元对所述通话完成扣费。

10.一种呼叫控制系统，其特征在于，包括应用服务器和如权利要求7-9任一项所述的呼叫控制装置。