miron@extropia.wimsey.com (Miron Cuperman) writes:
sdw@sdwsys.lig.net (Stephen D. Williams) writes:
Also, from a previous note, you wouldn't want to turn off V.42/V.42bis since that is where the error correction is. Also, even on compressed data, you get some additional bandwidth because it does packetized synchronous data. This gets close to 8bits/byte instead of 10 (start, stop).
I think that you *do* want to turn off V.42. V.42 does error correction by using error detection and retransmission. This introduces variable delay and throughput, which are unacceptable in a real-time application like voice.
I think that error correction through error correction codes is the way to go.
Exactly. v.42/v.42bis packetizes the data stream and, depending on the CODEC, would have adverse effects on voice quality. I don't know if CELP requires an error-free transmittion stream from codec to codec. If it doesn't then that's great, I hope it self-synchronizes itself after a byte or two of garbage coming through. Big deal, so you hear a click or pop of static, so what.. you get that with analog lines. On the other hand, since this stream will also be encrypted, it is unlikely that errors could not mangle the entire conversation, and screw up the encryption. A single byte of garbage can unsync both encryption/decryption sides and things could get very messy. Here's how to deal with error checking/correction. You CAN use v.42/v.42bis if both crypto-phones offer somekind of FIFO chip in between the modem and the crypto-chip. This can smooth out a packety/bursty stream into a smooth 24kbps data stream. However, the resending of large packets by v.42 might cause some wierd sound delays similar to what you hear on satellite circuits. The best solution, as suggested by Miron is to use forward error correction. There is plenty of bandwidth in a 19.2/21.6/24.0/28.8 kbps connection to send CELP nybbles or bytes each along with their own ECC code. I believe a 4 bits of CELP would require 3 bits of ECC. In any case, there is enough bandwidth on a 19.2 kbps modem carrier to send a fully encrypted and fully forward error corrected 9600 bps CELP stream. Let's assume we use a 4-bit ECC code for each 4 bits of data, thus doubling our bandwidth. Here's how it would look: 9.6kbps 19.2kbps sending: | | v v voice ----> CELP ------------> IDEA --- ECC -------------v coder 9.6kbps encryption coding raw 19.2 modulation v 9.6kbps 19.2k | receiving: | | | v v | voice <---- CELP <------------ IDEA <------ ECC ------+ decoder 9.6kbps decryption correction Thug