ICE实现Nat穿越方案设计说明书
Keywords 关键词：ICE，STUN，TURN，RtpP，VPS，SIP，SDP，RTP/RTCP，NAT，候选地址
Abstract 摘要：本文描述基于ICE方式实现NAT穿越方案设计，主要介绍了4种NAT类型、ICE算法及结合现有实际环境实现NAT穿越的可行性及工作的主要流程，用于指导后续方案实施及详细概要设计工作。
List of abbreviations 缩略语清单：
Table 1 缩略语列表
|
名词 |
英文解释 |
中文解释 |
|
ICE |
Interactive Connectivity Establishment |
交互式连通建立方式 |
|
STUN |
Simple Traversal of UDP through NAT |
简单的用UDP穿透NAT |
|
TURN |
Traversal Using Relay NAT |
通过Relay方式穿越NAT |
|
RTPP |
Rtpproxy server |
RTP媒体转发服务器 |
|
VPS |
Sipproxy server |
SIP信令代理服务器 |
|
SIP |
Session Initiation Protocol |
会话初始控制协议 |
|
SDP |
Session Description Protocol |
会话描述协议 |
|
RTP/RTCP |
Real-time Transport Protocol/RTP Control Protocol |
实时传输协议/RTP 控制协议 |
|
NAT |
Network Address Translation |
网络地址转换 |
我司现有服务器网络架构对NAT穿越采用的是RTPP媒体中转方式(Application Layer Gateway简称ALG解决方案)，所有呼叫媒体都必须经由RTPP中转服务器进行转发，因此对RTPP转发性能及宽带需求很高，同时在手机等复杂环境下，由于中转导致延迟丢包率加大，影响用户的正常呼叫体验，也成为后续视频功能的一个颈瓶，因此急需一种能够很好提供负载均衡的解决方案。
1.2ICE方案设计目的结合我司实际运营情况及P2P(Peer to Peer)技术发展，本文提出基于ICE方式实现NAT穿越完成P2P通讯的设计方案，描述结合我司现有网络架构上使用ICE算法实现NAT穿越可行性及优势。ICE算法是针对现有NAT类型寻找最优化通讯路径，最大可能的实行P2P媒体流通讯，从而降低了由于中转导致延迟丢包和对RTPP中转服务器性能需求，实现负载均衡。
2ICE实现NAT穿越方案2.1现有NAT类型1. Full Cone （完全开放型）：来自相同的内部地址的请求消息映射为相同的外部地址， 与外部地址(目的地址)无关。映射关系为P:p↔A:b，任何外部主机可通过(A:b) 发送到数据到(P:p)上。
2. Restricted Cone（地址受限型）：来自相同的内部地址的请求消息映射为相同的外部地 址，返回的数据只接受该内部节点曾发数据的那个目的计算机地址X。映射关系为 P:p↔A:b↔X，只有来自X的数据包才可通过(A:b)发送到数据到(P:p)上。
3. Port Restricted Cone(端口受限型)：来自相同的内部地址的请求消息映射为相同的外 部地址，返回的数据只接受该内部节点曾发数据的那个目的地址X:x。映射关系为 P:p↔A:b↔X:x，只有来自X:x的数据包才可通过(A:b)发送到数据到(P:p)上。
4. Symmetric(对称型) NAT：只有来自相同的内部地址(P:p)，并且发送到同一个地址(X:x) 的请求消息，才被映射为相同的外部地址(A:b)，返回的数据只接受该内部节点曾发数 据的那个目的地址X:x。映射关系为P:p↔A:b↔X:x，当(P:p)访问(Y:y)时，映射为 P:p↔B:c↔Y:y。
NAT给P2P带来的问题是：NAT只允许单方面发起连接，通讯的双方不是平等的，具体 的表现为：
（1）内网主机IP是私有的，外部主机看不到，也无法主动发起连接；
（2）即使知道了内网IP，但NAT会丢弃没有在映射表的数据包；
（3）内网主机可以作为客户端访问外网，但不能作为服务器提供服务；
（4）当两个主机都位于各自的NAT之后，要实现P2P的连接，就不仅是谁主动的 问题，而是如何解决在两个NAT上同时有对方映射表项的问题。
2.2基本组成1.呼叫发起/接受终端(会话参与者)
呼叫发起方和接收方是交互的实体，呼叫发起方负责SIP通信并等待接收方应答，接 收方被动接受SIP（Session Initiation Protocol，信令控制协议）请求，并根据实 际情况选择接受或者拒绝，并发送回相应的响应码。
2.VPS控制服务器(SIP信令代理服务器)
整个SIP应用过程需要一个控制服务器，它负责用户的注册、登录、管理和SIP信令的中转，并且负责传递控制信息；功能上讲，控制服务器起到注册服务器和信令中继功能。
3.STUN服务器(VPS STUN服务器)
STUN（Simple Traversal of UDP over NATs）是指NAT 的UDP简单穿越；实际运用中配合完成NAT类型检查及连通性验证,并提供3个扩展属性:USE-CANDIDATE, ICE-CONTROLLED 和ICE-CONTROLLING。
4.RTPP服务器
RTPP服务器为媒体中转服务器，当呼叫双方都处于Symmetric NAT(对称型NAT)后面 时，则媒体流经由RTPP服务器中转完成NAT穿越。
ICE是通过一系列的尝试来决定最佳NAT的穿越路径方式，最佳路径的探测过程需要TURN服务器支持，而TURN服务器需要在会话还没进行前就分配媒体中转端口，多点部署更无法保证呼叫双方都使用同一个TURN服务器，结合TURN在ICE算法中作用和现有服务器网络架构，本方案用VPS RTPP替代TURN服务器，因此在TURN依赖上对ICE算法进行改造，使之更适合我们实际运用环境；但保留在使用TURN服务器情况的兼容性。VPS控制服务器、RTPP服务器、STUN服务器在逻辑上是分开的，但VPS本身具有STUN服务器功能,VPS与RTPP绑定实现多点部署，因此实际运用时完全可以在同一个服务器上。
2.3ICE算法流程ICE算法流程如图1-0所示：
图 1-0 ICE算法流程图
1.收集传输地址
会话者需要在呼叫前收集的地址包括：本地传输地址(Local Transport Address)和外部传输地址(Derived Transport Address)。本地传输地址通常由主机上一个物理(或虚拟)接口绑定一个端口而获得；会话者还将访问提供UNSAF(Unilateral self-address fixing)的服务器（例如本方案中的STUN服务器），对于每一个本地传输地址，会话者都可以从服务器上获得一组来源传输地址。显然，实现物理或虚拟连通方式越多，本方案将工作得越好。
2.启动STUN服务器
会话发起者获得一组传输地址后，将在本地地址和外部地址上启动STUN服务器用来使会话应答方能够判断地址的可达性。客户端将在每个本地传输地址上同时接受STUN请求包和媒体包，所以发起者需要对STUN消息与媒体流协议进行区分，在RTP和RTCP中实现这个并不难，因为RTP与RTCP(详见RFC3550/RFC 1889 )包总是以0b10(v=2)打头，而STUN(详见RFC3489)是0b00。
3.确定传输地址优先级
优先级反映了UA在该地址上接收媒体流的优先级别，取值范围在1到(2^31-1)之间，通常优先级按照被传输媒体流量确定。流量小者优先，而且对于相同流量者IPv6地址比IPv4地址具有更高优先级。物理接口产生的本地IPv6传输地址具有最高的优先级，然后是本地IPv4传输地址，在是外部公网地址，最后是通过VPN接口获得的本地传输地址。
4.构造初始化消息
初始化消息由一系列媒体流组成，每一个媒体流都有一个缺省地址和候选列表。缺省 地址通常为本地地址并被映射到消息传递地址上，而候选地址列表用于提供一些额外的地 址。理论上对于每个媒体流来说，实现最大连通可能性的传输地址是由公网上转发服务器 (如TURN)提供的地址，通常也是优先级最低的传输地址，但本方案中使用VPS RTPP替代 TURN服务器，因此初始化消息中无需提供公网转发服务器地址。客户端将可用的传输地址 编成一个候选地址列表(包括缺省地址)，一旦初始化信息生成后即可被发送。
5.构造应答消息
接收到初始化信息（Initiate Message）后，首先执行4中描述的地址收集过程(该过程在初始化信息到来前预收集完)，根据本端收集候选地址生成接受信息(Accept Message)并发送给对方。
6.候选对(Candidate pair)生成及连通性检查
如果接受者不支持ICE，则应答消息将只包含缺省的地址信息，这样发起方就知道它不用执行连通性检查了。否则会话应答方接收到初始化信息后，会话者就都有了双方候选地址；会话者将本地候选地址（Local Candidate）与远端候选地址（Remote Candidate）进行配对，生成候选对(Candidate Pair)，并按照优先级进行排序，检测删除冗余的候选对，设置当前状态，接着按照候选对优先级从高到低依次发送探测STUN Bind请求，来测试各个候选对的连通性，筛选出所有有效的候选对保存到有效候选对列表(Valid Candidate Pair List)中。连接检查的步骤可以简单归为：
(1) 将候选者进行优先级组织。
(2) 发送检查每个优先级对
(3) 回复从其他代理中收到的每个检查。
每个检查都是一个STUN request/response传输，是一个四次握手的过程，因此ICE检查每个方向，直到两边都有了回应才能确定联通。
7.最佳候选对提名
每一个会话中，会话参与者都拥有自己的角色，这个角色分为：控制角色（Controlling Role）和受控角色（Controlled Role），控制角色是最终通讯路径的决定者；在实际运用中发起方往往处于控制角色，而接收方处于受控角色。ICE为控制角色提供两种提名方法:完整提名(Regular Nomination)和快速提名(Aggressive Nomination)。
完整提名:即控制方要求检测出至少一对有效候选对才停止检测，并从新对有效候选对发送STUN Bind请求，但此时请求消息将加入提名标记(USE-CANDIDATE)，一旦有接收到应答消息，该有效候选对将作为最终通讯路径。流程如下图：
图1-1 完整提名
快速提名:即控制方一开始就在发送的STUN Bind请求消息中加入提名标记（USE-CANDIDATE)，一旦接收到应答就立即停止探测，并将该有效候选对作为最终通讯路径。流程如下图:
图 1-2 快速提名
3信令格式3.1"candidate"属性使用ICE方式穿透NAT，必须映射ICE定义的参数到SIP消息格式中，同时对其SDP属性进行简单扩展，在SDP的Media块中定义一个新的属性“candidate”来支持ICE。它包含一个候选IP地址和端口，以及传输协议类型、优先级别等参数。Media块中可能会有多个“candidate”属性，这时每个“candidate”应该包括不重复的IP地址和端口。语法属性如下：
candidate-attribute = "candidate" ":" foundation SP component-id SP
transport SP
priority SP
connection-address SP;from RFC 4566
port ;port from RFC 4566
SP cand-type
[SP rel-addr]
[SP rel-port]
*(SP extension-att-name SP
extension-att-value)
foundation = 1*32ice-char
component-id = 1*5DIGIT
transport = "UDP" / transport-extension
transport-extension = token; from RFC 3261
priority = 1*10DIGIT
cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr = "raddr" SP connection-address
rel-port = "rport" SP port
extension-att-name = byte-string;from RFC 4566
extension-att-value = byte-string
ice-char = ALPHA / DIGIT / " " / "/"
“candidate”属性字段说明详见《draft-ietf-mmusic-ice-19》。
1.1SDP中编码格式ICE信令格式在SDP中编码格式如下图所示：
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=ice
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 UDP 2130706178 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
m-line 格式：
m=<media> <port>/<number of ports> <transport> <fmt list>
每一个媒体流都对应一个m-line，m-line的顺序ICE是关心的，因为这关系到ICE的连通性检查的顺序，所以最重要的媒体流要排在前面。STUN对agent之间的连通性检查是利用短期的证书，证书在offer/answer的过程中通过“ice-ufrag”与“ice-pwd”被交换。 证书的username是从agent的username生成的，每一个agent提供密码用来检查它接收的请求的完整性，username也提供了二义性和正确性的检查。如果agent是轻量级的实现,那么在它的SDP中必须包含一个”a=ice_lite”来标示。Agent使用RTCP的话，必须按照RF3605所说的使用a=rtcp的属性，如果没有使用RTCP，那么必须根据RFC3556使用b=RS:0 b=RR:0。
2ICE工作流程描述本文将通过一个测试仿真环境来展示ICE算法的工作流程。由于ICE算法处理RTP和处理RTCP流程相同，以下主要以对RTP媒体流处理流程进行讲解。这里假设通话的双方是A和B，都处于各自的NAT之后，A的地址是10.0.1.9，A的NAT映射地址是211.35.29.30；B的地址是192.168.1.6，B的NAT出口地址是202.205.80.130，同时在公网上架设服务器务器上运行STUN服务器，服务器地址为218.65.228.110，监听端口为3478；A的RTP和RTCP本地分配端口是1080和1081，NAT映射端口为10890和10891；B的RTP和RTCP本地分配端口是2060和2061，NAT映射端口为20680和20681。网络拓扑图如图1-3所示：
图 1-3 仿真网络拓扑图
2.1地址收集过程A在呼叫B前，首先从本端主机获得本地Host地址10.0.1.9:1080，在通过公网上的STUN 服务器获得Nat映射地址211.35.29.30:10890，此过程时序如图1-4所示。
图1-4 A端取映射地址过程
表1 A端地址映射表
|
A |
A's NAT |
STUN | |
|
RTP |
10.0.1.9:1080 |
211.35.29.30:10890 |
218.65.228.110:3478 |
|
RTCP |
10.0.1.9:1081 |
211.35.29.30:10891 |
218.65.228.110:3478 |
A收集到本端所有候选地址后，计算出每个候选地址优先级，并生成A的Initiate Message如下：
>v=0
>o=- 3414953978 3414953978 IN IP4 10.0.1.9
>s=ice
>t=0 0
>a=ice-ufrag:0124305e
>a=ice-pwd:440d491c
>m=audio 1080 RTP/AVP 0
>c=IN IP4 10.0.1.9
>a=candidate:1 1 UDP 2130706431 10.0.1.9 1080 typ host
>a=candidate:2 1 UDP 1694498562 211.35.29.30 10890 typ srflx raddr 10.0.1.9 rport 1080
>a=candidate:3 2 UDP 2130706431 10.0.1.9 1081 typ host
>a=candidate:4 2 UDP 1694498562 211.35.29.30 10891 typ srflx raddr 10.0.1.9 rport 1081
同样B也需要完成本端地址收集工作。流程如图1-5，所得的地址如表2所示。
图1-5 B端取映射地址过程
表2 B端映射地址表
|
B |
B's NAT |
STUN | |
|
RTP |
192.168.1.6:2060 |
202.205.80.130:20680 |
218.65.228.110:3478 |
|
RTCP |
192.168.1.6:2061 |
202.205.80.130:20681 |
218.65.228.110:3478 |
同样B端根据收集到的地址，生成对A的响应消息(Accept Message)，消息格式如下:
>v=0
>o=- 3414953978 3414953978 IN IP4 192.168.1.6
>s=ice
>t=0 0
>a=ice-ufrag:0124305e
>a=ice-pwd:440d491c
>m=audio 2060 RTP/AVP 0
>c=IN IP4 192.168.1.6
>a=candidate:1 1 UDP 2130706431 192.168.1.6 2060 typ host
>a=candidate:2 1 UDP 1694498562 202.205.80.130 20680 typ srflx raddr 192.168.1.6 rport 2060
>a=candidate:3 2 UDP 2130706431 10.0.1.9 1081 typ host
>a=candidate:4 2 UDP 1694498562 202.205.80.130 20681 typ srflx raddr 192.168.1.6 rport 2061
当A和B双方都接收到对方候选地址列表时，此时已完成所有地址收集工作，接着双方将本端候选地址与远端候选地址进行配对(Candidate Pair),并按照优先级排序，生成连通性候选对检查表,如表3所示:
表3 候选对映射地址表
|
Pairs |
Local Cand |
Remote Cand |
valid |
nominated |
State |
default |
|
Pair 1 |
candidate:1 |
candidate:1 |
x |
x |
x |
0 |
|
Pair 2 |
candidate:1 |
candidate:2 |
x |
x |
x |
0 |
|
Pair 3 |
candidate:2 |
candidate:1 |
x |
x |
x |
0 |
|
Pair 4 |
candidate:2 |
candidate:2 |
x |
x |
x |
0 |
候选配对优先级计算方法为如下( G为控制方候选项优先级 D为受控方候选项优先级):
pair priority = 2^32*MIN(G,D) 2*MAX(G,D) (G>D?1:0)
2.2连通性检查确定穿越方式连通性检查是从候选对生成后开始的，双方同时进行，通过STUN协议完成。为了讨论方便将测试分为以下三种情况:
- 双方为non-symmetric NAT。
- 一方为symmetric NAT，一方为non-symmetric NAT，一方为Full Cone NAT。
- 一方方为symmetricNAT，一个方为非Full Cone NAT。
(1) non-symmetric NAT
测试流程如图1-6所示。
图1-6 non-summetric下测试过程
首先B根据候选对列表优先级依次发送STUN Bind请求，显然Pair 1不通，然后再尝试探测Pair 2候选对的连通性，从图1-5中看出，Pair2可以收到STUN Resp的回应，此时该候选对会被放入有效配对列表，并继续对其他配对进行探测，直到所有该媒体流可能候选配对都探测完成。同样A也执行这一过程，并得到相应的有效配对列表，最后由会话的控制方A根据收集到的有效配对列表，按照优先级别从新进行探测，此时STUN Bind请求消息中被加入 USE-CANDIDATE 属性标识，一旦有接收到受控方B的STUN Resp应答，则停止检测，并最终确定媒体流的最佳通讯路径，这里选择的就是Pair2通讯路径。至此，A和B就建立了媒体通道使得语音流穿越了各自的NAT。
(2)一方为symmetric NAT
这里假设A处于symmetric NAT而B处于non-symmetric NAT，测试过程如图1-7所示。
图1-7 A处于symmetric NAT下测试过程
由于A 处于symmetric NAT，因此B根据收集的候选对列表发送探测的STUN Bind请求都无法得到有效应答。此时B只能等待A的探测请求配合完成对A候选对的有效性探测，并最终由受控方A确定媒体流的最佳通讯路径，从图可知，A将使用Pair2作为双方的媒体通信路径。
(3)双方为symmetric NAT
这里假设A和B都处于symmetric NAT，RTPP与STUN服务器部署在同一台服务器，结合我司实际运营环境可知，双方的SDP默认连接地址及端口经VPS替换为RTPP媒体转发地址及端口，因此在A和B完成对双方候选地址收集同时也得到了对方默认候选地址，这里我们假设RTPP为A分配的默认转发端口为35260，为B分配的默认转发端口为53620，则整个测试过程如图1-8所示。
图1-8 A和B都处于symmetric NAT下的测试过程
由于A和B都处于symmetric NAT，因此由(2)可知此时A和B对有效候选对探测都将失败，至此使用STUN探测穿越NAT已经失效，A和B只能直接向对方提供的默认接收地址(即SDP中m与c选项地址)发送媒体流，从现有服务器架构可知，默认接收地址即为RTPP服务器转发地址，此时正符合现有NAT穿越方法，实现双方的媒体通信建立。
2.3映射与会话超时在通信过程中还需要考虑以下超时问题:
(1)地址映射的超时：大多数NAT为内网主机的地址和端口建立的“NAT映射地址”都有一个生存时间，如果一段时间内（通常为30秒），这个映射上没有数据流量，这个映射就被自动释放，所以如果想一直保持这个连接，在通信双方没有数据流量的时候，必须有一种keepalive机制来确保映射不被释放。既如果没有数据传递，内网主机必须定时的向外网发送特定的keepalive报文，接收方收到这个报文后马上回复。
(2)会话的超时：会话（session）的概念是在非对称NAT中，当内网使用同一个端口号向外网几个不同的主机和端口发送UDP数据包时，NAT会自动在内部为每一个外部主机创建一个session。只有在session期间，外部主机才能向那内部主机发送数据报。如果通信双方很长时间没有数据流量，session就会被释放调，所以必须有一种相似的keepalive机制来保持session不要超时释放。一个地址映射对应一个或多个session，而一个session只能属于一个映射。
(3)RTPP会话超时：当双方不同时处于symmetric NAT时，ICE算法此时能实现P2P传输，由于现有服务器架构不管是否执行P2P传输，VPS都会向RTPP发送申请转发请求，因此RTPP转发超时机制就一直会存在，这就需要解决在P2P传输情况下RTPP超时挂断问题。
3ICE策略方案3.1Libjingle策略方案描述Libjingle - Google Talk Voice及 P2P 的交互操作函数库，Google提供的C 组件集，它为Google Talk的点对点通讯与语音呼叫功能提供交互操作性。其独特的P2P ice探测策略即实时最佳路径选择，为点对点语音通讯质量提供可靠保障。
Libjingle P2P支持以下两种策略模式：
(1)ICEPROTO_GOOGLE, Google自己的ICE控制策略；
(2)ICEPROTO_RFC5245，标准的ICE控制策略；
以上我们已经介绍过RFC5245标准ICE的探测流程和控制策略，下面我们重点介绍Google的ICE控制策略(下面我们统一用gice表示)；
在gice中一个P2P连接包含有两个通道：探测通道(The session negotiation channel) 和 数据通道(The data channel)；前置顾名思义主要负责ICE探测流程，而后者则是有效数据的传输通道(audio, video, files, etc)；如下图5-1所示：
图 5-1 gice P2P连接通道描述
gice整个P2P测试会话建立流程可以用图5-2描述：
图 5-2 gice P2P测试会话建立流程描述
由以上流程可以可知，gice的地址收集过程与RFC5245标准的ICE策略是一致的，而不同点主要体现在以下几点：
(1)sdp 中ice信息不携带candidate信息；
gice中不管是请求消息(sdp1 ice1)，还是应答消息(sdp2 ice2)，它们ice内容都只包含ice-ufrag和ice-pwd，而candidate信息是由专门的消息进行发送的(在libjingle提供的测试程序中，一个candidate消息只携带一条地址信息，candidate信息是按照优先级发送的，优先级最高的最先发送)，这样做一方面是为了能动态实时地将本地的最新地址信息通知对方；另一方面也加快双方探测启动过程,一定程度上减少了探测流程；
(2)不仅能动态实时调整最佳路径，且双方不受角色限制；
图中阴影部分是一个持续过程，探测贯穿于整个会话中，只要新的探测结果优于当前路径，则立即进行最优路径切换；这里需要说明的是，gice不受角色控制，也就是说双方都可以独立选择本端最好的通讯路径；
(3)最优路径决策；
Gice最优路径选择策略主要从以下几个方面考虑：
A. Compare first on writability and static preferences.(读写能力，优先级别)
B. Otherwise, sort based on latency estimate.(rtt时间)
C. new_conn->rtt() <= cur_conn->rtt() kMinImprovement(kMinImprovement = 10ms)
注：gice相比RFC5245标准，在STUN探测信令字段上有做相应的优化，这里我们只关注ice决策固不做特别说明；
3.2Pjsip策略方案描述只支持RFC5245标准的ICE策略(详见5.3(1)中策略描述)。
3.3我司策略方案描述由于我司使用的RTPP媒体中转服务器不支持TURN协议(VPS RTPP替代TURN服务器），因此中转地址作为默认有效地址对，不参与ICE探测，其优先级别最低；结合我司目前网络架构及实际运用场景，pjsip项目中ICE功能完善，模块独立可移植性好，库的大小比较适合移动平台，因此在PJSIP ICE架构上提出两种策略模型：支持动态切换和不支持动态切换；
(1)不支持动态切换策略
我司目前组件架构主要由USCRTC-TGO、USCRTC-UGO、USCRTC-VOGO、USCRTC-VIGO四个库组成；其中USCRTC-TGO、USCRTC-UGO是协议库，USCRTC-VOGO、USCRTC-VIGO是音视频引擎库；结合ICE原理可知ICE信息交互需承载在USCRTC-TGO与USCRTC-UGO协议库上，而多媒体数据通道则主要由USCRTC-VOGO、USCRTC-VIGO自己管理和维护。
因此在不考虑通话过程中动态切换多媒体数据通道链路的话，则此时ICE作为一个独立的模块，功能仅仅是完成P2P探测任务，其结果是返回一个有效的通讯链路(有效是指能保证正常通讯需求，有可能是P2P链路，也有可能是中转链路)，结果一旦确定，ICE就立即释放P2P会话资源，最终的多媒体数据链路由USCRTC-VOGO、USCRTC-VIGO根据ICE结果创建管理和维护；具体流程描述如下：
图 5-3 P2P呼叫流程描述(不支持动态切换)
A)首先，初始化ICE模块时启动地址收集，完成本地候选地址收集任务；
B)当发起呼叫时，UGo从ICE模块获取本地ICE会话信息(ice认证信息和候选地址)；
C)将ICE会话信息封装到呼叫请求SDP(图中sdp1 ice1)中，经sipex服务器转发，此 时sdp中默认媒体地址和端口被服务器替换为中转服务器RTPP地址(图中sdp2 ice1)；
D)当被叫方收到呼叫请求时，从消息中获取出ICE会话信息以及中转地址(sdp2中的 RTPP地址)，并配置到本端ICE模块中完成远端ICE信息收集过程，同时被叫方也类 似执行B)、C）步骤将本地ICE信息通过应答消息发送给主叫方；
E)主叫接收到应答消息后,类似执行D)步骤完成远端ICE信息收集过程；
F)任何一方一旦完成候选地址配对，则立即启动ICE探测过程；
G)ICE完成所有媒体通道探测后，返回探测结果(注：探测成功则返回有效P2P地址对， 否则使用默认中转服务器RTPP地址)；
H)UGO获取到ICE返回地址对信息后，首先删除释放ICE会话资源，发送ice通知请 求给服务器，然后根据返回ICE结果信息启动VOGO、VIGO会话，完成媒体通道建立；
最优路径决策：
A.探测流程使用快速提名方式(按照优先级高到低探测，一旦探测成功则停止后续 探测流程)；
B.使用RFC5245标准ICE决策（即由control方根据地址对优先级确定）；
(2)支持实时动态切换策略
该模式下地址收集交互流程与（1）相同，不同的是需要VOGO、VIGO的Transport使用外部扩展模式，即由ICE管理维护媒体通道，VOGO、VIGO使用ICE接口完成媒体数据收发操作；同时ICE探测贯穿在整个会话过程中，从而达到实时更新最佳路径目的，借鉴gice策略，在标准决策上我们也增加对网络RTT延迟时间的判断；详细流程如下：
图 5-3 P2P呼叫流程描述(实时动态切换)
最佳路径决策：
A.使用ICE标准探测流程；
B.由control方根据地址对的RTT值和优先级确认；
(3)支持“静态”切换策略
所谓的“静态”切换策略是指：当ice探测成功情况下，优先使用P2P进行通讯传输，当RTP丢包率大于一定阀值时（比如ppl>10%），则切换使用RTPP中转方式传输，而后不在做传输切换。该策略实现比较简单，ice探测只需要进行一次，无需存在在整个会话中；丢包率阀值可根据实际运用环境设定，整个通话中最多只存在一次通道切换。
最佳路径决策：
A.使用ICE标准探测流程，探测成功优先使用P2P；
B.当丢包率大于一定阀值时，切换为RTPP中转方式；
(4)多媒体通道探测策略
一路会话，主要包括音频和视频(当支持视频情况下)；一个媒体通道(音频或者视频通道)一般包括RTP和RTCP两个传输通道；因此一路会话可能存在2~4个传输通道，由以上ice探测可知，对于每一个传输通道ice都是独立探测维护的，也就是说一路会话需要进行2~4个传输通道探测过程，只有当所有传输通道探测完成后，才能得到最终探测结果。 目前我司一个传输通道探测信令重发超时是100ms，探测信令重发7次，而后等待16*100ms超时，因此一个传输通道探测失败最多需要消耗7*100ms 16*100ms = 23*100ms即2.3秒，由于探测信令发送是采用超时群发方式，因此一路会话ice探测最多消耗估计时间为2.3s~3s。
在实际运用中RTP和RTCP的传输端口是成对的(默认RTCP传输端口为RTP端口加1)，业界惯例绝大部分运用场景也仅仅是提供RTP端口；因此这里我们对RTCP传输通道的ICE探测作简化，只探测音视频RTP传输通道，RTCP传输决策与RTP一致，仅仅在端口上做加1处理。(注：RTP传输端口范围在30000~60000 且为偶数)。
4最优线路判决方案根据我司实际情况，p2p很大程度上可以降低延迟，尤其是在视频应用中，不仅能解决服务器中转性能问题，对网络延时和丢包提供了较好的保证；同时考虑到p2p也存在一定的不足之处，在复杂的网络环境下，最佳路径往往不是绝对的，需要一个实时探测的方式，动态调整切换当前网络最佳的路径，为语音视频传输提供最优保证。总上所述方案(2)比较符合我们的需求。
在使用方案2时，这里需要注意几个问题：
(1) 当p2p成功时，中转服务器不需要主动释放资源，组件需要定时1s发一个续活PING报文(可以为禁音包或者stun心跳包)。
(2) 我们需要一个执行动态切换的标准，这里我们主要参考两个参数:RTT值和PPL丢包率；RTT参数我们可以由ICE定时探测和webrtc neteq模块中获取，而PPL参数则只能借助VoGo中neteq统计参数；具体切换策略描述如下：
i. 当为直拨呼叫时，不启用ICE模块，使用VoGo自带UDP传输。
ii. 当P2P探测失败，启用ICE模块中RTPP中转线路，不启用ICE探测定时器，不启用定时动态切换判断定时器。
iii. 当P2P探测成功，启动1s定时PING探测(ping超时则此次RTT累加1000ms)，启动10s线路切换判断，30s内有两次判决切换，则执行线路切换。
RTT值统计方法:
RTT_RATIO = 3.
_rtt = (RTT_RATIO * oRTT nRTT) / (RTT_RATIO 1); 其中RTT_RATIO为权重系数，oRTT是历史统计值，nRTT是当前统计值。
切换判决条件:
kMinImprovement = 20ms;
（ping_rtt < me_rtt - kMinImprovement） && （ change_cnt > 1）;其中ping_rtt是空闲线路rtt统计值，me_rtt为当前使用线路rtt统计值；change_cnt为判决切换次数。
线路切换判断代码如下：
/*ice line check 10s timer callback */
/*LionGong 20120518 */
void on_ice_linecheck_cb(int timeid)
{
static int change_cnt = 0;
static int check_cnt = 0;
int ping_rtt = 0;
int me_rtt = 0;
/*get ice ping rtt value*/
ping_rtt = iceapi_get_rtt(eICE_COMP_AUDIO_RTP);//获取ice空闲线路rtt值
/*get current media rtt value*/
me_rtt = me_get_rtt();//获取vogo neteq中rtt统计值
/*if (30s) have 2 times need to change , we do line change*/
if ((ping_rtt < me_rtt - kMinImprovement) && ( change_cnt > 1))
{
if (iceapi_get_mode() == ICE_P2P)
{
iceapi_update_mode(ICE_RTPP);
me_update_ice_mode(eME_ICE_RTPP_MD);
pcp_trace_line_change(ICE_RTPP);
ms_report("on_ice_linecheck_cb: best line change to rtpp.");
on_trace(eUGo_TraceWarning, "on_ice_linecheck_cb: #best line change to rtpp.");
}
else
{
iceapi_update_mode(ICE_P2P);
me_update_ice_mode(eME_ICE_P2P_MD);
pcp_trace_line_change(ICE_P2P);
ms_report("on_ice_linecheck_cb: best line change to p2p.");
on_trace(eUGo_TraceWarning, "on_ice_linecheck_cb: #best line change to p2p.");
}
change_cnt = 0;
}
/*if check cnt > 3 times (30s) , we clean change cnt*/
if ( check_cnt > 2)
{
change_cnt = 0;
check_cnt = 0;
}
ms_report("on_ice_linecheck_cb:ping_rtt[%d],me_rtt[%d]---change_cnt[%d].", ping_rtt, me_rtt, change_cnt);
}
(3) 组件在启用动态切换方案时，媒体引擎是否使用外部扩展传输(即ice传输链路)，与p2p是否成功有关；当p2p成功时，则媒体引擎使用ice通道进行媒体传输，否则，使用内部webrtc提供通道进行媒体传输(直拨模式下默认使用webrtc传输通道)。
(4) 组件动态切换方案架构如下：
图 6-1 组件动态切换架构
(5) 呼叫处理流程如下：
图 6-2 ice呼叫处理流程
5PPL参数统计方案当考虑PPL参数时，由于ICE中没有对PPL参数做统计，因此只能根据neteq统计参数获取当前正在使用的线路PPL值，空闲线路没有有效的统计手段；以下提供两种参考方案:
方案一：
在ICE模块中添加对空闲线路PPL参数的统计方法，而当前使用的线路可由neteq中获取得到；PPL值与RTT值可以借鉴服务器智能路由算法得出各个线路的总体delay值，具体计算公式如下：
/*LionGong 20120518 */
int rtpc_calc_network_vector_value(int delay, int lost)
{
int vector_val = -1;
if(lost <= 5)
vector_val = delay;
else
vector_val = delay lost * lost;
return vector_val;
}
优点： 能实时有效统计出各个线路的RTT和PPL参数值，准确性比较高。
缺点： 需要额外在ICE中添加PPL统计模块，可能需要使用icmp协议。
方案二：
根据现有情况，只获取当前正在使用线路PPL参数(即neteq中统计参数)，与给定阀值(15%)比对，此时有两种场景：
(1) 当空闲线路没有进行过历史PPL统计参数记录时，如果当前线路PPL值大于15%，则立即执行线路切换；否则只根据各个线路统计RTT值，判决是否执行切换。
(2) 当各个线路都有进行过历史PPL参数统计时，直接根据RTT与PPL统计算法计算得出各个线路总体delay值，通过对比delay值，判断是否进行线路切换。
优点： 无需额外添加PPL统计模块，实现相对简单。
缺点： 由于使用的是历史数据参与delay值计算，因此有一定的误差。
6总结本方案消除了现有的UNSAF机制的许多脆弱性。例如传统的STUN有几个脆弱点，其中一个就是发现过程需要客户端自己去判断所在NAT类型。另一点脆弱性在于STUN、TURN等机制都完全依赖于一个附加的服务器，而ICE利用服务器分配单边地址的同时，还允许客户端直接相连，因此即使STUN或TRUN服务器中有任何一个失败了，ICE方式仍可让呼叫过程继续下去。此外，传统的STUN最大的缺陷在于它不能保证在所有网络拓扑结构中都正常工作，最典型的问题就是Symmetric NAT。对于TURN或类似转发方式工作的协议来说，由于服务器的负担过重，很容易出现丢包或者延迟情况。而ICE方式正好提供了一种负载均衡的解决方案，它将转发服务作为优先级最低的服务，从而在最大程度上保证了服务的可靠性和灵活性。
本方案实际运用过程中需要注意以下问题：
1. ICE算法本身来看，双方收集到的候选地址越多，算法越容易成功，但同时也增加了探 测过程，导致会话建立时间延长，因此需要结合实际环境合理限制候选地址个数。
2. 在网络延迟丢包情况下，有可能存在对优先级更高的候选对发送的探测包丢包，导致最 终选择优先级较低配对的情况，因此需要结合实际选择是否进行多次探测或重复发包过 程。
3. ICE算法本身要求会话双方明确自己角色，也就是说会话参与者中必须一方作为控制方， 另一个作为受控方，不允许双方都处于相同角色，因此类似第三方控制建立的会话场合 不适合本方案。
4. 本方案是基于使用SDP协议承载ICE属性字段的，暂不支持私有协议承载。
7参考资料
参考资料列表
8附录(1) 常用NAT穿越方案对比表
NAT穿越方案对比
(2) Libjingle 语音会话数据流程
Libjingle语音会话数据流程
作者：龚火金 （Lion）
版权归属：灵云快智
灵云快智_专注实时音视频智能硬件场景解决方案,智能手表,智能机器人,智慧社区,企业通信
,
