WebRTC ICE 狀態與提名處理

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

大家都知道奧斯卡有提名,其實在 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 作為實際的通道。

真實案例:
WebRTC ICE 狀態與提名處理

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。
WebRTC ICE 狀態與提名處理

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

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