Speaking of Standards

Looking for a softphone that lets you easily make VoIP calls over IPv6 using the SIP protocol? I was looking to do this and after trying several of the common SIP softphones I knew of, several people pointed me over to Linphone which turns out to work like a charm! I knew of Linphone from a number of years back, but I mistakenly thought it was Linux-only… nope! It truly is cross-platform with binary versions for Windows and Mac OS X, and source available for Linux distros – plus versions for iPhone, Android and Blackberry.

With really just one configuration change, here is what it looked like to make a SIP call using IPv6 addresses (well, almost what it looked like since I did mask the actual addresses, being as security-paranoid as I am):

In the top address field I simply entered the SIP address using the standard format:

sip:user@ipddress

with the exception that because it is an IPv6 address I enclosed the address in square brackets (per RFC 3986). That’s it. I was off and making my call.

The One Configuration Step (and the caveat)

All I had to do to make this work was go into the settings (which you get by going to the “Windows” menu and choosing “Preferences” on Mac OS X) and checking off the box that says to use IPv6:

After checking that box and pressing “Done”, Linphone changed my identity to show my local IPv6 address and let me start making calls to IPv6 addresses.

The caveat

Now whether this “just works” does depend upon how you are connected via IPv6.

In my case, I use Tunnelbroker.net to have IPv6 in my home office (which I explained previously how to configure for Apple devices and for generic devices). The effect of doing this is that…

I am directly connected to the IPv6 side of the Internet.

So for me, the screen above with the radio button next to “Direct connection to the Internet” works fine. If you are behind a IPv6 NAT or gateway device, you may need to adjust the settings here.

Indeed, when I used Linphone for testing with IPv4, I did need to change the options myself, because for IPv4, my home network is behind a NAT / firewall. In my case I went for the second of the three options and provided my external IP address:

So you may need to adjust these settings in order to have Linphone work with IPv6.

Now, Linphone is a pretty bare-bones SIP client… it doesn’t have all the features and frills of many of the other clients out there… but that’s okay… all I wanted to do was test out the ability to make calls using SIP over IPv6. And for that it worked great!

As a bonus, it does not require you to set up a SIP account and register with a SIP registrar. You can just use it for direct computer-to-computer calling… which again is exactly what I needed in this case.

I’ll be writing more about making SIP calls over IPv6 in the weeks and months ahead… but in the meantime I thought I’d pass along this info.

I’ve tried Jitsi, the rebranded “SIP Communicator”, but it seemed to require me to set up a SIP account before I could make calls… and I don’t have an IPv6-compliant SIP system to which I can register.

In any event, I’m greatly impressed with Linphone… kudos to the team there for making it work so well over IPv6!

P.S. Thanks to some Voxeo colleagues for the recommendation of Linphone and also to someone in the #ipv6 IRC channel on Freenode (mentioned in this post).

Would you like to learn about IPv6 and how it works with VoIP? On this Friday, November 26th, at 12 noon US Eastern time, the VoIP Users Conference crew will gather on their weekly conference call to discuss IPv6 with Olle Johansson. Olle is well known within the Asterisk community and will be discussing his work with Asterisk and IPv6 along with other topics. The proposed agenda right now is:

• IPv6 – how to get it into your network today
• VoIP and IPv6 – why is this a good marriage?
• Experiences from Asterisk 1.8 IPv6 support
• Living in a dual stack world
• Dual stack considered bad for VoIP?
• Implementations out there – a call for help? Which devices used in the VUC community supports IPv6? Any experiences?
• Setting up a VUC IPv6 testbed
• Follow-up call planning – monitoring the IPv6 migration process in the VUC community.

More info about the call is at:

http://www.voipusersconference.org/2010/ip-v6/

Info about how to join the conference call is available on the VUC site, but can be summarized as:

• SIP: sip:200901@login.zipdx.com
• Skype: vuc.me
• PSTN: +1 425-906-3916
• iNum: +883 5100 123 94882

There is also an active IRC backchannel during the call (#vuc on freenode).

If you’re interested in IPv6 it should be a fun and informative call. If you can’t attend, the call will be recorded for later listening.

P.S. And yes, Friday is the day after US Thanksgiving and a holiday for most US companies… but VUC is global and meets every Friday.

Otmar Lendl recently posted a thoughtful piece called “What’s wrong with Speermint and Drinks” that digs into the differences between and the challenges of the IETF’s Speermint and Drinks Working Groups. Otmar started out explaining why they are necessary:

First of all, why do we need these WGs at all? The quick answer is that VoIP interconnection based on plain SIP and ENUM did not work out as envisioned by the authors of the respective RFCs. There are a number of reasons for that (see draft-lendl-speermint-background), and I don’t expect that the IETF can do anything to change this.

He then points out the fundamental problem facing these groups and really the “SIP/VoIP space” in general:

Call routing was rather simple in the full mesh world (be it PSTN or RFC3263 SIP), it only needed some directory service to map Public Identities (PI = phone numbers or SIP URIs) to operators. In a lot of cases, these directories are static simple mappings like “route anything starting with +49 to Deutsche Telekom”.

This is no longer sufficient. Any solution to the current world-wide call routing problem needs to cope with arbitrary interconnection graphs, not just the trivial case of full meshes. A directory will not suffice any more: we need a full blown routing algorithm.

I repeat: The current graph of interconnection between carriers has no special properties any more. We have a text-book routing problem to solve.

That is the challenge. The old world of the PSTN was relatively simple. Fewer players in the interconnection game… and because there were so few they could do “full mesh” interconnectivity between the various players.

It’s a different world, today. There are many players in the call routing game and pretty much anyone can enter that game. Otmar’s point is that the current proposed solutions focus more on central registries and other mechanisms traditionally used in the world of the PSTN. He argues that we really need more of a “routing” solution that allows multiple registries and systems – and indeed works like other Internet routing protocols.

For those interested in the underlying SIP plumbing that is being built to better interconnect all of us using SIP out there, Otmar’s post is well worth a read (fair warning that it does dive into details and terminology).

I don’t know that there are any easy answers out there (or it would have been solved already)… but the conversation is ongoing and will continue for quite some time.

If you aren’t thinking about the security of your VoIP systems, you should be, because the tools to attack those systems keep getting better. Over on the Voice of VOIPSA blog, I recently wrote about the release of a new suite of security test tools that make some of the attacks now “point-and-click”.

For a variety of reasons, many of these attacks are against SIP or unencrypted RTP, so they are definitely good to understand.

P.S. Note that VOIPSA (VoIP Security Alliance) does have a lengthy list of VoIP security tools already… this new suite is just one more to be added to the list.

Technorati Tags: sip, sip security, voip, voip security, security, voipsa