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