IPv6friday.org :: Learn more about IPv6 every FridayI’ve started a separate blog to inspire people to learn more about IPv6 and start their own labs. It’s called IPv6friday.org and publishes a short article about IPv6 every Friday. I don’t know how the idea got started – I think it was just this Tweet that got a lot of responses.

IPv6 Friday beings

The main problem with IPv6: Knowledge and experience

The main problem with IPv6 today is the lack of knowledge and experience among all the network engineers and system developers out there. In Sweden, we have been running a few very open meetings about IPv6 to discuss and map what to do. Almost all discussions ends up with the question: How can we get companies to invest in IPv6 training on all levels? How do we get the technical people to start playing with IPv6? I don’t have the answer, but for myself, I’ve learned a lot by publishing these articles. Learning new stuff is always fun. As a parallel project, I’m moving a lot of my own servers and services to dual stack (or in some cases, single stack IPv6) servers. It takes time, I make mistakes and I discover a lot of issues in various pieces of software.

Follow me and spend 30 minutes on IPv6 every Friday!

Spend 30 minutes with IPv6 every Friday!Please join the ride, follow the flow and spend at least 30 minutes on IPv6 every Friday. Learn more, lab and join the discussion. In addition to the blog, there’s a Twitter account, Facebook page and a Google plus page. If you have ideas or want to contribute, just contact me.

IPv6 is the future of the Internet. It’s required for the Internet to grow. It’s required for the Internet to be for everyone on the planet. It’s needed for true peer-to-peer applications. We do need it to stop spending time on NAT traversal in SIP and focus on more important issues – like how SIP can become competitive to Skype and FaceTime and the architecture and requirements for a global open Internet-based federation for realtime communication. 30 minutes a week isn’t too much of your valuable time. It’s an investment for the future that will help both yourself in your personal career and the organization your work for. See you next Friday!


SIP over dual stacks - IPv4 and IPv6

Stay Connected - learn more about SIP & IPv6

Yesterday I found an Internet Draft called Testing Eyeball Happiness that gives examples on how to test dual stack deployments. There is a known issue with applications that retrieves multiple IP addresses from the same host name in DNS and , following current RFCs, test them sequentially with a preference for IPv6 addresses. The timeouts when things go bad with one flow are far longer than what the user accepts. Let’s say that Bob (you know him) use his SIP phone to place a call to Alice. Bob’s phone calls an outbound proxy, that wants to forward to another domain. This domain announces both IPv4 and IPv6 addresses in DNS for their proxy. Now, Bob’s proxy actually has an IPv6 address, but is not connected to the Internet with IPv6. The proxy will try connecting to Alice’s domain SIP proxy over IPv6 for quite a long time before it recognizes that there’s no connectivity. Hopefully it will then try another address, but the question is if the user is waiting for that to happen. In telephony, loosing seconds is a catastrophe, especially between requesting a call and getting the first ringing signal. Remember – this is not about media, this is only about signaling. Without signaling, we’ll never get into any media issues.

HTTP and Happy Eyeballs

We’ve seen this problem on the web. Browsers suddenly told us that large sites was not available. Turned out that the new home router enabled IPv6 tunnels and announced IPv6 prefixes on the LAN, something that the firewall blocked. By disabling IPv6 in the laptop, we could reach the web site again. This caused web sites to stop announcing IPv6 and computer owners to disable IPv6. This was no good for the IPv6 migration so the browser developers started to try to find solutions. The Happy Eyeballs discussion in the IETF is about finding algorithms where the browser connects to all addresses in parallel and selects a candidate that answers quickly. In SIP, we need to implement the same fix, over UDP, TCP and STCP. I’ll try to set up some tests at SIPit to see what the current state is.

A quote from the abstract section of the IETF draft:

In a dual stack network (i.e., one that contains both IPv4 [RFC0791] and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network that uses multiple prefixes allocated by upstream providers that implement BCP 38 Ingress Filtering [RFC2827], the fact that two hosts that need to communicate have addresses using the same architecture does not imply that the network has usable routes connecting them, or that those addresses are useful to the applications in question. In addition, the process of establishing a session using the Sockets API [RFC3493] is generally described in terms of obtaining a list of possible addresses for a peer (which will normally include both IPv4 and IPv6 addresses) using getaddrinfo() and trying them in sequence until one succeeds or all have failed. This naive algorithm, if implemented as described, has the side-effect of making the worst case delay in establishing a session far longer than human patience normally allows. This has the effect of discouraging users from enabling IPv6 in their equipment, or content providers from offering AAAA records for their services.


Last week I talked at the Voip2Day conference in Madrid, organized by Avanzada7. The talk, named “Watch out!” covers new areas developed in SIP, but not implemented in many devices or servers out there. Solutions for NAT traversal, PSTN trunk registration and new work with the real time web is covered, along with a small update to the list of 10 bullets to remember when implementing a new SIP platform.

Some topics covered:

  • ICE, Interactive Connection Establishment, a complex but working solution to find a working media path between two Sip phones, either directly or using a media relay (A TURN server). Used both for NAT traversal and IPv4/IPv6 dual stack deployments.
  • SIP Outbound, the way to handle NAT traversal for SIP signaling. With SIP outbound, the client sets up multiple IP connections, called flows, to servers while indicating that it’s actually the same device that registers on all these connections. The proxy can then do failover if one connection fails. It’s up to the SIP phone, the user agent, to maintain the connections and re-open them when they fail.
  • GIN – the way SIPconnect sends a registration for a SIP trunk with multiple phone numbers. Before GIN, every vendor used it’s very own hack which raised the cost for service providers that wanted to support multiple vendors.
  • GRUU – Globally Routable User URI’s – a domain-based address for every device that registers for an account. Makes it possible to do more complex operations over domain boundaries. Without a GRUU, many URI’s are unusable since they’re referring to an IP address hidden behind a NAT device.
I feel that ICE and SIP outbound are good candidates on solving the NAT puzzle as well as the IPv6 transition. We need more Open Source implementations as a reference!
The presentation also covers RTCweb briefly. On the conference, there was a live demonstration by Iñaki Bas Castillo and a colleague of a SIP implementation in JavaScript connecting over WebSockets to a SIP proxy. They lacked RTCweb so there was no media in the calls, but it showed that it’s possible to implement SIP in the browser!

The talk is now published on Slideshare and can be viewed online. Enjoy!


Realtime communication in web browsersVideo sessions in the browser opens up for a lot of new applications. While this has been working with various plugins, new opportunities will open up when it becomes part of your standard web browser. HTML5 introduced native video in the browser. New standardization are looking into peer2peer multimedia sessions in the browser, not just broadcast. This opens up for a large set of applications, from “click2call” without plugins to video chats like in Facebook and Google+. This is exciting. And all the old SIP architects seems to have jumped onto this project, trying to get things right from start in this second generation effort. (more…)

Alec Saunders has written a new manifesto called “Voice 3.0: The emergence of the Voice Web“. It’s very good reading and I agree with most of it. Please read it! What I am missing, which you will see in my comment far down the side, are two things:

  • IPv6 – it’s the glue that will make Voice 3.0 work
  • Security – we need to learn from our mistakes and make Voice 3.0 secure by default

I have written a lot of information about SIP and IPv6 on Edvina’s web site, Twitter and Facebook. Dan York has joined me in this campaign and have a lot of good podcasts, presentations and information on Voxeo’s IPv6 resources page. There’s quite a lot of work we still need to do, but we’re heading in the right direction in the SIP community.

I’m embarrassed

Now is the  time to start working on security. I find it really embarrassing that we have almost no experience of security in VoIP. The protocol has been around for ten years or more and we’re still confused. The hardware vendors claim that the CPUs can’t handle it. Or the DSP’s. Or something else. As we move towards more video we need more CPU power to encrypt. On the other side we have users that doesn’t require any security. They run stuff over the enterprise networks, over home networks and the Internet without bothering with who can listen in, access the log files or access their accounts.

The dark side

This last year, the number of attacks on SIP servers has grown in numbers. I hear not only rumours, but see attacks in progress. I have met a number of people who have lost huge amounts of money on International calls to foreign countries, placed by unknown hackers that figured out that their account (typically “300”) had a very complicated password (typically “300”). The next thing that we’re going to see during summer leave or xmas is someone showing a journalist how easy it is to see that the boss calls the union several times a day, propably to negotiate layoffs. Or calling competition, maybe to sell the company.

Let’s agree on one thing: ALL networks are insecure

I think it’s time to stop ignoring security. I think we have to agree that it makes our architecture much more easy if we assume that ALL networks are insecure. We can not judge, our users surely can not determine if a network is secure or not. They have to be able to connect to any open WiFi network and use the services we produce. Without thinking about anything else than reaching their office, customer, family or the kid back home. Every communication needs to be secure. Period.

If we start there, we’re on the right track. Now we need to work together and figure out where to go. How do we exchange encryption keys? How do we handle identities? Where do we start. Let’s not make the mistake of trying to hook on to a global PKI that doesn’t scale (and has proven not to be secure) like the one used by the web. PGP is interesting, but only scale on a nerd level. It’s too complicated the way we use it today. I would not even try to explain it and make my mother use it. We need to work on this.

Distributed webs of trust

Maybe it’s Facebook, Google+ or LinkedIn that will be the trust platform. Or a combination of them using systems like OpenID, oAuth and SAML 2.0 in various combinations. We need something simple, scalable and secure. That’s not easy to fulfill. Especially in a world filled with engineers with a lot of opinions, experiences and ideas. It’s our responsibility to start working on this. The IETF and other parties are already working hard on other components of Voice 3.0.Let’s get our act together on the security part of the vision for Voice 3.0 too. We need to, step by step, build a trustworthy platform for realtime communication for everyone.

SIPit 28 was hosted by Digium in Huntsville, Alabama, USA the week of April 11-15, 2010. There were 54 attendees from 19 companies visiting from 10 countries, using 40 distinct implementations in the interoperability tests.

SIPit, organized by the SIP Forum, is one of the foundations that make SIP work across vendors and implementations. Twice each year, developers from all around the world meet and test, discuss, learn and fix issues both in implementations and standards. During SIPit events, many bugs in the RFCs – or just missing explanations – has been found. Under the leadership of Robert Sparks, SIPit has become the primary event for all SIP developers. Edvina proudly organized SIPit #26 in Stockholm in May 2010.

See the report for SIPit 28 at https://www.sipit.net/SIPit28_summary

I really miss attending SIPit. I do hope I can attend SIPit #29 in the fall. If you are developing SIP software – clients, servers, devices – make sure you attend the next SIPit with your team!  We have a lot to test, from SIP outbound to SRTP, MSRP, IPv6 and TLS.

During the last couple of months, I’ve been trying to understand how to migrate SIP to a world with dual stacks or only IPv6 stacks.  In order to get momentum, I’ve started to create a repository of information on Edvina’s SIPv6 site. I’ve also started a new Twitter flow and a Facebook page. Please follow the project there.

Dan York of Voxeo encouraged this work even further by writing an article on the Voxeo blog called “Will You Join In Olle’s Crusade for VoIP and IPv6?” Great support – thanks, Dan!

I have been doing a lot of reading, trying to start discussion on various mailing lists and have gotten a lot of good feedback I’m trying to digest. Here’s the summary from the latest page on the Edvina web:

I’m confused! My personal feeling is that there are many bits and pieces, many in expired drafts, that is needed to create a working solution. In addition, we need to create a happy-signalling-solution that focuses on dual stack call setup using DNS to find the next hop and possibly Record-route issues. For developers, this is all very confusing and time-consuming to understand and try to implement. It’s time to come up with clear guidelines.

Help me untangle this mess!


IPv6 has lead to many bad user experiences in the web world, something we in the SIP community needs to learn from and avoid. Many problems come from the idea about dual stacks. For softphones, dual stack will be a reality, for edge servers it is a must-have but for hard phones it might not be a requirement at all. We need to develop a best current practice. While the web browser can take a few seconds to retry connections, doing that for a phone call might be a disaster. Especially if it happens for every phone call.


You are drafted for my IPv6 SIP task force! Here’s our action points:

  • Review IETF documents on SIP IPv6  migration. Are all depending on all devices having dual stack? If so, does it really work?
  • Test IPv6-only solutions. Do they work? Is it possible to use Asterisk or Kamailio for reaching IPv4 SIP devices?
  • Test DNS SRV records. Are they usable to indicate your preference for IPv6 or IPv4 calls to your domain? Will devices support it?
  • Check SIP service providers – do they support IPv6 today?
  • Check Open Source solutions – is the IPv6 support complete? Does it work both in dual stack and single IPv6 stack mode?
  • Check phone manufacturers – does their products support IPv6?

Are there other questions to sort out? Is so, let me know. And let’s make 2011 the year when the SIP world embraced IPv6!

After each SIPit, Robert J Sparks writes a summary that includes the results of a survey done during SIPit and reports from the multiparty tests. These are all very interesting and show where the SIP developers are in relationship to the IETF work.

The SIPit26 summary shows  an uptake in SIP implementations that support TLS. It also reveals that we’re going to make the automated self-tests that has been created during SIPit available on line. We’ve created self-tests for TLS, Early media and IPv6. Hopefully there will be more tests added to this suite. Thanks to Nils Ohlmeier and Daniel Constatin Mierla for helping me with these!

The next SIPit is not determined yet – SIP forum is still looking for a host, primarily in Australia or New Zeeland. If you want  to know more about what it means to be a host, please don’t hesitate to contact me. SIPit test events are important for the whole business. Read the report and you’ll understand why.

Next Page »