On Thu, Feb 16, 2012 at 9:02 PM, Tim Ingalls <t...@sharedcom.net> wrote: > Hi Everyone. I promise I am not trying to be a troll. I have some serious > questions that I hope I can ask honestly and get some honest feedback about > using the free version of sipXecs as a commercial product.
Tim, it's at the end of my day and so I'm not going to be able to give this the response it deserves but in short, I believe you raised a lot of great points. Yes, sipxecs 4.4 and the previous versions are a mixed bag of success if you happen to catch a break on the features you need working. I'll go thru this email tomorrow a point out where the new upcoming release 4.6 either addresses these points or why 4.6 will allow us address these in very short order. > > I implemented sipXecs about a year ago. My hope was to find something more > reliable than Asterisk/Trixbox/FreePBX and easier to deploy. My purpose was > to start selling phone systems and SIP trunking to businesses as a VAR. So > far, after testing the system day in and day out as my home/home-office > phone system, I haven't found it stable enough to feel comfortable selling > it to customers. > > I have had a host of issues with sipXecs, and every time I think I've got > the platform stable, something else fails and I get one of those > barely-descriptive error messages in my email inbox. I've followed the > instructions from the book, the wiki, and this forum, but still have issues > every month. Some of the issues are as follows: > > Routing inbound calls to an auto-attendant worked great for a long time and > then just stopped working one day. After connecting the call, visitors were > greeted with no sound at all. I decided after hours of trying everything to > just skip the auto-attendant and deactivate it. > With both Vitelity and Voip.ms, I have problems where periodically an > authentication request is rejected. Instead of re-trying immediately, > sipXecs waits a full 10 minutes to try to connect again. > Nuances about how certain ITSPs (e.g., Vitelity and Voip.ms) work, and how > you can and cannot connect to them without getting strange behavior like > inbound audio not working, rejected authentication requests, etc., take days > and weeks to isolate sometimes. These are not very well tested nor > documented. I think that a serious effort at interop testing and > certification should be undertaken with detailed results --warts and all-- > posted so that someone can make an educated decision when selecting an ITSP > to use with sipXecs. > Just a few days ago, calls that were transfered to voicemail resulted in the > call failing and the ITSP routing the call to my failover phone number (my > cell phone) -- this is after the call initially rang correctly. Rebooting > the system fixed it for some reason. Why? > Periodically, (perhaps due to a sipviscious attack) certain services just > stop working. Sometimes it is the proxy service. Sometimes it is the > registrar service. Sometimes it is the NAT traversal feature as a result of > temporarily not being able to reach the STUN server assigned (since there is > no back-up STUN server setting). Why should these services just fail and > require human intervention to restart them? Can't they just time out for a > certain short period and then fix themselves? > CID doesn't work reliably. I change all of the settings as I'm told in the > wiki, but it still doesn't get transmitted correctly (or at all). For some > of my users, it works flawlessly, and for others it doesn't work at all. > Doing a SIP trace to isolate an issue is a pain in the neck. In Asterisk, > all you have to do is type "asterisk -rvv" and you can see a dialog stream > which you can read quickly. With sipXecs, you have to run a series of > research tasks to find the call in question, convert the time to UTC, grep > for the time stamp in a big list of calls, then create a merged XML file, > then load it into SIPViewer, and then find what you are looking for. The > process takes at least 5 minutes if you are an expert. > > Those are just a few examples. I'm always wondering what is going to go > wrong next. It drives me (and my wife and kids) crazy. I never had this many > problems with Trixbox. I'm not saying that sipXecs doesn't have its good > points. I'm just saying that over the last year+ since I started using 4.2 > and then 4.4, it has been anything but reliable. Reliability is the number > one need for commercial clients. > > Yes, I'll admit that it could all be my fault. It probably is. But there are > so many options, so many opinions, so many sources of information, (there > are even so many places to set port numbers for various things) that it > seems you have to do only sipXecs development for a living to be able to > deploy it correctly. It is far from simple. And that complexity is part of > the problem. > > I know that some of you have deployed many of these systems in a commercial > setting, so I have to ask you, how do you do it? I'm too afraid that if I > deploy sipXecs in an actual customer's location that they'll hate me within > a few months and ask for their money back. How do you set everything up > (selection of ITSP, etc.) so that the system is rock-solid reliable? Can we > collect some rock-solid fool-proof (as much as possible) recipes that are > known to work reliably every time? This seems to be something that should be > placed on the wiki. I know that there are 100+ ways to configure the system > (SIP trunking gateway configs, various hardware, ITSP settings, dial rules, > etc.). I'm looking for just the recipes that make the system reliable. I > also know that there are various conflicting opinions on this forum about > what works and what doesn't. I'm looking for PROVEN opinions. > > This is my final shot before I give up on the platform. I'd even be willing > to partner with someone who has a near-flawless system implemented and pay > you to do the technical part if you can prove your solution is stable. Until > I find the answer to this problem, I can't use sipXecs as the cornerstone of > my business plan and will have to move on. If I can solve this issue, I'd be > willing to pay for further development out of my profits. > > I know someone will suggest that I should just sell Ezuce's commercial > products. Based on what I've experienced so far, I don't think I'd feel > confident in relying on Ezuce to be the partner in question. If the > open-source version has these problems, what's to say that the commercial > version is any better? > > Does anyone else experience the same reliability issues? > > Also, is anyone willing to have a phone conversation about this and impart > some wisdom or have a partnership conversation? > > -- > Thanks, > > Tim Ingalls > Shared Communications, Inc. > 801-618-2102 Office > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- Join me to talk about sipXecs and the upcoming version 4.6 at CoLab @ CSU March (5th & 6th). http://www.sipfoundry.org/sipx-colab Hack with me on at the CoLab Hackfest. http://wiki.sipfoundry.org/display/sipXecs/2012+sipX-CoLab+Hackfest _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
