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時表明媒體流在使用。
建議根據對端連接配接的可能性來選擇預設候選。建議預設候選順序：中繼位址，伺服器自反位址，主機候選位址