基於 <live-pusher> 和 <live-player> 所構建的雙人視頻通話功能。
技術指標
- 通訊延遲：300ms - 800ms
- 底層協議：基於 UDP 協議構建，並遵循 RTMP 標准對音視頻數據進行切分和封裝，支持丟包恢復和網絡自適應。
- 安全加密：每次連接都獨立啟用一對全新的非對稱加密密鑰，整個通訊過程無法監聽和篡改。
- 支持錄制：如果需要可以在雲端進行錄制，適用於在線客服、金融開戶等商用音視頻解決方案，支持私有化部署。
內部原理
通訊的雙方 各自創建一個 RTC 模式的 <live-pusher> 和 <live-player> ，然后URL 給對方。
流程
- step1：首先A 跟業務服務器溝通，獲取 push-url-A 和低延時的 play-url-A，服務器分配 URL 的方法參考 DOC。
- step2：A 創建一個 RTC 模式的 標簽，指定 url 為 step1 中獲得的 push-url-A，並通過 bindstatechange 屬性綁定一個 javascript 函數（比如叫 onPushEvent）。
- step3：A 這邊需要一些時間啟動推流，推流開始以后， <live-pusher>會通過 onPushEvent 的 PUSH_EVT_PUSH_BEGIN（1002）事件通知給 A， 此時 A 可以向 B 發起通話請求，請求中可以攜帶 play-url-A。
- step4：B 需要等待 UI 界面上的確認，如果 B 確認接通，接下來要做的就是創建一個 RTC 模式的 <live-player> ，並指定 src 為 play-url-A。
- step5：B 此時還要跟業務服務器溝通，獲取 push-url-B 和低延時的 play-url-B，並創建一個 RTC 模式的 <live-pusher> 標簽，指定 url 為 push-url-B，並通過 bindstatechange 屬性綁定一個 javascript 函數（比如叫 onPushEvent）。
- step6：B 此時需要一些時間啟動推流，推流開始以后， <live-pusher> 會通過 onPushEvent 的 PUSH_EVT_PUSH_BEGIN（1002）事件通知給 B，之后 B 可以向 A 響應通話請求，請求中可以攜帶 play-url-B。
- step7: A 此時要做的就是創建一個 RTC 模式的<live-player> ，並指定 src 為 play-url-B。
在真實的場景中，我們需要面對的業務邏輯遠比簡單的把 A 和 B 連接起來要復雜。
- 房間管理
以金融開戶和保險定損為例，如果 A 端使用的是小程序，那么真正的 B 端一般情況下會是企業的客服職員（通常都是一個人），所以這里就牽扯到要給用戶分配客服的邏輯。同時，如果目前所有的客服都是忙碌的，那就需要有排隊等待的邏輯。
所以，真實場景下的邏輯是這樣的： 客服 MM 在進入工作崗位后即創建好一個屬於自己的“房間”，這個房間有三種狀態：BUSY(占線)、IDLE(空閑) 以及 CLOSE(關閉)。處於 BUSY 狀態的房間表示對應的客服正在跟用戶進行溝通， IDLE 表示可以分配給新進來的呼叫，CLOSE 則表示客服 MM 已經下班了。
- 消息系統
在 A 和 B 之間搭建 IM 消息系統也是必不可少的，一方面，如果 A 和 B 中某一方網絡發生異常，那么文本消息可以用極低的帶寬維持最基本的消息通訊；另一方面，消息系統對於事件的傳遞要比音視頻通道更加可靠。
現代實時音視頻系統一般都有數據通道和信令通道兩個傳輸通道，這樣設計的原因是音視頻通道並不適合用於傳輸信令，比如 B 端的 通知音視頻數據沒有了，可能原因是 A 已經掛斷，但也有可能是 A 的網絡出現了長時間的波動。而基於消息系統的“掛斷事件”則不需要考慮這種不確定性問題。