RFC3261: SIP:16.7响应处理

16.7 Response Processing
16.7响应处理

   When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response.  If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below).  If a match is found, the response is handed to the client transaction.

​当一个元素接收到响应时，它首先尝试定位与该响应匹配的客户端事务（第17.1.3节）。如果找不到任何响应，则元素必须将响应（即使它是一个信息性响应）作为无状态代理（如下所述）进行处理。如果找到匹配项，则将响应交给客户端事务。

      Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness.  In particular, it ensures that "late" 2xx responses to INVITE requests are forwarded properly.

转发未发现客户端事务（或者更一般地，未发现已发送相关请求的任何知识）的响应提高了鲁棒性。特别是，它确保正确转发对INVITE请求的“延迟”2xx响应。

   As client transactions pass responses to the proxy layer, the following processing MUST take place:

当客户端事务将响应传递到代理层时，必须进行以下处理：

      1.  Find the appropriate response context

1.找到合适的响应上下文

      2.  Update timer C for provisional responses

2.针对临时响应更新定时器C

      3.  Remove the topmost Via

3.移除最上面的Via

      4.  Add the response to the response context

4.将响应添加到响应上下文中

      5.  Check to see if this response should be forwarded immediately

5.检查此响应是否应立即转发

      6.  When necessary, choose the best final response from the response context

6.必要时，从响应上下文中选择最佳的最终响应

   If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the "best" response from those it has seen so far.

如果在与响应上下文相关联的每个客户端事务终止后都没有转发最终响应，则代理必须从迄今为止看到的响应中选择并转发“最佳”响应。

   The following processing MUST be performed on each response that is forwarded.  It is likely that more than one response to each request will be forwarded: at least each provisional and one final response.

必须对转发的每个响应执行以下处理。可能会对每项请求作出不止一项答复：至少每项临时答复和一项最后答复。

      7.  Aggregate authorization header field values if necessary

7.必要时聚合授权报头字段值

      8.  Optionally rewrite Record-Route header field values

8.可选择重写记录路由报头字段值

      9.  Forward the response

9.转发响应

      10. Generate any necessary CANCEL requests

10.生成任何必要的CANCEL请求

   Each of the above steps are detailed below:

上述每个步骤的详细信息如下：

      1.  Find Context

1.查找上下文

         The proxy locates the "response context" it created before forwarding the original request using the key described in Section 16.6.  The remaining processing steps take place in this context.
​
代理使用第16.6节中描述的密钥定位其在转发原始请求之前创建的“响应上下文”。剩下的处理步骤就是在这种情况下进行的。

      2.  Update timer C for provisional responses

2.针对临时响应更新定时器C

         For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction.  The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes.

对于INVITE事务，如果该响应是具有状态代码101到199（包括101到199）的临时响应（即，除了100以外的任何响应），则代理必须为该客户端事务重置定时器C。计时器可以重置为不同的值，但该值必须大于3分钟。

      3.  Via

         The proxy removes the topmost Via header field value from the response.

代理从响应中删除最上面的Via报头字段值。

         If no Via header field values remain in the response, the response was meant for this element and MUST NOT be forwarded. The remainder of the processing described in this section is not performed on this message, the UAC processing rules described in Section 8.1.3 are followed instead (transport layer processing has already occurred).

​如果响应中没有Via报头字段值，则该响应是针对该元素的，不得转发。本节所述处理的其余部分不在此消息上执行，而是遵循第8.1.3节所述的UAC处理规则（传输层处理已经发生）。

         This will happen, for instance, when the element generates CANCEL requests as described in Section 10.

​例如，当元素生成第10节所述的CANCEL请求时，就会发生这种情况。

      4.  Add response to context

4.添加对上下文的响应

         Final responses received are stored in the response context until a final response is generated on the server transaction associated with this context.  The response may be a candidate for the best final response to be returned on that server transaction.  Information from this response may be needed in forming the best response, even if this response is not chosen.

接收到的最终响应存储在响应上下文中，直到在与该上下文相关联的服务器事务上生成最终响应为止。该响应可以是在该服务器事务上返回的最佳最终响应的候选者。在形成最佳响应时，可能需要来自该响应的信息，即使没有选择该响应。

         If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it MUST remove them from the response before adding the response to the response context.  However, a proxy SHOULD NOT recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI.  If the proxy recurses on all of the contacts in a 3xx response, the proxy SHOULD NOT add the resulting contactless response to the response context.

如果代理选择通过将3xx响应中的任何联系人添加到目标集来重复出现在这些联系人上，则必须在将响应添加到响应上下文之前将其从响应中删除。但是，如果原始请求的请求URI是SIPS URI，则代理不应递归到非SIPS URI。如果代理在3xx响应中的所有联系人上重复出现，则代理不应将产生的非接触式响应添加到响应上下文中。

         Removing the contact before adding the response to the response context prevents the next element upstream from retrying a location this proxy has already attempted.

在将响应添加到响应上下文之前删除联系人会阻止上游的下一个元素重试此代理已经尝试的位置。

         3xx responses may contain a mixture of SIP, SIPS, and non-SIP URIs.  A proxy may choose to recurse on the SIP and SIPS URIs and place the remainder into the response context to be returned, potentially in the final response.

3xx响应可以包含SIP、SIPS和非SIP URI的混合。代理可以选择在SIP和SIPS URI上递归，并将剩余部分放入要返回的响应上下文中，可能是在最终响应中。

         If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy SHOULD add a new URI to the target set.  This URI SHOULD be a SIP URI version of the non-SIP URI that was just tried.  In the case of the tel URL, this is accomplished by placing the telephone-subscriber part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs.

​如果代理接收到对请求URI方案不是SIP，但原始接收到的请求中的方案是SIP或SIPS的请求的416（不支持的URI方案）响应（即，代理在代理请求时将方案从SIP或SIP更改为其他方案），则代理应向目标集添加新的URI。此URI应该是刚才尝试的非SIP URI的SIP URI版本。在tel URL的情况下，这是通过将tel URL的电话订户部分放置到SIP URI的用户部分中，并将主机部分设置为发送先前请求的域来实现的。有关从tel URL形成SIP URI的更多详细信息，请参阅第19.1.6节。

         As with a 3xx response, if a proxy "recurses" on the 416 by trying a SIP or SIPS URI instead, the 416 response SHOULD NOT be added to the response context.

与3xx响应一样，如果代理通过尝试SIP或SIPS URI在416上“递归”，则不应将416响应添加到响应上下文中。

      5.  Check response for forwarding

5.检查转发的响应

         Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately:

在服务器事务上发送最终响应之前，必须立即转发以下响应：

         -  Any provisional response other than 100 (Trying)

-100以外的任何临时响应（正在尝试）

         -  Any 2xx response

-任何2xx响应

         If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context.

​如果收到6xx响应，则不会立即转发，但有状态代理应取消所有客户端挂起的事务，如第10节所述，并且在这种情况下不得创建任何新分支。

         This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response immediately.  For an INVITE transaction, this approach had the problem that a 2xx response could arrive on another branch, in which case the proxy would have to forward the 2xx.  The result was that the UAC could receive a 6xx response followed by a 2xx response, which should never be allowed to happen.  Under the new rules, upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from all outstanding client transactions, and then at that point the 6xx is forwarded upstream.

​这与RFC 2543有所不同，后者要求代理立即转发6xx响应。对于INVITE事务，这种方法存在2xx响应可能到达另一个分支的问题，在这种情况下，代理必须转发2xx。结果是，UAC可以接收到6xx响应，然后是2xx响应，这是不应该允许的。根据新规则，在收到6xx后，代理将发出CANCEL请求，这通常会导致来自所有未完成的客户端交易的487响应，然后在这一点上将6xx转发到上游。

         After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately:

在服务器事务上发送最终响应后，必须立即转发以下响应：

         -  Any 2xx response to an INVITE request

-对INVITE请求的任何2xx响应

         A stateful proxy MUST NOT immediately forward any other responses.  In particular, a stateful proxy MUST NOT forward any 100 (Trying) response.  Those responses that are candidates for forwarding later as the "best" response have been gathered as described in step "Add Response to Context".

有状态代理不得立即转发任何其他响应。特别是，有状态代理不得转发任何100（Trying）响应。如步骤“将响应添加到上下文”中所述，已经收集了那些作为“最佳”响应稍后转发的候选响应。

         Any response chosen for immediate forwarding MUST be processed as described in steps "Aggregate Authorization Header Field Values" through "Record-Route".

任何选择立即转发的响应都必须按照步骤“聚合授权报头字段值”到“记录路由”中的说明进行处理。

         This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request.

此步骤与下一步相结合，确保有状态代理将向非INVITE请求转发恰好一个最终响应，并向INVITE要求转发恰好一次非2xx响应或一次或多次2xx响应。

      6.  Choosing the best response

6.选择最佳响应

         A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated.

如果上述规则没有立即转发最终响应，并且此响应上下文中的所有客户端事务都已终止，则有状态代理必须向响应上下文的服务器事务发送最终响应。

         The stateful proxy MUST choose the "best" final response among those received and stored in the response context.

有状态代理必须在接收并存储在响应上下文中的响应中选择“最佳”的最终响应。

         If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction.

如果上下文中没有最终响应，则代理必须向服务器事务发送408（请求超时）响应。

         Otherwise, the proxy MUST forward a response from the responses stored in the response context.  It MUST choose from the 6xx class responses if any exist in the context.  If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context.  The proxy MAY select any response within that chosen class.  The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen.

否则，代理必须转发来自存储在响应上下文中的响应。它必须从6xx类响应中进行选择（如果上下文中存在）。如果不存在6xx类响应，则代理应该从存储在响应上下文中的最低响应类中进行选择。代理可以选择所选类中的任何响应。如果选择了4xx类，则代理应该优先选择提供影响此请求的重新提交的信息的响应，例如401、407、415、420和484。

         A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request-URI in the request which generated the 503.  If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream.

接收503（服务不可用）响应的代理不应将其向上游转发，除非它能够确定它可能代理的任何后续请求也将生成503。换句话说，转发503意味着代理知道它不能为任何请求提供服务，而不仅仅是为生成503的请求中的请求URI提供服务。如果接收到的唯一响应是503，则代理应该生成500响应并将其转发到上游。

         The forwarded response MUST be processed as described in steps "Aggregate Authorization Header Field Values" through "Record-Route".

转发的响应必须按照步骤“聚合授权报头字段值”到“记录路由”中的说明进行处理。

         For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response.

例如，如果代理将请求转发到4个位置，并且接收到503、407、501和404响应，则它可以选择转发407（需要代理验证）响应。

         1xx and 2xx responses may be involved in the establishment of dialogs.  When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request.  A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one.  A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response.

1xx和2xx响应可以被包括在对话的建立中。当请求不包含To标记时，UAC会使用响应中的To标记来区分对创建对话请求的多个响应。如果请求不包含标签，则代理不得将标签插入1xx或2xx响应的To报头字段。代理不得修改1xx或2xx响应的To报头字段中的标记。

         Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not contain one, it cannot issue non-100 provisional responses on its own.  However, it can branch the request to a UAS sharing the same element as the proxy.  This UAS can return its own provisional responses, entering into an early dialog with the initiator of the request.  The UAS does not have to be a discreet process from the proxy.  It could be a virtual UAS implemented in the same code space as the proxy.

由于代理可能不会将标签插入到1xx响应的To报头字段中，以响应不包含标签的请求，因此它不能自行发出非100临时响应。但是，它可以将请求分支到与代理共享相同元素的UAS。该UAS可以返回自己的临时响应，与请求的发起人进行早期对话。UAS系统不必是一个来自代理的谨慎过程。它可以是在与代理相同的代码空间中实现的虚拟UAS。

         3-6xx responses are delivered hop-by-hop.  When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements.  An element SHOULD preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag.

3-6xx响应逐跳传递。当发出3-6xx响应时，元素有效地充当UAS，通常基于从下游元素接收到的响应发出自己的响应。当简单地向不包含To标记的请求转发3-6xx响应时，元素应该保留To标记。

         A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag.

代理不得在对包含To标记的请求的任何转发响应中修改To标记。

         While it makes no difference to the upstream elements if the proxy replaced the To tag in a forwarded 3-6xx response, preserving the original tag may assist with debugging.

虽然如果代理在转发的3-6xx响应中替换了to标签，则对上游元素没有影响，但保留原始标签可能有助于调试。

         When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier.  This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses.

当代理聚合来自多个响应的信息时，从其中选择To标记是任意的，生成新的To标记可能会使调试更容易。例如，当组合401（未经授权）和407（需要代理身份验证）质询，或组合未加密和未经身份验证的3xx响应中的Contact值时，就会发生这种情况。

      7.  Aggregate Authorization Header Field Values

7.聚合授权报头字段值

         If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy MUST collect any WWW-Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding.  The resulting 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW-Authenticate AND Proxy-Authenticate header field values.

如果所选响应是401（未授权）或407（需要代理身份验证），则代理必须从迄今为止在此响应上下文中接收到的所有其他401（未经授权）和407（需要代理人身份验证）响应中收集任何WWW-Authenticate和Proxy Authenticate报头字段值，并在转发之前将它们添加到此响应中而不进行修改。所得到的401（未授权）或407（需要代理验证）响应可能具有多个WWW-Authenticate和Proxy Authenticate报头字段值。

         This is necessary because any or all of the destinations the request was forwarded to may have requested credentials.  The client needs to receive all of those challenges and supply credentials for each of them when it retries the request. Motivation for this behavior is provided in Section 26.

​这是必要的，因为请求转发到的任何或所有目的地都可能请求了凭据。客户端需要接收所有这些质询，并在重试请求时为每个质询提供凭据。第26节提供了这种行为的动机。

      8.  Record-Route

8.记录路由

         If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response.  This allows the proxy to provide different URIs for itself to the next upstream and downstream elements.  A proxy may choose to use this mechanism for any reason.  For instance, it is useful for multi-homed hosts.

如果所选响应包含此代理最初提供的记录路由报头字段值，则代理可以选择在转发响应之前重写该值。这允许代理为自己向下一个上游和下游元素提供不同的URI。代理可以出于任何原因选择使用此机制。例如，它对多宿主主机非常有用。

         If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI.  If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI.

如果代理通过TLS接收到请求，并通过非TLS连接发送，则代理必须将记录路由报头字段中的URI重写为SIPS URI。如果代理通过非TLS连接接收到请求，并通过TLS发送，则代理必须将“记录路由”报头字段中的URI重写为SIP URI。

         The new URI provided by the proxy MUST satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications:

​代理提供的新URI必须满足对请求中记录路由报头字段中的URI的相同约束（见第16.6节的步骤4），并进行以下修改：

         The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport.

URI不应包含传输参数，除非代理知道后续请求路径中的下一个上游（而不是下游）元素支持该传输。

         When a proxy does decide to modify the Record-Route header field in the response, one of the operations it performs is locating the Record-Route value that it had inserted.  If the request spiraled, and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value in the response (which must be the proper iteration in the reverse direction) is tricky.  The rules above recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently distinct URIs into the Record-Route header field so that the right one may be selected for rewriting.  A RECOMMENDED mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI.

当代理决定修改响应中的“记录路由”报头字段时，它执行的操作之一是定位它插入的“记录路由”值。如果请求螺旋上升，并且代理在螺旋的每个迭代中插入一个Record-Route值，那么在响应中定位正确的值（必须是反向的正确迭代）是很棘手的。上面的规则建议希望重写记录路由报头字段值的代理将足够不同的URI插入到记录路由报头字段中，以便可以选择正确的URI进行重写。实现这一点的推荐机制是代理将代理实例的唯一标识符附加到URI的用户部分。

         When the response arrives, the proxy modifies the first Record-Route whose identifier matches the proxy instance.  The modification results in a URI without this piece of data appended to the user portion of the URI.  Upon the next iteration, the same algorithm (find the topmost Record-Route header field value with the parameter) will correctly extract the next Record-Route header field value inserted by that proxy.

当响应到达时，代理修改其标识符与代理实例匹配的第一个记录路由。修改的结果是URI中没有将这段数据附加到URI的用户部分。在下一次迭代时，相同的算法（使用参数查找最上面的记录路由报头字段值）将正确提取该代理插入的下一个记录路由报头字段值。

         Not every response to a request to which a proxy adds a Record-Route header field value will contain a Record-Route header field.  If the response does contain a Record-Route header field, it will contain the value the proxy added.

并不是每个对请求的响应（代理向其添加记录路由报头字段值）都包含记录路由报头字段。如果响应确实包含Record-Route报头字段，则它将包含代理添加的值。

      9.  Forward response

9.转发响应

         After performing the processing described in steps "Aggregate Authorization Header Field Values" through "Record-Route", the proxy MAY perform any feature specific manipulations on the selected response.  The proxy MUST NOT add to, modify, or remove the message body.  Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3.  In particular, the proxy MUST NOT remove any "received" parameter it may have added to the next Via header field value while processing the request associated with this response.  The proxy MUST pass the response to the server transaction associated with the response context.  This will result in the response being sent to the location now indicated in the topmost Via header field value.  If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport.  The server transaction might indicate failure to send the response or signal a timeout in its state machine.  These errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial action from the proxy.

​在通过“记录路由”执行步骤“聚合授权报头字段值”中描述的处理后，代理可以对所选响应执行任何特定于功能的操作。代理不得添加、修改或删除消息体。除非另有规定，否则代理不得删除第16.7节第3项中讨论的Via报头字段值以外的任何报头字段值。特别是，代理在处理与此响应相关的请求时，不得删除其可能添加到下一个Via报头字段值中的任何“已接收”参数。代理必须将响应传递给与响应上下文关联的服务器事务。这将导致响应被发送到最上面的Via报头字段值中现在指示的位置。如果服务器事务不再可用于处理传输，则元素必须通过将响应发送到服务器传输来无状态地转发响应。服务器事务可能指示发送响应失败，或者在其状态机中发出超时信号。这些错误将被记录以用于适当的诊断目的，但协议不需要代理采取补救措施。

         The proxy MUST maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response.

代理必须维护响应上下文，直到其所有相关事务都已终止，即使在转发最终响应之后也是如此。

      10. Generate CANCELs

10.生成CANCEL

         If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context.  A proxy SHOULD also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response.  A pending client transaction is one that has received a provisional response, but no final response (it is in the proceeding state) and has not had an associated CANCEL generated for it.  Generating CANCEL requests is described in Section 9.1.

​如果转发的响应是最终响应，则代理必须为与该响应上下文相关联的所有未决客户端事务生成CANCEL请求。当代理收到6xx响应时，它还应该为与该响应上下文相关的所有未决客户端事务生成CANCEL请求。挂起的客户端事务是指已经收到临时响应，但没有最终响应（处于正在进行状态），并且没有为其生成相关的CANCEL的事务。生成CANCEL请求如第9.1节所述。

         The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE.  200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed.  Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests.

在转发最终响应时取消挂起的客户端事务的要求并不保证端点不会接收到对INVITE的200（OK）响应。在可以发送和处理CANCEL请求之前，可以在多于一个分支上生成200（OK）响应。此外，可以合理地预期，未来的扩展可能会推翻这一要求，以发出CANCEL请求。