We were recently hired to customize the core A2Billing project to meet some custom business rules and they wanted to use the A2Billing Restful API to integrate A2Billing with other systems in their environment.  There are a lot of blog posts on how to install and configure the core A2Billing project, but very little info on the Restful API.  Therefore, I will explain how to configure it with the assumption that A2Billing is already installed and configured.  I will use CentOS 7 to demonstrate how to set it up.   If you need help you can hire us by purchasing support time.

Assumptions:

• CentOS  6 or 7 is being used
• A2Billing version 2.2.0 is already installed and working

Architecture and Background

The A2Billing Restful API is developed by Star2Billing, the same company that develops A2Billing.   It’s built using Python and Flask.  Flask has a number of components, but the main components used is the RESTful request dispatching.  The bits are located on GitHub at https://github.com/areski/a2billing-flask-api.  The install script is only supported on Debian, but most of our customers use A2Billing with the FreePBX on CentOS.  Therefore, we will focus on installing it on CentOS.

Installation Steps

Download the bits from github

cd /usr/src
git clone https://github.com/areski/a2billing-flask-api
cd a2billing-flask-api

Install the required libraries

There are a number of Python libraries needed.  The included makefile contains the commands to install the libraries.  The list of libraries can be found in a file called “requirements.txt” if are really interested in what libraries are being used. Execute make to install.

If running Python < 2.7.9

wget https://bootstrap.pypa.io/get-pip.py 
python get-pip.py
pip install -r requirements.txt
pip install virtualenv
make

Modify the Activation Script

Change path on the activate_this and sys.path lines to reflect the actual location of the a2billing-flask-api

vi a2billing-flash-api/a2billing-flask-app.wsgi

import os
import sys
activate_this = '/usr/src/a2billing-flask-api/a2billing_flask_api_env/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))
apache_configuration= os.path.dirname(__file__)
project = os.path.dirname(apache_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace)

sys.path.insert(0, '/usr/src/a2billing-flask-api/a2billing_flask_api/lib/python2.6/site-packages')
sys.path.insert(1, '/usr/src/a2billing-flask-api/a2billing_flask_api/lib/python2.7/site-packages')
sys.path.append('/usr/share')
sys.path.append('/usr/src/a2billing-flask-api/a2billing_flask_api')

# os.environ['DJANGO_SETTINGS_MODULE'] = 'newfies_dialer.settings'
# import django.core.handlers.wsgi
# application = django.core.handlers.wsgi.WSGIHandler()

from a2billing_flask_api import app as application

Installed the WSGI Plugin for Apache

The A2Billing Flask API depends on Flask API (surprise).  In order to get Flask to execute within your Apache server you need the WSGI Plugin

yum install mod_wsgi

For Apache 2.2

Listen 9090
WSGISocketPrefix /var/run/wsgi
<VirtualHost *:9090>
ServerName api-a2billing.dopensource.com

WSGIDaemonProcess a2billing_flask_app user=asterisk group=asterisk threads=5
WSGIScriptAlias / /usr/src/a2billing-flask-api/a2billing_flask_api/a2billing_flask_app.wsgi
WSGIPassAuthorization On

<Directory /usr/src/a2billing-flask-api>
WSGIProcessGroup a2billing_flask_app
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
ErrorLog "/var/log/httpd/a2billing-flask.log"
</VirtualHost>

For Apache 2.4

Listen 9090
WSGISocketPrefix /var/run/wsgi
<VirtualHost *:9090>
ServerName api-a2billing.dopensource.com

WSGIDaemonProcess a2billing_flask_app user=asterisk group=asterisk threads=5
WSGIScriptAlias / /usr/src/a2billing-flask-api/a2billing_flask_api/a2billing_flask_app.wsgi
WSGIPassAuthorization On

<Directory /usr/src/a2billing-flask-api>
WSGIProcessGroup a2billing_flask_app
WSGIApplicationGroup %{GLOBAL}
# Order deny,allow
# Allow from all
<strong>Require all granted</strong>
</Directory>
ErrorLog "/var/log/httpd/a2billing-flask.log"
</VirtualHost>

Setup the database configuration parameters.

The database configuration information is located in a file called config.py.

vi a2billing_flask_api/config.py

change the name (database name), user and passwd parameters based on your A2Billing Installation

DATABASE = {
'name': 'mya2billing',
'engine': 'peewee.MySQLDatabase',
'user': 'a2billinguser',
'passwd': 'a2billing',
}

Start Web Server and Test

service httpd restart

Test it locally:

curl -u admin:admin http://localhost:9090/api/callerid/

Test it from a Remote System:

curl -u admin:admin http://<external ip>:9090/api/callerid/

You should get a list of calling card id’s

If you have any problems look in /var/log/httpd/a2billing-flask.log

Let me know if you have issues with these instructions and I will fix them.

 

Series Intro

This series of articles will give you the information you need to standup a cluster of Asterisk servers using Docker containers, which we categorize as media servers where traffic will be load balanced by Kamailio.

Part I Intro

In this article we will configure the plumbing of the cluster and deploy a couple of Asterisk containers (media servers). At the end of this article you will understand how to setup a basic Docker cluster that can automatically discover and auto register Asterisk servers to the cluster.

Bootstrapping the Cluster

Let’s start by setting up the main components of the cluster. We will use Consul, which was developed by HashiCorp to provide the plumping for our cluster. This plumbing includes Service Discovery, DNS, Event notification and other services that we may discuss later on in this series. The documentation for Consul can be found at <https://www.consul.io/docs/index.html>

The prerequisite is to have docker installed

We can start the cluster by running:

docker run -d -p 0.0.0.0:8400:8400 -p 0.0.0.0:8500:8500 -p 0.0.0.0:8600:8600/udp --volume=/var/run/docker.sock:/tmp/docker.sock --name consul -h voiphost1 docker.io/consul agent -ui -server -bootstrap-expect 1 -client 0.0.0.0

The above command will start the cluster and make the Consul web interface available on the host machine via port 8500 and make a DNS interface available to us on port 8600. Below is a screenshot of the Consul web interface after running the above command.

Now we need to have a mechanism to automatically register Asterisk servers with the cluster and specify the SIP ports that the server is listening on. For example, we might want to spin up 3 Asterisk servers to handle the load. We need to have a way to tell the cluster the IP address and the Asterisk SIP port number of these servers without having to manually configure the cluster. This is done using Registrator, which was developed by GliderLabs.

You can start Registrator by by running:

docker run -d -v /var/run/docker.sock:/tmp/docker.sock --privileged gliderlabs/registrator:latest consul://10.10.10.183:8500

The above command will start the Registrator container and listen for Docker events using the Unix socket (/var/run/docker.sock). This port acts as a control port for Docker. We will dig deeper into this socket in upcoming articles. All we need to understand right now is that start/stop events is sent via this socket each time a Docker container is started or stopped. We use the volume option (-v) to make the socket available to the Registrator container on /tmp/docker.sock. The last parameter specifies the registry that events should be sent to. In our case, we are using consul as the registry, but Registrator is designed to use other registries. The ip of our registry is the exposed ip address of the Consul server that we started earlier in the article. Here a picture of what Consul looks like after starting the Registrator container

Now we need to registrator a coupe of media server, which can be done using:

docker run -d -p 35061:5060 -e "SERVICE_NAME=mediaserver" docker.io/cleardevice/docker-cert-asterisk13-ubuntu

docker run -d -p 35062:5060 -e "SERVICE_NAME=mediaserver" docker.io/cleardevice/docker-cert-asterisk13-ubuntu

The above commands will start two (2) Asterisk servers with a service name of “mediaserver”. In this example we had to specify the exposed port numbers, but this will typically be done randomly and automatically so that we don’t have to keep track of which port numbers are already in use versus what’s available. We will release our own asterisk server containers for these articles that will handle this for us – we will update the article once that is complete.

Here’s a picture of what Consul looks like now:

In Part II we will discuss how to deploy a SIP Proxy service ran by Kamailio that will automatically know how to route SIP traffic to Asterisk containers that are available on the cluster.

We have made a decision to jump head first into containers with a focus on providing Enterprise Grade Docker and Kubernetes Support.  It’s only right to convert our infrastructure into containers.  We are going to start with our bread and butter, which is our phone system.  Being a support company with a strong focus on helping companies deploy VoIP means that this is huge risk for us – we have to get this right or we will literally lose money.  But, if you never jump you will not soar.  In other words, if we are going to provide support for Docker, Kubernetes and in general Microservices we need to go through the process ourselves so that we can help others navigate the waters.

Current Environment

We currently use the FreePBX distribution as our PBX and Flowroute as our carrier (we love Flowroute by  the way).  We only use an handful of the options in FreePBX.  To be precise, we use:

• IVR
• Extension Management
• Voicemail
• Follow-me
• Queues
• Ring Groups
• Conferences

If you think about it…each one of these features could become a container, but does that really make sense….not really sure yet.

Project Goals

We have decided to break this project into phases and we will make each new phase better by incorporating what we learned from the previous phases.

Phase I – Create a conference container and have all conference traffic be routed to 1 or more containers that just handles conferencing.  There are times when we had multiple conferences happening all at the same time, which causes performance issues.  We want a solution that would realize that the existing conference server has too many requests and it automatically spins up another conference server and start routing requests to the newly created instance.

More phases to come…

Proposed Components

• Kamailio – to provide load balancing and routing of calls to one or more Asterisk servers
• Asterisk – Media server
• Docker
• Consul – Will keep track of all Asterisk servers that are up and available

We will also need a Web GUI for managing the conferences and the other features that we need.  FreePBX is not container aware, so we are toying with the idea of developing a simple Web GUI that knows how to deal with functionality being containerized.

Kamailio 4.4 on CentOS 6.

Are you looking for the CentOS 7.x version?  It can be found here

Setup YUM Repository

1. Install wget so we can pull down the rpm.

yum install wget

1. Let’s download the yum repo file for our Cent OS version.

cd /etc/yum.repos.d/
wget http://download.opensuse.org/repositories/home:/kamailio:/v4.4.x-rpms/CentOS_6/home:kamailio:v4.4.x-rpms.repo

1. Update system so yum is aware of the new repository.

yum update

1. You can look at the kamailio packages in the YUM repository by typing:

yum search kam

Install Kamailio and Required Database Modules

1. Install the following packages from the new repo.

yum install -y kamailio kamailio-mysql kamailio-debuginfo kamailio-unixodbc kamailio-utils gdb

1. Set kamailio to start at boot.

chkconfig kamailio on

1. The Kamailio configuration files will be owned by the root user, rather than the kamailio user created by the Kamailio package. We will need to change the ownership of these files.

chown kamailio:kamailio /etc/default/kamailio
chown -R kamailio:kamailio /etc/kamailio/
chown -R kamailio:kamailio /var/run/kamailio

Install MySQL

1. Since we plan on using MySQL, we will need to instal the MySQL server as well as the client.

yum install -y mysql-server mysql

1. Next we need to start up MySQL:

service mysqld start

1. And enable mysqld at boot.

chkconfig mysqld on

1. Now we can set a root password for mysql:

You can hit yes to all the options. There is no root password as of yet, so the first question will be blank. Be sure to use a secure unique password for your root user.

[root@localhost yum.repos.d]# sudo /usr/bin/mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MySQL to secure it, we'll need the current
password for the root user. If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

Set root password? [Y/n]
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n]
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n]
... Success!

By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n]
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n]
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

Configure Kamailio to use MySQL

• By default, Kamailio does not use MySQL. To change this we need to edit one of Kamailio’s configuration files.

vi /etc/kamailio/kamctlrc

1. Uncomment the DBENGINE parameter by removing the pound symbol and make sure the value equals MYSQL. The parameter should look like this afterwards:

DBENGINE=MYSQL

1. To have the kamdbctl command create the mysql database with the correct permissions, we will want to set the databaseusers and passwords in kamctlrc

## database read/write user
DBRWUSER="kamailio"

## password for database read/write user
DBRWPW="kamailiorw"

## database read only user
DBROUSER="kamailioro"

## password for database read only user
DBROPW="kamailioro"

Create the Kamailio Database Schema

• The Command will create all the users and tables needed by Kamailio. You will be prompted to put in the MySQL root password that you created in the Install MySQL section of this document. You will be asked if you want to install different tables – just say “yes” to all the questions.

/usr/sbin/kamdbctl create

• Below are all the prompts you will be presented:

MySQL password for root: ''
Install presence related tables? (y/n):
Install tables for imc cpl siptrace domainpolicy carrierroute userblacklist htable purple uac pipelimit mtree sca mohqueue rtpproxy?
(y/n):
Install tables for uid_auth_db uid_avp_db uid_domain uid_gflags uid_uri_db? (y/n):

• The following MySQL users and passwords are created (please change these in a production environment).

• kamailio – (With default password ‘kamailiorw’) – user which has full access rights to ‘kamailio’ database.

• kamailioro – (with default password ‘kamailioro’) – user which has read-only access rights to ‘kamailio’ database.

Enable the mysql and auth modules.

Add the following to the beginning of the kamailio.cfg after #!KAMAILIO

#!define WITH_MYSQL
#!define WITH_AUTH

Update the DBURL line to match the username and password you set in kamctlrc before running kamdbctl

#!define DBURL "mysql://kamailio:kamailioro@localhost/kamailio"

Start the Kamailio Server

service kamailio start

We also need to edit /etc/default/kamailio to notify Kamailio that is is configured and ready to go.

Uncomment the following:

RUN_KAMAILIO=yes

Test Kamailio

• In order to test that Kamailio is working correctly, I’m going to create a SIP user account and register that account using a softphone such as X-Lite, Linphone, or Zoiper.

Create SIP User Accounts

• The following command will create a new SIP User. Note, that hte domain portion has to be specified unltess you export hte SIP_DOMAIN environment variable.

kamctl add <extension@domain>

• Here is what I created

kamctl add 1001@dopensource.com opensourceisneat

Registering a SIP Softphone

• configure whichever softphone you choose with the following options:

User ID: 1001
Domain:
Password: opensourceisneat

• Once you are registered, you can view all the registered extensions in kamailio with the following command.

kamctl ul show

Make a Test Call

• You can call yourself by entering 1001 into your softphone. If it rings then you have a basic Kamailio server installed and ready to be configured to provide load balancing, failover, accounting, etc. As an exercise, you should create another SIP user account and register that user using another softphone and try calling between the two SIP users.

References

• Install And Maintain Kamailio v4.1.x From GIT – http://www.kamailio.org/wiki/install/4.1.x/git

The purpose of this document is to explain how to install Kamailio and setup your development environment to make it easier to start configuring Kamailio to fit your requirements.  In this document I will explain how to install Kamailio on CentOS 6.6 and configuring VIM to make it easier to do development.

Assumptions:

• MySQL is installed

Installing Kamailio 4.2 from source on CentOS 6.6 (for some reason we love CentOS)

I used the instructions located at http://www.kamailio.org/wiki/install/4.2.x/git as my basis.

You first need to install some packages that will be need for compiling Kamailio

yum install -y gcc flex bison mysql-libs make openssl-devel libcurl libxml2 expat-devel

Next we need to create a location for the Kamailio source

mkdir -p /usr/local/src/kamailio-4.2
cd /usr/local/src/kamailio-4.2

We now can use GIT to grab the source and checkout the latest 4.2 release

git clone --depth 1  git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.2 origin/4.2

Continue with the installation by starting at step 3 thru step 7 in the instructions located at http://www.kamailio.org/wiki/install/4.2.x/git

Setup Development Environment

We personally like using the VIM autocomplete plugin for Kamailio that was created by Daniel-Constantin Mierla (co-founder of Kamailio).  It makes development much easier.

The vim extensions that handle syntax highlighting and file type auto detection is shipped part of the source. So you just need to install it

cd /usr/local/src/kamailio-4.2/kamailio/utils/misc/vim/
make install

If you want to have autocomplete you will need to grab it from Daniel’s GIT repository

git clone https://github.com/miconda/vim-extensions.git
cd vim-extensions
make install-kamailio-plugin

Now you can have autocomplete turn on automatically when you edit a Kamailio file in VIM by running this command which will create a ~/.virmrc file with the command to turn on autocomplete for Kamailio functions and reserved words

echo '" custom complete function for kamailio config
 autocmd FileType kamailio setlocal completefunc=KamailioComplete' >> ~/.vimrc'

Test that it’s working

vim /usr/local/etc/kamailio/kamailio.cfg

You should see #!KAMAILIO in purple. You can test autocomplete by starting hit “i” on the keyboard to enter insert mode and then hit CTRL+x, then CTRL+u.  You will see a list of Kamailio functions that will pop up.  See my screenshot below:

References

• http://www.kamailio.org/w/tag/4-2/
• https://github.com/miconda/vim-extensions/blob/master/plugin/kamailio/README.md

Load balancing traffic with Kamailio

Note: We assume you have Asterisk/Freeswitch setup to handle inbound traffic from Kamailio

In part 3 of our Kamailio series we will explain how to load balance calls from users between several different media servers. For this part in the series we will use the “dispatcher” module. The dispatcher module provides us with several different ways to load balance calls from round-robin to weight based routing.

Getting Started

For this tutorial, you’ll only need one thing besides Kamailio and that is a list of media servers. If you don’t have any media servers, we recommend using Freeswitch and/or Asterisk.

Configuring Kamailio

By default, Kamailio does not load the dispatcher module or any of the modules respective settings. Let’s start with loading the module into Kamailio. Open up your kamailio configuration file (/etc/kamailio/kamailio.cfg), find the load modules section and add the following line:

 loadmodule “dispatcher.so”

Scroll down further in the file until you locate the module parameters section. Go the bottom of that list and add the following:

modparam("dispatcher", "db_url", "mysql://kamailioro:kamailioro@localhost/kamailio")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")

Save the file and restart Kamailio to make sure there are no errors. You can restart kamailio with:

# kamctl restart

If that didn’t work, go back and make sure you have everything entered properly. Once it’s running with no problem open back up the configuration file and proceed to the “request_route” section. Comment out the following line by appending a “#” pound symbol to the front of it.

 route(PSTN);

Right below add the following line:

 route(DISPATCHER);

It’s time to add the actual code that will do the dispatching. Go to the code block below “route[RELAY]” and add the following:

route[DISPATCHER] {
  # round robin dispatching on gateways group '1'
  if(!ds_select_dst("1", "4"))
  {
    send_reply("404", "No destination");
    exit;
  }
  xlog(“ —— DISPATCH: going to <$ru> via <$du>n");
  route(RELAY);
  exit;
}

In the above code, we chose to use the round-robin algorithm for routing calls. Basically, our calls will cycle between the media servers we chose to setup. If we have 2 media servers setup our calls will process like so, call 1 will go out of MS1, call 2 out of MS2, call 3 out of MS1 and so on.

With the dispatching code in place, we’ll need to add the actual destinations into the Kamailio database. Login to your MySQL database and execute the following commands. You can replace the destination and description with your media servers.

mysql> INSERT into dispatcher (setid, destination, flags, priority, attrs, description) VALUES (1, “sip:asterisk.example.com:5060”, 0, 0, "", "Endpoint: Asterisk Media Server");

mysql> INSERT into dispatcher (setid, destination, flags, priority, attrs, description) VALUES (1, “sip:freeswitch.example.net:5060”, 0, 0, "", "Endpoint: Freeswitch Media server");

With that completed, we’ll need to reload Kamailio. Since we haven’t restarted Kamailio since adding the dispatch route let’s just restart Kamailio using the same command as before. However, if you restarted Kamailio since adding the dispatch route you can just use the following command to reload the dispatcher info.

# kamctl dispatcher reload

Now that the routes are loaded into Kamailio, all you’ll need to do is push some calls through to Kamailio and they will be routed in a round-robin fashion like we stated above.

Reference

• Dispatcher Modules Documentation – http://kamailio.org/docs/modules/4.1.x/modules/dispatcher.html

 

The goal of this document is to explain how to get Kamailio to route traffic to the carrier with the least cost. This is part 2 in our Kamailio series.

 Getting Started

You don’t need much for this tutorial. All you’ll need is 2 carrier endpoints and their rates for calling a certain area code. Other than a Kamailio server, you can proceed with the rest of the tutorial.

 Configuring Kamailio 

Before we start setting up the LCR module, we first need to make some changes to the Kamailio configuration file. First off, we will need to modify the listen parameter. Open up your Kamailio configuration (kamailio.cfg) and look for the “listen” line.

If your Kamailio instance is behind a firewall make your line look like this:

listen=udp:<internal address>:5060 advertise <external address>:5060

Else if your Kamailio instance is on the public internet make it look like this:

listen=udp:<external address>:5060

By default Kamailio does not load the LCR module so we will need to add it.  In the same config file, locate the section where it says “loadmodule” and go to the bottom of that list and add:

loadmodule “lcr.so”

We can now begin setting up the LCRs module parameters.

Configuring LCR Module 

Now that we’ve configured Kamailio, we need to configure the LCR module. Back in the configuration file, look for the module parameters section.  At the bottom of that section, add the following values:

modparam("lcr", "db_url", "mysql://kamailioro:kamailioro@localhost/kamailio")
modparam("lcr", "gw_uri_avp", "$avp(i:709)")
modparam("lcr", "ruri_user_avp", "$avp(i:500)")
modparam("lcr", "tag_avp", "$avp(lcr_tag)")
modparam("lcr", "flags_avp", "$avp(i:712)")
modparam("lcr", "lcr_id_avp", "$avp(s:lcr_id_avp)")
modparam("lcr", "defunct_gw_avp", "$avp(s:defunct_gw_avp)")

With the module configured, it’s time to setup the actual routing of the SIP requests. In the “request_route” above the line that says:

 # dispatch request to foreign domains

Add the following line:

 route(LCR);

Then add a new route using the code below, put this at the end of the file:

route[LCR] {
if (status=="200")
{
  xlog("LCR: Inside the LCR routen");
}

if(method=="INVITE")
{
  xlog("We got an invite");
  if(!load_gws(1, $rU, $var(caller_uri))) {
    xlog("Couldn't load gateways");
    sl_send_reply("500", "Server Internal Error - Cannot load gateways");
    exit;
  } else {
        xlog("GW Selected '$avp(i:709)'n");
        xlog("Domain of destination: $ddn");
        xlog("To URI: $tun");
  }

  if(!next_gw()) {
    xlog("Couldn't proceed to next gateway");
    sl_send_reply("503", "Service not available, no gateways found");
    exit;
  } else {
        xlog("Calling the first matched gatewayn");
        xlog("ruri_user_avp: '$avp(i:500)'n");
        xlog("To URI after next_gw: $tun");
        xlog("Request URI: $rUn");

  }

}
}

 

Adding LCR Data

With our routing code in place, we need to add some data to LCR tables. Before we do that let’s go over what tables the LCR module uses and how they all fit together.

There are 3 tables that the LCR module uses:

• lcr_gw  – holds the gateways or endpoints where we can send our requests
• lcr_rule – holds all the rules we will match against. Our area codes. 
• lcr_rule_target – holds the rule to gateway matchings.

The most important table is the lcr_rule_target table. In this table, we take the ID of the rule from the lcr_rule table and connect it to the ID of the gateway we want all requests to go out of of it the request matches that rule.

For instance, if we setup a rule in the table that matches all request that start with 734 with an ID of 12, we can match that to a gateway ID in the lcr_rule_target table. So when a request comes in that starts with 734, it will be sent to that gateway.

For this example, we will be using 734 as the area code and 192.168.1.112 as the carrier. You can replace these values with your own in the steps below.

1.   Login to MySQL

 # mysql -u root -p

1.   Connect to the Kamailio DB

 mysql> use kamailio;

1.   Let’s insert a gateway.

mysql> INSERT INTO lcr_gw (lcr_id, gw_name, ip_addr, port, uri_scheme, transport, strip, flags) VALUES (1, “Carrier1”, “192.168.1.112”, 5060, 1, 1, 0, 1);

1.   Next let’s add an LCR rule.

mysql> INSERT INTO lcr_rule (lcr_id, prefix, stopper, enabled) VALUES (1, “734”, 1, 1);

1.   Finally let’s add rule to gateway matching.

mysql> INSERT INTO lcr_rule_target (lcr_id, rule_id, gw_id, priority, weight) VALUES (1, 1, 1, 1, 1);

Repeat these steps for each of your carriers. Increase the weight for the carrier with the cheaper weight.

Testing Kamailio

Before we begin testing we need to make sure a few other things are in order. You’ll need to make sure that your ITSP knows you’re going to be sending traffic from your Kamailio IP address. You’ll also need a SIP phone pointed at Kamailio or have Kamailio setup as a trunk in a PBX.

With that said, we need to refresh what Kamailio has in memory. We can do this with:

# kamctl lcr reload

 

Now just call that area code from a phone and your call should go out of the carrier with the higher weight.