RTCIceTransport: state 屬性

Baseline 2024
新推出

自 ⁨2024 年 4 月⁩ 起,此功能可在最新的裝置和瀏覽器版本中執行。此功能可能不適用於較舊的裝置或瀏覽器。

RTCIceTransport 介面中只讀的 state 屬性返回 ICE transport 的當前狀態,因此您可以確定 ICE gathering 程序所處的狀態。

這與 gatheringState 不同,後者僅指示 ICE gathering 當前是否正在進行。它也與 RTCPeerConnection.connectionState 不同,後者聚合了整個連線上每個 RTCRtpSender 和每個 RTCRtpReceiver 所使用的所有 RTCIceTransport 的狀態。

一個字串,其值是以下之一:

"new"

RTCIceTransport 正在收集本地候選地址,或正在等待遠端裝置開始傳送遠端候選地址,或兩者兼有。在此狀態下,尚未開始檢查候選地址以尋找可能可接受的地址。

"checking"

已接收到至少一個遠端候選地址,並且 RTCIceTransport 已開始檢查遠端和本地候選地址的配對,以嘗試識別可用於建立連線的可用配對。請記住,本地候選地址的收集可能仍在進行中,同樣,遠端裝置也可能仍在收集自己的候選地址。

"connected"

已找到並選擇了一個可用的候選地址配對,並且 RTCIceTransport 已使用該配對將兩個對等方連線起來。但是,仍有候選地址配對需要考慮,並且兩個裝置中的一個或兩個裝置上仍可能進行收集。

如果任一對等方決定取消使用選定候選地址配對的同意,transport 可能會從 "connected" 狀態恢復到 "checking" 狀態,如果已無剩餘候選地址可供檢查但一個或兩個客戶端仍在收集候選地址,則可能恢復到 "disconnected" 狀態。

"completed"

Transport 已完成本地候選地址的收集,並收到了遠端對等方傳送的不再發送候選地址的通知。此外,已考慮所有候選地址配對並選擇了一個用於使用的配對。如果所有成功的候選地址配對的同意檢查都失敗,transport 狀態將更改為 "failed"

"disconnected"

ICE 代理已確定此 RTCIceTransport 的連線已丟失。這不是失敗狀態(那是 "failed")。"disconnected" 值表示發生了暫時性問題,已中斷連線,但該問題應能自動解決,而無需您的程式碼採取任何措施。有關更多詳細資訊,請參閱 The disconnected state

"failed"

RTCIceTransport 已完成收集過程,收到了遠端對等方傳送的“不再發送候選地址”的通知,並已完成候選地址配對的檢查,但未能成功找到一個既有效又可獲得其使用同意的配對。這是一個終止狀態,表示無法實現或維持連線。

"closed"

Transport 已關閉,不再響應 STUN 請求。

用法說明

如果發生 ICE 重啟,候選地址收集和連線性檢查過程將重新開始;如果重啟發生在 "completed" 狀態下,這將導致從 "connected" 狀態進行轉換。如果重啟發生在暫時性的 "disconnected" 狀態期間,狀態將轉換為 "checking"

The disconnected state

"disconnected" 是一個暫時性狀態,當兩個對等方之間的連線以 WebRTC 基礎設施可以在連線再次可用時自動糾正的方式失敗時發生。它不是失敗狀態。相反,您可以將 "disconnected" 視為類似於 "checking",但增加了連線曾工作但當前未工作的額外資訊。

每個 使用者代理 和平臺可能都有其自身的觸發 "disconnected" 狀態的場景。可能的原因包括:

  • 連線正在使用的網路介面已離線。
  • 傳送到遠端裝置的 STUN 請求反覆未得到答覆。

當 transport 已完成檢查所有現有候選地址配對但未找到可用的配對,或找到可用配對但因拒絕使用該配對的同意而拒絕時,也可能出現 "disconnected" 狀態。在此情況下,transport 仍將繼續收集候選地址,和/或等待遠端對等方傳送候選地址。

規範

規範
WebRTC:瀏覽器中的即時通訊
# dom-icetransport-state

瀏覽器相容性