目前业界如教育行业，直播行业，低延迟音视频连麦方案基本采用声网，即构，腾讯等第三方方案，采用第三方方案最大的优点就是接入快捷，可以迅速搭建自己的产品，缺点就是完全受制于第三方，另外费用比较高，公司规模小的时候比较合适，公司规模大了后就会有顾虑，通常达到一定规模后可以考虑自研一套方案和第三方方案并行使用，避免完全受制于第三方，和华为采购高通芯片的同时也研发自有芯片一个道理。
正是基于这样的考虑，我们开始研发自研的连麦系统，作为技术方案来说，现今支持浏览器直连基本上已经是刚需，所以webrtc是必须要兼容的，所以技术方案设计上决定是以webrtc协议为基础，支持多人会议，完全从0开始做不可取，经过对现有开源框架的研究比较后，决定在janus方案的基础上研发并逐步改进以符合需要，本系列文章就是对整改系统的研发过程的记录和总结，供大家参考。
如图所示，janus支持房间和视频分发， turn负责解决连通性问题，比如某些海外用户无法直接连到国内的janus服务时，需要走turn。
连接步骤：
1. 用户向调度服务器申请加入房间
2.调度服务器查询房间所在janus，若房间已经存在直接告诉用户房间所在服务器，若房间不存在，选择一个空闲和最近的服务器创建房间并返回给用户；
3.用户根据janus协议连指定的服务器并加入房间，发布媒体，拉取其他用户的媒体；
4.视频通话连接完成；
优势：
用turn服务解决连通性问题，一个房间用户连到一台janus服务器，janus和turn都很成熟可以直接用，作为第一阶段尽快看到结果比较合适
劣势：
1. 存在容量问题，单个房间用户数受限一台服务器处理能力
2. 若janus在国内，国内有一个用户，国外比如南非本地有3个用户，这三个用户都需要到国内走一圈获取到其他2人的数据，无法智能本地获取；
3. Janus的房间概念让系统设计不太灵活，不太合适按需获取
虽然有些劣势，不过做为第一阶段尽快出成果来说，这个方案是比较合适的，只需要少量的工作即可看到成功：
1. 调度服务器，先实现简单的案容量来调度以及房间服务器的映射查询；
2.Janus服务器改造，上报自身状况，供调度服务器调度决策
3. Janus客服端SDK，当前Janus提供了web接入，android和ios接入demo代码，都能顺利连通，很遗憾的是翻遍整个网络，没有找到windows和Mac下的c++接入demo， 所以这块是先阶段的重点和难点，因为我们的产品windows原生客户端是很重要的一环。
调度服务器和Janus服务器状态上报都很简单在此不多讲，后续几篇文章主要讲如何开发windows和mac下的原生c++的janus客户端SDK.
-----------------------------------------------------------------------------------------------------------------
原创文章，带点个人作品小广告，勿怪勿怪： “证爱网，见证爱”。
情侣之间，家庭成员之间，欢迎光临本店购买证爱礼物>>>