Android IOS WebRTC 音视频开发总结(五四)-- WebRTC标准之父谈WebRTC

本文主要是整理自国内首届WebRTC大会上对Daniel的一些专访,转载必须说明出处,欢迎关注微信公众号blacker,更多说明详见www.rtc.help

说明:以下内容主要整理自InfoQ的专访,为了方便大家更好理解有些地方我加入了一些说明或做了特别标记。

问题1:

InfoQ:JavaScript 之父 Brendan Eich(Mozilla 前 CTO)曾说过,“WebRTC is a new front in the long war for an open and unencumbered web.”,您怎么理解他的这句话?

Daniel C. Burnett:谷歌想把网页版应用的体验做的和 Native 应用一致,但是他们很快发现,谷歌自身的产品诸如 Google Docs、Gmail 等并没有解决通讯的问题,也就是说它们不能控制麦克风、摄像头以及人与人之间的通讯。所以我同意 Brendan Eich 的说法,这对互联网和 Web 来说是一件大事。

问题2:

InfoQ:据了解,WebRTC 联盟曾故意遗漏信令标准来避免冲突,但此举造成后来厂商使用各不相同的协议,包括 SIP、WebSockets 以及 HTTP 协议。您认为这个问题应该怎么解决?

Daniel C. Burnett:我认为这是 W3C 做的最好的决定。有的厂商想强制把 SIP 作为浏览器通讯的信令,但是这样的话,你想用 XMPP 或者 Jingle 就不可能了。与其抄袭过时的电话网络用 SIP 协议,不如把这一部分留白,让大家自己选择何种实现。有人诟病 SIP 信令层的借口是 SIP 层没有很好的 JavaScript 库。显然这个说法是错误的,事实上有很多很好的 JavaScript 库可以用。所以,如果你一定要用 SIP 做信令层,有很多很好的 JavaScript 库供你选择,但是你不会因此受限制,这才是互联网真正该有的样子。

blacker注释:从我们接触的这么多案例来看,信令完全没有必要统一,因为不同业务场景,不同系统用的的完全不一样,有的适合jason,有的适合xmpp,有的适合sip,等等)。

问题3:

InfoQ:随着企业云通信市场的发展,许多厂商和开发者并没有等 WebRTC 最终定稿便投入到产品研发中,这对未来 WebRTC 标准的制定有哪些不利的影响?在您看来有没有像 Flash 之于 HTML4 那样的产品或者技术来促成 WebRTC 标准的制定?

Daniel C. Burnett:早期吃螃蟹的人,他们的反馈对 WebRTC 标准的制定也是至关重要的,这对未来标准的制定是很有帮助的。互联网本来就是快速迭代的过程,产品要不断试错,我们 WebRTC 标准的制定也遵循这样的规律。

HTML5 的多媒体标准分好几部分,WebRTC 是其中的一部分。一个好消息是,WebRTC 的标准制定比较超前,很多 HTML5 其他工作组的标准制定者对这一方面的工作十分关心,最终的结果是 HTML5 和 WebRTC 会很好地共存,两者之间的沟通其实是无缝的。举个例子好了,目前 HTML5 标准里没有很好地定义音频应该输出到麦克风还是扬声器,现在 WebRTC 已经作出了一些可选择的方案,HTML5 和 WebRTC 正在密切协作以改进这个标准,其结果是二者会很相似,于开发者而言将不再会面临两种标准的困扰。

问题4:

InfoQ:开发者对实现通信受既有概念的束缚是对 WebRTC 和云通信的真实挑战,比如企业中的电话会议依然是很受信赖的形式。怎么改变这种局面?

Daniel C. Burnett:有些协议和标准的制定者认为,标准或者说规范越少、越简单越好。但 WebRTC 标准制定者认为还是应该稍微多给定一些标准和规范,于是我们多给了一些,但这多给出的部分依然不够,这也是为什么我写了《WebRTC权威指南》这本书。

WebRTC 的目的就是打破常规的人们对电话的固有认识,把人和人之间的互动、沟通加入到人们日常工作流、任意的APP当中;而不是在这个APP中内置一个电话功能,这种思想是错误的。正确的思想是,通讯应该是一种功能,而不是一种应用。也就是说,让打电话不再只是打电话,他就是人与人之间自然的交流。比如,电话不再是一个物理的设备,现在的智能可穿戴设备将来都有可能取代打电话这件事,而且未来的通讯不止是人跟人之间,有可能是人跟物之间发生。

王骅补充:再比如,视频通讯不应该被视为“我能看到你的脸”,人们看到的可能是一个大的数据流——通过大数据的挖掘,你的心跳、体温、脸色等等都可以通过摄像头传输过来。这跟传统的电话的模式有根本的区别。

问题5:

InfoQ:在从事 WebRTC 开发的厂商中,与运营商合作是一个选择,打造更强大的 SDK 和更富弹性的服务也是一种选择。您怎么评价这两种策略的未来发展?您对 WebRTC 技术在中国的发展有哪些期望?

Daniel C. Burnett:我是 WebRTC 标准的制定者,对商业模式的话题并不方便也不适合回答(这就是专业做学术的人,不想给商业做代言)。

王骅:如果从市场的角度来看,提供 SDK 的公司只是给开发者提供了一种便利,因此很难生存。用户需要的是提供一个稳定、可靠的点对点通讯服务。以美国市场为例,现有的20多家提供 SDK 的厂商已经有7、8家被收购了,这种收购不是以大的价值被收购的,而是活不下去才不得不被收购。

在国内市场方面,国内浏览器厂商都不大,很多厂商使用的都是同样的开源代码,我们很惊喜地发现有些代码写一遍在各家的浏览器上都可以运行。在微软慢慢往 WebRTC 这个方向靠拢之后市场方面的问题应该不大。这的确是一个比较对大家利好的事情,从运营商的角度来,他们主要是做基础建设和卖数据流,在这些数据上会衍生出很多公司和各种丰富的服务,最基本的可能是音视频服务,但远远不止这些。只要政策上面没有太多的干预,这个行业将会有很大的爆发。

问题6:

InfoQ:目前支持 WebRTC 的浏览器有 Chrome、Firefox、Opera 以及在此基础上的衍生产品。阻碍了 WebRTC 跨浏览器支持的因素有哪些?微软的 IE 浏览器(微软一直在推进自己的 WebRTC 版本)和苹果的 Safari 不支持 WebRTC 的主要原因是什么?

Daniel C. Burnett:过去的几年里我被无数次问到这个问题。我不为微软和苹果工作,我很难知道他们是怎么想的。

然而,微软在我们最初在讨论 WebRTC 标准的时候,Skype 里的确有一些有远见的人愿意参与,但是当时正值微软收购 Skype 时期,这些人都不能说话,因此微软没能参与进来;等收购结束他们能参与进来的时候,W3C 已经决定使用另外一套方案了。Skype 的人再想走另外一条道路的时候,已经基本不可能了,所以最终微软选择的是一个非标准的ORTC

最初微软推出 ORTC 是想跟 WebRTC 分庭抗礼,但从去年开始两边有了一定的沟通,在 WebRTC 1.0 版之后他们能互相兼容,慢慢在标准上会互相靠拢。微软的新浏览器 Edge 已经支持了 ORTC,有迹象标明微软会在 JavaScript 库方面与 WebRTC 做兼容,从这个角度来看很有可能未来 Chrome、IE、FireFox 会站在一起。

至于苹果,没有人知道苹果到底要做什么直到他们 release。在过去的一年里,我们偶尔发现会有苹果的人来旁听了一下 WebRTC 的标准讨论。最近我们发现苹果在招聘 WebRTC 的开发岗位。所以大家还是很希望苹果能在兼容性方面能做点什么的。

要猜大公司什么时候决定支持什么样的东西是很难的,但我认为谷歌、Mozilla 和微软都站在了一起,这对苹果来说是个威胁,苹果如果不参与进来,就有可能被孤立。苹果内部可能有一些考虑,这些我就不得而知了。

blacker注释:1)前面我写文章说过ORTC后面迟早会和WebRTC统一;2)这样看下去,以后各家浏览器上支持WebRTC是迟早的事情,这东西确实有前途。

王骅补充:最近亚马逊、思科、谷歌、英特尔、微软、Mozilla 和 Netflix 组建了开放媒体联盟,这对苹果会形成一定的压力,我们也希望看到苹果会支持 WebRTC。

上一篇:Linux 下绑定域名与IP地址


下一篇:java第十三次作业