默认
打赏 发表评论 4
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
访谈WebRTC标准之父:WebRTC的过去、现在和未来
阅读(109781) | 评论(4 收藏8 淘帖1
微信扫一扫关注!

前言


首届(WebRTC)网络实时通信大会期间,InfoQ 对 WebRTC 之父 Daniel C. Burnett 进行了专访,以下是专访实录。(注:Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。)

WebRTC的来历


2010年5月,Google 以6,820万美元收购 VoIP 软件开发商 Global IP Solutions 的 GIPS 引擎,将其开源并改为名为“WebRTC”。随即 WebRTC 被纳入万维网联盟的 W3C 推荐标准。2014年7月1日,WebRTC 浏览器 API 标准的1.0版由 W3C 发布。WebRTC 是一个由 Google、Mozilla和 Opera 主导的开源项目,通过在浏览器中调用简单的 JavaScript API 和标准的 HTML5 标签,浏览器、手机平台还有其他设备可通过一个通用的协议进行实时通信。

Q&A:回答关于前 Mozilla CTO对WebRTC的抱怨


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

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

Q&A:关于WebRTC为何未将通讯信令纳入标准


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

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

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


Q&A:关于WebRTC尚未正式定稿但各厂商已迫不及待的问题


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

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

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

Q&A:传统认知对 WebRTC 和云通信的束缚


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

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

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

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

Q&A:对 WebRTC 技术在中国的发展有的期望


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

答:我是 WebRTC 标准的制定者,对商业模式的话题并不方便也不适合回答。

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

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

Q&A:各大巨头对待 WebRTC 的态度


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

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

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

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

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

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

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

附录:更多实时音视频技术文章


[1] 开源实时音视频技术WebRTC的文章:
开源实时音视频技术WebRTC的现状
简述开源实时音视频技术WebRTC的优缺点
访谈WebRTC标准之父:WebRTC的过去、现在和未来
良心分享:WebRTC 零基础开发者教程(中文)[附件下载]
WebRTC实时音视频技术的整体架构介绍
新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?
WebRTC实时音视频技术基础:基本架构和协议栈
浅谈开发实时视频直播平台的技术要点
[观点] WebRTC应该选择H.264视频编码的四大理由
基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
简述实时音视频聊天中端到端加密(E2EE)的工作原理
实时通信RTC技术栈之:视频编解码
开源实时音视频技术WebRTC在Windows下的简明编译教程
网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料:
专访微信视频技术负责人:微信实时视频聊天技术的演进
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生
实时语音聊天中的音频处理与编码压缩技术简述
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端实时音视频直播技术详解(一):开篇
移动端实时音视频直播技术详解(二):采集
移动端实时音视频直播技术详解(三):处理
移动端实时音视频直播技术详解(四):编码和封装
移动端实时音视频直播技术详解(五):推流和传输
移动端实时音视频直播技术详解(六):延迟优化
理论联系实际:实现一个简单地基于HTML5的实时视频直播
IM实时音视频聊天时的回声消除技术详解
浅谈实时音视频直播中直接影响用户体验的几项关键技术指标
如何优化传输机制来实现实时音视频的超低延迟?
首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?
Android直播入门实践:动手搭建一套简单的直播系统
网易云信实时视频直播在TCP数据传输层的一些优化思路
实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:微信团队原创分享:Android版微信从300KB到30MB的技术演进下一篇:如何选择即时通讯应用的数据传输格式

本帖已收录至以下技术专辑

推荐方案
评论 4
一个不争的事实是实时音视频技术将得到更广泛的应用,希望html5标准能早日成为主流,至少对开发者而言,相关技术的门槛就要低的多了
签名: 国庆长假还没有缓过来,请让我静一静,产品狗死远点...
引用:IMDeveloper 发表于 2016-04-15 15:12
一个不争的事实是实时音视频技术将得到更广泛的应用,希望html5标准能早日成为主流,至少对开发者而言,相 ...

现在巨头都很看好这一块,但看起来短时间内还是很难改变实时音视频的开发门槛啊。http://webrtc.org.cn/webrtc-solutions-week-in-review/
“通讯应该是一种功能,而不是一种应用”  赞
引用:x931609201 发表于 2018-01-09 11:12
“通讯应该是一种功能,而不是一种应用”  赞

我倒是没注意到这句话,哈哈
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部