关于WebRTC网上有好多介绍，这里我就不详细的叙述了。重点放在WebRTC的项目实施过程，涉及后续开发，将会有详细介绍。
WebRTC是由谷歌提出的一套基于UDP协议的网页流媒体协议。有以下几个特点：
1、网页间直接通信。即不需要安装任何插件，通过网页前端的JS程序，即可构建两端的通信。
2、NAT穿透。不需要中间流媒体服务器进行中转流媒体数据，通过NAT穿透协议ICE框架，即可实现NAT后的网页端的P2P的通信。
3、提供基于非网页端的开发库，以构建基于WebRTC视频传输的应用软件。
由于目前还在发展和普及阶段，所以只有Chrome、Firefox浏览器以及基于这两款浏览器的内核的浏览器支持WebRTC协议。这是因为Chrome、Firefox内核在底层由C++开发出供JS层调用的各种API，从而实现视频传输功能。
基本的WebRTC通信架构如图所示：
第一步：每个浏览器必须获取自己的“候选（通信）地址”。所谓“候选地址”，即一个PC机可能包含多个网卡，而同时又包含内网IP和外网IP（在ICE协议里，内网IP对应的外网IP被称为“反射地址”）。所以，WebRTC协议本身“借用”ICE协议（ICE协议包含stun协议和turn协议），获取最佳的通信IP，通过能够通信的IP地址来交换数据。譬如：内网IP在公网上是不能直接通信的，必须借用所在外网的IP地址来通信。而候选地址的提供由stun/turn服务器提供。好消息是，有许多公共的stun/turn服务器地址供直接使用。当然我们也可以搭建stun/turn服务器。关于ICE（也就是stun/turn协议）协议，后续会继续介绍。
第二步：获取的“候选地址”必须由信令服务器进行交换从而告知对方。初次之外，信令服务器还承担其他信息的交互比如SDP报文。（即媒体信息，如编码方式等）这些信息交换完成后，即可开始传输媒体数据。
第三步：媒体传输。当获取可以通信的IP地址后，即开始交换媒体数据。在WebRTC中媒体的传输有新的理解方式。以往我们了解的数据传输是由一端发到一端。在WebRTC中，网页端会构建一个媒体显示控件，当开始通信时，会把自己的摄像头加入“信令服务器”中。在本地端，当媒体显示控件绑定到本地摄像头时，将会显示本地视频，当媒体显示控件绑定远端摄像头时，即显示远端摄像头数据。WebRTC用这种方式实现视频的传输。（虽然本质也是视频发送接收，但注意WebRTC中在看待视频传输这个问题的角度和往常的socket的send、receive有不同的理解）
但是，此次项目有个需求就是，必须保存流媒体数据！所以，就必须有一个中间服务器进行中转，然后通过中间服务器来处理视频。目前开发较为完善的WebRTC流媒体服务器是：Kurento。所以接下来就是研究Kurento流媒体服务器的使用问题，以后简称KMS。
