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" <[email protected]> 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 <[email protected]> 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 <[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/ > > > > > > > > > > -- > > 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 > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > -- > ~~~~~~~~~~~~~~~~~~ > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > 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: [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/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
