场景介绍
语聊房是指以纯音频的方式进行线上互动社交的虚拟空间，房间内通常设有数个麦位，主播和连麦听众在麦上聊天，其他听众可以进入房间收听。不同类型的房间麦位数量和可容纳最大听众数量不同。腾讯云实时音视频 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 联合 T-Sec 天御，提供了实时的音视频内容识别与告警服务，使用实时音视频服务时，支持全局自动或手动发起策略进行音视频内容的识别和告警：
全局自动审核
客户可以指定审核策略和审核流类型，TRTC 云端自动完成应用下所有房间内的音视频内容审核，并通过回调把违规信息发送到客户指定的回调 URL，无需手动发起审核。该方式简单易用，省去了代码接入的工作量，但灵活性欠佳。
TRTC 与天御内容安全审核平台结合的实现原理如下图所示：直播内容安全通过“哑终端”的形式进入指定的 TRTC 房间，作为“观众”拉取音视频流，并针对拉取的音视频流进行内容审核，然后通过回调把违规信息发送到用户指定的 HTTP/HTTPS 服务上。
?
手动自定义审核
客户只需要调用天御音视频流接口即可实时检测音视频流中是否出现违规内容。音视频安全审核服务会通过回调把违规信息发送给客户指定的回调 URL。该方式更灵活、可定制化更强，但需要调用 REST API 发起审核任务，具有一定的接入复杂度。
?
关键业务逻辑
幽灵麦处理方案
幽灵麦又称炸麦或黑麦，是指不在麦上的用户能说话，并且其他用户能听到该麦下用户的声音。导致幽灵麦现象出现的根本原因，是业务的麦位状态与 TRTC 的用户角色状态不一致。该问题出现有以下几种可能的原因。
听众下麦，更新麦位列表，但因麦位信息回调未触达或被拦截，听众本地未执行 TRTC 切换观众角色及关闭麦克风操作，从而导致其处于麦下却还能发言。
听众下麦，更新麦位列表，收到麦位信息回调后，听众本地调用 TRTC 切换观众角色接口失败，从而导致其处于麦下却还能发言。
App 被暴力破解，导致 UserSig 被黑客截获，进而导致黑客能够以主播角色进入到 TRTC 房间中随意发言。
幽灵麦的检测及处理
我们可以通过检测幽灵麦，主动识别并及时处理幽灵麦。这里推荐使用服务端检测方案：实时主播列表对比检测。
方案原理：语聊房场景下用户角色分为主播和观众，只有主播角色能够上行本地音频，因此可以通过对比业务麦位列表和 TRTC 角色列表来检测幽灵麦。TRTC 提供了服务端的房间与媒体事件回调，您可通过监听进入房间、切换角色、退出房间等事件来维护一个当前房间的实时主播列表。然后将 TRTC 实时主播列表和业务全量麦位列表进行比对，即可轻松检测识别出幽灵麦，然后执行踢出房间或禁言等操作。
1. 实时音视频 TRTC 控制台支持自助配置回调信息，配置完成后即可接收事件回调通知。详情请参见 回调配置。
2. 接收并解析回调事件包体，关注 103/104/105 事件，统计当前房间实时在线的主播角色用户列表。详情请参见 事件回调。
{"EventGroupId": 1, #房间事件组"EventType": 103, #进入房间事件"CallbackTs": 1687679847972, #回调时间，单位毫秒"EventInfo": {"RoomId": "123456", #房间号"EventTs": 1687679847, #事件发生时间，单位秒"EventMsTs": 1687679847899, #事件发生时间，单位毫秒"UserId": "1a99b0a9", #用户名"Role": 20, #用户角色 20:主播; 21:观众"TerminalType": 2, #终端类型"UserType": 3, #用户类型"Reason": 1 #具体原因}}
{"EventGroupId": 1, #房间事件组"EventType": 104, #退出房间事件"CallbackTs": 1687679847972, #回调时间，单位毫秒"EventInfo": {"RoomId": "123456", #房间号"EventTs": 1687679847, #事件发生时间，单位秒"EventMsTs": 1687679847899, #事件发生时间，单位毫秒"UserId": "1a99b0a9", #用户名"Role": 20, #用户角色 20:主播; 21:观众"Reason": 1 #具体原因}}
{"EventGroupId": 1, #房间事件组"EventType": 105, #切换角色事件"CallbackTs": 1687679847972, #回调时间，单位毫秒"EventInfo": {"RoomId": "123456", #房间号"EventTs": 1687679847, #事件发生时间，单位秒"EventMsTs": 1687679847899, #事件发生时间，单位毫秒"UserId": "1a99b0a9", #用户名"Role": 20 #用户角色 20:主播; 21:观众}}
注意：
105-切换角色事件只会在用户进房后的角色变化中被触发，因此您还需根据103-进入房间事件中的初始角色信息来补充用户角色列表，以及根据104-退出房间事件来删减用户角色列表，从而使得维护的房间用户角色列表更加精准。
3. 以一定频率循环对比每个房间的业务麦位列表和 TRTC 实时主播列表，识别出幽灵麦并将其踢出房间 RemoveUser。
上下麦防卡顿方案
问题描述
由于移动设备系统机制的差异，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 上进行相应的声波展示。注意：
纯音频混流单流音量评估
?
纯音频混流评估单流音量的实现流程如上图所示，麦上主播需要监听音量大小回调，并判断本地音量和远端音量，将本地音量值及用户信息以 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 房间供麦下观众拉流观看。
互动游戏房
狼人杀、剧本杀、PIA 戏、真心话大冒险、你画我猜等，该场景下会按照游戏流程创建房间，根据游戏进度业务上控制说话的玩家权限按顺序发言。
互动游戏场景一般参与人数有限，且会有频繁上下麦参与游戏的需求，适合使用麦上主播推拉 RTC 流 + 麦下观众拉 RTC 单流这种常规方案。游戏参与者可以随时上麦发言或者选择闭麦，直至角色死亡强制下麦观看或者退房。
说明：
该场景推荐：麦上主播推拉 RTC 流 + 麦下观众拉 RTC 单流方案。
互动游戏房通常包含本地游戏音效的播放，需要注意 AEC 处理及音量类型的选择。
方案配套产品
系统层级 | 产品名称 | 场景用途 |
接入层 | 提供低延时、高品质的多人语音实时互动直播解决方案，是语聊社交场景的基础底座能力。 | |
接入层 | 提供基于群组功能的房间管理、麦位管理能力，实现直播间全员消息、公屏消息等富媒体消息收发，以及自定义信令等通信需要。 | |
云端服务 | 提供实时音视频的旁路转推，以及加速媒体流的分发服务，此外还具备录制、鉴黄等附加能力。 | |
云端服务 | 面向音视频媒体，提供制作上传、存储、转码、媒体处理、媒体 AI、加速分发播放、版权保护等一体化的高品质媒体服务。 | |
安全服务 | 提供音频审核服务，自动识别音频中出现的可能令人反感、不安全或不适宜内容，支持自定义黑名单热词，识别自定义类型的音频内容。 | |
数据存储 | 提供音频录制文件、音频切片文件的存储服务。 |
?
