sip协议
历史背景
最近接手一个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语言的版本，如果那位同仁有现成的还请贡献。
相关阅读
IP数据报 IP数据报包含两个部分：一个头和一个正文。其中，头是由一个20字节的定长部分和一个可选的变长部分组成。如下图： 下面说
全球领先的移动通信及物联网核心芯片供应商紫光展锐今日宣布，与俄罗斯手机制造商INOI签署全面合作协议。紫光展锐智能手机芯片平台
测试服务器：https://47.89.249.43:4433/ （测试时，先将本机时间设置为2018年7月之前（我证书过期了），然后使用360国密浏览器访问。360国密
1. 什么是SOAP协议 SOAP 是一种简单的基于 XML 的协议，它底层通过 HTTP 来交换信息。SOAP的优点是可以传递结构化的数据。 客
1、 前言互联网上关于RTSP的文章很多，但是大多数都是抽象的理论介绍，本文将从实际例子解说RTSP协议，不求面面俱到，但求简单易懂。RTSP