为什么没有选择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之间做个转换层而已。