SBC Setup
SBC Setup
Below you'll find a step by step setup for installing FS as a SBC. The LCR engine is provided by
Kamailio and its module carrierroute. Kamailio is an opensource SIP Proxy (not a B2BUA).
In this setup, the dialplan is detailed only for inbound to outbound traffic, but it could be easily
extended for outbound to inbound traffic (or DID).
The design is the following:
FS is configured with an internal and an external profile, each profile listening on a different
network interface.
Kamailio is listening on the loopback interface, and is not used by any other process than FS.
Internal--------FS--------External
|
|
Kamailio
When FS receives an INVITE, FS fires this event in the default context, where it always matches
the extension named LOOKUP_ROUTE. In this extension, FS sends the INVITE to Kamailio, that
will replies with a 302 Redirect SIP message that contains the route FS has to use to reach the
number dialed. The call is then transfered in the context ROUTING where FS will match the
associated Gateway (in this setup it is an associated code) that will route the call.
If Kamailio has no route for the dialed number, it replies with a "604 unable to route the call" that
FS will relay.
So Kamailio is used only for route lookup by FS, and FS is the only equipment that is seen in the
SIP transaction.
This design has been choosen cause I needed a way to store big LCR table (it's now more than
450 000 routes on the production server) and LCR module was not available when I began playing
with FS (version 1.0.1).
I extensively tested this setup on an Intel Quad Core server (Q9550 running at 2.83Ghz with 8GB
RAM. 4GB should have been far enough).
I ran some tests using SIPP with 750 simultaneous calls and between 50 to 100 calls per second
(CPS) for more than 10 days with 25%-30% CPU ressource free. FS version was 1.2 at this time.
Advantages
Stable with quite huge routing table: Kamailio was using less than 3% CPU when doing the SIPP
tests with 160 000 entries in LCR table.
Scalable: some people are using carrierroute module with LCR table up to 1 million entries.
Correct call per second rate: up to 100cps.
Drawbacks
Each INVITE you send to FS will first send an INVITE to Kamailio, and once FS receives the
Kamailio answer, FS will bridge the call to the Peer that will process the call.
I'm feeling that if you want to process more call per seconds (more than 100 CPS), the fact that the
Sofia library is monothreaded and that it has to deal with one more session (FS to Kamailio) before
processing the call to the Peer could prevent FS to reach a higher CPS rate. (For everybody that
has a better internal knowledge of FS than me, feel free to correct this assumption).
Install screen
apt-get install screen
Restart server
reboot
Prepare Network interface (I'm using a switch with vlans, useful for network isolation)
* Load linux vlan module
modprobe 8021q
* add 2 vlans (one for internal profile ex: vlan 100, the other for external profile ex: vlan 200)
vconfig add eth0 100
vconfig add eth0 200
* bring them IP
ip addr add 10.10.10.254/24 dev eth0.100
ip addr add 10.10.20.254/24 dev eth0.200
Start FreeSWITCH
If you need a LCR route table of approximatively 50 000 routes, then bypass this step.
For those who'd like to load a bigger LCR route table in carrierroute (for my needs: 160 000 routes)
emacs /opt/sources/kamailio-1.5.0-notls/config.h
#define PKG_MEM_POOL_SIZE 32*1024*1024 /*!< Used only if PKG_MALLOC is defined*/
#define SHM_MEM_SIZE 4*32 /*!< Used if SH_MEM is defined*/
Note: these values have been set by empirical means and are maybe too high even for 160 000
routes
/opt/kamailio/sbin/kamdbctl create
You'll be prompted for root sql password (remember you used 1234 or ...) and don't forget to set
yes for carrierroute table creation
You have inserted your first route, that will match prefix 1000 and route this to PEER_01 with a
description, FRANCE in this example. PEER_01 will be defined later in FS dialplan. The
description parameter could be exported, for billing purpose for example. In this setup, I'll export
the description to an AREA variable in FS.
Configuration of Kamailio
cd /opt/kamailio/etc/kamailio
mv kamailio.cfg kamailio.cfg.default
emacs kamailio.cfg
Start Kamailio
/opt/kamailio/sbin/kamctl start
Check Kamailio is running
netstat -unlp
You should see something like this
udp 0 0 127.0.0.1:5062 0.0.0.0:* 16269/kamailio
Put this
<?xml version="1.0" encoding="utf-8"?>
<!-- http://wiki.freeswitch.org/wiki/Dialplan_XML -->
<include>
<context name="default">
<extension name="LOOKUP_ROUTE">
<condition field="destination_number" expression="(\d+)$">
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=true"/>
<action application="export" data="sip_h_X-ROUTE=LOOKUP"/>
<action application="bridge" data="sofia/internal/${destination_number}@127.0.0.1:5062"/>
<action application="set" data="ROUTE_GW=${sip_redirect_contact_host_0}"/>
<action application="set" data="AREA=${sip_redirect_contact_user_0}"/>
<action application="transfer" data="${destination_number} XML ROUTING"/>
</condition>
</extension>
</context>
<context name="ROUTING">
<extension name="PEER_01">
<condition field="${ROUTE_GW}" expression="PEER_01">
<action application="set" data="hangup_after_bridge=true"/>
<action application="set"
data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,TIMEOUT,NO_ROUTE_DESTINATION
<action application="set" data="PEER=1.1.1.1"/>
<action application="bridge" data="sofia/external/${destination_number}@1.1.1.1"/>
<action application="set" data="PEER=2.2.2.2"/>
<action application="bridge" data="sofia/external/${destination_number}@2.2.2.2"/>
<action application="set" data="PEER=3.3.3.3"/>
<action application="bridge" data="sofia/external/${destination_number}@3.3.3.3"/>
</condition>
</extension>
</context>
</include>
In fact PEER_01 is used as an index for a combination of peers. I do this to have a failover
mechanism to a backup peer if the 1st peer is down.
You can load balance to different PEER combinations by using probability in carrierroute table. Ex:
using 2 routes pointing to PEER_01 and PEER_02 with a probability of 0.5 and you will share the
load between these 2 peers combination.
Test connectivity between FreeSWITCH and Kamailio
Test that FS and Kamailio are talking to each others
Register an IP phone using credentials in /opt/freeswitch/conf/directory/default/1001 for example
to dump traffic on the loopback interface for SIP messages between FS and Kamailio
ngrep -d lo -nn -W byline
Optimizations
Stop FreeSWITCH
/opt/freeswitch/bin/freeswitch -stop
With these settings, we have defined a maximum of 500 bridged calls (2*500 channels) and a
maximum of 100 new sessions per second. You should set these parameters according to your
hardware
Use Proxy Media to keep FS in the RTP media path (topology hiding) but without analyzing RTP or
DTMF
emacs /opt/freeswitch/conf/sip_profiles/internal.xml
<param name="inbound-late-negotiation" value="true"/>
emacs /opt/freeswitch/conf/sip_profiles/external.xml
<param name="manage-presence" value="false"/>
Check that your Network Interfaces Cards (NIC) are not sharing IRQ
cat /proc/interrupts
ideally, your ethernet cards should be put on different IRQ, and if you have more than one CPU,
you can force affinity of a NIC with a specific CPU (I will add a note later on this)
Check CPU usage
Install some useful utils for checking CPU consumptions
apt-get install sysstat
You can check the load of your CPUs using
mpstat -P ALL 1
13:13:13 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
13:13:14 all 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00 162,00
13:13:14 0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00 162,00
The %idle represents the idle percentage of the CPU, higher is better as it means that you have
free CPU ressources
vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 80 234312 93496 1273928 0 0 1 32 55 65 2 3 95 0
0 0 80 234296 93496 1273928 0 0 0 0 106 1299 0 0 100 0
top
I think that I do not have to introduce this tool