Skip to main content

Posts

Showing posts from October, 2014

Hacking our way through Astricon

This year I was speaking at Astricon for Truphone Labs (you can see my slides here if you're interested). The week before Astricon I was invited try out respoke , a solution that allows you to build a WebRTC-based service . They provide you with a client JavaScript library, and you need a server account (with an app ID and secret key) to connect your application to the respoke server and allow clients to communicate with each other. This is an intuitive approach. As a service developer, you pay for the server usage, and you do so depending on how many concurrent clients you want. I got a testing account, and started trying out the JS library. The process of building a new application was very straightforward, and the docs guided me towards building a simple app to make audio calls, and then video calls as well. Soon I started thinking: respoke is from Digium , right, and Digium develops Asterisk . How is it possible that respoke and Asterisk cannot interconnect? W...

Removing all unused docker containers and images

docker containers are very easy to build, and the ability to re-use them is extremely handy. They do require a lot of disk space though, and if like me you need to retrieve some of that space you can delete the containers that are not running with this command: docker rm $(docker ps -a -q) In fact 'docker ps -a -q' lists all the containers, but 'docker rm' won't destroy running containers, and the command above will do the job. You still have the images though (visible with 'docker images'), and each one can be relatively big (> 400MB). I tend not to tag images, so in general I'm interested in the 'latest' ones, or the official ones (like ubuntu:14.04, where ubuntu is the repo and 14.04 is the tag). Anyway even if selecting the "untagged" ones does the job for me, I can clean up the undesired images with: docker rmi $(docker images -q --filter "dangling=true") I've seen other commands just relying on th...

Accessing the full P-Asserted-Identity header from FreeSWITCH

I hope this can save the reader some time. If you need to read the entire content of the P-Asserted-Identity header of an incoming INVITE, be aware that you should change the sofia profile by adding a param like: param name="p-asserted-id-parse" value="verbatim" FreeSWITCH will populate the variable accordingly and make it available with commands like (e.g. with lua): PAID = session:getVariable("sip_P-Asserted-Identity") If you don't add this parameter, you'll get the default behaviour, which is just filling the variable with the P-Asserted-Identity URI username part. Possible value are: "default", "user-only", "user-domain", "verbatim" , which I think are self-explanatory. A recent reference here .

Comparing Configuration Management Tools The Hard Way

I've been using Puppet for more than 2 years now, and written almost 50 custom modules, for about 4K lines of code. The more I work with it, the easier is to find a 3rd party module to solve a problem for me, and I can just focus on very specific needs. I rarely wrote any Ruby snippets, and basically relied on Puppet's DSL. A couple of times I submitted a pull request for a 3rd party module, and got my changes merged in. I started using Puppet for a very specific reason: there was already expertise in the company, and most part of the infrastructure pre-requirements were deployed using it (even if in a Master-Slave mode, while I favour the Standalone approach). All this said, I can't ignore what's going on in the Devops world; many other tools are being developed to solve automation of configuration management, and with the aim of being 1. Extremely easy to use 2. Reliable 3. Scalable. In my hunt for comparisons I've stumbled upon this article from Ryan Lane...

Build a test bed with FreeSWITCH and PJSUA (with SILK)

Build and run FreeSWITCH This is based on debian wheezy, and uses master FreeSWITCH . You can switch to stable when cloning. In my experience this is the quickest way to get to a working, vanilla setup that you can use to automate tests with PJSUA (the PJSIP command-line client). mkdir git cd git # To get master git clone https://stash.freeswitch.org/scm/fs/freeswitch.git cd git/freeswitch ./bootstrap.sh -j # If changes are needed to the list of modules to be compiled vi modules.conf ./configure --enable-core-pgsql-support make sudo make install # Launch FS (in foreground) sudo /usr/bin/freeswitch You can find here the process for building it from source recommended by the FreeSWITCH team. In /etc/freeswitch/vars.xml you may want to change the default password in: cmd="set" data="default_password=XXXXXXXX" If you're enabling SILK , add it to the list in modules.conf.xml : load module="mod_silk" and add it to global_codec_prefs ...