文档反馈官招募中，报名立赚积分兑换代金券！> HOT
文档中心>TRTC 云助手>场景化方案>社交娱乐>语聊房>场景解决方案

场景解决方案

最近更新时间：2026-05-18 17:55:01

我的收藏

本页目录：

场景介绍

语聊房是指以纯音频的方式进行线上互动社交的虚拟空间，房间内通常设有数个麦位，主播和连麦听众在麦上聊天，其他听众可以进入房间收听。不同类型的房间麦位数量和可容纳最大听众数量不同。腾讯云实时音视频 TRTC 支持最多50人同时上麦聊天，上下麦平滑切换，语聊时延低于300ms，支持变声、气氛音效、混响等多种音频效果，让语聊体验更加丰富。结合即时通信 IM，支持公聊、私聊、群聊、点赞、送礼等多种消息互动形式，打造良好的聊天互动体验。




实现方案

通常实现一个完整的语聊房场景，需要涉及到多个功能模块：房间管理、麦位管理、音频流管理、录制与审核 等。每个功能模块下的关键动作及功能点如下表所示：
功能模块
关键动作及功能点
房间管理
房间列表、创建房间、加入房间、退出房间、销毁房间
麦位管理
主动上麦、抱人上麦、主动下麦、踢人下麦、麦位禁音、麦位锁定、麦位移动
音频流管理
推拉流架构方案、实时流订阅模式
录制与审核
TRTC 云端录制、天御内容安全审核
语聊房的场景整体的业务架构图如下图所示。房主创建语聊房间，用户可以选择对应感兴趣的房间加入。进入房间后的用户可以上麦，跟麦上主播进行语音互动，而房间内的语音内容，由于合规的要求，需要录制下来并审核。




房间管理

房间管理模块主要负责对房间列表的维护，主要包含以下功能：
创建房间：用户登录业务系统后，可以创建房间，创建房间后房间列表要做新增操作。
加入房间：用户可以选择加入现有房间，加入房间后当前房间人员列表要做新增操作。
退出房间：用户可以选择退出当前房间，退出房间后当前房间人员列表要做删除操作。
销毁房间：所有用户退出房间后，需要销毁房间，销毁房间后房间列表要做删除操作。

方案架构

在整个房间管理的架构中，主要是涉及到三大模块的房间管理：
业务侧房间管理：主要用于房间列表的维护与管理，例如同步业务房间的属性与状态，功能包括房间列表查询、进退房间、创建销毁房间。
IM 群组管理：主要是用于房间成员列表、信令收发和消息互动，例如同意/拒绝上麦申请、抱人上/下麦、麦位声音的静音/解禁、麦位的封禁/解禁，同时也以群组维度进行区分，功能包括创建群组、加入群组、退出群组、销毁群组。
TRTC 房间管理：主要用于音频流的互动与传输，例如主播/听众的声音/音乐的发送与收听，同时也以房间维度进行区分，功能包括进退 TRTC 房间。




具体实现

在房间管理中，不同的用户角色具有不同的功能权限及实现流程。语聊房中主要存在房主和听众两种角色，角色描述及其区别详见下表：
角色
描述
区别
房主
房间最高权限的拥有者，可以创建或者销毁房间。
角色必须为主播
创建或者销毁业务房间/IM 群组/RTC 房间
听众
房间的参与者，也可以上麦变成主播。
角色可以为观众/主播
进退房间

实现流程

房主



1. 获取房间列表。
2. 通过业务接口创建对应的房间。
3. 创建 IM 群组。
4. 进入业务房间/IM 房间/RTC 房间，与其他人互动。
5. 退出 IM 房间/RTC 房间/业务房间。
6. 销毁 IM 群组。
听众



1. 获取房间列表。
2. 进入业务房间/ IM 群组/ RTC 房间，与其他人互动。
3. 退出 IM 群组/ RTC 房间/业务房间。

麦位管理

语聊房内的麦位一般都是有序且有限的，例如房间听众上麦需经房主同意后有序上麦，房间内的麦位数量一般不超过10个。麦位管理主要负责根据业务场景定义房间内的麦位数量，以及当前房间所有麦位的状态管理。麦位管理主要包含的功能：主动上麦、抱人上麦、主动下麦、踢人下麦、麦位禁音、麦位锁定、麦位移动等。
用户进入房间后，只有存在空闲状态的麦位时用户才可以申请上麦。
房主同意用户上麦后，需要修改麦位状态为非空闲状态。
用户停止推流下麦后，需要重置麦位状态。
房主有权锁定麦位、邀请上麦、强制下麦、麦上禁言等。

方案架构

下面将结合实时音视频 TRTC 和即时通信 IM 来组织麦位管理的方案架构。在整个房间管理的架构中，房主拥有最高的权限，可以抱人上麦/踢人/麦位音频的静音与解禁/麦位封禁与解禁，而听众也能通过申请上麦，成为麦上主播，与房间内其他的主播进行互动。




具体实现

在麦位管理中，不同的用户角色具有不同的功能权限及实现流程，主要存在房主和听众两种角色，角色描述及其区别详见下表：
角色
描述
区别
房主
麦位最高权限者，负责所有麦位的管理，房主退房后会自动解散所有麦位。
角色必须为主播
进房主动上麦
同意/拒绝上麦申请
抱人上/下麦
麦位声音的静音/解禁
麦位的封禁/解禁
听众
房间内麦位参与者，可以上下麦互动。
角色可以为观众/主播
申请上/下麦

实现流程

房主



1. 主播进入房间大厅，获取房间列表。
2. 主播作为房主创建房间，并加入房间。
3. 房主依赖群属性获取麦位列表，并主动上麦。
4. 听众上麦。上麦后，可与麦位上其他用户进行互动。听众上麦支持两种方式：听众主动申请上麦，房主同意；房主主动邀请听众上麦，听众同意。
5. 听众下麦。下麦支持两种方式：听众主动下麦；房主强制将听众抱下麦。
6. 房主退出并销毁房间（房间被解散，所有用户强制下麦退房）。
听众



1. 听众进入房间大厅，获取房间列表。
2. 听众选择并进入房间。
3. 听众依赖群属性获取麦位列表。
4. 听众申请上麦，房主同意后，听众与麦位上其他用户进行互动。
5. 听众下麦并退出房间。

音频流管理

语聊互动场景通常会选择 RTC 流接入方案，接入简单快捷，同时能够体验到实时互动的低时延特性。如下图所示，以麦上用户和麦下观众两种角色展示了一种比较经典的实时互动语聊的推拉流架构方案。



针对房间内的实时流订阅，TRTC 共有两种订阅模式可供选择：自动订阅、手动订阅。
自动订阅：用户进入房间后，会立刻接收到该房间中的音视频流，音频会自动播放，视频会自动开始解码。
手动订阅：用户进入房间后，需要手动调用 startRemoteView 启动视频流的订阅和解码，需要手动调用 muteRemoteAudio 启动音频的播放。
在绝大多数场景下， TRTC 默认采用自动订阅模式，用户进入房间后都会订阅房间中所有主播的音视频流，以求得更好的“秒开体验”。 而手动订阅模式则具备更好的灵活性和可定制性，用户可以选择性地订阅音视频流。
说明：
相较手动订阅模式，自动订阅无需繁杂的媒体流订阅管理，语聊场景下如无特殊需求推荐使用自动订阅模式。

录制与审核

由于国内对线上社交的监管政策日渐趋严，很多情况下需要云端录制及存储媒体内容，以便备案与审查。同时还有对线上互动内容进行实时安全审核的需求，以便及时管控违法违规的语聊房，从而使得线上社交平台更加规范化。

TRTC 云端录制

TRTC 最新升级的云端录制，不依赖云直播的能力，无需旁路转推云直播，使用 TRTC 内部的实时录制集群进行音视频录制，拥有更完整统一的录制体验。
单流录制：通过 TRTC 的云端录制功能，您可以将房间中的每一个用户的音频流都录制成独立的文件。



混流录制：将同一个房间的音频媒体流混流录制成一个文件。



注意：
TRTC 云端录制的具体介绍及开通指引详见 实现云端录制与回放。
单流录制可以使用 全局自动录制，混流录制则需使用 API 手动录制。

天御内容安全审核

TRTC 联合 T-Sec 天御，提供了实时的音视频内容识别与告警服务，使用实时音视频服务时，支持全局自动或手动发起策略进行音视频内容的识别和告警：
全局自动审核
客户可以指定审核策略和审核流类型，TRTC 云端自动完成应用下所有房间内的音视频内容审核，并通过回调把违规信息发送到客户指定的回调 URL，无需手动发起审核。该方式简单易用，省去了代码接入的工作量，但灵活性欠佳。
TRTC 与天御内容安全审核平台结合的实现原理如下图所示：直播内容安全通过“哑终端”的形式进入指定的 TRTC 房间，作为“观众”拉取音视频流，并针对拉取的音视频流进行内容审核，然后通过回调把违规信息发送到用户指定的 HTTP/HTTPS 服务上。



手动自定义审核
客户只需要调用天御音视频流接口即可实时检测音视频流中是否出现违规内容。音视频安全审核服务会通过回调把违规信息发送给客户指定的回调 URL。该方式更灵活、可定制化更强，但需要调用 REST API 发起审核任务，具有一定的接入复杂度。



说明：
全局自动审核接入指引详见 自动审核接入；手动审核接入指引详见 手动审核接入。

关键业务逻辑

幽灵麦处理方案

“幽灵麦”（又称“炸麦”或“黑麦”）是指用户不在业务侧麦位列表中，但仍能够在 RTC 房间内发言，且其他用户仍可听到其声音的异常现象。通常幽灵麦特指由未授权用户通过外挂、破解等方式恶意上麦发言，制造噪音、违规内容、刷屏等扰乱语聊房秩序的行为。
幽灵麦问题的本质在于业务侧麦位状态与 RTC 实际音频上行状态不一致，或业务权限控制被绕过。常见原因可归纳为以下三类：
麦位状态同步异常
用户下麦后，业务侧虽已更新麦位状态，但由于信令回调未正常触达、消息被拦截、状态同步异常等原因，客户端未及时执行切换观众角色、关闭麦克风或停止推流等操作，导致用户实际仍在进行音频上行。
RTC 状态切换失败
客户端已正确收到下麦通知，并开始执行 TRTC 角色切换或停止推流操作，但由于接口调用失败、状态机异常、网络问题等原因，导致 RTC 实际推流状态未成功关闭，从而出现“已下麦但仍能发言”的现象。
权限控制被绕过或恶意攻击
攻击者通过 App 破解、外挂、Hook、协议模拟、UserSig 泄露等方式，绕过业务侧上麦鉴权或客户端状态控制，伪造主播身份进入房间并强行进行音频上行，进而实施噪音干扰、违规内容传播、恶意刷屏等破坏房间秩序的行为。
针对幽灵麦问题，可通过主动检测 RTC 实际音频状态与业务侧麦位状态的一致性，实现幽灵麦的快速识别与处理。下面将介绍几种常用的幽灵麦预防和处理方案，建议根据业务需求自行选择合适的方案。

手动订阅音频流方案

方案原理：通过 TRTC SDK setDefaultStreamRecvMode 设置音频流手动订阅模式，当收到远端用户发布音频流的回调，先通过对比业务侧麦位列表，再决策是否订阅并播放该用户的音频流。该方案具备较好的幽灵麦预防效果，参考示例代码如下。
Kotlin
Swift
Dart
// 进房前：关闭自动订阅，改为手动按需拉流
trtcCloud.setDefaultStreamRecvMode(false, false)
trtcCloud.enterRoom(params, TRTCCloudDef.TRTC_APP_SCENE_LIVE)

// 麦位列表：业务侧自行维护，决定哪些用户的音频需要被订阅
private val seatUserSet = mutableSetOf<String>()

// SDK 回调：远端用户发布/取消音频流 → 对比麦位列表决定是否订阅
override fun onUserAudioAvailable(userId: String, available: Boolean) {
    if (available && userId in seatUserSet) {
        trtcCloud.muteRemoteAudio(userId, false)
    }
}

// 麦位变更补偿：防止音频回调与麦位信令时序不一致导致漏订或多订
fun onSeatListUpdated(newSet: Set<String>) {
    (newSet - seatUserSet).forEach { trtcCloud.muteRemoteAudio(it, false) }
    (seatUserSet - newSet).forEach { trtcCloud.muteRemoteAudio(it, true) }
    seatUserSet.clear(); seatUserSet.addAll(newSet)
}
// 进房前：关闭自动订阅，改为手动按需拉流
trtcCloud.setDefaultStreamRecvMode(false, video: false)
trtcCloud.enterRoom(params, appScene: .LIVE)

// 麦位列表：业务侧自行维护，决定哪些用户的音频需要被订阅
private var seatUserSet: Set<String> = []

// SDK 回调：远端用户发布/取消音频流 → 对比麦位列表决定是否订阅
func onUserAudioAvailable(_ userId: String, available: Bool) {
    if available && seatUserSet.contains(userId) {
        trtcCloud.muteRemoteAudio(userId, mute: false)
    }
}

// 麦位变更补偿：防止音频回调与麦位信令时序不一致导致漏订或多订
func onSeatListUpdated(_ newSet: Set<String>) {
    newSet.subtracting(seatUserSet).forEach { trtcCloud.muteRemoteAudio($0, mute: false) }
    seatUserSet.subtracting(newSet).forEach { trtcCloud.muteRemoteAudio($0, mute: true) }
    seatUserSet = newSet
}
// 进房前：关闭自动订阅，改为手动按需拉流
await trtcCloud.setDefaultStreamRecvMode(false, false);
await trtcCloud.enterRoom(params, TRTCAppScene.LIVE);

// 麦位列表：业务侧自行维护，决定哪些用户的音频需要被订阅
final _seatUserSet = <String>{};

// SDK 回调：远端用户发布/取消音频流 → 对比麦位列表决定是否订阅
void _onUserAudioAvailable(String userId, bool available) {
  if (available && _seatUserSet.contains(userId)) {
    trtcCloud.muteRemoteAudio(userId, false);
  }
}

// 麦位变更补偿：防止音频回调与麦位信令时序不一致导致漏订或多订
void onSeatListUpdated(Set<String> newSet) {
  newSet.difference(_seatUserSet).forEach((id) => trtcCloud.muteRemoteAudio(id, false));
  _seatUserSet.difference(newSet).forEach((id) => trtcCloud.muteRemoteAudio(id, true));
  _seatUserSet..clear()..addAll(newSet);
}
注意：
建议增加补偿机制：麦位列表变更时主动补订阅/退订阅，解决“音频回调先于麦位信令到达”的时序问题。
手动订阅音频流方案在幽灵麦预防方面表现良好，但同时也可能影响最佳的“秒开体验”。

音量大小回调方案

方案原理：通过 TRTC SDK enableAudioVolumeEvaluation 启用音量大小提示，当收到远端用户的音量大小回调，比对该音频推流用户和业务侧麦位列表，从而识别出不在麦位上却有音频推流的幽灵麦。整体实现流程如下图所示。

当检测出幽灵麦后，客户端本地执行 muteRemoteAudio 静音该远端用户的音频流，同时上报到业务服务端，业务服务端决策是否将该用户禁言或踢出房间 RemoveUser。
注意：
建议检测到幽灵麦后等待累计一定次数后再处理，避免弱网环境下 RTC 音频上行状态和业务侧麦位状态的更新存在短暂时差，导致误判幽灵麦。
若采用该方案，建议音量大小回调时间间隔 interval 不要设置太短，防止频繁的幽灵麦判断操作占用设备性能，导致音频卡顿。

业务侧进房校验方案

方案原理：幽灵麦用户通常会通过非法入侵手段获取 TRTC 鉴权凭证 UserSig，然后利用 Web 等平台直接绕过业务逻辑，通过 TRTC SDK 进入任意房间实施干扰或攻击。这种情况下，可以通过在 TRTC 服务端进房事件回调中增加业务侧校验逻辑，检查用户是否同时登录了业务房间，若仅进入了 TRTC 房间则视为幽灵麦用户并进行禁言处理或踢出房间。
1. 实时音视频 TRTC 控制台支持自助配置回调信息，配置完成后即可接收事件回调通知。详情请参见 回调配置。
2. 接收并解析回调事件包体，监听103（进入房间）事件，并在事件回调中检查用户是否同时登录了业务房间。详情请参见 事件回调。
3. 如果检测出用户仅进入 TRTC 房间并未登录业务房间，则将该用户视为幽灵麦用户并进行禁言或踢出房间 RemoveUser。
Node.js
Go
Python
app.post('/trtc/callback', async (req, res) => {
    const { EventType, EventInfo } = req.body;

    // 仅处理 103 进房事件
    if (EventType === 103) {
        const { RoomId, UserId } = EventInfo;

        // 查询业务侧：该用户是否在业务房间中
        const inBusinessRoom = await db.checkUserInRoom(RoomId, UserId);

        if (!inBusinessRoom) {
            // 幽灵麦 → 踢出房间
            await trtcApi.removeUser(RoomId, UserId);
        }
    }

    res.json({ code: 0 });
});
func handleCallback(w http.ResponseWriter, r *http.Request) {
    var cb CallbackBody
    json.NewDecoder(r.Body).Decode(&cb)

    // 仅处理 103 进房事件
    if cb.EventType == 103 {
        info := cb.EventInfo

        // 查询业务侧：该用户是否在业务房间中
        if !db.CheckUserInRoom(info.RoomId, info.UserId) {
            // 幽灵麦 → 踢出房间
            trtcApi.RemoveUser(info.RoomId, info.UserId)
        }
    }

    w.Write([]byte(`{"code":0}`))
}
@app.route('/trtc/callback', methods=['POST'])
def trtc_callback():
    data = request.get_json()

    # 仅处理 103 进房事件
    if data['EventType'] == 103:
        info = data['EventInfo']

        # 查询业务侧：该用户是否在业务房间中
        if not db.check_user_in_room(info['RoomId'], info['UserId']):
            # 幽灵麦 → 踢出房间
            trtc_api.remove_user(info['RoomId'], info['UserId'])

    return jsonify(code=0)

上下麦防卡顿方案

问题描述

由于移动设备系统机制的差异，Android 和 iOS 在语聊场景中的上下麦表现并不一致。iOS 端在上下麦时刻可能会出现短暂的音频卡顿。

原因分析

这与 iOS 系统音频机制有关，startLocalAudio 和 stopLocalAudio 操作会获取和释放麦克风设备权限，SDK 的音频重采集导致 AVAudioSession 重启音频驱动，从而出现上下麦时音频短暂卡顿的现象。

解决方案

TRTC 常规的上下麦方案时序如下图所示，切换角色的同时开启或停止本地音频的采集和发布。此方案在 Android 端上可以正常使用。
iOS 端可在下麦操作中仅通过切换观众角色来停止推流，而无需调用 stopLocalAudio 停止音频采集和释放麦克风权限，即可避免上下麦卡顿。



注意：
上下麦防卡顿方案中，下麦操作不调用 stopLocalAudio 系统会一直保持麦克风采集状态，可能会造成用户误解。

音频配置最佳实践

音频配置中音频质量和音量类型是两个不同的概念。TRTC 中音频质量可以在开启本地音频采集和发布时设置 startLocalAudio(TRTCAudioQuality) 或通过 setAudioQuality(TRTCAudioQuality) 单独设置音频质量；音量类型则是由进房场景和音频质量的设定等多种因素组合决定的，此外也可通过 setSystemVolumeType(TRTCSystemVolumeType) 强制指定某种音量类型。

音频质量配置最佳实践

TRTC SDK 目前提供了三种精心调校好的音质模式，用来满足各种垂直场景下对音质的差异化追求。
音质模式
音质枚举值
音质参数
音质说明
人声模式
TRTCAudioQualitySpeech
采样率：16k；单声道；
编码码率：16kbps
具备较强的网络抗性，在弱网环境下流畅度较好，适合以人声沟通为主的应用场景，例如在线会议，语音通话等。
默认模式
TRTCAudioQualityDefault
采样率：48k；单声道；
编码码率：50kbps
SDK 默认档位，对音乐的还原度比人声模式要好，同时传输数据量比音乐模式要低很多，对各种场景均有不错的适应性。
音乐模式
TRTCAudioQualityMusic
采样率：48k；全频带立体声；
编码码率：128kbps
该模式下音频传输的数据量很大，保障音乐信号在各频段均能获得高保真的细节还原度，适合需要高保真传输音乐的场景。
通过上表可以看出，从人声模式到音乐模式，音质效果是递增的，但音频传输的数据量也是递增的。
语聊房场景下，纯人声沟通建议选用人声模式，弱网条件下可以获得更好的流畅性；
有播放背景音乐需求的语聊房建议选用默认模式或音乐模式，以获得不错的音频细节还原度；
考虑到下行观众网络带宽压力，为保证良好的用户体验，十人以上麦位的业务场景建议慎用音乐模式。
说明：
TRTC 音频质量支持动态调整，即在推流过程中通过调用 setAudioQuality(TRTCAudioQuality) 来动态调整音频质量。

音量类型配置最佳实践

TRTC SDK 目前提供了三种系统音量类型的控制模式，用来满足不同场景下对音量类型的差异化需求。
音量类型模式
音量类型模式枚举值
音量类型模式说明
全程通话音量
TRTCSystemVolumeTypeVOIP
该方案的优势在于用户在上下麦时音频模块无需切换工作模式，可做到无缝上下麦，适合于用户需要频繁上下麦的应用场景。 如果在进房时选择的场景为 TRTCAppSceneVideoCall 或 TRTCAppSceneAudioCall，SDK 会自动使用该模式。
自动切换模式
TRTCSystemVolumeTypeAuto
也被称为“麦上通话，麦下媒体”，即主播上麦时使用通话音量，观众不上麦则使用媒体音量，适合在线直播场景。 如果在进房时选择的场景为 TRTCAppSceneLIVE 或 TRTCAppSceneVoiceChatRoom，SDK 会自动使用该模式。
全程媒体音量
TRTCSystemVolumeTypeMedia
通话全程使用媒体音量，适用于对音质要求比较苛刻的音乐场景中。如果您的用户大都使用外接设备（例如外接声卡）为主，可以使用该模式。
通话场景下，建议选用默认的全程通话音量，此时音频模块无需切换；
语聊房场景下，纯人声沟通建议选用默认的自动切换模式，即麦上通话，麦下媒体；
需要播放背景音乐的语聊房可以考虑设置全程媒体音量，避免用户上下麦时感知远端音乐卡顿和音量骤变。
说明：
如需指定某种音量类型，建议在进房后推流前调用一次 setSystemVolumeType，不要在上下麦时调用。
通话音量支持使用手机自带的 AEC 功能，并且支持通过蓝牙耳机上的麦克风进行拾音，缺点是音质比较一般。
媒体音量无法使用手机自带的 AEC 功能，并且不支持通过蓝牙耳机的麦克风进行拾音，但具备更好的音乐播放效果。

单流音量大小评估

在语聊房场景中，部分客户为了降低带宽节省成本，可能会选择麦上用户推拉 RTC 单流，观众通过拉取房间内的混流。然而语聊房场景通常需要根据麦上用户的音量大小在 UI 上做出相应的提示，例如“声波图”或“音量槽”。单路音频的音量大小评估反馈功能在 TRTC 房间内很容易实现，但要想在纯音频混流中实现则需要用到一些特殊的方法。下面将分别介绍两个方案的具体实现。

RTC 房间内单流音量评估

步骤一：启用音量大小提示
通过 enableAudioVolumeEvaluation 接口开启音量大小回调，同时可选开启本地人声检测功能。开启此功能后，SDK 会在 onUserVoiceVolume 回调中反馈本地用户和远端推流用户的音量大小、最大音量值，以及本地人声检测结果。
注意：
TRTC SDK 10.2 及以上版本新增了本地人声检测功能，开启后会在 TRTCVolumeInfo.vad 中展示本地人声检测结果（须为主播角色），muteLocalAudio 和 setAudioCaptureVolume(0) 操作不会影响人声检测结果，方便提醒用户开麦。
步骤二：监听音量大小回调
在 TRTCCloudListener 中监听 onUserVoiceVolume 回调，回调中反馈本地用户和远端推流用户的音量大小以及远端的最大音量值，您可根据音量大小在 UI 上进行相应的声波展示。
注意：
麦上用户声波动画的渲染可以根据 onUserVoiceVolume 回调中的音量大小来确定，声波动画的开启和关闭（用户开闭麦状态）建议根据 onUserAudioAvailable 回调来确定。

纯音频混流单流音量评估




纯音频混流评估单流音量的实现流程如上图所示，麦上主播需要监听音量大小回调，并判断本地音量和远端音量，将本地音量值及用户信息以 SEI 消息的形式插入到音频流中，经过混流后透传给麦下观众。或者由房主一人将所有麦上主播的回调音量值通过 SEI 的方式发送出去。下图展示了整个流程的时序图：



注意：
若涉及混流转推 CDN 透传 SEI 需求：
进房场景必须选用 LIVE，不能选用纯语音进房场景，否则 SEI 消息将无法透传。
若混流接口采用 setMixTranscodingConfig，则混流模式不能选用 PureAudio 纯音频模式。
若混流接口采用 startPublishMediaStream，则媒体流转码配置参数里必须携带 TRTCVideoLayout 参数。
如下图所示，观众端在拉混流解析出来的 SEI 消息中就会显示对应说话者的音量大小。




场景玩法

在语聊房场景中，房主和几名麦上用户以语音的方式在线互动，可能还会有观众，不能发言，只能收听，通过赠送礼物和聊天消息互动。通常会设置不同的房间主题，以吸引具有相同爱好的用户观看互动，常见的主题有：FM 电台、K 歌语聊、游戏互动、赛事直播等。

FM 电台房

会有主播单人直播或主持人和几名固定陪聊嘉宾，同时播放背景音乐和音效，麦下观众可以赠送礼物上麦，以参与语音互动。
此场景一般观众数量较多，且不会有频繁的上下麦动作，适合使用麦上主播推拉 RTC 流 + 麦下观众拉 CDN 混流方案。观众上麦时由 RTMP 通道切换成 TRTC 通道，进房上麦推拉实时流。此方案兼顾了实时互动性与费用成本。
说明：
该场景推荐：麦上主播推拉 RTC 流 + 麦下观众拉 CDN 混流方案。
观众连麦切换 RTMP 协议与 RTC 协议时，需要注意上下麦的平滑处理。

KTV 语聊房

一般会有一名管理员，大家可以点歌、评论、猜歌、接唱等，主要分为多人连麦和多人轮麦两个模式。 多人连麦为一个人主唱，其他连麦用户可以边听边说话，主唱听不到其他连麦者说话声，房间的听众则能听到全部的声音。 多人轮麦模式是点歌后，一人唱一段，唱完自动轮到下一个人唱，其他用户在等待的时间只能听，只能评论交流，不能语聊。
在线 K 歌场景对延时同步要求较高，且观众有随时上麦参与合唱的需求，适合使用麦上主播推拉 RTC 流 + 麦下观众拉 RTC 混流方案。这里需要一个混流机器人发起混流指令，并将混流回推至 TRTC 房间供麦下观众拉流观看。
说明：
该场景推荐：麦上主播推拉 RTC 流 + 麦下观众拉 RTC 混流方案。
关于 KTV 语聊房实现的具体技术细节以及注意事项，详情请参照 在线 K 歌场景解决方案。

互动游戏房

狼人杀、剧本杀、PIA 戏、真心话大冒险、你画我猜等，该场景下会按照游戏流程创建房间，根据游戏进度业务上控制说话的玩家权限按顺序发言。
互动游戏场景一般参与人数有限，且会有频繁上下麦参与游戏的需求，适合使用麦上主播推拉 RTC 流 + 麦下观众拉 RTC 单流这种常规方案。游戏参与者可以随时上麦发言或者选择闭麦，直至角色死亡强制下麦观看或者退房。
说明：
该场景推荐：麦上主播推拉 RTC 流 + 麦下观众拉 RTC 单流方案。
互动游戏房通常包含本地游戏音效的播放，需要注意 AEC 处理及音量类型的选择。

方案配套产品

系统层级
产品名称
场景用途
接入层
提供低延时、高品质的多人语音实时互动直播解决方案，是语聊社交场景的基础底座能力。
接入层
提供基于群组功能的房间管理、麦位管理能力，实现直播间全员消息、公屏消息等富媒体消息收发，以及自定义信令等通信需要。
云端服务
提供实时音视频的旁路转推，以及加速媒体流的分发服务，此外还具备录制、鉴黄等附加能力。
云端服务
面向音视频媒体，提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务。
安全服务
提供音频审核服务，自动识别音频中出现的可能令人反感、不安全或不适宜内容，支持自定义黑名单热词，识别自定义类型的音频内容。
数据存储
提供音频录制文件、音频切片文件的存储服务。

中国站