腾讯会议去年推出，疫情期间两个月急速扩容，日活跃账户数已超过1000万，成为了当前中国最多人使用的视频会议应用。腾讯会议突围背后，是如何通过端到端实时语音技术保障交流通畅的？本文是腾讯多媒体实验室音频技术中心高级总监商世东老师在「云加社区沙龙online」的分享整理，从实时语音通信的发展历程，到5G下语音通信体验的未来，为你一一揭晓。
一、通信系统的衍变
1. 从模拟电话到数字电话
说到腾讯会议背后的实时语音端到端解决方案，大家可能第一时间就想到了PSTN电话，从贝尔实验室创造模拟电话开始，经过一百多年的发展，整个语音通信、语音电话系统经历了很大一部分变化。尤其是最近三十年来，语音通话由模拟信号变为数字信号，从固定电话变为移动电话，从电路交换到现在的分组交换。
以前的PSTN电话系统，用的都是老式模拟话机。然后数字相对模拟电话的优势是显而易见的，尤其在通话语音质量上抗干扰，抗长距离信号衰减的能力明显优于模拟电话和系统，所以电话系统演进的第一步就是从终端从模拟电话升级到了数字电话，网络也升级到了ISDN(综合业务数字网)，可以支持数字语音和数据业务。
ISDN的最重要特征是能够支持端到端的数字连接，并且可实现话音业务和数据业务的综合，使数据和话音能够在同一网络中传递。但是本质上，ISDN还是电路交换网络系统。
所谓的电路交换，就是两个电话之间有一条专有的电路连接。基于专有电路连接的好处就是通话质量稳定。保证了链路的稳定性和通信的质量，同时也保证了整个通信的私密性。但是，这种基于电路交换的PSTN电话系统带来的弊端也很明显，尤其是打长途电话的时候。长途电话是基于专有线路，所以价格会非常昂贵。
同时，这一阶段，基于IP的互联网开始蓬勃发展，已通话为目的的通信终端也开始了从电路交换到分组交换的演进。如上图所示，分组交换的好处就是：可以分享带宽，整个链路连接并不是通话双方专享，而是很多电话共享的。共享带来的好处就是成本大幅度下降，同时，也进一步推动了整个电话语音通信技术的不断发展。
2. 从数字电话到IP电话
从2000年左右，当网络开始经历开始从电路交换到IP分组交换这样的衍进过程当中，近十年大家又开始面临一个新的挑战：整个网络、通信的终端较以前变得纷繁复杂，更加多样化。
以前主要就是电话与电话之间的通话，现在大家可以使用各种基于IP网络的客户端，比如PC、移动App，电话等通话，电话到电话间可以通过传统的电路交换，也可以是基于IP网络的数字电话。这样就导致了一个很显著的问题：整个网络开始变得异常复杂，异常多样化，终端也变成异样多样化。
在这样一个衍进过程当中，如何保证它们之间的互通性？传统的电话终端，跟不同互联网电话终端之间怎样解决互联互通的问题，又如何保证通话的质量和通话的体验呢？
3. H323与SIP协议
对于语音通话，不管是基于VoIP技术，还是基于传统的电路交换的电话，都有两个问题需要解决：首先需要注册到电话网里去，注册进去以后，在拨打电话的过程中，还需要弄清以下这些问题：怎样建立一个电话、怎样维护这个电话，以及最后怎样关闭这个电话？
电话建立起来以后还要进行能力协商，如果是IP电话，能力协商的本质就是双方交换彼此的IP和端口地址，建立逻辑通道才能进行通话。
在PSTN电话网络向IP电话网络衍进的过程当中，出现了两个非常有意思的协议族，第一个是H323协议。这个协议来自国际电信联盟ITO，它是传统制定电报电信标准的国际化组织。还有一个协议来自于互联网IETF（互联网工作组）制定的有关Internet各方面的很多标准。这两个标准协议的国际化组织各自推出相应的面对互联网通话的一整套解决方案。
H323协议族解决方案贯彻了ITO组织一贯的严谨，大包大揽的作风，整个协议族定义的非常完整和详细。从应用层到下面的传输层，使用H.225协议注册电话，用H225.0协议建立和维护电话，以及用H245在整个电话过程当中进行各种能力协商，进行IP地址的交换......这样一整套协议的制定，包括下面传输音视频使用RTP协议进行码流的传输，用RTCP协议进行整个码流的带宽控制，统计信息的上报，以及整个RTP协议上的音视频编码格式设置。整个H323协议族定义得非常详细而又完整，可以用做互联网上进行音视频通话的标准。
这个标准被很多大公司采用，像思科和微软的产品都遵循过H323标准。但是即使H323标准定义得如此完整和详细，它的市场推进速度却依然很慢。
而SIP协议来自IETF互联网工作组，互联网工作组的风格是开放和灵活的，所以他的整个协议也完全继承了其一贯的开放与灵活的思路。整体架构非常简单，SIP协议相对于H.323来说，并不规定媒体流具体是什么，只规定信令。整个SIP是利用互联网上已有的被广泛采用的像HTPP协议进行传输，整个message包全部都是用文本格式写的。所以在它各个不同的Entity之间，包括电话、Prosy、DNS、Location servier之间的通信是开放而又灵活的。
它不规定具体内容，只规定整个SIP协议有什么框架，什么样的网络结构，SIP模块之间互相通信遵循什么协议，例如用SDP协议来进行通信。通信格式也不是二进制，而H323协议就是二进制格式，非常难以扩展和阅读。
SIP协议非常开放和灵活，于是被很多公司和产品广泛采用，用在互联网通话过程中的通话建立，通话维护。但是它也有自身的弊端，那就是各个厂商之间的SIP解决方案往往难以互联互通。
H232和SIP协议，由于它们之间的定位不同，两家国际标准化组织的风格不同，在市场上也没有绝对的一家独大，各自都保留相应的市场份额。也正是因为有了H323或者SIP协议的出现，才使互联网上基于IP音视频的通话有了可能。
腾讯会议系统里面的音频解决方案正是这两个协议族和框架，在整个信令的解决方案上采用了H323协议，跟PSTN电话进行互联互通。在互联网和VoIP客户端之间采用SIP协议进行互联互通。
4. VoIP技术面临的困难和挑战
VoIP技术是基于当前这样复杂IP网络环境中，同样面临很多挑战。在电路交换中，因为资源是独占的，虽然贵但是质量可以得到保证。但是基于VoIP的解决方案是分组网络，不是独占资源，就会面临很多网络架构上的挑战，以及来自声学方面的挑战。
（1）丢包挑战
网络架构上的第一挑战是丢包，因为不是独有，而且整个UDP协议也不保证整个包一定送达目的地。
（2）延时挑战
第二个挑战是延时。整个IP网络存在很多交换机、存在各种中间交换节点，在各交换节点会产生延时。
（3）Jitter
第三个挑战是分组交换独有的一个概念：Jitter。就是对于延时的变化，虽然从发送的时间上来看，第一个包发出的时间比第二个包要早，但是到达目的地却可能是第二个包先到，导致就算收到第二个包，但是没有收到第一个包，语音也不能放出来。
（4）回声问题
VoIP电话相对于PSTN电话，会面临延时带来的挑战，导致我们在Echo的处理上也和传统大为不同。
传统电话很多时候不用考虑Echo，因为本地电话基本延时都能控制在50毫秒以内，人眼是分辨不出来到底是回声还是自己的讲话声音。但是互联网上因为Delay增大，甚至可能超过150毫秒，所以必须要把回声问题很好地解决，否则人耳听起来会感觉非常不舒服。
（5）带宽问题
另外整个网络的带宽，也跟通话质量息息相关。如果容量不够，对于VoIP通话路数和质量也会有很大的影响。
5. 腾讯会议的音视频解决方案
下图所示的是VoIP协议栈里面的一个主要框架，H323协议、SIP协议，它们各自在整个OSI集成网络模型中对应什么样的Layer，不同Layer之间是怎样进行交互的。
在整个腾讯会议语音通信里，H323和SIP信令怎样才能把呼叫建立起来，建立起来以后最重要的音视频媒体流在网上又是怎么传输的呢？
（1）实时语音通信：RTP协议
业界对于实时语音通信普遍采用的是RTP协议，RTP协议是基于UDP协议。因为它是UDP协议，所以跟TCP不太一样，它并不能保证无丢包，它是只要有包就想尽办法传送目的地。
RTP在语音通讯的过程中肯定不能直接跑在UDP上，因为语音通话对于丢包，抖动导致的语音卡顿非常敏感，但是也不能采用TCP协议，因为带来的延时太大。
所以目前大家都会采用RTP协议。RTP协议有一些机制，有两个典型的字段：Sequence Number 和 Time Stamp。通过这两个字段保证到达接收端的语音包在不连续或者乱序的情况下依然能通过一定的机制解决这个问题，在抖动不过大、丢包不过大的情况下不至于使语音通信的质量过低。
同时RTP协议里面，对于电话系统来说，语音通话存在多路流的情况。多人讲话，有音频、有视频，所以RTP定义了SRSC Identifier，不同的SRSC对应不同的音频流，不管是客户端还是服务器都可以根据情况进行混音或者混流的操作。
（2）Opus语音引擎
基于互联网的VoIP解决方案其实有很多选择，从最早的H323、G.711系列开始前前后后二三十年有几十种标准出现，但是目前Opus大有一统江湖的趋势。
从下图可以看出，整个Opus 覆盖了很宽的bite rate，从几kbps到几十kbps，Opus不光支持语音，也可以很好的支持到音乐场景，将来腾讯会议业务范围在音乐场景上也会占有一定的比例。
同时Opus还是一个低延时的语音引擎，因为在实时语音通讯中延时显得相当重要，延时超过200毫秒对于实时语音通信来说是显然不行的。
二、腾讯会议用户痛点和技术难点
在真正使用技术解决腾讯会议当中的音频问题的时候，还是能碰到很多的难点和痛点。我们在腾讯会议开发过程当中发现，用户在实际的使用体验过程中，由于各种各样的原因，导致出现许多问题。
1. 常见声音问题
（1）无声问题
首先是无声问题，例如通过VoIP客户端或者通过电话入会过程当中就能碰到无声问题，像驱动异常，硬件设备异常，无麦克风权限，设备初始化，电话打断等也能造成无声问题。
（2）漏回声
在实时语音过程当中还会出现漏回声的问题，在传统的PSTN电话系统中基本不存在回声，因为延时比较低，而且大部分电话都是话筒模式，很少使用外放。但是使用VoIP客户端，比如说PC和手机终端，越来越多的人喜欢使用外放，而不需要把耳机放在耳朵，这样就容易产生回声问题。
（3）声音嘈杂
同样还有声音嘈杂的问题，比如在移动场景，室外，或者是办公室里办公，大家使用VoIP客户端会经常听到办公室里的敲键盘声音、水杯喝水的声音，这些嘈杂声在以前使用普通电话话筒模式下并不明显。
（4）音量小，飘忽不定
还会有音量小，音量飘忽不定的情况出现，这也是跟使用的外设和使用的场景相关。像基于PC、Mac或者移动设备的系统播放回调过高，系统CPU载入过高，手持麦克风姿势不对，音乐语音判断错误，还有网络Jitter导致加减速，这些情况都会导致会议语音过程中碰到各种各样的问题，而在以前的通话里面基本上没有这些问题。
（5）声音浑浊，可懂度差
还有声音浑浊，可懂度差的问题，现在的实时通话场景比以前复杂的多，假如是在重混响的场景下，或者采集设备很差的环境下面通话，就容易导致声音的音质比较差。
（6）音频卡顿
还有像声音卡顿的问题，这个是所有使用VoIP通话过程当中大家都容易经历到的。声音卡顿大家第一时间会想到是和网络相关，但是实际解决问题的过程当中，我们发现有很多的原因都有可能导致音频卡顿。网络虽然占了很大一块，但不是所有的原因。
比如在信源质量差的时候进行声音信号处理的过程中会出现卡顿，因为一些很小的语音会被当成噪声消掉。同样，CPU过载，播放线程同步失效也会导致卡段，处理回声采集播放不同步的时候，导致漏回声的现象也会出现卡顿。所以在会议过程当中，会有来自很多方面的原因，导致最后的音质受损。
（7）宽带语音变窄带语音
另外我们还发现了一个很有意思的现象，我们公司内部很多在使用IP电话，话机和话机之间的通信音质通常比较好，但是一旦切入到腾讯会议就会发现话音由原来宽带的变成了窄带。
为什么会这样？很多时候是跟我们公司IP系统采用的网络拓扑结构有很大关系。因为很多公司内部很多网段并不能实现互联互通，这个时候往往需要经过转码，提供转码服务的语音网关为了保证最大的兼容性，往往会将原来高品质的语音通话直接转码成G.711，这个是三四十年前使用的窄带标准，能保证最大的兼容性，所有话机和系统都支持，但是音质相应的也会变成窄带的了。
宽带的语音、窄带语音，以及房间的重混响，都会导致音质受损，而且我们发现重混响对人耳的影响跟整个音量大小有关系，当你觉得音量不适合或者过响的时候，那么在重混响的房间里音质可能会进一步受损，再加上卡顿或者嘈杂声等多种因素聚合一块儿的时候，基于VoIP的通话音质就会受到很大挑战。
2. 同地多设备入会挑战
在使用腾讯会议的过程当中，还会出现同地多设备的问题。在以前使用电话的场景下，大家基本不会碰到这样的问题，因为一个房间就一个电话，不存在多个电话、多个声学设备在同一个地方入会的情形。现在随着会议解决方案的普及，每个人电脑上面都能安装一个协同会议的客户端，大家习惯性带着电脑参加会议，分享屏幕和PPT内容。每个人都进入会议，把他的屏幕分享打开，一下子会发现，在一个会议室里面出现了很多个终端在同一个房间入会，同样多个声学设备在同一个地方入会，立刻带来问题就是有回声。
对于单个设备来说，可以捕捉到播放信号作为参考，进而解决回声问题。但是对于多个设备来说，比如我这台笔记本的麦克风处理程序是怎么也不可能拿到另外一个人的扬声器播放出来的声音参考信号的，由于网络延时和当时CPU的情况不一样，这么做是不现实的。所以通常只能在本机解决简单的回声问题，对同样房间多个声源设备播放的声音没有很好办法处理。稍微好一点的情况就是产生漏回声，差一点的就会直接产生啸叫。
腾讯会议有一个检测方案，我们利用多个设备互相存在的相关性，解决这样一个同地多设备入会的问题，下文还会详细展开。
三、AI技术提升会议音频体验
在腾讯会议里面，我们还采用了什么样方法，来提高用户的通话体验呢？
1. 音频领域的超分—频宽拓展
第一，我们在通讯会议里针对一些窄带语音，特别是来自PSTN的窄带语音，做了窄带到宽带超分辨率扩展。
因为传统的PSTN电话，音质频率上限是3.4KHZ，人耳的直接听感就是声音不够明亮，声音细节不够丰富，跟VoIP电话比起来，显得差强人意。借助AI技术，根据低频的信息进行预测生成，把高频的分量很好的补偿出来，让原来听起来比较沉闷，不够丰富的语音变得更加明亮，声音音质变得更加丰满。
2. 丢包隐藏技术
第二，借助人工智能解决IP网络里面临的丢包挑战，丢包这个问题本身有很多种解决方案，在传输层面可以解决，通过FEC方案在网络层面都可以解决。但是网络层面解决丢包问题本身局限性，不管是ARQ还是FEC方案都会伴随着带宽的增加或者是延时的增加，造成不好的体验。
在声学层面上，语音信号或者是语言帧之间是存在一定的相关性的。正常人说话的时候，一个字节大概时长为200毫秒，假设一秒最多说五个字，每个字段时长为200毫秒，对于我们语音帧来说，以20毫秒为单位时长进行编包。通过丢包隐藏技术，并不需要每一个包都要收到，丢的语音包只要不是特别多的像突发大批量的丢包，而只是零星的丢包，或者是网络抖动带来的丢包情况，都可以在声学上通过数字信号处理技术和机器深度学习的技术把这些丢包弥补还原出来。
这样在对语音帧的参数进行编码的时候，我们可以通过一些数字信号处理技术和深度学习技术把丢失的参数预测出来，在信号层面通过各种滤波器把丢失掉的信号合成出来，再跟网络传输层本身的FEC或者AIQ技术结合起来，可以很好解决网络上丢包和抖动的挑战。
3. 降噪语言增强
语音通信另外一个很强的需求就是降噪，大家都不想听到环境噪声，最想关注的就是语音本身。传统的降噪技术，经过了三四十年的发展，不管是基于统计学或者是其他的方法已经可以很好的解决传统平稳噪声的降噪，能够准确估计出平稳噪声。
但是对于现在常见的非平稳，突发的声音的降噪，经典的语音处理技术就相形见绌了。腾讯会议音频解决方案是利用机器学习方法来训练模型，不断学习突发噪声本身具有的特性，如噪声频谱特性等，最终很好的把这些传统的数字信号技术解决不了的如键盘声、鼠标声、喝水水杯声、手机震动声等等这些突发的声音消除掉。
4. 语音音乐分类器
另外会议需要考虑音乐的存在场景，比如老师给学生讲课，时常会做一些视频内容的分享，这个时候就会存在高品质的背景音乐出现。如果我们的方案仅仅能处理语音，却不能处理音乐，对我们的一些应用场景就会有比较大的限制，所以如下图所示，我们研发了这样的语音音乐分类器，能够很好的将背景音乐集成到会议音频中去。
四、音频质量评估体系
对于像腾讯会议这样支持上千万DAU的互联网产品来说，对于音频的实时监控和音质评估是非常重要的。我们在整个腾讯会议开发期间，很大程度上借鉴实施了基于ITO国际电信联盟对于通信音质的测试评估方案，如下图所示，在音质测试评估方案中，我们配备了标准的人工头，标准的参考设备，来对整体语音通话的音质进行测试和评估。
整套评估方案我们参考了ITU，3GPP的标准，对在不同的声源环境，不同的测试码流，不同的声源条件下，各种不同的测试场景都有完整的定义，对于单向的语音通话，双讲，消除漏回声，降噪，评估语音SMOS和NMOS分数都有相应的标准。
如何对腾讯会议处理过的音质信号进行打分，怎样判断音质是否满足要求？我们已经形成了一整套完整的语音质量评估体系，来对整个端到端的语音通信质量进行评估。
以前在整个语音通话过程当中，无参考的音质评估普遍基于QoS参数模型的评估方案，更多是从使用的编码器类型，通话过程当中是否有丢包，延迟多少，整个音质使用的码流是多少，这些点出发，再根据参数推导出整个通话过程中的音质是怎样的。
这种方案对于运营商或者网络规划部门比较有用，因为他可以拿到这些参数。对于用户来说，就没有那样的直观感受了。
对于用户来说，能直观感受到的就是：是否存在漏回声，语音通话是否连续，通话音质是否自然等等。对于用户来说更多会关注QoE角度，从个人体验角度来看整个通话体验是否得到满意。我们把QoE指标进一步细化，主要看通话过程中的嘈杂声程度，整个通话语音的色彩度（通话语音的自然度），是否有变声和机械音，或者其他听起来不自然的声音，以及整个通话过程中语音是否存在卡顿？
人讲话本身是有卡顿的，我说一个字后会短暂停一下再说下一个字。这种卡顿跟网络丢包和网络抖动带来的卡顿是有明显区别的，我们通过数字信号处理方案和机器学习技术从QoE这三个不同维度，对音频进行无参考语音通信打分，这样就能从现网上得知，用户使用的通信会议效果是怎样的。如下图所示，用我们的无参考打分模型，跟有参考的数据进行拟合，可以看出，拟合的程度非常高。
基于无参考语音通话模型我们对现网通话质量可以有较好的把握，不需要拿到具体某一个语音的参考信号，仅仅根据播放端收到的信号，就能知道通话质量现在是否正常，如果不正常问题大概出现在什么地方。
五、会议音频系统的未来展望
在会议音频领域，除了通话以外，还有关于会议转录的需求。
微软2019年年初宣布—Project Denmark，可以用手机和Pad采集不同会议讲话人的声音，并且把不同讲话人声音进行分离。我们知道，在一个会议室多个人同时说话，讲话人声音单纯用ASR进行语音识别是无法实现的。最理想方法是把不同讲话人分离出来，再分别接ASR的后端进行语音到文字的转换。
一旦语音转成文字以后，后面就可以做很多事情，比如生成会议纪要，对内容进行检索，可以邮件发出来给没有参加会议的人浏览观看等等。
思科也在做同样的事情，思科近期收购了一家公司，这个公司也是做会议内容转录。
但是会议人声转录这里面会存在几个问题：ASR识别。ASR识别提供了很多很好的语言识别解决方案，比如对方言的识别，对基础的专有名词的识别，ASR也提供了比较好的方案前后端进行调试。
对于同一房间多人开会的会议音频转录来说最大挑战是：如何在多人会议场景下对连续说话人进行检测和切换?假如我说话的时候被别人打断了，或者是两个人讲话的声音重叠在一起，这个时候怎么有效把声音进行切割分离呢?如果多人说话在时间线上不相关，这个时候切割相对是比较容易的，通过声音识别把不同讲话人识别出来就可以了。
但是如果他们说话有重叠的时候怎么进一步分离呢？包括切割出来信号怎么进行聚类，刚才讲了几句，后面又讲几句，中间又插进来一些别的人说话，怎么把我之前讲的和之后讲的话聚合到一起?这些相关的技术对于整个会议转录来说都是非常重要的，目前有很多公司也在这方面加大投入，腾讯也有在做这样的事情。
除了会议转录需求之外，整个VoIP技术也是在不断的演进过程当中。常常听到有人问:整个5G对于语音通讯意味着什么?有人觉得语音5G带宽那么大，语音通话带宽这么小，没有太大意义。
其实不然，5G其实会为VoIP技术提供更大更好的舞台。首先是带宽对于会议语音通讯的推动作用，虽然语音本身的带宽很小，只有几十kbps，但是对于会议音频来说情况远比这个复杂。会议当中除了传输语音之外，还可以传输高品质的音频，高品质的音频就不是十几K可以搞定的。会议讲话人也可能不只是一路，会议当中同时开麦就会有好几路产生，这种情况下对于会议音频的带宽消耗是很快的，在网络条件不允许的情况下就有可能导致网络拥塞。而5G一旦把带宽上限拉大以后，会为会议音频提供更大更好的舞台，我们可以提供更优质和更高品质的音质。
5G也可以极大改善延时，几百毫秒的延时其实很大一部分都是消耗在传输延时上，但是5G可以令传输延时降低到原来的十分之一，对于整个实时可交互性体验是很大的提高。
所以5G技术的发展，能为语音通话更好的声音体验，更沉浸式的体验。只要带宽不受限制，让在会议音频上实现基于AR、VR带来的沉浸式体验成为可能，当延时大幅度缩减以后，会议交互性也会更好。如果交互性能更进一步提高，其实跟人面对面沟通就没有太大的区别了，这就是技术带来的发展。
从整个商业角度来说，我们看到很多的变化正在发生。像融合通信，更多是作为service被越来越多场景使用，现在越来越少的人采用电话设备，都是采用云的方式，因为带来的初始成本降低是非常显著的。
人工智能技术未来也会为语音通讯带来越来越好的体验，如前文提到的智能降噪、智能丢包补偿技术就可以很好解决原来的一些问题，进而提供比原来PSTN网络更好的音质体验。
WebRTC技术也将会得到普及，WebRTC也有一整套的协议族，在浏览器里得到普遍支持以后，VoIP技术借助WebRTC能在很多场景里得到广泛的应用。因为VoIP技术得到广泛的普及，在In-app communications里的应用也会越来越多。
IoT领域VoIP技术也出现了上升趋势，家里的智能音箱、智能冰箱等设备未来都会带一些通讯功能，通过IP网络进行连接。
Smarter VoIP assistants技术也会得到更多的发展， Smarter VoIP assistants是基于VoIP通话过程中提供的人工智能语音助手，来解决通讯过程中的语音问题。
六、Q&A
Q：老师关于实时音视频通信可以推荐经典的书和开源项目吗？
A：WebRTC就是很好的开源项目，基于WebRTC书籍也有，在网络上搜索WebRTC也有很好的博客，关于WebRTC架构，里面核心的技术都有比较好的介绍，上网可以搜到。
Q：关于本地多设备的解决方案，能详细讲解一下吗？
A：本地多设备是这样，虽然本机的采集可以拿到本机的信号，从而可以做回声抵消，但是本地的采集是不可能拿到房间里面另外一个设备的播放信号的，这是同地多设备问题的核心所在。我们虽然不能拿到另外一个设备的播放信号作为参考，但是这个本地播放设备，跟同房间另外一个播放设备之间存在很强的相关性。因为他们都来自于同样的声源，只是经过不同的网络，不同的设备播放出来的时候，会有不同的失真和延时。所以我们不一定能做到同地多设备导致的啸叫或者回声抑制，但是一定做到同地多设备的检测，一旦检测同地多设备的时候，就可以用不同的产品策略来解决这个问题。因为同地多设备消除是非常困难，假如有三五个设备同时入会，打开麦克风，这简直就是灾难，要解决这个问题带来声学挑战对于CPU消耗会非常大，很不值得，所以做好检测就可以了。
Q：很多直播间都在使用WebRTC,老师谈谈WebRTC是否有发展前景？
A：WebRTC很有发展前景，它首先是开源项目。WebRTC在实时音视频传输的时候，特别是对于网络NAT技术，网络穿越技术解决方案上都有很独到的地方。WebRTC对于音视频本身的编解码，音频的前处理都有一些相关的方案，WebRTC在很多场景都是很不错的解决方案。
Q：重混响失音，怎么样提高语音清晰度?
A：第一是多通道采集。使用麦克风阵列技术，通过方向性，比如说我在这个房间讲话，我的声音经过墙壁和桌子反射以后会被麦克风采集，造成干扰。如果麦克风是阵列形式，就可以很好对讲话人进行声源追踪，尽量只采集我的直达声，而屏蔽掉来自墙壁和桌面的反射声，这样可以很好的解决重混响问题。对于单通道麦克风的声音采集，不管是经典的数字信号处理技术，还是机器学习都可以解决这个问题，但因为毕竟是一个过滤处理，有可能会导致音质受损，所以在单通道条件下去做混响处理，并不是一件很容易的事。
Q：VoIP和VoLTE相比，有什么优缺点？
A：VoIP和VoLTE走的思路不一样。VoLTE传输的音视频流，需要QoS保障，语音比较高，发生网络拥塞优先传输语音，数据可以等等，差几十毫秒没有关系。所以VoLTE一定是保证带宽，保证低延时的。从QoS角度来讲，VoLTE有一定优势，但是当5G带宽高速公路越来越好之后，会发现VoLTE和VoIP相比就没有太多优势了。随着未来5G的大规模普及，VoIP质量可以做得非常好。
Q：老师，出现卡顿时的具体解决的方法是什么？
A：出现卡顿具体解决方案有很多，关键要看卡顿的具体原因是什么。是网络导致的卡顿，还是设备本身导致的卡顿，如果是网络导致的卡顿就要看是网络丢包导致还是抖动导致的，FEC技术可以解决一定的丢包问题，如果是抖动过大，就把Jitter包放大一点，虽然延时受损，但是可以解决抖动带来的卡顿。如果是设备本身有问题，可能是CPU占用率过高，调度不过来。有时候信源也会导致卡顿，比如我突然转过头说话，麦克风定向采集我的讲话声音和原先声音不匹配，这个时候就会突然听到声音变小，后台音效处理也会出现卡顿，所以卡顿原因比较复杂，需要分析原因有针对性的加以解决。
Q：大型直播，比如赛事比赛，发布会等直播，主要是用hls、flv等，5G时代是否可以用WebRTC技术呢？
A：两个场景不一样，直播的时候可能会跳动，或者VOD播放的时候如果延时比较大也没有关系，延时超过200毫秒，500毫秒，甚至1秒都没事，直播虽然晚一秒也不妨碍观看和体验。但是实时语音通信就不可以，超过300毫秒，甚至打电话1秒之后才回过来这肯定不行。我不觉得它们会用RTC技术，它们还是会用RTMP推流，或者HLS切包发送这样的技术，因为虽然会带来延时，但是在网络抖动处理，包括其他很多方面都能处理得更好。所以适用的场景不一样，未来做不同技术的考虑点也会不一样。
Q：同地多设备没有办法拿到其他设备的参考声音，通过什么办法做到回声消除？
A：同地多设备是没有拿到其他设备的参考声音，但是实际上采集声音之间还是存在一定的相关性的，在算法上可以做出判断和处理。
Q：深度学习算法对于音频前处理相对于以前传统的方法有什么区别？
A：有区别，传统的数字信号处理方法在不同的场景下很难做到精准的定位，比如一些传统的数字信号处理技术，对于突发的噪声没有很好的处理办法。但是这种非线性的声音用深度学习算法可以处理得很好，在拟合的时候能够把传统方式处理不好的问题，如残留回声、突发噪声、降噪问题包括聚合的问题更好的解决。
Q：腾讯会议是在WebRTC框架吗？
A：不是，腾讯会议不是在WebRTC框架下开发的。
Q：IoT应用就是智能家具产品应用吗？
A：是，越来越多智能家具会使用IoT技术，如智能音箱等未来更多也会集成语音通信的技术。
Q：语音问题是一直存在的，很好奇腾讯会议是通过什么来收集和了解到那些问题的？一个在线的视频语音产品怎么监测用户语音的视频质量？
A：我们需要无参考语音评估系统，有了无参考语音评估系统，就可以知道现网通信当中的语言质量是怎么样的，是否存在问题，是什么样的问题，问题出现在哪个区域、哪个时间段，或者发生在哪个外设上等等。
Q：对声源定位，麦克风阵列有什么好的分享吗？
A：声源定位，麦克风阵列上有很多技术可以做，如DOA技术，麦克风阵列技术，传统算法都是用来做语音信号处理的，上面有很多引申的技术发展出来，具体可以参考谷歌上的详细介绍，回答得更有深度，我这里粗粗介绍一下。
Q：音频质量的主观、客评估手段用哪个参数来评估比较合适？
A：主观评估就是召集人来打分，对于客观评估，ITO对应有一个P863标准，参考这样的语音标准对客观指标进行打分，可以更进一步评估噪声卡顿，语音质量等。
Q：老师，关于丢包处理补偿处理，之前学校通信课程上老师有讲过交叉帧处理的方式然后让丢失的包分布在各个帧，利用帧数据之间的关联来补偿丢包？腾讯会议的丢包处理也是类似这样的处理吗，深度学习处理的大体思路是什么呢？
A：学校老师在课堂讲的是针对突发大丢包的情况，把包分散到各个不同分组里面，收到组里面突发丢失的那一块以后可以通过FEC技术将收到包复原出来。和这里不太一样，分组交织可以解决一定的丢包问题，但是代价是延时过大，你把一个包或者多个包分到不同组，交织开来，收集的时候必须等所有包都收集完以后，才能把语音流复原出来，这样就会带来语言延时过大的问题。
Q：穿透转发服务器搭建方面，腾讯能提供服务吗？
A：关于WebRTC提供的穿越技术，腾讯云也提供解决方案，但是腾讯会议使用的相关技术是供腾讯会议使用的，如果在你的解决方案里需要腾讯云提供针对网络穿越的NAT相关技术，是可以做到的。
Q：请问质量评估是否可以这样做：本地进行抽样，然后异步传送（因为不需要实时，所以可以直接用TCP发送）给服务端，服务端对同样区间的实时音频流的数据进行抽样，来作对比。
A：在测试过程当中可以做，在现网当中当然也可以做，但是本身抽样会有很大局限性。像腾讯会议这样千万级DAU的产品，不太可能进行抽样，抽样对于评价现网也有很大局限性，我们更多建议通过无参考质量评估的手段搭建模型，对现网所有的数据进行实时评估。
讲师简介
商世东，腾讯多媒体实验室高级总监，于2019年初加入腾讯多媒体实验室，担任多媒体实验室音频技术中心高级总监。加入腾讯前，商世东于2010年组建了杜比北京工程团队，任职杜比北京和悉尼工程团队高级总监9年。加入腾讯后，带领多媒体实验室音频技术中心，负责实时音视频SDK中的音频引擎，音频处理的设计和开发工作。
关注云加社区公众号，回复“在线沙龙”，即可获取老师演讲PPT~
来源：oschina
链接：https://my.oschina.net/qcloudcommunity/blog/3210651