语音聊天基本是社交软件必备的功能，语音相比文字图片更丰富，比视频又更简便，是天然的社交工具。除了单纯的1对1语音或视频聊天，在实时音视频技术支持下，很多 APP 已经延伸出非常多的玩法。

目前比较火的语音聊天室又分为语音电台、语音游戏、私人聊天房、多人语聊房、KTV 语聊房等细分的场景，延伸出去还有更多的形态。

语音聊天室怎么实现呢？

通常，观众上麦请求、主播通过上麦申请等一系列操作都是通过消息服务来完成的。任意模式下，进入房间后可以允许听众上麦，用户发出上麦申请，房主同意后，听众可上麦，角色由听众变为了主播。主播要遵循房间模式来实现自己的功能。

会议属性：在语音聊天室 Demo 中，抢麦、主持、自由麦等模式均是通过会议属性实现的，包括各个模式中的上麦者，也是会议属性实现的。当会议属性发生更改时，会广播给房间内所有人。

已在语聊房间的观众通过 IMServer 发送 message 向房主发起上麦请求，房主同意后，通过 MediaServer 改变会议属性，将观众上麦成为主播，成为主播后就能说话进行推流。房间内其他的人都能收到推流通知并进行订阅。

当主播在麦上时，如果想要下麦，同样通过 IMServer 向房主发送 message 发起下麦请求，这里无需房主同意，默认直接下麦。若房主主动将主播下麦，则没有之前这步，房主直接通过 MediaServer 改变会议属性，将主播下麦成为观众，主播成为观众后就停止推流。房主调用 AppServer 销毁房间，进而销毁conference、chatroom。

假设ABC进入房间101，服务器会维护一个房间信息表记录每个房间的用户信息。当某个用户说话的时候，客户端将采集到的语音数据发给服务器，服务器就把语音数据发给101的每一个用户。客户端收到语音数据就可以播放出来。

但是实际生产中肯定不会使用这么简单的架构，为什么呢？首先一个服务器实现所有功能是不可行的，因为一方面服务器的性能不可能满足，另一方面大型软件的复杂度和维护成本是非常高的，因此软件工程一直都强调高内聚低耦合，把功能拆解可以使系统更容易维护。

拆解有两个方向，一个是按功能拆分，即把不同功能放到不同服务器完成；另一种是平行扩展，即相同功能的服务分布到多台机器上。

目录服务器是用户访问系统的地图，用户通过它可以找到要连接的服务器的IP和端口。语音服务器是处理语音数据上传和转发的服务。房间服务器维护房间-语音服务器-用户的映射关系。一个房间的用户可能分布在多个语音服务器，一个语音服务器上可以有多个房间的用户。