Giacomo Vacca

I've just finished reading a surprising book, and I'd like to share some notes with you. I was initially looking for something to improve the reasoning and logical flow during conversations. I found "Thinking, Fast and Slow" , which is not really about that, but kept going for some pages and then couldn't stop. I'm not using any kind of referral promotion, so if any reader of this post will buy the book I won't get a cent. And I'm not expert on psychology, sociology or economy. It's just that "Thinking, Fast and Slow" has been a great reading experience. There are some insights on the way people think and decide that are worth analysing. First of all the authors present two separate ways of "thinking": the first is intuitive, voluntary. It derives from millennia of evolution, where as animals we needed to decide in a fraction of second whether a situation was a danger or an opportunity. This is effortless and alway...

There's something about debugging: the more you have experienced finding the root cause of bugs in the past, the highest the hope and confidence you'll squash the one currently under the microscope. You see I didn't mention "fixing" a bug, because I think finding the root cause of any bug has value per se . Fixing them is a separate adventure. Anyway this week I was entirely bamboozled by this: a Docker container was re-deployed with a different networking configuration. In particular, with Compose, I was dedicating a network for that container (let's say 172.18.0.0/24) separate from the default Docker network (e.g. 172.17.0.0/24). In docker-compose.yml: networks:   apps:     driver: bridge     ipam:       driver: default       config:       - subnet: 172.18.0.0/24         gateway: 172.18.0.1 In the "service" definition I just added this: services:   THESERVICE:     ...

Following my earlier post on "Opus SDP negotiation" in the series "For The Practical Man", I'm presenting today a related topic: Opus audio codec when transcoding is involved. Most of the providers of PSTN connectivity require the simplest possible VoIP codec: G.711 (which comes in two flavours, u-law and a-law). G.711 is a sort of PCM encoding at 8000 samples per second: 8000 times per second an audio sample is encoded with 8 bit. Sometimes Comfort Noise can be used, reducing the bitrate when silence is detected, but otherwise the typical working principle is a continuous flow of digitally-encoded packets of voice. u-law and a-law just use a different way to encode the data. (If you're curious about what does silence look like in G.711, I wrote a post about it some time ago ). G.729 is another widely adopted codec, but I'll leave it for another day. With 8000 samples per second and 8 bit dedicated for each sample G.711 requires a net...

Opus [0] is a versatile audio codec, with a variable sample rate and bitrate, suitable for both music and speech. It is defined in RFC 6716 [1] and required by WebRTC [2]. Opus can operate at various sample rates, from 8 KHz to 48 KHz, and at variable bitrates, from 6 kbit/sec to 510 kbit/sec. The RTP payload format defined for Opus in RFC 7587 [3] explains the use of media type parameters in SDP, and this article aims to analyze them and show in particular how "asymmetric streams" can be achieved. This is an example of SDP defining an Opus offer or answer:       ...

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 captagent ,  nodejs apps to parse and collect specific logs, to be associated with the re...

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/loca...

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: Continuous Integration and Kamailio from Giacomo Vacca 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.

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: ./opusd...