我想分享一些关于 Firefox WebRTC 实现的有用且令人兴奋的更新，并提供我们未来 WebRTC 计划的一些抢先体验。然后，我将请 Adam Roach 提供一些关于 WebRTC 功能本身的历史背景以及整体进展情况的信息。Adam Roach 在 VoIP/SIP 领域从事 IETF 标准工作已有十多年，并于 11 月加入了 Mozilla WebRTC 团队。

准备在桌面版上发布我们的第一个 WebRTC 实现

Firefox 在桌面版 WebRTC 的初始实现方面取得了重大进展，尤其是在安全性和稳定性方面。在过去的几周里，PeerConnection 和 DataChannels 在 Nightly 和 Aurora 中默认已启用，我们预计将在 Firefox 22 的所有发布阶段保持启用状态（这意味着我们预计 WebRTC 将进入 Aurora、Beta 和正式版）。

我们还有机会更新 Firefox 22 中的 DataChannels 实现，以匹配最近的规范更改（上个月在 IETF 上达成一致）。请注意：为了符合规范更改，我们需要进行的更改 与之前的 DataChannels 实现（在 Firefox 21 或更早版本中）不兼容。因此，请使用 Firefox 22 及更高版本测试您的 DataChannels 应用。

TURN 支持已上线

还有更多好消息。我们刚刚在 Firefox Nightly 中添加了 TURN 支持，并且正在对其进行测试。这是一件大事，因为无论端点位于哪种类型的 NAT 后面，TURN 都可以提高呼叫成功连接的可能性。

TURN（穿越 NAT 后面的中继） 是一种用于管理（分配、使用和销毁）远程外部服务器上的中继会话的标准。此中继会话使 WebRTC 能够在两端都存在 NAT 且会导致呼叫失败的情况下进行连接。由于 TURN 会引入延迟，尤其是在 TURN 服务器远离两个端点时，并且 TURN 服务器可能很昂贵（因为它必须处理呼叫期间的所有媒体流），因此 ICE 通常仅在其他方法（如 STUN）无法使呼叫期间的媒体流正常工作时才使用 TURN。

适用于 Android 的 Firefox 上的 WebRTC 已准备好进行实验和反馈

2 月份在世界移动通信大会上，我们展示了 Firefox for Android 上 WebRTC 呼叫的令人兴奋的新演示。我们刚刚在 Nightly 中完成了此代码的上线。getUserMedia (gUM) 和 PeerConnection 的代码位于首选项后面（桌面版最初也是如此），但您可以通过将 media.navigator.enabled 首选项和 media.peerconnection.enabled 首选项都设置为“true”来启用它（浏览到 about:config 并搜索首选项列表中的 media.navigator.enabled 和 media.peerconnection.enabled）。

在同一列表的首选项中，您还可以将 media.navigator.permission.disabled 设置为“true”，以自动授予访问摄像头/麦克风的权限，并在测试 gUM 和 WebRTC 时绕过权限/选择对话框。

此代码仍处于测试的早期阶段，但我们鼓励您尝试一下，报告问题，并提出问题并提供反馈。如果您报告问题或提供反馈，请务必提及“Android”，因为我们现在正在跟踪 Android 和桌面版的问题。与桌面版一样，我们将在未来一年继续改进、稳定和扩展此代码。

Firefox OS 上的 WebRTC 即将推出

Mozilla 也正在努力让此代码在 Firefox OS 上运行。Firefox OS 上的 WebRTC 还没有 Firefox for Android 上的 WebRTC 那么成熟，但 Firefox OS 团队正在努力缩小差距。您可以关注 Bug 750011 以跟踪此工作。

未来的 WebRTC 功能

由于我们所有的产品都共享 Gecko 引擎，因此对核心“平台”或 Gecko 代码的改进和新功能通常会使我们所有的产品受益。在未来一年，我们计划进行以下改进

• 完整的错误和状态报告（符合规范）
• 录制 API 支持
• Persona 集成
• 每个 Peer Connection 的多个音频和视频流（超出 1 个视频流和 1 个音频流）
• 持久权限支持（在 UX/UI 中）
• AEC 改进
• 改进呼叫质量（尤其是音频延迟）

我们希望做更多的事情，但这些是我们最优先考虑的。我们还有一个WebRTC 文档和帮助页面，我们将在未来几周内努力完善并保持更新。该页面将包含我们已实现和正在开展工作的链接，以及贡献者参与的方式。

展望未来

尽管我们迫不及待地想要发布我们在桌面版上的第一个 WebRTC 实现（这对 Mozilla 和 WebRTC 功能本身来说都是一个巨大的里程碑），但我仍然鼓励所有尝试使用 WebRTC 的开发人员在可预见的未来继续使用 Nightly，因为那里是最新的和最棒的功能从规范中落地和错误首先被修复的地方——并且您的反馈在那里将是最有帮助的。

更重要的是，WebRTC 规范本身仍在标准化。有关更多详细信息，以及 WebRTC 背后的历史，我将本文的其余部分交给 Adam。

-Maire Reavy，Mozilla 媒体平台团队产品经理

WebRTC 是通信的真正未来

我是 Adam。

大约三年前，我亲爱的朋友兼 VoIP 远见卓识者 Henry Sinnreich 在午餐时花了一些时间试图说服我，通信的真正未来在于能够直接从无处不在的 Web 浏览器进行语音和视频通话。我仍然可以想象他热情地挥舞着他的智能手机，强调 Web 浏览器已经变得多么普遍。我的回应是，他的提议需要 IETF 和 W3C 之间前所未有的合作才能实现，并且需要主要浏览器供应商付出巨大的努力和承诺。简而言之：这是一个美好的愿景，但规模庞大。

然后，一件了不起的事情发生了。

WebRTC 崭露头角

在 2011 年期间，为这种 IETF/W3C 合作奠定了基础，并设计了一个广泛的技术框架。在 2012 年，Google 和 Mozilla 开始认真地着手实施正在开发的标准。

去年 11 月，旧金山举办了首届 WebRTC 博览会。开幕主题演讲座无虚席，人满为患，人们溢出到走廊里。在接下来的两天里，我们看到了无数新兴 WebRTC 服务的演示，并看到了数十家公司致力于 WebRTC 生态系统的开发。David Jodoin 与我们分享了一个惊人的事实，即美国十大银行中有一半已经在计划他们的 WebRTC 战略。

在 2 月份，Mozilla 和 Google 通过演示 Firefox 和 Chrome 之间的实时视频通话，为 WebRTC 铁路铺设了最后一根道钉。

那么我们现在处于什么阶段？

有了这个里程碑，很容易将 WebRTC 视为“即将完成”，并且很容易想象我们现在只是在打磨一些粗糙的边缘。虽然我非常希望如此，但仍有大量工作要做。

去年 2 月在波士顿，我们为各个标准工作组举行了联合临时会议，这些工作组正在为 WebRTC 工作做出贡献。主题包括从 WebRTC javascript API 的调用约定到如何发出多个视频流的结构等各种问题——这些问题对于标准的广泛采用至关重要。我并不是说 WebRTC 标准化工作举步维艰。在过去 16 年里，我一直致力于标准化工作，我可以向您保证，对于一项如此雄心勃勃的技术而言，这种开发速度是完全正常且预期的。我想说的是，如此庞大、如此重要、且涉及如此多利益相关者的规范需要很长时间。

标准的现状

即使标准化工作今天就完成了，WebRTC 所做的事情的规模也需要很长时间才能实现、调试和完善。我们的黄金道钉互操作时刻需要双方付出大量工作，并且揭示了两个实现中的许多缺点。去年 2 月也标志着SIPit 30的诞生，其中包括首个实际的 WebRTC 互操作测试事件。可以预见，此测试除了我们已知的限制之外，还发现了几个新的错误（在我们自己的实现以及其他人的实现中）。

当您将我知道 Mozilla 和 Google 都尚未开始着手的所有功能，以及尚未指定的任何功能都考虑在内时，在我们开始为 WebRTC 添加修饰之前，很容易就有一年的工作要做。

我们正在努力构建互联网上通信的未来，并且很难不对这项技术带来的机遇感到兴奋。我对 WebRTC 获得的热烈反响感到非常高兴。但我们都需要记住，这仍然是一项正在进行的工作。

来玩吧！但请当心头顶。

所以，请进来，四处看看，并试玩我们正在做的事情。但不要期望一切都光鲜亮丽且完美无缺。虽然我们正在尽最大努力限制不断变化的标准对应用程序开发人员和用户的影响，但随着规范的演变以及我们对哪些方法最有效了解更多，不可避免地会出现变化。我们会在这里的 Hacks 博客上让您了解这些变化，并尽量减少它们的影响，但我完全预计应用程序开发人员将不得不随着平台的演变进行调整和修改。预计我们将需要几个版本才能将语音和视频质量提升到我们都满意的程度。最重要的是，请了解，在相当长的一段时间内，任何人的实现都无法完全匹配快速发展的 W3C 规范。

我相信我们都希望 2013 年成为“WebRTC 之年”，正如一些人已经将其冠名的那样。对于早期采用者来说，这绝对是尝试现有可能性、了解哪些方面无法按预期工作以及——最重要的是——向我们提供反馈的最佳时机，以便我们能够改进我们的实现并改进正在开发的标准。

只要您能够处理轻微的中断和变化；如果您能够处理某些事情无法按描述工作的情况；如果您准备好撸起袖子并影响 WebRTC 的发展方向，那么我们随时欢迎您。带上您的安全帽，并保持沟通渠道畅通。

对于那些希望部署付费服务、可靠的渠道来管理客户关系、关键任务应用程序的人来说：我们也希望收到您的反馈，但请谨慎制定您的发布计划。我预计我们将在明年某个时候拥有一个稳定且真正开放的商业平台。

鸣谢：原始安全帽图片来自openclipart.org；Anthony Wing Kosner 首次将“黄金道钉”类比应用于 WebRTC 互操作性。