摘要
如果一台主机处于NAT后面，那么在一定条件下两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。
这个规范定义了一个名为TURN(使用中继穿越NAT)的协议，它允许一台主机使用中继服务与对端进行报文传输。TURN不同于其它中继协议在于它
允许客户机使用一个中继地址与多个对端同时进行通讯。
TURN协议也是ICE(交互式连接建立)协议的组成部分，也可以单独使用。
在现实Internet网络环境中，大多数计算机主机都位于防火墙或NAT之后，只有少部分主机能够直接接入Internet。很多时候，我们希望网络中的两台主机能够直接进行通信，即所谓的P2P通信，而不需要其他公共服务器的中转。由于主机可能位于防火墙或NAT之后，在进行P2P通信之前，我们需要进行检测以确认它们之间能否进行P2P通信以及如何通信。这种技术通常称为NAT穿透（NAT Traversal）。最常见的NAT穿透是基于UDP的技术，如RFC3489中定义的STUN协议。
STUN，首先在RFC3489中定义，作为一个完整的NAT穿透解决方案，英文全称是Simple Traversal of UDP Through NATs，即简单的用UDP穿透NAT。
在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具，而不是一个完整的解决方案，英文全称是Session Traversal Utilities for NAT，即NAT会话穿透效用。RFC5389与RFC3489除了名称变化外，最大的区别是支持TCP穿透。
TURN，首先在RFC5766中定义，英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中继穿透NAT:STUN的扩展。简单的说，TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。
RFC3489的劣势：一、NAT穿透有时会失败，但没有失败补救措施；二、NAT分类算法不适用于现代的很多NAT类型；三、安全弱点。
与RFC3489不同，该文档不再把STUN描述为解决NAT穿透的完整解决方案，而是将STUN作为一种工具集成到其他更完备的解决方案中去，例如本协议的扩展可用于ICE的两个端点之间的连接检测、用于TURN的的两个端点之间的包中转、用于SIP的客户端初始化连接。
该文档描述的STUN可运行在UDP、TLS/TCP、TCP上。
Stun协议的格式，定义在https://www.ietf.org/rfc/rfc3489.txt
11.1 Message Header
All STUN messages consist of a 20 byte header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transaction ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STUN的探测过程需要有一个公网IP的STUN server，在NAT后面的UAC必须和此server配合，互相之间发送若干个UDP数据包。UDP包中包含有UAC需要了解的信息，比如NAT外网IP，PORT等等。UAC通过是否得到这个UDP包和包中的数据判断自己的NAT类型。
假设有如下UAC（B），NAT（A），SERVER（C），UAC的IP为IPB，NAT的IP为 IPA ，SERVER的 IP为IPC1 、IPC2。请注意，服务器C有两个IP，后面你会理解为什么需要两个IP。
Restund is a modular and flexible STUN and TURN Server, with IPv4 and IPv6 support.
1) Requirements
In order to compile TurnServer, you need the followings packages :
本人最早接触WebRTC是在2011年底，
那时Google已经在Android源码中加入了webrtc源码，放在/external/webrtc/，
但是Android并没有用到它，更没有被浏览器使用。
当时试图在Android 2.3（Gingerbread）高通平台的手机上
用H.264 硬件codec替换掉WebRTC缺省使用的VP8软codec，费了不少劲勉强换掉后效果很差只得放弃。
最近得知Google最新版的Chrome for Android已经支持WebRTC，
应老板的要求搭一个手机浏览器上视频通信的demo，
为此在网上搜集各种资料，发现经过一年多的发展，
国内外研究和使用WebRTC的人明显多起来，可用的demo也很多。
在此做一个笔记，留作日后参考。
目前基于WebRTC的开发其实有两个方向，
一个是基于浏览器的WebRTC应用开发，编程语言主要是JavaScript、HTML等，
这也是WebRTC作为HTML5标准的组成部分原本的目的；
前段时间上手了NAT打洞类库ice4j（ICE框架），当时使用了numb.viagenie.ca的公共STUN服务器。最近又编译了rfc5766-turn-server，于是今天将两者结合起来，一个作为服务端，一个作为Peer端的协议，试验广域网穿透多级路由即时点对点通讯，并取得了成功。
rfc5766-turn-server是谷歌推荐的turn开源项目，经常作WebRTC的服务器端使用。关于rfc5766-turn-server在Windows或Ubuntu（Linux）下的编译，请参考 http://www.hankcs.com/program/network/compile-rfc5766-turn-server-to-build-turn-server.html 。这里假定你已经编译完成，输入
得到如下结果说明编译成功：
对于实时通讯来说WebRTC技术是一个革命性的存在，主要基于WebRTC开启软MCU的零客户端新时代，例如谷歌、英特尔、华为、微软、阿里、甲骨文、腾讯、奥科等国际巨头，投入都纷纷布局5G时代下的视频通信市场，本篇帖子，重点介绍英特尔在WebRTC方面的研发成果。