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的音視頻流的傳輸。
轉自：https://blog.csdn.net/heqinghua217/article/details/52174541