Independent Submission M. Boucadair
Request for Comments: 6947 France Telecom
Category: Informational H. Kaplan
ISSN: 2070-1721 Acme Packet
R. Gilman
Independent
S. Veikkolainen
Nokia
May 2013
Independent Submission M. Boucadair
Request for Comments: 6947 France Telecom
Category: Informational H. Kaplan
ISSN: 2070-1721 Acme Packet
R. Gilman
Independent
S. Veikkolainen
Nokia
May 2013
The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
会话描述协议（SDP）备用连接（ALTC）属性
Abstract
摘要
This 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.
本文档提出了一种机制，允许同一SDP产品承载不同地址系列（例如IPv4和IPv6）的多个IP地址。建议的属性“altc”属性解决了由于其语法而困扰替代网络地址类型（ANAT）的向后兼容性问题。
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.
建议的解决方案适用于不需要连接检查的场景。如果需要进行连接检查，RFC 5245中规定的交互式连接建立（ICE）可提供此类解决方案。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6947.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6947.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 7
4. Alternate Connectivity Attribute . . . . . . . . . . . . . . 8
4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 9
4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Usage of ALTC in an SDP Answer . . . . . . . . . . . 11
4.2.3. Interaction with ICE . . . . . . . . . . . . . . . . 11
4.2.4. Interaction with SDP-Cap-Neg . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. ALTC Use Cases . . . . . . . . . . . . . . . . . . . 15
A.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Multicast Use Case . . . . . . . . . . . . . . . . . . . 16
A.3. Introducing IPv6 into SIP-Based Architectures . . . . . . 17
A.3.1. Avoiding Crossing CGN Devices . . . . . . . . . . . . 17
A.3.2. Basic Scenario for IPv6 SIP Service Delivery . . . . 17
A.3.3. Avoiding IPv4/IPv6 Interworking . . . . . . . . . . . 18
A.3.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . 20
A.3.5. Direct Communications between IPv6-Enabled User
Agents . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 7
4. Alternate Connectivity Attribute . . . . . . . . . . . . . . 8
4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 9
4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Usage of ALTC in an SDP Answer . . . . . . . . . . . 11
4.2.3. Interaction with ICE . . . . . . . . . . . . . . . . 11
4.2.4. Interaction with SDP-Cap-Neg . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. ALTC Use Cases . . . . . . . . . . . . . . . . . . . 15
A.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Multicast Use Case . . . . . . . . . . . . . . . . . . . 16
A.3. Introducing IPv6 into SIP-Based Architectures . . . . . . 17
A.3.1. Avoiding Crossing CGN Devices . . . . . . . . . . . . 17
A.3.2. Basic Scenario for IPv6 SIP Service Delivery . . . . 17
A.3.3. Avoiding IPv4/IPv6 Interworking . . . . . . . . . . . 18
A.3.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . 20
A.3.5. Direct Communications between IPv6-Enabled User
Agents . . . . . . . . . . . . . . . . . . . . . . . 22
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) [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, 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 (CGNs) [RFC6888].
由于IPv4地址耗尽问题，IPv6部署正成为迫切需要，同时需要正确处理IPv6和IPv4共存的问题。IPv4-IPv6共存的现实引入了IPv4和IPv6节点组合的异构场景，其中一些节点能够同时支持IPv4和IPv6双栈（DS），一些节点只能支持IPv4或IPv6。在这种情况下，会话发起协议（SIP）[RFC3261]用户代理（UAs）需要能够指示其可用的IP能力，以提高建立成功SIP会话的能力，从而避免调用自适应功能，例如应用层网关（ALG）和IPv4-IPv6互连功能（例如NAT64）[RFC6146]），并避免通过消费者NAT或运营商级NAT（CGN）使用专用IPv4地址[RFC6888]。
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 [RFC6333]. In either case, the device has both address families available from a SIP and media perspective.
与此同时，服务提供商正在研究将其服务升级为支持IPv6的方案。当前的策略包括，例如，仅向移动设备提供IPv6，或者同时提供IPv4和IPv6，但使用CGN指定的专用IPv4地址。在后一种情况下，终端设备可能使用“正常”IPv4和IPv6堆栈和接口，或者通过集成到主机中的双堆栈Lite（DS Lite）堆栈对IPv4数据包进行隧道传输[RFC6333]。在任何一种情况下，该设备都具有从SIP和媒体角度可用的地址族。
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.
无论使用何种IPv6转换策略，很明显，双栈SIP设备都需要与仅IPv4的传统UAs、仅IPv6的UAs和其他双栈UAs通信。例如，双栈UA可能不可能与仅IPv6 UA通信，除非双栈UA具有向仅IPv6 UA提供IPv6地址的方法，而显然它需要向仅IPv4的传统设备提供IPv4地址。通信必须能够以向后兼容的方式进行，以便仅IPv4的SIP设备不需要支持与双栈UAs通信的新机制。
The current means by which multiple address families can be communicated are through ANAT [RFC4091] or ICE [RFC5245]. ANAT has serious backward-compatibility problems, as described in [RFC4092], which effectively make it unusable, and it has been deprecated by the IETF [RFC5245]. 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.
当前可通过ANAT[RFC4091]或ICE[RFC5245]传送多个地址族的方式。如[RFC4092]所述，ANAT存在严重的向后兼容性问题，这实际上使其无法使用，IETF[RFC5245]已不推荐使用它。ICE至少允许与传统设备的互操作性。但是，ICE是一种复杂的处理密集型机制，在SIP应用程序中的部署和实现非常有限。
ALTC has been implemented as reported in [NAT64-EXP]. No issues have been reported in that document.
已按照[NAT64-EXP]中的报告实施了ALTC。该文件没有报告任何问题。
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.
本文档提出了一种新的替代方案：一种向后兼容的语法，用于指示SDP产品中的多个媒体连接地址和端口，可立即从SDP应答中选择并在SDP应答中使用。
The proposed mechanism is independent of the model described in [RFC5939] and does not require implementation of SDP Capability Negotiations (a.k.a., SDPCapNeg) to function.
提议的机制独立于[RFC5939]中描述的模型，不需要实现SDP能力协商（也称为SDPCapNeg）才能发挥作用。
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.
应注意，本文档中的“向后兼容”通常指仅使用传统IPv4设备。必须做出这样或那样的选择，因为要与遗留设备进行互操作，需要构建它们能够理解和支持的SDP主体，以便它们能够在SDP连接线中检测它们的本地地址族。无法支持与具有相同SDP产品的仅旧式IPv4和仅旧式IPv6设备的互通。显然，现有的仅IPv4的传统设备要多得多，因此本文档中假设的就是这些设备。但是，该语法允许UA选择要向后兼容的地址族，以防它有某种确定方法。
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.
此外，即使双方都支持同一个地址族，也应该有一种方法，根据UAs的决定使用“最佳”地址族交通工具。对于特定会话“最佳”的地址族不能总是先验地知道。例如，在某些情况下，IPv4传输可能更好，即使两个UAs都支持IPv6。
The proposed solution provides the following benefits:
建议的解决方案具有以下优点：
o Allows a UA to signal more than one IP address (type) in the same SDP offer.
o 允许UA在同一SDP产品中发送多个IP地址（类型）的信号。
o 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.
o 是向后兼容的。传统UA或不理解此新机制的中间SIP节点不会遇到任何解析或语义错误。
o Is as lightweight as possible to achieve the goal, while still allowing and interoperating with nodes that support other similar or related mechanisms.
o 尽可能轻量级以实现目标，同时仍然允许与支持其他类似或相关机制的节点进行交互操作。
o Is easily deployable in managed networks.
o 易于在托管网络中部署。
o Requires minimal increase of the length of the SDP offer (i.e., minimizes fragmentation risks).
o 需要最小限度地增加SDP报价的长度（即，最小化碎片风险）。
ALTC may also be useful for the multicast context (e.g., Section 3.4 of [MULTRANS-FW] or Section 3.3 of [ADDR-ACQ]).
ALTC也可用于多播上下文（例如，[MULTRANS-FW]第3.4节或[ADDR-ACQ]第3.3节）。
More detailed information about ALTC use cases is provided in Appendix A.
关于ALTC用例的更多详细信息见附录A。
This document proposes an alternative scheme, as a replacement to the ANAT procedure [RFC4091], to carry several IP address types in the same SDP offer while preserving backward compatibility.
本文件提出了一种替代方案，作为ANAT程序[RFC4091]的替代方案，在同一SDP产品中承载多个IP地址类型，同时保持向后兼容性。
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., [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 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.
虽然在SIP层直接通信的两个UAs显然需要能够为SIP本身支持相同的地址族，但当前的SIP部署几乎总是在SIP信令路径中具有代理服务器或背靠背用户代理（B2BUA），这可以在SIP层提供IP地址族的必要互通（例如。，[RFC6157]）。SIP层地址族互通不在本文档范围内。相反，本文档重点讨论以向后兼容方式通信媒体地址族功能的问题。因为媒体可以直接在两个UAs之间传输，而用户代理客户端（UAC）不必事先知道远端用户代理服务器（UAS）支持哪种地址系列，它必须以向后兼容的方式提供这两种地址系列。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The ALTC mechanism defined in this document is primarily meant for managed networks. In particular, the following use cases were explicitly considered:
本文档中定义的ALTC机制主要用于托管网络。特别是，明确考虑了以下用例：
o A dual-stack UAC that initiates a SIP session without knowing the address family of the ultimate target UAS.
o 一种双栈UAC，在不知道最终目标UAS的地址族的情况下启动SIP会话。
o A UA that receives a SIP session request with SDP offer and that wishes to avoid using IPv4 or IPv6.
o 接收具有SDP提供的SIP会话请求并希望避免使用IPv4或IPv6的UA。
o An IPv6-only UA that wishes to avoid using a NAT64 [RFC6146].
o 希望避免使用NAT64[RFC6146]的仅限IPv6的UA。
o A SIP UA behind a DS-Lite CGN [RFC6333].
o DS Lite CGN[RFC6333]后面的SIP UA。
o 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.
o 仅IPv4和/或仅IPv6 UA的SIP服务提供商或企业域，通过调用IPv4-IPv6媒体中继提供互通，希望避免调用此类功能，并尽可能让媒体端到端传输。
o 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.
o UA的SIP服务提供商或企业域，与其他域通信，希望避免调用IPv4-IPv6互通或尽可能让媒体端到端地传输。
o 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.
o 一种SIP服务提供商，为可能需要修改SDP以提供IPv4-IPv6互通的SIP会话提供传输对等服务，但希望尽可能避免此类互通或一般避免中继媒体。
o SIP sessions that use the new mechanism when crossing legacy SDP-aware middleboxes, but that may not understand this new mechanism.
o 当跨越传统SDP感知的中间盒时使用新机制的SIP会话，但可能不理解此新机制。
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 Section 3.2. The SDP answerer would indicate its chosen address by simply using that address family in the "c=" line of its response.
ALTC机制仅依赖于SDP提供/应答机制，并使用特定语法来指示备用连接地址。基本概念是使用一个新的SDP属性“altc”来指示潜在备选连接地址的IP地址。最有可能为会话选择的地址位于正常的“c=”行中。通常，在当前的运营网络中，这将是一个IPv4地址。“a=altc”行包含此会话提供的备选地址。这样，双栈UA可能会在“c=”行中对其IPv4地址进行编码，同时可能更愿意通过在相应的“a=altc”行中显式指示优先顺序来使用IPv6地址。由于第3.2节解释的原因，其中一行“a=altc”与“c=”行中包含的地址重复。SDP应答者只需在其应答的“c=”行中使用该地址族即可指示其选择的地址。
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:
当认为IPv4最有可能用于会话，但首选IPv6时，使用此机制的SDP服务示例如下：
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:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340
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:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340
If IPv6 were considered more likely to be used for the session, the SDP offer would be as follows:
如果认为IPv6更有可能用于该会话，则SDP提供如下：
v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 45678 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 45678
a=altc:2 IP4 192.0.2.1 12340
v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 45678 RTP/AVP 0 8
a=altc:1 IP6 2001:db8::1 45678
a=altc:2 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 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.
由于备用地址可能也需要备用TCP/UDP端口号，因此新的“altc”属性包括IP地址和传输端口号（或多个端口号）。ALTC机制本身不支持提供不同的传输类型（即UDP与TCP）、编解码器或任何其他属性。它仅用于提供备用IP地址和端口号。
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.
根据[RFC4566]，使用“a=”属性行是扩展SDP并使其适应特定应用程序或媒体的主要手段。兼容的SDP解析器将忽略不支持的属性行。
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 Section 4.2.1.
在“a=altc”行中编码与在“m=”和“c=”行中相同的地址和端口的基本原理是提供对传统SDP更改中间盒的检测。此类系统可能会更改连接地址和媒体传输端口号，但不支持此新机制，因此支持此机制的两个UAs将尝试连接到错误的地址。因此，本文件要求SDP处理器继续执行第4.2.1节中定义的匹配规则。
The "altc" attribute adheres to the [RFC4566] "attribute" production. The ABNF syntax [RFC5234] of altc is provided below.
“altc”属性符合[RFC4566]“属性”产品。下面提供了altc的ABNF语法[RFC5234]。
altc-attr = "altc" ":" att-value
att-value = altc-num SP addrtype SP connection-address SP port
["/" rtcp-port]
altc-num = 1*DIGIT
rtcp-port = port
altc-attr = "altc" ":" att-value
att-value = altc-num SP addrtype SP connection-address SP port
["/" rtcp-port]
altc-num = 1*DIGIT
rtcp-port = port
Figure 1: Connectivity Capability Attribute ABNF
图1：连接能力属性ABNF
The meaning of the fields are as follows:
这些字段的含义如下：
o altc-num: digit to uniquely refer to an address alternative. It indicates the preference order, with "1" indicated the most preferred address.
o altc num：唯一引用地址替代项的数字。它表示优先顺序，“1”表示最优先的地址。
o addrtype: the addrtype field as defined in [RFC4566] for connection data.
o addrtype:[RFC4566]中定义的连接数据的addrtype字段。
o connection-address: a network address as defined in [RFC4566] corresponding to the address type specified by addrtype.
o 连接地址：[RFC4566]中定义的网络地址，对应于addrtype指定的地址类型。
o port: the port number to be used, as defined in [RFC4566]. 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.
o 端口：要使用的端口号，如[RFC4566]中所定义。每个IP地址类型可以使用不同的端口号。如果指定的地址类型不需要端口号，则应使用为该地址类型定义的值。
o 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.
o rtcp端口：包括RTP控制协议（rtcp）端口是可选的。当RTCP端口无法从RTP端口派生时，可在备选“c=”行中指示RTCP端口。
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.
“altc”属性仅适用于SDP报价。“altc”属性是仅媒体级别的属性，不得出现在SDP会话级别。（因为它定义了一个端口号，所以它本质上与媒体级别绑定。）在每个媒体描述中，每个addrtype不能有多个“altc”属性。此限制是必要的，以便报价人可以使用回复的addrtype来确定接受哪种备选方案。
The "addrtype"s of the altc MUST correspond to the "nettype" of the current connection ("c=") line.
altc的“addrtype”必须与当前连接（“c=”）行的“nettype”相对应。
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.
媒体描述必须包含两个“altc”属性：可选地址和可选端口。它还必须包含一个地址和一个端口，用于“复制”当前“c=”和“m=”行中的地址/端口信息。每个媒体级别必须至少包含一个这样的重复“altc”属性，其IP地址系列、地址和传输端口号与其级别的SDP连接和媒体线路中的IP地址系列、地址和传输端口号相同。特别是，如果“c=”行出现在介质描述中，则该“c=”行中的addrtype和连接地址必须用于该介质描述的重复“altc”属性中。如果“c=”行仅出现在会话级别，且给定的媒体描述没有自己的连接行，则该媒体描述的重复“altc”属性必须与会话级别地址信息相同。
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.
媒体描述中出现的“altc”属性必须优先排序。明确的优先顺序显示在每一行（“1”表示具有最高优先级的地址）。考虑到这一规则以及“m=”行和“o=”行中提供的地址信息也必须在“altc”属性中提供的要求，“m=”行和“o=”行中的地址可能不是首选。
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.
如果“altc”属性的addrtype与介质描述中指定的传输协议或介质格式不兼容，则必须忽略该“altc”属性。
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.
请注意，“a=altc”行描述的是备用连接地址，而不是并行连接的地址。当存在多条“altc”线路时，必须避免建立多个会话。对于关联的媒体描述，只需与远程方保持一个会话。
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.
在SDP报价/应答模型中，SDP报价包括“altc”属性，用于指示备选连接信息（即地址类型、地址和端口号），包括“c=”和“m=”行中已标识的“重复”连接信息。
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:
另外，后续产品可能会再次包含“altc”属性，并且可能会更改IP地址、端口号和优先顺序，但必须在该特定后续产品中包含连接和媒体线路的重复“altc”属性。换言之，每个提供的SDP媒体描述以及具有“altc”属性的备选地址提供都有两个“altc”属性：
- one duplicating the "c=" and "m=" line information for that media description
- 复制该介质描述的“c=”和“m=”行信息的一个
- one for the alternative
- 一个是另一个
These need not be the same as the original SDP offer.
这些服务不必与原始SDP服务相同。
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.
编码重复的“altc”属性的目的是允许SDP报价的接收者检测传统SDP变更中间盒是否修改了“c=”和/或“m=”线路地址/端口信息。如果SDP应答器未找到地址和端口与“c=”行和“m=”行中的地址和端口完全匹配的重复“altc”属性值，则SDP应答器必须忽略“altc”属性，并为整个SDP使用“c=”和“m=”提供的地址/端口，就像不存在“altc”属性一样。这样做的理由是，如果许多SDP更改中间盒未检测到媒体流经，它们将结束媒体会话。如果中间盒修改了SDP地址，则必须使用修改后的信息发送媒体。
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 [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.
请注意，对于RTCP，如果适用于给定的媒体类型，则每一方的行为将如同所选的“altc”属性的端口号位于“m=”媒体行中一样。通常，这意味着RTCP被发送到等于“RTP端口+1”的端口号，除非其他属性另有规定。例如，[RFC5761]中定义的RTP/RTCP多路复用机制仍然可以与ALTC一起使用，因此，如果双方都支持多路复用，他们将使用[RFC5761]中定义的“a=RTCP mux”属性来指示，但他们使用的IP连接地址和端口可以使用ALTC机制来选择。
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 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 [RFC3605]. 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.
如果SDP报价人希望使用[RFC3605]中定义的RTCP属性，可能会出现复杂情况，因为相对于ALTC提供的选择，“a=RTCP”属性适用于哪个地址选择可能不清楚。从技术上讲，RFC 3605允许在“a=RTCP”属性本身中显式指示RTCP的地址，但这是可选的，很少使用。因此，本文档建议对“m=”行中编码的地址选择使用“a=rtcp”属性，并在与备用地址对应的“a=altc”属性中包含备用rtcp端口。换句话说，如果“a=rtcp”属性在其属性中显式编码地址，则该地址适用于ALTC，如[RFC3605]。如果没有，则ALTC假定“a=rtcp”属性用于“m=”行中的地址，而可选的“ALTC”属性包括rtcp备用端口号。
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.
SDP答案不应包含“altc”属性，因为答案的“c=”行隐式地、明确地从报价中选择地址系列，并将其包含在答案的“c=”和“m=”行中。此外，这避免了在参与的对等方之间同时建立多个会话。
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.
任何需要在SDP应答中使用ALTC的解决方案都应记录其使用情况，特别是如何在参与的对等方之间建立会话。
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 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.
由于ICE[RFC5245]在其候选属性中还包括地址和端口号信息，因此出现了一个潜在的问题：哪一个获胜。由于ICE还包括SDP答案中的特定ICE属性，因此问题很容易避免：如果SDP报价人同时支持ALTC和ICE，则可能在同一SDP报价中包括这两组属性。传统的ICE专用应答器将简单地忽略“altc”属性并使用ICE。仅限ALTC的应答者将忽略ICE属性，并在没有这些属性的情况下进行应答。支持这两种机制的回答者必须选择且仅选择一种机制：ICE或ALTC。但是，如果中间框更改了“m=”或“c=”行，则ALTC和ICE的规则将使应答者恢复到基本的SDP语义。
The ALTC mechanism is orthogonal to SDPCapNeg [RFC5939]. If the offerer supports both ALTC and SDPCapNeg, it may offer both.
ALTC机制与SDPCapNeg[RFC5939]正交。如果报价人同时支持ALTC和SDPCapNeg，则可以同时提供这两种服务。
Per this document, the following new SDP attribute has been assigned.
根据本文档，已分配以下新的SDP属性。
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute name altc Long form Alternate Connectivity Type of name att-field Type of attribute Media level only Subject to charset No Purpose See Sections 1.2 and 3 Specification Section 4
属性名称altc长格式备用连接类型名称att字段类型属性媒体级别仅受字符集限制无目的请参见第1.2节和第3节规范第4节
The contact person for this registration is Mohamed Boucadair (email: mohamed.boucadair@orange.com; phone: +33 2 99 12 43 71).
此次注册的联系人是Mohamed Boucadair（电子邮件：Mohamed。boucadair@orange.com电话：+3329914371）。
The security implications for ALTC are effectively the same as they are for SDP in general [RFC4566].
ALTC的安全含义实际上与SDP的安全含义相同[RFC4566]。
Many thanks to T. Taylor, F. Andreasen, and G. Camarillo for their review and comments.
非常感谢T.泰勒、F.安德里森和G.卡马里洛的评论和评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC3605，2003年10月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[ADDR-ACQ] Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q. Sun, "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Work in Progress, January 2013.
[ADDR-ACQ]Tsou，T.，Clauberg，A.，Boucadair，M.，Venaas，S.，和Q.Sun，“源和接收器支持不同IP版本时多播内容的地址获取”，正在进行中，2013年1月。
[ADDR-FORMAT] Boucadair, M., Ed., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv6 Multicast Address With Embedded IPv4 Multicast Address", Work in Progress, April 2013.
[ADDR-FORMAT]Boucadair，M.，Ed.，Qin，J.，Lee，Y.，Venaas，S.，Li，X.，和M.Xu，“具有嵌入式IPv4多播地址的IPv6多播地址”，正在进行的工作，2013年4月。
[MULTRANS-FW] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
[MULTRANS-FW]Venaas，S.，Li，X.，和C.Bao，“IPv4/IPv6多播转换框架”，正在进行的工作，2011年6月。
[MULTRANS-PS] Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and Use Cases", Work in Progress, March 2013.
[MULTRANS-PS]Jacquenet，C.，Boucadair，M.，Lee，Y.，Qin，J.，Tsou，T.，和Q.Sun，“IPv4-IPv6多播：问题陈述和用例”，正在进行的工作，2013年3月。
[NAT64-EXP] Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. Queiroz, "PCP NAT64 Experiments", Work in Progress, September 2012.
[NAT64-EXP]Abdesselam，M.，Boucadair，M.，Hasnaoui，A.，和J.Queiroz，“PCP NAT64实验”，正在进行的工作，2012年9月。
[RFC2871] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000.
[RFC2871]Rosenberg，J.和H.Schulzrinne，“IP电话路由框架”，RFC 28712000年6月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091]Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）分组框架的替代网络地址类型（ANAT）语义”，RFC 4091，2005年6月。
[RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)", RFC 4092, June 2005.
[RFC4092]Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）替代网络地址类型（ANAT）语义在会话启动协议（SIP）中的使用”，RFC 4092，2005年6月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853]Hautakorpi，J.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年4月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年9月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157]Camarillo，G.，El Malki，K.，和V.Gurbani，“会话启动协议（SIP）中的IPv6转换”，RFC 6157，2011年4月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6406] Malas, D. and J. Livingood, "Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture", RFC 6406, November 2011.
[RFC6406]Malas，D.和J.Livingood，“多媒体互连（SPEERMINT）架构的会话对等”，RFC 6406，2011年11月。
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888]Perreault，S.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，2013年4月。
The following terms are used when discussing the ALTC use cases:
讨论ALTC用例时使用以下术语：
o SBE (Signaling Path Border Element) denotes a functional element, located at the boundaries of an ITAD (IP Telephony Administrative Domain) [RFC2871], 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 [RFC6406]. An SBE controls one or more DBEs. The SBE and DBE may be located in the same device (e.g., the SBC [RFC5853]) or be separated.
o SBE（信令路径边界元素）表示位于ITAD（IP电话管理域）[RFC2871]边界处的功能元素，其负责截获从UAs接收的信令流并将其中继到核心服务平台。SBE可以位于接入段（即UAs的服务接触点），或者位于与相邻域的互连处[RFC6406]。SBE控制一个或多个DBE。SBE和DBE可以位于同一设备中（例如，SBC[RFC5853]）或分开。
o 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 ([RFC6406]).
o DBE（数据路径边界元素）表示位于ITAD边界处的功能元素，负责截取从UAs接收的媒体/数据流，并将其中继到另一个DBE（或媒体服务器，例如公告服务器或IVR）。DBE的一个示例是拦截RTP流的媒体网关。SBE可以位于接入段（即UAs的服务接触点）或位于与相邻域的互连处（[RFC6406]）。
o Core service platform ("core SPF") is a macro functional block including session routing, interfaces to advanced services, and access control.
o 核心服务平台（“核心SPF”）是一个宏功能块，包括会话路由、高级服务接口和访问控制。
Figure 2 provides an overview of the overall architecture, including the SBE, DBE, and core service platform.
图2提供了总体架构的概述，包括SBE、DBE和核心服务平台。
+----------+
| Core SIP |
+--------->| SPF |<---------+
| SIP +----------+ SIP |
v v
+-----------+ +-----------+
+-----+ SIP | SBE | | SBE | SIP
| S |<----->| | | |<----->
| I | +-----------+ +-----------+
| P | || ||
| | +-----------+ +-----------+
| U | RTP | DBE | RTP | DBE | RTP
| A |<----->| |<----------------->| | <----->
+-----+ +-----------+ +-----------+
+----------+
| 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
SIP UA可以嵌入到CPE中或CPE后面的主机中
Figure 2: Service Architecture Overview
图2：服务架构概述
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., [RFC6146]). 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 [MULTRANS-PS].
最近，IETF内已做出重大努力，指定新机制，将仅IPv6主机互连到仅IPv4服务器（例如，[RFC6146]）。这项工作专门涉及单播传输模式。一项名为“multrans”的持续计划已经启动，以涵盖IPv6过渡期间遇到的多播问题。整体问题陈述记录在[MULTRANS-PS]中。
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 [MULTRANS-PS]):
在多播服务的IPv4/IPv6共存和IPv6转换环境中遇到的一个特殊问题是多播组和源的发现（请参阅[MULTRANS-PS]的第3.4节）：
o For an IPv6-only receiver requesting multicast content generated by an IPv4-only source:
o 对于请求由仅IPv4源生成的多播内容的仅IPv6接收器：
* 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.
* 当仅播发IPv4地址时（例如，使用SDP），需要ALG来帮助IPv6接收器选择适当的IP地址。否则，无法向IPv6接收器提供对IPv4多播内容的访问。ALG可位于接收器的下游。因此，ALG事先不知道接收器是双栈还是仅IPv6。可以使用例如ALTC SDP属性来调整ALG以插入原始IPv4地址和相应的IPv6多播地址。
* 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 [ADDR-FORMAT] using, for instance, the ALTC SDP attribute.
* 为了避免在路径中涉及ALG，仅IPv4的源可以使用（例如）ALTC SDP属性通告其IPv4地址和其IPv4嵌入式IPv6多播地址[ADDR-FORMAT]。
o 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.
o 对于通过IPv4和IPv6发送其多播内容的双堆栈源，需要在SDP部分中插入IPv4和IPv6地址。为此需要一种方法（如ALTC）。
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 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:
一些服务提供商正在启用DS Lite[RFC6333]作为继续向其客户提供IPv4服务的手段。为避免在建立媒体会话时跨越四个NAT级别（DS Lite地址系列转换路由器（AFTR）中的两个NAT和DBE中的两个NAT），建议在某些SBE/DBE中启用IPv6功能。然后，如果DS Lite服务客户的UA已启用IPv6，则不会跨越DS Lite AFTR：
o For a SIP UA embedded in the CPE, this is easy to implement since the SIP UA [RFC3261] can be tuned to behave as an IPv6-only UA when DS-Lite is enabled. No ALTC is required for this use case. o 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.
o 对于嵌入在CPE中的SIP UA，这很容易实现，因为当启用DS Lite时，SIP UA[RFC3261]可以调整为仅适用于IPv6的UA。此用例不需要ALTC。o对于位于CPE后面的SIP UAs，需要一个同时指示IPv4和IPv6（例如，ALTC）的解决方案，以避免穿越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.
使用仅IPv4核心服务平台向启用IPv6的UA提供基于SIP的服务的基本解决方案是在SBE/DBE中启用IPv4/IPv6互通功能。两个SBE和DBE之间的信令和媒体通过IPv4进行维护。IPv6在启用IPv6的UA和SBE/DBE之间使用。
Figure 3 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.
图3显示了UAs之间会话建立的结果。在此场景中，即使两个相关UAs都启用了IPv6，也会调用IPv4/IPv6互通功能。
+----------+
| 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| | |<-------+
|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 |
+----+ +-----------+ +-----------+ +----+
+----------+
| 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
图3：基本场景
It may be valuable for service providers to consider solutions that avoid redundant IPv4/IPv6 NATs and that avoid involving several DBEs.
对于服务提供商来说，考虑避免冗余IPv4/IPv6 NAT并且避免涉及多个DBE的解决方案可能是有价值的。
A solution to indicate both IPv4 and IPv4 addresses is required for service providers that want the following:
需要以下内容的服务提供商需要一个同时指示IPv4和IPv4地址的解决方案：
1. 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. 2. To optimize the cost related to IPv4-IPv6 translation licenses. 3. To reduce the dual-stack lifetime. 4. To maintain an IPv4-only core. 5. To have a set of SBEs/DBEs that are IPv6-enabled.
1. 一种促进IPv6传输功能调用的方法，可启用该功能，同时核心服务遗留节点不会遇到解析错误。2.优化与IPv4-IPv6转换许可证相关的成本。3.以缩短双堆栈的使用寿命。4.要维护仅IPv4的核心。5.要拥有一组启用IPv6的SBE/DBE。
This section provides an overview of the procedure to avoid IPv4/IPv6 interworking.
本节概述了避免IPv4/IPv6互通的过程。
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 Figure 4.
当SBE收到INVITE时，它在其DBE中实例化IPv6-IPv6上下文和IPv6-IPv4上下文。将返回IPv6地址和IPv4地址以及端口号等其他信息。SBE构建SDP服务，包括使用“altc”属性的IPv4和IPv6相关信息。IPv6被指示为首选连接类型；参见图4。
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:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
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:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 4: SDP Offer Updated by the SBE
图4:SBE更新的SDP报价
The request is then forwarded to the core SPF, which, in turn, forwards it to the terminating SBE.
然后将请求转发给核心SPF，核心SPF又将其转发给终止SBE。
o If this SBE is a legacy one, then it will ignore "altc" attributes and use the "c=" line.
o 如果此SBE是传统SBE，则它将忽略“altc”属性并使用“c=”行。
o If the terminating SBE is IPv6-enabled:
o 如果终止SBE已启用IPv6：
* If the called UA is IPv4 only, then an IPv6-IPv4 context is created in the corresponding DBE.
* 如果被调用的UA仅为IPv4，则在相应的DBE中创建IPv6-IPv4上下文。
* If the called UA is IPv6-enabled, then an IPv6-IPv6 context is created in the corresponding DBE.
* 如果被调用的UA已启用IPv6，则在相应的DBE中创建IPv6-IPv6上下文。
Figure 5 shows the results 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 optimal since redundant NAT66 is required (Appendix A.3.4).
图5显示了在IPv4和IPv6 UAs之间放置会话时的过程结果，而图6显示了在两个启用IPv6的UAs之间建立会话的结果。由于需要冗余NAT66，因此结果仍然不是最佳的（附录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
+----------+
| 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 Establishment between IPv4 and IPv6 UAs
图5:IPv4和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
+----------+
| 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 Establishment between IPv6 UAs
图6:IPv6 UAs之间的会话建立
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.
如果服务提供商希望在并非所有SBE/DBE和UAs都启用IPv6的情况下仅在媒体路径中包含一个DBE，则需要一种在不导致会话失败的情况下同时指示IPv4和IPv6地址的方法。本节介绍使用“altc”属性的示例过程。
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
当发起SBE从启用IPv6的UA接收到邀请时，它在其DBE中实例化IPv6-IPv6上下文和IPv6-IPv4上下文。将返回IPv6地址和IPv4地址以及其他信息，如端口号。SBE
builds an SDP offer, including both IPv4 and IPv6-related information using the "altc" attribute (Figure 7). IPv6 is indicated as preferred connectivity type.
使用“altc”属性构建SDP产品，包括IPv4和IPv6相关信息（图7）。IPv6被指示为首选连接类型。
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:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
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:1 IP6 2001:db8::2 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 7: SDP Offer Updated by the SBE
图7:SBE更新的SDP报价
The request is then forwarded to the core SPF, which, in turn, forwards it to the terminating SBE:
然后将请求转发至核心SPF，核心SPF再将其转发至终端SBE：
o 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.
o 如果目标UA是IPv6或可通过公共IPv4地址访问，则SBE仅转发请求而不更改SDP提供。核心服务节点没有遇到解析错误，因为ALTC是向后兼容的。
o If the terminating SBE does not support ALTC, it will ignore this attribute and use the legacy procedure.
o 如果终止SBE不支持ALTC，它将忽略此属性并使用传统过程。
As a consequence, only one DBE is maintained in the path when one of the involved parties is IPv6-enabled. Figure 8 shows the overall procedure when the involved UAs are IPv6-enabled.
因此，当其中一方启用IPv6时，路径中只维护一个DBE。图8显示了相关UAs启用IPv6时的总体过程。
+----------+
| 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
+----------+
| 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
图8：DBE旁路概述
The main advantages of such a solution are as follows:
这种解决方案的主要优点如下：
o DBE resources are optimized. o No redundant NAT is maintained in the path when IPv6-enabled UAs are involved. o End-to-end delay is optimized. o The robustness of the service is optimized since the delivery of the service relies on fewer nodes. o The signaling path is also 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.)
o 优化了DBE资源。o当涉及支持IPv6的UAs时，不会在路径中维护冗余NAT。o端到端延迟得到优化。o由于服务的交付依赖较少的节点，因此服务的健壮性得到了优化。o由于某些会话不需要终端侧的SBE和DBE之间的通信，因此信令路径也得到了优化。（该通信将通过电信和互联网融合服务和协议的高级网络/IP多媒体子系统（TISPAN/IMS）上下文中的服务策略决策功能（SPDF）进行。）
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.
对于希望允许启用IPv6的UAs之间直接IPv6通信的服务提供商，当并非所有SBE/DBE和UAs都启用IPv6时，需要一种在不导致会话失败的情况下指示IPv4和IPv6地址的方法。下面是使用“altc”属性的建议程序的示例。
At the SBE originating side, when the SBE receives an INVITE from the calling IPv6 UA (Figure 9), it uses ALTC to indicate two IP addresses:
在SBE发起端，当SBE接收到来自主叫IPv6 UA的INVITE时（图9），它使用ALTC指示两个IP地址：
1. An IPv4 address belonging to its controlled DBE. 2. The same IPv6 address and port as received in the initial offer made by the calling IPv6.
1. 属于其受控DBE的IPv4地址。2.与主叫IPv6发出的初始要约中接收到的IPv6地址和端口相同。
Figure 9 shows an excerpted example of the SDP offer of the calling UA, and Figure 10 shows an excerpted example of the updated SDP offer generated by the originating SBE.
图9显示了主叫UA的SDP报价的摘录示例，图10显示了由发起SBE生成的更新SDP报价的摘录示例。
o=- 25678 753849 IN IP6 2001:db8::1
c=IN IP6 2001:db8::1
m=audio 6000 RTP/AVP 0 8
o=- 25678 753849 IN IP6 2001:db8::1
c=IN IP6 2001:db8::1
m=audio 6000 RTP/AVP 0 8
Figure 9: SDP Offer of the Calling UA
图9：呼叫UA的SDP报价
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:1 IP6 2001:db8::1 6000
a=altc:2 IP4 192.0.2.2 12340
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:1 IP6 2001:db8::1 6000
a=altc:2 IP4 192.0.2.2 12340
Figure 10: SDP Offer Updated by the SBE
图10:SBE更新的SDP报价
The INVITE message will be routed appropriately to the destination SBE:
INVITE消息将适当路由到目标SBE：
1. 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. 2. If the SBE is IPv6-enabled, it will only forward the INVITE to the address of contact of the called party:
1. 如果SBE是传统设备（即，仅IPv4），它将忽略IPv6地址并联系其DBE以实例化IPv4-IPv4上下文。2.如果SBE已启用IPv6，它将只将邀请转发到被叫方的联系人地址：
a. 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 Figure 11. b. Otherwise, IPv4 will be used between the originating DBE and the called UA.
a. 如果被叫方已启用IPv6，则将使用IPv6进行通信。因此，数据路径中不涉及DBE，如图11所示。B否则，将在发起DBE和被调用UA之间使用IPv4。
+----------+
| 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
+----------+
| 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
图11：直接IPv6通信
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
美国马萨诸塞州伯灵顿第三大道71号Hadriel Kaplan Acme包01803
EMail: hkaplan@acmepacket.com
EMail: hkaplan@acmepacket.com
Robert R Gilman Independent
罗伯特·吉尔曼独立报
EMail: bob_gilman@comcast.net
EMail: bob_gilman@comcast.net
Simo Veikkolainen Nokia
诺基亚西莫·维科莱宁
EMail: Simo.Veikkolainen@nokia.com
EMail: Simo.Veikkolainen@nokia.com