[Asterisk-Users] Re: time to build an open phone?

[Steven Critchfield]

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 <critch at basesys.com>