WebRTC 服务器之Janus架构分析

1. Webrtc三种类型通信架构

1.1  1 对 1 通信

1 对 1 通信模型设计的主要⽬标是尽量让两个终端进⾏直联，这样即可以节省服务器的资源，⼜可以提⾼ ⾳视频的服务质量。WebRTC ⾸先尝试两个终端之间是否可以通过 P2P 直接进⾏通信，如果⽆法直接通信 的话，则会通过 STUN/TURN 服务器进⾏中转，如下图：

 1.2  多对多通信

Mesh 架构：适合刚学习 WebRTC 的场景，简单易实现，但实际应用中因上行带宽占用大、线性资源占用等问题，超过 4 人时问题明显，几乎无人在真实场景中使用。

MCU 架构：硬件 MCU 曾在视频会议广泛应用，技术成熟，但价格昂贵，且随着互联网发展逐步被淘汰；软 MCU 如 FreeSWITCH 虽存在，但因 CPU 消耗大，真正使用者不多。

SFU 架构：近年来流行，是 WebRTC 多方通信媒体服务器的主流架构，具有高灵活性和高性能，配合 Simulcast 或 SVC 模式可更好地适应不同网络和终端，被多数公司采用。

Janus的多方视频通话使用VideoRoom插件，采用SFU架构。

 1.2.1 架构优点

架构

方案

优势

        Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流（⼀般为三路， 如 1080P、720P、360P）。⽽ SFU 可以将接收到的三路流根据各终端的情况⽽选择其中某⼀路发送出 去。例如，由于 PC 端⽹络特别好，给 PC 端发送 1080P 分辨率的视频；⽽移动⽹络较差，就给 Phone 发送 360P 分辨率的视频。 Simulcast 模式对移动端的终端类型⾮常有⽤，它 可以灵活⽽⼜智能地适应不同的⽹络环境。      

         SVC（ Scalable Video Coding） 是可伸缩的视频编码模式。与 Simulcast 模式的 SVC 模式是 同时传多路流不同， 在视频编码时做“ ⼿脚” 。它在视频编码时将视频分成多层—— 核⼼层、中间层和扩展层。上层依赖于底层，⽽且越上层越清晰，越底层越模糊。在带宽不好的情况下，可以只传输核⼼层，在带宽充⾜的情况下，可以将三层全部 传输过去。

 2. Janus 系统架构

        Janus 被设计为通用的 WebRTC 服务器，专注于模块化和可扩展性。它提供必要的 WebRTC 基础设施，同时将特定的应用程序逻辑委托给插件。这种分离使 Janus 变得轻量级和灵活，无需更改内核即可支持广泛的用例。

架构的关键原则：

• 模块化设计：核心组件通过定义明确的接口清晰分离
• 基于插件的可扩展性：所有特定于应用程序的逻辑都在插件中实现
• 多传输支持：用于客户端交互的多种通信协议
• 媒体和信令分离：WebRTC 媒体处理和信令逻辑之间的明确分离

全局架构图如下：

2.1 核心组件

        Janus 核心处理 WebRTC 和会话管理基础知识，提供插件和传输构建的基础基础设施。

2.1.1 会话和句柄模型

Janus 中最重要的架构概念之一是 session/handle 模型：

• 会话：表示用户与 Janus 的连接
• Handle：表示用户与特定插件之间的连接
• PeerConnection：与句柄关联的 WebRTC 连接
• transaction：表示当前消息信息的唯一句柄

这种关系在用户、插件和媒体连接之间建立了明确的分离。客户端与 Janus 创建会话。在此会话中，客户端可以附加到多个插件（创建句柄）。每个句柄都有自己的 WebRTC PeerConnection，用于管理媒体交换。

2.1.2 会话管理

会话是客户端连接到 Janus 的核心抽象。会话管理系统处理：

• 会话创建和销毁
• 会话超时（可配置，默认 60 秒）
• 会话声明（在传输断开连接后恢复会话）

每个会话都包含句柄，这些句柄是会话和插件实例之间的桥梁。会话层维护客户端与其插件附件之间的关系。

2.1.3 Media Handl管理

Janus 的媒体处理层负责 WebRTC 连接和媒体处理。ICE （Interactive Connectivity Establishment） 组件处理：

• 候选人聚集和交流
• NAT 遍历
• 连接建立
• 用于安全连接的 DTLS 协商
• 用于加密媒体的 SRTP

 ​​​​​

媒体路径处理：

• RTP/RTCP 数据包从 routing 到plugins
• SDP offer/answer 处理
• 媒体统计和监控
• 数据包重传的 NACK 处理
• TWCC（全交通拥堵控制）

2.2 插件系统

        Janus 提供了一个插件架构，允许开发人员在不修改核心代码库的情况下实现各种 WebRTC 应用程序。插件向 Janus 核心注册，并为消息处理和媒体处理等事件实施回调。内核仅负责 WebRTC 连接和数据包路由，而插件则决定媒体会发生什么并实现应用程序逻辑。

Janus 包含的常见插件：

• VideoRoom：用于多方视频会议的选择性转发单元 （SFU）
• AudioBridge：具有混音功能的音频会议
• 流式处理：媒体流式处理（RTP、RTSP、HLS 源）
• SIP：用于 WebRTC 到 SIP 互作性的 SIP 网关
• EchoTest：用于测试 WebRTC 功能的简单 echo 测试插件
• TextRoom：基于数据通道的文本聊天室
• RecordPlay：WebRTC 会话的录制和播放

插件 API 公开了允许插件执行以下作的函数：

• 接收和发送媒体 （RTP/RTCP）
• 与客户交换消息
• 管理 WebRTC 连接
• 处理 SDP offers/answers
• 通过 Data Channel 发送和接收数据

2.3 传输层

        传输层提供客户端和 Janus 服务器之间的通信通道。可以同时使用多种传输机制，从而灵活地选择客户端连接到 Janus 的方式。

• HTTP/REST：用于请求-响应交互的传统 REST API
• WebSockets：实时双向通信
• RabbitMQ：基于消息队列的通信
• MQTT：轻量级发布-订阅消息传递
• Unix 套接字：同一台机器上的进程间通信

 所有传输都实现相同的 API，无论底层协议如何，都为核心提供一致的接口。这允许客户端选择最适合其需求的传输机制。

传输层负责：

• 身份验证请求（如果已配置）
• 解析和验证 JSON 消息
• 将请求路由到适当的会话/句柄
• 将事件和响应返回给客户端

2.4 事件处理程序

        事件处理程序为外部应用程序提供了一种监视和响应 Janus 中发生的事件的方法。这些事件可以包括会话创建/销毁、媒体统计、特定于插件的事件等。事件处理程序（如传输和插件）在启动时动态加载，并在内核中注册。它们从核心接收事件，并将其转发到外部系统进行监控、记录或处理。

2.5 实用程序和工具

2.5.1 实用程序

        Janus 提供了多种后处理工具，用于将录音转换为可以使用常见媒体播放器播放的标准格式。实用程序允许您将 Janus Media Recorder （） 文件转换为标准媒体格式。

Supported Output Formats  支持的输出格式

基本用法：

./janus-pp-rec /path/to/source.mjr /path/to/destination.[opus|ogg|mka|wav|webm|mkv|mp4|srt]
#分析录制信息而不进行处理：
./janus-pp-rec –json /path/to/source.mjr # Print JSON header
./janus-pp-rec –header /path/to/source.mjr # Parse header only
./janus-pp-rec –parse /path/to/source.mjr # Parse without processing

Janus 还包括用于在 Janus 录音和数据包捕获格式之间进行转换的实用程序：

• mjr2pcap：将 Janus 记录转换为 PCAP 格式，以便在 Wireshark 等工具中进行分析
• pcap2mjr：将 PCAP 文件转换为 Janus 录制格式

 2.5.2 测试工具

        Janus 提供了测试工具来验证 WebRTC 网关的功能和性能。aiortc 测试套件！该目录包含使用 WebRTC 功能测试库的基于 Python 的测试工具。test/aiortc

测试套件的 Python 依赖项：

websockets==15.0
aiortc==1.10.1

可以使用提供的帮助程序脚本执行测试套件：

./test_aiortc.sh echo.py ws://localhost:8188/

3.1 数据流架构

        下图说明了在典型的 WebRTC 交互期间通过 Janus 架构的完整数据流。此流程展示了 Janus 的不同层如何协同工作以处理 WebRTC 信令、媒体交换和特定于应用程序的逻辑。各个组件之间的干净分离实现了灵活性和可扩展性。

英文版： 

学习资料分享

0voice · GitHub