On Fri, Feb 17, 2012 at 9:52 PM, Tim Ingalls <[email protected]> wrote: > 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.
Heck there is a wiki page for voip.ms with a how-to for sipxecs. Did you look at that? > > 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 have never seen that Tomato supports the proper outbound NAT to function with sipxbridge like it should. > > 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. > Then I would suggest if you still had one way audio problems your NAT entries were setup before the outbound NAT (Manual AON) and the NAT entries need to be configured for static port AFTER this is done. > 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" <[email protected]> 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" <[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/ > > > 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/ -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ -- 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/
