简介
SIP，全称Seesion Initiation Protocol（会话发起协议），是由IETF制定的一个多媒体通信协议。
它是一个基于文本的应用层控制协议，用于创建、修改和释放一个或多个参与者的会话。
如果把一个多媒体会话分成信令和媒体两部分，那么SIP则处于信令的位置。
SIP协议族由其本体及其扩展组成。其中有不少都经过了版本的更替。
以下内容参考选用的是SIP协议族的现行标准（如SIP本体选用的是RFC3261而不是RFC2543），扩展部分则只选用了部分比较常见的来进行介绍。
SIP协议框架
SIP 可以分为四层，分别为协议层、传输层、事务层和事务用户层。
协议层（Protocol）：SIP 协议的基础，规定了 SIP 的语法和编码。
传输层（Transport）：这个我们就比较容易顾名思义了，是传输 SIP 消息用的。
事务层（Transaction）：一次请求以及其相关回复组成一个事务。
事务用户（Transaction User，简称 TU）：协议层面上在事务层之上，UA 核心和代理的核心都属于 TU（见下文「SIP 角色」一节）。
SIP消息
SIP 协议是基于文本的，采用请求-响应式。
SIP 的请求和回复统称为 SIP 消息。
内容有请求方法行、请求头、请求体，响应状态行、响应头、响应体，总之和 HTTP 很像就是了。
基本的请求方法有 OPTIONS、REGISTER、INVITE、ACK、CANCEL、BYE。
值得注意的是，虽然 SIP 是类似于 HTTP 的一种文本传输协议，但是 SIP 中的回复有两类：
临时回复 - 在最终回复前发的回复，和一些中间状态有关
最终回复 - 结束一个请求
一个请求在得到最终回复前是可能会有多个临时回复的（下面会有例子说明）。
传输层
SIP 可以运行在多种转输协议之上，如 UDP、TCP、SCTP 等。
SIP事务模型
SIP 也可以说是一种事务性的协议，一个 SIP 事务由一个请求以及其相关回复组成。
根据处理事务的角色，事务可分为两种：
客户端事务 - 请求方
服务端事务 - 回复方
根据请求的方法，事务也可以分两种：
INVITE 事务
非 INVITE 事务
注：因为 INVITE 比较特殊，所以 INVITE 有特殊的事务模型。
标准中对于各种细分的事务都给出了状态机，这里不详细展开。
SIP角色
在逻辑上，SIP有几类角色。 注册商（Registrar） 接收REGISTER 请求，维护一个目录服务 终端（UA） 发起和回应请求的角色，可再细分为：UAC请求发起方
UAS请求回复方
代理（Proxy server） 转发消息，可分为两类：有状态代理
无状态（仅转发）代理
重定向服务器（Redirect server） 不转发任何消息，重定向所有请求（CANCEL 除外）到别的地方这些角色分类只是逻辑上的。物理上，注册商和各类服务器常常是一起的。参与到事务中的服务器也一样是UA。注册
REGISTER方法，向注册商注册自己的一个或多个别名，以便其他人可以使用这些别名进行沟通。以上是典型的注册流程示意图。
图中的 Register、Location Service、Proxy 它们都是逻辑上的划分，实际上，它们基本都是由一个东西担任，就是被我们称之为 SIP 服务器的东西。
能力查询
OPTIONS 方法，查询对方支持哪些方法，和 HTTP 中的类似。
发起会话
NVITE 方法，发起会话。
近似来讲，就是一个打电话的过程。
和发起会话相关的有这几个请求：
拨号 INVITE - 发起会话
取消 CANCEL - 取消建立中的会话
改变 re-INVITE - 改变参数
再见 BYE - 结果已建立的会话
在发起会话的过程中一般都会包含一个媒体传输协商的过程（详见 RFC3264 Offer/Answer Model），它是借助 INVITE 请求和其回复完成的。
需要注意的是 re-INVITE 请求，实质上它也是一个 INVITE 请求，是在已经建议的会话中再次发起 INVITE 请求的这一个过程，它的用处是改变会话的参数和流媒体的参数，不会直接影响到会话的状态。
例子:
像这里的 1XX 类型的回复就是临时回复，一个事务中，可以有多个临时回复。
代理
中转 SIP 消息，一方面，可以使用别名与其他设备沟通，另一方面，用来跨越逻辑区域。
代理分为有状态和无状态两种。
无状态代理
服务器只工作在传输层，只负责转发消息，对事务层不会产生影响。
有状态代理
代理服务器参与了事务层，对于一个 SIP 请求中的请求方，服务器是 UAS，而对于响应方，服务器是 UAC。
代理服务器对转发一个请求的时候，可以转发给多个目标，SIP 中称为 forking。
典型的示意图如下：
P.S：SIP 的流程上和真实的打电话场景十分拟合。呼叫中、对方已振铃这些状态，和 SIP 发起会话的过程有着惊人的对应关系。
INFO方法
SIP 扩展，用以在会话中来发送不影响会话状态的信息。
RFC2976 定义了十分简单的 INFO 方法，RFC6086 重新定义了 INFO 方法，兼容 RFC2976，并给其增加了一个 Info Package 机制，以便通信双方能知道对方可以接收什么样的信息。
INFO 方法只能在会话中使用。
事件模型
SIP 扩展，提供了一个发布/订阅事件的框架。
事件只能在会话中使用。
基本模型如下：
即时消息模型
SIP 扩展，通过 MESSAGE 方法来传递即时消息。
特点是，消息可以在会话中，也可以在会话外，每个消息之间是独立的。
SIP的部署方式
在开始学习 SIP 之前，SIP 给我的印象是我一定要有一个服务器才可以运行 SIP，实则不尽然。
由上面角色的介绍可以看出来，服务器可以完成注册、代理、转发、重定向这些功能。
要发起一个 SIP 会话，这些都不是必须的。理论上，两个终端可以在没有任何服务器参与的情况下直接建立会话。
当然，SIP 服务器也有它的应用场景，在实际的部署中，没有服务器反倒是用处不大。
总结各类 SIP 服务器在部署上的特点如下：
最后，服务器的部署也不是只能选择一种，多种服务器同处一个系统也是很实用的部署方式。
以上，本文旨在介绍 SIP 中的一些概念和基本流程，没有过多涉及到 SIP 协议消息中的细节。
参考
RFC3261 - SIP: Session Initiation Protocol
RFC3263 - Session Initiation Protocol (SIP): Locating SIP Servers
RFC3264 - An Offer/Answer Model with the Session Description Protocol
RFC3265 - Session Initiation Protocol (SIP)-Specific Event Notification
RFC3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging
RFC6086 - Session Initiation Protocol (SIP) INFO Method and Package Framework