CN103209165B - Ims中的应用服务器框架以及转发会话控制逻辑的方法 - Google Patents

Abstract

本发明提供了一种在IP多媒体子系统中提供应用的方法，其包括：定义应用服务器框架；将会话控制逻辑经由SIP消息由外部传入所述应用服务器框架，和/或将会话控制逻辑以脚本形式预存储在所述应用服务器框架中，和/或通过应用程序接口将会话控制逻辑传入所述应用器框架。同时，还提供了一种在IP多媒体子系统的应用服务器框架中处理SIP请求的方法，其包括以下步骤：接收来自用户终端的SIP请求；评估从HSS处获取的与所述用户终端关联的初始过滤准则；如果条件满足，将从所述HSS处获取的与所述用户终端关联的会话控制逻辑相关信息添加入所述SIP请求；以及将添加了所述会话控制逻辑相关信息的所述SIP请求发送至所述初始过滤准则所指定的应用服务器框架。

Description

IMS中的应用服务器框架以及转发会话控制逻辑的方法

技术领域

本发明涉及IMS(IP多媒体子系统)，特别地涉及一种应用服务器框架，以及在S-CSCF(服务-呼叫/会话控制功能)中转发SIP请求的方法和装置，和在应用服务器框架中接收并处理SIP请求的方法和装置。

背景技术

IMS网络的一个重要特点是其在SIP应用服务器上快速部署各种功能的能力。尽管在IMS网络中对于SIP接口有明确的标准，但是新建立一个应用服务器并且以适当的方式为其分配功能仍需要系统设计者考虑所有必要的结构。这也是大多数开发者选择基于已有的应用服务器进行附加的开发而不愿从头开始建立一个应用服务器的重要原因之一。然而，在已有的应用服务器上进行附加的开发必须依赖于已有的应用服务器，并且即使当应用逻辑只是简单地修改信令内容，仍然会产生大量的开销。

以基于位置的路由为例，如果所期望实现的功能是当各个用户从不同位置接入网络时，给每个用户一个选项以显示不同的呼叫线路标识(callinglineID)，那么，简单的逻辑将会是匹配PANI(P-Access-Network-Info)头部并且以预定义的SIPURI替换PANI头部。上述逻辑看似简单，但是仍需要在已有的应用服务器上进行开发工作，或者在一个新建立的应用服务器上进行开发工作，这往往需要较长的开发周期。

发明内容

基于上述考虑，本发明提供了一种应用服务器框架，其可以构建在独立的服务器上，或者构建在已有的应用服务器上，或者构建在S-CSCF上。一些适用于所有用户终端的会话控制逻辑可以预先定义并存储在该应用服务器框架中，而适用于每个用户终端的各自的会话控制逻辑则是由S-CSCF在该用户终端注册时从HSS中获取并经由SIP注册请求(REGISTERRequest)或其他SIP请求转发给该应用服务器框架。之后，当应用服务器框架接收到对应于某个用户终端的SIP请求后，其将基于适用于所有用户终端的会话控制逻辑以及适用于该用户终端的会话控制逻辑处理该SIP请求从而实现应用服务器的功能。

可选的，会话控制逻辑可以通过XML语言(ExtensibleMarkupLanguage)定义。当然，其也可以通过其他任何适合的语言来定义，例如，C语言，或者Java语言等。

基于此，本发明在一个实施例中提供了一种在IP多媒体子系统中提供应用的方法，其中，所述方法包括以下步骤：i.定义应用服务器框架；ii.将会话控制逻辑经由SIP请求由外部传入所述应用服务器框架，和/或将会话控制逻辑以脚本形式预存储在所述应用服务器框架中，和/或通过应用程序接口将会话控制逻辑传入所述应用器框架。

本发明在另一个实施例中提供了一种在IP多媒体子系统的S-CSCF中转发SIP请求的方法，其中，所述方法包括以下步骤：a.接收来自用户终端的SIP请求；b.评估从HSS处获取的与所述用户终端关联的初始过滤准则；c.如果条件满足，将从所述HSS处获取的与所述用户终端关联的会话控制逻辑相关信息添加入所述SIP请求；d.将添加了所述会话控制逻辑相关信息的所述SIP请求发送至所述初始过滤准则所指定的应用服务器框架。

当所述SIP请求为SIPREGISTER请求时，所述步骤a之后，所述步骤b之前还包括以下步骤：从所述HSS处下载与所述用户终端关联的用户档案，其中所述用户档案中包括与所述用户终端关联的初始过滤准则以及与所述用户终端关联的所述会话控制逻辑相关信息。

本发明在又一个实施例中提供了一种在IP多媒体子系统的应用服务器框架中处理SIP请求的方法，其中，所述方法包括以下步骤：A.接收来自S-CSCF的SIP请求，所述SIP请求中包括与用户终端相关联的会话控制逻辑相关信息；B.从所述SIP请求中提取所述会话控制逻辑相关信息，并存储与所述用户设备相关联的会话控制逻辑。

可选的，所述步骤B之后还包括以下步骤：C.基于预先定义的会话控制逻辑以及所存储的与所述用户设备相关联的所述会话控制逻辑处理所述SIP请求。

通过应用本发明的技术方案，使得应用服务的开发工作变得更为快捷和灵活。

附图说明

通过对结合附图所示出的实施例进行详细说明，本发明的上述以及其他特征将更加明显，本发明附图中相同的标号表示相同或相似的部件。在附图中：

图1示出了根据本发明的一个实施例的应用服务器框架的示意图；

图2示出了根据本发明的一个实施例的S-CSCF、HSS和应用服务器框架交互的网络示意图；

图3示出了根据本发明的一个实施例的S-CSCF通过SIP注册请求将会话控制逻辑转发给应用服务器框架的方法流程图。

具体实施方式

本发明的主要构思之一在于：定义一种新的应用服务器框架；并且将会话控制逻辑经由SIP请求由外部传入该应用服务器框架，和/或将会话控制逻辑以脚本形式预存储在该应用服务器框架中，和/或通过应用程序接口将会话控制逻辑传入所述应用器框架。

以下结合图1对根据本发明的一个实施例的应用服务器框架进行描述。

参照图1，应用服务器框架10提供了可实现一种或多种功能的基础架构(infrastructure)。该一种或多种功能包括但不限于计费报告生成、操作与维护界面、基本冗余和负载平衡控制等。

此外，该应用服务器框架10还包括一个处理模块，用于提取并存储与各个用户终端关联的会话控制逻辑，以及基于这些会话控制逻辑来处理SIP请求。这将在下文中进行详细说明。

进一步地，该应用服务器框架10还提供了图形用户界面(GUI)，其可用于模拟所存储的会话控制逻辑，以验证是否可以实现相关功能。此外，该图形用户界面还可用于实现操作，管理和维护的目的。

除此之外，该应用服务器框架10还包括SIP协议栈和Diameter协议栈、TCP\UDP协议栈、IP协议栈(其可支持IPv6和IPv4)。

该应用服务器框架10可以构建在独立的服务器上，或者构建在已有的应用服务器上，或者构建在S-CSCF上等。

需要说明的是，图1示出的应用服务器框架10仅是示例性而非限制性的，本领域技术人员可以理解，任何能够实现本发明构思的应用服务器框架均在本专利的保护范围内。

正如在上文中发明内容部分所述，一些适用于所有用户终端的会话控制逻辑可以预先定义并存储在该应用服务器框架10中并通过图形用户界面进行模拟和验证，而适用于每个用户终端的各自的会话控制逻辑则是由S-CSCF在该用户终端注册时从HSS中获取并经由SIP注册请求或其他SIP请求转发给该应用服务器框架10的。

以下将参照图2、3并结合图1，对由S-CSCF通过SIP注册请求将会话控制逻辑转发给应用服务器框架的方案进行描述。

参见图2和图3，在步骤S31中，S-CSCF20接收来自用户终端UE的SIP注册请求。当认证成功后，在步骤S32中，S-CSCF20从HSS30(归属用户服务器)处下载与该用户终端UE相关联的用户档案(userprofile)。该用户档案中包括与该用户终端UE相关联的初始过滤准则以及与该用户终端UE相关联的会话控制逻辑相关信息。在一个实施例中，会话控制逻辑相关信息可以位于初始过滤准则中的ServiceInformation字段中。当然，在其他实施例中，会话控制逻辑也可以独立于初始过滤准则而存在于用户档案中。

该会话控制逻辑相关信息可以是与该用户终端UE相关联的会话控制逻辑本身；或者，为了节省传输开销，会话控制逻辑相关信息也可以是与该用户终端UE相关联的会话控制逻辑的索引。在会话控制逻辑相关信息是会话控制逻辑索引的情形下，在应用服务器框架10中需要存储有与所有用户终端相关联的会话控制逻辑，以用于根据会话控制逻辑索引查找到相应的会话控制逻辑。

当S-CSCF20从HSS30处下载了与用户终端UE相关联的用户档案后，在步骤S33中，S-CSCF20对用户档案中包括的与该用户终端UE相关联的初始过滤准则进行评估。如果该SIP注册请求与初始过滤准则匹配，则在步骤S34中，S-CSCF20将与该用户终端UE相关联的会话控制逻辑相关信息添加到SIP注册请求中，并向初始过滤准则所指定的应用服务器框架10发送第三方注册请求。

然后，在步骤S35中，应用服务器框架10接收来自S-CSCF20的SIP注册请求。接着，在步骤S36中，应用服务器框架10从接收到的SIP注册请求中提取与该用户终端UE相关联的会话控制逻辑相关信息，并存储与该用户终端UE相关联的会话控制逻辑。具体地，当会话控制逻辑相关信息是与用户终端UE相关联的会话控制逻辑本身时，那么应用服务器框架10直接从接收到的SIP注册请求中提取与用户终端UE相关联的会话控制逻辑并存储；当会话控制逻辑相关信息是与用户终端UE相关联的会话控制逻辑的索引时，应用服务器框架10从接收到的SIP注册请求中提取了与用户终端UE相关联的会话控制逻辑的索引后，根据该索引查找与用户终端10相关联的会话控制逻辑并存储。

可选的，当应用服务器框架10提取了与该用户终端UE相关联的会话控制逻辑后，可以基于已存储的适用于所有用户终端的会话控制逻辑以及已提取的与该用户终端UE相关联的会话控制逻辑对该SIP注册请求进行处理。

之后，当应用服务器框架10接收到对应于该用户终端UE的其他SIP请求，例如，INVITE请求后，可以基于已存储的适用于所有用户终端的会话控制逻辑以及适用于该用户终端UE的会话控制逻辑对该SIP请求进行处理。当然，如果应用服务器框架10中并未存储适用于所有用户终端的会话控制逻辑，那么，应用服务器框架10将仅基于已存储的适用于该用户终端UE的会话控制逻辑对该SIP请求进行处理。

在其他实施例中，与用户终端UE关联的会话控制逻辑相关信息也可以通过其他SIP请求转发至应用服务器框架10。具体地，可以在初始过滤准则中定义通过哪种SIP请求将会话控制逻辑相关信息转发给应用服务器框架。

以S-CSCF20通过SIPINVITE请求转发会话控制逻辑相关信息为例，当S-CSCF20接收到来自用户终端UE的SIPINVITE请求后，其首先对初始过滤准则进行评估(该初始过滤准则是在用户终端UE注册时，S-CSCF20从HSS30处下载并存储的)，如果该SIPINVITE请求与初始过滤准则匹配，则S-CSCF20将与该用户终端UE相关联的会话控制逻辑相关信息(该会话控制逻辑相关信息是在用户终端UE注册时，S-CSCF20从HSS30处下载并存储的)添加到SIPINVITE请求中，并向初始过滤准则所指定的应用服务器框架10转发该SIPINVITE请求。

在本发明中会话控制逻辑可以通过XML语言定义，或者任何其他适合的语言来定义。

例如，可以定义一种新的XML语言，称为SIMXL(ServiceInformationXML)，其中可以定义一些XML元素，如下：

●框架类型<Type>(例如，SIP代理，或背对背用户代理)

●SIP方法<Method>

●SIP方向<Direction>

●采取的动作<Action>(例如，拒绝呼叫，呼叫转移等)

●SIP头字段<Header>

●SIP内容<Content>

●媒体动作<Media>(针对背对背用户代理)

相应地，本地函数调用可以如下定义：

●stringmethod()：返回SIP方法

●stringdirection()：返回消息方向

●nullrespond(return_code)：返回响应

●arrayheader_all()：返回头字段阵列

●booleanheader(_header)：验证某种头字段的存在

●stringheader_content(_header)：返回头字段的内容

●arraycontent_all()：返回SIP内容的阵列

需要说明的是，以上列举的XML元素仅是示例性的，在实际应用中，还可以包括其他XML元素，例如<log>，<charging>等，以便于应用服务器框架实现多种不同的功能。

此处再次以基于位置的路由功能为例，假设需要在P-Access-Network-Info中dsl位置标识为“1234”时，将呼叫方号码改成+862112345678，那么，一种SIXML语言可定义如下：

在本发明的另一方面，还提供了一种在IP多媒体子系统的S-CSCF中转发SIP请求的装置，其中，所述装置包括：

第一接收装置，用于接收来自用户终端的SIP请求；

评估装置，用于评估从HSS处获取的与所述用户终端关联的初始过滤准则；

添加装置，用于如果条件满足，将从所述HSS处获取的与所述用户终端关联的会话控制逻辑相关信息添加入所述SIP请求；

发送装置，用于将添加了所述会话控制逻辑相关信息的所述SIP请求发送至所述初始过滤准则所指定的应用服务器框架。

可选的，当所述SIP请求为SIPREGISTER请求时，所述装置还包括：

第二接收装置，用于从所述HSS处下载与所述用户终端关联的用户档案，其中所述用户档案中包括与所述用户终端关联的初始过滤准则以及与所述用户终端关联的所述会话控制逻辑相关信息。

可选的，所述会话控制逻辑相关信息位于所述初始过滤准则中的ServiceInformation字段中。

所述会话控制逻辑相关信息可以是与所述用户终端关联的会话控制逻辑本身，或者可以是与所述用户终端关联的会话控制逻辑的索引。

可选的，所述会话控制逻辑通过XML语言定义。

此外，还提供了一种在IP多媒体子系统的应用服务器框架中处理SIP请求的装置，其中，所述装置包括：

第三接收装置，用于接收来自S-CSCF的SIP请求，所述SIP请求中包括与用户终端相关联的会话控制逻辑相关信息；

提取装置，用于从所述SIP请求中提取所述会话控制逻辑相关信息，并存储与所述用户设备相关联的会话控制逻辑。

可选的，所述装置还包括：

处理装置，用于基于预先定义的会话控制逻辑以及所存储的与所述用户设备相关联的所述会话控制逻辑处理所述SIP请求。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，明显的，“包括”一词不排除其他元件或步骤，在元件前的“一个”一词不排除包括“多个”该元件。产品权利要求中陈述的多个元件也可以由一个元件通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (12)

1.一种在IP多媒体子系统的S-CSCF中转发SIP请求的方法，其中，所述方法包括以下步骤：

a.接收来自用户终端的SIP请求；

b.评估从HSS处获取的与所述用户终端关联的初始过滤准则；

c.如果条件满足，将从所述HSS处获取的与所述用户终端关联的会话控制逻辑相关信息添加入所述SIP请求；

d.将添加了所述会话控制逻辑相关信息的所述SIP请求发送至所述初始过滤准则所指定的应用服务器框架。

2.根据权利要求1所述的方法，其特征在于，当所述SIP请求为SIPREGISTER请求时，所述步骤a之后，所述步骤b之前还包括以下步骤：

-从所述HSS处下载与所述用户终端关联的用户档案，其中所述用户档案中包括与所述用户终端关联的初始过滤准则以及与所述用户终端关联的所述会话控制逻辑相关信息。

3.根据权利要求2所述的方法，其特征在于，所述会话控制逻辑相关信息位于所述初始过滤准则中的ServiceInformation字段中。

4.根据权利要求1所述的方法，其特征在于，所述会话控制逻辑相关信息是与所述用户终端关联的会话控制逻辑本身，或者是与所述用户终端关联的会话控制逻辑的索引。

5.根据权利要求4所述的方法，其特征在于，所述会话控制逻辑通过XML语言定义。

6.一种在IP多媒体子系统的应用服务器框架中处理SIP请求的方法，其中，所述方法包括以下步骤：

A.接收来自S-CSCF的SIP请求，所述SIP请求中包括与用户终端相关联的会话控制逻辑相关信息；

B.从所述SIP请求中提取所述会话控制逻辑相关信息，并存储与所述用户终端相关联的会话控制逻辑；

C.基于预先定义的适用于所有用户终端的会话控制逻辑以及所存储的与所述用户终端相关联的所述会话控制逻辑处理所述SIP请求。

7.根据权利要求6所述的方法，其特征在于，所述控制逻辑相关信息是与所述用户终端关联的会话控制逻辑本身，或者是与所述用户终端关联的会话控制逻辑的索引。

8.根据权利要求7所述的方法，其特征在于，当所述控制逻辑相关信息是与所述用户终端关联的会话控制逻辑的索引时，所述步骤B还包括：

-基于所提取的所述会话控制逻辑相关信息，获取并存储与所述用户终端相关联的所述会话控制逻辑。

9.一种在IP多媒体子系统的S-CSCF中转发SIP请求的装置，其中，所述装置包括：

第一接收装置，用于接收来自用户终端的SIP请求；

评估装置，用于评估从HSS处获取的与所述用户终端关联的初始过滤准则；

添加装置，用于如果条件满足，将从所述HSS处获取的与所述用户终端关联的会话控制逻辑相关信息添加入所述SIP请求；

发送装置，用于将添加了所述会话控制逻辑相关信息的所述SIP请求发送至所述初始过滤准则所指定的应用服务器框架。

10.根据权利要求9所述的装置，其特征在于，当所述SIP请求为SIPREGISTER请求时，所述装置还包括：

第二接收装置，用于从所述HSS处下载与所述用户终端关联的用户档案，其中所述用户档案中包括与所述用户终端关联的初始过滤准则以及与所述用户终端关联的所述会话控制逻辑相关信息。

11.根据权利要求9所述的装置，其特征在于，所述会话控制逻辑相关信息位于所述初始过滤准则中的ServiceInformation字段中。

12.一种在IP多媒体子系统的应用服务器框架中处理SIP请求的装置，其中，所述装置包括：

第三接收装置，用于接收来自S-CSCF的SIP请求，所述SIP请求中包括与用户终端相关联的会话控制逻辑相关信息；

提取装置，用于从所述SIP请求中提取所述会话控制逻辑相关信息，并存储与所述用户终端相关联的会话控制逻辑；

处理装置，用于基于预先定义的适用于所有用户终端的会话控制逻辑以及所存储的与所述用户终端相关联的所述会话控制逻辑处理所述SIP请求。