webrtc技术详解(webrtc技术架构)

开放互联网和现代计算机的形成例证了科技开放驱动创新成长的能力。HTTP 协议大概是有史以来最伟大的发明之一，计算机可以通过 HTTP 协议从服务器请求和接收数据。

不幸的是，这些创造者们当时没有想到创造异步数据流和实时通讯，因为这些功能当时被电信供应商所掌控，他们基本上已经掌控了声音、视频和讯息的分发业务，不过现在，新的 web 标准将会开始打破这一传统商业模式。

多种浏览器支持WebRTC

随着 WebRTC API 标准的形成，电信企业通信的局面正在发生变化。这个标准以及它快速成长的生态系统使得开发者无须具备任何复杂的通讯技术和协议的经验就可以轻松地在他们的应用中集成实时通信模块。

WebRTC API标准形成开启通信时代新变化

能如此轻松地开发将会孕育出大量新的革命性应用，而这一切将会改变我们通信、交换信息以及相互交流的方式。

何谓 WebRTC

图-3 WebRTC强大功能

WebRTC，是终端的音视频媒体访问（输入输出）接口在类似web环境下的标准化抽象，以及用于实时通信的会话的建立过程、终端音视频媒体（或其他数据）编码格式、传输方式和参数的描述和协商规范。故此说，WebRTC并不是一个“解决方案”，也不囿于某一种实现的代码库，而是一种标准规范，那么无论具体实现方式如何，只要该实现符合该标准规范就应该可以互联互通、拥有实时通信的能力，这也是WebRTC最本质的意义。

图-5 WebRTC本质

基于这种规范，形成不同的WebRT开源项目，可以在浏览器中不借助任何插件进行实时通信。由 Google、Opera 和 Mozilla 主导的这开源项目允许开发者在浏览器中仅使用 JavaScript API 和 HTML5 就可以将声音、讯息和视频融为一体。

图-6 WebRTC技术架构

WebRTC提供了音视频通信的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android, iOS等。WebRTC中的任何的一个技术点都可以拿出来列一个专栏进行讨论，

WebRTC开源框架，技术要点，如下面概述介绍。

1. 视频相关视频采集(video_capture)，源代码在webrtcmodulesvideo_capturemain目录下，包含接口和各个平台的源代码。在windows平台上，WebRTC采用的是dshow技术，来实现枚举视频的设备信息和视频数据的采集，这意味着可以支持大多数的视频采集设备；对那些需要单独驱动程序的视频采集卡（比如海康高清卡）就无能为力了。视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。
2. 视频编解码(video_coding），源代码在webrtcmodulesvideo_coding目录下。 WebRTC采用I420/VP8编解码技术。VP8是google收购ON2后的开源实现，并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。
3. 视频加密（video_engine_encryption），视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。

图-7 基于WebRTC开源框架

4. 视频媒体文件（media_file ），源代码在webrtcmodulesmedia_file目录下。该功能是可以用本地文件作为视频源，有点类似虚拟摄像头的功能；支持的格式有Avi。另外，WebRTC还可以录制音视频到本地文件，比较实用的功能。
5. 视频图像处理（video_processing），源代码在webrtcmodulesvideo_processing目录下。视频图像处理针对每一帧的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。

图-8 通信交互方式

6. 视频显示（video_render），源代码在webrtcmodulesvideo_render目录下。在windows平台，WebRTC采用direct3d9和directdraw的方式来显示视频，只能这样，必须这样。
7. 视频网络传输与流控 对于网络视频来讲，数据的传输与控制是核心价值。WebRTC采用的是成熟的RTP/RTCP技术。
8. 音频相关，ebRTC的音频部分，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。

图-9 媒体库类型

9. 音频设备（audio_device), 源代码在webrtcmodulesaudio_devicemain目录下，包含接口和各个平台的源代码。在windows平台上，WebRTC采用的是Windows Core Audio和Windows Wave技术来管理音频设备，还提供了一个混音管理器。利用音频设备，可以实现声音输出，音量控制等功能。
10.音频编解码(audio_coding), 源代码在webrtcmodulesaudio_coding目录下。 WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。 WebRTC还提供NetEQ功能—抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。另外一个核心功能是基于语音会议的混音处理。
11.声音加密(voice_engine_encryption), 和视频一样，WebRTC也提供声音加密功能。声音文件该功能是可以用本地文件作为音频源，支持的格式有Pcm和Wav。同样，WebRTC也可以录制音频到本地文件。
12. 声音处理(audio_processing), 源代码在webrtcmodulesaudio_processing目录下。声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)、静音检测(VAD)处理等功能，用来提升声音质量。
13. 音频网络传输与流控 ，和视频一样，WebRTC采用的是成熟的RTP/RTCP技术。

主要的 WebRTC 组件包括：

getUserMedia – 允许一个 web 浏览器连接设备的摄像机和麦克风
peerConnection – 建立音频 / 视频呼叫
dataChannels – 允许浏览器点对点共享数据

开发者能够借助简单的 web 技术将实时通信集成到他们的应用中，使会话场景更富有弹性。在移动 app 或 web 浏览器具备发起和接受实时通信的能力可以为用户创造一个更好的交流环境，提高信息交换的效率。WebRTC 支持一个更加动态的生态系统，在这个系统中声音和视频通信与现有协议解耦，带来新的体验。这项技术第一次出现是在网站或 app 中的点击呼叫按钮，如若不详可以调研 Amazon 的紧急呼叫按钮。

图-10通信模式

目前WebRTC标准刚刚尘埃落定，提供了一些标准以促进创新，还存在各家浏览器厂商的现有WebRTC实现与规范不完全相符的情况，会多少存在某些应用场景下互联互通的问题，在2019年，各家浏览器新的版本也在持续完善现有实现以向标准看齐。在2018年以前，手机移动Android 和 iOS系统原生支持WebRTC标准支持有些问题，随着这几年的发展，新的操作系统对于WebRTC的支持，越来越普遍。

工具和服务供应商

随着标准的发展，许多厂商已经进入这个市场来填补生态系统的缺口，并帮助移动和 web 开发者将通信模块集成到他们的项目中。这些厂商为支持移动端实现提供了通过 RESTful API 集成通信服务的功能，并且提供了 SDK。除了提供连接服务，这些厂商同样也能够在云端为开发者提供便于访问的基于通讯的服务。

图-11 不同浏览器跨越通信

无论是通讯 API 供应商还是云 RTC 服务都在迅速成长并吸引了一大批竞争者。尽管所有的供应商都为市场带来连接和通讯功能和相关服务，但是厂商由于种种特质被区分开来，比如相互连接性和通话质量，或者是功能弹性和实现难度。诸如 Plivo、Twilio、Nexmo、Tropo 和 Telestax 这样的公司竞相与运营商建立联系，与此同时，诸如 Genband、Acision、Temasys、Voximplant 以及 Bit6 这样的公司专注于打造更强大的 SDK 和更富弹性的服务。

低垂的商业果实谁能摘到？

随着云通信领域的新工具和新技术获得青睐，开发者并没有等待 WebRTC 最终定稿，他们正在紧跟标准的脚步积极实现。现今开发者享受着易于实现的案例，正如顺手摘下低垂的果实一样简单，不过依然没出现真正的创新。

客户关系管理合作是第一个利用云通信的应用。如果销售和服务代表可以在 CRM 应用中便捷地拨通客户电话，生产力就可以显著提高。而 WebRTC 恰巧可以轻松地将客户信息和通话组合在一起。拨入的电话可以自动匹配客户信息，显示账户的细节和相关历史。如果客户通过网站拨入电话前已经验证过身份，那么服务代表就可以跳过恼人的重新验证过程来提升客户体验。WebRTC 规范中声明的点对点共享技术标准同样也支持服务代表与客户共享他们的屏幕。所有的这一切过程无须客户离开浏览器或下载附加软件。

图-13 广受欢迎贵于商业价值

尽管几年前就可以共享屏幕，但 WebRTC 带来的体验对于开发者和客户来说更易上手。开发者可以利用自己的 web 专长创造这些体验，他们无须理解通讯技术和协议就可以发起呼叫或管理数据流，这使得开发者可以创建适合自身需求和业务的自定义体验。金融服务垂直领域正在为他们复杂的产品快马加鞭地实现云通信功能，他们与客户的关系建立在相互信任的基础上，通过更近距离的交流以及更好地理解产品和需求可以树立相互的信任，因此金融服务企业成为了这项技术的先驱拥趸。

打破传统通信诸侯各自为政

图-14商业应用无孤岛

很长时间以来，实时通信能力一直是电信类专用设备（如电话、手机）的专有属性。随着各种互联网应用和移动互联网应用的层出不穷，特别是随着用户接入带宽条件的不断改善，许多新的应用都对实时通信服务有着切实的需求，希望能够把实时通信能力集成到应用程序中。其实很多终端设备都具有实时通信的潜力的，但是在WebRTC之前，没有一个统一的工业标准来描述一个设备的实时通信能力和连接建立过程。在对实时通信能力的需求特别迫切的应用（如微信、WhasApp、FaceTime、Messenger等等）中，大家各做一套，“七国八制”，完全不能互通。

图-15 通信架构

WebRTC最大的优势就是“标准化”，它解决的问题就是给所有需要进行实时通信的终端提供一套统一的、开放的实时通信能力描述和连接建立标准。只要符合WebRTC的规范，通信终端的形态和运行环境就是透明的（看不见也不关心），大家都可以用同一种“语言”进行“交谈”。WebRTC对音视频的编码格式（codec）、传输方式和协商过程做出了明确的规定，原则上所有支持WebRTC的终端，在互操作性上将不存在障碍。目前各大浏览器厂商都积极参与到WebRTC技术的生态中，从web应用开始，WebRTC将成为基于网页的音视频实时通信技术规范将。之后，在web应用于移动终端应用的交互需求驱动下，越来越多的移动应用的音视频服务也将采用WebRTC的技术规范。

图-16 多样的商业化场景

更好的弹性也弱化了不同模式通信之间的隔离。随着对话的发展，需求不断改变。对于 WebRTC 而言，你可以使用一个文本 URL，将一段文字交流转变为一通电话或者视频对话。拨入呼叫中心的电话也可以通过整合不同形式的通信手段提高效率。在一个支持用户使用可交互自动应答语音树进行导航的网站或 app 中，当你打电话与之交互时会显示文字菜单，大可不必再耐心听完所有选项。

知己知彼有所为而有所不为

图-17 成熟的商业化环境已经具备

终端具备具备天时，首先当然要让终端具备WebRTC能力。如果终端运行环境是浏览器，目前绝大部分浏览器都已经实现了对WebRTC的支持（其中Safari和Edge的支持还在持续完善中），虽然彼此有一些差异，但是可以借助adapter.js等适配层屏蔽掉这些差异。如果终端运行环境不是浏览器，则可以采用其他的开源SDK或商业SDK，将其集成在终端应用程序中。当然也可以基于Google的开源WebRTC实现的Native代码进行裁剪或移植。值得一提的是Google的开源WebRTC代码库中有大量的终端多媒体问题和传输问题的应对方案的实现，包括音视频的编解码、同步、带宽预测、QoS，AEC等，都是做终端（特别是IoT设备或桌面环境应用）开发时很好的参考。

图-18 订阅模式在转换中的应用

互联互通依赖于调度，终端实现了WebRTC只是表示它具备了实时通信的能力，但各个终端任然是孤立的，需要将各个终端的SDP进行交换才能让它们完成媒体和传输的协商才能让各个终端之间真正通起来。WebRTC并未就各个实现之间交换SDP的传输方式以及终端的“寻址”方式做出规定，这跟具体应用场景和其实现方式高度相关。因此要实现基于WebRTC的应用还需要一些“额外”的工作，通过一个各个终端都“认识”并能“找到”的“中间人”来进行SDP交换。譬如最简单的“1对1”呼叫的场景，这个“中间人”就是信令服务器，这种WebRTC的信令服务器可以基于任何消息系统构建，有很多开源实现可以利用或参考，自研开发也并不复杂。

图-19 不同的类库

如果要基于WebRTC做对多的实时通信应用，则情况要复杂一些，具体的做法也会因实际应用场景而不同，根据通信终端之间的媒体流拓扑结构，大体上可以分为Peer2Peer（终端点对点连接）模式、MCU（MultipointControl Unit，服务器混音混流）模式和SFU（Selective Forwarding Unit，服务器选择性转发）模式。

1. Peer2Peer模式（又称Mesh模式），所有参与方均需与其他所有参与方通信的情景的特征是呼叫中每两个需要进行通信的参与者之间都建立起点对点的音视频媒体连接（PeerConnection），所有的音视频媒体连接都是终端之间的（有可能通过TURN服务器进行NAT穿越，但不影响本质流拓扑），服务器侧不参与。

图-20 Peer2Peer模式

Peer2Peer模式，优点：是媒体拓扑去中心化，服务器简单（也可以称为不需要服务器），只需要将各个终端之间的信令交换送达即可；缺点：是终端需要受理多路媒体流的收发，对客户端要求比较高，随着呼叫中参与方数的增加，媒体连接数会阶乘函数式增长，无论对终端的编解码计算力还是带宽资源都会带来巨大的压力。如果一个呼叫中参数方数很少（譬如大多数时间2方偶尔3方），则可以考虑选用Peer2Peer模式的服务器侧实现方案。

2. MCU模式，是服务器混屏，也就是通过中间的多点控制单元收集各方传来的音视频数据并发送至服务器，由服务器将多路音视频信号整理合成为一路包含所有画面的音视频流并传输给每一个用户，每个节点仅与多点控制单元进行数据交换，所消耗的带宽与运算资源也会明显减少；当然这样做相当于是把包括编解码在内的大量运算任务交给服务器完成，这就要求服务器集成CPU与足够的带宽资源。

图-21 MCU模式

MCU模式，优点：节少了对接，对于客户端性能要求稍低；缺点：对于服务器硬件性能要求很高，服务器具有足够的带宽资源，服务器处理后对延时有一定影响，视频显示方式不是太灵活有一定难度。

3.SFU模式，是对Mesh和Mcu两种模式的折中.SFU模式也就是选择性转发单元是第三种实现视频会议的方式。如下图展示的那样，如果有五方进行视频会议，首先所有人都需要将自己这段的音视频信号传输至中间的选择性转发单元，SFU会按照会议需求选择性转发信号至每一个用户。

图-22 SFU模式

SFU模式，优点：相对于MCU，不处理编解码任务的SFU节省了一部分CPU运算资源对服务器要求没有那么高，稳定性较好；缺点：对于带宽消耗明显提高。

基于常见软交换（例如Freeswitch)框架模式

如果具体来说MCU在软交换中的作用便是如图-23展示的那样：黑色箭头代表下发，红色箭头代表上行；假设这里有四台设备分别输入的画面为1、2、3、4，现在我们将这四路画面传输至软交换的MCU设备，经过MCU的缩放、拼接、合成一路等一系列处理，我们得到了一个由四方画面拼接而成的会议画面；此时每个用户看到的画面都是视频融屏后的结果，同时看到四个画面且完全一致。

图-23 MCU应用模式

多画布是软交换的另一项功能，此功能多用于大型会议现场。有些应用场景需要主讲人与观众看到两个不同的画面，例如讲师看到的是观众的反应而观众则看到的是演示文稿或者会场实况，这就需要构建两个画布或多个画布，按照每位观看者的需求向其投送需要的画面。

图-24 MCU多画布应用模式

集群也是软交换上较为常用的功能，实现起来也比较复杂。集群多用于扩展会议规模，当然这需要多台服务器的集中处理。

图-25 MCU集群应用模式

拥抱创新开启通信新体验

图-26 应用模块组合

作为终端技术规范，虽然WebRTC只是实时通信解决方案中的一部分，但是是最贴近用户的一部分，也许也是最重要的一部分。终端技术规范的标准化，是一个很好的开始。连一向以封闭的技术生态闻名的Apple都拥抱WebRTC了，将促进WebRTC技术的发展和普及，会有越来越多的互联网（和移动互联网）应用基于WebRTC构建其实时通信服务。

图-27 多种商业场景

进入2019年，在互联网快速发展的当下和将来，WebRTC将极大激活人与人、人与物、物与物（IoT）之间的信息纽带，移除掉通信终端之间的时间（实时）和空间（基于互联网）的障碍，成为应用场景创新的一道强大的技术保障。同时，类似VR、AR、自动驾驶等新的应用场景的出现也会给WebRTC技术带来新的需求和动力，应用场景的商业化成功也将给技术发展持续注入活力和物质资源。譬如近年来直播连麦、网上课堂、远程控制（抓娃娃机）等基于互联网的视频应用的猛烈发展和火热，一次次催动着基于互联网的的实时音视频通信技术的发展，呼唤着WebRTC这样的统一、开放、透明的标准规范成熟和落地。

图-28 多方视频通信场景

想象一下，在基于WebRTC构建的世界里，所有通信终端的媒体描述和连接建立过程都是一致的，只要终端之间开放媒体协商的通道，就可以建立起实时通信，微信与WhatsApp能建立视频通话，就像你在中国用手机跟美国的朋友家中的座机打电话一样。那多美好！推动这一天的早日到来难道不也是我们互联网音视频通信工作者们的历史责任吗

图-29 多商业化应用

让 WebRTC 和云通信得到主流支持的一个真实挑战是，开发者对实现通信有预先形成的概念。电话通信自被发明以来，使用体验并没有显著改变，用户需要拨打电话号码发起呼叫然后等待对方接听，大众化的通信将引领一个新的创新浪潮，那带来的电话通信体验将远超我们的想象。缓步增量的创新可以引领业界不断前行，去探索我们未知的世界。开放基于自身不断驱动着创新创造。

刘一道整理及部分改编