本系列文章跳转目录如下：
- 是什么，为什么，如何使用
- 信令（交换信令消息后，WebRTC Agent才可以直接相互通信。）
- 连接（ 为什么WebRTC需要专用的子系统进行连接，又是怎样连接的？）
- 安全性（ WebRTC具有哪些安全性保障，又是如何做到的？）
- 搭建实时网络（网络在实时通信中的重要性以及如何处理网络中的各种问题）
- 媒体通信（WebRTC媒体通信的作用及其工作原理）
- 数据通信（WebRTC数据通信的作用及其工作原理）
- WebRTC应用场景（人们使用WebRTC构建什么以及他们是如何实现的）
- 调试（如何分析并定位相关问题，以及一些流行的调试工具）
- 历史（对WebRTC一系列协议作者的采访）
- 常见问题（ 使用WebRTC时常见的问题及解答）
- 术语
历史
在学习WebRTC时，开发人员经常对其复杂性感到沮丧，他们认为一些WebRTC功能与他们当前的项目无关，并希望WebRTC能够更简单一些。但问题是不同的开发者有迥然不同的应用场景。实时通信有着一段丰富的历史，人们在这个领域创造过很多不同的东西。
WebRTC是由一系列协议组成的，本章包含了对这些协议作者的采访。
这些采访可以让我们更深入的了解作者们在构建每个协议时所做的设计，并以关于WebRTC本身的采访结束。当你理解了软件的意图和设计，你可以用它构建出更有效率的系统。
RTP
RTP和RTCP是处理WebRTC的所有媒体传输的协议。它是在1996年1月的RFC 1889中定义的。
我们很幸运地邀请到其中一位作者Ron Frederick自己来谈论这个问题。Ron最近向GitHub上传了Network Video tool，这是一个展示了RTP的项目。
用他自己的话讲
在1992年10月，我开始尝试使用Sun VideoPix帧采集卡，当时的想法是编写一个基于IP多播的网络视频会议工具。它是根据"vat"建模的，"vat"是LBL开发的一个音频会议工具，它为参加会议的用户使用了类似的轻量级会话协议，你可以简单地使用此工具将数据发送到特定的多播组，并监听来自该组中其他小组成员的任何流量。
为了使程序真正成功，它需要先压缩视频数据，然后再将其发布到网络上。我的目标是在大约128 kbps或标准家庭ISDN线路的带宽上生成可接受的可视数据流。我还希望在一半带宽下生成仍能被观看到的东西。这意味着我需要将特定图像尺寸和帧率的视频压缩到大约20分之一的大小。我实现了这种压缩，并申请了专利，专利是 US5485212A：用于电话会议的软件视频压缩。
1992年11月上旬，我向互联网社区发布了视频会议工具"nv"（二进制形式）。经过一些初步测试后，它被用于在全球范围内对11月Internet工程任务组的部分进行视频广播。在15个国家/地区中，大约有200个子网能够接收此广播，并且一周中的某个时候，大约有50-100人使用"nv"接收了视频。
在接下来的几个月中，另外三个研讨会和一些较小的会议使用"nv"向整个Internet进行广播，包括澳大利亚NetWorkshop，MCNC分组音频和视频研讨会以及瑞典的分布式虚拟现实MultiG研讨会。
随后，在1993年2月，我发布了"nv"的源代码，并在3月发布了该工具的一个版本，在其中引入了新的基于小波的压缩方案。在1993年5月，我增加了对彩色视频的支持。
用于"nv"和其他Internet会议工具的网络协议成为了实时传输协议（RTP）的基础，该协议通过Internet工程任务组（IETF）进行了标准化，该工作组首先在RFCs 1889-1890中发布，后来又与其他各种RFC一起，在RFCs 3550-3551中进行了修订，它们涵盖了用于传递特定音频和视频格式的配置文件。
在接下来的几年中，关于"nv"的工作继续进行，该工具被移植到了许多其他硬件平台和视频捕获设备上。它仍然被用作当时在Internet上广播会议的主要工具之一，包括被NASA选中以在线直播的方式进行航天飞机飞行任务的实时报道。
1994年，我在"nv"中添加了对其他人开发的视频压缩算法的支持，其中包括一些硬件压缩方案，如SunVideo视频捕获卡支持的CellB格式。这也使得"nv"可以用CUSeeMe格式发送视频，并将视频发送给在Mac和PC上运行CUSeeMe的用户。
最新的"nv"版本是1994年7月发布的3.3beta版本。当时我正在开发"4.0alpha"版本，该版本旨在将"nv"迁移到RTP协议v2，但因为我转到了其他项目上，这项工作从未被完成。为了保持完整性，Network Video tool归档文件中包含4.0 alpha代码的副本，但它是未完成的，并且存在已知问题，尤其是在RTPv2支持不完整的情况下。
“nv"中提供的框架后来成为Xerox PARC的"Jupiter multi-media MOO"项目中视频会议的基础，该项目最终分拆为独立公司"PlaceWare”，后来该公司被Microsoft收购。它也被用作许多硬件视频会议项目的基础，这些项目允许通过高带宽以太网和ATM网络发送完整的NTSC广播质量的视频。后来我还使用了其中一些代码作为"Mediastore"的基础，"Mediastore"是基于网络的视频记录和回放服务。
你还记得草案中其他人的动机/想法吗？
我们都是IP多播的研究人员，并且帮助创建了Internet多播主干网（又名MBONE）。MBONE由Steve Deering（IP多播的首位开发者），Van Jacobson和Steve Casner创建。 我和Steve Deering在斯坦福大学有同一位顾问，Steve离开斯坦福大学后就去了Xerox PARC工作，我作为IP多播相关项目的实习生在Xerox PARC呆了一个夏天，后来在斯坦福大学还继续为他们兼职工作，再后来转为全职。Van Jacobson和Steve Casner是最初的RTP RFC的四位作者中的两位，还有Henning Schulzrinne和我本人。我们所有人都使用MBONE工具进行各种形式的在线协作，并且试图提炼出所有这些工具可以使用的通用基本协议，RTP就是这样出现的。
多播很棒，而WebRTC完全是单播的，可以说一下是为什么吗？
在前往斯坦福大学并学习IP多播之前，我花了很长时间致力于让计算机成为人们相互交流的方式。这是从80年代初期开始的，当时我运行了一个拨号公告板系统，人们可以登录并留下彼此的消息，既可以是私人的（相当于电子邮件），也可以是公共的（讨论小组）。大约在同一时间，我还了解了在线服务提供商CompuServe。 CompuServe的很酷的功能之一就是所谓的"CB Simulator"，人们可以在其中进行实时交谈。这些都是基于文本的，但是它具有"频道"的概念，就像真正的CB广播一样，只要他们在同一个频道中，大家就可以看到其他人键入的内容。我构建了自己的CB版本，该版本在我可以访问的分时共享系统上运行，该系统可以让该系统上的用户实时向彼此发送消息，然后在接下来的几年中，我与朋友一起开发了更复杂的各种版本的实时通信工具，可以在几个不同的计算机系统和网络上运行。事实上，其中一个系统仍在运行，我每天都会用它与30多年前上大学的人们进行交流！
所有这些工具都是基于文本的，因为当时的计算机通常没有任何音频/视频功能，但是当我到达斯坦福大学并学习了IP多播时，我产生了一个想法。做一个真正的"收音机"，你可以将信号发送到网络上，该信号并不是特别发给任何人的，但是调谐到该"频道"的每个人都可以接收到它。碰巧的是，我正在为之移植IP多播代码的计算机是Sun的第一代SPARC-station，而它实际上内置了电话级别的音频硬件！你可以将麦克风中的声音数字化，然后通过内置扬声器（或通过耳机输出）播放。因此，我的第一个想法是弄清楚如何使用IP多播将音频实时发送到网络上，然后看一下是否可以构建一个使用实际音频而不是文本的"CB收音机"。
这里有一些棘手的事情需要解决，例如计算机一次只能播放一个音频流，因此，如果有多个人在讲话，则需要在数学上将多个音频流"混合"为一个，然后才能播放。不过一旦你了解了音频采样的工作原理，这些工作就可以全部通过软件完成。该音频应用程序使我致力于MBONE的开发，并最终通过"nv"实现了到视频的转换。
协议中遗漏了什么你原本希望添加的东西吗？有没有哪些让你后悔加入的内容？
我不觉得有什么后悔的，不过最终人们对RTP抱怨最多的其中一点就是RTCP实现的复杂性，RTCP是与RTP主数据流量并行运行的控制协议。我认为，RTP并未得到更广泛采用的主要原因就是太过复杂，尤其是在单播情况下，对RTCP的某些功能的需求不再那么大。由于网络带宽变得不再那么稀缺，而拥塞也不再是一个大问题，许多人最终只是通过纯TCP（以及后来的HTTP）流式传输音频和视频，一般来说，这就已经"足够好"了，以至于没有必要再去与RTP打交道。
不幸的是，使用TCP或HTTP意味着多方音频和视频应用程序必须通过网络多次向需要接收数据的每个对等方发送相同的数据，从而从带宽的角度来看，效率被大大降低。有时，我希望我们之前能更加努力地推动IP多点广播的应用，使其不仅限于研究领域。我认为，如果我们这么做了的话，可能我们早就可以看到有线电视和广播电视过渡到基于Internet的音频和视频。
有什么东西是你曾经想过使用RTP构建的呢？是不是有一些很酷的RTP项目/想法随时间流逝了呢？
我构建的其中一个有趣的项目是一个使用IP多播的经典游戏"Spacewar"版本。在没有任何类型的中央服务器的情况下，多个客户端可以各自运行spacewar的二进制文件，并开始广播其船舶的位置/速度/所面对的方向以及已发射的任何"bullets"的类似信息，所有其他客户端将收集这些信息并将其呈现在本地，从而使所有人都可以看到彼此的飞船和bullets，如果飞船撞向对方或被bullets击中，飞船就会"爆炸"。我甚至将爆炸中的"碎片"也做成了可以击毁其他船只的活动物体，有时会引起有趣的连锁反应！
本着原始游戏的精神，我使用模拟矢量图形对其进行了渲染，因此你可以执行诸如放大和缩小视图之类的操作，并且一切都会按比例放大/缩小。飞船本身是一堆矢量形式的线段，我在PARC的一些同事帮助我进行了设计，因此每个人的飞船都有独特的外观。
基本上，如果一个东西需要实时数据流，又无需数据按照精确的时序传输，那么它就可以从RTP中受益。因此，除了音频和视频，我们还可以构建共享白板之类的东西。甚至使用RTP进行文件传输，尤其是与IP多播结合使用时。
这就像BitTorrent，但是你不需要在对等方之间点对点地传输所有数据。原始的做种者可以立即将多播流发送到所有接收者，并且通过成功接收数据的任何对等方的重发，就可以快速解决传输中数据包丢失的问题。接收者甚至可以确定重传请求的范围，以便附近的一些对等方能够传递数据的副本，重传请求也可以被多播到该区域中的其他节点，因为网络中间的数据包丢失往往意味着下游有很多客户端错过了相同的数据。
为什么你必须实现自己的视频压缩协议？当时没有其他可用的东西了吗？
在我开始构建"nv"时，我所知道的唯一进行视频会议的系统是非常昂贵的专用硬件。例如，Steve Casner可以从BBN访问一个名为"DVC"（后来商品化为"PictureWindow"）的系统。压缩需要专用硬件，但是解压缩可以通过软件完成。"nv"之所以与众不同，是因为压缩和解压缩都是在软件中完成的，唯一的硬件要求是对输入的模拟视频信号进行数字化处理。
当时，有关如何压缩视频的许多基本概念已经存在了，诸如MPEG-1标准之类的东西大约在"nv"出现的同时出现，但在当时绝对不可能使用MPEG-1进行实时编码。我所做的更改都是关于吸收这些基本概念并使用更便宜的算法对其进行近似模拟，其中我避免了余弦变换和浮点之类的事情，甚至避免了整数乘法，因为在SPARC-stations上这些运算速度非常慢。我尽量只进行加/减法、位屏蔽和移位，这样可以使速度足够快，并使结果看起来仍像是视频。
在"nv"发布的一两年之内，不仅是在MBONE网络上，还有其他地方（如Mac上的CU-SeeMe工具），都出现了许多不同的音视频工具可供选择。很明显的，实时视频的时机成熟了。事实上，我最终使"nv"与许多这些工具互操作，还有某些工具甚至采用了"nv"编解码器，以便在使用压缩方案时它们可以互操作。
WebRTC
WebRTC需要的标准化工作使得本章中描述的所有其他工作都相形见绌。它需要两个不同的标准机构（IETF 和 W3C），以及来自许多公司和国家的数以百计的人员合作。Serge Lachapelle会跟我们谈谈实现WebRTC的初始动机，以及在开发过程中所付出的巨大的努力。
Serge是Google的产品经理，目前担任Google Workspace的产品经理。下面是我总结后的采访内容。
什么促使你参与 WebRTC ？
从大学开始，我就一直热衷于构建通信软件。在90年代，像nv这样的技术开始出现，但很难使用。我创建了一个项目，它允许你可以直接从浏览器加入视频通话。我也将它移植到了Windows。
我把这段经历带到了我共同创立的公司Marratech。我们构建了用于群组视频会议的软件。从技术上来讲，当时的愿景与现在大不相同。当时的视频通信的前沿方向是使用多播网络。用户可以依靠网络将视频数据包传送给通话中的每一个人。这意味着我们的服务器可以非常简单。但这种做法存在一个巨大的缺点，必须设计网络以适配多播模式。后来，这个行业从多播转向了数据重组（packet shufflers），也就是现在大家都知道的SFU。
Marratech于2007年被Google收购。然后我得以继续这个后来成为WebRTC的项目。
在Google的第一个项目
WebRTC前身团队（后来才有WebRTC项目）参与的第一个项目是Gmail语音和视频聊天。将音频和视频导入浏览器并不容易。我们需要从各个公司获得特定功能模块的许可。音频模块由GIP授权，视频模块由Vidyo授权，网络模块由libjingle授权。然后，我们要像变魔术一般让这些组件一起工作。
每个子系统都有完全不同的API，而且它们都是为了解决不同的问题而设计的。为了让它们协同工作，你需要同时具备多个领域的专业知识，例如：网络、密码学、媒体等等。
Justin Uberti是这项工作的负责人。他将这些组件组合在一起，开发了一个可用的产品。
在浏览器中做实时渲染也非常困难。我们不得不使用NPAPI（Netscape Plugin API），并做了很多创新性的工作，才使其最终得以实现。
从这个项目中，我们学到了很多经验教训，这极大地影响了WebRTC。
Chrome
与此同时，Chrome项目在Google内部启动。Chrome在项目之初就拥有远大的格局，带来了很多令人兴奋的东西，简单举几个例子，比如WebGL、离线应用、数据库功能、游戏低延迟输入等等。
是否摒弃NPAPI是当时的一个争论焦点。它是一个强大的API，但也引入了诸多的安全性问题。Chrome使用沙盒设计来确保用户安全。潜在的不安全操作被隔离在不同进程中运行。即使出现一些问题，攻击者也无法访问用户数据。
WebRTC 诞生
我的个人理解是，多方面的因素和诉求，最终促成了WebRTC的诞生。
构建实时通信软件不应该如此艰难。开发者们耗费了大量的精力来重新实现相同的东西。我们应该一次性解决这些令人沮丧的集成问题，然后就可以专注于其他事情。
人际沟通应该是畅通无阻的，应该是开放的。为什么文本和HTML可以在浏览器里打开，而我的实时音视频却不能呢？
安全是重中之重。使用NPAPI对用户来说并不是最好的。因此这也是一个机会，让我们可以创建一个默认就很安全的协议。
为了实现WebRTC，Google收购并开源了很多我们用到过的组件，包括On2的视频技术和
Global IP Solution的RTC技术。我负责了其中GIPS的收购工作。我们必须将这些结合起来，让他们在浏览器内外都能够简单易用。
标准化
WebRTC的标准化是我们非常想要去做的一件事情，但我之前没有做过，当时的团队中也没有人有任何经验。这一点上，我们很幸运得到了Google的Harald Alvestrand的加盟。他此前已经在IETF做过很多工作，并且启动了WebRTC的标准化进程。
2010年的夏天，在Maastricht举办了一次非正式的午餐会。许多公司的开发人员们齐聚一堂，讨论WebRTC应该是什么样子的。餐桌上有来自 Google、Cisco、Ericsson、Skype、Mozilla、Linden Labs等公司的工程师。你可以在rtc-web.alvestrand.com找到完整的出席人员和演示的幻灯片。
Skype当时已经在IETF完成了Opus的标准化工作，他们也提供了一些很好的指导意见。
站在巨人的肩膀上
在IETF的工作实际是对过去人们工作的进一步扩展。
对WebRTC而言，我们非常幸运，因为已经有很多现有的技术可以使用。我们不需要负责所有的问题，因为很多问题（在现有的技术下）已经解决了。但如果你不喜欢现有的技术，这就可能成为一个麻烦的问题。我们一般不会选择重新造轮子，除非有特别必要的理由。
我们也有意识地避免对某些东西重新标准化，比如信令（signaling）。信令的标准化已经通过SIP和其他非IETF组织的努力得到了解决，如果重新对它标准化，最终可能会演变成为政治问题。还有最本质的原因是，我们觉得（对其重新标准化）并不会创造什么有价值的贡献。
我没有像Justin和Harald那样全程参与了标准化工作，不过我很享受参与其中的这段时光。当然，回来重新为用户创造产品是让我更兴奋的事。
未来
WebRTC如今正处于一个很好的位置。创新迭代在这个领域不断发生，而且这些创新并没有局限于我们曾经做过的一切。
我最兴奋的是云计算将会如何影响通信技术。使用高级算法，我们可以从通话中去除背景噪音，这让我们在一些以前无法沟通的场景下通信成为可能。我们还看到WebRTC也不再局限于通信……谁能想到它已经被应用于云游戏9年之久了呢？如果没有WebRTC作为基础，这一切都是不可能实现的。
