在全部署場景中（Full Implementations），初始offer的處理大概需要經過五個主要的步驟：候選地址獲取->候選地址優(yōu)先級處理->移除冗余候選地址->選擇默認候選地址，最后計算發(fā)送SDP offer。下面，筆者將會一步步介紹其中最主要的前四個步驟。

　　首先，筆者介紹一下候選地址獲取或者采集（Gathering Candidates）。在日常生活環(huán)境中，如果我們計劃出去旅游的話，我們一般都會提前準備旅游線路的一些背景資料，例如交通信息，旅游資料方便我們找到最佳的旅游路線，在最低成本的前提下獲得最佳的旅游體驗。同樣，候選地址獲取也是一樣的。當agent之間的通信即將開始時，agent需要獲取候選地址。agent或者offer提供方可以通過操作界面的提示或外部的初始請求來發(fā)起一個offer消息。每個候選地址就是一個傳輸?shù)刂罚�它也包括其類型和base。候選地址的base實際上也是一種候選地址（一個基準地址），當agent使用候選地址時，agent必須從此地址發(fā)送。在RFC5245中，規(guī)范定義了四種候選地址類型，它們分別是host candidates，server reflexive candidates，peer reflexive candidates和relayed candidates。其中，server reflexive candidates是通過STUN或者TURN服務器獲得，relayed candidates是通過TURN服務器獲得，peer reflexive candidates則是通過ICE協(xié)商過程中獲得（它事實上是一種連接性檢查的結果，不做討論）。關于以上四種類型的定義，筆者在前面很多歷史文章中結合一些圖例有一些介紹，這里為了能夠更好配合SDP的介紹，保持關于SDP內容討論的完整性，筆者再花費一點時間重新梳理一次前三種候選地址類型。

　　Host candidates（主機候選地址）是首先需要獲取的地址。主機地址是通過端口和IP地址綁定獲得。這里的IP地址可以此主機所屬的物理網(wǎng)口IP地址，虛擬地址或者VPN地址。agent想調用UDP媒體流的話（也可以通過拓展支持TCP），agent應該獲得本地主機支持的一個候選地址，這個候選地址是針對每個媒體流構件的，這些媒體流通過主機所支持的IP地址來傳輸。agent通過綁定一個具體的IP地址和端口來獲得每個候選地址。每個媒體構件有一個component ID，基于RTP的媒體流，它本身就有一個ID，這個ID是1，RTCP的ID是2。如果agent使用了RTCP的話，它必須獲取一個候選地址；如果agent使用RTP和RTCP的話，agent有k個IP地址的話，它必須以2*K的主機候選地址來最終地址計算方式。針對每個主機候選地址來說，base基準地址是候選地址自己本身。

　　Agent除了需要獲得主機候選地址以外，agent應該獲得Server Reflexive （反射地址）和 Relayed Candidates（轉發(fā)地址）兩種候選地址。讀者注意，這里使用的是應該而不是需要或者必須，使用的要求取決于提供者的環(huán)境變量要求。在有一些使用場景中，Server Reflexive 和 Relayed Candidates都是和公網(wǎng)綁定的，因此agent在一個封閉網(wǎng)絡環(huán)境中，或者從來不連接公網(wǎng)的話，沒有必要使用Server Reflexive 和 Relayed Candidates地址。如果agent支持了雙網(wǎng)絡協(xié)議或者支持多宿主地址的話，agent應該使用全部署方式來處理候選地址。部署TURN服務器的成本是非常高的，需要考慮實際場景。當使用ICE時，agent雙方都在NAT后，它們需要一個地址和端口映射處理時，用戶才需要考慮使用NAT部署。在后續(xù)部署使用過程中，可能一些用戶會把使用NAT地址映射作為一種用戶場景來滿足agent的支持能力，因此，通常這種可選的邊緣處理的用戶場景僅作為一種可選方案，可能也不會經常使用。因此，如果agent不采集Server Reflexive（反射地址） 和 Relayed Candidates（轉發(fā)地址）的話，RFC5245規(guī)范推薦關閉這種部署文件配置。如果將來網(wǎng)絡環(huán)境發(fā)生了變化，agent可以通過配置開啟采集地址的功能。這里再次重復一次筆者前面提到的廢話。如果agent正在采集Server Reflexive（反射地址）和 Relayed Candidates（轉發(fā)地址）的話，agent需要使用TURN服務器。如果agent僅采集反射地址的話，agent使用STUN服務器。部署場景決定以后，agent開始其候選配對的處理流程，agent可以通過界面配置方式或者其他的偵測手段（通常是通過GUI界面配置STUN/TURN服務器地址），通過STUN或者TURN服務器對其每個主機候選地址進行配對。如果已配置好了STUN或者TURN服務器的話，規(guī)范推薦配置一個domain名稱，使用DNS處理流程來發(fā)現(xiàn)STUN服務器和TURN服務器地址。

　　這里的DNS處理流程遵從兩個規(guī)范（RFC5389和RFC5766），分別實現(xiàn)對STURN服務器的查詢和TURN服務器的查詢。其中，查詢STUN服務器地址的流程是通過Service Records （SRV），使用 “stun” 服務來完成的，具體的流程按照RFC 5389的DNS流程實現(xiàn)。查詢TURN服務器地址的流程是通過SRV，使用“turn”服務來完成，具體的流程是按照RFC5766規(guī)范DNS流程實現(xiàn)。在具體的應用場景中，agent可能會通過學習從SRV查詢中獲得多個STUN或者TURN地址。根據(jù)RFC5245規(guī)范的說明，為了提升ICE的處理性能，在一個具體的會話中，對于所有候選地址來說，agent應該僅使用單個STUN或者TURN地址。查詢的結果就是通過STUN或TURN服務器的一系列主機候選配對。agent然后從一系列配對中選擇一個配對，從主機候選地址對STUN或者TRUN服務器端發(fā)送綁定或分配請求。特別注意，對STUN服務器來說，發(fā)送綁定請求是不需要簽權的，響應中任何服務器屬性（ALTERNATESERVER）都會被忽略掉，同時agent必須支持向后兼容的模式支持綁定請求（Binding request），此綁定請求在RFC5389中說明。分配請求（Allocate requests）應該需要通過簽權認證流程，agent端可以設定一定的安全機制來實現(xiàn)簽權流程。

　　在ICE采集候選地址階段，ICE設置了一個定時器（Ta），每Ta毫秒后，agent就會生成一個新的STUN或TURN事務。這個事務可以是針對前一個事務的重試，在這個新事務中可以攜帶一定的錯誤消息（例如，認證錯誤）。這個事務也可以是一個新的事務，新的事務可支持新的主機候選配對和STUN/TURN服務器配對。為了保證其ICE采集流程的穩(wěn)定性，不影響其他定時器的使用（例如，STUN重傳定時器RTO的），agent不應該在每Ta毫秒內過于頻繁生成新的事務。關于這兩種定時器的使用方式，我們在后續(xù)章節(jié)會涉及，這里不再深入討論。發(fā)送了綁定請求或分配請求后，agent將會收到一個綁定或分配請求的響應消息。如果收到的是一個成功的分配響應消息的話，消息中會包含Server Reflexive地址（反射地址，從映射地址中獲得） 和 Relayed Candidates（轉發(fā)地址）。其中，轉發(fā)候選地址是在響應消息的XOR-RELAYED-ADDRESS屬性設置中。如果分配請求被拒絕的話，那是因為服務器端沒有可提供的資源來支持這個請求，agent應該對服務器端發(fā)送一個綁定請求來獲得反射候選地址，綁定請求將會對agent提供一個反射候選地址（也是從映射地址中獲得）。反射候選地址的基準地址是一個主機候選地址，這個主機候選地址是發(fā)送綁定請求和分配請求的地址。轉發(fā)候選地址的基準地址是候選地址本身。對主機候選地址來說，如果轉發(fā)候選地址是確認狀態(tài)（很少發(fā)生的極端情況），那么，這個轉發(fā)候選地址必須要丟棄。

　　除了采集反射候選地址和轉發(fā)候選地址以外，最后，agent還要對每個候選地址分配一個foundation。Foundation是一個身份標識符，它在會話中使用。Foundation ID 用來決定兩個候選地址是否相同。計算foundation目前沒有特定的說法，它僅針對配對的計算，保持其唯一性。如果要保證兩個候選地址具有相同foundation ID的話，以下四個條件需要都為真：

　　采集到反射候選地址和轉發(fā)地址以后，為了保證ICE的正常工作，這種綁定關系需要一定的維護機制來保證此地址的連接性。因此，反射地址和轉發(fā)地址一旦分配以后，這些地址必須保持一個存活狀態(tài)。在后續(xù)章節(jié)中，筆者將繼續(xù)介紹關于釋放候選地址話題。對于通過綁定請求學習到的反射候選地址來說，這種綁定關系必須通過對服務器端發(fā)送其他的額外請求才能繼續(xù)維持。分配請求可以通過刷新事務的方式來實現(xiàn)，具體的處理方式，讀者可以參考RFC5766-7章節(jié)。刷新請求也同樣刷新了反射候選地址。

　　到此為止，筆者討論了采集候選地址所關注的幾個主要話題（主機候選地址，反射地址，轉發(fā)地址，foundation計算和候選地址的狀態(tài)維護）。接下來，筆者將繼續(xù)討論關于針對候選地址優(yōu)先級排序以及其計算方式和指導原則。

　　為了保證ICE的傳輸取得最佳的性能，候選地址需要進行優(yōu)先級的處理。優(yōu)先級處理針對每個候選地址指定了一個優(yōu)先級標識。傳輸媒體流的每個候選地址必須有一個唯一的優(yōu)先級，此優(yōu)先級必須是一個正數(shù)，取值范圍在1到（2**31 - 1）之間。ICE將使用此優(yōu)先級取值來決定檢查連接性的依據(jù)，和對候選地址進行修改偏好的選擇參數(shù)。Agent將使用計算公式來計算其優(yōu)先級，計算公式所使用的參數(shù)根據(jù)規(guī)范的指導原則進行。如果agent使用不同的計算公式的話，雙方agent對連接性檢查流程可能出現(xiàn)不協(xié)調的情況，因此，ICE將會耗費更長的時間匯聚數(shù)據(jù)交互。下面，筆者將針對計算公式和具體的指導原則進行說明。

　　通過以上公式可以看出，使用格式計算優(yōu)先級時，永久性的結果計算關聯(lián)了三個主要的參數(shù)（針對每個候選地址類型的偏好，本地IP地址和component ID）。其中，每個候選地址類型的偏好取決于候選地址的類型（host candidates，server reflexive candidates，peer reflexive candidates和relayed candidates）。如果agent是一臺多宿主的主機，其偏好取決于主機的IP地址。類型偏好（type preference）必須是整數(shù)，取值范圍從0到126范圍內，表示四種候選地址的偏好。126是最高偏好取值，0是最低偏好取值。如果對候選地址類型的偏好設置為0，則表示這個類型的候選地址將為最后的一種選擇。同樣類型偏好的候選地址必須要確認其相同性，不同的類型偏好的也需要確認其不同。以上四種候選地址類型的優(yōu)先級也具有不同的判斷級別。其中，peer reflexive candidates的類型偏好優(yōu)先級必須高于其他反射候選地址類型偏好。本地偏好（local preference）必須是整數(shù)，取值范圍從0到65535范圍內。它表示的偏好是針對具體的IP地址的，從這個具體的IP地址獲得候選地址，agent是一臺多宿主主機。65535是最高偏好取值，0是最低偏好取值。當本地主機只有單個IP地址時，偏好取值應該設置為65535。通常情況下，如果針對一個具體的媒體流的特別構件支持了多個候選地址的話，此特別構件的多個候選地址具有相同的類型的話，針對每個候選地址的本地偏好必須是唯一的。在RFC 5245規(guī)范中，以上這種情況僅發(fā)生在多宿主主機環(huán)境中。因為多宿主主機是一個雙棧主機，本地偏好應該等同于IP地址的優(yōu)先值。關于優(yōu)先值的取值讀者可以參考RFC3484-2.1，因為現(xiàn)在很多場景中已經部署了IPv6,，因此，可能在某些場景中，IPv6的優(yōu)先級高于IPv4的優(yōu)先級。具體的優(yōu)先值計算取決于具體的場景中。component ID是候選地址的component ID，它的取值范圍必須在1到256之間。介紹完計算公式以后，筆者接下來需要討論選擇類型偏好和本地偏好的四個指導原則或標準。

　　第一個指導原則是選擇類型偏好和本地偏好需要根據(jù)一定的標準。類型偏好和本地偏好取值是主要標準，具體來說，就是媒體的中間介質的使用，例如TURN服務器，VPN或者NAT。在使用這些媒體中間介質時，如果媒體發(fā)送到這些介質的候選地址，在收到媒體之前，媒體需要首先被發(fā)送到中間介質的候選地址。轉發(fā)候選地址就是其中一種候選地址類型，它涉及了媒體中間介質。另外一種媒體中間介質就是通過VPN接口獲得的主機候選地址。顯然，當媒體通過媒體中間介質以后，它會增加發(fā)送和接收方之間的時延。同時，因為媒體經過了多個路由器hops，增加了丟包的風險。當然，因為媒體需要進出媒體中間介質的服務器，服務提供商也需要相應增加部署成本。如果用戶覺得筆者前面說的這些因素是非常重要的，因為考慮到這些風險的重要性，轉發(fā)候選地址的偏好設置就應該要低于本地偏好設置。因此，針對偏好取值的取值可能需要做一定的調整。推薦的辦法是，本地候選地址偏好設置為126，反射候選地址偏好設置為100，peer reflexive candidates設置為110，轉發(fā)候選地址的偏好設置為0。進一步說，如果agent是一臺多宿主主機，它本身帶多個IP地址的話，從VPN接口獲得的主機候選地址的本地偏好設置為0。

　　來自于互聯(lián)網(wǎng)資源

　　選擇偏好的第二個指導原則是基于IP組選擇方式。ICE可以在IPv4和IPv6網(wǎng)絡環(huán)境中工作。ICE提供了一種工作機制，可以保證雙棧主機選擇IPv6，但是萬一IPv6網(wǎng)絡出現(xiàn)故障時（例如，在6to4路由器轉發(fā)失敗-RFC3056），它也允許主機回退到IPv4的網(wǎng)絡環(huán)境中。ICE也可以幫助主機獲得原生的IPv6地址和6to4地址。如果是我們以上所說的這種情況的話，相對比較高的本地偏好將會關聯(lián)到IPv6的地址，然后是6to4的地址，最后才是IPv4的地址。這樣安排的目的是允許agent可以馬上優(yōu)先使用原生IPv6地址，如果出現(xiàn)連接問題或者對端agent沒有啟用原生IPv6時，可以退回到6to4的地址繼續(xù)和對端通信。

　　第二個原則選擇偏好的原則是基于主機IP地址的類型。第三個原則是基本上是基于第二個原則的基礎上，針對網(wǎng)絡最重要的問題（安全機制）的選擇。因此，根據(jù)安全機制選擇偏好也是一種非常重要的指導原則。現(xiàn)在國際上很多公司的員工都是遠程辦公（特別是WebRTC終端方式），如果遠程辦公員工提供家庭私人網(wǎng)絡訪問企業(yè)內部網(wǎng)絡時，員工端希望通過企業(yè)內部網(wǎng)絡訪問語音流量，通過企業(yè)通信系統(tǒng)呼出到其他外部目的地。這樣的話，員工私人網(wǎng)絡和企業(yè)網(wǎng)絡之間就需要一個VPN的連接或者SBC的連接（筆者已經介紹過很多關于SBC的使用，這里僅指VPN）。如果是這樣的部署場景的話，和其他后續(xù)地址相比，VPN地址將具有比較高的本地偏好優(yōu)先級。

　　第四個選擇偏好的指導原則是關于網(wǎng)絡拓撲意識。企業(yè)網(wǎng)絡的拓撲設計也是選擇偏好時需要關注的地方。候選地址的處理如果可以靈活地充分利用網(wǎng)絡優(yōu)勢也可以優(yōu)化地址的選擇。對于后續(xù)地址來說，它可以利用其中間介質的多種已存網(wǎng)絡架構實現(xiàn)偏好選擇。在某些網(wǎng)絡環(huán)境中，如果agent可以預設或者動態(tài)發(fā)現(xiàn)中間介質，這些中間代理介質可能是最佳（或最近）的路徑地址包括候選地址的話，agent應該設定此候選地址的本地偏好為比較高的優(yōu)先級。

　　前面，筆者介紹了候選地址采集和候選地址的優(yōu)先級處理。接下來，我們繼續(xù)介紹優(yōu)先級處理以后的另外一個話題，這就是關于候選地址冗余移除的問題。為了保證agent端本身存儲和管理的問題，agent會移除一些冗余的候選地址。如何判斷候選地址是重復或是一個冗余地址呢？根據(jù)RFC5245的說明，如果一個候選地址的傳輸?shù)刂返扔谄渌�候選地址的傳輸?shù)刂罚�并且此候選地址的基準地址等于其他候選地址的基準地址，那么此候選地址就是一個冗余候選地址。另外，如果候選地址的傳輸?shù)刂废嗤�，但是它們的基準地址不同，這些候選地址不是冗余候選地址。很多情況下，當agent沒有在NAT背后時，反射候選地址和主機候選地址是冗余或者重復的，agent應該設置一個比較低的偏好優(yōu)先級移除這些冗余候選地址。

　　采集到候選地址以后，接下來就需要考慮如何設置一個默認的候選地址實現(xiàn)媒體流的進一步傳輸處理。如果一個候選地址被看作是一個默認的候選地址的話，從非-ICE用戶端來說，它將作為一個媒體目標。這個媒體目標稱之為DEFAULT DESTINATION（默認目的地）。如果當agent和一個ICE-aware peer（能夠感知到ICE的遠端）通信時，如果ICE算法沒有選擇候選地址的話，ICE處理流程完成以后，agent要求一個updated offer/answer 來修復或者糾正SDP，這樣的話，媒體默認的目的地地址將會匹配ICE已選的候選地址。當然，如果ICE選擇了默認的候選地址，agent就沒有必要發(fā)送更新的offer/answer。

　　Agent 必須選擇一組候選地址，每個在使用的媒體流的每個構件的一個候選地址作為默認的候選地址。如果端口不是0的話，說明媒體流正在使用其構件端口。這個結論我們在前面的討論中已經說明。接下來處理中，盡管a=inactive狀態(tài)或者bandwidth設置為0，媒體仍然會置于使用狀態(tài)。

　　RFC5245規(guī)范推薦選擇默認的候選地址是基于候選地址的概率，具體來說，這些候選地址和對端peer已經關聯(lián)在一起的概率，或者它們之間的一起工作的概率來決定。規(guī)范推薦的默認候選地址是，轉發(fā)候選地址（如果有轉發(fā)地址的話），反射候選地址（如果有反射候選地址的話）和最后主機候選地址。

　　前面所討論的都是基于全部署場景的內容。輕量級部署（Lite Implementation）相對比較簡單，它僅使用了主機候選地址。輕量級部署必須為每個媒體流的每個構件分配0個或者一個IPv4的地址。輕量級部署它可能分配0個或者一個IPv6地址，但是，主機不能使用多余1個以上的IPv6地址。因為很多時候，每個媒體流的每個構件可以支持多個IPv4候選地址，如果agent支持多個IPv4地址的話，它必須從分配的候選地址中選擇其中一個地址。如果主機支持的雙棧地址的話，RFC5245推薦分配一個IPv4候選地址和一個全局IPv6地址。在輕量級的部署場景中，ICE不能用來動態(tài)選擇一定范圍內的候選地址。在完整的ICE流程中，通過連接性檢查才能真正決定使用這個地址或者那個地址。因此，規(guī)范也不推薦從一個特定的網(wǎng)絡區(qū)域內包含一個以上的候選地址。

　　每個構件/模塊都會設定一個ID，我們稱之為component ID或者模塊ID。對于RTP媒體流來說，RTP自己的ID為1，RTCP為2。如果agent正在使用RTCP的話，它必須首先獲得一個候選地址。

　　每個候選地址會設定一個foundation。兩個從不同IP地址獲得的兩個候選地址，這兩個候選地址的foundation肯定是不同的，如果從相同的IP地址獲得的候選地址的話，foundation看到是相同的。這里的foundation計算方式和全部署場景的要求有所不同（同時也要求檢查端口）。對于優(yōu)先級的計算公式來說，對每個IP地址來說僅依靠一個簡單的整數(shù)遞增是不夠的。另外，針對同樣的媒體流，在所有候選地址中，每個候選地址必須設定一個唯一的優(yōu)先級標識。優(yōu)先級的計算公式如下：

　　在以上格式中，如果主機僅有IPv4地址的話，IP precedence設置為65535。如果主機是IPv6地址或者是雙棧地址的話，IP precedence應該是RFC3484中的precedence值。

　　接下來，agent將會為每個媒體流的每個構件選擇一個默認的候選地址。如果主機地址僅支持IPv4地址，主機將僅對每個媒體流的每個構件選擇一個候選地址，因此，這個候選地址是默認地址。如果主機支持支持IPv6或者雙棧地址，默認地址的選擇取決于本地策略。默認候選地址的可能是一個經常用來和對端peer通信的候選地址（參考前面章節(jié)的第四種指導原則）。簡單來說，默認候選地址更多傾向于使用以前和對端通信成功的候選地址。如果主機僅支持IPv6的地址，那就是全局的IPv6地址。對支持雙棧的主機來說，RFC5245規(guī)范推薦使用IPv4地址作為默認候選地址。

　　關于SDP的解碼處理流程，全局部署場景和輕量級的部署場景的流程是一樣的。Agent將針對每個媒體包含一個m行來表示它將要使用這個媒體。SDP中的媒體順序和ICE相關。ICE將首先執(zhí)行連接性檢查第一個m行檢查，接下來媒體流會進行傳輸。如果有媒體流的話，首先agent將媒體流置于SDP中，然后處理最重要的媒體流。

　　針對每個媒體流，每個候選地址將設置一個候選地址屬性。關于此屬性的構建需要遵從一定的規(guī)則，具體的規(guī)則參考RFC5245-15。屬性將會負責傳遞IP地址和端口和候選地址所使用的傳輸協(xié)議，另外還有配合對端工作的ICE的一些屬性：priority，foundation和component ID。除了以上這些屬性參數(shù)因為，屬性中還提供了關于候選地址的問題排查和其他函數(shù)功能，例如，候選地址類型和相關的傳輸?shù)刂贰?/div>