Thanks, Tim Ingalls Shared Communications, Inc. 801-618-2102 Office
On 02/18/2012 12:03 AM, Tony Graziano wrote: > On Fri, Feb 17, 2012 at 9:52 PM, Tim Ingalls<t...@sharedcom.net> 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? Yes I did. This issue is not covered there. >> 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. > That is good info. Thanks. I'll try it with pfsense and see how stable it is. >> 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. > It's been a while since I did that, so I don't quite remember how it all works. I'll go back in and try to see what you're saying. I'll try to attach a screenshot of my settings. >> 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/ > > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
