The Redirect Solution

In the Redirect solution [17], upon receipt of the IPv6 SIP INVITE message from UA1, the SIP server informs UA1 to set up the call to UA2 through IPv4. The call setup procedure in Figure 3.4 is described as follows.

Step 1. UA1 sends an IPv6 SIP INVITE message to UA2 through the SIP server.

Step 2. Upon receipt of the INVITE message, the SIP server performs IP version com-parison. Since the versions of UA1’s and UA2’s IP addresses are different, the SIP

server sends an IPv6 302 Moved Temporarily message to UA1 to indicate that IPv4 should be used for call setup.

Step 3. UA1 learns that UA2 is in the IPv4 domain and replies an IPv6 ACK message to the SIP server.

Step 4. UA1 sends an IPv4 SIP INVITE message to UA2 through the SIP server.

Steps 5 and 6. UA2 accepts the call and sends an IPv4 200 OK message to UA1 through the SIP server. UA1 then replies an IPv4 ACK message.

The call is established, and IPv4 RTP packets are delivered between UA1 and UA2.

3.3 The ICE Solution

In the ICE solution [19], UA1 and UA2 are responsible for selecting an appropriate IP version for RTP packet delivery. The SIP server translates the IPv4 packets (at the IP layer) that carry the SIP messages (at the application layer) to IPv6 packets, and vice versa. However, the transport addresses in these SIP messages are not modified by the SIP server except that the SIP server will add to the INVITE message an extra Via header field containing its IPv4 transport address for SIP (so that UA2 can route back the 200 OK message). The call setup procedure (see Figure 3.5) is described in the following steps.

Step 1. UA1 sends an IPv6 SIP INVITE message to UA2 through the SIP server. In addition to its IPv6 transport address for RTP, UA1 includes its IPv4 transport address for RTP in the SDP description. Upon receipt of the INVITE message, the SIP server retrieves UA2’s contact information from its registrar database and learns that UA2 supports IPv4 only. The SIP server then encapsulates the INVITE message in an IPv4 packet and forwards it to UA2.

Step 2. When UA2 receives the INVITE message, the Via header fields are retrieved (to be used for creating a subsequent 200 OK message). In addition, UA1’s IPv4 transport address for RTP in the SDP description is retrieved (to be used in Step 6).

UA1

1. INVITE (IPv6)

UA2 SIP Server

1. INVITE* (IPv4) 2. 200 OK (IPv4) 2. 200 OK* (IPv6)

3. ACK (IPv6)

3. ACK* (IPv4) 4. STUN Binding Request (IPv4)

5. STUN Binding Response (IPv4) 6. STUN Binding Request (IPv4) 7. STUN Binding Response (IPv4)

RTP Stream (IPv4)

The IP packets that carry the INVITE and the ACK messages are changed to the IPv4 format. On the other hand, the transport addresses filled by UA1 in the carried messages are not changed by the SIP server. Similarly, the IP packet that carries the 200 OK message is changed to the IPv6 format, but UA2's IPv4 transport address in the 200 OK message is not changed.

Call Setup

Connectivity Check

*

Figure 3.5: IPv4/IPv6 Interworking for SIP-based VoIP: the ICE Solution

Since UA2 supports IPv4 only, other IPv6 transport addresses in the message are ignored. UA2 then creates an IPv4 200 OK message with the retrieved Via header fields and includes its IPv4 transport address for RTP in the SDP description. The 200 OK message is sent to the SIP server in an IPv4 packet. The SIP server then forwards the 200 OK message to UA1 in an IPv6 packet.

Step 3. After receiving the 200 OK message, UA1 retrieves UA2’s IPv4 transport address for RTP from the SDP description (to be used in Step 4) and replies an IPv6 ACK message. Similar to the INVITE message, the ACK message is sent to the SIP server in an IPv6 packet and then forwarded to UA2 in an IPv4 packet by the SIP server.

Unlike the SIP-ALG and the Redirect solutions, the source/destination transport ad-dresses for RTP packet delivery are not confirmed in the ICE-based call setup procedure (Steps 1–3). Instead, they are confirmed after the connectivity checks, which are per-formed before UA1 and UA2 send the RTP packets to each other. The connectivity checks utilize STUN Binding Request/Response messages. Suppose that UA1’s IPv4 transport address for RTP is X and UA2’s IPv4 transport address for RTP is Y. The

1. INVITE (IPv6)

2. INVITE (IPv4) 3. 200 OK (IPv4) 3. 200 OK (IPv4)

4. ACK (IPv4)

4. ACK (IPv4)

UA1 SIP Server UA2

RTP Stream (IPv4)

Figure 3.6: IPv4/IPv6 Interworking for SIP-based VoIP: Our Solution

connectivity check procedure (see Steps 4–7 in Figure 3.5) is described as follows.

Step 4. To confirm that Y can be used for RTP packet delivery, UA1 sends UA2 a STUN Binding Request message with the source transport address X and the destination transport address Y.

Step 5. Upon receipt of the Binding Request message, UA2 replies a STUN Binding Response message with the source transport address Y and the destination transport address X. When UA1 receives this message, it confirms that the RTP packets with the source transport address X and the destination transport address Y can be sent to UA2.

Steps 6 and 7. UA2 performs similar procedure to confirm that X can be used for RTP packet delivery.

After the connectivity checks, IPv4 RTP packets are delivered between UA1 and UA2.