写点什么

专访 WebRTC 标准之父 Daniel C. Burnett

  • 2015-11-22
  • 本文字数:3284 字

    阅读完需:约 11 分钟

摘要: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 标签,浏览器、手机平台还有其他设备可通过一个通用的协议进行实时通信。

2015 年 11 月 11 日,由声网(Agora)与美国 TMC 联合主办的亚太区首届(WebRTC)网络实时通信大会在北京中关村皇冠假日酒店举行,声网(Agora)创始人赵斌在开场致辞中表示,“WebRTC 是互联网行业在实时通信领域影响深远的一项努力,它的目标是通过互联网为每个用户创建完整的实时音视频通话能力,同时还大幅降低了开发人员实现实时音视频通信功能的门槛。” WebRTC 大会已经由 TMC 在美国连续举办了三年,这是首次走进亚洲。

会上,InfoQ 对 WebRTC 之父 Daniel C. Burnett 进行了专访,声网(Agora)副总裁、北美业务负责人王骅补充了部分问题,以下是专访实录。(注:Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。)

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 来说是一件大事。

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

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

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

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

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

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

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

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

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

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

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

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

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

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 和微软都站在了一起,这对苹果来说是个威胁,苹果如果不参与进来,就有可能被孤立。苹果内部可能有一些考虑,这些我就不得而知了。

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


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015-11-22 17:113407
用户头像

发布了 64 篇内容, 共 23.5 次阅读, 收获喜欢 11 次。

关注

评论

发布
暂无评论
发现更多内容

Mac应用程序无法打开提示不明开发者或文件损坏的处理方法

理理

Mac软件打不开

OceanBase 第六期技术征文活动|小鱼还能“更快”吗?你来试试

OceanBase 数据库

数据库 oceanbase

数据基础设施 NFTScan 新增支持 Gnosis 网络

NFT Research

NFT 区块链、

详解基于 Celestia、Eclipse 构建的首个Layer3 链 Nautilus Chain

鳄鱼视界

初识VUE响应式原理

京东科技开发者

Vue 系统架构 Proxy 企业号 3 月 PK 榜 响应系统

写入性能:TDengine 最高达到 InfluxDB 的 10.3 倍,TimeScaleDB 的 6.74 倍

TDengine

大数据 tdengine 性能测试 时序数据库 国产数据库

面对“中国式报表”需求, 瓴羊 Quick BI的电子表格优于Tableau?

夏日星河

更人性化的无阈值监控不再为无效告警烦恼

观测云

运维 可观测性 监控告警 观测云 可观测性用观测云

开源即时通讯IM框架 MobileIMSDK:快速入门

JackJiang

网络编程 即时通讯 IM

A/B实验避坑指南:为什么不建议开AABB实验

字节跳动数据平台

大数据 云服务 数据产品 AB testing实战

k8s 探测方法总结

Geek_f24c45

#k8s

CDR2023下载安装图文教程coreldraw23

茶色酒

CorelDraw2023

FL Studio编曲2023最新水果中文版本功能介绍

茶色酒

FL Studio 21

敏捷开发工具leangoo时间线视图管理项目

顿顿顿

Scrum 敏捷开发 甘特图 敏捷开发管理 时间线

Apache Flink 1.16 功能解读

Apache Flink

大数据 flink 实时计算

「资源广场」上线|以开发者为中心,打造开放资源共享平台

Jianmu

jenkins CI/CD 镜像仓库 容器镜像 建木

详细剖析|袋鼠云数栈前端框架Antd 3.x 升级 4.x 的踩坑之路

袋鼠云数栈

前端‘’

详解基于 Celestia、Eclipse 构建的首个Layer3 链 Nautilus Chain

股市老人

打造成熟产品矩阵,瓴羊Quick BI数据可视化获认可

小偏执o

OceanBase 4.0 解读:全链路追踪要解决什么问题?从一条慢SQL说起

OceanBase 数据库

数据库 oceanbase

你也能成为“黑客”高手——趣谈Linux Shell编程语言

京东科技开发者

Linux 系统架构 操作系统 开发 企业号 3 月 PK 榜

详解基于 Celestia、Eclipse 构建的首个Layer3 链 Nautilus Chain

威廉META

云原生应用配置管理的5个最佳实践

HummerCloud

云原生

如何使用 Apache IoTDB 中的 UDF

Apache IoTDB

UDF IoTDB

Deploy Workshop|DIY部署环境,让OceanBase跑起来

OceanBase 数据库

数据库 oceanbase

类加载机制

Apache IoTDB

IoTDB

程序调试利器——GDB使用指南

京东科技开发者

c++ debug gdb 企业号 3 月 PK 榜 程序检测

mac无损音乐播放器软件:Audirvana使用设置技巧

理理

Audirvana

走进RocketMQ(四)高性能网络通信

白裤

Java RocketMQ io RocketMQ网络通信

专访WebRTC标准之父Daniel C. Burnett_JavaScript_魏星_InfoQ精选文章