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. > 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. > 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. > 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. > 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. > 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/
