1. Introduction（介绍）
RFC3264[4]基于为多媒体会话建立连接的目的，定义一个两阶段交互的SDP消息。请求/应答机制在SIP[3]等协议中也得到应用。
使用请求/应答机制的协议难于通过NAT。因为它们的目的是建立一个媒体包的流程，它们往往是通过它们的消息携带IP地址，而这对于通过NAT[4]是存在问题的。协议还探索在两个参与者之间创建一个直接流程，所以，在它们之间不存在应用层仲裁者。这样就降低了媒体时延，减少包丢失，并减少运行开销。但是，这对于穿越NAT来说是很困难的。一个完全的解决这个问题的方法将在本规范中给出。
提出了众多解决方案来允许这些协议操作通过NAT，它们包括ALGs(Application Layer Gateways)、Middlebox Control Protocol[15]、STUN (Simple Traversal of UDP through NAT[13])、TURN(Traversal Using Relay NAT)、RSIP(Realm Specific IP[17][18])、symmetric RTP等。不幸的是，这些技术在用于某些网络拓扑结构是都有某些利与弊。以至于我们只能根据不同的接入方式来应用不同的方案，所以未能很好地解决All-NAT与Efficiency的问题，同时还会给系统引入了许多复杂性和脆弱性因素。所以我们目前需要一种综合的足够灵活的方法，使之能在各种情况下对NAT/FW的信令穿透问题提供最优解。
本规范提供一个用于通过基于请求/应答模型的信令协议为媒体流建立连接的解决方案。称为Interactive Connectivity Establishment或ICE。ICE使用STUN和它的中继器扩展，通常所说的TURN，但是只是通过一些特殊的方法使用它们，这样避免只使用某一个所存在的缺陷。
2. Overview of ICE（ICE概述）
在典型的ICE配置中，有两个想要通信的终端（即RFC3264中的术语Agent）。它们不能通过SIP之类的信令协议直接通信，通过SIP协议可以执行请求/应答交互SDP消息。注意，ICE不是打算为SIP穿越NAT，SIP穿越NAT假定已经通过其他机制[31]实现了。在ICE处理的开始，Agent忽略它们自己的拓扑结构。尤其，它们可能在或者不在NAT之后（或者多层NATs）。ICE允许Agent发现足够的关于它自己的拓扑结构的信息，用于找到一条路径或者通过该路径通信。
图1显示了典型的ICE配置环境。两个终端标识为L和R。L和R都位于NATs之后——可是之前提到，他们彼此不知。NAT的类型和性质也不知道。Agent L和R能够通过传输SDP消息的请求/应答交互中结合，这种交互是为了为L和R之间建立一条媒体会话。典型的这种交互会通过SIP服务器发生。
在网络中，除Agent之外，一个SIP服务器和NATs，还有STUN服务器都被ICE使用。每个Agent可以有自己的STUN服务器，也可以共用一个。
+-------+
| SIP |
+-------+ | Srvr | +-- -- -- -+
| STUN | | | | STUN |
| Srvr | +-------+ | Srvr |
| | / \ | |
+------- + / \ +-- -- -- -+
/ / / / / <- Signalling -> / / +--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ / / +-------+ +-------+
| Agent | | Agent |
| L | | R |
| | | |
+--- ----+ +------- +
Figure 1
ICE的基本思想是：每个Agent都有一些可以用于与其他Agent通信的候选的传输地址。这些可能包括：
l 直接依附于网络接口（或者多初始地址主机的那些接口）的地址。
l 位于公网的经过NAT转换的地址（服务器反向地址）。
l Agent使用的媒体中继地址。
可能任何一个L的候选的地址能够用来与R的任何一个候选地址通信。实际上，一些组合是不能正常工作的。例如，如果L和R都位于NAT之后，他们的直接地接口地址就不能直接通信（这正是为什么需要ICE的原因）。ICE的目的就是发现一些可以正常工作的地址组合。ICE实现这些的途径是系统的尝试所有可能的组合（这些组合被合理的排序），直到找到一个或多个可以工作的组合。
2.1. Gathering Candidate Addresses（收集候选的传输地址）
为了实施ICE方案，Agent必须要确定所有的候选传输地址。自然而然地，一个可行的候选传输地址是直接从本地接口(interface)获取的指向网络的客户端地址。这个候选传输地址称为候选主机。这个本地接口可以是一个位于两层网络技术之上的接口，如：ethernet、WiFi，或者可以通过隧道机制获取，如VPN，或者是移动IP（MIP）。总之，作为代理的本地接口的这些端口(候选传输地址)必须是可被分配的。
如果代理是多重初始地址的，候选传输地址可以从各个接口获取。依赖于代理端通信的对方在网际中的位置，代理端可能经由这些接口中的一个或多个可达通信的对方。例如，一个代理拥有一个本地接口指向私网net 10，并且可通公网。一个来自net 10接口的候选传输地址当与位于同一私网net10的伙伴通信时，可通过net 10接口直接可达，虽然当与位于公网的对方通信时，来自公网接口的候选传输地址能直接可达。较于试图猜测哪个接口先发送请求，请求代理在发送请求时包括所有的候选传输地址。
一旦代理端获取了主机候选传输地址，它将使用STUN获取额外的候选传输地址。这些候选传输地址来自两种方式，一是通过NAT方式转换的外部地址，另一种是媒体中继地址。候选主机通过两种方式获取的候选传输地址的关系如图2，两种类型都是通过STUN发现的。
To Internet
|
|
| /------------ Relayed
| / Candidate
+--------+
| |
| STUN |
| Server |
| |
+--------+
|
|
| /------------ Server
|/ Reflexive
+------------+ Candidate
| NAT |
+------------+
|
| /------------ Host
|/ Candidate
+--------+
| |
| Agent |
| |
+--------+
Figure 2
为了找到服务器反向候选地址，Agent通过每一个主机候选传输地址，使用绑定发现用法（Binding Discovery Usage [11]）发送一个STUN绑定请求给STUN服务器（STUN server）（假定STUN服务器的地址已经被配置或者可以通过某种途径被学习到）。当Agent发送绑定请求，NAT将分配一个绑定，映射这个服务器反向候选地址到主机候选传输地址。通过主机候选传输地址发送的外发包，将通过NAT转换为通过服务器反向候选地址发送的包，而发往服务器反向候选传输地址的包，将被NAT转换为发往该主机候选传输地址，并且转发给Agent。我们称关联了一个特定的服务器反向候选地址的主机候选地址为BASE。
注意：
“BASE”指的是特定的发送的源候选传输地址。因而，作为一种简化的主机候选传输地址，同样拥有一个base，但是它与主机候选传输地址相同。
当在Agent与STUN服务器之间存在多种NAT，那么STUN请求将会为每一种NAT创建一个绑定，但是只有最外部的服务器反向候选传输地址（server reflexive candidate）会被Agent发现。如果Agent不在NAT之后，那么，基候选传输地址将会与服务器反向候选传输地址（server reflexive candidate）相同，服务器反向候选传输地址（server reflexive candidate）可以被忽略。
最后一种候选地址是中继候选传输地址。STUN中继用法（STUN Relay Usage [12]）允许STUN服务器作为一个媒体中继器进行工作，在L与R之间进行转发。为了发送消息到L，R必须发送消息给媒体中继器，通过媒体中继器转发给L。反之亦然。
从L到R的消息其地址信息将两次被重写：第一次被NAT，第二次被STUN中继服务器。这样，R所了解的想与之通信的地址就是STUN中继服务器的地址。这个地址是最后一种候选传输地址，称之为中继的候选传输地址（RELAYED CANDIDATE）。
2.2. Connectivity Checks（连通性检查）
一旦L收集到所有的候选传输地址，就将它们按优先级高低进行排序，然后通过信令信道发送给R。这些候选传输地址作为SDP请求的属性被传输。当R收到请求，它执行相同的收集过程，并且把它自己的候选传输地址作为响应消息发给请求者。这样，每个Agent都将有一个完整的包含了双方候选传输地址的列表，然后准备执行连通性检查（通过配对这些候选传输地址看那一对可以正常工作）。
连通性检查的基本原则很简单：
1. 按照优先顺序对候选传输地址进行排序
2. 利用每一个候选传输地址对发送一个检查包
3. 从另一个Agent收到肯定应答检查
针对每一对候选传输地址对，一个完整的连通性检查包含四次握手：
A B
- -
STUN request -> \ A's
<- STUN response / check
<- STUN request \ B's
STUN response -> / check
Figure 3
作为一个优化，B一旦收到A的检查消息就立即使用相同的候选传输地址对发送它的检查消息给A。这样就加速了发现有效候选传输地址的处理过程。
在这次握手的最后，A和B都知道它们可以在两个方向上发送（接收）端到端的消息。注意，B一收到A的STUN响应就知道B->A路径正常工作，并且可以立即开始经由该路径发送媒体（如下所示）。这考虑及“早熟媒体”尽快地传输。
A B
- -
STUN request -> \ A's
<- STUN response / check
<- STUN request \ B's
STUN response -> / check
<- RTP Data
Figure 4
一旦任何一个候选传输地址对的指定媒体成分的连通性检查成功，ICE使用该候选传输地址并且立即放弃其它所有的为该媒体成分的连通性检查。注意，由于竞争环境和包丢失，这可能意味着“最好的”候选传输地址没有被选中，但是它保证这个选择是可用的，因为排序过程一般倾向于最合适的。
2.3. Sorting Candidates（候选传输地址排序）
因为上述算法收集到的是所有的候选地址对，如果有一个可以正常工作的组合存在，那么该组合最终将会被找到，无论这个候选传输地址的次序是怎样的。为了处理的更快（更好），候选传输地址按特定的顺序排序，算法将在Section 4.2描述，该算法基于如下两个原则。
o 每一个Agent给它的候选传输地址一个数值的优先级，这个优先级和该候选传输地址一起发送给通信的对方。
o 综合本地的和远程的优先级，所以每个Agent拥有相同的候选传输地址对顺序。
第二个特性对于当A与B之间存在NATs时，启动ICE进行工作有很重要的影响。常常，NATs不允许来自一个主机的数据包进入，除非在NAT后的Agent曾经发送一个数据包给该主机。因此，ICE每一个方向的检查将不会成功，除非双方均曾发送一个检查通过它们各自的NATs。
一般而言，设计一个优先算法，这样相似类型的候选地址会得到相似的优先级，并且相对于间接路由，直接路由更好。然而，在这些方针之中，Agent拥有一个很好的数量上的判断力，用于协调算法。
2.4. Frozen Candidates（冻结的候选传输地址）
先前的描述只是忙于Agent意图确定单纯的媒体成分，也就是，一个单纯的具有专一主机-端口的四元组流。然而，在很多情况（特别是RTP和RTCP）Agent实际上需要建立一个连接而不仅仅是一个流。
一个简单的解决这个问题的方式是对每一个媒体成分进行简单的独立的ICE交互。但这会明显的低效，因为，对于媒体流的各成分，其网络特性都很可能非常相似（尤其对于RTP和RTCP典型的使用相邻的端口）。因而，在一个媒体成分中应该有一个起杠杆作用的信息，用于决定最好的候选传输地址。ICE实现它的机制被称为“冻结候选地址”（frozen candidates）。
冻结的候选传输地址的一个基本的原则是在开始时，只是单一媒体成分的候选传输地址被测试。其它媒体成分标记成“冻结”。当第一个成分的连通性检查成功，对于其它成分的相应的候选传输地址被解冻并且立即检查。这避免重复检查那些表面很优，实际很可能会失败的成分。
尽管我们已经在这里为着说明性的目的，作为一个独立的机制描述了“冻结”，实际上，它是ICE的一个完整的部分，并且ICE优先算法自动保证恰当的候选传输地址以正确的顺序被解冻、检查。
2.5. Security for Checks（检查的安全性）
因为ICE用于发现哪个地址可以用来在两个Agent之间传输媒体，所以，保证处理不被劫持而发送媒体到错误的地方是很重要的。每一个STUN连通性检查必须为一个在信令信道中利用密钥交换的消息鉴定编码（message authentication code (MAC)）计算所保护。这个消息鉴定编码（MAC）提供完整而真实的消息和原始认证数据，从而阻止入侵者伪造或修改连通性检查消息。消息鉴定编码（MAC）还帮助消除ICE交流与派生呼叫的歧义。
