浏览器原生 · 一键高清通话 · 千人互动会议 · AI 预警联动 · 双向指挥喊话
官网： https://me.automate.org.cn
🎯 一句话介绍
MeetHub 是一款可私有化部署的企业级 WebRTC 视频会议中台，融合 1对1 高清通话、千人互动会议、MCU 智能混流、WHEP 外部流入会、AI 预警联动、双向指挥喊话于一体，开箱即用、数据不出内网。
无论是日常远程办公，还是应急指挥调度、AI 事件联动，一套系统全部覆盖。
💡 为什么选择 MeetHub
| 痛点 | MeetHub 的答案 |
|---|---|
| 商业会议软件按人数收费，成本不可控 | 1000 元 / 服务器，不限房间数、不限并发用户 |
| 数据要出内网，安全审计过不了 | 全私有化部署，数据不出内网，支持 JWT + 房间级鉴权 |
| 硬件监控、会议、喊话三套系统割裂 | 与国标监控共用同一套后台，一套账号管全部 |
| 浏览器开会卡顿、糊成马赛克 | P2P 直连 <100ms，弱网 3 秒自动重连 |
| 几百人开会，前端直接卡死 | MCU 混流技术，1000 人旁听，前端只解 1 路音频 |
| 外部摄像头 / 医疗设备 / OBS 拉不进会议 | 标准 WHEP 协议，一键接入任意外部流 |
| 应急场景只能"看"，不能"喊" | 双向广播喊话，会议声音直接推到现场音柱 |
| 担心开源 MQTT Broker 版本碎片 / 漏洞 / 无人维护 | MeetHub 自研 MQHub 信令服务，全栈自主可控 |
🚀 核心能力
一、会议与通话
- 📞 1对1 高清通话：默认 P2P 直连，点对点不经服务器，延迟 <100ms；弱网自动降级 SFU 转发
- 👥 千人互动会议：单场最高 1000 人同时在线；硬性限制 16 人开麦、4 人开视频，保障极致流畅
- 🎙️ MCU 智能混流：3 人开麦起自动启动 MCU 混流，前端只解 1 路音频，带宽和 CPU 降低 90%+
- ⛶ 全屏与画面切换：一键全屏任意画面，指挥场景随时聚焦关键监控或人员
- 🪞 智能摄像头镜像：本地预览按自拍习惯镜像，对端始终看到真实视角
二、外部接入与双向喊话
- 🖥️ WHEP 外部流无缝入会：监控探头、医疗设备、OBS 直播流等，通过标准 WHEP 链接一键拉入会议。房间级互斥，同一时间仅一人共享
- 🎙️ 双向指挥喊话：会议中混流后的声音，可反向推流至带扬声器的国标摄像头或音柱 —— 领导和专家无需拿起电话，在会议里直接说话即可对现场喊话调度
三、与企业现有系统融合
- 🌐 GBHub 统一管理中台：与国标监控共用同一套后台。一套账号体系，同时管理摄像头、对讲终端与会议房间
- 🧠 AI 预警联动指挥：集成 AI 视频分析（安全帽、烟火、跌倒等），识别异常事件时自动拉起会议并推入现场画面，触发一键预警
四、基础设施
- 🚀 分布式媒体集群：控制面与媒体面分离，按房间动态绑定 MCU 节点，横向扩容无上限
- 📶 弱网自适应与秒级重连：心跳保活 + 断线重连 + ICE 恢复，网络抖动后 3 秒内自动恢复，外部流与喊话状态 10 秒内自动恢复
- 💾 云端录像与多端回放：边推流边录像，文件自动落盘；支持 HTTP-FLV / HLS / MP4 在任意设备回放
- 🔐 企业级安全与鉴权：全私有化部署，信令 HTTPS + WSS 加密，JWT Token + 房间级访问控制
🏗️ 技术架构
MeetHub 采用「客户端 → 信令接入 → 媒体转发」三层解耦架构，每一层都可以独立扩展与替换。整个后端由 纯 Rust 实现的两大微服务（gbhub-meeting 信令服务 + gbhub-mcu 混流服务）承担，共享同一个 common 协议库，与 ZLMediaKit 媒体引擎 + GB28181 网关 组成完整媒体面。
全系统信令总线由 MeetHub 自研的 MQHub 承载。MQHub 是 MeetHub 内置的 MQTT 信令服务组件，与信令服务同源、同部署、同升级，针对会议场景深度定制（Topic 结构、QoS 策略、心跳周期、重连策略），不依赖任何第三方 MQTT Broker，一个软件包 = 全套服务。
第一层：客户端（Browser / PWA）
- 支持浏览器：Chrome / Edge / Safari / Firefox / 微信内置浏览器
- 核心技术：WebRTC 原生 API（getUserMedia / RTCPeerConnection / MediaStream）
- 接入协议：HTTPS + WSS（信令全链路加密）
- 信令接入：通过 MeetHub 内置的 MQHub 提供的 WSS 通道订阅房间事件
- 附加能力：PWA 支持添加到手机主屏，体验接近原生 App
第二层：信令接入层（gbhub-meeting）
| 模块 | 职责 |
|---|---|
| MQHub 对接 | 接入同产品包内的 MQHub 信令服务，分发房间信令（加入 / 离开 / 状态 / 聊天 / 喊话） |
| JWT 鉴权 | Token 校验、房间级访问控制、用户身份确认 |
| 房间路由 | 媒体模式协商（P2P / SFU）、WHIP / WHEP 地址分发 |
| 状态中心 | 房间状态、参会者列表、喊话归属、外部流互斥锁（Redis 存储） |
| ZLM API 代理 | 开流 / 关流 / 开录像，把 ZLM REST 能力暴露给前端 |
第三层：媒体转发层（gbhub-mcu + ZLMediaKit）
| 模块 | 职责 |
|---|---|
| ZLMediaKit | WHIP 推流 / WHEP 拉流 / 转发 / 录像 |
MCU 混流节点（gbhub-mcu） |
多路音频混流为 1 路（16 人开麦 → 前端只解 1 路） |
| GB28181 网关 | 国标摄像头 / 音柱 / 对讲机接入与双向喊话 |
| 录像存储 | 边推流边录制，支持 HTTP-FLV / HLS / MP4 回放 |
数据流
① 普通会议流程：
参会者浏览器（WebRTC）→ 通过 WSS 连接到 MeetHub 自研的 MQHub 信令服务 → 信令服务分配房间并协商媒体模式 → 浏览器与媒体层的 ZLMediaKit 建立 WHIP/WHEP 连接 → 音视频开始双向流转。
② 1对1 通话流程：
参会者 A 与 B 通过 MQHub 交换 SDP 与 ICE → 双方直接建立 P2P 连接（不经服务器）→ 若 P2P 失败，自动降级为经由 ZLMediaKit 转发。
③ MCU 混流流程：
开麦人数 ≥ 3 → MQHub 推送 mix_state 事件 → MCU 混流节点拉取各参会者音频 → 解码 → 重采样到 48kHz → 定时叠加混流 → 编码为 1 路 Opus → 推回 ZLM → 前端所有参会者只拉 1 路混流音频。
④ 双向喊话流程：
MCU 混流结果 → 通过 GB28181 网关反向推流 → 现场音柱扬声器播放 → 现场人员听到指挥喊话。
⑤ 外部流接入流程：
用户粘贴 WHEP 链接 → 信令服务通过 Redis 抢占互斥锁 → 通过 MQHub 广播全房间 → 所有参会者从 ZLM 拉取同一路外部流。
关键设计特性
| 特性 | 说明 |
|---|---|
| P2P + SFU 双模智能路由 | 1对1 优先 P2P 降延迟；多人自动切 SFU 保稳定 |
| 控制面 / 媒体面分离 | 信令与媒体各自独立部署，单点故障不影响全局 |
| 自研 MQHub 信令总线 | 全栈自研的 MQTT 服务组件，无第三方依赖，针对会议场景深度定制 |
| 标准协议栈 | WebRTC / WHIP / WHEP / GB28181 / RTMP / HLS，可与任意系统对接 |
| 无客户端 | 现代浏览器直接打开，支持 PWA 添加到主屏 |
| 横向扩容 | 信令服务加实例即扩；媒体节点按房间动态绑定 |
| 边缘计算 | 支持多地域部署，就近接入降低延迟 |
⚙️ 后端服务技术栈
后端由两个纯 Rust 微服务组成，共享同一个 Cargo Workspace 与 common 协议库，同一份工具链、同一套 CI、零 C 依赖，交叉编译到 ARM / MIPS 国产服务器无障碍。
一、信令服务 gbhub-meeting
负责鉴权、房间管理、媒体模式协商、状态同步，是全系统的"大脑"。
运行时与基础设施
| 分类 | 依赖 | 作用 |
|---|---|---|
| 语言 | Rust（Workspace 统一版本） | 内存安全、高并发、无 GC |
| 异步运行时 | Tokio（full features） | 全异步 I/O，MQTT / Redis / HTTP 全无阻塞 |
| 异步工具 | futures-util | Stream / Sink 组合子，处理 MQTT 消息流与并发任务 |
| 内存分配器 | mimalloc（local_dynamic_tls） | 高并发连接场景下延迟更稳、抖动更低 |
| 配置与日志 | dotenv + env_logger + log | 环境变量加载、结构化日志、容器化友好 |
信令与消息
| 分类 | 依赖 | 作用 |
|---|---|---|
| MQTT 客户端 | rumqttc（rustls-no-provider） | 接入自研 MQHub 提供的 MQTT 服务，向前端下发 join/resp、broadcast、chat、mix_state、ext_state、talk_state 等信令 |
| HTTP 客户端 | reqwest（rustls-tls-webpki-roots-no-provider） | 调 ZLMediaKit REST API（开流、关流、开录像、查流） |
| TLS 实现 | rustls（aws-lc-rs） | 现代 TLS，无系统 OpenSSL 依赖，CVE 面更小 |
状态与缓存
| 分类 | 依赖 | 作用 |
|---|---|---|
| Redis 客户端 | redis（tokio-comp + aio） | 读写房间状态、参会者列表、喊话归属、外部流互斥锁 |
| Redis 连接池 | deadpool-redis（rt_tokio_1） | 连接复用，高并发下避免握手开销 |
| 序列化 | serde + serde_json | 房间状态、MQTT 消息体统一 JSON 编解码 |
会话与 ID
| 分类 | 依赖 | 作用 |
|---|---|---|
| 唯一 ID | uuid（v4） | 房间 ID、会话 ID、请求追踪 ID |
| URL 解析 | url（2.x） | 解析 ZLM 返回的 WHIP/WHEP 地址 |
| URL 编码 | urlencoding（2.x） | 构建 WHIP/WHEP 地址时对 app、stream 等参数安全编码 |
共享与错误
| 分类 | 依赖 | 作用 |
|---|---|---|
| 共享库 | common（本地 crate） | MQTT topic / Redis key / ZLM API 路径 / JWT 规则的单点定义 |
| 错误处理 | anyhow | 统一错误传播上下文，日志可定位到具体房间与 API 调用点 |
二、混流服务 gbhub-mcu
负责多路音频混流与双向喊话回推，是"16 路声音合成 1 路"的核心引擎。
运行时与基础设施
| 分类 | 依赖 | 作用 |
|---|---|---|
| 语言 | Rust（Workspace 统一版本） | 内存安全、零成本抽象、无 GC 停顿 |
| 异步运行时 | Tokio（full features） | 单 / 多线程异步调度，MQTT、HTTP、音频任务无阻塞 |
| 内存分配器 | mimalloc（local_dynamic_tls） | 高频音频 buffer 分配场景下延迟更低、抖动更小 |
| 配置与日志 | dotenv + env_logger + log | 环境变量加载、结构化分级日志 |
信令与消息
| 分类 | 依赖 | 作用 |
|---|---|---|
| MQTT 客户端 | rumqttc（rustls-no-provider） | 接入自研 MQHub，订阅房间状态、开麦人数、喊话请求，与前端共用同一套 Topic |
| HTTP 客户端 | reqwest（rustls-tls-webpki-roots-no-provider） | 调 ZLM HTTP API（拉流、录像、喊话回推）、鉴权、房间信息查询 |
| TLS 实现 | rustls（aws-lc-rs） | 现代 TLS 栈，不依赖系统 OpenSSL |
| 序列化 | serde + serde_json | MQTT 消息、API 载荷、配置解析 |
音频处理（核心）
| 分类 | 依赖 | 作用 |
|---|---|---|
| Opus 编解码 | opus-pure | 纯 Rust 实现，无 libopus 的 .so 依赖，交叉编译到 ARM / MIPS 无障碍 |
| G.711 编解码 | oxideav-g711 | GB28181 摄像头 / 对讲终端常用的 PCMA / PCMU |
| 音频重采样 | rubato（fft_resampler） | FFT 重采样，把 8k / 16k / 48k 多源统一到 48kHz |
| 音频缓冲 | audioadapter-buffers | 多路音频流的环形缓冲与适配，处理抖动与时钟漂移 |
共享与错误
| 分类 | 依赖 | 作用 |
|---|---|---|
| 共享库 | common（本地 crate） | 与信令服务共享 MQTT topic / Redis key / ZLM API 定义 |
| 错误处理 | anyhow | 统一错误传播，日志可定位到具体音频流 / 房间 |
三、自研 MQHub 信令服务
MQHub 是 MeetHub 团队自研的 MQTT 信令服务组件，是 MeetHub 全栈自研体系的重要一环。
| 特性 | 说明 |
|---|---|
| 自研而非开源 | 不依赖 Mosquitto / EMQX / HiveMQ 等第三方 Broker，代码完全自主可控 |
| 场景深度定制 | Topic 结构、QoS 策略、心跳周期、重连策略均针对"会议信令"场景深度优化 |
| 同源发布 | 与 MeetHub 同 Cargo Workspace、同 CI、同版本号，随 MeetHub 一同发版、一同升级 |
| 一体化部署 | 一个安装包即包含 MQHub，无需单独部署 / 单独运维 MQTT Broker |
| 内网私有化 | 完全部署在内网，与外部互联网零依赖，满足等保与审计要求 |
| 全链路掌控 | 从浏览器 WSS 接入、信令服务订阅、MCU 事件消费，全链路都是自研代码，出问题可秒级定位 |
关键说明：MeetHub 不依赖任何第三方 MQTT Broker，所有信令流量都由自研 MQHub 承载。好处是——出问题能直接改代码、版本能同步发、私有化部署没有任何"这个 Broker 是客户自己装的"甩锅空间。
四、完整依赖清单
MeetHub 一体化软件包内的全部组件：
| 组件 | 来源 | 角色 |
|---|---|---|
| gbhub-meeting | 自研（Rust） | 信令服务（鉴权 / 房间 / 状态 / ZLM 代理） |
| gbhub-mcu | 自研（Rust） | 混流服务（16 → 1 音频混流 + 喊话回推） |
| MQHub | 自研（Rust） | MQTT 信令总线（WSS 接入 + 消息路由） |
| ZLMediaKit | 开源（C++） | 媒体引擎（WHIP / WHEP / 转发 / 录像） |
| Redis | 开源（C） | 状态存储（房间状态、互斥锁） |
| GB28181 网关 | 自研 / 依赖 GBHub | 国标摄像头 / 音柱 / 对讲机接入 |
依赖策略：核心链路（信令 / 混流 / MQTT / 前端）全部自研；媒体引擎（ZLM）和状态存储（Redis）采用成熟开源组件，只做必要的私有化封装。
五、为什么这样选型
① 纯 Rust，零 C 依赖
opus-pure 替代 libopus、rustls 替代 OpenSSL、oxideav-g711 替代 ffmpeg 片段。单二进制部署，不依赖系统动态库版本，docker pull 即可运行；交叉编译到国产化 ARM / MIPS 服务器零障碍。
② 状态外置 Redis，信令服务无状态
房间状态全部放 Redis。信令服务可无限水平扩展，任何一个实例重启都不影响房间；喊话归属、外部流互斥锁靠 Redis 原子操作（SET NX / LPUSH）保证唯一性。
③ MQTT 用自研 MQHub，全栈自主可控
信令总线不由 MeetHub 依赖第三方 Broker，而是使用 MeetHub 自研的 MQHub。好处是：
- 零外部依赖：不引入 Mosquitto / EMQX / HiveMQ 等第三方组件，部署、升级、排障全在 MeetHub 团队掌控
- 场景定制：Topic 结构、QoS、心跳、重连策略针对会议场景深度调优，比通用 Broker 更贴合业务
- 版本同步：MQHub 与 MeetHub 同 Cargo Workspace、同 CI、同版本号，避免"Broker 版本与业务不兼容"
- 一体化打包：一个安装包即包含全部组件，客户无需单独选型、单独部署、单独运维 MQTT Broker
- 问题秒定位：从浏览器 WSS → MQHub → 信令服务 → MCU，全链路都是自研代码，线上问题能直接改代码
④ 信令服务不碰媒体，媒体扩展交给 ZLM
信令服务只调 ZLM 的 HTTP API，本身不解码、不转发、不混流。单实例轻松支撑数千房间，媒体扩展交给 ZLM 集群。
⑤ common 库统一协议
MQTT topic、Redis key 前缀、ZLM API 路径、JWT 签发校验规则全部在 common 中定义。任何一方修改，编译期就暴露不兼容，杜绝运行时"topic 拼错一个字符"的灾难。
六、两个服务的职责分工
| 维度 | gbhub-meeting（信令服务） |
gbhub-mcu（混流服务） |
|---|---|---|
| 所属层级 | 第二层：信令接入层 | 第三层：媒体转发层 |
| 核心职责 | 鉴权、房间管理、媒体协商、状态同步 | 多路音频混流（16 → 1）、双向喊话回推 |
| 对外接口 | MQHub 信令 + Redis 状态 | MQHub 事件 + ZLM HTTP API |
| 有无状态 | 无状态（状态在 Redis） | 无状态（任务跟随房间事件创建 / 销毁） |
| 能否水平扩展 | ✅ 加实例即扩 | ✅ 按房间绑定节点扩 |
| 典型调用方向 | 浏览器 ↔ MQHub ↔ Redis / ZLM | ZLM ↔ MQHub ↔ GB28181 网关 |
一句话总结：gbhub-meeting 负责"谁在房间里、房间什么状态、前端该连哪条流"；gbhub-mcu 负责"多人开麦时怎么把 16 路声音合成 1 路，以及怎么把这 1 路声音推回现场音柱"。两者通过自研 MQHub 和 ZLM 解耦，各自独立扩展。
七、MCU 混流工作流（文字描述）
① 启动：读 .env → 初始化日志 → 连接 MQHub → 等待房间事件
② 开麦人数达 3 人：收到 MQHub mix_state 变更 → 调 ZLM API 拉取各参会者音频（Opus / G.711）→ 解码到 PCM → 用 rubato 重采样到 48kHz
③ 混流：每路 PCM 通过 audioadapter-buffers 做环形缓冲 → 定时（20ms 一帧）叠加 → 混流结果编码为 Opus
④ 推送：混流音频推回 ZLM → 前端所有参会者只拉 1 路混流音频 → 带宽和前端 CPU 双双下降
⑤ 双向喊话：收到 talk_start → 把 MCU 混流结果通过 GB28181 网关反向推流至现场音柱 → 现场人员听到指挥喊话
⑥ 回落：开麦人数回落至 2 人以下 → 停止 MCU 混流 → 前端切回 P2P 点对点音频，延迟进一步降低
🎬 应用场景
🏢 企业远程办公
跨地域团队实时协作，屏幕演示、文件讨论、画面切换并行，浏览器直接开会。
🚨 应急指挥调度
AI 预警识别异常后自动拉起会议；指挥中心在会议里直接对现场广播喊话；全过程自动录像审计。
🏭 工业园区监控
将 GB28181 摄像头一键拉入会议，与现场对讲终端双向沟通，统一在一套账号体系管理。
🏥 远程医疗会诊
专科摄像头 + 医疗设备画面通过 WHEP 拉入会诊会议；专家实时讨论并指导现场操作。
🎓 在线教育与企业培训
千人旁听的大型培训课，16 人可开麦互动问答；课程自动录制归档，随时回放学习。
💼 远程面试与商务洽谈
1对1 高清通话，画面清晰、全程录像，P2P 延迟低于 100ms，体验接近面对面。
🎧 客服中心视频坐席
视频客服坐席一对多排队接入，全程录像可追溯，支持外部摄像头画面联动。
💰 授权方案
单服务器授权：¥1000 / 台
| 项目 | 说明 |
|---|---|
| ✅ 房间数量 | 不限 |
| ✅ 并发用户 | 不限（单场会议最高 1000 人旁听） |
| ✅ 全部功能 | 混流、外部流、AI 联动、双向喊话、录像，全部开放 |
| ✅ 版本升级 | 一年内免费升级至最新版本 |
| ✅ 技术支持 | 7×12 小时 专业技术支持 |
| ✅ 部署协助 | 提供初始安装部署协助 |
无隐藏费用，无按人头收费，一次授权，服务器内无限用。
部署流程
- 获取授权 — 联系我们购买 License，确认服务器信息
- 技术部署 — 远程安装 MeetHub 一体化软件包（内含 MQHub / 信令 / 混流 / ZLM / Redis），配置 HTTPS（1 天内可完成）
- 开始使用 — 创建账号与房间，分享链接给参会人
推荐配置： 4 核 8G 内存，100M 带宽，Linux（x86_64 / ARM64）
⚡ 立即体验
演示地址： https://mgr.automate.org.cn
- 🎯 1对1 通话演示：
https://mgr.automate.org.cn/meeting/?room=1234567 - 👥 多人会议演示：
https://mgr.automate.org.cn/meeting/group.html?room=3456
无需注册、无需安装插件，用 Chrome / Edge / Safari 最新版打开，输入任意房间号即可体验。
📊 关键指标速览
| 指标 | 数据 |
|---|---|
| P2P 通话延迟 | < 100ms |
| 单场会议容量 | 1000 人 旁听 |
| 同时开麦上限 | 16 人 |
| 同时开视频上限 | 4 人 |
| 弱网自动重连 | 3 秒 |
| 外部流 / 喊话状态恢复 | 10 秒 |
| 前端音频解码数 | 1 路（MCU 混流后） |
| 后端语言 | 纯 Rust（零 C 依赖） |
| 信令总线 | MQHub（MeetHub 自研），无第三方 MQTT Broker 依赖 |
| 授权价格 | ¥1000 / 服务器 |
📞 联系我们
官网： https://me.automate.org.cn
微信联系： prcloud（扫码或搜索添加）
服务时间： 工作日 9:00 - 21:00 在线回复
🎁 现在开始
- 体验演示 → https://mgr.automate.org.cn
- 添加微信 →
prcloud咨询授权与部署 - 私有化上线 → 一天内完成部署，次日即可开会
MeetHub · 让企业拥有属于自己的 WebRTC 视频会议平台
© 2026 MeetHub · 保留所有权利