webrtc入门实践

webrtc入门实践

目的

• 了解相关概念
• 实现一个简单p2p连接

webrtc的来历

2010年5月，Google 以6,820万美元收购 VoIP 软件开发商 Global IP Solutions 的 GIPS 引擎，将其开源并改为名为“WebRTC”。随即 WebRTC 被纳入万维网联盟的 W3C 推荐标准。2014年7月1日，WebRTC 浏览器 API 标准的1.0版由 W3C 发布。WebRTC 是一个由 Google、Mozilla和 Opera 主导的开源项目，通过在浏览器中调用简单的 JavaScript API 和标准的 HTML5 标签，浏览器、手机平台还有其他设备可通过一个通用的协议进行实时通信。

webrtc是什么？

借助WebRTC，您可以在基于开放标准的应用程序中添加实时通信功能。 它支持在同级之间发送视频，语音和通用数据，从而使开发人员能够构建功能强大的语音和视频通信解决方案。 该技术可在所有现代浏览器以及所有主要平台的本机客户端上使用。 WebRTC背后的技术被实现为一个开放的Web标准，并在所有主流浏览器中以常规JavaScript API的形式提供。 对于本机客户端（如Android和iOS应用程序），可以使用提供相同功能的库。 WebRTC项目是open-source，并得到Apple，Google，Microsoft和Mozilla等的支持。

webrtc(Real-time communication for the web)是一门不需要安装任何浏览器插件就可以在浏览器端实现web实时通讯的技术。

但是webrtc只提供了客户端的能力，并没提供服务端的能力。比如信令服务器、tun/stun服务器、媒体流服务器等

webrtc能干什么？

WebRTC有许多不同的用例，从使用摄像头或麦克风的基本Web应用程序到更高级的视频通话应用程序和屏幕共享。 我们收集了许多代码示例，以更好地说明该技术如何工作以及您可以将其用于什么。例子

场景：

• 直播

• 会议

• 在线教育

• 软电话

  等等…

API功能：

• 音视频实时通话

• 通话过程中，实时修改宽带

• 通话前进行视频转码。例如：vp8转vp9，vp9转H264

• 可以先SDP协商，真正需要建立连接时再进行ICE协商，最终建立连接。该功能可缩短建立建立的时间，改善用户体验

• 可以将输出流转发给另一个连接，意味着多个连接可以共享一个媒体流。

• 可以将多个媒体轨道流混成一个流发送，反之亦然

• 可以修改sdp参数

• 跨终端音视频。例如：拨打软电话、Polycom等等。

  等等…

webrtc怎么用？

###相关概念

• 流

  MediaStreamTrack对象的集合，也就是MediaStream

• 轨道

  媒体流（MediaStream）基本组成单元（MediaStreamTrack）

• STUN服务器

  概念：全称Session Traversal Utilities for NAT，NAT会话穿透实用工具，提供遍历候选项地址服务

  作用：遍历NAT并返回候选项地址

• TURN服务器

  概念：全称Traversal Utilities for NAT，NAT遍历实用工具

  作用：TURN服务器除了能够遍历遍历候选项地址外，还可以在ICE打洞失败时提供媒体中继地址

• NAT

  概念：网络地址转换（NetWork Address Translation）。处于同一个网段的IP地址都属于同一个NAT内，所以在互联网中会存在着许多的NAT网络，还有可能存在着多个NAT之间的包含关系。注意：两个不同的NAT之间不能直接进行信息交换，因为从外网发往内网的数据包将被NAT设备丢弃，这使得位于不同NAT设备之后的主机之间无法直接交换信息。

  作用：通过路由或交换机将内网端口IP地址映射到外网的端口IP地址

• 内网穿透（NAT穿透）

  概念：通常情况下两个内网IP（即同一个NAT下）不需要进行网络穿透（打洞）就可以直接访问对方（前提是没有防火墙等因数的干扰），但在通常情况下我们的网络是非常复杂的（即指两个用户不在同一个NAT下），而两个NAT之间是不能直接相互访问的，所以 内网穿透就是通过内外网端口地址映射（即NAT）实现能让外网访问内网的一门技术。

  作用：将两个不同NAT的用户打通，从而实现通信功能

• 流媒体服务器

  概念：对于Mesh系统架构来说，媒体流是直接从本地流向远端的（中间有可能穿越多个NAT），对于MCU和SFU需要一个中间服务器来转发处理两端的流，这个服务器就称为流媒体服务器。

  作用：转发和处理流

• 上行、下行

  概念：对于Mesh和MCU系统架构来说对等端连接是双向的所以没有上、下行之分，但是对于SFU来说推流和拉流的是分开的，将本地流推送至媒体流服务器的连接通常称之为上行，而拉去远端媒体流的连接则称为下行。

  作用：上行推流，下行拉流

• 信令（signaling）服务器

  • 概念：是一个提供对等端可靠通讯的服务（通常采用websock与客户端进行通讯）

  • 作用：

    1、媒体协商和设置

    2、标识和身份验证

    3、会话控制

    4、双占用分解

• 多人视频通讯常用架构Mesh/MCU/SFU

  架构图：
  

  • Mesh

    即：每个端都与其它端互连。以上图最左侧为例，5个浏览器，二二建立p2p连接，每个浏览器与其它4个建立连接，总共需要10个连接。如果每条连接占用1m带宽，则每个端上行需要4m，下行带宽也要4m，总共带宽消耗20m。而且除了带宽问题，每个浏览器上还要有音视频“编码/解码”，cpu使用率也是问题，一般这种架构只能支持4-6人左右，不过优点也很明显，没有中心节点，实现很简单。

  • MCU( (MultiPoint Control Unit))

    这是一种传统的中心化架构(上图中间部分)，每个浏览器仅与中心的MCU服务器连接，MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑，每个浏览器只要1个连接，整个应用仅消耗5个连接，带宽占用(包括上行、下行）共10m，浏览器端的压力要小很多，可以支持更多的人同时音视频通讯，比较适合多人视频会议。但是MCU服务器的压力较大，需要较高的配置。

  • SFU((Selective Forwarding Unit))

    上图右侧部分，咋一看，跟MCU好象没什么区别，但是思路不同，仍然有中心节点服务器，但是中心节点只负责转发，不做太重的处理，所以服务器的压力会低很多，配置也不象MUC要求那么高。但是每个端需要建立一个连接用于上传自己的视频，同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5，消耗的带宽也是最大的，如果每个连接1M带宽，总共需要25M带宽，它的典型场景是1对N的视频互动。

  基于宽带考虑的建议：如果规模不大(5人以下) Mesh框架就够用了，毕竟实现简单；如果50人以下，且带宽有限，选择MCU比较适合；如果规模更大，且带宽良好，SFU相对更适合。

• ICE协议

  概念：交互式连接建立（Interactive Connectivity Establishment）是一种标准穿透协议

  作用：利用STRUN和TURN服务器来帮助断点监建立连接

• sdp

  概念：会话描述协议（session description protocol）

  作用：用于描述对等连接的媒体特征，进行媒体协商

如何建立一个RTCPeerConnection对等连接?

• 第一步：获取媒体流

  媒体约束：

  //媒体约束
  const constraints:MediaStreamConstraints={
       
    video:MediaTrackConstraints;
    audio:MediaTrackConstraints;
  }
  

  以下是轨道约束(MediaTrackConstraints)参数说明：