SIP协议之事务(transaction)及INVITE事务

一、SIP事务

  SIP事务（SIP Transaction）：SIP 事务发生在客户端和服务器之间并且由从第一个从客户端发送到服务器的请求直到最后一个。

  SIP协议是一个事务协议，组件间的交互是由一系列独立的消息交换完成的。具体来说，一个SIP事务由一个请求和任意个应答组成，包含0个或多个临时应答以及一个或多个最终应答。在实际应用场景中，由INVITE请求发起的事务称为Invite事务（INVITE transaction）， 如果最终应答不是2xx，则该事务也包含ACK，如果应答是2xx, 则ACK不被认为是事务的一部分。针对上述ACK的区分，主要是源于发送200(OK)应答到UAC的重要性，为了发送200(OK)到UAC,UAS负责重传，而ACK只有被UAC重传，因此ACK被认为是UAC自己的事务逻辑。

二、客户端事务与服务端事务

  SIP事务分为客户侧和服务侧。客户侧事务称客户端事务（Client Transaction），而服务侧事务称为服务端事务（Server Transaction）。客户端事务发送请求，服务端事务响应并回送应答。客户端事务和服务端事务是一个逻辑上的功能定义，任何网元(UA)在发出请求时就是该事务的客户端，而接收处理请求的一方则是该事务的服务端。
  如下事务关系图：UAC完成客户端事务，它的外部代理完成服务端事务，而外部代理服务器也作为一个客户端事务，发送请求到内部代理服务器的服务端事务。代理也扮演客户端事务来发送请求到UAS的服务端事务。

  无状态代理不包含客户端或服务端事务， 客户端事务从事务的使用者（“Transaction User" or TU，可能是存在于UA或有状态代理中）接收请求，然后可靠的传输到服务端事务。客户端事务也负责接收服务端发回的应答并传回给事务使用者。 相应的，服务端事务接收请求并传递到事务使用者，并且接收事务使用者的应答并发回到客户端事务。

  客户端事务通过状态机实现它的功能性。事务使用者通过接口和客户端事务通信。当事务使用者希望初始化一个新的事务时，它创建一个客户端事务，开始执行它的状态机，合法的应答会被传递给客户端的事务使用者。

  依据请求的方法，有两种类型的客户端事务状态机。请求方法是INVITE时，称为INVITE客户端事务（INVITE client transaction）;其它的除了INVITE请求方法时，称为非INVITE客户端事务（non-INVITE client transaction）， ACK没有客户端事务，如果事务使用者希望发送ACK，它传输一个ACK到传输层去传输。

  服务端事务负责将请求发送到事务使用者（TU）和应答的可靠传输，这是通过状态机完成的。 服务端事务是核心在收到请求后建立的。和客户端事务一样，状态机行为依赖是否收到的请求是一个INVITE请求, 分为INVITE服务端事务(INVITE server transaction）和非INVITE服务端事务（non-INVITE server transaction）

三、INVITE事务

  INVITE请求是SIP协议中最重要的请求，用来发起语音/视频通话，而INVITE请求的处理基于INVITE事务，因此熟悉和掌握INVITE事务的处理逻辑和原理对于分析和解决INVITE相关的异常问题有事半功倍的用处。

  INVITE事务不同于其它非INVITE事务，因为INVITE事务有一定时间的持续周期。正常情况下，需要人的操作（如摘机等）来应答INVITE请求。INVITE事务分为INVITE客户端事务和服务端事务两种。

  INVITE事务由三次握手交互组成，客户端发送一个INVITE请求， 服务端事务发送应答，最后客户端事务发送ACK,有点类似TCP三次握手机制。

  对于不可靠的传输方式（如UDP），客户端事务以T1秒为第一次重传的间隔重传INVITE请求，之后重传间隔为前一次重传间隔的2倍。T1认为是一次请求/应答的往返时间，默认是500ms.几乎所有的事务定时时间都是在T1的基础上进行扩展的（比如2T1、1T1表示2倍的T1时长、1倍的T1时长)，并且通过改变T1来调节事务的定时器周期。

  在使用可靠传输方式时，请求不会被重传。在收到1xx临时应答后，任何重传都会停止，然后客户端等待后续的最终应答。服务端事务能够发送额外的1xx临时应答。1xx应答一般不会被可靠传输。 最终，服务端事务决定发送一个最终应答。对于不可靠传输方式，应答会被周期性的重传。对于可靠传输方式，应答只发送一次。客户端收到的每个最终应答，客户端事务发送ACK，来结束应答消息的重传。

3.1 INVITE 客户端事务

INVITE 客户端事务英文全称INVITE Client Transaction。
客户端状态机如下图：

客户端状态机逻辑说明：
  TU初始化INVITE客户端请求后，进入初始化状态”calling",传递请求到传输层。如果使用的是不可靠的传输方式，客户端事务必须启动定时器A，超时时间为T1秒.如果使用的是可靠的传输方式，客户端事务不应答启用定时器A。定时器A控制请求的重传。对于任何传输方式，客户端事务必须启动定时器B，超时时间为64*T1秒。定时器控制事务的超时。

  当定时器A超时时，客户端事务必须重传请求并以2倍的T1时间来重置定时器。当2*T1的定时器A超时后，请求必须再次重传。重传的流程必须继续，间隔时间为前一次的2倍。 这些重传只应该在客户端事务处于“calling"状态的时候执行。

  T1默认值是500ms,T1是一个客户端事务和服务端事务之间请求/应答的往返时间，这个时间是一个估算值。在封闭的私有网络中时，T1使用更小值。如果确认RTT更大时，则使用更大的值,比如在高延迟的网络环境中。无论T1选用多大的值，必须使用指数级超时重传的机制。

  如果定时器B触发，而客户端事务依然处于“calling"状态时，客户端应该通知事务使用者（TU）事务超时。客户端事务不产生ACK。64*T1相当于使用不可靠传输方式时重传7次请求的时间总和。

  如果客户端事在"caling"状态务收到一个临时应答（provisional response，如1xx), 将转换到”proceeding"状态。

  在porceeding状态时，客户端不再重传请求。进一步讲，临时应答必须传送到事务使用者。处于"proceeding"状态时收到的任何后续的临时应答都必须传送到事务使用者（TU），当处于“Calling"或者”Proceeding“状态时，收到300-699状态码的应答必须将客户端事务转换到”Completed"状态。客户端事务必须将应答上传到事务使用者（TU），并且客户端事务必须产生一个ACK请求（即使传输方式是可靠的），然后发送到和原始请求相同地址、端口、传输方式。客户端事务在进入“completed"状态后，应该开始定时器D，对于 不可靠传输方式，超时时间至少是32秒;如果是可靠方式，可设置为0秒。

  定时器D反应的是在不可靠传输方式下，服务端事务停留在”completed"状态的时间。这个是和INVITE服务端事务定时器H相等的，默认是64*T1.然而，客户端事务不知道服务端使用的T1值是多少，所以，一个绝对的最小值32秒被使用来代替基于T1的定时器D。处于“Completed"状态时，收到任何最终应答的重传时，必须相应的等重传ACK，但是新收到的应答不会被上传到事务使用者。

  如果客户端事务处于”Completed"状态时定时器D触发，则客户端事务必须切换到终止（terminated)状态。

  无论是在“Calling"还是”Proceeding"状态，收到2xx应答必须让客户端事务进入“Terminated"状态，并且2xx应答必须被上传到事务使用者（TU），而这个应答的处理逻辑依赖于事务使用者是一个代理核心还是一个UAC核心。UAC核心将对这个应答产生ACK，而代理核心总是向上游转发200(OK), 这种不同的处理方式源于处理是否发生在事务层面。

  客户端事务在进入”Terminated"状态后必须被销毁。实际上这是非常必要的。原因是INVITE的2xx应答处理不同，每一个应答被代理转发，并且UAC的ACK处理是不同的。因此每个2xx需要被传输到代理核心或者UAC核心 。

  无论什么时候传输层收到应答，如果传输层没有找到匹配的客户端事务，这个应答会被传递到核心。这是由于匹配的客户端事务已经被第一个2xx应答销毁，后续的2xx应答找不到匹配的客户端事务而被传递到核心。

3.2 INVITE服务端事务

INVITE服务端事务英文全称INVITE Server Transaction。
INVITE服务端事务状态机图：

服务端状态机逻辑说明：
  当服务端事务被一个请求创建时，就进入”Proceeding“状态。 服务端事务必须产生一个100（Trying)应答，除非它知道TU会在200ms内产生一个临时的或
最终的应答。这个临时应答是用来停止客户端请求重传逻辑的。

  请求必须被传递到事务使用者（TU）， TU可以传送任意个临时应答到服务端事务。只要服务端事务处于”proceeding"状态，这些应答就必须被传递到传输层进行传输。它们不会被可靠发送，也不会触发服务端事务的状态改变。
   如果在“Proceeding“状态时收到重传请求，服务端事务需要将从事务使用者收到的最近的应答发送出去。

  如果在“Proceeding“状态时，事务使用者传送一个2xx应答到服务端事务，则服务端事务必须传递这个应答到传输层进行发送。它不会被服务端事务重传，2xx应答的重传是由事务使用者处理。服务端事务这时必须切换到”Terminated"状态。
  当处于"Proceeding"状态期间，如果事务使用者传递一个状态码为300到699的应答到服务端事务时，该应答必须被传递到传输层进行发送。并且状态机必须进入"Completed"
状态。对于不可靠传输方式，以T1秒设置定时器G，而对于可靠传输方式，则不用启动定时器G。即使使用可靠的传输方式，应答也总是会重传的。

  当进入到”Completed"状态时，定时器必须以64T1秒启动（对于所有传输方式），定时器H决定服务端事务什么时间停止应答的重传。它的超时值和定时器B相等，在这期间，客户端事务可以继续重试发送一个请求。如果定时器G触发，应答会被再将传递到传输层进行重传。并且定时器重新以2T1和T2的最小值为超时时间继续启动。从那时起，应答被两次传递到传输层发送，并且定时器G以之前时间的2倍重置，如果值没超过T2的话。如果超过T2则以T2值作为超时值。这和处于“Trying"状态的非INVITE客户端事务对于重传的表现是相同的。此外，当处于”Completed"状态期间，如果收到重传的请求，服务端应该重传应答。

  当服务端事务处于“Completed"状态时， 如果收到了ACK， 服务端事务必须切换到”confirmed“状态，在这个状态中，定时器G是被忽略的，任何应答的重传将停止。

  如果定时器H在”Completed"状态触发，这表明没有收到ACK。在这种情况下，服务端事务必须切换到“Terminated"状态，并且必须通知事务使用者事务失败发生了。

四、关键说明

1. INVITE请示无应答重传
     当INVITE发出后，没有收到任何响应时，将以T1(500ms)为基础进行重传（0.5, 1, 2, 4, 8, 16），直到64T1停止，这时一般底层会向应用层返回408超时错误。*
   
2. 正常INVITE呼叫
   
3. 如果网络出现拥塞现象，1xx的应答不能及时收到时，也会看到INVITE请示消息的重传