CN112333343B - 一种语音会议***及其实现方法 - Google Patents

Abstract

本申请提供了一种语音会议***及其实现方法，该方案中用于创建会议室的媒体处理单元有多个，而第一媒体处理单元是根据负载情况从所述多个媒体处理单元中确定的任意一个媒体处理单元，因此可以均衡地分配计算资源、避免单点故障，同时在终端需要进入的会议室并非创建于当前呼叫的第一媒体处理单元中时，可以通过呼叫转移的方式，向正确的第二媒体处理单元发起呼叫请求，确保了终端能够顺利进入创建于任意媒体处理单元的会议室中。

Description

一种语音会议***及其实现方法

技术领域

本申请涉及信息技术领域，尤其涉及一种语音会议***及其实现方法。

背景技术

语音会议***至少包括SBC(Session Border Controller，边界会话控制器)设备和媒体服务器，其中，SBC设备与运营商网络之间可以通过SIP(Session InitiationProTOcol，会话初始协议)等通信协议连接，以获取需要进入语音会议的终端发起的呼叫。而媒体服务器用于提供会议桥的功能，一个媒体服务器可以提供有1个或多个会议桥，每个会议桥可以供1到N方的用户进入，但是有会议桥的参与者之和受限于单个媒体服务器的性能。

语音会议所对应的媒体服务是一种比较消耗CPU计算资源的服务，对于一个常规性能的媒体服务器，一般可以为数百个语音会议的参与者同时提供媒体服务。为了扩展语音会议***的整体容量，使得语音会议***能够为更多的用户提供服务，一种方式是提高单个媒体服务器的性能，另一种方式的增加媒体服务器的数量。实际场景中，出于成本因素的考虑一般会采用后一种方式，例如可以基于云计算平台的构架采用廉价的计算资源，通过动态申请、按需使用的方式，申请云计算平台中的计算节点作为媒体服务器，由此通过廉价的计算资源水平扩展整个语音会议***平台的容量。

但是，在具有多个媒体服务器的环境中，如果想通过媒体服务器提供的IVR(Interactive Voice Response，互动式语音应答)流程后再进入会议室，就会面临一个问题。那就是无法预先知道会议室存在于哪个媒体服务器中，终端的呼叫在进入其中一个媒体服务器，并通过IVR流程输入会议室ID以及密码准备进入会议室时，可能会发现会议室并不存在于当前进入的媒体服务器中，由此会导致进入会议室失败。

目前对于该问题的解决方案是预先分配专门的一个媒体服务器用于创建会议室，即可提前获知会议室存在于哪个媒体服务器中，在获取到终端的呼叫时直接进入到预先分配好的某个媒体服务器中即可。但是，此种解决方案会导致单点故障以及计算资源分配不均等问题。由此可知，现有的方案无法在避免单点故障、确保计算资源分配均衡的情况下，同时确保发起呼叫的终端顺利进入创建于任意一个媒体服务器中的会议室。

发明内容

本申请实施例提供了一种语音会议***及其实现方法，以解决无法在避免单点故障、确保计算资源分配均衡的情况下，同时确保发起呼叫的终端顺利进入创建于任意一个媒体服务器中的会议室的问题。

为实现上述目的，本申请提供了一种语音会议***的实现方法，该方法应用于包括呼叫处理单元、会议管理单元和多个媒体处理单元的语音会议***，所述方法包括：

所述呼叫处理单元根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求，所述第一媒体处理单元为根据负载情况从所述多个媒体处理单元中确定的一个媒体处理单元；

所述第一媒体处理单元根据第二呼叫请求向会议管理单元发送关于会议室的查询信息；

所述会议管理单元根据所述查询信息确定查询结果，并在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，所述第二媒体处理单元为所述多个媒体处理单元中除第一媒体处理单元之外的一个媒体处理单元；

所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求；

所述第二媒体处理单元基于第三呼叫请求控制所述终端进入会议室。

进一步地，该方法还包括：

在所述查询结果为会议室未创建时，所述第一媒体处理单元在本地创建会议室后控制所述终端进入会议室。

进一步地，该方法还包括：

在所述查询结果为会议室已创建、且存在于所述第一媒体处理单元中时，所述第一媒体处理单元控制所述终端进入会议室。

进一步地，所述呼叫处理单元包括边界处理单元和代理处理单元；

所述呼叫处理单元根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求，包括：

所述边界处理单元获取终端发起的第一呼叫请求，并采用B2BUA机制，基于所述第一呼叫请求向代理处理单元发起一个新的第二呼叫请求；

所述代理处理单元将第二呼叫请求转发至第一媒体处理单元。

进一步地，所述代理处理单元将第二呼叫请求转发至第一媒体处理单元之前，还包括：

所述代理处理单元根据多个媒体处理单元的负载情况，从多个媒体处理单元中确定第一媒体处理单元。

进一步地，所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求，包括：

所述代理处理单元将来自所述第一媒体处理单元的呼叫转移请求转发至所述边界处理单元；

所述边界处理单元采用B2BUA机制，基于所述呼叫转移请求向第二媒体处理单元发起一个新的第三呼叫请求。

进一步地，所述第一媒体处理单元根据第二呼叫请求向会议管理单元发送关于会议室的查询信息，包括：

所述第一媒体处理单元在获取到第二呼叫请求后，通过互动式语音应答服务获取所述终端的会议接入信息；

所述第一媒体处理单元根据所述终端的会议接入信息向会议管理单元发送关于会议室的查询信息。

进一步地，会议管理单元控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，包括：

会议管理单元通过调用第一媒体处理单元的事件接口控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，其中，所述呼叫转移请求的消息头中包括第二媒体处理单元的地址；

所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求，包括：

所述呼叫处理单元根据所述呼叫转移请求的消息头中包括的第二媒体处理单元的地址，向第二媒体处理单元发送第三呼叫请求。

基于本申请的另一方面，还提供了一种语音会议***，该***包括呼叫处理单元、会议管理单元和多个媒体处理单元；

所述呼叫处理单元，用于根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求；以及根据来自第一媒体处理单元的呼叫转移请求向第二媒体处理单元发送第三呼叫请求，其中，所述第一媒体处理单元和第二媒体处理单元均为多个媒体处理单元中的一个；

所述第一媒体处理单元，用于根据第二呼叫请求向会议管理单元发送关于会议室的查询信息，并向所述呼叫处理单元发送呼叫转移请求；

所述会议管理单元，用于根据所述查询信息确定查询结果，并在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求；

所述第二媒体处理单元，用于基于第三呼叫请求控制所述终端进入会议室。

进一步地，所述呼叫处理单元包括边界处理单元和代理处理单元；

所述边界处理单元，用于获取终端发起的第一呼叫请求，并采用B2BUA机制，基于所述第一呼叫请求向代理处理单元发起一个新的第二呼叫请求；以及获取所述代理处理单元转发的、来自所述第一媒体处理单元的呼叫转移请求，并采用B2BUA机制，基于所述呼叫转移请求向第二媒体处理单元发起一个新的第三呼叫请求；

所述代理处理单元，用于根据多个媒体处理单元的负载情况，从多个媒体处理单元中确定第一媒体处理单元，并将第二呼叫请求转发至第一媒体处理单元；以及将来自所述第一媒体处理单元的呼叫转移请求转发至所述边界处理单元。

本申请还提供了另一种语音会议***，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述语音会议***的实现方法。

此外，本申请还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述语音会议***的实现方法。

相较于现有技术，本申请实施例提供的语音会议***的实现方案中，由呼叫处理单元根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求，第一媒体处理单元根据第二呼叫请求向会议管理单元发送关于会议室的查询信息，会议管理单元根据所述查询信息确定查询结果，并在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，所述呼叫处理单元可以根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求，使得第二媒体处理单元基于第三呼叫请求控制所述终端进入会议室。由于用于创建会议室的媒体处理单元有多个，而第一媒体处理单元是根据负载情况从所述多个媒体处理单元中确定的任意一个媒体处理单元，因此可以均衡地分配计算资源、避免单点故障，同时在终端需要进入的会议室并非创建于当前呼叫的第一媒体处理单元中时，可以通过呼叫转移的方式，向正确的第二媒体处理单元发起呼叫请求，确保了终端能够顺利进入创建于任意媒体处理单元的会议室中。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的语音会议***的实现方法的处理流程图；

图2为一种采用本申请实施例方案的语音会议***在实现语音会议管理过程中的交互原理；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请的一些实施例提供的语音会议***的实现方法中，由于用于创建会议室的媒体处理单元有多个，而第一媒体处理单元是根据负载情况从所述多个媒体处理单元中确定的任意一个媒体处理单元，因此可以均衡地分配计算资源、避免单点故障，同时在终端需要进入的会议室并非创建于当前呼叫的第一媒体处理单元中时，也可以通过呼叫转移的方式，向正确的第二媒体处理单元发起呼叫请求，确保了终端能够顺利进入创建于任意媒体处理单元的会议室中。

本申请实施例提供的语音会议***的实现方法可以应用于至少包括呼叫处理单元、会议管理单元和多个媒体处理单元的语音会议***，其中，所述语音会议***中的各个功能单元的具体实现可以包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的虚拟计算机，云计算平台中可以创建具有一定计算资源(如CPU、内存等)的虚拟机，以作为实现呼叫处理单元、会议管理单元或媒体处理单元等功能单元的相关处理功能的服务器。

图1示出了本申请实施例提供的语音会议***的实现方法的处理流程，至少包括了以下的处理步骤：

步骤S101，所述呼叫处理单元根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求。

其中，所述呼叫处理单元与运营商网络之间可以通过合适的通信协议连接，例如本申请实施例中可以采用SIP协议。需要参与语音会议的用户可以通过终端经由运营商网络向语音会议***发起第一呼叫请求，而呼叫处理单元获取到该第一呼叫请求之后，可以向其中第一媒体处理单元发起相应的第二呼叫请求。

所述第一媒体处理单元是根据负载情况从所述多个媒体处理单元中确定的一个媒体处理单元，例如可以选择负载最低的其中一个媒体处理单元作为第一媒体处理单元，或者也可以根据负载情况选取其中负载小于某一阈值的几个媒体处理单元，然后从这几个媒体处理单元中随机选取其中之一作为第一媒体处理单元等。在此，本领域技术人员应当理解，本申请实施例中根据负载情况确定第一媒体处理单元的具体方式仅为举例，现有或今后出现的基于类似原理的其它形式如果能够适用于本申请，也应该包含在本申请的保护范围内，并以引用的形式包含于此，原则上选取负载相对较低的媒体处理单元，以确保实现负载均衡即可。

在本申请的一些实施例中，所述呼叫处理单元可以包括边界处理单元和代理处理单元。其中，所述边界处理单元用于实现SBC(Session Border Controller，边界会话控制器)的相关功能，与运营商网络之间采用SIP协议进行交互，可以提供一个B2BUA(Back-TO-Back User Agent，背靠背用户代理)的功能，作为SIP呼叫两端的用户代理，即在来自运营商网络的第一呼叫请求进入语音会议***后，作为服务端获取该第一呼叫请求，而在语音会议***内部作为客户端重新发起一个新的第二呼叫请求。

而所述代理处理单元提供负载均衡的功能，边界处理单元会向代理处理单元发起的新的第二呼叫请求，此时代理服务单元会根据多个媒体处理单元的实际负载情况，选择其中一个作为第一媒体处理单元，向其转发该第二呼叫请求，从而将呼叫请求平衡的分配到媒体处理单元中，以实现负载均衡。

由此，本申请实施例的方案中，呼叫处理单元在根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求时，可以先由边界处理单元获取终端发起的第一呼叫请求，并采用B2BUA机制，基于所述第一呼叫请求向代理处理单元发起一个新的第二呼叫请求，然后由代理处理单元将第二呼叫请求转发至第一媒体处理单元。

步骤S102，所述第一媒体处理单元根据第二呼叫请求向会议管理单元发送关于会议室的查询信息。

对于任意一个媒体处理单元，均可以提供会议桥功能，可以用于创建一个或多个虚拟的会议室，每个虚拟的会议室可以根据供预设数量的用户加入参与语音会议。若云计算平台中的虚拟机作为媒体服务器来实现本申请实施例中媒体处理单元的功能，单个媒体处理单元中可以用于创建的会议室数量，会受限于虚拟机的CPU数量，即CPU数量越多，该可以创建的会议室的数量也越多。从成本角度出发，一般可以采用4核CPU的虚拟机，并且随着业务数量的增加，可以通过增加作为媒体处理单元的虚拟机数量，以实现水平扩展。

在实际场景中，还可以提供IVR(互动式语音应答)服务，用于在终端进入过程中实现与用户之间的交互，从而收集用户参与语音会议时所需要的基本信息，如主叫号码、会议室号码、进入会议室所需要的密码等。当媒体处理单元基于云计算平台中的计算资源部署时，用于IVR服务的***可以直接利用云计算平台中的计算资源来部署，与会议桥共享计算资源，无需单独部署专用的IVR服务器，节约了专用的IVR***，使得方案实现更加简单。

当第一媒体处理单元提供了IVR服务时，所述第一媒体处理单元可以在获取到第二呼叫请求后，通过互动式语音应答服务获取所述终端的会议接入信息，例如在接收到第二呼叫请求之后，可以通过语音提示的方式要求用户依次输入会议室号码等会议接入信息。然后，第一媒体处理单元根据所述终端的会议接入信息向会议管理单元发送关于会议室的查询信息，例如查询信息中可以包括会议室号码93001，由此向会议管理单元查询号码为93001的会议室的具体情况。

步骤S103，会议管理单元可以根据所述查询信息确定查询结果。

所述会议管理单元用于完成会议的管理，因此可以记录与语音会议相关的必要信息。例如，媒体处理单元在创建会议室之后，可以将会议室号码、密码等信息上报给会议管理单元，由会议管理单元记录。由此会议管理单元可以存储有当前各个会议管理单元中已存在的所有会议室的号码以及密码。会议管理单元在接收到第一媒体处理单元发送的关于会议室的查询信息时，即可根据查询信息在已记录的数据中查找，从而确定查询结果。

对于第一媒体处理单元发送的查询信息，可以至少包括以下几种查询结果：1、查询的会议室已经创建、但是不存在于本地；2、查询的会议室已经创建、并且存在于本地；3、查询的会议室还未创建。

在第1种情况中，所查询的会议室已经由第一媒体处理单元之外的其它媒体处理单元创建。在该场景中，创建了所查询的会议室的其它媒体处理单元可以记为第二媒体处理单元，由此可知所述第二媒体处理单元可以是所述多个媒体处理单元中除第一媒体处理单元之外的一个媒体处理单元。例如，在本申请实施例中，媒体处理单元设定为两个，分别媒体处理单元MS1和MS2，若终端请求进入的会议室为的号码为93001，已经由第二媒体处理单元创建，并由会议管理单元记录相关信息。第一媒体处理单元发送关于该93001的会议室的查询信息后，会议管理单元通过查询记录的相关信息，即可确定查询结果为：查询的会议室已经创建、但是不存在于本地，同时也可以给出呼叫转移请求需要的信息，如第二媒体处理单元的地址等。

此时，可以执行步骤S104，在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，会议管理单元控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求。

在本申请的一些实施例中，会议管理单元可以通过调用第一媒体处理单元的事件接口(EVENT接口)来控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，其中，所述呼叫转移请求的消息头中包括第二媒体处理单元的地址。在实际场景中，所述呼叫转移请求可以是REFER请求，该REFER请求是SIP提供的实现呼叫转移功能的请求，其中消息头中的REFER-TO字段中可以包含会议室号码以及存在该会议室的媒体处理单元的地址(即第二媒体处理单元的地址)。例如，若REFER请求消息头中的REFER-TO字段如下：

REFER-TO:<sip:[email protected]:5060>

其中，93001即为会议室的号码，192.168.60.118是会议室实际存在的第二媒体处理单元的IP地址，5060是端口号。由此可知，REFER-TO字段指明了会议存在的媒体服务器地址以及会议的房间号。所述呼叫处理单元在收到呼叫转移请求，即可执行以下步骤，向已经创建了该会议室的第二媒体处理单元发起正确的呼叫请求，使得终端能够顺利进入会议室，参与语音会议。

步骤S105，所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求。

在本申请的一些实施例中，所述呼叫处理单元可以包括边界处理单元和代理处理单元，因此在发送呼叫转移请求的过程中，也可以由所述代理处理单元将来自所述第一媒体处理单元的呼叫转移请求转发至所述边界处理单元，然后再由边界处理单元采用B2BUA机制，基于所述呼叫转移请求向第二媒体处理单元发起一个新的第三呼叫请求。

若未采用B2BUA机制，呼叫转移请求将会被转发会终端，此时就是让终端感知到并处理这个来自于第一媒体处理单元的呼叫转移请求，对于使用终端的用户而言，也将会感知到呼叫转移的这一过程。对于使用终端的用户而言，仅需要获得进入会议室并能够参与语音会议的结果即可，并不需要关心进入的具体过程(无论直接进入还是通过呼叫转移进入)，因此感知到呼叫转移的过程会使得用户获得无用的多余信息，降低用户的使用体验。而本申请实施例的方案中，在边界处理单元中采用了B2BUA机制，因此可以让其处理过程中具备了终端的部分特点，即并不会如常规的呼叫转移是将呼叫转移请求转发回终端，而是由边界处理单元直接处理。由此，来自第一媒体处理单元的呼叫转移请求就不会被终端感知，对于使用终端的用户而言，并不会感知到呼叫转移的过程，这样就可以使得用户体验获得有效提升。

在基于B2BUA机制处理呼叫转移的过程中，边界处理单元可以在其配置文件中配置好相关请求的处理逻辑，当接收到呼叫转移请求后，根据该处理逻辑进行处理。例如，在本申请实施例中，可以在xml格式的配置文件中配置好处理逻辑，该处理逻辑为：接收到REFER请求后返回202响应，以通知发送方已经边界处理单元已经接收到请求，然后向正确的媒体处理单元发起一个新的第三呼叫请求。实际场景中，若采用了SIP协议，边界处理单元可以采用OpenSIPS实现B2BUA功能，并且第三呼叫请求可以是INVITE请求。由于REFER请求中包括了会议室号码以及存在该会议室的第二媒体处理单元的地址，因此可以确保INVITE请求被发送给正确的媒体处理单元。

步骤S106，所述第二媒体处理单元基于第三呼叫请求控制所述终端进入会议室，由此，使用终端的用户即可进入会议室，参与本次语音会议。

在实际场景中，新的第三呼叫请求到达会议室存在的第二媒体处理单元之后，第二媒体处理单元也可以向会议管理单元发起询问，通过发送查询信息的方式确认会议室是否存在于本地，在通过查询结果确认会议室确实存在于本地后，控制所述终端进入会议室。

此外，在会议管理单元的查询结果为第2种时，表示所查询的会议室已经由第一媒体处理单元创建，此时无需在进行呼叫转移，第一媒体处理单元在获知查询结果后，执行步骤S107，直接控制所述终端进入会议室即可。

而在查询结果为第3种时，则表示所查询的会议室目前还没有被创建，可以执行步骤S108，即所述第一媒体处理单元在本地创建会议室后控制所述终端进入会议室。由于在本申请的一些实施例中，代理处理单元是基于负载情况从多个媒体处理单元中选择了负载较低的第一媒体处理单元，相应地在第3种情况下，会议室也会创建于负载较低的第一媒体处理单元，以实现负载均衡的效果。

基于同一发明构思，本申请实施例中还提供了一种语音会议***，所述***对应的方法是前述实施例中的语音会议***的实现方法，并且其解决问题的原理与该方法相似。

本申请实施例提供的一种语音会议***中，可以包括呼叫处理单元、会议管理单元和多个媒体处理单元。呼叫处理单元用于根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求；以及根据来自第一媒体处理单元的呼叫转移请求向第二媒体处理单元发送第三呼叫请求，其中，所述第一媒体处理单元和第二媒体处理单元均为多个媒体处理单元中的一个。

第一媒体处理单元用于根据第二呼叫请求向会议管理单元发送关于会议室的查询信息，并向所述呼叫处理单元发送呼叫转移请求。

会议管理单元，用于根据所述查询信息确定查询结果，并在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求。

第二媒体处理单元，用于基于第三呼叫请求控制所述终端进入会议室。

在本申请的一些实施中，所述呼叫处理单元可以包括边界处理单元和代理处理单元。其中，所述边界处理单元可以用于获取终端发起的第一呼叫请求，并采用B2BUA机制，基于所述第一呼叫请求向代理处理单元发起一个新的第二呼叫请求；以及获取所述代理处理单元转发的、来自所述第一媒体处理单元的呼叫转移请求，并采用B2BUA机制，基于所述呼叫转移请求向第二媒体处理单元发起一个新的第三呼叫请求。而所述代理处理单元可以用于根据多个媒体处理单元的负载情况，从多个媒体处理单元中确定第一媒体处理单元，并将第二呼叫请求转发至第一媒体处理单元；以及将来自所述第一媒体处理单元的呼叫转移请求转发至所述边界处理单元。

图2示出了一种采用本申请方案的语音会议***在实现语音会议管理过程中的交互原理，该语音会议***包括终端、边界处理单元SBC、代理处理单元SIP Proxy、两个媒体处理单元MS1和MS2以及会议管理单元CMS，其交互处理流程包括以下步骤：

步骤S201，终端发起呼叫请求A-leg。

步骤S202，边界处理单元SBC获取到A-leg后基于B2BUA机制进行B2B处理，往代理处理单元发起一个新的呼叫请求b2b-Aleg。

步骤S203，SIP Proxy将呼叫请求b2b-Aleg转发给其中一个媒体处理单元。本实施例中，SIP Proxy具有负载均衡的功能，会根据MS1、MS2的负载情况选择当前负载较小的一个作为本次发送目标，若当前MS1的负载较小，则可以将MS1作为本次转发的目标，即将呼叫请求b2b-Aleg转发给媒体处理单元MS1。

步骤S204，媒体处理单元MS1向会议管理单元CMS发送关于会议室的查询信息。

步骤S205，若查询结果为会议室已经建立，并且不是本地建立的会议室，则CMS控制MS1发起一个呼叫转移请求REFER。REFER的消息头中可以包括建立了会议室的媒体处理单元的信息，本实施例中即为MS2。

在实际场景中，还存在其它可能的查询结果，例如当查询结果为会议室已经建立，并且是本地建立的会议室时，MS1可以直接控制终端进入会议室，而当查询结果为会议室未建立时，可以MS1可以在本地创建会议室后控制终端进入会议室。

步骤S206，SIP Proxy转发REFER给SBC。

步骤S207，SBC在接收到REFER后，根据预先设定的处理逻辑，向正确的媒体处理单元(即MS2)发起新的呼叫请求INVITE。同时，可以结束掉原来指向错误媒体处理单元MS1的请求b2b-Aleg。

步骤S208，MS2接收到INVITE请求后，询问CMS确认会议室已建立，且存在于本地(MS2)后，控制终端用户进入会议室。

此外，本申请实施例还提供了另一种语音会议***，该***包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述的语音会议***的实现方法。

特别地，本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处理单元执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图或框图示出了按照本申请各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (12)

1.一种语音会议***的实现方法，其中，该方法应用于包括呼叫处理单元、会议管理单元和多个媒体处理单元的语音会议***，所述方法包括：

所述呼叫处理单元根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求，所述第一媒体处理单元为根据负载情况从所述多个媒体处理单元中确定的一个媒体处理单元；

所述第一媒体处理单元根据第二呼叫请求向会议管理单元发送关于会议室的查询信息；

所述会议管理单元根据所述查询信息确定查询结果，并在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，所述第二媒体处理单元为所述多个媒体处理单元中除第一媒体处理单元之外的一个媒体处理单元；

所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求；

所述第二媒体处理单元基于第三呼叫请求控制所述终端进入会议室。

2.根据权利要求1所述的方法，其中，该方法还包括：

在所述查询结果为会议室未创建时，所述第一媒体处理单元在本地创建会议室后控制所述终端进入会议室。

3.根据权利要求1所述的方法，其中，该方法还包括：

在所述查询结果为会议室已创建、且存在于所述第一媒体处理单元中时，所述第一媒体处理单元控制所述终端进入会议室。

4.根据权利要求1所述的方法，其中，所述呼叫处理单元包括边界处理单元和代理处理单元；

所述呼叫处理单元根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求，包括：

所述边界处理单元获取终端发起的第一呼叫请求，并采用B2BUA机制，基于所述第一呼叫请求向代理处理单元发起一个新的第二呼叫请求；

所述代理处理单元将第二呼叫请求转发至第一媒体处理单元。

5.根据权利要求4所述的方法，其中，所述代理处理单元将第二呼叫请求转发至第一媒体处理单元之前，还包括：

所述代理处理单元根据多个媒体处理单元的负载情况，从多个媒体处理单元中确定第一媒体处理单元。

6.根据权利要求4所述的方法，其中，所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求，包括：

所述代理处理单元将来自所述第一媒体处理单元的呼叫转移请求转发至所述边界处理单元；

所述边界处理单元采用B2BUA机制，基于所述呼叫转移请求向第二媒体处理单元发起一个新的第三呼叫请求。

7.根据权利要求1所述的方法，其中，所述第一媒体处理单元根据第二呼叫请求向会议管理单元发送关于会议室的查询信息，包括：

所述第一媒体处理单元在获取到第二呼叫请求后，通过互动式语音应答服务获取所述终端的会议接入信息；

所述第一媒体处理单元根据所述终端的会议接入信息向会议管理单元发送关于会议室的查询信息。

8.根据权利要求1所述的方法，其中，会议管理单元控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，包括：

会议管理单元通过调用第一媒体处理单元的事件接口控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求，其中，所述呼叫转移请求的消息头中包括第二媒体处理单元的地址；

所述呼叫处理单元根据呼叫转移请求向第二媒体处理单元发送第三呼叫请求，包括：

所述呼叫处理单元根据所述呼叫转移请求的消息头中包括的第二媒体处理单元的地址，向第二媒体处理单元发送第三呼叫请求。

9.一种语音会议***，其中，该***包括呼叫处理单元、会议管理单元和多个媒体处理单元；

所述呼叫处理单元，用于根据终端发起的第一呼叫请求向第一媒体处理单元发起第二呼叫请求；以及根据来自第一媒体处理单元的呼叫转移请求向第二媒体处理单元发送第三呼叫请求，其中，所述第一媒体处理单元和第二媒体处理单元均为多个媒体处理单元中的一个；

所述第一媒体处理单元，用于根据第二呼叫请求向会议管理单元发送关于会议室的查询信息，并向所述呼叫处理单元发送呼叫转移请求；

所述会议管理单元，用于根据所述查询信息确定查询结果，并在所述查询结果为会议室已创建、且存在于第二媒体处理单元中时，控制所述第一媒体处理单元向所述呼叫处理单元发送呼叫转移请求；

所述第二媒体处理单元，用于基于第三呼叫请求控制所述终端进入会议室。

10.根据权利要求9所述的***，其中，所述呼叫处理单元包括边界处理单元和代理处理单元；

所述边界处理单元，用于获取终端发起的第一呼叫请求，并采用B2BUA机制，基于所述第一呼叫请求向代理处理单元发起一个新的第二呼叫请求；以及获取所述代理处理单元转发的、来自所述第一媒体处理单元的呼叫转移请求，并采用B2BUA机制，基于所述呼叫转移请求向第二媒体处理单元发起一个新的第三呼叫请求；

所述代理处理单元，用于根据多个媒体处理单元的负载情况，从多个媒体处理单元中确定第一媒体处理单元，并将第二呼叫请求转发至第一媒体处理单元；以及将来自所述第一媒体处理单元的呼叫转移请求转发至所述边界处理单元。

11.一种语音会议***，其中，该***包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述***执行权利要求1至8中任一项所述的方法。

12.一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现如权利要求1至8中任一项所述的方法。

Images