https://groups.google.com/g/discuss-webrtc/c/Bp8OzBzipSc
切换到M96分支
git checkout branch-heads/4664
PSAs
Plan B和Unified Plan
Plan B是Chrome/Chromium独有的实现，Safari和Firefox一直支持Unified Plan，Chrome在M72已经支持Unified Plan。从某种程度上说如果后续再开发WebRTC可以不考虑Plan B的支持了，因为Unified Plan的支持已经非常好。
Plan B和Unified Plan各有优劣，在只有一路音频和视频的时候这两种方案并没有什么区别，在多路音视频的时候Unified Plan每一路音视频都会有一个Mline，这样就提供了很大的灵活性，可以针对每一路音视频协商不同的能力，比如我们有一路摄像头和一个屏幕共享，就可以让屏幕共享使用av1编码，而摄像头使用h264。作为多年跟SDP打交道的开发者不得不说SDP Sucks，SDP真的是一个很糟糕的设计，它是一个标准但又是一个相对灵活的标准，每家的实现可能又不一样，不得不花费很多精力进行SDP的适配，如果你还有没有被SDP的适配困扰过某种意义上你可能还没有完全了解WebRTC。但标准一旦确立，别人撼动它也很难，微软曾经搞出来ORTC标准来屏蔽SDP的协商问题，最终也还是失败了。
用于 SCTP 传输的 DcSCTP 库
SCTP（Stream Control Transmission Protocol，流控制传输协议） RFC 4960
它是一种传输协议，默认使用5000端口，在TCP/IP协议栈中所处的位置和TCP、UDP类似，同时具备TCP和UDP的特征。
DcSCTP library for the SCTP transport used by WebRTC’s Data Channels
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.
--force-fieldtrials="WebRTC-DataChannel-Dcsctp/Enabled/“
Opus+Red冗余编码
Support for RFC 2198 redundancy
Audio redundancy for OPUS using RED is now available. See the PSA for details.
之前在WebRTC中如果想提升音频的弱网抗性，能做的就是增加NACK(重传)和开启Opus的FEC。如今我们有了更多的方案，在M96的WebRTC支持了通过red来发送音频冗余包来提升音频弱网抗性。RTP的RED规范之前很早就存在，二十多年前就被提出，基本思路就是通过发送多余的冗余包，使用RED将一个或者两个冗余音频帧放入每个分组中，有时候也被称为“带外FEC”。
当然，这些都是有代价的，可以能将你的音频码率从30kbps增加到60kbps或者90kbps，不过跟视频相比这些码率的增加并不算大，非常适合音频优先的场景。
Using RED to put one or two redundant audio frames into each packet would give much more resilience to packet loss than Opus FEC. It comes at a cost however, doubling or tripling the audio bitrate from 30kbps to 60kbps or 90kbps (with an additional 10 kbps for the header). Compared to more than one megabit per second of video data it does not seem so bad however.
在M96中可以通过setCodecPreferences 方法调整opus+red的顺序来开启，默认Chrome中只会编码一个red冗余包，这样可以在不过多增加带宽的情况下提升弱网抗性。另外可以通过WebRTC Encoded Insertable stream来调整冗余度。
github上已经有如何使用的demo https://github.com/fippo/opus-fec，另外开源的Janus媒体服务器已经支持。
opus+red并非是默认开启的，可以通过setCodecPreferences方法来调整编码的顺序，把red放到opus之前。
opus+red is not active by default but can be activated through the setCodecPreferences API by changing the order of codecs such that red appears before opus. Note that in getStats opus+red will still be identified as “opus”.
webrtc::field_trial::FindFullName("WebRTC-Audio-Red-For-Opus");
m=audio 9 UDP/TLS/RTP/SAVPF 96 111
a=rtpmap:96 red/48000/2
a=rtpmap:111 opus/48000/2
- First packet was Opus (payload type 111);
- Second packet was RED (payload type 96), but “smallish”;
- Other packets were RED as well, but all larger and similar in size.
