基于WebRTC的直播CDN
2020-09-17 15:46:49不需要SFU实现WebRTC联播实践
2020-08-03 02:19:16文 / Philipp Hancke
译 / 元宝
审校 / Ant
原文：
https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
同步联播是WebRTC用于多方会议的一个很有趣的方面。简而言之，它意味着可以同时发送三种不同的分辨率（空间可伸缩性）和不同的帧速率（时间可伸缩性）。
通常，需要一个SFU才能利用联播。但是有一个方法可以使在两个浏览器之间或在单个页面内效果可见。这对于做单页测试或使用联播功能是非常有用的，特别是能够只启用某些空间层或控制特定流的目标比特率。
Playground
Playground有两种变体，一种用于Chrome，另一种用于Firefox。Chrome版本使用了我们在2014年夏天的谷歌环聊中首次看到的旧的SDP munging hack 。Firefox 使用‘RTCRtpSender.setParameters’来启用同步联播。两者都没有遵守最新的规范，但这并不会影响任何人对它的使用。
两种变体都可以显示视频图像，首先是发送者图像和总体比特率/帧速率图，其后是三个不同的空间流，每个空间流具有用于比特率和帧率的对应图。
由于我们不想涉及到服务器的内容，所以我们需要破解一些东西。幸运的是，有一个Chrome的测试验证了这个想法。Chrome和Firefox都使用一个数据包的RTP SSRC将其路由到某一个特定的媒体流。这些SSRC可以在SDP提供中找到：
原始的Chrome SDP
webrtc 开启Simulcast功能
2020-08-03 00:59:24webrtc自带了Simulcast功能，可以将一个分辨率的流编码成多个分辨率并发送，观看端可以根据带宽去动态的选择某个分辨率，也可以自己选择某个分辨率，据说在webrtc M70版本提供了对外的接口开启Simulcast，并 vp8，vp9，h264三种编码器都支持Simulcast功能，但是在M70版本以下并不支持h264编码器的Simulcast功能，如果在M70版本以下使用Simulcast功能，需要通过修改SDP来开启，话不多说，直接上代码：
Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
2020-07-30 10:15:15There’s new functionality with the new API and the Unified Plan SDP format:
- Early media: after an offer is sent, the calling side can receive media before receiving the answer
- Support for multiple or no media streams for a given track
- With sender objects you can control media with sender.setParameters()
- With transceiver objects, you can more directly control certain aspects of SDP generation.
WebRTC源码分析rfc4588 RTP重传有效载荷格式
2020-07-30 08:22:09RTP重传是一种有效的丢包恢复技术，适用于具有宽松延迟界限的实时应用。该文档描述了用于
执行重传的RTP有效载荷格式。重传的RTP分组在与原始RTP流分开的流中发送。假设从接收器
到发送器的反馈是可用的。特别是，本备忘录中假设提供了实时传输控制协议（RTCP）反馈，
该RTCP反馈在基于RTCP的反馈（表示为RTP/AVPF）的扩展RTP配置文件中定义。
WebRTC网关服务器搭建：开源技术 vs 自行研发
2020-07-27 12:44:27作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。
大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：
● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。
● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。
为什么需要WebRTC网关
WebRTC网关服务器搭建：开源技术 vs 自行研发
2020-07-27 12:44:16作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。
大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：
● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。
● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。
为什么需要WebRTC网关
自研WebRTC网关服务器架构的实践之路
2020-07-27 12:43:22我们对他的演讲内容做了整理,整理后的文章分为上下两篇，本文为第二篇，欢迎阅读。
前面我给大家分享了：
第一，为什么需要WebRTC网关。对于即构来说，目前所使用的系统已经较为成熟，也经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
第二，WebRTC通信模型对比。分析了目前的WebRTC通信模型以及不同模型的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
第三，开源VS自研。分享了目前市面上的一些开源系统及其特点以及即构自研WebRTC网关的目的和出发点。
下面，我将结合即构自研的WebRTC网关服务器方案，分享在开发过程中遇到的难点和解决办法。
WEBRTC三种类型（Mesh、MCU 和 SFU）的多方通信架构
2020-07-22 11:50:50WebRTC 本身提供的是 1 对 1 的通信模型，在 STUN/TURN 的辅助下，如果能实现 NAT 穿越，那么两个浏览器是可以直接进行媒体数据交换的；如果不能实现 NAT 穿越，那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看，Google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。
如果你想要通过 WebRTC 实现多对多通信，该如何做呢？
其实，基于 WebRTC 的多对多实时通信的开源项目也有很多，综合来看，多方通信架构无外乎以下三种方案。
- Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
- MCU（Multipoint Conferencing Unit）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
- SFU（Selective Forwarding Unit）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。
janus的videoroom插件
2020-07-21 01:13:45在Janus的众多插件中，大家最感兴趣的恐怕就是VideoRoom插件了。因为它实现的是一个音视频会议的场景，这正是大多数同学所需要的。而且在Janus众多的插件中VideoRoom应该也是最复杂的一个，如果你们撑握了它，再去看其它插件的实现就容易多了。
在VideoRoom中，包括了很多API，这些API是我们打开VideoRoom的一把钥匙，所以本文的重点就是讲解这些API。我相信当你把这些API都撑握之后，再去看VideoRoom插件的代码时就会更加游刃有余了。
VideoRoom插件
VideoRoom是Janus的一个插件，实现了一个SFU（Selective Forwarding Unit）型的音视频会议。如果你从数据转发的角度看，也可以把它认为是一个音视频路由器。
VideoRoom实现的音视频会议是基于发布/订阅模式。每个参与方都可以发布自己的实时音视频流，因此它可以实现几种不同的场景，比如泛娱乐化直播或多人的实时互动产品(如音视频会议、在线教育小班课等）。
考虑到此插件允许一个参与方可以打开多个WebRTC PeerConnection（如每个参与方可以有1个用于推流的PeerConnection和N个拉流的PeerConnection），所以每个参与方需要为订阅不同的流attach到VideoRoom插件几次(每attach一次就会生成一个Handle，每个Handle就是一个上下文)。
因此，对于每个参与方至少要有一个Handle用于管理与插件的关系（如加入一个房间，离开一个房间，静音/取消静音，发布，接收事件）。
每当参与方需要订阅另一个参与方发布的音视频流时，它需要创建一个新的Handle。新创建的Handle在逻辑上属于“从”Handle，它不能像“主”Handle一样可以做取消房间静音这样的操作。因此，从Handle唯一目的是提供一个上下文，在该上下文中创建一个recvonly类型的PeerConnection来订阅发布者的音视频流。
通过上面的描述我们可以知道，主Handle用于管理，而从Handle用于订阅音视频流。