RFC3261: SIP:17.2.1 INVITE服务端事务

17.2.1 INVITE Server Transaction
17.2.1 INVITE服务端事务

   The state diagram for the INVITE server transaction is shown in Figure 7.

INVITE服务端事务的状态图如图7所示。

   When a server transaction is constructed for a request, it enters the "Proceeding" state.  The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it MAY generate a 100 (Trying) response.  This provisional response is needed to quench request retransmissions rapidly in order to avoid network congestion.  The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from MAY to SHOULD NOT. The request MUST be passed to the TU.

​当为请求构建服务器事务时，它将进入“正在进行”状态。服务端事务必须生成100（尝试）响应，除非它知道TU将在200毫秒内生成临时或最终响应，在这种情况下，它可能会生成100（尝试）响应。为了避免网络拥塞，需要该临时响应来快速终止请求重传。100（尝试）响应是根据第8.2.6节中的程序构建的，除了在响应的To报头字段中插入标记（当请求中不存在标记时）从“可能”降级为“不应该”。请求必须传递给TU。

   The TU passes any number of provisional responses to the server transaction.  So long as the server transaction is in the "Proceeding" state, each of these MUST be passed to the transport layer for transmission.  They are not sent reliably by the transaction layer (they are not retransmitted by it) and do not cause a change in the state of the server transaction.  If a request retransmission is received while in the "Proceeding" state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission.  A request is a retransmission if it matches the same server transaction based on the rules of Section 17.2.3.

​TU向服务端事务传递任意数量的临时响应。只要服务端事务处于“正在进行”状态，每个事务都必须传递到传输层进行传输。它们不是由事务层可靠地发送的（它们不是由它重新传输的），并且不会导致服务器事务的状态发生变化。如果在“进行”状态下接收到请求重传，则必须将从TU接收到的最新临时响应传递到传输层进行重传。根据第17.2.3节的规则，如果请求与同一服务器事务匹配，则该请求为重传。

   If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission.  It is not retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU.  The server transaction MUST then transition to the "Terminated" state.

如果在“进行”状态下，TU将2xx响应传递给服务端事务，则服务端事务必须将此响应传递给传输层进行传输。它不由服务端事务重新传输；2xx响应的重新传输由TU处理。然后服务端事务必须转换到“已终止”状态。

   While in the "Proceeding" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine MUST enter the "Completed" state.  For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports.

在“进行”状态下，如果TU将状态代码为300到699的响应传递给服务端事务，则该响应必须传递给传输层进行传输，并且状态机必须进入“完成”状态。对于不可靠的传输，定时器G设置为在T1秒内启动，而对于可靠的传输则不设置为启动。

      This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports.

​这与RFC 2543有所不同，响应总是被重新传输，即使是通过可靠的传输。

   When the "Completed" state is entered, timer H MUST be set to fire in 64*T1 seconds for all transports.  Timer H determines when the server transaction abandons retransmitting the response.  Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request.  If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds.  From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2.  This is identical to the retransmit behavior for requests in the "Trying" state of the non-INVITE client transaction.  Furthermore, while in the "Completed" state, if a request retransmission is received, the server SHOULD pass the response to the transport for retransmission.

当进入“完成”状态时，所有传输的定时器H必须设置为在64*T1秒内启动。定时器H确定服务端事务何时放弃重传响应。它的值被选择为等于Timer B，即客户端事务将继续重试发送请求的时间量。如果定时器G触发，则响应再次传递到传输层用于重传，并且定时器G被设置为在MIN（2*T1，T2）秒内触发。从那时起，当定时器G触发时，响应再次传递到传输装置用于传输，并且定时器G被重置为一个加倍的值，除非该值超过T2，在这种情况下，它被重置为T2的值。这与非INVITE客户端事务处于“正在尝试”状态的请求的重新传输行为相同。此外，在“完成”状态下，如果接收到请求重传，服务器应将响应传递给传输以进行重传。

   If an ACK is received while the server transaction is in the "Completed" state, the server transaction MUST transition to the "Confirmed" state.  As Timer G is ignored in this state, any retransmissions of the response will cease.

如果在服务端事务处于“已完成”状态时收到ACK，则服务端事务必须转换到“已确认”状态。由于定时器G在这种状态下被忽略，任何响应的重新传输都将停止。

   If timer H fires while in the "Completed" state, it implies that the ACK was never received.  In this case, the server transaction MUST transition to the "Terminated" state, and MUST indicate to the TU that a transaction failure has occurred.

如果定时器H在“完成”状态下触发，则表示从未接收到ACK。在这种情况下，服务端事务必须转换到“已终止”状态，并且必须向TU指示发生了事务失败。

                               |INVITE
                               |pass INV to TU
            INVITE             V send 100 if TU won't in 200ms
            send response+-----------+
                +--------|           |--------+101-199 from TU
                |        | Proceeding|        |send response
                +------->|           |<-------+
                         |           |          Transport Err.
                         |           |          Inform TU
                         |           |--------------->+
                         +-----------+                |
            300-699 from TU |     |2xx from TU        |
            send response   |     |send response      |
                            |     +------------------>+
                            |                         |
            INVITE          V          Timer G fires  |
            send response+-----------+ send response  |
                +--------|           |--------+       |
                |        | Completed |        |       |
                +------->|           |<-------+       |
                         +-----------+                |
                            |     |                   |
                        ACK |     |                   |
                        -   |     +------------------>+
                            |        Timer H fires    |
                            V        or Transport Err.|
                         +-----------+  Inform TU     |
                         |           |                |
                         | Confirmed |                |
                         |           |                |
                         +-----------+                |
                               |                      |
                               |Timer I fires         |
                               |-                     |
                               |                      |
                               V                      |
                         +-----------+                |
                         |           |                |
                         | Terminated|<---------------+
                         |           |
                         +-----------+

              Figure 7: INVITE server transaction
                图7:INVITE服务端事务

   The purpose of the "Confirmed" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response.  When this state is entered, timer I is set to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports.  Once timer I fires, the server MUST transition to the "Terminated" state.

“已确认”状态的目的是吸收由最终响应的重新传输触发的任何额外的ACK消息。当进入该状态时，计时器I被设置为在T4秒内触发不可靠传输，而在0秒内触发可靠传输。一旦计时器I启动，服务器必须转换到“已终止”状态。

   Once the transaction is in the "Terminated" state, it MUST be destroyed immediately.  As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE.

一旦事务处于“已终止”状态，就必须立即销毁它。与客户端事务一样，这是确保对INVITE的2xx响应的可靠性所必需的。