[要約] RFC 8445は、ネットワークアドレストランスレータ（NAT）トラバーサルのためのプロトコルであるICEについての要約です。このRFCの目的は、NATを介した通信の問題を解決し、インタラクティブな接続性を確立することです。
Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 8445 C. Holmberg
Obsoletes: 5245 Ericsson
Category: Standards Track J. Rosenberg
ISSN: 2070-1721 jdrosen.net
July 2018
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
インタラクティブ接続確立（ICE）：ネットワークアドレス変換（NAT）トラバーサルのプロトコル
Abstract
概要
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
このドキュメントでは、UDPベースの通信用のネットワークアドレス変換（NAT）トラバーサルのプロトコルについて説明します。このプロトコルはInteractive Connectivity Establishment（ICE）と呼ばれます。 ICEは、NAT用セッショントラバーサルユーティリティ（STUN）プロトコルとその拡張であるリレーNATを使用したトラバーサル（TURN）を利用します。
This document obsoletes RFC 5245.
このドキュメントはRFC 5245を廃止します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8445.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8445で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Gathering Candidates . . . . . . . . . . . . . . . . . . 8
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 10
2.3. Nominating Candidate Pairs and Concluding ICE . . . . . . 12
2.4. ICE Restart . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Lite Implementations . . . . . . . . . . . . . . . . . . 13
3. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. ICE Candidate Gathering and Exchange . . . . . . . . . . . . 17
5.1. Full Implementation . . . . . . . . . . . . . . . . . . . 17
5.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 18
5.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 18
5.1.1.2. Server-Reflexive and Relayed Candidates . . . . . 20
5.1.1.3. Computing Foundations . . . . . . . . . . . . . . 21
5.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 21
5.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
5.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22
5.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23
5.1.3. Eliminating Redundant Candidates . . . . . . . . . . 23
5.2. Lite Implementation Procedures . . . . . . . . . . . . . 23
5.3. Exchanging Candidate Information . . . . . . . . . . . . 24
5.4. ICE Mismatch . . . . . . . . . . . . . . . . . . . . . . 26
6. ICE Candidate Processing . . . . . . . . . . . . . . . . . . 26
6.1. Procedures for Full Implementation . . . . . . . . . . . 26
6.1.1. Determining Role . . . . . . . . . . . . . . . . . . 26
6.1.2. Forming the Checklists . . . . . . . . . . . . . . . 28
6.1.2.1. Checklist State . . . . . . . . . . . . . . . . . 28
6.1.2.2. Forming Candidate Pairs . . . . . . . . . . . . . 28
6.1.2.3. Computing Pair Priority and Ordering Pairs . . . 31
6.1.2.4. Pruning the Pairs . . . . . . . . . . . . . . . . 31
6.1.2.5. Removing Lower-Priority Pairs . . . . . . . . . . 31
6.1.2.6. Computing Candidate Pair States . . . . . . . . . 32
6.1.3. ICE State . . . . . . . . . . . . . . . . . . . . . . 36
6.1.4. Scheduling Checks . . . . . . . . . . . . . . . . . . 36
6.1.4.1. Triggered-Check Queue . . . . . . . . . . . . . . 36
6.1.4.2. Performing Connectivity Checks . . . . . . . . . 36
6.2. Lite Implementation Procedures . . . . . . . . . . . . . 38
7. Performing Connectivity Checks . . . . . . . . . . . . . . . 38
7.1. STUN Extensions . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 38
7.1.2. USE-CANDIDATE . . . . . . . . . . . . . . . . . . . . 38
7.1.3. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . . . 39
7.2. STUN Client Procedures . . . . . . . . . . . . . . . . . 39
7.2.1. Creating Permissions for Relayed Candidates . . . . . 39
7.2.2. Forming Credentials . . . . . . . . . . . . . . . . . 39
7.2.3. Diffserv Treatment . . . . . . . . . . . . . . . . . 40
7.2.4. Sending the Request . . . . . . . . . . . . . . . . . 40
7.2.5. Processing the Response . . . . . . . . . . . . . . . 40
7.2.5.1. Role Conflict . . . . . . . . . . . . . . . . . . 40
7.2.5.2. Failure . . . . . . . . . . . . . . . . . . . . . 41
7.2.5.2.1. Non-Symmetric Transport Addresses . . . . . . 41
7.2.5.2.2. ICMP Error . . . . . . . . . . . . . . . . . 41
7.2.5.2.3. Timeout . . . . . . . . . . . . . . . . . . . 41
7.2.5.2.4. Unrecoverable STUN Response . . . . . . . . . 41
7.2.5.3. Success . . . . . . . . . . . . . . . . . . . . . 42
7.2.5.3.1. Discovering Peer-Reflexive Candidates . . . . 42
7.2.5.3.2. Constructing a Valid Pair . . . . . . . . . . 43
7.2.5.3.3. Updating Candidate Pair States . . . . . . . 44
7.2.5.3.4. Updating the Nominated Flag . . . . . . . . . 44
7.2.5.4. Checklist State Updates . . . . . . . . . . . . . 44
7.3. STUN Server Procedures . . . . . . . . . . . . . . . . . 45
7.3.1. Additional Procedures for Full Implementations . . . 45
7.3.1.1. Detecting and Repairing Role Conflicts . . . . . 46
7.3.1.2. Computing Mapped Addresses . . . . . . . . . . . 47
7.3.1.3. Learning Peer-Reflexive Candidates . . . . . . . 47
7.3.1.4. Triggered Checks . . . . . . . . . . . . . . . . 47
7.3.1.5. Updating the Nominated Flag . . . . . . . . . . . 49
7.3.2. Additional Procedures for Lite Implementations . . . 49
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50
8.1. Procedures for Full Implementations . . . . . . . . . . . 50
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50
8.1.2. Updating Checklist and ICE States . . . . . . . . . . 51
8.2. Procedures for Lite Implementations . . . . . . . . . . . 52
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 53
8.3.1. Full Implementation Procedures . . . . . . . . . . . 53
8.3.2. Lite Implementation Procedures . . . . . . . . . . . 53
9. ICE Restarts . . . . . . . . . . . . . . . . . . . . . . . . 53
10. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . . 54
11. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 54
12. Data Handling . . . . . . . . . . . . . . . . . . . . . . . . 55
12.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . 55
12.1.1. Procedures for Lite Implementations . . . . . . . . 56
12.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . 56
13. Extensibility Considerations . . . . . . . . . . . . . . . . 57
14. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 57
14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 57
14.2. Ta . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
14.3. RTO . . . . . . . . . . . . . . . . . . . . . . . . . . 58
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 59
15.1. Example with IPv4 Addresses . . . . . . . . . . . . . . 60
15.2. Example with IPv6 Addresses . . . . . . . . . . . . . . 65
16. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 69
16.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 69
16.2. New Error-Response Codes . . . . . . . . . . . . . . . . 70
17. Operational Considerations . . . . . . . . . . . . . . . . . 70
17.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 70
17.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 70
17.2.1. STUN and TURN Server-Capacity Planning . . . . . . . 71
17.2.2. Gathering and Connectivity Checks . . . . . . . . . 71
17.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 72
17.3. ICE and ICE-Lite . . . . . . . . . . . . . . . . . . . . 72
17.4. Troubleshooting and Performance Management . . . . . . . 72
17.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 73
18. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73
18.1. Problem Definition . . . . . . . . . . . . . . . . . . . 73
18.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 74
18.3. Brittleness Introduced by ICE . . . . . . . . . . . . . 74
18.4. Requirements for a Long-Term Solution . . . . . . . . . 75
18.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 75
19. Security Considerations . . . . . . . . . . . . . . . . . . . 76
19.1. IP Address Privacy . . . . . . . . . . . . . . . . . . . 76
19.2. Attacks on Connectivity Checks . . . . . . . . . . . . . 77
19.3. Attacks on Server-Reflexive Address Gathering . . . . . 80
19.4. Attacks on Relayed Candidate Gathering . . . . . . . . . 80
19.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . 81
19.5.1. STUN Amplification Attack . . . . . . . . . . . . . 81
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
20.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 82
20.2. STUN Error Responses . . . . . . . . . . . . . . . . . . 82
20.3. ICE Options . . . . . . . . . . . . . . . . . . . . . . 82
21. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 83
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
22.1. Normative References . . . . . . . . . . . . . . . . . . 84
22.2. Informative References . . . . . . . . . . . . . . . . . 85
Appendix A. Lite and Full Implementations . . . . . . . . . . . 89
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 90
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 90
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 92
B.3. Purpose of the Related-Address and Related-Port
Attributes . . . . . . . . . . . . . . . . . . . . . . . 94
B.4. Importance of the STUN Username . . . . . . . . . . . . . 95
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 96
B.6. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 96
B.7. Why Prefer Peer-Reflexive Candidates? . . . . . . . . . . 97
B.8. Why Are Binding Indications Used for Keepalives? . . . . 97
B.9. Selecting Candidate Type Preference . . . . . . . . . . . 97
Appendix C. Connectivity-Check Bandwidth . . . . . . . . . . . . 99
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
Protocols establishing communication sessions between peers typically involve exchanging IP addresses and ports for the data sources and sinks. However, this poses challenges when operated through Network Address Translators (NATs) [RFC3235]. These protocols also seek to create a data flow directly between participants, so that there is no application-layer intermediary between them. This is done to reduce data latency, decrease packet loss, and reduce the operational costs of deploying the application. However, this is difficult to accomplish through NATs. A full treatment of the reasons for this is beyond the scope of this specification.
ピア間の通信セッションを確立するプロトコルには、通常、データソースとシンクのIPアドレスとポートの交換が含まれます。ただし、ネットワークアドレストランスレータ（NAT）[RFC3235]を介して操作すると、これが課題となります。これらのプロトコルは、参加者間に直接データフローを作成しようとするため、参加者間にアプリケーション層の仲介がありません。これは、データ遅延を減らし、パケット損失を減らし、アプリケーションの展開にかかる運用コストを削減するために行われます。ただし、これはNATを通じて達成するのは困難です。この理由の完全な扱いは、この仕様の範囲を超えています。
Numerous solutions have been defined for allowing these protocols to operate through NATs. These include Application Layer Gateways (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple Traversal of UDP Through NAT (STUN) specification [RFC3489] (note that RFC 3489 has been obsoleted by RFC 5389), and Realm Specific IP [RFC3102] [RFC3103] along with session description extensions needed to make them work, such as the Session Description Protocol (SDP) attribute [RFC4566] for the Real-Time Control Protocol (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and cons that make each one optimal in some network topologies, but a poor choice in others. The result is that administrators and implementers are making assumptions about the topologies of the networks in which their solutions will be deployed. This introduces complexity and brittleness into the system.
これらのプロトコルがNATを介して動作できるようにするために、多数のソリューションが定義されています。これらには、アプリケーションレイヤーゲートウェイ（ALG）、ミドルボックス制御プロトコル[RFC3303]、元のUDPのシンプルトラバーサル（STUN）仕様[RFC3489]（RFC 3489はRFC 5389で廃止されていることに注意）、および領域固有のIP [ RFC3102] [RFC3103]と、それらを機能させるために必要なセッション記述拡張（Real-Time Control Protocol（RTCP）[RFC3605]のSession Description Protocol（SDP）属性[RFC4566]など）。残念ながら、これらの手法にはすべて、いくつかのネットワークトポロジではそれぞれが最適になる長所と短所がありますが、他の方法では不十分な選択です。その結果、管理者と実装者は、ソリューションが展開されるネットワークのトポロジについて想定を行っています。これはシステムに複雑さともろさをもたらします。
This specification defines Interactive Connectivity Establishment (ICE) as a technique for NAT traversal for UDP-based data streams (though ICE has been extended to handle other transport protocols, such as TCP [RFC6544]). ICE works by exchanging a multiplicity of IP addresses and ports, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports are exchanged using ICE-usage-specific mechanisms (e.g., in an Offer/ Answer exchange), and the connectivity checks are performed using STUN [RFC5389]. ICE also makes use of Traversal Using Relay around NAT (TURN) [RFC5766], an extension to STUN. Because ICE exchanges a multiplicity of IP addresses and ports for each media stream, it also allows for address selection for multihomed and dual-stack hosts. For this reason, RFC 5245 [RFC5245] deprecated the solutions previously defined in RFC 4091 [RFC4091] and RFC 4092 [RFC4092].
この仕様では、UDPベースのデータストリームのNATトラバーサルの手法としてInteractive Connectivity Establishment（ICE）を定義しています（ただし、ICEはTCP [RFC6544]などの他のトランスポートプロトコルを処理するように拡張されています）。 ICEは、多数のIPアドレスとポートを交換することで機能し、ピアツーピア接続チェックによって接続がテストされます。 IPアドレスとポートは、ICE使用法固有のメカニズムを使用して（たとえば、オファー/アンサー交換で）交換され、接続チェックはSTUN [RFC5389]を使用して実行されます。 ICEは、STUNの拡張であるNAT（TURN）[RFC5766]のリレーを使用したトラバーサルも利用します。 ICEはメディアストリームごとに複数のIPアドレスとポートを交換するため、マルチホームホストとデュアルスタックホストのアドレス選択も可能です。このため、RFC 5245 [RFC5245]は、RFC 4091 [RFC4091]およびRFC 4092 [RFC4092]で以前に定義されたソリューションを廃止しました。
Appendix B provides background information and motivations regarding the design decisions that were made when designing ICE.
付録Bは、ICEの設計時に行われた設計決定に関する背景情報と動機を提供します。
In a typical ICE deployment, there are two endpoints (ICE agents) that want to communicate. Note that ICE is not intended for NAT traversal for the signaling protocol, which is assumed to be provided via another mechanism. ICE assumes that the agents are able to establish a signaling connection between each other.
典型的なICE配備では、通信したい2つのエンドポイント（ICEエージェント）があります。 ICEは、別のメカニズムを介して提供されることが想定されているシグナリングプロトコルのNATトラバーサルを対象としていないことに注意してください。 ICEは、エージェントが互いに信号接続を確立できると想定しています。
Initially, the agents are ignorant of their own topologies. In particular, the agents may or may not be behind NATs (or multiple tiers of NATs). ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can establish a data session.
最初は、エージェントは自身のトポロジを認識していません。特に、エージェントはNAT（または複数層のNAT）の背後にある場合とそうでない場合があります。 ICEを使用すると、エージェントはトポロジに関する十分な情報を検出して、データセッションを確立できる1つ以上のパスを潜在的に見つけることができます。
Figure 1 shows a typical ICE deployment. The agents are labeled L and R. Both L and R are behind their own respective NATs, though they may not be aware of it. The type of NAT and its properties are also unknown. L and R are capable of engaging in a candidate exchange process, whose purpose is to set up a data session between L and R. Typically, this exchange will occur through a signaling server (e.g., a SIP proxy).
図1は、一般的なICE展開を示しています。エージェントにはLとRのラベルが付けられています。LとRの両方は、それぞれのNATの背後にありますが、認識されていない場合があります。 NATのタイプとそのプロパティも不明です。 LとRは候補交換プロセスに従事でき、その目的はLとRの間のデータセッションをセットアップすることです。通常、この交換はシグナリングサーバー（SIPプロキシなど）を介して行われます。
In addition to the agents, a signaling server, and NATs, ICE is typically used in concert with STUN or TURN servers in the network. Each agent can have its own STUN or TURN server, or they can be the same.
エージェント、シグナリングサーバー、NATに加えて、ICEは通常、ネットワーク内のSTUNまたはTURNサーバーと組み合わせて使用されます。各エージェントは、独自のSTUNまたはTURNサーバーを持つことができますが、同じにすることもできます。
+---------+
+--------+ |Signaling| +--------+
| STUN | |Server | | STUN |
| Server | +---------+ | Server |
+--------+ / \ +--------+
/ \
/ \
/ <- Signaling -> \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
+-------+ +-------+
| Agent | | Agent |
| L | | R |
+-------+ +-------+
Figure 1: ICE Deployment Scenario
図1：ICE展開シナリオ
The basic idea behind ICE is as follows: each agent has a variety of candidate transport addresses (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include:
ICEの基本的な考え方は次のとおりです。各エージェントには、他のエージェントとの通信に使用できるさまざまな候補トランスポートアドレス（特定のトランスポートプロトコルのIPアドレスとポートの組み合わせ、この仕様では常にUDPです）があります。これらには以下が含まれます。
o A transport address on a directly attached network interface
o 直接接続されたネットワークインターフェイスのトランスポートアドレス
o A translated transport address on the public side of a NAT (a "server-reflexive" address)
o NATのパブリック側の変換されたトランスポートアドレス（「サーバー再帰」アドレス）
o A transport address allocated from a TURN server (a "relayed address")
o TURNサーバーから割り当てられたトランスポートアドレス（「中継アドレス」）
Potentially, any of L's candidate transport addresses can be used to communicate with any of R's candidate transport addresses. In practice, however, many combinations will not work. For instance, if L and R are both behind NATs, their directly attached interface addresses are unlikely to be able to communicate directly (this is why ICE is needed, after all!). The purpose of ICE is to discover which pairs of addresses will work. The way that ICE does this is to systematically try all possible pairs (in a carefully sorted order) until it finds one or more that work.
潜在的に、Lの候補トランスポートアドレスのいずれかを使用して、Rの候補トランスポートアドレスのいずれかと通信できます。ただし、実際には、多くの組み合わせが機能しません。たとえば、LとRの両方がNATの背後にある場合、直接接続されたインターフェイスアドレスは直接通信できない可能性が高いです（結局、ICEが必要な理由です！）。 ICEの目的は、どのアドレスのペアが機能するかを発見することです。 ICEがこれを行う方法は、1つ以上の機能が見つかるまで、すべての可能なペアを（注意深くソートされた順序で）体系的に試行することです。
In order to execute ICE, an ICE agent identifies and gathers one or more address candidates. A candidate has a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here). There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN.
ICEを実行するために、ICEエージェントは1つ以上のアドレス候補を識別して収集します。候補にはトランスポートアドレスがあります-特定のトランスポートプロトコルのIPアドレスとポートの組み合わせです（ここではUDPのみを指定しています）。候補者にはさまざまな種類があります。物理的または論理的なネットワークインターフェイスから派生するものもあれば、STUNおよびTURNを介して検出できるものもあります。
The first category of candidates are those with a transport address obtained directly from a local interface. Such a candidate is called a "host candidate". The local interface could be Ethernet or Wi-Fi, or it could be one that is obtained through a tunnel mechanism, such as a Virtual Private Network (VPN) or Mobile IP (MIP). In all cases, such a network interface appears to the agent as a local interface from which ports (and thus candidates) can be allocated.
候補の最初のカテゴリは、ローカルインターフェースから直接取得されるトランスポートアドレスを持つものです。このような候補は「ホスト候補」と呼ばれます。ローカルインターフェイスは、イーサネットまたはWi-Fiの場合と、仮想プライベートネットワーク（VPN）やモバイルIP（MIP）などのトンネルメカニズムを介して取得される場合があります。すべての場合において、そのようなネットワークインターフェースは、ポート（および候補）を割り当てることができるローカルインターフェースとしてエージェントに表示されます。
Next, the agent uses STUN or TURN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (server-reflexive candidates) and addresses on TURN servers (relayed candidates). When TURN servers are utilized, both types of candidates are obtained from the TURN server. If only STUN servers are utilized, only server-reflexive candidates are obtained from them. The relationship of these candidates to the host candidate is shown in Figure 2. In this figure, both types of candidates are discovered using TURN. In the figure, the notation X:x means IP address X and UDP port x.
次に、エージェントはSTUNまたはTURNを使用して追加の候補を取得します。これらには2つの種類があります。NATのパブリック側の変換されたアドレス（サーバー再帰候補）とTURNサーバーのアドレス（中継候補）です。 TURNサーバーを使用する場合、両方のタイプの候補がTURNサーバーから取得されます。 STUNサーバーのみが使用されている場合、サーバー再帰候補のみがそれらから取得されます。これらの候補とホスト候補の関係を図2に示します。この図では、TURNを使用して両方のタイプの候補が検出されます。この図では、X：xという表記はIPアドレスXとUDPポートxを意味します。
To Internet
と いんてｒねｔ
|
|
| /------------ Relayed
Y:y | / Address
+--------+
| |
| TURN |
| Server |
| |
+--------+
|
|
| /------------ Server
X1':x1'|/ Reflexive
+------------+ Address
| NAT |
+------------+
|
| /------------ Local
X:x |/ Address
+--------+
| |
| Agent |
| |
+--------+
Figure 2: Candidate Relationships
図2：候補関係
When the agent sends a TURN Allocate request from IP address and port X:x, the NAT (assuming there is one) will create a binding X1':x1', mapping this server-reflexive candidate to the host candidate X:x. Outgoing packets sent from the host candidate will be translated by the NAT to the server-reflexive candidate. Incoming packets sent to the server-reflexive candidate will be translated by the NAT to the host candidate and forwarded to the agent. The host candidate associated with a given server-reflexive candidate is the "base".
エージェントがIPアドレスとポートX：xからTURN Allocateリクエストを送信すると、NAT（存在する場合）はバインディングX1 '：x1'を作成し、このサーバー再帰候補をホスト候補X：xにマッピングします。ホスト候補から送信された発信パケットは、NATによってサーバー再帰候補に変換されます。サーバー再帰候補に送信された着信パケットは、NATによってホスト候補に変換され、エージェントに転送されます。特定のサーバー再帰候補に関連付けられたホスト候補は「ベース」です。
Note: "Base" refers to the address an agent sends from for a particular candidate. Thus, as a degenerate case, host candidates also have a base, but it's the same as the host candidate.
注：「ベース」とは、エージェントが特定の候補者から送信するアドレスを指します。したがって、退化したケースとして、ホスト候補にもベースがありますが、それはホスト候補と同じです。
When there are multiple NATs between the agent and the TURN server, the TURN request will create a binding on each NAT, but only the outermost server-reflexive candidate (the one nearest the TURN server) will be discovered by the agent. If the agent is not behind a NAT, then the base candidate will be the same as the server-reflexive candidate, and the server-reflexive candidate is redundant and will be eliminated.
エージェントとTURNサーバーの間に複数のNATがある場合、TURN要求は各NATにバインディングを作成しますが、エージェントは最も外側のサーバー再帰候補（TURNサーバーに最も近い候補）のみを検出します。エージェントがNATの背後にない場合、基本候補はサーバー再帰候補と同じであり、サーバー再帰候補は冗長であり、削除されます。
The Allocate request then arrives at the TURN server. The TURN server allocates a port y from its local IP address Y, and generates an Allocate response, informing the agent of this relayed candidate. The TURN server also informs the agent of the server-reflexive candidate, X1':x1', by copying the source transport address of the Allocate request into the Allocate response. The TURN server acts as a packet relay, forwarding traffic between L and R. In order to send traffic to L, R sends traffic to the TURN server at Y:y, and the TURN server forwards that to X1':x1', which passes through the NAT where it is mapped to X:x and delivered to L.
次に、割り当て要求がTURNサーバーに到着します。 TURNサーバーは、ローカルIPアドレスYからポートyを割り当て、割り当てられた応答を生成して、エージェントにこの中継された候補を通知します。 TURNサーバーは、Allocate要求のソーストランスポートアドレスをAllocate応答にコピーすることにより、サーバー再帰候補X1 '：x1'もエージェントに通知します。 TURNサーバーはパケットリレーとして機能し、LとRの間でトラフィックを転送します。Lにトラフィックを送信するために、RはトラフィックをY：yのTURNサーバーに送信し、TURNサーバーはそれをX1 '：x1'に転送します。 NATを通過し、X：xにマップされてLに配信されます。
When only STUN servers are utilized, the agent sends a STUN Binding request [RFC5389] to its STUN server. The STUN server will inform the agent of the server-reflexive candidate X1':x1' by copying the source transport address of the Binding request into the Binding response.
STUNサーバーのみが使用される場合、エージェントはSTUNバインディング要求[RFC5389]をそのSTUNサーバーに送信します。 STUNサーバーは、バインディング要求のソーストランスポートアドレスをバインディング応答にコピーすることにより、サーバー再帰候補X1 '：x1'をエージェントに通知します。
Once L has gathered all of its candidates, it orders them by highest-to-lowest priority and sends them to R over the signaling channel. When R receives the candidates from L, it performs the same gathering process and responds with its own list of candidates. At the end of this process, each ICE agent has a complete list of both its candidates and its peer's candidates. It pairs them up, resulting in candidate pairs. To see which pairs work, each agent schedules a series of connectivity checks. Each check is a STUN request/response transaction that the client will perform on a particular candidate pair by sending a STUN request from the local candidate to the remote candidate.
Lはすべての候補を収集すると、優先順位の高いものから順に並べ、シグナリングチャネルを介してRに送信します。 Rは、Lから候補を受け取ると、同じ収集プロセスを実行し、独自の候補リストで応答します。このプロセスの最後に、各ICEエージェントには、候補とそのピアの候補の両方の完全なリストがあります。それらをペアにして、候補ペアを作成します。どのペアが機能するかを確認するために、各エージェントは一連の接続チェックをスケジュールします。各チェックは、クライアントがローカル候補からリモート候補にSTUN要求を送信することにより、特定の候補ペアに対して実行するSTUN要求/応答トランザクションです。
The basic principle of the connectivity checks is simple:
接続性チェックの基本原則は簡単です。
1. Sort the candidate pairs in priority order.
1. 候補ペアを優先順に並べ替えます。
2. Send checks on each candidate pair in priority order.
2. 各候補ペアのチェックを優先順に送信します。
3. Acknowledge checks received from the other agent.
3. 他のエージェントから受信した確認を確認します。
With both agents performing a check on a candidate pair, the result is a 4-way handshake:
両方のエージェントが候補ペアのチェックを実行すると、結果は4ウェイハンドシェイクになります。
L R - - STUN request -> \ L's <- STUN response / check
L R--STUNリクエスト-> \ Lの<-STUNレスポンス/チェック
<- STUN request \ R's
STUN response -> / check
Figure 3: Basic Connectivity Check
図3：基本的な接続チェック
It is important to note that STUN requests are sent to and from the exact same IP addresses and ports that will be used for data (e.g., RTP, RTCP, or other protocols). Consequently, agents demultiplex STUN and data using the contents of the packets rather than the port on which they are received.
STUNリクエストは、データ（RTP、RTCP、その他のプロトコルなど）に使用されるのとまったく同じIPアドレスおよびポートとの間で送受信されることに注意してください。その結果、エージェントはSTUNおよびデータを、それらが受信されるポートではなく、パケットの内容を使用して逆多重化します。
Because a STUN Binding request is used for the connectivity check, the STUN Binding response will contain the agent's translated transport address on the public side of any NATs between the agent and its peer. If this transport address is different from that of other candidates the agent already learned, it represents a new candidate (peer-reflexive candidate), which then gets tested by ICE just the same as any other candidate.
接続チェックにSTUNバインディング要求が使用されるため、STUNバインディング応答には、エージェントとそのピア間のNATのパブリック側にあるエージェントの変換されたトランスポートアドレスが含まれます。このトランスポートアドレスが、エージェントがすでに学習している他の候補のアドレスと異なる場合、それは新しい候補（ピアリフレクティブ候補）を表し、ICEによって他の候補とまったく同じようにテストされます。
Because the algorithm above searches all candidate pairs, if a working pair exists, the algorithm will eventually find it no matter what order the candidates are tried in. In order to produce faster (and better) results, the candidates are sorted in a specified order. The resulting list of sorted candidate pairs is called the "checklist".
上記のアルゴリズムはすべての候補ペアを検索するため、有効なペアが存在する場合、アルゴリズムは、候補が試行される順序に関係なく最終的にそれを見つけます。 。ソートされた候補ペアの結果のリストは、「チェックリスト」と呼ばれます。
The agent works through the checklist by sending a STUN request for the next candidate pair on the list periodically. These are called "ordinary checks". When a STUN transaction succeeds, one or more candidate pairs will become so-called "valid pairs" and will be added to a candidate-pair list called the "valid list".
エージェントは、リストの次の候補ペアのSTUN要求を定期的に送信することにより、チェックリストを処理します。これらは「通常のチェック」と呼ばれます。 STUNトランザクションが成功すると、1つ以上の候補ペアがいわゆる「有効なペア」になり、「有効なリスト」と呼ばれる候補ペアリストに追加されます。
As an optimization, as soon as R gets L's check message, R schedules a connectivity-check message to be sent to L on the same candidate pair. This is called a "triggered check", and it accelerates the process of finding valid pairs.
最適化として、RはLのチェックメッセージを受信するとすぐに、接続候補チェックメッセージを同じ候補ペアのLに送信するようにスケジュールします。これは「トリガーチェック」と呼ばれ、有効なペアを見つけるプロセスを高速化します。
At the end of this handshake, both L and R know that they can send (and receive) messages end to end in both directions.
このハンドシェイクの最後に、LとRの両方が、エンドツーエンドでメッセージを送信（および受信）できることを知っています。
In general, the priority algorithm is designed so that candidates of a similar type get similar priorities so that more direct routes (that is, routes without data relays or NATs) are preferred over indirect routes (routes with data relays or NATs). Within those guidelines, however, agents have a fair amount of discretion about how to tune their algorithms.
一般に、優先度アルゴリズムは、類似したタイプの候補が同様の優先度を取得するように設計されているため、間接ルート（データリレーまたはNATを使用するルート）よりも直接ルート（つまり、データリレーまたはNATを使用しないルート）が優先されます。ただし、これらのガイドライン内では、エージェントはアルゴリズムを調整する方法についてかなりの裁量権を持っています。
A data stream might consist of multiple components (pieces of a data stream that require their own set of candidates, e.g., RTP and RTCP).
データストリームは、複数のコンポーネント（独自の候補セット（RTPやRTCPなど）を必要とするデータストリームの一部）で構成される場合があります。
ICE assigns one of the ICE agents in the role of the controlling agent, and the other in the role of the controlled agent. For each component of a data stream, the controlling agent nominates a valid pair (from the valid list) to be used for data. The exact timing of the nomination is based on local policy.
ICEは、ICEエージェントの1つを制御エージェントの役割に割り当て、もう1つを制御エージェントの役割に割り当てます。データストリームの各コンポーネントについて、制御エージェントは、データに使用する有効なペアを（有効なリストから）指名します。指名の正確なタイミングは、地元の政策に基づいています。
When nominating, the controlling agent lets the checks continue until at least one valid pair for each component of a data stream is found, and then it picks a valid pair and sends a STUN request on that pair, using an attribute to indicate to the controlled peer that it has been nominated. This is shown in Figure 4.
指名するとき、制御エージェントは、データストリームの各コンポーネントの有効なペアが少なくとも1つ見つかるまでチェックを続行し、有効なペアを選択して、そのペアにSTUNリクエストを送信します。指名されたことを同輩。これを図4に示します。
L R - - STUN request -> \ L's <- STUN response / check
L R--STUNリクエスト-> \ Lの<-STUNレスポンス/チェック
<- STUN request \ R's
STUN response -> / check
STUN request + attribute -> \ L's
<- STUN response / check
Figure 4: Nomination
図4：指名
Once the controlled agent receives the STUN request with the attribute, it will check (unless the check has already been done) the same pair. If the transactions above succeed, the agents will set the nominated flag for the pairs and will cancel any future checks for that component of the data stream. Once an agent has set the nominated flag for each component of a data stream, the pairs become the selected pairs. After that, only the selected pairs will be used for sending and receiving data associated with that data stream.
制御されたエージェントが属性を持つSTUN要求を受信すると、（チェックが既に行われていない限り）同じペアをチェックします。上記のトランザクションが成功した場合、エージェントはペアに指名されたフラグを設定し、データストリームのそのコンポーネントに対する今後のチェックをキャンセルします。エージェントがデータストリームの各コンポーネントに指定されたフラグを設定すると、ペアが選択されたペアになります。その後、選択したペアのみが、そのデータストリームに関連付けられたデータの送受信に使用されます。
Once ICE is concluded, it can be restarted at any time for one or all of the data streams by either ICE agent. This is done by sending updated candidate information indicating a restart.
ICEが完了すると、いずれかのICEエージェントによって、1つまたはすべてのデータストリームに対していつでも再起動できます。これは、再起動を示す更新された候補情報を送信することによって行われます。
Certain ICE agents will always be connected to the public Internet and have a public IP address at which it can receive packets from any correspondent. To make it easier for these devices to support ICE, ICE defines a special type of implementation called "lite" (in contrast to the normal full implementation). Lite agents only use host candidates and do not generate connectivity checks or run state machines, though they need to be able to respond to connectivity checks.
特定のICEエージェントは常にパブリックインターネットに接続され、任意の通信相手からパケットを受信できるパブリックIPアドレスを持っています。これらのデバイスがICEをサポートしやすくするために、ICEは（通常の完全な実装とは対照的に）「ライト」と呼ばれる特別なタイプの実装を定義しています。 Liteエージェントはホスト候補のみを使用し、接続チェックを生成したり、ステートマシンを実行したりしませんが、接続チェックに応答できる必要があります。
This document specifies generic use of ICE with protocols that provide means to exchange candidate information between ICE agents. The specific details (i.e., how to encode candidate information and the actual candidate exchange process) for different protocols using ICE (referred to as "using protocol") are described in separate usage documents.
このドキュメントは、ICEエージェント間で候補者情報を交換する手段を提供するプロトコルでのICEの一般的な使用を指定します。 ICEを使用したさまざまなプロトコル（「プロトコルの使用」と呼ばれます）の具体的な詳細（候補情報と実際の候補交換プロセスをエンコードする方法）は、個別の使用法ドキュメントに記載されています。
One mechanism that allows agents to exchange candidate information is the utilization of Offer/Answer semantics (which are based on [RFC3264]) as part of the SIP protocol [RFC3261] [ICE-SIP-SDP].
エージェントが候補情報を交換できるようにする1つのメカニズムは、SIPプロトコル[RFC3261] [ICE-SIP-SDP]の一部としてのオファー/アンサーセマンティクス（[RFC3264]に基づく）の利用です。
[RFC7825] defines an ICE usage for the Real-Time Streaming Protocol (RTSP). Note, however, that the ICE usage is based on RFC 5245.
[RFC7825]は、リアルタイムストリーミングプロトコル（RTSP）のICEの使用法を定義しています。ただし、ICEの使用法はRFC 5245に基づいていることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Readers need to be familiar with the terminology defined in [RFC5389] and NAT Behavioral requirements for UDP [RFC4787].
読者は、[RFC5389]で定義されている用語とUDPのNAT動作要件[RFC4787]に精通している必要があります。
This specification makes use of the following additional terminology:
この仕様では、次の追加の用語を使用しています。
ICE Session: An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations, and keepalives) between the ICE agents until all the candidates are released or an ICE restart is triggered.
ICEセッション：ICEセッションは、候補者の収集から始まり、その後にすべての候補者が解放されるか、ICEの再起動が完了するまで、ICEエージェント間のやり取り（候補者の交換、接続性チェック、指名、およびキープアライブ）に続くすべてのICE関連のアクションで構成されます引き金になった。
ICE Agent, Agent: An ICE agent (sometimes simply referred to as an "agent") is the protocol implementation involved in the ICE candidate exchange. There are two agents involved in a typical candidate exchange.
ICEエージェント、エージェント：ICEエージェント（単に「エージェント」と呼ばれることもあります）は、ICE候補交換に関与するプロトコル実装です。典型的な候補者の交換には2人のエージェントが関与しています。
Initiating Peer, Initiating Agent, Initiator: An initiating agent is an ICE agent that initiates the ICE candidate exchange process.
開始ピア、開始エージェント、イニシエーター：開始エージェントは、ICE候補交換プロセスを開始するICEエージェントです。
Responding Peer, Responding Agent, Responder: A responding agent is an ICE agent that receives and responds to the candidate exchange process initiated by the initiating agent.
応答ピア、応答エージェント、レスポンダー：応答エージェントは、開始エージェントによって開始された候補交換プロセスを受信して応答するICEエージェントです。
ICE Candidate Exchange, Candidate Exchange: The process where ICE agents exchange information (e.g., candidates and passwords) that is needed to perform ICE. Offer/Answer with SDP encoding [RFC3264] is one example of a protocol that can be used for exchanging the candidate information.
ICE Candidate Exchange、Candidate Exchange：ICEエージェントがICEを実行するために必要な情報（候補者やパスワードなど）を交換するプロセス。 SDPエンコーディングを使用したオファー/アンサー[RFC3264]は、候補情報の交換に使用できるプロトコルの一例です。
Peer: From the perspective of one of the ICE agents in a session, its peer is the other agent. Specifically, from the perspective of the initiating agent, the peer is the responding agent. From the perspective of the responding agent, the peer is the initiating agent.
ピア：セッション内のICEエージェントの1つから見ると、そのピアは他のエージェントです。具体的には、開始エージェントの観点から見ると、ピアは応答エージェントです。応答エージェントの観点から見ると、ピアは開始エージェントです。
Transport Address: The combination of an IP address and the transport protocol (such as UDP or TCP) port.
トランスポートアドレス：IPアドレスとトランスポートプロトコル（UDPやTCPなど）ポートの組み合わせ。
Data, Data Stream, Data Session: When ICE is used to set up data sessions, the data is transported using some protocol. Media is usually transported over RTP, composed of a stream of RTP packets. Data session refers to data packets that are exchanged between the peer on the path created and tested with ICE.
データ、データストリーム、データセッション：ICEを使用してデータセッションを設定すると、データは何らかのプロトコルを使用して転送されます。メディアは通常、RTPパケットのストリームで構成されるRTPを介して転送されます。データセッションとは、ICEで作成およびテストされたパス上のピア間で交換されるデータパケットを指します。
Candidate, Candidate Information: A transport address that is a potential point of contact for receipt of data. Candidates also have properties -- their type (server reflexive, relayed, or host), priority, foundation, and base.
候補者、候補者情報：データの受信のための潜在的な連絡先であるトランスポートアドレス。候補者には、タイプ（サーバー再帰、リレー、またはホスト）、優先度、ファンデーション、ベースなどのプロパティもあります。
Component: A component is a piece of a data stream. A data stream may require multiple components, each of which has to work in order for the data stream as a whole to work. For RTP/RTCP data streams, unless RTP and RTCP are multiplexed in the same port, there are two components per data stream -- one for RTP, and one for RTCP. A component has a candidate pair, which cannot be used by other components.
コンポーネント：コンポーネントは、データストリームの一部です。データストリームには複数のコンポーネントが必要な場合があり、データストリーム全体として機能するためには、それぞれが機能する必要があります。 RTP / RTCPデータストリームの場合、RTPとRTCPが同じポートで多重化されていない限り、データストリームごとに2つのコンポーネントがあります。1つはRTP用で、もう1つはRTCP用です。コンポーネントには候補ペアがあり、他のコンポーネントでは使用できません。
Host Candidate: A candidate obtained by binding to a specific port from an IP address on the host. This includes IP addresses on physical interfaces and logical ones, such as ones obtained through VPNs.
ホスト候補：ホストのIPアドレスから特定のポートにバインドすることによって取得される候補。これには、物理インターフェイスのIPアドレスと、VPN経由で取得されたものなどの論理インターフェイスのIPアドレスが含まれます。
Server-Reflexive Candidate: A candidate whose IP address and port are a binding allocated by a NAT for an ICE agent after it sends a packet through the NAT to a server, such as a STUN server.
サーバー再帰候補：IPアドレスとポートが、NATを介してSTUNサーバーなどのサーバーにパケットを送信した後、ICEエージェントのNATによって割り当てられたバインディングである候補。
Peer-Reflexive Candidate: A candidate whose IP address and port are a binding allocated by a NAT for an ICE agent after it sends a packet through the NAT to its peer.
ピア再帰候補：IPアドレスとポートが、NATを介してピアにパケットを送信した後、ICEエージェント用にNATによって割り当てられたバインディングである候補。
Relayed Candidate: A candidate obtained from a relay server, such as a TURN server.
中継候補：TURNサーバーなどの中継サーバーから取得した候補。
Base: The transport address that an ICE agent sends from for a particular candidate. For host, server-reflexive, and peer-reflexive candidates, the base is the same as the host candidate. For relayed candidates, the base is the same as the relayed candidate (i.e., the transport address used by the TURN server to send from).
ベース：ICEエージェントが特定の候補者から送信するトランスポートアドレス。ホスト、サーバー再帰、およびピア再帰の候補の場合、ベースはホスト候補と同じです。リレーされた候補の場合、ベースはリレーされた候補と同じです（つまり、TURNサーバーが送信元として使用するトランスポートアドレス）。
Related Address and Port: A transport address related to a candidate, which is useful for diagnostics and other purposes. If a candidate is server or peer reflexive, the related address and port is equal to the base for that server or peer-reflexive candidate. If the candidate is relayed, the related address and port are equal to the mapped address in the Allocate response that provided the client with that relayed candidate. If the candidate is a host candidate, the related address and port is identical to the host candidate.
関連アドレスとポート：候補に関連するトランスポートアドレス。診断やその他の目的に役立ちます。候補がサーバーまたはピア再帰的である場合、関連するアドレスとポートは、そのサーバーまたはピア再帰的候補のベースと同じです。候補がリレーされる場合、関連するアドレスとポートは、クライアントにそのリレーされた候補を提供したAllocate応答のマッピングアドレスと同じです。候補がホスト候補の場合、関連するアドレスとポートはホスト候補と同じです。
Foundation: An arbitrary string used in the freezing algorithm to group similar candidates. It is the same for two candidates that have the same type, base IP address, protocol (UDP, TCP, etc.), and STUN or TURN server. If any of these are different, then the foundation will be different.
財団：類似の候補をグループ化するためにフリーズアルゴリズムで使用される任意の文字列。同じタイプ、ベースIPアドレス、プロトコル（UDP、TCPなど）、およびSTUNまたはTURNサーバーを持つ2つの候補の場合も同じです。これらのいずれかが異なる場合、基盤は異なります。
Local Candidate: A candidate that an ICE agent has obtained and may send to its peer.
ローカル候補：ICEエージェントが取得し、そのピアに送信する可能性のある候補。
Remote Candidate: A candidate that an ICE agent received from its peer.
リモート候補：ICEエージェントがピアから受信した候補。
Default Destination/Candidate: The default destination for a component of a data stream is the transport address that would be used by an ICE agent that is not ICE aware. A default candidate for a component is one whose transport address matches the default destination for that component.
デフォルトの宛先/候補：データストリームのコンポーネントのデフォルトの宛先は、ICEに対応していないICEエージェントが使用するトランスポートアドレスです。コンポーネントのデフォルト候補は、トランスポートアドレスがそのコンポーネントのデフォルト宛先と一致するものです。
Candidate Pair: A pair containing a local candidate and a remote candidate.
候補ペア：ローカル候補とリモート候補を含むペア。
Check, Connectivity Check, STUN Check: A STUN Binding request for the purpose of verifying connectivity. A check is sent from the base of the local candidate to the remote candidate of a candidate pair.
チェック、接続性チェック、STUNチェック：接続性を確認するためのSTUNバインディング要求。ローカル候補のベースから候補ペアのリモート候補にチェックが送信されます。
Checklist: An ordered set of candidate pairs that an ICE agent will use to generate checks.
チェックリスト：ICEエージェントがチェックを生成するために使用する、順序付けられた候補ペアのセット。
Ordinary Check: A connectivity check generated by an ICE agent as a consequence of a timer that fires periodically, instructing it to send a check.
通常のチェック：定期的に起動するタイマーの結果としてICEエージェントによって生成される接続チェックで、チェックを送信するように指示します。
Triggered Check: A connectivity check generated as a consequence of the receipt of a connectivity check from the peer.
トリガーされたチェック：ピアからの接続性チェックの受信の結果として生成された接続性チェック。
Valid Pair: A candidate pair whose local candidate equals the mapped address of a successful connectivity-check response and whose remote candidate equals the destination address to which the connectivity-check request was sent.
有効なペア：ローカル候補が正常な接続性チェック応答のマッピングアドレスと等しく、リモート候補が接続性チェック要求の送信先の宛先アドレスと等しい候補ペア。
Valid List: An ordered set of candidate pairs for a data stream that have been validated by a successful STUN transaction.
有効なリスト：成功したSTUNトランザクションによって検証された、データストリームの候補ペアの順序付きセット。
Checklist Set: The ordered list of all checklists. The order is determined by each ICE usage.
チェックリストセット：すべてのチェックリストの順序付きリスト。順序は、ICEの使用法ごとに決定されます。
Full Implementation: An ICE implementation that performs the complete set of functionality defined by this specification.
完全実装：この仕様で定義されている機能の完全なセットを実行するICE実装。
Lite Implementation: An ICE implementation that omits certain functions, implementing only as much as is necessary for a peer that is not a lite implementation to gain the benefits of ICE. Lite implementations do not maintain any of the state machines and do not generate connectivity checks.
ライト実装：特定の機能を省略したICE実装。ライト実装ではないピアがICEのメリットを得るために必要なだけ実装します。 Lite実装は、状態マシンを維持せず、接続性チェックを生成しません。
Controlling Agent: The ICE agent that nominates a candidate pair. In any session, there is always one controlling agent and one controlled agent.
制御エージェント：候補ペアを指名するICEエージェント。どのセッションでも、常に1つの制御エージェントと1つの制御エージェントがあります。
Controlled Agent: The ICE agent that waits for the controlling agent to nominate a candidate pair.
制御エージェント：制御エージェントが候補ペアを指名するのを待つICEエージェント。
Nomination: The process of the controlling agent indicating to the controlled agent which candidate pair the ICE agents will use for sending and receiving data. The nomination process defined in this specification was referred to as "regular nomination" in RFC 5245. The nomination process that was referred to as "aggressive nomination" in RFC 5245 has been deprecated in this specification.
指名：ICEエージェントがデータの送受信に使用する候補のペアを被制御エージェントに示す、制御エージェントのプロセス。この仕様で定義されている指名プロセスは、RFC 5245では「通常の指名」と呼ばれていました。RFC5245で「積極的な指名」と呼ばれていた指名プロセスは、この仕様で廃止されました。
Nominated, Nominated Flag: Once the nomination of a candidate pair has succeeded, the candidate pair has become nominated, and the value of its nominated flag is set to true.
指名、指名フラグ：候補ペアの指名が成功すると、候補ペアが指名され、指名フラグの値がtrueに設定されます。
Selected Pair, Selected Candidate Pair: The candidate pair used for sending and receiving data for a component of a data stream is referred to as the "selected pair". Before selected pairs have been produced for a data stream, any valid pair associated with a component of a data stream can be used for sending and receiving data for the component. Once there are nominated pairs for each component of a data stream, the nominated pairs become the selected pairs for the data stream. The candidates associated with the selected pairs are referred to as "selected candidates".
選択ペア、選択候補ペア：データストリームのコンポーネントのデータを送受信するために使用される候補ペアは、「選択ペア」と呼ばれます。選択したペアがデータストリームに対して生成される前に、データストリームのコンポーネントに関連付けられている有効なペアを使用して、コンポーネントのデータを送受信できます。データストリームの各コンポーネントに指定されたペアがあると、指定されたペアがデータストリームの選択されたペアになります。選択されたペアに関連付けられた候補は、「選択された候補」と呼ばれます。
Using Protocol, ICE Usage: The protocol that uses ICE for NAT traversal. A usage specification defines the protocol-specific details on how the procedures defined here are applied to that protocol.
プロトコル、ICEの使用法の使用：NATトラバーサルにICEを使用するプロトコル。使用法の仕様は、ここで定義された手順がそのプロトコルにどのように適用されるかに関するプロトコル固有の詳細を定義します。
Timer Ta: The timer for generating new STUN or TURN transactions.
タイマーTa：新しいSTUNまたはTURNトランザクションを生成するためのタイマー。
Timer RTO (Retransmission Timeout): The retransmission timer for a given STUN or TURN transaction.
タイマーRTO（再送信タイムアウト）：特定のSTUNまたはTURNトランザクションの再送信タイマー。
As part of ICE processing, both the initiating and responding agents gather candidates, prioritize and eliminate redundant candidates, and exchange candidate information with the peer as defined by the using protocol (ICE usage). Specifics of the candidate-encoding mechanism and the semantics of candidate information exchange is out of scope of this specification.
ICE処理の一部として、開始エージェントと応答エージェントの両方が候補を収集し、冗長な候補に優先順位を付けて排除し、使用プロトコル（ICEの使用法）で定義されたピアと候補情報を交換します。候補エンコーディング機構の詳細と候補情報交換のセマンティクスは、この仕様の範囲外です。
An ICE agent gathers candidates when it believes that communication is imminent. An initiating agent can do this based on a user interface cue or on an explicit request to initiate a session. Every candidate has a transport address. It also has a type and a base. Four types are defined and gathered by this specification -- host candidates, server-reflexive candidates, peer-reflexive candidates, and relayed candidates. The server-reflexive candidates are gathered using STUN or TURN, and relayed candidates are obtained through TURN. Peer-reflexive candidates are obtained in later phases of ICE, as a consequence of connectivity checks.
コミュニケーションが差し迫っていると思われる場合、ICEエージェントは候補者を収集します。開始エージェントは、ユーザーインターフェイスキューまたはセッションを開始する明示的な要求に基づいてこれを行うことができます。すべての候補者はトランスポートアドレスを持っています。タイプとベースもあります。この仕様では、ホスト候補、サーバー再帰候補、ピア再帰候補、および中継候補の4つのタイプが定義および収集されています。サーバー再帰候補はSTUNまたはTURNを使用して収集され、中継された候補はTURNを介して取得されます。ピアリフレクティブ候補は、接続性チェックの結果として、ICEの後のフェーズで取得されます。
The process for gathering candidates at the responding agent is identical to the process for the initiating agent. It is RECOMMENDED that the responding agent begin this process immediately on receipt of the candidate information, prior to alerting the user of the application associated with the ICE session.
応答エージェントで候補を収集するプロセスは、開始エージェントのプロセスと同じです。 ICEセッションに関連付けられたアプリケーションについてユーザーに警告する前に、候補者の情報を受け取った直後に応答エージェントがこのプロセスを開始することをお勧めします。
Host candidates are obtained by binding to ports on an IP address attached to an interface (physical or virtual, including VPN interfaces) on the host.
ホスト候補は、ホスト上のインターフェイス（VPNインターフェイスを含む物理または仮想）に接続されたIPアドレスのポートにバインドすることによって取得されます。
For each component of each data stream the ICE agent wishes to use, the agent SHOULD obtain a candidate on each IP address that the host has, with the exceptions listed below. The agent obtains each candidate by binding to a UDP port on the specific IP address. A host candidate (and indeed every candidate) is always associated with a specific component for which it is a candidate.
ICEエージェントが使用する各データストリームの各コンポーネントについて、エージェントは、以下に示す例外を除いて、ホストが持つ各IPアドレスの候補を取得する必要があります（SHOULD）。エージェントは、特定のIPアドレスのUDPポートにバインドすることによって各候補を取得します。ホスト候補（実際にはすべての候補）は常に、それが候補である特定のコンポーネントに関連付けられています。
Each component has an ID assigned to it, called the "component ID". For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a component ID of 1, and RTCP has a component ID of 2. In case of RTP/ RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP.
各コンポーネントには、「コンポーネントID」と呼ばれるIDが割り当てられています。 RTP / RTCPデータストリームの場合、RTPとRTCPの両方が同じUDPポートで多重化されていない限り（RTP / RTCP多重化）、RTP自体のコンポーネントIDは1で、RTCPのコンポーネントIDは2です。RTP/ RTCP多重化。RTPとRTCPの両方にコンポーネントID 1が使用されます。
When candidates are obtained, unless the agent knows for sure that RTP/RTCP multiplexing will be used (i.e., the agent knows that the other agent also supports, and is willing to use, RTP/RTCP multiplexing), or unless the agent only supports RTP/RTCP multiplexing, the agent MUST obtain a separate candidate for RTCP. If an agent has obtained a candidate for RTCP, and ends up using RTP/ RTCP multiplexing, the agent does not need to perform connectivity checks on the RTCP candidate. Absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used.
候補が取得されたとき、エージェントがRTP / RTCP多重化が使用されることを確実に知っている場合（つまり、エージェントは、他のエージェントもサポートし、RTP / RTCP多重化をサポートしていることを知っている場合）、またはエージェントがサポートする場合を除いてRTP / RTCP多重化では、エージェントはRTCPの個別の候補を取得する必要があります。エージェントがRTCPの候補を取得し、最終的にRTP / RTCP多重化を使用する場合、エージェントはRTCP候補の接続性チェックを実行する必要はありません。コンポーネントID 2が存在しないことは、RTCP / RTP多重化の使用を意味するものではありません。これは、RTCPが使用されないことを意味する場合もあります。
If an agent is using separate candidates for RTP and RTCP, it will end up with 2*K host candidates if an agent has K IP addresses.
エージェントがRTPとRTCPの別々の候補を使用している場合、エージェントがK個のIPアドレスを持っていると、2 * Kのホスト候補になります。
Note that the responding agent, when obtaining its candidates, will typically know if the other agent supports RTP/RTCP multiplexing, in which case it will not need to obtain a separate candidate for RTCP. However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used.
応答エージェントは、その候補を取得するときに、通常、他のエージェントがRTP / RTCP多重化をサポートしているかどうかを知っています。この場合、RTCPの個別の候補を取得する必要はありません。ただし、コンポーネントID 2が存在しないことは、RTCP / RTP多重化の使用を意味するものではありません。これは、RTCPが使用されないことを意味する場合もあります。
The use of multiple components, other than for RTP/RTCP streams, is discouraged as it increases the complexity of ICE processing. If multiple components are needed, the component IDs SHOULD start with 1 and increase by 1 for each component.
RTP / RTCPストリーム以外の複数のコンポーネントを使用すると、ICE処理が複雑になるため、使用しないでください。複数のコンポーネントが必要な場合、コンポーネントIDは1で始まり、コンポーネントごとに1ずつ増加する必要があります（SHOULD）。
The base for each host candidate is set to the candidate itself.
各ホスト候補のベースは、候補自体に設定されます。
The host candidates are gathered from all IP addresses with the following exceptions:
ホスト候補は、次の例外を除き、すべてのIPアドレスから収集されます。
o Addresses from a loopback interface MUST NOT be included in the candidate addresses.
o ループバックインターフェイスからのアドレスは、候補アドレスに含まれてはいけません。
o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site-local unicast addresses [RFC3879] MUST NOT be included in the address candidates.
o 非推奨のIPv4互換IPv6アドレス[RFC4291]およびIPv6サイトローカルユニキャストアドレス[RFC3879]をアドレス候補に含めてはなりません（MUST NOT）。
o IPv4-mapped IPv6 addresses SHOULD NOT be included in the address candidates unless the application using ICE does not support IPv4 (i.e., it is an IPv6-only application [RFC4038]).
o IPv4にマップされたIPv6アドレスは、ICEを使用するアプリケーションがIPv4をサポートしていない場合（つまり、IPv6のみのアプリケーション[RFC4038]）でない限り、アドレス候補に含めるべきではありません（SHOULD NOT）。
o If gathering one or more host candidates that correspond to an IPv6 address that was generated using a mechanism that prevents location tracking [RFC7721], host candidates that correspond to IPv6 addresses that do allow location tracking, are configured on the same interface, and are part of the same network prefix MUST NOT be gathered. Similarly, when host candidates corresponding to an IPv6 address generated using a mechanism that prevents location tracking are gathered, then host candidates corresponding to IPv6 link-local addresses [RFC4291] MUST NOT be gathered.
oロケーショントラッキングを防止するメカニズムを使用して生成されたIPv6アドレスに対応する1つ以上のホスト候補を収集する場合[RFC7721]、ロケーショントラッキングを許可するIPv6アドレスに対応するホスト候補は、同じインターフェイス上で構成され、同じネットワークプレフィックスの一部を収集してはなりません。同様に、位置追跡を防止するメカニズムを使用して生成されたIPv6アドレスに対応するホスト候補を収集する場合、IPv6リンクローカルアドレス[RFC4291]に対応するホスト候補を収集してはなりません（MUST NOT）。
The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses.
IPv6デフォルトアドレス選択仕様[RFC6724]は、一時アドレス[RFC4941]が永続アドレスよりも優先されることを指定しています。
An ICE agent SHOULD gather server-reflexive and relayed candidates. However, use of STUN and TURN servers may be unnecessary in certain networks and use of TURN servers may be expensive, so some deployments may elect not to use them. If an agent does not gather server-reflexive or relayed candidates, it is RECOMMENDED that the functionality be implemented and just disabled through configuration, so that it can be re-enabled through configuration if conditions change in the future.
ICEエージェントは、サーバー再帰的な中継候補を収集する必要があります（SHOULD）。ただし、特定のネットワークではSTUNサーバーとTURNサーバーの使用が不要であり、TURNサーバーの使用はコストがかかる場合があるため、一部のデプロイメントではそれらを使用しないことを選択する場合があります。エージェントがサーバー再帰候補または中継候補を収集しない場合は、機能が実装され、構成を通じて無効化されることをお勧めします。これにより、将来状況が変化した場合に構成を通じて再度有効化できます。
The agent pairs each host candidate with the STUN or TURN servers with which it is configured or has discovered by some means. It is RECOMMENDED that a domain name be configured, the DNS procedures in [RFC5389] (using SRV records with the "stun" service) be used to discover the STUN server, and the DNS procedures in [RFC5766] (using SRV records with the "turn" service) be used to discover the TURN server.
エージェントは、各ホスト候補を、それが構成されている、または何らかの手段で発見したSTUNまたはTURNサーバーとペアにします。ドメイン名を構成し、[RFC5389]のDNSプロシージャ（「stun」サービスでSRVレコードを使用）を使用してSTUNサーバーを発見し、[RFC5766]のDNSプロシージャ（SRVレコードを使用して「ターン」サービス）を使用して、TURNサーバーを検出します。
When multiple STUN or TURN servers are available (or when they are learned through DNS records and multiple results are returned), the agent MAY gather candidates for all of them and SHOULD gather candidates for at least one of them (one STUN server and one TURN server). It does so by pairing host candidates with STUN or TURN servers, and for each pair, the agent sends a Binding or Allocate request to the server from the host candidate. Binding requests to a STUN server are not authenticated, and any ALTERNATE-SERVER attribute in a response is ignored. Agents MUST support the backwards-compatibility mode for the Binding request defined in [RFC5389]. Allocate requests SHOULD be authenticated using a long-term credential obtained by the client through some other means.
複数のSTUNまたはTURNサーバーが利用可能な場合（またはDNSレコードを通じて学習され、複数の結果が返された場合）、エージェントはそれらすべての候補を収集でき（MAY）、少なくとも1つの候補（1つのSTUNサーバーと1つのTURN）の候補を収集する必要があります（SHOULD）。サーバ）。これは、ホスト候補をSTUNまたはTURNサーバーとペアリングすることによって行われ、ペアごとに、エージェントはバインディングまたは割り当て要求をホスト候補からサーバーに送信します。 STUNサーバーへのバインド要求は認証されず、応答内のALTERNATE-SERVER属性は無視されます。エージェントは、[RFC5389]で定義されているバインディング要求の後方互換モードをサポートする必要があります。割り当てリクエストは、他の方法でクライアントが取得した長期資格情報を使用して認証する必要があります（SHOULD）。
The gathering process is controlled using a timer, Ta. Every time Ta expires, the agent can generate another new STUN or TURN transaction. This transaction can be either a retry of a previous transaction that failed with a recoverable error (such as authentication failure) or a transaction for a new host candidate and STUN or TURN server pair. The agent SHOULD NOT generate transactions more frequently than once per each ta expiration. See Section 14 for guidance on how to set Ta and the STUN retransmit timer, RTO.
収集プロセスは、タイマーTaを使用して制御されます。 Taが期限切れになるたびに、エージェントは別の新しいSTUNまたはTURNトランザクションを生成できます。このトランザクションは、回復可能なエラー（認証の失敗など）で失敗した前のトランザクションの再試行、または新しいホスト候補とSTUNまたはTURNサーバーのペアのトランザクションのいずれかです。エージェントは、taの有効期限ごとに1回よりも頻繁にトランザクションを生成しないでください。 TaおよびSTUN再送信タイマーRTOの設定方法については、セクション14を参照してください。
The agent will receive a Binding or Allocate response. A successful Allocate response will provide the agent with a server-reflexive candidate (obtained from the mapped address) and a relayed candidate in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is rejected because the server lacks resources to fulfill it, the agent SHOULD instead send a Binding request to obtain a server-reflexive candidate. A Binding response will provide the agent with only a server-reflexive candidate (also obtained from the mapped address). The base of the server-reflexive candidate is the host candidate from which the Allocate or Binding request was sent. The base of a relayed candidate is that candidate itself. If a relayed candidate is identical to a host candidate (which can happen in rare cases), the relayed candidate MUST be discarded.
エージェントは、BindingまたはAllocate応答を受け取ります。 Allocate応答が成功すると、エージェントにサーバー再帰候補（マッピングされたアドレスから取得）とXOR-RELAYED-ADDRESS属性の中継候補が提供されます。サーバーがそれを実行するためのリソースを欠いているために割り当て要求が拒否された場合、エージェントは代わりにサーバー再帰候補を取得するためにバインディング要求を送信する必要があります。バインディング応答は、エージェントにサーバー再帰候補（マップされたアドレスからも取得される）のみを提供します。サーバー再帰候補のベースは、割り当て要求またはバインディング要求の送信元のホスト候補です。中継された候補のベースは、その候補自体です。リレーされた候補がホストの候補と同一である場合（これはまれに発生する可能性があります）、リレーされた候補は破棄されなければなりません（MUST）。
If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it may also gather IPv4 server-reflexive and/or relayed candidates from IPv4-only STUN or TURN servers. IPv6-only agents SHOULD also utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates.
IPv6のみのエージェントが、NAT64 [RFC6146]およびDNS64 [RFC6147]テクノロジーを利用するネットワークにある場合、IPv4のみのSTUNまたはTURNサーバーからIPv4サーバー再帰および/または中継候補を収集することもあります。 IPv6のみのエージェントは、IPv6プレフィックス検出[RFC7050]も利用して（存在する場合）NAT64が使用するIPv6プレフィックスを検出し、それに応じて各IPv6のみのインターフェースのサーバー再帰候補を生成する必要があります（SHOULD）。 NAT64サーバー再帰候補は、IPv4サーバー再帰候補と同様に優先されます。
The ICE agent assigns each candidate a foundation. Two candidates have the same foundation when all of the following are true:
ICEエージェントは、各候補者に基盤を割り当てます。次のすべてが当てはまる場合、2人の候補者は同じ基盤を持っています。
o They have the same type (host, relayed, server reflexive, or peer reflexive).
o それらは同じタイプ（ホスト、リレー、サーバー再帰、またはピア再帰）です。
o Their bases have the same IP address (the ports can be different).
o それらのベースは同じIPアドレスを持っています（ポートは異なる場合があります）。
o For reflexive and relayed candidates, the STUN or TURN servers used to obtain them have the same IP address (the IP address used by the agent to contact the STUN or TURN server).
o 再帰的およびリレーされた候補の場合、それらを取得するために使用されるSTUNまたはTURNサーバーは、同じIPアドレス（エージェントがSTUNまたはTURNサーバーに接続するために使用するIPアドレス）を持っています。
o They were obtained using the same transport protocol (TCP, UDP).
o それらは同じトランスポートプロトコル（TCP、UDP）を使用して取得されました。
Similarly, two candidates have different foundations if their types are different, their bases have different IP addresses, the STUN or TURN servers used to obtain them have different IP addresses (the IP addresses used by the agent to contact the STUN or TURN server), or their transport protocols are different.
同様に、2つの候補は、タイプが異なる場合、ベースが異なる場合、基盤が異なる場合、ベースが異なる場合、候補を取得するために使用されるSTUNまたはTURNサーバーは、異なるIPアドレス（エージェントがSTUNまたはTURNサーバーに接続するために使用するIPアドレス）を持ちます。またはそれらの転送プロトコルが異なります。
Once server-reflexive and relayed candidates are allocated, they MUST be kept alive until ICE processing has completed, as described in Section 8.3. For server-reflexive candidates learned through a Binding request, the bindings MUST be kept alive by additional Binding requests to the server. Refreshes for allocations are done using the Refresh transaction, as described in [RFC5766]. The Refresh requests will also refresh the server-reflexive candidate.
セクション8.3で説明されているように、サーバー再帰候補と中継候補が割り当てられたら、それらはICE処理が完了するまで存続しなければなりません（MUST）。 Bindingリクエストを通じて学習したサーバー再帰候補の場合、サーバーへの追加のBindingリクエストによってバインディングを維持する必要があります。 [RFC5766]で説明されているように、割り当ての更新は更新トランザクションを使用して行われます。更新要求は、サーバー再帰候補を更新します。
Host candidates do not time out, but the candidate addresses may change or disappear for a number of reasons. An ICE agent SHOULD monitor the interfaces it uses, invalidate candidates whose base has gone away, and acquire new candidates as appropriate when new IP addresses (on new or currently used interfaces) appear.
ホスト候補はタイムアウトしませんが、候補アドレスはさまざまな理由で変更または消失する可能性があります。 ICEエージェントは、使用するインターフェースを監視する必要があり（SHOULD）、ベースが廃止された候補を無効にし、（新しいまたは現在使用されているインターフェース上の）新しいIPアドレスが表示されたときに、必要に応じて新しい候補を取得します。
The prioritization process results in the assignment of a priority to each candidate. Each candidate for a data stream MUST have a unique priority that MUST be a positive integer between 1 and (2**31 - 1). This priority will be used by ICE to determine the order of the connectivity checks and the relative preference for candidates. Higher-priority values give more priority over lower values.
優先順位付けプロセスにより、各候補者に優先順位が割り当てられます。データストリームの各候補には、1から（2 ** 31-1）までの正の整数である必要がある一意の優先順位が必要です。この優先順位は、接続チェックの順序と候補の相対的な優先順位を決定するためにICEによって使用されます。優先度の高い値は、低い値よりも優先されます。
An ICE agent SHOULD compute this priority using the formula in Section 5.1.2.1 and choose its parameters using the guidelines in Section 5.1.2.2. If an agent elects to use a different formula, ICE may take longer to converge since the agents will not be coordinated in their checks.
ICEエージェントは、セクション5.1.2.1の式を使用してこの優先順位を計算し、セクション5.1.2.2のガイドラインを使用してそのパラメーターを選択する必要があります（SHOULD）。エージェントが別の式を使用することを選択した場合、エージェントはチェックで調整されないため、ICEは収束に時間がかかることがあります。
The process for prioritizing candidates is common across the initiating and the responding agent.
候補者に優先順位を付けるプロセスは、開始エージェントと応答エージェント全体で共通です。
The recommended formula combines a preference for the candidate type (server reflexive, peer reflexive, relayed, and host), a preference for the IP address for which the candidate was obtained, and a component ID using the following formula:
推奨される式は、次の式を使用して、候補タイプの優先順位（サーバー再帰、ピア再帰、中継、およびホスト）、候補が取得されたIPアドレスの優先順位、およびコンポーネントIDを組み合わせたものです。
priority = (2^24)*(type preference) +
(2^8)*(local preference) +
(2^0)*(256 - component ID)
The type preference MUST be an integer from 0 (lowest preference) to 126 (highest preference) inclusive, MUST be identical for all candidates of the same type, and MUST be different for candidates of different types. The type preference for peer-reflexive candidates MUST be higher than that of server-reflexive candidates. Setting the value to 0 means that candidates of this type will only be used as a last resort. Note that candidates gathered based on the procedures of Section 5.1.1 will never be peer-reflexive candidates; candidates of this type are learned from the connectivity checks performed by ICE.
タイプの優先順位は、0（最低優先順位）から126（最高優先順位）までの整数である必要があり、同じタイプのすべての候補で同一である必要があり、異なるタイプの候補では異なる必要があります。ピア再帰候補のタイプ設定は、サーバー再帰候補のタイプ設定よりも高くなければなりません（MUST）。値を0に設定すると、このタイプの候補は最後の手段としてのみ使用されます。セクション5.1.1の手順に基づいて収集された候補者は、決して同僚反射的な候補者になることはありません。このタイプの候補は、ICEによって実行される接続性チェックから学習されます。
The local preference MUST be an integer from 0 (lowest preference) to 65535 (highest preference) inclusive. When there is only a single IP address, this value SHOULD be set to 65535. If there are multiple candidates for a particular component for a particular data stream that have the same type, the local preference MUST be unique for each one. If an ICE agent is dual stack, the local preference SHOULD be set according to the current best practice described in [RFC8421].
ローカル設定は0（最低設定）から65535（最高設定）までの整数でなければなりません。 IPアドレスが1つしかない場合、この値は65535に設定する必要があります（SHOULD）。同じタイプの特定のデータストリームの特定のコンポーネントの候補が複数ある場合、ローカル設定はそれぞれに固有でなければなりません。 ICEエージェントがデュアルスタックの場合、ローカル設定は[RFC8421]で説明されている現在のベストプラクティスに従って設定する必要があります（SHOULD）。
The component ID MUST be an integer between 1 and 256 inclusive.
コンポーネントIDは1から256までの整数でなければなりません。
The RECOMMENDED values for type preferences are 126 for host candidates, 110 for peer-reflexive candidates, 100 for server-reflexive candidates, and 0 for relayed candidates.
タイププリファレンスのRECOMMENDED値は、ホスト候補の場合は126、ピア再帰候補の場合は110、サーバー再帰候補の場合は100、中継候補の場合は0です。
If an ICE agent is multihomed and has multiple IP addresses, the recommendations in [RFC8421] SHOULD be followed. If multiple TURN servers are used, local priorities for the candidates obtained from the TURN servers are chosen in a similar fashion as for multihomed local candidates: the local preference value is used to indicate a preference among different servers, but the preference MUST be unique for each one.
ICEエージェントがマルチホームであり、複数のIPアドレスを持っている場合、[RFC8421]の推奨に従う必要があります。複数のTURNサーバーが使用されている場合、TURNサーバーから取得された候補のローカル優先順位は、マルチホームのローカル候補と同様の方法で選択されます。ローカル優先値は、異なるサーバー間の優先を示すために使用されますが、優先は一意でなければなりませんそれぞれ。
When choosing type preferences, agents may take into account factors such as latency, packet loss, cost, network topology, security, privacy, and others.
タイプ設定を選択するとき、エージェントは、遅延、パケット損失、コスト、ネットワークトポロジ、セキュリティ、プライバシーなどの要素を考慮に入れる場合があります。
Next, the ICE agents (initiating and responding) eliminate redundant candidates. Two candidates can have the same transport address yet different bases, and these would not be considered redundant. Frequently, a server-reflexive candidate and a host candidate will be redundant when the agent is not behind a NAT. A candidate is redundant if and only if its transport address and base equal those of another candidate. The agent SHOULD eliminate the redundant candidate with the lower priority.
次に、ICEエージェント（開始および応答）は冗長な候補を排除します。 2つの候補は同じトランスポートアドレスを持つことができますが、ベースは異なる可能性があり、これらは冗長とは見なされません。多くの場合、エージェントがNATの背後にない場合、サーバー再帰候補とホスト候補は冗長になります。トランスポートアドレスとベースが別の候補のトランスポートアドレスとベースと等しい場合に限り、候補は冗長です。エージェントは、優先度の低い冗長な候補を削除する必要があります（SHOULD）。
Lite implementations only utilize host candidates. For each IP address, independent of an IP address family, there MUST be zero or one candidate. With the lite implementation, ICE cannot be used to dynamically choose amongst candidates. Therefore, including more than one candidate from a particular IP address family is NOT RECOMMENDED, since only a connectivity check can truly determine whether to use one address or the other. Instead, it is RECOMMENDED that agents that have multiple public IP addresses run full ICE implementations to ensure the best usage of its addresses.
Liteの実装では、ホスト候補のみが使用されます。各IPアドレスには、IPアドレスファミリとは関係なく、候補がゼロまたは1つ存在する必要があります。ライトインプリメンテーションでは、ICEを使用して候補の中から動的に選択することはできません。したがって、特定のIPアドレスファミリから複数の候補を含めることはお勧めできません。接続チェックだけが、どちらのアドレスを使用するかを決定できるためです。代わりに、複数のパブリックIPアドレスを持つエージェントが完全なICE実装を実行して、そのアドレスを最適に使用することをお勧めします。
Each component has an ID assigned to it, called the "component ID". For RTP/RTCP data streams, unless RTCP is multiplexed in the same port with RTP, the RTP itself has a component ID of 1 and RTCP a component ID of 2. If an agent is using RTCP without multiplexing, it MUST obtain candidates for it. However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used.
各コンポーネントには、「コンポーネントID」と呼ばれるIDが割り当てられています。 RTP / RTCPデータストリームの場合、RTPと同じポートでRTCPが多重化されていない限り、RTP自体のコンポーネントIDは1、RTCPのコンポーネントIDは2です。エージェントが多重化なしでRTCPを使用している場合、その候補を取得する必要があります。 。ただし、コンポーネントID 2が存在しないことは、RTCP / RTP多重化の使用を意味するものではありません。これは、RTCPが使用されないことを意味する場合もあります。
Each candidate is assigned a foundation. The foundation MUST be different for two candidates allocated from different IP addresses; otherwise, it MUST be the same. A simple integer that increments for each IP address will suffice. In addition, each candidate MUST be assigned a unique priority amongst all candidates for the same data stream. If the formula in Section 5.1.2.1 is used to calculate the priority, the type preference value SHOULD be set to 126. If a host is IPv4 only, the local preference value SHOULD be set to 65535. If a host is IPv6 or dual stack, the local preference value SHOULD be set to the precedence value for IP addresses described in RFC 6724 [RFC6724].
各候補者には財団が割り当てられます。異なるIPアドレスから割り当てられた2つの候補については、基盤が異なる必要があります。それ以外の場合は、同じである必要があります。 IPアドレスごとに増分する単純な整数で十分です。さらに、各候補には、同じデータストリームのすべての候補の中で一意の優先順位を割り当てる必要があります。セクション5.1.2.1の式を使用して優先度を計算する場合、タイプ設定値は126に設定する必要があります（SHOULD）。ホストがIPv4のみの場合、ローカル設定値は65535に設定する必要があります（SHOULD）。ホストがIPv6またはデュアルスタックの場合、ローカルプリファレンス値は、RFC 6724 [RFC6724]で説明されているIPアドレスの優先値に設定する必要があります（SHOULD）。
Next, an agent chooses a default candidate for each component of each data stream. If a host is IPv4 only, there would only be one candidate for each component of each data stream; therefore, that candidate is the default. If a host is IPv6 only, the default candidate would typically be a globally scoped IPv6 address. Dual-stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used for the default candidate, and the configuration needs to be based on which one its administrator believes has a higher chance of success in the current network environment.
次に、エージェントは各データストリームの各コンポーネントのデフォルト候補を選択します。ホストがIPv4のみの場合、各データストリームの各コンポーネントの候補は1つだけです。したがって、その候補がデフォルトです。ホストがIPv6のみの場合、デフォルトの候補は通常、グローバルスコープのIPv6アドレスです。デュアルスタックホストは、IPv4とIPv6のどちらをデフォルトの候補として使用する場合でも構成を許可する必要があり（SHOULD）、構成は、管理者が現在のネットワーク環境で成功する可能性が高いと信じている構成に基づく必要があります。
The procedures in this section are common across the initiating and responding agents.
このセクションの手順は、開始エージェントと応答エージェントに共通です。
ICE agents (initiating and responding) need the following information about candidates to be exchanged. Each ICE usage MUST define how the information is exchanged with the using protocol. This section describes the information that needs to be exchanged.
ICEエージェント（開始および応答）は、交換する候補者に関する以下の情報を必要とします。各ICE使用法は、情報が使用プロトコルとどのように交換されるかを定義しなければなりません。このセクションでは、交換する必要がある情報について説明します。
Candidates: One or more candidates. For each candidate:
候補者：1人以上の候補者。各候補者：
Address: The IP address and transport protocol port of the candidate.
アドレス：候補者のIPアドレスとトランスポートプロトコルポート。
Transport: The transport protocol of the candidate. This MAY be omitted if the using protocol only runs over a single transport protocol.
トランスポート：候補者のトランスポートプロトコル。使用しているプロトコルが単一のトランスポートプロトコル上でのみ実行される場合、これは省略される場合があります。
Foundation: A sequence of up to 32 characters.
財団：最大32文字のシーケンス。
Component ID: The component ID of the candidate. This MAY be omitted if the using protocol does not use the concept of components.
コンポーネントID：候補のコンポーネントID。使用するプロトコルがコンポーネントの概念を使用しない場合、これは省略される場合があります。
Priority: The 32-bit priority of the candidate.
優先度：候補者の32ビットの優先度。
Type: The type of the candidate.
タイプ：候補者のタイプ。
Related Address and Port: The related IP address and port of the candidate. These MAY be omitted or set to invalid values if the agent does not want to reveal them, e.g., for privacy reasons.
関連アドレスとポート：候補者の関連IPアドレスとポート。プライバシー上の理由などでエージェントが公開したくない場合は、これらを省略したり、無効な値に設定したりできます。
Extensibility Parameters: The using protocol might define means for adding new per-candidate ICE parameters in the future.
拡張性パラメーター：使用プロトコルは、将来的に候補者ごとの新しいICEパラメーターを追加する手段を定義する可能性があります。
Lite or Full: Whether the agent is a lite agent or full agent.
LiteまたはFull：エージェントがライトエージェントかフルエージェントか。
Connectivity-Check Pacing Value: The pacing value for connectivity checks that the agent wishes to use. This MAY be omitted if the agent wishes to use a defined default value.
接続性チェックのペーシング値：エージェントが使用する接続性チェックのペーシング値。これは、エージェントが定義済みのデフォルト値を使用する場合は省略できます。
Username Fragment and Password: Values used to perform connectivity checks. The values MUST be unguessable, with at least 128 bits of random number generator output used to generate the password, and at least 24 bits of output to generate the username fragment.
ユーザー名フラグメントとパスワード：接続性チェックの実行に使用される値。値は推測不可能である必要があり、少なくとも128ビットの乱数ジェネレータ出力がパスワードの生成に使用され、少なくとも24ビットの出力がユーザー名フラグメントの生成に使用されます。
Extensions: New media-stream or session-level attributes (ICE options).
拡張機能：新しいメディアストリームまたはセッションレベルの属性（ICEオプション）。
If the using protocol is vulnerable to, and able to detect, ICE mismatch (Section 5.4), a way is needed for the detecting agent to convey this information to its peer. It is a boolean flag.
使用しているプロトコルがICEミスマッチに対して脆弱であり、それを検出できる場合（セクション5.4）、検出エージェントがこの情報をピアに伝達する方法が必要です。ブールフラグです。
The using protocol may (or may not) need to deal with backwards compatibility with older implementations that do not support ICE. If a fallback mechanism to non-ICE is supported and is being used, then presumably the using protocol provides a way of conveying the default candidate (its IP address and port) in addition to the ICE parameters.
使用するプロトコルは、ICEをサポートしない古い実装との下位互換性を処理する必要がある場合があります（そうでない場合もあります）。非ICEへのフォールバックメカニズムがサポートされ、使用されている場合、おそらく使用しているプロトコルは、ICEパラメータに加えてデフォルトの候補（そのIPアドレスとポート）を伝達する方法を提供します。
Once an agent has sent its candidate information, it MUST be prepared to receive both STUN and data packets on each candidate. As discussed in Section 12.1, data packets can be sent to a candidate prior to its appearance as the default destination for data.
エージェントが候補情報を送信したら、各候補でSTUNとデータパケットの両方を受信する準備をしなければなりません。 12.1項で説明したように、データパケットは、データのデフォルトの宛先として表示される前に候補に送信できます。
Certain middleboxes, such as ALGs, can alter signaling information in ways that break ICE (e.g., by rewriting IP addresses in SDP). This is referred to as "ICE mismatch". If the using protocol is vulnerable to ICE mismatch, the responding agent needs to be able to detect it and inform the peer ICE agent about the ICE mismatch.
ALGなどの特定のミドルボックスは、ICEを壊すような方法でシグナリング情報を変更する可能性があります（たとえば、SDPでIPアドレスを書き換えることによって）。これは「ICEミスマッチ」と呼ばれます。使用しているプロトコルがICEの不一致に対して脆弱である場合、応答するエージェントはそれを検出し、ICEの不一致についてピアICEエージェントに通知できる必要があります。
Each using protocol needs to define whether the using protocol is vulnerable to ICE mismatch, how ICE mismatch is detected, and whether specific actions need to be taken when ICE mismatch is detected.
各使用プロトコルは、使用プロトコルがICEの不一致に対して脆弱かどうか、ICEの不一致を検出する方法、およびICEの不一致が検出されたときに特定のアクションを実行する必要があるかどうかを定義する必要があります。
Once an ICE agent has gathered its candidates and exchanged candidates with its peer (Section 5), it will determine its own role. In addition, full implementations will form checklists and begin performing connectivity checks with the peer.
ICEエージェントが候補者を収集し、候補者をピアと交換すると（セクション5）、エージェントは自身の役割を決定します。さらに、完全な実装はチェックリストを形成し、ピアとの接続性チェックの実行を開始します。
For each session, each ICE agent (initiating and responding) takes on a role. There are two roles -- controlling and controlled. The controlling agent is responsible for the choice of the final candidate pairs used for communications. The sections below describe in detail the actual procedures followed by controlling and controlled agents.
セッションごとに、各ICEエージェント（開始および応答）が役割を果たします。制御と制御の2つの役割があります。制御エージェントは、通信に使用される最終的な候補ペアの選択を担当します。以下のセクションでは、制御エージェントと制御エージェントが実行する実際の手順について詳しく説明します。
The rules for determining the role and the impact on behavior are as follows:
役割と行動への影響を決定するためのルールは次のとおりです。
Both agents are full: The initiating agent that started the ICE processing MUST take the controlling role, and the other MUST take the controlled role. Both agents will form checklists, run the ICE state machines, and generate connectivity checks. The controlling agent will execute the logic in Section 8.1 to nominate pairs that will become (if the connectivity checks associated with the nominations succeed) the selected pairs, and then both agents end ICE as described in Section 8.1.2.
両方のエージェントがいっぱいです。ICE処理を開始した開始エージェントは制御の役割を果たさなければならず、他のエージェントは制御の役割を果たさなければなりません。両方のエージェントがチェックリストを作成し、ICEステートマシンを実行し、接続チェックを生成します。制御エージェントはセクション8.1のロジックを実行してペアを指定し（指名に関連する接続性チェックが成功した場合）、選択されたペアになり、セクション8.1.2で説明されているように両方のエージェントがICEを終了します。
One agent full, one lite: The full agent MUST take the controlling role, and the lite agent MUST take the controlled role. The full agent will form checklists, run the ICE state machines, and generate connectivity checks. That agent will execute the logic in Section 8.1 to nominate pairs that will become (if the connectivity checks associated with the nominations succeed) the selected pairs and use the logic in Section 8.1.2 to end ICE. The lite implementation will just listen for connectivity checks, receive them and respond to them, and then conclude ICE as described in Section 8.2. For the lite implementation, the state of ICE processing for each data stream is considered to be Running, and the state of ICE overall is Running.
フルエージェント1つ、ライト1つ：フルエージェントが制御の役割を果たし、ライトエージェントが制御された役割を実行する必要があります。完全なエージェントはチェックリストを作成し、ICEステートマシンを実行し、接続チェックを生成します。そのエージェントはセクション8.1のロジックを実行してペアを指定し（指名に関連する接続性チェックが成功した場合）、選択されたペアになり、セクション8.1.2のロジックを使用してICEを終了します。ライト実装は、接続性チェックをリッスンし、それらを受信して応答し、セクション8.2で説明されているようにICEを終了します。 Lite実装の場合、各データストリームのICE処理の状態は実行中と見なされ、ICE全体の状態は実行中です。
Both lite: The initiating agent that started the ICE processing MUST take the controlling role, and the other MUST take the controlled role. In this case, no connectivity checks are ever sent. Rather, once the candidates are exchanged, each agent performs the processing described in Section 8 without connectivity checks. It is possible that both agents will believe they are controlled or controlling. In the latter case, the conflict is resolved through glare detection capabilities in the signaling protocol enabling the candidate exchange. The state of ICE processing for each data stream is considered to be Running, and the state of ICE overall is Running.
両方のライト：ICE処理を開始した開始エージェントは制御の役割を果たさなければならず（MUST）、もう一方は制御の役割を果たさなければなりません（MUST）。この場合、接続性チェックは送信されません。むしろ、候補が交換されると、各エージェントは接続性チェックなしでセクション8で説明されている処理を実行します。両方のエージェントが、自分が制御されているか制御していると信じている可能性があります。後者の場合、競合は、候補交換を可能にするシグナリングプロトコルのグレア検出機能によって解決されます。各データストリームのICE処理の状態は実行中と見なされ、ICE全体の状態は実行中です。
Once the roles are determined for a session, they persist throughout the lifetime of the session. The roles can be redetermined as part of an ICE restart (Section 9), but an ICE agent MUST NOT redetermine the role as part of an ICE restart unless one or more of the following criteria is fulfilled:
セッションの役割が決定されると、その役割はセッションの存続期間を通じて持続します。役割はICE再起動の一部として再決定できますが（セクション9）、次の基準の1つ以上が満たされない限り、ICEエージェントはICE再起動の一部として役割を再決定してはなりません。
Full becomes lite: If the controlling agent is full, and switches to lite, the roles MUST be redetermined if the peer agent is also full.
フルがライトになる：制御エージェントがフルでライトに切り替わる場合、ピアエージェントもフルである場合、役割を再決定する必要があります。
Role conflict: If the ICE restart causes a role conflict, the roles might be redetermined due to the role conflict procedures in Section 7.3.1.1.
役割の競合：ICEの再起動により役割の競合が発生した場合、7.3.1.1の役割の競合手順により、役割が再決定される可能性があります。
NOTE: There are certain Third Party Call Control (3PCC) [RFC3725] scenarios where an ICE restart might cause a role conflict.
注：ICEの再起動が役割の競合を引き起こす可能性がある特定のサードパーティコール制御（3PCC）[RFC3725]シナリオがあります。
NOTE: The agents need to inform each other whether they are full or lite before the roles are determined. The mechanism for that is specific to the signaling protocol and outside the scope of the document.
注：エージェントは、役割が決定される前に、エージェントが満員かライトかを互いに通知する必要があります。そのメカニズムは、シグナリングプロトコルに固有であり、ドキュメントの範囲外です。
An agent MUST accept if the peer initiates a redetermination of the roles even if the criteria for doing so are not fulfilled. This can happen if the peer is compliant with RFC 5245.
ピアが役割の再決定を開始する場合、その基準が満たされていない場合でも、エージェントはそれを受け入れる必要があります。これは、ピアがRFC 5245に準拠している場合に発生する可能性があります。
There is one checklist for each data stream. To form a checklist, initiating and responding ICE agents form candidate pairs, compute pair priorities, order pairs by priority, prune pairs, remove lower-priority pairs, and set checklist states. If candidates are added to a checklist (e.g., due to detection of peer-reflexive candidates), the agent will re-perform these steps for the updated checklist.
データストリームごとに1つのチェックリストがあります。チェックリストを作成するには、開始と応答のICEエージェントが候補ペアを形成し、ペアの優先度を計算し、優先度でペアを並べ替え、ペアをプルーニングし、優先度の低いペアを削除し、チェックリストの状態を設定します。候補がチェックリストに追加された場合（ピア再帰候補の検出などにより）、エージェントは更新されたチェックリストに対してこれらの手順を再実行します。
Each checklist has a state, which captures the state of ICE checks for the data stream associated with the checklist. The states are:
各チェックリストには状態があり、チェックリストに関連付けられたデータストリームのICEチェックの状態をキャプチャします。状態は次のとおりです。
Running: The checklist is neither Completed nor Failed yet. Checklists are initially set to the Running state.
実行中：チェックリストはまだ完了も失敗もしていません。チェックリストは、最初は実行状態に設定されています。
Completed: The checklist contains a nominated pair for each component of the data stream.
完了：チェックリストには、データストリームの各コンポーネントの指定されたペアが含まれています。
Failed: The checklist does not have a valid pair for each component of the data stream, and all of the candidate pairs in the checklist are in either the Failed or the Succeeded state. In other words, at least one component of the checklist has candidate pairs that are all in the Failed state, which means the component has failed, which means the checklist has failed.
失敗：チェックリストには、データストリームの各コンポーネントに対して有効なペアがありません。チェックリストのすべての候補ペアは、失敗または成功のいずれかの状態です。言い換えると、チェックリストの少なくとも1つのコンポーネントに、すべてFailed状態の候補ペアがあります。これは、コンポーネントが失敗したこと、つまりチェックリストが失敗したことを意味します。
The ICE agent pairs each local candidate with each remote candidate for the same component of the same data stream with the same IP address family. It is possible that some of the local candidates won't get paired with remote candidates, and some of the remote candidates won't get paired with local candidates. This can happen if one agent doesn't include candidates for all of the components for a data stream. If this happens, the number of components for that data stream is effectively reduced and is considered to be equal to the minimum across both agents of the maximum component ID provided by each agent across all components for the data stream.
ICEエージェントは、各ローカル候補と各リモート候補を、同じIPアドレスファミリーを持つ同じデータストリームの同じコンポーネントのペアにします。一部のローカル候補がリモート候補とペアにならず、一部のリモート候補がローカル候補とペアにならない可能性があります。これは、1つのエージェントがデータストリームのすべてのコンポーネントの候補を含まない場合に発生する可能性があります。これが発生した場合、そのデータストリームのコンポーネント数は実質的に減少し、データストリームのすべてのコンポーネントにわたって各エージェントによって提供される最大コンポーネントIDの両方のエージェント全体の最小数と等しいと見なされます。
In the case of RTP, this would happen when one agent provides candidates for RTCP, and the other does not. As another example, the initiating agent can multiplex RTP and RTCP on the same port [RFC5761]. However, since the initiating agent doesn't know if the peer agent can perform such multiplexing, it includes candidates for RTP and RTCP on separate ports. If the peer agent can perform such multiplexing, it would include just a single component for each candidate -- for the combined RTP/RTCP mux. ICE would end up acting as if there was just a single component for this candidate.
RTPの場合、これは1つのエージェントがRTCPの候補を提供し、他のエージェントが提供しない場合に発生します。別の例として、開始エージェントは同じポート[RFC5761]でRTPとRTCPを多重化できます。ただし、開始エージェントは、ピアエージェントがそのような多重化を実行できるかどうかを認識していないため、別のポートでのRTPおよびRTCPの候補が含まれています。ピアエージェントがこのような多重化を実行できる場合、候補ごとに1つのコンポーネント（RTP / RTCPを組み合わせたマルチプレクサ）のみが含まれます。 ICEは、この候補のコンポーネントが1つしかないかのように動作することになります。
With IPv6, it is common for a host to have multiple host candidates for each interface. To keep the amount of resulting candidate pairs reasonable and to avoid candidate pairs that are highly unlikely to work, IPv6 link-local addresses MUST NOT be paired with other than link-local addresses.
IPv6では、ホストが各インターフェースに複数のホスト候補を持つことが一般的です。結果の候補ペアの量を合理的に保ち、機能する可能性が非常に低い候補ペアを回避するために、IPv6リンクローカルアドレスはリンクローカルアドレス以外とペアにしてはなりません（MUST NOT）。
The candidate pairs whose local and remote candidates are both the default candidates for a particular component is called the "default candidate pair" for that component. This is the pair that would be used to transmit data if both agents had not been ICE aware.
ローカル候補とリモート候補の両方が特定のコンポーネントのデフォルト候補である候補ペアは、そのコンポーネントの「デフォルト候補ペア」と呼ばれます。これは、両方のエージェントがICEを認識していなかった場合にデータを送信するために使用されるペアです。
Figure 5 shows the properties of and relationships between transport addresses, candidates, candidate pairs, and checklists.
図5は、トランスポートアドレス、候補、候補ペア、およびチェックリストのプロパティと関係を示しています。
+--------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +Component ID |
| | Transport | +Related Address |
| | Addr | |
| +---------------------+ +Base |
| Candidate |
+--------------------------------------------+
* *
* *************************************
* *
+-------------------------------+
| |
| Local Remote |
| +----+ +----+ +default? |
| |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?|
| +State |
| |
| |
| Candidate Pair |
+-------------------------------+
* *
* ************
* *
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
Checklist
チェックリスト
Figure 5: Conceptual Diagram of a Checklist
図5：チェックリストの概念図
The ICE agent computes a priority for each candidate pair. Let G be the priority for the candidate provided by the controlling agent. Let D be the priority for the candidate provided by the controlled agent. The priority for a pair is computed as follows:
ICEエージェントは、各候補ペアの優先度を計算します。制御エージェントによって提供された候補の優先順位をGとします。被制御エージェントによって提供された候補の優先順位をDとします。ペアの優先度は次のように計算されます。
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
The agent sorts each checklist in decreasing order of candidate pair priority. If two pairs have identical priority, the ordering amongst them is arbitrary.
エージェントは、候補のペアの優先度の降順で各チェックリストを並べ替えます。 2つのペアの優先順位が同じ場合、それらの間の順序は任意です。
This sorted list of candidate pairs is used to determine a sequence of connectivity checks that will be performed. Each check involves sending a request from a local candidate to a remote candidate. Since an ICE agent cannot send requests directly from a reflexive candidate (server reflexive or peer reflexive), but only from its base, the agent next goes through the sorted list of candidate pairs. For each pair where the local candidate is reflexive, the candidate MUST be replaced by its base.
このソートされた候補ペアのリストは、実行される接続性チェックのシーケンスを決定するために使用されます。各チェックでは、ローカルの候補者からリモートの候補者にリクエストを送信します。 ICEエージェントは再帰候補（サーバー再帰またはピア再帰）から直接要求を送信することはできませんが、そのベースからのみ送信できるため、エージェントは次に候補ペアのソートされたリストを通過します。ローカル候補が再帰的である各ペアについて、候補はそのベースで置き換えられなければなりません（MUST）。
The agent prunes each checklist. This is done by removing a candidate pair if it is redundant with a higher-priority candidate pair in the same checklist. Two candidate pairs are redundant if their local candidates have the same base and their remote candidates are identical. The result is a sequence of ordered candidate pairs, called the "checklist" for that data stream.
エージェントは各チェックリストを整理します。これは、同じチェックリスト内で優先順位の高い候補ペアと冗長である場合、候補ペアを削除することによって行われます。ローカル候補が同じベースを持ち、リモート候補が同一である場合、2つの候補ペアは冗長です。結果は、そのデータストリームの「チェックリスト」と呼ばれる、順序付けされた候補ペアのシーケンスです。
In order to limit the attacks described in Section 19.5.1, an ICE agent MUST limit the total number of connectivity checks the agent performs across all checklists in the checklist set. This is done by limiting the total number of candidate pairs in the checklist set. The default limit of candidate pairs for the checklist set is 100, but the value MUST be configurable. The limit is enforced by, within in each checklist, discarding lower-priority candidate pairs until the total number of candidate pairs in the checklist set is smaller than the limit value. The discarding SHOULD be done evenly so that the number of candidate pairs in each checklist is reduced the same amount.
セクション19.5.1で説明されている攻撃を制限するために、ICEエージェントは、チェックリストセットのすべてのチェックリストにわたってエージェントが実行する接続チェックの総数を制限する必要があります。これは、チェックリストセットの候補ペアの総数を制限することによって行われます。チェックリストセットの候補ペアのデフォルトの制限は100ですが、値は構成可能でなければなりません。制限は、各チェックリスト内で、チェックリストセット内の候補ペアの総数が制限値よりも小さくなるまで、優先度の低い候補ペアを破棄することによって適用されます。各チェックリストの候補ペアの数が同じ量だけ削減されるように、破棄は均等に行われる必要があります。
It is RECOMMENDED that a lower-limit value than the default is picked when possible, and that the value is set to the maximum number of plausible candidate pairs that might be created in an actual deployment configuration. The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic.
可能な場合はデフォルトよりも低い値が選択され、その値が実際のデプロイメント構成で作成される可能性のある候補ペアの最大数に設定されることをお勧めします。構成の要件は、いったん展開すると問題があることが判明した場合に、フィールドでこの値を修正するためのツールを提供することを意図しています。
Each candidate pair in the checklist has a foundation (the combination of the foundations of the local and remote candidates in the pair) and one of the following states:
チェックリストの各候補ペアには、基盤（ペアのローカル候補とリモート候補の基盤の組み合わせ）と、次のいずれかの状態があります。
Waiting: A check has not been sent for this pair, but the pair is not Frozen.
待機中：このペアのチェックは送信されていませんが、ペアは凍結されていません。
In-Progress: A check has been sent for this pair, but the transaction is in progress.
進行中：このペアのチェックが送信されましたが、トランザクションは進行中です。
Succeeded: A check has been sent for this pair, and it produced a successful result.
成功：このペアのチェックが送信され、正常な結果が生成されました。
Failed: A check has been sent for this pair, and it failed (a response to the check was never received, or a failure response was received).
失敗：このペアに対してチェックが送信され、失敗しました（チェックへの応答が受信されなかったか、失敗応答が受信されました）。
Frozen: A check for this pair has not been sent, and it cannot be sent until the pair is unfrozen and moved into the Waiting state.
Frozen：このペアの小切手は送信されていません。ペアがフリーズ解除されてWaiting状態になるまで送信できません。
Pairs move between states as shown in Figure 6.
図6に示すように、ペアは状態間を移動します。
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
|unfreeze
|
V
+-----------+ +-----------+
| | | |
| | perform | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
failure // |success
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+
Figure 6: Pair State Finite State Machine (FSM)
図6：ペア状態有限状態機械（FSM）
The initial states for each pair in a checklist are computed by performing the following sequence of steps:
チェックリストの各ペアの初期状態は、次の一連の手順を実行することによって計算されます。
1. The checklists are placed in an ordered list (the order is determined by each ICE usage), called the "checklist set".
1. チェックリストは、「チェックリストセット」と呼ばれる順序付けされたリスト（順序は各ICE使用法によって決定されます）に配置されます。
2. The ICE agent initially places all candidate pairs in the Frozen state.
2. ICEエージェントは、最初にすべての候補ペアを凍結状態にします。
3. The agent sets all of the checklists in the checklist set to the Running state.
3. エージェントは、チェックリストセット内のすべてのチェックリストを実行状態に設定します。
4. For each foundation, the agent sets the state of exactly one candidate pair to the Waiting state (unfreezing it). The candidate pair to unfreeze is chosen by finding the first candidate pair (ordered by the lowest component ID and then the highest priority if component IDs are equal) in the first checklist (according to the usage-defined checklist set order) that has that foundation.
4. 各ファンデーションについて、エージェントは1つの候補ペアの状態を待機状態（フリーズ解除）に設定します。フリーズ解除する候補ペアは、その基盤を持つ最初のチェックリスト（使用法で定義されたチェックリストセットの順序に従って）の最初のチェックリスト（コンポーネントIDが等しい場合は、コンポーネントIDが最も高く、次に優先順位が最も高い）を見つけることによって選択されます。 。
NOTE: The procedures above are different from RFC 5245, where only candidate pairs in the first checklist were initially placed in the Waiting state. Now it applies to candidate pairs in the first checklist that have that foundation, even if the checklist is not the first one in the checklist set.
注：上記の手順はRFC 5245とは異なります。RFC5245では、最初のチェックリストの候補ペアのみが最初に待機状態に置かれました。チェックリストがチェックリストセットの最初のチェックリストでなくても、その基礎を持つ最初のチェックリストの候補ペアに適用されます。
The table below illustrates an example.
次の表に例を示します。
Table legend:
テーブルの凡例：
Each row (m1, m2,...) represents a checklist associated with a data stream. m1 represents the first checklist in the checklist set.
各行（m1、m2、...）は、データストリームに関連付けられたチェックリストを表します。 m1は、チェックリストセットの最初のチェックリストを表します。
Each column (f1, f2,...) represents a foundation. Every candidate pair within a given column share the same foundation.
各列（f1、f2、...）は基礎を表します。特定の列内のすべての候補ペアは、同じ基盤を共有します。
f-cp represents a candidate pair in the Frozen state.
f-cpは、Frozen状態の候補ペアを表します。
w-cp represents a candidate pair in the Waiting state.
w-cpは、待機状態の候補ペアを表します。
1. The agent sets all of the pairs in the checklist set to the Frozen state.
1. エージェントは、チェックリストセットのすべてのペアを凍結状態に設定します。
f1 f2 f3 f4 f5
-----------------------------
m1 | f-cp f-cp f-cp
|
m2 | f-cp f-cp f-cp f-cp
|
m3 | f-cp f-cp
2. For each foundation, the candidate pair with the lowest component ID is placed in the Waiting state, unless a candidate pair associated with the same foundation has already been put in the Waiting state in one of the other examined checklists in the checklist set.
2. 各ファンデーションについて、同じファンデーションに関連付けられた候補ペアがチェックリストセット内の他の検査済みチェックリストのいずれかですでに待機状態になっていなければ、最小のコンポーネントIDを持つ候補ペアが待機状態になります。
f1 f2 f3 f4 f5
-----------------------------
m1 | w-cp w-cp w-cp
|
m2 | f-cp f-cp f-cp w-cp
|
m3 | f-cp w-cp
Table 1: Pair State Example
表1：ペア状態の例
In the first checklist (m1), the candidate pair for each foundation is placed in the Waiting state, as no pairs for the same foundations have yet been placed in the Waiting state.
最初のチェックリスト（m1）では、同じファンデーションのペアはまだ待機状態になっていないため、各ファンデーションの候補ペアは待機状態になります。
In the second checklist (m2), the candidate pair for foundation f4 is placed in the Waiting state. The candidate pair for foundations f1, f2, and f3 are kept in the Frozen state, as candidate pairs for those foundations have already been placed in the Waiting state (within checklist m1).
2番目のチェックリスト（m2）では、ファンデーションf4の候補ペアが待機状態になります。ファンデーションf1、f2、およびf3の候補ペアは凍結状態のままです。これらのファンデーションの候補ペアはすでに（チェックリストm1内で）待機状態になっているためです。
In the third checklist (m3), the candidate pair for foundation f5 is placed in the Waiting state. The candidate pair for foundation f1 is kept in the Frozen state, as a candidate pair for that foundation has already been placed in the Waiting state (within checklist m1).
3番目のチェックリスト（m3）では、ファンデーションf5の候補ペアが待機状態になります。ファンデーションf1の候補ペアは凍結状態のままです。これは、そのファンデーションの候補ペアがすでに（チェックリストm1内で）待機状態になっているためです。
Once each checklist have been processed, one candidate pair for each foundation in the checklist set has been placed in the Waiting state.
各チェックリストが処理されると、チェックリストセットの各ファンデーションの1つの候補ペアが待機状態になります。
The ICE agent has a state determined by the state of the checklists. The state is Completed if all checklists are Completed, Failed if all checklists are Failed, or Running otherwise.
ICEエージェントには、チェックリストの状態によって決定される状態があります。状態は、すべてのチェックリストが完了した場合は完了、すべてのチェックリストが失敗した場合は失敗、その他の場合は実行中です。
Once the ICE agent has computed the checklists and created the checklist set, as described in Section 6.1.2, the agent will begin performing connectivity checks (ordinary and triggered). For triggered connectivity checks, the agent maintains a FIFO queue for each checklist, referred to as the "triggered-check queue", which contains candidate pairs for which checks are to be sent at the next available opportunity. The triggered-check queue is initially empty.
ICEエージェントがチェックリストを計算してチェックリストセットを作成すると、セクション6.1.2で説明されているように、エージェントは接続チェック（通常およびトリガー）の実行を開始します。トリガーされた接続性チェックの場合、エージェントは、「トリガーされたチェックキュー」と呼ばれる各チェックリストのFIFOキューを維持します。トリガーされたチェックキューは、最初は空です。
The generation of ordinary and triggered connectivity checks is governed by timer Ta. As soon as the initial states for the candidate pairs in the checklist set have been set, a check is performed for a candidate pair within the first checklist in the Running state, following the procedures in Section 7. After that, whenever Ta fires the next checklist in the Running state in the checklist set is picked, and a check is performed for a candidate within that checklist. After the last checklist in the Running state in the checklist set has been processed, the first checklist is picked again, etc.
通常のトリガーされた接続性チェックの生成は、タイマーTaによって制御されます。チェックリストセットの候補ペアの初期状態が設定されるとすぐに、セクション7の手順に従って、実行状態の最初のチェックリスト内の候補ペアのチェックが実行されます。その後、Taが次のチェックリストセットのRunning状態のチェックリストが選択され、そのチェックリスト内の候補に対してチェックが実行されます。チェックリストセットのRunning状態の最後のチェックリストが処理された後、最初のチェックリストが再度選択されます。
Whenever Ta fires, the ICE agent will perform a check for a candidate pair within the checklist that was picked by performing the following steps:
Taが起動するたびに、ICEエージェントは、次の手順を実行して、選択されたチェックリスト内の候補ペアのチェックを実行します。
1. If the triggered-check queue associated with the checklist contains one or more candidate pairs, the agent removes the top pair from the queue, performs a connectivity check on that pair, puts the candidate pair state to In-Progress, and aborts the subsequent steps.
1. チェックリストに関連付けられたトリガーされたチェックキューに1つ以上の候補ペアが含まれている場合、エージェントはキューから上位ペアを削除し、そのペアに対して接続性チェックを実行し、候補ペアの状態を進行中にして、後続の手順を中止します。
2. If there is no candidate pair in the Waiting state, and if there are one or more pairs in the Frozen state, the agent checks the foundation associated with each pair in the Frozen state. For a given foundation, if there is no pair (in any checklist in the checklist set) in the Waiting or In-Progress state, the agent puts the candidate pair state to Waiting and continues with the next step.
2. 待機状態に候補ペアがない場合、および凍結状態に1つ以上のペアがある場合、エージェントは凍結状態の各ペアに関連付けられたファンデーションをチェックします。特定のファウンデーションについて、（チェックリストセットのどのチェックリストにも）待機または進行中の状態のペアがない場合、エージェントは候補ペアの状態を待機にして、次のステップに進みます。
3. If there are one or more candidate pairs in the Waiting state, the agent picks the highest-priority candidate pair (if there are multiple pairs with the same priority, the pair with the lowest component ID is picked) in the Waiting state, performs a connectivity check on that pair, puts the candidate pair state to In-Progress, and aborts the subsequent steps.
3. Waiting状態の候補ペアが1つ以上ある場合、エージェントは、Waiting状態で最も優先度の高い候補ペアを選択し（同じ優先度のペアが複数ある場合は、最も低いコンポーネントIDのペアが選択されます）、そのペアの接続性チェック、候補ペアの状態を処理中、および後続の手順を中止します。
4. If this step is reached, no check could be performed for the checklist that was picked. So, without waiting for timer Ta to expire again, select the next checklist in the Running state and return to step #1. If this happens for every single checklist in the Running state, meaning there are no remaining candidate pairs to perform connectivity checks for, abort these steps.
4. このステップに達した場合、選択されたチェックリストのチェックは実行できません。したがって、タイマーTaが再び期限切れになるのを待たずに、実行状態で次のチェックリストを選択して、手順1に戻ります。これがRunning状態のすべてのチェックリストで発生する場合、つまり、接続チェックを実行する候補ペアが残っていない場合は、これらの手順を中止してください。
Once the agent has picked a candidate pair for which a connectivity check is to be performed, the agent starts a check and sends the Binding request from the base associated with the local candidate of the pair to the remote candidate of the pair, as described in Section 7.2.4.
エージェントは、接続性チェックを実行する候補ペアを選択すると、チェックを開始し、ペアのローカル候補に関連付けられているベースからペアのリモート候補にバインディング要求を送信します。セクション7.2.4。
Based on local policy, an agent MAY choose to terminate performing the connectivity checks for one or more checklists in the checklist set at any time. However, only the controlling agent is allowed to conclude ICE (Section 8).
ローカルポリシーに基づいて、エージェントは、チェックリストセット内の1つ以上のチェックリストの接続性チェックの実行をいつでも終了することを選択できます（MAY）。ただし、ICEを終了できるのは制御エージェントのみです（セクション8）。
To compute the message integrity for the check, the agent uses the remote username fragment and password learned from the candidate information obtained from its peer. The local username fragment is known directly by the agent for its own candidate.
チェックのメッセージ整合性を計算するために、エージェントは、ピアから取得した候補情報から学習したリモートのユーザー名フラグメントとパスワードを使用します。ローカルのユーザー名フラグメントは、エージェント自身の候補として直接エージェントに知られています。
Lite implementations skip most of the steps in Section 6 except for verifying the peer's ICE support and determining its role in the ICE processing.
ライトの実装では、ピアのICEサポートの確認とICE処理におけるその役割の決定を除いて、セクション6のほとんどの手順をスキップします。
If the lite implementation is the controlling agent (which will only happen if the peer ICE agent is also a lite implementation), it selects a candidate pair based on the ones in the candidate exchange (for IPv4, there is only ever one pair) and then updates the peer with the new candidate information reflecting that selection, if needed (it is never needed for an IPv4-only host).
ライト実装が制御エージェントである場合（ピアICEエージェントもライト実装である場合にのみ発生します）、候補交換のペアに基づいて候補ペアを選択します（IPv4の場合、ペアは1つしかありません）。次に、必要に応じて、その選択を反映する新しい候補情報でピアを更新します（IPv4のみのホストには必要ありません）。
This section describes how connectivity checks are performed.
このセクションでは、接続性チェックの実行方法について説明します。
An ICE agent MUST be compliant to [RFC5389]. A full implementation acts both as a STUN client and a STUN server, while a lite implementation only acts as a STUN server (as it does not generate connectivity checks).
ICEエージェントは[RFC5389]に準拠している必要があります。完全な実装はSTUNクライアントとSTUNサーバーの両方として機能しますが、liteの実装はSTUNサーバーとしてのみ機能します（接続チェックを生成しないため）。
ICE extends STUN with the attributes: PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These attributes are formally defined in Section 16.1. This section describes the usage of the attributes.
ICEはSTUNを次の属性で拡張します：PRIORITY、USE-CANDIDATE、ICE-CONTROLLED、ICE-CONTROLLING。これらの属性は、セクション16.1で正式に定義されています。このセクションでは、属性の使用法について説明します。
The attributes are only applicable to ICE connectivity checks.
属性はICE接続性チェックにのみ適用されます。
The PRIORITY attribute MUST be included in a Binding request and be set to the value computed by the algorithm in Section 5.1.2 for the local candidate, but with the candidate type preference of peer-reflexive candidates.
PRIORITY属性は、Bindingリクエストに含まれている必要があり、ローカル候補のセクション5.1.2のアルゴリズムによって計算された値に設定されますが、ピア再帰候補の候補タイププリファレンスがあります。
The controlling agent MUST include the USE-CANDIDATE attribute in order to nominate a candidate pair (Section 8.1.1). The controlled agent MUST NOT include the USE-CANDIDATE attribute in a Binding request.
制御エージェントは、候補ペアを指定するために、USE-CANDIDATE属性を含める必要があります（セクション8.1.1）。被制御エージェントは、バインディング要求にUSE-CANDIDATE属性を含めてはなりません（MUST NOT）。
The controlling agent MUST include the ICE-CONTROLLING attribute in a Binding request. The controlled agent MUST include the ICE-CONTROLLED attribute in a Binding request.
制御エージェントは、バインディング要求にICE-CONTROLLING属性を含める必要があります。被制御エージェントは、バインディング要求にICE-CONTROLLED属性を含める必要があります。
The content of either attribute is used as tiebreaker values when an ICE role conflict occurs (Section 7.3.1.1).
いずれかの属性の内容は、ICEロールの競合が発生したときにタイブレーカー値として使用されます（セクション7.3.1.1）。
If the connectivity check is being sent using a relayed local candidate, the client MUST create a permission first if it has not already created one previously. It would have created one previously if it had told the TURN server to create a permission for the given relayed candidate towards the IP address of the remote candidate. To create the permission, the ICE agent follows the procedures defined in [RFC5766]. The permission MUST be created towards the IP address of the remote candidate. It is RECOMMENDED that the agent defer creation of a TURN channel until ICE completes, in which case permissions for connectivity checks are normally created using a CreatePermission request. Once established, the agent MUST keep the permission active until ICE concludes.
中継されたローカル候補を使用して接続チェックが送信されている場合、クライアントは、以前に許可を作成していない場合は、最初に許可を作成する必要があります。リモートの候補者のIPアドレスに向けて、指定されたリレーされた候補者に許可を作成するようにTURNサーバーに指示した場合は、以前に作成されていたはずです。許可を作成するために、ICEエージェントは[RFC5766]で定義されている手順に従います。リモートの候補者のIPアドレスに対して許可を作成する必要があります。エージェントがICEが完了するまでTURNチャネルの作成を延期することをお勧めします。この場合、接続性チェックの権限は通常、CreatePermissionリクエストを使用して作成されます。いったん確立されると、エージェントはICEが完了するまで許可をアクティブに維持しなければなりません。
A connectivity-check Binding request MUST utilize the STUN short-term credential mechanism.
接続性チェックバインディングリクエストは、STUN短期クレデンシャルメカニズムを使用する必要があります。
The username for the credential is formed by concatenating the username fragment provided by the peer with the username fragment of the ICE agent sending the request, separated by a colon (":").
資格情報のユーザー名は、ピアから提供されたユーザー名フラグメントと、リクエストを送信するICEエージェントのユーザー名フラグメントを、コロン（ "："）で区切って連結して形成されます。
The password is equal to the password provided by the peer.
パスワードは、ピアから提供されたパスワードと同じです。
For example, consider the case where ICE agent L is the initiating agent and ICE agent R is the responding agent. Agent L included a username fragment of LFRAG for its candidates and a password of LPASS. Agent R provided a username fragment of RFRAG and a password of RPASS. A connectivity check from L to R utilizes the username RFRAG:LFRAG and a password of RPASS. A connectivity check from R to L utilizes the username LFRAG:RFRAG and a password of LPASS. The responses utilize the same usernames and passwords as the requests (note that the USERNAME attribute is not present in the response).
たとえば、ICEエージェントLが開始エージェントであり、ICEエージェントRが応答エージェントである場合を考えます。エージェントLには、候補者用のLFRAGのユーザー名フラグメントとLPASSのパスワードが含まれていました。エージェントRは、RFRAGのユーザー名フラグメントとRPASSのパスワードを提供しました。 LからRへの接続チェックでは、ユーザー名RFRAG：LFRAGとパスワードRPASSを使用します。 RからLへの接続チェックは、ユーザー名LFRAG：RFRAGとパスワードLPASSを使用します。応答は、要求と同じユーザー名とパスワードを使用します（応答にUSERNAME属性が存在しないことに注意してください）。
If the agent is using Differentiated Services Code Point (DSCP) markings [RFC2475] in data packets that it will send, the agent SHOULD apply the same markings to Binding requests and responses that it will send.
エージェントが送信するデータパケットでDiffServコードポイント（DSCP）マーキング[RFC2475]を使用している場合、エージェントは、送信するバインド要求と応答に同じマーキングを適用する必要があります（SHOULD）。
If multiple DSCP markings are used on the data packets, the agent SHOULD choose one of them for use with the connectivity check.
データパケットで複数のDSCPマーキングが使用されている場合、エージェントは、接続チェックで使用するためにそのうちの1つを選択する必要があります（SHOULD）。
A connectivity check is generated by sending a Binding request from the base associated with a local candidate to a remote candidate. [RFC5389] describes how Binding requests are constructed and generated.
接続性チェックは、ローカル候補に関連付けられたベースからリモート候補にバインディング要求を送信することによって生成されます。 [RFC5389]は、Bindingリクエストがどのように構築および生成されるかを説明しています。
Support for backwards compatibility with RFC 3489 MUST NOT be assumed when performing connectivity checks. The FINGERPRINT mechanism MUST be used for connectivity checks.
接続性チェックを実行するとき、RFC 3489との下位互換性のサポートを前提としてはなりません。接続チェックにはFINGERPRINTメカニズムを使用する必要があります。
This section defines additional procedures for processing Binding responses specific to ICE connectivity checks.
このセクションでは、ICE接続性チェックに固有のバインディング応答を処理するための追加手順を定義します。
When a Binding response is received, it is correlated to the corresponding Binding request using the transaction ID [RFC5389], which then associates the response with the candidate pair for which the Binding request was sent. After that, the response is processed according to the procedures for a role conflict, a failure, or a success, according to the procedures below.
バインディング応答が受信されると、それはトランザクションID [RFC5389]を使用して対応するバインディング要求に関連付けられ、次に、バインディング要求が送信された候補ペアに応答が関連付けられます。その後、以下の手順に従って、役割の競合、失敗、成功の手順に従って応答が処理されます。
If the Binding request generates a 487 (Role Conflict) error response (Section 7.3.1.1), and if the ICE agent included an ICE-CONTROLLED attribute in the request, the agent MUST switch to the controlling role. If the agent included an ICE-CONTROLLING attribute in the request, the agent MUST switch to the controlled role.
バインディング要求が487（ロールの競合）エラー応答を生成する場合（セクション7.3.1.1）、ICEエージェントが要求にICE-CONTROLLED属性を含めた場合、エージェントは制御ロールに切り替えなければなりません（MUST）。エージェントがリクエストにICE-CONTROLLING属性を含めた場合、エージェントは制御されたロールに切り替える必要があります。
Once the agent has switched its role, the agent MUST add the candidate pair whose check generated the 487 error response to the triggered-check queue associated with the checklist to which the pair belongs, and set the candidate pair state to Waiting. When the triggered connectivity check is later performed, the ICE-CONTROLLING/ ICE-CONTROLLED attribute of the Binding request will indicate the agent's new role. The agent MUST change the tiebreaker value.
エージェントがその役割を切り替えると、エージェントは、チェックが487エラー応答を生成した候補ペアを、ペアが属するチェックリストに関連付けられたトリガーチェックキューに追加し、候補ペアの状態を待機中に設定する必要があります。トリガーされた接続性チェックが後で実行されると、BindingリクエストのICE-CONTROLLING / ICE-CONTROLLED属性は、エージェントの新しい役割を示します。エージェントはタイブレーカーの値を変更する必要があります。
NOTE: A role switch requires an agent to recompute pair priorities (Section 6.1.2.3), since the priority values depend on the role.
注：優先度の値はロールによって異なるため、ロールの切り替えでは、エージェントがペアの優先度を再計算する必要があります（セクション6.1.2.3）。
NOTE: A role switch will also impact whether the agent is responsible for nominating candidate pairs, and whether the agent is responsible for initiating the exchange of the updated candidate information with the peer once ICE is concluded.
注：役割の切り替えは、エージェントが候補ペアの指名を担当するかどうか、およびICEが完了した後、エージェントがピアとの更新された候補情報の交換を開始することを担当するかどうかにも影響します。
This section describes cases when the candidate pair state is set to Failed.
このセクションでは、候補ペアの状態が失敗に設定されている場合について説明します。
NOTE: When the ICE agent sets the candidate pair state to Failed as a result of a connectivity-check error, the agent does not change the states of other candidate pairs with the same foundation.
注：接続性チェックエラーの結果としてICEエージェントが候補ペアの状態をFailedに設定しても、エージェントは同じ基盤を持つ他の候補ペアの状態を変更しません。
The ICE agent MUST check that the source and destination transport addresses in the Binding request and response are symmetric. That is, the source IP address and port of the response MUST be equal to the destination IP address and port to which the Binding request was sent, and the destination IP address and port of the response MUST be equal to the source IP address and port from which the Binding request was sent. If the addresses are not symmetric, the agent MUST set the candidate pair state to Failed.
ICEエージェントは、Binding要求と応答のソースと宛先のトランスポートアドレスが対称であることを確認する必要があります。つまり、応答の送信元IPアドレスとポートは、Binding要求の送信先の宛先IPアドレスとポートに等しくなければならず、応答の宛先IPアドレスとポートは、送信元IPアドレスとポートに等しくなければなりません（MUST）。 Bindingリクエストの送信元。アドレスが対称でない場合、エージェントは候補ペアの状態を失敗に設定する必要があります。
An ICE agent MAY support processing of ICMP errors for connectivity checks. If the agent supports processing of ICMP errors, and if a Binding request generates a hard ICMP error, the agent SHOULD set the state of the candidate pair to Failed. Implementers need to be aware that ICMP errors can be used as a method for Denial-of-Service (DoS) attacks when making a decision on how and if to process ICMP errors.
ICEエージェントは、接続性チェックのICMPエラーの処理をサポートする場合があります。エージェントがICMPエラーの処理をサポートし、BindingリクエストがハードICMPエラーを生成する場合、エージェントは候補ペアの状態をFailedに設定する必要があります（SHOULD）。実装者は、ICMPエラーを処理する方法とかどうかを決定するときに、サービス拒否（DoS）攻撃の方法としてICMPエラーを使用できることを認識する必要があります。
If the Binding request transaction times out, the ICE agent MUST set the candidate pair state to Failed.
バインディング要求トランザクションがタイムアウトした場合、ICEエージェントは候補ペアの状態を失敗に設定する必要があります。
If the Binding request generates a STUN error response that is unrecoverable [RFC5389], the ICE agent SHOULD set the candidate pair state to Failed.
バインディングリクエストが回復不可能なSTUNエラー応答[RFC5389]を生成する場合、ICEエージェントは候補ペアの状態を失敗に設定する必要があります（SHOULD）。
A connectivity check is considered a success if each of the following criteria is true:
次の各基準に該当する場合、接続性チェックは成功と見なされます。
o The Binding request generated a success response; and
o Bindingリクエストは成功レスポンスを生成しました。そして
o The source and destination transport addresses in the Binding request and response are symmetric.
o Binding要求と応答の送信元と宛先のトランスポートアドレスは対称的です。
If a check is considered a success, the ICE agent performs (in order) the actions described in the following sections.
チェックが成功したと見なされると、ICEエージェントは、次のセクションで説明するアクションを（順番に）実行します。
The ICE agent MUST check the mapped address from the STUN response. If the transport address does not match any of the local candidates that the agent knows about, the mapped address represents a new candidate: a peer-reflexive candidate. Like other candidates, a peer-reflexive candidate has a type, base, priority, and foundation. They are computed as follows:
ICEエージェントは、STUN応答からマッピングされたアドレスを確認する必要があります。トランスポートアドレスが、エージェントが認識しているローカル候補のいずれとも一致しない場合、マッピングアドレスは新しい候補、つまりピアリフレクティブ候補を表します。他の候補者と同様に、ピアリフレクティブ候補者には、タイプ、ベース、優先順位、および基盤があります。これらは次のように計算されます。
o The type is peer reflexive.
o タイプはピアリフレクティブです。
o The base is the local candidate of the candidate pair from which the Binding request was sent.
o ベースは、Bindingリクエストが送信された候補ペアのローカル候補です。
o The priority is the value of the PRIORITY attribute in the Binding request.
o 優先度は、BindingリクエストのPRIORITY属性の値です。
o The foundation is described in Section 5.1.1.3.
o 基盤については、セクション5.1.1.3で説明します。
The peer-reflexive candidate is then added to the list of local candidates for the data stream. The username fragment and password are the same as for all other local candidates for that data stream.
次に、ピア・リフレクティブ候補が、データ・ストリームのローカル候補のリストに追加されます。ユーザー名のフラグメントとパスワードは、そのデータストリームの他のすべてのローカル候補と同じです。
The ICE agent does not need to pair the peer-reflexive candidate with remote candidates, as a valid pair will be created due to the procedures in Section 7.2.5.3.2. If an agent wishes to pair the peer-reflexive candidate with remote candidates other than the one in the valid pair that will be generated, the agent MAY provide updated candidate information to the peer that includes the peer-reflexive candidate. This will cause the peer-reflexive candidate to be paired with all other remote candidates.
セクション7.2.5.3.2の手順により有効なペアが作成されるため、ICEエージェントは、ピア再帰候補をリモート候補とペアにする必要はありません。エージェントがピア再帰候補を生成される有効なペアの1つ以外のリモート候補とペアにすることを望む場合、エージェントはピア再帰候補を含むピアに更新された候補情報を提供してもよい（MAY）。これにより、ピアリフレクティブ候補が他のすべてのリモート候補とペアになります。
The ICE agent constructs a candidate pair whose local candidate equals the mapped address of the response and whose remote candidate equals the destination address to which the request was sent. This is called a "valid pair".
ICEエージェントは、ローカル候補が応答のマッピングアドレスと等しく、リモート候補が要求の送信先の宛先アドレスと等しい候補ペアを作成します。これは「有効なペア」と呼ばれます。
The valid pair might equal the pair that generated the connectivity check, a different pair in the checklist, or a pair currently not in the checklist.
有効なペアは、接続性チェックを生成したペア、チェックリストの別のペア、または現在チェックリストにないペアと等しい場合があります。
The agent maintains a separate list, referred to as the "valid list". There is a valid list for each checklist in the checklist set. The valid list will contain valid pairs. Initially, each valid list is empty.
エージェントは、「有効なリスト」と呼ばれる別のリストを保持します。チェックリストセットの各チェックリストに有効なリストがあります。有効なリストには、有効なペアが含まれます。最初は、各有効なリストは空です。
Each valid pair within the valid list has a flag, called the "nominated flag". When a valid pair is added to a valid list, the flag value is set to 'false'.
有効なリスト内の各有効なペアには、「指定されたフラグ」と呼ばれるフラグがあります。有効なペアが有効なリストに追加されると、フラグ値は「false」に設定されます。
The valid pair will be added to a valid list as follows:
次のように、有効なペアが有効なリストに追加されます。
1. If the valid pair equals the pair that generated the check, the pair is added to the valid list associated with the checklist to which the pair belongs; or
1. 有効なペアがチェックを生成したペアと等しい場合、ペアは、ペアが属するチェックリストに関連付けられた有効なリストに追加されます。または
2. If the valid pair equals another pair in a checklist, that pair is added to the valid list associated with the checklist of that pair. The pair that generated the check is not added to a valid list; or
2. 有効なペアがチェックリストの別のペアと等しい場合、そのペアは、そのペアのチェックリストに関連付けられた有効なリストに追加されます。チェックを生成したペアは有効なリストに追加されません。または
3. If the valid pair is not in any checklist, the agent computes the priority for the pair based on the priority of each candidate, using the algorithm in Section 6.1.2. The priority of the local candidate depends on its type. Unless the type is peer reflexive, the priority is equal to the priority signaled for that candidate in the candidate exchange. If the type is peer reflexive, it is equal to the PRIORITY attribute the agent placed in the Binding request that just completed. The priority of the remote candidate is taken from the candidate information of the peer. If the candidate does not appear there, then the check has been a triggered check to a new remote candidate. In that case, the priority is taken as the value of the PRIORITY attribute in the Binding request that triggered the check that just completed. The pair is then added to the valid list.
3. 有効なペアがチェックリストにない場合、エージェントは、セクション6.1.2のアルゴリズムを使用して、各候補の優先度に基づいてペアの優先度を計算します。ローカル候補者の優先順位は、そのタイプによって異なります。タイプがピアリフレクティブでない限り、優先度は候補交換でその候補に対して通知された優先度と同じです。タイプがピアリフレクティブである場合、これは、完了したバインディングリクエストにエージェントが配置したPRIORITY属性と同じです。リモート候補の優先順位は、ピアの候補情報から取得されます。候補がそこに表示されない場合、チェックは新しいリモート候補へのトリガーされたチェックです。その場合、優先度は、完了したばかりのチェックをトリガーしたBindingリクエストのPRIORITY属性の値として使用されます。次に、ペアが有効なリストに追加されます。
NOTE: It will be very common that the valid pair will not be in any checklist. Recall that the checklist has pairs whose local candidates are never reflexive; those pairs had their local candidates converted to the base of the reflexive candidates and were then pruned if they were redundant. When the response to the Binding request arrives, the mapped address will be reflexive if there is a NAT between the two. In that case, the valid pair will have a local candidate that doesn't match any of the pairs in the checklist.
注：有効なペアがチェックリストにないことは非常に一般的です。チェックリストには、ローカル候補が再帰的ではないペアがあることを思い出してください。これらのペアは、ローカル候補を再帰候補のベースに変換し、冗長である場合は枝刈りしました。バインディング要求への応答が到着すると、2つの間にNATがある場合、マッピングされたアドレスは再帰的です。その場合、有効なペアには、チェックリストのどのペアとも一致しないローカル候補があります。
The ICE agent sets the states of both the candidate pair that generated the check and the constructed valid pair (which may be different) to Succeeded.
ICEエージェントは、チェックを生成した候補ペアと構成された有効なペア（異なる場合があります）の両方の状態を成功に設定します。
The agent MUST set the states for all other Frozen candidate pairs in all checklists with the same foundation to Waiting.
エージェントは、同じ基盤を持つすべてのチェックリスト内の他のすべての凍結候補ペアの状態を待機に設定する必要があります。
NOTE: Within a given checklist, candidate pairs with the same foundations will typically have different component ID values.
注：特定のチェックリスト内で、同じ基盤を持つ候補ペアは通常、異なるコンポーネントID値を持ちます。
If the controlling agent sends a Binding request with the USE-CANDIDATE attribute set, and if the ICE agent receives a successful response to the request, the agent sets the nominated flag of the pair to true. If the request fails (Section 7.2.5.2), the agent MUST remove the candidate pair from the valid list, set the candidate pair state to Failed, and set the checklist state to Failed.
制御エージェントがUSE-CANDIDATE属性が設定されたバインディング要求を送信し、ICEエージェントが要求に対する正常な応答を受信した場合、エージェントはペアの指定されたフラグをtrueに設定します。リクエストが失敗した場合（セクション7.2.5.2）、エージェントは候補ペアを有効なリストから削除し、候補ペアの状態をFailedに設定し、チェックリストの状態をFailedに設定する必要があります。
If the controlled agent receives a successful response to a Binding request sent by the agent, and that Binding request was triggered by a received Binding request with the USE-CANDIDATE attribute set (Section 7.3.1.4), the agent sets the nominated flag of the pair to true. If the triggered request fails, the agent MUST remove the candidate pair from the valid list, set the candidate pair state to Failed, and set the checklist state to Failed.
制御されたエージェントが、エージェントによって送信されたバインディング要求に対する正常な応答を受信し、そのバインディング要求が、USE-CANDIDATE属性が設定された受信されたバインディング要求によってトリガーされた場合（セクション7.3.1.4）、エージェントは、 trueとペアにします。トリガーされたリクエストが失敗した場合、エージェントは候補ペアを有効なリストから削除し、候補ペアの状態を失敗に設定し、チェックリストの状態を失敗に設定する必要があります。
Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component (Section 8).
指定されたフラグがデータストリームのコンポーネントに設定されると、そのコンポーネントのICE処理が終了します（セクション8）。
Regardless of whether a connectivity check was successful or failed, the completion of the check may require updating of checklist states. For each checklist in the checklist set, if all of the candidate pairs are in either Failed or Succeeded state, and if there is not a valid pair in the valid list for each component of the data stream associated with the checklist, the state of the checklist is set to Failed. If there is a valid pair for each component in the valid list, the state of the checklist is set to Succeeded.
接続性チェックが成功したか失敗したかに関係なく、チェックの完了にはチェックリストの状態の更新が必要になる場合があります。チェックリストセットの各チェックリストについて、すべての候補ペアがFailedまたはSucceeded状態であり、チェックリストに関連付けられたデータストリームの各コンポーネントの有効なリストに有効なペアがない場合、チェックリストの状態チェックリストは「失敗」に設定されています。有効なリスト内の各コンポーネントに有効なペアがある場合、チェックリストの状態は成功に設定されます。
An ICE agent (lite or full) MUST be prepared to receive Binding requests on the base of each candidate it included in its most recent candidate exchange.
ICEエージェント（ライトまたはフル）は、最新の候補者交換に含まれる各候補者に基づいてバインディング要求を受信する準備ができていなければなりません。
The agent MUST use the short-term credential mechanism (i.e., the MESSAGE-INTEGRITY attribute) to authenticate the request and perform a message integrity check. Likewise, the short-term credential mechanism MUST be used for the response. The agent MUST consider the username to be valid if it consists of two values separated by a colon, where the first value is equal to the username fragment generated by the agent in a candidate exchange for a session in progress. It is possible (and in fact very likely) that the initiating agent will receive a Binding request prior to receiving the candidates from its peer. If this happens, the agent MUST immediately generate a response (including computation of the mapped address as described in Section 7.3.1.2). The agent has sufficient information at this point to generate the response; the password from the peer is not required. Once the answer is received, it MUST proceed with the remaining steps required; namely, see Sections 7.3.1.3, 7.3.1.4, and 7.3.1.5 for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several pairs to be queued up in the triggered-check queue.
エージェントは、短期的な認証メカニズム（つまり、MESSAGE-INTEGRITY属性）を使用して、リクエストを認証し、メッセージの整合性チェックを実行する必要があります（MUST）。同様に、短期的な資格メカニズムを応答に使用する必要があります。エージェントは、ユーザー名がコロンで区切られた2つの値で構成されている場合、ユーザー名が有効であると見なさなければなりません。ピアから候補を受信する前に、開始エージェントがバインディング要求を受信する可能性があります（実際、非常に可能性が高いです）。これが発生した場合、エージェントはすぐに応答を生成する必要があります（セクション7.3.1.2で説明されているマッピングアドレスの計算を含む）。この時点で、エージェントは応答を生成するのに十分な情報を持っています。ピアからのパスワードは必要ありません。回答を受け取ったら、必要な残りの手順に進む必要があります。つまり、完全な実装については、セクション7.3.1.3、7.3.1.4、および7.3.1.5を参照してください。回答の前に複数のSTUN要求が受信される場合、これにより、いくつかのペアがトリガーされたチェックキューにキューイングされる可能性があります。
An agent MUST NOT utilize the ALTERNATE-SERVER mechanism and MUST NOT support the backwards-compatibility mechanisms defined in RFC 5389 (for working with the protocol in RFC 3489). It MUST utilize the FINGERPRINT mechanism.
エージェントは、ALTERNATE-SERVERメカニズムを利用してはならず（MUST NOT）、RFC 5389で定義された後方互換性メカニズムをサポートしてはなりません（RFC 3489のプロトコルを操作するため）。 FINGERPRINTメカニズムを使用する必要があります。
If the agent is using DSCP markings [RFC2475] in its data packets, it SHOULD apply the same markings to Binding responses. The same would apply to any Layer 2 markings the endpoint might be applying to data packets.
エージェントがデータパケットでDSCPマーキング[RFC2475]を使用している場合、バインディング応答に同じマーキングを適用する必要があります（SHOULD）。エンドポイントがデータパケットに適用する可能性のあるすべてのレイヤ2マーキングにも同じことが当てはまります。
This subsection defines the additional server procedures applicable to full implementations, when the full implementation accepts the Binding request.
このサブセクションでは、完全な実装がバインディング要求を受け入れるときに、完全な実装に適用可能な追加のサーバープロシージャを定義します。
In certain usages of ICE (such as 3PCC), both ICE agents may end up choosing the same role, resulting in a role conflict. The section describes a mechanism for detecting and repairing role conflicts. The usage document MUST specify whether this mechanism is needed.
ICEの特定の使用法（3PCCなど）では、両方のICEエージェントが同じ役割を選択してしまい、役割の競合が発生する場合があります。このセクションでは、役割の競合を検出して修復するメカニズムについて説明します。使用法ドキュメントでは、このメカニズムが必要かどうかを指定する必要があります。
An agent MUST examine the Binding request for either the ICE-CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these procedures:
エージェントは、ICE-CONTROLLINGまたはICE-CONTROLLED属性のいずれかのバインディング要求を検査する必要があります。次の手順に従う必要があります。
o If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request:
o エージェントが制御ロールにあり、ICE-CONTROLLING属性が要求に存在する場合：
* If the agent's tiebreaker value is larger than or equal to the contents of the ICE-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role.
* エージェントのタイブレーカー値がICE-CONTROLLING属性の内容以上の場合、エージェントはバインディングエラー応答を生成し、値487（役割の競合）を持つERROR-CODE属性を含めますが、その役割は保持します。
* If the agent's tiebreaker value is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role.
* エージェントのタイブレーカー値がICE-CONTROLLING属性の内容よりも小さい場合、エージェントは制御された役割に切り替えます。
o If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request:
o エージェントが制御されたロールにあり、ICE-CONTROLLED属性がリクエストに存在する場合：
* If the agent's tiebreaker value is larger than or equal to the contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role.
* エージェントのタイブレーカー値がICE-CONTROLLED属性の内容以上の場合、エージェントは制御ロールに切り替えます。
* If the agent's tiebreaker value is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role.
* エージェントのタイブレーカー値がICE-CONTROLLED属性の内容よりも小さい場合、エージェントはバインディングエラー応答を生成し、値487（役割の競合）を持つERROR-CODE属性を含めますが、その役割は保持します。
o If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or if the agent was in the controlling role and the ICE-CONTROLLED attribute was present in the request, there is no conflict.
o エージェントが制御された役割にあり、ICE-CONTROLLING属性が要求に存在する場合、またはエージェントが制御する役割にあり、ICE-CONTROLLED属性が要求に存在した場合、競合はありません。
A change in roles will require an agent to recompute pair priorities (Section 6.1.2.3), since those priorities are a function of role. The change in role will also impact whether the agent is responsible for selecting nominated pairs and initiating exchange with updated candidate information upon conclusion of ICE.
ロールの変更は、エージェントがペアの優先度を再計算することを必要とします（セクション6.1.2.3）。これらの優先度はロールの関数であるためです。役割の変更は、指名されたペアを選択し、ICEの終了時に更新された候補者情報との交換を開始する責任があるかどうかにも影響します。
The remaining subsections in Section 7.3.1 are followed if the agent generated a successful response to the Binding request, even if the agent changed roles.
エージェントが役割を変更した場合でも、エージェントがバインディング要求に対して正常な応答を生成した場合は、セクション7.3.1の残りのサブセクションが続きます。
For requests received on a relayed candidate, the source transport address used for STUN processing (namely, generation of the XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the TURN server. That source transport address will be present in the XOR-PEER-ADDRESS attribute of a Data Indication message, if the Binding request was delivered through a Data Indication. If the Binding request was delivered through a ChannelData message, the source transport address is the one that was bound to the channel.
リレーされた候補で受信された要求の場合、STUN処理（つまり、XOR-MAPPED-ADDRESS属性の生成）に使用されるソーストランスポートアドレスは、TURNサーバーから見たトランスポートアドレスです。バインディング要求がデータ表示を介して配信された場合、そのソーストランスポートアドレスは、データ表示メッセージのXOR-PEER-ADDRESS属性に存在します。 BindingDataがChannelDataメッセージを介して配信された場合、ソーストランスポートアドレスはチャネルにバインドされたアドレスです。
If the source transport address of the request does not match any existing remote candidates, it represents a new peer-reflexive remote candidate. This candidate is constructed as follows:
要求のソーストランスポートアドレスが既存のリモート候補と一致しない場合、それは新しいピア再帰リモート候補を表します。この候補者は次のように構成されています。
o The type is peer reflexive.
o タイプはピアリフレクティブです。
o The priority is the value of the PRIORITY attribute in the Binding request.
o 優先度は、BindingリクエストのPRIORITY属性の値です。
o The foundation is an arbitrary value, different from the foundations of all other remote candidates. If any subsequent candidate exchanges contain this peer-reflexive candidate, it will signal the actual foundation for the candidate.
o 基盤は任意の値であり、他のすべてのリモート候補者の基盤とは異なります。後続の候補交換にこのピアリフレクティブ候補が含まれている場合は、候補の実際の基盤を示します。
o The component ID is the component ID of the local candidate to which the request was sent.
o コンポーネントIDは、リクエストが送信されたローカル候補のコンポーネントIDです。
This candidate is added to the list of remote candidates. However, the ICE agent does not pair this candidate with any local candidates.
この候補者は、リモート候補者のリストに追加されます。ただし、ICEエージェントはこの候補をローカルの候補とペアにしません。
Next, the agent constructs a pair whose local candidate has the transport address (as seen by the agent) on which the STUN request was received and a remote candidate equal to the source transport address where the request came from (which may be the peer-reflexive remote candidate that was just learned). The local candidate will be either a host candidate (for cases where the request was not received through a relay) or a relayed candidate (for cases where it is received through a relay). The local candidate can never be a server-reflexive candidate. Since both candidates are known to the agent, it can obtain their priorities and compute the candidate pair priority. This pair is then looked up in the checklist. There can be one of several outcomes:
次に、エージェントは、STUN要求が受信されたトランスポートアドレス（エージェントから見た）を持つローカル候補と、要求が送信されたソーストランスポートアドレス（ピアである可能性があります）に等しいリモート候補を持つペアを構築します。学習したばかりの再帰的なリモート候補者）。ローカル候補は、ホスト候補（要求がリレーを介して受信されなかった場合）またはリレー候補（リレーを介して受信された場合）のいずれかになります。ローカル候補者がサーバー再帰候補者になることはありません。エージェントは両方の候補を認識しているため、エージェントの優先順位を取得し、候補ペアの優先順位を計算できます。次に、このペアがチェックリストで調べられます。いくつかの結果のうちの1つが考えられます。
o When the pair is already on the checklist:
o ペアが既にチェックリストにある場合：
* If the state of that pair is Succeeded, nothing further is done.
* そのペアの状態が成功した場合、それ以上何も行われません。
* If the state of that pair is In-Progress, the agent cancels the In-Progress transaction. Cancellation means that the agent will not retransmit the Binding requests associated with the connectivity-check transaction, will not treat the lack of response to be a failure, but will wait the duration of the transaction timeout for a response. In addition, the agent MUST enqueue the pair in the triggered checklist associated with the checklist, and set the state of the pair to Waiting, in order to trigger a new connectivity check of the pair. Creating a new connectivity check enables validating In-Progress pairs as soon as possible, without having to wait for retransmissions of the Binding requests associated with the original connectivity-check transaction.
* そのペアの状態が進行中の場合、エージェントは進行中のトランザクションをキャンセルします。キャンセルとは、エージェントが接続性チェックトランザクションに関連付けられたバインディングリクエストを再送信せず、応答がないことを障害として処理せずに、トランザクションタイムアウトが続くまで応答を待機することを意味します。さらに、エージェントは、ペアの新しい接続チェックをトリガーするために、チェックリストに関連付けられたトリガーされたチェックリストにペアをエンキューし、ペアの状態を待機に設定する必要があります。新しい接続性チェックを作成すると、元の接続性チェックトランザクションに関連付けられたバインディングリクエストの再送信を待たずに、できるだけ早く進行中のペアを検証できます。
* If the state of that pair is Waiting, Frozen, or Failed, the agent MUST enqueue the pair in the triggered checklist associated with the checklist (if not already present), and set the state of the pair to Waiting, in order to trigger a new connectivity check of the pair. Note that a state change of the pair from Failed to Waiting might also trigger a state change of the associated checklist.
* そのペアの状態がWaiting、Frozen、またはFailedの場合、エージェントは、チェックリストに関連付けられているトリガーされたチェックリスト（まだ存在しない場合）にペアをエンキューし、ペアの状態をWaitingに設定して、ペアの新しい接続性チェック。ペアの状態がFailedからWaitingに変わると、関連するチェックリストの状態が変わることもあります。
These steps are done to facilitate rapid completion of ICE when both agents are behind NAT.
これらの手順は、両方のエージェントがNATの背後にある場合にICEの迅速な完了を容易にするために行われます。
o If the pair is not already on the checklist:
o ペアがまだチェックリストにない場合：
* The pair is inserted into the checklist based on its priority.
* ペアは、優先度に基づいてチェックリストに挿入されます。
* Its state is set to Waiting.
* その状態は待機中に設定されます。
* The pair is enqueued into the triggered-check queue.
* ペアは、トリガーされたチェックキューにエンキューされます。
When a triggered check is to be sent, it is constructed and processed as described in Section 7.2.4. These procedures require the agent to know the transport address, username fragment, and password for the peer. The username fragment for the remote candidate is equal to the part after the colon of the USERNAME in the Binding request that was just received. Using that username fragment, the agent can check the candidates received from its peer (there may be more than one in cases of forking) and find this username fragment. The corresponding password is then picked.
トリガーされたチェックが送信される場合、セクション7.2.4で説明されているようにチェックが作成および処理されます。これらの手順では、エージェントがピアのトランスポートアドレス、ユーザー名フラグメント、およびパスワードを知っている必要があります。リモート候補のユーザー名フラグメントは、受信したBindingリクエストのUSERNAMEのコロンの後の部分と同じです。そのユーザー名フラグメントを使用して、エージェントはそのピアから受信した候補（フォーキングの場合は複数ある可能性があります）をチェックして、このユーザー名フラグメントを見つけることができます。次に、対応するパスワードが選択されます。
If the controlled agent receives a Binding request with the USE-CANDIDATE attribute set, and if the ICE agent accepts the request, the following action is based on the state of the pair computed in Section 7.3.1.4:
被制御エージェントがUSE-CANDIDATE属性が設定されたバインディング要求を受信し、ICEエージェントがその要求を受け入れる場合、次のアクションは7.3.1.4で計算されたペアの状態に基づいています。
o If the state of this pair is Succeeded, it means that the check previously sent by this pair produced a successful response and generated a valid pair (Section 7.2.5.3.2). The agent sets the nominated flag value of the valid pair to true.
o このペアの状態がSucceededの場合、このペアによって以前に送信されたチェックが成功した応答を生成し、有効なペアを生成したことを意味します（セクション7.2.5.3.2）。エージェントは、有効なペアの指定されたフラグ値をtrueに設定します。
o If the received Binding request triggered a new check to be enqueued in the triggered-check queue (Section 7.3.1.4), once the check is sent and if it generates a successful response, and generates a valid pair, the agent sets the nominated flag of the pair to true. If the request fails (Section 7.2.5.2), the agent MUST remove the candidate pair from the valid list, set the candidate pair state to Failed, and set the checklist state to Failed.
o 受信したバインディング要求がトリガーされたチェックキュー（7.3.1.4）にエンキューされる新しいチェックをトリガーした場合、チェックが送信され、それが成功した応答を生成し、有効なペアを生成すると、エージェントは指定されたフラグを設定しますペアのtrueに。リクエストが失敗した場合（セクション7.2.5.2）、エージェントは候補ペアを有効なリストから削除し、候補ペアの状態をFailedに設定し、チェックリストの状態をFailedに設定する必要があります。
If the controlled agent does not accept the request from the controlling agent, the controlled agent MUST reject the nomination request with an appropriate error code response (e.g., 400) [RFC5389].
被制御エージェントが制御エージェントからの要求を受け入れない場合、被制御エージェントは適切なエラーコード応答（400など）[RFC5389]を使用して指名要求を拒否する必要があります。
Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component. See Section 8.
指名されたフラグがデータストリームのコンポーネントに設定されると、そのコンポーネントのICE処理が終了します。セクション8を参照してください。
If the controlled agent receives a Binding request with the USE-CANDIDATE attribute set, and if the ICE agent accepts the request, the agent constructs a candidate pair whose local candidate has the transport address on which the request was received, and whose remote candidate is equal to the source transport address of the request that was received. This candidate pair is assigned an arbitrary priority and placed into the valid list of the associated checklist. The agent sets the nominated flag for that pair to true.
被制御エージェントがUSE-CANDIDATE属性が設定されたバインディング要求を受信し、ICEエージェントが要求を受け入れる場合、エージェントは、ローカル候補が要求を受信したトランスポートアドレスを持ち、リモート候補がその候補である候補ペアを作成します。受信したリクエストのソーストランスポートアドレスと同じです。この候補ペアには任意の優先順位が割り当てられ、関連するチェックリストの有効なリストに配置されます。エージェントは、そのペアの指定されたフラグをtrueに設定します。
Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component. See Section 8.
指名されたフラグがデータストリームのコンポーネントに設定されると、そのコンポーネントのICE処理が終了します。セクション8を参照してください。
This section describes how an ICE agent completes ICE.
このセクションでは、ICEエージェントがICEを完了する方法について説明します。
Concluding ICE involves nominating pairs by the controlling agent and updating state machinery.
ICEの終了には、制御エージェントによるペアの指名と状態機械の更新が含まれます。
Prior to nominating, the controlling agent lets connectivity checks continue until some stopping criterion is met. After that, based on an evaluation criterion, the controlling agent picks a pair among the valid pairs in the valid list for nomination.
指名する前に、制御エージェントは、いくつかの停止基準が満たされるまで接続チェックを続行させます。その後、評価基準に基づいて、制御エージェントは有効なリスト内の有効なペアの中から1つのペアを選択して指名します。
Once the controlling agent has picked a valid pair for nomination, it repeats the connectivity check that produced this valid pair (by enqueueing the pair that generated the check into the triggered-check queue), this time with the USE-CANDIDATE attribute (Section 7.2.5.3.4). The procedures for the controlled agent are described in Section 7.3.1.5.
制御エージェントが候補として有効なペアを選択すると、このチェックを生成したペアをトリガーチェックキューにエンキューすることにより、この有効なペアを生成した接続性チェックを繰り返します。今回は、USE-CANDIDATE属性を使用します（7.2節）。 .5.3.4）。管理エージェントの手順については、7.3.1.5項で説明しています。
Eventually, if the nominations succeed, both the controlling and controlled agents will have a single nominated pair in the valid list for each component of the data stream. Once an ICE agent sets the state of the checklist to Completed (when there is a nominated pair for each component of the data stream), that pair becomes the selected pair for that agent and is used for sending and receiving data for that component of the data stream.
最終的に、ノミネートが成功すると、制御エージェントと被制御エージェントの両方が、データストリームの各コンポーネントの有効なリストに単一のノミネートペアを持ちます。 ICEエージェントがチェックリストの状態を完了に設定すると（データストリームの各コンポーネントに指定されたペアがある場合）、そのペアはそのエージェントの選択されたペアになり、そのコンポーネントのデータの送受信に使用されますデータストリーム。
If an agent is not able to produce selected pairs for each component of a data stream, the agent MUST take proper actions for informing the other agent, e.g., by removing the stream. The exact actions are outside the scope of this specification.
エージェントがデータストリームの各コンポーネントに対して選択されたペアを生成できない場合、エージェントは、たとえばストリームを削除することによって、他のエージェントに通知するための適切なアクションを実行する必要があります。正確なアクションは、この仕様の範囲外です。
The criteria for stopping the connectivity checks and for picking a pair for nomination are outside the scope of this specification. They are a matter of local optimization. The only requirement is that the agent MUST eventually pick one and only one candidate pair and generate a check for that pair with the USE-CANDIDATE attribute set.
接続性チェックを停止するための基準と指名のためのペアを選択するための基準は、この仕様の範囲外です。それらはローカル最適化の問題です。唯一の要件は、エージェントが最終的に1つだけの候補ペアを選択し、USE-CANDIDATE属性セットでそのペアのチェックを生成する必要があることです。
Once the controlling agent has successfully nominated a candidate pair (Section 7.2.5.3.4), the agent MUST NOT nominate another pair for same component of the data stream within the ICE session. Doing so requires an ICE restart.
制御エージェントが候補ペアの指名に成功すると（セクション7.2.5.3.4）、エージェントはICEセッション内のデータストリームの同じコンポーネントに対して別のペアを指名してはなりません（MUST NOT）。これを行うには、ICEを再起動する必要があります。
A controlling agent that does not support this specification (i.e., it is implemented according to RFC 5245) might nominate more than one candidate pair. This was referred to as "aggressive nomination" in RFC 5245. If more than one candidate pair is nominated by the controlling agent, and if the controlled agent accepts multiple nominations requests, the agents MUST produce the selected pairs and use the pairs with the highest priority.
この仕様をサポートしない（つまり、RFC 5245に従って実装されている）制御エージェントは、複数の候補ペアを指定する場合があります。これはRFC 5245で「積極的な指名」と呼ばれていました。複数の候補ペアが制御エージェントによって指名され、制御エージェントが複数の指名リクエストを受け入れる場合、エージェントは選択されたペアを生成し、最高のペアを使用する必要があります優先。
The usage of the 'ice2' ICE option (Section 10) by endpoints supporting this specification is supposed to prevent controlling agents that are implemented according to RFC 5245 from using aggressive nomination.
この仕様をサポートするエンドポイントによる「ice2」ICEオプション（セクション10）の使用は、RFC 5245に従って実装された制御エージェントが積極的な指名を使用するのを防ぐことになっています。
NOTE: In RFC 5245, usage of "aggressive nomination" allowed agents to continuously nominate pairs, before a pair was eventually selected, in order to allow sending of data on those pairs. In this specification, data can always be sent on any valid pair, without nomination. Hence, there is no longer a need for aggressive nomination.
注：RFC 5245では、「積極的な指名」の使用により、ペアが最終的に選択される前に、エージェントがペアを継続的に指名して、それらのペアでデータを送信できるようになりました。この仕様では、データは指定なしで常に有効なペアで送信できます。したがって、もはや積極的な指名の必要はありません。
For both a controlling and a controlled agent, when a candidate pair for a component of a data stream gets nominated, it might impact other pairs in the checklist associated with the data stream. It might also impact the state of the checklist:
制御エージェントと制御エージェントの両方で、データストリームのコンポーネントの候補ペアが指名されると、データストリームに関連付けられたチェックリストの他のペアに影響を与える可能性があります。チェックリストの状態にも影響を与える可能性があります。
o Once a candidate pair for a component of a data stream has been nominated, and the state of the checklist associated with the data stream is Running, the ICE agent MUST remove all candidate pairs for the same component from the checklist and from the triggered-check queue. If the state of a pair is In-Progress, the agent cancels the In-Progress transaction. Cancellation means that the agent will not retransmit the Binding requests associated with the connectivity-check transaction, will not treat the lack of response to be a failure, but will wait the duration of the transaction timeout for a response.
o データストリームのコンポーネントの候補ペアが指定され、データストリームに関連付けられたチェックリストの状態がRunningになると、ICEエージェントは、同じコンポーネントのすべての候補ペアをチェックリストおよびトリガーチェックから削除する必要がありますキュー。ペアの状態が進行中の場合、エージェントは進行中のトランザクションをキャンセルします。キャンセルとは、エージェントが接続性チェックトランザクションに関連付けられたバインディングリクエストを再送信せず、応答がないことを障害として処理せずに、トランザクションタイムアウトが続くまで応答を待機することを意味します。
o Once candidate pairs for each component of a data stream have been nominated, and the state of the checklist associated with the data stream is Running, the ICE agent sets the state of the checklist to Completed.
o データストリームの各コンポーネントの候補ペアが指定され、データストリームに関連付けられたチェックリストの状態がRunningになると、ICEエージェントはチェックリストの状態をCompletedに設定します。
o Once a candidate pair for a component of a data stream has been nominated, an agent MUST continue to respond to any Binding request it might still receive for the nominated pair and for any remaining candidate pairs in the checklist associated with the data stream. As defined in Section 7.3.1.4, when the state of a pair is Succeeded, an agent will no longer generate triggered checks when receiving a Binding request for the pair.
oデータストリームのコンポーネントの候補ペアが指名された後、エージェントは、指名されたペアおよびデータストリームに関連付けられたチェックリスト内の残りの候補ペアに対して受信する可能性があるバインディング要求に引き続き応答する必要があります。セクション7.3.1.4で定義されているように、ペアの状態がSucceededの場合、ペアのバインディングリクエストを受信しても、エージェントはトリガーされたチェックを生成しなくなります。
Once the state of each checklist in the checklist set is Completed, the agent sets the state of the ICE session to Completed.
チェックリストセットの各チェックリストの状態が完了したら、エージェントはICEセッションの状態を完了に設定します。
If the state of a checklist is Failed, ICE has not been able to successfully complete the process for the data stream associated with the checklist. The correct behavior depends on the state of the checklists in the checklist set. If the controlling agent wants to continue the session without the data stream associated with the Failed checklist, and if there are still one or more checklists in Running or Completed mode, the agent can let the ICE processing continue. The agent MUST take proper actions for removing the failed data stream. If the controlling agent does not want to continue the session and MUST terminate the session, the state of the ICE session is set to Failed.
チェックリストの状態がFailedの場合、ICEはチェックリストに関連付けられたデータストリームのプロセスを正常に完了できませんでした。正しい動作は、チェックリストセットのチェックリストの状態によって異なります。制御エージェントが、失敗したチェックリストに関連付けられたデータストリームなしでセッションを継続する場合、および実行モードまたは完了モードのチェックリストが1つ以上残っている場合、エージェントはICE処理を続行できます。エージェントは、失敗したデータストリームを削除するための適切なアクションを実行する必要があります。制御エージェントがセッションの継続を望まず、セッションを終了しなければならない場合、ICEセッションの状態はFailedに設定されます。
If the state of each checklist in the checklist set is Failed, the state of the ICE session is set to Failed. Unless the controlling agent wants to continue the session without the data streams, it MUST terminate the session.
チェックリストセットの各チェックリストの状態がFailedの場合、ICEセッションの状態はFailedに設定されます。制御エージェントがデータストリームなしでセッションを続行したい場合を除き、セッションを終了する必要があります。
When ICE concludes, a lite ICE agent can free host candidates that were not used by ICE, as described in Section 8.3.
ICEが終了すると、ライトICEエージェントは、セクション8.3で説明されているように、ICEで使用されなかったホスト候補を解放できます。
If the peer is a full agent, once the lite agent accepts a nomination request for a candidate pair, the lite agent considers the pair nominated. Once there are nominated pairs for each component of a data stream, the pairs become the selected pairs for the components of the data stream. Once the lite agent has produced selected pairs for all components of all data streams, the ICE session state is set to Completed.
ピアが完全なエージェントである場合、ライトエージェントが候補ペアの指名要求を受け入れると、ライトエージェントはペアが指名されたと見なします。データストリームの各コンポーネントに指定されたペアがあると、そのペアがデータストリームのコンポーネントの選択されたペアになります。ライトエージェントがすべてのデータストリームのすべてのコンポーネントに対して選択されたペアを生成すると、ICEセッション状態は完了に設定されます。
If the peer is a lite agent, the agent pairs local candidates with remote candidates that are of the same data stream and have the same component, transport protocol, and IP address family. For each component of each data stream, if there is only one candidate pair, that pair is added to the valid list. If there is more than one pair, it is RECOMMENDED that an agent follow the procedures of RFC 6724 [RFC6724] to select a pair and add it to the valid list.
ピアがライトエージェントである場合、エージェントはローカル候補とリモート候補をペアにし、それらは同じデータストリームであり、同じコンポーネント、トランスポートプロトコル、およびIPアドレスファミリを持っています。各データストリームの各コンポーネントについて、候補ペアが1つしかない場合、そのペアが有効なリストに追加されます。複数のペアがある場合は、エージェントがRFC 6724 [RFC6724]の手順に従ってペアを選択し、それを有効なリストに追加することをお勧めします。
If all of the components for all data streams had one pair, the state of ICE processing is Completed. Otherwise, the controlling agent MUST send an updated candidate list to reconcile different agents selecting different candidate pairs. ICE processing is complete after and only after the updated candidate exchange is complete.
すべてのデータストリームのすべてのコンポーネントに1つのペアがある場合、ICE処理の状態は完了です。それ以外の場合、制御エージェントは、更新された候補リストを送信して、異なる候補ペアを選択する異なるエージェントを調整する必要があります。 ICE処理は、更新された候補者交換が完了した後でのみ完了します。
The rules in this section describe when it is safe for an agent to cease sending or receiving checks on a candidate that did not become a selected candidate (i.e., is not associated with a selected pair) and when to free the candidate.
このセクションのルールは、エージェントが選択された候補にならなかった（つまり、選択されたペアに関連付けられていない）候補のチェックの送信または受信を安全に停止できる場合と、候補を解放する場合について説明します。
Once a checklist has reached the Completed state, the agent SHOULD wait an additional three seconds, and then it can cease responding to checks or generating triggered checks on all local candidates other than the ones that became selected candidates. Once all ICE sessions have ceased using a given local candidate (a candidate may be used by multiple ICE sessions, e.g., in forking scenarios), the agent can free that candidate. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed.
チェックリストが完了状態に達すると、エージェントはさらに3秒間待機する必要があり（SHOULD）、チェックへの応答を停止するか、選択された候補以外のすべてのローカル候補に対してトリガーされたチェックを生成できます。特定のローカル候補を使用してすべてのICEセッションが終了すると（候補は、たとえば分岐シナリオで複数のICEセッションによって使用される場合があります）、エージェントはその候補を解放できます。 3秒の遅延は、積極的な指名が使用される場合を処理し、選択されたペアはICEの完了後にすばやく変更できます。
Freeing of server-reflexive candidates is never explicit; it happens by lack of a keepalive.
サーバー再帰候補の解放は明示的ではありません。キープアライブがないために発生します。
A lite implementation can free candidates that did not become selected candidates as soon as ICE processing has reached the Completed state for all ICE sessions using those candidates.
ライトの実装では、選択された候補にならなかった候補を、それらの候補を使用するすべてのICEセッションでICE処理が完了状態に達するとすぐに解放できます。
An ICE agent MAY restart ICE for existing data streams. An ICE restart causes all previous states of the data streams, excluding the roles of the agents, to be flushed. The only difference between an ICE restart and a brand new data session is that during the restart, data can continue to be sent using existing data sessions, and a new data session always requires the roles to be determined.
ICEエージェントは、既存のデータストリームのICEを再起動する場合があります。 ICEを再起動すると、エージェントの役割を除く、データストリームの以前の状態がすべてフラッシュされます。 ICEの再起動と新しいデータセッションの唯一の違いは、再起動中、既存のデータセッションを使用してデータを送信し続けることができ、新しいデータセッションでは常に役割を決定する必要があることです。
The following actions can be accomplished only by using an ICE restart (the agent MUST use ICE restarts to do so):
次のアクションは、ICE再起動を使用することによってのみ実行できます（エージェントは、ICE再起動を使用する必要があります）。
o Change the destinations of data streams.
o データストリームの宛先を変更します。
o Change from a lite implementation to a full implementation.
o 簡易実装から完全実装に変更します。
o Change from a full implementation to a lite implementation.
o 完全な実装からライトな実装に変更します。
To restart ICE, an agent MUST change both the password and the username fragment for the data stream(s) being restarted.
ICEを再起動するには、エージェントは、再起動されるデータストリームのパスワードとユーザー名フラグメントの両方を変更する必要があります。
When the ICE is restarted, the candidate set for the new ICE session might include some, none, or all of the candidates used in the current ICE session.
ICEを再起動すると、新しいICEセッションの候補セットには、現在のICEセッションで使用されている候補の一部またはすべてが含まれる場合と、まったく含まれない場合があります。
As described in Section 6.1.1, agents MUST NOT redetermine the roles as part as an ICE restart, unless certain criteria that require the roles to be redetermined are fulfilled.
セクション6.1.1で説明されているように、エージェントは、役割の再決定を要求する特定の基準が満たされない限り、ICEの再起動として役割を再決定してはなりません。
This section defines a new ICE option, 'ice2'. When an ICE agent includes 'ice2' in a candidate exchange, the ICE option indicates that it is compliant to this specification. For example, the agent will not use the aggressive nomination procedure defined in RFC 5245. In addition, it will ensure that a peer compliant with RFC 5245 does not use aggressive nomination either, as required by Section 14 of RFC 5245 for peers that receive unknown ICE options.
このセクションでは、新しいICEオプション「ice2」を定義します。 ICEエージェントが候補交換に「ice2」を含む場合、ICEオプションは、この仕様に準拠していることを示します。たとえば、エージェントはRFC 5245で定義されている積極的な指名手順を使用しません。さらに、RFC 5245のセクション14で不明を受信するピアに要求されるように、RFC 5245に準拠するピアも積極的な指名を使用しないようにします。 ICEオプション。
An agent compliant to this specification MUST inform the peer about the compliance using the 'ice2' option.
この仕様に準拠するエージェントは、「ice2」オプションを使用して、準拠についてピアに通知する必要があります。
NOTE: The encoding of the 'ice2' option, and the message(s) used to carry it to the peer, are protocol specific. The encoding for SDP [RFC4566] is defined in [ICE-SIP-SDP].
注：「ice2」オプションのエンコーディング、およびそれをピアに運ぶために使用されるメッセージは、プロトコル固有です。 SDPのエンコーディング[RFC4566]は[ICE-SIP-SDP]で定義されています。
All endpoints MUST send keepalives for each data session. These keepalives serve the purpose of keeping NAT bindings alive for the data session. The keepalives SHOULD be sent using a format that is supported by its peer. ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an ICE agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full).
すべてのエンドポイントは、データセッションごとにキープアライブを送信する必要があります。これらのキープアライブは、データセッションのためにNATバインディングを存続させる目的を果たします。キープアライブは、そのピアでサポートされているフォーマットを使用して送信する必要があります（SHOULD）。 ICEエンドポイントは、UDPストリームのSTUNベースのキープアライブを可能にするため、ICEエージェントが完全なICE実装であり、ICEをサポートするピア（ライトまたはフル）と通信している場合は、STUNキープアライブを使用する必要があります。
An agent MUST send a keepalive on each candidate pair that is used for sending data if no packet has been sent on that pair in the last Tr seconds. Agents SHOULD use a Tr value of 15 seconds. Agents MAY use a bigger value but MUST NOT use a value smaller than 15 seconds.
エージェントは、最後のTr秒でそのペアにパケットが送信されなかった場合に、データの送信に使用される各候補ペアにキープアライブを送信する必要があります。エージェントは15秒のTr値を使用する必要があります（SHOULD）。エージェントはより大きな値を使用できますが、15秒未満の値を使用してはなりません。
Once selected pairs have been produced for a data stream, keepalives are only sent on those pairs.
選択したペアがデータストリームに対して生成されると、キープアライブはそれらのペアでのみ送信されます。
An agent MUST stop sending keepalives on a data stream if the data stream is removed. If the ICE session is terminated, an agent MUST stop sending keepalives on all data streams.
データストリームが削除された場合、エージェントはデータストリームでキープアライブの送信を停止する必要があります。 ICEセッションが終了した場合、エージェントはすべてのデータストリームでキープアライブの送信を停止する必要があります。
An agent MAY use another value for Tr, e.g., based on configuration or network/NAT characteristics. For example, if an agent has a dynamic way to discover the binding lifetimes of the intervening NATs, it can use that value to determine Tr. Administrators deploying ICE in more controlled networking environments SHOULD set Tr to the longest duration possible in their environment.
エージェントは、たとえば、構成またはネットワーク/ NAT特性に基づいて、Trに別の値を使用できます。たとえば、エージェントが動的に介在するNATのバインディングライフタイムを検出する方法を持っている場合、その値を使用してTrを決定できます。より制御されたネットワーク環境にICEを展開する管理者は、Trをその環境で可能な最長の期間に設定する必要があります（SHOULD）。
When STUN is being used for keepalives, a STUN Binding Indication is used [RFC5389]. The Indication MUST NOT utilize any authentication mechanism. It SHOULD contain the FINGERPRINT attribute to aid in demultiplexing, but it SHOULD NOT contain any other attributes. It is used solely to keep the NAT bindings alive. The Binding Indication is sent using the same local and remote candidates that are being used for data. Though Binding Indications are used for keepalives, an agent MUST be prepared to receive a connectivity check as well. If a connectivity check is received, a response is generated as discussed in [RFC5389], but there is no impact on ICE processing otherwise.
キープアライブにSTUNが使用されている場合、STUNバインディング表示が使用されます[RFC5389]。表示はいかなる認証メカニズムも利用してはならない（MUST NOT）。逆多重化を支援するためにFINGERPRINT属性を含める必要がありますが、他の属性を含めないでください。これは、NATバインディングを存続させるためにのみ使用されます。バインディング表示は、データに使用されているのと同じローカルおよびリモート候補を使用して送信されます。バインディング表示はキープアライブに使用されますが、エージェントは接続チェックも受信できるように準備する必要があります。接続チェックが受信されると、[RFC5389]で説明されているように応答が生成されますが、それ以外の場合はICE処理に影響はありません。
Agents MUST by default use STUN keepalives. Individual ICE usages and ICE extensions MAY specify usage-/extension-specific keepalives.
エージェントはデフォルトでSTUNキープアライブを使用する必要があります。個々のICEの使用法とICE拡張機能は、使用法/拡張機能固有のキープアライブを指定する場合があります。
An ICE agent MAY send data on any valid pair before selected pairs have been produced for the data stream.
ICEエージェントは、データストリームに対して選択されたペアが生成される前に、有効なペアでデータを送信できます（MAY）。
Once selected pairs have been produced for a data stream, an agent MUST send data on those pairs only.
選択されたペアがデータストリームに対して生成されると、エージェントはそれらのペアについてのみデータを送信する必要があります。
An agent sends data from the base of the local candidate to the remote candidate. In the case of a local relayed candidate, data is forwarded through the base (located in the TURN server), using the procedures defined in [RFC5766].
エージェントは、ローカル候補者のベースからリモート候補者にデータを送信します。ローカルで中継された候補の場合、データは[RFC5766]で定義されている手順を使用して、ベース（TURNサーバーにある）を介して転送されます。
If the local candidate is a relayed candidate, it is RECOMMENDED that an agent creates a channel on the TURN server towards the remote candidate. This is done using the procedures for channel creation as defined in Section 11 of [RFC5766].
ローカル候補が中継候補である場合、エージェントがリモート候補に向けてTURNサーバー上にチャネルを作成することをお勧めします。これは、[RFC5766]のセクション11で定義されているチャネル作成の手順を使用して行われます。
The selected pair for a component of a data stream is:
データストリームのコンポーネントに対して選択されるペアは次のとおりです。
o empty if the state of the checklist for that data stream is Running, and there is no previous selected pair for that component due to an ICE restart
o そのデータストリームのチェックリストの状態が[実行中]で、ICEの再起動によりそのコンポーネントに対して以前に選択されたペアがない場合は空
o equal to the previous selected pair for a component of a data stream if the state of the checklist for that data stream is Running, and there was a previous selected pair for that component due to an ICE restart
o データストリームのチェックリストの状態が[実行中]で、ICEの再起動によりそのコンポーネントに対して以前に選択されたペアがあった場合、データストリームのコンポーネントに対して以前に選択されたペアに等しい
Unless an agent is able to produce a selected pair for each component associated with a data stream, the agent MUST NOT continue sending data for any component associated with that data stream.
エージェントがデータストリームに関連付けられた各コンポーネントの選択されたペアを生成できる場合を除き、エージェントは、そのデータストリームに関連付けられたコンポーネントのデータの送信を継続してはなりません。
A lite implementation MUST NOT send data until it has a valid list that contains a candidate pair for each component of that data stream. Once that happens, the ICE agent MAY begin sending data packets. To do that, it sends data to the remote candidate in the pair (setting the destination address and port of the packet equal to that remote candidate) and will send it from the base associated with the candidate pair used for sending data. In case of a relayed candidate, data is sent from the agent and forwarded through the base (located in the TURN server), using the procedures defined in [RFC5766].
ライトの実装は、そのデータストリームの各コンポーネントの候補ペアを含む有効なリストがあるまで、データを送信してはなりません（MUST NOT）。それが発生すると、ICEエージェントはデータパケットの送信を開始する場合があります。そのために、ペアのリモート候補にデータを送信し（パケットの宛先アドレスとポートをそのリモート候補に等しく設定する）、データの送信に使用される候補ペアに関連付けられたベースからデータを送信します。リレーされた候補の場合、データはエージェントから送信され、[RFC5766]で定義されている手順を使用して、ベース（TURNサーバーにある）を介して転送されます。
Even though ICE agents are only allowed to send data using valid candidate pairs (and, once selected pairs have been produced, only on the selected pairs), ICE implementations SHOULD by default be prepared to receive data on any of the candidates provided in the most recent candidate exchange with the peer. ICE usages MAY define rules that differ from this, e.g., by defining that data will not be sent until selected pairs have been produced for a data stream.
ICEエージェントは有効な候補ペアを使用してのみデータを送信することを許可されています（そして、選択されたペアが生成されると、選択されたペアでのみ）、ICE実装は、デフォルトで、ほとんどのピアとの最近の候補者交換。 ICEの使用法は、これとは異なるルールを定義することができます（たとえば、データストリームに対して選択されたペアが作成されるまでデータが送信されないことを定義するなど）。
When an agent receives an RTP packet with a new source or destination IP address for a particular RTP/RTCP data stream, it is RECOMMENDED that the agent readjust its jitter buffers.
エージェントが特定のRTP / RTCPデータストリームの新しい送信元または宛先IPアドレスを含むRTPパケットを受信した場合、エージェントがそのジッタバッファを再調整することが推奨されます。
Section 8.2 of RFC 3550 [RFC3550] describes an algorithm for detecting synchronization source (SSRC) collisions and loops. These algorithms are based, in part, on seeing different source transport addresses with the same SSRC. However, when ICE is used, such changes will sometimes occur as the data streams switch between candidates. An agent will be able to determine that a data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission. Thus, if there is a change in the source transport address, but the media data packets come from the same peer agent, this MUST NOT be treated as an SSRC collision.
RFC 3550 [RFC3550]のセクション8.2は、同期ソース（SSRC）の衝突とループを検出するためのアルゴリズムについて説明しています。これらのアルゴリズムは、同じSSRCで異なるソーストランスポートアドレスを確認することに部分的に基づいています。ただし、ICEを使用すると、データストリームが候補間で切り替わるときに、このような変更が発生することがあります。メディアデータ送信を進めるSTUN交換の結果として、エージェントはデータストリームが同じピアからのものであることを判別できます。したがって、ソーストランスポートアドレスに変更があるが、メディアデータパケットが同じピアエージェントからのものである場合、これはSSRC衝突として扱われてはならない（MUST NOT）。
This specification makes very specific choices about how both ICE agents in a session coordinate to arrive at the set of candidate pairs that are selected for data. It is anticipated that future specifications will want to alter these algorithms, whether they are simple changes like timer tweaks or larger changes like a revamp of the priority algorithm. When such a change is made, providing interoperability between the two agents in a session is critical.
この仕様は、セッション内の両方のICEエージェントが、データ用に選択された候補ペアのセットに到達するように調整する方法について非常に具体的な選択を行います。タイマーの微調整のような単純な変更でも、優先アルゴリズムの改良のような大きな変更でも、将来の仕様ではこれらのアルゴリズムを変更する必要があると予想されます。このような変更を行う場合、セッション内の2つのエージェント間の相互運用性を提供することが重要です。
First, ICE provides the ICE option concept. Each extension or change to ICE is associated with an ICE option. When an agent supports such an extension or change, it provides the ICE option to the peer agent as part of the candidate exchange.
まず、ICEはICEオプションのコンセプトを提供します。 ICEへの各拡張または変更は、ICEオプションに関連付けられています。エージェントがそのような拡張または変更をサポートする場合、候補交換の一部としてICEオプションをピアエージェントに提供します。
One of the complications in achieving interoperability is that ICE relies on a distributed algorithm running on both agents to converge on an agreed set of candidate pairs. If the two agents run different algorithms, it can be difficult to guarantee convergence on the same candidate pairs. The nomination procedure described in Section 8 eliminates some of the need for tight coordination by delegating the selection algorithm completely to the controlling agent, and ICE will converge perfectly even when both agents use different pair prioritization algorithms. One of the keys to such convergence is triggered checks, which ensure that the nominated pair is validated by both agents.
相互運用性を実現する際の複雑さの1つは、ICEが両方のエージェントで実行される分散アルゴリズムに依存して、合意された候補ペアのセットに収束することです。 2つのエージェントが異なるアルゴリズムを実行する場合、同じ候補ペアでの収束を保証するのは難しい場合があります。セクション8で説明する指名手順では、選択アルゴリズムを制御エージェントに完全に委任することにより、緊密な調整の必要性の一部を排除し、両方のエージェントが異なるペア優先順位付けアルゴリズムを使用する場合でも、ICEは完全に収束します。このような収束の鍵の1つはトリガーチェックです。これにより、指名されたペアが両方のエージェントによって検証されることが保証されます。
ICE is also extensible to other data streams beyond RTP and for transport protocols beyond UDP. Extensions to ICE for non-RTP data streams need to specify how many components they utilize and assign component IDs to them, starting at 1 for the most important component ID. Specifications for new transport protocols MUST define how, if at all, various steps in the ICE processing differ from UDP.
ICEは、RTPを超える他のデータストリームや、UDPを超えるトランスポートプロトコルにも拡張できます。非RTPデータストリームのICEの拡張では、使用するコンポーネントの数を指定し、コンポーネントIDをそれらに割り当てる必要があります。最も重要なコンポーネントIDの1から始めます。新しいトランスポートプロトコルの仕様では、ICE処理のさまざまなステップがUDPとどのように異なるかを定義する必要があります。
During the ICE gathering phase (Section 5.1.1) and while ICE is performing connectivity checks (Section 7), an ICE agent triggers STUN and TURN transactions. These transactions are paced at a rate indicated by Ta, and the retransmission interval for each transaction is calculated based on the retransmission timer for the STUN transactions (RTO) [RFC5389].
ICE収集フェーズ（セクション5.1.1）中、およびICEが接続性チェックを実行している間（セクション7）、ICEエージェントはSTUNおよびTURNトランザクションをトリガーします。これらのトランザクションは、Taで示される速度で調整され、各トランザクションの再送信間隔は、STUNトランザクション（RTO）の再送信タイマー[RFC5389]に基づいて計算されます。
This section describes how the Ta and RTO values are computed during the ICE gathering phase and while ICE is performing connectivity checks.
このセクションでは、ICE収集フェーズ中、およびICEが接続性チェックを実行している間に、TaおよびRTO値がどのように計算されるかについて説明します。
NOTE: Previously, in RFC 5245, different formulas were defined for computing Ta and RTO, depending on whether or not ICE was used for a real-time data stream (e.g., RTP).
注：以前は、RFC 5245では、ICEがリアルタイムデータストリーム（RTPなど）に使用されたかどうかに応じて、TaとRTOを計算するための異なる式が定義されていました。
The formulas below result in a behavior whereby an agent will send its first packet for every single connectivity check before performing a retransmit. This can be seen in the formulas for the RTO (which represents the retransmit interval). Those formulas scale with N, the number of checks to be performed. As a result of this, ICE maintains a nicely constant rate, but it becomes more sensitive to packet loss. The loss of the first single packet for any connectivity check is likely to cause that pair to take a long time to be validated, and instead, a lower-priority check (but one for which there was no packet loss) is much more likely to complete first. This results in ICE performing suboptimally, choosing lower-priority pairs over higher-priority pairs.
以下の式により、再送信を実行する前に、エージェントが接続チェックごとに最初のパケットを送信するという動作になります。これは、RTO（再送信間隔を表す）の式で確認できます。これらの式は、実行されるチェックの数であるNに比例します。この結果、ICEは一定の速度を維持しますが、パケット損失の影響を受けやすくなります。接続チェックで最初の単一パケットが失われると、そのペアの検証に長い時間がかかる可能性が高く、代わりに、優先度の低いチェック（ただし、パケット損失がなかったもの）の可能性がはるかに高くなります。最初に完了します。その結果、ICEのパフォーマンスが最適化されず、優先度の高いペアよりも優先度の低いペアが選択されます。
ICE agents SHOULD use a default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated data.
ICEエージェントは、デフォルトのTa値である50ミリ秒を使用する必要があります（SHOULD）が、関連するデータの特性に基づいて別の値を使用してもよい（MAY）。
If an agent wants to use a Ta value other than the default value, the agent MUST indicate the proposed value to its peer during the establishment of the ICE session. Both agents MUST use the higher value of the proposed values. If an agent does not propose a value, the default value is used for that agent when comparing which value is higher.
エージェントがデフォルト値以外のTa値を使用したい場合、エージェントはICEセッションの確立中にピアに提案された値を示さなければなりません（MUST）。両方のエージェントは、提案された値のより高い値を使用する必要があります。エージェントが値を提案しない場合、どちらの値が高いかを比較するときに、そのエージェントのデフォルト値が使用されます。
Regardless of the Ta value chosen for each agent, the combination of all transactions from all agents (if a given implementation runs several concurrent agents) MUST NOT be sent more often than once every 5 ms (as though there were one global Ta value for pacing all agents). See Appendix B.1 for the background of using a value of 5 ms with ICE.
各エージェントに選択されたTa値に関係なく、すべてのエージェントからのすべてのトランザクションの組み合わせ（特定の実装が複数の同時エージェントを実行する場合）は、5ミリ秒に1回よりも頻繁に送信してはなりません（ペーシング用のグローバルTa値が1つあるかのように）すべてのエージェント）。 ICEで5 msの値を使用する背景については、付録B.1を参照してください。
NOTE: Appendix C shows examples of required bandwidth, using different Ta values.
注：付録Cは、さまざまなTa値を使用して必要な帯域幅の例を示しています。
During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula:
ICE収集フェーズ中に、ICEエージェントは、次の式を使用してRTO値を計算する必要があります（SHOULD）。
RTO = MAX (500ms, Ta * (Num-Of-Cands))
RTO = MAX（500 ms、To *（Number-Of-Canes））
Num-Of-Cands: the number of server-reflexive and relay candidates
カードの数：サーバー再帰候補とリレー候補の数
For connectivity checks, agents SHOULD calculate the RTO value using the following formula:
接続性チェックの場合、エージェントは次の式を使用してRTO値を計算する必要があります（SHOULD）。
RTO = MAX (500ms, Ta * N * (Num-Waiting + Num-In-Progress))
N: the total number of connectivity checks to be performed.
N：実行される接続チェックの総数。
Num-Waiting: the number of checks in the checklist set in the Waiting state.
Num-Waiting：待機状態に設定されたチェックリスト内のチェックの数。
Num-In-Progress: the number of checks in the checklist set in the In-Progress state.
Num-In-Progress：In-Progress状態に設定されたチェックリスト内のチェックの数。
Note that the RTO will be different for each transaction as the number of checks in the Waiting and In-Progress states change.
Waiting状態とIn-Progress状態のチェックの数が変わると、RTOはトランザクションごとに異なることに注意してください。
Agents MAY calculate the RTO value using other mechanisms than those described above. Agents MUST NOT use an RTO value smaller than 500 ms.
エージェントは、上記以外のメカニズムを使用してRTO値を計算できます（MAY）。エージェントは、500ミリ秒未満のRTO値を使用してはなりません。
This section shows two ICE examples: one using IPv4 addresses and one using IPv6 addresses.
このセクションでは、2つのICEの例を示します。1つはIPv4アドレスを使用し、もう1つはIPv6アドレスを使用します。
To facilitate understanding, transport addresses are listed using variables that have mnemonic names. The format of the name is entity-type-seqno: "entity" refers to the entity whose IP address the transport address is on and is one of "L", "R", "STUN", or "NAT". The type is either "PUB" for transport addresses that are public or "PRIV" for transport addresses that are private [RFC1918]. Finally, seq-no is a sequence number that is different for each transport address of the same type on a particular entity. Each variable has an IP address and port, denoted by varname.IP and varname.PORT, respectively, where varname is the name of the variable.
理解を容易にするために、トランスポートアドレスは、ニーモニック名を持つ変数を使用してリストされます。名前の形式はentity-type-seqnoです。「entity」は、トランスポートアドレスが存在するIPアドレスのエンティティを指し、「L」、「R」、「STUN」、または「NAT」のいずれかです。タイプは、パブリックのトランスポートアドレスの場合は「PUB」、プライベートのトランスポートアドレスの場合は「PRIV」のいずれかです[RFC1918]。最後に、seq-noは、特定のエンティティ上の同じタイプのトランスポートアドレスごとに異なるシーケンス番号です。各変数にはIPアドレスとポートがあり、それぞれvarname.IPとvarname.PORTで示されます。varnameは変数の名前です。
In the call flow itself, STUN messages are annotated with several attributes. The "S=" attribute indicates the source transport address of the message. The "D=" attribute indicates the destination transport address of the message. The "MA=" attribute is used in STUN Binding response messages and refers to the mapped address. "USE-CAND" implies the presence of the USE-CANDIDATE attribute.
コールフロー自体では、STUNメッセージにいくつかの属性が付けられています。 「S =」属性は、メッセージの送信元トランスポートアドレスを示します。 「D =」属性は、メッセージの宛先トランスポートアドレスを示します。 「MA =」属性はSTUNバインディング応答メッセージで使用され、マッピングされたアドレスを参照します。 「USE-CAND」は、USE-CANDIDATE属性の存在を意味します。
The call flow examples omit STUN authentication operations and focus on a single data stream between two full implementations.
コールフローの例では、STUN認証操作を省略し、2つの完全な実装間の単一のデータストリームに焦点を当てています。
The example below is using the topology shown in Figure 7.
次の例は、図7に示すトポロジを使用しています。
+-------+
|STUN |
|Server |
+-------+
|
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
| |
+---------+ |
| NAT | |
+---------+ |
| |
| |
+-----+ +-----+
| L | | R |
+-----+ +-----+
Figure 7: Example Topology
図7：トポロジの例
In the example, ICE agents L and R are full ICE implementations. Both agents have a single IPv4 address, and both are configured with the same STUN server. The NAT has an endpoint-independent mapping property and an address-dependent filtering property. The IP addresses of the ICE agents, the STUN server, and the NAT are shown below:
この例では、ICEエージェントLおよびRは完全なICE実装です。両方のエージェントは単一のIPv4アドレスを持ち、両方が同じSTUNサーバーで構成されています。 NATには、エンドポイントに依存しないマッピングプロパティとアドレスに依存するフィルタリングプロパティがあります。 ICEエージェント、STUNサーバー、NATのIPアドレスを以下に示します。
ENTITY IP Address Mnemonic name
--------------------------------------------------
ICE Agent L: 10.0.1.1 L-PRIV-1
ICE Agent R: 192.0.2.1 R-PUB-1
STUN Server: 192.0.2.2 STUN-PUB-1
NAT (Public): 192.0.2.3 NAT-PUB-1
L NAT STUN R
|STUN alloc. | | |
|(1) STUN Req | | |
|S=$L-PRIV-1 | | |
|D=$STUN-PUB-1 | | |
|------------->| | |
| |(2) STUN Req | |
| |S=$NAT-PUB-1 | |
| |D=$STUN-PUB-1 | |
| |------------->| |
| |(3) STUN Res | |
| |S=$STUN-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<-------------| |
|(4) STUN Res | | |
|S=$STUN-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|(5) L's Candidate Information| |
|------------------------------------------->|
| | | | STUN
| | | | alloc.
| | |(6) STUN Req |
| | |S=$R-PUB-1 |
| | |D=$STUN-PUB-1 |
| | |<-------------|
| | |(7) STUN Res |
| | |S=$STUN-PUB-1 |
| | |D=$R-PUB-1 |
| | |MA=$R-PUB-1 |
| | |------------->|
|(8) R's Candidate Information| |
|<-------------------------------------------|
| | (9) Bind Req |Begin
| | S=$R-PUB-1 |Connectivity
| | D=$L-PRIV-1 |Checks
| | <-------------------|
| | Dropped |
|(10) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|------------->| | |
| |(11) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |---------------------------->|
| |(12) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(13) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|Data | | |
|===========================================>|
| | | |
| |(14) Bind Req | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |<----------------------------|
|(15) Bind Req | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|<-------------| | |
|(16) Bind Res | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | |
|------------->| | |
| |(17) Bind Res | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | |
| |---------------------------->|
|Data | | |
|<===========================================|
| | | |
.......
| | | |
|(18) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|USE-CAND | | |
|------------->| | |
| |(19) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |USE-CAND | |
| |---------------------------->|
| |(20) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(21) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
| | | |
Figure 8: Example Flow
図8：フローの例
Messages 1-4: Agent L gathers a host candidate from its local IP address, and from that it sends a STUN Binding request to the STUN server. The request creates a NAT binding. The NAT public IP address of the binding becomes agent L's server-reflexive candidate.
メッセージ1〜4：エージェントLは、ローカルIPアドレスからホスト候補を収集し、そこからSTUNバインディング要求をSTUNサーバーに送信します。リクエストはNATバインディングを作成します。バインディングのNATパブリックIPアドレスは、エージェントLのサーバー再帰候補になります。
Message 5: Agent L sends its local candidate information to agent R, using the signaling protocol associated with the ICE usage.
メッセージ5：エージェントLは、ICEの使用に関連付けられたシグナリングプロトコルを使用して、ローカル候補情報をエージェントRに送信します。
Messages 6-7: Agent R gathers a host candidate from its local IP address, and from that it sends a STUN Binding request to the STUN server. Since agent R is not behind a NAT, R's server-reflexive candidate will be identical to the host candidate.
メッセージ6-7：エージェントRは、ローカルIPアドレスからホスト候補を収集し、そこからSTUNバインディング要求をSTUNサーバーに送信します。エージェントRはNATの背後にないため、Rのサーバー再帰候補はホスト候補と同一になります。
Message 8: Agent R sends its local candidate information to agent L, using the signaling protocol associated with the ICE usage.
メッセージ8：エージェントRは、ICEの使用に関連するシグナリングプロトコルを使用して、ローカル候補情報をエージェントLに送信します。
Since both agents are full ICE implementations, the initiating agent (agent L) becomes the controlling agent.
両方のエージェントが完全なICE実装であるため、開始エージェント（エージェントL）が制御エージェントになります。
Agents L and R both pair up the candidates. Both agents initially have two pairs. However, agent L will prune the pair containing its server-reflexive candidate, resulting in just one (L1). At agent L, this pair has a local candidate of $L_PRIV_1 and a remote candidate of $R_PUB_1. At agent R, there are two pairs. The highest-priority pair (R1) has a local candidate of $R_PUB_1 and a remote candidate of $L_PRIV_1, and the second pair (R2) has a local candidate of $R_PUB_1 and a remote candidate of $NAT_PUB_1. The pairs are shown below (the pair numbers are for reference purposes only):
エージェントLとRの両方が候補をペアにします。どちらのエージェントも最初は2つのペアを持っています。ただし、エージェントLはそのサーバー再帰候補を含むペアをプルーニングし、1つだけ（L1）を生成します。エージェントLでは、このペアには$ L_PRIV_1のローカル候補と$ R_PUB_1のリモート候補があります。エージェントRには2つのペアがあります。最も優先順位の高いペア（R1）には$ R_PUB_1のローカル候補と$ L_PRIV_1のリモート候補があり、2番目のペア（R2）には$ R_PUB_1のローカル候補と$ NAT_PUB_1のリモート候補があります。ペアを以下に示します（ペア番号は参照専用です）。
Pairs
ENTITY Local Remote Pair # Valid
------------------------------------------------------------------
ICE Agent L: L_PRIV_1 R_PUB_1 L1
ICE Agent R: R_PUB_1 L_PRIV_1 R1 R_PUB_1 NAT_PUB_1 R2
ICEエージェントR：R_PUB_1 L_PRIV_1 R1 R_PUB_1 NAT_PUB_1 R2
Message 9: Agent R initiates a connectivity check for pair #2. As the remote candidate of the pair is the private address of agent L, the check will not be successful, as the request cannot be routed from R to L, and will be dropped by the network.
メッセージ9：エージェントRがペア＃2の接続性チェックを開始します。ペアのリモート候補はエージェントLのプライベートアドレスであるため、リクエストはRからLにルーティングできず、ネットワークによってドロップされるため、チェックは成功しません。
Messages 10-13: Agent L initiates a connectivity check for pair L1. The check succeeds, and L creates a new pair (L2). The local candidate of the new pair is $NAT_PUB_1, and the remote candidate is $R_PUB_1. The pair (L2) is added to the valid list of agent L. Agent L can now send and receive data on the pair (L2) if it wishes.
メッセージ10-13：エージェントLがペアL1の接続性チェックを開始します。チェックは成功し、Lは新しいペア（L2）を作成します。新しいペアのローカル候補は$ NAT_PUB_1で、リモート候補は$ R_PUB_1です。ペア（L2）がエージェントLの有効なリストに追加されます。エージェントLは、必要に応じてペア（L2）でデータを送受信できます。
Pairs
ENTITY Local Remote Pair # Valid
------------------------------------------------------------------
ICE Agent L: L_PRIV_1 R_PUB_1 L1
NAT_PUB_1 R_PUB_1 L2 X
ICE Agent R: R_PUB_1 L_PRIV_1 R1 R_PUB_1 NAT_PUB_1 R2
ICEエージェントR：R_PUB_1 L_PRIV_1 R1 R_PUB_1 NAT_PUB_1 R2
Messages 14-17: When agent R receives the Binding request from agent L (message 11), it will initiate a triggered connectivity check. The pair matches one of agent R's existing pairs (R2). The check succeeds, and the pair (R2) is added to the valid list of agent R. Agent R can now send and receive data on the pair (R2) if it wishes.
メッセージ14-17：エージェントRがエージェントLからバインディング要求を受信すると（メッセージ11）、トリガーされた接続性チェックが開始されます。このペアは、エージェントRの既存のペア（R2）の1つと一致します。チェックが成功し、ペア（R2）がエージェントRの有効なリストに追加されます。エージェントRは、必要に応じてペア（R2）でデータを送受信できます。
Pairs
ENTITY Local Remote Pair # Valid
------------------------------------------------------------------
ICE Agent L: L_PRIV_1 R_PUB_1 L1
NAT_PUB_1 R_PUB_1 L2 X
ICE Agent R: R_PUB_1 L_PRIV_1 R1 R_PUB_1 NAT_PUB_1 R2 X
ICEエージェントR：R_PUB_1 L_PRIV_1 R1 R_PUB_1 NAT_PUB_1 R2 X
Messages 18-21: At some point, the controlling agent (agent L) decides to nominate a pair (L2) in the valid list. It performs a connectivity check on the pair (L2) and includes the USE-CANDIDATE attribute in the Binding request. As the check succeeds, agent L sets the nominated flag value of the pair (L2) to 'true', and agent R sets the nominated flag value of the matching pair (R2) to 'true'. As there are no more components associated with the stream, the nominated pairs become the selected pairs. Consequently, processing for this stream moves into the Completed state. The ICE process also moves into the Completed state.
メッセージ18-21：ある時点で、制御エージェント（エージェントL）が有効なリストのペア（L2）を指名することを決定します。ペア（L2）の接続性チェックを実行し、バインディングリクエストにUSE-CANDIDATE属性を含めます。チェックが成功すると、エージェントLはペアの指定されたフラグ値（L2）を「true」に設定し、エージェントRは一致するペアの指定されたフラグ値（R2）を「true」に設定します。ストリームに関連付けられたコンポーネントがなくなるため、指定されたペアが選択されたペアになります。その結果、このストリームの処理は完了状態に移行します。 ICEプロセスも完了状態に移行します。
The example below is using the topology shown in Figure 9.
以下の例は、図9に示すトポロジーを使用しています。
+-------+
|STUN |
|Server |
+-------+
|
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
| |
| |
| |
| |
| |
| |
+-----+ +-----+
| L | | R |
+-----+ +-----+
Figure 9: Example Topology
図9：トポロジの例
In the example, ICE agents L and R are full ICE implementations. Both agents have a single IPv6 address, and both are configured with the same STUN server. The IP addresses of the ICE agents and the STUN server are shown below:
この例では、ICEエージェントLおよびRは完全なICE実装です。両方のエージェントに単一のIPv6アドレスがあり、両方が同じSTUNサーバーで構成されています。 ICEエージェントとSTUNサーバーのIPアドレスを以下に示します。
ENTITY IP Address mnemonic name
--------------------------------------------------
ICE Agent L: 2001:db8::3 L-PUB-1
ICE Agent R: 2001:db8::5 R-PUB-1
STUN Server: 2001:db8::9 STUN-PUB-1
L STUN R
|STUN alloc. | |
|(1) STUN Req | |
|S=$L-PUB-1 | |
|D=$STUN-PUB-1 | |
|---------------------------->| |
|(2) STUN Res | |
| S=$STUN-PUB-1 | |
| D=$L-PUB-1 | |
| MA=$L-PUB-1 | |
|<----------------------------| |
|(3) L's Candidate Information| |
|------------------------------------------->|
| | | STUN
| | | alloc.
| |(4) STUN Req |
| |S=$R-PUB-1 |
| |D=$STUN-PUB-1 |
| |<-------------|
| |(5) STUN Res |
| |S=$STUN-PUB-1 |
| |D=$R-PUB-1 |
| |MA=$R-PUB-1 |
| |------------->|
|(6) R's Candidate Information| |
|<-------------------------------------------|
|(7) Bind Req | |
|S=$L-PUB-1 | |
|D=$R-PUB-1 | |
|------------------------------------------->|
|(8) Bind Res | |
|S=$R-PUB-1 | |
|D=$L-PUB-1 | |
|MA=$L-PUB-1 | |
|<-------------------------------------------|
|Data | |
|===========================================>|
| | |
|(9) Bind Req | |
|S=$R-PUB-1 | |
|D=$L-PUB-1 | |
|<-------------------------------------------|
|(10) Bind Res | |
|S=$L-PUB-1 | |
|D=$R-PUB-1 | |
|MA=$R-PUB-1 | |
|------------------------------------------->|
|Data | |
|<===========================================|
| | |
.......
| | |
|(11) Bind Req | |
|S=$L-PUB-1 | |
|D=$R-PUB-1 | |
|USE-CAND | |
|------------------------------------------->|
|(12) Bind Res | |
|S=$R-PUB-1 | |
|D=$L-PUB-1 | |
|MA=$L-PUB-1 | |
|<-------------------------------------------|
| | | |
Figure 10: Example Flow
図10：フローの例
Messages 1-2: Agent L gathers a host candidate from its local IP address, and from that it sends a STUN Binding request to the STUN server. Since agent L is not behind a NAT, L's server-reflexive candidate will be identical to the host candidate.
メッセージ1-2：エージェントLは、ローカルIPアドレスからホスト候補を収集し、そこからSTUNバインディング要求をSTUNサーバーに送信します。エージェントLはNATの背後にないため、Lのサーバー再帰候補はホスト候補と同一になります。
Message 3: Agent L sends its local candidate information to agent R, using the signaling protocol associated with the ICE usage.
メッセージ3：エージェントLは、ICEの使用に関連付けられたシグナリングプロトコルを使用して、ローカル候補情報をエージェントRに送信します。
Messages 4-5: Agent R gathers a host candidate from its local IP address, and from that it sends a STUN Binding request to the STUN server. Since agent R is not behind a NAT, R's server-reflexive candidate will be identical to the host candidate.
メッセージ4-5：エージェントRはローカルIPアドレスからホスト候補を収集し、そこからSTUNバインディング要求をSTUNサーバーに送信します。エージェントRはNATの背後にないため、Rのサーバー再帰候補はホスト候補と同一になります。
Message 6: Agent R sends its local candidate information to agent L, using the signaling protocol associated with the ICE usage.
メッセージ6：エージェントRは、ICEの使用に関連付けられたシグナリングプロトコルを使用して、ローカル候補情報をエージェントLに送信します。
Since both agents are full ICE implementations, the initiating agent (agent L) becomes the controlling agent.
両方のエージェントが完全なICE実装であるため、開始エージェント（エージェントL）が制御エージェントになります。
Agents L and R both pair up the candidates. Both agents initially have one pair each. At agent L, the pair (L1) has a local candidate of $L_PUB_1 and a remote candidate of $R_PUB_1. At agent R, the pair (R1) has a local candidate of $R_PUB_1 and a remote candidate of $L_PUB_1. The pairs are shown below (the pair numbers are for reference purpose only):
エージェントLとRの両方が候補をペアにします。両方のエージェントには、最初はそれぞれ1つのペアがあります。エージェントLでは、ペア（L1）に$ L_PUB_1のローカル候補と$ R_PUB_1のリモート候補があります。エージェントRでは、ペア（R1）に$ R_PUB_1のローカル候補と$ L_PUB_1のリモート候補があります。ペアを以下に示します（ペア番号は参照専用です）。
Pairs
ENTITY Local Remote Pair # Valid
------------------------------------------------------------------
ICE Agent L: L_PUB_1 R_PUB_1 L1
ICE Agent R: R_PUB_1 L_PUB_1 R1
ICEエージェントR：R_PUB_1 L_PUB_1 R1
Messages 7-8: Agent L initiates a connectivity check for pair L1. The check succeeds, and the pair (L1) is added to the valid list of agent L. Agent L can now send and receive data on the pair (L1) if it wishes.
メッセージ7-8：エージェントLがペアL1の接続性チェックを開始します。チェックが成功し、ペア（L1）がエージェントLの有効なリストに追加されます。エージェントLは、必要に応じてペア（L1）でデータを送受信できます。
Pairs
ENTITY Local Remote Pair # Valid
------------------------------------------------------------------
ICE Agent L: L_PUB_1 R_PUB_1 L1 X
ICE Agent R: R_PUB_1 L_PUB_1 R1
ICEエージェントR：R_PUB_1 L_PUB_1 R1
Messages 9-10: When agent R receives the Binding request from agent L (message 7), it will initiate a triggered connectivity check. The pair matches agent R's existing pair (R1). The check succeeds, and the pair (R1) is added to the valid list of agent R. Agent R can now send and receive data on the pair (R1) if it wishes.
メッセージ9-10：エージェントRがエージェントLからバインディング要求を受信すると（メッセージ7）、トリガーされた接続性チェックを開始します。このペアは、エージェントRの既存のペア（R1）と一致します。チェックが成功し、ペア（R1）がエージェントRの有効なリストに追加されます。エージェントRは、必要に応じてペア（R1）でデータを送受信できます。
Pairs
ENTITY Local Remote Pair # Valid
------------------------------------------------------------------
ICE Agent L: L_PUB_1 R_PUB_1 L1 X
ICE Agent R: R_PUB_1 L_PUB_1 R1 X
ICEエージェントR：R_PUB_1 L_PUB_1 R1 X
Messages 11-12: At some point, the controlling agent (agent L) decides to nominate a pair (L1) in the valid list. It performs a connectivity check on the pair (L1) and includes the USE-CANDIDATE attribute in the Binding request. As the check succeeds, agent L sets the nominated flag value of the pair (L1) to 'true', and agent R sets the nominated flag value of the matching pair (R1) to 'true'.
メッセージ11-12：ある時点で、制御エージェント（エージェントL）は、有効なリストのペア（L1）を指名することを決定します。ペア（L1）の接続性チェックを実行し、USE-CANDIDATE属性をバインディング要求に含めます。チェックが成功すると、エージェントLはペアの指定されたフラグ値（L1）を「true」に設定し、エージェントRは一致するペアの指定されたフラグ値（R1）を「true」に設定します。
As there are no more components associated with the stream, the nominated pairs become the selected pairs. Consequently, processing for this stream moves into the Completed state. The ICE process also moves into the Completed state.
ストリームに関連付けられたコンポーネントがなくなるため、指定されたペアが選択されたペアになります。その結果、このストリームの処理は完了状態に移行します。 ICEプロセスも完了状態に移行します。
This specification defines four STUN attributes: PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
この仕様は、PRIORITY、USE-CANDIDATE、ICE-CONTROLLED、およびICE-CONTROLLINGの4つのSTUN属性を定義しています。
The PRIORITY attribute indicates the priority that is to be associated with a peer-reflexive candidate, if one will be discovered by this check. It is a 32-bit unsigned integer and has an attribute value of 0x0024.
PRIORITY属性は、このチェックで発見される場合に、ピア・リフレクティブ候補に関連付けられる優先順位を示します。これは32ビットの符号なし整数で、属性値は0x0024です。
The USE-CANDIDATE attribute indicates that the candidate pair resulting from this check will be used for transmission of data. The attribute has no content (the Length field of the attribute is zero); it serves as a flag. It has an attribute value of 0x0025.
USE-CANDIDATE属性は、このチェックの結果の候補ペアがデータの送信に使用されることを示します。属性にコンテンツがありません（属性の長さフィールドはゼロです）。フラグとして機能します。属性値は0x0025です。
The ICE-CONTROLLED attribute is present in a Binding request. The attribute indicates that the client believes it is currently in the controlled role. The content of the attribute is a 64-bit unsigned integer in network byte order, which contains a random number. The number is used for solving role conflicts, when it is referred to as the "tiebreaker value". An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session, unless it has received a 487 response, in which case it MUST change the number (Section 7.2.5.1). The agent MAY change the number when an ICE restart occurs.
ICE-CONTROLLED属性はバインディング要求に存在します。この属性は、クライアントが現在、制御された役割にあると信じていることを示しています。属性の内容は、ネットワークバイトオーダーの64ビット符号なし整数で、乱数が含まれています。この数値は、「タイブレーカー値」と呼ばれる場合に、役割の競合を解決するために使用されます。 ICEエージェントは、487応答を受信していない限り、ICEセッション内のすべてのBindingリクエスト、すべてのストリーム、同じ番号を使用する必要があります。その場合、番号を変更する必要があります（7.2.5.1）。 ICEの再起動が発生すると、エージェントは番号を変更できます（MAY）。
The ICE-CONTROLLING attribute is present in a Binding request. The attribute indicates that the client believes it is currently in the controlling role. The content of the attribute is a 64-bit unsigned integer in network byte order, which contains a random number. As for the ICE-CONTROLLED attribute, the number is used for solving role conflicts. An agent MUST use the same number for all Binding requests, for all streams, within an ICE session, unless it has received a 487 response, in which case it MUST change the number (Section 7.2.5.1). The agent MAY change the number when an ICE restart occurs.
ICE-CONTROLLING属性がバインディング要求に存在します。この属性は、クライアントが現在それを制御している役割であるとクライアントが信じていることを示しています。属性の内容は、ネットワークバイトオーダーの64ビット符号なし整数で、乱数が含まれています。 ICE-CONTROLLED属性の場合、この番号は役割の競合を解決するために使用されます。エージェントは、487応答を受信していない限り、ICEセッション内のすべてのストリーム、すべてのバインディング要求に同じ番号を使用する必要があります。その場合、番号を変更する必要があります（セクション7.2.5.1）。 ICEの再起動が発生すると、エージェントは番号を変更できます（MAY）。
This specification defines a single error-response code:
この仕様では、単一のエラー応答コードを定義しています。
487 (Role Conflict): The Binding request contained either the ICE-CONTROLLING or ICE-CONTROLLED attribute, indicating an ICE role that conflicted with the server. The remote server compared the tiebreaker values of the client and the server and determined that the client needs to switch roles.
487（役割の競合）：バインディング要求には、ICE-CONTROLLINGまたはICE-CONTROLLED属性のいずれかが含まれており、サーバーと競合したICEの役割を示しています。リモートサーバーは、クライアントとサーバーのタイブレーカー値を比較し、クライアントが役割を切り替える必要があると判断しました。
This section discusses issues relevant to operators operating networks where ICE will be used by endpoints.
このセクションでは、エンドポイントがICEを使用するネットワークを運用するオペレーターに関連する問題について説明します。
ICE was designed to work with existing NAT and firewall equipment. Consequently, it is not necessary to replace or reconfigure existing firewall and NAT equipment in order to facilitate deployment of ICE. Indeed, ICE was developed to be deployed in environments where the Voice over IP (VoIP) operator has no control over the IP network infrastructure, including firewalls and NATs.
ICEは、既存のNATおよびファイアウォール機器と連携するように設計されています。したがって、ICEの展開を容易にするために、既存のファイアウォールとNAT機器を交換または再構成する必要はありません。実際、ICEは、Voice over IP（VoIP）オペレーターがファイアウォールやNATなどのIPネットワークインフラストラクチャを制御できない環境に展開するために開発されました。
That said, ICE works best in environments where the NAT devices are "behave" compliant, meeting the recommendations defined in [RFC4787] and [RFC5382]. In networks with behave-compliant NAT, ICE will work without the need for a TURN server, thus improving voice quality, decreasing call setup times, and reducing the bandwidth demands on the network operator.
とはいえ、ICEは、NATデバイスが「動作」に準拠し、[RFC4787]および[RFC5382]で定義された推奨事項を満たす環境で最適に機能します。動作に準拠したNATを備えたネットワークでは、ICEはTURNサーバーがなくても機能するため、音声品質が向上し、通話のセットアップ時間が短縮され、ネットワークオペレーターの帯域幅の需要が減少します。
Deployment of ICE can have several interactions with available network capacity that operators need to take into consideration.
ICEの展開には、利用可能なネットワーク容量とのいくつかの相互作用があり、オペレーターはこれらを考慮する必要があります。
First and foremost, ICE makes use of TURN and STUN servers, which would typically be located in data centers. The STUN servers require relatively little bandwidth. For each component of each data stream, there will be one or more STUN transactions from each client to the STUN server. In a basic voice-only IPv4 VoIP deployment, there will be four transactions per call (one for RTP and one for RTCP, for both the caller and callee). Each transaction is a single request and a single response, the former being 20 bytes long, and the latter, 28.
何よりもまず、ICEは、通常はデータセンターに配置されるTURNサーバーとSTUNサーバーを利用します。 STUNサーバーに必要な帯域幅は比較的少ないです。各データストリームのコンポーネントごとに、各クライアントからSTUNサーバーへの1つ以上のSTUNトランザクションがあります。基本的な音声のみのIPv4 VoIP展開では、呼び出しごとに4つのトランザクションがあります（RTPとRTCPの1つ、呼び出し元と呼び出し先の両方）。各トランザクションは単一の要求と単一の応答であり、前者は長さ20バイト、後者は28バイトです。
Consequently, if a system has N users, and each makes four calls in a busy hour, this would require N*1.7bps. For one million users, this is 1.7 Mbps, a very small number (relatively speaking).
したがって、システムにN人のユーザーがいて、それぞれが最繁時に1回に4つの呼び出しを行う場合、これにはN * 1.7bpsが必要になります。 100万人のユーザーの場合、これは1.7 Mbpsと非常に小さな数です（比較的言えば）。
TURN traffic is more substantial. The TURN server will see traffic volume equal to the STUN volume (indeed, if TURN servers are deployed, there is no need for a separate STUN server), in addition to the traffic for the actual data. The amount of calls requiring TURN for data relay is highly dependent on network topologies, and can and will vary over time. In a network with 100% behave-compliant NATs, it is exactly zero.
TURNトラフィックはより多くなります。 TURNサーバーには、実際のデータのトラフィックに加えて、STUNボリュームに等しいトラフィックボリュームが表示されます（実際に、TURNサーバーがデプロイされている場合、個別のSTUNサーバーは必要ありません）。データリレーのためにTURNを必要とする呼び出しの量は、ネットワークトポロジに大きく依存し、時間とともに変化する可能性があります。 100％動作に準拠したNATを備えたネットワークでは、これは完全にゼロです。
The planning considerations above become more significant in multimedia scenarios (e.g., audio and video conferences) and when the numbers of participants in a session grow.
上記の計画に関する考慮事項は、マルチメディアシナリオ（オーディオ会議やビデオ会議など）やセッションの参加者数が増える場合により重要になります。
The process of gathering candidates and performing connectivity checks can be bandwidth intensive. ICE has been designed to pace both of these processes. The gathering and connectivity-check phases are meant to generate traffic at roughly the same bandwidth as the data traffic itself will consume once the ICE process concludes. This was done to ensure that if a network is designed to support communication traffic of a certain type (voice, video, or just text), it will have sufficient capacity to support the ICE checks for that data. Once ICE has concluded, the subsequent ICE keepalives will later cause a marginal increase in the total bandwidth utilization; however, this will typically be an extremely small increase.
候補を収集して接続性チェックを実行するプロセスは、帯域幅を大量に消費する可能性があります。 ICEは、これらのプロセスの両方に対応できるように設計されています。収集および接続性チェックのフェーズは、ICEプロセスが完了すると、データトラフィック自体が消費するのとほぼ同じ帯域幅でトラフィックを生成することを目的としています。これは、ネットワークが特定のタイプ（音声、ビデオ、またはテキストのみ）の通信トラフィックをサポートするように設計されている場合、そのデータのICEチェックをサポートするのに十分な容量があることを確認するために行われました。 ICEが終了すると、その後のICEキープアライブにより、総帯域幅使用率がわずかに増加します。ただし、これは通常、ごくわずかな増加です。
Congestion due to the gathering and check phases has proven to be a problem in deployments that did not utilize pacing. Typically, access links became congested as the endpoints flooded the network with checks as fast as they could send them. Consequently, network operators need to ensure that their ICE implementations support the pacing feature. Though this pacing does increase call setup times, it makes ICE network friendly and easier to deploy.
収集フェーズとチェックフェーズによる輻輳は、ペーシングを利用しない展開では問題であることが判明しています。通常、アクセスリンクは、エンドポイントが送信できる限りの速さでチェックでネットワークをフラッディングするため、輻輳しました。したがって、ネットワークオペレーターは、ICE実装がペーシング機能をサポートしていることを確認する必要があります。このペーシングはコールセットアップ時間を増加させますが、ICEネットワークを使いやすく、展開しやすくします。
STUN keepalives (in the form of STUN Binding Indications) are sent in the middle of a data session. However, they are sent only in the absence of actual data traffic. In deployments with continuous media and without utilizing Voice Activity Detection (VAD), or deployments where VAD is utilized together with short interval (max 1 second) comfort noise, the keepalives are never used and there is no increase in bandwidth usage. When VAD is being used without comfort noise, keepalives will be sent during silence periods. This involves a single packet every 15-20 seconds, far less than the packet every 20-30 ms that is sent when there is voice. Therefore, keepalives do not have any real impact on capacity planning.
STUNキープアライブ（STUNバインディング表示の形式）は、データセッションの途中で送信されます。ただし、実際のデータトラフィックがない場合にのみ送信されます。継続的なメディアがあり、Voice Activity Detection（VAD）を利用しない展開、またはVADが短い間隔（最大1秒）のコンフォートノイズと一緒に利用されている展開では、キープアライブが使用されることはなく、帯域幅の使用量は増加しません。 VADがコンフォートノイズなしで使用されている場合、沈黙期間中にキープアライブが送信されます。これには、15〜20秒ごとに1つのパケットが含まれ、音声があるときに送信される20〜30ミリ秒ごとのパケットよりもはるかに少なくなります。したがって、キープアライブはキャパシティプランニングに実際の影響を与えません。
Deployments utilizing a mix of ICE and ICE-lite interoperate with each other. They have been explicitly designed to do so.
ICEとICE-liteの組み合わせを利用した展開は、相互運用できます。それらは明示的にそうするように設計されています。
However, ICE-lite can only be deployed in limited use cases. Those cases, and the caveats involved in doing so, are documented in Appendix A.
ただし、ICE-liteは限られた使用例でのみ展開できます。これらのケース、およびその場合の注意事項については、付録Aに記載されています。
ICE utilizes end-to-end connectivity checks and places much of the processing in the endpoints. This introduces a challenge to the network operator -- how can they troubleshoot ICE deployments? How can they know how ICE is performing?
ICEは、エンドツーエンドの接続チェックを利用し、処理の多くをエンドポイントに配置します。これは、ネットワークオペレーターに課題をもたらします。ICE展開のトラブルシューティングをどのように行うことができますか？ ICEのパフォーマンスをどのようにして知ることができますか？
ICE has built-in features to help deal with these problems. Signaling servers, typically deployed in data centers of the network operator, will see the contents of the candidate exchanges that convey the ICE parameters. These parameters include the type of each candidate (host, server reflexive, or relayed), along with their related addresses. Once ICE processing has completed, an updated candidate exchange takes place, signaling the selected address (and its type). This updated signaling is performed exactly for the purposes of educating network equipment (such as a diagnostic tool attached to a signaling) about the results of ICE processing.
ICEには、これらの問題への対処に役立つ組み込みの機能があります。通常、ネットワークオペレーターのデータセンターに展開されているシグナリングサーバーは、ICEパラメータを伝達する交換候補のコンテンツを参照します。これらのパラメーターには、関連するアドレスとともに、各候補のタイプ（ホスト、サーバー再帰、またはリレー）が含まれます。 ICE処理が完了すると、更新された候補交換が行われ、選択したアドレス（およびそのタイプ）が通知されます。この更新されたシグナリングは、ICE処理の結果についてネットワーク機器（シグナリングに接続された診断ツールなど）を教育する目的で正確に実行されます。
As a consequence, through the logs generated by a signaling server, a network operator can observe what types of candidates are being used for each call and what addresses were selected by ICE. This is the primary information that helps evaluate how ICE is performing.
その結果、シグナリングサーバーによって生成されたログを介して、ネットワークオペレーターは、各コールで使用されている候補のタイプと、ICEによって選択されたアドレスを監視できます。これは、ICEのパフォーマンスの評価に役立つ主要な情報です。
ICE relies on several pieces of data being configured into the endpoints. This configuration data includes timers, credentials for TURN servers, and hostnames for STUN and TURN servers. ICE itself does not provide a mechanism for this configuration. Instead, it is assumed that this information is attached to whatever mechanism is used to configure all of the other parameters in the endpoint. For SIP phones, standard solutions such as the configuration framework [RFC6080] have been defined.
ICEは、エンドポイントに構成されているいくつかのデータに依存しています。この構成データには、タイマー、TURNサーバーの資格情報、STUNサーバーとTURNサーバーのホスト名が含まれます。 ICE自体は、この構成のメカニズムを提供しません。代わりに、この情報は、エンドポイントの他のすべてのパラメーターを構成するために使用されるメカニズムに添付されていると想定されます。 SIP電話の場合、構成フレームワーク[RFC6080]などの標準ソリューションが定義されています。
The IAB has studied the problem of "Unilateral Self-Address Fixing" (UNSAF), which is the general process by which an ICE agent attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. ICE is an example of a protocol that performs this type of function. Interestingly, the process for ICE is not unilateral, but bilateral, and the difference has a significant impact on the issues raised by the IAB. Indeed, ICE can be considered a Bilateral Self-Address Fixing (B-SAF) protocol, rather than an UNSAF protocol. Regardless, the IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
IABは、「片側自己アドレス修正」（UNSAF）の問題を調査しました。これは、協調エージェントリフレクションメカニズムを介して、ICEエージェントがNATの反対側にある別のレルムでアドレスを決定しようとする一般的なプロセスです[ RFC3424]。 ICEは、このタイプの機能を実行するプロトコルの例です。興味深いことに、ICEのプロセスは一方的ではなく二国間であり、その違いはIABが提起する問題に大きな影響を与えます。実際、ICEはUNSAFプロトコルではなく、Bilateral Self-Address Fixing（B-SAF）プロトコルと見なすことができます。とにかく、IABは、この目的のために開発されたすべてのプロトコルが特定の一連の考慮事項を文書化することを義務付けています。このセクションはそれらの要件を満たしています。
From RFC 3424, any UNSAF proposal needs to provide:
RFC 3424から、UNSAF提案は以下を提供する必要があります：
Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems. Such generalizations lead to the the prolonged dependence on and usage of the supposed short term fix -- meaning that it is no longer accurate to call it "short term".
UNSAF提案で解決される特定の限定スコープ問題の正確な定義。短期的な修正は、他の問題を解決するために一般化されるべきではありません。このような一般化は、想定された短期修正への長期にわたる依存と使用につながります。つまり、「短期」と呼ぶことはもはや正確ではありません。
The specific problems being solved by ICE are:
ICEによって解決される特定の問題は次のとおりです。
Providing a means for two peers to determine the set of transport addresses that can be used for communication.
2つのピアが通信に使用できるトランスポートアドレスのセットを決定する手段を提供します。
Providing a means for an agent to determine an address that is reachable by another peer with which it wishes to communicate.
エージェントが通信したい別のピアから到達可能なアドレスを決定する手段をエージェントに提供する。
From RFC 3424, any UNSAF proposal needs to provide:
RFC 3424から、UNSAF提案は以下を提供する必要があります：
Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
出口戦略/移行計画の説明。適切なテクノロジーが導入されるにつれて、より良い短期間の修正は、当然ながら使用がますます少なくなる修正です。
ICE itself doesn't easily get phased out. However, it is useful even in a globally connected Internet, to serve as a means for detecting whether a router failure has temporarily disrupted connectivity, for example. ICE also helps prevent certain security attacks that have nothing to do with NAT. However, what ICE does is help phase out other UNSAF mechanisms. ICE effectively picks amongst those mechanisms, prioritizing ones that are better and deprioritizing ones that are worse. As NATs begin to dissipate as IPv6 is introduced, server-reflexive and relayed candidates (both forms of UNSAF addresses) simply never get used, because higher-priority connectivity exists to the native host candidates. Therefore, the servers get used less and less and can eventually be removed when their usage goes to zero.
ICE自体は簡単に段階的に廃止されません。ただし、たとえばグローバルに接続されたインターネットでも、ルーターの障害によって接続が一時的に中断されたかどうかを検出する手段として役立ちます。 ICEは、NATとは関係のない特定のセキュリティ攻撃の防止にも役立ちます。ただし、ICEは他のUNSAFメカニズムを段階的に廃止するのに役立ちます。 ICEはこれらのメカニズムの中から効果的に選択し、より優れたメカニズムに優先順位を付け、より悪いメカニズムに優先順位を付けません。 IPv6の導入に伴い、NATが散逸し始めると、ネイティブホスト候補への接続の優先順位が高くなるため、サーバー再帰型および中継候補（両方の形式のUNSAFアドレス）が使用されることはありません。したがって、サーバーの使用率は低下し、使用率がゼロになったときに削除することができます。
Indeed, ICE can assist in the transition from IPv4 to IPv6. It can be used to determine whether to use IPv6 or IPv4 when two dual-stack hosts communicate with SIP (IPv6 gets used). It can also allow a network with both 6to4 and native v6 connectivity to determine which address to use when communicating with a peer.
実際、ICEはIPv4からIPv6への移行を支援できます。 2つのデュアルスタックホストがSIPと通信するときにIPv6を使用するかIPv4を使用するかを決定するために使用できます（IPv6が使用されます）。また、6to4接続とネイティブv6接続の両方を備えたネットワークが、ピアとの通信時に使用するアドレスを決定できるようにすることもできます。
From RFC 3424, any UNSAF proposal needs to provide:
RFC 3424から、UNSAF提案は以下を提供する必要があります：
Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
システムをより「脆弱」にする可能性のある特定の問題についての議論。たとえば、複数のネットワークレイヤーでデータを使用するアプローチでは、依存関係が増え、デバッグの課題が増え、移行が困難になります。
ICE actually removes brittleness from existing UNSAF mechanisms. In particular, classic STUN (as described in RFC 3489 [RFC3489]) has several points of brittleness. One of them is the discovery process that requires an ICE agent to try to classify the type of NAT it is behind. This process is error prone. With ICE, that discovery process is simply not used. Rather than unilaterally assessing the validity of the address, its validity is dynamically determined by measuring connectivity to a peer. The process of determining connectivity is very robust.
ICEは実際に、既存のUNSAFメカニズムから脆弱性を取り除きます。特に、古典的なSTUN（RFC 3489 [RFC3489]で説明されている）には、いくつかの脆弱な点があります。それらの1つは、ICEエージェントが背後にあるNATのタイプを分類しようとすることを要求する検出プロセスです。このプロセスはエラーが発生しやすくなります。 ICEでは、その発見プロセスは単に使用されません。アドレスの有効性を一方的に評価するのではなく、その有効性は、ピアへの接続を測定することによって動的に決定されます。接続性を決定するプロセスは非常に堅牢です。
Another point of brittleness in classic STUN and any other unilateral mechanism is its absolute reliance on an additional server. ICE makes use of a server for allocating unilateral addresses, but it allows agents to directly connect if possible. Therefore, in some cases, the failure of a STUN server would still allow for a call to progress when ICE is used.
従来のSTUNおよびその他の一方的なメカニズムの脆弱性のもう1つのポイントは、追加のサーバーへの絶対的な依存です。 ICEは、一方的なアドレスを割り当てるためにサーバーを使用しますが、可能であればエージェントが直接接続することを許可します。したがって、場合によっては、ICEが使用されている場合でも、STUNサーバーに障害が発生しても、通話が進行する可能性があります。
Another point of brittleness in classic STUN is that it assumes the STUN server is on the public Internet. Interestingly, with ICE, that is not necessary. There can be a multitude of STUN servers in a variety of address realms. ICE will discover the one that has provided a usable address.
従来のSTUNのもう1つの脆弱性は、STUNサーバーがパブリックインターネット上にあると想定していることです。興味深いことに、ICEでは、これは必要ありません。さまざまなアドレスレルムに多数のSTUNサーバーが存在する可能性があります。 ICEは、使用可能なアドレスを提供したアドレスを検出します。
The most troubling point of brittleness in classic STUN is that it doesn't work in all network topologies. In cases where there is a shared NAT between each agent and the STUN server, traditional STUN may not work. With ICE, that restriction is removed.
古典的なSTUNの脆弱性の最も厄介な点は、すべてのネットワークトポロジで機能しないことです。各エージェントとSTUNサーバーの間に共有NATがある場合、従来のSTUNは機能しない可能性があります。 ICEでは、その制限は取り除かれました。
Classic STUN also introduces some security considerations. Fortunately, those security considerations are also mitigated by ICE.
クラシックSTUNでは、セキュリティに関する考慮事項もいくつか導入されています。幸いにも、これらのセキュリティに関する考慮事項はICEによって軽減されます。
Consequently, ICE serves to repair the brittleness introduced in classic STUN, and it does not introduce any additional brittleness into the system.
その結果、ICEはクラシックSTUNで導入された脆弱性を修復するのに役立ち、システムに追加の脆弱性を導入することはありません。
The penalty of these improvements is that ICE increases session establishment times.
これらの改善のペナルティは、ICEがセッション確立時間を増加させることです。
From RFC 3424, any UNSAF proposal needs to provide the following:
RFC 3424から、UNSAF提案は以下を提供する必要があります。
Identify requirements for longer term, sound technical solutions; contribute to the process of finding the right longer term solution.
長期的で健全な技術ソリューションの要件を特定します。適切な長期的なソリューションを見つけるプロセスに貢献します。
Our conclusions from RFC 3489 remain unchanged. However, we feel ICE actually helps because we believe it can be part of the long-term solution.
RFC 3489からの結論は変更されていません。ただし、ICEは長期的なソリューションの一部になる可能性があるため、ICEが実際に役立つと感じています。
From RFC 3424, any UNSAF proposal needs to provide:
RFC 3424から、UNSAF提案は以下を提供する必要があります：
Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
既存の展開されたNA [P] Tとの経験的報告による、言及された実際的な問題の影響についての議論。
A number of NAT boxes are now being deployed into the market that try to provide "generic" ALG functionality. These generic ALGs hunt for IP addresses, in either text or binary form within a packet, and rewrite them if they match a binding. This interferes with classic STUN. However, the update to STUN [RFC5389] uses an encoding that hides these binary addresses from generic ALGs.
現在、「汎用」ALG機能を提供しようとする多くのNATボックスが市場に導入されています。これらの汎用ALGは、パケット内のテキスト形式またはバイナリ形式でIPアドレスを探し、バインディングと一致する場合はそれらを書き換えます。これは、従来のSTUNを妨害します。ただし、STUN [RFC5389]へのアップデートでは、これらのバイナリアドレスを一般的なALGから隠すエンコーディングを使用しています。
Existing NAPT boxes have non-deterministic and typically short expiration times for UDP-based bindings. This requires implementations to send periodic keepalives to maintain those bindings. ICE uses a default of 15 s, which is a very conservative estimate. Eventually, over time, as NAT boxes become compliant to behave [RFC4787], this minimum keepalive will become deterministic and well known, and the ICE timers can be adjusted. Having a way to discover and control the minimum keepalive interval would be far better still.
既存のNAPTボックスは非決定的であり、通常、UDPベースのバインディングの有効期限は短いです。これには、これらのバインディングを維持するために、実装に定期的なキープアライブを送信する必要があります。 ICEはデフォルトの15秒を使用します。これは非常に控えめな見積もりです。最終的に、時間の経過とともに、NATボックスが動作するように準拠するようになると[RFC4787]、この最小キープアライブが確定的かつ周知となり、ICEタイマーを調整できます。最小キープアライブインターバルを検出して制御する方法があれば、はるかに優れています。
The process of probing for candidates reveals the source addresses of the client and its peer to any on-network listening attacker, and the process of exchanging candidates reveals the addresses to any attacker that is able to see the negotiation. Some addresses, such as the server-reflexive addresses gathered through the local interface of VPN users, may be sensitive information. If these potential attacks cannot be mitigated, ICE usages can define mechanisms for controlling which addresses are revealed to the negotiation and/or probing process. Individual implementations may also have implementation-specific rules for controlling which addresses are revealed. For example, [WebRTC-IP-HANDLING] provides additional information about the privacy aspects of revealing IP addresses via ICE for WebRTC applications. ICE implementations where such issues can arise are RECOMMENDED to provide a programmatic or user interface that provides control over which network interfaces are used to generate candidates.
候補をプローブするプロセスは、クライアントとそのピアの送信元アドレスをネットワーク上のリスニング攻撃者に明らかにし、候補を交換するプロセスは、ネゴシエーションを見ることができるすべての攻撃者にアドレスを明らかにします。 VPNユーザーのローカルインターフェイスを介して収集されたサーバー再帰アドレスなど、一部のアドレスは機密情報である可能性があります。これらの潜在的な攻撃を緩和できない場合、ICEの使用法は、ネゴシエーションやプロービングプロセスに公開されるアドレスを制御するメカニズムを定義できます。個々の実装には、どのアドレスを公開するかを制御するための実装固有のルールがある場合もあります。たとえば、[WebRTC-IP-HANDLING]は、ICEを介してWebRTCアプリケーションのIPアドレスを公開するプライバシーの側面に関する追加情報を提供します。このような問題が発生する可能性があるICE実装は、候補を生成するために使用されるネットワークインターフェイスを制御するプログラムまたはユーザーインターフェイスを提供するために推奨されます。
Based on the types of candidates provided by the peer, and the results of the connectivity tests performed against those candidates, the peer might be able to determine characteristics of the local network, e.g., if different timings are apparent to the peer. Within the limit, the peer might be able to probe the local network.
ピアによって提供される候補のタイプ、およびそれらの候補に対して実行された接続性テストの結果に基づいて、ピアは、たとえば、ピアに異なるタイミングが明らかである場合、ローカルネットワークの特性を決定できる場合があります。制限内では、ピアはローカルネットワークをプローブできる可能性があります。
There are several types of attacks possible in an ICE system. The subsections consider these attacks and their countermeasures.
ICEシステムでは、いくつかのタイプの攻撃が可能です。サブセクションでは、これらの攻撃とその対策を検討します。
An attacker might attempt to disrupt the STUN connectivity checks. Ultimately, all of these attacks fool an ICE agent into thinking something incorrect about the results of the connectivity checks. Depending on the type of attack, the attacker needs to have different capabilities. In some cases, the attacker needs to be on the path of the connectivity checks. In other cases, the attacker does not need to be on the path, as long as it is able to generate STUN connectivity checks. While attacks on connectivity checks are typically performed by network entities, if an attacker is able to control an endpoint, it might be able to trigger connectivity-check attacks. The possible false conclusions an attacker can try and cause are: False Invalid: An attacker can fool a pair of agents into thinking a candidate pair is invalid, when it isn't. This can be used to cause an agent to prefer a different candidate (such as one injected by the attacker) or to disrupt a call by forcing all candidates to fail.
攻撃者は、STUN接続チェックを妨害しようと試みる可能性があります。結局のところ、これらの攻撃はすべて、ICEエージェントをだまして、接続チェックの結果について何かが間違っていると考えさせます。攻撃の種類に応じて、攻撃者は異なる機能を持つ必要があります。場合によっては、攻撃者は接続チェックのパス上にいる必要があります。他の場合では、STUN接続性チェックを生成できる限り、攻撃者はパス上にいる必要はありません。接続性チェックに対する攻撃は通常ネットワークエンティティによって実行されますが、攻撃者がエンドポイントを制御できる場合、接続性チェック攻撃をトリガーできる可能性があります。攻撃者が試行して引き起こす可能性のある誤った結論は次のとおりです。False無効：攻撃者はペアのエージェントをだまして、無効な候補ペアが無効であると考えさせることができます。これを使用して、エージェントに別の候補（攻撃者によって挿入された候補など）を優先させるか、すべての候補を強制的に失敗させることによってコールを中断させることができます。
False Valid: An attacker can fool a pair of agents into thinking a candidate pair is valid, when it isn't. This can cause an agent to proceed with a session but then not be able to receive any data.
False Valid：攻撃者はペアのエージェントをだまして、候補のペアが有効でない場合に有効であると考えさせることができます。これにより、エージェントはセッションを続行できますが、データを受信できなくなります。
False Peer-Reflexive Candidate: An attacker can cause an agent to discover a new peer-reflexive candidate when it is not expected to. This can be used to redirect data streams to a DoS target or to the attacker, for eavesdropping or other purposes.
偽のピア・リフレクティブ候補：攻撃者は、予期しないときにエージェントに新しいピア・リフレクティブ候補を発見させることができます。これは、盗聴やその他の目的で、データストリームをDoSターゲットまたは攻撃者にリダイレクトするために使用できます。
False Valid on False Candidate: An attacker has already convinced an agent that there is a candidate with an address that does not actually route to that agent (e.g., by injecting a false peer-reflexive candidate or false server-reflexive candidate). The attacker then launches an attack that forces the agents to believe that this candidate is valid.
False候補でFalse有効：攻撃者は、エージェントに実際にルーティングされないアドレスを持つ候補があることをエージェントにすでに確信させています（たとえば、偽のピア再帰候補または偽のサーバー再帰候補を挿入することにより）。その後、攻撃者は攻撃を開始し、エージェントにこの候補者が有効であると信じ込ませます。
If an attacker can cause a false peer-reflexive candidate or false valid on a false candidate, it can launch any of the attacks described in [RFC5389].
攻撃者が偽のピアリフレクティブ候補または偽の候補に対して偽の有効性を引き起こすことができる場合、[RFC5389]で説明されている攻撃のいずれかを開始する可能性があります。
To force the false invalid result, the attacker has to wait for the connectivity check from one of the agents to be sent. When it is, the attacker needs to inject a fake response with an unrecoverable error response (such as a 400), or drop the response so that it never reaches the agent. However, since the candidate is, in fact, valid, the original request may reach the peer agent and result in a success response. The attacker needs to force this packet or its response to be dropped through a DoS attack, a Layer 2 network disruption, or another technique. If it doesn't do this, the success response will also reach the originator, alerting it to a possible attack. The ability for the attacker to generate a fake response is mitigated through the STUN short-term credential mechanism. In order for this response to be processed, the attacker needs the password. If the candidate exchange signaling is secured, the attacker will not have the password, and its response will be discarded.
不正な無効な結果を強制するには、攻撃者はいずれかのエージェントからの接続性チェックが送信されるのを待つ必要があります。その場合、攻撃者は、回復不可能なエラー応答（400など）を含む偽の応答を挿入するか、応答をドロップしてエージェントに到達しないようにする必要があります。ただし、候補は実際には有効であるため、元の要求がピアエージェントに到達し、応答が成功する可能性があります。攻撃者は、このパケットまたはその応答を、DoS攻撃、レイヤ2ネットワークの中断、または別の手法で強制的にドロップする必要があります。これを行わない場合、成功の応答も発信者に到達し、攻撃の可能性があることを警告します。攻撃者が偽の応答を生成する能力は、STUN短期資格情報メカニズムによって軽減されます。この応答を処理するには、攻撃者がパスワードを必要とします。候補交換シグナリングが保護されている場合、攻撃者はパスワードを入手できず、その応答は破棄されます。
Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be used to create false invalid results. If an ICE agent implements a response to these ICMP errors, the attacker is capable of generating an ICMP message that is delivered to the agent sending the connectivity check. The validation of the ICMP error message by the agent is its only defense. For Type 3 code=4, the outer IP header provides no validation, unless the connectivity check was sent with DF=0. For codes 2 or 3, which are originated by the host, the address is expected to be any of the remote agent's host, reflexive, or relay candidate IP addresses. The ICMP message includes the IP header and UDP header of the message triggering the error. These fields also need to be validated. The IP destination and UDP destination port need to match either the targeted candidate address and port or the candidate's base address. The source IP address and port can be any candidate for the same base address of the agent sending the connectivity check. Thus, any attacker having access to the exchange of the candidates will have the necessary information. Hence, the validation is a weak defense, and the sending of spoofed ICMP attacks is also possible for off-path attackers from a node in a network without source address validation.
なりすましICMPハードエラー（タイプ3、コード2〜4）を使用して、無効な無効な結果を作成することもできます。 ICEエージェントがこれらのICMPエラーへの応答を実装する場合、攻撃者は、接続チェックを送信するエージェントに配信されるICMPメッセージを生成できます。エージェントによるICMPエラーメッセージの検証が唯一の防御手段です。タイプ3 code = 4の場合、接続チェックがDF = 0で送信されない限り、外部IPヘッダーは検証を提供しません。ホストから発信されたコード2または3の場合、アドレスは、リモートエージェントのホスト、再帰、またはリレーの候補IPアドレスのいずれかであることが期待されます。 ICMPメッセージには、エラーをトリガーするメッセージのIPヘッダーとUDPヘッダーが含まれます。これらのフィールドも検証する必要があります。 IP宛先とUDP宛先ポートは、ターゲットとなる候補アドレスとポート、または候補のベースアドレスと一致する必要があります。送信元IPアドレスとポートは、接続性チェックを送信するエージェントの同じベースアドレスの候補になります。したがって、候補者の交換にアクセスできる攻撃者は、必要な情報を入手できます。したがって、検証は弱い防御であり、送信元アドレスの検証なしに、ネットワーク内のノードからパスを離れた攻撃者が偽装ICMP攻撃を送信することも可能です。
Forcing the fake valid result works in a similar way. The attacker needs to wait for the Binding request from each agent and inject a fake success response. Again, due to the STUN short-term credential mechanism, in order for the attacker to inject a valid success response, the attacker needs the password. Alternatively, the attacker can route (e.g., using a tunneling mechanism) a valid success response, which normally would be dropped or rejected by the network, to the agent.
偽の有効な結果を強制することは、同様の方法で機能します。攻撃者は、各エージェントからのバインディング要求を待機し、偽の成功応答を挿入する必要があります。繰り返しになりますが、STUNの短期的な認証メカニズムにより、攻撃者が有効な成功応答を注入するためには、攻撃者はパスワードを必要とします。または、攻撃者は、通常はネットワークによってドロップまたは拒否される有効な成功応答をエージェントにルーティングする（トンネリングメカニズムを使用するなど）ことができます。
Forcing the false peer-reflexive candidate result can be done with either fake requests or responses, or with replays. We consider the fake requests and responses case first. It requires the attacker to send a Binding request to one agent with a source IP address and port for the false candidate. In addition, the attacker needs to wait for a Binding request from the other agent and generate a fake response with a XOR-MAPPED-ADDRESS attribute containing the false candidate. Like the other attacks described here, this attack is mitigated by the STUN message integrity mechanisms and secure candidate exchanges.
偽のピア・リフレクティブ候補の結果を強制することは、偽の要求または応答のいずれか、あるいはリプレイで行うことができます。偽のリクエストとレスポンスのケースを最初に検討します。攻撃者は、偽の候補のソースIPアドレスとポートを使用して1つのエージェントにバインド要求を送信する必要があります。さらに、攻撃者は他のエージェントからのBindingリクエストを待機し、偽の候補を含むXOR-MAPPED-ADDRESS属性を持つ偽の応答を生成する必要があります。ここで説明する他の攻撃と同様に、この攻撃はSTUNメッセージの整合性メカニズムと安全な候補交換によって軽減されます。
Forcing the false peer-reflexive candidate result with packet replays is different. The attacker waits until one of the agents sends a check. It intercepts this request and replays it towards the other agent with a faked source IP address. It also needs to prevent the original request from reaching the remote agent, by either launching a DoS attack to cause the packet to be dropped or forcing it to be dropped using Layer 2 mechanisms. The replayed packet is received at the other agent, and accepted, since the integrity check passes (the integrity check cannot and does not cover the source IP address and port). It is then responded to. This response will contain a XOR-MAPPED-ADDRESS with the false candidate, and it will be sent to that false candidate. The attacker then needs to receive it and relay it towards the originator.
ピアリフレクシブ候補の結果をパケットリプレイで強制することは異なります。攻撃者は、いずれかのエージェントがチェックを送信するまで待機します。このリクエストをインターセプトし、偽のソースIPアドレスを持つ他のエージェントに向けて再生します。また、DoS攻撃を開始してパケットをドロップさせるか、レイヤ2メカニズムを使用して強制的にドロップさせることにより、元のリクエストがリモートエージェントに到達しないようにする必要もあります。整合性チェックに合格したため、再生されたパケットは他のエージェントで受信され、受け入れられます（整合性チェックは送信元IPアドレスとポートをカバーできず、カバーしません）。その後、応答されます。この応答には、偽の候補のXOR-MAPPED-ADDRESSが含まれ、その偽の候補に送信されます。攻撃者はそれを受信し、発信者に中継する必要があります。
The other agent will then initiate a connectivity check towards that false candidate. This validation needs to succeed. This requires the attacker to force a false valid on a false candidate. The injecting of fake requests or responses to achieve this goal is prevented using the integrity mechanisms of STUN and the candidate exchange. Thus, this attack can only be launched through replays. To do that, the attacker needs to intercept the check towards this false candidate and replay it towards the other agent. Then, it needs to intercept the response and replay that back as well.
次に、他のエージェントはその偽の候補に向けて接続性チェックを開始します。この検証は成功する必要があります。これは、攻撃者が偽の候補に対して偽の有効を強制することを要求します。この目標を達成するための偽の要求または応答の挿入は、STUNと候補交換の整合性メカニズムを使用して防止されます。したがって、この攻撃はリプレイによってのみ開始できます。これを行うには、攻撃者はこの偽の候補に対するチェックをインターセプトし、他のエージェントに対してそれを再生する必要があります。次に、応答をインターセプトし、それを再生する必要があります。
This attack is very hard to launch unless the attacker is identified by the fake candidate. This is because it requires the attacker to intercept and replay packets sent by two different hosts. If both agents are on different networks (e.g., across the public Internet), this attack can be hard to coordinate, since it needs to occur against two different endpoints on different parts of the network at the same time.
この攻撃は、攻撃者が偽の候補者によって識別されない限り、起動するのが非常に困難です。これは、攻撃者が2つの異なるホストから送信されたパケットを傍受して再生する必要があるためです。両方のエージェントが異なるネットワーク上にある場合（たとえば、公衆インターネット全体）、この攻撃はネットワークの異なる部分にある2つの異なるエンドポイントに対して同時に発生する必要があるため、調整が難しい場合があります。
If the attacker itself is identified by the fake candidate, the attack is easier to coordinate. However, if the data path is secured (e.g., using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), the attacker will not be able to process the data packets, but will only be able to discard them, effectively disabling the data stream. However, this attack requires the agent to disrupt packets in order to block the connectivity check from reaching the target. In that case, if the goal is to disrupt the data stream, it's much easier to just disrupt it with the same mechanism, rather than attack ICE.
攻撃者自身が偽の候補者によって識別された場合、攻撃の調整が容易になります。ただし、データパスが保護されている場合（たとえば、Secure Real-time Transport Protocol（SRTP）[RFC3711]を使用）、攻撃者はデータパケットを処理することはできず、破棄することしかできず、事実上無効になります。データストリーム。ただし、この攻撃では、接続チェックがターゲットに到達するのをブロックするために、エージェントがパケットを中断する必要があります。その場合、データストリームを中断することが目的であれば、ICEを攻撃するよりも、同じメカニズムでそれを中断する方がはるかに簡単です。
ICE endpoints make use of STUN Binding requests for gathering server-reflexive candidates from a STUN server. These requests are not authenticated in any way. As a consequence, there are numerous techniques an attacker can employ to provide the client with a false server-reflexive candidate:
ICEエンドポイントは、STUNサーバーからサーバー再帰候補を収集するためにSTUNバインディング要求を利用します。これらのリクエストはいかなる方法でも認証されません。その結果、攻撃者がクライアントに偽のサーバー再帰候補を提供するために使用できる手法は数多くあります。
o An attacker can compromise the DNS, causing DNS queries to return a rogue STUN server address. That server can provide the client with fake server-reflexive candidates. This attack is mitigated by DNS security, though DNSSEC is not required to address it.
o 攻撃者はDNSを危険にさらし、DNSクエリが不正なSTUNサーバーアドレスを返すようにする可能性があります。そのサーバーは、クライアントに偽のサーバー再帰候補を提供できます。この攻撃はDNSセキュリティによって軽減されますが、DNSSECはそれに対処する必要はありません。
o An attacker that can observe STUN messages (such as an attacker on a shared network segment, like Wi-Fi) can inject a fake response that is valid and will be accepted by the client.
o STUNメッセージを監視できる攻撃者（Wi-Fiなどの共有ネットワークセグメントの攻撃者など）は、有効であり、クライアントによって受け入れられる偽の応答を挿入できます。
o An attacker can compromise a STUN server and cause it to send responses with incorrect mapped addresses.
o 攻撃者はSTUNサーバーを危険にさらし、不正なマッピングアドレスで応答を送信させることができます。
A false mapped address learned by these attacks will be used as a server-reflexive candidate in the establishment of the ICE session. For this candidate to actually be used for data, the attacker also needs to attack the connectivity checks, and in particular, force a false valid on a false candidate. This attack is very hard to launch if the false address identifies a fourth party (neither the initiator, responder, nor attacker), since it requires attacking the checks generated by each ICE agent in the session and is prevented by SRTP if it identifies the attacker itself.
これらの攻撃によって学習された誤ってマッピングされたアドレスは、ICEセッションの確立におけるサーバー再帰候補として使用されます。この候補が実際にデータに使用されるためには、攻撃者は接続チェックも攻撃する必要があり、特に、偽の候補に対してfalseを有効にする必要があります。この攻撃は、セッションの各ICEエージェントによって生成されたチェックを攻撃する必要があり、攻撃者を識別した場合にSRTPによって阻止されるため、偽アドレスが第4者（開始者、応答者、攻撃者のいずれでもない）を識別する場合、起動するのは非常に困難です自体。
If the attacker elects not to attack the connectivity checks, the worst it can do is prevent the server-reflexive candidate from being used. However, if the peer agent has at least one candidate that is reachable by the agent under attack, the STUN connectivity checks themselves will provide a peer-reflexive candidate that can be used for the exchange of data. Peer-reflexive candidates are generally preferred over server-reflexive candidates. As such, an attack solely on the STUN address gathering will normally have no impact on a session at all.
攻撃者が接続チェックを攻撃しないことを選択した場合、サーバー再帰候補が使用されるのを防ぐことができます。ただし、攻撃を受けているエージェントが到達可能な候補がピアエージェントに少なくとも1つある場合は、STUN接続チェック自体が、データの交換に使用できるピア再帰候補を提供します。ピアリフレクティブな候補者は、一般的にサーバーリフレクティブな候補者よりも好まれます。そのため、STUNアドレス収集のみに対する攻撃は、通常、セッションにまったく影響を与えません。
An attacker might attempt to disrupt the gathering of relayed candidates, forcing the client to believe it has a false relayed candidate. Exchanges with the TURN server are authenticated using a long-term credential. Consequently, injection of fake responses or requests will not work. In addition, unlike Binding requests, Allocate requests are not susceptible to replay attacks with modified source IP addresses and ports, since the source IP address and port are not utilized to provide the client with its relayed candidate.
攻撃者は、中継された候補の収集を妨害しようとする可能性があり、クライアントに偽の中継された候補があると信じ込ませます。 TURNサーバーとの交換は、長期の資格情報を使用して認証されます。したがって、偽の応答または要求の挿入は機能しません。さらに、Bindingリクエストとは異なり、Allocateリクエストは、ソースIPアドレスとポートがクライアントに中継候補を提供するために利用されないため、変更されたソースIPアドレスとポートを使用したリプレイ攻撃の影響を受けません。
Even if an attacker has caused the client to believe in a false relayed candidate, the connectivity checks cause such a candidate to be used only if they succeed. Thus, an attacker needs to launch a false valid on a false candidate, per above, which is a very difficult attack to coordinate.
攻撃者がクライアントに偽の中継候補を信じ込ませたとしても、接続性チェックにより、その候補は成功した場合にのみ使用されます。したがって、攻撃者は上記のように、偽の候補に対して偽の有効を起動する必要があり、これは調整が非常に難しい攻撃です。
In addition to attacks where the attacker is a third party trying to insert fake candidate information or STUN messages, there are attacks possible with ICE when the attacker is an authenticated and valid participant in the ICE exchange.
攻撃者が偽の候補者情報またはSTUNメッセージを挿入しようとする第三者である攻撃に加えて、攻撃者が認証された有効なICE交換の参加者である場合、ICEで攻撃が可能です。
The STUN amplification attack is similar to a "voice hammer" attack, where the attacker causes other agents to direct voice packets to the attack target. However, instead of voice packets being directed to the target, STUN connectivity checks are directed to the target. The attacker sends a large number of candidates, say, 50. The responding agent receives the candidate information and starts its checks, which are directed at the target, and consequently, never generate a response. In the case of WebRTC, the user might not even be aware that this attack is ongoing, since it might be triggered in the background by malicious JavaScript code that the user has fetched. The answerer will start a new connectivity check every Ta ms (say, Ta=50ms). However, the retransmission timers are set to a large number due to the large number of candidates. As a consequence, packets will be sent at an interval of one every Ta milliseconds and then with increasing intervals after that. Thus, STUN will not send packets at a rate faster than data would be sent, and the STUN packets persist only briefly, until ICE fails for the session. Nonetheless, this is an amplification mechanism.
STUN増幅攻撃は、「ボイスハンマー」攻撃に似ています。攻撃者は、他のエージェントに音声パケットを攻撃対象に誘導させます。ただし、音声パケットがターゲットに送信される代わりに、STUN接続チェックがターゲットに送信されます。攻撃者は多数の候補、たとえば50を送信します。応答エージェントは候補情報を受信し、チェックを開始します。チェックはターゲットに向けられているため、決して応答を生成しません。 WebRTCの場合、ユーザーがフェッチした悪意のあるJavaScriptコードによってバックグラウンドでトリガーされる可能性があるため、ユーザーはこの攻撃が進行中であることにさえ気付かない可能性があります。回答者は、Ta msごとに新しい接続チェックを開始します（たとえば、Ta = 50ms）。ただし、候補の数が多いため、再送信タイマーが多く設定されます。その結果、パケットはTaミリ秒ごとに1つの間隔で送信され、その後、間隔が増加します。したがって、STUNはデータが送信されるよりも速い速度でパケットを送信しません。また、ICEがセッションで失敗するまで、STUNパケットは一時的にしか持続しません。それにもかかわらず、これは増幅メカニズムです。
It is impossible to eliminate the amplification, but the volume can be reduced through a variety of heuristics. ICE agents SHOULD limit the total number of connectivity checks they perform to 100. Additionally, agents MAY limit the number of candidates they will accept.
増幅を排除することは不可能ですが、音量はさまざまなヒューリスティックによって削減できます。 ICEエージェントは、実行する接続チェックの総数を100に制限する必要があります（SHOULD）。さらに、エージェントは、受け入れる候補の数を制限してもかまいません（MAY）。
Frequently, protocols that wish to avoid these kinds of attacks force the initiator to wait for a response prior to sending the next message. However, in the case of ICE, this is not possible. It is not possible to differentiate the following two cases:
多くの場合、これらの種類の攻撃を回避したいプロトコルは、次のメッセージを送信する前に、イニシエーターに応答を待機させます。ただし、ICEの場合、これは不可能です。次の2つのケースを区別することはできません。
o There was no response because the initiator is being used to launch a DoS attack against an unsuspecting target that will not respond.
o イニシエーターは、応答しない疑いのないターゲットに対してDoS攻撃を開始するために使用されているため、応答はありませんでした。
o There was no response because the IP address and port are not reachable by the initiator.
o イニシエーターがIPアドレスとポートに到達できないため、応答がありませんでした。
In the second case, another check will be sent at the next opportunity, while in the former case, no further checks will be sent.
2番目のケースでは、次の機会に別の小切手が送信されますが、前者のケースでは、それ以上の小切手は送信されません。
The original ICE specification registered four STUN attributes and one new STUN error response. The STUN attributes and error response are reproduced here. In addition, this specification registers a new ICE option.
元のICE仕様では、4つのSTUN属性と1つの新しいSTUNエラー応答が登録されていました。ここでは、STUN属性とエラー応答が再現されています。さらに、この仕様は新しいICEオプションを登録します。
IANA has registered four STUN attributes:
IANAは4つのSTUN属性を登録しています。
0x0024 PRIORITY 0x0025 USE-CANDIDATE 0x8029 ICE-CONTROLLED 0x802A ICE-CONTROLLING
0x0024 PRIORITY 0x0025 USE-CANDIDATE 0x8029 ICE-CONTROLLED 0x802A ICE-CONTROLLING
IANA has registered the following STUN error-response code:
IANAは、次のSTUNエラー応答コードを登録しました。
487 Role Conflict: The client asserted an ICE role (controlling or controlled) that is in conflict with the role of the server.
487ロールの競合：クライアントは、サーバーのロールと競合するICEロール（制御または制御）をアサートしました。
IANA has registered the following ICE option in the "ICE Options" subregistry of the "Interactive Connectivity Establishment (ICE)" registry, following the procedures defined in [RFC6336].
IANAは、[RFC6336]で定義されている手順に従って、「Interactive Connectivity Establishment（ICE）」レジストリの「ICE Options」サブレジストリに次のICEオプションを登録しました。
ICE Option name: ice2
ICEオプション名：ice2
Contact: Name: IESG Email: iesg@ietf.org
連絡先：名前：IESGメール：iesg@ietf.org
Change Controller: IESG
コントローラーの変更：IESG
Description: The ICE option indicates that the ICE agent using the ICE option is implemented according to RFC 8445.
説明：ICEオプションは、ICEオプションを使用するICEエージェントがRFC 8445に従って実装されていることを示します。
Reference: RFC 8445
リファレンス：RFC 8445
The purpose of this updated ICE specification is to:
この更新されたICE仕様の目的は次のとおりです。
o Clarify procedures in RFC 5245.
o RFC 5245の手順を明確にします。
o Make technical changes, due to discovered flaws in RFC 5245 and feedback from the community that has implemented and deployed ICE applications based on RFC 5245.
o RFC 5245の欠陥が発見され、RFC 5245に基づいてICEアプリケーションを実装および導入したコミュニティからのフィードバックにより、技術的な変更を行います。
o Make the procedures independent of the signaling protocol, by removing the SIP and SDP procedures. Procedures specific to a signaling protocol will be defined in separate usage documents. [ICE-SIP-SDP] defines ICE usage with SIP and SDP.
o SIPおよびSDP手順を削除して、手順をシグナリングプロトコルから独立させます。シグナリングプロトコルに固有の手順は、別の使用法ドキュメントで定義されます。 [ICE-SIP-SDP]は、SIPおよびSDPでのICEの使用を定義します。
The following technical changes have been done:
以下の技術変更が行われました。
o Aggressive nomination removed.
o 積極的な推薦が削除されました。
o The procedures for calculating candidate pair states and scheduling connectivity checks modified.
o 候補ペアの状態を計算し、接続性チェックをスケジュールする手順が変更されました。
o Procedures for calculation of Ta and RTO modified.
o TaおよびRTOの計算手順が変更されました。
o Active checklist and Frozen checklist definitions removed.
o アクティブなチェックリストと凍結されたチェックリストの定義が削除されました。
o 'ice2' ICE option added.
o 'ice2' ICEオプションが追加されました。
o IPv6 considerations modified.
o IPv6の考慮事項が変更されました。
o Usage with no-op for keepalives, and keepalives with non-ICE peers, removed.
o キープアライブのno-opの使用、およびICE以外のピアのキープアライブは削除されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//www.rfc-editor .org / info / rfc4941>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：// www.rfc-editor.org/info/rfc5389>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<https://www.rfc-editor.org/info/rfc5766>。
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, DOI 10.17487/RFC6336, July 2011, <https://www.rfc-editor.org/info/rfc6336>.
[RFC6336] Westerlund、M。、およびC. Perkins、「IANA Registry for Interactive Connectivity Establishment（ICE）Options」、RFC 6336、DOI 10.17487 / RFC6336、2011年7月、<https://www.rfc-editor.org/info / rfc6336>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<https://www.rfc-editor.org/info/rfc6724>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ICE-SIP-SDP] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", Work in Progress, draft-ietf-mmusic-ice-sip-sdp-21, June 2018.
[ICE-SIP-SDP] Petit-Huguenin、M.、Nandakumar、S。、およびA. Keranen、「インタラクティブ接続確立（ICE）のセッション記述プロトコル（SDP）オファー/アンサー手順」、進行中の作業、ドラフト- ietf-mmusic-ice-sip-sdp-21、2018年6月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<https://www.rfc-editor.org/info/rfc2475>。
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, DOI 10.17487/RFC3102, October 2001, <https://www.rfc-editor.org/info/rfc3102>.
[RFC3102] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm Specific IP：Framework」、RFC 3102、DOI 10.17487 / RFC3102、2001年10月、<https：//www.rfc -editor.org/info/rfc3102>。
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, DOI 10.17487/RFC3103, October 2001, <https://www.rfc-editor.org/info/rfc3103>.
[RFC3103] Borella、M.、Grabelsky、D.、Lo、J。、およびK.谷口、「Realm Specific IP：Protocol Specification」、RFC 3103、DOI 10.17487 / RFC3103、2001年10月、<https：// www。 rfc-editor.org/info/rfc3103>。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, DOI 10.17487/RFC3235, January 2002, <https://www.rfc-editor.org/info/rfc3235>.
[RFC3235] Senie、D。、「Network Address Translator（NAT）-Friendly Application Design Guidelines」、RFC 3235、DOI 10.17487 / RFC3235、2002年1月、<https://www.rfc-editor.org/info/rfc3235> 。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, <https://www.rfc-editor.org/info/rfc3303>.
[RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「ミドルボックス通信アーキテクチャおよびフレームワーク」、RFC 3303、DOI 10.17487 / RFC3303、2002年8月、<https： //www.rfc-editor.org/info/rfc3303>。
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <https://www.rfc-editor.org/info/rfc3424>.
[RFC3424]ダイグル、L。、エド。とIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）ACR考慮事項」、RFC 3424、DOI 10.17487 / RFC3424、2002年11月、<https://www.rfc-editor.org/info/rfc3424>。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, DOI 10.17487/RFC3489, March 2003, <https://www.rfc-editor.org/info/rfc3489>.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「STUN-Simple Data Traversal of User Datagram Protocol（UDP）Through Network Address Translators（NATs）」、RFC 3489、DOI 10.17487 / RFC3489、2003年3月、<https://www.rfc-editor.org/info/rfc3489>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-editor.org/info/rfc3605>.
[RFC3605] Huitema、C。、「Session Description Protocol（SDP）のReal Time Control Protocol（RTCP）属性」、RFC 3605、DOI 10.17487 / RFC3605、2003年10月、<https://www.rfc-editor.org/ info / rfc3605>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, <https://www.rfc-editor.org/info/rfc3725>.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、DOI 10.17487 / RFC3725、2004年4月、<https://www.rfc-editor.org/info/rfc3725>。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, DOI 10.17487/RFC3879, September 2004, <https://www.rfc-editor.org/info/rfc3879>.
[RFC3879] Huitema、C。およびB. Carpenter、「Deprecating Site Local Addresses」、RFC 3879、DOI 10.17487 / RFC3879、2004年9月、<https://www.rfc-editor.org/info/rfc3879>。
[RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, DOI 10.17487/RFC4038, March 2005, <https://www.rfc-editor.org/info/rfc4038>.
[RFC4038] Shin、MK。、Ed。、Hong、YG。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6移行のアプリケーションアスペクト」、RFC 4038、DOI 10.17487 / RFC4038、2005年3月、 <https://www.rfc-editor.org/info/rfc4038>。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, DOI 10.17487/RFC4091, June 2005, <https://www.rfc-editor.org/info/rfc4091>.
[RFC4091] Camarillo、G。およびJ. Rosenberg、「セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、DOI 10.17487 / RFC4091、2005年6月、<https：// www.rfc-editor.org/info/rfc4091>。
[RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, DOI 10.17487/RFC4092, June 2005, <https://www.rfc-editor.org/info/rfc4092>.
[RFC4092] Camarillo、G。およびJ. Rosenberg、「Session Initiation Protocol（SIP）におけるSession Description Protocol（SDP）代替ネットワークアドレスタイプ（ANAT）セマンティクスの使用」、RFC 4092、DOI 10.17487 / RFC4092、2005年6月、<https://www.rfc-editor.org/info/rfc4092>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。、およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<https://www.rfc-editor.org/info/rfc4103>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787> 。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<https：// www .rfc-editor.org / info / rfc5245>。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC5382] Guha、S。、編、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT動作要件」、BCP 142、RFC 5382、DOI 10.17487 / RFC5382、 2008年10月、<https://www.rfc-editor.org/info/rfc5382>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<https://www.rfc-editor.org/info / rfc5761>。
[RFC6080] Petrie, D. and S. Channabasappa, Ed., "A Framework for Session Initiation Protocol User Agent Profile Delivery", RFC 6080, DOI 10.17487/RFC6080, March 2011, <https://www.rfc-editor.org/info/rfc6080>.
[RFC6080] Petrie、D。およびS. Channabasappa、編、「フレームワークセッション開始プロトコルユーザーエージェントプロファイル配信」、RFC 6080、DOI 10.17487 / RFC6080、2011年3月、<https：//www.rfc-editor。 org / info / rfc6080>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P。、およびI. van Beijnum、「DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のためのDNS拡張機能」、RFC 6147、DOI 10.17487 / RFC6147、4月2011、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc- editor.org/info/rfc6298>。
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC6544] Rosenberg、J.、Kerenen、A.、Lowekamp、B。、およびA. Roach、「インタラクティブ接続確立（ICE）を使用したTCP候補」、RFC 6544、DOI 10.17487 / RFC6544、2012年3月、<https：/ /www.rfc-editor.org/info/rfc6544>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y。、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<https：//www.rfc- editor.org/info/rfc6928>。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050] Savolainen、T.、Korhonen、J。、およびD. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、DOI 10.17487 / RFC7050、2013年11月、<https：//www.rfc -editor.org/info/rfc7050>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F。、およびD. Thaler、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：//www.rfc- editor.org/info/rfc7721>。
[RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, "A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)", RFC 7825, DOI 10.17487/RFC7825, December 2016, <https://www.rfc-editor.org/info/rfc7825>.
[RFC7825] Goldberg、J.、Westerlund、M。、およびT. Zeng、「リアルタイムストリーミングプロトコル（RTSP）によって制御されるメディアのネットワークアドレス変換（NAT）トラバーサルメカニズム」、RFC 7825、DOI 10.17487 / RFC7825 、2016年12月、<https://www.rfc-editor.org/info/rfc7825>。
[RFC8421] Martinsen, P., Reddy, T., and P. Patil, "Interactive Connectivity Establishment (ICE) Multihomed and IPv4/IPv6 Dual-Stack Guidelines", RFC 8421, DOI 10.17487/RFC8421, July 2018, <https://www.rfc-editor.org/info/rfc8421>.
[RFC8421] Martinsen、P.、Reddy、T。、およびP. Patil、「Interactive Connectivity Establishment（ICE）Multihomed and IPv4 / IPv6 Dual-Stack Guidelines」、RFC 8421、DOI 10.17487 / RFC8421、2018年7月、<https： //www.rfc-editor.org/info/rfc8421>。
[WebRTC-IP-HANDLING] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", Work in Progress, draft-ietf-rtcweb-ip-handling-09, June 2018.
[WebRTC-IP-HANDLING] Uberti、J。およびG. Shieh、「WebRTC IPアドレスの処理要件」、作業中、draft-ietf-rtcweb-ip-handling-09、2018年6月。
ICE allows for two types of implementations. A full implementation supports the controlling and controlled roles in a session and can also perform address gathering. In contrast, a lite implementation is a minimalist implementation that does little but respond to STUN checks, and it only supports the controlled role in a session.
ICEでは、2種類の実装が可能です。完全な実装は、セッション内の制御および制御された役割をサポートし、アドレス収集も実行できます。対照的に、ライト実装は、STUNチェックにほとんど応答しない最小限の実装であり、セッションで制御された役割のみをサポートします。
Because ICE requires both endpoints to support it in order to bring benefits to either endpoint, incremental deployment of ICE in a network is more complicated. Many sessions involve an endpoint that is, by itself, not behind a NAT and not one that would worry about NAT traversal. A very common case is to have one endpoint that requires NAT traversal (such as a VoIP hard phone or soft phone) make a call to one of these devices. Even if the phone supports a full ICE implementation, ICE won't be used at all if the other device doesn't support it. The lite implementation allows for a low-cost entry point for these devices. Once they support the lite implementation, full implementations can connect to them and get the full benefits of ICE.
ICEでは、どちらかのエンドポイントにメリットをもたらすために、両方のエンドポイントでサポートする必要があるため、ネットワークへのICEの段階的な導入はより複雑になります。多くのセッションには、それ自体がNATの背後になく、NATトラバーサルを心配することのないエンドポイントが含まれます。非常に一般的なケースは、NATトラバーサルを必要とする1つのエンドポイント（VoIPハードフォンやソフトフォンなど）がこれらのデバイスの1つに電話をかけることです。電話機が完全なICE実装をサポートしていても、他のデバイスがそれをサポートしていない場合、ICEはまったく使用されません。 Liteの実装により、これらのデバイスの低コストのエントリポイントが可能になります。それらがliteの実装をサポートすると、完全な実装がそれらに接続し、ICEの完全な利点を得ることができます。
Consequently, a lite implementation is only appropriate for devices that will *always* be connected to the public Internet and have a public IP address at which it can receive packets from any correspondent. ICE will not function when a lite implementation is placed behind a NAT.
したがって、liteの実装は、「常に」パブリックインターネットに接続され、任意の通信相手からパケットを受信できるパブリックIPアドレスを持つデバイスにのみ適しています。ライトインプリメンテーションがNATの背後に配置されている場合、ICEは機能しません。
ICE allows a lite implementation to have a single IPv4 host candidate and several IPv6 addresses. In that case, candidate pairs are selected by the controlling agent using a static algorithm, such as the one in RFC 6724, which is recommended by this specification. However, static mechanisms for address selection are always prone to error, since they can never reflect the actual topology or provide actual guarantees on connectivity. They are always heuristics. Consequently, if an ICE agent is implementing ICE just to select between its IPv4 and IPv6 addresses, and none of its IP addresses are behind NAT, usage of full ICE is still RECOMMENDED in order to provide the most robust form of address selection possible.
ICEを使用すると、簡易実装で単一のIPv4ホスト候補と複数のIPv6アドレスを使用できます。その場合、候補のペアは、この仕様で推奨されているRFC 6724のアルゴリズムなどの静的アルゴリズムを使用して、制御エージェントによって選択されます。ただし、アドレス選択の静的メカニズムは、実際のトポロジを反映したり、接続の実際の保証を提供したりできないため、常にエラーが発生しやすくなります。それらは常にヒューリスティックです。その結果、ICEエージェントがIPv4アドレスとIPv6アドレスのどちらかを選択するためだけにICEを実装し、そのIPアドレスのいずれもNATの背後にない場合でも、可能な限り最も堅牢なアドレス選択の形式を提供するために、完全なICEの使用が推奨されます。
It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation. Even for devices that are always connected to the public Internet with just a single IPv4 address, a full implementation is preferable if achievable. Full implementations also obtain the security benefits of ICE unrelated to NAT traversal. Finally, it is often the case that a device that finds itself with a public address today will be placed in a network tomorrow where it will be behind a NAT. It is difficult to definitively know, over the lifetime of a device or product, if it will always be used on the public Internet. Full implementation provides assurance that communications will always work.
完全な実装への足がかりを提供するために、Lite実装がこの仕様に追加されたことに注意することが重要です。常に1つのIPv4アドレスだけでパブリックインターネットに接続されているデバイスでも、完全な実装が可能であれば望ましいです。完全な実装では、NATトラバーサルに関係のないICEのセキュリティ上の利点も得られます。最後に、今日パブリックアドレスを使用して自分自身を見つけたデバイスが、NATの背後にある明日のネットワークに配置されることがよくあります。デバイスまたは製品の存続期間にわたって、それが常に公衆インターネットで使用されるかどうかを明確に知ることは困難です。完全な実装により、通信が常に機能することが保証されます。
ICE contains a number of normative behaviors that may themselves be simple but derive from complicated or non-obvious thinking or use cases that merit further discussion. Since these design motivations are not necessary to understand for purposes of implementation, they are discussed here. This appendix is non-normative.
ICEには、それ自体は単純であるが、複雑な、または自明ではない思考や、さらなる議論に値する使用事例から派生する可能性のある規範的な行動がいくつか含まれています。これらの設計の動機は、実装のために理解する必要がないため、ここで説明します。この付録は非規範的です。
STUN transactions used to gather candidates and to verify connectivity are paced out at an approximate rate of one new transaction every Ta milliseconds. Each transaction, in turn, has a retransmission timer RTO that is a function of Ta as well. Why are these transactions paced, and why are these formulas used?
候補の収集と接続の検証に使用されるSTUNトランザクションは、Taミリ秒ごとに1つの新しいトランザクションのおおよその速度でペースが上がります。次に、各トランザクションには、Taの関数である再送信タイマーRTOがあります。なぜこれらのトランザクションはペース調整され、なぜこれらの式が使用されるのですか？
Sending of these STUN requests will often have the effect of creating bindings on NAT devices between the client and the STUN servers. Experience has shown that many NAT devices have upper limits on the rate at which they will create new bindings. Discussions in the IETF ICE WG during the work on this specification concluded that once every 5 ms is well supported. This is why Ta has a lower bound of 5 ms. Furthermore, transmission of these packets on the network makes use of bandwidth and needs to be rate limited by the ICE agent. Deployments based on earlier draft versions of [RFC5245] tended to overload rate-constrained access links and perform poorly overall, in addition to negatively impacting the network. As a consequence, the pacing ensures that the NAT device does not get overloaded and that traffic is kept at a reasonable rate.
これらのSTUN要求を送信すると、多くの場合、クライアントとSTUNサーバー間のNATデバイスにバインディングを作成する効果があります。多くのNATデバイスには、新しいバインディングを作成するレートに上限があることが経験上わかっています。この仕様に関する作業中のIETF ICE WGでの議論により、5 msに1回は十分にサポートされていると結論付けられました。これが、Taの下限が5 msである理由です。さらに、ネットワーク上でのこれらのパケットの送信は帯域幅を使用するため、ICEエージェントによってレート制限する必要があります。 [RFC5245]の以前のドラフトバージョンに基づく展開では、ネットワークに悪影響を与えるだけでなく、レート制限されたアクセスリンクに過負荷がかかり、全体的なパフォーマンスが低下する傾向がありました。その結果、ペーシングにより、NATデバイスが過負荷にならないようになり、トラフィックが妥当なレートで維持されます。
The definition of a "reasonable" rate is that STUN MUST NOT use more bandwidth than the RTP itself will use, once data starts flowing. The formula for Ta is designed so that, if a STUN packet were sent every Ta seconds, it would consume the same amount of bandwidth as RTP packets, summed across all data streams. Of course, STUN has retransmits, and the desire is to pace those as well. For this reason, RTO is set such that the first retransmit on the first transaction happens just as the first STUN request on the last transaction occurs. Pictorially:
「妥当な」レートの定義は、データが流れ始めると、STUNがRTP自体が使用するよりも多くの帯域幅を使用してはならないことです。 Taの式は、STUNパケットがTa秒ごとに送信された場合、RTPパケットと同じ量の帯域幅を消費し、すべてのデータストリームで合計されるように設計されています。もちろん、STUNには再送信があり、それらのペースも合わせたいと考えています。このため、RTOは、最後のトランザクションで最初のSTUN要求が発生したときと同じように、最初のトランザクションでの最初の再送信が発生するように設定されています。絵で：
First Packets Retransmits
最初のパケットの再送信
| |
| |
-------+------ -------+------
/ \ / \
/ \ / \
+--+ +--+ +--+ +--+ +--+ +--+
|A1| |B1| |C1| |A2| |B2| |C2|
+--+ +--+ +--+ +--+ +--+ +--+
---+-------+-------+-------+-------+-------+------------ Time
0 Ta 2Ta 3Ta 4Ta 5Ta
In this picture, there are three transactions that will be sent (for example, in the case of candidate gathering, there are three host candidate/STUN server pairs). These are transactions A, B, and C. The retransmit timer is set so that the first retransmission on the first transaction (packet A2) is sent at time 3Ta.
この図では、3つのトランザクションが送信されます（たとえば、候補の収集の場合、3つのホスト候補/ STUNサーバーのペアがあります）。これらはトランザクションA、B、およびCです。再送信タイマーは、最初のトランザクション（パケットA2）の最初の再送信が時刻3Taに送信されるように設定されています。
Subsequent retransmits after the first will occur even less frequently than Ta milliseconds apart, since STUN uses an exponential backoff on its retransmissions.
STUNは再送信に指数バックオフを使用するため、最初の送信以降の再送信は、Taミリ秒間隔よりも頻繁に発生しません。
This mechanism of a global minimum pacing interval of 5 ms is not generally applicable to transport protocols, but it is applicable to ICE based on the following reasoning.
グローバルな最小ペーシング間隔である5ミリ秒のこのメカニズムは、一般にトランスポートプロトコルには適用できませんが、以下の理由に基づいてICEに適用できます。
o Start with the following rules that would be generally applicable to transport protocols:
o トランスポートプロトコルに一般的に適用される次のルールから始めます。
1. Let MaxBytes be the maximum number of bytes allowed to be outstanding in the network at startup, which SHOULD be 14600, as defined in Section 2 of [RFC6928].
1. [RFC6928]のセクション2で定義されているように、MaxBytesを起動時にネットワークで未処理のままにできる最大バイト数とします。これは14600にする必要があります（SHOULD）。
2. Let HTO be the transaction timeout, which SHOULD be 2*RTT if RTT is known or 500 ms otherwise. This is based on the RTO for STUN messages from [RFC5389] and the TCP initial RTO, which is 1 sec in [RFC6298].
2. HTOをトランザクションタイムアウトとし、RTTが既知の場合は2 * RTT、それ以外の場合は500ミリ秒にする必要があります。これは、[RFC5389]からのSTUNメッセージのRTOと、[RFC6298]では1秒であるTCP初期RTOに基づいています。
3. Let MinPacing be the minimum pacing interval between transactions, which is 5 ms (see above).
3. MinPacingをトランザクション間の最小ペーシング間隔である5ミリ秒にします（上記を参照）。
o Observe that agents typically do not know the RTT for ICE transactions (connectivity checks in particular), meaning that HTO will almost always be 500 ms.
o エージェントは通常、ICEトランザクションのRTT（特に接続性チェック）を知らないことに注意してください。これは、HTOがほとんど常に500ミリ秒であることを意味します。
o Observe that a MinPacing of 5 ms and HTO of 500 ms gives at most 100 packets/HTO, which for a typical ICE check of less than 120 bytes means a maximum of 12000 outstanding bytes in the network, which is less than the maximum expressed by rule 1.
o MinPacingが5ミリ秒、HTOが500ミリ秒の場合、最大100パケット/ HTOが得られます。これは、一般的なICEチェックで120バイト未満の場合、ネットワークで最大12000未解決のバイトを意味します。これは、ルール1。
o Thus, for ICE, the rule set reduces to just the MinPacing rule, which is equivalent to having a global Ta value.
o したがって、ICEの場合、ルールセットはMinPacingルールのみに削減されます。これは、グローバルTa値を持つことに相当します。
Section 5.1.3 talks about eliminating candidates that have the same transport address and base. However, candidates with the same transport addresses but different bases are not redundant. When can an ICE agent have two candidates that have the same IP address and port but different bases? Consider the topology of Figure 11:
セクション5.1.3は、同じトランスポートアドレスとベースを持つ候補の排除について説明しています。ただし、トランスポートアドレスが同じでベースが異なる候補は冗長ではありません。 ICEエージェントには、IPアドレスとポートが同じでベースが異なる2つの候補が存在する場合がありますか？図11のトポロジーを考えます。
+----------+
| STUN Srvr|
+----------+
|
|
-----
// \\
| |
| B:net10 |
| |
\\ //
-----
|
|
+----------+
| NAT |
+----------+
|
|
-----
// \\
| A |
|192.168/16 |
| |
\\ //
-----
|
|
|192.168.1.100 -----
+----------+ // \\ +----------+
| | | | | |
| Initiator|---------| C:net10 |-----------| Responder|
| |10.0.1.100| | 10.0.1.101 | |
+----------+ \\ // +----------+
-----
Figure 11: Identical Candidates with Different Bases
図11：異なるベースを持つ同一の候補
In this case, the initiating agent is multihomed. It has one IP address, 10.0.1.100, on network C, which is a net 10 private network. The responding agent is on this same network. The initiating agent is also connected to network A, which is 192.168/16, and has an IP address of 192.168.1.100. There is a NAT on this network, natting into network B, which is another net 10 private network, but it is not connected to network C. There is a STUN server on network B.
この場合、開始エージェントはマルチホームです。ネットワークCには1つのIPアドレス10.0.1.100があり、これはnet 10プライベートネットワークです。応答エージェントはこの同じネットワーク上にあります。開始エージェントは192.168 / 16であり、192.168.1.100のIPアドレスを持つネットワークAにも接続されています。このネットワークにはNATがあり、別のnet 10プライベートネットワークであるネットワークBに接続していますが、ネットワークCには接続されていません。ネットワークBにはSTUNサーバーがあります。
The initiating agent obtains a host candidate on its IP address on network C (10.0.1.100:2498) and a host candidate on its IP address on network A (192.168.1.100:3344). It performs a STUN query to its configured STUN server from 192.168.1.100:3344. This query passes through the NAT, which happens to assign the binding 10.0.1.100:2498. The STUN server reflects this in the STUN Binding response. Now, the initiating agent has obtained a server-reflexive candidate with a transport address that is identical to a host candidate (10.0.1.100:2498). However, the server-reflexive candidate has a base of 192.168.1.100:3344, and the host candidate has a base of 10.0.1.100:2498.
開始エージェントは、ネットワークCのIPアドレス（10.0.1.100:2498）のホスト候補とネットワークAのIPアドレス（192.168.1.100:3344）のホスト候補を取得します。 192.168.1.100:3344から構成済みのSTUNサーバーにSTUNクエリを実行します。このクエリはNATを通過します。NATはたまたまバインディング10.0.1.100:2498を割り当てます。 STUNサーバーは、これをSTUNバインディング応答に反映します。これで、開始エージェントは、ホスト候補と同じトランスポートアドレス（10.0.1.100:2498）を持つサーバー再帰候補を取得しました。ただし、サーバー再帰候補のベースは192.168.1.100:3344で、ホスト候補のベースは10.0.1.100:2498です。
The candidate attribute contains two values that are not used at all by ICE itself -- related address and related port. Why are they present?
候補属性には、ICE自体ではまったく使用されない2つの値（関連アドレスと関連ポート）が含まれています。なぜ彼らはいるのですか？
There are two motivations for its inclusion. The first is diagnostic. It is very useful to know the relationship between the different types of candidates. By including it, an ICE agent can know which relayed candidate is associated with which reflexive candidate, which in turn is associated with a specific host candidate. When checks for one candidate succeed but not for others, this provides useful diagnostics on what is going on in the network.
これを含める動機は2つあります。 1つは診断です。さまざまなタイプの候補者間の関係を知ることは非常に役立ちます。これを含めることにより、ICEエージェントは、中継された候補がどの再帰候補に関連付けられているか、次に、特定のホスト候補に関連付けられているかを知ることができます。 1つの候補のチェックは成功し、他の候補のチェックは成功しない場合、これはネットワークで何が起こっているかについての有用な診断を提供します。
The second reason has to do with off-path Quality-of-Service (QoS) mechanisms. When ICE is used in environments such as PacketCable 2.0, proxies will, in addition to performing normal SIP operations, inspect the SDP in SIP messages and extract the IP address and port for data traffic. They can then interact, through policy servers, with access routers in the network, to establish guaranteed QoS for the data flows. This QoS is provided by classifying the RTP traffic based on 5-tuple and then providing it a guaranteed rate, or marking its DSCP appropriately. When a residential NAT is present, and a relayed candidate gets selected for data, this relayed candidate will be a transport address on an actual TURN server. That address says nothing about the actual transport address in the access router that would be used to classify packets for QoS treatment. Rather, the server-reflexive candidate towards the TURN server is needed. By carrying the translation in the SDP, the proxy can use that transport address to request QoS from the access router.
2番目の理由は、パス外のサービス品質（QoS）メカニズムに関係しています。 ICEがPacketCable 2.0などの環境で使用される場合、プロキシは通常のSIP操作の実行に加えて、SIPメッセージのSDPを検査し、データトラフィックのIPアドレスとポートを抽出します。次に、ポリシーサーバーを介してネットワーク内のアクセスルーターと対話し、データフローの保証されたQoSを確立できます。このQoSは、RTPトラフィックを5タプルに基づいて分類し、保証レートを提供するか、DSCPを適切にマーキングすることで提供されます。レジデンシャルNATが存在し、中継候補がデータ用に選択された場合、この中継候補は実際のTURNサーバーのトランスポートアドレスになります。そのアドレスは、QoS処理のためにパケットを分類するために使用されるアクセスルータの実際のトランスポートアドレスについては何も述べていません。むしろ、TURNサーバーに対するサーバー再帰候補が必要です。 SDPで変換を行うことにより、プロキシはそのトランスポートアドレスを使用して、アクセスルータにQoSを要求できます。
ICE requires the usage of message integrity with STUN using its short-term credential functionality. The actual short-term credential is formed by exchanging username fragments in the candidate exchange. The need for this mechanism goes beyond just security; it is actually required for correct operation of ICE in the first place.
ICEでは、短期的な資格情報機能を使用して、STUNでメッセージの整合性を使用する必要があります。実際の短期信任状は、候補交換でユーザー名フラグメントを交換することによって形成されます。このメカニズムの必要性は、セキュリティだけではありません。そもそも、ICEを正しく動作させるために必要です。
Consider ICE agents L, R, and Z. L and R are within private enterprise 1, which is using 10.0.0.0/8. Z is within private enterprise 2, which is also using 10.0.0.0/8. As it turns out, R and Z both have IP address 10.0.1.1. L sends candidates to Z. Z responds to L with its host candidates. In this case, those candidates are 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a session at that same time and is also using 10.0.1.1:8866 and 10.0.1.1:8877 as host candidates. This means that R is prepared to accept STUN messages on those ports, just as Z is. L will send a STUN request to 10.0.1.1:8866 and another to 10.0.1.1:8877. However, these do not go to Z as expected. Instead, they go to R! If R just replied to them, L would believe it has connectivity to Z, when in fact it has connectivity to a completely different user, R. To fix this, STUN short-term credential mechanisms are used. The username fragments are sufficiently random; thus it is highly unlikely that R would be using the same values as Z. Consequently, R would reject the STUN request since the credentials were invalid. In essence, the STUN username fragments provide a form of transient host identifiers, bound to a particular session established as part of the candidate exchange.
ICEエージェントL、R、およびZを検討してください。LおよびRは、10.0.0.0 / 8を使用しているプライベートエンタープライズ1内にあります。 Zはプライベートエンタープライズ2内にあり、これも10.0.0.0/8を使用しています。結局のところ、RとZはどちらもIPアドレス10.0.1.1を持っています。 Lは候補をZに送信します。ZはLにホスト候補で応答します。この場合、これらの候補は10.0.1.1:8866および10.0.1.1:8877です。結局のところ、Rは同時にセッションに参加しており、ホスト候補として10.0.1.1:8866と10.0.1.1:8877も使用しています。これは、Zと同様に、RがこれらのポートでSTUNメッセージを受け入れる準備ができていることを意味します。 LはSTUN要求を10.0.1.1:8866に送信し、別の要求を10.0.1.1:8877に送信します。ただし、これらは期待どおりにZに行きません。代わりに、彼らはRに行きます！ Rが単にRに応答した場合、LはZに接続していると信じますが、実際には完全に異なるユーザーRに接続しています。これを修正するために、STUN短期資格メカニズムが使用されます。ユーザー名の断片は十分にランダムです。したがって、RがZと同じ値を使用することはほとんどありません。その結果、資格情報が無効であるため、RはSTUN要求を拒否します。本質的に、STUNユーザー名フラグメントは、一時的なホスト識別子の形式を提供し、候補交換の一部として確立された特定のセッションにバインドされます。
An unfortunate consequence of the non-uniqueness of IP addresses is that, in the above example, R might not even be an ICE agent. It could be any host, and the port to which the STUN packet is directed could be any ephemeral port on that host. If there is an application listening on this socket for packets, and it is not prepared to handle malformed packets for whatever protocol is in use, the operation of that application could be affected. Fortunately, since the ports exchanged are ephemeral and usually drawn from the dynamic or registered range, the odds are good that the port is not used to run a server on host R, but rather is the agent side of some protocol. This decreases the probability of hitting an allocated port, due to the transient nature of port usage in this range. However, the possibility of a problem does exist, and network deployers need to be prepared for it. Note that this is not a problem specific to ICE; stray packets can arrive at a port at any time for any type of protocol, especially ones on the public Internet. As such, this requirement is just restating a general design guideline for Internet applications -- be prepared for unknown packets on any port.
IPアドレスが一意でないことの不幸な結果は、上記の例では、RがICEエージェントでさえない可能性があることです。これは任意のホストである可能性があり、STUNパケットが向けられるポートはそのホスト上の任意の一時ポートである可能性があります。このソケットでパケットをリッスンするアプリケーションがあり、どのプロトコルが使用されていても、不正な形式のパケットを処理する準備ができていない場合、そのアプリケーションの動作が影響を受ける可能性があります。幸いにも、交換されるポートは一時的なものであり、通常は動的範囲または登録範囲から引き出されるため、ポートがホストRでサーバーを実行するために使用されるのではなく、一部のプロトコルのエージェント側である可能性が高くなります。これにより、この範囲でのポート使用の一時的な性質により、割り当てられたポートにヒットする可能性が減少します。ただし、問題が発生する可能性があり、Network Deployerが問題に備える必要があります。これはICE固有の問題ではないことに注意してください。浮遊パケットは、あらゆるタイプのプロトコル、特にパブリックインターネット上のプロトコルについて、いつでもポートに到着する可能性があります。そのため、この要件は、インターネットアプリケーションの一般的な設計ガイドラインを言い換えたものであり、どのポートでも不明なパケットに備えておく必要があります。
The priority for a candidate pair has an odd form. It is:
候補ペアの優先度は奇妙な形をしています。それは：
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Why is this? When the candidate pairs are sorted based on this value, the resulting sorting has the MAX/MIN property. This means that the pairs are first sorted based on decreasing value of the minimum of the two priorities. For pairs that have the same value of the minimum priority, the maximum priority is used to sort amongst them. If the max and the min priorities are the same, the controlling agent's priority is used as the tiebreaker in the last part of the expression. The factor of 2*32 is used since the priority of a single candidate is always less than 2*32, resulting in the pair priority being a "concatenation" of the two component priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, for a particular ICE agent, a lower-priority candidate is never used until all higher-priority candidates have been tried.
どうしてこれなの？候補ペアがこの値に基づいてソートされると、結果のソートにはMAX / MINプロパティがあります。これは、ペアが最初に2つの優先順位の最小値の減少値に基づいてソートされることを意味します。最小優先度の値が同じであるペアの場合、最大優先度を使用してペアが並べ替えられます。最大優先度と最小優先度が同じ場合は、制御エージェントの優先度が式の最後の部分でタイブレーカーとして使用されます。 1つの候補の優先順位は常に2 * 32未満であるため、2 * 32の係数が使用されます。その結果、ペアの優先順位は2つのコンポーネントの優先順位の「連結」になります。これにより、MAX / MINソートが作成されます。 MAX / MINは、特定のICEエージェントに対して、優先度の高い候補がすべて試行されるまで、優先度の低い候補が使用されないようにします。
Once data begins flowing on a candidate pair, it is still necessary to keep the bindings alive at intermediate NATs for the duration of the session. Normally, the data stream packets themselves (e.g., RTP) meet this objective. However, several cases merit further discussion. Firstly, in some RTP usages, such as SIP, the data streams can be "put on hold". This is accomplished by using the SDP "sendonly" or "inactive" attributes, as defined in RFC 3264 [RFC3264]. RFC 3264 directs implementations to cease transmission of data in these cases. However, doing so may cause NAT bindings to time out, and data won't be able to come off hold.
候補ペアでデータが流れ始めると、セッションの期間中、バインディングを中間NATで存続させる必要があります。通常、データストリームパケット自体（RTPなど）はこの目的を満たします。ただし、いくつかのケースはさらに議論する価値があります。まず、SIPなどの一部のRTPの使用法では、データストリームを「保留」にすることができます。これは、RFC 3264 [RFC3264]で定義されているように、SDPの「送信専用」または「非アクティブ」属性を使用して実現されます。 RFC 3264は、これらの場合にデータの送信を中止するように実装に指示します。ただし、これを行うと、NATバインディングがタイムアウトし、データを保持できなくなります。
Secondly, some RTP payload formats, such as the payload format for text conversation [RFC4103], may send packets so infrequently that the interval exceeds the NAT binding timeouts.
次に、テキストカンバセーションのペイロード形式[RFC4103]などの一部のRTPペイロード形式は、パケットの送信頻度が非常に低いため、間隔がNATバインディングタイムアウトを超えることがあります。
Thirdly, if silence suppression is in use, long periods of silence may cause data transmission to cease sufficiently long for NAT bindings to time out.
第3に、無音圧縮が使用されている場合、無音状態が長時間続くと、NATバインディングがタイムアウトするまでデータ転送が十分長く停止する可能性があります。
For these reasons, the data packets themselves cannot be relied upon. ICE defines a simple periodic keepalive utilizing STUN Binding Indications. This makes its bandwidth requirements highly predictable and thus amenable to QoS reservations.
これらの理由により、データパケット自体は信頼できません。 ICEは、STUNバインディング表示を利用した単純な定期的なキープアライブを定義します。これにより、帯域幅の要件が非常に予測可能になり、QoS予約が可能になります。
Section 5.1.2 describes procedures for computing the priority of a candidate based on its type and local preferences. That section requires that the type preference for peer-reflexive candidates always be higher than server reflexive. Why is that? The reason has to do with the security considerations in Section 19. It is much easier for an attacker to cause an ICE agent to use a false server-reflexive candidate rather than a false peer-reflexive candidate. Consequently, attacks against address gathering with Binding requests are thwarted by ICE by preferring the peer-reflexive candidates.
セクション5.1.2では、候補者のタイプと地域の好みに基づいて候補者の優先順位を計算する手順について説明します。そのセクションでは、ピア・リフレクティブ候補のタイプ設定が常にサーバー・リフレクティブよりも高い必要があります。何故ですか？その理由は、セクション19のセキュリティに関する考慮事項に関係しています。攻撃者がICEエージェントに、偽のピア再帰候補よりも偽のサーバー再帰候補を使用させるほうがはるかに簡単です。その結果、Binding要求によるアドレス収集に対する攻撃は、ピア再帰候補を優先することにより、ICEによって阻止されます。
Data keepalives are described in Section 11. These keepalives make use of STUN when both endpoints are ICE capable. However, rather than using a Binding request transaction (which generates a response), the keepalives use an Indication. Why is that?
データキープアライブについては、セクション11で説明します。これらのキープアライブは、両方のエンドポイントがICE対応の場合にSTUNを利用します。ただし、キープアライブは、Binding要求トランザクション（応答を生成する）を使用するのではなく、Indicationを使用します。何故ですか？
The primary reason has to do with network QoS mechanisms. Once data begins flowing, network elements will assume that the data stream has a fairly regular structure, making use of periodic packets at fixed intervals, with the possibility of jitter. If an ICE agent is sending data packets, and then receives a Binding request, it would need to generate a response packet along with its data packets. This will increase the actual bandwidth requirements for the 5-tuple carrying the data packets and introduce jitter in the delivery of those packets. Analysis has shown that this is a concern in certain Layer 2 access networks that use fairly tight packet schedulers for data.
主な理由は、ネットワークQoSメカニズムに関係しています。データが流れ始めると、ネットワークエレメントは、データストリームがかなり規則的な構造であり、ジッターの可能性がある一定の間隔で定期的なパケットを使用すると想定します。 ICEエージェントがデータパケットを送信していて、Bindingリクエストを受信した場合は、そのデータパケットとともに応答パケットを生成する必要があります。これにより、データパケットを伝送する5タプルの実際の帯域幅要件が増加し、これらのパケットの配信にジッタが発生します。分析によると、これはデータにかなりタイトなパケットスケジューラを使用する特定のレイヤ2アクセスネットワークでの問題です。
Additionally, using a Binding Indication allows integrity to be disabled, which may result in better performance. This is useful for large-scale endpoints, such as Public Switched Telephone Network (PSTN) gateways and Session Border Controllers (SBCs).
さらに、バインディング表示を使用すると、整合性を無効にできるため、パフォーマンスが向上する場合があります。これは、公衆交換電話網（PSTN）ゲートウェイやセッションボーダーコントローラー（SBC）などの大規模なエンドポイントで役立ちます。
One criterion for selecting type and local preference values is the use of a data intermediary, such as a TURN server, a tunnel service such as a VPN server, or NAT. With a data intermediary, if data is sent to that candidate, it will first transit the data intermediary before being received. One type of candidate that involves a data intermediary is the relayed candidate. Another type is the host candidate, which is obtained from a VPN interface. When data is transited through a data intermediary, it can have a positive or negative effect on the latency between transmission and reception. It may or may not increase the packet losses, because of the additional router hops that may be taken. It may increase the cost of providing service, since data will be routed in and right back out of a data intermediary run by a provider. If these concerns are important, the type preference for relayed candidates needs to be carefully chosen.
タイプとローカルプリファレンス値を選択するための1つの基準は、TURNサーバーなどのデータ中間体、VPNサーバーなどのトンネルサービス、またはNATの使用です。データ仲介者の場合、その候補者にデータが送信されると、最初にデータ仲介者を経由してから受信されます。データの仲介を伴う候補の1つは、中継される候補です。別のタイプは、VPNインターフェースから取得されるホスト候補です。データがデータの中間を通過するとき、送信と受信の間の待ち時間にプラスまたはマイナスの影響を与える可能性があります。ルーターホップが追加される可能性があるため、パケット損失が増加する場合と増加しない場合があります。データはプロバイダーによって実行されるデータ中間サーバーにルーティングされ、データアウトバックされるため、サービスを提供するコストが増加する可能性があります。これらの懸念が重要な場合は、中継される候補者のタイプ設定を慎重に選択する必要があります。
Another criterion for selecting preferences is the IP address family. ICE works with both IPv4 and IPv6. It provides a transition mechanism that allows dual-stack hosts to prefer connectivity over IPv6 but to fall back to IPv4 in case the v6 networks are disconnected. Implementation SHOULD follow the guidelines from [RFC8421] to avoid excessive delays in the connectivity-check phase if broken paths exist.
プリファレンスを選択するためのもう1つの基準は、IPアドレスファミリです。 ICEはIPv4とIPv6の両方で動作します。これは、デュアルスタックホストがIPv6よりも接続を優先できるようにするが、v6ネットワークが切断された場合にIPv4にフォールバックできる移行メカニズムを提供します。実装は、[RFC8421]のガイドラインに従い、壊れたパスが存在する場合の接続性チェックフェーズでの過度の遅延を回避する必要があります。
Another criterion for selecting preferences is topological awareness. This is beneficial for candidates that make use of intermediaries. In those cases, if an ICE agent has preconfigured or dynamically discovered knowledge of the topological proximity of the intermediaries to itself, it can use that to assign higher local preferences to candidates obtained from closer intermediaries.
好みを選択するためのもう1つの基準は、トポロジー意識です。これは、仲介者を利用する候補者にとって有益です。これらの場合、ICEエージェントが仲介者のトポロジー自体への事前設定された知識または動的に発見した知識を持っている場合、それを使用して、より近い仲介者から取得した候補に高いローカル優先度を割り当てることができます。
Another criterion for selecting preferences might be security or privacy. If a user is a telecommuter, and therefore connected to a corporate network and a local home network, the user may prefer their voice traffic to be routed over the VPN or similar tunnel in order to keep it on the corporate network when communicating within the enterprise but may use the local network when communicating with users outside of the enterprise. In such a case, a VPN address would have a higher local preference than any other address.
設定を選択するためのもう1つの基準は、セキュリティまたはプライバシーです。ユーザーが在宅勤務者であり、企業ネットワークとローカルホームネットワークに接続している場合、ユーザーは、企業内で通信するときに音声トラフィックをVPNまたは同様のトンネル経由でルーティングして、企業ネットワーク上に維持することを好む場合があります。ただし、企業外のユーザーと通信するときにローカルネットワークを使用する場合があります。このような場合、VPNアドレスは、他のどのアドレスよりもローカル優先度が高くなります。
The tables below show, for IPv4 and IPv6, the bandwidth required for performing connectivity checks, using different Ta values (given in ms) and different ufrag sizes (given in bytes).
次の表は、IPv4およびIPv6の場合、さまざまなTa値（ms単位）と異なるufragサイズ（バイト単位）を使用して、接続チェックを実行するために必要な帯域幅を示しています。
The results were provided by Jusin Uberti (Google) on 11 April 2016.
結果は2016年4月11日にJusin Uberti（Google）によって提供されました。
IP version: IPv4
Packet len (bytes): 108 + ufrag
|
ms | 4 8 12 16
-----|------------------------
500 | 1.86k 1.98k 2.11k 2.24k
200 | 4.64k 4.96k 5.28k 5.6k
100 | 9.28k 9.92k 10.6k 11.2k
50 | 18.6k 19.8k 21.1k 22.4k
20 | 46.4k 49.6k 52.8k 56.0k
10 | 92.8k 99.2k 105k 112k
5 | 185k 198k 211k 224k
2 | 464k 496k 528k 560k
1 | 928k 992k 1.06M 1.12M
IP version: IPv6
Packet len (bytes): 128 + ufrag
|
ms | 4 8 12 16
-----|------------------------
500 | 2.18k 2.3k 2.43k 2.56k
200 | 5.44k 5.76k 6.08k 6.4k
100 | 10.9k 11.5k 12.2k 12.8k
50 | 21.8k 23.0k 24.3k 25.6k
20 | 54.4k 57.6k 60.8k 64.0k
10 | 108k 115k 121k 128k
5 | 217k 230k 243k 256k
2 | 544k 576k 608k 640k
1 | 1.09M 1.15M 1.22M 1.28M
Figure 12: Connectivity-Check Bandwidth
図12：接続性チェック帯域幅
Acknowledgements
謝辞
Most of the text in this document comes from the original ICE specification, RFC 5245. The authors would like to thank everyone who has contributed to that document. For additional contributions to this revision of the specification, we would like to thank Emil Ivov, Paul Kyzivat, Pal-Erik Martinsen, Simon Perrault, Eric Rescorla, Thomas Stach, Peter Thatcher, Martin Thomson, Justin Uberti, Suhas Nandakumar, Taylor Brandstetter, Peter Saint-Andre, Harald Alvestrand, and Roman Shpount. Ben Campbell did the AD review. Stephen Farrell did the sec-dir review. Stewart Bryant did the gen-art review. Qin We did the ops-dir review. Magnus Westerlund did the tsv-art review.
このドキュメントのテキストの大部分は、元のICE仕様であるRFC 5245に基づいています。作成者は、そのドキュメントに貢献してくれたすべての人に感謝します。この仕様の改訂に対する追加の貢献について、Emil Ivov、Paul Kyzivat、Pal-Erik Martinsen、Simon Perrault、Eric Rescorla、Thomas Stach、Peter Thatcher、Martin Thomson、Justin Uberti、Suhas Nandakumar、Taylor Brandstetter、 Peter Saint-Andre、Harald Alvestrand、Roman Shpount。ベンキャンベルがADのレビューを行いました。 Stephen Farrellがsec-dirのレビューを行いました。スチュワート・ブライアントは、gen-artレビューを行いました。 Qin ops-dirのレビューを行いました。 Magnus Westerlundがtsv-artレビューを行いました。
Authors' Addresses
著者のアドレス
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
あり けらねん えりｃっそん ひｒさぁんちえ １１ ０２４２０ じょｒゔぁｓ ふぃんぁんｄ
Email: ari.keranen@ericsson.com
Christer Holmberg Ericsson Hirsalantie 11 02420 Jorvas Finland
Christer Holmberg Ericsson Hirsalantie 11 02420 Jorvasフィンランド
Email: christer.holmberg@ericsson.com
Jonathan Rosenberg jdrosen.net Monmouth, NJ United States of America
ジョナサン・ローゼンバーグjdrosen.netモンマス、ニュージャージー州アメリカ合衆国
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net