Published online 20 August 2009 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/dac.1040
An effective IPv4–IPv6 translation mechanism for SIP applications
in next generation networks
Whai-En Chen
1,∗,†, Ya-Lin Huang
2and Yi-Bing Lin
21Institute of Computer Science and Information Engineering, National Ilan University, Ilan, Taiwan 2Department of Computer Science, National Chaio Tung University, Hsinchu, Taiwan
SUMMARY
In a next generation network, the IPv6-enabled IP multimedia subsystem (IMS) network may connect to an IPv4 network. When an IPv4/IPv6 dual-stack user equipment (UE) initiates a call by sending an IPv6 SIP INVITE message to an IPv4-only user agent (UA), the call cannot be established correctly. To resolve this problem, the IMS-application layer gateway solution, the redirect solution, and the interactive connectivity establishment solution have been proposed. In this paper, we propose an effective solution where only the IPv6 INVITE message is translated into an IPv4 INVITE message. Upon receipt of the IPv4 200 OK message replied from the IPv4-only UA, the dual-stack UE learns that the correspondent UA supports IPv4-only and utilizes IPv4 instead of IPv6 to send the subsequent SIP messages and real-time transport protocol (RTP) packets. The proposed solution is compared with the existing solutions in terms of network node modification, call setup complexity, and RTP transmission latency. Our study indicates that the proposed solution outperforms the other three solutions in the call setup and the RTP transmission. Copyrightq 2009 John Wiley & Sons, Ltd.
Received 5 February 2009; Revised 25 April 2009; Accepted 22 May 2009 KEY WORDS: ICE; IMS-ALG; IPv4/IPv6 interworking; RTP; SIP; VoIP
1. INTRODUCTION
In a next generation network (NGN), IP multimedia subsystem (IMS) is adapted to provide various telecommunication and multimedia services such as voice over IP (VoIP). In the current stage of IPv6 deployment, the IPv6-enabled IMS network may connect to an IPv4 network. In addition, session initiation protocol (SIP)[1] is used in IMS as the signaling protocol in VoIP services for establishing calls, where the voice and the multimedia data (e.g. video) are typically transmitted using real-time transport protocol (RTP) [2]. The details of the voice and the multimedia data (e.g. the data type, the media codec, and the IP address/port number that the data should be sent
∗Correspondence to: Whai-En Chen, Institute of Computer Science and Information Engineering, National Ilan
University, Ilan, Taiwan.
to) are carried in the SIP message body in the format of session description protocol (SDP)[3]. When an IMS user equipment (UE) with both IPv4 and IPv6 protocol stacks (i.e. an IPv4/IPv6 dual-stack UE) initiates a call by sending an IPv6 SIP INVITE message to a SIP user agent (UA) that supports IPv4 only (IPv4-only UA), the call is not established correctly. For example, the IPv4-only UA may ignore the IPv6 INVITE message because it is unable to process SIP messages that contain IPv6 addresses. Furthermore, the IPv4-only UA cannot send the RTP packets to the IPv4/IPv6 dual-stack UE because the destination of the RTP packets resides in the IPv6 network. That is, IPv6 network is unreachable for an IPv4 host.
To resolve this problem, three solutions have been proposed in the literature, including the IMS-application layer gateway (ALG) solution[4], the Redirect solution [5], and the interactive connectivity establishment (ICE) solution[6]. These three solutions are described in Section 2. We propose an effective solution in Section 3 and evaluate these four solutions in terms of network node modification, call setup complexity, and RTP transmission latency in Section 4. The readers who would like to understand the detailed operations of normal IMS can refer to[7].
2. EXISTING SOLUTIONS
The IPv4/IPv6 interworking environment for SIP-based VoIP is illustrated in Figure 1. The calling party (UE; see Figure 1 (1)) is an IPv4/IPv6 dual-stack UE. The called party (UA; see Figure 1 (2)) is an IPv4-only UA. An IPv4/IPv6 dual-stack call session control function (CSCF; see Figure 1 (3)) can be viewed as a SIP server supporting a registrar and proxy. A transition gateway (TrGW; Figure 1 (4)) is responsible for translating IPv4 RTP packets to IPv6 RTP packets, and vice versa. Similarly, an IMS-ALG (Figure 1 (5)) is responsible for translating SIP messages. For the three solutions described in this section (the IMS-ALG solution, the Redirect solution, and the ICE solution), the CSCF is required for all solutions while the TrGW and IMS-ALG are used in the IMS-ALG solution only. Without loss of generality, we assume that both UE and UA register their contact information at the CSCF in all solutions.
Consider the SIP registration message flow in Figure 2 where UE’s IPv4/IPv6 addresses are 140.113.1.1 and 2001:f18:113::1. UA’s IPv4 address is 140.113.1.2. The CSCF’s IPv4/IPv6 addresses are 140.113.1.10 and 2001:f18:113::10, respectively.
In the registration procedure, UE first sends an IPv6 SIP REGISTER message to the CSCF with both its IPv6 and IPv4 contact information filled in two separate Contact header fields (Step 1 in
IP Connectivity Access Network (5) IMS-ALG (3) CSCF (4) TrGW IPv4 Network (IPv4/IPv6 Network) (1) UE (2) UA SIP RTP
A U F C S C E U (140.113.1.1/2001:f18:113::1) (140.113.1.10/2001:f18:113::10) (140.113.1.2) 1. REGISTER (IPv6) Contact: <sip:UE1@[2001:f18:113::1]:5060> Contact: <sip:[email protected]:5060> 2. 200 OK (IPv6) Contact: <sip:UE1@[2001:f18:113::1]:5060> Contact: <sip:[email protected]:5060>
User Contact Information (Empty) Registration Database
User Contact Information UE1 [2001:f18:113::1]:5060 Registration Database UE1 140.113.1.1:5060 3. REGISTER (IPv4) Contact: <sip:[email protected]:5060> 4. 200 OK (IPv4) Contact: <sip:[email protected]:5060> User Contact Information
UE1 [2001:f18:113::1]:5060 Registration Database
UE1 140.113.1.1:5060 UE2 140.113.1.2:5060
Figure 2. SIP registration message flow.
UE (with IMS-ALG function)CSCF TrGW UA
1. INVITE (IPv6) Create Address Mapping 2. INVITE (IPv4) 3. 200 OK (IPv4)
4. 200 OK (IPv6) 5. ACK (IPv6)
Create Address Mapping
6. ACK (IPv 4)
RTP Stream (IPv6) RTP Stream (IPv4)
Figure 3. Message flow for the IMS-ALG solution.
Figure 2). The CSCF then stores the contact information in its registrar database and replies an IPv6 SIP 200 OK message indicating that the registration is successful (Step 2 in Figure 2). UA performs a similar procedure to register its IPv4 contact information (Steps 3 and 4 in Figure 2). After registration, UE and UA can be reached through the CSCF. Furthermore, we assume that when UE initiates a call, it always attempts to send an IPv6 SIP INVITE message[8, 9].
2.1. The IMS-ALG solution
In the IMS-ALG solution[4, 10, 11], the CSCF equipped with the IMS-ALG function cooperates with the TrGW to translate SIP/RTP packets delivered between UE and UA. The call setup procedure is illustrated in Figure 3 with the following steps.
Step 1. UE sends an IPv6 SIP INVITE message to UA through the CSCF.
Step 2. Upon receipt of the INVITE message, the CSCF retrieves UE’s IP address from the Contact header field of the INVITE message and UA’s IP address from the CSCF’s registrar database. The CSCF then compares the versions of UE’s and UA’s IP addresses. This action is called IP version comparison. In this example, the versions of UE’s and UA’s IP addresses are IPv6 and IPv4, respectively. To establish the call without changing the IP version that UE chooses for the call, the IMS-ALG translates the SIP messages for this call setup. For the INVITE message, UE’s IPv6 address in the Via and the Contact header fields is replaced by the CSCF’s IPv4 address. In addition, UE’s IPv6 address and port number in the SDP c and m fields are passed to the TrGW to build an IP/port mapping for forwarding the RTP packets from UA to UE. The TrGW returns its IPv4 address and an unused port number to the CSCF for modifying the SDP c/m fields. After translation, the revised IPv4 INVITE message is then forwarded to UA.
Step 3. Upon receipt of the INVITE message, UA retrieves the Via header field in the INVITE message, which indicates the SIP nodes visited by the INVITE message. When UA accepts the call, an IPv4 SIP 200 OK message with the retrieved Via header field is created. The IPv4 200 OK message is then sent to the CSCF according to the Via header field.
Step 4. Upon receipt of the 200 OK message, the IMS-ALG replaces its IPv4 address in the Via header field by UE’s IPv6 address. In addition, UA’s IPv4 address in the Contact header field is replaced by the CSCF’s IPv6 address. Similar to the description in Step 2, the IMS-ALG passes UA’s IPv4 address and port number in the SDP c/m fields to the TrGW to build an IP/port mapping for forwarding the RTP packets from UE to UA. Then the IMS-ALG modifies the SDP c/m fields by using the TrGW’s IPv6 address and the port number that are returned from the TrGW. According to the Via header field, the IPv6 200 OK message is forwarded to UE.
Steps 5 and 6. When UE receives the 200 OK message, it replies an IPv6 SIP ACK message. The IMS-ALG replaces UE’s IPv6 address in the Via and the Contact header fields by the CSCF’s IPv4 address and forwards the IPv4 ACK message to UA.
After the call is established, UE sends IPv6 RTP packets to UA through the TrGW. The TrGW translates these packets into IPv4 RTP packets and forwards them to UA. Similarly, the IPv4 RTP packets from UA are translated into IPv6 RTP packets and then forwarded to UE by the TrGW.
2.2. The Redirect solution
In the Redirect solution[5], upon receipt of the IPv6 INVITE message from UE, the CSCF informs UE to set up the call to UA through IPv4. The call setup procedure in Figure 4 is described as below.
Step 1. UE sends an IPv6 SIP INVITE message to UA through the CSCF.
Step 2. Upon receipt of the INVITE message, the CSCF performs IP version comparison. Since the versions of UE’s and UA’s IP addresses are different, the CSCF sends an IPv6 302 Move Temporarily message to UE to indicate that IPv4 should be used for call setup.
Step 3. UE learns that UA is in the IPv4 domain and replies an IPv6 ACK message to the CSCF. Step 4. UE sends an IPv4 SIP INVITE message to UA through the CSCF.
Steps 5 and 6. UA accepts the call and sends an IPv4 200 OK message to UE through the CSCF. UE then replies an IPv4 ACK message.
UE (with redirect function)CSCF UA 1. INVITE (IPv6)
2. 302 Move Temporarily (IPv6) 3. ACK (IPv6) 4. INVITE (IPv4) 5. 200 OK (IPv4) 6. ACK (IPv6) 4. INVITE (IPv4) 5. 200 OK (IPv4) 6. ACK (IPv6) RTP Stream (IPv4)
Figure 4. Message flow for the Redirect solution.
Figure 5. Message flow for the ICE solution.
2.3. The ICE solution
In the ICE solution[6], UE and UA are responsible for selecting an appropriate IP version for RTP packet delivery. The CSCF 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 IP addresses in these SIP messages are not modified by the CSCF except that the CSCF will add an extra Via header field containing its IPv4 address to the INVITE message (so that UA can route back the 200 OK message). The call setup procedure (see Figure 5) is described in the following steps.
Step 1. UE sends an IPv6 SIP INVITE message to UA through the CSCF. In addition to its IPv6 address, UE includes its IPv4 address in the SDP c/m fields. Upon receipt of the INVITE message, the CSCF retrieves UA’s IP address from its registrar database and learns that UA supports IPv4 only. The CSCF encapsulates the INVITE message in an IPv4 packet and forwards it to UA.
Step 2. When UA receives the INVITE message, the Via header fields are retrieved (to be used for creating a subsequent 200 OK message). In addition, UE’s IPv4 address in the SDP c field is retrieved (to be used in Step 6). Since UA supports IPv4 only, other IPv6 addresses in the message are ignored. UA then creates an IPv4 200 OK message with retrieved Via header fields and includes its IPv4 address in the SDP c field. The 200 OK message is sent to the CSCF in an IPv4 packet. The CSCF then forwards the 200 OK message to UE in an IPv6 packet.
Step 3. After receiving the 200 OK message, UE retrieves UA’s IPv4 address from the SDP c field (to be used in Step 4) and replies an IPv6 ACK message. Similar to the INVITE message, the ACK message is sent to the CSCF in an IPv6 packet and then forwarded to UA in an IPv4 packet by the CSCF.
Unlike the IMS-ALG and the Redirect solutions, the IP addresses 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 performed before UE and UA send the RTP packets to each other. Connectivity check utilizes simple traversal of user datagram protocol through network address translators (STUN) Binding Request and Response messages. Suppose that UE’s IPv4 address is X and UA’s IPv4 address is Y. The connectivity check procedure (see Steps 4–7 in Figure 5) is described as follows.
Step 4. To confirm that Y can be used for RTP packet delivery, UE sends UA a STUN Binding Request message carried by an IP packet with source X and destination Y.
Step 5. Upon receipt of the Binding Request message, UA replies a STUN Binding Response message with source Y and destination X. When UE receives this message, it confirms that RTP packets with source X and destination Y can be sent to UA.
Steps 6 and 7. UA performs similar procedure to confirm that X can be used for RTP packet delivery.
After the connectivity checks, IPv4 RTP packets are delivered between UE and UA.
3. THE CSCF-TRANSLATION SOLUTION
The solutions discussed in the previous section have some disadvantages. In the IMS-ALG solution, all RTP packets need to be translated at the TrGW. Therefore, the RTP transmission delay, jitter, and packet loss may increase. For the Redirect and the ICE solutions, the call setup latency increases due to extra SIP/STUN message exchange for call setup. In this section, we propose a solution that neither requires the TrGW nor incurs extra call setup messages.
In the CSCF-Translation solution, the CSCF translates the SIP INVITE message based on the contact information stored in the CSCF’s registrar database, and UE learns from the 200 OK message that UA resides in the IPv4 domain. The call setup procedure in Figure 6 is described as follows.
Step 1. UE sends an IPv6 SIP INVITE message to UA through the CSCF. Suppose that the port number filled in the SDP description is Z. UE prepares to use its IPv6 address with port Z for sending/receiving RTP packets. In addition, UE prepares to use its IPv4 address with port Z for RTP in case UA supports IPv4 only.
UE (with SIP/SDP translation function)CSCF UA 1. INVITE (IPv6) 2. 200 OK (IPv4) 3. ACK (IPv4) 1. INVITE (IPv4) 2. 200 OK (IPv4) 3. ACK4 (IPv4) RTP Stream (IPv4)
Figure 6. Message flow for CSCF-Translation solution.
Step 2. When the CSCF receives the INVITE message, it performs IP version comparison. Since the versions of UE’s and UA’s IP addresses are different, the CSCF translates the INVITE message into an IPv4 SIP INVITE message. Specifically, the CSCF retrieves UE’s IPv4 contact information from its registrar database. It then replaces UE’s IPv6 contact information in the Via and the Contact header fields with UE’s IPv4 contact information. In addition, UE’s IPv6 address in the SDP c field is replaced with UE’s IPv4 address. However, the port number in the SDP m field is left unchanged. The translated IPv4 INVITE message is then sent to UA.
Step 3. When UA receives the INVITE message, it accepts the call by sending an IPv4 200 OK message to UE through the CSCF.
Step 4. Upon receipt of the 200 OK message, UE learns that UA is in the IPv4 domain. Therefore, an IPv4 ACK message is sent to UA through the CSCF, and UE chooses its IPv4 address with port Z (mentioned in Step 1) for sending/receiving RTP packets.
After the call is established, IPv4 RTP packets are delivered between UE and UA.
4. COMPARISONS
In this section, the four solutions discussed in this paper are compared with several aspects listed in Table I and described as follows.
UE modification: In the IMS-ALG solution, standard SIP UEs are used without modification. In the Redirect solution, the calling party is equipped with the redirect function from IPv6 to IPv4. The called party does not require any modification. In the ICE solution, both the calling and the called parties support ICE. In addition, the called party should be able to process the SIP messages that contain IPv6 addresses. In the CSCF-Translation solution, the calling party needs to select the IP version for RTP based on the 200 OK message sent from the called party. No modification is made to the called party.
CSCF modification: In the IMS-ALG solution, the CSCF is equipped with IP version comparison function and IMS-ALG. In the Redirect solution, the CSCF needs to perform IP version comparison and to act as a redirect server. In the ICE solution, the CSCF encapsulates the SIP messages in IPv4 or IPv6 packets based on the destination of the SIP messages, which is determined according to the standard SIP message processing procedure. In the CSCF-Translation solution, the CSCF performs IP version comparison and translates the IPv6 INVITE message into an IPv4 INVITE message based on the calling party’s contact information.
Table I. Comparison of the IPv4/IPv6 interworking solutions for SIP-based VoIP.
SIP UE CSCF Call setup RTP
Solutions modification modification complexity transmission latency
IMS-ALG Calling party: No Significant 6 messages with 3 translations High Called party: No
Redirect Calling party: Yes Medium 9 messages Low
Called party: No
ICE Calling party: Yes Medium 10 messages Low
Called party: Yes
CSCF-Translation Calling party: Yes Minor 6 messages with 1 translation Low Called party: No
Call setup complexity: Compared with the standard SIP call setup procedure, the IMS-ALG solution incurs additional call setup overhead for the SIP message translation (between IPv6 and IPv4) performed at the CSCF. The Redirect solution requires an extra INVITE transaction (including INVITE, 302 Move Temporarily, and ACK messages). In the ICE solution, extra call setup overhead is introduced to carry out the connectivity checks. In the CSCF-Translation solution, the SIP proxy needs to translate the first IPv6 INVITE message into an IPv4 INVITE message.
RTP transmission latency: In the IMS-ALG solution, the RTP packets are delivered between the call parties indirectly through the TrGW. In other solutions, the RTP packets are directly delivered between the call parties. We have conducted experiments to measure the extra RTP transmission delay introduced by the TrGW. In our experiments, the TrGW is a PC (with an Intel Pentium 4 3.0 GHz CPU and 1.0 GB main memory) installed with the RTP Proxy[12] on Linux operating system. The TrGW has two interfaces and each interface connects to an IP network through 100 Mbps Ethernet. During the experiments, RTP packets are injected to one interface of the TrGW at the rate of 10 Mbps (without loss), and the RTP packets translated by the TrGW are received from the other interface of the TrGW. Each of the RTP packets contains 20 ms voice data encoded in G.711 (172 bytes in length). The average latency of translating an RTP packet is 5.9 ms. The extra delay is more than twice the network latency in most cases we investigated. For example, the network latency from National Chiao Tung University to ArtDio VoIP operator (passing through 7 routers) is 2.012 ms in average. Therefore, the RTP transmission latency in the IMS-ALG solution is about 6–8 ms more than that in other solutions.
5. CONCLUSIONS
This paper utilized VoIP as an example to describe three existing IPv4/IPv6 interworking solu-tions for the SIP-based NGN telecommunication services: the IMS-ALG solution, the Redirect solution, and the ICE solution. Then we proposed a CSCF-Translation solution and compared the new approach with the three existing solutions. Our study indicated that the RTP transmission performance in the IMS-ALG solution is worse than the other three solutions. Both the Redirect solution and the ICE solution introduce extra call setup messages with extra call setup overhead. In the CSCF-Translation solution, the least extra call setup overhead is introduced, and no impairment is incurred to the RTP transmission performance.
REFERENCES
1. Rosenberg J, Schulzrinne H, Camarillo G, Johnston A, Peterson J, Sparks R, Handley M, Schooler E. SIP: session initiation protocol. RFC 3261, IETF, June 2002.
2. Schulzrinne H, Casner S, Frederick R, Jacobson V. RTP: a transport protocol for real-time applications. RFC 3550, IETF, July 2003.
3. Handley M, Jacobson V, Perkins C. SDP: session description protocol. RFC 4566, IETF, July 2006.
4. Sisalem D, Fiedler J, Ruppelt R. SIP and IPv6: why and how. SAINT2003, Orlando, Fl, U.S.A., January 2003, 27–31.
5. Mulahusic J, Persson H. SIP issues in dual-stack environments. Internet-Draft, February 2003. Draft-persson-sipping-sip-issues-dual-stack-00.2003.
6. Rosenberg J. Interactive connectivity establishment (ICE): a protocol for network addresstranslator (NAT) traversal for offer/answer protocols. Internet-Draft, October 2007. Draft-ietf-mmusic-ice-19.
7. 3GPP. 3rd generation partnership project; technical specification group services and systems aspects; signalling flows for the ip multimedia call control based on session initiation protocol (SIP) and session description protocol (SDP) Stage 3. Technical Specification 3G TS 24.228 version 5.15.0, October 2006.
8. Shin M-K, Hong Y-G, Hagino J, Savola P, Castro EM. Application aspects of IPv6 transition. RFC 4038, IETF, March 2005.
9. Castro EM, Miguel T, Pavon S. Transition of applications to IPv6. Upgrade Journal 2005; 6(2):15–18. 10. Chen W-E, Lin Y-B, Pang A-C. An IPv4–IPv6 translation mechanism for SIP overlay network in UMTS All-IP
environment. IEEE Journal of Selected Areas in Communications(J-SAC) 2005; 23(11):2152–2160.
11. Chen W-E, Wu Q, Lin Y-B. Design of SIP application level gateway for IPv6 translation. Journal of Internet Technology(JIT) Special Issue on IPv6 2004; 5(2):343–348.
12. RTPProxy-RTP (Real-time Transport Protocol) Proxy Server. Available from: http://ftp.iptel.org/pub/rtpproxy/.
AUTHORS’ BIOGRAPHIES
Whai-En Chen received a Bachelor of Science degree in Electric Engineering from Tam Kang University in 1997, and received a PhD in Computer Science from National Tsing Hua University in 2002. He began serving as a Research Assistant Professor in National Chiao Tung University from 2002 to 2007. Since August 2007, Dr Chen is serving as an assistant professor in the Institute of Computer Science and Information Engineering (CSIE) and as the director in the network division of the computer and IT center in National Ilan University. Since September 2008, he is the the chair of the Institute of CSIE. His research interests include 3G IP Multimedia Subsystem (IMS), SIP-based VoIP services, IPv6 translation mechanisms, IEEE 802.16 WiMAX MAC.
Ya-Lin Huang received the BS and MS degrees from the National Chiao Tung University (NCTU), Hsinchu, Taiwan, R. O. C., in 2005 and 2007, respectively. Her research interests include VoIP and IPv6.
Yi-Bing Lin is the Dean and Chair professor of the College of Computer Science, National Chiao Tung University (NCTU). He is a senior technical editor of IEEE NETWORK. He serves on the editorial boards of IEEE TRANSACTIONS ON WIRE-LESS COMMUNICATIONS and IEEE Transactions on Vehicular Technology. He is the General or Program Chair for prestigious conferences including ACM MobiCom 2002. He is the Guest Editor for several first-class journals including IEEE TRANS-ACTIONS ON COMPUTERS. Lin is the author of the books Wireless and Mobile Network Architecture (Wiley, 2001), Wireless and Mobile All-IP Networks (John Wiley, 2005), and Charging for Mobile All-IP Telecommunications (Wiley, 2008). Lin is listed in ISI-HighlyCited.Com among the top 1% most-cited Computer Science researchers. He received numerous research awards including 2005 NSC Distinguished Researcher and 2006 Academic Award of Ministry of Education. Lin is an ACM Fellow, an AAAS Fellow, and an IET Fellow.
