CN101448223B - 电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 - Google Patents
电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 Download PDFInfo
- Publication number
- CN101448223B CN101448223B CN200810091029XA CN200810091029A CN101448223B CN 101448223 B CN101448223 B CN 101448223B CN 200810091029X A CN200810091029X A CN 200810091029XA CN 200810091029 A CN200810091029 A CN 200810091029A CN 101448223 B CN101448223 B CN 101448223B
- Authority
- CN
- China
- Prior art keywords
- multimedia system
- state
- medium
- user equipment
- remote user
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了CS接入IP多媒体子***的呼叫保持和呼叫恢复实现方法，其呼叫保持实现方法，应用于本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持，包括：(1)所述本地IP多媒体子***集中业务的用户设备向IP多媒体子***电路域控制功能发送呼叫保持请求消息，携带媒体工作方式指示信息；(2)所述IP多媒体子***电路域控制功能将所述媒体工作方式指示信息发送给所述远端用户设备；(3)所述远端用户设备根据接收到的媒体工作方式指示信息，控制本终端的媒体资源迁移到相应的保持状态。采用本发明所述方法，满足CS接入IMS的呼叫保持和呼叫恢复的业务需求。
Description
技术领域
本发明涉及IP(网络互联协议，Internet Protocol，简称IP)多媒体子***(IP Multimedia Core Network Subsystem，简称IMS)，更具体地说，涉及电路域(Circuit Swithched)接入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)
IMS电路域控制功能106(IMS CS Control Function，简称ICCF)
呼叫会话控制功能107(Call Session Control Function，简称CSCF)
UE_101到IMS域共建立3条路径，分别是：会话控制路径、承载控制路径和承载路径。
其中，会话控制路径在UE_101和ICCF_106之间传递会话信息有如下两种方式：
(1)CS会话控制路径：承载于CS域上，采用非结构化补充业务数据(Unstructured Supplementary Service Data，简称USSD)，该路径经过VMSC_102和HSS_103。
(2)CS会话控制路径：承载于PS域上，采用会话初始协议(SessionInitial Protocol，简称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，用户设备A)和用户B的UE(UE-B，用户设备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发送呼叫保持请求，请求消息中媒体工作方式为“只发送”或“未激活”，指示UE-B进入相应的保持状态。
请求消息中媒体工作方式是“只发送”还是“未激活”状态，取决于UE-A的当前状态，如果UE-A当前自身的媒体工作状态为“发送接收”状态，则请求消息中的媒体工作方式为“只发送”；如果UE-A当前自身的媒体工作状态为“只接收”状态，则请求消息中的媒体工作方式为“未激活”。
步骤202，ICCF向UE-B发送更新请求消息，其中包含步骤201中的媒体工作方式。
步骤203，UE-B控制本终端的媒体资源迁移到相应的保持状态，并向ICCF返回成功响应；
步骤204，ICCF向MGCF发送更新请求，请求消息中媒体工作方式为“只接收”或“未激活”，指示MGCF/MGW进入“只发送”或“未激活”的保持状态。
请求消息中媒体工作方式是“只接收”还是“未激活”状态，取决于UE-A的当前状态，如果UE-A当前自身的媒体工作状态为“发送接收”状态，则请求消息中的媒体工作方式为“只接收”；如果UE-A当前自身的媒体工作状态为“只接收”状态，则请求消息中的媒体工作方式为“未激活”。
步骤205，MGCF控制MGW中IMS侧的媒体资源进入相应的状态，并向ICCF返回成功响应。
步骤204～205可以和步骤202～203同时进行，也可以按照先后顺序进行。
根据MGCF的功能要求，MGCF在接收到步骤204的含有“未激活”的更新请求时，还会存在步骤206～207，通过CS域通知UE-A被远端用户保持。
步骤206，MGCF向VMSC发送呼叫保持消息。
步骤207，VMSC向UE-A发送呼叫保持消息。
步骤208，ICCF收到UE-B和MGCF返回的成功响应后，通过会话控制路径向UE-A返回呼叫保持成功响应。
此时，UE-A和UE-B进入呼叫保持状态，MGCF/MGW和UE-A一致，也进入相应的呼叫保持状态，MGW和UE-B之间的媒体流从MGW到UE-B单向状态，或中断状态。
在步骤207中，UE-A收到了从CS域(VMSC)发送过来的保持通知消息，而实际上UE-A是发起呼叫保持方，这样可能会导致UE-A认为是远端发送了保持请求，结果进入了被保持状态，引起混乱。
假设UE-A和UE-C进入正常的保持状态，当UE-A希望恢复与UE-B之间的媒体传输时，与呼叫保持过程类似，参见图3，有以下步骤：
步骤301，UE-A通过会话控制路径向ICCF发送呼叫恢复请求，请求消息中媒体工作方式为“发送接收”或“只接收”，指示UE-B退出相应的保持状态。
请求消息中媒体工作方式是“发送接收”或“只接收”，取决于UE-A的当前状态，如果UE-A当前自身的媒体工作状态为“未激活”状态，则请求消息中的媒体工作方式为“只接收”；如果UE-A当前自身的媒体工作状态为“只发送”状态，则请求消息中的媒体工作方式为“发送接收”。
步骤302，ICCF向UE-B发送更新请求消息，其中包含步骤301中的媒体工作方式。
步骤303，UE-B控制本终端的媒体资源迁移到相应的恢复状态，并向ICCF返回成功响应；
步骤304，ICCF向MGCF发送更新请求，请求消息中媒体工作方式为“接收发送”或“只发送”，指示MGCF/MGW进入恢复状态。
请求消息中媒体工作方式是“发送接收”还是“只发送”状态，取决于UE-A的当前状态，如果UE-A当前自身的媒体工作状态为“只发送”状态，则请求消息中的媒体工作方式为“发送接收”；如果UE-A当前自身的媒体工作状态为“未激活”状态，则请求消息中的媒体工作方式为“只发送”。
步骤305，MGCF控制MGW中IMS侧的媒体资源进入相应的状态，并向ICCF，并返回成功响应。
步骤304～305可以和步骤302～303同时进行，也可以按照先后顺序进行。
根据MGCF的功能要求，MGCF在接收到步骤304的含有“发送接收”的更新请求时，还存在步骤306～307，通过CS域通知UE-A呼叫恢复。
步骤306，MGCF向VMSC发送呼叫恢复消息。
步骤307，VMSC向UE-A发送呼叫恢复消息。
步骤308，ICCF收到UE-B和MGCF返回的成功响应后，通过会话控制路径向UE-A返回呼叫保持成功响应。
此时，UE-A和UE-B退出相应的呼叫保持状态，MGCF/MGW和UE-A一致，也退出相应的呼叫保持状态。
这时，UE-A是发起呼叫恢复方，结果收到了从CS域(VMSC)发送过来的恢复通知消息，可能会导致UE-A认为是远端解除了呼叫保持，也可能会引起混乱。
综上所述，目前的呼叫保持和呼叫恢复方法无法满足现有的用户设备的呼叫保持和呼叫恢复的业务需求。
发明内容
本发明所解决的技术问题在于提供一种CS接入IMS的呼叫保持的实现方法，以满足CS接入IMS的呼叫保持的业务需求。
为了实现上述问题，本发明提供了一种电路域接入IP多媒体子***的呼叫保持实现方法，应用于本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持，其包括以下步骤：
(1)所述本地IP多媒体子***集中业务的用户设备向IP多媒体子***电路域控制功能发送呼叫保持请求消息，携带媒体工作方式指示信息；
(2)所述IP多媒体子***电路域控制功能将所述媒体工作方式指示信息发送给所述远端用户设备；
(3)所述远端用户设备根据接收到的媒体工作方式指示信息，控制本终端的媒体资源迁移到相应的保持状态。
本发明所述的方法，其中，在上述呼叫保持建立的过程中，所述IP多媒体子***电路域控制功能中的媒体网关控制功能和媒体网关维持原有收发状态。
进一步地，步骤(1)中所述媒体工作方式指示信息由所述用户设备根据当前自身的媒体工作状态而设置：
如果所述用户设备当前自身的媒体工作状态为“发送接收”状态，则所述媒体工作方式设置为“只发送”状态，步骤(3)远端用户设备将本端的媒体工作方式迁移为“只接收”状态；
如果所述用户设备当前自身的媒体工作状态为所述“只接收”状态，则所述媒体工作方式设置为“未激活”状态，步骤(3)远端用户设备将本端的媒体工作方式迁移为“未激活”状态。
进一步地，步骤(2)中，所述IP多媒体子***电路域控制功能通过更新请求或重邀请请求，将所述相应的媒体工作方式指示发送给所述远端用户设备。
进一步地，步骤(3)之后还包括：
(4)所述远端用户设备向所述IP多媒体子***电路域控制功能返回更新成功响应；
(5)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫保持成功响应。
为了实现上述问题，本发明还提供了一种电路域接入IP多媒体子***的呼叫恢复实现方法，应用于本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫恢复，其包括以下步骤：
(a)所述本地IP多媒体子***集中业务用户设备向IP多媒体子***电路域控制功能发送呼叫恢复请求消息，携带媒体工作方式指示；
(b)所述IP多媒体子***电路域控制功能将所述的媒体工作方式指示发送给所述远端用户设备；
(c)所述远端用户设备根据接收到的媒体工作方式指示信息，控制本终端的媒体资源迁移到相应的恢复状态。
本发明所述的方法，其中，在上述呼叫恢复的过程中，所述IP多媒体子***电路域控制功能中的媒体网关控制功能和媒体网关维持原有收发状态。
进一步地，步骤(1)中所述媒体工作方式指示信息由所述用户设备根据当前自身的媒体工作状态而设置：
如果所述用户设备当前自身的媒体工作状态为“只发送”状态，则将所述媒体工作方式设置为“发送接收”状态，步骤(3)所述远端用户设备将本端的媒体工作方式迁移为“发送接收”状态；
如果所述用户设备当前自身的媒体工作状态为“未激活”状态，则将所述媒体工作方式设置为“只接收”，步骤(3)所述远端用户设备将本端的媒体工作方式迁移为“只发送”状态。
进一步地，步骤(b)中所述IP多媒体子***电路域控制功能通过更新请求或重邀请请求，将所述相应的媒体工作方式发送给所述远端用户设备。
进一步地，步骤(c)之后还包括：
(d)所述远端用户设备向所述IP多媒体子***电路域控制功能返回更新成功响应；
(e)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫恢复成功响应。
与现有技术相比较，采用本发明所述方法，ICS用户设备根据当前的媒体工作状态向ICCF发送呼叫保持或呼叫恢复请求，ICCF将所述请求中的媒体工作方式通知远端UE执行相应的媒体控制，而不需要控制MGCF/MGW改变媒体状态，从而实现了IMS集中业务中呼叫保持或呼叫恢复，避免了现有技术中可能引起ICS UE媒体状态混乱的问题，同时简化了控制过程。
附图说明
图1为现有技术中IMS集中业务实施例的架构示意图；
图2为现有技术中ICS呼叫保持实施例流程示意图；
图3为现有技术中ICS呼叫恢复实施例流程示意图；
图4为本发明ICS呼叫保持实施例流程示意图；
图5为本发明ICS呼叫恢复实施例流程示意图。
具体实施方式
本发明在这里提供了一种CS接入IMS的呼叫保持和呼叫恢复实现方法，以解决当ICS UE(UE-A)向远端UE(UE-B)发起呼叫保持或呼叫恢复时，这两个用户设备都进入相应的呼叫保持状态，或退出相应的呼叫保持状态，已经处于所要求的状态，此时没有必要要求媒体经过的MGCF/MGW也一定和UE-A保持一致的状态，即如果MGCF/MGW继续保持发送接收状态，也不会影响保持业务。同时，由于ICCF不需要向MGCF/MGW发送更新请求，因此MGCF不会被触发向VMSC发送呼叫保持或呼叫恢复消息，避免引起ICS UE状态的混乱，同时可以简化了呼叫保持业务的控制过程。以下对具体实施方式进行详细描述，但不作为对本发明的限定。
如图4所示本发明中呼叫保持的流程，包括如下步骤：
步骤401，UE-A通过会话控制路径向ICCF发送呼叫保持请求，请求消息中媒体工作方式为“只发送”或“未激活”，指示UE-B进入“只接收”或“未激活”的保持状态。
请求消息中媒体工作方式是“只发送”还是“未激活”状态，取决于UE-A的当前状态，如果UE-A当前自身的媒体工作状态为“发送接收”状态，则请求消息中的媒体工作方式为“只发送”，UE-B需相应迁移至“只接收”的保持状态；如果UE-A当前自身的媒体工作状态为“只接收”状态，则请求消息中的媒体工作方式为“未激活”，UE-B需相应迁移至“未激活”的保持状态。
步骤402，ICCF向UE-B发送更新请求消息或重邀请请求，其中包含步骤401中的媒体工作方式。
步骤403，UE-B控制本终端的媒体资源迁移到相应的保持状态，并向ICCF返回成功响应；
步骤404，ICCF通过会话控制路径向UE-A返回呼叫保持成功响应。
此时，UE-A和UE-B进入呼叫保持状态。
与图2相比，由于ICCF没有向MGCF/MGW发送控制消息(步骤204)，没有触发图2中的步骤206～207的CS域呼叫保持消息，从而避免了ICS UE可能出现的状态混乱的问题。另外，由于MGCF/MGW一直维持原有收发状态(原有收发状态可以是只发送、只接收、发送接收、未激活等等)，当UE-A和UE-B进入呼叫保持状态，仍然实现了呼叫保持的业务需求。
如图5所示本发明中呼叫恢复的流程，包括如下步骤：
步骤501，UE-A通过会话控制路径向ICCF发送呼叫恢复请求，请求消息中媒体工作方式为“发送接收”或“只接收”，指示UE-B进行呼叫恢复；
请求消息中媒体工作方式是“发送接收”或“只接收”，取决于UE-A的当前状态，如果UE-A当前自身的媒体工作状态为“只发送”状态，则请求消息中的媒体工作方式为“发送接收”，UE-B需相应迁移至“发送接收”状态；如果UE-A当前自身的媒体工作状态为“未激活”状态，则请求消息中的媒体工作方式为“只接收”，UE-B需相应迁移至“只发送”状态。
步骤502，ICCF向UE-B发送更新请求消息或重邀请请求，其中包含步骤501中的媒体工作方式；
步骤503，UE-B控制本终端的媒体资源迁移到相应的恢复状态，并向ICCF返回成功响应；
步骤504，ICCF通过会话控制路径向UE-A返回呼叫恢复成功响应。
此时，UE-A和UE-B退出呼叫保持状态。
与图3相比，由于没有ICCF没有像MGCF/MGW发送控制消息(步骤304)，没有触发图3中描述的步骤306～307的CS域呼叫恢复消息。从而避免了ICS UE可能出现的状态混乱的问题。另外，由于MGCF/MGW一直维持原有收发状态，因此不影响呼叫恢复的业务需求。
采用本发明所述方法，通过ICS UE根据当前的媒体工作状态，向ICCF发送呼叫保持或呼叫恢复请求，并在请求中指示出相应的媒体工作方式，ICCF再将所述的媒体工作方式通知远端UE，且不执行MGCF/MGW的媒体控制，始终保持MGCF/MGW处于发送接收状态，从而达到了满足IMS集中业务中呼叫保持业务的业务需求。
当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员可根据本发明做出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
Claims (8)
1.一种电路域接入IP多媒体子***的呼叫保持实现方法，应用于本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫保持，其特征在于，包括以下步骤：
(1)所述本地IP多媒体子***集中业务的用户设备向IP多媒体子***电路域控制功能发送呼叫保持请求消息，携带媒体工作方式指示信息；
(2)所述IP多媒体子***电路域控制功能将所述媒体工作方式指示信息发送给所述远端用户设备；
(3)所述远端用户设备根据接收到的媒体工作方式指示信息，控制本终端的媒体资源迁移到相应的保持状态；
在上述呼叫保持建立的过程中，所述IP多媒体子***电路域控制功能中的媒体网关控制功能和媒体网关维持原有收发状态。
2.如权利要求1所述的方法，其特征在于，
步骤(1)中所述媒体工作方式指示信息由所述本地IP多媒体子***集中业务用户设备根据当前自身的媒体工作状态而设置：
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为“发送接收”状态，则所述媒体工作方式设置为“只发送”状态，步骤(3)远端用户设备将本端的媒体工作方式迁移为“只接收”状态；
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为所述“只接收”状态，则所述媒体工作方式设置为“未激活”状态，步骤(3)远端用户设备将本端的媒体工作方式迁移为“未激活”状态。
3.如权利要求1或2所述的方法，其特征在于，步骤(2)中，所述IP多媒体子***电路域控制功能通过更新请求或重邀请请求，将所述相应的媒体工作方式指示发送给所述远端用户设备。
4.如权利要求1所述的方法，其特征在于，步骤(3)之后还包括：
(4)所述远端用户设备向所述IP多媒体子***电路域控制功能返回更新成功响应；
(5)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫保持成功响应。
5.一种电路域接入IP多媒体子***的呼叫恢复实现方法，应用于本地IP多媒体子***集中业务用户设备与远端用户设备之间的呼叫恢复，其特征在于，包括以下步骤：
(a)所述本地IP多媒体子***集中业务用户设备向IP多媒体子***电路域控制功能发送呼叫恢复请求消息，携带媒体工作方式指示；
(b)所述IP多媒体子***电路域控制功能将所述的媒体工作方式指示发送给所述远端用户设备；
(c)所述远端用户设备根据接收到的媒体工作方式指示信息，控制本终端的媒体资源迁移到相应的恢复状态；
在上述呼叫恢复的过程中，所述IP多媒体子***电路域控制功能中的媒体网关控制功能和媒体网关维持原有收发状态。
6.如权利要求5所述的方法，其特征在于，
步骤(a)中所述媒体工作方式指示信息由所述本地IP多媒体子***集中业务用户设备根据当前自身的媒体工作状态而设置：
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为“只发送”状态，则将所述媒体工作方式设置为“发送接收”状态，步骤(c)所述远端用户设备将本端的媒体工作方式迁移为“发送接收”状态；
如果所述本地IP多媒体子***集中业务用户设备当前自身的媒体工作状态为“未激活”状态，则将所述媒体工作方式设置为“只接收”，步骤(c)所述远端用户设备将本端的媒体工作方式迁移为“只发送”状态。
7.如权利要求5或6所述的方法，其特征在于，步骤(b)中所述IP多媒体子***电路域控制功能通过更新请求或重邀请请求，将所述相应的媒体工作方式发送给所述远端用户设备。
8.如权利要求5所述的方法，其特征在于，步骤(c)之后还包括：
(d)所述远端用户设备向所述IP多媒体子***电路域控制功能返回更新成功响应；
(e)所述IP多媒体子***电路域控制功能向本地IP多媒体子***集中业务用户设备返回呼叫恢复成功响应。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810091029XA CN101448223B (zh) | 2008-04-10 | 2008-04-10 | 电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200810091029XA CN101448223B (zh) | 2008-04-10 | 2008-04-10 | 电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101448223A CN101448223A (zh) | 2009-06-03 |
| CN101448223B true CN101448223B (zh) | 2011-12-07 |
Family
ID=40743554
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200810091029XA Expired - Fee Related CN101448223B (zh) | 2008-04-10 | 2008-04-10 | 电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101448223B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103179680B (zh) * | 2011-12-23 | 2016-05-25 | ***通信集团北京有限公司 | 一种链路保持方法、***、iad及sbc |
| CN107371147B (zh) * | 2017-06-13 | 2020-04-03 | 努比亚技术有限公司 | 呼叫保持方法及保持、被保持终端、计算机可读存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101087473A (zh) * | 2006-06-19 | 2007-12-12 | 中兴通讯股份有限公司 | 一种传送语音呼叫连续性业务的业务状态的方法 |
| CN101102604A (zh) * | 2007-08-01 | 2008-01-09 | 中兴通讯股份有限公司 | Ip多媒体子***集中控制业务中用户关机前转的方法 |
| CN101106803A (zh) * | 2006-07-13 | 2008-01-16 | 华为技术有限公司 | 在相互独立的网络间切换并保持呼叫连续性的方法及*** |
-
2008
- 2008-04-10 CN CN200810091029XA patent/CN101448223B/zh not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101087473A (zh) * | 2006-06-19 | 2007-12-12 | 中兴通讯股份有限公司 | 一种传送语音呼叫连续性业务的业务状态的方法 |
| CN101106803A (zh) * | 2006-07-13 | 2008-01-16 | 华为技术有限公司 | 在相互独立的网络间切换并保持呼叫连续性的方法及*** |
| CN101102604A (zh) * | 2007-08-01 | 2008-01-09 | 中兴通讯股份有限公司 | Ip多媒体子***集中控制业务中用户关机前转的方法 |
Non-Patent Citations (1)
| Title |
|---|
| 3GPP TSG SSA.IP Multimedia Subsystem (IMS) centralized services(Release 8).《3GPP TR 23.892 V8.0.1》.2008, * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101448223A (zh) | 2009-06-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8289887B2 (en) | Late call forwarding method in IP multimedia core network subsystem centralized service | |
| CN101123822B (zh) | Ip多媒体子***集中业务中紧急呼叫业务的实现方法 | |
| CN101217702A (zh) | Ip多媒体子***集中业务呼叫保持业务的实现方法 | |
| CN101325590B (zh) | 一种ip多媒体子***集中控制业务实现终呼的方法 | |
| CN101132644A (zh) | Ip多媒体子***集中控制业务紧急呼叫实现方法和*** | |
| CN101102612A (zh) | Ip多媒体子***集中业务中紧急呼叫业务的实现方法 | |
| CN101102615B (zh) | 一种ip多媒体子***集中控制业务终呼的实现方法 | |
| CN101102613B (zh) | 一种ip多媒体子***集中控制业务终呼的实现方法 | |
| CN100574348C (zh) | 一种实现用户决定用户忙前转的方法 | |
| CN101102614B (zh) | Ims集中控制业务中实现用户决定用户忙前转的方法 | |
| CN101102610B (zh) | 一种ims集中控制业务中实现用户忙呼叫前转的方法 | |
| CN101448223B (zh) | 电路域接入ip多媒体子***呼叫保持和呼叫恢复实现方法 | |
| CN115361362A (zh) | 基于ims的煤矿通话***和方法 | |
| CN101330640B (zh) | 一种ip多媒体子***集中业务呼叫保持业务的实现方法 | |
| CN101217797B (zh) | 一种ip多媒体子***集中控制业务的起呼方法 | |
| CN101330455B (zh) | Ip多媒体子***集中业务用户不可及前转实现方法 | |
| CN101115237B (zh) | 在ip多媒体子***集中控制业务中进行呼叫偏转的方法 | |
| CN101127957B (zh) | 终端用户实现呼叫前转的方法 | |
| CN101141693B (zh) | 被叫在电路域接入时网络决定用户忙的发现及处理方法 | |
| CN102026108A (zh) | 呼叫等待业务中区别振铃的实现方法及*** | |
| CN101330746B (zh) | 一种ims集中控制业务中进行呼叫偏转的方法和*** | |
| CN101330745B (zh) | 一种ims集中控制业务中进行呼叫偏转的方法和*** | |
| CN101325733A (zh) | Ip多媒体子***集中业务呼叫保持和呼叫恢复实现方法 | |
| CN101325792B (zh) | 一种ip多媒体子***集中业务会话控制路径的切换方法 | |
| CN101137096B (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 | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20171205 Address after: 15 No. 532200 the Guangxi Zhuang Autonomous Region Jiangzhou District of Chongzuo City Stone Forest Avenue Patentee after: Pan Rongqiong Address before: 510640 Guangdong City, Tianhe District Province, No. five, road, public education building, unit 371-1, unit 2401 Patentee before: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Effective date of registration: 20171205 Address after: 510640 Guangdong City, Tianhe District Province, No. five, road, public education building, unit 371-1, unit 2401 Patentee after: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Address before: 518057 Nanshan District high tech Industrial Park, Guangdong, South Road, science and technology, ZTE building, legal department Patentee before: ZTE Corp. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20180328 Address after: 510000 room 3, No. 104, Yuexiu North Road, Yuexiu District, Guangzhou, Guangdong Province, room 3, No. 104 Patentee after: Guangdong Hua Heng Telecom Equipment Co.,Ltd. Address before: 15 No. 532200 the Guangxi Zhuang Autonomous Region Jiangzhou District of Chongzuo City Stone Forest Avenue Patentee before: Pan Rongqiong |
|
| TR01 | Transfer of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20111207 Termination date: 20190410 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |