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

# Multi-channel

> Join multiple channels at once with the SRTC Swift SDK: joining and leaving each Channel, how engine-level tracks are reused across channels, when capture is released, the hard constraint on publishing audio to multiple channels, and per-channel events.

One `SRTCEngine` can join multiple channels at the same time. Typical scenarios are use cases like "main session + group discussions" that need to listen to
two streams at once, or publishing one camera to two channels at the same time.

### Join and leave

`joinChannel` can be called multiple times, and each call returns an independent `Channel`:

```swift theme={null}
let main = try await srtc.joinChannel(token: mainToken)
let group = try await srtc.joinChannel(token: groupToken)

srtc.channels          // [main, group], ordered by join time
srtc.defaultChannel    // main (the earliest-joined one that's still live)
```

Joining the same channel name twice throws `SRTCError.alreadyJoined`—this also applies while a join is in progress, so you never get two
`Channel` objects pointing to the same channel.

We recommend specifying explicitly which channel to leave:

```swift theme={null}
await group.leave()            // Or srtc.leaveChannel(group)
await srtc.leaveChannel()      // The no-argument version applies to defaultChannel
```

The no-argument version of `leaveChannel()` applies only to the default channel; after you leave the default channel, the next one takes its place. Single-channel users
never notice this rule, but with multiple channels we recommend not relying on it and naming the channel to leave directly.

Publishing, subscribing, the user list, event callbacks, and leaving all happen on each `Channel` independently, without interfering with each other.

***

### Tracks are engine-level objects and can be published to multiple channels

Tracks created with `createLocalXxxTrack` belong to the engine rather than to a particular channel, so the same track can be published to multiple channels:

```swift theme={null}
let camera = srtc.createLocalCameraTrack(preset: .h720p)
try await camera.startCapture()

try await main.publishLocalTrack(camera)
try await group.publishLocalTrack(camera)   // One capture, sent separately by each channel
```

This captures only once and encodes separately per channel, without opening the camera twice.

**Capture release follows "the last releaser is responsible"**: when you unpublish or leave one of the channels, as long as the track is still
published by another live channel, the SDK doesn't stop capture; only when the last holder releases it does it actually
`stopCapture()`. So in the code below, `main`'s video isn't interrupted after leaving `group`:

```swift theme={null}
await group.leave()      // camera is still published by main → capture continues
await main.leave()        // Last holder → capture stops automatically
```

Screen sharing works the same way. iOS full-screen capture (Broadcast Extension) is itself exclusive at the process level: one screen track corresponds to
one broadcast, and publishing it to multiple channels still uses only one capture.

***

### Hard constraint on publishing audio to multiple channels

<Warning>
  When multiple channels **publish** audio at the same time, the set of audio sources published in each channel must be **exactly the same**; otherwise
  `publishLocalTrack` throws `SRTCError.invalidState`.
</Warning>

The reason lies in the audio pipeline: the whole process has only one audio device module and one mix, so the audio tracks of all channels get **the same
mixed result**. If channel A publishes only the microphone while channel B publishes the microphone + screen audio, then this global mix contains
the screen audio, and A's subscribers also hear what B is sharing—something A has no way to anticipate from the API semantics. This is cross-channel
audio leakage, so the SDK blocks it at the publishing entry point.

Identical sets give predictable behavior: both channels send the same content. So the most common usage is allowed:

```swift theme={null}
let mic = srtc.createLocalMicTrack()
try await mic.startCapture()

try await main.publishLocalTrack(mic)
try await group.publishLocalTrack(mic)     // ✅ The audio source set of both channels is {mic}
```

But the following is rejected:

```swift theme={null}
try await main.publishLocalTrack(mic)                    // {mic}
try await group.publishLocalTrack(mic)                   // {mic}
try await group.publishLocalTrack(screenTrack)           // ❌ group becomes {mic, screen_audio}
// SRTCError.invalidState: the audio sources published in each channel must be exactly the same
```

Either have both channels publish the same audio sources, or unpublish audio in the other channel first.

**The subscribing side has no restrictions**: any channel can subscribe to remote audio normally. Downlink audio is mixed by WebRTC itself and is unrelated to the constraint above.

***

### Events

Each `Channel` has its own delegate list; delegates registered on a channel receive only that channel's events:

```swift theme={null}
main.delegates.add(delegate: mainHandler)
group.delegates.add(delegate: groupHandler)
```

Track-level events (`TrackDelegate`) are registered on the track, so a track shared across channels only needs to be registered once.

***

### FAQ

#### Does multi-channel open the camera / microphone multiple times?

No. Capture is engine-level; multiple channels share the same capture, and the hardware is opened only once.

#### After leaving one channel, the other channel's video goes black?

Normally this doesn't happen—capture release is handled by "the last releaser". If it does happen, check whether you created a separate track for each of the two channels
(which means two captures, unrelated to each other) instead of reusing the same one.

#### Can two channels send different audio?

Not currently, for the reason explained in the mixing constraint above. If your scenario needs this capability, contact us; it depends on support for a direct publishing path.