Browsed by
Tag: webrtc

为什么放弃了webRTC?

为什么放弃了webRTC?

首先必须要说明的是:webRTC是非常好的技术,以至于我现在仍然在怀疑,放弃webRTC是不是个明智的决定,内心依然是忐忑不安。

然而现状就是将webRTC从MSS新版本中砍掉了。下面试图说明清楚做决定时的一些考虑。

从webRTC技术的发展脉络看,感觉ta更适合于公共网络的通信,尤其是越来越像专为google hangouts服务。由于是服务于公共网络,因此“加密”提高到一个非常重要的位置,几乎达到了神经质的地步。webRTC设计之初就没有考虑过传统的VoIP网络(尽管该技术来自于收购的GIPS团队,而该团队本身就是为VoIP网络开发出身的),从传输到业务,基本都特立独行。当然,这没什么不好,只是由于与传统VoIP网络切割开来,实在让人经常感到惋惜。

既然没有考虑传统VoIP网络,当然就更不可能考虑网络部署的多样性。全方位加密固然让自己显得安全,带来心理上的安慰,但也增加了网络部署的复杂性(VoIP本身已经够复杂了)。就一般的VoIP应用而言,“salt+MD5”以及SRTP已经足够保证通信的安全性和私密性。而最新的webRTC(不特别说明的话,这里我们总是指Chrome的webRTC实现)要求getUserMedia等操作必须是来自加密(HTTPS)的网站,websocket也必须进行加密。这也就是说,用户必须要为webRTC服务器(通常也是呼叫服务器或者IPPBX)部署单独的签名加密(TLS或者SSL)。对于提供公众服务的网站而言,部署TLS/SSL不是太大问题,而要求中小企业申请签名并部署在呼叫服务器中,这毫无疑问极大地增加了系统的复杂度,增加了部署难度,而且这样做的意义又有多大了?在企业通信网络里与其这样增加复杂度(网络复杂度和管理复杂度),还不如干脆直接建立VPN网络,方案很成熟,加密更全面,保护更周到,方式方法也简单得多。

这就是我们感觉webRTC只适合公众网络并且已经神经质的原因之一。何况,“加密”有时候更多的是个管理问题而不是技术问题。

webRTC另一个宏大的目标是提供各平台统一的用户体验。愿望是很美好的,但是是否能实现值得商榷。把所有的处理都放入浏览器,固然增加了可移植性,但最大的问题也就是牺牲了平台的独特性和高效性。比如在移动平台,webRTC的耗电量就明显偏高。而且在移动平台各种莫名其妙的设定,极大地损害了用户体验,比如播放ring-back tone,居然要求用户必须点击一个按钮才能继续(是我out了么?),这实在是太扯了。

而最被我们诟病的是兼容性。webRTC基本没有什么兼容性可言。按道理已经发布这么久了,多少应该在一些关键点上考虑一下兼容性,然而并没有。这对一个像google hangouts这样的网站来说,不是大问题,用户无非升级一下chrome好了。而对部署在许许多多用户voip网络中的PBX或者webRTC服务器而言,就是噩梦了。用户升级了Chrome,就必须同时升级服务器,如果不升级服务器,就必须降级Chrome。与之相比,microsoft对兼容性的考虑简直贴心贴肺。

这种对兼容性的唾弃有时候甚至直接表现在产品本身。比如当初的Gtalk,直接就放弃了,我们花费大量时间精力对接Gtalk,最后也是然并卵。对webRTC也会产生同样的顾虑。

webRTC当然有很多非常优秀的技术特点,比如源自GIPS的回音消除技术、超强的语音编解码技术等。思虑再三,决定还是不再跟随,砍了算了,以后再说吧。

为什么没有选择sipml5

为什么没有选择sipml5

有多种技术和实现方式可以将SIP与webRTC两个世界连接起来,比如我们的miniWebPhone/miniSIPServer以及sipml5等。当然,最早出现的是sipml5以及与TA配套的webrtc网关。既然已经有了sipml5,为什么我们在设计和实现miniWebPhone(以下简称MWP)时,不采用现成的解决方案呢?

回答这个问题之前,请先粗略的看一下完成后的情况。sipml5的javascript文件大小超过2MB,而MWP的javascript文件是20KB。仅仅对比这两个数据,我就认为我们的决定非常正确,sipml5实在是太臃肿了!

造成sipml5如此庞大的根本原因在于:TA的目标是在浏览器端用javascript来实现一个完整的SIP协议栈及呼叫处理过程。理想很丰满,现实太骨感。

我想sipml5的设计者被HTTP与SIP之间的相似性给迷惑了。两者的确都是基于文本格式,SIP甚至都基本遵循HTTP的消息定义,但是两者却有最根本的区别:HTTP本质上是无状态、无层次的协议,而SIP是有严格的状态,不仅有transaction的状态,也有session和dialog状态。同时SIP又是多层次的,包括transaction、session、UA等不同的层次。当你用一个无状态、无差别的协议模式强行去套一个多状态、多层次的模式,工作量无疑是巨大的。

而对javascript语言而言,其实并不擅长去解析或者分析类HTTP协议格式的文本。而SIP协议虽然采用HTTP协议的文本格式,但是在会话过程中,不仅仅要解析到header层面,还要进一步解析内部各种参数。这种情况就更加不是javascript擅长的。因此可以看到sipml5不得不耗费大量的处理过程去解析SIP协议的细节。javascript擅长处理什么文本格式呢?JSON!因此在miniWebPhone的设计和实现过程中,我们理所当然地采用JSON来重新定义消息格式。

让我们再看看服务器端的设计。这又是另一个让人很纠结的地方。由于浏览器不支持开UDP和TCP连接,只支持websocket连接(本质上其实还是个TCP连接),sipml5的设计者们不得不引入SIP over websocket(这个定义到现在还处于draft状态)。而这要求客户端和服务器两端都必须修改才能支持。虽然websocket与TCP几乎没有区别,但是对SIP协议栈、SIP会话层面的处理来说,可不是仅仅重用TCP处理那么简单,服务器端的工作量同样巨大。

说到这里就稍微跑跑题,让我们先吐槽一下浏览器的实现者们。当浏览器支持websocket的时候,实际上就已经支持了TCP,为什么不向应用层开放TCP连接能力?websocket本质上就是个TCP连接,只有开始的两个握手消息是HTTP格式,后续跟HTTP一点关系都没有。同样,既然已经支持了webRTC,为什么不向应用层开放UDP连接能力?打开一个SRTP端口和打开一个UDP端口同样一点区别都没有。如果浏览器开放了TCP和UDP连接能力,哪怕仅仅开放UDP能力,sipml5的开发者也不用一边哭一边改设计,更不用搞出“SIP over websocket”这么个爷爷不疼、姥姥不爱的东西了。

让我们回到原点。分析了这些困难和不足,既然服务器(或者网关)死活都要修改,那我们为什么不把工作量集中到一端,从而解放另外一端?因此我们放弃sipml5,重新思考:

客户端无疑还是必须基于webRTC和javascript的。但是消息格式不再是HTTP或者SIP格式,而是JSON格式,这样javascript就可以轻松处理。客户端采用无状态方式,呼叫的状态由服务器端来维持。这就是MWP的javascript文件仅仅20KB就ok了的根本原因。

既然客户端采用了JSON格式的消息,因此服务器端也要相应作出设计。主要工作无非就是转码成SIP消息格式并维持websocket连接,其他处理仍然可以沿用目前已有的SIP流程。而我们要做的,仅仅是在客户端和SIP之间做个转换层而已。

webRTC调试方法小结

webRTC调试方法小结

前段时间完成了miniWebPhone V1版本的开发,基于Chrome浏览器,采用了webRTC技术。在开发过程中,发现其实webRTC技术使用起来还是不太方便,有很多让人感觉很困扰的地方。基本上只有VoIP领域专家才能明白诸多操作以及参数的意义,即便是这样,仍然需要根据Chrome的输出信息来了解Chrome中webRTC的各项细节。

有几种方法可以了解webRTC过程中的细节信息。

方法1:chrome://webrtc-internals/

这个方法是最简单的。在Chrome地址栏中输入上述命令,即可了解webRTC的过程。不过这种方法输出的信息非常粗略。如果您对webRTC很熟悉,那么可以从中了解一些有用的信息。如果您对webRTC不熟悉,那TA的信息您肯定看不明白。

方法2:chrome日志

这种方法我经常使用,而且推荐在linux环境(例如Debian)中使用。实际上,我不知道windows系统下如何看Chrome的日志。Chrome的日志很详细,基本上会输出每个步骤详细的信息。

在linux终端窗口用以下命令启动Chrome即可:

google-chrome --enable-logging=stderr --log-level=4 --vmodule=*libjingle/*=3,*=0

方法3:Chrome源代码

日志可以帮助我们了解大部分webRTC的细节,但是webRTC某些实现仍然是有问题或者说让人困扰的(例如对ICE的处理主、被叫流程不一致,错误处理没有输出日志等),此时直接看代码就是比较好的解决方法。完全、彻底地阅读Chrome是个不可能完成的任务,只能结合Chrome日志去追踪相应的代码。

基于HTML5的SIP客户端

基于HTML5的SIP客户端

项目名称是:sipml5,地址:http://code.google.com/p/sipml5/

该项目基于Google的WebRTC项目。这点与我以前写的一篇blog吻合,将SIP引入WebRTC不仅是可能,而且已经有人搞定了!

粗略地看了一下该项目的情况,界面是比较丑陋,不过看介绍应该是基本可用的。这是个好消息啊,尤其对企业用户而言,可能都不需要每个员工安装部署SIP终端,直接部署该终端即可,再结合云通信平台,整个系统都能简化不少。

如果该项目能覆盖Chrome, Firefox以及IE三个主要平台,基本就可以在实际环境中部署。非常让人期待啊。

WebRTC与SIP

WebRTC与SIP

毫无疑问,WebRTC是个好东西。之所以这么说,是因为他居然开源了GIPS的audio引擎。GIPS的回声抑制、噪声消除等方面的技术,几乎独步天下。当年GIPS仅靠这些个算法包,就活得有滋有味。Skype、MSN、QQ等等,凡是做IP语音通信的,都无一例外地使用了GIPS的技术,这里还没包括各硬件芯片厂商。

Google居然将它开源了,牛啊!实在是让人佩服!

既然已经开源了,我们也希望在已有的free项目中引入webrtc的相关模块(主要是EC, NS等)。看了一下webrtc的文档(目前还是非常简陋),忽然有个想法,其实我们没有必要将webrtc的模块引入我们的项目,相反,我们只需要基于webrtc,将我们已经实现的SIP会话层以及GUI层添加到webrtc中。从webrtc的模块分层看,这样似乎更可行一些。

替换掉webrtc的会话层,或者新增SIP会话层似乎都是可行的。不过编译webrtc实在是麻烦,居然要vc2005(还不能是express版本)/ Win7 SDK / DirectX SDK等等,个个都是巨无霸。

另外,这个对Speex项目应该也有影响吧?Speex项目自己实现了一个audio引擎,不过其中的EC,NS等关键部件效果还是不太让人满意,不知道他们会不会从webrtc中获得灵感。

Google开放实时通信框架WebRTC

Google开放实时通信框架WebRTC

据说WebRTC是Web方式进行语音、视频实时通信的框架。项目地址如下:

http://sites.google.com/site/webrtc/ (需翻墙浏览?)

暂时还不太清楚这个技术的细节,不过如果像Google宣传的那样,就可以实现高质量的web通信方式。传统的SIP软终端就面临很大的挑战,从另一方面来说,可能也是一次打破现有格局的机遇。