asterisk users - Dec 2003 - Re: time to build an open phone?

ACES - Asterisk Communications Endpoint System
{the following could be used by any IP-PBX but the name pays homage to Mark
Spencer and friends who
cannot be lauded enough for their fine work}

As you read this it will be obvious I am not a professional engineer but I do
have enough knowledge
to be fairly certain what I'm proposing is feasible from not only an
engineering, but production
cost and perhaps most importantly, marketing standpoint. 

An open phone is a great idea but as soon as you "get physical" you
add a quantity issue that
doesn't exist in software.  Multiply this for keypads, handsets, bells, etc.
etc. etc. and you have
a lot of work but more importantly NO ONE has built a phone that can
simultaneously be brain-dead
simple to operate for one person yet offer the advanced user whatever 
functionality they might
want.  You will never solve that issue as long as you have a keypad of any kind.

So you end up with what started this open-phone thread in the first place...  a
plethora of IP,
analog or digital phones with a dizzying array (or lack thereof) of bells and
whistles all trying
to achieve a balance between quality, ease of use and functionality which will
sell enough units to
make their manufacturing and distribution profitable.  In this environment you
will always have at
the low end manufacturers competing on price and inevitably that results in
quality issues.  Right
now it's Grandstream but next year it'll be someone else at a $30 price
point and the same issues
will apply all over again.

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.

ACES has three components and for simplicity of description I won't go into
VERY cool extensions to
these components for conferencing and/or duplication of the typical 2,3 or 4
line analog phone
features.  It also assumes a LAN environment again only for simplicity of
initial description.
There's no reason that an ACES Call control server couldn't support 
multiple, geographically
dispersed Asterisk servers.

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.

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.

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 :-)

Cheers

Bill Schultz wrote:
>	ACES - Asterisk Communications Endpoint System
>{the following could be used by any IP-PBX but the name pays homage to Mark
Spencer and friends who
>cannot be lauded enough for their fine work}
>
>As you read this it will be obvious I am not a professional engineer but I
do have enough knowledge
>to be fairly certain what I'm proposing is feasible from not only an
engineering, but production
>cost and perhaps most importantly, marketing standpoint. 
>
>An open phone is a great idea but as soon as you "get physical"
you add a quantity issue that
>doesn't exist in software.  Multiply this for keypads, handsets, bells,
etc. etc. etc. and you have
>a lot of work but more importantly NO ONE has built a phone that can
simultaneously be brain-dead
>simple to operate for one person yet offer the advanced user whatever 
functionality they might
>want.  You will never solve that issue as long as you have a keypad of any
kind.
>
An open phone is open.  It does specify any type of I/O device, only how 
to interface to them.
We just start with something like a light weight netbsd/* code base.
Folks can add whatever from there.
>
>So you end up with what started this open-phone thread in the first place...
a plethora of IP,
>analog or digital phones with a dizzying array (or lack thereof) of bells
and whistles all trying
>to achieve a balance between quality, ease of use and functionality which
will sell enough units to
>make their manufacturing and distribution profitable.  In this environment
you will always have at
>the low end manufacturers competing on price and inevitably that results in
quality issues.  Right
>now it's Grandstream but next year it'll be someone else at a $30
price point and the same issues
>will apply all over again.
>
I have no interest in trying to make money by manufacturing widgets.
I only want control of my own destiny.
I don't care what the phones cost.  I just want control of the code.
>
>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.
>
The markets I work in not only do not want to use pc's as phones.
They do not want voice on their data networks.
Some of my customers, including my office have no pc's at all.
Just unix work stations.
>Of course, I could always be wrong :-)
>
I would not say you are wrong.
You are just looking for something different than I am.

-- 
Bob Knight
[-w] the work option
bk@minusw.com
925-449-9163

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@basesys.com>

While looking for some cell phone goodies to go with my ngage, I noticed
a bluetooth earpiece that happened to come with a usb adapter. It made
me think of this project. Many of the bluetooth adapters have a single
button used on cell phones for voice dialing and answer/hangup
functions. Doesn't this sound a lot like a good tie in with a gnophone
or other iax client. It also sounds like a good idea as the hardware is
already around and functional. 

While bluetooth is already being supported in linux, I'm not impressed
yet with the glue software. I bought a bluetooth adapter so I could try
and sync wirelessly the contacts on my phone. Also even with the crap
you have to go through it is the best way to transfer apps to my phone.

Well that should plug the hardware hole for temporary, go dig into the
software. 
-- 
Steven Critchfield <critch@basesys.com>