CN1556644A - 一种实现支持多媒体业务的软交换呼叫处理***及方法 - Google Patents
一种实现支持多媒体业务的软交换呼叫处理***及方法 Download PDFInfo
- Publication number
- CN1556644A CN1556644A CNA2003101238907A CN200310123890A CN1556644A CN 1556644 A CN1556644 A CN 1556644A CN A2003101238907 A CNA2003101238907 A CN A2003101238907A CN 200310123890 A CN200310123890 A CN 200310123890A CN 1556644 A CN1556644 A CN 1556644A
- Authority
- CN
- China
- Prior art keywords
- call
- receiving end
- control module
- carrying
- unit
- 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
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种实现支持多媒体业务的软交换呼叫处理***，其设置在软交换实体中，包含：呼叫控制子***和承载控制子***；呼叫控制子***包含：发端呼叫控制模块和收端呼叫控制模块；承载控制子***包含：发端承载控制模块、收端承载控制模块、多种媒体承载通道模块；一种媒体承载通道模块传输一种媒体类型的数据信息。本发明同时公开了一种实现支持多媒体业务的软交换呼叫处理方法，在建立呼叫连接的过程中，先进行媒体类型协商，再根据媒体类型选择相应的承载通道进行业务数据信息传输。本发明适应了分组交换网络中多媒体业务呼叫控制信道与承载通道相互分离的特点，并能对不同承载通道进行单独控制，满足控制多媒体业务的需要。
Description
技术领域
本发明涉及多媒体业务的实现技术，特别涉及一种实现支持多媒体业务的软交换呼叫处理***及方法。
背景技术
IP语音(VoIP)技术作为一种新兴的语音通信技术已显示了越来越重要的地位。尽管VoIP网络的建设目前初具规模，VoIP技术也日臻成熟，但是目前的VoIP网络仅限于提供基本的语音传输服务，还不能以统一的方式实现同时提供语音、图像和数据的多媒体业务，这限制了VoIP技术的发展和推广。能够同时提供语音、图像和数据的多媒体业务已成为未来VoIP发展的一个重要方向。
软交换(Softswitch)作为顺应VoIP发展需要的新型交换技术，主要应用于分组交换网，体现了呼叫处理与承载传输分离的思想，是实现新一代IP语音、多媒体和数据通信的核心技术。
软交换作为VoIP网络中的核心控制实体，它独立于底层承载协议，主要完成呼叫控制、媒体网关接入控制、资源分配、协议处理、路由、认证、计费等主要功能。此外，软交换需要支持多种信令，至少包括ISUP、SIP、H.323和MGCP等协议，还要能够实现这些信令之间的转换。
简单地说，软交换要能够提供类似传统程控交换机的“呼叫控制”功能，但传统程控交换机的“呼叫控制”功能是和“业务控制”结合在一起的，软交换提供的呼叫控制功能是与各种业务控制功能分离的，更能满足在下一代网络(NGN)中为用户快速提供新业务的需要。
作为一项新兴的技术，虽然目前支持基本语音业务的软交换技术正逐渐成熟，但是支持多媒体解决方案的软交换还处于研究起步阶段。这是由于语音业务与多媒体业务在控制方式和业务复杂度方面有很大的不同。一般情况下，语音业务的控制方式比较简单，在呼叫控制过程中，只涉及通话双方、单一承载；而多媒体业务在呼叫控制过程中，同时涉及多方、多承载，在IP网中还具有呼叫控制与媒体承载连接相分离的特点，这使得多媒体业务的控制操作相对于语音业务要复杂的多。因此软交换作为VoIP网络中的核心控制实体，要实现对多媒体业务的支持，就需要提供能够充分表达多媒体业务处理特点的多媒体呼叫处理***。
发明内容
有鉴于此，本发明的一个主要目的在于提供一种实现支持多媒体业务的软交换呼叫处理***，使得VoIP网络能够以统一的方式同时提供语音、图像和数据的多媒体业务。
本发明的另一个主要目的在于提供一种实现支持多媒体业务的软交换呼叫处理方法，使得软交换能够以统一的控制方式同时提供包含语音、图像和数据的多媒体业务。
为达到上述目的一个方面，本发明提供了一种实现支持多媒体业务的软交换呼叫处理***，设置在软交换实体中，其特征在于，该***包含：呼叫控制子***和承载控制子***；
呼叫控制子***根据发端用户的呼叫请求，向收端用户发起呼叫请求，对呼叫的接续过程进行控制，在发端用户与收端用户建立呼叫连接后，启动承载控制子***；
承载控制子***根据呼叫请求进行媒体类型协商，选择相应的媒体承载通道并控制选定的媒体承载通道进行媒体数据信息传输。
其中，所述的呼叫控制子***可以包含：发端呼叫控制模块和收端呼叫控制模块；
发端呼叫控制模块接收发端用户的呼叫请求，进行初步处理，并将该呼叫请求发送给收端呼叫控制模块；
收端呼叫控制模块向收端用户发送呼叫请求，并将收端用户在不同阶段的接续状态指示返回给发端呼叫控制模块。
所述的发端呼叫控制模块可以包含：
发端空闲状态处理单元，其接收发端用户的呼叫请求，并将该呼叫信息转发给发端试呼鉴权单元；
发端试呼鉴权单元，根据发端用户标识和业务轮廓检查发端用户的权限，证实发端用户是否有权和有能力进行此类型的呼叫，并将鉴权检查结果发送给收集并分析信息单元；
收集并分析信息单元，从呼叫请求中收集初始信息包，并根据编号计划判定呼叫类型以及执行地址翻译，确定收端用户地址，将分析结果发送给鉴权呼叫建立单元；
鉴权呼叫建立单元，验证发端用户是否具有发起本次呼叫连接的权利，并将验证结果发送给发送呼叫单元；
发送呼叫单元，将通过鉴权呼叫建立单元验证的发端用户的呼叫请求发送到收端呼叫控制模块；
发端提醒单元，接收收端呼叫控制模块发送的收端用户振铃的接续指示，返回给发端用户，等待收端用户应答接续指示；
发端呼叫建立单元，接收收端呼叫控制模块发送的收端用户应答的接续指示，返回给发端用户，在发端用户和收端用户之间建立稳态的呼叫连接关系，并对后续的呼叫控制过程进行监视。
所述的发端呼叫控制模块可以进一步包含：发端呼叫例外处理单元，其在发端试呼鉴权未通过或收集到无效信息或鉴权呼叫建立失败或呼叫发送失败或收端用户拒绝接续或收端用户无应答或呼叫建立出故障时，终止发端后续呼叫事务，并返回到发端呼叫空闲状态处理单元。
所述的收端呼叫控制模块可以包含：
收端空闲状态处理单元，其接收发端呼叫控制模块的发送呼叫单元转发的发端用户的呼叫请求，并将该呼叫请求转发给收端试呼鉴权单元；
收端试呼鉴权单元，检查收端用户是否有权和有能力进行此类型呼叫，并将检查结果发送给显示呼叫单元；
显示呼叫单元，将通过收端试呼鉴权单元检查的来话呼叫通知给收端用户；
收端提醒单元，提醒收端用户有来话呼叫，并等待收端用户终端应答；
收端呼叫建立单元，将收端用户应答的接续状态发送给呼叫处理***的发端呼叫控制模块，在发端用户和收端用户之间建立稳态的呼叫连接关系，并对后续的呼叫控制过程进行监视。
所述的收端呼叫控制模块可以进一步包含：收端呼叫例外处理单元，其在收端试呼鉴权未通过或呼叫显示故障或收端用户拒绝接续或收端用户无应答或呼叫建立出故障时，结束收端后续呼叫事务，并返回到收端呼叫空闲状态处理单元。
所述的承载控制子***可以包含：发端承载控制模块、收端承载控制模块、一种或一种以上的媒体承载通道模块；一种媒体承载通道模块传输一种媒体类型的数据信息；
呼叫处理***的发端承载控制模块和收端承载控制模块分别接收发端用户和收端用户发送的承载操作请求信息，并将该承载操作信息发送给对端承载控制模块；
呼叫处理***的发端承载控制模块与收端承载控制模块进行协议交互，协商媒体类型，并根据协商好的媒体类型，选择同种类型的媒体承载通道模块；
呼叫处理***的发端承载控制模块与收端承载控制模块分别根据接收的承载操作请求信息，控制相应的媒体承载通道模块对所选择的媒体承载通道进行操作。
所述的承载操作请求信息可以为：协商媒体类型请求信息、媒体数据信息传输请求信息、打开媒体承载通道请求信息、关闭媒体承载通道请求信息或修改媒体承载通道请求信息。
所述的发端承载控制模块可以包含：
发端承载空闲状态处理单元，接收发端用户媒体协商请求或收端承载控制模块转发的收端用户媒体协商请求，将该请求转发给发端资源预视单元；
发端资源预视单元，与收端承载控制模块的收端资源预视单元交互，执行发端用户、收端用户能力集和主从角色及媒体协商，选定媒体承载通道模块；
发端承载协调单元，与收端承载控制模块配合，控制选定的承载通道模块打开、关闭和修改发端用户、收端用户之间的媒体承载通道。
所述的发端承载控制模块可以进一步包含：承载例外处理单元，其在发端用户、收端用户能力集的交换或主从角色协商失败时，终止发端的后续承载事务操作，并返回到发端承载空闲状态处理单元。
所述的收端承载控制模块可以包含：
收端承载空闲状态处理单元，接收收端用户媒体协商请求或发端承载控制模块转发的发端用户媒体协商请求，将该请求转发给收端资源预视单元；
收端资源预视单元，与发端承载控制模块的发端资源预视单元交互，执行发端用户、收端用户能力集的交换和主从角色及媒体协商，选定承载通道模块；
收端承载协调单元，与发端承载协调单元配合，控制选定的承载通道模块打开、关闭和修改发端用户、收端用户终端之间的媒体承载通道；并对承载控制过程进行监视。
所述的收端承载控制模块可以进一步包含：承载例外处理单元，其在发端用户、收端用户能力集的交换或主从角色协商失败时，终止收端的后续承载事务操作，并返回到收端承载空闲状态处理单元。
该呼叫处理***可以包含与发端承载控制模块和收端承载控制模块分别相连的一种或一种以上承载通道模块，所述的承载通道模块可以包含：
承载通道空闲状态处理单元，接收发端承载控制模块或收端承载控制模块发送的打开媒体承载通道的控制信息，并根据控制信息发送给承载通道打开单元；
承载通道打开单元，根据收到的打开媒体承载通道指示信息打开媒体承载通道；
承载通道激活单元，媒体承载通道打开后激活媒体承载通道，***体承载通道在发端用户和收端用户终端之间传输媒体数据信息流；
承载通道修改单元，根据收到的修改媒体承载通道指示信息修改媒体承载通道；
承载通道关闭单元，根据收到的关闭媒体承载通道指示信息关闭媒体承载通道。
所述的承载通道模块可以进一步包含：承载通道例外处理单元，其在承载通道打开或激活或承载通道修改错误或承载通道关闭错误时，终止后续媒体承载通道事务操作，返回到承载通道空闲状态处理单元。
为达到上述目的另一个方面，本发明提供了一种实现支持多媒体业务的软交换呼叫处理方法，在软交换实体中设置所述的呼叫处理***，并在其呼叫控制子***中设置发端呼叫控制模块、收端呼叫控制模块；在其承载控制子***中设置发端承载控制模块、收端承载控制模块，该方法包括以下步骤：
1)呼叫控制子***的发端呼叫控制模块接收发端用户发起的呼叫请求，并发送给收端呼叫控制模块；
2)呼叫控制子***的收端呼叫控制模块向收端用户转发该呼叫请求，并将收端用户后续接续状态返回给发端呼叫控制模块；
3)呼叫控制子***的发端呼叫控制模块将收端用户的接续状态通知发端用户；
4)承载控制子***的发端或收端承载控制子***接收本端用户的媒体类型协商请求，并发送给对端承载控制子***；
5)承载控制子***的发端承载控制模块与收端承载控制模块进行交互，根据该请求进行媒体类型协商，选择相同媒体类型的媒体承载通道；
6)收端用户应答后，承载控制子***的发端承载控制模块与收端承载控制模块配合，共同打开选择的媒体承载通道，控制该媒体类型数据信息传输。
所述步骤1)可以进一步包括：发端呼叫控制模块根据发端用户的呼叫请求，对发端用户是否有权和有能力进行此类型呼叫进行鉴权；
对于通过鉴权的呼叫请求，收集初始信息，根据编号计划判定呼叫类型以及执行地址翻译，确定收端用户地址；
并根据分析结果对发端用户是否有进行本次呼叫的权限进行鉴权；
发端呼叫控制模块只将通过上述两次鉴权的呼叫请求发送给收端呼叫控制模块，将鉴权未通过的呼叫请求丢弃。
所述步骤2)可以进一步包括：收端呼叫控制模块对收端用户是否有权和有能力进行此类型呼叫进行鉴权，只将通过鉴权的呼叫请求发送给收端用户，将鉴权未通过的呼叫请求丢弃。
所述步骤4)可以为：在发端用户与收端用户建立连接时，发端承载控制模块接收发端用户的媒体类型协商请求，并发送给收端承载控制模块，启动承载控制过程；或收端承载控制模块接收收端用户的媒体类型协商请求，并发送给发端承载控制模块，启动承载控制过程。
该方法可以进一步包括：对呼叫处理过程进行监视，在出现异常情况时结束呼叫流程。
由本发明的技术方案可见，本发明的这种支持多媒体业务的软交换呼叫处理***及方法，将呼叫处理***设置为呼叫控制子***和承载控制子***；在呼叫处理过程中，由呼叫控制子***发起和建立呼叫，在建立媒体承载连接的过程中，先进行媒体类型协商，再根据媒体类型选择相应的承载通道并控制其传输业务数据信息。本发明能够很好地适应分组交换网络中呼叫控制与承载传输相互分离的特点，并能够对不同媒体承载通道进行单独控制，因此本发明的软交换呼叫处理***及方法，不仅支持现有的PSTN和VoIP基本语音业务，而且也支持VoIP网上的多媒体业务。
附图说明
图1为本发明一个较佳实施例的软交换呼叫处理***结构示意图；
图2为图1所示实施例中发端呼叫控制模块101内部结构示意图；
图3为图1所示实施例中收端呼叫控制模块102内部结构示意图；
图4a为图1所示实施例中发端承载控制模块111内部结构示意图；
图4b为图1所示实施例中发端承载控制模块112内部结构示意图；
图5为图1所示实施例中承载通道模块113内部结构示意图；
图6a为主、被叫用户属于同一个软交换实体控制域的示意图；
图6b为主、被叫用户属于不同软交换实体控制域的示意图；
图7为图6a所示的情况下的呼叫处理过程示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明进一步详细说明。
本发明的这种支持多媒体业务的软交换呼叫处理***及方法，根据呼叫控制与承载传输分离的思想，将呼叫处理***设置为呼叫控制子***和承载控制子***；在处理多媒体呼叫时，由呼叫控制子***控制呼叫信令通道的接续过程，由承载控制子******体传输通道的连接过程；在建立媒体承载连接的过程中，先进行媒体类型协商，再根据媒体类型选择相应的媒体承载通道进行媒体流的传输。
参见图1，图1为本发明一个较佳实施例的软交换呼叫处理***结构示意图。该呼叫处理***包含：呼叫控制子***100，包含发端呼叫控制模块101和收端呼叫控制模块102；承载控制子***110，包含发端承载控制模块111、收端承载控制模块112以及媒体承载通道模块113，本实施例的媒体承载通道模块113包含了三种基本类型：语音承载通道模块114、图像承载通道模块115和数据承载通道模块116；每种承载通道模块传输相应媒体类型的数据信息。本实施例的媒体承载通道模块113可以在这三种基本承载通道模块类型的基础上进一步定义粒度更小的媒体承载通道模块类型，如语音承载通道模块114可以进一步根据不同的语音压缩编码格式划分成G.711语音承载通道模块、G.729语音承载通道模块、G.723.1媒体承载通道模块等。
其中，发端呼叫控制模块101接收发端用户的呼叫请求，并将该呼叫请求发送给收端呼叫控制模块102；收端呼叫控制模块102向收端用户发送接续呼叫请求，并将收端用户的接续状态信息返回给发端呼叫控制模块101；发端呼叫控制模块101将收端用户的接续状态返回给发端用户。
发端承载控制模块111与收端承载控制模块112分别接收发端用户和收端用户发送的媒体类型协商请求，进行协议交互确定媒体类型，并根据确定的媒体类型，选择同种类型的媒体承载通道模块113，例如本实施例发送的是语音数据信息，则选择语音承载通道模块114。
发端承载控制模块111与收端承载控制模块112控制选择的媒体承载通道模块113打开相应的媒体承载通道，在发端用户终端和收端用户终端之间传输相应的媒体流数据信息。
本实施例中的发端呼叫控制模块101的结构参见图2，图2为图1所示实施例中发端呼叫控制模块101内部结构示意图。该发端呼叫控制模块101包含：发端空闲状态处理单元201、发端试呼鉴权单元202、收集并分析信息单元203、鉴权呼叫建立单元204、发送呼叫单元205、发端提醒单元206、发端呼叫建立单元207和发端呼叫例外处理单元208。
发端空闲状态处理单元201，接收发端用户的呼叫发起请求，并将该呼叫请求转发给发端试呼鉴权单元202。
发端试呼鉴权单元202根据发端用户标识和业务轮廓检查发端用户的权限，证实发端用户是否有权和有能力进行此类型的呼叫，并将鉴权检查结果发送给收集并分析信息单元203。
收集并分析信息单元203，从发端用户呼叫请求中收集初始信息包，并根据编号计划判定呼叫类型以及执行地址翻译，确定收端用户地址，将分析结果发送给鉴权呼叫建立单元204。
鉴权呼叫建立单元204，验证发端用户是否具有发起本次呼叫连接的权利，并将验证结果发送给发送呼叫单元205。
发送呼叫单元205，将通过鉴权呼叫建立单元验证的发端用户的呼叫请求发送到收端呼叫控制模块102，等待收端呼叫控制模块102返回的收端用户振铃的接续状态指示信息，并在接收到该指示信息后发送给发端提醒单元206。
发端提醒单元206，发送收端用户振铃指示信息给发端用户，等待收端呼叫控制模块102发送的收端用户应答指示信息，并在接收到该指示信息后发送给发端呼叫建立单元207；
发端呼叫建立单元207，发送收端用户应答指示信息给发端用户，并通过收端呼叫控制模块102的配合，在发端用户和收端用户之间建立问题的呼叫控制关系。
发端呼叫例外处理单元208，在发端试呼鉴权未通过或收集到无效信息或鉴权呼叫建立失败或呼叫发送失败或收端用户拒绝接续或收端用户无应答或呼叫建立出故障时，返回到发端呼叫空闲状态处理单元201。
在上述单元运行过程中，如果发端用户放弃呼叫或切断呼叫，则也返回到发端呼叫空闲状态处理单元201。
本实施例中的收端呼叫控制模块102的结构参见图3，图3为图1所示实施例中收端呼叫控制模块102内部结构示意图。该收端呼叫控制模块102包含：收端空闲状态处理单元301、收端试呼鉴权单元302、显示呼叫单元303、收端提醒单元304、收端呼叫建立单元305和收端呼叫例外处理单元306。
其中，收端空闲状态处理单元301，接收发端空闲状态处理单元201转发的发端用户的呼叫请求，并将该呼叫请求转发给收端试呼鉴权单元302。
收端试呼鉴权单元302，检查收端用户是否有权和有能力进行此类型呼叫，并将检查结果发送给显示呼叫单元303。
显示呼叫单元303，将通过收端试呼鉴权单元302检查的来话呼叫根据收端用户地址等信息通知给收端用户。
收端提醒单元304，提醒收端用户有来话呼叫，等待收端用户终端应答信息，并将收端用户振铃的接续状态指示信息发送给发端呼叫控制模块101的发送呼叫单元205。
收端呼叫建立单元305，将收端用户应答指示返回给发端呼叫控制模块101的发端提醒单元206，并通过发端呼叫控制模块102的配合，在发端用户和收端用户之间建立稳态的呼叫控制关系。
收端呼叫例外处理单元306，在收端试呼鉴权未通过或呼叫显示故障或收端用户拒绝接续或收端用户无应答或呼叫建立出故障时，返回到收端呼叫空闲状态处理单元301。
本实施例中的发端承载控制模块111的结构参见图4a，图4a为图1所示实施例中发端承载控制模块111内部结构示意图。该发端承载控制模块111包含：发端承载空闲状态处理单元401，发端资源预视单元402、发端承载协调单元403和承载例外处理单元404。
发端承载空闲状态处理单元401，在发端呼叫控制模块运行发端提醒单元206或者发端呼叫建立单元207时，接收发端用户媒体协商请求和收端承载控制模块112发送的收端用户媒体协商请求，转发给发端资源预视单元402。
发端资源预视单元402，与收端承载控制模块112的收端资源预视单元412交互，执行发端用户、收端用户能力集的交换和主从角色及媒体协商，选定特定类型的媒体承载通道模块113；
发端承载协调单元403，与收端承载协调单元413配合，控制选定的媒体承载通道模块113打开、关闭和修改发端用户、收端用户之间的媒体承载通道；并监视发端对该媒体承载通道的后续操作过程。
承载例外处理单元404，其在发端用户、收端用户能力集的交换或主从角色协商失败时，返回到发端承载空闲状态处理单元401。
本实施例中发端承载控制模块111和收端承载控制模块112的结构基本相同，收端承载控制模块112的结构参见图4b，图4b为图1所示实施例中收端承载控制模块112内部结构示意图。该收端承载控制模块112包含：收端承载空闲状态处理单元411、收端资源预视单元412、收端承载协调单元413和承载例外处理单元414。
收端承载空闲状态处理单元411，在收端呼叫控制模块运行收端提醒单元304或者收端呼叫建立单元305时，接收被叫媒体协商请求和发端承载控制模块111发送的主叫媒体协商请求，转发给收端资源预视单元412。
收端资源预视单元412，与发端承载控制模块111的发端资源预视单元402交互，执行发端用户、收端用户能力集的交换和主从角色及媒体协商，选定与发端相同类型的承载通道模块113。
收端承载协调单元413，与发端承载协调单元403配合，控制选定的承载通道模块113打开、关闭和修改发端用户、收端用户之间的媒体承载通道；并监视收端对该媒体承载通道的后续操作过程。
承载例外处理单元414，其在发端用户、收端用户能力集的交换或主从角色协商失败时，返回到收端承载空闲状态处理单元411。
另外本实施例的发端承载控制模块111和收端承载控制模块112在关闭或切断呼叫时都返回到收端承载空闲状态处理单元411。
本实施例中的媒体承载通道模块113的结构参见图5，图5为图1所示实施例中媒体承载通道模块113内部结构示意图。本实施例中的语音承载通道模块114、图像承载通道模块115和数据承载通道模块116虽然所控制的媒体承载通道类型不同，但这些承载通道模块本身的结构是相同的，都包含：承载通道空闲状态处理单元501、承载通道打开单元502、承载通道激活单元503、承载通道修改单元504、承载通道关闭单元505和承载通道例外处理单元506。
承载通道空闲状态处理单元501，接收发端承载控制模块111或收端承载控制模块112发送的打开承载通道的控制信息，转发给承载通道打开单元502。
承载通道打开单元502，根据发端承载控制模块111或收端承载控制模块112发送的控制信息打开承载通道，并在承载通道打开后转入承载通道激活单元503。
承载通道激活单元503，激活打开的媒体承载通道，控制发端用户、收端用户之间的媒体流传输过程，在收到发端承载控制模块111或收端承载控制模块112发送的关闭和修改承载通道的控制信息后，转发给承载通道关闭单元505或承载通道修改单元504。
承载通道修改单元504，根据发端承载控制模块111或收端承载控制模块112发送的控制信息修改承载通道，并在承载通道修改完毕后再次转入承载通道激活单元503。
承载通道关闭单元505，根据发端承载控制模块111或收端承载控制模块112发送的控制信息关闭承载通道，并在承载通道关闭后转入承载通道空闲状态处理单元501。
承载通道例外处理单元506，在承载通道打开错误或承载通道激活错误或承载通道修改错误或承载通道关闭错误时，处理后续操作，并返回到承载通道空闲状态处理单元501。
在实际应用时，对于同一个媒体承载通道需要设置两个相同的承载通道模块113，分别与发端承载控制模块111、收端承载控制模块112相连，它们相互配合，共同完成对媒体承载通道的控制功能。
本发明的呼叫处理***设置在软交换实体中。实际应用中，主叫用户和被叫用户可能属于同一个软交换控制，也可能属于不同的软交换控制。参见图6a，图6a为主、被叫用户属于同一个软交换控制情况的示意图。其中主叫用户601与软交换602中的发端呼叫控制模块101和发端承载控制模块111进行信息交互；被叫用户603与软交换602中的收端呼叫控制模块102和收端承载控制模块112进行信息交互。
参见图6b，图6b为主、被叫用户属于不同软交换控制情况的示意图。其中主叫用户601与软交换610中的发端呼叫控制模块101和发端承载控制模块111进行信息交互；软交换610中的收端呼叫控制模块102与软交换620中的发端呼叫控制模块101进行信息交互；软交换610中的收端承载控制模块112与软交换620中的发端承载控制模块111进行信息交互；被叫用户603与软交换620中的收端呼叫控制模块102和收端承载控制模块112进行信息交互。
本申请中的“发端用户”、“收端用户”根据软交换实体在呼叫处理过程中的所处的位置，“发端用户”可以代表主叫用户或者代表前一个软交换实体，“收端用户”可以代表被叫用户或者代表下一个软交换实体。
参见图7，图7为主被叫用户使用H.323信令时，图6a所示情况下的多媒体呼叫处理过程示意图。图7示意了在一次成功的多媒体呼叫建立流程中，H.323信令事件与呼叫处理***各个模块之间的处理关系。该过程包括呼叫控制过程和承载控制过程，具体包括以下步骤：
步骤(1)发端呼叫控制模块(O_CCM)的发端空闲状态处理单元(O_NULL)收到主叫用户发起呼叫请求的“Setup”消息之后，发送到发端试呼鉴权单元(Auth Orig.Attempt)。
步骤(2)发端试呼鉴权单元，首先向发端用户发送“Calll Proceeding”消息通知呼叫正在处理过程中，然后根据主叫用户标识和业务轮廓检查发端终端的权限，证实主叫用户是否有权/能力进行本类型呼叫，如果鉴权成功，则将鉴权结果发送到收集并分析信息单元(Collect&Analyse_Information)。
步骤(3)收集并分析信息单元从呼叫请求中收集初始信息包/拨号串，并根据拨号计划分析和翻译信息，确定收端用户地址和呼叫类型，例如本地呼叫，转接呼叫，国际呼叫等，在得到收端用户地址和地址性质后，将分析结果发送到鉴权呼叫建立单元(Auth Call Setup)。
步骤(4)鉴权呼叫建立单元，证实主叫用户是否有进行本次呼叫的权限，当发起此呼叫的权限被证实时，呼叫建立有权事件发生，并转入发送呼叫单元(Send_Call)。
步骤(5)发送呼叫单元，向收端呼叫控制模块(T_CCM)的收端空闲状态处理单元(T_NULL)发送想要建立到被叫用户呼叫的指示。
步骤(6)收端呼叫控制模块的收端空闲状态处理单元(T_NULL)在收到发端呼叫请求指示后，将该请求发送给收端试呼鉴权单元(AuthTerm.Attempt)。
步骤(7)收端试呼鉴权单元，根据被叫用户标识和业务轮廓检查被叫终端的权限，证实呼叫是否有权接续到被叫终端，如果鉴权成功，将鉴权结果发送到显示呼叫单元(Present_Call)。
步骤(8)显示呼叫单元，向被叫用户发送“Setup”消息，将来话呼叫通知给被叫终端，同时等待被叫用户的响应信息。当呼叫显示单元接收到被叫终端发送来的“Alerting”消息后，将该消息发送到收端提醒单元(T_Alerting)，并通知发端呼叫控制模块被叫用户正在振铃。显示呼叫单元可以根据收端用户地址等信息判断出主、被叫用户是否属于不同软交换控制。本实施例是属于同一个软交换控制的情况。如果主、被叫用户属于不同软交换控制，则收端呼叫控制模块向被叫用户所在的软交换中的发端呼叫控制模块转发“Setup”消息，该发端呼叫控制模块向同一软交换中的收端呼叫控制模块转发“Setup”消息，该收端呼叫控制模块将Setup”消息最终发送给被叫用户。
本实施例中，在显示呼叫单元运行时，收端呼叫控制模块可能会在接收到被叫用户发送的“Alerting”之前接收到一个“Call_Proceeding”消息，该消息不会导致收端呼叫控制模块运行其他功能单元。
步骤(9)发端呼叫控制模块在运行发送呼叫单元时，收到收端呼叫控制模块发送的被叫振铃指示之后，向主叫终端发送“Alerting”消息，将振铃事件通知给主叫用户，并运行发端提醒单元(O_Alerting)。
当发端呼叫控制模块和收端呼叫控制模块运行发端提醒单元(O_Alerting)和收端提醒单元(T_Alerting)时，发端承载控制模块(O_BCM)和收端承载控制模块(T_BCM)开始并发运行发端和收端承载空闲状态(Bear_null)处理单元，以接收发端和收端之间的承载操作信息。
步骤(10)发端承载控制模块收到主叫用户发送的媒体类型协商消息“TerminalCapabilitySet(TCS)”后，运行发端资源预视单元(Look_Ahead)，向收端承载控制模块发送媒体类型协商指示，并等待被叫用户终端发送的媒体类型协商响应消息“TerminalCapabilitySetAck(TCSA)”。
步骤(11)收端承载控制模块在收到发端承载控制模块发送来的“TCS”指示后，运行收端资源预视单元(Look_Ahead)，同时向被叫用户终端发送媒体协商消息“TerminalCapabilitySet(TCS)”。本实施例是属于同一个软交换控制的情况。如果主、被叫用户属于不同软交换控制，则收端承载控制模块向被叫用户所在的软交换中的发端承载控制模块转发媒体协商消息，该发端承载控制模块向同一软交换中的收端承载控制模块转发媒体协商消息。
步骤(12)收端承载控制模块在运行收端资源预视单元时，接收到被叫用户终端的媒体资源协商回应消息“TCSA”，将之转发给发端承载控制模块，并继续运行收端资源预视单元(Look_Ahead)等待角色协商过程。
步骤(13)发端承载控制模块的资源预视单元收到收端承载控制模块发送来的媒体类型响应指示后，向主叫用户终端发送媒体协商回应消息“TerminalCapabilitySetAck(TCSA)”，并继续运行发端资源预视单元(Look_Ahead)等待角色协商过程。
步骤(14)发端承载控制模块在运行发端资源预视单元时，接收到主叫用户终端发送的角色协商消息“MasterSlaveDetermination(MSD)”，将之转发给收端承载控制模块，并继续运行发端资源预视单元，等待收端承载控制模块的回应消息。
步骤(15)收端承载控制模块收到发端承载控制模块发送来的角色协商指示后，向被叫用户终端发送“MasterSlaveDetermination”消息，并继续运行收端资源预视单元等待被叫用户终端发送的角色协商回应消息“MasterSlaveDetermination ACK(MSDA)”。
步骤(16)收端承载控制模块在运行收端资源预视单元时，接收到被叫用户终端的角色协商回应消息“MasterSlaveDetermination ACK(MSDA)”，将之转发给发端承载控制模块，并转入运行收端承载协调单元(Bear_Coordination)。
步骤(17)发端承载控制模块在运行收端资源预视单元时，接收到收端承载控制模块发送的角色协商回应指示后，向主叫用户终端发送角色协商回应消息“MasterSlaveDeterminationACK(MSDA)”，并转入运行发端承载协调单元(Bear_Coordination)。
步骤(18)收端呼叫控制模块在运行收端提醒单元(T_Alerting)时，接收到被叫用户发送来的“Connect”消息，运行收端呼叫建立单元(T_Setup)，向发端呼叫控制模块发送被叫用户应答指示。
步骤(19)发端呼叫控制模块在运行发端提醒单元(O_Alerting)时，接收到收端呼叫控制模块发送来的被叫应答指示后，运行发端呼叫建立单元(O_Setup)，向主叫用户发送“Connect”消息，。
当发端/收端呼叫控制模块分别运行发端/收端呼叫建立单元(O/T_Setup)”时，主被叫用户终端之间就可以进行打开承载通道的操作了，打开承载通道可以由主叫终端发起也可以由被叫终端发起。
下面假设主叫用户首先发起打开承载通道的消息流程，继续步骤(20)～(23)所示：
步骤(20)发端承载控制模块在运行发端承载协调单元时，收到主叫用户打开承载通道的请求消息“OpenLogicalChannel(OLC)”，运行一个承载通道模块(O_CSM)，并驱动该承载通道模块由承载通道空闲单元(Channel_Null)，转入承载通道打开单元(Channel_Opening)，同时向收端承载控制模块发送打开承载通道请求指示。
步骤(21)收端承载控制模块在运行收端承载协调单元时，收到发端承载控制模块发送的打开承载通道请求指示后，运行一个与发端承载通道模块相同的收端承载通道模块(T_CSM)，并驱动该承载通道模块由承载通道空闲单元(Channel_Null)转入承载通道打开单元(Channel_Opening)，同时向被叫用户终端发送“OpenLogicalChannel(OLC)”消息。
步骤(22)收端承载控制模块在运行收端承载协调单元时，收到被叫用户终端发送的承载通道已打开的回应消息“OpenLogicalChannelAck(OLCA)”后，驱动承载通道模块运行承载通道激活单元(Channel_Active)，并向发端承载控制模块发送该承载通道已打开的通知。
步骤(23)发端承载控制模块在运行发端承载协调单元时，接收到收端承载控制模块发送的承载通道已打开的回应消息后，驱动发端承载通道模块运行承载通道激活单元(Channel_Active)，并向主叫终端发送相应的“OpenLogicalChannelAck(OLCA)消息。
当主、被叫侧代表同一条媒体通道的承载通道模块都运行承载通道激活单元(Channel_Avtive)后，媒体通道被建立成功，主被叫终端之间可以开始传输相应类型的媒体数据。重复步骤(20)～(23)可以打开多条媒体承载通道，从而实现主、被叫用户终端之间的多种媒体(语音、视频和数据)流的传输。
当主、被叫用户之间的通话结束时，呼叫释放可以由主叫用户发起也可以由被叫用户发起。下面假设主叫用户发起释放呼叫的请求，将首先按照(24)～(27)所描述的流程关闭所有的媒体承载通道，并在成功关闭所有的媒体通道之后，按照(28)～(29)所描述的流程结束承载控制过程。
步骤(24)发端承载控制模块在运行发端承载协调单元时，收到主叫用户终端发送的关闭某条媒体承载通道的请求消息“CloseLogicalChannel”，驱动发端代表本条媒体承载通道的承载通道模块运行承载通道关闭单元(Channel_closing)，并向收端承载控制模块发送关闭该媒体承载通道的指示。
步骤(25)收端承载控制模块在运行收端承载协调单元时，接收到发端承载控制模块发来的关闭承载通道指示后，驱动收端代表本条媒体承载通道的承载通道模块运行承载通道关闭单元(Channel_closing)，并向被叫用户终端发送“CloseLogicalChannel”请求消息。
步骤(26)收端承载控制模块在运行收端承载协调单元时，收到被叫用户终端发送的承载通道已关闭的回应消息“CloseLogicalChannelAck(CLCA)”，驱动收端承载通道模块运行承载通道空闲单元(Channel_Null)，并向发端承载控制模块发送该媒体承载通道已关闭的通知。
步骤(27)发端承载控制模块在运行发端承载协调单元时，接收到收端承载控制模块发送的承载通道已关闭的通知，驱动发端承载通道模块运行承载通道空闲单元(Channel_Null)，并向主叫用户终端发送相应的“CloseLogicalChannelAck(CLCA)消息。
步骤(28)发端承载控制模块在运行发端承载协调单元时，接收到主叫端点发送来的结束承载控制会话的消息“EndSessionCommand”，运行发端承载空闲单元(Bear_NULL)，并通知收端承载控制模块请求结束本次承载控制会话；
步骤(29)收端承载控制模块在运行收端承载协调单元时，接收到发端承载控制模块发来的结束承载控制会话的通知，运行收端承载空闲单元(Bear_NULL)，向被叫终端发送“EndCessionCommand”消息，并关闭该承载控制会话，承载控制至此全部结束。
当承载控制会话关闭后，主/被叫将发起呼叫拆除流程，其流程如(30)～(31)所示：
步骤(30)发端呼叫控制模块在运行发端呼叫建立单元(O_Setup)时，接收到主叫用户结束本次呼叫的请求消息“Release Complete”，运行发端空闲状态处理单元(O_NULL)，同时向收端呼叫控制模块发送结束此呼叫的指示。
步骤(31)收端呼叫控制模块在运行收端呼叫建立单元(T_Setup)时，接收到发端呼叫控制模块发送的结束本次呼叫的指示，运行收端空闲状态处理单元(T_NULL)，同时向被叫用户发送结束此呼叫的“Release Complete”消息，至此一次正常的呼叫已经全部结束。
图7所描述的多媒体呼叫处理过程表明，本发明提出的基于分层处理原则的软交换多媒体呼叫处理***适应了多媒体业务的呼叫控制与承载控制分离的需要，为实现多媒体业务控制奠定了基础。
由上述的实施例可见，本发明的这种实现软交换支持多媒体业务的呼叫处理***及方法，能够很好地适应基于IP网络的多媒体业务呼叫控制与承载传输相互分离的特点，并能够对不同承载通道进行单独控制，不仅可以支持基于IP网络的多媒体业务，而且也可以支持现有的PSTN和VoIP基本语音业务。
Claims (19)
1、一种实现支持多媒体业务的软交换呼叫处理***，设置在软交换实体中，其特征在于，该***包含：呼叫控制子***和承载控制子***；
呼叫控制子***根据发端用户的呼叫请求，向收端用户发起呼叫请求，对呼叫的接续过程进行控制，在发端用户与收端用户建立呼叫连接后，启动承载控制子***；
承载控制子***根据呼叫请求进行媒体类型协商，选择相应的媒体承载通道并控制选定的媒体承载通道进行媒体数据信息传输。
2、如权利要求1所述的呼叫处理***，其特征在于，所述的呼叫控制子***包含：发端呼叫控制模块和收端呼叫控制模块；
发端呼叫控制模块接收发端用户的呼叫请求，进行初步处理，并将该呼叫请求发送给收端呼叫控制模块；
收端呼叫控制模块向收端用户发送呼叫请求，并将收端用户在不同阶段的接续状态指示返回给发端呼叫控制模块。
3、如权利要求2所述的呼叫处理***，其特征在于，所述的发端呼叫控制模块包含：
发端空闲状态处理单元，其接收发端用户的呼叫请求，并将该呼叫信息转发给发端试呼鉴权单元；
发端试呼鉴权单元，根据发端用户标识和业务轮廓检查发端用户的权限，证实发端用户是否有权和有能力进行此类型的呼叫，并将鉴权检查结果发送给收集并分析信息单元；
收集并分析信息单元，从呼叫请求中收集初始信息包，并根据编号计划判定呼叫类型以及执行地址翻译，确定收端用户地址，将分析结果发送给鉴权呼叫建立单元；
鉴权呼叫建立单元，验证发端用户是否具有发起本次呼叫连接的权利，并将验证结果发送给发送呼叫单元；
发送呼叫单元，将通过鉴权呼叫建立单元验证的发端用户的呼叫请求发送到收端呼叫控制模块；
发端提醒单元，接收收端呼叫控制模块发送的收端用户振铃的接续指示，返回给发端用户，等待收端用户应答接续指示；
发端呼叫建立单元，接收收端呼叫控制模块发送的收端用户应答的接续指示，返回给发端用户，在发端用户和收端用户之间建立稳态的呼叫连接关系，并对后续的呼叫控制过程进行监视。
4、如权利要求3所述的呼叫处理***，其特征在于，所述的发端呼叫控制模块进一步包含：发端呼叫例外处理单元，其在发端试呼鉴权未通过或收集到无效信息或鉴权呼叫建立失败或呼叫发送失败或收端用户拒绝接续或收端用户无应答或呼叫建立出故障时，终止发端后续呼叫事务，并返回到发端呼叫空闲状态处理单元。
5、如权利要求2所述的呼叫处理***，其特征在于，所述的收端呼叫控制模块包含：
收端空闲状态处理单元，其接收发端呼叫控制模块的发送呼叫单元转发的发端用户的呼叫请求，并将该呼叫请求转发给收端试呼鉴权单元；
收端试呼鉴权单元，检查收端用户是否有权和有能力进行此类型呼叫，并将检查结果发送给显示呼叫单元；
显示呼叫单元，将通过收端试呼鉴权单元检查的来话呼叫通知给收端用户；
收端提醒单元，提醒收端用户有来话呼叫，并等待收端用户终端应答；
收端呼叫建立单元，将收端用户应答的接续状态发送给呼叫处理***的发端呼叫控制模块，在发端用户和收端用户之间建立稳态的呼叫连接关系，并对后续的呼叫控制过程进行监视。
6、如权利要求5所述的呼叫处理***，其特征在于，所述的收端呼叫控制模块进一步包含：收端呼叫例外处理单元，其在收端试呼鉴权未通过或呼叫显示故障或收端用户拒绝接续或收端用户无应答或呼叫建立出故障时，结束收端后续呼叫事务，并返回到收端呼叫空闲状态处理单元。
7、如权利要求1所述的呼叫处理***，其特征在于，所述的承载控制子***包含：发端承载控制模块、收端承载控制模块、一种或一种以上的媒体承载通道模块；一种媒体承载通道模块传输一种媒体类型的数据信息；
呼叫处理***的发端承载控制模块和收端承载控制模块分别接收发端用户和收端用户发送的承载操作请求信息，并将该承载操作信息发送给对端承载控制模块；
呼叫处理***的发端承载控制模块与收端承载控制模块进行协议交互，协商媒体类型，并根据协商好的媒体类型，选择同种类型的媒体承载通道模块；
呼叫处理***的发端承载控制模块与收端承载控制模块分别根据接收的承载操作请求信息，控制相应的媒体承载通道模块对所选择的媒体承载通道进行操作。
8、如权利要求7所述的呼叫处理***，其特征在于，所述的承载操作请求信息为：协商媒体类型请求信息、媒体数据信息传输请求信息、打开媒体承载通道请求信息、关闭媒体承载通道请求信息或修改媒体承载通道请求信息。
9、如权利要求7所述的呼叫处理***，其特征在于，所述的发端承载控制模块包含：
发端承载空闲状态处理单元，接收发端用户媒体协商请求或收端承载控制模块转发的收端用户媒体协商请求，将该请求转发给发端资源预视单元；
发端资源预视单元，与收端承载控制模块的收端资源预视单元交互，执行发端用户、收端用户能力集和主从角色及媒体协商，选定媒体承载通道模块；
发端承载协调单元，与收端承载控制模块配合，控制选定的承载通道模块打开、关闭和修改发端用户、收端用户之间的媒体承载通道。
10、如权利要求9所述的呼叫处理***，其特征在于，所述的发端承载控制模块进一步包含：承载例外处理单元，其在发端用户、收端用户能力集的交换或主从角色协商失败时，终止发端的后续承载事务操作，并返回到发端承载空闲状态处理单元。
11、如权利要求7所述的呼叫处理***，其特征在于，所述的收端承载控制模块包含：
收端承载空闲状态处理单元，接收收端用户媒体协商请求或发端承载控制模块转发的发端用户媒体协商请求，将该请求转发给收端资源预视单元；
收端资源预视单元，与发端承载控制模块的发端资源预视单元交互，执行发端用户、收端用户能力集的交换和主从角色及媒体协商，选定承载通道模块；
收端承载协调单元，与发端承载协调单元配合，控制选定的承载通道模块打开、关闭和修改发端用户、收端用户终端之间的媒体承载通道；并对承载控制过程进行监视。
12、如权利要求11所述的呼叫处理***，其特征在于，所述的收端承载控制模块进一步包含：承载例外处理单元，其在发端用户、收端用户能力集的交换或主从角色协商失败时，终止收端的后续承载事务操作，并返回到收端承载空闲状态处理单元。
13、如权利要求7所述的呼叫处理***，其特征在于，该呼叫处理***包含与发端承载控制模块和收端承载控制模块分别相连的一种或一种以上承载通道模块，所述的承载通道模块包含：
承载通道空闲状态处理单元，接收发端承载控制模块或收端承载控制模块发送的打开媒体承载通道的控制信息，并根据控制信息发送给承载通道打开单元；
承载通道打开单元，根据收到的打开媒体承载通道指示信息打开媒体承载通道；
承载通道激活单元，媒体承载通道打开后激活媒体承载通道，***体承载通道在发端用户和收端用户终端之间传输媒体数据信息流；
承载通道修改单元，根据收到的修改媒体承载通道指示信息修改媒体承载通道；
承载通道关闭单元，根据收到的关闭媒体承载通道指示信息关闭媒体承载通道。
14、如权利要求13所述的呼叫处理***，其特征在于，所述的承载通道模块进一步包含：承载通道例外处理单元，其在承载通道打开或激活或承载通道修改错误或承载通道关闭错误时，终止后续媒体承载通道事务操作，返回到承载通道空闲状态处理单元。
15、一种实现支持多媒体业务的软交换呼叫处理方法，其特征在于，在软交换实体中设置权利要求1所述的呼叫处理***，并在其呼叫控制子***中设置发端呼叫控制模块、收端呼叫控制模块；在其承载控制子***中设置发端承载控制模块、收端承载控制模块，该方法包括以下步骤：
1)呼叫控制子***的发端呼叫控制模块接收发端用户发起的呼叫请求，并发送给收端呼叫控制模块；
2)呼叫控制子***的收端呼叫控制模块向收端用户转发该呼叫请求，并将收端用户后续接续状态返回给发端呼叫控制模块；
3)呼叫控制子***的发端呼叫控制模块将收端用户的接续状态通知发端用户；
4)承载控制子***的发端或收端承载控制子***接收本端用户的媒体类型协商请求，并发送给对端承载控制子***；
5)承载控制子***的发端承载控制模块与收端承载控制模块进行交互，根据该请求进行媒体类型协商，选择相同媒体类型的媒体承载通道；
6)收端用户应答后，承载控制子***的发端承载控制模块与收端承载控制模块配合，共同打开选择的媒体承载通道，控制该媒体类型数据信息传输。
16、如权利要求15所述的呼叫处理方法，其特征在于，所述步骤1)进一步包括：发端呼叫控制模块根据发端用户的呼叫请求，对发端用户是否有权和有能力进行此类型呼叫进行鉴权；
对于通过鉴权的呼叫请求，收集初始信息，根据编号计划判定呼叫类型以及执行地址翻译，确定收端用户地址；
并根据分析结果对发端用户是否有进行本次呼叫的权限进行鉴权；
发端呼叫控制模块只将通过上述两次鉴权的呼叫请求发送给收端呼叫控制模块，将鉴权未通过的呼叫请求丢弃。
17、如权利要求15所述的呼叫处理方法，其特征在于，所述步骤2)进一步包括：收端呼叫控制模块对收端用户是否有权和有能力进行此类型呼叫进行鉴权，只将通过鉴权的呼叫请求发送给收端用户，将鉴权未通过的呼叫请求丢弃。
18、如权利要求15所述的呼叫处理方法，其特征在于，所述步骤4)为：在发端用户与收端用户建立连接时，发端承载控制模块接收发端用户的媒体类型协商请求，并发送给收端承载控制模块，启动承载控制过程；或收端承载控制模块接收收端用户的媒体类型协商请求，并发送给发端承载控制模块，启动承载控制过程。
19、如权利要求15所述的呼叫处理方法，其特征在于，该方法进一步包括：对呼叫处理过程进行监视，在出现异常情况时结束呼叫流程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2003101238907A CN1556644A (zh) | 2003-12-30 | 2003-12-30 | 一种实现支持多媒体业务的软交换呼叫处理***及方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2003101238907A CN1556644A (zh) | 2003-12-30 | 2003-12-30 | 一种实现支持多媒体业务的软交换呼叫处理***及方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN1556644A true CN1556644A (zh) | 2004-12-22 |
Family
ID=34338934
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2003101238907A Pending CN1556644A (zh) | 2003-12-30 | 2003-12-30 | 一种实现支持多媒体业务的软交换呼叫处理***及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN1556644A (zh) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007143896A1 (fr) * | 2006-05-25 | 2007-12-21 | Huawei Technologies Co., Ltd. | Procédé, système et appareil de réalisation d'un service d'appels multimédia |
| WO2009006847A1 (en) * | 2007-07-10 | 2009-01-15 | Huawei Technologies Co., Ltd. | Method, device and system for combination of resource admission control |
| CN100459542C (zh) * | 2005-03-02 | 2009-02-04 | 华为技术有限公司 | 下一代网络环境中实现上网接入的方法 |
| WO2009074103A1 (fr) * | 2007-12-04 | 2009-06-18 | Huawei Technologies Co., Ltd. | Procédé et dispositif pour réaliser la mise en attente |
| CN1822684B (zh) * | 2005-02-16 | 2011-09-28 | 日本电气株式会社 | 移动通信***中的传输载体设置控制***和方法 |
| CN101378539B (zh) * | 2007-08-27 | 2012-01-25 | 华为技术有限公司 | 一种操纵媒体流的方法、***和设备 |
| CN105282089A (zh) * | 2014-05-30 | 2016-01-27 | 中国电信股份有限公司 | 媒体互通的方法和***以及互通媒体网关 |
| CN110366008A (zh) * | 2018-03-26 | 2019-10-22 | 优酷网络技术（北京）有限公司 | 多媒体资源请求识别方法及装置 |
| CN114945213A (zh) * | 2022-05-11 | 2022-08-26 | 中国电信股份有限公司 | 一种多数据通道同步的全息通信***及方法 |
| CN115767484A (zh) * | 2022-11-07 | 2023-03-07 | 中国联合网络通信集团有限公司 | 客服场景下的通话处理方法、装置、服务器、***及介质 |
-
2003
- 2003-12-30 CN CNA2003101238907A patent/CN1556644A/zh active Pending
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1822684B (zh) * | 2005-02-16 | 2011-09-28 | 日本电气株式会社 | 移动通信***中的传输载体设置控制***和方法 |
| CN100459542C (zh) * | 2005-03-02 | 2009-02-04 | 华为技术有限公司 | 下一代网络环境中实现上网接入的方法 |
| WO2007143896A1 (fr) * | 2006-05-25 | 2007-12-21 | Huawei Technologies Co., Ltd. | Procédé, système et appareil de réalisation d'un service d'appels multimédia |
| CN101080097B (zh) * | 2006-05-25 | 2012-01-04 | 华为技术有限公司 | 一种实现多媒体呼叫业务的方法、***及装置 |
| US8832141B2 (en) | 2007-07-10 | 2014-09-09 | Huawei Technologies Co., Ltd. | Method, device and system for combination of resource and admission control |
| WO2009006847A1 (en) * | 2007-07-10 | 2009-01-15 | Huawei Technologies Co., Ltd. | Method, device and system for combination of resource admission control |
| CN101378539B (zh) * | 2007-08-27 | 2012-01-25 | 华为技术有限公司 | 一种操纵媒体流的方法、***和设备 |
| WO2009074103A1 (fr) * | 2007-12-04 | 2009-06-18 | Huawei Technologies Co., Ltd. | Procédé et dispositif pour réaliser la mise en attente |
| CN105282089A (zh) * | 2014-05-30 | 2016-01-27 | 中国电信股份有限公司 | 媒体互通的方法和***以及互通媒体网关 |
| CN110366008A (zh) * | 2018-03-26 | 2019-10-22 | 优酷网络技术（北京）有限公司 | 多媒体资源请求识别方法及装置 |
| CN110366008B (zh) * | 2018-03-26 | 2021-10-08 | 阿里巴巴（中国）有限公司 | 多媒体资源请求识别方法、装置及存储介质 |
| CN114945213A (zh) * | 2022-05-11 | 2022-08-26 | 中国电信股份有限公司 | 一种多数据通道同步的全息通信***及方法 |
| CN115767484A (zh) * | 2022-11-07 | 2023-03-07 | 中国联合网络通信集团有限公司 | 客服场景下的通话处理方法、装置、服务器、***及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1188985C (zh) | 用于经由网际协议的话音网络的拥塞控制*** | |
| CN1921478A (zh) | 基于网际协议的业务信号传输方法 | |
| CN1361994A (zh) | 电信网络中的能力协商 | |
| CN1297124C (zh) | Ip多媒体子***中利用电路交换承载业务的***及方法 | |
| CN1139243C (zh) | 基于因特网的电话设备 | |
| CN1848889A (zh) | 多模服务会话建立和提供方法以及建立和提供*** | |
| CN1795643A (zh) | 通过切换将局域电话***扩展到广域网 | |
| CN1968328A (zh) | 语音通信设备及操作语音通信设备的方法 | |
| CN1455554A (zh) | 网际协议上的话音网络*** | |
| CN101052161A (zh) | 一种实现ims业务互通的方法和*** | |
| CN1870826A (zh) | 一种呼叫释放控制***及其方法 | |
| CN1816213A (zh) | 一种端到端加密语音通信的方法 | |
| CN1917456A (zh) | 移动监控方法及网关设备和监控*** | |
| CN1968318A (zh) | 统一通信业务的通讯方法及统一通信业务***和相关装置 | |
| CN1889603A (zh) | 一种点击拨号业务的实现方法 | |
| CN1665324A (zh) | 架构即按即说通信连结及即按即说客户单元的方法及通信装置 | |
| CN1556644A (zh) | 一种实现支持多媒体业务的软交换呼叫处理***及方法 | |
| CN1816172A (zh) | 在端到端语音通信中实现明话/密话间相互切换的方法 | |
| CN1468490A (zh) | 通话装置适配器及线路连接方法及线路连接程序及记录媒体 | |
| CN1882116A (zh) | 内置视频网关的移动交换中心及实现多媒体互通的方法 | |
| CN1848885A (zh) | 通信***中的呼叫代答方法 | |
| CN101080097A (zh) | 一种实现多媒体呼叫业务的方法、***及装置 | |
| CN1901742A (zh) | 一种信道切换方法 | |
| CN1549541A (zh) | 对媒体网关进行自动测试的方法和装置 | |
| CN1812453A (zh) | 一种留言灯的实现方法及通信*** |
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 |