史上第一次,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即将在中国出现“井喷”!肉伯特君会一直陪伴在你身边。
——————————————————————
抚摸一下,肉伯特君需要你的关怀。
至此,肉伯特将准备好实时通信小酒供各位品尝。