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

网络地址转换

1简介

1.1现有NAT穿越方案

我司现有服务器网络架构对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 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 10.0.1.1 8998 typ host a=candidate:2 1 UDP 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

As 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=- IN IP4 10.0.1.9 >s=ice >t=0 0 >a=ice-ufrag:e >a=ice-pwd:440d491c >m=audio 1080 RTP/AVP 0 >c=IN IP4 10.0.1.9 >a=candidate:1 1 UDP 10.0.1.9 1080 typ host >a=candidate:2 1 UDP 211.35.29.30 10890 typ srflx raddr 10.0.1.9 rport 1080 >a=candidate:3 2 UDP 10.0.1.9 1081 typ host >a=candidate:4 2 UDP 211.35.29.30 10891 typ srflx raddr 10.0.1.9 rport 1081

同样B也需要完成本端地址收集工作。流程如图1-5，所得的地址如表2所示。

图1-5 B端取映射地址过程

表2 B端映射地址表

B

Bs 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=- IN IP4 192.168.1.6 >s=ice >t=0 0 >a=ice-ufrag:e >a=ice-pwd:440d491c >m=audio 2060 RTP/AVP 0 >c=IN IP4 192.168.1.6 >a=candidate:1 1 UDP 192.168.1.6 2060 typ host >a=candidate:2 1 UDP 202.205.80.130 20680 typ srflx raddr 192.168.1.6 rport 2060 >a=candidate:3 2 UDP 10.0.1.9 1081 typ host >a=candidate:4 2 UDP 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*/ 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*/ 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）

版权归属：灵云快智

灵云快智_专注实时音视频智能硬件场景解决方案,智能手表,智能机器人,智慧社区,企业通信