From: Lucky Green <shamrock@netcom.com>
To: Mullen Patrick <Mullen.Patrick@mail.ndhm.gtegsc.com>
Message Hash: d5610940d85c805833a189fe236c89c38ac6b9c41b32147cb7d6f3524008642b
Message ID: <Pine.3.89.9611221147.A7402-0100000@netcom6>
Reply To: <n1363459702.71040@mail.ndhm.gtegsc.com>
UTC Datetime: 1996-11-22 19:47:27 UTC
Raw Date: Fri, 22 Nov 1996 11:47:27 -0800 (PST)
From: Lucky Green <shamrock@netcom.com>
Date: Fri, 22 Nov 1996 11:47:27 -0800 (PST)
To: Mullen Patrick <Mullen.Patrick@mail.ndhm.gtegsc.com>
Subject: RE: Mass-market crypto phones
In-Reply-To: <n1363459702.71040@mail.ndhm.gtegsc.com>
Message-ID: <Pine.3.89.9611221147.A7402-0100000@netcom6>
MIME-Version: 1.0
Content-Type: text/plain
On 22 Nov 1996, Mullen Patrick wrote:
> To be honest, I thought he had a good idea. I just wouldn't want to pay
> $1000 for phone encryption. But, it's rare I have conversations where I
> need that much security. I'm sure the product is worth it; it's just out
> of my price range. And probably out of the price range of the average user.
It was a good idea. It just is facing some very hard engineering
challenges. Using software based voice encryption products
may work for you. By all means, do give them a try. PGPfone has a codec
for use with an ISDN or better. If you have such a fast line, the voice
quality is fine. Note that a fast IP connection may or may not suffice.
Here is why:
Other than bandwidth, the other essential property of the link is constant
and preferably low delay. I did not mention this in my original
tutorial, since this
1. We were assuming use over a regular POTS, which already has fairly
constant delay.
2. There is nothing any codec can do to make up for variable delays.
The reason is simple. If the delay is not constant, such as if you are
sending UDP packets over the Internet new problems arise. One packet
may take 50ms and the next packet may take 250ms, if it doesn't just get lost along the
way. Packets may also arrive out of sequence. One might think the answer
to this is simply a large buffer at the receiving end. Make the buffer
large enough, to be reasonably sure that the packets will all be there, say
500ms. Assuming no other delays, that would mean that you have a 1/2
second delay between the person saying a word and you hearing it.
Multiply this by two, since the other side would have the same buffer,
and you have 1 second delays. Too long for a conversation. And then there
is echo cancellation. But I'll spare you this. ;-)
--Lucky
Return to November 1996
Return to ““Mullen Patrick” <Mullen.Patrick@mail.ndhm.gtegsc.com>”