janus是Meetecho开发的一个WebRTC网关，janus的主要作用就是它可以和你的内网设备和浏览器同时建立连接，并将浏览器发来的音视频数据包如rtp/rtcp包，通过自定义插件转发给你的内网设备，也可以将你发给janus的音视频数据包，加密后转发给浏览器。
这样就完成了内网音视频服务器和外网浏览器的互通。
janus为我们完成了与浏览器建立会话的复杂逻辑，并且提供给我们简单的插件机制来处理音视频数据。
对于PeerConnection连接的建立过程，涉及到复杂的NAT穿透的ICE协议的实现，SDP的交换，DTLS-SRTP的握手和数据包加密发送，数据包接收后解密的复杂逻辑。
janus将我们从与浏览器交互的PeerConnection建立的过程中解脱出来，更专注于音视频业务逻辑。
createEndpoint
当我们打开index.js 后，看到的第一个重要的 API就是createEndpoint函数了。我们就以这个 API为开头，一步一步的分析一下medooze的运行机制。
createEndpoint函数定义在 medooze-media-server 库中的 lib 目录下的 MediaServer.js 中。代码如下：
/**
* Create a new endpoint object
* @memberof MediaServer
* @param {String} ip - External IP address of server, to be used when announcing the local ICE candidate
* @returns {Endpoint} The new created endpoing
*/
MediaServer.createEndpoint = function(ip)
{
//Cretate new rtp endpoint
return new Endpoint(ip);
};
它的作用是公布 ICE 本地候选者，当做一个终端。顺着这个函数我们继续往下看，在该函数中会创建一个 Endpoint 对象。
执行脚本
#!/bin/sh
yum install -y epel-release && \
yum update -y && \
yum install -y deltarpm && \
yum install -y openssh-server sudo which file curl zip unzip wget && \
yum install -y libmicrohttpd-devel jansson-devel libnice-devel glib22-devel opus-devel
libogg-devel pkgconfig gengetopt libtool autoconf automake make gcc gcc-c++ git cmake libconfig-devel openssl-devel
进行查看depot_tools工具的linux下的安装方式
主要是在
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git本身之前就是需要翻墙的，我是在windows下做的代理，然后将windows上的git通过设置代理以后下载的这个工具
然后传输到linux里进行下面的编译
在编译之前还需要设置这个路径为PATH中，在/etc/profile中最后设置
export PATH=$PATH:/mnt/hgfs/linuxwebrtc/depot_tools然后执行
source /etc/profileWebRTC 开源实现：https://github.com/webrtc/apprtc
安装 java
yum -y install java-1.8.0-openjdk*安装 node.js
curl -sL https://rpm.nodesource.com/setup_10.x | bash -
yum install -y nodejs
# 确认是否成功
node --version
npm --version
# 构建 apprtc 用到
npm -g install grunt-cli
grunt --version下载和编译参照：http://depthlove.github.io/2019/05/02/webrtc-development-2-source-code-download-and-build/
最后的编译选项：
gn gen out/linux --args='target_os="linux" target_cpu="x64" is_debug=false is_clang=false treat_warnings_as_errors=false rtc_include_tests=false is_component_build=false use_custom_libcxx=false rtc_enable_protobuf=false'
1、连接webrtc静态库时候出现：error adding symbols: Malformed archive
vi build/config/compiler/BUILD.gn
搜索 complete_static_lib
去掉arflags = [ "-T" ] ，不用-T
在使用任何工具之前，我们都有必要对工具做大概地的了解，做到粗犷但不失偏颇，这对我们选择工具和切入点是很关键的。本节的标题虽然是 WebRTC 源码下载与编译，但在这之前，我们有必要大概地了解 WebRTC，比如开发机构、免费性、支持的平台、功能亮点。WebRTC 是一个免费开源的跨平台项目，由 Google，Mozilla，Opera 等支持，支持 Chrome，Firefox，Opera 以及 Android 和 iOS 平台，能够给浏览器、手机应用和物联网设备提供了实时互动能力。WebRTC 是一组协议和 API。WebRTC 的起源可追溯到 2011年，经过六年多的时间的发展，在 2017年底 WebRTC 1.0 标准正式出炉。通过 WebRTC 的 Release Notes 可以看到现在最新的 release 版本是 M74 Release Noted。2015年移动端直播的兴起，观众可以在手机端实时看主播的直播，但是观众与主播之间的沟通需要通过发弹幕来进行，这种交流的实时性较差，沟通不便利，观众参与感较差。2016年初移动端上出现了主播与观众之间可以通过实时视频聊天这种方式来沟通，即，视频连麦。那我们想实现这种视频连麦的功能该怎么做呢？现在通过 WebRTC 以及其它一些音视频工具，我们就可以搭建一个视频聊天工具，做到视频连麦，也能做到类似于微信视频群聊。关于各种实现视频连麦的方式，这里就不细说了，放到后面的章节来解说。了解到 WebRTC 是个什么东西后，通常人的心里就会产生一种跃跃欲试的冲动，想试试，那试试就试试呗。“磨刀不误砍柴工”这句话是有道理的，当我们没有经验和没有人传授经验的时候，那我们就要琢磨这句“磨刀不误砍柴工”了。我们要砍柴做饭，找到一把刀拿起就跑到树林里去砍柴，结果发现刀太钝，砍柴真费劲。这个时候，我们就意识到砍柴刀要用磨刀石磨一磨，磨锋利了，就能提升砍柴的效率。我举这个例子，就想说明两点：
基础环境的准备，包括服务器环境、地址、证书、防火墙配置等。
操作系统：centos 7.6 x64
一个带有SSL证书的域名
需要开放对应的端口：8088 8188 3478 3480-3500 7000-9000 443
mkdir /etc/ssl/cert/domain.com cd /etc/ssl/cert/domain.com
上传证书至此目录，一般用Nginx适用的证书即可。如果有pem的最好，直接上传到此处，如果没有的话，需要转换。
openssl rsa -in domain.com.key -text > key.pem openssl x509 -inform PEM -in domain.com.crt > cert.pem
Posted by Alex Gouaillard on October 18, 2018
If you plan to have multiple participants in your WebRTC calls then you will probably end up using a Selective Forwarding Unit (SFU). Capacity planning for SFU’s can be difficult – there are estimates to be made for where they should be placed, how much bandwidth they will consume, and what kind of servers you need.
To help network architects and WebRTC engineers make some of these decisions, webrtcHacks contributor Dr. Alex Gouaillard and his team at CoSMo Software put together a load test suite to measure load vs. video quality. They published their results for all of the major open source WebRTC SFU’s. This suite based is the Karoshi Interoperability Testing Engine (KITE) Google funded and uses on webrtc.org to show interoperability status. The CoSMo team also developed a machine learning based video quality assessment framework optimized for real time communications scenarios.
First an important word of caution – asking what kind of SFU is the best is kind of like asking what car is best. If you only want fast then you should get a Formula 1 car but that won’t help you take the kids to school. Vendors never get excited about these kinds of tests because it boils down their functionality into just a few performance metrics. These metrics may not have been a major part of their design criterion and a lot of times they just aren’t that important. For WebRTC SFU’s in particular, just because you can load a lot of streams on an SFU, there may be many resiliency, user behavior, and cost optimization reasons for not doing that. Load also tests don’t take a deep look at the end-to-end user experience, ease of development, or all the other functional elements that go into a successful service. Lastly, a published report like this represents a single point in time – these systems are always improving so result might be better today.
That being said, I personally have had many cases where I wish I had this kind of data when building out cost models. Alex and his team have done a lot of thorough work here and this is great sign for maturity in the WebRTC open source ecosystem. I personally reached out to each of the SFU development teams mentioned here to ensure they were each represented fairly. This test setup is certainly not perfect, but I do think it will be a useful reference for the community.
Please read on for Alex’s test setup and analysis summary.