On Wed, Oct 21, 2009 at 1:38 PM, Mark Eissler <moeli...@mixtur.com> wrote:
> I've taken a look at sipX a few times over the past couple of years to > see if it could replace an Asterisk-based system. Here are my thoughts. > > When people say "Trixbox" they really mean two things: 1) the ISO; 2) > the FreePBX GUI. The drag about Asterisk is that until GUIs came along > the thing was very time consuming to configure and debug. But the fact > of the matter is that when we did finally switch to a GUI system we > actually lost some of the functionality I had programmed into our custom > dialplan over the years. Yes, I could have "manually" added all of those > "special" features back again but then you just get back into that whole > issue of maintainability and the closer you stick to the standard > install the better off you are when it comes to upgrading. > > Personally, I can't stand Trixbox. I think it's just a huge hack. I had > originally deployed Druid Community edition but gave up when it turned > out that that system, although quite pretty, omits a bunch of > functionality that is included in FreePBX. At that point I could have > installed FreePBX without Trixbox, but I didn't have the time to make a > marathon of it and just wanted to install a quick and dirty ISO with the > idea that later, I'd switch to something else. > > SwitchVox is beautiful. Sipcat is quite nice too. The key is that they > both feature highly useable GUIs that make configuration simple for both > Admins and end users...there's zero point in offering a bunch of > functionality in your phone system if users can't easily figure out how > to use that functionality. Look, we spend hundred of dollars on our > phones that can do so many things yet they're impossible to use. Look at > the Polycom 650 for instance, with it's overly deep menu system. > > One of the primary issues with sipX is that the GUI is ugly and appears > highly stripped down compared to the competition. My understanding is > that sipXecs 4.2 hopes to solve some of these problems with a new GUI > but other than a mention in the roadmap, accompanied by a few interface > mockups, I haven't seen any talk on this list about a new GUI. > > Ugly? Ok if you say so. But there are changes to it with every version. A lot of the changes are built into the web GUI so admin's don't have to support an additional app. The big deal with all of this is that it still stays very manageable and everything is in the core so manual hacks don't get done, the system can expose the options to you and allow you to use them, so there is no manual editing. I also find that even though the interface, as it is today, is simple, a lot of users can;'t figure out how to use a lot of its functions. There's something to be said for a simple interface and usability. Adding a lot more features to an interface doesn't always translate into more usability. The DEV list has posts for some of the screenshots, all of which are in the TRACKER (track.sipfoundry.org). > Other than that, the fact that sipX now can be configured as a B2BUA is > a huge (huge!) step forward to making this more accessible to small biz > deployments. > > Yes, this is a big step. Thanks Ranga! > -mark > > > Keith Gearty wrote: > > Picher, Michael wrote: > > > >> There's no doubt that Trixbox is good for very small installations. It > >> has a lot of functionality and can be easy to setup. For those two > >> reasons alone it can make a lot of sense for home users. > >> > >> For those of us with corporate responsibilities sipXecs is a more robust > >> solution that is easier to manage and expand. There is a level of > >> knowledge required around DNS and IP that I believe is required... > >> Programming knowledge however is not required (I am not one, nor do I > >> pretend to be). > >> > >> > > > > SipXecs is well suited to enterprise environments, but I feel that more > > work could be done to make it more accessible to small business and home > > users. I run SipXecs in a small business environment, so it certainly > > is possible, but it doesn't seem to be what it was designed for. Here > > are a few suggestions I'd like to discuss. I implore people to consider > > them carefully, from a small business / home users perspective, rather > > than discarding them as heresy or blasphemy: > > > > 1. Provide proper control of the system as a whole through the web > > interface. This issue stems from the fact that most developers view > > SipXecs as one of many Linux applications, while most users view SipXecs > > as a complete stand-alone system installable from ISO. By making ISOs > > available, the developers are encouraging the latter view, and should > > therefore be prepared to support it. What this means in reality is > > providing uncomplicated control of features such as changing the NIC IP > > settings, changing the domain name settings (this must be a simplified > > and abstracted way of editing the DNS records), configuring certain key > > features of sendmail (such as Smart Host, SMTP Auth, etc). All of these > > would be "out of scope" for an individual Linux application, but if you > > view it as a stand-alone system then these features should all be > > configurable through the central management interface (SipXconfig). > > > > 2. Re-think the strict DNS requirements. The SIP protocol does not > > require a local domain name to work, it can work just as well with IP > > addresses. Using domain names should be preferred, as without them you > > can't connect to an ITSP, but they shouldn't be mandatory. Many small > > business / home users use PSTN gateways instead of ITSPs, and can't set > > up local DNS servers because of the issue mentioned here: > > http://list.sipfoundry.org/archive/sipx-users/msg17340.html . A few > > responders to that thread suggested overcoming the issue using an > > external DNS server, but why should users have to pay for DNS hosting > > just to overcome a shortcoming in SipXecs? Using IP addresses instead > > of domain names is already possible in SipXecs, by going to "System > > > Domain", changing the "Domain Name" to the correct IP address, then > > adding the original domain name as an alias. This setup works fine, but > > its an unsupported hack. I would suggest that, in both the web > > interface and the lo-res initial setup wizard, you add the option to use > > IP addresses instead of domain names. This should be changable at any > > time, and if required you can automatically use a script to change the > > setting in all the required config files. > > > > I believe that if these 2 points are addressed, it would go a long way > > to making SipXecs more accessible to the world of small business and > > home users. This is a very large market, and catering for it would > > result in increased popularity of SipXecs, and ultimately a higher > > market share. As Tony likes to say: "Adapt and survive, or become a > > dinosaur with limited lifespan." > > > > Keith. > > _______________________________________________ > > sipx-users mailing list sipx-users@list.sipfoundry.org > > List Archive: http://list.sipfoundry.org/archive/sipx-users > > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > > sipXecs IP PBX -- http://www.sipfoundry.org/ > > _______________________________________________ > sipx-users mailing list sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
