语聊房实现流程(语音聊天室怎么创建)

在上一篇文章中，我们介绍了语聊房的一些基本概念和应用场景，本篇我们来看下语聊房方案架构和具体的实现流程。

即构科技语聊房是指在线语音连麦虚拟房间。在本方案中，每个房间设有若干个麦位，主播在麦上聊天，同时向房间内其他用户推流，其他听众可以进入房间收听。主播也可邀请听众上麦互动，但是听众之间不能互相邀请上麦进行互动。

ZEGO 语聊房解决方案预设 5 个麦位（包括主播麦位），听众人数在客户端侧没有做限制（但会受限于 ZEGO Express SDK 和 ZIM SDK）。

语聊房方案架构

本方案房间内业务的整体架构如下图所示。由于业务后台仅管理房间列表，不涉及房间内业务，因此没有在下图中体现。房间内通过 ZIM SDK 进行消息的可靠传输，实现麦位管理，通过 ZEGO Express SDK 实现推拉流管理。

在语聊房内进行麦位管理，能够确保用户根据自身角色有序展开活动。本解决方案是通过调用 ZIM SDK 接口实现麦位管理，主要包括发起连麦、结束连麦以及麦位列表同步。

语聊房内不同角色的行为如下表所示：

角色	行为
主播	负责语聊房房间的创建和销毁。主播在创建房间后自动上麦，且无法下麦。本方案的麦位更新逻辑对主播有强依赖，因此，只有主播在良好的网络环境下，玩家才能有相对良好的游戏体验。
麦下听众	所有用户（除主播）在刚进入房间均为此角色。麦下听众只能听麦上用户的语音聊天，不能参与，如需加入聊天需要上麦。
麦上听众	当麦下听众向主播申请上麦，或被主播邀请上麦且同意后，即成为麦上听众。
麦上用户	包括主播和麦上听众。麦上用户可互相进行语音聊天。

发起连麦主要使用了 ZIM SDK 的呼叫邀请接口，存在两种使用情况，即一方发起连麦邀请，一方接受或拒绝，下文从听众视角展示相关接口调用顺序，但主播方也遵循同样时序：

麦上听众通过修改房间属性从而修改自己的麦位信息，其他用户在监听到房间属性变更后执行更新操作。基本时序图如下：

不论是麦上听众主动下麦，还是主播将麦上听众踢下麦位，都是采用相同逻辑。

语聊房使用 ZIM SDK 提供的房间属性功能实现麦位数据的同步。房间属性是一个以 key-value 为存储方式的对象，最多能设置 10 个属性。每个麦位占用一个键值对，key 为麦位序号，value 为麦位数据。

房间属性由主播负责更新，听众只需接收房间属性更新通知，用于变更麦位信息。不过，麦上听众主动结束连麦的时候，由该用户负责更新房间属性。这是为了防止主播在断网情况下听众无法下麦。

为了实现成本与体验效果的平衡，本方案各角色的推拉流策略如下表所示：

角色	推拉流
主播	推一路 RTC 单流，拉取其他麦上听众的 RTC 单流，并负责发起混流任务。
麦上听众	推一路 RTC 单流，拉取其他麦上听众和主播的 RTC 单流。
麦下听众	不推流，仅拉取 CDN 混流，不从 RTC 服务器拉单流。