通信过程

因为WebRTC标准里没有蕴含信令协定，所以像OWT、mediasoup等反对WebRTC的开源我的项目，其通信两端建设连贯的过程中的信令逻辑各不相同。然而，总体上来说，其通信过程必然会包含以下过程。

  1. 发动端创立本地的PeerConnection，并且创立Offer。
  2. 发动端通过信令服务器将Offer发送给应答端。
  3. 应答端创立本地的PeerConnection，把发动端的Offer设置到PeerConnection中，并且获取到Answer。
  4. 应答端通过信令服务器将Answer发送给发动端。
  5. 发动端把应答段的Answer设置到PeerConnection中。
  6. 两端都收集本地PeerConnection的ICE Candidate，通过信令服务器发送给对方，对方收到ICE Candidate后设置给本地的PeerConnection。
  7. 两端胜利建设音视频通道，开始收发音视频数据。

这个过程如果是在局域网中，能够通过某种形式与对端间接建设好信令通道，则能够不须要信令服务器，间接建设P2P的音视频通道。

这个过程中有些概念能够理解一下。

  • PeerConnection：WebRTC最后设计师用于浏览器的P2P媒体通信，所以其外围接口类就是PeerConnection，简称PC。
  • Offer、Answer：都属于SDP。SDP是一种形容会话协定，用于形容一次会话的多媒体数据格式等配置信息。通信单方替换SDP就是为了协商一个单方都反对的会话配置。
  • ICE：一种NAT穿透协定，利用STUN、TURN协定实现工作。ICE会在SDP中减少传输地址信息，而后对其进行连通性测试，测试胜利后就能够用于传输媒体数据了。
  • ICE Candidate：即ICE的传输地址信息，包含host、srflx、relayed和prflx。

外围流程

WebRTC反对的客户端零碎有iOS、Mac、Android、Windows和Linux。各端的代码各不相同，然而，其外围API的调用过程是相似的。所以，只有把握了总体的调用过程就能顺藤摸瓜的去查看各端的具体代码。这里总结下调用的关键步骤：

  • 全局初始化。
  • 创立PeerConnectionFactory。
  • 通过PeerConnectionFactory接口创立PeerConnection。
  • 创立Capturer。
  • 通过PeerConnectionFactory接口创立Source、Track。
  • 通过PeerConnection接口创立Transceiver。
  • 创立Offer、Answer，设置给PeerConnection，并相互交换。
  • 相互交换ICE Candidate，通过ICE Candidate回调承受对端ICE Candidate，设置给PeerConnection。
  • P2P连贯的状态能够通过监听PeerConnection的状态回调函数（Windows端是OnIceConnectionChange）。

其中，几个重要的WebRTC中的概念能够理解一下：

  • Capturer：视频数据采集，包含相机、屏幕、视频文件等。
  • Source：数据源，数据来自Capturer或其余，而后将数据传给Track。
  • Track：媒体数据交换的载体。
  • Sink：Track数据的消费者，本地预览和渲染远端视频都是Sink。
  • Transceiver：负责收发媒体数据。

以视频数据收发为例，发送端的Capturer采集到视频数据，交给Source，再由Source交给本地的Track，而后本地Track中数据分为2路，一路给本地Sink做预览，一路由Transceiver发送给接收端。接收端的Track收到数据后交给接收端的Sink进行渲染。