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)
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.
インタラクティブ接続確立（ICE）は、セッション交渉のオファー/アンサーモデルに基づいたマルチメディア通信プロトコルのためのNATトラバーサルのためのメカニズムを定義します。その後、NATのためのセッショントラバーサルユーティリティ（STUN）に基づいてピア・ツー・ピア接続をチェックして検証される各メディアストリームのための候補トランスポート・アドレスのセットを提供することによって、ICE作品。 ICEは、候補者を記述するための一般的なフレームワークを提供するだけUDPベースのメディアストリームを定義します。この仕様は、単一のストリームのためのTCPおよびUDPベースの候補の組み合わせを提供する機能など、TCPベースのメディアにICEを拡張します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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トラバーサルのためのメカニズムを定義します。その後、NATのためのセッショントラバーサルユーティリティ（STUN）[RFC5389]に基づいて、ピア・ツー・ピア接続をチェックして検証される各メディアストリームのための候補トランスポート・アドレスのセットを提供することによって、ICE作品。しかし、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のためのICEのサポートが必要とされています。また、RTPはまた、TCP [RFC4571]の上に実行することができます。一般的に、TCP UDP上でRTPを実行することが好ましい、とではありません。しかし、さまざまなネットワーク環境では、過度に制限NATやファイアウォールデバイスは完全にUDPベースの通信を防ぐが、一般的なTCPベースの通信が許可されています。そのような環境では、TCP上のRTPを送信するので、メディアセッションを確立し、それは完全に失敗有することが好ましいであろう。この仕様では、薬剤は、メディアストリームのためにUDPとTCPの候補者を集めることができる優先度の高いUDPのものをリストアップし、UDPのものが失敗した場合にのみ、TCPベースのものを使用します。これは、マルチメディア通信は、高い信頼性を可能にするフォールバックメカニズムを提供します。
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.
NAT（TURN）[RFC5766]の周りにリレーを使用トラバーサルと組み合わせた場合にTCPオーバーRTPの使用は、特に有用です。この場合、剤の一つは、TCPを使用してTURNサーバーに接続し、TCPベースの中継された候補者を得るでしょう。それは候補としてそのピアエージェントにこれを提供します。他の薬剤は、TURNサーバーへのTCP接続を開始します。その接続が確立されると、メディアがTURNサーバーを介して、接続を介して流れることができます。この使用方法の利点は、それが唯一の公共ネットワーク上のサーバへのアウトバウンド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 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を拡張します。また、ICEは、TCPとUDPの候補者の両方を提供するために、RTPおよびSecure RTP（SRTP）で使用することができる方法を定義します。この仕様は、ICE自体の概要を以下とICEにTCP候補を支援するための追加や変更を呼び出すことによってそうします。 ICEの基本動作[RFC5245]はTCP候補とICEの使用方法を定義し、この文書に記載されている拡張子を除い変わりません。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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とICEの使用は比較的簡単です。この仕様は、主にこれらの接続は、候補対にどのように関係するか、いつ接続が開かれ、どのように扱っています。
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）候補。アクティブな候補者は、エージェントがアウトバウンド接続を開こうとしますが、着信接続要求を受信しませんれるものです。受動的な候補薬剤が着信接続試行を受信するが、接続を試行しないであろうためです。 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候補を取得します。同様に、一方が得るための異なる技術を使用することができ、例えば、サーバ再帰、NATアシストトンネリング、またはこれら三種類（セクション5を参照）の候補を中継。リレーされたとサーバ再帰候補者のために使用するサーバへの接続は、ICEの処理中に開いたままにしています。
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 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.
オファーとアンサーにこれらの候補をコードする場合、候補の種類が通知されます。アクティブ候補の場合には、IPアドレスとポートの両方が存在するが、ポートは、（それだけで他の候補の種類と一致するアクティブ候補の符号化を行うためにそこにあり、ピアによって無視される）は無意味です。その結果、アクティブな候補者は、物理的にアドレス収集の時に割り当てする必要はありません。むしろ、接続の試行の結果として生じる物理的な割り当ては、接続性チェック時に起こります。
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は、彼らが同じポート上に表示されているので、STUNとアプリケーション層のトラフィックを分離するために、エージェントを必要とします。この分離は、[RFC5245]に記載されており、マジッククッキーおよびメッセージの他のフィールドを使用して行われます。それらはアプリケーションとSTUNパケットがアプリケーション層のトラフィックから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）を使用する場合STUNは、（D）TLS接続の外で実行されている間、彼らはまた、RFC 4571フレーミングシム上で実行されます。 （D）は右側に左側及びそれなしTLSで得ICE TCPプロトコルスタックは、図1に示されています。
+----------+
| |
| 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：TLSとし、（D）なしICE TCPスタック
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によって保護されたメディアストリームのために、エージェントは最初STUNメッセージを交換する、ICE手順を実行する、ということです。 ICEが完了すると次に、（D）TLS手続きが始まります。 ICE及び（D）TLSは、このようにプロトコルスタックにおける「ピア」です。 STUNメッセージは、（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 where mobility and user control are possible, a multiplicity of techniques is essential for reliability.
それは設定可能であるし、それをオフに設定し、機能を全く持っていないよりもはるかに優れています。この仕様の重要な目標は、すべてのエンドポイントタイプで使用できる単一のメカニズムを提供することです。このように、代わりの実装にハードコードされた制限の設定によってプロバイダとネットワークの変化を考慮することが好ましいです。また、ネットワークの特性および接続仮定は、および、時間の経過とともに変化することができます。エージェントは、パブリックネットワーク上のサーバと通信しているからといって、今日はそれがNAT明日の後ろに1と通信する必要がないという意味ではありません。エージェントがエンドポイント非依存のマッピングとNATの背後にあるからといって、今日は、そのエージェントをピックアップし、アドレス - ポート依存マッピングでNATがあり、パブリックネットワークアクセスポイントにそれを取らないこと明日を意味するものではありません。プロパティまたは唯一のアウトバウンドTCPを可能にするもの。それらの少なくとも1つは、ほぼ確実にどのような状況で動作するように起こっているように、エージェントは、アドレスを割り当てるための技術の多様なセットを実装するためにこれらのケースを処理し、信頼性の高いシステムを構築する方法があります。実装者は、アドレス割り当てのための機構の一つを実装しないように選出する前に、非常に慎重な展開について行われたすべての前提条件を考慮すべきです。具体的には、実装は、システム内の要素は移動可能で、異なる接続で異なるネットワークを介して接続することができるかどうかを検討すべきです。彼らはまた、場所やネットワーク接続性の観点から、その制御下にあるエンドポイントは、常に自分のコントロール下であるかどうかを検討すべきです。モビリティとユーザーコントロールが可能である環境では、技術の多様性は、信頼性のために不可欠です。
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.
次に、薬剤は、受動的（およびおそらくS-O）を入手する必要があり、セクション5.5で説明したように各構成要素の候補を中継します。各エージェントは、各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セットを取得することを推奨されます。追加の候補を取得することに成功し、直接接続を作成する機会が増加します。
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.
候補が得られたらICE処理が完了するまで、エージェントがオープン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.
メディアストリームは、（RTPなど）UDPベースである場合、エージェントは、TURNサーバ（または同様の機能を持ついくつかの他のリレー）からのUDPベースの候補を要求するために、追加のホストTCP候補を使用するかもしれません。そのような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ごとのTaミリ秒で実施ペーシングされる（[RFC5245]のセクション16を参照）。このペースでは、厳密STUN取引（バインディングと要求を割り当ての両方）を指します。トランザクションのパフォーマンスは、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 candidates. This allows ICE to use the lower latency UDP connectivity if it exists but fallback to TCP if UDP doesn't work.
トランスポートプロトコル自体は別の上に一つの候補を選択するための基準です。特定のメディア・ストリームは、UDPまたはTCP上で実行することができた場合は、UDP候補は、TCPの候補より優先される場合もあります。これは、UDPが動作しない場合は、TCPにフォールバックが存在する場合にはICEが低レイテンシーUDP接続を使用することができます。
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を参照）UDPトンネリングの候補者のためのNAT支援候補者と75のための105です。
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両方の候補が同じメディア・ストリームのために提供され、一つのトランスポートプロトコルが他よりも優先されるべきである場合、好ましいトランスポートプロトコル候補のタイプの好みが増加し、及び/又はされるべきである他のトランスポートプロトコル候補のタイプの好みSHOULD減少したこと。どのくらいの値は、特定のトランスポートプロトコルまたは特定の候補の種類を選択することがより重要であるかどうかに依存して増加または減少させるべきです。候補タイプがより重要である場合に他のトランスポートプロトコルの候補のために一つによってタイプ優先値を変更する（例えば、UDPが好ましい場合であっても、TCPホスト候補がUDPサーバ再帰候補よりも好まれる）が十分です。トランスポート・プロトコル（例えば、任意の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
ローカル優先=（2 ^ 13）*方向県+他方県
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.
方向県7が最も好ましい、0及び7（両方を含む）の間でなければなりません。他の-県が最も好ましい8191と、0と8191（両方を含む）の間でなければなりません。ホスト、UDPトンネリング、および中継TCP候補を有することが推奨される方向県次のように割り当てられる：S-Oパッシブ4、アクティブ6、及び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, 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.
ここに記載されている優先順位の優先順位は、単に成功確率と結果のパスの効率性のバランスをしようと提案しています。 ICEのTCPが使用されているシナリオに応じて、異なる値が適切かもしれません。 UDPトンネルのオーバーヘッドが問題ではない場合、彼らは高い成功確率を持っている可能性があるため、例えば、これらの候補者は、より高い優先すべきです。 TCP S-Oは、両方のエンドポイントのオペレーティング・システムでサポートされている場合、それはアクティブ - パッシブアプローチとして、少なくとも同様に動作するはずですので、また、同時オープンはNAT支援し、サーバ再帰候補者のためのアクティブとパッシブの候補者よりも優先されます。実装はS-O候補がサポートされているかどうかは不確実であるならば、低く、それらの優先順位を決定するのが妥当かもしれません。ホストの場合は、UDPトンネリング、および候補者を中継アクティブ - パッシブ候補は、少なくともだけでなく、それらと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).
任意の二つの候補者が同じタイプの好みや方向-県を持っている場合、彼らは独自の他、県を持たなければなりません。本明細書では、これは通常は他の-県候補が得られた特定の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.
デフォルト候補は主に非ICEピアでの作業、それの可能性に基づいて選択されます。混合モード（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]「セットアップ」属性の値が「アクティブ」のデフォルト候補としてアクティブ候補を選択して使用するために提供する完全なエージェントをお勧めします。エージェントがNATの背後にあるとピアがない場合、これはでも、ICEのサポートなしで成功した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で説明したように、オファーが（すなわち、それは常に、グローバルに一意のIPアドレスを公開する必要があります）ライトモードの基準を満たしている場合、それはTCP候補についてICEのライトモードを使用するかもしれません。アクティブな候補は、デフォルトの候補として必要とされない限り、ライトモードでは、TCPの候補のために、唯一のパッシブホスト候補は、収集されます。そうでない場合は、[RFC5245]でライトモードに関して記載した手順はまた、TCPの候補者に適用されます。 UDPとTCPの候補者がメディア・ストリーム内に混在している場合は、モード（ライトまたはフル）は、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候補など=候補線に符号化されます。しかし、（すなわち、[RFC5245]、セクション15.1で定義されたトランスポート拡張トークンの値）（アクティブ、パッシブ、又はS-O）、「TCP」と接続タイプに設定されているトランスポートプロトコルは、新しい拡張属性を使用して符号化されます。 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)
"基礎SPコンポーネント-ID SP "TCP" SP優先SPコネクション・アドレスSPポートSPのCAND型[SPのREL-addrに] [SP REL-ポート] SPのTCPタイプ-EXT *：= "候補"" 候補属性（SP拡張-ATT名SP拡張-ATT値）
tcp-type-ext = "tcptype" SP tcp-type tcp-type = "active" / "passive" / "so"
tcptype-EXT = "tcptype" SPのtcptype tcptype = "アクティブ" / "受動的" / "そう"
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ベースの場合、エージェントは、A =セットアップを含まなければならないと=接続がICEを使用していないかのようにそこに定義された手順を以下、RFC 4145 [RFC4145]からの属性。エージェントは回答がある場合は特に、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コネクション確立の方向性は、ここで定義されたICE属性と手順によって決定されます。
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を構築しなければなりません。方向性属性（=セットアップ）は、TLSハンドシェイクの方向を決定するために厳密に利用されます。 TCPコネクション確立の方向性は、ここで定義されたICE属性と手順によって決定されます。
Examples of SDP offers and answers with ICE TCP extensions are shown in Appendix C.
SDPオファーやICEのTCP拡張と回答の例は、付録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つは、少なくとも1つの中継された技術（例えば、TURN）およびNAT（例えば、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アドレッシングをサポートしていない場合、クライアントは、ターンのIPv6 [RFC6156]、Teredoの[RFC4380]、またはSOCKSのIPv4-IPv6のゲートウェイ[RFC3089]を、IPv6の候補を得るために、例えば、他の技術の使用をしなければなりません。
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トンネリングのいずれかを使用して、または技術を中継することは、多くの場合十分です。
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 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.
ホストの候補者は、彼らが唯一必要とホストのインタフェース上のTCPソケットを開き、そこから接続性チェックを送信/受信以来、最もシンプルな候補です。ホストが異なる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つのホスト候補（異なるポート上の各）を得なければなりませんホストは、持っていること - 同時オープン用とパッシブ候補者のための1つ。エージェントは、これらのモードのいずれかで作用することが可能でない場合は、それらの候補を省略します。
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の他方の側のサーバからの求め、次いで、（例えば、既に存在しない限り）ホスト間で送信される接続性チェックとのNATに適切なバインディングを作成することによって、ホストに与えられたアドレスを発見することを目的とします。これらの技術の成功は、[RFC5382] NATのマッピングおよびフィルタリング動作に依存し、また、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候補から導出することができます。 1つは、実際に良い作品ホストとNATのに依存しているので、両方のサーバー再帰受動的およびS-O候補を取得するのに便利です。さらに、いくつかの技術（例えば、中継回転）予めピアのアクティブ候補のIPアドレスを知ることが必要なので、アクティブサーバ再帰候補が正常に機能するような技術のために必要とされます。
A widely used protocol for obtaining server reflexive candidates is STUN. Its TCP-specific behavior is described in [RFC5389], Section 7.2.2.
サーバー再帰候補を得るために広く使われているプロトコルはSTUNです。その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 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と通信し、このように、NATがホストに与えられたアドレスを発見します。 NAT支援技術はまた、NATの上、適切なバインディングを作成します。サーバー反射的技術に比べてこれらの技術の利点は、接続が正常に作成できるように、NATのは、彼らのマッピングおよびフィルタリング動作を調整することができるということです。 NAT支援技術の欠点は、それらが一般的にのみホストと同じサブネット内にあり、従ってしばしばNATの複数の層を有するシナリオに失敗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.
これらの候補者は、ICEの提供でエンコードし、サーバ再帰候補者のように答えるが、（第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-BASE]、SOCKS [RFC1928]、レルム特定IP（RSIP）[RFC3103]、およびシンプルなミドル構成（SIMCO）[RFC4540]を含んでいます。また、ミドル・コミュニケーションズ（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トラバーサルより簡単でより効率的であるという事実を利用します。これらの技術では、（おそらく、または完全なIPパケット）TCPパケットが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トンネリングの候補者は、ICEの提供でエンコードし、トンネリングプロトコル、ホスト間の中継を利用するかどうかに応じて、中継されたとして、またはサーバ再帰候補のいずれかを答えることができます。 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トラバーサル技術であります彼らのフィルタリングとマッピング動作の。しかしながら、リレーを使用するなど、いくつかの欠点を有し、それは通常、パケットの準最適経路をもたらす、リレーが存在する必要があり、それが発見される必要がある、リレーは、潜在的にA消費を中継する、障害の可能性のある一点です直接のパスが他の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]）。適切なサーバが利用可能であり、サーバがこれを許可した場合に中継候補としてセキュアシェル（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候補とICEの提供を処理するUDP候補者と同様の方法で動作します。まず、ICEのサポートは（[RFC5245]のセクション5.1で説明した氷不一致のチェックを含む）、検証され、エージェントの役割が決定されます。候補は、セクション4.2で説明したように、セクション5に記載され優先順位付け技術を使用して収集されます。デフォルトの候補は、4.3節で考慮に考慮を取って選択されています。 SDPの答えは、符号化4.5節に記述されているTCP候補を除いて、[RFC5245]の4.3節のように符号化されています。
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.
オファー側が最初の答えを受け取ると、それはまた、ICEのサポートを確認し、その役割を決定します。薬剤の両方は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.
両方の薬剤は、ライトモードを使用しているとオファーは、A =設定使用している場合ならば：新しいオファーに活性な属性[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.
アンサーは、接続がすでに新しいオファーを並行して作成された候補のペアに一致する新しい申し出を受けた場合、それは申し出を受け入れなければならないし、既に作成された接続を維持しながら、それに応答します。新しいオファーを並行して作成された接続が新しいプランで候補ペアと一致しない場合は、接続が閉じなければならない、とICEの再起動を実行する必要があります。
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）が使用されない限り、両方の薬剤が、ライトモードを使用するシナリオで接続性チェックを使用して認証されていないので、代わりにフルモードを使用することが推奨されます。完全な実装の考慮事項に対してより多くのライトについては、[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と同様に、チェックリストは、唯一のフルICEの実装によって形成されています。候補対を形成する場合、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.
TCP接続のチェックは、UDPと同じように、唯一の完全な実装によって生成されます。 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で定義された長さフィールドは、各STUNメッセージに先行するように要求と応答を結合STUNは、このシムの頂部に送られます。 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 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.
接続が確立されると、クライアント・プロシージャは、UDPの候補者のためのものと同じです。 TCPは信頼性の高いメッセージ配信の世話をするので、STUNの接続性チェックメッセージの再送信は、必要とされていません。メモは、アクティブTCP候補で受信そのSTUN応答は、典型的には、ピア再帰候補を生成します。確立されたTCP接続上の最初の接続性チェックへの応答がSTUNメッセージ以外の何かがある場合は、リモート候補アドレスは明らかにピアのアドレスの一つではなかった、とエージェントは接続を閉じて、そのリモート候補として持つすべてのペアを検討すべきです失敗しました。
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]で定義されたフレーミングを利用しなければなりません。これによってフレーミングに、エージェントは、個別のフレーム内のデータを受信します。各フレームは、TLS、DTLS、またはSTUNパケット（例えばRTPまたはSRTPのような）媒体とすることができます。 10.2項に記載されているようにSTUNパケットが抽出されます。
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.
メディアストリームのためのICEの処理が完了すると、各エージェントは、ICEによって選択された候補ペアの間のものを除いて（これによる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.
これら二つのルールは関連しています。 ICEの完了時に接続の閉鎖は、通常の選択アルゴリズムが使用されなければならないことを意味します。積極的な選択は過渡ペアが選択されることがありますので、これがあります。このような対が選択されると、薬剤は、より良い選択のように選択されようとすることができる一方が他の接続を閉じることになります。この競合状態が誤っている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の再起動は、ICEによって選択されたTCP候補ペアとメディアストリームのために発生した場合、エージェントは、再起動後に接続を閉じてはなりません。提供または再起動が発生する答えでは、薬剤は、そのトランスポートアドレス、以前に選択された候補と一致した同時オープン候補を含むかもしれません。両方のエージェントがこれを行う場合、結果は既存のTCP接続をマッチング同時オープン候補ペアになります。この場合、エージェントは、新しい接続を開きます（または新しいTLSまたはDTLS-SRTPの手続きを開始）することを試みてはいけません。代わりに、その既存の接続が再利用され、そしてSTUNチェックが実行されます。
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のフレームにおけるペイロードとして。バイトの結果セットは、セクション6と[RFC5389]の8つのルールに基づいて、STUNパケットとして見られるかどう次に、送信者かどうかを確認します。これは、上位2ビットのチェック、マジッククッキー、長さ、および指紋を含んでいます。 、これらのルールに基づいて、バイトがSTUNメッセージと見なすことになる場合は、長さチェックが失敗するように、送信側は、バイトの異なった数を利用しなければなりません。それはバイトストリームから任意のバイト数が、チェックのすべてに基づいて、STUNパケットに似ているであろうと、通常は非常に低いですがアプリケーションストリームの含有量は、例えば（STUNメッセージが含まれているために発生した場合、それは、ファイルを発生することがありますSTUNメッセージを含むクライアントからのログの転送）。
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手順は、メディアストリームを保護するために利用されている場合、これらの手順は、ICE仕様[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フレームのペイロードを抽出し、それがSTUN又は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.
非STUNデータの場合、エージェントはフレームから収集した継続的なバイトストリームにこれを追加します。それが直接の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 ICEの再起動は、異なる候補ペアの選択で、その結果、行われます。
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.
そのイベントが発生したときにこれらのケースのいずれにおいても、エージェントが接続を閉じる必要があります。これは、薬の一つが、通常は最初の接続を閉じることになります。その場合にはセッションの両方のエージェントに適用されます。
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.
エージェントのローカル候補がTCP-アクティブまたはTCP-そうであるならば、O、それは選択されたペアのリモート候補への接続を再度開く必要があります。
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のフレーミングが利用されています。エージェントが接続をオープンし、完全なエージェントである場合、それはSTUNの接続性チェックを送らなければなりません。エージェントは、それが開かれたり受け入れ接続を介して接続性チェックを受けるために準備しなければなりません（これは一般的に真であることに注意してください。ICEは、エージェントが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を再起動する必要があります。これは、薬剤の一つは接続に依存マッピングプロパティ[RFC5382]とNATの背後にある場合に起こります。
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.
エージェントが中継された候補を収集する目的で、TURNサーバーへの接続を開いた場合TURNサーバーから中継された候補者は、ICEで選択された場合、その接続は、メディアセッションの間、クライアントで開いたままにしなければなりません。 ICEの処理が完了するとそうでない場合は、TURNサーバーへの接続を閉じる必要があります。
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 stream. Similar measures SHOULD apply also to other types of relaying servers.
、クライアントの努力にもかかわらず、TURNサーバーへのTCP接続は、そのサーバによって割り当てられたトランスポート・アドレスを利用し、メディアセッションの存続期間中に失敗した場合、クライアントは、TURNサーバーに再接続し、新たな割り当てを取得し、氷を再起動する必要がありそのメディアストリーム。同様の措置は、中継サーバの他のタイプにも適用されるべきです。
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セキュア（SIPS）[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.
STUN増幅攻撃は[RFC5245]のセクション18.5.2に記載されています。同じ考察は、TCPに適用されますが、TCPでの増幅効果は、任意のチェックが実行される前に、TCPコネクションを確立するために必要とするため、大きくなっています。したがって、ICEエージェントは、同じ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.
両方の薬剤は、ライトモードを使用する場合は、接続性チェックは送信されず、追加の手順（例えば、メディアレベルのセキュリティ）が接続を検証するために必要とされます。ピアは、偶然同じプライベートアドレス空間を使用して別のサブネット内のホストに接続することがあります。ホストの1つがNATの背後にあるプライベートアドレス空間からアドレスを持っている場合は接続性チェックの欠如は特に問題です。これは、ライトモードがNATの背後にあるICEエージェントに適していない理由の一つです。
A more detailed analysis of different attacks and the various ways ICE prevents them are described in [RFC5245]. Those considerations apply to this specification.
異なる攻撃や様々な方法のICEのより詳細な分析は、それらが[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）」のレジストリに新しいサブレジストリ「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.
作者は、このドキュメントのクチコミと入力のためにティム・ムーア、Saikatグハ、フランソワAudet、ロニでも、サイモン・ペロー、アルフレッドHeggestad、Hadrielカプラン、ジョナサン・レノックス、フレミングAndreasenの、ダン・ウィング、およびビジェイGurbaniに感謝したいと思います。 SDPの例を提供するためのマーク・プティ・Hugueninに感謝します。
[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月。
[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）とのオファー/アンサーモデル"。
[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月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、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]ラザロ、J.、RFC 4571、2006年7月 "リアルタイム転送プロトコル（RTP）およびRTP制御プロトコルコネクション型トランスポート・オーバー（RTCP）パケットをフレーミング"。
[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]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（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]クロッカー、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]ローゼンバーグ、J.、 "インタラクティブ接続確立（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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するための拡張」、RFC 5764、2010年5月。
[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月。
[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]グハ、S.及びP.フランシス、「特性とのNATやファイアウォールを介してTCPトラバーサルの測定」、インターネット計測、2005年第5回ACM SIGCOMM会議の議事録。
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]チェシャー、S.、Krochmal、M.、およびK.スカール、 "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]ウイング、D.、チェシャー、S.、Boucadair、M.、Penno、R.、およびP.セルカーク、 "ポート制御プロトコル（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]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089]北村、H.、 "SOCKSベースの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]ボレッラ、M.、Grabelsky、D.、ロー、J.、およびK.谷口、 "レルム特定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、 "セキュアシェル（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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（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]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、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]ペロー、S.およびJ.ローゼンバーグ、 "NAT（TURN）の周りにトラバーサル使用リレーTCP割り当ての拡張"、RFC 6062、2010年11月。
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[RFC6081]ターラー、D.、 "Teredoの拡張機能"、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]キャマリロ、G.、ノボ、O.、およびS.ペロー、 "IPv6のトラバーサルNAT周りにリレーを使用（TURN）拡張子"、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.、アイヤル、P.、Pennerath、F.、Marynissen、G.、シュミッツ、M.、Siddiqi、W.、およびM. Blaszczak、「インターネットゲートウェイデバイス（IGD）標準デバイス制御議定書V 1.0" 、2001年11月。
Appendix A. Limitations of ICE TCP
付録A.制限ICEのTCPの
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.
ホストの両方がNATの背後にある場合はUDPベースのICEと比較すると、ICE TCPは、一般的には、リレーなしで接続を可能とするための低成功確率を持っています。現在展開のNATの多くがエンドポイントに依存マッピング動作を持っているので、これが発生し、またはそれらは例えば、同時オープンTCPの場合に見られTCPハンドシェイクパケットの流れをサポートしていない、いくつかのNATはからの着信TCP SYNパケットを許可していません。 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].
測定（2005）、ここで説明するNATトラバーサル技術の一つの時点で展開するNATの人口、TCP同時オープンで、例の中におよそ45％を働いたということは、[IMC05]で報告されています。また、いないすべてのオペレーティング・システムが正常にTCP同時オープンを実装するため、このような候補を使用することができません。しかし、より多くのNATが固定されている[RFC5382]で設定された要件およびオペレーティングシステムのTCPスタックに準拠する場合、同時オープンの成功確率が増加する可能性があります。また、このような成功異なるシナリオに[RFC6081]の図1に記載されているのTeredo、としてより高い成功率を持つ追加の技術を実装することが重要です。
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をより）からの支援を必要とします。異なる技術がサポートされてどれだけの包括的な実験データがなければ、成功確率の実際の増加は、評価することは困難です。
Appendix B. Implementation Considerations for BSD Sockets
BSDソケット付録B.実装の考慮事項
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は、TURNサーバーに、サーバー再帰候補を得るために、STUNサーバへのローカルポート（例えば、からのTCP接続を開始し、ローカルIPおよびポートにバインドされ、ローカルTCP候補を取得するためにエージェントが必要です）接続性チェックの一部として、またはピアに中継候補を取得し、受動的及び同時オープン候補の着信TCP接続を（）を受信するように準備されます。 「典型的な」BSDソケットは接続を開始または受信するための、および両方ではないためにも使用されます。同じローカルIPおよびポート上の着信および発信接続を許可するために必要なコードは、非自明です。 Saikatグハが寄与する次の擬似コードは、多くのプラットフォーム上で動作することがわかっています。
for i in 0 to MAX sock_i = socket() set(sock_i, SO_REUSEADDR) bind(sock_i, local)
I MAX sock_i =ソケット（）セット（sock_i、SO_REUSEADDR）バインド（sock_i、ローカル）を0にするための
listen(sock_0) connect(sock_1, stun) connect(sock_2, remote_a) connect(sock_3, remote_b)
聞く（sock_0）接続（sock_1、スタン）接続（sock_2、remote_a）接続（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接続の最大数を表します。この数は、同時オープンの候補者のための潜在的に大きくなることがあります。リクエストフォーク場合は、ICEの手順は、複数のピアで行われてもよいです。さらに、各ピアのために、接続が同じコンポーネントのそれぞれ受動的又は同時オープン候補に確立される必要があります。我々は5本のフォーク枝の最悪のケースを想定し、各ピアのために、5同時オープン候補、MAXの結果は25を=という場合。
Appendix C. SDP Examples
付録C. SDP例
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):
最初の例では、オファーは、（線はRFCのフォーマットルールを満足する実施例に折り畳まれている）のみTCP候補が含まれています。
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
V = 0 0 = IP4 IN jdoeの2890844526 2890842807 10.0.1.1 S = Cの= IP4 192.0.2.3 INさt = 0、A =氷PWD：asd88fgpdd777uzjYhagZg A =氷ufrag：8hhY M =オーディオ45664 TCP / RTP / AVP 0 B = RS：0 B = RR：0 A = rtpmap：0 PCMU / 8000 =セットアップ：アクティブA =接続：新A =候補：1つのTCP 2128609279 10.0.1.1 9 TYPホストtcptypeアクティブA =候補1：2 TCP 2124414975 10.0.1.1 8998標準ホストtcptype受動A =候補1：3 TCP 2120220671 10.0.1.1 8999標準ホストtcptypeので=候補1：4 TCP 1688207359 192.0.2.3 9 TYPのsrflxのRADDR 10.0.1.1 RPORT 9 tcptypeアクティブ=候補1：5 TCP 1684013055 192.0.2.3 45664標準のsrflxのRADDR 10.0.1.1 RPORT 8998 tcptype受動A =候補：6 1 TCP 1692401663 192.0.2.3 45687標準のsrflxのRADDR 10.0.1.1 RPORT 8999 tcptypeそう
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
V = 0 0 = IP4の192.0.2.1のT IN IP4 192.0.2.1 S = INボブ2808844564 2808844564のC = = 0、A =氷PWD：YH75Fviy6338Vbrhrlp8YhのA =氷ufrag：9uB6 M =オーディオ3478 TCP / RTP / AVP 0 B = RS：0 B = RR：0 A =セットアップ：受動A =接続：新しいA = rtpmap：0 PCMU / 8000 =候補：1 TCP 2128609279 192.0.2.1 9 TYPホストtcptypeアクティブA =候補1：2 TCP 2124414975 192.0.2.1 3478標準ホストtcptype受動A =候補1：3 TCP 2120220671 192.0.2.1 3482標準ホストtcptypeそう
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候補を減少させることによって、同時オープン、およびUDP候補が好ましい（しかし、候補の種類の優先順位が同じに保たれる）TCPをサポートしていないホストに混合されるが、SO候補が省略されています一つのタイプのプリファレンス（すなわち、サーバ再帰候補のホスト候補と99のタイプ嗜好125を使用して）。
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
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：0 A = rtpmap：0 PCMU / 8000 =候補：1つのTCP 2111832063 10.0.1.1 9 TYPホストtcptypeアクティブA =候補2：1 TCP 2107637759 10.0.1.1 9012標準ホストtcptype受動=候補1：3 TCP 1671430143 192.0.2.3 9 TYPのsrflxのRADDR 10.0.1.1 RPORT 9 tcptypeアクティブA =候補1：4 TCP 1667235839 192.0.2.3 44642標準のsrflxのRADDR 10.0.1.1 RPORT 9012 tcptype受動A =候補：5 1 UDP 2130706431 10.0.1.1 8998 TYPホストA =候補：6 1 UDP 1694498815 192.0.2.3 45664標準の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
V = 0 0 =ボブ2808844564 2808844564 IP4 192.0.2.1のIN、S = Cの= IP4 192.0.2.1 INさt = 0、A =氷PWD：YH75Fviy6338Vbrhrlp8Yh A =氷ufrag：9uB6 M =オーディオ3478 RTP / AVP 0 B = RS：0 B = RR：0 A = rtpmap：0 PCMU / 8000 =候補：1 TCP 2111832063 192.0.2.1 9 TYPホストtcptypeアクティブA =候補2：1 TCP 2107637759 192.0.2.1 3478標準ホストtcptype受動=候補：3 1 UDP 2130706431 192.0.2.1 3478 TYPホスト
Authors' Addresses
著者のアドレス
Jonathan Rosenberg jdrosen.net
ジョナサン・ローゼンバーグjdrosen.net
EMail: jdrosen@jdrosen.net URI: http://www.jdrosen.net
電子メール：jdrosen@jdrosen.net URI：http://www.jdrosen.net
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
KeranenエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: ari.keranen@ericsson.com
メールアドレス：ari.keranen@ericsson.com
Bruce B. Lowekamp Skype
ブルース・B. Lowekampスカイプ
EMail: bbl@lowekamp.net
メールアドレス：bbl@lowekamp.net
Adam Roach Tekelec 17210 Campbell Rd., Suite 250 Dallas, TX 75252 US
アダムローチTekelec 17210キャンベルRdを。、スイート250、ダラス、TX 75252米国
EMail: adam@nostrum.com
メールアドレス：adam@nostrum.com