Quoting Bill Stewart <bill.stewart@pobox.com>:
First of all, the sound system on a Palm Pilot can't handle the job - there's no microphone, and the speaker system mainly knows how to beep (you can play different tones, but it's not made for voice.) Somebody said here that the iPaQ audio is half-duplex - too bad, because push-to-talk is annoying.
I wasn't proposing the palm's audio subsystem; direct access to the audio feed in/out of a bluetooth wireless headset, instead. I would probably do the same thing with an Ipaq, even though the ipaq 3600 hardware, linux, and wince-with-compaq-drivers support full duplex. I think the ipaq is probably a better target platform, if it can be done as a WinCE app, and not require putting linux on the device, or if the device is sold pre-configured with linux and the secure voice software. Ipaq also has the benefit of supporting 802.11, etc., so you could do an "encrypted cordless phone" when around the office, with cell as a way to roam.
Second, crypto is hardly ever the CPU bottleneck - voice compression is.
Right -- 70MHz ARM7 is enough for ogg vorbis at nearly the bitrate required, so I'm pretty confident this is possible on an ARM platform. Key management would tax a palm a bit, depending on how you handle public key crypto, primarily on the battery side. I suppose if you do key generation on the palm when docked, it's not as much of a concern.
In the current cell-phone world, you typically need 9600 or below, and 4800 would be better. Cell phones do have voice compression built in; unfortunately, the software isn't designed to let you get at the compressed data stream and do other things with it, and if you're using modems, you need one or two more sets of similar hardware to transmit it after that. (The easy data channel in the US, CDPD, doesn't work for voice - it fits the data into gaps between voice packets, so the latency is generally way too long and way too variable to handle voice.)
People have done CDPD voice before, but yes, the latency is a problem. Most of the ultra-low bitrate encoding algorithms seem designed for 2.4Kbps...GSM is...13Kbps? And so do do full-duplex gsm-quality you'd probably need 4-channel HSCSD. I assume cellphones are either simplex or effectively so.
Does GSM support handset-to-handset data connections? Or does you have to use modems? How fast are they?
GSM does 9.6kbps modem/data connections (PPP). In the civilized parts of Europe, you can get High Speed Circuit Switched Data; basically, channel bonding for GSM. In the UK, 14.4Kbps HSCSD is free; 28.8kbps is surcharged. Since in the EU it is "caller pays", you could easily run an on-network GSM gateway, with both sides supporting HSCSD, at 14.4kbps, ~150ms latency, operating 24x7, for about USD 110/month flatrate to the calling side. Nokia cardphones, Ericsson T39m and T68 all support HSCSD.
Almost all of the newer cellphone data formats are fast enough, usually 64kbps or more, if anybody bothers deploying them. (I'm not counting the Japanese i-mode stuff.) 32kbps (plus async overhead, if any), lets you use dirt-simple compression algorithms,
So palm would then be sort of feasible on a bluetooth-headset, bluetooth-cellphone, with 28.8kbps HSCSD, at about USD 0.15/minute cell to cell in the UK.
or you could burn some of your 206MHz horsepower on better compression.
I suppose battery life is the concern; the ipaq can throttle back quite a bit, so you could have a "call cost/audio quality/battery life" multi-axis control. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan@havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F