共计 1509 个字符，预计需要花费 4 分钟才能阅读完成。
通信过程
因为 WebRTC 标准里没有蕴含信令协定，所以像 OWT、mediasoup 等反对 WebRTC 的开源我的项目，其通信两端建设连贯的过程中的信令逻辑各不相同。然而，总体上来说，其通信过程必然会包含以下过程。
- 发动端创立本地的 PeerConnection，并且创立 Offer。
- 发动端通过信令服务器将 Offer 发送给应答端。
- 应答端创立本地的 PeerConnection，把发动端的 Offer 设置到 PeerConnection 中，并且获取到 Answer。
- 应答端通过信令服务器将 Answer 发送给发动端。
- 发动端把应答段的 Answer 设置到 PeerConnection 中。
- 两端都收集本地 PeerConnection 的 ICE Candidate，通过信令服务器发送给对方，对方收到 ICE Candidate 后设置给本地的 PeerConnection。
- 两端胜利建设音视频通道，开始收发音视频数据。
这个过程如果是在局域网中，能够通过某种形式与对端间接建设好信令通道，则能够不须要信令服务器，间接建设 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 进行渲染。
正文完
