My company has been actively using an Allworx 6x since 2008, during which time we have always been using a SIP trunk for calling and have been with bandwidth.com as our primary provider.  There are so many problems we have encountered over the years with so many caveats that it won’t help to review the old information except to say we have burned too much time working with Allworx idiosyncrosies over the years.

Pros:

1. A solid, local hardware solution with programmability to work with hard lines, SIP trunks and a great deal of programmability on the phones.
2. The phones have programmable buttons with multiple colors such that you can see messages, other lines busy or a variety of other functions.
3. Many improvements over the years have led to a mature architecture that does 95% of what we want to do.
4. The handset call quality is generally good and the basic phone function allows for an efficient workflow with call staff and regular staff.

Cons:

1. Redundancy is an afterthought and support is little help.  I want to buy a solution using a SIP trunk that can failover from one connection to another easily with a high quality, multi-wan router sitting in front of the Allworx. Due to the way the Allworx is programmed and it’s SIP packets are handled, a solid solution does not exist.  The result is unreliable phone service if you have an unreliable connection.  If this one issue were dealt with, my happiness with this system would improve greatly.
2. The phones are outlandishly expensive for the quality you get.  Many phone models are not duplex despite marketing claims.  I spent more money adding phones for several offices this year than some entire systems cost with more phones in total.
3. Poor documentation for various features.
4. When we bought this system in 2008, we were using ringcentral with many issues.  As cloud services have matured, the need for a local PBX has diminished.  The benefits of a local PBX do still exist but they come at greater cost that must be weighed more carefully now.

Conclusion:

The Allworx system is generally competent and worth a solid look.  Were I starting my company today and faced with the same decision I was faced with in 2008, I believe I would choose a cloud based service.  The lack of redundancy, difficult to navigate or unhelpful support and high cost (once phones and features are included) prevent the Allworx 6x from competing with now mature cloud based phone systems.  During this same time, the cloud services have themselves matured and now offer similar or better reliability and features at a lower price point.

With traditional hard lines instead of a SIP trunk, the Allworx 6x would gain reliability but lose flexibility at which point my conclusion remains the same.

Yesterday, one of my sites went down while using a Cradlepoint MBR1400.  This was especially odd given that the area did not have an internet outage and because this site has a Comcast primary and 4G secondary connection.

I was not on site and the local staff chose to reboot the router which resolved the issue short term.  The question remained, why did the connection fail with primary and secondary connections that were up?

The answer came from the the failure check settings in the MBR1400.  Both the primary and secondary connections were set to check 8.8.8.8 for failure testing and failback was based on time.  8.8.8.8 (google dns) went down causing the primary connection test to fail so the cradlepoint switched to the secondary connection.  The secondary connection test to 8.8.8.8 also failed causing the MBR1400 to re-try primary.  Essentially at this point the system entered a logical loop in which it stayed stuck until a reboot.  The total downtime was approximately 25 minutes (unacceptably poor).

There are two parts to the resolution here.  The settings need to be altered as they were programmed poorly (though the documentation on this is lacking).  After some testing and communication with Cradlepoint I will update which settings we found to be effective.  The second part to the resolution requires a fundamental change from Cradlepoint.  Simply put, you cannot test a single ip otherwise you may end up with a false outage as we did.  Even if that ip has Google reliability.  The failure check testing should be using 2 to 4 ip addresses with programmability for how quickly a positive result is active upon.

So, please improve your failure check Cradlepoint to easily prevent false outages for the market you serve.

Update: Per recommendations from Cradlepoint, I changed the settings per the images below.  The results were much improved.  45 seconds and several lost packets to failover on a primary line disconnect. ~5 seconds and one lost packet on primary modem power failure. Failback in both cases lost only one packet and didn’t come up until the cable modem was ready.  We also worked with comcast to improve the modem cycle time.

While these improvements are a huge, there are still issues.  The Cradlepoint problem of testing only one destination for our primary wired connection is a clearly identifiable point of failure that largely negates the redundancy benefits.  The failover event could be improved on our primary line disconnect test case, bringing the time down from 45 seconds and many lost packets which we know competing hardware can achieve.

Primary, wired connection.

Secondary, 4G connection.