WebRTC被誉为是web长期开源开发的一个新启元，是近年来web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或者点对点数据传输，不需要复杂的代码或者昂贵的配置。目前支持Chrome、Firefox和Opera，后续会支持更多的浏览器，它有能力达到数十亿的设备。
然而，WebRTC一直被误解为仅适合于浏览器。事实上，WebRTC最重要的一个特征是允许本地和web应用间的互操作，自然也可以在Android应用中植入WebRTC 。
WebRTC Android端的大体实现过程如下：（在不考虑播放本地视频的情况下）
RTSP（实时流协议）
RTSP中使用会话概念代替连接，由于它本身不与传输层绑定，因此RTSP会话在传输层支持TCP与UDP协议发送请求。RTSP客户机和服务器都可以发出请求，本身并不携带传输的媒体数据，而是控制RTP协议进行媒体数据传输。由于RTSP控制通过单独协议发送流，与控制通道无关，因此RTSP会话状态标记了服务器流资源的分配情况，如果对数据进行提取数据，需要同时进行流媒体数据传输协议（RTP协议）的解析。
Stun服务器 : 服务器用于获取设备的外部网络地址 Turn服务器 : 服务器是在点对点失败后用于通信中继 信令服务器 : 负责端到端的连接。两端在连接之初，需要交换信令，如sdp、candidate等，都是通过信令服务器 进行转发交换的。iOS PC BroswerMediaStream：通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流RTCPeerConnection：RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件RTCDataChannel：RTCDataChannel使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据。 其中RTCPeerConnection是我们WebRTC的核心组件。当我们使用像Skype、QQ这样的工具和朋友流畅地进行语音视频聊天时，我们可曾想过其背后有哪些强大的技术在支撑？本文将对网络语音通话所使用到的技术做一些简单的介绍，算是管中窥豹吧。
网络语音通话通常是双向的，就模型层面来说，这个双向是对称的。为了简单起见，我们讨论一个方向的通道就可以了。一方说话，另一方则听到声音。看似简单而迅捷，但是其背后的流程却是相当复杂的。我们将其经过的各个主要环节简化成下图所示的概念模型：
这是一个最基础的模型，由五个重要的环节构成：采集、编码、传送、解码、播放。
语音采集指的是从麦克风采集音频数据，即声音样本转换成数字信号。其涉及到几个重要的参数：采样频率、采样位数、声道数。
简单的来说：采样频率，就是在1秒内进行采集动作的次数；采样位数，就是每次采集动作得到的数据长度。
而一个音频帧的大小就等于：（采样频率×采样位数×声道数×时间）/8。
GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web 相关技术(如 JavaScript, HTML5). 所以, WebRTC 的源码结构非常庞大, 单单是从 trunk 中获取的代码和数据就达到1.2G还多.
不过, 如果明白了 WebRTC 的架构, 就可以从这份开源代码中摘出我们想要的部分. WebRTC 包含下面几个部分:
下面很多程序的安装之后都会要加入到环境变量中，先解释 一下什么叫环境变量。
当我们在cmd下输入命令的时候，例如cp，dir等命令，可以直接运行，而想执行一个打开chrome浏览器的chrome.exe命令时候,就会提示chrome.exe找不到等类似的错误，那是因为chrome.exe并没有被加入到环境变量中。你必须形如这样的方式"C:\Program Files\Google\Chrome\Application\chrome.exe",在cmd下才可以将chrome浏览器打开。
对于cmd下，会解析用户的输入，对于用户输入的命令，它会向系统变量和环境变量中的一个path参数下去寻找，有没有相应的可执行文件，于是如果你想执行svn命令，而svn.exe所在目录却并没有加入到环境变量的path路径中，那么cmd下就会报“命令不存在”的错误。加入命令到环境变量有这样的一个好处，对于一个命令不需要输入它的完整路径，而仅仅需要输入命令的名字就可以了，这可以给我们在cmd下执行命令提供相当大的方便。于是乎当下面安装的某一个程序提示需要加入到环境变量的时候，实际上就是说你在cmd下可以直接输入命令的名字就可以执行目录下的命令。
编译WebRTC之Android版本（AppRTC工程编译）
前言
准备工作
下载源码
编译依赖库
总结
前言
最近有项目需要用到android与web互通音视频，甚至与原生windows互通，很久没编译过了，所以今天亲自编译一下，并记录下来。
发起视频通话流程图如下
创建dsp描述符,CreateOffer在流程中位于 OnSignalingMessage(offer)
void CConductor::ConnectToPeer(int peer_id) {
if (peer_connection_.get()) {
LOG(LS_ERROR) <<
"We only support connecting to one peer at a time";
return;
}
if (InitializePeerConnection()) {
peer_connection_->CreateOffer(this, NULL);
}
else {
LOG(LS_ERROR) << "Failed to initialize PeerConnection";
}
}
说明：此系类的内容都是本人自己对libjingle native API代码的学习总结。其中可能存在不准确甚至是错误的内容。欢迎大家帮忙指出错误。
此文是个人根据WebRTC项目中的libjingle部分总结出来。只代表WebRTC中的libjingle部分的结构，不代表原始的libjingle项目。
国内现在很多语音聊天工具都是基于TURN方式实现的，包括YY、AK等等，这种方式对于服务器的性能要求很高，而且在用户量增大的时候，服务器压力也会越来越大，用户的语音质量也会受到很大影响。而基于P2P方式实现的语聊服务器，就可以极大的避免这种情况的发生，而且用户的语音体验也会非常好。
通过上文(P2P的原理和常见的实现方式(为libjingle开路))我们知道，因为NAT设备没有固定标准的原因，导致并不能100%的实现P2P，但是根据现在通用的ICE&STUN的方式，P2P的成功率可以达到90%多。前段时间在找使用这种方法实现的成熟库，最后猛然发现libjingle就在那里。
通过一个多星期的研究，在此记录一下libjingle库的大致情况，如有不妥，希望朋友们可以留言或者邮件(peakflys@gmail.com)指正。