rfc5245--概要翻译

http://blog.csdn.net/spivic/article/details/20999455

前言:

rfc5245介绍了 NAT下p2p的解决框架ICE（Interactive Connectivity Establishment）

此文档取代了过时的rfc4091, rfc4092 

rfc6336上有rfc5245的更新

很多次关键的不翻译了

对此rfc的翻译正确性不做任何保证。按照它而导致的任何问题后果自负。转载请注明原地址。

1-介绍

rfc3264介绍通过SDP传输媒体会话信息，它的机制(offer/answer)由sip提供

offer/answer在NAT环境下实现困难。原因offer/answer是为了建立媒体流的直接传输(译注:p2p)，而NAT下p2p是有困难的。

有很多其他机制解决这样的问题（如ALGS，Middlebox Control Protocol,STUN等)，但这些方案对网络拓扑适应性差。我们要个一揽子解决方案。

ICE解决了UDP下的媒体流跨NATp2p问题(ICE可以扩展以用于TCP)。ICE是个扩展的offer/answer,在SDP的offer/answer中增加多个用于p2p连接检查的IP:port对（就像STUN）。ICE还用到了TURN。ICE可用于多宿主和双栈主机。

2--概要

下面是大体拓扑图

ICE的思路:每个Agent有很多候选的传输层地址（即UDP的IP:port对）（下面称候选地址）,它可以用来和别的agent通信。这些地址包括:

直接相连的地址（A transport address on a directly attached network interface）

NAT外网的转义地址(服务自反地址)（A translated transport address on the public side of a NAT (a  "server reflexive" address)）

TURN分配的地址(中继地址)（A transport address allocated from a TURN server (a "relayed  address")）

上图的L候选地址理论上都可以用来和R的候选地址通信，但事实不行。ICE通过系统的判断判断什么候选地址可以用。

2.1收集候选地址

为了运行ICE，必须找出agent的候选地址。其中一个候选地址就是直连地址。

如果agent是多宿主主机,它的候选包括多个地址。根据对端的地址，本机可以通过一或多个候选地址和对端通信。例：一个agent在私有网络I1上有个候选地址，在公有网络I2上有个候选地址。agent可以通过I1上的候选地址和I1上的对端通信，I2上的候选地址可以和公网上的对端通信。(ICE)不猜哪个地址优先，而是提供两个候选地址。

接下去，agent通过stun或turn获得额外的候选地址。这包含2类:NAT外网的转义地址,TURN分配的地址。这2类地址都由TURN服务器发现，而不是分别从STUN/TURN获取（当只有STUN运行时，只能从STUN获得NAT外网的转义地址）。两类地址的关系见下图。

当agent从主机候选地址X:x向TURN发Allocate 请求,NAT会创造服务自反地址X1:x1,发向X1:x1的包会转成主机候选地址X:x发给agent。我们称和服务自反地址相关的主机候选地址BASE。

如果agent和TURN中有多个NAT，只有最外层的服务自反地址能被agent发现。如果没有NAT,服务自反地址会和主机候选地址相同（最后因为冗余而从候选地址中删除）

当Allocate请求到达TURN,TURN服务器在自己的IP Y上分配个端口y,然后发回Allocate响应，通知agent这个中继地址。同时TURN服务器也通过把Allocate 请求的传输层地址复制到Allocate响应中来告知agent 服务自反地址X1:x1。TURN（在NAT中）的原理实际是扮演个中继，R为了发给L消息，R先发到Y:y,TURN把它转发到X1:x1，然后NAT映射到X:x后发给L。

如果只存在STUN（rfc5389）,agent只发送STUN Binding请求道STUN服务器，STUN服务器靠把Binding请求的传输层地址复制到Binding响应中来告知agent 服务自反地址。

2.2连通性测试

当L获得了它全部的候选地址，把它们按优先级从高到低排序后通过信令通道（SDP offer）发送给R。R收到后做同样的事，然后通过响应发给L。最后，每个agent都拥有了自己和对方的候选地址。它们共同组成CANDIDATE  PAIRS(候选地址对)。client通过CANDIDATE  PAIRS发送给对端STUN request来检查它们。

原则如下：

根据优先级对候选地址对排序

根据优先级向对候选地址发送request

确认对端的响应

由于双方都进行检查，所以结果就是四次握手：

重要的是STUN request从未来媒体流(如RTP RCTP)将使用的地址发送接收。所以要从这里解复用（译注：就是个双工器）STUN和媒体流,这很容易。

如果在连通性测试中stun响应中的服务自反地址和已知的候选地址不同，这个候选地址叫PEER REFLEXIVE CANDIDATE（对端反身候选地址），它也会像其他候选地址一样被ICE测试。

一旦R收到L的测试（request）,R马上发起对L的测试。这个可以提高测试速度。它叫做TRIGGERED CHECK（触发测试）

测试结束后L和R都知道双方p2p的收发地址。

2.3. 候选排序

由于算法搜索所有的候选对，所以不管候选地址是按什么顺序加入的，可用对（working pair）如果有的话，肯定能发现。为了更快更好的搜索，我们用了特殊算法对候选排序。排序后的候选对结果列表叫做检查表(CHECK LIST)。4.1.2介绍了算法，在这里先介绍下思路：

1每个agent给出自己候选地址的数字优先级，然后连候选地址一起发给对端。

2远程和本地的优先级混合，这样每个agent的候选对顺序是一样的。

当L和R在NAT后面时，思路2很重要。因为通常外网不许向NAT内网发数据，除非内网agent向外网发数据。所以ICE直到各agent从各自的NAT后发送check，都没法成功检测。

agent通过定期为列表中下个候选对发送STUN request来完成检测。这过程叫普通检测（ ORDINARY CHECKS）。

总之，相同类型的候选对获得相似的优先级，更多直连路径的优先级高于非直连。按照上面的原则，agnet在调整算法时有很多自由度。

2.4. 冻结候选

上面只描述了agent希望为一个媒体会话获得一个组件（COMPONENT）的情况。然而媒体流中每一块要一个传输层地址，所以一个媒体流要多个组件。比如RTP和RCTP。

每个组件的网络状况类似（比如RTP和RCTP的IP地址是相同的）。因此常常可以通过一个组件获得另个组件的最佳候选地址。ICE靠"冻结候选"机制实现它。

每个候选地址有个关联属性"基础"(FOUNDATION)。当两个候选地址类似（类型相同、主机地址相同、STUN服务器协议相同）时基础是一样的。候选地址对也有"基础"，它由相关的两个候选地址的"基础"组成。开始，只有独立"基础"的候选对被测试，其他（重复"基础"）的候选对只有在刚才候选对检查成功时再检查（先被“冻结”了）。这样避免了检查那些看上去会成功但实际失败的候选对。

尽管我们单独讨论了“冻结”，但实际上这是作为ICE候选排序的一部分。

2.5检查的安全性

为避免媒体流被劫持到别的地址,STUN的连接测试中夹带消息认证码(MAC)（密钥交换在信令中）。MAC确保消息正确和来源可靠。进一步，如果SIP使用ICE,而且分叉了，ICE在每个分叉上的交互是独立的。信令上的密钥交互帮助了ICE和各接收者的信息交互。

2.6ICE结束

ICE根据候选对的优先级来检查。一种实现方法是当一个候选对检查成功时便宣布胜利。的确这是个合理的算法。但是，一旦丢包，一个高优先级的检查可能会花更多时间。所以让ICE多运行会会比较好。更本质的问题是，上面的优先级高的也许不是最优解。可以用往返时间RTT来证明。

所以ICE叫一个agent控制端，另个被控端。控制端决定用什么候选地址。有两种实现方法：经常提名或进取型提名( REGULAR NOMINATION or AGGRESSIVE NOMINATION)。

经常提名时，控制端一直检查，直到至少发现一个有效候选对。然后控制端选一个未提名的候选对，在上面发送第二个STUN Request，不过在这请求上打上个标记告诉对方这个对被提名了。如下所示：

 L                        R
   -                        -
   STUN request ->             \  L's
             <- STUN response  /  check

              <- STUN request  \  R's
   STUN response ->            /  check

   STUN request + flag ->      \  L's
             <- STUN response  /  check

                       Figure 4: Regular Nomination

当最后打标记的STUN事物完成了，双方都取消对此地址对的检测，然后就用它传媒体流。这个地址对叫选择对（SELECTED PAIR）。

进取型提名时，控制端在每个STUN request上打上flag。这意味着一旦第一个检查成功，ICE流程结束。选择的对也就是最高优先级的。进取型提名更快但灵活性弱。

L                        R
   -                        -
   STUN request + flag ->      \  L's
             <- STUN response  /  check

              <- STUN request  \  R's
   STUN response ->            /  check

                      Figure 5: Aggressive Nomination

当媒体流建立时，如果媒体流中的候选地址(m行和c行)（默认地址）和ICE的选择对不同时，控制端发送更新请求。

当ICE结束时，双方都通过发更新请求来重启。

2.7简易实现

为了用ICE,所有agent必须要支持它。然而有些agent在公网上。为了这些agent，ICE定义了简易实现。简易实现不收集候选地址，它只包括主机地址。简易agent不发出连接检查，但会对连接检查做响应。当简易实现和完全实现互联时，完全实现做控制端，另个做被控端。两个简易实现互联时，没有事发生。

附录A表示什么时候简易实现是恰当的。

简易实现只是个过度，如果可能最好都完全实现。

3术语

(略)

4发送初始offer

为了能在offer/answer交互中发初始offer,一个agent必须1收集候选地址2排序3删除重复4选择默认候选5制定并发送SDP。

4.1完整实现所需要的

4.1.1收集候选

一个agent在即将通信前做这件事。它可以由用户接口触发或者在会话初始中明确要求。所有候选是个传输层地址。候选还包括类型和BASE。类型有四种:主机地址，服务器自反地址，对端自反地址，中继地址。服务器自反地址由STUN或TURN获取，中继地址由TURN获取。对端自反地址在ICE连接性检测的阶段获取。BASE是agent发送数据时必须用的候选地址（译注？）。

4.1.1.1主机候选地址

主机地址由在IP上绑定端口获得。

agent要为每个媒体流组件获得候选地址。每个IP上的主机候选地址总和组件相绑定（译注：看例子）。每个组件有个组件ID，例如如RTP媒体流，RTP组件ID1,RCTP组件ID2。如果agent用RCTP，它必须为RCTP收集候选地址。如果agent用RTP+RCTP，最终会有2*K个主机候选地址，其中K是agent的IP数量。每个主机候选地址的BASE是它自己。

4.1.1.2服务自反候选地址和中继候选地址

agent应该能获得服务器自反地址和中继地址。这个具体取决于网络。比如纯内网环境下的多栈主机（多IP）,只要获取它的主机地址就足够了，ICE只是用来选择用什么主机地址。

TURN的使用代价高昂，只有双终端在对称型NAT后才用。所以有些时候就不用TURN了。所以建议当agent不需要收集服务器自反地址和中继地址时，可以关闭这功能，需要时再打开。

当收集服务器自反地址和中继地址时用TURN服务器，只收集服务器自反地址时用STUN服务器。

agnet通过配置或DNS来确定TURN/STUN服务器的位置。建议用DNS。rfc5389描述DNS找STUN服务器,rfc5766描述DNS找TURN服务器。

上面只讲了单STUN和单TURN。如果有多个STUN或TURNserver，从同一个Server来获取候选地址。（多Server）的结果是有多个从Server传来的主机地址。agent选择一个，从上面向Server发送Binding or  Allocate。绑定是没有验证的，备用服务器发回的响应也需忽略。agent必须为Binding请求实现rfc5389中的向后兼容模式。Allocate请求需要通过其他长期的验证方式验证。

Ta微秒后,agent能发起新的STUN/TURN事物。新事物可以是可恢复性故障的重试（如认证错误），或是为新的主机候选地址--Server对发起。agent发送频率不应该超过Ta，详细见16章如何设置Ta和STUN重传超时RTO

Agent会收到Binding or  Allocate响应。成功的Allocate响应使agent获得了服务器自反地址(包含在映射地址中)，和中继地址（在XOR-RELAYED-ADDRESS属性中)。如果服务器由于缺乏资源而拒绝了Allocate请求,agent应该发Binding请求,来获得服务器自反地址。Binding响应会给agent提供唯一一个服务器自反地址(包含在映射地址中)。服务器自反地址的BASE是Binding or  Allocate发送的主机候选地址。中继地址的BASE是它自己。如果中继地址和主机候选地址相同，这个中继被忽略。

4.1.1.3计算"基础"

最后，agent给每个候选地址分配个"基础(Foundations)",它在一个会话中有效。两个候选地址在如下的情况下的“Foundations”必须一致：

1类型一致（主机、中继、服务器自反、对端自反）

2BASE的IP相同（端口可以不一样）

3获取自反和中继地址的STUN和TURN服务器IP必须一样。

4传输层协议相同（TCP/UDP）

如果上述条件有一条不满足，Foundations必须不同。

4.1.1.4保持候选有效

中继、服务器自反地址在ICE流程结束前必须保持有效（见8.3）。从Binding Request中获得的服务器自反地址还需要通过向服务器发额外的Binding Request来保持有效。更新(Refresh)通过更新事物来完成(rfc5766)，Refresh请求也会刷新服务器自反地址。

4.1.2候选优先级计算

媒体流的候选地址的优先级必须是唯一的，范围1-2^31-1。优先级将用来决定连接检测的顺序和候选地址的选择。

Agent应该用4.1.2.1节的方法计算优先级。并按4.1.2.2的原则选择计算参数。如果一个agent不用这个算法，双方会不协调而导致ICE完成时间变长。

4.1.2.1推荐方法

方法：Agent对各类型的候选地址设定偏好值，并且当agent是多IP的，为不同IP设置偏好值（译注：本地偏好）。然后两个偏好值混合起来计算候选地址的优先级。计算公式如下：

 

   priority =(2^24)*(type preference) +

             (2^8)*(local preference) +

             (2^0)*(256 - component ID)

类型偏好范围[0-126] 的整数,126最高0最低。相同类型候选的类型偏好值必须一样，不同类型候选的类型偏好值必须不同。对端自反地址偏好值必须高于服务器自反地址。注意通过4.1.1的过程后不可能获得对端自反地址；它通过ICE的连接检查获取。

本地偏好必须是[0-65535]的整数。65535最高。当只有一个IP，本地偏好应该被设置为65535。更一般的来说，一个媒体组件有多个类型相同的候选地址，每个候选地址的本地偏好必须唯一。这个只发生在多IP主机。如果是因为双栈（IPv6 +IPV4）原因导致的多IP(rfc3484)，本地偏好应该一样。

组件ID范围[0-256]

4.1.2.2选择类型和本地偏好的原则

选择标准之一是媒体中继,如TURN，VPN，NAT的用法。如果媒体流发到那些候选地址，它在到达目的前会在中继中转。一类需要媒体中继的候选地址是中继地址（译注:TURN）。另类是从VPN获得的主机地址。使用媒体中继的成本高。建议优先级:主机候选地址126，服务器自反地址100,对端自反地址110，0中继地址0。如果是多IP主机，从VPN获得的地址的本地偏好（local preference）应该设为0

选择标准之二是IP的类型。(RFC3056)在双栈（IPv4+IpV6）主机上，优先选择IPv6，Ipv6失败选择Ipv4。这时IpV6的本地偏好优先值高，6转4地址优先级次之，4地址最低。

选择标准之三是安全性。比如用户通过VPN网络和内部客户相连，而和外网直接连通，用户希望和内部用户通话时优先选择VPN，这时VPN地址的本地优先级要提高。

选择标准之四是网络拓扑发现。在有中继时很有用当一个agent有个预先配置/动态发现的中继。这个候选地址的本地偏好值可以调高。

4.1.3删除冗余地址

冗余地址是指传输层地址相同且BASE相同的候选地址。通常一个设备不在NAT后的话服务器自反地址和主机地址是冗余的。Agent应该删除低优先级的冗余地址

4.1.4选择默认候选

和不支持ICE对端通信的目的候选地址叫做默认候选；它也叫默认目标。如果和支持ICE的对端交互时没有选择默认候选，需要在ICE完成后需要一个update offer/answer，用来”修复”SDP来让默认候选和ICE选择的候选地址相同。

Agent必须为每个在使用的媒体流选个默认地址。在使用的媒体流没有0端口（rfc3264 用来拒绝媒体流）。甚至当如果媒体流a=inactive(RFC 4566)或者bandwidth值0时表明媒体流在使用。

建议根据对端连接的可能性来选择默认候选。建议默认候选顺序：中继地址，服务器自反地址，主机候选地址

4.2简易实现需要的