3 ms·

But the point of compression is, you wouldn't transmit a bunch of zeroes. You would transmit "here go 285 zeroes" or "here go 403ms silence". Which is far less

by corty 6y ago

But the point of compression is, you wouldn't transmit a bunch of zeroes. You would transmit "here go 285 zeroes" or "here go 403ms silence". Which is far less data than the equivalent time in non-silence. Really transmitting the zeroes as they are is just transmitting uncompressed PCM, which is the trivial solution. Adding filler is undoing most of the compression. The hard part is to add just enough filler, jitter and confusion for an attacker to be sufficiently blinded while maintaining an acceptable compression ratio.

quonn 6y ago
> Adding filler is undoing most of the compression. Really? Would I not just get a not quite constant stream of (unencrypted) data that‘s small enough to send at a low bandwidth? And when that data arrives at less than the maximum bandwidth of the channel that I actually use, I just add some filler. And then I encrypt that now really constant stream of data.
beagle3 6y ago
Basically all audio codecs meant for real time communication are built to maintain constant but rate — because even though it is nice to save a few bits occasionally when you can, you can’t use present silence to encode future speech (you haven’t heard it yet...); So, no. The filler is part of the protocol and is not undoing any of the PCM compression; silence would let you compress the stream more than the plain voice codec would - and THAT would interact with encryption. But that’s quite unusual for real time systems.
- corty 6y ago
  Not really. Silence is encoded with silence frames containing just a length of silence marker in most VoIP protocols. On the receiving end, silence frames are then filled with "comfort noise". If you pay attention and have a crappy phone you can hear this, because the comfort noise generator will produce noticably different "silence". Yes, one often does CBR, but even there, variable difficulty of compression often produces variable jitter, which can then be used to infer information about the plaintext stream. There are constant runtime CBR codecs, but one has to take care to use them.

by corty 6y ago

quonn 6y ago

> Adding filler is undoing most of the compression. Really? Would I not just get a not quite constant stream of (unencrypted) data that‘s small enough to send at a low bandwidth? And when that data arrives at less than the maximum bandwidth of the channel that I actually use, I just add some filler. And then I encrypt that now really constant stream of data.

beagle3 6y ago

Basically all audio codecs meant for real time communication are built to maintain constant but rate — because even though it is nice to save a few bits occasionally when you can, you can’t use present silence to encode future speech (you haven’t heard it yet...); So, no. The filler is part of the protocol and is not undoing any of the PCM compression; silence would let you compress the stream more than the plain voice codec would - and THAT would interact with encryption. But that’s quite unusual for real time systems.

corty 6y ago
Not really. Silence is encoded with silence frames containing just a length of silence marker in most VoIP protocols. On the receiving end, silence frames are then filled with "comfort noise". If you pay attention and have a crappy phone you can hear this, because the comfort noise generator will produce noticably different "silence". Yes, one often does CBR, but even there, variable difficulty of compression often produces variable jitter, which can then be used to infer information about the plaintext stream. There are constant runtime CBR codecs, but one has to take care to use them.