WebRTC的源码中自带了一个turnserver，编译之后，会在out/Default下生成一个turnserver文件，可以充当STUN和TURN server。用法如下：
./turnserver int_addr ext_addr realm auth_fileint_addr指的是面对turnclient，接收turnclient数据的ip和端口，形式是host:port，例如192.168.1.12:3478。
ext_addr是公共IP（可能是公网IP，内网使用则可能是相对于NAT的公共IP），例如192.168.1.12。
realm是类似example.com之类的。
官网在这里：https://webrtc.org/。然后这里有一个官方的Getting Started：https://webrtc.org/start/。
Google关于WebRTC的幻灯片：
然后是WebRTC的SPEC：
WebRTC项目源码地址：https://chromium.googlesource.com/external/webrtc。
Native开发文档：https://webrtc.org/native-code/development/。
JS端的API文档：http://w3c.github.io/webrtc-pc/。
维基百科对WebRTC的介绍：https://en.wikipedia.org/wiki/WebRTC。
WebRTC工作组：https://www.w3.org/2011/04/webrtc/。
假如你在企业内使用WebRTC，可能会遇到UDP端口被封的情况，这个时候可以强制WebRTC使用TCP转发模式。
要使用TCP转发，得配合一个 turn server，开源的 coturn 实现了 TCP 转发，我在“Ubuntu Server 14.04下配置coturn for WebRTC”一文中介绍了如何安装配置，可以参考。
配置了 coturn 后，在 Chrome 内建立 PeerConnection 对象时，做个配置，就可以实现转发了，类似下面：
NAT给设备提供了一个IP地址以使用专用局域网，但是这个地址不能在外部使用。由于没有公用地址，WebRTC对等端就无法进行通信。而WebRTC使用 STUN来解决这个问题。
STUN服务器位于公共网络上，并且有一个简单的任务：检查传入请求的IP地址（来自运行在NAT后面的应用程序），并将该地址作为响应发送回去。换句话说，应用程序使用 STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址，然后通过信令机制将其传递给另一个对等端以建立直接链接。（实际上不同NAT工作方式都有所不同，可能有多个NAT层，但是原理是一样的）。
因为 STUN服务器不需要做太多的工作或者记特别多的东西，所以相对低规格的 STUN服务器就可以处理大量的请求。
根据webrtcstats.com的统计（2013年），大多数WebRTC通话都成功地使用 STUN进行连接，有86%。尽管对于防火墙之后的对等端之间的呼叫以及复杂的NAT配置，成功通话量会更少一些。
原文：WebRTC in the real world: STUN, TURN and signaling By Sam Dutton
WebRTC 实现了网页点对点交流。
但是…
WebRTC 仍然需要服务器来:
本文将向你展示如何建立一个信令服务器，并使用STUN和TURN服务器来处理实际应用中出现的一些怪异的连接问题。也将解释WebRTC应用是如何处理多方通讯并与类似VoIP、PSTN的服务互动的。
如果你没有了解过WebRTC，我强烈建议你在看这篇文章之前先看看这篇文章 Getting Started With WebRTC
1.Ubuntu下安装coturn：
apt-get install coturn，源码：http://turnserver.open-sys.org/downloads/
安装类似下面：
sudo -i
# ignore if you already in admin mode
apt-get update && apt-get install libssl-dev libevent-dev libhiredis-dev make -y
# install the dependencies
让人类通过网络进行音视频通信是网络最后的巨大挑战：实时通信( RTC )。实时通信就像网络上在文本框中输入文本一样自然，没有它，就限制了我们开发新的方式使人们互动交流起来。
从历史上看，RTC 变化很大很复杂，需要昂贵的音视频技术授权或者花费巨大代价去开发，RTC 技术与现有的内容、数据和服务整合一直都很困难和耗时，在网络上尤其如此。
Gmail 视频聊天在 2008 年开始流行，在 2011 年 Google 推出视频群聊，它使用 GoogleTalk 服务，就像 Gmail 一样。Google 收购了 GIPS，它是一个为 RTC 开发出许多组件的一个公司，例如编解码和回声消除技术。Google 开源了 GIPS 开发的技术，与相关机构 IET 和 W3C 制定行业标准。在 2011 年 5 月，爱立信实现第一 个 WebRTC应用。
WebRTC 已经实现了对于实时通信，免插件音频数据传输的标准制定。需求是：
- 许多网络服务已经使用了 RTC，但是需要下载，本地应用或者是插件。包括 Skype、Facebook、Google Hangouts。
- 下载安装升级插件是复杂的，可能出错的，令人厌烦的。
- 插件可能很难部署、调试、故障排除等——可能需要技术授权，复杂集成和昂贵的技术。说服人们去安装插件是很难的。
WebRTC 项目的指导原则是APIs应该是开源的，免费的，标准化的，浏览器内置的，比现有技术更高效的。
这两年来，WebRTC 越来越频繁地出现在人们的视野，在在线教育、在线医疗等领域的应用也越来越多。大家研究 WebRTC 的热情也越来越高涨，不过 WebRTC 的入门门槛个人觉得稍微有些高，特别是各种概念，比如 NAT 穿越，ICE、STUN、TURN、Signaling server等，刚开始可能会觉得比较繁杂，不易理解。然后建立连接的整个过程，异步调用比较多，很容易搞混。那么这篇文章里我们会根据 WebRTC 的官方 demo AppRTC 的 iOS 版本来分析一下 WebRTC 从进入房间到建立音视频连接的过程，为了便于了解，我们本次的讨论不涉及到底层的具体实现。
我们首先来简单地了解几个概念：
因为 WebRTC 是 P2P 的，很多时候 peer 是隐藏在 NAT 之后，没有外网的 IP 地址，如果两个 peer 都在 NAT 后面，都没有外网的 IP (或者说都不知道自己的外网 IP)，是无法建立连接的。那么 NAT 穿越就是用来解决这个问题的，NAT 穿越也俗称 “P2P 打洞”。常见的两种穿越方式是 STUN 和 TURN。
如果我们想要理解 HTML5 视频，首先需要知道，你应该知道，但你不知道的内容？那怎么去判断呢？ ok，很简单，我提几个问题即可，如果某些童鞋知道答案的话，可以直接跳过。
.）这些叫做什么吗？当然，还有一些问题，我这里就不废话了。上面主要想说的其实就两个概念：视频文件格式（容器格式），视频编解码器（视频编码格式）。当然，还有另外一种，叫做音频编解码器。简而言之，就是这三个概念比较重要：
这里，我们主要讲解一下前面两个。视频一开始会由两个端采集，一个是视频输入口，是一个音频输入口。然后，采集的数据会分别进行相关处理，简而言之就是，将视频/音频流，通过一定的手段转换为比特流。最终，将这里比特流以一定顺序放到一个盒子里进行存放，从而生成我们最终所看到的，比如，mp4/mp3/flv 等等音视频格式。
视频编码格式就是我们上面提到的第一步，将物理流转换为比特流，并且进行压缩。同样，它的压缩编码格式会决定它的视频文件格式。所以，第一步很重要。针对于 HTML5 中的 video/audio，它实际上是支持多种编码格式的，但局限于各浏览器厂家的普及度，目前视频格式支持度最高的是 MPEG-4/H.264，音频则是 MP3/AC3。（下面就主要说下视频的，音频就先不谈了。）
目前市面上，主流浏览器支持的几个有：