Irontec Tiny SBC

Hello !

First of all: Keep Calm, what we are releasing is the functional base, something like «the minimum viable product» that would be said from the perspective of a project manager;)

Something to start walking and open the project to the community, is not something production ready or similar, do not consider right now for anything serious please.

Another SBC?

There are many projects that allow you to build yourself something as generic as an SBC, which even in the RFC say is somewhat diffuse and many experts consider it a marketing term.

With Kamailio, OpenSIPS, SEMS, FreeSwitch, YATE, … there are many options to build an entire one, fitted exactly to your needs.

In our case, the needs we had (and especially those that we do not have – which are almost the most determining factors) have led us to build our own tiny solution, which allowed us to:

Use a simple web interface that can be handled by technicians who know SIP but are not experts in Kamailio, OpenSIPS.
An easy system that allows us to manage well the needs of NAT traversal and rtp proxy’ing in diverse environments in which we are usually involved.

That said, and when you see it (for its simplicity) you will understand why the name;)

We strongly recommend reading README.md to see features that are not supported and those that are.

Show me the code and stop talking

Currently, at the time being, we use our private GITLAB, but migrating to public Github ASAP, it more than possible that when you read this post is available, please look on our repos.

Update: available here https://github.com/irontec/itsbc

Irontec Tiny SBC Architecture (ITSBC)

The architecture is tremendously simple (the «tiny» adjective is not ironic), mainly we have:

OpenSIPS for all signaling management.
Special mention to the midregistrar module.
RTPEngine for all media management.
Web interface to manage all this made with Symfony (EasyAdmin Bundle).

Complete case example of actual use

Description of the scenario

This hello world usage case is a very simple and introductory scenario, a deploy of ITSBC managing registers, requests and two type of agents: Corporate IP PBX and remote public internet users, so, main concepts can be demonstrated:

Previous needed tasks

Before following the next steps, we need to have:

VM or physical server with Debian 9 64bits installed.
Router / Firewall doing NAT and with the following redirections (port forward)
- [SIP TLS] TCP 4061 WAN against TCP 4061 of 192.168.1.2
- [RTP] UDP 17001-19000 WAN against UDP 17001-19000 of 192.168.1.2
  - (/etc/default/rtpengine)

We wanted to use an example behind nat because it’s easy to try this on Amazon EC2 or any other cloud.

ITSBC installation

The installation is fully documented in the file README.md, but we rephrase it here:

First add the Irontec repo for Debian 9:

echo 'deb http://packages.irontec.com/debian itsbc main'> /etc/apt/sources.list.d/irontectinysbc.list
wget http://packages.irontec.com/public.key -q -O - | apt-key add -
apt-get update

To install the packages:

apt-get install itsbc

The installation of the database, we will choose MariaDB, which is what is by default in Debian 9, but it should work with any MySQL Like (Percona, MySQL, ProxySQL …):

apt-get install mariadb-server
mysql -e "GRANT ALL PRIVILEGES ON *. * TO 'root' @ 'localhost' IDENTIFIED BY 'ROOTPASSWORD' WITH GRANT OPTION"

Then we have to edit and leave the MySQL options changed: /etc/opensips/opensipsctlrc

DBENGINE=MYSQL
## database port (PostgreSQL=5432 default; MYSQL=3306 default)
DBPORT=3306

## database host
DBHOST=localhost

## database name (for ORACLE this is TNS name)
DBNAME=opensips

## database read/write user
DBRWUSER=opensips

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

Finally, create the official OpenSIPS DB with this command (it will ask us for the MariaDB root pass):

opensipsdbctl create

With the password that we have decided for the user opensips we need to edit:

/opt/irontec/itsbc/config/opensips/opensips_database.cfg and change the access data:

modparam ("usrloc", "db_url", "mysql: // opensips: [email protected]/opensips")
modparam ("avpops", "db_url", "mysql: // opensips: [email protected]/opensips")

The last step is to add the tables necessary for the ITSBC administration website to work, it’s needed to edit: /opt/irontec/itsbc/app/config/parameters.yml with the correct access data

Web Administration will be ready after running this final command:

cd /opt  irontec/itsbc/
bin/console doctrine: database: import schema/initial.sql

Finally, reboot all the VM/Machine for making systemd start correctly OpenSIPS, Apache2 and RTPEngine.

Configurations to be made

Once executed those commands we can enter (https://192.168.1.2) with admin / irontec credentials.

For the example we have defined, we need to define:

2 SIP Listeners
- The first one is the one that listens «to / from WAN» by TLS and after NAT.
- The second one is the one against the IP PBX enterna, by UDP and without NAT.
2 Media IPs
- The first one is in 192.168.1.2 but with public 9.9.9.9 (what will travel in the SDP’s).
- The second one is the same IP 192.168.1.2 but without
1 Rule on Registers Routing
- Only the remote user’s are allowed to register
2 Rules on Requests Routing
- 1 rule for incoming traffic from Corporate IP PBX
- 1 rule for incoming traffic from remote users.

Easily, on the web side we define these elements following these screenshots (please change values with real ones 😉 )

(screenshots are with spanish column names, prior to our fully english rename everything 😉 )

SIP Listeners

The two SIP Listeners (for external requests and internal requests):

Media IPs

The two Media IP’s (like SIP Listeners, it’s same IP but different advertised – because of nat):

Rules in Routing Registers

A single rule for routing registers (from world) to private IP Corporate PBX (192.168.1.3)

Rules in Routing Requests

For non-register requests (such as INVITEs, SUBSCRIBEs, ACKs and BYEs) we need to define two rules:

First rule with less metric is for requests coming from corporate IP PBX, on this case we did not define destination, but we use special keyword «lookup».
Second rule are for requests from outside world.

On both cases we use RTP handling with external/internal or internal/external directions (please follow prior sections with the media ip’s name you have chosen):

Next Hop

At the moment, we do not have a clear roadmap, we wanted to share with you all this little tool, which for many cases can be worth. There are many points that can be improved and hundreds of implementable features, but we are going little by little.

May be the next stage is to refactor everything and make it web administrable with entities such as network objects, ACL’s, agents … so you can choose each item on the rules web section.

Feel free to hack the code, to do PR on Github or whatever you need;)