面试时被问到的一个问题，回答得不够全面，算是查漏补缺。
我一直都有一个疑问，为什么在C++中有了指针还要引用？在Stroustrup: C++ Style and Technique FAQ中给出了回复，原文如下：
C++ inherited pointers from C, so I couldn’t remove them without causing serious compatibility problems. References are useful for several things, but the direct reason I introduced them in C++ was to support operator overloading.
翻译：C++中指针继承自C语言，出于兼容的原因保留了下来。引用的用处很多，但是C++引入它最直接的原因是为了支持运算符重载。
面试时被问到的一个问题，没答上来，算是查漏补缺。
IDR（Instantaneous Decoder Refresh），即时解码刷新，是一种特殊的I帧。IDR帧是为了防止H264解码器在解码时参考无意义的帧而设置的。
当H264解码器收到IDR帧时，意味着后续抵达的帧不会再参考IDR帧之前的帧，因此，H264解码器会“清空”参考缓冲区（the reference buffer），而所谓的“清空”有可能是将参考缓冲区中的所有帧标识为“不可参考（unused for reference）”状态。
相较而言，当H264解码器收到普通的I帧时，后续抵达的帧有可能会参考这个I帧之前的帧，即参考缓冲区中的帧。
在GCC（Google Congestion Control）拥塞控制算法中，包含了两种带宽估计算法，分别是基于延迟的带宽估计算法和基于丢包的带宽估计算法。
其中，基于延迟的带宽估计算法有新旧两个不同的实现版本，分别是：旧版使用基于接收端的Kalman滤波器带宽估计算法，新版使用基于发送端的Trendline滤波器带宽估计算法。
在WebRTC中，为了向前兼容仍保留了旧版的实现，且对于视频流会同时开启两种基于延迟的带宽估计算法。因此，如果存在视频流时，GCC还好收到从接收端返回的带宽估计值：REMB（Remote Estimated Maximum Bitrate）。GCC算法最终会选取这三个带宽估计值中的最小值作为当前的带宽估计值。
本文介绍的是新版基于延迟的带宽估计算法中的Trendline滤波器，可根据数据包的延迟梯度的变化预测带宽的变化趋势，以此为参考对当前码率进行相应的调整，进而获得更为接近真实情况的带宽估计值。
所谓关键帧，就是不需要参考其他视频帧，可单独解码的帧。比如H264中的I帧。在WebRTC中有两种关键帧请求方式，分别是：
二者的主要区别在于报文结构和使用场景不同，但实际上在发送端处理两种请求的逻辑很可能是一样的，比如，WebRTC中的实现就是如此。
在WebRTC中，使用的GCC（Google Congestion Control）作为拥塞控制算法，且该算法有新旧两个版本。二者的主要区别之一就是基于延迟的带宽估计算法的实现不同：旧版采用的是基于接收端的Kalman滤波器带宽评估算法，而新版则是基于发送端的Trendline滤波器带宽评估算法。
此前在 WebRTC之抖动估计 中简单介绍过关于时延的概念，简单说就是指一个数据包或信号从发送端抵达接收端所需的时长。由于网络拥塞等原因，即便是以均匀时间间隔连续发送的数据包，在抵达接收端时的时间间隔也很可能是不均匀的。
新版采用的Trendline滤波器算法，是一种基于包的时延梯度的变化来评估当前网络变化趋势的算法，而时延梯度的计算基于发送时间间隔（inter-departure）和抵达时间间隔（inter-arrival）。
关于Trendline滤波器带宽评估算法的具体实现留待后续，本文介绍的是关于包组时间间隔的计算方式。
RTT（round-trip time），往返时延，表示在通信过程中，发送端发送的数据包或信号抵达接收端后，再返回发送端的整个往返过程所需时长。
RTT由三个部分决定，分别是
由于接收端的处理时长只与接收端的处理逻辑相关，不涉及网络传输，所以在RTT计算过程中一般不包括接收端的处理时长。即：
1 | RTT = 链路的传输时长 + 路由器的排队和处理时长 |
其中，路由器的排队和处理时长会随着整个网络的拥塞程度的变化而变化。
简言之，网络拥塞程度越严重，RTT的值也就越大。因此，RTT的变化在一定程度上反应了整个网络的拥塞程度的变化。这也是RTT常被当做重要指标用于分析网络性能的原因。
时延和抖动是两个不同但又相互关联的概念。时延是网络通信中的一个重要指标，用于衡量数据包从一个端点传送到另外一个端点所需的时间。
在网络通信中，连续发送的数据包即便使用相同的路径也会产生不同的时延。原因在于，路由器一次只能处理一个数据包。当数据包抵达的速度大于路由器处理数据包的速度，会被暂时放入路由器的网络缓冲区，等待路由器的处理和转发，从而增加了数据包的传输时延。
抖动就是用于表示数据包之间传输时延的不一致性，即用来衡量数据包传输时延的变化程度。
导致抖动产生的原因有很多，比如网路拥塞，网路错误，丢包等。
这是一本严谨的好书，书中围绕“刻意练习”这一主题，给出了明确的定义和方法论，并从多个角度分析其可行性。以下是我的学习心得：
SRTP协议，全称Secure Real-time Transport Protocol。顾名思义，SRTP就是在RTP协议的基础上提供了安全保障，主要包括数据加密、消息认证和重放保护。
SRTP提供了一套框架用于加密和认证RTP和RTCP数据流，且内置一系列预定义的加密套件。当然也可以使用自定义加密套件。
SRTP协议建立于在RTP协议之上，在RTP/RTCP包的基础上通过增加额外的空间和计算量来实现安全保障。因此SRTP增加的额外开销越小，对RTP传输影响也越小。而SRTP额外开销的大小主要取决于加密套件的选择，SRTP中预定义的加密套件是一个不错的选择，详见 RFC 3711。
DTLS在WebRTC中主要提供两个功能：
协商SRTP加密密钥
虽然DTLS协议提供了解决丢包和乱序的机制，但是具体实现方案比较简单，对于音视频这类对丢包和乱序更为敏感的数据包有点力不从心。因此WebRTC中RTP（Real-time Transport Protocol）协议作为音视频包的传输协议。而SRTP（Secure Real-time Transport Protocol）在RTP协议之上，为RTP包提供了加密、消息认证和完整性以及重放攻击等保护。
SRTP作为安全协议，采用的是对称加密算法，而密钥协商则是通过DTLS协议，具体协商过程留待下文。
为SCTP协议提供加密通道
SCTP是一种在网络连接两端之间同时传输多个数据流的协议，提供的服务与UDP和TCP类似，同样SCTP本身不提供加密功能。因此在WebRTC中使用DTLS作为SCTP的底层协议，为SCTP中的消息提供加密等一系列安全保护。