疫情期间，WebRTC发挥了至关重要的作用，让所有人都保持联系，许多人对它的工作原理和所做的技术决定感到惊讶和困惑。这次演讲旨在为这些决定提供一些历史背景，希望能减少关于这些决定的困惑。一下一起看看WebRTC一路走过的历程。

谁参与了WebRTC的发展历程

为什么WebRTC的发展历程如此之长

为什么WebRTC是P2P

为什么没有标准的信号形式

?为什么选择端到端（DTLS/SRTP）

为什么选择RTP

关于数据通道

为什么如此多的选择模式

关于编解码器

WebRTC的巨大成功

关于WebRTC API和协议的发展历程中有许多小故事，正如所有的web开发人员在第一次遇到WebRTC时都会问很多的为什么。许多答案实际上与历史有关，并且不同人的看法是存在偏差的，所以本次演讲只是一些关于本人对WebRTC标准化过程中所做出的选择的看法。

谁参与了WebRTC的发展历程

谷歌、思科、爱立信、微软、Mozilla和Voxeo都参与了WebRTC的发展历程，W3C和IETF组织也提供了一定的支持。

为什么WebRTC的发展历程如此之长

lib webRTC是在2011年开源的，人们困惑其发展历程所经历的时间之久，困惑的一方的原因是，WebRTC的构建基础早就具备，例如google早就拥有了许多相关的知识产权，Cisco也拥有许多SIP相关的产品，表面上来说所有要使用的协议的RFC都已经存在了，所以这就像一个组装工作，把这些组件放在一起，18个月内就能完成。

 

但实际上，这种想法实质上等同于把电话放进浏览器。只要扔一个进去，网络开发者就会使用它，这或许可以行得通，但是其和800电话模式（拨打电话的人不会被收费）或者skype相似，而本质上，这并没有将其考虑为一个RTC问题。

 

为什么WebRTC是P2P

开始之初Skype是主要的竞争对手，在那个时间点，这是一个PTP协议，它被视为一个巨大的成功，并且是一个meshframework框架，就像网格覆盖一样；此外，参与这个过程标准化过程的大多数人都受到了SIP的影响，而SIP灵感源于P2P。所以WebRTC是P2P在当时来说似乎是一个自然的选择。

为什么没有标准的信号形式

当时有几个原因，其中一个非常简单的原因是，SIP、XMPP和H323之间的激烈竞争并没有产生赢家；另一个更大的问题是网络授权认证方面，网络认证并不是一个简单的事，其并不像SIP的认证，如果尝试在浏览器中使用它，需要把一个SIP标识绑定到一个网络会话上，并保持这种表，其结果会相当复杂。此外，管理这些绑定关系数据是困难的。将呼叫状态绑定到Web应用状态要容易得多，如果Web应用正在执行调用控制，那么我们就到了希望Web应用参与核心控制的地步。

Why no standardised signalling?

为什么选择端到端（DTLS/SRTP）

在当时，著名的斯诺登事件所揭示的网络信息安全问题是主要原因。常规的SRTP/SDES授权被认为是实现过于困难而无法实际使用，所以选择了使用Java实现DTLS/SRTP。

为什么选择RTP

实际上这基本上是标准规则，由于许多原因，Adobe发展过程中的选择太慢了，当他们展示的时候就有点落时了。并且IAX2只是一个信息性RFC，因此不适合RTC。

关于数据通道

通话数据是有用的；

没有DTMF是不够的；

RTP数据通道超级笨重(被弃用8年后，在chrome中仍然支持)；

SCTP适用于RFC(如果过度使用)。

为什么如此多的选择模式

早期媒体、捆绑、SDES、PRANSWER等；

现有的电信中间箱支持webRTC的想法没有改变；

P2P和端到端网络确保了这永远不可能实现，但是我们仍然有api；

复杂的学习和测试噩梦。

关于编解码器

部分原因与当时其他应用的成功有关，由于Skype取得了巨大的成功，并且它已被开源，结合Opus，产生了一个开源代码。视频编解码器的东西要复杂得多，没有明显的开源编解码器可以被使用。许可证的原因推动了VP8的使用，而硬件性能问题则使得H.264被使用。

Why those codecs?

WebRTC的巨大成功