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
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)
具有交互式连接建立（ICE）的TCP候选协议
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穿越机制。ICE的工作原理是为每个媒体流提供一组候选传输地址，然后通过基于NAT会话遍历实用程序（STUN）的对等连接检查对这些地址进行验证。ICE提供了一个描述候选媒体的通用框架，但只定义了基于UDP的媒体流。该规范将ICE扩展到基于TCP的媒体，包括为单个流提供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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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.
ICE对TCP的支持之所以重要，有很多原因。首先，存在仅在TCP上运行的媒体协议。例如，此类协议用于屏幕共享和即时消息[RFC4975]。为了使这些协议在NAT存在的情况下工作，除非它们定义了自己的NAT遍历机制，否则需要ICE对TCP的支持。此外，RTP还可以在TCP[RFC4571]上运行。通常，最好通过UDP而不是TCP运行RTP。然而，在各种网络环境中，过度限制的NAT和防火墙设备会完全阻止基于UDP的通信，但允许基于TCP的一般通信。在这样的环境中，通过TCP发送RTP，从而建立媒体会话，可能比让它完全失败更可取。使用此规范，代理可以收集媒体流的UDP和TCP候选，列出具有更高优先级的UDP，然后仅在UDP失败时使用基于TCP的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.
当结合使用NAT（TURN）周围的中继进行遍历时，TCP上的RTP的使用尤其有用[RFC5766]。在这种情况下，其中一个代理将使用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
本规范通过定义ICE与TCP候选协议的用法来扩展ICE。它还定义了ICE如何与RTP和安全RTP（SRTP）一起使用，以提供TCP和UDP候选协议。本规范通过遵循ICE本身和
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.
调用添加和更改以支持ICE中的TCP候选者。ICE[RFC5245]的基本行为保持不变，但本文档中定义了ICE与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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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.
ICE与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）候选。活动候选是代理将尝试打开出站连接但不会接收传入连接请求的候选。被动候选是代理将接收传入连接尝试但不尝试连接的候选。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
当将这些候选项编码为提议和回答时，将显示候选项的类型。在活动候选的情况下，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.
生成连接检查、管理检查列表状态和更新有效列表的实际过程对TCP的作用与对UDP的作用相同。
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]中进行了描述，并使用magic cookie和消息的其他字段完成。面向流的传输带来了另一个问题，因为它们需要一种方法来构建连接，以便能够提取应用程序和STUN数据包，从而将STUN数据包与应用程序层通信区分开来。因此，利用ICE的TCP媒体流使用RFC 4571[RFC4571]中提供的基本帧，即使应用层协议不是RTP。
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帧垫片上运行，而STUN在（D）TLS连接之外运行。生成的ICE TCP协议栈如图1所示，左侧有（D）个TLS，右侧没有TLS。
+----------+
| |
| App |
+----------+----------+ +----------+----------+
| | | | | |
| STUN | (D)TLS | | STUN | App |
+----------+----------+ +----------+----------+
| | | |
| RFC 4571 | | RFC 4571 |
+---------------------+ +---------------------+
| | | |
| TCP | | TCP |
+---------------------+ +---------------------+
| | | |
| IP | | IP |
+---------------------+ +---------------------+
+----------+
| |
| 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的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保护的任何媒体流，代理将首先运行ICE过程，交换STUN消息。然后，一旦ICE完成，（D）TLS程序开始。因此，ICE和（D）TL是协议栈中的“对等方”。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.
对于将ICE用于TCP流的报价人，使用以下程序。与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的NAT。处理这些情况并构建可靠系统的方法是让代理实现一组不同的地址分配技术，这样，在任何情况下，至少其中一种技术都可以正常工作。在选择不执行地址分配机制之一之前，实现者应该非常仔细地考虑关于部署的任何假设。具体而言，实现者应该考虑系统中的元素是否可以移动，并且通过不同的网络以不同的连接性连接。他们还应该考虑在位置和网络连通性方面，他们所控制的端点是否总是在他们的控制之下。在环境中
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.
强烈建议主机至少获得一组主机候选和一组中继候选。获得更多的候选者将增加成功创建直接连接的机会。
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连接打开，直到ICE处理完成。有关重要的实施指南，请参见附录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候选来从TURN服务器（或具有类似功能的其他中继）请求基于UDP的候选。此类UDP候选的使用遵循ICE中为UDP候选定义的过程。
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事务以每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
传输协议本身是选择一个候选者而不是另一个候选者的标准。如果特定媒体流可以在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使用低延迟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候选，并且一种传输协议应优于另一种传输协议，则应增加首选传输协议候选的类型首选项和/或减少其他传输协议候选的类型首选项。应增加或减少多少值取决于选择某个传输协议或某个候选类型是否更重要。如果候选类型更重要（例如，即使首选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
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表示被动，2表示S-O。对于NAT辅助和服务器自反候选者，建议值为：6表示S-O，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隧道的开销不是一个问题，那么这些候选者的优先级应该更高，因为他们可能有很高的成功概率。此外，对于NAT辅助候选和服务器自反候选，同时开放的优先级高于主动和被动候选，因为如果两个端点的操作系统都支持TCP S-O，那么它至少应该与主动-被动方法一样有效。如果一个实现不确定是否支持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).
如果任意两个候选主机具有相同的类型首选项和方向pref，则它们必须具有唯一的other-pref。根据本规范，这通常只发生在多宿主主机上，在这种情况下，other-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.
默认候选者的选择主要基于其与非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中所述的lite模式标准（即，其将始终拥有一个公共的、全球唯一的IP地址），则其可将ICE的lite模式用于TCP候选。在lite模式下，对于TCP候选，仅收集被动主机候选，除非需要主动候选作为默认候选。否则，[RFC5245]中描述的lite模式的过程也适用于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的候选者被编码到a=候选者行中，就像[RFC5245]中描述的UDP候选者一样。但是，传输协议（即[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)
候选属性＝“候选者”“：”基础SP组件ID SP“TCP”SP优先级连接地址SP SP端口cand类型[sp RelADDR] [sp RelPale] SP TCP类型Ext*（SP扩展ATT名称SP扩展ATT值）
tcp-type-ext = "tcptype" SP tcp-type
tcp-type = "active" / "passive" / "so"
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=设置和a=连接属性，并按照此处定义的过程进行操作，就像没有使用ICE一样。特别是，如果代理是应答者，则a=setup属性必须满足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建立的连接运行SRTP。替代方案RTP over TLS破坏了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介质，则SDP必须按照RFC 4572[RFC4572]中的描述构造。方向性属性（a=设置）严格用于确定TLS握手的方向。TCP连接建立的方向性由此处定义的ICE属性和过程决定。
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穿越技术。然而，为了获得合理的成功率，应该实现至少一种中继技术（例如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寻址，则客户端应使用其他技术，例如TURN-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
候选主机是最简单的候选主机，因为它们只需要打开主机接口上的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的媒体流（包括RTP等可以是UDP或TCP的媒体流），代理应该为主机具有的每个接口上的媒体流的每个组件获取两个候选主机（每个位于不同的端口上）——一个用于同时打开，另一个用于被动候选主机。如果一个代理不能以这些模式中的一种进行操作，它将忽略这些候选者。
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上创建适当的绑定（除非已经存在），并在主机之间发送连接检查，从而发现NAT为主机提供的地址。这些技术的成功取决于NAT的映射和过滤行为[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.
一个广泛使用的获取服务器自反候选的协议是STUN。[RFC5389]第7.2.2节描述了其TCP特定行为。
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.
这些候选者与服务器自反候选者一样编码在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]。此外，Middlebox Communications（MIDCOM）MIB[RFC5190]定义了一种基于简单网络管理协议（SNMP）的机制，用于控制NAT。
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隧道候选可以在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的支持，无论其过滤和映射行为如何。然而，使用中继有几个缺点，例如，它通常会导致分组的次优路径，中继需要存在并且需要被发现，中继可能是单点故障，中继可能会消耗中继服务器的大量资源，等等。因此，当无法使用其他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连接的中继协议包括TURN 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节所述的ICE不匹配检查），并确定代理角色。使用第5节中描述的技术收集候选人，并按照第4.2节中描述的优先顺序排列。考虑到第4.3节中的考虑因素，选择默认候选人。SDP答案的编码如[RFC5245]第4.3节所述，但TCP候选者除外，其编码如第4.5节所述。
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.
如果两个代理都使用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.
如果应答者接收到与候选对匹配的新要约，其中已与新要约并行创建了连接，则应答者必须接受该要约并响应该要约，同时保持已创建的连接。如果与新要约并行创建的连接与新要约中的候选对不匹配，则必须关闭连接，并执行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].
由于在两个代理都使用lite模式的情况下，连接端点未使用连接检查进行身份验证，除非使用了媒体级安全性（例如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一样，检查列表仅由完整的ICE实现形成。形成候选对时，以下类型的TCP候选可以相互配对：
Local Remote
Candidate Candidate
---------------------------
tcp-so tcp-so
tcp-active tcp-passive
tcp-passive tcp-active
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]中定义的垫片。STUN绑定请求和响应在此垫片上发送，因此RFC 4571中定义的长度字段位于每条STUN消息之前。如果将TLS或DTLS-SRTP用于媒体会话，TLS或DTLS-SRTP握手也将在该垫片的顶部进行。然而，它们只在冰处理完成后才开始。本质上，TLS或DTLS-SRTP握手被视为媒体协议的一部分。作为ICE程序的一部分，决不在TLS或DTLS-SRTP会话中运行STUN。
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连接，则认为检查失败，并且完整模式代理必须在检查列表中将对状态更新为failed。有关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候选程序的过程相同。然而，不需要重新传输STUN连接检查消息，因为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.
消息，远程候选地址显然不是对等点的地址之一，代理应该关闭连接，并考虑所有与远程候选人配对失败。
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代理（full或lite）必须准备好接收基于任何同时打开或被动的TCP候选的传入TCP连接请求。当收到连接请求时，代理必须接受它。在该连接的生命周期内，代理必须使用RFC 4571[RFC4571]中定义的帧。由于该帧，代理将接收离散帧中的数据。每个帧可以是媒体（如RTP或SRTP）、TLS、DTL或STUN数据包。按照第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处理完成时，每个代理都应关闭所有TCP连接（由于ICE会话而打开的连接），ICE选择的候选对之间的连接除外。
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.
在连接检查成功后，当控制端点生成更新的报价时，将使用面向连接媒体的SDP扩展[RFC4145]来表示应使用现有连接，而不是打开新连接。
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的媒体流，代理将该媒体流视为字节流，并假设它有自己的某种帧（如果需要）。然后，它从字节流中获取任意数量的字节，并将其作为有效负载放入RFC4571帧中，包括长度。接下来，发送方根据[RFC5389]第6节和第8节中的规则检查生成的字节集是否会被视为STUN数据包。这包括检查最重要的两位、魔法cookie、长度和指纹。如果根据这些规则，字节将被视为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帧的有效负载，并根据ICE中的过程确定它是STUN还是应用层数据[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:
ICE打开TCP或TCP/TLS连接以进行连接检查后，其生命周期取决于其使用方式。如果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.
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的帧。如果代理打开了连接并且是完整代理，则必须发送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服务器的连接以收集中继候选，则如果ICE选择了TURN服务器的中继候选，则客户端必须在媒体会话期间保持该连接打开。否则，在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
如果尽管客户端做出了努力，但在媒体会话的生命周期内，使用该服务器分配的传输地址与TURN服务器的TCP连接失败，则客户端应重新连接到TURN服务器，获得新的分配，并重新启动该媒体的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事务。如果两个参与者都不知道在与ICE一起使用的集合协议（如SIP[RFC3261]）中交换的共享秘密，则无法完成此事务。这个共享秘密反过来又受到协议交换的保护。对于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.
[RFC5245]第18.5.2节描述了眩晕放大攻击。同样的考虑也适用于TCP，但由于在执行任何检查之前需要建立TCP连接，因此TCP的放大效应更大。因此，一个ICE代理在同一个对等方与同一IP地址的TCP连接尝试不应超过5次。
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模式，则不发送连接检查，并且需要其他过程（例如，媒体级安全性）来验证连接。如果其中一台主机位于NAT后面并且具有来自专用地址空间的地址，则缺乏连接检查的问题尤其严重：对等机可能会意外地连接到使用相同专用地址空间的不同子网中的主机。这就是为什么lite模式不适合位于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.
[RFC5245]中描述了对不同攻击以及ICE防止这些攻击的各种方式的更详细分析。这些注意事项适用于本规范。
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
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.
作者感谢Tim Moore、Saikat Guha、Francois Audet、Roni Even、Simon Perreault、Alfred Heggestad、Hadriel Kaplan、Jonathan Lennox、Fleming Andreasen、Dan Wing和Vijay Gurbani对本文件的评论和投入。特别感谢Marc Petit Huguein提供SDP示例。
[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：会话启动协议”，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，“安全实时传输协议（SRTP）”，RFC 37112004年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 41452005年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.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年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，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，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]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用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]Guha，S.和P.Francis，“通过NAT和防火墙的TCP穿越的特征和测量”，第五届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]柴郡，S.，克罗奇马尔，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]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协议版本5”，RFC 19281996年3月。
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089]北村，H.，“基于SOCKS的IPv6/IPv4网关机制”，RFC3089，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，“领域特定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：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006.
[RFC4540]Stieemerling，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，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008.
[RFC5190]Quitek，J.，Stieemering，M.，和P.Srisuresh，“用于中间箱通信的托管对象的定义”，RFC 51902008年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（TURN）扩展使用中继进行遍历”，RFC 6062，2010年11月。
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[RFC6081]Thaler，D.，“Teredo扩展”，RFC 60812011年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（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.，Iyer，P.，Pennerath，F.，Marynissen，G.，Schmitz，M.，Siddiqi，W.，和M.Blaszczak，“互联网网关设备（IGD）标准化设备控制协议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相比，通常情况下，如果两台主机都在NAT后面，ICE TCP在启用无中继连接时的成功概率较低。这是因为当前部署的许多NAT具有端点依赖的映射行为，或者它们不支持在TCP同时打开的情况下看到的TCP握手数据包流，例如。，某些NAT不允许从SYN数据包最近已发送到的地址或后续SYN-ACK未正确处理的地址传入TCP SYN数据包。
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]中已报告，在测量时（2005年）部署的NAT数量中，此处描述的NAT穿越技术之一，TCP同步开放，在大约45%的情况下有效。此外，并非所有操作系统都正确地实现了TCP同步打开，因此无法使用这些候选者。然而，当更多的NAT符合[RFC5382]设置的要求并且操作系统TCP堆栈固定时，同时打开的成功概率可能会增加。此外，实施具有更高成功率的其他技术也很重要，例如Teredo，其在不同场景中的成功在[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中，TCP连接的实现非常重要。
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服务器以获取服务器自反候选，到TURN服务器以获取中继候选，或到对等方以作为连接检查的一部分），并准备好接收传入的TCP连接（对于被动和同时打开的候选连接）。“典型”BSD插座用于启动或接收连接，而不是同时用于两者。允许在同一本地IP和端口上进行传入和传出连接所需的代码不明显。Saikat Guha提供的以下伪代码在许多平台上都可以工作：
for i in 0 to MAX sock_i = socket() set(sock_i, SO_REUSEADDR) bind(sock_i, local)
对于0中的i到最大sock\u i=socket（）集（sock\u i，SO\u REUSEADDR）绑定（sock\u i，本地）
listen(sock_0) connect(sock_1, stun) connect(sock_2, remote_a) connect(sock_3, remote_b)
监听（sock_0）连接（sock_1，眩晕）连接（sock_2，远程_a）连接（sock_3，远程_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.
这里的关键是，在listen（）调用之前，必须将需要用于传出连接的全套套接字分配并绑定到本地IP地址和端口。此数字MAX表示可能需要从同一本地候选者建立到不同目的地的最大TCP连接数。对于同时开放的候选对象，这个数字可能会很大。如果请求分叉，ICE过程可能与多个对等方一起进行。此外，对于每个对等点，需要为同一组件的每个被动或同时打开的候选节点建立连接。如果我们假设一个最坏的情况是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提供和应答的两个示例。这两个示例都基于[RFC5245]中图8的简化拓扑，具有相同的IP地址。此处显示的示例应被视为具有严格的信息性。
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
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
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):
在第二个示例中，UDP和TCP媒体流是混合的，但是由于主机不支持TCP同时打开，因此省略了S-O候选，并且通过将TCP候选类型首选项减少1，首选UDP候选（但候选类型的首选项顺序保持不变）（即，主机候选使用类型首选项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
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
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
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
EMail: ari.keranen@ericsson.com
Bruce B. Lowekamp Skype
布鲁斯·B·洛坎普·Skype
EMail: bbl@lowekamp.net
EMail: bbl@lowekamp.net
Adam Roach Tekelec 17210 Campbell Rd., Suite 250 Dallas, TX 75252 US
美国德克萨斯州达拉斯坎贝尔路17210号Adam Roach Tekelec，250室，邮编75252
EMail: adam@nostrum.com
EMail: adam@nostrum.com