webRTc+ websocket實現多人視訊通話，目前此demo只支援crome瀏覽器，

版本僅僅支援：ChromeStandalone_46.0.2490.80_Setup.1445829883

tomcat要8，jdk要1.7,不需要資料庫

192.168.1.118是我的ip地址，在所有jsp頁面中，要修改成自己的伺服器的ip地址

多人視訊通話啟動後訪問地址：

http://192.168.1.118:8080/WebRTC/manyrtcclientA

http://192.168.1.118:8080/WebRTC/manyrtcclientC

最後開啟http://192.168.1.118:8080/WebRTC/manyrtcclientB

因為B是觸發者，B會先發訊息給A和C

一對一視訊通話訪問地址

http://192.168.1.118:8080/WebRTC/rtcclientA

之後訪問：http://192.168.1.118:8080/WebRTC/rtcclientB

websocket測試地址：

http://192.168.1.118:8080/WebRTC/clientA

http://192.168.1.118:8080/WebRTC/clientB

沒有順序，可以直接測試

csdn下載原始碼下載地址：http://download.csdn.net/detail/heqinghua217/9600085

看程式碼之前，建議大家看看webrtc通訊原理，來自：http://www.cnblogs.com/fangkm/p/4364553.html

這段文字和圖片雖然很簡短，但是很清楚，要多看幾遍，反正我看了很多遍

--這篇文章有些文字也是很好的參考

http://www.cnblogs.com/lingyunhu/p/4058182.html?utm_source=tuicool

一對一的通訊網上有demo，其實很簡單，關鍵是多人視訊通訊，我也是想了很久，看了這個圖，自己也在本子上畫了幾個圖，

我多人視訊通話思路：饒了很多彎路，最後終於可以了，以下是我的心裡路程：

視訊通話websokit和webRTC視訊監控端除錯，發現問題。
C端資料可以接收到，但是無法顯示。


解決1：後面考慮C必須也要和AB建立連結，於是修改成C也傳送響應訊息給A和B結果，導致A和B通訊混亂，
解決2、考慮可能伺服器只是解決了信令服務的訊息傳送，但是視訊端的服務stun並沒有區分接受到的是誰的訊息，考慮client建立多個視訊連結connection。然後每一端都和相應的peerconnction通訊。這裡訊息是固定，需要拿到訊息，重新編輯，加入訊息傳送人，否則無法知道用哪個peerconnection保持通訊。
測試1、懷疑是未建立連結導致，測試，A和B的正常通訊，吧A的訊息不傳入給B，A是否可以看到B的視訊？修改程式碼後測試，發現看不到，所以必須要建立連結
測試2、先測試A和B通訊的情況下，建立多個peerconnection，建立連結，轉發訊息，看看是否可行？因為擔心，candidate訊息格式不允許修改，怕stun服務無法識別，發現不可行
測試3、A和B通訊建立後，可以繼續傳送文字訊息，不會斷開
疑問1、還是需要先確定A和B通訊，一共發起幾次請求，請求內容分別是什麼，否則不是僅僅修
改canidate就可以解決的。分析資料後發現
（場景：A和B通訊，B請求A的過程：
1、B先發送offer和sdp（音訊相關引數）給A，結束後繼續傳送candidate(ip和埠以及是video還是audio)給A，這裡video和audio傳送了4遍
2、A接收到請求，傳送answer和sdp，結束後繼續傳送candidate的audio和video也是多遍給B
然後再發送一個offer，sdp給B
3、B接收到資訊，傳送一個answer，sdp給A，最後連線成功後，websoket就沒有再傳遞訊息，感覺是他們自己直接通訊了。
有點類似，我打電話給你（不確定你是誰），先發個簡訊問確認下你是誰？（當然要把自己的一些基本資訊傳送過去，否則別人也不理我） ，對方看到短息，發現是朋友，然後回覆我，他張三，性別男、年齡88，然後張三回覆可以打電話了，，我收到資訊，打電話過去。

1、建立多個peerconnection之後，B和A之間的通訊也顯示不
了，B給A傳送請求，A可以收到的請求，但是A無法響應給B


2、懷疑多個peerconncetion會發送多條資料給別人，如B到A，B會發多條給A，那麼A的兩個訊息沖斷，導致混亂。原來這是考慮接受到訊息，用傳送方來判斷是B發過來的，用connection接受，是C發過來的用connect2接受，但是A也有兩個peerconnection，它會發送兩邊訊息給B和C，其實應該是A的connetion傳送給B，connection1傳送給C，然後B和C接受到訊息，判斷是來自A還是B。
最後方法可行

上述序列中，WebRTC並不提供Stun伺服器和Signal伺服器，伺服器端需要自己實現。Stun伺服器可以用google提供的實現stun協議的測試伺服器（stun:stun.l.google.com:19302），Signal伺服器則完全需要自己實現了，它需要在ClientA和ClientB之間傳送彼此的SDP資訊和candidate資訊，ClientA和ClientB通過這些資訊建立P2P連線來傳送音視訊資料。由於網路環境的複雜性，並不是所有的客戶端之間都能夠建立P2P連線，這種情況下就需要有個relay伺服器做音視訊資料的中轉，本文字著原始碼剖析的態度，這種情況就不考慮了。這裡說明一下， stun/turn、relay伺服器的實現在WebRTC原始碼中都有示例，真是個名副其實的大寶庫。

上述序列中，標註的場景是ClientA向ClientB發起對聊請求，呼叫描述如下：

• ClientA首先建立PeerConnection物件，然後開啟本地音視訊裝置，將音視訊資料封裝成MediaStream新增到PeerConnection中。
• ClientA呼叫PeerConnection的CreateOffer方法建立一個用於offer的SDP物件，SDP物件中儲存當前音視訊的相關引數。ClientA通過PeerConnection的SetLocalDescription方法將該SDP物件儲存起來，並通過Signal伺服器傳送給ClientB。
• ClientB接收到ClientA傳送過的offer SDP物件，通過PeerConnection的SetRemoteDescription方法將其儲存起來，並呼叫PeerConnection的CreateAnswer方法建立一個應答的SDP物件，通過PeerConnection的SetLocalDescription的方法儲存該應答SDP物件並將它通過Signal伺服器傳送給ClientA。
• ClientA接收到ClientB傳送過來的應答SDP物件，將其通過PeerConnection的SetRemoteDescription方法儲存起來。
• 在SDP資訊的offer/answer流程中，ClientA和ClientB已經根據SDP資訊建立好相應的音訊Channel和視訊Channel並開啟Candidate資料的收集，Candidate資料可以簡單地理解成Client端的IP地址資訊（本地IP地址、公網IP地址、Relay服務端分配的地址）。
• 當ClientA收集到Candidate資訊後，PeerConnection會通過OnIceCandidate介面給ClientA傳送通知，ClientA將收到的Candidate資訊通過Signal伺服器傳送給ClientB，ClientB通過PeerConnection的AddIceCandidate方法儲存起來。同樣的操作ClientB對ClientA再來一次。
• 這樣ClientA和ClientB就已經建立了音視訊傳輸的P2P通道，ClientB接收到ClientA傳送過來的音視訊流，會通過PeerConnection的OnAddStream回撥介面返回一個標識ClientA端音視訊流的MediaStream物件，在ClientB端渲染出來即可。同樣操作也適應ClientB到ClientA的音視訊流的傳輸。