Giacomo Vacca

This blog has been historically focused on technical topics in areas related to Real Time Communications, but I'm taking the liberty to digress a little. I've been reading recently about the dynamics of performance in running. I'm just an amateur runner, and I always train (and race) alone, so I felt the need to make it more interesting than just reading training tables. I've been studying what is it that limits performance. "Train more", unfortunately, not only doesn't always work, but needs to take into account injuries, and overtraining in general. One of the first concepts that struck me is that it's been proven that fatigue, and the consequential slow down, does not mean that the body is unable to continue with that effort. What's behind slowing down is a sort of protective mechanism in our nervous system, which wants to prevent the body to reach exhaustion. Our nervous system is constantly getting feedback signals from the bo...

Some time ago I prepared an introductory seminar on Docker, which I called "Docker from scratch". The audience was a local group of heterogeneous developers. As it typically happens, preparing that material was a great opportunity to understand better some of the aspects. I then published the slides in Slideshare. I notice now that they got a decent number of views and downloads, so I'm linking those slides here as well for reference . One big change in respect to 2016 is represented by the choice of abandoning Docker Toolbox in favour of running Docker directly on macOS. I have to say I liked the sandboxing that came with Docker Toolbox, where the docker engine ran inside VirtualBox, now only available for older versions .

In the first part of my brain dump about this year's edition of Kamailio World I focused mainly on testing. Core developers and application designers want to be able to test the behaviour of Kamailio -based architectures with minimal effort and fast feedback. A different dimension to testing, that I haven't mentioned in my previous post, was related to Fuzz testing . There were two presentations focused on this: Sandro Gauci's (The easiest way to understand who Sandro is: listen on port 5060 on the public Internet and wait a couple of minutes. You'll see a SIP request from a tool called sipvicious (aka friendly-scanner), a penetration testing tool Sandro wrote (and others misuse)) and Henning Westerholt , historical member of the Kamailio community. Sandro's presentation focused around fuzzing approaches for RTC in general ( slides ), while Henning was more specifically focused on Kamailio. Fuzzing is a sophisticated technique to verify the robustness...

This was my fifth time in a row attending Kamailio World in Berlin. The weather was warmer and sunnier than usual. Apart from the obvious focus on Kamailio , as usual the RTC ecosystem was well represented (with Janus, Asterisk, FreeSWITCH, Homer, RTPEngine, and many others). Attendance from the other side of the Atlantic Ocean gave stronger emphasis to the "World" term in the title. My personal mission this year was to talk about a framework for testing Kamailio as a tool for developers and maintainers of the project: kamailio-tests . The main concept was that early tests that are not focused on a specific business logic (as we all have in our projects) and can be automated will be beneficial to Kamailio's reliability. We want to defer end-to-end testing to later stages, because they are expensive. To provide a uniform infrastructure where to run the tests, without requiring permanent test environments, we use Docker for this. This is, of course, not th...

An interesting pattern that caught my attention is the role that Lua is gaining in the RTC (Real-Time Communications) world. Lua is a small-footprint programming language, powerful while keeping a simple syntax. I’ve been using Lua to script dialplan actions for FreeSWITCH since about 2014. It has provided me with a way to define relatively complex logic and speed up the definition of FS’ behaviour. Delegating this type of logic to a scripting language had several advantages, such as: It’s easier to read and understand than native dialplans or native routing logic. Makes unit testing of the dialplan possible/easier. Allows changing some pieces of logic easily, in many cases preventing expensive reload of modules or restart of applications. I’ve been using Lua for Kamailio as well. Kamailio is an open source programmable SIP Proxy . In a specific case, some bits of the routing logic required regex processing and was expecting to change often: an ideal case for...

One of the handiest features of the docker build system is the caching system. 'docker build' tries to reuse the layers already built until something changes inside the Dockerfile. In this way, we can save several minutes when rebuilding an image if the changes happen further down the list in the Dockerfile. Sometimes, though, we do want to invalidate the cache and ensure the next build won't use it. To do this an option is to pass the '--no-cache' argument to 'docker build'. When dealing with 'apt-get install' instructions though there are other tricks. I found this document on Dockerfile best practices very useful. First of all an observation. If you have 'RUN apt-get update' as a single line of a Dockerfile, followed by the installation of a package, e.g.: RUN apt-get update RUN apt-get install -y nginx then changing the list of packages and running again the build command won't trigger an 'apt-get update': that...

If you've ever worked with SIP, you must have stumbled upon a trace with 200 OK to INVITE being retransmitted for about 30" and then the call just being set up fail. The ACK was never received. Then comes the interesting part: discovering why. Here are some notes about what should happen, in particular when there are multiple proxies along the path, and with a little additional complexity of one of the proxies with two network interfaces. All this assuming loose routing everywhere. The main reference here of course is RFC 3261 . Isn't an image worth a thousand words? Then here's a sequence diagram: All Record-Route headers are assumed to carry loose routing URIs (they have the ;lr attribute). B, C and D, working as proxies that want to stay in the path, record route themselves. For this reason E, the UAS and "callee", receives an INVITE with a list of Record-Route headers with B, C and D. In particular for B there will be two Record-Route head...

Often things are more convoluted than you expect. Sometimes they are easier than you fear. Here's an example: you're generating files inside a Docker container (with no volumes configured) and you realise you need some of those files available in the host. A simple solution is to use 'docker cp', with a format like docker cp CONTAINER_ID:FILE_PATH HOST_FILE_PATH Official documentation . A Stackoverflow question with more discussions .