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

[Bill Schultz]

> > 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. 
> 
Sounds like we're arguing the same thing for different reasons.  For 
whatever reason PC-softphones are not a viable option.  I totally 
agree with that statement.

> So try to remember that we wish to bring efficiencies to the
> worker/person using our devices not new roadblocks. 
It probably doesn't look like it, but I tried to keep the initial 
comments low so I didn't go into detail on exactly how it would work 
but I am certain that the standard phone functions will all be at 
least as easy and as fast as any analog, digital or IP system I've 
seen so far and a dramatic improvement over most.

> 
> > 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. 
I meant Speech to Text, I can only apologize and claim brain-lock as 
to why I kept typing Text to speech.  Sorry, sorry sorry....

As far as phonetic dialling paretos law applies in all cases.  If the 
quantities of entries in your rolodex are so high that phonetic 
overlap becomes a problem you're not using your existing phone system 
to dial anyway.   Finally nothing precludes this limited set of users 
from adding the keypad option or using a conventional VOIP phone or 
using a PC based dialer but most will discover that if the system 
phonetically dials for them 80% or more of the time dialling the 
digits phonetically the other 20% is quite an acceptable trade-off.

> 
> > 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. 
Like I said , I'm not claiming to be an expert, just knowledgeable 
enough to know what I propose is feasible.  Your enlightening 
information just means throw out my reference to the hub and the guts 
of the IP unit just got simpler.  Perhaps I wasn't clear enough, the 
only reason fo the second port is if you need to cable to a PC and 
don't want to have to make two cat5 runs or if you want to expand to 
a 2,3 or more line phone.  I purposely made the snap-on option for a 
2,3,4 line separate to keep the cost of a basic single line phone as 
low as possible.  In any event there was and is only one cable to 
each phone not counting a patch cable if you need to hook up a PC 
also.

> 
> > 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.
The main point I'm trying to make here is to design a system that 
allows for one phone SKU to offer all the features for an advanced 
user yet keep the cost per desk at an entry level and allowing the 
simplest warehouse worker to use the same phone to perform the most 
rudimentary place and receive calls without being presented a device 
with lots of  confusing buttons.
Again, the MAIN point here is one-SKU, one-SKU, one-SKU.

> 
> Keep brainstorming.
> -- 
> Steven Critchfield <critch at basesys.com>
>