Tim - we really appreciate the feedback. The following might help add some additional perspective:
- We need the community's help to keep improving the open source edition, especially as it relates to documentation on our Wiki and elsewhere, but also for specific features important to the community. We will make every effort to incorporate contributions timely and properly - The UI can and should be improved - Our commercial edition, openUC, is positioned for larger enterprise and not SMB. This is the reason why certain features and design considerations are not optimized for the SMB market - SIP trunking is one of these features. Large enterprise will always use a commercial SBC and not sipXbridge. They also do not use voip.ms - We think the SMB market moves into the cloud and away from on-premises installations. The requirements for technology needed to build large scale cloud based systems is very different from on-premises installed SMB systems. Our engineering effort is focused on where the market is headed - We think that this industry transitions to IT and away from legacy systems and also away from the traditional VAR model. Most VARs, especially the many small ones, are in trouble already. We can help VARs transition and we work with partners to develop managed services offerings - We think that clients move into the Web with html5 and browsers / mobile apps capable to do real-time comms - Training and docs as well as support are available very similar to e.g. Cisco as mentioned below, but as part of the commercial edition Open source and commercial editions go hand in hand; they both need each other to exist. Every customer or reseller has a choice to work with either edition and there are benefits to both, but it often helps to clearly understand the two models. Our goal is to establish the undisputed leading and open UC solution in this new market that unfolds on the IT side. We have proven our viability even in very large deployments, our customers have saved substantial amounts, our users are happy, our support is highly regarded, and our partners (VARs and resellers) have built a business. --martin From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tim Ingalls Sent: Friday, February 17, 2012 9:53 PM To: Sipx-users list Subject: Re: [sipx-users] sipXecs Commercial Feasibility I appreciate your feedback. You're right. Being specific is helpful. However, I was trying to not be totally specific, because I'm bringing up a few main general points: 1. Learning and deploying sipXecs correctly is very complex. The learning curve is very steep compared to some other open-source projects, including Trixbox. Part of the complexity is the way the user interface is laid out (multiple places to configure similar things, etc.), part of it is due to bugs and incompatibility w/ specific ITSPs, and part of it is due to the technology itself. What I liked about Trixbox is that it pretty much just worked w/ most of the ITSPs without a bunch of headaches. So although the user interface (FreePBX) isn't as nice as sipXecs, you don't have to worry about tweaking the internals as much since it usually just works. I am trying to sell SIP trunking to small businesses who want to save money on their monthly bills. I'm not necessarily planning to resell SIP trunking at the beginning. I'm more the marketing type and am looking for someone who is great with the technical stuff, but I'm starting off by myself, so I'm looking for a system that can be deployed with only a medium amount of experience with interop w/ ITSPs. 2. The book is great, but it doesn't cover everything. For example, it doesn't tell you that if you are connecting to Voip.ms that you have to choose the same server to register to as you have set in the DID's POP setting in the Voip.ms portal. You can't register using the same DID to one sub-account at one server and another sub-account at another server so that you have server redundancy. You also cannot register two sub-accounts to the same server or you start seeing registration rejections and one-way audio on outbound calls. It also doesn't tell you that Voip.ms has a secret NAT keepalive setting they can set both on your main account AND on the sub-accounts, and that it can stop the problem of getting registration and call rejections for outbound calls. The book goes over the basics. Not the technical details. For the technical details, you have to read every post in this mailing list every day. You also have to read every page of the wiki. You also have to ask questions on this list. Some of us have too much going on to be able to do that. But the same questions pop up here over and over. Why? Because they aren't documented in an excellent way. I think that maybe we are subconsciously using "Read the book" as a crutch to not have to document things properly. The fact is, the lack of documentation for both how to configure sipXecs, and how NOT to configure it, even though it is possible to do so (because that feature isn't available or there is a bug, etc.) is a big problem with getting more people, including technical people, to adopt this as a platform. If you want to learn to deploy Cisco gear, there are classes you can take, books you can read, and certifications you can take. If you want to learn to deploy Avaya, Nortel, Alcatel, etc., there are similar programs. You learn the stuff, and then you know what to do. With sipXecs, the knowledge about how everything works is very diffuse. Even if I hire techs to do my installs, I imagine they would be struggling to learn how to deploy the system. The lack of documentation prevents a wide reach for the project. 3. I'm suggesting that we need some simplified recipes for deploying a fool-proof system. I'd like to cite the Drupal installation profiles as an example. Drupal is complicated. It has lots of documentation spread across several books, tons of articles on the Drupal site, and lots of third-party Web sites with info on it. But they also have installation profiles you can just install and everything works. Want an e-commerce site with PayPal as the back-end? There's an installation profile for it. An installation profile contains all of the optional modules you'll need without having to download and configure each one. We could do that for sipXecs. It would make it more accessible. I think if you study the rise of Asterisk and Trixbox, one of the keys for spreading their popularity was that they are accessible to moderately technical do-it-yourself types like myself. If the sipXecs project wants to get more traction, its proponents should pay more attention to making it easier to adopt. 4. You and others have suggested adding knowledge to the wiki. The problem I face in doing that is that I don't feel like I am an expert enough to definitively state how to do very many things that aren't already on the wiki. I don't want to give out bad information, especially since it seems that just when I think I have figured out sipXecs, something else breaks. I don't feel qualified to put much into the wiki. I've seen you give out some great information. But it gets buried under a pile of other posts in this mailing list. =========================== By the way, here is my setup: 1 Polycom IP 670 1 Polycom IP 450 1 Grandstream HT386 ATA 1 Sipura SPA-2002 ISP was Qwest for DSL and Xmission for the ISP service. I used to have 5 static IPs. My ISP is now Comcast 20Mbps residential service. Comcast doesn't sell static IPs for residential customers. 1 Linksys WRT54GL running Tomato Firmware. I used to use the QOS prioritization feature w/ Qwest, but don't use it any more since I have way more bandwidth than I can use and I don't have any troubles with QOS issues. The firewall currently has TCP/UDP ports 5060 and 5080 forwarded to symmetrical ports on my sipXecs server. No ports are forwarded for the RTP stream. When I connect to both Vitelity and Voip.ms, the SIP port is verified as registered to 5080. I also temporarily deployed pfSense on a mini computer (AMD PIC) to see if some of my issues were from my firewall setup, but there was no change, so I switched back to the Linksys router. My sipXecs server is running on a Pentium 4 3.2 GHz w/ 2GB RAM and 250GB SATA hard drive and 1Gbps Ethernet. Although it is a bit under-powered for a large company, for my home office it works fine. I am using a Cisco Catalyst 2924 10/100Mbps switch without implementing VLANs. There is no LAN QOS. But I don't think I need it. My problem is not call quality. It is flaky connections w/ ITSPs and other problems w/ CID, internal sipXecs services, etc. I use zoneedit.com as my DNS host. I also have port 53 forwarded at my firewall to the sipXecs machine, and I have all of my local machines listed at the end of the zone file so I can use sipXecs as my local DNS server. I don't know if my DNS setup is actually working well for requests from the outside world into specific machines on my network, but that's OK. I don't really want that to happen. I just port forward to my Web server, etc. The only mildly annoying thing related to latency is that the first micro-second of phrases I hear from the voicemail system get cut off or slurred when listened to on a Polycom phone, but I chalk that up to the slow CPU on my server. I've experimented with various firmware versions on my Polycom phones, but to no avail. I'm hopeful that a real server wouldn't have that issue. ================= But again, I think what I'm trying to accomplish here is to find out what specific configurations people are using that actually work. What ITSPs do you use? What configs work with them and which ones don't? I'm not looking to just dump on sipXecs. I really like the platform. I really really want it to work out. My only issue is that it keeps me up at night worrying that if I deploy it to any customers I'll be in deep doo-doo. Thanks, Tim Ingalls Shared Communications, Inc. 801-618-2102 Office On 02/17/2012 06:34 PM, Tony Graziano wrote: The book was written based on an earlier version of sipx but the concept is no different. I have heard a lot of positive feedback from people who have ready the book. If you stop being vague and ask questions while providing detail I'm sure you will get the answers you seek, if you are actively looking for answers. An example would be: I use phone model "a" with firmware version "1" and my calls are sometimes connected with one way audio using trunks from so and so and a firewall from blankety blank. Here is my sip trace. If you have a little mystery it takes a little digging and problem solving to find out why. Dig in and see what's wrong. If you want to resell siptrunking (no matter the platform and provider) you had best be able to do this any given day anyway. Good luck. On Feb 17, 2012 8:16 PM, "Tim Ingalls" <t...@sharedcom.net> wrote: I did read the book. There are lots of important technical details that are not in the book. Thanks, Tim Ingalls Shared Communications, Inc. 801-618-2102 Office On 02/16/2012 07:29 PM, Tony Graziano wrote: You should read the book. On Feb 16, 2012 9:03 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/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
