WebRTC源码研究（30）1对1连接的基本流程

WebRTC源码研究（30）1对1连接的基本流程

1. 端对端连接

1.1 基本流程

先来看一张流程图：

首先在这张图里面有4个实体，第一个是A，也就是端到端连接的A端，然后是B端，然后是信令服务器Signal，最后是stun/turn，这个stun和turn服务用的是同一台服务器，既具有stun功能又具有turn功能，首先A是发起端也就是呼叫端，呼叫端要与信令服务器建立连接，被呼叫端B端也要与信令服务器建立连接，这样他们就可以经过信令服务器信令消息的中转。

接下来A如果想要发起呼叫，首先它要创建一个PeerConnect，对端的连接对象RTP，RTC，PeerConnect，创建一个这样的实例，之后通过getUserMedia拿到本地的音视频流，将这个流添加到连接里去，这是第一步。

接下来第二步它就可以调用PeerConnect的 Create Offer的方法去创建一个Offer的SDP，创建好SDP之后在调用setLocalDescription，把它设置到LocalDescription这个槽里去，那调用完这个方法之后实际在底层会发送一个bind请求给stun和turn服务，那这个时候它就开始收集所有与对方连接的候选者了。

那与此同时调用完setLocalDescription之后，拿到这个之前create offer方法拿到这个SDP那也要发送给信令服务器，那通过信令服务器的中转，最终转给B，这个时候B就拿到了offer,也就是说A这端的媒体相关的描述信息。

我们再来看B端 ，B端收到这个SDP之后呢，首先要创建一个PeerConnetion，创建一个连接对象，创建好这个对象之后它会调用setRemoteDescription将这个收到的SDP设置进去，那设置完成之后它要给一个应答，它要调用Create Answer,这时候它就产生了本机相关的媒体的信息也就是Answer SDP,创建好之后它也要调用setLocalDescription,讲这个本地的Answer SDP设置进去，这样对B来说它的协商就OK了。也就是说它有远端的SDP同时它自己这端的SDP也获取到了，这时候在底层就会进行协商。那与此同时在setLocalDescription的时候它也要向stun和turn服务发送一个bind请求，也就是收集它能够与A进行通信的所有的候选者，在调用完setLocalDescription之后，它将它这个Answer SDP发送给信令服务器 ，通过信令服务器又转给了A，那A这个时候就拿到了B 这一端的媒体描述信息，然后它再设置setRemoteDescription,那这个时候A也可以进行媒体协商了，这个时候A和B进行媒体协商的动作就算完成了。这是媒体协商这一部分。

那接下来stun和turn服务将这个信息回给A，这个时候就会触发这个onIceCandidate，因为我们上面是有一个请求，所有这个时候我们就能收到很多不同的onIceCandidate,A收到这个候选者之后它将这个候选者发送给这个信令服务器，通过信令服务器转给对端，也就是让对端知道我都有哪些通路，那对端收到这个Candidate之后要调用AddIceCandidate这个方法将它添加到对端的这个连接通路的候选者列表中去。那同样的道理，当B收到这个Candidate之后，它也发给信令，通过信令转发给A，那这个时候A也拿到B的所有的候选者，并将它添加到这个候选者列表中去，也就是AddIceCandidate，那这个时候双方就拿到了所有的对方的可以互通的候选者，这个时候它底层就会做连接检测，看看哪些，首先他会做一个个的Candidate pair也就是候选者对，然后进行排序，排序完了之后进行连接检测等一系列的连接检测。

在我们之前都做过这个方面的介绍，当它找到一个最优的线路之后呢，A与B就进行通讯了，那首先是A将数据流发送给B，那B在收到这个数据流之后，因为它们前面已经做了绑定了，就是谁来的数据给我了，给我之后就与它的这个Connection进行对连，收到这个数据之后它是不能显示的，B虽然收到数据但是还是显示不出来，那它要将这个数据进行onAddStream，要添加进来，添加进行之后才能把这个视频数据和音频数据向上抛，那才能走到上一层进行视频的渲染和音频的渲染。

那以上就是一个基本的端对端连接的基本流程。那经过这样一个分析大家就会清楚，整个A要与B进行通讯，要走几步，从大的方面讲，首先是媒体协商部分，就是上面这一块，紧接着是候选者的交换与连接检测部分，最后一部分是媒体数据流的通讯部分，也就是分成这个三大块，熟悉了这个基本的流程之后，我们再编写这个程序的时候，就非常的简单了。我们只要按照这个步骤一步步的 操作那么就能实现两个端之间的通讯。