修正 BigBlueButton 分組討論室音訊無法連線的問題：可靠的故障排除方法

當 BigBlueButton 的分組討論室音訊無法連接時，最關鍵的一點不是“我應該重啟哪個服務？”，而是“音頻故障是只在進入分組討論室後出現，還是在主會議中也會出現？” 這種區分能夠迅速將問題歸咎於房間切換問題，還是更廣泛的瀏覽器、網絡或媒體服務器問題。

本指南適用於 BigBlueButton 3.0，截至 2026 年 10 月，此版本仍是目前穩定的文件版本；BigBlueButton 4.0 的文件仍在開發中。 BigBlueButton 3.0 可透過會議 API 使用不同的音訊橋接器，包括bbb-webrtc-sfu[此處應填寫音訊橋接器名稱]、[此處應填寫音訊橋接器名稱]livekit和 [此處應填寫音訊橋接器名稱freeswitch]，因此請勿假設每個部署都使用相同的媒體路徑。官方的BigBlueButton API 參考文件記錄了這些橋接器選項，而BigBlueButton 故障排除指南仍然是伺服器端檢查的最佳起點。

好的解決方案應該是什麼樣的

修復成功不僅僅意味著麥克風圖示變為綠色。修復後，參與者應該能夠進入分組討論室，在幾秒鐘內加入音頻，聽到其他參與者的聲音，正常發言和被發言，正常靜音和取消靜音，並返回主會議室而不會陷入重新連接的循環。如果其他參與者都成功後，只有一個瀏覽器或網路仍然有問題，請停止變更伺服器，並將重點放在該用戶端環境上。

步驟 1：準確重現問題

在變更配置之前，請先使用一位主持人和一位參與者重現問題。確認參與者可以在主會議室加入音訊後，將其移至分組討論室，並詳細記錄發生的情況。 「正在連接音訊…」的提示始終無法完成，這與瀏覽器權限被拒絕、麥克風設備缺失或音訊連線成功但沒有聲音等情況不同。

如果主會議室可以正常訪問，但分組討論室無法訪問，請嘗試離開分組討論室，返回主會議室，然後再重新進入一次。一次性的客戶端狀態異常通常會在重新加入後消失。如果問題重複出現，請繼續執行以下檢查步驟，而不是重複刷新頁面。

成功檢查：參與者加入分組討論音訊一次，退出，再重新加入，即可再次收聽音訊。如果此方法穩定有效，則問題很可能是暫時性的。如果每次都出現相同的轉換失敗，則繼續下一步。

步驟 2：驗證瀏覽器麥克風權限和所選設備

BigBlueButton 的音訊是基於瀏覽器的 WebRTC，因此，如果使用者在進入小房間後才注意到麥克風權限被拒絕的問題，可能會誤以為是某個特定於該房間的問題。請開啟瀏覽器，檢查 BigBlueButton 主機名稱的權限設置，確保已允許麥克風存取。然後確認已選擇目標麥克風，並且沒有其他應用程式佔用該裝置。

請使用最新版本的 Firefox 或基於 Chromium 的瀏覽器進行測試。如果參與者在兩個最新版本的瀏覽器上都能重現相同的故障，則純粹的瀏覽器設定檔問題的可能性較小。如果在同一台機器和網路環境下，一個瀏覽器可以正常運作而另一個瀏覽器卻無法正常運作，請在修改 BigBlueButton 設定之前重設權限或使用全新的瀏覽器設定檔進行測試。

成功檢查：麥克風活動指示器有反應，主會議室音訊正常，並且同一瀏覽器可以加入分組討論室的音訊。如果主會議室仍然無法連接，則表示分組討論室並非真正的問題所在。

步驟 3：重啟任何程序之前，請檢查 BigBlueButton。

在伺服器上運行命令sudo bbb-conf --check。 BigBlueButton 官方文件建議將此作為首要的伺服器端診斷步驟，因為它能檢查核心元件是否已正確啟動，並找出常見的設定問題。請先查看「潛在問題」下列出的所有內容，而不是立即重啟所有服務。

同時運作sudo bbb-conf --status並檢查音訊橋接相關的 systemd 服務。 BigBlueButton 3.0 部署通常bbb-webrtc-sfu預設使用 FreeSWITCH 進行音訊傳輸，而 LiveKit 可以針對每個會議或伺服器啟用。如果整合測試通過audioBridge=livekit，請檢查 LiveKit 的問題，而不是假設瀏覽器音訊是透過傳統的 FreeSWITCH 路徑傳輸的。

官方設定檔文件建議將本地覆蓋設定放在以下位置/etc/bigbluebutton，這樣軟體包升級就不會覆蓋它們。

成功檢查： bbb-conf --check未發現任何無法解釋的錯誤，音訊橋接服務正在運行，且新的測試會議運作正常。如果服務運作狀況良好，但某個網路仍然出現故障，則應檢查 ICE、NAT 和 TURN。

步驟 4：診斷 ICE、NAT、防火牆和 TURN 問題

WebRTC 必須在瀏覽器和 BigBlueButton 媒體基礎架構之間建立可用的媒體路徑。如果訊號成功但媒體找不到有效的網路路徑，使用者可能會遇到 ICE 協商失敗或在加入音訊時卡住。 BigBlueButton 的防火牆文件特別指出，錯誤的外部 IP 通告和被封鎖的 UDP 是常見原因。

在 Firefox 瀏覽器中，about:webrtc此功能很有用，因為它會顯示 ICE 候選位址和連線狀態。如果您發現伺服器通告的是內部位址，而預期的是外部位址，請檢查 NAT 和 announce-IP 設定。 BigBlueButton 的防火牆設定指南解釋了當伺服器位於 NAT 之後時，mediasoup 應該如何通告公網位址。

如果故障集中在限制性較強的企業、學校、飯店或 VPN 網路中，請設定 TURN 伺服器。 BigBlueButton 的安裝文件建議對位於限制性防火牆後的使用者使用 TURN。一個有效的驗證方法是讓同一用戶在其他網路（例如手機熱點）上進行測試。如果熱點連接正常而受管網路故障，則有力地證明網路路徑（而非會議室邏輯）是瓶頸所在。

不要盲目地從舊論壇貼文複製大範圍的連接埠號碼。請使用與您已安裝的 BigBlueButton 版本和部署拓撲相​​符的連接埠和橋接要求。舊版 FreeSWITCH 或 SIP.js 的相關建議可能不適用於目前的 3.0 版本。

成功檢查： ICE 達到連線狀態，預期的公共或中繼候選連接埠出現，受影響的使用者可以從先前失敗的網路加入分割畫面音訊。如果該使用者仍然失敗，而同一網路上的其他使用者成功，則傳回裝置/瀏覽器檢查。

步驟五：比較配置的音訊橋接並重新測試房間過渡效果

如果主會議室音訊正常，但許多使用者的分組討論音訊持續出現故障，請確認會議實際使用的音訊橋接器。 BigBlueButton 3.0 公開了audioBridgecreate 參數，其有效值包括bbb-webrtc-sfu`<command>`、livekit`<command>` 和 `<command> freeswitch`。整合可以覆寫每個會議的伺服器預設值，因此您檢查的配置可能與發生故障的會話所使用的橋接器不符。

建立一個全新的測試會議，不進行任何自訂會議設置，然後重複相同的主會議室 → 分組討論室 → 主會議室的順序。如果全新建立的會議正常，但由您的 LMS 或自訂應用程式建立的會議失敗，請檢查該整合發送的 API 參數。如果兩者都失敗，則問題很可能出在伺服器媒體配置或特定版本缺陷。

配置變更後，僅在需要時重新啟動 BigBlueButton sudo bbb-conf --restart，然後sudo bbb-conf --check再次執行。避免在測試前疊加多個更改；一次只更改一個，這樣才能確定哪個調整真正解決了問題。

成功檢查：兩位參與者可以在分組討論室中互相交談，返回主會議室後，再次進入分組討論室且連接無中斷。在確認問題已解決之前，至少需要從一個外部網路重複此操作。

何時改變策略

如果在檢查瀏覽器權限、伺服器運作狀況、ICE/TURN 和橋接選擇後問題仍然存在，請收集證據而不是繼續猜測。記錄 BigBlueButton 版本、瀏覽器和作業系統版本、問題是否在公開的 BigBlueButton 演示環境中重現、命令的輸出sudo bbb-conf --check、會議的音訊橋接設定以及任何相關的瀏覽器 WebRTC 診斷資訊。 BigBlueButton 的「取得協助」指南明確指出，在排查音訊或視訊故障時，需要提供此類網路和環境資訊。

截至 2026 年 10 月，BigBlueButton 3.0 的文件版本仍然穩定，GitHub 上會持續發布 3.0 版本，而 4.0 版本的文件目前處於開發階段。這一點很重要，因為 BigBlueButton 4.0 將預設媒體框架更改為 LiveKit，所以針對 4.0 版本的建議不應直接應用於 3.0 版本的伺服器。在執行任何版本相關的操作之前，請務必查看BigBlueButton 的官方發布頁面。

最終核查清單

• 受影響的參與者的主房間音訊已連接。
• 麥克風權限已授予，目標裝置顯示輸入活動。
• bbb-conf --check沒有出現無法解釋的媒體服務錯誤。
• ICE 達到連線狀態；限制性網路在需要時具有可用的 TURN 路徑。
• 會議使用的音訊橋接器正是您認為它使用的。
• 兩位使用者可以在分組討論室中互相聽到對方的聲音，然後返回主房間並成功重新加入。

如果六項檢查全部反覆通過，則說明維修產生了重要的結果：在房間切換時音訊穩定，而不僅僅是臨時的綠色麥克風圖示。