SIPitSIPit is one part of the SIP development. IETF develops new proposed standards and additions to existing standards – but they need to be tested for interoperability. Just writing documents is not enough. We need code and we need agreements that the standards actually work and deliver interoperability to the users. One implementation following the standards should be able to interoperate fully with another implementation of the same standards. If not, we have a huge problem.

The SIP Interoperability Testbed

SIPit is organized by the SIP forum and lead by Robert Sparks, one of the engineers in the IETF. Robert has organized 29 SIPit events around the world and the next one, SIPit 30, will be hosted by Cisco Systems in Raleigh-Durham, North Carolina, USA. At SIPit we test both the base SIP standard, as documented in RFC 3261, and the new additions, like SIP Outbound, SIP identity, GRUU and ICE. We have phones, proxys, conference bridges, session border controllers and all kinds of devices as well as SIP stacks under development. We have a gentleman’s agreement not to reveal anything else than generic test results. I can’t use Facebook and say “ha ha, Saul’s new SIP server sucks!“. This leads to a very open and helpful environment. We teach each other, wants everyone to succeed and learn a lot in the process.

Here’s a presentation with a few bullet points to explain to you and your employer why you need to register now! The company will earn on it, get a better product. You will learn more. See you at SIPit!


The benefit of open standards is that it put the customers in control. They can use any SIP-compatible phone with any SIP-compatible server. We can place calls between companies. We can freely choose a SIP PSTN-gateway service provider. There are no vendor lock-ins.

To reach this, a lot of work is needed. A lot of testing, code changes, discussions between developers and regular meetings as standards evolve. The SIP Forum, an organization for vendors that sell SIP based services or products, organizes SIPit events where developers meet to run tests, discuss standards and improve their products. The winners here are the customers. A result of SIPit is better interoperability between products, something that expands the market and makes it easier to integrate solutions from different vendors.

As a customer, please ask your vendor if they send teams to SIPit. That’s enough. There are no formal tests involved, no official test results that you can ask for. Participation means that a vendor is interested in interoperability, which is good for you.

Registration for the next SIPit in Monte Carlo, Monaco, is now open. It’s hosted by ETSI, an European Union standardization organization. If you develop SIP products – make sure you register now!

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.

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.

At SIPit26 we began setting up a series of automated self-tests for IPv6, like we’ve done previously with SIP/TLS. We also integrated IPv6 in as many multiparty tests as possible, to see how IPv4 and IPv6 lived together.Some notes and experiences:

  • IPv4-only applications will receive IPv6 in messaging. Even if an application DO NOT support IPv6-native connections, the application will surely get IPv6 addresses in various places in the message. In SIP, a call may traverse an IPv6 proxy before reaching your IPv4 proxy or phone. Via headers will have IPv6 and maybe a record-route header too. All user agents needs to support this. We had at least one crash in a proxy that failed to parse an IPv6 address.
  • Placing an IPv4 call to a proxy that forwards the message to an IPv6 phone without handling RTP traversal leads to issues as well. The phone gets an IPv6 address in the Contact: header and failes to send the ACK properly. This happened with Asterisk. Because of parsing failure, the parser gave up and sent ACKs and BYEs to the wrong address.
  • We did successfully set up calls between IPv6 user agents using IPv6 proxys. The failures happened in the mixed scenarious.
  • When placing a call to a domain that was configured with both A and AAAA records for the SRV records, but only one of them responding, we noticed long timeouts before failover, if that even happened. Many discussions about this followed, which lead to the conclusion that this was a poorly configured domain. Some implementations have hard-coded a preference for IPv4 since IPv6 is mostly used over tunnels and add latency today. This should be user-configurable. An owner of a domain can use SRV record weights to indicate a preference to one or the other protocols, which is a better solution. If you use IPv6 over tunnels, make sure that you separate host records for A and AAAA and have a preference towards the A record hosts in your SRV records.

We do need to continue testing all kinds of migration scenarious to  be able to come up with a best current practise document. SIPit26 gave us many good experiences to build from. I hope that testing continues at SIPit27 with the new SIPit IPv6-o-matic(R)(C)(TM) and the prompts from Allison Smith!