Kyle, Thanks for the awesome info. I guess I'll just give up on the SIP trunking until I find something more stable to make sipXecs work with it. What do you use for your PRI gateways?
You're right about the local calls. If you make a lot of them, it makes sense to get unlimited local. Most cheap ITSPs charge per minute for all calls, inbound and outbound, local and LD. Thanks, Tim Ingalls Shared Communications, Inc. 801-618-2102 Office On 02/17/2012 09:25 AM, Kyle Haefner wrote: > Hi Tim, > > Sorry to hear you've had trouble...I remember when we first got > rolling feeling the same way. However, the mistakes we made early on > we've corrected and it is my completely biased opinion that we have a > pretty stable setup now between our network, gateways, servers and > phones. > > We've had no down time (calls not reaching recipients) for at least > two years. The only thing approaching down time was the reboot of > phones after the upgrades to 4.0,4.2,4.4 and one of those upgrades > was to completely new server hardware. We run a 3 node cluster with > 500 phones (doubling that this year) with an additional two separate > remote campuses each with a 2 node cluster and site-to-site calling > between all of them. We even had a lightning strike that took out one > of our T1s, it killed the connections on that T1/gateway but new > connections were fine through our backup T1/gateway. > > We use only T1-PRI connections to our voice gateways, and honestly i'm > in no hurry to move away from that, as no ITSP can match our cost for > local calls, and from what I've read in mailing lists (and your post!) > long distance savings using an ITSP are not worth the headaches > (literally if it pages me at 2AM!). > > The issues we have had are mainly inter-operabilty with MS Exchange > and various softphones (users love em' I hate em') and once or twice > the presence server died. > > Cheers, good luck, and by all means take advantage of the growing > community for help. > > Kyle > > > > > > > On Thu, Feb 16, 2012 at 7: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. >> >> 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/
