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网关服务器方案，分享在开发过程中遇到的难点和解决办法。
在Janus的众多插件中，大家最感兴趣的恐怕就是VideoRoom插件了。因为它实现的是一个音视频会议的场景，这正是大多数同学所需要的。而且在Janus众多的插件中VideoRoom应该也是最复杂的一个，如果你们撑握了它，再去看其它插件的实现就容易多了。
在VideoRoom中，包括了很多API，这些API是我们打开VideoRoom的一把钥匙，所以本文的重点就是讲解这些API。我相信当你把这些API都撑握之后，再去看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用于订阅音视频流。
客户端SDK集成了WebRTC和libwebsockets，服务端使用了Janus，需要支持拉流秒开。
关于WebSocket
Janus作为SFU，使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择，C层主要是libwebsockets库，这个也是Janus使用的库，还有Boost的Beast库，不过比较新，不敢踩坑，IOS上有RocketSocket，但不是跨平台，因此最后采用了libwebsockets库。
libwebsockets库主要的问题是IO接口不太友好，需要自己启动一个线程轮询获取IO事件，在其回调中处理所有事件。
秒开要考虑的问题
libwebsockets IO的优化
主要是写数据的处理。
libwebsockets需要调用者自己维护发送队列，调用者调用lws_callback_on_writable来告知libwebsockets有数据要写，然后数据放入发送队列，libwebsockets会通过LWS_CALLBACK_CLIENT_WRITEABLE事件通知可写，这个时候调用者才可以从发送队列取出数据发送，这个是一个异步的过程。
在libwebsockets的IO事件循环中，lws_service用于阻塞等待IO事件，但是lws_callback_on_writable并不会让lws_service退出阻塞状态，lws_service有一个最大等待时间，如果等待lws_service超时才处理待发送的数据无疑会增加整体接续时间。这里可以通过在调用线程中调用lws_cancel_service方法强制lws_service退出阻塞来立刻处理发送队列中的数据。这里需要用互斥锁对发送队列做一个同步。
1. 运行效果
https://janus.conf.meetecho.com/videoroomtest.html?simulcast=true
包含：Simulcast功能
视频高等质量（分辨率：1280*720，带宽1.5M+）
视频中等质量（分辨率：640*360，带宽500K左右）
视频低等质量（分辨率：320*180，带宽150K左右）
1、运行效果图
Echo测试演示的是发送给服务器网关的音频和视频，服务器会回传给你，效果如下图所示：
2、代码分析
2.1 代码结构
2.2 源码分析
2.2.1 创建线程
在janus = new Janus()时，调用Janus(gatewayCallbacks)在其中有函数createSession，并且传入下面的回调函数：
createSession创建请求，成功建立一次httpAPICall，输出Created handle: 1747107217737787