WebRTC 客户端状态机

WebRTC 客户端状态机

客户端状态机

首先我们来看一下客户端的一个状态机，客户端与服务器直接通过信令的一个交互之后自然而然的形成一个状态机：

最开始的时候状态机是处于初始化状态的，当用户发送了一个join到服务端之后服务端会给它回一个joined消息，客户端在收到joined消息之后就变成了加入状态（joined），这个时候用户是可以离开房间的。当客户端离开的时候会回到初始化或者是离开状态。

当一个用户A处于joined的状态的时候，另外一个用户B又进来了，这时用户A就会变成joined_conn状态，就是加入并且可以与对方进行通话的状态。其中用户A的变化就是通过other_join消息通知的，当他收到other_join的时候它就改变状态从joined到joined_conn，对于后加入的用户B，它还是处于joined这个状态，因为它自己并没有收到other_join这个消息，所以房间这两个人其实是两个不同的状态，用户A是先加入房间的，是joiner_conn状态 ，对于后加入的用户B是joined状态。对于join_conn这个状态的用户它也可离开，当他离开的时候它也处于初始化或者离开状态，这同joined状态的情况是一样的。

如果用户A需要离开房间，离开的时候它会发送一个bye消息给这个现在还在房间中用户B，用户B收到bye这个消息的时候状态变成joined_unbind，它虽然已经在这个房间内，但是由于另外一个用户已经走了，所以他们直接进行通讯的这个连接已经不需要了，那这个时候需要释放这个连接，所以要将peerconnection这个连接中的相应通道全部进行解绑，所以它就处于joined_unbind状态。

如果用户B这个时候处于joined_unbind状态，这时候又有一个新的用户C进入，那么用户B会变成joined_conn状态，而刚进来用户C变成joined的状态。用户B处于join_conn状态的时候，就是说这两个用户直接可以进行通讯了，那么这时候如果用户C在加入后离开了，用户B就回到这个joined_unbind状态。

如果处于joined_unbind状态，也可以离开，那这个时候是房间里一个人都没有了，那都处于初始化和离开状态。

有这样一个状态机之后，客户端与服务器之间就可以进行交互了，以上就是整个房间中各个用户状态的变化的一个状态机。

客户端加入流程图

首先获取这个音视频数据（本地），但如果不能获取到，那就直接失败了，本次通讯肯定不能完成了。

但是如果能获取到音视频数据（本地）的时候，就要拿到数据之后，再与这个信令服务器进行连接，然后注册相关的信令处理函数，也就是本机可以处理接收到的服务端信息，比如joined加入成功信息。

发送加入房间消息后的分支：

1. 无论房间中是否有其他用户（或者房间已经满了），都会走这一步：如果有一个用户A加入的房间，那么他首先要设置状态，说我现在已经处于加入的状态，这时候它要创建并绑定媒体流PeerConnection，创建一个我们最终通讯的通道，并且将媒体流绑定，这是用户加入的情况。
2. 如果房间中原本有另外一个用户B，那B要判断现在的状态，如果他现在是一个未绑定状态，他要创建PeerConnection，可能就要跟对方A进行通讯，并且绑定这个他本地的媒体流到这个PeerConnection后面才能进入相应通讯。如果不是这种状态，B是一个joined状态，那这时B就变成了这个join_conn，说明在这之前它已经创建过PeerConnection，并绑定过本地音视频媒体流了，之后所以就不需要绑定，这时候他只要改变状态，变成了join_conn状态，然后变成join_conn状态之后就开始媒体协商，然后收集这个candidate进行连接性检测，最终传输。
3. 最后一个分支，就是当这个房间满了，用户C来了（经过分支一）发现房间满了，这时候将C设成离开的状态，并关闭与服务端的连接。注意：因为如果返回full房间满状态，是不会去走分支一的，所以不会去创建peerConnection连接和localStream数据，所以不需要去释放。

客户端离开流程图

另外还有leave消息，当离开的时候把它分成两种：

1. 本地自己发送离开消息：先走中间的分支，关闭掉自己的peerconnection，关闭音视频设备（媒体流），然后等待收到服务器端确认已离开的消息，那这时就变成了leaved初始状态，这时候关闭连接就好了。
2. 对端离开后，对方发送bye消息到本地的时候，本地状态就变成了join_unbind状态，同样也要关闭对应的peerconnection。关闭之后其他用户再加入的时候，当本机收到other_join消息的时候又会重新创建PeerConnection并进行绑定。

端到端连接的基本流程