WebRTC本身是一组技术的集合，基本上考虑到了音视频通话的方方面面，但是要把它用起来也并不容易。要自建WebRTC服务，除了要考虑信令服务器和NAT防火墙穿透外，在多人通话中你还需要考虑用选择发送单元（SFU）或多点控制单元（MCU）来控制通话信息路由。Slack在其工程博客介绍，它采用了Janus来作为自建的SFU，同时进行了大量的性能优化。这只是WebRTC应用开发中的其中一例。
受访嘉宾介绍
Raj Kumar， Slack视频组高级主管工程师。毕业于卡内基梅隆大学电子工程专业，WebRTC视频编解码专家，全栈工程师，擅长多媒体领域数字信号处理。先后就职于Apple, Internet Archive, Flurry Live。任职苹果公司工程师期间负责QuickTime Video编解码研发工作，获得十项研发专利。
InfoQ：Slack为什么会选用WebRTC技术？
Raj： WebRTC的一个很大优势是它内置在当今的Web浏览器中。在WebRTC之上构建您的产品，意味着用户可以在Web浏览器中启动应用程序，无需安装任何插件或下载任何其他软件。
内置在Web浏览器中的WebRTC技术不仅可以提供一流的用户体验，同时也使得不同产品之间的协同变得轻而易举。例如，Slack用户可以使用Slack Calls进行视频通话，也可以使用与Slack集成的任何一款第三方的视频会议应用程序。这些应用程序能够与Slack无缝地链接在一起。
使用WebRTC的另一个优点是，当由Google主导的WebRTC团队对产品进行改进时，基于WebRTC而构建的所有应用程序都可以快速获得相应的改进。例如，当WebRTC团队优化回声消除或带宽估计算法时，所有的WebRTC应用程序也都可以立即使用这些成果。
实时通信是由采集、编码、前后处理、解码、缓冲、渲染等多种技术组成的集合体，WebRTC提供了前端实现和编解码，如果开发者要商用，还需要做不少的开发部署工作，来提供可用性。
InfoQ：我们在网上看到了一些评论，说WebRTC会占用非常高的CPU计算资源，这是怎么回事呢？
Raj： WebRTC中最消耗计算资源的组件是视频编码器。在大多数平台上，视频编码和解码都是在软件中执行，而不是使用专用的硬件编解码器。好消息是，这种情况正在缓慢地改善。
WebRTC允许使用VP8、VP9或H.264视频编解码器。H.264编解码器的硬件支持适用于大多数的移动平台，现在我们开始看到WebRTC应用程序已经在iOS和Android上通过使用H.264来获得更好的性能。在桌面系统支持方面，WebRTC的H.264硬件编码目前还不能像在移动系统上那样获得广泛的支持，还不能在浏览器中启用。
此外，WebRTC在使用H.264时还不支持诸如Simulcast或Scalable Video Coding之类的技术。需要这些功能的应用程序主要使用VP8或VP9编解码器，这些编解码器还没有在大多数平台上获得硬件支持。对WebRTC编解码器的硬件支持将有助于减少我们今天看到的高CPU使用率问题，不过这些问题正在解决之中，预计还需要时间。
InfoQ：当您在Slack部署WebRTC时，遇到的最大的技术问题是什么？
Raj： Slack可以为Mac、Windows和Linux桌面，以及iOS和Android设备提供客户端。我们面临的一个挑战是使所有客户的WebRTC库保持同步，并为每个客户端团队提供本地平台的高级WebRTC API。
为了应对这些挑战，我们打造了一个构建系统，该系统可以让我们的Android团队通过Java界面，让我们的iPhone团队通过Objective-C界面，让我们的桌面团队通过C ++界面，对WebRTC进行协同编译。该系统让我们的团队可以专注于建立强大的客户端，而不必担心WebRTC代码的接口问题。
InfoQ：关于如何使用WebRTC，您可以向我们的读者提供一些建议吗？
Raj：通过WebRTC，任何人都可以轻松地访问强大的应用程序。您只需少量的Javascript操作即可将视频会议添加到您的应用程序中，并且由于WebRTC可以在浏览器之间进行点对点的连接，因此您无需托管视频服务器就可以部署出应用程序。
WebRTC仍然是一种新兴的技术，与之相关的质量演进还需要比较长时间，应用场景都有很大空间可以挖掘，所以对开发者来说，现在是构建自己的应用的很好时机！
