This site uses cookies, if you continue you agree to our cookie policy.

PBX Clustering

This article explains the benefits of clustering PBXs together, the problem that this creates for a call logger and how Data Track's Eclipse CMS call logger can overcome this problem.


Scalability is a key requirement when purchasing equipment for today's networks. Equipment must meet the needs of today and the growth of tomorrow. One way PBX manufacturers achieve this is to allow 2 or more PBXs of the same model to be joined or 'clustered' together as dictated by the organisation's requirements. Extensions, PSTN trunks and Operator Consoles can all be connected to any PBX within the cluster. An IPBX trunk line connects each of the PBXs together and enables them to collectively function as a single large PBX.

Telecommunications is a vital part of any business and many use a call logging package in conjunction with their PBX systems. Call logging provides management reporting information that can be used to monitor and assess a company's utilisation of their telecoms system, its performance, operator and employee performance, as well as the overall cost.

The Problem

On a single PBX, one SMDR port outputs the call data to a call logger for processing. In a cluster site, there will be two or more PBXs supplying call logging data to the call logger. This information must be carefully stitched back together if a clear view of internal, external and tandem (trunk to trunk) calls is to be presented within the management reports.

The following is an example of a PBX cluster.


Internal Calls

On a cluster site, SMDR output for an internal call made from extension 102 to extension 103 appears on PBX B as an outgoing call from extension 102 to an IPBX trunk line. PBX C shows an incoming call from an IPBX trunk to extension 103. To a call logger, neither SMDR output describes an internal call as it would appear on a single PBX system. Consequently, only internal calls between extensions connected to the same PBX would be reported accurately. An administrator would have to manually identify the calls between the other PBXs.

External Calls

The SMDR output from PBX A would clearly identify an external call if one was made from extension 101 and directed out onto one of the PSTN trunks. However, if extension 102 made an external call, the SMDR data from PBX B would only show that the call went out on an IPBX trunk; just as it would if extension 102 made an internal call to extension 101. PBX A would then record that a tandem (IPBX trunk to PSTN trunk) call had been made but would not identify where it originated from. So in the example used, only one third of all the external calls made by an organisation could be traced in the reporting to the originating extension (those extensions connected to PBX A).

Operator Performance

In the example PBX network, monitoring operator performance would be very difficult. Any external calls being directed to the operator would appear on the SMDR data for PBX A as a tandem call. PBX C would show an incoming IPBX trunk call being directed to the operator. It would be impossible to tell which external calls were directed to which operator. When operators transferred calls, two thirds of them would go out on an IPBX trunk, rather than being recognised by a call logger as a call transferred to an extension by the operator. This makes it very hard for the call logger to provide an accurate picture of operator performance.

The Solution

Data Track has introduced the Cluster Sites feature into the Eclipse Call Management System. A Cluster Site is a logical grouping created within Eclipse CMS by telling the software which physical sites (e.g. PBX A, B & C) belong to the new cluster site. Once Eclipse CMS knows this information, it will automatically add all the trunks and extensions from the physical sites to the new cluster site. As the SMDR data from each physical site is collected and converted, the conversion process creates another set of modified call segment files for the cluster site. This process alters the call data to look the same as the output from a single PBX; matching up calls in the cluster and removing the parts involving IPBX trunks. Accurate and meaningful reports can now be generated using data from the cluster site.

The implementation of cluster sites within Eclipse CMS does not change the data that has been collected and converted for the actual physical sites. They still exist as part of the Eclipse CMS configuration. So it is possible to run reports that analyse the performance, utilisation and cost of each PBX within the cluster separately.

Eclipse CMS is the only call logging package to support clustering in this way; providing report information on a cluster as if it was a single PBX. Some packages will try to merge all the SMDR data from PBXs within the cluster together. Although this enables the software to produce reports based on all the PBXs within the cluster at the same time, it still does not address the issue that there could be two call detail records for a single call: one record showing the call originating on PBX A and routed out on an IPBX trunk to PBX B. While the other shows an incoming IPBX trunk call on PBX B (internal or external) to an extension. An administrator would still need to manually examine each call to work out its original starting point and final destination.

By Dominic Martin