The Session Description
Protocol (SDP) Alternate Connectivity (ALTC) AttributeFrance TelecomRennes35000Francemohamed.boucadair@orange.comAcme Packet71 Third Ave.BurlingtonMA01803USAhkaplan@acmepacket.comIndependentbob_gilman@comcast.netNokiaSimo.Veikkolainen@nokia.comThis document proposes a mechanism that allows the same SDP offer to carry multiple IP
addresses of different address families (e.g., IPv4 and IPv6).
The proposed attribute, the "altc" attribute, solves the backward-compatibility
problem that plagued Alternative Network Address Types (ANAT) due to
their syntax.The proposed solution is applicable to scenarios where connectivity
checks are not required. If connectivity checks are required,
Interactive Connectivity Establishment (ICE), as specified in
RFC 5245, provides such a solution.Due to the IPv4 address exhaustion problem, IPv6 deployment is
becoming an urgent need, along with the need to properly handle the coexistence of IPv6
and IPv4. The reality of IPv4-IPv6 coexistence
introduces heterogeneous scenarios with combinations of IPv4 and IPv6
nodes, some of which are capable of supporting both IPv4 and IPv6
dual-stack (DS) and some of which are capable of supporting only IPv4
or only IPv6. In this context, Session Initiation Protocol (SIP) User Agents (UAs) need to be able to
indicate their available IP capabilities in order to increase the
ability to establish successful SIP sessions, to avoid
invocation of adaptation functions such as Application Layer Gateways
(ALGs) and IPv4-IPv6 interconnection functions (e.g., NAT64 ), and to avoid using private IPv4 addresses
through consumer NATs or Carrier-Grade NATs (CGNs) .In the meantime, service providers are investigating scenarios to
upgrade their service offering to be IPv6 capable. The current
strategies involve either offering IPv6 only, for example, to mobile
devices, or providing both IPv4 and IPv6, but with private IPv4
addresses that are NATed by CGNs. In the latter case, the end device
may be using "normal" IPv4 and IPv6 stacks and interfaces, or it may
tunnel the IPv4 packets though a Dual-Stack Lite (DS-Lite) stack that is integrated into the
host . In either case, the device has
both address families available from a SIP and media perspective.Regardless of the IPv6 transition strategy being used, it is
obvious that there will be a need for dual-stack SIP devices to
communicate with IPv4-only legacy UAs, IPv6-only UAs, and other
dual-stack UAs.
It may not be possible, for example, for a dual-stack UA to
communicate with an IPv6-only UA unless the dual-stack UA has a means
of providing the IPv6-only UA with an IPv6 address,
while clearly it needs to provide a legacy IPv4-only device an
IPv4 address.
The communication must be possible in a
backward-compatible fashion, such that IPv4-only SIP devices need not
support the new mechanism to communicate with dual-stack UAs.The current means by which multiple address families can be
communicated are through ANAT or ICE
. ANAT has serious
backward-compatibility problems, as described in , which effectively make it unusable, and it
has been deprecated by the IETF .
ICE at least allows interoperability with legacy devices. But, ICE is a
complicated and
processing-intensive mechanism and has seen limited deployment and
implementation in SIP applications.
ALTC has been implemented as reported in . No issues have
been reported in that document.This document proposes a new alternative: a backward-compatible
syntax for indicating multiple media connection addresses and ports in
an SDP offer, which can immediately be selected from and used in an
SDP answer.The proposed mechanism is independent of the model described in
and does not require implementation of
SDP Capability Negotiations (a.k.a., SDPCapNeg) to function.It should be noted that "backward-compatible" in this document
generally refers to working with legacy IPv4-only devices. The choice
has to be made, one way or the other, because to interoperate with
legacy devices requires constructing SDP bodies that they would
understand and support, such that they detect their local address
family in the SDP connection line. It is not possible to support
interworking with both legacy IPv4-only and legacy IPv6-only devices
with the same SDP offer. Clearly, there are far more legacy IPv4-only
devices in existence, and thus those are the ones assumed in this
document. However, the syntax allows for a UA to choose which address
family to be backward-compatible with, in case it has some means of
determining it.Furthermore, even for cases where both sides support the same
address family, there should be a means by which the "best" address
family transport is used, based on what the UAs decide. The address
family that is "best" for a particular session cannot always be known
a priori. For example, in some cases the IPv4 transport may be better,
even if both UAs support IPv6.The proposed solution provides the following benefits:Allows a UA to signal more than one IP address (type) in the
same SDP offer.Is backward compatible. No parsing or semantic errors will be
experienced by a legacy UA or by intermediary SIP nodes that do not
understand this new mechanism.Is as lightweight as possible to achieve the goal, while still
allowing and interoperating with nodes that support other similar
or related mechanisms.Is easily deployable in managed networks.Requires minimal increase of the length of the SDP offer (i.e.,
minimizes fragmentation risks).ALTC may also be useful for the multicast context (e.g., Section 3.4 of or
Section 3.3 of ).More detailed information about ALTC use cases is provided in .This document proposes an alternative scheme, as a replacement to the
ANAT procedure , to carry several IP
address types in the same SDP offer while preserving backward
compatibility.While two UAs communicating directly at a SIP layer clearly need to
be able to support the same address family for SIP itself, current SIP
deployments almost always have proxy servers or back-to-back user agents (B2BUAs) in the SIP
signaling path, which can provide the necessary interworking of the IP
address family at the SIP layer (e.g., ). SIP-layer address family interworking is
out of scope of this document. Instead, this document focuses on the
problem of communicating media address family capabilities in a
backward-compatible fashion. Because media can go directly between two
UAs, without a priori knowledge by the User Agent Client (UAC) of which address family the
far-end User Agent Server (UAS) supports, it has to offer both, in a backward-compatible
fashion.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.The ALTC mechanism defined in this document is primarily meant for
managed networks. In particular, the following use cases were explicitly
considered:A dual-stack UAC that initiates a SIP session without knowing the
address family of the ultimate target UAS.A UA that receives a SIP session request with SDP offer and that wishes to
avoid using IPv4 or IPv6.An IPv6-only UA that wishes to avoid using a NAT64 .A SIP UA behind a DS-Lite CGN .A SIP service provider or enterprise domain of an IPv4-only and/or
IPv6-only UA that provides interworking by invoking IPv4-IPv6
media relays and that wishes to avoid invoking such functions and to let media
go end to end as much as possible.A SIP service provider or enterprise domain of a UA that
communicates with other domains and that wishes either to avoid invoking
IPv4-IPv6 interworking or to let media go end to end as much as
possible.A SIP service provider that provides transit peering services for SIP
sessions that may need to modify SDP in order to provide IPv4-IPv6
interworking, but would prefer to avoid such interworking or to avoid
relaying media in general, as much as possible.SIP sessions that use the new mechanism when crossing legacy SDP-aware
middleboxes, but that may not understand this new mechanism.The ALTC mechanism relies solely on the SDP offer/answer mechanism,
with specific syntax to indicate alternative connection addresses. The
basic concept is to use a new SDP attribute, "altc", to indicate the IP
addresses for potential alternative connection addresses. The address
that is most likely to get chosen for the session is in the normal
"c=" line. Typically, in current operational networks, this would be an
IPv4 address. The "a=altc" lines contain the alternative
addresses offered for this session. This way, a dual-stack UA might
encode its IPv4 address in the "c=" line, while possibly
preferring to use an IPv6 address by explicitly indicating the
preference order in the corresponding "a=altc" line. One
of the "a=altc" lines duplicates the address contained in
the "c=" line, for reasons explained in . The SDP answerer would indicate its chosen
address by simply using that address family in the "c="
line of its response.An example of an SDP offer using this mechanism is as follows when
IPv4 is considered most likely to be used for the session, but IPv6 is
preferred:If IPv6 were considered more likely to be used for the session, the
SDP offer would be as follows:Since an alternative address is likely to require an alternative
TCP/UDP port number as well, the new "altc" attribute
includes both an IP address and a transport port number (or
multiple port numbers). The ALTC mechanism does not itself support
offering a different transport type (i.e., UDP vs. TCP), codec, or
any other attribute. It is intended only for offering an alternative
IP address and port number.The use of an "a=" attribute line is, according to , the primary means for extending SDP and
tailoring it to particular applications or media. A compliant SDP
parser will ignore the unsupported attribute lines.The rationale for encoding the same address and port in the
"a=altc" line as in the "m=" and
"c=" lines is to provide detection of legacy SDP-changing
middleboxes. Such systems may change the connection address and media
transport port numbers, but not support this new mechanism, and thus
two UAs supporting this mechanism would try to connect to the wrong
addresses.
Therefore, this document requires the SDP processor to proceed to the
matching rules defined in .
The "altc" attribute adheres to the
"attribute" production. The ABNF syntax
of altc is provided below.The meaning of the fields are as follows:altc-num: digit to uniquely refer to an address alternative. It
indicates the preference order, with "1" indicated the most preferred
address.addrtype: the addrtype field as defined in for connection data.connection-address: a network address as defined in corresponding to the address type
specified by addrtype.port: the port number to be used, as defined in . Distinct port numbers may be used for each IP
address type. If the specified address type does not require a
port number, a value defined for that address type should be
used.rtcp-port: including an RTP Control Protocol (RTCP) port is optional. An RTCP port may
be indicated in the alternative "c=" line when the RTCP port cannot
be derived from the RTP port.The "altc" attribute is applicable only in an SDP
offer. The "altc" attribute is a media-level-only
attribute and MUST NOT appear at the SDP session level. (Because it
defines a port number, it is inherently tied to the media level.)
There MUST NOT be more than one "altc" attribute per
addrtype within each media description. This restriction is necessary
so that the addrtype of the reply may be used by the offerer to
determine which alternative was accepted.
The "addrtype"s of the altc MUST correspond to the "nettype" of the
current connection ("c=") line.
A media description MUST contain two "altc" attributes:
the alternative address and an alternative port. It must also contain an address
and a port that "duplicate" the address/port information from the
current "c=" and "m=" lines. Each media level MUST contain at least
one such duplicate "altc" attribute, of the same IP address family,
address, and transport port number as those in the SDP connection and
media lines of its level. In particular, if a "c=" line appears within
a media description, the addrtype and connection-address from that
"c=" line MUST be used in the duplicate "altc" attribute
for that media description. If a "c=" line appears only at the session
level and a given media description does not have its own connection
line, then the duplicate "altc" attribute for that media
description MUST be the same as the session-level address
information.The "altc" attributes appearing within a media
description MUST be prioritized. The explicit preference order is
indicated in each line ("1" indicates the address with the
highest priority).
Given this rule, and the requirement that the address information
provided in the "m=" line and "o=" line must be provided in an "altc"
attribute as well, it is possible that the addresses in the
"m=" line and "o=" line are not the preferred choice.
If the addrtype of an "altc" attribute is not
compatible with the transport protocol or media format specified in
the media description, that "altc" attribute MUST be ignored.Note that "a=altc" lines describe alternative
connection addresses, NOT addresses for parallel connections. When
several "altc" lines are present, establishing multiple sessions MUST
be avoided. Only one session is to be maintained with the remote party
for the associated media description.In an SDP offer/answer model, the SDP offer includes
"altc" attributes to indicate alternative connection
information (i.e., address type, address and port numbers),
including the "duplicate" connection information already identified
in the "c=" and "m=" lines.Additional, subsequent offers MAY include "altc"
attributes again, and they may change the IP address, port numbers, and
order of preference, but they MUST include a duplicate
"altc" attribute for the connection and media lines in
that specific subsequent offer. In other words, every offered SDP
media description with an alternative address offer with an
"altc" attribute has two "altc"
attributes:
- one duplicating the "c=" and "m=" line information for that
media description- one for the alternativeThese need not be the same as the original SDP
offer.The purpose of encoding a duplicate "altc" attribute
is to allow receivers of the SDP offer to detect if a legacy
SDP-changing middlebox has modified the "c=" and/or "m=" line
address/port information. If the SDP answerer does not find a
duplicate "altc" attribute value for which the address
and port exactly match those in the "c=" line and "m=" line, the SDP
answerer MUST ignore the "altc" attributes and use the
"c=" and "m=" offered address/ports for the entire SDP instead, as
if no "altc" attributes were present. The rationale for
this is that many SDP-changing middleboxes will end the media
sessions if they do not detect media flowing through them. If a
middlebox modified the SDP addresses, media MUST be sent using the
modified information.Note that for RTCP, if applicable for the given media types, each
side would act as if the chosen "altc" attribute's port
number was in the "m=" media line. Typically, this would mean that RTCP
is sent to the port number equal to "RTP port + 1", unless some other
attribute determines otherwise. For example, the RTP/RTCP
multiplexing mechanism defined in can
still be used with ALTC, such that if both sides support
multiplexing, they will indicate so using the "a=rtcp-mux" attribute,
as defined in , but the IP connection
address and port they use may be chosen using the ALTC
mechanism.If the SDP offerer wishes to use the RTCP attribute defined in
, a complication can arise, since it
may not be clear which address choice the "a=rtcp" attribute applies
to, relative to the choices offered by ALTC. Technically, RFC 3605
allows the address for RTCP to be indicated explicitly in the "a=rtcp"
attribute itself, but this is optional and rarely used. For this
reason, this document recommends using the "a=rtcp" attribute for
the address choice encoded in the "m=" line and including an
alternate RTCP port in the "a=altc" attribute corresponding to the
alternative address. In other words, if the "a=rtcp" attribute
explicitly encodes an address in its attribute, that address applies
for ALTC, as per . If it does not, then
ALTC assumes that the "a=rtcp" attribute is for the address in the "m="
line, and the alternative "altc" attribute includes an RTCP alternate
port number.The SDP answer SHOULD NOT contain "altc" attributes,
because the answer's "c=" line implicitly and definitively chooses the
address family from the offer and includes it in "c="
and "m=" lines of the answer. Furthermore, this avoids
establishing several sessions simultaneously between the
participating peers.Any solution requiring the use of ALTC in the SDP answer SHOULD
document its usage, in particular how sessions are established
between the participating peers.Since ICE also includes address
and port number information in its candidate attributes, a potential
problem arises: which one wins. Since ICE also includes specific ICE
attributes in the SDP answer, the problem is easily avoided: if the
SDP offerer supports both ALTC and ICE, it may include both sets of
attributes in the same SDP offer. A legacy ICE-only answerer will
simply ignore the "altc" attributes and use ICE. An ALTC-only
answerer will ignore the ICE attributes and reply without them. An
answerer that supports both MUST choose one and only one of the
mechanisms to use: either ICE or ALTC. However, if the "m=" or "c=" line
was changed by a middlebox, the rules for both ALTC
and ICE would make the answerer revert to basic SDP semantics.The ALTC mechanism is orthogonal to SDPCapNeg . If the offerer supports both ALTC and
SDPCapNeg, it may offer both.Per this document, the following new SDP attribute has been assigned.The contact person for this registration is Mohamed Boucadair (email:
mohamed.boucadair@orange.com; phone: +33 2 99 12 43 71).The security implications for ALTC are effectively the same as they
are for SDP in general .Many thanks to T. Taylor, F. Andreasen, and G. Camarillo for their
review and comments.IPv6 Multicast Address With Embedded IPv4 Multicast AddressThis document reserves one bit (M-bit) of the unicast prefix-based multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM mode to be used in the context of IPv4-IPv6 interconnection. The document specifies an algorithmic translation of an IPv6 multicast address to a corresponding IPv4 multicast address, and vice versa. This algorithmic translation can be used in both IPv4-IPv6 translation or encapsulation schemes.Address Acquisition For Multicast Content When Source and Receiver Support Differing IP VersionsEach IPTV operator has their own arrangements for pre-provisioning program information including addresses of the multicast groups corresponding to broadcast programs on the subscriber receiver. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines what has to be done to allow the receiver to acquire multicast address information in the version it supports in such scenarios.PCP NAT64 ExperimentsThis memo documents a set of PCP experiments conducted in NAT64 environment. Two services are detailed in the document: access to a video server behind NAT64 and SIP-based sessions. Both 3G and Wi-Fi IPv6-only connectivity have been used.IPv4-IPv6 Multicast: Problem Statement and Use CasesThis document discusses issues and requirements raised by IPv4-IPv6 multicast interconnection and co-existence scenarios. It also discusses various multicast use cases which may occur during IPv6 transitioning.Framework for IPv4/IPv6 Multicast TranslationThis draft describes how IPv4/IPv6 multicast translation may be used in various scenarios and attempts to be a framework for possible solutions. This can be seen as a companion document to the document "Framework for IPv4/IPv6 Translation" by Baker et al. When considering scenarios and solutions for unicast translation, one should also see how they may be extended to provide multicast translation.The following terms are used when discussing the ALTC use cases:SBE (Signaling Path Border Element) denotes a functional
element, located at the boundaries of an ITAD (IP Telephony
Administrative Domain) , that is
responsible for intercepting signaling flows received from UAs
and relaying them to the core service platform. An SBE may be
located at the access segment (i.e., be the service contact point
for UAs), or be located at the interconnection with
adjacent domains . An SBE controls
one or more DBEs. The SBE and DBE may be located in the same device
(e.g., the SBC ) or be separated.DBE (Data Path Border Element) denotes a functional element,
located at the boundaries of an ITAD, that is responsible for
intercepting media/data flows received from UAs and relaying
them to another DBE (or media servers, e.g., an announcement server
or IVR). An example of a DBE is a media gateway that intercepts RTP
flows. An SBE may be located at the access segment (i.e., be the
service contact point for UAs) or be located at the
interconnection with adjacent domains ().Core service platform ("core SPF") is a macro functional block including
session routing, interfaces to advanced services, and access
control. provides an overview
of the overall architecture, including the SBE, DBE, and core service
platform.Recently, a significant effort has been undertaken within the IETF to
specify new mechanisms to interconnect IPv6-only hosts to IPv4-only
servers (e.g., ). This effort exclusively covered
unicast transfer mode. An ongoing initiative, called
"multrans", has been launched to cover multicast issues that are
encountered during IPv6 transition. The overall problem statement is
documented in .A particular issue encountered in the context of IPv4/IPv6
coexistence and IPv6 transition of multicast services is the
discovery of the multicast group and source (refer to Section 3.4 of ):For an IPv6-only receiver requesting multicast content generated by
an IPv4-only source: An ALG is required to help the IPv6 receiver select the
appropriate IP address when only the IPv4 address is
advertised (e.g., using SDP). Otherwise, access to the IPv4
multicast content cannot be offered to the IPv6 receiver. The
ALG may be located downstream of the receiver. As such, the ALG
does not know in advance whether the receiver is dual-stack or
IPv6-only. The ALG may be tuned to insert both the original
IPv4 address and the corresponding IPv6 multicast address using,
for instance, the ALTC SDP attribute.To avoid involving an ALG in the path, an
IPv4-only source can advertise both its IPv4 address and its
IPv4-embedded IPv6 multicast address
using, for instance, the ALTC SDP attribute.For a dual-stack source sending its multicast content over IPv4 and
IPv6, both IPv4 and IPv6 addresses need to be inserted in the SDP
part. A means (e.g., ALTC) is needed for this purpose.Some service providers are in the process of enabling DS-Lite
as a means to continue delivering
IPv4 services to their customers. To avoiding crossing four levels
of NAT when establishing a media session (two NATs in the DS-Lite Address Family Transition Router (AFTR) and two NATs
in the DBE), it is recommended to enable IPv6 functions in some
SBEs/DBEs. Then, DS-Lite AFTRs will not be crossed for DS-Lite
serviced customers if their UA is IPv6-enabled:For a SIP UA embedded in the CPE, this is easy to implement since the SIP UA can be tuned to
behave as an IPv6-only UA when DS-Lite is enabled. No ALTC is
required for this use case.For SIP UAs located behind the CPE, a solution to
indicate both IPv4 and IPv6 (e.g., ALTC) is required in order to
avoid crossing the DS-Lite CGN.A basic solution to deliver SIP-based services using an IPv4-only
core service platform to an IPv6-enabled UA is to enable the IPv4/IPv6
interworking function in the SBE/DBE. Signaling and media between two
SBEs and DBEs is maintained over IPv4. IPv6 is used between an
IPv6-enabled UA and an SBE/DBE. shows the results of session
establishment between UAs. In this scenario, the IPv4/IPv6 interworking
function is invoked even when both involved UAs are
IPv6-enabled.
It may be valuable for service providers to consider solutions that
avoid redundant IPv4/IPv6 NATs and that avoid involving several DBEs.
A solution to indicate both IPv4 and IPv4 addresses is required for service providers that want the following:
A means to promote the invocation of IPv6 transfer capabilities
that can be enabled, while no parsing errors are experienced by
core service legacy nodes.To optimize the cost related to IPv4-IPv6 translation licenses.To reduce the dual-stack lifetime.To maintain an IPv4-only core. To have a set of SBEs/DBEs that are IPv6-enabled. This section provides an overview of the procedure to avoid IPv4/IPv6
interworking.When an SBE receives an INVITE, it instantiates in its DBE an
IPv6-IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and
an IPv4 address are returned, together with other information such as
port numbers. The SBE builds an SDP offer, including both the IPv4 and
IPv6-related information using the "altc" attribute. IPv6 is indicated as
the preferred connectivity type; see .The request is then forwarded to the core SPF, which, in turn,
forwards it to the terminating SBE.If this SBE is a legacy one, then it will ignore "altc"
attributes and use the "c=" line.If the terminating SBE is IPv6-enabled: If the called UA is IPv4 only, then an IPv6-IPv4 context
is created in the corresponding DBE.If the called UA is IPv6-enabled, then an IPv6-IPv6
context is created in the corresponding DBE. shows the results of the procedure
when placing a session between an IPv4 and IPv6 UAs, while shows the results of establishing a session
between two IPv6-enabled UAs. The result is still not optimal since
redundant NAT66 is required ().For service providers wanting to involve only one DBE in the
media path when not all SBEs/DBEs and UAs are IPv6-enabled, a means
to indicate both IPv4 and IPv6 addresses without inducing session
failures is required. This section proposes an example
procedure using the "altc" attribute.When the originating SBE receives an INVITE from an IPv6-enabled
UA, it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4
context. Both an IPv6 address and an IPv4 address are returned,
together with other information, such as port numbers. The SBE builds an
SDP offer, including both IPv4 and IPv6-related information using
the "altc" attribute (). IPv6 is
indicated as preferred connectivity type.The request is then forwarded to the core SPF, which, in turn,
forwards it to the terminating SBE:If the destination UA is IPv6 or reachable with a public IPv4
address, the SBEs only forwards the request without altering the
SDP offer. No parsing error is experienced by core service nodes
since ALTC is backward compatible.If the terminating SBE does not support ALTC, it will ignore
this attribute and use the legacy procedure.As a consequence, only one DBE is
maintained in the path when one of the involved parties is
IPv6-enabled. shows the overall
procedure when the involved UAs are IPv6-enabled.The main advantages of such a solution are as follows:DBE resources are optimized.No redundant NAT is maintained in the path when IPv6-enabled
UAs are involved.End-to-end delay is optimized.The robustness of the service is optimized since the delivery
of the service relies on fewer nodes.The signaling path is alos optimized since no communication
between the SBE and DBE at
the terminating side is required for some sessions. (That
communication would be through the Service Policy Decision
Function (SPDF) in a Telecoms and Internet converged
Services and Protocols for Advanced Networks/IP
Multimedia Subsystem (TISPAN/IMS) context.)For service providers wanting to allow direct IPv6 communications
between IPv6-enabled UAs, when not all SBEs/DBEs and UAs are
IPv6-enabled, a means to indicate both the IPv4 and IPv6 addresses
without inducing session failures is required. Below is an example of a proposed procedure using the "altc" attribute.At the SBE originating side, when the SBE receives an INVITE from
the calling IPv6 UA (), it uses
ALTC to indicate two IP addresses:An IPv4 address belonging to its controlled DBE.The same IPv6 address and port as received in the initial
offer made by the calling IPv6. shows an excerpted example of the SDP offer of the calling UA, and
shows an excerpted example of the updated SDP offer generated by
the originating SBE.
The INVITE message will be routed appropriately to the
destination SBE:If the SBE is a legacy device (i.e., IPv4-only), it will
ignore IPv6 addresses and will contact its DBE to instantiate an
IPv4-IPv4 context.If the SBE is IPv6-enabled, it will only forward the INVITE
to the address of contact of the called party:If the called party is IPv6-enabled, the communication
will be placed using IPv6. As such, no DBE is involved in the
data path, as illustrated in .Otherwise, IPv4 will be used between the originating DBE and
the called UA.