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

# Network and port requirements

> Ports a self-hosted deployment opens: client ports 443/TCP, 18883/TCP, 39001/UDP; device gateway SIP / H.323 / GB28181 ports and RTP range; multi-node and MCU live ports; ports never to expose; firewall commands. Use it for firewall change requests to network and security teams.

**The short version**: a standard deployment only needs to open three ports to clients—**443/TCP, 18883/TCP, and 39001/UDP**;
add the device gateway set if you connect hardware devices; no other port is exposed externally.

All ports below are defaults. They can be changed at deployment, so go by the actual on-site configuration.

***

## Quick reference

```text theme={null}
Clients (required):       443/TCP   18883/TCP   39001/UDP
Add for devices:          1720, 1740-1759/TCP   1719/UDP   5060, 5070/TCP+UDP   58000-59000/UDP
Add for media nodes:      39002/UDP (between nodes only)
All other ports:          never exposed externally
```

***

## Client access (required)

Open to: the networks of all users of the apps, desktop clients, web, and Mini Programs.

| Port | Protocol | Purpose |
| - | - | - |
| **443** | TCP | HTTPS unified entry point: APIs, admin console, web client, recording downloads, web signaling (WSS) |
| **18883** | TCP | Signaling for native clients (Android, iOS, Windows, Mac, and others) (MQTT over TLS) |
| **39001** | **UDP** | Audio and video media. All users share this one port |

> [!WARNING]
>
> **39001/UDP must be open.** Audio and video use UDP only, with no TCP fallback. The typical symptom when this port is blocked:
> **users can log in and enter meetings, but see no video and hear no audio**.

* The web client uses only 443 and 39001/UDP; native clients need all three
* Clients connect only to these three ports. If you change 443 or 18883, also update the access addresses under **System configuration → Network** in the admin console
* 80/TCP doesn't need to be open externally

***

## Device gateway

Needed only when connecting [hardware devices](https://docs.stmlink.com/en/product/device-access/overview.md). Open to **the subnets where the devices are**, not the internet.

| Port | Protocol | Purpose |
| - | - | - |
| 5060 | TCP + UDP | SIP signaling (endpoint registration, calls) |
| 1720 | TCP | H.323 call signaling |
| 1719 | UDP | H.323 gatekeeper (endpoint registration) |
| 1740-1759 | TCP | H.323 media control, one per call |
| 5070 | TCP + UDP | GB28181 signaling |
| 58000-59000 | UDP | Device audio and video (RTP), 2–4 ports per call; **the whole range must be open** |

**When there's NAT between devices and the device gateway**:

* At deployment, set the "device access gateway IP" to the address the devices see (the post-NAT address)
* Port mappings on the NAT must **keep the same port numbers**, especially for the RTP port range; otherwise calls connect but have no audio or video

With RTSP, the direction is reversed: the device gateway connects to the camera, so open gateway → camera 554/TCP (and the camera's RTP ports).

***

## Between servers

In a single-server deployment, services talk over loopback, so **nothing extra needs to be opened**. In split-server or multi-node deployments, open the following on the **internal network between servers**:

| Scenario | Port | Description |
| - | - | - |
| Multiple media nodes | 39002/UDP | Cascaded forwarding between media nodes; open in both directions between nodes. See [Multiple nodes and nearest access](https://docs.stmlink.com/en/product/deploy/multi-node.md) |
| Extension services on separate servers | 8701/TCP | The MCU, device gateway, and others call platform APIs |
| Extension services on separate servers | 11883/TCP, 39001/UDP | The MCU, device gateway, and others enter meetings as members and must reach the signaling and media ports |
| Extension services on separate servers | 8721/TCP (MCU), 8722/TCP (device gateway) | The platform sends recording and call commands |

***

## MCU live streaming (optional, off by default)

Needed only when using the MCU's built-in live streaming:

| Port | Protocol | Purpose |
| - | - | - |
| 1935 | TCP | RTMP |
| 7001 | TCP | HTTP-FLV playback |
| 7002 | TCP | HLS playback |

These ports have no encryption or authentication. For public audiences, we recommend reverse proxying them through 443 instead of exposing them directly.

***

## Never expose externally

The following ports are used only on the server itself or the internal network. **Don't open them to the internet**:

| Port | Description |
| - | - |
| 8799 | Installer; close it after installation |
| 18083 | MQTT management console |
| 8700 / 8701 / 8702 / 8720 / 8721 / 8722 / 8729 / 8730 | Internal service APIs, exposed only through 443 |
| 1883 / 8083 / 11883 | MQTT internal ports |
| 5432 / 6379 / 9000 / 8123 | Database, Redis, log database |
| 8797 / 8798 | Monitoring center |
| 22 | SSH; we recommend restricting source IPs |

***

## Outbound connections from servers

On internal-only networks, the following features need **outbound** access from the server:

| Feature | Destination |
| - | - |
| Event callbacks | The callback URL of the customer's business system (443 / 80) |
| Storing recordings in object storage | OSS / S3 endpoint (443) |
| Speech recognition | Recognition engine service (default 10096) |
| MCU re-streaming / stream pulling | CDN (1935 / 443), cameras (554) |

***

## Firewall configuration examples

**Minimal set** (firewalld):

```bash theme={null}
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=18883/tcp
firewall-cmd --permanent --add-port=39001/udp
firewall-cmd --reload
```

**Adding the device gateway**:

```bash theme={null}
firewall-cmd --permanent --add-port=5060/tcp --add-port=5060/udp
firewall-cmd --permanent --add-port=5070/tcp --add-port=5070/udp
firewall-cmd --permanent --add-port=1720/tcp
firewall-cmd --permanent --add-port=1740-1759/tcp
firewall-cmd --permanent --add-port=1719/udp
firewall-cmd --permanent --add-port=58000-59000/udp
firewall-cmd --reload
```

**Between media nodes** (open only to the peer node's IP):

```bash theme={null}
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=<peer-node-IP> port port=39002 protocol=udp accept'
firewall-cmd --reload
```

With ufw, the equivalents are `ufw allow 443/tcp`, `ufw allow 39001/udp`, and so on.

***

## Verifying after installation

| Check | How |
| - | - |
| Ports are listening | Run `ss -tulnp` on the server and confirm 443, 18883, 39001, and others are listed |
| Clients can connect | The web client opens and you can log in → 443 is open |
| Media works | Two people in the same meeting can see each other → 39001/UDP is open |


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