From: Ray Cromwell <rjc@clark.net>
Date: Sun, 13 Aug 95 01:13:26 PDT
To: shamrock@netcom.com (Lucky Green)
Subject: Re: PRZ encrypted voice software release imminent
In-Reply-To: <v02120d01ac51ef81b1df@[192.0.2.1]>
Message-ID: <199508130813.EAA02621@clark.net>
MIME-Version: 1.0
Content-Type: text/plain


> 
> At 14:42 8/11/95, Ray Cromwell wrote:
> 
> >I would like to see a secure voice communication protocol that is divorced
> >from the particular details of the algorithms used (although a
> >base level of some voice compression technique + DES + RSA will have to
> >be used) That way, new and better algorithms can be dropped in depending
> >on the network used (modem, ipx, tcp/udp, etc) and the bandwidth required
> >(CELP vocoder, MPEG-audio, lossless encoding, progressive PCM, etc)
> 
> The codec used is at the very core of any computer telephony system. A
> standard that doesn't specify the codec(s) can be little more than a
> standard on message formats, which will be of little value if the other
> side doesn't implement the same codec.

  Uh, that's why you define a base level of support like I said. This
same arguments applies to all communications technology, such as 
secure ip, e-mail standards, etc. You always have a base defined to
insure something to fall back on. that has absolutely nothing to do
with my comments which are directed at developing an open standard
for inteoperability that allows other algorithms to be sused rather
than locking everyone into a particular codec. The codec is irrevelent,
it's cement in the foundation, but the design of the house is more
important to the end user. The message protocol and application
level is much more important because it controls 1) how easy
it is to create applications, and 2) how those competing
applications can interoperate with each other. These supports
a rich market with lots of interoperating "phones". on the other
hand, a poorly designed protocol will lead to a market dominated
by one or two proprietary players that is hard to upgrade
when better capabilities come out later, or new demands are made. 

  There are other reasons to abstract above codecs, for instance, a
lot of codec algorithms are patented or trademarked, so that
if a program is "welded" to any particular codec, you create hassles
for application developers who can't use non-open algorithms.

  Finally, abstracting above the codecs allows competition between
codec developers ( a sub market) whereas a design that locks in
one particular codec pretty much forces price competition
only.

-Ray