This paper addresses an important aspect of the deployment of session initiation protocol (SIP) systems: getting the signaling and media to be understood and accepted when any of the endpoints are conversing over a different network protocol, namely, Internet protocol version 4 (IPv4) or Internet protocol version 6 (IPv6).

Two solutions that have been employed in Taiwan are presented in this paper: socket-layer translation (SLT) and the SIPv6 translator. The SLT is modeled after the bump-in-the-application programming interface (API) (BIA) technique, which inserts an API translator between the socket API module and the transmission control protocol/Internet protocol (TCP/IP) module in the dual stack hosts, so that it translates the IPv4 socket API function into an IPv6 socket API function and vice versa. The second solution, the SIPv6 translator, involves using network address translation and protocol translation (NAT-PT) to essentially forward the message to an application layer gateway (ALG) for further processing, which involves rewriting portions of the message (especially the ones that contain network identifiers).

There are problems with both solutions. With regard to SLT, the authors have based it on the BIA technique, which is defined in Internet Engineering Task Force (IETF) request for comments (RFC) 3338. The problem is that RFC3338 is experimental in nature; it is not a standards-track RFC. As such, it is unclear how many implementations in the field support this RFC, if any. Furthermore, the authors have tied their particular implementation to the Windows platform. There are many non-Windows devices, mobile and stationary, that have SIP user agents on them. Clearly, it is unfeasible to retrofit every user agent to support BIA. Using BIA is good for only one thing: as a proof of concept. It is very hard to draw any conclusions on how generally pervasive and scalable this technique will be.

Regarding the SIPv6 translator, the biggest problem is its reliance on NAT-PTs. Serious issues have been uncovered in implementing NAT-PTs; there is work underway [1] in the IETF to relegate the NAT-PT RFC to experimental status. Clearly, this solution is a nonstarter as well, especially given the fact that it requires an ALG for every protocol that runs in the SIPv6 translator (domain name system (DNS), SIP, session description protocol (SDP), and so on).

The IETF is working on other ways to get SIP to work between different network protocols [2] that leverage serial tunneling (STUN), traversal using relay NAT (TURN), and interactive connectivity establishment (ICE). The authors do not mention any of this related work. As such, while the paper is adequate as a point solution in this space, it is not suitable for a comprehensive solution to making SIP work between IPv4 and IPv6.