历史背景

最近接手一个IM项目，类似微信，支持文字消息和实时音视频对讲。技术路线是基于已有的IM TCP信道发送对讲相关的控制信令。使用下来，有几个技术问题：

1. 控制信令即时性不足

如果目前有较多的文本消息未投递，那么控制信令必须等到文本消息投递完毕之后才会被投递，待客户端收到控制信令，这条信令也没有意义了。使用TCP协议的传输也没有UDP速度快，对讲呼通延迟时间久，用户会认为是系统问题。

2. 可预见的扩展

客户本身已有电话系统，客户可能会希望将所有的通信手段统一使用，于是对讲需要兼容SIP协议。

3. 私有协议设计不完善

目前的私有协议，虽然从信令的种类，使用方式上与SIP类似，但是系统总是有莫名其妙的永久不在线，永久呼不通的情况。排查到了几种会话异常结束，但是服务端未及时重置的情形，需要在客户端和服务端增加必要的超时控制、确认控制。但是，缺少文档仅有信令的作用和数据结构，并未对通信双方的状态做约定，以及异常时的处理约定。代码中的协议处理到处可见类型判断，想想都觉得累。

出于平台的扩展性和健壮考虑，决定基于已知的SIP替换掉原来的私有协议，将音视频对讲这块独立出来。从商业角度，客户不一定需要这个语音对讲，隐藏功能也太不拿客户的技术部门当回事了。从产品角度，公司又多了一套产品。从开发维护的角度，独立出来逻辑清晰，BUG寻找也容易一些，IM组和对讲组的冲突能够减少。

SIP协议栈

SIP协议栈的边界在我的认知中是不断变化的，开源的SIP协议栈声称支持的协议范围也不尽相同。这里谈一下个人体会。SIP全称是Session Initial Protocol，中文名是会话初始化协议或者会话发起协议。但是靠这个协议仅能发起一个会话，但是做什么事情还得依靠其他协议来完成，而且基于SIP的补充或者扩展协议不止一个。因此，实际使用的SIP协议栈通常都会是SIP协议+SIP协议的扩展协议（依赖SIP协议的机制，增加新功能）。

学习路线

1. RFC3261 SIP: Session Initiation Protocol

这个是大家经常说的SIP协议，说明了P2P对讲的会话发起。

2. RFC3265  Session Initiation Protocol (SIP)-Specific Event Notification

在RFC3261的基础上，增加事件订阅功能，支持SUB/PUB；

3. RFC4575  A Session Initiation Protocol (SIP)                   Event Package for Conference State

RFC3265仅说明了事件的机制，并没有定义有哪些事件。RFC4575则定义了多人对讲（会议）场景下的会议事件。

4. RFC4579 Session Initiation Protocol (SIP)              Call Control - Conferencing for User Agents

这个协议定义了在会议场景下的呼叫控制。

这里没有再向外延伸如会话描述协议（SDP），实时流媒体传输协议（RTP/RTCP），以及流媒体的各种编解码标准。目前从协议上知道，协议是由发送的信令，信令时序，通信双方状态预估和异常处理构成的。使用公有协议不一定是效率最高的，但有可能是最稳定的，接下来重点关注会议场景。SIP协议本身有诸多的开源项目已经完成，但是后面的扩展目前没有看到Java语言的版本，如果那位同仁有现成的还请贡献。