The main reason for grouping services is to reduce complexity not only for the admin, but especially also for what combinations need to be tested, documented and supported in the field.
In general, we should not allow an admin to add or remove individual services to distributed servers. This is too complex to understand and document and creates too many test cases. We also cannot support the many possible configurations that would result. The following is a quick summary of what was discussed so far: a) Upon a new installation of a master server all services are installed and enabled on the master server. This server is called a Master. The admin can still see the table of services we have already including status for every service, but cannot add or remove services from that server. b) When the admin creates a new distributed server the admin shall only be able to select a preconfigured role for this new server. The proposal for the grouping is below in Scott's post. Instead of calling it SIP Router I'd prefer "Call Server". c) When creating a distributed media, conference or ACD server the admin shall either be able to move the existing such server that runs on the master to the new distributed server or create a new additional instance of this service. If the server is moved from the master to the new distributed server, all existing configuration shall be moved with it. I would be ok initially to say that services such as Park, Page, RLS, IVR can only run on the master. The main objective is to allow for load distribution for services that require a lot of resources. Creating a distributed call server (HA) has to allow for the allocation of additional (i.e. media) servicves to that server. I.e. the master runs VM and ACD, the HA call server runs conferencing. --martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence, Scott (BL60:9D30) Sent: Monday, October 20, 2008 2:14 PM To: sipx-dev Subject: [sipX-dev] Grouping services in a friendlier way Currently the Configuration->Services page displays all the individual services (in some order): ACDServer CallResolver CallResolver-Agent ConfigServer MediaServer PageServer ParkServer PresenceServer ResourceListServer SIPRegistrar SIPStatus SipXbridge sipXivr SIPXProxy SipXrelay (Side Note: We are missing some from this list: Certainly the conference service, and isn't there a sipxconfig-agent that has to run on an ACD system?) Especially given that some of those names are not exactly admin-friendly, I think it would be good to consider reducing the number of entries by creating some functional groups that have related functions. The Services page would then be restricted to configuring the functional groups on a Server. This not only makes it easier to understand, but Here's a strawman list of groups and what they contain (I'm not crazy about some of these group names; suggestions are encouraged); they reduce the number from 15 to 6: Management (always on the master, by definition) ConfigServer CallResolver SIP Router (N per cluster: replicated) SIPRegistrar SIPXProxy SipXrelay ResourceListServer CallResolver-Agent Voicemail (One per cluster) MediaServer SIPStatus Call Distribution (1|N ?) PageServer ParkServer sipXivr SIP Trunk (N per cluster) SipXbridge Call Center (N per cluster) ACDServer PresenceServer Conference Service (N per cluster) (?) Some questions to consider: * Do administrators need to be able to be able to "explode" the group to see what's inside them even if they cannot control them individually? * Does the above grouping create any problems? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
