现状
在现在的**产品中，我们提供音视频通话的功能。支持发起用户级一对一的音视频通话，群组级多人参与的音视频会议，以及将单人电脑屏幕投屏给多个参会人的会议场景。
技术架构：
1、音视频信令服务（**自研）
2、Jitsi开源音视频服务（私有化部署）
现存问题
问题一
Jitsi的服务端以Java作为主要开发语言，来提供音视频流的转发服务。**的服务端以Golang为主要语言开发，提供**App用户鉴权等业务能力。由于开发语言不同，在音视频服务与**业务服务的通信过程中，需要编写更多的胶水代码来对接两个服务。
问题二
移动客户端SDK同时集成了音视频服务通信，连接状态维护与前端展示UI逻辑。Jitsi堆砌的功能非常多，导致整个SDK的代码复杂度很高。当**业务需要个性化定制某些功能逻辑时，必须在维护Jitsi代码逻辑的基础上，才能正常推进。有的UI逻辑会碰到Jitsi的代码逻辑与**业务相违背的情况，增加定制难度。
问题三
Jitsi框架使用React Native作为移动端跨平台实现方案，主要开发语言为Java Script，与**目前以Flutter为主的跨平台相违背，开发人员技术栈不兼容，功能后期维护成本高。
解决方案
基于现在的技术架构，我们可以选择使用新的音视频方案对接**的自研音视频信令服务，平滑替换掉的Jitsi音视频服务。
在选择新方案时，优先考虑的几个条件：
1、服务端使用Golang作为开发语言，方便后期与**业务通信。
2、客户端SDK复杂度适中，降低二次开发的难度。
3、客户端SDK使用Flutter跨平台方案，或为原生平台方案。
本次调研涉及的开源方案
1、Jitsi（https: //github.com/jitsi/jitsi）
2、OpenVidu（https: //github.com/jitsi/jitsi）
3、Pionion（https: //pionion.github.io）
4、LiveKit（https: //livekit.io）
Jitsi
优点：
1、部署容易，可水平扩展
2、提供JS、React、React Native的客户端SDK
3、服务端基于Java编写
4、适合大流量的音视频，支持P2P
缺点：
1、缺少HTTP接口
2、后期二次开发复杂（涉及xmpp协议，lua脚本，jicofo/jvb等Java后端模块）
3、缺少文档
OpenVidu
优点
1、流媒体服务器基于Kurento（WebRTC SFU）框架开发
2、提供JS、React、Vue、React Native的客户端SDK
3、文档详细。
3、提供Webhook（可以监控每个房间的具体信息）
缺点
1、服务端基于Java编写，使用Springboot框架
2、不支持P2P通话，需要流媒体服务器中转
3、由于Sesson的逻辑限制，服务水平扩展需要二次开发
Pionion
优点：
1、服务端基于Golang开发
2、提供JS、Flutter的客户端SDK
3、社区活跃
4、信令与媒体服务解耦，易于扩展
缺点
1、缺少文档
2、无原生平台SDK
3、框架处于快速迭代期，稳定性不佳
LiveKit
优点：
1、使用可水平扩展的WebRTC 可选转发单元（SFU），可基于Redis水平扩展
2、提供JS、React、Swift、Kotlin、Flutter的客户端SDK
3、服务端基于纯Go语言，可单二进制部署
4、文档详细
5、提供JWT身份验证、服务端API（Go）
6、提供UDP、TCP通道，内置TURN/TLS
7、单节点性能高（10个演讲者+1000个听众，或4个视频源+400个观看者）
缺点：
1、不支持P2P通话，需要流媒体服务器中转
2、客户端SDK功能简单，需重新业务定制
3、官方demo缺少客户端断线重连逻辑
结论
基于调查结果，我们将选用LiveKit作为升级方案。
Livekit服务端使用Golang语言，方便后期与**业务的通信。同时提供JS、Flutter、iOS/Android原生平台的SDK，可以使**现有的PC、Mac、Android、iOS客户端快速替换现存音视频服务。使用对应平台的开发语言，可以降低开发人员在业务定制上的难度，同时减少后期的维护成本。
