On Fri, 2003-12-26 at 13:26, Bill Schultz wrote: > I've never seen stats, but it's probably a safe assumption that the majority of IP > phones are > sitting next to a PC and the additional expense has been incurred because "people > want a phone that > looks and works like a phone". That's certainly been my experience far outweighing > any technical > issues with quality or reliability of a PC-softphone. In every market I can think > of with the > possible exception of hospitality I think ACES could be successfully sold a > substantial number of > times even though it does not "look like a phone" because it affords a much better > way to resolve > the conflict between ease of use and functionality. For the unconvinced, a more > elaborate version > could include the obligatory keypad and cosmetic plastic but I would submit that the > ability to > pick up a handset and place a call by saying "call Pat" alone would "sell" most > potential customers > on learning how to operate a two position switch on a device that doesn't have a > conventional > keypad. At it's simplest, to use the phone you need to know that position A is used > to hangup and > dial by saying "dial 1-800-555-1212" (or whatever number you want called) and > position b is used to > talk.
Soft phones are only as reliable as the host OS. It would be extremely hard to explain to a user that they need to upgrade their PC or close apps so their call quality can stay at the expected level. This is especially true if you are wanting to do Speech Recognition. Which by the way, you make that mistake many times in this post, you are wanting speech recognition to determine what the person on the phone says, not text to speech where the computer could read to the user. Speech recognition uses significant resources to be accurate. In the long run you only shift cost from your add on to the PC. Then you have to support whatever OS is on the desktop, not a good idea. The reason for people wanting a real hardware phone on the desk next to the PC is that they understand that computers crash, have virus problems, have upgrade incompatibilities and any number of other instabilities that can render their workstation down for a day or more. These people must still be able to use the phone no matter the condition of the machine on the desk. Many peoples jobs can still be preformed when the PC is either non functional or not functioning optimally. Take my mothers job for a option, she routes freight for her company. If her computer was to become inoperable for a period of time, she usually has a hour or more of paperwork she can complete on the phone with her customers and freight companies. She could probably use a VoIP phone, but not one tied to the stability of her computer. I'm sure this is true with many other jobs. I can also tell you that my mothers windows computer crashes several times a day, and some of the calls she makes requires her to be on hold for 10-20 minutes. If she was to experience a crash in that wait period, it would basically waste the time she had been on hold. So try to remember that we wish to bring efficiencies to the worker/person using our devices not new roadblocks. > The heart of this concept is use of text-to-speech to replace keypad functions. I > cannot emphasize > enough how acutely aware I am of the HUGE resistance users will have to buying > something without a > keypad but bear with me and I hope you'll agree that this has enough "sex appeal" to > overcome this > historically undefeated resistance. Each "phone is two complete analog/IP circuits > defined as: > Talk - a subset of what Asterisk uses now not requiring any of the control functions > TTSControl - moving control functions currently handled by DTMF over to a > text-to-speech engine > located on ACES component 3 described below. The TTS engine would be capable of > translating most > peoples voices when they speak the word "call" and the ten digits required to place > a call. The > "phones"(ACES component 2 described below) would simultaneously be user-specific so > individual > users could train their personal library to recognize them when they are "logged in" > at that phone > to place calls by saying "call Pat", etc. etc. etc. and of course to receive calls. Speech recognition would be less helpful than a computerized rollodex with click to call functionality. A home user may have a short enough list of people on speed dial to make it easy for the speech recognition. I think in the case of the example of my mother above, she would have way too many similar sounding entries to be accurate enough times. > ACES Component 1 > EM unit-Ear and Mouth piece, this is a headset or handset with a two position switch > and a 4 > conductor jack that plugs into the IP unit(ACES component 2). FOr prototyping two > typical monaural > PC headsets into a 2.5mm switchbox would do fine. Switch position one connects the > 1st mike and > earpiece to the 2 "talk" pins on the Talk/TTSControl port on the IP unit and Switch > position two > connects the 2nd mike and earpiece to the 2 "ttsControl" pins on the Talk/TTSControl > port on the IP > unit. Obviously production handsets/headsets would have only one earpiece/mike with > the switch > changing the connection from one pair of pins to the other. > > ACES Component 2 > IP unit - a black box containing 5 physical interfaces: > LCD for callerID/outbound calling number verification > Ethernet port 1 - the IP unit gets two IP addresses, one for "talk" and one for > "ttscontrol" so > appropriate hub/switch circuitry would be behind it One codec connects the first IP > address to the > 2 "talk" pins on the Talk/TTSControl port and the other IP address is connected by a > second codec > to the 2 "ttsControl" pins on the Talk/TTSControl port. If one codec can be used > for both, great > but I believe to be marketable the speed of placing or receiving a phone call has to > be equal to or > faster than the standard POTS-analog equivalent. The "talk" IP address interfaces > with Asterisk > and the "ttscontrol" IP interfaces with the Call control service described in the > next section. > Ethernet port 2 - pass-through port this one works just like existing 2 port > IPphones to connect > your PC, etc. but the physical design would permit additional modules to be snapped > on to add > functionality similar to 2,3,4 line analog phones later. > Ringer port - inbound call notification > Talk/TTSControl port - connects to EM unit above > It is significant to note that the IP unit requires no DTMF capability whatsoever. > Smarter people > than me can determine whether SIP/IAX/H323 or whatever works. Additionally I see no > reason an > 802.11x version could not be easily developed to achieve whatever mix of "corded" > and "cordless" > phones you wanted. You show your lack of IP knowledge above. You can bind many IP addresses to a single ethernet port. No need for additional annoying cables. Add to this the ability to do more than one thing on that IP address. Therefore there is no need to waste additional IP addresses. > ACES Component 3 > Call control service - obviously this could be part of asterisk but scalability > issues probably > make it better implemented as a separate service. In a SOHO environment it would > run as a service > on the same box as Asterisk. Larger environments would have a dedicated "Call > control server". > > So, in summary ACES is a system that offers enough advantages over existing IP > phones to convince > most users to try it without a keypad. Could even be just what Asterisk needs to > take it > mainstream. The only thing you'd have to "manufacture" would be the IP unit and I > would think the > elimination of earpiece, mike, DTMF and other components coupled with the fact that > one SKU could > be designed regardless of whether you wanted basic or advanced functionality make > the open-source > engineering that much more feasible. > > I'm guessing that Digium would be the logical vendor for ACES Component 2 since > unlike existing IP > phones one SKU would be as universal as the FXS cards they now sell. ACES component > 2 could easily > be homebuilt in handset or headset form from existing manufacturing and 3 would be > GPL open-source > software > > Of course, I could always be wrong :-) I think you have missed the mark by a bit. Maybe aimed in the right quadrant, but not spot on yet. Keep brainstorming. -- Steven Critchfield <[EMAIL PROTECTED]> _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users