RFC3261: SIP:17.1.1.2 形式描述

17.1.1.2 Formal Description
17.1.1.2 形式描述

   The state machine for the INVITE client transaction is shown in Figure 5.  The initial state, "calling", MUST be entered when the TU initiates a new client transaction with an INVITE request.  The client transaction MUST pass the request to the transport layer for transmission (see Section 18).  If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions).  For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts).

​INVITE客户端事务的状态机如图5所示。当TU使用INVITE请求启动新的客户端事务时，必须输入初始状态“调用”。客户端事务必须将请求传递到传输层进行传输（见第18节）。如果正在使用不可靠的传输，则客户端事务必须启动值为T1的计时器A。如果正在使用可靠的传输，则客户端事务不应启动计时器a（计时器a控制请求重新传输）。对于任何传输，客户端事务必须以64*T1秒的值启动计时器B（计时器B控制事务超时）。

   When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1.  The formal definition of retransmit within the context of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport layer once more.

当定时器A触发时，客户端事务必须通过将请求传递到传输层来重新发送请求，并且必须用2*T1的值重置定时器。在事务层的上下文中重新传输的正式定义是将之前发送到传输层的消息再次传递到传输层。

   When timer A fires 2*T1 seconds later, the request MUST be retransmitted again (assuming the client transaction is still in this state).  This process MUST continue so that the request is retransmitted with intervals that double after each transmission. These retransmissions SHOULD only be done while the client transaction is in the "calling" state.

当计时器A在2*T1秒后触发时，必须再次重新发送请求（假设客户端事务仍处于此状态）。此过程必须继续，以便在每次传输后以双倍的间隔重新传输请求。这些重新传输应该只在客户端事务处于“调用”状态时进行。

   The default value for T1 is 500 ms.  T1 is an estimate of the RTT between the client and server transactions.  Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection.  T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used.

T1的默认值是500毫秒。T1是客户端和服务端事务之间的RTT的估计值。元素可能（尽管不建议）在不允许一般互联网连接的封闭专用网络中使用较小的T1值。T1可以选择得更大，并且如果事先知道（例如在高延迟接入链路上）RTT更大，则建议这样做。无论T1的值是多少，都必须使用本节中描述的重传的指数退避。

   If the client transaction is still in the "Calling" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occurred.  The client transaction MUST NOT generate an ACK.  The value of 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport.

如果定时器B触发时客户端事务仍处于“调用”状态，则客户端事务应通知TU发生超时。客户端事务不得生成ACK。64*T1的值等于在传输不可靠的情况下发送七个请求所需的时间。

   If the client transaction receives a provisional response while in the "Calling" state, it transitions to the "Proceeding" state. In the "Proceeding" state, the client transaction SHOULD NOT retransmit the request any longer. Furthermore, the provisional response MUST be passed to the TU.  Any further provisional responses MUST be passed up to the TU while in the "Proceeding" state.

如果客户端事务在“调用”状态下接收到临时响应，则会转换到“正在进行”状态。在“正在进行”状态下，客户端事务不应再重新发送请求。此外，临时响应必须传递给TU。任何进一步的临时响应必须在“正在进行”状态下传递给TU。

   When in either the "Calling" or "Proceeding" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to "Completed".  The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission.  The ACK MUST be sent to the same address, port, and transport to which the original request was sent.  The client transaction SHOULD start timer D when it enters the "Completed" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used. This is equal to Timer H in the INVITE server transaction, whose default is 64*T1.  However, the client transaction does not know the value of T1 in use by the server transaction, so an absolute minimum of 32s is used instead of basing Timer D on T1.

​当处于“呼叫”或“正在进行”状态时，从300-699接收到状态代码的响应必须使客户端事务转换为“已完成”。客户端事务必须将接收到的响应传递到TU，并且客户端事务必须生成ACK请求，即使传输是可靠的（根据响应构建ACK的指南在第17.1.1.3节中给出），然后将ACK传递到传输层进行传输。ACK必须发送到原始请求发送到的相同地址、端口和传输。客户端事务应在进入“完成”状态时启动计时器D，对于不可靠的传输，计时器D的值至少为32秒，对于可靠的传输则为0秒。计时器D反映了当使用不可靠的传输时，服务端事务可以保持在“完成”状态的时间量。这等于INVITE服务器事务中的Timer H，其默认值为64*T1。然而，客户端事务不知道服务端事务正在使用的T1的值，因此使用绝对最小值32秒，而不是将计时器D基于T1。

   Any retransmissions of the final response that are received while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU.  A retransmission of the response is defined as any response which would match the same client transaction based on the rules of Section 17.1.3.

​在“完成”状态下接收的最终响应的任何重传都必须使ACK重新传递到传输层进行重传，但新接收的响应不得传递到TU。响应的重传定义为根据第17.1.3节的规则匹配相同客户端事务的任何响应。

                               |INVITE from TU
             Timer A fires     |INVITE sent
             Reset A,          V                      Timer B fires
             INVITE sent +-----------+                or Transport Err.
               +---------|           |---------------+inform TU
               |         |  Calling  |               |
               +-------->|           |-------------->|
                         +-----------+ 2xx           |
                            |  |       2xx to TU     |
                            |  |1xx                  |
    300-699 +---------------+  |1xx to TU            |
   ACK sent |                  |                     |
resp. to TU |  1xx             V                     |
            |  1xx to TU  -----------+               |
            |  +---------|           |               |
            |  |         |Proceeding |-------------->|
            |  +-------->|           | 2xx           |
            |            +-----------+ 2xx to TU     |
            |       300-699    |                     |
            |       ACK sent,  |                     |
            |       resp. to TU|                     |
            |                  |                     |      NOTE:
            |  300-699         V                     |
            |  ACK sent  +-----------+Transport Err. |  transitions
            |  +---------|           |Inform TU      |  labeled with
            |  |         | Completed |-------------->|  the event
            |  +-------->|           |               |  over the action
            |            +-----------+               |  to take
            |              ^   |                     |
            |              |   | Timer D fires       |
            +--------------+   | -                   |
                               |                     |
                               V                     |
                         +-----------+               |
                         |           |               |
                         | Terminated|<--------------+
                         |           |
                         +-----------+

                 Figure 5: INVITE client transaction
                图5:INVITE客户端事物

   If timer D fires while the client transaction is in the "Completed" state, the client transaction MUST move to the terminated state.

如果定时器D在客户端事务处于“完成”状态时触发，则客户端事务必须移动到终止状态。

   When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU. The handling of this response depends on whether the TU is a proxy core or a UAC core.  A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream.  The differing treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the transaction layer.

当处于“正在调用”或“正在进行”状态时，2xx响应的接收必须使客户端事务进入“已终止”状态，并且该响应必须向上传递给TU。该响应的处理取决于TU是代理核心还是UAC核心。UAC核心将处理此响应的ACK生成，而代理核心将始终向上游转发200（OK）。代理和UAC之间对200（OK）的不同处理是它的处理不在事务层中进行的原因。

   The client transaction MUST be destroyed the instant it enters the "Terminated" state.  This is actually necessary to guarantee correct operation.  The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different.  Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged).  No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core.  Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core.

​客户端事务必须在进入“已终止”状态时立即销毁。这实际上是保证正确操作所必需的。原因是对INVITE的2xx响应被区别对待；每一个都由代理转发，并且UAC中的ACK处理是不同的。因此，每个2xx都需要传递给一个代理核心（以便转发）和一个UAC核心（以便确认）。不进行事务层处理。每当传输接收到响应时，如果传输层没有发现匹配的客户端事务（使用第17.1.3节的规则），则将响应直接传递给核心。由于匹配的客户端事务被第一个2xx破坏，随后的2xx将找不到匹配项，因此将被传递到核心。