You should read the book. On Feb 16, 2012 9:03 PM, "Tim Ingalls" <[email protected]> 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. > > 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 > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
