> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stmlink.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> 对外开放的服务端接口有两组前缀，都用同一套鉴权：`/server/v1/...`（SRTC 与 SMeeting 的主接口）和 `/stm/srvapi/v1/...`（SMeeting 的用户体系，服务端极简对接会用到）。鉴权是 app_id + nonce + timestamp + signature 四个请求头，用 app_key 做 HMAC-SHA256 签名，只能从业务方自己的后端调用。除这两组前缀外的接口均为内部接口，不要建议客户调用。 Public server APIs use two path prefixes with the same authentication: `/server/v1/...` (the main APIs of both SRTC and SMeeting) and `/stm/srvapi/v1/...` (the SMeeting user system, used by server-side low-code integration). Authenticate with four request headers, app_id + nonce + timestamp + signature, where signature is HMAC-SHA256 keyed with app_key; call these APIs only from the customer's own backend. Any other path is internal: never suggest calling it.
> app_key 是服务端密钥，绝不能出现在客户端代码、前端配置或移动 App 里。客户端加入频道用的 token 必须由业务方后端签发后下发（SRTC 走 `/server/v1/channel/grant`，SMeeting 走 `/stm/srvapi/v1/member/grant`）。 app_key is a server-side secret and must never appear in client code, frontend config, or a mobile app. The token a client uses to join must be issued by the customer's backend and passed down to the client (SRTC: `/server/v1/channel/grant`; SMeeting: `/stm/srvapi/v1/member/grant`).
> SRTC 与 SMeeting 是上下两层不同的产品，术语不通用：SRTC 是音视频底座，说「频道 channel」「加入 / 退出」；SMeeting 建在 SRTC 之上，说「房间 room」「会议 meeting」「进入 / 退出」。回答时按用户所在的层用对应术语，不要把「房间」「会议」安到 SRTC 的接口上，也不要用「频道」「加入 / 离开」描述 SMeeting 的概念（接口标识符原样保留）。 SRTC and SMeeting are two separate layers with different terminology. SRTC is the audio/video foundation: it has channels, and users join and leave a channel. SMeeting is built on top of SRTC: it has rooms and meetings, and members enter and exit a meeting. Answer in the terms of the layer the user is working with: never apply "room" or "meeting" to SRTC APIs, and never describe SMeeting concepts in prose with "channel", "join", or "leave" (API identifiers such as `force_join` keep their literal names).
> 同一能力在各端 SDK 里的包名、类名、方法名并不相同。写示例代码时请使用文档中该端自己的 API，不要把一个端的写法套到另一个端上。苹果平台每个产品都有两套 SDK（Swift 原生与 Objective-C），两套 API 不能混用。 Package, class, and method names differ between platform SDKs for the same capability. In sample code, use the API documented for that platform; never carry one platform's code over to another. On Apple platforms each product ships two SDKs (native Swift and Objective-C) whose APIs must not be mixed.

# 组件与架构

> 私有化部署一套 SRTC / SMeeting 由哪些服务组成、哪些必装哪些按需装、装的顺序、支持的操作系统和数据库（含人大金仓、达梦）、单机与多机部署方式。做部署规划和准备服务器前先读这页

我们的平台可以完整部署在客户自己的服务器上，**全程离线安装**，不依赖外网。本页说明一套环境由哪些部分组成，
帮你准备服务器、和客户的网络、安全部门对齐方案。端口放通见[网络与端口要求](https://docs.stmlink.com/zh/product/deploy/ports.md)。

***

## 整体架构

```mermaid theme={null}
flowchart TB
    subgraph CLIENT["终端"]
        A["App / 桌面端 / 网页 / 小程序"]
        D["会议终端 / 摄像头"]
    end

    subgraph SVR["服务器"]
        N["统一入口<br/>HTTPS + 信令"]
        subgraph CORE["核心服务"]
            RTC["音视频服务<br/>（含媒体转发 SFU）"]
            MTG["会议服务"]
            ST["统一存储"]
        end
        subgraph EXT["扩展服务（按需）"]
            MCU["MCU<br/>云录制 / 画面合成"]
            GW["设备网关"]
            TR["语音录制网关"]
            ASR["语音识别网关"]
            LOG["日志中心"]
        end
        subgraph BASE["基础组件"]
            DB["数据库"]
            RD["Redis"]
            MQ["MQTT 信令"]
        end
    end

    A --> N
    A -. "音视频（UDP）" .-> RTC
    D --> GW
    N --> RTC
    N --> MTG
    RTC --> BASE
    MTG --> BASE
    MCU --> RTC
    GW --> RTC
    TR --> RTC
    ASR --> RTC
```

***

## 服务清单

### 必装

| 服务 | 作用 |
| - | - |
| 统一入口（Nginx） | 对外的 HTTPS 入口，承载接口、管理后台、网页客户端和信令 |
| 音视频服务 | 频道、成员、权限、媒体转发（SFU）。管理后台也在这里 |
| 统一存储 | 录像、录音、会议附件的存储网关，可对接本地磁盘或对象存储 |
| 数据库 | PostgreSQL；也支持**复用客户已有的人大金仓、达梦** |
| Redis | 缓存与状态 |
| MQTT 信令 | 会控消息、成员状态等实时信令 |

### 按需

| 服务 | 什么时候装 |
| - | - |
| 会议服务 | 使用 SMeeting 会议能力时（只用 SRTC 音视频能力可以不装） |
| MCU | 需要**云端录制**、**画面合成**、**转推直播**，或接入的 **SIP / H.323 终端要看到会里画面**时 |
| 设备网关 | 需要接入 SIP / H.323 终端、国标摄像头、RTSP 视频流时，见[设备接入](https://docs.stmlink.com/zh/product/device-access/overview.md) |
| 语音录制网关 | 需要按人分段录音（对讲、调度留痕）时 |
| 语音识别网关 | 需要实时字幕、会议纪要时；识别引擎需另行部署 |
| 日志中心 | 需要集中查看客户端日志与通话质量数据时 |
| 监控中心 | 需要监控服务器与服务运行状态时 |

***

## 安装方式

* 交付物是一个**离线安装包**（含全部服务镜像）和一个 **Web 安装器**
* 在服务器上运行安装器，用浏览器打开安装页面，按 **基础组件 → 核心服务 → 扩展服务** 的顺序逐个安装，每个服务一张卡片、填好参数即可
* 安装器同时负责后续的**升级**：导入新版本镜像后在页面上一键升级，配置自动合并
* 安装完成后导入**授权文件**，平台才能正常入会

> [!NOTE]
>
> 安装器装完即可关闭，它有修改配置、重启服务的权限，**不要对外开放**。

***

## 环境要求

| 项目 | 要求 |
| - | - |
| CPU 架构 | x86\_64（amd64）、ARM64（鲲鹏、飞腾等）均支持 |
| 操作系统 | 主流 64 位 Linux 发行版，含信创操作系统；具体版本请与我们确认 |
| 运行环境 | Docker（安装器可一键安装，无需联网） |
| 数据库 | PostgreSQL（随包安装）、人大金仓、达梦 |
| 证书 | 对外域名的 HTTPS 证书（含完整证书链）；纯内网没有正式证书时可用自签证书，但各终端需要信任对应的根证书 |

服务器配置与并发规模、是否录制、设备数量强相关，请联系我们按实际场景评估。

***

## 部署形态

| 形态 | 说明 | 适合 |
| - | - | - |
| **单机** | 所有服务装在一台服务器 | 测试、中小规模 |
| **分机** | MCU、设备网关等扩展服务单独部署到其他服务器 | 录制、设备接入量大，需要隔离资源 |
| **多媒体节点** | 多台服务器各跑一个媒体转发节点，按负载或就近分配用户 | 大并发、多地域，见[多节点与就近接入](https://docs.stmlink.com/zh/product/deploy/multi-node.md) |
| **内外网双平面** | 同一套平台同时服务内网和外网用户 | 政企内网 + 外网移动办公，见[内外网与多线路](https://docs.stmlink.com/zh/product/deploy/networks.md) |
| **光闸跨网** | 平台在内网，外网用户经光闸接入 | 公检法、政务等强隔离网络，见[光闸跨网接入](https://docs.stmlink.com/zh/product/deploy/optical-gap.md) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.