CN100596124C - 实现业务互通的方法及系统 - Google Patents

Abstract

本发明涉及一种实现业务互通的方法及系统。本发明应用于包含分组域的应用服务器，以及与传统电路域通信的互通网元的系统中，在具体实现过程中分组域的应用服务器向传统电路域网络之间交互的信息以预定格式的消息承载交互，从而使得分组域网络与传统电路域网络之间均可以解析获得对端发来的信息，实现两网络之间业务的互通。本发明使得仿真业务AS(即分组域应用服务器)可以准确判断出对端是否为传统电路域网络，从而决定消息的发送方式，并扩展使得预定格式的消息可以在MGCF(即互通网元)和仿真业务AS之间直接或通过SIP-I代理网元透明传送，避免了因某些网元对SIP-I的不支持等原因而导致业务互通失败，有效提高了业务互通的成功率。

Description

实现业务互通的方法及系统

技术领域

本发明涉及网络通信技术领域，尤其涉及传统电路域业务与分组域业务互通技术领域。

背景技术

目前，随着分组技术的不断成熟，基于电路交换的传统电信网络正在向着基于分组交换的宽带电信网发展，而使用SIP(会话初始协议)作为分组电信核心网的呼叫控制信令则是当前的技术发展趋势之一，例如，当前的NGN(Next Genteration Network，下一代网络)便采用3GPP标准组织定义的IMS(IP多媒体子系统)网络架构作为NGN的核心网。

在这种分组电信网络中，分组终端SIP终端将逐步取代传统的终端话机。其中，在NGN中向SIP终端用户提供的具有传统业务特征的业务统称为PSTN(公共电话网)/ISDN(综合业务数字网)simulation services(仿真业务)，如MCID(恶意呼叫识别)业务等，MCID业务可以使用户识别出一个呼入来话的身份，从而可以作为确定是否为恶意呼叫的依据。

目前，用户使用MCID业务可以有两种签约方式：永久签约(permanentsupervision)和临时签约(case by case supervision)方式，其中，对于后一种签约方式，用户可以在其终端设备上发起对MCID业务的订阅，向MCID AS(处理MCID业务的应用服务器)发送SIP SUBSCRIBE(SIP订阅)消息，消息中携带扩展的事件包“mcid-request-info(MCID请求信息)”，MCID AS则返回SIP NOTIFY(SIP通知)消息，消息中携带呼入来话身份标识等相关信息。

在IMS标准定义的MGCF(媒体网关控制功能)上，目前只支持基本呼叫信令的互通映射，无法对开展MCID业务过程中涉及的SIP SUBSCRIBE消息和SIP NOTIFY消息进行处理，因而，在MGCF上对如MCID等补充业务互通的则尚无法支持。所述的MGCF的处理过程只包括呼叫发起、呼叫释放、呼叫相关请求三个呼叫处理过程，即MGCF还不支持基本呼叫信令之外的如SIP SUBSCRIBE、SIP NOTIFY、SIP MESSAGE(SIP即时消息)、SIP REFER(SIP参考消息)等消息的信令互通映射，而这些SIP消息往往是仿真业务中所必须的。

也就是说，当前仿真业务和PSTN/ISDN/PLMN等传统电路域网络(以下简称“传统电路域网络”)的补充业务互通时，存在着部分业务应用信息不能在以IMS为核心网的分组域和传统电路域间相互映射的问题，而导致在出现互通时业务无法使用的情况。所述的分组域和传统电路域间的业务互通是指该业务在这两个网络中都需要被处理，也即需要两个网络配合完成。

为了解决上述问题，则业界提出了要求MGCF和处理仿真业务AS(即仿真业务的AS)均支持SIP-I(SIP with encapsulated ISUP，封装ISUP的SIP)，这是一种将ISUP信令封装在消息体内的SIP消息，以前述的MCID业务互通为例，可以将ISUP IDR(ISDN用户部分识别请求)/IRS(识别响应)消息直接封装在SIP INFO(SIP信息)消息体内传递，MGCF和MCIDAS从SIP INFO消息体内提取并解析ISUP IDR/IRS消息，从而完成MCID业务的互通。

由于采用于上述方案解决业务互通的问题，因而，导致在相应的仿真业务处理过程中仍然存在如下两方面的问题，具体如下：

(1)仿真业务AS在业务处理过程中，当需要向对端(主叫方或被叫方)发送一个包含仿真业务应用相关信息的消息时，无法确定是发送普通的SIP消息还是SIP-I消息，仍以MCID业务为例，MCID AS收到携带MCID业务定义事件包的SIP SUBSCRIBE消息，无法确定是继续向主叫侧发送SIP SUBSCRIBE消息，还是向主叫侧发送封装了ISUP IDR消息的SIP INFO消息，即仿真业务AS无法判别对端是IMS网络还是传统电路域网络，从而可能会引发错误的业务流程处理而导致业务互通失败。

(2)在SIP标准中，INFO消息作为一个会话相关的消息，用来传递会话中的信令信息，其信令路径为呼叫建立的信令路径。由于一次IMS会话中，可能会有多个处理不同业务的AS被触发，因此，若仿真业务AS不是第一个或最后一个被触发，即仿真业务AS的前后有处理其它业务的、且不支持SIP-I消息的AS(如预付费业务AS被触发)时，则AS收到SIP-I消息，将可能会返回415Unsupported Media Type(不支持的媒体类型)等失败响应码，从而导致仿真业务AS无法收到SIP-I消息而使业务互通失败。

发明内容

本发明的目的是提供一种实现业务互通的方法及系统，可以令分组域网络与传统电路域网络之间可以通过预定格式的消息进行信息交互，从而实现两网络之间的业务互通。

本发明的目的是通过以下技术方案实现的：

本发明提供了一种实现业务互通的方法，所述方法应用于包含分组域的应用服务器，以及与传统电路域通信的互通网元的系统中，其中：

当分组域的应用服务器通过与对端交互的消息确定对端无法处理分组域的基本消息(例如SIP消息等)时，则确定为由分组域的应用服务器向传统电路域发送信息，相应的处理包括：

A、分组域的应用服务器将需要发送给传统电路域的信息封装或转译为互通网元可以解析的预定格式的消息，并发送；

B、互通网元接收到所述预定格式的消息后，解析获得传统电路域的信息，并向传统电路域发送；

当传统电路域无法将待发送的信息转译为分组域的基本消息时，则对于由传统电路域向分组域的应用服务器发送信息的处理包括：

C、传统电路域向互通网元发送需要发送给分组域的信息，互通网元将所述需要发送给分组域的信息封装或转译为所述预定格式的消息，并向分组域发送；

D、分组域的应用服务器接收到所述预定格式的消息后，解析获得分组域的信息，并发送。

本发明中，所述的步骤A包括：

A1、分组域的应用服务器将需要发送给传统电路域的信息，封装于目的地址为互通网元的地址信息的封装有综合业务数字网用户部分ISUP的会话初始协议SIP-I消息中，或者转译为扩展标记语言XML描述的目的地址为互通网元的地址信息的超文本传输协议HTTP消息发送给互通网元；

或者，

A2、分组域的应用服务器将需要发送给传统电路域的信息转译为XML描述携带于超文本传输协议HTTP消息中发送给寻址网元，由寻址网元确定对端互通网元的地址信息，并将所述HTTP消息发送给所述互通网元；

或者，

A3、分组域的应用服务器将需要发送给传统电路域的信息封装于SIP-I消息中并通过已经建立的呼叫信令路径发送给互通网元；

所述的步骤C包括：

C1、互通网元将需要发送给分组域的信息封装于目的地址为分组域的应用服务器的地址信息的SIP-I消息中、或转译为XML描述携带于目的地址为分组域的应用服务器的地址信息的超文本传输协议HTTP消息中发送给相应的应用服务器；

或者，

C2、互通网元将需要发送给分组域的信息转译为XML描述携带于HTTP消息中发送给寻址网元，由寻址网元确定对端应用服务器的地址信息，并将所述HTTP消息发送给所述的应用服务器；

或者，

C3、互通网元将需要发送给分组域的信息封装于SIP-I消息中，并通过已经建立的呼叫信令路径发送给相应的应用服务器。

所述步骤D进一步包括：

所述的应用服务器根据收到的呼叫信令中包含的头域中的信息确定对端的互通网元的域名地址信息；

所述步骤B进一步包括：

所述的互通网元根据收到的呼叫信令中包含的头域中的信息确定对端的应用服务器的域名地址信息；或者，互通网元通过预先配置的信息获取应用服务器的域名地址；或者，互通网元根据收到的来自应用服务器的消息确定应用服务器的域名地址。

寻址网元中配置有以预定的信息索引的应用服务器及互通网元的地址信息，当寻址网元接收到包含预定的信息的消息时，则以所述预定的信息为索引查找对应的地址信息，并作为消息接收端的地址信息。

寻址网元设置于互通网元或应用服务器中，或独立设置于网络中。

XML描述包括以扩展标记语言配置访问协议XCAP或简单对象访问协议SOAP描述。

所述的方法还包括：

E、分组域的应用服务器在业务处理过程中，当需要向对端发送信息时，若确定接收端为所述的互通网元，则执行步骤A。

所述的确定接收端为所述的互通网元的处理包括：

根据对端发送来的消息中承载的信息确定对端能够支持所述预定格式的消息，则确定对端为互通网元；或者，分组域的应用服务器根据收到的SIP消息中包含的路径信息确定对端是否为互通网元。

所述的路径信息包括：SIP消息中的头域承载的地址信息和/或用户标识信息。

所述的方法还包括：

分组域的应用服务器在业务处理过程中，当需要向对端发送信息时，若确定接收端为互通网元，并进一步确定所述互通网元无法处理包含以SIP头域表述的发送信息的SIP消息，则执行步骤A。

确定互通网元无法处理分组域的消息的处理包括：

分组域的应用服务器向互通网元发送所述SIP消息，当互通网元返回对所述SIP消息不支持的失败响应消息时，则确定互通网元无法处理所述SIP消息。

所述的分组域的应用服务器和互通网元之间传递的信息包括：

恶意呼叫识别MCID业务信息或消息等待指示MWI业务信息。

本发明还提供了一种应用服务器，用于与互通网元进行信息交互，实现分组域网络与传统电路域网络的业务互通，包括：

第一消息发送处理模块：用于将由分组域网络向传统电路域网络发送的信息构造为互通网元可以识别的预定格式的消息，并将所述预定格式的消息向所述互通网元发送；

第一消息接收模块：接收并解析互通网元发来的预定格式的消息，获得由传统电路域发来的信息。

所述的第一消息发送处理模块包括：

第一消息构造模块，用于构造互通网元可以识别的SIP-I消息或HTTP消息，消息中的目的地址为对端互通网元的地址信息；以及第一消息发送模块，用于将第一消息构造模块构造的消息向所述的互通网元发送；

或者，

第二消息构造模块，用于构造互通网元可以识别的SIP-I消息；以及第二消息发送模块，用于将第二消息构造模块构造的消息通过已经建立的呼叫信令路径向所述的互通网元发送；

或者，

第三消息构造模块，用于构造互通网元可以识别的HTTP消息；以及第三消息发送模块，用于将第三消息构造模块构造的消息发送给可以与互通网元通信的中间寻址网元。

本发明还提供了一种互通网元，用于与应用服务器进行信息交互，实现分组域网络与传统电路域网络的业务互通，其特征在于，包括：

第二消息发送处理模块：用于将传统电路域需要向分组域发送的信息构造为与应用服务器间交互的预定格式的消息，并将所述预定格式的消息向所述应用服务器发送；

第二消息接收模块：接收并解析应用服务器发来的预定格式的消息，获得由分组域发来的信息。

所述的第二消息发送处理模块包括：

第四消息构造模块，用于构造向应用服务器发送的的SIP-I消息或HTTP消息，消息中的目的地址为对端应用服务器的地址信息；以及第四消息发送模块，用于将第四消息构造模块构造的消息向所述的应用服务器发送；

或者，

第五消息构造模块，用于构造向应用服务器发送的SIP-I消息；以及第五消息发送模块，用于将第五消息构造模块构造的消息通过已经建立的呼叫信令路径向所述的应用服务器发送；

或者，

第六消息构造模块，用于构造向应用服务器发送的HTTP消息；以及第六消息发送模块，用于将第六消息构造模块构造的消息发送给可以与应用服务器通信的中间寻址网元。

本发明还提供了一种实现业务互通的系统，包括：

应用服务器，设置于分组域网络中，用于构造互通网元可以识别的预定格式的消息，并发送给互通网元，同时，接收并解析互通网元发来的预定格式的消息，获得传统电路域发来的信息；

互通网元，连接设置于分组域网络与传统电路域网络之间，用于构造所述预定格式的消息，并发送给所述应用服务器，同时，接收并解析应用服务器发来的预定格式的消息，获得分组域网络发送给传统电路域的信息，并发送给传统电路域网络。

所述的系统还包括：

寻址网元，连接设置于应用服务器与互通网元之间，用于应用服务器与互通网元之间交互有消息寻址。

由上述本发明提供的技术方案可以看出，本发明使得仿真业务AS(即分组域应用服务器)可以准确判断出对端是否为传统电路域网络，从而决定是否发送SIP-I消息，并扩展SIP INFO的会话外路由方式以使SIP-I消息可以在MGCF(即互通网元)和仿真业务AS之间直接或通过SIP-I代理网元透明传送，从而使业务互通可以正常进行，避免了因某些网元对SIP-I的不支持等原因而导致业务互通失败，有效提高了业务互通的成功率。

而且，本发明中，仿真业务AS和MGCF之间的消息交互还可以通过专门设置的中间寻址网元实现，从而使得本发明的应用更为广泛、灵活。

附图说明

图1为本发明所述的方法的实现方式流程图一；

图2为本发明所述的方法的实现方式流程图二；

图3为本发明所述的方法的实现方式流程图三；

图4为本发明所述的方法的实现方式流程图四；

图5为本发明所述的方法的实现方式流程图五；

图6为本发明所述的方法的实现方式流程图六；

图7为本发明所述系统的结构示意图；

图8为本发明所述系统的具体实现结构示意图。

具体实施方式

本发明将提出一种仿真业务在IMS网络和传统电路域网络互通时的实现方案，该方案主要是将需要向对端网络发送的信息构造(即封装或转译)为预定格式的对端可以识别的消息，并发送给对端。具体一点讲，本发明还可以使仿真业务AS准确判断出对端网络是IMS网络和传统电路域网络，从而决定是否使用封装ISUP信令的SIP-I消息等预定格式的消息，并扩展SIP INFO的会话外路由方式以使SIP-I消息可以在MGCF和仿真业务AS之间直接或通过SIP-I代理网元透明传送。其中，SIP-I代理网元是指该网元对SIP-I消息中的ISUP信令不解析，透明传送SIP-I消息。

本发明提供了分组域和传统电路域业务互通的实现方案，该方案主要是针对分组域中的应用服务器(如仿真业务AS)和互通网元(如MGCF)的改进实现，即通过改进使得分组域和传统电路域业务能够实现互通。互通的业务包括MCID业务、MWI业务等。

(一)基于分组域中的应用服务器的改进的目的是使得由分组域的应用服务器通过互通网元向传统电路域发送的消息可以顺利传递，具体改进为：

当分组域中的应用服务器在处理所述业务时，需要向对端发送包含第一格式业务信息的SIP第一消息，具体的处理方式为：若对端为不能处理所述SIP第一消息的互通网元，则应用服务器需要向互通网元发送包含所述第二格式业务信息的第二消息，即预定格式的消息，例如，应用服务器将需要发送给MGCF(即互通网元)不能处理的SIPSUBSCRIBE/NOTIFY等消息转译成封装了ISUP消息的SIP-I消息向MGCF发送；否则，应用服务器只需要直接向对端发送该SIP第一消息即可；

应用服务器要向互通网元发送所述第二消息的方式具体可以为以下任一种实现方式：

(1)应用服务器根据收到的呼叫信令中包含的Contact头域，获取互通网元的域名地址，并向其直接发送所述第二消息；

(2)应用服务器按已经建立的呼叫信令路径将所述第二消息发送至互通网元；

(3)应用服务器将所述第二消息发送一寻址网元，寻址网元根据所述第二消息中包含的所述业务第二信息匹配得到一个互通网元，寻址网元将所述第二消息发送至所述互通网元；

其中，应用服务器判断对端是不能处理所述SIP第一消息的互通网元的实现方式可以为以下一种或任意几种实现方式的组合：

1、应用服务器根据呼叫信令中包含的路径信息来判断对端是否为互通网元，即是否为传统电路域网络，而且，应用服务器还需要判断互通网元是否不能处理所述SIP第一消息；

其中，应用服务器根据呼叫信令中包含的路径信息来判断对端是互通网元的方式可以为下面的一种或两种方式的组合：

(11)应用服务器根据收到的呼叫信令中包含的Contact(联系)头域，判断是否为互通网元域名地址，以判断对端是否为互通网元；

具体为：

仿真业务AS根据收到的来话呼入INVITE(邀请)消息或呼出INVITE消息的SIP响应码中携带的Contact头域，判断对端是否为MGCF域名地址，以判断对端是否为传统电路域网络；

(12)应用服务器根据收到的呼叫信令中包含的P-Asserted-Identity(声明标识)头域，判断对端用户是否为传统电路域用户，以判断对端是否为互通网元。

2、应用服务器向对端发送所述SIP第一消息，若收到表示对该消息不支持的SIP响应码，则确定对端是不能处理所述SIP第一消息的互通网元；

例如，仿真业务AS向对端发送SIP SUBSCRIBE/NOTIFY等消息，如果收到对该消息不支持的失败响应码，仿真业务AS确定对端MGCF不能处理SIP消息；

3、应用服务器根据收到的呼叫信令中包含的SIP-I支持指示信息，判断对端是互通网元，且应用服务器判断互通网元不能处理所述SIP第一消息。

在IMS网络中最多只有MGCF网元和仿真业务AS可以在SIP消息中通过Accept(接受)头域添加表示支持ISUP信令解析的SIP-I支持指示信息的情况下，当仿真业务AS根据收到的来话呼入INVITE消息或呼出INVITE消息的SIP响应码中携带的Accept头域指示支持SIP-I，则仿真业务AS可以确认对端是MGCF，即为传统电路域网络；

(二)基于互通网元的改进的目的是使得由传统电路域通过互通网元向分组域的应用服务器发送的消息可在顺利传递，具体的改进为：

在业务应用过程中，互通网元收到来自传统电路域的包含第一格式业务信息的ISUP第一消息，具体的处理方式为：若互通网元不能将该ISUP第一消息转译成合适的SIP消息，则向分组域中的应用服务器发送包含第二格式业务信息的第二消息，即预定格式的消息；否则，互通网元向分组域发送所述SIP消息；

互通网元要向应用服务器发送所述第二消息的方式具体为：

互通网元根据收到的呼叫信令中包含的Record-Route头域等，获取应用服务器的域名地址，并向其直接发送所述第二消息；或者，互通网元通过事先的数据配置获取应用服务器域名地址，并向其直接发送所述第二消息；或者，互通网元根据收到的来自应用服务器的SIP-I消息中获取应用服务器域名地址，并向其直接发送所述第二消息；

所述的互通网元也可以仍按已经建立的呼叫信令路径将所述第二消息发送至S-CSCF，并由后者触发至应用服务器；或者，所述的互通网元还可以将所述第二消息发送给寻址网元，寻址网元根据所述第二消息中包含的第二格式业务信息匹配得到一个应用服务器，寻址网元将所述第二消息发送至所述应用服务器；其中，寻址网元将所述业务第二信息和预置的配置数据匹配得到应用服务器的域名地址，该预置的配置数据可以是一种普通的表格形式，也可以是一种以某种语法如XML等描述的过滤规则。

在上述针对应用服务器及互通网元的改进中，所述的包含第二格式业务信息的第二消息分别可以为以下任一种：

1、携带了以消息体内封装的ISUP信令描述的第二格式业务信息的SIP-I消息；

2、携带了以XML(扩展标记语言)描述的第二格式业务信息HTTP消息，所述XML描述可以是XCAP(扩展标记语言配置访问协议)或SOAP(简单对象访问协议)或其它定义格式。

下面将对本发明中作为互通网元MGCF和作为应用服务器的仿真业务AS之间SIP-I消息的路由方式进行说明：

(1)MGCF和仿真业务AS可以获取对方的域名地址，进而使得两端之间不通过IMS网络中的S-CSCF、I-CSCF、BGCF、IBCF等无法处理仿真业务的网元而将SIP-I消息直接发送给对端，即本发明中允许SIP INFO消息的不与SIP会话相关的会话外路由方式，而且SIP INFO消息只在MGCF和仿真业务AS之间直接传递不会影响IMS的计费功能；

其中，所述的仿真业务AS可以根据收到的来话呼入INVITE消息或呼出INVITE消息的SIP响应码中携带的Contact头域来获取MGCF的域名地址；

其中，所述的MGCF可以从收到的呼出INVITE消息或其发出INVITE消息的SIP响应码中携带的Record-Route头域等，获取仿真业务AS的域名地址。此外，MGCF甚至也可以通过事先的数据配置获取仿真业务AS域名地址，或从来自仿真业务AS的SIP-I消息中获取仿真业务AS域名地址。

(2)仿真业务AS仍可以按已经建立的呼叫信令路径将SIP INFO消息发送至MGCF，此时，S-CSCF、BGCF、IBCF等作为SIP-I代理网元需要能够透明传递INFO消息。

(3)MGCF仍可以按已经建立的呼叫信令路径将SIP INFO消息发送至S-CSCF，并由S-CSCF根据3GPP标准定义的iFC(Initial Filter Criteria，初始过滤规则)触发至指定的仿真业务AS，此时，S-CSCF、I-CSCF等作为SIP-I代理网元需要能够透明传递INFO消息，并且允许SIP INFO消息的不与SIP会话相关的会话外路由方式。

为便于对本发明的理解，下面将结合两个流程图描述本发明的具体实现方案。需要说明的是，本发明中在此提出的流程图示和文字说明仅为突出本发明的关键技术所作的解释，并不表示一个完整的呼叫和业务控制流程，也没有穷尽所有可能的分支流程。

流程图一：从IMS网络向传统电路域网络发起的业务互通

如图1所示，流程图一中相应的处理过程如下：

步骤11：IMS网络和传统电路域网络之间的呼叫信令路径已经建立；

步骤12：S-CSCF向仿真业务AS发送某个SIP消息，比如表示某个业务订阅的SIPSUBSCRIBE消息。

步骤13：仿真业务AS进行相应的业务处理，如果需要向对端发送包含有仿真业务应用相关信息的消息，则要判断对端是IMS网络还是传统电路域网络，因为此时呼叫信令路径已经建立，则仿真业务AS可以根据呼叫信令包含的路径信息判断对端是否为MGCF地址；

具体的判断对端是IMS网络还是传统电路域网络的方法主要有两种：

第一种方法为：

由于在从IMS网络向传统电路域网络的呼叫信令路径建立过程中，MGCF收到前向发来的SIP INVITE(SIP邀请)消息，在返回的SIP响应码如183 Session Progress(会话进行)中，在Contact(联系)头域中，将置上自己的域名地址；或者，在从传统电路域网络向IMS网络的呼叫信令路径建立过程中，MGCF发出的SIP INVITE消息中，在Contact头域中，将置上自己的域名地址，即：

Contact:<sip:mgcf1.home1.net>

而且，还由于Contact头域表示的是在IMS域中距离本端最远的网络实体的联系地址，具体是对端用户的IP地址，或者是MGCF或IBCF等处于分组域边界网元的联系地址(该分组域边界网元的域名)，因此，当仿真业务AS收到该SIP响应码或SIP INVITE消息时，可以通过分析Contact头域是否为MGCF域名，以判断对端网络是否为传统电路域网络。

第二种方法为：

即除上述判断对端网络类型的方法外，还有一种方法可以判断对端网络是否为传统电路域网络，具体为：在MGCF发出的SIP INVITE消息或183 Session Progress响应码中，P-Asserted-Identity(声明标识)头域中会置上传统电路域用户的标识，即：

P-Asserted-Identity:<tel:+86-755-1234-5678>

仿真业务AS收到该SIP响应码或SIP INVITE消息时，判断P-Asserted-Identity头域中的用户标识仅有tel(telephone，电话)URI(Uniform Resource Identifier，统一资源标识)格式，如果仅有tel URI格式，则表示该用户标识是传统电路域用户的标识。

当然，在实际应用过程中，也可以将上述两种方法联合起来判断判断对端网络是否为传统电路域网络。

判断出对端网络的类型后，便可以根据对端的网络类型采用不同的处理方法，具体为：

(1)对端网络是IMS网络

仿真业务AS向S-CSCF发送合适的SIP消息，如某个业务订阅的SIP SUBSCRIBE消息；

(2)对端网络是传统电路域网络且MGCF无法处理上述的SIP消息，如MGCF不能处理SIP SUBSCRIBE消息，则将上述的仿真业务应用相关信息转换为相应的ISUP信令，并封装在SIP INFO消息中，这是由于SIP-I消息一般只有SIP INVITE和SIP INFO两种消息，而且此时呼叫信令路径已经建立，因而只能封装于SIP INFO消息中，然后，直接向已经获取到的MGCF域名地址发送，如在该SIP-I消息的Route头域中设置如下：

Route:<sip:mgcf1.home1.net>

可以看到，该INFO消息直接从仿真业务AS路由到MGCF，而没有按正常的IMS标准定义的信令流程经过S-CSCF(可能还有BGCF、IBCF等)；此时对INFO消息来说，扩展了它的标准定义，由于该消息没有沿着在步骤1中已经建立的呼叫信令路径路由，因此要求其必须支持会话外的路由方式，此时，S-CSCF、BGCF、IBCF等网元不需要支持SIP-I消息。

当然，如果S-CSCF、BGCF、IBCF等网元可以作为SIP-I代理网元，也可以不扩展INFO消息的路由方式，仍让其沿已经建立的呼叫信令路径路由至MGCF，在该处理流程中略去这一处理过程。

步骤14：MGCF收到该SIP-I消息，从中提取出封装的ISUP消息，向对端传统电路域网络发送该ISUP消息。

在上述处理流程中，仿真业务AS需要判断对端是传统电路域时MGCF是否能处理SIPSUBSCRIBE、SIP NOTIFY等SIP消息，具体的可以由MGCF在业务互通时表现的特性通过呼叫信令建立时SIP消息的交互来判断。

1、MGCF在业务互通时表现的特性之一就是不支持SIP SUBSCRIBE、SIP NOTIFY等消息，这样如果假设在IMS中除了MGCF其它网元都可以处理这些SIP消息，则可以由仿真业务AS直接向对端发送这些SIP消息，如果对端是MGCF且不能处理此类SIP消息，则返回400 BadRequest(坏的请求)或403 Forbidden(禁止)或405 Method Not Allowed(方法不允许)或420 Bad Extension(坏的扩展)或415 Unsupported Media Type(不支持的媒体类型)或一扩展的指示此特征的失败响应码，仿真业务AS根据响应码得知对端是MGCF且不能处理这些SIP消息，则将这些SIP消息转译成封装了ISUP信令的SIP-I消息向MGCF发送。

或者，

2、MGCF业务互通时表现的另一特性就是支持并解析SIP-I消息中的ISUP信令，这样可以限制在IMS网络中最多只有MGCF网元和仿真业务AS可以在SIP消息中添加支持SIP-I指示信息(通过Accept头域)，这样，此时如果Accept头域中携带的SIP-I支持指示，表示的是支持对SIP-I中ISUP信令的解析，显然S-CSCF、I-CSCF、BGCF、IBCF等网元虽然可能要支持传递SIP-I消息，但是这些网元与仿真业务应用无关，因此不需要解析其中的ISUP信令，所以在这种限制条件下，当仿真业务AS收到对端发来的SIP INVITE消息或SIP响应码等中携带的Accept头域指示支持SIP-I，仿真业务AS可以确认对端是MGCF(即为传统电路域)。

流程图二：从传统电路域网络向IMS网络发起的业务互通

如图2所示，相应的处理流程如下：

步骤21：IMS网络和传统电路域网络之间的呼叫信令路径已经建立。

步骤22：传统电路域网络向MGCF发送包含有必须的传统补充业务应用相关信息的ISUP消息。

步骤23：MGCF收到该ISUP消息，判断该补充业务应用相关信息是否能被MGCF处理映射为SIP消息参数，如果不能，则将该ISUP消息封装在合适的SIP-I消息即INFO消息中，并根据从已经建立的信令路径中获取的仿真业务AS地址，直接向AS发送该SIP-I消息，如果能，则MGCF将所述的ISUP消息映射为SIP消息发送即可，本发明仅关注MGCF无法将ISUP消息映射为SIP消息的情况；

仿真业务AS在收到呼叫发起请求的SIP INVITE消息后，因为要留在信令路径中处理业务，则将自己的地址(域名)加入到Record-Route(记录-路由)头域中，如下所示：

Record-Route:<sip:simulation-as1.home1.net>

该Record-Route头域将在向MGCF发送的该SIP INVITE消息或该SIP INVITE消息的SIP响应码如183 Session Progress中携带，MGCF从Record-Route头域中获取仿真业务AS的域名地址，在上述的SIP-I消息的Route头域中设置如下：

Route:<sip:simulation-as1.home1.net>

由于Record-Route头域中会有多个网元的域名地址，因此，MGCF可以通过配置识别的方式从中获取仿真业务AS的域名地址，如“simulation-as1.home1.net”；

而且，当该头域中存在多个这样的AS域名时，则MGCF将SIP-I消息如INFO消息按上述头域中的记录顺序进行路由，如MGCF收到的呼出INVITE消息中的Record-Route头域为：

Record-Route:<sip:simulation-as2.home1.net>，<sip:simulation-as1.home1.net>，

             <sip:s-cscf1.home1.net>，<sip:p-cscf1.home1.net>

则MGCF发出的SIP INFO消息按下列顺序进行路由：

Route:<sip:simulation-as1.home1.net>，<sip:simulation-as2.home1.net>

可以看到，该INFO消息直接从MGCF路由到仿真业务AS，而没有按正常的IMS标准定义的信令流程经过S-CSCF(可能还有I-CSCF等)，显然此时对INFO消息来说，扩展了它的标准定义，因为该消息没有沿着步骤21中已经建立的呼叫信令路径路由，所以要求该消息必须支持会话外的路由方式，而且，这种情况下，不需要S-CSCF、I-CSCF等网元支持SIP-I消息。

此时，如果S-CSCF、I-CSCF等网元可以作为SIP-I代理网元，也可以仍让该INFO消息沿已经建立的呼叫信令路径路由至S-CSCF，该INFO消息仍要求是会话外的，即与步骤21中呼叫对应的会话无关；S-CSCF可以采用3GPP标准定义的iFC触发机制，根据预置的iFC签约数据和该INFO消息的内容匹配以得到被触发AS的联系地址，由于该INFO消息携带了封装的ISUP信令，根据这样的消息内容可以将该INFO消息触发至指定的仿真业务AS，在该处理流程图图2中略了这一过程。

可以看到，步骤23解决了前述的现有技术缺点二，或者由MGCF根据已经建立的呼叫信令包含的路径信息得到仿真业务AS地址，从而直接发送INFO消息；或者由S-CSCF根据iFC触发机制将该INFO消息发送至指定的仿真业务AS；这两种方式都要求INFO消息是会话外的。

步骤24：仿真业务AS收到该SIP-I消息，从中提取出封装的ISUP消息，处理该ISUP消息中包含的传统补充业务应用相关信息，向S-CSCF发送合适的SIP消息或向MGCF发送合适的SIP-I消息。

前面两个流程给出了本发明针对各种业务的通用实现方案，为进一步说明本发明，下面将以所述的MCID业务应用到具体业务互通中为例对本发明提供的具体实施例进行说明，具体的应用场景为：主叫用户位于传统电路域网络中，被叫用于位于IMS网络中，主叫用户发起匿名呼叫，被叫用户使用MCID业务追查主叫用户的身份标识。

如图3所示，相应的处理过程具体包括：

步骤31：传统电路域网络用户呼叫IMS用户，发起一个匿名呼叫；

步骤32：通话后，IMS用户发现这是一个恶意电话，则将使用MCID业务对主叫身份标识进行追查，具体为首先发送SIP SUBSCRIBE消息，消息中携带MCID业务订阅事件包。

步骤33：S-CSCF将携带MCID业务订阅事件包的SIP SUBSCRIBE消息发送给仿真业务AS(即MCID AS)。

步骤34：仿真业务AS接收对MCID业务的订阅，返回200OK响应码。

步骤35：S-CSCF将该200OK响应码传递给IMS用户终端。

步骤36：仿真业务AS根据呼入来话的SIP INVITE消息中携带的Contact头域判断是否为MGCF域名地址，以判断对端网络是否为传统电路域网络，如果是，且MGCF无法处理SIPSUBSCRIBE订阅消息，则仿真业务AS将该消息转译为ISUP IDR消息，并封装在SIP INFO消息中直接发送给MGCF，即向MGCF发送SIP-I消息。

步骤37：MGCF返回对SIP INFO消息的200OK响应码。

步骤38：MGCF收到该SIP INFO消息，从中提取出ISUP IDR消息，发送给传统电路域网络，从而可以向传统电路域网络请求主叫身份标识。

步骤39：传统电路域网络返回ISUP IRS消息，其中携带主叫身份标识。

步骤310：MGCF因其不能处理SIP NOTIFY通知消息，所以无法将ISUP IRS消息转译为合适的SIP消息，为此需要将其封装在INFO消息中直接发送给仿真业务AS；

所述的MGCF可以在建立呼叫信令路径时通过SIP响应码中携带的Record-Route头域，获取仿真业务AS的域名地址；也可以在步骤38中根据收到的SIP INFO消息直接获取仿真业务AS的域名地址。

步骤311：仿真业务AS返回对SIP INFO消息的200OK响应码。

步骤312：仿真业务AS从SIP INFO消息中提取并解析ISUP IRS消息，然后，将其转译为SIP NOTIFY消息，消息中携带MCID业务订阅事件包和主叫身份标识，并发送给S-CSCF。

步骤313：S-CSCF将SIP NOTIFY消息传递给IMS用户终端。

步骤314：IMS用户终端从SIP NOTIFY消息中获取其追查的主叫身份标识，返回200OK响应码。

步骤315：S-CSCF将该200OK响应码传递给仿真业务AS。

经过上述处理过程可以看出，基于本发明可以很好地实现IMS网络与传统电路域网络之间的业务互通，实现本发明的目的。

下面再通过一个具体的另一种业务实施例说明本发明方案的应用，所述的另一种仿真业务为MWI(消息等待指示)业务，俗称“留言灯”业务，该业务可以使网络在用户的邮箱有新留言时，通知用户。目前，可以使用的通知用户有新留言的两种方式分别：SIPNOTIFY消息和SIP MESSAGE消息，这两种消息MGCF上均无法处理，下面将介绍使用本发明方案支持MWI业务在IMS网络和传统电路域网络间的互通的实施。

该实施例应用场景一

该应用场景为语音邮箱在传统电路域，邮箱用户在IMS域，用户有新留言，语音邮箱通知该用户。

应用场景一的具体处理流程如图4所示，具体包括以下步骤：

步骤41：某个来话呼入IMS网络的SIP用户，该用户归属的S-CSCF收到SIP INVITE消息；

步骤42：呼入来话发生前转，转移至语音邮箱(具体的呼叫转移过程本发明不关注，故省略)，S-CSCF将该前转呼叫触发至仿真业务AS；

步骤43：仿真业务AS将自己加入信令路径中，向S-CSCF返回SIP INVITE消息；

步骤44：由于语音邮箱位于传统电路域，因此，S-CSCF将该前转呼叫发送至MGCF；

步骤45：MGCF将SIP INVITE消息转译为ISUP IAM(Initial Address Message，起始地址消息)消息，向传统电路域网络发送；

步骤46：呼叫建立，且呼入来话开始留言；

步骤47：留言呼叫一建立后，语音邮箱向SIP用户通知有新留言，发送一个ISUP IAM消息，消息中携带留言通知指示；

步骤48：MGCF收到该ISUP IAM消息，由于不能将该消息中携带的留言通知指示转译为合适的SIP消息，则将该IAM消息直接封装在SIP INFO消息中，并根据其在上述流程收到的SIP INVITE消息中获取的仿真业务AS域名地址，将该SIP INFO消息直接发送至仿真业务AS：

步骤49：仿真业务AS返回对SIP INFO消息的200OK响应码；

步骤410：仿真业务AS从SIP INFO消息中提取出被封装的ISUP IAM消息，根据其中携带的留言通知指示，生成SIP MESSAGE消息并向SIP用户发送，消息中携带指示提醒用户有新留言；

步骤411：S-CSCF向SIP用户发送SIP MESSAGE消息；

步骤412：SIP用户终端收到SIP MESSAGE消息，终端上显示SIP MESSAGE消息内容，指示有新留言，并返回200OK响应码；

步骤413：S-CSCF将该200OK响应码传递给仿真业务AS。

通过上述处理过程，实现了MWI业务在IMS网络与传统电路域网络之间的互通。

实施例应用场景二

该应用场景中语音邮箱在IMS域，邮箱用户在传统电路域，用户有新留言，语音邮箱通知该用户。

应用场景二的具体处理流程如图5所示，具体包括以下步骤：

步骤51：某个来话呼入传统电路域网络的传统终端用户，该用户归属的交换机收到ISUP IAM消息；

步骤52：交换机处理业务逻辑，比如该传统终端用户设置了无条件呼叫前转语音邮箱业务，则将该呼叫向语音邮箱发起前转，呼叫目的地址为位于IMS网络的语音邮箱的接入码，该前转呼叫根据目的地址寻址至MGCF；

步骤53：MGCF将ISUP IAM消息转译为SIP INVITE消息，并向S-CSCF发送；

步骤54：S-CSCF将呼叫触发至仿真业务AS；

步骤55：仿真业务AS根据收到的SIP INVITE消息中判断对端为传统电路域网络，记录下MGCF的域名地址，消息返回S-CSCF；

步骤56：S-CSCF将SIP INVITE消息路由至语音邮箱；

步骤57：语音邮箱应答，呼叫建立，呼入来话开始留言；

步骤58：留言呼叫一建立，语音邮箱向传统终端用户通知有新留言，具体为向S-CSCF发送一个SIP MESSAGE消息，消息中携带留言通知指示；

步骤59：S-CSCF将SIP MESSAGE消息触发至仿真业务AS；

步骤510：仿真业务AS返回对SIP MESSAGE消息的200OK响应码；

步骤511：S-CSCF将该200OK响应码传递给语音邮箱；

步骤512：由于MGCF无法处理SIP MESSAGE消息，因此，仿真业务AS生成指示有新留言通知的ISUP IAM消息，并将其封装在SIP INFO消息中，直接发送给MGCF；

步骤513：MGCF返回对SIP INFO消息的200OK响应码；

步骤514：MGCF从SIP INFO消息中提取出携带有新留言通知指示的ISUP IAM消息，并向传统电路域网络发送。

通过上述处理过程可以实现IMS网络与传统电路域网络的互通，从而使得设置于IMS网络中的语音邮箱同样可以正常应用。

本发明中，除上可以通过前面描述的实现方案实现本发明的目的外，还可以采用其他实现方案实现本发明的目的，下面将对本发明提供的其他的可供选择的具体实现方式进行说明。

本发明需要在仿真业务AS和MGCF之间建立直达路由，进而直接传送携带仿真业务相关信息的SIP-I消息。因此，对仿真业务AS来说，除采用SIP协议实现仿真业务AS和MGCF之间建立直达路由外，还可以通过HTTP协议承载XML来传递业务相关信息，XML可以有多种形式的具体应用，例如可以采用XCAP实现，XCAP是XML在应用配置数据访问方面的具体应用。因此如果MGCF可以支持HTTP/XCAP，则也可以在仿真业务AS和MGCF之间通过HTTP/XCAP来完成业务互通时的业务相关信息的传递。

下面将对两种可能的具体实现方案进行描述。

(一)由前面提供的实现方案可知，仿真业务AS和MGCF之间在呼叫信令路径已经建立后，便可以分别获取对方的域名地址。这样，在该实现方案中，当判断满足仿真业务AS和MGCF要发送SIP-I的条件时，仿真业务AS和MGCF便可以分别向对方发送包含业务相关信息的XCAP消息，MGCF和仿真业务AS收到并解析该XCAP消息，并分别转译成合适的ISUP消息和SIP消息。与所述的图1和图2提供的处理流程对应，在相应的第3步骤(即步骤13和步骤23)中，该方案的处理为：仿真业务AS和MGCF发出的是XCAP消息，而对应步骤14和步骤24，该方案的处理为：MGCF和仿真业务AS将该XCAP消息转译成合适的ISUP消息和SIP消息并发出。

(二)MGCF和仿真业务AS可以通过中间设置的寻址网元将XCAP消息发送至对方，以实现本发明。

即在仿真业务AS和MGCF之间设置一个逻辑网元HTTP寻址网元，MGCF收到一个包含业务相关信息的ISUP消息，无法将其映射成合适的SIP消息，则将其转译成包含业务相关信息的XCAP消息，向该寻址网元发送，该寻址网元根据XCAP消息的内容，寻址出一个合适的仿真业务AS，并将该XCAP消息路由至该仿真业务AS。

具体可以在XCAP消息中携带仿真业务标识，如“MCID”、“MWI”等，寻址网元根据仿真业务标识以及XCAP消息中携带的其它相关信息，如相关用户标识等，通过和预置的配置数据匹配得到对应仿真业务AS的域名地址，该预置的配置数据可以是一种普通的表格形式，也可以是一种以某种语法如XML等描述的过滤规则。

同时，在IMS域中，当存在多个MGCF时，在互通呼叫中MGCF是根据号码分析确定的，因此仿真业务AS在前述的要向MGCF发送SIP-I的判断条件满足时，向寻址网元发送包含业务相关信息的XCAP消息，业务相关信息中可以包含此次呼叫的主被叫号码，寻址网元根据号码分析确定一个MGCF，并将该XCAP消息路由至该MGCF。

下面以这种设置寻址网元的方式对图4中描述的应用场景的具体实现进行说明。参照图4的应用场景：语音邮箱在传统电路域，邮箱用户在IMS域，用户有新留言，语音邮箱将通知该用户，该方案的具体实现如图6所示，具体包括以下步骤：

步骤61：某个来话呼入IMS网络的SIP用户，该用户归属的S-CSCF收到SIP INVITE消息；

步骤62：呼入来话发生前转，转移至语音邮箱(过程略)，语音邮箱位于传统电路域，S-CSCF将到该前转呼叫发送至MGCF；

步骤63：MGCF将SIP INVITE消息转译为ISUP IAM消息，向传统电路域网络发送；

步骤64：呼叫建立，呼入来话开始留言；

步骤65：留言呼叫建立，语音邮箱向SIP用户通知有新留言，发送一个ISUP IAM消息，消息中携带留言通知指示；

步骤66：MGCF收到该ISUP IAM消息，由于不能将该消息中携带的留言通知指示转译为合适的SIP消息，则将该留言通知指示通过XML描述由HTTP消息携带发送至寻址网元，如以XCAP描述，定义的格式示例如下：

<xs:element name＝″MWI″substitutionGroup＝″ss:absService″>

……………………

<xs:element name＝″identity″base＝″xs:anyURI″substitutionGroup＝″cp:condition″/>

<xs:element name＝″messages″base＝″xs:string″substitutionGroup＝″cp:action″/>

其中，“MWI”即表示业务标识；“identity”表示被留言的用户标识，“anyURI”表示其数据类型为任意格式的统一资源标识(Uniform Resource Identifier，URI)；“messages”表示留言信息，“string”即表示其数据类型为字符串，如具体内容可以是“You have two new messages”(你有两个新留言)。

步骤67：寻址网元收到该HTTP请求，根据HTTP请求中携带的XML描述内容，如根据业务标识“MWI”和被留言的用户标识，和预置的配置数据匹配，得到对应的仿真业务AS(MWI AS)的域名地址，并将该HTTP请求向已获取地址的仿真业务AS发送；

步骤68：仿真业务AS接收到该HTTP请求，返回HTTP响应；

步骤69：寻址网元将该HTTP响应传递给MGCF；

步骤610：仿真业务AS解析HTTP请求中携带的XML描述内容，向被留言的用户标识即前述的SIP用户(“identity”)发送SIP MESSAGE消息，消息中携带留言信息相关内容(“messages”)；

步骤611：S-CSCF向SIP用户发送SIP MESSAGE消息；

步骤612：SIP用户终端收到SIP MESSAGE消息，终端上显示SIP MESSAGE消息内容，指示有新留言，并返回200OK响应码；

步骤613：S-CSCF将该200OK响应码传递给仿真业务AS。

在图6所示的处理流程中，与图5所示的处理流程不同的是：在图6中，仿真业务AS没有将自己加入在呼叫信令路径中，而是由寻址网元根据MGCF发送的HTTP消息中携带的XML描述，匹配得到相应的仿真业务AS的域名地址，然后，再由将相应的消息发送给仿真业务AS。

需要说明的是：由于XCAP只是XML的一种具体应用，因此，本发明中还可以采用其它XML的应用如SOAP(Simple Object Access Protocol，简单对象访问协议)是XML在远程过程调用方面的具体应用，通过SOAP协议，MGCF和仿真业务AS之间可以直接传递一些表示仿真业务相关信息的参数，以流程图6为例，在步骤66中，HTTP消息中携带的SOAP描述的定义格式示例如下：

<SOAP-ENV:Body>

        <SimulationServicesApplication>

               <ServiceName xsi:type＝″xsd:string″>MWI</ServiceName>

               <identity xsi:type＝″xsd:anyURI″>123@exm.com</identity>

               <messages xsi:type＝″xsd:string″>You have two new messages</messages>

</SOAP-ENV:Body>

其中，“SimulationServicesApplication”是被调用的远程过程的名称，相当于MGCF调用位于仿真业务AS上的过程SimulationServicesApplication，其参数有业务名称(ServiceName)，参数值为“MWI”、用户标识(identity)，参数值为“123@exm.com”、留言信息(messages)，参数值为“You have two new messages”。可以看到，通过这三个参数，MGCF向仿真业务AS传递了相关的业务信息。

本发明中还可以采用其它的XML描述方式，比如自定义的XML描述等。

本发明还提供了一种实现互通业务的系统，如图7所示，在所述系统中，仿真业务AS与MGCF之间可以直接连接通信，也可以通过HTTP寻址网元间接进行通信，下面将对图7所示的系统中包含的实体进行描述：

(1)仿真业务AS

为各类仿真业务提供业务逻辑控制功能，是各种仿真业务的宿主执行环境，在逻辑功能上，具体按不同的仿真业务种类可以分成不同的仿真业务AS，如MCID AS等；

当仿真业务AS用于与互通网元MGCF进行信息交互，实现分组域网络与传统电路域网络的业务互通，其结构如图8所示，具体包括：

(11)第一消息发送处理模块

用于将由分组域网络向传统电路域网络发送的信息构造为互通网元可以识别的预定格式的消息，并向所述互通网元发送；而且，所述的第一消息发送处理模块具体包括：

第一消息构造模块，用于构造互通网元可以识别的承载着传统电路域信令的SIP消息，即SIP-I消息，或HTTP消息，消息中的目的地址为对端互通网元的地址信息；以及第一消息发送模块，用于将第一消息构造模块构造的消息向所述的互通网元发送，图8中仅示出了这种结构，其他结构类似，故未示出；

或者，

第二消息构造模块，用于构造互通网元可以识别的承载着传统电路域信令的SIP消息，即SIP-I消息；以及第二消息发送模块，用于将第二消息构造模块构造的消息通过已经建立的呼叫信令路径向所述的互通网元发送；

或者，

第三消息构造模块，用于构造互通网元可以识别的HTTP消息，所述的HTTP消息中承载着以XML描述的信息；以及第三消息发送模块，用于将第三消息构造模块构造的消息发送给可以与互通网元通信的中间寻址网元。

(12)第一消息接收模块

接收并解析互通网元发来的预定格式的消息，如SIP-I消息和HTTP消息等，从而获得由传统电路域发来的信息。

(2)S-CSCF

用于提供IMS会话路由、业务触发等功能，图中S-CSCF和MGCF之间通过虚线相连接，表示两者之间可以直接相连接，也可以通过其它网元如I-CSCF(问询-呼叫会话控制功能)、BGCF(出口网关控制功能)、IBCF(互通边界控制功能)实体等间接相连接；

S-CSCF和仿真业务AS之间I1接口是SIP或SIP-I，和MGCF之间的接口是SIP或SIP-I；当仿真业务AS和MGCF之间的网元S-CSCF、I-CSCF、BGCF、IBCF等实体支持SIP-I时，则各实体可以作为SIP-I代理网元，将经过的仿真业务AS与MGCF之间交互的消息透传给对端仿真业务AS或MGCF。

(3)MGCF

即互通网元，其与传统电路域网络之间的接口为ISUP，而且，本发明中与标准IMS架构定义不同的是：MGCF和仿真业务AS之间存在着一个直接接口I3，I3可以是SIP-I，还可以是HTTP(超文本传输协议)；

当互通网元用于与应用服务器进行信息交互，实现分组域网络与传统电路域网络的业务互通，则如图8所示，所述的MGCF具体包括：

(31)第二消息发送处理模块

用于将传统电路域需要向分组域发送的信息构造为与应用服务器间交互的预定格式的消息，并向所述应用服务器发送，而且，所述的第二消息发送处理模块具体包括：

第四消息构造模块，用于构造向应用服务器发送的SIP消息，即承载有传统电路域信令的SIP-I消息，或HTTP消息，消息中的目的地址为对端应用服务器的地址信息；以及第四消息发送模块，用于将第一消息构造模块构造的消息向所述的应用服务器发送，图8中仅示出了这种结构，其他结构类似，故未示出；

或者，

第五消息构造模块，用于构造向应用服务器发送的SIP消息，即承载有传统电路域信令的SIP-I消息；以及第五消息发送模块，用于将第五消息构造模块构造的消息通过已经建立的呼叫信令路径向所述的应用服务器发送；

或者，

第六消息构造模块，用于构造向应用服务器发送的HTTP消息，所述的消息中承载着以XML描述的传统电路域需要发送的信息；以及第六消息发送模块，用于将第六消息构造模块构造的消息发送给可以与应用服务器通信的中间寻址网元。

(32)第二消息接收模块

接收并解析应用服务器发来的预定格式的消息，如SIP-I消息或HTTP消息等，获得由分组域发来的信息。

(4)HTTP寻址网元

该网元为本发明新增加的网元，用于配置仿真业务AS与MGCF之间的间接基于HTTP的通信，具体为：当MGCF和仿真业务AS之间支持HTTP协议时，该网元是用于发送HTTP消息的路由寻址网元，即MGCF和仿真业务AS之间的HTTP协议可以通过I3接口直接相连，也可以通过I4接口间接相连。

综上所述，本发明的实现使得仿真业务AS可以准确判断出对端是否为传统电路域网络，从而决定是否发送SIP-I消息，并扩展SIP INFO的会话外路由方式以使SIP-I消息可以在MGCF和仿真业务AS之间直接或通过SIP-I代理网元透明传送，从而使业务互通可以正常进行，避免了因某些网元对SIP-I的不支持等原因而导致业务互通失败，提高了业务互通成功率。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (18)

1、一种实现业务互通的方法，所述方法应用于包含分组域的应用服务器，以及与传统电路域通信的互通网元的系统中，其特征在于，

当分组域的应用服务器通过与对端交互的消息确定对端无法处理分组域的基本消息时，则确定为由分组域的应用服务器向传统电路域发送信息，相应的处理包括：

A、分组域的应用服务器将需要发送给传统电路域的信息封装或转译为互通网元可以解析的预定格式的消息，并发送；

B、互通网元接收到所述预定格式的消息后，解析获得传统电路域的信息，并向传统电路域发送；

当传统电路域无法将待发送的信息转译为分组域的基本消息时，则对于由传统电路域向分组域的应用服务器发送信息的处理包括：

C、传统电路域向互通网元发送需要发送给分组域的信息，互通网元将所述需要发送给分组域的信息封装或转译为所述预定格式的消息，并向分组域发送；

D、分组域的应用服务器接收到所述预定格式的消息后，解析获得分组域的信息，并发送。

2、根据权利要求1所述的方法，其特征在于：

所述的步骤A包括：

A1、分组域的应用服务器将需要发送给传统电路域的信息，封装于目的地址为互通网元的地址信息的封装有综合业务数字网用户部分ISUP的会话初始协议SIP-I消息中，或者转译为扩展标记语言XML描述的目的地址为互通网元的地址信息的超文本传输协议HTTP消息发送给互通网元；

或者，

A2、分组域的应用服务器将需要发送给传统电路域的信息转译为XML描述携带于超文本传输协议HTTP消息中发送给寻址网元，由寻址网元确定对端互通网元的地址信息，并将所述HTTP消息发送给所述互通网元；

或者，

A3、分组域的应用服务器将需要发送给传统电路域的信息封装于SIP-I消息中并通过已经建立的呼叫信令路径发送给互通网元；

所述的步骤C包括：

C1、互通网元将需要发送给分组域的信息封装于目的地址为分组域的应用服务器的地址信息的SIP-I消息中、或转译为XML描述携带于目的地址为分组域的应用服务器的地址信息的超文本传输协议HTTP消息中发送给相应的应用服务器；

或者，

C2、互通网元将需要发送给分组域的信息转译为XML描述携带于HTTP消息中发送给寻址网元，由寻址网元确定对端应用服务器的地址信息，并将所述HTTP消息发送给所述的应用服务器；

或者，

C3、互通网元将需要发送给分组域的信息封装于SIP-I消息中，并通过已经建立的呼叫信令路径发送给相应的应用服务器。

3、根据权利要求2所述的方法，其特征在于，

所述步骤D进一步包括：

所述的应用服务器根据收到的呼叫信令中包含的头域中的信息确定对端的互通网元的域名地址信息；

所述步骤B进一步包括：

所述的互通网元根据收到的呼叫信令中包含的头域中的信息确定对端的应用服务器的域名地址信息；或者，互通网元通过预先配置的信息获取应用服务器的域名地址；或者，互通网元根据收到的来自应用服务器的消息确定应用服务器的域名地址。

4、根据权利要求2所述的方法，其特征在于，寻址网元中配置有以预定的信息索引的应用服务器及互通网元的地址信息，当寻址网元接收到包含预定的信息的消息时，则以所述预定的信息为索引查找对应的地址信息，并作为消息接收端的地址信息。

5、根据权利要求2所述的方法，其特征在于，寻址网元设置于互通网元或应用服务器中，或独立设置于网络中。

6、根据权利要求2所述的方法，其特征在于，XML描述包括以扩展标记语言配置访问协议XCAP或简单对象访问协议SOAP描述。

7、根据权利要求1至6任一项所述的方法，其特征在于，所述的方法还包括：

E、分组域的应用服务器在业务处理过程中，当需要向对端发送信息时，若确定接收端为所述的互通网元，则执行步骤A。

8、根据权利要求7所述的方法，其特征在于，所述的确定接收端为所述的互通网元的处理包括：

根据对端发送来的消息中承载的信息确定对端能够支持所述预定格式的消息，则确定对端为互通网元；或者，分组域的应用服务器根据收到的SIP消息中包含的路径信息确定对端是否为互通网元。

9、根据权利要求8所述的方法，其特征在于，所述的路径信息包括：SIP消息中的头域承载的地址信息和/或用户标识信息。

10、根据权利要求1至6任一项所述的方法，其特征在于，所述的方法还包括：

分组域的应用服务器在业务处理过程中，当需要向对端发送信息时，若确定接收端为互通网元，并进一步确定所述互通网元无法处理包含以SIP头域表述的发送信息的SIP消息，则执行步骤A。

11、根据权利要求10所述的方法，其特征在于，确定互通网元无法处理分组域的消息的处理包括：

分组域的应用服务器向互通网元发送所述SIP消息，当互通网元返回对所述SIP消息不支持的失败响应消息时，则确定互通网元无法处理所述SIP消息。

12、根据权利要求1至6任一项所述的方法，其特征在于，所述的分组域的应用服务器和互通网元之间传递的信息包括：

恶意呼叫识别MCID业务信息或消息等待指示MWI业务信息。

13、一种应用服务器，用于与互通网元进行信息交互，实现分组域网络与传统电路域网络的业务互通，其特征在于，包括：

第一消息发送处理模块：用于将由分组域网络向传统电路域网络发送的信息构造为互通网元可以识别的预定格式的消息，并将所述预定格式的消息向所述互通网元发送；

第一消息接收模块：接收并解析互通网元发来的预定格式的消息，获得由传统电路域发来的信息。

14、根据权利要求13所述的应用服务器，其特征在于，所述的第一消息发送处理模块包括：

第一消息构造模块，用于构造互通网元可以识别的SIP-I消息或HTTP消息，消息中的目的地址为对端互通网元的地址信息；以及第一消息发送模块，用于将第一消息构造模块构造的消息向所述的互通网元发送；

或者，

第二消息构造模块，用于构造互通网元可以识别的SIP-I消息；以及第二消息发送模块，用于将第二消息构造模块构造的消息通过已经建立的呼叫信令路径向所述的互通网元发送；

或者，

第三消息构造模块，用于构造互通网元可以识别的HTTP消息；以及第三消息发送模块，用于将第三消息构造模块构造的消息发送给可以与互通网元通信的中间寻址网元。

15、一种互通网元，用于与应用服务器进行信息交互，实现分组域网络与传统电路域网络的业务互通，其特征在于，包括：

第二消息发送处理模块：用于将传统电路域需要向分组域发送的信息构造为与应用服务器间交互的预定格式的消息，并将所述预定格式的消息向所述应用服务器发送；

第二消息接收模块：接收并解析应用服务器发来的预定格式的消息，获得由分组域发来的信息。

16、根据权利要求15所述的互通网元，其特征在于，所述的第二消息发送处理模块包括：

第四消息构造模块，用于构造向应用服务器发送的的SIP-I消息或HTTP消息，消息中的目的地址为对端应用服务器的地址信息；以及第四消息发送模块，用于将第四消息构造模块构造的消息向所述的应用服务器发送；

或者，

第五消息构造模块，用于构造向应用服务器发送的SIP-I消息；以及第五消息发送模块，用于将第五消息构造模块构造的消息通过已经建立的呼叫信令路径向所述的应用服务器发送；

或者，

第六消息构造模块，用于构造向应用服务器发送的HTTP消息；以及第六消息发送模块，用于将第六消息构造模块构造的消息发送给可以与应用服务器通信的中间寻址网元。

17、一种实现业务互通的系统，其特征在于，包括：

应用服务器，设置于分组域网络中，用于构造互通网元可以识别的预定格式的消息，并发送给互通网元，同时，接收并解析互通网元发来的预定格式的消息，获得传统电路域发来的信息；

互通网元，连接设置于分组域网络与传统电路域网络之间，用于构造所述预定格式的消息，并发送给所述应用服务器，同时，接收并解析应用服务器发来的预定格式的消息，获得分组域网络发送给传统电路域的信息，并发送给传统电路域网络。

18、根据权利要求17所述的系统，其特征在于，所述的系统还包括：

寻址网元，连接设置于应用服务器与互通网元之间，用于应用服务器与互通网元之间交互有消息寻址。

Images