CN100550884C - 基于重试机制的业务过程中对sip协议请求的处理方法 - Google Patents

Abstract

本发明公开了一种基于重试机制的业务过程中SIP协议请求的处理方法，该方法中，执行重试功能的SIP节点接收到该SIP会话请求后，按照重试规则向一个后向节点转发该SIP会话请求，并针对该请求启动SIP协议定时器；若执行重试功能的SIP节点出现了当前请求失败的情况，则按照重试规则向下一个后向节点转发该SIP会话请求，针对该请求启动SIP协议定时器，并向前向节点发送重置定时器通知；前向节点根据该通知重启SIP协议定时器，并继续本次业务。应用本发明能够减少SIP协议定时器超时处理对基于重试机制的业务的影响，保证此类业务的正常运行。

Description

基于重试机制的业务过程中对SIP协议请求的处理方法

技术领域

本发明涉及以SIP协议为会话控制协议的系统业务过程中，对SIP协议请求的处理技术，特别涉及一种基于重试机制的业务过程中对SIP协议请求的处理方法。

背景技术

随着移动通讯技术的发展，单一的语音通信方式不能完全满足用户的需要，而需要全新的多媒体通信方式。这种多媒体通信不仅仅是简单的视音频通信，还包括即时消息、同址浏览、协同工作、流媒体等等业务，特别是新通信方式和传统语音融合的业务。在众多的基于Internet和电信网络融合会话控制系统中，大多数都采用初始会话协议(SIP)作为会话控制协议，例如IP多媒体子系统(IMS)、NGN网络大都采用了SIP协议。

SIP协议是由Internet工程任务组(IETF)制订的多媒体通信系统框架协议之一，是用于建立、改变或结束多媒体会话的应用层协议。由于SIP协议基于公开的Internet标准，在语音与数据业务的结合及互通方面具有天然优势，能跨越媒体和设备实现呼叫控制，支持丰富的媒体格式。

采用SIP协议作为会话控制协议的会话控制系统中，SIP协议对于请求消息有统一的超时处理，以下以IMS系统为例，介绍SIP协议对于请求消息的超时处理方法。

3GPP在分组承载网基础上引入的全IP业务网络架构的IMS系统，目标是按照个性化用户数据，屏蔽用户接入方式，控制业务能力的开放程度，提供多媒体的通信体验。

IMS中主要的功能实体包括控制用户注册、会话控制等功能的呼叫控制实体(CSCF)、提供各种业务逻辑控制功能的应用服务器(AS)、集中管理用户签约数据的归属用户服务器(HSS)以及用于实现与电路交换网互通的MGCF/IM-MGW。

根据在网络中的功能，CSCF分为：当前所在地代理节点(P-CSCF)、注册地的归属域服务节点(S-CSCF)以及查询节点(I-CSCF)。

用户(UE)通过P-CSCF接入IMS，会话和业务触发控制及与AS的业务控制交互则由其注册地的S-CSCF完成；IMS采用SIP协议作为应用层交互信令，终端和CSCF之间、CSCF之间、CSCF与AS之间接口协议均为SIP协议。

其中，S-CSCF在IMS核心网中处于核心的控制地位，负责对UE的注册鉴权和会话控制，执行针对主叫端及被叫端IMS用户的基本会话路由功能，并根据用户签约的IMS触发规则，在条件满足时进行到AS的增值业务路由触发及业务控制交互。

I-CSCF则主要用于实现两个网络间的互通。

参见图1，图1为简化的IMS系统连接结构示意图。图1中IMS系统仅示出了两个S-CSCF。下面以UE11呼叫UE21的过程，来说明该系统中各实体的连接关系。该呼叫过程包括：

步骤1，UE11通过P-CSCF1向该UE11注册地的S-CSCF1发送对UE21的会话请求。

步骤2，S-CSCF1判断主叫用户是否已注册，如未注册则拒绝会话请求；如已注册则执行步骤3。

步骤3，S-CSCF1依据来自U11的SIP会话消息内容，对主叫SIP用户所签约的IMS多条AS触发规则进行按优先级的顺序匹配，匹配成功的情况下将SIP会话路由到规则指定的SIP AS业务平台，以触发IMS用户相关增值业务逻辑的执行，并跳转到步骤4；匹配不成功或剩余触发规则为空情况下，则跳转到步骤5。

步骤4，S-CSCF1等待从SIP AS业务平台返回的SIP会话消息，依据该SIP会话消息内容，该SIP会话消息可能修改过，对主叫SIP用户剩余的其他未匹配AS签约触发规则进行按优先级的顺序匹配，匹配成功的情况下将SIP会话路由到规则指定的SIP AS业务平台，并返回执行本步骤，等待从规则指定的SIP AS业务平台返回的SIP会话消息。

匹配不成功或剩余触发规则为空的情况下，则跳转到步骤5。如果没有从SIP AS业务平台返回消息，则S-CSCF1按照缺省处理(default handling)中的规则，决定是继续对剩余的其他未匹配AS签约触发规则进行按优先级的顺序触发，还是结束会话。

步骤5，当目的网络与主叫网络属同一网络时，S-CSCF1依据被叫SIP用户地址信息通过DNS域名解析获得目的网络运营商地址信息，并将SIP会话消息转发到目的网络的I-CSCF2。当目的网络与主叫网络不属于同一网络且主叫网络要求网络拓扑隐藏时，将会话消息先转至主叫网络I-CSCF1完成拓扑隐藏处理后再转发到目的网络的I-CSCF2。

步骤6，S-CSCF1对被叫用户进行分析，若分析被叫为非IMS的SIP用户或H.323用户，也就是没有在HSS(图1中未示出)未注册，则根据运营策略，转发SIP消息到IMS媒体网关功能(I-MGCF)(图1中未示出)，以完成其他非IMS网络的SIP Server的协议互通。

步骤7，目的网络的I-CSCF2将会话消息转发给被叫UE21注册地的S-CSCF2。

步骤8，S-CSCF2判断被叫用户是否已注册，如未注册则直接从HSS通过Diameter协议下载相关IMS基本签约数据。

步骤9，S-CSCF2依据来自目的网络I-CSCF2的SIP会话消息内容，对被叫SIP用户所签约的IMS多条AS触发规则进行按优先级的顺序匹配，在匹配成功的情况下将SIP会话路由到签约规则指定的SIP AS业务平台地址，以触发IMS用户相关增值业务逻辑的执行，并跳转到步骤10；在匹配不成功或剩余触发规则为空的情况下，则跳转到步骤11。

步骤10，S-CSCF2等待从SIP AS业务平台返回的SIP会话消息，并判断返回的SIP会话消息内容的Request URL地址是否修改过。若未修改过，则对被叫SIP用户剩余的其他未匹配AS签约触发规则进行按优先级的顺序匹配，在匹配成功的情况下将SIP会话路由到签约规则指定的SIP AS业务平台地址，并返回执行本步骤，等待从规则指定的SIP AS业务平台返回的SIP会话消息。在匹配不成功或剩余触发规则为空的情况下，则跳转到步骤11。如果没有从SIP AS业务平台返回消息，则S-CSCF2按照″default handling″中的规则决定是继续对剩余的其他未匹配AS签约触发规则进行按优先级的顺序触发，还是结束会话。

若SIP会话消息内容的Request URL地址修改过，则跳转到上述的步骤5，根据新的被叫URL地址进行到被叫网络I-CSCF的寻址。

步骤11，S-CSCF2依据被叫IMS用户注册过程中在S-CSCF2中记录的P-CSCF2地址进行到被叫用户UE21漫游所在的P-CSCF2的会话路由。

步骤12，P-CSCF2向UE21发送会话请求。

IMS网络中业务触发是基于存储在HSS中并在用户注册时下载到为用户分配的S-CSCF实体的用户签约数据中的初始过滤准则(iFC)检测完成的。iFC按照不同优先级定义了业务触发的条件和目的AS，S-CSCF将收到的来自或发往所服务用户的业务请求消息与iFC中的业务触发条件相匹配，匹配成功后则将该业务请求消息发送往匹配成功的iFC所指定的AS，否则所触发的AS将请求消息返回来后，S-CSCF继续进行较低优先级iFC的检测，在所有iFC检测完成后，S-CSCF根据业务请求中的目地标识将该业务请求发往下一个网络节点。

其中，iFC主要包括：

Application Server Address

AS priority

Default Handling

Subscribed Media

Trigger Points

Optional Service Information

上述步骤1～步骤6为主叫流程(MO流程)；步骤7～步骤12为被叫流程(MT流程)。

S-CSCF在MT流程中，会对SIP会话请求进行转发。S-CSCF可以按照任何次序来处理目标地址集，既可以对于多个目标地址采用串行处理的方法，使得一个目标地址处理完成后再开始下一个地址的处理，也可以并行处理所有的目标地址。这种串行处理的方法称为串行Fork。

图1所示的IMS系统中，各个采用SIP协议的网络实体中对SIP请求超时处理方法相同的，该方法主要包括(这里只介绍与本发明相关的SIP消息超时的处理)：

SIP请求可以分为会话连接请求(Invite请求)和非Invite请求。

对于Invite请求消息，SIP网络实体将该请求消息转发给其后向节点时，对于每个转发消息，设置三个定时器进行超时处理：TimerA来处理Invite请求的重发、TimerB来处理无法得到任何响应的情况、TimerC用来处理无法得到最终响应的情况。这三个定时器的定时时间，是在业务开始前预先配置好的。

举例来说：

假如一SIP网络实体将Invite请求消息转发给其后向节点，则同时启动TimerA、TimerB以及TimerC。

当该SIP网络实体收到后向节点返回的Invite请求的临时响应1XX时，停止TimerA和TimerB，并重启TimerC。当该SIP网络实体收到其后向节点返回的Invite请求的最终响应2XX-6XX时，停止TimerC。

如果在TimerA定时时间内没有收到任何响应，则TimerA会超时如果在TimerB定时时间内没有收到任何响应，则TimerB会超时，本发明对TimerA和TimerB的超时处理没有改进，这里不再详细说明。

如果在TimerC定时时间内没有收到最终响应，则TimerC会超时。一旦TimerC超时，通常有两种超时处理的方法：

第一种：终结Invite请求的客户端事务，释放实例，从而会话过程结束。

这种处理方法对于多次触发AS业务、串行Fork业务、序前转业务等基于重试机制的业务会出现下述情况：一旦S-CSCF对一次触发AS业务的TimerC超时或一个执行串行Fork业务的被叫用户的TimerC超时、或执行顺序前转业务的AS的TimerC超时，会话就被结束。也就是说，在没有完成对所有需要触发AS业务或没有向所有执行串行Fork业务的被叫用户发送会话请求前，或没有完成顺序前转业务前，会话被异常结束。

第二种：根据当前的业务情况动态的增加TimerC的超时时长，重启TimerC。但这样会导致其他业务的TimerC超时释放的处理，并且一味的重启TimerC，造成多次触发AS业务、串行Fork业务或顺序前转业务等处理时间较长的业务会话吊死。

对非Invite请求，SIP网络实体将该请求转发给其后向节点时，对于每个转发消息，启动两个定时器：启动TimerE用于非Invite请求的重发，启动TimerF用于处理没有收到任何响应或没有收到最终响应的情况。这两个定时器的定时时间，也是在业务开始前预先配置好的。

举例来说：

假如一SIP网络实体将非Invite请求消息转发给其后向节点，则同时启动TimerE、TimerF。

当该SIP网络实体收到其后向节点返回的临时响应1XX后，改变TimerE的超时时长。

当该SIP网络实体收到其后向节点返回的最终响应2XX-6XX时，停止TimerE和TimerF。

当该SIP网络实体在TimerF定时时间内，没有收到最终响应2XX-6XX时，TimerF超时。

一旦TimerF超时，则终结非Invite请求的客户端事务，释放实例，从而会话结束。同样，这种处理方法对于S-CSCF多次触发AS业务、串行Fork业务或AS执行顺序前转业务等基于重试机制的业务也会出现下述情况：在没有完成对所有需要触发AS业务或没有向所有执行串行Fork业务的被叫用户发送会话请求前，或执行顺序前转业务的AS未完成前转业务前，会话被异常结束。

总之，目前SIP协议的对消息的超时处理，会影响基于重试机制的业务的正常运行，导致业务不可用。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于重试机制的业务过程中SIP协议消息的处理方法，减少SIP协议定时器超时处理对基于重试机制的业务的影响。

为达到上述发明目的，本发明提供了一种基于重试机制的业务过程中SIP协议请求的处理方法，该方法包括以下步骤：

A、前向节点向执行重试功能的SIP节点发送SIP会话请求，并针对该请求启动第一SIP协议定时器；

B、执行重试功能的SIP节点接收到该SIP会话请求后，按照重试规则向一个后向节点转发该SIP会话请求，并针对该请求启动第二SIP协议定时器；所述重试规则包括：用户签约的初始过滤准则(iFC)多条应用服务器(AS)触发规则、缺省处理(default handling)中的规则、目标地址集和排序原则或被叫用户的签约数据中的前转顺序；

C、若执行重试功能的SIP节点出现了当前请求失败的情况，则按照重试规则向下一个后向节点转发该SIP会话请求，针对该请求重启第二SIP协议定时器，并向前向节点发送重置定时器通知；若没有出现当前请求失败的情况，则按SIP协议流程继续执行该业务；

D、返回执行步骤C，直到按照重试规则执行结束；

E、每个前向节点在每次接收到重置定时器通知时，向其前一个前向节点前传该通知，并重启第一SIP协议定时器；继续该业务。

其中，所述的当前请求失败的情况可以为：接收到后向节点返回的SIP会话失败响应，或在第二SIP协议定时器超时没有收到后向节点返回的SIP最终会话响应。

步骤C所述向前向节点发送重置定时器通知的方法可以为：

向前向节点发送重置定时器的临时响应。

所述临时响应可以为SIP协议中规定的临时响应，或重新定义的SIP临时响应。

所述前向节点发送重置定时器通知的方法可以为：

先生成一个目的标识To tag，将该To tag加入到重置定时器的临时响应中，再将重置定时器的临时响应发送给前向节点；或直接将重置定时器的临时响应发送给前向节点。

若临时响应中包含To tag，则所述步骤E中，在重启第一SIP协议定时器前，将临时响应中包含To tag与发送的SIP会话请求中包含的To tag进行比较，如果不同，则按照协议规定，重新创建一个会话，将该会话与原会话相联系。

执行重试功能的SIP节点作为背靠背用户代理B2BUA时，其为重置定时器的临时响应生成一个To Tag，并且该会话中后续所有的响应都使用这个To Tag；

执行重试功能的SIP节点作为代理服务器PROXY时，其为重置定时器的临时响应生成一个To Tag，并且该会话中其后续构造的临时响应都使用这个To Tag。

所述向前向节点发送重置定时器通知的方法可以为：

若前向节点发送的是Invite请求，则采用协议规定的可选标志100Rel和定义临时响应的应答PRACK机制，向前向节点发送重置定时器的可靠临时响应；

若前向节点发送的非Invite请求，则采用协议规定的客户端事务的重传机制，向前向节点发送重置定时器的可靠临时响应。

对于非Invite请求：如果重用已有的临时响应，则在临时响应中增加重置定时器标识后，将该临时响应发送给前向节点；

所述步骤E进一步包括：前向节点收到临时响应后，判断其中是否包含重置定时器标识，根据包含该标识的临行响应，重启所述第一SIP协议定时器；

如果用新定义的临时响应，前向节点收到该临时响应时，先判断是否为上述新定义的临时响应，根据新定义的临时响应，重启所述第一SIP协议定时器。

所述的基于重试机制的业务为IMS系统中的多次触发AS业务时，所述执行重试功能的SIP节点可以为主叫用户或被叫用户的注册地的归属域服务节点S-CSCF。

所述的基于重试机制的业务为IMS系统中的串行Fork业务时，所述执行重试功能的SIP节点可以为被叫用户的注册地的S-CSCF。

所述的基于重试机制的业务为IMS系统中的顺序前转业务时，所述执行重试功能的SIP节点为目标网络的应用服务器AS。

由上述的技术方案可见，本发明的这种基于重试机制的业务过程中SIP协议消息的处理方法，执行重试功能的SIP节点在重试过程中，出现当前请求失败的情况下，通知前向节点重置SIP协议定时器，并继续本次业务。这样，就防止了会话被中途结束或会话被吊死，从而减少了SIP协议定时器超时处理对基于重试机制的业务的影响，保证了此类业务的正常运行。

附图说明

图1为简化的IMS系统连接结构示意图；

图2为本发明第一较佳实施例的流程图；

图3为本发明第二较佳实施例的流程图；

图4为本发明第三较佳实施例的流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图及具体实施例对本发明作进一步地详细描述。

本发明的这种基于重试机制的业务过程中SIP协议消息的处理方法，执行重试功能的SIP节点在重试过程中，出现当前请求失败的情况下，通知前向节点重置SIP协议定时器，并继续本次业务。

本发明中所述的当前请求失败的情况可以是：在SIP定时器定时期间没有收到后向节点返回的最终响应，或收到后向节点返回的失败的最终响应。

以下举三个较佳实施例对本发明进行详细说明。

第一较佳实施例：

本实施例是在IMS系统中，S-CSCF多次触发AS业务过程中，出现定时器超时情况的处理过程。参见图2，图2为本发明第一较佳实施例的流程图。该流程包括以下步骤：

步骤201～202，相关的前向节点向本节点S-CSCF发送SIP会话请求消息，并启动包含TimerC(Invite请求)或TimerF(非Invite请求)的相关协议定时器。

步骤203，本节点S-CSCF根据SIP会话消息内容，对用户所签约的iFC多条AS触发规则进行按优先级的顺序匹配。假设本实施例与一条触发规则匹配成功，该规则指定的后向节点为AS1。

步骤204～205，S-CSCF向AS1发送SIP会话请求，将SIP会话路由到后向节点AS1的业务平台，以触发IMS用户相关增值业务逻辑的执行，并启动包含TimerC(Invite请求)或TimerF(非Invite请求)等相关SIP协议定时器。

本实施例中，假设在S-CSCF启动的TimerC或TimerF时间内，没有收到AS1的触发响应，即TimerC或TimerF超时，则执行步骤206。

步骤206，S-CSCF按照″default handling″中的规则决定是继续对剩余的其他未匹配AS签约触发规则进行按优先级的顺序触发。假设本实施例为继续进行顺序触发，假设按顺序选择下一个AS为后向节点AS2。

现有技术中已经说明：IMS网络中业务触发是基于iFC检测完成的，iFC在用户注册时已下载到为用户分配的S-CSCF实体。

步骤207～210，S-CSCF向相关的前向节点发送重置定时器通知，相关的前向节点根据该通知，重启自身的TimerC或TimerF。同时，S-CSCF向后向节点AS发送SIP会话请求，启动新的TimerC或TimerF。

此时，当前节点S-CSCF可充当B2BUA或者PROXY的角色，并且该业务需要继续向其他后向节点发出SIP请求，继续业务处理，因此，本发明中不将超时的响应或失败的最终响应发送给前向节点，而是通知前向节点重置定时器。

S-CSCF可以在定时器超时或收到失败的响应等请求失败的情况下，通知前向节点重置定时器。S-CSCF可以采用如下方式通知前向节点重置定时器：构造临时响应1XX(非100)，回传给前向节点。构造临时响应时，该临时响应中可以携带To tag，对RFC2543协议也可以不携带To tag。

在携带To tag的情况下，To Tag的设置会根据当前节点角色的不同分别处理：

A、B2BUA：为当前临时响应生成一个To Tag，并且后续所有的响应都使用这个To Tag。

B、PROXY：为当前临时响应生成一个To Tag，并且后续的当前节点构造的临时响应都使用这个To Tag，而其他后向节点发送来的响应，不改变To tag，正常处理。

另外，根据协议规定：当S-CSCF向前向节点转发后向节点发送来的其他响应后，如果其中的To Tag不同，前向节点会对当前会话(Dialog1)进行复制操作。具体点说就是：前向节点针对To Tag不同的响应，重新创建Dialog2，并与初始请求的Dialog1相联系。当前向节点收到最终响应后，Dialog2正常处理。而Dialog1最终会因为没有收到最终响应而超时，释放相应资源，不会影响正常进行的业务。

本发明中提到的Dialog、B2BUA、PROXY、Fork等相关细节可参考协议RFC3261，本发明对这些没有改动。

本实施例中，通知前向节点重置定时器的具体方法为：

1、对于Invite请求，可以重用已有的临时响应或定义新的临时响应。

(a)重用已有的临时响应时，虽然前向节点的TimerC收到任何临时响应都会重启，但需要选取不影响原会话流程状态的临时响应。

(b)定义新的临时响应时，其他不支持该临时响应的节点的SIP协议栈的应用层的可以采用丢弃或前传等缺省处理，比如UA可以采用丢弃处理，PROXY则采用前传处理。

当前向节点收到该临时响应时，重启TimerC，其他前向节点的处理依此类推，不会造成超时释放会话，业务可继续进行。

为了保证该临时响应的可靠传输，本实施例还运用了“100rel”可选标志和定义临时响应的应答PRACK机制，具体细节与RFC 3262协议规定相同。

2、对于非Invite请求，也可以重用已有的临时响应或定义新的临时响应。

(a)重用已有的临时响应，则在临时响应中增加重置定时器标识的特殊标识来区分原有临时响应的处理，对带有特殊标识的重用的已有临时响应增加重启TimerF的处理。前向节点收到临时响应时，先判断其中是否包含上述的特殊标识，如果有则重启TimerF，否则为普通临时响应，按原有流程进行处理。

(b)定义新的临时响应时，非Invite请求的TimerF在收到已有的临时响应后，不会重启。前向节点收到临时响应时，先判断是否为上述新的临时响应，区分其他已有的临时响应，如果是新的临时响应则进行重启TimerF的处理；否则为普通临时响应，按原有流程进行处理。判断是否为新临时响应的方法很简单，有多种形式，比如：新临时响应中使用专用符号来标识，通过判断是否包含该标识来判断，也可以通过预先记录哪个是新的临时响应，收到临时响应后与该记录进行比较来判断。

其他不支持该临时响应的节点的SIP协议栈的应用层可以采用丢弃或前传等缺省处理，比如UA可以采用丢弃处理，PROXY则采用前传处理。

当前向节点收到该临时响应时，重启TimerF，其他前向节点的处理依此类推，不会造成超时释放会话，业务可继续进行。

为了保证该临时响应的可靠传输，本实施例采用了RFC 3261协议中，非Invite请求的客户端事务的重传机制，来传输该用于通知前向节点重置定时器的临时响应。

步骤211，本实施例中，假设后向节点AS2向S-CSCF返回了SIP触发成功响应。

步骤212，S-CSCF清除为该SIP请求启动的TimerC或TimerF。

假设当前应用中S-CSCF只需收到一个SIP触发成功响应就结束AS触发，则执行步骤213和214。

步骤213，S-CSCF向相关的前向节点返回SIP最终响应。

步骤214，S-CSCF向其他相关后向节点发送SIP会话请求，以继续后续流程。

图2中省略了其他与本发明无关的流程，应用本发明时其他流程可以改变也可以不改变。

本实施例中，AS的触发流程是按照AS作为代理服务器(PROXY)的业务流程描述的，但本发明不仅适用于AS作为代理服务器的业务流程，也适用于AS作为B2BUA的业务触发流程。

本实施例的处理流程可以应用在主叫流程中，也可以应用在被叫流程中。本实施例中所提到的相关的前向节点，不是单指S-CSCF的前一个实体，指其所有的相关前向节点。在实际应用中，重置定时器通知发送给前一个实体后，继续向再前一个实体前传该通知，该通知会前传给所有S-CSCF的相关前向节点，每个前向节点每次收到重置通知后，都会做上述的处理。

第二较佳实施例：

本实施例是在IMS系统中，被叫S-CSCF执行串行Fork业务过程中，出现定时器超时和接收到失败响应情况的处理过程。参见图3，图3为本发明第二较佳实施例的流程图。(为了描述直观，图3中省略了本节点被叫S-CSCF到UE之间的各中间节点)该流程包括以下步骤：

步骤301～302，相关的前向节点向本节点被叫S-CSCF发送SIP会话请求消息，并启动包含TimerC(Invite请求)或TimerF(非Invite请求)等相关SIP协议定时器。

步骤303，被叫S-CSCF收到SIP会话请求后，根据目标地址集和排序原则，依次选择目标地址。假设，本实施例中目标地址的顺序为UE1、UE2、UE3。

步骤304～305，被叫S-CSCF向UE1发送SIP会话请求，对UE1发起串行Fork；并启动包含TimerC(Invite请求)或TimerF(非Invite请求)的相关协议定时器。

本实施例中，假设在S-CSCF启动的TimerC或TimerF时间内，没有收到AS1的返回响应，即TimerC或TimerF超时，则执行步骤306。

步骤306，被叫S-CSCF按照目标地址集的顺序，继续选择剩余的目标地址。

步骤307～310，被叫S-CSCF向相关的前向节点发送重置定时器通知，相关的前向节点根据该通知，重启自身的TimerC或TimerF。同时，被叫S-CSCF向后向节点UE2发送SIP会话请求，对UE2发起串行Fork；并启动新的TimerC或TimerF。

步骤311，本实施例中，假设后向节点UE2向被叫S-CSCF返回了SIP失败响应。

步骤312，被叫S-CSCF按照目标地址集的顺序，继续选择剩余的目标地址。

步骤313～316，被叫S-CSCF向相关的前向节点发送重置定时器通知，相关的前向节点根据该通知，重启自身的TimerC或TimerF。同时，被叫S-CSCF向后向节点UE3发送SIP会话请求，对UE3发起串行Fork；并启动新的TimerC或TimerF。

步骤317，本实施例中，假设后向节点UE3向被叫S-CSCF返回了SIP成功响应。

步骤318，被叫S-CSCF，清除TimerC或TimerF，并向相关的前向节点返回SIP成功响应。

如果在步骤317，UE3也返回了SIP失败响应，根据目标地址集，所有UE都已被发起过串行Fork，则在步骤318中，被叫S-CSCF向相关的前向节点返回SIP失败响应。

本实施例中所提到的相关的前向节点，不是单指被叫S-CSCF的前一个实体，指被叫S-CSCF所有的相关前向节点。在实际应用中，重置定时器通知发送给前一个实体后，继续向再前一个实体前传该通知，该通知会前传给所有被叫S-CSCF相关的前向节点，每个前向节点每次收到重置通知后，都会做上述的处理。

第三较佳实施例：

本实施例是在IMS系统中，AS实现用户的顺序前转业务过程中，出现定时器超时和接收到失败响应情况的处理过程。参见图4，图4为本发明第三较佳实施例的流程图。(为了描述直观，图4中省略了本节点AS与S-CSCF之间的消息流程)该流程包括以下步骤：

步骤401～402，相关的前向节点向本节点AS发送SIP会话请求消息，并启动包含TimerC(Invite请求)的相关SIP协议定时器。

步骤403，AS收到SIP会话请求后，根据被叫用户的签约数据，发现了该用户签约了前转业务。假设，该被叫用户的前转顺序为UE1、UE2、UE3。

步骤404～405，AS向后向节点UE1发送SIP会话请求，并启动包含TimerC等相关SIP协议定时器。

本实施例中，假设在AS启动的TimerC时间内，没有收到UE1的返回响应，即TimerC超时，则执行步骤406。

步骤406，AS按照前转的顺序，选择UE2。

步骤407～410，AS向相关的前向节点发送重置定时器通知，相关的前向节点根据该通知，重启自身的TimerC。同时，AS向后向节点UE2发送SIP会话请求，并启动新的TimerC。

步骤411，本实施例中，假设后向节点UE2由于用户忙等原因，向AS返回了SIP失败响应。

步骤412，AS按照前转的顺序，选择后向节点UE3。

步骤413～416，AS向相关的前向节点发送重置定时器通知，相关的前向节点根据该通知，重启自身的TimerC。同时，AS向后向节点UE3发送SIP会话请求，并启动新的TimerC。

步骤417，本实施例中，假设后向节点UE3向AS返回了SIP成功响应。

步骤418，AS清除TimerC，向相关的前向节点返回SIP成功响应。

如果在步骤417，UE3也返回了SIP失败响应，根据前转顺序，所有UE都已被前转，则在步骤418中，AS向相关的前向节点返回SIP失败响应。

本实施例的处理流程应用在被叫流程中。本实施例中所提到的相关的前向节点，不是单指AS的前一个实体，指AS所有的相关前向节点。在实际应用中，重置定时器通知发送给前一个实体后，继续向再前一个实体前传该通知，该通知会前传给所有AS相关的前向节点，每个前向节点每次收到重置通知后，都会做上述的处理。

上述实施例二、实施例三中，被叫S-CSCF或AS向相关的前向节点发送重置定时器通知的方法和过程与图2中完全相同，这里不再赘述。

上述三个实施例都是IMS系统中的应用实例，本发明不仅适合IMS系统，也适合NGN等其他以SIP协议为会话控制协议的系统。

由上述的实施例可见，本发明的这种基于重试机制的业务过程中SIP协议消息的处理方法，解决了基于重试机制的业务由于处理时间过长所引发的SIP协议栈定时器超时的问题，解决了SIP协议的超时机制与处理时间过长的业务之间的矛盾，解决了SIP协议与基于该协议的应用中的相关业务的冲突。为利用灵活的SIP协议向用户提供更为丰富的业务创造了条件。

Claims (11)

1、一种基于重试机制的业务过程中SIP协议请求的处理方法，其特征在于，该方法包括：

A、前向节点向执行重试功能的SIP节点发送SIP会话请求，并针对该请求启动第一SIP协议定时器；

B、执行重试功能的SIP节点接收到该SIP会话请求后，按照重试规则向一个后向节点转发该SIP会话请求，并针对该请求启动第二SIP协议定时器；所述重试规则包括：用户签约的初始过滤准则(iFC)多条应用服务器(AS)触发规则、缺省处理(default handling)中的规则、目标地址集和排序原则或被叫用户的签约数据中的前转顺序；

C、若执行重试功能的SIP节点出现了当前请求失败的情况，则按照重试规则向下一个后向节点转发该SIP会话请求，针对该请求重启第二SIP协议定时器，并向前向节点发送重置定时器通知；若没有出现当前请求失败的情况，则按SIP协议流程继续执行该业务；

D、返回执行步骤C，直到按照重试规则执行结束；

E、每个前向节点在每次接收到重置定时器通知时，向其前一个前向节点前传该通知，并重启第一SIP协议定时器；继续该业务。

2、如权利要求1所述的处理方法，其特征在于，所述的当前请求失败的情况为：接收到后向节点返回的SIP会话失败响应，或在第二SIP协议定时器超时没有收到后向节点返回的SIP最终会话响应。

3、如权利要求1所述的处理方法，其特征在于，步骤C所述向前向节点发送重置定时器通知的方法为：

向前向节点发送重置定时器的临时响应；所述临时响应为SIP协议中规定的临时响应，或重新定义的SIP临时响应。

4、如权利要求3所述的处理方法，其特征在于，所述前向节点发送重置定时器通知的方法为：

先生成一个To tag，将该To tag加入到重置定时器的临时响应中，再将重置定时器的临时响应发送给前向节点；或直接将重置定时器的临时响应发送给前向节点。

5、如权利要求4所述的处理方法，其特征在于，若临时响应中包含目的标识To tag，则所述步骤E中，在重启第一SIP协议定时器前，将临时响应中包含To tag与发送的SIP会话请求中包含的To tag进行比较，如果不同，则按照协议规定，重新创建一个会话，将该会话与原会话相联系。

6、如权利要求4所述的处理方法，其特征在于：执行重试功能的SIP节点作为背靠背用户代理B2BUA时，其为重置定时器的临时响应生成一个To Tag，并且该会话中后续所有的响应都使用这个To Tag；

执行重试功能的SIP节点作为代理服务器PROXY时，其为重置定时器的临时响应生成一个To Tag，并且该会话中其后续构造的临时响应都使用这个To Tag。

7、如权利要求3所述的处理方法，其特征在于，所述向前向节点发送重置定时器通知的方法为：

若前向节点发送的是Invite请求，则采用协议规定的可选标志100Rel和定义临时响应的应答PRACK机制，向前向节点发送重置定时器的可靠临时响应；

若前向节点发送的非Invite请求，则采用协议规定的客户端事务的重传机制，向前向节点发送重置定时器的可靠临时响应。

8、如权利要求3所述的处理方法，其特征在于，对于非Invite请求：如果重用已有的临时响应，则在临时响应中增加重置定时器标识后，将该临时响应发送给前向节点；

所述步骤E进一步包括：前向节点收到临时响应后，判断其中是否包含重置定时器标识，根据包含该标识的临行响应，重启所述第一SIP协议定时器；

如果用新定义的临时响应，前向节点收到该临时响应时，先判断是否为上述新定义的临时响应，根据新定义的临时响应，重启所述第一SIP协议定时器。

9、如权利要求1所述的处理方法，其特征在于：所述的基于重试机制的业务为IP多媒体子系统中的多次触发应用服务器AS业务时，所述执行重试功能的SIP节点为主叫用户或被叫用户的注册地的归属域服务节点S-CSCF。

10、如权利要求1所述的处理方法，其特征在于：所述的基于重试机制的业务为IP多媒体子系统中的串行Fork业务时，所述执行重试功能的SIP节点为被叫用户的注册地的S-CSCF。

11、如权利要求1所述的处理方法，其特征在于：所述的基于重试机制的业务为IP多媒体子系统中的顺序前转业务时，所述执行重试功能的SIP节点为目标网络的应用服务器AS。

Images