erve both IPv4 and IPv6-enabled customers (either by replacing them physically or updating all nodes). This alternative is not viable for service providers offering IPv4-enabled SIP services. 3.3.5 Service Engineering Recommendations The main objective of this section is to identify a non-exhaustive list of techni- cal issues that should be handled by a solution pretending to solve SIP-based services migration to IPv6 and associated complications to interconnect with IPv4-enabled SIP-based services realm. These issues may be considered as recommendations for solution designers to take into account. First, in order to avoid confusions, between the ":" usage to separate the IPv4 address and the port number and its usage in IPv6, SIP IPv6 C 2009 by Taylor & Francis Group, LLC SIP and IPv6 elements should enclose IPv6 addresses between "[" and "]" (Schulzrinne 1996). Second, in order to avoid the usage of "hard" IP addresses inside SIP messages, UA should invoke means for discovering SIP servers (for instance, through DHCP and particularly the procedures defined in (Schulzrinne 2002) and (Schulzrinne and Volz 2003)). Therefore, the SIP user agent will retrieve an IP address in the same realm version it is attached to. SIP user agents can also be provisioned with a Fully Qualified Domain Name (FQDN) of the first contact point (e.g., SBC or Proxy Call Session Control Function (P-CSCF) in the context of IMS/TISPAN architectures). Of course, the DNS should be provisioned with both IPv4 and IPv6 entries. For call routing optimization purposes, SIP proxy servers need to know the type of the called and the caller parties SO as to determine if there is a need to alter the SDP body of the received SIP messages. SIP proxy servers should implement means to discriminate SIP user agents based on their connectivity type. This feature may optimize the invocation of adaptation functions, such as ALG or NAT - PT blocks. In addition, service providers may implement means to verify the consistency between the SIP user agent connectivit