[要約] RFC 7339は、SIPオーバーロード制御に関するガイドラインであり、SIPネットワークの過負荷を制御するための方法を提供します。このRFCの目的は、SIPネットワークのパフォーマンスを向上させ、過負荷によるサービスの低下や障害を防ぐことです。
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（Service Unavailable）応答コードを通じて制限された過負荷制御メカニズムを提供しますが、SIPサーバーは依然として過負荷に対して脆弱です。このドキュメントでは、過負荷制御に関連するSIPサーバーの動作を定義し、SIPの損失ベースの過負荷スキームも指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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サーバーの過負荷に関係のない障害状態のためにそれらを拒否しなければならない場合もあります。たとえば、トランクが不足してもSIPメッセージを処理する十分な容量がある公衆交換電話網（PSTN）ゲートウェイは、488（Not Acceptable Here）応答[RFC4412]を使用して着信INVITEを拒否する必要があります。同様に、登録データベースへの接続が失われたものの、SIP要求を処理できるSIPレジストラは、500（サーバーエラー）応答でREGISTER要求を拒否する必要があります[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（Service Unavailable）応答コードを介して過負荷制御のための制限されたメカニズムを提供します。ただし、このメカニズムではSIPサーバーの過負荷を防止できず、輻輳の崩壊を防止できません。実際、503（Service Unavailable）応答コードを使用すると、トラフィックが発振してSIPサーバー間でシフトし、過負荷状態が悪化する可能性があります。 SIP過負荷の問題、503（Service Unavailable）応答コードの問題、および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 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.
このドキュメントでは、SIPサーバーとクライアントの間で過負荷情報を通信するためのプロトコルを定義しているため、クライアントは過負荷サーバーに送信されるトラフィックの量を削減し、輻輳の崩壊を回避して有用なスループットを向上できます。セクション4では、この通信に使用されるViaヘッダーパラメーターについて説明します。過負荷制御に関連するSIPサーバーおよびクライアントの一般的な動作については、セクション5で説明します。さらに、セクション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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
過負荷制御はホップバイホップで実行されるため、2つの隣接するSIPエンティティが過負荷制御のサポートを示し、それに関連する情報を交換できるため、Viaヘッダーパラメーターは魅力的です[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ヘッダーの4つの新しいパラメーターを定義します。これらのパラメータは、隣接するSIPエンティティ間で過負荷制御情報を伝達するメカニズムを提供します。 「oc」パラメーターは、サーバーに到着する要求の数の減少を示すためにSIPサーバーによって使用されます。 「oc-algo」パラメーターには、クライアントがサポートする過負荷制御アルゴリズムのクラスに対応するトークンまたはトークンのリストが含まれています。サーバーはこのリストから1つのアルゴリズムを選択します。 「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.
4つのViaヘッダーパラメータを以下に紹介します。さまざまな条件下でこれらを解釈する方法の詳細については、セクション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リクエストに挿入する最上位のViaヘッダーに「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 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.
ダウンストリームサーバーは、要求に「oc」パラメーターを含めたクライアントへの上流に向かう応答の「oc」パラメーターに値を追加する必要があります。パラメータに値を含めることは、2つのことを表しています。まず、最初の連絡（セクション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.
このパラメーターには、過負荷制御アルゴリズムの1つ以上のクラスの名前が含まれています。 SIPクライアントは、損失ベースの過負荷制御方式をサポートする必要があり、「oc-algo」パラメーター値の1つとして少なくともトークン「損失」を挿入する必要があります。さらに、SIPクライアントは、レートベースのスキーム[RATE-CONTROL]などの他の過負荷制御スキームをサポートしている場合、「oc-algo」パラメーターにカンマで区切られた他のトークンを挿入してもよい（MAY）。コンマ区切りのリストの各要素は、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」パラメーターで指定された複数の過負荷制御アルゴリズム（オプションで優先順位の降順で並べ替え）を含む要求を受信すると、リストから1つのアルゴリズムを選択し、選択した単一のアルゴリズムをクライアントに返す必要があります。
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-validity」パラメーターがない場合、SIPクライアントは「oc-validity = 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」パラメーターと組み合わせてのみ存在する必要があります。対応する「oc」パラメーターも存在しないクライアントが応答で受信した場合、SIPクライアントは「oc-validity」パラメーターのゼロ以外の値を破棄する必要があります。
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」パラメーターに関連付けられたシーケンス番号を示す符号なし整数値が含まれています。このシーケンス番号は、2つの異なる瞬間に過負荷制御アルゴリズムによって生成された2つの「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）にクエリを実行して、ポート番号を持つ1つ以上の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-validity」期間がまだ満了していない場合）、クライアントは関連するアルゴリズムを適用して、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」パラメーターを挿入しなければなりません（MUST）。このリストには「損失」を含める必要があり、IANAによって承認され、対応するドキュメントで説明されている他のアルゴリズム名を含めることができます（MAY）。クライアントは、選択したサーバーに要求を送信します。
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リクエストを受信した場合、サーバーは、このクライアントで過負荷制御アルゴリズムクラスをすでに選択しているかどうかを判断する必要があります。もしそうなら、サーバーはメッセージへの応答で以前に選択されたアルゴリズムクラスを使用すべきです（SHOULD）。サーバーがメッセージが新しいクライアントからのものであるか、サーバーが長い間聞いていないクライアントであると判断した場合、サーバーは「oc-algo」パラメーターのアルゴリズムのリストから1つのアルゴリズムを選択する必要があります。選択したアルゴリズムを、クライアントに送信する応答の「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-CONTROL]をサポートするクライアントは、「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 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.
応答の最上位のViaヘッダーは処理後にアップストリームクライアントによって削除されるため、「oc」パラメーターに含まれる過負荷制御フィードバックは、アップストリーム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 Trying応答での過負荷制御パラメータの転送に関する特別な考慮事項については、セクション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」パラメーターも追加する必要があります（SHOULD）。 「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」パラメーター値を使用する必要があります（SHOULD）。これは、「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 neighbors change), there are also responses flowing in both directions. Thus, both SIP servers can exchange overload information.
"oc-validity"および "oc-seq" Viaヘッダーパラメータは、SIP応答でのみ定義され、SIP要求で使用してはなりません（MUST NOT）。クライアントは新しいリクエストをリダイレクトまたは拒否することでトラフィックをオフロードできるエンティティであるため、これらのパラメータはSIPサーバーの上流のネイバー（つまり、SIPサーバーにリクエストを送信しているエンティティ）にのみ役立ちます。リクエストが2つのSIPサーバー間で双方向に転送される場合（つまり、上流/下流のネイバーの役割が変わる場合）、両方向に流れる応答もあります。したがって、両方の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」パラメーターの値は、任意の関連情報を使用して過負荷のサーバーによって決定されます。このドキュメントによって課される唯一の制約は、サーバー制御アルゴリズムが、受信SIPクライアントがこのSIPへのすべてのダウンストリームSIPリクエスト（ダイアログ形成およびダイアログ内）に適用することを期待する「oc」パラメーターの値を生成する必要があることです。サーバ。この規定を超えて、過負荷のサーバーが「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％がクライアントで削減されることを意味します。同様に、レートベースのアルゴリズム[RATE-CONTROL]を使用する場合の「oc = 10」の値は、クライアントがSIPリクエストを1秒あたり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ヘッダーを除いて、受信した応答のすべてのViaヘッダーから「oc」、「oc-validity」、および「oc-seq」パラメーターを削除する必要があります（SHOULD）。これにより、ダウンストリーム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クライアントは、特定のダウンストリームサーバーからの現在の「oc」および「oc-algo」パラメーター値で許可されているよりも多くの要求をSIPサーバーに転送してはなりません（MUST NOT）。
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にクエリして、それぞれに対応するポート番号とトランスポートを持つ1つ以上の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リクエストを送信する必要があります（SHOULD）。 （デフォルトの損失ベースの過負荷制御アルゴリズムについては、セクション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プロキシは、要求をさらにダウンストリームにプロキシする前に、クライアントによって挿入された過負荷制御パラメータを取り除く必要があります（SHOULD）。もちろん、プロキシがクライアントとして機能し、ダウンストリームのリクエストをプロキシする場合、リクエストに挿入された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-validity」期間（または、サーバーが「oc-validity」パラメーターを以前に指定していなかった場合のデフォルト値の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に設定する必要があります（SHOULD）。
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に設定することにより、過負荷制御を効果的に停止できることに注意してください。ただし、レートベースのスキーム[RATE-CONTROL]には、 「oc-validity = 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 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-seq」番号が大きい応答を受信すると、「oc-validity」パラメーターを確認します。 「oc-validity」パラメーターの値が0の場合、これは、サーバー宛てのメッセージの過負荷制御が不要になり、トラフィックを削減せずに流せることをクライアントに示します。さらに、「oc-validity」パラメーターの値が0の場合、クライアントは「oc」パラメーターの値を無視する必要があります（SHOULD）。
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時間）変更すべきではありません（SHOULD NOT）。この期間には、サーバーでのトラフィックとリソースに応じて、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.
注：これを実現する1つの方法は、クライアントのネットワーク識別子によってインデックスが付けられたルックアップテーブルで、最後のアルゴリズム変更の時間をサーバーが保存することです。サーバーは、最後の変更からの時間が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（Request Timeout）ステータスコードを受け取ったかのように処理する必要があります。トランスポート層によって致命的なトランスポートエラーが報告された場合、...状態は503（Service Unavailable）ステータスコードとして扱われる必要があります。
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 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クライアントは、ダウンストリームサーバーが使用可能なメカニズムを使用して生きているかどうかを定期的にプローブする必要があります（SHOULD）。クライアントは、その活性プローブが過負荷状態を悪化させないように、（たとえば、指数バックオフを使用して）調査において保守的である必要があります。 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.
ただし、この宛先が過負荷ではなく、追加の負荷を処理できることを確認する必要があります。クライアントは、過負荷状態が迅速に解決され、要求が時間内に転送されることを期待して、要求をバッファリングすることもできます。ただし、多くの場合、Retry-Afterヘッダーのない「503（Service Unavailable）」応答でこれらの要求を拒否する必要があります。
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クライアントはローカルポリシーに従うことが期待されます。したがって、次の3つの段落の規範的な動作は、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クライアントは、INVITEと既存のセッションに関連付けられたリクエストなど、メッセージタイプに基づくポリシーなどのSIPリクエストに優先順位を付けるために、ローカルポリシーを尊重する必要があります（SHOULD）。
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クライアントは、Resource-Priorityヘッダー（RPH）[RFC4412]の内容に基づいてSIPリクエストに優先順位を付けるためのローカルポリシーを尊重する必要があります（SHOULD）。特定の（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 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.
SIPクライアントは、緊急要求を示すSOS URN [RFC5031]によって識別されるように、緊急呼び出しに関連するSIP要求を優先するためのローカルポリシーを尊重する必要があります（SHOULD）。このポリシーにより、サーバーが過負荷になり、非緊急通話がクライアントに到着するトラフィックの緊急通話よりも多い場合、少数の緊急通話が優先されます。一方、サーバーが過負荷であり、クライアントに到着するコールの大部分が本質的に緊急である場合、クライアントがトラフィックの量を削減する必要がある場合、メッセージの優先順位付けは、すべての緊急コールの配信を保証しません。サーバーによって要求されました。
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サーバーは、Retry-Afterヘッダーのない503（Service Unavailable）応答で、参加していないクライアントからの要求を拒否する必要があります。
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 Trying応答で転送される過負荷制御情報には特別な注意が必要です。
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 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 Trying応答は、再送信を抑制するためにSIPで使用されていました。一部の実装では、100 Tryingメッセージはトランザクションユーザー（TU）によって生成されず、TUによって消費されない場合があります。これらの実装では、100 Trying応答がトランザクション層で生成され、上流のSIPクライアントに送信されます。受信側のSIPクライアントでは、対応する要求の再送信を禁止することにより、トランザクション層で100 Tryingが消費されます。したがって、100 Tryingに過負荷制御情報を挿入する実装では、上流のSIPクライアントが100 Tryingの過負荷制御情報を対応する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サーバーP2に要求を送信しているSIPクライアントP1について考えます。次の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" ...
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/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はオーバーロード制御をサポートしているため、作成した最上位のViaヘッダーに「oc」パラメーターを挿入します。 P1は、「損失」と「A」と呼ばれるアルゴリズムの2つの過負荷制御アルゴリズムをサポートしています。
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.
2行目（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に過負荷が発生し始めます。 P1がP2に到着するメッセージを0.5秒間20％減らす必要があることを示す次のSIPメッセージを送信します。
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
...
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.
クライアントは2つのカテゴリーの要求を維持します。最初のカテゴリには削減の候補となるリクエストが含まれ、2番目のカテゴリには、最初のカテゴリのすべてのメッセージが拒否され、さらに削減が必要な場合を除いて、削減の対象にならないリクエストが含まれます。セクション5.10.1には、2番目のカテゴリに含めるメッセージを識別するためのディレクティブが含まれています。残りのメッセージは最初のカテゴリに割り当てられます。
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 = 110」でリクエストの40％を最初のカテゴリに含める必要がある場合は、次のようになります。
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％削減できます。クライアントはランダム破棄を使用して、最初のカテゴリのメッセージを25％削減します。 2番目のカテゴリのメッセージは無傷でダウンストリームに進みます。最初のカテゴリから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.
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
switch (sip_msg.type) {
スイッチ（sip_msg.type）{
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 (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)
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 (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 case // outbound request
end case //アウトバウンドリクエスト
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.
} process_msg(sip_msg)
} process_msg（sip_msg）
end case // inbound response case inbound request:
end case //インバウンドレスポンスケースインバウンドリクエスト：
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 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.
このドキュメントで説明されている過負荷制御メカニズムは本質的に事後対応型であり、セクション5.10.1にリストされているメッセージ優先順位付けディレクティブとは別に、このドキュメントで説明されているメカニズムは、ユーザーID、フィルタリングアクション、および到着時間に基づいてリクエストを区別しません。 [RFC7200]で説明されているように、プロアクティブな過負荷制御メカニズムを必要とするSIPネットワークは、ユーザーレベルの負荷制御フィルターをアップロードできます。ローカルポリシーは、トラフィックに適用されるさまざまな過負荷制御メカニズムの優先順位も決定します。具体的には、負荷制御フィルターがシグナリングネイバー[RFC7200]によってインストールされ、同じトラフィックが過負荷制御メカニズムを使用して抑制できるシナリオでは、ローカルポリシーにより、これらのスキームのどちらを優先するかが決定されます。 2つのスキーム間の相互作用は、このドキュメントの範囲外です。
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
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ヘッダーフィールドパラメータを使用して送信できます。 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メッセージを送信する必要があります。これには、アクティブおよび非アクティブなネイバーが含まれます。これらの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エンティティがそれをサポートする必要がないという利点があります。両方のサーバーが過負荷制御をサポートし、他のサーバーまたはユーザーエージェントからのサポートに依存しない場合、2つの隣接する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 \
: ------- ------ :
-----> 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 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.
攻撃者がリンクL1のPaとP1間のトラフィックを変更できる場合、PaがP1にトラフィックを送信しないようにすることで、P1にサービス拒否攻撃を引き起こすことができます。このような攻撃は、攻撃者がP1からPaへの応答を変更することで進行し、PaのViaヘッダーが変更されて、P1宛てのすべての要求がドロップされることを示します。逆に、攻撃者はPaへの応答でP1によって追加された「oc」、「oc-validity」、および「oc-seq」マーキングを単に削除できます。このような場合、攻撃者は要求の抑制を拒否することにより、P1を強制的に過負荷にします。 Paは過負荷制御を実行できますが、Paでは
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間のトラフィックを変更できる場合、P1からP1への応答でP1に関連付けられたViaヘッダーを変更して、P1からPb宛ての後続のすべての要求がドロップされるようにすることができます。本質的に、攻撃者は偽の過負荷制御を示すことにより、Pbにサービス拒否攻撃を仕掛けます。 Pbが過負荷制御をサポートするかどうかは重要ではないことに注意してください。攻撃者がL2を制御できる限り、攻撃は成功します。逆に、攻撃者は、P1への応答でPbによって追加された「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.
攻撃を実行する別の方法は、この拡張をサポートしないプロキシを介して、高いオーバーロードフィードバック値を含むメッセージを送信することです。このフィードバックが2番目の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-validity」間隔が長く、攻撃者がこの間隔を推測できる場合、攻撃者は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」サブレジストリで詳述されるように、4つの新しい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]
[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：Session Initiation Protocol」 、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、「Session Initiation Protocol（SIP）：Locating SIP Servers」、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）のインターネット割り当て番号機関（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、「Communications Resource Priority for the Session Initiation Protocol（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.
[RATE-CONTROL]ノエル、E.、P。ウィリアムズ、「Session Initiation Protocol（SIP）Rate Control」、Work in Progress、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]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：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。、「緊急およびその他の既知のサービスのためのUniform Resource Name（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。、「Session Initiation Protocolにおける過負荷の管理の要件」、RFC 5390、2008年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、「Session Initiation Protocol（SIP）Overload Controlに関する設計上の考慮事項」、RFC 6357、2011年8月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、2011年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、「A Session Initiation Protocol（SIP）Load-Control Event Package」、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_value> cat1」の場合の処理を単純化する変更を提案しました。
Richard Barnes provided invaluable comments as a part of the Area Director review of the document.
リチャードバーンズは、ドキュメントのエリアディレクターレビューの一部として、非常に貴重なコメントを提供しました。
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 |
+-------------+-------------------+
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.
REQ 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.
REQ 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.
REQ 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.
REQ 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.
REQ 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.
REQ 5に対応：部分的に。過負荷制御情報は1組の通信エンティティ間で共有されるため、この通信には機密で認証されたチャネルを使用できます。ただし、そのようなチャネルが利用できない場合は、セクション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.
REQ 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.
REQ 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.
REQ 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.
REQ 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.
REQ 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.
REQ 11に適合：はい。アップストリームクライアントの数に制限はありません。
REQ 12: The mechanism should work between servers in different domains.
REQ 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.
REQ 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：メカニズムは、過負荷時のプロキシ内の処理の優先順位付けのために特定のアルゴリズムを指示してはなりません。これは、プロキシがローカルポリシーに基づいてリクエストに優先順位を付けることを許可する必要があります。これにより、特定のリクエスト（緊急サービスの呼び出しや、Resource-Priorityヘッダーフィールド[RFC4412]の特定の値を持つ呼び出しなど）が優先的に処理されます。ドロップされない、追加の再送信が与えられる、または他より先に処理される。
Meets REQ 13: Yes. Please see Section 5.10.
REQ 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.
REQ 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.
REQ 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.
REQ 16に適合：はい。過負荷制御メッセージは最上位のViaヘッダーで送信され、常にSIPエレメントによって処理されます。
REQ 17: The overload mechanism must not provide an avenue for malicious attack, including DoS and DDoS attacks.
REQ 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.
REQ 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.
REQ 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固有の考慮事項に基づいて、過負荷時に他のメッセージタイプよりも処理が望ましいメッセージタイプに関するガイダンスを提供する必要があります。たとえば、有効期限がゼロのSUBSCRIBEリフレッシュよりも有効期限がゼロのSUBSCRIBEリフレッシュを処理する方が（前者が要素への全体的な負荷量を減らすため）、新しいINVITEを介してre-INVITEを処理する方が有利な場合があります。 。
Meets REQ 19: Yes. Please see Section 5.10.
REQ 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.
REQ 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.
REQ 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：それらのターゲットのIDに基づいて、上流ターゲットへの負荷情報のレポートを無効にすることが可能でなければなりません。これにより、要素の負荷を機密情報と見なすドメイン管理者は、その情報へのアクセスを制限できます。もちろん、そのような場合、オーバーロードメカニズム自体がその上流ターゲットからのオーバーロードを防止するのに役立つとは期待されていません。
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.
REQ 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).
REQ 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（編集者）Bell Labs、アルカテルルーセント1960ルーセントレーン、RM 9C-533ネーパーヴィル、IL 60563米国
EMail: vkg@bell-labs.com
Volker Hilt Bell Labs, Alcatel-Lucent Lorenzstrasse 10 70435 Stuttgart Germany
Volker Hilt Bell Labs、アルカテルルーセントLorenzstrasse 10 70435シュトゥットガルトドイツ
EMail: volker.hilt@bell-labs.com
Henning Schulzrinne Columbia University/Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルズリンネコロンビア大学/コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027アメリカ
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu