> ## 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.

# 内外网与多线路

> 一套私有化平台同时服务内网用户和外网用户怎么部署：什么是网络线路（内网/外网）、每条线路要准备的入口地址和媒体地址、入口与出口 IP 不同的机房要注意什么，以及业务系统如何让用户走对线路

政企客户常见的情况：平台部署在内网机房，内网员工直接访问；出差、居家的同事从外网访问，
走的是防火墙映射出去的公网地址。同一套平台、同一场会议，内外网用户要能互通。

我们用**网络线路**解决这个问题：平台为每条线路分别配置一组「客户端该连的地址」，
用户进会时说明自己走哪条线路，平台就把对应的地址发给他。

***

## 网络线路是什么

```mermaid theme={null}
flowchart LR
    subgraph IN["内网"]
        U1["内网用户"]
    end
    subgraph OUT["外网"]
        U2["外网用户"]
    end
    FW["防火墙 / NAT<br/>公网 IP 203.0.113.10"]
    P["平台服务器<br/>192.168.10.8"]

    U1 -- "线路：内网<br/>连 192.168.10.8" --> P
    U2 -- "线路：外网<br/>连 203.0.113.10" --> FW
    FW --> P
```

每条线路包含两类地址：

| 地址 | 作用 | 端口 |
| - | - | - |
| 入口地址 | 接口、信令、网页访问 | 443/TCP、18883/TCP |
| 媒体地址 | 音视频 | 39001/UDP |

常见是两条线路：**内网**、**外网**。也可以按需配置更多（例如专网、另一个园区）。

***

## 部署时要准备什么

1. **每条线路的地址**：内网线路用服务器内网地址；外网线路用防火墙映射出去的公网 IP 或域名
2. **防火墙映射**：外网线路的 443/TCP、18883/TCP、39001/UDP 映射到平台服务器，**端口号保持一致**
3. **域名与证书**：内外网通常使用不同的访问地址，证书要覆盖到用户实际访问的那个域名
4. **在安装器中选择网络模式**：仅内网、仅外网、或内外网都有。安装完成后，各线路的入口地址可以在管理后台 **系统配置 → 网络** 中查看和修改

> [!WARNING]
>
> **入口 IP 和出口 IP 不同的机房要特别注意**：很多机房用户访问进来的公网 IP，和服务器访问外网时出去的 IP 不是同一个。
> 这种情况下必须把外网线路的媒体地址**明确配置成用户访问进来的那个公网 IP**，否则外网用户能进会但没有画面和声音。

***

## 用户怎么走对线路

平台根据用户进会时带的「线路」决定发哪组地址给他。业务系统有两种做法：

* **让用户选**：客户端列出「内网 / 外网」，用户自己选
* **服务端自动判断**：按用户访问的域名、或用户的 IP 是否是内网地址来判断

没有指定线路时默认按**内网**处理。具体做法和代码示例见开发者文档[多网络线路](https://docs.stmlink.com/zh/rtc/network-line.md)。

> [!TIP]
>
> 现象「内网用户正常、外网用户能进会但没画面」，十有八九是外网用户被当成了内网线路，或者外网线路的媒体地址配错。

***

## 与光闸的关系

内外网之间是**光闸 / 网闸**隔离、不能直接做防火墙映射时，外网线路的地址要指向光闸外侧的穿透网关，
见[光闸跨网接入](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.