Cisco WebEx：企业协作服务中的音频需求

在LiveVideoStack线上交流分享中，Cisco资深音频算法工程师高华基于思科的企业协作服务产品实践，分析整理了协作服务中遇到的音频需求，详细介绍了思科WebEx meeting 中的音频方案——WebEx Media Engine (WME)。

文 / 高华

整理 / LiveVideoStack

直播回放

https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=faac0d5d64b84d4a86fbfd5d4befa468

大家好，我是来自思科的高华，在音频算法和视频会议应用开发方面有10余年经验，精通VoIP引擎的设计、开发，擅长麦克风阵列、算法性能优化等。接下来我将为大家分享的内容主要是关于企业协作服务中的音频需求。

核心内容分为以下三个部分：

• Cisco WebEx音频方案发展历史

• Cisco企业协作中音频需求的演化

• 音频引擎介绍

首先从Cisco WebEx音频方案发展历史开始。Cisco在2007年的时候收购了一家做Web Conference的SAAS服务公司 —— WebEx 。在2010年之前，WebEx一直使用GIPS作为VoIP引擎，它在2010年的时候被Google收购，开源后就变成了现在的WebRTC。在Google收购GIPS之后，WebEx与GIPS的合同也随之到期，于是在2010年成立了现在的音频团队。音频团队成立之初，是以当时GIPS的一些文档和API为基础开始制作自己的音频引擎，到2011年5月份WebRTC实现开源之前，我们已经开始为PC版本的内测以及上线做准备。与WebRTC存在着一个时间差，可以说我们是自行研发出的这款音频引擎。2012年WebEx的音频引擎正式上线，然后着手Mobile版本的开发。Mobile版借鉴了WebRTC当中相对成熟的算法模块AECM。到了2014年，Cisco对于音视频有了新的规划，就像WebRTC一样，将整个Media打包成一个统一的MediaEngine。这个MediaEngine就成为了Cisco未来的一个战略方向。之后所有Cisco软件上的需要Media实现的产品都由MediaEngine来做支撑。 以上就是WebEx音频方案的发展历史。

在近十年发展过程中需求方所提出的需求也是有比较多的变化。比如像2010年刚成立的时候，主要面对的需求针对的是WebEx。和现在所有的VoIP需求一样，对于声音方案的要求是在不同平台上的采集、3A处理以及Codec，JitterBuffer等。还有一个叫做SVS的应用，是指支持多媒体文件在线共享。由于当时只有一个WebEx的应用，它的所有需求只要做到和VoIP一模一样就好，并没有演化出一些应用上更为复杂的需求。但是随着Cisco协作产品的出现，需求也开始慢慢发生变化。Cisco协作是企业协作平台，WebEx则是企业协作产品中一个重要的部分，并且在企业协作当中会有更多的其他产品加入。

现在的Cisco WebEx不再是一个简单的Web Conference产品，它已经被定义成一个全新的品牌，相当于Cisco的企业协作都在WebEx这个品牌之下。在2014年的时候Cisco开始重新做下一代IM和Meeting Cloud的集成应用-Teams；Meetings即最初Cisco的WebEx Web Conference应用；Calling是Cisco收购的一家叫做Broadsoft的公司，提供Cloud Base的PBX应用，解决的是电话服务的问题；Jabber是一种的Cisco的企业IM通信应用；Devices就是包括了Cisco的IPPhone以及TP这样设备的硬件，基于硬件连接的一些通信服务的设备。Openplatform是向第三方开放并且能够接入Cisco协作方案的平台。在这些产品中，有Teams，Meetings和Calling三款APP的产品都已经应用了最新的Audio engine。

因为Cisco有三款APP采用了WebEx Media Engine， 就存在某些用户同时安装和运行这三款APP的可能。每一款APP都通过WME（WebEx Media Engine）实现audio的各种功能。这其中就会遇到一些新旧需求的融合问题。例如，在同一个OS上运行着的三个APP，同时在启用Cisco proximity的需求，它是利用基于超声通讯进行连接在同一个房间内的TP或者其他的一些桌面视频设备；与此同时，还有可能在进行VoIP call的需求；以及call 的过程中有multiple-call的需求，即表示和A通话的过程中，B的电话进来了，那么此时你需要先把A挂起，再接入B，也有可能把A和B同时升级到Call conference的需求。 这些需求都是我们音频解决方案当中需要考虑和解决的问题。这些需求是由于协作产品的扩容以及产品本身多样性所带来的需求变化。

接下来介绍WME， WebEx Media Engine，类似于WebRTC中MediaEngine的一个定义。它主要的一些功能，我们列在这里。它主要对Application提供Connection以及SDP协商，超声接进功能，以及一些声学事件检测等功能。声学事件检测是在应用过程中有些客户提出需求，例如说在家中开会（主要是面对的是欧美客户），他们养的宠物的叫声，社区里面有一些警报声，还有像键盘敲击声之类的噪声，这些都统一被我们归类到Soundevent的声学事件检测当中；Ringtone它是一个比较泛的类，它的需求除了Call过程中的铃声播放，还包括语音信息，DTMF等。MediaTrack这一层更像是WebRtc中MediaEngine，它会把Video，Audio等部分放在一起。对Audio相关的部分提供了Device Manager， Codec管理，还有3A Processing设置，以及对AV synch的支持，以上都被我们放在了WME框架里面。

继续深入看Audio的这部分方案，这是最新设计的audio Architecture。针对前述的应用需求，主要分为Ringtone，ultrasound 、Sound event，还有VoIP。这张ppt主要介绍的VoIP的实现。我们在audio engine中设计了realtime block和 unrealtime block，中间利用DataInfobus 进行数据共享。realtime的部分是传统的VoIP这部分，这样做是源于一个假设，也就是实时VoIP应用是需要尽量减少其他会产生阻塞的操作，如数据处理或者信息统计等。相当于把这些做成了两个独立的处理，通过DataBus把实时性处理过程当中可共享的一些数据直接共享给非实时处理。比如像sound event的检测和ultrasound的检测，就共享了实时处理的中间结果，运行在其他线程，因为它们可以承受更高的Delay。针对VoIP的需求， 提供了Device的管理；Codec的管理；Transport的管理； Channel的Interface管理，它的管理主要是Process和3A处理参数的设置管理上。这里的Channel和WebRtc的Channel不太一样，这个Channel是有固定职能的Channel实现。现在主要分了三种Channel，第一个RecordChannel，就是采集到发送的实现，里面包括AEC和NR，AGC处理。Playback channel是对接收的所有数据处理，包括VoIP和音频的共享数据流。Broadcastchannel是多媒体文件的音频发送处理。

这张ppt是非实时处理的介绍。这部分主要包括是Engine State、Statistic model、Metrics、Proximity 和Sound event. Engine State和Statistic model用于VoIP中audio运行的健康状况等统计。Metrics是整个Cisco协作产品中的服务监控数据，在会议结束后上传到云端。利用Metrics信息去做大数据集，通过大数据去管理。然后通过监控数据监测整个服务产品的稳定性。目前来说监测的主要方向还是在网络和应用信息，因为通过经验判断目前遇到的问题80%以上都是出在网络层造成音频质量下降，还有剩下一半以上就是Device、噪声的等问题。Device的问题是最难解决的一类问题，主要原因是它难以监测。Proximity就是刚才所说的，主要的检测TP等视频设备来发送超声的信息。Sound event是针对用户所在的一个场景，比如说他们在家中开会时有宠物的叫声，对这种声音做一个检测，提示用户您当前的使用场景中有一些噪声在里边。

刚才提到，在同一个APP中，会有多种设备访问以及音频采集的需求。比如，在同一个APP里面，可能在VoIP call 中，有可能有另外的一个call 连接进来，这时候就要播ring tone; 或者在播Ringtone过程中，也有可能会进来一条Audio message，需要播放这种Audio message的信息。在此时就有了一个新的需求，即在同一个APP当中，不同的应用会访问不同的底层的AudioDevice，对不同的AudioDevice去做播放采集的处理。由于在Cisco里，Client team 和 media team不是在同一个BU，就有可能造成了在client的Design和我们预期的Design完全不一样。 因此其中之一的解决方案是学习系统层的一个AudioEngine。 这张ppt是微软提供的AudioEngine的一个构架图。我们的应用和系统层的AudioEngine是很相像的。对于系统层的AudioEngine就要支持整个Application层的多种App，他们会在同时访问到Hardware需求。基于对他们的构架做的一个学习，提出我们的一个方案。

这张ppt就是应用层对多device同时访问需求的解决方案。Session1，Session2，Session3，是在同一个APP中的不同种类的需求。比如Session1，是单纯的一个Play需求，它需要的访问是在DeviceA（Speaker）。Session2 代表UoIP通讯， DeviceB是一个USB device，USB device正被用于VoIP通讯。Session3是超声检测，通常会同时对多种设备进行访问，即同时进行检测。我们会在不同的Session中构建不同的MediaEngine，在下一层的Audio部分则需要做成统一的Audio Engine，以支撑不同的Session需求，也相当于是做单例实现。接下来就可以通过同一个Audio engine支撑不同的Device访问。这就是从系统层的实现构架中学习之后构建出的实现方案。

以上就是本次分享的主要内容。总结一下，本次分享中主要介绍了Cisco协作系统中音频需求的演化，演化主要是指Audio Engine在Cisco的协作产品中不同的时间段，对不同协作产品的支持，以及在同一个协作产品当中像TP、电话或者是multiple call 这样一种新的应用需求的支持。这些需求对audio的构架提出了一些新的挑战，相应的audio engine进行的一系列改进演化。

LiveVideoStack  招募

LiveVideoStack正在招募编辑/记者/运营，与全球顶尖多媒及技术专家和LiveVideoStack年轻的伙伴一起，推动多媒体技术生态发展。了解岗位信息请在BOSS直聘上搜索“LiveVideoStack”，或通过微信“Tony_Bao_”与主编包研交流。

点击【阅读原文】，了解更多大会讲师及内容信息。