Scene

分析一個問題時候遇到這樣的場景：服務端一個 Candidate，客戶端三個不同優先級的 Candidate，但是最後居然選擇了一個優先級最低的 Pair。

服務端有一個 Relay Candidate，端口 50217。

a=candidate:3 1 udp 503316991 11.135.171.187 50217 typ relay raddr 10.101.107.25 rport 40821

客戶端有三個 Candidate，端口 50218（中間優先級），50219（最低優先級），50220（最高優先級）。

Candidate 1:
candidate:592388294 1 udp 47563391 11.135.171.187 50219 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fO75 network-cost 50

Candidate 2:
candidate:592388294 1 udp 48562623 11.135.171.187 50218 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fO75 network-cost 50

Candidate 3:
candidate:592388294 1 udp 49562879 11.135.171.187 50220 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fO75 network-cost 50

但是最後選擇的卻是最低優先級的 Pair，50219。

Remote selected pair: 1:1 592388294 UDP 11.135.171.187:50219 RELAYED

Candidate's Foundation

Candidate 的 Foundation: 這裡先提一下 Foundation，會涉及到 Frozen 狀態。

對於一條相同的信道，可能有不同的 Candidate，比如 Relay Candidate 被發現的時候，就可以生成一個新的 Server Reflexive 類型的 Candidate，但是他們都是基於相同的本地地址（IP，端口）和協議，則可以認為這些網絡是相似的，則他們就會有相同的 Foundation。其中 Foundation 在 SDP 中為第一個字段，即下面例子中的 '7'。

a=candidate:7 1 udp 503316991 11.178.68.36 51571 typ relay raddr 30.40.198.7 rport 55896

ICE States

ICE 主要有以下五種狀態，其中前四種是正常的狀態，第五種狀態 Frozen 涉及到 ICE Frozen Algorithm。

ICE 的五種狀態：

Waiting: 當連通性檢查還沒有開始執行的時候（Binding Request 還沒發送）。
In Progress: 當連通性檢查發送了，但是相應檢查的事務仍在執行中（Binding Request 已發送）。
Successed: 連通性檢查執行完成且返回結果成功（Binding Request 已完成）。
Failed: 連通性檢查執行完成且結果失敗（Binding Request 已完成）。
Frozen: ，所有 Candidate Pair 初始化完成以後就在這個狀態，對於相同的 Foundation（相似的 Candidate），會按照優先級依次選取一個 Pair，Unfreeze，並設置為 Waiting 狀態，其他則保持 Frozen。直到選取的 Pair 完成，才會繼續 Unfreeze 另一個 Pair。

ICE Nomination

ICE 有兩種提名方式：

1.Regular Nomination

對於常規提名，主要工作流程如下：

L                        R
-                        -
STUN request ->             \  L's
<- STUN response  /  check

<- STUN request  \  R's
STUN response ->            /  check

STUN request + flag ->      \  L's
<- STUN response  /  check

Regular Nomination

Controlling 模式下的 Agent 發起 Binding Request，並且收到對端的 Response，同時對端發起的 Connective Check 完成，Controling 一端會再次發出一個攜帶 USE_CANDIDATE 標誌位的 Binding Request，當 Controlled 一端收到了，就接受這次提名。

2.Aggressive nomination

除了常規提名，還有一種比較激進的提名，常規提名中會新增一次握手。

L                        R
-                        -
STUN request + flag ->      \  L's

<- STUN response  /  check
<- STUN request  \  R's
STUN response ->            /  check

Figure 5: Aggressive Nomination

Controlling 模式下的 Agent 發起 Binding Request，但是在這個 Binding Request 中會直接攜帶 USE_CANDIDATE 的標誌位，Controlled 模式下的 Agent 收到了以後就接受這次提名。在激進提名模式下，能節約一次握手過程，但是當多個 Pair 同時接受提名時，會根據這些 Pair 各自的優先級進行選擇，選擇出優先級最高的 Pair 作為實際的信道。

真實案例：

Updating States When Nomination

原文參考

當一個新的提名產生時，會對 ICE 內部狀態進行對應的變化。

當一端的 Binding Request 攜帶了 Use Candidate 的標誌位時，則會產生一次提名（Nomination）。

不管 Controlling 或者 Controlled 模式下的 Agent，處理提名的狀態更新規則建議如下：

如果沒有提名的 Pair，則繼續進行連通性檢查的過程。
如果至少有一個有效的提名:
- Agent 必須刪除該 Component 下的所有 Waiting 狀態和 Frozen 狀態的 Pair。
- 對於 In Progress 狀態下的 Pair，優先級低於當前提名 Pair 優先級的，停止重傳（取消）。
當某一個 Stream 的所有 Compont 都至少擁有一個提名時，且檢查仍然在進行時：
- Agent 必須將該 Stream 標記為已完成。
- Agent 可以開始傳輸媒體流。
- Agent 必須持續響應收到的消息。
- Agent 必須重傳當前仍然在 In Progress 的 Pair（優先級高於當前提名的，不然已經被刪除或者取消）。
當檢查列表中的所有 Pair 都完成時:
- ICE 完成。
- Controlling Agent 根據優先級更新 Offer（貌似 WebRTC 沒有這一步）。
當檢查列表檢查有失敗時:
- 所有 Pair 都失敗時，關閉 ICE。
- 當有某個流的檢查成功時，Controlling Agent 移出失敗的 Pair，並更新 Offer。
- 如果有些檢查沒有完成，則 ICE 繼續。

Scheduling Checks

在描述提名時，還會涉及 ICE 對 Pair 的調度（當有效 Candidate 還在 In Progress 的時候但是其他 Candidate 的 Pair 已經收到 Binding Request）。

這裡只討論 Full，先不描述 Lite 模式。

ICE 的 Checks 分成兩種，Ordinary Checks And Triggered Checks。

Ordinary Checks 是常規的 Pair 的檢查，表示這些 Pair 的檢查是從正常流程中切換過來的狀態的檢查。
Triggered Check 是被動觸發的檢查，當這些 Pair 雖然還處在不可以開始檢查的狀態，但是這時候收到了對端的連通性檢查，這時候會對這個 Pair 進行提速，將其直接放入調度列表。

當 ICE 建立一個 Check List （每個 Stream 一個）後，會對每個 Check List 添加一個定時器，當定時器到來時，會進行如下調度：

注：這裡有點不能理解，整個流程看起來是串行的，激活速度有點慢。

首先調度 Triggered Check 並執行。
若無，調度優先級最高的 Waiting 狀態的 Pair，發送 Request，同時將狀態置為 In Progress。
若無，則從 Check List 中找出優先級最高的 Frozen 狀態的 Pair，Unfreeze 之，併發送 Request，狀態設置為 In Progress。
若無，終止調度。

Case Analyzed

簡單瞭解了 ICE 的流程後，我們迴歸最開始的 Case。

首先看 Add Candidate，三個 Remote Candidate 添加順序不同，依次為 50219，50218，50220，注意，此時 50219 收到了對端的 Binding Request，激進提名，攜帶 USE_CANDIDATE，因此很快執行 Create Permission 並完成，這時候可以開始發送 Binding Request 了，屬於 Triggered Checks 優先調度，發送 Binding Request，並進入 In Progress 狀態。

注：這裡除了本地 Relay 的 Pair，還有和 Turn 通信的本地 Host 類型的 Candidate。

接著在 50219 在其他兩個 Create Permission 還沒完成時候以迅雷不及掩耳之勢完成了 Check，根據 rfc 8.1.2 中的描述，對於不是在 In Progress 狀態的 Pair，都刪除，並不參考其優先級，故最後選擇了 50219 這個優先級最低的 Pair。

「視頻雲技術」你最值得關注的音視頻技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視頻領域一流工程師交流切磋。

WebRTC ICE 狀態與提名處理