生活随笔
收集整理的這篇文章主要介紹了
WebRTC通话原理
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
WebRTC通話原理
目錄
媒體協商-音視頻編解碼 網絡協商 STUN TURN 媒體協商+網絡協商 數據的交換通道 WebRTC API 一對一通話
1. 媒體協商-音視頻編解碼
比如： Peer-A端可支持VP8、 H264多種編碼格式，而Peer-B端支持VP9、 H264，要保證二端都正確的編解碼，最簡單的辦法就是取它們的交集H264 有一個專門的協議 ，稱為Session Description Protocol (SDP)，可用于描述上述這類信息，在WebRTC中，參與視頻通訊的雙方必須先交換SDP信息，這樣雙方才能知根知底，而交換SDP的過程，也稱為"媒體協商"。
2. 網絡協商
彼此要了解對方的網絡情況，這樣才有可能找到一條相互通訊的鏈路 理想的網絡情況是每個瀏覽器的電腦都是私有公網IP，可以直接進行點對點連接 實際情況是：我們的電腦和電腦之間或大或小都是在某個局域網中， 需要NAT（Network Address Translation，網絡地址轉換）
1. STUN
STUN（Session Traversal Utilities for NAT， NAT會話穿越應用程序）是一種網絡協議，它允許位于NAT（或多重NAT） 后的客戶端找出自己的公網地址(ip+port)，查出自己位于哪種類型的NAT之后以及NAT為某一個本地端口所綁定的Internet端端口。 使用一句話說明STUN做的事情就是：告訴我你的公網IP地址+端口是什么。 問題是： STUN并不是每次都能成功的為需要NAT的通話設備分配IP地址的， P2P在傳輸媒體流時，使用的本地帶寬，在多人視頻通話的過程中，通話質量的好壞往往需要根據使用者本地的帶寬確定。 TURN可以很好的解決這個問題。
2. TURN
TURN的全稱為Traversal Using Relays around NAT，是STUN/RFC5389的一個拓展，主要添加了Relay功能。如果終端在NAT之后， 那么在特定的情景下，有可能使得終端無法和其對等端（peer）進行直接的通信，這時就需要公網的服務器作為一個中繼，對來往的數據進行轉發 在STUN分配公網IP失敗后，可以通過TURN服務器請求公網IP地址作為中繼地址。這種方式的帶寬由服務器端承擔，在多人視頻聊天的時候，本地帶寬壓力較小。 以上是WebRTC中經常用到的2個協議， STUN和TURN服務器我們使用coturn開源項目來搭建 ICE（ Interactive Connectivity Establishment，交互式連接建立） 跟STUN和TURN不一樣， ICE不是一種協議，而是一個框架（Framework），它整合了STUN和TURN。 coturn開源項目集成了STUN(打洞)和TURN(中繼)的功能。 網絡信息：放在 candidate
3. 媒體協商+網絡協商 數據的交換通道
從上面我們知道了2個客戶端協商媒體信息(SDP)和網絡信息(candidate)，那怎么去交換？是不是需要一個中間商去做交換？所以我們需要一個信令服務器（Signal server）（房間服務器）轉發彼此的媒體信息和網絡信息。 訪問到的局域網，借助信令服務器，就可以實現上面提到的SDP媒體信息及Candidate網絡信息交換。 信令服務器不只是交換 媒體信息sdp和網絡信息candidate，比如： 房間管理 人員進出房間
4. WebRTC API
MediaStream ： MediaStream用來表示一個媒體數據流（通過getUserMedia接口獲取），允許你訪問輸入設備，如麥克風和 Web攝像機，該 API 允許從其中任意一個獲取媒體流。 RTCPeerConnection ： RTCPeerConnection 對象允許用戶在兩個瀏覽器之間直接通訊 ，你可以通過網絡將捕獲的音頻和視頻流實時發送到另一個 WebRTC端點。使用這些 Api，你可以在本地機器和遠程對等點之間創建連接。它提供了連接到遠程對等點、維護和監視連接以及在不再需要連接時關閉連接的方法。
5. 一對一通話
超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生
總結
以上是生活随笔 為你收集整理的WebRTC通话原理 的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網站內容還不錯，歡迎將生活随笔 推薦給好友。
