RFC3261: SIP:17.2.3 将请求与服务端事务匹配

17.2.3 Matching Requests to Server Transactions
17.2.3 将请求与服务端事务匹配

   When a request is received from the network by the server, it has to be matched to an existing transaction.  This is accomplished in the following manner.

当服务端从网络接收到请求时，必须将其与现有事务相匹配。这是通过以下方式实现的。

   The branch parameter in the topmost Via header field of the request is examined.  If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification.  Therefore, the branch parameter will be unique across all transactions sent by that client.  The request matches a transaction if:

检查请求的最上面的Via报头字段中的分支参数。如果它存在并且以魔法cookie“z9hG4bK”开头，则该请求是由符合此规范的客户端事务生成的。因此，分支参数在该客户端发送的所有事务中都是唯一的。在以下情况下，请求与事务匹配：

      1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and

1.请求中的分支参数等于创建事务的请求的顶部Via报头字段中的参数，以及

      2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and

2.请求顶部Via中的sended-by值等于创建事务的请求中的值，并且

      3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE.

3.请求的方法与创建事务的方法匹配，除了ACK，其中创建事务的请求的方法是INVITE。

   This matching rule applies to both INVITE and non-INVITE transactions alike.

此匹配规则同样适用于INVITE和非INVITE事务。

      The sent-by value is used as part of the matching process because there could be accidental or malicious duplication of branch parameters from different clients.

“sent-by”值被用作匹配过程的一部分，因为可能存在来自不同客户端的分支参数的意外或恶意重复。

   If the branch parameter in the top Via header field is not present, or does not contain the magic cookie, the following procedures are used.  These exist to handle backwards compatibility with RFC 2543 compliant implementations.

​如果顶部Via报头字段中的分支参数不存在，或者不包含魔术cookie，则使用以下过程。它们的存在是为了处理与符合RFC 2543的实现的向后兼容性。

   The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field match those of the INVITE request which created the transaction.  In this case, the INVITE is a retransmission of the original one that created the transaction.  The ACK request matches a transaction if the Request-URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction, and the To tag of the ACK matches the To tag of the response sent by the server transaction.  Matching is done based on the matching rules defined for each of those header fields. Inclusion of the tag in the To header field in the ACK matching process helps disambiguate ACK for 2xx from ACK for other responses at a proxy, which may have forwarded both responses (This can occur in unusual conditions.  Specifically, when a proxy forked a request, and then crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses upstream).  An ACK request that matches an INVITE transaction matched by a previous ACK is considered a retransmission of that previous ACK.

如果request URI、To标记、From标记、Call-ID、CSeq和top Via报头字段与创建事务的INVITE请求的字段相匹配，则INVITE要求与事务相匹配。在这种情况下，INVITE是创建事务的原始INVITE的重传。如果request URI、From标签、Call-ID、CSeq编号（而非方法）和顶部Via报头字段与创建事务的INVITE请求的字段匹配，并且ACK的To标签与服务端事务发送的响应的To标签匹配，则ACK请求与事务匹配。匹配是基于为每个报头字段定义的匹配规则来完成的。在ACK匹配过程中，在To报头字段中包含标签有助于消除2xx的ACK与代理上其他响应的ACK的歧义，代理可能已经转发了两个响应（这可能发生在不寻常的情况下。特别是，当代理分叉一个请求，然后崩溃时，响应可能会传递到另一个代理，后者可能最终向上游转发多个响应）。与先前ACK匹配的INVITE事务相匹配的ACK请求被认为是该先前ACK的重传。

                                  |Request received
                                  |pass to TU
                                  V
                            +-----------+
                            |           |
                            | Trying    |-------------+
                            |           |             |
                            +-----------+             |200-699 from TU
                                  |                   |send response
                                  |1xx from TU        |
                                  |send response      |
                                  |                   |
               Request            V      1xx from TU  |
               send response+-----------+send response|
                   +--------|           |--------+    |
                   |        | Proceeding|        |    |
                   +------->|           |<-------+    |
            +<--------------|           |             |
            |Trnsprt Err    +-----------+             |
            |Inform TU            |                   |
            |                     |                   |
            |                     |200-699 from TU    |
            |                     |send response      |
            |  Request            V                   |
            |  send response+-----------+             |
            |      +--------|           |             |
            |      |        | Completed |<------------+
            |      +------->|           |
            +<--------------|           |
            |Trnsprt Err    +-----------+
            |Inform TU            |
            |                     |Timer J fires
            |                     |-
            |                     |
            |                     V
            |               +-----------+
            |               |           |
            +-------------->| Terminated|
                            |           |
                            +-----------+

                Figure 8: non-INVITE server transaction
                图8：非INVITE服务端事务

   For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq (including the method), and top Via header field match those of the request that created the transaction.  Matching is done based on the matching rules defined for each of those header fields.  When a non-INVITE request matches an existing transaction, it is a retransmission of the request that created that transaction.

对于所有其他请求方法，如果request-URI、To标记、From标记、Call-ID、CSeq（包括方法）和top Via报头字段与创建事务的请求的字段匹配，则请求与事务匹配。匹配是基于为每个报头字段定义的匹配规则来完成的。当非INVITE请求与现有事务匹配时，它是创建该事务的请求的重传。

   Because the matching rules include the Request-URI, the server cannot match a response to a transaction.  When the TU passes a response to the server transaction, it must pass it to the specific server transaction for which the response is targeted.

因为匹配规则包括请求URI，所以服务端无法将响应匹配到事务。当TU将响应传递给服务端事务时，它必须将其传递给响应所针对的特定服务端事务。