KVS WebRTC

本篇文章的目標

這篇文章想要用精簡的方式描述如何成功使用 KVS WebRTC 建立 WebRTC 連線
方便自己日後複習，也讓想使用這服務的人在閱讀官方文件前先建立基本觀念

建議繼續看下去之前，先閱讀《NAT 穿透是如何工作的：技术原理及企业级实践》的 1 ~ 6 章，以及 7.8 章

KVS WebRTC 提供什麼、解決了什麼

• Signaling channel：一個可以交換資訊的管道，提供想直接連線的客戶端可以透過它交換 SDP Offer、SDP Answer，以及他們各自的 IP、Port

• Ice server：包含以下兩者

• STUN：讓客戶端可以獲得自己連到網際網路時用的 IP、Port

• TURN：客戶端之間無法直連時，TURN Server 可以當作替代方案，中轉客戶端之間的流量

事前設定

• 一個有足夠權限的 AWS 帳號

  • 可以建立 IAM Role

  • 可以執行 STS AssumeRole

  • 可以建立 KVS Signaling Channel

• Debug 工具

  • Chrome 的 about:webrtc

  • Firefox 的 about:webrtc

• SDK

  • 請到這個頁面下載您可以使用的SDK

連線流程介紹

建立 Signaling Channel

Signaling Channel 有角色區別，分為 Master、Viewer
每個頻道只能有一個 Master，但能有十個 Viewer
比如我們有一個監視器，監視器適合當 Master，並讓最多 10 個 Viewer（客戶端）連進去交換連線資訊

因此有幾個監視器，就要建立幾個 Signaling channel

建立完成後，每個 Signaling channel 有名稱、ARN、Tag 等資訊供後續使用

連線到 Signaling Channel

Master、Viewer 要各自完成的步驟：

1. 用各種方式取得臨時金鑰

• STS AssumeRole：由後端幫已檢驗過的使用者申請金鑰

• IoT Core Credential Provider：用 x509 憑證兌換金鑰

• Cognito Identity Pool：我聽過但沒用過

2. 用 SDK 執行 GetSignalingChannelEndpoint() 取得後續 API 要用的 Endpoint，會取得 HTTPS、WSS 兩種

3. 用 SDK 執行 GetIceServerConfig() 取得 Ice server 資訊

4. 用 SDK 連線到第二步取得的 WSS Endpoint

在兩個客戶端間建立連線

承上，Master、Viewer 各自對 WSS Endpoint 建立 WebSocket 連線，並大致按照下列順序交換連線資訊，並嘗試連線

參考

• Signaling and video calling：這篇文章裡面的連線流程圖比我詳細很多，在開發時值得參考，但有部分流程跟我不一樣

• BlogGeek.me – Trickle ICE：本篇文章的「先交換 Offer、Answer 然後才交換 Ice candidate」的做法叫做 Trickle ICE

• WebRTC for the curious：這個網站針對 WebRTC 的每個部分有深入的解釋，適合想要特地研究某部分的人閱讀