前言

因为某些工作需要双人共享屏幕聊天以及操作，但是众所周知国内很多会议软件并不是免费的

例如钉钉，腾讯会议，飞书等都不好用，因此我决定自己搭建一个

开始折腾

方案选择

SRS推流

一开始想的是直接让想直播的一方用OBS推流，然后另一方用VLC或者ffplay拉流，同时用语音软件在线交流

我打算用SRS，然后用RTMP推流

跑起来倒是很简单

docker run -d --name srs -p 1935:1935 -p 1985:1985 -p 8080:8080 ossrs/srs:latest

然后区配置一下端口映射，把1985映射出去就可以

推流端的地址是rtmp://服务器IP:1935/live/stream

拉流端的地址也一样

但这样有几个问题

首先的话这是没有鉴权的，任何人知道地址都可以推流拉流，不安全

虽然可以通过httphook和手写后端来实现鉴权，但首先这太复杂了，我后续需要部署到K8s上

前端 后端 SRS服务都需要写一个Deployment，就为了实现一个鉴权和直播，像屎山

其次延迟是个问题，大约1-2s的延迟导致语音看起来和视频不大同步，这并不满足会议的体验和需求

然后OBS推流对于直播端网络要求不低，如果上传不稳定会断流，并且OBS并不会很积极的重试，导致一旦断流卡顿就是将近十秒的卡顿

所以体验不佳，综上，这个方案被Pass了

上面这些其实一定程度上是RTMP的问题，一个是它本身就不是为了低延迟设计，一个就是SRS不支持H265,所以对带宽要求高

所以我打算换一些方案

WebRTC

由Google设计的用于会议场景的推流协议，完美满足我们的需求

那么基于这个协议有什么开源方案呢

我找了一下，主要是Jitsi Meet和Livekit，以及Janus WebRTC Server

Janus WebRTC Server就完全是一个基于WebRTC的底层服务了，几乎所有东西都要自己写，这个有点麻烦了

我懒

LiveKit其实也差不多，但是提供了SDK去做这些，稍微方便点

Jitsi Meet本身就是开箱即用的会议系统

Jitsi Meet是比较符合我的需求的

LiveKit的话等我以后需要进一步详细配置的时候再考虑吧（OAuth 录制 AI总结啥的）

Jitsi Meet

看了下他的官方文档，基本上就是Docker Compose

wget $(wget -q -O - https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep zip | cut -d\" -f4)
unzip docker-jitsi-meet-*.zip
cd docker-jitsi-meet
cp env.example .env
docker-compose up -d

直接跑起来，然后访问http://localhost:8443就可以了

端口映射的话，需要8443,10000

然后依然没有鉴权，不过这可以用反代实现，关键还是画质

找朋友试了下，根本用不了（）

研究一下为啥

啊忘记该配置了（）

.env里面有几行需要改一下

PUBLIC_URL=https:/域名:${HTTPS_PORT}

JVB_ADVERTISE_IPS=服务器IP

然后就可以了

LiveKit

这个说白了仅仅只是一个基于WebRTC的解决方案，想实现会议的话要弄很多东西，我打算先用Jitsi看看了

结尾

那个SRS我打算也留着，虽然不适用于会议，但私有直播服务器给群友直播一些没法在平台播的东西还是很有用的

先这样