携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情
疫情期间，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被使用。
