C, and finally the leg between the terminating SBC and called SIP user agent. This procedure is applicable to both "Alternative 1" and "Alternative 2" solutions, with different outcomes as shown below: - Alternative 1: The procedure allows the setup of IPv6 SIP sessions between IPv6-capable SBC, while neither disturbing nor requiring modifications on IPv4-only SBCs. Notably, it ensures that as soon as an IPv4-only SBC inter- venes in the exchange, this latter will occur only in IPv4. Therefore, IPv6 C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security usage can be promoted whenever possible, keeping IPv4 service and behavior unchanged. - Alternative 2: The procedure enables to lower IP version changes. Therefore, it provides appropriate means to detect the preferred IP version of the distant peer, thus ensuring the originating peer can adapt to the "unknown yet" destination peer to prevent IP version changes. In an environment where dual stack will be predominant, the SIP-based service can afford choosing the better IP version to avoid IP version changes all along the call path. The principle of this procedure is to rely on the ability of SIP elements to generate and treat "blank" SDP offers, i.e., messages where the SDP part is empty. This means that the initial SDP offer is to be done by the receiving node, not the originating one. This simple operation enables the discovery of the SBC connectivity type. This procedure is likely to be implemented in early stages of IPv6 deployment and can be enforced when deploying Alternative 1-like solutions. The proposed solution may be fully adopted, by all intervening SBCs, when envisaging Alternative 2-like solutions. 3.4.2.1 Application to Alternative 1 As far as IPv4 SBCs are concerned, and owing to the activation of this pro- cedure, IPv6 introduction is transparent. Indeed, IPv4-cabapble SBCs still perform the same operations they are used to in the already deployed IPv4- only SIP-based service. The only slight modification is that 