CN102469066B - 一种消息处理方法及装置 - Google Patents

Abstract

本发明公开了一种消息处理方法及装置，用以在实现同一业务平台同时部署多个业务应用的情况下，避免占用过多的域名(或地址)、端口以及物理设备。本发明提供的一种消息处理方法包括：服务呼叫会话控制功能实体S-CSCF，收到来自主叫用户终端的会话发起协议SIP消息后，根据初始过滤规则iFC的配置，将业务应用App标识添加到该SIP消息的路由Route头域中；S-CSCF将添加有App标识的SIP消息发送给应用服务器AS。

Description

一种消息处理方法及装置

技术领域

本发明涉及通信技术领域，尤其涉及一种消息处理方法及装置。

背景技术

在IP多媒体子系统(IMS，IP Multimedia Subsystem)的架构下，可以在同一个业务平台设备上同时部署多个业务应用，多个业务各自运行，也可以在多个业务平台设备部署多个业务应用。

对于在同一个业务平台设备上同时部署多个业务应用的情况，在业务部署时，不同的业务部署在不同的域(或地址)及端口上。若要在同一应用服务器(AS)设备上部署多个业务应用，需要在该设备上配置多个不同的域及端口，或地址及端口。其应用系统结构如图1所示，图1中的App1、App2、AppN是三个不同的业务应用处理软件包，分属不同的域或地址，并且位于同一AS上。处理过程描述如下：

不同的业务在归属签约用户服务器(HSS，Home Subscriber Server)中的初始过滤规则(iFC，initial Filter Criteria)及应用服务器中，配置不同的域或地址。例如：业务应用1配置为：App2beijing.com；业务应用2配置为：App1xian.com。

会话发起协议(SIP，Session Initiation Protocol)请求(Request)到达呼叫会话控制功能(CSCF，Call Session Control Function)设备后，CSCF根据iFC将业务触发到AS业务平台。触发时，CSCF需要根据iFC中的配置，将相应的域名或地址填写到Route头域中。

AS业务平台收到该请求后，直接根据多个业务的不同的域或地址，进行业务的逻辑控制处理。

对于多个业务部署在不同的业务应用设备上的情况，其应用系统结构如图2所示，图2中的App1、App2、AppN是三个不同的业务应用处理软件包，分属不同的域或地址，并且分别位于不同的AS上。处理过程描述如下：

针对不同的业务，在HSS中的iFC及应用服务器的配置等参数中，配置不同的域或地址；例如：业务应用1配置为：App2beijing.com；业务应用2配置为：App1xian.com。

SIP请求(Request)到达CSCF设备后，CSCF根据iFC将业务触发到不同的AS业务平台。触发时，CSCF需要根据iFC中的配置，将相应的域名或地址填写到Route头域中。

AS业务平台收到该请求后，直接根据多个业务的不同的域或地址，进行业务的逻辑控制处理。

由此可见，现有在AS设备上部署多个业务应用的技术，对域名(或地址)及端口的需求过多，当要进行多个业务部署时，就必须为不同业务申请不同的域名(或地址)标识及端口资源，然而地址资源日益紧张，无法满足大量业务的需求。并且，有多个业务，就需要多台物理设备(即AS)，这在业务用户不多的情况下，或业务发展初期，投入设备过多，造成资源浪费。

发明内容

本发明实施例提供了一种消息处理方法及装置，用以在实现同一业务平台同时部署多个业务应用的情况下，避免占用过多的域名(或地址)、端口以及物理设备。

本发明实施例提供的一种消息处理方法包括：

服务呼叫会话控制功能实体S-CSCF，收到来自主叫用户终端的会话发起协议SIP消息后，根据初始过滤规则iFC的配置，将业务应用App标识添加到该SIP消息的路由Route头域中；

S-CSCF将添加有App标识的SIP消息发送给应用服务器AS。

本发明实施例提供的一种消息处理方法包括：

应用服务器AS接收服务呼叫会话控制功能实体S-CSCF发送的初始会话请求SIP消息；

AS对该SIP消息进行解析，获取该SIP消息的路由Route头域中的业务应用App标识，并且触发与该App标识相对应的业务处理。

本发明实施例提供的一种消息处理装置包括：

第一消息接收单元，用于接收来自主叫用户终端的会话发起协议SIP消息；

App标识添加单元，用于根据初始过滤规则iFC的配置，将业务应用App标识添加到该SIP消息的路由Route头域中；

第一消息发送单元，用于将添加有App标识的SIP消息发送给应用服务器AS。

本发明实施例提供的一种消息处理装置包括：

消息接收单元，用于接收服务呼叫会话控制功能实体S-CSCF发送的初始会话请求SIP消息；

消息解析处理单元，用于对该SIP消息进行解析，获取该SIP消息的路由Route头域中的业务应用App标识，并且触发与该App标识相对应的业务处理。

本发明实施例，S-CSCF收到来自主叫用户终端的SIP消息后，根据iFC的配置，将业务应用App标识添加到该SIP消息的Route头域中；S-CSCF将添加有App标识的SIP消息发送给AS，从而使得AS可以根据App标识来区分不同的业务应用，进而在实现同一业务平台同时部署多个业务应用的情况下，既能节省域名(或地址)以及端口的占用，又无需占用过多的物理设备。

附图说明

图1为多业务应用部署在同一应用平台上的示意图；

图2为多业务应用部署在不同应用平台上的示意图；

图3为本发明实施例提供的一种消息处理方法的流程示意图；

图4为本发明实施例提供的一种消息处理方法的流程示意图；

图5为本发明实施例提供的多业务应用共享地址，并部署在同一应用平台上的示意图；

图6为本发明实施例提供的S-CSCF业务触发控制流程示意图；

图7为本发明实施例提供的S-CSCF业务触发信令流程示意图；

图8为本发明实施例提供的AS上的业务加载流程示意图；

图9为本发明实施例提供的AS上的业务触发流程示意图；

图10为本发明实施例提供的一种消息处理系统的结构示意图。

具体实施方式

本发明实施例提供了一种消息处理方法及装置，用以在实现同一业务平台同时部署多个业务应用的情况下，避免占用过多的域名(或地址)、端口以及物理设备。

本发明实施例为了满足多业务集约化或特殊行业多业务小型化的应用要求，在同一个业务平台设备上使用同一域名(或地址)及端口资源，同时部署多个业务应用，多个业务可以各自运行，互不干扰，并且提供相应的业务功能。

下面结合附图对本发明实施例提供的技术方案进行说明。

在S-CSCF侧，参见图3，本发明实施例提供的一种消息处理方法包括步骤：

S101、服务呼叫会话控制功能实体S-CSCF，收到来自主叫用户终端的会话发起协议SIP消息后，根据初始过滤规则iFC的配置，将业务应用App标识添加到该SIP消息的路由Route头域中。

S102、S-CSCF将添加有App标识的SIP消息发送给应用服务器AS。

较佳地，S-CSCF将添加有App标识的SIP消息发送给AS之前，该方法还包括：

S-CSCF将会话标识添加到SIP消息的Route头域中。

较佳地，S-CSCF将添加有App标识的SIP消息发送给AS之后，该方法还包括：

S-CSCF接收AS返回的SIP消息，根据该SIP消息的Route头域中的会话标识，确定将该SIP消息发送给被叫用户终端归属网络的查询呼叫会话控制功能实体I-CSCF。

在AS侧，参见图4，本发明实施例提供的一种消息处理方法包括步骤：

S201、应用服务器AS接收服务呼叫会话控制功能实体S-CSCF发送的初始会话请求SIP消息；

S202、AS对该SIP消息进行解析，获取该SIP消息的路由Route头域中的业务应用App标识，并且触发与该App标识相对应的业务处理。

较佳地，步骤S202中，AS对该SIP消息进行解析时，进一步还从S-CSCF发送的SIP消息的Route头域中获取会话标识。

较佳地，步骤S202中，AS触发的与App标识相对应的业务处理完成之后，该方法还包括：

AS向S-CSCF返回SIP消息，其中，在该SIP消息的Route头域中携带有步骤S202中获取的会话标识。

图5为本发明实施例提供的在同一个业务平台设备上使用同一域名(或地址)及端口资源，同时部署多个业务应用的示意图。整个处理过程描述如下：

SIP消息(即图5中所示的SIP请求)到达S-CSCF设备后，S-CSCF根据iFC进行业务的触发，将业务触发到相应的AS业务平台上。触发时，S-CSCF根据iFC中的配置，将该SIP消息中请求处理的每一业务对应的App标识，填写到该SIP消息的Route头域中。

AS业务平台收到SIP消息后，根据SIP消息中的Route头域中的App标识，鉴别出不同的业务应用，从而完成后续业务的逻辑控制处理，将不同的业务应用发往不同的App进行处理。

本发明实施例中，在同一业务平台上同时部署多个业务应用，原理上可同时部署的业务数量是不限的，但是主要考虑集约化的应用场景，所以在进行业务部署时，本发明实施例中部署业务的原则包括：

部署多个业务的业务平台(即AS)对外体现是唯一的，即对于S-CSCF而言，多个业务应用在同一个业务平台设备上使用同一域名(或地址)及端口资源，S-CSCF不会识别每一业务是由具体的哪个App处理；

根据业务平台硬件配置情况，及业务用户数量，决定在AS上部署业务的数量；

业务部署没有先后之分，同一AS上部署的App各自处理所有触发到该App的请求。

参见图6，下面介绍一下本发明实施例中，S-CSCF是如何实现业务触发控制的。

IMS系统中，业务的触发在S-CSCF中完成。当S-CSCF接收到一个SIP消息时，要寻找存储在S-CSCF上的iFC(对于未注册用户终呼的情况，是SIP消息到来后才从HSS下载相关业务属性的)。S-CSCF会分析SIP消息，查找业务触发点(SPTs)，将找到的SPTs和iFC进行匹配，即查找与SPTs相对应的iFC，如果SIP请求与iFC匹配，则S-CSCF将请求转发给相应的AS。接下来S-CSCF还会检查该SIP请求是否与较低优先级的下一个iFC匹配，如果匹配，则在SIP消息从前一个联系的AS处返回时，将SIP消息继续转发给该iFC所对应的AS。

若该SIP请求不能与最高优先级的iFC匹配，则检查它是否与下一个优先级的iFC匹配，直到匹配上一个为止。若不再有(或没有)iFC适用，则S-CSCF基于路由决策对该请求进行转发。

在S-CSCF对起始和终止的iFC的处理上，存在一个明显的区别。在终止的iFC情形下，当S-CSCF发现有一个AS已经更改了请求统一资源标识符(URI，Uniform Resource Identifier)时，则S-CSCF会停止检查，并基于更改过的请求URI值，来对请求进行路由。在初始的iFC情形下，S-CSCF将会继续评估iFC，直至所有iFC均被匹配为止。

如果所联系的AS没有响应，则S-CSCF遵从与iFC相关联的缺省处理过程，即终止会话或继续处理会话。如果AS中没有包括在联系AS失败后S-CSCF应如何操作的指令，则S-CSCF的缺省处理是继续呼叫。

参见图7，下面以初始会话业务的触发流程为例来说明。用户注册后，用户发起呼叫，请求消息到达S-CSCF后，S-CSCF需要进行业务的触发。流程说明如下：

发起呼叫的用户已经注册，当为其服务的S-CSCF收到初始会话请求(INVITE)消息后，对INVITE消息的SIP头进行必要的修改，并且在插入S-CSCF的Route头时，加入一个会话标识(dialog-ID)的参数，用于标识会话；

S-CSCF根据iFC找到匹配的App标识，并将该App标识添加到Route头域；

S-CSCF将此INVITE消息路由到相应的AS；

AS执行相应的业务控制逻辑后，AS(作为B2BUA)依据收到的INVITE请求消息，重新构造一个INVITE消息，发回给S-CSCF。这个重新构造的INVITE消息中的dialog-ID和从S-CSCF收到的INVITE消息中的dialog-ID是相同的；

AS将这个重新构造的INVITE消息发回给S-CSCF。S-CSCF会根据这个重新构造的INVITE消息的顶端Route头中的dialog-ID值，识别这个INVITE消息不是一个新用户的INVITE消息，而是AS执行完业务后返回的一个INVITE消息；

S-CSCF将AS返回的INVITE消息发送给被叫用户归属网络的入口点查询CSCF(I-CSCF，Interrogating CSCF)。

至此，一次业务的触发过程结束。

S-CSCF触发到业务平台AS的INVITE消息举例如下：

INVITE tel：+8613500000000 SIP/2.0

From：<tel：+8613912345678>；tag＝2387838-80110ac-17a2-50029-12d3-57b58f9c-12d3

To：<tel：+8613500000000>

Call-ID：2aaab8492178-60110ac-177a-50029-170bd-440e899f-170bd

CSeq：1INVITE

Record-Route：<sip：172.16.1.6：6010；lr>

Via：SIP/2.0/UDP 172.16.1.6：6010；branch＝z9hG4bK-170bd-5a0629f-292cd22d

Route：<sip：appname172.16.1.30：5060；lr>//其中的appname，即App标识。

Route：<sip：scscf172.16.1.6：6010；lr>；dlg-id＝131206//其中的dlg-id，即会话标识。

Via：SIP/2.0/UDP 172.16.1.5：6090；branch＝z9hG4bK-170c2-5a0784b-77ad4c01

Via：SIP/2.0/UDP 172.16.1.8：6050；branch＝z9hG4bK-12d3-498a95-799aecbe

Via：SIP/2.0/UDP 172.16.1.245：6070；branch＝z9hG4bK-ce9-326e28-3399c1ba

Max-Forwards：67

Supported：sec-agree，replaces

P-Access-Netwotk-Info：3GPP-UTRAN-TDD；utran-cell-id-3gpp＝234151D0FCE11

P-Asserted-Identity：<tel：+8613912345678>

P-Charging-Vector：

icid-value＝172.16.1.6-210；icid-generated-at＝172.16.1.5；orig-ioi＝172.16.1.6

P-Charging-Function-Addresses：ccf＝172.16.0.10；ccf＝0.0.0.0

P-Served-User：<tel：+8613912345678>；sescase＝orig

P-Called-Party-ID：<tel：+8613500000000>

Contact：<tel：+8613912345678>

Session-Expires：9000；refresher＝uac

Min-SE：90

Content-Type：application/sdp

Content-Length：180

v＝0

o＝caller 2890844526 2890844526 IN IP4172.16.1.245

s＝rv_sample_call

c＝IN IP4 172.16.1.245

t＝0 0

m＝audio 15182 RTP/AVP 970

a＝rtpmap：97 AMR-WB/8000

a＝rtpmap：0 PCMU/8000

AS回复给S-CSCF的INVITE消息举例如下：

INVITE tel：+8613500000000SIP/2.0

Content-Type：application/sdp

To：<tel：+8613500000000>

Via：SIP/2.0/UDP

172.16.1.30：5060；wlsscid＝1ae4800a2536c2；branch＝z9hG4bKdb59bfd76dce9d5aecfd85ec0f

df204b

Min-SE：90

P-Served-User：<tel：+8613912345678>；sescase＝orig

P-Called-Party-ID：<tel：+8613500000000>

P-Charging-Function-Addresses：ccf＝172.16.0.10；ccf＝0.0.0.0

Call-ID：wlss-7d07ecab-2aaab8492178-60110ac-177a-50029-170bd-440e899f-170bd

Max-Forwards：66

From：<tel：+8613912345678>；tag＝ac79f556

Contact：

<sip：172.16.1.30：5060；transport＝udp；wlsscid＝1ae4800a2536c2；sipappsessionid＝app-10gv02

26m8wwt>

Session-Expires：9000；refresher＝uac

P-Access-Network-Info：3GPP-UTRAN-TDD；utran-cell-id-3gpp＝234151D0FCE11

P-Charging-Vector：

icid-value＝172.16.1.6-210；icid-generated-at＝172.16.1.5；orig-ioi＝172.16.1.6

CSeq：1 INVITE

Route：<sip：scscf172.16.1.6：6010；lr>；dlg-id＝131206//其中的dlg-id，即会话标识，与S-CSCF发送给AS的INVITE消息中的会话标识相同。

Content-Length：180

Supported：sec-agree，replaces

P-Asserted-Identity：<tel：+8613912345678>

v＝0

o＝caller 2890844526 2890844526IN IP4 172.16.1.245

s＝rv_sample_call

c＝IN IP4 172.16.1.245

t＝0 0

m＝audio 15182 RTP/AVP 970

a＝rtpmap：97AMR-WB/8000

a＝rtpmap：0 PCMU/8000

本发明实施例中以在S-CSCF和AS间业务触发的处理流程为例进行的说明，其它过程例如：注册过程触发、非注册过程触发、终呼过程触发等流程和此流程的处理相类似。

下面具体介绍一下本发明实施例中AS是如何实现业务区别控制的。

AS上业务触发的区别控制主要分为两个过程：业务加载过程和业务触发处理过程，下面分别进行描述。

业务加载过程如图8所示，业务加载流程描述如下：

业务平台运行起来后，即可加载业务应用；

用户选择要加载的业务应用包，即应用软件包App；

用户指定该App业务应用的名称，一般和应用软件包名称保持一致，即App标识(Appname)；该名称同时也是在HSS设备中的该用户的iFC中配置的AS标识中的username部分；是S-CSCF业务触发的重要参数的组成部分；

用户配置业务应用模式等参数；

业务加载完成，如果加载成功，AS就会将该业务应用的名称记录下来，并标明相关状态，为后续业务触发请求的处理做好准备；如果加载失败，则会产生错误原因提示信息，用户修正错误后可选择再次加载。

业务触发处理过程如图9所示，业务触发处理流程描述如下：

步骤一、业务平台AS收到SIP请求；

步骤二、业务平台从该SIP请求中获取Route头域及参数；如果有Route头域，则进行步骤三，否则，当有默认应用包时，就将此请求交由默认应用包处理；没有默认应用包时，也没有加载任何应用，则业务平台输出错误提示信息；

步骤三、业务平台从Route头域中提取出App标识，并根据App标识查找业务应用的名称对应的业务是否已加载，如果是，则将此SIP请求交由该App标识对应的业务包App进行后续处理；否则，业务平台输出错误提示信息；

步骤四、当SIP请求进入某一具体的业务应用处理过程后，再根据具体的业务请求方法，比如：请求(Request)URI或SIP方法(METHOD)分别进行业务的处理过程。

综上，本发明实施例通过对SIP头域Route的扩展来进行业务触发，选取AS处理，通过App标识来区别不同的业务请求消息的处理。从而节约了域名地址资源，特别适用于多业务集约化或行业多业务应用场景，业务部署方便，增加业务部署无需调整系统结构。

参见图10，本发明实施例提供的一种消息处理系统包括服务呼叫会话控制功能实体S-CSCF 101，和应用服务器AS 102。

较佳地，S-CSCF 101包括：

第一消息接收单元201，用于接收来自主叫用户终端的会话发起协议SIP消息。

App标识添加单元202，用于根据初始过滤规则iFC的配置，将业务应用App标识添加到该SIP消息的路由Route头域中。

会话标识添加单元203，用于将会话标识添加到SIP消息的Route头域中。

第一消息发送单元204，用于将添加有App标识和会话标识的SIP消息发送给应用服务器AS 102。

较佳地，S-CSCF 101还包括：

第二消息接收单元205，用于接收AS 102返回的SIP消息。

第二消息发送单元206，用于根据AS 102返回的SIP消息的Route头域中的会话标识，确定将该SIP消息发送给被叫用户终端归属网络的查询呼叫会话控制功能实体I-CSCF。

较佳地，AS 102包括：

消息接收单元207，用于接收服务呼叫会话控制功能实体S-CSCF 101发送的初始会话请求SIP消息。

消息解析处理单元208，用于对该SIP消息进行解析，获取该SIP消息的路由Route头域中的业务应用App标识，并且触发与该App标识相对应的业务处理。

较佳地，所述消息解析处理单元208，还用于从所述SIP消息的Route头域中获取会话标识。

较佳地，AS 102还包括：

消息发送单元209，用于在所述消息解析处理单元208触发的与所述App标识相对应的业务处理完成之后，向所述S-CSCF 101返回SIP消息，其中，在该SIP消息的Route头域中携带有所述会话标识。

综上，本发明实施例在IMS的体系架构下，CSCF可根据iFC进行业务的触发，在AS中增加对消息的预处理，即根据App标识来区分不同的业务应用，达到在同一个业务平台设备上使用同一域名(或地址)及端口资源，同时部署多个业务应用的目的，既合乎标准又扩展了标准应用，既能节省域名(或地址)以及端口的占用，又无需占用过多的物理设备。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

Claims (12)

1.一种消息处理方法，其特征在于，该方法包括：

服务呼叫会话控制功能实体S-CSCF，收到来自主叫用户终端的会话发起协议SIP消息后，根据初始过滤规则iFC的配置，将所述SIP消息中请求处理的每一业务对应的业务应用App标识添加到该SIP消息的路由Route头域中；

S-CSCF将添加有App标识的SIP消息发送给应用服务器AS。

2.根据权利要求1所述的方法，其特征在于，S-CSCF将添加有App标识的SIP消息发送给AS之前，该方法还包括：

S-CSCF将会话标识添加到SIP消息的Route头域中。

3.根据权利要求2所述的方法，其特征在于，S-CSCF将添加有App标识的SIP消息发送给AS之后，该方法还包括：

S-CSCF接收AS返回的SIP消息，根据SIP消息的Route头域中的会话标识，确定将该SIP消息发送给被叫用户终端归属网络的查询呼叫会话控制功能实体I-CSCF。

4.一种消息处理方法，其特征在于，该方法包括：

应用服务器AS接收服务呼叫会话控制功能实体S-CSCF发送的初始会话请求SIP消息；

AS对该SIP消息进行解析，获取该SIP消息的路由Route头域中的业务应用App标识，并且根据所述App标识，触发与该App标识相对应的业务处理。

5.根据权利要求4所述的方法，其特征在于，所述SIP消息的Route头域中还包括：会话标识。

6.根据权利要求5所述的方法，其特征在于，AS触发的与所述App标识相对应的业务处理完成之后，该方法还包括：

AS向所述S-CSCF返回SIP消息，其中，在该SIP消息的Route头域中携带有所述会话标识。

7.一种消息处理装置，其特征在于，该装置包括：

第一消息接收单元，用于接收来自主叫用户终端的会话发起协议SIP消息；

App标识添加单元，用于根据初始过滤规则iFC的配置，将所述SIP消息中请求处理的每一业务对应的业务应用App标识添加到该SIP消息的路由Route头域中；

第一消息发送单元，用于将添加有App标识的SIP消息发送给应用服务器AS。

8.根据权利要求7所述的装置，其特征在于，该装置还包括：

会话标识添加单元，用于在所述第一消息发送单元将添加有App标识的SIP消息发送给AS之前，将会话标识添加到SIP消息的Route头域中。

9.根据权利要求8所述的装置，其特征在于，该装置还包括：

第二消息接收单元，用于接收AS返回的SIP消息；

第二消息发送单元，用于根据AS返回的SIP消息的Route头域中的会话标识，确定将该SIP消息发送给被叫用户终端归属网络的查询呼叫会话控制功能实体I-CSCF。

10.一种消息处理装置，其特征在于，该装置包括：

消息接收单元，用于接收服务呼叫会话控制功能实体S-CSCF发送的初始会话请求SIP消息；

消息解析处理单元，用于对该SIP消息进行解析，获取该SIP消息的路由Route头域中的业务应用App标识，并且根据所述App标识，触发与该App标识相对应的业务处理。

11.根据权利要求10所述的装置，其特征在于，所述消息解析处理单元，还用于从所述SIP消息的Route头域中获取会话标识。

12.根据权利要求11所述的装置，其特征在于，该装置还包括：

消息发送单元，用于在所述消息解析处理单元触发的与所述App标识相对应的业务处理完成之后，向所述S-CSCF返回SIP消息，其中，在该SIP消息的Route头域中携带有所述会话标识。