I think you need to apologize for your cross attitude with Martin and eZuce. It was rude, unprofessional, uncalled for and plain old disdainful.
I look forward to your public apology. On Feb 17, 2012 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. > > 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" <[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].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<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/
