Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 7339 V. Hilt
Category: Standards Track Bell Labs, Alcatel-Lucent
ISSN: 2070-1721 H. Schulzrinne
Columbia University
September 2014
Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 7339 V. Hilt
Category: Standards Track Bell Labs, Alcatel-Lucent
ISSN: 2070-1721 H. Schulzrinne
Columbia University
September 2014
Session Initiation Protocol (SIP) Overload Control
会话启动协议（SIP）过载控制
Abstract
摘要
Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.
当SIP服务器没有足够的资源来处理它们接收到的所有SIP消息时，会话初始化协议（SIP）网络中会发生过载。即使SIP协议通过其503（服务不可用）响应代码提供有限的过载控制机制，SIP服务器仍然容易过载。本文档定义了涉及过载控制的SIP服务器的行为，并为SIP指定了基于丢失的过载方案。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7339.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7339.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview of Operations ..........................................6
4. Via Header Parameters for Overload Control ......................6
4.1. The "oc" Parameter .........................................6
4.2. The "oc-algo" Parameter ....................................7
4.3. The "oc-validity" Parameter ................................8
4.4. The "oc-seq" Parameter .....................................8
5. General Behavior ................................................9
5.1. Determining Support for Overload Control ..................10
5.2. Creating and Updating the Overload Control Parameters .....10
5.3. Determining the "oc" Parameter Value ......................12
5.4. Processing the Overload Control Parameters ................12
5.5. Using the Overload Control Parameter Values ...............13
5.6. Forwarding the Overload Control Parameters ................14
5.7. Terminating Overload Control ..............................14
5.8. Stabilizing Overload Algorithm Selection ..................15
5.9. Self-Limiting .............................................15
5.10. Responding to an Overload Indication .....................16
5.10.1. Message Prioritization at the Hop before
the Overloaded Server .............................16
5.10.2. Rejecting Requests at an Overloaded Server ........17
5.11. 100 Trying Provisional Response and Overload
Control Parameters .......................................17
6. Example ........................................................18
7. The Loss-Based Overload Control Scheme .........................19
7.1. Special Parameter Values for Loss-Based Overload Control ..19
7.2. Default Algorithm for Loss-Based Overload Control .........20
8. Relationship with Other IETF SIP Load Control Efforts ..........23
9. Syntax .........................................................24
10. Design Considerations .........................................24
10.1. SIP Mechanism ............................................24
10.1.1. SIP Response Header ...............................24
10.1.2. SIP Event Package .................................25
10.2. Backwards Compatibility ..................................26
11. Security Considerations .......................................27
12. IANA Considerations ...........................................29
13. References ....................................................29
13.1. Normative References .....................................29
13.2. Informative References ...................................30
Appendix A. Acknowledgements ......................................31
Appendix B. RFC 5390 Requirements .................................31
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview of Operations ..........................................6
4. Via Header Parameters for Overload Control ......................6
4.1. The "oc" Parameter .........................................6
4.2. The "oc-algo" Parameter ....................................7
4.3. The "oc-validity" Parameter ................................8
4.4. The "oc-seq" Parameter .....................................8
5. General Behavior ................................................9
5.1. Determining Support for Overload Control ..................10
5.2. Creating and Updating the Overload Control Parameters .....10
5.3. Determining the "oc" Parameter Value ......................12
5.4. Processing the Overload Control Parameters ................12
5.5. Using the Overload Control Parameter Values ...............13
5.6. Forwarding the Overload Control Parameters ................14
5.7. Terminating Overload Control ..............................14
5.8. Stabilizing Overload Algorithm Selection ..................15
5.9. Self-Limiting .............................................15
5.10. Responding to an Overload Indication .....................16
5.10.1. Message Prioritization at the Hop before
the Overloaded Server .............................16
5.10.2. Rejecting Requests at an Overloaded Server ........17
5.11. 100 Trying Provisional Response and Overload
Control Parameters .......................................17
6. Example ........................................................18
7. The Loss-Based Overload Control Scheme .........................19
7.1. Special Parameter Values for Loss-Based Overload Control ..19
7.2. Default Algorithm for Loss-Based Overload Control .........20
8. Relationship with Other IETF SIP Load Control Efforts ..........23
9. Syntax .........................................................24
10. Design Considerations .........................................24
10.1. SIP Mechanism ............................................24
10.1.1. SIP Response Header ...............................24
10.1.2. SIP Event Package .................................25
10.2. Backwards Compatibility ..................................26
11. Security Considerations .......................................27
12. IANA Considerations ...........................................29
13. References ....................................................29
13.1. Normative References .....................................29
13.2. Informative References ...................................30
Appendix A. Acknowledgements ......................................31
Appendix B. RFC 5390 Requirements .................................31
As with any network element, a Session Initiation Protocol (SIP) [RFC3261] server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation where the retransmissions of dropped SIP messages may overwhelm the capacity of the network. This is often called "congestion collapse".
与任何网络元件一样，当会话启动协议（SIP）[RFC3261]服务器接收的SIP消息数量超过其可以处理的消息数量时，服务器可能会过载。过载会给SIP服务器网络带来严重问题。在过载期间，SIP服务器网络的吞吐量会显著降低。事实上，过载可能导致丢弃的SIP消息的重新传输可能会超过网络的容量。这通常被称为“拥塞崩溃”。
Overload is said to occur if a SIP server does not have sufficient resources to process all incoming SIP messages. These resources may include CPU processing capacity, memory, input/output, or disk resources.
如果SIP服务器没有足够的资源来处理所有传入的SIP消息，就会发生过载。这些资源可能包括CPU处理能力、内存、输入/输出或磁盘资源。
For overload control, this document only addresses failure cases where SIP servers are unable to process all SIP requests due to resource constraints. There are other cases where a SIP server can successfully process incoming requests but has to reject them due to failure conditions unrelated to the SIP server being overloaded. For example, a Public Switched Telephone Network (PSTN) gateway that runs out of trunks but still has plenty of capacity to process SIP messages should reject incoming INVITEs using a 488 (Not Acceptable Here) response [RFC4412]. Similarly, a SIP registrar that has lost connectivity to its registration database but is still capable of processing SIP requests should reject REGISTER requests with a 500 (Server Error) response [RFC3261]. Overload control does not apply to these cases, and SIP provides appropriate response codes for them.
对于过载控制，本文档仅解决SIP服务器由于资源限制而无法处理所有SIP请求的故障情况。在其他情况下，SIP服务器可以成功地处理传入的请求，但由于与SIP服务器过载无关的故障条件，必须拒绝这些请求。例如，一个公共交换电话网（PSTN）网关，如果没有中继线，但仍有足够的容量来处理SIP消息，则应使用488（此处不可接受）响应来拒绝传入的邀请[RFC4412]。类似地，与注册数据库失去连接但仍能处理SIP请求的SIP注册器应以500（服务器错误）响应拒绝注册请求[RFC3261]。过载控制不适用于这些情况，SIP为它们提供适当的响应代码。
The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code. However, this mechanism cannot prevent overload of a SIP server, and it cannot prevent congestion collapse. In fact, the use of the 503 (Service Unavailable) response code may cause traffic to oscillate and shift between SIP servers, thereby worsening an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code, and the requirements for a SIP overload control mechanism can be found in [RFC5390].
SIP协议通过其503（服务不可用）响应代码为过载控制提供了有限的机制。然而，这种机制不能防止SIP服务器过载，也不能防止拥塞崩溃。事实上，503（服务不可用）响应代码的使用可能导致业务在SIP服务器之间振荡和转移，从而恶化过载状况。有关SIP过载问题、503（服务不可用）响应代码问题以及SIP过载控制机制要求的详细讨论，请参见[RFC5390]。
This document defines the protocol for communicating overload information between SIP servers and clients so that clients can reduce the volume of traffic sent to overloaded servers, avoiding congestion collapse and increasing useful throughput. Section 4 describes the Via header parameters used for this communication. The
本文档定义了用于在SIP服务器和客户端之间通信过载信息的协议，以便客户端可以减少发送到过载服务器的通信量，避免拥塞崩溃并增加有用的吞吐量。第4节描述了用于此通信的Via头参数。这个
general behavior of SIP servers and clients involved in overload control is described in Section 5. In addition, Section 7 specifies a loss-based overload control scheme.
第5节描述了涉及过载控制的SIP服务器和客户端的一般行为。此外，第7节规定了基于损耗的过载控制方案。
This document specifies the loss-based overload control scheme (Section 7), which is mandatory to implement for this specification. In addition, this document allows other overload control schemes to be supported as well. To do so effectively, the expectations and primitive protocol parameters common to all classes of overload control schemes are specified in this document.
本文件规定了基于损耗的过载控制方案（第7节），该方案是本规范强制实施的。此外，本文件还允许支持其他过载控制方案。为了有效地实现这一点，本文件规定了所有类别过载控制方案通用的期望值和原始协议参数。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In this document, the terms "SIP client" and "SIP server" are used in their generic forms. Thus, a "SIP client" could refer to the client transaction state machine in a SIP proxy, or it could refer to a user agent client (UAC). Similarly, a "SIP server" could be a user agent server (UAS) or the server transaction state machine in a proxy. Various permutations of this are also possible, for instance, SIP clients and servers could also be part of back-to-back user agents (B2BUAs).
在本文档中，术语“SIP客户端”和“SIP服务器”以其通用形式使用。因此，“SIP客户端”可以指SIP代理中的客户端事务状态机，也可以指用户代理客户端（UAC）。类似地，“SIP服务器”可以是用户代理服务器（UAS）或代理中的服务器事务状态机。这方面的各种排列也是可能的，例如，SIP客户端和服务器也可以是背靠背用户代理（B2BUA）的一部分。
However, irrespective of the context these terms are used in (i.e., proxy, B2BUA, UAS, UAC), "SIP client" applies to any SIP entity that provides overload control to traffic destined downstream. Similarly, "SIP server" applies to any SIP entity that is experiencing overload and would like its upstream neighbor to throttle incoming traffic.
然而，无论在何种上下文中使用这些术语（即，代理、B2BUA、UAS、UAC），“SIP客户端”适用于向目的地为下游的流量提供过载控制的任何SIP实体。类似地，“SIP服务器”适用于任何正在经历过载并希望其上游邻居限制传入流量的SIP实体。
Unless otherwise specified, all SIP entities described in this document are assumed to support this specification.
除非另有规定，否则本文件中描述的所有SIP实体均假定支持本规范。
The normative statements in this specification as they apply to SIP clients and SIP servers assume that both the SIP clients and SIP servers support this specification. If, for instance, only a SIP client supports this specification and not the SIP server, then the normative statements in this specification pertinent to the behavior of a SIP server do not apply to the server that does not support this specification.
本规范中适用于SIP客户端和SIP服务器的规范性声明假定SIP客户端和SIP服务器都支持本规范。例如，如果只有SIP客户机支持本规范而不支持SIP服务器，则本规范中与SIP服务器行为相关的规范性陈述不适用于不支持本规范的服务器。
This section provides an overview of how the overload control mechanism operates by introducing the overload control parameters. Section 4 provides more details and normative behavior on the parameters listed below.
本节通过介绍过载控制参数，概述过载控制机制的工作方式。第4节提供了关于下列参数的更多细节和规范行为。
Because overload control is performed hop-by-hop, the Via header parameter is attractive since it allows two adjacent SIP entities to indicate support for, and exchange information associated with, overload control [RFC6357]. Additional advantages of this choice are discussed in Section 10.1.1. An alternative mechanism using SIP event packages was also considered, and the characteristics of that choice are further outlined in Section 10.1.2.
因为过载控制是逐跳执行的，所以Via头参数很有吸引力，因为它允许两个相邻的SIP实体指示对过载控制的支持，并交换与过载控制相关的信息[RFC6357]。第10.1.1节讨论了该选择的其他优点。还考虑了使用SIP事件包的替代机制，第10.1.2节进一步概述了该选择的特征。
This document defines four new parameters for the SIP Via header for overload control. These parameters provide a mechanism for conveying overload control information between adjacent SIP entities. The "oc" parameter is used by a SIP server to indicate a reduction in the number of requests arriving at the server. The "oc-algo" parameter contains a token or a list of tokens corresponding to the class of overload control algorithms supported by the client. The server chooses one algorithm from this list. The "oc-validity" parameter establishes a time limit for which overload control is in effect, and the "oc-seq" parameter aids in sequencing the responses at the client. These parameters are discussed in detail in the next section.
本文档为SIP Via头定义了四个新参数，用于过载控制。这些参数提供了在相邻SIP实体之间传输过载控制信息的机制。SIP服务器使用“oc”参数表示到达服务器的请求数量减少。“oc algo”参数包含一个令牌或令牌列表，对应于客户端支持的过载控制算法类。服务器从该列表中选择一个算法。“oc validity”参数确定了过载控制生效的时间限制，“oc seq”参数有助于在客户端对响应进行排序。下一节将详细讨论这些参数。
The four Via header parameters are introduced below. Further context about how to interpret these under various conditions is provided in Section 5.
下面介绍四个过孔收割台参数。第5节提供了关于如何在各种条件下解释这些内容的更多上下文。
This parameter is inserted by the SIP client and updated by the SIP server.
此参数由SIP客户端插入，并由SIP服务器更新。
A SIP client MUST add an "oc" parameter to the topmost Via header it inserts into every SIP request. This provides an indication to downstream neighbors that the client supports overload control. There MUST NOT be a value associated with the parameter (the value will be added by the server).
SIP客户端必须通过插入到每个SIP请求中的头将“oc”参数添加到最顶端。这向下游邻居提供了客户端支持过载控制的指示。不得有与参数关联的值（该值将由服务器添加）。
The downstream server MUST add a value to the "oc" parameter in the response going upstream to a client that included the "oc" parameter in the request. Inclusion of a value to the parameter represents two
下游服务器必须在向上游发送到请求中包含“oc”参数的客户端的响应中向“oc”参数添加一个值。在参数中包含一个值表示两个
things. First, upon the first contact (see Section 5.1), addition of a value by the server to this parameter indicates (to the client) that the downstream server supports overload control as defined in this document. Second, if overload control is active, then it indicates the level of control to be applied.
东西。首先，在第一次联系时（参见第5.1节），服务器向该参数添加一个值表示（向客户端）下游服务器支持本文档中定义的过载控制。第二，如果过载控制处于活动状态，则表示要应用的控制级别。
When a SIP client receives a response with the value in the "oc" parameter filled in, it MUST reduce, as indicated by the "oc" and "oc-algo" parameters, the number of requests going downstream to the SIP server from which it received the response (see Section 5.10 for pertinent discussion on traffic reduction).
当SIP客户端接收到填写了“oc”参数值的响应时，它必须减少（如“oc”和“oc algo”参数所示）从其接收响应的SIP服务器下游的请求数（有关流量减少的相关讨论，请参阅第5.10节）。
This parameter is inserted by the SIP client and updated by the SIP server.
此参数由SIP客户端插入，并由SIP服务器更新。
A SIP client MUST add an "oc-algo" parameter to the topmost Via header it inserts into every SIP request, with a default value of "loss".
SIP客户端必须向插入到每个SIP请求中的最顶层Via头添加一个“oc algo”参数，默认值为“loss”。
This parameter contains names of one or more classes of overload control algorithms. A SIP client MUST support the loss-based overload control scheme and MUST insert at least the token "loss" as one of the "oc-algo" parameter values. In addition, the SIP client MAY insert other tokens, separated by a comma, in the "oc-algo" parameter if it supports other overload control schemes such as a rate-based scheme [RATE-CONTROL]. Each element in the comma-separated list corresponds to the class of overload control algorithms supported by the SIP client. When more than one class of overload control algorithms is present in the "oc-algo" parameter, the client may indicate algorithm preference by ordering the list in a decreasing order of preference. However, the client cannot assume that the server will pick the most preferred algorithm.
此参数包含一个或多个过载控制算法类的名称。SIP客户端必须支持基于丢失的过载控制方案，并且必须至少插入令牌“loss”作为“oc algo”参数值之一。此外，如果SIP客户端支持其他过载控制方案，例如基于速率的方案[速率控制]，则它可以在“oc algo”参数中插入其他令牌（用逗号分隔）。逗号分隔列表中的每个元素对应于SIP客户端支持的过载控制算法类。当“oc algo”参数中存在一类以上的过载控制算法时，客户机可通过按偏好的降序排列列表来指示算法偏好。但是，客户端不能假定服务器将选择最首选的算法。
When a downstream SIP server receives a request with multiple overload control algorithms specified in the "oc-algo" parameter (optionally sorted by decreasing order of preference), it chooses one algorithm from the list and MUST return the single selected algorithm to the client.
当下游SIP服务器接收到具有在“oc algo”参数中指定的多个过载控制算法的请求时（可选地按偏好的降序排序），它从列表中选择一个算法，并且必须将单个选择的算法返回给客户端。
Once the SIP server has chosen a mutually agreeable class of overload control algorithms and communicated it to the client, the selection stays in effect until the algorithm is changed by the server. Furthermore, the client MUST continue to include all the supported algorithms in subsequent requests; the server MUST respond with the agreed-to algorithm until the algorithm is changed by the server.
一旦SIP服务器选择了一类相互同意的过载控制算法并将其传送给客户端，该选择将保持有效，直到服务器更改算法为止。此外，客户端必须继续在后续请求中包含所有支持的算法；在服务器更改算法之前，服务器必须使用同意的算法进行响应。
The selection SHOULD stay the same for a non-trivial duration of time to allow the overload control algorithm to stabilize its behavior (see Section 5.8).
选择应在非平凡的时间内保持不变，以允许过载控制算法稳定其行为（见第5.8节）。
The "oc-algo" parameter does not define the exact algorithm to be used for traffic reduction; rather, the intent is to use any algorithm from a specific class of algorithms that affect traffic reduction similarly. For example, the reference algorithm in Section 7.2 can be used as a loss-based algorithm, or it can be substituted by any other loss-based algorithm that results in equivalent traffic reduction.
“oc algo”参数未定义用于交通量减少的精确算法；相反，目的是使用特定类别算法中的任何算法，这些算法同样会影响流量减少。例如，第7.2节中的参考算法可以用作基于损耗的算法，也可以被任何其他导致等效流量减少的基于损耗的算法替代。
This parameter MAY be inserted by the SIP server in a response; it MUST NOT be inserted by the SIP client in a request.
该参数可由SIP服务器在响应中插入；SIP客户端不能将其插入请求中。
This parameter contains a value that indicates an interval of time (measured in milliseconds) that the load reduction specified in the value of the "oc" parameter should be in effect. The default value of the "oc-validity" parameter is 500 (milliseconds). If the client receives a response with the "oc" and "oc-algo" parameters suitably filled in, but no "oc-validity" parameter, the SIP client should behave as if it had received "oc-validity=500".
此参数包含一个值，该值指示“oc”参数值中指定的负载降低应生效的时间间隔（以毫秒为单位）。“oc validity”参数的默认值为500（毫秒）。如果客户端接收到的响应中适当填写了“oc”和“oc algo”参数，但没有“oc VALITY”参数，则SIP客户端的行为应与接收到的“oc VALITY=500”相同。
A value of 0 in the "oc-validity" parameter is reserved to denote the event that the server wishes to stop overload control or to indicate that it supports overload control but is not currently requesting any reduction in traffic (see Section 5.7).
“oc validity”参数中保留的值为0，表示服务器希望停止过载控制的事件，或表示它支持过载控制，但当前未请求任何流量减少的事件（参见第5.7节）。
A non-zero value for the "oc-validity" parameter MUST only be present in conjunction with an "oc" parameter. A SIP client MUST discard a non-zero value of the "oc-validity" parameter if the client receives it in a response without the corresponding "oc" parameter being present as well.
“oc validity”参数的非零值只能与“oc”参数一起出现。如果SIP客户端在响应中接收到“oc validity”参数的非零值，而相应的“oc”参数也不存在，则SIP客户端必须丢弃该参数的非零值。
After the value specified in the "oc-validity" parameter expires and until the SIP client receives an updated set of overload control parameters from the SIP server, overload control is not in effect between the client and the downstream SIP server.
在“oc validity”参数中指定的值过期之后，直到SIP客户端从SIP服务器接收到一组更新的过载控制参数，过载控制在客户端和下游SIP服务器之间无效。
This parameter MUST be inserted by the SIP server in a response; it MUST NOT be inserted by the SIP client in a request.
SIP服务器必须在响应中插入此参数；SIP客户端不能将其插入请求中。
This parameter contains an unsigned integer value that indicates the sequence number associated with the "oc" parameter. This sequence number is used to differentiate two "oc" parameter values generated by an overload control algorithm at two different instants in time. "oc" parameter values generated by an overload control algorithm at time t and t+1 MUST have an increasing value in the "oc-seq" parameter. This allows the upstream SIP client to properly collate out-of-order responses.
此参数包含一个无符号整数值，表示与“oc”参数关联的序列号。该序列号用于区分过载控制算法在两个不同时刻生成的两个“oc”参数值。由过载控制算法在时间t和t+1生成的“oc”参数值必须在“oc seq”参数中具有递增值。这允许上游SIP客户端正确整理无序响应。
Note: A timestamp can be used as a value of the "oc-seq" parameter.
注：时间戳可用作“oc seq”参数的值。
If the value contained in the "oc-seq" parameter overflows during the period in which the load reduction is in effect, then the "oc-seq" parameter MUST be reset to the current timestamp or an appropriate base value.
如果“oc seq”参数中包含的值在减负荷有效期间溢出，则必须将“oc seq”参数重置为当前时间戳或适当的基值。
Note: A client implementation can recognize that an overflow has occurred when it receives an "oc-seq" parameter whose value is significantly less than several previous values. (Note that an "oc-seq" parameter whose value does not deviate significantly from the last several previous values is symptomatic of a tardy packet. However, overflow will cause the "oc-seq" parameter value to be significantly less than the last several values.) If an overflow is detected, then the client should use the overload parameters in the new message, even though the sequence number is lower. The client should also reset any internal state to reflect the overflow so that future messages (following the overflow) will be accepted.
注意：当客户端实现接收到一个“oc seq”参数，该参数的值明显小于之前的几个值时，客户端实现可以识别出发生了溢出。（请注意，如果“oc seq”参数的值与前几个值没有明显偏差，则表示数据包延迟。但是，溢出会导致“oc seq”参数值明显小于前几个值。）如果检测到溢出，然后，客户机应该在新消息中使用重载参数，即使序列号较低。客户端还应重置任何内部状态以反映溢出，以便接受将来的消息（溢出后）。
When forwarding a SIP request, a SIP client uses the SIP procedures of [RFC3263] to determine the next-hop SIP server. The procedures of [RFC3263] take a SIP URI as input, extract the domain portion of that URI for use as a lookup key, query the Domain Name Service (DNS) to obtain an ordered set of one or more IP addresses with a port number and transport corresponding to each IP address in this set (the "Expected Output").
在转发SIP请求时，SIP客户端使用[RFC3263]的SIP过程来确定下一跳SIP服务器。[RFC3263]的过程将SIP URI作为输入，提取该URI的域部分以用作查找密钥，查询域名服务（DNS）以获得一个或多个IP地址的有序集，该IP地址具有端口号，传输对应于该集中的每个IP地址（“预期输出”）。
After selecting a specific SIP server from the Expected Output, a SIP client determines whether overload controls are currently active with that server. If overload controls are currently active (and the "oc-validity" period has not yet expired), the client applies the relevant algorithm to determine whether or not to send the SIP request to the server. If overload controls are not currently active with this server (which will be the case if this is the initial contact with the server, the last response from this server had
从预期输出中选择特定SIP服务器后，SIP客户端确定过载控制当前是否在该服务器上处于活动状态。如果过载控制当前处于活动状态（且“oc有效期”尚未到期），则客户端应用相关算法来确定是否向服务器发送SIP请求。如果此服务器当前未激活过载控制（如果这是与该服务器的初始联系，则会出现这种情况），则此服务器的最后一次响应为
"oc-validity=0", or the time period indicated by the "oc-validity" parameter has expired), the SIP client sends the SIP message to the server without invoking any overload control algorithm.
“oc validity=0”，或“oc validity”参数指示的时间段已过期），SIP客户端将SIP消息发送到服务器，而不调用任何过载控制算法。
If a client determines that this is the first contact with a server, the client MUST insert the "oc" parameter without any value and MUST insert the "oc-algo" parameter with a list of algorithms it supports. This list MUST include "loss" and MAY include other algorithm names approved by IANA and described in corresponding documents. The client transmits the request to the chosen server.
如果客户机确定这是与服务器的第一次联系，则客户机必须插入“oc”参数（不带任何值），并且必须插入“oc algo”参数及其支持的算法列表。该列表必须包括“损失”，还可能包括IANA批准并在相应文件中描述的其他算法名称。客户端将请求传输到所选服务器。
If a server receives a SIP request containing the "oc" and "oc-algo" parameters, the server MUST determine if it has already selected the overload control algorithm class with this client. If it has, the server SHOULD use the previously selected algorithm class in its response to the message. If the server determines that the message is from a new client or a client the server has not heard from in a long time, the server MUST choose one algorithm from the list of algorithms in the "oc-algo" parameter. It MUST put the chosen algorithm as the sole parameter value in the "oc-algo" parameter of the response it sends to the client. In addition, if the server is currently not in an overload condition, it MUST set the value of the "oc" parameter to be 0 and MAY insert an "oc-validity=0" parameter in the response to further qualify the value in the "oc" parameter. If the server is currently overloaded, it MUST follow the procedures in Section 5.2.
如果服务器接收到包含“oc”和“oc algo”参数的SIP请求，则服务器必须确定是否已经为此客户端选择了过载控制算法类。如果有，服务器应该在其对消息的响应中使用先前选择的算法类。如果服务器确定消息来自新客户机或服务器很久没有收到消息的客户机，则服务器必须从“oc algo”参数中的算法列表中选择一种算法。它必须将所选算法作为发送给客户端的响应的“oc algo”参数中的唯一参数值。此外，如果服务器当前未处于过载状态，则必须将“oc”参数的值设置为0，并可以在响应中插入“oc validity=0”参数，以进一步限定“oc”参数中的值。如果服务器当前过载，则必须遵循第5.2节中的步骤。
Note: A client that supports the rate-based overload control scheme [RATE-CONTROL] will consider "oc=0" as an indication not to send any requests downstream at all. Thus, when the server inserts "oc-validity=0" as well, it is indicating that it does support overload control, but it is not under overload mode right now (see Section 5.7).
注意：支持基于速率的过载控制方案（RATE控件）的客户端将考虑“OC＝0”作为不发送任何请求的指示。因此，当服务器同时插入“oc validity=0”时，这表明它确实支持过载控制，但它现在不在过载模式下（参见第5.7节）。
A SIP server provides overload control feedback to its upstream clients by providing a value for the "oc" parameter to the topmost Via header field of a SIP response, that is, the Via header added by the client before it sent the request to the server.
SIP服务器通过向SIP响应最顶端的Via头字段提供“oc”参数值，即客户端在向服务器发送请求之前添加的Via头，向其上游客户端提供过载控制反馈。
Since the topmost Via header of a response will be removed by an upstream client after processing it, overload control feedback contained in the "oc" parameter will not travel beyond the upstream
由于响应的最顶端Via头在处理后将被上游客户端删除，“oc”参数中包含的过载控制反馈将不会超出上游
SIP client. A Via header parameter therefore provides hop-by-hop semantics for overload control feedback (see [RFC6357]) even if the next-hop neighbor does not support this specification.
SIP客户端。因此，即使下一跳邻居不支持此规范，Via头参数也为过载控制反馈提供逐跳语义（请参见[RFC6357]）。
The "oc" parameter can be used in all response types, including provisional, success, and failure responses (please see Section 5.11 for special consideration on transporting overload control parameters in a 100 Trying response). A SIP server can update the "oc" parameter in a response, asking the client to increase or decrease the number of requests destined to the server or to stop performing overload control altogether.
“oc”参数可用于所有响应类型，包括临时响应、成功响应和失败响应（有关在100次响应中传输过载控制参数的特殊考虑，请参见第5.11节）。SIP服务器可以更新响应中的“oc”参数，请求客户端增加或减少发送给服务器的请求数，或者停止执行过载控制。
A SIP server that has updated the "oc" parameter SHOULD also add a "oc-validity" parameter. The "oc-validity" parameter defines the time in milliseconds during which the overload control feedback specified in the "oc" parameter is valid. The default value of the "oc-validity" parameter is 500 (milliseconds).
已更新“oc”参数的SIP服务器还应添加“oc validity”参数。“oc validity”参数定义了“oc”参数中指定的过载控制反馈有效的时间（以毫秒为单位）。“oc validity”参数的默认值为500（毫秒）。
When a SIP server retransmits a response, it SHOULD use the "oc" and "oc-validity" parameter values consistent with the overload state at the time the retransmitted response was sent. This implies that the values in the "oc" and "oc-validity" parameters may be different than the ones used in previous retransmissions of the response. Due to the fact that responses sent over UDP may be subject to delays in the network and arrive out of order, the "oc-seq" parameter aids in detecting a stale "oc" parameter value.
SIP服务器重新传输响应时，应使用与发送重新传输响应时的过载状态一致的“oc”和“oc validity”参数值。这意味着“oc”和“oc validity”参数中的值可能不同于先前响应重传中使用的值。由于通过UDP发送的响应可能会在网络中受到延迟并无序到达，“oc seq”参数有助于检测过时的“oc”参数值。
Implementations that are capable of updating the "oc" and "oc-validity" parameter values during retransmissions MUST insert the "oc-seq" parameter. The value of this parameter MUST be a set of numbers drawn from an increasing sequence.
能够在重传期间更新“oc”和“oc validity”参数值的实现必须插入“oc seq”参数。此参数的值必须是从递增序列中提取的一组数字。
Implementations that are not capable of updating the "oc" and "oc-validity" parameter values during retransmissions -- or implementations that do not want to do so because they will have to regenerate the message to be retransmitted -- MUST still insert a "oc-seq" parameter in the first response associated with a transaction; however, they do not have to update the value in subsequent retransmissions.
无法在重传期间更新“oc”和“oc validity”参数值的实现——或者由于必须重新生成要重传的消息而不想更新的实现——必须在与事务相关联的第一个响应中插入“oc seq”参数；但是，它们不必在随后的重新传输中更新值。
The "oc-validity" and "oc-seq" Via header parameters are only defined in SIP responses and MUST NOT be used in SIP requests. These parameters are only useful to the upstream neighbor of a SIP server (i.e., the entity that is sending requests to the SIP server) since the client is the entity that can offload traffic by redirecting or rejecting new requests. If requests are forwarded in both directions between two SIP servers (i.e., the roles of upstream/downstream
“oc validity”和“oc seq”Via头参数仅在SIP响应中定义，不得在SIP请求中使用。这些参数仅对SIP服务器的上游邻居（即，向SIP服务器发送请求的实体）有用，因为客户端是可以通过重定向或拒绝新请求来卸载流量的实体。如果请求在两个SIP服务器之间双向转发（即上游/下游服务器的角色
neighbors change), there are also responses flowing in both directions. Thus, both SIP servers can exchange overload information.
邻居改变），也有双向的反应。因此，两个SIP服务器都可以交换过载信息。
This specification provides a good overload control mechanism that can protect a SIP server from overload. However, if a SIP server wants to limit advertisements of overload control capability for privacy reasons, it might decide to perform overload control only for requests that are received on a secure transport, such as Transport Layer Security (TLS). Indicating support for overload control on a request received on an untrusted link can leak privacy in the form of capabilities supported by the server. To limit the knowledge that the server supports overload control, a server can adopt a policy of inserting overload control parameters in only those requests received over trusted links such that these parameters are only visible to trusted neighbors.
该规范提供了一种良好的过载控制机制，可以防止SIP服务器过载。然而，如果SIP服务器出于隐私原因想要限制过载控制能力的广告，它可能会决定仅对在安全传输（如传输层安全性（TLS））上接收的请求执行过载控制。指示对在不受信任的链接上接收的请求支持过载控制可能会以服务器支持的功能的形式泄露隐私。为了限制服务器支持过载控制的知识，服务器可以采用仅在通过受信任链路接收的请求中插入过载控制参数的策略，以便这些参数仅对受信任的邻居可见。
The value of the "oc" parameter is determined by the overloaded server using any pertinent information at its disposal. The only constraint imposed by this document is that the server control algorithm MUST produce a value for the "oc" parameter that it expects the receiving SIP clients to apply to all downstream SIP requests (dialogue forming as well as in-dialogue) to this SIP server. Beyond this stipulation, the process by which an overloaded server determines the value of the "oc" parameter is considered out of the scope of this document.
“oc”参数的值由过载的服务器使用其可支配的任何相关信息来确定。本文档施加的唯一约束是，服务器控制算法必须为“oc”参数生成一个值，它期望接收SIP客户端应用于该SIP服务器的所有下游SIP请求（对话形成以及对话中）。除此规定外，过载服务器确定“oc”参数值的过程不在本文档范围内。
Note: This stipulation is required so that both the client and server have a common view of which messages the overload control applies to. With this stipulation in place, the client can prioritize messages as discussed in Section 5.10.1.
注意：此规定是必需的，以便客户机和服务器都有过载控制应用于哪些消息的通用视图。有了这一规定，客户可以按照第5.10.1节的讨论对消息进行优先级排序。
As an example, a value of "oc=10" when the loss-based algorithm is used implies that 10% of the total number of SIP requests (dialogue forming as well as in-dialogue) are subject to reduction at the client. Analogously, a value of "oc=10" when the rate-based algorithm [RATE-CONTROL] is used indicates that the client should send SIP requests at a rate of 10 SIP requests or fewer per second.
例如，当使用基于丢失的算法时，值“oc＝10”意味着SIP请求总数（对话形成以及对话中）的10%在客户端被减少。类似地，当使用基于速率的算法[速率控制]时，值“oc＝10”指示客户端应以每秒10个或更少的速率发送SIP请求。
A SIP client SHOULD remove the "oc", "oc-validity", and "oc-seq" parameters from all Via headers of a response received, except for the topmost Via header. This prevents overload control parameters that were accidentally or maliciously inserted into Via headers by a downstream SIP server from traveling upstream.
SIP客户端应从接收到的响应的所有Via头中删除“oc”、“oc validity”和“oc seq”参数，但最顶端的Via头除外。这可以防止下游SIP服务器意外或恶意插入到Via头中的过载控制参数向上游移动。
The scope of overload control applies to unique combinations of IP and port values. A SIP client maintains the overload control values received (along with the address and port number of the SIP servers from which they were received) for the duration specified in the "oc-validity" parameter or the default duration. Each time a SIP client receives a response with an overload control parameter from a downstream SIP server, it compares the "oc-seq" value extracted from the Via header with the "oc-seq" value stored for this server. If these values match, the response does not update the overload control parameters related to this server, and the client continues to provide overload control as previously negotiated. If the "oc-seq" value extracted from the Via header is larger than the stored value, the client updates the stored values by copying the new values of the "oc", "oc-algo", and "oc-seq" parameters from the Via header to the stored values. Upon such an update of the overload control parameters, the client restarts the validity period of the new overload control parameters. The overload control parameters now remain in effect until the validity period expires or the parameters are updated in a new response. Stored overload control parameters MUST be reset to default values once the validity period has expired (see Section 5.7 for the detailed steps on terminating overload control).
过载控制的范围适用于IP和端口值的唯一组合。SIP客户端在“oc validity”参数中指定的持续时间或默认持续时间内维护接收到的过载控制值（以及从中接收这些值的SIP服务器的地址和端口号）。每次SIP客户端从下游SIP服务器接收到带有过载控制参数的响应时，它都会将从Via头中提取的“oc seq”值与为该服务器存储的“oc seq”值进行比较。如果这些值匹配，则响应不会更新与此服务器相关的过载控制参数，并且客户端将继续提供先前协商的过载控制。如果从Via头提取的“oc-seq”值大于存储值，则客户端通过将“oc”、“oc-algo”和“oc-seq”参数的新值从Via头复制到存储值来更新存储值。更新过载控制参数后，客户端重新启动新过载控制参数的有效期。过载控制参数现在保持有效，直到有效期到期或参数在新响应中更新。一旦有效期到期，必须将存储的过载控制参数重置为默认值（有关终止过载控制的详细步骤，请参阅第5.7节）。
A SIP client MUST honor overload control values it receives from downstream neighbors. The SIP client MUST NOT forward more requests to a SIP server than allowed by the current "oc" and "oc-algo" parameter values from that particular downstream server.
SIP客户端必须遵守从下游邻居接收的过载控制值。SIP客户端向SIP服务器转发的请求不得超过来自该特定下游服务器的当前“oc”和“oc algo”参数值所允许的数量。
When forwarding a SIP request, a SIP client uses the SIP procedures of [RFC3263] to determine the next-hop SIP server. The procedures of [RFC3263] take a SIP URI as input, extract the domain portion of that URI for use as a lookup key, query the DNS to obtain an ordered set of one or more IP addresses with a port number and transport corresponding to each IP address in this set (the Expected Output).
在转发SIP请求时，SIP客户端使用[RFC3263]的SIP过程来确定下一跳SIP服务器。[RFC3263]的过程将SIP URI作为输入，提取该URI的域部分用作查找密钥，查询DNS以获得一个或多个IP地址的有序集合，该集合中的每个IP地址对应一个端口号和传输（预期输出）。
After selecting a specific SIP server from the Expected Output, the SIP client determines if it already has overload control parameter values for the server chosen from the Expected Output. If the SIP client has a non-expired "oc" parameter value for the server chosen from the Expected Output, then this chosen server is operating in overload control mode. Thus, the SIP client determines if it can or cannot forward the current request to the SIP server based on the "oc" and "oc-algo" parameters and any relevant local policy.
从预期输出中选择特定SIP服务器后，SIP客户端确定是否已经具有从预期输出中选择的服务器的过载控制参数值。如果SIP客户端具有从预期输出中选择的服务器的未过期“oc”参数值，则所选服务器正在过载控制模式下运行。因此，SIP客户端根据“oc”和“oc algo”参数以及任何相关的本地策略来确定是否可以将当前请求转发给SIP服务器。
The particular algorithm used to determine whether or not to forward a particular SIP request is a matter of local policy and may take into account a variety of prioritization factors. However, this local policy SHOULD transmit the same number of SIP requests as the sample algorithm defined by the overload control scheme being used. (See Section 7.2 for the default loss-based overload control algorithm.)
用于确定是否转发特定SIP请求的特定算法是本地策略的问题，并且可以考虑各种优先级因素。但是，此本地策略传输的SIP请求数应与所使用的过载控制方案定义的示例算法相同。（关于默认的基于损耗的过载控制算法，请参见第7.2节。）
Overload control is defined in a hop-by-hop manner. Therefore, forwarding the contents of the overload control parameters is generally NOT RECOMMENDED and should only be performed if permitted by the configuration of SIP servers. This means that a SIP proxy SHOULD strip the overload control parameters inserted by the client before proxying the request further downstream. Of course, when the proxy acts as a client and proxies the request downstream, it is free to add overload control parameters pertinent to itself in the Via header it inserted in the request.
重载控制以逐跳方式定义。因此，通常不建议转发过载控制参数的内容，只有在SIP服务器的配置允许的情况下才应执行转发。这意味着SIP代理应该在代理进一步下游的请求之前剥离客户端插入的过载控制参数。当然，当代理充当客户端并在下游代理请求时，它可以在插入请求的Via头中自由添加与自身相关的过载控制参数。
A SIP client removes overload control if one of the following events occur:
如果发生以下事件之一，SIP客户端将删除过载控制：
1. The "oc-validity" period previously received by the client from this server (or the default value of 500 ms if the server did not previously specify an "oc-validity" parameter) expires.
1. 客户端以前从此服务器接收到的“oc有效期”（如果服务器以前未指定“oc有效期”参数，则默认值为500毫秒）将过期。
2. The client is explicitly told by the server to stop performing overload control using the "oc-validity=0" parameter.
2. 服务器会明确告知客户端停止使用“oc validity=0”参数执行过载控制。
A SIP server can decide to terminate overload control by explicitly signaling the client. To do so, the SIP server MUST set the value of the "oc-validity" parameter to 0. The SIP server MUST increment the value of "oc-seq" and SHOULD set the value of the "oc" parameter to 0.
SIP服务器可以通过显式地向客户端发送信号来决定终止过载控制。为此，SIP服务器必须将“oc validity”参数的值设置为0。SIP服务器必须增加“oc seq”的值，并应将“oc”参数的值设置为0。
Note that the loss-based overload control scheme (Section 7) can effectively stop overload control by setting the value of the "oc" parameter to 0. However, the rate-based scheme [RATE-CONTROL] needs an additional piece of information in the form of "oc-validity=0".
请注意，基于损耗的过载控制方案（第7节）可以通过将“oc”参数的值设置为0来有效地停止过载控制。然而，基于费率的方案[费率控制]需要一条“oc有效性=0”形式的附加信息。
When the client receives a response with a higher "oc-seq" number than the one it most recently processed, it checks the "oc-validity" parameter. If the value of the "oc-validity" parameter is 0, this indicates to the client that overload control of messages destined to
当客户机收到一个“oc seq”编号高于其最近处理的编号的响应时，它会检查“oc validity”参数。如果“oc validity”参数的值为0，则这向客户端指示对发送到的消息的过载控制
the server is no longer necessary and the traffic can flow without any reduction. Furthermore, when the value of the "oc-validity" parameter is 0, the client SHOULD disregard the value in the "oc" parameter.
服务器不再是必需的，通信量可以在不减少的情况下流动。此外，当“oc validity”参数的值为0时，客户端应忽略“oc”参数中的值。
Realities of deployments of SIP necessitate that the overload control algorithm may be changed upon a system reboot or a software upgrade. However, frequent changes of the overload control algorithm must be avoided. Frequent changes of the overload control algorithm will not benefit the client or the server as such flapping does not allow the chosen algorithm to stabilize. An algorithm change, when desired, is simply accomplished by the SIP server choosing a new algorithm from the list in the client's "oc-algo" parameter and sending it back to the client in a response.
SIP部署的现实需要在系统重新启动或软件升级时更改过载控制算法。然而，必须避免频繁更改过载控制算法。频繁更改过载控制算法对客户端或服务器没有好处，因为这种抖动不允许所选算法稳定。如果需要，算法更改只需通过SIP服务器从客户机的“oc algo”参数中的列表中选择一个新算法并在响应中将其发送回客户机即可完成。
The client associates a specific algorithm with each server it sends traffic to, and when the server changes the algorithm, the client must change its behavior accordingly.
客户机将特定的算法与其发送流量到的每台服务器相关联，当服务器更改算法时，客户机必须相应地更改其行为。
Once the server selects a specific overload control algorithm for a given client, the algorithm SHOULD NOT change the algorithm associated with that client for at least 3600 seconds (1 hour). This period may involve one or more cycles of overload control being in effect and then being stopped depending on the traffic and resources at the server.
一旦服务器为给定客户端选择了特定的过载控制算法，该算法至少在3600秒（1小时）内不应更改与该客户端关联的算法。这段时间可能涉及一个或多个过载控制周期生效，然后根据服务器上的流量和资源停止。
Note: One way to accomplish this involves the server saving the time of the last algorithm change in a lookup table, indexed by the client's network identifiers. The server only changes the "oc-algo" parameter when the time since the last change has surpassed 3600 seconds.
注意：实现这一点的一种方法是服务器节省查找表中最后一次算法更改的时间，该表由客户端的网络标识符索引。仅当上次更改后的时间超过3600秒时，服务器才会更改“oc algo”参数。
In some cases, a SIP client may not receive a response from a server after sending a request. RFC 3261 [RFC3261] states:
在某些情况下，SIP客户端在发送请求后可能不会收到来自服务器的响应。RFC 3261[RFC3261]规定：
Note: When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer ..., the condition MUST be treated as a 503 (Service Unavailable) status code.
注意：当从事务层接收到超时错误时，必须将其视为接收到408（请求超时）状态代码。如果传输层报告了致命的传输错误…，则必须将该情况视为503（服务不可用）状态代码。
In the event of repeated timeouts or fatal transport errors, the SIP client MUST stop sending requests to this server. The SIP client SHOULD periodically probe if the downstream server is alive using any
如果出现重复超时或致命的传输错误，SIP客户端必须停止向该服务器发送请求。SIP客户端应定期使用任何
mechanism at its disposal. Clients should be conservative in their probing (e.g., using an exponential back-off) so that their liveness probes do not exacerbate an overload situation. Once a SIP client has successfully received a normal response for a request sent to the downstream server, the SIP client can resume sending SIP requests. It should, of course, honor any overload control parameters it may receive in the initial, or later, responses.
可供其使用的机制。客户机在探测时应保持保守（例如，使用指数退避），以便其活跃度探测不会加剧过载情况。一旦SIP客户端成功接收到发送到下游服务器的请求的正常响应，SIP客户端就可以继续发送SIP请求。当然，它应该尊重在最初或以后的响应中可能收到的任何过载控制参数。
A SIP client can receive overload control feedback indicating that it needs to reduce the traffic it sends to its downstream server. The client can accomplish this task by sending some of the requests that would have gone to the overloaded element to a different destination.
SIP客户端可以接收过载控制反馈，指示它需要减少发送到下游服务器的流量。客户机可以通过向不同的目的地发送一些本应发送到重载元素的请求来完成此任务。
It needs to ensure, however, that this destination is not in overload and is capable of processing the extra load. A client can also buffer requests in the hope that the overload condition will resolve quickly and the requests can still be forwarded in time. In many cases, however, it will need to reject these requests with a "503 (Service Unavailable)" response without the Retry-After header.
但是，它需要确保该目的地没有过载，并且能够处理额外的负载。客户机还可以缓冲请求，希望过载情况能够快速解决，并且请求仍然可以及时转发。但是，在许多情况下，它需要使用“503（服务不可用）”响应拒绝这些请求，而不使用Retry After标头。
During an overload condition, a SIP client needs to prioritize requests and select those requests that need to be rejected or redirected. This selection is largely a matter of local policy. It is expected that a SIP client will follow local policy as long as the result in reduction of traffic is consistent with the overload algorithm in effect at that node. Accordingly, the normative behavior in the next three paragraphs should be interpreted with the understanding that the SIP client will aim to preserve local policy to the fullest extent possible.
在过载情况下，SIP客户端需要对请求进行优先级排序，并选择需要拒绝或重定向的请求。这种选择在很大程度上取决于当地政策。只要减少通信量的结果与该节点上有效的过载算法一致，SIP客户端将遵循本地策略。因此，在解释下三段中的规范行为时，应理解SIP客户机的目标是尽可能充分地维护当地政策。
A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on message type, e.g., INVITEs versus requests associated with existing sessions.
SIP客户端应遵守本地策略，对SIP请求进行优先级排序，例如基于消息类型的策略，例如邀请与现有会话相关的请求。
A SIP client SHOULD honor the local policy for prioritizing SIP requests based on the content of the Resource-Priority header (RPH) [RFC4412]. Specific (namespace.value) RPH contents may indicate high-priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload.
SIP客户端应遵守基于资源优先级头（RPH）内容对SIP请求进行优先级排序的本地策略[RFC4412]。特定的（namespace.value）RPH内容可能表示高优先级请求，在重载期间应尽可能多地保留这些请求。RPH内容还可以指示低优先级请求，该请求在过载期间有资格被丢弃。
A SIP client SHOULD honor the local policy for prioritizing SIP requests relating to emergency calls as identified by the SOS URN [RFC5031] indicating an emergency request. This policy ensures that
SIP客户机应遵守本地政策，按照指示紧急请求的SOS URN[RFC5031]确定的与紧急呼叫相关的SIP请求的优先级。这项政策确保
when a server is overloaded and non-emergency calls outnumber emergency calls in the traffic arriving at the client, the few emergency calls will be given preference. If, on the other hand, the server is overloaded and the majority of calls arriving at the client are emergency in nature, then no amount of message prioritization will ensure the delivery of all emergency calls if the client is to reduce the amount of traffic as requested by the server.
当服务器过载且到达客户端的流量中非紧急呼叫数超过紧急呼叫数时，将优先考虑少数紧急呼叫。另一方面，如果服务器过载，并且到达客户端的大部分呼叫本质上是紧急呼叫，那么如果客户端要按照服务器的请求减少通信量，那么没有多少消息优先级将确保所有紧急呼叫的传递。
A local policy can be expected to combine both the SIP request type and the prioritization markings, and it SHOULD be honored when overload conditions prevail.
可以期望本地策略将SIP请求类型和优先级标记结合起来，并且在过载条件盛行时应遵守该策略。
If the upstream SIP client to the overloaded server does not support overload control, it will continue to direct requests to the overloaded server. Thus, for the non-participating client, the overloaded server must bear the cost of rejecting some requests from the client as well as the cost of processing the non-rejected requests to completion. It would be fair to devote the same amount of processing at the overloaded server to the combination of rejection and processing from a non-participating client as the overloaded server would devote to processing requests from a participating client. This is to ensure that SIP clients that do not support this specification don't receive an unfair advantage over those that do.
如果到过载服务器的上游SIP客户端不支持过载控制，它将继续将请求定向到过载服务器。因此，对于未参与的客户机，过载的服务器必须承担拒绝来自客户机的某些请求的成本，以及处理未拒绝的请求直到完成的成本。公平的做法是，在过载的服务器上，将相同的处理量用于拒绝和处理来自非参与客户端的请求，就像过载的服务器用于处理来自参与客户端的请求一样。这是为了确保不支持此规范的SIP客户端不会比支持此规范的客户端获得不公平的优势。
A SIP server that is in overload and has started to throttle incoming traffic MUST reject some requests from non-participating clients with a 503 (Service Unavailable) response without the Retry-After header.
处于过载状态并已开始限制传入流量的SIP服务器必须使用503（服务不可用）响应拒绝来自非参与客户端的某些请求，而不使用Retry After标头。
The overload control information sent from a SIP server to a client is transported in the responses. While implementations can insert overload control information in any response, special attention should be accorded to overload control information transported in a 100 Trying response.
从SIP服务器发送到客户端的过载控制信息在响应中传输。虽然实现可以在任何响应中插入过载控制信息，但应特别注意在100次响应中传输的过载控制信息。
Traditionally, the 100 Trying response has been used in SIP to quench retransmissions. In some implementations, the 100 Trying message may not be generated by the transaction user (TU) nor consumed by the TU. In these implementations, the 100 Trying response is generated at the transaction layer and sent to the upstream SIP client. At the receiving SIP client, the 100 Trying is consumed at the transaction layer by inhibiting the retransmission of the corresponding request. Consequently, implementations that insert overload control information in the 100 Trying cannot assume that the upstream SIP
传统上，在SIP中使用100trying响应来终止重传。在一些实现中，100 Trying消息可能不由事务用户（TU）生成，也不被TU使用。在这些实现中，100 Trying响应在事务层生成并发送到上游SIP客户端。在接收SIP客户端，通过禁止相应请求的重传，在事务层消耗100次尝试。因此，在系统中插入过载控制信息的实现不能假定上游SIP
client passed the overload control information in the 100 Trying to their corresponding TU. For this reason, implementations that insert overload control information in the 100 Trying MUST re-insert the same (or updated) overload control information in the first non-100 Trying response being sent to the upstream SIP client.
客户端将100尝试中的过载控制信息传递给其相应的TU。因此，在100尝试中插入过载控制信息的实现必须在发送给上游SIP客户端的第一个非100尝试响应中重新插入相同（或更新）的过载控制信息。
Consider a SIP client, P1, which is sending requests to another downstream SIP server, P2. The following snippets of SIP messages demonstrate how the overload control parameters work.
考虑一个SIP客户机P1，它将请求发送到另一个下游SIP服务器P2。下面的SIP消息片段演示了过载控制参数是如何工作的。
INVITE sips:user@example.com SIP/2.0 Via: SIP/2.0/TLS p1.example.net; branch=z9hG4bK2d4790.1;oc;oc-algo="loss,A" ...
邀请SIP：user@example.comSIP/2.0 Via:SIP/2.0/TLS p1.example.net；分支=z9hG4bK2d4790.1；oc；oc algo=“损失，A”。。。
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0
...
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0
...
In the messages above, the first line is sent by P1 to P2. This line is a SIP request; because P1 supports overload control, it inserts the "oc" parameter in the topmost Via header that it created. P1 supports two overload control algorithms: "loss" and an algorithm called "A".
在上面的消息中，第一行由P1发送到P2。这一行是SIP请求；因为P1支持过载控制，所以它将“oc”参数插入到它创建的最顶端的Via头中。P1支持两种过载控制算法：“丢失”和一种称为“A”的算法。
The second line -- a SIP response -- shows the topmost Via header amended by P2 according to this specification and sent to P1. Because P2 also supports overload control and chooses the loss-based scheme, it sends "loss" back to P1 in the "oc-algo" parameter. It also sets the value of the "oc" and "oc-validity" parameters to 0 because it is not currently requesting overload control activation.
第二行——SIP响应——显示了根据本规范由P2修改并发送到P1的最顶层Via头。由于P2还支持过载控制并选择基于损耗的方案，因此它在“oc algo”参数中将“损耗”发送回P1。它还将“oc”和“oc validity”参数的值设置为0，因为它当前未请求过载控制激活。
Had P2 not supported overload control, it would have left the "oc" and "oc-algo" parameters unchanged, thus allowing the client to know that it did not support overload control.
如果P2不支持过载控制，它将保持“oc”和“oc algo”参数不变，从而允许客户端知道它不支持过载控制。
At some later time, P2 starts to experience overload. It sends the following SIP message indicating that P1 should decrease the messages arriving to P2 by 20% for 0.5 seconds.
稍后，P2开始经历过载。它发送以下SIP消息，指示P1应将到达P2的消息减少20%，持续0.5秒。
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.3;received=192.0.2.111;
oc=20;oc-algo="loss";oc-validity=500;
oc-seq=1282321615.782
...
After some time, the overload condition at P2 subsides. It then
changes the parameter values in the response it sends to P1 to allow
P1 to send all messages destined to P2.
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.3;received=192.0.2.111;
oc=20;oc-algo="loss";oc-validity=500;
oc-seq=1282321615.782
...
After some time, the overload condition at P2 subsides. It then
changes the parameter values in the response it sends to P1 to allow
P1 to send all messages destined to P2.
SIP/2.0 183 Queued
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.4;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
...
SIP/2.0 183 Queued
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.4;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
...
Under a loss-based approach, a SIP server asks an upstream neighbor to reduce the number of requests it would normally forward to this server by a certain percentage. For example, a SIP server can ask an upstream neighbor to reduce the number of requests this neighbor would normally send by 10%. The upstream neighbor then redirects or rejects 10% of the traffic originally destined for that server.
在基于丢失的方法下，SIP服务器要求上游邻居将其通常转发到此服务器的请求数量减少一定百分比。例如，SIP服务器可以要求上游邻居将该邻居通常发送的请求数减少10%。然后，上游邻居重定向或拒绝最初发送给该服务器的流量的10%。
This section specifies the semantics of the overload control parameters associated with the loss-based overload control scheme. The general behavior of SIP clients and servers is specified in Section 5 and is applicable to SIP clients and servers that implement loss-based overload control.
本节规定了与基于损耗的过载控制方案相关联的过载控制参数的语义。SIP客户端和服务器的一般行为在第5节中有规定，适用于实施基于丢失的过载控制的SIP客户端和服务器。
The loss-based overload control scheme is identified using the token "loss". This token appears in the "oc-algo" parameter list sent by the SIP client.
基于损耗的过载控制方案使用令牌“损耗”来识别。此令牌出现在SIP客户端发送的“oc algo”参数列表中。
Upon entering the overload state, a SIP server that has selected the loss-based algorithm will assign a value to the "oc" parameter. This value MUST be in the range of [0, 100], inclusive. This value indicates to the client the percentage by which the client is to reduce the number of requests being forwarded to the overloaded server. The SIP client may use any algorithm that reduces the traffic it sends to the overloaded server by the amount indicated.
进入过载状态后，选择基于丢失算法的SIP服务器将为“oc”参数分配一个值。此值必须在[0，100]的范围内，包括在内。此值向客户端指示客户端减少转发到过载服务器的请求数的百分比。SIP客户端可以使用任何算法，将发送到过载服务器的流量减少指定的数量。
Such an algorithm should honor the message prioritization discussion in Section 5.10.1. While a particular algorithm is not subject to standardization, for completeness, a default algorithm for loss-based overload control is provided in Section 7.2.
这种算法应遵循第5.10.1节中的消息优先级讨论。虽然特定算法不受标准化的约束，但为了完整性，第7.2节提供了基于损耗的过载控制的默认算法。
This section describes a default algorithm that a SIP client can use to throttle SIP traffic going downstream by the percentage loss value specified in the "oc" parameter.
本节描述了一种默认算法，SIP客户端可以使用该算法通过“oc”参数中指定的损失百分比值来限制向下游传输的SIP流量。
The client maintains two categories of requests. The first category will include requests that are candidates for reduction, and the second category will include requests that are not subject to reduction except when all messages in the first category have been rejected and further reduction is still needed. Section 5.10.1 contains directives on identifying messages for inclusion in the second category. The remaining messages are allocated to the first category.
客户端维护两类请求。第一类将包括候选缩减的请求，第二类将包括不受缩减影响的请求，除非第一类中的所有消息都已被拒绝且仍需要进一步缩减。第5.10.1节包含关于识别第二类信息的指令。剩余的消息分配给第一个类别。
Under overload condition, the client converts the value of the "oc" parameter to a value that it applies to requests in the first category. As a simple example, if "oc=10" and 40% of the requests should be included in the first category, then:
在重载条件下，客户端将“oc”参数的值转换为应用于第一类请求的值。举个简单的例子，如果“oc=10”和40%的请求应包含在第一类中，则：
10 / 40 * 100 = 25
10 / 40 * 100 = 25
Or, 25% of the requests in the first category can be reduced to get an overall reduction of 10%. The client uses random discard to achieve the 25% reduction of messages in the first category. Messages in the second category proceed downstream unscathed. To affect the 25% reduction rate from the first category, the client draws a random number between 1 and 100 for the request picked from the first category. If the random number is less than or equal to the converted value of the "oc" parameter, the request is not forwarded; otherwise, the request is forwarded.
或者，可以减少第一类中25%的请求，以获得10%的总体减少。客户端使用random discard来实现第一类邮件减少25%。第二类消息顺流而下，不会受到影响。为了影响第一个类别25%的减少率，客户机为从第一个类别中选择的请求抽取一个介于1和100之间的随机数。如果随机数小于或等于“oc”参数的转换值，则不转发请求；否则，请求将被转发。
A reference algorithm is shown below.
参考算法如下所示。
cat1 := 80.0 // Category 1 -- Subject to reduction
cat2 := 100.0 - cat1 // Category 2 -- Under normal operations,
// only subject to reduction after category 1 is exhausted.
// Note that the above ratio is simply a reasonable default.
// The actual values will change through periodic sampling
// as the traffic mix changes over time.
cat1 := 80.0 // Category 1 -- Subject to reduction
cat2 := 100.0 - cat1 // Category 2 -- Under normal operations,
// only subject to reduction after category 1 is exhausted.
// Note that the above ratio is simply a reasonable default.
// The actual values will change through periodic sampling
// as the traffic mix changes over time.
while (true) {
// We're modeling message processing as a single work
// queue that contains both incoming and outgoing messages.
sip_msg := get_next_message_from_work_queue()
while (true) {
// We're modeling message processing as a single work
// queue that contains both incoming and outgoing messages.
sip_msg := get_next_message_from_work_queue()
update_mix(cat1, cat2) // See Note below
update_mix(cat1, cat2) // See Note below
switch (sip_msg.type) {
交换机（sip_消息类型）{
case outbound request:
destination := get_next_hop(sip_msg)
oc_context := get_oc_context(destination)
case outbound request:
destination := get_next_hop(sip_msg)
oc_context := get_oc_context(destination)
if (oc_context == null) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop since this
// particular destination is not subject to overload.
}
else {
// Determine if server wants to enter in overload or is in
// overload.
in_oc := extract_in_oc(oc_context)
oc_value := extract_oc(oc_context)
oc_validity := extract_oc_validity(oc_context)
if (oc_context == null) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop since this
// particular destination is not subject to overload.
}
else {
// Determine if server wants to enter in overload or is in
// overload.
in_oc := extract_in_oc(oc_context)
oc_value := extract_oc(oc_context)
oc_validity := extract_oc_validity(oc_context)
if (in_oc == false or oc_validity is not in effect) {
send_to_network(sip_msg) // Process it normally by sending
// the request to the next hop since this particular
// destination is not subject to overload. Optionally,
// clear the oc context for this server (not shown).
}
else { // Begin performing overload control.
r := random()
drop_msg := false
if (in_oc == false or oc_validity is not in effect) {
send_to_network(sip_msg) // Process it normally by sending
// the request to the next hop since this particular
// destination is not subject to overload. Optionally,
// clear the oc context for this server (not shown).
}
else { // Begin performing overload control.
r := random()
drop_msg := false
category := assign_msg_to_category(sip_msg)
category := assign_msg_to_category(sip_msg)
pct_to_reduce_cat1 = oc_value / cat1 * 100
pct_to_reduce_cat1 = oc_value / cat1 * 100
if (oc_value <= cat1) { // Reduce all msgs from category 1
if (r <= pct_to_reduce_cat1 && category == cat1) {
drop_msg := true
}
}
else { // oc_value > category 1. Reduce 100% of msgs from
// category 1 and remaining from category 2.
pct_to_reduce_cat2 = (oc_value - cat1) / cat2 * 100
if (category == cat1) {
drop_msg := true
}
else {
if (r <= pct_to_reduce_cat2) {
drop_msg := true;
}
}
}
if (oc_value <= cat1) { // Reduce all msgs from category 1
if (r <= pct_to_reduce_cat1 && category == cat1) {
drop_msg := true
}
}
else { // oc_value > category 1. Reduce 100% of msgs from
// category 1 and remaining from category 2.
pct_to_reduce_cat2 = (oc_value - cat1) / cat2 * 100
if (category == cat1) {
drop_msg := true
}
else {
if (r <= pct_to_reduce_cat2) {
drop_msg := true;
}
}
}
if (drop_msg == false) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop.
}
else {
// Do not send request downstream; handle it locally by
// generating response (if a proxy) or treating it as
// an error (if a user agent).
}
if (drop_msg == false) {
send_to_network(sip_msg) // Process it normally by
// sending the request to the next hop.
}
else {
// Do not send request downstream; handle it locally by
// generating response (if a proxy) or treating it as
// an error (if a user agent).
}
} // End perform overload control.
}
} // End perform overload control.
}
end case // outbound request
结束案例//出站请求
case outbound response:
if (we are in overload) {
add_overload_parameters(sip_msg)
}
send_to_network(sip_msg)
case outbound response:
if (we are in overload) {
add_overload_parameters(sip_msg)
}
send_to_network(sip_msg)
end case // outbound response
结束案例//出站响应
case inbound response:
个案入站回应：
if (sip_msg has oc parameter values) {
create_or_update_oc_context() // For the specific server
// that sent the response, create or update the oc context,
// i.e., extract the values of the oc-related parameters
// and store them for later use.
if (sip_msg has oc parameter values) {
create_or_update_oc_context() // For the specific server
// that sent the response, create or update the oc context,
// i.e., extract the values of the oc-related parameters
// and store them for later use.
} process_msg(sip_msg)
}加工味精（sip味精）
end case // inbound response case inbound request:
结束案例//入站响应案例入站请求：
if (we are not in overload) {
process_msg(sip_msg)
}
else { // We are in overload.
if (sip_msg has oc parameters) { // Upstream client supports
process_msg(sip_msg) // oc; only sends important requests.
}
else { // Upstream client does not support oc
if (local_policy(sip_msg) says process message) {
process_msg(sip_msg)
}
else {
send_response(sip_msg, 503)
}
}
}
end case // inbound request
}
}
if (we are not in overload) {
process_msg(sip_msg)
}
else { // We are in overload.
if (sip_msg has oc parameters) { // Upstream client supports
process_msg(sip_msg) // oc; only sends important requests.
}
else { // Upstream client does not support oc
if (local_policy(sip_msg) says process message) {
process_msg(sip_msg)
}
else {
send_response(sip_msg, 503)
}
}
}
end case // inbound request
}
}
Note: A simple way to sample the traffic mix for category 1 and category 2 is to associate a counter with each category of message. Periodically (every 5-10 seconds), get the value of the counters, and calculate the ratio of category 1 messages to category 2 messages since the last calculation.
注：对类别1和类别2的流量组合进行采样的一种简单方法是将计数器与每个类别的消息相关联。定期（每5-10秒）获取计数器的值，并计算自上次计算以来类别1消息与类别2消息的比率。
Example: In the last 5 seconds, a total of 500 requests arrived at the queue. 450 out of the 500 were messages subject to reduction, and 50 out of 500 were classified as requests not subject to reduction. Based on this ratio, cat1 := 90 and cat2 := 10, so a 90/10 mix will be used in overload calculations.
示例：在过去5秒内，总共有500个请求到达队列。在500封邮件中，有450封邮件需要减少，而在500封邮件中，有50封被归类为不需要减少的请求。基于此比率，cat1:=90和cat2:=10，因此将在过载计算中使用90/10混合。
The overload control mechanism described in this document is reactive in nature, and apart from the message prioritization directives listed in Section 5.10.1, the mechanisms described in this document will not discriminate requests based on user identity, filtering action, and arrival time. SIP networks that require pro-active overload control mechanisms can upload user-level load control filters as described in [RFC7200]. Local policy will also dictate the precedence of different overload control mechanisms applied to
本文件中描述的过载控制机制本质上是被动的，除了第5.10.1节中列出的消息优先级指令外，本文件中描述的机制不会根据用户身份、过滤操作和到达时间区分请求。需要主动过载控制机制的SIP网络可以上传用户级负载控制过滤器，如[RFC7200]所述。本地政策还将规定应用于该系统的不同过载控制机制的优先级
the traffic. Specifically, in a scenario where load control filters are installed by signaling neighbors [RFC7200] and the same traffic can also be throttled using the overload control mechanism, local policy will dictate which of these schemes shall be given precedence. Interactions between the two schemes are out of the scope of this document.
交通堵塞。具体而言，在负载控制过滤器通过向邻居发送信号[RFC7200]安装的情况下，同样的流量也可以使用过载控制机制进行节流，本地策略将规定优先考虑这些方案中的哪一个。这两个方案之间的交互不在本文件的范围内。
This specification extends the existing definition of the Via header field parameters of [RFC3261]. The ABNF [RFC5234] syntax is as follows:
本规范扩展了[RFC3261]的Via标头字段参数的现有定义。ABNF[RFC5234]语法如下：
via-params =/ oc / oc-validity / oc-seq / oc-algo
oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT
oc-validity = "oc-validity" [EQUAL delta-ms]
oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list)
DQUOTE
algo-list = "loss" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39
delta-ms = 1*DIGIT
via-params =/ oc / oc-validity / oc-seq / oc-algo
oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT
oc-validity = "oc-validity" [EQUAL delta-ms]
oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list)
DQUOTE
algo-list = "loss" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39
delta-ms = 1*DIGIT
This section discusses specific design considerations for the mechanism described in this document. General design considerations for SIP overload control can be found in [RFC6357].
本节讨论本文件中所述机构的具体设计注意事项。SIP过载控制的一般设计考虑可在[RFC6357]中找到。
A SIP mechanism is needed to convey overload feedback from the receiving to the sending SIP entity. A number of different alternatives exist to implement such a mechanism.
需要SIP机制将过载反馈从接收端传送到发送SIP实体。有许多不同的备选方案来实施这种机制。
Overload control information can be transmitted using a new Via header field parameter for overload control. A SIP server can add this header parameter to the responses it is sending upstream to provide overload control feedback to its upstream neighbors. This approach has the following characteristics:
过载控制信息可以使用用于过载控制的新Via header字段参数进行传输。SIP服务器可以将此头参数添加到向上游发送的响应中，以向其上游邻居提供过载控制反馈。这种方法具有以下特点：
o A Via header parameter is light-weight and creates very little overhead. It does not require the transmission of additional messages for overload control and does not increase traffic or processing burdens in an overload situation.
o Via头参数重量轻，产生的开销很小。它不需要为过载控制传输额外的消息，也不会在过载情况下增加流量或处理负担。
o Overload control status can frequently be reported to upstream neighbors since it is a part of a SIP response. This enables the use of this mechanism in scenarios where the overload status needs to be adjusted frequently. It also enables the use of overload control mechanisms that use regular feedback, such as window-based overload control.
o 过载控制状态可以经常报告给上游邻居，因为它是SIP响应的一部分。这使得在需要频繁调整过载状态的场景中可以使用此机制。它还支持使用使用定期反馈的过载控制机制，例如基于窗口的过载控制。
o With a Via header parameter, overload control status is inherent in SIP signaling and is automatically conveyed to all relevant upstream neighbors, i.e., neighbors that are currently contributing traffic. There is no need for a SIP server to specifically track and manage the set of current upstream or downstream neighbors with which it should exchange overload feedback.
o 通过Via报头参数，过载控制状态在SIP信令中是固有的，并自动传送到所有相关的上游邻居，即当前提供流量的邻居。SIP服务器不需要专门跟踪和管理一组当前的上游或下游邻居，它应该与这些邻居交换过载反馈。
o Overload status is not conveyed to inactive senders. This avoids the transmission of overload feedback to inactive senders, which do not contribute traffic. If an inactive sender starts to transmit while the receiver is in overload, it will receive overload feedback in the first response and can adjust the amount of traffic forwarded accordingly.
o 过载状态不会传送到非活动发送方。这样可以避免将过载反馈传输到不参与通信的非活动发送方。如果非活动发送方在接收方过载时开始发送，它将在第一次响应中接收过载反馈，并可以相应地调整转发的通信量。
o A SIP server can limit the distribution of overload control information by only inserting it into responses to known upstream neighbors. A SIP server can use transport-level authentication (e.g., via TLS) with its upstream neighbors.
o SIP服务器只需将过载控制信息插入到对已知上游邻居的响应中，就可以限制过载控制信息的分发。SIP服务器可以与其上游邻居使用传输级身份验证（例如，通过TLS）。
Overload control information can also be conveyed from a receiver to a sender using a new event package. Such an event package enables a sending entity to subscribe to the overload status of its downstream neighbors and receive notifications of overload control status changes in NOTIFY requests. This approach has the following characteristics:
过载控制信息也可以使用新的事件包从接收方传送到发送方。这样的事件包使发送实体能够订阅其下游邻居的过载状态，并在NOTIFY请求中接收过载控制状态更改的通知。这种方法具有以下特点：
o Overload control information is conveyed decoupled from SIP signaling. It enables an overload control manager, which is a separate entity, to monitor the load on other servers and provide overload control feedback to all SIP servers that have set up subscriptions with the controller.
o 过载控制信息的传输与SIP信令分离。它使过载控制管理器（一个单独的实体）能够监视其他服务器上的负载，并向所有已与控制器建立订阅的SIP服务器提供过载控制反馈。
o With an event package, a receiver can send updates to senders that are currently inactive. Inactive senders will receive a notification about the overload and can refrain from sending traffic to this neighbor until the overload condition is resolved.
o 使用事件包，接收者可以向当前处于非活动状态的发送者发送更新。非活动发送方将收到有关过载的通知，并且在过载情况得到解决之前，可以避免向该邻居发送通信量。
The receiver can also notify all potential senders once they are permitted to send traffic again. However, these notifications do generate additional traffic, which adds to the overall load.
一旦允许所有潜在发送方再次发送通信量，接收方还可以通知所有潜在发送方。但是，这些通知确实会生成额外的流量，从而增加总体负载。
o A SIP entity needs to set up and maintain overload control subscriptions with all upstream and downstream neighbors. A new subscription needs to be set up before/while a request is transmitted to a new downstream neighbor. Servers can be configured to subscribe at boot time. However, this would require additional protection to avoid the avalanche restart problem for overload control. Subscriptions need to be terminated when they are not needed any more, which can be done, for example, using a timeout mechanism.
o SIP实体需要与所有上游和下游邻居建立和维护过载控制订阅。在将请求传输到新的下游邻居之前/期间，需要设置新的订阅。服务器可以配置为在启动时订阅。然而，这需要额外的保护，以避免过载控制的雪崩重启问题。当不再需要订阅时，需要终止订阅，这可以通过使用超时机制来完成。
o A receiver needs to send NOTIFY messages to all subscribed upstream neighbors in a timely manner when the control algorithm requires a change in the control variable (e.g., when a SIP server is in an overload condition). This includes active as well as inactive neighbors. These NOTIFYs add to the amount of traffic that needs to be processed. To ensure that these requests will not be dropped due to overload, a priority mechanism needs to be implemented in all servers these requests will pass through.
o 当控制算法需要更改控制变量时（例如，当SIP服务器处于过载状态时），接收器需要及时向所有订阅的上游邻居发送通知消息。这包括活动邻居和非活动邻居。这些NOTIFY增加了需要处理的通信量。为了确保这些请求不会因为过载而被丢弃，需要在这些请求将通过的所有服务器中实现优先级机制。
o As overload feedback is sent to all senders in separate messages, this mechanism is not suitable when frequent overload control feedback is needed.
o 由于过载反馈在单独的消息中发送给所有发送者，因此当需要频繁的过载控制反馈时，此机制不适用。
o A SIP server can limit the set of senders that can receive overload control information by authenticating subscriptions to this event package.
o SIP服务器可以通过验证对此事件包的订阅来限制可以接收过载控制信息的发送者集。
o This approach requires each proxy to implement user agent functionality (UAS and UAC) to manage the subscriptions.
o 这种方法要求每个代理实现用户代理功能（UAS和UAC）来管理订阅。
A new overload control mechanism needs to be backwards compatible so that it can be gradually introduced into a network and function properly if only a fraction of the servers support it.
一种新的过载控制机制需要向后兼容，以便在只有一小部分服务器支持的情况下，它可以逐渐引入网络并正常工作。
Hop-by-hop overload control (see [RFC6357]) has the advantage that it does not require that all SIP entities in a network support it. It can be used effectively between two adjacent SIP servers if both servers support overload control and does not depend on the support from any other server or user agent. The more SIP servers in a network support hop-by-hop overload control, the better protected the network is against occurrences of overload.
逐跳过载控制（参见[RFC6357]）的优点是它不要求网络中的所有SIP实体都支持它。如果两台服务器都支持过载控制，并且不依赖于任何其他服务器或用户代理的支持，则可以在两台相邻的SIP服务器之间有效地使用它。网络中支持逐跳过载控制的SIP服务器越多，网络对过载的保护就越好。
A SIP server may have multiple upstream neighbors from which only some may support overload control. If a server would simply use this overload control mechanism, only those that support it would reduce traffic. Others would keep sending at the full rate and benefit from the throttling by the servers that support overload control. In other words, upstream neighbors that do not support overload control would be better off than those that do.
SIP服务器可能有多个上游邻居，其中只有一些邻居可能支持过载控制。如果服务器只使用这种过载控制机制，那么只有支持这种机制的服务器才能减少通信量。其他人将继续以全速发送，并从支持过载控制的服务器的节流中获益。换句话说，不支持过载控制的上游邻居将比支持过载控制的上游邻居境况更好。
A SIP server should therefore follow the behavior outlined in Section 5.10.2 to handle clients that do not support overload control.
因此，SIP服务器应遵循第5.10.2节中概述的行为来处理不支持过载控制的客户端。
Overload control mechanisms can be used by an attacker to conduct a denial-of-service attack on a SIP entity if the attacker can pretend that the SIP entity is overloaded. When such a forged overload indication is received by an upstream SIP client, it will stop sending traffic to the victim. Thus, the victim is subject to a denial-of-service attack.
如果攻击者可以假装SIP实体过载，则攻击者可以使用过载控制机制对SIP实体进行拒绝服务攻击。当上游SIP客户端接收到这种伪造的过载指示时，它将停止向受害者发送流量。因此，受害者会受到拒绝服务攻击。
To better understand the threat model, consider the following diagram:
为了更好地理解威胁模型，请考虑下面的图表：
Pa ------- ------ Pb
\ /
: ------ +-------- P1 ------+------ :
/ L1 L2 \
: ------- ------ :
Pa ------- ------ Pb
\ /
: ------ +-------- P1 ------+------ :
/ L1 L2 \
: ------- ------ :
-----> Downstream (requests)
<----- Upstream (responses)
-----> Downstream (requests)
<----- Upstream (responses)
Here, requests travel downstream from the left-hand side, through Proxy P1, towards the right-hand side; responses travel upstream from the right-hand side, through P1, towards the left-hand side. Proxies Pa, Pb, and P1 support overload control. L1 and L2 are labels for the links connecting P1 to the upstream clients and downstream servers.
这里，请求从左侧向下移动，通过代理P1，到达右侧；响应从右侧向上游移动，通过P1向左侧移动。代理Pa、Pb和P1支持过载控制。L1和L2是将P1连接到上游客户端和下游服务器的链路的标签。
If an attacker is able to modify traffic between Pa and P1 on link L1, it can cause a denial-of-service attack on P1 by having Pa not send any traffic to P1. Such an attack can proceed by the attacker modifying the response from P1 to Pa such that Pa's Via header is changed to indicate that all requests destined towards P1 should be dropped. Conversely, the attacker can simply remove any "oc", "oc-validity", and "oc-seq" markings added by P1 in a response to Pa. In
如果攻击者能够修改链路L1上Pa和P1之间的通信量，则可通过让Pa不向P1发送任何通信量，在P1上造成拒绝服务攻击。攻击者可以通过修改从P1到Pa的响应来进行此类攻击，从而更改Pa的Via标头，以指示所有发送到P1的请求都应该被丢弃。相反，攻击者可以简单地删除P1在响应Pa中添加的任何“oc”、“oc validity”和“oc seq”标记
such a case, the attacker will force P1 into overload by denying request quenching at Pa even though Pa is capable of performing overload control.
在这种情况下，即使Pa能够执行过载控制，攻击者也会通过拒绝Pa的请求终止来迫使P1过载。
Similarly, if an attacker is able to modify traffic between P1 and Pb on link L2, it can change the Via header associated with P1 in a response from Pb to P1 such that all subsequent requests destined towards Pb from P1 are dropped. In essence, the attacker mounts a denial-of-service attack on Pb by indicating false overload control. Note that it is immaterial whether Pb supports overload control or not; the attack will succeed as long as the attacker is able to control L2. Conversely, an attacker can suppress a genuine overload condition at Pb by simply removing any "oc", "oc-validity", and "oc-seq" markings added by Pb in a response to P1. In such a case, the attacker will force P1 into sending requests to Pb even under overload conditions because P1 would not be aware that Pb supports overload control.
类似地，如果攻击者能够修改链路L2上P1和Pb之间的通信量，则可以在从Pb到P1的响应中更改与P1关联的Via标头，从而丢弃所有从P1发送到Pb的后续请求。本质上，攻击者通过指示错误的过载控制，在Pb上发起拒绝服务攻击。请注意，Pb是否支持过载控制并不重要；只要攻击者能够控制L2，攻击就会成功。相反，攻击者只需删除Pb在响应P1时添加的任何“oc”、“oc validity”和“oc seq”标记，即可在Pb处抑制真正的过载情况。在这种情况下，即使在过载条件下，攻击者也会迫使P1向Pb发送请求，因为P1不会意识到Pb支持过载控制。
Attacks that indicate false overload control are best mitigated by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be similarly avoided by using TLS on the connection. Generally, TCP or WebSockets [RFC6455] in conjunction with BCP 38 makes it more difficult for an attacker to insert or modify messages but may still prove inadequate against an adversary that controls links L1 and L2. TLS provides the best protection from an attacker with access to the network links.
指示错误过载控制的攻击最好通过结合使用TLS和应用BCP 38[RFC2827]来缓解。通过在连接上使用TLS，同样可以避免为抑制真实过载情况而安装的攻击。通常，TCP或WebSockets[RFC6455]与BCP 38结合使用会使攻击者更难插入或修改消息，但可能仍然无法抵御控制链路L1和L2的对手。TLS提供了最好的保护，使攻击者能够访问网络链接。
Another way to conduct an attack is to send a message containing a high overload feedback value through a proxy that does not support this extension. If this feedback is added to the second Via header (or all Via headers), it will reach the next upstream proxy. If the attacker can make the recipient believe that the overload status was created by its direct downstream neighbor (and not by the attacker further downstream), the recipient stops sending traffic to the victim. A precondition for this attack is that the victim proxy does not support this extension since it would not pass through overload control feedback otherwise.
另一种攻击方式是通过不支持此扩展的代理发送包含高过载反馈值的消息。如果将此反馈添加到第二个Via头（或所有Via头），它将到达下一个上游代理。如果攻击者可以让收件人相信过载状态是由其直接下游邻居（而不是下游攻击者）创建的，则收件人将停止向受害者发送流量。此攻击的一个先决条件是受害者代理不支持此扩展，因为否则它不会通过过载控制反馈。
A malicious SIP entity could gain an advantage by pretending to support this specification but never reducing the amount of traffic it forwards to the downstream neighbor. If its downstream neighbor receives traffic from multiple sources that correctly implement overload control, the malicious SIP entity would benefit since all other sources to its downstream neighbor would reduce load.
恶意SIP实体可以通过假装支持此规范而从不减少转发给下游邻居的流量来获得优势。如果其下游邻居从正确实施过载控制的多个源接收流量，恶意SIP实体将受益，因为其下游邻居的所有其他源将减少负载。
Note: The solution to this problem depends on the overload control method. With rate-based, window-based, and other similar overload control algorithms that promise to produce no more than a specified number of requests per unit time, the overloaded server can regulate the traffic arriving to it. However, when using loss-based overload control, such policing is not always obvious since the load forwarded depends on the load received by the client.
注：此问题的解决方案取决于过载控制方法。使用基于速率、基于窗口和其他类似的过载控制算法，保证每单位时间产生的请求数不超过指定数量，过载服务器可以调节到达它的流量。但是，当使用基于丢失的过载控制时，这种策略并不总是明显的，因为转发的负载取决于客户端接收的负载。
To prevent such attacks, servers should monitor client behavior to determine whether they are complying with overload control policies. If a client is not conforming to such policies, then the server should treat it as a non-supporting client (see Section 5.10.2).
为防止此类攻击，服务器应监视客户端行为，以确定它们是否符合过载控制策略。如果客户端不符合此类策略，则服务器应将其视为非支持客户端（见第5.10.2节）。
Finally, a distributed denial-of-service (DDoS) attack could cause an honest server to start signaling an overload condition. Such a DDoS attack could be mounted without controlling the communications links since the attack simply depends on the attacker injecting a large volume of packets on the communication links. If the honest server attacked by a DDoS attack has a long "oc-validity" interval and the attacker can guess this interval, the attacker can keep the server overloaded by synchronizing the DDoS traffic with the validity period. While such an attack may be relatively easy to spot, mechanisms for combating it are outside the scope of this document and, of course, since attackers can invent new variations, the appropriate mechanisms are likely to change over time.
最后，分布式拒绝服务（DDoS）攻击可能导致诚实的服务器开始发出过载状态的信号。这种DDoS攻击可以在不控制通信链路的情况下进行，因为攻击完全取决于攻击者在通信链路上注入大量数据包。如果受DDoS攻击的诚实服务器具有较长的“oc有效期”间隔，并且攻击者可以猜测该间隔，则攻击者可以通过将DDoS流量与有效期同步来保持服务器过载。虽然此类攻击可能相对容易发现，但与之对抗的机制不在本文档的范围内，当然，由于攻击者可以发明新的变体，因此适当的机制可能会随着时间的推移而改变。
This specification defines four new Via header parameters as detailed below in the "Header Field Parameter and Parameter Values" sub-registry as per the registry created by [RFC3968]. The required information is:
本规范根据[RFC3968]创建的注册表，在“header Field Parameter and Parameter Values”（标题字段参数和参数值）子注册表中定义了四个新的Via标题参数，详情如下。所需资料如下：
Header Field Parameter Name Predefined Values Reference
__________________________________________________________
Via oc Yes [RFC7339]
Via oc-validity Yes [RFC7339]
Via oc-seq Yes [RFC7339]
Via oc-algo Yes [RFC7339]
Header Field Parameter Name Predefined Values Reference
__________________________________________________________
Via oc Yes [RFC7339]
Via oc-validity Yes [RFC7339]
Via oc-seq Yes [RFC7339]
Via oc-algo Yes [RFC7339]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RATE-CONTROL] Noel, E. and P. Williams, "Session Initiation Protocol (SIP) Rate Control", Work in Progress, July 2014.
[速率控制]Noel，E.和P.Williams，“会话启动协议（SIP）速率控制”，正在进行的工作，2014年7月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008.
[RFC5390]Rosenberg，J.，“会话启动协议中过载管理的要求”，RFC 53902008年12月。
[RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design Considerations for Session Initiation Protocol (SIP) Overload Control", RFC 6357, August 2011.
[RFC6357]Hilt，V.，Noel，E.，Shen，C.，和A.Abdelal，“会话启动协议（SIP）过载控制的设计考虑”，RFC 6357，2011年8月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 64552011年12月。
[RFC7200] Shen, C., Schulzrinne, H., and A. Koike, "A Session Initiation Protocol (SIP) Load-Control Event Package", RFC 7200, April 2014.
[RFC7200]Shen，C.，Schulzrinne，H.，和A.Koike，“会话启动协议（SIP）负载控制事件包”，RFC 7200，2014年4月。
The authors acknowledge the contributions of Bruno Chatras, Keith Drage, Janet Gunn, Rich Terpstra, Daryl Malas, Eric Noel, R. Parthasarathi, Antoine Roly, Jonathan Rosenberg, Charles Shen, Rahul Srivastava, Padma Valluri, Shaun Bharrat, Paul Kyzivat, and Jeroen Van Bemmel to this document.
作者感谢Bruno Chatras、Keith Drage、Janet Gunn、Rich Terpstra、Daryl Malas、Eric Noel、R.Parthasarathi、Antoine Roly、Jonathan Rosenberg、Charles Shen、Rahul Srivastava、Padma Valluri、Shaun Bharrat、Paul Kyzivat和Jeroen Van Bemmel对本文件的贡献。
Adam Roach and Eric McMurry helped flesh out the different cases for handling SIP messages described in the algorithm in Section 7.2. Janet Gunn reviewed the algorithm and suggested changes that led to simpler processing for the case where "oc_value > cat1".
亚当·罗奇（Adam Roach）和埃里克·麦克默里（Eric McMurry）帮助充实了第7.2节算法中描述的处理SIP消息的不同案例。Janet Gunn回顾了该算法，并建议对“oc_值>cat1”的情况进行修改，以简化处理。
Richard Barnes provided invaluable comments as a part of the Area Director review of the document.
Richard Barnes提供了宝贵的意见，作为区域主任审查该文件的一部分。
Table 1 provides a summary of how this specification fulfills the requirements of [RFC5390]. A more detailed view on how each requirements is fulfilled is provided after the table.
表1总结了本规范如何满足[RFC5390]的要求。表后提供了关于如何满足每个要求的更详细视图。
+-------------+-------------------+
| Requirement | Meets requirement |
+-------------+-------------------+
| REQ 1 | Yes |
| REQ 2 | Yes |
| REQ 3 | Partially |
| REQ 4 | Yes |
| REQ 5 | Partially |
| REQ 6 | Not applicable |
| REQ 7 | Yes |
| REQ 8 | Partially |
| REQ 9 | Yes |
| REQ 10 | Yes |
| REQ 11 | Yes |
| REQ 12 | Yes |
| REQ 13 | Yes |
| REQ 14 | Yes |
| REQ 15 | Yes |
| REQ 16 | Yes |
| REQ 17 | Partially |
| REQ 18 | Yes |
| REQ 19 | Yes |
| REQ 20 | Yes |
| REQ 21 | Yes |
| REQ 22 | Yes |
| REQ 23 | Yes |
+-------------+-------------------+
+-------------+-------------------+
| Requirement | Meets requirement |
+-------------+-------------------+
| REQ 1 | Yes |
| REQ 2 | Yes |
| REQ 3 | Partially |
| REQ 4 | Yes |
| REQ 5 | Partially |
| REQ 6 | Not applicable |
| REQ 7 | Yes |
| REQ 8 | Partially |
| REQ 9 | Yes |
| REQ 10 | Yes |
| REQ 11 | Yes |
| REQ 12 | Yes |
| REQ 13 | Yes |
| REQ 14 | Yes |
| REQ 15 | Yes |
| REQ 16 | Yes |
| REQ 17 | Partially |
| REQ 18 | Yes |
| REQ 19 | Yes |
| REQ 20 | Yes |
| REQ 21 | Yes |
| REQ 22 | Yes |
| REQ 23 | Yes |
+-------------+-------------------+
Table 1: Summary of Meeting Requirements in RFC 5390
表1：满足RFC 5390要求的汇总
REQ 1: The overload mechanism shall strive to maintain the overall useful throughput (taking into consideration the quality-of-service needs of the using applications) of a SIP server at reasonable levels, even when the incoming load on the network is far in excess of its capacity. The overall throughput under load is the ultimate measure of the value of an overload control mechanism.
REQ 1：过载机制应努力将SIP服务器的总体有效吞吐量（考虑到使用应用程序的服务质量需求）保持在合理水平，即使网络上的输入负载远远超过其容量。负载下的总吞吐量是过载控制机制值的最终度量。
Meets REQ 1: Yes. The overload control mechanism allows an overloaded SIP server to maintain a reasonable level of throughput as it enters into congestion mode by requesting the upstream clients to reduce traffic destined downstream.
满足要求1：是。过载控制机制允许过载的SIP服务器在进入拥塞模式时通过请求上游客户端减少目的地为下游的流量来保持合理的吞吐量水平。
REQ 2: When a single network element fails, goes into overload, or suffers from reduced processing capacity, the mechanism should strive to limit the impact of this on other elements in the network. This helps to prevent a small-scale failure from becoming a widespread outage.
REQ 2：当单个网元出现故障、过载或处理能力降低时，该机制应努力限制其对网络中其他网元的影响。这有助于防止小规模故障成为大范围停机。
Meets REQ 2: Yes. When a SIP server enters overload mode, it will request the upstream clients to throttle the traffic destined to it. As a consequence of this, the overloaded SIP server will itself generate proportionally less downstream traffic, thereby limiting the impact on other elements in the network.
满足要求2：是。当SIP服务器进入过载模式时，它将请求上游客户端限制发送给它的流量。因此，过载的SIP服务器本身将按比例减少下游流量，从而限制对网络中其他元素的影响。
REQ 3: The mechanism should seek to minimize the amount of configuration required in order to work. For example, it is better to avoid needing to configure a server with its SIP message throughput, as these kinds of quantities are hard to determine.
要求3：该机制应尽量减少工作所需的配置量。例如，最好避免使用SIP消息吞吐量配置服务器，因为这些数量很难确定。
Meets REQ 3: Partially. On the server side, the overload condition is determined monitoring "S" (cf., Section 4 of [RFC6357]) and reporting a load feedback "F" as a value to the "oc" parameter. On the client side, a throttle "T" is applied to requests going downstream based on "F". This specification does not prescribe any value for "S" nor a particular value for "F". The "oc-algo" parameter allows for automatic convergence to a particular class of overload control algorithm. There are suggested default values for the "oc-validity" parameter.
满足要求3：部分。在服务器端，通过监视“S”（参见[RFC6357]第4节）并将负载反馈“F”作为值报告给“oc”参数来确定过载条件。在客户端，节流阀“T”应用于基于“F”的下游请求。本规范未规定“S”的任何值，也未规定“F”的特定值。“oc algo”参数允许自动收敛到特定类别的过载控制算法。“oc validity”参数有建议的默认值。
REQ 4: The mechanism must be capable of dealing with elements that do not support it so that a network can consist of a mix of elements that do and don't support it. In other words, the mechanism should not work only in environments where all elements support it. It is reasonable to assume that it works better in such environments, of course. Ideally, there should be incremental improvements in overall network throughput as increasing numbers of elements in the network support the mechanism.
REQ 4：该机制必须能够处理不支持它的元素，以便网络可以由支持和不支持它的元素的混合组成。换句话说，该机制不应该只在所有元素都支持它的环境中工作。当然，我们有理由假设它在这样的环境中工作得更好。理想情况下，随着网络中支持该机制的元素数量的增加，总体网络吞吐量应该有增量的提高。
Meets REQ 4: Yes. The mechanism is designed to reduce congestion when a pair of communicating entities support it. If a downstream overloaded SIP server does not respond to a request in time, a SIP client will attempt to reduce traffic destined towards the non-responsive server as outlined in Section 5.9.
满足要求4：是。该机制设计用于在一对通信实体支持时减少拥塞。如果下游过载的SIP服务器没有及时响应请求，SIP客户端将尝试减少发送到非响应服务器的流量，如第5.9节所述。
REQ 5: The mechanism should not assume that it will only be deployed in environments with completely trusted elements. It should seek to operate as effectively as possible in environments where other elements are malicious; this includes preventing malicious elements from obtaining more than a fair share of service.
REQ 5：该机制不应假定它仅部署在具有完全受信任元素的环境中。它应寻求在其他元素恶意的环境中尽可能有效地运行；这包括防止恶意元素获得超过公平份额的服务。
Meets REQ 5: Partially. Since overload control information is shared between a pair of communicating entities, a confidential and authenticated channel can be used for this communication. However, if such a channel is not available, then the security ramifications outlined in Section 11 apply.
满足要求5：部分。由于过载控制信息在一对通信实体之间共享，因此可以使用保密和经过身份验证的通道进行此通信。但是，如果此类渠道不可用，则第11节中概述的安全后果适用。
REQ 6: When overload is signaled by means of a specific message, the message must clearly indicate that it is being sent because of overload, as opposed to other, non-overload-based failure conditions. This requirement is meant to avoid some of the problems that have arisen from the reuse of the 503 response code for multiple purposes. Of course, overload is also signaled by lack of response to requests. This requirement applies only to explicit overload signals.
REQ 6：当通过特定消息发出过载信号时，该消息必须清楚地表明是由于过载而发送的，而不是其他基于非过载的故障情况。此要求旨在避免因将503响应代码用于多种用途而产生的一些问题。当然，过载的信号还包括对请求的响应不足。此要求仅适用于明确的过载信号。
Meets REQ 6: Not applicable. Overload control information is signaled as part of the Via header and not in a new header.
符合要求6：不适用。过载控制信息作为Via报头的一部分发出信号，而不是在新报头中。
REQ 7: The mechanism shall provide a way for an element to throttle the amount of traffic it receives from an upstream element. This throttling shall be graded so that it is not "all or nothing" as with the current 503 mechanism. This recognizes the fact that overload is not a binary state and that there are degrees of overload.
REQ 7：该机制应为元件提供一种方式，以限制其从上游元件接收的通信量。该节流应分级，以使其不像当前503机制那样“全有或全无”。这认识到过载不是二进制状态，并且存在不同程度的过载。
Meets REQ 7: Yes. Please see Sections 5.5 and 5.10.
符合要求7：是。请参见第5.5节和第5.10节。
REQ 8: The mechanism shall ensure that, when a request was not processed successfully due to overload (or failure) of a downstream element, the request will not be retried on another element that is also overloaded or whose status is unknown. This requirement derives from REQ 1.
REQ 8：该机制应确保，当由于下游元件过载（或故障）导致请求未成功处理时，不会在另一个同样过载或状态未知的元件上重试该请求。此要求源自REQ 1。
Meets REQ 8: Partially. A SIP client that has overload information from multiple downstream servers will not retry the request on another element. However, if a SIP client does not know the overload status of a downstream server, it may send the request to that server.
满足要求8：部分。具有来自多个下游服务器的过载信息的SIP客户端不会在另一个元素上重试该请求。但是，如果SIP客户端不知道下游服务器的过载状态，它可能会向该服务器发送请求。
REQ 9: That a request has been rejected from an overloaded element shall not unduly restrict the ability of that request to be submitted to and processed by an element that is not overloaded. This requirement derives from REQ 1.
REQ 9：来自过载元素的请求被拒绝不应过度限制该请求提交给未过载元素并由其处理的能力。此要求源自REQ 1。
Meets REQ 9: Yes. A SIP client conformant to this specification will send the request to a different element.
符合要求9：是。符合此规范的SIP客户端将向不同的元素发送请求。
REQ 10: The mechanism should support servers that receive requests from a large number of different upstream elements, where the set of upstream elements is not enumerable.
REQ 10：该机制应支持从大量不同上游元素接收请求的服务器，其中上游元素集不可枚举。
Meets REQ 10: Yes. There are no constraints on the number of upstream clients.
符合要求10：是。上游客户机的数量没有限制。
REQ 11: The mechanism should support servers that receive requests from a finite set of upstream elements, where the set of upstream elements is enumerable.
REQ 11：该机制应支持从有限的上游元素集接收请求的服务器，其中上游元素集是可枚举的。
Meets REQ 11: Yes. There are no constraints on the number of upstream clients.
满足要求11：是。上游客户机的数量没有限制。
REQ 12: The mechanism should work between servers in different domains.
请求12：该机制应在不同域中的服务器之间工作。
Meets REQ 12: Yes. There are no inherent limitations on using overload control between domains. However, interconnections points that engage in overload control between domains will have to populate and maintain the overload control parameters as requests cross domains.
符合要求12：是。在域之间使用重载控制没有固有的限制。但是，当请求跨域时，参与域间过载控制的互连点必须填充并维护过载控制参数。
REQ 13: The mechanism must not dictate a specific algorithm for prioritizing the processing of work within a proxy during times of overload. It must permit a proxy to prioritize requests based on any local policy so that certain ones (such as a call for emergency services or a call with a specific value of the Resource-Priority header field [RFC4412]) are given preferential treatment, such as not being dropped, being given additional retransmission, or being processed ahead of others.
REQ 13：该机制不得规定在过载期间对代理内的工作处理进行优先级排序的特定算法。它必须允许代理根据任何本地策略对请求进行优先级排序，以使某些请求（例如紧急服务呼叫或具有资源优先级标头字段[RFC4412]特定值的呼叫）得到优先处理，例如不被丢弃、被给予额外重传或被提前处理。
Meets REQ 13: Yes. Please see Section 5.10.
满足要求13：是。请参见第5.10节。
REQ 14: The mechanism should provide unambiguous directions to clients on when they should retry a request and when they should not. This especially applies to TCP connection establishment and SIP registrations in order to mitigate against an avalanche restart.
REQ 14：该机制应向客户端提供明确的指示，说明何时应重试请求，何时不应重试请求。这尤其适用于TCP连接建立和SIP注册，以缓解雪崩重启。
Meets REQ 14: Yes. Section 5.9 provides normative behavior on when to retry a request after repeated timeouts and fatal transport errors resulting from communications with a non-responsive downstream SIP server.
符合要求14：是。第5.9节提供了在与非响应下游SIP服务器通信导致重复超时和致命传输错误后，何时重试请求的规范行为。
REQ 15: In cases where a network element fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure or network partition, it will not be able to provide explicit indications of the nature of the failure or its levels of congestion. The mechanism must properly function in these cases.
REQ 15：如果一个网元发生故障，过载到无法处理消息，或者由于网络故障或网络分区而无法通信，那么它将无法提供故障性质或拥塞级别的明确指示。在这些情况下，该机制必须正常运作。
Meets REQ 15: Yes. Section 5.9 provides normative behavior on when to retry a request after repeated timeouts and fatal transport errors resulting from communications with a non-responsive downstream SIP server.
满足要求15：是。第5.9节提供了在与非响应下游SIP服务器通信导致重复超时和致命传输错误后，何时重试请求的规范行为。
REQ 16: The mechanism should attempt to minimize the overhead of the overload control messaging.
REQ 16：该机制应尝试最小化过载控制消息传递的开销。
Meets REQ 16: Yes. Overload control messages are sent in the topmost Via header, which is always processed by the SIP elements.
符合要求16：是。过载控制消息通过报头在最顶端发送，该报头始终由SIP元素处理。
REQ 17: The overload mechanism must not provide an avenue for malicious attack, including DoS and DDoS attacks.
请求17：过载机制不得提供恶意攻击的途径，包括DoS和DDoS攻击。
Meets REQ 17: Partially. Since overload control information is shared between a pair of communicating entities, a confidential and authenticated channel can be used for this communication. However, if such a channel is not available, then the security ramifications outlined in Section 11 apply.
满足要求17：部分。由于过载控制信息在一对通信实体之间共享，因此可以使用保密和经过身份验证的通道进行此通信。但是，如果此类渠道不可用，则第11节中概述的安全后果适用。
REQ 18: The overload mechanism should be unambiguous about whether a load indication applies to a specific IP address, host, or URI so that an upstream element can determine the load of the entity to which a request is to be sent.
REQ 18：重载机制应明确负载指示是否适用于特定IP地址、主机或URI，以便上游元素可以确定将向其发送请求的实体的负载。
Meets REQ 18: Yes. Please see discussion in Section 5.5.
符合要求18：是。请参见第5.5节中的讨论。
REQ 19: The specification for the overload mechanism should give guidance on which message types might be desirable to process over others during times of overload, based on SIP-specific considerations. For example, it may be more beneficial to process a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh with a non-zero expiration (since the former reduces the overall amount of load on the element) or to process re-INVITEs over new INVITEs.
REQ 19：过载机制的规范应根据SIP的具体考虑，给出过载期间哪些消息类型可能需要优先于其他类型处理的指导。例如，处理到期时间为零的订阅刷新可能比处理到期时间为非零的订阅刷新更有利（因为前者减少了元素上的总负载量），或者处理新邀请上的重新邀请。
Meets REQ 19: Yes. Please see Section 5.10.
符合要求19：是。请参见第5.10节。
REQ 20: In a mixed environment of elements that do and do not implement the overload mechanism, no disproportionate benefit shall accrue to the users or operators of the elements that do not implement the mechanism.
REQ 20：在实施和未实施过载机制的元件的混合环境中，未实施过载机制的元件的用户或操作员不得获得不相称的利益。
Meets REQ 20: Yes. An element that does not implement overload control does not receive any measure of extra benefit.
符合要求20：是。未实现过载控制的元素不会获得任何额外的好处。
REQ 21: The overload mechanism should ensure that the system remains stable. When the offered load drops from above the overall capacity of the network to below the overall capacity, the throughput should stabilize and become equal to the offered load.
REQ 21：过载机制应确保系统保持稳定。当提供的负载从网络的总容量以上下降到总容量以下时，吞吐量应稳定并与提供的负载相等。
Meets REQ 21: Yes. The overload control mechanism described in this document ensures the stability of the system.
符合要求21：是。本文件中描述的过载控制机制确保了系统的稳定性。
REQ 22: It must be possible to disable the reporting of load information towards upstream targets based on the identity of those targets. This allows a domain administrator who considers the load of their elements to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the overload mechanism itself will help prevent overload from that upstream target.
REQ 22：必须能够根据上游目标的标识禁用向这些目标报告负载信息。这允许将其元素的负载视为敏感信息的域管理员限制对该信息的访问。当然，在这种情况下，我们并不期望过载机制本身能够帮助防止来自上游目标的过载。
Meets REQ 22: Yes. An operator of a SIP server can configure the SIP server to only report overload control information for requests received over a confidential channel, for example. However, note that this requirement is in conflict with REQ 3 as it introduces a modicum of extra configuration.
满足要求22：是。例如，SIP服务器的操作员可以将SIP服务器配置为仅报告通过机密信道接收的请求的过载控制信息。但是，请注意，此要求与REQ 3冲突，因为它引入了少量额外配置。
REQ 23: It must be possible for the overload mechanism to work in cases where there is a load balancer in front of a farm of proxies.
REQ 23：在代理服务器群前面有负载平衡器的情况下，过载机制必须能够工作。
Meets REQ 23: Yes. Depending on the type of load balancer, this requirement is met. A load balancer fronting a farm of SIP proxies could be a SIP-aware load balancer or one that is not SIP-aware. If the load balancer is SIP-aware, it can make conscious decisions on throttling outgoing traffic towards the individual server in the farm based on the overload control parameters returned by the server. On the other hand, if the load balancer is not SIP-aware, then there are other strategies to perform overload control. Section 6 of [RFC6357] documents some of these strategies in more detail (see discussion related to Figure 3(a) of that document).
符合要求23：是。根据负载平衡器的类型，满足此要求。前置SIP代理服务器群的负载平衡器可以是SIP感知的负载平衡器，也可以是不感知SIP的负载平衡器。如果负载平衡器是SIP感知的，它可以根据服务器返回的过载控制参数，有意识地决定是否限制流向服务器场中单个服务器的传出流量。另一方面，如果负载平衡器不知道SIP，那么还有其他策略来执行过载控制。[RFC6357]第6节更详细地记录了其中一些策略（参见与该文件图3（a）相关的讨论）。
Authors' Addresses
作者地址
Vijay K. Gurbani (editor) Bell Labs, Alcatel-Lucent 1960 Lucent Lane, Rm 9C-533 Naperville, IL 60563 USA
Vijay K.Gurbani（编辑）贝尔实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编：60563
EMail: vkg@bell-labs.com
EMail: vkg@bell-labs.com
Volker Hilt Bell Labs, Alcatel-Lucent Lorenzstrasse 10 70435 Stuttgart Germany
沃尔克希尔特贝尔实验室，阿尔卡特朗讯洛伦茨特拉斯10 70435德国斯图加特
EMail: volker.hilt@bell-labs.com
EMail: volker.hilt@bell-labs.com
Henning Schulzrinne Columbia University/Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
Henning Schulzrinne哥伦比亚大学/计算机科学系美国纽约州纽约市计算机科学大楼450号，邮编10027
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu