Speaking of Standards

Perfectly in time for my webinar on Thursday about IPv6 and SIP, the IETF has published RFC 6157 on “IPv6 Transition in the Session Initiation Protocol (SIP)“. You can get it here:

http://tools.ietf.org/html/rfc6157

Or at any of the other typical RFC repositories.

From the abstract:

This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered.

The authors of the document did an excellent job discussion both the signaling layer (using SIP) as well as the issues at the media layer. While SIP is obviously only about signaling, the SIP endpoints (user agents) need to be able to send and receive media streams as well… and ideally do all of that over IPv6.

Making the Transition

The great part about this document is that it is focused on the transition between IPv4 and IPv6 and all the thorny issues that lie in that space where you have some mixture of:

• IPv4-only clients
• IPv6-only clients
• IPv4 / IPv6 “dual stack” clients
• IPv4 / IPv6 “dual stack” clients without IPv6 connectivity

This last case is an interesting one. You could easily have a SIP softphone on a computer that has both IPv4 and IPv6 enabled. Just in the way IPv6 works, the computer will have a link-local IPv6 address and thus may appear to the softphone to have IPv6 connectivity. The softphone might therefore try to connect out over IPv6 until that eventually fails and the softphone falls back to IPv4. The delays introduced in this type of situation could be problematic.

Anyway, the document describes the different scenarios and the questions you need to be thinking about in each.

The ICE Problem

The one “issue” I have with the document is around how a SIP user agent sends along to the remote recipient the list of IP addresses (both IPv4 and IPv6) that it has.

The fundamental problem here is that within the SDP part of an INVITE, there can be only one IP address for a media stream. You can’t send both an IPv4 address and an IPv6 address. There is no SDP parameter for that. You can certainly add another section to the SDP, but now you are offering multiple media streams.

The solution promoted by folks within the IETF, and described here in RFC 6157 in section 4.2, is to use Interactive Connectivity Establishment (ICE), defined in RFC 5245. ICE is a robust yet somewhat complicated method for two SIP user agents to figure out what are the best IP addresses for them to use to communicate to each other. Basically each endpoint develops a list of potential IP addresses and then a series of “candidate pairs” are created, prioritized and attempted. At the end of the ICE process, one of those address pairs is chosen.

While much of the ICE document talks about using ICE so that SIP user agents can find their IPv4 addresses while behind firewalls, proxies, etc., ICE could certainly be used for gathering IPv4 and IPv6 address pairs and exchanging them.

Here’s the problem:

ICE is not widely deployed yet.

Given that, most SIP user agents today can’t really use ICE for negotiation. Now, the cynics may point out that IPv6 is also not widely deployed… so perhaps by the time IPv6 starts being more widely available, SIP endpoint / user agent vendors will have implemented ICE.

Perhaps. Perhaps not. Meanwhile the transition is hard without a widely deployed mechanism for dual-stack endpoints to easily communicate both their addresses.

I would note that there was an earlier mechanism called “Alternative Network Address Types (ANAT)” and defined in RFC 4091 and RFC 4092 that provided a simpler solution for passing both IPv4 and IPv6 addresses… but it was obsoleted by RFC 5245 when it was formally issued in April 2010. So ANAT is dead from a standards point-of-view.

Personally, I see this as one of the harder issues for SIP to deal with in an IPv4/IPv6 dual-stack world, and it’s not clear to me that simply mandating ICE is going to solve the problem.

A “Must-Read” Document

Regardless of the ICE issue, RFC 6157 truly is a “must-read” document for anyone working with SIP and curious about how SIP will work in an IPv6 world and more importantly in a IPv4/IPv6 world.

Kudos to the authors for getting this RFC out there… it’s definitely a helpful contribution as we look at how to move SIP communication to IPv6.

Related posts:

1. New Version of “Design Considerations for Session Initiation Protocol (SIP) Overload Control”
2. New release of “Media Server Control Protocol Requirements” – time to get your feedback in!
3. How to Test Your IPv6 Connection -> ipv6-test.com
4. How To Make SIP Calls Over IPv6 Using Linphone (on Mac, Windows, Linux)
5. New IPv6 Mailing List From SIP Forum For Discussing SIP/VoIP Issues With IPv6

Tags: IPv6, SIP

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.