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
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（TURN）のセッショントラバーサルユーティリティを使用しています。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]の二相交流を定義します。このオファー/アンサーメカニズムは、セッション開始プロトコル（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）を介して動作することは困難です。彼らの目的は、メディアパケットの流れを確立することであるので、それらはNAT [RFC3235]を通じて問題があることが知られている彼らのメッセージ内のメディアソースおよびシンクの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]彼らは、このようなセッション記述プロトコル（SDP）リアルタイム制御プロトコル（RTCP）[RFC3605]のための[RFC4566]属性として、動作させます。残念ながら、これらの技術のすべては、いくつかのネットワークトポロジ内の各1つの最適な、しかし、他の貧しい選択をする長所と短所を持っています。その結果、管理者と実装者がその解決策が展開されているネットワークのトポロジについての仮定をしているということです。これは、システムに複雑さと脆さを紹介します。必要なものは、すべての状況でうまく動作するのに十分な柔軟性があり、単一のソリューションです。
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は、TCP [ICE-TCP]などの他のトランスポートプロトコルを扱うように拡張することができるが）この仕様は、UDPベースのメディアストリームのためのNATトラバーサルのための技術として、インタラクティブ接続確立（ICE）を定義します。 ICEは、オファー/アンサーモデルに拡張され、その後、ピア・ツー・ピア接続性チェックにより接続について試験するSDPオファーや回答、内のIPアドレスとポートを多数含むことにより動作します。 IPアドレスとポートは、SDPに含まれる接続性チェックは、現在NATのためのセッショントラバーサルユーティリティに改名改訂STUN仕様[RFC5389]を使用して行われます。新しい名前と新しい仕様は、元のSTUN仕様があったように、他のNATトラバーサル技法（すなわちICE）のではなく、スタンドアロンのNATトラバーサルソリューションで使用されるツールとしての新しい役割を反映します。 ICEはまた、NAT周りのリレーを使用トラバーサルの使用（TURN）[RFC5766]、STUNへの拡張を行います。 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.
典型的なICEの展開では、我々は通信したい（RFC 3264の用語では薬として知られている）2つのエンドポイントを持っています。彼らは、SDPのオファー/アンサー交換を行うことが可能な（例えば、SIPなどの）いくつかのシグナリングプロトコル、[RFC3264]メッセージを介して間接的に通信することができます。 ICEは、別のメカニズム[RFC5626]を介して提供されているものとするSIPのNATトラバーサルのために意図されていないことに留意されたいです。 ICEプロセスの開始時に、エージェントは、自分のトポロジの無知です。特に、それらは、または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は、ICEの展開のための一般的な環境を示します。 2つのエンドポイントは、（コールフローを視覚化するのに役立つ左右用）LとRが標識されています。彼らはそれを認識していないかもしれないが、LとRの両方がそれぞれ独自のNATの背後にあります。 NATとそのプロパティのタイプも不明です。剤LおよびRは、それらが目的この交換は、SIPサーバを介して発生する、典型的にはLとRの間のメディアセッションをセットアップすることであるSDPメッセージを交換することが可能なオファー/アンサー交換に従事することが可能です。
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は、一般的に、ネットワーク内のSTUNやTURNサーバと連携して使用されています。各エージェントは、独自のSTUNやTURNサーバーを持つことができ、またはそれらは同一であってもよいです。
+-------+
| SIP |
+-------+ | Srvr | +-------+
| STUN | | | | STUN |
| Srvr | +-------+ | Srvr |
| | / \ | |
+-------+ / \ +-------+
/ \
/ \
/ \
/ \
/ <- Signaling -> \
/ \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
/ \
+-------+ +-------+
| Agent | | Agent |
| L | | R |
| | | |
+-------+ +-------+
Figure 1: ICE Deployment Scenario
図1：ICE展開シナリオ
The basic idea behind ICE is as follows: each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port for a particular transport protocol, which is always UDP in this specification)) it could use to communicate with the other agent. These might include:
次のようにICEの基本的な考え方は次のとおりです。各エージェントは、候補トランスポートアドレスの様々な、それは他のエージェントと通信するために使用することができます）（本明細書では、常に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 TURNサーバから割り当てられたトランスポートアドレス（「アドレスを中継しました」）。
Potentially, any of L's candidate transport addresses can be used to communicate with any of R's candidate transport addresses. In practice, however, many combinations will not work. For instance, if L and R are both behind NATs, their directly attached interface addresses are unlikely to be able to communicate directly (this is why ICE is needed, after all!). The purpose of ICE is to discover which pairs of addresses will work. The way that ICE does this is to systematically try all possible pairs (in a carefully sorted order) until it finds one or more that work.
潜在的に、Lの候補トランスポート・アドレスのいずれかがRの候補トランスポート・アドレスのいずれかと通信するために使用することができます。しかし実際には、多くの組み合わせが動作しません。 LとRの両方がNATの背後にある場合例えば、彼らの直接接続インターフェイスアドレスは（ICEは結局、必要とされている理由です！）直接通信することができることはほとんどありません。 ICEの目的は、アドレスのペアが動作するどの発見することです。 ICEがこれを行う方法は、それが1つまたは複数のその仕事を見つけるまで体系的に（慎重にソートされた順序で）すべての可能なペアを試してみることです。
In order to execute ICE, an 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を実行するために、エージェントは、そのアドレスの候補のすべてを識別することがあります。 （ここで指定したUDPのみで）特定のトランスポートプロトコルのIPアドレスとポートの組み合わせ - 候補者は、トランスポート・アドレスです。この文書は、候補の三種類、物理的または論理的ネットワークインターフェースに由来するいくつかの、STUNとTURNを介して発見他人を定義します。当然のことながら、ある実行可能な候補は、ローカルインターフェースから直接得られたトランスポートアドレスです。このような候補がHOST候補者と呼ばれています。ローカルインタフェースは、イーサネットまたは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）に接続された第二。同じプライベートネット10ネットワーク上のピアとの通信時に公衆インターネット上のピアとの通信時にI2から候補が直接到達するがI1からの候補は、直接到達可能であろう。むしろプランを送信する前に動作しますどの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.
次に、エージェントは追加の候補を得るために、STUNやTURNを使用しています。 NATのパブリック側で変換されたアドレス（SERVER再帰候補）とTURNサーバ上のアドレス（中継される候補）：これらは、2つの種類があります。 TURNサーバを利用する場合には、候補者の両方のタイプは、TURNサーバから取得されます。唯一STUNサーバを利用している場合は、サーバのみ再帰候補は、それらから得られます。ホスト候補にこれらの候補者の関係は、候補者の両方のタイプがTURNを使用して発見され、この図では、図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.
エージェントはTURNは、IPアドレスとポートXからの要求割り当て送信する場合：X：ホスト候補Xにこのサーバ再帰候補をマッピングし、「X1」Xを、NAT（1があると仮定）が結合X1を作成します。ホスト候補から送信された発信パケットは、サーバ再帰候補者へのNATによって変換されます。サーバー再帰候補者に送信された着信パケットはホスト候補にNATによって変換され、エージェントに転送されます。私たちは、特定のサーバー再帰候補者BASEに関連付けられたホスト候補を呼び出します。
Note: "Base" refers to the address an agent sends from for a particular candidate. Thus, as a degenerate case host candidates also have a base, but it's the same as the host candidate.
注：「ベース」は、薬剤が特定の候補のための送信アドレスを指します。このように、縮退ケースとしてホスト候補にも拠点を持っているが、それはホスト候補と同じです。
When there are multiple NATs between the agent and the TURN server, the TURN request will create a binding on each NAT, but only the outermost server reflexive candidate (the one nearest the TURN server) will be discovered by the agent. If the agent is not behind a NAT, then the base candidate will be the same as the server reflexive candidate and the server reflexive candidate is redundant and will be eliminated.
エージェントとTURNサーバー間の複数のNATがある場合は、TURN要求は、各NATに結合を作成しますが、唯一の最も外側のサーバー再帰候補（TURNサーバー最寄り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.
その後、TURNサーバーに到着した要求を割り当てます。 TURNサーバは、そのローカルIPアドレスYからポートyを割り当て、割り当て応答を生成し、この中継候補の薬剤を知らせます。割り当て応答に割り当て要求の送信元トランスポートアドレスをコピーして：「X1」TURNサーバーは、サーバー再帰候補、X1のエージェントに通知します。 TURN Lにトラフィックを送信するために、LとRの間のトラフィックを転送するパケット中継としてサーバ作用、RはYでTURNサーバにトラフィックを送信する：X1へのY、及びTURNサーバに転送「X1」、どのそれはXにマッピングされるNATを通過し、XおよびL.に送達
When only STUN servers are utilized, the agent sends a STUN Binding request [RFC5389] to its STUN server. The STUN server will inform the agent of the server reflexive candidate X1':x1' by copying the source transport address of the Binding request into the Binding response.
唯一STUNサーバが利用される場合、エージェントはSTUNサーバーにSTUNバインディング要求[RFC5389]を送信します。バインディングレスポンスにバインディング要求の送信元トランスポートアドレスをコピーして：「X1」STUNサーバは、サーバ再帰候補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は、提供を受けたとき、それは同じ収集プロセスを実行し、候補者の独自のリストで応答します。このプロセスの終わりに、各エージェントは、その候補者とそのピアの候補者の両方の完全なリストを持っています。それ候補対になるペアそれらを、。各エージェントのスケジュールに、ペアが動作している一連のチェックを参照してください。各チェックは、クライアントがリモートの候補者へのローカル候補からSTUNリクエストを送信することにより、特定の候補ペア上で実行されますSTUN要求/応答トランザクションです。
The basic principle of the connectivity checks is simple:
接続性チェックの基本的な原理は簡単です：
With both agents performing a check on a candidate pair, the result is a 4-way handshake:
両方の薬剤は、候補ペアのチェックを行うと、結果は、4ウェイハンドシェイクです。
L R - - STUN request -> \ L's <- STUN response / check
LのR - - STUN要求 - > \ L'sの< - STUN応答/確認
<- STUN request \ R's STUN response -> / check
< - STUN要求の\ RのSTUNレスポンス - > /チェック
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要求をすると、メディア（例えば、RTPおよびRTCP）のために使用される正確に同じIPアドレスとポートから送信されたことに注意することが重要です。その結果、薬剤はなく、それらが受信されたポートよりも、パケットの内容を使用して、STUNおよび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.
STUNバインディング要求が接続性チェックのために使用されるため、STUNバインディング応答は、エージェントとそのピアの間の任意のNATのパブリック側のエージェントの翻訳トランスポートアドレスが含まれています。このトランスポートアドレスは、他の候補者と異なる場合は、エージェントがすでに学んだ、それは新たな候補を表し、そして他の候補としてちょうど同じICEによってテストされますPEER再帰CANDIDATE、と呼ばれます。
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に送信されます。これは、有効な候補者を見つけるプロセスを加速し、TRIGGERED CHECKと呼ばれています。
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.
NATの背後にあるエージェントがそのホストに向けてパケットを送信したまで、第2の特性は、LのフロントとR.におけるNATのよくあるときに動作するICEを得るために重要であり、NATはホストからでパケットを許可しません。両側がそれぞれのNATを経由小切手を送ってきたまでは結果的に、各方向におけるICEチェックは成功しません。
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.
エージェントは、定期的に、リスト上の次の候補ペアのSTUNリクエストを送信することにより、このチェックリストを動作します。これらは、通常の点検と呼ばれています。
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.
先の説明は、薬剤は一つの構成要素（単一のトランスポートアドレスを必要とするメディアストリームの部分とメディアセッションを確立したい場合に対処し、メディアストリームは、複数の構成要素を必要とするかもしれない、メディアストリームのために働くことをそれぞれ有します全体として）仕事であることを。典型的には、（例えば、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アドレスから受信された特にため）ネットワークのプロパティは、各コンポーネントのための非常に類似する可能性があります。別のための最良の候補を決定するために、1つのメディア・コンポーネントからの情報を活用することが通常可能です。 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.
各候補者は、そのFOUNDATIONというプロパティに関連付けられています。同じタイプのと同じプロトコルを使用して、同じホスト候補とSTUNサーバーから取得した - 彼らは「類似」しているときに、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.
私たちは「凍結」説明してきたものの、ここで解説の目的のために別のメカニズムとして、実際には、ICEの不可欠な一部であり、ICEの優先順位付けアルゴリズムは、自動的に右の候補が正しい順序で凍結されていないと確認されていることを保証します。
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は、二つの薬剤の間でメディアを送信するために使用できるアドレスを発見するために使用されているので、プロセスが間違った場所にメディアを送信するためにハイジャックすることができないようにすることが重要です。各STUN接続性チェックがシグナリングチャネルで交換した鍵を使用して計算されたメッセージ認証コード（MAC）で覆われています。このMACは、このように接続性チェックメッセージを偽造または変更から攻撃を停止し、メッセージの整合性とデータ発信元認証を提供します。また、SIP [RFC3261]発信者がICEを使用して、そのコールフォークされている場合、ICEの交換は、各二股受信者と独立に起こります。このような場合には、キーは、シグナリングヘルプ会合に各二股レシピエントと各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チェックは、特定の順序で行われます。 ICEを締結する1つの方法は、各メディアストリームの各コンポーネントのチェックが正常に完了するとすぐに勝利を宣言することです。確かに、これは合理的なアルゴリズムであり、そしてそのための詳細を以下に示します。しかし、パケットロスが高い優先順位のチェックが完了するまでに長い時間がかかることになります可能性があります。その場合には、ICEが少し長く実行できるようにすることは、より良い結果を生むかもしれません。より基本的に、しかしながら、この仕様で定義された優先順位は、「最適な」結果が得られないかもしれません。目的は、低レイテンシ・メディア・パスを選択する場合、一例として、リレーの使用は、待ち時間が高くなることが示唆され、それはヒントに過ぎません。実際のラウンドトリップ時間（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は、制御剤の役割剤の一つ、および制御さAGENTの他に割り当てます。制御エージェントは、ペアが有効であるものの中でメディアに使用されますどの候補者指名する取得します。 REGULAR指名またはAGGRESSIVE指名を使用して - それは、次のいずれかの方法でこれを行うことができます。
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つの有効な候補ペアが見つかるまでチェックを継続することができます。その後、それはこのペアは、使用にノミネートされたピアを伝えるために設定されたフラグで有効なものの中で取り上げ、そのノミネート候補ペアの二STUN要求を送信しますが、この時間。これは、図4に示されています。
L R - - STUN request -> \ L's <- STUN response / check
LのR - - STUN要求 - > \ L'sの< - STUN応答/確認
<- STUN request \ R's STUN response -> / check
< - STUN要求の\ RのSTUNレスポンス - > /チェック
STUN request + flag -> \ L's <- STUN response / check
STUN要求+フラグ - > \ L'sの< - STUN応答/確認
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.
フラグとSTUNトランザクションが完了すると、両側は、メディアストリームのための将来のチェックを解除してください。 ICEは今、このペアを使用してメディアを送信します。メディアの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.
積極的な推薦では、制御エージェントは、それが送信するすべてのSTUN要求にフラグを置きます。最初のチェックが成功したら、この方法では、ICEの処理は、そのメディアストリームのための完全であると制御因子は、第二のSTUN要求を送信する必要はありません。選択されたペアは、そのチェック成功し、最も優先順位の高い有効なペアとなります。積極的な推薦は、通常の指名よりも高速ですが、あまり柔軟性を提供します。積極的な推薦は、図5に示されています。
L R - - STUN request + flag -> \ L's <- STUN response / check
LのR - - STUN要求フラグ+ - > \ L'S < - STUN応答/確認
<- STUN request \ R's STUN response -> / check
< - STUN要求の\ RのSTUNレスポンス - > /チェック
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.
一旦、全てのメディアストリームのが完了している（DEFAULT候補と呼ばれる）メディアストリームのための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.
ICEが締結されると、それは、いずれかの薬剤によって、メディアストリームの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.
ICEは、呼び出しで使用するためには、両方の薬剤は、それをサポートする必要があります。しかし、特定の薬剤は、常に公共のインターネットに接続されており、それがどんな通信員からのパケットを受信できるパブリック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].
読者は、オファー/アンサーモデルで定義された用語[RFC3264]、STUN [RFC5389]、およびUDPのNAT行動要件[RFC4787]に精通している必要があります。
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.
ピアは：セッションのエージェントのうちの一つの観点から、そのピアは、他の薬剤です。具体的には、提供者の観点から、ピアが回答です。回答の観点からは、ピアは、オファーです。
Transport Address: The combination of an IP address and transport protocol (such as UDP or TCP) port.
トランスポートアドレス：ポート（UDPやTCPなど）IPアドレスおよびトランスポートプロトコルの組み合わせ。
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のための1つ、およびRTCPのための1つ - RTPに基づいて、メディアストリームのために、メディアストリームごとに2つの成分が存在します。
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アドレスから特定のポートに結合することによって得られた候補。これは、仮想プライベートネットワーク（VPN）とレルム特定IP（RSIP）（オペレーティング・システム・レベルで住む）[RFC3102]を経て得られたものなどの物理インターフェースと論理1、上の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アドレスとポート、それがサーバにNATを介してパケットを送信したときに、エージェントのためのNATによって割り当てバインドされている候補者。サーバー再帰候補は、バインディング要求を使用してSTUNサーバによって学習、または中継とサーバーの再帰候補の両方を提供し、サーバをオンにすることができます。
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バインディング要求を送信したときに、エージェントのための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.
中継された候補：TURNを送信することにより得られた候補が、TURNサーバーにホスト候補からの要求を割り当てます。中継された候補者は、TURNサーバーに常駐しており、TURNサーバーがバックエージェントへのパケットを中継します。
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など）、およびSTUNを持っているか、サーバーを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.
STUNは、接続性を検証する目的で要求トランザクションをバインド：、接続性チェック、STUNチェックを確認してください。検査は、候補ペアのリモート候補ローカル候補から送信されます。
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.
有効なリスト：成功STUNトランザクションによって検証されたメディアストリームのための候補ペアの順序付きセット。
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.
ライト：ICEの利点を得ることがいっぱいあるピアの実装に必要ななだけを実装し、特定の機能を省略ICEの実装。 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.
制御剤：必要に応じて、候補対の最終的な選択を選択し、STUNと更新のオファーを介してそれらを知らせるための責任があるICEエージェント。いずれのセッションでは、1つのエージェントが常に制御しています。その他は、制御された薬剤です。
Controlled Agent: An ICE agent that waits for the controlling agent to select the final choice of candidate pairs.
制御エージェント：候補対の最終的な選択を選択するために、制御エージェントを待っICEエージェント。
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.
正規ノミネート一のSTUN要求と対を検証し、その指名を示すフラグを有する第二STUN要求を送信することによってそれを選択することによりメディアトラフィックのための有効な候補ペアを選ぶ工程。
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.
アグレッシブノミネート：有効な候補のペアを生成するために最初のものがメディアに使用されるように、すべてのSTUN要求、にフラグを含めることによって、メディアトラフィックのための有効な候補ペアを選ぶ工程。
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.
（3）、冗長な候補者を排除する（4）デフォルトの候補を選択し、（5）策定、（2）それらに優先順位を付け、エージェントは、（1）候補者を収集する必要があり、オファー/アンサー交換に最初のオファーを送信するためにとSDPオファーを送ります。すべてのこれらの5つのステップの最後には、フルとliteの実装のために異なっています。
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つのタイプに定義され、この仕様によって収集されている - ホスト候補、サーバー再帰候補、再帰候補ピア、および候補者を中継します。サーバー再帰候補はSTUNやTURNを使用して収集され、そして中継された候補者は、TURNを介して取得されています。ピア再帰候補は、接続性チェックの結果として、ICEの後の段階で得られています。候補の塩基は、エージェントがその候補を使用するときから送信しなければならない候補です。
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を持っています。エージェントはRTCPを使用している場合、RTPベースのメディアストリームは、RTP自体は部品1のID、及びRTCP 2のコンポーネントIDを有し、それの候補を取得しなければなりません。エージェントは、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.
エージェントは中継された候補を取得する必要があり、サーバ再帰候補を取得する必要があります。これらの要件は、プロバイダの変動を許容するためにSHOULD強度です。 STUNやTURNサーバの使用は、エージェントが、閉じたネットワークの外のエンドポイント公衆インターネットまたはに接続されることはありません、閉じたネットワークでは不要です。このような場合には、完全な実装は、ホスト候補を選択するために、デュアルスタックまたはマルチホームである薬剤のために使用されます。 TURNサーバの使用は高価であり、ICEが使用されているとき、両方のエンドポイントがアドレスとポート依存マッピングを行うNATの背後にあるとき、彼らはのみ利用されます。その結果、いくつかの展開では、このユースケースが限界であることを考えるかもしれません、とTURNサーバーを使用しないことを選択します。エージェントは、サーバ再帰または中継された候補を収集しない場合は、機能が実装され、条件が将来的に変更された場合、それは設定を通して再び有効にすることができるようにだけ、設定によって無効にすることをお勧めします。
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.
エージェントがリレーされたとサーバの両方再帰候補を収集する場合は、TURNサーバーを使用しています。それだけで、サーバ再帰候補を収集している場合、それはSTUNサーバーを使用しています。
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.
エージェントの次のペア、それが設定されているか、何らかの手段によって発見されたとSTUNやTURNサーバと各ホスト候補。 STUNやTURNサーバーが構成されている場合は、ドメイン名を設定することを推奨されており、中にDNS手順[RFC5389] STUNサーバーを検出するために使用され、DNS手順（「スタン」サービスでSRVレコードを使用） [RFC5766]（「ターン」サービスでSRVレコードを使用）でTURNサーバーを検出するために使用されます。
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レコードを介して学習されており、複数の結果が返され、）その単一のSTUNやTURNサーバーの複数の選択肢がある場合、エージェントはすべてのために（そのIPアドレスに基づいて）単一STUNやTURNサーバーを使用すべきです特定のセッションのための候補者。これは、ICEのパフォーマンスが向上します。結果は、STUNやTURNサーバーでホスト候補のペアのセットです。エージェントは、1つのペアを選択し、そのホスト候補からサーバへの結合または割り当て要求を送信します。 STUNサーバーにバインド要求が認証されていない、と応じて任意のALTERNATE-SERVER属性は無視されます。薬剤は、[RFC5389]で定義されたバインディング要求のための後方互換性モードをサポートしなければなりません。いくつかの他の手段を介してクライアントによって得られた長期的な資格情報を使用して認証されるべきである（SHOULD）要求を割り当てます。
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ミリ秒その後、エージェントは、別の新しいSTUNやTURNトランザクションを生成することができます。この取引は、（認証失敗など）回復可能なエラーで失敗しました前のトランザクション、または新しいホスト候補とSTUNやTURNサーバペアのトランザクションの再試行のいずれかとすることができます。エージェントはより頻繁ごとに1つの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:
最後に、エージェントは、各候補者に基礎を割り当てます。財団は、セッション内でスコープ付き識別子です。二つの候補者は、次のすべてに該当する同じ基礎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).
それらのベースが同じIPアドレスを持つO（ポートが異なる場合があります）。
o for reflexive and relayed candidates, the STUN or TURN servers used to obtain them have the same IP address.
O再帰と中継候補者のために、それらを取得するために使用されるSTUNやTURNサーバーは、同じ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アドレスを持って、それらを取得するために使用されるSTUNやTURNサーバーは、異なるIPアドレスを持っている、またはそのトランスポートプロトコルが異なっています。
Once server reflexive and relayed candidates are allocated, they MUST be kept alive until ICE processing has completed, as described in Section 8.3. For server reflexive candidates learned through a Binding request, the bindings MUST be kept alive by additional Binding requests to the server. Refreshes for allocations are done using the Refresh transaction, as described in [RFC5766]. The Refresh requests will also refresh the server reflexive candidate.
サーバー反射的とリレーされた候補者が割り当てられるとICEの処理が完了するまで、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と（ - 1 2 ** 31）との間の正の整数でなければならない固有の優先順位を持っていなければなりません。この優先順位は、接続性チェックの順序と候補の相対的優先度を決定するために、ICEによって使用されるであろう。
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アドレスの優先度を選択する、マルチホームである場合、候補の各種類（サーバ再帰ピア再帰、中継、およびホスト）についての優先性を決定することによって、優先順位を計算し、そして。これらの二つのプリファレンスは、候補の優先度を計算するために結合されています。その優先度は以下の式を用いて計算されます。
priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID)
優先度=（2 ^ 24）*（タイプ選好）+（2 ^ 8）*（ローカル優先）+（2 ^ 0）*（256 - コンポーネント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.
タイプおよびローカル優先値を選択するための一つの基準は、TURNサーバ、VPNサーバ、またはNATとして、メディア仲介の使用です。メディアがその候補に送信された場合は、メディアの仲介で、それは最初のトランジットは、前のメディアの仲介は受信されます。中継された候補者は、メディアの仲介を必要とする候補の一種です。もう一つは、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.
好みの選択のための別の基準は、IPアドレス・ファミリーです。 ICEは、IPv4とIPv6の両方で動作します。 V6ネットワークが切断された場合に、それは、[RFC3056]（これは、例えば、6to4リレーの故障のため）、したがってデュアルスタックホストがIPv6で接続を好むことを可能にする遷移機構を提供するが、背中のIPv4に落下します。また、ネイティブのIPv6アドレスおよび6to4アドレスの両方を持つホストを支援することができます。このような場合には、より高いローカル優先V4アドレス続いて、6to4のアドレスが続く、V6アドレスに割り当てることができます。これは、サイトが入手し、すぐにネイティブ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.
環境設定を選択するための別の基準は、トポロジカルな意識です。これは、仲介を利用する候補者のために最も有用です。エージェントは、それ自体に仲介のトポロジカル近接の知識を事前に設定または動的に発見した場合、これらのケースでは、それは近い仲介から得た候補者に高いローカルプリファレンスを割り当てるためにそれを使用することができます。
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.
候補者は、それが非ICEピアからメディアの対象になります場合は、デフォルトであると言われ、そのターゲットは、デフォルトの保存先と呼ばれています。 ICE-認識ピアと通信するときに、デフォルトの候補がICEアルゴリズムによって選択されていない場合は、メディアのデフォルトの宛先が一致するようにICE処理はSDPを「アップ修正」するために完了した後、更新オファー/アンサーが必要となりますICEによって選択された候補者。 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.
エージェントはデフォルトであるためには、候補の集合、各使用中のメディアストリームの各コンポーネントのいずれかを選択しなければなりません。それは（メディアストリームを拒否するRFC 3264で使用されている）がゼロのポートを持っていない場合、メディア・ストリームが使用中です。したがって、メディアストリームは、それが非アクティブ= [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つのIPv4候補と一つのグローバルIPv6アドレスを割り当てることが推奨されます。 liteの実装では、ICEは、動的に候補者の間で選択するために使用することはできません。のみ接続性チェックが本当に一つのアドレスまたはその他のどちらを使用するかを決定することができるので、したがって、特定の範囲から複数の候補を含む、推奨されません。
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自体は、エージェントがRTCPを使用している場合は2のコンポーネントIDは、それの候補を取得する必要があり部品1の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)
優先度=（2 ^ 24）*（126）+（8 ^ 2）*（IP優先順位）+（2 ^ 0）*（256 - コンポーネント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].
ホストがある場合、ホストは、V6またはデュアルスタックの場合V4のみ、それは65535にIP優先順位を設定すべきである、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を符号化するプロセスは、完全とLiteの実装の間で同一です。
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に関連します。 ICEは、まず、第1の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には、この属性を構築するための詳細な規則を提供します。優先順位、ファンデーション、およびコンポーネントID：属性が動作するICEのピアに通知する必要がある、その特性に加えて、候補のIPアドレス、ポート、およびトランスポートプロトコルを運びます。その種類や関連トランスポートアドレス：候補属性は、診断および他の機能のために有用である候補者についての情報を運びます。
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接続性チェックがSTUN [RFC5389]のために定義された短期資格メカニズムを使用して認証されています。このメカニズムは、クライアントとサーバ間のプロトコル機械を介して交換されているユーザー名とパスワードに依存しています。 ICEでは、オファー/アンサー交換は、それらを交換するために使用されます。この資格のユーザ名部分は、コロンで区切られた各エージェントからユーザ名断片を連結することによって形成されています。各エージェントはまた、受信した要求のためのメッセージの整合性を計算するために使用されるパスワードを、提供します。ユーザー名とパスワードの断片は、それぞれ、アイスufragと氷-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 =氷-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に基づいたストリームの場合、これは、それぞれ、CとM行にRTP候補のIPアドレスとポートを配置することによって行われます。エージェントはRTCPを利用している場合は、RFC 3605 [RFC3605]で定義されるように、それは、A = RTCP属性を使用してRTCP候補を符号化しなければなりません。 0およびb = RR：0 RFC 3556で定義されるように[RFC3556]をRTCPを使用しない場合、エージェントは、B = RSを使用することを通知しなければなりません。
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.
非ICEピアと通信するときに、メディアのデフォルト先となるトランスポート・アドレスは、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拡張を識別する一連のトークンが含まれているの申し出または回答を可能にすることにより、拡張性を提供します。エージェントがICE拡張をサポートしている場合、それは氷のオプション属性で、その拡張子のために定義されたトークンを含まなければなりません。
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
asd88fgpdd777uzjYhagZg A =氷ufrag：IP4 10.0.1.1 S = Cの= IP4 192.0.2.3 INさt = 0、A =氷PWD IN V = 0 0 = jdoeの2890844526 2890842807 8hhY M =オーディオ45664 RTP / AVP 0 B = RS：0 B = RR：= rtpmap 0 A：0 PCMU / 8000 =候補：1 UDP 2130706431 10.0.1.1 8998標準ホストA =候補2：1 UDP 1694498815 192.0.2.3 45664標準の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.
エージェントはその申し出またはその答えを送信した後は、そのエージェントは、各候補者にSTUNとメディアパケットの両方を受け取る準備が必要です。セクション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.
エージェントが最初のオファーを受けたとき、それは、オファーがICEをサポートしている場合、チェックし、自身の役割を決定、候補者を集め、それらに優先順位を付け、デフォルトの候補を選択し、エンコードと答えを送って、そして完全な実装のために、チェックリストを形成し、接続を開始しますチェック。
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内の各メディアストリームのために、そのメディア・ストリームの各コンポーネントのデフォルトの出力先は、候補属性に表示されて、いる場合は、この仕様で定義されたICEの手続きを進めてまいります。例えば、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:
この条件が満たされない場合、エージェントは、以下の例外を除いて、本明細書の残りの部分で説明ICE機構のいずれかを使用することなく、通常の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. =候補属性があったので、エージェントがICEを進めるのではなく、メディアストリームのデフォルトの保存先をマッチどれも、エージェントがその答えで、A =氷不一致属性が含まれていない必要があります。
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アドレスのTURNサーバーの権限を作成する必要があり、TURNサーバーを通じて学習しました。これを行わない場合は、ピアからのメディアストリームの最初のパケットが失われる可能性があります。
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.
各セッションについて、各エージェントが役割を引き受けます。制御および制御 - 二つの役割があります。制御エージェントは、通信に使用される最終候補ペアの選択に責任があります。完全なエージェントの場合、これは指名各メディアストリームのために、必要に応じICEの選択、に基づいて更新のオファーを生成するためにICEで使用できる候補ペアを意味しています。 liteの実装のために、制御剤であること（IPv4で、しかつのペアがある）を提供し、応答におけるものに基づいて候補対を選択し、その後必要なときに、その選択を反映して更新されたプランを生成する手段（それがあります）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.
支配的な役割を取る必要がありICE処理を開始したプランを生成したエージェント、およびその他のは、制御された役割を取る必要があります：両方のエージェントがいっぱいです。両方のエージェントは、チェックリストを形成ICE状態マシンを実行し、接続性チェックを生成します。制御剤は、ICEによって選択される対を指名するセクション8.1のロジックを実行する、およびセクション8.1.2に記載したように、両方の薬剤は、ICEを終了します。珍しいケースでは、付録B.11に記載し、両方のエージェントが誤ってそれらが制御または制御されていると信じてすることは可能です。 （つまり、64ビットの正の整数である）1 - これを解決するために、各エージェントは、乱数を選択する必要があり、一様に0と（** 64 2）間に分配、タイブレーカと呼ばれます。セクション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つのライト：フルエージェント支配的な役割を取る必要があり、かつライトエージェントは、制御された役割を取る必要があります。完全なエージェントは、チェックリストを形成ICE状態マシンを実行し、接続性チェックを生成します。そのエージェントは、ICEによって選択される対を指名するセクション8.1のロジックを実行し、ICEを終了するセクション8.1.2のロジックを使用します。 liteの実装では、単に、接続性チェックのために耳を傾け、それらを受け取り、それらに対応して、8.2節で説明したようにICEを締結します。 liteの実装では、各メディアストリームのためのICE処理の状態が実行されていると考えられる、とICEの全体的な状態が実行されています。
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.
支配的な役割を取る必要がありICE処理を開始したプランを生成したエージェントを、もう一方は、制御的な役割を取る必要があります：どちらも、liteの。この場合、接続性チェックは、これまで送信されません。オファー/アンサー交換が完了すると、むしろ、各エージェントは、接続性チェックなしセクション8で説明した処理を行います。両方の薬剤は、それらが制御または制御されていると信じてすることが可能です。後者の場合、競合がオファー/アンサー交換を運ぶシグナリングプロトコルにおけるグレア検出機能によって解決されます。各メディアストリームのためのICE処理の状態が実行されていると考えられる、とICEの全体的な状態が実行されています。
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.
役割はセッションのために決定されるとICEが再起動されない限り、彼らが持続します。 ICEの再起動（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.
完全な実装とLiteの実装については、セクション4.2は、セクション4.1.1に記載したように回答候補を収集するための方法は、提供者のためのプロセスと同じです。このプロセスは前にユーザーに警告し、オファーの受信時に直ちに開始することを推奨されます。エージェントが起動するとこのような集会が開始されます。
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.
回答で候補を優先順位付けするためのプロセスは、完全な実装とLiteの実装については、セクション4.2は、セクション4.1.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.2は、セクション4.1.4に記載したように、提供者続くプロセスと同じです。
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.
まず、エージェントは、メディアストリーム（と呼ばれるLOCAL候補）と、それはそのメディアストリームのための（と呼ばれるREMOTE候補）ピアから受信した候補者と対それらをするためにその候補の各々をとります。セクション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の候補を提供するとき、これは起こるだろう、と他にはありません。別の例として、提供者は、SDP属性[RFC5761]を介してSDPでそれを行うことができ、同じポートと信号にRTPとRTCPを多重化することができます。回答は、このような多重化を行うことができれば、オファーがわからないので、オファーがメディアストリームごとに2つのコンポーネントを持つようしかし、オファー側は、別々のポート上のRTPとRTCPの候補を含んでいます。合わせたRTP / RTCPマルチプレクサのための - 回答者がそのような多重化を行うことができれば、それは、各候補のためだけの単一成分を含むことになります。 ICEはこの候補者のために1つだけのコンポーネントがあったかのように働くことになります。
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)
一対の優先= 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式です。優先順位が割り当てられると、エージェントは、優先順位の順に候補対をソートします。二対が同一の優先権を持っている場合は、それらの間での順序は任意です。
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:
チェックリスト内の各候補ペアは、基礎と状態を持っています。財団は、ペアでのローカルとリモート候補の基礎の組み合わせです。各メディアストリームのためのチェックリストが計算された後の状態が割り当てられます。状態が持つことができる5つの潜在的な値があります。
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.
待機中：チェックはこのペアのために行われていない、とすぐそれは、チェックリストの最も優先順位の高い待機ペアであるように行うことができます。
In-Progress: A check has been sent for this pair, but the transaction is in 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.
冷凍：このペアのチェックが行われていない、といくつかの他のチェックが成功するまで、それはまだこのペアは、凍結を解除し、待機状態に移行することができ、実行することはできません。
As ICE runs, the pairs will move between states as shown in Figure 7.
ICEを実行すると、図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.
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つの活性のチェックリストと呼ばれている待っているペア、および冷凍冷凍のチェックリストと呼ばれているすべてのペアでのチェックリストとチェックリスト。
The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are three states:
チェックリスト自体は、そのメディアストリームのためのICEチェックの状態をキャプチャ状態、関連付けられています。 3つの状態があります。
Running: In this state, ICE checks are still in progress for this media stream.
実行：この状態では、ICEのチェックは、このメディアストリームのためまだ進行中です。
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.
失敗しました：この状態では、ICEのチェックは、このメディアストリームのために正常に完了していません。
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.
すべてのメディアストリーム全体ICE処理もそれに関連する状態を持っています。この状態は、ICEの処理が進行中である間、実行しているに等しいです。 ICEの処理が完了し、それが成功せずに失敗した場合には失敗したときの状態が完成します。状態間の遷移のためのルールは以下の通りです。
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節で説明したように、エージェントがチェックリストを計算したら、それはアクティブな各チェックリストのためのタイマーを設定します。タイマー火災Nはアクティブなチェックリストの数（最初は、一つだけアクティブのチェックリストがある）である、すべてのTa * N秒、。実装はそれほど頻繁にこれよりも起動するようにタイマーを設定することができます。実装は、彼らが各メディアストリームのために同時に発火しないように、これらのタイマーを広げるために世話をする必要があります。 Nによって乗算部16で説明したようにTaと再送タイマーRTOは、計算され、この集計チェックスループットは、すべてのアクティブなチェックリストの間で分割されることを可能にします。最初のタイマーが起動直後に、エージェントは（唯一のアクティブなチェックリストがあるので）接続は、Ta秒後に次のチェックが続くオファー/アンサー交換が行われた瞬間に、チェックが実行されるように。
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:
そのようなペアがある場合○：
* 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.
*そのペアのリモート候補者にそのペアのローカル候補からSTUNチェックを送信します。この目的のためのSTUN要求を形成するための手順は、セクション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.
ICEは、SIPで使用されるとき、フォークは、答えの多数を生成する単一のオファーをもたらし得ます。その場合、各回答の完全並列かつ独立に、ICE進み、そうでペア、チェックリスト、状態、および独自のセットを用いて、独立したオファー/アンサー交換としてのオファーの組み合わせと、各回答を処理します。一組の影響他のどの処理における唯一のケースは、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.
オファー側はこれまで=氷の不一致がSDPに属性を生成しないことを除いて、セクション5.1で説明したようにオファー側の論理は、回答のそれと同じです。
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.
いくつかのケースでは、答えは=候補がメディアストリームの属性を省略することができ、その代わりにSDP内のメディアストリームの1つまたは複数のために、A =氷不一致属性が含まれます。シグナリング仲介は、対応する候補属性を変更することなく、メディアコンポーネントのデフォルトの宛先を変更しているため回答がICEをサポートしていることを提供者が、そのICE処理と、この信号は、セッションのために使用されませんでした。この現象が発生することができます例の議論については、セクション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]とは対照的に、すべてのICEの実装は、[RFC5389]に準拠するために必要とされています。しかし、完全な実装のに対し（STUNクライアントとして動作する）のチェックを生成し、（STUNサーバとして機能する）、それらを受け取ることになります両方、liteの実装では、唯一の小切手を受け取ることになりますので、唯一STUNサーバーとして機能します。
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.
接続性チェックが中継された地元の候補者を使用して送信されている場合、それはすでに以前に1を作成していない場合、クライアントは、最初の許可を作成する必要があります。それは、リモート候補のIPアドレスへの特定の中継候補者の許可を作成するために、TURNサーバーを伝えていた場合は、以前に1を作成しているだろう。許可を作成するには、エージェントが[RFC5766]で定義された手順に従います。許可は、リモート候補のIPアドレスに向けて作成する必要があります。接続性チェックのためのケースの権限は通常CreatePermission要求を使用して作成されている、ICEが完了するまで、エージェントがTURNチャネルの作成を延期することが推奨されます。確立されると、エージェントは、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]はバインディング要求が構築され、生成されている方法を説明します。接続性チェックは、STUN短期資格情報メカニズムを利用しなければなりません。 RFC 3489との互換性を維持するためのサポートを使用したり、接続性チェックと仮定してはなりません。 FINGERPRINTメカニズムは、接続性チェックのために使用されなければなりません。
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はPRIORITY、USE-CANDIDATE、ICE制御、およびICE-制御を含むいくつかの新しい属性を、定義することによって、STUNを拡張します。これらの新しい属性は、正式にセクション19.1で定義されており、その使用法は以下のサブセクションで説明されています。これらのSTUNの拡張機能はICEに使用接続性チェックにも適用可能です。
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.
エージェントは、その結合リクエストでPRIORITY属性を含まなければなりません。 1は、このチェックの結果として学習しなければならない属性は、（方法については、セクション7.1.3.2.1を参照してください、ピア再帰候補に、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.
それは制御の役割であり、それは支配的な役割である場合、要求におけるICE制御属性を含まなければならない場合、エージェントは、要求の中のICE制御の属性を含まなければなりません。いずれかの属性の内容は、セクション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).
接続性チェックとしてのバインディング要求をSTUN短期資格メカニズムを利用しなければなりません。資格のユーザ名は、コロン（「：」）で区切られた要求を、送信エージェントのユーザ名断片とピアによって提供されるユーザ名断片を連結することによって形成されています。パスワードは、ピアによって提供されたパスワードと同じです。例えば、エージェントLが申し出であり、そしてRエージェントは回答である場合を考えます。エージェントLは、その候補者のためのLFRAGのユーザ名断片とLPASSのパスワードが含まれています。エージェントRはRFRAGのユーザ名断片とRPASSのパスワードを提供しました。 LFRAGとRPASSのパスワード：LからRへの接続性チェックは、ユーザ名RFRAGを利用しています。 RFRAGとLPASSのパスワード：LへのRから接続性チェックは、ユーザー名LFRAGを利用しています。応答が要求（USERNAME属性が応答に存在しないことに注意してください）と同じユーザ名とパスワードを利用しています。
If the agent is using Diffserv Codepoint markings [RFC2475] in its media packets, it SHOULD apply those same markings to its connectivity checks.
エージェントは、そのメディアパケットにDiffservのコードポイント・マーキング[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制御の属性が含まれていた場合、それはまだ行っていない場合、エージェントは、制御ロールに切り替える必要があります。要求はICE制御属性が含まれていた場合、それはまだ行っていない場合、エージェントは、制御されたロールに切り替える必要があります。それが切り替わった後は、薬剤は、そのチェック、トリガーチェックキューに487を生成された候補ペアをエンキューする必要があります。そのペアの状態が待機に設定されています。トリガーされた小切手が送られると、その新しい役割を反映したICE-制御またはICE制御の属性が含まれます。タイブレーカーの値が再選択されてはならないこと、しかし、注意してください。
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項）を再計算するためにエージェントを必要とするであろう。役割の変化も、エージェントが指名対を選択し、ICEの終了時に更新のオファーを生成するための責任があるかどうかに影響します。
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
エージェントは、接続性チェックのためのICMPエラーの受信をサポートするかもしれません。 STUNトランザクションがICMPエラーが発生した場合、エージェントは失敗にペアの状態を設定します。 STUNトランザクションが発生した場合
STUN error response that is unrecoverable (as defined in [RFC5389]) or times out, the agent sets the state of the pair to Failed.
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.
応答の送信元IPアドレスとポートOたバインディング要求が送信された宛先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そのベースは、STUN確認を送信した候補ペアのローカル候補に等しく設定されます。
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.
セクション4.1.1.3で説明したように、O創業が選択されています。
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の手順に基づいて、それから生成されます。エージェントが生成されます有効なペアで1以外の他のリモートの候補者とのピア再帰候補をペアリングすることを希望する場合は、エージェントは、ピア再帰候補者を含み、更新のオファーを生成してもよいです。これは、他のすべてのリモートの候補者とペアにされるようになります。
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.
エージェントは、そのローカル候補応答のマッピングされたアドレスに等しく、その遠隔候補要求が送られた先のアドレスに等しい候補ペアを構成します。それはSTUNの接続性チェックによって検証されているので、これは、有効なペアと呼ばれています。有効なペアは、チェックリスト内の異なる対を等しくすることができるか、またはしない現在どのチェックリスト上のペアであってもよいし、チェックを発生対に等しくてもよいです。一対のチェックを生成または現在のチェックリスト上にあるペアに等しい場合、それはまた、各メディアストリームのためのエージェントによって維持されている有効なリストに追加されます。このリストは、ICE処理の開始時に空で、チェックが実行されるように、有効な候補対が得られる、充填します。
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.
ペアが任意のチェックリストにはならないだろうということは非常に一般的になります。チェックリストは、その地域の候補者再帰サーバーは決してありませんペアを持っていることを思い出してください。これらのペアは、地元の候補者は、サーバ再帰候補の塩基に変換した後、彼らは冗長だったら剪定ました。 STUNチェックへの応答が到着すると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でその候補の合図を優先に等しいです。それは再帰ピアがある場合は、完了したばかりのバインディング要求に配置されたエージェントの属性PRIORITYに等しいです。リモート候補の優先順位は、ピアの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.このメディアストリームのすべてのコンポーネントのための有効なリストにペアが存在する場合（これは部品点数がSDP回答にオファーは異なるでシグナリングの場合に、使用されている構成部品の実際の数である）、成功このチェックの他のメディアストリームのためのチェックをアンフリーズします。このステップは、検討中の有効なリストは、すべてのコンポーネントのペアを持っていますが、後続のすべての時間は、チェックが成功し、その有効なリストにさらに別のペアを追加するだけではなく、最初の時間を追っていることに注意してください。エージェントは、順番に各他のメディアストリームのためのチェックリストを調べます。
* 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に設定されています。このフラグは、それが最も高い優先順位は、その指名フラグが設定されているものの中1であれば、この有効なペアがメディアのために使用されるべきであることを示しています。これは、このメディアストリームまたはすべてのメディアストリームのためのICE処理を締結することができます。第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.
エージェントが制御因子である場合、応答は、それ自体がUSE-CANDIDATE属性を持っていた要求に応答して送信されたトリガされたチェックの結果である可能性があります。この場合は、セクション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.
エージェントは要求を認証し、メッセージの整合性チェックを実行するために短期的な資格情報を使用しなければなりません。それが第1の値は、進行中のセッションのオファー又はアンサー内のエージェントによって生成されたユーザ名断片に等しい結腸で区切られた2つの値で構成されている場合、エージェントは、ユーザ名が有効であることを考慮しなければなりません。それは可能である（実際は非常に可能性が高い）、オファーがピアからの回答を受信する前にバインディング要求を受信すること。この場合、エージェントは、直ちに（セクション7.2.1.2に記載されるようにマッピングされたアドレスの計算を含む）応答を生成しなければなりません。エージェントは、応答を生成するために、この時点で十分な情報を有しています。ピアからのパスワードが必要とされていません。答えが受信されると、それはすなわち、7.2.1.3、7.2.1.4、および7.2.1.5完全な実装のために、必要な残りの手順を続行しなければなりません。複数のSTUNリクエストが答えの前に受信されている場合、これはいくつかのペアがトリガーチェックキューにキューに入れられなければ可能性があります。
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.
エージェントは、ALTERNATE-SERVERメカニズムを利用てはならない、とそれは指紋メカニズムを利用しなければならない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コードポイントマーキング[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.
制御一方と制御される1つ - 通常、セクション5.2において役割を選択するためのルールは異なる役割を選択する各エージェントをもたらすであろう。両方のエージェントが同じ役割を選択するしかし、異例のコールフローでは、通常、第三者呼制御を利用し、それが可能です。このセクションでは、このケースをチェックし、それを修復するための手順を説明します。
An agent MUST examine the Binding request for either the ICE-CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these procedures:
エージェントは、ICE-制御またはICE制御の属性のいずれかのバインディング要求を調べる必要があります。これは、これらの手順に従う必要があります。
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.
どちらもICE制御もICE制御が要求に存在している場合は、O、ピアエージェントは、この仕様の以前のバージョンを実装している場合があります。そこ紛争かもしれないが、それを検出することはできません。
o If the agent is in the controlling role, and the ICE-CONTROLLING 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-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role.
エージェントのタイブレーカーがより大きい又はICE制御属性の内容に等しい場合*、エージェントは、バインディングエラー応答を生成し、エラーコードは487（ロールの競合）の値を持つ属性が、その役割を保持含みます。
* If the agent's tie-breaker is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role.
エージェントのタイブレーカーはICE制御属性の内容よりも小さい場合*、エージェントが制御ロールに切り替わります。
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.
エージェントのタイブレーカーがより大きいまたはICE制御属性の内容に等しい場合*、エージェントは、制御ロールに切り替わります。
* 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.
エージェントのタイブレーカーは、ICE制御属性の内容よりも小さい場合*、エージェントは、バインディングエラー応答を生成し、エラーコードは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.
エージェントが管理役割であるとICE制御属性が要求に存在していた、またはエージェントが制御役割にあったとICE制御の属性が要求に存在した場合には、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項）を再計算するためにエージェントを必要とするであろう。役割の変化も、エージェントがICEの終結の時ノミネート組と生成された更新のオファーを選択するための責任があるかどうかに影響します。
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
要求が中継された候補者で受信されるため、ソーストランスポートアドレスをSTUN処理に使用される（即ち、XORマッピングされたアドレス属性の世代）TURNサーバによって見られるようなトランスポート・アドレスです。バインディング要求がデータ表示を介して配信された場合、ソーストランスポートアドレスは、データ指示メッセージのXOR-PEER-ADDRESS属性に存在するであろう。もし
Binding request was delivered through a ChannelData message, the source transport address is the one that was bound to the channel.
結合要求が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候補の優先順位は、要求からPRIORITY属性に設定されています。
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.
この候補のコンポーネントIDは、要求が送信されたローカル候補のコンポーネントIDに設定されているoを。
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:
次に、エージェントは、そのローカル候補STUN要求を受信したトランスポート・アドレス、および要求があったピア再帰遠隔候補とすることができる（から来たソース輸送アドレスに等しいリモート候補に等しいペアを構築しますちょうど）を学びました。局所的な候補は、（それがリレーを介して受信される場合）または中継候補（要求が中継を介して受信しなかった場合の）ホスト候補になります。地元の候補者は、サーバ再帰候補になることはありません。両方の候補者がエージェントに知られているので、それは彼らの優先順位を取得し、候補ペアの優先度を計算することができます。このペアは、チェックリストに検索されます。いくつかの成果の一つが存在することができます：
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.
そのペアの状態が進行中である場合は*、エージェントは、進行中のトランザクションを取り消します。キャンセルは、エージェントは、要求を再送信しないことを意味失敗する応答の欠如を処理しませんが、応答のトランザクション・タイムアウトの時間を待っています。また、エージェントがトリガチェックキュー内のペアをエンキューすることによって（新しいSTUNバインディング要求トランザクションを表す）、そのペアのための新たな接続性チェックを作成する必要があります。ペアの状態は、待機に変更されます。
* 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.
ペアの状態が失敗した場合*、トリガされたチェックキュー内のペアをエンキューすることで、待機中に変更され、エージェントは（要求トランザクションをバインド新しいSTUNを表す）は、そのペアのための新たな接続性チェックを作成する必要があります。
* 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の背後にあるICEの迅速な完了を促進するために行われます。
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に記載したように、それが構築されて処理されます。これらの手順は、ピアの転送アドレス、ユーザー名フラグメント、およびパスワードを知っているエージェントを必要としています。リモート候補のユーザ名断片はちょうど受信されたバインディング要求にUSERNAMEのコロンの後の部分に等しいです。その名の断片を使用して、エージェントは、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:
エージェントが受信したバインディング要求がUSE-CANDIDATE属性セットを持っていたし、エージェントが管理役割になっている場合、エージェントは、セクション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に有効なペアでノミネートフラグを設定します。これは、このメディアストリームのためのICE処理を終了してもよいです。第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、結果の有効なペアは、その指名フラグが設定されています。それが到着したとき、これは、このメディアストリームのためのICE処理を終了してもよいです。第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にそのペアにノミネートフラグを設定します。有効なリストは、各コンポーネントの候補ペアが含まれている場合はICEの処理は、メディアストリームのための完了したと見なされます。
This section describes how an agent completes ICE.
このセクションでは、エージェントがICEを完了する方法について説明します。
Concluding ICE involves nominating pairs by the controlling agent and updating of state machinery.
結論ICEは、制御エージェントと状態機械の更新によって指名ペアを必要とします。
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.
通常の指名や積極的な推薦：制御エージェントは、二つの技術のいずれかを使用して、ICEが選択するペアを指名します。そのピアがliteの実装を持っている場合、エージェントは、通常の指名アルゴリズムを使用しなければなりません。そのピアエージェントが理解していないこと（氷のオプションに存在するが、ピアから属性）ICEオプションを使用している場合、エージェントは、通常の指名アルゴリズムを使用しなければなりません。そのピアが完全実施され、任意のICEオプションを使用していないか、またはエージェントによって理解ICEオプションを使用している場合、エージェントは、積極的なまたは通常の指名アルゴリズムのいずれかを使用することができます。それは大きな安定性を提供しますので、定期的なアルゴリズムが推奨されます。
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.
定期的に指名すると、エージェントは、USE-CANDIDATE属性を省略し、それぞれが完全なチェック、いくつかの数をすることができます。メディアストリームのコンポーネントの正常に完了一つ以上チェックしたら、有効なペアが生成され、有効なリストに追加されます。エージェントは、いくつかの停止基準が満たされるまでチェックを継続することができますし、その後の評価基準に基づいて、有効なペアの間で選択されます。チェックを停止するための、有効なペアを評価するための基準は、完全にローカルな最適化の問題です。
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.
制御剤が有効なペアを選択すると、それは、USE-CANDIDATE属性で、この時間（トリガーされたチェックキューにチェックを生成したペアをエンキューすることによって）この有効なペアを作成し、チェックを繰り返します。このチェックは、と設定するだけで、その対の指名フラグを引き起こし、（以前はなかったので）成功する必要があります。その結果、各成分の有効リスト内の唯一の単一指名ペアが存在するであろう、チェックリストの状態を完了するために移動したときに、その正確な対は、そのコンポーネントのメディアを送受信するための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を選んで、唯一の候補ペアとUSE-候補が存在属性とそのペアのチェックを生成しなければならないということです。定期的な指名も（セクション14を参照）実装の変化にICEの回復力を向上させます。定期的な指名は、両方のエージェントが積極的なアルゴリズムで発生する可能性があります任意の過渡セレクション、なし、メディアのための単一のペアに収束することができ、また、より安定しています。通常の指名の欠点は、行われるために追加のチェックを必要とするため、レイテンシを増加することが保証されていることです。
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.
積極的に指名して、制御エージェントは、すべてそれが送信チェックでUSE-CANDIDATE属性を含んでいます。コンポーネントの最初のチェックが成功したら、それは有効なリストに追加され、その指名フラグが設定されています。すべてのコンポーネントが有効なリストにノミネートペアを持っている場合は、メディアが最優先指名のペアを使用して流れ始めることができます。ただし、ため、エージェントは、その指名フラグが設定されているために、別の有効なペアを引き起こし、別のチェックがまだ完了しても、その小切手の全てでUSE-CANDIDATE属性が含まれています。 ICEは常にメディアのために使用されるものとして有効なリストから最も優先度の高いノミネート候補ペアを選択します。これにより、選択されたペアは、実際にそれが安定するまでの過渡の選択のセットで得られた、完全な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:
制御および制御の両方の薬剤については、ICE処理の状態が有効なリストで、チェックリストの状態にノミネート候補対の存在に依存します。任意の時点で、以下の例以上を適用することができ、ことに注意してください：
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、ICEの処理は続行されます。
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メディアストリームと実行されたチェックリストの状態のために有効なリストでペアを指名少なくとも一つがある場合：
* 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.
*エージェントが完了し、全体的なICE処理の状態を設定します。
* 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.
*すべてのチェックリストが失敗している場合は、ICEの処理は全体的に失敗状態にあるとみなされ、エージェントがセッションに失敗したことを考慮しなければならない、ICEを再起動しません。また、制御エージェントは、セッション全体を終了する必要があります。
* 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.
*他のメディアストリームのためのチェックリストの少なくとも一方が完了した場合、制御エージェントは、その更新のオファーにセッションから失敗したメディアストリームを削除する必要があります。
* If none of the check lists for other media streams are Completed, but at least one is Running, the agent SHOULD let ICE continue.
他のメディアストリームのためのチェックリストのどれもが完了されていないが、少なくとも一つが実行されている場合は*、エージェントはICEを継続させてください。
Concluding ICE for a lite implementation is relatively straightforward. There are two cases to consider:
liteの実施のためのICEを締結することは比較的簡単です。考慮すべき2つのケースがあります。
The implementation is lite, and its peer is full.
実装はライトであり、そのピアがいっぱいです。
The implementation is lite, and its peer is lite.
実装はライトであり、そのピアは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.
ICEの結論の効果は、エージェントは8.3節で説明したように、ICEによって使用されなかった割り当てられたホスト候補を解放することができるということです。
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.
この場合、エージェントは、そのピアから接続確認を受信します。エージェントは、メディアストリームの各成分、完了に実行され、そのメディア・ストリームを移動するためのICE処理の状態のためにUSE候補属性を含む接続確認を受信した場合。すべてのメディアストリームのためのICE処理の状態が完了すると、ICE処理の状態は全体的に完成しています。
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の実装は、自身がそのICE処理は、メディアストリームのために失敗したかを決定することはありません。むしろ、完全なピアはその決意を行いますし、その後の提供に失敗したメディアストリームを削除するか、再起動してください。
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).
オファー/アンサー交換が完了すると、両方の薬剤は、その候補者とそのピアのそれらを調べます。各メディアストリームの場合、そのメディアストリームのためのピアの候補者との独自の候補者まで各エージェントのペア。二つの候補は、彼らが同じコンポーネントのためのものであるとき、同じトランスポートプロトコル（この仕様で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ペアを持っていた場合、そのメディアストリームのためのICE処理の状態を完了に設定されています。すべてのメディアストリームが完了している場合は、ICE処理の状態は、全体的な完了に設定されています。これは、常にIPv4のみです実装のためのケースとなります。
o If there is more than one pair per component:
コンポーネントごとに複数のペアがある場合○：
* 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.
オファーが送信された場合*エージェントがICE処理の状態をアップデートしてはいけません。これ以降のオファーが完了した場合、制御剤は、すべてのメディアストリームのために完成し、完成に全体的なICE処理の状態にICE処理の状態を変更する必要があります。制御エージェントの状態は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章の手順では、エージェントがSTUN要求をリッスンし、そのストリームの処理が完了しても一度、メディアストリームのため、トリガーチェックを生成し続けることを続けることが必要です。エージェントが送信またはICEで選択されなかった候補者に検査を受けて中止して、候補者を解放するためにそれが安全であるとき、このセクションのルールは説明しています。
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.
ICEは、SIPで使用され、そして提供が複数の受信者に二股され、並列にICEが進行し、それぞれ独立して回答と、全て同じローカル候補を使用する場合。 ICEの処理は、それらの候補を使用して、メディアストリームのすべてのピアのために完成した状態に達した後は、その候補者のチェックをトリガエージェントは、さらに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の実装では、無料の候補とすぐICE処理は、それらの候補を使用して、すべてのメディアストリームのためのすべてのピアのために完成した状態に達したとして、ICEが選択しない場合があります。
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章の規則は、ICEは、デフォルトのペアから別の候補対を選択したとき制御剤は、ICE処理の終了時に更新のオファーを送信します。このセクションでは、後続のオファーとアンサーを構築するための規則を定義します。
Should a subsequent offer be rejected, ICE processing continues as if the subsequent offer had never been made.
その後のオファーがなされていなかったかのように、後続のオファーが拒否されるべき、ICEの処理は続行されます。
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処理を再起動する場合があります。 ICEの再起動、名前が示すように、ICE処理のすべての以前の状態がフラッシュされることになりますとチェックが新たに開始します。 ICEの再起動やブランドの新しいメディアセッションの唯一の違いは、再起動時に、メディアが以前に検証ペアに送信し続けることができる、ということです。
An agent MUST restart ICE for a media stream if:
エージェントがあれば、メディアストリームのためのICEを再起動する必要があります。
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].
これらの規則は、0.0.0.0にC線にIPアドレスを設定するとICEの再起動の原因となりますことを示唆しています。したがって、ICEの実装では、呼保留のためにこのメカニズムを利用してはいけません、その代わりに[RFC3264]に記載されているよう=非アクティブ、および= sendonlyのAを使用しなければなりません。
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を再起動するには、エージェントが氷-PWDおよび提供におけるメディアストリームのためのアイスufragの両方を変更する必要があります。 1つのオファーでセッションレベルの属性を使用することが許されることに注意してください、それ以降の提供におけるメディアレベル属性と同じ氷-PWDまたはアイスufragを提供します。これは、パスワードの変更は、その表現中だけの変化ではなく、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.
エージェントは、このメディアストリームの最初のオファーに（4.3節を参照）と同じように、このメディアストリームのためのSDP内のフィールドの残りの部分を設定します。その結果、候補の集合は、そのストリームの前の候補のいくつか、なし、またはすべてを含んでいてもよいし、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で定義された他のICE-関連の属性を含んではならない含んではいけません。
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.
エージェントが新しいメディアストリームを追加したい場合は、これはそのメディアストリームのための最初のオファーだったかのように、それは（4.3節を参照）、このメディアストリームのためのSDPのフィールドを設定します。これは、ICE処理は、このメディアストリームのために開始します。
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.
追加の動作は、そのメディアストリームの状態ICE処理に依存します。
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.
エージェントが以前に確立し、そのためICEチェックが実行状態であるたメディアストリームを含む更新のオファーを生成した場合、エージェントは、ここで定義された手順に従います。
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.
エージェントが以前に確立し、そのためICEチェックが完了した状態にありましたメディアストリームを含む更新のオファーを生成した場合、エージェントは、ここで定義された手順に従います。
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 =リモート・候補者は、そのチェックリストが完了した状態にある各メディアストリームのための属性を含まなければなりません。属性は、そのメディア・ストリームの各コンポーネントの有効なリストで最も優先度の高いノミネートペアからのリモート候補者が含まれています。制御エージェントは、そのペアを選択しますが、更新オファーはしてもこれらのペアが有効である知っている、ましてや選択しない制御エージェントへの接続性チェックを打つことにより、競合状態を避けるために必要とされます。この競合状態に推敲については、付録B.6を参照してください。
This section describes procedures for lite implementations for existing streams for which ICE is running.
このセクションでは、ICEが実行されているため、既存のストリームのliteの実装のための手順を説明します。
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の実装は、後続の提供で追加のホスト候補を追加してはなりません。エージェントは、追加の候補を提供する必要がある場合、それはICEを再起動する必要があります。
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の実装では、メディアストリームの各コンポーネントの有効なリストで1つだけの候補ペアが常にあります。また、エージェントは、各デフォルト先の候補属性を含まなければなりません。
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 =リモート候補が各メディアストリームのための属性を含まなければなりません。属性が有効なリスト（各メディアストリームのコンポーネントごとに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で検証手順を再適用する必要があります。確かに、以前のオファー/アンサー交換が使用されていないICEが生じている可能性があり、それは、その後の交流の結果として使用されています。
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 =アイスufragまたは=氷-PWD属性の変更が含まれていた場合、それはICEは、このメディアストリームのために再起動されることを示しています。すべてのメディアストリームが再開された場合、ICEは、全体的に再起動されます。
If ICE is restarting for a media stream:
ICEは、メディアストリームのために再起動されている場合：
o The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in the answer.
Oエージェントは、A =アイスufragと答えにおける=氷-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.
エージェントは、このメディアストリームへの最初の回答で（4.3節を参照）と同じように、このメディアストリームのためのSDP内のフィールドの残りの部分を設定します。その結果、候補の集合は、そのストリームの前の候補のいくつか、なし、またはすべてを含んでいてもよいし、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節を参照）の答えのフィールドを設定します。これは、ICE処理は、このメディアストリームのために開始します。
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で定義された他のICE-関連の属性を含んではならない含んではいけません。
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を再起動する必要があります。 ICEは答えで再起動することはできません。
Additional behaviors depend on the state of ICE processing for that media stream.
追加の動作は、メディアストリームのためのICE処理の状態に依存しています。
9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates
9.2.2.1。 ICEが動作している既存のメディアストリームと無遠隔-候補
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で説明したように、答えの建設のための規則は、オファーのためのものと同じです。
9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates
9.2.2.2。完成したICEとの既存のメディアストリームと無遠隔-候補
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 =リモートの候補者が答えに属性を含めません。
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との申し出を受けます。この属性は、オファーの領収書、および回答ICEによって選択される候補者に伝えるの結合応答の受信との間の競合状態に対処するためのオファーに存在しています。この競合状態の説明については、付録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の行の内容、及びaは= RTCP RTCPの属性）
o Setting the local candidate equal to the transport address for that same component in the a=remote-candidates attribute in the offer.
=リモート候補がオファーに属性Aで同じコンポーネントのトランスポート・アドレスに等しいローカルな候補を設定O。
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.
ペアのどれも進行中でないと、少なくとも1つが失敗した場合、O、そのようなネットワークパーティションまたは重大なパケット損失などのネットワーク障害は、発生している可能性が最も高いです。エージェントは、リモート候補が存在していなかった属性かのように、このメディアストリームのための答えを生成し、このストリームのための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ペアの少なくとも一方が進行中である場合、これらのチェックが完了すると、エージェントは待つ必要があり、それぞれが完了すると全く負け組がなくなるまで、このセクションの処理をやり直します。
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).
受け取ったオファーは、リモート・候補者がメディアストリームのための属性が含まれている場合、エージェントは、メディアストリームの各コンポーネントの候補対を形成することにより、：のそのコンポーネントのオファー側のデフォルトの宛先に等しいリモート候補を設定するO（例えば、内容mおよびRTPの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.
=リモート候補がオファーに属性Aで同じコンポーネントのトランスポート・アドレスに等しいローカルな候補を設定O。
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.
その後、メディアストリームのための有効なリストに候補者を配置します。そのメディアストリームのためのICE処理の状態を完了に設定されています。
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.
オファー/アンサー交換は、メディアストリームを削除、または答えが提供されたメディアストリームを拒否した場合、エージェントは、そのメディアストリームのための有効なリストをフラッシュする必要があります。これは、そのメディアストリームのために進行中のSTUN取引を終えなければなりません。エージェントは、そのメディアストリームのためのチェックリストを削除し、それのために保留中の通常のチェックを解除しなければなりません。
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ではありません同じ基盤と同じチェックリストのすべての冷凍ペアは、それらの状態が待機に設定されています。特定のチェックリストについては、成功状態でそのメディアストリームの各成分のペアがあり、エージェントが他のすべてのメディア・ストリームの最初のコンポーネントのすべての冷凍ペアの状態を移動（従って異なるチェックリストで）、もしと待機中に同じ基盤。
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節で説明したようにそこにメディアを送信し続けなければなりません。各メディアストリームのためのICE処理の状態が実行中に変更しなければならない、とICE処理の状態が実行中に変更する必要があります。
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.
すべてのエンドポイントは、各メディアセッションのためのキープアライブを送らなければなりません。これらのキープアライブは、メディアセッションのために生きているNATバインディングを維持する目的を果たします。これらのキープアライブは関係なく、メディアストリームがsendonlyで、recvonlyで、またはSENDRECV、と関係なく、帯域幅の属性の存在または値の、現在非アクティブであるかどうか送らなければなりません。 ICEが全くセッションのために利用されていない場合でも、これらのキープアライブを送らなければなりません。キープアライブは、ピアによってサポートされているフォーマットを使用して送信されるべきです。 ICEエンドポイントは、UDPストリームのためのSTUNベースキープアライブを可能にする、エージェントは、完全なICEの実装であり、ICE（ライトまたは完全）をサポートし、ピアと通信している場合など、STUNキープアライブを使用しなければなりません。エージェントは、そのピアが=候補者の存在によって、ICEは、各メディアセッションのための属性をサポートすることを決定することができます。ピアがICEをサポートしていない場合は、キープアライブのためのパケットフォーマットの選択は、ローカルの実装の問題です。パケットは容易に実際のメディアコンテンツが存在しない状態で送信されることを可能にする形式が推奨されます。容易にこの目標を達成フォーマットの例は、RTP無オペアンプ[NO-OP-RTP]であり、双方がそれをサポートする場合には、RTP快適雑音[RFC3389]。ピアがキープアライブのために特に適している任意のフォーマットをサポートしていない場合は、エージェントが誤ったバージョン番号、またはそれらは、ピアによって破棄される原因となるエラーのいくつかの他の形式で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.
（パケットは、成分（RTPまたはRTCP）と前回のキープアライブ用に定義されたものを含む）のTr秒間メディアコンポーネントのために使用されている候補ペアICE上で送信されないパケットがなかった場合、エージェントはその対にキープアライブを生成しなければなりません。 Trが設定可能であるべきで、15秒のデフォルトを持つべきである（SHOULD）。 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は、キープアライブするために使用されている場合、STUNバインディング指示は[RFC5389]を使用します。表示は、任意の認証メカニズムを利用してはなりません。これは、逆多重化を支援するためにFINGERPRINT属性を含有しなければならないが、他の属性を含めることはできません。生きているNATバインディングを維持するためにのみ使用されます。結合指示はメディアのために使用されている同じローカルおよびリモートの候補を使用して送信されます。バインディング適応症は、キープアライブのために使用されているが、エージェントは、同様に接続性チェックを受け取る準備が必要です。接続性チェックが受信された場合、[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は、メディアでの使用のための候補を選択している、またはメディアが流れ始め、いずれか早い方いったんエージェントは、キープアライブ処理を開始する必要があります。セッションが終了するか、メディアストリームが除去されるとキープアライブを終了します。
Procedures for sending media differ for full and lite implementations.
メディアを送信するための手順は、フルとliteの実装のために異なっています。
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]で定義された手順を用いて、そのTURNサーバを介してベースから送信されます。
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].
地元の候補者が中継された候補者である場合は、エージェントがリモートの候補へのTURNサーバー上のチャネルを作成することをお勧めします。 [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そのメディアストリームのためのチェックリストの状態が実行され、そのコンポーネントの以前の選択されたペアが原因ICEの再起動に存在しない場合
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そのメディアストリームのためのチェックリストの状態が実行されている場合、メディアストリームのコンポーネントの前の選択された対に等しく、前の選択された対起因ICE再開するために、そのコンポーネントにありました
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.
メディアストリームの少なくとも一つの成分のために選択された対が空の場合、エージェントは、メディアストリームの任意のコンポーネントのメディアを送ってはいけません。メディアストリームの各コンポーネントの選択したペアの値を有する場合、エージェントは、メディアストリームのすべてのコンポーネントにメディアを送信することができます。
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ストリームは一つの候補の使用を開始し、これはICEでめったに起こりませんが、別のものに切り替えることができます。異なる遅延特性を有するもの - 新しい候補は、ネットワークを介して異なるパスを取るRTPパケットをもたらし得ます。以下に説明するように、薬剤は、ソースまたはメディアパケットの宛先アドレスに変更がある場合、ジッタバッファを再調整することが奨励されます。さらに、多くのオーディオコーデックは、ジッタバッファアダプテーションの目的のために、有音部の始まりを知らせるためにマーカービットを使用します。そのようなコーデックのために、薬剤は一つの候補ペアから別のメディアの送信を切り替える際に、送信者は、マーカビット[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を使用した場合、メディアストリームが候補を切り替えるように、そのような変化が時々発生します。エージェントは、メディアストリームは、メディア伝送を進行STUN交換の結果として同じピアからのものであることを決定することができるであろう。そこソーストランスポートアドレスの変化があるが、メディアパケットが同じピアエージェントから来る場合したがって、これは、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は、エンドポイント間で場所を取るためにSTUNベースの接続の一連のチェックが必要です。これらのチェックは、その答えの世代の回答から開始し、それが答えを受信したときにオファー側からスタート。これらのチェックが完了するまでに時間がかかることがあり、そのように、オファーとアンサーで使用するメッセージの選択は、知覚、ユーザーの待ち時間に影響を与えることができます。二つのレイテンシの数値は特に重要です。これらは、ポストピックアップ遅延とポストダイヤル遅延しています。ポストピックアップ遅延は、ユーザーが「電話に応答」するときの間の時間を意味し、彼らが口にするあらゆるスピーチは、発信者に配信することができるとき。ポストダイヤル遅延は、ユーザーがユーザーのために宛先アドレスを入力し、成功したの結果は、着信側の電話機を鳴らす始めとして、リングバックが開始されたときの間の時間を指します。
Two cases can be considered -- one where the offer is present in the initial INVITE and one where it is in a response.
2つのケースが考えられ得る - オファーがINVITE初期に存在し、それが応答しているものです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.
ポストダイヤル遅延を低減するためには、呼び出し側が前に実際にINVITEその初期を送信するために候補者を集め始めることが推奨されます。これは、キーパッドまたはオフフックに行く電話での活動として、コールが保留されていることをユーザインタフェース手がかり時に開始することができます。
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
オファーは、INVITE要求で受信した場合、回答はオファーの受信時にその候補を収集し、それがそのプロセスを完了した後、暫定応答で答えを生成するために開始する必要があります。 ICEは、SDPとの暫定的な応答を確実に送信されることを必要とします。これは、既存の暫定的な応答確認応答（PRACK）メカニズム[RFC3262]を介して、またはICEに固有の最適化を介して行うことができます。この最適化では、1つまたは複数のメディアストリームのためのICEの処理を開始するSDP回答を含む暫定応答がこれを行うにはRFC 3262.せずに確実に送信することができ、エージェントがRFCに3262.再送信を説明した指数バックオフタイマーで暫定応答を再送するMUSTバインディングSTUNの領収書に中止
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.
（バインディング要求の受信に申出が答えを受信したことを示すため）または2xx応答における回答の送信にメディアストリームのうちの1つの要求は、SDPに合図しました。ピア・エージェントはliteのであれば、STUNバインディング要求がされることはありません。そのような場合には、エージェントが4倍（;しかし、経験がそれを送ることがミドルボックスやファイアウォール越えのために重要であることが示されているピアが18倍を受けたことがない場合でも、ICEが実際に動作します）、それを送信した後に18倍を再送中止しなければなりません。何のバインディング要求が最後に再送信する前に受信されない場合、エージェントは終了したセッションを考慮していません。暫定応答が確実に配信されるという事実にもかかわらず、エージェントは提供が含まれて招待した場合、具体的にRFC 3262.に指定されたものから変更されません更新のオファーや解答を送信することができたときのためのルールは、同じ答えがすべてに表示されます。 1XXのとINVITEに対する2xx応答インチその2XXが送信された後にのみ更新オファー/アンサー交換が発生する可能性があります。両方のエージェントがPRACKをサポートする場合は、この最適化を使用してはいけません。最適化は、ICEの処理を開始する答えを運ぶ暫定応答に非常に特異的であることに注意してください。それは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.
答えが送信されると、エージェントは、その接続性チェックを開始する必要があります。メディアストリームの各コンポーネントの候補ペアが有効なリストを入力すると、アンサー側は、メディアストリームのメディアの送信を開始することができます。
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]の使用を必要とせずに動作します。また、ポストピックアップ遅延がゼロになるように、メディアのない単一のパケットは、クリップされますことを保証するという利点を有します。エージェントは、このように局所的な警告を遅らせることを選択した場合、アラートが始まると、それは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.
オファーがINVITE、と答えが暫定および/または200 OK応答であるである用途に加えて、ICEは、オファーが応答に表示されます例で動作します。 [RFC3725]サードパーティの呼制御に共通しているような場合では、ICEエージェントは、INVITEの受信時にユーザーに警告（RFC 3262を利用しなければならない）信頼できる暫定応答で彼らのオファーを生成し、そしてべきではありません。答えはPRACKに到着します。これは、増加したコールセットアップの遅延を犠牲にして何のポストピックアップ遅延は、存在しないように、事前警告に場所を取るためにICEの処理が可能になります。 ICEが完了すると、呼び出し先は、ユーザーに警告することができ、その後、彼らは答えたときに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で来る）での提供を配置することがあります。このような場合、呼び出し先は、INVITEの受信時にユーザーに警告し、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はフォークに関連するいくつかの問題を修正します。コールフォークと発信者が複数の入力メディアストリームを受信したときにICEせず、それは、被呼者に対応するメディアストリームを決定することができません。
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.
ICEでは、この問題は解決されます。メディアの伝送に先立って起こる接続性チェックは、次に、特定の被呼者に対応付けられているユーザ名断片を運びます。接続性チェックと同じ候補対に到着する後続のメディアパケットは、同じ呼び出し先に関連付けられます。したがって、呼び出し側は、それが答えを受け取ったとして、この相関を実行することができます。
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で定義されている（QoS）の前提条件、[RFC3312]およびRFC 4032 [RFC4032]は、唯一のオファー/アンサーにメディアのデフォルトのターゲットとしてリストされているトランスポートアドレスに適用されます。
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は、メディアが受信されたトランスポートアドレスを変更した場合、この変更は、メディアがICEの選択を一致させるために、デフォルトの保存先を変更する更新プランに反映されています。このように、それは再招く他のように表示され、完全にメディアの宛先が原因ICE交渉は「バックグラウンドで」発生に変化しているという事実に関係なく適用されたRFC 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.
[RFC3725]に記載されているようにICE Iは、フローにIII、及びIVの作品。流れIは、コントローラ支援やICEを意識することなく動作します。流れIVは限りコントローラはそのままICE属性に沿って通過するように動作します。フローIIは、ICEと根本的に互換性がありません。各エージェントは、回答することと、このようにINVITE再生成しないように自分自身を信じています。
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の実装の追加の動作を必要とします。エージェントは、ダイアログ中の受信した場合、特に、それが何の申し出を含まない再-INVITE、それは各メディアストリームのための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]は、代替ネットワークアドレスタイプ（ANAT）SDPグルーピングフレームワークのセマンティクス、及びRFC 4092 [RFC4092]、SIPとの使用量は、エージェントは、メディアのためのIPv4とIPv6の両方をサポートできることを示すための機構を定義しますストリーム、それは2メートルのライン、V4用とV6のための1つを含むことによってそうします。これは、候補者の属性を使用して、複数のトランスポート・アドレスを示すために、エージェントを可能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.
この仕様は、セッション中に両方のエージェントは、メディアのために選択された候補のペアのセットに到達する座標方法について非常に特異的な選択肢になります。将来の仕様は、彼らがタイマーの調整のような単純な変更や優先順位アルゴリズムの刷新などの大きな変化であるかどうか、これらのアルゴリズムを変更したいことが予想されます。このような変更が行われた場合には、セッション中に二つの薬剤間の相互運用性を提供することが重要です。
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 =アイスオプションのSDP属性を提供します。 ICEに各拡張や変更は、トークンに関連付けられています。そのような拡張や変更をサポートしているエージェントが提供または回答を生成するとき、それは、この属性でその拡張子のトークンを含まなければなりません。これは、それぞれの側が他側が何をしているかを知ることができます。エージェントは、任意のICEの拡張や変更をサポートしていない場合、この属性は存在してはなりません。
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レジストリや登録手続きは、これらのオプションタグに定義されていません。執筆の時点では、ICEの変更や拡張は、レジストリを保証するために十分に一般的になるかどうかは不明です。
One of the complications in achieving interoperability is that ICE relies on a distributed algorithm running on both agents to converge on an agreed set of candidate pairs. If the two agents run different algorithms, it can be difficult to guarantee convergence on the same candidate pairs. The 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.
相互運用性を達成する上で合併症の一つは、ICEが候補ペアの合意されたセットに収束するように、両方のエージェントで実行されている分散アルゴリズムに依存しているということです。二つの薬剤が異なるアルゴリズムを実行する場合、同じ候補対に収束を保証することは困難です。第8章で説明した通常の指名手続は、制御エージェントに完全に選択アルゴリズムを委任することにより、タイトなコーディネートの一部を排除します。制御剤は、それが認識していないオプションをサポートしてピアと通信しているときその結果、エージェントは、通常の指名アルゴリズムを実行する必要があります。通常の指名を使用する場合は、両方の薬剤が異なるペアの優先順位付けアルゴリズムを使用する場合でも、ICEは完全に収束していきます。このような収束の鍵の一つは、指名対が両方のエージェントによって検証されることを確実にトリガチェックです。その結果、将来のICEの機能強化は、トリガーチェックを保存しなければなりません。
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を割り当てる必要があります。新しいトランスポートプロトコルの仕様は、すべての場合には、ICE処理における様々なステップは、UDPとどのように異なるか、定義する必要があります。
This specification defines seven new SDP attributes -- the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-ufrag", "ice-pwd", and "ice-options" attributes.
この仕様は定義7新しいSDP属性 - 「候補」、「リモート・候補者」、「氷-LITE」、「アイス不一致」、「アイスufrag」、「アイスPWD」、および「アイスオプション」属性。
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)
候補属性= "候補" "; RFC 4566ポートから、" ファンデーションSP成分-ID SP輸送SP優先SPコネクション・アドレスSP RFC 4566 SPのCAND型からポート[SPのREL-ADDR] [SPのRELポート] *（SP延長-ATT-名SP拡張子-ATT値）
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 / "+" / "/"
ファンデーション= 1 * 32ice-チャー成分-ID = 1 * 5DIGIT輸送= "UDP" /トランスポート拡張トランスポート拡張=トークン。 RFCから3261優先順位= 1 * 10DIGIT CAND型= "標準" SP候補-タイプ候補タイプ= "ホスト" / "srflx" / "prflx" / "中継" /トークンREL-ADDR = "RADDR" SP connection-アドレスのrel-ポート= "RPORT" SPポート延長-ATT-名=バイト文字列; RFC 4566の拡張-ATT値から=バイト文字列氷-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.
<接続アドレス>は：RFC 4566 [RFC4566]から取られます。これは、IPv4アドレス、IPv6アドレス、および完全修飾ドメイン名（FQDN）を考慮して、候補のIPアドレスです。このフィールドを解析するとき、エージェントは、その値にコロンの存在によりIPv4アドレスとIPv6アドレスを区別することができる - 結腸の存在がIPv6を示します。エージェントがサポートされたり認識されないIPアドレスのバージョンと候補者を含める候補線を無視しなければなりません。 IPアドレスを使用する必要がありますが、FQDN、IPアドレスの代わりに使用してもよいです。その場合には、オファーを受けたとき、または、A =候補属性にFQDNを含む応答、FQDNは、第一（エージェントサポートIPv6を仮定する）AAAAレコードを使用してDNSで検索され、そしていかなる結果が見つからない場合、または薬剤のみDNSクエリが複数のIPアドレスを返す場合A.を使用して、IPv4のをサポートし、一方が選択され、そして次に氷処理の残りのために使用されます。
<port>: is also taken from RFC 4566 [RFC4566]. It is the port of the candidate.
<ポート>：また、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].
<トランスポート>：候補のためのトランスポートプロトコルを示します。この仕様はUDPのみを定義します。しかしながら、拡張は、TCPまたはデータグラム輻輳制御プロトコル（DCCP）などのICE、[RFC4340]で使用する将来のトランスポートプロトコルを可能にするために設けられています。
<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.
<ファンデーション>が1 <氷チャー> S 32で構成されています。これは、同じタイプである同じベースを共有し、同じSTUNサーバから来る2人の候補者のための同等の識別子です。財団は、冷凍アルゴリズムでICEのパフォーマンスを最適化するために使用されます。
<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.
<コンポーネントID>：これは候補されたメディアストリームの特定のコンポーネントを識別する1と256の間の正の整数です。それは、1で始まる必要があり、特定の候補の各成分について1ずつ増加しなければなりません。 RTPに基づいて、メディアストリームのために、実際のRTPメディアの候補は、1のコンポーネントIDがなければなりません、とRTCPの候補のマッピングを定義する仕様を開発しなければならない複数のコンポーネントを必要とするメディアストリームの2他のタイプのコンポーネントIDがなければなりませんコンポーネントIDのコンポーネント。新しいメディアストリームにICEを拡張する上で追加の議論については、セクション14を参照してください。
<priority>: is a positive integer between 1 and (2**31 - 1).
<優先順位>は：1（ - 1 2 ** 31）との間の正の整数です。
<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型>：候補のタイプを符号化します。この仕様は、値「ホスト」、「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.
<REL-addrに>と<REL-ポート>：診断および他の目的のために有用な、候補に関連するトランスポートアドレスを伝えます。 <REL-ADDR>及び<RELポート>サーバ再帰ピア再帰のために存在すること、及び候補を中継しなければなりません。候補者は、サーバまたはピア再帰<REL-ADDR>及び<RELポート>である場合、そのサーバまたはピア再帰候補のベースに等しいです。候補が、<REL-ADDR>及び<REL-ポート>中継される場合、その中継候補（その目的の議論は、付録B.3を参照）をクライアントに提供割り当て応答にマッピングされたアドレスと同じです。候補がホスト候補、<REL-addrに>と<REL-ポート>の場合は省略しなければなりません。
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
リモート候補ATTは= "リモート候補" "：" リモート候補0 *（SP遠隔候補）遠隔候補=成分-ID SPコネクション・アドレスSPポート
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:
「氷-LITE」と「アイス不一致」の構文は次のとおりです、フラグはどちらも、属性：
ice-lite = "ice-lite" ice-mismatch = "ice-mismatch"
氷-LITE = "氷-LITE" アイス不一致= "氷の不一致"
"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.
「氷-Liteは、」唯一のセッションレベル属性であり、エージェントはliteの実装であることを示しています。 「氷の不一致は、」メディアレベル属性のみであり、存在する場合にその答えに、オファーが対応する候補属性を持っていなかったメディアコンポーネントのデフォルトの出力先に到着したことを示しています。
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment and password used by ICE for message integrity. Their syntax is:
「アイスufrag」と「氷-PWD」属性は、メッセージの整合性のためにICEが使用するユーザ名とパスワードの断片を伝えます。彼らの構文は次のとおりです。
ice-pwd-att = "ice-pwd" ":" password ice-ufrag-att = "ice-ufrag" ":" ufrag password = 22*256ice-char ufrag = 4*256ice-char
"パスワードの氷のufrag-へ= "アイスufrag" "：" ufragパスワード= 22 * 256ice CHAR ufrag = 4 * 256ice炭PWD = "氷-PWD"" 氷
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.
「氷-PWD」と「アイスufrag」属性は、セッションレベルまたはメディアレベルのいずれかで表示されます。存在する場合の両方において、メディアレベルの値が優先されます。従って、セッション・レベルの値は、メディアレベル値によって上書きされない限り、すべてのメディアストリームに適用されるデフォルト値は有効です。セッションまたはメディアレベルで存在するかどうかは、各メディアストリームのための氷-PWDとアイスufrag属性があるに違いありません。 2つのメディアストリームは、同一のアイスufragさんを持っている場合、これらは同一氷-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.
アイスufragと氷-PWD属性は、セッションの開始時にランダムに選択されなければなりません。氷ufrag属性は、ランダムの、少なくとも24ビットを含まなければなりません、そして氷PWD属性はランダムの少なくとも128ビットを含まなければなりません。これは、これらの属性のための文法は、文字ごとにランダム性の6ビットが可能になりますので、アイスufrag属性は、長い間、少なくとも4文字の長、そして氷-PWD少なくとも22文字であることを意味します。属性はもちろん、256文字まで、それぞれ、4と22文字よりも長くすることができます。上限値は、実装にバッファサイズを可能にします。その大きな上限は、時間をかけて追加されるランダム性の量が増加することができます。
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
アイスオプション= "アイスオプション" "：" アイスオプションタグ0 *（SPアイス・オプション・タグ）アイスオプションタグ= 1 *氷-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.
ICE（4.1.1項）とICEを実行している間接続性チェック（セクション7）の収集フェーズでは、薬剤は、STUNターントランザクションを送ります。これらの取引は1ごとのTaミリ秒のレートでペース、および特定のRTOを利用しています。このセクションでは、TaとRTOの値が計算される方法を説明します。この計算は、ICEがリアルタイムメディア（RTPなど）ストリームまたは何か他のものと一緒に使用されているかどうかに依存します。 ICEは、既知の最大帯域幅を有するストリームのために使用される場合、セクション16.1に計算は、速度を制御するためにICE交換を行ってもよいです。他のすべてのストリームについては、項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.
ICE処理の存続期間中RTOとTaの値が変化します。値の1つのセットは接続性チェックのために、収集段階中に適用され、他の。
The value of Ta SHOULD be configurable, and SHOULD have a default of:
Taの値が設定可能であるべきであり、デフォルトを持っている必要があります。
For each media stream i:
各メディアストリームのためのI：
Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime
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:
また、STUNトランザクションの再送タイマーは、RTOは、[RFC5389]、設定可能であるべきで定義され、収集フェーズの間、のデフォルトを有するべきです。
RTO = MAX (100ms, Ta * (number of pairs))
RTO = MAX（100ミリ秒、Taの*（ペア数））
where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers.
どこペアの数は、STUNやTURNサーバーとの候補のペアの数を指します。
For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of:
接続性チェックのために、RTOは設定する必要があり、デフォルトを持っている必要があります。
RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))
RTO = MAX（100ミリ秒、Taの* N *（NUM-待機+テンキー進行中））
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.
これらの式は、STUNトランザクションがメディアと同じレートで整調させることを目的としています。これは、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はきれいに一定の速度を維持するが、パケット損失に対してより敏感になります。任意の接続性チェックのための最初の単一のパケットの損失は、そのペアを検証するのに長い時間がかかることがありそうで、代わりに、優先順位の低いチェック（ただし、パケットロスがなかったそのため1）は、はるかに可能性があります最初に完了します。これは、優先順位の高いペアにわたって低い優先度のペアを選択し、サブ最適に行う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はリアルタイムではなく、ICEが配備されているネットワーク上で動作することが知られ、それに関連付けられた固定レートを有していないセッションのいくつかの種類を確立するために使用される場合には、TaとRTOは、より保守的な値に戻します。 Taが500ミリ秒のデフォルトを持つべきである（SHOULD）、設定可能であるべきであり、500ms未満であることが設定可能にすることはできません。
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.
どこペアの数は、STUNやTURNサーバーとの候補のペアの数を指します。
For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of:
接続性チェックのために、RTOは設定する必要があり、デフォルトを持っている必要があります。
RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
RTO = MAX（500msのはTa * N *（NUM-待機+テンキー進行中））
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は、ICEを使用しています。どちらも、フルモードICEの実装であり、彼らがコントロールしている積極的な指名を使用しています。どちらの薬剤は、単一のIPv4アドレスを持っています。エージェント・Lの場合は、プライベートアドレス空間[RFC1918]で10.0.1.1、およびエージェントR、公共のインターネット上の192.0.2.1のためです。 192.0.2.2、ポート3478のIPアドレスでSTUNバインディング要求をリスニングして、（実際には薬剤が同じSTUNサーバを使用する必要はありませんが、簡単のためこの例に示されている）の両方が同じSTUNサーバで構成されています。TURNサーバは、この例で使用されていません。エージェントLは、NATの背後にある、エージェントRは、公共のインターネット上にあります。 NATは、エンドポイントの独立したマッピングプロパティとアドレス依存フィルタリング特性を有しています。 NATのパブリック側は、192.0.2.3のIPアドレスを持っています。
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.
理解を容易にするために、トランスポート・アドレスは、ニーモニック名を持つ変数を使用して記載されています。名前のフォーマットは、企業がそのIPアドレストランスポート・アドレスがオンになっているエンティティを指すエンティティ・タイプSEQNO、であり、「L」の一つである、「R」、「STUN」、または「NAT」。タイプは、どちらかのプライベートなトランスポートアドレスの公開されているトランスポートアドレスのための「PUB」、および「PRIV」です。最後に、配列-NOは、特定のエンティティに同じタイプの各トランスポート・アドレスの異なるシーケンス番号です。各変数は、VARNAMEは変数の名前であり、それぞれvarname.IPとvarname.PORT、で示される、IPアドレスとポートを持っています。
The STUN server has advertised transport address STUN-PUB-1 (which is 192.0.2.2:3478).
STUNサーバは、トランスポートアドレス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.
コールフロー自体では、STUNメッセージは、いくつかの属性で注釈を付けています。 「S =」属性は、メッセージの送信元トランスポートアドレスを示しています。 「D =」属性は、メッセージの宛先トランスポートアドレスを示します。 「MA =」属性は、STUNバインディング応答メッセージに使用され、マッピングされたアドレスを指します。 「USE-CANDは、」USE-候補者の属性が存在することを意味します。
The call flow examples omit STUN authentication operations and RTCP, and focus on RTP for a single media stream between two full implementations.
コール・フローの例は、STUNの認証操作を省略し、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アドレス（図示せず）からホスト候補を取得し、そこから、サーバー再帰候補（メッセージ1-4）を取得するためにSTUNサーバーにSTUNバインド要求を送信します。 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であり、サーバ再帰候補のホスト候補が1の基礎、及びサーバ再帰、2の基礎、そのを選択するが割り当てられ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
asd88fgpdd777uzjYhagZg A =氷ufrag：IP4 10.0.1.1 S = Cの= IP4 192.0.2.3 INさt = 0、A =氷PWD IN V = 0 0 = jdoeの2890844526 2890842807 8hhY M =オーディオ45664 RTP / AVP 0 B = RS：0 B = RR：= rtpmap 0 A：0 PCMU / 8000 =候補：1 UDP 2130706431 10.0.1.1 8998標準ホストA =候補2：1 UDP 1694498815 192.0.2.3 45664標準の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の背後ではないので、この候補者は、そのホスト候補と同一であり、それらは同じベースを共有しています。したがって、この冗長候補を破棄し、単一のホスト候補で終わります。 Lと同じタイプおよびローカル好みで、この候補の優先順位は、その単一の候補者のための1の基盤を選択2130706431.あります。その結果の答えは次のようになります。
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.
どちらの側は、それがライトであることを示しているので、ICE処理（エージェント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はただ一つで、その結果、そのサーバー再帰候補を含むペアを整理します。エージェント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は、（2つのホスト候補間の）第一の対のために接続性チェック（メッセージ9）を開始します。 Rは、このセッションの制御因子であるので、チェックはUSE-CANDIDATE属性を省略します。エージェント・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が答えを取得すると、それは、その唯一無二の接続性チェック（メッセージ10-13）を行います。これは、積極的な推薦アルゴリズムを実装し、ひいてはこのチェックでUSE-CANDIDATE属性を含んでいます。チェックが成功したため、エージェントLは、そのローカル候補結合応答にマッピングされたアドレスからの新しいペアを作成し、リモート候補と（メッセージ13からNAT-PUB-1）は、要求（R-PUB-1の宛先でありますメッセージ10から）。これは有効なリストに追加されます。バインド要求がUSE-CANDIDATE属性が含まれているので、選択として加えて、それがマークされています。このメディアストリームの一の成分の有効なリストで選択された候補があるので、このストリームの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）からSTUNバインディング要求を受信した後、エージェントRは、そのトリガーチェックを生成します。そのホスト候補からエージェントL'sのサーバー再帰候補に - このチェックでは、チェックリストの次のいずれかに一致して起こります。このチェック（メッセージ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.
例えばSIPSとして安全なシグナリング技術と併せてICEを用いO。
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.
100への接続性チェックの合計数を制限し、必要に応じて彼らが提供または回答に受け入れるだろう候補の数を制限し、O。
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:
攻撃者は、STUNの接続性チェックを混乱させるしようとする場合があります。最終的には、これらの攻撃の全ては、接続性チェックの結果について間違った何かを考えることにエージェントをだまします。攻撃者が試してみて、原因となる可能性のある偽の結論は以下のとおりです。
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.
偽無効：それはないときに候補ペアを考えにエージェントのペアをだますことができる攻撃者は、無効です。これは、（攻撃者によって注入1など）別の候補者を好むか、失敗するすべての候補者を強制することにより、通話を破壊する物質を引き起こすために使用することができます。
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 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].
攻撃者が偽の候補者に偽のピア再帰候補またはfalse有効を引き起こすことができれば、それは[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.
偽無効な結果を強制するには、攻撃者が送信される薬の一つから接続性チェックのために待たなければなりません。それがあるときは、攻撃者は、候補者があるので、実際には、有効な、元の要求は、ピアエージェントに達することが、成功の応答をもたらすなど400として、回復不能なエラー応答で偽の応答を注入する必要があります。攻撃者は、DoS攻撃、レイヤ2ネットワークの中断、または他の技術により、このパケットまたは削除されるその応答を強制する必要があります。それはこれをしない場合は、成功応答も攻撃の可能性を警告、発信元に達するだろう。幸いなことに、この攻撃は、STUN短期資格情報メカニズムを完全に軽減されます。攻撃者は、偽の応答を注入する必要があり、この応答を処理するためには、攻撃者がパスワードを必要とします。オファー/アンサーシグナル伝達が確保された場合、攻撃者がパスワードを持っていないだろうし、その応答は破棄されます。
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.
偽の有効な結果を強制すると同じように動作します。エージェントは、各エージェントからのバインディング要求を待つ、と偽の成功応答を注入する必要があります。攻撃者は、候補者が有効でない場合、それはおそらくとにかく受信されない、ので、実際の応答を中断することを心配する必要はありません。しかし、偽の無効な攻撃と同様に、この攻撃は、安全なオファー/アンサー交換と一緒にSTUN短期資格情報メカニズムによって軽減されます。
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アドレスとポートを持つ一つの薬剤との結合要求を送信するために、攻撃者が必要です。また、攻撃者は、他のエージェントからのバインディング要求を待ち、偽候補を含むXOR-MAPPED-ADDRESS属性を持つ偽の応答を生成する必要があります。ここで説明する他の攻撃と同様に、この攻撃はSTUNメッセージの整合性メカニズムと安全なオファー/アンサー交換によって軽減されます。
Forcing the false peer reflexive candidate result with packet replays is different. The attacker waits until one of the agents sends a check. It intercepts this request, and replays it towards the other agent with a faked source IP address. It 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.
パケットリプレイで偽ピア再帰候補結果を強制するとは異なります。剤の一つは、チェックを送信するまで、攻撃者が待機します。これは、この要求をインターセプトし、偽造送信元IPアドレスを持つ他のエージェントに向けて再生します。また、パケットがドロップさせるようにDoS攻撃を開始、またはレイヤ2つのメカニズムを使用して削除するためにそれを強制することにより、いずれか、リモートエージェントに達することから、元の要求を防ぐ必要があります。整合性チェックは、（完全性チェックができず、送信元IPアドレスおよびポートをカバーしていない）を通過するので、再生パケットは、他のエージェントで受信され、受け入れられています。これは、その後に応えています。この応答は、偽の候補者とのXOR-MAPPED-ADDRESSが含まれ、その偽の候補者に送信されます。攻撃者は、それを受信し、発信に向けてそれを中継しなければなりません。
The other agent will then initiate a connectivity check towards that false candidate. This validation needs to succeed. This requires the attacker to force a false valid on a false candidate. 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.
他の薬剤は、その偽の候補への接続性チェックを開始します。この検証は、成功するために必要です。これは、偽の候補者に有効な虚偽を強制するために、攻撃者が必要です。この目標を達成するために、偽の要求または応答の注入は、STUNの整合性メカニズムとオファー/アンサー交換を使用して防止することができます。したがって、この攻撃はリプレイから起動することができます。そのためには、攻撃者がこの偽の候補者へのチェックを傍受し、他のエージェントに向けて、それを再生する必要があります。その後、それが応答をインターセプトしなければなりませんし、同様にそのバック再生します。
This attack is very hard to launch unless the attacker is identified by the fake candidate. This is because it requires the attacker to intercept and replay packets sent by two different hosts. If both agents are on different networks (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つの異なるエンドポイントに対して発生する必要があるため、この攻撃は、調整が困難であることができます。
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よりも、同じメカニズムでそれを破壊することがはるかに簡単です。
ICE endpoints make use of STUN Binding requests for gathering server reflexive candidates from a STUN server. These requests are not authenticated in any way. As a consequence, there are numerous techniques an attacker can employ to provide the client with a false server reflexive candidate:
ICEのエンドポイントは、STUNサーバーからサーバー再帰候補を収集するためのSTUNバインディング要求を使用しています。これらの要求は、どのような方法で認証されません。その結果、攻撃者は偽のサーバ再帰候補をクライアントに提供するために採用することができる多数の技術があります。
o An attacker can compromise the DNS, causing DNS queries to return a rogue STUN server address. That server can provide the client with fake server reflexive candidates. This attack is mitigated by DNS security, though DNS-SEC is not required to address it.
O攻撃者がDNSクエリが不正なSTUNサーバのアドレスを返すように引き起こして、DNSを危うくすることができます。そのサーバーが偽のサーバー再帰候補者をクライアントに提供することができます。 DNS-SECは、それに対処する必要がありませんが、この攻撃は、DNSセキュリティによって軽減されます。
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のような共有ネットワークセグメント上の攻撃など）STUNメッセージを観察することができ、攻撃者は有効であり、クライアントによって受け入れられる偽の応答を注入することができます。
o An attacker can compromise a STUN server by means of a virus, and cause it to send responses with incorrect mapped addresses.
O攻撃者は、ウイルスによってSTUNサーバーを危うくし、それが間違ってマップされたアドレスに応答を送信することがあります。
A false mapped address learned by these attacks will be used as a server reflexive candidate in the 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.
これらの攻撃によって学習された偽のマッピングされたアドレスは、ICEの交換でサーバー再帰候補として使用されます。この候補者は、実際にメディアに使用されるためには、攻撃者はまた、接続性チェックを攻撃しなければならない、特に、偽の候補者に虚偽の有効を強制します。この攻撃は、セッション内の各エージェントによって生成されたチェックを攻撃する必要があるため偽のアドレスは、（どちらもオファー側、回答、また攻撃者）第四者を識別した場合に起動することは非常に困難であり、それは攻撃者を特定した場合にSRTPによって阻止されますその人自身。
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つの候補を持っている場合は、STUN接続自体は、メディアの交換のために使用することができるピア再帰候補を提供するチェックします。ピア再帰候補は、一般的に、サーバ再帰候補よりも優先されます。そのため、単にSTUNアドレスの収集への攻撃は、通常のすべてのセッションには影響を与えません。
An attacker might attempt to disrupt the gathering of relayed candidates, forcing the client to believe it has a false relayed candidate. Exchanges with the TURN server are authenticated using a long-term credential. Consequently, injection of fake responses or requests will not work. In addition, unlike Binding requests, Allocate requests are not susceptible to replay attacks with modified source IP addresses and ports, since the source IP address and port are not utilized to provide the client with its relayed candidate.
攻撃者は、それが偽の中継された候補者を持っていると信じてクライアントを強制的に、中継された候補者の集会を混乱しようとする場合があります。 TURNサーバーとの交流は、長期的な資格情報を使用して認証されます。その結果、偽のレスポンスやリクエストの注入は動作しません。また、バインディングの要求とは異なり、要求を割り当て元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.
ただし、TURNサーバーでは、ゾンビや不正なサーバーにそれを回すの目的のために、DNS攻撃に対する、またはTURNサーバを狙ったウイルスの影響を受けやすいです。これらの攻撃は、DNS-SECによっておよびTURNサーバー上良い箱やソフトウェアのセキュリティによって軽減することができます。
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.
自身が容易にICEとのさまざまな攻撃を起動することができオファー/アンサー交換を変更したり、混乱させることができ、攻撃者。ように彼らは、DoS攻撃のターゲットにメディアを直接ことができ、彼らはメディアストリームの中に自分自身を挿入することができ、そして。これらは、オファー/アンサー交換のための一般的なセキュリティ上の考慮事項、およびRFC 3264のセキュリティ上の考慮事項に似ています[RFC3264]適用されます。これらは、SIPを使用するSIPSメカニズム[RFC3261]によって満たされるオファーとアンサーのためのメッセージの整合性および暗号化のための技術を必要とします。そのため、ICEとSIPSの使用が推奨されます。
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.
音声ハンマー攻撃は、増幅攻撃です。この攻撃では、攻撃者が他のエージェントにセッションを開始し、メディアトラフィックの宛先は、SDPでシグナリングとして悪意のDoSターゲットのIPアドレスとポートを含みます。これはかなりの増幅を起こします。単一オファー/アンサー交換が可能性高い率（ビデオソースを考える）で、メディアパケットの継続的な洪水を作成することができます。この攻撃は、ICEに特有のものではなく、ICEは、修復を提供するのに役立つことができます。
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.
STUN増幅攻撃は、音声ハンマーに似ています。しかし、代わりに、標的に向けられる音声パケットの、STUN接続性チェックは、ターゲットに向けられます。攻撃者は候補者の数が多いのオファーを送り、50回答は申し出を受けて、ターゲットに向けられそのチェックを開始し、その結果、応答を生成したことがない、と言います。回答は、新たな接続性チェックのすべてのTaミリ秒（たとえば、TA = 20msの）を開始します。しかし、再送信タイマーは、多数の候補のために大規模な数に設定されています。その結果、パケットは、その後の間隔の増加に伴って、その後1ごとのTaミリ秒の間隔で送信され、されます。このように、STUNは、メディアが送信されると、ICEは、セッションのために失敗するまで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:
多くの場合、攻撃のこれらの種類を避けたいのプロトコルは、次のメッセージを送信する前に応答を待つイニシエータを強制します。しかし、ICEの場合には、これは不可能です。次の2つの場合を区別することはできません。
o There was no response because the initiator is being used to launch a DoS attack against an unsuspecting target that will not respond.
イニシエータが応答しません無防備なターゲットに対するDoS攻撃を起動するために使用されているため、O応答がありませんでした。
o There was no response because the IP address and port are not reachable by the initiator.
IPアドレスとポートは、イニシエータによって到達できないので、O応答がありませんでした。
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デバイスに存在関数です。セッションボーダーコントローラ（SBCS）のALGの近いいとこであるが、それらは実際にアプリケーション層SIPの媒体として存在するので、あまり透明です。 ICEはSBCS文字との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:
ALGはSIPを認識しているが、認識して氷でない場合は、ICEは限りALGが正しくSDPを変更すると、それを介して動作します。次のように正しい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:
M、Cのラインは、内部アドレスが含まれている場合、O、修飾はALGの状態に依存します。
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.
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.
ALGがすでにバインドされていない場合、それは新しいものを作成し、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.
残念ながら、多くのALGはこれらのコーナーケースで十分に機能しないことが知られています。これは、その機能の範囲外であるとして、ICEは、周りに壊れたのALGを仕事にしようとしません。 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.
シグナリングはTLS上で実行されるとICEはのALGを通じて最も適しています。これは、SDPメッセージを操作し、ICEの動作を妨げるからALGを防ぐことができます。 ALGの背後に展開されると予想されている実装は、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は、任意のSDPは、ICEの属性を含む、それは理解していない属性を削除します。他の側はICEをサポートしていないかのようにその結果、コールは両方のエンドポイントに表示されます。これは、ICEが無効になっている、とSBCがそれを要求した場合は、メディアは、SBCを流れることになります。しかし、SBCをそのままICE属性を渡し、まだ（M、Cのライン及びRTCP属性に含まれている）メディアのデフォルトの宛先を変更する場合、これはICEのミスマッチとして検出され、ICE処理をコールするために中止され。それは、「周りの作業」のSBCのためのツールとして機能するためのICEの範囲外です。 1が存在する場合、ICEは使用されず、SBC技術が優先されます。
This specification defines four new attributes, PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
この仕様は4つの新しい属性、PRIORITY、USE-CANDIDATE、ICE制御、およびICE-制御を定義します。
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.
PRIORITY属性は1つが、このチェックによって発見されなければならない、ピア再帰候補に関連付けられている優先度を示します。これは、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.
USE候補属性は、このチェックに起因候補対がメディアの送信に使用されるべきであることを示します。属性は（属性の長さフィールドがゼロである）コンテンツがありません。それがフラグとして働きます。それは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.
ICE制御属性は、バインディング要求に存在し、クライアントはそれが支配的な役割に現在あると考えていることを示しています。属性の内容は、ロールの競合のタイブレークのために使用される乱数を含むネットワークバイト順、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（ロールの競合）：バインディング要求は、サーバと競合役割を示す、ICE制御またはICE制御属性のいずれかを含んでいました。サーバーは、要求でタイブレーカーの値に基づいてタイブレーカーを実行し、クライアントが役割を交換する必要があると判断しました。
This section discusses issues relevant to network operators looking to deploy ICE.
このセクションでは、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やファイアウォール機器で動作するように設計されました。したがって、ICEの展開を容易にするために、既存のファイアウォールやNAT機器を交換したり、再設定する必要はありません。確かに、ICEは、ボイスオーバー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は、このように、音声品質を向上通話セットアップ時間を減少させること、およびネットワークオペレータの帯域幅の需要を減らすこと、TURNサーバーを必要とせずに動作します。
Deployment of ICE can have several interactions with available network capacity that operators should take into consideration.
ICEの展開は、事業者が考慮すべき利用可能なネットワーク容量を持ついくつかの相互作用を持つことができます。
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は通常、ネットワークオペレータのデータセンターに配置されることになるTURNとSTUNサーバーを使用しています。 STUNサーバは、比較的少ない帯域幅を必要とします。各メディアストリームの各コンポーネントについて、STUNサーバへの各クライアントから1つのまたは複数のSTUNトランザクションが存在します。基本的な音声-IPv4のみのVoIP展開では、（呼び出し元と呼び出し先の両方のためのRTP用とRTCPのための1、）コールごとに4つのトランザクションがあるでしょう。各トランザクションは、単一の要求と単一の応答、前者は20バイト長であり、システムは、N人のユーザを有し、それぞれがビジー時間の4つの呼び出しを行う場合は、後者、28はしたがって、これは、N *の1.7bpsを必要とするであろう。百万ユーザーの場合、これは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.
TURNトラフィックは、より実質的です。 TURNサーバーは、実際のメディアトラフィックのトラフィックに加えて、STUNのボリューム（TURNサーバが展開されている場合は確かに、別のSTUNサーバーの必要がない）に等しいトラフィック量が表示されます。メディアリレーのターンを必要とするコールの量は、ネットワークトポロジーに大きく依存し、かつ経時変化することになることができます。 100％振る舞う準拠のNATとのネットワークでは、それが正確にゼロです。執筆の時点では、大規模な消費者の展開は、TURNサーバを必要とする通話の5〜10パーセントを見ていました。忙しい時間の間0.2アーランとG.711（各方向で非常に80 kbps）を使用して、音声のみの配備を考慮すると、これはN * 3.2 kbpsです。百万ユーザーの人口については、これはTURNサーバの10％の使用を想定し、3.2 Gbpsです。
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は、これらのプロセスの両方をペーシングするように設計されています。収集フェーズと接続チェック相で略メディアトラフィック自体と同じ帯域幅をトラフィックを生成することを意味します。これは、ネットワークは、特定のタイプ（音声、ビデオ、またはテキストだけ）のマルチメディアトラフィックをサポートするように設計されている場合、それはそのメディアのICEチェックをサポートするのに十分な能力を持っているだろう、ということを保証するために行われました。もちろん、ICEのチェックは、総利用におけるわずかな増加の原因となります。しかし、これは一般的に非常に小さな増加となります。
Congestion due to the gathering and check phases has proven to be a problem in deployments that did not utilize pacing. Typically, access links became congested as the endpoints flooded the network with checks as fast as they 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の実装は、ペーシング機能をサポートしていることを確認する必要があります。このペースが増加呼設定時間を行うが、それは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.
（STUNバインディング適応症の形で）STUNキープアライブは、メディアセッションの途中で送信されます。しかし、彼らは唯一の実際のメディアトラフィックが存在しない状態で送信されます。音声アクティビティ検出（VAD）を利用していない展開では、キープアライブを使用しないと、帯域幅使用量が増加することはないんです。 VADが使用されている場合、キープアライブは、沈黙期間中に送信されます。これは、単一のパケットのパケットよりもはるかに少ないごとに15〜20秒、音声がある場合に送信されるすべての20-30ミリ秒を必要とします。したがって、キープアライブは、容量計画上の任意の実際の影響はありません。
Deployments utilizing a mix of ICE and ICE-lite interoperate perfectly. They have been explicitly designed to do so, without loss of function.
ICEとICE-LITEのミックスを利用展開が完全に相互運用します。彼らは、明示的機能を喪失することなく、そうするように設計されています。
However, ICE-lite can only be deployed in limited use cases. Those cases, and the caveats involved in doing so, are documented in Appendix A.
しかし、ICE-Liteは、限られたユースケースで展開することができます。これらの例、そしてそうすることに関わる注意事項が、付録Aに記載されています
ICE utilizes end-to-end connectivity checks, and places much of the processing in the endpoints. This introduces a challenge to the network operator -- how can they troubleshoot ICE deployments? How can they know how ICE is performing?
ICEは、エンドツーエンドの接続性チェックを利用して、エンドポイントにおける処理の多くを配置します。これは、ネットワークオペレータへの挑戦を紹介 - 彼らはICEの展開のトラブルシューティングを行うことができますか？彼らはどのようにICEが実行しているかを知ることができますか？
ICE has built-in features to help deal with these problems. 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パラメータを伝えるオファー/アンサー交換の内容が表示されます。これらのパラメータは、それらに関連するアドレスと共に、各候補（ホスト、サーバ再帰、または中継）の種類を含みます。 ICEの処理が完了すると、更新のオファー/アンサー交換は、選択したアドレス（とそのタイプを）シグナリング、行われます。このICE処理の結果について（例えばSIPサーバに接続診断ツールとして）ネットワーク機器を教育の目的のために正確に行われる再INVITE更新。
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が実行しているか評価するのに役立ちます主要な情報です。
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は、エンドポイントに構成されたデータのいくつかの部分に依存しています。このコンフィギュレーション・データは、STUNやTURNサーバー用のタイマ、TURNサーバーの資格情報、およびホスト名を含んでいます。 ICE自体は、この構成のためのメカニズムを提供していません。代わりに、この情報は、エンドポイントにおける他のすべてのパラメータを設定するために使用されるどのような機構に取り付けられているものとします。 SIP電話機の場合、このような構成の枠組み[SIP-UA-FRMWK]のような標準的な解決策が定義されています。
This specification registers new SDP attributes, four new STUN attributes, and one new STUN error response.
この仕様は、新たなSDP属性、4つの新しいSTUN属性、および1つの新しいSTUNエラー応答を登録します。
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.
担当者名：ジョナサン・ローゼンバーグ、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属性の対象ではありません。
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）を使用し、通信のための多くの可能な候補アドレスのいずれかを提供しています。これらのアドレスは、NAT（STUN））のセッショントラバーサルユーティリティを使用して、エンドツーエンドの接続性チェックで検証されています。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
担当者名：ジョナサン・ローゼンバーグ、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属性の対象ではありません。
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.
担当者名：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net。
Attribute Name: ice-lite
属性名：氷-LITE
Long Form: ice-lite
長い形式：氷-LITE
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 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.
担当者名：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net。
Attribute Name: ice-mismatch
属性名：氷のミスマッチ
Long Form: ice-mismatch
長い形式：氷のミスマッチ
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 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）で使用され、エージェントがICE可能であることを示しているが、SDPに合図メディアのデフォルトの出力先を伴う候補の不一致にICEを続行しませんでした。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
担当者名：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net。
Attribute Name: ice-pwd
属性名：氷-PWD
Long Form: ice-pwd
長い形式：氷-PWD
Type of Attribute: session- or media-level
属性の型：セッション - またはメディアレベル
Charset Considerations: The attribute is not subject to the charset attribute.
文字セットに関する注意事項：属性はcharset属性の対象ではありません。
Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the password used to protect STUN connectivity checks.
目的：この属性は、インタラクティブ接続確立（ICE）を使用し、STUNの接続性チェックを保護するために使用するパスワードを提供しています。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
担当者名：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net。
Attribute Name: ice-ufrag
属性名：アイスufrag
Long Form: ice-ufrag
長い形式：アイスufrag
Type of Attribute: session- or media-level
属性の型：セッション - またはメディアレベル
Charset Considerations: The attribute is not subject to the charset attribute.
文字セットに関する注意事項：属性は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）を使用し、STUNの接続性チェックにユーザ名を構築するために使用されるフラグメントを提供しています。
Appropriate Values: See Section 15 of RFC 5245.
適切な値：RFC 5245のセクション15を参照してください。
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
担当者名：ジョナサン・ローゼンバーグ、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つの新しいSTUN属性を登録します。
0x0024 PRIORITY 0x0025 USE-CANDIDATE 0x8029 ICE-CONTROLLED 0x802A ICE-CONTROLLING
0x0024 0x0025 PRIORITY使用候補0x8029のICE制御0x802AのICE-制御
This section registers one new STUN error response code per the procedures in [RFC5389].
このセクションでは、[RFC5389]の手順ごとに新しいSTUNエラー応答コードを登録します。
487 Role Conflict: The client asserted an ICE role (controlling or controlled) that is in conflict with the role of the server.
487ロールの競合：クライアントは、サーバーの役割と競合しているICEの役割（制御または制御）を主張しました。
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は、関数のこのタイプを行うプロトコルの一例です。興味深いことに、ICEのためのプロセスは、片側が、二国間ではなく、違いはIABが提起した問題に大きな影響を与えます。確かに、ICEは、B-SAF（二国間の自己アドレス固定）プロトコルではなく、UNSAFプロトコルとみなすことができます。かかわらず、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:
ICEによって解決されている具体的な問題は、次のとおりです。
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自体は簡単に段階的に廃止されません。しかし、それはルータの障害とは、例えば、接続を一時的に中断しているかどうかを検出するための手段として機能するように、でも世界的に接続されてインターネットに有用です。 ICEはまた、NATとは何の関係もない、特定のセキュリティ攻撃を防ぐことができます。しかし、どのようなICEは、他のUNSAFメカニズムを段階手助けあるん。 ICEは、効果的に優れているものを優先し、それらのメカニズムの中で選択し、悪いものをdeprioritizing。ローカルIPv6アドレスが優先することができます。 NATはIPv6が反射的に、サーバを導入し、優先度の高い接続がネイティブホスト候補に存在するため、単純に使用されることはありません飽きない候補（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が使用されます）と通信する場合のIPv6またはIPv4を使用するかどうかを決定するために使用することができます。また、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.
ICEは、実際には、既存のUNSAFメカニズムから脆性を削除します。具体的には、古典的なSTUNは（RFC 3489に記載されているように[RFC3489]）脆性のいくつかの点を有します。そのうちの一つは、それが背後にある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.
古典的なSTUNと他の一方的なメカニズムで脆性のもう一つのポイントは、追加のサーバー上の絶対的な信頼です。 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.
古典的なSTUNにおける脆性のもう一つのポイントは、それがSTUNサーバは公共のインターネット上にあることを前提としていることです。興味深いことに、ICEで、その必要はありません。アドレスレルムの様々なSTUNサーバの多数が存在する場合があります。 ICEは、利用可能なアドレスを提供しているものを発見するでしょう。
The most troubling point of brittleness in classic STUN is that it doesn't work in all network topologies. In cases where there is a shared NAT between each agent and the STUN server, traditional STUN may not work. With ICE, that restriction is removed.
古典的なSTUNにおける脆性の最も厄介な点は、それがすべてのネットワークトポロジでは動作しないということです。各エージェントとSTUNサーバの間で共有NATがある場合には、伝統的なSTUNは動作しない場合があります。 ICEでは、その制限が取り除かれます。
Classic STUN also introduces some security considerations. Fortunately, those security considerations are also mitigated by ICE.
クラシックSTUNはまた、いくつかのセキュリティ上の考慮事項を紹介します。幸いなことに、これらのセキュリティ上の考慮事項は、ICEによって軽減されています。
Consequently, ICE serves to repair the brittleness introduced in classic STUN, and does not introduce any additional brittleness into the system.
その結果、ICEは、古典的なSTUNで導入された脆弱性を修復するためのものであり、システムに追加の脆性を導入しません。
The penalty of these improvements is that ICE increases session establishment times.
これらの改善のペナルティは、ICEがセッション確立時間を増大させることです。
From RFC 3424, any UNSAF proposal 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からの私たちの結論は変わりません。しかし、我々は、それが長期的な解決策の一部にすることができます信じているので、ICEが実際に助けを感じます。
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と体験レポートを展開しました。
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箱の数は現在、「一般的な」ALG機能を提供しようとする市場に展開されています。これらの汎用のALGのIPアドレスについて、いずれかのパケット内のテキストまたはバイナリ形式で狩り、それらが結合一致する場合は、それらを書き換えます。これは古典的なSTUNと干渉する。しかしながら、[RFC5389]をSTUNする更新は、汎用のALGからこれらのバイナリアドレスを隠し符号化を使用します。
Existing NAPT boxes have non-deterministic and typically short expiration times for UDP-based bindings. This requires implementations to send periodic keepalives to maintain those bindings. ICE uses a default of 15 s, which is a very conservative estimate. Eventually, over time, as NAT boxes become compliant to behave [RFC4787], this minimum keepalive will become deterministic and well-known, and the ICE timers can be adjusted. Having a way to discover and control the minimum keepalive interval would be far better still.
既存のNAPT箱は、UDPベースのバインディングの非決定論的、一般的に短い有効期限を持っています。これは、これらのバインディングを維持するために定期的にキープアライブを送信するために実装する必要があります。 ICEは非常に保守的な見積もりである15秒のデフォルトを使用します。最終的に、時間をかけて、NATボックスは、[RFC4787]に動作するように準拠するように、この最小キープアライブは決定論と、よく知られており、ICEタイマーを調整することが可能になります。最小キープアライブ間隔を発見し、制御する方法を持つことは、はるかに良いまだだろう。
The 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.
作者は彼らのコメントのためにダン・ウィング、エリックレスコラ、フレミングAndreasenの、ロハンマーイ、ディーンウィリス、エリック・クーパー、ジェイソンFischl、ダグラス・オーティス、ティム・ムーア、ジャン=フランソワラバ、ケビン・ジョーンズ、ジョナサン・レノックス、そしてフランソワAudetに感謝したいと思いますそして、入力。特別な感謝を行うために、本明細書における概念のいくつかを示唆したビル・メイ、フィリップ・マシューズ、本明細書中の主要なパフォーマンスの最適化の多くを示唆し、エリックレスコラ、導入にテキストを起草し、マグヌスウェスターに行きますこの仕様のさまざまなリビジョンのいくつかの詳細なレビュー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、 "リアルタイム制御プロトコル（RTCP）セッション記述プロトコル（SDP）内の属性"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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]キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]キャマリロ、G.とP. Kyzivat、 "セッション開始プロトコル（SIP）前提条件フレームワークへの更新"、RFC 4032、2005年3月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]キャマリロ、G.およびJ.ローゼンバーグ、RFC 4091、2005年6月 "セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス"。
[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]キャマリロ、G.およびJ.ローゼンバーグ、 "セッション記述プロトコルの使用（SDP）の代替ネットワークアドレスタイプ（ANAT）セッション開始プロトコル（SIP）でセマンティクス"、RFC 4092、2005年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルNAT（TURN）の周りにリレーを使用してリレー拡張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]ローゼンバーグ、J.、RFC 5768、2010年4月 "セッション開始プロトコル（SIP）におけるインタラクティブ接続確立（ICE）のサポートを示します"。
[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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[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.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RFC3102]ボレッラ、M.、ロー、J.、Grabelsky、D.、およびG.モンテネグロ、 "レルム特定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]ボレッラ、M.、Grabelsky、D.、ロー、J.、およびK.谷口、 "レルム特定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.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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.、マグリュー、D.、Naslund、M.、カララ、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]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389] Zopf、R.、RFC 3389、2002年9月 "コンフォートノイズ（CN）のためのリアルタイムトランスポートプロトコル（RTP）ペイロード"。
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[RFC3960]キャマリロ、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、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]アンドレア、F.、カマリロ、G.、オラン、D.、およびD.翼、 "セッション記述プロトコルのメディアストリームの接続前提条件"、進歩、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]アンドレア、F.、オラン、D.、およびD.翼、 "RTPのための無オペアンプペイロードフォーマット"、進歩、2007年5月での作業。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のための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]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、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]ペトリー、D.とS. Channabasappa、エド。、 "セッション開始プロトコルユーザエージェントプロファイル配信のためのフレームワーク" が進歩、2010年2月に作業。
[ICE-TCP] Perreault, S., Ed. and J. Rosenberg, "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, October 2009.
[ICE-TCP]ペロー、S.、エド。およびJ.ローゼンバーグ、「インタラクティブ接続確立（ICE）とTCPの候補者は」、進歩、2009年10月に作業します。
Appendix A. Lite and Full Implementations
付録A.ライトとフル実装
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の実装が少しを行いますが、チェックをSTUNに応答ミニマリストの実装です。
Because ICE requires both endpoints to support it in order to bring benefits to either endpoint, incremental deployment of ICE in a network is more complicated. Many sessions involve an endpoint that is, by itself, not behind a NAT and not one that would worry about NAT traversal. A very common case is to have one endpoint that requires NAT traversal (such as a VoIP hard phone or soft phone) make a call to one of these devices. Even if the phone supports a full ICE implementation, ICE won't be used at all if the other device doesn't support it. The lite implementation allows for a low-cost entry point for these devices. Once they support the lite implementation, full implementations can connect to them and get the full benefits of ICE.
ICEは、どちらかのエンドポイントに恩恵をもたらすために、それをサポートするために、両方のエンドポイントを必要とするため、ネットワークにおけるICEの増分の展開はより複雑です。多くのセッションがないNATトラバーサルを心配でしょう1 NATの後ろではなく、それ自体で、あるエンドポイントを伴います。非常に一般的なケースは、（VoIPなどハードフォンやソフトフォンなど）NATトラバーサルは、これらのデバイスのいずれかに電話をかける必要が一方のエンドポイントを持つことです。電話がフル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.
その結果、ライトの実装は*必ず*公共のインターネットに接続されており、それがどんな通信員からのパケットを受信できるパブリックIPアドレスを持つことになるデバイスにのみ適しています。 liteの実装はNATの背後に配置されたときにICEが機能しません。
ICE allows a lite implementation to have a single IPv4 host candidate and several IPv6 addresses. In that case, candidate pairs are selected by the controlling agent using a static algorithm, such as the one in RFC 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内の1つとして、静的なアルゴリズムを用いて、制御エージェントによって選択されます。彼らはこれまで、実際のトポロジを反映することができないと、接続上の実際の保証を提供することはできませんので、アドレス選択のための静的なメカニズムは、常にエラーする傾向があります。彼らは常にヒューリスティックです。そのため、エージェントがICEを実施している場合は、単にそのIPv4アドレスとIPv6アドレスの間で選択すると、そのIPアドレスのどれもフルICEの使用はまだ可能アドレス選択の最も堅牢な形を提供するために推奨される、NATの背後にありません。
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,
liteの実装は完全実施への足がかりを提供するために、この仕様に追加されたことに注意することが重要です。実現可能な場合であっても、常に1つだけのIPv4アドレスを持つパブリックインターネットに接続されたデバイスのために、完全な実装が望ましいです。 ICEのアグレッシブモードを使用することができますので、完全な実装では、コールセットアップ時間を短縮します。完全な実装もNATトラバーサルとは無関係のICEのセキュリティ上の利点を得ます。具体的には、第18に記載の音声ハンマー攻撃のみ完全な実装のために防止され、
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のではありません。最後に、今日パブリックアドレスで自身を見つけたデバイスがネットワークにそれがNATの背後になる明日を置かれる場合が多いです。常に公共のインターネット上で使用されることを、デバイスまたは製品の寿命にわたって、明確に知ることは困難です。完全な実装では、通信が常に動作することを保証を提供します。
Appendix B. Design Motivations
付録B.デザイン動機
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自体は簡単であるが、さらなる議論に値する複雑または非自明な思考や使用例から導くことができる規範的行動の数が含まれています。これらの設計動機は、実装のために理解することがneccesaryではありませんので、それらは仕様の付録にここで説明されています。このセクションでは、非規範的です。
B.1. Pacing of STUN Transactions
B.1。 STUN取引のペーシング
STUN transactions used to gather candidates and to verify connectivity are paced out at an approximate rate of one new transaction every Ta milliseconds. Each transaction, in turn, has a retransmission timer RTO that is a function of Ta as well. Why are these transactions paced, and why are these formulas used?
候補者を集めるために、接続を検証するために使用されるSTUN取引は1つの新しいトランザクションごとのTaミリ秒のおおよその速度でペーシングされます。各トランザクションは、順番に、同様の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.
これらのSTUN要求の送信は、多くの場合、クライアントとSTUNサーバーの間の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:
「合理的な」率の定義は、メディアが流れ始めるとSTUNは、RTP自身が使用するよりも、より多くの帯域幅を使用してはならないことです。 STUNパケットは、すべてのTa秒を送られた場合、それはすべてのメディアストリームにわたって合計RTPパケット、と同じ量の帯域幅を消費することになる、ようにTaのための式は設計されています。もちろん、STUNは再送を持ち、そして欲望は同様にそれらをペーシングするです。このため、RTOは、最初のトランザクションの最初の再送信が最後のトランザクションの最初のSTUN要求が発生したと同じように起こるように設定されています。絵画的に：
First Packets Retransmits
まず、パケット再送信
| |
| |
-------+------ -------+------
/ \ / \
/ \ / \
+--+ +--+ +--+ +--+ +--+ +--+
|A1| |B1| |C1| |A2| |B2| |C2|
+--+ +--+ +--+ +--+ +--+ +--+
---+-------+-------+-------+-------+-------+------------ Time
0 Ta 2Ta 3Ta 4Ta 5Ta
In this picture, there are three transactions that will be sent (for example, in the case of candidate gathering, there are three host candidate/STUN server pairs). These are transactions A, B, and C. The retransmit timer is set so that the first retransmission on the first transaction (packet A2) is sent at time 3Ta.
この写真では、送信される3つのトランザクションは、（例えば、候補収集の場合には、3つのホスト候補/ STUNサーバのペアがある）があります。これらは、トランザクションの最初のトランザクション（パケットA2）上の最初の再送信が時間3Taで送信されるように、A、B、およびCは、再送信タイマーが設定されています。
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（ミリ秒）よりもさらに少ない頻度で発生します。
B.2. Candidates with Multiple Bases
B.2。複数の拠点を持つ候補者
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.
この場合、オファー側がマルチホームです。これは、ネット10のプライベートネットワークであるネットワークC、上、1つのIPアドレス、10.0.1.100を持っています。回答はこの同じネットワーク上にあります。提供者はまた、192.168 / 16 Aを、ネットワークに接続されています。オファー側は、このネットワーク上の192.168.1.100のIPアドレスを持っています。そここのネットワーク上のNATは、別のネット10のプライベートネットワークであるネットワークBへnatting、ですが、C.をネットワークに接続されていないネットワークB上のSTUNサーバーがあります
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）及びネットワークA（192.168.1.100:3344）上のIPアドレス上のホスト候補にそのIPアドレス上のホスト候補を取得します。それは192.168.1.100:3344からその構成されたSTUNサーバーにSTUNクエリを実行します。このクエリは、結合10.0.1.100:2498を割り当てることが起こるNATを通過します。 STUNサーバは、STUNバインディング応答でこれを反映しています。さて、オファー側はホスト候補（10.0.1.100:2498）と同じであるトランスポートアドレスを持つサーバ再帰候補を取得しています。ただし、サーバー再帰候補は192.168.1.100:3344の基盤を持っており、ホスト候補は10.0.1.100:2498のベースを持っています。
B.3. Purpose of the <rel-addr> and <rel-port> Attributes
B.3。 <REL-addrに>と<REL-port>の属性の目的
The candidate attribute contains two values that are not used at all by ICE itself -- <rel-addr> and <rel-port>. Why is it present?
<REL-addrに>と<REL-ポート> - 候補属性は、ICE自体が全く使用されていない2つの値が含まれています。なぜそれが存在していますか？
There are two motivations for its inclusion. The first is diagnostic. It is very useful to know the relationship between the different types of candidates. By including it, an 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つの動機があります。最初の診断です。候補者のさまざまな種類との関係を知ることは非常に便利です。それを含めることで、エージェントが中継された候補者が順番に特定のホスト候補に関連付けられている再帰候補、関連付けられているかを知ることができます。一つの候補のためのチェックが他人のために成功していない場合は、これはネットワークで何が起こっているのかに便利な診断機能を提供します。
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.
第二の理由は、サービス（QoS）のメカニズムのオフパスの品質に関係しています。 ICEは、例えばのPacketCable 2.0のような環境で使用される場合、プロキシは、通常のSIPの動作を実行することに加えて、SIPメッセージ内のSDPを検査、およびメディアトラフィックのためのIPアドレスとポート番号を抽出します。そして、彼らはメディアフローのための保証されたQoSを確立するために、ネットワーク内のアクセスルータと、ポリシーサーバを通じて、対話することができます。このQoSは、5タプルに基づいてRTPトラフィックを分類し、次にそれを保証速度を提供する、または適切にそのDiffservのコードポイントをマークすることによって提供されます。住宅のNATが存在し、中継候補がメディアを選択しますと、これは候補者が実際のTURNサーバー上のトランスポート・アドレスになります中継されます。このアドレスは、QoS処理のためにパケットを分類するために使用されるアクセスルータでの実際の転送アドレスについては何も言いません。むしろ、TURNサーバーへのサーバーの再帰候補が必要とされています。 SDPでの翻訳を実施することにより、プロキシは、アクセスルータからQoSを要求するために、そのトランスポートアドレスを使用することができます。
B.4. Importance of the STUN Username
B.4。 STUNユーザー名の重要性
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オファー/アンサー交換でユーザ名の断片を交換することにより形成されます。このメカニズムの必要性は、単にセキュリティを超えました。それは、実際に最初の場所でのICEが正しく動作するために必要とされます。
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はまた10.0.0.0/8を使用している民間企業2、の範囲内です。結局のところ、R及びZの両方がIPアドレス10.0.1.1を持ちます。 Lは、その答えに、Z. Zへのオファーを送り、そのホスト候補とLを提供します。この場合、これらの候補者は10.0.1.1:8866と10.0.1.1:8877です。結局のところ、Rはその同時にセッションであり、また、ホスト候補として10.0.1.1:8866と10.0.1.1:8877を使用しています。これは、Rは、Zは同じように、これらのポート上のSTUNメッセージを受け入れる用意があることを意味します。 Lは10.0.1.1:8877に10.0.1.1:8866し、別のSTUN要求を送信します。ただし、期待どおりこれらはZに行っていません。代わりに、彼らはRに行きます！ Rはちょうどそれらに答えた場合は、実際に、それは完全に別のユーザーへの接続を持っている場合、Lは、それはZへの接続を持っていると信じてしまう、R.はこれを修正するには、STUN短期資格情報メカニズムが使用されています。ユーザ名フラグメントは、資格情報が無効であったため結果的に、RはSTUN要求を拒否し、RはZと同じ値を使用してしまう可能性はほとんどありませんことを十分にランダムです。本質的には、STUNのユーザー名フラグメントは、特定のオファー/アンサーセッションにバインドされた過渡ホスト識別子のフォームを、提供しています。
An unfortunate consequence of the non-uniqueness of IP addresses is that, in the above example, R might not even be an ICE agent. It could be any host, and the port to which the STUN packet is directed could be any ephemeral port on that host. If there is an application listening on this socket for packets, and it is not prepared to handle malformed packets for whatever protocol is in use, the operation of that application could be affected. Fortunately, since the ports exchanged 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エージェントではないかもしれない、ということです。これは、任意のホストになることができ、およびSTUNパケットが向けられているポートは、そのホスト上の任意の一時的なポートである可能性があります。そこのパケットをこのソケットにリスニングのアプリケーションがあり、そしてプロトコルが使用されているものは何でものために不正なパケットを処理する準備ができていない場合には、そのアプリケーションの動作が影響を受ける可能性があります。幸いなエフェメラル、ポートはSDPで交換ためであり、通常、ダイナミックまたは登録範囲から引き出され、オッズは、ポートは、ホストR上のサーバを実行するために使用されていないと良いが、むしろ、いくつかのプロトコルのエージェント側です。これは、この範囲内のポートの使用状況の一時的な性質のために割り当てられたポートを、打つ確率を減少させます。しかし、問題の可能性が存在し、かつネットワークデプロイヤはそれのために準備する必要があります。これはICEに特有の問題ではないことに注意してください。浮遊パケットは、プロトコルのいずれかのタイプ、公共のインターネット上で、特にもののために任意の時点でのポートに到着することができます。そのため、この要件は、単にインターネットアプリケーションのための一般的な設計指針を修正再表示される - 任意のポートでの未知のパケットのために準備されます。
B.5. The Candidate Pair Priority Formula
B.5。候補ペア優先式
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)
一対の優先= 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.
どうしてこれなの？候補対がこの値に基づいてソートされる場合、結果として生じる分類は、MAX / MIN性を有します。このペアは、最初の二つの優先度の最小の値を減少させるに基づいてソートされることを意味します。最小優先順位の同じ値を持つ対に対して、最大優先順位は、それらの間でソートするために使用されます。最大値と最小値の優先順位が同じ場合は、制御剤の優先順位は、式の最後の部分でタイブレーカとして使用されています。 2×32の係数は単一の候補の優先ために使用される一対の優先順位は、2つの成分の優先順位の「連結」され、その結果、常に×32 2未満です。これは、MAX / MINのソートを作成します。 MAX / MINはすべて、優先順位の高い候補が試みられているまで、特定のエージェントのために、優先順位の低い候補が使用されることはありません、ということを保証します。
B.6. The remote-candidates Attribute
B.6。リモート・候補者は属性
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が更新され提供し、有効なリストに候補者を動かさSTUNバインディング要求に対する応答の間の競合状態を解消するために存在します。この競合状態は、メッセージ4を受信すると、図11に示されている、エージェントLは有効なリストに候補ペアを追加します。単一のコンポーネントを持つ唯一の単一のメディアストリームがあった場合は、エージェントのLは現在、更新のオファーを送信することができます。しかし、エージェントRからのチェックがまだ応答を生成していない、エージェントRは、応答（メッセージ9）を取得する前に更新されたオファー（メッセージ7）を受信します。したがって、それはまだ、この特定のペアが有効であることを知りません。この状態を解消するには、オファー側（遠隔候補者）によって選択された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：競合状態の流れ
B.7. Why Are Keepalives Needed?
B.7。なぜ、キープアライブが必要とされていますか？
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]で定義されるように、これは、「非アクティブ」属性「sendonlyの」SDPを使用するかによって達成されます。 RFC 3264は、これらのケースでは、メディアの送信を停止するために実装を指示します。しかし、そうすることは、タイムアウトにNATバインディングを引き起こす可能性があり、そしてメディアがホールドをオフに来ることができなくなります。
Secondly, some RTP payload formats, such as the payload format for text conversation [RFC4103], may send packets so infrequently that the interval exceeds the NAT binding timeouts.
第二に、そのようなテキストの会話[RFC4103]のためのペイロード・フォーマットのようないくつかのRTPペイロードフォーマットは、間隔がNATバインディングタイムアウトを超えているので、まれにパケットを送信することができます。
Thirdly, if silence suppression is in use, long periods of silence may cause 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はSTUNバインディングの適応症を利用し、簡単な定期的なキープアライブを定義します。これは、その帯域幅の要件は非常に予測可能で、かつQoS予約することが適します。
B.8. Why Prefer Peer Reflexive Candidates?
B.8。なぜピア再帰候補者を優先？
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によって阻止されています。
B.9. Why Send an Updated Offer?
B.9。なぜ更新されたオファーを送信しますか？
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節は、メディアを送信するためのルールを説明しています。両方のエージェントは更新のオファーを待たずに、完全なICEチェック後にメディアを送信することができます。確かに、更新オファーの唯一の目的は、メディアが（最も優先度の高いノミネート候補ペアとなります）ICE手順に基づいて送信されているメディアの一致のための「正しい」SDPているので、デフォルトの先にあります。
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.
なぜ更新オファー/アンサー交換が全く必要とされている - これは質問を頼みますか？確かに、純粋なオファー/アンサー環境では、それはないだろう。オファー側とアンサーはICEによって使用する候補者に同意するだろうし、それらの使用を開始することができます。限りエージェント自体が懸念しているとして、更新オファー/アンサーには、新たな情報を提供していません。しかし、実際には、シグナリングパスに沿って多数の構成要素は、SDP情報を見てください。これらは、オフパスQoS予約を行うエンティティを含む、このような受動ネットワークを監視するのALGおよびセッションボーダーコントローラ（SBCS）、および診断ツールとしてNATトラバーサルコンポーネント。 M、CのラインとRTCP属性 - - 保持されなければならない既存のメディアのために使用されるアドレスの前ICEの定義があること - これらのツールは、変更せずにSDPのコアプロパティを機能させる継続します。このため、更新されたオファーが送られなければなりません。
B.10. Why Are Binding Indications Used for Keepalives?
B.10。なぜ、キープアライブに使用される適応症をバインドしていますか？
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?
メディアキープアライブは、両方のエンドポイントがICEが可能である場合、これらのキープアライブは、STUNを利用して、セクション10に記載されています。しかし、むしろ（応答を生成する）バインディング要求トランザクションを使用するよりも、キープアライブは、指示を使用します。何故ですか？
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.
主な理由は、ネットワークの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などの大規模なエンドポイントのために有用です。
B.11. Why Is the Conflict Resolution Mechanism Needed?
B.11。なぜ紛争解決メカニズムが必要なの？
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つのピア間で実行されると、一つの薬剤は制御として制御されるように作用し、他の。ルールが制御され、誰が制御されている者を決定するために実装タイプ及びオファー/アンサーの関数として定義されます。ただし、仕様はいくつかのケースでは、両側は、彼らがコントロールしていると考えているかもしれない、または両側は、それらが制御されていると考えているかもしれない、ということに言及しています。これはどのように起こることができますか？
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の流れIII [RFC3725]のバリエーションです。それはより少ないメッセージを生成するので実際には、それが流れIIIよりも良い作品。このフローでは、コントローラはofferlessがそのオファー、SDP1で応答エージェントAにINVITEを送信します。エージェントは、offerlessが、それはその提供、SDP2とに応答エージェントBにINVITEを送信します。次いで、コントローラは、答えを生成するために、各エージェントからのオファーを使用しています。このフローを使用する場合、ICEは、エージェントAとBの間で実行されますが、両方は、彼らが支配的な役割であると考えています。 ICEを使用する場合、ロール紛争解決手続では、この流れが正常に機能します。
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
ジョナサン・ローゼンバーグjdrosen.netモンマス、NJ US
Email: jdrosen@jdrosen.net URI: http://www.jdrosen.net
メール：jdrosen@jdrosen.net URI：http://www.jdrosen.net