CN101729687A

CN101729687A - 一种呼叫属性判断方法、设备和系统

Info

Publication number: CN101729687A
Application number: CN200910150738A
Authority: CN
Inventors: 尼凌飞; 吴越; 袁泉; 张少伟; 舒续祖; 严光兵; 彭世强
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2008-10-24
Filing date: 2009-06-30
Publication date: 2010-06-09

Abstract

本发明实施例公开了一种呼叫属性判断方法、设备和系统。所述方法包括以下步骤：接收主叫终端发送的包含主叫终端号码和被叫终端号码的呼叫请求消息；根据所述呼叫请求消息，向号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息；根据所述主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应的呼叫业务的呼叫属性。本发明实施例，通过号码信息存储服务器对号码规划信息的集中存储和统一管理，降低了维护成本，通过应用该号码信息存储服务器提出的呼叫属性判断方法、设备和系统，实现了对终端呼叫属性的判断。

Description

一种呼叫属性判断方法、设备和系统

技术领域

本发明涉及通信技术领域，特别是涉及一种呼叫属性判断方法、设备和系统。

背景技术

联邦通信委员会(Federal Communications Commission，FCC)要求北美负责语音呼叫的交换机需要判断呼叫属性(Call Type)，比如：Local，LocalToll，Long Distance，International等，其中，北美负责语音呼叫的交换机包括公共交换电话网络交换机(Public Switched Telephone Network Switch，PSTNSwitch)和基于IP语音技术的电话网络交换机(Voice over Internet ProtocolSwitch，VOIP Switch)两种类型。

由于北美电话号码规划(North America Number Plan)的特点，其涉及到相当大的数据量(几十万行记录)，从而导致需要占用交换机中的大量内存和大量检索过程。

为了能够判断出Call Type，主被叫用户号码的规划信息至关重要，即主被叫号码所属的本地接入和交换区域(Local Access and Transport Area，LATA)和费用中心(Rate Center，RC)信息。FCC将美国(包括加拿大，百慕大等地区)划分为数十个LATA，而每个LATA下面又管辖数十上百个RC，每个号码都属于一个特定的RC。

因此，交换机为了能够准确判断出Call Type，它必须根据主被叫号码查询各自所属的LATA和RC，再结合一定的判断逻辑得到该次呼叫的Call Type。根据FCC规定，号码的前六位，即北美号码的NPA-NXX是可以唯一确定它下面的号码所属的LATA，RC的，而北美NPA-NXX的个数也相应的达到几十万规模。

另外，由于号码及其所属的LATA，RC信息并不是一成不变的，北美有专门的组织会定期以本地交换路由指导文件(Local Exchange Routing Guide，File，LERG File)方式发布最新的数据，通常是LERG6.DAT，LERGINS.DAT的文本文件。

相应的，各个交换机都需要导入该数据，并更新到本地数据中，维护成本高。

以上只是举例，当然并不限于北美，相似应用场景同样可能存在以上问题。

发明内容

本发明实施例提供了一种呼叫属性判断方法、设备和系统。通过用号码信息存储服务器对号码规划信息数据进行存储和管理，降低了维护成本，通过应用该号码信息存储服务器提出的呼叫属性判断方法、设备和系统，实现了对终端呼叫属性的判断。

为达到上述目的，本发明实施例一方面提出一种呼叫属性判断方法，包括以下步骤：

接收主叫终端发送的包含主叫终端号码和被叫终端号码的呼叫请求消息；

根据所述呼叫请求消息，向号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息；

根据所述主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应的呼叫业务的呼叫属性。

另一方面，本发明实施例还提出一种呼叫控制服务器，包括：

接收模块，用于接收主叫终端发送的包含主叫终端号码和被叫终端号码的呼叫请求消息；

第一查询模块，用于向号码信息存储服务器查询所述接收模块所接收呼叫请求消息中的主叫终端号码和/或所述被叫终端号码的规划信息；

判断模块，用于根据所述第一查询模块所查询的所述主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

另一方面，本发明实施例还提供一种号码信息存储服务器，包括：

存储模块，用于存储号码的规划信息和/或规划关联信息；

接收模块，用于接收主叫终端号码和/或被叫终端号码的规划信息查询消息；

查询模块，用于根据所述接收模块所接收的主叫终端号码和/或被叫终端号码的规划信息查询消息，查询存储模块获得相应的主叫终端号码和/或被叫终端号码的规划信息；和/或根据主叫终端号码和/或被叫终端号码的规划信息，查询所述存储模块，获得相应的规划关联信息；

发送模块，用于发送查询模块获得的相应的主叫终端号码和/或被叫终端号码的规划信息，和/或查询模块获得的相应的规划关联信息。

另一方面，本发明实施例还提出一种呼叫控制网络，包括：

号码信息存储服务器，用于存储号码的规划信息和/或规划关联信息，并根据路由更新信息更新所述号码的规划信息；

呼叫控制服务器，用于向所述号码信息存储服务器查询呼叫业务的主叫终端号码和/或被叫终端号码的规划信息，并根据所述规划信息和/或规划关联信息判断所述呼叫业务的呼叫属性。

本发明实施例的技术方案具有以下优点，因为采用了号码信息存储服务器对号码规划信息和/或规划关系信息进行存储和管理，则避免了在每个呼叫控制服务器上存储相关信息数据，实现对终端呼叫属性的判断时，降低了维护成本。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是针对本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一中一种呼叫属性判断方法的流程示意图；

图2为本发明实施例二中一种呼叫控制网络的结构示意图；

图3为本发明实施例中LATA和RC的关系示意图；

图4为本发明实施例三中一种呼叫属性判断方法的流程示意图；

图5为本发明实施例中在IMS网络中进行呼叫属性判断的呼叫控制网络的组网结构示意图；

图6为本发明实施例四中一种由S-CSCF进行呼叫属性判断方法的流程示意图；

图7为本发明实施例五中一种由AS进行呼叫属性判断方法的流程示意图；

图8为本发明实施例六中一种呼叫属性判断方法的流程示意图；

图9为本发明实施例七中一种呼叫属性判断方法的流程示意图；

图10为本发明实施例八中I-CSCF/S-CSCF/AS进行呼叫属性判断方法的流程示意图；

图11为本发明实施例九中HSS/HLR进行呼叫属性逻辑判断方法的流程示意图。

具体实施方式

发明人发现现有技术中每个呼叫控制设备/交换机都需要导入和维护号码规划信息数据，一旦需要刷新，现网上的每个呼叫控制设备/交换机都需要更新号码规划信息数据，维护成本高，也增大了因数据更新过程中，不同呼叫控制设备/交换机上数据不同步而造成问题的可能性；而且号码规划信息数据本身的数据量较大，通常有几十万条数据，在每个呼叫控制设备/交换机上都进行存储，浪费了存储空间，也提高了每个呼叫控制设备/交换机的硬件开销。

针对现有技术中存在的问题，本发明实施例在现有的通信网络系统中增设了一个号码信息存储服务器，对号码规划信息和/或规划关联信息进行集中存储和统一管理，从而，达到了降低硬件和维护成本的效果。进一步的，通过应用该号码信息存储服务器，本发明实施例提出了一种呼叫属性判断方法、设备和系统，实现了对终端呼叫属性的判断。

下面将结合本发明实施例的附图，对本发明实施例描述的技术方案进行清楚、完整地描述，显然，本文所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例一提供了一种呼叫属性判断方法，具体流程示意图如图1所示，包括以下步骤：

步骤S101、接收主叫终端发送的包含主叫终端号码和被叫终端号码的呼叫请求消息。

步骤S102、根据该呼叫请求消息，向号码信息存储服务器查询主叫终端号码和/或被叫终端号码的规划信息。

具体可以包括以下步骤：

通过查询接口，向号码信息存储服务器发送包含主叫终端号码的查询请求消息，接收号码信息查询服务器返回的包含主叫终端号码规划信息的查询响应消息；和/或

通过查询接口，向号码信息存储服务器发送包含被叫终端号码的查询请求消息，接收号码信息查询服务器返回的包含被叫终端号码规划信息的查询响应消息。

需要进一步指出的是，在本步骤中，主叫终端号码和被叫终端号码的规划信息通常是通过两次查询来实现的，但是在具体的应用环境中，为了进一步节约网络资源，减少交互的信息数量，上述的查询步骤可以按照以下两种情况进行简化，具体说明如下：

情况一、当主叫终端注册时，呼叫控制服务器直接保存主叫终端号码的规划信息。

在这种情况下，本步骤中的查询过程将相应的变更为：

获取本地所保存的主叫终端号码的规划信息；

向号码信息存储服务器查询获取被叫终端号码的规划信息。

其中，在本地获取主叫终端号码的规划信息即直接在呼叫控制服务器上进行信息提取，无需再向号码信息存储服务器进行查询。

情况二、在步骤S102中对主叫终端号码和被叫终端号码的规划信息的查询完成之后，直接保存主叫终端号码和被叫终端号码的规划信息，在这种情况下，后续的呼叫建立过程中，呼叫属性判断流程中的规划信息的查询步骤也将相应发生以下几种情况的变更：

当后续接收到主叫终端发送的对其他被叫终端的呼叫请求消息时，获取本地所保存的主叫终端号码的规划信息，向号码信息存储服务器查询其他被叫终端号码的规划信息；或，

当后续接收到其他主叫终端发送的对被叫终端的呼叫请求消息时，获取本地所保存的被叫终端号码的规划信息，向号码信息存储服务器查询其他主叫终端号码的规划信息；或，

当后续接收到主叫终端发送的对被叫终端的呼叫请求消息时，获取本地所保存的主叫终端和被叫终端号码的规划信息。

上述的几种情况的变更方案主要是考虑在本步骤的基础方案中，一个普通的呼叫会涉及至少两次规划信息查询，效率上会有一定影响。因此，本发明提出了进一步的改进方案，一方面引入查询记录的缓存，减少规划信息的查询次数，另一方面则考虑在注册时，就将注册用户的相关信息从号码信息存储服务器上查询出来并保存，如果主被叫都是在一个呼叫控制服务器上时，他们间的呼叫就可以不再去查询号码信息存储服务器了。

步骤S103、根据主叫终端号码和被叫终端号码的规划信息，判断呼叫请求消息所对应呼叫业务的呼叫属性。

需要进一步指出的是，在上述实施例中，呼叫控制服务器是根据主叫终端号码和被叫终端号码的规划信息，判断呼叫请求消息所对应呼叫业务的呼叫属性的。在本发明另一实施例中，也可以根据主叫终端号码、被叫终端号码的规划信息以及规划关联信息(LOCAL RC)，来判断呼叫请求消息所对应呼叫业务的呼叫属性。所述规划关联信息可以保存在本地，也可以保存在号码信息存储服务器中。当规划关联信息保存在号码信息存储服务器中时，可以向号码信息存储服务器查询所述规划关联信息。

具体可以包括以下几种情况：

情况一、根据所述主叫终端号码和所述被叫终端号码的规划信息，向所述号码信息存储服务器发送用户规划关联请求，并根据所述号码信息存储服务器发送的用户规划关联响应，判断所述呼叫请求消息所对应的呼叫业务的呼叫属性。

此处具体是指：所述关联规划信息保存在号码信息存储服务器，呼叫控制服务器根据所述主叫终端号码和所述被叫终端号码的规划信息向所述号码信息存储服务器发送用户规划关联请求，所述号码信息存储服务器查询所述关联规划信息给出用户规划关联响应；所述呼叫控制服务器根据所述用户规划关联响应判断所述呼叫请求消息所对应的呼叫业务的呼叫属性。

情况二、向所述号码信息存储服务器发送包含主叫终端号码和被叫终端号码的呼叫请求消息，并接收所述号码信息存储服务器发送的所述呼叫请求消息所对应的呼叫业务的呼叫属性。

此处具体是指：所述呼叫控制服务器向所述所述号码信息存储服务器发送包含主叫终端号码和被叫终端号码的呼叫请求消息。根据呼叫请求消息，号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息。号码信息存储服务器获得主叫终端号码和/或所述被叫终端号码的规划信息后，可以继续根据规划信息得到规划关联信息，根据规划关联信息，号码信息存储服务器可以判断出呼叫属性，从而在返回查询结果中直接返回呼叫请求消息所对应的呼叫业务的呼叫属性。

在具体的应用环境中，为了进一步节约网络资源，减少交互的信息数量，上述的查询步骤可以简化，具体说明如下：

情况三：对主叫终端号码、被叫终端号码的规划信息以及规划关联信息的查询完成之后，直接保存主叫终端号码、被叫终端号码的规划信息以及规划关联信息，在这种情况下，后续的呼叫建立过程中，主叫终端号码、被叫终端号码的规划信息以及规划关联信息的查询就可以简化。比如可以引入查询记录的缓存，减少规划信息和规划关联信息的查询次数；也可以考虑在注册时，就将注册用户的相关信息从号码信息存储服务器上查询出来并保存，如果主被叫都是在一个呼叫控制服务器上时，他们间的呼叫就可以不再去查询号码信息存储服务器了。

需要进一步指出的是，当步骤S103完成之后，本方法还包括后续的更新流程，具体为：

当主叫终端号码和/或被叫终端号码发生更新时，呼叫控制服务器向号码信息存储服务器查询更新后的主叫终端号码和/或被叫终端号码对应的规划信息和/或规划关联信息；

根据更新后的主叫终端号码、被叫终端号码对应的规划信息和/或规划关联信息，呼叫控制服务器判断呼叫请求消息所对应呼叫业务的呼叫属性。

需要说明的是，在本实施例中所提到的号码信息存储服务器可以是一个号码信息存储服务器，也可以是由多个号码信息存储服务器组成的号码信息存储服务器池，具体指代内容的变化并不影响本发明的保护范围，这一点在全文中都是一致的，后文不再重复叙述。

进一步的，根据具体的应用场景需要，本发明实施例所提出的上述技术方案还可以进一步的调整为如下的两种改进方案：

改进方案一：在号码信息存储服务器中为特殊的业务号码(比如北美的N11业务)配置其所对应的规划参数比如路由号码。

其中，N11是北美特殊号码的一个通称，即211，311，411，511，611，711，811，911，在北美这些号码都有特殊意义，这仅为本发明实施例中为了方便说明而选取的一种示例，对其具体内容本发明不再另行详述。

当被叫终端号码为预设的服务号码时，呼叫控制服务器向号码信息存储服务器查询该服务号码所对应的规划参数，查询过程中，需要向号码信息存储服务器发送的信息包含主叫号码，因为这类业务往往是跟主叫号码所处的位置相关。

以北美通信控制网络为例，对改进方案一的具体实施过程说明如下：

将LATA和RC信息集中存储到E164号码映射(E164 Telephone NumberMapping，ENUM)服务器上的同时，以同样的方式将各号码对应的N11等特殊服务号码也集中存储到ENUM服务器中。

需要说明的是，在北美通信控制网络中，ENUM服务器即为在本发明前述实施例中所提到的号码信息存储服务器，具体名称的改变并不影响本发明的保护范围。

比如，以社区服务号码211为例，当一个用户作为主叫用户拨打211时，在北美，网络侧需要将211翻译成一个规划参数，即一个可路由的10位北美号码规则(North America Numbering Plan，NANP)号码，而翻译的依据是主叫用户号码所属的LATA和RC信息，在最理想的情况下，所翻译的10位NANP号码所属的RC区域与主叫用户号码所属的RC区域应该是一致的，但这仅是本发明示例中最理想的情况，是否一致并不会对本发明的保护范围产生影响。进一步的，将该10位NANP号码以参数的形式配置到用户主叫号码对应的名称权威指针(Naming Authority Pointer，NAPTR)记录中，继而实现将该10位NANP号码随ENUM响应一并返回给呼叫控制服务器，从而实现在主叫方所在地或者就近实现特殊服务业务的目的。

改进方案二：生成主叫终端号码和被叫终端号码的规划域名，以实现呼叫属性的进一步判断。

具体的技术方案说明如下：

根据主叫终端号码和被叫终端号码的规划信息所对应的规划区域名，生成主叫终端号码和被叫终端号码的规划域名；

查询保存本地呼叫域名集合的域名系统中是否包括主叫终端号码和被叫终端号码的规划域名；

当域名系统中包含规划域名时，则判定主叫终端号码和被叫终端号码位于同一本地呼叫区域，并接收域名系统生成的本地呼叫类型参数；当域名系统中未包含规划域名时，则判定主叫终端号码和被叫终端号码位于不同的本地呼叫区域。

同样以北美通信控制网络为例，这种情况的具体实施方案为：

首先，在一个域名系统(Domain Name System，DNS)中，将相邻的RC以关联域名的形式进行存储，例如，RC1分别与RC2和RC3相邻，则在DNS中存储“RC1.RC2”和“RC1.RC3”两个域名，其他相邻的RC也可以依此类推。

呼叫控制服务器在判断呼叫的Call Type时，除了LERG发布的LATA和RC信息外，Local Calling Area信息也是一个重要信息，即前文所提到的本地呼叫区域，其作用是帮助呼叫控制服务器进一步判断出Local或Local Toll类型的呼叫，但是它并不随LERG数据发布。结合本实施例的技术思想，可以将主被叫所属的RC Name构造成域名的形式，如“RC1.RC2”然后查询存储有此类关联域名的DNS的NAPTR记录。

如果查询不到记录，则表示主被叫所属的RC不在一个Local Calling Area里，即主被叫用户之间的呼叫属性不是Local；如果查询到相应的记录，则表示主被叫所属的RC处于同一个Local Calling Area，即主被叫用户之间的呼叫属性是Local。

查询完成后，DNS以参数的形式向呼叫控制服务器返回主被叫用户之间的呼叫属性是Local还是Local Toll的信息。

需要进一步指出的是，改进方案二中所提出的关联域名的技术方案仅是本发明的一种优选实施例，其他可以达到相同的技术效果的处理方法，比如服务资源记录SRV等，也同样属于本发明的保护范围。

本发明实施例的技术方案具有以下优点，因为采用了通过用号码信息存储服务器对号码规划信息数据进行存储和管理，为各呼叫控制服务器提供号码规划信息的查询服务的方案，从而，实现了对号码规划信息的集中存储和统一管理，达到了降低维护成本，节约存储空间和硬件资源的效果。

对应上述的方法，本发明通过实施例二提供了一种呼叫控制网络，结构示意图如图2所示，包括号码信息存储服务器1和呼叫控制服务器2：

号码信息存储服务器1，用于存储号码的规划信息和/或规划关联信息，并可以根据路由更新信息更新号码的规划信息，具体包括：

存储模块11，用于存储号码的规划信息和/或规划关联信息；

接收模块12，用于接收呼叫控制服务器2发送的主叫终端号码和/或被叫终端号码的规划信息查询消息；

查询模块13，用于根据所述接收模块12所接收的主叫终端号码和/或被叫终端号码的规划信息查询消息，查询存储模块11获得相应的主叫终端号码和/或被叫终端号码的规划信息；和/或根据主叫终端号码和/或被叫终端号码的规划信息，查询所述存储模块13，获得相应的规划关联信息；

发送模块14，用于向呼叫控制服务器2发送查询模块13获得的相应的主叫终端号码和/或被叫终端号码的规划信息，和/或查询模块13获得的相应的规划关联信息。

进一步的，号码信息存储服务器1还包括：

更新模块15，用于根据路由更新指导文件，更新所述存储模块11中所存储的号码的规划信息。

其中，以北美通信控制网络为例，这里所提到的路由更新指导文件即为北美有专门的组织定期以LERG File方式发布最新的数据，通常是LERG6.DAT，LERGINS.DAT的文本文件。其他可以达到本发明技术效果的路由更新指导文件也同样属于本发明的保护范围。

号码信息存储服务器中的查询模块13可以查询存储模块11获得主叫终端号码和/或所述被叫终端号码的规划信息。号码信息存储服务器中的查询模块13获得主叫终端号码和/或所述被叫终端号码的规划信息后，可以继续根据规划信息查询存储模块13得到规划关联信息，然后由发送模块向呼叫控制服务器2发送。进一步地，号码信息存储服务器1还可以包括判断模块16，根据规划关联信息，判断出呼叫属性，从而在返回查询结果中直接返回呼叫请求消息所对应的呼叫业务的呼叫属性。

所述号码信息存储服务器1还包括：

判断模块16，用于根据所述查询模块13获得的相应的主叫终端号码和/或被叫终端号码的规划信息以及所述规划关联信息，判断所述呼叫请求消息所对应的呼叫业务的呼叫属性。

生成模块17，用于当所述被叫终端号码为预设的服务号码时，根据所述主叫终端号码的规划信息，生成所述被叫终端号码的规划参数；所述发送模块16发送所述被叫终端号码的规划参数给呼叫控制服务器2。

值得说明的是，号码信息存储服务器1可具体为一个号码信息存储服务器，或多个号码信息存储服务器组成的号码信息存储服务器池。

呼叫控制服务器2，用于向号码信息存储服务器1查询呼叫业务的主叫终端号码和/或被叫终端号码的规划信息，并根据规划信息和/或规划关联信息判断呼叫业务的呼叫属性，包括：

接收模块21，用于接收主叫终端发送的包含主叫终端号码和被叫终端号码的呼叫请求消息。

第一查询模块22，用于向号码信息存储服务器2查询接收模块21所接收呼叫请求消息中的主叫终端号码和/或被叫终端号码的规划信息。

判断模块23，用于根据第一查询模块22所查询的主叫终端号码和被叫终端号码的规划信息以及规划关联信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

进一步的，呼叫控制服务器2还包括：

存储模块24，用于当主叫终端注册时，保存主叫终端号码的规划信息，或，保存第一查询模块22所查询的主叫终端号码和/或被叫终端号码的规划信息。

相应的，第一查询模块22还用于向存储模块24查询主叫终端号码和/或被叫终端号码的规划信息。

再进一步的，呼叫控制服务器2还包括：

生成模块25，用于根据第一查询模块22所查询的主叫终端号码和被叫终端号码的规划信息所对应的规划区域名，生成主叫终端号码和被叫终端号码的规划域名；

第二查询模块26，用于查询保存本地呼叫域名集合的域名系统中是否包括生成模块25生成的主叫终端号码和被叫终端号码的规划域名。

在具体的应用场景中，呼叫控制服务器2可以具体为IP多媒体系统网络中的会话控制功能实体和/或业务服务器；或，软交换网络中的呼叫控制服务器，这样的指代内容的变化并不影响本发明的保护范围。

上述模块可以分布于一个装置，也可以分布于多个装置。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

本发明实施例的技术方案具有以下优点，因为采用了通过用号码信息存储服务器对号码规划信息数据进行存储和管理，为各呼叫控制服务器提供号码规划信息的查询服务的系统设计方案，从而，实现了对号码规划信息的集中存储和统一管理，达到了降低维护成本，节约存储空间和硬件资源的效果。

下面，对应着上述实施例所提出的技术方案，本发明的后续实施例以北美的通信控制网络为例进行详细的技术方案说明，需要指出的是，这仅是本发明的优选实施例，其他符合本技术方案的实施场景要求的网络也同样属于本发明的保护范围。并且，在具体的实施场景中，名词称谓的区别并不影响本发明的保护范围。

相对于北美的通信控制网络，本发明实施例所提出的技术方案主要是通过用ENUM服务器存储和管理号码规划信息(LERG6数据)，并对各呼叫控制服务器提供标准的ENUM查询接口，以达到对号码规划信息集中存储，统一管理的目的，而其中号码规划信息具体包括LATA信息和RC信息等，LATA和RC的关系示意图具体如图3所示。

各呼叫控制服务器可以通过标准的ENUM NAPTR向ENUM服务器查询号码规划信息，主被叫终端的号码通过标准的ENUM查询接口输入给ENUM服务器，通过在ENUM服务器上匹配NAPTR记录，返回该号码所属的LATA、RC等号码规划信息。

由于在北美的通信控制网络中，号码的前六位即NPA-NXX可以唯一确定号码所属的LATA和RC信息，所以，本实施例以前六位号码612-201和207-698的两个号码为例进行说明。

具体的，612-201和207-698在ENUM服务器上的两条NAPTR记录信息如下：

*.1.0.2.2.1.6 IN NAPTR 100 10″u″″sip+E2U″″！^(.*)$！sip:\\1；

napn_lata＝628；napn_rc＝TWINCITIES！″.

*.8.9.6.7.0.2 IN NAPTR 100 10″u″″sip+E2U″″！^(.*)$！sip:\\1；

napn_lata＝120；napn_rc＝BERWICK！″.

通过该信息，可以看到六位号首为612-201的号码通过NAPTR记录，映射到一个Sip URI中，该Sip URI里以参数的形式添加了LATA和RC信息，其中，LATA信息为三位标识，即628，RC信息为最长十位的标识字符，六位号首为612-201的号码对应的RC信息为十位，即TWINCITIES。

这样当呼叫控制服务器以612-201-XXXX的号码来查询ENUM时，这些参数就会作为该号码的规划信息，随着查询响应消息一并返回给呼叫控制服务器。

相类似的，六位号首为207-698的号码通过NAPTR记录，映射到一个Sip URI中，该Sip URI里以参数的形式添加了LATA和RC信息，其中，LATA信息为为三位标识，即120，RC信息为最长十位的标识字符，六位号首为207-698的号码对应的RC信息为七位，RC信息为BERWICK。

为了不和其他ENUM查询混淆，可以定义单独的顶级域名Top LevelDomain，本文为了描述方便，顶级域名暂时用已有的e164.arpa为例。

基于以上的规则设置，下面通过本发明实施例三进行具体的流程说明，假设主叫用户612-201-1234呼叫被叫用户207-698-4321，那么流程图如图4所示，包括以下步骤：

步骤S401、终端向呼叫控制服务器发送呼叫建立请求，该请求中包含主被叫终端的号码信息。

步骤S402、呼叫控制服务器向ENUM服务器发送主叫终端号码规划信息的查询请求消息。

即呼叫控制服务器发送包含主叫用户的E164号码612-201-1234的NAPTR查询消息，请求查询该号码的规划信息。

需要指出的是，在本发明实施例所提出的技术方案中，呼叫控制服务器向ENUM服务器的查询过程是通过标准的ENUM接口来实现的，所以，在向ENUM服务器发送主被叫号码时，是通过将原有的E164号码翻译为符合标准ENUM接口的DNS域名来进行传输的，例如，E164号码612-201-1234将被映射为4.3.2.1.1.0.2.2.1.6.e164.arpa的DNS域名，其中，e164.arpa为顶级域名，以便于ENUM服务器识别该信息。

通过上述的说明，步骤S402具体为：呼叫控制服务器通过标准的ENUM接口发送包含“4.3.2.1.1.0.2.2.1.6.e164.arpa”的DNS域名信息的查询消息，请求查询对应的规划信息。

这一点在全文中都是一致的，后文的实施例中不再重复叙述。

步骤S403、ENUM服务器向呼叫控制服务器发送主叫终端号码规划信息的查询响应消息。

即ENUM服务器发送包含主叫用户号码的规划信息的NAPTR响应消息，向呼叫控制服务器反馈主叫用户号码的规划信息，包括LATA信息和RC信息。

步骤S404、呼叫控制服务器向ENUM服务器发送被叫终端号码规划信息的查询请求消息。

即，呼叫控制服务器通过标准的ENUM接口发送包含“1.2.3.4.8.9.6.7.0.2.e164.arpa”的DNS域名信息的查询消息，请求查询对应的规划信息。

步骤S405、ENUM服务器向呼叫控制服务器发送被叫终端号码规划信息的查询响应消息。

即ENUM服务器发送包含被叫用户号码的规划信息的NAPTR响应消息，向呼叫控制服务器反馈被叫用户号码的规划信息，包括LATA信息和RC信息。

需要进一步指出的是，步骤S402和步骤S403完成了主叫用户号码的规划信息的查询流程，步骤S404和步骤S405完成了被叫用户号码的规划信息的查询流程，但是，主叫用户号码的规划信息的查询流程和被叫用户号码的规划信息的查询流程之间没有必然的先后关系，步骤S402和S403与步骤S404和S405之间先后顺序的变化并不影响本发明的保护范围。

步骤S406、呼叫控制服务器根据接收到的主被叫用户号码的规划信息，判断该主被叫用户所对应呼叫业务的呼叫属性类型。

具体的判断规则说明如下：

参照图3中所示的LATA和RC的关系，假设LATA1中的一个号码A属于RC1，如果该号码呼叫属于LATA2中的一个号码，那么这个呼叫的呼叫属性类型(Call Type)为InterLATA，即在不同的LATA之间进行通信，如果A呼叫LATA1中RC6的一个号码，因为主被叫都属于LATA1，那么这个呼叫的呼叫属性类型(Call Type)为IntraLATA，即在同一个LATA内部进行通信，而如果A呼叫RC1中的一个号码，因为主被叫都属于一个RC，那么这个呼叫的呼叫属性类型(Call Type)为Local。

步骤S407、呼叫控制服务器向被叫用户发送呼叫建立消息，建立主叫用户和被叫用户之间的呼叫业务。

在本实施例中，呼叫控制服务器通过两次NAPTR查询分别获得了主被叫的LATA和RC信息，再进一步结合本地的判断逻辑，判断出本次呼叫的呼叫类型。继而实现了不需要在本地保存大量数据，即可判断出CallType的目的。

具体的，本发明实施例三所提出的技术方案可以在IP多媒体子系统(IPMultimedia Subsystem，IMS)网络中实现，呼叫控制服务器即会话控制功能实体(Call Session Control Function，CSCF)，CSCF可以通过标准ENUM查询接口去ENUM服务器上查询主被叫用户的规划信息，再根据查询的规划信息判断出该呼叫业务的Call Type。

考虑到IMS网络中呼叫控制和业务分离的架构，业务服务器(Application Server，AS)在某些场景下也需要能够通过ENUM查询接口获得用户的LATA，RC信息。

具体的，在IMS网络中的按照本发明技术方案所提出的呼叫控制网络的组网结构示意图如图5所示。

通过该示意图可以看到，在该组网结构中实现了对号码规划信息的集中数据存储，方便了数据的维护和更新，并且CSCF/AS和ENUM之间采用标准的ENUM接口，没有任何扩展，对现有网络结构的更改程度降到最低，有效控制了成本。

需要指出的是，因为该组网结构是集中存储，为了提供更高可靠性，可以将ENUM服务器以资源池的方式部署，以达到负荷分担和容灾的效果。

具体的，本发明通过实施例四具体描述上述的在IMS网络下CSCF进行呼叫属性判断的方法，相应的在IMS中CSCF查询ENUM的呼叫流程示意如图8所示。

为方便说明，在本实施例中同样按照前述实施例假设主叫用户612-201-1234呼叫被叫用户207-698-4321，则该方法包括以下步骤：

步骤S601、终端向P-CSCF(代理CSCF)发送呼叫建立请求，该请求中包含主被叫终端的号码信息。

步骤S602、P-CSCF向S-CSCF(服务CSCF)转发该呼叫建立请求，该请求中包含主被叫终端的号码信息。

步骤S603、S-CSCF向ENUM服务器发送主叫终端号码规划信息的查询请求消息。

即S-CSCF通过标准的ENUM接口发送包含“4.3.2.1.1.0.2.2.1.6.e164.arpa”的DNS域名信息的查询消息，请求查询对应的规划信息。

步骤S604、ENUM服务器向S-CSCF发送主叫终端号码规划信息的查询响应消息。

即ENUM服务器发送包含主叫用户号码的规划信息的NAPTR响应消息，向S-CSCF反馈主叫用户号码的规划信息，包括LATA信息和RC信息。

步骤S605、S-CSCF向ENUM服务器发送被叫终端号码规划信息的查询请求消息。

即S-CSCF通过标准的ENUM接口发送包含“1.2.3.4.8.9.6.7.0.2.e164.arpa”的DNS域名信息的查询消息，请求查询对应的规划信息。

步骤S606、ENUM服务器向S-CSCF发送被叫终端号码规划信息的查询响应消息。

即ENUM服务器发送包含被叫用户号码的规划信息的NAPTR响应消息，向S-CSCF反馈被叫用户号码的规划信息，包括LATA信息和RC信息。

步骤S607、S-CSCF根据接收到的主被叫用户号码的规划信息，判断该主被叫用户所对应呼叫业务的呼叫属性类型。

步骤S608、S-CSCF向AS发送呼叫建立消息，以建立主叫用户和被叫用户之间的呼叫业务。

具体的，在该种呼叫流程下，主叫侧CSCF需要能够分别为主、被叫号码各查一次ENUM服务器，以获得主被叫号码所属的LATA和RC信息，然后结合本地的判断逻辑得出本次呼叫的Call Type。

进一步的，因为某些业务需要知道Call Type才能进行后续的判断和服务，比如限制某种类型的Call Type呼叫，那么CSCF在触发到AS之前，需要将判断出来的Call Type以某种方式带给AS，具体的携带方式可以是在Sip消息中定义某种格式的参数，而当AS的某些业务涉及到对主，被叫号码的更改时，当触发完再到CSCF时，CSCF还需要再次进行Call Type的判断。

正是因为业务的影响，因此也可以让AS去实现Call Type的判断，那么ENUM查询将再AS上执行，具体的流程通过本发明实施例五来说明，其流程示意图如图7所示，包括以下步骤：

步骤S701、终端向P-CSCF发送呼叫建立请求，该请求中包含主被叫终端的号码信息。

步骤S702、P-CSCF向S-CSCF转发该呼叫建立请求，该请求中包含主被叫终端的号码信息。

步骤S703、S-CSCF向AS转发该呼叫建立请求，该请求中包含主被叫终端的号码信息。

步骤S704、AS向ENUM服务器发送主叫终端号码规划信息的查询请求消息。

即AS通过标准的ENUM接口发送包含“4.3.2.1.1.0.2.2.1.6.e164.arpa”的DNS域名信息的查询消息，请求查询对应的规划信息。

步骤S705、ENUM服务器向AS发送主叫终端号码规划信息的查询响应消息。

即ENUM服务器发送包含主叫用户号码的规划信息的NAPTR响应消息，向AS反馈主叫用户号码的规划信息，包括LATA信息和RC信息。

步骤S706、AS向ENUM服务器发送被叫终端号码规划信息的查询请求消息。

即AS通过标准的ENUM接口发送包含“1.2.3.4.8.9.6.7.0.2.e164.arpa”的DNS域名信息的查询消息，请求查询对应的规划信息。

步骤S707、ENUM服务器向AS发送被叫终端号码规划信息的查询响应消息。

即ENUM服务器发送包含被叫用户号码的规划信息的NAPTR响应消息，向AS反馈被叫用户号码的规划信息，包括LATA信息和RC信息。

步骤S708、AS根据接收到的主被叫用户号码的规划信息，判断该主被叫用户所对应呼叫业务的呼叫属性类型。

步骤S709、AS向S-CSCF发送呼叫建立消息，由S-CSCF进行进一步处理，建立主叫用户和被叫用户之间的呼叫业务。

通过上述的技术方案，只要是有对Call Type产生影响的业务，AS都需要查询ENUM服务器。

进一步的，处于具体应用场景的要求，需要CSCF和AS都能够去查询ENUM服务器，并进行Call Type的判断，从而保证数据的准确性，这样的技术方案流程与本发明前述实施例所描述的方法流程类似，也同样属于本发明的保护范围，这里不再赘述。

本发明实施例六具体描述了一种通过在号码信息存储服务器，如HSS/HLR集中保存规划信息，由呼叫控制服务器(S-CSCF/I-CSCF/AS)或号码信息存储服务器(HSS/HLR)实现呼叫属性(CALL TYPE)的判断。下面结合附图8具体说明呼叫属性判断的流程。

步骤801、S-CSCF收到用户注册消息，发送SAR(Server-Assignment-Request服务器分配请求)下载用户签约数据；

需要说明的是，对于未注册用户或本地注册用户数据中没有用户规划信息的用户，S-CSCF可以先使用主叫号码的NPA-NXX查询HSS获得主叫用户的规划信息；

步骤802、HSS在收到用户签约数据后，SAA(Server-Assignment-Answer服务器分配响应)中通过组AVP格式下载用户所属的规划信息(RC，LATA)；

步骤803、S-CSCF在收到SAA后，保存规划信息到本地数据；

步骤804、S-CSCF返回注册200响应；

步骤805、S-CSCF在收到invite请求后，从Request-URI中取出被叫的号码并规整；

步骤806、S-CSCF检查请求中没有携带CALL TYPE信息，先使用主叫号码中的NPA-NXX和被叫号码的NPA-NXX查询本地配置，若可获得呼叫属性则不需要查询被叫规划信息，若发现没有获取到CALL TYPE，则使用被叫号码中的NPA-NXX组成TEL格式的PSI，然后发送SAR到HSS获得规划信息；

步骤807、HSS收到SAR请求后，根据PSI做精确匹配获得对应的PSI的规划信息，通过组AVP格式返回给S-CSCF；

步骤808、S-CSCF根据主被叫的规划信息(RC，LATA数据)和本地保存的规划关联信息(LOCAL RC)数据进行CALL TYPE判断，获得呼叫属性(CALL TYPE)，并填写在请求trunk group参数携带，S-CSCF将主叫号码中的NPA-NXX，被叫号码中的NPA-NXX，对应的CALL TYPE保存在本地。

当本次通话结束后，若用户再次拨打被叫号码，则有以下后续步骤：步骤809、S-CSCF收到初始Invite后，从主被叫号码中取出NPA-NXX，查询本地配置获得CALL TYPE；

步骤810、S-CSCF在发送出请求中携带呼叫属性(CALL TYPE)。

此时，由于S-CSCF已经存储了特定主被叫号码之间的呼叫对应的呼叫属性，因此对于这个初始呼叫请求，不需要查询HSS，而是直接从本地获取呼叫属性即可。

需要说明的是，为了避免使用率低的冗余数据占用HSS/HLR内存空间，所以保存的规划信息遵循一定的保存周期和老化机制，例如保存周期可以使用系统支持的最大注册时长。

图9示出了本发明实施例七中一种呼叫属性判断的流程图，如图11所示，所述呼叫属性判断流程包括：

步骤901、I-CSCF在收到invite请求后，从request-uri中取出被叫的号码并规整；

步骤902、I-CSCF检查请求中没有携带CALL TYPE信息，先使用主叫号码中的NPA-NXX和被叫号码的NPA-NXX查询本地配置，没有获取到CALL TYPE后，使用主叫号码中的NPA-NXX组成TEL格式的PSI发送LIR(Location-Info-Request本地信息请求)下载用户数据；

步骤903、HSS收到LIR请求后，根据PSI做精确匹配获得对应的PSI的规划信息，通过组AVP格式返回LIA(Location-Info-Answer本地信息响应)给I-CSCF；

步骤904、I-CSCF收到LIA后获得主叫规划信息并保存本地，使用被叫号码中的NPA，NXX组成TEL格式的PSI发送LIR下载用户数据；

步骤905、HSS收到LIR请求后，根据PSI做精确匹配获得对应的PSI的规划信息.通过组AVP格式返回LIA给I-CSCF；

步骤906、I-CSCF接收到的LIA后，获取主叫规划信息并保存本地。根据获得的主被叫的规划信息(RC，LATA数据)和规划关联信息(LOCALRC)数据进行CALL TYPE判断，获得呼叫属性(CALL TYPE)，并填写在请求中携带，I-CSCF将主叫号码中的NPA-NXX，被叫号码中的NPA-NXX，对应的CALL TYPE保存在本地；

步骤907、I-CSCF收到初始Invite后，从主被叫号码中取出NPA-NXX，查询本地配置获得CALL TYPE；

步骤908、I-CSCF在发送出请求中携带呼叫属性(CALL TYPE)。

上述实施例中，也可以主被叫规划信息一起从HSS下载。

AS(Application Server，应用服务器)在本地保存位置关联信息(LOCALRC)的情况，与上述实施例六、七类似。在HSS/HLR上保存LATA，RC数据，AS通过SH接口使用PSI下载LATA，RC数据。对于支持第三方注册方并能提供业务的AS在第三方注册的处理过程中，从HSS/HLR上通过SH接口按照用户IMPU下载用户对应的规划信息(RC，LATA)，后续流程同S-CSCF、I-CSCF的获取CALL TYPE流程类似，在此不再赘述。

本发明实施例六、七中描述的呼叫属性判断流程，其中LOCAL RC数据保存在本地，S-CSCF/I-CSCF根据从HSS获取的主被叫的规划信息(RC，LATA)以及本地保存的LOCAL RC数据来判断本次呼叫的呼叫属性(CALL TYPE)；需要进一步说明的是，本发明还可以实施为：LATA，RC，LOCAL RC数据都保存在HSS中，I-CSCF/S-CSCF/AS进行呼叫属性逻辑判断，下面进行说明。

如图10所示，本发明实施例八中I-CSCF/S-CSCF/AS进行呼叫属性逻辑判断的流程包括：

步骤1001-1005、在收到invite请求后，与HSS交互获得主被叫用户的规划信息，流程可以参照前面实施例相关描述，此处不赘述；

步骤1006、呼叫控制服务器(I-CSCF/S-CSCF)或AS使用获得的主被叫规划信息，向HSS发送用户关联关系请求消息，消息中携带关联类型标志(如位置关联)；

此处具体是指：用户规划关联信息(Local RC)保存在HSS/HLR上，HSS根据呼叫控制服务器(I-CSCF/S-CSCF)或AS发送用户关联关系请求消息，查询用户关联信息(Local RC)；

步骤1007、呼叫控制服务器(I-CSCF/S-CSCF)或AS收到HSS返回的位置关联关系响应后，根据关联结果即规划关联信息判断所述呼叫的呼叫属性，具体为：

如果关联结果为无或空，则不改变本地的呼叫属性，如果关联结果为存在关联，则使用关联具体信息替换本地的呼叫属性；

步骤1008、呼叫控制服务器(I-CSCF/S-CSCF)或AS在发送出请求中携带呼叫属性(CALL TYPE)。

本发明实施例与实施例六、七相比，不同点在于所有规划信息和规划关联信息集中存储在HSS/HLR上，减少了数据冗余，提高了数据的可靠性，而呼叫属性的判断逻辑仍由呼叫控制服务器(I-CSCF/S-CSCF)或AS完成，HSS/HLR只作数据存放或管理，并不涉及业务逻辑。

本发明还可以实施为，规划信息，Local RC信息都在HSS/HLR上保存，并且由HSS/HLR进行呼叫属性逻辑判断，这种方式下一次呼叫只用一次交互即可获得呼叫属性信息，提高了整个呼叫控制网络的有效性。下面结合本发明实施例九与附图13进行详细描述。

如图11所示，HSS/HLR进行呼叫属性逻辑判断方法的流程包括：

步骤1101、I-CSCF/S-CSCF/AS收到初始Invite请求后，检查没有携带呼叫属性信息，使用主被叫号码中的NPANXX构造URR(User-Relation-Request用户关联请求)中的主被叫PSI，并在关联管理标志填写为用户标识信息；

步骤1102、发送URR到HSS；

步骤1103、HSS根据主被叫PSI查询对应签约数据获得主叫和被叫的规划信息和规划关联信息，根据主被叫的规划信息和规划关联信息进行呼叫属性判断，获得呼叫属性信息，填写在URA(User-Relation-Answer用户关联响应)响应中的关联具体信息中返回给I-CSCF/S-CSCF/AS，；

步骤1104、I-CSCF/S-CSCF/AS根据关联结果为有关联，从关联具体信息中取出呼叫属性，并填写在发送的invite请求中。

本发明实施例提供的方案，通过IMS/NGN架构下的HSS/HLR或ENUM服务器集中数据存储方式，将LATA和RC数据，和/或Local RC存储在HSS/HLR或者ENUM服务器上，实现用户数据的集中统一管理，然后由呼叫控制服务器或者HSS/HLR根据LATA和RC，和/或Local RC等数据判断呼叫属性，这样既大大节省了呼叫控制设备/交换设备的内存，又减少了判断呼叫属性流程中的交互次数，提高了数据存储的效率和可靠性。

本发明实施例对IMS网络下本发明技术方案的实现流程进行了说明，需要进一步指出的是，本发明实施例所提出的技术方案也可以在软交换网络中实现，即由软交换的呼叫控制服务器负责去ENUM服务器、或升级后的HLR、或HSS/HLR上查询，继而根据查询结果判断出本次呼叫的呼叫类型。因为查询过程同样与本发明前述实施例所描述的方法流程类似，这里就不再重复描述了。

本发明实施例的技术方案具有以下优点，因为采用了通过用号码信息存储服务器(如ENUM服务器、或HSS/HLR)对号码规划信息数据进行存储和管理，为各呼叫控制服务器提供号码规划信息的查询服务的方案，从而，实现了对号码规划信息的集中存储和统一管理，达到了降低维护成本，节约存储空间和硬件资源的效果。

基于号码信息存储服务器，本发明实施例提出的呼叫属性判断方法、设备和系统，可以方便地对终端的呼叫属性进行判断。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以可借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims

1.一种呼叫属性判断方法，其特征在于，包括以下步骤：

2.如权利要求1所述的方法，其特征在于，所述向号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息，具体包括：

向所述号码信息存储服务器发送包含所述主叫终端号码的查询请求消息，接收所述号码信息查询服务器返回的包含所述主叫终端号码规划信息的查询响应消息；和/或

向所述号码信息存储服务器发送包含所述被叫终端号码的查询请求消息，接收所述号码信息查询服务器返回的包含所述被叫终端号码规划信息的查询响应消息。

3.如权利要求1所述的方法，其特征在于，所述方法根据所述主叫终端号码、所述被叫终端号码的规划信息以及规划关联信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

4.如权利要求3所述的方法，其特征在于，所述根据所述主叫终端号码、所述被叫终端号码的规划信息以及规划关联信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性，包括：

根据所述主叫终端号码和所述被叫终端号码的规划信息，向所述号码信息存储服务器发送用户规划关联请求，并根据所述号码信息存储服务器发送的规划关联信息判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

5.如权利要求1所述的方法，其特征在于，所述根据所述主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性，包括：

号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息，并根据所述主叫终端号码和/或所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

6.如权利要求3或5所述的方法，其特征在于，所述号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息，根据所述主叫终端号码和/或所述被叫终端号码的规划信息查询规划关联信息，根据所述规划关联信息判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

7.如权利要求1至5所述的方法，其特征在于，当所述被叫终端号码为预设的服务号码时，所述向号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息，具体为：

向所述号码信息存储服务器查询所述主叫终端号码的规划信息；

接收所述号码信息存储服务器根据所述主叫终端号码的规划信息，根据所述主叫终端号码的规划信息所代表的规划区域，按照预设的规则为所述被叫终端号码生成规划参数。

8.如权利要求7所述的方法，其特征在于，根据所述主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性，具体为：

根据所述主叫终端号码的规划信息和所述被叫终端号码的规划参数，判断所述呼叫请求消息所对应呼叫业务的呼叫属性为本地呼叫，以使所述主叫终端实现对本地服务号码的呼叫业务。

9.如权利要求1所述的方法，其特征在于，根据所述主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性的步骤，还可以包括：

根据所述主叫终端号码和所述被叫终端号码的规划信息所对应的规划区域名，生成所述主叫终端号码和所述被叫终端号码的规划域名；

查询保存本地呼叫域名集合的域名系统中是否包括所述主叫终端号码和所述被叫终端号码的规划域名；

当所述域名系统中包含所述规划域名时，则判定所述主叫终端号码和所述被叫终端号码位于同一本地呼叫区域，并接收所述域名系统生成的本地呼叫类型参数；当所述域名系统中未包含所述规划域名时，则判定所述主叫终端号码和所述被叫终端号码位于不同的本地呼叫区域。

10.如权利要求1所述的方法，其特征在于，所述方法之前，还包括以下步骤：

当所述主叫终端注册时，保存所述主叫终端号码的规划信息；所述向号码信息存储服务器查询所述主叫终端号码和/或所述被叫终端号码的规划信息，具体为：

获取本地所保存的所述主叫终端号码的规划信息；

向所述号码信息存储服务器查询所述被叫终端号码的规划信息。

11.如权利要求1所述的方法，其特征在于，所述根据主叫终端号码和所述被叫终端号码的规划信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性之后，还包括：

保存所述主叫终端号码和所述被叫终端号码的规划信息；

当接收到所述主叫终端发送的对其他被叫终端的呼叫请求消息时，获取本地所保存的所述主叫终端号码的规划信息，向所述号码信息存储服务器查询所述其他被叫终端号码的规划信息；或，

当接收到其他主叫终端发送的对所述被叫终端的呼叫请求消息时，获取本地所保存的所述被叫终端号码的规划信息，向所述号码信息存储服务器查询所述其他主叫终端号码的规划信息；或，

当接收到所述主叫终端发送的对所述被叫终端的呼叫请求消息时，获取本地所保存的所述主叫终端和所述被叫终端号码的规划信息。

12.一种呼叫控制服务器，其特征在于，包括：

13.如权利要求12所述的呼叫控制服务器，其特征在于，还包括：

存储模块，用于当所述主叫终端注册时，保存所述主叫终端号码的规划信息，或，保存所述第一查询模块所查询的所述主叫终端号码和/或所述被叫终端号码的规划信息；

所述第一查询模块，还用于向所述存储模块查询所述主叫终端号码和/或所述被叫终端号码的规划信息。

14.如权利要求12或13所述的呼叫控制服务器，其特征在于，还包括：

生成模块，用于根据所述第一查询模块所查询的主叫终端号码和被叫终端号码的规划信息所对应的规划区域名，生成所述主叫终端号码和所述被叫终端号码的规划域名；

第二查询模块，用于查询保存本地呼叫域名集合的域名系统中是否包括所述生成模块生成的所述主叫终端号码和被叫终端号码的规划域名。

15.如权利要求12或13所述的呼叫控制服务器，其特征在于，所述判断模块，用于根据所述第一查询模块所查询的所述主叫终端号码、所述被叫终端号码的规划信息以及规划关联信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

16.一种号码信息存储服务器，其特征在于，包括：

存储模块，用于存储号码的规划信息和/或规划关联信息；

查询模块，用于根据所述接收模块所接收的主叫终端号码和/或被叫终端号码的规划信息查询消息，查询所述存储模块，获得相应的主叫终端号码和/或被叫终端号码的规划信息；和/或根据主叫终端号码和/或被叫终端号码的规划信息，查询所述存储模块，获得相应的规划关联信息；

发送模块，用于发送查询模块获得的相应的主叫终端号码和/或被叫终端号码的规划信息；和/或查询模块获得的相应的规划关联信息。

17.如权利要求16所述的号码信息存储服务器，其特征在于，还包括：

判断模块，用于根据所述查询模块获得的相应的主叫终端号码和/或被叫终端号码的规划信息以及所述规划关联信息，判断所述呼叫请求消息所对应呼叫业务的呼叫属性。

18.如权利要求16所述的号码信息存储服务器，其特征在于，还包括：

生成模块，用于当所述被叫终端号码为预设的服务号码时，根据所述主叫终端号码的规划信息，生成所述被叫终端号码的规划参数；

所述发送模块发送所述被叫终端号码的规划参数给呼叫控制服务器。

19.一种呼叫控制网络，其特征在于，包括：

号码信息存储服务器，用于存储号码的规划信息和/或规划关联信息；

20.如权利要19所述的呼叫控制网络，其特征在于，所述号码信息存储服务器，还用于根据获得的主叫终端号码和/或被叫终端号码的规划信息以及所述规划关联信息，判断所述呼叫请求消息所对应的呼叫业务的呼叫属性。