根据anyRTC官方运营数据分析预测，到2020年物联网设备的数量将达到近210亿。随着工业产品，可穿戴设备和智能家用电器的不断涌现，它们的多样性正在迅速增长。 物联网产品的数据收集和通信功能为企业与客户的互动创造了新的途径，并获得了新的营销数据来源。
下一代的网络将更加快速，这就是WebRTC（Web实时通信）发挥作用的地方。它专注于实时双向音频和视频通信，并通过端到端加密进行保护。这些功能可用于物联网设备用户之间的通信。
什么是WebRTC
WebRTC是Google于2011年发布的一个开源项目，它提供基于API的Web浏览器和移动应用程序之间的通信，包括音频、视频和数据的传输。 它消除了对本机插件和应用程序安装的依赖，使这些连接易于使用，并得到所有主要浏览器和移动操作系统的支持。
在过去的几年中，WebRTC在技术社区中的应用迅速发展。 Facebook、Amazon和Google都是实现WebRTC的主要技术公司之一，这些公司实现了WebRTC，从而使他们的Web应用程序更快、更可靠和更安全。WebRTC还提供现成的解决方案，可以轻松地与其他软件集成。
WebRTC技术概要
WebRTC是一套标准的而技术，可以使用Web或者移动应用程序通过浏览器实现强大的实时语音、视频、数据和视频会议等服务（如图1所示）。
如同一个基于浏览器的多媒体电话，或软件电话，它不但可以与其他的浏览器共同使用，也可与其他通信系统使用，如PSTN和VoIP。以前，如果试图建立的实时解决方案，必须依赖于昂贵的专用硬件和定制软件，需要投入把巨大的基础设施。但由于WebRTC的出现，在浏览器平台定义必要的接口后，就可以提供各种实时通信解决方案。这都归功于速度更快，高速计算硬件的出现。
2017 年 12 月，微信小程序向开发者开放了实时音视频能力，给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配，然而只有在原生的 APP 上才能保障良好的用户体验。
那时候，在微信小程序中无法进行实时音视频互动。微信小程序在去年 12 月宣布开放实时音视频能力，再加上去年 6 月苹果宣布即将支持 WebRTC，业内一下子千树万树梨花开，前途一片光明。
连麦互动直播技术和微信小程序以及 WebRTC 能产生怎么样的化学作用？开发者在微信小程序或者浏览器 WebRTC 上实现连麦互动直播技术的时候，需要知道什么和考虑什么？
连麦视频直播的客户端主要包括：原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。
有人说 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是编码流程，本篇文章打算先分析一下初始化流程。
