Webrtc 介绍与Demo环境搭建
一，webrtc的基本介绍
WebRTC是一个开源项目，提供简单的JavaScript接口以实现浏览器的实时通信（RTC）。与普通的客户端与服务器之间的即时通信不同，webrtc通过一系列的信令，能建立起一个浏览器与浏览器之间（peer-to-peer）的信道，这个信道可以发送任何数据，包括音视频数据，而不需要经过服务器。
WebRTC通过实现MediaStream，调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频
WebRTC applications need to do several things:
* Get streamingaudio, video or other data.
* Get networkinformation such as IP addresses and ports, and exchange this with other WebRTCclients (known as peers) to enable connection, even through NATs and firewalls.
* Coordinatesignaling communication to report errors and initiate or close sessions.
* Exchangeinformation about media and client capability, such as resolution and codecs.
* Communicate streamingaudio, video or data.
To acquire and communicate streaming data, WebRTCimplements the following APIs:
* MediaStream:get access to data streams, such as from the user's camera and microphone.
*RTCPeerConnection: audio or video calling, with facilities for encryption andbandwidth management.
* RTCDataChannel:peer-to-peer communication of generic data.
现在WebRTC已经可以在较新版的Chrome、Opera和Firefox中使用了，著名的浏览器兼容性查询网站caniuse上给出了一份详尽的浏览器兼容情况。国内大部分主流浏览器都支持（如：360极速浏览器，傲游，搜狗等）。
支持的操作系统平台有：ios, android。
从https://webrtc.org/start/开始认识webrtc.
网络拓扑图：
上面是一个简单的webrtc系统网络拓扑图，其中链路1表示终端从服务器上获取前端页面；链路2表示信令交互过程；链路3表示NAT穿透过程；链路4是终端数据交互。
二， webrtc的信令框架
1) Whatis signaling?
WebRTC uses RTCPeerConnection to communicate streamingdata between browsers, but also needs a mechanism to coordinate communicationand to send control messages, a process known as signaling. Signaling methodsand protocols are not specified by WebRTC.
Instead, WebRTC app developers can choose whatevermessaging protocol they prefer, such as SIP or XMPP, and any appropriate duplex(two-way) communication channel. The apprtc.appspot.com example usesXHR and the Channel API as the signaling mechanism. The codelab webuilt uses Socket.io runningon a Node server.
WEBRTC支持点对点数据通讯,但仍然需要服务端来协调双方的信令消息。在Webrtc规范中未定义信令相关的方法和协议，也就是说信令服务器和控制机制是由应用开发者来自已定义和实现。
至于为什么对信令机制不作定义，有以下的解释：
Why is signaling not defined by WebRTC?
To avoidredundancy and to maximize compatibility with established technologies,signaling methods and protocols are not specified by WebRTC standards.
2) What does signaling do?
Signaling is used to exchange three types of information:
* Session control messages: to initialize or closecommunication and report errors.
* Network configuration: to the outside world, what's mycomputer's IP address and port?
* Media capabilities: what codecs and resolutions can behandled by my browser and the browser it wants to communicate with?
信令机制用来交换三类信息：
*会话控制消息：初始化或关闭通讯通道，上报各种异常；
*网络配置：对于其它设备，主机的IP地址和端口号（包括NAT穿透相关的信息）；
*媒体能力：本机支持的编解码格式和分辨率信息，以及所期望的相关媒体信息。
同时，我觉得对信令服务器加以扩展，使其能支持以下功能：
1. 客户端管理与相互之间的发现，以及基础信息交互；
2. NAT/防火墙穿透失败后，也就是P2P通信失败，协调中转服务器为客户端服务；
3) How does signaling work?
WebRTC clients (known as peers, aka Alice and Bob) alsoneed to ascertain and exchange local and remote audio and video mediainformation, such as resolution and codec capabilities. Signaling to exchangemedia configuration information proceeds by exchanging an offer and an answerusing the Session Description Protocol (SDP):
1. Alice runs theRTCPeerConnection createOffer() method. The callback argument of this is passedan RTCSessionDescription: Alice's local session description.
2. In thecallback, Alice sets the local description using setLocalDescription() and thensends this session description to Bob via their signaling channel. Note thatRTCPeerConnection won't start gathering candidates until setLocalDescription()is called: this is codified in JSEP IETF draft.
3. Bob sets thedescription Alice sent him as the remote description using setRemoteDescription().
4. Bob runs theRTCPeerConnection createAnswer() method, passing it the remote description hegot from Alice, so a local session can be generated that is compatible withhers. The createAnswer() callback is passed an RTCSessionDescription: Bob setsthat as the local description and sends it to Alice.
5. When Alicegets Bob's session description, she sets that as the remote description with setRemoteDescription.
6. Ping!
RTCSessionDescription objects are blobs that conform tothe Session Description Protocol, SDP. Serialized, an SDP object looks likethis:
v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
// ...
a=ssrc:2223794119label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810
另外Alice和Bob也需要交换网络信息(即candidates):
1,Alice创建RTCPeerConnection对象时设置onicecandidate handler；
2,当有新的candidates找到的时候，会调用hander，并将candidates内容通过信令通道传递给Bob；
3,当Bob收到来自Alice的candidate消息的时候,他调用方法addIceCandidate(),添加candidate到远端描述里面。
The offer/answer architecture described above is calledJSEP, JavaScript Session Establishment Protocol.
JSEP architecture Once the signaling process hascompleted successfully, data can be streamed directly peer to peer, between thecaller and callee—or if that fails, via an intermediaryrelay server (more about that below). Streaming is the job of RTCPeerConnection.
JSEP支持ICE Candidate Trickling,他允许呼叫方在offer初始化结束后提供candidates给被叫方.而被叫方开始建立呼叫和连接而不需要等到所有candidate到达。
RTCPeerConnection就是webrtc应用程序用来创建客户端连接和视频通讯的API.为了初始化这个过程 RTCPeerConnection有两个任务：
1,确定本地媒体条件,如分辨率,编解码能力,这些需要在offer和answer中用到；
2,取到应用程序所在机器的网络地址,即称作candidates。
一旦上面这些东西确定了,他们将通过信令机制和远端进行交换.
示例：https://github.com/LingyuCoder/SkyRTC
参考附件中的demo源码
信令交互序列图：
图一，建立连接部分
a，终端浏览器从 WebServer拉取相应的前面页面数据html+css，并进行渲染；
b，用户在页面上点击start按钮，会向信令服务器进行帐户注册，返回用户ID；
c，用户在UI上输入对方的用户ID，点击call按钮，首先向信令服务器查询对方在线状态，服务器如果返回“在线”，则再次发送“连接请求”，信令服务器会转发到对方，对方在连接数未达到上限（5个连接）时，会返回“允许连接”，接着创建一个peerconnection将生成的offerMsg通过信令服务器转发到对方，对方收到后创建 peerconnection并生成answerMsg回转，至此双方的本地准备工作就绪。
d，双方在创建peerconnection后，均会传入TURNSERVER地址，同时会主动查询本地的网络环境情况，查询后会有icecandidate回调回来，此时将此icecandidate信息转发给对方。
e，双方在收到对方的若干icecandidate信息后，会尝试与对方进行连接，连接成功会进行P2P数据传输，如果连接失败，即一方或者双方的NAT环境不允许建立P2P，则经过TURNSERVER进行数据转发。
图二，断开连接部分
当一方需要断开与对方的连接时，在输入框中输入对方的用户ID，点击“hangup”,本地会停止当前的数据连接，删除保存的对方信息，同时通过信令服务器转发“hangup”事件，对方收到后，也会停止数据连接并删除对方信息。
当一方因网络断开或者刷新页面时，会监听到disconnect事件，此时会转发“bye”事件到对方，对方也会处理相关的事件和信息。
三，ICE、STUN、TURN
ICE(Interactive Connectivity Establishment)，即交互式连通建立方式，它并非一种新的协议，而是通过综合运用STUN、TRUN、RSIP等几种协议以适应不同的NAT网络环境，以弥补单独使用其中任何一种所带来的固有缺陷。
现实生活中网络客户端都位于一个或多个NAT之后,或者一些杀毒软件还阻止了某些端口和协议,或者在公司还有防火墙或代理,等等,许多应用需要解决NAT穿透问题，目前比较流行的方案有：ALGs(Application LayerGateways)、Middlebox Control Protocol、STUN (Simple Traversal of UDP through NAT)、TURN(TraversalUsing Relay NAT)、RSIP(Realm Specific IP)、symmetric RTP等。
webrtc就是通过 ICE这套框架来处理复杂的网络环境的,如果想启用这个功能,你必须让你得应用程序传ice服务器的URL给RTCPeerConnection。
javascript中ice配置如下：
var iceServer = {
'iceServers': [{
//url:'turn:10.27.105.105:3478',
url:'turn:'+serverIp+':'+turnPort,
username: 'media1',
credential: 'mediatest1'
}]
};
在初始化RTCPeerConnection 时将ICE对象传进去，如下：
pc = newRTCPeerConnection(iceServer);
ICE试着找最好的路径来让客户端建立连接,他会尝试所有可能的选项,然后选择最合适的方案,ICE首先尝试P2P连接,如果失败就会通过Turn服务器进行转接。
换一个说法就是:
1,STUN服务器是用来取外网地址的；
2,TURN服务器是在P2P失败时进行转发的；
每个TURN服务器都支持STUN,ICE处理复杂的NAT设置。
STUN的作用就是让客户端发现自己的公网IP和端口,所以负载不大,同时目前免费得STUN服务器也很多。
TURN的作用是在RTCPeerConnection尝试使用P2P失败后，转发两个端点的音视频数据。因为TURN服务器是在公网上,所以他能被各个客户端找到,另外TURN服务器转发的是数据流,很占用带宽和资源.
google提供了stun.l.google.com:19302供测试, apprtc.appspot.com用的就是这个stun服务器,实际应用中,最常使用的是rfc5766-turn-server。
TURN通道连通流程示例：
Symmetric NAT网络拓扑是最严格的，以此对称型为例。
A请求收集自已的地址：
首先生成A的地址信息：
v=0
o=Dodo 2890844730 2890844731 IN IP4host.example.com
s=
c=IN IP4 218.65.228.110
t=0 0
m=audio 8076 RTP/AVP 0
a=alt:1 1.0 : user 9kksj== 10.0.1.9 1010
a=alt:2 0.8 : user1 9kksk== 211.35.29.309988
a=alt:3 0.4 : user2 9kksl== 218.65.228.1108076
B收集自身地址：
B收集到的自身信息：
v=0
o= Vincent 2890844730 289084871 IN IP4host2.example.com
s=
c=IN IP4 218.65.228.110
t=0 0
m=audio 8078 RTP/AVP 0
a=alt:4 1.0 : peer as88jl 192.168.1.6 23766
a=alt:5 0.8 : peer1 as88kl 202.205.80.13010892
a=alt:6 0.4 : peer2 as88ll 218.65.228.1108078
a=alt:7 0.4 3 peer3 as88ml 218.65.228.1105556
A的连通性检测：
B的连通性检测：
三， webrtc的DEMO环境
1，web服务器的搭建及注意事项
使用基于浏览器的webrtc应用，需要有web前端页面，由web服务器提供服务，常用的有nginx和apache，这里以ubuntu14.04系统上搭建apache为例。
注意：最新的webrtc仅支持HTTPS安全连接，所以需要支持 ssl，不使用https访问，会出现getUserMedia（获取本地摄像头对象）失败。
a, apache安装，sudo apt-getinstall apache2，安装方法细节可参考网上资料，安装完成后，配置文件在/etc/apache2/apache2.conf，默认端口为80，如果有冲突可修改/etc/apache2/ports.conf，默认的根目录在/var/www/html，可在本机或者同网络下其它机器浏览器输入（假如IP地址是10.27.105.60）http:// 10.27.105.60，如果有apache页面出来就说明OK了；
b, 生成ssl所需要证书；参考网上方法，可自己制作也可一些网站上申请。
cd /etc/apache2/
sudo mkdir cert
cd cert
把附件的两个证书放进来（cert.key,cert.crt）。
c, 配置apache的ssl功能支持模块
cd /etc/apache2/mods-enabled
sudo ln -s ../mods-available/ssl.conf ssl. conf
sudo ln -s ../mods-available/ssl.load ssl.load
cd /etc/apache2/sites-enabled
sudo ln -s ../sites-available/ default-ssl.conf default-ssl. conf
在default-ssl.conf文件中找到SSLCertificateFile和SSLCertificateKeyFile两处，并修改后面的文件路径为/etc/apache2/cert/cert.crt和/etc/apache2/cert/cert.key
完成后，执行sudo/etc/init.d/apache2 restart可能会失败，如下错误：SSLSessionCache: 'shmcb' session cache not supported
Vi ssl.conf中把相应的行注释掉，这样再 restart应该就OK了
浏览器中输入https://10.27.105.60，默认使用433端口，如有需要，可自行修改端口，注意，有两处需要修改:
第一处：/etc/apache2/ports.conf中ssl_module模块中的Listen,如下，我修改为40443
<IfModule ssl_module>
Listen 40443
</IfModule>
第二处：/etc/apache2/sites-available/default-ssl.conf
<VirtualHost _default_:40443>
修改完成后，重启sudo/etc/init.d/apache2 restart
然后在浏览器中输入https://10.27.105.60:40443
不出问题应该能出来页面。
d, 下载并webrtcdemo.tar.gz解压到/var/www/html目录下：
下载地址：http://download.csdn.net/download/yunjinwang/10037767
sudo tar –zxvf webrtcdemo.tar.gz
sudo mv webrtcdemo webrtc
完成后，在浏览器中输入https:// 10.27.105.60:40443/webrtc
不出问题应该会出现页面，“欢迎使用联彤视频通信”的字样。页面会检测本机的摄像头和麦克设备，如果有这些设备，则本地视频会出现视频内容，如果没有视频设备可安装虚拟摄像头设备。https://pan.baidu.com/s/1dE2yl1Z
2，信令服务器的搭建及注意事项
A， 由于DEMO中使用的信令服务端采用js编写，需要安装nodejs到服务器上，版本不同可能会有一些问题，可http://pan.baidu.com/s/1qXNaDIW下载解压后，将node配置到PATH环境使用，配置后执行node–v可查看版本 V6.11.3；
B， 下载附件服务端代码webrtc_server.tar.gz到服务器目录
执行node index.js会打印listen on 40444，这是信令服务端监听的40444端口，可进入index.js中进行修改，记得同时要个性前面webrtcdemo/js/main.js中的相应该位置值；
这个信令服务端信是一个简易的信令交互系统，可进行扩展。具体过程可参考C/S代码。
3，TURN服务器的搭建及注意事项
环境：Ubuntu 14.04，单网卡
IP地址 10.27.105.60
安装方法：
|
# sudo apt-get install rfc5766-turn-server |
启动turnserver
|
# ./turnserver -c /etc/turnserver.conf |
-c后面是指定的配置文件
配置说明：
配置文件在/etc/turnserver.conf
使能基础的stun功能，需要增加配置项：
|
external-ip= 10.27.105.60 |
使能TURN的relay功能，开启long-term credential和realm，并且指定静态的用户名密码
明文的用户名密码
|
user=media1:mediatest1 user=media2:mediatest2 |
加密的
|
#turnadmin -k -u media1 -p mediatest1 -r liantong.com user=media1:0x8499785f1a6c5ae070116302f6c80136 |
设置realm，这个很关键，否则client端无法进行注册
|
realm=liantong.com |
公网映射总结
在入口路由器处做端口映射，整体网络拓扑如下图所示：
图1 TURNserver网络拓扑
在公网环境下的部署，需要注意：
external-ip配置项写成 public ip/private ip的格式
本例中，该项配置为：
|
external-ip=218.106.117.18/10.27.105.60 |
relay-ip项不需要设置，由external-ip的配置服务器自动处理
relay端口组，需要设置为端口映射的端口组
本例中，该项配置为：
|
min-port=59100 max-port=59130 |
4，演示方法
Web、signaling、Turn服务器搭建好后，找两台有摄像头的PC，安装支持webrtc的浏览器，目前使用最新的chrome\firefox\360极速浏览器是可以的，都验证过。
在浏览器地址栏输入https://10.27.105.60:40443/webrtc，“当前用户ID”能分配到ID，说明信令服务器工作OK，本地视频有图像说明本浏览器支持webrtc，在另外一台PC上同样输入上面的网址，能分配到另外一个ID，在“请输入对方ID”框中输入对方的ID，点击startàcall就可进行视频通话了，理论上“远程视频”中会出现对方的图像。
注意：刷新页面如果弹出来“请求摄像头、麦克”等通知，请选择“允许”。
由于https是的证书过期，可能会出现访问受限，拿不到自己的ID，请baidu下解决。