一种IMS会话处理方法及系统转让专利
申请号 : CN200710120673.0
文献号 : CN100589603C
文献日 : 2010-02-10
发明人 : 张智江 , 王明会 , 杨征 , 马红兵 , 陈国利 , 刘宝庆 , 陈勋 , 杨艳松 , 蔡子龙 , 朱斌 , 张惠谦 , 尼松涛
申请人 : 中国联合网络通信集团有限公司
摘要 :
本发明涉及一种IMS会话处理方法，包括：步骤11，主叫侧S-CSCF判断是否有被叫用户的注册信息，如果是，执行步骤12，否则，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP标准会话流程处理；步骤12，S-CSCF检查被叫PUI状态及签约信息，并进行处理。本发明在3GPP IMS会话流程的基础上，对S-CSCF功能进行一定的扩展，进而对IMS会话处理流程进行优化，可以减少IMS局内会话时不必要的信令交互，有效降低信令流量及设备处理负荷，提升业务质量。
权利要求 :
1、一种IMS会话处理方法，其特征在于，包括： 步骤11，主叫侧S-CSCF判断是否有被叫用户的注册信息，如果是，执行步骤12，否则，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP标准会话流程处理； 步骤12，S-CSCF检查被叫PUI状态及业务信息，并进行处理； 步骤12包括： 步骤121，如果被叫PUI是注册状态，或者是未注册状态但有未注册状态的业务，则执行步骤122；如果被叫PUI是未注册状态，并且没有未注册状态的业务，则执行步骤123； 步骤122，S-CSCF调用被叫用户签约的业务逻辑来建立会话； 步骤123，S-CSCF向P-CSCF返回失败消息。
2、 如权利要求1所述的IMS会话处理方法，其特征在于，步骤11之前 还包括步骤10，主叫侧S-CSCF判断被叫PUI目的地址是否在该S-CSCF允许 注册的域内，如果是，执行步骤ll，否则，S-CSCF根据被叫PUI进行目的地 址分析，将Invite请求转发给相应的I-CSCF， I-CSCF按照3GPP标准会话流 程处理。
3、 如权利要求1所述的IMS会话处理方法，其特征在于，步骤122，S-CSCF 调用被叫用户签约的业务逻辑来建立会话时，在Invite消息中Via头域和 Record-Route头域分别添加两条S-CSCF地址；当S-CSCF收到响应消息后， 根据响应消息中Via头域中两条S-CSCF地址得知这是局内会话的情况，分别 进行被叫侧和主叫侧会话处理。
4、 如权利要求1所述的IMS会话处理方法，其特征在于，步骤11之前 还包括：步骤501，主叫侧S-CSCF收到初始请求消息； 步骤502，调用主叫用户签约的业务逻辑来建立会话； 步骤503，判断被叫PUI是否是SIPURI，如果是，执行步骤ll，否则执 行步骤504;步骤504，向Enum服务器进行号码解析，判断是否有对应的SIP URI，如果是，执行步骤505，否则将Invite请求转交给BGCF进行后续处理；步骤505，将TelURI替换为对应的SIPURI，执行步骤ll。
5、 如权利要求1所述的IMS会话处理方法，其特征在于，所述失败消息是404消息。
6、 一种IMS会话处理系统，该系统包括S-CSCF、 I-CSCF，其特征在于，S-CSCF还用于：判断是否有被叫用户的注册信息；如果有被叫用户的注册信息，S-CSCF检查被叫PUI状态及业务信息，并进行处理；如果没有被叫用户的注册信息，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-(〕SCF按照3GPP标准会话流程处理；S-CSCF检査被叫PUI状态及业务信息后，所进行的处理包括：如果被叫PUI是注册状态，或者是未注册状态但有未注册状态的业务，则S-CSCF调用被叫用户签约的业务逻辑来建立会话；如果被叫PUI是未注册状态，并且没有未注册状态的业务，则S-CSCF向P-CSCF返回失败消息。
7、 如权利要求6所述的IMS会话处理系统，其特征在于，S-CSCF还用于判断被叫PUI目的地址是否在该S-CSCF允许注册的域内。
8、 如权利要求6所述的IMS会话处理系统，其特征在于，S-CSCF调用被叫用户签约的业务逻辑来建立会话时，在Invite消息中Via头域和Record-Route头域分别添加两条S-CSCF地址；当S-CSCF收到响应消息后，根据响应消息中Via头域中两条S-CSCF地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会话处理。
说明书 :
一种IMS会话处理方法及系统
技术领域
本发明涉及IMS领域，尤其涉及一种IMS会话处理方法及系统。背景技术
IMS (IP Multimedia Subsystem, IP多媒体子系统）由3GPP (3rd GenerationPartnership Project,第三代合作伙伴计划）在其标准系列R5中提出，是一个基于PS (Packet Switching,分组交换）域提供IP多媒体业务的子系统。IMS系统结构如图1所示，分为业务层，核心层及接入层。业务层由各种应用服务器组成；核心层由代理会话控制功能（P-CSCF )、服务会话控制功能（S-CSCF )、査询会话控制功能（I-CSCF)、归属用户服务器（HSS)、签约定位功能（SLF)、出口网关控制功能（BGCF)、媒体网关控制功能（MGCF) 、 IMS媒体网关(IMS-MGW)、多媒体资源功能控制器（MRFC)、多媒体资源功能处理器(MRFP)等网元组成，接入层由策略决策功能（PDF)、网关GPRS支持节点（GGSN)、服务GPRS支持节点（SGSN)等组成。IMS系统中有三种用户状态：
注册状态（registeredstate):用户成功注册，并且网络给用户分配了一个S-CSCF 。
注销状态（not registered state):用户没有进行注册，网络没有给用户分配S-CSCF 。
未注册状态（unregistered state):在两种情况下，用户处于未注册状态。1)用户签约了未注册状态业务，当用户为注销状态时作为一个终止呼叫而进行的注册，此时HSS中会将用户从注销状态改变为未注册状态，同时为用户指配一个S-CSCF，该S-CSCF会从HSS下载用户相关信息；2)用户发起注销时，HSS保留用户注册的S-CSCF名，同时S-CSCF上不清除相关用户信息，HSS和S-CSCF只是将用户状态从注册状态改变为未注册状态。
另外，在IMS系统中，未注册状态业务指与用户注销状态或者未注册状态有关的业务，如呼叫转移类业务等。
如图2-图4所示，3GPP TS24.228" Signalling flows for the IP multimedia callcontrol based on SIP and SDP;Stage 3"定义了呼叫不同用户的会话流程。这里按照不进行拓扑隐藏的场景进行说明，本方案和是否需要进行拓扑隐藏无关。
图2是呼叫注册用户的会话流程（S-CSCF到S-CSCF部分），包括：
步骤21,主叫侧S-CSCF#1收到初始Invite请求；
步骤22， S-CSCF#1返回100 trying (尝试中）消息，表示由S-CSCF#1负责Invite消息的重传；
步骤23， S-CSCF#1调用主叫用户签约的业务逻辑来建立会话，如触发到相应的AS等（Service Control);
步骤24， S-CSCF#1向被叫用户归属网络中的I-CSCF弁2发送Invite消息；
步骤25， I-CSCF#2向S-CSCF#1返回100trying消息，表示由I-CSCF#2负责Invite消息的重传；
步骤26， I-CSCF#2向HSS发送位置査询请求消息（LIR);
步骤27， HSS向I-CSCF#2发送位置査询响应消息（LIA);
步骤28， I-CSCF#2向被叫侧S-CSCF#2发送Invite消息；
步骤29， S-CSCF#2向I-CSCF#2返回100trying消息；
步骤210， S-CSCF弁2调用被叫用户签约的业务逻辑来建立会话，如触发到相应的AS等进行业务控制；
步骤211， S-CSCF#2向被叫侧发送Invite消息；
步骤212， S-CSCF存2收到100trying消息，表示由下一个节点负责Invite消息的重传；
步骤213-步骤228,主被叫用户完成媒体协商，同时网络侧完成资源预留；
步骤229-步骤238，被叫用户振铃；
步骤239-步骤245，被叫用户摘机，双方建立通话。
图3是呼叫一个注销状态或者未注册状态，同时签约了未注册状态业务的用户的会话流程图，包括：
步骤31 ，主叫侧S-CSCF#1收到初始Invite请求；
步骤32， S-CSCF#1返回100 trying消息，表示由S-CSCF#1负责Invite消息的重传；步骤33， S-CSCF#1调用主叫用户签约的业务逻辑来建立会话，如触发到相应的AS等（Service Control);
歩骤34， S-CSCF#1向被叫用户归属网络中的I-CSCF弁2发送Invite消息;
步骤35， I-CSCF#2向S-CSCF#1返回100trying消息，表示由I-CSCF#2负责Invite消息的重传；
步骤36， I-CSCF#2向HSS发送位置査询请求消息（LIR);
步骤37, HSS向I-CSCF#2发送位置査询响应消息（LIA);
步骤38， I-CSCF#2选择被叫侧S-CSCF#2;
步骤39， I-CSCF#2向被叫侧S-CSCF#2发送Invite消息；
步骤310， S-CSCF#2向I-CSCF#2返回100trying消息；
步骤311，被叫侧S-CSCF#2向HSS发送服务器分配请求消息（SAR);
步骤312， HSS向被叫侧S-CSCF#2发送服务器分配应答消息（SAA);
步骤313，被叫侧S-CSCF#2进行业务控制Service Control;
步骤314,被叫侧S-CSCF#2执行后续流程。
注：如果S-CSCF弁2上己经保存了用户相关信息（即用户处于未注册状态时），可以省略步骤311、 312。
图4是呼叫一个注销状态或者未注册状态并且没有签约未注册状态业务的用户的流程，包括：
步骤41,主叫侧S-CSCF#1收到初始Invite请求；
步骤42， S-CSCF#1返回100 trying消息，表示由S-CSCF#1负责Invite
消息的重传；
步骤43， S-CSCF#1调用主叫用户签约的业务逻辑来建立会话，如触发到相应的AS等（Service Control);
步骤44， S-CSCF#1向被叫用户归属网络中的I-CSCF存2发送Invite消息；
步骤45， I-CSCF弁2向S-CSCF弁l返回100trying消息，表示由I-CSCF#2负责Invite消息的重传；
步骤46， I-CSCF#2向HSS发送位置查询请求消息（LIR);
步骤47， HSS向I-CSCF存2发送位置査询响应消息（LIA);
步骤48， I-CSCF#2向主叫侧S-CSCF#1返回失败消息，如404消息；
步骤49， S-CSCF#1向I-CSCF发送ACK确认消息；步骤410， S-CSCF#1向主叫侧P-CSCF转发404消息；步骤411 ， S-CSCF弁1收到ACK确认消息。
图2-图4中3GPP IMS呼叫不同用户的会话流程可以用图5进行总结描述:步骤501 ，主叫S-CSCF收到初始Invite请求；
步骤502, S-CSCF调用主叫用户签约的业务逻辑来建立会话（如，是否需要触发到相应的AS);
步骤503， S-CSCF判断被叫PUI (公共用户标识）是否是SIPURI (SIP统一资源标识符），如果是，执行步骤504，如果否，执行步骤505;
步骤504， S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，执行步骤507;
步骤505，向Erium (电话号码映射）服务器进行号码解析，是否有对应的SIPURI,如果是，执行步骤506，如果否，执行步骤523;
步骤506，将TelURI (电话统一资源定位符）替换为对应的SIP URI，执行步骤504;
步骤507， I-CSCF向HSS发起用户位置查询请求（LIR);
步骤508， HSS检査PU1状态及相关业务信息，依据PUI状态及相关业务信息，相应执行步骤509、 510、 511;
步骤509，如果PUI是注册状态，或者是未注册状态但有未注册状态的业务，执行步骤5i2;
步骤510，如果PUI是注销状态，但有未注册状态的业务，执行步骤515;
歩骤511，如果PUI是注销或者是未注册状态，并且没有未注册状态的业务，执行步骤520;
歩骤512， HSS在位置查询响应消息中返回所保存的S-CSCF名称；
步骤513， I-CSCF选择S-CSCF，并将请求转发给S-CSCF;
步骤514，被叫侧S-CSCF调用被叫用户签约的业务逻辑来建立会话； 步骤515， HSS要检查该IMS签约是否至少有一个PUI分配了 S-CSCF名称，如果是，执行步骤516，否则执行步骤517;
歩骤516， HSS在位置查询响应消息中返回S-CSCF名称，执行步骤518;
步骤517， HSS在位置查询响应消息中返回S-CSCF能力信息或由I-CSCF任意选择一个S-CSCF ，执行步骤518;步骤518， I-CSCF选择S-CSCF，并将请求转发给S-CSCF;
步骤519，被叫侧S-CSCF向HSS发送服务器分配请求（SAR)，获取用 户签约信息，执行步骤514;
步骤520， HSS在LIA响应中将Experimental-Result-Code设置为 DIAMETER—ERROR—IDENTITY—NOT—REGISTERED;
步骤521， I-CSCF向主叫侧S-CSCF返回失败消息，如404消息；
步骤522，主叫侧S-CSCF向P-CSCF转发失败消息，如404消息；
步骤523，将Invite请求转交给BGCF进行后续处理。
在上述3GPP定义的IMS会话流程中，对于IMS局内会话的情况，即主 叫侧S-CSCF同时保存了被叫用户信息的情况下，存在着不必要的信令交互。 如，呼叫一个注册用户时，主叫侧S-CSCF根据主叫用户签约信息进行相应的 业务处理之后，将Invite请求转发给I-CSCF，之后I-CSCF查询HSS后得知 被叫用户同时注册在主叫侧S-CSCF， I-CSCF将Invite请求又返回给主叫侧 S-CSCF,这样便造成了不必要的信令处理。其他一些呼叫场景也存在着这样 的问题。
IMS (IP Multimedia Subsystem, IP多媒体子系统）由3GPP (3rd GenerationPartnership Project,第三代合作伙伴计划）在其标准系列R5中提出，是一个基于PS (Packet Switching,分组交换）域提供IP多媒体业务的子系统。IMS系统结构如图1所示，分为业务层，核心层及接入层。业务层由各种应用服务器组成；核心层由代理会话控制功能（P-CSCF )、服务会话控制功能（S-CSCF )、査询会话控制功能（I-CSCF)、归属用户服务器（HSS)、签约定位功能（SLF)、出口网关控制功能（BGCF)、媒体网关控制功能（MGCF) 、 IMS媒体网关(IMS-MGW)、多媒体资源功能控制器（MRFC)、多媒体资源功能处理器(MRFP)等网元组成，接入层由策略决策功能（PDF)、网关GPRS支持节点（GGSN)、服务GPRS支持节点（SGSN)等组成。IMS系统中有三种用户状态：
注册状态（registeredstate):用户成功注册，并且网络给用户分配了一个S-CSCF 。
注销状态（not registered state):用户没有进行注册，网络没有给用户分配S-CSCF 。
未注册状态（unregistered state):在两种情况下，用户处于未注册状态。1)用户签约了未注册状态业务，当用户为注销状态时作为一个终止呼叫而进行的注册，此时HSS中会将用户从注销状态改变为未注册状态，同时为用户指配一个S-CSCF，该S-CSCF会从HSS下载用户相关信息；2)用户发起注销时，HSS保留用户注册的S-CSCF名，同时S-CSCF上不清除相关用户信息，HSS和S-CSCF只是将用户状态从注册状态改变为未注册状态。
另外，在IMS系统中，未注册状态业务指与用户注销状态或者未注册状态有关的业务，如呼叫转移类业务等。
如图2-图4所示，3GPP TS24.228" Signalling flows for the IP multimedia callcontrol based on SIP and SDP;Stage 3"定义了呼叫不同用户的会话流程。这里按照不进行拓扑隐藏的场景进行说明，本方案和是否需要进行拓扑隐藏无关。
图2是呼叫注册用户的会话流程（S-CSCF到S-CSCF部分），包括：
步骤21,主叫侧S-CSCF#1收到初始Invite请求；
步骤22， S-CSCF#1返回100 trying (尝试中）消息，表示由S-CSCF#1负责Invite消息的重传；
步骤23， S-CSCF#1调用主叫用户签约的业务逻辑来建立会话，如触发到相应的AS等（Service Control);
步骤24， S-CSCF#1向被叫用户归属网络中的I-CSCF弁2发送Invite消息；
步骤25， I-CSCF#2向S-CSCF#1返回100trying消息，表示由I-CSCF#2负责Invite消息的重传；
步骤26， I-CSCF#2向HSS发送位置査询请求消息（LIR);
步骤27， HSS向I-CSCF#2发送位置査询响应消息（LIA);
步骤28， I-CSCF#2向被叫侧S-CSCF#2发送Invite消息；
步骤29， S-CSCF#2向I-CSCF#2返回100trying消息；
步骤210， S-CSCF弁2调用被叫用户签约的业务逻辑来建立会话，如触发到相应的AS等进行业务控制；
步骤211， S-CSCF#2向被叫侧发送Invite消息；
步骤212， S-CSCF存2收到100trying消息，表示由下一个节点负责Invite消息的重传；
步骤213-步骤228,主被叫用户完成媒体协商，同时网络侧完成资源预留；
步骤229-步骤238，被叫用户振铃；
步骤239-步骤245，被叫用户摘机，双方建立通话。
图3是呼叫一个注销状态或者未注册状态，同时签约了未注册状态业务的用户的会话流程图，包括：
步骤31 ，主叫侧S-CSCF#1收到初始Invite请求；
步骤32， S-CSCF#1返回100 trying消息，表示由S-CSCF#1负责Invite消息的重传；步骤33， S-CSCF#1调用主叫用户签约的业务逻辑来建立会话，如触发到相应的AS等（Service Control);
歩骤34， S-CSCF#1向被叫用户归属网络中的I-CSCF弁2发送Invite消息;
步骤35， I-CSCF#2向S-CSCF#1返回100trying消息，表示由I-CSCF#2负责Invite消息的重传；
步骤36， I-CSCF#2向HSS发送位置査询请求消息（LIR);
步骤37, HSS向I-CSCF#2发送位置査询响应消息（LIA);
步骤38， I-CSCF#2选择被叫侧S-CSCF#2;
步骤39， I-CSCF#2向被叫侧S-CSCF#2发送Invite消息；
步骤310， S-CSCF#2向I-CSCF#2返回100trying消息；
步骤311，被叫侧S-CSCF#2向HSS发送服务器分配请求消息（SAR);
步骤312， HSS向被叫侧S-CSCF#2发送服务器分配应答消息（SAA);
步骤313，被叫侧S-CSCF#2进行业务控制Service Control;
步骤314,被叫侧S-CSCF#2执行后续流程。
注：如果S-CSCF弁2上己经保存了用户相关信息（即用户处于未注册状态时），可以省略步骤311、 312。
图4是呼叫一个注销状态或者未注册状态并且没有签约未注册状态业务的用户的流程，包括：
步骤41,主叫侧S-CSCF#1收到初始Invite请求；
步骤42， S-CSCF#1返回100 trying消息，表示由S-CSCF#1负责Invite
消息的重传；
步骤43， S-CSCF#1调用主叫用户签约的业务逻辑来建立会话，如触发到相应的AS等（Service Control);
步骤44， S-CSCF#1向被叫用户归属网络中的I-CSCF存2发送Invite消息；
步骤45， I-CSCF弁2向S-CSCF弁l返回100trying消息，表示由I-CSCF#2负责Invite消息的重传；
步骤46， I-CSCF#2向HSS发送位置查询请求消息（LIR);
步骤47， HSS向I-CSCF存2发送位置査询响应消息（LIA);
步骤48， I-CSCF#2向主叫侧S-CSCF#1返回失败消息，如404消息；
步骤49， S-CSCF#1向I-CSCF发送ACK确认消息；步骤410， S-CSCF#1向主叫侧P-CSCF转发404消息；步骤411 ， S-CSCF弁1收到ACK确认消息。
图2-图4中3GPP IMS呼叫不同用户的会话流程可以用图5进行总结描述:步骤501 ，主叫S-CSCF收到初始Invite请求；
步骤502, S-CSCF调用主叫用户签约的业务逻辑来建立会话（如，是否需要触发到相应的AS);
步骤503， S-CSCF判断被叫PUI (公共用户标识）是否是SIPURI (SIP统一资源标识符），如果是，执行步骤504，如果否，执行步骤505;
步骤504， S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，执行步骤507;
步骤505，向Erium (电话号码映射）服务器进行号码解析，是否有对应的SIPURI,如果是，执行步骤506，如果否，执行步骤523;
步骤506，将TelURI (电话统一资源定位符）替换为对应的SIP URI，执行步骤504;
步骤507， I-CSCF向HSS发起用户位置查询请求（LIR);
步骤508， HSS检査PU1状态及相关业务信息，依据PUI状态及相关业务信息，相应执行步骤509、 510、 511;
步骤509，如果PUI是注册状态，或者是未注册状态但有未注册状态的业务，执行步骤5i2;
步骤510，如果PUI是注销状态，但有未注册状态的业务，执行步骤515;
歩骤511，如果PUI是注销或者是未注册状态，并且没有未注册状态的业务，执行步骤520;
歩骤512， HSS在位置查询响应消息中返回所保存的S-CSCF名称；
步骤513， I-CSCF选择S-CSCF，并将请求转发给S-CSCF;
步骤514，被叫侧S-CSCF调用被叫用户签约的业务逻辑来建立会话； 步骤515， HSS要检查该IMS签约是否至少有一个PUI分配了 S-CSCF名称，如果是，执行步骤516，否则执行步骤517;
歩骤516， HSS在位置查询响应消息中返回S-CSCF名称，执行步骤518;
步骤517， HSS在位置查询响应消息中返回S-CSCF能力信息或由I-CSCF任意选择一个S-CSCF ，执行步骤518;步骤518， I-CSCF选择S-CSCF，并将请求转发给S-CSCF;
步骤519，被叫侧S-CSCF向HSS发送服务器分配请求（SAR)，获取用 户签约信息，执行步骤514;
步骤520， HSS在LIA响应中将Experimental-Result-Code设置为 DIAMETER—ERROR—IDENTITY—NOT—REGISTERED;
步骤521， I-CSCF向主叫侧S-CSCF返回失败消息，如404消息；
步骤522，主叫侧S-CSCF向P-CSCF转发失败消息，如404消息；
步骤523，将Invite请求转交给BGCF进行后续处理。
在上述3GPP定义的IMS会话流程中，对于IMS局内会话的情况，即主 叫侧S-CSCF同时保存了被叫用户信息的情况下，存在着不必要的信令交互。 如，呼叫一个注册用户时，主叫侧S-CSCF根据主叫用户签约信息进行相应的 业务处理之后，将Invite请求转发给I-CSCF，之后I-CSCF查询HSS后得知 被叫用户同时注册在主叫侧S-CSCF， I-CSCF将Invite请求又返回给主叫侧 S-CSCF,这样便造成了不必要的信令处理。其他一些呼叫场景也存在着这样 的问题。
发明内容
为了解决上述的技术问题，本发明提供了一种IMS会话处理方法及系统， 其目的在于，减少不必要的消息交互，降低设备处理负荷，节约带宽，并且降 低会话处理时延，提升业务质量。
本发明提供了一种IMS会话处理方法，包括：
步骤ll，主叫侧S-CSCF判断是否有被叫用户的注册信息，如果是，执行 步骤12，否则，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发 给相应的I-CSCF， I-CSCF按照3GPP标准会话流程处理；
步骤12， S-CSCF检查被叫PUI状态及业务信息，并进行处理。
步骤11之前还包括步骤10，主叫侧S-CSCF判断被叫PUI目的地址是否 在该S-CSCF允许注册的域内，如果是执行步骤ll,否则，S-CSCF根据被叫 PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP 标准会话流程处理。
步骤12包括：步骤121，如果被叫PUI是注册状态，或者是未注册状态但有未注册状态 的业务，则执行步骤122;如果被叫PUI是未注册状态，并且没有未注册状态 的业务，则执行步骤123;
步骤122， S-CSCF调用被叫用户签约的业务逻辑来建立会话；
步骤123， S-CSCF向P-CSCF返回失败消息。
步骤122， S-CSCF调用被叫用户签约的业务逻辑来建立会话时，在Invite 消息中Via头域和Record-Route头域分别添加两条S-CSCF地址；当S-CSCF 收到响应消息后，根据响应消息中Via头域中两条S-CSCF地址得知这是局内 会话的情况，分别进行被叫侧和主叫侧会话处理。
步骤ll之前还包括：
步骤501 ，主叫侧S-CSCF收到初始请求消息； 步骤502，调用主叫用户签约的业务逻辑来建立会话； 步骤503，判断被叫PUI是否是SIPURI，如果是，执行步骤ll，否则执 行步骤504;
步骤504，向Enum服务器进行号码解析，判断是否有对应的SIP URI， 如果是，执行步骤505，否则将Invite请求转交给BGCF进行后续处理； 步骤505，将Td URI替换为对应的SIP URI,执行步骤ll。 所述失败消息是404消息。
本发明提供了一种IMS会话处理系统，该系统包括S-CSCF、 I-CSCF， S-CSCF还用于：
判断是否有被叫用户的注册信息；如果有被叫用户的注册信息，S-CSCF 检査被叫PUI状态及业务信息，并进行处理；如果没有被叫用户的注册信息， S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF， I-CSCF按照3GPP标准会话流程处理。
S-CSCF还用于判断被叫PUT目的地址是否在该S-CSCF允许注册的域内。 S-CSCF检查被叫PUI状态及业务信息后，所进行的处理包括： 如果被叫PUI是注册状态，或者是未注册状态但有未注册状态的业务，则 S-CSCF调用被叫用户签约的业务逻辑来建立会话；
如果被叫PUI是未注册状态，并且没有未注册状态的业务，则S-CSCF向 P-CSCF返回失败消息。S-CSCF调用被叫用户签约的业务逻辑来建立会话时，在Invite消息中Via 头域和Record-Route头域分别添加两条S-CSCF地址；当S-CSCF收到响应消 息后，根据响应消息中Via头域中两条S-CSCF地址得知这是局内会话的情况， 分别进行被叫侧和主叫侧会话处理。
本发明在3GPP IMS会话流程的基础上，对S-CSCF功能进行一定的扩展， 进而对IMS会话处理流程进行优化。本发明能够在局内会话的场景下，有效 减少不必要的信令流量及设备处理负荷，节省带宽等网络资源，并且降低会话 处理时延，提升业务质量。
本发明提供了一种IMS会话处理方法，包括：
步骤ll，主叫侧S-CSCF判断是否有被叫用户的注册信息，如果是，执行 步骤12，否则，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发 给相应的I-CSCF， I-CSCF按照3GPP标准会话流程处理；
步骤12， S-CSCF检查被叫PUI状态及业务信息，并进行处理。
步骤11之前还包括步骤10，主叫侧S-CSCF判断被叫PUI目的地址是否 在该S-CSCF允许注册的域内，如果是执行步骤ll,否则，S-CSCF根据被叫 PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP 标准会话流程处理。
步骤12包括：步骤121，如果被叫PUI是注册状态，或者是未注册状态但有未注册状态 的业务，则执行步骤122;如果被叫PUI是未注册状态，并且没有未注册状态 的业务，则执行步骤123;
步骤122， S-CSCF调用被叫用户签约的业务逻辑来建立会话；
步骤123， S-CSCF向P-CSCF返回失败消息。
步骤122， S-CSCF调用被叫用户签约的业务逻辑来建立会话时，在Invite 消息中Via头域和Record-Route头域分别添加两条S-CSCF地址；当S-CSCF 收到响应消息后，根据响应消息中Via头域中两条S-CSCF地址得知这是局内 会话的情况，分别进行被叫侧和主叫侧会话处理。
步骤ll之前还包括：
步骤501 ，主叫侧S-CSCF收到初始请求消息； 步骤502，调用主叫用户签约的业务逻辑来建立会话； 步骤503，判断被叫PUI是否是SIPURI，如果是，执行步骤ll，否则执 行步骤504;
步骤504，向Enum服务器进行号码解析，判断是否有对应的SIP URI， 如果是，执行步骤505，否则将Invite请求转交给BGCF进行后续处理； 步骤505，将Td URI替换为对应的SIP URI,执行步骤ll。 所述失败消息是404消息。
本发明提供了一种IMS会话处理系统，该系统包括S-CSCF、 I-CSCF， S-CSCF还用于：
判断是否有被叫用户的注册信息；如果有被叫用户的注册信息，S-CSCF 检査被叫PUI状态及业务信息，并进行处理；如果没有被叫用户的注册信息， S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF， I-CSCF按照3GPP标准会话流程处理。
S-CSCF还用于判断被叫PUT目的地址是否在该S-CSCF允许注册的域内。 S-CSCF检查被叫PUI状态及业务信息后，所进行的处理包括： 如果被叫PUI是注册状态，或者是未注册状态但有未注册状态的业务，则 S-CSCF调用被叫用户签约的业务逻辑来建立会话；
如果被叫PUI是未注册状态，并且没有未注册状态的业务，则S-CSCF向 P-CSCF返回失败消息。S-CSCF调用被叫用户签约的业务逻辑来建立会话时，在Invite消息中Via 头域和Record-Route头域分别添加两条S-CSCF地址；当S-CSCF收到响应消 息后，根据响应消息中Via头域中两条S-CSCF地址得知这是局内会话的情况， 分别进行被叫侧和主叫侧会话处理。
本发明在3GPP IMS会话流程的基础上，对S-CSCF功能进行一定的扩展， 进而对IMS会话处理流程进行优化。本发明能够在局内会话的场景下，有效 减少不必要的信令流量及设备处理负荷，节省带宽等网络资源，并且降低会话 处理时延，提升业务质量。
附图说明
图1为3GPP IMS系统结构图；
图2为现有技术中呼叫注册用户的会话流程（S-CSCF到S-CSCF部分）；
图3为现有技术中呼叫一个注销状态或者未注册状态但签约了未注册状 态业务的用户的会话流程图；
图4为现有技术中呼叫一个注销状态或者未注册状态并且没有签约未注 册状态业务的用户的流程；
图5为现有技术中S-CSCF收到初始Invite请求后的处理流程；
图6为本发明提供的会话处理流程。
图2为现有技术中呼叫注册用户的会话流程（S-CSCF到S-CSCF部分）；
图3为现有技术中呼叫一个注销状态或者未注册状态但签约了未注册状 态业务的用户的会话流程图；
图4为现有技术中呼叫一个注销状态或者未注册状态并且没有签约未注 册状态业务的用户的流程；
图5为现有技术中S-CSCF收到初始Invite请求后的处理流程；
图6为本发明提供的会话处理流程。
具体实施方式
本发明通过对3GPP TS23.228定义的会话流程进行扩展，使得对于局内会 话的场景下，可以有效减少不必要的信令流量，节省带宽等网络资源。下面首 先对本发明中定义的IMS局内会话进fiH兑明：
IMS局内会话，在本方案中指以下三种情况下的IMS会话：
1) 主被叫用户都是注册状态，同时注册在同一个S-CSCF上；
2) 主叫用户为注册状态，被叫用户为未注册状态但签约了未注册状态的 业务，被叫用户数据保留在主叫用户注册的S-CSCF上；
3) 主叫用户为注册状态，被叫用户为未注册状态同时没有签约未注册状 态的业务，被叫用户数据保留在主叫用户注册的S-CSCF上。
对于前两种局内会话的情形，在3GPP定义的会话流程中，主叫侧S-CSCF收到初始Invite请求后，会根据被叫PUI将请求转发给相应的I-CSCF (图2 中步骤24，图3中的步骤34)，由I-CSCF向HSS发起用户位置査询-LIR/LIA (图2中步骤26/27，图3中步骤36/37)，由于主被叫用户信息保存在同一个 S-CSCF上，I-CSCF会根据LIR/LIA查询结果，将Invite请求又转回给主叫 S-CSCF (图2中步骤28，图3中步骤39)。对于这两种局内会话的情形，经 过一系列Invite消息的处理转发，以及LIR/LIA信令处理之后，Invite请求又 回到了主叫侧的S-CSCF，因此这些信令处理过程（图2中步骤24-29，图3 中的步骤34-310)是不必要的。同样，对于图2中后续的183、 180、 200OK 消息（对Invite消息的应答）也没有必要经过I-CSCF。
第三种局内会话的情形，尽管被叫用户没有签约未注册状态的业务， S-CSCF可以设置在用户注销时保留用户的相关数据，而将用户状态更新为未 注册状态。在3GPP定义的会话流程中，对于该局内会话的情形，主叫侧S-CSCF 收到初始Invite请求后，会根据被叫PUI将请求转发给相应的I-CSCF (图4 中步骤44)，由I-CSCF向HSS发起用户位置査询-LIR/LIA (图4中的步骤 46/47),由于被叫PUI为未注册状态，同时没有签约未注册状态的业务，HSS 会在LIA响应中将Experimental-Result-Code设置为
DIAMETER—ERROR—IDENTITY—NOT—REGISTERED,之后I-CSCF根据LIA 响应，向主叫侧S-CSCF返回失败消息，如404消息（图4中步骤48)，主叫 S-CSCF将该消息转发给主叫侧P-CSCF。而实际上，对于这种局内会话的情 形，当主叫侧S-CSCF收到Invite请求后，可以经过查询自身保存的被叫用户 数据，得知被叫用户为未注册状态，同时没有签约未注册状态的业务，这样 S-CSCF可以直接向P-CSCF返回失败消息，如404消息，而无需再根据被叫 PUI来选择I-CSCF ，经过I-CSCF向HSS发起LIR/LIA査询后，由I-CSCF返 回失败指示消息，即对于第三种局内会话的情形，图4中的步骤44-49是不必 要的。
本发明主要是针对S-CSCF的呼叫处理过程进行扩展，当S-CSCF收到 Invite请求后，处理流程如下：
步骤IOI.调用主叫用户签约的业务逻辑来建立会话，如触到相应的AS
等；
步骤102.判断目的地址类型，-如果是SIPURI，直接进行步骤104;
-否则继续步骤103;
步骤103.向Emim服务器进行号码解析，
-如果Enum服务器中存在对应的SIPURI，贝lj S-CSCF将Invite请求消 息中的目的地址转为对应的SIPURI，执行步骤104;
-否则，贝IJS-CSCF将Invite请求转发给相应的BGCF，由BGCF进行后 续处理；
步骤104.进行目的地址分析，判断目的地址是否在该S-CSCF允许注册 的域内，
-如果目的地址在S-CSCF允许注册的域内，则继续步骤105;
-否则，S-CSCF将请求发送到相应的I-CSCF做进一步处理；
注：在IMS系统中，用户注册时将根据域名路由到归属网络中，这样 S-CSCF上将只会注册上属于有限的若干域的用户，也就是说根据网络配置 S-CSCF允许这些特定域用户的注册。
步骤105. S-CSCF査询是否保存有被叫用户信息（被叫用户可以是注册 或未注册状态）：
-如果保存有被叫用户信息，S-CSCF检査被叫PUI状态及相关业务信息， -如果PUI是注册状态，或者是未注册状态但有未注册状态的业务， S-CSCF直接调用被叫用户签约的业务逻辑来建立会话：S-CSCF向被叫侧 P-CSCF或AS发送Invite请求时，在Invite消息中Via头域和Record-Route 头域分别添加两条S-CSCF地址。当S-CSCF收到后续的响应消息，如183、 180、2000K(对Invite消息的应答）时，根据响应消息中Via头域中两条S-CSCF 地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会话处理。本方案不 影响S-CSCF对后续请求消息的处理。
-如果PUI是未注册状态，并且没有未注册状态的业务，S-CSCF直 接向P-CSCF返回404消息；
-否则，S-CSCF根据被叫用户目的地址将请求转发到相应的I-CSCF，按 照标准流程作进一步处理。
具体流程如图6所示，包括：
步骤601 ，主叫侧S-CSCF收到初始Invite请求；步骤602，调用主叫用户签约的业务逻辑来建立会话，如触到相应的AS
等；
步骤603，被叫PUI是否是SIPURI?如果是，执行步骤604，否则执行 步骤605;
步骤604，判断目的地址是否在本S-CSCF允许注册的域内，如果是执行 步骤607，否则执行步骤613;
步骤605，向Enum服务器进行号码解析，是否有对应的SIP URI?如果 是，执行步骤606,否则执行步骤615;
步骤606，将TdURI替换为对应的SIPURI，执行步骤604;
步骤607,是否有被叫用户的注册信息（注册/未注册状态）？如果是，执 行步骤608，否则执行步骤613;
步骤608， S-CSCF检査PUI状态及相关业务信息，并根据PUI状态及相 应信息，执行步骤609或步骤610;
步骤609，如果PUI是注册状态，或者是未注册状态但有未注册状态的业 务，则执行步骤611;
步骤610，如果PUI是未注册状态，并且没有未注册状态的业务，则执行 步骤612;
步骤6U， S-CSCF调用被叫用户签约的业务逻辑来建立会话：S-CSCF向 被叫侧P-CSCF或AS发送Invite请求时，在Invite消息中Via头域和 Record-Route头域分别添加两条S-CSCF地址。当S-CSCF收到后续的响应消 息，如183、 180、 2000K (对Invite消息的应答）时，根据响应消息中Via头 域中两条S-CSCF地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会 话处理。本方案不影响S-CSCF对后续请求消息的处理。
步骤612， S-CSCF向P-CSCF返回404消息；
步骤613， S-CSCF根据PUI进行目的地址分析，将Invite请求转发给相
应的I-CSCF;
步骤614，下述流程同3GPP定义的标准流程； 步骤615，将Invite请求转交给BGCF进行后续处理。 本发明提供的会话处理流程，针对前面所述的三种局内会话的情况，当主 叫侧S-CSCF收到初始Invite请求后，主叫侧S-CSCF通过查询自身数据获知其保存了被叫用户信息，进而直接进行相应的处理，如调用合适的业务逻辑，
或向P-CSCF返回失败消息等，进而可以减少原有图2所示流程中24-29、 214-215、 230-231、 240-241共12条消息；减少原有图3所示流程中34-37、 39-310共6条消息（图3中未包括后续可能的183、 180等消息）；减少原有 图4所示流程中44-49共6条消息（被叫为未注册状态的情况）。
本方明提供的会话流程可以减少局内会话场景下不必要的信令交互，节省 端口及带宽等资源。对于其他非局内会话的影响在于引入了步骤604和607 两个判断过程，不会对会话建立时延等造成明显的影响。
本发明提供的会话流程，只对S-CSCF进行了一定的扩展，对其他IMS 网络设备没有要求，不影响与不支持这种优化会话流程设备间的互通。
本领域的技术人员在不脱离权利要求书确定的本发明的精神和范围的条 件下，还可以对以上内容进行各种各样的修改。因此本发明的范围并不仅限于 以上的说明，而是由权利要求书的范围来确定的。
IMS局内会话，在本方案中指以下三种情况下的IMS会话：
1) 主被叫用户都是注册状态，同时注册在同一个S-CSCF上；
2) 主叫用户为注册状态，被叫用户为未注册状态但签约了未注册状态的 业务，被叫用户数据保留在主叫用户注册的S-CSCF上；
3) 主叫用户为注册状态，被叫用户为未注册状态同时没有签约未注册状 态的业务，被叫用户数据保留在主叫用户注册的S-CSCF上。
对于前两种局内会话的情形，在3GPP定义的会话流程中，主叫侧S-CSCF收到初始Invite请求后，会根据被叫PUI将请求转发给相应的I-CSCF (图2 中步骤24，图3中的步骤34)，由I-CSCF向HSS发起用户位置査询-LIR/LIA (图2中步骤26/27，图3中步骤36/37)，由于主被叫用户信息保存在同一个 S-CSCF上，I-CSCF会根据LIR/LIA查询结果，将Invite请求又转回给主叫 S-CSCF (图2中步骤28，图3中步骤39)。对于这两种局内会话的情形，经 过一系列Invite消息的处理转发，以及LIR/LIA信令处理之后，Invite请求又 回到了主叫侧的S-CSCF，因此这些信令处理过程（图2中步骤24-29，图3 中的步骤34-310)是不必要的。同样，对于图2中后续的183、 180、 200OK 消息（对Invite消息的应答）也没有必要经过I-CSCF。
第三种局内会话的情形，尽管被叫用户没有签约未注册状态的业务， S-CSCF可以设置在用户注销时保留用户的相关数据，而将用户状态更新为未 注册状态。在3GPP定义的会话流程中，对于该局内会话的情形，主叫侧S-CSCF 收到初始Invite请求后，会根据被叫PUI将请求转发给相应的I-CSCF (图4 中步骤44)，由I-CSCF向HSS发起用户位置査询-LIR/LIA (图4中的步骤 46/47),由于被叫PUI为未注册状态，同时没有签约未注册状态的业务，HSS 会在LIA响应中将Experimental-Result-Code设置为
DIAMETER—ERROR—IDENTITY—NOT—REGISTERED,之后I-CSCF根据LIA 响应，向主叫侧S-CSCF返回失败消息，如404消息（图4中步骤48)，主叫 S-CSCF将该消息转发给主叫侧P-CSCF。而实际上，对于这种局内会话的情 形，当主叫侧S-CSCF收到Invite请求后，可以经过查询自身保存的被叫用户 数据，得知被叫用户为未注册状态，同时没有签约未注册状态的业务，这样 S-CSCF可以直接向P-CSCF返回失败消息，如404消息，而无需再根据被叫 PUI来选择I-CSCF ，经过I-CSCF向HSS发起LIR/LIA査询后，由I-CSCF返 回失败指示消息，即对于第三种局内会话的情形，图4中的步骤44-49是不必 要的。
本发明主要是针对S-CSCF的呼叫处理过程进行扩展，当S-CSCF收到 Invite请求后，处理流程如下：
步骤IOI.调用主叫用户签约的业务逻辑来建立会话，如触到相应的AS
等；
步骤102.判断目的地址类型，-如果是SIPURI，直接进行步骤104;
-否则继续步骤103;
步骤103.向Emim服务器进行号码解析，
-如果Enum服务器中存在对应的SIPURI，贝lj S-CSCF将Invite请求消 息中的目的地址转为对应的SIPURI，执行步骤104;
-否则，贝IJS-CSCF将Invite请求转发给相应的BGCF，由BGCF进行后 续处理；
步骤104.进行目的地址分析，判断目的地址是否在该S-CSCF允许注册 的域内，
-如果目的地址在S-CSCF允许注册的域内，则继续步骤105;
-否则，S-CSCF将请求发送到相应的I-CSCF做进一步处理；
注：在IMS系统中，用户注册时将根据域名路由到归属网络中，这样 S-CSCF上将只会注册上属于有限的若干域的用户，也就是说根据网络配置 S-CSCF允许这些特定域用户的注册。
步骤105. S-CSCF査询是否保存有被叫用户信息（被叫用户可以是注册 或未注册状态）：
-如果保存有被叫用户信息，S-CSCF检査被叫PUI状态及相关业务信息， -如果PUI是注册状态，或者是未注册状态但有未注册状态的业务， S-CSCF直接调用被叫用户签约的业务逻辑来建立会话：S-CSCF向被叫侧 P-CSCF或AS发送Invite请求时，在Invite消息中Via头域和Record-Route 头域分别添加两条S-CSCF地址。当S-CSCF收到后续的响应消息，如183、 180、2000K(对Invite消息的应答）时，根据响应消息中Via头域中两条S-CSCF 地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会话处理。本方案不 影响S-CSCF对后续请求消息的处理。
-如果PUI是未注册状态，并且没有未注册状态的业务，S-CSCF直 接向P-CSCF返回404消息；
-否则，S-CSCF根据被叫用户目的地址将请求转发到相应的I-CSCF，按 照标准流程作进一步处理。
具体流程如图6所示，包括：
步骤601 ，主叫侧S-CSCF收到初始Invite请求；步骤602，调用主叫用户签约的业务逻辑来建立会话，如触到相应的AS
等；
步骤603，被叫PUI是否是SIPURI?如果是，执行步骤604，否则执行 步骤605;
步骤604，判断目的地址是否在本S-CSCF允许注册的域内，如果是执行 步骤607，否则执行步骤613;
步骤605，向Enum服务器进行号码解析，是否有对应的SIP URI?如果 是，执行步骤606,否则执行步骤615;
步骤606，将TdURI替换为对应的SIPURI，执行步骤604;
步骤607,是否有被叫用户的注册信息（注册/未注册状态）？如果是，执 行步骤608，否则执行步骤613;
步骤608， S-CSCF检査PUI状态及相关业务信息，并根据PUI状态及相 应信息，执行步骤609或步骤610;
步骤609，如果PUI是注册状态，或者是未注册状态但有未注册状态的业 务，则执行步骤611;
步骤610，如果PUI是未注册状态，并且没有未注册状态的业务，则执行 步骤612;
步骤6U， S-CSCF调用被叫用户签约的业务逻辑来建立会话：S-CSCF向 被叫侧P-CSCF或AS发送Invite请求时，在Invite消息中Via头域和 Record-Route头域分别添加两条S-CSCF地址。当S-CSCF收到后续的响应消 息，如183、 180、 2000K (对Invite消息的应答）时，根据响应消息中Via头 域中两条S-CSCF地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会 话处理。本方案不影响S-CSCF对后续请求消息的处理。
步骤612， S-CSCF向P-CSCF返回404消息；
步骤613， S-CSCF根据PUI进行目的地址分析，将Invite请求转发给相
应的I-CSCF;
步骤614，下述流程同3GPP定义的标准流程； 步骤615，将Invite请求转交给BGCF进行后续处理。 本发明提供的会话处理流程，针对前面所述的三种局内会话的情况，当主 叫侧S-CSCF收到初始Invite请求后，主叫侧S-CSCF通过查询自身数据获知其保存了被叫用户信息，进而直接进行相应的处理，如调用合适的业务逻辑，
或向P-CSCF返回失败消息等，进而可以减少原有图2所示流程中24-29、 214-215、 230-231、 240-241共12条消息；减少原有图3所示流程中34-37、 39-310共6条消息（图3中未包括后续可能的183、 180等消息）；减少原有 图4所示流程中44-49共6条消息（被叫为未注册状态的情况）。
本方明提供的会话流程可以减少局内会话场景下不必要的信令交互，节省 端口及带宽等资源。对于其他非局内会话的影响在于引入了步骤604和607 两个判断过程，不会对会话建立时延等造成明显的影响。
本发明提供的会话流程，只对S-CSCF进行了一定的扩展，对其他IMS 网络设备没有要求，不影响与不支持这种优化会话流程设备间的互通。
本领域的技术人员在不脱离权利要求书确定的本发明的精神和范围的条 件下，还可以对以上内容进行各种各样的修改。因此本发明的范围并不仅限于 以上的说明，而是由权利要求书的范围来确定的。