CN1832473A

CN1832473A - 一种在ims网络中处理会话消息的方法及装置

Info

Publication number: CN1832473A
Application number: CNA2005101197569A
Authority: CN
Inventors: 朱奋勤; 武亚娟
Original assignee: Huawei Technologies Co Ltd
Current assignee: Yingweite SPE limited liability company
Priority date: 2005-08-19
Filing date: 2005-11-03
Publication date: 2006-09-13
Anticipated expiration: 2025-11-03
Also published as: BRPI0614848B1; EP1755310A1; BRPI0614848A2; ATE512535T1; CN100502402C; US7835352B2; BRPI0614848A8; US20070121622A1; EP1755310B1; WO2007019775A1

Abstract

本发明公开了一种在IMS网络中的B2BUA模式下处理会话消息的方法，该方法由IMS网络的应用服务器(AS)接收业务－呼叫会话控制功能(S－CSCF)实体转发的第一会话消息，AS产生第二会话消息；在产生第二会话消息的过程中，若AS判断在S－CSCF实体上第二会话消息与第一会话消息的业务逻辑需要关联，则将第一会话消息的Route头域去掉AS的统一资源标识后作为第二会话消息的Route头域，若不需要关联，AS按始发方式重新构造第二会话消息的Route头域，并发送该第二会话消息。本发明还同时公开了一种IMS网络中的应用服务器，至少包括第一业务逻辑处理单元和第二业务逻辑处理单元。

Description

一种在IMS网络中处理会话消息的方法及装置

技本领域

本发明涉及通信领域的IMS网络，尤其涉及在IMS网络中的B2BUA模式下处理会话消息的方法及其装置。

背景技术

在IMS网络中，业务-呼叫会话控制功能(S-CSCF)通常不具体执行相关业务，而相关业务的逻辑放置在应用服务器(AS)上。S-CSCF在收到一条会话初始消息时，将根据用户在注册时下载的User Profile中所包含的初始过滤规则(iFC)对会话消息进行匹配，根据匹配后的规则，S-CSCF将所收到的会话消息转发给相关的AS。AS在这个会话过程中，可以充当不同的角色。其中一个可能的模式为AS充当Originate模式，其模式如图1A所示，另一个可能的模式为AS充当B2BUA(Back-to-Back User Agent，背靠背用户代理)模式，其模式如图1B所示。

在B2BUA模式的业务处理中，与发明比较密切相关的几个头域的简单解释如下：

Route头域，用来预先设定路由，规定了SIP消息下一跳的目的地。其中可包含Orig-DIALOG ID信息，用来协助S-CSCF获悉新旧会话之间的对应关系。

P-Asserted-Identity IMS头域，网络实体插入的用户标识，用来标识发起呼叫的始发端。

REQUEST-URI头域，用来表示呼叫的目的地。

在B2BUA模式下，AS接受来自一侧的会话消息，同时它又在另一侧新发起一个会话。两个会话之间的内部关联，由AS来映射。从S-CSCF的角度来看，由于左右两者为不同的会话，所有会话相关的信息是截然不同的。但是有时S-CSCF需要明确两者之间的关联关系，这是因为用户可能希望在后续的会话中，继续对原有后续的iFC规则进行判断。通过SIP会话标识(如CallID)来关联两个不同会话的方法，将无法继续使用。因此在IMS网络中引入了Orig-Dialog ID的标识。并规定S-CSCF在将消息送往AS时，必须将该标识放置在Route头域AS的URI标识后。这样当AS收到该消息后，移去AS的URI，就将S-CSCF的URI标识放置在Route头域的顶部。当S-CSCF收到该消息后，通过判断该标识，就能确定该新收到的消息，最开始是由AS还是S-CSCF始发的。这样若后续还需要进行原有的后续iFC处理，S-CSCF就可以判断新会话同老会话之间的关联，进而决定采用那一个iFC。

当AS执行B2BUA操作时，前后会话之间没有必然联系(由AS根据业务逻辑自己内部决定如何映射)。AS是可以修改REQUEST-URI或者P-Asserted-Identity头域的。

在传统的电信网络中，存在一类特殊的电话号码，如114/1000等。他们通常并不代表某个实际的用户，也就不存在相应的用户注册/鉴权等过程。对于这类特殊标识，IMS网络也引入了类似的特殊标识，称为PSI(Public ServiceIdentity公共业务标识)。同传统的特殊标识不同的是，在IMS网络中，引入了两种PSI。一种可以称为特定的PSI，它指向特定的用户。另一类称为通配PSI，它不指向特定用户，而指向一类用户。

对于通配PSI可指向多个不同的特定的PSI，它的格式为采用SIP URI时，在USER-INFO可包含用“！”限定的采用IEEE 1003.1-2004 Part 1定义的扩展正则表达式格式，如″sip：chatlist！.*！@example.com″，它可以匹配到：

sip：chatlist1@example.com，

sip：chatlist2@example.com，

sip：chatlist42@example.com，

sip：chatlistAbC@example.com。

当采用TEL URI格式时，则在电话用户部分包含用“！”限定的采用IEEE1003.1-2004 Part 1定义的扩展正则表达式格式，如″TEl：123456！.*！″，它可以匹配到：

TEL：1234561；

TEL：1234567；

TEL：123456789。

在现有技术中对S-CSCF和AS做了如下规定，从而让S-CSCF知道如何同原有的老会话进行关联：

S-CSCF动作：

(1)S-CSCF在收到任何一条消息后，若发现其中包含了Orig-DIALOGID，则知道该消息初始为S-CSCF始发，在S-CSCF上存在同新消息关联的原会话。根据该Orig-Dialog ID，S-CSCF找到原会话，并判断相关用户标识(如P-Asserted-Identity或Request-URI)未修改继续执行未执行完毕的iFC。

(2)S-CSCF在收到的消息中，若未发现Orig-DIALOG ID，则知道该消息为新会话。S-CSCF再根据iFC规则，确定需要将该消息转发给那个AS后，S-CSCF在Route头域中，首先填上AS的URI，随后紧跟着S-CSCF的URI，其中S-CSCF的URI包含了ORIG-DIALOG ID。其示例如下：

ROUTE<AS-URI；>；<ORIG-DIALGO ID@S-CSCF1；>；...

AS的动作；

(1)AS在收到消息并执行了相关操作后，确定如何产生新的会话初始消息，此时，AS须将Route头域中其自身的AS-URI移走，将剩余的Route头域原封不动的拷贝到新的会话消息中作为新会话的Route头域，并根据该头域进行新消息的路由。因此在新消息中来自S-CSCF的包含ORIG-DILOG ID标识的URI将放置在Route头域的顶端。

这样在后续的从AS返回消息中，AS消耗了第一个Route头域，因此，S-CSCF必然将收到如下的头域：

Route<ORIG-DIALOG ID@S-CSCF1；>；...

S-CSCF就可以根据该标识，确定同原先的那一个老会话关联，并判断相关用户标识未修改执行后续的iFC检测。

S-CSCF在在上述判断相关用户标识未修改是严格参照RFC3261标准检查是否被AS修改。

在上述B2BUA模式下对主叫侧进行呼叫的处理，其基本出发点就是新会话不会更改P-Asserted-Identity，因此不应该在新会话重新构造Route头域，否则会导致在S-CSCF重新进行iFC检测。对于前后会话此时为同一用户的情况，应该是进行原有未检测完iFC的继续处理，因此在现有标准中，对于这种情况，要求AS直接拷贝原有的Route头域，不能直接构建一新头域。但是这个处理过程并未考虑AS始发的新会话消息，即新会话消息与原会话消息不属于同一用户的情况，在这种情况下会出现上述情况，如AS确定新的会话消息代表新的用户，按照目前的规则AS必须把原有的Route头域去除AS的SIP URI后拷贝到新会话消息的Route头域，这样构成了如下头域：

Route<ORIG-DIALOG ID@S-CSCF1>

这样就会存在以下问题：

1、当AS在主叫侧执行B2BUA处理，S-CSCF收到经AS以B2BUA方式处理后的消息，检查到ORIG-DIALOG ID标识，根据该标识S-CSCF判断该呼叫为一个B2BUA呼叫，但是S-CSCF随即发现P-Asserted-Identity不同，因此不能继续进行后续的iFC判断。由于S-CSCF无法判断该消息为主叫端还是被叫端处理，缺省情况下按照被叫处理，将根据REQUEST-URI进行后续的路由处理。因此在此过程中，若AS希望S-CSCF执行主叫侧所代表的新用户iFC处理，将无法执行。例如，用户登记了主叫号码隐藏业务，主叫号码隐藏使AS改变了P-Asserted-Identity(因为它可以显示用户)后重新发起一到被叫的新呼叫。此时在S-CSCF上需要执行新P-Asserted-Identity的iFC检测，因此AS必须重新构造新的Route头域，而不是拷贝原先的Route头域，如按照现有技术，将导致S-CSCF既不能按照原iFC进行检测，同时也不能按照新的iFC进行检测。

2、当AS在被叫侧执行B2BUA处理，S-CSCF收到经AS以B2BUA方式处理后的消息后，检查到ORIG-DIALOG ID标识，根据该标识。S-CSCF判断该呼叫为一个B2BUA呼叫。S-CSCF随即只检查REQUEST-URI，而并不检查P-Asserted-Identity是否发生变化。因此在此过程中，若AS希望S-CSCF执行主叫侧的iFC处理，也将无法执行。

3、按照目前的SIP URI比较方法，如果AS将某个通配标识符改变为某个特定的标识符时，从业务逻辑处理上来说，应该继续原先的业务处理。例如用户无法确定目前的空闲聊天室号，因此初始呼叫为一个通配聊天室PSI，经过AS以B2BUA模式处理后，AS转换为一个特定的PSI。按照目前的RFC3261 SIP URI比较方法，这两个URI将被当作不同的URI，因此就不会继续原先的iFC处理，将会视为一个新的呼叫重新进行iFC检测处理。显然，将其视为一个新的呼叫在业务逻辑处理上不太合理。

发明内容

本发明提供一种在IMS网络中处理会话消息的方法及其装置，以解决现有IMS网络中的S-CSCF在处理B2BUA呼叫过程中，由于根据错误的新会话消息与原会话消息是否关联标识而导致不能正确完成逻辑处理的问题。

本发明提供以下技术方案：

一种在IMS网络中的B2BUA模式下处理会话消息的方法，IMS网络的应用服务器(AS)接收业务-呼叫会话控制功能(S-CSCF)实体转发的第一会话消息；AS产生和发送第二会话消息，并且在产生第二会话消息的过程中判断第二会话消息与第一会话消息在S-CSCF实体上是否需要关联；其中：

AS在确定第二会话消息与第一会话消息在S-CSCF实体上需要关联时，将第一会话消息的Route头域去掉AS的统一资源标识后作为第二会话消息的Route头域；或者，AS在确定第二会话消息与第一会话消息在S-CSCF实体上不需要关联时，AS按始发方式重新构造第二会话消息的Route头域。

AS根据选择的业务逻辑本身确定前后会话是否相关连，即由业务逻辑的设计者决定前后业务是否需要关联。

AS根据处理会话消息的业务逻辑来判断第二会话消息与第一会话消息在S-CSCF实体上是否需要关联。

AS在为第二会话消息生成Route头域时，可进一步比较第二会话消息中已生成的相关信息与第一会话消息中对应的相关信息，确定第二会话消息与第一会话消息在S-CSCF实体上是否关联，并根据比较结果为第二会话消息生成相应的Route头域。

接收到第二会话消息的业务-呼叫会话控制功能实体(S-CSCF)进行下述步骤：

A、判断第二会话消息中是否携带相关的关联会话标识，若有则进行步骤B，否则，按照新会话方式处理第二会话消息；

B、S-CSCF根据所述关联会话标识查找到相关联的第一会话消息，并判断第一会话消息和第二会话消息中相关的信息是否匹配；

C、若匹配，则按第一会话消息和第二会话消息的业务逻辑相关联对第二会话消息进行后续处理；若不匹配，则按第一会话消息和第二会话消息的业务逻辑不相关联对第二会话消息进行后续处理。

一种在IMS网络中的B2BUA模式下处理会话消息的方法，包括如下步骤：

A、接收到第二会话消息的S-CSCF实体判断该会话消息中是否携带相关的关联会话信息，若是，则进行步骤B，否则，按照新会话方式处理第二会话消息；

B、S-CSCF根据所述关联会话信息查找到相匹配的第一会话消息，并第一会话消息、第二会话消息中相关的信息是否相同；若相同，则进行步骤E；若不相同，则进行步骤C；

C、判断所述相关的信息中是否包含中通配符，若包含通配符，则进行步骤D，若不包含通配符，则进行步骤F；

D、按通配规则判断第一会话消息和第二会话消息中相关的用户标识是否匹配，若匹配，则进行步骤E，否则，进行步骤F；

E、按第一会话消息和第二会话消息的业务逻辑相关联对第二会话消息进行后续处理；

F、按第一会话消息和第二会话消息的业务逻辑不关联对第二会话消息继续后续处理。

一种在IMS网络中匹配URI的方法，包括如下步骤：

A、判断待匹配的两个URI是否相同，若相同，则确定该两个URI匹配；若不相同，则继续步骤B；

B、判断URI中是否包含中通配符，若包含通配符，则进行步骤C，否则，确定两个URI不匹配；

C、按通配规则判断两个URI是否相同，若相同，则确定匹配，否则，确定不匹配。

一种IMS网络中的应用服务器，包括：

用于处理业务-呼叫会话控制功能(S-CSCF)实体转发的第一会话消息的第一业务逻辑单元；

用于产生第二会话消息，并在生产第二会话过程中根据第二会话消息与第一会话消息的业务逻辑在S-CSCF实体上是否需要关联为第二会话消息产生头Route头域的第二业务逻辑单元；

所述第二业务逻辑单元在需要关联时将第一会话消息中的Route头域去掉AS的统一资源标识后作为第二会话消息的Route头域，或在不需要关联时按始发方式重新构造第二会话消息的Route头域。

所述第二业务处理单元包括：

用于判断第一会话消息与第二会话消息中相关的信息是否相同的第一模块；

用于在第一模块判断所述相关的信息不同且其中包含通配标识符，判断第一会话消息与第二会话消息中相关的信息是否匹配的第二模块；

用于根据第一模块或第二模块的判断结果，产生Route头域的第三模块。

一种在IMS网络中用于业务控制的网络设备，包括：

用于确定接收到的第二会话消息是否包含相关的关联会话标识，并在确定包含关联会话标识时查找到相匹配的第一会话消息的第一处理单元；

用于判断第一会话消息与第二会话消息中相关的信息是否相同的第二处理单元；

用于在第二处理单元判断所述相关的信息不同且其中包含通配标识符时，按通配规则判断第一会话消息与第二会话消息中相关的信息是否匹配的第三处理单元；

用于根据所述第二处理单元或所述第三单元的判断结果，处理第二会话消息的第四处理单元。

本发明的有益效果如下：

1、解决了现有方案中未考虑新旧会话在S-CSCF处可能存在无须关联的情况，如新旧会话代表不同用户，由此导致的AS构造的ROUTE头域内容应不同，避免引起S-CSCF的检测及处理混乱。

2、在进行URI的比较时引入了通配规则比较，从而避免了因现有技术中因不考虑存在通配符的情况而不能正确完成逻辑处理的问题。

附图说明

图1A为现有技术中AS充当Originate模式的示意图；

图1B为现有技术中AS充当B2BUA模式的示意图；

图2为本发明中AS处理B2BUA呼叫的流程图；

图3A、3B为本发明中AS分别处于主叫模式和被叫模式确定业务逻辑关联的流程图；

图4为本发明中S-CSCF处理B2BUA呼叫的流程图；

图5为本发明中在IMS网络中匹配任意两个URI的流程图；

图6为本发明中AS的结构示意图；

图7为本发明中S-CSCF的结构示意图。

具体实施方式

在IMS网络中，影响呼叫业务逻辑处理的两个关键头域为P-Asserted-Identity头域和Request-URI头域。在B2BUA模式下，若应用服务器(AS)从S-CSCF接收到的第一会话消息和AS产生的第二会话消息在业务逻辑上没有关联关系，AS在第二会话消息中对这两个头域都有可能进行修改。为了使业务-呼叫会话控制功能(S-CSCF)能够正确的检测和处理AS转发来第二会话消息，本发明中AS根据前后会话消息是否在业务逻辑上相关联来产生相应的Route头域。

确定前后会话消息是否在业务逻辑上相关联可以有以下两种方式：

1、AS所执行的业务逻辑本身决定了是否会修改P-ASSERT-IDENTITY头域，因此AS在选择业务时即可确定前后会话是否关联，并根据这个关联结果处理会话，即由业务逻辑的设计者决定前后业务是否需要关联。当然并不限于通过是否修改P-ASSERT-IDENTITY头域来确定。

2、AS根据处理会话消息的业务逻辑来判断第二会话消息与第一会话消息在S-CSCF实体上是否需要关联。

采用上述两种方式中任意一种确定前后业务是否需要关联后的后续处理流程相同，因此，以下主要以第二种方式为例进行说明：

参阅图2所示，AS处理B2BUA呼叫的主要过程如下(以下流程并未包括AS处理B2BUA呼叫的所有步骤)：

步骤100、AS接收S-CSCF实体转发的第一会话消息并按业务逻辑进行处理。

步骤110、根据业务逻辑产生第二会话消息，并在产生第二会话消息的过程中，判断第二会话消息与第一会话消息的业务逻辑在S-CSCF实体上是否需要关联；若是，则进行步骤120，若否，则进行步骤130。

在此过程中，AS也可根据所选择的业务本身，判断第二会话消息与第一会话消息的业务逻辑在S-CSCF实体上是否需要关联；若是，则进行步骤120，若否，则进行步骤130。

步骤120、AS将第一会话消息中Route头域去掉AS的统一资源标识后拷贝到第二会话消息中，作为第二会话消息的Route头域，继续步骤140。

步骤130、AS按始发方式重新构造第二会话消息的Route头。

步骤140、AS向S-CSCF实体发送第二会话消息。

对于一个会话，AS可能是处理主叫，也可能是处理被叫。AS可以根据初始过滤规则(iFC)的签约数据来区分AS所处理的IMPU为主叫用户还是被叫用户，据此，AS收到从S-CSCF转发的会话消息后可以判断自己是处于主叫还是被叫处理模式。例如，AS在签约的iFC中注明ORIG-AS，在根据iFC处理而需要将消息路由给AS时带上ORIG-AS信息。这样AS就知道自己处于主叫侧，需要处理P-Asserted-Identity，否则AS知道自己处于被叫侧，需要处理Request-URI信息。当然，并不限于此，也可通过AS的URI中的特殊标识，或特殊端口来区分是处理主叫，还是处理被叫。

在生成第二会话消息的过程中，AS需要根据业务逻辑判断第二会话消息与第一会话消息的业务逻辑在S-CSCF实体上是否需要关联，以此业生成相关信息以通知S-CSCF。本发明在生成Route头域时，可以直接利用该判断结果；也可以检测生成的相关信息来获知第二会话消息与第一会话消息的业务逻辑在S-CSCF实体上是否关联。在检测时，若AS处于主叫模式，主要依据两个会话消息中P-Asserted-Identity头域的内容进行判断；若AS处于被叫模式时，主要依据两个会话消息中Request-URI头域的内容标识进行判断。在对第一、第二会话消息中的P-Asserted-Identity和Request-URI进行比较时，需要考虑存在通配符的情况。

参阅图3A所示，AS处于主叫模式时，检测获知第一会话消息和第二会话消息的业务逻辑是否关联的主要步骤如下：

步骤200、获取第一会话消息和第二会话消息中的P-Asserted-Identity。

步骤210、按照RFC3261标准(第19章的比较规定)判断第一、第二会话的P-Asserted-Identity是否相同，若相同，则进行步骤240；若不相同，则进行步骤220。

步骤220、判断P-Asserted-Identity中是否包含通配符，若包含通配符，则进行步骤230，否则，进行步骤250。

步骤230、按3GPP TS23.003第13.5节中通配规则描述，判断第一会话消息和第二会话消息中的P-Asserted-Identity是否相同，若相同，则进行步骤240，否则，进行步骤250。

步骤240、AS确定第一会话消息和第二会话消息的业务逻辑在S-CSCF上关联。

步骤250、AS确定第一会话消息和第二会话消息的业务逻辑在S-CSCF上不关联。

根据业务逻辑处理的需要，AS判断的依据也可以是第一会话消息和第二会话消息中P-Asserted-Identity和Request-URI的组合。也就是，AS在第一会话消息与第二会话消息中的P-Asserted-Identity一致后，还可进一步判断这两个会话消息中的Request-URI是否一致作为判断的参考。如，若P-Asserted-Identity一致，而Request-URI不一致，此时也可以认为第一会话消息和第二会话消息的业务逻辑在S-CSCF上不需要关联。

参阅图3B所示，AS处于被叫模式时，判断第一会话消息和第二会话消息的业务逻辑是否需要关联的主要步骤如下：

步骤300、获取第一会话消息和第二会话消息中的Request-URI。

步骤310、按照RFC3261标准(第19章的比较规定)判断第一、第二会话的Request-URI是否相同；若相同，则进行步骤340；若不相同，则进行步骤320。

步骤320、判断Request-URI中是否包含通配符，若包含通配符，则进行步骤330，否则，进行步骤350。

步骤330、按3GPP TS23.003第13.5节中通配规则描述，判断第一会话消息和第二会话消息中的Request-URI是否相同，若相同，则进行步骤340，否则，进行步骤350。

步骤340、AS确定第一会话消息和第二会话消息的业务逻辑在S-CSCF上关联。

步骤350、AS确定第一会话消息和第二会话消息的业务逻辑在S-CSCF上不关联。

同样，AS在判断Request-URI一致后，还可进一步判断这两个会话消息中P-Asserted-Identity是否相同作为判断参考。

AS也可在第二会话消息中加入信息，提示S-CSCF是否需要后续iFC处理。该标识可以为上述的Route头域拷贝原先的Route头域，或者Route头域拷贝原先的Route头域同时P-Asserted-Identity或Request-URI按照SIPURI或Tel-URL比较规则未修改。

对于S-CSCF而言，在接收到AS发送的第二会话消息后，如果检测到其中携带有ORIG-DIALOG ID标识，直接根据该ORIG-DIALOG ID匹配到第一会话消息(即原先的老会话)；然后，根据第二会话消息中给出的是否需要后续iFC处理标识进行相应的处理。如果S-CSCF在第二会话消息中未检测到ORIG-DIALOG ID标识，则认为该消息为新的会话消息，直接按照目前标准已有方法处理该会话消息。

对于AS按上述方法产生的第二会话消息，S-CSCF实体可以直接依据Route头域对第二会话进行后续iFC检测和处理(因在AS已确定第一、第二会话需要关联后才会将第一会话中的Route头域拷贝到第二会话消息中)。但为了在与AS配合时尽可能少的改动现有S-CSCF的处理机制，或者使S-CSCF能够兼容不具有上述处理能力的AS，S-CSCF在根据ORIG-DIALOG ID标识匹配到第一会话消息后，可进一步依据SIP URI或Tel-URL判别规则，确定新旧会话中的P-Asserted-Identity或Request-URI是否需要后续iFC处理。

S-CSCF可以根据第一会话消息中的信息确定自己是在处理主叫侧会话消息还是在处理被叫侧会话消息，若S-CSCF确定在处理主叫侧会话消息，则主要根据P-Asserted-Identity对AS转发来的会话消息进行iFC检测和处理；若S-CSCF确定在处理被叫侧会话消息，则主要根据Request-URI对AS转发来的会话消息进行iFC检测和处理。在对第一、第二会话消息中的P-Asserted-Identity和Request-URI进行比较时，应当考虑存在通配符的情况。

参阅图4所示，S-CSCF处于主叫模式时，处理AS发送来的第二会话消息的主要步骤如下：

步骤400、S-CSCF实体接收到第二会话消息。

步骤410、检测Route头域中是否有ORIG-DIALOG ID标识，若有，则进行步骤420，否则进行步骤480。

步骤420、S-CSCF根据ORIG-DIALOG ID标识查找到相匹配的第一会话消息。

步骤430、按照RFC3261标准(第19章的比较规定)判断第一、第二会话的P-Asserted-Identity是否相同，若相同，则进行步骤460；若不相同，则进行步骤440。

步骤440、判断P-Asserted-Identity中是否包含通配符，若包含通配符，则进行步骤450，否则，进行步骤470。

步骤450、按3GPP TS23.003第13.5节中通配规则描述，判断第一会话消息和第二会话消息中的P-Asserted-Identity是否匹配，若匹配，则进行步骤460，否则，进行步骤470。

步骤460、确定第一会话消息和第二会话消息的业务逻辑相关联，对第二会话消息进行后续的iFC检测和处理。

步骤470、确定第一会话消息和第二会话消息的业务逻辑不关联，S-CSCF不再进行iFC检测处理，而按照Route头域和Request-URI确定下一跳，随后将第二会话消息转发给下一跳。

步骤480、S-CSCF实体按新会话处理第二会话消息。

S-CSCF处于被叫模式时，处理AS发送来的第二会话消息除了判断第一、第二会话中的Request-URI与处于主叫模式时不同外，其余处理同理，不再赘述。

参阅上述图3A、3B和图4中的描述，可以得知本发明中匹配URI的方法可以用到IMS网络的任何场景中对URI进行比较，如图5所示，其主要步骤如下：

步骤500、按照RFC3261标准(第19章的比较规定)判断待匹配的两个URI是否相同；若相同，则转步骤，若不相同，则继续步骤510。

步骤510、进一步判断URI中是否包含中通配符，若不包含通配符，则转发步骤，若包含通配符，则继续步骤520。

步骤520、按3GPP TS23.003第13.5节中通配规则描述，判断两个URI是否相同，若相同，则继续步骤530，否则，转步骤540。

步骤530、确定该两个URI匹配。

步骤540、确定两个URI不匹配。

参阅图6所示，本发明实现上述方法的应用服务器(AS)60包括：第一业务逻辑处理单元600和第二业务逻辑处理单元601(实现现有基本功能的其他功能模块在图中未出)。

第一业务逻辑处理单元600，用于处理业务-呼叫会话控制功能(S-CSCF)实体转发的第一会话消息。

第二业务逻辑处理单元601，与第一业务逻辑处理单元600具有逻辑上的连接关系，用于产生第二会话消息，并在生产第二会话过程中根据第二会话消息与第一会话消息的业务逻辑在S-CSCF实体上是否需要关联为第二会话消息产生头对应的Route头域；在需要关联时，将第一会话消息的Route头域去掉AS的统一资源标识后作为第二会话消息的Route头域，在不需要关联时，按始发方式重新构造第二会话消息的Route头域。

第二业务逻辑处理单元601包括第一模块6010、第二模块6011和第三模块6012，其中：

第一模块6010，用于判断第一会话消息与第二会话消息中相关的信息是否相同。

第二模块6011，与第一模块6010具有逻辑上的连接关系，用于在第一模块判断所述相关的信息不同且其中包含通配标识符时，判断第一会话消息与第二会话消息中相关的信息是否匹配。

第三模块6012，与第二模块6011，用于根据第一模块或第二模块的判断结果，产生相应的Route头域。

参阅图7所示，本发明实现上述方法的业务-呼叫会话控制功能(S-CSCF)实体70包括：第一处理单元700、第二处理单元701、第三处理单元702和第四处理单元703(实现现有基本功能的其他功能模块在图中未出)。其中：

第一处理单元700，确定接收到的第二会话消息是否包含相关的关联会话标识，并在确定包含关联会话标识时查找到相匹配的第一会话消息。

第二处理单元701，与第一处理单元701具有逻辑上的连接关系，用于判断第一会话消息与第二会话消息中相关的信息是否相同。

第三处理单元702，与第二处理单元702具有逻辑上的连接关系，用于在第二处理单元判断所述相关的信息不同且其中包含通配标识符时，按通配规则判断第一会话消息与第二会话消息中相关的信息是否匹配。

第四处理单元703，与第二处理单元701和第三处理单元702具有逻辑上的连接关系，用于根据所述第二处理单元或所述第三单元的通知处理第二会话消息。

以下通过一个具体实例进一步说明，该具体实例仅列出包含与本发明相关的主要内容的会话消息片断，对于各消息的其他细节请参考相关标准。

1、AS在主叫侧处理，判断S-CSCF前后业务逻辑不需要关联

(1)S-CSCF外部收到的会话消息(片断)如下：

F1

.....

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob<sip：bob@biloxi.com>

From：Alice<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66710

Route：s-cscf1@biloxi.com

P-Asserted-Identity：″John Doe″<sip：user1_public1@home1.net>

S-CSCF执行相关的业务逻辑，决定将消息转发给AS。

(2)AS从S-CSCF实体接收到的第一会话消息(片断)如下：

F2

.....

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob<sip：bob@biloxi.com>

From：Alice<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66710

Route：<AS@biloxi.com>，<ORIG_DILAG ID@biloxi.com>

P-Asserted-Identity：″John Doe″<sip：user1_public1@home1.net>

(3)AS根据业务逻辑，发现须修改P-Asserted-Identity，由此判断在S-CSCF处前后业务逻辑无须关联，因此重新构造ROUTE头域，此时CALLID也会修改。AS产生的第二会话消息(片断)如下：

F3

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob2<sip：bob@biloxi.com>

From：Alice2<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66721

Route：<S-CSCF@biloxi.com；Orig>

P-Asserted-Identity：″TOM″<sip：user2_public1@home1.net>

(4)S-CSCF接收到AS发送的第二会话消息后，未检测到ORIG-DIALOGID，判断为一新的主叫会话，重新按照一新的iFC处理。处理后的会话消息(片断)如下：

F4

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob2<sip：bob@biloxi.com>

From：Alice2<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66721

P-Asserted-Identity：″TOM″<sip：user2_public1@home1.net>

2、AS在主叫侧处理，判断S-CSCF前后业务逻辑需要关联

(1)S-CSCF收到的会话消息(片断)如下：

F1

.....

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob<sip：bob@biloxi.com>

From：Alice<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66710

Route：s-cscf1@biloxi.com

P-Asserted-Identity：″John Doe″<sip：user1_public1@home1.net>

S-CSCF执行相关的业务逻辑，决定将消息转发给AS。

(2)AS从S-CSCF实体接收到的第一会话消息(片断)如下：

F2

.....

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob<sip：bob@biloxi.com>

From：Alice<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66710

Route：<AS@biloxi.com>，<ORIG_DILAG ID@biloxi.com>

P-Asserted-Identity：″John Doe″<sip：user1_public1@home1.net>

(3)AS根据业务逻辑，发现不修改P-Asserted-Identity，由此判断在S-CSCF处前后业务逻辑须关联，因此拷贝原先的ROUTE头域。AS产生的第二会话消息(片断)如下：

F3

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob2<sip：bob@biloxi.com>

From：Alice2<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66721

Route：<ORIG_DILAG ID@biloxi.com>

P-Asserted-Identity：″John Doe″<sip：user1_public1@home1.net>

(4)S-CSCF接收到第二会话消息后，检测到ORIG-DIALOG ID，判断为与一老会话关联，且发现P-Asserted-Identity未改变，继续原有的iFC处理。处理后的会话消息(片断)如下：

F4

INVITE sip：bob@biloxi.com SIP/2.0

To：Bob2<sip：bob@biloxi.com>

From：Alice2<sip：alice@atlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66721

P-Asserted-Identity：″John Doe″<sip：user1_public1@home1.net>

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1、一种在IMS网络中的B2BUA模式下处理会话消息的方法，IMS网络的应用服务器(AS)接收业务-呼叫会话控制功能(S-CSCF)实体转发的第一会话消息；AS产生和发送第二会话消息，并且在产生第二会话消息的过程中判断第二会话消息与第一会话消息在S-CSCF实体上是否需要关联；其特征在于：

2、如权利要求1所述的方法，其特征在于，AS根据选择的业务逻辑本身确定前后会话是否相关联，即由业务逻辑的设计者决定前后业务是否需要关联。

3、如权利要求1所述的方法，其特征在于，AS根据处理会话消息的业务逻辑来判断第二会话消息与第一会话消息在S-CSCF实体上是否需要关联。

4、如权利要求3所述的方法，其特征在于，AS在为第二会话消息生成Route头域时，进一步比较第二会话消息中已生成的相关信息与第一会话消息中对应的相关信息，并根据比较结果为第二会话消息生成相应的Route头域。

5、如权利要求4所述的方法，其特征在于，比较第二会话消息中已生成的相关信息与第一会话消息中对应的相关信息包括如下步骤：

(1)、判断第一会话消息、第二会话消息中相关的信息是否相同，若相同，则确定需要关联；若不相同，则继续步骤(2)；

(2)、判断所述相关信息中是否包含中通配符，若包含通配符，则进行步骤(3)，否则，确定不需要关联；

(3)、按通配规则判断第一会话消息和第二会话消息中相关的信息是否匹配，若匹配，则确定需要关联，否则，确定不需要关联。

6、如权利要求3所述的方法，其特征在于，AS确定处于处理主叫时，所述相关的信息为第一、第二会话消息中用于标识呼叫始发端的用户标识(P-Asserted-Identiy)；或者

AS确定处于处理被叫时，所述相关的信息为第一会话消息和第二会话消息中用于标识目的端的用户标识(Request-URI)，或，所述相关的信息为第一会话消息和第二会话消息中用于标识呼叫始发端的用户标识(P-Asserted-Identiy)和用于标识目的端的用户标识(Request-URI)组合成的标识。

7、如权利要求6所述的方法，其特征在于，AS通过初始过虑规则(iFC)的签约数据区分目前处于处理主叫模式还是处理被叫模式。

8、如权利要求1至7任一项所述的方法，其特征在于，接收到第二会话消息的业务-呼叫会话控制功能实体(S-CSCF)进行下述步骤：

9、如权利要求8所述的方法，其特征在于，第一会话消息和第二会话消息的业务逻辑相关联时的后续处理包括后续iFC处理。

10、如权利要求8所述的方法，其特征在于，判断相关的信息是否匹配包括步骤：

(1)、判断第一会话消息、第二会话消息中相关的信息是否相同，若相同，则确定相关的信息匹配；若不相同，则继续步骤(2)；

(2)、判断所述相关的信息中是否包含通配符，若包含通配符，则进行步骤(3)，否则，确定所述相关的信息不匹配；

(3)、按通配规则判断第一会话消息和第二会话消息中相关的信息标识是否匹配。

11、如权利要求8所述的方法，其特征在于，S-CSCF实体确定处于处理主叫时，所述相关的用户标识为第一会话消息和第二会话消息中的用于标识呼叫始发端的用户标识(P-Asserted-Identiy)；或者

S-CSCF实体确定处于处理被叫时，所述相关的用户标识为第一会话消息和第二会话消息中用于标识目的端的用户标识(Request-URI)，或，所述相关的用户标识为第一会话消息和第二会话消息中用于标识呼叫始发端的用户标识(P-Asserted-Identiy)和用于标识目的端的用户标识(Request-URI)组合成的标识。

12、一种在IMS网络中的B2BUA模式下处理会话消息的方法，其特征在于，包括如下步骤：

13、如权利要求12所述的方法，其特征在于，步骤E中所述后续处理包括后续iFC处理。

14、如权利要求12所述的方法，其特征在于，S-CSCF实体确定处于处理主叫时，所述相关的用户标识为第一会话消息和第二会话消息中的用于标识呼叫始发端的用户标识(P-Asserted-Identiy)；或者

S-CSCF实体确定处于被叫模式时，所述相关的用户标识为第一会话消息和第二会话消息中用于标识目的端的用户标识(Request-URI)，或者，所述相关的用户标识为第一会话消息和第二会话消息中用于标识呼叫始发端的用户标识(P-Asserted-Identiy)和用于标识目的端的用户标识(Request-URI)组合成的标识。

15、一种在IMS网络中匹配URI的方法，其特征在于，包括如下步骤：

16、一种IMS网络中的应用服务器，其特征在于，包括：

17、如权利要求16所述的应用服务器，其特征在于，所述第二业务处理单元包括：

18、一种在IMS网络中用于业务控制的网络设备，其特征在于，包括：