|
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:
|
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
