上一篇，已經獲取到了ICE服務地址，從返回結果中看，是兩組TURN服務地址。

拿到這些地址有什么用呢？接下來就要說到WebRTC中ICE Agent的作用了，返回的服務地址會傳給WebRTC最終給到ICE Agent。

ICE Agent的作用：

1、收集候選地址（ICE Candidates），包括 host、srflx、relay、prflx：

類型	來源說明
host	本地 WebRTC自己通過系統網絡接口直接獲取的。
srflx	使用 STUN 服務器，發現 NAT 映射后的公網 IP
prflx	在通信過程中由對端反推出的 IP（較少見）
relay	使用 TURN 服務器，提供中繼服務

?2、測試連接性（connectivity checks）：嘗試不同的候選對組合

ICE Agent 通過發送 STUN Binding Request 檢查候選對（candidate pair）的可連通性。

• STUN Binding Request 是 ICE 用來做連接性檢測的標準機制。

• 無論對端 candidate 是哪種類型（host、srflx、relay），只要能夠被訪問，它就可以接收到并響應 STUN 消息。

• 檢查是否連通 = 看是否能收到 STUN Binding Response。

• 雖然 relay 類型的候選地址是由 TURN 服務提供的，但它本質上依然支持 STUN Binding Request 的收發，作為 ICE 的連接性檢測機制的一部分。

3、優選路徑（nominating best candidate pair）：優先使用能直連的、延遲最小的路徑；當直連失敗時，才使用 TURN 中繼。

會按 ICE 優先級 測試連接路徑，比如：

• Host ? Host

• Host ? srflx

• srflx ? srflx

• relay ? relay（最慢，最貴）

通常優先選擇 非中繼的直連鏈路（即 P2P）。

補充說明一下，收集候選地址（candidates）指的是僅收集本端（local）的候選地址，包括 host、srflx、relay，將這些候選地址通過信令通道（比如 SDP）發送給對方，就是說本地收集完成后，WebRTC 應用會通過 SDP（Session Description Protocol） 把這些 candidates 發送給對端。

4、接收。對端候選地址的獲取來自信令過程，對端收集完自己的候選地址后，會通過信令通道傳送過來（在 SDP 中或者通過 trickle ICE 逐步發送），本地 ICE Agent 會接收到這些對端候選，并將其組合成 candidate pairs（候選對）進行連接性檢測。

這時候我對比了一下，iOS app端的打印日志：

[iOS-P2P:2f214551-*****A1100*****] ICE servers retrieved - Count: 3
2025-05-19 15:48:29.611+0800 [Open Stream] ??? INFO className:Channel+Tracker fuction:logP2PEvent(_:details:)  line:25 [iOS-P2P:2f214551-C2E2DA110017952] ICE[1/3] - turn:***-***-***-***.t-*****.kinesisvideo.cn-****-*.amazonaws.com.cn:443?transport=udp, turns:***-***-***-***.t-*******.kinesisvideo.cn-*****-*.amazonaws.com.cn:443?transport=udp, turns:***-***-***-***.t-*******.kinesisvideo.cn-****-*.amazonaws.com.cn:443?transport=tcp
2025-05-19 15:48:29.612+0800 [Open Stream] ??? INFO className:Channel+Tracker fuction:logP2PEvent(_:details:)  line:25 [iOS-P2P:2f214551-*****A1100*****] ICE[2/3] - turn:**-***-***-***.t-********.kinesisvideo.cn-****-*.amazonaws.com.cn:443?transport=udp, turns:**-***-***-***.t-*******.kinesisvideo.cn-****-*.amazonaws.com.cn:443?transport=udp, turns:**-***-***-***.t-*********.kinesisvideo.cn-***-*.amazonaws.com.cn:443?transport=tcp
2025-05-19 15:48:29.613+0800 [Open Stream] ??? INFO className:Channel+Tracker fuction:logP2PEvent(_:details:)  line:25 [iOS-P2P:2f214551-C2E2DA110017952] ICE[3/3] - stun:stun.kinesisvideo.*.amazonaws.com:443

iOS app的日志中是有stun返回的，為什么boto3請求卻沒有返回呢，查了一下：

AWS 的 WebRTC Signaling Channel 默認不提供 STUN Server，只靠 TURN 來確保連接可靠性。

1. AWS 官方設計如此：

   • AWS 的 get_ice_server_config() 接口返回的 IceServerList 默認只包含 TURN server。

   • 這些 TURN server 本身就能提供中繼功能（比 STUN 更通用），AWS 更傾向于提供自己可控的服務。

2. AWS 文檔說明：

   The returned ICE server list contains TURN-only servers. STUN servers are not included in this API.

我問了一下iOS開發同學，確實在本地配置了STUN server：

stun.kinesisvideo.{數字}.amazonaws.com

下一篇：AWS WebRTC：獲取ICE服務地址（part 3）介紹STUN服務和TURN服務的作用。