消息确认

        UA之间的大部分SIP请求是端到端消息。两个UA之间的代理服务器只是简单地转发它们所收到的消息，并用依赖UA生成确认或应答消息。

        上述普世规则有一些意外的场景。CANCEL方法(用于终止未建立的呼叫或查找)是一种逐跳(hop-by-hop)处理的请求。代理服务器收到CANCEL请求之后，立刻向发送方回应一条200 OK，并生成一条新的CANCEL请求，然后在下一跳将其转发给与原始请求相同的目标集 (200 OK与转发CANCEL之间的顺序并不重要) 。整个过程如下图所示。

 

        另一个意外场景是INVITE请求收到3xx、4xx、5xx或6xx应答时。与2xx的ACK是由终端生成的不同，3xx、4xx、5xx或6xx应答的ACK是逐跳确认的。代理服务器收到这类应答时，立刻生成一个ACK发回给应答发送方，并把应答消息转发给下一跳。下图展示了这种逐跳确认机制。

 

        ACK消息只用于确认收到INVITE请求的最终应答。其它请求类型，没有确认消息。当UAS收到请求的重传消息时，它就能监测到应答丢失事件。

 

 

消息可靠性

        SIP定义了可靠性机制，该机制用于非可靠传输，比如说UDP。当SIP使用TCP传输时，不使用自身的可靠性机制，因为它假设TCP会负责丢包重传，并通知客户端XX服务不可达。

        使用UDP传输SIP时，总是要承受丢包或乱序的风险，因为UDP只保证数据报的正确性。UAS验证并解析SIP请求，以确保UAC所创建的请求没有缺少必须的头域或其它语法冲突而导致出错。SIP的可靠性机制包括以下几点：

• 重传定时器

• 增加命令***CSeq的数值

• 肯定的确认

 

        SIP的重传取决于请求的方法。INVITE请求定义了一套机制，称为INVITE事务；其它方法定义了另一套机制，称为非INVITE事务。

        对于非INVITE事务，UAC或有状态代理服务器在生成或发送一个新的请求时，启动一个SIP定时器T1。如果T1触发时，没有收到请求对应的应答(标识符匹配，包括本端tag、远端tag、Call-ID和CSeq)，那么重发一次请求。在请求重传之后，下一个定时器周期增倍，直到周期达到上限T2。如果收到临时应答(信息类1XX)，UAC或有状态服务器立刻切换到定时器T2。这个有上限的指数退避过程将持续64倍的T1周期，如果还是没收到最终应答，请求将被判定死亡。有状态代理服务器收到重传消息时直接丢弃，并按自己的定时器周期继续执行重传方案。通常，(收到重传请求时)它会重传最后一个临时应答消息。下图以REFER请求为例，显示非INVITE事务的重传机制。

                SIP非INVITE事务的可靠性

 

        对于INVITE事务，重传机制稍微有些不同。INVITE请求的重传周期始于T1，每次重传之后定时器周期倍增。INVITE重传机制持续的上限是64倍T1，超过这个期限没有收到最终应答则判定请求死亡。如果收到临时应答(1XX)，那么立刻停止重传。代理可以在三分钟之后放弃事务状态。有状态代理必须存储转发的请求或响应消息32秒。建议的T1、T2默认值分别为500毫秒和4秒。定时器T1应该是网络中往返时间(RTT)的估计值。允许调大，但不允许调小，因为这会导致更多的重消息消息。请参考RFC3261 的表4以了解SIP定时器的信息摘要。下图展示了这INVITE事务的重传机制。

                                SIP INVITE事务可靠性

        请注意：CSeq编号的中间间隙并不一定表示消息丢失。在鉴权示例中，如果信令路径中的代理要求鉴权，那么并不是UAC生成的每条请求(以及由此产生的CSeq)都能抵达UAS端。