什么是 WebRTC ？

WebRTC (Web Real-Time Communication) 是一个可以用在视频聊天，音频聊天或P2P文件分享等Web App中的 API。- MDN

WebRTC 有三个主要的API

getUserMedia - 采集本地音频和视频流

Web Real-Time Communications (WEBRTC) W3C 组织：定义浏览器 API。

Real-Time Communication in Web-browsers (RTCWEB) IETF 标准组织：定义其所需的协议，数据，安全性等手段。

简单来说，WebRTC 是一个可以在 Web 应用程序中实现音频，视频和数据的实时通信的开源项目。在实时通信中，音视频的采集和处理是一个很复杂的过程。比如音视频流的编解码、降噪和回声消除等，但是在 WebRTC 中，这一切都交由浏览器的底层封装来完成。我们可以直接拿到优化后的媒体流，然后将其输出到本地屏幕和扬声器，或者转发给其对等端。

WebRTC 的音视频处理引擎

所以，我们可以在不需要任何第三方插件的情况下，实现一个浏览器到浏览器的点对点（P2P）连接，从而进行音视频实时通信。当然，WebRTC 提供了一些 API 供我们使用，在实时音视频通信的过程中，我们主要用到以下三个：

getUserMedia：获取音频和视频流（MediaStream）

RTCPeerConnection：点对点通信

RTCDataChannel：数据通信

不过，虽然浏览器给我们解决了大部分音视频处理问题，但是从浏览器请求音频和视频时，我们还是需要特别注意流的大小和质量。因为即便硬件能够捕获高清质量流，CPU 和带宽也不一定可以跟上，这也是我们在建立多个对等连接时，不得不考虑的问题。

实现

接下来，我们通过分析上文提到的 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 验证码实践 1。

这里也可以通过 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 5

  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） 1。

需求还是老规矩，先了解一下需求。图片加载慢，可以直接看演示地址 2

连接过程涉及到多个环节，这里就不一一截图了，可以直接去演示地址查看。简单分析一下我们要做的事情：

加入房间后，获取到房间的所有在线成员。

选择任一成员进行通话，也就是呼叫动作。这时候就有一些细节问题要处理：不能呼叫自己、同一时刻只允许呼叫一个人且需要判断对方是否是通话中、呼叫后回复需要有相应判断（同意、拒绝以及通话中）

拒绝或通话中，都没有后续动作，可以换个人再呼叫。同意之后，就要开始建立点对点连接。

加入房间简单看一下加入房间的流程：

  // 前端
  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;
  }

后记

如果你看到了这里，且本文对你有一点帮助的话，希望你可以动动小手支持一下作者，感谢:beers:。文中如有不对之处，也欢迎大家指出，共勉。