在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中的消息提供加密等一系列安全保护。
由于TLS协议主要是提供加密功能以保障通道数据的安全性，因此要求底层协议提供一个可靠且有序的通信过程，一旦数据包出现丢包或乱序的情况则会断开连接，所以UDP协议是不能和TLS协议组合使用。
现实情况是UDP协议常用于媒体数据传输，因此为了保障媒体传输的安全性，引入了DTLS协议来对UDP通信过程进行加密。DTLS是在TLS的基础为UDP定制和改进的安全传输协议，在设计上尽可能复用TLS现有的结构。
DTLS和TLS在版本上的对应关系：
TLS(Transport Layer Security)协议，其前身为SSL(Secure Socket Layer)，是1994年由Netscape公司设计的一套协议，并于1995年发布了3.0版本，而TLS是IETF基于SSL3.0设计的协议，相当于SSL的后续版本。
TLS建立在传输层之上，服务于应用层，旨在于为通信双方提供一条安全通道，主要提供一下三重保障：
时间与人类的生活息息相关，可时间本身是连续的且不存在刻度，因此，人类引入了世界标准时的概念用以统一时间计量。度量时间意味着需要将时间转换成离散的，即使用计量单位表示时间。不同的标准时使用的度量标准不同：即对计量单位的定义标准不同。
以下是关于计量单位秒的两种定义标准，分别是：
根据地球自转和公转
地球自转，且围绕太阳公转。根据相对运动的原理，以地球为参照物时，太阳是围绕地球运动的。因此，把太阳连续两次穿过地球表面某一个定点的经线（子午线）所需的时间定为一天，即24个小时，换算可得到秒的时长。
比如格林尼治时间（Greenwich Mean Time，GMT）将太阳两次横穿格林尼治子午线所需的时长定为一天。
这种定义标准显然更符合人类习惯，但是由于地球公转轨迹是一个椭圆，意味着地球公转速度是不均匀的，且地球自转的速度正在缓慢减速，换言之，GMT时间在缓慢地变长。因此，GMT时间不再作为标准时间，取而代之的是UTC时间。
采用原子时秒
原子时秒，由原子钟导出，简言之，是以铯-133的振荡频率来定义秒。由于GMT时间存在不均匀性和低精度性，自1867年起，世界标准时改用原子时作为基本的时间计量系统。
协调世界时（Universal Time Coordinated，UTC），就是采用的这种定义标准。
定义秒这一计量单位后，向下可以进一步细分为毫秒、微妙和纳秒等，向上则可以组合成分钟、小时、日、月和年等概念。