CN105991577B - 一种语音通话处理方法、系统和云端服务器 - Google Patents

Abstract

本发明公开了一种语音通话处理方法，语音通话的流控引擎以及混音引擎均部署在云端服务器，所述方法包括：所述流控引擎接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或中转服务器上报的第二状态信息；根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略；下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；所述混音引擎对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端。

Description

一种语音通话处理方法、系统和云端服务器

技术领域

本发明涉及基于互联网的语音通话技术领域，尤其涉及一种语音通话处理方法、系统和云端服务器。

背景技术

对于语音通话业务而言，语音数据中转系统不仅需要将音频数据从发送端转发到接收端，还要尽量保证语音通话的高质量。如果将两人语音通话中双方的上下行数据流视作一个全双工通讯信道，那么这个通道中任意一方的网络质量发生波动，都会引发控制策略的动态调整，从而对通话质量产生正面/负面的影响。这些控制策略的集合称为流控引擎。

从抽象层面上来看，有M路语音发送方和N路语音收听方的多人语音通话可以视作M×N个两人全双工通讯信道相互关联而形成的通讯网络。由于这个通讯网络中的任何一环出现质量问题都会对整个多人会话的语音质量造成影响，因此多人语音通话服务的流控引擎不但要能有效对抗通讯信道网络的质量波动，还要兼顾整体通话质量，从而比两人通话的控制策略更为复杂，实现起来的难度和成本也更大。

虽然流控引擎对于多人语音通话数据中转系统的重要性不言而喻，但除了需要控制好复杂交织的通讯信道网络之外，还需要解决多人通话特有的一些问题，比如：通话参与人数越多，上下行的语音路数也就越多，而多人通话的扩散效应导致的前后台带宽和处理器计算压力就越明显，这也会间接地影响语音通话质量。以上也为本发明要解决的技术问题。

发明内容

为解决现有存在的技术问题，本发明实施例提供一种语音通话处理方法、系统和云端服务器。

本发明实施例提供了一种语音通话处理方法，语音通话的流控引擎以及混音引擎均部署在云端服务器，所述方法包括：

所述流控引擎接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或中转服务器上报的第二状态信息；

所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略；

通过所述中转服务器，下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；

所述方法还包括：所述混音引擎对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端。

上述方案中，所述方法还包括：所述混音引擎和流控引擎之间通过共享内存完成数据交互。

上述方案中，所述客户端的上行通道是所述客户端作为语音发送方时到中转服务器之间的通讯通道，所述客户端的下行通道是所述客户端作为语音接收方时到中转服务器之间的通讯通道。

上述方案中，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

相应的，所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略，包括：

所述流控引擎根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与所述流控引擎接收的信息相匹配的流控策略。

本发明实施例还提供了一种云端服务器，所述流控引擎，用于接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或中转服务器上报的第二状态信息；所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略；通过所述中转服务器，下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；

所述云端服务器中还部署有语音通话的混音引擎，所述混音引擎用于，对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端。

上述方案中，所述云端服务器还包括共享内存，所述混音引擎和流控引擎之间通过共享内存完成数据交互。

上述方案中，所述流控策略包括对应所述客户端的上行通道流控策略和下行通道流控策略，所述客户端的上行通道是所述客户端作为语音发送方时到中转服务器之间的通讯通道，所述客户端的下行通道是所述客户端作为语音接收方时到中转服务器之间的通讯通道。

上述方案中，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

所述流控引擎进一步用于，根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与接收的信息相匹配的流控策略。

本发明实施例还提供了一种语音通话处理系统，所述系统包括：云端服务器和中转服务器，其中，

所述云端服务器中部署有语音通话的流控引擎，所述流控引擎接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息；根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，计算对应所述客户端的流控策略，并通过所述中转服务器下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；

所述云端服务器中还部署有语音通话的混音引擎，所述混音引擎用于，对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端；

所述中转服务器用于，为客户端提供接入和数据中转、扩散通道，接收客户端的能力信息和第一状态信息上报到所述流控引擎，接收所述流控引擎的流控策略并下发到相应的客户端。

上述方案中，所述云端服务器还包括共享内存，所述混音引擎和流控引擎之间通过共享内存完成数据交互。

上述方案中，所述客户端的上行通道是所述客户端作为语音发送方时到中转服务器之间的通讯通道，所述客户端的下行通道是所述客户端作为语音接收方时到中转服务器之间的通讯通道。

上述方案中，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

所述流控引擎进一步用于，根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与接收的信息相匹配的流控策略。

本发明实施例提供的一种语音通话处理方法、系统和云端服务器，在云端部署流控引擎和混音引擎，使多人语音通话在单个会话规模上拥有了极强的扩展性，可以轻而易举地支持单会话数千人同时在线的体验。相对于Skype单会话最多25人、且对发起方软硬件和网络环境要求及其严苛的限制而言是一个巨大的进步。与此同时，“上下行通道流控策略分离”与“流控、混音双引擎”架构也在最大程度上降低了上下行通道之间的相互干扰，保证了多人语音通话的最优服务体验。本发明实施例通过强化和提升多人音视频通话系统的云端服务能力，实现在用户网络质量不稳定、上下行带宽受限等不利因素的干扰下，仍然能够持续、稳定地提供清晰流畅的高质量多人语音通话服务。

附图说明

图1为本发明实施例一的语音通话处理系统的结构示意图；

图2为本发明实施例一的音频编码分组与带外FEC的示意图一；

图3为本发明实施例一的音频编码分组与带外FEC的示意图二；

图4为本发明实施例一的上下行通道流控策略分离的示意图；

图5为本发明实施例三的语音通话处理方法的流程示意图。

具体实施方式

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

实施例一

为强化和提升多人音视频通话系统的云端服务能力，本发明实施例一提供一种语音通话处理系统，如图1所示，该系统主要包括：云端服务器和中转服务器；其中，

云端服务器中部署有语音通话的流控引擎，所述流控引擎用于接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息；根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，计算对应所述客户端的流控策略，并通过所述中转服务器下发所述流控策略给所述客户端执行；

所述中转服务器用于，为客户端提供接入和数据中转、扩散通道，接收客户端的能力信息和第一状态信息上报到所述流控引擎，接收所述流控引擎的流控策略并下发到相应的客户端。

在一实施方式中，云端服务器中还可部署语音通话的混音引擎，所述混音引擎用于，对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端。

其中，所述云端服务器还可包括共享内存，所述混音引擎和流控引擎之间通过共享内存完成数据交互。

下面再结合图1详细介绍语音通话处理系统的各部分功能。

图1中的虚线箭头线代表信令通道，实线箭头线代表音频数据通道。客户端与云端服务器、客户端与客户端之间的数据交互都需要通过中转服务器进行转发。出于效率方面的考虑，流控引擎与混音引擎可以同机部署也可以不同机部署，双引擎之间数据交互通过共享内存来实现；所述共享内存中可用于存储用户信息、客户端上报信息、语音通话的房间信息等等，以上信息都可以为所述混音引擎和流控引擎所用。

图1所示系统中的中转服务器负责为客户端提供接入和数据中转、扩散通道，该通道不仅能够传输音频数据，还肩负着客户端能力(是否有摄像头/麦克风、CPU/IO性能评分等)与状态(网络类型切换、丢包率、时延、CPU占用等)信息上报和流控策略下发等重要责任。需要说明的是，在本发明实施例中，语音数据中转和扩散都是通过由中转服务器完成的，客户端之间并不会有直接的数据交互。

图1所示系统中的流控引擎是部署在云端的，主要负责根据客户端的能力信息和当前的网络状况，周期性地为其计算并下发有针对性的流控策略，以帮助客户端对抗网络抖动、提高通话质量等。在多人语音通话中，一路上行语音数据会被中转服务器扩散给相同会话内的所有用户，所以上行语音用户的网络质量和冗余策略将会影响所有收听的用户的通话效果。进一步地，当会话中存在多路上行语音时，收听方的通话效果取决于所有上行语音质量和收听方客户端到中转服务器之间网络状况的叠加，这就要求流控引擎的控制策略不但要实时、精细化，而且要有会话级别的大局观。这也是多人语音通话与两人通话流控引擎最大的差别所在。

图1所示系统中的混音引擎是部署在云端的，即由云端来执行多路上行语音数据的混音处理，这也是区别于现有技术的。在多人语音通话中，由于每一路上行语音都会扩散给相同会话内的所有用户，因此，上行语音路数越多，收听方客户端的带宽压力和混音的系统开销也就越大。此外，如果采用收听方客户端混音的做法也不利于流控引擎针对低带宽用户的调控。例如，当个别收听方下行带宽不够时，降低所有上行方的音频码率会导致会话内所有其他收听方通话质量下降；而如果针对该低带宽收听方停止中转某些数据将会使其通话信息接收不完整。所以，如果没有云端的混音引擎，流控引擎此时将陷入两难的境地，最终只能放弃对这些低带宽用户的调控，任其下行通道撑爆。再有，现有技术如Skype将混音的责任放到会话发起方客户端，即多人语音通话的发起方客户端负责接收所有被叫方的上行语音数据，将多路数据混音和重新编码之后再转发给所有被叫方客户端播放；而在流控策略方面，如果发起方网络上下行质量变差，则所有被叫方收到的语音码率都会随之下调，以减少发起方的网络带宽压力。发起方客户端负责混音的方案，对发起方的网络质量和计算能力要求颇高，这会成为制约整个多人通话质量的瓶颈，同时严重影响会话规模的扩展。因此，综合考虑了上述发起方客户端负责混音的方案、以及收听方客户端负责混音的方案，本发明实施例选择采用云端负责混音的方案，即将混音引擎部署在云端服务器中；本发明实施例选择在云端部署混音引擎不仅可以规避上述发起方客户端负责混音、以及收听方客户端负责混音方案中的缺陷，而且，当有参与者通过公共交换电话网络(PSTN，PublicSwitchedTelephoneNetwork)或WEB的形式接入多人语音通话时，也需要混音引擎为其混音和转码，以保证PSTN/WEB接入用户的正常使用，混音引擎部署在云端更能从容应对PSTN或WEB参与者的接入。

关于能力信息上报，需要说明的是，在用户创建或进入多人通话之前，需要对用户所在客户端本地的能力信息(如是否有摄像头/麦克风、CPU能力评分等)进行收集，并通过中转服务器上报给流控引擎，以备流控引擎在计算针对该客户端的流控策略时参考。例如：如果客户端是2G/3G网络，则流控引擎会命令客户端使用较低的采样率以节省带宽；如果客户端CPU评分过低，则流控引擎会控制客户端使用复杂度较低的编码方式以减少CPU消耗；对于某些参与用户非常多的超大规模多人语音通话，在计算单个用户流控策略时，对于无上行能力(既没有摄像头、也没有麦克风)的收听用户，可以适当拉长计算间隔。在用户通话过程中，如果客户端能力信息发生变化(比如热拔插摄像头/麦克风等)，客户端也需要及时向流控引擎上报其能力变更信息，以备流控引擎及时调整针对该客户端的流控策略。

关于状态信息上报，需要说明的是，作为多人通话的收听方的客户端需要根据收到数据包的序列号和时间间隔来统计中转服务器与收听方客户端之间的网络丢包和延迟的情况，并周期性地(出于调控及时性考虑，周期通常很短)将这些信息上报给流控引擎，作为流控引擎进行策略计算和动态调整的依据。而由于本发明实施例中所有数据都需要通过中转服务进行传输，所以语音数据发送方客户端到中转服务之间网络的丢包和延迟情况就只能由中转服务负责计算并上报给流控引擎了。因此，本发明实施例中，作为多人通话的收听方客户端需要周期性地向流控引擎上报其与中转服务器之间的网络丢包和延迟等第一状态信息；而中转服务器也需要周期性地向流控引擎上报其与发送方客户端之间的网络丢包和延迟等第二状态信息。

在本发明实施例中，将语音发送方客户端到中转服务之间的通讯信道称为上行通道、将中转服务与收听方客户端之间的通讯信道称为下行通道。通道带宽预测结果作为一种状态信息，是指根据历史和当前的通道带宽观测值、利用特定的算法来预测下一时刻的可用带宽大小。对于流控引擎而言，通道的可用带宽是最重要的调控参考指标之一，所以准确、及时的通道带宽预测对于语音通话业务的服务质量至关重要。带宽预测有很多成熟且高效的算法，引擎实现者可以根据实际情况选择适合业务特点的算法。由于带宽预测的结果通常是由通道的接收方负责计算的，所以上行通道的带宽预测是由中转服务器计算并通过内网上报给流控引擎的，而下行通道的预测则是由客户端计算并通过中转服务器上报给流控引擎的。在多人语音通话业务中，每个上行通道只有一路数据，所以带宽预测的实现方式和两人通话区别不大；但对于下行通道而言，由于每个收听用户会接收多路语音数据，所以语音上行用户说话与否将会导致收听用户下行语音路数和流量的剧烈变化，从而严重影响带宽预测算法的准确性，进而影响流控策略的计算。因此本发明实施例引入了混音引擎，在服务端进行音频选路和混音，使每个收听用户的下行通道也只有一路数据，从而降低了上行用户的多寡对收听用户下行通道流量和带宽预测算法的影响，提升了整体通话质量。

综上所述，流控引擎会根据多人通话的收听方客户端上报的第一状态信息，计算和动态调整针对相应收听方客户端的流控策略；会根据中转服务器上报的其与发送方客户端之间第二状态信息，计算和动态调整针对相应发送方客户端的流控策略。

由此可见，本发明实施例中，流控策略包括对应所述客户端的上行通道流控策略和下行通道流控策略，所述客户端的上行通道是所述客户端作为语音发送方时到中转服务器之间的通讯通道，所述客户端的下行通道是所述客户端作为语音接收方时到中转服务器之间的通讯通道；

其中，所述客户端的上行通道流控策略和下行通道流控策略采用分离的方式。

下面以前向纠错编码(FEC，ForwardErrorCorrection)策略的上下行通道隔离来具体说明上行通道流控策略和下行通道流控策略隔离的实现。

FEC是通信领域常用的一种信道差错控制方法，大多数实时语音通话服务都采用了FEC来对抗网络抖动、提高服务质量，本发明实施例中提到的FEC是指Outbound-FEC，即所谓带外FEC。在多人语音通话中，每个发言用户的语音数据(包括FEC)都被扩散并转发至所有收听用户，而上行通道与各个下行通道之间的网络状况差异又很大，所以上行用户用以对抗网络抖动所加的FEC数量难以兼顾到多个下行通道的实际状况。如果只是简单粗暴地在上行通道加大FEC比例来覆盖最差下行通道的网络抖动，则上行语音的核心码率将被多余的FEC挤占，导致最差下行通道拖累了整体通话质量；对于大多数网络状况很好、不需要那么多FEC的下行通道而言，多余的FEC只会浪费客户端流量、加大服务端带宽成本压力。综上所述，上行通道不应、也无法很好地兼顾下行通道的抗抖动策略。因此，本发明实施例将上行通道和下行通道的控制策略完全隔离，杜绝了上下行通道相互影响的弊端，从而进一步节省前后台带宽成本、降低了流控引擎控制策略的复杂度。

一个实时的语音通话数据流的编码分组通常如图2所示，若干个音频包构成了一个编码分组，音频数据包之间的发送间隔是固定的(比如60ms)，在分组的最后一个音频数据包发出之后会立即再发送这个编码分组所对应的FEC包，FEC包的数量与设定的冗余率相关。

于是，一个实时的语音通话数据流如图3所示，由一个个连续的音频编码分组构成，每个编码分组根据当时上下行通道的网络状况携带了不同数量的FEC。

上下行通道流控策略分离的基本思想是：发送方只对上行通道的网络质量负责，即发送方上行的FEC数量只够对抗上行抖动即可；而中转服务器在转发上行数据之前，会按编码分组对上行的FEC进行重编，即使用音频分组数据重新生成与音频数据包数量相同的FEC(50％冗余率)；然后在下行扩散音频分组数据时，根据每一个下行通道的丢包率，动态计算应该下发的FEC数量(即对于网络质量好的下行通道，跳过一些FEC包的下发)，使每一个下行通道都能实现合理的冗余率，从而实现上下行通道流控策略的分离。完整的通道控制分离和FEC重编与按需跳过的整体架构如图4所示。

下面再详细介绍流控策略的计算。

参与多人通话的每个客户端和中转服务器都会将客户端能力变化、网络丢包状况和带宽预测结果等重要信息周期性地上报给流控引擎，从而触发流控引擎周期性地计算针对每个客户端的流控策略并下发给客户端执行。得益于混音引擎和上下行通道控制策略的分离技术，消弭了多人语音通话上、下行通道的本质差异(即收听方本应接收多路下行语音数据)，使得上下行通道控制可以用统一的方式来进行，从而简化了流控引擎的复杂度。

流控引擎包括流控策略集合，其表现形式可以是如下所示的一个表格，表格中的每一行代表一条流控策略。

流控引擎只需要根据客户端的当前状态、网络丢包率、带宽预测值等信息查找对应的表项(也可称为档位)下发给客户端即可。上述表格中，RateTH表示可用带宽预测档位值(Kbps)，FEC表示是否需要加带外FEC(其值只有0＝False，1＝True)，Kernel表示核心码率(Kbps)，Span表示发包间隔(ms)，而FECUP则表示冗余率。

下面举例来说明流控引擎是如何工作的。对于一个语音上行通道，其初始状态的档位是LINE_1；在一个上报周期之后，假设该上行通道网络质量不错，丢包率很低(低于某个预定的阀值)且带宽预测结果高于当前档位阀值，那么流控引擎就会对其做“升档”处理，即将核心码率更大、发包间隔更小的LINE_2下发给客户端；假定这段时间网络情况一直不错，带宽预测结果也一直高于当前档位阀值，则流控引擎就会一直做升档处理，直到丢包率增大、带宽预测值低于当前档位阀值或已经升到最高档位为止(当然，升降档的速度需要另外调控)。如果丢包率超过阀值但带宽预测结果变化不大，则引擎会升档到一个核心码率不变、但FEC冗余率变大的档位来抵抗网络波动；而如果带宽预测结果小于当前档位，则流控引擎需要降档到一个符合带宽预测值且FEC冗余足够多的档位来缓解带宽压力并对抗过载。这个过程就好比驾驶一辆手动挡的汽车，车多拥挤时需要降档缓行，车少通畅时可以升档提速(但不能超过限速阀值)；远远看到(预测)到前面车多拥堵时需要尽快降档减速；相反地，如果看到(预测)前面拥堵缓解时则需要缓慢提速避免发生事故。

对于语音下行通道，除了FEC重编和跳过策略之外，如果下行通道带宽不足，流控引擎还可以通知混音引擎调整该通道混音后数据的采样率和编码复杂度来达到以质量换带宽的目的。但如果上行的采样率已经是系统设定的最小值，那么流控引擎也没有更多办法做进一步处理，毕竟下行通道的调控余地比上行通道要小一些。

综上所述，通过本发明实施例一，在云端部署流控引擎和混音引擎，使多人语音通话在单个会话规模上拥有了极强的扩展性，可以轻而易举地支持单会话数千人同时在线的体验。相对于Skype单会话最多25人、且对发起方软硬件和网络环境要求及其严苛的限制而言是一个巨大的进步。与此同时，“上下行通道流控策略分离”与“流控、混音双引擎”架构也在最大程度上降低了上下行通道之间的相互干扰，保证了多人语音通话的最优服务体验。

实施例二

基于本发明实施例一所提供的语音通话处理系统，本发明实施例二介绍一种云端服务器。如图1所示，该系统中的云端服务器中部署有语音通话的流控引擎，所述流控引擎用于，接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息；根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，计算对应所述客户端的流控策略，并通过所述中转服务器下发所述流控策略给所述客户端执行。

在一实施方式中，所述云端服务器中还部署有语音通话的混音引擎，所述混音引擎用于，对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端。

在一实施方式中，所述云端服务器还包括共享内存，所述混音引擎和流控引擎之间通过共享内存完成数据交互。

在一实施方式中，所述流控策略包括对应所述客户端的上行通道流控策略和下行通道流控策略，所述客户端的上行通道是所述客户端作为语音发送方时到中转服务器之间的通讯通道，所述客户端的下行通道是所述客户端作为语音接收方时到中转服务器之间的通讯通道；

其中，所述客户端的上行通道流控策略和下行通道流控策略分离。

在一实施方式中，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

所述流控引擎进一步用于，根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与接收的信息相匹配的流控策略。

实施例三

基于本发明实施例一所提供的语音通话处理系统，以及实施例二所提供的云端服务器，本发明实施例三提供一种语音通话处理方法，将语音通话的流控引擎以及混音引擎均部署在云端服务器。如图5所示，所述方法包括：

步骤501，所述流控引擎接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或中转服务器上报的第二状态信息。

步骤502，所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略，通过所述中转服务器，下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离。

在一实施方式中，语音通话的混音引擎也部署在云端服务器，所述方法还包括：

所述混音引擎对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端。

其中，混音引擎和流控引擎之间通过共享内存完成数据交互，所述共享内存中可用于存储用户信息、客户端上报信息、语音通话的房间信息等等，以上信息都可以为所述混音引擎和流控引擎所用。

其中，所述流控策略包括对应所述客户端的上行通道流控策略和下行通道流控策略，所述客户端的上行通道是所述客户端作为语音发送方时到中转服务器之间的通讯通道，所述客户端的下行通道是所述客户端作为语音接收方时到中转服务器之间的通讯通道；

所述客户端的上行通道流控策略和下行通道流控策略分离。

所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

相应的，所述云端服务器根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，计算对应所述客户端的流控策略，包括：

所述流控引擎根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与所述流控引擎接收的信息相匹配的流控策略。

综上所述，本发明实施例在云端部署流控引擎和混音引擎，使多人语音通话在单个会话规模上拥有了极强的扩展性，可以轻而易举地支持单会话数千人同时在线的体验。相对于Skype单会话最多25人、且对发起方软硬件和网络环境要求及其严苛的限制而言是一个巨大的进步。与此同时，“上下行通道流控策略分离”与“流控、混音双引擎”架构也在最大程度上降低了上下行通道之间的相互干扰，保证了多人语音通话的最优服务体验。本发明实施例通过强化和提升多人音视频通话系统的云端服务能力，实现在用户网络质量不稳定、上下行带宽受限等不利因素的干扰下，仍然能够持续、稳定地提供清晰流畅的高质量多人语音通话服务。

还需要说明的是，本发明实施例的流控策略并不仅包括FEC策略，还可以包括自动重传请求(ARQ，AutomaticRepeat-reQuest)等其他策略。流控策略的计算也不仅限于本发明实施例中描述的查表方式，还可以使用其他任何智能、动态的策略计算和调控方式。“FEC重编与按需FEC跳过”中说明的音频编码分组内的FEC的存在方式，可以不必严格放在分组内最后一个音频包后面，而是可以根据实际需要放在分组内任意的位置。流控引擎和混音引擎可以同机部署，也可以不同机部署；流控引擎和混音引擎的交互方式也不仅限于本发明实施例的共享内存实现方式，还可以根据实际需要选择采用其他可行的替代方式。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (12)

1.一种语音通话处理方法，其特征在于，语音通话的流控引擎以及混音引擎均部署在云端服务器，所述方法包括：

所述流控引擎接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或中转服务器上报的第二状态信息；

所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略；

通过所述中转服务器，下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；

所述方法还包括：所述混音引擎对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端；

其中，所述客户端包括参与语音通话的所述收听方客户端和发送方客户端，所述第一状态信息反映 所述中转服务器与所述收听方客户端之间的网络丢包和延迟；所述第二状态信息反映 所述中转服务器与所述发送方客户端之间的网络丢包和延迟。

2.根据权利要求1所述语音通话处理方法，其特征在于，所述方法还包括：所述混音引擎和流控引擎之间通过共享内存完成数据交互。

3.根据权利要求1或2任一所述语音通话处理方法，其特征在于，

所述客户端的上行通道是所述发送方客户端到所述中转服务器之间的通讯通道，所述客户端的下行通道是所述收听方客户端到所述中转服务器之间的通讯通道。

4.根据权利要求1或2任一所述语音通话处理方法，其特征在于，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

相应的，所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略，包括：

所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合；

获得与所述流控引擎接收的信息相匹配的流控策略。

5.一种云端服务器，其特征在于，所述云端服务器中部署有语音通话的流控引擎；

所述流控引擎，用于接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或中转服务器上报的第二状态信息；所述流控引擎根据所述客户端的能力信息和第一状态信息、和/或所述中转服务器的第二状态信息，计算对应所述客户端的流控策略；通过所述中转服务器，下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；

所述云端服务器中还部署有语音通话的混音引擎，所述混音引擎用于，对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端；

其中，所述客户端包括参与语音通话的所述收听方客户端和发送方客户端，所述第一状态信息反映 所述中转服务器与所述收听方客户端之间的网络丢包和延迟；所述第二状态信息反映 所述中转服务器与所述发送方客户端之间的网络丢包和延迟。

6.根据权利要求5所述云端服务器，其特征在于，所述云端服务器还包括共享内存，所述混音引擎和流控引擎之间通过共享内存完成数据交互。

7.根据权利要求5或6任一所述云端服务器，其特征在于，所述客户端的上行通道是所述发送方客户端到所述中转服务器之间的通讯通道，所述客户端的下行通道是所述收听方客户端到所述中转服务器之间的通讯通道。

8.根据权利要求5或6任一所述云端服务器，其特征在于，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

所述流控引擎进一步用于，根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与接收的信息相匹配的流控策略。

9.一种语音通话处理系统，其特征在于，所述系统包括：云端服务器和中转服务器，其中，

所述云端服务器中部署有语音通话的流控引擎，所述流控引擎接收参与语音通话的客户端通过中转服务器上报的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息；根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，计算对应所述客户端的流控策略，并通过所述中转服务器下发所述流控策略给所述客户端执行；其中，所述流控策略包括有：对应所述客户端的上行通道流控策略和下行通道流控策略、且所述客户端的上行通道流控策略和下行通道流控策略分离；

所述云端服务器中还部署有语音通话的混音引擎，所述混音引擎用于，对接收的多路上行语音数据进行混音，并将混音所获得的语音数据发送到语音通话的所有收听方客户端；

所述中转服务器用于，为客户端提供接入和数据中转、扩散通道，接收客户端的能力信息和第一状态信息上报到所述流控引擎，接收所述流控引擎的流控策略并下发到相应的客户端；

其中，所述客户端包括参与语音通话的所述收听方客户端和发送方客户端，所述第一状态信息反映 所述中转服务器与所述收听方客户端之间的网络丢包和延迟；所述第二状态信息反映 所述中转服务器与所述发送方客户端之间的网络丢包和延迟。

10.根据权利要求9所述语音通话处理系统，其特征在于，所述云端服务器还包括共享内存，所述混音引擎和流控引擎之间通过共享内存完成数据交互。

11.根据权利要求9或10任一所述语音通话处理系统，其特征在于，所述客户端的上行通道是所述发送方客户端到所述中转服务器之间的通讯通道，所述客户端的下行通道是所述收听方客户端到所述中转服务器之间的通讯通道。

12.根据权利要求9或10任一所述语音通话处理系统，其特征在于，所述流控引擎中存储流控策略集合，所述流控策略集合中包括至少一项流控策略；

所述流控引擎进一步用于，根据接收的所述客户端的能力信息和第一状态信息、和/或所述中转服务器上报的第二状态信息，查找所述流控引擎中的流控策略集合，获得与接收的信息相匹配的流控策略。