Tony, perhaps you missed the insulting comment by Martin, "Grow up and take charge" and then basically says to go run Asterisk. If you did miss it, I can see how you would rightfully be upset with me.
I did not start the rudeness. Martin did. I do not need to be told to grow up and bugger off when all I'm trying to do is find workarounds for the weaknesses in his company's/project's product. Would you enjoy that kind of comment? His comment was totally unprofessional. I have considered for a long time the option of joining the Ezuce partner program, but after a comment like that I don't see that they value their company image or potential partners. I would expect that the CEO of a company would acknowledge the weaknesses in the product and share a desire and a plan to fix them. That would be grown-up behavior. Instead, he just treats me like I'm whining and should stop complaining and should stop asking people for configurations that work. I have never been treated like that by any CEO/President of a telecom (or any other) company. If you did see Martin's comment that I was responding to, I guess I don't see how you can't acknowledge that he had it coming. Why aren't you asking Martin to apologize? Do you really defend him? If so, I would encourage everyone on the list to ignore you, too. I don't have a beef with you, but neither do I feel the need to be bullied. My intent here is to be professional, and I expect the same back. Thanks, Tim Ingalls Shared Communications, Inc. 801-618-2102 Office On 02/18/2012 12:07 AM, Tony Graziano wrote: > I don't think any of the responses to you have been unprofessional, > that was uncalled for. > > I'll encourage anyone reading this thread to ignore the poster until > (if) he musters up some civility. > > > On Sat, Feb 18, 2012 at 2:01 AM, Tim Ingalls<t...@sharedcom.net> wrote: >> Martin, >> >> I'm trying to grow up. I really am. I'll try to take charge. I really will. >> Thanks for the advice and the encouragement. >> >> Does eZuce pay you to offend potential partners? What a great job to have! >> Oh, wait, you're the President and CEO of Ezuce! So you can offend anyone >> you want to! That's so great for you. You don't have to care about the image >> of your company or anything like that. I'm sure none of this will ever come >> back to haunt you. How could it? You can just delete the whole thread, since >> it makes your company look bad. Awesome. >> >> I don't think I got very many specific answers regarding ITSPs. But maybe >> there aren't any answers to find there. If sipXecs can't successfully >> connect to ITSPs, then maybe I have found my answer: just use PSTN. Or use a >> product that does work well with ITSPs. >> >> To any whose fragile sense of security and/or superiority has been shattered >> by the ideas in this very reasonable thread, my apologies, but you might >> want to grow up and take charge...of your company. >> >> Thanks, >> >> Tim Ingalls >> Shared Communications, Inc. >> 801-618-2102 Office >> >> >> On 02/17/2012 09:43 PM, Martin Steinmann wrote: >> >> Tim – as I read through this thread I think you got your answers. Grow up >> and take charge. You can do it – many others have before you. If not there >> is always Asterisk. >> >> --martin >> >> >> >> >> >> From: sipx-users-boun...@list.sipfoundry.org >> [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tim Ingalls >> Sent: Friday, February 17, 2012 11:35 PM >> To: Michael Picher; sipx-users list >> Subject: Re: [sipx-users] sipXecs Commercial Feasibility >> >> >> >> I'm hoping we can not resort to name calling, Robert. I'm just trying to >> have a serious conversation so I can stop messing around with unsuccessful >> configs and get out and start selling. >> >> Michael, I believe that you have multi-thousand-seat systems. Are you using >> any ITSPs for sipXecs, or are those installations using traditional TDM >> systems? If you are using ITSPs, which ones work flawlessly with the system? >> Can you share screenshots of the config pages or upload a valid snapshot or >> something? Are you only using TDM access as opposed to SIP trunking? >> >> I realize that you wrote the book, but there is more to it than that, isn't >> there. The book covers the basics. There are lots of holes that a person can >> fall into if they try various things that aren't documented in your book. >> >> Are you thinking of doing a second edition? I think that would be a great >> idea, and I would buy it if it went significantly beyond what the current >> one contains. But how do you handle the conflict between making money on the >> book and providing free info in the sipXecs wiki? I can see how it may be >> difficult to investing lots of time updating the wiki since that would take >> away some of the value of buying the book. I'm not sure how I would deal >> with that. >> >> Thanks, >> >> >> >> Tim Ingalls >> >> Shared Communications, Inc. >> >> 801-618-2102 Office >> >> >> >> >> On 02/17/2012 10:12 AM, Michael Picher wrote: >> >> Ok... there are just some who can't get it... no worries. Properly >> installed, with proper gear it works great. I have many multi-thousand seat >> systems to point to. It's not everybody's cup of tea but I respectfully >> disagree with you. >> >> On Feb 17, 2012 12:03 PM, "Robert Durst"<rdu...@smsystems.com> wrote: >> >> Picher, >> >> >> >> No one was discussing hosted solutions. We have deployed Asterisk switches >> at each of our client locations. Simply, sipx is a mess, much like it’s >> idiot supporters. >> >> >> >> >> >> Rob Durst >> >> Santa Monica Systems, Inc. >> >> 310.395.5135 >> >> www.smsystems.com >> >> To ensure perfect aim, shoot first and call whatever you hit the target >> >> >> >> From: Michael Picher [mailto:mpic...@ezuce.com] >> Sent: Friday, February 17, 2012 6:26 AM >> To: Robert Durst >> Cc: t...@sharedcom.net; tgrazi...@myitdepartment.net >> Subject: Re: [sipx-users] sipXecs Commercial Feasibility >> >> >> >> Now that's a troll... or at least a vulture. >> >> >> >> I think the other thing some folks run into is that they try to use this as >> a hosted / tenanted system.... which it isn't. nor does it pretend to be. >> >> >> >> Mike >> >> >> >> On Fri, Feb 17, 2012 at 9:12 AM, Robert Durst<rdu...@smsystems.com> wrote: >> >> Tim, >> >> >> >> We receive most of the sipx emails (now in my junk folder) as we have >> previously tested sipx. After seeing this, I thought I’d respond with a few >> of our own experiences. >> >> >> >> We are in a similar situation, as we are relatively new to the VOIP world. >> We currently manage over 400 DIDs, so we are still very small. But there >> have been a couple of discoveries that make our job much easier now. First, >> after testing most of the voip apps, we settled with Asterisk (you are >> already aware of the myriad of problems with sipx). Second, after employing >> Sonicwall routers at all clients, we have now switched away for the voice >> circuits. Most of the random problems have disappeared (no more dropped >> calls leaving VMs, no more one way audio loss, etc.) We now use a $50 router >> (tp-link), which works even in 100 phone deployments. And after two years >> with Vitelity, we are now currently porting out all our accounts. The >> underlying carrier problems, the sbc problems, the hacker attacks, etc. were >> just too much to ask our clients to accept. VI has good service (so far), >> few trouble tickets, and good rates (originations .001) >> >> >> >> For phones, we have used Polycom, Aastra (my favorite), Snom and >> Grandstream. All work OK (Grandstream is OK now with latest firmware >> update). >> >> >> >> Hope some of this is helpful. >> >> >> >> Rob Durst >> >> Santa Monica Systems, Inc. >> >> 310.395.5135 >> >> www.smsystems.com >> >> To ensure perfect aim, shoot first and call whatever you hit the target >> >> >> >> From: sipx-users-boun...@list.sipfoundry.org >> [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Becker, Jesse >> Sent: Friday, February 17, 2012 5:14 AM >> To: Discussion list for users of sipXecs software >> >> >> Subject: Re: [sipx-users] sipXecs Commercial Feasibility >> >> >> >> Tim, >> >> No one has accused you of being a troll and several of us have provided >> advise regarding LAN, firewall and PSTN setup. I would start with those >> recommendations and report back with any further issues to be addressed. >> >> On Feb 17, 2012 6:21 AM, "Tony Graziano"<tgrazi...@myitdepartment.net> >> wrote: >> >> A familiar refrain here is: >> >> Use good phones. Use good switching gear (and a vlan for voice). If >> you are supporting trunking and/or remote users have a thorough >> understanding of your firewall to ensure it is compatible or use a SBC >> that can deliver the desired results. >> >> Pick and choose your ITSP carefully too. If trunking is too >> porblmeatic, switch to PSTN service from the local phone company, it >> still works with sipx. I think unless you are VERY well rounded in >> telephony and SIP, reselling trunking will get you in over your head >> real fast. >> >> Many of the problems you list are likely related to LAN or firewall >> configurations. Some of what you are saying is strange to me (port >> numbers), because unless you really need to go outside the box you >> don't really have to change those things. >> >> Don't let anyone tell you voip is easy. Don't expect to start doing >> this without a primer in telephony functions too. Read the book. >> >> >> >> On Fri, Feb 17, 2012 at 5:02 AM, Michael Picher<mpic...@ezuce.com> wrote: >>> Tim, >>> >>> I think the message here from all involved is that cutting corners gives >>> you >>> the results you have experienced. >>> >>> A VoIP system will quickly point out the problems with your network. Good >>> network switches, properly configured are important to larger >>> installations. >>> >>> Cheap phones stink, my recommendation for now is to use Polycom. We're >>> trying to get a few others to the table but they aren't there yet with >>> their >>> plugins. >>> >>> With tier 3 players for ITSP connections, you get tier 3 service. If you >>> want top quality voice connections, get a top quality ITSP on a dedicated >>> link or get traditional service and bring it in with a gateway. >>> >>> Thanks, >>> Mike >>> >>> On Thu, Feb 16, 2012 at 9:02 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/ >>> >>> >>> >>> -- >>> Michael Picher, Director of Technical Services >>> eZuce, Inc. >>> >>> 300 Brickstone Square >>> >>> Suite 201 >>> >>> Andover, MA. 01810 >>> >>> O.978-296-1005 X2015 >>> M.207-956-0262 >>> @mpicher<http://twitter.com/mpicher> >>> www.ezuce.com >>> >>> >>> ------------------------------------------------------------------------------------------------------------ >>> Hope to see you at the sipX CoLab! http://www.sipfoundry.org/sipx-colab >>> A gathering for - open source users, eZuce customers& eZuce partners >>> Get the inside track on 4.6 and a glimpse at the future of sipXecs! >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> -- >> ~~~~~~~~~~~~~~~~~~ >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: tgrazi...@voice.myitdepartment.net >> 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: 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/ >> >> >> >> >> >> -- >> Michael Picher, Director of Technical Services >> eZuce, Inc. >> >> 300 Brickstone Square >> >> Suite 201 >> >> Andover, MA. 01810 >> >> O.978-296-1005 X2015 >> M.207-956-0262 >> @mpicher<http://twitter.com/mpicher> >> www.ezuce.com >> >> >> >> ------------------------------------------------------------------------------------------------------------ >> >> Hope to see you at the sipX CoLab! http://www.sipfoundry.org/sipx-colab >> >> A gathering for - open source users, eZuce customers& eZuce partners >> >> Get the inside track on 4.6 and a glimpse at the future of sipXecs! >> >> >> >> >> _______________________________________________ >> 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/
