Douglas,
On 02/17/2012 07:29 AM, Douglas Hubler wrote: > Tim, I welcomed your frank email, but I'm weird like that ;) > > On Thu, Feb 16, 2012 at 9:02 PM, Tim Ingalls<t...@sharedcom.net> wrote: >> 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. > not sure here, I would need to look at logs. > >> 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. > ITSP interop is a serious challenge. No one has stepped forward to > maintain sipxbridge so I'm predicting switch to Karoo/Freeswitch in > our short term future. What I feel is important in this area is to > join a larger community already addressing interop issues instead of > trying to start from scratch with sipxbridge. > I like your approach. When I first saw sipXecs, it was actually during a demo of the Nortel SCS500 version of it. One thing I noticed was that it didn't have an internal SIP trunking capability like Asterisk had at the time. Would you suggest an external SIP gateway instead of sipXbridge? If so, which one seems to have the best compatibility with ITSPs? >> 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? > unclear, deadlocks or stale server state with config possibly. > > re: stale configs much work has gone into 4.6 to ensure services are > made aware of configuration changes > > re: deadlocks we're now using a thread safe datastore (mongo) which > removed the need for dozens of locks. Locks that absolutely caused > deadlocks in 4.4 with root causes rarely determined. > >> Periodically, (perhaps due to a sipviscious attack) certain services just >> stop working. Sometimes it is the proxy service. Sometimes it is the >> registrar service. > 4.6 will have a firewall enabled by default. (One that you could turn > off if you already have a firewall in your network.) 4.6 will have > the platform capability to integrate DoS and call fraud detection, but > until then there are ample examples to solve this outside of sipxecs. > I've just been too busy to implement fail2ban. It's not a huge issue for me yet. For a customer installation, it would be. >> 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). > Agreed, not cool. > Right? But if reaching the STUN server fails, couldn't the server try again sooner instead of just shutting down the media relay service until I manually have to intervene? Is there some secret setting I could tweak to make it try again? And if I get this error: The ITSP Account 'seattle.voip.ms' disallowed an operation because of Authentication failure. Suggested Resolution: Check your ITSP Account domain and password and restart the SIP Trunking service. couldn't the timeout before another retry be much much less than 10 minutes? Is there a config file setting I could tweak to make it wait only 10 seconds or so? Would there be any issues with trying again so soon? >> 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? > in 4.4 I think they should but hard to tell. This is one of my last > things to look at for 4.6 beta. I'm looking to use the tried and true > SNMP server installed by linux that has capabilities to run commands > to fix a detected issue. > >> 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. > Telecats wrote a plugin for 4.6 that will give greater control here. > It needs some more testing but was working with last engineering > tests. > But is there a way to find out why it works for one user using one gateway/branch config and not for another user that is assigned to another branch and gateway? Is there a specific log file to look at? As far as I can tell, the configurations are identical. Is it just an ITSP issue? But when I had both users sent to the same ITSP (before I switched one of the DIDs to a Voip.ms), CID worked for one user and not for the other. Strange behavior, huh? >> 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. > I'm looking to integrate homer > http://www.sipcapture.org/ > > http://wiki.sipfoundry.org/display/sipXecs/2012+sipX-CoLab+Hackfest > >> 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. > Releases up to and including sipxecs 4.4 were largely the efforts of > Avaya and Nortel. sipxecs 4.6 represents a major effort put forward > by eZuce, the new sponsor. If nothing else, you owe it to yourself to > at least try 4.6 before you decide to switch forever. 4.6 is really > about increasing the core stability and paving the way for stability > in non-core features. Net-Net not all bugs will go away by any means, > but you should see an increase in stability showing the direction > sipxecs is headed and why i think it's a great investment to get in > on now. > > sipxecs 4.6 did a complete turn around as far as platform > capabilities. So even if you aren't a developer or have developer > resources at hand, you should see more contributions from the public > evolving that are solving some of the same problems you are having. > Problems such as a lack of tools. > My two cents is that priority should be placed on interop testing with ITSPs. The cost savings involved with SIP trunking is what spurred many people like me to implement VOIP via systems like Trixbox (Asterisk + FreePBX) several years ago before most regular carriers had a SIP trunking product at all. Although lots of people on here are bashing ITSPs, my SIP trunking experience with Trixbox was fabulous. My calls were clearer, call routing was very flexible, and things just worked. The fact that SIP trunking doesn't work as well with sipXecs prevents it from having as much cutting-edge appeal to guys like me who don't have lots of bucks like a university to pay for PRIs everywhere. I know that Ezuce thinks that the best market for its product is large businesses. I disagree. I think that the big untapped market is the small business. 95% or more of companies in Utah have under 100 employees. That's a big portion of the pie, and most small businesses haven't figured out VOIP yet. Every week I go into several small businesses, and tons of them have old Nortel Norstar systems that they would love to dump for a VoIP system, but they can't afford $50,000 for a new system. sipXecs is a great fit for them (if it is stable). I really do appreciate your attitude about all of this. I also appreciate all of the hard work to make this an even better system than it is. I wish I had the cash to attend the upcoming conference. I need to sell a few phone systems first. (I have prospects, just no system to sell them yet). >> Also, is anyone willing to have a phone conversation about this and impart >> some wisdom or have a partnership conversation? > regarding the technology, sure, i'll send you my number off list . I > can also direct you to folks that can talk about partnerships if you > want. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
