SIP timer

使用UDP传输(unreliable way)SIP时需要进行重传。

一、UAC端

1. Invite transaction

---------------------------------------------------

T1,是对RTT的一个估计，默认500ms。可以根据实际情况进行配置，比如内网，建议减小，外网，建议增大。

Timer A:

发送Request后，启动，超时值是T1。如果超时，则重传，启动Timer A，超时值是2*T1。根据Timer B的值，一共可以传6次。

Timer B: 64*T1

Transaction的超时值

Timer D:

Client Transaction发送Ack后，如果使用UDP，则至少32s，使用TCP，则至少0s。

Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used.

这个和Server Transaction的Timer H等价，其默认值是64*T1，但Client Transaction不知道Server的T1，所以使用了绝对值32s

StateMachine：

Calling -> Proceeding -> Completed -> Terminated

2. Non-Invite transaction

--------------------------------------------------------

UDP传输才需要重传

发送request后，启动timer E，超时值为T1，每次重传后再启动时为此前一次2倍，直到T2。

如果收到了一个provisional response，那么重传继续，但超时值变为T2；

发送reuqest后，启动Timer F，超时值为64*T1

每次重传后，启动的timer E，超时值为此前一次超时值的2倍与T2之间的最小值；

T2的默认值是4s，因此timer E的超时值可能依次是：500ms，1s，2s，4s，4s，... 直到Timer F超时

一旦UAC进入Completed状态，应该启动Timer K，超时值为T4（TCP的情况为0s）。

T4的默认值是5s，代表了网络清空UAC和UAS之间事务消息的时间。

Trying -> Proceeding -> Completed -> Terminated

二、UAS端

1. Invite transaction

收到Invite请求后，建立server transaction，进入Proceeding 状态

server transaction必须产生100 trying，除非他知道TU会在200ms内产生provisional 或者 final response

2xx 的重传由TU负责，不由server transaction 负责

在收到300 - 699 response后，server transaction进入Completed状态。

如果是unreliable 传输，则启动Timer G，超时值T1

进入Completed状态，启动Timer H，超时值64*T1

如果Timer G超时，那么重传并再启动，超时值min（2*old，T2），

在Completed状态收到Ack，则进入Confirmed状态，在这个状态下，Timer G被忽略。

进入Confirmed状态，是为了消化后续可能的Ack，进入这个状态，启动Timer I，超时值T4（UDP），0s（TCP）

在Completed状态，Timer H超时，则说明没有收到Ack，那么server transaction进入Terminated状态，并且，通知TU该failure

2. Non-Invite transaction

初始Trying状态，收到provisional response后，进入Proceeding状态

在Proceeding状态收到final response，则进入Completed状态，启动Timer J，超时值64*T1(UDP), 0s(TCP)。 Timer J超时，进入Terminated状态