CN100589603C - 一种ims会话处理方法及系统 - Google Patents
一种ims会话处理方法及系统 Download PDFInfo
- Publication number
- CN100589603C CN100589603C CN200710120673A CN200710120673A CN100589603C CN 100589603 C CN100589603 C CN 100589603C CN 200710120673 A CN200710120673 A CN 200710120673A CN 200710120673 A CN200710120673 A CN 200710120673A CN 100589603 C CN100589603 C CN 100589603C
- Authority
- CN
- China
- Prior art keywords
- cscf
- called
- pui
- session
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及一种IMS会话处理方法，包括：步骤11，主叫侧S-CSCF判断是否有被叫用户的注册信息，如果是，执行步骤12，否则，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP标准会话流程处理；步骤12，S-CSCF检查被叫PUI状态及签约信息，并进行处理。本发明在3GPP IMS会话流程的基础上，对S-CSCF功能进行一定的扩展，进而对IMS会话处理流程进行优化，可以减少IMS局内会话时不必要的信令交互，有效降低信令流量及设备处理负荷，提升业务质量。
Description
技术领域
本发明涉及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系统中有三种用户状态：
注册状态(registered state)：用户成功注册，并且网络给用户分配了一个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返回100trying(尝试中)消息，表示由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返回100trying消息，表示由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返回100trying消息，表示由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#1返回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(公共用户标识)是否是SIP URI(SIP统一资源标识符)，如果是，执行步骤504，如果否，执行步骤505；
步骤504，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，执行步骤507；
步骤505，向Enum(电话号码映射)服务器进行号码解析，是否有对应的SIP URI，如果是，执行步骤506，如果否，执行步骤523；
步骤506，将Tel URI(电话统一资源定位符)替换为对应的SIP URI，执行步骤504；
步骤507，I-CSCF向HSS发起用户位置查询请求(LIR)；
步骤508，HSS检查PUI状态及相关业务信息，依据PUI状态及相关业务信息，相应执行步骤509、510、511；
步骤509，如果PUI是注册状态，或者是未注册状态但有未注册状态的业务，执行步骤512；
步骤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会话处理方法，包括：
步骤11，主叫侧S-CSCF判断是否有被叫用户的注册信息，如果是，执行步骤12，否则，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP标准会话流程处理；
步骤12，S-CSCF检查被叫PUI状态及业务信息，并进行处理。
步骤11之前还包括步骤10，主叫侧S-CSCF判断被叫PUI目的地址是否在该S-CSCF允许注册的域内，如果是执行步骤11，否则，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地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会话处理。
步骤11之前还包括：
步骤501，主叫侧S-CSCF收到初始请求消息；
步骤502，调用主叫用户签约的业务逻辑来建立会话；
步骤503，判断被叫PUI是否是SIP URI，如果是，执行步骤11，否则执行步骤504；
步骤504，向Enum服务器进行号码解析，判断是否有对应的SIP URI，如果是，执行步骤505，否则将Invite请求转交给BGCF进行后续处理；
步骤505，将Tel URI替换为对应的SIP URI，执行步骤11。
所述失败消息是404消息。
本发明提供了一种IMS会话处理系统，该系统包括S-CSCF、I-CSCF，S-CSCF还用于：
判断是否有被叫用户的注册信息；如果有被叫用户的注册信息，S-CSCF检查被叫PUI状态及业务信息，并进行处理；如果没有被叫用户的注册信息，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照3GPP标准会话流程处理。
S-CSCF还用于判断被叫PUI目的地址是否在该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为本发明提供的会话处理流程。
具体实施方式
本发明通过对3GPP TS23.228定义的会话流程进行扩展，使得对于局内会话的场景下，可以有效减少不必要的信令流量，节省带宽等网络资源。下面首先对本发明中定义的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请求后，处理流程如下：
步骤101.调用主叫用户签约的业务逻辑来建立会话，如触到相应的AS等；
步骤102.判断目的地址类型，
-如果是SIP URI，直接进行步骤104；
-否则继续步骤103；
步骤103.向Enum服务器进行号码解析，
-如果Enum服务器中存在对应的SIP URI，则S-CSCF将Invite请求消息中的目的地址转为对应的SIP URI，执行步骤104；
-否则，则S-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是否是SIP URI？如果是，执行步骤604，否则执行步骤605；
步骤604，判断目的地址是否在本S-CSCF允许注册的域内，如果是执行步骤607，否则执行步骤613；
步骤605，向Enum服务器进行号码解析，是否有对应的SIP URI？如果是，执行步骤606，否则执行步骤615；
步骤606，将Tel URI替换为对应的SIP URI，执行步骤604；
步骤607，是否有被叫用户的注册信息(注册/未注册状态)？如果是，执行步骤608，否则执行步骤613；
步骤608，S-CSCF检查PUI状态及相关业务信息，并根据PUI状态及相应信息，执行步骤609或步骤610；
步骤609，如果PUI是注册状态，或者是未注册状态但有未注册状态的业务，则执行步骤611；
步骤610，如果PUI是未注册状态，并且没有未注册状态的业务，则执行步骤612；
步骤611，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网络设备没有要求，不影响与不支持这种优化会话流程设备间的互通。
本领域的技术人员在不脱离权利要求书确定的本发明的精神和范围的条件下，还可以对以上内容进行各种各样的修改。因此本发明的范围并不仅限于以上的说明，而是由权利要求书的范围来确定的。
Claims (8)
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允许注册的域内，如果是，执行步骤11，否则，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是否是SIP URI，如果是，执行步骤11，否则执行步骤504；
步骤504，向Enum服务器进行号码解析，判断是否有对应的SIP URI，如果是，执行步骤505，否则将Invite请求转交给BGCF进行后续处理；
步骤505，将Tel URI替换为对应的SIP URI，执行步骤11。
5、如权利要求1所述的IMS会话处理方法，其特征在于，所述失败消息是404消息。
6、一种IMS会话处理系统，该系统包括S-CSCF、I-CSCF，其特征在于，S-CSCF还用于：
判断是否有被叫用户的注册信息；如果有被叫用户的注册信息，S-CSCF检查被叫PUI状态及业务信息，并进行处理；如果没有被叫用户的注册信息，S-CSCF根据被叫PUI进行目的地址分析，将Invite请求转发给相应的I-CSCF，I-CSCF按照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地址得知这是局内会话的情况，分别进行被叫侧和主叫侧会话处理。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710120673A CN100589603C (zh) | 2007-08-23 | 2007-08-23 | 一种ims会话处理方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710120673A CN100589603C (zh) | 2007-08-23 | 2007-08-23 | 一种ims会话处理方法及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101141678A CN101141678A (zh) | 2008-03-12 |
| CN100589603C true CN100589603C (zh) | 2010-02-10 |
Family
ID=39193367
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200710120673A Active CN100589603C (zh) | 2007-08-23 | 2007-08-23 | 一种ims会话处理方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100589603C (zh) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102143478B (zh) * | 2010-09-21 | 2014-01-01 | 华为技术有限公司 | 业务参数的处理方法及装置 |
| CN102137347B (zh) * | 2010-11-04 | 2013-10-09 | 华为技术有限公司 | 提供主叫信息的呼叫方法、系统和业务控制点 |
| CN103037501B (zh) * | 2011-09-30 | 2016-03-02 | 中国移动通信集团河南有限公司 | 一种网际协议多媒体子系统终端的注册方法、设备及系统 |
| CN103618739B (zh) * | 2013-12-09 | 2017-02-15 | 中国联合网络通信集团有限公司 | 一种增强的s‑cscf服务器的数据处理方法及装置 |
| CN104717180B (zh) * | 2013-12-13 | 2019-02-26 | 中国电信股份有限公司 | Ims网络中抑制被叫业务触发的方法和系统 |
| CN113543163B (zh) * | 2020-04-16 | 2023-08-15 | 中国移动通信集团设计院有限公司 | 提升Volte端到端语音质量方法及装置 |
| CN114979006B (zh) * | 2021-10-14 | 2023-09-05 | 中移互联网有限公司 | 一种会话初始协议sip消息处理方法及其消息处理系统 |
| CN114070823B (zh) * | 2021-11-10 | 2023-11-03 | 北京挪拉斯坦特芬通信设备有限公司 | 会话建立控制方法、电子设备和计算机可读存储介质 |
-
2007
- 2007-08-23 CN CN200710120673A patent/CN100589603C/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN101141678A (zh) | 2008-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9906566B2 (en) | Voice session termination for messaging clients in IMS | |
| CN100589603C (zh) | 一种ims会话处理方法及系统 | |
| US9906565B2 (en) | Method, apparatus and program product for merging communication sessions in an IMS | |
| US7586903B2 (en) | System and method for VoIP call transfer using instant message service in an IP multimedia subsystem | |
| JP4700105B2 (ja) | Ｉｐマルチメディアサブシステム（ｉｍｓ）おける呼転送 | |
| US20050213606A1 (en) | Method of triggering application service using response filter criteria and IP multimedia subsystem using the same | |
| JP5606074B2 (ja) | 通信ネットワークにおける動的サービストリガ | |
| CA2605475C (en) | Session initiation from application servers in an ip multimedia subsystem | |
| US8774178B2 (en) | Call transfer with multiple application servers in session initiation protocol-based network | |
| EP2182692A1 (en) | A method, device and system for processing the continuity of the media stream in a session | |
| CN100574474C (zh) | 一种通讯系统中建立通讯业务连接的方法 | |
| KR100703426B1 (ko) | 아이피 기반 멀티미디어 서브시스템에서 가입자 정보유실시 발신 및 착신 호를 가능하게 하는 방법 및 장치 | |
| CN100550884C (zh) | 基于重试机制的业务过程中对sip协议请求的处理方法 | |
| CN101031139B (zh) | 用于呼叫控制实体释放会话的方法 | |
| JP5212363B2 (ja) | 通信システム、通信装置および輻輳発生時の迂回制御方法 | |
| JP2010525623A (ja) | 通信ネットワークにおいて使用する方法、および、装置 | |
| CN102006272B (zh) | 应用服务器对Replace参数的替换方法及系统 | |
| JP5063530B2 (ja) | Ｉｍｓネットワークを介したｓｉｐ非対応サーバへのアクセス方法及びシステム | |
| KR20100131787A (ko) | Ｉｍｓ망의 호 처리 방법 및 장치 | |
| KR20100040567A (ko) | 인터넷 기반의 호 처리 방법 및 시스템 | |
| JP2010183480A (ja) | リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |