From: thug@phantom.com (Murdering Thug)
Date: Wed, 10 Feb 93 08:47:10 PST
To: cypherpunks@toad.com
Subject: Re: Compressed/Encrypted Voice using Modems
In-Reply-To: <1993Feb10.101337.17788@extropia.wimsey.bc.ca>
Message-ID: <m0nMKUy-000k1hC@phantom.com>
MIME-Version: 1.0
Content-Type: text/plain


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