44% of SIP Implementations at SIPit 29 Supported IPv6!

Sipitlogo

Last week (Oct 24-27) was the 29th SIPit interoperability test event hosted by ETSI in Monaco. Organizer Robert Sparks has provided his usual outstanding summary of what occurred:

https://www.sipit.net/SIPit29_summary

The key point for me, given my new role, was right up at the top:

44% of the implementations present supported IPv6.

Now, of course ideally we’d like that to be 100%, but hey, it’s at least a good start!

There is also some narrative further down the report about “IPv6 Focused Tests” with some interesting info. One interesting note seems to be this:

Most UAs that supported dual-stack had a configuration to tell the application
to ignore any returned AAAAs due to issues encountered in deployments where
endpoints autoconfigured IPV6 that didn’t actually work.

In the web world this has been referred to as the “happy eyeballs” problem where a browser will try a DNS AAAA record to get to a site over IPv6 and then eventually will fail back to trying the A record to go over IPv4. The delay will cause the user to be very UNhappy. There are a couple of ways to address the issue with the usual one being to try both IPv6 and IPv4 addresses simultaneously and then connect over whichever one responds back first. (There is an entire “happy eyeballs” Internet-Draft that goes into this topic for those interested.)

From this simple sentence it would sound to me like the implementations are NOT supporting a “happy eyeballs” approach for SIP but are rather providing an “ignore IPv6” configuration setting. I wasn’t there so I don’t know… but I would hope that over time all dual-stack SIP implementations would move to supporting this kind of approach (versus disabling IPv6).

It was also good to see that tests occurred in a mixed environment:

We successfully tested
calls going though a mix of v4 and v6 hops (accruing Via and Route/Record-Route
headers with addresses in both families.

Wearing my security hat I was also pleased to see this:

80% of the endpoints present supported SRTP using sdes

Again, you’d love 100%, but at least this shows the availability of SRTP should companies decide to enable SRTP.

Lots of other great commentary in the SIPit 29 summary around STUN/TURN/ICE and many other issues. Definitely worth a read if you are interested in SIP.

And… if you a creator of SIP-related hardware and software, watch the SIPit website for news of the next SIPit event so that you, too, can join in the testing!

And if you have not heard of SIPit before, here’s a video I did back in September 2009 with organizer Robert Sparks:


If you found this post interesting or useful, please consider either:


3 thoughts on “44% of SIP Implementations at SIPit 29 Supported IPv6!

  1. Dan Wing

    Most UAs that supported dual-stack had a configuration to tell the application to ignore any returned AAAAs due to issues encountered in deployments where endpoints autoconfigured IPV6 that didn’t actually work.
    Wow, that won’t work well at all.
    RFC6157 is the answer for SIP. Nothing else will work reliably, especially the “send on IPv6 and pray” — that has been demonstrated on the Internet with the failures of IPv6 paths when IPv4 paths are working.

  2. Dan Wing

    Ah, sorry — SIP (signaling) itself was the problem. Unreal. http://tools.ietf.org/html/rfc5626 and some Happy Eyeballs. Or, just remove the “disable IPv6” feature and occasionally break the IPv6 path, and developers will find solutions…
    This same problem exists with XMPP clients where connections are made/broken to wired and wireless Ethernet. It’s been “solved”, for some value of “solved”.

Comments are closed.