omers to select on a per-call basis the interface to be used to access to SIP-based service: In some scenarios where customers are multi-homed, they can apply some policies SO that the decision-making pro- cess regarding the interface to be used to place a SIP call can lead to use distinguished Network interfaces for each SIP call. As a consequence, the SIP-based service should not be mapped statically to a given interface. The service platform should not use a static interface to contact a SIP user agent. 3- Ability of the customers to send signalling data and media streams using distinct interfaces: Customers should be able to send their signalling messages using a distinct interface than the one used to transmit and receive media streams. Consequently, the SIP-based service platform should have means to enforce such a requirement. For instance, it should not consider a customer runs an IPv4-enabled SIP user agent based on its lonely subscription using its IPv4 address in this context of service subscription. The context of the service subscription, especially activated socket type, should not be exploited for the placement of further SIP calls. A SIP-based service platform should be IP version-agnostic unless this interferes with the call routing logic and can lead to unsuccessful SIP sessions. In such a case, the last requirement should be relaxed and considered as optional. Second Objective-SIP IPv4-IPv6 interworking: The goal is to ensure SIP- based calls between all service subscribed customers and especially between those using heterogeneous SIP user agents. This objective is valid when it remains some IPv4-only customers or at least when all customers are not dual stack. This objective aims at eliminating service access' segregation based on IP connectivity considerations and not creating VoIP communities based on the type of the activated connectivity protocol. The heterogeneity of IP ver- sions should be transparent for end users and no service degradation should be observed when interconnecting two he