参考网址 https://webrtcglossary.com/
ORTC stands for Object-RTC.
ORTC is an initiative involving Google, Microsoft and several other companies with the effort of
defining an object-centric API to real time communications.
At its heart, ORTC aims to replace the current SDP interface that is used by WebRTC as the API used by developers.
SVC stands for Scalable Video Coding.
SVC is added as part of the VP9 codec implementation in WebRTC.
NetEQ is an implementation of a Jitter Buffer optimized for voice.
A dynamic jitter buffer and error concealment algorithm
used for concealing the negative effects of network jitter and packet loss.
Keeps latency as low as possible while maintaining the highest voice quality.
RED stands for REDundant coding and it is a RTP payload format defined in RFC 2198 for encoding redundant audio or video data.
RTP BUNDLE is a mechanism in RTP that enables using a single socket/connection to send multiple media types
BWE
Bandwidth Estimation is the mechanism used in WebRTC (and other VoIP systems)
to decide how much bandwidth is available for a given session.
Loss-based BWE通过RTCP-RR报文来检测丢包率，然后根据丢包率来调整对应的带宽。
Delay-based BWE通过分析包之间的延时来预测拥塞，在路由器丢弃数据包之前尝试降低带宽
Recv-side Delay-based BWE：REMB-based GCC
Send-side Delay-based BWE：TransportFB-based GCC
TCC的缺点在于浪费了一定的带宽，同时Firefox目前还不支持TCC。
REMB的优点在于码率的控制权在服务端（接收端），没有额外的带宽浪费。
REMB的缺点在于调试起来不方便，需要同时关注两个端，同时WebRTC已经不对REMB提供支持——这意味着当下的REMB实现版本可能存在不少BUG，
同时BWE的新特性也不会加入到当前的REMB实现。
Google从Chrome55开始支持Send-side Delay-based BWE。查了下WebRTC的代码提交，REMB方案几乎没有实质性修改，而TCC针对性做了优化。
在采用TCC方案后，接收也可以利用REMB来通知发送端码率发送上限