在使用任何工具之前，我们都有必要对工具做大概地的了解，做到粗犷但不失偏颇，这对我们选择工具和切入点是很关键的。本节的标题虽然是 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 是个什么东西后，通常人的心里就会产生一种跃跃欲试的冲动，想试试，那试试就试试呗。“磨刀不误砍柴工”这句话是有道理的，当我们没有经验和没有人传授经验的时候，那我们就要琢磨这句“磨刀不误砍柴工”了。我们要砍柴做饭，找到一把刀拿起就跑到树林里去砍柴，结果发现刀太钝，砍柴真费劲。这个时候，我们就意识到砍柴刀要用磨刀石磨一磨，磨锋利了，就能提升砍柴的效率。我举这个例子，就想说明两点：
WebRTC 开发（二）源码下载与编译
2019-11-29 01:49:11Janus Webrtc服务的搭建
2019-11-29 00:31:40基础环境的准备，包括服务器环境、地址、证书、防火墙配置等。
环境准备
操作系统：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
开始安装
Breaking Point: WebRTC SFU Load Testing (Alex Gouaillard)
2019-11-29 00:29:33Posted 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部署总结
2019-11-29 00:28:04Janus安装
安装环境为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 installcentos下 Janus Server 搭建笔记
2019-11-29 00:11:36基于Webrtc和Janus的多人视频会议系统开发1--系统架构
2019-11-28 21:47:14目前业界如教育行业，直播行业，低延迟音视频连麦方案基本采用声网，即构，腾讯等第三方方案，采用第三方方案最大的优点就是接入快捷，可以迅速搭建自己的产品，缺点就是完全受制于第三方，另外费用比较高，公司规模小的时候比较合适，公司规模大了后就会有顾虑，通常达到一定规模后可以考虑自研一套方案和第三方方案并行使用，避免完全受制于第三方，和华为采购高通芯片的同时也研发自有芯片一个道理。
正是基于这样的考虑，我们开始研发自研的连麦系统，作为技术方案来说，现今支持浏览器直连基本上已经是刚需，所以webrtc是必须要兼容的，所以技术方案设计上决定是以webrtc协议为基础，支持多人会议，完全从0开始做不可取，经过对现有开源框架的研究比较后，决定在janus方案的基础上研发并逐步改进以符合需要，本系列文章就是对整改系统的研发过程的记录和总结，供大家参考。
WebRTC 发送端无法获取丢包率的解决办法，以及如何获取 RTT
2019-11-28 10:56:59WebRTC 自 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 源码中需要修改的相关代码。
Ubuntu 下 Janus Server 搭建笔记
2019-11-28 10:56:02
webrtc gateway janus系列（二）运行demo
2019-11-28 10:53:57janus 执行参数
-h, --help 打印帮助信息并退出
-V, --version 打印版本信息并退出
-b, --daemon 后台运行（默认前台运行）
-p, --pid-file=path pid文件目录路径
-N, --disable-stdout 禁止日志输出到标准输出
-L, --log-file=path 日志文件路径
WebRTC gateway janus入门：从配置到插件编写
2019-11-28 10:52:13janus介绍
janus是Meetecho开发的一个WebRTC网关，janus的主要作用就是它可以和你的内网设备和浏览器同时建立连接，并将浏览器发来的音视频数据包如rtp/rtcp包，通过自定义插件转发给你的内网设备，也可以将你发给janus的音视频数据包，加密后转发给浏览器。
这样就完成了内网音视频服务器和外网浏览器的互通。
janus为我们完成了与浏览器建立会话的复杂逻辑，并且提供给我们简单的插件机制来处理音视频数据。
对于PeerConnection连接的建立过程，涉及到复杂的NAT穿透的ICE协议的实现，SDP的交换，DTLS-SRTP的握手和数据包加密发送，数据包接收后解密的复杂逻辑。
janus将我们从与浏览器交互的PeerConnection建立的过程中解脱出来，更专注于音视频业务逻辑。