从零上构建IP上的语音

我不认为我会做到这一点。一个简单的事实是，在传输之前收集两秒钟（甚至一秒钟）的语音数据会使您失去很多，并且什么也没获得。

与普通的开放协议相比，您可以在许多地方简化协议。典型的协议具有多种选择，用于多种传输速率，存在检测，NAT遍历，多个编解码器等。它们使正常的语音聊天程序相对复杂。通过消除其中的大多数，只是预选了一组选项，您可以大大简化代码。

但是，每几毫秒发送数据包不是很困难的。每隔几秒钟发送每隔几秒钟就不会使您的代码变得更加简单。如果有的话，这可能会使代码更加复杂，因为您必须处理更多的数据。在典型的情况下，您一次只处理几千字节的数据，因此存储几乎完全不是问题。如果您在传输之前存储大量数据，则存储数据将开始成为一个更加实质性的问题（尽管公平地说，这仍然不会非常困难）。

就个人而言，我认为我仍然使用一些标准编解码器，因此，如果您决定这样做，则代码和协议将很容易（或者无论如何，无论如何还是更容易）扩展到更完整的内容。例如，如果我想尽可能简单，我可能会首先使用G.711编解码器。即使是支持两种形式的压缩形式（MU-LAW和A LAW），因此我可能会选择其中一种（可能是法律），然后使用它。

使用它，实际的编解码器（压缩/扩展代码）应在100行代码下（可能接近50行），这取决于您喜欢如何格式化代码）。如果需要，可以从G.191中的ITU下载参考实现（注意：G.191还包括许多其他编解码器的代码）。

可以免费提供一定程度的压缩。关于同样重要的是，这意味着您将构建代码，以便在发送数据之前调用编码器以编码数据，并在收到数据后解码数据。如果您决定增强代码，您最终会选择其他编码器/解码器，而不是尝试添加以前不存在的地方（在这种情况下，您更有可能需要完整的重写）。

G.711旨在一次在样品的缓冲区上操作。支持的缓冲尺寸为40、80、160和320个样品。如果您不关心延迟，那么320个样本将是明显的选择。使用此过程，您可以从输入（麦克风）中读取320个样本，将其发送到压缩机，将结果放入UDP数据包中，然后将其运送到电线上。根据需要重复。您可能想在UDP数据包中包含一个序列编号，因此接收端可以按顺序播放后数据包。同样，我可能会遵循标准。RTP足够微不足道，它可能只添加了另外几十行代码左右（甚至可能比那少）。

为了尽可能简化，接收代码最初可能会忽略整个RTP标头，而只需接收一个数据包，解码有效载荷，播放它并重复。稍后，当/如果发现数据包丢失和重新排序是一个问题时，您可以添加代码以查看序列编号和/或时间戳，并采取相应的行动。

这里的重点是等待2秒（或其他）不会使您的代码变得更简单。如果有的话，一次使用固定数量（相当少的）样本可能会使代码变得更加简单。您可以预先分配您关心的大小的几个缓冲区，然后使用它们，而不是像一次缓冲几秒钟的数据一样处理动态分配。

如果您在传输音频之前等待2秒钟，那将不会像对话。如果延迟超过100毫秒，大概200毫秒。

其次，VOIP应用程序通常是为了与他人交谈。在您的应用程序达到世界上的统治力之前，这可能是一个好主意，这是一个既定的VoIP协议之一（H.323或SIP）的好主意，以便您可以与他人交谈。只是一个想法。