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
participants (4)
-
jim＠tadpole.com -
miron＠extropia.wimsey.com -
sdw＠sdwsys.lig.net -
thug＠phantom.com