为什么这里会出现 AliRTC：Live 后端负责创建会话、鉴权、控制信令和数字人编排，但不直接把麦克风、摄像头或数字人音视频通过 WebSocket 转发给 App。实时媒体流需要低延迟传输、设备采集、编解码、丢包恢复和订阅回调，因此由 AliRTC SDK 承载。
接入时要同时建立两条链路：App WebSocket 负责控制，AliRTC 负责媒体。两条链路是并行关系，缺一不可。
链路 | 承载内容 | 典型动作 |
|---|---|---|
App WebSocket | 控制信令 | `conn_init` 开始、`text_msg` 文字互动、`audio_interrupted` 打断、`call_hangup` 挂断。 |
AliRTC | 实时媒体流 | 发布 App 麦克风音频；`video` 模式发布摄像头视频；订阅数字人音频和视频。 |
AliRTC 前置条件
- 客户端需要单独集成 AliRTC SDK。Web 端可参考阿里云 RTC Web SDK 文档，并在页面中加载对应 SDK。
- 创建 live 接口返回的
rtc对象就是入会凭证来源，不需要客户端自行生成 token。 rtc.token：传给joinChannel的鉴权信息。rtc.user_id：当前 App 用户在 RTC 房间里的身份，作为joinChannel的第二个参数。rtc.channel_id：服务端创建的 RTC 房间标识，主要用于日志、订阅回调和问题排查；客户端通常不需要自行拼接。rtc.token_expire_at：token 过期时间，Unix 秒；过期后应重新创建 live。
基本概念
概念 | 说明 |
|---|---|
`channel` | 一次 live 对应的 RTC 房间。只有进入同一 channel 的用户才能互相收发媒体流。 |
`publish` | 把本端麦克风或摄像头推到 RTC 房间，让服务端和数字人链路能听到或看到用户。 |
`subscribe` | 从 RTC 房间拉取远端用户的音频或视频。本场景的远端用户主要是数字人音频和数字人视频推流。 |
入会并发布本端媒体
客户端使用创建 live 返回的 rtc.token 和 rtc.user_id 加入频道，然后发布本端麦克风；video 模式还需要发布摄像头。
模式 | channel_id | App 端职责 |
|---|---|---|
`audio` | `live-audio-{live_id}` | 发布麦克风音频，订阅数字人音频。 |
`video` | `live-user-{live_id}` | 发布麦克风和摄像头，订阅数字人视频流。 |
订阅并渲染数字人音视频
开启默认订阅后，远端音频通常会由 SDK 自动订阅和播放；实际播放仍可能受浏览器自动播放策略影响。远端视频需要准备 <video autoplay playsinline> 容器，并在订阅状态变为 subscribed 后绑定远端视图。
如果看不到远端画面，先确认日志中已经出现 RTC joined，再确认数字人推流用户是否上线，以及 videoSubscribeStateChanged 或 screenShareSubscribeStateChanged 是否进入 subscribed 状态。若浏览器拦截自动播放，需要引导用户点击播放或在用户手势后恢复播放。
角色 ID 规则
角色 | 用户 ID 格式 |
|---|---|
用户 | `live-user-{creatorID}-{liveID}` |
数字人音频 | `live-bot-{creatorID}-{liveID}` |
数字人视频推流 | `live-video-push-{creatorID}-{liveID}` |
客户端一般直接使用创建接口返回的 rtc 信息入会，不需要自己拼接 token 或 channel。上面的 ID 规则主要用于日志、订阅回调和排查问题。