We know in Wildix it is very easy to create a network of several systems. Once the network is created, it is completely transparent to end users whether they are in a system that is part of a network or not. The systems on the network appear as a single system to end users. When in a WMS Network environment, there is even a filter in CDR-View to filter reports based on which PBX the activity happened on. See the filter in the screenshot below.
However, there is some configuration needed in order to have the filter to work. Without such configuration the systems on the WMS Network can only access their own information. The purpose of this document is to explain the needed configurations to have a unified CDR-View in a WMS Network.
The only requirement to have a unified CDR-View is to have all of the systems configured to use the same database. Out of the box, every system uses a local database. So, first of all we need a database server that is accessible to all of the systems on the WMS network. For the sake of simplicity in this document we use one of the systems as a database server for the rest of systems.
Note: If you have an external database server you just have to recreate the database structure (use mysqldump), or even take a full dump of one of the servers database and apply it in your database server.
Note: Starting from WMS 5.03, there are also the following requirements for correct work of the unified CDR-View:
In case of VM/ HW Server (main) PBX, an external database should be set up.
In case of Cloud Server PBX, Client PBXs should also be Cloud and belong to the same region. Please open a ticket with the Support team to get assistance with the setup.
Here we take advantage of the fact that, once part of a WMS Network, systems are part of a secure intranetwork. In this scenario we have 2 systems:
As you can see, systems communicate to each other using the displayed IP addresses. For this example, we use system 2211000025eb (IP 126.96.36.199) as the database server.
The database server needs to be accessible by all of the other systems. Since here we are using one of the systems as the database server, we don't need to worry about the database structure, it is already there. We just need to make it available:
On the 188.8.131.52 server, login to mysql console (Password is wil01dix):
$mysql -u root -p
Execute the following command:
> show grants;
As you can see in the previous picture, the login for the root account is only available from the localhost. We need to execute the following command in order to enable access from remote locations:
>GRANT ALL PRIVILEGES ON *.* TO 'root'@'184.108.40.206' IDENTIFIED BY PASSWORD '*47C562035B611FE7E0CD4CF0F58AEC9EDEBF20E3' WITH GRANT OPTION;
220.127.116.11: this is the IP address of the remote Wildix system. Note that you need to execute the same command for all of the IPs you want to be able to use this database server. Specifically, all of the PBXs in the WMS network that are not the primary DB server (18.104.22.168 in our case).
'*47C562035B611FE7E0CD4CF0F58AEC9EDEBF20E3': this is the hash of the root password. You can copy the value from the output of the command on step number 2, that way we will use the same password both for local and remote connections
To apply changes immediately, execute following command on mysql cli:
Now you can logout of mysql console by executing:
There is one more step needed. By default mysql only accepts requests from the loopback. To finalize the enabling of remote connections, open the next config file with some text editor:
Search for a line with “bind-address = 127.0.0.1” and add a # to the beginning. This comments out this line and no longer restricts requests only to those that come on the loopback interface
Save and close the file, then execute:
$systemctl restart mysqld.service
Now we have our database server ready. It can be accessed by remote servers we added and on interfaces other than the loopback interface. You can now test it from the remote system (the other system part of the WMS Network) by executing:
$mysql -u root -p -h 22.214.171.124
And entering any password (invalid) you should see a message like the following:
If you see the previous message, you can proceed to configuring the clients.
Configuring the rest of the Wildix systems to use the server database is actually pretty easy (provided the server is ready). By default your Wildix system uses a local database. We just need to point to the remote server instead of the localhost. We accomplish this by editing the file /etc/callweaver/cdr_mysql.conf:
As you can see in the previous picture, Wildix is pointing to the localhost (127.0.0.1). You just need to change it to the server IP address, 126.96.36.199 in this example:
In the previous picture you can note that, besides the hostname, we also changed the timeout. This is a good idea since clients won't be using the localhost and surely the access to a remote DB will take more time than for a local DB.
Another thing worth mentioning is the fact that we did not change the dbname, table, user or port. This is because we are using a Wildix system as a database server, which means the database structure is ready. We did not change the password either because we configured the same password for the remote root access as the local root account was using.
Important: To avoid system overwriting the custom configurations with default configs after reboot/ upgrade of the PBX, lock files should be created.
1) Run the command:
2) Run the below command to apply the changes:
callweaver -rx 'reload'
Once the configuration is complete, you are able to see events for any system from any system:
If the systems you are working on already have some records in the CDR, all of the previous records on the clients won't be available on cdrview
If you use a Wildix system as a database server, old records on the DB server cdrview will be available even after unifying CDRs
If you are using an external database server, the database structure needs to be there before configuring the clients
If you are using an external database server, no previous records will be available (unless a full dump was used to recreate the database. In such case, records contained in the dump will be available)
If you are not using the same database name, table name, user or password, you need to adjust corresponding parameters on the cdr_mysql.conf file