RFC3261: SIP:16.6 请求转发

16.6 Request Forwarding
16.6 请求转发

   As soon as the target set is non-empty, a proxy MAY begin forwarding the request.  A stateful proxy MAY process the set in any order.  It MAY process multiple targets serially, allowing each client transaction to complete before starting the next.  It MAY start client transactions with every target in parallel.  It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel.

一旦目标集不是空的，代理就可以开始转发请求。有状态代理可以按任何顺序处理集合。它可以串行处理多个目标，允许每个客户端事务在开始下一个事务之前完成。它可以并行启动每个目标的客户端事务。它也可以任意地将集合划分为组，串行处理组，并行处理每组中的目标。

   A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields (see Section 20.10).  Targets are processed from highest qvalue to lowest.  Targets with equal qvalues may be processed in parallel.

​一种常见的顺序机制是使用从Contact报头字段获得的目标的qvalue参数（见第20.10节）。目标从最高qvalue到最低进行处理。可以并行处理具有相等qvalue的目标。

   A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request.  For the purposes of this model, this mechanism is a "response context" created by the proxy layer before forwarding the first request.

有状态代理必须具有一种机制，以便在接收到响应时维护目标集，并将对每个转发请求的响应与原始请求相关联。出于该模型的目的，该机制是代理层在转发第一个请求之前创建的“响应上下文”。

   For each target, the proxy forwards the request following these steps:

对于每个目标，代理将按照以下步骤转发请求：

      1.  Make a copy of the received request

1.复制收到的请求

      2.  Update the Request-URI

2.更新请求URI

      3.  Update the Max-Forwards header field

3.更新最大转发报头字段

      4.  Optionally add a Record-route header field value

4.可选择添加记录路由报头字段值

      5.  Optionally add additional header fields

5.可选择添加其他报头字段

      6.  Postprocess routing information

6.后处理路由信息

      7.  Determine the next-hop address, port, and transport

7.确定下一跳地址、端口和传输

     8.  Add a Via header field value

8.添加Via报头字段值

      9.  Add a Content-Length header field if necessary

9.如有必要，添加“Content-Length”报头字段

      10. Forward the new request

10.转发新请求

      11. Set timer C

11.设置定时器C

   Each of these steps is detailed below:

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

      1. Copy request

1.复制请求

         The proxy starts with a copy of the received request.  The copy MUST initially contain all of the header fields from the received request.  Fields not detailed in the processing described below MUST NOT be removed.  The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1).  The proxy MUST NOT add to, modify, or remove the message body.

​代理从接收到的请求的副本开始。副本最初必须包含接收到的请求中的所有报头字段。不得删除以下处理中未详细说明的字段。副本应保持接收到的请求中报头字段的顺序。代理不得使用公共字段名称重新排序字段值（见第7.3.1节）。代理不得添加、修改或删除消息体。

         An actual implementation need not perform a copy; the primary requirement is that the processing for each next hop begin with the same request.

实际实现不需要执行复制；主要要求是每个下一跳的处理从相同的请求开始。

      2. Request-URI

2.请求URI

         The Request-URI in the copy's start line MUST be replaced with the URI for this target.  If the URI contains any parameters not allowed in a Request-URI, they MUST be removed.

副本起始行中的请求URI必须替换为此目标的URI。如果URI包含请求URI中不允许的任何参数，则必须删除这些参数。

         This is the essence of a proxy's role.  This is the mechanism through which a proxy routes a request toward its destination.

这是代理角色的本质。这是代理将请求路由到其目的地的机制。

         In some circumstances, the received Request-URI is placed into the target set without being modified.  For that target, the replacement above is effectively a no-op.

在某些情况下，接收到的请求URI会被放入目标集中，而不会被修改。对于这一目标，上述替代方案实际上是一个不可行的方案。

      3. Max-Forwards

3.最大转发

         If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1).

如果副本包含“最大转发”报头字段，则代理必须将其值递减一（1）。

         If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70.

如果副本不包含Max-Forwards报头字段，则代理必须添加一个字段值为70的字段。

         Some existing UAs will not provide a Max-Forwards header field in a request.

某些现有UA将不会在请求中提供“Max-Forwards”报头字段。

      4. Record-Route

4.记录路由

         If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present.

如果此代理希望保留在此请求创建的对话中未来请求的路径上（假设请求创建了一个对话），则它必须在任何现有记录路由报头字段值之前将记录路由报头字段值插入副本中，即使路由报头字段已经存在。

         Requests establishing a dialog may contain a preloaded Route header field.

建立对话的请求可能包含预加载的路由报头字段。

         If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog.  In normal endpoint operation as described in Section 12, these Record-Route header field values will not have any effect on the route sets used by the endpoints.

​如果此请求已经是对话的一部分，则如果代理希望保留在对话中未来请求的路径上，则应插入记录路由报头字段值。在第12节所述的正常端点操作中，这些记录路由报头字段值不会对端点使用的路由集产生任何影响。

         The proxy will remain on the path if it chooses to not insert a Record-Route header field value into requests that are already part of a dialog.  However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog.

如果代理选择不在已经是对话框一部分的请求中插入记录路由头字段值，则它将保留在路径上。但是，当失败的端点重新构建对话框时，它将从路径中删除。

         A proxy MAY insert a Record-Route header field value into any request.  If the request does not initiate a dialog, the endpoints will ignore the value.  See Section 12 for details on how endpoints use the Record-Route header field values to construct Route header fields.

​代理可以在任何请求中插入记录路由报头字段值。如果请求没有启动对话，端点将忽略该值。有关端点如何使用记录路由报头字段值来构造路由报头字段的详细信息，请参见第12节。

         Each proxy in the path of a request chooses whether to add a Record-Route header field value independently - the presence of a Record-Route header field in a request does not obligate this proxy to add a value.

请求路径中的每个代理都独立选择是否添加记录路由报头字段值-请求中存在记录路由报头字段并不要求该代理添加值。

         The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI.  This URI MUST contain an lr parameter (see Section 19.1.1).  This URI MAY be different for each destination the request is forwarded to.  The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport.

​记录路由报头字段值中的URI必须是SIP或SIPS URI。此URI必须包含lr参数（请参阅第19.1.1节）。此URI可能因请求转发到的每个目的地而异。除非代理知道（例如在专用网络中）后续请求路径中的下一个下游元素支持该传输，否则URI不应包含传输参数。

         The URI this proxy provides will be used by some other element to make a routing decision.  This proxy, in general, has no way of knowing the capabilities of that element, so it must restrict itself to the mandatory elements of a SIP implementation: SIP URIs and either the TCP or UDP transports.

此代理提供的URI将被其他一些元素用来做出路由决策。通常，这个代理无法知道该元素的功能，因此它必须将自己限制在SIP实现的强制性元素中：SIP URI以及TCP或UDP传输。

         The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element.  If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI.  Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field.  In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI.

​当[4]的服务器定位过程应用于记录路由报头字段中的URI时，该URI必须解析为插入该URI的元素（或合适的替身），以便后续请求到达相同的SIP元素。如果请求URI包含SIPS URI，或者最上面的路由报头字段值（在项目符号6的后处理之后）包含SIPS URL，则放入记录路由报头字段的URI必须是SIPS URI。此外，如果未通过TLS接收到请求，则代理必须插入记录路由报头字段。以类似的方式，通过TLS接收请求，但在请求URI或最上面的路由报头字段值中生成没有SIPS URI的请求的代理（在项目符号6的后期处理之后），必须插入一个不是SIPS-URI的记录路由报头字段。

         A proxy at a security perimeter must remain on the perimeter throughout the dialog.

在整个对话中，安全周界上的代理必须始终保持在周界上。

         If the URI placed in the Record-Route header field needs to be rewritten when it passes back through in a response, the URI MUST be distinct enough to locate at that time.  (The request may spiral through this proxy, resulting in more than one Record-Route header field value being added).  Item 8 of Section 16.7 recommends a mechanism to make the URI sufficiently distinct.

​如果放置在记录路由报头字段中的URI在响应中返回时需要重写，则该URI必须足够独特，以便在该时间定位。（请求可能会螺旋式地通过此代理，导致添加多个记录路由报头字段值）。第16.7节第8项建议建立一种机制，使URI充分不同。

         The proxy MAY include parameters in the Record-Route header field value.  These will be echoed in some responses to the request such as the 200 (OK) responses to INVITE.  Such parameters may be useful for keeping state in the message rather than the proxy.

代理可以在记录路由报头字段值中包括参数。这些将在对请求的一些响应中得到响应，例如对INVITE的200（OK）响应。这样的参数对于在消息中而不是在代理中保持状态可能是有用的。

         If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it SHOULD add a Record-Route header field value to every request with a method it does not understand since that method may have dialog semantics.

如果代理需要在任何类型的对话（例如跨越防火墙的对话框）的路径中，它应该使用它不理解的方法向每个请求添加一个记录路由报头字段值，因为该方法可能具有对话语义。

         The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog created by the transaction in which it occurs.  A dialog-stateful proxy, for example, MAY refuse to accept future requests with that value in the Request-URI after the dialog has terminated.  Non-dialog-stateful proxies, of course, have no concept of when the dialog has terminated, but they MAY encode enough information in the value to compare it against the dialog identifier of future requests and MAY reject requests not matching that information.Endpoints MUST NOT use a URI obtained from a Record-Route header field outside the dialog in which it was provided.  See Section 12 for more information on an endpoint's use of Record-Route header fields.
​
代理放入记录路由报头字段中的URI仅在发生该URI的事务创建的任何对话的生存期内有效。例如，对话有状态代理可能会在对话终止后拒绝接受请求URI中具有该值的未来请求。当然，非对话状态代理不知道对话何时终止，但它们可能在值中编码足够的信息，以将其与未来请求的对话标识符进行比较，并可能拒绝与该信息不匹配的请求。端点不得使用从提供URI的对话之外的记录路由报头字段中获得的URI。有关端点使用记录路由报头字段的更多信息，请参阅第12节。

         Record-routing may be required by certain services where the proxy needs to observe all messages in a dialog.  However, it slows down processing and impairs scalability and thus proxies should only record-route if required for a particular service.

某些服务可能需要记录路由，其中代理需要观察对话中的所有消息。然而，它会减慢处理速度并损害可扩展性，因此代理只应在特定服务需要时记录路由。

         The Record-Route process is designed to work for any SIP request that initiates a dialog.  INVITE is the only such request in this specification, but extensions to the protocol MAY define others.

记录路由过程设计用于启动对话的任何SIP请求。INVITE是本规范中唯一的此类请求，但协议的扩展可能会定义其他请求。

      5. Add Additional Header Fields

5.添加其他报头字段

         The proxy MAY add any other appropriate header fields to the copy at this point.

此时，代理可以将任何其他适当的报头字段添加到副本中。

      6. Postprocess routing information

6.后处理路由信息

         A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination.  A proxy MUST ensure that all such proxies are loose routers.  Generally, this can only be known with certainty if the proxies are within the same administrative domain.  This set of proxies is represented by a set of URIs (each of which contains the lr parameter).  This set MUST be pushed into the Route header field of the copy ahead of any existing values, if present.  If the Route header field is absent, it MUST be added, containing that list of URIs.

代理可能有一个本地策略，要求请求在发送到目的地之前访问一组特定的代理。代理必须确保所有此类代理都是松散的路由器。通常，只有当代理在同一管理域内时，才能确定这一点。这组代理由一组URI表示（每个URI都包含lr参数）。如果存在任何现有值，则必须将此集合推送到副本的Route报头字段中。如果没有Route报头字段，则必须添加它，其中包含URI列表。

         If the proxy has a local policy that mandates that the request visit one specific proxy, an alternative to pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, and instead just send the request to the address, port, and transport for that specific proxy.  If the request has a Route header field, this alternative MUST NOT be used unless it is known that next hop proxy is a loose router.  Otherwise, this approach MAY be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality and consistency of operation. Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy.

如果代理有一个本地策略，要求请求访问一个特定的代理，那么将Route值推入Route报头字段的另一种选择是绕过下面项目10的转发逻辑，而只是将请求发送到该特定代理的地址、端口和传输。如果请求具有路由报头字段，则除非知道下一个跃点代理是松散的路由器，否则不得使用此替代方案。否则，可以使用这种方法，但由于其鲁棒性、灵活性、通用性和操作的一致性，上述路由插入机制是优选的。此外，如果请求URI包含SIPS URI，则必须使用TLS与该代理通信。

         If the copy contains a Route header field, the proxy MUST inspect the URI in its first value.  If that URI does not contain an lr parameter, the proxy MUST modify the copy as follows:

如果副本包含Route报头字段，则代理必须检查URI的第一个值。如果该URI不包含lr参数，则代理必须按如下方式修改副本：

         -  The proxy MUST place the Request-URI into the Route header field as the last value.

-代理必须将请求URI作为最后一个值放入Route报头字段中。

         -  The proxy MUST then place the first Route header field value into the Request-URI and remove that value from the Route header field.

-然后，代理必须将第一个Route报头字段值放入请求URI中，并从Route报头字段中删除该值。

         Appending the Request-URI to the Route header field is part of a mechanism used to pass the information in that Request-URI through strict-routing elements.  "Popping" the first Route header field value into the Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in the Request-URI and the next location to visit in the first Route header field value).

将请求URI附加到路由头字段是用于通过严格的路由元素传递该请求URI中的信息的机制的一部分。将第一个路由头字段值“弹出”到请求URI中，按照严格路由元素期望接收消息的方式格式化消息（在请求URI中有自己的URI，在第一个路由首字段值中有下一个要访问的位置）。

      7. Determine Next-Hop Address, Port, and Transport

7.确定下一个跃点地址、端口和传输

         The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI.  Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED; instead a Route header field should be used for that purpose as described above.

代理可能有一个本地策略，用于将请求发送到特定的IP地址、端口和传输，与Route和请求URI的值无关。如果代理不能确定IP地址、端口和传输是否对应于松散路由器的服务器，则不得使用此类策略。然而，不建议使用这种通过特定下一跳发送请求的机制；相反，如上所述，应为此目的使用Route报头字段。

         In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request.  If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request.  Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI.  The procedures will produce an ordered set of (address, port, transport) tuples. Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy MUST follow the procedures of [4] as if the input URI were a SIPS URI.

​在没有这种覆盖机制的情况下，代理应用下面[4]中列出的程序来确定将请求发送到哪里。如果代理已重新格式化请求以发送到上面步骤6中所述的严格路由元素，则代理必须将这些处理应用于请求的请求URI。否则，代理必须将过程应用于路由报头字段中的第一个值（如果存在），否则应用于请求URI。这些过程将生成一组有序的（地址、端口、传输）元组。独立于哪一个URI被用作[4]过程的输入，如果请求URI指定SIPS资源，则代理必须遵循[4]的过程，就像输入URI是SIPS URI一样。

         As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds.

​如[4]所述，代理必须尝试将消息传递到该集合中的第一个元组，并按顺序继续执行该集合，直到传递尝试成功。

         For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send the request using a new client transaction as detailed in steps 8 through 10.

对于尝试的每个元组，代理必须根据元组对消息进行适当的格式化，并使用新的客户端事务发送请求，如步骤8到10中所述。

         Since each attempt uses a new client transaction, it represents a new branch.  Thus, the branch parameter provided with the Via header field inserted in step 8 MUST be different for each attempt.

由于每次尝试都使用一个新的客户端事务，因此它代表一个新分支。因此，在步骤8中插入的Via报头字段提供的分支参数对于每次尝试都必须不同。

         If the client transaction reports failure to send the request or a timeout from its state machine, the proxy continues to the next address in that ordered set.  If the ordered set is exhausted, the request cannot be forwarded to this element in  the target set.  The proxy does not need to place anything in the response context, but otherwise acts as if this element of the target set returned a 408 (Request Timeout) final response.

如果客户端事务报告无法从其状态机发送请求或超时，则代理将继续到该有序集中的下一个地址。如果有序集已用完，则无法将请求转发到目标集中的此元素。代理不需要在响应上下文中放置任何内容，但在其他方面，其作用就好像目标集的这个元素返回了408（请求超时）最终响应一样。

      8. Add a Via header field value

8.添加Via报头字段值

         The proxy MUST insert a Via header field value into the copy before the existing Via header field values.  The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy.
​
代理必须在现有Via报头字段值之前将Via报头域值插入副本。该值的构造遵循第8.1.1.7节的相同指南。这意味着代理将计算其自己的分支参数，该参数对于该分支是全局唯一的，并包含必要的魔术cookie。请注意，这意味着通过代理的螺旋式或循环请求的不同实例的分支参数将不同。

         Proxies choosing to detect loops have an additional constraint in the value they use for construction of the branch parameter. A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation.  The first part MUST satisfy the constraints of Section 8.1.1.7 as described above.  The second is used to perform loop detection and distinguish loops from spirals.

​选择检测循环的代理在用于构造分支参数的值中具有附加约束。选择检测循环的代理应该创建一个可由实现分为两部分的分支参数。第一部分必须满足上述第8.1.1.7节的约束条件。第二个用于执行回路检测并将回路与螺旋线区分开来。

         Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed.  The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require and Proxy-Authorization header fields).  This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3).  A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present.  The  algorithm used to compute the hash is implementation-dependent, but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a reasonable choice.  (Base64 is not permissible for a token.)

​循环检测是通过验证当请求返回到代理时，那些对请求处理有影响的字段没有改变来执行的。放置在分支参数这一部分的值应该反映所有这些字段（包括任何Route、Proxy-Require和Proxy-Authorization报头字段）。这是为了确保如果请求被路由回代理，并且其中一个字段发生了更改，则将其视为螺旋而非循环（见第16.3节）。创建该值的常见方法是计算To标签、From标签、Call-ID报头字段、接收到的请求的请求URI（在翻译之前）、最顶部的Via报头的加密哈希，以及来自CSeq报头字段的序列号。用于计算哈希的算法取决于实现，但以十六进制表示的MD5（RFC 1321[35]）是一个合理的选择。（令牌不允许使用Base64。）

         If a proxy wishes to detect loops, the "branch" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing.  This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server.

如果代理希望检测循环，它提供的“分支”参数必须取决于影响请求处理的所有信息，包括传入的请求URI和影响请求的准入或路由的任何报头字段。这对于区分循环请求和路由参数在返回到此服务器之前已更改的请求是必要的。
         The request method MUST NOT be included in the calculation of the branch parameter.  In particular, CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding request they cancel or acknowledge.  The branch parameter is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2).

​请求方法不得包含在分支参数的计算中。特别是，CANCEL和ACK请求（对于非2xx响应）必须与它们取消或确认的相应请求具有相同的分支值。分支参数用于在处理这些请求的服务器上关联这些请求（参见第17.2.3节和第9.2节）。

      9. Add a Content-Length header field if necessary

9.如有必要，添加“Content-Length”报头字段

         If the request will be sent to the next hop using a stream-based transport and the copy contains no Content-Length header field, the proxy MUST insert one with the correct value for the body of the request (see Section 20.14).

​如果请求将使用基于流的传输发送到下一个跃点，并且副本不包含Content-Length报头字段，则代理必须插入一个具有请求正文的正确值的字段（见第20.14节）。

      10. Forward Request

10.转发请求

         A stateful proxy MUST create a new client transaction for this request as described in Section 17.1 and instructs the transaction to send the request using the address, port and transport determined in step 7.

​有状态代理必须为该请求创建一个新的客户端事务，如第17.1节所述，并指示事务使用步骤7中确定的地址、端口和传输发送请求。

      11. Set timer C

11.设置定时器C

         In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C.  Timer C MUST be set for each client transaction when an INVITE request is proxied.  The timer MUST be larger than 3 minutes.  Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires.

​为了处理INVITE请求从未生成最终响应的情况，TU使用一个称为计时器C的计时器。当INVITE要求被代理时，必须为每个客户端事务设置计时器C。计时器必须大于3分钟。第16.7节第2项讨论了如何使用临时响应更新此计时器，第16.8节讨论了它启动时的处理。