有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年，这并非没有根据。就在去年（2017年），
WebRTC 1.0 标准草案出炉（实际上WebRTC标准草案的早期版本早在2011年就已经发布，WebRTC并非一夜之间就出现的技术），
并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了，或许门槛如此之高的实时音视频技术终有白菜化的那一天。
补充：WebRTC标准草案的版本演进历史，请点击进入。
这篇文章会教你怎么搭建信令服务，和用STUN/TURN服务去做nat穿透。另外，我们会解释WebRTC是怎么做到多端通话的。以及如何和VoIP／PSTN（电话）建立通话。
如果你对WebRTC还没有基础，我们强烈建议你先看下Getting Started With WebRTC。
一.什么是信令服务（Signaling）？信令是一个协调沟通的过程，为了让一个WebRTC应用发起一个“通话”，客户端间需要交换以下信令信息：
1.发起和关闭一个通话的控制信息；
2.错误信息；
3.媒体元数据，比如编码解码设置，带宽和媒体类型；
4.Key数据，用于确保安全通讯；
5.网络数据，比如主机在外网下的IP地址和端口。
客户端的信令处理需要一种来回传递信息的方法，这种机制没有被WebRTC定义，你需要自己去创建它。下面我们将描绘几种构建信令服务的方法。
在此之前，先讲几个概念……为什么WebRTC没有定义信令？为了避免冗余和最大化兼容已经确立的技术，WebRTC没有指定信令的方法和协议。
-------------------------------
(WebRTC设计思想是完全指定和控制媒体层，但是让signaling层尽量脱离应用，原因是不同的应用可能会使用不同的协议，比如已经存在的SIP或者Jingle呼叫协议等。
这份协议中，需要交换的关键信息是多媒体会议的描述信息，包括在媒体层确定必要的传输方式和 媒体配置信息)
------------------------------------------------
JSEP的结构同样避免了让浏览器保存状态信息，如果让浏览器成为一个保存信令状态的机器，会出现一个问题，
就是每次当页面重载的时候，信令会丢失。所以更好的方案是用服务器保存信令状态。
webrtc视频处理流水线的第一个环节就是获取视频数据，视频源可以有多种来源，以摄像头采集为例，每个平台往往又提供不同的接口，本文打算以android平台camera采集为例，分析一下webrtc视频采集和分发流程。
如下所示，webrtc针对视频采集对外主要提供的是VideoCapturer接口，实现类有ScreenCapturerAndroid、FileVideoCapturer和CameraCapturer，分别表示屏幕、文件、摄像头三种不同的视频来源，因为android系统先后提供了camera1.0和camera2.0接口，因此CameraCapturer又用Camera1Capturer和Camera2Capturer两个子类分别表示。
在webrtc源码分析之视频编码之一分析了视频编码初始化流程，接下来分析一下视频编码流程，
如下图所示，视频编码流程是从VideoBroadcaster回调VideoStreamEncoder的OnFrame开始的。
新的一年又开始了，我打算先把年前看的webrtc的流程先梳理下。省的后面忙于其他事情，时间一长又忘记了。还是尽量按webrtc开篇中的顺利来梳理吧。在之前的两篇博客中基本完成了webrtc视频采集的分析，因此本篇开始就分析一下webrtc视频编码相关的内容，准备分三篇来介绍。
废话少说，如下图所示，主要是从初始化流程和编码流程来分析webrtc视频编码模块，step1～step31是初始化流程，主要是创建相关的对象，step32～step49是编码流程，本篇文章打算先分析一下初始化流程。
