Skip to main content

Posts

Showing posts from November, 2014

Bridging WebRTC and SIP with verto

Verto is a newly designed signalling protocol for WebRTC clients interacting with FreeSWITCH . It has an intuitive, JSON-based RPC which allows clients to exchange SDP offers and answers with FreeSWITCH over a WebSocket (and Secure WebSockets are supported). It’s available right now with the 1.4 stable version (1.4.14 at the moment of writing). The feature I like the most is “ verto.attach ”: when a client has an active bridge on FreeSWITCH and, for any reason (e.g. a tab refresh) it disconnects, upon reconnection FreeSWITCH automatically re-offers the session SDP and allows the client to immediately reattach to the existing session. I have not seen this implemented in other places and find it extremely useful. I’ve noticed recently that this does not fully work yet when the media is bypassed (e.g. on a verto-verto call), but Anthony Minnesale, on the FreeSWITCH dev mailing list said this feature is still a work in progress, so I’m keeping an eye on it. Initially I was ex...

Don't trust the kernel version on DigitalOcean

This was tricky. I was setting up a VPN connection with a newly built DigitalOcean droplet (standard debian wheezy 64bit in the London1 data center). The connection is based on openvpn , and it's the same on many other nodes, but openvpn wasn't starting properly (no sign of the tun interface). Googling the problem brought me to this reported debian bug , where apparently the problem was associated to an older version of the linux kernel. But I had the latest installed: ii  linux-image-3.2.0-4-amd64          3.2.63-2+deb7u1               amd64        Linux 3.2 for 64-bit PCs The reason why this problem was present is that the version actually loaded was different! Apparently [...] it seems that grub settings are ignored on digital ocean, and that you instead have to specify which kernel is booted from the Digital Ocean control panel, loaded from outside the droplet [...] So to see w...

Deploying Kamailio with Puppet

Almost three years ago I started automating the deployment of all server-side applications with Puppet . One of the key applications in Truphone's RTC platform (and arguably in most of VoIP/WebRTC platforms today) is Kamailio , so with some proper encapsulation it’s been possible to build a Puppet module dedicated to it. This is now publicly available on PuppetForge . Puppet Forge is a public repository of Puppet modules. We use many of them, and they can be incredibly useful to get you up to speed and solve common problems. You can also fork it on github , if you want. You can use this module in different ways: To quickly deploy a kamailio instance, with default configuration files. As the basis for a custom configuration, where you use the official debian packages but with your own configuration details and business logic. The first approach is very simple. Imagine you start from and empty VM or base docker container: all you have to do is install pup...

Puppet module support on 2.7.13

Yesterday I just noticed that on Ubuntu Precise, with a stock Puppet installation (2.7.13), 'puppet module' ( a tool to build and install modules ) was not available. Soon found an explanation on superuser : 'puppet module' was released with 2.7.14. There is a straightforward way to get out of this: upgrade Puppet as recommended by PuppetLabs and go straight to version 3 (unless of course you have constraints to stay on 2). These steps will allow you to get Puppet directly from PuppetLabs repos (just choose the target distribution). At the moment of writing this procedure would upgrade Puppet on Ubuntu Precise from '2.7.11-1ubuntu2.7' to '3.7.3-1puppetlabs1'.