CN100466641C - 基于sip支持多itsp的系统及实现方法 - Google Patents

Abstract

本发明涉及一种基于SIP支持多ITSP业务的系统及实现方法。本发明所述的系统包括SIP终端和多个ITSP服务器，本发明可以实现：在上行方向，为SIP终端发来的SIP消息选择相应的ITSP服务器，并将SIP消息转换为该ITSP服务器规定的格式后通过相应的端口发送给该ITSP服务器；在下行方向，接收ITSP服务器发来的SIP消息，根据接收到的SIP消息的端口信息确定该ITSP服务器的身份信息，并发送给SIP终端。本发明可以根据当前呼叫对应使用的ITSP的SIP接口规格生成和处理SIP消息和SIP呼叫流，并能够屏蔽消息交互过程中的差异。因此，本发明的实现为用户提供了一种可以同时支持多ITSP的接入设备。

Description

基于SIP支持多ITSP的系统及实现方法

技术领域

本发明涉及网络通信技术领域，尤其涉及一种基于SIP支持多ITSP的系统及实现方法。

背景技术

SIP(会话初始协议)作为下一代基于IP的多媒体网络中最重要的标准之一已经在全球范围之内得到了越来越多的认可。很多公司的实时通信产品已经为基于SIP实现，或者在产品中内嵌SIP支持功能。因此，SIP已经成为电信业努力奋斗的目标IMS(IP多媒体子系统)的核心技术之一。

现在基于SIP的VolP(基于IP的语音)运用已经越来越多。对于个人用户和企业用户来说，其拥有的SIP设备只有接入到ITSP(互联网电话服务提供商)的网络中，才能实现真正的大范围应用。目前，各个设备生产厂商均在开拓VoIP商机的同时也积极地制定和实践相应的SIP接口规格。

SIP本身只是一种通讯标准，该标准可以将很多业务和功能的实现方式、管理方式留给了实现者，所以对于真正商用级的SIP服务，ITSP不得不确定自己的业务实现方式，不得不将自己的SIP接口规格公之于终端开发者或接入设备开发者。

各ITSP有自己的用户管理方式，同时，各ITSP也必须不断地开拓独特的创新的业务和功能来赢得商业竞争的胜利。这样就使得各ITSP所提供的SIP接口规格出现了差异。

对于需要多条VolP外线(事实上就是多个VolP帐号)的企业用户而言，通常希望能够拥有属于不同ITSP的外线，从而可以利用不同ITSP所提供的独特业务，并可以在某个呼叫中自动地选择资费最低的外线，而且属于不同ITSP的外线可以同时使用，还可以在连上ITSP的同时使用本地IP-PBX(基于IP的企业内部交换机)提供的丰富而复杂的内线功能。同时，对于高端个人用户而言，也并不希望被绑定在某个ITSP上。

遗憾的是，不管是的个人终端产品还是企业接入设备，尽管有的已经实现了多条VoIP外线的同时使用，但这些外线所提供的规格是完全相同的，换言之，这些企业接入设备只支持单ITSP。也有一些产品，号称可以支持多个ITSP，但是所述支持并不是“同时性”和“根据呼叫智能性”的，而是在设备运行中只支持某个特定的ITSP，如果需要使用另一个ITSP提供的服务，需要重新进行用户配置和重新启动设备。

因此，目前的企业接入设备还无法实现同时支持多ITSP的功能。

发明内容

鉴于上述现有技术所存在的问题，本发明的目的是提供一种基于SIP支持多ITSP的系统及实现方法，从而为企业及个人用户提供一种可以同时支持多ITSP的技术方案，便于其灵活地根据需要选择应用相应的ITSP。

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

本发明提供了一种基于SIP支持多ITSP业务的装置，包括：

SIP业务处理部分：用于接收SIP终端或ITSP服务器发来的SIP消息，并根据配置的策略对所述的SIP消息进行处理后，通过选择的ITSP服务器端口或终端接口发送给ITSP服务器或SIP终端。

所述的SIP业务处理部分进一步包括SIP传输层部分、SIP事务层部分、SIP事务用户部分和媒体处理部分，各个部分又分别建立了对应的本地SIP用户代理模型和远端SIP用户代理处理模型，且：

本地SIP用户代理模型：与所述远端SIP用户代理处理模型间通过事件通知机制进行信息的交互，用于接收用户终端发来的SIP消息，并为其选择对应的远端SIP用户代理处理模型对其进行处理，接收远端SIP用户代理处理模型事件通知，并进行相应的处理后与用户终端通信；

一组远端SIP用户代理处理模型：各个模型分别根据本地SIP用户代理模型的事件通知通过对应的ITSP服务器端口与远端ITSP服务器通信，并接收处理ITSP服务器发来的SIP消息，通知本地SIP用户代理模型。

所述的远端SIP用户代理处理模型包括：

注册处理模块：用于将本地地址信息和对应于各个ITSP服务器的本地端口号注册于各个ITSP服务器上；

媒体中继处理模块：位于媒体处理部分，用于对相应的ITSP服务器或用户终端的媒体流进行格式转换处理；

信令处理模块:用于对相应的ITSP服务器或用户终端的对话的信令进行格式转换处理。

本发明提供了一种基于SIP支持多ITSP业务的系统，包括所述基于SIP支持多ITSP业务的装置，一组用户终端和一组ITSP服务器，所述的一组用户终端通过所述装置与一组ITSP服务器连接。

所述的一组用户终端还通过企业内部IP电话交换机与所述的装置连接，且所述的装置可以内置于网络设备中或单独设置。

本发明提供了一种基于SIP支持多ITSP业务的实现方法，该方法应用的系统包括SIP终端和多个ITSP服务器，所述的SIP终端通过所述基于SIP支持多ITSP业务的装置与所述ITSP服务器连接，具体包括：

A、在上行方向，所述装置为SIP终端发来的SIP消息选择相应的ITSP服务器，并将SIP消息以该ITSP服务器规定的格式进行处理，之后，通过为该ITSP服务器分配的本地端口发送给该ITSP服务器；

B、在下行方向，所述装置接收ITSP服务器发来的SIP消息，根据接收到的SIP消息的端口信息确定该ITSP服务器的身份信息，并将SIP消息以SIP终端或企业内部IP电话交换机要求的格式进行处理，然后发送给SIP终端或IP电话交换机。

所述的步骤A包括：

A1、当所述装置接收SIP终端发来的SIP消息时，根据SIP消息中来源From头字段和请求URI信息及保存的策略信息确定对应的ITSP服务器；

A2、将所述的SIP消息通过ITSP服务器对应的端口发送给该ITSP服务器。

所述的步骤B包括：

B1、当所述装置接收ITSP服务器发来的SIP消息时，根据SIP消息的目的端口号确定发送该SIP消息的ITSP服务器信息；

B2、将所述的SIP消息发送给该SIP终端。

本发明所述的方法还包括：

C、由所述的装置中的独立设置的SIP用户代理处理模型屏蔽SIP终端与远端ITSP服务器间的差异，所述SIP用户代理处理模型包括本地SIP用户代理处理模型和远端SIP用户代理处理模型。

所述的步骤C包括：

由所述装置中的SIP用户代理处理模型对SIP终端与所述的ITSP服务器之间交互的SIP消息进行SIP消息格式及地址信息的转换处理；本地SIP用户代理处理模型可以屏蔽SIP终端支持但ITSP服务器不支持的功能，远端SIP用户代理处理模型可以屏蔽ITSP服务器支持但SIP终端不支持的功能。

由上述本发明提供的技术方案可以看出，本发明使得用户终端可以同时向多个ITSP的SIP服务器上进行注册，从而为支持多ITSP提供了可能。

本发明中，用户终端作为主叫方时，能够根据灵活配置的路由规则自动地选择接入的ITSP；用户终端作为被叫方时，则可以有效识别呼叫来自于哪个ITSP。

同时，本发明还能够根据当前呼叫对应使用的ITSP的SIP接口规格生成和处理SIP消息和SIP呼叫流，并能够屏蔽消息交互过程中的差异。

因此，本发明的实现为用户提供了一种可以同时支持多ITSP的接入设备，该接入设备的应用使得用户终端可以灵活地选择应用各个ITSP。

附图说明

图1和图2为本发明所述的接入设备的应用组网示意图；

图3和图4为接入设备在网络中的设置位置示意图；

图5为所述的接入设备的具体实现结构示意图；

图6为应用该接入设备的信息交互过程示意图；

图7为本发明中媒体中继过程示意图；

图8为需要进行呼叫转移的呼叫关系示意图；

图9为图8中进行呼叫转移处理过程的示意图；

图10为屏蔽会话监测功能的实现过程示意图。

具体实施方式

本发明的目的是可以实现同时使用多ITSP的帐号及功能。本发明既可以适用于企业接入设备，同时，还可以适用于个人终端产品。

通过前面针对现有技术的描述可以看出，为实现对多ITSP的同时支持功能，目前的还需要解决以下问题：

1、用户终端必需可以同时注册到多个ITSP的SIP服务器上；

2、作为主叫方时，能够根据灵活的路由规则智能地选择接入的ITSP，作为被叫方时，能够识别呼叫来自于哪个ITSP；

3、能够根据当前呼叫对应使用的ITSP的SIP接口规格生成和处理SIP消息和SIP呼叫流；

4、能够在本地SIP服务器和ITSP端的SIP服务器(即ITSP服务器)间进行SIP消息转换；

5、能够屏蔽(吸收)本地SIP服务器提供的某些功能，因为ITSP尚未支持这些SIP消息和SIP呼叫流；并能够屏蔽(吸收)ITSP侧的某些功能，因为本地SIP服务器尚未支持这些SIP消息和呼叫流。

明确了上述需要解决的问题后，下面将对本发明针对上述问题的解决办法进行说明。

本发明中针对不同的ITSP采用不同的本地端口号，这样，便可以支持多路并发呼叫，这些并发呼叫可能属于不同的ITSP，通过SIP消息采用的端口号，可以区分这路呼叫属于哪个ITSP，从而根据该ITSP的规格进行处理。

采用收发SIP消息时的本地端口号来区分ITSP，是一种适应于现有和将来的ITSP的通用而可靠的实现方法。

另外，本发明还采用了多SIP UA(SIP用户代理)机制，具体为:针对每种ITSP SIP服务器和本地SIP服务器分别建立SIP UA模型，分别称为远端SIP UA处理模型和本地SIP UA模型，可以采用类或对象实现，每个SIP UA模型具备自己的一套行为方式。也就是说，不管针对本地SIP服务器还是针对ITSP的SIP服务器，都分别作为独立的SIP UA来运行。任何一路来电都可以根据前面所述的ITSP识别机制来智能地获知对应的ITSP从而选择合适的SIP UA模型。而且，本发明中，要求具有不同规格的SIP UA可以同时运行在该系统中。

在针对本地SIP服务器的本地SIP UA模型和针对ITSP SIP服务器的远端SIP UA处理模型之间不直接进行SIP消息的传递，而是相互通知事件。因为不同的SIP服务器可能支持不同的功能，用多SIP UA机制能够屏蔽本地SIP服务器或ITSP的SIP服务器的某些功能，使它们能够继续保持互通。

基于上述实现思想，本发明提供了一种接入设备，即ITSP-GW(ITSP网关)，以解决上述问题，实现本发明的目的。所述的ITSP-GW作为企业SIP网络的出口，主要用作本地SIP网络和ITSP的SIP网络间的网关，可以在单独的设备上运行，也可以和企业IP-PBX集成在同一个设备上运行。

此外，ITSP-GW还支持同其他ITSP-GW互连。于是，对于拥有众多分部的大型公司来说，部署在每个分部的ITSP-GW能够把它们互连起来。公司员工既可以通过ITSP和公司外部的IP电话使用者建立通话，也可以不通过ITSP直接和其他分部的同事建立通话。然而从软件实现机制来看，对于本地ITSP-GW而言，远端的ITSP-GW也不过相当于一个特殊的ITSP的SIP服务器，采用的仍然是多ITSP支持的实现方式。

从信令流向的角度看，ITSP-GW所处的位置如图1和图2所示：

也就是说，从信令流向来讲，ITSP-GW连接于各个ITSP与企业内部的IP-PBX之间。而且，如图2所示，对于企业内部的IP-PBX而言，ITSP-GW是它的一个普通终端，遵循它的规格，支持各种内线功能；对于每个ITSP而言，ITSP-GW也是它的一个普通终端，遵循它的规格，如可以作为ITSP A、ITSP B和ITSP C分别对应的终端。

在网络拓扑中，ITSP-GW所处的位置有两种可能。具体为：可以在路由器上运行，或者与路由器分开独立运行，下面将分别进行说明。

当ITSP-GW在路由器上运行时，相应的网络拓扑如图3所示，用户终端(即IP电话)所在的LAN(局域网)通过路由器以及WAN(广域网)与各个ITSP的SIP(会话初始协议)服务器通信，ITSP-GW运行于所述路由器上，从而实现用户终端与多个ITSP的SIP服务器间的通信。

需要说明的是：当ITSP-GW的LAN端为私有IP地址，WAN端为公有IP地址时，需要通过NAT(网络地址转换)进行地址转换；由于ITSP-GW本身可转发所有的SIP消息和RTP包，因此可以支持地址转换功能，也就不需要路由器的NAT功能来协助VoIP(基于IP的语音)的NAT穿越。

在位于多个地点的ITSP-GW互连的情况中，此时异地的ITSP-GW相当于本地ITSP-GW的一个特殊的ITSP服务器。若ITSP和企业之间建有VPN(虚拟专用网)，则ITSP-GW本身不需要拥有公有IP地址时，ITSP-GW就可以和路由器分开运行，相应的网络拓扑结构如图4所示，所述的ITSP-GW基于相应的VPN通道实现用户终端与各个ITSP间的互通；也就是说，对于一个拥有众多分部的大型企业来说，完全可以使各个分部之间通过VPN相连。

为对本发明有进一步理解，下面将结合附图对本发明中相应的ITSP-GW基本结构进行说明。

ITSP-GW主要包括SIP业务处理部分，用于接收SIP终端或ITSP服务器发来的SIP消息，并根据配置的策略对所述的SIP消息进行处理后，通过选择的端口或终端接口发送给ITSP服务器或SIP终端；如图5所示，所述的ITSP-GW的基本结构主要包括：

SIP信令处理部分，媒体处理部分，以及辅助部分，其中：根据SIP协议的规定可知所述的SIP信令处理部分包括SIP协议中规定的SIP传输层模块、SIP事务层模块以及SIP事务用户层模块；所述的媒体处理部分包括媒体中继单元模块；所述的辅助部分包括日志、接口检测等等模块。

所述的SIP传输层和SIP事务处理层在SIP协议中的规定比较明确，由于这两层专注于传输和连接，很少涉及用户逻辑，所以针对不同SIP服务器的主要规格差异在于SIP事务用户层以及媒体处理部分。

从图5可以看出，所述的SIP事务用户层和媒体中继单元，在呼叫时首先识别呼叫涉及的ITSP类型或本地服务器类型，然后分别建立相应的SIP UA模型的实体，来处理向某个服务器发送或从该服务器接收的SIP消息。在ITSP-GW内部建立起来的SIP-UA模型的实体之间通过内部事件进行事件通知。

在图5中，多个远端SIP UA处理模型共同对应一个本地SIP UA模型。远端SIP UA模型负责作为ITSP网络中的一个终端(在SIP用语中就是UA)运行，本地SIP UA模型负责作为本地SIP网络中的一个终端运行。所述SIP UA模型都可以具有一般终端所具有的功能，比如注册、发起呼叫、接收呼叫、收发媒体、结束呼叫、呼叫保留、呼叫转移、检查呼叫是否存活(Keepalive)等等功能。但是如果用户本地SIP网络或某个ITSP SIP网络不支持其中的某种功能，那么通过用户配置，这种功能在具体的SIP UA模型中就不会被激活。

具体采用的事件通知可以有两种实现方法：

一种为每个UA模型都有对外接口函数，另一个UA可以通过调用该接口函数来传递需要交互的数据，函数输入参数就是具体事件类型和事件参数；

另一种为每个UA模型带有一个FIFO(先进先出)的事件队列，一个UA可以把需要传递的事件(一个数据结构，包括事件类型和事件参数)加到另一个UA的事件队列中；

由于在内部采用自定的事件进行交互，而不是转发SIP消息，因此，本发明便可以实现单侧功能屏蔽，因为当本地UA和ITSP UA所支持的功能不相同时，很多消息是不能进行转发的。

本发明中，为了使得用户可以分别与不同的ITSP进行互通，实现相应的业务，首先需要保证用户可以向不同的ITSP注册，具体的实现方法如下：

ITSP-GW启动时或检测到网络接口从Down(去激活)变为Up(激活)时，以及Contact地址发生变化时都会自动进行注册处理，以便告诉ITSP的SIP服务器ITSP-GW当前的实际位置信息，如IP地址和端口号等。

ITSP-GW可以同时作为多个ITSP的SIP UA，根据已设置的ITSP用户帐号，分别向多个ITSP发送REGISTER(注册)请求。注册成功的用户帐号可以生效，并在呼叫时被使用。

由于通常情况下，ITSP-GW所在的物理实体只具有一个连接到公网的物理接口，而且为了节省利用企业所拥有的公网IP地址资源，因此，ITSP-GW针对不同的ITSP使用同一个公网IP地址。这样，只能针对不同ITSP使用不同的本地端口号，才能让后续来自ITSP的SIP消息被发送到相对应的本地端口号，从而识别SIP消息的来源。

因此，在向不同的ITSP服务器注册时，在所述注册消息中的ContactHeader字段中使用不同的端口号。例如：企业当前同时拥有ITSP A的电话号码11111111和ITSP B的电话号码22222222，ITSP-GW的出口IP地址是200.0.0.1，此时可以针对ITSP A使用本地端口号5070，而针对ITSP B使用本地端口号5080。注册时ITSP-GW向ITSP A和ITSP B分别发送以下注册消息：

ITSP-GW向ITSP A发送的注册消息如下：

REGISTER sip:sip.itspA.com SIP/2.0

Via:SIP/2.0/UDP 200.0.0.1:5070；branch＝z9hG4bK9160441A5F78

From:11111111<sip:11111111@sip.itspA.com>；tag＝1928301774

To:11111111<sip:11111111@sip.itspA.com>

Contact:<sip:11111111@200.0.0.1:5070>

Call-ID:17822483385A45F3A17F61DF525D2397@sip.itspA.com

CSeq:12836 REGISTER

Expires:1800

Max-Forwards:70

User-Agent:ITSP-GW

Content-Length:0

ITSP-GW向ITSP B发送的注册消息如下：

REGISTER sip:sip.itspB.com SIP/2.0

Via:SIP/2.0/UDP 200.0.0.1:5080；branch＝z9hG4bK9160690B5956

From:22222222<sip:22222222@sip.itspB.com>；tag＝456248

To:22222222<sip:22222222@sip.itspB.com>

Contact:<sip:22222222@200.0.0.1:5080>

Call-ID:2672246338AA45FDB17FF14F875D9BA@sip.itspB.com

CSeq:12845REGISTER

Expires:1800

Max-Forwards:70

User-Agent:ITSP-GW

Content-Length:0

经过上述注册过程后，在呼叫时便可以进行相应的ITSP的选择了，下面将对具体的ITSP选择处理过程进行说明。

当拥有多个ITSP的线路(用户帐号/电话号码)时，从企业内部向企业外部的一个目标用户发起呼叫时，需要选择使用哪个ITSP的线路来进行呼叫。在ITSP-GW的实现中，对ITSP的选择依赖于从本地接收到的INVITE(请求)消息所带有的信息以及在ITSP-GW上配置的呼叫路径选择表，所述的呼叫路径选择表中保存着用户终端选择各个ITSP的策略信息。

对于本地指定了呼叫号码时，相应的处理过程如下:

如果从本地接收的INVITE消息的From Header(来源头)的username(用户名)部分指定了ITSP端的加入电话号码，并且已针对该号码成功进行了SIP注册，则选择与之相符的ITSP进行呼叫。

对于本地未指定呼叫号码时，则相应的处理过程如下：

从本地接到的INVITE的Request-URI(请求URI)取出对端电话号码，从呼叫路径选择表检索该号码，确定ITSP。

呼叫路径选择表是用户配置的各种呼叫路径规则，每条规则包括“号码匹配条件”和“呼叫路径”；“号码匹配条件”可以是某个模糊表达式或某种算法(比如费用计算)的结果，“呼叫路径”指示当对端电话号码符合该呼叫路径规则的“号码匹配条件”时，需要按该路径进行呼叫；“呼叫路径”包括“使用ITSP-A的线路”，“使用ITSP-B的线路”，“自动选择ITSP”，“呼叫拒绝”等等。

本发明中，对于来电时的ITSP辨别的处理过程如下：

由于向不同的ITSP注册时使用了不同的本地端口号，因此，从ITSP侧来电时，ITSP的SIP服务器会把发起呼叫的INVITE消息发送到ITSP-GW向它注册时所使用的端口号上。在前例中，ITSP A的SIP服务器会把INVITE消息发送到200.0.0.1:5070，而ITSP B的SIP服务器会把INVITE消息发送到200.0.0.1:5080。因此，ITSP-GW通过消息接收的端口号就可以识别出该来电来自哪个ITSP，从而采用该ITSP所指定的SIP规格进行处理。

本发明在具体实现过程中，由于选择使用不同的ITSP，因此相应的消息规格会有所不同，此时需要进行消息的转换处理，具体的处理过程如下：

ITSP-GW在本地SIP服务器(或者终端)和ITSP的SIP服务器(或者终端)之间进行消息转换的目的有两个。

具体的转换过程包括转换地址信息和转换消息规格，如图6所示，其中：

(1)所述的转换地址信息具体为：

本地的SIP服务器并不知道一路外发的呼叫会经由哪个ITSP，也无法知道在外发的SIP消息中应该填写的正确的本地IP地址和本地端口号信息。因此需要ITSP-GW来填写合适的本地信息。

对于本地SIP服务器和ITSP端SIP服务器来说，ITSP-GW分别作为不同的SIP UA运行。在2个UA之间，不直接进行SIP消息的传递，而是相互通知信令事件。例如，将来自本地的来电作为对ITSP端的呼叫要求，或将ITSP端的来电，作为对本地端的呼叫要求进行通知。结果是，ITSP-GW在本地SIP网络和ITSP SIP网络之间进行SIP消息的转换。将SIP消息头的目标IP地址/端口号置换成本地服务器或ITSP端服务器的内容，甚至将呼叫源的IP地址/端口号置换成ITSP-GW的内容。将本地和ITSP双方进行关联，分别生成不同的对话。

(2)所述的转换消息规格，即转换消息格式的过程具体为：

为适应ITSP的SIP规格的不同，本地SIP服务器并不具有处理不同ITSP规格的能力，需要ITSP-GW依据具体会话中对应的ITSP规格来进行SIP消息的校正；

各ITSP的规格差异很多，常见的有：

注册AOR(Address or Record，地址记录)的构成；

本地Contact地址的写法；

注册请求中Request-URI(请求URI)的内容；

主叫时主叫号码的设置以及号码通知/非通知机制；

来电时如何从消息中取出主叫号码以及判断号码通知/非通知的方式；

来电时如何从消息中取出被叫号码；

尽管各家ITSP的规格差异很多，但是只要能够识别出当前呼叫相对应的ITSP，就能够使用适应该ITSP的UA模型进行SIR消息和内部事件的处理。

基于上述地址和消息格式转换处理，本发明可以在ITSP-GW上实现针对媒体数据的中继处理，如图7所示。

在ITSP-GW上，首先在本地端和ITSP端分别打开RTP(实时传输协议)端口，相互中继语音/视频数据

由于不同的ITSP在媒体处理规格上存在差异，因此，在ITSP-GW上需要进行中继处理。例如，在有的ITSP的SIP网络中，呼叫保留时的保留音依赖于发起呼叫保留的终端来生成，有的又依赖于被保留的终端来生成，还有由ITSP的媒体服务器生成保留音的。由于ITSP-GW进行媒体数据中继，因此能够根据不同ITSP的要求来区别对待媒体数据的生成和处理。

也就是说，ITSP-GW要进行单侧功能的屏蔽，而这些功能有的会涉及媒体流的处理，而不仅仅是SIP信令的处理，所以ITSP-GW本身也需要中继媒体数据。

本发明中，在ITSP-GW上中继媒体数据的方式为：如图7所示，需要对接收的RTP包包头做一定的修改，再转发出去。对于承载语音或视频数据的RTP包，包头中的Sequence(序列号)，TimeStamp(时间戳)，以及ssrc(同步源)需要重新生成，其他字段不变。中继SIP消息中，需要将SDP(会话描述协议)部分的IP地址/端口号码置换为ITSP-GW自身的地址/端口号码。保留/转发操作时停止向ITSP端发送语音/视频数据，改为发送自身生成的保留音/保留图像。

本发明中，除了需要在ITSP-GW上进行相应的SIR消息的转换处理外，在所述的ITSP-GW上还需要实现单侧功能屏蔽的功能，这是由于SIP的扩展功能很多，比如Fork(RFC3261)，Session Timer(RFC4028)，PRACK(RFC3262)，REFER(RFC3515)等等。因为不同的ITSP对应的SIP服务器可能支持不同的功能，因此ITSP-GW针对不同的本地或ITSP SIP服务器采用不同的SIP UA模型能够屏蔽本地SIP服务器或ITSP的SIP服务器的某些功能，使它们能够继续保持互通。

下面首先以使用到REFER(提交)消息的呼叫转移功能为例说明。

对于本地的SIP服务器，呼叫转移常常是必备的功能，但是并不是所有ITSP都支持REFER消息。于是当本地发生呼叫转移时，ITSP-GW必须吸收单侧的REFER消息，并且进行必要的媒体处理。

参见图8所示。本地终端1分别和ITSP侧的终端以及本地终端2建立起两路呼叫：呼叫1和呼叫2。

然后本地终端1打算执行呼叫转移，把ITSP终端转移到本地终端2，使这两个终端能够建立呼叫，并且自己退出呼叫。

如图9所示，本地终端1向ITSP-GW发送REFER消息，要求呼叫转移到本地终端2，并且通过REFER消息中的Replaces参数通知它希望结束呼叫2。由于REFER消息不能被ITSP侧处理，因此ITSP-GW不向ITSP终端发送REFER消息，而是自行处理该消息。ITSP-GW向本地终端2发起呼叫建立呼叫3，并且请本地终端2结束呼叫2。此后，本地终端2结束了呼叫2，并且当本地终端1获知呼叫3已经建立后就主动结束了呼叫1。此后ITSP-GW就把呼叫3与ITSP侧的呼叫关联起来，并且在本地终端2和ITSP终端之间转发媒体数据。

由上述应用实例可以看出，ITSP-GW可以根据不同ITSP的规格，由扩展功能针对某些ITSP的相应功能进行屏蔽处理，而针对另一些ITSP的相应功能进行开放。ITSP-GW在本地SIP网络和在ITSP的SIP网络中分别作为独立的SIP UA模型运行，从而能够很好地进行单侧功能屏蔽并且对于不同的功能具有良好的适应性。

下面再举一例对本发明中的媒体中继功能进行说明。有些ITSP要求启用Session Timer(会话定时器)功能，定期发送Re-INVITE(重新申请)消息来监测会话是否还存活。这个功能是基本SIP协议(RFC3261)的一个扩展。但是本地的SIP服务器或其他终端设备可能不采用这种方法或者根本不支持这种方法。在这种情况下，ITSP-GW就要支持单侧的Session Timer功能而屏蔽另一侧的。

如图10所示，会话建立后ITSP-GW定期向ITSP侧发送Re-INVITE消息以保持会话不中断，但是ITSP-GW在本地侧却不执行这样的功能。

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

Claims (10)

1、一种基于SIP支持多ITSP业务的装置，其特征在于，包括：

SIP业务处理部分：用于接收SIP终端或ITSP服务器发来的SIP消息，并根据配置的策略对所述的SIP消息进行处理后，通过选择的ITSP服务器端口或终端接口发送给ITSP服务器或SIP终端。

2、根据权利要求1所述的基于SIP支持多ITSP业务的装置，其特征在于，所述的SIP业务处理部分进一步包括SIP传输层部分、SIP事务层部分、SIP事务用户部分和媒体处理部分，各个部分又分别建立了对应的本地SIP用户代理模型和远端SIP用户代理处理模型，且：

本地SIP用户代理模型：与所述远端SIP用户代理处理模型间通过事件通知机制进行信息的交互，用于接收用户终端发来的SIP消息，并为其选择对应的远端SIP用户代理处理模型对其进行处理，接收远端SIP用户代理处理模型事件通知，并进行相应的处理后与用户终端通信；

一组远端SIP用户代理处理模型：各个模型分别根据本地SIP用户代理模型的事件通知通过对应的ITSP服务器端口与远端ITSP服务器通信，并接收处理ITSP服务器发来的SIP消息，通知本地SIP用户代理模型。

3、根据权利要求2所述的基于SIP支持多ITSP业务的装置，其特征在于，所述的远端SIP用户代理处理模型包括：

注册处理模块:用于将本地地址信息和对应于各个ITSP服务器的本地端口号注册于各个ITSP服务器上；

媒体中继处理模块：位于媒体处理部分，用于对相应的ITSP服务器或用户终端的媒体流进行格式转换处理；

信令处理模块：用于对相应的ITSP服务器或用户终端的对话的信令进行格式转换处理。

4、一种基于SIP支持多ITSP业务的系统，其特征在于，包括如权利要求1-3中任一所述的基于SIP支持多ITSP业务的装置，一组用户终端和一组ITSP服务器，所述的一组用户终端通过所述装置与一组ITSP服务器连接。

5、根据权利要求4所述的基于SIP支持多ITSP业务的系统，其特征在于，所述的一组用户终端还通过企业内部IP电话交换机与所述的装置连接，且所述的装置可以内置于网络设备中或单独设置。

6、一种基于SIP支持多ITSP业务的实现方法，该方法应用的系统包括SIP终端和多个ITSP服务器，所述的SIP终端通过如权利要求1-3中任一所述的装置与所述ITSP服务器连接，其特征在于，包括：

A、在上行方向，所述装置为SIP终端发来的SIP消息选择相应的ITSP服务器，并将SIP消息以该ITSP服务器规定的格式进行处理，之后，通过为该ITSP服务器分配的本地端口发送给该ITSP服务器；

B、在下行方向，所述装置接收ITSP服务器发来的SIP消息，根据接收到的SIP消息的端口信息确定该ITSP服务器的身份信息，并将SIP消息以SIP终端或企业内部IP电话交换机要求的格式进行处理，然后发送给SIP终端或IP电话交换机。

7、根据权利要求6所述的基于SIP支持多ITSP业务的实现方法，其特征在于，所述的步骤A包括：

A1、当所述装置接收SIP终端发来的SIP消息时，根据SIP消息中来源From头字段和请求U RI信息及保存的策略信息确定对应的ITSP服务器；

A2、将所述的SIP消息通过ITSP服务器对应的端口发送给该ITSP服务器。

8、根据权利要求6所述的基于SIP支持多ITSP业务的实现方法，其特征在于，所述的步骤B包括：

B1、当所述装置接收ITSP服务器发来的SIP消息时，根据SIP消息的目的端口号确定发送该SIP消息的ITSP服务器信息；

B2、将所述的SIP消息发送给该SIP终端。

9、根据权利要求8所述的基于SIP支持多ITSP业务的实现方法，其特征在于，该方法还包括：

C、由所述的装置中的独立设置的SIP用户代理处理模型屏蔽SIP终端与远端ITSP服务器间的差异，所述SIP用户代理处理模型包括本地SIP用户代理处理模型和远端SIP用户代理处理模型。

10、根据权利要求9所述的基于SIP支持多ITSP业务的实现方法，其特征在于，所述的步骤C包括：

由所述装置中的SIP用户代理处理模型对SIP终端与所述的ITSP服务器之间交互的SIP消息进行SIP消息格式及地址信息的转换处理；本地SIP用户代理处理模型可以屏蔽SIP终端支持但ITSP服务器不支持的功能，远端SIP用户代理处理模型可以屏蔽ITSP服务器支持但SIP终端不支持的功能。

Images