h in both realms even if this sub-optimality in each realm may not lead to a global optimal path. This requirement should be passed to control layers in order to meet service layers requirements. 1-3- End-to-end security mechanisms should be supported and not altered: In case the VoIP service offering allows end-to-end security mechanisms, this should be valid for both homogenous and heterogeneous calls. Hop-by-hop security mechanisms should also be supported. The impact of the presence of IP addresses and port numbers in SIP messages is to be carefully studied. A focus should also be put on how to ensure privacy of the call participant. 1-4- Both call direction should be supported: This means that IPv4 to IPv6 calls must be supported as well as IPv6 to IPv4 calls. The direction of the call must not have an impact on the result of call set-up. The Quality of Service (QoS) of both ways should be similar and no difference should be perceived by service end users. 2- Ability of a dual-stack user agent to place a call using its IPv4 connectivity with an IPv6-capable customer: This means that a dual-stack SIP user agent could select its IPv4 connectivity to place a call to IPv6 SIP user agents. The service platform should not impose the IP connectivity to be used by a dual-stack SIP user agent. This requirement should be relaxed for some service considerations like: traffic matrix of IPv4 clients, the success rate of IPv4/IPv6 calls, to speed the migration to IPv6, etc. 3- Ability of a dual-stack user agent to place a call using its IPv4 connectivity with an IPv4-capable customer: This means that a dual-stack SIP user agent could use its IPv4 connectivity to place a call to IPv4 SIP user agents. The service platform should not impose the IP connectivity to be used by a dual- stack SIP user agent. 4- Ability of a dual-stack user agent to place a call using its IPv6 connectiv- ity with an IPv4-capable customer: This means that a dual stack SIP user agent could use its IPv6 connectivity to place a call to IPv4 SIP user a