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

# Internal network and public internet

> Deploying one self-hosted platform for internal and public-internet users: what network lines are, the entry and media addresses each line needs, pitfalls when a data center's inbound and outbound IPs differ, and how your business system puts users on the right line.

A common situation for government and enterprise customers: the platform is deployed in an internal data center, and internal staff access it directly; colleagues on business trips or working from home access it from the public internet,
through a public address mapped out by the firewall. In the same platform and the same meeting, users on the internal network and the public internet must be able to talk to each other.

We solve this with **network lines**: the platform configures a separate set of "addresses clients should connect to" for each line.
When users enter a meeting they state which line they're on, and the platform gives them the matching addresses.

***

## What a network line is

```mermaid theme={null}
flowchart LR
    subgraph IN["Internal network"]
        U1["Internal-network user"]
    end
    subgraph OUT["Public internet"]
        U2["Public-internet user"]
    end
    FW["Firewall / NAT<br/>public IP 203.0.113.10"]
    P["Platform server<br/>192.168.10.8"]

    U1 -- "Line: internal network<br/>connects to 192.168.10.8" --> P
    U2 -- "Line: public internet<br/>connects to 203.0.113.10" --> FW
    FW --> P
```

Each line has two kinds of address:

| Address | Role | Ports |
| - | - | - |
| Entry address | APIs, signaling, web access | 443/TCP, 18883/TCP |
| Media address | Audio and video | 39001/UDP |

Usually there are two lines: **internal network** and **public internet**. You can configure more as needed (for example, a private network or another campus).

***

## What to prepare at deployment

1. **Addresses for each line**: the internal-network line uses the server's internal address; the public-internet line uses the public IP or domain mapped out by the firewall
2. **Firewall mapping**: map the public-internet line's 443/TCP, 18883/TCP, and 39001/UDP to the platform server, **keeping the same port numbers**
3. **Domain and certificate**: the internal network and the public internet usually use different access addresses, and the certificate must cover the domain users actually access
4. **Choose the network mode in the installer**: internal network only, public internet only, or both. After installation, you can view and change each line's entry address under **System configuration → Network** in the admin console

> [!WARNING]
>
> **Watch out for data centers whose inbound and outbound IPs differ**: in many data centers, the public IP users come in through isn't the IP the server uses to go out.
> In that case you must explicitly set the public-internet line's media address to **the public IP users come in through**; otherwise public-internet users can enter meetings but get no video or audio.

***

## Putting users on the right line

The platform decides which set of addresses to give a user based on the "line" the user brings when entering the meeting. Your business system can do this in two ways:

* **Let users choose**: the client lists "Internal network / Public internet" and users pick one
* **Decide on the server automatically**: based on the domain the user accessed, or whether the user's IP is an internal address

If no line is specified, the default is **internal**. For details and code examples, see the developer docs on [network lines](https://docs.stmlink.com/en/rtc/network-line.md).

> [!TIP]
>
> If "internal-network users are fine, but users on the public internet can enter meetings with no video", nine times out of ten the public-internet users are being treated as the internal-network line, or the public-internet line's media address is wrong.

***

## Relation to cross-domain solutions

When internal and public networks are isolated by a **cross-domain solution (CDS)** and firewall mapping isn't possible, the public-internet line's addresses must point to the tunnel gateway on the outer side of the CDS;
see [Access across a cross-domain solution](https://docs.stmlink.com/en/product/deploy/optical-gap.md).


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