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? 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. == 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. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
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? > > One thing that bothers me with the current crop of hardware SIP phones > is that they are hopelessly properitary. >no more so than a vcr or other consumer device.> So what would it take to build a fully-adaptable phone? >why bother when there are lots of < $100 perfectly fine phones already ?> 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. > >why not just take an existing device such as the n770 or nintendo ds. load a sip client of your choice on, and you are done - wireless phone, touchscreen, runs any other software you want, already low cost, no manufacturing. (both devices already have wifi, speaker and microphone as well as a colour touchscreen, so what else is missing ?) there are also iphone clones coming down into the same price range that are fully programmable.> == 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. > > == 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. > > >
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.
It's a dream! It's since years that I'm thinking to have an open hardware project targeted to a SIP application. I'm thinking, for example, to have a modular system that can be targeted to different custom appliances like, for example, (video) door bell opener/intercom, or building/desktop music streamer, or SIP compliant actuators. I have a (very) little experience on electronic projects. Is there something I can do to help starting a similar project? Thank you and best regards. Marco Signorini 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? > > 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. > > == 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. > > >
> I assume that the relevant application requires some non-trivial CPU power. I would > exclude e.g. a 486-based systems.I'm not sure that's the case. The industry has gone in the direction of throwing lots of silicon at a problem, often as an excuse for poorly written code, sometimes in an interpreted language. There are a number of high integration CPUs out there that I suspect could do this sort of thing. I develop device controllers for a variety of industry needs. They tend to have Ethernet, RS-232, sometimes 1 Mb/s synchronous communication. G711, quarter VGA color LCD with touchscreen and control loops running at about a 1 ms rate. The entire code takes less than 256K in C. My choice of processor is the DStni Ex (made by Lantronix and sold by Grid Connect) which is a high integration, high speed 186 core with two 10/100 Ethernet Ports and 256K of RAM on it in addition to the usual assortment of other stuff. The above required platform adds three support chips (one being the LCD controller). The CPU can run over 100 MHz. Memory accesses take one clock and typical instructions take two or three. Cost is in the $10 to $20 range for the chip and power consumption is around 1 W (the LCD backlight takes more than that!) I'm sure there are several other comparable platforms out there, such as by Digi International. The Geode is a good candidate as are some VIA chips, if one wants to use protected mode x86. The biggest thing for this is don't even consider Intel. For most of their life they have not provided cutting edge solutions for embedded use. Most of their stuff consumes too much power. And most importantly, they are targeting the very volatile, short lived PC market. By the time you get an embedded design up and running and reach market penetration, you won't be able to buy the chip any more. Wilton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090227/cb50781f/attachment.htm
On Fri, 27 Feb 2009, 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?Both my laptop and desktop PC have poor quality microphone inputs. I use a USB "phone" on my laptop when out and about.> One thing that bothers me with the current crop of hardware SIP phones > is that they are hopelessly properitary.SIP is an open standard...> So what would it take to build a fully-adaptable phone?Persuade an existing manufacturer to provide an SDK for their phone... And thinking about it, don't Snoms run Linux? anyone asked if an SDK is avalable?> 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. > > == 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.Custom DSP or ARM. Don't forget power requirements too. PoE may well be able to supply 15W, but imagine a building with 100 x 15W phones... Everything I've plugged into my meter idles at about 2W (Grandstream, Snom, Siemens, ATL)> == SIP Software: > Not really sure here. There must be something close to usable already, I > guess. > > == Micro Browser: > Hell no!"Executives" want it...> 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.I've actually used the RSS reader in my Grandstream Video phones.. It's usable, but I take your point about the full web thing!> == 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.Seen these: http://www.fit-pc.co.uk/meet-fit-pc.html#tiny And of-course the power line thing mentioned here a few days earlier - eg. http://www.theinquirer.net/inquirer/news/143/1051143/pc-plug-coming-soon-wall-near if you're going to use a USB phone, these platforms are ideal, if a little pricey.. I did play with a yealink phone and Linux some time back - get the display and keyboard working and it'll be very functional... (I got it to almost work with Zoiper, so a custom app. would be easy) Alas, I gave it to a friend, then go anothe from the same source (tesco), thinking it would be identical - and it was - in packaging, but was a totally different phone )-:> == 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.Dial the number, push the green button, off you go... Gordon
Witness the fact that the old Pingtel phones ran Java, and they were incredibly lame. I think part of what this thread misses is that DSP is a god chunk of what SIP phones need. A general purpose CPU is not the right tool for the task. A cheap DSP is better suited to compression, transcoding, etc. OTOH, presuming that the snom phones are Linux on a suitable platform soomeone could develop a custom software load for them and OEM the hardware. Michael --Original Message Text--- From: Wilton Helm Date: Fri, 27 Feb 2009 12:28:40 -0700>This is not entirely true - many of the nokia phones use a java OS as a >core, and you can load pretty much any java software you want on them, >but all the points about power and battery use are still valid. (and >whether you really consider that truly an OS is questionable, but its >out there)Java is the worst offender. Its resource requirements often exceed those of the application it is running. Java is useful for things like displaying web pages that are not time critical and where its write once, run everywhere philosophy is valuable. But anyone trying to actually do things like I/O control, call setup, transcoding, etc. in Java are asking for every issue I raised. If WCE can get 8 hours of battery life, Java would be about 3. Wilton -- Michael Graves mgraves<at>mstvp.com http://blog.mgraves.org o713-861-4005 c713-201-1262 sip:mgraves at mstvp.onsip.com skype mjgraves fwd 54245 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090227/db0a4bf9/attachment.htm
On Fri, Feb 27, 2009 at 09:39:59PM -0600, Michael Graves wrote:> Witness the fact that the old Pingtel phones ran Java, and they were > incredibly lame. > > I think part of what this thread misses is that DSP is a god chunk of > what SIP phones need. A general purpose CPU is not the right tool for > the task. A cheap DSP is better suited to compression, transcoding, > etc.Maybe. But it is also a great limitation on the hackability and thus on the speed of development. I think that general-purpose processors are strong enough for that. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
I have influential contacts inside snom... CS -----Urspr?ngliche Nachricht----- Von: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] Im Auftrag von Paul Chambers Gesendet: Sonntag, 1. M?rz 2009 01:30 An: Asterisk Users Mailing List - Non-Commercial Discussion Betreff: Re: [asterisk-users] building a phone Michael Graves wrote:> On Sat, 28 Feb 2009 14:59:23 -0800, Paul Chambers wrote: > >> Michael Graves wrote: >> >>> Witness the fact that the old Pingtel phones ran Java, and they were >>> incredibly lame. >>> >>> I think part of what this thread misses is that DSP is a god chunk of >>> what SIP phones need. A general purpose CPU is not the right tool for >>> the task. A cheap DSP is better suited to compression, transcoding, etc. >>> >>> OTOH, presuming that the snom phones are Linux on a suitable platform >>> soomeone could develop a custom software load for them and OEM the >>> hardware. >>> >> I'm surprised that no-one has mentioned Astfin. Basically uClinux and >> asterisk running on an Analog Devices Blackfin DSP. There's also some >> 'open source' hardware that's available - the IP04 and friends. I'm >> using an Edgepbx FX08, and they also have a two-port version (FX02). >> Atcom has a single-port one, the IP01. >> >> Though if I were going to prototype an 'open' SIP phone, I'd probably >> start with a beagle board (TI OMAP3530 - dual-core ARM+DSP). It's a >> pretty powerful SOC - its brother (3430) powers the Palm Pre. >> >> Just another datapoint :) >> > > Yeah, that'd be great hardware to select. > > What I was thinking is that this thread seems to be driven by those of > a software bent. For that group perhaps there's an opportunity to write > code for something like a snom 820. It's a solid solid hardware basis > for the project. Snom would be foolish not to sell it for such use, > even price it attractively. That way the hardware work would be done, > and the software geeks could work their magic. >I'm a card-carrying (embedded linux) software geek, and I know I'd be interested :) Anyone got some influencial contacts inside Snom? or Aastra, for that matter, their hardware also seems good quality from what people have said. Another possibility is talking to Atcom (or other VoIP ODMs), they seem to have done pretty well from the IP04 and derivatives. They've experienced the benefits of an open development model, perhaps they'd be interested. Not sure what the quality of their existing handset hardware is like. Anyone on the list have the contacts to get the ball rolling? Paul _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
To be honest: I am not very optimistic regarding this project. The WRT is really a case where you essentially use stuff that is already available and which is very very stable (e.g. Linux). There is nothing really special for the WRT. For a phone, the picture looks different. There are so many components necessary that are either not available or not very stable. There is a tremendous risk of ending up with a project that has a lot of loose ends. But if someone wants to give it a try, sure. We have nothing to lose! Those who know embedded Linux will easily feel like home on the phone once they are logged in. Definitively an interesting topic for our Asterisk developer meeting that we want to run this month in Berlin. Maybe for starters we just compile an Asterisk and run it on the phone. That will be fun! CS -----Urspr?ngliche Nachricht----- Von: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] Im Auftrag von Michael Graves Gesendet: Sonntag, 1. M?rz 2009 18:30 An: Asterisk Users Mailing List - Non-Commercial Discussion Betreff: Re: [asterisk-users] building a phone On Sun, 1 Mar 2009 18:14:18 +0100, Christian Stredicke wrote:>I have influential contacts inside snom... > >CSSo you do! What do you think? Would snom be interested in selling hardware into a group of users who would be loading community developed application firmware? It makes me wonder how many little routers Cisco sells that actually get loaded with WRT-DD and the like? Michael>-----Urspr?ngliche Nachricht----- >Von: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] Im Auftrag von Paul Chambers >Gesendet: Sonntag, 1. M?rz 2009 01:30 >An: Asterisk Users Mailing List - Non-Commercial Discussion >Betreff: Re: [asterisk-users] building a phone > >Michael Graves wrote: >> On Sat, 28 Feb 2009 14:59:23 -0800, Paul Chambers wrote: >> >>> Michael Graves wrote: >>> >>>> Witness the fact that the old Pingtel phones ran Java, and they were >>>> incredibly lame. >>>> >>>> I think part of what this thread misses is that DSP is a god chunk of >>>> what SIP phones need. A general purpose CPU is not the right tool for >>>> the task. A cheap DSP is better suited to compression, transcoding, etc. >>>> >>>> OTOH, presuming that the snom phones are Linux on a suitable platform >>>> soomeone could develop a custom software load for them and OEM the >>>> hardware. >>>> >>> I'm surprised that no-one has mentioned Astfin. Basically uClinux and >>> asterisk running on an Analog Devices Blackfin DSP. There's also some >>> 'open source' hardware that's available - the IP04 and friends. I'm >>> using an Edgepbx FX08, and they also have a two-port version (FX02). >>> Atcom has a single-port one, the IP01. >>> >>> Though if I were going to prototype an 'open' SIP phone, I'd probably >>> start with a beagle board (TI OMAP3530 - dual-core ARM+DSP). It's a >>> pretty powerful SOC - its brother (3430) powers the Palm Pre. >>> >>> Just another datapoint :) >>> >> >> Yeah, that'd be great hardware to select. >> >> What I was thinking is that this thread seems to be driven by those of >> a software bent. For that group perhaps there's an opportunity to write >> code for something like a snom 820. It's a solid solid hardware basis >> for the project. Snom would be foolish not to sell it for such use, >> even price it attractively. That way the hardware work would be done, >> and the software geeks could work their magic. >> >I'm a card-carrying (embedded linux) software geek, and I know I'd be >interested :) > >Anyone got some influencial contacts inside Snom? or Aastra, for that >matter, their hardware also seems good quality from what people have said. > >Another possibility is talking to Atcom (or other VoIP ODMs), they seem >to have done pretty well from the IP04 and derivatives. They've >experienced the benefits of an open development model, perhaps they'd be >interested. Not sure what the quality of their existing handset hardware >is like. > >Anyone on the list have the contacts to get the ball rolling? > >Paul > >_______________________________________________ >-- Bandwidth and Colocation Provided by http://www.api-digital.com -- > >asterisk-users mailing list >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > >_______________________________________________ >-- Bandwidth and Colocation Provided by http://www.api-digital.com -- > >asterisk-users mailing list >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-- Michael Graves mgraves<at>mstvp.com http://blog.mgraves.org o713-861-4005 c713-201-1262 sip:mgraves at mstvp.onsip.com skype mjgraves fwd 54245 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
On Sun, Mar 01, 2009 at 07:04:42PM +0100, Christian Stredicke wrote:> To be honest: I am not very optimistic regarding this project. > > The WRT is really a case where you essentially use stuff that is > already available and which is very very stable (e.g. Linux). There is > nothing really special for the WRT. > > For a phone, the picture looks different. There are so many components > necessary that are either not available or not very stable.Hence my focus on small quantities and hackability. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
I agree, the intersting part is adding what is not included in the standard firmware. Regarding documentation... On the one hand the phone is running a "regular" embedded Linux, I think that does not require additional documentation. The API to the phone is a different topic. It will really depend what content we are talking about. Many applications can be done using the mini-browser. The software does not even have to run on the phone for that. Maybe a concrete example of an application that has to run locally on the phone would be useful. CS -----Urspr?ngliche Nachricht----- Von: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] Im Auftrag von Paul Chambers Gesendet: Mittwoch, 4. M?rz 2009 05:15 An: Asterisk Users Mailing List - Non-Commercial Discussion Betreff: Re: [asterisk-users] building a phone It may not be necessary to replace Snom's firmware to add interesting functionality to the product. Though that was not the original poster's premise, admittedly. As to the 'loose ends', they usually remain so until someone is motivated to drive them to closure. Absence of a suitable hardware platform is guaranteed to perpetuate that situation :) The big question for me is whether Snom would provide some documentation to those prepared to invest their time. With GPL'd software likely to be part of the mix, such information couldn't be covered by a non-disclosure or some restrictive developer agreement. One of the things that helps to kick-start a developer community is to sell 'developer kits' (like Digium did). Single-unit quantities with a 'not-for-resale' provision, perhaps with membership of some developer program. Paul Christian Stredicke wrote:> To be honest: I am not very optimistic regarding this project. > > The WRT is really a case where you essentially use stuff that is already available and which is very very stable (e.g. Linux). There is nothing really special for the WRT. > > For a phone, the picture looks different. There are so many components necessary that are either not available or not very stable. There is a tremendous risk of ending up with a project that has a lot of loose ends. > > But if someone wants to give it a try, sure. We have nothing to lose! Those who know embedded Linux will easily feel like home on the phone once they are logged in. > > Definitively an interesting topic for our Asterisk developer meeting that we want to run this month in Berlin. > > Maybe for starters we just compile an Asterisk and run it on the phone. That will be fun! > > CS > > -----Urspr?ngliche Nachricht----- > Von: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] Im Auftrag von Michael Graves > Gesendet: Sonntag, 1. M?rz 2009 18:30 > An: Asterisk Users Mailing List - Non-Commercial Discussion > Betreff: Re: [asterisk-users] building a phone > > On Sun, 1 Mar 2009 18:14:18 +0100, Christian Stredicke wrote: > > >> I have influential contacts inside snom... >> >> CS >> > > So you do! What do you think? Would snom be interested in selling > hardware into a group of users who would be loading community developed > application firmware? > > It makes me wonder how many little routers Cisco sells that actually > get loaded with WRT-DD and the like? > > Michael > > >> -----Urspr?ngliche Nachricht----- >> Von: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] Im Auftrag von Paul Chambers >> Gesendet: Sonntag, 1. M?rz 2009 01:30 >> An: Asterisk Users Mailing List - Non-Commercial Discussion >> Betreff: Re: [asterisk-users] building a phone >> >> Michael Graves wrote: >> >>> On Sat, 28 Feb 2009 14:59:23 -0800, Paul Chambers wrote: >>> >>>> Michael Graves wrote: >>>> >>>>> Witness the fact that the old Pingtel phones ran Java, and they were >>>>> incredibly lame. >>>>> >>>>> I think part of what this thread misses is that DSP is a god chunk of >>>>> what SIP phones need. A general purpose CPU is not the right tool for >>>>> the task. A cheap DSP is better suited to compression, transcoding, etc. >>>>> >>>>> OTOH, presuming that the snom phones are Linux on a suitable platform >>>>> soomeone could develop a custom software load for them and OEM the >>>>> hardware. >>>>> >>>> I'm surprised that no-one has mentioned Astfin. Basically uClinux and >>>> asterisk running on an Analog Devices Blackfin DSP. There's also some >>>> 'open source' hardware that's available - the IP04 and friends. I'm >>>> using an Edgepbx FX08, and they also have a two-port version (FX02). >>>> Atcom has a single-port one, the IP01. >>>> >>>> Though if I were going to prototype an 'open' SIP phone, I'd probably >>>> start with a beagle board (TI OMAP3530 - dual-core ARM+DSP). It's a >>>> pretty powerful SOC - its brother (3430) powers the Palm Pre. >>>> >>>> Just another datapoint :) >>>> >>> Yeah, that'd be great hardware to select. >>> >>> What I was thinking is that this thread seems to be driven by those of >>> a software bent. For that group perhaps there's an opportunity to write >>> code for something like a snom 820. It's a solid solid hardware basis >>> for the project. Snom would be foolish not to sell it for such use, >>> even price it attractively. That way the hardware work would be done, >>> and the software geeks could work their magic. >>> >> I'm a card-carrying (embedded linux) software geek, and I know I'd be >> interested :) >> >> Anyone got some influencial contacts inside Snom? or Aastra, for that >> matter, their hardware also seems good quality from what people have said. >> >> Another possibility is talking to Atcom (or other VoIP ODMs), they seem >> to have done pretty well from the IP04 and derivatives. They've >> experienced the benefits of an open development model, perhaps they'd be >> interested. Not sure what the quality of their existing handset hardware >> is like. >> >> Anyone on the list have the contacts to get the ball rolling? >> >> Paul >>_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users