Network Working Group G. Camarillo
Request for Comments: 4091 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
Network Working Group G. Camarillo
Request for Comments: 4091 Ericsson
Category: Standards Track J. Rosenberg
Cisco Systems
June 2005
The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
会话描述协议（SDP）分组框架的可选网络地址类型（ANAT）语义
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream.
本文档定义了会话描述协议（SDP）分组框架的可选网络地址类型（ANAT）语义。ANAT语义允许不同类型的网络地址建立特定的媒体流。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope and Relation with Interactive Connectivity
Establishment. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Offer/Answer and ANAT . . . . . . . . . . . . . . . . . . . . 3
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informational References . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope and Relation with Interactive Connectivity
Establishment. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ANAT Semantics . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Offer/Answer and ANAT . . . . . . . . . . . . . . . . . . . . 3
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informational References . . . . . . . . . . . . . . . . 5
A Session Description Protocol (SDP) [2] session description contains the media parameters to be used in establishing a number of media streams. For a particular media stream, an SDP session description contains, among other parameters, the network addresses and the codec to be used in transferring media. SDP allows for a set of codecs per media stream, but only one network address.
会话描述协议（SDP）[2]会话描述包含用于建立多个媒体流的媒体参数。对于特定媒体流，SDP会话描述除其他参数外，还包含传输媒体时使用的网络地址和编解码器。SDP允许每个媒体流有一组编解码器，但只有一个网络地址。
The ability to offer a set of network addresses to establish a media stream is useful in environments with both IPv4-only hosts and IPv6-only hosts, for instance.
例如，提供一组网络地址以建立媒体流的功能在具有仅IPv4主机和仅IPv6主机的环境中非常有用。
This document defines the Alternative Network Address Types (ANAT) semantics for the SDP grouping framework [4]. The ANAT semantics allow for the expression of alternative network addresses (e.g., different IP versions) for a particular media stream.
本文档定义了SDP分组框架的可选网络地址类型（ANAT）语义[4]。ANAT语义允许表达特定媒体流的备选网络地址（例如，不同的IP版本）。
The ANAT semantics are intended to address scenarios that involve different network address types (e.g., different IP versions). They are not intended to provide alternative transport addresses with the same network type. Systems that need to provide different transport addresses with the same network type should use the SDP format defined in ICE (Interactive Connectivity Establishment) [6] instead.
ANAT语义旨在解决涉及不同网络地址类型（例如，不同IP版本）的场景。它们不打算提供具有相同网络类型的替代传输地址。需要提供具有相同网络类型的不同传输地址的系统应使用ICE（交互式连接建立）[6]中定义的SDP格式。
ICE is used by systems that cannot determine their own transport address as seen from the remote end, but that can provide several possible alternatives. ICE encodes the address that is most likely to be valid in an 'm' line, and the rest of addresses as a= lines after that 'm' line. This way, systems that do not support ICE simply ignore the a= lines and only use the address in the 'm' line. This achieves good backward compatibility.
ICE用于无法从远端确定自身传输地址的系统，但可以提供几种可能的替代方案。ICE将最有可能在“m”行中有效的地址编码，并将该“m”行之后的其余地址编码为a=行。这样，不支持ICE的系统就会忽略a=行，而只使用“m”行中的地址。这实现了良好的向后兼容性。
We have chosen to group 'm' lines with different IP versions at the 'm' level (ANAT semantics) rather than at the a= level (ICE format) in order to keep the IPv6 syntax free from ICE parameters used for legacy (IPv4) NATs (Network Address Translators). This yields a syntax much closer to vanilla SDP, where IPv6 addresses are defined in their own 'm' line, rather than in parameters belonging to a different 'm' line.
我们选择在“m”级别（ANAT语义）而不是在a=级别（ICE格式）将具有不同IP版本的“m”行分组，以使IPv6语法不受用于传统（IPv4）NAT（网络地址转换器）的ICE参数的影响。这产生了一种更接近于vanilla SDP的语法，其中IPv6地址在它们自己的“m”行中定义，而不是在属于不同“m”行的参数中定义。
Additionally, ICE only allows us to provide a single primary address when the peer does not support ICE. The ANAT semantics avoid relegating certain types of addresses (e.g., IPv6 addresses) to only be a secondary alternate to another address type (e.g., IPv4 addresses).
此外，当对等方不支持ICE时，ICE仅允许我们提供单个主地址。ANAT语义避免将某些类型的地址（例如IPv6地址）降级为另一种地址类型（例如IPv4地址）的次要替代地址。
Furthermore, the separation between ANAT and ICE helps systems that support IPv4 and IPv6 but that do not need to support ICE (e.g., a multicast server).
此外，ANAT和ICE之间的分离有助于支持IPv4和IPv6但不需要支持ICE的系统（例如，多播服务器）。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
We define a new "semantics" attribute within the SDP grouping framework [4]: ANAT (Alternative Network Address Types).
我们在SDP分组框架[4]中定义了一个新的“语义”属性：ANAT（可选网络地址类型）。
Media lines grouped using ANAT semantics provide alternative network addresses of different types for a single logical media stream. The entity creating a session description with an ANAT group MUST be ready to receive (or send) media over any of the grouped 'm' lines. The ANAT semantics MUST NOT be used to group media streams whose network addresses are of the same type.
使用ANAT语义分组的媒体线路为单个逻辑媒体流提供不同类型的可选网络地址。使用ANAT组创建会话描述的实体必须准备好通过任何分组的“m”行接收（或发送）媒体。ANAT语义不能用于对网络地址为相同类型的媒体流进行分组。
The entity generating a session description may have an order of preference for the alternative network address types offered. The identifiers of the media streams MUST be listed in order of preference in the group line. For example, in the session description in Section 6, the 'm' line with mid=1 has a higher preference than the 'm' line with mid=2.
生成会话描述的实体可以具有所提供的备选网络地址类型的优先顺序。媒体流的标识符必须在组行中按优先顺序列出。例如，在第6节的会话描述中，mid=1的“m”行比mid=2的“m”行具有更高的优先级。
An offerer using SIP [3] to send its offer SHOULD place the sdp-anat option-tag [5] in a Require header field.
使用SIP[3]发送报价的报价人应将sdp anat选项标记[5]放置在Require标头字段中。
An answerer receiving a session description that uses the ANAT semantics SHOULD use the address with the highest priority it understands and set the ports of the rest of the 'm' lines of the group to zero.
收到使用ANAT语义的会话描述的应答者应使用其理解的优先级最高的地址，并将组中其余“m”行的端口设置为零。
The session description below contains an IPv4 address and an IPv6 address grouped using ANAT. The format corresponding to the mapping of ICE into SDP [6] can be used in both 'm' lines to provide additional addresses.
下面的会话描述包含使用ANAT分组的IPv4地址和IPv6地址。与ICE到SDP[6]的映射相对应的格式可在两个“m”行中使用，以提供额外的地址。
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
t=0 0
a=group:ANAT 1 2
m=audio 25000 RTP/AVP 0
c=IN IP6 2001:DB8::1
a= <ICE-encoded additional IPv6 addresses (and ports)>
a=mid:1
m=audio 22334 RTP/AVP 0
c=IN IP4 192.0.2.1
a= <ICE-encoded additional IPv4 addresses (and ports)>
a=mid:2
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
t=0 0
a=group:ANAT 1 2
m=audio 25000 RTP/AVP 0
c=IN IP6 2001:DB8::1
a= <ICE-encoded additional IPv6 addresses (and ports)>
a=mid:1
m=audio 22334 RTP/AVP 0
c=IN IP4 192.0.2.1
a= <ICE-encoded additional IPv4 addresses (and ports)>
a=mid:2
An attacker adding group lines, using the ANAT semantics, to an SDP session description could make an end-point use only one out of all the streams offered by the remote end, when the intention of the remote-end might have been to establish all the streams.
攻击者使用ANAT语义将组行添加到SDP会话描述中，可能会使端点仅使用远程端提供的所有流中的一个，而远程端的意图可能是建立所有流。
An attacker removing group lines using ANAT semantics could make an end-point establish a higher number of media streams. If the end-point sends media over all of them, the session bandwidth may increase dramatically.
攻击者使用ANAT语义删除组行可能会使端点建立更多的媒体流。如果端点通过所有端口发送媒体，会话带宽可能会显著增加。
It is thus strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [3], S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [3]. Other applications MAY use a different form of integrity protection.
因此，强烈建议对SDP会话描述应用完整性保护。对于SIP[3]中的会话描述，S/MIME是提供端到端完整性保护的自然选择，如RFC 3261[3]中所述。其他应用程序可能使用不同形式的完整性保护。
The IANA has registered the following new 'semantics' attribute for the SDP grouping framework [4]:
IANA已为SDP分组框架[4]注册了以下新的“语义”属性：
Semantics Token Reference
--------------------------------- ----- ---------
Alternative Network Address Types ANAT [RFC4091]
Semantics Token Reference
--------------------------------- ----- ---------
Alternative Network Address Types ANAT [RFC4091]
ANAT has been registered in the SDP parameters registry under Semantics for the "group" SDP Attribute.
ANAT已在SDP参数注册表中的“group”SDP属性语义下注册。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] 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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[4] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[5] 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.
[5] Camarillo，G.和J.Rosenberg，“会话描述协议（SDP）替代网络地址类型（ANAT）语义在会话启动协议（SIP）中的使用”，RFC 4092，2005年6月。
[6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", Work in Progress, February 2005.
[6] Rosenberg，J.，“交互式连接建立（ICE）：多媒体会话建立协议的网络地址转换器（NAT）遍历方法”，正在进行的工作，2005年2月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
EMail: jdrosen@cisco.com
EMail: jdrosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。