and the Registrar. These addresses could be IP addresses, or Fully Qualified Domain Name (FQDN), or the IP address of an intermediary node that will isolate the SIP service platform (such as a Session Border Controller (SBC) to ensure topology hiding of the SIP-based service architecture). 3.1.2 Beyond the State of the Art IPv6 complications in a SIP environment (including IMS/TISPAN architec- tures) have not been studied deeply enough in the literature. Few papers and C 2009 by Taylor & Francis Group, LLC SIP and IPv6 Internet drafts have been edited to capture and to discuss related issues. For instance, Internet draft (Gurbani, Boulton, and Sparks 2007) proposes a set of recommendations to ease configuration of a SIP-based service that inter- connects SIP user agents (UA) from both IPv4 and IPv6 worlds. Nevertheless, this effort isn't possibly viable in operational architectures since the adopted architecture is a la Internet and not a la IMS. A paper (Gurbani, Boulton, and Sparks 2007) identifies issues related to IPv6 porting that developers of SIP applications should take into account when introducing IPv6 support to SIP applications running on either dual-stack (i.e., supporting both IPv4 and IPv6) hosts or IPv4-only nodes. As far as IMS is concerned, (3GPP TR 23.981 2005) details some scenarios to interconnect IPv4 and IPv6 realms to enable heterogeneous sessions (i.e., involving participants attached to dis- tinct realms (IPv4 and IPv6)). Unfortunately, (3GPP TR 23.981 2005) is not complete and proposed solutions are not optimal. This document is also used to undertake the effort documented in (Chen, Lin, and Pang 2005), which focuses mainly on Universal Mobile Telecommunications System (UMTS) net- works. Finally, (Chen and Wu 2005) provides details about an IPv6-based SIP VoIP network experiment deployed in Taiwan. This paper does not han- dle issues related to interworking with IPv4 realm or how operational service offerings may be migrated to support IPv6. It focuses only on the usage of TElephone NUm