音视频会议实现方法、音视频会议系统及相关装置

本申请涉及计算机领域，特别是涉及音视频会议实现方法、音视频会议系统及相关装置。

随着网络技术、通信技术和流媒体技术的迅速发展，以及人们工作、学习的流动性的增加，企业及个人对视频通讯的需求也越来越多，音视频会议系统应运而生。

目前的音视频会议多采用基于选择性转发单元(Selective Forwarding Unit，SFU)的会议架构，由一个服务器和多个终端组成，收到某个终端共享的音视频流后，就直接将该音视频流转发给会议房间内的其他终端。

然而，这种会议架构一旦进入一个会议房间的人数过多，将会大大增加服务器的数据分发压力，因此在这种会议架构下一个会议的参会人数有限，并且能够同时开麦或开视频的人数有限，普通观众要举手发言需要重定向，体验上不够顺滑。

为了解决上述技术问题，本申请提供了一种音视频会议实现方法、音视频会议系统及相关装置，大大降低了媒体源设备例如第二接口机数据分发压力。因此，可以支持更多参会人数，甚至支持百万人参会，同时由于媒体数据流传输时的数据分发压力大大降低，所有参会人员能够同时开麦或开视频，无需重定向，体验顺滑。

本申请实施例公开了如下技术方案：

第一方面，本申请实施例提供一种音视频会议实现方法，所述方法包括：

第一设备组中的回源设备接收所述第一设备组中第一接口机的拉流申请，所述第一设备组为多个设备组中的任一设备组，所述多个设备组中每个设备组中存在回源设备，每个设备组中包括多个接口机，所述多个接口机中每个接口机用于连接用户终端，以使所述用户终端通过接口机接入会议房间；所述第一接口机是所述第一设备组中的任一接口机；

所述第一设备组中的回源设备根据所述拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至所述第一接口机上，以使所述第一接口机将所述媒体数据流转发至对应的用户终端；产生所述媒体数据流的用户终端通过所述第二接口机接入所述会议房间，所述第二设备组为所述多个设备组中的任一设备组。

第二方面，本申请实施例提供一种音视频会议实现装置，所述装置包括接收单元和转发单元：

所述接收单元，用于接收第一设备组中第一接口机的拉流申请，所述第一设备组为多个设备组中的任一设备组，所述多个设备组中每个设备组中存在回源设备，每个设备组中包括多个接口机，所述多个接口机中每个接口机用于连接用户终端，以使所述用户终端通过接口机接入会议房间；所述第一接口机是所述第一设备组中的任一接口机；

所述转发单元，用于根据所述拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至所述第一接口机上，以使所述第一接口机将所述媒体数据流转发至对应的用户终端；产生所述媒体数据流的用户终端通过所述第二接口机接入所述会议房间，所述第二设备组为所述多个设备组中的任一设备组。

第三方面，本申请实施例提供一种音视频会议系统，所述系统包括数据传输网络和房间管理子系统：

所述数据传输网络用于传输会议房间中产生的媒体数据流，所述数据传输网络包括多个设备组，每个设备组中包括多个接口机；

所述多个接口机中每个接口机用于连接用户终端，以使所述用户终端通过接口机接入所述会议房间；

所述多个设备组中每个设备组中存在回源设备，第一设备组中的回源设备用于在接收到所述第一设备组中第一接口机的拉流申请后，根据所述拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至所述第一接口机上，产生所述媒体数据流的用户终端通过所述第二接口机接入所述会议房间，所述第一设备组和所述第二设备组分别为所述多个设备组中的任一设备组；

所述第一接口机是所述第一设备组中的任一接口机，所述第一接口机用于将所述媒体数据流转发至对应的用户终端；

所述房间管理子系统包括所述多个设备组和中心服务器，每个设备组中包括组内服务器，所述组内服务器用于辅助所述中心服务器管理所述会议房间。

第四方面，本申请实施例提供一种用于音视频会议实现的电子设备，所述电子设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行第一方面所述的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行第一方面所述的方法。

由上述技术方案可以看出，本申请涉及多个设备组，每个设备组中包括多个接口机，多个接口机中每个接口机用于连接用户终端，以便用户终端通过接口机接入会议房间。与相关技术中多个用户终端通过一个服务器接入会议房间相比，多个接口机与相关技术中服务器作用类似，而将用户终端分散到不同的接口机，通过多个接口机分担负载，便于接入更多的用户终端，支持大规模会议。多个设备组中每个设备组中存在回源设备，通过第二接口机接入会议房间产生媒体数据流，每个设备组例如第一设备组中的回源设备在接收到第一设备组中第一接口机的拉流申请后，根据拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至第一接口机上，以便第一接口机用于将媒体数据流转发至对应的用户终端。这样，在每个接口机都需要拉取第二接口机的媒体数据流时，仅需要第二接口机与各个设备组中的回源设备进行交互，进而由回源设备为媒体源设备例如第二接口机分担数据分发压力，与其他接口机进行交互，无需第二接口机与每个接口机进行交互，大大降低了设备例如第二接口机的数据分发压力。因此，该音视频会议实现方法可以支持更多参会人数，甚至支持百万人参会，同时由于媒体数据流传输时的数据分发压力大大降低，所有参会人员(即用户)能够同时开麦或开视频，无需重定向，体验顺滑。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术成员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为相关技术提供的一种基于SFU的会议架构图；

图2为相关技术提供的另一种基于SFU的会议架构图；

图3为相关技术提供的一种音视频会议系统的结构图；

图4a为本申请实施例提供的一种音视频会议实现方法的流程图；

图4b为本申请实施例提供的一种数据传输网络的结构图；

图5为本申请实施例提供的一种基于本申请实施例提供的音视频会议系统进行视频会议的界面图；

图6为本申请实施例提供的一种房间管理子系统的结构图；

图7为本申请实施例提供的一种基于混音引擎的音频处理架构图；

图8为本申请实施例提供的一种与第三方会议设备对接的架构图；

图9为本申请实施例提供的又一种音频处理架构图；

图10为本申请实施例提供的一种音视频会议实现装置的结构图；

图11为本申请实施例提供的一种终端的结构图；

图12为本申请实施例提供的一种服务器的结构图。

下面结合附图，对本申请的实施例进行描述。

目前的音视频会议多采用基于SFU的会议架构，参见图1所示，图中黑节点为服务器，灰节点为终端，多个终端与服务器连接，用户A、用户B、用户C分别通过对应的终端接入会议房间参与会议。

然而，这种会议架构一旦进入一个会议房间的人数过多，将会大大增加服务器的数据分发压力，因此在这种会议架构下一个会议的参会人数有限，并且能够同时开麦或开视频的人数有限，普通观众要举手发言需要重定向，体验上不够顺滑。

另外，这种方式参会人员不能同时开视频或开麦，为此，在图1所示的SFU架构基础上增加扩散代理(如图2中虚线框所示)，把不发言的用户放到扩散代理，举手发言时再重定向到通话节点(如图2中实线框所示)，利用扩散代理的分发优势扩大会议参与人数。这种方式却需要重定向，体验不够顺滑。

为了解决上述技术问题，本申请实施例提供一种音视频会议实现方法，该方法在每个接口机都需要拉取第二接口机的媒体数据流时，仅需要第二接口机与各个设备组中的回源设备进行交互，进而由回源设备为第二接口机分担数据分发压力，与其他接口机进行交互，无需第二接口机与每个接口机进行交互，大大降低了媒体源设备例如第二接口机的数据分发压力。因此，该音视频会议实现方法可以支持更多参会人数，甚至支持百万人参会，同时由于媒体数据流传输时的数据分发压力大大降低，所有参会人员能够同时开麦或开视频，无需重定向，体验顺滑。

需要说明的是，本申请实施例提供的音视频会议实现方法可以应用于各种音视频会议场景，尤其是用于单会议百万人参会的超大规模视音频会议。

接下来将对本申请实施例提供的音视频会议系统架构进行介绍。参会人员基于音视频会议系统进入会议房间参与会议时，参会人员主要包括需要开启音视频的嘉宾，以及普通观众，嘉宾开启音视频时会产生媒体数据流，并将媒体数据流传输至普通观众对应的用户终端，以及其他嘉宾对应的用户终端。因此，音视频会议主要在于参会人员开启音视频例如开启视频或开麦时媒体数据流的传输，当媒体数据流的传输不受会议房间中参会人员人数限制时，音视频会议系统将可以支持大规模会议，因此本申请实施例重点在于数据传输网络架构的改进。

另外，因为每个会议都要对应一个会议房间用来保存房间信息、参会列表和维护用户状态(开启或关闭音视频即上下麦、上下视频、静音、进退房等)。在超大规模会议的情况下，所有人都不断开启或关闭视频或进退房，会产生大量体现状态变更的通知消息；超大音视频会议的参会列表的拉取和同步也会对房间管理子系统产生很大压力。因此本申请实施例对房间管理子系统的改进也会使得音视频会议系统可以支持超大规模音视频会议。

因此，在本实施例中音视频会议系统架构可以参见图3所示，主要包括数据传输网络301和房间管理子系统302，数据传输网络301用于传输会议房间中产生的媒体数据流，房间管理子系统302用于对会议房间进行管理。

本申请实施例首先从数据传输网络301传输媒体数据流的角度对音视频会议实现方法进行介绍。参见图4a，所述方法包括：

S401、第一设备组中的回源设备接收所述第一设备组中第一接口机的拉流申请。

数据传输网络301可以参见图4b所示，包括多个设备组401，例如图4b中每个虚线框所示。每个设备组401中包括多个接口机，每个接口机例如图4b中设备组401中的圆圈所表示的节点。多个接口机中每个接口机用于连接用户终端，以便用户终端通过接口机接入会议房间，使得用户终端对应的参会人员可以进入会议房间参与会议。其中，设备组可以用SET表示，即多个接口机按照SET划分，接口机可以是服务器。多个设备组401中每个设备组401中存在回源设备。

其中，第一设备组为多个设备组中的任一设备组，第一接口机是第一设备组中的任一接口机。

当某个设备组(例如第一设备组)中的某个接口机(例如第一接口机)需要拉取媒体数据流时，第一接口机可以向第一设备组中的回源设备发送拉流申请。其中，第一接口机可以是订阅了媒体数据的用户对应的用户终端所连接的接口机。也就是说，第一接口机上的用户订阅了某个接口机的媒体数据，则触发第一接口机向第一设备组中的回源设备发送拉流申请。

S402、第一设备组中的回源设备根据所述拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至所述第一接口机上，以使所述第一接口机将所述媒体数据流转发至对应的用户终端。

第一设备组中的回源设备接收到拉流申请后，将从第二设备组中第二接口机获取的媒体数据流转发至第一接口机上，再由第一接口机将媒体数据流转发至对应的用户终端。其中，产生媒体数据流的用户终端通过第二接口机接入会议房间，第二设备组为多个设备组中的任一设备组。

第二接口机为开启了音视频的用户对应的用户终端所连接的接口机。例如，当某个用户例如第二用户在其用户终端上开启了视频，第二用户对应的用户终端通过第二接口机接入会议，第二接口机位于第二设备组中。若参与会议的任一用户例如第一用户希望观看第二用户的视频(例如订阅了第二用户的视频)时，第一用户对应的用户终端所连接的第一接口机可以到其所在设备组例如第一设备组中的回源设备，并向第一设备组中的回源设备发送拉流申请，以便回源设备根据拉流申请将从第二接口机获取的媒体数据流转发至第一接口机上，第一接口机将媒体数据流转发至对应的用户终端。其中，本申请实施例涉及的用户即参会人员。

需要说明的是，回源设备上的媒体数据流是从第二接口机上拉取的，拉取的媒体数据流可以保存在回源设备本地。也就是说，一般情况下，当回源设备第一次接收到拉取媒体数据流的拉流申请时，由于本地尚未保存该媒体数据流，故需要从第二接口机上拉取；若之前已经有其他接口机申请过，本地便保存了该媒体数据流，则无需再从第二接口机上拉取。

因此，在本实施例中，可以根据第一设备组中的回源设备是否在本地查到媒体数据流而采用不同的媒体数据流拉取方式。

在一种可能的实现方式中，第一设备组中的回源设备根据拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至第一接口机上的具体方式可以是第一设备组中的回源设备接收到第一接口机发送的拉流申请，根据拉流申请查第二接口机的媒体数据流，若未查到第二接口机的媒体数据流，向第二接口机转发该拉流申请，接收第二接口机根据拉流申请转发的媒体数据流，并将媒体数据流转发至第一接口机。

可以理解的是，若拉流申请是在第一用户订阅了第二用户的视频时发送的，则第二接口机接收到拉流申请后，可以在第二接口机的本地记录该回源设备订阅了第二接口机，然后在由第二接口机将媒体数据流发送给回源设备。回源设备也会将接收到的媒体数据流保存至本地，以便后续其他接口机请求该媒体数据流时，回源设备无需再与第二接口机进行交互，可以直接将媒体数据流返回给第一接口机。

例如图4b所示，其中节点A可以作为第二接口机，第二接口机为嘉宾所在接口机，即第二接口机上的用户终端所对应的用户可以开启视频，上行视频数据流，此时视频数据流作为媒体数据流。节点B可以作为第一接口机，节点D可以作为其所在设备组例如第一设备组的回源设备，节点B上的用户订阅了节点A上行的视频数据流，节点B会先在第一设备组内到节点D，向节点D发出拉流申请。节点D收到节点B的拉流申请后，先在本地查有没有节点A的媒体数据流，如果没有，则向节点A发起拉流申请。节点A收到节点D的拉流申请后，在本地记录节点D订阅节点A，然后将视频数据流转发给节点D，节点D收到视频数据流转发给节点B，节点B最终将视频数据流发送至对应的用户终端。

第一设备组中的回源设备根据拉流申请查第二接口机的媒体数据流时，若查到第二接口机的媒体数据流，直接将查到的媒体数据流转发至第一接口机。

例如图4b所示，其中节点A可以作为第二接口机，第二接口机为嘉宾所在接口机，即第二接口机上的用户终端所对应的用户可以开启视频，上行视频数据流，此时视频数据流作为媒体数据流。节点C可以作为第一接口机，节点D可以作为其所在设备组例如第一设备组的回源设备，节点C上的用户订阅了节点A上行的视频数据流，节点C会先在第一设备组内到节点D，向节点D发出拉流申请。注意同一设备组中的节点B和节点C通过一致性哈希或其他方法都到同一个节点D，向节点D发出拉流申请。节点D查到本地已经有这条视频数据流了(之前节点B申请过)，节点D直接将查到的视频数据流向节点C转发，节点C收到来自节点D的转发的视频数据流，最终将视频数据流转发给对应的用户终端。

可以理解的是，第一设备组中的回源设备是需要申请媒体数据流的接口机例如第一接口机按照预设规则确定得到的，该预设规则使得同一媒体数据流通过同一回源设备路由到其所在设备组中的接口机上。例如上述同一设备组中的节点B和节点C通过一致性哈希或其他方法都到同一个节点D。

需要说明的是，第一设备组与第二设备组可以位于同一局域网(即在内网中)，也可以位于不同局域网(即在外网中，包括国内网络和国外网络的外网)。若第一设备组与第二设备组位于同一局域网，则第一设备组中的回源设备直接向第二接口机转发拉流申请，第二接口机直接向回源设备发送媒体数据流。若第一设备组与第二设备组位于不同局域网，数据传输网络301中还包括中转代理设备402，例如图4b中402所示的设备。则第一设备组中的回源设备需要通过中转代理设备402向第二接口机转发拉流申请，相应的，第二接口机通过中转代理设备402将媒体数据流转发至第一设备组中的回源设备。

例如图4b所示，其中节点A可以作为第二接口机，第二接口机为嘉宾所在接口机，即第二接口机上的用户终端所对应的用户可以开启视频，上行视频数据流，此时视频数据流作为媒体数据流。节点G可以作为第一接口机，节点F可以作为其所在设备组例如第一设备组的回源设备，此时节点G所在第一设备组与节点A所在第二设备组不在同一局域网，即节点G为边缘节点。节点G上的用户订阅了节点A上行的视频数据流(该视频数据流作为媒体数据流)，获取视频数据流的路径会相对比较长，节点G会先在第一设备组内到节点F，向节点F发出拉流申请。节点F收到节点G的拉流申请后，先在本地查有没有节点A的视频数据流，如果没有，则通过中转代理设备402(例如图4b中节点E)向节点A发起拉流申请。节点A收到节点F的拉流申请，在本地记录节点F订阅节点A，然后通过节点E将视频数据流转发给节点F，节点F再将视频数据流转发给节点G，节点G最终将视频数据流转发给对应的用户终端。

图4b中节点H拉取节点A的视频数据流的过程与节点C类似，只是中间也要通过节点E，此处不再赘述。在这一过程中，中转代理设备402例如节点E的查，既可以是预先配置的，也可以做动态分配，这里不做限制。

在结构上，本申请实施例将用于接入音视频会议的接口机按设备组(SET)进行划分，在某个设备组中的接口机需要拉取媒体数据流时，可以通过在所在设备组中确定回源设备，进而通过回源设备向产生媒体数据流的接口机(即媒体源设备)发起拉流申请。这种设计大大减少了媒体源设备的数据分发压力，极大提升会议房间中参会人员的人数。举个例子，假设每个SET有100台接口机，整个音视频会议系统有100个SET，每台8核16G的接口机能够支持100路媒体数据流转发，如果一个会议只有一个嘉宾其余都是观众，那么这个会议的最大规模就是100(台)*100(SET)*100(分发)＝100万人。如果嘉宾不止一人，基于就近接入原则，会分配不同SET的不同接口机，上行转发的负载也会分散开，支持百万人的大会很容易。

由上述技术方案可以看出，本申请涉及多个设备组，每个设备组中包括多个接口机，多个接口机中每个接口机用于连接用户终端，以便用户终端通过接口机接入会议房间。与相关技术中多个用户终端通过一个服务器接入会议房间相比，多个接口机与相关技术中服务器作用类似，而将用户终端分散到不同的接口机，通过多个接口机分担负载，便于接入更多的用户终端，支持大规模会议。多个设备组中每个设备组中存在回源设备，通过第二接口机接入会议房间产生媒体数据流，每个设备组例如第一设备组中的回源设备在接收到第一设备组中第一接口机的拉流申请后，根据拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至第一接口机上，以便第一接口机用于将媒体数据流转发至对应的用户终端。这样，在每个接口机都需要拉取第二接口机的媒体数据流时，仅需要第二接口机与各个设备组中的回源设备进行交互，进而由回源设备为媒体源设备例如第二接口机分担数据分发压力，与其他接口机进行交互，无需第二接口机与每个接口机进行交互，大大降低了媒体源设备例如第二接口机的数据分发压力。因此，该音视频会议实现方法可以支持更多参会人数，甚至支持百万人参会，同时由于媒体数据流传输时的数据分发压力大大降低，所有参会人员(即用户)能够同时开麦或开视频，无需重定向，体验顺滑。

与基于多点控制单元(Multipoint Control Unit，MCU)的会议架构相比，运营维护简单，不会受性能和硬件价格限制，大大提升实际承载人数，便于实现超大规模会议。

基于本申请实施例提供的音视频会议实现方法及音视频会议系统进行视频会议的界面图可以参见图5所示，在该界面中可以显示开启视频的参会人员的图像、参会列表、相关功能键的图标(例如麦克风图标、摄像头图标、管理成员图标、离开会议图标等等)，开麦的参会人员可以显示麦克风的图标，未开麦的参会人员可以在麦克风的图标上划一条斜线。在本申请实施例提供的音视频会议系统下，实现了超大规模会议，例如进入会议的人数上限可以是50000，即管理成员50000。

接着，本申请实施例从房间管理子系统302管理会议房间的角度对音视频会议实现方法进行介绍。

房间管理子系统302可以参见图6所示，包括上述多个设备组601和中心服务器(RoomSvc)602，这里的设备组601同样是包括前述多个接口机，与图4b所示的设备组类似，与此同时，每个设备组601中还包括组内服务器(RoomSvcInSet)，组内服务器用于辅助中心服务器602管理会议房间。其中，组内服务器如图6中每个设备组601中的圆环所示，例如图6中节点B、节点C、节点D、节点E、节点F、节点G；中心服务器602例如图6中节点A。

需要说明的是，在本实施例中同一个设备组中的组内服务器与回源设备可以是同一个设备，也可以是不同设备，本实施例对此不做限定。

管理会议房间主要包括管理会议房间的房间信息、状态变更的通知消息、参会列表的拉取等等。其中，房间信息例如包括会议房间的名称、创建时间、参会人员、会议时间等等。

本申请实施例通过将房间管理系统分为中心服务器和组内服务器，中心服务器只有一个，组内服务器和接口机一样按SET部署，从而使得通知消息的同步和参会列表的拉取都可以通过组内服务器来缓解中心服务器的管理压力，便于实现超大规模会议。

在设备组内部，对于同一个会议房间，所有接口机都会通过一定的算法注册相同的RoomSvcInSet，并通过心跳维持一个长连接。当会议房间内有通知消息需要进行同步(如用户的状态变更：进入会议房间参加会议、退出会议房间、开关麦、开关视频等)、或者想要拉取参会列表时，都会通过这个RoomSvcInSet来完成。

首先介绍进入会议房间参见会议的注册流程。当任一设备组例如第三设备组中的任一接口机例如第三接口机请求进入会议房间时，第三设备组中的组内服务器接收第三接口机发送的注册请求，注册请求中可以包括房间标识，用于指示需要进入哪个会议房间。若第三设备组中的组内服务器在本地未查到该会议房间的信息，向中心服务器发送该注册请求。中心服务器将第三设备组中组内服务器的标识信息记录到第一会议注册列表，并向第三设备组中的组内服务器返回注册成功信息。第三设备组中的组内服务器将第三接口机的标识信息记录到第二会议注册列表，并向第三接口机返回注册成功信息，从而完成第三接口机的注册。其中，标识信息例如可以是地址。其中，第三设备组为多个设备组中任一设备组，第三接口机为第三设备组中的任一接口机。

例如图6所示，其中节点a可以作为第三接口机，第三接口机为希望注册会议的接口机，即第三接口机上的用户终端所对应的用户希望进入会议房间参加会议。节点A可以作为中心服务器，节点B可以作为第三接口机所在设备组例如第三设备组的组内服务器。其中，节点B可以是接点a根据一定规则(一致性哈希或者分配调度)确定的。节点a向节点B发送注册请求，节点B收到节点a的注册请求后，向调度系统(Scheduler)查该会议对应的RoomSvc，即节点A。节点B向节点A发送注册请求，节点A收到节点B发出的注册请求，将节点B的地址记录到该会议的注册列表(节点A上保存的第一会议注册列表)中，给B返回注册成功信息。节点B收到节点A返回注册成功信息后，将节点a的地址记录到该会议的注册列表(节点B上保存的第二会议注册列表)，向节点a返回注册成功信息。

可以理解的是，在本实施例中，在注册成功后，组内服务器与中心服务器、组内服务器与注册成功的接口机例如第三接口机可以保持长连接，方便后续二者之间的交互。例如节点B还可以向节点A定时发送心跳，与节点A保持一个长连接通道，节点a收到节点B返回注册成功信息后，定时发送心跳，与节点B保持长连接通道。

若第三设备组中的组内服务器在根据注册请求在本地查会议房间的信息时，若在本地查到会议房间的信息，将第三接口机的标识信息记录到第二会议注册列表，并向第三接口机返回注册成功信息。

例如图6所示，其中节点b可以作为第三接口机，第三接口机为希望注册会议的接口机，即第三接口机上的用户终端所对应的用户希望进入会议房间参加会议。节点A可以作为中心服务器，节点B可以作为第三接口机所在设备组例如第三设备组的组内服务器。其中，节点B可以是接点b根据一定规则(一致性哈希或者分配调度)确定的。节点b向节点B发送注册请求，节点B收到节点b的注册请求，发现本地已经有该会议房间的信息，将节点b的地址记录到该会议的注册列表(节点B上保存的第二会议注册列表)中，并向节点b返回注册成功信息。节点b收到节点B返回注册成功信息后，定时发送心跳，与节点B保持长连接通道。

同理，位于边缘节点(即设备组与中心服务器不在同一局域网，设备组中的接口机与中心服务器不在同一局域网)上的用户注册相同会议房间时，注册流程上只需要经过中转代理设备例如图6中节点O、节点P、节点Q进行中转，其他流程类似。

当接入会议房间的用户终端发生状态变更时，例如用户开启或关闭音视频时，需要将开启或关闭音视频的这种状态变更通知给会议房间中的其他用户。以发生状态变更的用户终端位于第三设备组中的第三接口机上为例，此时，第三设备组中的组内服务器接收第三接口机发送的通知消息，并将该通知消息发送至中心服务器。中心服务器将该通知消息发送至每个设备组的组内服务器上，每个设备组的组内服务器将该通知消息发送至注册成功的接口机。

继续以上述图6为例，其中节点a可以作为第三接口机，节点a为嘉宾所在接口机，节点A可以作为中心服务器，节点B可以作为第三接口机所在设备组例如第三设备组的组内服务器。若节点a上的嘉宾开了视频，即发生状态变更，节点a将指示状态变更的通知消息(msg-a-openvideo)发送至节点B，节点B将通知消息发送给节点A。节点A遍历本地注册列表(节点A上保存的第一会议注册列表)，将通知消息发送给所有组内服务器，例如图6中的节点B、节点C、节点D、节点E、节点F、节点G。节点B、节点C、节点D、节点E、节点F、节点G收到通知消息，遍历本地注册列表(各个作为组内服务器上保存的第二会议注册列表)，将通知消息发送给所有接口机，例如图6中的节点a、节点b、节点c、节点d、节点e、节点f、节点g、节点o、节点p、节点q、节点r和节点s。

音视频会议中维护参会列表，参会列表中包括所有参会人员，本申请实施例提供的音视频会议系统实现的超大规模音视频会议中，参会人员数量巨大，故可以采用分页拉取的方式来更新本地参会列表。当某个设备组例如第三设备组中的某个接口机例如第三接口机请求拉取参会列表时，第三设备组中的组内服务器接收第三接口机的列表拉取请求，第三设备组中的组内服务器在本地查参会列表，若第三设备组中的组内服务器在本地未查到该参会列表，向中心服务器发送该列表拉取请求。第三设备组中的组内服务器接收中心服务器发送的参会列表，并将该参会列表发送至第三接口机。

例如图6所示，若节点a作为第三接口机，节点a上的用户向节点B请求参会列表，节点B在本地缓存中查，如果没有，就向节点A发起列表拉取请求。节点A收到列表拉取请求后，将对应的参会列表返回给节点B，节点将参会列表缓存在本地后，并将参会列表返回给节点a。其中，参会列表可以是全部参会列表，也可以是分页拉取的某页参会列表例如Page1。

第三设备组中的组内服务器在本地查参会列表时，若第三设备组中的组内服务器在本地查到该参会列表，且该参会列表未过期，将该参会列表返回给第三接口机。

继续上个例子，若图6所示的节点b作为第三接口机，如果在节点b上之前已经存在其他节点也请求上述参会列表Page1，此时节点B上已经存在该参会列表，故无须再向节点A请求参会列表。故节点a向节点B发送列表拉取请求，节点B在本地缓存中查，发现有Page1，并且没过期，节点B将Page1的直接返回给节点b。

接着来看一下容灾恢复的流程：由于RoomSvc的所有信息都来自RoomSvcInSet和接口机，所以RoomSvc当机后，可以很方便通过RoomSvcInSet自动重建。同理RoomSvcInSet的数据都来自接口机，当RoomSvcInSet当机后，可以通过本设备组(SET)内的接口机自动重建。

本申请实施例提供的音视频会议实现方法，通过组内服务器来缓解中心服务器的管理压力，便于实现超大规模会议。

需要说明的是，在相关技术提供的基于SFU的音视频会议，在传输会议房间中产生的媒体数据流例如音频数据流时，需要基于能量值进行音频选路。而这种方式在长距离通话中产生的延迟会非常影响体验，当参会人数比较多的时候，浪费了大量带宽并增大了用户终端网络性能损耗。并且对会议中播放动式语音应答(Interactive Voice Response，IVR)和精确录制有要求的场景，在SFU的转构下不太容易做精确控制(比如，开始和结束的判断，靠信令还是靠媒体数据流等等)。此外，语音录制的情况下，金融行业的客户是不能接受在录制过程中有多录或是少录几个字的情况的，如果没有一个集中式的音频处理服务，就很容易出现录了不该录的内容或者该录的没录下来，这些情况对于较为苛刻的用户是绝对不可以接受的。

为此，参见图3所示，本申请实施例提供的音视频会议系统中还包括混音引擎303，混音引擎303位于媒体传输网络301和公共交换电话网络(Public Switched TelephoneNetwork，PSTN)305之间，作为二者沟通的桥梁，极大提升超大规模房间下的开会体验。其中，混音引擎303通过协议例如会话初始协议(Session Initiation Protocol，SIP)或实时传输协议(Real-time Transport Protocol，RTP)连接公共交换电话网络305。

其中，混音引擎303包括混音器(Mixer)和选路器(Selector)，每个设备组具有对应的混音引擎。当媒体数据流为音频数据流时，混音引擎中的选路器将获取的多路音频数据流向位于同一设备组的混音器发送，多路音频数据流分别来自不同设备组中的第四接口机。混音器从多路音频数据流中选择目标音频数据流，并向产生目标音频数据流的用户终端连接的目标接口机发送选中通知。目标接口机向混音器发送目标音频数据流，混音器对目标音频数据流进行混音，并将混音后的音频数据流转发至第四接口机对应的选路器，第四接口机包括目标接口机。第四接口机对应的选路器将混音后的音频数据流发送至第四接口机，第四接口机向其所在设备组中的其他接口机转发混音后的音频数据流。

Mixer和Selector也是按SET部署的。为了尽可能降低延迟，一个SET的Mixer和Selector部署在同一个可用区里(可用区内部传输延时可以控制在2ms)。与此同时，同一个会议的音频数据流，会集中在一个SET中处理，并且最终会集中到同一个Mixer执行混音。

假设图7代表了一个真实的会议，其中有3个参会人员开了麦，这三个参会人员所属接口机为节点a、节点f和节点g，其他接口机上都是观众。为了简化示例图，假定每个会议选2路音频数据流(通常真正的会议选4-6路音频数据流)，此时音频数据流的处理流程如下：

节点a、节点f、节点g向图6中的调度系统请求选路器(为了尽可能减小延迟，调度系统会对同会议房间的音频数据流分配同一个可用区的选路器)，分别得到图7中节点B、节点C、节点D所表示的选路器。节点a、节点f、节点g将音频数据流转发给分别对应的节点B、节点C、节点D。节点B、节点C、节点D将缓存上行音频数据流，将能量值上报给混音器。混音器对能量值进行排序，并从中选出节点f、节点g的两路音频数据流作为目标音频数据流，然后告知节点C和节点D，节点C和节点D作为目标接口机。节点C和节点D收到选中通知后，把相应的目标音频数据流转发给混音器(这两步延迟在5ms以内)，混音器对收到的目标音频数据流进行混音，然后把混音后的音频数据流转发给节点B、节点C、节点D，节点B、节点C、节点D将混音后的音频数据流发送给节点a、节点f、节点g。节点a、节点f、节点g再进行SET内部转发。

注意，这里给发送给嘉宾的流和给普通观众的流是不同的，给嘉宾的混音后的音频数据流要把自己说话的那一路排除掉。所以被选中的接口机会收到两路音频数据流，一路转发给发言的那个嘉宾，另一路转发给SET内的观众。

混音引擎303是实时的媒体处理系统，因为经过混音引擎303处理过的音频数据流需要实时转发给会议房间内的所有参会人员。而很多情况下还有可能需要异步流处理系统，即这个系统拿到音频数据流之后不需要再发回给会议房间里的参会人员，而是另作他用(例如录制、鉴黄、直播推流等)，所以通常不需要那么实时。基于此，本申请实施例提供的音视频会议系统参见图3所示，还包括旁路媒体处理系统304，旁路媒体处理系统304用于通过机器人终端拉取会议房间中产生的媒体数据流，并对媒体数据流进行处理。其中，机器人终端参见图3所示，包括直播流机器人(LiveStream Robot)、录制机器人(Record Robot)、会议连接机器人(MRA Robot)。

在本实施例中，采用机器人(Robot)终端进入会议房间拉流的方式来实现旁路媒体处理功能。以录制为例，用户业务后台通过应用程序接口(Application ProgrammingInterface，API)方式启动一个录制任务，录制任务系统实例化一个Record Robot模拟参会人员进入会议。Record Robot将会议中的媒体数据流拉到本地，混流转码后进行录制。会议结束后，Record Robot将录制的文件上传到指定的存储(也可以定时上传部分分片)。

需要说明的是，鉴黄、直播推流的方案与录制类似，区别仅在于业务逻辑。与第三方会议设备对接时，由于要进行双向通信，所以与录制方案稍有不同：

在与第三方会议设备对接时，参见图8所示，用户业务后台启动一个MRA(会议连接器)Robot，MRA Robot进入**会议(此时其他参会人员可以看到这个MRA Robot)，MRA Robot同时通过连接协议(例如SIP或H323等协议)与第三方会议设备连接。MRA Robot把**会议中的所有媒体数据流拉到本地、混流之后，通过连接协议转发给第三方会议设备。从第三方会议设备发来的媒体数据流，MRA Robot将其转换成**会议的私有协议，通过媒体传输网络转发给会议房间中其他参会人员。其中，图8中801为移动会议终端，802为**会议房间智能会议室，用于接入**会议。

需要说明的是，如果音视频会议系统不引入混音引擎，还可以使用图9所示的架构来实现数据传输网络301与公共交换电话网络305的对接。即通过选路器与旁路媒体处理系统中涉及到的机器人共同实现混音引擎的功能。其中，选路器基于能量及对应的选路决策进行选路。

基于前述提供的音视频会议实现方法，本申请实施例还提供一种音视频会议实现装置，参见图10所示，所述装置1000包括接收单元1001和转发单元1002：

所述接收单元1001，用于接收第一设备组中第一接口机的拉流申请，所述第一设备组为多个设备组中的任一设备组，所述多个设备组中每个设备组中存在回源设备，每个设备组中包括多个接口机，所述多个接口机中每个接口机用于连接用户终端，以使所述用户终端通过接口机接入会议房间；所述第一接口机是所述第一设备组中的任一接口机；

所述转发单元1002，用于根据所述拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至所述第一接口机上，以使所述第一接口机将所述媒体数据流转发至对应的用户终端；产生所述媒体数据流的用户终端通过所述第二接口机接入所述会议房间，所述第二设备组为所述多个设备组中的任一设备组。

在一种可能的实现方式中，所述转发单元1002，用于：

根据所述拉流申请查所述第二接口机的媒体数据流；

若未查到所述第二接口机的媒体数据流，向所述第二接口机转发所述拉流申请；

所述接收单元1001，还用于接收所述第二接口机根据所述拉流申请转发的所述媒体数据流；

所述转发单元1002，还用于将所述媒体数据流转发至所述第一接口机。

在一种可能的实现方式中，所述转发单元1002，还用于：

若查到所述第二接口机的媒体数据流，将所述媒体数据流转发至所述第一接口机。

在一种可能的实现方式中，若所述第一设备组与所述第二设备组位于不同局域网，所述转发单元1002，用于：

通过所述中转代理设备向所述第二接口机转发所述拉流申请；

通过所述中转代理设备接收所述第二接口机根据所述拉流申请转发的所述媒体数据流。

在一种可能的实现方式中，所述第一设备组中的回源设备是所述第一接口机按照预设规则确定得到的，所述预设规则使得同一媒体数据流通过同一回源设备路由到其所在设备组中的接口机上。

在一种可能的实现方式中，所述装置还包括发送单元、记录单元和返回单元：

当第三设备组中的第三接口机请求进入所述会议房间时，所述接收单元1001，还用于接收所述第三接口机发送的注册请求，所述第三设备组为所述多个设备组中的任一设备组，所述第三接口机为所述第三设备组中的任一接口机；

所述发送单元，用于若在本地未查到所述会议房间的信息，向中心服务器发送所述注册请求，以使所述中心服务器将所述第三设备组中组内服务器的标识信息记录到第一会议注册列表，并向所述第三设备组中的组内服务器返回注册成功信息；

所述记录单元，用于将所述第三接口机的标识信息记录到第二会议注册列表；

所述返回单元，用于向所述第三接口机返回所述注册成功信息。

在一种可能的实现方式中，若在本地查到所述会议房间的信息，所述记录单元，还用于将所述第三接口机的标识信息记录到所述第二会议注册列表；

所述返回单元，还用于向所述第三接口机返回所述注册成功信息。

在一种可能的实现方式中，当第三设备组中的第三接口机连接的用户终端发生状态变更时，所述接收单元1001，还用于接收所述第三接口机发送的通知消息；

所述发送单元，用于将所述通知消息发送至所述中心服务器，以使所述中心服务器将所述通知消息发送至每个设备组的组内服务器上，每个设备组的组内服务器用于将所述通知消息发送至注册成功的接口机。

在一种可能的实现方式中，当第三设备组中的第三接口机请求拉取参会列表时，所述接收单元1001，还用于接收所述第三接口机的列表拉取请求；

所述发送单元，用于若在本地未查到所述参会列表，向所述中心服务器发送所述列表拉取请求；

所述接收单元1001，还用于接收所述中心服务器发送的所述参会列表；

所述发送单元，用于将所述参会列表发送至所述第三接口机。

在一种可能的实现方式中，所述发送单元，还用于若在本地查到所述参会列表，且所述参会列表未过期，将所述参会列表返回给所述第三接口机。

在一种可能的实现方式中，所述装置还包括选择单元和混音单元：

所述发送单元，还用于当媒体数据流为音频数据流时，通过混音引擎中的选路器将获取的多路音频数据流向位于同一设备组的混音器发送，所述多路音频数据流分别来自不同设备组中的第四接口机；

所述选择单元，用于通过混音器从所述多路音频数据流中选择目标音频数据流；

所述发送单元，用于向目标接口机发送选中通知，所述目标接口机为产生所述目标音频数据流的用户终端连接的接口机；

所述接收单元1001，还用于通过所述混音器接收所述目标接口机发送的目标音频数据流；

所述混音单元，用于对所述目标音频数据流进行混音；

所述转发单元1002，还用于将混音后的音频数据流转发至所述第四接口机对应的选路器；所述第四接口机包括所述目标接口机；

所述发送单元，还用于通过所述第四接口机对应的选路器将混音后的音频数据流发送至所述第四接口机，以使所述第四接口机向其所在设备组中的其他接口机转发所述混音后的音频数据流。

在一种可能的实现方式中，所述装置还包括处理单元：

所述处理单元，用于通过机器人终端拉取所述会议房间中产生的媒体数据流，并对所述媒体数据流进行处理。

本申请实施例还提供了一种用于音视频会议实现的电子设备，该电子设备可以是终端，以终端为智能手机为例：

图11示出的是与本申请实施例提供的终端相关的智能手机的部分结构的框图。参考图11，智能手机包括：射频(英文全称：Radio Frequency，英文缩写：RF)电路1110、存储器1120、输入单元1130、显示单元1140、传感器1150、音频电路1160、无线保真(英文全称：wireless fidelity，英文缩写：WiFi)模块1170、处理器1180、以及电源1190等部件。输入单元1130可包括触控面板1131以及其他输入设备1132，显示单元1140可包括显示面板1141，音频电路1160可以包括扬声器1161和传声器1162。本领域技术人员可以理解，图11中示出的智能手机结构并不构成对智能手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储器1120可用于存储软件程序以及模块，处理器1180通过运行存储在存储器1120的软件程序以及模块，从而执行智能手机的各种功能应用以及数据处理。存储器1120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据智能手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器1180是智能手机的控制中心，利用各种接口和线路连接整个智能手机的各个部分，通过运行或执行存储在存储器1120内的软件程序和/或模块，以及调用存储在存储器1120内的数据，执行智能手机的各种功能和处理数据，从而对智能手机进行整体监控。可选的，处理器1180可包括一个或多个处理单元；优选的，处理器1180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1180中。

在本实施例中，前述实施例中由终端所执行的步骤可以基于图2所示的结构实现。

该电子设备还可以包括服务器，本申请实施例还提供服务器，请参见图12所示，图12为本申请实施例提供的服务器1200的结构图，服务器1200可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，简称CPU)1222(例如，一个或一个以上处理器)和存储器1232，一个或一个以上存储应用程序1242或数据1244的存储介质1230(例如一个或一个以上海量存储设备)。其中，存储器1232和存储介质1230可以是短暂存储或持久存储。存储在存储介质1230的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1222可以设置为与存储介质1230通信，在服务器1200上执行存储介质1230中的一系列指令操作。

服务器1200还可以包括一个或一个以上电源1226，一个或一个以上有线或无线网络接口1250，一个或一个以上输入输出接口1258，和/或，一个或一个以上操作系统1241，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

在本实施例中，所述服务器1200中的中央处理器1222可以执行以下步骤：

接收所述第一设备组中第一接口机的拉流申请，所述第一设备组为多个设备组中的任一设备组，所述多个设备组中每个设备组中存在回源设备，每个设备组中包括多个接口机，所述多个接口机中每个接口机用于连接用户终端，以使所述用户终端通过接口机接入会议房间；所述第一接口机是所述第一设备组中的任一接口机；

根据所述拉流申请将从第二设备组中第二接口机获取的媒体数据流转发至所述第一接口机上，以使所述第一接口机将所述媒体数据流转发至对应的用户终端；产生所述媒体数据流的用户终端通过所述第二接口机接入所述会议房间，所述第二设备组为所述多个设备组中的任一设备组。

根据本申请的一个方面，提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行前述各个实施例所述的音视频会议实现方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例各种可选实现方式中提供的方法。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术成员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。