[要約] RFC 5245は、Offer/AnswerプロトコルのためのNATトラバーサルのためのICEプロトコルについての要約です。このRFCの目的は、ネットワークアドレストランスレータ（NAT）を介した通信の問題を解決するための手法を提供することです。
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5245 jdrosen.net
Obsoletes: 4091, 4092 April 2010
Category: Standards Track
ISSN: 2070-1721
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
インタラクティブな接続性確立（ICE）：ネットワークアドレス翻訳者（NAT）のプロトコルオファー/回答プロトコルのトラバーサル
Abstract
概要
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. 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). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP).
このドキュメントでは、オファー/回答モデルで確立されたUDPベースのマルチメディアセッションのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコルについて説明します。このプロトコルは、インタラクティブ接続確立（ICE）と呼ばれます。ICEは、NAT（STUN）プロトコルのセッショントラバーサルユーティリティとその拡張、リレーNAT（ターン）を使用したトラバーサルを使用します。ICEは、セッション開始プロトコル（SIP）など、オファー/回答モデルを使用して、任意のプロトコルで使用できます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5245.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5245で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.eで説明されている法的規定のセクション4.eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 12
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 14
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 16
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19
4.1. Full Implementation Requirements . . . . . . . . . . . . 19
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20
4.1.1.3. Computing Foundations . . . . . . . . . . . . . . 22
4.1.1.4. Keeping Candidates Alive . . . . . . . . . . . . 22
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23
4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23
4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 25
4.1.4. Choosing Default Candidates . . . . . . . . . . . . . 25
4.2. Lite Implementation Requirements . . . . . . . . . . . . 25
4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 26
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 29
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 30
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30
5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 31
5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 31
5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 31
5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 31
5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 34
5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 34
5.7.4. Computing States . . . . . . . . . . . . . . . . . . 34
5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 37
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 39
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 39
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 39
6.3. Forming the Check List . . . . . . . . . . . . . . . . . 40
6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 40
7. Performing Connectivity Checks . . . . . . . . . . . . . . . 40
7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 40
7.1.1. Creating Permissions for Relayed Candidates . . . . . 40
7.1.2. Sending the Request . . . . . . . . . . . . . . . . . 40
7.1.2.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 41
7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 41
7.1.2.3. Forming Credentials . . . . . . . . . . . . . . . 41
7.1.2.4. DiffServ Treatment . . . . . . . . . . . . . . . 42
7.1.3. Processing the Response . . . . . . . . . . . . . . . 42
7.1.3.1. Failure Cases . . . . . . . . . . . . . . . . . . 42
7.1.3.2. Success Cases . . . . . . . . . . . . . . . . . . 43
7.1.3.2.1. Discovering Peer Reflexive Candidates . . . . 43
7.1.3.2.2. Constructing a Valid Pair . . . . . . . . . . 44
7.1.3.2.3. Updating Pair States . . . . . . . . . . . . 45
7.1.3.2.4. Updating the Nominated Flag . . . . . . . . . 46
7.1.3.3. Check List and Timer State Updates . . . . . . . 46
7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 46
7.2.1. Additional Procedures for Full Implementations . . . 47
7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 47
7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 48
7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 49
7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 49
7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 50
7.2.2. Additional Procedures for Lite Implementations . . . 51
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 51
8.1. Procedures for Full Implementations . . . . . . . . . . . 51
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 51
8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 52
8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 52
8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 53
8.2. Procedures for Lite Implementations . . . . . . . . . . . 54
8.2.1. Peer Is Full . . . . . . . . . . . . . . . . . . . . 54
8.2.2. Peer Is Lite . . . . . . . . . . . . . . . . . . . . 55
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 56
8.3.1. Full Implementation Procedures . . . . . . . . . . . 56
8.3.2. Lite Implementation Procedures . . . . . . . . . . . 56
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 56
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 57
9.1.1. Procedures for All Implementations . . . . . . . . . 57
9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 57
9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 58
9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 58
9.1.2. Procedures for Full Implementations . . . . . . . . . 58
9.1.2.1. Existing Media Streams with ICE Running . . . . . 58
9.1.2.2. Existing Media Streams with ICE Completed . . . . 59
9.1.3. Procedures for Lite Implementations . . . . . . . . . 59
9.1.3.1. Existing Media Streams with ICE Running . . . . . 59
9.1.3.2. Existing Media Streams with ICE Completed . . . . 60
9.2. Receiving the Offer and Generating an Answer . . . . . . 60
9.2.1. Procedures for All Implementations . . . . . . . . . 60
9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 60
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 61
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 61
9.2.2. Procedures for Full Implementations . . . . . . . . . 61
9.2.2.1. Existing Media Streams with ICE Running and no
remote-candidates . . . . . . . . . . . . . . . . 61
9.2.2.2. Existing Media Streams with ICE Completed and
no remote-candidates . . . . . . . . . . . . . . 61
9.2.2.3. Existing Media Streams and remote-candidates . . 61
9.2.3. Procedures for Lite Implementations . . . . . . . . . 62
9.3. Updating the Check and Valid Lists . . . . . . . . . . . 63
9.3.1. Procedures for Full Implementations . . . . . . . . . 63
9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 63
9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 63
9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 64
9.3.1.4. ICE Continuing for Existing Media Stream . . . . 64
9.3.2. Procedures for Lite Implementations . . . . . . . . . 64
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 65
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 66
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 66
11.1.1. Procedures for Full Implementations . . . . . . . . . 66
11.1.2. Procedures for Lite Implementations . . . . . . . . . 67
11.1.3. Procedures for All Implementations . . . . . . . . . 67
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 67
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 68
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 68
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 68
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 70
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 70
12.3. Interactions with Forking . . . . . . . . . . . . . . . . 70
12.4. Interactions with Preconditions . . . . . . . . . . . . . 70
12.5. Interactions with Third Party Call Control . . . . . . . 71
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 71
14. Extensibility Considerations . . . . . . . . . . . . . . . . 72
15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 73
15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 75
15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 75
15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 76
15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 76
16. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 76
16.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . . 77
16.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . 78
17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
18. Security Considerations . . . . . . . . . . . . . . . . . . . 85
18.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 86
18.2. Attacks on Server Reflexive Address Gathering . . . . . . 88
18.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 89
18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 89
18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 90
18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 90
18.5.2. STUN Amplification Attack . . . . . . . . . . . . . . 90
18.6. Interactions with Application Layer Gateways and SIP . . 91
19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 92
19.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 92
19.2. New Error Response Codes . . . . . . . . . . . . . . . . 93
20. Operational Considerations . . . . . . . . . . . . . . . . . 93
20.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 93
20.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 93
20.2.1. STUN and TURN Server Capacity Planning . . . . . . . 93
20.2.2. Gathering and Connectivity Checks . . . . . . . . . . 94
20.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 94
20.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 95
20.4. Troubleshooting and Performance Management . . . . . . . 95
20.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 95
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
21.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 96
21.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 96
21.1.2. remote-candidates Attribute . . . . . . . . . . . . . 96
21.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 97
21.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 97
21.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 98
21.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 98
21.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 98
21.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 99
21.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 99
22. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 99
22.1. Problem Definition . . . . . . . . . . . . . . . . . . . 100
22.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 100
22.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 101
22.4. Requirements for a Long-Term Solution . . . . . . . . . . 102
22.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 102
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 102
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 103
24.1. Normative References . . . . . . . . . . . . . . . . . . 103
24.2. Informative References . . . . . . . . . . . . . . . . . 104
Appendix A. Lite and Full Implementations . . . . . . . . . . . 107
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 108
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 108
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 109
B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 111
B.4. Importance of the STUN Username . . . . . . . . . . . . . 111
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 113
B.6. The remote-candidates Attribute . . . . . . . . . . . . . 113
B.7. Why Are Keepalives Needed? . . . . . . . . . . . . . . . 114
B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 115
B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 115
B.10. Why Are Binding Indications Used for Keepalives? . . . . 115
B.11. Why Is the Conflict Resolution Mechanism Needed? . . . . 116
RFC 3264 [RFC3264] defines a two-phase exchange of Session Description Protocol (SDP) messages [RFC4566] for the purposes of establishment of multimedia sessions. This offer/answer mechanism is used by protocols such as the Session Initiation Protocol (SIP) [RFC3261].
RFC 3264 [RFC3264]は、マルチメディアセッションの確立を目的として、セッション説明プロトコル（SDP）メッセージ[RFC4566]の2相交換を定義します。このオファー/回答メカニズムは、セッション開始プロトコル（SIP）[RFC3261]などのプロトコルで使用されます。
Protocols using offer/answer are difficult to operate through Network Address Translators (NATs). Because their purpose is to establish a flow of media packets, they tend to carry the IP addresses and ports of media sources and sinks within their messages, which is known to be problematic through NAT [RFC3235]. The protocols also seek to create a media flow directly between participants, so that there is no application layer intermediary between them. This is done to reduce media latency, decrease packet loss, and reduce the operational costs of deploying the application. However, this is difficult to accomplish through NAT. A full treatment of the reasons for this is beyond the scope of this specification.
オファー/回答を使用したプロトコルは、ネットワークアドレス翻訳者（NAT）を介して操作が困難です。彼らの目的はメディアパケットのフローを確立することであるため、彼らはメッセージ内のメディアソースとシンクのIPアドレスとポートを携帯する傾向があります。また、プロトコルは参加者間にメディアフローを直接作成しようとするため、それらの間にアプリケーションレイヤーの中間媒介がありません。これは、メディアの遅延を減らし、パケットの損失を減らし、アプリケーションの展開の運用コストを削減するために行われます。ただし、これはNATを通じて達成することは困難です。この理由の完全な扱いは、この仕様の範囲を超えています。
Numerous solutions have been defined for allowing these protocols to operate through NAT. These include Application Layer Gateways (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple Traversal of UDP Through NAT (STUN) [RFC3489] specification, and Realm Specific IP [RFC3102] [RFC3103] along with session description extensions needed to make them work, such as the Session Description Protocol (SDP) [RFC4566] attribute for the Real Time Control Protocol (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and cons which, make each one optimal in some network topologies, but a poor choice in others. The result is that administrators and implementors are making assumptions about the topologies of the networks in which their solutions will be deployed. This introduces complexity and brittleness into the system. What is needed is a single solution that is flexible enough to work well in all situations.
これらのプロトコルがNATを介して動作できるようにするために、多数のソリューションが定義されています。これらには、アプリケーションレイヤーゲートウェイ（ALG）、ミドルボックス制御プロトコル[RFC3303]、NAT（STUN）[RFC3489]仕様を介したUDPの元の単純なトラバーサル、およびレルム固有のIP [RFC3102] [RFC3103]とともに、セッションの説明拡張が必要なセッションの説明拡張が必要です。リアルタイムコントロールプロトコル（RTCP）[RFC3605]のセッション説明プロトコル（SDP）[RFC4566]属性など、それらを機能させます。残念ながら、これらの手法にはすべての手法があり、それぞれがいくつかのネットワークトポロジで最適になりますが、他のテクノロジーでは選択肢がありません。その結果、管理者と実装者は、ソリューションが展開されるネットワークのトポロジについて仮定を立てています。これにより、システムに複雑さと脆性が導入されます。必要なのは、あらゆる状況でうまく機能するほど柔軟性がある単一のソリューションです。
This specification defines Interactive Connectivity Establishment (ICE) as a technique for NAT traversal for UDP-based media streams (though ICE can be extended to handle other transport protocols, such as TCP [ICE-TCP]) established by the offer/answer model. ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports included in the SDP and the connectivity checks are performed using the revised STUN specification [RFC5389], now renamed to Session Traversal Utilities for NAT. The new name and new specification reflect its new role as a tool that is used with other NAT traversal techniques (namely ICE) rather than a standalone NAT traversal solution, as the original STUN specification was. ICE also makes use of Traversal Using Relays 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, and for this reason it deprecates RFC 4091 [RFC4091] and [RFC4092].
この仕様では、インタラクティブな接続性確立（ICE）を、UDPベースのメディアストリームのNATトラバーサルの手法として定義します（ただし、オファー/回答モデルによって確立されたTCP [ICE-TCP]など、他の輸送プロトコルを処理するためにICEを拡張できます）。ICEはオファー/回答モデルの拡張であり、SDPオファーと回答に多数のIPアドレスとポートを含めることで機能し、ピアツーピア接続のチェックによって接続がテストされます。SDPに含まれるIPアドレスとポートと接続チェックは、改訂されたSTUN仕様[RFC5389]を使用して実行され、NATのセッショントラバーサルユーティリティに改名されました。新しい名前と新しい仕様は、元のSTUN仕様がそうであったように、独立したNATトラバーサルソリューションではなく、他のNATトラバーサルテクニック（すなわちICE）で使用されるツールとしての新しい役割を反映しています。ICEは、STUNの拡張であるNAT（ターン）[RFC5766]の周りのリレーを使用してトラバーサルを使用します。ICEは各メディアストリームの多数のIPアドレスとポートを交換するため、マルチホームとデュアルスタックのホストのアドレス選択も可能になり、このため、RFC 4091 [RFC4091]および[RFC4092]を非難します。
In a typical ICE deployment, we have two endpoints (known as AGENTS in RFC 3264 terminology) that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can perform an offer/answer exchange of SDP [RFC3264] messages. Note that ICE is not intended for NAT traversal for SIP, which is assumed to be provided via another mechanism [RFC5626]. At the beginning of the ICE process, the agents are ignorant of their own topologies. In particular, they might or might not be behind a NAT (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 communicate.
典型的な氷の展開には、通信したい2つのエンドポイント（RFC 3264用語のエージェントとして知られています）があります。彼らは、SDP [RFC3264]メッセージのオファー/回答交換を実行できる、いくつかのシグナル伝達プロトコル（SIPなど）を介して間接的に通信することができます。ICEは、SIPのNATトラバーサルを意図していないことに注意してください。これは、別のメカニズム[RFC5626]を介して提供されると想定されています。氷のプロセスの開始時に、エージェントは自分のトポロジを無知です。特に、彼らはNAT（またはNATの複数の層）の背後にいるかもしれないし、そうでないかもしれません。ICEにより、エージェントはトポロジーに関する十分な情報を発見して、通信できる1つ以上のパスを潜在的に見つけることができます。
Figure 1 shows a typical environment for ICE deployment. The two endpoints are labelled L and R (for left and right, which helps visualize call flows). 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. Agents L and R are capable of engaging in an offer/answer exchange by which they can exchange SDP messages, whose purpose is to set up a media session between L and R. Typically, this exchange will occur through a SIP server.
図1は、氷の展開の典型的な環境を示しています。2つのエンドポイントには、LとRとラベル付けされています（左右の場合、コールフローを視覚化するのに役立ちます）。LとRの両方がそれぞれのNATの背後にありますが、彼らはそれを認識していないかもしれません。NATのタイプとその特性も不明です。エージェントLとRは、LとRの間にメディアセッションをセットアップすることを目的とするSDPメッセージを交換できるオファー/回答の交換に従事することができます。通常、この交換はSIPサーバーを介して発生します。
In addition to the agents, a SIP 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.
エージェント、SIPサーバー、およびNATに加えて、ICEは通常、ネットワーク内のスタンまたはターンサーバーとの協調で使用されます。各エージェントは、独自のスタンまたはサーバーをターンすることができます。または、同じものにすることができます。
+-------+
| SIP |
+-------+ | Srvr | +-------+
| STUN | | | | STUN |
| Srvr | +-------+ | Srvr |
| | / \ | |
+-------+ / \ +-------+
/ \
/ \
/ \
/ \
/ <- Signaling -> \
/ \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
/ \
+-------+ +-------+
| Agent | | Agent |
| L | | R |
| | | |
+-------+ +-------+
Figure 1: ICE Deployment Scenario
図1：アイス展開シナリオ
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:
氷の背後にある基本的なアイデアは次のとおりです。各エージェントには、さまざまな候補輸送アドレス（この仕様では常にUDPである特定の輸送プロトコルのIPアドレスとポートの組み合わせ）があります）は、他のエージェントとの通信に使用できます。これらには以下が含まれます。
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 ターンサーバー（「中継アドレス」）から割り当てられたトランスポートアドレス。
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がこれを行う方法は、1つ以上の機能が見つかるまで、可能なすべてのペア（慎重に並べ替えられた順序で）を体系的に試すことです。
In order to execute ICE, an agent has to identify all of its address candidates. A CANDIDATE is a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here). This document defines three types of candidates, some derived from physical or logical network interfaces, others discoverable via STUN and TURN. Naturally, one viable candidate is a transport address obtained directly from a local interface. Such a candidate is called a HOST CANDIDATE. The local interface could be ethernet or WiFi, 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.
ICEを実行するために、エージェントはすべてのアドレス候補を特定する必要があります。候補者は、特定の輸送プロトコル用のIPアドレスとポートの組み合わせです（ここではUDPのみが指定されています）。このドキュメントでは、物理的または論理的なネットワークインターフェイスから派生した3つのタイプの候補を定義します。当然のことながら、1つの実行可能な候補は、ローカルインターフェイスから直接取得されたトランスポートアドレスです。このような候補者は、ホスト候補と呼ばれます。ローカルインターフェイスは、イーサネットまたはWiFiである可能性があります。または、仮想プライベートネットワーク（VPN）やモバイルIP（MIP）などのトンネルメカニズムを介して取得されるものである可能性があります。すべての場合において、このようなネットワークインターフェイスは、ポート（したがって候補者）を割り当てることができるローカルインターフェイスとしてエージェントに表示されます。
If an agent is multihomed, it obtains a candidate from each IP address. Depending on the location of the PEER (the other agent in the session) on the IP network relative to the agent, the agent may be reachable by the peer through one or more of those IP addresses. Consider, for example, an agent that has a local IP address on a private net 10 network (I1), and a second connected to the public Internet (I2). A candidate from I1 will be directly reachable when communicating with a peer on the same private net 10 network, while a candidate from I2 will be directly reachable when communicating with a peer on the public Internet. Rather than trying to guess which IP address will work prior to sending an offer, the offering agent includes both candidates in its offer.
エージェントがマルチホームされている場合、各IPアドレスから候補を取得します。エージェントと比較して、IPネットワーク上のピア（セッションの他のエージェント）の場所（セッションの他のエージェント）に応じて、エージェントは、これらのIPアドレスの1つ以上を介してピアが到達できる場合があります。たとえば、プライベートネット10ネットワーク（I1）にローカルIPアドレスを持っているエージェントと、パブリックインターネット（I2）に接続された2番目のエージェントを検討してください。I1の候補者は、同じプライベートネット10ネットワークでピアと通信するときに直接到達可能になりますが、I2の候補者は、パブリックインターネットでピアと通信するときに直接到達可能になります。オファーを送信する前にどのIPアドレスが機能するかを推測するのではなく、提供エージェントには両方の候補者がそのオファーに含まれます。
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.
次に、エージェントはスタンまたはターンを使用して追加の候補者を取得します。これらには2つのフレーバーがあります。NAT（サーバー反射候補）のパブリック側での翻訳されたアドレスと、ターンサーバー（中継候補）のアドレス。ターンサーバーが使用されると、両方のタイプの候補がターンサーバーから取得されます。スタンサーバーのみが利用されている場合、サーバー反射候補のみがそれらから取得されます。これらの候補者とホスト候補の関係を図2に示します。この図では、両方のタイプの候補がターンを使用して発見されます。図では、表記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 the 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. We call the host candidate associated with a given server reflexive candidate the BASE.
エージェントがIPアドレスとポートX：Xからターンアロケートリクエストを送信すると、NAT（1つがあると仮定）がバインディング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.
エージェントとターンサーバーの間に複数のNATがある場合、ターンリクエストは各NATにバインディングを作成しますが、エージェントによって最も外側のサーバー反射候補（ターンサーバーに最も近い1つ）のみが発見されます。エージェントが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.
その後、Alocateリクエストはターンサーバーに到着します。ターンサーバーは、ローカルIPアドレスYからポートYを割り当て、割り当てられた応答を生成し、この中継候補のエージェントに通知します。また、ターンサーバーは、Allocateリクエストのソーストランスポートアドレスを割り当て応答にコピーすることにより、サーバー反射候補のエージェントx1 '：x1'にも通知します。ターンサーバーはパケットリレーとして機能し、LとRの間のトラフィックを転送します。Lにトラフィックを送信するために、rはy：yでターンサーバーにトラフィックを送信し、ターンサーバーはそれを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.
スタンサーバーのみが使用されると、エージェントはスタンビンディングリクエスト[RFC5389]をスタンサーバーに送信します。STUNサーバーは、バインディングリクエストのソーストランスポートアドレスをバインディング応答にコピーすることにより、サーバー反射候補x1 '：x1'のエージェントに通知します。
Once L has gathered all of its candidates, it orders them in highest to lowest priority and sends them to R over the signaling channel. The candidates are carried in attributes in the SDP offer. When R receives the offer, it performs the same gathering process and responds with its own list of candidates. At the end of this process, each 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 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に送信します。候補者は、SDPオファーの属性に携帯されています。Rがオファーを受け取ると、同じ収集プロセスを実行し、独自の候補者リストで応答します。このプロセスの終わりに、各エージェントには、候補者とピアの候補者の両方の完全なリストがあります。それらをペアにして、候補のペアになります。どのペアが機能するかを確認するには、各エージェントが一連のチェックをスケジュールします。各チェックは、地元の候補者からリモート候補者にスタンリクエストを送信することにより、クライアントが特定の候補者ペアで実行するスタンリクエスト/応答トランザクションです。
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--スタンリクエスト - > \ l's < - スタン応答 /チェック
<- STUN request \ R's
STUN response -> / check
Figure 3: Basic Connectivity Check
図3：基本的な接続チェック
It is important to note that the STUN requests are sent to and from the exact same IP addresses and ports that will be used for media (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ RTCP using contents of the packets, rather than the port on which they are received. Fortunately, this demultiplexing is easy to do, especially for RTP and RTCP.
STUN要求は、メディアに使用されるまったく同じIPアドレスとポート（RTPやRTCPなど）に送信されることに注意することが重要です。その結果、エージェントは、受信したポートではなく、パケットのコンテンツを使用して、STUNおよびRTP/ RTCPのDemultiplexとRTP/ RTCPをスタンします。幸いなことに、特にRTPとRTCPでは、この逆流は簡単です。
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 other candidates the agent already learned, it represents a new candidate, called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just the same as any other candidate.
接続チェックにはスタンバインディングリクエストが使用されるため、スタンバインディング応答には、エージェントとそのピアの間のNATのパブリック側にエージェントの翻訳された輸送アドレスが含まれます。この輸送住所がすでに学んだ他の候補者とは異なる場合、ピア反射候補と呼ばれる新しい候補者を表し、他の候補と同じようにICEでテストされます。
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 accelerates the process of finding a valid candidate, and is called a TRIGGERED CHECK.
最適化として、RがLのチェックメッセージを取得するとすぐに、Rは同じ候補ペアで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の両方は、両方向にエンドツーエンドのメッセージを送信（および受信）できることを知っています。
Because the algorithm above searches all candidate pairs, if a working pair exists it 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 CHECK LIST. The algorithm is described in Section 4.1.2 but follows two general principles:
上のアルゴリズムはすべての候補ペアを検索するため、作業ペアが存在する場合、候補者がどの順序で試行されていても、最終的にそれが見つかります。より速く（そしてより良い）結果を生成するために、候補者は指定された順序でソートされます。ソートされた候補ペアの結果のリストは、チェックリストと呼ばれます。アルゴリズムはセクション4.1.2で説明されていますが、2つの一般原則に従います。
o Each agent gives its candidates a numeric priority, which is sent along with the candidate to the peer.
o 各エージェントには、候補者と一緒にピアに送られる数値の優先度を候補者に与えます。
o The local and remote priorities are combined so that each agent has the same ordering for the candidate pairs.
o 各エージェントが候補ペアに対して同じ順序を持つように、ローカルおよびリモートの優先順位が組み合わされています。
The second property is important for getting ICE to work when there are NATs in front of L and R. Frequently, NATs will not allow packets in from a host until the agent behind the NAT has sent a packet towards that host. Consequently, ICE checks in each direction will not succeed until both sides have sent a check through their respective NATs.
2番目のプロパティは、LとRの前にNATがいる場合に氷を動作させるために重要です。頻繁に、NATはNATの後ろのエージェントがそのホストにパケットを送信するまで、ホストからパケットを入れません。その結果、両側がそれぞれのNATを通してチェックを送信するまで、各方向の氷のチェックは成功しません。
The agent works through this check list by sending a STUN request for the next candidate pair on the list periodically. These are called ORDINARY CHECKS.
エージェントは、リストの次の候補ペアのスタンリクエストを定期的に送信することにより、このチェックリストを使用します。これらは通常のチェックと呼ばれます。
In general, the priority algorithm is designed so that candidates of similar type get similar priorities and so that more direct routes (that is, through fewer media relays and through fewer NATs) are preferred over indirect ones (ones with more media relays and more NATs). Within those guidelines, however, agents have a fair amount of discretion about how to tune their algorithms.
一般に、優先アルゴリズムは、同様のタイプの候補者が同様の優先順位を取得し、より多くの直接的なルート（つまり、メディアリレーが少なく、より少ないNAT）よりも優先されるように設計されています（メディアリレーが多く、NATが増えます。）。ただし、これらのガイドラインでは、エージェントはアルゴリズムをチューニングする方法についてかなりの額の裁量をしています。
The previous description only addresses the case where the agents wish to establish a media session with one COMPONENT (a piece of a media stream requiring a single transport address; a media stream may require multiple components, each of which has to work for the media stream as a whole to be work). Typically (e.g., with RTP and RTCP), the agents actually need to establish connectivity for more than one flow.
前の説明は、エージェントが1つのコンポーネント（単一のトランスポートアドレスを必要とするメディアストリームの一部）を使用してメディアセッションを確立したい場合にのみ対応します。メディアストリームには複数のコンポーネントが必要になる場合があります。全体として仕事になる）。通常（例えば、RTPおよびRTCPを使用）、エージェントは実際に複数のフローの接続を確立する必要があります。
The network properties are likely to be very similar for each component (especially because RTP and RTCP are sent and received from the same IP address). It is usually possible to leverage information from one media component in order to determine the best candidates for another. ICE does this with a mechanism called "frozen candidates".
ネットワークプロパティは、各コンポーネントで非常に類似している可能性があります（特に、RTPとRTCPが同じIPアドレスから送信および受信されるため）。通常、あるメディアコンポーネントからの情報を活用して、別の候補者に最適な候補者を決定することが可能です。ICEは、「凍結候補」と呼ばれるメカニズムでこれを行います。
Each candidate is associated with a property called its FOUNDATION. Two candidates have the same foundation when they are "similar" -- of the same type and obtained from the same host candidate and STUN server using the same protocol. Otherwise, their foundation is different. A candidate pair has a foundation too, which is just the concatenation of the foundations of its two candidates. Initially, only the candidate pairs with unique foundations are tested. The other candidate pairs are marked "frozen". When the connectivity checks for a candidate pair succeed, the other candidate pairs with the same foundation are unfrozen. This avoids repeated checking of components that are superficially more attractive but in fact are likely to fail.
各候補者は、その基礎と呼ばれるプロパティに関連付けられています。2人の候補者は、同じタイプの「類似」であり、同じプロトコルを使用して同じホスト候補とスタンサーバーから取得した場合、同じ基盤を持っています。そうでなければ、彼らの基盤は異なります。候補者のペアにも基礎があります。これは、2人の候補者の基礎の連結にすぎません。当初、一意の基礎を持つ候補ペアのみがテストされています。他の候補ペアには「フローズン」とマークされています。候補ペアの接続が成功すると、同じ基盤を持つ他の候補ペアが登場しません。これにより、表面的にはより魅力的ですが、実際には失敗する可能性が高いコンポーネントの繰り返しのチェックが回避されます。
While we've described "frozen" here as a separate mechanism for expository purposes, in fact it is an integral part of ICE and the ICE prioritization algorithm automatically ensures that the right candidates are unfrozen and checked in the right order.
ここでは「フローズン」を説明する目的のための別のメカニズムとして説明しましたが、実際には氷の不可欠な部分であり、氷の優先順位付けアルゴリズムは自動的に適切な候補者が未zenであり、適切な順序でチェックされることを保証します。
Because ICE is used to discover which addresses can be used to send media between two agents, it is important to ensure that the process cannot be hijacked to send media to the wrong location. Each STUN connectivity check is covered by a message authentication code (MAC) computed using a key exchanged in the signaling channel. This MAC provides message integrity and data origin authentication, thus stopping an attacker from forging or modifying connectivity check messages. Furthermore, if the SIP [RFC3261] caller is using ICE, and their call forks, the ICE exchanges happen independently with each forked recipient. In such a case, the keys exchanged in the signaling help associate each ICE exchange with each forked recipient.
ICEは、2つのエージェント間でメディアを送信するためにどのアドレスを使用できるかを発見するために使用されるため、メディアを間違った場所に送信するためにハイジャックできないことを確認することが重要です。各スタン接続チェックは、信号チャネルで交換されたキーを使用して計算されたメッセージ認証コード（MAC）によってカバーされます。このMACは、メッセージの整合性とデータ起源の認証を提供するため、攻撃者が接続チェックメッセージの鍛造または変更を停止します。さらに、SIP [RFC3261]発信者がICEを使用しており、コールフォークを使用している場合、氷の交換は各フォークのレシピエントと独立して発生します。そのような場合、シグナリングで交換されたキーは、各氷の交換を各フォークのレシピエントと関連付けるのに役立ちます。
ICE checks are performed in a specific sequence, so that high-priority candidate pairs are checked first, followed by lower-priority ones. One way to conclude ICE is to declare victory as soon as a check for each component of each media stream completes successfully. Indeed, this is a reasonable algorithm, and details for it are provided below. However, it is possible that a packet loss will cause a higher-priority check to take longer to complete. In that case, allowing ICE to run a little longer might produce better results. More fundamentally, however, the prioritization defined by this specification may not yield "optimal" results. As an example, if the aim is to select low-latency media paths, usage of a relay is a hint that latencies may be higher, but it is nothing more than a hint. An actual round-trip time (RTT) measurement could be made, and it might demonstrate that a pair with lower priority is actually better than one with higher priority.
アイスチェックは特定のシーケンスで実行されるため、優先順位の高い候補ペアが最初にチェックされ、次に低優先度のペアがチェックされます。ICEを結論付ける1つの方法は、各メディアストリームの各コンポーネントのチェックが正常に完了するとすぐに勝利を宣言することです。実際、これは合理的なアルゴリズムであり、その詳細を以下に示します。ただし、パケットの損失により、より優先度の高いチェックが完了するのに時間がかかる可能性があります。その場合、氷をもう少し長く走らせることで、より良い結果が得られる可能性があります。しかし、より根本的には、この仕様で定義された優先順位付けは、「最適な」結果をもたらさない場合があります。例として、低遅延メディアパスを選択することを目的としている場合、リレーの使用はレイテンシが高くなる可能性があるというヒントですが、それはヒントに過ぎません。実際の往復時間（RTT）測定を行うことができ、優先度の低いペアが実際に優先度が高いペアよりも優れていることを示している可能性があります。
Consequently, ICE assigns one of the agents in the role of the CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The controlling agent gets to nominate which candidate pairs will get used for media amongst the ones that are valid. It can do this in one of two ways -- using REGULAR NOMINATION or AGGRESSIVE NOMINATION.
その結果、ICEは、制御エージェントの役割におけるエージェントの1つ、もう1つは制御エージェントの1つを割り当てます。制御エージェントは、どの候補ペアが有効なペアの中でメディアに使用されるかを指名します。これは、通常のノミネートまたは積極的な指名を使用して、2つの方法のいずれかで行うことができます。
With regular nomination, the controlling agent lets the checks continue until at least one valid candidate pair for each media stream is found. Then, it picks amongst those that are valid, and sends a second STUN request on its NOMINATED candidate pair, but this time with a flag set to tell the peer that this pair has been nominated for use. This is shown in Figure 4.
定期的な指名により、コントロールエージェントは、各メディアストリームの少なくとも1つの有効な候補ペアが見つかるまでチェックを継続させます。次に、有効なものの中で選択し、ノミネートされた候補者ペアに2番目のスタンリクエストを送信しますが、今回はこのペアが使用のためにノミネートされたことをピアに伝えるフラグが設定されています。これを図4に示します。
L R - - STUN request -> \ L's <- STUN response / check
l r--スタンリクエスト - > \ l's < - スタン応答 /チェック
<- STUN request \ R's
STUN response -> / check
STUN request + flag -> \ L's
<- STUN response / check
Figure 4: Regular Nomination
図4：通常の指名
Once the STUN transaction with the flag completes, both sides cancel any future checks for that media stream. ICE will now send media using this pair. The pair an ICE agent is using for media is called the SELECTED PAIR.
フラグを備えたスタントランザクションが完了すると、そのメディアストリームの将来のチェックをキャンセルします。ICEはこのペアを使用してメディアを送信するようになりました。アイスエージェントがメディアに使用しているペアは、選択したペアと呼ばれます。
In aggressive nomination, the controlling agent puts the flag in every STUN request it sends. This way, once the first check succeeds, ICE processing is complete for that media stream and the controlling agent doesn't have to send a second STUN request. The selected pair will be the highest-priority valid pair whose check succeeded. Aggressive nomination is faster than regular nomination, but gives less flexibility. Aggressive nomination is shown in Figure 5.
積極的な指名で、コントロールエージェントは、送信するすべてのスタンリクエストにフラグを置きます。このようにして、最初のチェックが成功すると、そのメディアストリームのために氷加工が完了し、制御エージェントは2番目のスタンリクエストを送信する必要はありません。選択されたペアは、チェックが成功した最も優先順位の有効なペアになります。積極的な指名は通常の指名よりも速いですが、柔軟性が低下します。積極的な指名を図5に示します。
L R
- -
STUN request + flag -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
Figure 5: Aggressive Nomination
図5：積極的な指名
Once all of the media streams are completed, the controlling endpoint sends an updated offer if the candidates in the m and c lines for the media stream (called the DEFAULT CANDIDATES) don't match ICE's SELECTED CANDIDATES.
すべてのメディアストリームが完了すると、メディアストリーム（デフォルト候補と呼ばれる）のMおよびCラインの候補者がICEの選択した候補と一致しない場合、制御エンドポイントは更新されたオファーを送信します。
Once ICE is concluded, it can be restarted at any time for one or all of the media streams by either agent. This is done by sending an updated offer indicating a restart.
氷が終了すると、いずれかのエージェントによってメディアストリームの1つまたはすべてがいつでも再起動できます。これは、再起動を示す更新オファーを送信することによって行われます。
In order for ICE to be used in a call, both agents need to support it. However, certain 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). A lite implementation doesn't gather candidates; it includes only host candidates for any media stream. Lite agents do not generate connectivity checks or run the state machines, though they need to be able to respond to connectivity checks. When a lite implementation connects with a full implementation, the full agent takes the role of the controlling agent, and the lite agent takes on the controlled role. When two lite implementations connect, no checks are sent.
氷を呼び出しに使用するには、両方のエージェントがそれをサポートする必要があります。ただし、特定のエージェントは常にパブリックインターネットに接続され、特派員からパケットを受信できるパブリックIPアドレスを持っています。これらのデバイスがICEをサポートできるようにするために、ICEはLiteと呼ばれる特別なタイプの実装を定義します（通常の完全な実装とは対照的に）。Liteの実装では候補者が集まりません。メディアストリームのホスト候補のみが含まれます。ライトエージェントは、接続マシンを生成したり、状態マシンを実行したりしませんが、接続チェックに応答できる必要があります。Liteの実装が完全な実装と接続すると、完全なエージェントが制御エージェントの役割を担い、Liteエージェントは制御された役割を引き受けます。2つのLite実装が接続すると、チェックは送信されません。
For guidance on when a lite implementation is appropriate, see the discussion in Appendix A.
Liteの実装が適切な場合のガイダンスについては、付録Aの説明を参照してください。
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, a full implementation is preferable if achievable.
Liteの実装がこの仕様に追加され、完全な実装に足がかりを提供することに注意することが重要です。常にパブリックインターネットに接続されているデバイスであっても、達成可能な場合は完全な実装が望ましいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Readers should be familiar with the terminology defined in the offer/ answer model [RFC3264], STUN [RFC5389], and NAT Behavioral requirements for UDP [RFC4787].
読者は、UDP [RFC4787]のオファー/回答モデル[RFC3264]、スタン[RFC5389]、およびNAT行動要件で定義されている用語に精通している必要があります。
This specification makes use of the following additional terminology:
この仕様では、次の追加用語を使用します。
Agent: As defined in RFC 3264, an agent is the protocol implementation involved in the offer/answer exchange. There are two agents involved in an offer/answer exchange.
エージェント：RFC 3264で定義されているように、エージェントはオファー/回答の交換に関与するプロトコルの実装です。オファー/回答の交換には2つのエージェントが関与しています。
Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the offerer, the peer is the answerer. From the perspective of the answerer, the peer is the offerer.
ピア：セッションのエージェントの1人の観点から見ると、そのピアは他のエージェントです。具体的には、提供者の観点から見ると、ピアは回答者です。回答者の観点から見ると、ピアはオファーです。
Transport Address: The combination of an IP address and transport protocol (such as UDP or TCP) port.
トランスポートアドレス：IPアドレスと輸送プロトコル（UDPやTCPなど）ポートの組み合わせ。
Candidate: A transport address that is a potential point of contact for receipt of media. Candidates also have properties -- their type (server reflexive, relayed or host), priority, foundation, and base.
候補者：メディアの受領の潜在的な連絡先である輸送住所。候補者には、そのタイプ（サーバー反射、中継、またはホスト）、優先度、基礎、ベースのプロパティもあります。
Component: A component is a piece of a media stream requiring a single transport address; a media stream may require multiple components, each of which has to work for the media stream as a whole to work. For media streams based on RTP, there are two components per media stream -- one for RTP, and one for RTCP.
コンポーネント：コンポーネントは、単一の輸送アドレスを必要とするメディアストリームの一部です。メディアストリームには複数のコンポーネントが必要になる場合がありますが、それぞれがメディアストリーム全体で機能するために機能する必要があります。RTPに基づくメディアストリームの場合、メディアストリームごとに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 Virtual Private Networks (VPNs) and Realm Specific IP (RSIP) [RFC3102] (which lives at the operating system level).
ホスト候補：ホストのIPアドレスから特定のポートにバインディングすることで取得した候補者。これには、仮想プライベートネットワーク（VPNS）およびレルム固有のIP（RSIP）[RFC3102]（オペレーティングシステムレベルに存在する）を介して取得したものなど、物理インターフェイスのIPアドレスや論理インターフェイスのIPアドレスが含まれます。
Server Reflexive Candidate: A candidate whose IP address and port are a binding allocated by a NAT for an agent when it sent a packet through the NAT to a server. Server reflexive candidates can be learned by STUN servers using the Binding request, or TURN servers, which provides both a relayed and server reflexive candidate.
サーバー反射候補：IPアドレスとポートが、AgentがNATを介してサーバーにパケットを送信したときにNATによって割り当てられたバインディングである候補。サーバー反射候補は、バインディングリクエストを使用してスタンサーバーによって学習することも、リレーした候補とサーバー反射候補の両方を提供するサーバーをターンすることもできます。
Peer Reflexive Candidate: A candidate whose IP address and port are a binding allocated by a NAT for an agent when it sent a STUN Binding request through the NAT to its peer.
ピア反射候補：IPアドレスとポートが、NATを介してSTUNバインディングリクエストをピアに送信したときにAGENにNATによって割り当てられた拘束力のある候補。
Relayed Candidate: A candidate obtained by sending a TURN Allocate request from a host candidate to a TURN server. The relayed candidate is resident on the TURN server, and the TURN server relays packets back towards the agent.
中継された候補者：ホスト候補からターンサーバーにターン割り当てリクエストを送信することで取得した候補者。中継された候補者はターンサーバーに居住しており、ターンサーバーはパケットをエージェントにリレーします。
Base: The base of a server reflexive candidate is the host candidate from which it was derived. A host candidate is also said to have a base, equal to that candidate itself. Similarly, the base of a relayed candidate is that candidate itself.
ベース：サーバー反射候補のベースは、派生したホスト候補です。ホスト候補者は、その候補者自身に等しいベースを持っているとも言われています。同様に、中継された候補のベースは、その候補者自体です。
Foundation: An arbitrary string that 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. Two candidate pairs with the same foundation pairs are likely to have similar network characteristics. Foundations are used in the frozen algorithm.
基礎：同じタイプ、ベースIPアドレス、プロトコル（UDP、TCPなど）、およびスタンまたはターンサーバーを持っている2つの候補で同じ任意の文字列。これらのいずれかが異なる場合、財団は異なります。同じ基礎ペアを持つ2つの候補ペアには、同様のネットワーク特性がある可能性があります。基礎は凍結アルゴリズムで使用されます。
Local Candidate: A candidate that an agent has obtained and included in an offer or answer it sent.
地元の候補者：エージェントが送信した申し出や回答に入手して含めた候補者。
Remote Candidate: A candidate that an agent received in an offer or answer from its peer.
リモート候補者：エージェントがピアから申し出または回答で受け取った候補者。
Default Destination/Candidate: The default destination for a component of a media stream is the transport address that would be used by an agent that is not ICE aware. For the RTP component, the default IP address is in the c line of the SDP, and the port is in the m line. For the RTCP component, it is in the rtcp attribute when present, and when not present, the IP address is in the c line and 1 plus the port is in the m line. A default candidate for a component is one whose transport address matches the default destination for that component.
デフォルトの宛先/候補：メディアストリームのコンポーネントのデフォルトの宛先は、ICEが認識していないエージェントが使用するトランスポートアドレスです。RTPコンポーネントの場合、デフォルトのIPアドレスはSDPのCラインにあり、ポートはMラインにあります。RTCPコンポーネントの場合、存在するときはRTCP属性にあり、存在しない場合、IPアドレスはCラインにあり、1プラスポートはMラインにあります。コンポーネントのデフォルトの候補は、そのコンポーネントのコンポーネントの候補です。
Candidate Pair: A pairing containing a local candidate and a remote candidate.
候補ペア：地元の候補者とリモート候補を含むペアリング。
Check, Connectivity Check, STUN Check: A STUN Binding request transaction for the purposes of verifying connectivity. A check is sent from the local candidate to the remote candidate of a candidate pair.
チェック、接続チェック、スタンチェック：接続を検証する目的で、スタンバインディングリクエストトランザクション。小切手は、地元の候補者から候補ペアのリモート候補に送信されます。
Check List: An ordered set of candidate pairs that an agent will use to generate checks.
チェックリスト：エージェントがチェックを生成するために使用する候補ペアの順序付けられたセット。
Ordinary Check: A connectivity check generated by an agent as a consequence of a timer that fires periodically, instructing it to send a check.
通常のチェック：定期的に発射するタイマーの結果としてエージェントによって生成された接続チェック。チェックを送信するように指示します。
Triggered Check: A connectivity check generated as a consequence of the receipt of a connectivity check from the peer.
トリガーチェック：ピアからの接続チェックの受領の結果として生成された接続チェック。
Valid List: An ordered set of candidate pairs for a media stream that have been validated by a successful STUN transaction.
有効なリスト：成功したスタントランザクションによって検証されたメディアストリームの候補ペアの順序付けられたセット。
Full: An ICE implementation that performs the complete set of functionality defined by this specification.
完全：この仕様で定義された機能の完全なセットを実行するICE実装。
Lite: An ICE implementation that omits certain functions, implementing only as much as is necessary for a peer implementation that is full to gain the benefits of ICE. Lite implementations do not maintain any of the state machines and do not generate connectivity checks.
Lite：特定の機能を省略し、氷の利点を獲得するために完全なピア実装に必要なだけ実装する氷の実装。Liteの実装は、状態マシンを維持せず、接続性チェックを生成しません。
Controlling Agent: The ICE agent that is responsible for selecting the final choice of candidate pairs and signaling them through STUN and an updated offer, if needed. In any session, one agent is always controlling. The other is the controlled agent.
コントロールエージェント：候補ペアの最終的な選択を選択し、必要に応じてスタンと更新されたオファーを通じてそれらを通知する責任のあるアイスエージェント。どのセッションでも、1人のエージェントが常に制御しています。もう1つは制御エージェントです。
Controlled Agent: An ICE agent that waits for the controlling agent to select the final choice of candidate pairs.
制御エージェント：制御剤が候補ペアの最終選択を選択するのを待つ氷剤。
Regular Nomination: The process of picking a valid candidate pair for media traffic by validating the pair with one STUN request, and then picking it by sending a second STUN request with a flag indicating its nomination.
通常の指名：1つのスタンリクエストでペアを検証することにより、メディアトラフィックの有効な候補ペアを選択し、その指名を示すフラグで2番目のスタンリクエストを送信することにより、それを選択するプロセス。
Aggressive Nomination: The process of picking a valid candidate pair for media traffic by including a flag in every STUN request, such that the first one to produce a valid candidate pair is used for media.
積極的な指名：すべてのスタン要求にフラグを含めることにより、メディアトラフィックの有効な候補ペアを選ぶプロセス。
Nominated: If a valid candidate pair has its nominated flag set, it means that it may be selected by ICE for sending and receiving media.
ノミネート：有効な候補者ペアにノミネートされたフラグセットがある場合、メディアを送信および受信するためにICEによって選択される可能性があることを意味します。
Selected Pair, Selected Candidate: The candidate pair selected by ICE for sending and receiving media is called the selected pair, and each of its candidates is called the selected candidate.
選択されたペア、選択された候補：メディアを送信および受信するためにICEで選択された候補ペアは選択されたペアと呼ばれ、各候補は選択された候補と呼ばれます。
In order to send the initial offer in an offer/answer exchange, an agent must (1) gather candidates, (2) prioritize them, (3) eliminate redundant candidates, (4) choose default candidates, and then (5) formulate and send the SDP offer. All but the last of these five steps differ for full and lite implementations.
オファー/回答の交換で初期オファーを送信するには、エージェントが（1）候補者を収集し、（2）優先順位を付け、（3）冗長候補を排除し、（4）デフォルト候補を選択し、次に（5）定式化して定式化して（5）SDPオファーを送信します。これらの5つのステップの最後を除くすべては、完全な実装とライトの実装で異なります。
An agent gathers candidates when it believes that communication is imminent. An offerer can do this based on a user interface cue, or based on an explicit request to initiate a session. Every candidate is 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. The base of a candidate is the candidate that an agent must send from when using that candidate.
エージェントは、コミュニケーションが差し迫っていると信じるときに候補者を集めます。オファーは、ユーザーインターフェイスキューに基づいて、またはセッションを開始するための明示的なリクエストに基づいてこれを行うことができます。すべての候補者は輸送住所です。また、タイプとベースがあります。この仕様では、ホスト候補、サーバー反射候補、ピア反射候補、および中継候補の4つのタイプが定義および収集されます。サーバーの反射候補は、スタンまたはターンを使用して収集され、中継された候補者はターンで得られます。ピア反射候補は、接続性チェックの結果として、氷の後期段階で得られます。候補者のベースは、その候補者を使用するときにエージェントが送信しなければならない候補です。
The first step is to gather host candidates. Host candidates are obtained by binding to ports (typically ephemeral) on a IP address attached to an interface (physical or virtual, including VPN interfaces) on the host.
最初のステップは、ホスト候補者を集めることです。ホスト候補は、ホストのインターフェイス（VPNインターフェイスを含む物理的または仮想）に接続されたIPアドレスでポート（通常は短命）に結合することにより取得されます。
For each UDP media stream the agent wishes to use, the agent SHOULD obtain a candidate for each component of the media stream on each IP address that the host has. It 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. Each component has an ID assigned to it, called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP, it MUST obtain a candidate for it. If an agent is using both RTP and RTCP, it would end up with 2*K host candidates if an agent has K IP addresses.
エージェントが使用したい各UDPメディアストリームについて、エージェントは、ホストが持っている各IPアドレスのメディアストリームの各コンポーネントの候補を取得する必要があります。特定のIPアドレスのUDPポートにバインドすることにより、各候補を取得します。ホスト候補者（および実際にはすべての候補者）は、常に候補者である特定のコンポーネントに関連付けられています。各コンポーネントには、コンポーネントIDと呼ばれるIDが割り当てられています。RTPベースのメディアストリームの場合、RTP自体には1のコンポーネントIDがあり、RTCPは2のコンポーネントIDを持ちます。エージェントがRTCPを使用している場合、候補を取得する必要があります。エージェントがRTPとRTCPの両方を使用している場合、エージェントがK IPアドレスを持っている場合、2*kホスト候補になります。
The base for each host candidate is set to the candidate itself.
各ホスト候補のベースは、候補者自体に設定されます。
Agents SHOULD obtain relayed candidates and SHOULD obtain server reflexive candidates. These requirements are at SHOULD strength to allow for provider variation. Use of STUN and TURN servers may be unnecessary in closed networks where agents are never connected to the public Internet or to endpoints outside of the closed network. In such cases, a full implementation would be used for agents that are dual stack or multihomed, to select a host candidate. Use of TURN servers is expensive, and when ICE is being used, they will only be utilized when both endpoints are behind NATs that perform address and port dependent mapping. Consequently, some deployments might consider this use case to be marginal, and elect not to use TURN servers. 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.
エージェントは中継された候補を取得し、サーバー反射候補を取得する必要があります。これらの要件は、プロバイダーのバリエーションを可能にするために強度があります。Stunおよびターンサーバーの使用は、エージェントがパブリックインターネットや閉じたネットワーク外のエンドポイントに接続されない閉じたネットワークでは不要です。そのような場合、ホスト候補を選択するために、デュアルスタックまたはマルチホームのエージェントに完全な実装が使用されます。ターンサーバーの使用は高価であり、氷が使用されている場合、両方のエンドポイントがアドレスとポートに依存するマッピングを実行するNATの背後にある場合にのみ使用されます。その結果、一部の展開では、このユースケースが限界であると考える場合があり、ターンサーバーを使用しないことを選択します。エージェントがサーバーの反射または中継候補を収集しない場合、将来の条件が変化した場合に構成を通じて再度有効にすることができるように、機能を実装し、構成を通じて無効にすることをお勧めします。
If an agent is gathering both relayed and server reflexive candidates, it uses a TURN server. If it is gathering just server reflexive candidates, it uses a STUN server.
エージェントが中継候補とサーバー反射候補の両方を収集している場合、ターンサーバーを使用します。サーバー反射候補のみを収集している場合、スタンサーバーを使用します。
The agent next pairs each host candidate with the STUN or TURN server with which it is configured or has discovered by some means. If a STUN or TURN server is configured, it is RECOMMENDED that a domain name be configured, and 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.
次に、エージェントは、各ホスト候補者が、何らかの手段で構成または発見されたスタンまたはターンサーバーとペアになります。スタンまたはターンサーバーが構成されている場合は、ドメイン名を構成することをお勧めします。[RFC5389]のDNS手順（「スタン」サービスを備えたSRVレコードを使用）を使用して、スタンサーバーとDNS手順を発見します。[RFC5766]では、「ターン」サービスでSRVレコードを使用）を使用して、ターンサーバーを発見します。
This specification only considers usage of a single STUN or TURN server. When there are multiple choices for that single STUN or TURN server (when, for example, they are learned through DNS records and multiple results are returned), an agent SHOULD use a single STUN or TURN server (based on its IP address) for all candidates for a particular session. This improves the performance of ICE. The result is a set of pairs of host candidates with STUN or TURN servers. The agent then chooses one pair, and sends a Binding or Allocate request to the server from that 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レコードを介して学習され、複数の結果が返される場合、エージェントはすべての人に対して単一のスタンまたはターンサーバー（IPアドレスに基づいて）を使用する必要があります特定のセッションの候補者。これにより、氷の性能が向上します。その結果、スタンまたはターンサーバーを備えたホスト候補のペアのセットが得られます。次に、エージェントは1つのペアを選択し、そのホスト候補からサーバーにバインディングまたは割り当てリクエストを送信します。スタンサーバーへのバインディングリクエストは認証されておらず、応答の代替サーバー属性は無視されます。エージェントは、[RFC5389]で定義されているバインディング要求の後方互換モードをサポートする必要があります。割り当てリクエストは、他の手段を通じてクライアントが取得した長期的な資格を使用して認証する必要があります。
Every Ta milliseconds thereafter, the agent can generate another new STUN or TURN transaction. This transaction can either be 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 one every Ta milliseconds. See Section 16 for guidance on how to set Ta and the STUN retransmit timer, RTO.
その後、TAミリ秒ごとに、エージェントは別の新しいスタンまたはターントランザクションを生成できます。このトランザクションは、回復可能なエラー（認証障害など）で失敗した以前のトランザクションの再試行、または新しいホスト候補者およびスタンまたはサーバーペアのトランザクションのいずれかです。エージェントは、すべてのTAミリ秒よりも頻繁にトランザクションを生成してはなりません。TAおよびSTUN再送信タイマーRTOを設定する方法については、セクション16を参照してください。
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.
エージェントは、拘束力のある応答または割り当てを受け取ります。割り当て応答が成功すると、エージェントにサーバー反射候補（マッピングアドレスから取得）とXORリレードアドレス属性の中継候補を提供します。サーバーがそれを満たすためのリソースがないために割り当て要求が拒否された場合、エージェントは代わりにサーバー反射候補を取得するために拘束力のあるリクエストを送信する必要があります。バインディング応答は、エージェントにサーバー反射候補のみを提供します（マッピングされたアドレスからも取得）。サーバー反射候補のベースは、割り当てまたは拘束力のある要求が送信されたホスト候補です。中継された候補者の基盤は、その候補者自体です。中継された候補者がホスト候補（まれな場合に発生する可能性がある）と同一である場合、中継された候補者を破棄する必要があります。
Finally, the agent assigns each candidate a foundation. The foundation is an identifier, scoped within a session. Two candidates MUST have the same foundation ID when all of the following are true:
最後に、エージェントは各候補者に基礎を割り当てます。基礎は識別子であり、セッション内でスコープされています。次のすべてが真実である場合、2人の候補者が同じ基礎IDを持っている必要があります。
o they are of 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.
o 再帰的および中継された候補の場合、それらを取得するために使用されるスタンまたはターンサーバーは同じIPアドレスを持っています。
o they were obtained using the same transport protocol (TCP, UDP, etc.).
o それらは、同じ輸送プロトコル（TCP、UDPなど）を使用して取得しました。
Similarly, two candidates MUST 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, or their transport protocols are different.
同様に、2つの候補者は、タイプが異なる場合、ベースのIPアドレスが異なる場合、取得に使用されるスタンまたはターンサーバーが異なるIPアドレスを持っている場合、またはトランスポートプロトコルが異なる場合、2つの候補者が異なる基礎を持っている必要があります。
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で説明されているように、サーバーの反射と中継の候補者が割り当てられたら、氷の処理が完了するまで生存する必要があります。拘束力のあるリクエストを通じて学んだサーバー反射候補の場合、ビンディングは、サーバーへの追加のバインディングリクエストによって生存する必要があります。[RFC5766]に記載されているように、割り当てのリフレッシュは更新トランザクションを使用して行われます。更新リクエストは、サーバー反射候補も更新されます。
The prioritization process results in the assignment of a priority to each candidate. Each candidate for a media 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.
優先順位付けプロセスにより、各候補者の優先順位が割り当てられます。メディアストリームの各候補には、1〜（2 ** 31-1）の間の正の整数でなければならない独自の優先事項が必要です。この優先順位は、氷によって使用されて、接続性チェックの順序と候補者の相対的な好みを決定します。
An agent SHOULD compute this priority using the formula in Section 4.1.2.1 and choose its parameters using the guidelines in Section 4.1.2.2. If an agent elects to use a different formula, ICE will take longer to converge since both agents will not be coordinated in their checks.
エージェントは、セクション4.1.2.1の式を使用してこの優先度を計算し、セクション4.1.2.2のガイドラインを使用してそのパラメーターを選択する必要があります。エージェントが別の式を使用することを選択した場合、両方のエージェントがチェックで調整されないため、ICEは収束に時間がかかります。
When using the formula, an agent computes the priority by determining a preference for each type of candidate (server reflexive, peer reflexive, relayed, and host), and, when the agent is multihomed, choosing a preference for its IP addresses. These two preferences are then combined to compute the priority for a candidate. That priority is computed using the following formula:
フォーミュラを使用する場合、エージェントは、各タイプの候補（サーバー反射、ピアリフレクティブ、リレー、ホスト）の選好を決定することにより優先順位を計算し、エージェントがマルチホームになったら、IPアドレスの優先権を選択します。次に、これらの2つの好みを組み合わせて、候補者の優先度を計算します。その優先度は、次の式を使用して計算されます。
priority = (2^24)*(type preference) +
(2^8)*(local preference) +
(2^0)*(256 - component ID)
The type preference MUST be an integer from 0 to 126 inclusive, and represents the preference for the type of the candidate (where the types are local, server reflexive, peer reflexive, and relayed). A 126 is the highest preference, and a 0 is the lowest. Setting the value to a 0 means that candidates of this type will only be used as a last resort. The type preference 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. Note that candidates gathered based on the procedures of Section 4.1.1 will never be peer reflexive candidates; candidates of these type are learned from the connectivity checks performed by ICE.
タイプの選好は、0〜126の整数である必要があり、候補者のタイプ（タイプがローカル、サーバー反射、ピア反射、中継）の優先度を表します。126は最高の好みであり、0は最低です。値を0に設定することは、このタイプの候補者が最後の手段としてのみ使用されることを意味します。タイプの選好は、同じタイプのすべての候補者と同一である必要があり、異なるタイプの候補で異なる必要があります。ピア反射候補のタイプの好みは、サーバー反射候補の候補よりも高い必要があります。セクション4.1.1の手順に基づいて集められた候補者は、ピア反射候補者になることは決してないことに注意してください。これらのタイプの候補者は、ICEによって実行される接続チェックから学習されます。
The local preference MUST be an integer from 0 to 65535 inclusive. It represents a preference for the particular IP address from which the candidate was obtained, in cases where an agent is multihomed. 65535 represents the highest preference, and a zero, the lowest. When there is only a single IP address, this value SHOULD be set to 65535. More generally, if there are multiple candidates for a particular component for a particular media stream that have the same type, the local preference MUST be unique for each one. In this specification, this only happens for multihomed hosts. If a host is multihomed because it is dual stack, the local preference SHOULD be set equal to the precedence value for IP addresses described in RFC 3484 [RFC3484].
ローカルの好みは、0〜65535の整数でなければなりません。これは、エージェントがマルチホームされている場合に、候補者が取得された特定のIPアドレスの好みを表します。65535は最高の好みを表し、ゼロは最低です。単一のIPアドレスのみがある場合、この値は65535に設定する必要があります。より一般的には、同じタイプの特定のメディアストリームの特定のコンポーネントの複数の候補がある場合、ローカルの好みはそれぞれに対して一意でなければなりません。この仕様では、これはマルチホームのホストでのみ発生します。ホストがデュアルスタックであるためにマルチホームされている場合、RFC 3484 [RFC3484]に記載されているIPアドレスの優先順位値にローカル設定を設定する必要があります。
The component ID is the component ID for the candidate, and MUST be between 1 and 256 inclusive.
コンポーネントIDは候補のコンポーネントIDであり、1〜256の包括的でなければなりません。
One criterion for selection of the type and local preference values is the use of a media intermediary, such as a TURN server, VPN server, or NAT. With a media intermediary, if media is sent to that candidate, it will first transit the media intermediary before being received. Relayed candidates are one type of candidate that involves a media intermediary. Another are host candidates obtained from a VPN interface. When media is transited through a media intermediary, it can increase the latency between transmission and reception. It can increase the packet losses, because of the additional router hops that may be taken. It may increase the cost of providing service, since media will be routed in and right back out of a media intermediary run by a provider. If these concerns are important, the type preference for relayed candidates SHOULD be lower than host candidates. The RECOMMENDED values are 126 for host candidates, 100 for server reflexive candidates, 110 for peer reflexive candidates, and 0 for relayed candidates. Furthermore, if an agent is multihomed and has multiple IP addresses, the local preference for host candidates from a VPN interface SHOULD have a priority of 0.
タイプとローカルの優先度値を選択するための1つの基準は、ターンサーバー、VPNサーバー、NATなどのメディア仲介者の使用です。メディアの仲介者を使用すると、メディアがその候補者に送信された場合、最初に受信する前にメディアの仲介者を通過します。中継された候補者は、メディアの仲介者を含む1つのタイプの候補です。もう1つは、VPNインターフェイスから取得したホスト候補です。メディアがメディアの仲介者を通じて通過すると、送信と受信の間の遅延が増加する可能性があります。撮影される可能性のある追加のルーターホップのために、パケットの損失を増やすことができます。メディアはプロバイダーが運営するメディアの仲介者から外れてルーティングされ、すぐに戻ってくるため、サービスを提供するコストが増加する可能性があります。これらの懸念が重要な場合、中継候補者のタイプの選好はホスト候補よりも低くなければなりません。推奨される値は、ホスト候補の場合は126、サーバー反射候補の場合は100、ピアリフレクション候補者は110、中継候補者は0です。さらに、エージェントがマルチホームで、複数のIPアドレスを持っている場合、VPNインターフェイスのホスト候補に対するローカル優先は0の優先度を持つ必要があります。
Another criterion for selection of preferences is IP address family. ICE works with both IPv4 and IPv6. It therefore 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 (due, for example, to a failure in a 6to4 relay) [RFC3056]. It can also help with hosts that have both a native IPv6 address and a 6to4 address. In such a case, higher local preferences could be assigned to the v6 addresses, followed by the 6to4 addresses, followed by the v4 addresses. This allows a site to obtain and begin using native v6 addresses immediately, yet still fall back to 6to4 addresses when communicating with agents in other sites that do not yet have native v6 connectivity.
選好の選択のもう1つの基準は、IPアドレスファミリです。ICEは、IPv4とIPv6の両方で動作します。したがって、デュアルスタックホストがIPv6よりも接続を好むことを可能にする遷移メカニズムを提供しますが、V6ネットワークが切断された場合に備えてIPv4に戻ります（たとえば、6to4リレーの障害による）[RFC3056]。また、ネイティブIPv6アドレスと6to4アドレスの両方を持つホストにも役立ちます。そのような場合、より高いローカル設定をV6アドレスに割り当てることができ、その後6to4アドレスが続き、その後にV4アドレスが続きます。これにより、サイトはネイティブV6アドレスをすぐに取得して使用し始めることができますが、まだネイティブV6接続がない他のサイトのエージェントと通信する場合、6to4アドレスに戻ります。
Another criterion for selecting preferences is security. 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 in order to keep it on the corporate network when communicating within the enterprise, but 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.
設定を選択するための別の基準はセキュリティです。ユーザーが在宅勤務者であり、したがってコーポレートネットワークとローカルホームネットワークに接続されている場合、ユーザーは、企業内で通信するときにコーポレートネットワーク上でそれを維持するために、VPNを介して音声トラフィックをルーティングすることを好むかもしれませんが、使用しますが、使用しますエンタープライズ以外のユーザーと通信するときのローカルネットワーク。そのような場合、VPNアドレスは、他のどのアドレスよりも局所選好が高くなります。
Another criterion for selecting preferences is topological awareness. This is most useful for candidates that make use of intermediaries. In those cases, if an 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つの基準は、トポロジカル認識です。これは、仲介者を利用する候補者にとって最も便利です。そのような場合、エージェントが仲介業者のトポロジカル近接性に関する知識を事前に構成または動的に発見した場合、それを使用して、より近い仲介者から得られた候補者に高いローカル設定を割り当てることができます。
Next, the agent eliminates redundant candidates. A candidate is redundant if its transport address equals another candidate, and its base equals the base of that other candidate. Note that two candidates can have the same transport address yet have 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. The agent SHOULD eliminate the redundant candidate with the lower priority.
次に、エージェントは冗長候補を排除します。輸送先住所が別の候補者に等しい場合、候補者は冗長であり、その基地はその他の候補者のベースに等しくなります。2人の候補者は同じ輸送住所を持つことができるが、異なるベースを持っている可能性があり、これらは冗長であるとは見なされないことに注意してください。多くの場合、エージェントがNATの背後にいない場合、サーバーの反射候補とホスト候補は冗長になります。エージェントは、優先度が低い冗長候補を排除する必要があります。
A candidate is said to be default if it would be the target of media from a non-ICE peer; that target is called the DEFAULT DESTINATION. If the default candidates are not selected by the ICE algorithm when communicating with an ICE-aware peer, an updated offer/answer will be required after ICE processing completes in order to "fix up" the SDP so that the default destination for media matches the candidates selected by ICE. If ICE happens to select the default candidates, no updated offer/answer is required.
候補者は、それが非氷のピアのメディアのターゲットになる場合、デフォルトであると言われています。そのターゲットはデフォルトの宛先と呼ばれます。アイスアウェアピアと通信するときにデフォルトの候補者がアイスアルゴリズムによって選択されていない場合、メディアのデフォルトの宛先が一致するようにSDPを「修正」するために、氷の処理が完了した後に更新されたオファー/回答が必要になります。氷で選択された候補者。ICEがデフォルトの候補者を選択している場合、更新されたオファー/回答は必要ありません。
An agent MUST choose a set of candidates, one for each component of each in-use media stream, to be default. A media stream is in-use if it does not have a port of zero (which is used in RFC 3264 to reject a media stream). Consequently, a media stream is in-use even if it is marked as a=inactive [RFC4566] or has a bandwidth value of zero.
エージェントは、デフォルトであるために、使用中の各メディアストリームの各コンポーネントに1つの候補のセットを選択する必要があります。メディアストリームには、ゼロのポートがない場合（RFC 3264でメディアストリームを拒否するために使用されています）。したがって、メディアストリームは、a = a = inactive [rfc4566]としてマークされている場合でも、帯域幅の値をゼロにしても使用します。
It is RECOMMENDED that default candidates be chosen based on the likelihood of those candidates to work with the peer that is being contacted. It is RECOMMENDED that the default candidates are the relayed candidates (if relayed candidates are available), server reflexive candidates (if server reflexive candidates are available), and finally host candidates.
デフォルトの候補者は、それらの候補者が連絡されているピアと協力する可能性に基づいて選択することをお勧めします。デフォルトの候補者は、中継候補（中継候補が利用可能な場合）、サーバー反射候補（サーバー反射候補が利用可能な場合）、および最終的にホスト候補であることをお勧めします。
Lite implementations only utilize host candidates. A lite implementation MUST, for each component of each media stream, allocate zero or one IPv4 candidates. It MAY allocate zero or more IPv6 candidates, but no more than one per each IPv6 address utilized by the host. Since there can be no more than one IPv4 candidate per component of each media stream, if an agent has multiple IPv4 addresses, it MUST choose one for allocating the candidate. If a host is dual stack, it is RECOMMENDED that it allocate one IPv4 candidate and one global IPv6 address. With the lite implementation, ICE cannot be used to dynamically choose amongst candidates. Therefore, including more than one candidate from a particular scope is NOT RECOMMENDED, since only a connectivity check can truly determine whether to use one address or the other.
Lite実装は、ホスト候補のみを利用します。Liteの実装は、各メディアストリームの各コンポーネントに対して、ゼロまたは1つのIPv4候補を割り当てる必要があります。ゼロ以上のIPv6候補を割り当てる場合がありますが、ホストが使用する各IPv6アドレスごとに1つ以下です。各メディアストリームのコンポーネントごとに1つのIPv4候補が存在する可能性があるため、エージェントが複数のIPv4アドレスを持っている場合、候補を割り当てるために1つを選択する必要があります。ホストがデュアルスタックの場合、1つのIPv4候補と1つのグローバルIPv6アドレスを割り当てることをお勧めします。Liteの実装では、ICEを使用して候補者の間で動的に選択することはできません。したがって、特定の範囲から複数の候補者を含めることは推奨されません。これは、接続チェックのみが1つのアドレスを使用するか別のアドレスを使用するかを真に決定できるためです。
Each component has an ID assigned to it, called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP, it MUST obtain candidates for it.
各コンポーネントには、コンポーネントIDと呼ばれるIDが割り当てられています。RTPベースのメディアストリームの場合、RTP自体には1のコンポーネントIDがあり、RTCPは2のコンポーネントIDを持ちます。エージェントがRTCPを使用している場合、候補者を取得する必要があります。
Each candidate is assigned a foundation. The foundation MUST be different for two candidates allocated from different IP addresses, and MUST be the same otherwise. 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 media stream. This priority SHOULD be equal to:
各候補者には基礎が割り当てられます。財団は、異なるIPアドレスから割り当てられた2人の候補者の場合、異なる必要があり、そうでなければ同じでなければなりません。各IPアドレスの増分を追加する単純な整数で十分です。さらに、各候補者には、同じメディアストリームのすべての候補者の中に独自の優先事項を割り当てる必要があります。この優先順位は次のとおりです。
priority = (2^24)*(126) +
(2^8)*(IP precedence) +
(2^0)*(256 - component ID)
If a host is v4-only, it SHOULD set the IP precedence to 65535. If a host is v6 or dual stack, the IP precedence SHOULD be the precedence value for IP addresses described in RFC 3484 [RFC3484].
ホストがV4のみである場合、IPの優先順位を65535に設定する必要があります。ホストがV6またはデュアルスタックの場合、IPの優先順位は、RFC 3484 [RFC3484]で説明されているIPアドレスの優先値である必要があります。
Next, an agent chooses a default candidate for each component of each media stream. If a host is IPv4 only, there would only be one candidate for each component of each media stream, and therefore that candidate is the default. If a host is IPv6 or dual stack, the selection of default is a matter of local policy. This default SHOULD be chosen such that it is the candidate most likely to be used with a peer. For IPv6-only hosts, this would typically be a globally scoped IPv6 address. For dual-stack hosts, the IPv4 address is RECOMMENDED.
次に、エージェントが各メディアストリームの各コンポーネントのデフォルト候補を選択します。ホストがIPv4のみである場合、各メディアストリームの各コンポーネントに1つの候補者のみが存在するため、その候補者はデフォルトです。ホストがIPv6またはデュアルスタックの場合、デフォルトの選択はローカルポリシーの問題です。このデフォルトは、ピアで使用される可能性が最も高い候補であるように選択する必要があります。IPv6のみのホストの場合、これは通常、グローバルにスコープされたIPv6アドレスになります。デュアルスタックホストの場合、IPv4アドレスをお勧めします。
The process of encoding the SDP is identical between full and lite implementations.
SDPをエンコードするプロセスは、完全な実装とライトの実装との間で同じです。
The agent will include an m line for each media stream it wishes to use. The ordering of media streams in the SDP is relevant for ICE. ICE will perform its connectivity checks for the first m line first, and consequently media will be able to flow for that stream first. Agents SHOULD place their most important media stream, if there is one, first in the SDP.
エージェントには、使用したいメディアストリームごとにMラインが含まれます。SDPでのメディアストリームの順序は、氷に関連しています。ICEは最初に最初のMラインで接続性チェックを実行し、その結果、メディアは最初にそのストリームに流れることができます。エージェントは、最初にSDPで最も重要なメディアストリームがある場合は、最も重要なメディアストリームを配置する必要があります。
There will be a candidate attribute for each candidate for a particular media stream. Section 15 provides detailed rules for constructing this attribute. The attribute carries the IP address, port, and transport protocol for the candidate, in addition to its properties that need to be signaled to the peer for ICE to work: the priority, foundation, and component ID. The candidate attribute also carries information about the candidate that is useful for diagnostics and other functions: its type and related transport addresses.
特定のメディアストリームの各候補者に候補属性があります。セクション15では、この属性を構築するための詳細なルールを提供します。属性には、候補者のIPアドレス、ポート、および輸送プロトコルが搭載されていますが、そのプロパティは、優先度、ファンデーション、コンポーネントIDで機能するためにピアに合図する必要があります。候補属性は、診断やその他の機能に役立つ候補に関する情報も伝えています：そのタイプと関連する輸送アドレス。
STUN connectivity checks between agents are authenticated using the short-term credential mechanism defined for STUN [RFC5389]. This mechanism relies on a username and password that are exchanged through protocol machinery between the client and server. With ICE, the offer/answer exchange is used to exchange them. The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon. Each agent also provides a password, used to compute the message integrity for requests it receives. The username fragment and password are exchanged in the ice-ufrag and ice-pwd attributes, respectively. In addition to providing security, the username provides disambiguation and correlation of checks to media streams. See Appendix B.4 for motivation.
エージェント間のスタン接続チェックは、Stun [RFC5389]に対して定義された短期の資格情報メカニズムを使用して認証されます。このメカニズムは、クライアントとサーバー間のプロトコル機械を介して交換されるユーザー名とパスワードに依存しています。ICEを使用すると、オファー/回答の交換を使用してそれらを交換します。この資格情報のユーザー名部分は、各エージェントからのユーザー名フラグメントを連結して、コロンで区切ることによって形成されます。また、各エージェントは、受信するリクエストのメッセージの整合性を計算するために使用されるパスワードを提供します。ユーザー名のフラグメントとパスワードは、それぞれICE-UFRAGおよびICE-PWD属性で交換されます。セキュリティの提供に加えて、ユーザー名は、メディアストリームに対するチェックの曖昧性の低下と相関を提供します。動機については、付録B.4を参照してください。
If an agent is a lite implementation, it MUST include an "a=ice-lite" session-level attribute in its SDP. If an agent is a full implementation, it MUST NOT include this attribute.
エージェントがLite実装の場合、SDPに「A = Ice-Lite」セッションレベルの属性を含める必要があります。エージェントが完全な実装である場合、この属性を含めてはなりません。
The default candidates are added to the SDP as the default destination for media. For streams based on RTP, this is done by placing the IP address and port of the RTP candidate into the c and m lines, respectively. If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 [RFC3605]. If RTCP is not in use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556].
デフォルトの候補者は、メディアのデフォルトの宛先としてSDPに追加されます。RTPに基づくストリームの場合、これはそれぞれRTP候補のIPアドレスとポートをCラインとMラインに配置することによって行われます。エージェントがRTCPを使用している場合、RFC 3605 [RFC3605]で定義されているA = RTCP属性を使用してRTCP候補をエンコードする必要があります。RTCPが使用されていない場合、エージェントは、RFC 3556 [RFC3556]で定義されているように、b = rs：0およびb = rr：0を使用することを信号する必要があります。
The transport addresses that will be the default destination for media when communicating with non-ICE peers MUST also be present as candidates in one or more a=candidate lines.
氷のないピアと通信する際のメディアのデフォルトの宛先となる輸送アドレスは、1つ以上のa =候補ラインの候補として存在する必要があります。
ICE provides for extensibility by allowing an offer or answer to contain a series of tokens that identify the ICE extensions used by that agent. If an agent supports an ICE extension, it MUST include the token defined for that extension in the ice-options attribute.
ICEは、そのエージェントが使用するアイス拡張を識別する一連のトークンをオファーまたは回答に含めることにより、拡張性を提供します。エージェントが氷の延長をサポートする場合、ICE-Options属性にその延長に定義されたトークンを含める必要があります。
The following is an example SDP message that includes ICE attributes (lines folded for readability):
以下は、ICE属性（読みやすさのために折り畳まれた行）を含むSDPメッセージの例です。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
Once an agent has sent its offer or its answer, that agent MUST be prepared to receive both STUN and media packets on each candidate. As discussed in Section 11.1, media packets can be sent to a candidate prior to its appearance as the default destination for media in an offer or answer.
エージェントがオファーまたはその回答を送信したら、そのエージェントは各候補者のスタンパケットとメディアパケットの両方を受け取る準備をしなければなりません。セクション11.1で説明したように、メディアパケットは、オファーまたは回答のメディアのデフォルトの目的地として登場する前に候補者に送信できます。
When an agent receives an initial offer, it will check if the offerer supports ICE, determine its own role, gather candidates, prioritize them, choose default candidates, encode and send an answer, and for full implementations, form the check lists and begin connectivity checks.
エージェントが最初のオファーを受け取ったとき、オファーがアイスをサポートし、独自の役割を決定し、候補者を収集し、デフォルト候補を選択し、回答をエンコードして送信し、完全な実装のためにチェックリストを形成し、接続を開始するかどうかを確認します。チェック。
The agent will proceed with the ICE procedures defined in this specification if, for each media stream in the SDP it received, the default destination for each component of that media stream appears in a candidate attribute. For example, in the case of RTP, the IP address and port in the c and m lines, respectively, appear in a candidate attribute and the value in the rtcp attribute appears in a candidate attribute.
エージェントは、受信したSDPの各メディアストリームについて、そのメディアストリームの各コンポーネントのデフォルトの宛先が候補属性に表示される場合、この仕様で定義された氷の手順を進めます。たとえば、RTPの場合、CラインとMラインのIPアドレスとポートはそれぞれ候補属性に表示され、RTCP属性の値は候補属性に表示されます。
If this condition is not met, the agent MUST process the SDP based on normal RFC 3264 procedures, without using any of the ICE mechanisms described in the remainder of this specification with the following exceptions:
この状態が満たされていない場合、エージェントは、次の例外を除いて、この仕様の残りの部分で説明されている氷のメカニズムを使用せずに、通常のRFC 3264手順に基づいてSDPを処理する必要があります。
1. The agent MUST follow the rules of Section 10, which describe keepalive procedures for all agents.
1. エージェントは、すべてのエージェントのキープライブ手順を説明するセクション10の規則に従う必要があります。
2. If the agent is not proceeding with ICE because there were a=candidate attributes, but none that matched the default destination of the media stream, the agent MUST include an a=ice-mismatch attribute in its answer.
2. A =候補の属性があるためにエージェントがICEを進めていないが、メディアストリームのデフォルトの宛先と一致するものはない場合、エージェントはその回答にa = ice-mismatch属性を含める必要があります。
3. If the default candidates were relayed candidates learned through a TURN server, the agent MUST create permissions in the TURN server for the IP addresses learned from its peer in the SDP it just received. If this is not done, initial packets in the media stream from the peer may be lost.
3. デフォルトの候補者がターンサーバーを介して学習した候補者を中継した場合、エージェントは、受け取ったばかりのSDPのピアから学習したIPアドレスに対してターンサーバーにアクセス許可を作成する必要があります。これが行われない場合、ピアからのメディアストリーム内の初期パケットが失われる可能性があります。
For each session, each agent 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. For a full agent, this means nominating the candidate pairs that can be used by ICE for each media stream, and for generating the updated offer based on ICE's selection, when needed. For a lite implementation, being the controlling agent means selecting a candidate pair based on the ones in the offer and answer (for IPv4, there is only ever one pair), and then generating an updated offer reflecting that selection, when needed (it is never needed for an IPv4-only host). The controlled agent is told which candidate pairs to use for each media stream, and does not generate an updated offer to signal this information. The sections below describe in detail the actual procedures followed by controlling and controlled nodes.
各セッションで、各エージェントが役割を引き受けます。制御と制御の2つの役割があります。制御エージェントは、通信に使用される最終候補ペアの選択に責任があります。完全なエージェントの場合、これは、各メディアストリームでICEで使用できる候補のペアを指名し、必要に応じてICEの選択に基づいて更新されたオファーを生成するために意味します。Liteの実装の場合、制御エージェントであることは、オファーと回答の候補ペアを選択することを意味します（IPv4の場合、1つのペアしかありません）。IPv4のみのホストには必要ありません）。制御されたエージェントは、各メディアストリームに使用する候補ペアが通知され、この情報を通知するための更新されたオファーは生成されません。以下のセクションでは、実際の手順と制御ノードと制御されたノードが続くことを詳細に説明します。
The rules for determining the role and the impact on behavior are as follows:
役割と行動への影響を決定するためのルールは次のとおりです。
Both agents are full: The agent that generated the offer which started the ICE processing MUST take the controlling role, and the other MUST take the controlled role. Both agents will form check lists, 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 be selected by ICE, and then both agents end ICE as described in Section 8.1.2. In unusual cases, described in Appendix B.11, it is possible for both agents to mistakenly believe they are controlled or controlling. To resolve this, each agent MUST select a random number, called the tie-breaker, uniformly distributed between 0 and (2**64) - 1 (that is, a 64-bit positive integer). This number is used in connectivity checks to detect and repair this case, as described in Section 7.1.2.2.
どちらのエージェントもいっぱいです。氷の処理を開始したオファーを生成したエージェントは、制御の役割を担う必要があり、もう1つは制御された役割を担う必要があります。どちらのエージェントもチェックリストを形成し、アイスステートマシンを実行し、接続性チェックを生成します。制御エージェントは、セクション8.1のロジックを実行して、氷で選択されるペアを指名し、セクション8.1.2で説明したように両方のエージェントが氷を終了します。付録B.11に記載されている異常な場合、両方のエージェントが誤って制御または制御されていると誤って信じることができます。これを解決するには、各エージェントは、0〜（2 ** 64）-1（つまり、64ビットの正の整数）の間に均一に分布するタイブレーカーと呼ばれる乱数を選択する必要があります。この数字は、セクション7.1.2.2で説明されているように、このケースを検出および修復するために接続チェックで使用されます。
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 check lists, run the ICE state machines, and generate connectivity checks. That agent will execute the logic in Section 8.1 to nominate pairs that will be selected by ICE, 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 media stream is considered to be Running, and the state of ICE overall is Running.
1人のエージェントがいっぱい、1人のライト：完全なエージェントが制御する役割を担う必要があり、Liteエージェントは制御された役割を取る必要があります。完全なエージェントは、チェックリストを形成し、アイスステートマシンを実行し、接続チェックを生成します。そのエージェントは、セクション8.1のロジックを実行して、氷で選択されるペアを指名し、セクション8.1.2のロジックを使用して氷を終了します。Liteの実装では、接続チェックを聞き、それらを受け取り、応答し、セクション8.2で説明されているようにICEを締めくくります。Liteの実装では、各メディアストリームの氷加工の状態が実行されていると見なされ、氷の状態全体が実行されています。
Both lite: The agent that generated the offer which 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 offer/answer exchange completes, 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 carrying the offer/answer exchange. The state of ICE processing for each media stream is considered to be Running, and the state of ICE overall is Running.
両方のLite：氷加工を開始したオファーを生成したエージェントは、制御の役割を担う必要があり、もう1つは制御された役割を担う必要があります。この場合、接続チェックは送信されません。むしろ、オファー/回答の交換が完了すると、各エージェントは、接続チェックなしでセクション8で説明されている処理を実行します。両方のエージェントが、彼らが制御または制御されていると信じる可能性があります。後者の場合、競合は、オファー/回答の交換を運ぶシグナリングプロトコルのグレア検出機能を通じて解決されます。各メディアストリームの氷加工の状態は実行されていると見なされ、氷の状態全体が実行されています。
Once roles are determined for a session, they persist unless ICE is restarted. An ICE restart (Section 9.1) causes a new selection of roles and tie-breakers.
セッションの役割が決定されると、氷が再起動されない限り、それらは持続します。アイス再起動（セクション9.1）は、ロールとタイブレーカーの新しい選択を引き起こします。
The process for gathering candidates at the answerer is identical to the process for the offerer as described in Section 4.1.1 for full implementations and Section 4.2 for lite implementations. It is RECOMMENDED that this process begin immediately on receipt of the offer, prior to alerting the user. Such gathering MAY begin when an agent starts.
Answererで候補者を収集するプロセスは、完全な実装についてはセクション4.1.1、Lite実装のセクション4.2で説明されているように、提供者のプロセスと同一です。このプロセスは、ユーザーに警告する前に、オファーの受信時にすぐに開始することをお勧めします。そのような収集は、エージェントが開始されると開始される場合があります。
The process for prioritizing candidates at the answerer is identical to the process followed by the offerer, as described in Section 4.1.2 for full implementations and Section 4.2 for lite implementations.
Answererで候補者に優先順位を付けるプロセスは、完全な実装についてはセクション4.1.2、Lite実装のセクション4.2で説明されているように、提供者がそれに続くプロセスと同一です。
The process for selecting default candidates at the answerer is identical to the process followed by the offerer, as described in Section 4.1.4 for full implementations and Section 4.2 for lite implementations.
回答者でデフォルトの候補を選択するプロセスは、完全な実装についてはセクション4.1.4、ライト実装のセクション4.2で説明されているように、プロセスとその後のプロセスと同一です。
The process for encoding the SDP at the answerer is identical to the process followed by the offerer for both full and lite implementations, as described in Section 4.3.
回答者でSDPをエンコードするプロセスは、セクション4.3で説明されているように、完全な実装とライトの両方の実装のために提供者がそれに続くプロセスと同一です。
Forming check lists is done only by full implementations. Lite implementations MUST skip the steps defined in this section.
チェックリストの形成は、完全な実装によってのみ行われます。Liteの実装は、このセクションで定義されている手順をスキップする必要があります。
There is one check list per in-use media stream resulting from the offer/answer exchange. To form the check list for a media stream, the agent forms candidate pairs, computes a candidate pair priority, orders the pairs by priority, prunes them, and sets their states. These steps are described in this section.
オファー/回答の交換に起因する使用中のメディアストリームごとに1つのチェックリストがあります。メディアストリームのチェックリストを形成するために、エージェントは候補のペアを形成し、候補ペアの優先順位を計算し、優先順位でペアを注文し、それらをプルーネし、状態を設定します。これらの手順については、このセクションで説明します。
First, the agent takes each of its candidates for a media stream (called LOCAL CANDIDATES) and pairs them with the candidates it received from its peer (called REMOTE CANDIDATES) for that media stream. In order to prevent the attacks described in Section 18.5.2, agents MAY limit the number of candidates they'll accept in an offer or answer. A local candidate is paired with a remote candidate if and only if the two candidates have the same component ID and have the same IP address version. 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 the all of the components for a media stream. If this happens, the number of components for that media stream is effectively reduced, and considered to be equal to the minimum across both agents of the maximum component ID provided by each agent across all components for the media stream.
まず、エージェントは各候補者をメディアストリーム（ローカル候補者と呼ばれる）に採用し、そのメディアストリームのピア（リモート候補と呼ばれる）から受け取った候補者と組み合わせます。セクション18.5.2に記載されている攻撃を防ぐために、エージェントは申し出または回答で受け入れる候補者の数を制限する場合があります。2人の候補者が同じコンポーネントIDを持ち、同じ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 offerer can multiplex RTP and RTCP on the same port and signals that it can do that in the SDP through an SDP attribute [RFC5761]. However, since the offerer doesn't know if the answerer can perform such multiplexing, the offerer includes candidates for RTP and RTCP on separate ports, so that the offer has two components per media stream. If the answerer 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の候補を提供する場合に発生し、もう1つのエージェントはそうではありません。別の例として、オファーは同じポートでRTPとRTCPをマルチプレックスでき、SDP属性[RFC5761]を介してSDPでそれを行うことができるという信号を送ることができます。ただし、オファーは、応答者がそのような多重化を実行できるかどうかを知らないため、オファーには別々のポートにRTPとRTCPの候補者が含まれているため、オファーにはメディアストリームごとに2つのコンポーネントがあります。回答者がそのような多重化を実行できる場合、候補者ごとに単一のコンポーネントのみが含まれます。ICEは、この候補者に単一のコンポーネントだけがあるかのように振る舞うことになります。
The candidate pairs whose local and remote candidates are both the default candidates for a particular component is called, unsurprisingly, the default candidate pair for that component. This is the pair that would be used to transmit media if both agents had not been ICE aware.
ローカルおよびリモートの候補者が両方とも特定のコンポーネントのデフォルト候補である候補ペアは、当然のことながら、そのコンポーネントのデフォルト候補ペアと呼ばれます。これは、両方のエージェントがICEを認識していなかった場合、メディアを送信するために使用されるペアです。
In order to aid understanding, Figure 6 shows the relationships between several key concepts -- transport addresses, candidates, candidate pairs, and check lists, in addition to indicating the main properties of candidates and candidate pairs.
理解を支援するために、図6は、候補者と候補ペアの主な特性を示すことに加えて、輸送アドレス、候補者、候補ペア、チェックリストなど、いくつかの重要な概念間の関係を示しています。
+------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +ComponentiD |
| | Transport | +RelatedAddr |
| | Addr | |
| +---------------------+ +Base |
| Candidate |
+------------------------------------------+
* *
* *************************************
* *
+-------------------------------+
.| |
| Local Remote |
| +----+ +----+ +default? |
| |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?|
| +State |
| |
| |
| Candidate Pair |
+-------------------------------+
* *
* ************
* *
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
Check List
リストを確認してください
Figure 6: Conceptual Diagram of a Check List
図6：チェックリストの概念図
Once the pairs are formed, a candidate pair priority is computed. 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:
ペアが形成されると、候補ペアの優先順位が計算されます。gを、制御エージェントが提供する候補の優先事項とします。制御されたエージェントが提供する候補の優先順位をDとします。ペアの優先度は次のように計算されます。
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G>D?1:0 is an expression whose value is 1 if G is greater than D, and 0 otherwise. Once the priority is assigned, the agent sorts the candidate pairs in decreasing order of priority. If two pairs have identical priority, the ordering amongst them is arbitrary.
ここで、g> d？1：0は、gがdより大きい場合、値が1である式、それ以外の場合は0です。優先度が割り当てられると、エージェントは優先度の低下順に候補ペアをソートします。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 agent cannot send requests directly from a reflexive candidate, but only from its base, the agent next goes through the sorted list of candidate pairs. For each pair where the local candidate is server reflexive, the server reflexive candidate MUST be replaced by its base. Once this has been done, the agent MUST prune the list. This is done by removing a pair if its local and remote candidates are identical to the local and remote candidates of a pair higher up on the priority list. The result is a sequence of ordered candidate pairs, called the check list for that media stream.
候補ペアのこのソートされたリストは、実行される一連の接続チェックを決定するために使用されます。各チェックには、地元の候補者からリモート候補者にリクエストを送信することが含まれます。エージェントは反射候補からリクエストを直接送信できないため、その基地からのみ、エージェントは候補ペアのソートされたリストを通過します。ローカル候補がサーバーの反射である各ペアについて、サーバー反射候補はそのベースに置き換える必要があります。これが完了したら、エージェントはリストを剪定する必要があります。これは、そのローカルおよびリモート候補が優先順位リストの上位にあるペアのローカルおよびリモート候補と同一である場合、ペアを削除することによって行われます。その結果、そのメディアストリームのチェックリストと呼ばれる一連の順序付けられた候補ペアがあります。
In addition, in order to limit the attacks described in Section 18.5.2, an agent MUST limit the total number of connectivity checks the agent performs across all check lists to a specific value, and this value MUST be configurable. A default of 100 is RECOMMENDED. This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100. It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen 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.
さらに、セクション18.5.2に記載されている攻撃を制限するために、エージェントはすべてのチェックリストで実行されるエージェントが実行される接続チェックの総数を特定の値に制限する必要があり、この値は設定可能でなければなりません。デフォルトの100が推奨されます。この制限は、100未満になるまで低優先候補の候補ペアを破棄することにより強制されます。可能な場合は、実際の展開構成で見られる可能性のある最大数の妥当なチェックに設定することをお勧めします。構成の要件は、展開したら問題があることが判明した場合、フィールドでこの値を修正するためのツールを提供することを目的としています。
Each candidate pair in the check list has a foundation and a state. The foundation is the combination of the foundations of the local and remote candidates in the pair. The state is assigned once the check list for each media stream has been computed. There are five potential values that the state can have: Waiting: A check has not been performed for this pair, and can be performed as soon as it is the highest-priority Waiting pair on the check list.
チェックリストの各候補ペアには、基盤と状態があります。基礎は、ペアの地元と遠隔の候補者の基礎の組み合わせです。各メディアストリームのチェックリストが計算されると、状態は割り当てられます。状態が持つことができる5つの潜在的な値があります。待機：このペアの小切手は実行されておらず、チェックリストで最高程度の優先順位の待機ペアになるとすぐに実行できます。
In-Progress: A check has been sent for this pair, but the transaction is in progress.
PROGRESS：このペアのチェックが送信されましたが、トランザクションが進行中です。
Succeeded: A check for this pair was already done and produced a successful result.
成功：このペアのチェックはすでに完了しており、成功した結果を生み出しました。
Failed: A check for this pair was already done and failed, either never producing any response or producing an unrecoverable failure response.
失敗：このペアのチェックはすでに行われており、失敗しましたが、応答を生成することも、回復不可能な障害応答を生成しませんでした。
Frozen: A check for this pair hasn't been performed, and it can't yet be performed until some other check succeeds, allowing this pair to unfreeze and move into the Waiting state.
Frozen：このペアの小切手は実行されておらず、他のチェックが成功するまでまだ実行できず、このペアが凍結して待機状態に移動することができます。
As ICE runs, the pairs will move between states as shown in Figure 7.
氷が走ると、図7に示すように、ペアは状態間を移動します。
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
|unfreeze
|
V
+-----------+ +-----------+
| | | |
| | perform | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
failure // |success
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+
Figure 7: Pair State FSM
図7：ペア状態FSM
The initial states for each pair in a check list are computed by performing the following sequence of steps:
チェックリストの各ペアの初期状態は、次の一連のステップを実行することにより計算されます。
1. The agent sets all of the pairs in each check list to the Frozen state.
1. エージェントは、各チェックリストのすべてのペアを凍結状態に設定します。
2. The agent examines the check list for the first media stream (a media stream is the first media stream when it is described by the first m line in the SDP offer and answer). For that media stream:
2. エージェントは、最初のメディアストリームのチェックリストを調べます（メディアストリームは、SDPオファーと回答の最初のM行で説明されている場合の最初のメディアストリームです）。そのメディアストリームの場合：
* For all pairs with the same foundation, it sets the state of the pair with the lowest component ID to Waiting. If there is more than one such pair, the one with the highest priority is used.
* 同じ基盤を持つすべてのペアについて、最低コンポーネントIDを持つペアの状態を待っています。そのようなペアが複数ある場合、最優先度の高いペアが使用されます。
One of the check lists will have some number of pairs in the Waiting state, and the other check lists will have all of their pairs in the Frozen state. A check list with at least one pair that is Waiting is called an active check list, and a check list with all pairs Frozen is called a frozen check list.
チェックリストの1つには、待機状態にいくつかのペアがあり、もう1つのチェックリストには凍結状態のすべてのペアがあります。待機中の少なくとも1つのペアを含むチェックリストはアクティブチェックリストと呼ばれ、すべてのペアが冷凍されたチェックリストは冷凍チェックリストと呼ばれます。
The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are three states:
チェックリスト自体は状態に関連付けられており、そのメディアストリームの氷のチェックの状態をキャプチャします。3つの状態があります。
Running: In this state, ICE checks are still in progress for this media stream.
ランニング：この状態では、このメディアストリームでは氷のチェックがまだ進行中です。
Completed: In this state, ICE checks have produced nominated pairs for each component of the media stream. Consequently, ICE has succeeded and media can be sent.
完了：この状態では、ICEチェックはメディアストリームの各コンポーネントに指名されたペアを作成しました。その結果、ICEが成功し、メディアを送信できます。
Failed: In this state, the ICE checks have not completed successfully for this media stream.
失敗：この状態では、このメディアストリームの氷のチェックは正常に完了していません。
When a check list is first constructed as the consequence of an offer/answer exchange, it is placed in the Running state.
チェックリストが最初にオファー/回答の交換の結果として構築されると、実行状態に配置されます。
ICE processing across all media streams also has a state associated with it. This state is equal to Running while ICE processing is under way. The state is Completed when ICE processing is complete and Failed if it failed without success. Rules for transitioning between states are described below.
すべてのメディアストリームにわたる氷加工には、それに関連する状態もあります。この状態は、氷の加工が進行中のときに実行されることに等しくなります。状態は、氷の加工が完了すると完了し、成功せずに失敗した場合に失敗します。州間の移行の規則については、以下に説明します。
Checks are generated only by full implementations. Lite implementations MUST skip the steps described in this section.
チェックは、完全な実装によってのみ生成されます。Liteの実装は、このセクションで説明する手順をスキップする必要があります。
An agent performs ordinary checks and triggered checks. The generation of both checks is governed by a timer that fires periodically for each media stream. The agent maintains a FIFO queue, called the triggered check queue, which contains candidate pairs for which checks are to be sent at the next available opportunity. When the timer fires, the agent removes the top pair from the triggered check queue, performs a connectivity check on that pair, and sets the state of the candidate pair to In-Progress. If there are no pairs in the triggered check queue, an ordinary check is sent.
エージェントは通常のチェックとトリガーチェックを実行します。両方のチェックの生成は、各メディアストリームに定期的に発射するタイマーによって支配されます。エージェントは、トリガーされたチェックキューと呼ばれるFIFOキューを維持します。これには、次の利用可能な機会に小切手が送信される候補ペアが含まれています。タイマーが発火すると、エージェントはトリガーされたチェックキューからトップペアを削除し、そのペアで接続チェックを実行し、候補ペアの状態を進行に設定します。トリガーされたチェックキューにペアがない場合、通常のチェックが送信されます。
Once the agent has computed the check lists as described in Section 5.7, it sets a timer for each active check list. The timer fires every Ta*N seconds, where N is the number of active check lists (initially, there is only one active check list). Implementations MAY set the timer to fire less frequently than this. Implementations SHOULD take care to spread out these timers so that they do not fire at the same time for each media stream. Ta and the retransmit timer RTO are computed as described in Section 16. Multiplying by N allows this aggregate check throughput to be split between all active check lists. The first timer fires immediately, so that the agent performs a connectivity check the moment the offer/answer exchange has been done, followed by the next check Ta seconds later (since there is only one active check list).
セクション5.7で説明されているように、エージェントがチェックリストを計算すると、各アクティブチェックリストのタイマーを設定します。タイマーはすべてのta*n秒を発射します。ここで、nはアクティブチェックリストの数です（最初は、アクティブチェックリストは1つだけです）。実装により、タイマーがこれよりも頻繁に発射されるように設定される場合があります。実装は、これらのタイマーが各メディアストリームに対して同時に発砲しないように、これらのタイマーを広げるように注意する必要があります。TAおよび再送信タイマーRTOは、セクション16で説明されているように計算されます。Nを掛けることで、この集約チェックスループットをすべてのアクティブなチェックリスト間で分割できます。最初のタイマーはすぐに発射されるため、エージェントがオファー/回答の交換が行われた瞬間に接続チェックを実行し、その後数秒後に次のチェックTAが続きます（アクティブなチェックリストが1つしかないため）。
When the timer fires and there is no triggered check to be sent, the agent MUST choose an ordinary check as follows:
タイマーが発射され、送信されるトリガーチェックがない場合、エージェントは次のように通常のチェックを選択する必要があります。
o Find the highest-priority pair in that check list that is in the Waiting state.
o 待機状態にあるそのチェックリストで最高の優先順位ペアを見つけます。
o If there is such a pair:
o そのようなペアがある場合：
* Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the STUN request for this purpose are described in Section 7.1.2.
* そのペアのローカル候補からスタンチェックを送信して、そのペアのリモート候補に送信します。この目的のためのスタン要求を形成する手順は、セクション7.1.2で説明されています。
* Set the state of the candidate pair to In-Progress.
* 候補ペアの状態を進みに設定します。
o If there is no such pair:
o そのようなペアがない場合：
* Find the highest-priority pair in that check list that is in the Frozen state.
* 凍結状態にあるチェックリストで最高優先度のペアを見つけます。
* If there is such a pair:
* そのようなペアがある場合：
+ Unfreeze the pair.
+ ペアを解凍します。
+ Perform a check for that pair, causing its state to transition to In-Progress.
+ そのペアのチェックを実行し、その状態が進行中に移行します。
* If there is no such pair:
* そのようなペアがない場合：
+ Terminate the timer for that check list.
+ そのチェックリストのタイマーを終了します。
To compute the message integrity for the check, the agent uses the remote username fragment and password learned from the SDP from its peer. The local username fragment is known directly by the agent for its own candidate.
チェックのメッセージの整合性を計算するために、エージェントはリモートユーザー名フラグメントとSDPから学習したパスワードをピアから使用します。ローカルユーザー名フラグメントは、独自の候補者のためにエージェントによって直接知られています。
This section describes the procedures that an agent follows when it receives the answer from the peer. It verifies that its peer supports ICE, determines its role, and for full implementations, forms the check list and begins performing ordinary checks.
このセクションでは、エージェントがピアから答えを受け取ったときに従う手順について説明します。ピアがICEをサポートし、その役割を決定し、完全な実装のためにチェックリストを形成し、通常のチェックの実行を開始することを確認します。
When ICE is used with SIP, forking may result in a single offer generating a multiplicity of answers. In that case, ICE proceeds completely in parallel and independently for each answer, treating the combination of its offer and each answer as an independent offer/ answer exchange, with its own set of pairs, check lists, states, and so on. The only case in which processing of one pair impacts another is freeing of candidates, discussed below in Section 8.3.
氷がSIPで使用されると、フォーキングにより、多数の回答が生成される単一のオファーが発生する可能性があります。その場合、氷は各回答に対して完全に並行して独立して進行し、その申し出と各回答の組み合わせを独自のペア、チェックリスト、状態などのセットとともに独立したオファー/回答交換として扱います。あるペアの処理が別のペアに影響を与える唯一のケースは、セクション8.3で以下で説明する候補者の解放です。
The logic at the offerer is identical to that of the answerer as described in Section 5.1, with the exception that an offerer would not ever generate a=ice-mismatch attributes in an SDP.
オファーのロジックは、セクション5.1で説明されているように、応募者がSDPでa = ice-mismatch属性を生成しないことを除いて、回答者のロジックと同一です。
In some cases, the answer may omit a=candidate attributes for the media streams, and instead include an a=ice-mismatch attribute for one or more of the media streams in the SDP. This signals to the offerer that the answerer supports ICE, but that ICE processing was not used for the session because a signaling intermediary modified the default destination for media components without modifying the corresponding candidate attributes. See Section 18 for a discussion of cases where this can happen. This specification provides no guidance on how an agent should proceed in such a failure case.
場合によっては、回答はA =メディアストリームの候補属性を省略し、代わりにSDPの1つ以上のメディアストリームのa = ice-mismatch属性を含めることがあります。これは、応募者が氷をサポートしていることを提供者に合図しますが、シグナリング中間部が対応する候補属性を変更せずにメディアコンポーネントのデフォルトの宛先を変更したため、セッションには氷の処理が使用されなかったことを示します。これが起こる可能性のあるケースの議論については、セクション18を参照してください。この仕様は、そのような障害の場合にエージェントがどのように進行するかについてのガイダンスを提供しません。
The offerer follows the same procedures described for the answerer in Section 5.2.
オファーは、セクション5.2の回答者について説明したのと同じ手順に従います。
Formation of check lists is performed only by full implementations. The offerer follows the same procedures described for the answerer in Section 5.7.
チェックリストの形成は、完全な実装によってのみ実行されます。オファーは、セクション5.7の回答者について説明したのと同じ手順に従います。
Ordinary checks are performed only by full implementations. The offerer follows the same procedures described for the answerer in Section 5.8.
通常のチェックは、完全な実装によってのみ実行されます。オファーは、セクション5.8の回答者について説明したのと同じ手順に従います。
This section describes how connectivity checks are performed. All ICE implementations are required to be compliant to [RFC5389], as opposed to the older [RFC3489]. However, whereas a full implementation will both generate checks (acting as a STUN client) and receive them (acting as a STUN server), a lite implementation will only receive checks, and thus will only act as a STUN server.
このセクションでは、接続チェックの実行方法について説明します。すべての氷の実装は、古い[RFC3489]とは対照的に、[RFC5389]に準拠する必要があります。ただし、完全な実装はチェック（スタンクライアントとして機能する）を生成し、それらを受信（スタンサーバーとして機能させる）の両方で、Lite実装はチェックのみを受信し、したがってスタンサーバーとしてのみ機能します。
These procedures define how an agent sends a connectivity check, whether it is an ordinary or a triggered check. These procedures are only applicable to full implementations.
これらの手順は、エージェントが通常のチェックであろうとトリガーされたチェックであろうと、接続チェックをどのように送信するかを定義します。これらの手順は、完全な実装にのみ適用できます。
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 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アドレスに対する特定の中継候補の許可を作成するようにターンサーバーに指示した場合、それは以前に作成したでしょう。許可を作成するために、エージェントは[RFC5766]で定義されている手順に従います。許可は、リモート候補のIPアドレスに対して作成する必要があります。エージェントは、ICEが完了するまでターンチャネルの作成を延期することをお勧めします。その場合、接続チェックの接続チェックの許可は通常、createpermissionリクエストを使用して作成されます。設立されたら、エージェントはICEが終了するまで許可をアクティブに保つ必要があります。
The check is generated by sending a Binding request from a local candidate to a remote candidate. [RFC5389] describes how Binding requests are constructed and generated. A connectivity check MUST utilize the STUN short-term credential mechanism. Support for backwards compatibility with RFC 3489 MUST NOT be used or assumed with connectivity checks. The FINGERPRINT mechanism MUST be used for connectivity checks.
チェックは、地元の候補者からリモート候補者に拘束力のある要求を送信することにより生成されます。[RFC5389]は、バインディングリクエストがどのように構築および生成されるかを説明しています。接続チェックは、スタンの短期資格メカニズムを利用する必要があります。RFC 3489との逆方向の互換性のサポートは、接続チェックで使用または想定してはなりません。指紋メカニズムは、接続のチェックに使用する必要があります。
ICE extends STUN by defining several new attributes, including PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These new attributes are formally defined in Section 19.1, and their usage is described in the subsections below. These STUN extensions are applicable only to connectivity checks used for ICE.
ICEは、優先順位、使用能力、アイスコントロール、アイスコントロールなど、いくつかの新しい属性を定義することでスタンを拡張します。これらの新しい属性は、セクション19.1で正式に定義されており、それらの使用法は以下のサブセクションで説明されています。これらのスタンエクステンションは、氷に使用される接続チェックにのみ適用されます。
An agent MUST include the PRIORITY attribute in its Binding request. The attribute MUST be set equal to the priority that would be assigned, based on the algorithm in Section 4.1.2, to a peer reflexive candidate, should one be learned as a consequence of this check (see Section 7.1.3.2.1 for how peer reflexive candidates are learned). This priority value will be computed identically to how the priority for the local candidate of the pair was computed, except that the type preference is set to the value for peer reflexive candidate types.
エージェントは、バインディングリクエストに優先度属性を含める必要があります。属性は、セクション4.1.2のアルゴリズムに基づいて、ピア反射候補に割り当てられる優先度に等しく設定する必要があります。ピア反射候補者が学習されます）。この優先値は、タイプの設定がピアリフレクション候補タイプの値に設定されていることを除いて、ペアのローカル候補の優先度が計算された方法と同じように計算されます。
The controlling agent MAY include the USE-CANDIDATE attribute in the Binding request. The controlled agent MUST NOT include it in its Binding request. This attribute signals that the controlling agent wishes to cease checks for this component, and use the candidate pair resulting from the check for this component. Section 8.1.1 provides guidance on determining when to include it.
制御エージェントには、バインディングリクエストにユースキャンディデート属性を含めることができます。制御されたエージェントは、拘束力のある要求にそれを含めてはなりません。この属性は、制御エージェントがこのコンポーネントのチェックを停止し、このコンポーネントのチェックから生じる候補ペアを使用することを望んでいることを示しています。セクション8.1.1は、いつ含まれるかを決定するためのガイダンスを提供します。
The agent MUST include the ICE-CONTROLLED attribute in the request if it is in the controlled role, and MUST include the ICE-CONTROLLING attribute in the request if it is in the controlling role. The content of either attribute MUST be the tie-breaker that was determined in Section 5.2. These attributes are defined fully in Section 19.1.
エージェントは、コントロールされた役割にある場合は、リクエストにアイス制御属性をリクエストに含める必要があり、コントロールの役割にある場合は、リクエストにアイスコントロール属性を含める必要があります。いずれかの属性の内容は、セクション5.2で決定されたタイブレーカーでなければなりません。これらの属性は、セクション19.1で完全に定義されています。
A Binding request serving as a connectivity check MUST utilize the STUN short-term credential mechanism. The username for the credential is formed by concatenating the username fragment provided by the peer with the username fragment of the agent sending the request, separated by a colon (":"). The password is equal to the password provided by the peer. For example, consider the case where agent L is the offerer, and agent R is the answerer. 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).
接続チェックとして機能するバインディングリクエストは、スタン短期資格情報メカニズムを利用する必要があります。資格情報のユーザー名は、ピアが提供するユーザー名フラグメントを、コロン（ "："）で区切られたリクエストを送信するエージェントのユーザー名フラグメントを使用して、ユーザー名フラグメントを連結することによって形成されます。パスワードは、ピアが提供するパスワードに等しくなります。たとえば、エージェントLが提供者であり、エージェントRが回答者である場合を考えてください。エージェントLには、候補者用のLFRAGのユーザー名フラグメントとLPASSのパスワードが含まれていました。エージェントRは、RFRAGのユーザー名フラグメントとRPassのパスワードを提供しました。LからRへの接続チェックは、ユーザー名RFRAG：LFRAGとRPASSのパスワードを使用します。RからLへの接続チェックは、ユーザー名LFRAG：RFRAGとLPASSのパスワードを使用します。応答は、リクエストと同じユーザー名とパスワードを使用します（ユーザー名属性は応答に存在しないことに注意してください）。
If the agent is using Diffserv Codepoint markings [RFC2475] in its media packets, it SHOULD apply those same markings to its connectivity checks.
エージェントがメディアパケットでDiffServ CodePointマーキング[RFC2475]を使用している場合、それらの接続チェックにそれらの同じマーキングを適用する必要があります。
When a Binding response is received, it is correlated to its Binding request using the transaction ID, as defined in [RFC5389], which then ties it to the candidate pair for which the Binding request was sent. This section defines additional procedures for processing Binding responses specific to this usage of STUN.
拘束力のある応答が受信されると、[RFC5389]で定義されているように、トランザクションIDを使用してバインディングリクエストと相関し、バインディングリクエストが送信された候補ペアに関連付けられます。このセクションでは、このSTUNの使用に固有の結合応答を処理するための追加の手順を定義します。
If the STUN transaction generates a 487 (Role Conflict) error response, the agent checks whether it included the ICE-CONTROLLED or ICE-CONTROLLING attribute in the Binding request. If the request contained the ICE-CONTROLLED attribute, the agent MUST switch to the controlling role if it has not already done so. If the request contained the ICE-CONTROLLING attribute, the agent MUST switch to the controlled role if it has not already done so. Once it has switched, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue. The state of that pair is set to Waiting. When the triggered check is sent, it will contain an ICE-CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. Note, however, that the tie-breaker value MUST NOT be reselected.
STUNトランザクションが487（役割の競合）エラー応答を生成する場合、エージェントは、バインディング要求にICE制御属性またはICE制御属性が含まれているかどうかをチェックします。リクエストにICEが制御した属性が含まれている場合、エージェントはまだ行っていない場合は、管理の役割に切り替える必要があります。リクエストにアイスコントロール属性が含まれている場合、エージェントはまだ行っていない場合は、制御された役割に切り替える必要があります。切り替えたら、エージェントは、チェックが487を生成し、トリガーされたチェックキューに生成された候補ペアをエンキューする必要があります。そのペアの状態は待機に設定されています。トリガーされたチェックが送信されると、その新しい役割を反映したアイスコントロールまたはアイス制御属性が含まれます。ただし、タイブレーカーの値を再選択してはならないことに注意してください。
A change in roles will require an agent to recompute pair priorities (Section 5.7.2), since those priorities are a function of controlling and controlled roles. The change in role will also impact whether the agent is responsible for selecting nominated pairs and generating updated offers upon conclusion of ICE.
役割の変更には、エージェントがペアの優先順位を再計算する必要があります（セクション5.7.2）。これらの優先順位は、制御および制御された役割の関数であるためです。役割の変更は、エージェントが指名されたペアを選択し、氷の結論に応じて更新されたオファーを生成する責任があるかどうかにも影響します。
Agents MAY support receipt of ICMP errors for connectivity checks. If the STUN transaction generates an ICMP error, the agent sets the state of the pair to Failed. If the STUN transaction generates a STUN error response that is unrecoverable (as defined in [RFC5389]) or times out, the agent sets the state of the pair to Failed.
エージェントは、接続チェックのICMPエラーの受領をサポートする場合があります。STUNトランザクションがICMPエラーを生成すると、エージェントはペアの状態を失敗させます。STUNトランザクションが回復不可（[RFC5389]で定義されている）またはタイムアウトのスタンエラー応答を生成する場合、エージェントはペアの状態を失敗に設定します。
The agent MUST check that the source IP address and port of the response equal the destination IP address and port to which the Binding request was sent, and that the destination IP address and port of the response match the source IP address and port from which the Binding request was sent. In other words, the source and destination transport addresses in the request and responses are symmetric. If they are not symmetric, the agent sets the state of the pair to Failed.
エージェントは、応答のソースIPアドレスとポートが、バインディングリクエストが送信された宛先IPアドレスとポートに等しく、応答の宛先IPアドレスとポートがソースIPアドレスとポートのポートと一致することを確認する必要があります。拘束力のあるリクエストが送信されました。言い換えれば、リクエストと応答のソースと宛先の輸送アドレスは対称です。それらが対称でない場合、エージェントはペアの状態を失敗させるように設定します。
A check is considered to be a success if all of the following are true:
次のすべてが真である場合、チェックは成功と見なされます。
o The STUN transaction generated a success response.
o STUNトランザクションは成功応答を生成しました。
o The source IP address and port of the response equals the destination IP address and port to which the Binding request was sent.
o 応答のソースIPアドレスとポートは、バインディングリクエストが送信された宛先IPアドレスとポートに等しくなります。
o The destination IP address and port of the response match the source IP address and port from which the Binding request was sent.
o 宛先IPアドレスと応答のポートは、バインディングリクエストが送信されたソースIPアドレスとポートと一致します。
The agent checks 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, it has a type, base, priority, and foundation. They are computed as follows:
エージェントは、STUN応答からマッピングされたアドレスをチェックします。輸送アドレスがエージェントが知っているローカル候補のいずれかと一致しない場合、マッピングされたアドレスは新しい候補であるピア反射候補を表します。他の候補者と同様に、タイプ、ベース、優先度、および基礎があります。それらは次のように計算されます：
o Its type is equal to peer reflexive.
o そのタイプはピア反射に等しい。
o Its base is set equal to the local candidate of the candidate pair from which the STUN check was sent.
o そのベースは、スタンチェックが送信された候補ペアのローカル候補に等しく設定されます。
o Its priority is set equal to the value of the PRIORITY attribute in the Binding request.
o その優先度は、バインディング要求の優先度属性の値に等しく設定されます。
o Its foundation is selected as described in Section 4.1.1.3.
o その基礎は、セクション4.1.1.3で説明されているように選択されています。
This peer reflexive candidate is then added to the list of local candidates for the media stream. Its username fragment and password are the same as all other local candidates for that media stream.
このピア反射候補は、メディアストリームのローカル候補者のリストに追加されます。そのユーザー名のフラグメントとパスワードは、そのメディアストリームの他のすべてのローカル候補と同じです。
However, the peer reflexive candidate is not paired with other remote candidates. This is not necessary; a valid pair will be generated from it momentarily based on the procedures in Section 7.1.3.2.2. If an agent wishes to pair the peer reflexive candidate with other remote candidates besides the one in the valid pair that will be generated, the agent MAY generate an updated offer which includes the peer reflexive candidate. This will cause it to be paired with all other remote candidates.
ただし、ピア反射候補は他のリモート候補とペアになっていません。これは必要ありません。セクション7.1.3.2.2の手順に基づいて、有効なペアが瞬間的に生成されます。エージェントが、生成される有効なペアの候補以外にピア反射候補と他のリモート候補をペアリングしたい場合、エージェントはピア反射候補を含む更新されたオファーを生成する場合があります。これにより、他のすべてのリモート候補とペアになります。
The 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, since it has been validated by a STUN connectivity check. The valid pair may equal the pair that generated the check, may equal a different pair in the check list, or may be a pair not currently on any check list. If the pair equals the pair that generated the check or is on a check list currently, it is also added to the VALID LIST, which is maintained by the agent for each media stream. This list is empty at the start of ICE processing, and fills as checks are performed, resulting in valid candidate pairs.
エージェントは、ローカル候補者が応答のマッピングされたアドレスに等しい候補ペアを構築し、リモート候補はリクエストが送信された宛先アドレスに等しくなります。これは、スタン接続チェックによって検証されているため、有効なペアと呼ばれます。有効なペアは、チェックを生成したペアに等しく、チェックリストの別のペアに等しく、または現在どのチェックリストに載っていないペアである場合があります。ペアがチェックを生成したペアに等しく、現在チェックリストにある場合、各メディアストリームのエージェントによって維持される有効なリストにも追加されます。このリストは氷加工の開始時に空であり、チェックが実行されると記入されているため、有効な候補ペアになります。
It will be very common that the pair will not be on any check list. Recall that the check list has pairs whose local candidates are never server reflexive; those pairs had their local candidates converted to the base of the server reflexive candidates, and then pruned if they were redundant. When the response to the STUN check 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 check list.
ペアがチェックリストに載っていないことは非常に一般的です。チェックリストには、地元の候補者がサーバー反射ではないペアがあることを思い出してください。これらのペアには、地元の候補者がサーバー反射候補のベースに変換され、冗長である場合は剪定されました。スタンチェックへの応答が到着すると、2つの間にNATがある場合、マッピングされたアドレスが再帰的になります。その場合、有効なペアには、チェックリストのペアのいずれにも一致しないローカル候補があります。
If the pair is not on any check list, the agent computes the priority for the pair based on the priority of each candidate, using the algorithm in Section 5.7. The priority of the local candidate depends on its type. If it is not peer reflexive, it is equal to the priority signaled for that candidate in the SDP. If it 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 SDP of the peer. If the candidate does not appear there, then the check must have 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.
ペアがチェックリストに載っていない場合、エージェントは、セクション5.7のアルゴリズムを使用して、各候補の優先度に基づいてペアの優先度を計算します。地元の候補者の優先順位は、そのタイプに依存します。ピア反射でない場合、SDPの候補者に対して合図された優先度に等しくなります。ピア反射の場合、完了したばかりの拘束力のあるリクエストに配置されたエージェントが優先属性に等しくなります。リモート候補の優先順位は、ピアのSDPから取得されます。候補者がそこに表示されない場合、チェックは新しいリモート候補者へのトリガーチェックであったに違いありません。その場合、優先順位は、完了したばかりのチェックをトリガーしたバインディング要求の優先順位属性の値と見なされます。その後、ペアは有効なリストに追加されます。
The agent sets the state of the pair that *generated* the check to Succeeded. Note that, the pair which *generated* the check may be different than the valid pair constructed in Section 7.1.3.2.2 as a consequence of the response. The success of this check might also cause the state of other checks to change as well. The agent MUST perform the following two steps:
エージェントは、成功するためにチェックを *生成 *したペアの状態を設定します。チェックを *生成 *したペアは、応答の結果としてセクション7.1.3.2.2で作成された有効なペアとは異なる場合があることに注意してください。このチェックの成功により、他のチェックの状態も変更される可能性があります。エージェントは、次の2つのステップを実行する必要があります。
1. The agent changes the states for all other Frozen pairs for the same media stream and same foundation to Waiting. Typically, but not always, these other pairs will have different component IDs.
1. エージェントは、同じメディアストリームの他のすべての凍結ペアのために状態を変更し、同じ基礎を待っています。通常、常にではありませんが、これらの他のペアには異なるコンポーネントIDがあります。
2. If there is a pair in the valid list for every component of this media stream (where this is the actual number of components being used, in cases where the number of components signaled in the SDP differs from offerer to answerer), the success of this check may unfreeze checks for other media streams. Note that this step is followed not just the first time the valid list under consideration has a pair for every component, but every subsequent time a check succeeds and adds yet another pair to that valid list. The agent examines the check list for each other media stream in turn:
2.
* If the check list is active, the agent changes the state of all Frozen pairs in that check list whose foundation matches a pair in the valid list under consideration to Waiting.
* チェックリストがアクティブな場合、エージェントは、そのチェックリストのすべての凍結ペアの状態を変更します。
* If the check list is frozen, and there is at least one pair in the check list whose foundation matches a pair in the valid list under consideration, the state of all pairs in the check list whose foundation matches a pair in the valid list under consideration is set to Waiting. This will cause the check list to become active, and ordinary checks will begin for it, as described in Section 5.8.
* チェックリストが凍結されており、検討中の有効なリストの基礎と一致するペアと一致するチェックリストに少なくとも1つのペアがある場合、検討中の有効なリストの基礎がペアと一致するチェックリストのすべてのペアの状態があります待っています。これにより、チェックリストがアクティブになり、セクション5.8で説明されているように、通常のチェックが開始されます。
* If the check list is frozen, and there are no pairs in the check list whose foundation matches a pair in the valid list under consideration, the agent
* チェックリストが凍結されており、チェックリストにペアがない場合、検討中の有効なリストの基礎がペアと一致するペアがあります。
+ groups together all of the pairs with the same foundation, and
+ 同じ基盤を持つすべてのペアをグループ化し、
+ for each group, sets the state of the pair with the lowest component ID to Waiting. If there is more than one such pair, the one with the highest priority is used.
+ 各グループについて、最低コンポーネントIDを使用してペアの状態を待っています。そのようなペアが複数ある場合、最優先度の高いペアが使用されます。
If the agent was a controlling agent, and it had included a USE-CANDIDATE attribute in the Binding request, the valid pair generated from that check has its nominated flag set to true. This flag indicates that this valid pair should be used for media if it is the highest-priority one amongst those whose nominated flag is set. This may conclude ICE processing for this media stream or all media streams; see Section 8.
エージェントが制御エージェントであり、バインディングリクエストにユースキャンディデート属性が含まれていた場合、そのチェックから生成された有効なペアには、ノミネートされたフラグがtrueに設定されています。このフラグは、この有効なペアが、指名されたフラグが設定されている人の中で最も優先度の高いペアである場合、メディアに使用する必要があることを示しています。これにより、このメディアストリームまたはすべてのメディアストリームの氷加工が終了する場合があります。セクション8を参照してください。
If the agent is the controlled agent, the response may be the result of a triggered check that was sent in response to a request that itself had the USE-CANDIDATE attribute. This case is described in Section 7.2.1.5, and may now result in setting the nominated flag for the pair learned from the original request.
エージェントが制御されたエージェントである場合、応答は、それ自体が使用補助属性を持っている要求に応じて送信されたトリガーチェックの結果である可能性があります。このケースはセクション7.2.1.5で説明されており、元のリクエストから学んだペアの指名フラグを設定する可能性があります。
Regardless of whether the check was successful or failed, the completion of the transaction may require updating of check list and timer states.
小切手が成功したか失敗したかに関係なく、トランザクションの完了にはチェックリストとタイマーの状態の更新が必要になる場合があります。
If all of the pairs in the check list are now either in the Failed or Succeeded state:
チェックリストのすべてのペアが失敗した状態または成功した状態のいずれかにある場合：
o If there is not a pair in the valid list for each component of the media stream, the state of the check list is set to Failed.
o メディアストリームの各コンポーネントの有効なリストにペアがない場合、チェックリストの状態が故障するように設定されています。
o For each frozen check list, the agent
o 各凍結チェックリストについて、エージェント
* groups together all of the pairs with the same foundation, and
* 同じ基盤を持つすべてのペアをグループ化し、
* for each group, sets the state of the pair with the lowest component ID to Waiting. If there is more than one such pair, the one with the highest priority is used.
* 各グループについて、最低コンポーネントIDを使用してペアの状態を待っています。そのようなペアが複数ある場合、最優先度の高いペアが使用されます。
If none of the pairs in the check list are in the Waiting or Frozen state, the check list is no longer considered active, and will not count towards the value of N in the computation of timers for ordinary checks as described in Section 5.8.
チェックリストのペアが待機状態または凍結状態にない場合、チェックリストはアクティブと見なされなくなり、セクション5.8で説明されている通常のチェックのタイマーの計算におけるNの値にカウントされません。
An agent MUST be prepared to receive a Binding request on the base of each candidate it included in its most recent offer or answer. This requirement holds even if the peer is a lite implementation.
エージェントは、最新のオファーまたは回答に含まれる各候補者のベースに拘束力のあるリクエストを受ける準備をする必要があります。この要件は、ピアがLiteの実装であっても保持されます。
The agent MUST use a short-term credential to authenticate the request and perform a message integrity check. 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 an offer or answer for a session in-progress. It is possible (and in fact very likely) that an offerer will receive a Binding request prior to receiving the answer from its peer. If this happens, the agent MUST immediately generate a response (including computation of the mapped address as described in Section 7.2.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, 7.2.1.3, 7.2.1.4, and 7.2.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.
エージェントは、短期資格情報を使用してリクエストを認証し、メッセージの整合性チェックを実行する必要があります。エージェントは、コロンによって区切られた2つの値で構成される場合、ユーザー名が有効であると考える必要があります。最初の値は、プログレス内のセッションの申し出または回答でエージェントによって生成されたユーザー名フラグメントに等しくなります。提供者がピアから答えを受け取る前に拘束力のある要求を受け取ることは可能です（そして実際には非常に可能性があります）。これが発生した場合、エージェントはすぐに応答を生成する必要があります（セクション7.2.1.2で説明されているように、マッピングされたアドレスの計算を含む）。エージェントは、この時点で応答を生成するのに十分な情報を持っています。ピアからのパスワードは必要ありません。回答を受信したら、必要な残りの手順、つまり7.2.1.3、7.2.1.4、および7.2.1.5を完全に実装する必要があります。回答の前に複数のスタンリクエストが受信された場合、これにより、トリガーされたチェックキューでいくつかのペアがキューに登録される可能性があります。
An agent MUST NOT utilize the ALTERNATE-SERVER mechanism, and MUST NOT support the backwards-compatibility mechanisms to RFC 3489. It MUST utilize the FINGERPRINT mechanism.
エージェントは、代替サーバーメカニズムを利用してはならず、RFC 3489の後方互換性メカニズムをサポートしてはなりません。指紋メカニズムを利用する必要があります。
If the agent is using Diffserv Codepoint markings [RFC2475] in its media packets, it SHOULD apply those same markings to its responses to Binding requests. The same would apply to any layer 2 markings the endpoint might be applying to media packets.
エージェントがメディアパケットでDiffServ CodePointマーキング[RFC2475]を使用している場合、それらの同じマーキングをバインディングリクエストに対する応答に適用する必要があります。エンドポイントがメディアパケットに適用される可能性のあるレイヤー2のマークにも同じことが当てはまります。
This subsection defines the additional server procedures applicable to full implementations.
このサブセクションでは、完全な実装に適用される追加のサーバー手順を定義します。
Normally, the rules for selection of a role in Section 5.2 will result in each agent selecting a different role -- one controlling and one controlled. However, in unusual call flows, typically utilizing third party call control, it is possible for both agents to select the same role. This section describes procedures for checking for this case and repairing it.
通常、セクション5.2での役割を選択するためのルールは、各エージェントが異なる役割を選択し、1つは制御され、1つは制御されます。ただし、通常、サードパーティのコールコントロールを利用する異常なコールフローでは、両方のエージェントが同じ役割を選択することが可能です。このセクションでは、このケースをチェックして修理する手順について説明します。
An agent MUST examine the Binding request for either the ICE-CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these procedures:
エージェントは、アイスコントロールまたはアイス制御属性のいずれかのバインディングリクエストを調べる必要があります。これらの手順に従う必要があります。
o If neither ICE-CONTROLLING nor ICE-CONTROLLED is present in the request, the peer agent may have implemented a previous version of this specification. There may be a conflict, but it cannot be detected.
o リクエストにアイスコントロールもアイスコントロールも存在しない場合、ピアエージェントはこの仕様の以前のバージョンを実装した可能性があります。競合があるかもしれませんが、検出することはできません。
o If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request:
o エージェントが管理の役割にあり、リクエストにはアイスコントロール属性が存在する場合：
* If the agent's tie-breaker 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.
* エージェントのタイブレーカーがアイスコントロール属性の内容以下が大きい場合、エージェントはバインディングエラー応答を生成し、値487（役割競合）のエラーコード属性を含みますが、その役割を保持します。
* If the agent's tie-breaker is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role.
* エージェントのタイブレーカーがアイスコントロール属性の内容よりも少ない場合、エージェントは制御された役割に切り替えます。
o If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request:
o エージェントが制御された役割にあり、リクエストにICE制御された属性が存在する場合：
* If the agent's tie-breaker is larger than or equal to the contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role.
* エージェントのタイブレーカーが、アイス制御属性の内容よりも大きい場合、エージェントは制御ロールに切り替えます。
* If the agent's tie-breaker 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.
* エージェントのタイブレーカーがアイス制御属性の内容よりも少ない場合、エージェントはバインディングエラー応答を生成し、値487（役割競合）のエラーコード属性を含みますが、その役割を保持します。
o If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or the agent was in the controlling role and the ICE-CONTROLLED attribute was present in the request, there is no conflict.
o エージェントが制御された役割にあり、リクエストにアイスコントロール属性が存在するか、エージェントが制御役割であり、リクエストにアイス制御属性が存在する場合、競合はありません。
A change in roles will require an agent to recompute pair priorities (Section 5.7.2), since those priorities are a function of controlling and controlled roles. The change in role will also impact whether the agent is responsible for selecting nominated pairs and generated updated offers upon conclusion of ICE.
役割の変更には、エージェントがペアの優先順位を再計算する必要があります（セクション5.7.2）。これらの優先順位は、制御および制御された役割の関数であるためです。役割の変更は、エージェントが指名されたペアを選択し、氷の結論に応じて更新されたオファーを生成する責任があるかどうかにも影響します。
The remaining sections in Section 7.2.1 are followed if the server generated a successful response to the Binding request, even if the agent changed roles.
セクション7.2.1の残りのセクションは、エージェントが役割を変更したとしても、サーバーがバインディング要求に対する成功した応答を生成した場合に追跡されます。
For requests being 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.
中継候補で受信されるリクエストの場合、スタン処理に使用されるソーストランスポートアドレス（つまり、XOR-Mapp-Address属性の生成）は、Turn Serverで見られる輸送アドレスです。そのソーストランスポートアドレスは、データ表示を介してバインディングリクエストが配信された場合、データ表示メッセージのXOR-PEER-ADDRESS属性に存在します。バインディングリクエストが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 priority of the candidate is set to the PRIORITY attribute from the request.
o 候補者の優先度は、リクエストから優先属性に設定されます。
o The type of the candidate is set to peer reflexive.
o 候補者のタイプは、ピア反射に設定されています。
o The foundation of the candidate is set to an arbitrary value, different from the foundation for all other remote candidates. If any subsequent offer/answer exchanges contain this peer reflexive candidate in the SDP, it will signal the actual foundation for the candidate.
o 候補者の基礎は、他のすべてのリモート候補者の基礎とは異なり、任意の価値に設定されています。その後のオファー/回答交換にSDPのこのピア反射候補者が含まれている場合、候補者の実際の基盤が示されます。
o The component ID of this candidate is set to the component ID for the local candidate to which the request was sent.
o この候補者のコンポーネントIDは、リクエストが送信されたローカル候補のコンポーネントIDに設定されます。
This candidate is added to the list of remote candidates. However, the agent does not pair this candidate with any local candidates.
この候補者は、リモート候補のリストに追加されます。ただし、エージェントはこの候補者と地元の候補者を組み合わせていません。
Next, the agent constructs a pair whose local candidate is equal to the transport address 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 either be 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 check list. There can be one of several outcomes:
次に、エージェントは、ローカル候補がスタンリクエストを受信した輸送アドレスに等しいペアを構築し、リクエストが来たソーストランスポートアドレスに等しいリモート候補（これはピア反射的なリモート候補である可能性があります。学んだばかり）。地元の候補者は、ホスト候補（リレーンを介してリクエストが受信されなかった場合）またはリレー候補（リレーを介して受信される場合）のいずれかです。地元の候補者は、サーバー反射候補になることはできません。両方の候補者はエージェントに知られているため、優先順位を取得し、候補者のペアの優先順位を計算できます。このペアは、チェックリストで検索されます。いくつかの結果の1つがあります。
o If the pair is already on the check list:
o ペアがすでにチェックリストに載っている場合：
* If the state of that pair is Waiting or Frozen, a check for that pair is enqueued into the triggered check queue if not already present.
* そのペアの状態が待っているか冷凍されている場合、そのペアのチェックは、まだ存在していない場合、トリガーされたチェックキューに囲まれています。
* 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 request, 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 create a new connectivity check for that pair (representing a new STUN Binding request transaction) by enqueueing the pair in the triggered check queue. The state of the pair is then changed to Waiting.
* そのペアの状態が進行中の場合、エージェントは進行中のトランザクションをキャンセルします。キャンセルとは、エージェントがリクエストを再送信せず、応答の欠如を失敗に扱わないことを意味しますが、トランザクションタイムアウトの期間を応答の期間待ちます。さらに、エージェントは、トリガーされたチェックキューにペアを囲むことにより、そのペアの新しい接続チェック（新しいスタンバインディングリクエストトランザクションを表す）を作成する必要があります。その後、ペアの状態が待機に変更されます。
* If the state of the pair is Failed, it is changed to Waiting and the agent MUST create a new connectivity check for that pair (representing a new STUN Binding request transaction), by enqueueing the pair in the triggered check queue.
* ペアの状態が失敗した場合、それは待機に変更され、エージェントは、トリガーされたチェックキューにペアをエンキューすることにより、そのペアの新しい接続チェック（新しいスタンバインディングリクエストトランザクションを表す）を作成する必要があります。
* If the state of that pair is Succeeded, nothing further is done.
* そのペアの状態が成功した場合、それ以上は何も行われません。
These steps are done to facilitate rapid completion of ICE when both agents are behind NAT.
これらの手順は、両方のエージェントがNATの背後にいるときに氷の迅速な完了を促進するために行われます。
o If the pair is not already on the check list:
o ペアがまだチェックリストに載っていない場合：
* The pair is inserted into the check list 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.1.2. 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 SDP messages received from its peer (there may be more than one in cases of forking), and find this username fragment. The corresponding password is then selected.
トリガーされたチェックを送信すると、セクション7.1.2で説明されているように構築および処理されます。これらの手順では、エージェントがピアのトランスポートアドレス、ユーザー名フラグメント、およびパスワードを知る必要があります。リモート候補のユーザー名フラグメントは、受け取ったばかりのバインディング要求のユーザー名のコロンの後の部品に等しくなります。そのユーザー名フラグメントを使用して、エージェントはピアから受信したSDPメッセージを確認できます（フォーキングの場合は複数ある場合があります）。このユーザー名フラグメントを見つけます。対応するパスワードが選択されます。
If the Binding request received by the agent had the USE-CANDIDATE attribute set, and the agent is in the controlled role, the agent looks at the state of the pair computed in Section 7.2.1.4:
エージェントが受信したバインディングリクエストには、ユースキャンディデート属性セットがあり、エージェントが制御された役割にある場合、エージェントはセクション7.2.1.4で計算されたペアの状態を調べます。
o If the state of this pair is Succeeded, it means that the check generated by this pair produced a successful response. This would have caused the agent to construct a valid pair when that success response was received (see Section 7.1.3.2.2). The agent now sets the nominated flag in the valid pair to true. This may end ICE processing for this media stream; see Section 8.
o このペアの状態が成功した場合、このペアによって生成されたチェックが成功した応答を生成したことを意味します。これにより、その成功応答が受信されたときにエージェントが有効なペアを構築しました（セクション7.1.3.2.2を参照）。エージェントは、有効なペアに指名されたフラグをTrueに設定します。これにより、このメディアストリームの氷加工が終了する場合があります。セクション8を参照してください。
o If the state of this pair is In-Progress, if its check produces a successful result, the resulting valid pair has its nominated flag set when the response arrives. This may end ICE processing for this media stream when it arrives; see Section 8.
o このペアの状態が進行中である場合、そのチェックが成功した結果を生成する場合、結果の有効なペアは、応答が届くとノミネートされたフラグセットがあります。これにより、このメディアストリームが到着したときの氷加工が終了する可能性があります。セクション8を参照してください。
If the check that was just received contained a USE-CANDIDATE attribute, the agent constructs a candidate pair whose local candidate is equal to 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 a list of valid candidates called the valid list. The agent sets the nominated flag for that pair to true. ICE processing is considered complete for a media stream if the valid list contains a candidate pair for each component.
受け取ったばかりのチェックにユースキャンディデート属性が含まれている場合、エージェントは、ローカル候補がリクエストが受信されたトランスポートアドレスに等しい候補ペアを構築し、リモート候補はリクエストのソーストランスポートアドレスに等しいそれが受け取られました。この候補ペアには任意の優先度が割り当てられ、有効なリストと呼ばれる有効な候補のリストに配置されます。エージェントは、そのペアのノミネートされたフラグをTrueに設定します。有効なリストに各コンポーネントの候補ペアが含まれている場合、メディアストリームのアイスプロセシングは完全であると見なされます。
This section describes how an agent completes ICE.
このセクションでは、エージェントがどのように氷を完成させるかについて説明します。
Concluding ICE involves nominating pairs by the controlling agent and updating of state machinery.
氷の締め切りには、制御剤によるペアの指名と状態機械の更新が含まれます。
The controlling agent nominates pairs to be selected by ICE by using one of two techniques: regular nomination or aggressive nomination. If its peer has a lite implementation, an agent MUST use a regular nomination algorithm. If its peer is using ICE options (present in an ice-options attribute from the peer) that the agent does not understand, the agent MUST use a regular nomination algorithm. If its peer is a full implementation and isn't using any ICE options or is using ICE options understood by the agent, the agent MAY use either the aggressive or the regular nomination algorithm. However, the regular algorithm is RECOMMENDED since it provides greater stability.
コントロールエージェントは、2つのテクニックのいずれかを使用して、ICEで選択されるペアを指名します：定期的な指名または積極的な指名。ピアにLite実装がある場合、エージェントは通常のノミネートアルゴリズムを使用する必要があります。ピアがエージェントが理解していないアイスオプション（ピアからのアイスオプション属性に存在する）を使用している場合、エージェントは通常のノミネートアルゴリズムを使用する必要があります。ピアが完全な実装であり、アイスオプションを使用していない場合、またはエージェントが理解したアイスオプションを使用している場合、エージェントは攻撃的または通常のノミネートアルゴリズムのいずれかを使用できます。ただし、通常のアルゴリズムはより大きな安定性を提供するため推奨されます。
With regular nomination, the agent lets some number of checks complete, each of which omit the USE-CANDIDATE attribute. Once one or more checks complete successfully for a component of a media stream, valid pairs are generated and added to the valid list. The agent lets the checks continue until some stopping criterion is met, and then picks amongst the valid pairs based on an evaluation criterion. The criteria for stopping the checks and for evaluating the valid pairs is entirely a matter of local optimization.
定期的な指名により、エージェントはいくつかのチェックを完了させ、それぞれがユースキャンディデート属性を省略します。メディアストリームのコンポーネントに対して1つ以上のチェックが正常に完了すると、有効なペアが生成され、有効なリストに追加されます。エージェントは、一部の停止基準が満たされるまでチェックを続け、評価基準に基づいて有効なペアを選択します。チェックを停止し、有効なペアを評価するための基準は、完全にローカル最適化の問題です。
When the controlling agent selects the valid pair, it repeats the check that produced this valid pair (by enqueuing the pair that generated the check into the triggered check queue), this time with the USE-CANDIDATE attribute. This check should succeed (since the previous did), causing the nominated flag of that and only that pair to be set. Consequently, there will be only a single nominated pair in the valid list for each component, and when the state of the check list moves to completed, that exact pair is selected by ICE for sending and receiving media for that component.
制御エージェントが有効なペアを選択すると、この有効なペアが生成されたチェックを繰り返します（トリガーされたチェックキューにチェックを生成したペアをエンキューすることにより）、今回はユースキャンディデート属性を使用します。このチェックは成功するはずです（以前に行ったため）。その指名フラグが発生し、そのペアのみが設定されます。その結果、各コンポーネントの有効なリストに1つのノミネートされたペアのみが存在し、チェックリストの状態が完了するように移動すると、そのコンポーネントのメディアを送信および受信するためにその正確なペアがICEによって選択されます。
Regular nomination provides the most flexibility, since the agent has control over the stopping and selection criteria for checks. 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 present. Regular nomination also improves ICE's resilience to variations in implementation (see Section 14). Regular nomination is also more stable, allowing both agents to converge on a single pair for media without any transient selections, which can happen with the aggressive algorithm. The drawback of regular nomination is that it is guaranteed to increase latencies because it requires an additional check to be done.
エージェントがチェックの停止基準と選択基準を制御できるため、定期的な指名は最も柔軟性を提供します。唯一の要件は、エージェントが最終的に1つの候補ペアのみを選択し、存在するユースキャンディデート属性を使用してそのペアのチェックを生成する必要があることです。定期的な指名により、ICEの実装の変動に対する回復力も向上します（セクション14を参照）。定期的な指名もより安定しているため、両方のエージェントが一時的な選択なしでメディア用に単一のペアに収束することができます。これは、積極的なアルゴリズムで発生する可能性があります。定期的な指名の欠点は、追加のチェックを行う必要があるため、レイテンシを増やすことが保証されていることです。
With aggressive nomination, the controlling agent includes the USE-CANDIDATE attribute in every check it sends. Once the first check for a component succeeds, it will be added to the valid list and have its nominated flag set. When all components have a nominated pair in the valid list, media can begin to flow using the highest priority nominated pair. However, because the agent included the USE-CANDIDATE attribute in all of its checks, another check may yet complete, causing another valid pair to have its nominated flag set. ICE always selects the highest-priority nominated candidate pair from the valid list as the one used for media. Consequently, the selected pair may actually change briefly as ICE checks complete, resulting in a set of transient selections until it stabilizes.
積極的な指名により、コントロールエージェントには、送信するすべてのチェックにユースキャンディデート属性が含まれます。コンポーネントの最初のチェックが成功すると、有効なリストに追加され、ノミネートされたフラグセットがあります。すべてのコンポーネントが有効なリストにノミネートされたペアを持っている場合、メディアは最高の優先度の指名ペアを使用して流れ始めることができます。ただし、エージェントにはすべてのチェックにユースキャンディデート属性が含まれているため、別のチェックがまだ完了する可能性があるため、別の有効なペアにノミネートされたフラグが設定されます。ICEは常に、メディアに使用されているものとして有効なリストから最高優先権指名候補ペアを常に選択します。したがって、選択したペアは、氷のチェックが完了すると実際に一時的に変化する可能性があり、その結果、安定するまで一時的な選択のセットが得られます。
For both controlling and controlled agents, the state of ICE processing depends on the presence of nominated candidate pairs in the valid list and on the state of the check list. Note that, at any time, more than one of the following cases can apply:
制御エージェントと制御されたエージェントの両方について、氷加工の状態は、有効なリストとチェックリストの状態に指名された候補ペアの存在に依存します。いつでも、次の場合は複数のケースを適用できることに注意してください。
o If there are no nominated pairs in the valid list for a media stream and the state of the check list is Running, ICE processing continues.
o メディアストリームの有効なリストに指名されたペアがなく、チェックリストの状態が実行されている場合、氷の処理は継続します。
o If there is at least one nominated pair in the valid list for a media stream and the state of the check list is Running:
o メディアストリームの有効なリストに少なくとも1つのノミネートされたペアがあり、チェックリストの状態が実行されている場合：
* The agent MUST remove all Waiting and Frozen pairs in the check list and triggered check queue for the same component as the nominated pairs for that media stream.
* エージェントは、チェックリストのすべての待機と冷凍ペアを削除し、そのメディアストリームの指名ペアと同じコンポーネントのチェックキューをトリガーする必要があります。
* If an In-Progress pair in the check list is for the same component as a nominated pair, the agent SHOULD cease retransmissions for its check if its pair priority is lower than the lowest-priority nominated pair for that component.
* チェックリストの進行中のペアがノミネートされたペアと同じコンポーネントの場合、エージェントは、そのコンポーネントの最優先度のノミネートペアよりもペアの優先度が低い場合、チェックの再送信を停止する必要があります。
o Once there is at least one nominated pair in the valid list for every component of at least one media stream and the state of the check list is Running:
o 少なくとも1つのメディアストリームのすべてのコンポーネントの有効なリストに少なくとも1つのノミネートされたペアがあり、チェックリストの状態が実行されています。
* The agent MUST change the state of processing for its check list for that media stream to Completed.
* エージェントは、そのメディアストリームが完了するようにチェックリストの処理状態を変更する必要があります。
* The agent MUST continue to respond to any checks it may still receive for that media stream, and MUST perform triggered checks if required by the processing of Section 7.2.
* エージェントは、そのメディアストリームに対してまだ受け取る可能性のある小切手に引き続き応答し、セクション7.2の処理で必要な場合はトリガーされたチェックを実行する必要があります。
* The agent MUST continue retransmitting any In-Progress checks for that check list.
* エージェントは、そのチェックリストの進行中のチェックを再送信し続ける必要があります。
* The agent MAY begin transmitting media for this media stream as described in Section 11.1.
* エージェントは、セクション11.1で説明されているように、このメディアストリームのメディアの送信を開始できます。
o Once the state of each check list is Completed:
o 各チェックリストの状態が完了したら：
* The agent sets the state of ICE processing overall to Completed.
* エージェントは、氷の処理の状態を全体的に設定して完了します。
* If an agent is controlling, it examines the highest-priority nominated candidate pair for each component of each media stream. If any of those candidate pairs differ from the default candidate pairs in the most recent offer/answer exchange, the controlling agent MUST generate an updated offer as described in Section 9. If the controlling agent is using an aggressive nomination algorithm, this may result in several updated offers as the pairs selected for media change. An agent MAY delay sending the offer for a brief interval (one second is RECOMMENDED) in order to allow the selected pairs to stabilize.
* エージェントがコントロールしている場合、各メディアストリームの各コンポーネントに対して最高優先権指名候補ペアを調べます。これらの候補ペアのいずれかが最新のオファー/回答交換のデフォルトの候補ペアと異なる場合、制御エージェントはセクション9で説明されているように更新されたオファーを生成する必要があります。制御エージェントが積極的なノミネートアルゴリズムを使用している場合、これはメディアの変更に選択されたペアとして、いくつかの更新されたオファー。エージェントは、選択したペアが安定することを可能にするために、短い間隔のオファーの送信（1秒が推奨されます）を遅らせることができます。
o If the state of the check list is Failed, ICE has not been able to complete for this media stream. The correct behavior depends on the state of the check lists for other media streams:
o チェックリストの状態が失敗した場合、ICEはこのメディアストリームのために完了することができませんでした。正しい動作は、他のメディアストリームのチェックリストの状態に依存します。
* If all check lists are Failed, ICE processing overall is considered to be in the Failed state, and the agent SHOULD consider the session a failure, SHOULD NOT restart ICE, and the controlling agent SHOULD terminate the entire session.
* すべてのチェックリストが失敗した場合、氷の処理全体が失敗した状態にあると見なされ、エージェントはセッションを失敗し、氷を再起動するべきではなく、制御エージェントがセッション全体を終了する必要があります。
* If at least one of the check lists for other media streams is Completed, the controlling agent SHOULD remove the failed media stream from the session in its updated offer.
* 他のメディアストリームのチェックリストの少なくとも1つが完了した場合、制御エージェントは更新されたオファーでセッションから失敗したメディアストリームを削除する必要があります。
* If none of the check lists for other media streams are Completed, but at least one is Running, the agent SHOULD let ICE continue.
* 他のメディアストリームのチェックリストが完了していないが、少なくとも1つが実行されている場合、エージェントはICEを継続させる必要があります。
Concluding ICE for a lite implementation is relatively straightforward. There are two cases to consider:
ライトの実装のために氷を締めくくるのは比較的簡単です。考慮すべき2つのケースがあります。
The implementation is lite, and its peer is full.
実装はライトであり、そのピアはいっぱいです。
The implementation is lite, and its peer is lite.
実装はライトであり、そのピアはライトです。
The effect of ICE concluding is that the agent can free any allocated host candidates that were not utilized by ICE, as described in Section 8.3.
氷の結論の効果は、セクション8.3で説明されているように、エージェントが氷によって使用されなかった割り当てられたホスト候補を解放できることです。
In this case, the agent will receive connectivity checks from its peer. When an agent has received a connectivity check that includes the USE-CANDIDATE attribute for each component of a media stream, the state of ICE processing for that media stream moves from Running to Completed. When the state of ICE processing for all media streams is Completed, the state of ICE processing overall is Completed.
この場合、エージェントはピアから接続チェックを受け取ります。エージェントがメディアストリームの各コンポーネントのユースキャンディデート属性を含む接続チェックを受け取った場合、そのメディアストリームの氷加工の状態は、実行から完了まで移動します。すべてのメディアストリームの氷加工の状態が完了すると、全体の氷処理の状態が完了します。
The lite implementation will never itself determine that ICE processing has failed for a media stream; rather, the full peer will make that determination and then remove or restart the failed media stream in a subsequent offer.
Liteの実装は、メディアストリームで氷の処理が失敗したとは決して決定しません。むしろ、完全なピアがその決定を下し、その後のオファーで失敗したメディアストリームを削除または再起動します。
Once the offer/answer exchange has completed, both agents examine their candidates and those of its peer. For each media stream, each agent pairs up its own candidates with the candidates of its peer for that media stream. Two candidates are paired up when they are for the same component, utilize the same transport protocol (UDP in this specification), and are from the same IP address family (IPv4 or IPv6).
オファー/回答の交換が完了すると、両方のエージェントが候補者とそのピアの候補者を調べます。各メディアストリームについて、各エージェントは、そのメディアストリームのピアの候補者と独自の候補者を組み合わせます。2つの候補者は、同じコンポーネントの場合にペアになり、同じトランスポートプロトコル（この仕様ではUDP）を使用し、同じIPアドレスファミリ（IPv4またはIPv6）からのものです。
o If there is a single pair per component, that pair is added to the Valid list. If all of the components for a media stream had one pair, the state of ICE processing for that media stream is set to Completed. If all media streams are Completed, the state of ICE processing is set to Completed overall. This will always be the case for implementations that are IPv4 only.
o コンポーネントごとに単一のペアがある場合、そのペアは有効なリストに追加されます。メディアストリームのすべてのコンポーネントに1つのペアがある場合、そのメディアストリームの氷加工の状態は完了するように設定されています。すべてのメディアストリームが完了した場合、氷加工の状態は全体的に完了するように設定されています。これは、IPv4のみである実装の場合に常に当てはまります。
o If there is more than one pair per component:
o コンポーネントごとに複数のペアがある場合：
* The agent MUST select a pair based on local policy. Since this case only arises for IPv6, it is RECOMMENDED that an agent follow the procedures of RFC 3484 [RFC3484] to select a single pair.
* エージェントは、ローカルポリシーに基づいてペアを選択する必要があります。このケースはIPv6に対してのみ発生するため、エージェントがRFC 3484 [RFC3484]の手順に従って単一のペアを選択することをお勧めします。
* The agent adds the selected pair for each component to the valid list. As described in Section 11.1, this will permit media to begin flowing. However, it is possible (and in fact likely) that both agents have chosen different pairs.
* エージェントは、各コンポーネントの選択したペアを有効なリストに追加します。セクション11.1で説明されているように、これにより、メディアが流れ始めることができます。ただし、両方のエージェントが異なるペアを選択したことは可能です（実際には可能性があります）。
* To reconcile this, the controlling agent MUST send an updated offer as described in Section 9.1.3, which will include the remote-candidates attribute.
* これを調整するには、制御エージェントは、リモートキャンディデート属性を含むセクション9.1.3に記載されているように、更新されたオファーを送信する必要があります。
* The agent MUST NOT update the state of ICE processing when the offer is sent. If this subsequent offer completes, the controlling agent MUST change the state of ICE processing to Completed for all media streams, and the state of ICE processing overall to Completed. The states for the controlled agent are set based on the logic in Section 9.2.3.
* エージェントは、オファーが送信されたときに氷加工の状態を更新してはなりません。この後続のオファーが完了した場合、制御エージェントは、すべてのメディアストリームの氷加工の状態を変更して完了する必要があり、氷加工の状態全体が完了する必要があります。制御されたエージェントの状態は、セクション9.2.3のロジックに基づいて設定されています。
The procedures in Section 8 require that an agent continue to listen for STUN requests and continue to generate triggered checks for a media stream, even once processing for that stream completes. The rules in this section describe when it is safe for an agent to cease sending or receiving checks on a candidate that was not selected by ICE, and then free the candidate.
セクション8の手順では、エージェントがスタンリクエストを聞き続け、そのストリームの処理が完了した場合でも、メディアストリームのトリガーチェックを生成し続けることが必要です。このセクションのルールでは、エージェントが氷で選択されていない候補者の小切手の送信または受信をやめてから候補者を解放することが安全であることを説明しています。
When ICE is used with SIP, and an offer is forked to multiple recipients, ICE proceeds in parallel and independently with each answerer, all using the same local candidates. Once ICE processing has reached the Completed state for all peers for media streams using those candidates, the agent SHOULD wait an additional three seconds, and then it MAY cease responding to checks or generating triggered checks on that candidate. It MAY free the candidate at that time. Freeing of server reflexive candidates is never explicit; it happens by lack of a keepalive. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed.
氷がSIPで使用され、複数の受信者にオファーが分岐すると、各応答者と同じローカル候補者を使用して氷が並行して独立して進行します。氷の処理がこれらの候補を使用してメディアストリームのすべてのピアの完了した状態に達したら、エージェントはさらに3秒待つ必要があり、その後、その候補者のチェックへの応答やトリガーチェックの生成を停止する可能性があります。その時点で候補者を解放する可能性があります。サーバー反射候補の解放は決して明確ではありません。それはキープライブの欠如によって起こります。3秒の遅延は、積極的な指名が使用されている場合のケースを処理し、ICEが完了した後に選択されたペアがすぐに変化する可能性があります。
A lite implementation MAY free candidates not selected by ICE as soon as ICE processing has reached the Completed state for all peers for all media streams using those candidates.
Liteの実装は、氷の処理がこれらの候補を使用してすべてのメディアストリームのすべてのピアの完了した状態に達したとすぐに、氷で選択されない自由候補者を使用する場合があります。
Either agent MAY generate a subsequent offer at any time allowed by RFC 3264 [RFC3264]. The rules in Section 8 will cause the controlling agent to send an updated offer at the conclusion of ICE processing when ICE has selected different candidate pairs from the default pairs. This section defines rules for construction of subsequent offers and answers.
どちらのエージェントも、RFC 3264 [RFC3264]によって許可されているいつでもその後のオファーを生成できます。セクション8のルールにより、氷がデフォルトのペアから異なる候補ペアを選択した場合、氷加工の終了時に制御エージェントが更新されたオファーを送信します。このセクションでは、その後のオファーと回答の構築に関するルールを定義します。
Should a subsequent offer be rejected, ICE processing continues as if the subsequent offer had never been made.
その後のオファーが拒否された場合、その後のオファーが行われたことがないかのように、氷の処理が続きます。
An agent MAY restart ICE processing for an existing media stream. An ICE restart, as the name implies, will cause all previous states of ICE processing to be flushed and checks to start anew. The only difference between an ICE restart and a brand new media session is that, during the restart, media can continue to be sent to the previously validated pair.
エージェントは、既存のメディアストリームのICE処理を再起動できます。名前が示すように、氷の再起動は、以前のすべての氷加工状態を洗い流し、新たに開始するためにチェックするようになります。アイス再起動と真新しいメディアセッションの唯一の違いは、再起動中、メディアを以前に検証されたペアに引き続き送信できることです。
An agent MUST restart ICE for a media stream if:
エージェントは、次の場合の場合、メディアストリームのために氷を再起動する必要があります。
o The offer is being generated for the purposes of changing the target of the media stream. In other words, if an agent wants to generate an updated offer that, had ICE not been in use, would result in a new value for the destination of a media component.
o このオファーは、メディアストリームのターゲットを変更する目的で生成されています。言い換えれば、エージェントがICEが使用されていなかった更新されたオファーを生成したい場合、メディアコンポーネントの宛先に新しい価値が生じます。
o An agent is changing its implementation level. This typically only happens in third party call control use cases, where the entity performing the signaling is not the entity receiving the media, and it has changed the target of media mid-session to another entity that has a different ICE implementation.
o エージェントは実装レベルを変更しています。これは通常、シグナリングを実行するエンティティがメディアを受信するエンティティではなく、メディアの中間セッションの目標を異なるICE実装を持つ別のエンティティに変更したサードパーティコールコントロールユースケースでのみ発生します。
These rules imply that setting the IP address in the c line to 0.0.0.0 will cause an ICE restart. Consequently, ICE implementations MUST NOT utilize this mechanism for call hold, and instead MUST use a=inactive and a=sendonly as described in [RFC3264].
これらのルールは、C行のIPアドレスを0.0.0.0に設定すると、ICEの再起動が原因であることを意味します。したがって、ICEの実装は、[RFC3264]に記載されているように、このメカニズムをコールホールドにこのメカニズムを利用してはならず、A = a = inactiveとa = sendonlyを使用する必要があります。
To restart ICE, an agent MUST change both the ice-pwd and the ice-ufrag for the media stream in an offer. Note that it is permissible to use a session-level attribute in one offer, but to provide the same ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This is not a change in password, just a change in its representation, and does not cause an ICE restart.
ICEを再起動するには、エージェントがオファーでメディアストリームのICE-PWDとICE-UFRAGの両方を変更する必要があります。セッションレベルの属性を1つのオファーで使用することは許可されていますが、その後のオファーでメディアレベルの属性と同じICE-PWDまたはICE-USFRAGを提供することは許可されています。これはパスワードの変更ではなく、その表現の変更だけでなく、ICEの再起動を引き起こしません。
An agent sets the rest of the fields in the SDP for this media stream as it would in an initial offer of this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.
エージェントは、このメディアストリームの最初のオファーと同様に、このメディアストリームのSDPの残りのフィールドを設定します（セクション4.3を参照）。その結果、候補者のセットには、そのストリームの以前の候補者の一部、なし、またはすべてが含まれ、セクション4.1.1で説明されているように、まったく新しい候補のセットを含めることができます。
If an agent removes a media stream by setting its port to zero, it MUST NOT include any candidate attributes for that media stream and SHOULD NOT include any other ICE-related attributes defined in Section 15 for that media stream.
エージェントがポートをゼロに設定してメディアストリームを削除する場合、そのメディアストリームの候補属性を含めるべきではなく、そのメディアストリームのセクション15で定義されている他の氷関連属性を含めるべきではありません。
If an agent wishes to add a new media stream, it sets the fields in the SDP for this media stream as if this was an initial offer for that media stream (see Section 4.3). This will cause ICE processing to begin for this media stream.
エージェントが新しいメディアストリームを追加したい場合、このメディアストリームのSDPのフィールドを、これがそのメディアストリームの初期オファーであるかのように設定します（セクション4.3を参照）。これにより、このメディアストリームで氷の処理が開始されます。
This section describes additional procedures for full implementations, covering existing media streams.
このセクションでは、既存のメディアストリームをカバーする完全な実装に関する追加の手順について説明します。
The username fragments, password, and implementation level MUST remain the same as used previously. If an agent needs to change one of these, it MUST restart ICE for that media stream.
ユーザー名のフラグメント、パスワード、および実装レベルは、以前に使用したものと同じままでなければなりません。エージェントがこれらのいずれかを変更する必要がある場合、そのメディアストリームのICEを再起動する必要があります。
Additional behavior depends on the state ICE processing for that media stream.
追加の動作は、そのメディアストリームの状態氷加工に依存します。
If an agent generates an updated offer including a media stream that was previously established, and for which ICE checks are in the Running state, the agent follows the procedures defined here.
エージェントが以前に確立されたメディアストリームを含む更新されたオファーを生成し、氷のチェックが実行状態にある場合、エージェントはここで定義されている手順に従います。
An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream. The properties of that candidate as signaled in SDP -- the priority, foundation, type, and related transport address -- SHOULD remain the same. The IP address, port, and transport protocol, which fundamentally identify that candidate, MUST remain the same (if they change, it would be a new candidate). The component ID MUST remain the same. The agent MAY include additional candidates it did not offer previously, but which it has gathered since the last offer/answer exchange, including peer reflexive candidates.
エージェントは、そのメディアストリームに対して以前に合図したすべてのローカル候補者の候補属性を含める必要があります。SDPで合図されたその候補の特性（優先順位、基礎、タイプ、および関連する輸送住所）は、同じままでなければなりません。候補者を根本的に識別するIPアドレス、ポート、および輸送プロトコルは、同じままでなければならない（それらが変更された場合、それは新しい候補者になるでしょう）。コンポーネントIDは同じままでなければなりません。エージェントには、以前に提供していなかった追加の候補者を含めることができますが、ピア反射候補を含む最後の申し出/回答交換以来収集しています。
The agent MAY change the default destination for media. As with initial offers, there MUST be a set of candidate attributes in the offer matching this default destination.
エージェントは、メディアのデフォルトの宛先を変更する場合があります。最初のオファーと同様に、このデフォルトの宛先に一致するオファーには、一連の候補属性が必要です。
If an agent generates an updated offer including a media stream that was previously established, and for which ICE checks are in the Completed state, the agent follows the procedures defined here.
エージェントが以前に確立されたメディアストリームを含む更新されたオファーを生成し、氷のチェックが完成した状態にある場合、エージェントはここで定義されている手順に従います。
The default destination for media (i.e., the values of the IP addresses and ports in the m and c lines used for that media stream) MUST be the local candidate from the highest-priority nominated pair in the valid list for each component. This "fixes" the default destination for media to equal the destination ICE has selected for media.
メディアのデフォルトの宛先（つまり、そのメディアストリームに使用されるMおよびCラインのIPアドレスとポートの値）は、各コンポーネントの有効なリストの最高優先権指名ペアのローカル候補でなければなりません。これにより、メディアがメディア用に選択した宛先ICEに等しくなるデフォルトの宛先が「修正」します。
The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream, and MUST NOT include any other candidates.
エージェントには、メディアストリームの各コンポーネントのデフォルトの宛先に一致する候補者の候補属性を含める必要があり、他の候補者を含めてはなりません。
In addition, if the agent is controlling, it MUST include the a=remote-candidates attribute for each media stream whose check list is in the Completed state. The attribute contains the remote candidates from the highest-priority nominated pair in the valid list for each component of that media stream. It is needed to avoid a race condition whereby the controlling agent chooses its pairs, but the updated offer beats the connectivity checks to the controlled agent, which doesn't even know these pairs are valid, let alone selected. See Appendix B.6 for elaboration on this race condition.
さらに、エージェントが制御している場合、チェックリストが完成した状態にある各メディアストリームのa = remote-candidates属性を含める必要があります。属性には、そのメディアストリームの各コンポーネントの有効なリストにある最高優先順位のノミネートされたペアのリモート候補が含まれています。制御エージェントがペアを選択する人種状態を回避する必要がありますが、更新されたオファーは、制御エージェントへの接続チェックを打ち負かします。この人種状態に関する詳細については、付録B.6を参照してください。
This section describes procedures for lite implementations for existing streams for which ICE is running.
このセクションでは、氷が走っている既存のストリームのライト実装の手順について説明します。
A lite implementation MUST include all of its candidates for each component of each media stream in an a=candidate attribute in any subsequent offer. These candidates are formed identically to the procedures for initial offers, as described in Section 4.2.
Liteの実装には、各メディアストリームの各コンポーネントのすべての候補者を、後続のオファーにA =候補の属性に含める必要があります。これらの候補者は、セクション4.2で説明されているように、最初のオファーの手順と同じように形成されます。
A lite implementation MUST NOT add additional host candidates in a subsequent offer. If an agent needs to offer additional candidates, it MUST restart ICE.
Liteの実装は、後続のオファーに追加のホスト候補を追加してはなりません。エージェントが追加の候補者を提供する必要がある場合は、氷を再起動する必要があります。
The username fragments, password, and implementation level MUST remain the same as used previously. If an agent needs to change one of these, it MUST restart ICE for that media stream.
ユーザー名のフラグメント、パスワード、および実装レベルは、以前に使用したものと同じままでなければなりません。エージェントがこれらのいずれかを変更する必要がある場合、そのメディアストリームのICEを再起動する必要があります。
If ICE has completed for a media stream, the default destination for that media stream MUST be set to the remote candidate of the candidate pair for that component in the valid list. For a lite implementation, there is always just a single candidate pair in the valid list for each component of a media stream. Additionally, the agent MUST include a candidate attribute for each default destination.
メディアストリームのICEが完成した場合、そのメディアストリームのデフォルトの宛先は、有効なリストのそのコンポーネントの候補ペアのリモート候補に設定する必要があります。Lite実装の場合、メディアストリームの各コンポーネントの有効なリストには常に単一の候補ペアがあります。さらに、エージェントは、デフォルトの各宛先に候補属性を含める必要があります。
Additionally, if the agent is controlling (which only happens when both agents are lite), the agent MUST include the a=remote-candidates attribute for each media stream. The attribute contains the remote candidates from the candidate pairs in the valid list (one pair for each component of each media stream).
さらに、エージェントが制御している場合（両方のエージェントがライトである場合にのみ発生する）、エージェントには各メディアストリームのa = remote-candidates属性を含める必要があります。属性には、有効なリストの候補ペアのリモート候補が含まれています（各メディアストリームの各コンポーネントに1つのペア）。
When receiving a subsequent offer within an existing session, an agent MUST reapply the verification procedures in Section 5.1 without regard to the results of verification from any previous offer/answer exchanges. Indeed, it is possible that a previous offer/answer exchange resulted in ICE not being used, but it is used as a consequence of a subsequent exchange.
既存のセッション内で後続のオファーを受け取る場合、エージェントは、以前のオファー/回答交換からの検証の結果に関係なく、セクション5.1の検証手順を再申請する必要があります。実際、以前のオファー/回答交換が氷が使用されなかった可能性がありますが、その後の交換の結果として使用されています。
If the offer contained a change in the a=ice-ufrag or a=ice-pwd attributes compared to the previous SDP from the peer, it indicates that ICE is restarting for this media stream. If all media streams are restarting, then ICE is restarting overall.
オファーに、ピアからの以前のSDPと比較してA = ICE-UFRAGまたはA = ICE-PWD属性の変更が含まれていた場合、このメディアストリームのICEが再起動していることを示します。すべてのメディアストリームが再起動している場合、ICEは全体的に再起動します。
If ICE is restarting for a media stream:
メディアストリームのために氷が再起動している場合：
o The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in the answer.
o エージェントは、回答のa = ice-ufragおよびa = ice-pwd属性を変更する必要があります。
o The agent MAY change its implementation level in the answer.
o エージェントは、回答の実装レベルを変更する場合があります。
An agent sets the rest of the fields in the SDP for this media stream as it would in an initial answer to this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.
エージェントは、このメディアストリームに対する最初の回答と同様に、このメディアストリームのSDPの残りのフィールドを設定します（セクション4.3を参照）。その結果、候補者のセットには、そのストリームの以前の候補者の一部、なし、またはすべてが含まれ、セクション4.1.1で説明されているように、まったく新しい候補のセットを含めることができます。
If the offer contains a new media stream, the agent sets the fields in the answer as if it had received an initial offer containing that media stream (see Section 4.3). This will cause ICE processing to begin for this media stream.
オファーに新しいメディアストリームが含まれている場合、エージェントはそのメディアストリームを含む最初のオファーを受け取ったかのように、回答にフィールドを設定します（セクション4.3を参照）。これにより、このメディアストリームで氷の処理が開始されます。
If an offer contains a media stream whose port is zero, the agent MUST NOT include any candidate attributes for that media stream in its answer and SHOULD NOT include any other ICE-related attributes defined in Section 15 for that media stream.
オファーにポートがゼロのメディアストリームが含まれている場合、エージェントはその回答にそのメディアストリームの候補属性を含めるべきではなく、そのメディアストリームのセクション15で定義されている他の氷関連属性を含めるべきではありません。
Unless the agent has detected an ICE restart from the offer, the username fragments, password, and implementation level MUST remain the same as used previously. If an agent needs to change one of these it MUST restart ICE for that media stream by generating an offer; ICE cannot be restarted in an answer.
エージェントがオファーからICEの再起動を検出しない限り、ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用したものと同じままでなければなりません。エージェントがこれらのいずれかを変更する必要がある場合、オファーを生成することにより、そのメディアストリームのICEを再起動する必要があります。回答で氷を再起動することはできません。
Additional behaviors depend on the state of ICE processing for that media stream.
追加の動作は、そのメディアストリームの氷加工の状態に依存します。
If ICE is running for a media stream, and the offer for that media stream lacked the remote-candidates attribute, the rules for construction of the answer are identical to those for the offerer as described in Section 9.1.2.1.
ICEがメディアストリームのために稼働している場合、およびそのメディアストリームのオファーにリモートキャンディデート属性が欠けている場合、回答の構築のルールは、セクション9.1.2.1で説明されているように、提供者のルールと同じです。
If ICE is Completed for a media stream, and the offer for that media stream lacked the remote-candidates attribute, the rules for construction of the answer are identical to those for the offerer as described in Section 9.1.2.2, except that the answerer MUST NOT include the a=remote-candidates attribute in the answer.
メディアストリームのためにICEが完成し、そのメディアストリームのオファーにリモートキャンディデート属性がない場合、回答の構築のルールは、セクション9.1.2.2で説明されているように提供者のルールと同じです。回答にa = remote-candidates属性を含めないでください。
A controlled agent will receive an offer with the a=remote-candidates attribute for a media stream when its peer has concluded ICE processing for that media stream. This attribute is present in the offer to deal with a race condition between the receipt of the offer, and the receipt of the Binding response that tells the answerer the candidate that will be selected by ICE. See Appendix B.6 for an explanation of this race condition. Consequently, processing of an offer with this attribute depends on the winner of the race.
制御されたエージェントは、ピアがそのメディアストリームのICE処理を締結したときに、メディアストリームのA = Remote-Candidates属性とのオファーを受け取ります。この属性は、オファーの受領と、氷によって選択される候補者に応答者に伝える拘束力のある応答の受領との間の人種条件に対処するための申し出に存在します。この人種状態の説明については、付録B.6を参照してください。その結果、この属性を使用したオファーの処理は、レースの勝者に依存します。
The agent forms a candidate pair for each component of the media stream by:
エージェントは、メディアストリームの各コンポーネントに対して候補ペアを形成します。
o Setting the remote candidate equal to the offerer's default destination for that component (e.g., the contents of the m and c lines for RTP, and the a=rtcp attribute for RTCP)
o リモート候補をそのコンポーネントの提供者のデフォルト宛先に等しく設定します（たとえば、RTPのMおよびCラインの内容、およびRTCPのA = RTCP属性）
o Setting the local candidate equal to the transport address for that same component in the a=remote-candidates attribute in the offer.
o オファー内のA = remote-candidates属性の同じコンポーネントの輸送アドレスに等しいローカル候補を設定します。
The agent then sees if each of these candidate pairs is present in the valid list. If a particular pair is not in the valid list, the check has "lost" the race. Call such a pair a "losing pair".
エージェントは、これらの候補ペアのそれぞれが有効なリストに存在するかどうかを確認します。特定のペアが有効なリストにない場合、チェックはレースを「失い」ました。そのようなペアを「負けペア」と呼びます。
The agent finds all the pairs in the check list whose remote candidates equal the remote candidate in the losing pair:
エージェントは、リモート候補者が負けペアのリモート候補に等しいチェックリスト内のすべてのペアを見つけます。
o If none of the pairs are In-Progress, and at least one is Failed, it is most likely that a network failure, such as a network partition or serious packet loss, has occurred. The agent SHOULD generate an answer for this media stream as if the remote-candidates attribute had not been present, and then restart ICE for this stream.
o ペアが進行中であり、少なくとも1つが失敗していない場合、ネットワークパーティションや重大なパケット損失などのネットワーク障害が発生した可能性が最も高いです。エージェントは、このメディアストリームに対する回答を生成し、まるでリモートキャンディデート属性が存在していないかのように、このストリームのICEを再起動する必要があります。
o If at least one of the pairs is In-Progress, the agent SHOULD wait for those checks to complete, and as each completes, redo the processing in this section until there are no losing pairs.
o 少なくとも1つのペアが進行中である場合、エージェントはそれらのチェックが完了するのを待つ必要があり、それぞれが完了したら、ペアを失うことがなくなるまでこのセクションの処理をやり直します。
Once there are no losing pairs, the agent can generate the answer. It MUST set the default destination for media to the candidates in the remote-candidates attribute from the offer (each of which will now be the local candidate of a candidate pair in the valid list). It MUST include a candidate attribute in the answer for each candidate in the remote-candidates attribute in the offer.
ペアを失うことがなくなったら、エージェントは答えを生成できます。メディアのデフォルトの宛先を、オファーからリモートキャンディデート属性の候補者に設定する必要があります（それぞれが有効なリストの候補ペアのローカル候補になります）。オファーのリモートキャンディデート属性の各候補者の回答に候補属性を含める必要があります。
If the received offer contains the remote-candidates attribute for a media stream, the agent forms a candidate pair for each component of the media stream by: o Setting the remote candidate equal to the offerer's default destination for that component (e.g., the contents of the m and c lines for RTP, and the a=rtcp attribute for RTCP).
受信オファーにメディアストリームのリモートキャンディデート属性が含まれている場合、エージェントは次のようにメディアストリームの各コンポーネントに対して候補ペアを形成します。RTPのMおよびCライン、およびRTCPのA = RTCP属性）。
o Setting the local candidate equal to the transport address for that same component in the a=remote-candidates attribute in the offer.
o オファー内のA = remote-candidates属性の同じコンポーネントの輸送アドレスに等しいローカル候補を設定します。
It then places those candidates into the Valid list for the media stream. The state of ICE processing for that media stream is set to Completed.
次に、これらの候補者をメディアストリームの有効なリストに入れます。そのメディアストリームの氷加工の状態は、完了するように設定されています。
Furthermore, if the agent believed it was controlling, but the offer contained the remote-candidates attribute, both agents believe they are controlling. In this case, both would have sent updated offers around the same time. However, the signaling protocol carrying the offer/answer exchanges will have resolved this glare condition, so that one agent is always the 'winner' by having its offer received before its peer has sent an offer. The winner takes the role of controlled, so that the loser (the answerer under consideration in this section) MUST change its role to controlled. Consequently, if the agent was going to send an updated offer since, based on the rules in Section 8.2.2, it was controlling, it no longer needs to.
さらに、エージェントがそれが制御されていると信じていたが、オファーにはリモートキャンディデート属性が含まれていた場合、両方のエージェントは自分が制御していると信じています。この場合、どちらも同じ時期に更新されたオファーを送信していました。ただし、オファー/回答の交換を運ぶシグナルプロトコルは、このまぶしさの状態を解決するため、1人のエージェントは、ピアがオファーを送信する前にオファーを受け取ることで常に「勝者」になります。勝者はコントロールされた役割を担っているため、敗者（このセクションで検討中の回答者）がその役割を制御に変更する必要があります。その結果、セクション8.2.2のルールに基づいて、エージェントが更新されたオファーを送信する場合、それは制御していましたが、もはや必要ありません。
Besides the potential role change, change in the Valid list, and state changes, the construction of the answer is performed identically to the construction of an offer as described in Section 9.1.3.
潜在的な役割の変更、有効なリストの変更、および状態の変更に加えて、回答の構築は、セクション9.1.3で説明されているように、オファーの構築と同じように実行されます。
The agent MUST remember the highest-priority nominated pairs in the Valid list for each component of the media stream, called the previous selected pairs, prior to the restart. The agent will continue to send media using these pairs, as described in Section 11.1. Once these destinations are noted, the agent MUST flush the valid and check lists, and then recompute the check list and its states as described in Section 5.7.
エージェントは、再起動前に、以前の選択したペアと呼ばれるメディアストリームの各コンポーネントの有効なリストに最高優先権の指名ペアを覚えておく必要があります。セクション11.1で説明されているように、エージェントはこれらのペアを使用してメディアを送信し続けます。これらの宛先が記録されたら、エージェントは有効なリストとチェックリストをフラッシュし、セクション5.7で説明したようにチェックリストとその状態を再計算する必要があります。
If the offer/answer exchange added a new media stream, the agent MUST create a new check list for it (and an empty Valid list to start of course), as described in Section 5.7.
オファー/回答の交換が新しいメディアストリームを追加した場合、エージェントはセクション5.7で説明されているように、新しいチェックリスト（およびもちろん開始するための空の有効なリスト）を作成する必要があります。
If the offer/answer exchange removed a media stream, or an answer rejected an offered media stream, an agent MUST flush the Valid list for that media stream. It MUST terminate any STUN transactions in progress for that media stream. An agent MUST remove the check list for that media stream and cancel any pending ordinary checks for it.
オファー/回答の交換がメディアストリームを削除した場合、または回答が提供されたメディアストリームを拒否した場合、エージェントはそのメディアストリームの有効なリストをフラッシュする必要があります。そのメディアストリームの進行中のスタントランザクションを終了する必要があります。エージェントは、そのメディアストリームのチェックリストを削除し、保留中の通常のチェックをキャンセルする必要があります。
The valid list is not affected by an updated offer/answer exchange unless ICE is restarting.
有効なリストは、ICEが再起動しない限り、更新されたオファー/回答交換の影響を受けません。
If an agent is in the Running state for that media stream, the check list is updated (the check list is irrelevant if the state is completed). To do that, the agent recomputes the check list using the procedures described in Section 5.7. If a pair on the new check list was also on the previous check list, and its state was Waiting, In-Progress, Succeeded, or Failed, its state is copied over. Otherwise, its state is set to Frozen.
エージェントがそのメディアストリームの実行状態にある場合、チェックリストが更新されます（状態が完了した場合、チェックリストは無関係です）。そのために、エージェントはセクション5.7で説明されている手順を使用してチェックリストを再構成します。新しいチェックリストのペアも前のチェックリストに載っていて、その状態が待機していた、進行中、成功した、または失敗した場合、その状態はコピーされます。それ以外の場合、その状態は凍結するように設定されています。
If none of the check lists are active (meaning that the pairs in each check list are Frozen), the full-mode agent sets the first pair in the check list for the first media stream to Waiting, and then sets the state of all other pairs in that check list for the same component ID and with the same foundation to Waiting as well.
チェックリストのいずれもアクティブでない場合（各チェックリストのペアが凍結されていることを意味します）、フルモードエージェントは最初のメディアストリームのチェックリストの最初のペアを待ってから、他のすべての状態を設定します同じコンポーネントIDのチェックリストのペアと、同じ基盤も待っています。
Next, the agent goes through each check list, starting with the highest-priority pair. If a pair has a state of Succeeded, and it has a component ID of 1, then all Frozen pairs in the same check list with the same foundation whose component IDs are not 1 have their state set to Waiting. If, for a particular check list, there are pairs for each component of that media stream in the Succeeded state, the agent moves the state of all Frozen pairs for the first component of all other media streams (and thus in different check lists) with the same foundation to Waiting.
次に、エージェントは各チェックリストを通過し、最高優先度のペアから始めます。ペアに成功の状態があり、1のコンポーネントIDがある場合、コンポーネントIDが1つないコンポーネントIDが状態を待っているのと同じ基盤と同じチェックリストにあるすべての冷凍ペアがあります。特定のチェックリストには、後続の状態にそのメディアストリームの各コンポーネントのペアがある場合、エージェントは他のすべてのメディアストリームの最初のコンポーネント（したがって異なるチェックリスト）のすべての冷凍ペアの状態を移動します。同じ基盤を待っています。
If ICE is restarting for a media stream, the agent MUST start a new Valid list for that media stream. It MUST remember the pairs in the previous Valid list for each component of the media stream, called the previous selected pairs, and continue to send media there as described in Section 11.1. The state of ICE processing for each media stream MUST change to Running, and the state of ICE processing MUST change to Running.
ICEがメディアストリームのために再起動している場合、エージェントはそのメディアストリームの新しい有効なリストを開始する必要があります。以前の選択したペアと呼ばれるメディアストリームの各コンポーネントの前の有効なリストのペアを覚えておく必要があり、セクション11.1で説明されているようにそこにメディアを送信し続けます。各メディアストリームの氷加工の状態は、実行に変更する必要があり、氷加工の状態は実行に変更する必要があります。
All endpoints MUST send keepalives for each media session. These keepalives serve the purpose of keeping NAT bindings alive for the media session. These keepalives MUST be sent regardless of whether the media stream is currently inactive, sendonly, recvonly, or sendrecv, and regardless of the presence or value of the bandwidth attribute. These keepalives MUST be sent even if ICE is not being utilized for the session at all. The keepalive 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 agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). An agent can determine that its peer supports ICE by the presence of a=candidate attributes for each media session. If the peer does not support ICE, the choice of a packet format for keepalives is a matter of local implementation. A format that allows packets to easily be sent in the absence of actual media content is RECOMMENDED. Examples of formats that readily meet this goal are RTP No-Op [NO-OP-RTP], and in cases where both sides support it, RTP comfort noise [RFC3389]. If the peer doesn't support any formats that are particularly well suited for keepalives, an agent SHOULD send RTP packets with an incorrect version number, or some other form of error that would cause them to be discarded by the peer.
すべてのエンドポイントは、各メディアセッションにキープライブを送信する必要があります。これらのキープライブは、メディアセッションのためにナットバインディングを生かし続ける目的に役立ちます。これらのキープライブは、メディアストリームが現在非アクティブであるか、センドンリー、レコボンリー、またはsendrecvであるか、および帯域幅属性の存在または価値に関係なく送信する必要があります。これらのキープライブは、氷がセッションに使用されていない場合でも、送信する必要があります。KeepAliveは、ピアによってサポートされている形式を使用して送信する必要があります。ICEエンドポイントは、UDPストリームのスタンベースのキンコール性を可能にするため、エージェントが完全なICEの実装であり、ICE（ライトまたはフル）をサポートするピアと通信している場合は、スタンキープライブを使用する必要があります。エージェントは、各メディアセッションにA =候補の属性が存在することにより、ピアがICEをサポートすることを判断できます。ピアがICEをサポートしていない場合、KeepAlives用のパケット形式の選択はローカルの実装の問題です。実際のメディアコンテンツがないときにパケットを簡単に送信できるようにする形式が推奨されます。この目標を容易に満たす形式の例は、RTP NO-OP [NO-OP-RTP]であり、双方がそれをサポートする場合、RTP Comfort Noise [RFC3389]。ピアがKeepaliveに特に適したフォーマットをサポートしていない場合、エージェントはRTPパケットを誤ったバージョン番号、またはピアによって破棄する他の形式のエラーを送信する必要があります。
If there has been no packet sent on the candidate pair ICE is using for a media component for Tr seconds (where packets include those defined for the component (RTP or RTCP) and previous keepalives), an agent MUST generate a keepalive on that pair. Tr SHOULD be configurable and SHOULD have a default of 15 seconds. Tr MUST NOT be configured to less than 15 seconds. Alternatively, 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.
候補ペアICEに送信されたパケットがTR秒（パケットが含まれているパケット（RTPまたはRTCP）および以前のKeepAlives）が含まれている場合、エージェントはそのペアにキープライブを生成する必要があります。TRは構成可能であり、デフォルトの15秒を持つ必要があります。TRを15秒未満に設定してはなりません。あるいは、エージェントが介在するNATの結合寿命を発見する動的な方法を持っている場合、その値を使用してtrを決定できます。より制御されたネットワーキング環境にICEを展開する管理者は、環境で可能な限り長い期間にTRを設定する必要があります。
If 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 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 media. 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がKeepaliveに使用されている場合、スタン結合表示が使用されます[RFC5389]。適応症は、認証メカニズムを利用してはなりません。非gultiplexingを支援するために指紋属性を含める必要がありますが、他の属性を含めるべきではありません。Nat Bindingsを生かし続けるためだけに使用されます。結合表示は、メディアに使用されているのと同じローカルおよびリモート候補を使用して送信されます。バインディングの適応症はKeepAlivesに使用されますが、エージェントも接続チェックを受けるために準備する必要があります。接続チェックが受信された場合、[RFC5389]で説明されているように応答が生成されますが、それ以外の場合はICE処理に影響はありません。
An agent MUST begin the keepalive processing once ICE has selected candidates for usage with media, or media begins to flow, whichever happens first. Keepalives end once the session terminates or the media stream is removed.
エージェントは、ICEがメディアで使用する候補者を選択した場合、またはメディアが最初に起こった方も、メディアが流れ始めると、KeepAlive処理を開始する必要があります。セッションが終了するか、メディアストリームが削除されると、キープライブが終了します。
Procedures for sending media differ for full and lite implementations.
メディアを送信するための手順は、完全な実装とライトの実装に対して異なります。
Agents always send media using a candidate pair, called the selected candidate pair. An agent will send media to the remote candidate in the selected pair (setting the destination address and port of the packet equal to that remote candidate), and will send it from the local candidate of the selected pair. When the local candidate is server or peer reflexive, media is originated from the base. Media sent from a relayed candidate is sent from the base through that TURN server, using procedures defined in [RFC5766].
エージェントは、選択した候補ペアと呼ばれる候補ペアを使用して常にメディアを送信します。エージェントは、選択したペアのリモート候補にメディアを送信し（そのリモート候補と等しいパケットの宛先アドレスとポートを設定します）、選択したペアのローカル候補から送信します。ローカル候補がサーバーまたはピア反射である場合、メディアはベースから生まれます。[RFC5766]で定義されている手順を使用して、リレーした候補から送信されたメディアは、そのターンサーバーを介してベースから送信されます。
If the local candidate is a relayed candidate, it is RECOMMENDED that an agent create 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].
ローカル候補が中継候補である場合、エージェントがリモート候補に向かってターンサーバー上にチャネルを作成することをお勧めします。これは、[RFC5766]のセクション11で定義されているチャネル作成手順を使用して行われます。
The selected pair for a component of a media stream is:
メディアストリームのコンポーネントの選択されたペアは次のとおりです。
o empty if the state of the check list for that media stream is Running, and there is no previous selected pair for that component due to an ICE restart
o そのメディアストリームのチェックリストの状態が実行されている場合は空になり、アイスの再起動のためにそのコンポーネントに対して以前に選択されたペアがない場合
o equal to the previous selected pair for a component of a media stream if the state of the check list for that media stream is Running, and there was a previous selected pair for that component due to an ICE restart
o そのメディアストリームのチェックリストの状態が実行されている場合、メディアストリームのコンポーネントに対して以前の選択したペアに等しく、アイス再起動のためにそのコンポーネントに対して以前の選択されたペアがありました
o equal to the highest-priority nominated pair for that component in the valid list if the state of the check list is Completed
o チェックリストの状態が完了した場合、有効なリスト内のそのコンポーネントの最高優先順位の指名ペアに等しい
If the selected pair for at least one component of a media stream is empty, an agent MUST NOT send media for any component of that media stream. If the selected pair for each component of a media stream has a value, an agent MAY send media for all components of that media stream.
メディアストリームの少なくとも1つのコンポーネントの選択されたペアが空である場合、エージェントはそのメディアストリームのコンポーネントに対してメディアを送信してはなりません。メディアストリームの各コンポーネントの選択されたペアに値がある場合、エージェントはそのメディアストリームのすべてのコンポーネントに対してメディアを送信できます。
Note that the selected pair for a component of a media stream may not equal the default pair for that same component from the most recent offer/answer exchange. When this happens, the selected pair is used for media, not the default pair. When ICE first completes, if the selected pairs aren't a match for the default pairs, the controlling agent sends an updated offer/answer exchange to remedy this disparity. However, until that updated offer arrives, there will not be a match. Furthermore, in very unusual cases, the default candidates in the updated offer/answer will not be a match.
メディアストリームのコンポーネントに選択したペアは、最新のオファー/回答交換の同じコンポーネントのデフォルトペアに等しくない場合があることに注意してください。これが発生すると、選択したペアはデフォルトペアではなく、メディアに使用されます。ICEが最初に完了すると、選択したペアがデフォルトのペアと一致しない場合、制御エージェントはこの格差を改善するために更新されたオファー/回答交換を送信します。ただし、更新されたオファーが到着するまで、試合はありません。さらに、非常に珍しい場合、更新されたオファー/回答のデフォルトの候補者は一致しません。
A lite implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream. Once that happens, the agent MAY begin sending media packets. To do that, it sends media 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 local candidate.
Liteの実装は、そのメディアストリームの各コンポーネントの候補ペアを含む有効なリストができるようになるまで、メディアを送信してはなりません。それが起こると、エージェントはメディアパケットの送信を開始する場合があります。そのために、ペア内のリモート候補にメディアを送信します（そのリモート候補と等しいパケットの宛先アドレスとポートを設定します）、地元の候補者から送信します。
ICE has interactions with jitter buffer adaptation mechanisms. An RTP stream can begin using one candidate, and switch to another one, though this happens rarely with ICE. The newer candidate may result in RTP packets taking a different path through the network -- one with different delay characteristics. As discussed below, agents are encouraged to re-adjust jitter buffers when there are changes in source or destination address of media packets. Furthermore, many audio codecs use the marker bit to signal the beginning of a talkspurt, for the purposes of jitter buffer adaptation. For such codecs, it is RECOMMENDED that the sender set the marker bit [RFC3550] when an agent switches transmission of media from one candidate pair to another.
ICEには、ジッターバッファ適応メカニズムとの相互作用があります。RTPストリームは1つの候補の使用を開始し、別の候補に切り替えることができますが、これは氷ではめったに起こりません。新しい候補者は、RTPパケットがネットワークを介して異なるパスを取ることになる場合があります - 異なる遅延特性を持つもの。以下で説明するように、メディアパケットのソースまたは宛先アドレスに変更がある場合、エージェントはジッターバッファを再調整することをお勧めします。さらに、多くのオーディオコーデックはマーカービットを使用して、ジッターバッファーの適応を目的として、Talkspurtの開始を知らせます。このようなコーデックの場合、エージェントが候補ペアから別の候補ペアにメディアの送信を切り替えるときに、送信者がマーカービット[RFC3550]を設定することをお勧めします。
ICE implementations MUST be prepared to receive media on each component on any candidates provided for that component in the most recent offer/answer exchange (in the case of RTP, this would include both RTP and RTCP if candidates were provided for both).
ICEの実装は、最新のオファー/回答交換でそのコンポーネントに提供された候補者の各コンポーネントのメディアを受信するために準備する必要があります（RTPの場合、これには両方に候補者が提供された場合、RTPとRTCPの両方が含まれます）。
It is RECOMMENDED that, when an agent receives an RTP packet with a new source or destination IP address for a particular media stream, that the agent re-adjust its jitter buffers.
特定のメディアストリームの新しいソースまたは宛先IPアドレスを備えたRTPパケットをエージェントに受信する場合、エージェントがジッターバッファを再調整することをお勧めします。
RFC 3550 [RFC3550] describes an algorithm in Section 8.2 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 media streams switch between candidates. An agent will be able to determine that a media stream is from the same peer as a consequence of the STUN exchange that proceeds media transmission. Thus, if there is a change in source transport address, but the media packets come from the same peer agent, this SHOULD NOT be treated as an SSRC collision.
RFC 3550 [RFC3550]は、同期ソース（SSRC）の衝突とループを検出するためのセクション8.2のアルゴリズムを説明しています。これらのアルゴリズムは、同じSSRCを使用して異なるソーストランスポートアドレスを表示することに部分的に基づいています。ただし、ICEを使用すると、メディアストリームが候補者間を切り替えると、そのような変更が発生することがあります。エージェントは、メディアストリームがメディアの伝達を進めるスタン交換の結果と同じピアからのものであると判断できます。したがって、ソーストランスポートアドレスに変更がありますが、メディアパケットが同じピアエージェントからのものである場合、これはSSRC衝突として扱われるべきではありません。
ICE requires a series of STUN-based connectivity checks to take place between endpoints. These checks start from the answerer on generation of its answer, and start from the offerer when it receives the answer. These checks can take time to complete, and as such, the selection of messages to use with offers and answers can affect perceived user latency. Two latency figures are of particular interest. These are the post-pickup delay and the post-dial delay. The post-pickup delay refers to the time between when a user "answers the phone" and when any speech they utter can be delivered to the caller. The post-dial delay refers to the time between when a user enters the destination address for the user and ringback begins as a consequence of having successfully started ringing the phone of the called party.
ICEには、エンドポイント間で一連のスタンベースの接続チェックが必要です。これらのチェックは、その回答の生成時に回答者から始まり、答えを受け取ったときに提供者から始まります。これらのチェックは完了するのに時間がかかる場合があり、そのため、オファーや回答で使用するメッセージの選択は、認識されたユーザーの遅延に影響を与える可能性があります。2つのレイテンシー数値が特に興味深いです。これらは、ピックアップ後遅延とダイヤル後の遅延です。ピックアップ後の遅延とは、ユーザーが「電話に応答する」時と、発信者に発声されるスピーチを伝えることができる時間を指します。ダイヤル後の遅延とは、ユーザーがユーザーの宛先アドレスに入力してからリングバックの宛先アドレスを入力するまでの間の時間を指します。
Two cases can be considered -- one where the offer is present in the initial INVITE and one where it is in a response.
2つのケースを考慮することができます。1つは最初の招待状にオファーが存在する場合、もう1つは応答しています。
To reduce post-dial delays, it is RECOMMENDED that the caller begin gathering candidates prior to actually sending its initial INVITE. This can be started upon user interface cues that a call is pending, such as activity on a keypad or the phone going offhook.
ダイヤル後の遅延を減らすには、実際に最初の招待を送信する前に、発信者が候補者の収集を開始することをお勧めします。これは、キーパッドでのアクティビティやオフフックになる電話など、通話が保留中のユーザーインターフェイスの手がかりから開始できます。
If an offer is received in an INVITE request, the answerer SHOULD begin to gather its candidates on receipt of the offer and then generate an answer in a provisional response once it has completed that process. ICE requires that a provisional response with an SDP be transmitted reliably. This can be done through the existing Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or through an optimization that is specific to ICE. With this optimization, provisional responses containing an SDP answer that begins ICE processing for one or more media streams can be sent reliably without RFC 3262. To do this, the agent retransmits the provisional response with the exponential backoff timers described in RFC 3262. Retransmits MUST cease on receipt of a STUN Binding request for one of the media streams signaled in that SDP (because receipt of a Binding request indicates the offerer has received the answer) or on transmission of the answer in a 2xx response. If the peer agent is lite, there will never be a STUN Binding request. In such a case, the agent MUST cease retransmitting the 18x after sending it four times (ICE will actually work even if the peer never receives the 18x; however, experience has shown that sending it is important for middleboxes and firewall traversal). If no Binding request is received prior to the last retransmit, the agent does not consider the session terminated. Despite the fact that the provisional response will be delivered reliably, the rules for when an agent can send an updated offer or answer do not change from those specified in RFC 3262. Specifically, if the INVITE contained an offer, the same answer appears in all of the 1xx and in the 2xx response to the INVITE. Only after that 2xx has been sent can an updated offer/answer exchange occur. This optimization SHOULD NOT be used if both agents support PRACK. Note that the optimization is very specific to provisional response carrying answers that start ICE processing; it is not a general technique for 1xx reliability.
招待状のリクエストでオファーを受け取った場合、応答者は、オファーの受領時に候補者を集め始め、そのプロセスを完了したら暫定的な回答で回答を生成する必要があります。ICEでは、SDPを使用した暫定的な反応を確実に送信する必要があります。これは、既存の暫定応答承認（PRACK）メカニズム[RFC3262]またはICEに固有の最適化を通じて行うことができます。この最適化により、1つ以上のメディアストリームの氷加工を開始するSDP回答を含む暫定的な応答は、RFC 3262なしで確実に送信できます。そのSDPで合図されたメディアストリームの1つのスタンバインディングリクエストの受領を停止します（バインディングリクエストの受領は、提供者が回答を受け取ったことを示します）ピアエージェントがライトの場合、スタンバインドリクエストは決してありません。そのような場合、エージェントは4回送信した後、18倍の再送信をやめなければなりません（ピアが18倍も受け取らない場合でも、実際には氷は機能します。最後の再送信の前に拘束力のあるリクエストが受信されない場合、エージェントはセッションが終了したとは考えていません。暫定的な対応が確実に配信されるという事実にもかかわらず、エージェントが更新されたオファーまたは回答を送信できる場合のルールは、RFC 3262で指定されたものから変更されない。1xxの招待への2xx応答。その2xxが送信された後にのみ、更新されたオファー/回答交換が発生する可能性があります。両方のエージェントがプラックをサポートしている場合、この最適化は使用しないでください。最適化は、氷の処理を開始する回答を運ぶ暫定的な応答に非常に固有であることに注意してください。1XXの信頼性の一般的な手法ではありません。
Alternatively, an agent MAY delay sending an answer until the 200 OK; however, this results in a poor user experience and is NOT RECOMMENDED.
あるいは、エージェントは200 OKまで回答の送信を遅らせることがあります。ただし、これによりユーザーエクスペリエンスが低下し、推奨されません。
Once the answer has been sent, the agent SHOULD begin its connectivity checks. Once candidate pairs for each component of a media stream enter the valid list, the answerer can begin sending media on that media stream.
回答が送信されたら、エージェントは接続チェックを開始する必要があります。メディアストリームの各コンポーネントの候補ペアが有効なリストを入力すると、Answererはそのメディアストリームでメディアの送信を開始できます。
However, prior to this point, any media that needs to be sent towards the caller (such as SIP early media [RFC3960]) MUST NOT be transmitted. For this reason, implementations SHOULD delay alerting the called party until candidates for each component of each media stream have entered the valid list. In the case of a PSTN gateway, this would mean that the setup message into the PSTN is delayed until this point. Doing this increases the post-dial delay, but has the effect of eliminating 'ghost rings'. Ghost rings are cases where the called party hears the phone ring, picks up, but hears nothing and cannot be heard. This technique works without requiring support for, or usage of, preconditions [RFC3312], since it's a localized decision. It also has the benefit of guaranteeing that not a single packet of media will get clipped, so that post-pickup delay is zero. If an agent chooses to delay local alerting in this way, it SHOULD generate a 180 response once alerting begins.
ただし、この点より前に、発信者に送信する必要があるメディア（SIPアーリーメディア[RFC3960]など）を送信してはなりません。このため、実装は、各メディアストリームの各コンポーネントの候補者が有効なリストに入力するまで、呼び出された当事者への警告を遅らせるはずです。PSTNゲートウェイの場合、これは、PSTNへのセットアップメッセージがこの時点まで遅延することを意味します。これを行うと、ダイヤル後の遅延が増加しますが、「ゴーストリング」を排除する効果があります。ゴーストリングは、呼び出されたパーティーが電話の指輪を聞き、拾い上げますが、何も聞こえず、聞こえない場合です。この手法は、ローカライズされた決定であるため、前提条件[RFC3312]のサポートまたは使用を必要とせずに機能します。また、メディアの1つのパケットがクリップされないことを保証するという利点があります。そのため、ポストピックアップの遅延はゼロです。エージェントがこの方法でローカルアラートを遅らせることを選択した場合、警告が始まると180の応答が生成されるはずです。
In addition to uses where the offer is in an INVITE, and the answer is in the provisional and/or 200 OK response, ICE works with cases where the offer appears in the response. In such cases, which are common in third party call control [RFC3725], ICE agents SHOULD generate their offers in a reliable provisional response (which MUST utilize RFC 3262), and not alert the user on receipt of the INVITE. The answer will arrive in a PRACK. This allows for ICE processing to take place prior to alerting, so that there is no post-pickup delay, at the expense of increased call setup delays. Once ICE completes, the callee can alert the user and then generate a 200 OK when they answer. The 200 OK would contain no SDP, since the offer/answer exchange has completed.
オファーが招待状である場合、および答えは暫定的および/または200 OK応答にある使用に加えて、ICEは応答が応答に表示されるケースで動作します。このような場合、サードパーティのコールコントロール[RFC3725]で一般的な場合、ICEエージェントは信頼できる暫定的な対応（RFC 3262を利用する必要がある）でオファーを生成し、招待状の受領時にユーザーに警告しません。答えはプラックに届きます。これにより、警告の前に氷の処理が行われるため、コールセットアップの遅延が増加して、ピックアップ後の遅延はありません。ICEが完了すると、Calleeはユーザーに警告し、回答すると200 OKを生成できます。200 OKには、オファー/回答の交換が完了しているため、SDPが含まれません。
Alternatively, agents MAY place the offer in a 2xx instead (in which case the answer comes in the ACK). When this happens, the callee will alert the user on receipt of the INVITE, and the ICE exchanges will take place only after the user answers. This has the effect of reducing call setup delay, but can cause substantial post-pickup delays and media clipping.
あるいは、代わりにエージェントが2xxにオファーを配置する場合があります（この場合、答えはACKにあります）。これが発生すると、Calleeは招待状の受領時にユーザーに警告し、ユーザーが回答した後にのみICE交換が行われます。これは、コールのセットアップ遅延を削減する効果がありますが、大幅なピックアップ後の遅延やメディアクリッピングを引き起こす可能性があります。
[RFC5768] specifies a SIP option tag and media feature tag for usage with ICE. ICE implementations using SIP SHOULD support this specification, which uses a feature tag in registrations to facilitate interoperability through signaling intermediaries.
[RFC5768]は、ICEで使用するためのSIPオプションタグとメディア機能タグを指定します。SIPを使用したICEの実装は、この仕様をサポートする必要があります。この仕様は、登録の機能タグを使用して、シグナリング仲介者を介した相互運用性を促進します。
ICE interacts very well with forking. Indeed, ICE fixes some of the problems associated with forking. Without ICE, when a call forks and the caller receives multiple incoming media streams, it cannot determine which media stream corresponds to which callee.
アイスはフォーキングと非常によく相互作用します。実際、ICEはフォークに関連する問題のいくつかを修正します。ICEがなければ、コールフォークと発信者が複数の着信メディアストリームを受信すると、どのメディアストリームがどのCalleeに対応するかを決定することはできません。
With ICE, this problem is resolved. The connectivity checks which occur prior to transmission of media carry username fragments, which in turn are correlated to a specific callee. Subsequent media packets that arrive on the same candidate pair as the connectivity check will be associated with that same callee. Thus, the caller can perform this correlation as long as it has received an answer.
氷の場合、この問題は解決されます。メディアの送信前に発生する接続チェックは、ユーザー名フラグメントを持ち、特定のCalleeと相関しています。接続性チェックと同じ候補ペアに到着する後続のメディアパケットは、その同じCalleeに関連付けられます。したがって、発信者は、回答を受け取っている限り、この相関を実行できます。
Quality of Service (QoS) preconditions, which are defined in RFC 3312 [RFC3312] and RFC 4032 [RFC4032], apply only to the transport addresses listed as the default targets for media in an offer/answer.
RFC 3312 [RFC3312]およびRFC 4032 [RFC4032]で定義されているサービス品質（QOS）前提条件は、オファー/回答のメディアのデフォルトのターゲットとしてリストされている輸送アドレスにのみ適用されます。
If ICE changes the transport address where media is received, this change is reflected in an updated offer that changes the default destination for media to match ICE's selection. As such, it appears like any other re-INVITE would, and is fully treated in RFCs 3312 and 4032, which apply without regard to the fact that the destination for media is changing due to ICE negotiations occurring "in the background".
ICEがメディアが受信された場所で輸送アドレスを変更した場合、この変更は、メディアの選択に合わせてデフォルトの目的地を変更する更新されたオファーに反映されます。このように、それは他の再インバイトのように見え、RFCS 3312および4032で完全に扱われています。これは、「バックグラウンドで」氷の交渉が発生するためにメディアの目的地が変化しているという事実に関係なく適用されます。
Indeed, an agent SHOULD NOT indicate that QoS preconditions have been met until the checks have completed and selected the candidate pairs to be used for media.
実際、エージェントは、チェックが完了し、メディアに使用される候補ペアを選択するまでQoSの前提条件が満たされたことを示すべきではありません。
ICE also has (purposeful) interactions with connectivity preconditions [SDP-PRECON]. Those interactions are described there. Note that the procedures described in Section 12.1 describe their own type of "preconditions", albeit with less functionality than those provided by the explicit preconditions in [SDP-PRECON].
ICEには、接続性の前提条件との（目的のある）相互作用もあります[SDP Precon]。これらの相互作用について説明します。セクション12.1で説明されている手順は、[SDP-Precon]の明示的な前提条件で提供されるものよりも機能性が低いにもかかわらず、独自のタイプの「前処理」を説明していることに注意してください。
ICE works with Flows I, III, and IV as described in [RFC3725]. Flow I works without the controller supporting or being aware of ICE. Flow IV will work as long as the controller passes along the ICE attributes without alteration. Flow II is fundamentally incompatible with ICE; each agent will believe itself to be the answerer and thus never generate a re-INVITE.
ICEは、[RFC3725]に記載されているように、Flows I、III、およびIVで動作します。フロー私は、コントローラーが氷をサポートしたり、認識したりせずに動作します。Flow IVは、コントローラーが変更せずに氷の属性に沿って通過する限り機能します。Flow IIは、氷と基本的に互換性がありません。各エージェントは、自分自身が応答者であると信じているため、再入力を生成することはありません。
The flows for continued operation, as described in Section 7 of RFC 3725, require additional behavior of ICE implementations to support. In particular, if an agent receives a mid-dialog re-INVITE that contains no offer, it MUST restart ICE for each media stream and go through the process of gathering new candidates. Furthermore, that list of candidates SHOULD include the ones currently being used for media.
RFC 3725のセクション7で説明されているように、継続的な動作のフローは、サポートするために氷の実装の追加の動作が必要です。特に、エージェントがオファーが含まれていないミッドダイアログの再入手を受け取った場合、各メディアストリームのICEを再起動し、新しい候補者を収集するプロセスを経る必要があります。さらに、その候補者のリストには、現在メディアに使用されているものを含める必要があります。
RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT) Semantics for the SDP grouping framework, and RFC 4092 [RFC4092], its usage with SIP, define a mechanism for indicating that an agent can support both IPv4 and IPv6 for a media stream, and it does so by including two m lines, one for v4 and one for v6. This is similar to ICE, which allows for an agent to indicate multiple transport addresses using the candidate attribute. However, ANAT relies on static selection to pick between choices, rather than a dynamic connectivity check used by ICE.
RFC 4091 [RFC4091]、SDPグループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス、およびRFC 4092 [RFC4092]、SIPでの使用は、エージェントがメディアのIPV4とIPv6の両方をサポートできることを示すメカニズムを定義します。ストリーミング、および2つのmラインを含めることで、1つはV4用、もう1つはV6用です。これはICEに似ており、エージェントが候補属性を使用して複数の輸送アドレスを示すことができます。ただし、ANATは、ICEが使用する動的接続チェックではなく、選択の選択に依存しています。
This specification deprecates RFC 4091 and RFC 4092. Instead, agents wishing to support dual stack will utilize ICE.
この仕様はRFC 4091とRFC 4092を非難します。代わりに、デュアルスタックをサポートしたいエージェントはICEを利用します。
This specification makes very specific choices about how both agents in a session coordinate to arrive at the set of candidate pairs that are selected for media. 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.
この仕様は、セッション内の両方のエージェントがメディアに選択された候補ペアのセットに到達する方法について非常に具体的な選択をします。将来の仕様は、タイマーの調整などの単純な変更であろうと、優先アルゴリズムの改良のような大きな変更であろうと、これらのアルゴリズムを変更したいと予想されます。このような変更が行われると、セッションで2つのエージェント間で相互運用性を提供することが重要です。
First, ICE provides the a=ice-options SDP attribute. Each extension or change to ICE is associated with a token. When an agent supporting such an extension or change generates an offer or an answer, it MUST include the token for that extension in this attribute. This allows each side to know what the other side is doing. This attribute MUST NOT be present if the agent doesn't support any ICE extensions or changes.
まず、ICEはA = Ice-Options SDP属性を提供します。各拡張または氷への変更は、トークンに関連付けられています。そのような拡張機能または変更をサポートするエージェントがオファーまたは回答を生成する場合、この属性にその拡張機能のトークンを含める必要があります。これにより、両側は反対側が何をしているのかを知ることができます。エージェントが氷の拡張または変更をサポートしない場合、この属性は存在しないでください。
At this time, no IANA registry or registration procedures are defined for these option tags. At time of writing, it is unclear whether ICE changes and extensions will be sufficiently common to warrant a registry.
現時点では、これらのオプションタグに対してIANAレジストリまたは登録手順は定義されていません。執筆時点では、レジストリを保証するのに氷の変化と拡張機能が十分に一般的であるかどうかは不明です。
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 regular nomination procedure described in Section 8 eliminates some of the tight coordination by delegating the selection algorithm completely to the controlling agent. Consequently, when a controlling agent is communicating with a peer that supports options it doesn't know about, the agent MUST run a regular nomination algorithm. When regular nomination is used, 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. Consequently, any future ICE enhancements MUST preserve triggered checks.
相互運用性を達成する上での合併症の1つは、ICEが両方のエージェントで実行されている分散アルゴリズムに依存して、合意された候補ペアに収束することです。2つのエージェントが異なるアルゴリズムを実行している場合、同じ候補ペアで収束を保証することは困難です。セクション8で説明されている定期的な指名手順は、選択アルゴリズムを完全に制御エージェントに委任することにより、厳しい調整の一部を排除します。その結果、制御エージェントが知らないオプションをサポートするピアと通信している場合、エージェントは通常のノミネートアルゴリズムを実行する必要があります。通常の指名が使用されると、両方のエージェントが異なるペア優先順位付けアルゴリズムを使用している場合でも、ICEは完全に収束します。このような収束のキーの1つは、トリガーされたチェックです。これにより、ノミネートされたペアが両方のエージェントによって検証されることが保証されます。その結果、将来の氷の強化は、トリガーされたチェックを保持する必要があります。
ICE is also extensible to other media streams beyond RTP, and for transport protocols beyond UDP. Extensions to ICE for non-RTP media 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の1から始まるコンポーネントIDを割り当てる必要があります。新しい輸送プロトコルの仕様は、氷加工のさまざまなステップがUDPとどのように異なるかを定義する必要があります。
This specification defines seven new SDP attributes -- the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", and "ice-options" attributes.
この仕様では、「候補」、「リモートキャンディデート」、「アイスライト」、「アイスミスマッチ」、「アイスウフラグ」、「アイス-PWD」、「アイスオプション」の7つの新しいSDP属性を定義します。属性。
The candidate attribute is a media-level attribute only. It contains a transport address for a candidate that can be used for connectivity checks.
候補属性は、メディアレベルの属性のみです。接続のチェックに使用できる候補者の輸送アドレスが含まれています。
The syntax of this attribute is defined using Augmented BNF as defined in RFC 5234 [RFC5234]:
この属性の構文は、RFC 5234 [RFC5234]で定義されている拡張BNFを使用して定義されます。
candidate-attribute = "candidate" ":" foundation SP component-id SP
transport SP
priority SP
connection-address SP ;from RFC 4566
port ;port from RFC 4566
SP cand-type
[SP rel-addr]
[SP rel-port]
*(SP extension-att-name SP
extension-att-value)
foundation = 1*32ice-char
component-id = 1*5DIGIT
transport = "UDP" / transport-extension
transport-extension = token ; from RFC 3261
priority = 1*10DIGIT
cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr = "raddr" SP connection-address
rel-port = "rport" SP port
extension-att-name = byte-string ;from RFC 4566
extension-att-value = byte-string
ice-char = ALPHA / DIGIT / "+" / "/"
This grammar encodes the primary information about a candidate: its IP address, port and transport protocol, and its properties: the foundation, component ID, priority, type, and related transport address:
この文法は、候補者に関する主要な情報をエンコードします：そのIPアドレス、ポートおよび輸送プロトコル、およびそのプロパティ：基礎、コンポーネントID、優先度、タイプ、および関連する輸送アドレス：
<connection-address>: is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing.
<Connection-Address>：RFC 4566 [RFC4566]から取得されます。これは候補のIPアドレスであり、IPv4アドレス、IPv6アドレス、および完全資格のドメイン名（FQDNS）を許可します。このフィールドを解析する場合、エージェントは、その値にコロンの存在によってIPv4アドレスとIPv6アドレスを区別できます - コロンの存在はIPv6を示します。エージェントは、サポートまたは認識されていないIPアドレスバージョンを持つ候補を含む候補の行を無視する必要があります。IPアドレスを使用する必要がありますが、IPアドレスの代わりにFQDNを使用できます。その場合、A =候補属性にFQDNを含むオファーまたは回答を受信すると、FQDNは最初にAAAAレコードを使用してDNSで検索されます（エージェントがIPv6をサポートしていると仮定）。Aを使用してIPv4のみをサポートします。DNSクエリが複数のIPアドレスを返す場合、1つが選択され、残りの氷加工に使用されます。
<port>: is also taken from RFC 4566 [RFC4566]. It is the port of the candidate.
<port>：RFC 4566 [RFC4566]からも採取されています。候補者の港です。
<transport>: indicates the transport protocol for the candidate. This specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE, such as TCP or the Datagram Congestion Control Protocol (DCCP) [RFC4340].
<Transport>：候補者の輸送プロトコルを示します。この仕様はUDPのみを定義します。ただし、TCPやDatagram混雑制御プロトコル（DCCP）[RFC4340]など、将来の輸送プロトコルをICEで使用できるようにするための拡張性が提供されます。
<foundation>: is composed of 1 to 32 <ice-char>s. It is an identifier that is equivalent for two candidates that are of the same type, share the same base, and come from the same STUN server. The foundation is used to optimize ICE performance in the Frozen algorithm.
<Foundation>：1〜32 <Ice-char>で構成されています。これは、同じタイプの2つの候補者と同じベースを共有し、同じStunサーバーから来る2つの候補と同等の識別子です。基礎は、冷凍アルゴリズムの氷の性能を最適化するために使用されます。
<component-id>: is a positive integer between 1 and 256 that identifies the specific component of the media stream for which this is a candidate. It MUST start at 1 and MUST increment by 1 for each component of a particular candidate. For media streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2. Other types of media streams that require multiple components MUST develop specifications that define the mapping of components to component IDs. See Section 14 for additional discussion on extending ICE to new media streams.
<component-id>：これが候補であるメディアストリームの特定のコンポーネントを識別する1〜256の間の正の整数です。特定の候補者の各コンポーネントに対して1から開始し、1件ずつ増加する必要があります。RTPに基づくメディアストリームの場合、実際のRTPメディアの候補者には1のコンポーネントIDが必要であり、RTCPの候補者には2のコンポーネントIDが必要です。コンポーネントIDへのコンポーネント。氷を新しいメディアストリームに拡張することに関する追加の議論については、セクション14を参照してください。
<priority>: is a positive integer between 1 and (2**31 - 1).
<Priority>：1〜（2 ** 31-1）の間の正の整数です。
<cand-type>: encodes the type of candidate. This specification defines the values "host", "srflx", "prflx", and "relay" for host, server reflexive, peer reflexive, and relayed candidates, respectively. The set of candidate types is extensible for the future.
<Cand-Type>：候補のタイプをエンコードします。この仕様は、ホスト、サーバー反射、ピアリフレクション、リレー候補の値「ホスト」、「SRFLX」、「PRFLX」、および「リレー」の値を定義します。候補タイプのセットは、将来に拡張可能です。
<rel-addr> and <rel-port>: convey transport addresses related to the candidate, useful for diagnostics and other purposes. <rel-addr> and <rel-port> MUST be present for server reflexive, peer reflexive, and relayed candidates. If a candidate is server or peer reflexive, <rel-addr> and <rel-port> are equal to the base for that server or peer reflexive candidate. If the candidate is relayed, <rel-addr> and <rel-port> is equal to the mapped address in the Allocate response that provided the client with that relayed candidate (see Appendix B.3 for a discussion of its purpose). If the candidate is a host candidate, <rel-addr> and <rel-port> MUST be omitted.
<RER-ADDR>および<REL-PORT>：診断やその他の目的に役立つ候補者に関連する輸送アドレスを伝えます。<REL-ADDR>および<REL-PORT>は、サーバーの反射、ピア反射、および中継された候補者に存在する必要があります。候補者がサーバーまたはピア反射である場合、<RER-ADDR>および<RER-PORT>は、そのサーバーまたはピア反射候補のベースに等しくなります。候補者が中継されている場合、<RER-ADDR>および<RER-PORT>は、クライアントにその中継された候補を提供した割り当て応答のマップされたアドレスに等しくなります（その目的の議論については、付録B.3を参照）。候補者がホスト候補である場合、<RER-ADDR>および<RER-PORT>を省略する必要があります。
The candidate attribute can itself be extended. The grammar allows for new name/value pairs to be added at the end of the attribute. An implementation MUST ignore any name/value pairs it doesn't understand.
候補属性自体を拡張できます。文法により、属性の最後に新しい名前/値のペアを追加できます。実装は、わからない名前/値ペアを無視する必要があります。
The syntax of the "remote-candidates" attribute is defined using Augmented BNF as defined in RFC 5234 [RFC5234]. The remote-candidates attribute is a media-level attribute only.
「リモートキャンディデート」属性の構文は、RFC 5234 [RFC5234]で定義されている拡張BNFを使用して定義されます。リモートキャンディデート属性は、メディアレベルの属性のみです。
remote-candidate-att = "remote-candidates" ":" remote-candidate
0*(SP remote-candidate)
remote-candidate = component-ID SP connection-address SP port
The attribute contains a connection-address and port for each component. The ordering of components is irrelevant. However, a value MUST be present for each component of a media stream. This attribute MUST be included in an offer by a controlling agent for a media stream that is Completed, and MUST NOT be included in any other case.
属性には、各コンポーネントの接続アドレスとポートが含まれています。コンポーネントの順序は無関係です。ただし、メディアストリームの各コンポーネントに値が存在する必要があります。この属性は、完成したメディアストリームの管理エージェントによるオファーに含める必要があり、他のケースに含めてはなりません。
The syntax of the "ice-lite" and "ice-mismatch" attributes, both of which are flags, is:
どちらもフラグです。
ice-lite = "ice-lite" ice-mismatch = "ice-mismatch"
Ice-lite = "Ice-lite" Ice-mismatch = "Ice-mismatch"
"ice-lite" is a session-level attribute only, and indicates that an agent is a lite implementation. "ice-mismatch" is a media-level attribute only, and when present in an answer, indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute.
「Ice-Lite」はセッションレベルの属性のみであり、エージェントがLiteの実装であることを示します。「アイスミスマッチ」はメディアレベルの属性のみであり、回答に存在する場合、対応する候補属性を持たないメディアコンポーネントのデフォルトの宛先がオファーが届いたことを示します。
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment and password used by ICE for message integrity. Their syntax is:
「ICE-UFRAG」および「ICE-PWD」属性は、メッセージの整合性のためにICEで使用されるユーザー名フラグメントとパスワードを伝えます。それらの構文は次のとおりです。
ice-pwd-att = "ice-pwd" ":" password
ice-ufrag-att = "ice-ufrag" ":" ufrag
password = 22*256ice-char
ufrag = 4*256ice-char
The "ice-pwd" and "ice-ufrag" attributes can appear at either the session-level or media-level. When present in both, the value in the media-level takes precedence. Thus, the value at the session-level is effectively a default that applies to all media streams, unless overridden by a media-level value. Whether present at the session or media-level, there MUST be an ice-pwd and ice-ufrag attribute for each media stream. If two media streams have identical ice-ufrag's, they MUST have identical ice-pwd's.
「ICE-PWD」および「ICE-UFRAG」属性は、セッションレベルまたはメディアレベルのいずれかに表示されます。両方に存在する場合、メディアレベルの値が優先されます。したがって、セッションレベルの値は、メディアレベルの値によってオーバーライドされない限り、すべてのメディアストリームに適用されるデフォルトです。セッションに存在する場合でも、メディアレベルであれ、各メディアストリームにICE-PWDとICE-UFRAG属性がある必要があります。2つのメディアストリームに同一のICE-UFRAGがある場合、同一のICE-PWDが必要です。
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the beginning of a session. The ice-ufrag attribute MUST contain at least 24 bits of randomness, and the ice-pwd attribute MUST contain at least 128 bits of randomness. This means that the ice-ufrag attribute will be at least 4 characters long, and the ice-pwd at least 22 characters long, since the grammar for these attributes allows for 6 bits of randomness per character. The attributes MAY be longer than 4 and 22 characters, respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large upper limit allows for increased amounts of randomness to be added over time.
ICE-UFRAGおよびICE-PWD属性は、セッションの開始時にランダムに選択する必要があります。ICE-UFRAG属性には、少なくとも24ビットのランダム性を含める必要があり、ICE-PWD属性には少なくとも128ビットのランダム性を含める必要があります。これは、これらの属性の文法により、文字ごとに6ビットのランダム性を可能にするため、Ice-Ufrag属性の長さは少なくとも4文字、少なくとも22文字の長さ22文字になることを意味します。もちろん、属性はそれぞれ4文字と22文字より長くなる場合があります。もちろん、最大256文字です。上限により、実装のバッファーサイジングが可能になります。その大きな上限により、時間の経過とともにランダム性の量を増やすことができます。
The "ice-options" attribute is a session-level attribute. It contains a series of tokens that identify the options supported by the agent. Its grammar is:
「アイスオプション」属性は、セッションレベルの属性です。エージェントがサポートするオプションを識別する一連のトークンが含まれています。その文法は次のとおりです。
ice-options = "ice-options" ":" ice-option-tag
0*(SP ice-option-tag)
ice-option-tag = 1*ice-char
During the gathering phase of ICE (Section 4.1.1) and while ICE is performing connectivity checks (Section 7), an agent sends STUN and TURN transactions. These transactions are paced at a rate of one every Ta milliseconds, and utilize a specific RTO. This section describes how the values of Ta and RTO are computed. This computation depends on whether ICE is being used with a real-time media stream (such as RTP) or something else. When ICE is used for a stream with a known maximum bandwidth, the computation in Section 16.1 MAY be followed to rate-control the ICE exchanges. For all other streams, the computation in Section 16.2 MUST be followed.
氷の収集段階（セクション4.1.1）および氷が接続チェックを実行している間（セクション7）、エージェントはスタンとターントランザクションを送信します。これらのトランザクションは、1ミリ秒ごとに1つの速度でペースを合わせており、特定のRTOを利用しています。このセクションでは、TAとRTOの値がどのように計算されるかについて説明します。この計算は、アイスがリアルタイムメディアストリーム（RTPなど）または他の何かで使用されているかどうかに依存します。既知の最大帯域幅を持つストリームに氷が使用される場合、セクション16.1の計算に従って、氷交換を速度制御することができます。他のすべてのストリームについては、セクション16.2の計算に従う必要があります。
The values of RTO and Ta change during the lifetime of ICE processing. One set of values applies during the gathering phase, and the other, for connectivity checks.
RTOとTAの値は、氷加工の存続期間中に変化します。1つのセットの値は、収集フェーズ中に適用され、もう1つは接続チェックに適用されます。
The value of Ta SHOULD be configurable, and SHOULD have a default of:
TAの値は構成可能である必要があり、次のデフォルトを持つ必要があります。
For each media stream i:
各メディアストリームについて：
Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime
1
Ta = MAX (20ms, ------------------- )
k
----
\ 1
> ------
/ Ta_i
----
i=1
where k is the number of media streams. During the gathering phase, Ta is computed based on the number of media streams the agent has indicated in its offer or answer, and the RTP packet size and RTP ptime are those of the most preferred codec for each media stream. Once an offer and answer have been exchanged, the agent recomputes Ta to pace the connectivity checks. In that case, the value of Ta is based on the number of media streams that will actually be used in the session, and the RTP packet size and RTP ptime are those of the most preferred codec with which the agent will send.
ここで、Kはメディアストリームの数です。収集段階では、TAはエージェントがオファーまたは回答で示すメディアストリームの数に基づいて計算され、RTPパケットサイズとRTP Ptimeは、各メディアストリームで最も好ましいコーデックのものです。オファーと回答が交換されると、エージェントはTAを再構成して接続チェックをペースします。その場合、TAの値は、セッションで実際に使用されるメディアストリームの数に基づいており、RTPパケットサイズとRTP Ptimeは、エージェントが送信する最も好ましいコーデックのものです。
In addition, the retransmission timer for the STUN transactions, RTO, defined in [RFC5389], SHOULD be configurable and during the gathering phase, SHOULD have a default of:
さらに、[RFC5389]で定義されているSTUNトランザクションの再送信タイマーであるRTOは、構成可能であり、収集フェーズ中は次のデフォルトを持つ必要があります。
RTO = MAX (100ms, Ta * (number of pairs))
rto = max（100ms、ta *（ペア数））
where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers.
ペアの数は、スタンまたはターンサーバーを持つ候補者のペア数を指します。
For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of:
接続チェックの場合、RTOは構成可能であり、次のデフォルトを持つ必要があります。
RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))
where Num-Waiting is the number of checks in the check list in the Waiting state, and Num-In-Progress is the number of checks in the In-Progress state. Note that the RTO will be different for each transaction as the number of checks in the Waiting and In-Progress states change.
数字が待機状態のチェックリストのチェック数であり、進行中の数が進行中の状態のチェック数です。待機状態と進行中の状態のチェックの数が変更されるため、RTOはトランザクションごとに異なることに注意してください。
These formulas are aimed at causing STUN transactions to be paced at the same rate as media. This ensures that ICE will work properly under the same network conditions needed to support the media as well. See Appendix B.1 for additional discussion and motivations. Because of this pacing, it will take a certain amount of time to obtain all of the server reflexive and relayed candidates. Implementations should be aware of the time required to do this, and if the application requires a time budget, limit the number of candidates that are gathered.
これらの式は、メディアと同じ速度でスタントランザクションをペースにすることを目的としています。これにより、メディアをサポートするために必要な同じネットワーク条件の下でICEが適切に機能することが保証されます。追加の議論と動機については、付録B.1を参照してください。このペーシングのため、すべてのサーバーの反射と中継の候補者を得るのに一定の時間がかかります。実装はこれを行うのに必要な時間を認識し、アプリケーションに時間予算が必要な場合は、収集された候補者の数を制限します。
The formulas 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 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 sub-optimally, choosing lower-priority pairs over higher-priority pairs. Implementors should be aware of this consequence, but still should utilize the timer values described here.
フォーミュラは、再送信を実行する前にエージェントが単一の接続チェックごとに最初のパケットを送信する動作になります。これは、RTOの式で見ることができます（再送信間隔を表します）。これらの式は、n、実行されるチェックの数を拡張します。この結果、ICEは十分に一定の速度を維持しますが、パケットの損失により敏感になります。接続チェックのための最初のシングルパケットの損失は、そのペアが検証されるのに長い時間がかかる可能性があり、代わりに、より低い優先度チェック（ただし、パケット損失がなかったもの）ははるかに高い可能性が高くなります。最初に完了します。これにより、氷が最適に動作し、より優先順位のペアよりも優先順位のペアを選択します。実装者はこの結果に注意する必要がありますが、ここで説明するタイマーの値を利用する必要があります。
In cases where ICE is used to establish some kind of session that is not real time, and has no fixed rate associated with it that is known to work on the network in which ICE is deployed, Ta and RTO revert to more conservative values. Ta SHOULD be configurable, SHOULD have a default of 500 ms, and MUST NOT be configurable to be less than 500 ms.
氷がリアルタイムではないある種のセッションを確立するために使用され、ICEが展開されるネットワークで動作することが知られている固定レートがない場合、TAおよびRTOはより保守的な値に戻ります。TAは設定可能であり、デフォルトの500ミリ秒を持つ必要があり、500ミリ秒未満になるように構成できないようにしてください。
In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of:
さらに、STUNトランザクションの再送信タイマーであるRTOは、構成可能であり、収集段階では次のデフォルトを持つ必要があります。
RTO = MAX (500ms, Ta * (number of pairs))
rto = max（500ms、ta *（ペア数））
where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers.
ペアの数は、スタンまたはターンサーバーを持つ候補者のペア数を指します。
For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of:
接続チェックの場合、RTOは構成可能であり、次のデフォルトを持つ必要があります。
RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
The example is based on the simplified topology of Figure 8.
この例は、図8の単純化されたトポロジに基づいています。
+-----+
| |
|STUN |
| Srvr|
+-----+
|
+---------------------+
| |
| Internet |
| |
| |
+---------------------+
| |
| |
+---------+ |
| NAT | |
+---------+ |
| |
| |
| |
+-----+ +-----+
| | | |
| L | | R |
| | | |
+-----+ +-----+
Figure 8: Example Topology
図8：トポロジの例
Two agents, L and R, are using ICE. Both are full-mode ICE implementations and use aggressive nomination when they are controlling. Both agents have a single IPv4 address. For agent L, it is 10.0.1.1 in private address space [RFC1918], and for agent R, 192.0.2.1 on the public Internet. Both are configured with the same STUN server (shown in this example for simplicity, although in practice the agents do not need to use the same STUN server), which is listening for STUN Binding requests at an IP address of 192.0.2.2 and port 3478. TURN servers are not used in this example. Agent L is behind a NAT, and agent R is on the public Internet. The NAT has an endpoint independent mapping property and an address dependent filtering property. The public side of the NAT has an IP address of 192.0.2.3.
LとRの2つのエージェントがICEを使用しています。どちらもフルモードの氷の実装であり、制御するときに積極的な指名を使用します。両方のエージェントには、単一のIPv4アドレスがあります。エージェントLの場合、プライベートアドレススペース[RFC1918]で10.0.1.1、およびエージェントRの場合、パブリックインターネットでは192.0.2.1です。どちらも同じStunサーバーで構成されています（この例には簡単に示されていますが、実際にはエージェントは同じStunサーバーを使用する必要はありません）。これは、192.0.2.2およびポート3478のIPアドレスでスタンバインディングリクエストをリッスンしています。。この例では、ターンサーバーは使用されていません。エージェントLはNATの背後にあり、エージェントRはパブリックインターネット上にあります。NATには、エンドポイント独立マッピングプロパティとアドレス依存のフィルタリングプロパティがあります。NATのパブリックサイドのIPアドレスは192.0.2.3です。
To facilitate understanding, transport addresses are listed using variables that have mnemonic names. The format of the name is entity-type-seqno, where 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, and "PRIV" for transport addresses that are private. 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です。ここでは、エンティティはIPアドレスが輸送アドレスがオンになっているエンティティを指し、「L」、「R」、「スタン」、または「NAT」の1つです。このタイプは、公開されている輸送住所の「パブ」、プライベートの輸送アドレスの「PRIC」のいずれかです。最後に、SEQ-NOは、特定のエンティティ上の同じタイプの各輸送アドレスで異なるシーケンス番号です。各変数には、それぞれvarname.ipとvarname.portで示されるIPアドレスとポートがあります。ここで、Varnameは変数の名前です。
The STUN server has advertised transport address STUN-PUB-1 (which is 192.0.2.2:3478).
Stunサーバーには、Transport Address Stun-Pub-1（192.0.2.2:3478）が宣伝されています。
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.
コールフロー自体では、スタンメッセージにはいくつかの属性が注釈が付けられています。「s =」属性は、メッセージのソーストランスポートアドレスを示します。「d =」属性は、メッセージの宛先輸送アドレスを示します。「MA =」属性は、スタンバインド応答メッセージで使用され、マッピングされたアドレスを参照しています。「ユースキャンド」は、ユースキャンディデート属性の存在を意味します。
The call flow examples omit STUN authentication operations and RTCP, and focus on RTP for a single media stream between two full implementations.
コールフローの例は、スタン認証操作とRTCPを省略し、2つの完全な実装間の単一のメディアストリームのRTPに焦点を当てています。
L NAT STUN R
|RTP 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) Offer | | |
|------------------------------------------->|
| | | |RTP 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) answer | | |
|<-------------------------------------------|
| |(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 | | |
|USE-CAND | | |
|------------->| | |
| |(11) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |USE-CAND | |
| |---------------------------->|
| |(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 | | |
|<-------------| | |
|RTP flows | | |
| |(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 | |
| |---------------------------->|
| | | |RTP flows
Figure 9: Example Flow
図9：フローの例
First, agent L obtains a host candidate from its local IP address (not shown), and from that, sends a STUN Binding request to the STUN server to get a server reflexive candidate (messages 1-4). Recall that the NAT has the address and port independent mapping property. Here, it creates a binding of NAT-PUB-1 for this UDP request, and this becomes the server reflexive candidate for RTP.
最初に、エージェントLはローカルIPアドレスからホスト候補を取得し（表示していません）、それからSTUNサーバーにスタンバインディングリクエストを送信して、サーバー反射候補（メッセージ1-4）を取得します。NATにはアドレスとポートの独立マッピングプロパティがあることを思い出してください。ここでは、このUDP要求のためにNAT-PUB-1のバインディングを作成し、これがRTPのサーバー反射候補になります。
Agent L sets a type preference of 126 for the host candidate and 100 for the server reflexive. The local preference is 65535. Based on this, the priority of the host candidate is 2130706431 and for the server reflexive candidate is 1694498815. The host candidate is assigned a foundation of 1, and the server reflexive, a foundation of 2. It chooses its server reflexive candidate as the default candidate, and encodes it into the m and c lines. The resulting offer (message 5) looks like (lines folded for clarity):
エージェントLは、ホスト候補で126のタイプ優先を設定し、サーバーの反射で100を設定します。ローカル選好は65535です。これに基づいて、ホスト候補の優先順位は2130706431であり、サーバー反射候補の場合は1694498815です。デフォルトの候補としてのサーバー反射候補は、それをMおよびCラインにエンコードします。結果のオファー（メッセージ5）は（明確にするために折りたたまれた行）のように見えます。
v=0
o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
s=
c=IN IP4 $NAT-PUB-1.IP
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio $NAT-PUB-1.PORT RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ
host
a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ
srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT
The offer, with the variables replaced with their values, will look like (lines folded for clarity):
変数がその値に置き換えられたオファーは、（明確にするために折りたたまれた線）のように見えます。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
This offer is received at agent R. Agent R will obtain a host candidate, and from it, obtain a server reflexive candidate (messages 6-7). Since R is not behind a NAT, this candidate is identical to its host candidate, and they share the same base. It therefore discards this redundant candidate and ends up with a single host candidate. With identical type and local preferences as L, the priority for this candidate is 2130706431. It chooses a foundation of 1 for its single candidate. Its resulting answer looks like:
このオファーはエージェントRで受け取られます。エージェントRはホスト候補を取得し、そこからサーバー反射候補を取得します（メッセージ6-7）。RはNATの背後にないため、この候補者はホスト候補と同一であり、同じベースを共有しています。したがって、この冗長な候補者を破棄し、1人のホスト候補者になります。Lと同一のタイプとローカル設定では、この候補者の優先度は2130706431です。単一の候補者に対して1の基礎を選択します。その結果の答えは次のように見えます：
v=0
o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
s=
c=IN IP4 $R-PUB-1.IP
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio $R-PUB-1.PORT RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host
With the variables filled in:
変数が入力されています。
v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host
Since neither side indicated that it is lite, the agent that sent the offer that began ICE processing (agent L) becomes the controlling agent.
どちらの側もそれがライトであることを示していないため、氷加工を開始した申し出（エージェントL）を送信したエージェントが制御エージェントになりました。
Agents L and R both pair up the candidates. They both initially have two pairs. However, agent L will prune the pair containing its server reflexive candidate, resulting in just one. At agent L, this pair has a local candidate of $L_PRIV_1 and remote candidate of $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that an implementation would represent this as a 64-bit integer so as not to lose precision). At agent R, there are two pairs. The highest priority has a local candidate of $R_PUB_1 and remote candidate of $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and priority 3.63891E+18.
エージェントLとRは両方とも候補者をペアにします。両方とも最初に2つのペアを持っています。ただし、エージェントLは、サーバー反射候補を含むペアをプルーズし、1つだけになります。エージェントLでは、このペアは$ l_priv_1のローカル候補と$ r_pub_1のリモート候補を持ち、4.57566e 18の候補ペアの優先度があります（実装はこれを64ビット整数として表していることに注意してください。）。エージェントRには、2つのペアがあります。最優先事項は、$ r_pub_1のローカル候補と$ l_priv_1のリモート候補を持ち、4.57566e 18の優先度があり、2番目は$ r_pub_1のローカル候補と$ nat_pub_1および優先度3.63891e 18のリモート候補を持っています。
Agent R begins its connectivity check (message 9) for the first pair (between the two host candidates). Since R is the controlled agent for this session, the check omits the USE-CANDIDATE attribute. The host candidate from agent L is private and behind a NAT, and thus this check won't be successful, because the packet cannot be routed from R to L.
エージェントRは、最初のペアの接続チェック（メッセージ9）を開始します（2人のホスト候補者の間）。Rはこのセッションの制御エージェントであるため、チェックはユースキャンディデート属性を省略します。エージェントLのホスト候補はプライベートであり、NATの後ろであるため、パケットをRからLにルーティングできないため、このチェックは成功しません。
When agent L gets the answer, it performs its one and only connectivity check (messages 10-13). It implements the aggressive nomination algorithm, and thus includes a USE-CANDIDATE attribute in this check. Since the check succeeds, agent L creates a new pair, whose local candidate is from the mapped address in the Binding response (NAT-PUB-1 from message 13) and whose remote candidate is the destination of the request (R-PUB-1 from message 10). This is added to the valid list. In addition, it is marked as selected since the Binding request contained the USE-CANDIDATE attribute. Since there is a selected candidate in the Valid list for the one component of this media stream, ICE processing for this stream moves into the Completed state. Agent L can now send media if it so chooses.
エージェントLが答えを取得すると、1つの唯一の接続チェック（メッセージ10-13）を実行します。積極的なノミネートアルゴリズムを実装しているため、このチェックにはユースキャンディデート属性が含まれています。チェックが成功したため、エージェントLは新しいペアを作成します。そのローカル候補は、バインディング応答のマップされたアドレス（メッセージ13からのNAT-PUB-1）からのもので、リモート候補はリクエストの宛先です（R-Pub-1メッセージ10から）。これは有効なリストに追加されます。さらに、バインディングリクエストにはユースキャンディデート属性が含まれているため、選択されたとマークされています。このメディアストリームの1つのコンポーネントの有効なリストに選択された候補があるため、このストリームのICE処理は完成した状態に移動します。エージェントLが選択した場合、メディアを送信できるようになりました。
Soon after receipt of the STUN Binding request from agent L (message 11), agent R will generate its triggered check. This check happens to match the next one on its check list -- from its host candidate to agent L's server reflexive candidate. This check (messages 14-17) will succeed. Consequently, agent R constructs a new candidate pair using the mapped address from the response as the local candidate (R-PUB-1) and the destination of the request (NAT-PUB-1) as the remote candidate. This pair is added to the Valid list for that media stream. Since the check was generated in the reverse direction of a check that contained the USE-CANDIDATE attribute, the candidate pair is marked as selected. Consequently, processing for this stream moves into the Completed state, and agent R can also send media.
エージェントL（メッセージ11）からのスタンバインディングリクエストを受信してすぐに、エージェントRはそのトリガーチェックを生成します。このチェックは、ホスト候補からエージェントLのサーバー反射候補まで、そのチェックリストの次のチェックと一致します。このチェック（メッセージ14-17）が成功します。その結果、エージェントRは、ローカル候補（R-PUB-1）として応答のマップされたアドレスを使用して、リクエストの宛先（NAT-PUB-1）をリモート候補として使用して、新しい候補ペアを構築します。このペアは、そのメディアストリームの有効なリストに追加されます。チェックは、ユースキャンディデート属性を含むチェックの逆方向に生成されたため、候補ペアは選択されたとマークされます。その結果、このストリームの処理は完成した状態に移行し、エージェントRはメディアを送信することもできます。
There are several types of attacks possible in an ICE system. This section considers these attacks and their countermeasures. These countermeasures include:
ICEシステムには、いくつかの種類の攻撃が可能です。このセクションでは、これらの攻撃とそれらの対策を検討します。これらの対策には次のものが含まれます。
o Using ICE in conjunction with secure signaling techniques, such as SIPS.
o SIPなどの安全なシグナル伝達技術と組み合わせてICEを使用します。
o Limiting the total number of connectivity checks to 100, and optionally limiting the number of candidates they'll accept in an offer or answer.
o 接続チェックの総数を100に制限し、オプションまたは回答で受け入れる候補者の数をオプションで制限します。
An attacker might attempt to disrupt the STUN connectivity checks. Ultimately, all of these attacks fool an agent into thinking something incorrect about the results of the connectivity checks. 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.
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 media.
false有効：攻撃者は、エージェントのペアをだまして、候補者のペアが有効であると考えていない場合があります。これにより、エージェントはセッションを進めることができますが、メディアを受け取ることができません。
False Peer Reflexive Candidate: An attacker can cause an agent to discover a new peer reflexive candidate, when it shouldn't have. This can be used to redirect media streams to a Denial-of-Service (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 doesn't actually route to that agent (for example, by injecting a false peer reflexive candidate or false server reflexive candidate). It must then launch an attack that forces the agents to believe that this candidate is valid.
誤った候補者に対して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. 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, layer 2 network disruption, or other technique. If it doesn't do this, the success response will also reach the originator, alerting it to a possible attack. Fortunately, this attack is mitigated completely through the STUN short-term credential mechanism. The attacker needs to inject a fake response, and in order for this response to be processed, the attacker needs the password. If the offer/answer signaling is secured, the attacker will not have the password and its response will be discarded.
誤った無効な結果を強制するために、攻撃者は、エージェントの1人からの接続チェックが送信されるのを待たなければなりません。そうである場合、攻撃者は400などの回復不可能なエラー応答で偽の応答を注入する必要があります。ただし、候補者は実際に有効であるため、元の要求はピアエージェントに到達し、成功応答が発生する可能性があります。。攻撃者は、DOS攻撃、レイヤー2ネットワークの破壊、またはその他の手法を通じて、このパケットまたはその応答を強制する必要があります。これが行われない場合、成功応答は発信者にも届き、攻撃の可能性を警告します。幸いなことに、この攻撃は、スタンの短期資格情報メカニズムを通じて完全に軽減されます。攻撃者は偽の応答を注入する必要があり、この応答を処理するためには、攻撃者がパスワードを必要とします。オファー/回答のシグナルが確保されている場合、攻撃者はパスワードを持たず、その応答は破棄されます。
Forcing the fake valid result works in a similar way. The agent needs to wait for the Binding request from each agent, and inject a fake success response. The attacker won't need to worry about disrupting the actual response since, if the candidate is not valid, it presumably wouldn't be received anyway. However, like the fake invalid attack, this attack is mitigated by the STUN short-term credential mechanism in conjunction with a secure offer/answer exchange.
偽の有効な結果を強制することは、同様の方法で機能します。エージェントは、各エージェントからの拘束力のあるリクエストを待ち、偽の成功応答を注入する必要があります。攻撃者は、候補者が有効でない場合、とにかく受信されないため、実際の応答を混乱させることを心配する必要はありません。ただし、偽の無効な攻撃のように、この攻撃は、安全なオファー/回答交換と併せて、スタン短期資格メカニズムによって軽減されます。
Forcing the false peer reflexive candidate result can be done either with 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 must 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 offer/answer exchanges.
偽のピア反射候補の結果を強制することは、偽のリクエストまたは応答、またはリプレイで行うことができます。最初に偽のリクエストと応答のケースを検討します。攻撃者は、誤った候補者のソースIPアドレスとポートを持つ1人のエージェントに拘束力のあるリクエストを送信する必要があります。さらに、攻撃者は、他のエージェントからの拘束力のある要求を待ち、誤った候補を含むXORマップアドレス属性を使用して偽の応答を生成する必要があります。ここで説明した他の攻撃と同様に、この攻撃は、スタンメッセージの整合性メカニズムと安全なオファー/回答の交換によって軽減されます。
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 must also prevent the original request from reaching the remote agent, either by 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 will be sent to that false candidate. The attacker must then receive it and relay it towards the originator.
誤ったピア反射候補の結果をパケットリプレイで強制することは異なります。攻撃者は、エージェントの1人が小切手を送信するまで待ちます。この要求を傍受し、偽造ソースIPアドレスで他のエージェントにリプレイします。また、DOS攻撃を起動してパケットをドロップするか、レイヤー2メカニズムを使用してパケットを強制することにより、元のリクエストがリモートエージェントに届かないようにする必要があります。再生されたパケットは、他のエージェントで受信され、整合性チェックが通過するため、受け入れられます（整合性チェックは、ソースIPアドレスとポートをカバーすることはできません。その後、応答します。この応答には、虚偽の候補者とのXORマップアドレスが含まれ、その虚偽の候補者に送信されます。その後、攻撃者はそれを受け取り、オリジネーターに向かって中継する必要があります。
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. Injecting of fake requests or responses to achieve this goal is prevented using the integrity mechanisms of STUN and the offer/answer exchange. Thus, this attack can only be launched through replays. To do that, the attacker must intercept the check towards this false candidate, and replay it towards the other agent. Then, it must intercept the response and replay that back as well.
その後、他のエージェントは、その誤った候補に向けて接続チェックを開始します。この検証は成功する必要があります。これには、攻撃者が虚偽の候補者に対して虚偽の有効を強制する必要があります。この目標を達成するための偽のリクエストまたは応答を注入することは、スタンの整合性メカニズムとオファー/回答の交換を使用して防止されます。したがって、この攻撃はリプレイによってのみ起動できます。そのためには、攻撃者はこの誤った候補者にチェックを傍受し、他のエージェントにリプレイする必要があります。次に、応答を傍受し、それを再生する必要があります。
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 (for example, 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 SRTP is used [RFC3711], the attacker will not be able to play the media packets, but will only be able to discard them, effectively disabling the media stream for the call. 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 media stream, it's much easier to just disrupt it with the same mechanism, rather than attack ICE.
攻撃者自体が偽の候補者によって識別された場合、攻撃は調整しやすいです。ただし、SRTPを使用した場合[RFC3711]、攻撃者はメディアパケットを再生することはできませんが、それらを破棄することのみができ、コールのメディアストリームを効果的に無効にします。ただし、この攻撃では、エージェントがターゲットに到達するのをブロックするために、エージェントがパケットを破壊する必要があります。その場合、目標がメディアストリームを混乱させることである場合、氷を攻撃するのではなく、同じメカニズムでそれを混乱させる方がはるかに簡単です。
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エンドポイントは、スタンサーバーからサーバー反射候補を収集するためのスタンバインディングリクエストを使用します。これらのリクエストは決して認証されません。結果として、攻撃者がクライアントに誤ったサーバーの反射候補を提供するために採用できる多くの手法があります。
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 DNS-SEC is not required to address it.
o 攻撃者はDNSを妥協する可能性があり、DNSクエリがRogue Stunサーバーアドレスを返します。そのサーバーは、クライアントに偽のサーバー反射候補を提供できます。この攻撃はDNSセキュリティによって軽減されますが、DNS-SECは対処する必要はありません。
o An attacker that can observe STUN messages (such as an attacker on a shared network segment, like WiFi) can inject a fake response that is valid and will be accepted by the client.
o スタンメッセージ（WiFiのような共有ネットワークセグメントの攻撃者など）を観察できる攻撃者は、有効でクライアントに受け入れられる偽の応答を挿入できます。
o An attacker can compromise a STUN server by means of a virus, and cause it to send responses with incorrect mapped addresses.
o 攻撃者は、ウイルスを使用してスタンサーバーを妥協し、マッピングされたアドレスが誤っていることで応答を送信させることができます。
A false mapped address learned by these attacks will be used as a server reflexive candidate in the ICE exchange. For this candidate to actually be used for media, the attacker must also 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 offerer, answerer, nor attacker), since it requires attacking the checks generated by each agent in the session, and is prevented by SRTP if it identifies the attacker themself.
これらの攻撃によって学んだ誤ったマッピングされたアドレスは、氷交換のサーバー反射候補として使用されます。この候補者が実際にメディアに使用されるためには、攻撃者は接続チェックを攻撃する必要があり、特に虚偽の候補者に対して虚偽の有効を強制する必要があります。セッションで各エージェントによって生成された小切手を攻撃する必要があるため、誤ったアドレスが第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 media. 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人の候補者がいる場合、スタン接続チェック自体は、メディアの交換に使用できるピア反射候補を提供します。通常、ピア反射候補は、サーバー反射候補よりも好まれます。そのため、スタンアドレスの収集のみに対する攻撃は、通常、セッションにまったく影響を与えません。
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.
攻撃者は、中継された候補者の集まりを混乱させようとする可能性があり、クライアントに誤った中継候補があると信じるように強制します。ターンサーバーとの交換は、長期的な資格情報を使用して認証されます。その結果、偽の応答またはリクエストの注入は機能しません。さらに、バインディングリクエストとは異なり、ソースIPアドレスとポートがリレー候補を提供するために使用されていないため、リクエストの割り当てリクエストは、修正されたソースIPアドレスとポートで攻撃を再生する影響を受けにくくなります。
However, TURN servers are susceptible to DNS attacks, or to viruses aimed at the TURN server, for purposes of turning it into a zombie or rogue server. These attacks can be mitigated by DNS-SEC and through good box and software security on TURN servers.
ただし、ターンサーバーは、ゾンビまたはローグサーバーに変換するため、DNS攻撃、またはターンサーバーを対象としたウイルスの影響を受けやすいです。これらの攻撃は、DNS-SECによって、およびターンサーバーの優れたボックスおよびソフトウェアセキュリティを介して軽減できます。
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 must launch a false valid on a false candidate, per above, which is a very difficult attack to coordinate.
攻撃者がクライアントに誤った中継候補を信じさせた場合でも、接続性チェックにより、そのような候補者が成功した場合にのみ使用されます。したがって、攻撃者は、上記の虚偽の候補者に対して虚偽の有効な有効なものを起動する必要があります。これは、調整するのが非常に難しい攻撃です。
An attacker that can modify or disrupt the offer/answer exchanges themselves can readily launch a variety of attacks with ICE. They could direct media to a target of a DoS attack, they could insert themselves into the media stream, and so on. These are similar to the general security considerations for offer/answer exchanges, and the security considerations in RFC 3264 [RFC3264] apply. These require techniques for message integrity and encryption for offers and answers, which are satisfied by the SIPS mechanism [RFC3261] when SIP is used. As such, the usage of SIPS with ICE is RECOMMENDED.
オファー/回答の交換自体を変更または混乱させることができる攻撃者は、氷でさまざまな攻撃を容易に開始できます。彼らはメディアをDOS攻撃のターゲットに向けることができ、メディアストリームに自分自身を挿入することもできます。これらは、提供/回答交換の一般的なセキュリティに関する考慮事項に似ており、RFC 3264 [RFC3264]のセキュリティ上の考慮事項が適用されます。これらには、SIPが使用されているときにSIPSメカニズム[RFC3261]によって満たされる、オファーと回答のメッセージの整合性と暗号化の手法が必要です。そのため、氷でSIPの使用をお勧めします。
In addition to attacks where the attacker is a third party trying to insert fake offers, answers, or stun messages, there are several attacks possible with ICE when the attacker is an authenticated and valid participant in the ICE exchange.
攻撃者が偽のオファー、回答、またはスタンメッセージを挿入しようとするサードパーティである攻撃に加えて、攻撃者がICE交換の認証された有効な参加者である場合、ICEで可能ないくつかの攻撃があります。
The voice hammer attack is an amplification attack. In this attack, the attacker initiates sessions to other agents, and maliciously includes the IP address and port of a DoS target as the destination for media traffic signaled in the SDP. This causes substantial amplification; a single offer/answer exchange can create a continuing flood of media packets, possibly at high rates (consider video sources). This attack is not specific to ICE, but ICE can help provide remediation.
音声ハンマー攻撃は増幅攻撃です。この攻撃では、攻撃者は他のエージェントとのセッションを開始し、悪意を持ってDOSターゲットのIPアドレスとポートをSDPで合図したメディアトラフィックの宛先として含めます。これにより、大幅な増幅が発生します。単一のオファー/回答交換は、おそらく高いレートでメディアパケットの継続的な洪水を作成できます（ビデオソースを考慮してください）。この攻撃は氷に固有のものではありませんが、氷は修復を提供するのに役立ちます。
Specifically, if ICE is used, the agent receiving the malicious SDP will first perform connectivity checks to the target of media before sending media there. If this target is a third-party host, the checks will not succeed, and media is never sent.
具体的には、ICEを使用する場合、悪意のあるSDPを受け取るエージェントは、最初にメディアを送信する前にメディアのターゲットに接続チェックを実行します。このターゲットがサードパーティのホストである場合、チェックは成功せず、メディアは送信されません。
Unfortunately, ICE doesn't help if its not used, in which case an attacker could simply send the offer without the ICE parameters. However, in environments where the set of clients is known, and is limited to ones that support ICE, the server can reject any offers or answers that don't indicate ICE support.
残念ながら、ICEは使用されていない場合は役に立ちません。その場合、攻撃者は単にICEパラメーターなしでオファーを送信できます。ただし、クライアントのセットが既知であり、ICEをサポートするクライアントに限定されている環境では、サーバーはICEサポートを示さないオファーや回答を拒否できます。
The STUN amplification attack is similar to the voice hammer. However, instead of voice packets being directed to the target, STUN connectivity checks are directed to the target. The attacker sends an offer with a large number of candidates, say, 50. The answerer receives the offer, and starts its checks, which are directed at the target, and consequently, never generate a response. The answerer will start a new connectivity check every Ta ms (say, Ta=20ms). 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 media would be sent, and the STUN packets persist only briefly, until ICE fails for the session. Nonetheless, this is an amplification mechanism.
スタン増幅攻撃は、音声ハンマーに似ています。ただし、ターゲットに向けられる音声パケットの代わりに、スタン接続チェックはターゲットに向けられます。攻撃者は、多数の候補者、たとえば50のオファーを送信します。応答者はオファーを受け取り、ターゲットに向けられたチェックを開始し、その結果、応答を生成することはありません。回答者は、すべてのTA MS（たとえば、TA = 20ms）に新しい接続チェックを開始します。ただし、多数の候補者のために、再送信タイマーは多数に設定されています。結果として、パケットは1つのTAミリ秒の間隔で送信され、その後増加する間隔で送信されます。したがって、Stunはメディアが送信されるよりも速いレートでパケットを送信することはなく、Stunパケットはセッションで故障するまで短時間しか持続しません。それにもかかわらず、これは増幅メカニズムです。
It is impossible to eliminate the amplification, but the volume can be reduced through a variety of heuristics. Agents SHOULD limit the total number of connectivity checks they perform to 100. Additionally, agents MAY limit the number of candidates they'll accept in an offer or answer.
増幅を排除することは不可能ですが、さまざまなヒューリスティックによってボリュームを減らすことができます。エージェントは、実行する接続チェックの総数を100に制限する必要があります。さらに、エージェントは、オファーまたは回答で受け入れる候補者の数を制限する場合があります。
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:
多くの場合、これらの種類の攻撃を回避したいプロトコルは、次のメッセージを送信する前にイニシエーターに応答を待つように強制されます。ただし、氷の場合、これは不可能です。次の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 should be sent at the next opportunity, while in the former case, no further checks should be sent.
2番目のケースでは、次の機会に別のチェックを送信する必要がありますが、前者の場合は、それ以上のチェックを送信する必要はありません。
Application Layer Gateways (ALGs) are functions present in a NAT device that inspect the contents of packets and modify them, in order to facilitate NAT traversal for application protocols. Session Border Controllers (SBCs) are close cousins of ALGs, but are less transparent since they actually exist as application layer SIP intermediaries. ICE has interactions with SBCs and ALGs.
アプリケーションレイヤーゲートウェイ（ALG）は、アプリケーションプロトコルのNATトラバーサルを容易にするために、パケットの内容を検査して変更するNATデバイスに存在する関数です。セッションボーダーコントローラー（SBC）は、ALGSの緊密ないとこですが、アプリケーションレイヤーSIP仲介業者として実際に存在するため、透明度が低くなります。ICEには、SBCおよびALGとの相互作用があります。
If an ALG is SIP aware but not ICE aware, ICE will work through it as long as the ALG correctly modifies the SDP. A correct ALG implementation behaves as follows:
アルグがSIPを認識しているがICEの認識ではない場合、ALGがSDPを正しく変更する限り、ICEはそれを通過します。正しいALG実装は次のように動作します。
o The ALG does not modify the m and c lines or the rtcp attribute if they contain external addresses.
o ALGは、外部アドレスが含まれている場合、MおよびCラインまたはRTCP属性を変更しません。
o If the m and c lines contain internal addresses, the modification depends on the state of the ALG:
o MおよびCラインに内部アドレスが含まれている場合、変更はアルグの状態に依存します。
If the ALG already has a binding established that maps an external port to an internal IP address and port matching the values in the m and c lines or rtcp attribute, the ALG uses that binding instead of creating a new one.
ALGには、外部ポートを内部IPアドレスにマッピングし、MおよびCラインまたはRTCP属性の値と一致するポートをマップするバインディングがすでに確立されている場合、ALGは新しいものを作成する代わりにそのバインディングを使用します。
If the ALG does not already have a binding, it creates a new one and modifies the SDP, rewriting the m and c lines and rtcp attribute.
アルグにまだバインディングがない場合、新しいものを作成し、SDPを変更し、MおよびCラインとRTCP属性を書き換えます。
Unfortunately, many ALGs are known to work poorly in these corner cases. ICE does not try to work around broken ALGs, as this is outside the scope of its functionality. ICE can help diagnose these conditions, which often show up as a mismatch between the set of candidates and the m and c lines and rtcp attributes. The ice-mismatch attribute is used for this purpose.
残念ながら、多くのアルグは、これらのコーナーケースでは不十分に機能することが知られています。ICEは、壊れたアルグを回避しようとはしません。これは機能の範囲外であるためです。ICEは、これらの状態の診断に役立ちます。これらの条件は、候補のセットとMおよびCラインとRTCP属性の間の不一致として表示されることがよくあります。この目的のために、氷のない属性が使用されます。
ICE works best through ALGs when the signaling is run over TLS. This prevents the ALG from manipulating the SDP messages and interfering with ICE operation. Implementations that are expected to be deployed behind ALGs SHOULD provide for TLS transport of the SDP.
ICEは、シグナリングがTLSを介して実行されるときにALGを介して最適に機能します。これにより、ALGがSDPメッセージを操作し、氷操作を妨害することを防ぎます。アルグの背後に展開されると予想される実装は、SDPのTLS輸送を提供する必要があります。
If an SBC is SIP aware but not ICE aware, the result depends on the behavior of the SBC. If it is acting as a proper Back-to-Back User Agent (B2BUA), the SBC will remove any SDP attributes it doesn't understand, including the ICE attributes. Consequently, the call will appear to both endpoints as if the other side doesn't support ICE. This will result in ICE being disabled, and media flowing through the SBC, if the SBC has requested it. If, however, the SBC passes the ICE attributes without modification, yet modifies the default destination for media (contained in the m and c lines and rtcp attribute), this will be detected as an ICE mismatch, and ICE processing is aborted for the call. It is outside of the scope of ICE for it to act as a tool for "working around" SBCs. If one is present, ICE will not be used and the SBC techniques take precedence.
SBCがSIPを認識しているがICE認識ではない場合、結果はSBCの動作に依存します。適切な連続したユーザーエージェント（B2BUA）として機能している場合、SBCは、ICE属性を含む、理解できないSDP属性を削除します。したがって、反対側が氷をサポートしていないかのように、コールは両方のエンドポイントに表示されます。これにより、SBCが要求した場合、氷が無効になり、SBCを介してメディアが流れるようになります。ただし、SBCが変更なしでICE属性を渡すが、メディアのデフォルトの宛先（MおよびCラインおよびRTCP属性に含まれる）を変更する場合、これは氷の不一致として検出され、コール用に氷加工が中止されます。氷の範囲外で、SBCSを「動作させる」ためのツールとして機能するためです。存在する場合、氷は使用されず、SBC技術が優先されます。
This specification defines four new attributes, PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
この仕様では、4つの新しい属性、優先順位、使用能力、アイスコントロール、およびアイスコントロールを定義します。
The PRIORITY attribute indicates the priority that is to be associated with a peer reflexive candidate, should one be discovered by this check. It is a 32-bit unsigned integer, and has an attribute value of 0x0024.
優先属性は、このチェックによって発見された場合、ピア反射候補に関連付けられる優先度を示します。これは32ビットの署名されていない整数であり、属性値は0x0024です。
The USE-CANDIDATE attribute indicates that the candidate pair resulting from this check should be used for transmission of media. 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.
ユースキャンディデート属性は、このチェックから生じる候補ペアをメディアの送信に使用する必要があることを示します。属性にはコンテンツがありません（属性の長さフィールドはゼロです）。それは旗として機能します。属性値は0x0025です。
The ICE-CONTROLLED attribute is present in a Binding request and 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 used for tie-breaking of role conflicts.
ICE制御属性は拘束力のある要求に存在し、クライアントが現在管理されている役割にあると信じていることを示します。属性のコンテンツは、ネットワークバイト順序の64ビットの符号なし整数です。これには、役割の競合の結びつきに使用される乱数が含まれています。
The ICE-CONTROLLING attribute is present in a Binding request and 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 used for tie-breaking of role conflicts.
アイスコントロール属性は拘束力のあるリクエストに存在し、クライアントが現在管理する役割にあると信じていることを示しています。属性のコンテンツは、ネットワークバイト順序の64ビットの符号なし整数です。これには、役割の競合の結びつきに使用される乱数が含まれています。
This specification defines a single error response code:
この仕様は、単一のエラー応答コードを定義します。
487 (Role Conflict): The Binding request contained either the ICE-CONTROLLING or ICE-CONTROLLED attribute, indicating a role that conflicted with the server. The server ran a tie-breaker based on the tie-breaker value in the request and determined that the client needs to switch roles.
487（役割の競合）：バインディング要求には、アイスコントロールまたはアイス制御属性のいずれかが含まれており、サーバーと矛盾する役割を示しています。サーバーは、リクエストのタイブレーカー値に基づいてタイブレーカーを実行し、クライアントが役割を切り替える必要があると判断しました。
This section discusses issues relevant to network operators looking to deploy 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 NAT.
ICEは、既存のNATおよびファイアウォール機器で動作するように設計されています。その結果、氷の展開を容易にするために、既存のファイアウォールと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 [RFC5766]. 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は、[RFC4787]および[RFC5766]で定義されている推奨事項を満たしているNATデバイスが準拠している環境で最適に機能します。行動に準拠したNATを備えたネットワークでは、ICEはターンサーバーを必要とせずに機能し、音声品質を改善し、コールのセットアップ時間を減らし、ネットワークオペレーターの帯域幅の要求を減らします。
Deployment of ICE can have several interactions with available network capacity that operators should take into consideration.
氷の展開は、オペレーターが考慮すべき利用可能なネットワーク容量といくつかの相互作用を持つことができます。
First and foremost, ICE makes use of TURN and STUN servers, which would typically be located in the network operator's data centers. The STUN servers require relatively little bandwidth. For each component of each media 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 caller and callee). Each transaction is a single request and a single response, the former being 20 bytes long, and the latter, 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).
何よりもまず、ICEは、通常、ネットワークオペレーターのデータセンターに配置されるターンサーバーとスタンサーバーを使用します。スタンサーバーには、比較的少ない帯域幅が必要です。各メディアストリームの各コンポーネントについて、各クライアントからスタンサーバーへの1つ以上のスタントランザクションがあります。基本的な音声のみのIPv4VoIP展開では、コールごとに4つのトランザクションがあります（RTP用に1つ、CallerとCalleeの両方でRTCPに1つ）。各トランザクションは単一のリクエストと単一の応答であり、前者は20バイトの長さ、後者、28です。その結果、システムにnユーザーがあり、それぞれが忙しい時間に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 media traffic. The amount of calls requiring TURN for media relay is highly dependent on network topologies, and can and will vary over time. In a network with 100% behave-compliant NAT, it is exactly zero. At time of writing, large-scale consumer deployments were seeing between 5 and 10 percent of calls requiring TURN servers. Considering a voice-only deployment using G.711 (so 80 kbps in each direction), with .2 erlangs during the busy hour, this is N*3.2 kbps. For a population of one million users, this is 3.2 Gbps, assuming a 10% usage of TURN servers.
回転トラフィックはより重要です。ターンサーバーでは、トラフィックボリュームがスタンボリュームに等しくなります（実際、実際のメディアトラフィックのトラフィックに加えて、トラフィックボリューム（実際には、ターンサーバーが展開されている場合、別のStunサーバーは必要ありません）。メディアリレーにターンを必要とするコールの量は、ネットワークトポロジに大きく依存しており、時間とともに変化する可能性があります。100％の挙動に準拠したNATを持つネットワークでは、まさにゼロです。執筆時点で、大規模な消費者の展開は、ターンサーバーを必要とする通話の5〜10％の間で見られていました。g.711を使用した音声のみの展開（各方向に80 kbps）を考慮して、忙しい時間中に.2のerlangsを使用すると、これはn*3.2 kbpsです。100万人のユーザーの人口の場合、これは3.2 Gbpsです。これは、ターンサーバーの10％の使用を想定しています。
The process of gathering of candidates and performing of connectivity checks can be bandwidth intensive. ICE has been designed to pace both of these processes. The gathering phase and the connectivity check phase are meant to generate traffic at roughly the same bandwidth as the media traffic itself. This was done to ensure that, if a network is designed to support multimedia traffic of a certain type (voice, video, or just text), it will have sufficient capacity to support the ICE checks for that media. Of course, the ICE checks will cause a marginal increase in the total utilization; however, this will typically be an extremely small increase.
候補者の収集と接続チェックの実行プロセスは、帯域幅集中的になります。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 can send them. Consequently, network operators should make sure 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ネットワークはフレンドリーで展開しやすくなります。
STUN keepalives (in the form of STUN Binding Indications) are sent in the middle of a media session. However, they are sent only in the absence of actual media traffic. In deployments that are not utilizing Voice Activity Detection (VAD), the keepalives are never used and there is no increase in bandwidth usage. When VAD is being used, 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 don't have any real impact on capacity planning.
スタンキープライブ（スタンバインディング表示の形で）は、メディアセッションの途中で送信されます。ただし、実際のメディアトラフィックがない場合にのみ送信されます。音声アクティビティ検出（VAD）を利用していない展開では、キープライブは使用されず、帯域幅の使用が増加しません。VADが使用されている場合、沈黙期間中にKeepAlivesが送信されます。これには、音声があるときに送信される20〜30ミリ秒ごとにパケットよりもはるかに少ない15〜20秒ごとに1つのパケットが含まれます。したがって、Keepalivesは能力計画に本当の影響を与えません。
Deployments utilizing a mix of ICE and ICE-lite interoperate perfectly. They have been explicitly designed to do so, without loss of function.
氷と氷のライトのミックスを使用して展開が完全に相互操作します。それらは、機能を失うことなく、そうするように明示的に設計されています。
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ライトは限られたユースケースでのみ展開できます。これらの場合、およびそうすることに関与する警告は、付録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 has built-in features to help deal with these problems. SIP servers on the signaling path, typically deployed in the data centers of the network operator, will see the contents of the offer/answer 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 offer/answer exchange takes place, signaling the selected address (and its type). This updated re-INVITE is performed exactly for the purposes of educating network equipment (such as a diagnostic tool attached to a SIP server) about the results of ICE processing.
ICEには、これらの問題に対処するのに役立つ機能が組み込まれています。通常、ネットワークオペレーターのデータセンターに展開されるシグナリングパス上のSIPサーバーは、ICEパラメーターを伝えるオファー/回答交換の内容を確認します。これらのパラメーターには、各候補のタイプ（ホスト、サーバー反射、または中継）と関連するアドレスが含まれます。氷の処理が完了すると、更新されたオファー/回答の交換が行われ、選択したアドレス（およびそのタイプ）が合図されます。この更新されたRe-Inviteは、氷の処理の結果についてネットワーク機器（SIPサーバーに接続された診断ツールなど）を教育する目的で正確に実行されます。
As a consequence, through the logs generated by the SIP server, a network operator can observe what types of candidates are being used for each call, and what address was selected by ICE. This is the primary information that helps evaluate how ICE is performing.
結果として、SIPサーバーによって生成されたログを介して、ネットワークオペレーターは、各コールで使用されている候補の種類と、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 [SIP-UA-FRMWK] have been defined.
ICEは、エンドポイントに構成されているいくつかのデータに依存しています。この構成データには、タイマー、ターンサーバーの資格情報、スタンおよびターンサーバーのホスト名が含まれます。ICE自体は、この構成のメカニズムを提供しません。代わりに、この情報は、エンドポイントの他のすべてのパラメーターを構成するために使用されるあらゆるメカニズムに添付されていると想定されています。SIP電話の場合、構成フレームワーク[SIP-UA-FRMWK]などの標準ソリューションが定義されています。
This specification registers new SDP attributes, four new STUN attributes, and one new STUN error response.
この仕様は、新しいSDP属性、4つの新しいスタン属性、および1つの新しいスタンエラー応答を登録します。
This specification defines seven new SDP attributes per the procedures of Section 8.2.4 of [RFC4566]. The required information for the registrations is included here.
この仕様では、[RFC4566]のセクション8.2.4の手順ごとに7つの新しいSDP属性を定義します。登録に必要な情報はここに含まれています。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: candidate
属性名：候補者
Long Form: candidate
長いフォーム：候補者
Type of Attribute: media-level
属性のタイプ：メディアレベル
Charset Considerations: The attribute is not subject to the charset attribute.
charsetの考慮事項：属性は、charset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides one of many possible candidate addresses for communication. These addresses are validated with an end-to-end connectivity check using Session Traversal Utilities for NAT (STUN)).
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、コミュニケーションのための多くの候補者アドレスの1つを提供します。これらのアドレスは、NAT（STUN）のセッショントラバーサルユーティリティを使用して、エンドツーエンドの接続チェックで検証されます。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: remote-candidates
属性名：リモートキャンディデート
Long Form: remote-candidates
長いフォーム：リモートキャンディデート
Type of Attribute: media-level
属性のタイプ：メディアレベル
Charset Considerations: The attribute is not subject to the charset attribute.
charsetの考慮事項：属性は、charset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the identity of the remote candidates that the offerer wishes the answerer to use in its answer.
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、提供者が回答者にその回答で使用することを望んでいるリモート候補の身元を提供します。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: ice-lite
属性名：アイスライト
Long Form: ice-lite
長い形：氷のライト
Type of Attribute: session-level
属性のタイプ：セッションレベル
Charset Considerations: The attribute is not subject to the charset attribute.
charsetの考慮事項：属性は、charset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent has the minimum functionality required to support ICE inter-operation with a peer that has a full implementation.
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、エージェントが完全な実装を持つピアとのICE間操作をサポートするために必要な最小機能を持っていることを示します。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: ice-mismatch
属性名：ICE-MISMATCH
Long Form: ice-mismatch
長いフォーム：アイスミスマッチ
Type of Attribute: session-level
属性のタイプ：セッションレベル
Charset Considerations: The attribute is not subject to the charset attribute.
charsetの考慮事項：属性は、charset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent is ICE capable, but did not proceed with ICE due to a mismatch of candidates with the default destination for media signaled in the SDP.
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、エージェントが氷能力が高いことを示しますが、SDPで信号を送られたデフォルトの宛先を持つ候補者の不一致のために氷を進めなかったことを示します。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: ice-pwd
属性名：ICE-PWD
Long Form: ice-pwd
長いフォーム：ICE-PWD
Type of Attribute: session- or media-level
属性のタイプ：セッションレベルまたはメディアレベル
Charset Considerations: The attribute is not subject to the charset attribute.
charsetの考慮事項：属性は、charset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the password used to protect STUN connectivity checks.
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、スタン接続のチェックを保護するために使用されるパスワードを提供します。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: ice-ufrag
属性名：Ice-ufrag
Long Form: ice-ufrag
長いフォーム：Ice-ufrag
Type of Attribute: session- or media-level
属性のタイプ：セッションレベルまたはメディアレベル
Charset Considerations: The attribute is not subject to the charset attribute.
charsetの考慮事項：属性は、charset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the fragments used to construct the username in STUN connectivity checks.
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、スタン接続チェックでユーザー名を構築するために使用されるフラグメントを提供します。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡先名：Jonathan Rosenberg、jdrosen@jdrosen.net。
Attribute Name: ice-options
属性名：アイスオプション
Long Form: ice-options
長いフォーム：氷のオプション
Type of Attribute: session-level Charset Considerations: The attribute is not subject to the charset attribute.
属性のタイプ：セッションレベルのチャーセット考慮事項：属性はcharset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates the ICE options or extensions used by the agent.
目的：この属性は、インタラクティブな接続性確立（ICE）で使用され、エージェントが使用するICEオプションまたは拡張機能を示します。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
This section registers four new STUN attributes per the procedures in [RFC5389].
このセクションでは、[RFC5389]の手順ごとに4つの新しいスタン属性を登録します。
0x0024 PRIORITY 0x0025 USE-CANDIDATE 0x8029 ICE-CONTROLLED 0x802A ICE-CONTROLLING
0x0024優先度0x0025ユースキャンディデート0x8029アイスコントロール0x802aアイスコントロール
This section registers one new STUN error response code per the procedures in [RFC5389].
このセクションは、[RFC5389]の手順に従って1つの新しいスタンエラー応答コードを登録します。
487 Role Conflict: The client asserted an ICE role (controlling or controlled) that is in conflict with the role of the server.
487役割の競合：クライアントは、サーバーの役割と競合するICEの役割（制御または制御）を主張しました。
The IAB has studied the problem of "Unilateral Self-Address Fixing", which is the general process by which a 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 IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address Fixing) 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は、「一方的な自己アドレス固定」の問題を研究しています。これは、エージェントが共同プロトコル反射メカニズム[RFC3424]を介してNATの反対側の別の領域のアドレスを決定しようとする一般的なプロセスです。ICEは、このタイプの機能を実行するプロトコルの例です。興味深いことに、氷のプロセスは一方的ではなく、両側性であり、違いはIABによって提起された問題に大きな影響を与えます。実際、ICEは、UNSAFプロトコルではなく、B-SAF（二国間自己アドレス固定）プロトコルと見なすことができます。とにかく、IABは、この目的のために開発されたプロトコルが特定の考慮事項を文書化することを義務付けています。このセクションでは、これらの要件を満たしています。
>From RFC 3424, any UNSAF proposal must 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; this is why "short-term fixes usually aren't".
UNSAF提案で解決される特定の限られたスコープ問題の正確な定義。他の問題を解決するために、短期的な修正を一般化しないでください。これが、「短期的な修正は通常そうではない」理由です。
The specific problems being solved by ICE are:
氷によって解決される特定の問題は次のとおりです。
Provide a means for two peers to determine the set of transport addresses that can be used for communication.
2人のピアが通信に使用できる一連の輸送アドレスを決定するための手段を提供します。
Provide a means for a agent to determine an address that is reachable by another peer with which it wishes to communicate.
エージェントが、通信したい別のピアが到達可能なアドレスを決定する手段を提供します。
>From RFC 3424, any UNSAF proposal must 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 selects amongst those mechanisms, prioritizing ones that are better, and deprioritizing ones that are worse. Local IPv6 addresses can be preferred. 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 remove when their usage goes to zero.
氷自体は簡単に段階的になりません。ただし、たとえば、ルーターの故障が接続性を一時的に破壊したかどうかを検出する手段として機能することは、グローバルに接続されたインターネットでも役立ちます。ICEは、NATとは関係のない特定のセキュリティ攻撃を防ぐのにも役立ちます。ただし、ICEが行うことは、他のUNSAFメカニズムを段階的に廃止するのに役立ちます。ICEは、これらのメカニズムの中で効果的に選択し、より良いメカニズムに優先順位を付け、さらに悪いものを剥奪します。ローカルIPv6アドレスをお勧めします。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 must 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 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.
氷は実際に既存のUNSAFメカニズムから脆性を除去します。特に、Classic Stun（RFC 3489 [RFC3489]で説明されている）には、いくつかのポイントがあります。それらの1つは、エージェントが背後にある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 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.
古典的なスタンと他の一方的なメカニズムにおける脆性のもう1つのポイントは、追加のサーバーへの絶対的な依存です。ICEは、一方的なアドレスを割り当てるためにサーバーを使用しますが、可能であればエージェントが直接接続できるようにします。したがって、場合によっては、STUNサーバーの障害により、ICEが使用されている場合に呼び出しが進行する可能性があります。
Another point of brittleness in classic STUN is that it assumes that 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.
古典的なスタンにおける脆性のもう1つのポイントは、スタンサーバーがパブリックインターネット上にあることを前提としていることです。興味深いことに、氷の場合、それは必要ありません。さまざまなアドレス領域に多数のスタンサーバーがあります。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.
古典的なスタンで最も厄介な脆性の点は、すべてのネットワークトポロジで機能しないことです。各エージェントとスタンサーバーの間に共有NATがある場合、従来のスタンは機能しない場合があります。氷で、その制限は削除されます。
Classic STUN also introduces some security considerations. Fortunately, those security considerations are also mitigated by ICE.
クラシックスタンは、いくつかのセキュリティ上の考慮事項も紹介しています。幸いなことに、これらのセキュリティ上の考慮事項も氷によって軽減されます。
Consequently, ICE serves to repair the brittleness introduced in classic STUN, and does not introduce any additional brittleness into the system.
その結果、ICEは古典的なスタンで導入された脆性性を修復するのに役立ち、システムに追加の脆性を導入しません。
The penalty of these improvements is that ICE increases session establishment times.
これらの改善のペナルティは、氷がセッションの確立時間を増加させることです。
From RFC 3424, any UNSAF proposal must provide:
RFC 3424から、UNSAFの提案は次のことを提供する必要があります。
... 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からの結論は変更されていません。しかし、氷は実際に役立つと感じています。なぜなら、それが長期的な解決策の一部になると信じているからです。
From RFC 3424, any UNSAF proposal must provide:
RFC 3424から、UNSAFの提案は次のことを提供する必要があります。
Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
既存の展開されたNA [P] TSおよびExperience Reportsに関する有名な実用的な問題の影響についての議論。
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, either in 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.
現在、「ジェネリック」アルグ機能を提供しようとする多くのNATボックスが市場に展開されています。これらの一般的なアルグは、パケット内のテキストまたはバイナリ形式のいずれかで、IPアドレスを狩り、バインディングに一致する場合は書き直します。これは古典的なスタンを妨げます。ただし、Stun [RFC5389]の更新は、一般的なアルグからこれらのバイナリアドレスを隠すエンコードを使用します。
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ボックスが動作するように準拠するようになると、この最小キープライブは決定論的でよく知られ、氷のタイマーを調整できます。最小キープライブ間隔を発見して制御する方法を持つことは、はるかに優れています。
The authors would like to thank Dan Wing, Eric Rescorla, Flemming Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl, Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan Lennox, and Francois Audet for their comments and input. A special thanks goes to Bill May, who suggested several of the concepts in this specification, Philip Matthews, who suggested many of the key performance optimizations in this specification, Eric Rescorla, who drafted the text in the introduction, and Magnus Westerlund, for doing several detailed reviews on the various revisions of this specification.
著者は、ダン・ウィング、エリック・レスコルラ、フレミング・アンドレアセン、ローハン・マヒ、ディーン・ウィリス、エリック・クーパー、ジェイソン・フィッシュ、ダグラス・オーティス、ティム・ムーア、ジャン・フランコイス・ミュール、ケビン・ジョンズ、ジョナサン・レンノックス、フランコイス・オーデトに感謝します。および入力。この仕様のいくつかの概念を提案したビル・メイ、この仕様の主要なパフォーマンスの最適化の多くを提案したフィリップ・マシューズ、紹介でテキストを起草したエリック・レスコルラとマグナス・ウェスターランドを提案したビル・メイに特別に感謝します。この仕様のさまざまな改訂に関するいくつかの詳細なレビュー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605] Huitema、C。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、RFC 3605、2003年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S。、「セッション説明プロトコル（SDP）RTPコントロールプロトコル（RTCP）帯域幅の帯域幅修飾子」、RFC 3556、2003年7月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032] Camarillo、G。およびP. Kyzivat、「セッション開始プロトコル（SIP）Preconditions Frameworkの更新」、RFC 4032、2005年3月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。
[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, June 2005.
[RFC4092] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコルの使用（SDP）セッション開始プロトコル（SIP）における代替ネットワークアドレスタイプ（ANAT）セマンティクス、RFC 4092、2005年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Nat（Stun）のセッショントラバーサルユーティリティ」、RFC 5389、2008年10月。
[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, April 2010.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NAT（ターン）の周りのリレーを使用したトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、RFC 5766、2010年4月。
[RFC5768] Rosenberg, J., "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", RFC 5768, April 2010.
[RFC5768] Rosenberg、J。、「セッション開始プロトコル（SIP）におけるインタラクティブな接続性確立（ICE）のサポートを示す」、RFC 5768、2010年4月。
[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, March 2003.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235] Senie、D。、「ネットワークアドレス翻訳者（NAT）フレンドリーなアプリケーション設計ガイドライン」、RFC 3235、2002年1月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、2002年8月。
[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, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RFC3102] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有のIP：フレームワーク」、RFC 3102、2001年10月。
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RFC3103] Borella、M.、Grabelsky、D.、Lo、J。、およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、2001年10月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389] ZOPF、R。、「リアルタイム輸送プロトコル（RTP）コンフォートノイズのペイロード（CN）」、RFC 3389、2002年9月。
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[RFC3960] Camarillo、G。およびH. Schulzrinne、「セッション開始プロトコル（SIP）の初期メディアとリンギングトーン生成」、RFC 3960、2004年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[SDP-PRECON] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, "Connectivity Preconditions for Session Description Protocol Media Streams", Work in Progress, March 2010.
[SDP Precon] Andreasen、F.、Camarillo、G.、Oran、D。、およびD. Wing、「セッション説明プロトコルメディアストリームの接続性の前提条件」、2010年3月の進行中。
[NO-OP-RTP] Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload Format for RTP", Work in Progress, May 2007.
[no-op-rtp] Andreasen、F.、Oran、D。、およびD. Wing、「RTPのNo-opペイロード形式」、2007年5月の作業。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761] Perkins、C。およびM. Westerlund、「単一のポートのRTPデータと制御パケットを多重化」、RFC 5761、2010年4月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）におけるクライアント開始接続の管理」、RFC 5626、2009年10月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT行動要件」、BCP 142、RFC 5382、2008年10月。
[SIP-UA-FRMWK] Petrie, D. and S. Channabasappa, Ed., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, February 2010.
[SIP-UA-FRMWK] Petrie、D。and S. Channabasappa、ed。、「セッション開始プロトコルユーザーエージェントプロファイル配信のフレームワーク」、2010年2月の作業。
[ICE-TCP] Perreault, S., Ed. and J. Rosenberg, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, October 2009.
[Ice-TCP] Perreault、S.、ed。J. Rosenberg、「Interactive Connectivity Indecivity（ICE）を持つTCP候補」、2009年10月、進行中の作業。
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.
ICEは、2種類の実装を可能にします。完全な実装は、セッションでの制御および制御された役割をサポートし、アドレス収集を実行することもできます。対照的に、Liteの実装は、スタンチェックに応答するだけでなく、ほとんど機能しないミニマリストの実装です。
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の後ろではないエンドポイントが含まれます。非常に一般的なケースは、これらのデバイスのいずれかにNATトラバーサル（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 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 3484, which is recommended by this specification. However, static mechanisms for address selection are always prone to error, since they cannot ever reflect the actual topology and can never provide actual guarantees on connectivity. They are always heuristics. Consequently, if an 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を使用すると、Lite実装では、単一のIPv4ホスト候補といくつかのIPv6アドレスを持つことができます。その場合、候補ペアは、この仕様で推奨されるRFC 3484のような静的アルゴリズムなど、制御エージェントによって選択されます。ただし、アドレス選択の静的メカニズムは、実際のトポロジを反映することができず、接続性に関する実際の保証を提供できないため、常にエラーが発生しやすいです。彼らは常にヒューリスティックです。その結果、エージェントが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. A full implementation will reduce call setup times, since ICE's aggressive mode can be used. Full implementations also obtain the security benefits of ICE unrelated to NAT traversal; in particular, the voice hammer attack described in Section 18 is prevented only for full implementations, not lite. 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, that it will always be used on the public Internet. Full implementation provides assurance that communications will always work.
Liteの実装がこの仕様に追加され、完全な実装に足がかりを提供することに注意することが重要です。単一のIPv4アドレスを使用して常にパブリックインターネットに接続されているデバイスであっても、達成可能な場合は完全な実装が望ましいです。ICEの攻撃モードを使用できるため、完全な実装ではコールセットアップ時間が短縮されます。完全な実装は、Nat Traversalとは関係のない氷のセキュリティ利益も得ます。特に、セクション18で説明されている音声ハンマー攻撃は、ライトではなく、完全な実装に対してのみ防止されます。最後に、今日の公開アドレスで自分自身を見つけたデバイスが明日ネットワークに配置されるデバイスが、それが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 neccesary to understand for purposes of implementation, they are discussed here in an appendix to the specification. This section 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?
候補者を収集し、接続性を確認するために使用されるスタントランザクションは、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. Experiments have shown that once every 20 ms is well supported, but not much lower than that. This is why Ta has a lower bound of 20 ms. Furthermore, transmission of these packets on the network makes use of bandwidth and needs to be rate limited by the agent. Deployments based on earlier draft versions of this document 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.
これらのスタンリクエストを送信すると、クライアントとスタンサーバーの間にNATデバイスにバインディングを作成する効果があります。経験によると、多くのNATデバイスには、新しいバインディングが作成されるレートに上限があります。実験では、20ミリ秒ごとに十分にサポートされているが、それよりもそれほど低くないことが示されています。これが、TAの下限が20ミリ秒の理由です。さらに、ネットワーク上のこれらのパケットの送信により、帯域幅が利用され、エージェントがレートに制限する必要があります。このドキュメントの以前のドラフトバージョンに基づいた展開は、ネットワークに悪影響を与えることに加えて、レート制約のアクセスリンクを過負荷にし、全体的にパフォーマンスを低下させる傾向がありました。結果として、ペーシングにより、NATデバイスが過負荷にならず、トラフィックが妥当な速度で維持されることが保証されます。
The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media 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 media 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:
「合理的な」レートの定義は、メディアが流れ始めると、RTP自体が使用するよりも多くの帯域幅を使用すべきではないということです。TAの式は、STUNパケットがTAごとに送信された場合、すべてのメディアストリームで合計されたRTPパケットと同じ量の帯域幅を消費するように設計されています。もちろん、Stunには再送信があり、それらもそれらをペースにすることを望んでいます。このため、RTOは、最後のトランザクションの最初のスタン要求が発生するように、最初のトランザクションの最初の再送信が発生するように設定されています。絵で：
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つのホスト候補/スタンサーバーペアがあります）。これらはトランザクションA、B、およびCです。再送信タイマーが設定されているため、最初のトランザクション（パケットA2）の最初の再送信が時間3TAで送信されます。
Subsequent retransmits after the first will occur even less frequently than Ta milliseconds apart, since STUN uses an exponential back-off on its retransmissions.
Stunはその再送信で指数関数的なバックオフを使用するため、最初の再送信はTA Millisecondよりもさらに少ない頻度で発生します。
Section 4.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 agent have two candidates that have the same IP address and port, but different bases? Consider the topology of Figure 10:
セクション4.1.3では、同じ輸送住所と基地を持つ候補者の排除について説明します。ただし、同じ輸送の住所を持つ候補者は、根拠が異なることは冗長ではありません。エージェントには、同じIPアドレスとポートを持っているが、ベースが異なる2人の候補者がいつできますか？図10のトポロジを考えてみましょう。
+----------+
| STUN Srvr|
+----------+
|
|
-----
// \\
| |
| B:net10 |
| |
\\ //
-----
|
|
+----------+
| NAT |
+----------+
|
|
-----
// \\
| A |
|192.168/16 |
| |
\\ //
-----
|
|
|192.168.1.100 -----
+----------+ // \\ +----------+
| | | | | |
| Offerer |---------| C:net10 |-----------| Answerer |
| |10.0.1.100| | 10.0.1.101 | |
+----------+ \\ // +----------+
-----
Figure 10: Identical Candidates with Different Bases
図10：さまざまなベースを持つ同一の候補
In this case, the offerer is multihomed. It has one IP address, 10.0.1.100, on network C, which is a net 10 private network. The answerer is on this same network. The offerer is also connected to network A, which is 192.168/16. The offerer has an IP address of 192.168.1.100 on this network. There is a NAT on this network, natting into network B, which is another net 10 private network, but not connected to network C. There is a STUN server on network B.
この場合、提供者はマルチホームです。ネットワークCには、ネットワーク10のIPアドレス10.0.1.100があります。これは、ネット10プライベートネットワークです。回答者はこの同じネットワークにあります。オファーは、192.168/16であるネットワークAにも接続されています。オファーは、このネットワーク上の192.168.1.100のIPアドレスを持っています。このネットワークにはNATがあり、ネットワークBにNATがあります。これは別のネット10プライベートネットワークですが、ネットワークCに接続されていません。ネットワークBにはスタンサーバーがあります。
The offerer 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 offerer 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（10.0.1.100:2498）のIPアドレスでホスト候補を取得し、ネットワークA（192.168.1.100:3344）上のIPアドレスのホスト候補を取得します。192.168.1.100:3344から構成されたStunサーバーにスタンクエリを実行します。このクエリは、バインディング10.0.1.100:2498を割り当てるためにたまたまNATを通過します。スタンサーバーは、これをスタンバインディング応答に反映しています。現在、オファーは、ホスト候補（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 -- <rel-addr> and <rel-port>. Why is it present?
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 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 and not for others, this provides useful diagnostics on what is going on in the network.
その包含には2つの動機があります。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 media traffic. They can then interact, through policy servers, with access routers in the network, to establish guaranteed QoS for the media flows. This QoS is provided by classifying the RTP traffic based on 5-tuple, and then providing it a guaranteed rate, or marking its Diffserv codepoints appropriately. When a residential NAT is present, and a relayed candidate gets selected for media, 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）メカニズムに関係しています。Packetcable 2.0などの環境で氷が使用される場合、プロキシは通常のSIP操作を実行することに加えて、SIPメッセージでSDPを検査し、IPアドレスとポートをメディアトラフィックのために抽出します。その後、ポリシーサーバーを介して、ネットワーク内のアクセスルーターを介して対話して、メディアフローの保証されたQOを確立できます。このQoSは、5タプルに基づいてRTPトラフィックを分類し、保証レートを提供するか、DiffServ CodePointsを適切にマークすることにより提供されます。住宅のNATが存在し、中継候補がメディアに選択されると、この中継候補は実際のターンサーバーの輸送住所になります。そのアドレスは、QoS処理のパケットを分類するために使用されるアクセスルーター内の実際の輸送アドレスについて何も述べていません。むしろ、ターンサーバーに向けてサーバー反射候補が必要です。翻訳を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 SDP offer/answer 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とのメッセージの整合性の使用が必要です。実際の短期資格情報は、SDPオファー/回答交換でユーザー名フラグメントを交換することによって形成されます。このメカニズムの必要性は、単なるセキュリティを超えています。そもそも氷の正しい操作には実際に必要です。
Consider 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 an offer to Z. Z, in its answer, provides 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, the STUN short-term credential mechanisms are used. The username fragments are sufficiently random that 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 offer/answer session.
エージェント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にオファーを送信し、その回答では、ホスト候補を提供します。この場合、これらの候補者は10.0.1.1:8866および10.0.1.1:8877です。結局のところ、Rは同時にセッションに参加しており、ホスト候補として10.0.1.1:8866および10.0.1.1:8877を使用しています。これは、Rがzと同様に、これらのポートでスタンメッセージを受け入れる準備ができていることを意味します。Lは10.0.1.1:8866にスタンリクエストを送信し、別のリクエストは10.0.1.1:8877に送信します。ただし、これらは予想どおりZに移動しません。代わりに、彼らはrに行きます！Rがちょうど彼らに答えた場合、LはZへの接続性があると信じています。実際、まったく異なるユーザーに接続されている場合、R。ユーザー名フラグメントは十分にランダムであり、RがZと同じ値を使用する可能性は非常に低いため、資格情報が無効であるため、Rはスタン要求を拒否します。本質的に、スタンユーザー名フラグメントは、特定のオファー/回答セッションにバインドされた一時的なホスト識別子の形式を提供します。
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 in SDP 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 should 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エージェントでさえない可能性があるということです。それはあらゆるホストである可能性があり、スタンパケットが指示されるポートは、そのホストのすべての短命ポートになる可能性があります。パケット用のこのソケットでリスニングされているアプリケーションがあり、使用中のプロトコルに対して不正なパケットを処理する準備ができていない場合、そのアプリケーションの動作が影響を受ける可能性があります。幸いなことに、SDPで交換されたポートは短命であり、通常は動的または登録範囲から引き出されるため、ポートがホストrでサーバーを実行するのに使用されず、一部のプロトコルのエージェント側である可能性があります。これにより、この範囲でのポート使用の一時的な性質により、割り当てられたポートを押す確率が低下します。ただし、問題の可能性が存在し、ネットワークの展開を準備する必要があります。これは氷に固有の問題ではないことに注意してください。迷ったパケットは、あらゆる種類のプロトコル、特にパブリックインターネット上のプロトコルについて、いつでもポートに到着できます。そのため、この要件は、インターネットアプリケーションの一般的な設計ガイドラインを再定義するだけです。ポートの不明なパケット用に準備してください。
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 tie-breaker 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 agent, a lower-priority candidate is never used until all higher-priority candidates have been tried.
どうしてこれなの？候補ペアがこの値に基づいてソートされると、結果のソートには最大/minプロパティがあります。これは、2つの優先順位の最小値の減少値に基づいて、ペアが最初にソートされることを意味します。最小優先度の同じ値を持つペアの場合、最大の優先度が使用され、それらの間でソートされます。最大および最小優先順位が同じ場合、制御エージェントの優先順位は、式の最後の部分でタイブレーカーとして使用されます。1人の候補者の優先順位は常に2*32未満であるため、2*32の係数が使用されます。その結果、ペアの優先順位は2つのコンポーネントの優先順位の「連結」です。これにより、最大/minソートが作成されます。Max/Minは、特定のエージェントの場合、すべてのより優先順位の候補者が試されるまで、より低い優先度の候補者が使用されないようにします。
The a=remote-candidates attribute exists to eliminate a race condition between the updated offer and the response to the STUN Binding request that moved a candidate into the Valid list. This race condition is shown in Figure 11. On receipt of message 4, agent L adds a candidate pair to the valid list. If there was only a single media stream with a single component, agent L could now send an updated offer. However, the check from agent R has not yet generated a response, and agent R receives the updated offer (message 7) before getting the response (message 9). Thus, it does not yet know that this particular pair is valid. To eliminate this condition, the actual candidates at R that were selected by the offerer (the remote candidates) are included in the offer itself, and the answerer delays its answer until those pairs validate.
a = remote-candidates属性は、更新されたオファーと、候補者を有効なリストに移動したスタンバインディングリクエストへの応答とのレース条件を排除するために存在します。このレース条件を図11に示します。メッセージ4を受け取ると、エージェントLは有効なリストに候補ペアを追加します。単一のコンポーネントを備えた単一のメディアストリームしかなかった場合、エージェントLは更新されたオファーを送信できるようになりました。ただし、エージェントRからのチェックはまだ応答を生成しておらず、エージェントRは応答を取得する前に更新されたオファー（メッセージ7）を受け取ります（メッセージ9）。したがって、この特定のペアが有効であることはまだわかりません。この状態を排除するために、提供者（リモート候補者）によって選択されたRの実際の候補者はオファー自体に含まれ、回答者はそれらのペアが検証されるまでその回答を遅らせます。
Agent A Network Agent B
|(1) Offer | |
|------------------------------------------>|
|(2) Answer | |
|<------------------------------------------|
|(3) STUN Req. | |
|------------------------------------------>|
|(4) STUN Res. | |
|<------------------------------------------|
|(5) STUN Req. | |
|<------------------------------------------|
|(6) STUN Res. | |
|-------------------->| |
| |Lost |
|(7) Offer | |
|------------------------------------------>|
|(8) STUN Req. | |
|<------------------------------------------|
|(9) STUN Res. | |
|------------------------------------------>|
|(10) Answer | |
|<------------------------------------------|
Figure 11: Race Condition Flow
図11：人種状態の流れ
Once media 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 media stream packets themselves (e.g., RTP) meet this objective. However, several cases merit further discussion. Firstly, in some RTP usages, such as SIP, the media 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 media in these cases. However, doing so may cause NAT bindings to timeout, and media won't be able to come off hold.
メディアが候補ペアに流れ始めると、セッションの期間中、バインディングを中間NATで生かし続ける必要があります。通常、メディアストリームパケット自体（たとえば、RTP）はこの目的を満たしています。ただし、いくつかのケースはさらなる議論に値します。第一に、SIPなどの一部のRTP使用では、メディアストリームを「保留」することができます。これは、RFC 3264 [RFC3264]で定義されているように、SDP「Sendonly」または「非アクティブ」属性を使用することによって達成されます。RFC 3264は、これらのケースでメディアの送信を停止するように実装を指示します。ただし、そうすることで、Nat Bindingsがタイムアウトを引き起こす可能性があり、メディアはホールドオフになることはできません。
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 media transmission to cease sufficiently long for NAT bindings to time out.
第三に、沈黙の抑制が使用されている場合、長い期間の沈黙により、メディアの伝達がタイムアウトのNATバインディングが十分に長く停止する可能性があります。
For these reasons, the media 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は、スタンバインディングの適応症を利用して、単純な周期的なキープライブを定義します。これにより、帯域幅の要件が非常に予測可能であるため、QoSの予約に適しています。
Section 4.1.2 describes procedures for computing the priority of 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 18. It is much easier for an attacker to cause an agent to use a false server reflexive candidate than it is for an attacker to cause an agent to use a false peer reflexive candidate. Consequently, attacks against address gathering with Binding requests are thwarted by ICE by preferring the peer reflexive candidates.
セクション4.1.2では、候補者の優先順位を計算するための手順について、その種類とローカルの好みに基づいて説明します。そのセクションでは、ピア反射候補のタイプの選好が常にサーバー反射よりも高いことが必要です。何故ですか？その理由は、セクション18のセキュリティ上の考慮事項に関係しています。攻撃者は、攻撃者が攻撃者がエージェントに誤ったピア反射候補を使用させるよりも、誤ったサーバー反射候補を使用させるのがはるかに簡単です。その結果、拘束力のあるリクエストでの住所収集に対する攻撃は、ピア反射候補を好むことにより、ICEによって妨害されます。
Section 11.1 describes rules for sending media. Both agents can send media once ICE checks complete, without waiting for an updated offer. Indeed, the only purpose of the updated offer is to "correct" the SDP so that the default destination for media matches where media is being sent based on ICE procedures (which will be the highest-priority nominated candidate pair).
セクション11.1では、メディアを送信するためのルールについて説明します。両方のエージェントは、更新されたオファーを待つことなく、アイスチェックが完了するとメディアを送信できます。実際、更新されたオファーの唯一の目的は、SDPを「修正」することです。これにより、メディアのデフォルトの宛先がICE手順（最高優先順位の指名候補ペアになる）に基づいてメディアが送信される場所に一致するようにすることです。
This begs the question -- why is the updated offer/answer exchange needed at all? Indeed, in a pure offer/answer environment, it would not be. The offerer and answerer will agree on the candidates to use through ICE, and then can begin using them. As far as the agents themselves are concerned, the updated offer/answer provides no new information. However, in practice, numerous components along the signaling path look at the SDP information. These include entities performing off-path QoS reservations, NAT traversal components such as ALGs and Session Border Controllers (SBCs), and diagnostic tools that passively monitor the network. For these tools to continue to function without change, the core property of SDP -- that the existing, pre-ICE definitions of the addresses used for media -- the m and c lines and the rtcp attribute -- must be retained. For this reason, an updated offer must be sent.
これは疑問を投げかけます - なぜ更新されたオファー/回答交換がまったく必要なのですか？確かに、純粋なオファー/回答環境では、そうではありません。オファーと応答者は、氷を介して使用する候補者に同意し、それらを使用し始めることができます。エージェント自体に関する限り、更新されたオファー/回答は新しい情報を提供しません。ただし、実際には、信号パスに沿った多数のコンポーネントがSDP情報を調べています。これらには、オフパスQoS予約を実行するエンティティ、ALGSやセッションボーダーコントローラー（SBC）などのNATトラバーサルコンポーネント、およびネットワークを受動的に監視する診断ツールが含まれます。これらのツールが変更なしで機能し続けるためには、SDPのコアプロパティ - メディアに使用されるアドレス（MおよびCラインとRTCP属性）の既存の氷室前定義が保持されなければならないことです。このため、更新されたオファーを送信する必要があります。
Media keepalives are described in Section 10. 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? The primary reason has to do with network QoS mechanisms. Once media begins flowing, network elements will assume that the media stream has a fairly regular structure, making use of periodic packets at fixed intervals, with the possibility of jitter. If an agent is sending media packets, and then receives a Binding request, it would need to generate a response packet along with its media packets. This will increase the actual bandwidth requirements for the 5-tuple carrying the media 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 media.
メディアのキープライブについては、セクション10で説明されています。これらのキープライブは、両方のエンドポイントが氷が可能である場合、スタンを使用します。ただし、バインディングリクエストトランザクション（応答を生成する）を使用するのではなく、keepAlivesは表示を使用します。何故ですか？主な理由は、ネットワークQoSメカニズムに関係しています。メディアが流れ始めると、ネットワーク要素はメディアストリームがかなり規則的な構造を持ち、固定間隔で定期的なパケットを使用し、ジッターの可能性を伴うと想定します。エージェントがメディアパケットを送信してからバインディングリクエストを受信している場合、メディアパケットとともに応答パケットを生成する必要があります。これにより、メディアパケットを運ぶ5タプルの実際の帯域幅要件が増加し、それらのパケットの配信にジッターが導入されます。分析により、これは、メディアにかなりタイトなパケットスケジューラを使用する特定のレイヤー2アクセスネットワークの懸念であることが示されています。
Additionally, using a Binding Indication allows integrity to be disabled, allowing for better performance. This is useful for large-scale endpoints, such as PSTN gateways and SBCs.
さらに、結合表示を使用すると、整合性を無効にすることができ、パフォーマンスが向上します。これは、PSTNゲートウェイやSBCなどの大規模なエンドポイントに役立ちます。
When ICE runs between two peers, one agent acts as controlled, and the other as controlling. Rules are defined as a function of implementation type and offerer/answerer to determine who is controlling and who is controlled. However, the specification mentions that, in some cases, both sides might believe they are controlling, or both sides might believe they are controlled. How can this happen?
ICEが2つのピアの間を走ると、1つのエージェントが制御として機能し、もう1つは制御として機能します。ルールは、誰が制御し、誰が制御されているかを決定するための実装タイプとオファー担当者/回答者の関数として定義されます。ただし、仕様には、場合によっては、双方が制御していると信じるか、双方が制御されていると信じるかもしれないと述べています。これはどうすれば起こりますか？
The condition when both agents believe they are controlled shows up in third party call control cases. Consider the following flow:
両方のエージェントがそれらが制御されていると信じている場合の条件は、サードパーティコールコントロールケースに表示されます。次のフローを検討してください。
A Controller B
|(1) INV() | |
|<-------------| |
|(2) 200(SDP1) | |
|------------->| |
| |(3) INV() |
| |------------->|
| |(4) 200(SDP2) |
| |<-------------|
|(5) ACK(SDP2) | |
|<-------------| |
| |(6) ACK(SDP1) |
| |------------->|
Figure 12: Role Conflict Flow
図12：役割の競合フロー
This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact, it works better than flow III since it produces fewer messages. In this flow, the controller sends an offerless INVITE to agent A, which responds with its offer, SDP1. The agent then sends an offerless INVITE to agent B, which it responds to with its offer, SDP2. The controller then uses the offer from each agent to generate the answers. When this flow is used, ICE will run between agents A and B, but both will believe they are in the controlling role. With the role conflict resolution procedures, this flow will function properly when ICE is used.
このフローは、RFC 3725 [RFC3725]のフローIIIのバリエーションです。実際、Flow IIIよりも少ないメッセージを生成するため、Flow IIIよりもうまく機能します。このフローでは、コントローラーはオファーレスの招待状をエージェントAに送信します。エージェントAは、そのオファーSDP1で応答します。その後、エージェントはオファーレスの招待状をエージェントBに送信します。エージェントBは、そのオファーであるSDP2で応答します。次に、コントローラーは各エージェントからのオファーを使用して回答を生成します。このフローを使用すると、エージェントAとBの間で氷が実行されますが、どちらも制御の役割にあると信じるでしょう。役割の競合解決手順により、氷が使用されるとこの流れが適切に機能します。
At this time, there are no documented flows that can result in the case where both agents believe they are controlled. However, the conflict resolution procedures allow for this case, should a flow arise that would fit into this category.
現時点では、両方のエージェントが自分が制御されていると信じる場合に生じる可能性のある文書化されたフローはありません。ただし、このカテゴリに適合するフローが発生した場合、紛争解決手続きがこのケースを許可します。
Author's Address
著者の連絡先
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
Jonathan Rosenberg Jdrosen.netモンマス、ニュージャージー州
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net