嗨，Chrome和火狐，有第三者插足！-CSDN博客

史上第一次，Chrome，火狐和Edge浏览器之间可以通过WebRTC和ORTC互相“通话”了。

哈哈，别急，Chrome和火狐死忠粉们也别忧虑，问题多着呢。他仨之间的“通话”：音频功能运行正常，可是涉及到视频和协作通信的编解码兼容问题……俺只能表示“呵呵”了。

WELCOME TO #肉伯特#专栏

图片摘自1959年的电影《枕边细语》

肉伯特君将原因归结为下列表格：

性能	兼容性	备注
ICE	yes	Edge浏览器要求参与者终端的信令
DTLS	yes
audio	yes	运用了G.722, Opus 或者 G.711编解码器
video	no	标准H.264在Edge浏览器中还尚未支持
DataChannels	no	Edge浏览器还尚未支持 dataChannels

先让我引用一下WebRTC当初于2013年早期的 Chromium blog post上，正式宣布有关Chrome和火狐浏览器之间的交互协作性的那段话：

WebRTC是一系列全新的可以带来清晰的语音体验、高锐度高分辨率（HD）视频和低延迟性Web浏览器的通信技术。

为了达到这个目的，一个基于Web的通信平台需要在跨浏览器间运作。多亏了W3C组织（万维网联盟）和IETF（国际互联网工程任务组）在开发这个平台过程中作出的沟通和贡献，Chrome 和火狐浏览器可以通过运用一些标准化技术：类似于Opus和Vp8的视音频编码器、DTLS-SRTP的加密技术和 ICE的网络系统技术来实现通话。

让我们再从WebRTC和ORTC的官网上再进一步了解WebRTC和ORTC的含义：

WebRTC是一项免费的开源项目，WebRTC通过简单的APIs在浏览器和移动应用上嵌入了RTC功能。优化了WebRTC的构成要素以最佳地服务好这一目的。

我们的使命是：为浏览器、移动端平台以及物联网设备打造（开发出）丰富的、高质量的RTC应用，并可以通过一套通用的协议进行通信。

WebRTC是一项由谷歌、Mozilla、Opera以及其他一些厂商支持的项目。这一页主要由谷歌Chrome团队维护。

再来看ORTC:

ORTC是一项免费的开源项目，通过与生俱来的、简易的Javascript APIs获取实时通信功能，移动设备终端可以和服务器、Web 浏览器进行对话。优化ORTC的构成要素以最佳地服务好这一目的。

我们的使命：通过唾手可得的工具包、简易的Javascript APIs和HTML5，为移动设备和服务器打造丰富的、高质量的RTC应用。必须肯定的是，ORTC可以与WebRTC兼容。

ORTC的倡议是由Hookflash团队, 微软, 谷歌以及一些其他团队共同构建的计划。现在这个介绍页主要由Hookflash团队维护。

从官网上我们可以知道：WebRTC和ORTC的本质和使命没有多大差别，主要是组织结构上加上了新成员：微软！

要知道，早先时候，微软对于W3C组织（万维网联盟）采取无视态度，并且拒绝遵循WebRTC标准，原因何在呢？

这得从早先时候开始说起，微软于2012年8月发布了CU-RTC-Web，他们不断地宣称WebRTC是一个很糟糕的标准。也许根本原因在于WebRTC跟SDP（Session Description Protocol（会话描述协议））规范联系紧密，而SDP是一个开放工业标准，可以和SIP结合支持VoIP和视频会议。SDP本非为浏览器间异步通信所设计，WebRTC使用到的一些东西已经超过了其规范，因此微软及其盟友认为Chrome和Firefox最终的实现也不会互相兼容。

除此之外，WebRTC的基础——SDP标准并非由W3C管理，而是IETF的MMUSIC（“Multiparty Multimedia Session Control”），如果他们不合作的话，最终也很难实现浏览器间的兼容。

看来，问题的症结还是出在SDP标准上，我们再来仔细分析一下现如今的ORTC:

编解码的问题...

在音频通信上我们具有兼容性。这仅仅是音频呢。还没有达到视频兼容呢。摆在所有供应商面前的一个需要解决的问题是：一个通用的视频编解码器迫在眉睫！

Edge浏览器如今运用了一个微软的H264编码的变体——被称之为：H264UC，H264UC被加入了一些类似于SVC的协议。
在进程中加入了H264。
当播放视频时有VP9解码，但是这不适用于ORTC。
Chrome支持VP8解码。H264也已被加入了进程。
火狐支持VP8和H264。
音频的交互协作方面目前仍使用G.722替代Opus，原因是Edge浏览器比起Opus来说，更偏向于Silk 和 G.722。

APIs呢？

咳咳，等一下，问题又来了，如果这些浏览器在API接口上未达成一致，如何进行“通话”呢？

有开发者已经将PeerConnection的API嵌入了ORTC的顶部，一些骇人听闻的细节将以作为adapter.js的pull请求的一部分在此处被察觉。

经历了一场颇为严酷的考验之后，结果也确实验证了这一点。这一过程在ORTC技术规范中仍凸显了几个问题。而总有那么一个假设，是否有这样一种可能，将PeerConnection作为低一层级的ORTC API，而现如今没有人能真正做到这一点。

另外，在功能部署上受限的。不仅仅是单一的音频和视频轨道尚未被测试，原因在于，就好像专门依照一个“统一规划”一样，使用SDP可能不支持与Chrome的交互操作性。不过对于大量的应用程序来说是有效的，不仅仅非要受益于原生的ORTC就能轻易达到。

这将允许大量的WebRTC的点对点连接的示例在Edge浏览器上运行，就正如大量的getUserMedia示例已经运行得如鱼得水那样。

这两者都能正常运作了，下一个大挑战将是浏览器的交互协作性。

自从加入了ICE（交互式连接建立，是一个综合的 NAT 穿越技术，是一个可以让你的web 浏览器建立点对点连接的框架。）之后，双方之间的连接打破了冰点，DTLS（数据包传输层安全性协议）的状态迅速变为已完成状态并建立连接。在Chrome浏览器上至少是这样的。

截止到目前我所关注的难点来说，ICE和DTLS（数据包传输层安全性协议）交互操作性已经解决了。我认为剩下的问题在于编解码的问题上了。

（以下有“彩蛋”宣布哦~）

好了，反观我先前分析的，其实我们将大量的关注点放在了协作能力上，据资料显示，位于微软Redmond总部的Philipp Hancke和Lance Stout两名工程师已经找到了能嵌入Edge浏览器的ORTC API的早期捷径。Philipp他构建了使用SimpleWebRTC建立起的Demo。

所以我们可以说，全球首个架构在Chrome、Firefox和微软Edge浏览器之间的会议即将出现了！微软算“插足”成功了？

P.S.个人感觉只有深入微软Redmond总部才是王道耶！

抓住机会，开始打造你理想中的实时通信应用吧，据说WebRTC即将在中国出现“井喷”！肉伯特君会一直陪伴在你身边。

——————————————————————

抚摸一下，肉伯特君需要你的关怀。

至此，肉伯特将准备好实时通信小酒供各位品尝。