Saturday, 17 September 2016

Deploying Homer with Puppet

Fan of Homer? So am I, and as sometimes happens I'm a fan who could join the team!

If despite the title of this post you're still reading, then it's a good sign and we can move on.

Homer is a vast project that aims to provide a tool, with a GUI, to correlate all the signalling, RTCP stats, events, logs in your RTC network. It focuses heavily on SIP, for historical reasons, but it's also an extendible framework to store other types of signalling, correlate data, and compute statistics. People browsing their github account are often heard saying "Do they have this too? And this? Wow!".

It is compatible off the shelf with common applications like Kamailio, opensips, FreeSWITCH, Asterisk, so if you're into VoIP, adding Homer to your platform is as easy as installing it and telling your apps where to send their data. There are also standalone tools like captagentnodejs apps to parse and collect specific logs, to be associated with the related signalling, and a plethora of libraries, including a C one.

Anyway the topic is extremely vast and you can find a lot (a lot) of information on the sipcapture website.

Lately I've been working on Homer deployments using Puppet, a Configuration Management tool, so I wanted to share the experience, and as a result you can find a Puppet module in the homer-puppet repo. In fact this is re-written from scratch from previous experiences and focusing on debian/Ubuntu. Specific need on other distributions can be addressed without much effort, so anybody deploying their infrastructure with Puppet and using Homer is encouraged to look at this work and provide feedback and questions.

Homer can be installed with a well tested homer-installer and through Docker containers, so this work just adds to the deployment opportunities, but as usual in this field, what fits for an organisation may not fit for another.

The approach is quite flexible. Most of the data has a default value so the minimum amount of data to be passed to the module - which of course can be done via hiera - is very limited and aims to allow people to configure a new system in minutes.

Homer has 4 main components: the DB of course, kamailio or opensips to collect data from the apps, a web server for the GUI  (homer-ui) and an API for the queries (homer-api). With homer-puppet you can git checkout the versions you need for homer-ui and homer-api and just launch puppet apply (standalone mode) to have everything installed and configured.

There is a default kamailio.cfg for storing data and providing stats, but that can be customised to your needs (see the modules/homer/files/kamailio folder inside the Puppet module).

Templates are used for the files containing variable elements (namely, mysql and admin credentials, and a few more).


I'm working on a version that instead of installing the components directly on the target host is designed to manage Docker containers (one for kamailio, one for the web part), through Docker Compose. There are many moving parts and while it fits well in a system that already includes a private Docker registry, it's trickier to "sanitise" and share. But I'm getting there.

Meanwhile, enjoy!

Monday, 6 June 2016

FreeSWITCH - Check what configuration directories are in use

There is a little trick to see what directories FreeSWITCH is using as paths for the configuration files:

/opt/freeswitch/bin/fs_cli -x 'global_getvar'| grep _dir

For example, the output can be:

base_dir=/usr/local/freeswitch
recordings_dir=/usr/local/freeswitch/recordings
sounds_dir=/usr/local/freeswitch/sounds
conf_dir=/opt/freeswitch/etc/freeswitch/
log_dir=/usr/local/freeswitch/log
run_dir=/usr/local/freeswitch/log
db_dir=/usr/local/freeswitch/db
mod_dir=/usr/local/freeswitch/mod
htdocs_dir=/usr/local/freeswitch/htdocs
script_dir=/usr/local/freeswitch/scripts
temp_dir=/tmp
grammar_dir=/usr/local/freeswitch/grammar
fonts_dir=/usr/local/freeswitch/fonts
images_dir=/usr/local/freeswitch/images
certs_dir=/usr/local/freeswitch/certs
storage_dir=/usr/local/freeswitch/storage
cache_dir=/usr/local/freeswitch/cache
data_dir=/usr/local/freeswitch
localstate_dir=/usr/local/freeswitch
internal_ssl_dir=/usr/local/freeswitch/conf/ssl
external_ssl_dir=/usr/local/freeswitch/conf/ssl 

This is handy in particular when you're testing an installation from source but the configuration is not in the default location.

It's possible to set non-default values by passing them as arguments for the daemon, e.g.:

/usr/local/freeswitch/bin/freeswitch -conf /opt/freeswitch/etc/freeswitch/ -log /usr/local/freeswitch/log -db /usr/local/freeswitch/db -ncwait -core

In general, when in doubt about the configuration path, use that fs_cli command to verify.

More info is as usual available from FreeSWITCH official documentation: Command Line Switches.

Friday, 27 May 2016

Continuous Integration and Kamailio

I've presented a workshop at Kamailio World 2016. It focused on tools to help automating the build, deployment and test of Kamailio-based applications using Jenkins, Docker and a few other technologies.

It's been also an opportunity to show a sample usage of the new http_async_client module, designed to perform non-blocking HTTP queries from Kamailio.

The interested reader can find the slides here:



And if you have an hour to spare, here's the full video:




Any feedback or question you may have, please get in touch. I have a post on the event in progress, but there are so many things to highlight that it will require some more time.

Many thanks to Daniel and Elena-Ramona (more info here), event hosts, and Pascom.net for video streaming, recording and editing.


Wednesday, 3 February 2016

Extracting Opus from a pcap file into an audible wav

From time to time I need to verify that the audio inside a trace is as expected. Not much in terms of quality, but more often content and duration.

A few years ago I wrote a small program to transform a pcap into a wav file - the codec in use was SILK.

These days I'm dealing with Opus, and I have to say things are greatly simplified, in particular if you consider opus-tools, a set of utilities to handle opus files and traces.

One of those tools, opusrtp, can do live captures and write the interpreted payload into a .opus file.
Still, what I needed was to achieve the same result but from a pcap already existing, i.e. "offline".

So I come up with a small - quite shamlessly copy&pasted - patch to opusrtc, which is now in this fork.
Once you have a pcap with an RTP stream with opus (say in input.pcap) you can retrieve the .opus equivalent (in rtpdump.opus) with:

./opusrtp --extract input.pcap

Then you can generate an audible wav file with:

./opusdec --rate 8000 rtpdump.opus output.wav

Happy decoding.

Friday, 18 December 2015

TADHack mini Paris

"I’ve been following TADHack and its related events for some time, and finally this month I got the opportunity to attend TADHack-mini Paris. Participants can join from remote too, but the personal full immersion is something different (even, ironically, when the topic is Real Time Communications, and more in particular WebRTC and Telecom APIs.
We met in central Paris [...] "
This is the beginning of the behind-the-scenes story about my TADHack participation. You can read my full article here.

Wednesday, 16 December 2015

Speed up testing Kamailio routing

I was very happy to see the news of the release of a new Kamailio module, authored by Victor Sveva.
CFGT can be used to test call scenarios and see what routing logic was triggered in Kamailio.
Test calls need to be marked with a specific, configurable Call-ID pattern ('callid_prefix').
A JSON report is generated, with the possibility to choose what variables to dump into it.
This is going to greatly simplify testing, while potentially keep the logging to a minimum. Highly recommended.

Wednesday, 25 November 2015

Docker and Puppet for Continuous Integration

This is a topic I really care about. Please take a look at the slides (they are quite verbose) used in a seminar at a local developers group: