視頻通話，你也能開發

我們可以發現目前保險行業會通過現場定損的方式處理車險理賠，這種方式需要派定損員驅車前往事發地點進行損傷判定，每次的出車成本非常高。

如果要采用遠程電話解決，保險公司無法簡單通過語音溝通確認損傷程度，而且照片采集很難規避定車騙保的可能，所以**實時的視頻通話**可以解決這種問題。

小程序中 <live-pusher> 和 <live-player> 兩個組件 ，都有一個叫做 RTC 的模式，通過這種模式，可以在小程序實現實時視頻通話。

 <live-pusher> 和 <live-player> 兩個組件的 RTC 模式，主要是實現端到端能夠以很低的時延傳輸音視頻數據。

這樣一來，視頻通話的雙方 A 和 B 就可以各自拉通一路方向相反的音視頻鏈路，從而實現 A 和 B 之間的雙向低延時的音視頻數據傳輸。與此同時，RTC 模式還會開啟內置的 AEC (回聲抑制)，避免通話的雙方會因為本地麥克風對播放器的聲音進行二次采集而引起的回聲問題。

小程序的 RTC 模式解決了雙向或者多人實時音視頻通話在終端所需要的各項技術組件，但是通話線路本身可能也會引入很高的延時，所以要確保視頻通話的 A 和 B 雙方所使用的 rtmp 線路要有很低的時延。

如果是自己搭建rtmp服務器（例如 nginx-rtmp 服務），請檢查 nginx-rtmp 的服務端參數設置，確保不要在服務器端引入太多音視頻數據緩存。

如果是使用騰訊云的超低延時線路，那么要注意給 RTC 模式下的 <live-player> 傳遞帶防盜鏈簽名的播放 url。

小程序的 RTC 模式主要用于視頻通話，由于這類場景以交流為重，所以小程序會有限保證聲音的流暢，相應的，視頻數據的發送會被放在第二優先級上。因此，如果網絡有波動，小程序會舍棄尚未發送出去的視頻數據，優先保障音頻數據的發送。

所以如果在 RTC 模式下，建議不要給  <live-pusher> 設置太高的畫質，也就是不要將 min-bitrate 和 max-bitrate 設置的太大，一般而言，推薦 min-bitrate 設置為 300kbps， max-bitrate 設置為 800kbps，即可滿足常規視頻通話的需求。