1993-11-01 - Re: Secure Phone Progress (fwd)

Header Data

From: jim@Tadpole.COM (Jim Thompson)
To: mg5n+@andrew.cmu.edu
Message Hash: 61def0f5421fe178e3f4b0d0de830c0635a4d90452df2ed7a0d6f8fb910c772a
Message ID: <9311010328.AA04235@tadpole.Tadpole.COM>
Reply To: N/A
UTC Datetime: 1993-11-01 03:29:39 UTC
Raw Date: Sun, 31 Oct 93 19:29:39 PST

Raw message

From: jim@Tadpole.COM (Jim Thompson)
Date: Sun, 31 Oct 93 19:29:39 PST
To: mg5n+@andrew.cmu.edu
Subject: Re: Secure Phone Progress (fwd)
Message-ID: <9311010328.AA04235@tadpole.Tadpole.COM>
MIME-Version: 1.0
Content-Type: text/plain


Most (US-based) phone equipment can't deal with clear channels, (ok,
long strings of zero data) thus, a DS0 (the cannonical single voice
call) operates with one bit always set 'on', so your 64kbps channel is now
a 56kbps channel.  4:1 compression would get you to (just) inside the magic
'14400' bps limit of v.32bis signaling.  Such algorithms exist, though their
performance on data with characteristics like 'voice' is poor at worst.

CLEP is a speech encoding algorithm (compressor) that can work well inside
a 4800bps channel.  It is, however, quite expensive in terms of CPU power.
A DSP would help here.  :-)  CLEP also tends to diminish the dynamic range of
its input, with a resulting loss of 'quality'.

Writing things in assembly is not a magic bullet, making the algorithm go faster
just as a consequence of it being hand-rolled.

The v.fast (28000 bps) modes may, or may not work at 28000 bps between any two
endpoints. (subscribers).

Jim






Thread