> ## 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. # Choosing SRTC or SMeeting > How SRTC (audio and video SDK) and SMeeting (conferencing SDK) are layered, how their terms and capabilities differ, and which one fits your product. Read before you start integrating, if you're not sure which layer to build on. We offer two products, and **SMeeting is built on top of SRTC**. Here is the difference in one line each: * **SRTC** gives you the audio and video transport. Who can speak, who the host is, when a meeting starts—you write these rules yourself. * **SMeeting** (the SDK behind STMLink Meeting) gives you the meeting rules too. Host, raise hand, mute all, waiting room, and recording are all built in. If you're still unsure, start with this question: **do you want to write the rules for "who can do what in a meeting" yourself, or use them as is?** *** ## How to choose | Your situation | Choose | | - | - | | You're building a meeting product and need meeting controls such as host, raise hand, mute all, and waiting room | **SMeeting** | | You want to launch as fast as possible and can accept the meeting UI we provide | **SMeeting** (low-code integration with UI) | | Your interaction isn't a meeting: interactive live streaming with guests, one-to-one customer service calls, AI voice conversations, remote inspection | **SRTC** | | You already have your own business rules and UI and only lack audio and video transport | **SRTC** | | Server-side recording by a bot in the channel, re-streaming, AI agent integration | **SRTC** (C SDK or the platform SDKs) | When in doubt, look at SMeeting first. Meeting control rules look simple, but actually implementing them (state sync across devices, host permissions, state recovery after reconnecting) is the most time-consuming part of a meeting product. If your product is a meeting, writing it all yourself isn't worth it. *** ## How they relate SMeeting isn't a replacement for SRTC; it's a higher-level wrapper around it: ```text theme={null} ┌────────────────────────────────────────────────────────────┐ │ Your business │ ├────────────────────────────────────────────────────────────┤ │ SMeeting Rooms / meetings / members / meeting controls │ ← Meeting semantics ├────────────────────────────────────────────────────────────┤ │ SRTC Channels / users / tracks │ ← Audio and video transport └────────────────────────────────────────────────────────────┘ ``` When you use SMeeting, SRTC still works underneath, just wrapped inside—you don't need to call it directly. *** ## Terminology mapping The terms of the two layers **are not interchangeable**. When reading the docs, keep track of which layer you're in: | | SRTC | SMeeting | | - | - | - | | Space | Channel `channel` | Room `room` / meeting `meeting` | | Entering and leaving | Join / leave | Enter / exit | | Participants | User `uid` | Member | | Media | Track `track` | Managed by the meeting layer | The APIs of the two layers can't be mixed. SMeeting's server API doesn't accept channel names, and SRTC's API doesn't recognize meeting numbers. The sample code in the docs only works in the layer it belongs to. *** ## Capability differences | Capability | SRTC | SMeeting | | - | :-: | :-: | | Audio and video calls, screen sharing | ✅ | ✅ | | Custom signaling (business messages meant for programs) | ✅ | ✅ | | In-meeting text chat (with history, chat can be disabled) | Build it yourself | ✅ | | Out-of-meeting notification channel (calling, reminders) | ✅ (IM channel, out-of-channel messaging) | ✅ | | Cloud recording, MCU stream mixing | ✅ | ✅ | | Host and meeting controls (mute all, remove members, change roles) | Build it yourself | ✅ | | Raise hand, ask to unmute | Build it yourself | ✅ | | Waiting room, sub-meetings, sign-in | Build it yourself | ✅ | | Meeting scheduling and lifecycle management | Build it yourself | ✅ | | Ready-made meeting UI | ❌ | ✅ (low-code integration with UI) | | One user online on multiple devices at once | Plan the uid yourself | ✅ (distinguished automatically by device type) | | Server / embedded integration (recording, AI agents) | ✅ (C SDK) | ❌ | *** ## FAQ **If I use SMeeting, can I still call SRTC directly?** Usually you don't need to. SMeeting already wraps the audio and video capabilities in meeting semantics. A few platforms (such as Swift) keep an entry point to the underlying layer for scenarios we don't cover, but a normal integration doesn't use it. **How costly is it to switch from SRTC to SMeeting later?** Client code basically has to be rewritten—the two layers have different APIs and conceptual models. On the server, if you already treat audio and video as a separate module, the changes are smaller. So **try to make the right choice up front**, rather than thinking "use SRTC for now and switch later". **Can I use both at the same time?** Not recommended within the same business scenario. Separate scenarios are fine—for example, SMeeting for meetings and SRTC for one-to-one customer service calls, each integrated independently. **Is self-hosted deployment any different?** Both support it. SMeeting requires one additional meeting-layer service. *** ## Next steps Once you've chosen, start with that product's overview: * [SRTC overview](/en/rtc/overview)—audio and video SDK * [SMeeting overview](/en/meeting/overview)—conferencing SDK If you're still unsure, contact us directly and describe your business scenario.