WebRTC系列-WebRTC基础(四)连接建立时序图及运行机制

1. 连接建立时序图

WebRTC消息的交互是交个应用自己去实现，主要是完成媒体协商和ICE穿透功能，这两个只是点会在接下来的章节里介绍；先看下WebRTC的建立连接时序图：

上图中按照颜色不同，WebRTC的连接建立主要分为三大部分，stun/turn服务（绿色）、信令服务（黄色）、各个客户端（蓝色）；接下来分析这三部分是如何完成WebRTC连接的建立过程:

1. WebRTC中不提供信令服务，需要客户端自己实现信令服务可以是https的服务，也可以是socketio或websocket等信令服务；客户端A和B在服务端启动后连接上信令服务，为后续媒体协商做好消息发送准备；
2. client A作为offer(发起方)先调用WebRTC提供的API创建一个peer对象，然后将准备好的媒体stream(同时要调用peerFactor创建音视频的track,将音频track和视频track添加到stream中)加入到peer中，这时候client Ad的媒体已经准备好了；
3. 这时候调用peerconnection的offer方法后，会生成sdp通过回调返回到应用；
4. 拿到offer SDP后client A 通过信令服务转发给client B，同样的client B应该再收到sdp调用peer的setRemote前将本地的stream加入到peer中，然后调用CreateAnswer方法
5. 然后通过peer的回调就可以拿到answer SDP，通过信令服务发送给client A;
6. 补充流程:在上述流程中candidate的生成是在client A和client B 调用setLocal后就开始持续手机candidate了，这里客户端一般需要换存等到setRemote后再发送给对方或自己在调用setRemote后再加入对方的candidate；
7. 这时候peerConnection会给客户端通过回调接把local candidate以及stun服务返回的reflex和relay的candidate按照顺序返回给客户端，这时候client A和client B就可以通过信令服务交换ICE信息，同时尝试打洞及连接过程；
8. 当连接完成后，peerCOnnection就会通过回调告知ice的状态，当成功后同时也会回调一个对方媒体数据的消息onAddStream；
   经过上述基本WebRTC的连接就可以建立，双方就可以开始通话，当有网络变化时候，可以通过持续的candidate收集，双方交换后重新开始尝试建立连接，或者客户端主动调用restartICE方法。

2. 运行机制及主要接口类

2.1 概念介绍

在开始之前先介绍两个概念：流(mediaStream)与轨(track)，

• track：像一路视频一路音频都是单独的轨分别叫音轨和视频轨；两路视频之间也是两路轨，是不相交的；
• mediaStream：借鉴传统的媒体流的概念，一路流里面包含视频轨、音频轨、字幕轨等；
  track和mediaStream主要是一个层级关系，在媒体流里一般都包含一个或多个轨；

2.2 几个重要类

WebRTC在面向应用层的接口提供了几个重要的类，如图：

• MediaStream 也就是媒体流，WebRTC将其封成一个单独的类；
• RTCPeerConnection WebRTC中最重要的类，这个类是大而全的类，包含了WebRTC的大部分对外接口的功能，对应用来说就很方便；在应用层只要创建一个链接，然后将mediaStream添加的peer中，用户不用去管传输、链接建立，编解码等都在内部执行；
• RTCDataChannel 通过peerconnection创建，主要用于发送二进制数据；

2.3 PeerConnection调用过程

WebRTC官网也提供了一个简单介绍如图：

最上面的stream也就是上节介绍过的一个MediaStream中会包含多个track,而每一个音频或者视频都是单独的一个轨；接下来就是PeerConnection类的调用过程，按照从左到右按照箭头走向介绍：

• PeerConnectionFactoryInterface 在这个类中会创建两个关键线程work Thread和signaling Thread 以及同时会创建PortAllocator(端口分配，源码分析会讲到)；
• 同时PeerConnectionFactoryInterface世界也是一个链接工厂，通过调用其提供的接口CreateLocalVideo/AudioTrack就能创建出视频、音频的Track(是LocalVideo/AduioTrackInterface接口类型的)，通过CreateLocalMediaStream方法可以创建LocalMediaStreamInterface接口类性的媒体流，然后通过CreatePeerConnection方法可以创建出PeerConnectionInterface接口类型的PeerConnection；
• 其中LocalVideo/AduioTrackInterface通过mediaStream的AddTrack方法将音频视频轨添加的LocalMediaStreamInterface接口类中；LocalMediaStreamInterface又通过PeerConnection的AddStream方法将轨道流添加到每一个PeerConnectionInterface中，
• WebRTC中的状态等事件通过PeerConnectionInterface的PeerConnectionObserve回调(Callback)给应用.

2.3 PeerConnection调用时序图

上述介绍的几个类的调用时序图（官方的时序图），这几个图其实也就是对开篇综合图的一个详细的分解，当然也最主要是包含了几个关键类的调用关系及调用顺序:

1. 呼叫方(offer)的时序图：
   

• 应用应该调用方法生成PeerConnectionFactory对象(且全局有且只有一个)；
• 通过这个factory创建peerConnection的实例；
• 依次调用对应的方法创建mediaStream、audioTrack和videoTrack的对象，然后将audioTrack和videoTrack加入到mediaStream中；
• 将创建好的stream加入到peerConnection中，接着调用peerConnect的offer方法提交这个媒体改变；
• 时候PeerConnection通过应用监听的回调告诉应用有流更新或改变，同时也会回调offer的sdp数据给application；
• 应用拿到这个sdp(offer)发送给远端；
• 远端收到后生成answer发送给application，然后调用setRemote告诉PeerConnection；
• 当双方都准备完成就开始尝试连接；
• 媒体一旦连接成功，就会通过peerConnection的回调告诉应用；

2. 接收方(answer)的时序图：
   
   与offer端想法的是Application先会收到远端的sdp消息，然后进入流程;\

• 调用对应的方法创建唯一的PeerConnectionFactory;
• 然后调用CreatePeerConnection方法创建PeerConnection对象；
• 接着调用peer对象的(先调用peer的setRemote提交远端的sdp)answer方法提交，
• PeerConnection会通过回调告诉Application添加了一个媒体流(能获取到peer 在底层生成的远端的多个媒体的track)，
• 然后依次调用对应的方法创建mediaStream、audioTrack和videoTrack的对象，然后将audioTrack和videoTrack加入到mediaStream中，然后提交个peerConnetion ；(注:这里删除的原因是，实际上在创建peer的时候就应该加入了，在下一篇讲接口使用的时候会介绍)；
• 调用peer的answer方法会通过回调返回anser SDP ，Application将这个sdp通过信令发送给远端；
• 当双方都准备完成就开始尝试连接，连接建立完成就可以进行通话互动；

3. 结束通话的时序图：
   
   任何一端的Application通过调用PeerConnection的close方法断开连接的同时，WebRTC会通过PeerCOnnection的回调方法告诉应用当前的关闭状态以及媒体流移除等通知；同时也会告知对方关闭消息，当双方关闭后结束通话(后续的四个箭头步骤，在WebRTC底层实现)，最终的关闭会推送close状态；

到这里，WebRTC的信令时序图集运行的机制这里介绍完毕；
下一篇，介绍这些接口类在iOS端的使用及类关系；