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