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!