There is a finite set of subsystems that can be individually turned on or off on each server: SIP proxy, Call-Processing, Voicemail, Database, DNS, DHCP, FTP, etc. For some of these subsystems, clustering does not make sense (for example DHCP or FTP) and it's enough to offer the same service (with identical or similar configurations) on a set of servers. For other subsystems, the design drives the configuration so that servers belonging to the same cluster behave as expected: database servers in the same cluster are configured to replicate off each other; call-processing servers share the same database so that call-forward-all, do-not-disturb, etc. are available to all servers in the call-processing cluster; proxy servers share the same database so that phone registration information is shared; voicemail servers share information about passwords, number of messages, and replicate the messages content off each other.

All of these aspects are automatically handled by the management system once the servers are assigned to the different clusters in the configuration.

Note that in our design all servers are active; this is not a "hot/standby" design model. Where applicable, servers in clusters are load-balanced using standard SRV records, which are also generated by the management subsystem.

We plan to support as many types of devices as possible. We've had some contacts with Aastra and plan to add support for their phones.

We have code to provide XML directories for Polycom phones; however in the case of the Polycom phones this is a simple flat file that is downloaded at boot time, not dynamic scripting over HTTP.

On the other hand we also provision Apache (for the provisioning GUI only at this time, but this can be expanded), so, given the specifics of the XML interaction between the Aastra phone and the sever, we could build or integrate an application that handles this.

Not in the spring. Call menus can be configured via the text-based interface today; we haven't had requests for conference bridges (MeetMe) and queues yet but this wouldn't be too difficult to add to the provisioning system (again, not as GUI elements but as text-based elements in the first place, unless you'd be interested in financing the GUI development for these, as one of our clients has pledged to do for other elements).

The main issue we are seeing with both MeetMe and Queues is that neither of these can be distributed when using Asterisk, meaning that a solution using either of these is not natively highly-available. We haven't started investigating how this could be done at this time; our experience making Asterisk's Voicemail highly-available is that the issues to solve are non-trivial and take time to develop properly. Obviously doing failover (between a hot and a standby server) can be achieved relatively easily but is not "high availability" (calls or conferences still get dropped).

CDR are centrally collected; again, getting web access to CDRs is mostly a question of designing the proper GUI components. We have plans for this to be done later in the year based on our current financing plans.

Although we haven't talked directly with Aheeva we think integrating with their solution should be somewhat straightforward.