WO2010045882A1

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

Info

Publication number: WO2010045882A1
Application number: PCT/CN2009/074593
Authority: WO
Inventors: 尼凌飞; 吴越; 袁泉; 张少伟; 舒续祖; 严光兵; 彭世强
Original assignee: 华为技术有限公司
Priority date: 2008-10-24
Filing date: 2009-10-23
Publication date: 2010-04-29
Also published as: US20110211684A1

Description

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

本申请要求了 2008年 10月 24日提交的、申请号为 200810170764. X、发明名称为 "一种呼叫属性判断方法、设备和系统" 以及 2009年 6月 30日提交的、申请号为 200910150738. 5、发明名称为 "一种呼叫属性判断方法、设备和系统" 的中国申请的优先权，其全部内容通过引用结合在本申请中。技术领域本发明涉及通信技术领域，特别是涉及一种呼叫属性判断方法、设备和系统。发明背景联邦通信委员会（Federal Communications Commission, FCC) 要求北美负责语音呼叫的交换机需要判断呼叫属性（Call Type ) ，比如： Local (本地）， Local Toll (本地收费）， Long Distance (长途）， International (国际)等，其中，北美负责语音呼叫的交换机包括公共交换电话网络交换机（Public Switched Telephone Network Switch, PSTN Switch) 和基于 IP语音技术的电话网络交换机（Voice over Internet Protocol Switch， 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中对主叫终端号码和被叫终端号码的规划信息的査询完成之后，直接保存主叫终端号码和被叫终端号码的规划信息，在这种情况下，后续的呼叫建立过程中，呼叫属性判断流程中的规划信息的査询步骤也将相应发生以下几种情况的变更：

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

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

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

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

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

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

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

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

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

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

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

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

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

需要进一步指出的是，当步骤 S103完成之后，本方法还包括后续的更新流程，具体为：当主叫终端号码和 /或被叫终端号码发生更新时，呼叫控制服务器向号码信息存储服务器査询更新后的主叫终端号码和 /或被叫终端号码对应的规划信息和 /或规划关联信息；

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

需要说明的是，在本实施例中所提到的号码信息存储服务器可以是一个号码信息存储服务器，也可以是由多个号码信息存储服务器组成的号码信息存储服务器池，具体指代内容的变化并不影响本发明的保护范围，这一点在全文中都是一致的，后文不再重复叙述。进一步的，根据具体的应用场景需要，本发明实施例所提出的上述技术方案还可以进一步的调整为如下的两种改进方案：

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

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

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

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

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

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

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

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

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

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

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

呼叫控制服务器在判断呼叫的呼叫属性时，除了 LERG发布的 LATA和 RC信息外， Local Calling Area信息也是一个重要信息，即前文所提到的本地呼叫区域，其作用是帮助呼叫控制服务器进一步判断出 Local或 Local Toll类型的呼叫，但是 Local Calling Area信息并不随 LERG数据发布。结合本实施例的技术思想，可以将主被叫用户所属的 RC Name构造成域名的形式，如 "RCL 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获得相应的主叫终端号码和 /或被叫终端号码的规划信息；和 /或根据主叫终端号码和 /或被叫终端号码的规划信息，査询所述存储模块 11，获得相应的规划关联信息；发送模块 14, 用于向呼叫控制服务器 2发送査询模块 13获得的相应的主叫终端号码和 /或被叫终端号码的规划信息，和 /或査询模块 13获得的相应的规划关联信息。

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

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

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

判断模块 16，用于根据所述査询模块 13获得的相应的主叫终端号码和 /或被叫终端号码的规划信息以及所述规划关联信息，判断所述呼叫请求消息所对应的呼叫业务的呼叫属性，从而在返回査询结果中直接返回呼叫请求消息所对应的呼叫业务的呼叫属性。

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

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

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

接收模块 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 "\x" "sip+E2U" 'Ί ' (· *) $！ sip： \\ 1；

napn_lata=628； napn_rc=TWINCITIES！ " .

*. 8. 9. 6. 7. 0. 2 IN NAPTR 100 10 "\x" "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 Level Domain, 本文为了描述方便，顶级域名暂时用已有的 e l64. 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. e l64. arpa的 DNS域名，其中， e l64. arpa为顶级域名，以便于 ENUM服务器识别该信息。

通过上述的说明，步骤 S402 具体为：呼叫控制服务器通过标准的 ENUM 接口发送包含 " 4. 3. 2. 1. 1. 0. 2. 2. 1. 6. e l64. arpa"的 DNS域名信息的査询消息，请求査询对应的规划信息。

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

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

步骤 S404、呼叫控制服务器向 ENUM服务器发送被叫终端号码规划信息的査询请求消息。即，呼叫控制服务器通过标准的 ENUM接口发送包含 " 1. 2. 3. 4. 8. 9. 6. 7. 0. 2. e l64. arpa" 的 DNS域名信息的査询消息，请求査询对应的规划信息。

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

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

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

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

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

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

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

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

考虑到 IMS网络中呼叫控制和业务分离的架构，业务服务器（Appl icat ion Server, AS ) 在某些场景下也需要能够通过 ENUM査询接口获得用户的 LATA, RC信息。具体的，在 IMS网络中的按照本发明实施例技术方案所提出的呼叫控制网络的组网结构示意图如图 5所示。

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

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

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

为方便说明，在本实施例中同样按照前述实施例假设主叫用户 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. e l64. 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. e l64. arpa " 的 DNS域名信息的査询消息，请求査询对应的规划信息。

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

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

步骤 S607、 S-CSCF根据接收到的主被叫用户号码的规划信息，判断该主被叫用户所对应呼叫业务的呼叫属性类型。步骤 S608、 S-CSCF向 AS发送呼叫建立消息，以建立主叫用户和被叫用户之间的呼叫业务。在本实施例中，呼叫控制服务器通过两次 NAPTR査询分别获得了主被叫的 LATA和 RC信息，再进一步结合本地的判断逻辑，判断出本次呼叫的呼叫类型。继而实现了不需要在本地保存大量数据，即可判断出 Cal l Type的目的。

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

Type。

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

正是因为业务的影响，因此也可以让 AS去实现 Cal l 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. e l64. 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. e l64. arpa" 的 DNS域名信息的査询消息，请求査询对应的规划信息。步骤 S707、 ENUM服务器向 AS发送被叫终端号码规划信息的査询响应消息。

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

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

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

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

进一步的，处于具体应用场景的要求，需要 CSCF和 AS都能够去査询 ENUM服务器，并进行 Cal l 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在收到 S-CSCF发送的用户签约数据后，在 SAA ( Server-Ass ignment-Answer 服务器分配响应）中通过组 AVP格式下载用户所属的规划信息（RC， LATA)；

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

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

步骤 805、 S-CSCF在收到 invite请求后，从 Request-URI中取出被叫的号码并规整；步骤 806、 S-CSCF检査 invite 请求中没有携带 CALL TYPE信息，先使用主叫号码中的 NPA-NXX和被叫号码的 NPA-NXX査询本地配置，如果能够获得呼叫属性则不需要査询被叫规划信息，如果不能获取呼叫属性，则使用被叫号码中的 NPA-NXX组成 TEL格式的 PSI，然后发送 SAR到 HSS获得规划信息；

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

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

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

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

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

需要说明的是，为了避免使用率低的冗余数据占用 HSS/HLR内存空间，所以保存的规划信息遵循一定的保存周期和老化机制，例如保存周期可以使用系统支持的最大注册时长。图 9示出了本发明实施例七中一种呼叫属性判断的流程图，如图 9所示，所述呼叫属性判断流程包括：

步骤 901、 I-CSCF在收到 invite请求后，从 request-uri中取出被叫的号码并规整；步骤 902、 I-CSCF检査请求中没有携带 CALL TYPE信息，先使用主叫号码中的 NPA-NXX和被叫号码的 NPA-NXX査询本地配置，没有获取到 CALL TYPE后，使用主叫号码中的 NPA-NXX组成 TEL格式的 PSI发送 LIR (Locat ion-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数据）和规划关联信息（LOCAL RC ) 数据进行呼叫属性判断，获得呼叫属性，并填写在请求中携带， I-CSCF将主叫号码中的 NPA-NXX, 被叫号码中的 NPA-NXX, 对应的 CALL TYPE保存在本地；

步骤 907、 I-CSCF收到初始 Invite请求后，从主被叫号码中取出 NPA-NXX，査询本地配置获得呼叫属性；

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

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

AS (Application Server, 应用服务器)在本地保存位置关联信息（LOCAL RC)的情况，与上述实施例六、七类似。在 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、 I-CSCF/S-CSCF/AS发送 URR到 HSS ;

步骤 1103、 HSS根据主被叫 PSI査询对应签约数据获得主叫和被叫的规划信息和规划关联信息，根据主被叫的规划信息和规划关联信息进行呼叫属性判断，获得呼叫属性信息，填写在 URA ( User-Re lation-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、如权利要求 16所述的号码信息存储服务器，其特征在于，所述号码信息存储服务器还包括：更新模块，用于根据路由更新指导文件，更新所述存储模块中所存储的号码的规划信息。

20、如权利要求 16所述的号码信息存储服务器，其特征在于，所述号码信息存储服务器具体为：一个号码信息存储服务器，或多个号码信息存储服务器组成的号码信息存储服务器池。

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

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

23、如权利要求 21所述的呼叫控制网络，其特征在于，所述号码信息存储服务器，还用于当所述被叫终端号码为预设的服务号码时，根据所述主叫终端号码的规划信息，生成所述被叫终端号码的规划参数，将该规划参数发送给所述呼叫控制服务器。

24、如权利要求 21所述的呼叫控制网络，其特征在于，所述号码信息存储服务器，具体为：一个号码信息存储服务器，或多个号码信息存储服务器组成的号码信息存储服务器池。