Re: Compressed/Encrypted Voice using Modems

> And why are you limiting this to V.32 (9600bps)?  V.32bis (14.4k bps) modem
> chips cost maybe 20% more than v.32 chips in quantity.
> 
> Even higher speeds are available if you're willing to go that far.  Zyxel
> v.32bis modems have proprietary 16.8 kbps and 19.2 kbps full duplex raw
> modulation rates, but they use DSPs instead of modem chips like the
> ones from Rockwell, AT&T, and Intel.  I believe there are some v.FAST
> (not CCITT compliant) modems like the one's from Motorola (Codex) that
> can do 21.6 kbps and 24.0 kbps.  I believe the final speed of v.FAST once
> standardized by the CCITT will be 28.8 kbps.

I don't see how a 28.8kbps (raw) data rate is possible, as the Shannon
limit for a POTS line is 22kbps.  Certainly parts of the phone system
no longer impose the narrow bandwidth that are part of the 'spec', but
one can not always depend on getting a line that exceedes the published
parameters of the phone system.

The Rockwell (RC96AC/RC96ACL/RC144AC/RC144ACL) modem chip (set) has an
on-board codec that does ADPCM in hardware.  It makes for a very nice
programable answering machine.  Interestingly, the designers guide has
someting to say about bit rates.

At a sampling rate of 7.2 KHz, (the only sample rate this chipset
supports) 8 bit samples are presented at a bit rate of 57600 bps.  Add
in a start/stop bit, and you now need a DTE rate of 72,000 bps.  Most
UARTS don't support this rate, and thus you will need to find one that
will run at 115.2 Kbps.

Drop to 4 bit samples, and you get a bit rate of 28,800 bps, for a
required async DTE speed of 36,000.  (or 38400 bps on most uarts.)

I'm also fairly sure that recent Zyxel modems (e.g. the U-1496) use
this Rockwell chip(set), and not a dedicated DSP.

Jim

jim@tadpole.com writes:
> thug@phantom.com writes:
> > Even higher speeds are available if you're willing to go that far.  Zyxel
> > v.32bis modems have proprietary 16.8 kbps and 19.2 kbps full duplex raw
> > modulation rates, but they use DSPs instead of modem chips like the
> > ones from Rockwell, AT&T, and Intel.  I believe there are some v.FAST
> > (not CCITT compliant) modems like the one's from Motorola (Codex) that
> > can do 21.6 kbps and 24.0 kbps.  I believe the final speed of v.FAST once
> > standardized by the CCITT will be 28.8 kbps.
> 
> I don't see how a 28.8kbps (raw) data rate is possible, as the Shannon
> limit for a POTS line is 22kbps.  Certainly parts of the phone system
> no longer impose the narrow bandwidth that are part of the 'spec', but
> one can not always depend on getting a line that exceedes the published
> parameters of the phone system.

Then how come Hayes demonstrated their v.FAST modems at Fall Comdex '92 in
Las Vegas.  According to the report on Comdex I am reading, the Hayes
modem dialed up another modem at Hayes headquarters in Atlanta and set
up a perfect 28.8 kbps full duplex raw data link.  With v.42bis the two
modems were exchanging text at close to 115.2 kbps.

> The Rockwell (RC96AC/RC96ACL/RC144AC/RC144ACL) modem chip (set) has an
> on-board codec that does ADPCM in hardware.  It makes for a very nice
> programable answering machine.  Interestingly, the designers guide has
> someting to say about bit rates.
> 
> At a sampling rate of 7.2 KHz, (the only sample rate this chipset
> supports) 8 bit samples are presented at a bit rate of 57600 bps.  Add
> in a start/stop bit, and you now need a DTE rate of 72,000 bps.  Most
> UARTS don't support this rate, and thus you will need to find one that
> will run at 115.2 Kbps.

This is way more than what is needed for telephone quality audio.  I
have programmed voice mail systems based on Dialogic hardware.  They use
a simple ADPCM codec and 6,000 4-bit samples/second.  This gives you
a audio bandwidth of 3khz, basically telephone quality.  At this rate,
we're talking about 6,000 x 4 bits = 24,000 bps.  And this is WITHOUT 
any kind of advanced compression.  A v.FAST modem doing 24.0 kbps
like the Motorola Codex can handle this now, and 28.8 kbps modems
can handles this and provide a 4kbps digital subcarrier for carrying
data with voice.  For instance, I could be having an encrypted conversation
with you and at the same time, I can send you a spreadsheet file at 4 kbps.
Obviously since the entire 28,800 bps stream would be encrypted, the
spreadsheet file would be encrypted as well.

You can also get excellent quality using 4800 samples/second using 3-bit
ADPCM samples.  This would give you 14,400 bps and an analog bandwidth
of 2400hz.  This is lower than phone quality which is 3000hz, but anything
above 2400hz is really useless for transmitting a male speaking voice
which hardly ever goes past 2000hz.  A female voice on the other hand might
sound somewhat distorted if everything above 2400hz is chopped off.  However,
using a DSP, one may shift the 0-2400hz bandwidth to 300-2700hz using a
toggle switch.  Thus all a female would have to do is toggle a switch on
the cryptophone to tell the other side about the shift.
 
> I'm also fairly sure that recent Zyxel modems (e.g. the U-1496) use
> this Rockwell chip(set), and not a dedicated DSP.

No, Zyxel uses a DSP. They are always updating their DSP roms to provide
new features.  Not only do Zyxel modems provide v.32/v.32bis/v.42/v.42bis,
and MNP 1-5, but also MNP 10, Caller ID, Voice Mail, and proprietary
16.8 kbps and 19.2 kbps full duplex modes. 

As soon as ISDN hits the streets, we won't have to worry about bandwidth
since it will be quite easy to build an all-digital crypto-phone that
provides end-to-end encryption based on a public key system.

Picture this: an ISDN phone that can operate in normal or encrypted mode,
that has a small 20mb 1.8" hard disk or flash eprom card to store the public
keys of all the people that you converse with who have similar phones.  In
fact, it is possible to set up a trusted centralized public key directory
assistance like service, which would contain perhaps everyone's public key,
and could be queried automatically at the beginning of each call.  The 20mb
storage could be a public key storage cache for people you call frequently,
while the public key directory assistance is used for people who you only
plan to call once.  On the other hand, a centralized authority is always
bad when it comes to security.  A PGP-like scheme of decentralized public
key distribution is much safer.  If Bob wants to give Mike's public key
(which is stored in Bob's phone) to Joe, all Bob has to do is call up
Joe, tell Joe that he that he wants to give him's Mike's phone number and
public key. Bob then presses a button on his phone and instantly uploads
Mike's public key to Joe's phone, either via a digital subchannel, or
via the main channel (and interrupt the conversation for a few seconds),
like the old video phones used to do to transmit still frames. 
 

Thug

> 
> I don't see how a 28.8kbps (raw) data rate is possible, as the Shannon
> limit for a POTS line is 22kbps.  Certainly parts of the phone system
> no longer impose the narrow bandwidth that are part of the 'spec', but
> one can not always depend on getting a line that exceedes the published
> parameters of the phone system.
My impression was that most of the new systems dealt with variable 
bandwidth automatically.  28.8kbps might only be acheived on a higher
quality line.  The stated rates are max, not nominal.
> 
...
> I'm also fairly sure that recent Zyxel modems (e.g. the U-1496) use
> this Rockwell chip(set), and not a dedicated DSP.
They told me they use their own design 'datapump', and I know they use
a 68K (I swapped the rom in mine).
> 
> Jim
> 

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 get around 1760cps for LZW (zoo/compress) data.
This is Zyxel to non-zyxel (Cerfnet or World).

sdw

-----BEGIN PGP SIGNED MESSAGE-----

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.

- -- 
        Miron Cuperman <miron@extropia.wimsey.com> | NeXTmail/Mime ok
                       <miron@cs.sfu.ca>           | Public key avail
        AMIX: MCuperman                            |
cyberspacecomputingcryptoimmortalitynetworkslaissezfaire

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK3i7lZNxvvA36ONDAQF3sQP+Ibesz2FVTGLfWL0Xsjj5X1jFkEU807va
+qpmDLDGghgdM5xCpc+Xv8Zl8lJx356WMPrbZfdshumXtmjsqf33Wq6fcAUse87k
6nsPiTkDpWnsga9g6oKUjPjTuQUcdk7VzrosJ+l3MAnvhQ0bD1TJD2ySIQk8NIPV
+uGM5Ore+6Q=
=7ViZ
-----END PGP SIGNATURE-----

New signature on my key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.1

mQCNAiqvJ10AAAED/jXfntqmsRjJRYoxYTxLO7obzMfzgUNtSDEawb3Suj4UO1xq
uARc25PJNAHQhIa83Yxf9z/R/3AjwmYrZqxvB2RkLPTjTmzQd04fypsZToiR/TlM
5F43JCuCM779mAir9Idy1CQzXQ2bn89eUZaVhOUJzNgndl+wLpNxvvA36ONDAAUR
tCxJbW1vcnRhbCBGcmVlZG9tIDxtaXJvbkBleHRyb3BpYS53aW1zZXkuY29tPokA
lQIFECtQgZGoEwOvWCFMNwEB4ecD+wdqaIGhJgfhlY+ypQwmgN3ytgUi/MjgmUdT
B2qfjRj0uhyXOPegSQ+n0ZF4wHEo1a2osdAo387iYHNebqAOv1+3xM10beI/RNT1
dZwUcm/LXwuCRACAqlL5lB5cQNy4ZbG/QvioAWYqqq6g9ftiI6Z1nkvZ6mIb9QZv
WBCysIj8iQCVAgUQKxc8tJNxvvA36ONDAQG/bQP+Mgq7zP0M/7BMstZhllrH3Cck
nNGQP3/+QUALSKzosw0xJJfTIbA4+aoQjvXQFKi+5MCU0GaoGsyuXQGnluzGkI3w
XDcxzR7Hl97V5+hyRWNc0sw/QbimWvQAUwDgpc0T4x/AsUx34Zx3G5+ujTIqgHKC
wfBD6ib6u61E8jLz38+JAEUCBRArDHAdS60iYsR4D/cBAZCdAXwPRl2uvP6QwCC4
4A0GFufGbm3NqThNaDfuGn+JTYIR8htb8hRUg8SM2G8zpyNnWNA=
=AVXx
-----END PGP PUBLIC KEY BLOCK-----

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

-----BEGIN PGP SIGNED MESSAGE-----

thug@phantom.com (Murdering Thug) writes:

>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.

CELP resyncs.  Not sure how fast.  Maybe after a tenth of a second or so.

On a side note, we are finishing up an implementation of CELP on the
TMS320C5x.  This is a 20 MIPS integer chip.  We are taking up less
than 15 MIPS.  We also know how to write error corrected CELP (such
that bits that cause more significant degradation are protected
better).
- -- 
        Miron Cuperman <miron@extropia.wimsey.com> | NeXTmail/Mime ok
                       <miron@cs.sfu.ca>           | Public key avail
        AMIX: MCuperman                            |
cyberspacecomputingcryptoimmortalitynetworkslaissezfaire

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK3lZpJNxvvA36ONDAQEdNAP9EAcRyDEoREWnftWMQqEGt2arHVttqkRQ
PUjPFIsoaIR8s+D7cAjoJUa3Hl6c9n93N7epBKCz0XqbsHdk2ihQJG9vez9oI0wG
RnIv3RUK9GfKJ6fhDppagoQESDCTvMyjYjG8XBsk8aFEM0pvPCQkhsZnEbCkzdYu
xYSh1f7lsZU=
=xy4W
-----END PGP SIGNATURE-----

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> thug@phantom.com (Murdering Thug) writes:
> 
> >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.
> 
> CELP resyncs.  Not sure how fast.  Maybe after a tenth of a second or so.
> 
> On a side note, we are finishing up an implementation of CELP on the
> TMS320C5x.  This is a 20 MIPS integer chip.  We are taking up less
> than 15 MIPS.  We also know how to write error corrected CELP (such
> that bits that cause more significant degradation are protected
> better).

Does everyone know that the new Zyxel's have CELP builtin?

Don't know details yet...

sdw