I would vote for redundancy in any customer facing application - Voicemail and Auto Attendant come to mind first. In a failed state, registered phones can call out, and even get calls when they are set up for DID (I'm assuming here, don't know for sure), but there needs to be continued call processing as if there isn't an issue in the system, via the Auto-Attendant and the voicemail system, which are pretty much table stakes in today's telecommunications environment for any company of size.
-----Original Message----- From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Scott Lawrence Sent: Tuesday, July 14, 2009 6:26 AM To: Keith Gearty Cc: sipx-users@list.sipfoundry.org; ingo...@netvision.an Subject: [sipx-users] Redundancy and load-sharing in sipXecs On Tue, 2009-07-14 at 10:05 +0100, Keith Gearty wrote: > Basically from what I can gather, the intended purpose of HA systems > is load balancing, not true redundancy. It would be nice if it were > designed with both purposes in mind, but it doesn't seem to be. I wouldn't say that... our strategy has been to use a redundancy strategy that encompasses load-sharing so that for an HA service that needs N systems to handle the load, you only need N+1 for HA. Keeping a standby system is more expensive. I would say that sipXecs is highly modular - different 'features' are implemented by separate loosely coupled components. This modularity has allowed us to incrementally upgrade a number of components (including a major upgrade of the voicemail service coming in 4.2!). This has allowed us to implement HA in some and not in others, which is a two-edged sword - it means that the extra burdens of HA are not imposed on every component (accelerating development and lowering system overhead), but that HA is not available for all. I'm interested in opinions on which services that are not currently redundant that users thing should be. If you could pick just one service for us to add HA to, what would it be? _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/