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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　每個(gè)構件/模塊都會(huì )設定一個(gè)ID，我們稱(chēng)之為component ID或者模塊ID。對于RTP媒體流來(lái)說(shuō)，RTP自己的ID為1，RTCP為2。如果agent正在使用RTCP的話(huà)，它必須首先獲得一個(gè)候選地址。

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

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

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

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

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

　　基于agent之間的STUN連接性檢查中使用的認證方式是短期認證機制，具體關(guān)于認證的處理在規范RFC5389中定義。相對于短期認證方式，RFC5389還定義了長(cháng)期認證的方式。短期認證設定了一個(gè)時(shí)間限定，它僅在每個(gè)時(shí)間范圍內有效。長(cháng)期認證是通過(guò)訂閱的方式實(shí)現認證。RFC5389-10章節有非常完整的介紹，讀者可以查閱此章節細節獲得更多內容。短期認證的處理機制是依賴(lài)于終端和服務(wù)器端之間通過(guò)協(xié)議使用用戶(hù)和密碼交互的方式實(shí)現。在ICE部署場(chǎng)景中，終端和服務(wù)器端則通過(guò)offer/answer的模式進(jìn)行交互。安全用戶(hù)名稱(chēng)是agent用戶(hù)名稱(chēng)，通過(guò)冒號隔離。每個(gè)agent為了發(fā)送和接收消息，它使用密碼來(lái)計算消息的完整性。用戶(hù)名稱(chēng)和用戶(hù)密碼的交互通過(guò)ICE的ice-ufrag和ice-pwd屬性來(lái)實(shí)現。用戶(hù)名稱(chēng)和密碼是為了保證其終端的認證以外，用戶(hù)名稱(chēng)還有另外一個(gè)重要作用。Agent為了提供了針對媒體的安全設置，用戶(hù)名稱(chēng)提供了針對媒體流的歧義和相關(guān)性檢查。關(guān)于STUN用戶(hù)名稱(chēng)的重要性的討論，讀者可以查閱RFC5245-B.4附錄內容。

　　如果agent是一個(gè)輕量級的部署終端的話(huà)，agent必須在SDP中包含一個(gè)“ice-lite”的會(huì )話(huà)級屬性。如果agent是全場(chǎng)景部署的終端的話(huà)，則一定不要包含此屬性。

　　在SDP中添加默認的候選地址作為一個(gè)默認媒體目的地地址。RTP和RTCP的添加方式有所不同。如果媒體是基于RTP的媒體的話(huà)，把RTP候選地址中的IP地址和端口存入SDP中的c行和m行來(lái)完成。如果agent使用了RTCP的話(huà)，它必須使用a=rtcp屬性對RTCP候選地址進(jìn)行解碼。具體RTCP的解碼參考RFC3605-2.1章節。如果agent沒(méi)有使用RTCP的話(huà)，agent必須說(shuō)明未使用RTCP，具體的說(shuō)明方式是通過(guò)b=RS:0和b=RR:0來(lái)表示。此SDP拓展是在RFC3556-2章節中聲明。

　　當agent和一個(gè)非ICE端進(jìn)行通信時(shí)，傳輸地址將是默認媒體目的地地址的話(huà)，這個(gè)傳輸地址必須作為候選地址出現在SDP中，可以以一個(gè)或者多個(gè)a=candidate行來(lái)表示。

　　ICE可提供拓展支持，拓展實(shí)現方式可通過(guò)在offer或answer中包含一系列的令牌來(lái)實(shí)現，agent使用其令牌可以確認ICE的拓展。具體來(lái)說(shuō)，如果agent支持ICE拓展，它必須包含一個(gè)令牌，使用此令牌定義這個(gè)拓展，令牌定義在SDP中使用ice-options選項屬性。以下是一個(gè)具體的包含ICE消息的SDP示例：

　　v=0

　　o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1

　　s=

　　c=IN IP4 192.0.2.3

　　t=0 0

　　a=ice-pwd:asd88fgpdd777uzjYhagZg

　　a=ice-ufrag:8hhY  // agnet 用戶(hù)名稱(chēng)

　　m=audio 45664 RTP/AVP 0

　　b=RS:0  // 使用全部署場(chǎng)景

　　b=RR:0

　　a=rtpmap:0 PCMU/8000

　　a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host

　　a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr

　　10.0.1.1 rport 8998

　　一旦agent已發(fā)送了offer或者answer消息，它必須準備接收在每個(gè)候選地址上的STUN和媒體數據包。在全部署場(chǎng)景和輕量級部署場(chǎng)景中，媒體發(fā)送的流程有一定區別，更多關(guān)于不同部署場(chǎng)景中發(fā)送媒體包的討論將在后續文章中做介紹。媒體包可被發(fā)送到一個(gè)候選地址中，此候選地址是在以前的offer或answer消息中出現的媒體默認目的地地址。

　　筆者通過(guò)以上章節的內容，重點(diǎn)介紹了發(fā)送初始化offer的一些流程，主要包括三個(gè)部分的內容，其中包括了全部署場(chǎng)景中的要求（采集候選地址，候選地址排序，移除冗余候選地址，選擇默認候選地址），輕量級部署要求，SDP解碼。

　　在下一個(gè)章節中，筆者將介紹接收初始化offer的處理流程。

　　https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39

　　https://www.rfc-editor.org/rfc/rfc5245

　　https://www.rfc-editor.org/rfc/rfc8445

　　https://www.rfc-editor.org/rfc/rfc3264

　　關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享

　　Asterisk freepbx FreeSBC技術(shù)文檔： www.freepbx.org.cn

　　融合通信/IPPBX商業(yè)解決方案：www.hiastar.com

　　如何使用FreeSBC，qq技術(shù)分享群：334023047