对网络协议来说，需要做的通常就两件事情：1、建立连接，2、传输数据，WebRTC也不例外。
假设WebRTC应用的两端已经建立了连接，那么，剩下就是如何传输数据的问题了。
WebRTC同时支持传输音视频数据、自定义应用数据。这其中，涉及多种协议，包括UDP、RTP/SRTP、RTCP/SRTCP、DTLS、SCTP。
这些协议名字比较相似，很容易让人混淆，简单总结下：
下面就简单介绍下，这些协议是做什么的，有什么区别，存在什么联系。
对WebRTC应用来说，不管是音视频数据，还是自定义应用数据，都要求基于加密的信道进行传输。DTLS 有点类似 TLS，在UDP的基础上，实现信道的加密。
DTLS的主要用途，就是让通信双方协商密钥，用来对数据进行加解密。
作者：deepstreamHub（原文链接）
翻译：刘通
原标题：WebRTC 06: File Transfer
上一篇：WebRTC教程—屏幕共享
WebRTC使得在两个浏览器间使用data-channels和二进制数据传输任意文件成为可能。
（点击图片跳转到原文查看例子）
二进制数据在浏览器中是如何工作的
目前的这代浏览器允许你发送字节数组—有八个0或1组成的集合，可以代表0到255之间的任何数字。为了完成这些，我们提供了一系列的概念—Uint8Array来储存它们，FileReader来创建它们，Blob来组合它们。像Websocket和WebRTC这样的传输工具允许传输原始字节流。
为什么很重要
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