ents might be introduced to the core platform, which is not likely to remain IPv4-only. How- ever, we don't expect dual-stack core nodes to provide the service to all kind of SIP user agents. Before this happens, it is rather reasonable to consider that IPv4-only SIP user agents remain managed by IPv4-only service nodes, while IPv6-enabled SIP user agents are managed by dual-stack core service nodes in the early stages of deployment. This leaves time to field-prove the IPv6 solution before considering a full dual-stack core. In this context, it could be possible for dual-stack core nodes to handle both IPv4 and IPv6 contact addresses of dual-stack SIP user agents, providing potentially more flexibility to the service and especially for call routing optimization. Another solution would consist in relying on the same procedures as des- cribed in the previous section at the access segment. SIP user agents would be handled by dual-stack SBCs SO as to be represented by a single IP contact address toward the core, potentially IPv6 for IPv6-enabled SIP user agents (i.e., including dual-stack SIP user agents). Whatever the adopted solution, IPv4-only SIP user agents keep being managed relying on IPv4 legacy opera- tions. This means that a distinction (i.e., Discovery of SIP user agents types) must be performed "somewhere" by the service platform. Maintaining IPv4- only nodes in the core also means that IP version changes should be carefully looked at. One purpose of this solution's design would be to know how to exploit dual-stack core nodes in order to improve call routing and limit these IP version changes. Therefore, this scenario presents the same technical challenges as the pre- vious one, i.e., the need for SIP user agent discrimination in order to know what treatment must be applied by SBCs and routing optimization. 3.3.4.3 Third Alternative This third alternative is radical and proposes to change the existing infras- tructure by eliminating existing IPv4-enabled SIP elements and deploy new SIP elements SO as to s