iOS下WebRTC音视频通话（一）

在iOS下作IM功能时，不免都会涉及到音频通话和视频通话。QQ中的QQ电话和视频通话效果就很是好，可是若是你没有很是深厚的技术，也没有那么大的团队，很难作到QQ那么快速和稳定的通话效果。

可是利用WebRTC技术，即便一我的也可以实现效果不错的音视频通话。本篇介绍WebRTC的基础概念。

WebRTC介绍

WebRTC，名称源自网页实时通讯（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美圆收购Global IP Solutions公司而得到的一项技术。

WebRTC（Web Real-Time Communication）项目的最终目的主要是让Web开发者可以基于浏览器（Chrome\FireFox...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序便可实现。可是通过多年的打磨，WebRTC如今已经能够在windows，linux，mac，android，iOS等多个平台中使用。

WebRTC除了能够用来作音频通话、视频通话，还能够用来作视频会议。

其余关于WebRTC的介绍能够参考：百度百科-WebRTC 以及 WebRTC官网

WebRTC 过程

WebRTC 利用RTCPeerConnection能够创建点对点高效、稳定的音频、视频流传输。可是在进行点对点的流传输以前，它依然还须要利用服务器来作一些准备工做。而准备工做须要用到的东西就比较多了，好比STUN服务器、TURN服务器、ICE（NAT和防火墙穿透）、信令传输，相互之间的信令交换完毕，就会发送实时音视频留给对方。

进行音视频通话的完整过程：

• 一、首先设置好STUN服务器、和TURN服务器，而后将STUN服务器和TURN服务器包装成RTCICEServer对象，保存进数组备用。
• 二、利用上一步的数组建立RTCPeerConnection链接。
• 三、为RTCPeerConnection添加RTCMediaStream，而RTCMediaStream内包含视频和音频轨迹，只是作一些配置，而后WebRTC内部按照你的配置作音频、视频的采集。若是你只为RTCMediaStream添加音轨，就是作音频通话；同时添加音轨和视频轨迹，则是作视频通话；只添加视频轨迹，则只能看到视频画面，没有声音。（这些都是在采集端设置）
• 四、为视频轨迹设置渲染的容器，便于开始音视频通话后，将实时视频画面渲染到视图上。（若是是音频通话则没有视频轨迹，就不须要渲染）
• 五、发起方建立Offer，建立完成后会返回一个本地SessisonDescription（简称sdp，其实就是一些媒体和网络相关的元数据信息），而后为RTCPeerConnection设置本地sdp（RTCPeerConnection须要设置远程sdp和本地sdp完成后才能进行点对点的流传输）。
• 六、将本地sdp信息设置完成后，将本地sdp发送给对方（这个过程就是将本地offer信令发送给对方）。
• 七、接收方收到offer信令以后，重复上面的一、二、三、4，而后将接收到的offer sdp设置为本身的远程sdp，而后再建立一个Answer。一样的建立完成后会返回一个SessisonDescription，将这个sdp设置为RTCPeerConnection的本地sdp，设置完成后再将answer发送给发起方。
• 八、发起方收到answer后，将answer sdp设置为RTCPeerConnection的远程sdp。
• 九、而后双方就开始互相发送多媒体流数据，整个音视频通话就完成了。

说明 STUN服务器、TURN服务器地址其实就是个url而已：stun:stun.l.google.com:19302，turn:numb.viagenie.ca，其中STUN服务器和TURN服务器能够在自家的服务上建立，STUN、TURN服务器能够有多个，作备用。

ICE，本端会生成全部网络接口对应不一样协议的Candidate。 每个Candidate实际上描述了和本身的通讯方式。好比一个STUN类型的Candidate会包含本端在防火墙外的IP和端口类型。本端会经过信令协议（sip/xmpp/http）将本身的全部的Candidate发送给对端。对方接收到后，会尝试链接， 并找到一个最好的链接方式创建和本端的链接，以后的流媒体数据将经过此链接传输。

关于Candidate，是对本端网络通讯能力的一种描述。对于UDP/STUN协议，Candidate仅包含IP及端口信息，对于TURN，包含TURN server的IP，端口，以及用户名密码等。Candidate由本端代码生成，生成后经过信令发送给对端。对端会在本端全部的candidate中选择一个最好的创建与本端的链接。

除了上面那些服务器外，还须要一些额外的服务器用来发现用户，好比XMPP服务，主要是为了维护用户的关系以及保持其在线、离线等状态。

WebRTC框架内不提供信令服务，所以信令信息的发送和接收处理须要咱们本身去处理。处理的方式也有不少种，好比利用XMPP的的发送和接收消息的机制，将信令信息发送给对方；也能够用Http网络将信令消息发送给对方；还能够利用WebSocket将信息发送给对方。

先大体了解WebRTC交互的过程，便于后面理解代码。

下一篇我会编写一个在同路由器 的局域网内进行视频通话的Demo。

关于WebRTC概念性的理解下面有几篇文章，文章内也有一些连接都是很好的资料：

使用WebRTC搭建前端视频聊天室——入门篇

使用WebRTC搭建前端视频聊天室——信令篇

WebRTC的RTCDataChannel

虽然以上三篇主要是讲Web前端的WebRTC使用，可是过程和概念概括的很是好，能够多读几遍。

WebRTC and the Early API

WebRTC代理中的各类枚举状态

P2P传输，其中Candidate的做用以及P2P链接的过程介绍的对理解很是有帮助。

WebRTC中文网 其实iOS 中WebRTC的处理过程与Web端的处理过程除了API命名不一样，过程基本是一致的。

重要的是经过编写代码，而后对照代码的每一步去思考它这样作是为了干啥。

Have Fun!