基于mediasoup的多方通话研究（一）
mediasoup简介
mediasoup的特性
安装mediasoup-demo
本地运行Demo
server的配置文件
mediasoup的原理
扩展与展望
总结
mediasoup简介
webrtc中多流的实现越来越简单，也越来越规范高效化，从planB-->到unifiedPlan，不过做的早的一些视频会议还是基于plan A做的，也是老版本的webrtc版本，planB兼容planA，不过后边的趋势一定是unifiedplan，这边刚好看到对这三个SDP多流标准的说明的博文，就记录下，转载过来了，感谢原博主。本文转自https://blog.csdn.net/gyj072001/article/details/80406106
Plan A
一个PeerConnection一路媒体流。这里编辑文章摘要...
webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁，重复的内容我不再赘述。对我来讲，webrtc的概念可以有三个角度去解释：
（1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去；
（2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS；
（3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。
对webrtc的理解与使用，我认为有三个境界：
最近一段时间，工作内容也是在迁移项目，加上之前有读者要源码，所以打算重构下。
这个项目是之前因为工作中的调研（项目最后因为难度太大放弃了 == ），需要了解关于 WebRTC H5 + Java 如何实现实现网页端的视频聊天，而编写的sample。
原理就是 WebRTC + WebSocket。使用 WebRTC 采集视频看，通过 WebSocket 截取页面的视频流转发到后台，再经过后台分发到其他的客户端网页。
项目本身使用 Spring，打成 war，直接部署到 Tomcat 的方式运行。而写这个sample的时候，MyEcplise 还是我的最爱。
现在我已经习惯了 IDEA ，所以打算改成 Spring Boot，然后用 IDEA 跑起来。
项目实现基本不变，代码实现可考古 WebRTC H5实现服务器转发的视频聊天
此处使用到的WebRTC皆为H5的API，实际上调用的是封装在浏览器的WebRTC的库，用于获取实时视频数据，传输数据则是使用WebSocket实现。
其中的实例语法只用到原生JS，版本为ES6，可能需要较高版本的浏览器支持（IE一般不支持）。
1.获取音视频数据
方法：navigator.mediaDevices.getUserMedia
webrtc流媒体转发服务器
定义
难点
建立连接
如何转发媒体流
如何高效转发媒体流
转发后如何保证视频质量
定义
由于webrtc是基于P2P技术的一个协议栈，大多数情况下能满足1-5人的同时并发音视频通讯。但是对于多于5人乃至10、20人的并发，使用P2P技术会造成终端设备无法承受负荷。因此需要将P2P模式改造成能适应大量并发模式，即媒体转发服务（MCU）。
NAT给设备提供了一个IP地址以使用专用局域网，但是这个地址不能在外部使用。由于没有公用地址，WebRTC对等端就无法进行通信。而WebRTC使用 STUN来解决这个问题。
STUN服务器位于公共网络上，并且有一个简单的任务：检查传入请求的IP地址（来自运行在NAT后面的应用程序），并将该地址作为响应发送回去。换句话说，应用程序使用 STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址，然后通过信令机制将其传递给另一个对等端以建立直接链接。（实际上不同NAT工作方式都有所不同，可能有多个NAT层，但是原理是一样的）。
因为 STUN服务器不需要做太多的工作或者记特别多的东西，所以相对低规格的 STUN服务器就可以处理大量的请求。
根据webrtcstats.com的统计（2013年），大多数WebRTC通话都成功地使用 STUN进行连接，有86%。尽管对于防火墙之后的对等端之间的呼叫以及复杂的NAT配置，成功通话量会更少一些。
