WebRTC ICE 狀態與提名處理

阿里雲視訊雲發表於2021-01-13
Web

大家都知道奧斯卡有提名，其實在 WebRTC 的 ICE 中也有提名，有常規的提名，也有激進的提名，而且提名的候選人不一定是最優秀的候選人喔，本文就帶你一探其中玄妙。文章內容主要描述 RFC 5245 中 ICE 相關的狀態和 ICE 提名機制，並結合 libnice(0.14) 版本進行分析。

作者：陣圖，阿里雲開發工程師
審校：泰一，阿里雲高階開發工程師

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。

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

相關文章