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

# Error codes

> The Python SDK's SdkError: the three kinds of code values (the SDK's own 180xxx, server 1xxx passed through unchanged, and -1 internal errors), causes and troubleshooting for common errors, and how to handle join failures.

When an API fails it raises `srtc.SdkError`, which has two fields:

| Field | Type | Description |
| - | - | - |
| `code` | `int` | Error code |
| `msg` | `str` | Error reason |

```python theme={null}
try:
    ch = await srtc.Channel.join(token)
except srtc.SdkError as e:
    print(e.code, e.msg)
```

`code` falls into three kinds:

| Value | Source | Description |
| - | - | - |
| `180xxx` | The SDK itself | The same set as [C SDK · Error codes](/zh/rtc/capi/error-codes#日志里的-180xxx：sdk-层错误) (Chinese); server-side integrations share the `180` prefix |
| `≥1000` (such as `1033`) | Server | The business-level reason for rejection, passed through unchanged by the SDK. For the full list, see [Server API · Error codes](/en/rtc/server-api/error-codes) |
| `-1` | SDK internal | Failures with no specific error code (such as a malformed token or no network connectivity); check `msg` |

***

## Common errors

| Code | Meaning | Common causes and fixes |
| - | - | - |
| `180001` | Not in a channel | An in-channel API was called after the channel disconnected (`ch.closed` is `True`) |
| `180002` | Token expired | The token wasn't used before it timed out. **Issue a new one for every `join`** |
| `180003` | Track doesn't exist | The subscribed uid / track\_id is wrong, or the other side has unpublished |
| `180300` / `180301` | Publish / subscribe failed | Media negotiation failed; check the network |
| `180302` / `180303` | Publish / subscribe negotiation timed out | The server's media ports are unreachable; check the firewall |
| `1021` | Token already used | The same token was used twice |
| `1032` | Session is not online | A token from a session that already left the channel was reused |
| `1033` | Concurrency limit reached | The app's concurrency license quota is used up; expand the license or wait for other sessions to end |
| `1034` / `1035` | No available node / node fully loaded | The server's media nodes are busy. The SDK backs off and retries automatically when **reconnecting**; if the **initial join** fails, you need to retry later |

<Tip>
  When a join fails, handle it by error code: `1021` / `1032` / `180002` are token problems—**issue a new token** before retrying; `1034` / `1035` are temporary—retry later with a new token; `1033` is a license quota problem, and retrying doesn't help.
</Tip>

***

## Logging

The SDK uses Python's standard `logging`, with the logger name `srtc`:

```python theme={null}
import logging

logging.basicConfig(level=logging.INFO)
logging.getLogger("srtc").setLevel(logging.DEBUG)     # Turn on when troubleshooting
```

Logs from the native core (signaling, media connections) go directly to the process's stdout / stderr, not through `logging`.