由于webrtc工程代码本身非常庞大，编译工具也很独特，Licode并未全部引入，仅仅抽取了webrtc的部分代码，如下图所示：
https://tools.ietf.org/pdf/rfc4585.pdf RTP/AVPF 传输层反馈；
https://tools.ietf.org/pdf/rfc4588.pdf 4585补充 重传包格式；
https://tools.ietf.org/pdf/rfc4588.pdf 4585补充 负载层反馈；
https://tools.ietf.org/pdf/rfc5124.pdf RTP/SAVPF
https://tools.ietf.org/pdf/rfc5450.pdf 4585补充 Jitter报告
(2). 前向纠错 (FEC)
https://blog.csdn.net/volvet/article/details/53573359 WebRTC中的前向纠错编码 - Red Packet
https://blog.csdn.net/volvet/article/details/53575514 WebRTC 的前向纠错编码 - XOR FEC
(3). 带宽检测 (BWE)
传统的基于RTCP RR报文中丢包数来进行带宽检测的算法目前被认为是最low的了，因为属于事后处理；先进的算法是需要事前感知的（突发情况除外），假定带宽是逐渐变窄的，根据信号估计理论可以在网络链路发生丢包以前就监测到网络拥塞。
https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02
https://tools.ietf.org/pdf/draft-alvestrand-rmcat-remb-03.pdf
GCC算法与函数调用 ：
https://www.jianshu.com/p/0f7ee0e0b3be
带宽估计：
https://blog.csdn.net/u013160228/article/details/46392037
带宽检测 ：
https://blog.csdn.net/volvet/article/details/54577776
接收缓冲区延迟估计：WebRTC视频接收缓冲区基于KalmanFilter的延迟模型。
网络收发或一个SFU实现，并非简单的从一个源地址收到若干个数据包再复制多份发送给多个目的地址，正如3.6所描述，除了需要堆栈式的ICE地址转换、DTLS/SRTP的解密，还需要流水线式的RTP/RTCP的丢包检测与重传、FEC处理、带宽检测与估计、包缓冲区调整以及平滑发送等若干个复杂步骤，这个流程在Licode代码中是通过Pipeline-Handler这样的架构实现的，由于webrtc仅提供底层算法并未提供SFU架构，所以我认为这种架构是Licode最重要的关键技术，可供未来想成为软件架构师的开发者参考学习。
Pipeline的类图如下图：
对Pipeline来说，需要全局管理、长时处理或非逐个包处理的流程，实现对象叫Service，包括Handler的管理、RTCP的计算与处理、当前状态的处理、网络质量的管理以及包缓冲的管理都是Service；而需要每次逐包处理的流程，实现对象叫Handler，包括19项Handler，其代码都位于erizo\src\erizo\rtp目录下：