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

# Access across a cross-domain solution

> How public-internet users enter meetings when the platform sits behind a cross-domain solution (CDS): the RTSP tunnel, architecture, what the gateway must allow, only 3 channels needed, prerequisites, and limits. For strongly isolated government networks.

Public security bureaus, procuratorates, courts, government agencies, and similar organizations separate their internal network from the public internet with a **cross-domain solution (CDS)**, which controls what may pass between security domains. The CDS only allows specific business protocols
and doesn't let ordinary TCP / UDP pass through directly, so the audio and video platform's APIs, signaling, and media streams can't get across.

On site, the CDS usually already has an **RTSP video service** channel open. Our solution takes advantage of this: a **tunnel gateway** sits on each side of the CDS
and wraps the platform's traffic in standard RTSP sessions to cross it, restoring it on the other side. Users on the public internet and on the internal network can then talk to each other in the same meeting.

***

## Deployment architecture

```mermaid theme={null}
flowchart LR
    subgraph EXT["Public internet"]
        U1["Public-internet users<br/>browser / App / PC"]
    end

    subgraph DMZ["Public-internet side of the CDS"]
        OG["Outer gateway<br/>443/TCP · 18883/TCP · 39001/UDP"]
    end

    GAP{{"CDS<br/>allows RTSP only"}}

    subgraph IN["Internal network"]
        IG["Inner gateway"]
        PF["Audio and video platform"]
        I1["Internal-network users"]
    end

    U1 --> OG
    OG == "RTSP tunnel" ==> GAP
    GAP ==> IG
    IG --> PF
    I1 -- "Direct" --> PF
```

| Component | Location | Role |
| - | - | - |
| Outer gateway | Public-internet side of the CDS | Provides access ports for public-internet users and wraps traffic in RTSP sessions sent into the CDS |
| Inner gateway | Internal side of the CDS | Restores the RTSP sessions coming through the CDS into the original traffic and hands it to the platform |
| Audio and video platform | Internal network | Deployed normally; internal-network users access it directly |

***

## How it works

* **APIs and signaling (TCP)**: for each connection a public-internet user opens, the outer gateway opens an RTSP session carried over RTSP over TCP, for reliable, ordered delivery
* **Audio and video (UDP)**: when the outer gateway receives a user's first media packet, it opens an RTSP session carried over RTP over UDP, for real-time delivery
* Once a session is established, traffic flows both ways, and the platform's responses return the same way

```mermaid theme={null}
sequenceDiagram
    participant C as Public-internet user
    participant O as Outer gateway
    participant G as CDS
    participant I as Inner gateway
    participant P as Platform

    C->>O: Open connection / send media packet
    O->>G: RTSP handshake
    G->>I: Forward RTSP handshake
    I->>P: Connect to the matching platform port
    C->>O: Original data
    O->>G: Wrapped as RTP
    G->>I: RTP
    I->>P: Restored to original data
    P-->>C: Responses return the same way
```

***

## Highlights

| Highlight | Description |
| - | - |
| Complies with CDS controls | Only standard RTSP / RTP crosses the CDS, so it only needs to allow the RTSP service—no general forwarding |
| End-to-end encryption | The gateways don't decrypt data; HTTPS, encrypted signaling, and encrypted media pass through as is, and certificates stay only on the internal platform |
| Transparent to the business | Neither the platform nor the clients need changes for the CDS; web, Android, iOS, and PC can all connect |
| Few channels | All users share one media port, so public-internet access needs only **3 channels** (one each for APIs, signaling, and media), regardless of user count |
| No extra relay | No separate TURN relay or media conversion service is needed |
| Internal-network and public-internet users in one meeting | Users on the public internet and on the internal network exchange audio and video in the same meeting |
| Session isolation | Each public-internet connection has its own RTSP session, reclaimed automatically when idle, with concurrency limits per port |

***

## Prerequisites

| Item | Requirement |
| - | - |
| Servers | One on each side of the CDS, running the outer gateway and the inner gateway respectively |
| Public address | The outer gateway needs an IP or domain reachable by public-internet users |
| CDS policy | Allow the RTSP control ports (for example, 3 TCP ports) and the RTP media port range (UDP, one pair per public-internet media connection, sized by concurrent public-internet users) between the two gateways. Specific ports are agreed with the CDS vendor during implementation |
| Public-internet-side ports | The outer gateway opens 443/TCP, 18883/TCP, and 39001/UDP externally, matching the platform ports |
| Internal-side connectivity | The inner gateway can reach the platform's 443/TCP, 18883/TCP, and 39001/UDP |
| Platform configuration | Deploy the platform with [internal-network and public-internet lines](https://docs.stmlink.com/en/product/deploy/networks.md), with **the public-internet line's addresses pointing to the outer gateway** |
| License | The tunnel gateways need a separate license |
| Capacity | Size the gateways' concurrent sessions and the CDS's throughput by the number of concurrent public-internet members |

***

## Usage notes

> [!WARNING]
>
> **Users on the public internet must explicitly use the "public internet" line.** After passing through the gateways, the platform sees the gateway as the source address instead of the user,
> so it can't tell the internal network from the public internet by IP. Your business system must keep users coming through the public-internet entry on the public-internet line (for example, by access domain); otherwise they enter meetings with no video.

* **Content auditing**: data passes through encrypted end to end, and the CDS sees only the RTSP / RTP wrapping, not the business content. If the customer requires the CDS to audit content, discuss it in advance
* **Source IP**: in platform logs, public-internet users' source addresses appear as the gateway address
* **Capacity planning**: each public-internet user takes about 2 media sessions and 3–4 API connections; we recommend a load test before large-scale rollout
* **Implementation**: CDS traversal is implemented per project and requires us, the customer, and the CDS vendor to agree on ports and policies; contact us


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