On the state of Free VoIP

| 3 Comments | No TrackBacks

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. ;)

No TrackBacks

TrackBack URL: http://the.earth.li/~noodles/cgi-bin/mt/mt-tb.cgi/282

3 Comments

Hi!

In no way I'm a VoIP expert but in the past I read a few articles that SIP is a quite old technology coming from the good old phone network area. Especially establishing end-to-end encryption in a way that it works with almost all providers/clients seems to be quite hard.

For me XMPP seems to be the natural solution, did you tried it? I have to admit that I didn't tried video/audio chat for quite some time. But text chat works great. My mail address is also my XMPP address. We have many good clients and audio+video chat should also work these days.

I guess you will have read http://www.rtcquickstart.org/ as well? I was able to get two Jitsi clients call each other that way already. Unfortunately I did not manage to find a Nokia N9 client yet which can connect to the TLS-only server. (Did not try installing a client certificate on the phone yet though.) I tend to agree - this is still difficult, even after many years. It does feel like some decent progress is being made lately.

Cheers,
Frederik

The StartCom issue with missing certificate purposes is: https://forum.startcom.org/viewtopic.php?f=15&t=2328

Of course, it got ignored.

//mirabilos

Leave a comment

About this Entry

This page contains a single entry by Jonathan McDowell published on July 17, 2014 2:08 PM.

2014 SPI Board election nominations open was the previous entry in this blog.

Breaking up with America is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.10