[要約] RFC 6544は、TCP Candidates with Interactive Connectivity Establishment (ICE)に関する規格であり、ICEフレームワークを使用してTCP接続の候補を特定する方法を提供します。このRFCの目的は、TCP接続の確立と維持を改善し、ネットワーク上の通信の信頼性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 6544 jdrosen.net
Category: Standards Track A. Keranen
ISSN: 2070-1721 Ericsson
B. B. Lowekamp
Skype
A. B. Roach
Tekelec
March 2012
TCP Candidates with Interactive Connectivity Establishment (ICE)
インタラクティブ接続の確立を備えたTCP候補（ICE）
Abstract
概要
Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream.
Interactive Connectivity Indecivity（ICE）は、セッション交渉のオファー/回答モデルに基づいて、マルチメディア通信プロトコルのNATトラバーサルのメカニズムを定義します。ICEは、各メディアストリームに一連の候補輸送アドレスを提供することで機能し、NAT（STUN）のセッショントラバーサルユーティリティに基づいてピアツーピア接続性チェックで検証されます。ICEは、候補者を説明するための一般的なフレームワークを提供しますが、UDPベースのメディアストリームのみを定義します。この仕様は、TCPベースのメディアにICEを拡張します。これには、TCPとUDPベースの候補を単一のストリームに組み合わせて提供する機能が含まれます。
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/rfc6544.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6544で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview of Operation ...........................................5
4. Sending the Initial Offer .......................................7
4.1. Gathering Candidates .......................................7
4.2. Prioritization .............................................8
4.3. Choosing Default Candidates ...............................10
4.4. Lite Implementation Requirements ..........................10
4.5. Encoding the SDP ..........................................11
5. Candidate Collection Techniques ................................12
5.1. Host Candidates ...........................................12
5.2. Server Reflexive Candidates ...............................13
5.3. NAT-Assisted Candidates ...................................13
5.4. UDP-Tunneled Candidates ...................................14
5.5. Relayed Candidates ........................................15
6. Receiving the Initial Offer and Answer .........................15
6.1. Considerations with Two Lite Agents .......................16
6.2. Forming the Check Lists ...................................16
7. Connectivity Checks ............................................17
7.1. STUN Client Procedures ....................................17
7.2. STUN Server Procedures ....................................18
8. Concluding ICE Processing ......................................18
9. Subsequent Offer/Answer Exchanges ..............................18
9.1. Updated Offer .............................................18
9.2. ICE Restarts ..............................................19
10. Media Handling ................................................19
10.1. Sending Media ............................................19
10.2. Receiving Media ..........................................20
11. Connection Management .........................................20
11.1. Connections Formed during Connectivity Checks ............20
11.2. Connections Formed for Gathering Candidates ..............21
12. Security Considerations .......................................22
13. IANA Considerations ...........................................23
14. Acknowledgements ..............................................23
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................24
Appendix A. Limitations of ICE TCP ...............................26
Appendix B. Implementation Considerations for BSD Sockets ........27
Appendix C. SDP Examples .........................................28
Interactive Connectivity Establishment (ICE) [RFC5245] defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model [RFC3264] of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN) [RFC5389]. However, ICE only defines procedures for UDP-based transport protocols.
インタラクティブな接続確立（ICE）[RFC5245]は、セッション交渉のオファー/回答モデル[RFC3264]に基づいて、マルチメディア通信プロトコルのNATトラバーサルのメカニズムを定義します。ICEは、各メディアストリームに一連の候補輸送アドレスを提供することで機能し、NAT（STUN）のセッショントラバーサルユーティリティに基づいてピアツーピア接続性チェックで検証されます[RFC5389]。ただし、ICEはUDPベースの輸送プロトコルの手順のみを定義します。
There are many reasons why ICE support for TCP is important. First, there are media protocols that only run over TCP. Such protocols are used, for example, for screen sharing and instant messaging [RFC4975]. For these protocols to work in the presence of NAT, unless they define their own NAT traversal mechanisms, ICE support for TCP is needed. In addition, RTP can also run over TCP [RFC4571]. Typically, it is preferable to run RTP over UDP, and not TCP. However, in a variety of network environments, overly restrictive NAT and firewall devices prevent UDP-based communications altogether, but general TCP-based communications are permitted. In such environments, sending RTP over TCP, and thus establishing the media session, may be preferable to having it fail altogether. With this specification, agents can gather UDP and TCP candidates for a media stream, list the UDP ones with higher priority, and then only use the TCP-based ones if the UDP ones fail. This provides a fallback mechanism that allows multimedia communications to be highly reliable.
TCPのICEサポートが重要である理由はたくさんあります。まず、TCPのみを実行するメディアプロトコルがあります。このようなプロトコルは、たとえば、画面共有やインスタントメッセージング[RFC4975]に使用されます。これらのプロトコルがNATの存在下で機能するには、独自のNATトラバーサルメカニズムを定義しない限り、TCPの氷のサポートが必要です。さらに、RTPはTCP [RFC4571]を超えることもできます。通常、TCPではなくUDPを介してRTPを実行することが望ましいです。ただし、さまざまなネットワーク環境では、過度に制限されたNATおよびファイアウォールデバイスがUDPベースの通信を完全に防止しますが、一般的なTCPベースの通信は許可されています。このような環境では、TCPを介してRTPを送信し、したがってメディアセッションを確立することが、完全に失敗するよりも望ましい場合があります。この仕様により、エージェントはUDPおよびTCP候補をメディアストリームの候補を収集し、優先度の高いUDPの候補をリストし、UDPベースのものが故障した場合にのみ使用できます。これにより、マルチメディア通信が非常に信頼性が高いことを可能にするフォールバックメカニズムが提供されます。
The usage of RTP over TCP is particularly useful when combined with Traversal Using Relays around NAT (TURN) [RFC5766]. In this case, one of the agents would connect to its TURN server using TCP and obtain a TCP-based relayed candidate. It would offer this to its peer agent as a candidate. The other agent would initiate a TCP connection towards the TURN server. When that connection is established, media can flow over the connections, through the TURN server. The benefit of this usage is that it only requires the agents to make outbound TCP connections to a server on the public network. This kind of operation is broadly interoperable through NAT and firewall devices. Since it is a goal of ICE and this extension to provide highly reliable communications that "just work" in as broad a set of network deployments as possible, this use case is particularly important.
TCPを介したRTPの使用は、NAT（ターン）の周りのリレーを使用してトラバーサルと組み合わせると特に役立ちます[RFC5766]。この場合、エージェントの1人がTCPを使用してターンサーバーに接続し、TCPベースの中継候補を取得します。これを候補者としてピアエージェントに提供します。他のエージェントは、Turnサーバーに向かってTCP接続を開始します。その接続が確立されると、メディアはターンサーバーを介して接続を介して流れる可能性があります。この使用の利点は、エージェントがパブリックネットワーク上のサーバーへのアウトバウンドTCP接続を行う必要があることです。この種の操作は、NATおよびファイアウォールデバイスを通じて広く相互運用可能です。ICEの目標であり、この拡張機能は、可能な限り幅広いネットワーク展開のセットで「機能する」非常に信頼性の高いコミュニケーションを提供することであるため、このユースケースは特に重要です。
This specification extends ICE by defining its usage with TCP candidates. It also defines how ICE can be used with RTP and Secure RTP (SRTP) to provide both TCP and UDP candidates. This specification does so by following the outline of ICE itself and
この仕様は、TCP候補との使用を定義することにより、ICEを拡張します。また、RTPと安全なRTP（SRTP）でICEを使用する方法を定義して、TCP候補とUDP候補の両方を提供します。この仕様は、氷自体の概要をたどり、
calling out the additions and changes to support TCP candidates in ICE. The base behavior of ICE [RFC5245] remains unchanged except for the extensions in this document that define the usage of ICE with TCP candidates.
氷のTCP候補者をサポートするために追加と変更を呼びかけます。ICE [RFC5245]の基本挙動は、TCP候補との氷の使用を定義するこのドキュメントの拡張機能を除き、変更されていません。
It should be noted that since TCP NAT traversal is more complicated than with UDP, ICE TCP is not generally as efficient as UDP-based ICE. Discussion about this topic can be found in Appendix A.
TCP NATトラバーサルはUDPよりも複雑であるため、ICE TCPは一般にUDPベースのICEほど効率的ではないことに注意してください。このトピックに関する議論は、付録Aにあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "not"、 "becommended"、 "bodement"、 ""、 "、" optional「この文書では、RFC 2119 [RFC2119]に記載されているように解釈されます。
This document uses the same terminology as ICE (see Section 3 of [RFC5245]).
このドキュメントでは、ICEと同じ用語を使用しています（[RFC5245]のセクション3を参照）。
The usage of ICE with TCP is relatively straightforward. This specification mainly deals with how and when connections are opened and how those connections relate to candidate pairs.
TCPでの氷の使用は比較的簡単です。この仕様は、主に接続が開かれる方法と時期と、それらの接続が候補ペアとどのように関連するかを扱います。
When agents perform address allocations to gather TCP-based candidates, three types of candidates can be obtained: active candidates, passive candidates, and simultaneous-open (S-O) candidates. An active candidate is one for which the agent will attempt to open an outbound connection but will not receive incoming connection requests. A passive candidate is one for which the agent will receive incoming connection attempts but not attempt a connection. An S-O candidate is one for which the agent will attempt to open a connection simultaneously with its peer.
エージェントがアドレス割り当てを実行してTCPベースの候補者を収集すると、アクティブな候補、パッシブ候補、および同時オープン（S-O）候補の3種類の候補を取得できます。アクティブな候補は、エージェントがアウトバウンド接続を開こうとするが、着信接続要求を受け取らない候補です。受動的な候補は、エージェントが着信接続の試みを受け取りますが、接続を試みない候補です。S-O候補は、エージェントがピアと同時に接続を開くことを試みる候補です。
When gathering candidates from a host interface, the agent typically obtains active, passive, and S-O candidates. Similarly, one can use different techniques for obtaining, e.g., server reflexive, NAT-assisted, tunneled, or relayed candidates of these three types (see Section 5). Connections to servers used for relayed and server reflexive candidates are kept open during ICE processing.
ホストインターフェイスから候補者を収集するとき、エージェントは通常、アクティブ、パッシブ、およびS-O候補を取得します。同様に、これら3つのタイプのサーバー反射、NATアシスト、トンネル、またはリレーした候補などの取得には、さまざまな手法を使用できます（セクション5を参照）。中継およびサーバー反射候補に使用されるサーバーへの接続は、氷の加工中に開いたままになります。
When encoding these candidates into offers and answers, the type of the candidate is signaled. In the case of active candidates, both IP address and port are present, but the port is meaningless (it is there only for making encoding of active candidates consistent with the other candidate types and is ignored by the peer). As a consequence, active candidates do not need to be physically allocated
これらの候補者をオファーと回答にエンコードすると、候補者のタイプが合図されます。アクティブな候補者の場合、IPアドレスとポートの両方が存在しますが、ポートは無意味です（他の候補タイプと一致するアクティブな候補のエンコードを作成するためだけにあり、ピアによって無視されます）。結果として、アクティブな候補者は物理的に割り当てる必要はありません
at the time of address gathering. Rather, the physical allocations, which occur as a consequence of a connection attempt, occur at the time of the connectivity checks.
住所の収集時に。むしろ、接続の試みの結果として発生する物理的割り当ては、接続チェック時に発生します。
When the candidates are paired together, active candidates are always paired with passive, and S-O candidates with each other. When a connectivity check is to be made on a candidate pair, each agent determines whether it is to make a connection attempt for this pair.
候補者が一緒にペアになっている場合、アクティブな候補者は常にパッシブとペアになり、S-O候補者は互いにペアになります。候補ペアで接続チェックを行う場合、各エージェントは、このペアの接続を試みるかどうかを判断します。
The actual process of generating connectivity checks, managing the state of the check list, and updating the Valid list works identically for TCP as it does for UDP.
接続性チェックを生成し、チェックリストの状態を管理し、有効なリストを更新する実際のプロセスは、UDPと同様にTCPと同じように機能します。
ICE requires an agent to demultiplex STUN and application-layer traffic, since they appear on the same port. This demultiplexing is described in [RFC5245] and is done using the magic cookie and other fields of the message. Stream-oriented transports introduce another wrinkle, since they require a way to frame the connection so that the application and STUN packets can be extracted in order to differentiate STUN packets from application-layer traffic. For this reason, TCP media streams utilizing ICE use the basic framing provided in RFC 4571 [RFC4571], even if the application layer protocol is not RTP.
ICEは、同じポートに表示されるため、エージェントがスタンとアプリケーション層トラフィックを非難する必要があります。この非複数のプレックスは[RFC5245]で説明されており、メッセージのMagic Cookieおよびその他のフィールドを使用して行われます。Stunパケットをアプリケーション層トラフィックと区別するためにアプリケーションとスタンパケットを抽出できるように、接続をフレーム化する方法が必要なため、ストリーム指向のトランスポートは別のしわを導入します。このため、ICEを使用するTCPメディアストリームは、アプリケーション層プロトコルがRTPでなくても、RFC 4571 [RFC4571]で提供される基本的なフレーミングを使用します。
When Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) is used, they are also run over the RFC 4571 framing shim, while STUN runs outside of the (D)TLS connection. The resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on the left side and without it on the right side.
トランスポートレイヤーセキュリティ（TLS）またはデータグラムトランスポートレイヤーセキュリティ（DTLS）を使用すると、RFC 4571フレーミングシムでも実行され、スタンは（d）TLS接続の外側で実行されます。結果のICE TCPプロトコルスタックを図1に示し、左側に（d）TLSが右側にありません。
+----------+
| |
| App |
+----------+----------+ +----------+----------+
| | | | | |
| STUN | (D)TLS | | STUN | App |
+----------+----------+ +----------+----------+
| | | |
| RFC 4571 | | RFC 4571 |
+---------------------+ +---------------------+
| | | |
| TCP | | TCP |
+---------------------+ +---------------------+
| | | |
| IP | | IP |
+---------------------+ +---------------------+
Figure 1: ICE TCP Stack with and without (D)TLS
図1：（d）TLSの有無にかかわらずICETCPスタック
The implication of this is that, for any media stream protected by (D)TLS, the agent will first run ICE procedures, exchanging STUN messages. Then, once ICE completes, (D)TLS procedures begin. ICE and (D)TLS are thus "peers" in the protocol stack. The STUN messages are not sent over the (D)TLS connection, even ones sent for the purposes of keepalive in the middle of the media session.
これの意味は、（d）TLSによって保護されているメディアストリームについて、エージェントが最初に氷の手順を実行し、スタンメッセージを交換することです。次に、ICEが完了すると、（d）TLS手順が開始されます。したがって、ICEおよび（d）TLSは、プロトコルスタックの「ピア」です。スタンメッセージは、メディアセッションの途中でKeepAliveの目的で送信されたものでさえ、（d）TLS接続を介して送信されません。
For offerers making use of ICE for TCP streams, the procedures below are used. The main differences compared to UDP candidates are the new methods for gathering candidates, how TCP candidates are prioritized, and how they are encoded in the Session Description Protocol (SDP) offer and answer.
TCPストリームにICEを使用する提供者には、以下の手順が使用されます。UDP候補と比較した主な違いは、候補者を収集するための新しい方法、TCP候補者の優先順位付け方法、およびセッション説明プロトコル（SDP）のオファーと回答でエンコードされる方法です。
Providers of real-time communications services may decide that it is preferable to have no media at all rather than to have media over TCP. To allow for choice, it is RECOMMENDED that it be possible to configure agents to either obtain or not obtain TCP candidates for real-time media.
リアルタイム通信サービスのプロバイダーは、TCPを介してメディアを持つよりもメディアを持たないことが望ましいと判断する場合があります。選択を可能にするために、リアルタイムメディアのTCP候補を取得または取得しないようにエージェントを構成することをお勧めします。
Having it be configurable, and then configuring it to be off, is far better than not having the capability at all. An important goal of this specification is to provide a single mechanism that can be used across all types of endpoints. As such, it is preferable to account for provider and network variation through configuration instead of hard-coded limitations in an implementation. Besides, network characteristics and connectivity assumptions can, and will, change over time. Just because an agent is communicating with a server on the public network today doesn't mean that it won't need to communicate with one behind a NAT tomorrow. Just because an agent is behind a NAT with endpoint-independent mapping today doesn't mean that tomorrow it won't pick up its agent and take it to a public network access point where there is a NAT with address- and port-dependent mapping properties or one that only allows outbound TCP. The way to handle these cases and build a reliable system is for agents to implement a diverse set of techniques for allocating addresses, so that at least one of them is almost certainly going to work in any situation. Implementors should consider very carefully any assumptions made about deployments before electing not to implement one of the mechanisms for address allocation. In particular, implementors should consider whether the elements in the system may be mobile and connect through different networks with different connectivity. They should also consider whether endpoints that are under their control, in terms of location and network connectivity, would always be under their control. In environments
構成可能であることを確認し、オフにするように構成することは、機能をまったく持たないよりもはるかに優れています。この仕様の重要な目標は、あらゆる種類のエンドポイントで使用できる単一のメカニズムを提供することです。そのため、実装におけるハードコーディングされた制限の代わりに、構成を通じてプロバイダーとネットワークのバリエーションを考慮することが望ましいです。その上、ネットワークの特性と接続の仮定は、時間とともに変化する可能性があり、そしてそうするでしょう。エージェントが今日パブリックネットワーク上のサーバーと通信しているからといって、明日のNATの背後にあるものと通信する必要がないというわけではありません。エージェントが今日エンドポイントに依存しないマッピングを備えたNATの背後にいるからといって、明日はエージェントを受け取らず、アドレスとポートに依存したマッピングを備えたNATがあるパブリックネットワークアクセスポイントに持ち込まないという意味ではありません。プロパティまたはアウトバウンドTCPのみを許可するプロパティ。これらのケースを処理して信頼できるシステムを構築する方法は、エージェントがアドレスを割り当てるための多様なテクニックセットを実装するためのものであるため、少なくともそのうちの1つはほぼ確実にどのような状況でも機能します。実装者は、アドレス割り当てのメカニズムの1つを実装しないように選択する前に、展開について行われた仮定を非常に慎重に検討する必要があります。特に、実装者は、システム内の要素がモバイルであり、異なる接続を持つさまざまなネットワークを介して接続できるかどうかを検討する必要があります。また、場所とネットワークの接続の観点から、制御下にあるエンドポイントが常に制御されるかどうかを検討する必要があります。環境で
where mobility and user control are possible, a multiplicity of techniques is essential for reliability.
モビリティとユーザー制御が可能な場合、信頼性には多数のテクニックが不可欠です。
First, agents SHOULD obtain host candidates as described in Section 5.1. Then, each agent SHOULD "obtain" (allocate a placeholder for) an active host candidate for each component of each TCP-capable media stream on each interface that the host has. The agent does not yet have to actually allocate a port for these candidates, but they are used for the creation of the check lists.
まず、セクション5.1で説明されているように、エージェントはホスト候補を取得する必要があります。次に、各エージェントは、ホストが持っている各インターフェイス上の各TCP対応メディアストリームの各コンポーネントのアクティブなホスト候補を「取得」（プレースホルダーを割り当てる」必要があります。エージェントは、これらの候補者に実際にポートを割り当てる必要はありませんが、チェックリストの作成には使用されます。
The agent SHOULD then obtain server reflexive, NAT-assisted, and/or UDP-tunneled candidates (see Section 5.2, Section 5.3, and Section 5.4). The mechanisms for establishing these candidates and the number of candidates to collect vary from technique to technique. These considerations are discussed in the relevant sections.
エージェントは、サーバーの反射、NATアシスト、および/またはUDPタンネの候補を取得する必要があります（セクション5.2、セクション5.3、およびセクション5.4を参照）。これらの候補者を確立するためのメカニズムと候補者の数は、テクニックごとに異なります。これらの考慮事項については、関連するセクションで説明します。
Next, agents SHOULD obtain passive (and possibly S-O) relayed candidates for each component as described in Section 5.5. Each agent SHOULD also allocate a placeholder for an active relayed candidate for each component of each TCP-capable media stream.
次に、エージェントは、セクション5.5で説明されているように、各コンポーネントのパッシブ（および場合によってはS-O）中継された候補を取得する必要があります。また、各エージェントは、各TCP対応メディアストリームの各コンポーネントのアクティブリレー候補にプレースホルダーを割り当てる必要があります。
It is highly RECOMMENDED that a host obtains at least one set of host candidates and one set of relayed candidates. Obtaining additional candidates will increase the chance of successfully creating a direct connection.
ホストは、少なくとも1つのホスト候補と1つの中継候補のセットを取得することを強くお勧めします。追加の候補を取得すると、直接接続を正常に作成する可能性が高まります。
Once the candidates have been obtained, the agent MUST keep the TCP connections open until ICE processing has completed. See Appendix B for important implementation guidelines.
候補者が取得されたら、エージェントは氷の処理が完了するまでTCP接続を開いたままにしなければなりません。重要な実装ガイドラインについては、付録Bを参照してください。
If a media stream is UDP-based (such as RTP), an agent MAY use an additional host TCP candidate to request a UDP-based candidate from a TURN server (or some other relay with similar functionality). Usage of such UDP candidates follows the procedures defined in ICE for UDP candidates.
メディアストリームがUDPベース（RTPなど）の場合、エージェントは追加のホストTCP候補を使用して、ターンサーバー（または同様の機能を備えた他のリレー）からUDPベースの候補を要求することができます。このようなUDP候補の使用は、UDP候補のICEで定義されている手順に従います。
Like its UDP counterparts, TCP-based STUN transactions are paced out at one every Ta milliseconds (see Section 16 of [RFC5245]). This pacing refers strictly to STUN transactions (both Binding and Allocate requests). If performance of the transaction requires establishment of a TCP connection, then the connection gets opened when the transaction is performed.
UDPのカウンターパートと同様に、TCPベースのSTUNトランザクションは、1ミリ秒ごとに1つのペースでペースを出します（[RFC5245]のセクション16を参照）。このペーシングとは、厳密にスタントランザクション（拘束力のあるリクエストと割り当ての両方）を指します。トランザクションのパフォーマンスにTCP接続の確立が必要な場合、トランザクションが実行されると接続が開かれます。
The transport protocol itself is a criteria for choosing one candidate over another. If a particular media stream can run over UDP or TCP, the UDP candidates might be preferred over the TCP
トランスポートプロトコル自体は、ある候補を別の候補よりも選択するための基準です。特定のメディアストリームがUDPまたはTCPを介して実行できる場合、UDP候補がTCPよりも優先される場合があります
candidates. This allows ICE to use the lower latency UDP connectivity if it exists but fallback to TCP if UDP doesn't work.
候補者。これにより、ICEが存在する場合は、ICEが存在する場合は低いレイテンシUDP接続を使用できますが、UDPが機能しない場合はTCPへのフォールバックを使用できます。
In Section 4.1.2.1 of [RFC5245], a recommended formula for UDP ICE candidate prioritization is defined. For TCP candidates, the same formula and candidate type preferences SHOULD be used, and the RECOMMENDED type preferences for the new candidate types defined in this document (see Section 5) are 105 for NAT-assisted candidates and 75 for UDP-tunneled candidates.
[RFC5245]のセクション4.1.2.1では、UDP ICE候補の優先順位付けの推奨式が定義されています。TCP候補の場合、同じフォーミュラと候補のタイプの設定を使用する必要があり、このドキュメントで定義されている新しい候補タイプの推奨タイプ設定（セクション5を参照）は、NAT支援候補の場合は105、UDPが緊張した候補者は75です。
When both UDP and TCP candidates are offered for the same media stream, and one transport protocol should be preferred over the other, the type preferences for the preferred transport protocol candidates SHOULD be increased and/or the type preferences for the other transport protocol candidates SHOULD be decreased. How much the values should be increased or decreased depends on whether it is more important to choose a certain transport protocol or a certain candidate type. If the candidate type is more important (e.g., even if UDP is preferred, TCP host candidates are preferred over UDP server reflexive candidates) changing type preference values by one for the other transport protocol candidates is enough. On the other hand, if the transport protocol is more important (e.g., any UDP candidate is preferred over any TCP candidate), all the preferred transport protocol candidates SHOULD have type preference higher than the other transport protocol candidates. However, it is RECOMMENDED that the relayed candidates are still preferred lower than the other candidate types. For RTP-based media streams, it is RECOMMENDED that UDP candidates are preferred over TCP candidates.
UDP候補とTCP候補の両方が同じメディアストリームに対して提供され、1つの輸送プロトコルを他の輸送プロトコルよりも優先する場合、優先輸送プロトコル候補のタイプ設定を増やす必要があります。減少します。値を増やすか減少させるべきかは、特定の輸送プロトコルまたは特定の候補タイプを選択することがより重要かどうかによって異なります。候補のタイプがより重要である場合（たとえば、UDPが優先されたとしても、TCPホスト候補はUDPサーバー再帰候補よりも優先されます）他の輸送プロトコル候補者のタイプ優先値を1つずつ変更します。一方、輸送プロトコルがより重要である場合（たとえば、任意のUDP候補がTCP候補よりも優先される場合）、すべての優先輸送プロトコル候補は、他の輸送プロトコル候補よりも高いタイプ優先を持つ必要があります。ただし、中継された候補者は、他の候補タイプよりも低いことを依然として推奨することをお勧めします。 RTPベースのメディアストリームの場合、UDP候補はTCP候補よりも推奨されることをお勧めします。
With TCP candidates, the local preference part of the recommended priority formula is updated to also include the directionality (active, passive, or simultaneous-open) of the TCP connection. The RECOMMENDED local preference is then defined as:
TCP候補では、推奨される優先順位式のローカル選好部分が更新され、TCP接続の方向性（アクティブ、パッシブ、または同時開放）も含まれます。推奨されるローカルの好みは、次のように定義されます。
local preference = (2^13) * direction-pref + other-pref
The direction-pref MUST be between 0 and 7 (both inclusive), with 7 being the most preferred. The other-pref MUST be between 0 and 8191 (both inclusive), with 8191 being the most preferred. It is RECOMMENDED that the host, UDP-tunneled, and relayed TCP candidates have the direction-pref assigned as follows: 6 for active, 4 for passive, and 2 for S-O. For the NAT-assisted and server reflexive candidates, the RECOMMENDED values are: 6 for S-O, 4 for active, and 2 for passive.
方向prefは0〜7（両方とも包括的）でなければならず、7が最も好まれています。他のPREFは0〜8191（両方とも包括的）でなければならず、8191が最も優先されます。ホスト、UDPが抑え、リレーしたTCP候補には、次のように方向PREFを割り当てることをお勧めします。アクティブに6、パッシブの場合は4、S-Oの場合は2つあります。NATアシストおよびサーバー反射候補の場合、推奨される値は次のとおりです。S-Oの場合6、アクティブの場合は4、パッシブの場合は2です。
The preference priorities listed here are simply recommendations that try to strike a balance between success probability and the resulting path's efficiency. Depending on the scenario where ICE TCP is used,
ここにリストされている選好の優先順位は、成功確率と結果のパスの効率のバランスをとることを試みる単なる推奨事項です。ICE TCPが使用されるシナリオに応じて、
different values may be appropriate. For example, if the overhead of a UDP tunnel is not an issue, those candidates should be prioritized higher since they are likely to have a high success probability. Also, simultaneous-open is prioritized higher than active and passive candidates for NAT-assisted and server reflexive candidates since if TCP S-O is supported by the operating systems of both endpoints, it should work at least as well as the active-passive approach. If an implementation is uncertain whether S-O candidates are supported, it may be reasonable to prioritize them lower. For host, UDP-tunneled, and relayed candidates, the S-O candidates are prioritized lower than active and passive since active-passive candidates should work with them at least as well as the S-O candidates.
異なる値が適切かもしれません。たとえば、UDPトンネルのオーバーヘッドが問題ではない場合、それらの候補者は高い成功確率を持っている可能性が高いため、より高い優先順位を付ける必要があります。また、TCP S-Oが両方のエンドポイントのオペレーティングシステムによってサポートされている場合、少なくともアクティブパッシブアプローチと同様に機能するはずであるため、同時にオープンはNATアシストおよびサーバー反射候補のアクティブおよびパッシブ候補よりも優先順位が優先されます。実装がS-O候補がサポートされているかどうかが不明な場合、より低い優先順位を付けることが合理的かもしれません。Host、UDP-Tunneled、および中継候補の場合、S-O候補は、少なくともS-O候補者と同様に、アクティブパッシブ候補者と協力する必要があるため、アクティブおよびパッシブよりも優先順位が低くなります。
If any two candidates have the same type-preference and direction-pref, they MUST have a unique other-pref. With this specification, this usually only happens with multi-homed hosts, in which case other-pref is the preference for the particular IP address from which the candidate was obtained. When there is only a single IP address, this value SHOULD be set to the maximum allowed value (8191).
2人の候補者が同じタイププレーと方向PREFを持っている場合、独自の他のPREFを持っている必要があります。この仕様では、これは通常、マルチホームのホストでのみ発生します。この場合、他のPREFは、候補者が取得された特定のIPアドレスの好みです。単一のIPアドレスしかない場合、この値は最大許容値（8191）に設定する必要があります。
The default candidate is chosen primarily based on the likelihood of it working with a non-ICE peer. When media streams supporting mixed modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, for real-time streams (such as RTP), the default candidates be UDP-based. However, the default SHOULD NOT be a simultaneous-open candidate.
デフォルトの候補者は、主に非氷のピアで作業する可能性に基づいて選択されます。混合モード（TCPとUDPの両方）をサポートするメディアストリームがICEで使用される場合、リアルタイムストリーム（RTPなど）の場合、デフォルトの候補者はUDPベースであることをお勧めします。ただし、デフォルトは同時に開かれた候補であってはなりません。
If a media stream is inherently TCP-based, it is RECOMMENDED for an offering full agent to select an active candidate as the default candidate and use [RFC4145] "setup" attribute value "active". This increases the chances for a successful NAT traversal even without ICE support if the agent is behind a NAT and the peer is not. For the same reason, for a lite agent, it is RECOMMENDED to use a passive candidate and "setup" attribute value "passive" in the offer.
メディアストリームが本質的にTCPベースである場合、デフォルトの候補としてアクティブな候補を選択し、[RFC4145]「セットアップ」属性値「Active」を使用するための完全なエージェントが提供することをお勧めします。これにより、エージェントがNATの背後にいてピアがそうでない場合でも、氷のサポートがなくても、NATトラバーサルを成功させる可能性が高まります。同じ理由で、Liteエージェントの場合、オファーでパッシブ候補と「セットアップ」属性値「パッシブ」を使用することをお勧めします。
If an offerer meets the criteria for the lite mode as described in Appendix A of [RFC5245] (i.e., it will always have a public, globally unique IP address), it MAY use the lite mode of ICE for TCP candidates. In the lite mode, for TCP candidates, only passive host candidates are gathered, unless active candidates are needed as the default candidates. Otherwise, the procedures described for lite mode in [RFC5245] also apply to TCP candidates. If UDP and TCP candidates are mixed in a media stream, the mode (lite or full) applies to both UDP and TCP candidates.
[RFC5245]の付録Aに記載されているLiteモードの基準を提供者が（つまり、常にグローバルにユニークなIPアドレスが常に含まれます）。Liteモードでは、TCP候補の場合、デフォルトの候補者としてアクティブな候補者が必要でない限り、受動的なホスト候補者のみが収集されます。それ以外の場合、[RFC5245]のライトモードについて説明されている手順もTCP候補に適用されます。UDP候補とTCP候補がメディアストリームで混合されている場合、モード（LiteまたはFull）がUDP候補とTCP候補の両方に適用されます。
TCP-based candidates are encoded into a=candidate lines like the UDP candidates described in [RFC5245]. However, the transport protocol (i.e., value of the transport-extension token defined in [RFC5245], Section 15.1) is set to "TCP" and the connection type (active, passive, or S-O) is encoded using a new extension attribute. With TCP candidates, the candidate-attribute syntax with Augmented BNF [RFC5234] is then:
TCPベースの候補は、[RFC5245]で説明されているUDP候補のようなa =候補線にエンコードされます。ただし、[RFC5245]、セクション15.1で定義されているトランスポートエクステンショントークンの値）は「TCP」に設定され、接続タイプ（アクティブ、パッシブ、またはS-O）は新しい拡張属性を使用してエンコードされます。TCP候補の場合、BNFの増強と候補者とアトリブの構文[RFC5234]は次のとおりです。
candidate-attribute = "candidate" ":" foundation SP component-id SP "TCP" SP priority SP connection-address SP port SP cand-type [SP rel-addr] [SP rel-port] SP tcp-type-ext *(SP extension-att-name SP extension-att-value)
候補者-Attribute = "候補" "：" Foundation SP Component-ID SP "TCP" SP PRIORITY SP Connection-Address SP PORT CAND-TYPE [SP REL-ADDR] [SP REL-PORT] SP TCP-Type-Ext *（sp endoct-att-name sp extension-att-value）
tcp-type-ext = "tcptype" SP tcp-type
tcp-type = "active" / "passive" / "so"
The connection-address encoded into the candidate-attribute for active candidates MUST be set to the IP address that will be used for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). For active relayed candidates, the value for connection-address MUST be identical to the IP address of a passive or simultaneous-open candidate from the same relay server.
アクティブな候補者の候補者とアトリブにエンコードされた接続アドレスは、試行に使用されるIPアドレスに設定する必要がありますが、ポートは9に設定する必要があります（つまり、破棄）。アクティブなリレー候補の場合、接続アドレスの値は、同じリレーサーバーからの受動的または同時に開かれた候補のIPアドレスと同一でなければなりません。
If the default candidate is TCP-based, the agent MUST include the a=setup and a=connection attributes from RFC 4145 [RFC4145], following the procedures defined there as if ICE were not in use. In particular, if an agent is the answerer, the a=setup attribute MUST meet the constraints in RFC 4145 based on the value in the offer.
デフォルトの候補がTCPベースの場合、エージェントは、氷が使用されていないかのように定義された手順に従って、RFC 4145 [RFC4145]のa = setupとa = connection属性を含める必要があります。特に、エージェントが応答者である場合、A =セットアップ属性は、オファーの値に基づいてRFC 4145の制約を満たす必要があります。
If an agent is utilizing SRTP [RFC3711], it MAY include a mix of UDP and TCP candidates. If ICE selects a TCP candidate pair, it is RECOMMENDED that the agent still utilizes SRTP but runs it over the connection established by ICE. The alternative, RTP over TLS, breaks RTP header compression and on-path RTP analysis tools and hence SHOULD be avoided. In the case of DTLS-SRTP [RFC5764], the directionality attributes (a=setup) are utilized strictly to determine the direction of the DTLS handshake. Directionality of the TCP connection establishment is determined by the ICE attributes and procedures defined here.
エージェントがSRTP [RFC3711]を使用している場合、UDP候補とTCP候補の組み合わせが含まれる場合があります。ICEがTCP候補ペアを選択する場合、エージェントはまだSRTPを使用しますが、ICEで確立された接続の上で実行することをお勧めします。TLSを介した代替のRTPは、RTPヘッダー圧縮とオンパスRTP分析ツールを破壊するため、避ける必要があります。DTLS-SRTP [RFC5764]の場合、方向性属性（A =セットアップ）は、DTLSハンドシェイクの方向を決定するために厳密に利用されます。TCP接続確立の方向性は、ここで定義されている氷の属性と手順によって決定されます。
If an agent is securing non-RTP media over TCP/TLS, the SDP MUST be constructed as described in RFC 4572 [RFC4572]. The directionality attributes (a=setup) are utilized strictly to determine the direction of the TLS handshake. Directionality of the TCP connection establishment is determined by the ICE attributes and procedures defined here.
エージェントがTCP/TLSで非RTPメディアを保護している場合、RFC 4572 [RFC4572]に記載されているように、SDPを構築する必要があります。方向性属性（A =セットアップ）は、TLSハンドシェイクの方向を決定するために厳密に利用されます。TCP接続確立の方向性は、ここで定義されている氷の属性と手順によって決定されます。
Examples of SDP offers and answers with ICE TCP extensions are shown in Appendix C.
ICE TCP拡張機能を使用したSDPオファーと回答の例は、付録Cに示されています。
The following sections discuss a number of techniques that can be used to obtain candidates for use with ICE TCP. It is important to note that this list is not intended to be exhaustive, nor is implementation of any specific technique beyond host candidates (Section 5.1) considered mandatory.
次のセクションでは、ICE TCPで使用する候補を取得するために使用できる多くの手法について説明します。このリストは、網羅的であることを意図していないことも、ホスト候補以外の特定の手法の実装（セクション5.1）が必須と見なされることに注意することが重要です。
Implementors are encouraged to implement as many of the following techniques from the following list as is practical, as well as to explore additional NAT-traversal techniques beyond those discussed in this document. However, to get a reasonable success ratio, one SHOULD implement at least one relayed technique (e.g., TURN) and one technique for discovering the address given for the host by a NAT (e.g., STUN).
実装者は、次のリストから以下の手法を実用的なものと同じくらい実装し、このドキュメントで説明したものを超えて追加のNATトラバーサル手法を探索することをお勧めします。ただし、合理的な成功率を取得するには、少なくとも1つのリレーテクニック（例：ターン）と、NATによってホストに与えられたアドレスを発見するための1つの手法（例：STUN）を実装する必要があります。
To increase the success probability with the techniques described below and to aid with transition to IPv6, implementors SHOULD take particular care to include both IPv4 and IPv6 candidates as part of the process of gathering candidates. If the local network or host does not support IPv6 addressing, then clients SHOULD make use of other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates.
以下で説明する手法で成功確率を高め、IPv6への移行を支援するには、実装者は候補者を収集するプロセスの一部としてIPv4候補とIPv6候補の両方を含めるように特に注意する必要があります。ローカルネットワークまたはホストがIPv6のアドレス指定をサポートしていない場合、クライアントは他の手法、例えばTurn-IPV6 [RFC6156]、Teredo [RFC4380]、またはIPv6候補を取得するために[RFC3089]をソックスする必要があります。
While implementations SHOULD support as many techniques as feasible, they SHOULD also consider which of them to use if multiple options are available. Since different candidates are paired with each other, offering a large number of candidates results in a large check list and potentially long-lasting connectivity checks. For example, using multiple NAT-assisted techniques with the same NAT usually results only in redundant candidates. Similarly, using just one of the multiple UDP tunneling or relaying techniques is often enough.
実装は実行可能なだけ多くの手法をサポートする必要がありますが、複数のオプションが利用可能な場合、使用するもののどれを検討する必要があります。さまざまな候補者が互いにペアになっているため、多数の候補者を提供すると、大規模なチェックリストと潜在的に長期にわたる接続チェックが得られます。たとえば、同じNATで複数のNATアシストされた技術を使用すると、通常、冗長な候補者のみが発生します。同様に、複数のUDPトンネルまたはリレーテクニックの1つだけを使用するだけで十分です。
Host candidates are the most simple candidates since they only require opening TCP sockets on the host's interfaces and sending/ receiving connectivity checks from them. However, if the hosts are
ホスト候補は、ホストのインターフェイスでTCPソケットを開き、接続性チェックを送信/受信するだけであるため、最も単純な候補者です。ただし、ホストがそうである場合
behind different NATs, host candidates usually fail to work. On the other hand, if there are no NATs between the hosts, host candidates are the most efficient method since they require no additional NAT traversal protocols or techniques.
さまざまなNATの背後で、ホスト候補者は通常作業に失敗します。一方、ホスト間にNATがない場合、ホスト候補は、追加のNATトラバーサルプロトコルまたはテクニックを必要としないため、最も効率的な方法です。
For each TCP-capable media stream the agent wishes to use (including ones like RTP that can be either UDP or TCP), the agent SHOULD obtain two host candidates (each on a different port) for each component of the media stream on each interface that the host has -- one for the simultaneous-open and one for the passive candidate. If an agent is not capable of acting in one of these modes, it would omit those candidates.
TCP対応メディアストリームごとに、エージェントは使用したい（UDPまたはTCPのいずれかのRTPなど）を使用することを望みます。エージェントは、各インターフェイスのメディアストリームの各コンポーネントに対して2つのホスト候補（それぞれ異なるポート上）を取得する必要があります。ホストが持っていること - 同時に開かれたものと受動的な候補者のためのもの。エージェントがこれらのモードのいずれかで行動できない場合、それらの候補者を省略します。
Server reflexive techniques aim to discover the address a NAT has given for the host by asking that from a server on the other side of the NAT and then creating proper bindings (unless such already exist) on the NATs with connectivity checks sent between the hosts. Success of these techniques depends on the NATs' mapping and filtering behavior [RFC5382] and also on whether the NATs and hosts support the TCP simultaneous-open technique.
サーバーの反射技術は、NATの反対側のサーバーからそれを尋ね、ホスト間で送信される接続チェックを伴うNATに適切なバインディング（すでに存在しない限り）を作成することにより、ホストに与えられたアドレスを発見することを目的としています。これらの手法の成功は、NATSのマッピングおよびフィルタリング動作[RFC5382]と、NATとホストがTCP同時オープン技術をサポートするかどうかに依存します。
Obtaining server reflexive passive candidates may require initiating connections from host's passive candidates; see Appendix B for implementation details on this. Server reflexive active candidates can be derived from passive or S-O candidates by using the same IP addresses and interfaces as those candidates. It is useful to obtain both server reflexive passive and S-O candidates since which one actually works better depends on the hosts and NATs. Furthermore, some techniques (e.g., TURN relaying) require knowing the IP address of the peer's active candidates beforehand, so active server reflexive candidates are needed for such techniques to function properly.
サーバーの反射パッシブ候補を取得するには、ホストのパッシブ候補から接続を開始する必要がある場合があります。これの実装の詳細については、付録Bを参照してください。サーバー反射的アクティブ候補は、それらの候補と同じIPアドレスとインターフェイスを使用することにより、パッシブまたはS-O候補から導出できます。実際にうまく機能するサーバー反射パッシブ候補とS-O候補の両方を取得すると、ホストとNATに依存することが役立ちます。さらに、一部の手法（例：ターンリレー）では、ピアのアクティブな候補者のIPアドレスを事前に知る必要があるため、そのような技術が適切に機能するには、アクティブなサーバー再帰候補が必要です。
A widely used protocol for obtaining server reflexive candidates is STUN. Its TCP-specific behavior is described in [RFC5389], Section 7.2.2.
サーバー反射候補を取得するために広く使用されているプロトコルはスタンです。そのTCP固有の動作は、[RFC5389]、セクション7.2.2で説明されています。
NAT-assisted techniques communicate with the NATs directly and, in this way, discover the address that the NAT has given to the host. NAT-assisted techniques also create proper bindings on the NATs. The benefit of these techniques over the server reflexive techniques is that the NATs can adjust their mapping and filtering behavior so that connections can be successfully created. A downside of NAT-assisted techniques is that they commonly allow communicating only with a NAT
NATアシストテクニックはNATと直接通信し、このようにして、NATがホストに与えたアドレスを発見します。NATアシストテクニックは、NATに適切なバインディングを作成します。サーバーの反射技術に対するこれらの手法の利点は、NATがマッピングとフィルタリングの動作を調整して、接続を正常に作成できるようにできることです。NATアシストテクニックの欠点は、一般的にNATとのみ通信を許可することです
that is in the same subnet as the host and thus often fail in scenarios with multiple layers of NATs. These techniques also rely on NATs supporting the specific protocols and allowing the users to modify their behavior.
これはホストと同じサブネットにあり、したがって、多くの場合、NATの複数の層を持つシナリオで失敗します。これらの手法は、特定のプロトコルをサポートし、ユーザーが動作を変更できるようにするNATに依存しています。
These candidates are encoded in the ICE offer and answer like the server reflexive candidates, but they (commonly) use a higher priority (as described in Section 4.2) and hence are tested before the server reflexive candidates.
これらの候補者は、サーバー反射候補のように氷のオファーと回答にエンコードされますが、（一般的に）より高い優先度（セクション4.2で説明されているように）を使用するため、サーバー反射候補の前でテストされます。
Currently, the Universal Plug and Play (UPnP) forum's Internet Gateway Device (IGD) protocol [UPnP-IGD] and the NAT Port Mapping Protocol (PMP) [NAT-PMP] are widely supported NAT-assisted techniques. Other known protocols include Port Control Protocol (PCP) [PCP-BASE], SOCKS [RFC1928], Realm Specific IP (RSIP) [RFC3103], and Simple Middlebox Configuration (SIMCO) [RFC4540]. Also, the Middlebox Communications (MIDCOM) MIB [RFC5190] defines a mechanism based on the Simple Network Management Protocol (SNMP) for controlling NATs.
現在、ユニバーサルプラグアンドプレイ（UPNP）フォーラムのインターネットゲートウェイデバイス（IGD）プロトコル[UPNP-IGD]およびNATポートマッピングプロトコル（PMP）[NAT-PMP]は、NATアシストテクニックを広くサポートしています。他の既知のプロトコルには、ポート制御プロトコル（PCP）[PCPベース]、ソックス[RFC1928]、レルム固有のIP（RSIP）[RFC3103]、および単純なミドルボックス構成（SIMCO）[RFC4540]が含まれます。また、Middlebox Communications（MIDCOM）MIB [RFC5190]は、NATを制御するための単純なネットワーク管理プロトコル（SNMP）に基づいたメカニズムを定義します。
UDP-tunneled NAT traversal techniques utilize the fact that UDP NAT traversal is simpler and more efficient than TCP NAT traversal. With these techniques, the TCP packets (or possibly complete IP packets) are encapsulated in UDP packets. Because of the encapsulation, these techniques increase the overhead for the connection and may require support from both of the endpoints, but on the other hand, UDP tunneling commonly results in reliable and fairly simple TCP NAT traversal.
UDPターンネッドNATトラバーサル技術は、UDP NATトラバーサルがTCP NATトラバーサルよりも単純で効率的であるという事実を利用しています。これらの手法では、TCPパケット（または完全なIPパケット）がUDPパケットにカプセル化されています。カプセル化のため、これらの手法は接続のオーバーヘッドを増加させ、両方のエンドポイントからのサポートが必要になる場合がありますが、一方で、UDPトンネルは一般に信頼性が高くかなり単純なTCP NATトラバーサルをもたらします。
UDP-tunneled candidates can be encoded in the ICE offer and answer either as relayed or server reflexive candidates, depending on whether the tunneling protocol utilizes a relay between the hosts. The UDP-tunneled candidates may appear to applications as host candidates from a local pseudo-interface. Treating these candidates as host candidates results in incorrect prioritization and possibly non-optimal candidate selection. Implementations may attempt to detect pseudo-interfaces, e.g., from the address prefix of the interface, but detection details vary from technique to technique.
UDPターン型候補は、トンネリングプロトコルがホスト間のリレーを利用するかどうかに応じて、リレーまたはサーバー反射候補のいずれかとして、アイスオファーにエンコードして回答できます。UDPが抑えられた候補者は、地元の擬似インターフェイスのホスト候補としてアプリケーションに表示される場合があります。これらの候補者をホスト候補として扱うことにより、誤った優先順位付けと、おそらく最適でない候補者の選択が誤っています。実装では、インターフェイスのアドレスプレフィックスから擬似インターフェイスを検出しようとする場合がありますが、検出の詳細は手法によって異なります。
For example, the Teredo protocol [RFC4380] [RFC6081] provides automatic UDP tunneling and IPv6 interworking. The Teredo UDP tunnel is visible to the host application as an IPv6 address; thus, Teredo candidates are encoded as IPv6 addresses.
たとえば、Teredoプロトコル[RFC4380] [RFC6081]は、自動UDPトンネルとIPv6インターワーキングを提供します。Teredo UDPトンネルは、IPv6アドレスとしてホストアプリケーションに表示されます。したがって、Teredo候補はIPv6アドレスとしてエンコードされます。
Relaying packets through a relay server is often the NAT traversal technique that has the highest success probability: communicating via a relay that is in the public Internet looks like normal client-server communication for the NATs and is supported in practice by all existing NATs, regardless of their filtering and mapping behavior. However, using a relay has several drawbacks, e.g., it usually results in a sub-optimal path for the packets, the relay needs to exist and it needs to be discovered, the relay is a possible single point of failure, relaying consumes potentially a lot of resources of the relay server, etc. Therefore, relaying is often used as the last resort when no direct path can be created with other NAT traversal techniques.
リレーサーバーを介したリレーパケットは、多くの場合、最高の成功確率を持つNATトラバーサル技術です。公開インターネットにあるリレーを介して通信することは、NATの通常のクライアントサーバー通信のように見え、既存のすべてのNATによって実際にサポートされています。フィルタリングとマッピング動作の。ただし、リレーを使用するにはいくつかの欠点があります。たとえば、通常、パケットの最適下パスになり、リレーを存在する必要があり、発見する必要があります。リレーは障害の可能性があります。したがって、リレーサーバーなどの多くのリソース。リレーは、他のNATトラバーサルテクニックで直接パスを作成できない場合に最後のリゾートとしてよく使用されます。
With relayed candidates, the host commonly needs to obtain only a passive candidate since any of the peer's server reflexive (and NAT-assisted if the peer can communicate with the outermost NAT) active candidates should work with the passive relayed candidate. However, if the relay is behind a NAT or a firewall, also using active and S-O candidates will increase success probability.
中継された候補者を使用すると、ホストは通常、ピアのサーバーの反射（およびピアが最も外側のNATと通信できる場合はNATアシスト）のいずれかがアクティブな候補者がパッシブ中継候補と連携する必要があるため、パッシブ候補のみを取得する必要があります。ただし、リレーがNATまたはファイアウォールの背後にある場合、アクティブおよびS-O候補を使用すると、成功確率が増加します。
Relaying protocols capable of relaying TCP connections include TURN TCP [RFC6062] and SOCKS [RFC1928] (which can also be used for IPv4- IPv6 gatewaying [RFC3089]). It is also possible to use a Secure SHell (SSH) [RFC4251] tunnel as a relayed candidate if a suitable server is available and the server permits this.
TCP接続を中継することができるリレープロトコルには、ターンTCP [RFC6062]およびSOCKS [RFC1928]（IPv4- IPv6ゲートウェイング[RFC3089]にも使用できます）が含まれます。適切なサーバーが利用可能であり、サーバーがこれを許可する場合、Secure Shell（SSH）[RFC4251]トンネルを中継候補として使用することも可能です。
Handling an ICE offer with TCP candidates works in a similar way as with UDP candidates. First, ICE support is verified (including the check for ice-mismatch described in Section 5.1 of [RFC5245]) and agent roles are determined. Candidates are gathered using the techniques described in Section 5 and prioritized as described in Section 4.2. Default candidates are selected taking into account the considerations in Section 4.3. The SDP answer is encoded as in Section 4.3 of [RFC5245], with the exception of TCP candidates whose encoding is described in Section 4.5.
TCP候補者との氷のオファーの取り扱いは、UDP候補者と同様の方法で機能します。最初に、氷のサポートが検証され（[RFC5245] 5.1セクション5.1で説明されている氷の不一致のチェックを含む）、エージェントの役割が決定されます。候補者は、セクション5で説明されている手法を使用して収集され、セクション4.2で説明されているように優先順位付けされます。デフォルトの候補者は、セクション4.3の考慮事項を考慮して選択されます。SDPの回答は、[RFC5245]のセクション4.3のようにエンコードされますが、エンコードがセクション4.5で説明されているTCP候補を除きます。
When the offerer receives the initial answer, it also verifies ICE support and determines its role. If both of the agents use lite implementations, the offerer takes the controlling role and uses the procedures defined in [RFC4145] to select the most preferred candidate pair with a new offer.
オファーが最初の答えを受け取ると、氷のサポートも検証し、その役割を決定します。両方のエージェントがLITE実装を使用した場合、オファーは管理の役割を担い、[RFC4145]で定義されている手順を使用して、新しいオファーで最も優先される候補ペアを選択します。
If both agents are using the lite mode and if the offerer uses the a=setup:active attribute [RFC4145] in the new offer, the offerer MAY initiate the TCP connection on the selected pair in parallel with the new offer to speed up the connection establishment. Consequently, the answerer MUST still accept incoming TCP connections to any of the passive candidates it listed in the answer, from any of the IP addresses the offerer listed in the initial offer.
両方のエージェントがLiteモードを使用しており、オファーが新しいオファーでa = setup：active属性[RFC4145]を使用している場合、オファーは、接続を高速化するための新しいオファーと並行して選択したペアのTCP接続を開始することができます確率。その結果、回答者は、最初のオファーに記載されているIPアドレスのいずれかから、回答に記載されている受動的候補のいずれかへの着信TCP接続を受け入れる必要があります。
If the answerer receives the new offer matching the candidate pair where a connection was already created in parallel with the new offer, it MUST accept the offer and respond to it while keeping the already-created connection. If the connection that was created in parallel with the new offer does not match the candidate pair in the new offer, the connection MUST be closed, and ICE restart SHOULD be performed.
回答者が、接続が既に新しいオファーと並行して作成されている候補ペアと一致する新しいオファーを受け取った場合、すでに作成された接続を維持しながら、オファーを受け入れ、応答する必要があります。新しいオファーと並行して作成された接続が、新しいオファーの候補ペアと一致しない場合、接続を閉じて、アイス再起動を実行する必要があります。
Since the connection endpoints are not authenticated using the connectivity checks in the scenario where both agents use the lite mode, unless media-level security (e.g., TLS) is used, it is RECOMMENDED to use the full mode instead. For more lite versus full implementation considerations, see Appendix A of [RFC5245].
メディアレベルのセキュリティ（TLSなど）を使用しない限り、両方のエージェントがLiteモードを使用するシナリオで接続性チェックを使用して接続エンドポイントは認証されていないため、代わりにフルモードを使用することをお勧めします。より多くのライトと完全な実装に関する考慮事項については、[RFC5245]の付録Aを参照してください。
As with UDP, check lists are formed only by full ICE implementations. When forming candidate pairs, the following types of TCP candidates can be paired with each other:
UDPと同様に、チェックリストは完全な氷の実装によってのみ形成されます。候補ペアを形成する場合、次のタイプのTCP候補を互いに組み合わせることができます。
Local Remote
Candidate Candidate
---------------------------
tcp-so tcp-so
tcp-active tcp-passive
tcp-passive tcp-active
When the agent prunes the check list, it MUST also remove any pair for which the local candidate is a passive TCP candidate. With pruning, the NAT-assisted candidates are treated like server reflexive candidates if the base is also used as a host candidate.
エージェントがチェックリストをプルネする場合、ローカル候補が受動的なTCP候補であるペアも削除する必要があります。剪定すると、ベースがホスト候補としても使用されている場合、NAT支援候補はサーバー反射候補のように扱われます。
The remainder of check list processing works in the same way as the UDP case.
チェックリスト処理の残りは、UDPケースと同じ方法で機能します。
The TCP connectivity checks, like with UDP, are generated only by full implementations. The TCP candidate pairs are in the same check list with the UDP candidate pairs, and they are scheduled for connectivity checks, as described in Section 5.8 of [RFC5245], based on the priority order.
UDPと同様に、TCP接続チェックは、完全な実装によってのみ生成されます。TCP候補のペアは、UDP候補ペアと同じチェックリストにあり、優先順位に基づいて[RFC5245]のセクション5.8で説明されているように、接続チェックが予定されています。
When an agent wants to send a TCP-based connectivity check, it first opens a TCP connection, if none yet exists, for the 5-tuple defined by the candidate pair for which the check is to be sent. This connection is opened from the local candidate of the pair to the remote candidate of the pair. If the local candidate is tcp-active, the agent MUST open a connection from the interface associated with that local candidate. This connection SHOULD be opened from an unallocated port. For host candidates, this is readily done by connecting from the local candidate's interface. For relayed, NAT-assisted, and UDP-tunneled candidates, the agent may need to use additional procedures specific to the protocol.
エージェントがTCPベースの接続チェックを送信したい場合、チェックを送信する候補ペアによって定義された5タプルに対して、まだ存在しない場合、最初にTCP接続を開きます。この接続は、ペアのローカル候補からペアのリモート候補に開かれます。ローカル候補者がTCP活性である場合、エージェントはそのローカル候補に関連付けられたインターフェイスから接続を開く必要があります。この接続は、未割り当てのポートから開く必要があります。ホスト候補の場合、これは地元の候補者のインターフェイスから接続することで容易に行われます。中継、NATアシスト、およびUDPが抑えた候補の場合、エージェントはプロトコルに固有の追加手順を使用する必要があります。
Once the connection is established, the agent MUST utilize the shim defined in RFC 4571 [RFC4571] for the duration this connection remains open. The STUN Binding requests and responses are sent on top of this shim, so that the length field defined in RFC 4571 precedes each STUN message. If TLS or DTLS-SRTP is to be utilized for the media session, the TLS or DTLS-SRTP handshakes will take place on top of this shim as well. However, they only start once ICE processing has completed. In essence, the TLS or DTLS-SRTP handshakes are considered a part of the media protocol. STUN is never run within the TLS or DTLS-SRTP session as part of the ICE procedures.
接続が確立されると、エージェントはRFC 4571 [RFC4571]で定義されているシムを利用して、これが開いたままです。スタンバインディングリクエストと応答は、このシムの上に送信されるため、RFC 4571で定義されている長さフィールドは各スタンメッセージの前にあります。TLSまたはDTLS-SRTPがメディアセッションに使用される場合、TLSまたはDTLS-SRTPハンドシェイクもこのシムの上に行われます。ただし、ICE処理が完了したら開始します。本質的に、TLSまたはDTLS-SRTPハンドシェイクは、メディアプロトコルの一部と見なされます。Stunは、ICE手順の一部としてTLSまたはDTLS-SRTPセッション内で実行されることはありません。
If the TCP connection cannot be established, the check is considered to have failed, and a full-mode agent MUST update the pair state to Failed in the check list. See Section 7.2.2 of [RFC5389] for more details on STUN over TCP.
TCP接続を確立できない場合、チェックは失敗したと見なされ、フルモードエージェントはチェックリストでペア状態を更新する必要があります。TCPを介したStunの詳細については、[RFC5389]のセクション7.2.2を参照してください。
Once the connection is established, client procedures are identical to those for UDP candidates. However, retransmissions of the STUN connectivity check messages are not needed, since TCP takes care of reliable delivery of the messages. Note also that STUN responses received on an active TCP candidate will typically produce a peer reflexive candidate. If the response to the first connectivity check on the established TCP connection is something other than a STUN
接続が確立されると、クライアント手順はUDP候補者の手順と同じです。ただし、TCPはメッセージの信頼できる配信を処理するため、スタン接続チェックメッセージの再送信は必要ありません。また、アクティブなTCP候補で受け取ったSTUN応答は、通常、ピア反射候補を生成することに注意してください。確立されたTCP接続の最初の接続チェックへの応答がスタン以外のものである場合
message, the remote candidate address apparently was not one of the peer's addresses, and the agent SHOULD close the connection and consider all pairs with that remote candidate as failed.
メッセージ、リモート候補の住所は明らかにピアのアドレスの1つではなく、エージェントは接続を閉じて、そのリモート候補とのすべてのペアを失敗したと考える必要があります。
An ICE TCP agent, full or lite, MUST be prepared to receive incoming TCP connection requests on the base of any TCP candidate that is simultaneous-open or passive. When the connection request is received, the agent MUST accept it. The agent MUST utilize the framing defined in RFC 4571 [RFC4571] for the lifetime of this connection. Due to this framing, the agent will receive data in discrete frames. Each frame could be media (such as RTP or SRTP), TLS, DTLS, or STUN packets. The STUN packets are extracted as described in Section 10.2.
ICE TCPエージェントであるフルまたはライトは、同時オープンまたはパッシブであるTCP候補のベースで着信TCP接続要求を受信する準備をする必要があります。接続要求が受信されたら、エージェントはそれを受け入れる必要があります。エージェントは、この接続の寿命にRFC 4571 [RFC4571]で定義されているフレーミングを利用する必要があります。このフレーミングにより、エージェントは離散フレームのデータを受け取ります。各フレームは、メディア（RTPやSRTPなど）、TLS、DTLS、またはスタンパケットです。STUNパケットは、セクション10.2で説明されているように抽出されます。
Once the connection is established, STUN server procedures are identical to those for UDP candidates. Note that STUN requests received on a passive TCP candidate will typically produce a remote peer reflexive candidate.
接続が確立されると、STUNサーバー手順はUDP候補の手順と同じです。受動的なTCP候補で受信したSTUNリクエストは、通常、リモートピア反射候補を生成することに注意してください。
If there are TCP candidates for a media stream, a controlling agent MUST use the regular selection algorithm.
メディアストリームのTCP候補がある場合、制御エージェントは通常の選択アルゴリズムを使用する必要があります。
When ICE processing for a media stream completes, each agent SHOULD close all TCP connections (that were opened due to this ICE session) except the ones between the candidate pairs selected by ICE.
メディアストリームの氷加工が完了すると、各エージェントは、氷で選択された候補ペアの間のペアの間のペアの間のものを除き、すべてのTCP接続（このアイスセッションのために開いたもの）を閉じる必要があります。
These two rules are related; the closure of connection on completion of ICE implies that a regular selection algorithm has to be used. This is because aggressive selection might cause transient pairs to be selected. Once such a pair is selected, the agents would close the other connections, one of which may be about to be selected as a better choice. This race condition may result in TCP connections being accidentally closed for the pair that ICE selects.
これらの2つのルールは関連しています。氷の完了時に接続の閉鎖は、通常の選択アルゴリズムを使用する必要があることを意味します。これは、積極的な選択により、一時的なペアが選択される可能性があるためです。そのようなペアが選択されると、エージェントは他の接続を閉じます。そのうちの1つは、より良い選択として選択されようとしている可能性があります。このレースの状態により、ICEが選択するペアのTCP接続が誤って閉じられる可能性があります。
When an updated offer is generated by the controlling endpoint after the connectivity checks have succeeded, the SDP extensions for connection-oriented media [RFC4145] are used to signal that an existing connection should be used, rather than opening a new one.
接続チェックが成功した後、制御エンドポイントによって更新されたオファーが生成されると、接続指向のメディア[RFC4145]のSDP拡張機能は、新しい接続を開くのではなく、既存の接続を使用する必要があることを示すために使用されます。
If an ICE restart occurs for a media stream with TCP candidate pairs that have been selected by ICE, the agents MUST NOT close the connections after the restart. In the offer or answer that causes the restart, an agent MAY include a simultaneous-open candidate whose transport address matches the previously selected candidate. If both agents do this, the result will be a simultaneous-open candidate pair matching an existing TCP connection. In this case, the agents MUST NOT attempt to open a new connection (or start new TLS or DTLS-SRTP procedures). Instead, that existing connection is reused, and STUN checks are performed.
ICEで選択されたTCP候補ペアを備えたメディアストリームに対してICEの再起動が発生した場合、エージェントは再起動後に接続を閉じてはなりません。再起動を引き起こすオファーまたは回答には、エージェントには、以前に選択された候補者と輸送アドレスが一致する同時オープン候補を含めることができます。両方のエージェントがこれを行うと、結果は既存のTCP接続に一致する同時開かれた候補ペアになります。この場合、エージェントは新しい接続を開こうとしてはなりません（または、新しいTLSまたはDTLS-SRTP手順を起動します）。代わりに、その既存の接続が再利用され、スタンチェックが実行されます。
Once the restart completes, if the selected pair does not match the previously selected pair, the TCP connection for the previously selected pair SHOULD be closed by the agent.
再起動が完了すると、選択したペアが以前に選択したペアと一致しない場合、以前に選択したペアのTCP接続はエージェントによって閉じている必要があります。
When sending media, if the selected candidate pair matches an existing TCP connection, that connection MUST be used for sending media.
メディアを送信するとき、選択した候補ペアが既存のTCP接続と一致する場合、その接続はメディアの送信に使用する必要があります。
The framing defined in RFC 4571 MUST be used when sending media. For media streams that are not RTP-based and do not normally use RFC 4571, the agent treats the media stream as a byte stream and assumes that it has its own framing of some sort, if needed. It then takes an arbitrary number of bytes from the byte stream and places that as a payload in the RFC 4571 frames, including the length. Next, the sender checks to see if the resulting set of bytes would be viewed as a STUN packet based on the rules in Sections 6 and 8 of [RFC5389]. This includes a check on the most significant two bits, the magic cookie, the length, and the fingerprint. If, based on those rules, the bytes would be viewed as a STUN message, the sender MUST utilize a different number of bytes so that the length checks will fail. Though it is normally highly unlikely that an arbitrary number of bytes from a byte stream would resemble a STUN packet based on all of the checks, it can happen if the content of the application stream happens to contain a STUN message (for example, a file transfer of logs from a client that includes STUN messages).
RFC 4571で定義されたフレーミングは、メディアを送信するときに使用する必要があります。 RTPベースではなく、通常RFC 4571を使用していないメディアストリームの場合、エージェントはメディアストリームをバイトストリームとして扱い、必要に応じて何らかのフレーミングがあると想定しています。次に、バイトストリームからの任意の数のバイトと、長さを含むRFC 4571フレームのペイロードとしての場所が必要です。次に、送信者は、結果のバイトセットが[RFC5389]のセクション6および8のルールに基づいてスタンパケットと見なされるかどうかを確認します。これには、最も重要な2つのビット、マジッククッキー、長さ、指紋のチェックが含まれます。これらのルールに基づいて、バイトがスタンメッセージと見なされる場合、送信者は長さのチェックが故障するように異なる数のバイトを利用する必要があります。通常、バイトストリームからの任意の数のバイトがすべてのチェックに基づいてスタンパケットに似ていることはほとんどありませんが、アプリケーションストリームのコンテンツにスタンメッセージが含まれている場合に発生する可能性があります（たとえば、ファイルなどスタンメッセージを含むクライアントからのログの転送）。
If TLS or DTLS-SRTP procedures are being utilized to protect the media stream, those procedures start at the point that media is permitted to flow, as defined in the ICE specification [RFC5245]. The TLS or DTLS-SRTP handshakes occur on top of the RFC 4571 shim and
TLSまたはDTLS-SRTP手順がメディアストリームを保護するために利用されている場合、これらの手順は、氷の仕様[RFC5245]で定義されているように、メディアが流れることが許可されているポイントから始まります。TLSまたはDTLS-SRTPの握手は、RFC 4571シムの上に発生し、
are considered part of the media stream for the purposes of this specification.
この仕様の目的のために、メディアストリームの一部と見なされます。
The framing defined in RFC 4571 MUST be used when receiving media. For media streams that are not RTP-based and do not normally use RFC 4571, the agent extracts the payload of each RFC 4571 frame and determines if it is a STUN or an application-layer data based on the procedures in ICE [RFC5245]. If media is being protected with DTLS-SRTP, the DTLS, RTP, and STUN packets are demultiplexed as described in Section 5.1.2 of [RFC5764].
RFC 4571で定義されたフレーミングは、メディアを受信するときに使用する必要があります。RTPベースではなく、通常RFC 4571を使用していないメディアストリームの場合、エージェントは各RFC 4571フレームのペイロードを抽出し、ICEの手順に基づくスタンまたはアプリケーション層データのかどうかを判断します[RFC5245]。メディアがDTLS-SRTPで保護されている場合、[RFC5764]のセクション5.1.2で説明されているように、DTLS、RTP、およびSTUNパケットが非難されます。
For non-STUN data, the agent appends this to the ongoing byte stream collected from the frames. It then parses the byte stream as if it had been directly received over the TCP connection. This allows for ICE TCP to work without regard to the framing mechanism used by the application-layer protocol.
非スタンデータの場合、エージェントはこれをフレームから収集した進行中のバイトストリームに追加します。次に、TCP接続で直接受信されたかのようにバイトストリームを解析します。これにより、ICE TCPは、アプリケーション層プロトコルで使用されるフレーミングメカニズムに関係なく機能します。
Once a TCP or TCP/TLS connection is opened by ICE for the purpose of connectivity checks, its life cycle depends on how it is used. If that candidate pair is selected by ICE for usage for media, an agent SHOULD keep the connection open until:
TCPまたはTCP/TLS接続が接続チェックの目的でICEによって開かれると、そのライフサイクルはその使用方法によって異なります。その候補ペアがメディアの使用のためにICEで選択されている場合、エージェントは次のように接続を開いたままにしておく必要があります。
o the session terminates,
o セッションは終了します、
o the media stream is removed, or
o メディアストリームが削除されます
o an ICE restart takes place, resulting in the selection of a different candidate pair.
o アイス再起動が行われ、異なる候補ペアが選択されます。
In any of these cases, the agent SHOULD close the connection when that event occurs. This applies to both agents in a session, in which case one of the agents will usually end up closing the connection first.
これらの場合、エージェントはそのイベントが発生したときに接続を閉じる必要があります。これは、セッションの両方のエージェントに適用されます。その場合、エージェントの1人が通常、最初に接続を閉じることになります。
If a connection has been selected by ICE, an agent MAY close it anyway. As described in the next paragraph, this will cause it to be reopened almost immediately, and in the interim, media cannot be sent. Consequently, such closures have a negative effect and are NOT RECOMMENDED. However, there may be cases where an agent needs to close a connection for some reason.
接続がICEによって選択されている場合、とにかくエージェントがそれを閉じることができます。次の段落で説明されているように、これによりすぐに再開され、暫定的にはメディアを送信できません。その結果、そのような閉鎖は悪影響を及ぼし、推奨されません。ただし、エージェントが何らかの理由で接続を閉じる必要がある場合がある場合があります。
If an agent needs to send media on the selected candidate pair, and its TCP connection has closed, then:
エージェントが選択した候補ペアでメディアを送信する必要があり、そのTCP接続が閉じている場合、次のとおりです。
o If the agent's local candidate is tcp-active or tcp-so, it MUST reopen a connection to the remote candidate of the selected pair.
o エージェントのローカル候補がTCPアクティブまたはTCP-SOである場合、選択したペアのリモート候補への接続を再開する必要があります。
o If the agent's local candidate is tcp-passive, the agent MUST await an incoming connection request and, consequently, will not be able to send media until it has been opened.
o エージェントのローカル候補者がTCPパッシブである場合、エージェントは着信接続要求を待つ必要があり、その結果、オープンするまでメディアを送信することはできません。
If the TCP connection is established, the framing of RFC 4571 is utilized. If the agent opened the connection and is a full agent, it MUST send a STUN connectivity check. An agent MUST be prepared to receive a connectivity check over a connection it opened or accepted (note that this is true in general; ICE requires that an agent be prepared to receive a connectivity check at any time, even after ICE processing completes). If a full agent receives a connectivity check after re-establishment of the connection, it MUST generate a triggered check over that connection in response if it has not already sent a check. Once an agent has sent a check and received a successful response, the connection is considered Valid, and media can be sent (which includes a TLS or DTLS-SRTP session resumption or restart).
TCP接続が確立されている場合、RFC 4571のフレーミングが利用されます。エージェントが接続を開いて完全なエージェントである場合、スタン接続チェックを送信する必要があります。エージェントは、開いたまたは受け入れた接続の接続チェックを受信する準備をする必要があります（これは一般的に真実であることに注意してください。ICEは、アイス処理が完了した後でも、エージェントをいつでも接続チェックを受信する必要があります）。接続の再確立後に完全なエージェントが接続チェックを受信した場合、まだ小切手を送信していない場合、その接続に対するトリガーチェックを生成する必要があります。エージェントが小切手を送信して成功した応答を受け取ったら、接続が有効であると見なされ、メディアを送信できます（TLSまたはDTLS-SRTPセッションの再開または再開を含む）。
If the TCP connection cannot be established, the controlling agent SHOULD restart ICE for this media stream. This will happen in cases where one of the agents is behind a NAT with connection-dependent mapping properties [RFC5382].
TCP接続を確立できない場合、制御エージェントはこのメディアストリームのICEを再起動する必要があります。これは、エージェントの1人が接続依存マッピングプロパティを備えたNATの背後にいる場合に発生します[RFC5382]。
If the agent opened a connection to a STUN server, or another similar server, for the purposes of gathering a server reflexive candidate, that connection SHOULD be closed by the client once ICE processing has completed. This happens regardless of whether the candidate learned from the server was selected by ICE.
エージェントが、サーバーの反射候補を収集する目的で、Stunサーバーまたは別の同様のサーバーへの接続を開いた場合、ICE処理が完了したら、クライアントがその接続を閉じる必要があります。これは、サーバーから学んだ候補者がICEで選択されたかどうかに関係なく発生します。
If the agent opened a connection to a TURN server for the purposes of gathering a relayed candidate, that connection MUST be kept open by the client for the duration of the media session if a relayed candidate from the TURN server was selected by ICE. Otherwise, the connection to the TURN server SHOULD be closed once ICE processing completes.
エージェントが中継候補を収集する目的でターンサーバーへの接続を開いた場合、ターンサーバーの中継候補がICEで選択された場合、メディアセッションの期間中、その接続をクライアントがクライアントによって開いたままにしなければなりません。それ以外の場合、アイス処理が完了したら、ターンサーバーへの接続を閉じる必要があります。
If, despite efforts of the client, a TCP connection to a TURN server fails during the lifetime of the media session utilizing a transport address allocated by that server, the client SHOULD reconnect to the TURN server, obtain a new allocation, and restart ICE for that media
クライアントの努力にもかかわらず、そのサーバーによって割り当てられたトランスポートアドレスを使用してメディアセッションの寿命の間にターンサーバーへのTCP接続が失敗した場合、クライアントはターンサーバーに再接続し、新しい割り当てを取得し、ICEを再起動する必要があります。そのメディア
stream. Similar measures SHOULD apply also to other types of relaying servers.
ストリーム。他のタイプの中継サーバーにも同様の手段が適用される必要があります。
The main threat in ICE is hijacking of connections for the purposes of directing media streams to denial-of-service (DoS) targets or to malicious users. When full implementations are used, ICE TCP prevents that by only using TCP connections that have been validated. Validation requires a STUN transaction to take place over the connection. This transaction cannot complete without both participants knowing a shared secret exchanged in the rendezvous protocol used with ICE, such as SIP [RFC3261]. This shared secret, in turn, is protected by that protocol exchange. In the case of SIP, the usage of the SIP Secure (SIPS) [RFC3261] mechanism is RECOMMENDED. When this is done, an attacker, even if it knows or can guess the port on which an agent is listening for incoming TCP connections, will not be able to open a connection and send media to the agent.
ICEの主な脅威は、メディアストリームをサービス拒否（DOS）ターゲットまたは悪意のあるユーザーに指示する目的で、接続のハイジャックです。完全な実装を使用すると、ICE TCPは、検証されたTCP接続のみを使用することでそれを防ぎます。検証では、接続を介してSTUNトランザクションが行われる必要があります。このトランザクションは、SIP [RFC3261]などのICEで使用されているランデブープロトコルで交換された共有秘密を知っている両方の参加者がいなければ、完了することはできません。この共有秘密は、そのプロトコル交換によって保護されています。SIPの場合、SIPセキュア（SIP）[RFC3261]メカニズムの使用が推奨されます。これが完了すると、攻撃者は、たとえエージェントが着信TCP接続を聞いているポートを知っているか推測できる場合でも、接続を開いてメディアをエージェントに送信することができません。
If the rendezvous protocol exchange is compromised, the shared secret can be learned by an attacker, and the attacker may be able to fake the connectivity check validation and open a TCP connection to the target. Hence, using additional security mechanisms (e.g., application-layer security) that mitigate these risks is RECOMMENDED.
ランデブープロトコル交換が侵害された場合、共有された秘密は攻撃者によって学ぶことができ、攻撃者は接続チェック検証を偽造し、ターゲットへのTCP接続を開くことができます。したがって、これらのリスクを軽減する追加のセキュリティメカニズム（アプリケーションレイヤーセキュリティなど）を使用することをお勧めします。
A STUN amplification attack is described in Section 18.5.2 of [RFC5245]. The same considerations apply to TCP, but the amplification effect with TCP is larger due to need for establishing a TCP connection before any checks are performed. Therefore, an ICE agent SHOULD NOT have more than 5 outstanding TCP connection attempts with the same peer to the same IP address.
スタン増幅攻撃は、[RFC5245]のセクション18.5.2で説明されています。同じ考慮事項はTCPにも当てはまりますが、チェックが実行される前にTCP接続を確立する必要があるため、TCPによる増幅効果は大きくなります。したがって、ICEエージェントは、同じPEERを使用して同じIPアドレスを使用して、5つ以上の未解決のTCP接続試行を行うべきではありません。
If both agents use the lite mode, no connectivity checks are sent, and additional procedures (e.g., media-level security) are needed to validate the connection. The lack of connectivity checks is especially problematic if one of the hosts is behind a NAT and has an address from a private address space: the peer may accidentally connect to a host in a different subnet that uses the same private address space. This is one of the reasons why the lite mode is not appropriate for an ICE agent located behind a NAT.
両方のエージェントがLITEモードを使用する場合、接続性チェックは送信されず、接続を検証するために追加の手順（メディアレベルのセキュリティなど）が必要です。ホストの1人がNATの背後にあり、プライベートアドレススペースの住所がある場合、接続性チェックの欠如は特に問題があります。ピアは、同じプライベートアドレススペースを使用する別のサブネットのホストに誤って接続できます。これは、LiteモードがNATの後ろにあるICEエージェントに適していない理由の1つです。
A more detailed analysis of different attacks and the various ways ICE prevents them are described in [RFC5245]. Those considerations apply to this specification.
さまざまな攻撃のより詳細な分析と氷がそれらを妨げるさまざまな方法について、[RFC5245]で説明されています。これらの考慮事項は、この仕様に適用されます。
IANA has created a new sub-registry "ICE Transport Protocols" in the "Interactive Connectivity Establishment (ICE)" registry for ICE candidate-attribute transport extensions. Initial values are given below; future assignments are to be made through IETF Review or IESG Approval [RFC5226]. Assignments consist of an extension token (as defined in Section 15.1 of [RFC5245]) and a reference to the document defining the extension.
IANAは、ICE候補者輸送拡張のための「インタラクティブ接続確立（ICE）」レジストリに「Interactive Connectivity Indecivity Indecivity（ICE）」に新しいサブレジストリ「氷輸送プロトコル」を作成しました。初期値を以下に示します。将来の割り当ては、IETFレビューまたはIESG承認[RFC5226]を通じて行われます。割り当ては、拡張トークン（[RFC5245]のセクション15.1で定義されている）と、拡張機能を定義するドキュメントへの参照で構成されています。
Token Reference
----- ---------
UDP RFC 5245, Section 15.1
TCP RFC 6544, Section 4.5
The authors would like to thank Tim Moore, Saikat Guha, Francois Audet, Roni Even, Simon Perreault, Alfred Heggestad, Hadriel Kaplan, Jonathan Lennox, Flemming Andreasen, Dan Wing, and Vijay Gurbani for the reviews and input on this document. Special thanks to Marc Petit-Huguenin for providing the SDP examples.
著者は、ティム・ムーア、サイカット・グハ、フランソワ・オーデット、ロニ・イヴ・ロニ、サイモン・ペロー、アルフレッド・ヘゲスタッド、ハドリエル・カプラン、ジョナサン・レノックス、フレミング・アンドレアセン、ダン・ウィング、ビジャイ・グルバニに感謝します。SDPの例を提供してくれたMarc Petit-Hugueninに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571] Lazzaro、J。、「接続指向の輸送上のリアルタイム輸送プロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットのフレーミング」、RFC 4571、2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox、J。、「セッション説明プロトコル（SDP）の輸送層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NAT周辺のリレーを使用したトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、RFC 5766、2010年4月。
[IMC05] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of the 5th ACM SIGCOMM Conference on Internet Measurement, 2005.
[IMC05] Guha、S。およびP. Francis、「NATとファイアウォールを介したTCPトラバーサルの特性評価と測定」、2005年の第5回ACM Sigcomm会議の議事録、2005年。
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP] Cheshire、S.、Krochmal、M。、およびK. Sekar、「NATポートマッピングプロトコル（NAT-PMP）」、2008年4月、進行中の作業。
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012.
[PCP-Base] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R.、およびP. Selkirk、「ポートコントロールプロトコル（PCP）」、2012年3月の作業。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、 "Socks Protocolバージョン5"、RFC 1928、1996年3月。
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089] Kitamura、H。、「ソックスベースのIPv6/IPv4ゲートウェイメカニズム」、RFC 3089、2001年4月。
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RFC3103] Borella、M.、Grabelsky、D.、Lo、J。、およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、2001年10月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006.
[RFC4540] Stiemerling、M.、Quittek、J。、およびC. Cadar、「NECのシンプルなミドルボックス構成（SIMCO）プロトコルバージョン3.0」、RFC 4540、2006年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008.
[RFC5190] Quittek、J.、Stiemerling、M。、およびP. Srisuresh、「ミドルボックス通信のための管理オブジェクトの定義」、RFC 5190、2008年3月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT行動要件」、BCP 142、RFC 5382、2008年10月。
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010.
[RFC6062] Perreault、S。およびJ. Rosenberg、「TCP割り当てのNAT（ターン）拡張機能の周りのリレーを使用したトラバーサル」、RFC 6062、2010年11月。
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[RFC6081] Thaler、D。、「Teredo Extensions」、RFC 6081、2011年1月。
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011.
[RFC6156] Camarillo、G.、Novo、O.、およびS. Perreault、「IPv6のNAT周辺のリレーを使用したトラバーサル」、RFC 6156、2011年4月。
[UPnP-IGD] Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., Schmitz, M., Siddiqi, W., and M. Blaszczak, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001.
[UPNP-IGD] Warrier、U.、Iyer、P.、Pennerath、F.、Marynissen、G.、Schmitz、M.、Siddiqi、W。、およびM. Blaszczak、「インターネットゲートウェイデバイス（IGD）標準化されたデバイス制御Protocol v 1.0 "、2001年11月。
Compared to UDP-based ICE, ICE TCP has, in general, lower success probability for enabling connectivity without a relay if both of the hosts are behind a NAT. This happens because many of the currently deployed NATs have endpoint-dependent mapping behavior, or they do not support the flow of TCP handshake packets seen in the case of TCP simultaneous-open, e.g., some NATs do not allow incoming TCP SYN packets from an address where a SYN packet has been sent to recently or the subsequent SYN-ACK is not processed properly.
UDPベースのICEと比較して、ICE TCPは一般に、両方のホストがNATの背後にある場合、リレーなしで接続を可能にするための成功確率を低くします。これは、現在展開されているNATの多くがエンドポイント依存のマッピング動作を持っているか、TCP同時オープンの場合に見られるTCPハンドシェイクパケットのフローをサポートしていないために起こります。Synパケットが最近送信された場合、またはその後のSyn-ackが適切に処理されていないアドレス。
It has been reported in [IMC05] that with the population of NATs deployed at the time of the measurements (2005), one of the NAT traversal techniques described here, TCP simultaneous-open, worked in roughly 45% of the cases. Also, not all operating systems implement TCP simultaneous-open properly and thus are not able to use such candidates. However, when more NATs comply with the requirements set by [RFC5382] and operating system TCP stacks are fixed, the success probability of simultaneous-open is likely to increase. Also, it is important to implement additional techniques with higher success ratios, such as Teredo, whose success in different scenarios is described in Figure 1 of [RFC6081].
[IMC05]では、NATの母集団が測定時に展開された場合（2005年）、ここで説明するNATトラバーサル技術の1つであるTCPが同時に開放されており、ケースの約45％で機能したことが報告されています。また、すべてのオペレーティングシステムがTCPを同時に適切に実装するわけではないため、そのような候補者を使用できません。ただし、より多くのNATが[RFC5382]によって設定された要件とオペレーティングシステムTCPスタックが固定されている場合、同時開放の成功確率は増加する可能性があります。また、テレドなど、より高い成功率を持つ追加の手法を実装することが重要です。テレドは、さまざまなシナリオでの成功を[RFC6081]の図1に記載しています。
Finally, it should be noted that implementing various techniques listed in Section 5 should increase the success probability, but many of these techniques require support from the endpoints and/or from some network elements (e.g., from the NATs). Without comprehensive experimental data on how well different techniques are supported, the actual increase of success probability is hard to evaluate.
最後に、セクション5にリストされているさまざまな手法を実装することは成功確率を高めるはずですが、これらの手法の多くは、エンドポイントおよび/または一部のネットワーク要素（たとえば、NATから）からのサポートを必要とすることに注意する必要があります。さまざまな手法がどれだけよくサポートされているかに関する包括的な実験データがなければ、実際の成功確率の増加を評価するのは困難です。
This specification requires unusual handling of TCP connections, the implementation of which is non-trivial in traditional BSD socket APIs.
この仕様には、TCP接続の異常な処理が必要であり、その実装は従来のBSDソケットAPIでは自明ではありません。
In particular, ICE requires an agent to obtain a local TCP candidate, bound to a local IP and port, then initiate a TCP connection from that local port (e.g., to the STUN server in order to obtain server reflexive candidates, to the TURN server to obtain a relayed candidate, or to the peer as part of a connectivity check), and be prepared to receive incoming TCP connections (for passive and simultaneous-open candidates). A "typical" BSD socket is used either for initiating or receiving connections, and not for both. The code required to allow incoming and outgoing connections on the same local IP and port is non-obvious. The following pseudocode, contributed by Saikat Guha, has been found to work on many platforms:
特に、ICEでは、エージェントがローカルIPとポートにバインドされたローカルTCP候補を取得し、そのローカルポートからTCP接続を開始する必要があります（たとえば、サーバー反射候補を取得するためにSTUNサーバーへ、ターンサーバーへリレーした候補を取得したり、接続チェックの一部としてピアに取得したり、着信TCP接続を受信する準備をしてください（受動的で同時に開かれた候補者用）。「典型的な」BSDソケットは、両方ではなく、接続の開始または受信に使用されます。同じローカルIPおよびポートで着信および発信接続を許可するために必要なコードは、非自明です。Saikat Guhaによって貢献した以下のPseudocodeは、多くのプラットフォームで動作することがわかっています。
for i in 0 to MAX sock_i = socket() set(sock_i, SO_REUSEADDR) bind(sock_i, local)
0からmax sock_i = socket（）set（sock_i、so_reuseaddr）bind（sock_i、local）のiの場合
listen(sock_0) connect(sock_1, stun) connect(sock_2, remote_a) connect(sock_3, remote_b)
聞く（sock_0）connect（sock_1、stun）connect（sock_2、remote_a）connect（sock_3、remote_b）
The key here is that, prior to the listen() call, the full set of sockets that need to be utilized for outgoing connections must be allocated and bound to the local IP address and port. This number, MAX, represents the maximum number of TCP connections to different destinations that might need to be established from the same local candidate. This number can be potentially large for simultaneous-open candidates. If a request forks, ICE procedures may take place with multiple peers. Furthermore, for each peer, connections would need to be established to each passive or simultaneous-open candidate for the same component. If we assume a worst case of 5 forked branches, and for each peer, five simultaneous-open candidates, that results in MAX=25.
ここで重要なのは、聴取（）呼び出しの前に、発信接続に使用する必要があるソケットの完全なセットを割り当てて、ローカルIPアドレスとポートに拘束する必要があることです。この数であるMaxは、同じローカル候補から確立する必要があるさまざまな宛先へのTCP接続の最大数を表しています。この数は、同時に開かれた候補者の場合、潜在的に大きくなる可能性があります。要求の場合、複数のピアで氷の手順が行われる場合があります。さらに、ピアごとに、同じコンポーネントの各受動的または同時に開かれた候補に接続を確立する必要があります。5つの分岐ブランチの最悪のケースと、各ピア、5つの同時オープン候補の場合、MAX = 25になります。
This section shows two examples of SDP offer and answer when the ICE TCP extension is used. Both examples are based on the simplified topology of Figure 8 in [RFC5245], with the same IP addresses. The examples shown here should be considered strictly informative.
このセクションでは、ICE TCP拡張が使用されている場合のSDPオファーと回答の2つの例を示します。どちらの例も、同じIPアドレスを持つ[RFC5245]の図8の単純化されたトポロジに基づいています。ここに示す例は、厳密に有益であると見なされるべきです。
In the first example, the offer contains only TCP candidates (lines are folded in examples to satisfy RFC formatting rules):
最初の例では、オファーにはTCP候補のみが含まれています（RFCのフォーマットルールを満たすために、ラインは例で折りたたまれています）：
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 TCP/RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=setup:active
a=connection:new
a=candidate:1 1 TCP 2128609279 10.0.1.1 9 typ host tcptype active
a=candidate:2 1 TCP 2124414975 10.0.1.1 8998 typ host tcptype passive
a=candidate:3 1 TCP 2120220671 10.0.1.1 8999 typ host tcptype so
a=candidate:4 1 TCP 1688207359 192.0.2.3 9 typ srflx raddr 10.0.1.1
rport 9 tcptype active
a=candidate:5 1 TCP 1684013055 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 tcptype passive
a=candidate:6 1 TCP 1692401663 192.0.2.3 45687 typ srflx raddr
10.0.1.1 rport 8999 tcptype so
The answer to that offer could look like this:
その申し出に対する答えは次のようになる可能性があります：
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 TCP/RTP/AVP 0
b=RS:0
b=RR:0
a=setup:passive
a=connection:new
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2128609279 192.0.2.1 9 typ host tcptype active
a=candidate:2 1 TCP 2124414975 192.0.2.1 3478 typ host tcptype passive
a=candidate:3 1 TCP 2120220671 192.0.2.1 3482 typ host tcptype so
In the second example, UDP and TCP media streams are mixed, but S-O candidates are omitted due to hosts not supporting TCP simultaneous-open, and UDP candidates are preferred (but preference order for candidate types is kept the same) by decreasing the TCP candidate type preferences by one (i.e., using type preference 125 for the host candidates and 99 for the server reflexive candidates):
2番目の例では、UDPとTCPのメディアストリームは混合されますが、TCP同時オープンをサポートしていないホストのためにS-O候補は省略されており、UDP候補はTCP候補を減らすことで候補者タイプの優先順序が同じに保たれます）。タイプ設定（つまり、ホスト候補にタイプ設定125を使用し、サーバー反射候補者に99を使用）：
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 TCP 2111832063 10.0.1.1 9 typ host tcptype active
a=candidate:2 1 TCP 2107637759 10.0.1.1 9012 typ host tcptype passive
a=candidate:3 1 TCP 1671430143 192.0.2.3 9 typ srflx raddr 10.0.1.1
rport 9 tcptype active
a=candidate:4 1 TCP 1667235839 192.0.2.3 44642 typ srflx raddr
10.0.1.1 rport 9012 tcptype passive
a=candidate:5 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:6 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
The corresponding answer could look like this:
対応する答えは次のようになります：
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 TCP 2111832063 192.0.2.1 9 typ host tcptype active
a=candidate:2 1 TCP 2107637759 192.0.2.1 3478 typ host tcptype passive
a=candidate:3 1 UDP 2130706431 192.0.2.1 3478 typ host
Authors' Addresses
著者のアドレス
Jonathan Rosenberg jdrosen.net
Jonathan Rosenberg Jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
EMail: ari.keranen@ericsson.com
Bruce B. Lowekamp Skype
ブルース・B・ローカンプ・スカイプ
EMail: bbl@lowekamp.net
Adam Roach Tekelec 17210 Campbell Rd., Suite 250 Dallas, TX 75252 US
Adam Roach Tekelec 17210 Campbell Rd。、Suite 250 Dallas、TX 75252 US
EMail: adam@nostrum.com