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
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
