2017年，苹果宣布将在iOS 11中支持WebRTC，至此完成了主流PC浏览器、移动端的全覆盖，而其提供了一整套完备的音视频通信方案，这给开发者带来了巨大利好。英特尔协同通信解决方案架构师段先德针对WebRTC的能力、优势与不足、开发要点及未来发展几方面进行分析。本文是『WebRTC-互联网音视频新标准？』系列的第一篇，如果您对WebRTC技术的未来有分析和洞见，欢迎联系 contribute@livevideostack.com。
文 / 段先德
策划 / LiveVideoStack
2017年，随着微软和苹果表态在其浏览器或系统产品中对WebRTC技术的支持，以及WebRTC 1.0标准的定案，WebRTC的话题越来越多地出现在广大互联网行业开发人员的视野中。很多同学对WebRTC的背景、目的、意义以及限制其实并不明白，加上媒体上各种吹捧和质疑的声音互相掺杂，对WebRTC这项技术的应用前景和开发难度没有切实的判断。本文希望通过对WebRTC技术的粗浅梳理，为大家提供参考。
WebRTC是什么？能做什么？
很多人期望WebRTC是一个“拿来即用”的“端到端解决方案”，只需要在web端写几行JavaScript调用甚至不需要编程就能实现浏览器之间的实时音视频通信。也有很多人把WebRTC等同于Google在其Chromium工程中的开源实现。其实这都是误解。WebRTC并不是一个“解决方案”，也不囿于某一种实现的代码库。WebRTC是终端的音视频媒体访问（输入输出）接口在类似web环境下的标准化抽象，以及用于实时通信的会话的建立过程、终端音视频媒体（或其他数据）编码格式、传输方式和参数的描述和协商规范。既然是一种标准规范，那么无论具体实现方式如何，只要该实现符合该标准规范就应该可以互联互通、拥有实时通信的能力，这也是WebRTC最本质的意义。
WebRTC虽然冠以“web”之名，但并不受限于传统互联网应用或浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备（Android或iOS）还是IoT设备，只要IP连接可到达且符合WebRTC规范就可以互通。这一点释放了大量智能终端（或运行在智能终端上的app）的实时通信能力，打开了许多对于实时交互性要求较高的应用场景的想象空间，譬如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。
WebRTC有什么优势和不足？
很长时间以来，实时通信能力一直是电信类专用设备（如电话、手机）的专有属性。随着各种互联网应用和移动互联网应用的层出不穷，特别是随着用户接入带宽条件的不断改善，许多新的应用都对实时通信服务有着切实的需求，希望能够把实时通信能力集成到应用程序中。其实很多终端设备都具有实时通信的潜力的，但是在WebRTC之前，没有一个统一的工业标准来描述一个设备的实时通信能力和连接建立过程。在对实时通信能力的需求特别迫切的应用（如微信、WhasApp、FaceTime、Messenger等等）中，大家各做一套，“七国八制”，完全不能互通。
WebRTC最大的优势就是“标准化”，它解决的问题就是给所有需要进行实时通信的终端提供一套统一的、开放的实时通信能力描述和连接建立标准。只要符合WebRTC的规范，通信终端的形态和运行环境就是透明的（看不见也不关心），大家都可以用同一种“语言”进行“交谈”。WebRTC对音视频的编码格式（codec）、传输方式和协商过程做出了明确的规定，原则上所有支持WebRTC的终端，在互操作性上将不存在障碍。目前各大浏览器厂商都积极参与到WebRTC技术的生态中，从web应用开始，WebRTC将成为基于网页的音视频实时通信技术规范将。之后，在web应用于移动终端应用的交互需求驱动下，越来越多的移动应用的音视频服务也将采用WebRTC的技术规范。
要说不足之处，一个就是目前WebRTC标准刚刚尘埃落定，在2018年以及今后的一段时间内，还存在各家浏览器厂商的现有WebRTC实现与规范不完全相符的情况，会多少存在某些应用场景下互联互通的问题，亟待各家浏览器厂商将持续完善现有实现以向标准看齐。另一个很大的不足（遗憾）可能是Android和iOS系统原生支持WebRTC标准的愿景目前还不明确，需要通过在app中集成客户端SDK来实现。不过向来技术标准的发展和与工业界的应用普及是相互激励的，我们也可以说这是WebRTC标准发展的一个巨大空间。
怎么做基于WebRTC的应用开发？
首先当然要让终端具备WebRTC能力。如果终端运行环境是浏览器，目前绝大部分浏览器都已经实现了对WebRTC的支持（其中Safari和Edge的支持还在持续完善中），虽然彼此有一些差异，但是可以借助adapter.js等适配层屏蔽掉这些差异。如果终端运行环境不是浏览器，则可以采用其他的开源SDK或商业SDK，将其集成在终端应用程序中。当然也可以基于Google的开源WebRTC实现的Native代码进行裁剪或移植。值得一提的是Google的开源WebRTC代码库中有大量的终端多媒体问题和传输问题的应对方案的实现，包括音视频的编解码、同步、带宽预测、QoS，AEC等，都是做终端（特别是IoT设备或桌面环境应用）开发时很好的参考。
终端实现了WebRTC只是表示它具备了实时通信的能力，但各个终端任然是孤立的，需要将各个终端的SDP进行交换才能让它们完成媒体和传输的协商才能让各个终端之间真正通起来。WebRTC并未就各个实现之间交换SDP的传输方式以及终端的“寻址”方式做出规定，这跟具体应用场景和其实现方式高度相关。因此要实现基于WebRTC的应用还需要一些“额外”的工作，通过一个各个终端都“认识”并能“找到”的“中间人”来进行SDP交换。譬如最简单的“1对1”呼叫的场景，这个“中间人”就是信令服务器，这种WebRTC的信令服务器可以基于任何消息系统构建，有很多开源实现可以利用或参考，自研开发也并不复杂。
如果要基于WebRTC做“1对多”或者“多对多”的实时通信应用，则情况要复杂一些，具体的做法也会因实际应用场景而不同，根据通信终端之间的媒体流拓扑结构，大体上可以分为Peer2Peer（终端点对点连接）模式、SFU（Selective Forwarding Unit，服务器选择性转发）模式和MCU（MultipointControl Unit，服务器混音混流）模式。
Peer2Peer模式（所有参与方均需与其他所有参与方通信的情景又叫Mesh模式）的特征是呼叫中每两个需要进行通信的参与者之间都建立起点对点的媒体连接（PeerConnection），所有的媒体连接都是终端之间的（有可能通过TURN服务器进行NAT穿越，但不影响本质流拓扑），服务器侧不参与。Peer2Peer模式的优点是媒体拓扑去中心化，服务器侧实现简单，只需要将各个终端之间的信令交换送达即可；缺点是终端需要受理多路媒体流的收发，随着呼叫中参与方数的增加，媒体连接数会阶乘函数式增长，无论对终端的编解码计算力还是带宽资源都会带来巨大的压力。如果一个呼叫中参数方数很少（譬如大多数时间2方偶尔3方），则可以考虑选用Peer2Peer模式的服务器侧实现方案。
SFU模式的特征是呼叫中所有的参与者都与服务器侧的媒体服务器建立媒体连接，把媒体流发送到媒体服务器，媒体服务器把媒体流（根据需要）选择性转发给需要接收该媒体流的所有参与者。SFU模式的优点是终端编码运算和上行网络带宽消耗大大减少，并且媒体服务器可以根据要求将媒体流（需支持SVC）的不同分层选择性地发送给接收者，适当减少接收者侧下行网络带宽的消耗并提供一定的“可定制性”用户体验。缺点（或“代价”）是媒体服务器需要受理所有媒体连接请求，接收所有参与者发布的流并转发给所有订阅者，产生服务器侧运营压力。
MCU模式的特征是呼叫中所有的参与者都与服务器侧的媒体服务器建立媒体连接并把媒体流发送到媒体服务器，媒体服务器把所有收到的媒体流进行混流混音后发送给所有需要接收的参与者。MCU模式相对SFU模式的优点是终端解码运算和下行网络带宽消耗进一步减少，并且天然具有转码能力，可以放宽终端采用音视频编解码格式的限制，使终端可以选择对自身最友好的编解码格式，大大提高终端生存能力。并且由于将所有终端的媒体混合在一起，可以实现服务器侧所见即所得的录制和向外部流媒体服务器推流。MCU的缺点（或“代价”）是媒体服务器需要实时将所有接收的媒体流解码混合再编码，会带来更大的计算力开销。
在基于WebRTC的应用的实际开发中，大多数时候服务集成商并不需要从头自研一套SFU或MCU系统，而是在市面上可用的开源或商业方案中进行选择。在进行方案选择时需要考虑的是，如果：
- 希望客户端侧拥有更多的显示布局的灵活性且下行带宽够大够稳定；
- 呼叫中发布媒体流的参与方数较少（譬如不多于6方）；
- 无异种终端接入需求也不需要转码，则可以选择SFU模式。
否则，如果：
- 客户端对下行数据量有苛刻的要求而对聚合画面布局没有差异化要求；
- 所有参与方（或很多参与方）都有发布媒体流的需求（视频会议的情景）；
- 有异种终端（譬如SIP终端、IPCamera）的接入需求或转码需求；
- 有服务器侧（云端）录制和推流到CDN的需求，则或许MCU模式更适合。除去所述这些情况以外的应用场景，则需要在各种需求的矛盾中权衡轻重得失以做出选择了。
不过其实SFU模式和MCU模式并不是绝对互斥的，有的解决方案（例如Intel CS for WebRTC及其商业化版本）是将这两种模式集成在一起的，服务集成商可以根据具体的应用场景进行灵活配置。
WebRTC发展前景如何？
作为终端技术规范，虽然WebRTC只是实时通信解决方案中的一部分，但是是最贴近用户的一部分，也许也是最重要的一部分。终端技术规范的标准化，是一个很好的开始。连一向以封闭的技术生态闻名的Apple都拥抱WebRTC了，将促进WebRTC技术的发展和普及，会有越来越多的互联网（和移动互联网）应用基于WebRTC构建其实时通信服务。
进入2018年，在互联网快速发展的当下和将来，WebRTC将极大激活人与人、人与物、物与物（IoT）之间的信息纽带，移除掉通信终端之间的时间（实时）和空间（基于互联网）的障碍，成为应用场景创新的一道强大的技术保障。同时，类似VR、AR、自动驾驶等新的应用场景的出现也会给WebRTC技术带来新的需求和动力，应用场景的商业化成功也将给技术发展持续注入活力和物质资源。譬如近年来直播连麦、网上课堂、远程控制（抓娃娃机）等基于互联网的视频应用的猛烈发展和火热，一次次催动着基于互联网的的实时音视频通信技术的发展，呼唤着WebRTC这样的统一、开放、透明的标准规范成熟和落地。
想象一下，在基于WebRTC构建的世界里，所有通信终端的媒体描述和连接建立过程都是一致的，只要终端之间开放媒体协商的通道，就可以建立起实时通信，“微信”与“WhatsApp”能建立视频通话，就像你在中国用手机跟美国的朋友家中的座机打电话一样。那多美好！推动这一天的早日到来难道不也是我们互联网音视频通信工作者们的历史责任吗？
为什么要做一场WebRTC主题的大会？
正如段先德所说，WebRTC提供的快速、完整的能力、日趋健壮的生态以及高速发展，一跃进入我们的视野，它是否能成为互联网音视频的新标准还无法给出定论，不过我们启动了一场新的技术大会WebRTCon，希望与行业专家一同分享、探讨。如果你拥有音视频领域独当一面的能力，欢迎申请成为讲师，分享你的实践和洞察，请联系 speaker@livevideostack.com。
