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

# Device integration guide

> How to register SIP / H.323 phones, GB28181 surveillance devices, and RTSP streams through a device gateway and bring them into a channel: the six integration types, GB28181 channels, inviting devices, and controlling them in the channel. Read this before integrating hardware devices.

Device integration brings things that don't run our SDK into the channel: the SIP phone in a meeting room, the GB28181 camera on the wall,
an RTSP stream. They join through a **device gateway** acting on their behalf, and appear in the channel as a regular user (with a `uid` prefixed with `_agent_`).

For the parameters and response structure of each endpoint, see [Device integration](/en/rtc/server-api/agent).

## Three steps

```text theme={null}
1. Get a gateway              POST /server/v1/agent/list-gw?type=regsip   → gw
2. Register the device        POST /server/v1/agent/create?type=regsip    → device ID
3. Bring it into the channel  POST /server/v1/agent/invite                → wait for the user_join callback
```

Devices don't connect to RTC directly. Each one is attached to a gateway, which handles signaling and media conversion. So **step 1 can't be skipped**—
a wrong `gw` keeps the device from coming online.

## Six integration types

`type` is a **URL query parameter** (`?type=regsip`), not part of the request body. The request body fields of [Add a device](/en/rtc/server-api/agent#add-a-device) and
[Update a device](/en/rtc/server-api/agent#update-a-device) change with it:

| `type` | Description | Type-specific required fields |
| - | - | - |
| `ipsip` | SIP phone, direct IP | `uri` (`ip:port`) |
| `regsip` | SIP phone, registration mode | `username` (must not contain `:`), `auth_pwd` |
| `iph323` | H.323 endpoint, direct IP | `uri` (`ip:port`) |
| `regh323` | H.323 endpoint, registration mode | `username` (**numeric short number only**), `auth_pwd` |
| `gb28181` | GB28181 surveillance device | `sip_no` (18–20 digits), `auth_pwd`, optional `subjects` |
| `rtsp` | RTSP stream pull | `uri` (must start with `rtsp`), optional `transport_type` (`UDP` default / `TCP`) |

The table lists only the fields **specific** to each type. For the full request body of each value, see
[Add a device](/en/rtc/server-api/agent#add-a-device) (with a section per `type`).
All types require `display_name` (display name) and `gw` (device gateway); `remark` is optional.
For types other than `rtsp`, also note: registration mode requires the device to register with the gateway itself, while with direct IP we connect to the device.
Which one to choose depends on whether we can reach the network the device is on.
To be notified when a registration-mode device comes online or goes offline, subscribe to the `agent_online` / `agent_offline` callbacks; see the [Callback events guide](/en/rtc/server-api/guides/callbacks).

When updating a device, `type` **must match the type the device was registered with**; you can't use it to turn a SIP device into an RTSP one.
To change the integration type, delete the device and register it again.

## GB28181 channels

A GB28181 device (an NVR or a dome camera) may have several camera channels, and each GB28181 channel is a separate video in the SRTC channel.
`subjects` is a map of "channel number → channel name":

```json theme={null}
{"50010700001320000001": "Guest seats", "50010700001320000002": "Audience seats"}
```

There are three ways to maintain them, with the same result:

* Pass them all at once in `subjects` when registering the device
* Add or rename them one by one later with [Set a GB28181 device channel](/en/rtc/server-api/agent#set-a-gb28181-device-channel)
* Don't want to build the numbers yourself → first call [Generate a GB28181 channel number](/en/rtc/server-api/agent#generate-a-gb28181-channel-number) to generate them according to the standard, then register

Likewise, the device's own `sip_no` can be obtained with [Generate a GB28181 device SIP number](/en/rtc/server-api/agent#generate-a-gb28181-device-sip-number).
Both "generate" endpoints **only return a number and don't save anything**; you still have to register it yourself.

For a GB28181 camera to register, the device must be configured with the "upper-level platform" info (SIP number, domain, IP, port)—
get these values from [List device gateway platform info](/en/rtc/server-api/agent#list-device-gateway-platform-info).

## Inviting devices and controlling them in the channel

Get `agents[].type` and `contact` for [Invite devices to the channel](/en/rtc/server-api/agent#invite-devices-to-the-channel) from
[List devices](/en/rtc/server-api/agent#list-devices). Each channel of a GB28181 device is a separate entry, and its `contact` is the channel number.

**Joining is asynchronous**: a successful response only means the invitation was sent. The device is actually online only when the `user_join` callback arrives.
If you subscribe to the `agent_join` callback, you must also return `sid` in it, or the device can't join—see the [Callback events guide](/en/rtc/server-api/guides/callbacks).

Devices can't turn their own microphone and camera on or off; only the server can send these commands:
[Turn device video on or off](/en/rtc/server-api/agent#turn-device-video-on-or-off) / [Turn device audio on or off](/en/rtc/server-api/agent#turn-device-audio-on-or-off).
For `uid`, use the device's user ID in the channel (prefixed with `_agent_`, from the user list or the `user_join` callback).
If you don't pass `uid`, the operation applies to all devices in the channel.

If you subscribe to the `agent_operate` callback, both operations first ask your backend, and a non-zero return rejects them.

## Device type numbers

`list-invite` and `invite` use numeric types, which are a different scheme from the `type` strings:

| Number | Meaning | Corresponding `type` |
| - | - | - |
| 2 | SIP | `ipsip` / `regsip` |
| 3 | H.323 | `iph323` / `regh323` |
| 4 | GB28181 surveillance | `gb28181` |
| 5 | RTSP stream pull | `rtsp` |

The `device_type` of users in the channel is a third numbering scheme (the agent range starting at `80`); see the [Callback events guide](/en/rtc/server-api/guides/callbacks).