SIP协议详解

SIP协议可能大家有所接触。那么则个协议的意思是会话初始化协议，是一种应用层控制协议。那么更多具体的功能和应用是什么呢？它可用来创建、修改或终止多媒体会话，如因特网电话呼叫。SIP 能够邀请参与者加入已存在的会话，如组播会议。现有的会话中可以添加或删除媒体。SIP协议支持名称映射和重定向服务，其支持用户移动性。不管用户网络位置在哪，用户只需维持单一外部可视标识符。

SIP 在五个方面支持创建和终止多媒体通信：

用户定位：决定用于通信的终端系统的确定；

用户可用性：决定被叫方是否愿意加入通信；

用户能力：媒体和媒体参数的确定；

呼叫建立：“响铃“，主叫方和被叫方的会话参数的建立；

呼叫管理：包括传输和终止会话、修改呼叫参数和调用服务。

SIP协议可以结合其它 IETF 协议来建立完善的多媒体结构，如提供实时数据传输和服务质量（QOS）反馈的实时传输协议（RTP）、提供流媒体发送控制的实时流协议（RTSP）、为公用交换电话网络（PSTN）提供网关控制的媒体网关控制协议（MEGACO），以及描述多媒体会话的会话描述协议（SDP）。因此，SIP 需要与其它协议协同作用来为用户提供完善的服务。然而 SIP 的基本功能和操作并不依赖于这些协议。

SIP 提供了一组安全服务，包括防止拒绝服务攻击、认证（用户对用户和代理对用户）、完整性保护和加密及隐私服务。

SIP协议同时支持 IPv4 和 IPv6 。关于因特网电话会话，SIP 做如下工作：

通过 SIP 地址识别主叫方和被叫方。当建立一个 SIP 呼叫时，主叫方首先定位适合的服务器，然后发出一个 SIP 请求。最通常的 SIP 行为是邀请。SIP 请求会被代理重定向或者触发一系列的新 SIP 请求，而不是直接到达目的被叫方。用户可以通过 SIP 服务器注册他们的位置。SIP 地址（URL）可以嵌入到网页中，因此只要点击一下就可以和对方建立呼叫会话。

协议结构

SIP 信息可以在 TCP 上传输也可以在 UDP 上传输。SIP 信息是基于文本的，采用 UTF-8 编码中的 ISO 10646 字符集。信息的每一行必须通过 CRLF 终止。大多数信息语法和头字段类似于 HTTP。SIP 信息可以是请求信息也可以是响应信息。

一个请求信息具有以下格式：

Method

Request URI

SIP version

Method ― 资源上所执行的方法。可能的方法有：Invite、Ack、Options、Bye、Cancel 和 Register。

Request-URI ― 指一个 SIP URL 或一个通用 URI；是请求要被寻址到用户或服务。

SIP version ― 正在使用的 SIP 版本。

响应信息头的格式见下图 ：

SIP version

Status code

Reason phrase

SIP version ―正在使用的SIP协议版本。

Status-code ― 3 位整数结果代码，用于试图了解和满足请求要求。

Reason-phrase ― status code 的原文描述。

sip事务的概念：一个sip请求以及由它触发的一系列应答（包括临时应答和一个最终应答）。

sip请求有6种（核心规范定义的，也有扩展），也叫6个方法(Method字段标识)：INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER

sip 请求的格式包括请求行(如INVITE sip:192.168.101.30 SIP/2.0)，sip应答的格式包括状态行(如SIP/2.0 100 Trying)；sip应答的状态码从100到699，其中100~199是临时(provisional)应答。

INVITE请求是三次握手机制，其他请求都采用两次握手机制。

CANCEL 请求用于取消悬而未决的事务，我的理解是一方发出INVITE，但是另一方始终没有做出应答，发出200OK消息（超过了默认的振铃时长），那么UAC会 自动发出一个CANCEL请求，UAS返回200OK，并且同时发出487状态码的应答，UAC再对收到的487消息发出ACK确认，即最开始的 INVITE和487以及ACK构成三次握手。

OPTIONS请求用于询问服务器的性能情况，包括这个服务器所支持的方法（可能会有扩展方法）和会话描述协议。

代理服务器的三种类型：保留呼叫状态代理、保留状态代理、不保留状态代理。这三种类型的代理在处理能力和所占用资源上有差别，在代理分发中我们采用网络核心无状态，而在流量较小的网络边界采用智能性高的保留（呼叫）状态服务器处理路由。

sip消息编码采用文本方式（即使用字符串），相对的是二进制的编码方式，前者易于调试和扩展，后者则有利于节省带宽。

sip标题头：
CALL-ID 字 段用于标识一个特定邀请以及与这个邀请相关的所有后续事务（即标识一个会话），比如一方发起邀请加入一个国际象棋的会话，那么INVITE请求以及应答， BYE请求以及应答都共享一个CALL-ID，因为这两个事务都属于一个特定邀请。而两个用户之间可以同时存在多个邀请（比如在下象棋的同时发起聊天的邀 请），那么一个邀请中的后续事务将通过这个邀请特有的CALL-ID来区分，如一方发出BYE消息来结束聊天，但是下棋仍然进行中，那么另一方将根据 BYE消息的CALL-ID来确定要结束的究竟是哪一个会话。

CSeq 字段是用来给同一个会话中的 事务进行排序的。可以理解为，会话由CALL-ID来标识，会话中的事务则由CSeq标识。除了ACK请求和CANCEL请求，INVITE之后的请求中 CSeq字段的数字是最初请求(INVITE)的CSeq递增的结果。而ACK和CANCEL请求则拥有与它所确认（取消）的请求相同的CSeq数字部 分，只是方法名不同。

(sip标题头续)
Contact 字段是被呼叫方发送200OK消息时带上的，包含了被叫方的真实IP，这样sip服务器在路由第一个INVITE请求之后就可以被卸载掉（越过），不再需要存在于信令路径中。

Recode-Route和Route字 段是用来使sip服务器保留在每次请求中，不被绕过。Record-Route字段由信令路径上的服务器添加（每经过一个信令路径上必须存在的代理，就添 加一个Record-Route标题头），maddr参数包含该代理的IP地址。被叫方发出的200OK应答包含Record-Route和 Contact字段（Record-Route可能有多个），呼叫方收到200OK后根据这两个字段创建用于后续请求的Route标题头（可能有多个）， 其包含的是信令路径上的下一跳的下一跳的（hehe，有点别扭，不过意思是对的）真实IP。

To 字段 总是包含被呼叫方的地址（通过sip代理时是公用地址，点对点时是真实ip），要注意的是区别该标题头和sip消息请求行中的Request-URI。 To在信令路径中不会被代理改变，然而Request-URI包含的是信令路径中下一跳的地址，因此在路途中被每个代理改变。

Via 字 段存储所有处理请求的代理地址（包括用户代理和sip代理），它可以用来检测路由循环，也用于使应答消息经过请求消息来时相同的路径（方向相反）。因此， 在请求消息发送时，via标题头的数量是随着跳数逐渐增加的，而应答消息返回时，via标题头的数量则逐渐递减（每经过一跳则剥离一个有它自己地址的 Via标题头）。
(sip标题头完)

sip消息可能含有消息体（一个或多个），通常是会话描述符，也可以是照片或其他附件。一般情况下，消息体只对UA有意义，因此可被端到端加密。有时候，sip代理处于控制的原因也需要检查被交换媒体的信息。

 NVITE事务：

SIP使用UDP传输协议来传送INVITE消息时，要使用逐 跳重传机制保证INVITE的最终传送，即用户代理UA和sip代理proxy都要保证INVITE到达下一跳，下一跳收到时会返回一个临时应答 （proxy返回100Trying，UA返回100Trying和180ringing），代理在限定时间内收不到应答即会重传INVITE。

临时应答（100~199）用于阻止逐跳INVITE重传，没有端到端的可靠传输，也就是说当被叫方返回180应答时，如果在路径中途丢失，也不会重传。

最终应答（200~699）能被保证到达它们想要去的目的地。
成 功应答（200~299）被可靠地传送到呼叫方UA，但不是使用逐跳重传机制。只有呼叫方UA能为最终成功应答发送一个ACK（直接发送到被叫方UA）， 如果成功应答在路径中途丢失或者UA发出的ACK丢失，那么被叫方会在限定时间内收不到ACK时重新发送最终应答，直到收到ACK的确认。
非成功最终应答（300~699）使用和INVITE一样的逐跳机制。被叫方用户代理将持续重传非成功应答（给前一跳），直到收到ACK为止（proxy也可以为非成功应答发送ACK）。 
CANCEL事务：
CANCEL事务与INVITE事务都是逐跳事务，但是处理方法不同，路径上的每一个代理收到CANCEL请求时，都会发送一个最终应答来响应（而不是发出临时应答），并且向下一跳发送一个CANCEL请求