WebRTC 开源实现：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.
Janus安装
安装环境为Centos7
#!/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
#upgrade libsrtp 1.5.4
#wget https://github.com/cisco/libsrtp/archive/v1.5.4.tar.gz
#tar xfv v1.5.4.tar.gz
#cd libsrtp-1.5.4
#./configure --prefix=/usr --enable-openssl
#make shared_library && sudo make install目前业界如教育行业，直播行业，低延迟音视频连麦方案基本采用声网，即构，腾讯等第三方方案，采用第三方方案最大的优点就是接入快捷，可以迅速搭建自己的产品，缺点就是完全受制于第三方，另外费用比较高，公司规模小的时候比较合适，公司规模大了后就会有顾虑，通常达到一定规模后可以考虑自研一套方案和第三方方案并行使用，避免完全受制于第三方，和华为采购高通芯片的同时也研发自有芯片一个道理。
正是基于这样的考虑，我们开始研发自研的连麦系统，作为技术方案来说，现今支持浏览器直连基本上已经是刚需，所以webrtc是必须要兼容的，所以技术方案设计上决定是以webrtc协议为基础，支持多人会议，完全从0开始做不可取，经过对现有开源框架的研究比较后，决定在janus方案的基础上研发并逐步改进以符合需要，本系列文章就是对整改系统的研发过程的记录和总结，供大家参考。
WebRTC 自 M68 版本推出新的重载方法 GetStats 以后，使用新的接口便再也获取不到发送端的丢包率了（包括所有的 Native 端和 Web 端），原因是在 void OnStatsDelivered(const rtc::scoped_refptr<const RTCStatsReport>& report) 回调中返回的结构体 RTCStatsReport 中没有 packets_lost 的定义，只有 packets_sent、frames_encoded 等信息，默认只能获取到发送的码率、帧率，而得不到丢包率、rtt 等判断网络质量的关键信息。不过 WebRTC 底层其实已经将丢包信息、rtt 等关键信息实时统计上来了，只是 PeerConnectionInterface 在获取 Statistics 时，没有将相关信息打包进 RTCStatsReport 结构体中，那么解决办法就是：在 RTCStatsReport 结构体中新增定义 packets_lost、rtt_ms 字段，并为其赋值即可，下面为 Native 源码中需要修改的相关代码。
