ICE實現(xiàn)Nat穿越方案設(shè)計說明書

Keywords 關(guān)鍵詞：ICE，STUN，TURN，RtpP，VPS，SIP，SDP，RTP/RTCP，NAT，候選地址

Abstract 摘要：本文描述基于ICE方式實現(xiàn)NAT穿越方案設(shè)計，主要介紹了4種NAT類型、ICE算法及結(jié)合現(xiàn)有實際環(huán)境實現(xiàn)NAT穿越的可行性及工作的主要流程，用于指導后續(xù)方案實施及詳細概要設(shè)計工作。

List of abbreviations 縮略語清單：

Table 1 縮略語列表

1簡介

1.1現(xiàn)有NAT穿越方案

我司現(xiàn)有服務(wù)器網(wǎng)絡(luò)架構(gòu)對NAT穿越采用的是RTPP媒體中轉(zhuǎn)方式(Application Layer Gateway簡稱ALG解決方案)，所有呼叫媒體都必須經(jīng)由RTPP中轉(zhuǎn)服務(wù)器進行轉(zhuǎn)發(fā)，因此對RTPP轉(zhuǎn)發(fā)性能及寬帶需求很高，同時在手機等復雜環(huán)境下，由于中轉(zhuǎn)導致延遲丟包率加大，影響用戶的正常呼叫體驗，也成為后續(xù)視頻功能的一個頸瓶，因此急需一種能夠很好提供負載均衡的解決方案。

1.2ICE方案設(shè)計目的

結(jié)合我司實際運營情況及P2P(Peer to Peer)技術(shù)發(fā)展，本文提出基于ICE方式實現(xiàn)NAT穿越完成P2P通訊的設(shè)計方案，描述結(jié)合我司現(xiàn)有網(wǎng)絡(luò)架構(gòu)上使用ICE算法實現(xiàn)NAT穿越可行性及優(yōu)勢。ICE算法是針對現(xiàn)有NAT類型尋找最優(yōu)化通訊路徑，最大可能的實行P2P媒體流通訊，從而降低了由于中轉(zhuǎn)導致延遲丟包和對RTPP中轉(zhuǎn)服務(wù)器性能需求，實現(xiàn)負載均衡。

2ICE實現(xiàn)NAT穿越方案

2.1現(xiàn)有NAT類型

1. Full Cone （完全開放型）：來自相同的內(nèi)部地址的請求消息映射為相同的外部地址， 與外部地址(目的地址)無關(guān)。映射關(guān)系為P:p?A:b，任何外部主機可通過(A:b) 發(fā)送到數(shù)據(jù)到(P:p)上。

2. Restricted Cone（地址受限型）：來自相同的內(nèi)部地址的請求消息映射為相同的外部地 址，返回的數(shù)據(jù)只接受該內(nèi)部節(jié)點曾發(fā)數(shù)據(jù)的那個目的計算機地址X。映射關(guān)系為 P:p?A:b?X，只有來自X的數(shù)據(jù)包才可通過(A:b)發(fā)送到數(shù)據(jù)到(P:p)上。

3. Port Restricted Cone(端口受限型)：來自相同的內(nèi)部地址的請求消息映射為相同的外 部地址，返回的數(shù)據(jù)只接受該內(nèi)部節(jié)點曾發(fā)數(shù)據(jù)的那個目的地址X:x。映射關(guān)系為 P:p?A:b?X:x，只有來自X:x的數(shù)據(jù)包才可通過(A:b)發(fā)送到數(shù)據(jù)到(P:p)上。

4. Symmetric(對稱型) NAT：只有來自相同的內(nèi)部地址(P:p)，并且發(fā)送到同一個地址(X:x) 的請求消息，才被映射為相同的外部地址(A:b)，返回的數(shù)據(jù)只接受該內(nèi)部節(jié)點曾發(fā)數(shù) 據(jù)的那個目的地址X:x。映射關(guān)系為P:p?A:b?X:x，當(P:p)訪問(Y:y)時，映射為 P:p?B:c?Y:y。

NAT給P2P帶來的問題是：NAT只允許單方面發(fā)起連接，通訊的雙方不是平等的，具體 的表現(xiàn)為：

　?。?）內(nèi)網(wǎng)主機IP是私有的，外部主機看不到，也無法主動發(fā)起連接；

　?。?）即使知道了內(nèi)網(wǎng)IP，但NAT會丟棄沒有在映射表的數(shù)據(jù)包；

　　（3）內(nèi)網(wǎng)主機可以作為客戶端訪問外網(wǎng)，但不能作為服務(wù)器提供服務(wù)；

　?。?）當兩個主機都位于各自的NAT之后，要實現(xiàn)P2P的連接，就不僅是誰主動的 問題，而是如何解決在兩個NAT上同時有對方映射表項的問題。

2.2基本組成

1.呼叫發(fā)起/接受終端(會話參與者)

呼叫發(fā)起方和接收方是交互的實體，呼叫發(fā)起方負責SIP通信并等待接收方應(yīng)答，接 收方被動接受SIP（Session Initiation Protocol，信令控制協(xié)議）請求，并根據(jù)實 際情況選擇接受或者拒絕，并發(fā)送回相應(yīng)的響應(yīng)碼。

2.VPS控制服務(wù)器(SIP信令代理服務(wù)器)

整個SIP應(yīng)用過程需要一個控制服務(wù)器，它負責用戶的注冊、登錄、管理和SIP信令的中轉(zhuǎn)，并且負責傳遞控制信息；功能上講，控制服務(wù)器起到注冊服務(wù)器和信令中繼功能。

3.STUN服務(wù)器(VPS STUN服務(wù)器)

STUN（Simple Traversal of UDP over NATs）是指NAT 的UDP簡單穿越；實際運用中配合完成NAT類型檢查及連通性驗證,并提供3個擴展屬性:USE-CANDIDATE, ICE-CONTROLLED 和ICE-CONTROLLING。

4.RTPP服務(wù)器

RTPP服務(wù)器為媒體中轉(zhuǎn)服務(wù)器，當呼叫雙方都處于Symmetric NAT(對稱型NAT)后面 時，則媒體流經(jīng)由RTPP服務(wù)器中轉(zhuǎn)完成NAT穿越。

ICE是通過一系列的嘗試來決定最佳NAT的穿越路徑方式，最佳路徑的探測過程需要TURN服務(wù)器支持，而TURN服務(wù)器需要在會話還沒進行前就分配媒體中轉(zhuǎn)端口，多點部署更無法保證呼叫雙方都使用同一個TURN服務(wù)器，結(jié)合TURN在ICE算法中作用和現(xiàn)有服務(wù)器網(wǎng)絡(luò)架構(gòu)，本方案用VPS+RTPP替代TURN服務(wù)器，因此在TURN依賴上對ICE算法進行改造，使之更適合我們實際運用環(huán)境；但保留在使用TURN服務(wù)器情況的兼容性。VPS控制服務(wù)器、RTPP服務(wù)器、STUN服務(wù)器在邏輯上是分開的，但VPS本身具有STUN服務(wù)器功能,VPS與RTPP綁定實現(xiàn)多點部署，因此實際運用時完全可以在同一個服務(wù)器上。

2.3ICE算法流程

ICE算法流程如圖1-0所示：

圖 1-0 ICE算法流程圖

1.收集傳輸?shù)刂?/strong>

會話者需要在呼叫前收集的地址包括：本地傳輸?shù)刂?Local Transport Address)和外部傳輸?shù)刂?Derived Transport Address)。本地傳輸?shù)刂吠ǔＳ芍鳈C上一個物理(或虛擬)接口綁定一個端口而獲得；會話者還將訪問提供UNSAF(Unilateral self-address fixing)的服務(wù)器（例如本方案中的STUN服務(wù)器），對于每一個本地傳輸?shù)刂?，會話者都可以從服?wù)器上獲得一組來源傳輸?shù)刂贰ｏ@然，實現(xiàn)物理或虛擬連通方式越多，本方案將工作得越好。

2.啟動STUN服務(wù)器

會話發(fā)起者獲得一組傳輸?shù)刂泛螅瑢⒃诒镜氐刂泛屯獠康刂飞蠁覵TUN服務(wù)器用來使會話應(yīng)答方能夠判斷地址的可達性?？蛻舳藢⒃诿總€本地傳輸?shù)刂飞贤瑫r接受STUN請求包和媒體包，所以發(fā)起者需要對STUN消息與媒體流協(xié)議進行區(qū)分，在RTP和RTCP中實現(xiàn)這個并不難，因為RTP與RTCP(詳見RFC3550/RFC 1889 )包總是以0b10(v=2)打頭，而STUN(詳見RFC3489)是0b00。

3.確定傳輸?shù)刂穬?yōu)先級

優(yōu)先級反映了UA在該地址上接收媒體流的優(yōu)先級別，取值范圍在1到(2^31-1)之間，通常優(yōu)先級按照被傳輸媒體流量確定。流量小者優(yōu)先，而且對于相同流量者IPv6地址比IPv4地址具有更高優(yōu)先級。物理接口產(chǎn)生的本地IPv6傳輸?shù)刂肪哂凶罡叩膬?yōu)先級，然后是本地IPv4傳輸?shù)刂罚谑峭獠?span id="n5ny6fb" class="candidate-entity-word" data-gid="1623363" qid="6579563235396048131" mention-index="0">公網(wǎng)地址，最后是通過VPN接口獲得的本地傳輸?shù)刂贰?/span>

4.構(gòu)造初始化消息

初始化消息由一系列媒體流組成，每一個媒體流都有一個缺省地址和候選列表。缺省 地址通常為本地地址并被映射到消息傳遞地址上，而候選地址列表用于提供一些額外的地 址。理論上對于每個媒體流來說，實現(xiàn)最大連通可能性的傳輸?shù)刂肥怯晒W(wǎng)上轉(zhuǎn)發(fā)服務(wù)器 (如TURN)提供的地址，通常也是優(yōu)先級最低的傳輸?shù)刂?，但本方案中使用VPS+RTPP替代 TURN服務(wù)器，因此初始化消息中無需提供公網(wǎng)轉(zhuǎn)發(fā)服務(wù)器地址?？蛻舳藢⒖捎玫膫鬏?shù)刂?編成一個候選地址列表(包括缺省地址)，一旦初始化信息生成后即可被發(fā)送。

5.構(gòu)造應(yīng)答消息

接收到初始化信息（Initiate Message）后，首先執(zhí)行4中描述的地址收集過程(該過程在初始化信息到來前預收集完)，根據(jù)本端收集候選地址生成接受信息(Accept Message)并發(fā)送給對方。

6.候選對(Candidate Pair)生成及連通性檢查

如果接受者不支持ICE，則應(yīng)答消息將只包含缺省的地址信息，這樣發(fā)起方就知道它不用執(zhí)行連通性檢查了。否則會話應(yīng)答方接收到初始化信息后，會話者就都有了雙方候選地址；會話者將本地候選地址（Local Candidate）與遠端候選地址（Remote Candidate）進行配對，生成候選對(Candidate Pair)，并按照優(yōu)先級進行排序，檢測刪除冗余的候選對，設(shè)置當前狀態(tài)，接著按照候選對優(yōu)先級從高到低依次發(fā)送探測STUN Bind請求，來測試各個候選對的連通性，篩選出所有有效的候選對保存到有效候選對列表(Valid Candidate Pair List)中。連接檢查的步驟可以簡單歸為：

(1) 將候選者進行優(yōu)先級組織。

(2) 發(fā)送檢查每個優(yōu)先級對

(3) 回復從其他代理中收到的每個檢查。

每個檢查都是一個STUN request/response傳輸，是一個四次握手的過程，因此ICE檢查每個方向，直到兩邊都有了回應(yīng)才能確定聯(lián)通。

7.最佳候選對提名

每一個會話中，會話參與者都擁有自己的角色，這個角色分為：控制角色（Controlling Role）和受控角色（Controlled Role），控制角色是最終通訊路徑的決定者；在實際運用中發(fā)起方往往處于控制角色，而接收方處于受控角色。ICE為控制角色提供兩種提名方法:完整提名(Regular Nomination)和快速提名(Aggressive Nomination)。

完整提名:即控制方要求檢測出至少一對有效候選對才停止檢測，并從新對有效候選對發(fā)送STUN Bind請求，但此時請求消息將加入提名標記(USE-CANDIDATE)，一旦有接收到應(yīng)答消息，該有效候選對將作為最終通訊路徑。流程如下圖：

圖1-1 完整提名

快速提名:即控制方一開始就在發(fā)送的STUN Bind請求消息中加入提名標記（USE-CANDIDATE)，一旦接收到應(yīng)答就立即停止探測，并將該有效候選對作為最終通訊路徑。流程如下圖:

圖 1-2 快速提名

3信令格式

3.1"candidate"屬性

使用ICE方式穿透NAT，必須映射ICE定義的參數(shù)到SIP消息格式中，同時對其SDP屬性進行簡單擴展，在SDP的Media塊中定義一個新的屬性“candidate”來支持ICE。它包含一個候選IP地址和端口，以及傳輸協(xié)議類型、優(yōu)先級別等參數(shù)。Media塊中可能會有多個“candidate”屬性，這時每個“candidate”應(yīng)該包括不重復的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>

每一個媒體流都對應(yīng)一個m-line，m-line的順序ICE是關(guān)心的，因為這關(guān)系到ICE的連通性檢查的順序，所以最重要的媒體流要排在前面。STUN對agent之間的連通性檢查是利用短期的證書，證書在offer/answer的過程中通過“ice-ufrag”與“ice-pwd”被交換。 證書的username是從agent的username生成的，每一個agent提供密碼用來檢查它接收的請求的完整性，username也提供了二義性和正確性的檢查。如果agent是輕量級的實現(xiàn),那么在它的SDP中必須包含一個”a=ice_lite”來標示。Agent使用RTCP的話，必須按照RF3605所說的使用a=rtcp的屬性，如果沒有使用RTCP，那么必須根據(jù)RFC3556使用b=RS:0 b=RR:0。

2ICE工作流程描述

本文將通過一個測試仿真環(huán)境來展示ICE算法的工作流程。由于ICE算法處理RTP和處理RTCP流程相同，以下主要以對RTP媒體流處理流程進行講解。這里假設(shè)通話的雙方是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，同時在公網(wǎng)上架設(shè)服務(wù)器務(wù)器上運行STUN服務(wù)器，服務(wù)器地址為218.65.228.110，監(jiān)聽端口為3478；A的RTP和RTCP本地分配端口是1080和1081，NAT映射端口為10890和10891；B的RTP和RTCP本地分配端口是2060和2061，NAT映射端口為20680和20681。網(wǎng)絡(luò)拓撲圖如圖1-3所示：

圖 1-3 仿真網(wǎng)絡(luò)拓撲圖

2.1地址收集過程

A在呼叫B前，首先從本端主機獲得本地Host地址10.0.1.9:1080，在通過公網(wǎng)上的STUN 服務(wù)器獲得Nat映射地址211.35.29.30:10890，此過程時序如圖1-4所示。

圖1-4 A端取映射地址過程

表1 A端地址映射表

A收集到本端所有候選地址后，計算出每個候選地址優(yōu)先級，并生成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端根據(jù)收集到的地址，生成對A的響應(yīng)消息(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),并按照優(yōu)先級排序，生成連通性候選對檢查表,如表3所示:

表3 候選對映射地址表

候選配對優(yōu)先級計算方法為如下( G為控制方候選項優(yōu)先級 D為受控方候選項優(yōu)先級):

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

2.2連通性檢查確定穿越方式

連通性檢查是從候選對生成后開始的，雙方同時進行，通過STUN協(xié)議完成。為了討論方便將測試分為以下三種情況:

• 雙方為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根據(jù)候選對列表優(yōu)先級依次發(fā)送STUN Bind請求，顯然Pair 1不通，然后再嘗試探測Pair 2候選對的連通性，從圖1-5中看出，Pair2可以收到STUN Resp的回應(yīng)，此時該候選對會被放入有效配對列表，并繼續(xù)對其他配對進行探測，直到所有該媒體流可能候選配對都探測完成。同樣A也執(zhí)行這一過程，并得到相應(yīng)的有效配對列表，最后由會話的控制方A根據(jù)收集到的有效配對列表，按照優(yōu)先級別從新進行探測，此時STUN Bind請求消息中被加入 USE-CANDIDATE 屬性標識，一旦有接收到受控方B的STUN Resp應(yīng)答，則停止檢測，并最終確定媒體流的最佳通訊路徑，這里選擇的就是Pair2通訊路徑。至此，A和B就建立了媒體通道使得語音流穿越了各自的NAT。

(2)一方為symmetric NAT

這里假設(shè)A處于symmetric NAT而B處于non-symmetric NAT，測試過程如圖1-7所示。

圖1-7 A處于symmetric NAT下測試過程

由于A 處于symmetric NAT，因此B根據(jù)收集的候選對列表發(fā)送探測的STUN Bind請求都無法得到有效應(yīng)答。此時B只能等待A的探測請求配合完成對A候選對的有效性探測，并最終由受控方A確定媒體流的最佳通訊路徑，從圖可知，A將使用Pair2作為雙方的媒體通信路徑。

(3)雙方為symmetric NAT

這里假設(shè)A和B都處于symmetric NAT，RTPP與STUN服務(wù)器部署在同一臺服務(wù)器，結(jié)合我司實際運營環(huán)境可知，雙方的SDP默認連接地址及端口經(jīng)VPS替換為RTPP媒體轉(zhuǎn)發(fā)地址及端口，因此在A和B完成對雙方候選地址收集同時也得到了對方默認候選地址，這里我們假設(shè)RTPP為A分配的默認轉(zhuǎn)發(fā)端口為35260，為B分配的默認轉(zhuǎn)發(fā)端口為53620，則整個測試過程如圖1-8所示。

圖1-8 A和B都處于symmetric NAT下的測試過程

由于A和B都處于symmetric NAT，因此由(2)可知此時A和B對有效候選對探測都將失敗，至此使用STUN探測穿越NAT已經(jīng)失效，A和B只能直接向?qū)Ψ教峁┑哪J接收地址(即SDP中m與c選項地址)發(fā)送媒體流，從現(xiàn)有服務(wù)器架構(gòu)可知，默認接收地址即為RTPP服務(wù)器轉(zhuǎn)發(fā)地址，此時正符合現(xiàn)有NAT穿越方法，實現(xiàn)雙方的媒體通信建立。

2.3映射與會話超時

在通信過程中還需要考慮以下超時問題:

(1)地址映射的超時：大多數(shù)NAT為內(nèi)網(wǎng)主機的地址和端口建立的“NAT映射地址”都有一個生存時間，如果一段時間內(nèi)（通常為30秒），這個映射上沒有數(shù)據(jù)流量，這個映射就被自動釋放，所以如果想一直保持這個連接，在通信雙方?jīng)]有數(shù)據(jù)流量的時候，必須有一種keepalive機制來確保映射不被釋放。既如果沒有數(shù)據(jù)傳遞，內(nèi)網(wǎng)主機必須定時的向外網(wǎng)發(fā)送特定的keepalive報文，接收方收到這個報文后馬上回復。

(2)會話的超時：會話（session）的概念是在非對稱NAT中，當內(nèi)網(wǎng)使用同一個端口號向外網(wǎng)幾個不同的主機和端口發(fā)送UDP數(shù)據(jù)包時，NAT會自動在內(nèi)部為每一個外部主機創(chuàng)建一個session。只有在session期間，外部主機才能向那內(nèi)部主機發(fā)送數(shù)據(jù)報。如果通信雙方很長時間沒有數(shù)據(jù)流量，session就會被釋放調(diào)，所以必須有一種相似的keepalive機制來保持session不要超時釋放。一個地址映射對應(yīng)一個或多個session，而一個session只能屬于一個映射。

(3)RTPP會話超時：當雙方不同時處于symmetric NAT時，ICE算法此時能實現(xiàn)P2P傳輸，由于現(xiàn)有服務(wù)器架構(gòu)不管是否執(zhí)行P2P傳輸，VPS都會向RTPP發(fā)送申請轉(zhuǎn)發(fā)請求，因此RTPP轉(zhuǎn)發(fā)超時機制就一直會存在，這就需要解決在P2P傳輸情況下RTPP超時掛斷問題。

3ICE策略方案

3.1Libjingle策略方案描述

Libjingle - Google Talk Voice及 P2P 的交互操作函數(shù)庫，Google提供的C++組件集，它為Google Talk的點對點通訊與語音呼叫功能提供交互操作性。其獨特的P2P ice探測策略即實時最佳路徑選擇，為點對點語音通訊質(zhì)量提供可靠保障。

Libjingle P2P支持以下兩種策略模式：

(1)ICEPROTO_GOOGLE, Google自己的ICE控制策略；

(2)ICEPROTO_RFC5245，標準的ICE控制策略；

以上我們已經(jīng)介紹過RFC5245標準ICE的探測流程和控制策略，下面我們重點介紹Google的ICE控制策略(下面我們統(tǒng)一用gice表示)；

在gice中一個P2P連接包含有兩個通道：探測通道(The session negotiation channel) 和 數(shù)據(jù)通道(The data channel)；前置顧名思義主要負責ICE探測流程，而后者則是有效數(shù)據(jù)的傳輸通道(audio, video, files, etc)；如下圖5-1所示：

圖 5-1 gice P2P連接通道描述

gice整個P2P測試會話建立流程可以用圖5-2描述：

圖 5-2 gice P2P測試會話建立流程描述

由以上流程可以可知，gice的地址收集過程與RFC5245標準的ICE策略是一致的，而不同點主要體現(xiàn)在以下幾點：

(1)sdp 中ice信息不攜帶candidate信息；

gice中不管是請求消息(sdp1 ice1)，還是應(yīng)答消息(sdp2 ice2)，它們ice內(nèi)容都只包含ice-ufrag和ice-pwd，而candidate信息是由專門的消息進行發(fā)送的(在libjingle提供的測試程序中，一個candidate消息只攜帶一條地址信息，candidate信息是按照優(yōu)先級發(fā)送的，優(yōu)先級最高的最先發(fā)送)，這樣做一方面是為了能動態(tài)實時地將本地的最新地址信息通知對方；另一方面也加快雙方探測啟動過程,一定程度上減少了探測流程；

(2)不僅能動態(tài)實時調(diào)整最佳路徑，且雙方不受角色限制；

圖中陰影部分是一個持續(xù)過程，探測貫穿于整個會話中，只要新的探測結(jié)果優(yōu)于當前路徑，則立即進行最優(yōu)路徑切換；這里需要說明的是，gice不受角色控制，也就是說雙方都可以獨立選擇本端最好的通訊路徑；

(3)最優(yōu)路徑?jīng)Q策；

Gice最優(yōu)路徑選擇策略主要從以下幾個方面考慮：

A. Compare first on writability and static preferences.(讀寫能力，優(yōu)先級別)

B. Otherwise, sort based on latency estimate.(rtt時間)

C. new_conn->rtt() <= cur_conn->rtt() + kMinImprovement(kMinImprovement = 10ms)

注：gice相比RFC5245標準，在STUN探測信令字段上有做相應(yīng)的優(yōu)化，這里我們只關(guān)注ice決策固不做特別說明；

3.2Pjsip策略方案描述

只支持RFC5245標準的ICE策略(詳見5.3(1)中策略描述)。

3.3我司策略方案描述

由于我司使用的RTPP媒體中轉(zhuǎn)服務(wù)器不支持TURN協(xié)議(VPS+RTPP替代TURN服務(wù)器），因此中轉(zhuǎn)地址作為默認有效地址對，不參與ICE探測，其優(yōu)先級別最低；結(jié)合我司目前網(wǎng)絡(luò)架構(gòu)及實際運用場景，pjsip項目中ICE功能完善，模塊獨立可移植性好，庫的大小比較適合移動平臺，因此在PJSIP ICE架構(gòu)上提出兩種策略模型：支持動態(tài)切換和不支持動態(tài)切換；

(1)不支持動態(tài)切換策略

我司目前組件架構(gòu)主要由USCRTC-TGO、USCRTC-UGO、USCRTC-VOGO、USCRTC-VIGO四個庫組成；其中USCRTC-TGO、USCRTC-UGO是協(xié)議庫，USCRTC-VOGO、USCRTC-VIGO是音視頻引擎庫；結(jié)合ICE原理可知ICE信息交互需承載在USCRTC-TGO與USCRTC-UGO協(xié)議庫上，而多媒體數(shù)據(jù)通道則主要由USCRTC-VOGO、USCRTC-VIGO自己管理和維護。

因此在不考慮通話過程中動態(tài)切換多媒體數(shù)據(jù)通道鏈路的話，則此時ICE作為一個獨立的模塊，功能僅僅是完成P2P探測任務(wù)，其結(jié)果是返回一個有效的通訊鏈路(有效是指能保證正常通訊需求，有可能是P2P鏈路，也有可能是中轉(zhuǎn)鏈路)，結(jié)果一旦確定，ICE就立即釋放P2P會話資源，最終的多媒體數(shù)據(jù)鏈路由USCRTC-VOGO、USCRTC-VIGO根據(jù)ICE結(jié)果創(chuàng)建管理和維護；具體流程描述如下：

圖 5-3 P2P呼叫流程描述(不支持動態(tài)切換)

A)首先，初始化ICE模塊時啟動地址收集，完成本地候選地址收集任務(wù)；

B)當發(fā)起呼叫時，UGo從ICE模塊獲取本地ICE會話信息(ice認證信息和候選地址)；

C)將ICE會話信息封裝到呼叫請求SDP(圖中sdp1 ice1)中，經(jīng)sipex服務(wù)器轉(zhuǎn)發(fā)，此 時sdp中默認媒體地址和端口被服務(wù)器替換為中轉(zhuǎn)服務(wù)器RTPP地址(圖中sdp2 ice1)；

D)當被叫方收到呼叫請求時，從消息中獲取出ICE會話信息以及中轉(zhuǎn)地址(sdp2中的 RTPP地址)，并配置到本端ICE模塊中完成遠端ICE信息收集過程，同時被叫方也類 似執(zhí)行B)、C）步驟將本地ICE信息通過應(yīng)答消息發(fā)送給主叫方；

E)主叫接收到應(yīng)答消息后,類似執(zhí)行D)步驟完成遠端ICE信息收集過程；

F)任何一方一旦完成候選地址配對，則立即啟動ICE探測過程；

G)ICE完成所有媒體通道探測后，返回探測結(jié)果(注：探測成功則返回有效P2P地址對， 否則使用默認中轉(zhuǎn)服務(wù)器RTPP地址)；

H)UGO獲取到ICE返回地址對信息后，首先刪除釋放ICE會話資源，發(fā)送ice通知請 求給服務(wù)器，然后根據(jù)返回ICE結(jié)果信息啟動VOGO、VIGO會話，完成媒體通道建立；

最優(yōu)路徑?jīng)Q策：

A.探測流程使用快速提名方式(按照優(yōu)先級高到低探測，一旦探測成功則停止后續(xù) 探測流程)；

B.使用RFC5245標準ICE決策（即由control方根據(jù)地址對優(yōu)先級確定）；

(2)支持實時動態(tài)切換策略

該模式下地址收集交互流程與（1）相同，不同的是需要VOGO、VIGO的Transport使用外部擴展模式，即由ICE管理維護媒體通道，VOGO、VIGO使用ICE接口完成媒體數(shù)據(jù)收發(fā)操作；同時ICE探測貫穿在整個會話過程中，從而達到實時更新最佳路徑目的，借鑒gice策略，在標準決策上我們也增加對網(wǎng)絡(luò)RTT延遲時間的判斷；詳細流程如下：

圖 5-3 P2P呼叫流程描述(實時動態(tài)切換)

最佳路徑?jīng)Q策：

A.使用ICE標準探測流程；

B.由control方根據(jù)地址對的RTT值和優(yōu)先級確認；

(3)支持“靜態(tài)”切換策略

所謂的“靜態(tài)”切換策略是指：當ice探測成功情況下，優(yōu)先使用P2P進行通訊傳輸，當RTP丟包率大于一定閥值時（比如ppl>10%），則切換使用RTPP中轉(zhuǎn)方式傳輸，而后不在做傳輸切換。該策略實現(xiàn)比較簡單，ice探測只需要進行一次，無需存在在整個會話中；丟包率閥值可根據(jù)實際運用環(huán)境設(shè)定，整個通話中最多只存在一次通道切換。

最佳路徑?jīng)Q策：

A.使用ICE標準探測流程，探測成功優(yōu)先使用P2P；

B.當丟包率大于一定閥值時，切換為RTPP中轉(zhuǎn)方式；

(4)多媒體通道探測策略

一路會話，主要包括音頻和視頻(當支持視頻情況下)；一個媒體通道(音頻或者視頻通道)一般包括RTP和RTCP兩個傳輸通道；因此一路會話可能存在2~4個傳輸通道，由以上ice探測可知，對于每一個傳輸通道ice都是獨立探測維護的，也就是說一路會話需要進行2~4個傳輸通道探測過程，只有當所有傳輸通道探測完成后，才能得到最終探測結(jié)果。 目前我司一個傳輸通道探測信令重發(fā)超時是100ms，探測信令重發(fā)7次，而后等待16*100ms超時，因此一個傳輸通道探測失敗最多需要消耗7*100ms + 16*100ms = 23*100ms即2.3秒，由于探測信令發(fā)送是采用超時群發(fā)方式，因此一路會話ice探測最多消耗估計時間為2.3s~3s。

在實際運用中RTP和RTCP的傳輸端口是成對的(默認RTCP傳輸端口為RTP端口加1)，業(yè)界慣例絕大部分運用場景也僅僅是提供RTP端口；因此這里我們對RTCP傳輸通道的ICE探測作簡化，只探測音視頻RTP傳輸通道，RTCP傳輸決策與RTP一致，僅僅在端口上做加1處理。(注：RTP傳輸端口范圍在30000~60000 且為偶數(shù))。

4最優(yōu)線路判決方案

根據(jù)我司實際情況，p2p很大程度上可以降低延遲，尤其是在視頻應(yīng)用中，不僅能解決服務(wù)器中轉(zhuǎn)性能問題，對網(wǎng)絡(luò)延時和丟包提供了較好的保證；同時考慮到p2p也存在一定的不足之處，在復雜的網(wǎng)絡(luò)環(huán)境下，最佳路徑往往不是絕對的，需要一個實時探測的方式，動態(tài)調(diào)整切換當前網(wǎng)絡(luò)最佳的路徑，為語音視頻傳輸提供最優(yōu)保證。總上所述方案(2)比較符合我們的需求。

在使用方案2時，這里需要注意幾個問題：

(1) 當p2p成功時，中轉(zhuǎn)服務(wù)器不需要主動釋放資源，組件需要定時1s發(fā)一個續(xù)活PING報文(可以為禁音包或者stun心跳包)。

(2) 我們需要一個執(zhí)行動態(tài)切換的標準，這里我們主要參考兩個參數(shù):RTT值和PPL丟包率；RTT參數(shù)我們可以由ICE定時探測和webrtc neteq模塊中獲取，而PPL參數(shù)則只能借助VoGo中neteq統(tǒng)計參數(shù)；具體切換策略描述如下：

i. 當為直撥呼叫時，不啟用ICE模塊，使用VoGo自帶UDP傳輸。

ii. 當P2P探測失敗，啟用ICE模塊中RTPP中轉(zhuǎn)線路，不啟用ICE探測定時器，不啟用定時動態(tài)切換判斷定時器。

iii. 當P2P探測成功，啟動1s定時PING探測(ping超時則此次RTT累加1000ms)，啟動10s線路切換判斷，30s內(nèi)有兩次判決切換，則執(zhí)行線路切換。

RTT值統(tǒng)計方法:

RTT_RATIO = 3.
_rtt = (RTT_RATIO * oRTT + nRTT) / (RTT_RATIO+1); 其中RTT_RATIO為權(quán)重系數(shù)，oRTT是歷史統(tǒng)計值，nRTT是當前統(tǒng)計值。

切換判決條件:

kMinImprovement = 20ms;
（ping_rtt < me_rtt - kMinImprovement） && （++change_cnt > 1）;其中ping_rtt是空閑線路rtt統(tǒng)計值，me_rtt為當前使用線路rtt統(tǒng)計值；change_cnt為判決切換次數(shù)。

線路切換判斷代碼如下：

/*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統(tǒng)計值
	/*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) 組件在啟用動態(tài)切換方案時，媒體引擎是否使用外部擴展傳輸(即ice傳輸鏈路)，與p2p是否成功有關(guān)；當p2p成功時，則媒體引擎使用ice通道進行媒體傳輸，否則，使用內(nèi)部webrtc提供通道進行媒體傳輸(直撥模式下默認使用webrtc傳輸通道)。

(4) 組件動態(tài)切換方案架構(gòu)如下：

圖 6-1 組件動態(tài)切換架構(gòu)

(5) 呼叫處理流程如下：

圖 6-2 ice呼叫處理流程

5PPL參數(shù)統(tǒng)計方案

當考慮PPL參數(shù)時，由于ICE中沒有對PPL參數(shù)做統(tǒng)計，因此只能根據(jù)neteq統(tǒng)計參數(shù)獲取當前正在使用的線路PPL值，空閑線路沒有有效的統(tǒng)計手段；以下提供兩種參考方案:

方案一：

在ICE模塊中添加對空閑線路PPL參數(shù)的統(tǒng)計方法，而當前使用的線路可由neteq中獲取得到；PPL值與RTT值可以借鑒服務(wù)器智能路由算法得出各個線路的總體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;	
}

優(yōu)點： 能實時有效統(tǒng)計出各個線路的RTT和PPL參數(shù)值，準確性比較高。

缺點： 需要額外在ICE中添加PPL統(tǒng)計模塊，可能需要使用icmp協(xié)議。

方案二：

根據(jù)現(xiàn)有情況，只獲取當前正在使用線路PPL參數(shù)(即neteq中統(tǒng)計參數(shù))，與給定閥值(15%)比對，此時有兩種場景：

(1) 當空閑線路沒有進行過歷史PPL統(tǒng)計參數(shù)記錄時，如果當前線路PPL值大于15%，則立即執(zhí)行線路切換；否則只根據(jù)各個線路統(tǒng)計RTT值，判決是否執(zhí)行切換。

(2) 當各個線路都有進行過歷史PPL參數(shù)統(tǒng)計時，直接根據(jù)RTT與PPL統(tǒng)計算法計算得出各個線路總體delay值，通過對比delay值，判斷是否進行線路切換。

優(yōu)點： 無需額外添加PPL統(tǒng)計模塊，實現(xiàn)相對簡單。

缺點： 由于使用的是歷史數(shù)據(jù)參與delay值計算，因此有一定的誤差。

6總結(jié)

本方案消除了現(xiàn)有的UNSAF機制的許多脆弱性。例如傳統(tǒng)的STUN有幾個脆弱點，其中一個就是發(fā)現(xiàn)過程需要客戶端自己去判斷所在NAT類型。另一點脆弱性在于STUN、TURN等機制都完全依賴于一個附加的服務(wù)器，而ICE利用服務(wù)器分配單邊地址的同時，還允許客戶端直接相連，因此即使STUN或TRUN服務(wù)器中有任何一個失敗了，ICE方式仍可讓呼叫過程繼續(xù)下去。此外，傳統(tǒng)的STUN最大的缺陷在于它不能保證在所有網(wǎng)絡(luò)拓撲結(jié)構(gòu)中都正常工作，最典型的問題就是Symmetric NAT。對于TURN或類似轉(zhuǎn)發(fā)方式工作的協(xié)議來說，由于服務(wù)器的負擔過重，很容易出現(xiàn)丟包或者延遲情況。而ICE方式正好提供了一種負載均衡的解決方案，它將轉(zhuǎn)發(fā)服務(wù)作為優(yōu)先級最低的服務(wù)，從而在最大程度上保證了服務(wù)的可靠性和靈活性。

本方案實際運用過程中需要注意以下問題：

1. ICE算法本身來看，雙方收集到的候選地址越多，算法越容易成功，但同時也增加了探 測過程，導致會話建立時間延長，因此需要結(jié)合實際環(huán)境合理限制候選地址個數(shù)。

2. 在網(wǎng)絡(luò)延遲丟包情況下，有可能存在對優(yōu)先級更高的候選對發(fā)送的探測包丟包，導致最 終選擇優(yōu)先級較低配對的情況，因此需要結(jié)合實際選擇是否進行多次探測或重復發(fā)包過 程。

3. ICE算法本身要求會話雙方明確自己角色，也就是說會話參與者中必須一方作為控制方， 另一個作為受控方，不允許雙方都處于相同角色，因此類似第三方控制建立的會話場合 不適合本方案。

4. 本方案是基于使用SDP協(xié)議承載ICE屬性字段的，暫不支持私有協(xié)議承載。

7參考資料

參考資料列表

8附錄

(1) 常用NAT穿越方案對比表

NAT穿越方案對比

(2) Libjingle 語音會話數(shù)據(jù)流程

Libjingle語音會話數(shù)據(jù)流程

作者：龔火金 （Lion）

版權(quán)歸屬：靈云快智

靈云快智_專注實時音視頻智能硬件場景解決方案,智能手表,智能機器人,智慧社區(qū),企業(yè)通信