前言
WebRTC是一個建立在瀏覽器協定上的新技術，讓視訊功能不用再安裝額外套件，便可以實現，而他也可以成為許多創新APP上，非常重要的一環，在搜尋許多文件後，發現網路上不乏許多概念清晰的資源，但較為散落，因此寫這一篇論述一下自己所理解的概念，順便將網路學習資源也都放上來！
WebRTC 重要的三大API
- MediaStream：支持大多數瀏覽器，使用 getUserMedia() 獲取 audio and webcam stream。
- RTCPeerConnection： Caller & Calle 必需互相傳送 Session Description，透過 Session Description Protocol 所定義的 offer 與 answer 來交換多媒體相關的資訊（例如解析度與 codec 等），而此交換的機制稱為 JavaScript Session Establishment Protocol（JSEP）。但由於可能會遇到 NAT 或者 防火牆的關係，因此要靠 ICE 來解決，因此可以使用 Stun/Turn Server來解決，Stun伺服器功能很簡單，就是要讓在 NAT 中的Client取得自己本身公開的 IP/Port，嘗試順序為 UDP -> TCP , Http -> Https ，若直接連線都失敗了，這時後 Turn Server 就會來扮演將全部資料轉送的角色，而前述所提的嘗試順序，會形成不同的連線狀態也稱為 ICE Candidate，然而在進行 p2p 連線時，就會進行這樣的嘗試過程，並在當中選擇最好的 ICE Candidate來使用，而常用的有 google's stun => stun:stun.l.google.com:19302。上述兩者所要最後則要透過信號通道/服務來傳送 RTCPeerConnection 會負責解決其餘的多媒體串流問題。
- RTCDataChannel：可以使兩個 browser 直接傳送檔案，不用再透過Server當作中介。負責一般性資料之傳送。PubNub有提供相關服務：然而WebRTC協定很遺憾地沒有提供儲存機制，但有許多的資料例如：聊天的歷史記錄等等，因此也有像 PubNub 這種公司提供一些付費的Solution來給需要使用的人。
運作流程
- 欲呼叫的原瀏覽器(caller)會提供一個 offer 包含 session description
- 被呼叫的瀏覽器(callee)會接收呼叫者的資訊並且回覆一個 session description
- 呼叫的原瀏覽器(caller)得到呼叫對象的回覆後
- 雙方開始交換 ICE candidate 候選人
- 當足夠且據連線力的候選人出線後，就開始進行 Peer Connection
Signaling issues(有許多的方法)
- Codelab上有一份資源： bitbucket.org/webrtc/codelab 利用 socket.io 建設signaling server， 也在教材中運用 RTCPeerConnection 協定，實作一個簡易的視訊系統。
- 網路上有許多開源的資源如 easyRTC (full stack) 或者是 Signalmaster (signaling server created for SimpleWebRTC)。
- 此網站 apprtc.appspot.com 使用 XHR and the Google App Engine Channel API 來處理 signaling。
- HTML5 Websocket - ex. WebSocket 簡單介紹與 jQuery 實作應用 , WebSocket 通訊協定簡介：比較 Polling、Long-Polling 與 Streaming 的運作原理。
參考
- WebRTC 入門教學（二）：以 RTCPeerConnection 建立 Peer-to-peer 連線
- What is WebRTC? - PubNub
- Getting Started with WebRTC - HTML5ROCKS
- WebRTC in the real world: STUN, TURN and signaling
沒有留言:
張貼留言