maybe you should start with this book instead: http://www.amazon.com/gp/aw/d/1451612575/ref=mp_s_a_3?qid=1329577567&sr=8-3 On Feb 18, 2012 9:51 AM, "Tony Graziano" <[email protected]> wrote:
> 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/
