語音聊天基本是社交軟體必備的功能，語音相比文字圖片更豐富，比視頻又更簡便，是天然的社交工具。除了單純的1對1語音或視頻聊天，在實時音視頻技術支持下，很多 APP 已經延伸出非常多的玩法。
目前比較火的語音聊天室又分為語音電臺、語音遊戲、私人聊天房、多人語聊房、KTV 語聊房等細分的場景，延伸出去還有更多的形態。
語音聊天室怎麼實現呢？
實現語音連麥
通常，觀眾上麥請求、主播通過上麥申請等一系列操作都是通過消息服務來完成的。任意模式下，進入房間後可以允許聽眾上麥，用戶發出上麥申請，房主同意後，聽眾可上麥，角色由聽眾變為了主播。主播要遵循房間模式來實現自己的功能。
會議屬性：在語音聊天室 Demo 中，搶麥、主持、自由麥等模式均是通過會議屬性實現的，包括各個模式中的上麥者，也是會議屬性實現的。當會議屬性發生更改時，會廣播給房間內所有人。
上麥
已在語聊房間的觀眾通過 IMServer 發送 message 向房主發起上麥請求，房主同意後，通過 MediaServer 改變會議屬性，將觀眾上麥成為主播，成為主播後就能說話進行推流。房間內其他的人都能收到推流通知並進行訂閱。
下麥、銷毀房間
當主播在麥上時，如果想要下麥，同樣通過 IMServer 向房主發送 message 發起下麥請求，這裡無需房主同意，默認直接下麥。若房主主動將主播下麥，則沒有之前這步，房主直接通過 MediaServer 改變會議屬性，將主播下麥成為觀眾，主播成為觀眾後就停止推流。房主調用 AppServer 銷毀房間，進而銷毀conference、chatroom。
假設ABC進入房間101，伺服器會維護一個房間信息表記錄每個房間的用戶信息。當某個用戶說話的時候，客戶端將採集到的語音數據發給伺服器，伺服器就把語音數據發給101的每一個用戶。客戶端收到語音數據就可以播放出來。
但是實際生產中肯定不會使用這麼簡單的架構，為什麼呢？首先一個伺服器實現所有功能是不可行的，因為一方面伺服器的性能不可能滿足，另一方面大型軟體的複雜度和維護成本是非常高的，因此軟體工程一直都強調高內聚低耦合，把功能拆解可以使系統更容易維護。
拆解有兩個方向，一個是按功能拆分，即把不同功能放到不同伺服器完成；另一種是平行擴展，即相同功能的服務分布到多臺機器上。
目錄伺服器是用戶訪問系統的地圖，用戶通過它可以找到要連接的伺服器的IP和埠。語音伺服器是處理語音數據上傳和轉發的服務。房間伺服器維護房間-語音伺服器-用戶的映射關係。一個房間的用戶可能分布在多個語音伺服器，一個語音伺服器上可以有多個房間的用戶。