RFC3261: SIP:13.2.2.4 2xx响应

13.2.2.4 2xx Responses
13.2.2.4 2xx响应

   Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy.  Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier.

由于分叉代理，对于单个INVITE请求，多个2xx响应可能到达UAC。每个响应都通过To报头字段中的标记参数进行区分，每个响应都表示一个不同的对话，具有不同的对话标识符。

   If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2.

​如果2xx响应中的对话标识符与现有对话的对话标识符匹配，则必须将对话转换为“已确认”状态，并且必须使用第12.2.1.2节的程序根据2xx响应重新计算对话的路由集。否则，必须使用第12.1.2节的程序构建处于“已确认”状态的新对话。

      Note that the only piece of state that is recomputed is the route set.  Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed.  The route set only is recomputed for backwards compatibility.  RFC2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx.  However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example.

​请注意，唯一重新计算的状态是路由集。对话中发送的其他状态片段（如最高序列号（远程和本地））不会重新计算。仅为向后兼容性重新计算路由集。RFC2543没有强制镜像1xx中的记录路由报头字段，只有2xx。但是，我们无法更新对话的整个状态，因为对话中期请求可能是在早期对话中发送的，例如修改序列号。

   The UAC core MUST generate an ACK request for each 2xx received from the transaction layer.  The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication.  The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK.  The ACK MUST contain the same credentials as the INVITE.  If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body.  If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately.

​UAC核心必须为从事务层接收的每个2xx生成一个ACK请求。ACK的报头字段的构造方式与在对话中发送的任何请求的构造方式相同（见第12节），但CSeq和与身份验证相关的报头字段除外。CSeq报头字段的序列号必须与正在确认的INVITE相同，但CSeq方法必须是ACK。ACK必须包含与INVITE相同的凭据。如果2xx包含offer（基于上述规则），则ACK必须在其消息体中包含answer。如果2xx响应中的提议不可接受，UAC核心必须在ACK中生成有效answer，然后立即发送BYE。

   Once the ACK has been constructed, the procedures of [4] are used to determine the destination address, port and transport.  However, the request is passed to the transport layer directly for transmission, rather than a client transaction.  This is because the UAC core handles retransmissions of the ACK, not the transaction layer.  The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives.

​一旦构造了ACK，就使用[4]的过程来确定目的地址、端口和传输。但是，请求被直接传递到传输层进行传输，而不是客户端事务。这是因为UAC核心处理ACK的重传，而不是事务层。每次触发ACK的2xx最终响应的重传到达时，都必须将ACK传递到客户端传输。

   The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response.  At this point all the early dialogs that have not transitioned to established dialogs are terminated.  Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive.

UAC核心认为INVITE事务在接收到第一个2xx响应后64*T1秒完成。此时，所有尚未转换为已建立对话的早期对话都将终止。一旦INVITE事务被认为是由UAC核心完成的，预计不会有更多新的2xx响应到达。

   If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15.

​如果在确认对INVITE的任何2xx响应后，UAC不想继续进行该对话，则UAC必须通过发送第15节所述的BYE请求来终止该对话。