YOUR SOURCE FOR ELASTIX HOW-TOS

Getting started with your Elastix or Xorcom channel bank

Jose L Landivar — Tue, 16 Feb 2010 00:59:00 GMT

So you have purchased a new Elastix or Xorcom channel bank and don't know where to start. This guide will quickly get you up to speed on what you need to know.

We will show you how to configure an FXS port in your channel bank to start making calls with an analog phone. Then, you could extend the concept to configuring T1/E1 or FXO porrts. For this tutorial you will need a server running at least Elastix version 1.6-12 aside from the channel bank unit.

CONNECTING YOUR CHANNEL BANK

It does not get any easier than this. Simply connect the channel bank's rear USB port labeled "MAIN" to any USB port in your Elastix server with the USB cable provided.

In order to make sure everything is connected correctly, simply execute the "lsusb" command in your Elastix server (via ssh or console). In the following picture you can see the results of this command before and after plugging in the channel bank to the Elastix server.

In the latter result, you will notice an entry such as:

Bus 001 Device 004: ID e4e4:1162

Make a note of the Bus and Device numbers for the device with ID "e4e4:1162". In the above example, Bus = 001 and Device = 004.

Next, we will find out what kind of channel bank we have connected to our Elastix server. We do this using the command as follows:

# astribank_allow -D /proc/bus/usb/[Bus]/[Device]

In our case, this is how this command will look:

From the output of the command you can see we have a channel bank with 24 FXS ports.

CHANNEL BANK CONFIGURATION

We have already connected everything up. Now we need to make sure Elastix (and Asterisk) recognizes it. For this, we head over to the System -> Hardware Detection tab of the Elastix interface. Currently, we only see a Sangoma B600D (4 FXO, 1 FXS) card detected but no signs of the channel bank. See below.

We know have to click on the "Detect New Hardware" button.

The following is the result:

As you can see, we now have detected all 24 FXS ports of the channel bank. In fact, we have detected 30 ports! Notice that three port modules (8 FXS ports each) are detected. However, the first one has 2 extra "Output" ports and 4 extra "Input" ports. These ports are used to activate door openers or to trigger alarms through the channel bank. We will take a look at these ports in a future How-To.

We are now ready to create extensions for the channel bank's ports and test it out.

CONFIGURING EXTENSIONS

We now head over to the PBX -> PBX Configuration tab of the Elastix interface. You will notice from the picture below that we have a few extensions created. Extension 218 is a SIP extension registered to our Elastix system. We will proceed and create a new extension called 217 that corresponds to an analog phone connected to the first FXS port of our channel bank.

In order to do this, click on "Add Extension" and select "Generic ZAP Device" as your Device.

Make sure to fill the "User Extension" and "Display Name". The most important part is to fill in the "channel" number under "Device Options".

We will enter "25" for the first FXS port in the channel bank (See output of the Hardware Detection above for the right port number) in the "channel" field. We have connected our analog phone into this port.

Make sure you do an "asterisk -rx reload" on your console in order to continue.

Per the picture below you see that once you connect the analog phone, the channel bank port will light up red.

TESTING

All we have left to do is to try out calling between our extensions (we don't have a trunk connected so we will limit ourselves to making calls between extensions). Pick up the analog phone (you will see a green light go off on the channel bank port) and you will hear a dial tone. Then, dial 218 and the suitable extension should ring and complete the call. You can also try dialing from 218 to the analog extension 217 with the same results.

If you do not hear a dial tone please make sure you first have your channel bank ports show up as the following picture when doing a "lsdahdi" command.

# lsdahdi

If the ports say something such as RED or NOTOPEN, something is wrong with dahdi. Do an "asterisk -rx reload".

And yes, it's that easy!

If you have trouble, your first check should be if you are using Elastix 1.6-12 or above.

Configuring a Redfone Fonebridge2 with Elastix (Part 1)

Jose L Landivar — Fri, 20 Nov 2009 01:43:00 GMT

In this two-part article you will find everything you need to know in order to configure your Redfone Fonebridge2 with Elastix 1.5.2-2. Part 1 goes through setting up a single Elastix appliance (or server) with a Redfone Fonebridge2 as an external T1/E1 interface. Part 2 explains how to implement high availability with the Redfone Fonebridge2 and a secondary (backup) Elastix appliance (or server). After going through both parts of this article you will be able to setup a high availability environment on your own. In this way, if one Elastix server or appliance were to fail, the calls will still flow to a backup Elastix server or appliance.

SCHEMATIC DIAGRAM

Our objective in Part 1 of this article is to setup an Elastix appliance or server with a Fonebridge2 device. The following is the diagram of the solution that we are looking to accomplish.

That is, a call originates from extension 509 in the Elastix appliance. The call then gets routed to the Fonebridge2 device and out of span 1. Afterwards, the call gets received through span 2 of the same Fonebridge2 and back into the appliance. Once the call is back in the Elastix appliance, it should terminate by ringing extension 503.

EQUIPMENT REQUIRED

For the purposes of this article, we will be using the following devices:

1) One (1) Redfone Fonebridge2 Dual Port T1/E1

2) Two (2) Elastix Appliances ELX-025 loaded with Elastix 1.5.2-2 Stable, with two (2) network interfaces each:

In Part 1 of this article we will only use one (1) Elastix appliance. In Part 2 we will use both Elastix appliances in order to setup a high availability environment.

CONNECTING THE DEVICES

For the purposes of this article we will use a single Redfone Fonebridge2 to act as both the Telco T1/E1 provider and also as the receiver T1/E1 device. We do this for lab testing since it does not require an actual T1/E1 trunk from the Telco. In order to do this, we will create a loopback between the two ports (labeled T1/E1 1 and 2) of the Fonebridge2 (one to simulate the T1/E1 from the Telco and the other to receive the calls from the simulated T1/E1). The cable used for this loopback needs to be crossover. A pin-out diagram for the cable is provided below for your reference.

Now we need to connect the Redfone Fonebridge2 to our Elastix appliance. For this, we connect the port on the Fonebridge2 labeled "Ethernet FB1" to the second network interface of the Elastix appliance (Ethernet 1). Please remember that the first network interface of the Elastix appliance, Ethernet 0, is reserved for connecting the appliance to the network (and IP phones). Here is a picture of how the setup will look so far including the loopback connection. The picture does not show the connectivity of the appliance to the network through Ethernet 0.

The Fonebridge2 comes with two (2) Ethernet interfaces. "Ethernet FB1" is preconfigured with as 192.168.1.254/24, and "Ethernet FB2" is preconfigured as 192.168.1.253/24. Due to this, we will configure the second network interface (Ethernet 1) in the Elastix appliance as 192.168.1.200/24 (We use 200 here, but you could choose any unused IP address in the range).

COMMUNICATING WITH THE FONEBRIDGE2

If you are using an Elastix appliance everything should be ready for you to start configuring (make sure you have a secondary network card). If you are using a server of your own, please make sure to have Elastix 1.5.2-2 Stable installed properly with two network interfaces. The actual installation of Elastix is outside the scope of this document. For more information on this please visit www.elastix.org

1) We now need to install the "fonulator" utility provided by Redfone. For this, we issue the following command:

[root@elastix~]# rpm -ivh http://support.red-fone.com/downloads/fonulator/fonulator-2.0.0-36.i386.rpm

Please confirm that the "fonulator" was installed successfully by issuing the following command:

[root@elastix~]# fonulator -V

2) We need to download and configure a sample redfone.conf file as follows.

[root@elastix~]# cd /etc/
[root@elastix etc]# wget http://support.red-fone.com/downloads/fonulator/redfone.conf

Using your preferred text editor you need to modify the redfone.conf sample file according to your needs. Here is what we have for our redfone.conf configuration.

Please note in this file that we are using the directive "fb=192.168.1.254" because we are using a single Elastix appliance. In Part 2 of this article, when we setup high availability with (2) two Elastix appliances, we will use the "FB1=" and "FB2=" directives instead.

3) Download the "fonulator script" as follows.

[root@elastix etc]# cd init.d/
[root@elastix init.d]# wget http://support.red-fone.com/downloads/fonulator/old/fonulator_initd_script
[root@elastix init.d]# mv fonulator_initd_script fonulator
[root@elastix init.d]# chmod +x fonulator

4) Now we need to download the "dahdi init script" for use with the Fonebridge2.

[root@elastix init.d]# mv dahdi /opt/dahdi.old
[root@elastix init.d]# wget http://support.red-fone.com/downloads/elastix/dahdi
[root@elastix init.d]# chmod 755 dahdi

Here we need to modify the shutdown sequence for some services to prevent a current bug. If the network services are shutdown before dahdi, you will see a kernel panic. This will happen during Elastix shutdown or restart. In order to avoid this issue, you need to modify the sequence by issuing the commands below. Surely this bug will go away in future versions and you won't have to do this any longer.

[root@elastix init.d]# cd /etc/rc0.d/
[root@elastix rc0.d]# mv K92dahdi K90dahdi
[root@elastix rc0.d]# mv K90network K92network
[root@elastix rc0.d]# cd ../rc6.d/
[root@elastix rc6.d]# mv K92dahdi K90dahdi
[root@elastix rc6.d]# mv K90network K92network

5) At this point, we need to test the communication between our Elastix appliance and the Fonebridge2 by using the "fonulator".

[root@elastix rc6.d]# fonulator -vq

CONFIGURING DAHDI AND ELASTIX/ASTERISK

At this point we need to configure the Elastix appliance (or server) to use the external Redfone Fonebridge2 to communicate telephonically with the outside world.

1) Let's start by editing the system.conf file for dahdi. Feel free to use the text editor of your choice. We will be using the "vim" editor. The configuration depicted below is used for an E1 trunk. If you will be configuring a T1, this file will need to change accordingly. Basically, this file is telling dahdi to target the external Fonebridge2's IP address using the ethmf technology to connect calls.

Please note that the provided above is only a sample file for our setup.

2) Next we must tell dahdi how to treat the T1/E1 spans in the Fonebridge2. We do this by modifying (or creating if it does not exist yet) the dahdi-channels file. The following picture shows our sample configuration. Please keep in mind that we are defining this for an E1. If you are using a T1 you'll need to modify it accordingly. Also note that the group 1 (corresponding to span 1 of the Fonebridge2) will be configured as CPE and group 2 (corresponding to span 2 of the Fonebridge2) will be configured to emulate an E1 from the Telco. Remember we are doing a loopback on the Fonebridge2. Again, we will be using "vim" as our text editor but feel free to use whatever you are comfortable with.

[root@elastix dahdi]# vim ../asterisk/dahdi-channels.conf

Please make sure to set the permissions and ownership correctly:

[root@elastix dahdi]# chmod 664 /etc/asterisk/dahdi-channels.conf
[root@elastix dahdi]# chown asterisk:asterisk /etc/asterisk/dahdi-channels.conf

3) We must now restart Asterisk for the changes to the configuration files to take effect. We perform this by issuing the following commands:

[root@elastix dahdi]# amportal stop
[root@elastix dahdi]# service asterisk stop
[root@elastix dahdi]# amportal start

4) Finally, we need to make sure that all channels in the Fonebridge2 have been configured correctly. We verify the channels as follows.

[root@elastix dahdi]# lsdahdi

If we have done everything correctly up to now, we will notice that the LEDs on the Fonebridge2 are now lit up signaling the correct configuration of our devices.

TESTING THE ELASTIX / FONEBRIDGE2 SETUP

In this section we will make sure that all of our work has been effective by making calls according to our initial schematic diagram.

1) First, we create the two (2) SIP extensions that we'll need. In this case extension 503 belonging to "Jorge" and extension 509 belonging to "Mauro" are created:

We can verify that both extensions have been created properly by using the CLI functionality from the Elastix interface:

2) Now we must define the g1 trunk since we are using a group 1 in our dahdi-channels.conf file earlier in this article. We do this by creating a group within Elastix as follows:

3) Now we need to add an outgoing route and assign group 1 (g1) to it. This will basically tell Elastix to send all calls out through the g1 trunk (associated to span 1 of the Fonebridge2).

4) In the same manner we must tell Elastix to be ready to receive calls. We do this by creating an incoming route. In our case, we will send all received calls to extension 503.

5) We can finally proceed to make a call from extension 509 to extension 503. We do this by dialing 1503 (remember that we set our outgoing route to respond to "1|XXX". The result should be that a call is connected from extension 509 to extension 503. You can verify that it all went well by looking at the console report shown below.

If you have reached this point successfully, congratulations! You are now ready to implement a high availability environment with Elastix and the Redfone Fonebridge2 in Part 2 of this article.

Alfredo Zambrano

Configuring a Redfone Fonebridge2 with Elastix (Part 2)

Jose L Landivar — Fri, 20 Nov 2009 01:40:00 GMT

This is part 2 of the two-part article on configuring Elastix with Redfone Fonebridge2 devices. In this part, we will cover all the details of setting up a robust high availability cluster with Elastix and a T1/E1 interface. At the end of this article, you will be able to implement high availability in any environment so if either server were to fail for any reason, the other will take all future calls.

SCHEMATIC DIAGRAM

Our objective for this article is to assemble a cluster of two (2) Elastix servers with a Redfone Fonebridge2 device. The following is the diagram of the solution that we are trying to accomplish.

Basically, the call originates in extension 509 in the Elastix cluster (actually registered with the primary Elastix appliance) and then gets routed to the Fonebridge2 device and out the span 1. The call then loopsback from span 1 to span 2 of the Fonebridge2. After this, the call is received by the primary Elastix appliance and terminated on extension 503. The secondary Elastix appliance does not intervene up until this point. When we unplug the primary Elastix appliance from the network, we can try the call again and the call path is exactly the same but it's routed through the cluster by the secondary Elastix appliance (which would actually now be the primary). In either case, the call should complete without problems demonstrating the reliability of this environment.

EQUIPMENT REQUIRED

For the purposes of this article, we will be making use of the following equipment:

1) One (1) Redfone Fonebridge2 Dual Port T1/E1:

2) Two (2) Elastix Appliances ELX-3000 loaded with Elastix 1.5.2-2 Stable, with two (2) network interfaces each:

Please ensure to connect the devices according to the diagram above before continuing. You could review the "CONNECTING THE DEVICES" section of Part 1 for more information here.

INSTALLING AND PREPARING ELASTIX

If you purchased an Elastix appliance there is no need to reinstall your Elastix software since a portion of your hard drive has already been reserved for use with high availability applications. If you are setting up an Elastix server of your own please install Elastix ON BOTH SERVERS according to the following specifications.

1. Boot Elastix from Installation CD.

2. In Boot menu, select 'advanced' and press<Enter>.

3. Partition the disk space manually based on the following example of a 120GB hard drive:

root (/), ext3, 60% of total hard disk capacity (sda1)
SWAP, twice the size of available RAM
Boot (/boot) 100 MB
Free unformatted space, fill remaining space

4. All other choices are standard installation options so just follow on-screen instructions.

5. After installation is finished, please log into the system and update any new packages from the Elastix repository. We do this by executing the following command:

[root@artemisa ~]# yum –y update

6. Check the /etc/grub/grub.conf file and ensure that the first kernel scheduled to boot is not the Xen kernel which could cause problems.

NOTE: At some point during installation or soon after, please set the IP address and hostname for each server. In our example we have assigned 192.168.50.14 to the primary server with hostname "artemisa.elastixdepot.com" and 192.168.50.15 to the secondary server with hostname "apolo.elastixdepot.com".

Now that you have both Elastix servers installed, we can proceed to set up the DRDB service to replicate and keep both servers synchronized.

DRDB AND HEARTBEAT PREPARATIONS

Whether you are using Elastix appliances or you installed your own Elastix server you will need to create a new partition in the unused space that you left in your hard drive. This must be done on both servers.

1. Create a partition that will contain the data to be replicated between both servers as follows:

[root@artemisa ~]# fdisk /dev/hda

Command to add a new partition (n)
Primary (p)
Partition number (4)

IMPORTANT NOTE: If the two servers have hard drives of different sizes, it is imperative that the size of the replication partition is identical in both servers, otherwise, they will never be able to synchronize over DRBD. Due to this requirement, please select the desired size of the partition exactly the same in the continuing options of the fdisk command. In our case, we chose 3GB (3072M).

First cylinder (<enter> to choose default)
Last cylinder (+3072M)
Command to select a partition (t)
Choose the correct partition (4)
Select type of the partition (83)
Command to save all changes (w)
Reboot both servers

Verify that the partition was created correctly with the "fdisk -l" command.

2. Format the newly created partition (in our case with the "mke2fs -j /dev/hda4" command).

3. Now, you must erase some file system structure information from the partition that we just created in the previous step. If we don't do this, this file system structure information will also be replicated between the servers and may cause problems.

4. Install DRBD, HEARTBEAT and all dependencies with yum.

[root@artemisa ~]# rpm -ivh vault.centos.org/5.2/extras/i386/RPMS/drbd82-8.2.6-1.el5.centos.i386.rpm
[root@artemisa ~]# yum install kmod-drbd82

[root@artemisa ~]# yum install heartbeat

[root@artemisa ~]# yum install OpenIPMI-libs openhpi heartbeat-libs heartbeat-stonith

5. Make sure that hostnames are correctly configured for IP resolution in the file (/etc/hosts) IN BOTH SERVERS. The /etc/hosts files in both servers should contain the same entries. Please note that the IP address for the primary server (artemisa) is 192.168.50.14 and for the secondary server (apolo) is 192.168.50.15. As you will see later, the cluster will share a floating IP address of 192.168.50.16.

CONFIGURING DRDB

1. DRBD allows us to write in the partition declared in both cluster members, in our case /dev/hda4. We must create a virtual partition called /dev/drdb0 IN BOTH SERVERS. Why?

2. Edit /etc/drbd.conf IN BOTH SERVERS. The file drbd.conf must be identical in both servers. Modify this sample file according to your particular requirements:

3. Before continuing, change the name for the Elastix server from web interface. Why? Delete?

4. Now, we create the metadata for /dev/drdb0 in the two servers. This is a required step to setup the environment for DRDB. We do this with the following command:

[root@artemisa ~]# drbdadm create-md r0

5. Start DRDB services IN BOTH SERVERS to initiate sync process.

[root@artemisa ~]# service drbd start

6. Verify that the synchronization process is ready with the following command:

[root@artemisa ~]# service drbd status

7. Initially, both servers will be secondary (as seen in the previous screen as "Secondary/Secondary"). We need to further designate which one will be the primary server.

Run the following command IN THE PRIMARY SERVER ONLY:

[root@artemisa ~]# drbdsetup /dev/drbd0 primary -o

And this command IN THE SECONDARY SERVER ONLY:

[root@artemisa ~]# drbdadm secondary r0

8. Check DRDB status again with the command "service drbd status". The result of this command should be similar to the one below for the primary server.

And the following for the secondary server.

9. We can determine a server's role by executing this command ON BOTH SERVERS:

[root@artemisa ~]# drbdadm state r0

The primary server should reply something like this:

The secondary server should reply something like this:

10. We will mount the virtual partition /dev/drbd0 as "/replica" in the primary server, move the contents of relevant files to the /replica directory and the create symbolic links in the main file system to the new location of the relevant files as follows. In the secondary server we will create symbolic links in the same fashion and remove the contents of the relevant files as they will be replicated into the /replica directory by DRDB and the directory mounted by HEARTBEAT when the secondary server is awakened.

The relevant files are located in:

/etc/asterisk
/var/lib/asterisk
/usr/lib/asterisk
/var/spool/asterisk
/var/lib/mysql
/var/log/asterisk
/var/www

Perform the following command ON BOTH SERVERS:

[root@artemisa ~]# mkdir /replica

Perform the following commands IN THE PRIMARY SERVER ONLY.

[root@artemisa ~]# mount /dev/drbd0 /replica

[root@artemisa ~]# cd /replica
[root@artemisa replica]# tar -zcvf etc-asterisk.tgz /etc/asterisk
[root@artemisa replica]# tar -zxvf etc-asterisk.tgz
[root@artemisa replica]# tar -zcvf var-lib-asterisk.tgz /var/lib/asterisk
[root@artemisa replica]# tar -zxvf var-lib-asterisk.tgz
[root@artemisa replica]# tar -zcvf usr-lib-asterisk.tgz /usr/lib/asterisk/
[root@artemisa replica]# tar -zxvf usr-lib-asterisk.tgz
[root@artemisa replica]# tar -zcvf var-spool-asterisk.tgz /var/spool/asterisk/
[root@artemisa replica]# tar -zxvf var-spool-asterisk.tgz
[root@artemisa replica]# tar -zcvf var-lib-mysql.tgz /var/lib/mysql/
[root@artemisa replica]# tar -zxvf var-lib-mysql.tgz
[root@artemisa replica]# tar -zcvf var-log-asterisk.tgz /var/log/asterisk/
[root@artemisa replica]# tar -zxvf var-log-asterisk.tgz
[root@artemisa replica]# tar -zcvf var-www.tgz /var/www/
[root@artemisa replica]# tar -zxvf var-www.tgz

Perform the following commands ON BOTH SERVERS:

[root@artemisa replica]# rm -rf /etc/asterisk
[root@artemisa replica]# rm -rf /var/lib/asterisk
[root@artemisa replica]# rm -rf /usr/lib/asterisk/
[root@artemisa replica]# rm -rf /var/spool/asterisk
[root@artemisa replica]# rm -rf /var/lib/mysql/
[root@artemisa replica]# rm -rf /var/log/asterisk/
[root@artemisa replica]# ln -s /replica/etc/asterisk/ /etc/asterisk
[root@artemisa replica]# ln -s /replica/var/lib/asterisk/ /var/lib/asterisk
[root@artemisa replica]# ln -s /replica/usr/lib/asterisk/ /usr/lib/asterisk
[root@artemisa replica]# ln -s /replica/var/spool/asterisk/ /var/spool/asterisk
[root@artemisa replica]# ln -s /replica/var/lib/mysql/ /var/lib/mysql
[root@artemisa replica]# ln -s /replica/var/log/asterisk/ /var/log/asterisk
[root@artemisa replica]# ln -s /replica/var/www /var/www

11. Finally, we must restart mysql ON BOTH SERVERS:

[root@artemisa replica]# service mysqld restart

CONFIGURING HEARTBEAT

We will be making use of the HEARTBEAT service to awaken the secondary service in the case it's detected that the primary server has stopped responding. Both servers must have HEARTBEAT enabled. Please follow the following steps.

1. Remember to stop all services that will be controlled by heartbeat IN BOTH SERVERS (and make sure that they don't start during boot time). These services will be managed by HEARTBEAT on the server that is in control in that moment. You can accomplish all this with the following commands:

[root@artemisa ~]# chkconfig asterisk off
[root@artemisa ~]# chkconfig mysqld off
[root@artemisa ~]# chkconfig httpd off

2. Edit file/etc/ha.d/ha.cf. This is a basic configuration of the file that provides all the functionalities we require. Please make sure both servers have the same exact contents in this file. In the following picture we show the contents in the primary server only.

3. Edit /etc/ha.d/haresources. In this file we will specify which is our primary server initially, which partition will be mounted when the server is brought up as primary, our floating IP (192.168.50.16 in this example), network interface (eth2 in this example) and the init scripts from init.d that will be awakened in case of a server failure (fonulator,asterisk, mysqld y httpd). Please note that the order of this list is important. Also note in the pictures below that /etc/ha.d/haresources on both servers contain the primary server name (artemisa.elastixdepot.com); in fact, both files are exactly the same.

NOTE: Ensure that all the parameters are specified in a single line in this file.

4. Edit /etc/ha.d/authkeys and change the key to one of your preference. Please make sure that both servers contain the same key. This provides security and authentication capabilities between nodes.

5. Change permissions to file/etc/ha.d/authkeys.

[root@artemisa ~]# chmod 600 /etc/ha.d/authkeys

6. Configure HEARTBEAT to initiate at server boot time.

[root@artemisa ~]# chkconfig --add heartbeat

7. Unmount /replica IN THE PRIMARY SERVER ONLY. We do this because we are going to restart HEARTBEAT and it will automatically mount /replica when it comes up.

[root@artemisa ~]# umount /replica

8. Restart DRDB IN BOTH SERVERS.

[root@artemisa ~]# service drbd restart

9. Verify that BOTH SERVERS are secondary initially.

[root@artemisa ~]# drbdadm state r0

The result should be ‘Secondary/Secondary’ in both servers.

10. Restart heartbeat ON BOTH SERVERS.

[root@artemisa ~]# service heartbeat restart

11. Wait about a minute and recheck the server status ON BOTH SERVERS.

[root@artemisa ~]# drbdadm state r0

This time, the result should be ‘Primary/Secondary’ on primary server and 'Secondary/Secondary' in the secondary server.

12. Execute ‘df –h’ ON THE PRIMARY SERVER and confirm that the /dev/drbd0 partition is mounted and in use.

[root@artemisa ~]# df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 5.9G 1.9G 3.8G33% /
tmpfs 1.5G 0 1.5G 0%/dev/shm
/dev/drbd0 138G 305M 131G1% /replica

13. You can monitor the synchronization process with following command:

[root@artemisa ~]# cat /proc/drbd

INSTALLING THE FONEBRIDGE

We must now install the actual Redfone Fonebridge2 device. You may find more detailed instructions on how to do this in Part 1 of this article here. Please follow the following steps ON BOTH SERVERS:

1. Install the fonulator utility from the online repository.

[root@artemisa ~]# rpm -ivh support.red-fone.com/downloads/fonulator/fonulator-2.0.0-36.i386.rpm

2. Download a demo redfone.conf from the online repository.

[root@artemisa ~]# cd /etc/
[root@artemisa etc]# wget support.red-fone.com/downloads/fonulator/redfone.conf

3. Edit redfone.conf to meet your needs. Please see Part 1 for more information on this here.

4. Download the fonulator initd script from the online repository.

[root@artemisa etc]# cd /etc/init.d
[root@artemisa init.d]# wget support.red-fone.com/downloads/fonulator/old/fonulator_initd_script
[root@artemisa init.d]# mv fonulator_initd_script fonulator
[root@artemisa init.d]# chmod +x fonulator

5. Reboot BOTH SERVERS and confirm proper functionality in both. Under regular conditions, your primary server must boot, mount the DRDB partition and initiate the scripts specified in /etc/ha.d/haresources. The secondary server must boot, NOT mount the DRDB partition and NOT initiate the scripts specified in /etc/ha.d/haresources. Why? Any particular order of booting?

6. Verify that the DRDB partition is mounted IN THE PRIMARY SERVER by executing ‘df –h’. It should show something similar to:

[root@artemisa init.d]# df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 5.9G 1.8G 3.8G32% /
tmpfs 125M 0 125M 0%/dev/shm
/dev/drbd0 5.7G 409M 5.0G8% /replica

7. It is recommended that you use the dahdi init script provided by Redfone due to some earlier issues with the default. We will backup the default dahdi script and then download the one from Redfone. Please do the following ON BOTH SERVERS.

[root@artemisa init.d]# mv /etc/init.d/dahdi ~/dahdi.backup
[root@artemisa init.d]# wget support.red-fone.com/downloads/elastix/dahdi
[root@artemisa init.d]# chmod 755 /etc/init.d/dahdi

8. Sometimes we run into problems with an erroneous detection of another Asterisk instance running. To prevent this, we'll implement a work-around by changing the exit value of the 'exit' from 1 to 0 in the /etc/init.d/asterisk file ON BOTH SERVERS. Please see the before and after pictures below.

[root@artemisa ~]# vim /etc/init.d/asterisk

9. In this version of Elastix (1.5.2-2 Stable) there is an issue with a kernel panic occurring when we shutdown the network service before dahdi. Therefore, we must change the order for shutting down these services as follows:

[root@artemisa ~]# cd /etc/rc0.d/
[root@artemisa rc0.d]# mv K92dahdi K90dahdi
[root@artemisa rc0.d]# mv K90network K92network
[root@artemisa rc0.d]# cd ../rc6.d/
[root@artemisa rc0.d]# mv K92dahdi K90dahdi
[root@artemisa rc0.d]# mv K90network Kk92network

Congratulations! You have successfully finished setting up your high availability environment. Now we must make sure it's working well.

TESTING OUR HIGH AVAILABILITY CLUSTER

After having performed all configurations properly and made the connections properly you should have something similar to this:

Now we need to make sure all this hard work will pay off. We should be able to define our extensions 503 and 509 (please see Diagram at the top of this article) in our high availability cluster. In order to do this, we need to direct our browser to the floating IP we defined for the cluster. In our case this would be 192.168.50.16. This request from your browser is actually being handled by the primary server unless it were to fail. In case of failure of the primary server, the secondary server will respond any request to 192.168.50.16.

In either case we will be presented with an Elastix GUI where we can specify the required extensions. Please refer to Part 1 of this article (TESTING THE ELASTIX / FONEBRIDGE2 SETUP section) for more information and screenshots of how to do this here. After the extensions are setup, we can initiate a call from extension 509 and dial 1503 (we defined an outgoing route of '1|XXX' in Part 1 of this article). The call should be completed and the phone in extension 503 should ring.

In order to test our high availability setup you must now unplug the primary server's ethernet cable from the switch (to simulate a failure of this server). After a couple of minutes try making the same call from 509 to 1503. The call should complete without any problems although the call is now being routed through the secondary server.

Voila! There you have it. You have just completed your very own high availability clustered PBX with Elastix and Redfone.

Alfredo Zambrano