问题：为什么要搞这么多架构？
webrtc虽然是一项主要使用p2p的实时通讯技术，本应该是无中心化节点的，但是在一些大型多人通讯场景，如果都使用端对端直连，端上会遇到很带宽和性能的问题，所以就有了下图的三种架构。
webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU
2020-07-11 21:45:20基于WebRTC构建超低延迟(500ms)的直播系统
2020-07-11 21:40:08上周写了一篇文章基于RTMP和WebRTC 构建低延迟的直播系统(https://zhuanlan.zhihu.com/p/47302561), 只所以要基于RTMP, 还是考虑尽可能复用现有的技术和基础设施. 实际上国外已经有基于WebRTC的CDN系统, 比如 http://phenixrts.com/, https://www.millicast.com/. 比这更早的可以追溯到beam, 一个实时的游戏直播平台, 在2016年被微软收购后改名mixer(https://mixer.com). 目前国内低延迟直播的做法是在rtmp的基础调优, 比如使用可靠UDP方案替换RTMP的传输层, 目前使比较多的方案有KCP和QUIC. 但魔改RTMP的方案始终没有特别好的适配浏览器的方法. 相比有超过40亿设备支持的WebRTC来说, WebRTC的方案无疑更有想象空间.
但WebRTC天生为Peer-To-Peer而生, 并没有提供对大规模分发的支持. 为提升WebRTC分发能力, 于是有了SFU的方案, 但常见的SFU方案, 也只能让WebRTC具备几十路到几百路的分发能力. 试想在用WebRTC直播, 瞬间进入几百个观看端, 这几百观看端都在请求关键帧, 发送端的压力会非常大造成整个直播不可观看. 在这几百人中如果有几个人网络特别差, 也会造成整个直播质量的下降. 如果我们想提升WebRTC的分发能力, 我们应该切端观看端向发送端的反馈机制. 在牺牲一定视频质量的情况做到大规模的分发.
基于RTMP和WebRTC开发大规模低延迟(1000毫秒内)直播系统
2020-07-11 21:35:47随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.
WebRTC兴起提供的方案以及遇到的问题
WebRTC技术的兴起为低延迟音视频传输带来了解决方案, 但WebRTC是为端到端设计的, 适合的场景是小规模内的实时互动, 例如视频会议, 连麦场景. 即使加入了SFU Media server作为转发服务器, 也很难做到大规模的分发. 另外一个需要考量的是流量成本, WebRTC的实时流量是通过UDP传输的(某些情况下可以用TCP), 无法复用在传统CDN的架构之上, 实时的流量价格更是CDN流量的3倍以上, 部署一个超低延迟的直播网络成本非常高.
RTMP系统推流播放延迟分析
WebRTC使用SDES代替DTLS协商
2020-07-11 21:33:57WebRTC作为浏览器中的一个组件，在设计的时候考虑了大量了安全问题，比如要求getUserMedia在加密网页中才能打开摄像头， 使用MDNS来防止IP地址的泄露， 使用DTLS来加密datachannel数据，使用DTLS-SRTP来加密音视频数据等等，在带来更高的安全性的同时也带来更多的复杂性，更多的资源占用。尤其是对于开发者来说，DTLS-SRTP的引入带来很多问题，工程的复杂性，服务器资源的占用，以及音视频建立连接的延迟等，我们使用SDES来减少DTLS带来的影响，在保证兼容WebRTC协议的同时减少系统的复杂度，降低弱网下的首帧延迟。
网页版WebRTC多人聊天Demo
2020-07-11 14:21:46网页版WebRTC多人聊天Demo
本文基于Codelab中step7，在其基础上作简单修改，使其支持多人视频通讯，本文暂时只支持星状结构三人聊天，多人聊天可以在基础上扩展，原理相同。
一.源码分析
该工程包括三个文件：server.js，main.js，index.html。
1.server.js
WebrRTC(4) 端对端连接
2020-07-11 13:40:55WebRTC端对端连接
RTCPeerConnection
一个核心类，是上层的统一接口。
在底层有很多复杂逻辑，媒体协商 、流轨道处理、数据接收发送、数据统计等等。
Android WebRTC完整入门教程04: 多人视频
2020-07-11 12:00:33
kurento代码分析（二）rtp流的处理
2020-07-10 15:59:25 今天得闲，又翻了下kurento的代码，没忍住。学有所得，分享在这里。
kurento在处理rtp流时，需要创建一个rtpbin这样一个element。我上一篇，分析了kurento是怎么通过工厂模式，创建一个gstreamer中的element对象。
这种工厂模式，提供了很大的灵活性，有新的需求的时候，就可以继承父类，构造新的处理逻辑。例如关于webrtc的rtp流的处理，在C层，KmsWebrtcEndpoint继承了KmsBaseRtpEndpoint。
WebRTC网关服务器单端口方案实现
2020-07-10 15:51:18标准WebRTC连接建立流程
这里描述的是Trickle ICE过程，并且省略了通话发起与接受的信令部分。流程如下：
1） WebRTC A通过Signal Server转发SDP OFFER到WebRTC B。WebRTC B做完本地处理以后，通过 Signal Server转发SDP ANSWER到A。
2）A、B同时向STUN Server发送Binding request请求自身的外网地址，并从STUN Server回包的MAPPED-ADDRESS中得到各自的外网地址；
3）A、B收集完内外网ICE Candidate，并通过Signal Server发送给对方；
4）双方开始做NAT穿越，互相给对方的ICE Candidate发送STUN Binding Request；
5）NAT穿越成功，A、B之间的P2P连接建立，进入媒体互通阶段。在这个过程中，我们看到了有三个核心的部分，SDP协商、ICE Candidate交换、Stun Binding Req/Res的连通性检查。
WebRTC网关连接建立流程
基于mediasoup的多方通话研究
2020-07-10 15:19:04基于mediasoup的多方通话研究（一）
mediasoup简介
mediasoup的特性
安装mediasoup-demo
本地运行Demo
server的配置文件
mediasoup的原理
扩展与展望
总结
mediasoup简介