Administrator Guide: Consolidated Management

Table of contents

History

[2013/02/15]
  • Initial version based on SMP 4.8 admin guide

Overview

Consolidated Management allows to configure a single logical Unified Communication system (SOP cluster) which is physically implemented by a number of autonomous SOPs.

A single logical system implies that:
  • All extensions and phones are uniquely defined in a single directory interface but can be spread on different machines (SOPs)
  • Intelligence is shared by all the different SOPs and is uniquely defined.

An autonomous SOP means:
  • If connections between SOPs are broken, each SOP contains all the necessary information to continue to work autonomously.

Benefits

  • Easier design, configuration and maintenance: callflows, restriction groups, internal routing, prompts, music on hold, etc... are configured only once for the cluster.
  • Flexible internal routing: Provide an easy and flexible way to connect different SOPs using any type of interface (SIP/IAX/PRI etc...) and codecs. For example, 2 companies can share the same communication platform through the use of a PRI without interconnecting their LANs.
  • Better resilience on WAN outage: An autonomous SOP works with the full feature set even if the WAN between SOPs is broken.
  • Better scalability: Adding new users is just a matter of adding a new SOP in the cluster.
  • Easy maintenance of heterogeneous configuration: Different versions of the module can be installed on the different SOPs. This enables you to deploy new features on specific SOPs only where they are required, still consolidating the management.
  • Personal User Mobility: Users with a virtual phone can log in their extensions on any phone of any SOP in the cluster.

Requirements

  • Consolidated Management function is only available in the 'ESCAUX Corporate Edition'.

Service Enabling

When the consolidated management option is activated, an additional Cluster Level is added to the SOP network overview page. The Cluster Manager is just a virtual representation of the cluster as a whole and not a physical machine.

In such a configuration, the management can be done at Cluster, SOP and Clone level.

The following menu items are available on the Cluster level:
  • Directory
    • Users
    • Internal Directory
  • Communication Flow Studio
  • Communication Routing
    • Intra-cluster routing
    • Route Groups
    • Restriction Groups
    • External Number mapping (incoming and outgoing)
  • Resources
  • Reporting
    • Advanced Reporting
    • Time slot definition
    • Price list
  • Advanced
    • Action Management
    • Configuration Management
    • System Tasks

The following menu items are available on the SOP level:
  • Directory
    • Internal Directory (only for extensions defined on the master physical SOP)
  • Communication Routing
    • Extra-cluster routing
  • Resources (only for resources defined on the master physical SOP)
  • Reporting
    • Basic Reporting
  • Advanced
    • Server Configuration
    • Module Configuration
    • Configuration Management
    • System Status
    • System Tasks

The following menu items are available on the Clone level:
  • Advanced
    • Server Configuration
  • System Status

You can navigate to the Cluster Manager by clicking the world icon:

Cluster Manager icon

The SOP network map can be requested by clicking on the tree icon:

SOP network map icon

Service delivery

Cluster Manager configuration

The configuration of a Cluster Manager is similar to a single SOP except for the following:
  • there is an additional page for configuring the intra-cluster routing
  • the internal directory has an additional SOP property indicating on which physical SOP the extension resides (home SOP)
  • technical extensions in the internal directory can be defined on "all" SOPs.
    • the callflow for those extensions will always be executed on the local SOP (same SOP than the caller).
    • extensions defined on "all" SOPs should have a static profile and use STARTAPPLICATION as parameters are not saved in SOP databases
    • note that it is not a way to provide Active-Active redundancy
  • each phone has an additional SOP property indicating on which physical SOP the phone will register
  • the following constraints apply:
    • the SOP of the primary and secondary phone must match the SOP of the extension
    • a queue can only contain phones that are located on the same SOP

Intra-cluster routing

Intra-cluster routing is the mechanism to specify how individual extensions are routed within the cluster. The idea is to start by defining a full mesh of connections between all SOPs and then optimize the routing by adding more specifc routes.

In order to facilitate the meshed network implementation, the concept of a mesh route has been introduced. A mesh route is an interface configured on all SOPs pointing to a specific SOP. Therefore an special trunk is foreseen, the SIP Mesh Trunk

To configure the intra-cluster routing:

  • Create a SIP Mesh Trunk with the required parameters pointing towards each SOP
  • Navigate to Communication Routing > Intra-cluster routing
  • Define specific, default and mesh routes
  • Each SOP must be connected to each other:

Intra-cluster routing

Per SOP configuration

Following things remain to be done for each SOP separately:
  • SOP server and module configuration
  • Extra Cluster Routing (legacy routing):
    • Dial plan can vary from one SOP to another taking into account national dial plan. As a result, each route group can have a different implementation from one SOP to another. For example: the 'Mobile route group' can be different in US and in Belgium

Checklist for Consolidated Management configuration

  • Directory entries must have the SOP set in order to attach them to a specific (home) SOP
  • Some types of resources can be:
    • Configured on a single SOP: E.g. ZOA10001 (Native PRI interface), Phones, ...
    • Configured on all SOPs: E.g. SOA20001 (Mesh SIP trunk), ...
    • Either configured on a single or on all SOPs: E.g. SDA10001 (Wireless Phones), ...
  • Resource names must be unique for the whole cluster
  • Extra-cluster routing can use mesh trunks to facilitate the routing table
  • In order to synchronise prompts and music-on-hold among the whole cluster, the Cluster & Active-Active Support module has to be reinstalled on every sop each time a new sop is added to the cluster
  • Queues < 2.0 are defined on all SOPs. Example: a 'support' queue, when defined will be available on all SOPs (in fact all SOPs will have a queue named "support" but it will not be the same queue) but a queue on SOP A can only contain phones located on SOP A. Queues >= 2.0 are only defined on selected SOPs.
  • The STARTDYNAMICAPPLICATION.4.00+ application selector must be used to route calls taking into account the intra-cluster routing.
  • The STARTAPPLICATION application selector can be used to simply call a local implementation (for example with a local queue) of a callflow.
  • a new GetExtensionInfo action allows to get the home SOP of a specific extension. It is then possible to use CallInterface with a mesh trunk to call a specific application on the home SOP.
  • When a call enters via an interface and is routed to the internal context, the MapDDI action is called to map the external number to an internal number. It is only at this point and by using the STARTAPPLICCATION.4.00 (or above) application selector that the intra-cluster routing will be applied.
  • Pickup Groups are defined per SOP.
  • It is advised to always configure internal directory and resources at the Cluster Manager level.

Speeding up Apply Changes on large installations

On a cluster with many SOPs and many extensions/resources, a full "Apply Cluster Changes" can take a considerable time to complete. If this is a problem, a number of possibilities exist to avoid this:

  • Apply SOP Changes: From the SOP view you can do "Apply SOP Changes". This will only run the apply changes on one SOP instead of all. This can be used if the change only affects one SOP. Examples are changes in phone resources, physical interfaces and extra-cluster routes. Also changes in callflows if they are only used on one SOP.
  • Apply Extension Change: In the internal directory, press the "Apply Extension Change" icon to apply the changes for one extension. Note that changes to an extension will be replicated to all SOPs in the Cluster. You cannot use Apply SOP Changes for extensions. See SMP Admin Guide, section "Move, Add and Change an extension" and the Administrator Guide Extension Move-Add-Change.
  • Apply Callflow Change: In the callflow editor, use the "Apply Callflow Changes" to apply just the changes made to that callflow. The change in done on all SOPs in the cluster. See the Administrator Guide Apply Callflow Changes.

Other resources

Copyright © Escaux SA