CN101448226B

CN101448226B - 一种前转业务的识别方法和设备

Info

Publication number: CN101448226B
Application number: CN2008101879701A
Authority: CN
Inventors: 雷娜; 王瞬迪
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2008-12-31
Filing date: 2008-12-31
Publication date: 2011-02-09
Anticipated expiration: 2028-12-31
Also published as: WO2010075692A1; CN101448226A

Abstract

本发明实施例公开了一种前转业务的识别方法和设备，所述方法包括：当接收的消息中的请求资源标识符Request-URI被改变时，判断所述消息是否符合初始过滤规则iFC所包含的一个或多个业务触发点SPT中的匹配条件；当所述消息符合所述iFC所包含的一个或多个SPT中的匹配条件时，根据所述iFC包含的前转业务识别标识识别所述消息所对应的业务是否为前转业务。通过应用本发明的技术方案，可以准确而灵活的进行前转业务的识别，达到了提高业务识别准确率，避免因误识别而导致业务失败和通信资源浪费的效果。

Description

一种前转业务的识别方法和设备

技术领域

本发明涉及通信技术领域，特别是涉及一种前转业务的识别方法和设备。

背景技术

IP多媒体子系统(IP Multimedia Subsystem，IMS)网络是第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)定义的，3GPP 24.229标准中定义的IP多媒体子系统业务控制(IP Multimedia Subsystem Service Control，ISC)接口是指呼叫会话控制功能(Call Session Control Function，CSCF)与应用服务器(Application Server，AS)之间的接口。其中，被叫服务-呼叫会话控制功能(Serving-Call Session Control Function，S-CSCF)对于触发AS的前转识别只是对触发前后的消息中的请求资源标志符(Request-UniversalResource Identifier，Request-URI)简单的比较，当此判断应用到IMS网络上时，将面临如下问题：因业务需要和场景的繁多，与S-CSCF对接触发的AS经常进行一些改号业务，对于请求INVITE消息的Request-URI经常修改为一些和业务相关的形式，导致S-CSCF识别为前转而重复进行被叫路由导致业务失败。

3GPP 24.229中对于S-CSCF识别前转的描述并未给出详细具体描述，被叫S-CSCF对于触发AS的前转业务的识别只是根据触发前后会话发起协议(theSession Initiation Protocol，SIP)消息中的Request-URI是否改变来作简单的识别。例如：触发AS前的SIP消息中的Request-URI为“TEL：+8675528760001”，触发AS后AS将SIP消息中的Request-URI修改为了“TEL：+8613911112222”，那么S-CSCF判断触发前后的Request-URI发生了变化，识别为前转直接路由到前转方网络不进行后续业务触发。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

现有技术方案中，S-CSCF对前转的识别只是根据触发前后SIP消息中的Request-URI是否改变来识别，因业务需要和场景的繁多，与S-CSCF对接触发的AS对于INVITE消息的Request-URI经常修改为各种和业务相关的形式，当对Request-URI改变的简单的判断应用到IMS网络上时，会出现前转业务识别不准确，或无法识别前转业务的问题。

发明内容

本发明实施例要解决的问题是提供一种前转业务的识别方法和设备，用于准确识别前转业务。

为达到上述目的，本发明实施例一方面提出一种前转业务的识别方法，包括：

当接收的消息中的请求资源标识符Request-URI被改变时，判断所述消息是否符合初始过滤规则iFC所包含的一个或多个业务触发点SPT中的匹配条件；所述接收的消息为应用服务器AS触发后返回的消息；

当所述消息符合所述iFC所包含的一个或多个SPT中的匹配条件时，根据所述iFC包含的前转业务识别标识识别所述消息所对应的业务是否为前转业务。

另一方面，本发明实施例还提出一种S-CSCF，包括：

匹配判断模块，用于当接收的消息中的Request-URI被改变时，判断所述消息是否符合iFC所包含的一个或多个SPT中的匹配条件；所述接收的消息为应用服务器AS触发后返回的消息；

前转识别模块，用于当所述匹配判断模块判断所述消息符合所述iFC所包含的一个或多个SPT中的匹配条件时，根据所述iFC包含的前转业务识别标识识别所述消息所对应的业务是否为前转业务。

本发明实施例的技术方案具有以下优点，因为采用了根据iFC所包含的一个或多个SPT中的匹配条件及其对应的扩展参数进行前转业务识别的方法和设备，从而，可以准确的进行前转业务的识别，达到了提高业务识别准确率，避免因误识别而导致通信资源浪费的效果。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一中一种前转业务的识别方法的流程示意图；

图2为本发明实施例二中一种S-CSCF的结构示意图；

图3为本发明实施例三中一种前转业务的识别方法的流程示意图；

图4为本发明实施例四中一种原被叫信息的获取方法的流程示意图；

图5为本发明实施例四中场景一下获取原被叫信息的流程示意图；

图6为本发明实施例四中场景二下获取原被叫信息的流程示意图；

图7为本发明实施例四中场景三下获取原被叫信息的流程示意图。

具体实施方式

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

本发明实施例一提供了一种前转业务的识别方法，其流程示意图如图1所示，包括以下步骤：

步骤S101、当接收的消息中的Request-URI被改变时，判断该消息是否符合初始过滤规则(Initial Filter Criteria，iFC)所包含的一个或多个业务触发点(Service Point Trigger，SPT)中的匹配条件。

当该消息符合iFC所包含的一个或多个SPT中的匹配条件时，转入步骤S102；

当该消息不符合iFC所包含的一个或多个SPT中的匹配条件时，转入步骤S103。

其中，接收的消息可以为应用服务器AS触发后返回的消息。

其中，iFC所包含的一个或多个SPT中的匹配条件具体通过精确值或正则表达式进行设置，该匹配条件的具体内容为：

在第一SPT中的<Request-URI>字段设置的Request-URI内容；和/或，

在第二SPT中的<SIPHeader>字段设置的History-info头域；和/或，

在第三SPT中的<SIPHeader>字段设置的Diversion头域。

具体的，基于上述的匹配条件设置，该消息符合iFC所包含的一个或多个SPT中的匹配条件的判断依据包括以下几种情况：

当所接收的AS触发后返回的消息中的Request-URI与在第一SPT中的<Request-URI>字段设置的Request-URI内容相匹配时，判断该消息符合匹配条件；或，

当所接收的AS触发后返回的消息中的Request-URI与在第一SPT中的<Request-URI>字段设置的Request-URI内容相匹配，且该消息在AS触发前所对应的消息和在第二SPT中的<SIPHeader>字段设置的History-info头域的信息相匹配时，判断该消息符合匹配条件；或，

当所接收的AS触发后返回的消息中的Request-URI和该消息在AS触发前所对应的消息之间的差异性关系与在第一SPT中的<Request-URI>字段设置的Request-URI内容和在第二SPT中的<SIPHeader>字段设置的History-info头域所对应的差异性关系相匹配时，判断该消息符合匹配条件；或，

当所接收的AS触发后返回的消息中的Request-URI与在第一SPT中的<Request-URI>字段设置的Request-URI内容匹配，且与在第三SPT中的<SIPHeader>字段设置的Diversion头域所设置的内容相匹配时，判断该消息符合匹配条件。

步骤S102、根据iFC包含的前转业务识别标识识别消息所对应的业务是否为前转业务。

前转业务识别标识包括服务器标识和前转标识。

当iFC包含的服务器标识为全网识别位置字符，且前转标识为前转确认字符时，转入步骤S104；

当iFC包含的服务器标识不是全网识别位置字符，或该前转标识不是前转确认字符时，转入步骤S103。

具体的，根据iFC包含的前转业务识别标识识别该消息所对应的业务是否为前转业务的流程为：

判断iFC包含的服务器标识是否为全网识别位置字符；

当该iFC包含的服务器标识为全网识别位置字符时，判断该前转标识是否为前转确认字符；

当该前转标识为前转确认字符时，识别该消息所对应的业务为前转业务。

步骤S103、识别该消息所对应的业务为非前转业务，进行该消息所对应的后续业务的触发。

步骤S104、识别该消息所对应的业务为前转业务，将该消息路由到前转方网络。

进一步需要指出的是，在上述的方法中，当iFC为针对单一用户的配置时，该iFC配置在该单一用户所签约的归属签约用户服务器(Home SubscriberServer，HSS)上；当iFC为针对当前网络的全部用户的配置时，该iFC配置在S-CSCF上。

进一步的，上述方法还包括根据消息中携带的History-Info信息，获取该消息在AS触发前所对应消息的原被叫信息的方法，具体流程如下：

获取所接收的AS触发后返回的消息中的最后一条index信息；

根据该index信息，获取该index信息的父级index信息；

确认该父级index信息所对应的信息为该消息在AS触发前所对应消息的原被叫信息。

根据实际情况，对本发明实施例中的步骤或流程进行相应的调换或改变，并不影响本专利保护范围。

本发明实施例的技术方案具有以下优点，因为采用了根据iFC所包含的一个或多个SPT中的匹配条件及其对应的扩展参数进行前转业务识别的方法，从而，可以准确的进行前转业务的识别，达到了提高业务识别准确率，避免因误识别而导致通信资源浪费的效果。

基于上述实施例所提出的方法，本发明实施例二提出了一种S-CSCF，其结构示意图如图2所示，具体包括：

匹配判断模块1，用于当接收的消息中的Request-URI被改变时，判断该消息是否符合iFC所包含的一个或多个SPT中的匹配条件

匹配判断模块1具体用于应用服务器AS触发后返回的消息，当接收的消息中的Request-URI被改变时，判断所述消息是否符合iFC所包含的一个或多个SPT中的匹配条件。

匹配判断模块1，具体包括：

第一判断子模块11，用于判断所接收的AS触发后返回的消息中的Request-URI是否被改变；

条件获取子模块12，用于当第一判断子模块11判断所接收的AS触发后返回的消息中的Request-URI被改变时，在HSS或本地获取所接收的AS触发后返回的消息所对应的iFC所包含的一个或多个SPT中的匹配条件；

第二判断子模块13，用于判断所接收的AS触发后返回的消息是否符合条件获取子模块12所获取的匹配条件。

前转识别模块2，用于当匹配判断模块1判断该消息符合iFC所包含的一个或多个SPT中的匹配条件时，根据该iFC包含的前转业务识别标识识别该消息所对应的业务是否为前转业务，该前转业务识别标识包括服务器标识和前转标识，前转识别模块2具体包括：

第三判断子模块21，用于根据所述匹配条件，判断服务器标识是否为全网识别位置字符；

第四判断子模块22，用于当第三判断子模块21判断服务器标识为全网识别位置字符时，判断前转标识是否为前转确认字符，当前转标识为前转确认字符时，识别消息所对应的业务为前转业务。

进一步的，S-CSCF还包括：

信息获取模块3，用于根据所接收的AS触发后返回的消息中的最后一条索引index信息的父级index信息，获取该消息在AS触发前所对应消息的原被叫信息。

上述模块可以分布于一个装置，也可以分布于多个装置。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。

本发明实施例的技术方案具有以下优点，因为采用了根据iFC所包含的一个或多个SPT中的匹配条件及其对应的扩展参数进行前转业务识别的S-CSCF，从而，可以准确的进行前转业务的识别，达到了提高业务识别准确率，避免因误识别而导致通信资源浪费的效果。

在现有的技术场景下，结合具体的示例，Request-UR形式变换应用场景主要包括以下几种情况：

情况一、被叫触发前的Request-URI为“tel：+8675512345”，对接的AS出于业务需求或者自身支持能力限制，将触发后的Request-URI作了形式变换，修改为了“sip：+8675512345@huawei.com；user＝phone”。

情况二、触发前的Request-URI为“tel：12345；phone-context＝+86755”，对接的AS对此短号形式进行了号码分析和规整，将触发后的Request-URI规整为了“tel：+8675512345”，实际上是同一个号码。

情况三、触发前的Request-URI为“tel：+8675512345”，对接的AS进行了业务参数的添加(例如：cic)，触发AS后的Request-URI被修改为了“tel：+8675512345；cic＝+8001”。

情况四、触发前的Request-URI为“tel：+8613911112222”，对接的AS进行了特殊业务处理，将号码统一添加了运营预选前缀(例如：17951)，触发AS后的Request-URI被修改为了“tel：179586113911112222”。

需要指出的是，上述四种情况只是为了方便描述而选择了具体的号码或标识的示例，在具体的应用中，具体号码或标识内容的变化并不影响上述各情况所代表的示例范围。

下面，为了更清楚的阐述本发明实施例所提出的技术方案，本发明在后续实施例中结合上述的几种情况，进行具体的说明。

现有的前转识别技术只是简单的对触发前后的Request-URI进行比较，这样的识别并不能准确区分前转业务，因此，会将多种非前转场景被识别成了前转情况，而额外多进行一次被叫路由过程，并进而导致业务失败，影响了业务响应效率，浪费了网络资源。

本发明实施例所提出的技术方案是通过S-CSCF灵活运用已有的用户签约数据iFC和扩展部分参数对前转的灵活识别方式，解决S-CSCF对各种场景下AS改号后的前转的有效识别，避免被叫触发时影响路由的部分发生变化，额外多进行一次被叫路由过程所带来的导致业务失败。

在本发明实施例所提出的技术方案中，S-CSCF灵活运用规范已有的用户签约数据中iFC的SPT中<Request-URI>字段和/或<SIPHeader>字段以及其他字段来进行匹配条件的配置，并判断触发AS后的消息是否满足制定的SPT，在上述判断的结果为是时，将当前的消息触发到该SPT所对应的<ApplicationServer>服务器。对于前转业务，在<ApplicationServer>中的<ServerName>字段，不再配置AS的地址，而是配置了全网识别的一个位置字符，即全网识别位置字符，并且配置S-CSCF自身进行业务识别的一个扩展参数作为前转标识，本发明实施例中以“CF”对该前转标识进行命名，在具体的应用场景中，参数名称的变化并不会影响本发明的保护范围。

例如：用户签约的iFC为：

<SPT>

<Request-URI>制定的URI</Request-URI>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝1</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

当触发AS后的SIP消息中的Request-URI发生了变化，消息中的Request-URI被AS修改为制定的URI时，S-CSCF执行此条iFC时会判断该消息满足此触发点的匹配条件，从而，触发到<ApplicationServer>中的<ServerName>，此时S-CSCF判断<ServerName>是全网识别的位置字符而非AS地址，将不进行ISC接口的AS触发路由而是进行自身的业务逻辑判断。例如：获取<ServerName>中扩展的前转标识“CF”，根据此参数判断当前消息所对应的业务是否是前转业务，如果CF＝1则为前转，如果CF＝0或者不存在则认为非前转。

具体的，基于上述的技术思路，本发明实施例所提出的技术方案通过对iFC数据配置及扩展参数“CF”的灵活运用，解决各种场景下的前转识别问题，下面，通过本发明实施例三对具体的识别过程进行说明，其流程示意图如图3所示，包括以下步骤：

步骤S301、S-CSCF收到从AS触发回来的消息后，判断该消息中的Request-URI是否被改变。

如果Request-URI未被改变，则转入步骤S302；

如果Request-URI被改变，则转入步骤S303，进一步判断该消息所对应的业务是否是前转业务。

步骤S302、S-CSCF继续对该消息执行业务触发，而不进行前转。

步骤S303、S-CSCF判断该Request-URI是否符合iFC所包含的一个或多个SPT中的匹配条件。

当S-CSCF判断该Request-URI符合匹配条件时，转入步骤S304；

当S-CSCF判断该Request-URI不符合匹配条件时，转入步骤S302。

在本步骤中，S-CSCF执行下一条S-CSCF内部业务逻辑识别(如前转识别逻辑)的iFC，使用iFC中SPT的<Request-URI>和/或<SIPHeader>以及其他字段所设置的条件作为触发S-CSCF进行内部前转识别逻辑的判断驱动，即，利用iFC的触发条件的满足，进一步触发根据<ApplicationServer>所进行的前转业务识别。

步骤S304、S-CSCF判断满足该STP触发条件所触发的<ApplicationServer>是否为全网识别位置字符。

当<ApplicationServer>为全网识别位置字符时，转入步骤S305；

当<ApplicationServer>不是全网识别位置字符时，转入步骤S302。

步骤S305、S-CSCF判断满足该SPT触发条件所触发的<ApplicationServer>中的前转标识是否为前转确认字符。

基于本发明实施例前述的场景设置，本步骤相当于判断“CF”的标识值是否为1，CF＝1即表示前转标识为前转确认字符。

当S-CSCF判断前转标识为前转确认字符，即CF＝1时，转入步骤S306；

当S-CSCF判断前转标识不是前转确认字符，或不存在前转标识，即CF＝0或无CF值时，转入步骤S302。

步骤S306、S-CSCF识别该消息所对应的业务为前转业务，将该消息路由到前转方网络。

为了更加清楚地对上述识别过程进行说明，本发明实施例根据具体的应用示例对上述的方法实现场景进行描述。

首先，需要说明的是，上述的SPT中的匹配条件可以支持精确配置，也可以支持正则表达式配置。

下面，根据具体的实施场景分情况进行说明。

情况一、当S-CSCF只针对AS触发回来的消息中的Request-URI来识别是否是前转时，则只需要在SPT中配置<Request-URI>为制定的Request-URI即可，可以是精确值，也可以是正则表达式。

具体示例如下：

例1：当用户B需要被前转到C时，S-CSCF可通过如下配置的iFC来识别此次前转(例如：C的号码为“TEL：+867551234”)：

<SPT>

<Request-URI>TEL：+867551234</Request-URI>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝1</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

例2：触发AS后Request-URI被改号为具有制定的具有某些特征的正则匹配URI(例如：以+86755为前缀的号码)，则识别为前转。S-CSCF可通过如下配置的iFC进行此类识别。

<SPT>

<Request-URI>TEL：+86755(.*)</Request-URI>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝1</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

情况二、当S-CSCF需要同时判断触发前和触发后的Request-URI来识别是否是前转，即需要触发前的原被叫满足某个条件，同时需要触发AS后所改变的Request-URI也满足某个条件时，iFC中的SPT需要使用<SIPHeader>配置History-Info头域，因为History-info头域能够正确的代表改号前的原被叫的Request-URI。

例3：设置触发前的原被叫为制定的URI(例如：以139前缀的号码)且触发后的Request-URI为某类特征号码(以86755为前缀的号码)，则识别为前转/非前转，例如，同振业务中需要对以86755为前缀的号码认为非前转，其它号码认为前转。

<SPT>

<Request-URI>TEL：+86755(.*)</Request-URI>

</SPT>

<SPT>

<Header>History-Info</Header>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝0</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

上述匹配条件可以只包含<SIPHeader>而不包括REQUEST-URI，其原理相同，再次不再赘述。

iFC中的SPT也可使用<SIPHeader>配置Diversion头域，因为Diversion头域也能够代表改号前的原被叫的Request-URI。

<SPT>

<Request-URI>TEL：+86755(.*)</Request-URI>

</SPT>

<SPT>

<Header>Diversion</Header>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝0</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

情况三、当S-CSCF需要判断触发前后的Request-URI有差异性关系时，需要控制差异是否是前转的判断依据，而差异是多种多样的，通过灵活配置History-Info头域中的原内容和新的内容的差异正则表达式将差异配置出来，达到控制的效果，上述原内容可以为原URI，新的内容可以为新的URI。

例4：设置触发AS后原Request-URI被改变为携带了某些关键参数(例如：Phone-context或Trunk Group或cic或rn等)制定值的Request-URI时，则识别为前转。S-CSCF可通过如下配置的iFC进行此类识别。

<SPT>

<Request-URI>(条件)[cic＝制定 cic](.*)</Request-URI>

</SPT>

<SPT>

<Header>History-Info</Header>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝1</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

例5：触发前的Request-URI为TEL形式，而触发后的Request-URI为此号码的SIP：user＝phone形式时，则识别为非前转。

<SPT>

<Request-URI>SIP：！条件！@(.*)；user＝phone</Request-URI>

</SPT>

<SPT>

<Header>History-Info</Header>

</SIPHeader>

</SPT>

</TriggerPoint>

<ServerName>全网识别位置字符；CF＝0</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

需要进一步指出的是，上述三种情况所对应的例1至例5所提出的各种具体应用场景中，通过前转标识CF的灵活调整，可以对符合匹配条件的AS触发返回的消息是否对应前转业务做出准确识别，并且，上述各方法可以单独使用，也可以组合使用，从而可以实现对待识别消息的属性的准确定义，从而灵活确定待识别消息的范围。

再进一步的，本发明实施例四还提出了一种原被叫信息的获取方法，根据消息中携带的History-Info信息，获取该消息在AS触发前所对应消息的原被叫信息，具体流程图如图4所示。

因为History-Info是一个列表list，要准确获取到当前S-CSCF所处理的原被叫的信息，可以通过以下步骤实现：

步骤S401、S-CSCF获取当前收到的AS触发后的Invite消息中的最后一条index。

步骤S402、S-CSCF根据该index信息，再获取此index所在的父级 index，该父级index所对应的信息即为该消息在AS触发前所对应消息的原被叫信息。

进一步的，通过以下前转场景进行具体说明，以下场景涵盖了各种前转业务点，即通过History-Info的获取算法可正确获取到当前S-CSCF所处理的原被叫信息。

场景一、如图5所示，此场景中发生两次前转，其中第一次为早前转(即，无条件前转)，第二次为晚前转(即，遇忙前转)。其中，<B；index＝1>是原被叫，<C；index＝1.1>是B用户所触发的AS无条件前转后的第一被叫，<D；index＝1.2>是触发AS后遇忙前转后的第二被叫。

其中，<C；index＝1.1>和<D；index＝1.2>是同级index，而<B；index＝1>是<C；index＝1.1>和<D；index＝1.2>的父级index。

那么对于原被叫B所在的S-CSCF2来说，在第一次无条件前转中，获取的原被叫的信息就是触发AS后的消息的当前History-Info中最后一跳<C；index＝1.1>的上一级index＝1的URI，即<B；index＝1>，而在第二次遇忙前转中，获取的原被叫的信息就是触发AS后的消息的当前History-Info中最后一跳的<D；index＝1.2>的上一级index＝1的URI，即<B；index＝1>。

场景二、如图6所示，此场景中发生了两次无条件前转，在第一次无条件前转中，<B；index＝1>是原被叫，经过B用户的AS前转到<C；index＝1.1>的第二原被叫，而在第二次无条件前转中，<C；index＝1.1>则成为了原被叫，然后再经过C用户的前转AS前转到<D；index＝1.1.1>的当前被叫。

其中，<B；index＝1>是<C；index＝1.1>的父级index，而<C；index＝1.1>是<D；index＝1.1.1>的父级index。

那么S-CSCF2对应的是第一次无条件前转，其获取的原被叫则为其当前触发AS后的History-Info中最后一跳<C；index＝1.1>的上一级index＝1的URI，即<B；index＝1>；而S-CSCF3对应的是第二次无条件前转，其获取的原被叫则为其当前触发后的History-Info中最后一跳<D；index＝1.1.1>的上一级index＝1.1的URI，即<C；index＝1.1>。

场景三、如图7所示，此场景中发生了三次前转，包括两次无条件前转和一次遇忙前转，在第一次无条件前转中，<B；index＝1>是原被叫，经过B用户的AS无条件前转到C后增加了<C；index＝1.1>的第二原被叫，由于C用户忙，于是B的AS进行了第二次遇忙前转，前转到<D；index＝1.2>的第三原被叫；D用户的触发AS将呼叫进行第三次无条件前转，前转到当前用户E。

其中，<B；index＝1>是<C；index＝1.1>和<D；index＝1.2>的父级index，而<D；index＝1.2>是<E；index＝1.2.1>的父级index。

那么对于S-CSCF2来说，第一次无条件前转获取的原被叫就为触发后当前History-Info中最后一跳<C；index＝1.1>的上一级index＝1的URI，即<B；index＝1>，第二次遇忙前转获取的原被叫就为触发后当前的History-Info中最后一跳的<D；index＝1.2>的上一级index＝1的URI，即<B；index＝1>。

对于S-CSCF4来说，获取的原被叫就为触发后当前的History-Info中最后一跳的<E；index＝1.2.1>的上一级index＝1.2的URI，即<D；index＝1.2>。

通过应用本发明实施例所提出的技术方案，S-CSCF能够利用iFC中对SPT的灵活运用及扩展参数“CF”的运用，即可解决S-CSCF对各种场景下AS改号后的前转的有效识别，避免被叫触发时候不影响路由的部分发生变化，额外多进行一次被叫路由过程，导致业务失败。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以可借助软件加必要的通用硬件平台的方式来实现基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

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

Claims

1.一种前转业务的识别方法，其特征在于，包括：

2.如权利要求1所述的方法，其特征在于，所述前转业务识别标识包括服务器标识和前转标识。

3.如权利要求1所述的方法，其特征在于，所述iFC所包含的一个或多个SPT中的匹配条件，具体通过精确值或正则表达式进行设置。

4.如权利要求3所述的方法，其特征在于，所述iFC所包含的一个或多个SPT中的匹配条件，具体为：

在第一SPT中的请求资源标识符<Request-URI>字段设置的Request-URI内容；和/或，

在第二SPT中的会话发起协议头<SIPHeader>字段设置的历史信息History-info头域；和/或，

在第三SPT中的<SIPHeader>字段设置的转移Diversion头域。

5.如权利要求1或3或4任一项所述的方法，其特征在于，所述消息符合所述iFC所包含的一个或多个SPT中的匹配条件，具体包括：

当所接收的AS触发后返回的消息中的Request-URI与在第一SPT中的<Request-URI>字段设置的Request-URI内容相匹配时，判断所述消息符合所述匹配条件；或，

当所接收的AS触发后返回的消息中的Request-URI与在第一SPT中的<Request-URI>字段设置的Request-URI内容相匹配，且所述消息在AS触发前所对应的消息和在第二SPT中的<SIPHeader>字段设置的History-info头域的信息相匹配时，判断所述消息符合所述匹配条件；或，

当所接收的AS触发后返回的消息中的Request-URI和所述消息在AS触发前所对应的消息之间的差异性关系与在第一SPT中的<Request-URI>字段设置的Request-URI内容和在第二SPT中的<SIPHeader>字段设置的History-info头域所对应的差异性关系相匹配时，判断所述消息符合所述匹配条件；或，

当所接收的AS触发后返回的消息中的Request-URI与在第一SPT中的<Request-URI>字段设置的Request-URI内容匹配，且与在第三SPT中的<SIPHeader>字段设置的Diversion头域中所设置的内容相匹配时，判断所述消息符合所述匹配条件。

6.如权利要求2所述的方法，其特征在于，所述根据所述iFC包含的前转业务识别标识识别所述消息所对应的业务是否为前转业务，具体为：

判断所述服务器标识是否为全网识别位置字符；

当判断结果为所述服务器标识为全网识别位置字符时，判断所述前转标识是否为前转确认字符；

当所述前转标识为前转确认字符时，识别所述消息所对应的业务为前转业务。

7.如权利要求1所述的方法，其特征在于，

当所述iFC为针对单一用户的配置时，所述iFC配置在所述单一用户所签约的归属签约用户服务器HSS上；

当所述iFC为针对当前网络的全部用户的配置时，所述iFC配置在服务-呼叫会话控制功能实体S-CSCF上。

8.如权利要求1所述的方法，其特征在于，还包括根据所述消息中携带的History-Info信息，获取所述消息在AS触发前所对应消息的原被叫信息的方法，具体为：

获取所接收的AS触发后返回的消息中的最后一条索引index信息；

根据所述index信息，获取所述index信息的父级index信息；

确认所述父级index信息所对应的信息为所述消息在AS触发前所对应消息的原被叫信息。

9.一种S-CSCF，其特征在于，包括：

10.如权利要求9所述的S-CSCF，其特征在于，所述前转识别模块具体用于根据所述iFC包含的前转业务识别标识包括的服务器标识和前转标识的类型识别所述消息所对应的业务是否为前转业务。

11.如权利要求9所述的S-CSCF，其特征在于，所述匹配判断模块，具体包括：

第一判断子模块，用于判断所接收的AS触发后返回的消息中的Request-URI是否被改变；

条件获取子模块，用于当所述第一判断子模块判断所接收的AS触发后返回的消息中的Request-URI被改变时，在归属签约用户服务器HSS或本地获取所接收的AS触发后返回的消息所对应的iFC所包含的一个或多个SPT中的匹配条件；

第二判断子模块，用于判断所接收的AS触发后返回的消息是否符合所述条件获取子模块所获取的匹配条件。

12.如权利要求10所述的S-CSCF，其特征在于，所述前转识别模块，具体包括：

第三判断子模块，用于根据所述匹配条件，判断所述服务器标识是否为全网识别位置字符；

第四判断子模块，用于当所述第三判断子模块判断所述iFC包含的服务器标识为全网识别位置字符时，判断所述前转标识是否为前转确认字符，当所述前转标识为前转确认字符时，识别所述消息所对应的业务为前转业务。

13.如权利要求9所述的S-CSCF，其特征在于，还包括：

信息获取模块，用于根据所接收的AS触发后返回的消息中的最后一条索引index信息的父级index信息，获取所述消息在AS触发前所对应消息的原被叫信息。