WO2010097041A1

WO2010097041A1 - 一种呼叫处理方法、系统及装置

Info

Publication number: WO2010097041A1
Application number: PCT/CN2010/070738
Authority: WO
Inventors: 资小兵; 章发太
Original assignee: 华为技术有限公司
Priority date: 2009-02-27
Filing date: 2010-02-24
Publication date: 2010-09-02
Also published as: EP2395707A4; US8442190B2; CN101820410A; EP2395707A1; EP2395707B1; ES2420999T3; CN101820410B; US20130301819A1; US20110311039A1

Abstract

本发明实施例公开了一种呼叫处理方法、系统及装置,该呼叫处理方法包括:呼叫发起方获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息, 所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的呼叫管理器;所述呼叫发起方根据所述全部或部分呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息;所述呼叫发起方接收来自所述相邻的呼叫管理器的第一呼叫建立响应消息。采用本发明实施例,在客户侧业务需要经过多个服务侧网络传送的情况下,通过分段呼叫处理可以实现域间链路选择及准入控制。

Description

一种呼叫处理方法、系统及装置本申请要求于 2009 年 2 月 27 日提交中国专利局、申请号为 200910037565.6, 发明名称为"一种呼叫处理方法、系统及装置"的中国专利申请的优先权，在先申请文件的内容通过引用结合在本申请中。

技术领域

本发明涉及通信领域，尤其涉及一种呼叫处理方法、系统及装置。

背景技术

在通信网络中，用户可以通过运营商网络提供的连接业务来连通自己的设备，例如，用户可以通过某个光网络运营商提供的光连接业务来连接两台路由器。在网络中引入控制平面的情况下，控制平面定义通用的协议，可以实现用户业务的快速自动创建。该协议包括呼叫和连接两部分，呼叫用于实现用户接入权限的认证、用户侧链路信息的交换等功能，连接主要实现用户业务的提供，即在运营商网络中进行资源分配及预留。

参见图 1 , 是现有技术的呼叫模型示意图，两客户侧网络利用 UNI ( User Network Interface )链路接入服务侧网络，服务侧网络传送客户侧信号到另一端。 U I两端节点中，客户侧网络中的节点称作 U I-C, 服务侧网络中的节点称作 U I-N。

在建立 U I-C 之间的连接之前，先建立呼叫以实现两端路由信息的交互，以及服务侧网络的准入控制功能，呼叫建立成功之后，再建立相应的连接。客户侧网络设备发起的呼叫，可以由服务侧网络的接入设备进行处理，也可以由一个专门的单元来处理，其中，处理呼叫的单元称作呼叫管理器（ Call Manager )。

如图 1所示，在建立 U I-C1和 U I-C2之间的连接之前， U I-C1发起呼叫建立过程，即发送呼叫建立请求消息到 UNI-N1 , 消息中携带请求带宽等相关信息。 U I-N1根据预先配置的策略确定是否允许该呼叫，如果允许，则将呼叫建立请求消息转发到 U I-N2, U I-N2再将呼叫建立请求消息转发到 U I-C2。 U I-C2查看本地 U I链路带宽等信息，如果满足需求，则返回呼叫建立响应消息给 UNI-N2, 消息中可以携带本地可用 UM链路信息，用于建立连接时指定可用链路。 U I-N2再将呼叫建立响应消息转发给 U I-N1, U I-N1 再转发给 U I-C1, 至此呼叫建立成功。在上述过程中， U I-C1、 U I-N1、 UNI-N2、 U I-C2 都具有处理呼叫的功能，即都实现了呼叫管理器的功能。

呼叫建立成功之后，发起连接建立过程。例如， U I-C1发送连接建立请求消息给 U I-N1, 指定建立到 U I-C2 的连接，并指定远端链路。 U I-N1 计算合适的路径，并建立到 U I-C2的连接。

发明人在实施本发明的过程中，发现现有的呼叫模型至少具有如下缺点：现有的通用多协议标签交换（ GMPLS, General Multi-Protocol Label Switch ) 呼叫模型只支持端到端的呼叫处理，在连接业务经过多个服务侧网络（假定每个服务侧网络划分为一个域）的情况下，现有的呼叫模型不支持各域对呼叫的分段处理，从而不支持域间链路选择及各域的准入控制等功能。发明内容

本发明实施例所要解决的技术问题是：提供一种呼叫处理方法、系统及装置，克服现有技术中在客户侧业务经过多个服务侧网络的情况下，不支持各域对呼叫进行分段处理的缺陷。

为解决上述问题，本发明实施例提供了一种呼叫处理方法，该方法包括：呼叫发起方获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的呼叫管理器；

所述呼叫发起方根据所述全部或部分呼叫管理器的地址信息中的所述第一呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息；所述呼叫发起方接收来自所述相邻的呼叫管理器的第一呼叫建立响应消息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器针对所述第一呼叫建立请求消息发出。

相应地，本发明实施例还提供了一种呼叫处理方法，该方法包括：呼叫管理器获得处理呼叫的网域中该呼叫管理器和呼叫接收节点之间的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与该呼叫管理器相邻的下一个呼叫管理器；

所述呼叫管理器根据所述全部或部分呼叫管理器的地址信息中的所述下一个呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息，所述第三呼叫建立请求消息包括所述全部或部分呼叫管理器的地址信息；

所述呼叫管理器接收来自所述相邻的呼叫管理器的第三呼叫建立响应消息，所述第三呼叫建立响应消息由所述相邻的呼叫管理器针对所述第三呼叫建立请求消息发出。

相应地，本发明实施例还提供了一种呼叫处理方法，该方法包括：接收呼叫发起节点发送的携带业务信息的呼叫建立请求消息；

根据所述业务信息和预置的拓朴信息，获得处理所述呼叫的第二网域的呼叫管理器的地址信息；

将所述携带业务信息的呼叫建立请求消息发送至第二网域的呼叫管理器；

接收来自所述第二网域的呼叫管理器的呼叫建立响应消息，所述呼叫建立响应消息包括呼叫接收节点的可用链路信息和第二网域的呼叫标识，所述第二网域的呼叫标识基于所述业务信息确定；

将所述呼叫建立响应消息中第二网域的呼叫标识替换为第一网域的呼叫标识，其中，所述第一网域的呼叫标识基于所述业务信息确定，所述第二网域接入所述第一网域的信息流；发送经替换的呼叫建立响应消息至所述呼叫发起节点。

相应地，本发明实施例还提供了一种呼叫处理方法，该方法包括：呼叫发起方获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的第一呼叫管理器；

所述呼叫发起方根据所述全部或部分呼叫管理器地址信息中的所述第一呼叫管理器的地址信息向所述第一呼叫管理器发送呼叫建立请求消息；所述第一呼叫建立请求消息中包括所述全部或部分呼叫管理器的地址信息；

所述第一呼叫管理器接收所述呼叫建立请求消息，删除所述第一呼叫建立请求消息中的第一呼叫管理器的地址信息，判断该呼叫建立请求消息中是否包括第二呼叫管理器的地址信息，所述第二呼叫管理器为与所述第一呼叫管理器相邻的靠近呼叫终止方的呼叫管理器；

当所述呼叫建立请求消息中不包括所述第二呼叫管理器的地址信息时，所述第一呼叫管理器获取所述第二呼叫管理器的地址信息，将所述第二呼叫管理器的地址信息添加到所述呼叫建立请求消息，根据获取的所述第二呼叫管理器的地址信息将所述呼叫建立请求消息发送到第二呼叫管理器；

所述第二呼叫管理器向该第二呼叫管理器的下一个呼叫管理器发送呼叫建立请求消息，并从该第二呼叫管理器的下一个呼叫管理器接收所述下一个呼叫管理器根据接收的呼叫建立请求消息发送的呼叫建立响应消息，将所述呼叫建立响应消息传送给所述第一呼叫管理器；

所述第一呼叫管理器将所述呼叫建立响应消息传送给所述呼叫发起方。相应地，本发明实施例还提供了一种节点，包括：

第一地址获取单元，用于获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的呼叫管理器；

第一请求单元，用于根据所述全部或部分呼叫管理器的地址信息中的所述第一呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息；

第一响应接收单元，用于接收来自所述相邻的呼叫管理器的第一呼叫建立响应消息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器针对所述第一呼叫建立请求消息发出。

相应地，本发明实施例还提供了一种呼叫管理器，包括：

第二地址获取单元，用于获得处理呼叫的网域中该呼叫管理器和呼叫接收节点之间的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与该呼叫管理器相邻的下一个呼叫管理器；

第二请求单元，用于根据所述全部或部分呼叫管理器的地址信息中的所述下一个呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息，所述第三呼叫建立请求消息包括所述全部或部分呼叫管理器的地址信息；

第二响应接收单元，用于接收来自所述相邻的呼叫管理器的第三呼叫建立响应消息，所述第三呼叫建立响应消息由所述相邻的呼叫管理器针对所述第三呼叫建立请求消息发出。

相应地，本发明实施例还提供了一种呼叫管理器，包括：消息收发单元和处理单元；

所述消息收发单元，用于接收呼叫发起方发送的携带业务信息的呼叫建立请求消息；

所述处理单元，用于获得处理呼叫发起方的呼叫的多个网域的呼叫管理器的地址信息，才艮据所述地址信息确定处理所述呼叫的呼叫管理器；

则所述消息收发单元还用于将所述呼叫建立请求消息转发至所述处理单元所确定的呼叫管理器，并接收来自所述呼叫管理器的呼叫建立响应消息，将所述呼叫建立响应消息发送至所述呼叫发起方。

相应地，本发明实施例还提供了一种呼叫处理系统，包括：呼叫发起节点、呼叫接收节节点以及多个呼叫管理器；

所述呼叫发起节点，用于发送呼叫建立请求消息，请求建立所述呼叫发起节点到所述呼叫接收节点的呼叫；

所述呼叫管理器，用于接收所述呼叫发起节点发送的携带业务信息的呼叫建立请求消息，获得处理呼叫的多个网域的呼叫管理器的地址信息，根据所述地址信息确定处理所述呼叫的相邻的呼叫管理器，向所述相邻的呼叫管理器发送呼叫建立请求消息；接收来自所述相邻的呼叫管理器的呼叫建立响应消息，将所述呼叫建立响应消息发送至所述呼叫发起节点；所述呼叫建立响应消息由所述相邻的呼叫管理器根据接收的呼叫建立请求消息发出。

釆用本发明实施例，具有如下有益效果：

在客户侧业务需要经过多个服务侧网络传送的情况下，本发明实施例提供的呼叫处理方法、系统及装置，通过对呼叫发起方的呼叫进行分段处理，实现各个网域之间的链路选择及准入控制。

附图说明

图 1是现有技术提供的呼叫模型示意图；

图 2是本发明实施例提供的呼叫处理方法的第一实施例的流程图；图 3是本发明实施例提供的呼叫处理方法的第二实施例的流程图；图 4是本发明实施例提供的呼叫处理方法的第一场景示意图；

图 5是本发明实施例提供的呼叫处理方法的第三实施例的流程图；图 6是本发明实施例提供的呼叫处理方法的第二场景示意图；

图 7是本发明实施例提供的节点的结构示意图；

图 8是本发明实施例提供的呼叫管理器的结构示意图；

图 9是本发明实施例提供的叫处理系统的结构示意图。

具体实施方式

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

参见图 2, 是本发明实施例提供的呼叫处理方法的第一实施例的流程图。在客户侧业务需要经过多个服务侧网络（假定每个服务侧网络划分为一个网域）传送的情况下，通过分段呼叫处理实现域间链路选择及准入控制。该呼叫过程包括如下步骤：

5100、呼叫发起方获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的呼叫管理器；

5101、所述呼叫发起方根据所述全部或部分呼叫管理器的地址信息中的所述相邻呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息；

5102、所述呼叫发起方接收来自所述相邻的呼叫管理器的第一呼叫建立响应消息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器针对所述第一呼叫建立请求消息发出。

所述呼叫发起方可以是客户侧节点，也可以是网络侧节点。在具体实施当中，所述地址信息包括处理该呼叫的多个网域中的全部或部分呼叫管理器的地址，该地址信息可以是预先配置的，也可以由呼叫发起方或第一网域的呼叫管理器根据呼叫业务信息及预置的拓朴信息计算获得。

其中，所述第一呼叫请求消息中包括所述全部或部分呼叫管理器的地址信息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器在向该相邻的呼叫管理器的下一个呼叫管理器发送第二呼叫建立请求消息，并从该下一个呼叫管理器接收到第二呼叫建立响应消息后发送；所述第二呼叫建立响应消息由所述下一个呼叫管理器针对所述第二呼叫建立请求消息发出；所述第二呼叫请求消息中包括所述下一个呼叫管理器的地址信息，还包括所述全部或部分呼叫管理器的地址信息中除所述相邻的呼叫管理器和所述下一个呼叫管理器外的其它呼叫管理器的地址信息。

所述相邻的呼叫管理器属于第一网域，所述下一个呼叫管理器属于第二网域，所述第二呼叫响应消息中包括所述第一网域和所述第二网域的可用域间链路信息。所述第一呼叫建立响应消息中包括处理所述呼叫的网域之间的可用域间链路信息。

本发明实施例提供的呼叫处理方法，在客户侧业务需要经过多个服务侧网络传送的情况下，能够实现多个呼叫管理器对呼叫进行分段处理，从而进一步实现各个网域之间的链路选择及准入控制。

参见图 3 , 是本发明实施例提供的呼叫处理方法的第二实施例的流程图。 S200、呼叫管理器获得处理呼叫的网域中该呼叫管理器和呼叫接收节点之间的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与该呼叫管理器相邻的下一个呼叫管理器；

S201、所述呼叫管理器根据所述全部或部分呼叫管理器的地址信息中的所述下一个呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息，所述第三呼叫建立请求消息包括所述全部或部分呼叫管理器的地址信息；

S202、所述呼叫管理器接收来自所述下一个呼叫管理器的第三呼叫建立响应消息，所述第三呼叫建立响应消息由所述下一个呼叫管理器针对所述第三呼叫建立请求消息发出。

其中，所述第三呼叫建立响应消息由所述下一个呼叫管理器在向该下一个呼叫管理器的靠近呼叫终止方的相邻呼叫管理器发送第四呼叫建立请求消息，并从该相邻呼叫管理器接收到第四呼叫建立响应消息后发送；所述第三呼叫请求消息中包括所述相邻呼叫管理器的地址信息，还包括所述全部或部分呼叫管理器的地址信息中除所述下一个呼叫管理器和所述相邻呼叫管理器外的其它呼叫管理器的地址信息。

所述下一个呼叫管理器属于第三网域，所述相邻呼叫管理器属于第四网域，所述第四呼叫建立响应消息中包括所述第三网域和所述第四网域的可用域间链路信息。

可选的，本发明实施例的呼叫处理方法还包括：所述呼叫管理器在向所述下一个呼叫管理器发送第三呼叫建立请求消息之前，所述呼叫管理器还可以根据呼叫业务信息及本地配置的策略信息进行准入控制，判断所述呼叫是否符合本地策略；若是，则允许所述呼叫，执行根据所述全部或部分呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息的后续步骤；否则，拒绝所述呼叫，不执行后续步骤。

在本发明的又一实施例中，在客户侧业务需要经过多个服务侧网络传送的情况下，本实施例的呼叫处理方法通过对呼叫进行分段处理实现各个网域之间的链路选择。该方法具体包括：

呼叫发起方获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的第一呼叫管理器；

所述第一呼叫管理器将所述呼叫建立响应消息传送给所述呼叫发起方。当所述呼叫建立请求消息中包括所述第二呼叫管理器的地址信息时，所述第一呼叫管理器根据所述呼叫建立请求消息中包含的第二呼叫管理器的地址信息将所述呼叫建立请求消息发送到第二呼叫管理器。

其中，所述第一呼叫管理器获取所述第二呼叫管理器的地址信息包括：所述第一呼叫管理器接收网管指定的所述第二呼叫管理器的地址信息；或者，所述第一呼叫管理器接收的呼叫建立请求消息包括所述呼叫发起方的呼叫业务信息及预置的拓朴信息；

所述第一呼叫管理器根据所述呼叫发起方的呼叫业务信息及预置的拓朴信息计算所述第二呼叫管理器的地址信息。

所述第二呼叫管理器的下一个呼叫管理器为靠近呼叫终止方的所述第二呼叫管理器的下一个呼叫管理器，或者所述第二管理器的下一个呼叫管理器为呼叫终止方。

参见图 4 , 是本发明实施例提供的呼叫处理方法的第一场景示意图。本实施例仅以客户侧业务经过三个服务侧网络（假定每个服务侧网络划分为一个网域）传送为例进行说明。其中，每个网域中都配置有拓朴信息，例如节点、域内拓朴信息、各个网域的互连信息等。且每个网域中均设置有呼叫管理器（Call Manager ), 用于对呼叫进行处理。

在本发明实施例中，源节点 R1和目的节点 R2为客户侧设备，域 1、域 2、域 3、域 4联合提供源节点 R1到目的节点 R2的连接业务，其中，域 1、域 3 接入客户侧设备，域 2为域 1提供传送服务，即可以将域 1接入的流量传送至域 3。具体的，建立源节点 R1到目的节点 R2的呼叫过程如下：

( 1 )、源节点 R1 发送呼叫建立请求消息给 R11 , 请求建立到目的节点 R2的呼叫，其中，所述呼叫建立请求消息中携带有业务信息，用于指示该呼叫的源节点、目的节点及所需带宽；

( 2 )、 R11接收上述的呼叫建立请求消息，根据呼叫建立请求消息中的业务信息以及本地配置的策略信息进行准入控制。其中，所述策略信息包括最大带宽信息、域路径信息等。在具体实施当中，可以根据实际需要进行配置本地的策略信息，例如，该策略信息可以包括：允许 R1接入并传送到 R2的最大带宽信息、 R1接入的流量可以经过域 2和域 3传送到 R2的信息。

R11判断所述源节点 R1到目的节点 R2的呼叫是否符合本地配置的策略信息，例如，判断该呼叫所请求的带宽是否超过本地配置的最高值，如果不超过，即符合本地策略，则允许该呼叫，根据所述呼叫的业务信息及预置的拓朴信息，计算获得处理所述呼叫的多个网域的全部呼叫管理器的地址信息，确定源节点 R1到目的节点 R2的域路径；将所述地址信息添加到呼叫建立请求消息中，并发送至处理该呼叫的下一个网域的呼叫管理器（假定域 2 的 R21 ), 所述呼叫建立请求消息携带的地址信息中中指定 R21、 R32处理该呼叫。如果不符合本地配置的策略，则拒绝该呼叫，不进行后续处理。

需要说明的是，在具体实施当中，还可以预先配置各个网域的呼叫管理器的地址信息，在呼叫过程中可以根据所述预先配置的地址信息，直接获得处理呼叫的呼叫管理器的地址。

( 3 )、 R21 接收携带业务信息的呼叫建立请求消息，根据所述业务信息以及本地配置的策略信息进行准入控制，判断所述呼叫是否符合本地策略，如果符合，则允许该呼叫，根据所述呼叫建立请求消息中的地址信息，将呼叫建立请求消息转发到下一个网域的呼叫管理器（假定域 3的 R32 ), 所述呼叫建立请求消息携带的地址信息中指定 R32处理该呼叫；如果不符合本地策略，则拒绝该呼叫；

( 4 )、 R32 接收携带业务信息的呼叫建立请求消息，根据所述业务信息以及本地配置的策略信息进行准入控制，判断所述呼叫是否符合本地策略，如果符合，则允许该呼叫，根据所述呼叫建立请求消息中的地址信息，将呼叫建立请求消息转发到下一个网域的呼叫管理器（ R2 );如果不符合本地策略, 则拒绝该呼叫；

( 5 )、目的节点 R2接受该呼叫，返回呼叫建立响应消息给 R32; 可选的，在向 R32发送呼叫建立响应消息之前，可以根据 R2的本地 U I链路带宽等信息，在所述呼叫建立响应消息中加入 R2的可用 UNI链路信息；

( 6 )、 R32接收 R2返回的呼叫建立响应消息，将所述呼叫建立响应消息转发至 R21 ; 可选的，在向 R21发送呼叫建立响应消息之前，可以根据域 2 和域 3之间的可用链路信息，在呼叫响应消息中加入域 2和域 3之间的可用域间链路信息；

( 7 )、 R21接收 R32返回的呼叫建立响应消息，将所述呼叫建立响应消息转发至 R11 ; 可选的，在向 R11发送呼叫建立响应消息之前，可以根据域 1 和域 2之间的可用链路信息，在呼叫响应消息中加入域 1和域 2之间的可用域间链路信息；

( 8 )、 R11接收 R21返回的呼叫建立响应消息，将所述呼叫建立响应消息转发给 R1 ;

( 9 )、源节点 R1接收 R11返回的呼叫建立响应消息，呼叫建立成功。在呼叫响应过程中，如果节点 R2、 R32、 R21 均在呼叫建立响应消息中添加链路信息，则 R1所接收到的呼叫建立响应消息中包含有远端 R2的可用 U I链路信息、域 2和域 3之间的可用域间链路信息、域 1和域 2之间的可用域间链路信息。

上述实施例是由域 1的呼叫管理器 R11来指定需要处理源节点 R1到目的节点 R2的呼叫的所有网域的呼叫管理器地址。在本发明的另一实施例中，还可以由发起呼叫建立请求消息的源节点 R1来指定需要处理呼叫的全部（或部分）呼叫管理器，下面以图 3 所示的场景示意图进行说明，具体的处理流程下：

( 1 )、 R1 发送呼叫建立请求消息给 R11 , 请求建立到 R2 的呼叫，所述呼叫建立请求消息中指定需要处理该呼叫的呼叫管理器： Rll , R33。其中，所述呼叫建立请求消息中携带有业务信息，用于指示该呼叫的源节点、目的节点及所需带宽；

( 2 )、 R11 根据呼叫建立请求消息中的带宽等流量信息，以及本地配置的策略信息（例如，所述策略信息包括：最大允许 R1 接入并传送到 R2 的带宽； R1 接入的流量可以经过域 2、域 3传送到 R2 )进行准入控制，判断所述呼叫是否符合本地策略，如果符合，则允许该呼叫，根据所述业务信息及配置的拓朴信息，获得处理该呼叫的呼叫管理器的地址信息，在呼叫建立请求消息中指定需要处理该呼叫的呼叫管理器： R12, R21 , R23 , R32, R33 , 并将呼叫建立请求消息转发到下一个呼叫管理器： R12;如果不符合本地策略，则拒绝该呼叫。

( 3 )、 R12 收到呼叫建立请求消息，将呼叫建立请求消息转发到下一个呼叫管理器： R21 , 并在呼叫建立请求消息中指定需要处理该呼叫的呼叫管理器： R21 , R23 , R32, R33。

( 4 )、 R21 根据呼叫建立请求消息中的带宽等流量信息，以及本地配置的策略信息（例如，所述策略信息包括：最大允许 R12接入并传送到域 3的带宽）进行准入控制，如果符合本地策略，则呼叫通过，并将所述呼叫建立请求消息转发到下一个呼叫管理器： R23 , 并在呼叫建立请求消息中指定需要处理该呼叫的呼叫管理器： R23、 R32、 R33; 否则，呼叫被拒绝。 ( 5 )、 R23 收到呼叫建立请求消息，将呼叫建立请求消息转发到下一个呼叫管理器： R32, 并在呼叫建立请求消息中指定需要处理该呼叫的呼叫管理器： R32, R33。

( 6 )、 R32 根据呼叫建立请求消息中的带宽等流量信息，以及本地配置的策略信息（例如，所述策略信息包括：最大允许 R23 接入并传送到 R2 的带宽）进行准入控制，如果符合本域策略，则呼叫通过，在呼叫建立请求消息中指定需要处理该呼叫的呼叫管理器： R33 , 并将所述呼叫建立请求消息转发到下一个呼叫处单元： R33; 否则，呼叫被拒绝。

( 7 )、 R33 收到呼叫建立请求消息，将呼叫建立请求消息转发到呼叫接收方： R2。

( 8 )、呼叫接收方 R2接受该呼叫，返回呼叫建立响应消息给 R33。可选的，在向 R33发送呼叫建立响应消息之前，根据 R2的 U I链路带宽等信息，可以在呼叫建立响应消息中加入可用 UNI链路信息。

( 9 )、 R33接收 R2返回的呼叫建立响应消息，将所述呼叫建立响应消息转发给 R32。

( 10 )、 R32接收 R33返回的呼叫建立响应消息，将所述呼叫建立响应消息转发给 R23。可选的，在向 R23发送呼叫建立响应消息之前，根据域 3和域 2之间的域间链路信息，可以在呼叫建立响应消息中加入可用域间链路信息。

( 11 )、 R23将呼叫建立响应消息发送给 R21。

( 12 )、 R21 接收 R23返回的呼叫建立响应消息，将所述呼叫建立响应消息转发给 R12。可选的，在向 R12发送呼叫建立响应消息之前，根据域 2和域 1 之间的域间链路信息，可以在呼叫建立响应消息中加入可用域间链路信息。

( 13 )、 R12接收 R21返回的呼叫建立响应消息，将呼叫建立响应消息发送给 Rll。 ( 14 )、 Rll接收 R12返回的呼叫建立响应消息，将所述呼叫建立响应消息转发给 Rl。

( 15 )、 R1 接收 Rll返回的呼叫建立响应消息，呼叫建立成功。

在呼叫响应过程中，如果节点 R2、 R32、 R21 均在呼叫建立响应消息中添加链路信息，则 R1所接收到的呼叫建立响应消息中包含有远端 R2的可用 U I链路信息、域 2和域 3之间的可用域间链路信息、域 1和域 2之间的可用域间链路信息。

上述实施例中，步骤（1 ) 中还可以由 R1指定需要处理该呼叫的所有呼叫管理器。即在向 R11发送的呼叫建立请求消息中指定 R11、R12、R21、 R23、 R32、 R33处理该呼叫。

进一步的，呼叫建立成功后，启动连接建立过程，源节点 R1 发起连接建立过程，发送连接建立请求消息到 Rll。如果通过呼叫过程获得了相关可用 U I链路信息及域间链路信息，可以在连接建立请求消息中指定 U I链路及域间链路。该连接过程可以通过 GMPLS RSVP-TE ( RSVP with TE, 带流量工程的资源预留协议）实现，这是本发明技术领域的人员所熟知的，在此不再详述。

本发明实施例提供的呼叫处理方法，在源节点到目的节点的连接经过多个服务侧网络的情况下，能够实现多个网域对呼叫进行分段处理，从而进一步实现各个网域之间的链路选择及准入控制。

参见图 5, 是本发明实施例提供的呼叫处理方法的第三实施例的流程图；本发明实施例在客户侧业务经过多个服务侧网络 (假定每个服务侧网络划分为一个网域）传送的情况下，各个网域对该呼叫进行分段处理。该方法包括如下步骤：

5300、接收源节点发送的携带业务信息的呼叫建立请求消息；

5301、根据所述业务信息和预置的拓朴信息，获得处理所述呼叫的第二网域的呼叫管理器的地址信息； 5302、将所述携带业务信息的呼叫建立请求消息发送至第二网域的呼叫管理器；

5303、接收来自上述第二网域的呼叫建立响应消息，该呼叫建立响应消息包括目的节点的可用链路信息和第二网域的呼叫标识；

5304、将上述呼叫建立响应消息中第二网域的呼叫标识替换为第一网域的呼叫标识，其中，上述第一网域的呼叫标识基于上述业务信息确定；

5305、发送经替换的呼叫建立响应消息至源节点。

具体的，在步骤 S300之后，还包括：根据上述业务信息和预置的域内拓朴信息，确定第一网域的域内链路。

在步骤 S301 获得处理所述呼叫的第二网域的呼叫管理器的地址信息之后，还包括：根据上述业务信息和预置的边界链路信息，确定第一网域与第二网域的域间链路。呼叫建立请求消息经由第一网域的域内链路、第一网域与第二网域的域间链路发送给第二网域的呼叫管理器。

在步骤 S303接收来自第二网域的携带第二网域的呼叫标识的呼叫建立响应消息之后，还包括：记录上述第一网域的呼叫标识和上述第二网域的呼叫标识的对应关系；则在步骤 S305指示呼叫建立成功之后，还包括：接收源节点发送的连接建立请求消息，该连接建立请求消息携带有业务信息和第一网域的呼叫标识；根据上述的第一网域的呼叫标识和第二网域的呼叫标识的对应关系，将连接建立请求消息中第一网域的呼叫标识替换为对应的第二网域的呼叫标识，通过上述第一网域的域内链路、上述第一网域与第二网域的域间链路，发送经替换的连接建立请求消息至第二网域；接收来自第二网域的预留消息，发送该预留消息至源节点。

在上述接收源节点发送的连接建立请求消息之前，还包括：记录上述业务信息和第一网域的呼叫标识的对应关系；此时，在根据上述对应关系将连接建立请求消息中第一网域的呼叫标识替换为对应的第二网域的呼叫标识之前，还包括：判断第一网域的呼叫标识对应的业务信息，是否与连接建立请求消息中携带的业务信息相符，如果是，根据上述的第一网域的呼叫标识和第二网域的呼叫标识的对应关系将连接建立请求消息中第一网域的呼叫标识替换为对应的第二网域的呼叫标识；否则，不执行后续步骤。

可选的，在接收源节点发送的携带业务信息的呼叫建立请求消息之后，还包括：判断呼叫建立请求消息携带的业务信息是否符合预置策略，如果是, 则根据上述业务信息和预置的拓朴信息，获得处理所述呼叫的第二网域的呼叫管理器的地址信息，将所述携带业务信息的呼叫建立请求消息发送至该第二网域的呼叫管理器；否则，不执行后续步骤。

本发明实施例在源节点到目的节点的呼叫经过多个服务侧网络的情况下，能够实现多个网域对源节点到目的节点的呼叫进行分段处理，从而进一步实现各个网域之间的链路选择。

参见图 6 , 是本发明实施例提供的呼叫处理方法的第二场景示意图，仅以源节点到目的节点的业务经过三个网域为例进行说明。

在本发明实施例中，域 1、域 2、域 3联合提供源节点 R1到目的节点 R2 的连接业务，其中，域 1、域 3接入客户侧设备，域 2为域 1提供传送服务，即可以将从域 1中接入的流量传送至域 3。在呼叫建立过程中，可以在呼叫消息中带上策略标识（如合同号），各个域的呼叫管理器根据策略标识对应的策略进行准入控制。具体的，域 1、域 2、域 3互相签订合同，定义如下：

合同 1 ( ID = 1 ): 域 2负责将域 1的最大带宽为 X 的流量传送到域 3 , 域 2向域 1收费 Y1 ;

合同 2 ( ID = 2 ):域 3可以接收从域 2传送过来的最大带宽为 X 的流量，这些流量流向域 3的客户侧设备，域 2向域 3收费 Y2；

进一步的，客户侧设备 R1及 R2 分别接入域 1和域 3 , 客户侧设备 R1 和 R2 属于同一个客户，并分别与域 1、域 3签订合同，如下：

合同 3 ( ID = 3 ): 域 1负责接入客户侧设备 R1 最大带宽为 X 的流量，域 1向客户收费 Y3。合同 4 (ID = 4): 域 3负责传送最大带宽为 X 的流量到客户侧设备 R2, 域 3向客户收费 Y4。

在具体实施当中，客户侧设备 R1 中保存有合同 3 的信息，客户侧设备 R2 保存有合同 4的信息，域 1中的节点 R11 保存有合同 3、合同 1的信息，域 2的节点 R21和 R22 保存有合同 1、合同 2的信息，域 3的节点 R31和 R32保存有合同 2、合同 4的信息。

下面仅以建立客户侧设备 R1到客户侧设备 R2的连接经过三个域为例，对利用分段呼叫处理模式实现准入控制的方法进行说明。呼叫建立过程如下：

( 1 )、 R1 发送呼叫建立请求消息（通用多协议标签交换 GMPLS CALL 中定义的 Notify 消息）到 R11, 其中，上述消息中携带有业务信息（源节点 = R1, 目的节点 =R2; 带宽 =X)及合同信息（ID = 3 );

(2 )、 R11 接收上述呼叫建立请求消息，并对该呼叫进行处理，包括：根据消息中的合同号，查看预存的合同信息，校验呼叫建立请求消息中携带的业务信息是否符合合同规定；若符合，则允许该呼叫，分配对应于上述业务信息的呼叫标识 CalllD (假定 CalllD = 10 ), 并保存该 CalllD以及业务信息的对应关系； R11根据上述业务信息、预置的拓朴信息以及边界链路信息，确定釆用域 2传送该业务到 R2, 并发现 R12-R21 的链路满足带宽需求，则将 R12作为出边界节点。然后发送呼叫建立请求消息到选定的边界节点 R12,其中，呼叫建立请求消息中携带有业务信息、呼叫标识（CalllD = 10)以及合同号（ ID = 1 )。

( 3 )、 R12接收上述呼叫建立请求消息，保存域 1的呼叫标识（ CalllD = 10), 并将该 CalllD从消息中去掉，转发给下一个网域的边界节点 R21;

(4)、 R21 接收上述呼叫建立请求消息，查看预存的合同信息（ID = 1 的合同需要传送到域 3 ), 校验呼叫建立请求消息中携带的业务信息是否符合合同规定；若符合，则允许该呼叫，分配对应于上述业务信息的呼叫标识 CalllD (假定 CallID=20), 并保存该 CalllD以及业务信息的对应关系。 R21根据上述业务信息、预置的拓朴信息以及边界链路信息，确定釆用域 3传送该业务到 R2, 并发现 R23-R31的链路满足带宽需求，则将 R23 作为出边界节点。然后发送呼叫建立请求消息到选定的出边界节点 R23, 其中，呼叫建立请求消息中携带有业务信息、呼叫标识（CallID = 20) 以及合同号（ ID = 2 );

( 5 )、 R23接收上述呼叫建立请求消息，保存域 2的呼叫标识（ CalllD = 20), 并将该 CalllD从消息中去掉，转发给下一个网域的边界节点 R31;

(6)、 R31 接收上述呼叫建立请求消息，查看预存的与域 2签订的合同信息（ID = 2 的合同可以接收从域 2传送过来的最大带宽为 X 的流量，这些流量流向域 3的客户侧设备）以及与客户签订的合同信息（ID = 4的合同），校验呼叫建立请求消息中携带的业务信息是否符合合同规定；若符合，则允许该呼叫，分配对应于上述业务信息的呼叫标识 CalllD (假定 CalllD = 30), 并保存该 CalllD以及业务信息的对应关系。 R31根据上述业务信息及预置的拓朴信息，选择到达客户侧设备 R2的路由，将 R33 作为出边界节点。然后发送呼叫建立请求消息到选定的出边界节点 R33, 其中，呼叫建立请求消息中携带有业务信息、呼叫标识（CallID = 30) 以及合同号（ ID = 4 );

(7)、 R33接收上述呼叫建立请求消息，并转发给目的节点 R2;

(8)、 R2接收上述呼叫建立请求消息，查看预存的合同信息（ID = 4的合同），校验所请求的业务信息是否符合合同规定；若符合，则允许该呼叫，查看本地链路信息，选择满足业务需求的可用链路，并构造携带有目的节点可用链路信息的呼叫建立响应消息（GMPLSCALL 中定义的 Notify 消息），发送给 R33;

(9)、 R33 接收上述呼叫建立响应消息，并转发给 R31;

( 10 )、 R31接收上述呼叫建立响应消息，查看与域 3与域 2之间的链路，选择满足业务需求的可用域间链路，并将上述域间可用链路信息以及域 3 的呼叫标识（ CalllD = 30) 添加到呼叫建立响应消息中，转发给 R23；

( 11)、 R23 接收上述呼叫建立响应消息，保存域 3的呼叫标识（CalllD = 30 ), 并记录呼叫标识 ( CalllD = 30 ) 与域 2 的呼叫标识 ( CalllD = 20) 的对应关系，将上述呼叫建立响应消息转发给 R21；

(12)、 R21 接收上述呼叫建立响应消息，查看域 2与域 1之间的链路，选择满足业务需求的可用域间链路，并将上述域间可用链路信息添加到呼叫建立响应消息中以及将该消息中的呼叫标识（ CalllD = 30 )替换为域 2的呼叫标识（ CalllD = 20 )后，转发给 R12;

(13)、 R12接收上述呼叫建立响应消息，保存域 2的呼叫标识（CalllD = 20 ), 并记录呼叫标识 ( CalllD = 20) 与域 1 的呼叫标识 ( CalllD = 10) 的对应关系，将上述呼叫建立响应消息转发给 R11;

(14)、 R11 接收上述呼叫建立响应消息，将呼叫建立响应消息中的呼叫标识（CallID = 20)替换为域 1的呼叫标识（CallID = 10)后，转发给 R1;

(15)、 R1 接收上述呼叫建立响应消息，消息中包括各网域之间的域间可用链路信息，以及域 1的呼叫标识信息（CalllD = 10), 呼叫建立成功。

在呼叫建立成功后，启动连接建立过程，连接建立的具体过程如下： ( 1 )、 R1根据各域间可用链路信息确定提供连接业务的各个网域的边界节点，并构造携带有业务信息（源节点=11, 目的节点 =R2; 带宽 = X)、呼叫标识信息（CalllD = 10) 以及边界节点信息（Rll, R21, R31 )的路径消息 (资源预留协议 RSVP 中的 Path 消息），发送给 R11;

(2)、 R11 收到 Path 消息，查看消息中的业务信息是否和呼叫标识 (CallID= 10)对应的业务信息相符，如果相符，则计算到下一个边界节点 R21 的路径（R11-R12-R21 ), 并发送 Path 消息到下一个节点 R12, 请求建立连接；

(3)、 R12 收到 Path 消息， R12是出边界节点，根据 Path消息中的呼叫标识（CalllD = 10)与域 2的呼叫标识（ CalllD = 20 ) 的对应关系，将 Path 消息中的呼叫标识 ( CalllD = 10)替换为呼叫标识 (CalllD = 20), 并发送至域 2的入边界节点 R21; (4)、 R21 收到 Path 消息，查看消息中的业务信息是否和呼叫标识 ( CalllD = 20 )对应的业务信息相符，如果相符，则计算到下一个边界节点 R31 的路径（R21-R23-R31 ), 并发送 Path 消息到下一个节点 R23, 请求建立连接；

(5)、 R23 收到 Path 消息， R23是出边界节点，根据 Path消息中的呼叫标识（CallID = 20)与域 3的呼叫标识（ CalllD = 30 ) 的对应关系，将 Path 消息中的呼叫标识 ( CalllD = 20 )替换为呼叫标识 ( CalllD = 30 ), 并发送至域 3的入边界节点 R31;

(6)、 R31 收到 Path 消息，查看消息中的业务信息是否和呼叫标识 (CalllD = 30)对应的业务信息相符，如果相符，则计算到目的节点 R2 的路径（R31-R33-R2), 并发送 Path 消息到下一个节点 R33, 请求建立连接；

(7)、 R33 收到 Path 消息，直接转发给 R2;

(8)、 R2 收到 Path 消息，构造并发送预留消息（RSVP 中的 Resv 消息）给 R33, Resv 消息中携带有呼叫标识（ CalllD = 30 )。

(9)、 R33 收到 Resv 消息，转发给 R31;

(10)、 R31 收到 Resv 消息，转发给 R23;

(11)、 R23 收到 Resv 消息，根据 Resv 消息中的呼叫标识 ( CalllD = 30)与域 2的呼叫标识（CallID = 20) 的对应关系，将 Resv 消息中的呼叫标识（CalllD = 30)替换为呼叫标识 (CalllD = 20), 并发送给 R21;

(12)、 R21 收到 Resv 消息，转发给前一个节点 R12;

(13)、 R12 收到 Resv 消息，根据 Resv 消息中的呼叫标识 ( CalllD = 20)与域 1的呼叫标识（CallID = 10) 的对应关系，将 Resv 消息中的呼叫标识 ( CalllD = 20 )替换为呼叫标识 ( CalllD = 10), 并发送给 R11;

(14)、 R11 收到 Resv 消息，转发给 R1;

(15)、 R1 收到 Resv 消息，连接建立成功。

在具体实现中，还可以在呼叫建立过程的步骤（2)、（4)、 (6) 中，可以分别计算本网域的域内链路、本网域与下游相邻网域的域间链路（若域内链路计算失败，则拒绝呼叫），建立并保存本网域的呼叫标识与域内链路的映射

系，从而在连接建立过程的步骤（2 )、（4 )、 ( 6 ) 中，可以根据呼叫标识查看对应的域内链路、域间链路，而不需要重新计算域内链路、域间链路，确保域内、域间都有资源，保证业务建立成功。

本发明实施例提供的呼叫处理方法，在源节点到目的节点的业务经过多个服务侧网络的情况下，能够实现多个网域对源节点到目的节点的呼叫进行分段处理，从而进一步实现各个网域之间的链路选择及准入控制。

上述仅以源节点到目的节点的连接经过三个网域的情况为例进行说明，本发明的实施方式并不限于此，还可以应用于源节点到目的节点之间存在多个网域的场景。

现有技术的 GMPLS Call中呼叫消息的定义如下：

<Notify message> ： := <Common Header> [ <INTEGRITY> ]

[[ <MESSAGE_ID_ACK> |

<MESSAGE_ID_NACK>]―.]

[ <MESSAGE_ID> ]

<ERROR_SPEC>

<notify session> <SESSION> [ <ADMIN_STATUS> ]

[ <POLICY— DATA> ]

[ <LINK— CAPABILITY ]

[ <SESSION— ATTRIBUTE ]

[ <sender descriptor | <flow descriptor ] <sender descriptor ：: = <SENDER_TEMPLATE> <SENDER_TSPEC>

<flow descriptor ::= see [RFC3473]

其中，现有技术的 <LINK— CAPABILITY>、 <POLICY— DATA>…等对象都不能分段处理。而且 <LINK— CAPABILITY †象默认为呼叫目的节点的链路信息，因此在响应消息中不显式指定其所属的节点。如果要携带域间链路信息，需要在消息中显示指定域间链路所属的节点，以及 U I链路所属的节点。

提供的呼叫处理方法应用于通用多协议标签交换呼叫 GMPLS Call 消息中的第一个实施例如下：

<Notify message> ： := <Common Header> [ <INTEGRITY> ]

[[ <MESSAGE_ID_ACK> |

<MESSAGE_ID_NACK>] ...]

[ <MESSAGE_ID> ]

<ERROR_SPEC>

<notify session> <SESSION> [ <ADMIN_STATUS> ]

[ <SESSION— ATTRIBUTE ]

[ <sender descriptor> | <flow descriptor ]

[ <call manager list> ]

< call manager list >：： = [ < call manager list > ] < call manager >

< call manager > <call manager address> [ <POLICY_DATA>...]

[<node id> <LINK— CAPABILITY ] <sender descriptor ::= see [RFC3473]

<flow descriptor ::= see [RFC3473]

呼叫建立请求消息及呼叫建立响应消息的格式可以参照上述实施例，其中增加 < call manager list >对象，用于实现分段处理域间链路选择、准入控制等功能，即指定每个呼叫管理器需要处理的呼叫内容；呼叫管理器的地址在 <call manager address>中指定。在具体实施当中，可以根据需要指定 <POLICY— 0 了 >等对象用于携带其需要处理的内容；其他的呼叫管理器都需要处理的相关内容，可以在<110^ session^†象中指定。

在响应消息中，在<1^^ — CAPABILITY^前增加一个 <node id>对象，用于指示该链路信息所属的节点 ID。

上述是呼叫协议扩展方法的一种可实施方案，本发明实施例还可以采用其它的呼叫协议扩展方法。下面是本发明实施例提供的呼叫处理方法应用于通用多协议标签交换呼叫 GMPLS Call消息中的第二个实施例。

<Notify message> ： := <Common Header> [ <INTEGRITY> ]

[[ <MESSAGE_ID_ACK> |

<MESS AGE— ID— NACK〉] ...]

[ <MESSAGE_ID> ]

<ERROR_SPEC>

<notify session> ： := <SESSION> [ <ADMIN_STATUS> ]

[<POLICY_DATA>... ] [<LINK_CAPABILITY> ]

[ <SESSION— ATTRIBUTE ]

[<Call_ERO> ]

[ <sender descriptor | <flow descriptor ] <sender descriptor ::= see [RFC3473]

<flow descriptor ::= see [RFC3473]

在本实施例中， <Call— ERO>携带各呼叫处理器地址。 <POLICY— DATA> 为各网域的统一策略（例如负责同一条客户侧业务的传送），不需要在各个呼叫处理器地址后面单独携带该策略信息。

下面是本发明实施例提供的呼叫处理方法应用于通用多协议标签交换呼叫 GMPLS Call消息中的第三个实施例。

<Notify message> ： := <Common Header> [ <INTEGRITY> ]

[[ <MESSAGE_ID_ACK> |

<MESSAGE_ID_NACK>] ...]

[ <MESSAGE_ID> ]

<ERROR_SPEC>

<notify session> ： := <SESSION> [ <ADMIN_STATUS> ]

[ <SESSION— ATTRIBUTE ]

[ <sender descriptor | <flow descriptor ]

[ <call manager list> ]

< call manager list > ::= [ < call manager list > ] < call manager >

< call manager > ::= <call manager address> [ <POLIC Y D ATA> ... ]

[<node id> <LINK— CAPABILITY ]

<sender descriptor ::= see [RFC3473] <flow descriptor ::= see [RFC3473]

上述增加的 < call manager list >对象，用于实现分段处理域间链路、准入控制等功能，该对象的内容就是一个呼叫管理器的可达地址。在 <LINK— CAPABILITY>前增加一个 <node id>对象，用于指示该链路所属的节点。

参见图 7 , 是本发明实施例提供的节点的结构示意图，所述节点包括：第一地址获取单元 701、第一请求单元 702及第一响应接收单元 703 , 其中：第一地址获取单元 701 ,用于获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的呼叫管理器；

第一请求单元 702 ,用于根据所述全部或部分呼叫管理器的地址信息中的所述相邻的呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息；

第一响应接收单元 703 ,用于接收来自所述相邻的呼叫管理器的第一呼叫建立响应消息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器针对所述第一呼叫建立请求消息发出。

参见图 8, 是本发明实施例提供的呼叫管理器的结构示意图，所述呼叫管理器，包括：第二地址获取单元 801、第二请求单元 802及第二响应接收单元 803 , 其中：

第二地址获取单元 801 ,用于获得处理呼叫的网域中该呼叫管理器和呼叫接收节点之间的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与该呼叫管理器相邻的下一个呼叫管理器；

第二请求单元 802 ,用于根据所述全部或部分呼叫管理器的地址信息中的所述下一个呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息，所述第三呼叫建立请求消息包括所述全部或部分呼叫管理器的地址信息；第二响应接收单元 803 ,用于接收来自所述下一个呼叫管理器的第三呼叫建立响应消息，所述第三呼叫建立响应消息由所述下一个呼叫管理器针对所述第三呼叫建立请求消息发出。

参见图 9, 是本发明实施例提供的呼叫处理系统的结构示意图，包括源节点 901、目的节点 902以及多个呼叫管理器 903 , 其中：

源节点 901 , 用于发送携带业务信息的呼叫建立请求消息，请求建立源节点 901到目的节点 903的呼叫；

呼叫管理器 903 ,用于接收源节点 901发送的携带业务信息的呼叫建立请求消息；获得处理所述源节点 901到目的节点 903的呼叫的多个网域的呼叫管理器的地址信息，根据所述地址信息确定处理所述呼叫的呼叫管理器，将呼叫建立请求消息转发至所述呼叫管理器；接收来自所述呼叫管理的呼叫建立响应消息，将所述呼叫建立响应消息发送至源节点 901。

具体的，呼叫管理器 903包括：消息收发单元 9031和处理单元 9032; 其中：

消息收发单元 9031 , 用于接收源节点 901发送的携带业务信息的呼叫建立请求消息；

处理单元 9032 , 用于获得处理源节点 901到目的节点 903的呼叫的多个网域的呼叫管理器的地址信息，根据所述地址信息确定处理所述呼叫的呼叫管理器；

则所述消息收发单元 9031还用于将呼叫建立请求消息转发至所述处理单元 9032所确定的呼叫管理器；接收来自所述呼叫管理器的呼叫建立响应消息，发送所述呼叫建立响应消息至源节点 901 ;

在本发明提供的呼叫管理器的一个实施例中，该呼叫管理器的处理单元具体包括：域间链路确定模块、准入控制模块、域内路径确定模块、呼叫标识配置模块和替换模块，其中：

域间链路确定模块，用于确定第一网域与第二网域之间的可用域间链路信息，将所述可用域间链路信息加入呼叫建立响应消息中；

准入控制模块，用于根据呼叫发起方的呼叫业务信息以及本地配置的策略信息，判断所述呼叫是否符合本地策略；如果是，则允许所述呼叫。

域内链路确定模块，用于根据所述呼叫建立请求消息中的业务信息以及预置的域内拓朴信息，确定所述第一网域的域内链路。

呼叫标识配置模块，用于根据所述呼叫建立请求消息携带的业务信息，配置第一网域的呼叫标识；

替换模块，用于将所述呼叫建立响应消息中的第二网域的呼叫标识替换为第一网域的呼叫标识。

本发明实施例提供的呼叫处理方法、系统及装置，在客户侧业务需要经过多个服务侧网络传送的情况下，通过分段呼叫处理实现各个网域之间的链路选择及准入控制。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（ Read-Only Memory, ROM )或随机存己忆体 ( Random Access Memory, RAM )等。

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

Claims

权利要求书

1、一种呼叫处理方法，其特征在于，包括：

呼叫发起方获得处理呼叫的网域中的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与所述呼叫发起方相邻的处理所述呼叫的呼叫管理器；

所述呼叫发起方根据所述全部或部分呼叫管理器的地址信息中的所述相邻呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息；所述呼叫发起方接收来自所述相邻的呼叫管理器的第一呼叫建立响应消息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器针对所述第一呼叫建立请求消息发出。

2、如权利要求 1所述的呼叫处理方法，其特征在于，所述第一呼叫请求消息中包括所述全部或部分呼叫管理器的地址信息，所述第一呼叫建立响应消息由所述相邻的呼叫管理器在向该相邻的呼叫管理器的下一个呼叫管理器发送第二呼叫建立请求消息，并从该下一个呼叫管理器接收到第二呼叫建立响应消息后发送；所述第二呼叫建立响应消息由所述下一个呼叫管理器针对所述第二呼叫建立请求消息发出；

所述第二呼叫请求消息中包括所述下一个呼叫管理器的地址信息，还包括所述全部或部分呼叫管理器的地址信息中除所述相邻的呼叫管理器和所述下一个呼叫管理器外的其它呼叫管理器的地址信息。

3、如权利要求 2所述的呼叫处理方法，其特征在于，所述相邻的呼叫管理器属于第一网域，所述下一个呼叫管理器属于第二网域，所述第二响应消息中包括所述第一网域和所述第二网域的可用域间链路信息。

4、如权利要求 1所述的呼叫处理方法，其特征在于，所述第一呼叫建立响应消息中包括处理所述呼叫的网域之间的可用域间链路信息。

5、如权利要求 1 - 4任一项所述的呼叫处理方法，其特征在于，所述全部或部分呼叫管理器的地址信息是预先配置的；或所述全部或部分呼叫管理器的地址信息是所述呼叫发起放根据呼叫发起方的呼叫业务信息及预置的拓朴信息计算获得。

6、一种呼叫处理方法，其特征在于，包括：

呼叫管理器获得处理呼叫的网域中该呼叫管理器和呼叫接收节点之间的全部或部分呼叫管理器的地址信息，所述全部或部分呼叫管理器包括与该呼叫管理器相邻的下一个呼叫管理器；

所述呼叫管理器根据所述全部或部分呼叫管理器的地址信息中的所述下一个呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息，所述第三呼叫建立请求消息包括所述全部或部分呼叫管理器的地址信息；所述呼叫管理器接收来自所述下一个呼叫管理器的第三呼叫建立响应消息，所述第三呼叫建立响应消息由所述下一个呼叫管理器针对所述第三呼叫建立请求消息发出。

7、如权利要求 6所述的呼叫处理方法，其特征在于，所述呼叫管理器在向所述下一个呼叫管理器发送第三呼叫建立请求消息之前还包括：所述呼叫管理器还根据呼叫业务信息及本地配置的策略信息进行准入控制，判断所述呼叫是否符合本地策略；若是，则允许所述呼叫，执行根据所述全部或部分呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息的后续步骤；否则，拒绝所述呼叫，不执行后续步骤。

8、如权利要求 6所述的呼叫处理方法，其特征在于, 所述第三呼叫建立响应消息由所述下一个呼叫管理器在向该下一个呼叫管理器的靠近呼叫终止方的相邻呼叫管理器发送第四呼叫建立请求消息，并从该相邻呼叫管理器接收到第四呼叫建立响应消息后发送；所述第三呼叫请求消息中包括所述相邻呼叫管理器的地址信息，还包括所述全部或部分呼叫管理器的地址信息中除所述下一个呼叫管理器和所述相邻呼叫管理器外的其它呼叫管理器的地址信息。

9、如权利要求 8所述的呼叫处理方法，其特征在于，所述下一个呼叫管理器属于第三网域，所述相邻呼叫管理器属于第四网域，所述第四呼叫建立响应消息中包括所述第三网域和所述第四网域的可用域间链路信息。

10、一种呼叫处理方法，其特征在于，包括：

接收呼叫发起节点发送的携带业务信息的呼叫建立请求消息；

将所述携带业务信息的呼叫建立请求消息发送至第二网域的呼叫管理器；接收来自所述第二网域的呼叫管理器的呼叫建立响应消息，所述呼叫建立响应消息包括呼叫接收节点的可用链路信息和第二网域的呼叫标识，所述第二网域的呼叫标识基于所述业务信息确定；

将所述呼叫建立响应消息中第二网域的呼叫标识替换为第一网域的呼叫标识，其中，所述第一网域的呼叫标识基于所述业务信息确定，所述第二网域接入所述第一网域的信息流；

发送经替换的呼叫建立响应消息至所述呼叫发起节点。

11、如权利要求 10所述的呼叫处理方法，其特征在于，在接收来自所述第二网域的呼叫管理器的呼叫建立响应消息之后，还包括：记录所述第一网域的呼叫标识和所述第二网域的呼叫标识的对应关系；

则在所述发送经替换的呼叫建立响应消息至呼叫发起方之后，还包括：接收所述呼叫发起方发送的连接建立请求消息，所述连接建立请求消息携带有所述业务信息和所述第一网域的呼叫标识；

根据所述第一网域的呼叫标识和第二网域的呼叫标识的对应关系，将所述连接建立请求消息中第一网域的呼叫标识替换为第二网域的呼叫标识，发送经替换的连接建立请求消息至所述第二网域；

接收来自所述第二网域的预留消息，发送所述预留消息至所述呼叫发起方。

12、如权利要求 11所述的呼叫处理方法，其特征在于，在所述接收所述呼叫发起方发送的连接建立请求消息之前，还包括：

记录所述业务信息和所述第一网域的呼叫标识的对应关系；

则在所述接收呼叫发起节点发送的连接建立请求消息之后，还包括：判断所述呼叫建立请求消息中的第一网域的呼叫标识对应的业务信息，是否与所述连接建立请求消息中携带的业务信息相符，如果是，则根据所述第一网域的呼叫标识和第二网域的呼叫标识的对应关系，将所述连接建立请求消息中第一网域的呼叫标识替换为第二网域的呼叫标识，发送经替换的连接建立请求消息至所述第二网域。

13、一种呼叫处理方法，其特征在于，包括：

所述呼叫发起方根据所述全部或部分呼叫管理器地址信息中的所述第一呼叫管理器的地址信息向所述第一呼叫管理器发送呼叫建立请求消息；所述第一呼叫建立请求消息中包括所述全部或部分呼叫管理器的地址信息；所述第一呼叫管理器接收所述呼叫建立请求消息，删除所述第一呼叫建立请求消息中的第一呼叫管理器的地址信息，判断该呼叫建立请求消息中是否包括第二呼叫管理器的地址信息，所述第二呼叫管理器为与所述第一呼叫管理器相邻的靠近呼叫终止方的呼叫管理器；

所述第一呼叫管理器将所述呼叫建立响应消息传送给所述呼叫发起方。

14、如权利要求 13所述的呼叫处理方法，其特征在于，还包括：当所述呼叫建立请求消息中包括所述第二呼叫管理器的地址信息时，所述第一呼叫管理器根据所述呼叫建立请求消息中包含的第二呼叫管理器的地址信息将所述呼叫建立请求消息发送到第二呼叫管理器。

15、如权利要求 13所述的呼叫处理方法，其特征在于，所述第一呼叫管理器获取所述第二呼叫管理器的地址信息包括：

所述第一呼叫管理器接收网管指定的所述第二呼叫管理器的地址信息；或者，所述第一呼叫管理器接收的呼叫建立请求消息包括所述呼叫发起方的呼叫业务信息及预置的拓朴信息；

16、如权利要求 13所述的呼叫处理方法，其特征在于，所述第二呼叫管理器的下一个呼叫管理器为靠近呼叫终止方的所述第二呼叫管理器的下一个呼叫管理器，或者所述第二管理器的下一个呼叫管理器为呼叫终止方。

17、一种节点，包括：

第一请求单元，用于根据所述全部或部分呼叫管理器的地址信息中的所述相邻的呼叫管理器的地址信息向所述相邻的呼叫管理器发送第一呼叫建立请求消息；

18、一种呼叫管理器，其特征在于，包括：

第二请求单元，用于根据所述全部或部分呼叫管理器的地址信息中的所述下一个呼叫管理器的地址信息向所述下一个呼叫管理器发送第三呼叫建立请求消息，所述第三呼叫建立请求消息包括所述全部或部分呼叫管理器的地址信息；第二响应接收单元，用于接收来自所述下一个呼叫管理器的第三呼叫建立响应消息，所述第三呼叫建立响应消息由所述下一个呼叫管理器针对所述第三呼叫建立请求消息发出。

19、一种呼叫管理器，其特征在于，包括：消息收发单元和处理单元；所述消息收发单元，用于接收呼叫发起方发送的携带业务信息的呼叫建立请求消息；

所述处理单元，用于获得处理呼叫发起方的呼叫的多个网域的呼叫管理器的地址信息，根据所述地址信息确定处理所述呼叫的呼叫管理器；

20、一种呼叫处理系统，其特征在于，包括：呼叫发起节点、呼叫接收节节点以及多个呼叫管理器；