| Network Working Group | M. Boucadair |
| Internet-Draft | France Telecom |
| Intended status: Informational | H. Kaplan |
| Expires: July 15, 2013 | Acme Packet |
| R. . Gilman | |
| Independent | |
| S. Veikkolainen | |
| Nokia | |
| January 11, 2013 |
Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
draft-boucadair-mmusic-altc-08
This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax.
The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, ICE (RFC 5245) provides such a solution.
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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 15, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Due to the IPv4 address exhaustion problem, IPv6 deployment is becoming an urgent need, along with the need to properly handle IPv6 and IPv4 co-existence. The reality of IPv4-IPv6 co-existence 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 [RFC3261]) User Agents (UAs) need to be able to indicate their available IP capabilities in order to increase the ability to establish successful SIP sessions, and also to avoid invocation of adaptation functions such as Application Layer Gateways (ALGs) and IPv4-IPv6 interconnection functions (e.g., NAT64 [RFC6146]), and to avoid using private IPv4 addresses through consumer NATs or Carrier Grade NATs (CGN, [I-D.ietf-behave-lsn-requirements]).
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 which are NAT'ed 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 DS-Lite stack integrated into the host [RFC6333]; 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, and IPv6-only UAs, and other dual-stack UAs. It may not, for example, be possible for a dual-stack UA to communicate with an IPv6-only UA unless the dual-stack UA had a means of providing the IPv6-only UA with its IPv6 local address for media, while clearly it needs to provide a legacy IPv4-only device its local IPv4 address. The communication must be possible in a backwards-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 [RFC4091] or ICE [RFC5245]. ANAT has serious backwards-compatibility problems as described in [RFC4092], which effectively make it unusable, and it is deprecated by the IETF [RFC5245]. ICE at least allows interoperability with legacy devices, by not doing ICE in such cases, but it is a complicated and processing intensive mechanism, and has seen limited deployment and implementation in SIP applications.
ALTC has been implemented as reported in [I-D.boucadair-pcp-nat64-experiments]; no issue has been reported in that document.
This document proposes a new alternative: a backwards-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 [RFC5939] and does not require implementation of sdp-capabilities-negotiations (a.k.a., SDPCapNeg) to function.
It should be noted that "backwards-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 which 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 backwards-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 which 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:
ALTC may also be useful for the multicast context (e.g., Section 3.4 of [I-D.venaas-behave-v4v6mc-framework] or Section 3.3 of [I-D.ietf-mboned-multrans-addr-acquisition]).
More detailed information about ALTC use cases is provided in Appendix A.
This document proposes an alternative scheme, as replacement to the ANAT procedure [RFC4091], to carry several IP address types in the same SDP offer/answer while preserving backward compatibility.
While clearly two UAs communicating directly at a SIP layer need to be able to support the same address family for SIP itself, current SIP deployments almost always have Proxy Servers or B2BUA's in the SIP signaling path, which can provide the necessary interworking of the IP address family at the SIP layer (e.g., [RFC6157]). 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 backwards-compatible fashion. Since media can go directly between two UAs, without a priori knowledge by the UAC of which address family the far-end UAS supports, it has to offer both, in a backwards-compatible fashion.
The ALTC mechanism defined in this document is primary meant for managed networks. In particular, the following use cases were explicitly considered:
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 which 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, in preference order, 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 indicating this by the “a=altc” attribute line ordering. One of the “a=altc” lines duplicates the address contained in the “c=” line, for reasons explained in Section 3.2). 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:
v=0 o=- 25678 753849 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 m=audio 12340 RTP/AVP 0 8 a=altc IP6 2001:db8::1 45678 a=altc IP4 192.0.2.1 12340
If IPv6 was considered most likely to be used for the session, the SDP offer would be as follows:
v=0 o=- 25678 753849 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 m=audio 12340 RTP/AVP 0 8 a=altc IP6 2001:db8::1 45678 a=altc IP4 192.0.2.1 12340
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 receive 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, nor any other attribute. It is only intended for offering an alternative IP address and port number.
The use of an 'a=' attribute line is, according to [RFC4566], 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, the rules detailed in this document require the SDP processor to check for matching altc and connection line addresses and media ports, before choosing one of the alternatives.
The altc attribute adheres to the [RFC4566] "attribute" production. The ABNF syntax [RFC5234] of altc is provided below:
altc-attr = "altc" att-value att-value = addrtype SP connection-address SP port ["/" rtcp-port] rtcp-port = port
Figure 1: Connectivity Capability Attribute ABNF
The meaning of the fields are listed hereafter:
The “altc” attribute is only applicable in an SDP offer. The “altc” attribute is a media-level-only attribute, and MUST NOT appear at the SDP session level (since 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 in order 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 as well as an address and port which "duplicates" 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 addr-type 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 in order of appearance, with the first altc given highest priority and the following altc attributes prioritized in decending order. 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 address 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, multiple sessions establishment MUST be avoided. Only one session is to be maintained with the remote party for the associated media description.
If no port number is indicated for the alternative address, the same port number is used for all address families.
In an SDP offer/answer model, the SDP offer includes “altc” attributes to indicate alternative connection information (i.e., address type, address and port number(s)), including the "duplicate" connection information already identified in the 'c=' and 'm=' lines.
Additional, subsequent offers MAY include “altc” attributes again, and 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 of them:
even though these 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 middle box 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 match exactly 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 RTCP is sent to the odd +1 of the port number, unless some other attribute determines otherwise. For example the RTP/RTCP multiplexing mechanism defined in [RFC5761] 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 [RFC5761]; 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 [RFC3605], a complication can arise since it may not be clear which address choice the 'a=rtcp' attribute applies to, relative the choices offered by ALTC. Technically RFC 3605 allows indicating the address for RTCP explicitly in the 'a=rtcp' attribute itself, but this is optional and rarely used. For this reason, this document recommends using 'a=rtcp' attribute to be for the address choice encoded in the "m=" line, and include 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, then that applies for ALTC as per [RFC3605]; if it does not, then ALTC assumes the 'a=rtcp' attribute is for the address in the "m=" line, and the alternative "altc" attribute include an RTCP alternate port number.
The SDP answer SHOULD NOT contain “altc” attributes, as 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 SDP answer SHOULD document its usage, in particular how sessions are established between the participating peers.
Since ICE [RFC5245] 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 which supports both MUST choose one and only one of the mechanisms to use: either ICE or ALTC (unless the 'm=' or 'c=' lines were changed by a middlebox, in which case the rules for both ALTC and ICE would make the answerer revert to basic SDP semantics).
The ALTC mechanism is orthogonal to SDPCapNeg [RFC5939]. If the offerer supports both ALTC and SDPCapNeg, it may offer both.
This document requests the following new SDP attribute:
SDP Attribute ("att-field"):
Attribute name altc
Long form Alternate Connectivity
Type of name att-field
Type of attribute Media level only
Subject to charset No
Purpose See Section 1.2, Section 3
Specification Section 4
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 [RFC4566].
Many thanks to T. Taylor, F. Andreasen and G. Camarillo for their review and comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3605] | Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. |
| [RFC5761] | Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
The following terms are used:
+----------+
| Core SIP |
+--------->| SPF |<---------+
| SIP +----------+ SIP |
v v
+-----------+ +-----------+
+-----+ SIP | SBE | | SBE | SIP
| S |<----->| | | |<----->
| I | +-----------+ +-----------+
| P | || ||
| | +-----------+ +-----------+
| U | RTP | DBE | RTP | DBE | RTP
| A |<----->| |<----------------->| | <----->
+-----+ +-----------+ +-----------+
SIP UA can be embedded in the CPE or in a host behind the CPE
Figure 2: Service Architecture: Overview
Recently, a significant effort has been undertaken within IETF to specify new mechanisms to interconnect IPv6-only hosts to IPv4-only servers (e.g., [RFC6146]). This effort covered exclusively unicast transfer mode. An ongoing initiative, called multrans, has been launched to cover multicast issues to be encountered during IPv6 transition. The overall problem statement is documented in [I-D.ietf-mboned-v4v6-mcast-ps].
A particular issue encountered in the context of IPv4/IPv6 co-existence and IPv6 transition of multicast services is the discovery of multicast group and source (refer to Section 3.4 of [I-D.ietf-mboned-v4v6-mcast-ps]):
Some service providers are in the process of enabling DS-Lite [RFC6333] as a means to continue delivering IPv4 services to their customers. To avoiding crossing four levels of NAT when placing a media session (2 NAT in DS-Lite AFTR + 2 NAT in the DBE), it is recommended to enable IPv6 functions in some SBEs/DBEs. Therefore DS-Lite AFTRs won't be crossed for DS-Lite serviced customers if their UA is IPv6-enabled:
A basic solution to deliver SIP-based services using IPv4-only core service platform to IPv6-enabled UA is to enabled IPv4/IPv6 interworking function in SBE/DBE. Signaling and media between two SBEs and DBEs is maintained over IPv4. IPv6 is used between an IPv6-enabled UA and a SBE/DBE.
Figure 3 shows the results of session establishment between UAs. In this scenario, IPv4/IPv6 interworking function is invoked even when both involved UAs are IPv6-enabled.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| | |<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->|IPv4/v6 IWF|<------>| |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
Figure 3: Basic scenario
Solutions to avoid redundant IPv4/IPv6 NAT and involving several DBEs may be valuable to consider by service providers.
For services providers wanting:
A solution to indicate both IPv4 and IPv6 addresses is required. This section provides an overview of this procedure:
When a 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. SBE builds an SDP offer including both IPv4 and IPv6-related information using ALTC attribute. IPv6 is indicated as preferred connectivity type.
o=- 25678 753849 IN IP4 192.0.2.2 c=IN IP4 192.0.2.2 m=audio 12340 RTP/AVP 0 8 a=altc IP6 2001:db8::2 6000 a=altc IP4 192.0.2.2 12340
Figure 4: SDP offer updated by the SBE
The request is then forwarded to the core SPF which in its turn forwards the requests to the terminating SBE.
Figure 5 shows the result of the procedure when placing a session between an IPv4 and IPv6 UAs while Figure 6 shows the results of establishing a session between two IPv6-enabled UAs. The result is still not optima since redundant NAT66 is required (Appendix A.3.4).
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv4|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv4 RTP+-|IPv4|
| UA |<-------->| NAT66 |<------>|IPv4/v6 IWF|<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 5: Session establishement between IPv4 and IPv6 UAs
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv6 RTP+-|IPv6|
| UA |<-------->| NAT66 |<------>| NAT66 |<-------->| UA |
+----+ +-----------+ +-----------+ +----+
2001:db8::2
Figure 6: Session establishement between IPv6 UAs
For service providers wanting to involve only one DBE in the media path, when not all SBE/DBE and UAs are IPv6-enabled, a means to indicate both IPv4 and IPv6 addresses without inducing session failures is required. Below is proposed an example of a proposed procedure using 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. SBE builds an SDP offer including both IPv4 and IPv6-related information using ALTC attribute (Figure 7). IPv6 is indicated as preferred connectivity type.
o=- 25678 753849 IN IP4 192.0.2.2 c=IN IP4 192.0.2.2 m=audio 12340 RTP/AVP 0 8 a=altc IP6 2001:db8::2 6000 a=altc IP4 192.0.2.2 12340
Figure 7: SDP offer updated by the SBE
The request is then forwarded to the core SPF which in its turn forwards the requests to the terminating SBE:
Figure 8 shows the overall procedure when involved UAs are IPv6-enabled.
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | +-----------+ | +----+
|IPv6|-+IPv6 RTP| DBE | IPv6 RTP +-|IPv6|
| UA |<-------->| NAT66 |<----------------------------->| UA |
+----+ +-----------+ +----+
2001:db8::1 2001:db8::2
Figure 8: DBE Bypass Overview
The main advantages of such solutions are as follows:
For service providers wanting to allow direct IPv6 communications between IPv6-enabled UAs, when not all SBE/DBE and UA are IPv6-enabled, a means to indicate both IPv4 and IPv6 addresses without inducing session failures is required. Below is proposed an example of a proposed procedure using ALTC attribute.
At the SBE originating side, when the SBE receives an INVITE from the calling IPv6 UA (Figure 9), it updates uses the ALTC to indicate two IP addresses:
Figure 10 shows an excerpt example of the SDP offer generated by the originating SBE.
o=- 25678 753849 IN IP6 2001:db8::1 c=IN IP6 2001:db8::1 m=audio 12340 RTP/AVP 0 8
Figure 9: SDP offer of the calling UA
o=- 25678 753849 IN IP4 192.0.2.2 c=IN IP4 192.0.2.2 m=audio 12340 RTP/AVP 0 8 a=altc IP6 2001:db8::1 6000 a=altc IP4 192.0.2.2 12340
Figure 10: SDP offer updated by the SBE
The INVITE message will be routed appropriately to the destination SBE:
+----------+
| Core SIP |
+--->|SPF (IPv4)|<---+
IPv4 SIP | +----------+ |IPv4 SIP
v v
+-----------+ +-----------+
| SBE | | SBE | SIP
+------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+
|IPv6 +-----------+ +-----------+ IPv6|
| SIP SIP|
+----+ | | +----+
|IPv6|-+ IPv6 RTP +-|IPv6|
| UA |<---------------------------------------------------->| UA |
+----+ +----+
2001:db8::1
Figure 11: Direct IPv6 communication