CN101325733A - Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 - Google Patents
Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 Download PDFInfo
- Publication number
- CN101325733A CN101325733A CNA200710108470XA CN200710108470A CN101325733A CN 101325733 A CN101325733 A CN 101325733A CN A200710108470X A CNA200710108470X A CN A200710108470XA CN 200710108470 A CN200710108470 A CN 200710108470A CN 101325733 A CN101325733 A CN 101325733A
- Authority
- CN
- China
- Prior art keywords
- multimedia system
- working method
- medium
- state
- medium working
- 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.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种IMS集中业务呼叫保持和呼叫恢复实现方法,用以实现本地IMS集中业务UE与远端UE之间的呼叫保持和呼叫恢复,包括如下步骤:本地IMS集中业务UE向IP多媒体子***电路域控制功能发送呼叫保持请求消息或呼叫恢复请求消息,请求消息中携带有本地IMS集中业务UE所设置的媒体工作方式指示;IP多媒体子***电路域控制功能将相应的媒体工作方式指示分别发送给远端UE和媒体网关控制功能;远端UE根据接收到的媒体工作方式指示,设置本端的媒体工作方式;媒体网关控制功能根据接收到的媒体工作方式指示,设置媒体网关的媒体工作方式。采用本发明方法,实现了IMS集中业务的呼叫保持或呼叫恢复。
Description
技术领域
本发明涉及IP(网络互联协议,Internet Protocol,简称IP)多媒体子***(IP Multimedia Core Network Subsystem,简称IMS),尤其涉及IMS集中业务呼叫保持和呼叫恢复实现方法。
背景技术
IMS是由第三代合作伙伴计划(3rd Generation Partnership Project,简称3GPP)提出的一种基于IP的网络架构。其构建了一个开放而灵活的业务环境,支持多媒体应用,并为用户提供丰富的多媒体业务。
IMS是基于IP的电信网络架构,与接入技术无关,除了可以为GPRS(General Packet Radio Service,通用分组无线业务)、WLAN(Wireless LocalArea Network,无线局域网)等分组接入网络提供业务外,还可以为GSM(Global System for Mobile communications,全球移动通讯***)、UMTS(Universal Mobile Telecommunications System,统一移动通讯***)等移动蜂窝网络提供业务。
GSM、UMTS等移动蜂窝网络采用电路交换技术,称为电路(CircuitSwitched,简称CS)域,能够为用户提供基本的语音业务,以及基于语音业务的补充业务。当CS域接入IMS时,其演变为一种接入方式,业务完全由IMS统一提供,这种技术称为IMS集中业务(IMS Centralized Service,简称ICS)。
图1是IMS集中业务场景的架构图,有如下网元:
101用户设备(User Equipment,简称UE)
102拜访移动交换中心(Visited Mobile Switch Center,简称VMSC)
103归属用户服务器(Home Subscriber Server,简称HSS)
104媒体网关控制功能(Media Gateway Control Function,简称MGCF)
105媒体网关(Media Gateway,简称MGW)
106IMS电路域控制功能(IMS CS Control Function,简称ICCF)
107呼叫会话控制功能(Call Session Control Function,简称CSCF)
UE_101到IMS域共建立3条路径,分别是:会话控制路径、承载控制路径和承载路径。
其中会话控制路径在UE_101和ICCF_106之间传递会话信息有如下两种方式:
(一)CS会话控制路径:承载于CS域上,采用非结构化补充业务数据(Unstructured Supplementary Service Data,简称USSD),该路径经过VMSC_102和HSS_103。
(二)CS会话控制路径:承载于PS域上,采用会话初始协议(Session InitialProtocol,简称SIP),该路径经过IP承载网、IMS域中的CSCF_107。
承载控制路径控制着承载路径的建立以及承载资源的管理,UE_101采用标准的CS控制信令接入VMSC_102,并通过MGCF_104接入到IMS,经过CSCF_107到达ICCF。
承载路径是UE_101通过VMSC_102和MGW_105接入到IMS,并与该会话的远端用户设备建立媒体连接。
IMS集中业务利用会话控制路径在UE_101和ICCF_106之间交互会话控制信息,并通过承载控制路径建立和***体承载,ICCF_106充当IMS用户设备代理,代替用户设备接入IMS。
呼叫保持(Call Hold)业务是通信***中的一种补充业务,包括呼叫保持和呼叫恢复两个过程。当两个用户(用户A和用户B)在通信***中建立通话后,其中一个用户(以用户A为例)可以请求远端用户(用户B)保持当前通话连接,但不进行语音传输,此为呼叫保持过程。用户A的UE(UE-A)和用户B的UE(UE-B)还可以从呼叫保持状态重新转入通话状态,这个过程称为呼叫恢复(Call Resume)过程。
在呼叫保持上,用户A可以拨打或接听第三方如用户C,建立与用户C之间的通话。用户A还可以在与用户B和用户C的两个通话之间切换。
ICS作为一种电信***,必须要支持呼叫保持业务。在目前的ICS中,呼叫保持和呼叫恢复是由ICS用户设备通知ICCF,由ICCF代替ICS用户设备执行呼叫保持和呼叫恢复过程,下面以呼叫保持为例说明实现方式,具体过程如图2所示。
UE-A具备ICS能力,通过VMSC、ICCF、MGCF、CSCF等设备建立了与远端终端UE-B之间的通话,并通过VMSC、MGW与UE-B建立双向的媒体连接。当用户A希望启动呼叫保持时,参见图2,有以下步骤:
步骤201,UE-A通过会话控制路径向ICCF发送呼叫保持请求。
步骤202,ICCF分别向UE-B和MGCF发送媒体更新消息(分别如附图标记202a和202b所示),请求消息中媒体工作方式为“未激活”,分别指示UE-B和MGCF进入未激活状态,不接收也不发送媒体流。
步骤203,UE-B控制本终端的媒体资源迁移到“未激活”状态,不接收也不发送媒体流,并向ICCF返回媒体更新成功响应(如附图标记203a所示);MGCF也控制MGW的媒体资源迁移到“未激活”状态,不接收也不发送媒体流,并向ICCF返回媒体更新成功响应(如附图标记203b所示)。
步骤204,ICCF收到UE-B和MGCF的成功响应后,通过会话控制路径向UE-A返回呼叫保持成功响应。
此时,UE-A和UE-B进入呼叫保持状态,MGW和UE-B之间的媒体流中断,也即UE-A和UE-B之间仍然保持通话连接,但媒体流中断。
当UE-A希望恢复与UE-B之间的媒体传输时,与呼叫保持过程类似。由UE-A发送呼叫恢复请求到ICCF,ICCF分别向UE-B和MGCF发送媒体更新消息,指示UE-B和MGCF/MGW分别将媒体资源状态迁移到“发送接收”状态,同时进行发送和接收工作,从而恢复原来的通话状态。
目前这种实现方式存在以下问题:
(1)根据呼叫保持的要求,双方用户都处于通话状态时,当一个用户(例如用户A)向另外一个用户(用户B)发送呼叫保持请求,请求消息中包含“只发送”指示。在呼叫保持成功后,UE-A处于“只发送”状态(Sendonly),向UE-B发送媒体流,而不再接收UE-B的媒体流;UE-B处于“只接收”状态(Recvonly),只接收对端媒体流,而不再向对端发送媒体流,即只存在UE-A到UE-B的单向媒体流,此时可以由UE-A或网络向UE-B播放保持音提示。
如果UE-A处于“只接收”状态,UE-B处于“只发送”状态,UE-A向UE-B发送呼叫保持,请求消息中包含“未激活”指示。在呼叫保持成功后,UE-A和UE-B都处于“未激活”状态,停止发送和接收媒体流。
因此目前的方法是从“发送接收”状态直接迁移到“未激活”状态,无法满足呼叫保持在不同状态下的需求。
(2)在呼叫保持状态下,通常会由网络向被保持的UE播放保持音,如果向被保持的UE发送含“非激活”的媒体指示,被保持的UE将停止接收和发送,此时网络无法向被保持的UE播放保持音,从而影响用户体验。
综上所述,目前的ICS呼叫保持方法无法满足呼叫保持的业务需求,并影响被保持用户的业务体验。
发明内容
本发明所要解决的技术问题是在于需要提供一种IMS集中业务呼叫保持和呼叫恢复实现方法,以满足IMS集中业务中呼叫保持业务的业务需求。
为了解决上述技术问题,本发明首先提供了一种IP多媒体子***集中业务呼叫保持实现方法,用以实现本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持,包括如下步骤:
(1)所述本地IP多媒体子***集中业务用户设备向IP多媒体子***电路域控制功能发送呼叫保持请求消息,所述呼叫保持请求消息中携带有所述本地IP多媒体子***集中业务用户设备所设置的媒体工作方式指示;
(2)所述IP多媒体子***电路域控制功能将相应的媒体工作方式指示分别发送给所述远端用户设备和媒体网关控制功能;
(3)所述远端用户设备根据接收到的媒体工作方式指示,设置本端的媒体工作方式;所述媒体网关控制功能根据接收到的媒体工作方式指示,设置媒体网关的媒体工作方式,完成所述本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持。
根据上述的IP多媒体子***集中业务呼叫保持实现方法,步骤(1)中所述媒体工作方式指示,可以由所述本地IP多媒体子***集中业务用户设备根据当前自身的媒体工作状态而设置。
进一步地,所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态可以包括“发送接收”状态或“只接收”状态。
再进一步地,步骤(1)中:如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“发送接收”状态,则所述媒体工作方式设置可以为“只发送”状态;如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“只接收”状态,则所述媒体工作方式设置可以为“未激活”状态。
更进一步地,如果所述步骤(1)中所述媒体工作方式指示为“只发送”状态,则步骤(2)中所述IP多媒体子***电路域控制功能可以向所述远端用户设备发送的媒体工作方式指示为“只发送”状态,可以向所述媒体网关控制功能发送的媒体工作方式指示为“只接收”状态;如果所述步骤(1)中所述媒体工作方式指示为“未激活”状态,则步骤(2)中所述IP多媒体子***电路域控制功能可以向所述远端用户设备和所述媒体网关控制功能发送的媒体工作方式指示为“未激活”状态。
根据上述的IP多媒体子***集中业务呼叫保持实现方法,步骤(2)中所述IP多媒体子***电路域控制功能可以通过媒体更新或重邀请请求,将所述相应的媒体工作方式分别发送给所述远端用户设备和媒体网关控制功能。
进一步地,所述IP多媒体子***电路域控制功能采用重邀请请求发送所述媒体工作方式,则步骤(3)之后所述IP多媒体子***电路域控制功能在接收到所述远端用户设备或所述媒体网关控制功能返回的重邀请成功响应后,可以进一步向所述远端用户设备或所述媒体网关控制功能发送确认消息。
根据上述的IP多媒体子***集中业务呼叫保持实现方法,可以进一步包括:
(4)所述远端用户设备和所述媒体网关控制功能向所述IP多媒体子***电路域控制功能返回媒体更新成功响应;
(5)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫保持成功响应。
本发明进而提供了一种IP多媒体子***集中业务呼叫恢复实现方法,用以实现本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫恢复,包括如下步骤:
(a)所述本地IP多媒体子***集中业务用户设备向IP多媒体子***电路域控制功能发送呼叫恢复请求消息,所述呼叫恢复请求消息中携带有所述本地IP多媒体子***集中业务用户设备所设置的媒体工作方式指示;
(b)所述IP多媒体子***电路域控制功能将相应的媒体工作方式指示分别发送给所述远端用户设备和媒体网关控制功能;
(c)所述远端用户设备根据接收到的媒体工作方式指示,设置本端的媒体工作方式;所述媒体网关控制功能根据接收到的媒体工作方式指示,设置媒体网关的媒体工作方式,完成所述本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫恢复。
根据上述的IP多媒体子***集中业务呼叫恢复实现方法,步骤(a)中所述媒体工作方式指示,可以由所述本地IP多媒体子***集中业务用户设备根据当前自身的媒体工作状态而设置。
进一步地,所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态可以包括“未激活”状态或“只发送”状态。
再进一步地,步骤(a)中:如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“未激活”状态,则所述媒体工作方式可以设置为“只接收”状态;如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“只发送”状态,则所述媒体工作方式可以设置为“发送接收”状态。
更进一步地,如果所述步骤(a)中所述媒体工作方式指示为“只接收”状态,则步骤(b)中所述IP多媒体子***电路域控制功能可以向所述远端用户设备发送的媒体工作方式指示为“只接收”状态,可以向所述媒体网关控制功能发送的媒体工作方式指示为“只发送”状态;如果所述步骤(a)中所述媒体工作方式指示为“发送接收”状态,则步骤(b)中所述IP多媒体子***电路域控制功能可以向所述远端用户设备和所述媒体网关控制功能发送的媒体工作方式指示为“发送接收”状态。
根据上述的IP多媒体子***集中业务呼叫恢复实现方法,步骤(b)中所述IP多媒体子***电路域控制功能可以通过媒体更新或重邀请请求,将所述相应的媒体工作方式分别发送给所述远端用户设备和媒体网关控制功能。
进一步地,所述IP多媒体子***电路域控制功能采用重邀请请求发送所述媒体工作方式,则步骤(c)之后所述IP多媒体子***电路域控制功能在接收到所述远端用户设备或所述媒体网关控制功能返回的重邀请成功响应后,可以进一步向所述远端用户设备或所述媒体网关控制功能发送确认消息。
根据上述的IP多媒体子***集中业务呼叫恢复实现方法,可以进一步包括:
(d)所述远端用户设备和所述媒体网关控制功能向所述IP多媒体子***电路域控制功能返回媒体更新成功响应;
(e)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫恢复成功响应。
采用本发明所述方法,ICS用户设备根据当前的媒体工作状态向ICCF发送呼叫保持或呼叫恢复请求,ICCF再根据请求中的媒体工作方式通知远端UE和MGCF/MGW执行相应的媒体控制,从而实现了IMS集中业务中呼叫保持或呼叫恢复。
附图说明
图1为现有技术中IMS集中业务实施例的架构示意图;
图2为现有技术中ICS呼叫保持实施例流程示意图;
图3为本发明ICS呼叫保持实施例流程示意图;
图4为本发明ICS呼叫恢复实施例流程示意图;
图5为本发明ICS完整呼叫保持业务实施例流程示意图。
具体实施方式
以下结合附图和具体实施方式对本发明作进一步的详细说明。
图3示出了本发明中呼叫保持的流程,包括如下步骤:
步骤301,ICS本地IMS集中业务UE通过会话控制路径向ICCF发送呼叫保持请求消息,请求消息中携带有本地IMS集中业务UE根据当前自身的媒体工作状态所设置的媒体工作方式指示;
步骤302,ICCF将相应的媒体工作方式指示分别发送给远端UE和MGCF(如步骤302a和步骤302b所示);
步骤303,远端UE根据接收到的媒体工作方式指示,设置本端的媒体工作方式(如步骤303a所示);MGCF根据接收到的媒体工作方式指示,设置MGW的媒体工作方式(如步骤303b所示);
步骤304,远端UE和MGCF均向ICCF返回媒体更新成功响应(如步骤304a和步骤304b所示);
步骤305,ICCF收到远端UE和MGCF发送的媒体更新成功响应后,通过会话控制路径向本地IMS集中业务UE返回呼叫保持成功响应,此时,本地IMS集中业务UE和远端UE进入呼叫保持状态。
步骤301中,本地IMS集中业务UE当前自身的媒体工作状态包括“发送接收”状态或“只接收”状态。进一步地,如果本地IMS集中业务UE当前自身的媒体工作状态为“发送接收”状态,则媒体工作方式设置为“只发送”;如果本地IMS集中业务UE当前自身的媒体工作状态为“只接收”状态,则媒体工作方式设置为“未激活”。
步骤302中,ICCF通过媒体更新或重邀请请求,将相应的媒体工作方式分别发送给远端用户设备和MGCF。进一步地,如果ICCF采用重邀请请求发送媒体工作方式,则在步骤304中ICCF接收到媒体更新成功响应后,需要分别向对端也即远端UE或MGCF发送确认消息。
如果步骤301中本地IMS集中业务UE向ICCF所发送的呼叫保持请求消息中的媒体工作方式指示为“只发送”,则步骤302中ICCF向远端UE发送的媒体工作方式指示为“只发送”,向MGCF发送的媒体工作方式指示为“只接收”;如果步骤301中本地IMS集中业务UE向ICCF所发送的呼叫保持请求中的媒体工作方式指示为“未激活”,则步骤302中ICCF向远端UE和MGCF发送的媒体工作方式指示均为“未激活”。
图4示出了本发明中呼叫恢复的流程,包括如下步骤:
步骤401,ICS本地IMS集中业务UE通过会话控制路径向ICCF发送呼叫恢复请求消息,请求消息中携带本地IMS集中业务UE根据当前自身的媒体工作状态所设置的媒体工作方式指示;
步骤402,ICCF将相应的媒体工作方式指示分别发送给远端UE和MGCF;
步骤403,远端UE根据接收到的媒体工作方式指示,设置本端的媒体工作方式;MGCF根据接收到的媒体工作方式指示,设置MGW的媒体工作方式;
步骤404,远端UE和MGCF均向ICCF返回媒体更新成功响应;
步骤405,ICCF收到远端UE和MGCF发送的成功响应后,通过会话控制路径向UE-A返回呼叫恢复成功响应。此时,本地IMS集中业务UE和远端UE恢复双向通话状态。
步骤401中,本地IMS集中业务UE当前自身的媒体工作状态包括“未激活”状态或“只发送”状态。进一步地,如果本地IMS集中业务UE当前自身的媒体工作状态为“未激活”状态,则媒体工作方式设置为“只接收”;如果本地IMS集中业务UE当前自身的媒体工作状态为“只发送”状态,则媒体工作方式设置为“发送接收”。
步骤402中,ICCF通过媒体更新或重邀请请求,将相应的媒体工作方式分别发送给远端用户设备和MGCF。进一步地,如果ICCF采用重邀请请求发送媒体工作方式,则在步骤404中ICCF接收到媒体更新成功响应后,需要分别向对端发送确认消息。
如果步骤401中本地IMS集中业务UE向ICCF所发送的呼叫恢复请求中的媒体工作方式指示为“只接收”,则步骤402中ICCF向远端UE发送的媒体工作方式指示为“只接收”,向MGCF发送的媒体工作方式指示为“只发送”;如果步骤401中本地IMS集中业务UE向ICCF所发送的呼叫恢复请求中的媒体工作方式指示为“发送接收”,则步骤402中ICCF向远端UE和MGCF发送的媒体工作方式指示均为“发送接收”。
图5为本发明UE-A和UE-B实现完整呼叫保持业务实施例的流程示意图,也即示出了两个UE从进入呼叫保持状态到恢复双方通话状态的全过程。其中的UE-A为本地IMS集中业务UE,具备ICS能力,通过VMSC、ICCF、MGCF、CSCF等设备建立了与远端终端UE-B之间的通话,并通过VMSC、MGW与UE-B建立了双向的媒体连接,处于双向通话状态。此时MGCF/MGW和UE-B的媒体资源都处于“发送接收”状态。完整呼叫保持业务实施例的流程包括以下步骤:
步骤501,当用户A启动呼叫保持时,UE-A通过会话控制路径向ICCF发送呼叫保持请求,该请求中携带的媒体工作方式指示设置为“只发送”。
步骤502,ICCF向UE-B发送媒体更新消息,该请求消息中媒体工作方式为“只发送”,通知UE-B对端的媒体状态将迁移到“只发送”状态,并要求UE-B相应地进入“只接收”状态(如步骤502a所示);同时,ICCF还向MGCF发送媒体更新消息,该请求消息中媒体工作方式为“只接收”,向MGCF通知UE-B准备将媒体状态迁移到“只接收”状态,并要求MGCF/MGW在IMS侧的媒体资源进入“只发送”状态,即接收UE-A的发送媒体流,并转换后发送发给UE-B,但不接收UE-B的媒体流,不向UE-A发送媒体流(如步骤502b所示)。
步骤503,UE-B控制本端的媒体资源迁移到“只接收”状态,只接收但不发送媒体流,并向ICCF返回媒体更新成功响应(如步骤503a所示);而且,MGCF控制MGW的媒体资源迁移到“只发送”状态,只向UE-B发送媒体流,但不接收UE-B的媒体流,也向ICCF返回媒体更新成功响应(如步骤503b所示)。
步骤504,ICCF收到UE-B和MGCF发送的成功响应后,通过会话控制路径向UE-A返回呼叫保持成功响应。
此时,UE-A和UE-B进入呼叫保持状态,UE-A和UE-B之间仍然保持通话连接。MGW和UE-B之间只存在从MGW到UE-B的单向媒体流,UE-A和MGW之间仍然保持双向的媒体流。UE-A可以通过会话控制路径呼叫第三方用户,而不需要重新建立与MGW之间的呼叫连接。
当UE-A希望恢复与UE-B之间的媒体传输,与呼叫保持过程类似,UE-A发送呼叫恢复请求到ICCF,ICCF分别向UE-B和MGCF发送媒体更新消息,指示UE-B和MGCF/MGW分别将媒体资源状态迁移到“发送接收”状态,同时进行发送和接收工作,从而恢复原来的通话状态。具体为:
步骤505,UE-A通过会话控制路径向ICCF发送呼叫恢复请求,请求中携带的媒体工作方式指示设置为“发送接收”。
步骤506,ICCF向UE-B发送媒体更新消息,请求消息中媒体工作方式为“发送接收”,通知UE-B对端的媒体状态将迁移到“发送接收”状态,并要求UE-B相应地进入“发送接收”状态(如步骤506a所示);同时,ICCF向MGCF发送媒体更新消息,请求消息中媒体工作方式也为“发送接收”,向MGCF通知UE-B准备将媒体状态迁移到“发送接收”状态,并要求MGCF/MGW在IMS侧的媒体资源进入“发送接收”状态,接收发送媒体流(如步骤506b所示)。
步骤507,UE-B控制本端的媒体资源迁移到“发送接收”状态,同时接收发送媒体流,并向ICCF返回媒体更新成功响应;而且,MGCF控制MGW的媒体资源也迁移到“发送接收”状态,同时接收发送媒体流,也向ICCF返回媒体更新成功响应。
步骤508,ICCF收到UE-B和MGCF发送的成功响应后,通过会话控制路径向UE-A返回呼叫恢复成功响应。此时,UE-A和UE-B恢复双向通话状态。
在上述步骤502中,也可以采用重邀请请求。如果采用重邀请请求,在步骤503中ICCF接收到成功响应后,需要分别向对端发送确认请求。
建立呼叫保持的过程中,如果UE-A处于“只接收”状态,即在IMS侧只存在从UE-B到MGW的单向媒体流,如果用户A需要启动呼叫保持,过程与步骤501~步骤504相似,只是步骤501中的媒体工作指示为“未激活”,在步骤502中ICCF向UE-B和MGCF发送的媒体更新请求中的媒体工作方式都为“未激活”,在步骤503中媒体资源状态迁移到“未激活”,即不发送也不接收媒体流。
建立呼叫恢复的过程中,如果只存在UE-A处于“未激活”状态,用户A启动呼叫恢复,其过程与步骤505~步骤508相似,只是步骤505中的媒体工作指示为“只接收”;在步骤506中ICCF向UE-B所发送的媒体更新请求中的媒体工作方式都为“只接收”,向MGCF发送的媒体更新请求中的媒体工作方式为“只发送”;在步骤507中UE-B的媒体资源状态迁移到“只发送”状态,而且MGW在IMS侧的媒体资源状态迁移到“只接收”,即恢复UE-B到MGW方向的单向媒体流。
采用本发明所述方法,通过ICS UE根据当前的媒体工作状态,向ICCF发送呼叫保持或呼叫恢复请求,并在请求中指示出相应的媒体工作方式,ICCF再根据请求中的媒体工作方式通知远端UE和MGCF/MGW执行相应的媒体控制,建立相应的媒体连接,从而达到了满足IMS集中业务中呼叫保持业务的业务需求。
当然,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围之内。
Claims (16)
1、一种IP多媒体子***集中业务呼叫保持实现方法,用以实现本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持,其特征在于,包括如下步骤:
(1)所述本地IP多媒体子***集中业务用户设备向IP多媒体子***电路域控制功能发送呼叫保持请求消息,所述呼叫保持请求消息中携带有所述本地IP多媒体子***集中业务用户设备所设置的媒体工作方式指示;
(2)所述IP多媒体子***电路域控制功能将相应的媒体工作方式指示分别发送给所述远端用户设备和媒体网关控制功能;
(3)所述远端用户设备根据接收到的媒体工作方式指示,设置本端的媒体工作方式;所述媒体网关控制功能根据接收到的媒体工作方式指示,设置媒体网关的媒体工作方式,完成所述本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持。
2、如权利要求1所述的方法,其特征在于,
步骤(1)中所述媒体工作方式指示,由所述本地IP多媒体子***集中业务用户设备根据当前自身的媒体工作状态而设置。
3、如权利要求2所述的方法,其特征在于,
所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态包括“发送接收”状态或“只接收”状态。
4、如权利要求3所述的方法,其特征在于,
步骤(1)中:
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“发送接收”状态,则所述媒体工作方式设置为“只发送”状态;
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“只接收”状态,则所述媒体工作方式设置为“未激活”状态。
5、如权利要求4所述的方法,其特征在于,
如果所述步骤(1)中所述媒体工作方式指示为“只发送”状态,则步骤(2)中所述IP多媒体子***电路域控制功能向所述远端用户设备发送的媒体工作方式指示为“只发送”状态,向所述媒体网关控制功能发送的媒体工作方式指示为“只接收”状态;
如果所述步骤(1)中所述媒体工作方式指示为“未激活”状态,则步骤(2)中所述IP多媒体子***电路域控制功能向所述远端用户设备和所述媒体网关控制功能发送的媒体工作方式指示为“未激活”状态。
6、如权利要求1所述的方法,其特征在于,
步骤(2)中所述IP多媒体子***电路域控制功能通过媒体更新或重邀请请求,将所述相应的媒体工作方式分别发送给所述远端用户设备和媒体网关控制功能。
7、如权利要求6所述的方法,其特征在于,
所述IP多媒体子***电路域控制功能采用重邀请请求发送所述媒体工作方式,则步骤(3)之后所述IP多媒体子***电路域控制功能在接收到所述远端用户设备或所述媒体网关控制功能返回的重邀请成功响应后,进一步向所述远端用户设备或所述媒体网关控制功能发送确认消息。
8、如权利要求1所述的方法,其特征在于,进一步包括:
(4)所述远端用户设备和所述媒体网关控制功能向所述IP多媒体子***电路域控制功能返回媒体更新成功响应;
(5)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫保持成功响应。
9、一种IP多媒体子***集中业务呼叫恢复实现方法,用以实现本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫恢复,其特征在于,包括如下步骤:
(a)所述本地IP多媒体子***集中业务用户设备向IP多媒体子***电路域控制功能发送呼叫恢复请求消息,所述呼叫恢复请求消息中携带有所述本地IP多媒体子***集中业务用户设备所设置的媒体工作方式指示;
(b)所述IP多媒体子***电路域控制功能将相应的媒体工作方式指示分别发送给所述远端用户设备和媒体网关控制功能;
(c)所述远端用户设备根据接收到的媒体工作方式指示,设置本端的媒体工作方式;所述媒体网关控制功能根据接收到的媒体工作方式指示,设置媒体网关的媒体工作方式,完成所述本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫恢复。
10、如权利要求9所述的方法,其特征在于,
步骤(a)中所述媒体工作方式指示,由所述本地IP多媒体子***集中业务用户设备根据当前自身的媒体工作状态而设置。
11、如权利要求10所述的方法,其特征在于,
所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态包括“未激活”状态或“只发送”状态。
12、如权利要求11所述的方法,其特征在于,
步骤(a)中:
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“未激活”状态,则所述媒体工作方式设置为“只接收”状态;
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“只发送”状态,则所述媒体工作方式设置为“发送接收”状态。
13、如权利要求12所述的方法,其特征在于,
如果所述步骤(a)中所述媒体工作方式指示为“只接收”状态,则步骤(b)中所述IP多媒体子***电路域控制功能向所述远端用户设备发送的媒体工作方式指示为“只接收”状态,向所述媒体网关控制功能发送的媒体工作方式指示为“只发送”状态;
如果所述步骤(a)中所述媒体工作方式指示为“发送接收”状态,则步骤(b)中所述IP多媒体子***电路域控制功能向所述远端用户设备和所述媒体网关控制功能发送的媒体工作方式指示为“发送接收”状态。
14、如权利要求9所述的方法,其特征在于,
步骤(b)中所述IP多媒体子***电路域控制功能通过媒体更新或重邀请请求,将所述相应的媒体工作方式分别发送给所述远端用户设备和媒体网关控制功能。
15、如权利要求14所述的方法,其特征在于,
所述IP多媒体子***电路域控制功能采用重邀请请求发送所述媒体工作方式,则步骤(c)之后所述IP多媒体子***电路域控制功能在接收到所述远端用户设备或所述媒体网关控制功能返回的重邀请成功响应后,进一步向所述远端用户设备或所述媒体网关控制功能发送确认消息。
16、如权利要求9所述的方法,其特征在于,进一步包括:
(d)所述远端用户设备和所述媒体网关控制功能向所述IP多媒体子***电路域控制功能返回媒体更新成功响应;
(e)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫恢复成功响应。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA200710108470XA CN101325733A (zh) | 2007-06-14 | 2007-06-14 | Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA200710108470XA CN101325733A (zh) | 2007-06-14 | 2007-06-14 | Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101325733A true CN101325733A (zh) | 2008-12-17 |
Family
ID=40189007
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA200710108470XA Pending CN101325733A (zh) | 2007-06-14 | 2007-06-14 | Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101325733A (zh) |
-
2007
- 2007-06-14 CN CNA200710108470XA patent/CN101325733A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101217788B (zh) | 一种多媒体会话连续性业务的起呼方法 | |
CN101198101B (zh) | Ip多媒体子***集中业务***方会议业务的实现方法 | |
CN101123822B (zh) | Ip多媒体子***集中业务中紧急呼叫业务的实现方法 | |
CN101217702A (zh) | Ip多媒体子***集中业务呼叫保持业务的实现方法 | |
CN101325590B (zh) | 一种ip多媒体子***集中控制业务实现终呼的方法 | |
CN101577889B (zh) | 一种紧急呼叫***及紧急通信受理中心的回呼方法 | |
CN101102612B (zh) | Ip多媒体子***集中业务中紧急呼叫业务的实现方法 | |
CN101102615B (zh) | 一种ip多媒体子***集中控制业务终呼的实现方法 | |
CN101102613B (zh) | 一种ip多媒体子***集中控制业务终呼的实现方法 | |
CN101102610B (zh) | 一种ims集中控制业务中实现用户忙呼叫前转的方法 | |
CN101227728A (zh) | 一种多媒体会话连续性业务的会话合并方法 | |
CN100574348C (zh) | 一种实现用户决定用户忙前转的方法 | |
CN115361362A (zh) | 基于ims的煤矿通话***和方法 | |
CN101448223B (zh) | 电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 | |
CN101217796B (zh) | 一种ip多媒体子***集中控制业务中终呼的实现方法 | |
CN101330640B (zh) | 一种ip多媒体子***集中业务呼叫保持业务的实现方法 | |
CN101217797B (zh) | 一种ip多媒体子***集中控制业务的起呼方法 | |
CN101448222B (zh) | 一种实现ims集中业务被叫转接的方法 | |
CN101217700B (zh) | 一种在ims网络的话务台实现保持的方法 | |
CN101325733A (zh) | Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 | |
CN101115237B (zh) | 在ip多媒体子***集中控制业务中进行呼叫偏转的方法 | |
CN101141693B (zh) | 被叫在电路域接入时网络决定用户忙的发现及处理方法 | |
CN101127957B (zh) | 终端用户实现呼叫前转的方法 | |
CN101330746B (zh) | 一种ims集中控制业务中进行呼叫偏转的方法和*** | |
CN101330745B (zh) | 一种ims集中控制业务中进行呼叫偏转的方法和*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20081217 |