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/

Reply via email to