实现1V1音视频实时互动直播系统 十二、第三节 直播系统中的信令及其逻辑关系

今天我们开始讲真正的音视频传输了，也就说将我们之前讲解的信令服务器与我们后面讲解的端到端传输过程，那么整个将他们连接到一起，这样就形成了一个真正的直播系统。看似很简单的东西，其实我们要改造的内容还是有很多的。下面我们就来分步骤的来实现我们这个一对一的直播系统。

首先我们来看看整个直播系统的核心，就是信令，终端与服务器之间如何进行交互，交互之后通过信令的中转然后讲整个的逻辑串联到一起。那么在我们这个直播系统中涉及的信令其实还是蛮少的，只有几个信令，那么就简简单单的几个信令就将我们整个的业务串了起来。下面我们来看看。

首先是客户端发送的信令

join加入房间 

客户端发送信令比较少，第一个就是加入房间，就是说我一个用户跟服务器连接之后，就发入一个join，那么服务器端在收到join这个信息之后就将这个用户进入到这个服务器端说明这样一个用户已经在了；

leave离开房间

第二个就是离开房间，这是成对出现的，我有进有出，这样能够随时知道房间内的人数实际有多少，我只进不出这样的话它就一直累加，那可能服务器端有一万人，实际真正的只有两个人，这也是我们很多直播系统里弄假数据的一个方法，它只进不出，但我们这里要有进有出。

message端到端消息

第三个就是message,message就是将消息之间发送给对端，怎么发送呢？也就是说它首先发送到服务端，服务端收到之后再将它中转给任意一个客户端 ，所以在服务器端是没有任何的逻辑操作的，只是做一个转发而已。

以上就是三个主要的命令，也就是加入房间、离开房间、和发送端对端的消息，但是端对端的消息我们又可以细分三个。

Offer消息

第一个就是通过我们createOffer获取到了我本机的媒体描述信息，就是我的媒体能力，这个我们此前已经介绍了就是createOffer，那当调用这样函数获取到我本机的媒体信息之后通过这个SDP，它是一个SDP的格式描述的，它就直接将它发送到服务端，服务端收到这个Offer之后转给另外一个终端，就可以将整个的协商过程进行串起来了。

Answer消息

同样的道理，当对方收到这个Offer之后它调用setRemoteDescription之后它要调createAnswer然后之后才能调用setLocalDescription，那在创建完Answer之后它也要创建Answer消息，也就是说将它本地的媒体协商信息传到呼叫端，这是Offer和Answer这就形成了一个交互。

Candidate消息

除此之外还有Candidate,也就是说如果我们双方要通信的话要知道彼此的candidate，对方拿到这个candidate之后就要进行这个连通性检测，找到一个非常高效的链路之后它们后边音视频数据传输打好基础。

所以作为客户端它只有三类命令，一个是join一个是leave,另外一个是端对端的消息message,它在message里又细分为三个消息第一个是offer第二个是Answer第三个是Candidate，在接下来是服务端的信令，也就是说看服务端会回哪些信令。

 

服务端信令消息

joined已加入房间

第一个是joined,这个很简单，当一个用户发送join加入房间之后，服务端说你这个已经加入成功了，要给他回一个消息确认说joined，那客户端收到这个joined之后就知道我与服务端这个信令已经发送成功了，那它可以用joined的这个消息去做后面的逻辑处理。

otherjoin其他用户加入房间

当有一端发送join到服务端之后呢，服务端一方面要给发送者回一个joined消息告诉它你已经加入了，另外它要给另外一个端另外一个参与者发送一个otherjoin,就是告诉另外一个参与者说有有另外一个人加进来了，就是这个消息，那另外一个人知道有人加进来了那就知道现在有两个人现在在这个房间中了。这个时候我们就可以进行媒体协商然后进行音视频的通讯了。这就是otherjoin。

full房间人数已满

第三个是full，也就是当有第三个用户再加入房间的时候，就不让他通讯了，就告诉他这个房间人数已满，你不能再来了，我们只支持一对一的音视频传输；

leaved已离开房间

用户离开的时候它发送leave,服务端就给他回一个leaved说我已经离开了，那一个比较好的处理方式是说当用户收到这个leaved之后再离开，这个有利有弊，可以辩证的看，就是说我们在处理这种消息比较多的之后是两个方面都要做的，就是说当用户离开的时候，为了客户端能快速的离开，那它可能就直接发送完了就断开了；还有一直是它收到这个leave之后然后要做一些资源的释放，然后再离开；如果在leaved再离开的时候就是说它客户端退的比较快，这样给用户的感觉更好一些。但是带来一些麻烦就是说你虽然走了但是你这个leave有可能没有发送到服务端，这个时候服务端就要等这个超时时间，所以它在统计人数或者是说在做一些逻辑处理的时候可能就比较麻烦。所以我们一般的做法是客户端发送leave消息要等一个超时时间，如果服务端在这个超时时间内回这个消息了，那我就用回这个消息去释放相应的资源，这样整个流程就是通的了。如果这个超时时间内没有回来，就是该离开还得离开，因为这个时候我还得离开，因为我不能等你，不能让用户感觉我卡死了。这就是leaved。

bye对方离开房间

另外一个就是也要告诉对方，也就是说发送一个bye告诉对方这个人离开了，在对方的用户列表里就要将这个人删除掉，或者说知道对方离开了，对我们一对一的来说，那它也要释放一些资源再等待，当有另外一个用户来的时候再重新创建资源进行音视频的通讯。

以上就是服务端的五个信令。

下面我们再来看一下整个直播系统的消息处理流程图。

大家对这个图一定要理解清楚，因为我们整个一对一的直播系统不管是一对一还是一对多，那它除了这个音视频通讯之外就是信令的交互关系，那只有把这整个信令的交互关系理清楚之后你才能抓住整个程序的流程 ，现在我们来看看这张图

左边有个Caller,它是呼叫者，第二个是SigServ就是信令服务器，第三个是Callee就是被呼叫者，第四个Callee是另外一个被呼叫者，那我们一个一个来看

首先呼叫者它要创建与信令服务器建立连接，对于其他端来说也是先把连接建立好，否则信令就是不通的；

这时候呼叫者首先发送一个信令是join，说我要加入房间，那么信令服务器回一个joined,表示你这个加入消息已经知道了，已经将你加入到房间了；

那另外一个用户这时候也发送一个join加入房间，这时服务器也回一个joined，就是一个请求一个应答，这样它也被加入房间，当第二个用户也加入房间之后，服务端要给第一个用户回一个otherjoin,这时候第一个用户就知道有另外一个用户已经进来了，这时候他们可以进行协商了，然后进行通讯了，那如果这时候有第三个用户Callee发送join说我要加入房间，那信令服务器一查看它这个列表现在已经有两个用户了，所以就给它返回一个full，说你不能加入这个房间。这时候第三个用户就要释放资源，比如这个提示信息比如“房间已经满了，不能再添加了”；所以这个时候与第三个用户已经没有任何关系了。就剩Caller和Callee这两个用户了 ，这个时候他们就可以进行媒体协商了，那么怎么进行媒体协商呢？就是发送端对端的消息，也就是message,它这个message里包括三个包括我们刚才讲的，也就是一个Offer，也就是它刚才发送的一个Offer给对方，对方处理完了然后回一个Answer在回来，这时候当有收集到这个Candidate地址的时候就收集好了，收集完了之后就通过这个信令 服务器转发给对方，对方拿到这个Candidate之后就进行 连通性检测，检测成功了之后这时候就可以进行P2P或者TURN服务进行音视频数据的转发，那它们就真正的通讯了。

那再下面，当有一个用户说我要离开了，比如说这里的Callee,它发送一个leave给信令服务器，信令服务器收到这个leave之后，首先也要告诉对端，就是说对方和你说byebye了，那你要做相应的处理，紧接着再给这个发送者回一个leaved，也就是说你这个消息我已经成功转发了。

同样的道理如果是主叫方去发送这个leave,那这个信令服务器也是走同样的流程，先给另一方发送bye，然后回一下这个leaved,然后整个信令服务流程就是这样一个关系。