The Third Generation Partnership Project (3GPP), which is responsible for the standardization of the third-generation mobile networks, has designated the session initiation protocol (SIP) as the call control protocol and Internet protocol version 6 (IPv6) as the only network protocol for 3G IP-based wireless networks. SIP is an application-layer control protocol used to initiate interactive user sessions involving multimedia elements in third-generation mobile networks. IPv6, a network layer protocol, is the new generation IP protocol, which is intended to replace IPv4 following a migration period. However, because the schedule for upgrading IPv4 to IPv6 is hard to predict, the issue of communication between legacy IPv4 and new IPv6 equipment must be solved. It is assumed that sessions between IPv4-only clients and IPv6-only 3G mobile terminals are needed and transition mechanisms are necessary to achieve inter-networking.

Exploration of such transition mechanisms started at the Ericsson Research Open System Lab in Montreal, in collaboration with Professor Bill Atwood and his graduate students from Concordia University. The idea was to provide a prototype solution based on Linux and open-source software.

In this article, we present a detailed solution for implementing a SIP audio communication between IPv6 endpoints based on the VOCAL system. We also demonstrate our implementation of an IPv4/v6-compatible SIP system on dual-stack Linux servers. As IPv4 and IPv6 will co-exist until a full migration to IPv6 takes place, a mechanism is needed that allows hosts in an IPv6-only network to talk to hosts in an IPv4-only network. We explore NAT-PT, which provides a solution for this scenario, and propose a DNS-ALG (DNS application level gateway) and a SIP-ALG (SIP application level gateway), which will be the subject of a follow up article in Linux Journal.

SIP is an application-layer control protocol that can establish, modify and terminate multimedia sessions, such as Internet telephony calls. SIP establishes sessions using the session description protocol (SDP), which is used to negotiate a set of compatible media types to be shared among participants. It also can invite participants to join existing sessions, such as multicast conferences.

SIP defines two distinct types of messages: requests and responses. A SIP message is either a request from a client to a server or a response from a server to a client. SIP requests can be sent directly from a user agent client to a user agent server, or they can traverse one or more proxy servers along the way (see Figure 1).

Figure 1. Sample scenario where SIP messages go through multiple SIP proxies before reaching their destinations.

User agents send requests either directly to the address indicated in the SIP uniform resource identifier (URI) or to a designated proxy (outbound proxy), independent of the destination address. The current destination address is carried in the request-URI. Each proxy can forward the request based on local policy and information contained in the SIP request.

Figure 2 illustrates an example of a SIP message exchange between two user agents running on two Linux nodes: Sauternes and Gamay. The setup is explained further in a later section and illustrated in Figure 3.

Figure 2. Establishment and termination of a SIP session between two user agents, one on Sauternes and the other on Gamay.

VOVIDA.org is a communications community Web site dedicated to providing a forum for open-source software used in datacom and telecom environments. The VOVIDA Open Communication Application Library (VOCAL) is an open-source project targeted at facilitating the adoption of VoIP in the marketplace. VOCAL provides the development community with software and tools needed to build new VoIP features, applications and services. The software in VOCAL includes a SIP-based Redirect Server, Feature Server, Provisioning Server and Marshal Proxy.

Both the SIPSet and VOCAL Servers now support IPv6. IPv4 and IPv6 are supported at the same time, with VOCAL being able to use both types of addresses. Provisioning currently requires valid IPv4 addresses, however.

In this article, we use the VOCAL implementation to demonstrate audio communications between two user agents running on IPv6 Linux servers. We describe how to set up the network, how to install and configure VOCAL and, finally, how to run and test it.

A minimal test setup requires three nodes: two nodes to establish communications and one node that act as an IPv6 router and DNS server (see Figure 3).

Figure 3. Network Setup

In order to achieve the desired setup presented in Figure 3, we need to follow three steps:

We explain each of these steps in the following sub-sections.

To build the Linux kernel with IPv6 support, please refer to the article "Supporting IPv6 on a Linux Server Node", which appeared in the August 2002 issue of Linux Journal. The article details supporting IPv6 in the Linux kernel and in the networking utilities.

In our setup, we used Apache version 2.0.39. For a detailed description of this procedure, please refer to a previous article titled "Apache Talking IPv6". The article covers installing and running Apache over IPv6.

An IPv6 DNS server is needed, as shown in Figure 2, to provide translation between domain names and IPv6 addresses. This was the subject of a previous article titled "Building an IPv6 Linux DNS Server Node". The article presents a tutorial on building an IPv6 DNS Linux server node that provides IPv6 name resolution as part of an IPv6 network. After following the steps in that article, you should be able to build your own DNS server that supports IPv6.

As far as supporting IPv6 routing, please refer to the IPv6 How-To of Peter Bieringer (see Resources). As this is not the purpose of this article, we are providing only pointers to be able to save the space for the VOCAL system.

There are three options for obtaining the VOCAL system from VOVIDA: RPMs, a tarball package that contains the source code or downloading directly from CVS. To obtain source code from CVS, check out the latest version of VOCAL system using the following commands:

In our case, we downloaded the latest source code package, vocal-1.4.0b.tar.gz, from the Web site.

The original SIP UA can build a voice communication device, but it lacks precise sound prompts, such as dial tone, ring and ring back. Thus, we needed to modify some sound card classes in the source tree to be able to support these sound prompts.

Before modifying the source code, extract the source code package:

To enable the sound prompts, first modify DupCardDevice and SoundCardDevice in vocal/sip/ua/UaDevice.cxx. DupCardDevice should be commented out and SoundCardDevice should be uncommented so it is included. Next, modify provideRingStart() in vocal/sip/ua/SoundCardDevice.cxx. To be able to get a ring-back after dialing, add one line:

After these modifications are completed, you are ready to compile and install the VOCAL system.

After you download VOCAL, uncompress the package and make the modifications noted above. You then are ready to compile and install all the VOCAL components:

Another alternative is to compile individual components, like this:

After compiling individual components, the configuration described below is not necessary; their corresponding binary files exist in the source tree. For instance, the binary file ua is located in vocal/sip/ua/bin.debug.Linux.i686/ after compiling.

The all-in-one VOCAL system means all (SIP) servers in the VOCAL system are running once the basic VOCAL dæmon vocald is invoked. The all-in-one system simplifies the procedures of running all servers separately.

To configure the all-in-one VOCAL system after compilation, run the following command:

You are prompted to answer a number of questions for which you should accept the default answers, except for the location of the Apache server. Be sure to specify your own directory here.

To verify the configuration of the all-in-one VOCAL system, run the following command:

If everything goes well, a message appears indicating the installation was successful.

After all-in-one configuration, the dæmon vocald runs automatically, which might cause some problems or conflicts. For instance, a UA is already running in memory, but we want to use our own UA. Therefore, the already-running dæmon should be shut down using the following command:

Because the all-in-one system needs an association with a Web server to manage all VOCAL servers, the Apache server should be run first. To start the Apache server and VOCAL dæmon, type:

The procedure for setting up a call with two default UA configuration files already configured for testing on the same machine is as follows:

Here is a sample IPv6 test scenario in which Sauternes calls Gamay with ua6 using Gamay's IPv6 address. Before starting, be sure to configure ua.cfg correctly for both hosts with the correct IPv6 address:

When porting to an IPv6-only VOCAL system, we had to do two tasks. First, we had to change the source code to recognize and process IPv6 addressees. Second, we had to convert data structures and function calls to recognize IPv6 addresses.

When changing the source code, we must consider that IPv4 addresses are 32 bits long, while IPv6 interfaces are identified by 128-bit addresses. IPv4 address uses dotted decimal format, such as 192.128.73.99:5060; following the colon is the port number. However, IPv6 address looks like fec0:0:0:1:250:b7ff:fe14:3617. The question is how to distinguish an IPv4 address with a port number from an IPv6 address with a port number. The solution we applied in the VOCAL system is to keep the format of the IPv4 address and to enclose the IPv6 address in a pair of brackets, [ ]. Following this, the format of an IPv6 address with a port number is now [fec0:0:0:1:250:b7ff:fe14:3617]:5060. Figure 4 illustrates the method to parse a SIP address in a IPv4-only VOCAL system.

Figure 4. Parsing IPv4 Addresses

As for parsing both IPv4 and IPv6 addresses, the method is shown in Figure 5.

Figure 5. Parsing IPv4 and IPv6 Addresses

The second part of porting VOCAL was to convert data structures and function calls. Because many address structures, socket structures and function calls support only IPv4, they must be changed to support IPv6. We summarize the most important changes in Figure 6.

Figure 6. Data structures and function calls that need to be modified for IPv6 support.

Based on the efforts of the VOVIDA community, we refined and modified the VOCAL system to obtain an IPv4-only SIP user agent, UA4, and an IPv6-only SIP user agent, UA6. UA4 and UA6 are binary executable files renamed from the binary file UA, which is generated from IPv4-only and IPv6-only VOCAL systems, respectively. Furthermore, we have tested all methods of direct call between two UAs.

There are two ways to make applications compatible with both IPv4 and IPv6. One method is to use AF-independent data structure and system calls (see Resources). The other method is to test which version of IP is present at runtime and then call appropriate system calls.

In implementing the VOCAL system, two important protocol-independent system calls have been widely used to update IPv4 supporting function calls. The two system calls are getaddrinfo() and getnameinfo(), and there are two reasons to choose them. First, using them together can achieve name resolution and can replace these system calls: gethostbyname(), gethostbyaddr(), inet_ntop(), inet_pton(), getservbyname() and getservbyport(). Second, they are protocol-independent because their return values can be used directly by other protocol-specific system calls, such as bind() and connect(), regardless of protocol families.

However, using these two system calls cannot completely implement Internet protocol compatibility. VOVIDA community has added a class, NetworkConfig, to guess the IPv4/IPv6 capabilities of the target host on its initialization. This class creates a flag to indicate which procedures address parsing classes, such as NetworkAddress and SipUrl, should perform concerning IPv6.

The VOCAL system has implemented a common system to be used over IPv4 and IPv6 since the 1.5.0-alpha version, although it is not stable yet at the time of this writing and there are some problems to be solved.

Typically, the full migration from IPv4 to IPv6 will not happen overnight and there will be a transition period in which IPv4 and IPv6 co-exist. For this reason, we have expanded the setup shown in Figure 3 to the setup illustrated in Figure 6. Bourgogne is a NAT-PT box sitting on the boundary between the IPv4 domain and the IPv6 domain. It has two network interface cards, each of them connecting to one IP domain. Moreover, NAT-PT is responsible for the functionality of DNS-ALG and SIP-ALG. IPv4 domain includes a DNS server and an IPv4 host, Macon. The IPv6 domain includes an IPv6 DNS server and an IPv6 host.

Figure 7. Communications Between IPv4 and IPv6 Domains through NAT-PT

Network Address Translation-Protocol Translation (NAT-PT) is an IPv4-to-IPv6 translation mechanism that attempts to provide transparent routing to end nodes in an IPv6 domain trying to communicate with endnodes in an IPv4 domain, and vice versa. NAT-PT allows native IPv6 hosts and applications to communicate with native IPv4 hosts and applications, and vice versa. A NAT-PT device resides on the boundary between an IPv4 and IPv6 network. It uses a pool of IPv4 addresses for assigning to IPv6 nodes dynamically, and this assignment is done when sessions are initiated across IPv4-IPv6 boundaries.

To implement address resolution, a DNS Application Level Gateway (DNS-ALG) must be employed in conjunction with NAT-PT. We currently are working on a project with Kedar C. Das (Concordia University) to research and develop this functionality for Linux.

SIP is an application layer control protocol for establishing media sessions. It encounters problems with NAT-like devices, because the payloads of SIP packets carry the addresses for the sessions to be established. The NAT function in NAT-PT is application-unaware and does not snoop the payloads. Along with NAT-PT and DNS-ALG, a SIP-ALG is needed on the boundary between the IPv4 and IPv6 domains.

A SIP packet is identified for the SIP-ALG by its destination port, 5060. The SIP-ALG must be able to modify the data in each packet traversing the IPv4/IPv6 boundary. The Via, From, To and Contact headers in a SIP packet must be modified according to the mapping stored in NAT-PT.

Because SIP messages carry the descriptions of media sessions by using SDP, the media session address and type that SDP carries must be translated when a SIP packet containing the SDP payload is traversing the IPv4/IPv6 boundary. The modification of the SDP payload probably changes the length of the SDP payload, so the Content-Length header of the SIP message must be modified accordingly.

At the time of writing, the stable release of VOCAL 1.5.0 was released, which includes many bug fixes, new features and security fixes. However, this does not change any of the installation steps illustrated in this article.

In a follow-up article, we plan to demonstrate how to ensure that SIP user agents between IPv4 domains and IPv6 stubs (Figure 7) can understand one another with the support of a NAT-PT Linux box, a DNS-ALG and a SIP-ALG.

VOCAL System

VOVIDA

IPv6 How-To

Linux Kernel

Mozilla Web Client

Apache Web Server

AF-independent Applications

RFC 3261

Open System Lab