I'm glad that you are starting work on this problem. One thing to keep in mind is the nature of the failures you are guarding against. In practice, the commonest failure isn't having a server go down but rather having the WAN get partitioned. This is a particularly interesting failure mode because both subsections of the system should keep operating, but they need to automatically resynchronize when the WAN starts working again. That is easy for phone calls but much harder for configuration information and voicemails.
In regard to the sipXecs components, they fall into several classes regarding redundancy: The proxy and registrar are already fully redundant, and an arbitrary number of copies of each can be hot-standbys for each other. With careful configuration, the park server can do this as well. The config system is more complex because it has two components: the web user-interface, through which the user updates a Postgres database, and a configuration-generation component, which generates configuration files from the database information. For full redundancy, each replica of the UI needs to be able to access "the same" database. Presumably this requires replacing vanilla Postgres with a distributed-and-redundant database system that keeps duplicate copies of the data on at least two servers. Once that difficult part is put into place, it's easy to arrange for each replica of the database to generate identical replicas of all the config files. The voicemaill system is even more difficult -- the database of recorded voicemails needs to be replicated between at least two servers, and when unified operation is restored, the replicas need to be be resynchronized. With the configuration information, we may allow that resynchronizing may require some manual intervention, with VM it has to be completely automatic. I would avoid having multiple servers masquerade for each other using the same IP address, as it puts a lot of demands on the underlying OS and the surrounding network design. Instead, use multiple DNS records to provide multiple addresses for each DNS name that is used. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
