Re: Peer-to-peer voice text encryption
@Mike16: Well you are mixing up a lot of things.
First of all if your landline provider is using codecs like G.729 you should seriously be considering to swap them for someone who knows what they are doing. There is no reason to use that codec as the licensing costs are far higher than the bandwidth costs. Any sane telephony provider will give you G.711 (either a or µ depening on the continent) which is the same as used on ISDN.
Then there's really bad CPEs. One of the main problems with VoIP is that both the transmitter and the receiver need to run at precisely the same clock. That either requires you to have a precise crystal oscillator, or to estimate and compensate your clock error via NTP. For some reason many CPEs do neither of those. So you'll end up with your transmitter transmitting frames with 8001 Hz sampling rate, and your receiver playing them with 7999 Hz. After a short while the timing difference will have made up a frame, and a frame gets dropped... many modem standards don't like that at all.
So modem transmissions do work, if you have a decent CPE and a decent voice provider. In fact on many voice providers you can even use ISDN transparent data transfers. Most protocols based on that can easily cope with the frame slips mentioned above, so that's even rather solid with cheap equipment.
However I'm talking about something else here: Imagine you have a mobile phone to mobile phone phone call. Both phones speak, lets say AMR as a codec. In the past this would have been transcoded to G.711, sent to the other carrier, and transcoded back to AMR. That is however expensive (proprietary voice codecs cost a _lot_ of money per channel) and decreases the quality of the call. Therefore phone companies try to avoid this more and more. Therefore they try to just send the data through verbatim.
Usually your codec turns voice into bits. Who says you need to actually encode voice? For the network bits are just bits. So if you bypass your voice codec and just send raw data, you will get those data on the other end. (provided there is no transcoding)
So essentially you'd start your call, and for the first second or so you transmit some bit pattern which would decode to some non-annoying noise. You can do that on both ends and detect a compatible peer. Then you know you have a bit transparent channel you can negotiate your encryption on. Once you are finished, you use a codec with a slightly lower bitrate and use the rest of the bits to work on renegotiating the next key while you encrypt your voice data.
The best thing about this is that your call will just look like any normal call. Your telephony provider has no idea its encrypted as the signaling is normal. This also would automatically work without any manual negotiation. If you happen to dial a compatible phone, it'll all happen automatically.