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

# Changelog

> Release history of the C SDK (librtc), including the 0.0.9 removal of rtc_user_info_t.link_id that requires recompiling and the 0.0.11 rtc_destroy callback fixes. Read this page before upgrading the C SDK.

### \[0.0.11] - 2026.09.26

#### Fixed

* **Callbacks could still be running after `rtc_destroy` returned**: previously `rtc_destroy` only cleared the callbacks without waiting for callbacks already in progress, so freeing `context` after it could crash the caller. `rtc_destroy` now waits for all in-flight callbacks to return before it returns, after which `context` can be freed safely
* **Keyframe callbacks still fired after a local track was destroyed**: `rtc_destroy_local_track` now removes the keyframe callback and waits for in-flight callbacks to return
* **Calling `rtc_destroy` in the disconnect callback deadlocked**: you can now destroy the instance from any of its callbacks
* When an instance is destroyed before an asynchronous join (`rtc_join_channel`) completes, it no longer stays in the channel indefinitely without leaving

<Note>
  The functions and struct layouts are identical to 0.0.10, so you can replace the library files directly. Code that waited a fixed time (sleep) after destroying to work around the issues above can be removed after upgrading.
</Note>

### \[0.0.10] - 2026.09.26

#### Changed

* Debug symbols are stripped from the library files, reducing the size of the Linux `librtc.so` by about 27% (17.6 MB → 12.8 MB). Functions and behavior are unchanged, and crash stack traces still print function names and line numbers

<Note>
  The interface is identical to 0.0.9; programs compiled against the 0.0.9 header can replace the library files directly.
</Note>

### \[0.0.9] - 2026.09.26

#### Added

* `rtc_get_last_error`: get the specific error code and reason after a function returns `RTC_ERROR` / `RTC_TIMEOUT`, without digging through the logs
* `rtc_set_disconnected_callback`: reports the disconnect reason (removed from the channel / replaced by another session with the same uid / heartbeat timeout / channel destroyed) when the connection finally ends, with the `RTC_DISCONNECT_*` macros
* `rtc_get_local_user_info`: get the local uid / sid
* `rtc_get_channel_info` / `rtc_free_channel_info` and the `rtc_channel_info_t` struct
* Added the macOS Apple Silicon platform (`librtc.dylib`)

#### Fixed

* **Joining a channel is about 3 seconds faster**: previously every join waited idly for about 3 seconds before starting to establish the signaling connection; it now connects immediately (measured join time 3.4 s → 0.4 s). The reconnect interval after a disconnect is unchanged
* Fixed an issue where the runtime treated the instance handle as an invalid pointer at certain moments and terminated the process
* When the channel's media streaming engine configuration is unknown, the SDK falls back to the default engine instead of failing to join

#### Breaking changes

* **Removed the `rtc_user_info_t.link_id` field** (it was always 0 and had no actual meaning)

<Warning>
  The memory layout of `rtc_user_info_t` changes as a result. **Upgrading from 0.0.8 or earlier requires recompiling with the new `librtc.h`**; replacing only the library files reads `stream_tracks` and other fields incorrectly, or even crashes. Just delete any code that references `link_id`.
</Warning>

<Note>
  The callback `context` must be a real pointer (or `NULL`). Don't cast small integers to pointers to use as IDs; see [Instance and channel · Callback registration](/en/rtc/capi/api-reference/engine#callback-registration).
</Note>