我应该使用 RTP 还是 WebRTC 进行本地网络音频通信

Question

我有一套 Raspberry Pi Zeros，我想用作家庭对讲机。我最初将它们设置为使用带有 gRPC 和双向流的 golang 相互发送音频，这适用于短时间调用，但随着时间的推移会出现延迟，所以我认为我需要切换到实时协议，如 RTP 或 WebRTC .由于我已经知道每个设备的 IP 地址，并且每个设备的硬件/支持的编解码器是相同的，而且它们都在同一个网络上，使用 WebRTC 比使用普通 RTP 有什么优势吗？我的理解是，WebRTC 主要提供了一些额外的安全性和连接编排，例如 ICE 和 SDP，我不一定需要这些。我试图尽量减少资源使用，因为这些设备不如手机或台式机强大。如果我确实使用 WebRTC，我可以使用 gRPC 或其他一些直接传递方法来发送 SDP 信号。由于有超过 2 个设备，我也对多播功能感到好奇，似乎纯 RTP 特定，而 WebRTC（使用 RTP）不一定支持多播，并且需要 @ 987654321@ p2p 连接。我对这一点非常不清楚/不确定。

另外，是否支持本机混合音频通道，还是需要在自定义软件中处理？

Answer 1

您可以使用 WebRTC，但需要安装 signalling server 和 STUN / TURN server。这些可以是超级简单和低容量的，因为一切都在专用网络上，但你仍然需要它们。信令服务器处理必要的 SDP 交换。完全使用 WebRTC 可能会过度设计这一点。 （当然，学习如何让 WebRTC 工作很有用。）

您已经构建了一个 golang 基础架构。看看您在专用网络上的情况，您可以更改该程序以发送多播 UDP 数据包或 RTP 数据包。然后你可以让你的听众听他们的。

无论您做什么，都需要处理滞后问题。在数据包世界中做到这一点的一个好方法：不要建立一个准备播放的缓冲区队列。相反，始终将每个收到的数据包作为下一个播放数据包，即使您必须覆盖以前收到的数据包。 （也就是说，跳过。）您可能会偶尔收到一次弹出消息，但是对于合理短的数据包（低于 50 毫秒），它应该不会显着影响用户体验。并且滞后不会累积。

老式电话系统在整个大陆的 8K 同步时钟上运行。所以滞后不是问题。但是当音频模拟到数字和数字到模拟时钟不同步时，这总是一个问题。每当它们在不同的设备上时都是如此。随着时间的推移，最轻微的漂移会逐渐增加。 （RPis 中没有 50 美元的时钟部件，保证低漂移。）

如果您的所有音频源都以相同的采样率运行，您可以对它们进行平均以混合它们。那应该让你开始。 （如果您在浏览器中使用 WebRTC，它将为您混合多个来源。）

Answer 2

由于您使用的是 Go，请查看 offline-browser-communication。这消除了对信令和 STUN/TURN 的需要。它使用 mDNS 和预生成的证书。 WICG Discourse 也正在讨论它是否/何时会登陆。

“滞后”是通过 TCP 处理媒体时非常常见的问题。您正在处理大量队列和拥塞控制。 WebRTC（以及一般的 RTP）非常擅长解决这个问题。你有以下标准化的事情来解决它。

• RTP 数据包具有相对时间戳
• RTP 发件人报告具有相对于 NTP 时间戳的映射。将此用于同步/计时。
• RTP 接收器报告为您提供数据包丢失/抖动。使用它来维护您的网络健康状况。

多播也是一个绝妙的建议。您降低了必须为所有这些 1:1 连接发送信号的复杂性，并减少了所需的带宽量。不过，它确实使安全性更加微妙/滚动您自己的。

使用 Pion，我们解耦了所有 RTP/RTCP 的东西 Pion Interceptor。因此，您不必使用完整的 WebRTC 堆栈来获取上述媒体传输的内容。