为我所用
由于我们可以控制本机库，因此我们在本机应用程序中所做的某些操作与您在浏览器的WebRTC中所看到的有所不同。
首先，WebRTC根据SDP在用户之间传输音频/视频信息（往返大小可能接近10 KB）。WebRTC本机库使我们能用WebRTC（即webrtc :: Call）中较低级别的API来创建发送流和接收流。在加入语音通道时，我们交换的信息量很少，包括语音后端服务器的地址和端口、加密方法和密钥、编解码器以及流标识（大约1000个字节）。
此外，WebRTC使用ICE来确定参与者之间的最佳通信路径。由于每个客户端都连接到了我们的媒体中继服务器，因此我们不需要ICE。当您处于NAT时，我们可以提供更可靠的连接，并且使您的IP地址不对通道中其他人可见。客户端会定期发送ping消息，以确保防火墙始终保持打开状态。
最后，WebRTC使用SRTP进行媒体加密。密钥使用DTLS设置，DTLS是基于用户每天在浏览器中使用的传输层安全性协议运行的。本地WebRTC库让您可以使用API webrtc :: Transport来建立自己的传输层。
而我们决定使用更快的Salsa20代替DTLS / SRTP来加密。此外，我们避免在静音期间发送音频数据，这种情况经常发生，特别是在人数较多的情况下。这样做确实可以节省大量带宽和CPU，但是客户端和服务器都必须随时准备停止接收音频数据，并重写音频/视频数据包序列号。
因为我们的浏览器应用程序使用浏览器WebRTC API，所以我们使用了SDP / ICE / DTLS / SRTP。我们在客户端和服务器之间交换所有必要的信息（往返少于1200个字节），并且从客户端的这些信息中合成SDP。我们的语音后端基础架构负责弥合桌面和浏览器应用程序之间的差异。
后端架构
市面上有好几种后端服务支持语音，但今天我们将重点介绍其中的三种：Discord Gateway、Discord Guilds和Discord Voice。我们所有的信令服务器都是用Elixir编写的，可以进行大量代码的重复使用。
当您在线时，您的客户端会保持与Discord Gateway的WebSocket连接。通过Gateway连接，您的客户端可以接收到行会、渠道、消息、状态等相关事件的信息。
当您接入某一语音通道时，连接状态由voice state object表示。客户端使用Gateway WebSocket连接来更新voice state object。
当加入语音通道后，您将被分配给一个Discord语音服务器。 Discord语音服务器负责将每个成员的音频传输到通道。同一行会中的所有语音通道都会被分配给同一台Discord Voice服务器。如果您是行会的第一个开语音的，那么Discord行会服务器负责使用以下所述的过程，将一台Discord Voice服务器分配给行会。
文章作者：Jozsef Vass
