On the state of Free VoIP

Every now and then I decide I’ll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn’t think I was aiming that high. I thought I’d start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the “I have my laptop and I want to remain connected” case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.

Let’s start with getting a SIP server up and running. I went with repro which seemed to be a reasonably well recommended SIP server to register against. And mostly getting it up and running and registering against it is fine. Until you try and make a TLS SIP call through it (to a sip5060.net test address). Problem the first; the StartCom free SSL certs are not suitable because they don’t advertise TLS Client. So I switch to CACert. And then I get bitten by the whole question about whether the common name on the cert should be the server name, or the domain name on the SIP address (it’s the domain name on the SIP address apparently, though that might make your SIP client complain).

That gets the SIP side working. Of course RTP is harder. repro looks like it’s doing the right thing. The audio never happens. I capitulate at this point, and install Lumicall on my phone. That registers correctly and I can call the sip:test.time@sip5060.net test number and hear the time. So the server is functioning, it’s the client that’s a problem. I try the following (Debian/testing):

  • jitsi - Registers fine, seems to lack any sort of TURN/STUN support.
  • ekiga - No sign of TLS registration support.
  • twinkle - Not in testing. A recompile leads to no sign of an actual client starting up when executed.
  • sflphone - Fails to start (Debian bug #745695).
  • Empathy - Fails to connect. Doesn’t show any useful debug.
  • linphone - No TLS connect (Debian bug #743494).

I’m bored at this point. Can I “dial” my debian.org SIP address from Lumicall? Of course not; I get a “Codecs incompatible” (SIP 488 Not Acceptable Here) response. I have no idea what that means. I seem to have all of the options on Lumicall enabled. Is it a NAT thing? A codec thing? Did I sacrifice the wrong colour of goat?

At some point during this process I get a Skype call from some friends, which I answer. Up comes a video call with them, their newborn, perfect audio, and no hassle. I have a conversation with them that doesn’t involve me cursing technology at all. And then I go back to fighting with SIP.

Gunnar makes the comment about Skype creating a VoIP solution 10 years ago when none was to be found. I believe they’re still the market leader. It just works. I’m running the Linux client, and they’re maintaining it (a little behind the curve, but close enough), and it works for text chat, voice chat and video calls. I’ve spent half a day trying to get a Free equivalent working and failing. I need something that works behind NAT, because it’s highly likely when I’m on the move that’s going to be the case. I want something that lets my laptop be the client, because I don’t want to rely on my mobile phone. I want my email address to also be my VoIP address. I want some security (hell, I’m not even insisting on SRTP, though I’d like to). And the state of the Open VoIP stack just continues to make me embarrassed.

I haven’t given up yet, but I’d appreciate some pointers. And Skype, if you’re hiring, drop me a line. ;)

2014 SPI Board election nominations open

I put out the call for nominations for the 2014 Software in the Public Interest (SPI) Board election last week. At this point I haven’t yet received any nominations, so I’m mentioning it here in the hope of a slightly wider audience. Possibly not the most helpful as I would hope readers who are interested in SPI are already reading spi-announce. There are 3 positions open this election and it would be good to see a bit more diversity in candidates this year. Nominations are open until the end of Tuesday July 13th.

The primary hard and fast time commitment a board member needs to make is to attend the monthly IRC board meetings, which are conducted publicly via IRC (#spi on the OFTC network). These take place at 20:00 UTC on the second Thursday of every month. More details, including all past agendas and minutes, can be found at http://spi-inc.org/meetings/. Most of the rest of the board communication is carried out via various mailing lists.

The ideal candidate will have an existing involvement in the Free and Open Source community, though this need not be with a project affiliated with SPI.

Software in the Public Interest (SPI, http://www.spi-inc.org/) is a non-profit organization which was founded to help organizations develop and distribute open hardware and software. We see it as our role to handle things like holding domain names and/or trademarks, and processing donations for free and open source projects, allowing them to concentrate on actual development.

Examples of projects that SPI helps includes Debian, LibreOffice, OFTC and PostgreSQL. A full list can be found at http://www.spi-inc.org/projects/.

Forms of communication

I am struck by the fragmentation in communication mechanisms. Let’s look at how I have communicated with my friends in the past few days:

  • Phone call
    Tried and tested, though I tend to avoid them. I’ve made some deliberate calls to sort out immediate plans, and at least one accidental call caused by user error which resulted in talking to someone it was good to hear from
  • Text message
    Again, reasonably tried and tested. I miss the inability to use Google Voice when I’m in the UK; I’d much rather read and compose text messages from my web browser when I’m near a computer than type them on my phone, even if it does have a keyboard.
  • Email
    One of my favourite methods of communication. Suitable for quick messages or longer screeds. I can throw links in and expect you to be able to click them. I can put lots of detail so that everything is covered easily. I can confuse you by quoting correctly. I guess while I do read email on my phone I’m less likely to reply there as I’m always a bit embarrassed how the clients cope with replies.
  • IRC
    Like, I suspect, many readers of my blog posts, I’m still a daily user of IRC. There are friends I keep in touch with mostly via this method. It’s great. It’s like Twitter for old people and much better in many ways.
  • Skype
    This started out as a work thing. It was the way in which the Belfast office communicated with the US, it become the way the Belfast office communicated with each other and when I moved on it was the way in which I kept in contact with a group of people I consider good friends. It’s great for calls (I feel bad saying that, but it’s an idea executed well across multiple platforms and any other VOIP stuff I’ve played with has been much more of a hassle), but the one to one and group chat functionality is pretty spot on as well. Also has the advantage that I can turn it off and mostly not end up with work queries.
  • Google Hangouts
    I actually quite like these. They work on my phone, I can poke them from a web browser, I can dump more than just text into them. IRC is better in some ways, but I do like the additional flexibility I get from a Hangout. It doesn’t play well with people who haven’t drunk the Google koolaid, which is the main reason I haven’t managed to convince the Skype group chat group to move it over here.
  • Facebook messenger
    I hate this. On the face of it there’s not a lot of difference between it and Hangouts, but the app wants more and more privileges, I’m less likely to be logged into Facebook (e.g. I avoid it at work, whereas there are good reasons I’d be logged into my Google account there, though less so since the demise of Reader) and I don’t think it’s as nicely implemented. However there are a few people who it’s easiest to get hold of via this method. And there’s a certain amount of mesmerisation by the floaty wee faces it invokes on my phone.

While some of these work better for me than others really what I’d like is to use fewer of them, and I can’t see that happening any time soon. I don’t want to have to run a handful of different messaging apps on my phone. I also don’t want to be limited to only using my laptop or my phone for something - I’d much prefer to be able to pickup the phone, laptop or tablet depending on what I’m up to and have my full range of communication available. Some of these things can be aggregated together, but that will then lose some of the advantages. And I’m sure that even if I got rid of one or two of the above there’d be something to fill the gap along shortly (I have, for example, so far completely avoided WhatsApp).

Choosing a new laptop

Recently I’ve been thinking about getting a new laptop. I have this rule that a laptop should last me at least 3 years (ideally more) and my old laptop was bought in September 2010. So for the past few months I’ve been trying to work out if there’s something suitable on the market that is a good replacement (last time I didn’t manage to find something that ticked all the boxes, but did pretty well for the price I paid).

To start with I decided to track my laptops over time - largely because one of my concerns was about the size of a replacement, because I have a significant leaning towards subnotebooks. In the end the reason I decided to upgrade was for some extra CPU grunt; my old machine had a tendency to get pretty hot under any sort of load.

DateModelCPUScreenRAMStorageW (mm)H (mm)D (mm)WeightCost
1991Amstrad PPC 640DNEC V30 8MHz9" 640x200 non-backlit green LCD640k2 x 3.5" FDD45023010010kg???
August 1997Compaq Aero 4/33c486sx337.8" 640x480 CSTN LCD4MB80MB260190431.6kg???
July 2002Compaq Evo N200P-III 700MHz10.4" 1024x768 TFT192MB20GB251198201.1kg£939.99
August 2005Toshiba Portege R200Pentium M 753 1.2GHz12.1" 1024x768 TFT1280MB60GB286229201.29kg£1313.58
September 2008Asus EEE 901Atom N270 1.6GHz8.9" 1024x600 TFT2GB4GB + 16GB SSD248175231.1kg£299.99
September 2010Acer Aspire 1830TCore-i5 470UM 1.33GHz11.6" 1366x768 TFT8GB500GB284203281.4kg$699.99 (~ £480)

The EEE didn’t actually replace the Toshiba, but I mention it for completeness. It was actually the only machine I moved to the US with, but after about a month of it as my primary machine I realized it wasn’t an option for day to day use - though it was fantastic as a machine to throw in an overnight bag, especially when coupled with a 3G dongle.

I wasn’t keen on significantly increasing the size of my laptop. There are a number of decent 13” Ultrabook options out there, and I looked at a few of them, but nothing grabbed me as being worth the increase in size. Also I wanted something better than the Acer - one of the major problems was finding something smaller than 13” that had 8G RAM, let alone more. There’s a significant trend towards everything soldered in for the smaller/slimmer notebooks, which makes some sense but means that the base spec had better be right.

Much to my surprise the Microsoft Surface Pro 2 looked like an option. It comes with an i5-4300U processor (at least since around Christmas 2013), and the 256/512G SSD models have 8G RAM. Screen resolution is an attractive true HD (1920x1080) and the 10” display means it’s smaller than the Aspire. Unfortunately the keyboard lets it down. It’s fine given a flat surface, but not great if you want to support the whole thing on your lap. Which is something I tend to do with my laptop, whether that’s on the sofa, or in bed, or on a bus/train.

Another option was the Sony Vaio Pro 11. This is a pretty sweet laptop (I managed to get to play with one at a Sony store in the US). Super slim and light. 8GB RAM. True HD screen. However I have bad memories of the build quality of the older Vaios and the fact that there was /no/ user replaceable parts put me off - it’s a safe bet that a laptop battery is going to need replaced in a 3 year lifespan.

What I managed to find, and purchase, was a Dell Latitude E7240. I admit that the Dell brand made me wary - while I’ve not had any issue with their desktops I didn’t associated their laptops as being particularly high quality. Mind you, I could say the same for Acer and I’ve been very pleased with the Aspire (if they’d had a more up to date model I’d have bought it). I bought the E7240 with the Core-i5 4300U (so the same as the Surface Pro 2) and True HD touch screen. It has a replaceable battery, expandable RAM (up to 16G) and the storage is an mSATA SSD. It also came with a built in 3G card. At 12.5” it’s a little bigger than my old machine, but I decided that was a reasonable idea given the higher resolution. I’m typing this article on it now, having finally completed the setup and migration of the data from the old laptop to it this evening. More details once I’ve been using it for a little bit I think.

Fixing my parents' ADSL

I was back at my parents’ over Christmas, like usual. Before I got back my Dad had mentioned they’d been having ADSL stability issues. Previously I’d noticed some issues with keeping a connection up for more than a couple of days, but it had got so bad he was noticing problems during the day. The eventual resolution isn’t going to surprise anyone who’s dealt with these things before, but I went through a number of steps to try and improve things.

Firstly, I arranged for a new router to be delivered before I got back. My old Netgear DG834G was still in use and while it didn’t seem to have been the problem I’d been meaning to get something with 802.11n instead of the 802.11g it supports for a while. I ended up with a TP-Link TD-W8980, which has dual band wifi, ADSL2+, GigE switch and looked to have some basic OpenWRT support in case I want to play with that in the future. Switching over was relatively simple and as part of that procedure I also switched the ADSL microfilter in use (I’ve seen these fail before with no apparent cause).

Once the new router was up I looked at trying to get some line statistics from it. Unfortunately although it supports SNMP I found it didn’t provide the ADSL MIB, meaning I ended up doing some web scraping to get the upstream/downstream sync rates/SNR/attenuation details. Examination of these over the first day indicated an excessive amount of noise on the line. The ISP offer the ability in their web interface to change the target SNR for the line. I increased this from 6db to 9db in the hope of some extra stability. This resulted in a 2Mb/s drop in the sync speed for the line, but as this brought it down to 18Mb/s I wasn’t too worried about that.

Watching the stats for a further few days indicated that there were still regular periods of excessive noise, so I removed the faceplate from the NTE5 master BT socket, removing all extensions from the line. This resulted in regaining the 2Mb/s that had been lost from increasing the SNR target, and after watching the line for a few days confirmed that it had significantly decreased the noise levels. It turned out that the old external ringer that was already present on the line when my parents’ moved in was still connected, although it had stopped working some time previously. Also there was an unused and much spliced extension in place. Removed both of these and replacing the NTE5 faceplate led to a line that was still stable. At the time of writing the connection has been up since before the new year, significantly longer than it had managed for some time.

As I said at the start I doubt this comes as a surprise to anyone who’s dealt with this sort of line issue before. It wasn’t particularly surprising to me (other than the level of the noise present), but I went through each of the steps to try and be sure that I had isolated the root cause and could be sure things were actually better. It turned out that doing the screen scraping and graphing the results was a good way to verify this. Observe:

ADSL Noise Graph

The blue/red lines indicate the SNR for the upstream and downstream links - the initial lower area is when this was set to a 6db target, then later is a 9db target. Green are the forward error correction errors divided by 100 (to make everything fit better on the same graph). These are correctable, but still indicate issues. Yellow are CRC errors, indicating something that actually caused a problem. They can be clearly seen to correlate with the FEC errors, which makes sense. Notice the huge difference removing the extensions makes to both of these numbers. Also notice just how clear graphing the data makes things - it was easy to show my parents’ the graph and indicate how things had been improved and should thus be better.

subscribe via RSS