Our Solution

In our solution, the SIP server translates the IPv6 SIP INVITE message based on the contact information stored in the SIP server’s registrar database, and UA1 learns from the 200 OK message that UA2 resides in the IPv4 domain. The call setup procedure in Figure 3.6 is described as follows.

Step 1. UA1 sends an IPv6 SIP INVITE message to UA2 through the SIP server. Sup-pose that the port number filled in the SDP description is Z. UA1 prepares to use

its IPv6 transport address (i.e., its IPv6 address and the port number Z) for send-ing/receiving RTP packets. Also, UA1 prepares to use its IPv4 transport address (i.e., its IPv4 address and the port number Z) for RTP in case UA2 supports IPv4 only.

Step 2. When the SIP server receives the INVITE message, it performs IP version com-parison. Since the versions of UA1’s and UA2’s IP addresses are different, the SIP server translates the INVITE message into an IPv4 SIP INVITE message that is the same as an IPv4 SIP INVITE message sent by UA1. Specifically, the SIP server retrieves UA1’s IPv4 contact information from its registrar database. It then re-places UA1’s IPv6 contact information in the Via and the Contact header fields by UA1’s IPv4 contact information. In addition, UA1’s IPv6 address in the SDP description is replaced by UA1’s IPv4 address. However, the port number in the SDP description is unchanged. The translated IPv4 INVITE message is then sent to UA2.

Step 3. When UA2 receives the INVITE message, it accepts the call by sending an IPv4 200 OK message to UA1 through the SIP server.

Step 4. Upon receipt of the 200 OK message, UA1 learns that UA2 is in the IPv4 domain.

Therefore, an IPv4 ACK message is sent to UA2 through the SIP server, and UA1 chooses its IPv4 transport address (i.e., its IPv4 address and the port number Z mentioned in Step 1) for sending/receiving RTP packets.

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

3.5 Comparisons

In this section, the four solutions discussed in this chapter are compared in several aspects listed in Table 3.1 and described as follows.

UA Modification: In the SIP-ALG solution, standard UAs are used. In the Redirect solution, the calling party is equipped with the redirect function from IPv6 to IPv4.

Table 3.1: Comparisons of the IPv4/IPv6 Interworking Solutions for SIP-based VoIP

Solution UA SIP Server Call Setup RTP Transmission Modification Modification Complexity Latency SIP-ALG Calling Party: No

Yes 6 Messages with Solution Called Party: No 3 Translations High Redirect Calling Party: Yes

Yes 9 Messages Low

Solution Called Party: No ICE Calling Party: Yes

No 10 Messages Low

Solution Called Party: Yes

Our Calling Party: Yes Yes 6 Messages with Low Solution Called Party: No 1 Translation

The called party does not require any modification. In the ICE solution, both the calling and the called parties support ICE. Also, the called party should be able to process the SIP messages that contain IPv6 addresses. In our 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.

SIP Server Modification: In the SIP-ALG solution, the SIP server is equipped with IP version comparison function and SIP-ALG. In the Redirect solution, the SIP server needs to perform IP version comparison and to act as a redirect server. In the ICE solution, the SIP server 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 defined in [23]. This task does not require any modification to the SIP server. In our solution, the SIP server performs IP version comparison and translates the IPv6 INVITE message into an IPv4 INVITE message based on the calling party’s contact information.

Call Setup Complexity: Compared to the standard SIP call setup procedure, the SIP-ALG solution incurs additional call setup overhead for the SIP message translation (between IPv6 and IPv4) performed at the SIP server. The Redirect solution re-quires an extra INVITE transaction (including INVITE, 302 Moved Temporarily, and ACK messages). In the ICE solution, extra call setup overhead is introduced to carry out the connectivity checks. In our solution, the SIP server needs to translate

the first IPv6 INVITE message into an IPv4 INVITE message. The numbers of the call setup messages and the SIP message translations of all solutions are listed in Table 3.1.

RTP Transmission Latency: In the SIP-ALG solution, the RTP packets are delivered between the call parties indirectly through the RTP proxy. In the 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 RTP proxy. In our experiments, the RTP proxy is a PC (with an Intel Pentium 4 3.0GHz CPU and 1.0GB main memory) installed with RTPProxy [1] on Linux operating system. The RTP proxy connects to an IP network through 100 Mbps Ethernet.

During the experiments, RTP packets are injected to the RTP proxy at the rate of 10 Mbps. 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. This extra delay is more than twice the network latency in most cases we have 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 SIP-ALG solution is about 6 to 8 ms more than that in the other solutions.

3.6 Summary

This chapter described three existing IPv4/IPv6 interworking solutions for SIP-based VoIP: the SIP-ALG solution, the Redirect solution, and the ICE solution. Then we proposed an effective solution and compared the new approach with the three existing solutions. Our study indicated that the RTP transmission performance in the SIP-ALG solution is worse than that in the other three solutions. Both the Redirect solution and the ICE solution introduce extra call setup messages with extra call setup overhead. In our solution, the least extra call setup overhead is introduced, and no impairment is incurred to the RTP transmission performance.

Chapter 4 Conclusions

Since every UA requires a unique IP address, the insufficiency of IPv4 addresses becomes a problem in SIP-based VoIP deployment. This problem can be solved by either introducing NATs into IPv4 networks or replacing IPv4 with IPv6. In Chapter 2, we discussed the case where NATs are adopted. An NAT is used so that a public IPv4 address is shared by multiple UAs in the private network. Nevertheless, the NAT translates the IP-layer transport address but leaves the application-layer content unchanged, which results in inconsistency between the transport address at the network and the transport layers and that in the SIP layer. Five UA-based and two server-based widely used solutions were discussed. Also, we designed and developed a UA to analyze these solutions in terms of UA modification, scope of NATs supported, multi-layer NAT traversal, extra server/public IP address requirements, configuration complexity, and time complexities.

At last, we concluded that there is no SIP/RTP NAT traversing solution that is better than the others in all aspects.

In Chapter 3, the usage of IPv6 was discussed. IPv6 provides large address space, which avoids the usage of the NAT. However, IPv4/IPv6 interworking problem is oc-curred when IPv4/IPv6 dual-stack UAs attempt to interact with IPv4-only UAs using IPv6. Three existing solutions were described. Also, we proposed an effective solution by performing SIP message translation to the INVITE message only. The four solutions were evaluated in terms of UA/SIP server modification, call setup complexity, and RTP trans-mission latency. It was shown that our solution outperforms the other solutions in the call setup and the RTP transmission performance. In summary, the usage of IPv6

coop-erating with our proposed solution is the best choice with the most efficient performance for deploying SIP-based VoIP services.

Bibliography

[1] RTPProxy – RTP (Realtime Transport Protocol) Proxy Server.

http://ftp.iptel.org/pub/rtpproxy/.

[2] Snom VoIP-telephones, Solutions for NAT Traversal in SIP Environment.

http://www.iptel.org/info/products/etc/snom-stun.pdf.

[3] The eXtended osip Library. http://savannah.nongnu.org/projects/exosip/.

[4] UPnP^TM Forum. http://www.upnp.org/.

[5] UPnP^TM Internet Gateway Working Committee.

http://www.upnp.org/newsletters/newsletterI/committee.htm#Internet.

[6] The Point-to-Point Protocol (PPP). RFC 1661, IETF, July 1994.

[7] Microsoft, What Is VPN - Technologies Related to VPN.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/

TechRef/bc5c01ea-189e-4d86-a9b7-d426ac80c8a2.mspx, March 2003.

[8] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi. Realm specific IP: protocol specification. RFC 3103, IETF, October 2001.

[9] G. Camarillo, R. Penfield, A. Hawrylyshenm, and M. Bhatia. Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments. Internet-Draft, October 2006. draft-camarillo-sipping-sbc-funcs-05.

[10] E. M. Castro, T. Miguel, and S. Pavon. Transition of Applications to IPv6. Upgrade Journal, 6(2):15–18, April 2005.

[11] W.-E. Chen, Y.-B. Lin, and A.-C. Pang. An IPv4-IPv6 Translation Mechanism for SIP Overlay Network in UMTS All-IP Environment. IEEE Journal of Selected Areas in Communications, 23(11):2152–2160, November 2005.

[12] W.-E. Chen, Y.-H. Sung, and Y.-B. Lin. SIPv6 Analyzer: An Analysis Tool for 3GPP IMS Services. Wireless Communications and Mobile Computing Journal.

[13] S. Deering and R. Hinden. Internet protocol, version 6 (IPv6) specification. RFC 2460, IETF, December 1998.

[14] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616, IETF, June 1999.

[15] Y. Y. Goland, T. Cai, P. Leach, Y. Gu, and S. Albright. Simple Service Discovery Protocol/1.0. Internet-Draft, April 1999. draft-cai-ssdp-v1-03.txt.

[16] M. Handley and V. Jacobson. SDP: Session Description Protocol. RFC 2327, IETF, April 1998.

[17] J. Mulahusic and H. Persson. SIP Issues in Dual-stack Environments. Internet-Draft, February 2003. draft-persson-sipping-sip-issues-dual-stack-00.

[18] S. Olson, G. Camarillo, and A. Roach. Support for IPv6 in Session Description Protocol (SDP). RFC 3266, IETF, June 2002.

[19] J. Rosenberg. Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. Internet-Draft, March 2007. draft-ietf-mmusic-ice-15.

[20] J. Rosenberg, C. Huitema, R. Mahy, and D. Wing. Simple Traversal of UDP Through Network Address Translators (NAT) (STUN). Internet-Draft, October 2006. draft-ietf-behave-rfc3489bis-05.

[21] J. Rosenberg, R. Mahy, and C. Huitema. Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN). Internet-Draft, October 2006. draft-ietf-behave-turn-02.

[22] J. Rosenberg and H. Schulzrinne. An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing. RFC 3581, IETF, August 2003.

[23] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol. RFC 3261, IETF, June 2002.

[24] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 3550, IETF, July 2003.

[25] M-K. Shin, Y-G. Hong, J. Hagino, P. Savola, and E. M. Castro. Application Aspects of IPv6 Transition. RFC 4038, IETF, March 2005.

[26] D. Sisalem, J. Fiedler, and R. Ruppelt. SIP and IPv6: Why and How. SAINT2003, Orlando (Florida, USA), pages 27–31, January 2003.

[27] P. Srisuresh and M. Holdrege. IP Network Address Translator (NAT) Terminology and Considerations. RFC 2663, IETF, August 1999.

[28] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan. Middlebox com-munication architecture and framework. RFC 3303, IETF, August 2002.