这里只是记录学习过程中个人的理解，以及查找资料的汇总，如果有理解不对的地方，还望多多指点～
接下来，这篇文章会按照这样的思路来写，WebRtc 协议涉及到哪些模块？各个模块之间是如何联系起来的？
对webRtc还没简单了解的童鞋，可以先看上一篇文章，先有个基本了解。
WebRtc学习之旅 —— 初认识” https://blog.csdn.net/Mr_ZJC/article/details/96701962
一、WebRtc 协议涉及到哪些模块？
介绍各个细的模块之前，先来个大体的图看看（网上偷的图）
1> 电脑端为设备A，手机移动端为设备B，A 和 B之间现在采用WebRtc 协议，实现p2p的连接;
2> 我们知道，在局域网内，我们的设备需要和外网连接的时候，是需要通过路由（Route）转发的,外网想连上我们的设备，是通过 公网IP + port(端口号)的方式，才能访问到具体的设备。这个公网的IP，也就是路由的ip地址，而具体设备的端口号，是由路由配置的，这里有个名称，叫做NAT(网络地址转换,Network Address Translation)，就是专门对想访问外网的设备，通过路由的NAT，然后才能访问到其它设备。
3> 那我们设备A，想要跳过路由，直接p2p 连接，就得知道连接方的外网ip和对应的端口号。那怎么才能做到呢？
4> 也就是我们需要有个服务器帮我们知道自己的路由ip和路由给自己配置的端口号，这个服务器就是stun 服务器,我们给stun 服务器发送请求，然后stun服务器会返回我们ip + port,这里还需要注意下，并不是所有情况下我们都能如愿的获取到自己的ip + port ,有些路由做了更多的限制（这里有兴趣的可以了解下NAT的各种类型），我们给stun 发送请求，是无法得到我们想要的信息的，这时2方想实现通信，就得借助另外的turn 服务器了,turn 服务器相当于个中转站，这个turn 服务器就有点像流媒体服务器了，双方发生的包都得经过turn服务器进行中转，这时turn服务器的负载也比较大。 ICE（Interactive Connectivity Establishment），它是一套框架，会帮我们决策采用最好的方式连接对方,这套框架里面，会优先采用连接stun服务器的方式，如果不行，会转用turn服务器。
5> 上面的图片，我们还看到有个signaling服务器，是的，这个就叫做信令服务器，2个设备进行连接，需要相互告诉对方各种处理音视频的能力，也就是音视频的码率、分辨率这些信息，这个是通过信令服务器来完成的，信令服务器不需要知道发生的内容，只需要负责转发信息即可。包括我们通过turn服务器获取到了路由的ip+port,这些信息也是通过信令服务器来转发给对方的。
好了，写到这里，我们来再理下webRtc协议都有哪些东西：
i、信令服务器
ii、stun服务器
iii、turn服务器
也就是我们需要3个服务器（至少需要2个，turn看情况看是否需要），如果只是局域网内的通信，则只需要信令服务器即可。
我们还需要了解一些概论：NAT 、ICE （这些概率继续看下面详细介绍）
二、webRtc 协议各个模块介绍
上面结合图片，我们大体看了些webRtc 协议涉及到的一些模块，下面就更详细的了解下各个模块的功能。
这里直接贴出*找到的一些资料，个人觉的介绍的还是比较清晰的。
ICE
Interactive Connectivity Establishment (ICE) is a framework to allow your web browser to connect with peers. There are many reasons why a straight up connection from Peer A to Peer B simply won’t work. It needs to bypass firewalls that would prevent opening connections, give you a unique address if like most situations your device doesn’t have a public IP address, and relay data through a server if your router doesn’t allow you to directly connect with peers. ICE uses STUN and/or TURN servers to accomplish this, as described below.
STUN
Session Traversal Utilities for NAT (STUN) (acronym within an acronym) is a protocol to discover your public address and determine any restrictions in your router that would prevent a direct connection with a peer.
The client will send a request to a STUN server on the Internet who will reply with the client’s public address and whether or not the client is accessible behind the router’s NAT.
NAT
Network Address Translation (NAT) is used to give your device a public IP address. A router will have a public IP address and every device connected to the router will have a private IP address. Requests will be translated from the device’s private IP to the router’s public IP with a unique port. That way you don’t need a unique public IP for each device but can still be discovered on the Internet.
Some routers will have restrictions on who can connect to devices on the network. This can mean that even though we have the public IP address found by the STUN server, not anyone can create a connection. In this situation we need to turn to TURN.
TURN
Some routers using NAT employ a restriction called ‘Symmetric NAT’. This means the router will only accept connections from peers you’ve previously connected to.
Traversal Using Relays around NAT (TURN) is meant to bypass the Symmetric NAT restriction by opening a connection with a TURN server and relaying all information through that server. You would create a connection with a TURN server and tell all peers to send packets to the server which will then be forwarded to you. This obviously comes with some overhead so it is only used if there are no other alternatives.
SDP
Session Description Protocol (SDP) is a standard for describing the multimedia content of the connection such as resolution, formats, codecs, encryption, etc. so that both peers can understand each other once the data is transferring. This is, in essence, the metadata describing the content and not the media content itself.
Technically, then, SDP is not truly a protocol, but a data format used to describe connection that shares media between devices.
Documenting SDP is well outside the scope of this documentation; however, there are a few things worth noting here.
下面这张图，也是大体描述了基于webRtc 的p2p连接过程：
三、信令交互流程
上面我们有介绍到设备端各子的媒体处理能力等信息，需要通过信令服务器来转发。对于连接的双方来说，一个是请求连接发起端，一个是接收端，它们之间的信令交互也是有一套流程的。
简单来说，就是3个流程，“init”请求、offer信令、answer信令。
发起端发生 “init”请求请求连接，接收端接收到请求后，回应offer信令，发起端接收到offer信令后，发生answer信令，具体发送的内容，这个后面的文章，结合android上的代码来进一步了解，这里先有个大概的认识。
-----2019-07-21 23:35 周六
=======================================================================