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
在最开始，我们在产品方面做出了用户可以感受到的改变，这让你与朋友玩游戏时，Discord非常适合你们之间的语音交流。这些决定让我们在资源有限并且团队比较小的情况下扩大了经营。
本文简要介绍了Discord使用的不同技术，来让视频音频交流达到接近现实的效果。
为了区分，我们将会使用guild来代表一组用户和频道-在客户端它们被称为servers. Server被用来描述我们的后端架构。
Discord中所有音频视频交流都是多方的。支持大规模组内交流需要客户端-服务器的网络架构因为当参与者人数增多时，点对点网络变得非常昂贵。
通过Discord servers发送你所有的数据同样确保在输入文本，声音或视频时你的IP地址不会被泄露，这防止了其他人找到你的IP地址并且创建DDoS来攻击你。通过媒体服务器发送具有其它优势，例如对于使人讨厌的参与者，管理员可以选择禁止他的音频视频交流。
本文原文由声网WebRTC技术专家毛玉杰分享。
有人说 2017 年是 WebRTC 的转折之年，2018 年将是 WebRTC 的爆发之年，这并非没有根据。就在去年（2017年），WebRTC 1.0 标准草案出炉（实际上WebRTC标准草案的早期版本早在2011年就已经发布，WebRTC并非一夜之间就出现的技术），并将于今年正式发布。与此同时，越来越多的浏览器和厂商都开始对它进行广泛的支持，WebRTC 即将成为互联网的基础设施了，或许门槛如此之高的实时音视频技术终有白菜化的那一天。
补充：WebRTC标准草案的版本演进历史，请点击进入。
本文主要讨论如何使用WebRTC技术来实现可扩展的，高效的多人音视频解决方案，介绍现有的多人音视频通讯模型 ，给出一种在Agora.io中使用的网页端技术方案。
WebRTC是一种基于点对点(peer to peer, P2P)的用于交换音视频媒体流以及数据流的技术，基于WebRTC的技术我们可以很容易的实现一对一场景的音视频通话以及数据流的传输并且有着不错的质量控制。但是如果要实现多人的音视频通话或者是一对多的直播应用，那么使用WebRTC就会面临一些困难和挑战，下面我们讨论两种常见的多方通讯模型。
1、网状模型
如果你计划在WebRTC中有多个参与者，那么最终可能会使用选择性转发单元（SFU）。webrtcHacks的撰稿人 Alex Gouaillard和他的CoSMo Software团队组建了一个负载测试套件来测量负载与视频质量，并发布了所有主要开源WebRTC SFU的结果。LiveVideoStack对原文进行的摘译。
可以将WebRTC系统体系结构大致分为两种类型：
不中断加密访问的媒体
