版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/twoconk/article/details/84313755
对讲后台业务架构图如下图：
图1、对讲后台业务架构图
通过NGINX负载Janus http服务器的API接口，通过该API接口可以获取可用Janus服务器的IP和端口；客户端拿到可用对讲服务器的IP和端口后，通过WebSocket连接到该服务器，并保持长连接，客户端进入会议室时，则复用这条长连接；如果进入其他会议室，则需要重新获取可用的Janus服务器IP和端口，并重复上述过程；多个对讲服务器之间通过RabbitMQ共享数据，三个服务器之间对等对外提供服务。
客户端进入会议室对讲主要流程：
客户端加入会议室后，使用两个peerconnection分别用来做publisher角色和subscriber角色类型通信，publisher主要用来讲话的通道，subscriber则主要用来听对讲的通道；每次讲话前都需要申请TBCP讲话权限，获取成功，则开启录音，并发送数据，否则不开启录音；如果其他人在讲话，则打开播放器，开始播放声音，主要业务流程如下图：
图2、对讲客户端主要业务
详细的客户端加入流程如下图3所示：
图3、对讲加入群组主要业务流程
退出会议室时，一定要保证两个Peerconnection的连接都能同服务器断开；
断网重连流程：如果碰到断网重连时，需要重新获取该房间的janus服务器的IP和端口，并在重连WebSocket成功后，重走图3的流程，完成重新自动进入对讲房间的工作。