作为实时音视频领域最火的开源技术，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
1. Janus插件交互流程
Janus中所有插件都遵循以下基本数据流程：
客户端发送create创建一个Janus会话；
Janus回复success返回Janus会话句柄；
客户端发送attach命令在Janus会话上attach指定插件；
Janus回复success返回插件的句柄；
客户端给指定的插件发送message进行信令控制；
Janus上的插件发送event通知事件给客户端；
客户端收集candidate并通过trickle消息发送给插件绑定的ICE通道；
Janus发送webrtcup通知ICE通道建立；
客户端发送媒体数据；
Janus发送media消息通知媒体数据的第一次到达；
Janus进行媒体数据转发。
背景
客户端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退出阻塞来立刻处理发送队列中的数据。这里需要用互斥锁对发送队列做一个同步。
本备忘录状态
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和建议。请参考最新版本的"Internet Official Protocol Standards"(STD1)来获得本协议的标准化进程和状态，此备忘录的发布不受任何限制。
版权注意
版权归因特网协会（1999）所有，保留一切权利。
摘要
本文档规定了一般性的前向纠错的媒体数据流的RTP打包格式。这种格式针对基于异或操作的FEC算法进行了特殊设计，它允许终端系统使用任意长度的纠错码，并且可以同时恢复出荷载数据和RTP头中的关键数据。由于FEC作为一个分离的数据流进行传送，这种方案可以向后兼容那些没有实现FEC解码器的接收 终端。对于那样的终端来说，可以简单地将FEC数据丢掉。
目录
1 简介 2
2 术语 2
3 基本操作 3
4 监督码 3
5 RTP媒体数据包结构 5
6 FEC包结构 5
6.1 FEC包的RTP包头 5
6.2 FEC头 5
7 保护操作 6
8 恢复过程 7
8.1 重建 7
8.2 何时进行恢复 8
9 例子 11
10 冗余编码中使用FEC的用法 13
11 在SDP中表示FEC 14
11.1 FEC作为独立的流传输 14
11.2 在冗余编码中使用FEC 15
11.3 在RTSP中的用法 16
12 安全性问题 16
13 致谢 17
14 作者地址 17
15 参考书目 17
16 版权声明 18
致谢 18