[asterisk-users] building a phone

[SIP]

Tzafrir Cohen wrote:
> Hi folks
>
> A common wisdom here is that one should use a proper hardware phone
> rather that an extra software on the user's PC. Why is that such a big
> issue?
>   

Marketability for one. People worldwide understand the telephone
paradigm. You have a handset and a box with numbers. You pick it up and
dial, talk through the handset, and listen in the other end. It's
simple. It's an elegant design. And everyone from 1 year olds to my 97
year old grandfather can use it.

Software phones? Not so much. In fact, not even close. The additional
complexity of running software on a machine ALONE would keep my
grandfather and that 1 year old from using it. Headsets? Seriously?
Since when have those been user-friendly OR comfortably.

In essence, adherence to a software phone paradigm breaks a century of
design advancement in telephone ergonomics, psychology, and reliance,
and replaces it with something that's clearly just a kludgy add-on to a
product which was never originally designed for the task.





> One thing that bothers me with the current crop of hardware SIP phones
> is that they are hopelessly properitary. 
>
> So what would it take to build a fully-adaptable phone?
>
> Here are some of my thoughts. This is not anything I plan to do soon (if
> at all), but I really find it strange that there aren't such phones
> already.
>
>
> == Small Quantities:
> When you look at such systems it becomes aparant that you can get much
> nicer prices if you buy large quanities. But this is something that will
> be a problem. Not only for prototying. The fact that you're limited to a
> strict hardware setting is very limiting. No mixing and matching like in
> a standard PC. I'm not exactly sure how to overcome that.
>   

This is one of the biggest reasons all the hardware phones are
proprietary -- they're each written for different basic hardware.


> == Platforms:
> There are many embedded platforms nowadays. I assume that the relevant
> application requires some non-trivial CPU power. I would exclude e.g. a
> 486-based systems. My target phone should be able to handle at least two
> concurrent Speex calls. Preferrebly 6 speex calls and above.
>
> OTOH, I can't afford a monster CoreDuo. I need a quiet system with no
> fan. Thus the target CPU may be higher end VIA or Atom. Not sure about
> Geode. 
>
> There are also some interesting ARM-based boards around. I'm completely
> unfamiliar with them but I suspect that they may prove to be cheaper. 
>
> == SIP Software:
> Not really sure here. There must be something close to usable already, I
> guess.
>
> == Micro Browser:
> Hell no!
>
> The device should have an LCD display, and the content of that display
> should be programmable. Programming it using a HTML renderred is a bad
> design decision.
>
> The device should be a good phone. It should not attempt to be a web
> browser, as it will be a lousy one.
>
> == Handset:
> I suppose that an obvious starting point for a handset is "skype phones"
> such as USB handsets from yealink. Far from an optimal design, but a
> driver already exists.
>
>
> == Ease of Use:
> A phone must be usable. The target device must be something my mom can
> use. However that does not mean it must be easy to program. It must be
> programmable and hackable. But I can live with a complicated user
> interface for that. If such phones become successful and useful, better
> interfaces will eventually be written.
>
>
>   


Just a note here -- a complicated user interface, though you personally
may be able to live with it, will pretty much ensure that the phones
never become successful enough for a better one to be written. UI design
is about 10% code and 90% psychology (and so FEW people who call
themselves UI 'programmers' understand that). Just having a UI that can
get you from point A to point B without typing in commands is NOT a UI
worth making, as it will never be a UI worth using.