【從頭到腳】擼一個多人視頻聊天 — 前端 WebRTC 實戰（一）

時間  2019-11-05
標籤 從頭到腳 一個 多人 視頻 聊天 前端 webrtc 實戰 简体版
原文   原文鏈接

前言

【 從頭到腳 】會做爲一個系列文章來發布，它包括但不限於 WebRTC 多人視頻，預計會有：javascript

  • WebRTC 實戰（一）：也就是本期，主要是基礎講解以及一對一的本地對等鏈接，網絡對等鏈接。
  • WebRTC 實戰（二）：主要講解數據傳輸以及多端本地對等鏈接、網絡對等鏈接。
  • WebRTC 實戰（三）：實現一個一對一的視頻聊天項目，包括但不限於截圖、錄製等。
  • WebRTC + Canvas 實現一個共享畫板項目。
  • 做者開源做品 💘🍦🙈Vchat — 一個社交聊天系統（vue + node + mongodb） 的系列文章

由於文章輸出確實要耗費很大的精力，因此上面計劃不必定是這個發佈順序，中間也會穿插發佈其它方向的文章，如 Vue、JavaScript 或者其餘學習的主題。在文章裏，會把我本身遇到過的一些坑點重點提示你們注意，儘可能讓你們在學習過程當中少走彎路。固然，個人也並非標準答案，只是我我的的思路。若是你們有更好的方法，能夠互相交流，也但願你們都能有所收穫。css

在這裏也但願你們能夠 關注 一波，大家的關注支持，也能激勵我輸出更好的文章。html

先放個效果圖，這期的目標是實現一個 1 V 1 的視頻通話（筆記本攝像頭不能用了，用的虛擬攝像頭）。文章比較長，能夠 mark 之後慢慢看。前端

文章末尾有 交流羣 和 公衆號，但願你們支持，感謝🍻。vue

什麼是 WebRTC ？

WebRTC 是由一家名爲 Gobal IP Solutions，簡稱 GIPS 的瑞典公司開發的。Google 在 2011 年收購了 GIPS，並將其源代碼開源。而後又與 IETF 和 W3C 的相關標準機構合做，以確保行業達成共識。其中：java

  • Web Real-Time Communications (WEBRTC) W3C 組織：定義瀏覽器 API。
  • Real-Time Communication in Web-browsers (RTCWEB) IETF 標準組織：定義其所需的協議，數據，安全性等手段。

簡單來講，WebRTC 是一個能夠在 Web 應用程序中實現音頻，視頻和數據的實時通訊的開源項目。在實時通訊中，音視頻的採集和處理是一個很複雜的過程。好比音視頻流的編解碼、降噪和回聲消除等，可是在 WebRTC 中，這一切都交由瀏覽器的底層封裝來完成。咱們能夠直接拿到優化後的媒體流，而後將其輸出到本地屏幕和揚聲器，或者轉發給其對等端。node

WebRTC 的音視頻處理引擎：git

WebRTC 的音視頻處理引擎

因此，咱們能夠在不須要任何第三方插件的狀況下，實現一個瀏覽器到瀏覽器的點對點（P2P）鏈接，從而進行音視頻實時通訊。固然，WebRTC 提供了一些 API 供咱們使用，在實時音視頻通訊的過程當中，咱們主要用到如下三個：es6

  • getUserMedia：獲取音頻和視頻流（MediaStream）
  • RTCPeerConnection：點對點通訊
  • RTCDataChannel：數據通訊

不過，雖然瀏覽器給咱們解決了大部分音視頻處理問題，可是從瀏覽器請求音頻和視頻時，咱們仍是須要特別注意流的大小和質量。由於即使硬件可以捕獲高清質量流，CPU 和帶寬也不必定能夠跟上，這也是咱們在創建多個對等鏈接時，不得不考慮的問題。github

實現

接下來，咱們經過分析上文提到的 API，來逐步弄懂 WebRTC 實時通訊實現的流程。

getUserMedia

MediaStream

getUserMedia 這個 API 你們可能並不陌生，由於常見的 H5 錄音等功能就須要用到它，主要就是用來獲取設備的媒體流（即 MediaStream）。它能夠接受一個約束對象 constraints 做爲參數，用來指定須要獲取到什麼樣的媒體流。

navigator.mediaDevices.getUserMedia({ audio: true, video: true }) 
    // 參數表示須要同時獲取到音頻和視頻
        .then(stream => {
          // 獲取到優化後的媒體流
          let video = document.querySelector('#rtc');
          video.srcObject = stream;
        })
        .catch(err => {
          // 捕獲錯誤
        });
複製代碼

咱們簡單看一下獲取到的 MediaStream。

能夠看到它有不少屬性，咱們只須要了解一下就好，更多信息能夠查看 MDN。

* id [String]: 對當前的 MS 進行惟一標識。因此每次刷新瀏覽器或是從新獲取 MS，id 都會變更。
* active [boolean]: 表示當前 MS 是不是活躍狀態（就是是否能夠播放）。
* onactive: 當 active 爲 true 時，觸發該事件。
複製代碼

結合上圖，咱們順便複習一下上期講的原型和原型鏈。MediaStream 的 __proto__ 指向它的構造函數所對應的原型對象，在原型對象中又有一個 constructor 屬性指向了它所對應的構造函數。也就是說 MediaStream 的構造函數是一個名爲 MediaStream 的函數。可能說得有一點繞，對原型還不熟悉的同窗，能夠去看一下上期文章 JavaScript 原型和原型鏈及 canvas 驗證碼實踐。

這裏也能夠經過 getAudioTracks()、getVideoTracks() 來查看獲取到的流的某些信息，更多信息查看 MDN。

* kind: 是當前獲取的媒體流類型（Audio/Video）。
* label: 是媒體設備，我這裏用的是虛擬攝像頭。
* muted: 表示媒體軌道是否靜音。
複製代碼

兼容性

繼續來看 getUserMedia，navigator.mediaDevices.getUserMedia 是新版的 API，舊版的是 navigator.getUserMedia。爲了不兼容性問題，咱們能夠稍微處理一下（其實說到底，如今 WebRTC 的支持率還不算高，有須要的能夠選擇一些適配器，如 adapter.js）。

// 判斷是否有 navigator.mediaDevices，沒有賦成空對象
    if (navigator.mediaDevices === undefined) {
        navigator.mediaDevices = {};
    }
    
    // 繼續判斷是否有 navigator.mediaDevices.getUserMedia，沒有就採用 navigator.getUserMedia
    if (navigator.mediaDevices.getUserMedia) {
        navigator.mediaDevices.getUserMedia = function(prams) {
            let getUserMedia = navigator.webkitGetUserMedia || navigator.mozGetUserMedia;
            // 兼容獲取
            if (!getUserMedia) {
                return Promise.reject(new Error('getUserMedia is not implemented in this browser'));
            }
            return new Promise(function(resolve, reject) {
                getUserMedia.call(navigator, prams, resolve, reject);
            });
        };
    }
    navigator.mediaDevices.getUserMedia(constraints)
        .then(stream => {
            let video = document.querySelector('#Rtc');
            if ('srcObject' in video) { // 判斷是否支持 srcObject 屬性
                video.srcObject = stream;
            } else {
                video.src = window.URL.createObjectURL(stream);
            }
            video.onloadedmetadata = function(e) {
                video.play();
            };
        })
        .catch((err) => { // 捕獲錯誤
            console.error(err.name + ': ' + err.message);
        });
複製代碼

constraints

對於 constraints 約束對象，咱們能夠用來指定一些和媒體流有關的屬性。好比指定是否獲取某種流：

navigator.mediaDevices.getUserMedia({ audio: false, video: true });
    // 只須要視頻流，不要音頻
複製代碼

指定視頻流的寬高、幀率以及理想值：

// 獲取指定寬高，這裏須要注意：在改變視頻流的寬高時，
    // 若是寬高比和採集到的不同，會直接截掉某部分
    { audio: false, 
      video: { width: 1280, height: 720 } 
    }
    // 設定理想值、最大值、最小值
    {
      audio: true,
      video: {
        width: { min: 1024, ideal: 1280, max: 1920 },
        height: { min: 776, ideal: 720, max: 1080 }
      }
    }
複製代碼

對於移動設備來講，還能夠指定獲取前攝像頭，或者後置攝像頭：

{ audio: true, video: { facingMode: "user" } } // 前置
    { audio: true, video: { facingMode: { exact: "environment" } } } // 後置
    // 也能夠指定設備 id，
    // 經過 navigator.mediaDevices.enumerateDevices() 能夠獲取到支持的設備
    { video: { deviceId: myCameraDeviceId } }
複製代碼

還有一個比較有意思的就是設置視頻源爲屏幕，可是目前只有火狐支持了這個屬性。

{ audio: true, video: {mediaSource: 'screen'} } 
複製代碼

這裏就不接着作搬運工了，更多精彩盡在 MDN，^_^!

RTCPeerConnection

RTCPeerConnection 接口表明一個由本地計算機到遠端的 WebRTC 鏈接。該接口提供了建立，保持，監控，關閉鏈接的方法的實現。—— MDN

概述

RTCPeerConnection 做爲建立點對點鏈接的 API，是咱們實現音視頻實時通訊的關鍵。在點對點通訊的過程當中，須要交換一系列信息，一般這一過程叫作 — 信令（signaling）。在信令階段須要完成的任務：

 * 爲每一個鏈接端建立一個 RTCPeerConnection，並添加本地媒體流。
 * 獲取並交換本地和遠程描述：SDP 格式的本地媒體元數據。
 * 獲取並交換網絡信息：潛在的鏈接端點稱爲 ICE 候選者。
複製代碼

咱們雖然把 WebRTC 稱之爲點對點的鏈接，但並不表明在實現過程當中不須要服務器的參與。相反，在點對點的信道創建起來以前，兩者之間是沒有辦法通訊的。這也就意味着，在信令階段，咱們須要一個通訊服務來幫助咱們創建起這個鏈接。WebRTC 自己沒有指定某一個信令服務，因此，咱們能夠但不限於使用 XMPP、XHR、Socket 等來作信令交換所需的服務。我在工做中採用的方案是基於 XMPP 協議的Strophe.js來作雙向通訊，可是在本例中則會使用Socket.io以及 Koa 來作項目演示。

NAT 穿越技術

咱們先看鏈接任務的第一條：爲每一個鏈接端建立一個 RTCPeerConnection，並添加本地媒體流。事實上，若是是通常直播模式，則只須要播放端添加本地流進行輸出，其餘參與者只須要接受流進行觀看便可。

由於各瀏覽器差別，RTCPeerConnection 同樣須要加上前綴。

let PeerConnection = window.RTCPeerConnection ||
                     window.mozRTCPeerConnection ||
                     window.webkitRTCPeerConnection;
let peer = new PeerConnection(iceServers);
複製代碼

咱們看見 RTCPeerConnection 也一樣接收一個參數 — iceServers，先來看看它長什麼樣：

{
  iceServers: [
    { url: "stun:stun.l.google.com:19302"}, // 谷歌的公共服務
    {
      url: "turn:***",
      username: ***, // 用戶名
      credential: *** // 密碼
    }
  ]
}
複製代碼

參數配置了兩個 url，分別是 STUN 和 TURN，這即是 WebRTC 實現點對點通訊的關鍵，也是通常 P2P 鏈接都須要解決的問題：NAT穿越。

NAT（Network Address Translation，網絡地址轉換）簡單來講就是爲了解決 IPV4 下的 IP 地址匱乏而出現的一種技術，也就是一個 公網 IP 地址通常都對應 n 個內網 IP。這樣也就會致使不是同一局域網下的瀏覽器在嘗試 WebRTC 鏈接時，沒法直接拿到對方的公網 IP 也就不能進行通訊，因此就須要用到 NAT 穿越（也叫打洞）。如下爲 NAT 穿越基本流程：

通常狀況下會採用 ICE 協議框架進行 NAT 穿越，ICE 的全稱爲 Interactive Connectivity Establishment，即交互式鏈接創建。它使用 STUN 協議以及 TURN 協議來進行穿越。關於 NAT 穿越的更多信息能夠參考 ICE協議下NAT穿越的實現（STUN&TURN）、P2P通訊標準協議(三)之ICE。

到這裏，咱們能夠發現，WebRTC 的通訊至少須要兩種服務配合：

  • 信令階段須要雙向通訊服務輔助信息交換。
  • STUN、TURN輔助實現 NAT 穿越。

創建點對點鏈接

WebRTC 的點對點鏈接究竟是什麼樣的過程呢，咱們經過結合圖例來分析鏈接。

顯而易見，在上述鏈接的過程當中：

呼叫端（在這裏都是指代瀏覽器）須要給 接收端 發送一條名爲 offer 的信息。

接收端 在接收到請求後，則返回一條 answer 信息給 呼叫端。

這即是上述任務之一 ，SDP 格式的本地媒體元數據的交換。sdp 信息通常長這樣：

v=0
    o=- 1837933589686018726 2 IN IP4 127.0.0.1
    s=-
    t=0 0
    a=group:BUNDLE audio video
    a=msid-semantic: WMS yvKeJMUSZzvJlAJHn4unfj6q9DMqmb6CrCOT
    m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
    ...
    ...
複製代碼

可是任務不只僅是交換，還須要分別保存本身和對方的信息，因此咱們再加點料：

* **呼叫端** 建立 offer 信息後，先調用 setLocalDescription 存儲本地 offer 描述，再將其發送給 **接收端**。
 * **接收端** 收到 offer 後，先調用 setRemoteDescription 存儲遠端 offer 描述；而後又建立 answer 信息，一樣須要調用 setLocalDescription 存儲本地 answer 描述，再返回給 **呼叫端**
 * **呼叫端** 拿到 answer 後，再次調用 setRemoteDescription 設置遠端 answer 描述。
複製代碼

到這裏點對點鏈接還缺一步，也就是網絡信息 ICE 候選交換。不過這一步和 offer、answer 信息的交換並無前後順序，流程也是同樣的。即：在呼叫端和接收端的 ICE 候選信息準備完成後，進行交換，並互相保存對方的信息，這樣就完成了一次鏈接。

這張圖是我認爲比較完善的了，詳細的描述了整個鏈接的過程。正好咱們再來小結一下：

* 基礎設施：必要的信令服務和 NAT 穿越服務
 * clientA 和 clientB 分別建立 RTCPeerConnection 併爲輸出端添加本地媒體流。若是是視頻通話類型，則意味着，兩端都須要添加媒體流進行輸出。
 * 本地 ICE 候選信息採集完成後，經過信令服務進行交換。
 * 呼叫端（比如 A 給 B 打視頻電話，A 爲呼叫端）發起 offer 信息，接收端接收並返回一個 answer 信息，呼叫端保存，完成鏈接。
複製代碼

本地 1 v 1 對等鏈接

基礎流程講完了，那麼是騾子是馬拉出來溜溜。咱們先來實現一個本地的對等鏈接，藉此熟悉一下流程和部分 API。本地鏈接，意思就是不通過服務，在本地頁面的兩個 video 之間進行鏈接。算了，仍是上圖吧，一看就懂。

明確一下目標，A 做爲輸出端，須要獲取到本地流並添加到本身的 RTCPeerConnection；B 做爲呼叫端，並無輸出的需求，所以只須要接收流。

建立媒體流

頁面佈局很簡單，就是兩個 video 標籤，分別表明 A 和 B。因此咱們直接看代碼，雖然源碼是用 Vue 構建的，可是並無用到特別的 API，總體上和 es6 的 class 語法相差不大，並且都有詳細的註釋，因此建議沒有 Vue 基礎的同窗能夠直接當成 es6 來閱讀。示例 源碼庫 webrtc-stream

async createMedia() {
      // 保存本地流到全局
      this.localstream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true })
      let video = document.querySelector('#rtcA');
      video.srcObject = this.localstream;
      this.initPeer(); // 獲取到媒體流後，調用函數初始化 RTCPeerConnection
  }
複製代碼

初始化 RTCPeerConnection

initPeer() {
      ...
      this.peerA.addStream(this.localstream); // 添加本地流
      this.peerA.onicecandidate = (event) => {
      // 監聽 A 的ICE候選信息 若是收集到，就添加給 B 鏈接狀態
          if (event.candidate) {
              this.peerB.addIceCandidate(event.candidate);
          }
      };
      ...
      // 監聽是否有媒體流接入，若是有就賦值給 rtcB 的 src
      this.peerB.onaddstream = (event) => {
          let video = document.querySelector('#rtcB');
          video.srcObject = event.stream;
      };
      this.peerB.onicecandidate = (event) => { 鏈接狀態
      // 監聽 B 的ICE候選信息 若是收集到，就添加給 A
          if (event.candidate) {
              this.peerA.addIceCandidate(event.candidate);
          }
      };
  }
複製代碼

這部分主要就是分別建立 peer 實例，並互相交換 ICE 信息。不過有一個屬性須要在這裏提一下，就是 iceConnectionState。

peer.oniceconnectionstatechange = (evt) => {
      console.log('ICE connection state change: ' + evt.target.iceConnectionState);
  };
複製代碼

咱們能夠經過 oniceconnectionstatechange 方法來監測 ICE 鏈接的狀態，它一共有七種狀態：

new        ICE代理正在收集候選人或等待提供遠程候選人。
checking   ICE代理已經在至少一個組件上接收了遠程候選者，而且正在檢查候選但還沒有找到鏈接。除了檢查，它可能還在收集。
connected  ICE代理已找到全部組件的可用鏈接，但仍在檢查其餘候選對以查看是否存在更好的鏈接。它可能還在收集。
completed  ICE代理已完成收集和檢查，並找到全部組件的鏈接。
failed     ICE代理已完成檢查全部候選對，但未能找到至少一個組件的鏈接。可能已找到某些組件的鏈接。
disconnected ICE 鏈接斷開
closed      ICE代理已關閉，再也不響應STUN請求。
複製代碼

咱們須要注意的是 completed 和 disconnected，一個是完成鏈接時觸發，一個在斷開鏈接時觸發。

建立鏈接

async call() {
      if (!this.peerA || !this.peerB) { // 判斷是否有對應實例，沒有就從新建立
          this.initPeer();
      }
      try {
          let offer = await this.peerA.createOffer(this.offerOption); // 建立 offer
          await this.onCreateOffer(offer);
      } catch (e) {
          console.log('createOffer: ', e);
      }
  }
複製代碼

這裏須要判斷是否有對應實例，是爲了掛斷以後又從新呼叫作的處理。

async onCreateOffer(desc) {
      try {
          await this.peerB.setLocalDescription(desc); // 呼叫端設置本地 offer 描述
      } catch (e) {
          console.log('Offer-setLocalDescription: ', e);
      }
      try {
          await this.peerA.setRemoteDescription(desc); // 接收端設置遠程 offer 描述
      } catch (e) {
          console.log('Offer-setRemoteDescription: ', e);
      }
      try {
          let answer = await this.peerA.createAnswer(); // 接收端建立 answer
          await this.onCreateAnswer(answer);
      } catch (e) {
          console.log('createAnswer: ', e);
      }
  },
  async onCreateAnswer(desc) {
      try {
          await this.peerA.setLocalDescription(desc); // 接收端設置本地 answer 描述
      } catch (e) {
          console.log('answer-setLocalDescription: ', e);
      }
      try {
          await this.peerB.setRemoteDescription(desc); // 呼叫端端設置遠程 answer 描述
      } catch (e) {
          console.log('answer-setRemoteDescription: ', e);
      }
  }
複製代碼

這基本就是以前重複過好幾回的流程用代碼寫出來而已，看到這裏，思路應該比較清晰了。不過有一點須要說明一下，就是如今這種狀況，A 做爲呼叫端，B 同樣是能夠拿到 A 的媒體流的。由於鏈接一旦創建了，就是雙向的，只不過 B 初始化 peer 的時候沒有添加本地流，因此 A 不會有 B 的媒體流。

網絡 1 v 1 對等鏈接

想必基本流程你們都已經熟悉了，經過圖解、實例來來回回講了好幾遍。因此趁熱打鐵，咱們此次把服務加上，作一個真正的點對點鏈接。在看下面的文章以前，我但願你有一點點 Koa 和 Scoket.io 的基礎，瞭解一些基本 API 便可。不熟悉的同窗也沒關係，如今看也來得及，Koa、Socke.io，或者能夠參考我以前的文章 Vchat - 一個社交聊天系統（vue + node + mongodb）。

需求

仍是老規矩，先了解一下需求。圖片加載慢，能夠直接看演示地址

鏈接過程涉及到多個環節，這裏就不一一截圖了，能夠直接去演示地址查看。簡單分析一下咱們要作的事情： * 加入房間後，獲取到房間的全部在線成員。 * 選擇任一成員進行通話，也就是呼叫動做。這時候就有一些細節問題要處理：不能呼叫本身、同一時刻只容許呼叫一我的且須要判斷對方是不是通話中、呼叫後回覆須要有相應判斷（贊成、拒絕以及通話中） * 拒絕或通話中，都沒有後續動做，能夠換我的再呼叫。贊成以後，就要開始創建點對點鏈接。

加入房間

簡單看一下加入房間的流程：

// 前端
  join() {
      if (!this.account) return;
      this.isJoin = true; // 輸入框彈層邏輯
      window.sessionStorage.account = this.account; // 刷新判斷是否登陸過
      socket.emit('join', {roomid: this.roomid, account: this.account}); // 發送加入房間請求
  }
  
  // 後端
  const sockS = {}; // 不一樣客戶端對應的 sock 實例
  const users = {}; // 成員列表
  sock.on('join', data=>{
      sock.join(data.roomid, () => {
          if (!users[data.roomid]) {
              users[data.roomid] = [];
          }
          let obj = {
              account: data.account,
              id: sock.id
          };
          let arr = users[data.roomid].filter(v => v.account === data.account);
          if (!arr.length) {
              users[data.roomid].push(obj);
          }
          sockS[data.account] = sock; // 保存不一樣客戶端對應的 sock 實例
           // 將房間內成員列表發給房間內全部人
          app._io.in(data.roomid).emit('joined', users[data.roomid], data.account, sock.id);
      });
  });
複製代碼

後端成員列表的處理，是由於作了多房間的邏輯，按每一個房間的成員表返回的。大家若是作的時候沒有多房間，則不須要這麼考慮。sockS 的處理，是爲了發送私聊消息。

呼叫

前面已經說了呼叫的注意事項，因此這裏就一塊兒來說。須要注意的就是消息中須要帶有本身和對方的 account，由於這是判斷成員 sock 的標識，也就是以前存儲在 socks 中的用來發私聊消息的。而後是前面說的三種狀態，在這裏用 type 值 1, 2, 3 來區分，而後給出不一樣的回覆。

// 前端
  apply(account) { // 發送請求
      // account 對方account self 是本身的account
      this.loading = true;
      this.loadingText = '呼叫中'; // 呼叫中 loading
      socket.emit('apply', {account: account, self: this.account});
  },
  reply(account, type) { // 處理回覆
      socket.emit('reply', {account: account, self: this.account, type: type});
  }
  // 收到請求
  socket.on('apply', data => {
      if (this.isCall) { // 判斷是否在通話中
          this.reply(data.self, '3');
          return;
      }
      this.$confirm(data.self + ' 向你請求視頻通話, 是否贊成?', '提示', {
          confirmButtonText: '贊成',
          cancelButtonText: '拒絕',
          type: 'warning'
      }).then(async () => {
          this.isCall = data.self;
          this.reply(data.self, '1');
      }).catch(() => {
          this.reply(data.self, '2');
      });
  });
  
  // 後端
  sock.on('apply', data=>{ // 轉發申請
      sockS[data.account].emit('apply', data);
  });
複製代碼

後端比較簡單，僅僅是轉發一下請求，給對應的客戶端。其實咱們這個例子的後端，基本都是這個操做，因此後面的後端代碼就不貼了，能夠去源碼直接看。

回覆

回覆和和呼叫是同樣的邏輯，分別處理不一樣的回覆就行了。

// 前端 
  socket.on('reply', async data =>{ // 收到回覆
      this.loading = false;
      switch (data.type) {
          case '1': // 贊成
              this.isCall = data.self; // 存儲通話對象
              break;
          case '2': //拒絕
              this.$message({
                  message: '對方拒絕了你的請求！',
                  type: 'warning'
              });
              break;
          case '3': // 正在通話中
              this.$message({
                  message: '對方正在通話中！',
                  type: 'warning'
              });
              break;
      }
  });
複製代碼

建立鏈接

呼叫和回覆的邏輯基本清楚了，那咱們繼續思考，應該在什麼時機建立 P2P 鏈接呢？咱們以前說的，拒絕和通話中都不須要處理，只有贊成須要，那就應該在贊成請求的位置開始建立。須要注意的是，贊成請求有兩個地方：一個是你點了贊成，另外一個是對方知道你點了贊成以後。

本例採起的是呼叫方發送 Offer，這個地方必定得注意，只要有一方建立 Offer 就能夠了，由於一旦鏈接就是雙向的。

socket.on('apply', data => { // 你點贊成的地方
      ...
      this.$confirm(data.self + ' 向你請求視頻通話, 是否贊成?', '提示', {
          confirmButtonText: '贊成',
          cancelButtonText: '拒絕',
          type: 'warning'
      }).then(async () => {
          await this.createP2P(data); // 贊成以後建立本身的 peer 等待對方的 offer
          ... // 這裏不發 offer
      })
      ...
  });
  socket.on('reply', async data =>{ // 對方知道你點了贊成的地方
      switch (data.type) {
          case '1': // 只有這裏發 offer
              await this.createP2P(data); // 對方贊成以後建立本身的 peer
              this.createOffer(data); // 並給對方發送 offer
              break;
          ...
      }
  });
複製代碼

和微信等視頻通話同樣，雙方都須要進行媒體流輸出，由於大家都要看見對方。因此這裏和以前本地對等鏈接的區別就是都須要給本身的 RTCPeerConnection 實例添加媒體流，而後鏈接後各自都能拿到對方的視頻流。在 初始化 RTCPeerConnection 時，記得加上 onicecandidate 函數，用以給對方發送 ICE 候選。

async createP2P(data) {
      this.loading = true; // loading動畫
      this.loadingText = '正在創建通話鏈接';
      await this.createMedia(data);
  },
  async createMedia(data) {
      ... // 獲取並將本地流賦值給 video 同以前
      this.initPeer(data); // 獲取到媒體流後，調用函數初始化 RTCPeerConnection
  },
  initPeer(data) {
      // 建立輸出端 PeerConnection
      ...
      this.peer.addStream(this.localstream); // 都須要添加本地流
      this.peer.onicecandidate = (event) => {
      // 監聽ICE候選信息 若是收集到，就發送給對方
          if (event.candidate) { // 發送 ICE 候選
              socket.emit('1v1ICE',
              {account: data.self, self: this.account, sdp: event.candidate});
          }
      };
      this.peer.onaddstream = (event) => {
      // 監聽是否有媒體流接入，若是有就賦值給 rtcB 的 src，改變相應loading狀態，賦值省略
          this.isToPeer = true;
          this.loading = false;
          ...
      };
  }
複製代碼

createOffer 等信息交換和以前同樣，只是須要經過 Socket 轉發給對應的客戶端。而後各自接收到消息後分別採起對應的措施。

socket.on('1v1answer', (data) =>{ // 接收到 answer
      this.onAnswer(data);
  });
  socket.on('1v1ICE', (data) =>{ // 接收到 ICE
      this.onIce(data);
  });
  socket.on('1v1offer', (data) =>{ // 接收到 offer
      this.onOffer(data);
  });
  
  // 這裏只貼一個 createOffer 的代碼，由於和以前的思路都同樣，只是寫法有些區別
  // 建議你們都本身敲一遍，有問題能夠交流，也能夠去源碼查看。
  async createOffer(data) { // 建立併發送 offer
      try {
          // 建立offer
          let offer = await this.peer.createOffer(this.offerOption);
          // 呼叫端設置本地 offer 描述
          await this.peer.setLocalDescription(offer);
          // 給對方發送 offer
          socket.emit('1v1offer', {account: data.self, self: this.account, sdp: offer});
      } catch (e) {
          console.log('createOffer: ', e);
      }
  }
複製代碼

掛斷

掛斷的思路依然是將各自的 peer 關閉，可是這裏掛斷方還須要藉助 Socket 告訴對方，你已經掛電話了，否則對方還在癡癡地等。

hangup() { // 掛斷通話 並作相應處理 對方收到消息後同樣須要關閉鏈接
      socket.emit('1v1hangup', {account: this.isCall, self: this.account});
      this.peer.close();
      this.peer = null;
      this.isToPeer = false;
      this.isCall = false;
  }
複製代碼

參考文章

交流羣

qq前端交流羣：960807765，歡迎各類技術交流，期待你的加入

後記

若是你看到了這裏，且本文對你有一點幫助的話，但願你能夠動動小手支持一下做者，感謝🍻。文中若有不對之處，也歡迎你們指出，共勉。

往期文章：

歡迎關注公衆號 前端發動機，第一時間得到做者文章推送，還有各種前端優質文章，但願在將來的前端路上，與你一同成長。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程