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

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.


Sollentuna, Geneva and Prague, April 1st, 2011: The IETF and the IPv6 Forum today launched SIP-six, the new version of SIP that cleans up a lot of misunderstandings and greatly simplifies implementations of SIP. 

  • ”We realize that 99% of the SIP users use SIP for PSTN phone calls. The original SIP standards was written with other applications in mind, a vision that never came true.” said Bob Plug, area director in the IETF. ”That’s why we sat down and said to our selves that this should be way more simple.”

The SIP-six standard totally removes the dependency of domains and URI syntax. There’s no longer any point in using this, since everyone seems to think that IP addressing is more than enough. The new standard use part of the vast IPv6 address space to incorporate the E.164 phone number as end point addresses. This is the reverse of the reverse phone number usage in the enum standard, which is no longer needed in SIP-six.

By using IPv6 mobile IP, phone users register their phones and get access to their phone number. Users that need security can easily integrate IPsec into their setup. Media and signalling uses the same addressing scheme and is mixed so that both SIP-six, RTP and RTCP only uses one port address – but in this case a single port address with a 32 bit subaddress identifying the media stream. This finally solves a lot of the firewall traversal issues that SIP v2.0 had. With the combination of mobile IP and use of public IP addresses NAT traversal won’t be an issue.

The testbed for SIP-six has been running for a year at six choosen large SIP carriers, with the assistance of Edvina AB in Sweden and ViaGenius in Montreal, Canada. In an International effort, the testbed is today put in production and Roboid phones all over the world is automatically connected to this worldwide network.


  • -”We have for a long time pointed out that IPv6 is not only a replacement of IPv4, it’s an enhancement that is the breeding ground for new types of applications.” says Olle E. Johansson, chairman of the SIP-six working group. ”With SIP-six we really use the potential of the IPv6 address space and new technologies, like Mobile IPv6.”

  • -”While the SIP v2 protocol was developed with IPv6 in mind, it never really used the potential of the new IP protocol. With SIP-six we finally solve that issue and move SIP to new areas. By simplifying the protocol and removing DNS and URIs from the design, new developers and vendors will embrace SIP and we’ll see new applications in a short while.” says Bob Plug. ”This will be the final death blow to ISDN, since it’s an easy upgrade to add the IPv6 address prefix and continue to use the same addressing.”

SIP-six is implemented as a channel driver in Asterisk 2.0, as a replacement for SIP2.0 in Kamailio 4.0 and a channel module in FreeSwitch – all releases to be released later today. Softphones for testing will shortly be available from Blink and Zoiper.

A friend of mine, Jacob Schlyter, has not only been busy working on DNSsec around the globe. He has also been co-writing a new draft in the IETF DANE working group. He blogs on

The working group’s first draft describes how to use DNSSEC to associate certificates with domain names For TLS. In this context, a certificate association is a secure binding between a DNS name, TLS/DTLS transport protocol (i.e., TCP, UDP or SCTP) and port number, to an end entity’s certificate or to a certification authority’s certificate.

This proposal builds a distributed PKI based on DNS.  If you want to call me in the domain, you will be able to get my certificate chain from DNS and set up a secure and trusted session. The current PKI model used in the web delivers encryption – but few bothers with checking identity of the other end, check if the certificate chain is trusted or even if a certificate is revoked.

In SIP, we can do better and really kick off DANE. I will work on this and write more as I make progress in trying to understand the details.

For many years I have believed that DNSsec is a platform that will change the trust model on the net. Now, the light is on the ICANN, IANA and the TLD registries. Will they earn our trust?  Will they be better than the current set of web CAs that someone else approved for all of us? If not, we will have to start building a distributed trustworthy root soon. The technology is getting there, so the focus needs to move to the people and organizations that will be the new platform. These are interesting times. Let’s start discussing SIPdane and get a few implementations running soon!

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!


FOSS Stockholm is a group of Open Source developers, users, advocates and fans that meet and talk about various Open Source related issues. Today we had a lot of good talks on Open Source in development countries and it’s affect on democracy, about Open Source project management and other interesting topics. I had a quick overview of realtime communication security in order to stimulate a discussion. The slides are now published on Slideshare.

Realtime communication security – SIP, XMPP and others

View more presentations from Olle E Johansson.

The Session Initiation Protocol was developed in the 21st century. RFC 3261 is dated June 2002. In this time, network and Internet security was nothing new. Still, this is the year 2011 and most phones and servers still lack important security features. It’s not a lack of security technology and solution proposals that is the problem. It’s a lack of requirements from the market. And two paradigms that yet again meet – the netheads and the bellheads. In this article, I will try to give you an overview of the issues at hand without going to far into all the technichal details. (more…)

Building services in Asterisk is about combining a lot of small services into larger building blocks. The Asterisk platform provides you with a large set of functions, like calling out, answering, recording, playing prompts and listening for DTMF. In combination with simple logic control statements – much like any other programming language, you can use these to build complex services. Asterisk very much follow the design principles behind the UNIX operating system – small building blocks combined with a script language may build very complex larger services.

The dial plan language gets more powerful for every release

During the years, the possibilities in the dialplan have been expanded. The language have gotten a lot of new constructs and both functions and applications.  I can admit that the language is not the best of languages, but it performs the job. Compared with Asterisk 1.0 the need for using an external language in AGI is much lower with Asterisk 1.8. Thew is one big roadblock that breaks the design – voicemail.

Asterisk Voicemail is a large monolithic roadblock

The Asterisk voicemail application does not follow this design. It has built-in menus you can not change. It has built-in assumptions on how you want to handle your voicemail that you can not change. It has built-in accounts that is not very adaptable or easy to fit in with your LDAP architecture.Many people have private versions of voicemail – either hardcoded changes to the app_voicemail.c source code or something they wrote in the dial plan. A few years ago I started my own voicemail system for a customer who just needed a small voicemail-to-email solution – mini voicemail. It was a bad name, it should have been named voicemailblocks.

VM-blocks – the tools you need to build voicemail solutions

The idea was to build a series of voicemail building blocks that anyone could use to build larger customized voicemail solutions. I still think it is a good idea. After I developed the original code, channel data stores was added to Asterisk, which should make it much more easy to build the rest of these blocks. A vm-block channel data store can keep all the data about a voicemail account in memory that can be shared by the different dial plan applications.I hope that someone in the Asterisk community agrees with these ideas and continue coding on this. The first blocks are part of Asterisk 1.8. Let’s hope we get a more complete system for 1.10. If you are interested, I am open for discussion so we can agree on the blocks we need.

Asterisk was originally built as a stand-alone system, a single central point for all telephony communication. In short, a PBX. Nowadays, the Asterisk Open Source telephony server, is used in many ways – many of them not really being PBXs. All kinds of applications are being powered by Asterisk.While building applications with Asterisk, you soon realize that you’re limited to that single server. It’s hard to scale and one limiting factor is that the call state is being held in one server. Many services depend on call states – if an agent in a call center is busy, you need to find an available agent. If a trunk to the PSTN is in use, you might want to find another way out. Call states are important.Of course, the Asterisk project is now working on the long term solution, the Asterisk SCF and the applications that will be built using this framework. But that will take some time. Meanwhile, the Asterisk PBX team has been working on a few ways to distribute the call states between a group of servers. This article will describe a few of the different architectures being worked on. (more…)

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!

« Previous PageNext Page »