@tencent-rtc/mcp 1.6.8 → 1.7.1

package/resource/knowledge/livekit/best-practice/ios/voice-room-anchor-start.md

@@ -0,0 +1,126 @@
+---
+title: "Voice Room Anchor Creates Room and Starts Streaming (iOS)（语聊房 / 房主 / 开播 / createLive）"
+product: live
+frameworks: [ios]
+scope: platform_specific
+tags: [voice room, anchor, start streaming, publish audio, createLive, openLocalMicrophone, muteMicrophone, unmuteMicrophone, LiveListStore, AudioSalon, keepOwnerOnSeat, seatMode, iOS, Swift, AtomicXCore]
+version_range: ">=2.0.0"
+---
+
+# Voice Room Anchor Creates Room and Starts Streaming (iOS)
+
+## 1. Key Takeaways
+
+- Voice room streaming flow: construct `LiveInfo` (with `liveID`, `seatTemplate`, `keepOwnerOnSeat`, `seatMode`), call `createLive` to create the room; on success, call `openLocalMicrophone` to capture and publish audio so other users in the room can hear the anchor.
+- `liveID` is required; setting `keepOwnerOnSeat` to `true` makes the anchor automatically take a seat upon entering (taking a seat is a prerequisite for publishing audio — only seated users can publish audio streams in the room).
+- `seatTemplate` should be set to `SeatLayoutTemplate.AudioSalon(seatCount: n)`, where n is the maximum seat count supported by the plan or a value less than it.
+- `seatMode` sets the seat-taking mode (e.g., `.apply` for apply-to-take-seat).
+- `muteMicrophone` pauses publishing local audio; `unmuteMicrophone` resumes publishing local audio.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `LiveInfo` | Room information | Contains `liveID`, `liveName`, `seatTemplate`, `keepOwnerOnSeat`, `seatMode`, etc. |
+| `liveID` | Room ID | Required parameter for `createLive` |
+| `liveName` | Room name | Display name of the room |
+| `seatTemplate` | Seat layout template | Use `SeatLayoutTemplate.AudioSalon(seatCount: n)` for voice rooms, where n ≤ max seats in plan |
+| `keepOwnerOnSeat` | Auto-seat the owner | Set to `true` so the anchor automatically takes a seat upon entering |
+| `seatMode` | Seat-taking mode | e.g., `.apply` for apply-to-take-seat |
+| `createLive(liveInfo)` | Create room (start streaming) | Pass `LiveInfo`, returns `Result` for async handling |
+| `openLocalMicrophone` | Capture and publish audio | Opens local microphone and publishes audio stream to the room |
+| `muteMicrophone` | Pause audio publishing | Pauses local audio stream while microphone remains open |
+| `unmuteMicrophone` | Resume audio publishing | Resumes local audio stream while microphone remains open |
+
+## 3. Mechanism & Sequence
+
+Construct `LiveInfo` (`liveID` required, `seatTemplate=AudioSalon(n)`, `keepOwnerOnSeat=true`, `seatMode` as needed) -> call `createLive` to create the room -> `case .success` callback fires, anchor is auto-seated -> call `openLocalMicrophone` to capture and publish audio -> other users in the room hear the anchor.
+
+Taking a seat is a prerequisite for streaming: `keepOwnerOnSeat=true` ensures the anchor takes a seat before publishing audio. `muteMicrophone` / `unmuteMicrophone` are used to pause/resume during streaming.
+
+## 4. Standard Usage
+
+1. Construct `LiveInfo`: set `liveID`, `seatTemplate`, `keepOwnerOnSeat`, `seatMode`.
+2. Call `createLive(liveInfo)` and handle success/failure in `switch result`.
+3. In `case .success`, call `openLocalMicrophone` to capture and publish audio.
+4. Call `muteMicrophone` / `unmuteMicrophone` to pause/resume streaming as needed.
+
+```swift
+import UIKit
+import AtomicXCore
+
+class YourAnchorViewController: UIViewController {
+    // ... 其他代码 ...
+    private let liveID = "test_voice_room_001"
+
+    override func viewDidLoad() {
+        super.viewDidLoad()
+        // ... 其他代码 ...
+
+        // 开始语聊
+        startLive()
+    }
+
+    private func startLive() {
+        // 1. 准备 LiveInfo 对象
+        var liveInfo = LiveInfo()
+
+        // 2. 设置房间 id
+        liveInfo.liveID = liveID
+        // 3. 设置房间名称
+        liveInfo.liveName = "test 语聊房"
+        // 4. 设置语聊房布局模板（传入 9 即代表有 9 个麦位）
+        liveInfo.seatTemplate = SeatLayoutTemplate.AudioSalon(seatCount: 9)
+
+        // 5. 设置主播开播后自动上麦
+        liveInfo.keepOwnerOnSeat = true
+
+        // 6. 设置上麦模式，例如申请上麦
+        liveInfo.seatMode = .apply
+
+        // 7. 调用 createLive 开始直播
+        liveListStore.createLive(liveInfo) { [weak self] result in
+            guard let self = self else { return }
+            switch result {
+            case .success(let liveInfo):
+                print("Response startLive onSuccess")
+                // 8. 房主创建成功后默认自动上麦，此时调用 openLocalMicrophone 采集并发布音频
+                liveSeatStore.openLocalMicrophone(completion: nil)
+            case .failure(let errorInfo):
+                print("Response startLive onError: \(errorInfo.message)")
+            }
+        }
+    }
+}
+```
+
+## 5. Expected Results
+
+- `case .success` callback fires: room created successfully, anchor is auto-seated.
+- After `openLocalMicrophone`: other users in the room can hear the anchor.
+- After `muteMicrophone`: local audio publishing is paused; after `unmuteMicrophone`: publishing resumes.
+- If `keepOwnerOnSeat` is not set to `true`: the anchor is not auto-seated and cannot publish audio.
+- `case .failure(let errorInfo)` callback fires: streaming failed, `errorInfo.message` contains the error description.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Calling `openLocalMicrophone` without calling `createLive` first (cannot publish audio without creating a room).
+- Pitfall 2: Not setting `keepOwnerOnSeat` to `true`, so the anchor is not seated and audio publishing does not work.
+- Pitfall 3: Not setting `seatTemplate` or setting `seatCount` beyond the plan's maximum seat count.
+- Pitfall 4: Confusing `muteMicrophone` (pauses audio stream publishing) with closing the microphone (stops audio capture).
+- Pitfall 5: Reusing `liveID` (it must be globally unique; otherwise creation fails).
+- Pitfall 6: Forgetting `[weak self]` (to avoid retain cycles causing memory leaks); both `success` and `failure` branches of `switch result` must be handled.
+
+## 7. Problem Definition (retrieval hint)
+
+An iOS voice room anchor needs to create a room and start audio streaming in the correct order, understanding the call timing and parameter meanings of `createLive`, `openLocalMicrophone`, `muteMicrophone`, and `unmuteMicrophone`.
+
+## 8. Alternative Queries (retrieval recall)
+
+- How does an iOS voice room anchor start streaming?
+- What is the call order of `createLive` and `openLocalMicrophone` on iOS?
+- How does an iOS anchor take a seat and publish audio?
+- What does the `keepOwnerOnSeat` parameter do?
+- How to set the `AudioSalon` template for `seatTemplate`?
+- What is the difference between `muteMicrophone` and `unmuteMicrophone` on iOS?
+- How to publish audio after creating a voice room?

package/resource/knowledge/roomkit/best-practice/common/room-ghost-member.md

@@ -0,0 +1,70 @@
+---
+title: "Why Abnormally Exited Members Still Appear in TUIRoomKit Member List and How to Clean Up（TUIRoomKit / 异常退出 / 幽灵成员 / 心跳检测 / 离线检测）"
+product: room
+frameworks: [react, vue, web, android, ios, flutter]
+scope: platform_common
+tags: [TUIRoomKit, abnormal exit, ghost member, heartbeat detection, offline detection, kick from room, kick_user_out, disconnect callback, member list, room cleanup]
+version_range: ">=2.0.0"
+---
+
+# Why Abnormally Exited Members Still Appear in TUIRoomKit Member List and How to Clean Up
+
+## 1. Key Takeaways
+
+- When a user exits abnormally (process killed, network disconnected, page closed without calling leave), the member still appears in the remote member list. This is the expected behavior of the **video conferencing SDK backend heartbeat offline detection**.
+- Current rule: the backend removes an abnormally exited user from the room approximately **5–6 minutes** after heartbeat loss. Only then do remote participants receive the leave notification and update the member list.
+- **The heartbeat interval cannot be set very short by default**: short heartbeat intervals increase the risk of false kicks during network jitter, disrupting normal meeting experience.
+- If your business requires faster ghost member cleanup: Option 1 (submit a ticket to shorten heartbeat to ~2 minutes) or Option 2 (use IM disconnect callback + `kick_user_out` to kick immediately).
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| Heartbeat offline detection | Detects user online status | Backend checks whether user heartbeat is lost |
+| Heartbeat loss | Signal of abnormal exit | Heartbeat stops when process is killed / network disconnected / page closed without leave |
+| Ghost member | Abnormally exited user still displayed | Removed from room after ~5–6 minutes |
+| `kick_user_out` | Kick a room member | Business backend calls this to immediately clean up |
+| `disconnect` callback | Disconnection callback | IM server detects user offline |
+| Heartbeat interval adjustment | Backend configuration | Can be shortened to ~2 minutes via support ticket |
+
+## 3. Mechanism & Sequence
+
+User exits abnormally (process killed, network disconnected, page closed without leave) -> Backend detects heartbeat loss -> After ~5–6 minutes, removes user from room -> Remote participants receive leave notification and update member list.
+
+The default heartbeat interval cannot be too short to avoid false kicks caused by network jitter. If the business requires faster cleanup:
+
+- **Option 1**: Submit a support ticket to shorten the backend heartbeat detection interval to ~2 minutes.
+- **Option 2**: Business backend listens for the IM `disconnect` callback to detect offline status, then calls `kick_user_out` to immediately remove the ghost member.
+
+## 4. Standard Usage
+
+1. **Option 1 (adjust heartbeat interval)**: Submit a support ticket to have the backend heartbeat detection interval shortened to ~2 minutes.
+2. **Option 2 (server-side proactive cleanup)**:
+   - Business backend listens for the IM server `disconnect` (disconnection) callback.
+   - Upon receiving the offline signal, calls `kick_user_out` to kick the room member.
+
+## 5. Expected Results
+
+- Abnormally exited users are removed from the room after ~5–6 minutes, and remote member list updates accordingly.
+- After adjusting heartbeat to ~2 minutes via support ticket, cleanup is faster.
+- Option 2 using `disconnect` callback + `kick_user_out` immediately removes ghost members.
+- Setting heartbeat too short increases the risk of false kicks during network jitter.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Expecting abnormally exited users to disappear from the member list immediately (heartbeat detection takes ~5–6 minutes).
+- Pitfall 2: Assuming the heartbeat interval can be set arbitrarily short (network jitter causes false kicks, disrupting normal meetings).
+- Pitfall 3: Overlooking that the business side can proactively kick members (`disconnect` callback + `kick_user_out`).
+
+## 7. Problem Definition (retrieval hint)
+
+Why an abnormally exited user still appears in the remote member list in TUIRoomKit, and how to clean up ghost members faster.
+
+## 8. Alternative Queries (retrieval recall)
+
+- What to do when an abnormally exited user still shows in the member list?
+- How to clean up ghost members in TUIRoomKit?
+- How long until a disconnected user is removed from the room?
+- Can the heartbeat detection interval be shortened?
+- Abnormally exited user keeps showing in the list?
+- How to kick an offline user?

package/resource/knowledge/roomkit/best-practice/common/room-limit-and-multi.md

@@ -0,0 +1,83 @@
+---
+title: "TUIRoomKit Concurrent Room Limits and Multi-Room Support（TUIRoomKit / 并发房间 / 房间上限 / 同时进多个房间 / 单房间人数）"
+product: room
+frameworks: [react, vue, web, android, ios, flutter]
+scope: platform_common
+tags: [TUIRoomKit, concurrent rooms, room limit, joining multiple rooms, single room capacity, peak group count, TUIRoomTypeConference, useRoomState, multi-device login, mutual kick, conference, room management]
+version_range: ">=2.0.0"
+---
+
+# TUIRoomKit Concurrent Room Limits and Multi-Room Support
+
+## 1. Key Takeaways
+
+- The number of concurrent rooms has an upper limit, determined by the **TUIRoomKit (multi-party audio/video) plan version + IM capabilities**.
+- **A single client / single SDK instance cannot be in multiple conference rooms simultaneously**: for conference-type rooms, the per-device concurrent room limit is 1. Exceeding this causes the earliest joined room to be exited.
+- **The same userId on multiple devices joining the same room results in mutual kick by default** (later entry kicks earlier entry). To have multi-device access to the same meeting, configure "multi-device login" according to your plan, or assign different userIds to different devices.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `TUIRoomTypeConference` | Conference-type room | Per-device concurrent room limit is 1 |
+| `useRoomState` | Room state (Atomicx no-UI path) | Singleton; a user can only be in one room at a time |
+| Room count limit | Room/group resource peak | Billed by natural month peak, not unlimited room creation |
+| Single room capacity | Max participants per meeting | Hard limit by plan (20/50/200/300) |
+| Multi-device login | Same userId on multiple devices | Only supported in higher-tier plans |
+
+## 3. Mechanism & Sequence
+
+### Concurrent Room Limit
+
+After activating a TUIRoomKit (multi-party audio/video) plan, the number of concurrent meetings is constrained by **room count limit + single room capacity**:
+
+| Capability Dimension | Trial | Basic Interactive | Advanced Interactive | Ultra-Large Room Interactive |
+|---|---|---|---|---|
+| **Room count limit** (billing metric) | Follows IM version | 100,000/month | 100,000/month | 100,000/month |
+| **Single room participant capacity** | 20 | 50 | 200 | 300 (submit ticket for expansion) |
+
+- Single room capacity is the hard upper limit on "max participants per meeting."
+- Room count limit (peak group count) is the IM-side group/room resource peak included in the plan (billed by natural month peak), not "unlimited rooms at any moment."
+- The actual number of simultaneous meetings also depends on IM plan, TRTC resources, and business architecture. Ultra-large rooms have an expansion channel.
+- Multi-device login to meetings / same-platform multi-device login requires a higher-tier plan.
+
+### Same User Joining Multiple Rooms
+
+When a single client / single SDK instance calls `joinRoom` to enter a new room while already in a conference-type room, the earliest joined room is exited (per-device concurrent room limit is 1).
+
+## 4. Standard Usage
+
+When evaluating concurrent room requirements, follow these steps:
+
+1. Confirm your TUIRoomKit plan version and check the room count limit and single room capacity in the [Features & Billing Documentation](https://cloud.tencent.com/document/product/269/104946).
+2. Evaluate whether the per-meeting participant count exceeds the plan limit; submit a ticket for ultra-large room expansion.
+3. When the business needs to host multiple meetings simultaneously, evaluate whether the room count limit (peak group count) is sufficient, combined with IM plan and TRTC resources.
+4. When the business needs the same user on multiple devices in the same meeting, confirm the plan supports multi-device login; otherwise assign different userIds to different devices.
+
+## 5. Expected Results
+
+- Concurrent meeting count is constrained by plan room count limit and single room capacity.
+- When a single SDK instance joins multiple conference rooms, exceeding 1 causes the earliest joined room to be exited.
+- The same userId on multiple devices joining the same room results in mutual kick (later kicks earlier).
+- Multi-device access to the same meeting requires plan support for multi-device login, or assigning different userIds to different devices.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming room count limit (peak group count) means "unlimited rooms at any time" (billed by natural month peak, not unlimited concurrency).
+- Pitfall 2: Assuming a single SDK instance can be in multiple conference rooms simultaneously (per-device limit is 1).
+- Pitfall 3: Assuming the same userId on multiple devices can join the same room simultaneously (mutual kick by default).
+- Pitfall 4: Ignoring plan version differences (multi-device login only supported in higher-tier plans).
+
+## 7. Problem Definition (retrieval hint)
+
+Whether TUIRoomKit has an upper limit on the number of concurrent meetings, and whether a single user can join multiple rooms simultaneously.
+
+## 8. Alternative Queries (retrieval recall)
+
+- What is the TUIRoomKit concurrent room limit?
+- How many meetings can run simultaneously?
+- Can the same user join two rooms at the same time?
+- What is the maximum number of participants per room?
+- Does TUIRoomKit support multi-device login?
+- Will the same userId on multiple devices cause mutual kick?
+- How to expand the meeting room capacity?

package/resource/knowledge/roomkit/best-practice/common/room-screen-share-preview.md

@@ -0,0 +1,83 @@
+---
+title: "TUIRoomKit Screen Sharing Local Preview and Avoiding Infinite Mirroring（TUIRoomKit / 屏幕共享 / 本地预览 / 无限套娃）"
+product: room
+frameworks: [react, vue, web]
+scope: platform_common
+tags: [TUIRoomKit, screen sharing, local preview, startScreenSharing, startScreenShare, full-screen sharing, infinite mirroring, infinite recursion, window sharing, external monitor, useDeviceState, view parameter]
+version_range: ">=2.0.0"
+---
+
+# TUIRoomKit Screen Sharing Local Preview and Avoiding Infinite Mirroring
+
+## 1. Key Takeaways
+
+- The `view` parameter enables local display of the shared content: passing a valid `view` renders the shared screen in a local container (local preview); omitting it or passing `null` skips local preview rendering.
+- Full-screen sharing with local preview causes "infinite mirroring/recursion": the local preview area is within the captured full screen/current page, so the preview image re-enters the capture, creating recursive mirroring.
+- **Preferred solution: share a "window" instead of the full screen**, preventing the meeting page from being captured and causing recursion.
+  - **Note for sharing WPS**: typically you cannot capture the "slideshow window" independently (the slideshow window and editor window behave inconsistently in the capture list). In this case, have the user connect an **external monitor**: place the slideshow on the external screen, then share that monitor/corresponding window. The main meeting screen continues operating, and the preview is less likely to recurse.
+- **Fallback solution**: when window sharing is not possible and no external monitor is available, make the local preview container as small as possible (shrink the `view` container) to significantly reduce the recursive mirroring impact; or do not pass `view` / pass `null` for local preview, using only a "sharing in progress" status indicator.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `view` | Local screen share preview container | Pass a valid DOM element or id to render local preview; pass `null` to skip |
+| `startScreenSharing` | Screen sharing API | TRTC Web / Room screen sharing; `view` specifies local preview |
+| `startScreenShare` | Underlying screen sharing | TRTC `startScreenShare`, consistent with Atomicx |
+| `useDeviceState().startScreenShare` | Atomicx no-UI path | Screen sharing entry; local preview determined by preview view/container |
+
+## 3. Mechanism & Sequence
+
+### Local Preview
+
+Call screen sharing API with a valid `view` -> local container renders the shared screen (local preview) -> omitting `view` or passing `null` skips local preview rendering.
+
+## 4. Standard Usage
+
+### Screen Sharing with Local Preview
+
+```javascript
+// TRTC Web / Room screen sharing, view specifies local preview container (element or id)
+startScreenShare({
+  view: 'local-preview-container',   // 传入有效 view，本地渲染分享画面
+  // 传 null 则不渲染本地预览
+});
+```
+
+### Avoiding Infinite Mirroring
+
+```javascript
+// 方案 1：优先分享窗口而非整屏，从源头避免套娃
+startScreenShare({ view: 'local-preview-container' });  // 选择窗口采集源
+
+// 方案 2（兜底）：无法分享窗口时，缩小本地预览容器或本地不传 view
+startScreenShare({ view: null });  // 不渲染本地预览，仅用"正在共享"状态提示
+```
+
+## 5. Expected Results
+
+- Passing a valid `view`: local container renders the shared screen, enabling local preview.
+- Omitting / passing `null`: no local preview rendering; only remote participants see the shared screen.
+- Full-screen sharing + local preview: may cause infinite mirroring; switch to window sharing or shrink the preview.
+- Sharing WPS slideshow: use the external monitor approach to avoid mirroring.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming `view` is a remote rendering parameter (`view` specifies the local screen share preview).
+- Pitfall 2: Giving up local preview entirely because full-screen sharing causes mirroring (switch to window sharing or shrink the preview instead).
+- Pitfall 3: Assuming you can capture the WPS slideshow window independently (typically not possible; use an external monitor).
+- Pitfall 4: Confusing `startScreenSharing` with `startScreenShare` (they are consistent at the underlying level; both use `view` for local preview).
+
+## 7. Problem Definition (retrieval hint)
+
+Whether the `view` parameter in TUIRoomKit screen sharing enables local preview of the shared content, and how to avoid infinite mirroring/recursion when sharing the full screen with local preview enabled.
+
+## 8. Alternative Queries (retrieval recall)
+
+- Can screen sharing show a local preview?
+- What is the TUIRoomKit screen sharing startScreenShare view parameter?
+- How to avoid infinite mirroring when sharing full screen?
+- What to do about recursive mirroring in screen sharing?
+- Is it better to share a window or the full screen?
+- How to shrink the local preview window?
+- How to hide local preview for screen sharing?

package/resource/knowledge/roomkit/best-practice/common/room-status-after-all-leave.md

@@ -0,0 +1,69 @@
+---
+title: "TUIRoomKit Room Status and Billing After All Members Leave（TUIRoomKit / 所有人离开 / 房间销毁 / 回收房间 / 解散房间）"
+product: room
+frameworks: [react, vue, web, android, ios, flutter]
+scope: platform_common
+tags: [TUIRoomKit, all members leave, room destruction, room reclaim, dismiss room, billing, meeting end, room existence, room count]
+version_range: ">=2.0.0"
+---
+
+# TUIRoomKit Room Status and Billing After All Members Leave
+
+## 1. Key Takeaways
+
+- A room is **not** automatically destroyed immediately when "all members leave."
+- After a meeting ends, the business side should **proactively call the dismiss room API** to end the meeting.
+- If not manually dismissed: the backend attempts to reclaim the room **6 hours after** the meeting end time, provided the **member count is 0**.
+- Billing is based on actual push/pull stream and call consumption. After all members leave and there is no media usage, audio/video duration charges generally stop; however, the room object still occupies room count quota until dismissed or reclaimed.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| Dismiss room API | Proactively end a meeting | Business side calls after meeting ends |
+| Backend reclaim | Automatic room cleanup | Attempted 6 hours after meeting end; condition: member count is 0 |
+| Room member count | Room member statistics | Reclaim condition: member count is 0 |
+| Audio/video duration billing | Call consumption billing | Billed by actual push/pull stream and call consumption |
+| Room count occupation | Room object occupation | Still occupies room count quota until dismissed or reclaimed |
+
+## 3. Mechanism & Sequence
+
+All members leave room -> Room is not destroyed immediately -> Business side proactively calls dismiss room API (recommended), or waits for backend automatic reclaim -> Backend attempts reclaim 6 hours after meeting end (condition: member count is 0) -> Room is reclaimed.
+
+Billing dimensions:
+
+- Audio/video duration is billed by actual push/pull stream and call consumption.
+- After all members leave and there is no media usage, audio/video duration charges for that room generally stop.
+- The room object still occupies room count quota until dismissed or reclaimed.
+
+## 4. Standard Usage
+
+1. After the meeting ends, the business side proactively calls the dismiss room API to end the meeting, avoiding lingering rooms.
+2. If manual dismissal is forgotten, the backend automatically reclaims the room after 6 hours (when member count is 0).
+3. When evaluating room count occupation, note that undismissed and unreclaimed room objects still consume quota.
+
+## 5. Expected Results
+
+- After proactive dismissal, the room ends immediately.
+- Without proactive dismissal, the backend reclaims the room 6 hours after meeting end when member count is 0.
+- After all members leave and there is no media usage, audio/video duration charges stop.
+- Undismissed and unreclaimed room objects still occupy room count quota.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming rooms are automatically destroyed after all members leave (requires proactive dismissal or waiting 6 hours for backend reclaim).
+- Pitfall 2: Assuming undismissed rooms incur no cost (room objects still occupy room count quota, potentially affecting concurrent capacity).
+- Pitfall 3: Neglecting proactive dismissal by the business side (recommended to call the dismiss API rather than relying on backend reclaim).
+
+## 7. Problem Definition (retrieval hint)
+
+Whether a TUIRoomKit room still exists after all members leave, whether billing continues, and how to proactively dismiss a room.
+
+## 8. Alternative Queries (retrieval recall)
+
+- Does the room auto-destroy after everyone leaves?
+- Does an empty TUIRoomKit room still incur charges?
+- How to dismiss a room after a meeting ends?
+- How long does room reclaim take?
+- What happens when room member count is 0?
+- Does the room object still occupy room count quota?

package/resource/knowledge/roomkit/best-practice/vue/room-uikit-vs-atomicx.md

@@ -0,0 +1,111 @@
+---
+title: "Comparison of tuikit-atomicx-vue3/room vs roomkit-web-vue3（roomkit-web-vue3 vs tuikit-atomicx-vue3/room 的区别）"
+product: room
+frameworks: [vue, web]
+scope: platform_specific
+tags: [TUIRoomKit, Atomicx, UIKit, tuikit-atomicx-vue3, roomkit-web-vue3, useRoomState, conference, layer comparison, no-UI, pre-built UI, custom integration, dependency, vue3]
+version_range: ">=2.0.0"
+---
+
+# Comparison of tuikit-atomicx-vue3/room vs roomkit-web-vue3
+
+## 1. Key Takeaways
+
+- `tuikit-atomicx-vue3/room` (Atomicx) is the **atomic capability layer**: the primary path for no-UI / highly customized integration, decomposing room, device, and member states into reactive State Hooks.
+- `@tencentcloud/roomkit-web-vue3` (RoomKit / UIKit) is the **pre-built UI low-code layer**: an out-of-the-box meeting suite with page-level components.
+- Dependency: **RoomKit (pre-built UI) is a productized wrapper built on top of Atomicx/Room capabilities**. From a business perspective, RoomKit reuses/interfaces with Atomicx capabilities rather than being two independent room protocols.
+- API entry points: Atomicx uses `useRoomState()`, UIKit uses `conference`.
+
+## 2. Field / API Reference
+
+| Field / Capability | Purpose | Notes |
+|---|---|---|
+| `useRoomState` | Atomicx room state entry | `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom` / `currentRoom` |
+| `useDeviceState` | Atomicx device state | Device toggles, screen sharing, etc. |
+| `useRoomParticipantState` | Atomicx participant state | Member management, event subscriptions |
+| `useLoginState` | Atomicx login state | Login capability, reusable within UIKit sessions |
+| `conference` | UIKit meeting facade API | Recommended: `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom` |
+| `ConferenceMainView` | UIKit pre-built view | Complete meeting UI: login, join room, meeting controls, layout, seat management |
+
+## 3. Mechanism & Sequence
+
+### Layer Comparison
+
+| Comparison | `tuikit-atomicx-vue3/room` (Atomicx) | `@tencentcloud/roomkit-web-vue3` (RoomKit / UIKit) |
+|---|---|---|
+| **Layer** | Atomicx (atomic capability layer): State Hooks + optional atomic UI components | UIKit / pre-built UI low-code layer: out-of-the-box meeting suite with page-level components |
+| **Package positioning** | No-UI / highly customized integration path; decomposes room, device, and member into reactive State | Pre-built UI rapid integration path; provides complete meeting UI and `conference` facade API |
+| **Core capabilities** | `useRoomState` / `useDeviceState` / `useRoomParticipantState` / `useLoginState`: create room, join meeting, device control, screen sharing, member management, event subscription; compose your own UI | `conference` + pre-built views (e.g. `ConferenceMainView`): login, join room, meeting controls, layout, seat management; supports selective component visibility / custom Widgets |
+| **Use cases** | Embedding audio/video into your own business UI (telemedicine, OA, education dashboards, etc.) with 100% control over interaction and branding | Fastest path to launch a standard meeting/webinar with minimal UI coding, accepting the official meeting interaction |
+| **Dependency** | Built on RoomEngine / TRTC / IM; an atomic integration approach | Pre-built UI reuses/interfaces with Atomicx capabilities (e.g. login uses `useLoginState`, in-meeting logic uses Room capabilities); RoomKit (pre-built UI) is a productized wrapper on top of Atomicx/Room |
+| **API entry** | `useRoomState()`: `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom`, `currentRoom`, event subscriptions, etc. | `conference`: recommended `createAndJoinRoom` / `joinRoom` / `leaveRoom` / `endRoom` |
+| **UI form** | Optional pre-built atomic components + primarily self-composed custom modules | Primarily pre-built complete meeting UI, with limited customization via Widget / visibility configuration |
+
+## 4. Standard Usage
+
+### Atomicx Approach (no-UI, custom integration)
+
+```javascript
+import { useRoomState } from 'tuikit-atomicx-vue3/room';
+
+const { createAndJoinRoom } = useRoomState();
+
+createAndJoinRoom({
+  roomId: 'YOUR_ROOM_ID', // 必填：建议由业务后台生成的唯一标识
+  options: {
+    roomName: '项目进度周会',
+  },
+});
+// 通过 useDeviceState / useRoomParticipantState 等获取响应式状态自拼 UI
+```
+
+### UIKit Approach (pre-built UI, rapid integration)
+
+```javascript
+import { conference, ConferenceMainView, ConferenceMainViewH5, RoomEvent, genTestUserSig } from '@tencentcloud/roomkit-web-vue3';
+const SDKAppID = 0; // 替换为您在开通服务阶段获取的 SDKAppID
+const SDKSecretKey = ''; // 替换为您在开通服务阶段获取的 SDKSecretKey
+const handleEnterRoom = async () => {
+  if (!SDKAppID || !SDKSecretKey) {
+    return;
+  }
+  try {
+    const { userSig } = genTestUserSig({ userId: 'test01', sdkAppId: SDKAppID, secretKey: SDKSecretKey });
+    await conference.login({ sdkAppId: SDKAppID, userId: 'test01', userSig });
+    await conference.setSelfInfo({ userName: 'test', avatarUrl: '' });
+    await conference.createAndJoinRoom({ roomId: '123456', options: { roomName: `test01 的会议` } });
+    inRoom.value = true;
+  } catch (error) {
+    console.error('进入会议失败:', error);
+  }
+};
+// 使用预制 ConferenceMainView 渲染完整会议 UI
+```
+
+## 5. Expected Results
+
+- No-UI / highly customized needs: choose Atomicx, use `useRoomState()` + State Hooks to compose your own UI.
+- Fastest path to a standard meeting: choose UIKit, use `conference` + `ConferenceMainView`.
+- Dependency: UIKit reuses Atomicx capabilities; they are not two independent protocols.
+- API entry: Atomicx uses `useRoomState()`, UIKit uses `conference`.
+
+## 6. Common Pitfalls
+
+- Pitfall 1: Assuming Atomicx and UIKit are two independent room protocols (UIKit is built on top of Atomicx/Room capabilities).
+- Pitfall 2: Assuming Atomicx includes a complete meeting UI (Atomicx provides State Hooks + optional atomic components; UI must be self-composed).
+- Pitfall 3: Assuming UIKit cannot be customized (it supports selective component visibility / custom Widgets).
+- Pitfall 4: Confusing the API entry points of the two approaches (Atomicx uses `useRoomState()`, UIKit uses `conference`).
+
+## 7. Problem Definition (retrieval hint)
+
+Comparing the positioning differences between two TUIRoomKit Vue3 integration approaches: `tuikit-atomicx-vue3/room` (Atomicx Core SDK, no-UI, State Hooks self-composed) vs `@tencentcloud/roomkit-web-vue3` (RoomKit UIKit, pre-built UI, conference low-code) in terms of layer, capabilities, use cases, dependency, and API entry (useRoomState vs conference).
+
+## 8. Alternative Queries (retrieval recall)
+
+- What is the difference between Atomicx and RoomKit?
+- How to choose between `tuikit-atomicx-vue3/room` and `roomkit-web-vue3`?
+- How to choose between TUIRoomKit no-UI and pre-built UI approaches?
+- What is the difference between `useRoomState` and `conference`?
+- Is RoomKit based on Atomicx?
+- Which package for custom meeting room UI?
+- Use Atomicx or UIKit for rapid meeting integration?

package/resource/knowledge/rtcengine/web/plugin/30-advanced-cross-room-link.md

@@ -8,6 +8,8 @@ Cross-room connections support two modes:
 - **Room-level connection**: Connect with all anchors in the target room.
 - **User-level connection**: Connect with a specific anchor in the target room.
 
+> **Note**: Room-level and user-level connections cannot be used simultaneously.
+
 ## How It Works
 
 - **Room-level connection**: Push the audio and video streams of all anchors in the current room to the target room, and push the audio and video streams of all anchors in the target room to the current room.

package/resource/knowledge/rtcengine/web/plugin/39-advanced-video-decoder.md

@@ -6,6 +6,8 @@ This document introduces how to use the TRTCVideoDecoder plugin to enable video
 
 - TRTC Web SDK version >= 5.9.0
 
+- Browser version: Chrome 141+, Edge 141+, and other Chromium-based browsers 141+ (Safari and Firefox are not supported)
+
 ## Implementation Steps
 
 ### Deploy Static Resources

package/server.js

@@ -3,40 +3,45 @@ import { registryTools } from './tools/index.js';
 const SERVER_INSTRUCTIONS = `
 You are using Tencent RTC MCP Server for SDK documentation retrieval.
 
-- search_trtc_knowledge: Primary tool for searching Tencent RTC / Chat(IM) / Push(TIMPush) product documentation.
+- search_trtc_knowledge: Primary tool for searching Tencent RTC / Chat (IM) / Push (TIMPush) documentation.
   Covers: Chat UIKit, CallKit, LiveKit, RoomKit, TRTC Native SDK, WebRTC/rtcEngine, TIMPush.
-  Use this tool FIRST for all technical documentation / FAQ / error code / integration guide lookups.
-  Do NOT use web_search for questions that can be answered via this knowledge base.
+  Use this tool FIRST for technical docs / FAQ / error codes / integration guide lookups.
+  Do NOT use web_search for questions answerable by this knowledge base.
 
-**Product routing（调用 search_trtc_knowledge 前 MUST 推断 product 数组）**：
-- TIMPush / 推送 / 厂商通道 / FCM / APNs / 华为 / 小米 / OPPO / vivo → product=["push"]（独立产品，禁止误归 chat）
-- 会话 / TUIKit / ChatKit / IM 组件 / 主题定制 → ["chat"]
-- CallKit / 通话 → ["call"]；直播 / 语聊房 / LiveKit → ["live"]；RoomKit / 会议 → ["room"]
-- TRTC Web SDK / rtcengine / WebRTC 插件 → ["rtcengine"]
-- TRTCCloud / Native SDK（客户端）→ ["native_trtc_sdk"]
-- 推送 + IM 同时涉及 → 可传 ["push","chat"]
-- 无法从 prompt 唯一判断 product → 先向用户确认，不要无 product 硬搜，也不要 web_search
+**Product routing (MUST infer product[] before calling search_trtc_knowledge):**
+- TIMPush / push / vendor channel / FCM / APNs / Huawei / Xiaomi / OPPO / vivo -> product=["push"] (independent product; do not misroute to chat)
+- conversation / TUIKit / ChatKit / Chat component / theme customization -> ["chat"]
+- CallKit / call -> ["call"]; live streaming / voice room / LiveKit -> ["live"]; RoomKit / conference -> ["room"]
+- TRTC Web SDK / rtcengine / WebRTC plugin -> ["rtcengine"]
+- TRTCCloud / Native SDK (client side) -> ["native_trtc_sdk"]
+- If both push and Chat are involved -> ["push","chat"]
+- If product cannot be uniquely inferred from prompt -> ask user to clarify first; do NOT hard-search with empty product; do NOT use web_search.
 
-**Frameworks**：返回 needs_framework 时 MUST 先 present_framework_choice；详见 search_trtc_knowledge 工具 description 决策表。
-**When in doubt**：仍优先调用 search_trtc_knowledge（带最佳猜测 product）；status=empty 或 low_confidence 时再澄清或重搜。
+**Frameworks:** If status=needs_framework, MUST call present_framework_choice first. See search_trtc_knowledge tool description decision table.
+**When in doubt:** still prefer search_trtc_knowledge with best-guess product; if status is empty or low_confidence, then clarify or retry.
 
-**queryID 传递规则（硬规则，违反会导致 CLS 数据断裂）**：
-- 首次调用 search_trtc_knowledge：无需传 queryID（默认空串），响应 JSON 中会有 server 生成的 queryID 字段
-- 后续每一次 search_trtc_knowledge / finalize_answer / submit_feedback 调用：**MUST** 携带首次响应中的 queryID
-- 不传 queryID = 视为全新咨询（CLS 数据无法串联）
-- 多 sub-question 迭代搜索时，每次都要带相同的 queryID
+**queryID passing rules (hard rule; violation breaks CLS trace continuity):**
+- First search_trtc_knowledge call: no queryID required (defaults to empty); response JSON will include server-generated queryID.
+- Every subsequent call to search_trtc_knowledge / finalize_answer / submit_feedback: MUST carry the first returned queryID.
+- Missing queryID means a brand-new consultation (CLS data cannot be linked).
+- For multi-sub-question iterative searches, always reuse the same queryID.
 
 Workflow:
 1. Call search_trtc_knowledge. Reuse the same queryID for all retries/searches in this consultation.
-2. Draft the final answer from fragments. Include References from meta.references/doc_urls when available.
-3. MUST call finalize_answer with the same prompt + queryID before replying.
-4. Reply with: answer + finalize_answer follow-up text.
-5. After finalize_answer follow-up, check the next user reply before any normal response. If it means Yes/已解决/thanks/OK, MUST call submit_feedback(resolved="1") before replying. If it means No/未解决/still not working, MUST call submit_feedback(resolved="0") before replying. Never say feedback was submitted unless submit_feedback was called.
+2. Draft the complete answer from fragments. Include References from meta.references/doc_urls when available.
+3. MUST call finalize_answer with the same prompt, answer, and queryID before replying.
+4. Reply with that answer + finalize_answer follow-up text.
+5. After finalize_answer follow-up, inspect the next user reply before any normal response. If it means Yes/resolved/thanks/OK, MUST call submit_feedback(resolved="1") before replying. If it means No/unresolved/still not working, MUST call submit_feedback(resolved="0") before replying. Never claim feedback was submitted unless submit_feedback was actually called.
+
+User-visible output rules (MUST):
+- Internal routing/tool decisions are NEVER user-facing text.
+- Before calling any tool, do NOT output prefacing planning text such as “should call... / call ... first / let me search first / this is a consultation task / not codegen”.
+- If a tool call is needed, call it directly and then provide user-visible results only.
 `.trim();
 export function createServer() {
     const server = new McpServer({
         name: "Tencent RTC MCP Server",
-        version: "1.6.8",
+        version: "1.7.1",
     }, {
         instructions: SERVER_INSTRUCTIONS,
     });