文 / 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功能，可以将一个分辨率的流编码成多个分辨率并发送，观看端可以根据带宽去动态的选择某个分辨率，也可以自己选择某个分辨率，据说在webrtc M70版本提供了对外的接口开启Simulcast，并 vp8，vp9，h264三种编码器都支持Simulcast功能，但是在M70版本以下并不支持h264编码器的Simulcast功能，如果在M70版本以下使用Simulcast功能，需要通过修改SDP来开启，话不多说，直接上代码：
There’s new functionality with the new API and the Unified Plan SDP format:
RTP重传是一种有效的丢包恢复技术，适用于具有宽松延迟界限的实时应用。该文档描述了用于
执行重传的RTP有效载荷格式。重传的RTP分组在与原始RTP流分开的流中发送。假设从接收器
到发送器的反馈是可用的。特别是，本备忘录中假设提供了实时传输控制协议（RTCP）反馈，
该RTCP反馈在基于RTCP的反馈（表示为RTP/AVPF）的扩展RTP配置文件中定义。
作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。
大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：
● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。
● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。
作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。
大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：
● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。
● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。
我们对他的演讲内容做了整理,整理后的文章分为上下两篇，本文为第二篇，欢迎阅读。
前面我给大家分享了：
第一，为什么需要WebRTC网关。对于即构来说，目前所使用的系统已经较为成熟，也经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
第二，WebRTC通信模型对比。分析了目前的WebRTC通信模型以及不同模型的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
第三，开源VS自研。分享了目前市面上的一些开源系统及其特点以及即构自研WebRTC网关的目的和出发点。
下面，我将结合即构自研的WebRTC网关服务器方案，分享在开发过程中遇到的难点和解决办法。