2026 年 1 月，法国政府宣布将在 2027 年前全面淘汰 Zoom、Microsoft Teams 和 Google Meet，用国产视频会议应用 Visio 取而代之。这并非单纯的政治表态，而是对技术主权的系统性诉求：超过 80% 的欧盟数字产品依赖非欧盟国家，数据主权与通信安全的边界正在被重新划定。本文不从政策角度展开，而是聚焦于构建这样一套主权视频栈的工程现实 —— 基于开源 Jitsi 生态的 WebRTC 架构选型、端到端加密的技术实现，以及与商业产品之间的功能差距与填补路径。
核心组件与架构划分
Jitsi 生态由五个核心项目构成，每个组件承担独立职责，理解这一分工是部署的基础。第一层是 Prosody，一个轻量级 XMPP 服务器，负责信令交换与用户认证。客户端通过 XMPP 协议与 Prosody 通信，完成房间创建、参与者状态同步、消息传递等任务。Prosody 的选择源于其对 WebSocket 的原生支持以及对 TLS 加密的完善实现，这在主权架构中尤为重要 —— 信令层的任何泄漏都会暴露元数据，而不仅仅是媒体内容。
第二层是 Jicofo（Jitsi Conference Focus），负责会议的生命周期管理。当用户加入房间时，Jicofo 分配 Videobridge 资源、协调 ICE 候选交换、处理参与者的加入与离开事件。Jicofo 的设计哲学是 "无状态会议"—— 它不持久化会议状态，仅在会议进行时维护必要的信息。这种设计简化了水平扩展：单个 Jicofo 实例可以同时管理数千个房间，而 Videobridge 的负载则可通过增加节点来线性扩展。
第三层是 Jitsi Videobridge（JVB），作为 SFU（Selective Forwarding Unit）处理媒体路由。与传统的 MCU（Multipoint Control Unit）不同，SFU 不对媒体流进行解码再混合，而是将每个参与者的编码流选择性转发给其他参与者。这一设计显著降低了服务端算力需求：JVB 只需维持约 100-200Mbps 的转发带宽即可支持 50 人的会议，而 MCU 在同等规模下需要完成数十路解码和一路编码，CPU 负载完全不在一个量级。
第四层是 Jitsi Meet 前端，采用 React 构建，提供跨平台的 Web 与移动端体验。前端通过 lib-jitsi-meet 库与后端通信，该库封装了 WebRTC 的复杂性，提供统一的 API 表面。前端代码库中有专门的 modules/e2ee 目录处理端到端加密，这一层将在下文详细展开。
第五层是 Jibri（Jitsi Broadcasting Infrastructure），用于会议录制与直播。Jibri 的实现方式较为特殊：它启动一个无头 Chrome 浏览器实例，渲染会议画面后通过 ffmpeg 采集编码。这种 "虚拟摄像头" 方案虽然资源消耗较高，但兼容性极佳 —— 任何前端支持的特性都会自动体现在录制中，无需额外适配。
理解这五个组件的关系后，可以勾勒出典型的信令与媒体流路径：用户通过 HTTPS 访问 Jitsi Meet 前端，前端与 Prosody 建立 WebSocket 连接加入 XMPP 房间；Jicofo 感知到新参与者后，分配 Videobridge 并通知双方进行 ICE 候选交换；WebRTC 连接建立后，媒体流直接通过 DTLS-SRTP 加密传输至 Videobridge，Videobridge 再将流转发给其他参与者。全程 Prosody 不接触媒体流，Jicofo 仅在关键节点介入，信令与媒体分离的架构天然具备抗单点故障能力。
端到端加密的技术实现
政府级视频栈的核心安全要求是端到端加密（E2EE）—— 即使服务器被攻破，攻击者也无法获取会议内容。Jitsi 的 E2EE 实现基于 WebRTC Insertable Streams API 与 SFrame 格式的变体，在浏览器原生加密框架之上构建了完整的密钥管理体系。
Insertable Streams API 是 WebRTC 的扩展，允许在 RTP 编码帧离开浏览器之前进行自定义处理。传统 WebRTC 使用 DTLS-SRTP 在传输层加密，但服务器（Videobridge）必须能够解密才能转发流，这意味着服务器拥有明文访问权限。Insertable Streams 解决了这个问题：编码后的帧在送入网络接口之前，会先经过一个 "插入" 阶段进行额外加密；接收端在解码之前，通过对应的 "提取" 阶段解密。服务器看到的只是双重加密的 blob，无法获取原始媒体内容。
Jitsi 的 E2EE 实现使用 AES-128-GCM 或 AES-256-GCM（取决于配置）进行媒体加密。加密帧的格式经过精心设计，以保持与 SFU 架构的兼容性。为了让 Videobridge 能够进行选择性转发，必须保留足够的元数据 —— 具体来说，VP8 视频帧的前 10 字节（关键帧）或前 3 字节（Delta 帧）、Opus 音频帧的 1 字节 TOC（Table of Contents）保持明文，其余载荷使用 AES-GCM 加密。加密后的帧结构如下：明文头部 + 密文载荷 + 12 字节 IV + 1 字节 IV 长度 + 1 字节密钥索引。这种格式被称为 "trailer-based format"，源自 IETF 的 SFrame 草案，但针对 Jitsi 的需求进行了调整。
密钥管理是 E2EE 的另一核心挑战。Jitsi 采用 Olm 协议进行密钥交换与分发，Olm 是 Matrix 协议中广泛使用的端到端加密库，基于 Double Ratchet 算法。每个参与者都有一个 256 位的主密钥（Master Key），从中派生出当前密钥（Current Key）用于加密。每当新参与者加入会议时，主密钥进行一次 "ratchet" 操作，生成新的当前密钥；由于 ratchet 是单向的，旧密钥无法恢复，从而实现前向安全性。当参与者离开时，会触发完整的密钥轮换，生成新的主密钥并分发给剩余参与者。
Olm 会话建立过程涉及四次消息交换。假设参与者 A（ID 较小）首先创建会话，向 B 发送 SESSION_INIT 消息，包含 A 的身份密钥与一次性密钥；B 收到后初始化 Olm 会话，回复 SESSION_ACK 并附带 B 的一次性密钥；此时双方已建立加密通道，A 通过 KEY_INFO 消息发送加密密钥给 B；B 确认收到后回复 KEY_INFO_ACK，并可附带自己的密钥。这一设计确保即使在会话建立阶段，也没有明文密钥在网络上传输。
为了防止中间人攻击，Jitsi 支持 Short Authentication String（SAS）验证。参与者在建立加密通道后，可以对比一个 4 字符或 7 字符的短字符串 —— 如果通道是安全的，双方看到的 SAS 应该一致；如果存在中间人，攻击者只能看到不同的 SAS。这种验证方式不需要额外的通道或设备，适合视频会议场景。
所有加密操作在独立的 Web Worker 中执行，避免阻塞主线程导致 UI 卡顿。Worker 接收主线程发来的帧，进行加密或解密后返回。由于密钥材料从不离开 Worker，且 Worker 与主线程之间的通信使用 postMessage，恶意脚本难以窃取密钥。浏览器兼容性方面，Jitsi 首先检测 window.RTCRtpScriptTransform 是否可用，这是现代浏览器支持的 API；如果不可用，则回退到已废弃但仍被部分浏览器支持的 createEncodedStreams；如果两者都不可用，E2EEncryption.isSupported() 返回 false，E2EE 选项将不可用。
部署架构与扩展参数
主权视频栈的部署必须考虑性能、可靠性与合规性的平衡。Jitsi 官方提供了 Docker Compose 配置，将五个核心组件封装为独立容器，这一编排方式是生产部署的良好起点。
Prosody 容器运行 XMPP 服务，监听 5222 端口（客户端连接）与 5280 端口（HTTP/BOSH）。默认配置使用 Prosody 的社区版，但对于高并发场景，可考虑编译安装带有 Luajit 支持的版本，性能提升约 30%。Prosody 的资源占用较低，单核 CPU 配合 512MB 内存即可支撑数千并发用户，但 I/O 是常见瓶颈 —— 建议使用 SSD 存储，并考虑启用 Prosody 的 mod_webhooks 将事件外发至监控系统。
Jicofo 容器是会议的协调者，单实例可管理数千房间。Jicofo 的配置关键是 jicofo.bridge.muc 指定 Videobridge 列表，jicofo.conference.allow-joining-before-host 控制是否允许主持人未到场时其他人加入。Jicofo 本身无状态，可水平扩展，但通常单个实例已足够 —— 瓶颈往往在 Videobridge 而非 Jicofo。
Videobridge 是资源消耗最大的组件。每个 JVB 实例的健康检查端点为 /about/health.json，返回 200 表示正常运行。JVB 的核心参数包括：
| 参数 | 默认值 | 建议调整范围 | 说明 |
|---|---|---|---|
VIDEOBRIDGE_MAX_MEMORY |
3072m | 2048m-6144m | JVM 堆内存，根据并发会话数调整 |
JVB_AUTH_USER |
jvb | - | 认证用户名，需与 Prosody 配置一致 |
JVB_AUTH_PASSWORD |
随机生成 | - | 建议使用 32 位以上随机字符串 |
JVB_STUN_MAPPING_ BEARER_ADDRESSS |
- | - | STUN 服务器地址，用于 NAT 穿透 |
JVB 的横向扩展通过增加实例并配置负载均衡实现。常见的方案是在 Jicofo 前部署 Nginx 或 HAProxy，配置 round-robin 转发 XMPP 流量；或者使用云服务商提供的 Application Load Balancer。JVB 之间不需要直接通信，每个参与者只与一个 JVB 建立连接。
对于政府级部署，还需要考虑地域合规。例如，法国政府要求公民数据不得出境，因此所有组件必须部署在法国境内的数据中心。DINUM 的 Visio 项目可能采用多区域部署：主区域在巴黎，灾备区域在马赛或里昂，区域之间通过专线同步状态。这种架构的关键是 Jicofo 的状态共享 ——Jicofo 本身无状态，但会议房间信息存储在 Prosody 的 XMPP 树中，跨区域同步需要额外的配置。
功能差距与工程权衡
开源方案与商业产品之间的功能差距是务实评估时必须正视的问题。Zoom 和 Teams 经过多年迭代，在用户体验、稳定性、兼容性方面积累了显著优势，单纯部署 Jitsi 无法立即达到同等水平。
首要差距是弱网适应性。Zoom 的自适应码率算法可以在 100kbps 的带宽下维持可用的视频质量，而 Jitsi 默认配置在低于 1Mbps 时画面会出现明显卡顿。Jitsi 的带宽估计基于 WebRTC 的 REMB 反馈机制，但默认配置较为保守。可以通过调整 Videobridge 的 config.js 中的 bandwidth 参数启用更激进的降级策略，例如将最大视频码率从 2500kbps 降至 800kbps，帧率从 30fps 降至 15fps。此外，启用 VP9 编码可以在低码率下获得更好的视觉质量，但编码计算量更高。
第二个差距是会议功能完整性。Zoom 提供了丰富的会议控制功能 —— 等候室、举手、分组讨论、投票、实时字幕、背景降噪等。Jitsi 通过插件生态支持部分功能：等候室通过 Prosody 的 mod_muc_waitingroom 实现；举手和反应在 Jitsi Meet 2.0+ 中已原生支持；分组讨论需要额外的 Jicofo 配置或第三方方案；投票和实时字幕暂无官方支持，需要通过 iframe 嵌入或自定义开发。ANSSI（法国国家信息安全局）对某些功能（如实时字幕的云端处理）可能存在顾虑，这既是挑战也是差异化机会 —— 可以针对性地实现本地化的 AI 字幕方案。
第三个差距是终端兼容性。Zoom 的桌面客户端覆盖 Windows、macOS、Linux，移动端覆盖 iOS、Android、Web。Jitsi 的 Web 端体验已经相当完善，但桌面客户端基于 Electron，资源占用较高且在低端设备上表现不佳。Linux 桌面客户端的问题尤其突出 ——Jitsi 的 Debian 包依赖较新的库，与某些发行版的默认环境不兼容。对于政府内部部署，可以考虑统一硬件标准或提供预配置的虚拟机镜像，规避客户端兼容性问题。
第四个差距是管理与合规功能。企业级视频会议需要详尽的审计日志、合规报告、eDiscovery 支持。Jitsi 的日志默认输出到 stdout，通过 ELK Stack 或类似方案收集分析。审计功能需要自定义开发 —— 例如，记录每次会议的开始时间、参与者列表、结束时间，以及聊天消息的哈希值。Jitsi 的外部 API（modules/external-api）提供事件钩子，可以用于集成 SIEM 系统或合规平台。
功能差距的填补需要投入工程资源，但开源方案的优势在于可控性。商业产品不会为特定国家的合规要求定制代码，而开源方案可以按需修改。例如，法国可能要求所有加密操作使用法国认可的算法套件，或要求密钥管理器的硬件安全模块（HSM）通过特定认证 —— 这些需求在开源栈中都可以实现。
监控与运维要点
生产环境的视频会议系统需要全方位的监控体系。Jitsi 各组件暴露了丰富的 Prometheus 指标，合理配置监控可以提前发现性能瓶颈。
Prosody 的 mod_status 暴露在线用户数、房间数、消息速率等指标。Jicofo 的指标端点为 /colibri/metrics，返回会议室占用率、Participant/Endpoint 数量、带宽分配等。JVB 的指标端点为 /about/metrics，包括 CPU 使用率、内存占用、活跃会议数、参与者数、进出流量字节数等。Prometheus 配置中建议为每个组件设置独立的 job_name，便于按组件筛选。
关键告警规则包括：Jicofo 房间数超过阈值（根据硬件配置，单实例通常可处理 2000-5000 房间）、JVB 活跃参与者数超过容量（单个 JVB 实例通常可处理 50-100 路视频流）、带宽使用率超过 80%（可能导致画质下降）、延迟超过 500ms（RTT 过高影响实时性）、丢包率超过 2%（视频卡顿）。
日志收集建议使用 Filebeat 或 Fluentd 采集各容器的日志，统一送入 Elasticsearch 或 Loki。Jitsi 的日志级别默认为 INFO，在排查问题时可临时调整为 DEBUG。需要注意日志中可能包含 PII（个人身份信息）—— 例如，XMPP 消息中可能包含用户的显示名称或邮箱前缀，生产环境应配置脱敏规则。
联邦互通与生态扩展
主权视频栈的长期价值不仅在于替代现有工具，还在于构建可互操作的通信生态。Matrix 协议的设计理念是 "联邦"—— 任何运行 Matrix 服务器的组织都可以与其他服务器的用户通信，类似于 email。Tchap，法国政府已有的安全消息应用，正是基于 Matrix 构建。
Jitsi 与 Matrix 的集成已有成熟方案：matrix-jitsi 桥接器允许 Matrix 房间与 Jitsi 会议互通。用户通过 Element（Tchap 的前端）创建会议，桥接器自动生成 Jitsi 房间链接，Matrix 房间成员点击链接即可加入会议。桥接器还支持将 Jitsi 的聊天消息同步到 Matrix 房间。
这一集成具有战略意义：如果 Visio 未来需要扩展为同时支持即时消息、视频会议、文件共享的综合协作平台，可以复用 Matrix 生态的基础设施。Matrix 的 E2EE 实现经过多年审计，ANSSI 对其安全性有正面评价。联邦架构意味着法国政府可以邀请欧盟合作伙伴加入同一个协作网络，而无需依赖美国的云服务。
另一个扩展方向是硬件终端集成。政府会议室通常配备专用的视频会议终端（Poly、Yealink、Cisco 等），这些设备通常支持 SIP 或 H.323 协议。Jigasi（Jitsi Gateway to SIP）是 Jitsi 生态中连接 SIP 终端的组件，允许传统会议室设备加入 Jitsi 会议。这一能力在过渡期尤为重要 —— 不可能一次性替换所有会议室设备，Jigasi 提供了平滑迁移的路径。
资料来源
本文技术细节参考以下来源：Jitsi 官方文档关于架构与部署的说明（https://jitsi.github.io/handbook/docs/architecture/）；Jitsi E2EE 白皮书详细描述了端到端加密的设计与实现（https://jitsi.org/e2ee-whitepaper/）；lib-jitsi-meet 的源代码展示了 WebRTC Insertable Streams 的集成方式与密钥管理逻辑；法国政府关于 Visio 项目的公开声明来自 La Tribune Dimanche 采访报道（2026 年 1 月）；Tchap 案例研究说明了 Matrix 在政府安全通信中的应用（https://element.io/en/case-studies/tchap）。