把房間擴充成網路研討會工作流程
為講者提供互動會話,同時為更大範圍的觀眾保留一個更乾淨的觀看層。
直接在瀏覽器中進行視訊通話、主持式網路研討會、支援空間與互動直播。區分發言者與觀眾、控制加入權限、錄製重要會議,並將同一空間延伸到更完整的直播或重播工作流程。
接收直播訊號、路由、保護並交付直播與隨選視訊;可透過產品介面或 API,在 AWS 雲端或自有環境運作。

讓主動發言者和被動觀眾共用同一活動介面,而不必把每位參加者都強行塞進同一種參與模式。
為講者提供互動會話,同時為更大範圍的觀眾保留一個更乾淨的觀看層。
決定誰可以加入、誰只能觀看,以及房間如何暴露出去,而不是讓這些規則只存在於臨時會議連結中。
使用房間聊天讓討論與即時通話保持同步,並在簡報、檢視或現場示範時允許獲准的參與者分享螢幕。
用同一套房間模型覆蓋支援、監看、網路研討會、內部評審和面向公眾的互動會話。
在瀏覽器中提供受控的來賓或網路研討會加入流程,無需講者或受邀參與者安裝特定平台的應用程式。
當會話需要超出房間參與者本身時,把它連線到觀眾播放層或其他傳遞層。
為了回放或審計保留會話,而不需要把即時房間重構成另一套單獨的錄製工作流程。
每項支援行為旁都提供實際驗收檢查。最終以已安裝的 Callaba 介面以及真實的訊號源、目的端和基礎設施設定為準。
| 功能 | 支援的行為 | 驗收檢查 |
|---|---|---|
| 讓來賓透過瀏覽器加入 | 在瀏覽器中提供受控的來賓或網路研討會加入流程,無需講者或受邀參與者安裝特定平台的應用程式。 | 設計目標是瀏覽器優先參與,這樣營運人員、講者和嘉賓的加入流程都可以保持輕量。 |
| 在需要時區分參與者與觀眾 | 讓主動發言者和被動觀眾共用同一活動介面,而不必把每位參加者都強行塞進同一種參與模式。 | 會。視訊通話在傳送和接收媒體時會使用行動數據或寬頻。在 1 Mbps 下,單向一小時約為 0.45 GB;傳送自己的視訊和接收其他參與者的視訊,都可能計入連線總用量。 |
| 把房間擴充成網路研討會工作流程 | 為講者提供互動會話,同時為更大範圍的觀眾保留一個更乾淨的觀看層。 | 可以。對於網路研討會、監看場景,或任何不希望所有人都成為活躍房間參與者的場景,這通常是正確做法。 |
| 透過房間聊天與螢幕分享協作 | 使用房間聊天讓討論與即時通話保持同步,並在簡報、檢視或現場示範時允許獲准的參與者分享螢幕。 | 請依位元率估算,而非採用固定的單次通話數字:單向以 1–5 Mbps 傳輸一小時約為 0.45–2.25 GB。實際用量取決於解析度、畫格率、編碼器、位元率、通話時間,以及裝置傳送或接收多少參與者視訊。 |
| 把房間送入播放或外部傳遞層 | 當會話需要超出房間參與者本身時,把它連線到觀眾播放層或其他傳遞層。 | 可以。對於網路研討會、監看場景,或任何不希望所有人都成為活躍房間參與者的場景,這通常是正確做法。 |
| 不改變房間邏輯也能錄製會話 | 為了回放或審計保留會話,而不需要把即時房間重構成另一套單獨的錄製工作流程。 | 會。較低的解析度、畫格率或位元率通常用得更少;較長的通話和同時接收多位活躍參與者視訊的版面則用得更多。編碼器選擇和自適應位元率也會改變結果,請查看應用程式選定的品質與您的網路方案,以取得確切數字。 |
本頁說明產品的能力範圍。以下指南會告訴您要開啟哪些控制項、接著連接哪個模組,以及如何確認工作流程已經就緒。
接收直播訊號、路由、保護並交付直播與隨選視訊;可透過產品介面或 API,在 AWS 雲端或自有環境運作。
按量付費的雲端方案適合希望快速上線瀏覽器通話和網路研討會的團隊:部署快、低延遲、基礎架構可靠,並具備託管擴充能力。
在 AWS 上部署 Callaba無限方案適合正在增長的中大型組織:既不受打包方案限制,又能繼續完全掌控自己的資料與基礎架構。
安裝自託管 Callaba當房間建立、觀眾播放和錄製被當作獨立模組來控制時,即時房間會更容易管理。當通話或網路研討會需要成為你自己的產品、活動棧或操作員工作流程的一部分時,就應該使用 API。
請依位元率估算,而非採用固定的單次通話數字:單向以 1–5 Mbps 傳輸一小時約為 0.45–2.25 GB。實際用量取決於解析度、畫格率、編碼器、位元率、通話時間,以及裝置傳送或接收多少參與者視訊。
會。視訊通話在傳送和接收媒體時會使用行動數據或寬頻。在 1 Mbps 下,單向一小時約為 0.45 GB;傳送自己的視訊和接收其他參與者的視訊,都可能計入連線總用量。
會。較低的解析度、畫格率或位元率通常用得更少;較長的通話和同時接收多位活躍參與者視訊的版面則用得更多。編碼器選擇和自適應位元率也會改變結果,請查看應用程式選定的品質與您的網路方案,以取得確切數字。
可以。對於網路研討會、監看場景,或任何不希望所有人都成為活躍房間參與者的場景,這通常是正確做法。
設計目標是瀏覽器優先參與,這樣營運人員、講者和嘉賓的加入流程都可以保持輕量。
直接在瀏覽器中進行視訊通話、主持式網路研討會、支援空間與互動直播。區分發言者與觀眾、控制加入權限、錄製重要會議,並將同一空間延伸到更完整的直播或重播工作流程。