關於webrtc視頻會議的解決方案

以個人經驗來看視頻會議分兩種模式：網狀模型，星型

一、網狀模型

　所謂的網狀模型就是參加會議的人中每兩我的創建一個點對點的鏈接。

　　好比：一個會議室有三我的A，B，C 基於網絡模型就須要這樣：

　　　　　　一、A和B創建鏈接
　　　　　　二、B和C創建鏈接
　　　　　　三、A和C創建鏈接

　　這樣一個三我的的會議就須要創建三條鏈接 計算方法：3*(3-1)/2

　　同理：4我的的會議須要創建的鏈接數4*(4-1)/2 = 6 ，5我的的會議就須要 5*(5-1)/2 = 10

　　適用場景：這種模型只適合3-4我的參加會議的狀況，由於參加會議的人每增長一個，就會增長n-1個鏈接（n表示參加會議的人數），這樣終端的負載會急劇增長。

　　　　　　　note：　會議人數每增長一我的，每一個終端就會增長一個連接，n我的參加的會議，每一個終端就須要創建n-1個鏈接

二、星型模型

　　星型模型又分爲：經過服務器合成轉發和經過某一個終端轉發兩種狀況。

　　a 、 在3我的的時候也這個使用以下的模型：

　　　　　　　一、A，B，C參加會議

　　　　　　　二、A 和 B 創建鏈接

　　　　　　　三、B 和 C 創建鏈接

　　　　　　   四、B 轉發A的音視頻給C，B轉發C的音視頻給A

　　　　這種狀況在B的狀況的設備性能較高，而A和C的性能較弱的狀況下使用，以B爲橋樑實現3方通話，這樣減輕了服務器的負擔。　適用場景：這種模型只適合3我的的會議。

　　b、經過服務器合成轉發

　　　　每個參加會議的人都把本身採集到的音視頻發到服務器端，通過服務器的合成以後，分發給每個參加會議的人。

　　　　以下模型：

　　　　　　一、A，B，C參加會議

　　　　　　二、A，B，C分別和服務器創建鏈接

　　　　　　三、A，B，C把採集到的視音頻發往服務器

　　　　　　四、服務器把A，B，C發過的音視頻合成以後發到A，B，C

　　　　　　這樣不管多少人蔘加會議，每個與會的終端都只創建了一個鏈接，把負載放在服務器端，適用場景：適合4我的以上的會議

　　　　這裏面有問題：不要讓服務器把終端發出的數據再發送回來，如服務器不該該把A發送到服務器的音視頻再發送給A，由於那樣作的話A就會聽（看）到本身的聲音（視頻），那樣作是不合理的

不合理的地方請廣大網友指正：243203950