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

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

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

List of abbreviations 縮略語清單：

Table 1 縮略語列表

1簡(jiǎn)介

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

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

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

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

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

2.1現(xiàn)有NAT類型

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

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

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

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

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

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

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

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

2.2基本組成

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

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

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

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

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

STUN（Simple Traversal of UDP over NATs）是指NAT 的UDP簡(jiǎn)單穿越；實(shí)際運(yùn)用中配合完成NAT類型檢查及連通性驗(yàn)證,并提供3個(gè)擴(kuò)展屬性:USE-CANDIDATE, ICE-CONTROLLED 和ICE-CONTROLLING。

4.RTPP服務(wù)器

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

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

2.3ICE算法流程

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

圖 1-0 ICE算法流程圖

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

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

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

會(huì)話發(fā)起者獲得一組傳輸?shù)刂泛?，將在本地地址和外部地址上啟?dòng)STUN服務(wù)器用來使會(huì)話應(yīng)答方能夠判斷地址的可達(dá)性。客戶端將在每個(gè)本地傳輸?shù)刂飞贤瑫r(shí)接受STUN請(qǐng)求包和媒體包，所以發(fā)起者需要對(duì)STUN消息與媒體流協(xié)議進(jìn)行區(qū)分，在RTP和RTCP中實(shí)現(xiàn)這個(gè)并不難，因?yàn)镽TP與RTCP(詳見RFC3550/RFC 1889 )包總是以0b10(v=2)打頭，而STUN(詳見RFC3489)是0b00。

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

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

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

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

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

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

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

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

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

(2) 發(fā)送檢查每個(gè)優(yōu)先級(jí)對(duì)

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

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

7.最佳候選對(duì)提名

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

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

圖1-1 完整提名

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

圖 1-2 快速提名

3信令格式

3.1"candidate"屬性

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

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

2ICE工作流程描述

本文將通過一個(gè)測(cè)試仿真環(huán)境來展示ICE算法的工作流程。由于ICE算法處理RTP和處理RTCP流程相同，以下主要以對(duì)RTP媒體流處理流程進(jìn)行講解。這里假設(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，同時(shí)在公網(wǎng)上架設(shè)服務(wù)器務(wù)器上運(yùn)行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ò)拓?fù)?/span>圖如圖1-3所示：

圖 1-3 仿真網(wǎng)絡(luò)拓?fù)鋱D

2.1地址收集過程

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

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

表1 A端地址映射表

A收集到本端所有候選地址后，計(jì)算出每個(gè)候選地址優(yōu)先級(jí)，并生成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ù)收集到的地址，生成對(duì)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

當(dāng)A和B雙方都接收到對(duì)方候選地址列表時(shí)，此時(shí)已完成所有地址收集工作，接著雙方將本端候選地址與遠(yuǎn)端候選地址進(jìn)行配對(duì)(Candidate Pair),并按照優(yōu)先級(jí)排序，生成連通性候選對(duì)檢查表,如表3所示:

表3 候選對(duì)映射地址表

候選配對(duì)優(yōu)先級(jí)計(jì)算方法為如下( G為控制方候選項(xiàng)優(yōu)先級(jí) D為受控方候選項(xiàng)優(yōu)先級(jí)):

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

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

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

• 雙方為non-symmetric NAT。
• 一方為symmetric NAT，一方為non-symmetric NAT，一方為Full Cone NAT。
• 一方方為symmetricNAT，一個(gè)方為非Full Cone NAT。

(1) non-symmetric NAT

測(cè)試流程如圖1-6所示。

圖1-6 non-summetric下測(cè)試過程

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

(2)一方為symmetric NAT

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

圖1-7 A處于symmetric NAT下測(cè)試過程

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

(3)雙方為symmetric NAT

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

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

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

2.3映射與會(huì)話超時(shí)

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

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

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

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

3ICE策略方案

3.1Libjingle策略方案描述

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

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

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

(2)ICEPROTO_RFC5245，標(biāo)準(zhǔn)的ICE控制策略；

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

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

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

gice整個(gè)P2P測(cè)試會(huì)話建立流程可以用圖5-2描述：

圖 5-2 gice P2P測(cè)試會(huì)話建立流程描述

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

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

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

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

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

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

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

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

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

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

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

3.2Pjsip策略方案描述

只支持RFC5245標(biāo)準(zhǔn)的ICE策略(詳見5.3(1)中策略描述)。

3.3我司策略方案描述

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

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

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

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

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

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

B)當(dāng)發(fā)起呼叫時(shí)，UGo從ICE模塊獲取本地ICE會(huì)話信息(ice認(rèn)證信息和候選地址)；

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

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

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

F)任何一方一旦完成候選地址配對(duì)，則立即啟動(dòng)ICE探測(cè)過程；

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

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

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

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

B.使用RFC5245標(biāo)準(zhǔn)ICE決策（即由control方根據(jù)地址對(duì)優(yōu)先級(jí)確定）；

(2)支持實(shí)時(shí)動(dòng)態(tài)切換策略

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

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

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

A.使用ICE標(biāo)準(zhǔn)探測(cè)流程；

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

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

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

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

A.使用ICE標(biāo)準(zhǔn)探測(cè)流程，探測(cè)成功優(yōu)先使用P2P；

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

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

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

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

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

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

在使用方案2時(shí)，這里需要注意幾個(gè)問題：

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

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

i. 當(dāng)為直撥呼叫時(shí)，不啟用ICE模塊，使用VoGo自帶UDP傳輸。

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

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

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

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

切換判決條件:

kMinImprovement = 20ms;
（ping_rtt < me_rtt - kMinImprovement） && （++change_cnt > 1）;其中ping_rtt是空閑線路rtt統(tǒng)計(jì)值，me_rtt為當(dāng)前使用線路rtt統(tǒng)計(jì)值；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)計(jì)值
	/*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) 組件在啟用動(dòng)態(tài)切換方案時(shí)，媒體引擎是否使用外部擴(kuò)展傳輸(即ice傳輸鏈路)，與p2p是否成功有關(guān)；當(dāng)p2p成功時(shí)，則媒體引擎使用ice通道進(jìn)行媒體傳輸，否則，使用內(nèi)部webrtc提供通道進(jìn)行媒體傳輸(直撥模式下默認(rèn)使用webrtc傳輸通道)。

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

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

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

圖 6-2 ice呼叫處理流程

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

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

方案一：

在ICE模塊中添加對(duì)空閑線路PPL參數(shù)的統(tǒng)計(jì)方法，而當(dāng)前使用的線路可由neteq中獲取得到；PPL值與RTT值可以借鑒服務(wù)器智能路由算法得出各個(gè)線路的總體delay值，具體計(jì)算公式如下：

/*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)點(diǎn)： 能實(shí)時(shí)有效統(tǒng)計(jì)出各個(gè)線路的RTT和PPL參數(shù)值，準(zhǔn)確性比較高。

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

方案二：

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

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

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

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

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

6總結(jié)

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

本方案實(shí)際運(yùn)用過程中需要注意以下問題：

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

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

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

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

7參考資料

參考資料列表

8附錄

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

NAT穿越方案對(duì)比

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

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

作者：龔火金 （Lion）

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

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