很久没有查看Google Meet的webrtc统计数据了，所以上周我趁开会的时候看了看，有哪些最新的变化被添加进来了。
P2P连接
我检查的第一个变化是：如果线上会议里只有两个参与者，Google Meet是否仍使用P2P连接。令人惊讶的是，过去会议是包含P2P支持（有关P2P-SFU过渡的讨论）的，但现在已经被移除了。
这会增加基础设施的成本（对Google来说不是什么大问题），和一对一呼叫的端对端延迟。但考虑到Google Meet可能是部署在许多接入点上，所以可能增长不大。而且移除之后不必再处理另一种类型的连接和P2P-SFU过渡，操作更简单了，所以移除它看起来是合理的。
ICE Candidate和（NO）TURN服务器
Google Meet不再配置任何ICE服务器，他们的服务器为IPv4、IPv6和UDP（随机端口）+TCP（与UDP相同的随机端口）+UDP（3478端口）+SSLTCP（443端口）这几类提供candidate。
以下是iceServers的配置，里面有空字符串。
https://meet.google.com/_meet/xxx-xxx-xxx, { iceServers: [], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan", extmapAllowMixed: true }, {advanced: [{googScreencastMinBitrate: {exact: 100}}]}
其实不用TURN服务器不会有特别大的影响。因为这些服务器都支持SSLTCP，之前也在其他应用程序（如Jitsi或Houseparty）中看到它们。真正影响的可能是类似firefox的其他浏览器，和一些非常严格的，阻止SSLTCP使用伪SSL连接的代理/防火墙会缺乏支持。
RTP header新扩展
Google Meet一直在用header扩展，这次检查时我又发现了两个过去没有见过的header。
其中一个header扩展与新的AV1视频编解码器有关，提供了服务器可以用来对视频层进行选择性过滤和转发的可扩展性信息。值得思考。虽然Google Meet没有采用AV1，但这可能暗示了有了些进展，或在产品的内部版本中可能支持新编解码器
a=extmap:15 https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension
（Twitter的@murillo&@HCornflower认为，虽然这个header扩展是为AV1定义的，其实它也可以用于VP9，快速嗅探实验说明这个结论是正确的）
另一个header扩展提供了各层的目标比特率、分辨率和帧率的信息，这样服务器就可以利用这些信息来决定转发哪一层，而不是像如今SFU那样，根据收到的比特率来做决定。这样做的好处是，这个值比计算出来的值更稳定、更可靠，因为计算出来的值可能会有瞬时的异常（temporal spikes），而且网络和逐步加快的实现，甚至发送的内容都会影响这个值。
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00
特殊RTP控制信息——RTCP
在SDP协商中，我发现有几个RTCP功能值得思考。
第一个是叫做RRTR的新RTCP信息。其实也不算新消息，因为它在很久以前就被标准化了（RFC3611），但目前我还没看到过它被采用的实例。RRTR信息和与DLRR相对应的目的是能够计算接收流的往返时间，计算方式类似于用SR和RR信息计算发送流的方式。基本上就是RRTR发送一个时间戳，DLRR返回原始时间戳以及RRTR和DLRR消息间的延迟。
a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc
第二个功能是Google Meet允许transport-cc RTCP消息也能使用音频数据包进行带宽估算，而不是像大多数平台那样，只能使用视频数据包完成该操作。这样做在过去风险很大，但显然现在已经足够安全了。这种情况下启用它看起来是个明智的选择。
a=fmtp:96 useadaptivelayering_v2=true; useadaptivelayering=true
视频编码
Google Meet采用VP9和用户配置文件0。但由于不知名原因，如果有来自Firefox浏览器的用户加入会议时，Meet会回到VP8。视频编码一个有趣的点是SDP协商中的 “useadaptivelayering” 属性。这个属性面世已经有一段时间了，而且有两个版本。但在Chromium/WebRTC的开放源版本中并没有这个属性，在Chrome二进制中也没有。所以我猜想它可能只适用于libwebrc的旧版本或自定义版本（比如手机？）
a=fmtp:96 useadaptivelayering_v2=true; useadaptivelayering=true
音频编码
如我所料，Google Meet采用了opus（启用了dtx和inbandfec）。但最有趣的是，冗余编码（RED）的使用也被协商用于音频通道。这种编码允许在需要时发送同一数据包的多个副本，来提供更强的稳健性，以防数据包丢失（详见WebRTCHacks中对RED的详细分析）。
但即使RED被协商了，它也不是真正的主动发送，因为它被包含在opus之后的编解码器列表中。经过嗅探实验我发现，RED引入了15%的数据包丢失。同时我也检查了其发送和接收的数据包有无异样。
a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1; stereo=0; sprop-stereo=0; usedtx=1 a=rtpmap:63 red/48000/2
媒体采集
检查的最后一项是麦克风和摄像头所需的配置。我发现了件有趣的事：帧率被明确限制在24fps，而默认值通常为30fps。
Video constraints: {deviceId: {exact: [“xxxxxxxxx”]}, advanced: [{frameRate: {min: 24}}, {height: {min: 720}}, {width: {min: 1280}}, {frameRate: {max: 24}}, {width: {max: 1280}}, {height: {max: 720}}, {aspectRatio: {exact: 1.77778}}]}
Google Meet还有一些有趣的点，比如单端连接的使用（除了用于屏幕共享的额外连接）；总是从浏览器端创建的offer；3个及以上的收发器或音频编解码器选择（VP9）的复用，但这些点已经存在有一段时间，且已经有其他人讨论过了。就不在此赘述了。
原文作者：Gustavo Garcia
