RFC3261: SIP:8.1.3.4处理3xx响应

8.1.3.4 Processing 3xx Responses
8.1.3.4处理3xx响应

   Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request.  This process is similar to that of a proxy recursing on a 3xx class response as detailed in Sections 16.5 and 16.6.  A client starts with an initial target set containing exactly one URI, the Request-URI of the original request.  If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set.  Subject to the restrictions in this specification, a client can choose which Contact URIs it places into the target set.  As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once.  If the original request had a SIPS URI in the Request-URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI.

收到重定向响应（例如301响应状态代码）后，客户端应使用Contact报头字段中的URI根据重定向请求制定一个或多个新请求。该过程类似于第16.5节和第16.6节中详述的3xx类响应上的代理递归。客户端以包含一个URI（原始请求的请求URI）的初始目标集开始。如果客户端希望基于对该请求的3xx类响应制定新请求，则将URI放入目标集进行尝试。根据本规范中的限制，客户可以选择将其放入目标集中的联系人。与代理递归一样，处理3xx类响应的客户端不得多次向目标集添加任何给定URI。如果原始请求在请求URI中具有SIPS URI，则客户端可以选择递归到非SIPS URI，但应通知用户重定向到不安全URI。

      Any new request may receive 3xx responses themselves containing the original URI as a contact.  Two locations can be configured to redirect to each other.  Placing any given URI in the target set only once prevents infinite redirection loops.

任何新的请求本身都可以接收3xx个响应，其中包含作为联系人的原始URI。可以将两个位置配置为重定向到彼此。在目标集中只放置一次任何给定的URI可以防止无限的重定向循环。

   As the target set grows, the client MAY generate new requests to the URIs in any order.  A common mechanism is to order the set by the "q" parameter value from the Contact header field value.  Requests to the URIs MAY be generated serially or in parallel.  One approach is to process groups of decreasing q-values serially and process the URIs in each q-value group in parallel.  Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value.

随着目标集的增长，客户端可能会以任何顺序生成对URI的新请求。一种常见机制是根据Contact报头字段值中的“q”参数值对集合进行排序。对URI的请求可以串行生成，也可以并行生成。一种方法是串行处理递减q值的组，并并行处理每个q值组中的URI。另一种是仅以q值递减的顺序执行串行处理，在相等q值的触点之间任意选择。

   If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted.  If the list is exhausted, then the request has failed.

如果联系列表中的某个地址导致失败，如下一段所定义，则元素会移动到列表中的下一个地址，直到列表用完为止。如果列表已用完，则表示请求失败。

   Failures SHOULD be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user.  Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not be considered failures.

应通过故障响应代码（大于399的代码）检测故障；对于网络错误，客户端事务将向事务用户报告任何传输层故障。请注意，一些响应代码（详见8.1.3.5）指示可以重试请求；被重新尝试的请求不应被视为失败。

   When a failure for a particular contact address is received, the client SHOULD try the next contact address.  This will involve creating a new client transaction to deliver a new request.

当收到特定联系人地址的故障时，客户端应该尝试下一个联系人地址。这将涉及创建一个新的客户端事务来传递一个新请求。

   In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the "method-param" and "header" URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the "header" parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section 19.1.5.

​为了在3xx响应中基于联系人地址创建请求，UAC必须将整个URI从目标集复制到请求URI中，但“method-param”和“header”URI参数除外（有关这些参数的定义，请参阅第19.1.1节）。它使用“header”参数为新请求创建报头字段值，根据第19.1.5节中的指导方针覆盖与重定向请求相关的报头字段值。

   Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request.  As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request.  If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address.  For example, if a contact address is returned with the following value:

请注意，在某些情况下，已在联系人地址中通信的报头字段可能会附加到原始重定向请求中的现有请求报头字段。作为一般规则，如果报头字段可以接受逗号分隔的值列表，则新的报头字段值可以附加到原始重定向请求中的任何现有值。如果报头字段不接受多个值，则原始重定向请求中的值可能会被联系人地址中传递的报头字段值覆盖。例如，如果返回的联系人地址具有以下值：

      sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

   Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values.

然后，原始重定向请求中的任何Subject报头字段都将被覆盖，但HTTP URL仅附加到任何现有的Call Info报头字段值。

   It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example.

建议UAC重复使用原始重定向请求中使用的相同To、From和Call ID，但UAC也可以选择更新新请求的Call ID报头字段值。

   Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7.

​最后，一旦构建了新请求，就会使用新的客户端事务进行发送，因此必须在顶部的Via字段中具有新的分支机构ID，如第8.1.1.7节所述。

   In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request.

在所有其他方面，收到重定向响应后发送的请求应该重用原始请求的报头字段和消息体。

   In some instances, Contact header field values may be cached at UAC temporarily or permanently depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 21.3.3.

​在某些情况下，根据接收到的状态代码和过期间隔的存在，Contact头字段值可以临时或永久地缓存在UAC中；参见第21.3.2节和第21.3.3节。
​