WebRTC: Web Real-Time Communication
ICE：ICE全名叫交互式连接建立(Interactive Connectivity Establishment)
STUN：Session Traversal Utilities for NAT
TURN：Traversal Using Relay NAT数据发送端和接收端都需要通过公网服务器进行转发（因为发送端和接收端通常都做了NAT，彼此并不知对方实际位置）。
犹如一个中国人和一个外国人，他们彼此不懂对方的语言，不知道对方的地址，但是中间有一个邮局知道对方的地址，因为对方都在邮局做了注册地址并且获取了同一个编号，那么如果他们之间需要互相通信的话，就需要和邮局联系，邮局会进行翻译并发往同一编号的对应地址。 但是这中间就会产生一个问题，这时候如果有多个中国人和多个外国人都要进行通信，那么邮局的工作量就会越来越大，当他们的通信超过原有邮局人手可处理规模时，邮局要么扩招（需要钱）要么延缓发送（会造成延迟，甚至丢失信件）。
怎么办？这时我们就要考虑另外一种解决方案了。我们让发送端直接发送数据给接收端，这样就可以省掉服务器的转发功能了是不是？当然是，但是如我们上述例子所说，中国人不懂俄语，俄罗斯人不懂中文，鸡同鸭讲眼碌碌。他们之间怎么通信呢？邮局觉得上述方式太不靠谱了，于是决定通过一种技术，当有一个中国人或者外国人寻求转发时，邮局通过“魔法”查找出了对方地址，并且不说话丢给了对方一只翻译面包，对方接收到翻译面包后可以习得对方语言，直接和对方通话。
例子中的“魔法”就是本文要介绍的 ICE框架，而翻译面包就是NAT穿越技术。
在真实世界的网络中，因为IPv4的地址个数问题，我们基本都是采用NAT连接的：
当处于以上网络时，Peer和Peer之间基本都是通过NAT和防火墙连接上互联网的，所以当我们要建立两端之间的直接通信时，我们需要服务器对两端进行Signalling，具体如何进行Signalling会在下篇文章中介绍。本文假设两端已经Signalling完毕。
- ICE框架 （ICE会尝试找到端与端之间最优连接路径）会完成以下工作：
·首先ICE会直接利用主机地址和网卡地址进行连接，如果刚好端拥有公网IP（无NAT），那么此时可以直接建立连接。
·如果第一步失败，ICE会尝试建立STUN连接。
·如果第二步失败，ICE会利用TURN服务器建立连接。
STUN（Session Traversal Utilities for NAT）
STUN服务器提供的功能十分简单，它让使用者获取自己所在的公网地址和在NAT中所映射端口号，这个服务有什么用呢？当使用者知道自己所在公网地址以及内部NAT映射端口时，它便可以讲自己的公网地址和端口号通知对方，这样对方就可以在茫茫大网中找到自己。在以往统计中，WebRTC通过STUN建立连接的成功率为86%。TURN（Traversal Using Relay NAT）
TURN是一个client-server协议。TURN的NAT穿透方法与STUN类似，都是通过取得应用层中的公有地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生”relay port”，也就是relayed-transport-address。这时TURN server会建立peer，即远端端点（remote endpoints），开始进行中继（relay）的动作，TURN client利用relay port将资料传送至peer，再由peer转传到另一方的TURN client。
webrtc的P2P穿透部分是由libjingle实现的.
步骤顺序大概是这样的:
- 尝试直连.
- 通过stun服务器进行穿透
- 无法穿透则通过turn服务器中转.
android socket.io聊天demo: https://dev.to/medaymentn/creating-a-realtime-chat-app-with-android--nodejs-and-socketio-4o55
How does webrtc work?
Before we start exchanging data between two peers via webrtc, we need to provide info to the peers about each other for media format negotiation and discovery.
This is done via following protocols. Interactive Connectivity Establishment (ICE) is used for connecting peer to peer. Session Description Protocol (SDP) is used to provide the metadata of the media content like resolution, encoding, bitrate, etc.
If the two peers are not on same network then we will need to provide a Session Traversal Utilities for NAT (STUN) server to provide the public address of the peers.
If any of the network is firewall protected the we need to provide Traversal Using Relays around NAT (TURN) servers also.
You can learn more about these protocols here. The mechanism to exchange ICE and SDP between the peers is called Signalling System and is usually done via websockets.
https://hackernoon.com/real-time-communication-with-webrtc-on-android-f96cdcfc4771
https://webrtc.org/native-code/android/
https://github.com/muaz-khan/WebRTC-Experiment
List<PeerConnection.IceServer> iceServers = new ArrayList<>();
https://blog.csdn.net/rayxiang520/article/details/78432838
国内免费可用的STUN服务器(webrtc 必备）
stun:stun1.l.google.com:19302
stun:stun2.l.google.com:19302
stun:stun3.l.google.com:19302
stun:stun4.l.google.com:19302
stun:23.21.150.121
stun:stun01.sipphone.com
stun:stun.ekiga.net
stun:stun.fwdnet.net
stun:stun.ideasip.com
stun:stun.iptel.org
stun:stun.rixtelecom.se
stun:stun.schlund.de
stun:stunserver.org
stun:stun.softjoys.com
stun:stun.voiparound.com
stun:stun.voipbuster.com
stun:stun.voipstunt.com
stun:stun.voxgratia.org
stun:stun.xten.com
webrtc的stun服务器无法穿透国内三大运营商4G
最近在研究P2P视频通信，由于要集成到APP中，信令服务器与STUN服务器都是部署在公网上(阿里云)。经过测试最终结果如下：
同一个局域网的两台移动设备可以连接进行通信
移动4G与WiFi，移动4G与联通4G，移动4G与电信4G都是可以连通进行通信
联通4G与WiFi，电信4G与WiFi，WiFi与WiFi偶尔可以通信，但是大多数是不可以连通的
以上情况是在STUN穿透服务器下测试的，只要使用TURN服务器进行穿透的话都是可以连通的，但是不太理解STUN服务器为什么不能穿透联通和电信的4G网络。经过后端和前端的debug及查阅相关资料得到如下发现：
运营商的NAT给电信4G或者联通4G分配的内网外网IP映射每次切换数据网络是一直变化的
电信4G与联通4G分配是多IP，而移动的4G分配的公网IP是不变的(在P2P连接使用中)，电信、联通4G分配的公网IP一直是变化的且前后端debug到的ip是不同的
当两台移动设备尝试建立连接时，如果通过STUN服务器无法穿透，STUN服务器的日志中显示双方在不断的尝试穿透
但是问题依然没有解决，所以想请教下各位大牛，联通和电信的内部NAT是什么类型的（如果是对称型NAT就只能依赖TURN服务器转发了）？联通电信分配的公网IP为什么一直是变化的？能否更改stun配置来固定分配一个可直接两客户端直接建立连接的公网IP？当然前提是使用STUN进行穿透，暂时不考虑TURN（因为它都能穿透^_^）希望大家指点一下！
https://github.com/webrtc/samples
Android IOS WebRTC 音视频开发总结(有87篇博文): https://www.cnblogs.com/lingyunhu/tag/webrtc%20android%20ios/
PeerConnection只是用来出来处理客户端与服务端连接的,音视频采集在其他模块里面.
博主，您研究过apprtc的server搭建吗？
一、自由职业：
1、职位1：
1.1、熟悉XMPP和openfire，客户想将IM功能外包给熟悉的人士完成，如果觉得您能胜任，我帮您推荐，价格你们自己协商。
2、职位2：
2.1、熟悉nodejs和socket.io，客户IM采用nodejs和socket.io的方案，需找熟悉nodejs的人士完成服务端功能。
3、职位3：
3.1、熟悉WebRTC，熟悉Android或iOS或PC（此职位有全职的，只要告诉我您在哪就行）
2、培训讲师：
2.1、语音通讯专家：有编解码、回声、噪声、抖动、语音合成方面的开发经验。
2.2、视频通讯专家：有图像合成、MCU、编解码，FEC方面的开发经验。
2.3、移动支付专家：熟悉移动支付开发，最好在BAT等企业有从事过具体开发工作。