1993-02-12 - Re: Compressed/Encrypted Voice using Modems

Header Data

From: Phil Karn <karn@qualcomm.com> (Phil Karn)
To: thug@phantom.com (Murdering Thug)
Message Hash: 537db2c00388b07f441be313455599c641ccfbcb72ba04389c05c3ef5fa53ea4
Message ID: <9302120707.AA13840@servo>
Reply To: N/A
UTC Datetime: 1993-02-12 07:09:26 UTC
Raw Date: Thu, 11 Feb 93 23:09:26 PST

Raw message

From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Date: Thu, 11 Feb 93 23:09:26 PST
To: thug@phantom.com (Murdering Thug)
Subject: Re: Compressed/Encrypted Voice using Modems
Message-ID: <9302120707.AA13840@servo>
MIME-Version: 1.0
Content-Type: text/plain


At 11:41 2/10/93 -0500, Murdering Thug wrote:

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

But modern high speed modems already do quite a bit of FEC. I really
don't think more is really necessary. As long as the decryptor and voice
decoder automatically resynchronize after an error, there's no real
problem with letting a few through. It's certainly preferable to adding
long (or variable) delay.

The sychronization problem seems to occur in "real" (government) secure
phones too. They take a second or two to unmute following loss of clock
synchronization. But not every bit error causes loss of clock synch;
only a really bad line will do that.

Phil








Thread