WebRTC使得实时通信变成一种标准功能，任何Web应用都无需借助第三方插件和专有软件，而是通过简单地JavaScript API即可完成。
在WebRTC中，有三个主要的知识点，理解了这三个知识点，也就理解了WebRTC的底层实现原理。这三个知识点分别是：
实时传送协议（Real-time Transport Protocol或简写RTP，也可以写成RTTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。
RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTCP协议或者RTSP协议）。因为RTP自身具有Time stamp所以在ffmpeg 中被用做一种formate.
RTP协议格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上图引自rfc3550，由上图中可知道RTP报文由两个部分构成--RTP报头和RTP的负载：
WebRTC（网页实时通信技术）是一系列为了建立端到端文本或者随机数据的规范，标准，API和概念的统称。这些对等端通常是由两个浏览器组成，但是WebRTC也可以被用于在客户端和服务器之间建立通信连接，或者在任何其他可以实施WebRTC标准的设备之间进行通信建立。
WebRTC是一个开源项目，可在浏览器中实现无插件的实时通信（RTC）。它包括用于高质量通信的基本构建模块，
例如用于语音和视频聊天应用的网络，音频和视频组件。这些组件在浏览器中实现时，可以通过JavaScript API访问，
使开发人员能够轻松实现自己的RTC Web应用程序。
WebRTC由三个API组成：
GetUserMedia（摄像头和麦克风访问）
PeerConnection（发送和接收媒体）
DataChannels（在浏览器之间直接发送非媒体）
视频编解码对许多Android程序员来说都是Android中比较难的一个知识点。在Android 4.1以前，Android并没有提供硬编硬解的API，所以之前基本上都是采用FFMpeg来做视频软件编解码的，现在FFMpeg在Android的编解码上依旧广泛应用。本篇博客主要讲到的是利用Android4.1增加的API MediaCodec和Android 4.3增加的API MediaMuxer进行Mp4视频的录制。
通常来说，对于同一平台同一硬件环境，硬编硬解的速度是快于软件编解码的。而且相比软件编解码的高CPU占用率来说，硬件编解码也有很大的优势，所以在硬件支持的情况下，一般硬件编解码是我们的首选。
在Android中，我们可以直接使用MediaRecord来进行录像，但是在很多适合MediaRecord并不能满足我们的需求，比如我们需要对录制的视频加水印或者其他处理后，所有的平台都按照同一的大小传输到服务器等。
在本篇博客中，将会讲到的是利用AudioRecord录音，利用OpenGL渲染相机数据并做处理。然后利用MediaCodec对音频和视频分别进行编码，使用MediaMuxer将编码后的音视频进行混合保存为Mp4的编码过程与代码示例。
值得注意的是，音视频编解码用到的MediaCodec是Android 4.1新增的API，音视频混合用到的MediaMuxer是Android 4.3新增的API，所以本篇博客的示例只实用于Android 4.3以上的设备。
这次的需求，准备做的是一个类似与QQ视频一样的点对点视频聊天。这几天了解了一些知识后，决定使用HTML5新支持的WebRtc来作为视频通讯。客户端使用支持HTML5浏览器即可。服务器段需要提供两个主要的服务功能，一个是信令服务器(Signaling Server)，一个是NAT穿透服务器(ICE Server)。简单的框架图如下:
注1：本文档适用于webrtc和webrtc-android源码的下载和编译；
注2：下载编译所使用的操作系统为Ubuntu 14.04.3 LTS;
Chromium和Chromium OS统一使用一个叫做depot_tools的工具的对其源码进行checkout的管理（这有点类似于Android使用repo工具对其源码进行管理一样），作为Chromium其中一个子模块的webrtc而言，也是使用这个工具对其代码进行checkout。这个depot_rools包里面包含了gclient、gcl、git-cl、repo等工具。
下载depot_tools工具包并放到标准路径PATH上：
首先确保Linux上安装了Git 2.2.1以上版本，以及Python 2.7以上版本；
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
修改HOME目录中的.bashrc文件，在最后增加：PATH="~/bin/depot_tools:$PATH"，注意一定要把depot_tools的位置放在PATH的最前面；
参考：https://dev.chromium.org/developers/how-tos/install-depot-tools
http://blog.sina.com.cn/s/blog_40d608bb01010n73.html
http://www.cnblogs.com/fangkm/p/4370492.html
http://mojiapp.cn/a/yuanmashili/2015/0708/542.html
http://max.book118.com/html/2015/1228/32140782.shtm
https://www.slideshare.net/libfetion/webrtc
https://chromium.googlesource.com/external/webrtc/+/master
https://source.codeaurora.org/quic/lc/external/webrtc/tree/webrtc?h=chromium.org/master
在一般的数字楼宇对讲系统应用中，对讲双方需要进行实时的语音交流，而在室内或是楼道门E1都采用外置音箱放音的形式，这势必会产生回声H。21，即通话的一方说话后通过网络传到通话另一方的音箱进行播放，然后播放出来的声音又被另一方的传声器采集到并且通过网络传回自己。这时，回声的产生将会影响对讲的通话质量和用户对于楼宇对讲产品体验，而对于现在新兴的Android数字楼宇对讲系统。更是如此。目前Android数字楼宇对讲系统中的回声消除技术实现有以下3方面的难点和问题：
1)Android本地实时回声消除技术问题Android系统是便携式嵌入式系统，软硬件的计算资源相对有限，很多在Windows系统等PC机平台上应用很成熟的回声消除算法和技术到Android平台上可能都会出现一些适应性问题。
2)回声消除中音频采集、播放的延时问题因为Android不是实时操作系统，造成传声器的录音、音响的放音之间都有一定时延，而且这个时延每个Android设备可能都不一样，这样即便有很好的回声消除方法，由于不能将录音、放音对齐将会使得回声消除没有效果或是消去正常通话声音，这会进一步增加Android回声消除难度。
3)Android回声消除的平台移植性
目前，Android版本很多，如何使Android回声消除技术能应用于多样的终端上是一个现实问题。
为了解决以上问题，采用WebRTC的回声消除模块实现Android本地实时回声消除，并设计了多线程编程技术实现音频采集、播放的同步，解决了Android楼宇对讲系统的回声问题，最后利用JNI(Java Native Interface——JAVA本地调用)技术将Android楼宇对讲系统回声消除程序进行封装，便于不同Android平台的移植。
