作者：Gustavo Garcia（原文链接）
翻译：刘通
Slack现在的火爆程度与Uber不相上下，并且拥有快速增长的通讯工具，集成了各种WebRTC服务器。Slack在一年以前收购了一个从事WebRTC技术的公司，并且在今年上半年推出了他们自己的音频会议服务器，我们在这两篇文章中进行过分析（点击查看，点击查看）。这周较早的时候，视频服务器也上线了。它们的工作是一样的吗？在Slack的实现过程中是否有什么窍门是我们可以学来的呢？很长时间以来WebRTC领域的专家，webrtcHacks的客座作者，Gustavo Garcia都在研究Slack的全新上线的视频会议，下面我们就来拨开它的面纱看看下面的真面目。
今年早些时候，Slack增加了使用WebRTC技术的音频通话服务。没过多长时间Philipp Hancke就写了一篇博客来分析它。Yoshimasa Iwase随后也对其进行了更细节的分析。
这周Slack宣布了视频功能上线，这再一次让WebRTC的圈内人兴奋了一把。今天我们一部分人第一时间看到了它上线，所以我们做的第一件事是什么？我们举行了一个会议来快速的规划我们能用这个做什么。为了能够窥探Slack关于WebRTC的工作，我们进行了几个简短的对话，在Chrome的webrtc-internals中观察SDP和其他可用数据。
没有TCP或IPv6
在webrtc-internals里你看到第一个东西是他们还在用TURN UDP并且关闭了IPv6：
Slack的最终目标是成为一个企业通讯工具。“企业”意味着会阻拦任何“可疑”UDP传输的用户。知道了这点，企业就会希望得到TURN TCP和TLS的支持，但出人意料的是Slack并没有这么做。同样的事也发生在IPv6上面—也许在Janus或者Slack信令堆栈中有些问题，但是在未来的版本中是容易改变的。
媒体服务器平台
接下来看到的是从服务器来的SDP：
就像预想的那样，我们看到Slack仍旧使用了很好的开源SFU，叫做Janus。
同播
当前在讨论多方WebRTC的时候，一件有趣的话题是如何对不同的参与者实施带宽适配。在SFU领域中，有一项关于同播的约定。同播技术已经产生几年了，但是WebRTC方面的标准和支持还没有完善。结果就是，还有很多同播的服务器没有得以使用。Slack使用了同播技术是一件好事情，越来越多的人除了Google的Hangouts和TokBox以外开始使用它了。
仔细的来看一下Slack的SDP，在请求中看SIM组以及在应答中看x-google-flag:conference就可以发现同播技术在这里得以使用。
使用同播技术的好处之一是可以在更深的间隔尺寸中自动的开启临时延展性。我对不同网络环境下接受到的帧速率做了一个简单的检查，而且结果很显然Slack还没有用这项功能。
另一个有意思的地方是经常检查他们是否使用了多数据流对等端连接。在Slack这个案例中，他们使用了一个新的RTCPeerConnection给每个发送方和接收方。这么做有一点点效率低，是因为有一些额外负载以及多余的建立时间。但是，在实施上要方便很多，所以在今天这是一个非常受欢迎的选择，因为没有办法在单一的，浏览器间方向上进行多数据流对等端连接。
Codecs
在codec方面我们没有看到任何的惊喜，Slack使用的还是Opus和VP8。这是在预料之中的，因为Chrome还不支持使用H264的同播。但是依旧很有意思的是，当一方没有在说话的时候他们在OPUS中使用了不连续传输来节省音频通道的带宽。如果将这种分析方法拓展到移动设备的话是一件很好的事情，可以查看他们是否使用了同样的codec。
讲话者活动性检测
Slack一个有意思的特点就是视频可以自动的切换到只显示当前正在说话的有效讲话者。看一下Chrome的控制台，你可以看到讲话者活动性的清单是如何使用信令通道进行传输的。这意味着讲话者的活动性是在服务器端检测的。这项检测有可能是通过SDP的音频等级的报头延伸来完成的。其中包括了RTP包中的声音标识。这项技术因为不需要任何音频解码，所以从媒体处理的角度上来讲是很廉价的。另一个很有趣的地方是，从没有被显示的参与方所接收的比特率得到了降低，但是出于种种原因并不是完全不会收到，而是保持了接收数据包在100kbps左右的速率。也许是与最低同播质量有关。
ICE连接
为了连接的建立和解析，我们看到ICE和DTLS得到了使用。这里使用的是一个完整的ICE实现而不是想我们在很多SFU中经常看到的简化版。一个好奇的地方是，SFU是否返回了两个不同的IP地址作为候选地址，而且这两个都是私有地址？我想不到有什么合理的理由来解释这个，而且这看起来像是一个会拖慢ICE建立速度的一个架构问题。
