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.

IPv6 enabled, but not connected: There are many IPv6-enabled computers out there that are not really connected to the IPv6 Internet. If the interface has IPv6 enabled and the user surfs to an address with both IPv4 and IPv6 records, the browser normally tries to connect to the IPv6 address first (following RFC 3484). In some cases, the browser fails if this doesn’t work out. In other cases, the browser tries the IPv4 address and succeeds and gives the user the impression that “this is a slow web server”. IPv6 may also work, but run over a poor tunnel giving bad call quality.

Open two connections at the same time: There are many articles out there suggesting that web browsers should open two HTTP connections at the same time and stick with the first one that connects. This way, the browser will not be delayed by the failure of either address family. In SIP we can do this with TCP connections. It’s not as easy with UDP, but I guess it is doable. How a device that receives the same INVITE over UDP and TCP will react is not easy to say though. We need to experiment with this a bit more.

The server domain can give hints: As I see it there are actions here for both server and client. The client can  manage the connections better, be more aggressive and not wait for failure. The server administrator can arrange his SRV records to show preference (which will be the topic for another post) of one address family over another. The question here is if UAs will understand this or just fail?

Do not make any assumptions about IPv4 or IPv6 in your software: Hardcoding preference for any protocol just leads to bad software. If you want to add a preference between IPv4 and IPv6 in your software – let the user make the choice. Assuming that IPv6 is worse because people often use tunnels will break on the network where IPv6 actually gives more performance. With all the carrier-grade-nats that seems to be coming up, IPv4 performance will not be enhanced, quite the opposite.

Do not assume media and signalling in the same call will use the same address family. There are also issues with media handling. Even in IPv4, you can’t assume that the SIP server is the media endpoint. Now, you can’t assume that the media will follow the same path and use the same address family as the signalling. In fact, with new SDP constructs server and client can offer alternatives and ICE can propably be used to check which way that works best. I need to look into this more and so do you.

We should all work on this in order to make the transition as smooth as possible. It is important that the SIP world migrates to IPv6 and takes benefit of this new network without causing harm to the phone calls. 

More reading: