简单生活

这篇文章是对mediasoup代码分析的一个总结，总结的相对简单，仅是对学习过程的一个记录，更详细的介绍请参考文末参考文章的介绍mediasoup总体的架构分为两个层次，nodejs层和C++层。nodejs负责信令处理和房间管理，信令部分主要是入会、离会、SDP协商、连接通道建立等，房间管理nodejs是用的protoo，不熟悉的朋友墙裂建议阅读下protoo，protoo已经为我们实现了room、peer的建立、管理等操作，还可以在peer上注册自定义事件，mediasoup很多信令（join、crea

整体架构上面这张图是一个比较老的架构图，但是也基本能说明整体架构，早期webrtc版本带宽估计是放到接收端处理，目前最新版本带宽估计放到了发送端，但是接收端计算得到的带宽并没有废弃，而是通过rtcp remb反馈给发送端。在发送端带宽估计由3个元素结合决定，基于丢包率估算的带宽（丢包率通过rtcp rr得到）、接收端的remb反馈的带宽、发送端带宽估计（方法类似于接收端的带宽估计，具体逻辑下面会介绍到），取三者带宽的最小值作为最终带宽估计值。接口说明rrhttps://tools..

协议汇总webrtc依赖的服务有如下几种signaling信令服务器，交换房间和会议的媒体信息，以及会议期间的消息，媒体描述使用的是SDP协议 ICE服务器，STUN和TURN，ICE的信息叫Candidate，可以通过SDP交换，或者通过Trickle SFU和MCU服务器SDP协议：1998-RFC2327,2006-RFC4566，例子（https://webrtchacks.com/sdp-anatomy/?spm=ata.13261165.0.0.41035c8c9sVCVD）S

RTP：RFC3550SRTP（安全）：RFC3711主要字段说明P（padding）：1 比特，若填充比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充字节。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。由于Opus的包大小差不太多，但又不完全一样，所以会出现很多大小差不多却又不一样的小包，这对于服务器GSO发送这些包会带来很大的困难，所以通过增加几个字节的padding，可以